The APPS schema and its importance
IT Security does not sufficiently understand Oracle E-Business Suite’s highly privileged accounts. As a result, apart from ensuring the account does not have a default password, these accounts generally do not receive sufficient security checks
The APPS schema has access to the complete Oracle E-Business Suite data model. This model is analogous to the SYSTEM schema, which has access to the entire database.
Poor governance of this account can lead to a complete compromise of your security posture. Attackers can bypass security hardening and procedures when they receive the account credentials, which allows them to directly access sensitive data and take control of the Oracle E-Business Suite system.
If the APPS schema has not been sufficiently controlled or shared with unauthorized personnel, your Oracle E-Business Suite could be compromised in several ways, including:
- An account-takeover attack could decrypt ALL application passwords.
- A data breach via access to sensitive data could compromise compliance, such as GPDR.
- A denial of service via service shutdown.
- An ability to run diagnostics.
- An escalation of privileges via the ability to run User and Responsibility create/update/delete APIs.
- An ability to make changes to any code and manipulate product tables.
Implications for compliance
Oracle E-Business Suite has hundreds of modules that can be licensed and, depending on licensing, can hold sensitive data, such as:
- Customer credit card information.
- Personal data of employees, customers, and vendors (name, address, social security details, bank account number, etc.).
- Protected healthcare information.
Thus, a security breach would mean the compromise of such compliance as:
- PCI Compliance for Credit Card Security.
- Sarbanes-Oxley (SOX).
- Health Insurance Portability and Accountability Act (HIPAA).
- European Union Data Protection Directive (GPDR).
- Gramm-Leach-Bliley Act (GLBA).
- Electronic Protected Health Information (ePHI).
Where is the risk?
Because the APPS schema is fundamental for the Oracle E-Business Suite to work — and as per the security guide, documentation should not be altered in any way — removal of grants or roles could result in the application functionality being broken. This means the account is not applicable to the principle of least privilege.
Also, while best practices for database password management recommend locking an account after X number of failed logins, and then forcing password resets to protect the account, APPS blocks this security measure. As a key account in the Oracle E-Business Suite login process, locking the account arbitrarily would mean application denial of service.
This lack of security puts APPS at risk in the following ways:
- The APPS password is often not changed sufficiently and can become known to attackers over time.
- The APPS password is generally not reset in cloned environments, where the sensitive data has not been scrambled — meaning, the attack vector is often not just the production system.
- Where standard encryption is configured, the APPS password is susceptible to a well-known decryption flaw, allowing attackers to obtain the APPS password and, by extension, any application user password.
- The security vulnerabilities of the APPS schema are just as prevalent as an internal threat. Thus, security implementations, such as network and perimeter security, do not mitigate attacks. Internal threats originate within the organization and are usually carried out by a current or former employee, contractor, business associate, etc. Insider attacks can be malicious or inadvertent.
- Implementing APPS password security is generally the jurisdiction of Oracle E-Business Suite administrators. Thus, security teams often realize an account has been compromised too late.
How to mitigate risk
To ensure the APPS schema is both compliant and protected against compromise, the following list of critical administration-level tasks can be performed to protect the integrity of the APPS password. This list is not exclusive; further defense-in-depth techniques/hardening should also be used.
- Implement EBS Hash password to protect against a well-known APPS password decryption compromise.
- Change the APPS password during cloning.
- For Oracle E-Business Suite 11i, ensure that the hard-coded APPS password in the configuration files have locked-down permissions.
- Harden the GUEST password.
- Recreate Database Links (APPS_TO_APPS) during cloning.
- Avoid Displaying APPS password in custom programs.
- Audit database connections, checking that APPS password is only used for known connections. (Implement SQLNet access to prevent direct database access with APPS schema.)
- Protect Tables with APPS password information.
- Configure the concurrent manager to “start/stop” without the APPS password.
Do you know if your organization is taking advantage of these techniques to harden your Oracle E-Business Suite system? Spinnaker Support checks for this type of setup (and many others) during the Vulnerability Assessment we perform for new clients. We also offer ongoing Oracle EBS Support to ensure your Oracle E-Business Suite has the best security posture.
For more information, please visit https://www.spinnakersupport.com/third-party-support/security-vulnerability/