Managing Secure Oracle Applications Environment

In this article, we will be presenting a systematic methodology and best practices for managing a highly secure Oracle E-Business Suite environment.  The attendees will come out understanding how to secure all aspects of the E-Business Suite technology stack.  We will present how to secure the data center, the network, the server, the database, the middleware, and the applications.  We will also present how to run a secure Applications environment from functional perspective from within the applications.

Introduction top

This paper discusses some of the systematic methodologies and best practices used by both AppsHosting and Experian in managing highly secure Oracle E-Business Suite environments.  AppsHosting is a managed hosting provider specializing in Oracle E-Business Suite and other enterprise applications.  In safeguarding sensitive customer data, all operations at AppsHosting revolve around high levels of security.  Experian, known as one of the “big three” consumer credit bureaus in the United States, is a global information solutions company collecting, rating, and providing consumer credit information.  Information security is at the core of both companies. 

According to the online privacy rights advocacy group PrivacyRights.org, over 150 million data records of US residents have been exposed due to data security breaches since 2005 when the group started to keep track.  The cost of such data breaches is hard to measure, yet still very real and high. The costs can be tangible, such as fines and other remediation costs, or intangible, such as diminished consumer confidence and productivity loss.  In the wrong hands, stolen data could be used to conduct fraudulent transactions or be left floating around somewhere waiting to be abused.

With the rapid deployment of network centric applications, security risks have become magnified.  Security threats can come at every layer of information technology (IT) infrastructure - the data center, the network, the operating systems, the databases, the middleware, and the applications.  In essence, the applications and the technology components form a chain link, where a vulnerability in any one of the links can jeopardize the entire application ecosystem.

This paper is intended for those looking to make their Oracle Applications environments more secure.  In particular, this paper focuses on securing all technology components of the Oracle E-Business Suite and the underlying infrastructure. Most (if not all) of the concepts and practices presented here can be used for other applications as well.

Why Secure? top

In this section, we will be covering the reasons why companies need to be committed to securing the application and data.  Companies need to take proactive approach to securing the perimeter and the applications before security attacks are instigated.  In this day and age, companies will suffer greatly for taking reactive approach to information security.

Today,  companies have become increasingly dependent on IT to run their businesses, the need to secure applications has become ever more pressing.  Recently, there has been a much higher awareness of information security, due to several high profile incidents where security breaches have caused harm to many unsuspecting people.  One of the biggest information system breaches occurred on May 22^nd, 2005, when up to 40 million credit card numbers were stolen by hackers according to statements made by the MasterCard International.¹  Data breaches of sensitive and personal information hit home because they can put anyone at risk.

Most publicized security breaches have originated externally, in that the unauthorized access into the information system came from the outside.  The security breach of the card processor for MasterCard came from an unauthorized outsider who “infiltrated” the payment processor network to steal personal and sensitive data.  As seen by the recent wave of data security breaches, companies in all industries, both public and private sector, are targets for security attacks.

Security breaches that originate from the inside pose a serious threat to companies because they come from trusted users.  In its 2005 survey, “The Global State of Information Security,” PricewaterhouseCoopers found that 33 percent of information security attacks originated from internal employees, while 28 percent came from ex-employees and partners.  The terms “delinquents,” “renegades,” and “rogues” are used to describe internal data and security attackers³.  Insider threats can be minimized by analyzing user access requirements and by instituting a proper infrastructure and application security policy.

As the old saying goes, “to err is human.”  There have been many recent high profile cases where personal and confidential information has leaked out due to human error.  According to PrivacyRights.org, in 2006 between 20 to 44% of data breaches were due to human or software incompetence.  It only takes one click of the mouse to inadvertently send sensitive data all over the world.  It also takes a few key strokes to wipe out the entire application and the operating system.  (We wont’be demoing this.)  Since at the center of every information system are humans, the system must be designed and implemented to guard against human mistakes whenever possible.

Oops! Tech error wipes out Alaska info By ANNE SUTTON, Associated Press Writer, Yahoo! News

Tue Mar 20, 10:28 AM ET

JUNEAU, Alaska - Perhaps you know that sinking feeling when a single keystroke accidentally destroys hours of work. Now imagine wiping out a disk drive containing information for an account worth $38 billion.

That's what happened to a computer technician reformatting a disk drive at the Alaska Department of Revenue. While doing routine maintenance work, the technician accidentally deleted applicant information for an oil-funded account — one of Alaska residents' biggest perks — and mistakenly reformatted the backup drive, as well.

There was still hope, until the department discovered its third line of defense, backup tapes, were unreadable.

Financial impacts of security breaches are real as seen in the “2006 Annual Study:  Cost of a Data Breach,” a benchmark study conducted by Ponemon Institute on actual cost incurred by 31 companies that lost confidential data.  According to the study, the total cost of data breach averaged $182 per lost customer record, and the average total cost per company was $4.8 million per breach and ranged from $226,000 to $22 million.⁴  Consumer data broker ChoicePoint, Inc., which last year acknowledged that the personal financial records of more than 163,000 consumers in its database had been compromised, will pay $10 million in civil penalties and $5 million in consumer redress to settle Federal Trade Commission charges that its security and record-handling procedures violated consumers’ privacy rights and federal laws.⁵

TJX breach could cost company $1B
InfoWorld.com, April 12, 2007

How much will it cost to clean up the mess caused by TJX Company's loss of financial records on 45 million customers? What would you think if I told you it would cost, in the words of Dr. Evil, $1 million dollars?!!!!? Not too bad? *Ahem* Sorry. How about $1 billion dollars?!!?! Now that's more like it! And that's the number that security industry analysts are bandying about in today's Boston Globe. How'd they get to the $1B figure? Well, it's all pretty fishy, but the formula looks something like this: (cost_per_lost_record x (number_of_lost_records) + cost_of_IT_cleanup = total_cost_of_breach.

Not surprisingly, there are a lot of caveats with at least one expert, Larry Ponemon of the Ponemon Institute, putting the figure in the hundreds of millions of dollars, and a Forrester analyst, Khalid Kark, putting it as high as $1.35 billion.

Forrester's number comes from that firm's estimate of a cost per lost record of $90 and an estimate that around 15 million of the 45 million stolen credit records were for unexpired debit and credit cards.

Curiously, Ponemon estimates that the cost to replace stolen records is a lot higher -- $182 per card, but that no company who has experienced a data loss has spent more than $22 million to recover from it. Given that other companies have experienced similar sized breaches -- ChoicePoint, CardSystems -- it's hard to see how $22 million could be the ceiling, but that's what the article says.

Other cleanup costs -- computer forensics and new consulting fees, better intrusion detection products....a database firewall anyone -- are just the cost of doing business and would be no more or less had a breach not occurred (translation: "they need this stuff anyway, so who cares why they're buying it?")

Besides, the costs to the company would be amortized over one or two years -- or more, depending on the outcome of lawsuits filed against TJX and the aftermath of the breach (in other words, how many consumers are victims of ID theft that can be traced back to TJX).

So, if security analysts are bearish on TJX, Wall Street certainly isn't. As the Globe story points out, the company's stock is trading within five or ten percent of where it was the day before news of the leak was disclosed.

Add it all up, and you've got to ask: "Is there really a price to pay for violating your customers' privacy?"

Data and security breaches have been receiving increased awareness from the public and law makers are following suit.  California state legislators took early lead in security and disclosure laws since then other state statutes have proliferated.  California was the first in enacting legislations that protect the residents and making companies protect personal and confidential data.  The Senate Bill No. 1386 ("SB 1386") requires any company that stores customer data electronically to notify its California customers of a security breach to the company's computer system if the company knows or reasonably believes that unencrypted information about the customer has been stolen. The Senate Bill No. 1 ("SB 1") commonly known as the California Financial Information Privacy Act, creates new limits on the ability of financial institutions to share nonpublic personal information about their clients with affiliates and third parties.⁶

To get to the point, all companies need to have the infrastructure, policies, and procedures, to secure their applications.  It will take effort and cultural change to build such an environment, but the cost of not securing is far greater.  It does pay in the long run to have secure application environments.

Chronology of Data Breaches 2006: Analysis

(PrivacyRights.org, February 2, 2007)

Design a Secure Architecture top

A secure application environment starts with a secure architecture.  The security of the overall infrastructure must be embedded into the application environment design and implementation.  It cannot be an afterthought!  Each technology component of the application environment must be segregated at each layer.  At the broadest level, the network must separate each application environment and each technology layer.  The server must also be hardened from a security perspective.

For Internet facing applications or any other externally facing applications, secure proxies must be used to protect the internal network and application environment.  No customer or sensitive data should reside in any areas exposed directly to the Internet.  To further protect sensitive data and ensure integrity, Secure Socket Layer (SSL) protocol and certificates can be used.  Single Sign-On (SSO) and Identity Management (IM) infrastructure can enhance application security and reduce the risk of password compromise.

Two factor authentication can be used to virtually eliminate password compromise. A secure architecture is achieved by designing security into all components of the application infrastructure, i.e. the network, the server, the database, and the applications.

Secure Infrastructure top

Data Center

A secure data center is the backbone of a successful IT security policy.  A secure data center requires various physical devices and operational procedures to be in place, allowing for controlled access, logging, monitoring, and accountability.  Employee background screening should be a routine part of the hiring process.  Obtaining Statement on Auditing Standard 70 (SAS70) certification for the data center is one of the better ways to ensure that high levels of internal controls and security procedures have been implemented and verified.  For many public companies especially those that deal with sensitive data, SAS70 certification is usually a requirement.

Physical security in the data center will typically consist of the following:

• Controlled access to data center (using key cards, biometric readers, and other devices)
• Controlled access to servers, storage, and networking devices
• Controlled access to back up media
• Round-the-clock staffing in the data center
• Active monitoring using video camera
• Logging and monitoring of all activity within the data center

Devices

Physical controls must be in place to secure devices. Device access includes access to consoles, access to internal disk drives and other device components, and access to the device as a whole. These controls can include controlled access to cabinets, cages, locked faceplates, etc. and are aimed at preventing the tampering of, removal or physical access to devices.   Access to tape backup media must also be controlled.

Network

Networks are passage ways, comprised of bidirectional traffic, that lead to company data.  Network access control (NAC) In a perfect world, establishing a secure network policy is absolutely simple. Simply block all traffic traveling in both directions. Unfortunately, this is usually not an option!  So we must come up with workarounds.  Fortunately, it is possible for a company to implement a secure network policy, using established procedures and protocols.

Network access requirements

The development of a company network security policy begins with clearly defined access requirements.  Access requirements generally center around company applications and servers that host the applications. These requirements specify which applications and servers need to be accessed by whom (from a networking perspective), and must contain detailed criteria.

Network zones

The next step involves the partitioning of the company network into various zones and subzones. Zones allow for segregation and control of traffic. Access controls should be set up between zones, only allowing essential traffic to flow between zones, in accordance with the access requirements that were documented earlier.  Zones (if implemented properly) can minimize exposure to risks associated with untrusted traffic, and also help to quarantine areas that have been compromised.

Inbound access control

Using perimeter firewalls and routers, inbound network access should be controlled. 

For the most part, inbound access to internal zones should be disallowed.

Exceptions would include the following:

• Access to Internet facing services. Examples include external access to Web sites, Web applications, FTP sites, etc.
• Remote user access. Examples include access to company applications for employees, external vendors, contractors etc. via virtual private networks.
• Remote location access. Examples include satellite offices, external vendors, international offices etc. connected with site to site VPN tunnels, or dedicated site to site network circuits.

TCP stateful packet inspection should be implemented for open ports at the firewall level. Packet filtering helps to control malformed packets, which can be used for DOS (denial of service) attacks, as well as to exploit vulnerabilities in various application services. Other applications that can be implemented include intrusion detection services, packet sniffing etc.

Outbound access control

Similar to inbound access restrictions, outbound network access must also be controlled.  Direct outbound network access should never be allowed, as even a single outbound open port can be used to set up malicious forward and reverse proxies, compromising the entire corporate network.  This can be done intentionally (i.e. by current and former employees/contractors) or unintentionally (i.e. by spyware, viruses etc.).

All outbound access should be permitted only via outbound proxies. Proxy servers can be implemented for various TCP protocols, and can be set up for employee web surfing, outbound FTP access, instant messaging, etc.  Proxy servers allow for access control, logging, monitoring etc. and can also provide performance benefits.

Operating system

The benefits of a secure operating system cannot be understated. In the absence of high security levels in other areas of IT infrastructure, it is still possible to maintain a reasonable level of security if the operating system is locked down well.  The first step in securing the operating system involves keeping up to date with vendor recommended security patches. This goes hand-in-hand with being aware of operating system vulnerabilities as they become published.

Disable unnecessary processes

An inventory should be taken of all active processes to figure out which processes are absolutely required. Once this is done, unnecessary processes should be disabled. Every service/process that runs on an operating system poses a security risk. Most operating systems have unnecessary processes enabled by default.  This risk is magnified when a process runs under a privileged user account. For this reason, any processes that run under a privileged user account such as root, should be modified to run under a different user account. Sometimes, this is not possible because the process will need certain permissions that are only available to a privileged user account.

Disable unnecessary network ports and network services

All unused and unnecessary network ports should be disabled via the Unix ‘/etc/services’ file or the Windows ‘C:\WINDOWS\system32\drivers\etc\services’ file. As with active processes, open ports also pose a security risk.  Unnecessary network services such as Telnet and FTP should be disabled (using inetd.conf in Unix or ‘Services’ Microsoft Management Console (MMC) in Windows.  Access controls should be put in place for TCP services, Using the ‘tcpwrappers’ tool (This can also be done via the operating system firewall).

Monitor file system integrity

Being the heart of the operating system, the filesystem contains critical files necessary for the sane operation of a server. The filesystem contains user data, authorization information, configuration information, etc., and is a common target for compromising systems. It is important to ensure that a rogue process does not replace files with malicious versions. There are many applications that can be used for checking  file system integrity, including Tripwire, Aide, Integrit, etc.

Maintain secure permissions and ownerships

File system permissions dictate the level of access that each system user has to a particular file or directory. Thus it is important to protect files that contain sensitive information, by using appropriate filesystem permissions. In addition, no files should have universal write access (i.e. 777 or 666).  This is especially true of data files which contain sensitive data.  Scripts should be run periodically to detect insecure permissions and ownerships.

Secure the server console

The server console, whether keyboard and display or a serial/Lights Out Management (LOM) console, should be protected.  In the case of a serial or LOM console, the connections should be encrypted and protected using access control lists. 

Encryption of inbound and outbound network connections

Inbound network connections to the server such as login sessions and connections from external interfaces should be encrypted. SSH or similar mechanism should be used for user logins, while SCP or similar mechanism should be used for file transfer purposes.  The SSH server on the operating system should be configured such that port forwarding is disabled and private keys are secured. If SecurID or another form of two factor authentication is in place, private keys should be disabled, as two factor authentication can be bypassed using private key authentication.  Outbound network connections should also be encrypted, such as interfaces with other servers.

Two factor authentication

Two factor authentication refers to when more than one authentication are used for log-in using SecurID or another method. Two factor authentication virtually eliminates the risk of password compromise, and reduces the need for scheduled password changes. There is also another important problem that is solved by requiring two factor authentication: multiple users will not be able to login using a single user account.

Operating system firewall

Although a server may reside within a trusted network zone, a perimeter operating system firewall is invaluable. Operating system firewalls can minimize or eliminate risks posed by compromised servers within a network zone. They can also be used to control access for inbound and outbound network connections.

Password policy

If a traditional password authentication mechanism is used to log into a server, it is important to maintain and enforce a password complexity and a password change policy.  Password complexity checkers may be done on a periodic basis to weed out weak passwords ( ‘John the Ripper’ is an example of such a tool).  The OS password management can be integrated into company wide single sign-on environment to reduce password exposure.

Auditing

The operating system should be configured such that adequate logging is taking place. This is done via syslog configuration.  In addition to adequate logging, it is also important to monitor log files on a regular basis.  If an abnormal event is detected, an efficient incident management protocol should be in place to notify appropriate personnel.

Secure Database top

Oracle as a company prides itself on having the most secure database in the market, reportedly having gone through 20 or so third-party security evaluations.  Companies can advantage of the security features of Oracle by setting up the database properly with security in mind.  The first step in securing the database is to lock down default Oracle accounts as the passwords for them are widely circulated.  Change the default passwords immediately when the database is created and also on a scheduled basis going forward.  For unused schemas, lock the account or revoke CREATE SESSION and/or CONNECT role.  Keep track of the database accounts and either disable or remove unused or unneeded accounts.

Create password profiles to enforce password security using the following:

Even though the network itself can be secured through the firewalls, the network traffic in and out of the database is not secure by default.  Anyone can put a packet sniffer on a machine that connects to the database and capture all the sensitive data that goes in and out of the database.  The encryption of the database traffic over the network is done by the Advanced Networking Option (ANO) that is part of the Advanced Security Option (ASO) and requires Oracle Applications 11.5.10 with Technology (ATG) RUP3 or later running Forms Listener Servlet.

Encryption of SQL*Net traffic is done by setting the following parameters in SQLNET.ORA:

The corresponding directives for JDBC drivers used in self-service Applications modules are made in jserv.properties:

The listener is critical to the database as it handles the user connection into the database.  One great way to secure the database listener is to set up encrypted password by using LSNRCTL utility:

Review the generated listener configuration file to make sure the encrypted password was generated as in the example below

Starting with 10g, local OS authentication is enabled by default allowing the user who started the listener to administer fully without providing a valid password.  With local OS authentication enabled, some say 10g listener is secure out of the box.  Still, the following parameter can be set to force the listener password to be entered for administration:

Additionally, enable admin restrictions by setting to avoid listener settings from being modified through lsnrctl commands.

One sure way to shield the database from unwanted users is by setting up valid node checking.  The configuration can again be completed using the Oracle Net Manager. The settings are placed in the SQLNET.ORA file. For example, the following configuration will only allow a network connection from a single computer with the IP address of 192.168.1.2:

The strategy for securing the Oracle environment should include auditing of the database for intrusion detection.  Database auditing can thwart and/or detect unauthorized access or misuse of data.  Auditing the database can be done by any combination of audit commands, system and object triggers, and fine-grained auditing.

In order to avoid performance problems and useless clutter, only pertinent actions should be audited.  If the default SYS.AUD$ is used to hold the audit data, then the growth of audit table must be carefully monitored to avoid space problems.  If auditing is done to the file system, one should protect the audit file designated by AUDIT_FILE_DEST parameter.  

Auditing database sessions helps to identify suspicious connections to highly privileged schemas (audit session).  Auditing schemas and user changes help detect malicious or inappropriate changes (audit user; audit create user; audit alter user; audit drop user).  Three other important auditing events for Oracle Applications include create database link, alter system, and system audit and are set by the following commands:

For those who are willing to put in more time and effort on security, Oracle offers optional products that will make the database even more secure.   Starting with 10g Release 2 Enterprise Edition, Oracle Database Vault option is available to companies to protect against internal threats from privileged users like the database administrators. Oracle Label Security (OLS) which is available for Oracle 9i and higher offers a way to implement very granular level of security down to specific data records.  Also, available for Oracle 9i and higher is the Oracle Secure Backup option which can be used to encrypt and back up the data to the tape storage device.  The database can be integrated with Oracle Internet Directory for centralized user and password management.

Secure Middleware top

The middleware refers to the application server component of Oracle E-Business Suite, specifically Internet Application Server (iAS).  As a critical component of the Oracle E-Business Suite, the middle-tier application servers need to be safeguarded.  The middleware servers are made more secure by enabling Secure Socket Layer (SSL) protocol.  The SSL protocol can be configured at reverse proxy, Apache web server and/or the Forms server level.  SSL-enabled applications communicate via encrypted protocol and are accessed by HTTPS mode instead of HTTP.

In E-Business Suite environment, Oracle Application Serve can be configured for SSL by using AutoConfig utility and then performing additional tasks for the secure certificates.  The following SSL parameters need to be set in the context file (<ORACLE_SID>_<server>.xml) for Applications:

After AutoConfig is done, the httpd.conf for the AS needs to be reviewed and SSL changes need to be made before starting up the middle tier services.  In particular, if the certificate chain is not used, then SSLCertificateChainFile needs to be commented out.  Additionally, the Certificate Authority verification path for client authentication needs to be set to point to ca-bundle.crt file.

With Internet-facing applications, a combination of network segregation and reverse proxy should be configured in order to protect the internal applications server and database from outside exposure.  Reverse proxy is used to secure the applications server by hiding the physical address of the server.  A separate external applications tier should be configured to service the external users accessing Oracle E-Business Suite.  The external app server must be tightly controlled and restricted to minimize the risk to the database.  Each tier in Figure 1 must be segregated by firewalls for enhanced security.

Figure 1 - Externally Facing Oracle E-Business Suite Architecture

Figure 1 above shows an Oracle E-Business Suite architecture where Oracle Forms Servlet is enabled so that complete applications environment can be run on SSL with just Apache SSL certificates.  The benefits of such architecture are easy of management and cost savings derived from not having to maintain a separate Forms Wallet certificate.  Figure 1 also shows a more flexible architecture where the external Applications server cluster can be used to service external users through the reverse proxy or to connect with third-party services through secure connection.

Oracle Single Sign-On (SSO) configuration makes the application environments more secure by centralizing password management and minimizing password exposure.  With SSO in place, users only have to authenticate once, and the log-in information is carried through other partner applications.  SSO with SSL is most secure due to reduction in password exposure and added encryption.  Single sign-on enables the sharing of  user authentication across the enterprise by linking the user accounts in the different directories through a common user definition called Globally Unique Identifier (GUID).  Oracle uses the Lightweight Directory Access Protocol (LDAP) directory known as Oracle Internet Directory (OID) as the repository for user information.

Figure 2 - Single Sign-On Architecture

When users log in to SSO enabled Oracle Applications, they are automatically directed to the SSO login page to get authenticated.  Once successfully authenticated, the users are redirected back to the Applications with “security cookie” to proceed on.  From this point forward, the user can log in to any “partner” application without having to re-enter the password.  By configuring Oracle Applications and Oracle Internet Directory as “provisioning integrated applications,” the changes from either system are provisioned (sent) to the other as set up by the “provisioning profiles.”   The provisioning profiles specify what user events are provisioned, the direction of provisioning, and the user attributes involved. ⁸

The password policies must be reviewed to ensure that passwords are propagated properly during provisioning.  The passwords in OID are case sensitive where as the passwords in Applications are case insensitive by default but can be set to be case sensitive.  Case insensitive Applications passwords become lower case passwords in OID.  The timeout settings must also be reviewed to ensure seamless user experience.  If the Application session times before Single Sign-On session, then the session user is directed to the SSO page then back to the Applications page maintaining the active SSO authentication.  If both Applications and SSO pages timed out, then the user needs to re-authenticate before continuing with the Applications.  One thing to remember is that the Applications timeout settings take precedence over the SSO timeout settings such that user will be able to log on to other partner applications without having to re-authenticate even after the SSO session has timed but the Applications session has not.

Oracle Single Sign-On can be integrated with other authentication systems such as Microsoft Windows (Windows Native Authentication/Kerberos) or Sun ONE Identity Server.  Oracle’s LDAP directory OID can be integrated with other LDAP-compliant directories such as Microsoft Active Directory or Entrust Critical Path Directory Server.  Even with other third-party authentication solutions or LDAP servers in place, Oracle E-Business Suite still requires Oracle SSO server and OID to act as a bridge.

Secure Applications top

One of the first steps in securing the Applications is to tighten the access into the Applications.  Change the SYSADMIN and other default account passwords (AUTOINSTALL, ANONYMOUS, CONCURRENT, MANAGER, APPSMGR, FEEDER SYSTEM, INITIAL SETUP).  Make sure GUEST user has no responsibility.  Review all seeded and new user accounts, and disable any unused or obsolete accounts.  Minimize the use of shared accounts, but balance that out with the need to have a dedicated account that  owns scheduled jobs.  Regularly change the passwords for privileged accounts to protect against password compromise.

Oracle E-Business Suite is a complex application made up of multiple products and technology stacks.   For Applications administrators, one of the first steps to take in making the Applications more secure is to set the security profiles.  The following are recommended profile options to enhance security:

The following standard reports are used to view the audit data:

Starting with 11.5.10, Oracle has implemented a new user access control model called Role Based Access Control (RBAC) based on American National Standards Institute standard (ANSI INCITS 359-2004) supported by National Institute of Standards and Technology (NIST).  RBAC maps the user access control to the role or job function the user performs rather than the user’s identity.  By doing so, RBAC streamlines the user administration process and security policy enforcement.  By using role inheritance, roles can be used to consolidate responsibilities as well as enforce lower level permissions and data security policies with just a one-time setup.¹⁰

Role vs. Responsibility

The credit card encryption feature of Oracle E-Business Suite offers a way to protect sensitive credit card information.  Using the feature also assists with compliance with the cardholder data protection requirements of the Payment Card Industry (PCI) Data Security Standard, and the Visa's Cardholder Information Security Program (CISP). The Visa program is based on the PCI Data Security Standard. When the feature is enabled, credit card numbers for external third-party payers, such as customers or students, are encrypted.  One limitation currently is that any internal credit card numbers, such as company-owned or employee credit cards, are not impacted by the Credit Card Encryption feature.¹¹

Applications specific data auditing can be done using Audit Trail feature of E-Business Suite.  Be selective on what data to audit making sure to avoid auditing high volume transaction tables and regularly purge audit tables after disabling audit trail.

To enable Audit Trail, follow these steps¹²:

Protect the workstation and browser by keeping up-to-date with the latest security patches from the respective vendor companies.  Ensure the browser security settings are set properly to enable the download of JInitiator and forms to open up properly.  Add the application servers to the Trusted Site zone on the browser.  Make sure you are using certified version of the workstation operating system and browser to ensure compatibility with Oracle JInitiator¹³.

More Best Practices top

In addition to the specific best practices that were covered in this paper, there are some other practices which will ensure that the applications and infrastructure are even more robust and secure.  After securing the environment and setting up auditing, round-the-clock monitoring and notification should be in place to address component failures or security breaches.  In addition to running scanners during the initial rollout of the application, Intrusion Detection Systems (IDS) should be put in place to constantly monitor the inbound and outbound network packets in real time.  Host-Based Intrusion Prevention Systems (HIPS) can be used for perimeter protection.  Oracle Enterprise Manager or Grid Control along with custom scripts can be implemented for proactive monitoring of running services.

To minimize unauthorized data access from the inside, companies should scramble sensitive data in development environments since developers have full access to these environments.  Custom scramble scripts or third-party tools can be used.  Balance out the need to scramble with ensuring the Applications function properly.  For example, scrambling the employee data can make the employee hierarchy difficult, if not impossible, to use.

Security diagnostic tools such as COPS, crack, and tcpd can be used to validate and report on the performance of implemented security measures.  Companies should also conduct regular audits by various groups.  The systems group should conduct self-audits, while the IT security group should conduct internal audits. Outside firms can be brought in to perform full external audits.

Companies should have a process in place to evaluate and apply quarterly Critical Patch Updates (CPU) from Oracle.  The CPU patches fix security bugs in the applications technology stack and are needed to maintain a secure environment.  Applying the CPU patches should be done in addition to keeping up to date with security patches for other technology components.   Although it is common knowledge, companies should ensure that good backups are taken in case a restore is required for any reason.  (Check out the $23 billion mishap).  Companies should also conduct regular restore exercises to ensure the integrity of backups.

Securing applications should be considered an ongoing work. Adhering to the recommendations presented in this white paper will provide the essentials required to secure the applications. Security threats arise daily, and security measures must constantly be reevaluated to ensure that all components of the Applications environment are protected.

References

1. Credit card breach exposes 40 million accounts, Joris Evers  Staff Writer (CNET News.com), June 17, 2005
2. A Chronology of Data Breaches (http://www.privacyrights.org/ar/ChronDataBreaches.htm)
3. Coping With Insider Threats, Melisa Bleasdale, May 9, 2006
4. 2006 Annual Study: Cost of a Data Breach, Ponemon Institute
5. ChoicePoint Settles Data Security Breach Charges; to Pay $10 Million in Civil Penalties, $5 Million for Consumer Redress (http://www.ftc.gov/opa/2006/01/choicepoint.htm), January 26, 2006
6. California Raises the Bar on Data Security and Privacy, James F. Brelsford (http://library.findlaw.com/2003/Sep/30/133060.html)
7. Encrypting EBS 11i Network Traffic using Advanced Security Option/Advanced Networking Option (Metalink Note:391248.1, February 23, 2007)
8. Integrating Oracle E-Business Suite Release 11i with Oracle Internet Directory and Oracle Single Sign-On
9. How to implement (Signon Password Custom) Profile Option in Oracle Applications 11i (Metalink Note 362663.1)
10. Oracle User Management FAQ (Metalink Note:290525.1, 09-AUG-2006)
11. Oracle Applications Credit Card Encryption (Metalink Note 338756.1, 12-DEC-2006)
12. Best Practices for Securing E-Business Suite (Metalink Note 189367.1, 15-NOV-2006)
13. Recommended Browsers for Oracle Applications 11i (Metalink Note 285218.1, 28-DEC-2006)