This chapter provides information on these topics:
Figure 1-1 illustrates the physical deployment model of the AIP application:
Figure 1-2 illustrates the deployment of the AIP application on the Oracle platform:
The AIP Servers and database are expected to be deployed in a corporate data center environment, with computer and physical access restricted to the machines. Data is imported into the application databases through batch processes from data files. The application secures the batch import process, but assumes the import data files are from a trusted source. It is the retailer's responsibility to ensure the integrity of the import data files and to secure access to the import files on the servers.
The AIP application is not designed to run over the public internet, but is expected to run within a private network. Ensure that the server systems running the database and application server and the client systems are located within a secured corporate network.
Corporate users accessing the system will use a Web browser on Microsoft Windows. Refer to the Oracle Retail Advanced Inventory Planning Installation Guide for supported versions. The retailer is responsible for applying the necessary security patches to the Web browser, operating system, and Java Runtime Environment.
The typical configuration of the AIP application runs on multiple servers: one for the Oracle WebLogic Server 11g Release 1 (10.3.6), one for the Oracle Retail Predictive Application Server, and one for the Oracle database. The WebLogic Server is used to host the Data Management and Order Management applications as well as the RPAS Fusion Client. The retailer is responsible for applying any critical patch updates released for the server hardware, application servers, and database.
For information on Oracle Retail Security Guides, including those related to RPAS and Oracle Retail integration technologies, see the following:
http://www.oracle.com/technetwork/documentation/oracle-retail-100266.html
This section provides information on these topics:
For both Data Management and Order Management there are user name and password controlled access to the applications. Security rights for each user is defined at a user level and administrated in a central screen. There are data access restrictions in both applications based on assigned rights to merchandise classes. There are screen level access restrictions based on assigned privileges.
The parameters of login functionality include:
System access is restricted by a User ID/Password login.
The password can be updated by the user through the ”Change Password” page.
There are standard and administrator users. Standard users are business users, while administration users assign rights and administrate user accounts.
General user administration, other than password changes, is restricted to the enterprise administrator user level only.
The administrator may perform creation of user accounts, password administration, and access rights administration, as well as locking, unlocking and removal of user accounts.
Password expiration and failed login lockout are available to be set and administrated by the admin user.
Only application areas the user has rights are made available upon login
User account information must at minimum include the following:
User ID
Password
User type
Phone
Country
Location
Language
User login is audited, including time and day of logging in. Refer to the section, Audit, for more details.
User details are stored in the ENT_USERS table.
It is recommended to use database level auditing of DML statements on the ENT_USERS table. See the chapter ”Configuring and Administering Auditing” in the Oracle Database Security Guide.
The parameters of merchandize data filtering functionality include:
Merchandise classes are automatically be added and deleted from the assignment list upon changes in the class definitions in the database.
The administrator can assign class access rights to users.
Data in the following categories will be restricted by the classes assigned to the user:
SKU
SKU Pack-size
Demand Group
Class
Data for classes not assigned to the user will not display in the listed drop-downs and List of Values (LOV).
Users should be set up to receiving the minimum data privileges necessary.
The parameters of screen level access functionality include:
Application access may be controlled at the tab level by the system administrator for each user account.
All fields in the screens of inaccessible tabs are disabled, and an alert message displays indicating that this area is not accessible for the user.
Note: This alert message will not display if the tab is the default selection in a selected area. |
User/class relationships are stored in the DEPARTMENT_SCOPE table.
Users should be set up to receive access only to the screens required for their role.
The assignment of screen and class-level permissions are done on a per user, per security permission basis. This means that adding a new user requires a detailed list of what screens they'll need to access and what Classes are necessary.
User role functionality is available in order to provide a method of mass assignment and mass maintenance. A user role may be associated with a particular screen, or set of screen privileges. This role can then be assigned to a user, thus granting the user permission to all screens assigned to the role.
The role is assigned to a user in the standard user permissions screen. All roles are prefaced with a type of role security indicator. The role is selected from the list of all available security types and saved to the user.
After the assignment of a role to users the administrator can grant additional screen access, or remove access from a particular role. The change will automatically be reflected in all user permissions assigned to the modified role.
It is important to note that the user roles only contain screen access permissions. They do not include Class permissions.
While the user roles are a tool to aid in assignment and maintenance of user permissions, individual screens may be assigned to a user on a screen-by-screen, user-by-user basis, as desired.
For more information, refer to the Oracle Retail Advanced Inventory Planning Administration Guide.
AIP does not contain any default accounts, user IDs, or passwords. An administration user account is created during the database installation process. The username and password of this administrator are chosen during installation. For more information, refer to the Oracle Retail Advanced Inventory Planning Installation Guide.
AIP protects authentication passwords. There are no clear-text passwords available in the application.
User passwords for Data Management and Order Management are stored in the Oracle database in the ENT_USERS table. Passwords are iteratively hashed using the SHA-1 secure hash algorithm with a salt before being inserted into the database.
Password policy settings are configured through a properties file (security.properties). Password policies are secure by default and it is not recommended to ease these restrictions. To prevent unauthorized changes to the password properties it is recommended to maintain strict file permissions (0600) on the properties file.
The default password policy includes the following restrictions:
Minimum of six (6) characters and a maximum of 128.
Minimum of five (5) different characters.
May not be simple.
For example, sequences (ABCDE or ABCXYZ) and may not contain more than four consecutive characters as this will result in ”pairing” (ABCDEF results in (5) pairs AB, BC, CD, DE, EF)
May not be easily derivable from user name or full name.
May not be derivable from a dictionary entry (the dictionary is configurable).
It is case sensitive.
Passwords expire after 60 days.
Accounts are locked after three (3) incorrect password entries.
For more information on setting up and maintaining password policies, see the Password Restrictions section in the Oracle Retail Advanced Inventory Planning Administration Guide.
Security changes and session activity are recorded in an audit table in the Oracle database. Table 1-1 shows the events included in the audit table
Table 1-1 Audit Events
Event Type | Event | Event ID |
---|---|---|
Login |
login |
1 |
Login |
logout |
2 |
Login |
badLogin |
3 |
Login |
passwordExpired |
4 |
Login |
loginTemporaryLock |
5 |
Login |
loginPermanentLock |
6 |
Updates |
userCreated |
50 |
Updates |
passwordChangedByUser |
51 |
Updates |
passwordChangedByAdmin |
52 |
Updates |
accountTemporaryLock |
53 |
Updates |
accountPermanentLock |
54 |
Updates |
accountLockCleared |
55 |
Admin Events |
adminLogin |
100 |
Admin Events |
adminLogout |
101 |
Admin Events |
adminBadLogin |
102 |
Admin Events |
adminCreated |
150 |
Admin Events |
adminPasswordChanged |
151 |
Audit events are stored in the ENT_AUDIT table. Details stored in the table include the user id and timestamp of the event, as well as an event-specific details field. It is recommended to limit access to this table to system administrators. The audit table should also be reviewed on an ongoing basis for irregularities.
For more information on auditing, refer to the Oracle Retail Advanced Inventory Planning Administration Guide.
AIP receives data from external systems in flat file format. Flat files are also used for integration internally in AIP between the Oracle and RPAS platforms.
Access to data flat files should be restricted to the user accounts that run AIP batch processes. It is recommended to use FTP over SLL to move data files securely over the network.
External systems for AIP can include:
Oracle Retail Demand Forecasting (RDF) supplies a demand forecast.
Oracle Retail Merchandising System (RMS) provides hierarchy data such as SKUs, stores, and warehouses, as well as measure data such as current inventory, in-transits, on-orders, product supplier links.
Oracle Retail Replenishment Optimization (RO) which provides optimized replenishment methods and parameters.
For more information on AIP interfaces, refer to the chapter AIP Integration in the Oracle Retail Advanced Inventory Planning Operations Guide.
The AIP application uses a number of security tools to scan for security issues. This includes tools such as WebInspect and an internal fuzzing tool to test SQL security.
Retailers and system integrators who are customizing or extending any of the applications should consider running the following or similar tools on their customizations and extensions. As with any tool, the output of these tools should be analyzed in detail since the output may contain false positive warnings.
Fortify 360 is a tool that analyzes software for vulnerabilities. The static analysis component examines an application's source code for potentially exploitable vulnerabilities. The dynamic analysis component identifies vulnerabilities that can be found only when an application is running. All vulnerabilities can be ranked according to their PCI relevance.
Fortify is found at the following Web site: