You are on page 1of 15

Securing Oracle E-Business Suite for

Internet Access by Suppliers


An Oracle White Paper
January 2003

Securing Oracle E-Business Suite for Internet Access


by Suppliers

OVERVIEW

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 eBusiness 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.

INTRODUCTION

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

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 2

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

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 3

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

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 4

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.

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 5

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.

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 6

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.

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 7

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.

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 8

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.

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 9

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

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 10

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.

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 11

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.

SAMPLE CONFIGURATIONS

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 highlevel 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).

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 12

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.

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 13

Additional features in this configuration include:


1. DMZ with interior/exterior firewalls.
2.

Proxy server in the DMZ (with additional routing rules to ignore nonSRM http requests).

3.

Dedicated JSERV instance for supplier users.

CONCLUSION

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 eBusiness 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

Page 14

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

Securing Oracle E-Business Suite for Internet Access by Suppliers

Page 15

You might also like