security 3

SSeeccuurriinngg OOrraaccllee EE--BBuussiinneessss SSuuiittee ffoorr IInntteerrnneett AAcccceessss bbyy SSuupppplliieerrss

An Oracle White Paper January 2003

Securing Oracle E-Business Suite for Internet Access by Suppliers Page 2

SSeeccuurriinngg OOrraaccllee EE--BBuussiinneessss SSuuiittee ffoorr IInntteerrnneett AAcccceessss bbyy SSuupppplliieerrss

OOVVEERRVVIIEEWW

E-Business applications have driven enormous cost savings over the years as more and more business processes have been put online, driving out costly manual interventions and re-keying of data. Traditionally this automation trend has been confined within the walls of a single enterprise, but many leading companies have begun leveraging the Internet to automate processes involving collaboration with suppliers. Oracle Supplier Relationship Management applications such as iSupplier Portal, Sourcing and Collaborative Planning are pioneering this expanded opportunity for cost savings throughout the supply chain.

To make SRM applications work involves providing your suppliers with network access to parts of your e-Business Suite implementation. The pure Internet architecture of the e-Business Suite means that you can do so very inexpensively. All your suppliers will need is an ordinary web browser and an Internet connection. All your IT department needs to do is to allow access to the e-Business Suite from the Internet. Simple as that is, it represents a change in the security profile of your e-Business Suite and this paper will help you step through the decisions involved in maintaining tight security as you roll out SRM.

IINNTTRROODDUUCCTTIIOONN

Traditional enterprise applications have benefited from an important simplifying security assumption: only employees inside your internal network use them, and you know exactly who they are. The major security threat to the integrity of an enterprise application has generally been the insider with a grudge. Knowing exactly who is has access is a big leg up on removing vulnerabilities and deterring attacks.

Even applications used only by your employees could be vulnerable to outside attack, of course. Most intranets are connected to the larger world at some


access point: to provide Internet access to employees while at work or to enable them to telecommute from their homes, for example. In principle a clever and suitably motivated attacker could use such access points.

Adding Supplier Relationship Management to your IT services is not radically different from providing any of the types of secured internet access points you may already have, but it does call for some risk assessment and planning to ensure continued tight security.

ASSESSING THE THREAT

As you consider deploying an Oracle Supplier Relationship Management solution, it is important to assess the nature and severity of the potential threats to the security of your data. There are essentially two types of threat you should consider in your planning: unauthorized access and denial of service.

Unauthorized Access

Your data center is already exposed to some risk of unauthorized access from people within your organization with some knowledge of the IT services you make available. Extending your e-Business Applications to include supplier users through Internet access expands both the number of legitimate users and the number of potential attackers.

From outsiders, the most likely attack is an intrusion aimed at looking around your network with no clear goal. Such intrusions might be from hackers simply exploring or possibly reconnoitering for a more serious attack. Any websites you have are already exposed to this threat. The only additional risk is a more focused attack motivated by a desire to break into your e-Business Suite applications.

Even as you dramatically expand the number of potential attackers, the fact is your highest risk will probably continue to come from the same people who already pose a threat. Most unauthorized access comes from insiders. The additional risk of providing Internet access may come as much from the greater anonymity available to the same attackers as it does from random outsiders.

Denial of Service

Another security threat to consider is denial of service. The most familiar type of denial of service is an e-mail virus. This is an e-mail message with some kind of attachment that sends out a lot of additional copies of the email every time it is opened. E-mail viruses are a fairly remote threat for your e-Business Suite applications. The applications do interact with e-mail, but the technology components managing e-mail in and out of the e-Business Suite are separate from


the middle-tier components that handle browser-based user access. A true denial of service attack on the e-Business Suite would involve a program that simulated a lot of user activity against the applications. The attack would aim to make the middle-tier and/or database servers too busy to handle any requests from legitimate users. This type of attack is highly unlikely in a traditional pure-intranet deployment since such an attack would be readily detected and prosecuted. In an extranet deployment, however, an attacker has a somewhat better chance of staging a denial of service without being identified. Also, because more people may be aware of your external Internet domain, people without any ties to your organization might be tempted to attack your site.

Balancing cost/benefit

Because your Supplier Relationship Management applications will raise the profile of your e-Business Suite installation, Oracle strongly recommends that you take some additional security precautions to limit the risk of attack. The appropriate precautions to take will depend on your circumstances, of course. The usual considerations of cost vs. benefit will apply.

We have reviewed the two basic threats and in the next sections will discuss how some additional security investments can mitigate them. Some questions to bear in mind in assessing the value of those security investments include:

Who might attack your site?

The Internet is a big place with many hundreds of millions of potential users. But only those who know about your site and are motivated to harm your organization pose a meaningful threat. The nature of your business and public profile will play a big role in defining the actual threat.

How would they become aware of it?

Not all Internet sites are created equal. Virtually every Internet user is aware of sites like Yahoo or e-Bay. But simply creating a domain name and setting up a web server doesnt drive any traffic to the site. Your own actions in promoting awareness of your SRM site will drive the traffic.

What disincentives to an attack already exist?

One big security advantage to an SRM site is the fact that the user community is your supply base. These are people motivated by a desire to sell you their products and services. Unlike a consumer-facing web store which would be promoted to a very broad audience and could pose an attractive target to an


attention-seeking attacker, your SRM site will likely be known almost exclusively to people who are, or would like to be, your business partners.

How vulnerable would you be?

There is a constant arms race in the industry between hackers identifying new exploits and technology vendors finding means to defeat them. In most cases a fix for a new vulnerability is identified and made widely available long before any damage is done. The weakest link in defending against security issues is typically the time it takes customers to notice the issues and apply the fixes. This is not surprising since the fixes amount to preventive maintenance rather than emergency repairs after an actual attack.

What would a successful attack actually cost you?

The cost of a denial of service can be measured by the length of the downtime plus lost goodwill with suppliers who may perceive your SRM site to be unreliable or insecure. The impact of unauthorized access is harder to quantify, as it would depend on the kind of data exposed. Since your e-Business Suite implementation may not include all available modules, you should consider what types of data are stored there and how damaging any unauthorized access could be. As you implement additional modules, you might wish to make further investments in security.

What recourse would you have after an attack?

Any type of attack will leave a variety of evidence that can be used in identifying and prosecuting an attacker. Web server logs, application access logs, transactional audit records all provide means of detecting the source of an attack. Law enforcement authorities are steadily improving their ability to understand and respond to destructive attacks on IT systems and the laws themselves are beginning reflect a heightened sensitivity to IT security.

SECURITY FEATURES OF THE E-BUSINESS SUITE

Much of the discussion in this paper is concerned with a fairly esoteric set of high-tech attacks that in most circumstances are quite unlikely to occur. To keep the matter in proper perspective, bear in mind that the more routine security issues are common to both intranet and extranet applications. The e-Business Suite has been engineered to deal with such routine issues very effectively and these security features will apply equally to extranet access by SRM users.


FUNCTION SECURITY

Very few of your e-Business Suite users have routine access to highly sensitive data. Nearly all are provided very narrow access to selected features and specific data relevant to their jobs. This assignment of specific access rights to individual users is managed through the Function Security screens available only to System Administrators. Even if a users password is compromised, Function Security will prevent access to highly sensitive information unless that user has the relevant authorization. Enforcing tighter security policies for more sensitive accounts can mitigate such risks. In a typical SRM environment, external users will be granted access only to those features and data that concern the supplier they represent. Furthermore, their access can be restricted to specific supplier sites or even restricted to only those transactions in which they are personally involved.

AUTHENTICATION

The core problem in security is being certain of the identity of a user. The most common approach is password-based authentication: if the legitimate user is the only one who knows the password, then you can be confident that whoever just entered the correct password is in fact the person authorized to use the account. In practice, many people use short easy-to-guess passwords, rarely change them and reuse them for many accounts. A password that the user easily remembers tends to be insecure.

Most of the time, insecure passwords dont do any harm. There just isnt anyone motivated to find and exploit them. An attacker will generally focus on identifying the password of a powerful user such as a system administrator. Such users are generally more sensitive to security risks and can be persuaded to take more care in their choice of password and to change it regularly. The e-Business Suite can force expiration of passwords, which can be used to further secure key accounts.

For the strongest authentication, the emerging standard is Public Key Infrastructure (or PKI) and specifically the certificate-based client authentication feature of HTTPS/SSL. Implementing client authentication involves providing certificates to all of your users. This provisioning problem has long posed a serious obstacle to uptake of PKI technology throughout the industry. Beyond the logistical issue of creating and distributing client certificates there is the functional obstacle they create to rapid, convenient uptake of SRM applications by your suppliers. This is where the inevitable tension between convenience and security is most apparent.

In most instances, full PKI is more security than is really needed, but Oracle recognizes the important potential of this and other security technologies and will continue to work toward flexible and convenient implementations of them.


AUDIT TRAIL

Every user login to the e-Business Suite is recorded permanently together with a time stamp, a session ID and information about the Function Security rules applicable to that session. Information about the identity of the user is also attached to all transactions. This provides a means of detecting the party responsible for any transaction, or determining which users might have viewed sensitive data in a given time period. Naturally, if a valid user password has been compromised, it can be difficult to trace back to the actual attacker. But the particular account being used is still potentially valuable information, since it might help to identify other people who could have learned that accounts password.

All failed attempts to login are also permanently recorded. This type of record could be used to determine when an attacker might have been trying to find a password by repeated guessing.

TECHNICAL DEFINITIONS

Understanding the security implications of SRM requires familiarity with some technical terminology.

E-BUSINESS SUITE COMPONENTS

Figure 1 illustrates the most common arrangement of key e-Business Suite technology components.

OHS

This refers to the Oracle HTTP Listener (based on Apache) that responds to the HTTP requests made by a users web browser and routes them to the applications.


JSERV

This refers to the Java Virtual Machine process that will handle the detailed processing of application business logic.

Middle-Tier

This refers collectively to OHS and JSERV, the components that manage user sessions, carry out a variety of data entry validations, formulate database queries and render HTML screens for browser display.

The most common configuration places OHS and JSERV together on each of one or more dedicated middle-tier server machines, and the database is run on one or more dedicated database servers.

NETWORK SECURITY

HTTP/HTTPS

These are the basic protocols used by web browsers to communicate with web servers. HTTP is the Hypertext Transfer Protocol and HTTPS is the secure variant. HTTPS uses the underlying TCP protocol in a slightly different way from HTTP because it uses the SSL (Secure Sockets Layer) to carry out the browser-to-server conversation.

SSL

Secure Sockets Layer is an encryption scheme that involves a negotiation over detailed protocol and an exchange of encryption keys. These keys are packaged in Certificates issued by a Certificate Authority (CA), Verisign being the best known. The added security is very valuable, but does impose an appreciable performance penalty.

X.509

This is the major standard relevant to defining the content of certificates and the processes surrounding their use.


PKI

Public Key Infrastructure refers to the technology and processes around allowing ubiquitous use of public key cryptography for secure communications. SSL and Certificates implement parts of the larger PKI agenda.

Server Certificate

This is the certificate issued to the organization running the web site (it may be specific to a particular web server). This is necessary for the site to support SSL at all.

Client Certificate

This is a certificate issued to the individual user. It is required only if the web server has been configured to activate Client Authentication. This option is rarely used because of the difficulty of providing all users with the right kind of certificate and getting their browsers configured to use them properly. Over time, Oracle expects that these issues will be resolved and will support this type of authentication as appropriate.

Firewall

This is a dedicated routing computer combined with specialized filtering software that enforces policy rules about what network traffic is permitted. The firewall is placed at a bottleneck in the physical network so that all traffic from one side to the other is forced through this consistent policy filter. Typical filtering rules check IP addresses, ports, protocol type, or their combination.

Bussed-Connection Firewall

This is one that allows all attached devices to examine any packets passing through it, relying on the integrity of those devices for consistent enforcement of filtering policy.

Switched Connection Firewall

This is one that isolates data packets so that only the intended recipient has any access. This allows the firewall to filter traffic based on source or destination. Naturally switched connections provide better security, but they are a more recent technology and may cost more.


Stateful Inspection

This is a feature of more advanced firewalls that enables them to track each sessions compliance with the state transition rules defined by HTTP (or other Internet protocols). A class of intrusion techniques is based on violating these rules, so stateful inspection helps in defending against such attacks.

DMZ

De-Militarized Zone is the network area between two firewalls. The term reflects the fact that it is a defensive perimeter surrounding a private intranet and any servers located there are dedicated to performing routing or security functions rather than business functions.

SECURITY REQUIREMENTS FOR SUPPLIER ACCESS

Oracle strongly recommends some additional investment in security infrastructure as a part of your deployment of Supplier Relationship Management applications. Providing Internet access is certain to expose your system to some additional risk of damaging attacks. The likelihood of such attacks and their probable cost are contingencies Oracle cannot accurately assess on your behalf. Therefore we provide some specific recommendations and a rough indication of their relative priority. Your risk assessment will determine how many of these options you implement to achieve the needed level of security. We close with two examples that provide a concrete starting point for your design effort.

Note: Further technical background on the issues and recommendations

discussed in this white paper are available in another document available from the Oracle Technology Network:

Best Practices in HTTP Security

Oracle Technology Network is located at:

http://technet.oracle.com/products/ias/techlisting.html

ENSURE PROPER TRAINING OF YOUR STAFF (Must Have)

Make sure that your project staff includes people with a strong background in network security. Consider additional training to ensure that your staff can be relied on for:

1. Accurate risk assessment


2. Prompt awareness of emerging Internet security issues

3. Systematic uptake of new security features/fixes.

All employees with operational responsibility for your SRM applications should be thoroughly trained on the security procedures associated with the system.

KEEP YOUR DATABASE BEHIND A FIREWALL (Must Have)

If you provide Internet access for your employees, you probably already have a firewall in place to ensure (among other things) that the traffic from the outside is limited to the data returning to web browsers on your employees PCs. If you do nothing else to secure your e-Business Suite from outside access, be certain that your database servers are not accessible from anywhere on the network other than the corresponding middle-tier servers. A firewall can provide added assurance that access to the database is available only through a known network route which can be monitored and further restricted at will.

KEEP YOUR MIDDLE-TIER BEHIND A FIREWALL (Must Have)

Your middle-tier servers will have to have access to the database in order to function. Once an attacker gains access to the middle-tier server, therefore, he will be a long step closer to the database itself. He would still need to find the password for the correct user on the middle-tier server and also a valid database schema password, but the task of finding those is greatly simplified by having access to the middle-tier box to begin with.

USE HTTPS/SSL TO ENCYPT TRANSMITTED DATA (Must Have)

To guard against attempts to eavesdrop on data passing between suppliers browsers and your middle-tier servers, use HTTPS as the protocol serving all requests. HTTPS protects both sensitive application data and the accompanying session tracking data. Some intrusion techniques involve capturing this data and impersonating either the client or server. HTTPS will require obtaining a server certificate, renewing it periodically and making some simple configuration changes on the middle-tier.

Certificate-based authentication is an HTTPS option we would like to offer, but for now it is not available in a form that is consistent with low cost SRM deployment. The difficulty of issuing certificates to supplier users would limit the walk-up registration and self-service profile management benefits that will drive ROI.

USE AN HTTPS ACCELERATOR (Nice to Have)

To mitigate the performance penalty imposed by https encryption, hardware is available which can greatly accelerate this computationally intensive operation.


PUT EXTERNAL USERS ON A SEPARATE MIDDLE-TIER (Nice to Have)

Setting up a dedicated middle-tier server exclusively for external users isolates the external user community and allows you to apply additional security restrictions such as completely ignoring browser requests for screens suppliers dont need to see. Function Security already provides user-specific access controls, but having a redundant layer enforcing similar access rules adds another obstacle to attackers.

This approach is also useful in defending against denial of service attacks since a successful attack on the extranet facing middle-tier could be addressed by shutting down the extranet middle-tier while leaving the rest of the system operational.

USE A DMZ PROXY SERVER FOR ADDED FILTERING (Nice to Have)

The middle-tier servers might be placed in a DMZ between two firewalls, or entirely inside both DMZ firewalls. In the latter case, some type of proxy server would be needed in the DMZ to route traffic on to the applications middle-tier server.

SSAAMMPPLLEE CCOONNFFIIGGUURRAATTIIOONNSS

To facilitate the planning process, we present two sample configurations illustrating reasonable deployments. The first is represents a minimal configuration possibly involving no additional investment in hardware. The second is intended to illustrate a configuration with more of the available options in place.

Bear in mind that any configuration is essentially a series of obstacles for an attacker to negotiate. No technology is completely invulnerable to attack and the basic trade-off is price vs. security. These configurations are presented as high-level architectural diagrams. There are a variety of best practices for the operating system and networking configuration which are an important part of any secure configuration.

Both configurations assume use of HTTPS/SSL for all extranet web traffic.

Minimal Configuration

Strengths Little or no incremental cost.

Ensures that external access to the environment is only through standard web ports, limiting potential attacks to vulnerabilities of the firewall or OHS (Apache).


Weakness Single layer between internet and key server host.

OHS (Apache) vulnerabilities could be exploited to gain control of mid-tier server. Some additional password cracking could permit access to the database from there.

This type of configuration might be appropriate for smaller customers where budget constraints make additional networking hardware an obstacle.

Preferred Configuration

Strengths Extra firewall imposes further burden on attacker.

Weakness May require additional investment in hardware

Would hamper performance. Hardware SSL accelerator would help to limit the performance impact.

This type of configuration is closer to the ideal for best security. Not every option will be required in every case, but this configuration illustrates how the environment might look in a fuller configuration.


Additional features in this configuration include:

1. DMZ with interior/exterior firewalls.

2. Proxy server in the DMZ (with additional routing rules to ignore non-SRM http requests).

3. Dedicated JSERV instance for supplier users.

CCOONNCCLLUUSSIIOONN

An Oracle Supplier Relationship Management solution can provide outstanding ROI because of the low implementation costs and straightforward hard-dollar savings that result. Direct collaboration with your suppliers within your own e-Business Suite applications just makes good business sense.

Internet access by suppliers is a change to the security profile of your e-Business Suite applications that deserves some attention in your deployment plans. Fortunately the issues involved arent a lot different from the security issues associated with any public websites you already manage. The data involved may be more sensitive, but the technologies available to secure them are essentially the same.


Securing Oracle E-Business Suite for

Internet Access by Suppliers

January 2003

Author: Seth Stafford

Contributors: Bruce Lowenthal, Reza Soudagar, Remi Aimsuphanimit, and Charles Colt

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

www.oracle.com

Oracle is a registered trademark of Oracle Corporation. Various

product and service names referenced herein may be trademarks

of Oracle Corporation. All other product and service names

mentioned may be trademarks of their respective owners.

Copyright 2003 Oracle Corporation

All rights reserved.c

security 3

Documents