E-Business Suite security is a huge topic, as there are many different facets to consider. This article will consider a small but essential part of the security model: protecting your APPS user password.

The APPS user in the E-Business Suite is the master of its world. I have gathered together some thoughts on steps you can take and things to consider to help you protect your APPS password from being compromised:

1. Stay current with our latest Security Best Practices

Regularly review the latest version of Best Practices for Securing Oracle E-Business Suite (Note 189367.1). This note is regularly updated and will give security advice covering many different aspects of Applications 11i. For Release 12, see Best Practices For Securing Oracle E-Business Suite Release 12 (Note 403537.1)

2. Regularly change your APPS password

This is an essential activity from a security perspective and needs to be part of your routine operating procedures. Same applies for other schema passwords and SYSADMIN user. As an aside, don't use predicable passwords, or have a system to create passwords, such as using "0ct0ber" for the password in October as this will make it easier to guess

3. Always change passwords as part of a clone process from PROD

It is recomended to change ALL schema passwords and ALL eBiz user passwords in a cloned instance. You can use Removing Credentials from a Cloned EBS Production Database (Note 419475.1) to achieve this. Similarly, you don't want to have any relation in the passwords used for PROD compared to any other instances. Data masking and obfuscation is a large topic in its own right, but is also something you may need to consider doing for the cloned instance to protect sensitive data generally. With Release 12, EM plugin provides some data scrambling facilities

4. Perform data masking on any files sent to outside parties from the PROD system

When you need to send any log files or configuration files, ensure that you scan for any sensitive data before packing the files to be sent. In this article we are concerned about the APPS password, but this applies equally well for other data as well. For example, a crude mechanism would be to use "ed" or "sed" on all files to globally change any occurrences of the APPS password before creating a tar archive to email or upload. You may be uploading files to Oracle Support, or just emailing them within your Organization. Whenever the files are going to someone who cannot access them directly you should always check the files before sending.

5. Create separate schemas with minimal access required for direct database access

If anyone requires direct access to the E-Business Suite database, ensure that you create a new unique schema with the specific permissions required for them to perform their job role. Except for a very few Apps DBAs, there should be no reason that anyone else needs the APPS user password. Sometimes pressures of work make it easier to just give someone APPS access, but this should be resisted and the time taken to provide only the minimum access absolutely required. Every person should also have their own unique login (but this is digressing into a separate area that I'll address in a later article). When considering permissions to allocate, don't be tempted to give read only access to everything, as being able to read sensitive information may be just as damaging as being able to change it.

6. Protect Apps 11i middle tier file system files

These days, there is little need to give anyone UNIX-level access to the servers, but it is still important to ensure the "applmgr" operating system user password is well protected. Also consider whether any of your own startup scripts or monitoring scripts have the APPS password hard coded in them, and protect these scripts with chmod 700 permissions, or remove them if no longer needed

7. Ensure no processes are running with APPS username/password in command line

Generally the APPS password is not listed in "ps" output, but there may be some manual scripts or other processes intermittently running with the APPS password in clear text or trivially encoded. Ensure these scripts are changed to hide the APPS password. In addition, ensure operating system access is restricted to only those who really need it

8. Protect OID access

If you have integrated the E-Business Suite with Oracle Application Server 10g, Single Sign-On, and Oracle Internet Directory, then the Apps user password is stored in the OID database, as it is required for Provisioning to function. The OID administrator and anyone with ldapsearch rights in the Provisioning Profiles will be able to extract the APPS password from OID. This in turn implies the "AppsDN" OID password should be protected in the same way as the APPS password itself. For assistance in security hardening OID, refer to the Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) - Part III Directory Security

9. Encrypt SQLNET traffic from Middle Tier to RDBMS

In a previous article, Steven highlighted that ANO is certified with the E-Business Suite. Use encryption to protect the APPS password from network sniffers tracing SQLNET connection packets and deciphering the APPS password on the wire.

10. Allow only specific IP addresses to access RDBMS via SQLNET

Slightly off topic, but if someone has acquired the APPS password they still have to be able to gain access to a tool that can use it. Restricting the IP addresses that can access your Apps database will help minimise this risk. If you are still using "fat" clients (Discoverer or ADI for example) then you will have to weigh up the risks against the administrative overhead. Oracle recommends upgrading to server-based equivalent tools or shared desktop technologies such as Citrix so desktop clients no longer need direct access. This topic is discussed further in E-Business Suite Recommended Set Up for Client/Server Products (Note 277535.1)

Conclusions

Defence in depth is generally considered the best approach so hopefully these recommendations will give you some food for thought when you are reviewing how well your own system is protected.

Sound password policies are critical to enforce access policies and enforce individual accountability. You need to jealously guard your passwords, particularly for the APPS user.

posted by Jaswinder Singh @ 12:21 AM

0 Comments: