Exalogic and PCI Compliance - · PDF fileExalogic and PCI Compliance Page 1 A COALFIRE WHITE...

Exalogic and PCI Compliance

A COALFIRE WHITE PAPER

Exalogic and PCI Compliance Implementing Oracle Exalogic in a Payment Card Environment

Version 2.0 August 15

th 2013

S. Dirk Anderson – Managing Director, Coalfire


Executive Summary

This paper examines the suitability of the Oracle Exalogic

platform for securely hosting Payment Card Industry (PCI)

applications in accordance with the PCI Data Security Standard

(PCI DSS)1.

In Coalfire’s evaluation and analysis of Exalogic and its various

security capabilities, we have determined it to be capable of

such support, when implemented within the context of a PCI

compliant security architecture. In addition, there are no

known inhibitors within Exalogic that would prevent an

organization from running PCI applications in a compliant

manner and there are some features which can actually

facilitate meeting certain of the PCI requirements.

Due to the unique business, technical, security and governance

requirements that every organization has, this paper does not

provide detailed recommendations for how to configure

Exalogic to meet the applicable portions of the PCI DSS.

Introduction

Merchants, large and small, face the high risk of data breaches

arising from inadequate security controls or insecurely

developed and deployed applications, which leak or allow

access to sensitive cardholder data. The Payment Card Industry

Data Security Standard was developed with the intent of

reducing the risk of handling cardholder data and is one of the

most rigorous standards established to date.

Security professionals, service providers, application

developers, hardware manufacturers and converged

infrastructure vendors are working across a number of security

domains to address the data security needs of merchants.

Virtualization and cloud computing can create additional

challenges in achieving compliance with the DSS, but does not

inherently prevent compliance.

1 The PCI DSS is available from the PCI Security Standards Council at http://pcisecuritystandards.org. At the time of

this writing the current standard is version 2.0.

Oracle Exalogic provides the

flexibility of configuration and

management to enable a variety

of implementation architectures

which can not only support PCI

compliance but make it easier to

achieve compliance. As an

application platform, Oracle

Exalogic includes the security

capabilities to allow

organizations to be fully PCI

compliant.

http://pcisecuritystandards.org/


Oracle Exalogic provides the flexibility of configuration and

management to enable a variety of implementation

architectures which can not only support PCI compliance but

enhance it. As an application platform, Oracle Exalogic includes

the security capabilities to allow organizations to run

applications which adhere to PCI guidelines. This paper

provides information to IT professionals who are implementing

Oracle Exalogic within their cardholder data environment and to

auditors conducting PCI assessments of those environments.

This paper is organized as follows:

PCI and Oracle Exalogic Basics: Provides the

background of PCI DSS and its application to Exalogic

Overview of Exalogic: Discusses the basic constructs of

Exalogic and its use as an application cloud platform

Exalogic PCI Scope: Describes the components of

Exalogic and how those support PCI

Applicability of PCI DSS to Exalogic: Reviews the

primary PCI DSS requirements and how, where

applicable, these are addressed by Exalogic

Conclusion: Summarizes the findings of the evaluation

of Exalogic and its fitness as a PCI DSS application

platform

Appendix: Exalogic Controls and Support Matrix

provides a cross reference of those PCI DSS sections

applicable to Exalogic

PCI and Oracle Exalogic Basics

This paper assumes the reader is familiar with PCI DSS (including

relevant guidance publications); Card Brand Requirements,

supplemental documents from the PCI Security Standards

Council, such as the cloud and virtualization guideline

documents2; and any specific guidance published by their

acquiring bank or processor. The PCI DSS applies to all

2 The Information Supplements: PCI DSS Cloud Computing Guidelines (version 2.0, February 2013) and the PCI DSS

Virtualization Guidelines (version 2.0, June 2011) are available from the PCI Security Council at http://pcisecuritystandards.org.



organizations that store, process, or transmit cardholder data,

regardless of volume. This includes merchants, service

providers, payment gateways, data centers, and outsourced

service providers.

This paper also assumes that readers have some familiarity with

the basics of the Oracle Exalogic product and its components

including its Exabus technology (InfiniBand-based I/O

backplane). This paper is not intended as an in depth technical

review of Exalogic or as an installation “how-to” guide, as there

are too many variables to be considered in implementing

Exalogic and, in many cases, there may be more than one

option to achieve compliance. Rather, it is presented as an

overall analysis of Exalogic’s ability to support the PCI DSS

requirements applicable to deployment in a cardholder data

environment (CDE).

Although this paper specifically addresses PCI compliance, the

same basic principles can be applied when implementing

systems that comply with other similar regulations, such as the

Gramm-Leach-Bliley Act (GLBA), Sarbanes Oxley (SOX), the

Health Insurance Portability and Accountability Act (HIPAA), the

Federal Information Security Management Act (FISMA) and so

on.

PCI, Virtualization and the “Cloud”

The PCI Data Security Standard requires compliance of

applications that process cardholder data when those

applications are resident in a merchant’s CDE. The CDE includes

all systems and devices that store, transmit or process

cardholder data. To reduce the scope of PCI DSS compliance

requirements, a merchant can segment their network in order

to separate the systems that store, transmit or process

cardholder data from those that do not. This method removes

systems that are unrelated to payment card processing from PCI

DSS scope.

The introduction of virtualization and cloud computing into

cardholder environments can blur the lines of segmentation.

This is especially true when hosting both virtual systems that

handle cardholder data and those that do not, on the same


virtualized platform. However, with attention to the additional

risk factors, virtualized environments, including cloud solutions,

can be implemented with full compliance, as acknowledged in

version 2.0 of the PCI-DSS and the PCI DSS Cloud Computing

Guidelines.

When implementing the CDE using virtualization or cloud

technologies there are additional risk factors that must be

considered and addressed. As noted in the Cloud Computing

Guidelines, this is especially true when outsourcing the CDE to a

cloud service provider (CSP) for hosting.

This paper does not attempt to address all of the concerns of

working with a CSP, which are clearly covered in the Guidelines

document. Nor does it address using Exalogic to provide multi-

tenant hosting, as the variables of doing so would be highly

dependent not just upon the overall architecture, but the

service model being provided, and the related responsibility

assignment for management controls.

However, the use of Exalogic in a private cloud environment or

single tenant hosting, even when hosting both CDE and non-CDE

systems, or multiple environments for the same tenant is

supportable by Exalogic.

Overview of Exalogic

Oracle Exalogic is an Engineered System, integrating compute

nodes, networking and storage with virtualization (optional),

operating system and management software. Exalogic provides

break-through performance, reliability, availability, scalability

and investment protection for the widest possible range of

business application workloads. This includes middleware and

custom applications to packaged applications from Oracle and

hundreds of 3rd party vendors. The hardware resources on

Exalogic may be virtualized or non-virtualized and can be

configured to provide any of the cloud based service levels as

defined by the PCI DSS Cloud Computing Guidelines:

Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or

Software as a Service (SaaS).

When virtualized, Exalogic uses a Type 1 hypervisor as defined

by the PCI DSS Virtualization Guidelines information

Although virtualization and

cloud computing can introduce

additional risks if not managed

properly, they do not inherently

preclude compliance with the PCI

DSS. Exalogic, through the use

of various controls for the

management and partitioning of

system and network resources

can be utilized to run PCI

compliant applications.

For additional considerations

associated with virtualization

and cloud computing see the

following PCI Security Council

Information Supplements:

“PCI DSS Virtualization

Guidelines” and “PCI DSS Cloud

Computing Guidelines”


supplement. Running directly on the hardware allows the

hypervisor to act as the abstraction layer for all hardware

operations and gives it full control over system utilization by the

compute nodes including CPU utilization, disk and I/O

management and guest operating system access to system

resources. Together with the system level management of the

InfiniBand fabric connecting the system components, Exalogic

allows a high level of manageability and access control for

hosted applications, including PCI compliant applications.

Exalogic PCI Scope

The Exalogic engineered solution consists of several

components, each of which must be deployed in a compliant

manner. These include both integrated hardware and logical

components. For a deployment of Exalogic in a CDE the

applicable requirements of the PCI DSS must be met by all of

the components.

Hardware Components:

An Exalogic system is made up of the following primary

hardware elements:

Between 4 and 30 x86 compute nodes, which comprise

the compute tier

A Sun ZFS storage appliance, which is the volume used

by all software binaries

An InfiniBand gateway switch providing connectivity

into Exalogic from the external network

A Cisco management switch for legacy Ethernet-based

management access

The following diagram provides an overview picture of the

general Exalogic architecture:

Typical Exalogic Architecture


At a logical level, Exalogic consists of several key components

which make up the bulk of its functionality and manageability,

and provide the management for applicable DSS controls.

These include the following:

Oracle Integrated Lights Out Manager (ILOM)

ILOM provides low level access to monitor and manage Exalogic

components, including the compute nodes, storage appliance

and network switching (gateway and InfiniBand).

Management Interface

Enterprise Manager Ops Center (EMOC) provides a single

consolidated tool for creating, supporting and monitoring the

Exalogic private cloud solution. This includes management of

the Exalogic system, including compute nodes, virtual machines,

storage, and Exabus networking. Integrating and simplifying

management of the infrastructure reduces the risk often

associated with the added complexity, which could otherwise

result in configuration errors or unintended threats.


Hosted Systems and Applications

When virtualized, the guest operating and/or hosted

applications provide the ultimate functionality in the Exalogic

environment and must, of course, be operated in compliance

with all the requirements of the DSS that would normally apply

to any system or application regardless of the hosting platform.

Exabus

Exabus, Exalogic’s I/O subsystem, is a collection of technology

including InfiniBand switches, gateways, host channel adapters,

firmware, device drivers, operating system extensions and

software libraries. The compute nodes, storage system, and

other Oracle engineered systems all communicate via Exabus

utilizing protocols like Socket Direct Protocol (SDP), Remote

Direct Memory Access (RDMA), Ethernet Over InfiniBand, and

Internet Protocol Over InfiniBand.

Exabus and the underlying technology provide the ability to

separate data content within the fabric as well as the ability to

group and limit connectivity between compute nodes at the

equivalent of the data link layer in a traditional Ethernet

network.

There are, however, some limitations to the use of InfiniBand

isolation on Exalogic which have to be taken into account when

architecting a PCI compliant environment.

Although InfiniBand underlies the Ethernet communications

(which allows for lower level enforcement of partition

management), the current implementation (Exabus) allows for

two types of partition members: full and limited. Limited

members can only see full members (and not other limited

members) while full members can see all other members of the

partition.

Since Exadata does not yet support interacting with multiple

partitions, all partitions that wish to communicate with Exadata

over InfiniBand must be a limited member of the same full

partition. If a greater level of strong granular control than this is

required, it may become necessary to either route traffic out of


the InfiniBand switched fabric and then back via a firewall, or

utilized host based firewalling within the partition.

Oracle Traffic Director

Oracle Traffic Director is a software-based load balancing

solution which can be used to front-end HTTP, HTTPS, and TCP

traffic to the Exalogic and hosted virtual servers. Its use is

optional and it is only available on Exalogic. While the majority

of its functionality is performance-related, it includes several

features which facilitate compliance with the PCI DSS including:

Support for SSL 3.0 and TLS 1.0 with commercial certificates.

SSL encryption and decryption is hardware-accelerated

Integration of web application firewalling to protect web

servers and applications utilizing the Open Web Application

Security Project (OWASP) core rule set

Reverse proxying to mask details such as addresses and

server names of back-end servers

Oracle Virtual Machine

The Oracle Virtual Machine (Oracle VM) is a type 1 hypervisor

which supports the implementation of multiple VMs on the

Exalogic platform. As with other virtualization technologies, it

abstracts basic system services such as processing, memory and

I/O management to the hosted virtual systems. The hypervisor

enables this abstraction and ensures that applications cannot

directly manipulate the system resources and thus limits their

ability to adversely affect those resources and other

applications.

The hypervisor provides the primary management interface for

managing guest operating systems and applications. However,

once the Exalogic system is in place, it is generally accessed

indirectly through the Exalogic Control interface.

In terms of support for PCI, Oracle VM supports strong isolation

of workload processing to ensure that applications and their

data cannot be accessed by unauthorized applications. This

allows for a mixed workload to exist on a single Exalogic node


while complying with the basic tenets of PCI, i.e., ensuring

processing and data isolation.

Another benefit of using Oracle VM is that templates can be

created for implementing new virtual systems. These templates

include both a raw image of the virtual host system and the

Oracle VM configuration information.

This capability can be further extended utilizing the Oracle

Virtual Assembly Builder. Used in conjunction with Oracle VM,

this allows organizations to package self-contained virtual

machines that are really multi-tiered deployments of

applications, middleware and databases.

While the primary benefit of Oracle VM templates and

Assembly Builder is faster time-to-value, but from a compliance

perspective this allows for highly consistent deployments to

ensure that each new VM meets the organization’s

configuration and hardening standards. Having the ability to

document such standard implementations may also reduce the

overall cost of compliance by allowing for a higher degree of

sampling during compliance audits.

The Oracle VM management server is a minimalist installation

derived from Oracle Linux using the Unbreakable Enterprise

Kernel. As a result, it is hardened by default and does not run

unnecessary applications, services, daemons, or protocols.

These capabilities make the use of Oracle VM critical to the

deployment of cloud architectures in an Exalogic environment,

while at the same time enabling compliance with PCI.

Virtualized Host Operating System

When implementing virtualized servers on the Exalogic

platform, host virtualization can be supported using either

Oracle Linux or Oracle Solaris. Either operating system must

itself be deployed and configured in accordance with a

documented hardening standard and the PCI DSS, just as if it

were installed on a stand-alone server. However, each of the

operating systems includes features which, in the Exalogic

environment, can further facilitate the securing of the overall

environment and meeting PCI compliance.


Oracle Linux

Oracle Linux is the most commonly deployed guest operating

system for Exalogic at this time and it provides a couple of

useful features for achieving PCI compliance, including:

iptables firewall enabled by default. This means that, by

default, a VM running Oracle Linux starts out segmented

from the network, including the InfiniBand fabric

Use of Oracle Linux also includes support for the Just

Enough Operating System (JeOS) project implementations.

This minimalist footprint operating system is customized

prior to installation to provide the necessary support for a

particular application it is intended to underlie. As a result,

it provides a base operating system which meets the PCI

DSS requirements to ensure that virtual machines are single

function, and do not run unnecessary applications, services,

daemons, or protocols

Oracle Solaris

Although Oracle Linux may be more common today, Exalogic

virtualization also supports the use of Solaris as the base

operating system for virtual machines, including the use of

Solaris Zones. Zones are a Solaris feature that use kernel-based

virtualization. Relative to PCI support, Zones provide isolation

based on a common OS kernel foundation and provide fine

grained access to system resources including IP address, users

and groups, disk space, network ports, etc. This allows for an

isolated virtual environment, within the overall Exalogic

architecture, which has security and application fault

containment, as well as its own name space that can be

customized for the application that will run in it, and provide

limits to access and privileges.

Applicability of the PCI DSS to Exalogic

As with any specific solution, there are a limited number of PCI

DSS requirements that apply directly to Exalogic, although

features of Exalogic may support meeting additional DSS

requirements. Many of the requirements, such as conducting


background checks on employees or implementing secure

coding standards for web applications, are non-applicable.

Others might apply indirectly, like the requirement to limit ports

and protocols to those that are necessary, which would include

those ports and protocols necessary to manage an Exalogic

environment. Some indirect requirements may even be

applicable only in certain architectures or implementations;

however, certain requirements of the DSS will apply directly to

the Exalogic product regardless of how it’s implemented.

At a minimum, these are the same requirements that would

apply to any computing system or network device placed into a

CDE and primarily include configuration management and

access controls for users.

As explained in the PCI DSS Virtualization Guidelines3, there are

additional scoping and risk factors that must be taken into

consideration based upon both the solution and the

implementation of the solution in the CDE.

Exalogic also provides functionality that, while not actually

necessary for compliance in implementation, can be utilized to

support and simplify compliance, such as the ability to

granularly restrict traffic between systems within InfiniBand

partitions.

The PCI DSS is broken into twelve high level requirements, each

of which contains multiple sub-requirements and defined

testing procedures for compliance. Below is a high level

alignment of applicability to the standard. A more detailed

treatment can be found in the Appendix at the end of this

document.

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to

protect cardholder data

While Exalogic must be deployed in accordance with this

requirement, there are no specific tenets that apply directly to

3 The PCI Information Supplement PCI DSS Virtualization Guidelines v2.0 is available from the PCI Security

Standards Council at http://pcisecuritystandards.org.



the Exalogic system. The PCI requirement for a firewall is

typically met by ensuring that Exalogic, as with other application

servers, is placed behind a firewall. Placing the system hosting

the application servers behind a firewall is standard for N-tier

architectures.

For “internal” segmentation to reduce the scope of the CDE, or

to meet the requirement that there be segmentation between

public facing systems and the system which store cardholder

data, the prescribed Exalogic enterprise deployment

architecture ensures that each functional grouping of software

components resides in its own zone, restricted by protocol and

service port. As a result communication is controlled between

the tiers.

The Exalogic architecture, with its Exabus integration of

InfiniBand, offers a robust approach for providing segmentation

between systems and data storage to meet the requirements

for segmentation between cardholder and non-cardholder

environment systems.

As mentioned earlier, there are limitations to the segmentation

capability provided by partitioning. When properly deployed,

the level of separation should provide adequate segmentation,

as defined in the PCI DSS, of multiple environments for the

same customer (such as testing, staging, production, etc.).

For multi-tenant environments, where each customer

environment is considered untrusted by the others, or meeting

requirement 1.1.3 for a firewall between the DMZ and the

“internal network zone,” this may not be adequate. However,

segmentation can be further enhanced, through the following

techniques:

1. Implementing host level firewalling using the integrated

firewall capabilities of Oracle Linux when it is the

operating system of choice

2. Routing traffic through the gateway switch to an

external firewall which enforces an appropriate rule set

Additionally, if using Oracle Traffic Director, the reverse proxy

capability can be used to mask, not just the IP, but additional

information from back-end systems as needed to achieve PCI

DSS requirement 1.3.4.

When using Oracle Traffic

Director (OTD) to implement

load balancing, OTD can also act

as the termination point for SSL

connections. OTD supports SSL

3.0 and TLS 1.0 with key sizes of

up to 4096 bits. Encryption and

decryption are accelerated by

the use of special hardware

features. Termination of SSL at

the OTD facilitates customer

implementation of web

application firewalls and

intrusion detection systems.


Ultimately, the adequacy of any segmentation, and therefore its

ability to support compliance with the PCI DSS, relies on the

validation of its effectiveness through review and as part of the

internal penetration testing.

Requirement 2: Do not use vendor-supplied defaults for

system passwords and other security parameters

There are two elements of this requirement which apply directly

to the management of Exalogic and its components, which

Exalogic supports:

Encrypt all non-console administrative access [2.3] which is

supported through the use of SSH (which is native for the

command line interface) and SSL to access the systems and

management interfaces. Furthermore, telnet and FTP are

disabled by default due to their insecurity

Change vendor defaults accounts, passwords, SNMP strings

etc. [2.1], which can be done either during the configuration

setup process or through the management utilities

Additionally, the following elements apply indirectly to, and are

supported by, Exalogic. These include the requirements to:

Develop configuration standards for all system components

that include hardening [2.2]

Implement only one primary function per server or virtual

system component [2.2.1]

Since the operating system ships minimalized, pre-configured

and pre-hardened, an optimal PCI security starting point is

achieved out of the box.

Protect Cardholder Data

Requirement 3: Protect stored cardholder data

Although any cardholder data stored on a guest system must be

protected, there are no applicable elements of requirement

three, which apply directly or indirectly to Exalogic.

Cardholder data can be protected utilizing other Oracle

solutions such as Transparent Data Encryption when that data is

stored in an Oracle database.


Requirement 4: Encrypt transmission of cardholder data across

open, public networks

The transmission of cardholder data to or from a guest system

over a public network must be protected, and similarly there

are no applicable elements of requirement four that apply

either directly or indirectly to the Exalogic solution. However,

the use of the InfiniBand fabric allows for the transmission of

cardholder data between hosted systems in a more restricted

manner than a traditional network infrastructure.

When using Oracle Traffic Director (OTD) to implement load

balancing, OTD can also act as the termination point for SSL

connections and thus provide a secure network path for data

transmitted to and from Exalogic. OTD supports SSL 3.0 and TLS

1.0 with key sizes of up to 4096 bits. Encryption and decryption

are accelerated by the use of special hardware features.

Termination of SSL at the OTD facilitates customer

implementation of web application firewalls and intrusion

detection systems.

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software

or programs

The supported Oracle Linux and Solaris operating systems,

when properly managed, are not generally considered affected

by malicious software as defined in the DSS. If it is determined

that anti-virus software is necessary in a given environment, this

would have to be addressed in accordance with the customer’s

overall anti-virus management solution and there are no

applicable elements of requirement five that apply directly or

indirectly to the Exalogic solution.

Requirement 6: Develop and maintain secure systems and

applications

Although most of the elements of requirement six do not apply

to the Exalogic solution, the requirement for all systems to have

the latest vendor supplied security patches installed [6.1] is

easier to adhere to with Exalogic, as Oracle releases

consolidated patches from the operating system on down. This


allows the entire system to be quickly and easily patched. If

hardware support is paid, Oracle will apply all patches quarterly

for free as part of Premier Support for Systems. Collectively, this

improves the patch coverage and increases the patching

frequency.

Finally, if the system is being used to support public facing web

applications, the requirement that they either be assessed (at

least annually and after changes) or have a web application

firewall (WAF) installed in front of them [6.6] can be facilitated

through the integration of the WAF with the Oracle Traffic

Director.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business

need to know

Requirement seven applies indirectly to the operation of the

Exalogic solution in that it requires establishing an access

control system that defaults to no access and that restricts user

access based on a user’s job function [7.2]. These requirements

can be met either through binding access management to an

already in-place directory service (LDAP, Active Directory) or

through the management of local accounts. Access to both the

administrative interfaces for Exalogic and to the guest compute

nodes can be managed granularly through Enterprise Manager

Ops Center and Exalogic Control. In virtualized implementations

of Exalogic, guest operating system and application access are

managed by the customer in the same manner as in a non-

virtualized implementation of Exalogic.

Requirement 8: Assign a unique ID to each person with

computer access

Like requirement seven, the applicable elements of requirement

eight regarding unique accounts [8.1 & 8.5.8], the use of

additional authentication methods [8.2], and account

management [8.4, 8.5.9-8.5.15] can either be met through the

binding of access management to an existing directory service in

the customer environment, or through the use of local account

configuration options.


Requirement 9: Restrict physical access to cardholder data

Physical installation of Exalogic and the controls around physical

protection of media must be in compliance with the DSS but

there are no directly applicable elements to Exalogic.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network

resources and cardholder data

The management applications, Oracle Enterprise Manager and

the Exalogic Control component, log both to a database and to

syslog on the local system, which can be off-loaded through

syslog along with the other system logs. At the lowest level the

ILOM interface provides the capability to offload both event

logs and audit trails to a syslog server.

Requirement 11: Regularly test security systems and processes

Exalogic must be included in the customer’s normal test

processes, including the scanning and penetration testing

requirements, file integrity monitoring, etc. However, these are

operational requirements for the customer and are not directly

applicable to Exalogic.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information

security for all personnel

Exalogic must be covered by and managed in accordance with

all of the customer’s operational policies and procedure.

However, these are operational requirement for the customer

and are not directly applicable to Exalogic.

Conclusion

While there are additional scoping concerns and risks associated

with virtualization and cloud computing, it is possible to

architect an Exalogic based solutions that will achieve the level

of controls necessary to meet the requirements of the PCI DSS.

The ability to achieve overall compliance with any regulation or


standard will be dependent upon the specific design and

implementation of the Exalogic environment and the context in

which it is implemented. In addition, those responsible for

architecting, managing and assessing the implementation need

to be familiar with the solution and the unique risks associated

with virtualization and the tools offered by Exalogic to achieve

compliance.

Oracle Exalogic not only supports the necessary controls but, as

a fully engineered system, includes features which can facilitate

compliance with certain requirements of the PCI DSS and

provides a consolidated management interface which can

actually simplify the management and security of the

environment at the same time that it allows for the elastic

scalability to meet the goals of the customer.


References & Resources

1. Abraham, J., Garami, M., Hoernemann, M., Rao, N.,

Schifano, A. (2012). Consolidating Oracle Applications on

Exalogic.

2. Cloud Special Interest Group, PCI Security Standards

Council. (2013). Information Supplement: PCI DSS Cloud

Computing Guidelines.

3. Getzelman, M. (2013). Oracle Solaris 11 and PCI DSS:

Meeting PCI DSS Compliance with Oracle Solaris 11.

4. Gururaj, Roychowdhuri, S (2012). Oracle Fusion

Middleware Exalogic Enterprise Deployment Guide, Release

EL X2-2 and EL X3-2.

5. Kay, D. (2011). Oracle Solaris ZFS Storage Management.

6. Kumar, M., Roberts, S., Kawalek, C. (2011). Oracle VM 3:

Application Driven Virtualization.

7. Lowenthal, B., Maurice, E. (2010). Recommendations for

leveraging the Critical Patch Update and Maintaining a

Proper Security Posture.

8. Oracle. (2013). Oracle Linux Security Guide for Release 6.

9. Oracle. (2013). Oracle VM: Security Guide for Release 3.

10. Oracle. (2012). Delivering Application Performance with

Oracle’s InfiniBand Technology.

11. Piech, M., Palmeter, M., Lehmann, M. (2011). Oracle

Exalogic Elastic Cloud: A Brief Introduction.

12. Su, H. (2013). Oracle VM 3: Architecture and Technical

Overview.

13. Thomas, Ashish. (2013). Oracle Exalogic Machine Owner’s

Guide, Release EL X2-2 and EL X3-2.

14. Vengurlekar, N. (2012). Network Isolation in Private

Database Cloud.

15. Virtualization Special Interest Group, PCI Security

Standards Council. (2011). Information Supplement: PCI

DSS Virtualization Guidelines.

16. Weise, J. (2012). Exalogic Security.

Additional documentation on implementing and managing

Oracle Exalogic can be found in the documentation area of the

Oracle Technology Network at:

http://docs.oracle.com/cd/E18476_01/index.htm

http://docs.oracle.com/cd/E18476_01/index.htm


Appendix: Exalogic Controls and Support Matrix

The following table provides additional details on the specific requirements which must either be met by

Exalogic for deployment in a PCI compliant environment, or which Exalogic features provide support to

assist in meeting. The table only lists those requirements which were considered to be either applicable

or supported, and not the entire PCI DSS4. Unlisted controls were determined to be inapplicable to

Exalogic, specifically, though they may apply to the broader design and management of a cardholder

data environment, which includes the implementation of Exalogic. Merchants, service providers and

any other entities covered by the requirements of the PCI DSS should always consult with their own PCI

Qualified Security Assessor (QSA) to determine the scope of controls applicable to them.

Supported requirements are those which apply to the use of Exalogic in the cardholder data

environment and must be met to meet to support the customer’s PCI compliance. Features are those

requirements which do not apply to Exalogic, but which a feature of Exalogic may provide additional

functionality to assist the customer in meeting the requirement. Some requirements may have both.

PCI DSS REQ.

REQUIREMENT DESCRIPTION SUPPORTED /

FEATURE COMMENT/EXPLANATION

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.

Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP.

SUPPORTED & FEATURE

Required ports for access and operation of Exalogic are largely industry standards (i.e. SSH) and are documented in the section 3.3.6 of the Oracle Fusion Middleware Exalogic Enterprise Deployment Guide.

Protocols, ports and services needed for the operation of guest systems and applications remain out of the scope of Exalogic.

1.3.4 Do not allow internal addresses to pass from the Internet into the DMZ.

SUPPORTED & FEATURE

Oracle Traffic Director supports reverse proxying which not only masks internal addressing, but server names and other information from disclosure.

1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ

FEATURE InfiniBand partitions allow only member compute nodes to communicate with each other similar to secure VLANs or fiber channel zones. InfiniBand partitions group nodes and support

4 The PCI DSS is available from the PCI Security Standards Council at http://pcisecuritystandards.org. At the time of

this writing the current standard is version 2.0.



PCI DSS REQ.



and other untrusted networks. partial members that can only communicate with full members and not with other partial members.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

2.1 Always change vendor-supplied defaults before installing a system on the network, including but not limited to passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.

SUPPORTED The Exalogic components support the customization of common defaults such as passwords, SNMP strings. These can be customized by the customer or by Oracle support during the Exalogic configuration.

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to:

Center for Internet Security (CIS)

International Organization for Standardization (ISO)

SysAdmin Audit Network Security (SANS) Institute

National Institute of Standards Technology (NIST)

SUPPORTED Oracle provides a variety of resources for their customers to help them configure their systems to their needs, including guidelines and recommendations for hardening and security. Recommendations for both securing Exalogic and using Exalogic to secure data run throughout the implementation and administration documentation. In particular, specific options and settings for securing Exalogic can be found in the Oracle Traffic Director Administrators Guide and in the Oracle Exalogic Security white paper. For additional document details see References & Resources on page 12.

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.) Note: Where virtualization technologies are in use, implement

SUPPORTED & FEATURE

Meeting the requirement for one primary function is largely a customer requirement as they determine the use for systems in their environment. Exalogic can support this both as a host as well as with a virtualized machine. Using the integrated segmentation capabilities and virtualization options within Exalogic can simplify the process of ensuring that each virtual component implements a single primary function


PCI DSS REQ.



only one primary function per virtual system component.

within the capacity of the larger engineered system. Virtualization allows the customer to consolidate their hardware and achieve greater efficiency by running multiple, single-purpose, VMs on shared hardware platforms, while still meeting the security requirements of the standard.

2.2.2 Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system.

Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

SUPPORTED By design, Exalogic only runs those secure services and protocols necessary for operation. Insecure services such as telnet and FTP are disabled by default. The configuration may be further customized by the end user to further reduce unused features and limited to secured technologies.

The configuration of services, protocols, applications and daemons on guest systems and applications is dependent upon the needs of the customer and outside of the scope of Exalogic compliance.

Additional specifics on securing Exalogic can be found throughout the implementation and management documentation, in particular in the Oracle Traffic Director Administrators Guide and in the Oracle Exalogic Security white paper.

For additional document details see References & Resources on page 19.

2.2.3 Configure system security parameters to prevent misuse.

SUPPORTED

2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

SUPPORTED

2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

SUPPORTED The administrative interfaces for both the bare metal and centralized management software support the use of encrypted protocols such as SSH and SSL. Insecure services such as telnet and FTP are disabled by default.

Requirement 3: Protect stored cardholder data

Although any cardholder data stored on a guest system must be protected, there are no applicable elements of requirement three which apply directly or indirectly to Exalogic.


PCI DSS REQ.



Requirement 4: Encrypt transmission of cardholder data across open, public networks

4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.

Examples of open, public networks that are in scope of the PCI DSS include but are not limited to:

The Internet

Wireless technologies,

Global System for Mobile communications (GSM)

General Packet Radio Service (GPRS)

SUPPORTED & FEATURE

Exalogic is designed for deployment as an application middle tier and, when used as intended, will not likely be exposed to open public networks. However, every customer need and architecture is different.

Generally, any network communication which includes cardholder data will occur at the guest system or application level, and encryption will likewise be implemented at that level. The integration of Oracle WebLogic and Java Virtual Machine (JVM) can allow both SSL and SSH to support secure transmissions.

When using Oracle Traffic Director (OTD) to implement load balancing, OTD can also act as the termination point for SSL connections. OTD supports SSL 3.0 and TLS 1.0 with commercial certificates or with self-signed certificates using key sizes of up to 4096 bits. Encryption and decryption are accelerated by the use of special hardware features.

Requirement 5: Use and regularly update anti-virus software or programs

The host operating systems used with Exalogic (Oracle Solaris and Oracle Linux) are generally not considered “commonly affected by malicious software,” particularly when properly deployed in a server based configuration. However, there are anti-virus solutions available for both operating systems and Exalogic users should consult with their own QSA regarding their architecture and the applicability of anti-virus software from a PCI perspective.


PCI DSS REQ.



Requirement 6: Develop and maintain secure systems and applications

6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release.

Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.

SUPPORTED Oracle develops their products in accordance with their Oracle Software Security Assurance (OSSA) methodology, building security into the full product development lifecycle. As a result, security is an integrated component of the Exalogic platform, instead of an add-on.

Oracle provides scheduled Critical Patch Updates (CPU) as part of their normal support contract. Guidance on patch management can be found in Recommendations for leveraging the Critical Patch Update and Maintaining a Proper Security Posture.

For additional document details see References & Resources on page 12.

6.6 For public facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

Reviewing public-facing web applications via manual or automated application vulnerability assessment tools or methods, at least annually and after any changes

Installing a web-application firewall in front of public facing web applications

SUPPORTED & FEATURE

Oracle Traffic Director supports the integration of ModSecurity web application firewalling function which includes support for the OWASP rule set. This can be implemented on a per server basis for each virtual system on Exalogic.

Requirement 7: Restrict access to cardholder data by business need-to-know

7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

SUPPORTED There are numerous user management tools and administration consoles across the various components of Exalogic. These support a variety of capabilities from fairly basic local account management in ILOM, to more robust


PCI DSS REQ.



This access control system must include the following:

tools such as embedded LDAP in the WebLogic Server Administration Console, or the integration with OEL user management in Exalogic Control.

However, user management for all of the components (including ILOM) can be integrated with customer deployed external databases such as Active Directory (AD), Lightweight Directory Access Protocol (LDAP) or Remote Authentication Dial In User Service (RADIUS). Through integration with these full featured access control systems it is possible to manage users in compliance with the PCI DSS requirements, including role based access controls which deny access by default and only grant the allocated privileges.

7.2.2 Assignment of privileges to individuals based on job classification and function.

SUPPORTED

7.2.3 Default “deny-all” setting

Note: Some access control systems are set by default to “allow-all,” thereby permitting access unless/until a rule is written to specifically deny it.

SUPPORTED

Requirement 8: Assign a unique ID to each person with computer access

8.1 Assign all users a unique ID before allowing them to access system components or cardholder data.

SUPPORTED The management tools support a variety of capabilities, from fairly basic local account management in ILOM, to more robust tools such as embedded LDAP in the WebLogic Server Administration Console or the integration with OEL user management in Exalogic Control.

However, user management for all of the components (including ILOM) can be integrated with customer deployed external authentication sources such as Active Directory (AD), Lightweight Directory Access Protocol (LDAP) or Remote Authentication Dial In User Service (RADIUS). Through integration with these full featured access control systems, it is possible to manage users in compliance with the PCI DSS requirements including the specific requirements for unique user IDs and password management.

8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

Something you know, such as a password or passphrase

Something you have, such as a token device or smart card

Something you are, such as a biometric

SUPPORTED

8.5.8 Do not use group, shared, or generic accounts and passwords, or other authentication methods.

SUPPORTED

8.5.9 Change user passwords at least every 90 days.

SUPPORTED

8.5.11 Use passwords containing both numeric and alphabetic characters.

SUPPORTED

8.5.12 Do not allow an individual to SUPPORTED


PCI DSS REQ.



submit a new password that is the same as any of the last four passwords he or she has used.

8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts.

SUPPORTED

8.5.14 Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

SUPPORTED

8.5.15 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

SUPPORTED Session timeouts can be set to user defined limits directly in the various management interfaces such as the Exalogic Control Browser User Interface (BUI), ILOM (both command line and web interface), WebLogic Administration Console and Enterprise Manager.

Requirement 9: Restrict physical access to cardholder data

No applicable requirements. If Exalogic is implemented as part of a cardholder data environment the user should ensure that it is deployed in a physically secure location, and that any data backups which include cardholder data, are secured in compliance with the PCI DSS. However, the controls surrounding the physical location and deployment of Exalogic are entirely dependent upon user architecture and are outside of the scope of this paper.

Requirement 10: Track and monitor all access to network resources and cardholder data

10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

SUPPORTED For low level management, the ILOM includes both event logs (such as chassis intrusion, component failures, removals and additions) as well as audit logs for all interface related user actions (such as login and logout, shell access, etc.) which can be output directly to one or two syslog servers.

The other administrative components write diagnostic log files in the Oracle Diagnostic Logging (ODL) format which are sent up to the central management repository and stored in the Enterprise Manager database on the ZFS storage. Log events can also be sent to the syslog daemon on the hosting operating system, which can then be redirected with the other system logs. The ExaSmoke tool can also be used to

10.2 Implement automated audit trails for all system components to reconstruct the following events:

SUPPORTED

10.2.2 All actions taken by any individual with root or administrative privileges

SUPPORTED

10.2.3 Access to all audit trails SUPPORTED

10.2.4 Invalid logical access attempts SUPPORTED

10.2.5 Use of identification and authentication mechanisms

SUPPORTED

10.2.6 Initialization of the audit logs SUPPORTED

10.2.7 Creation and deletion of system-level objects

SUPPORTED

10.3 Record at least the following audit trail entries for all system components for each event:

SUPPORTED


PCI DSS REQ.



10.3.1 User identification SUPPORTED aggregate the logs from the various Exalogic components for storage and analysis.

There is also a compliance framework built into the cloud control/Exalogic control which provides real-time event monitoring for files, process activity, user activity and monitor for events (like file changes, users performing administrative tasks via “sudo”, etc.). This includes an audit feature which tracks login and logout with role.

10.3.2 Type of event SUPPORTED

10.3.3 Date and time SUPPORTED

10.3.4 Success or failure indication SUPPORTED

10.3.5 Origination of event SUPPORTED

10.3.6 Identity or name of affected data, system component, or resource

SUPPORTED

10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.

SUPPORTED & FEATURE

Exalogic components and supported operating systems implement standard Network Time Protocol (NTP).

Through the Enterprise Management Ops Center NTP can be managed for each virtual server which allows for multiple time-zone support.

10.4.2 Time data is protected. SUPPORTED & FEATURE

Access to NTP configuration can be managed by user role. Additionally the Sun ZFS Storage Appliance used by Exalogic supports the use of Kerberos and signed authentication for NTP communication.

10.5.1 Limit viewing of audit trails to those with a job-related need.

SUPPORTED Access to Exalogic management, including the local viewing of logs and audit trails can be managed through roles in the various administrative interfaces. And, although Exalogic is intended for private cloud deployment, “cloud users” can be created who only have access to see and/or manage the components within their virtualized environment.

10.5.3 Promptly back up audit trails to a centralized log server or media that is difficult to alter.

SUPPORTED Both ILOM and the management applications can log either directly to a syslog server, or through the local operating system syslog daemon which can redirect to a syslog server.

Additionally, Enterprise Manager Cloud


PCI DSS REQ.



Control (EMCC) can monitor the applications running on the cloud servers. This is typically run outside of the Exalogic device and has agents on the nodes.

Requirement 11: Regularly test security systems and processes

No applicable requirements. If Exalogic is implemented as part of a cardholder data environment the user should ensure that it is included as part of the scope for any of their testing and vulnerability management processes including scanning and penetrations testing. Additionally, guest systems may fall into scope for the use of file-integrity monitoring. However none of Requirement 11 directly applies to Exalogic.

Requirement 12: Maintain a policy that addresses information security for all personnel

No applicable requirements. Along with the rest of the cardholder data environment, an Exalogic deployment must be covered by and managed in accordance with all of the organization’s policies and procedures. However discussion of those policies and procedures is outside of the scope of this paper and Exalogic users should consult with their own QSA regarding their coverage and compliance.


About Oracle

Oracle Corporation is a $37.1 billion public company headquartered in Redwood Shores, California, and

is the world’s largest enterprise software company, with more than 115,000 employees worldwide.

Oracle is a leading provider of computer hardware products and services. Oracle develops,

manufactures, markets, distributes and services database and middleware software; applications

software; and hardware systems, consisting primarily of computer server and storage products. Oracle

products are built on industry standards and are engineered to work together or independently within

existing customer IT, including private and public cloud computing environments. Oracle has a presence

in 145 countries and occupies 24.9 million square feet of space, including 2.1 million at the Corporate

Headquarters. For more information please visit: www.oracle.com.

About Coalfire

Coalfire is a leading independent information technology Governance, Risk and Compliance firm that

provides IT audit, risk assessment and compliance management solutions. Coalfire has offices in Dallas,

Denver, Los Angeles, New York Seattle and Washington, D.C. and completes thousands of projects

annually in the retail, financial services, healthcare, government, and utilities industry sectors. Coalfire

offers a new generation of cloud-based IT GRC tools under the Navis™ brand that are used to efficiently

manage IT controls and keep pace with rapidly changing regulations and best practices. Coalfire’s

solutions are adapted to requirements under the PCI DSS, GLBA, FFIEC, HIPAA/HITECH, NERC CIP,

Sarbanes-Oxley FISMA, and emerging data privacy legislation. Coalfire is a Qualified Security Assessor

(QSA) and Payment Application QSA (PA-QSA) firm, and is also a HITRUST CSF Assessor firm. For more

information, please visit www.coalfire.com.

Acknowledgments

Coalfire would like to acknowledge Kelly Goetsch and Kuyper Hoffman from Oracle for their support and

Joel Weise, for his contributions to the original version.

About the Author

S. Dirk Anderson ([email protected]) is Managing Director at Coalfire Systems, a QSA

Company headquartered in Denver, Colorado. He has twenty years of experience in information

technology and security and is a PCI Qualified Security Assessor (QSA) including for Point-to-Point

Encryption (P2PE) solutions.

© 2012, 2013 Coalfire Systems, Inc. All Rights Reserved

http://www.oracle.com/

http://www.coalfire.com/

mailto:[email protected]

Exalogic and PCI Compliance - · PDF fileExalogic and PCI Compliance Page 1 A COALFIRE WHITE...

Documents

Transcript of Exalogic and PCI Compliance - · PDF fileExalogic and PCI Compliance Page 1 A COALFIRE WHITE...