1 Fleet Management Security Overview

This chapter provides an overview of Oracle Hospitality Cruise Fleet Management security and explains the general principles of application security.

Basic Security Considerations

The following principles are fundamental to using any application securely:

  • Keep software up to date. This includes the latest product release and any patches that apply to it.

  • Limit privileges as much as possible. Users should be given only the access necessary to perform their work. User privileges should be reviewed periodically to determine relevance to current work requirements.

  • Monitor system activity. Establish who should access which system components, and how often, and monitor those components.

  • Install software securely. For example, use firewalls, secure protocols using Transport Layer Security (TLS), Secure Sockets Layer (SSL), and secure passwords. See Performing a Secure Fleet Management Installation for more information.

  • Learn about and use the Fleet Management security features. See Implementing Fleet Management Security for more information.

  • Use secure development practices. For example, take advantage of existing database security functionality instead of creating your own application security. See Security Considerations for Developers for more information.

  • Keep up to date on security information. Oracle regularly issues security-related patch updates and security alerts. You must install all security patches as soon as possible. See the “Critical Patch Updates and Security Alerts” website: http://www.oracle.com/technetwork/topics/security/alerts-086861.html

Overview of Fleet Management Security

Fleet Management Architecture Overview

Fleet Management uses a Client-Server Architecture (partially 3-tier architecture) and is a collection of desktop applications, Interfaces, web apps/web services. Most of the application pieces are thick clients that can be deployed anywhere and few are thin clients with business layers in the form of web services, few are stand-alone applications/interfaces used for internal processing/integration. It is scalable and does not have to be deployed on a single machine

Technology

Fleet Management Client-Server Architecture (partially 3-tier architecture) uses industry standards Simple Object Access Protocol (SOAP) web services to work with internal and external applications. SOAP-based web services are deployed and exposed on Microsoft Internet Information Services (IIS) web server, and IIS provides options to secure the communication using Secure Sockets Layer (SSL). It also uses Microsoft Message Queuing (MSMQ) in Work Group mode and also with Active Directory Integration (secure mode), Transmission Control Protocol/Internet Protocol (TCP/IP), File System for data transfer/third-party integration. Most of the communication can be configured to use Secure Sockets Layer (SSL) and, Oracle Wallets is used to secure communication between the client and the Oracle Database. It also uses recommended encryption/hashing algorithms such as Microsoft managed Rijndael, Microsoft Windows Data Protection Application Programming Interface (DPAPI), SHA256, Password-Based Key Derivation Function 2 (PBKDF2) to encrypt and store sensitive customer information, application user passwords, application configuration information, secrets, and passwords. At the database level, it also uses Transparent Data Encryption (TDE) to protect the data at rest

Figure 1-1 Fleet Management Architecture


This figure shows the Fleet Management Architecture

User Authentication

Overview

Authentication is the process of ensuring that people are who they say they are.

Thin and Thick Client Authentication

All user’s credentials of Fleet Management are stored in the database. Anyone who wishes to access the thin or thick clients must provide a valid user name and password. To ensure strict access control of the Fleet Management, always assign unique usernames and complex passwords to each user. Password must follow Payment Card Industry-Data Security Standard (PCI-DSS) guidelines, and must be at least 8 characters long and includes letters and numbers.

An alternative authentication method for thin and thick clients is Active Directory Lightweight Directory Access Protocol (LDAP). In this case, the Microsoft Windows username is used to login into the thin and thick clients.

Web Service Authentication

Web service uses a two-level approach for authentication.

Security Token Approach: This method is used in the Web Services/Web Apps Only. For the first time/first request, predefined credentials are passed to gain a security token, and a security token is used with subsequent requests throughout the session.

Basic Authentication In Combination With Secure Sockets Layer (SSL): This method is used for the web services/web apps in combination with the above method. Authentication is linked to a specific Microsoft Windows user account. Microsoft Windows user account/password needs to be passed with each validation request, and the Secure Sockets Layer (SSL) certificate is configured to make the requests secure.

Database Users

Fleet Management creates and uses predefined database users as required. FIDELIOBK, FCFMSADMIN, FCONSOL, FCRESVINT, FCRESVEXT, FCITIN, FCWKF, FCCAM, FCUCI are the important predefined users used for different applications/solutions. FIDELIOBK is the key database user that stores the passwords/encryption keys for other database users in an encrypted form. Clients connect to the FIDELIOBK user to obtain the passwords/encryption keys for database other users. FCFMSADMIN is the admin database user with all of the required configuration, application user security, and parameters. The remaining database users are used for different applications/solutions.

Security Note

FIDELIOBK user password and Key Encryption Key (KEK) are hosted/stored on a Fleet Management Security Server. Clients need to connect to the Fleet Management Security Server once to fetch the FIDELIOBK user password and KEK, and store them locally in its configuration file in an encrypted form using Microsoft Windows Data Protection Application Programming Interface (DPAPI) method. In the event where the FIDELIOBK user password has changed, the application then fetches the updated password from the Security Server before updating the Clients password and encryption keys for the other database users.

Understanding the Fleet Management Environment

When planning your Fleet Management implementation, consider the following:

  • Which resources need to be protected?

    • You need to protect customer data, such as credit card numbers.

    • You need to protect internal data, such as proprietary source code.

    • You need to protect system components from being disabled by external attacks or intentional system overloads.

  • Who are you protecting data from?

You need to protect your subscriber’s data from other subscribers, but someone in your organization might need to access that data to manage it. You can analyze your workflows to determine who needs access to the data; for example, a system administrator can manage your system components without needing to access the system data.

  • What will happen if protections on strategic resources fail?

In some cases, a fault in your security scheme is nothing more than an inconvenience. In other cases, a fault might cause great damage to you or your customers. Understanding the security ramifications of each resource will help you protect it properly.

Recommended Deployment Configurations

This section describes recommended deployment configurations for Fleet Management.

Fleet Management can be deployed on a single server or in a cluster of servers. The simplest deployment architecture is the one shown Figure 1-2

This single-computer deployment may be cost effective for small organizations, however, it cannot provide high availability because all components are stored on the same computer. In a single server environment such as the typical installation, the server should be protected behind a firewall.

Figure 1-2 Single Computer Deployment


This figure shows the architecture for single computer deployment

The general architectural recommendation is to use the well-known and generally accepted Internet-Firewall-DMZ-Firewall-Intranet architecture shown in the below figure – Traditional DMZ View.

Figure 1-3 Traditional DMZ View


This figure shows the Traditional DMZ View

The term demilitarized zone (DMZ) refers to a server that is isolated by firewalls from both the Internet and the Intranet, thus forming a buffer between the two. Firewalls separating DMZ zones provide two essential functions:

  • Blocking any traffic types that are known to be illegal

  • Providing intrusion containment, should successful intrusions take over processes or processors

See Appendix A – Fleet Management Port Numbers for more information about Fleet Management network port usage.

Component Security

Operating System Security

Before installing Fleet Management, it is essential that the operating system is updated with the latest security updates.

See below Microsoft TechNet articles for more information about operating system security:

Oracle Database Security

See Oracle Database Security Guide for more information about Oracle Database security requirements.