HP BladeSystem and Virtual Connect Suitability in PCI DSS Compliant Deployments

Transcription

1 HP BladeSystem and Virtual Connect Suitability in PCI DSS Compliant Deployments February 29 th, 2012 Version 1.0 atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX Tel: Fax: HP and atsec information security corporation Page 1 of 71

2 Table of contents Executive Summary Introduction Overview of this report Payment Card Industry Compliance The Data Security Standard Described Some Common Misconceptions about BladeSystems and PCI The Key Issues for PCI Compliance Assessors Benefits of the HP BladeSystem Environment HP BladeSystem c-class Server Components Server physical front and chassis enclosure Server networking Virtual Connect (VC) Virtual Connect Enterprise Manager (VCEM) VC and VCEM are optional HP BladeSystem components Integrated Lights Out (ilo) Onboard Administrator (OA) Data Path Analysis Access to memory, disk, or operating system Logging Overview Virtual Connect and VCEM ilo Onboard admin Logging summary Vulnerabilities Review ilo vulnerabilities OA vulnerabilities VCM and VCEM vulnerabilities BladeSystem hardware, interconnect modules, and related components Related vendor products Other vulnerabilities Server Blades Security Features of Server and Workstation Blades Trusted Platform Module Intel AES-NI Power-on and admin passwords HP and atsec information security corporation Page 2 of 71

3 4.1.4 Network boot USB port control Network server mode Storage, Adapters, and Mezzanines Storage Blades Tape Blades BladeSystem Interconnects (Switches and Passthrus) External Storage Adapters and Mezzanine Cards Virtualization PCI SSC Recommendations Evaluate risks associated with virtual technologies Understand impact of virtualization to scope of the CDE Restrict physical access Implement defense in depth Isolate security functions Enforce least privilege and separation of duties Evaluate hypervisor technologies Harden the hypervisor Harden virtual machines and other components Define appropriate use of management tools Clearly define all hosted virtual services Understand the technology Recommendations for Mixed-Mode Environments Segmentation in mixed-mode environments Virtualization in HP BladeSystem Virtual machines (VM) Operating system Hardware/platform Network and storage Memory Encryption and Key Management Key Management Security Assurance Certifications in the BladeSystem Environment Common Criteria FIPS PCI DSS Requirements in a BladeSystem and VC Environment HP and atsec information security corporation Page 3 of 71

4 9.1 Scoping and Scope Reduction Virtual machines PCI DSS Control Objectives in Detail Build and maintain a secure network Protect cardholder data Maintain a vulnerability management program Implement strong access control measures Regularly monitor and test networks Maintain an information security policy Summary/Conclusion A PCI Compliance Supplement A.1 PCI Related Terminology A.2 Standards and Programs B Glossary C Bibliography & References C.1 PCI SSC Documents C.2 Supporting References C.3 atsec references and links: C.4 Organizations HP and atsec information security corporation Page 4 of 71

5 Acknowledgements atsec gratefully acknowledges contributions from several people. Their expertise and knowledge on this subject is invaluable. From HP : Manny Novoa - HP Distinguished Engineer; Robert Checketts Group Manager, Virtual Connect Product Marketing From atsec: Jeff Jilg, Ph.D. - Principal Consultant, Fiona Pattinson Principal Consultant; QSA, Jessica Freda Technical Writer Special thanks to Broadcom Corporation for their partnership in resources and technology that make this report possible. Copyright and Trademarks Hewlett-Packard, HP, the HP logo, and hp.com are trademarks or registered trademarks of Hewlett-Packard Development Company, L.P in the United States, other countries, or both. These and other HP trademarked terms are marked on their first occurrence in this information with the appropriate symbol ( or ), indicating U.S. registered or common law trademarks owned by HP at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of HP trademarks is available on the Web at: BladeSystem integrated Lights Out (ilo) Onboard Administrator (OA) Virtual Connect (VC) UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Common Criteria is a registered trademark of the National Security Agency FEDERAL AGENCY UNITED STATES OFFICE OF THE ASSOCIATE GENERAL COUNSEL. Windows TM is a registered trademark of Microsoft Corporation in the United States and other countries. Bitlocker TM is a registered trademark of Microsoft Corporation in the United States and other countries. Broadcom, Broadcom MASTERS, the pulse logo, Connecting everything, and the Connecting everything logo are among the trademarks of Broadcom Corporation and/or its affiliates in the United States, certain other countries and/or the EU. Notes This report has not been produced in association with the PCI SSC [43]. The statements and opinions made in this report are those of the author. Each Report on Compliance is written by Qualified Security Assessors (QSAs) or Internal Security Assessors (ISAs) properly accredited by the PCI SSC and it is the QSAs responsibility to ensure that all the relevant interpretations and guidance issued by the PCI SSC are considered. The authors, reviewers, and atsec do not accept any responsibility for the acceptance by the relevant stakeholders of any suggestions made in this report HP and atsec information security corporation Page 5 of 71

6 Executive Summary An HP c-class BladeSystem (henceforth BladeSystem) brings with it multiple strengths that an organization using such an infrastructure must understand when considering information security. In the context of a Payment Card Industry (PCI) Data Security Standard (DSS) assessment, a Qualified Security Assessor (QSA) should also be aware of the security implications of both hardware and software components in a BladeSystem. The target audience for this paper includes two groups: Customers who are interested in HP BladeSystem from a PCI DSS compliance perspective, and how BladeSystem components compare to those on standalone servers QSAs responsible for assessing security aspects of a BladeSystem used within a cardholder data environment (CDE), especially where there may be unique features found in the product components Since a BladeSystem environment enables a wide set of configurations, the two main objectives of this paper are to demonstrate the following: An HP BladeSystem environment enables customers to configure a PCI DSS-compliant configuration when security best practices are followed. In particular, Virtual Connect modules enable secure fabric management to achieve a compliant PCI DSS configuration A review of PCI DSS requirements demonstrating which PCI DSS requirements apply (and which are not applicable) to an HP BladeSystem Many external PCI QSAs are probably familiar with traditional standalone server environments and the networking associated with them. The BladeSystem environment provides a similar computing environment, but in a physically denser package. To show the differences and similarities, the paper will also provide an overview the technology in the BladeSystem environment, including: BladeSystem hardware and architecture Virtual Connect (VC) Modules network interconnects integrated Lights Out (ilo) management Onboard Administrator (OA) management 2012 HP and atsec information security corporation Page 6 of 71

7 1 Introduction This report has been produced by atsec information security, an independent company providing IT security analyses, testing and evaluations and at the time of writing this report atsec was a QSA Company accredited by the PCI SSC in good standing. The intended audience of this report includes those who specify, install, use or assess HP BladeSystem in an environment that must be compliant with Payment Card Industry (PCI) standards. This would include those QSA, ISA, and others responsible for assessing the compliance of BladeSystem to the PCI standards. Each payment card brand runs a security program that is organized independently of the PCI SSC; see Appendix A.2, Standards and Programs for a list of these programs. However, the PCI DSS is specified by all of the major payment card brands as the key document for both on-site assessments led by QSAs, ISAs, and for self-assessments. The standard provides twelve requirements that cover many security technologies and business processes, and reflect some of the payment card industry s best practices for securing sensitive cardholder information. The intent of the card brands security programs and the supporting standards is to reduce the risk that cardholder data (CHD), and other critical information is compromised. This report provides the essential information needed to understand the PCI DSS requirements that affect the operation of BladeSystem and Virtual Connect using HP branded components in a PCI DSS compliant environment. 1.1 Overview of this report This chapter gives an overview of the report and introduces the audience and goals of the report. The second chapter discusses some of the basic tenets surrounding PCI DSS compliance and introduces those aspects which are relevant to the installation, configuration and operation of BladeSystems. The third chapter describes some of the benefits of BladeSystems that are supportive of maintain security in a PCI DSS compliant environment. The fourth chapter discusses server blades. The fifth chapter describes the storage blades, mezzanines, switches, and passthrus, as well as best practices that support PCI DSS compliance. The sixth chapter discusses the topic of virtualization in a BladeSystem. The seventh chapter describes cryptography and key management. The eighth chapter discusses Security assurance certifications that have been achieved by components of the BladeSystem architecture. The ninth chapter looks at the specific requirements (from PCI DSS V2) relevant to BladeSystem and looks at the topics of scope and scope reduction. The last chapter is the summary and conclusion HP and atsec information security corporation Page 7 of 71

8 2 Payment Card Industry Compliance This section provides an overview of how security is enforced throughout the payment card industry. The main players in the industry are introduced and the security programs mandated by the card brands are discussed. The Payment Card Industry Data Security Standard (PCI DSS) is a central element of the card brands security programs and is enforced throughout the industry. These security programs and some key terminology are referenced in Annex A. 2.1 The Data Security Standard Described The PCI DSS [1] is a compliance standard produced by the Payment Card Industry Security Standard Council (PCI SSC). All merchants, service providers, and acquirers are mandated by the various payment card brands to comply with the PCI DSS. The standard provides requirements with the goal of protecting valuable information assets (for example, specific cardholder data identified by the card brands). The PCI DSS standard is built around twelve key requirements which are the basis for every assessment of compliance and should already be familiar to the audience of this document. It is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. During PCI DSS compliance assessments, at any level of compliance the assessor must consider all aspects of their card holder data environment. This white paper focuses on those aspects of compliance that are related to HP's server blade technology. 2.2 Some Common Misconceptions about BladeSystems and PCI Whenever complex or innovative technology is deployed and compliance with security standards is necessary, misconceptions abound about how compliance with the standards and regulations are often promulgated. Here are some of the common misconceptions about HP server blades that we have heard and that are addressed in this report: Server blades are too complicated HP BladeSystems are not able to support PCI DSS compliance Server blades are not as secure as traditional tower or rack-mounted servers Virtual Connect cannot guarantee network isolation Virtual Connect cannot be compliant with PCI DSS requirements There is limited or no access control incorporated into Virtual Connect 2.3 The Key Issues for PCI Compliance Assessors When looking at the features of server technology, an assessor will need to understand how the system is supportive of the PCI DSS requirements and the guidance provided by the PCI SSC on the topics of virtualization, how encryption is supported, how connectivity is implemented and kept secure, and how separation is achieved HP and atsec information security corporation Page 8 of 71

9 3 Benefits of the HP BladeSystem Environment In the following list, the BladeSystem and Virtual Connect technologies are summarized to facilitate understanding by an assessor faced with a card holder data environment including BladeSystem and Virtual Connect technology. The systems are documented in detail by a variety of HP manuals and whitepapers, therefore this section will be limited to an overview and pointing the reader to the more detailed resources. The section will also highlight PCI DSS requirements which deal with configuration controlled by hardware. 3.1 HP BladeSystem c-class Server Components The BladeSystem claims the following advantages: Significant reduction of cables, Network Interface Controllers (NICs), Host Bus Adapters (HBAs), and transceivers Simple connection to LANs and SANs, with reduced time to move or replace servers Component replacement without power down Ease of manageability Reduced power and cooling costs Integrated with available Ethernet and Fibre Channel networks HP BladeSystem is available in 10U and 6U enclosures (c7000 and c3000 respectively) and has a set of connectors in the midplane connecting the blades in the enclosure s front to the components in the back of the enclosure. The midplane s connection topology is controlled by configuration options that can be set by Onboard Administrator and Virtual Connect. The back of the enclosure can contain a variety of power, cooling, and interconnect components, as shown in the following figure. Because it is not a goal of this paper to describe document hardware options, the reader is referred to HP documentation for further information: HP BladeSystem c-class Architecture [17] HP BladeSystem c-class Solution Overview [20] 2012 HP and atsec information security corporation Page 9 of 71

10 Figure 1: A C7000 Enclosure Each BladeSystem includes management components, ilo, and OA by default. The ilo management processor is embedded in every blade server and can be disabled (switched off) if no out-of-band server/blade manageability is desired. OA controls connectivity of the management network to ilo and interconnect bays and provides ongoing management of enclosure power and thermal health. Virtual Connect Manager is the embedded management firmwares available on the Virtual Connect interconnect modules, which are purchased as optional add-ins. These items are discussed in a separate section below. For each of the management components (ilo, OA, and Virtual Connect Manager), the following is true: None of the workloads (whether a single operating system on a physical blade or multiple operating systems on virtualized server instances running on a blade) has direct access to OA/VC/iLO components via just a driver within the operating system. The management/configuration of the OA, ilo, and VC BladeSystem components is via SSH connection to a CLI or via SSL connection to WEB GUI For Virtual Connect - Network traffic on the uplink ports interfaces of Virtual Connect (CLI, GUI)Interfaces to each management component are restricted to one of the following: Web session, encrypted by SSL (Version 3)/TLS For VC and OA, Command Line Interface (CLI), primarily intended for scripts or for interfacing with other GUI-driven tools Users must be authenticated to GUI and CLI via: TACACS+ and RADIUS (for VC only) LDAP Local User Accounts Server physical front and chassis enclosure From a PCI DSS compliance perspective, the hardware layer for servers (and switches) is typically not in consideration for networking. If the hardware provides some type of networked access to the server or operating systems, it would become in scope for 2012 HP and atsec information security corporation Page 10 of 71

11 compliance. That is not the case with a BladeSystem enclosure/chassis because neither the enclosure midplane nor the server blades provide direct connection technology, from the front of the enclosure, to an external network. Network layer considerations still apply to BladeSystems when network connections are established to a server blade through networking components in the back of the chassis Server networking HP C-class server blades offer multiple networking options. Each model server ships with two default NICs built on the motherboard. Optional mezzanine cards can be added for additional Ethernet capacity or fibre channel (FC) capability (via HBA). HP FlexFabric Adapters, when paired with Virtual Connect FlexFabric modules, can support Ethernet and Fibre Channel or iscsi traffic. There are a diverse variety of options in this area, and copious literature from HP on the topic. As stated above, there are no direct network connections available on the front of the enclosure (server side). Each server connects to components in the back of the enclosure (through the midplane connectors) to achieve networking. There are three options for this networking: Direct passthru module the NIC on the server is communicated with through a connector on the back of the chassis in a passthru module. In this case the server is networked directly with a switch or router that is connected to the passthru connector Interconnect switch module this is a component which provides Ethernet or FC (SAN) switching. The server is connected to the switch, but the switch handles the communications Virtual Connect module this is an interconnect module which provides converged networking, Ethernet or FC (SAN) networking connectivity, but not switching capability. The server is connected to the VC module, but the Virtual Connect module controls the communications because this is not a direct passthru In all three cases, a PCI DSS conformance assessment will consider networking access to the server and the ports being used for those connections. 3.2 Virtual Connect (VC) Virtual Connect (VC) is used to establish and manage server connectivity to networking and storage technologies. Virtual Connect also adds a virtualization infrastructure between the network and the servers, with the objective of creating flexibility in the number and type of connections that can be utilized, and management of those connections. The HP terminology used for this virtualization layer is server-edge virtualization. There are several Virtual Connect modules that can be classified as: Network only: For example the HP Virtual Connect Flex-10 10Gb Ethernet Module and the 1/10 GB Virtual Connect Ethernet module Fibre channel only: For example the HP Virtual Connect 8Gb 24-Port Fibre Channel Module and the HP Virtual Connect 8Gb 20-Port Fiber Channel Module Converged traffic: For example the HP Virtual Connect FlexFabric 10Gb/24-Port Module For further information on Virtual Connect, see the HP virtual connect web page [18]. Virtual Connect is not an external switch. One way to conceptualize Virtual Connect is to consider how networking connections from VC are presented to the network; i.e. in the same way a server with a hypervisor is viewed by the network as an endpoint network connection. Consider the following example which shows Virtual Connect VLANs: 2012 HP and atsec information security corporation Page 11 of 71

12 Figure 2: VC VLANs Example The top components in yellow and blue represent Virtual Connect profiles associated with four physical server blades with four physical NICs (pnics). The profiles associated with the servers routes the connections into two LANs controlled by Virtual Connect. A VC feature Private Networks can be established (not explicitly shown) to disable direct communications between VC LANs within the VC Domain. In this case, communication from VC LAN to VC LAN would have to be accomplished by an external switch or router. This Private Networks feature effectively disables any attempt to overtly establish VC LAN to VC LAN communications. Continuing the example, the two VC LANs are configured to a shared uplink VC Port 2 connected to an external switch (from HP or another vendor). The switch is configured with two VLANs, effectively served by the four server blades. The two VLANs can be connected to a corporate network as needed. About uplinks and downlinks: From a BladeSystem perspective, the term uplink is used for the external physical network ports that move traffic to/from corporate infrastructure (upstream switching fabric). The downlink term refers to the network/san traffic to/from server blade internal ports to an enclosure or across linked enclosures (via VC cross-links for up to 4-enclosure VC domains). As shown above, Virtual Connect enables a Virtual Local Area Network (VLAN) to be set up between the server and the VC module in the back of the chassis (which enables the physical external connection). The objective of this virtualized layer is to provide flexibility in network connectivity from the server blades to the network modules in the back of the enclosure. The VLAN traffic cannot be viewed or intercepted between VLANs unless there is an explicit network share setup to enable this communication path. Some VLANs managed by Virtual Connect may have shared uplink ports, as in the example above, where the same cable or set of cables carry traffic from multiple networks. Each Ethernet packet contains a VLAN tag (IEEE 802.1Q) to identify which network it belongs to HP and atsec information security corporation Page 12 of 71

13 VLAN tags are added to packets when they exit the VC-enabled enclosure, and VLAN tags are removed when they enter the VC-enabled enclosure. There are a variety of Virtual Connect networking and virtualization scenarios that can be implemented. The objective of the example above is to illustrate one of those scenarios, as this paper will not highlight all the features of Virtual Connect. It is useful to know that Virtual Connect typically is accessed through a Graphical User Interface (GUI) using an SSL connection to the firmware embedded on a VC hardware module (i.e., Ethernet, FlexFabric, or Fibre Channel). This GUI will be discussed further in section Virtual Connect Enterprise Manager (VCEM) As highlighted above, VCEM is an optional software product to accompany Virtual Connect modules when a customer wants to manage more than four enclosures (up to 1,000 BladeSystem enclosures). VCEM is a software product, and it accesses the Virtual Connect firmware in VC physical modules to configure and manage the VC profiles in different BladeSystem enclosures. The benefits of VCEM include: The ability to manage VC domains across thousands of server blades Programmatic access to VCEM repository available for customer customizations VC domain administration through group-based management, including change management across multiple enclosures VC and VCEM are optional HP BladeSystem components VC and VCEM are optional components for HP BladeSystem. It is possible for a customer to acquire a BladeSystem enclosure and servers, and to populate the back of the enclosure with non-vc networking modules. Some customers might opt for this type of installation. 3.3 Integrated Lights Out (ilo) Each server blade has an ilo management processor embedded on the motherboard. The ilo processor effectively subsumes the role of a service processor as found in other HP server products, as well as other vendors servers. In this role, ilo provides out-of-band management features such as temperature and hardware health monitoring, event logs, and power management. The sensor data is passed to Onboard Administrator (OA), which is discussed below. Similar to ilo in other HP servers (and service processors in other vendors servers), ilo provides interfaces to directly access the service processor. These interfaces include a virtual Keyboard, Video and Mouse (KVM) from a web browser or a Command Line Interface (CLI), which is useful for script access. System administrators often use service processors like ilo for hardware-based root debugging from a remote location. In this case, an administrator could use the virtual KVM remotely to access the independently powered ilo on the server blade to access event logs or even remotely reboot the server if it was determined the server blade was in a hung state. It is a benefit to customers to have this ilo service processor feature included by default in each server blade. 3.4 Onboard Administrator (OA) OA is a management infrastructure provided by default within each BladeSystem enclosure and individual server blades. While this infrastructure is not the focus of the paper, it is worth noting that OA enables the following management functions: Detects component(s) insertion and removal 2012 HP and atsec information security corporation Page 13 of 71

14 Identifies components and associated or potential connectivity Manages power and cooling Provides component control One access method to configure and monitor BladeSystem is through the OA Insight Display screen as shown below. Figure 3: Insight Display LCD on BladeSystem Enclosure The LCD panel accompanies each BladeSystem enclosure. The features available from the screen allow for initial enclosure configuration as well as information about the enclosure and its inhabitants. In addition to the LCD panel, OA can be accessed via a web GUI and a CLI. The web GUI is accessible via an SSL session, ensuring the transactions are encrypted. Note that SSL v2 is not allowable for PCI DSS compliance and that the HP OA 2.50 firmware update introduced an SSL V3 connection. The CLI is accessible from serial, telnet, or SSH connections, Note that telnet is often listed as an insecure protocol for PCI DSS compliance by QSAs. 3.5 Data Path Analysis This section reviews the operating characteristics of VC, ilo, and OA with respect to data paths. Specifically, it describes how data can be viewed or intercepted. From a PCI DSS compliance perspective, customers need to ensure cardholder data is secure, and cannot be viewed or copied by unauthorized individuals, whether they are company employees (insiders) or hackers (outsiders). The intent of this section is to reinforce that cardholder data is inaccessible by the management utilities on any of the devices, and that network traffic cannot be intercepted unless specifically configured. The following are objectives for this section: Memory, OS, hard disk contents can t be seen or inspected by any of the utilities except in specifically configured circumstances for ilo where Virtual Media and Virtual Folder can be used to remotely load or boot a new operating system Network contents can t be seen or inspected by any of the utilities Virtual Connect can mirror a port or a VLAN only when specifically configured to do so and that configuration change is logged for auditing purposes 2012 HP and atsec information security corporation Page 14 of 71

15 3.5.1 Access to memory, disk, or operating system Consider access to memory, disk, or the operating system from ilo, OA, and Virtual Connect. From a PCI DSS compliance perspective, this section considers whether information can be retrieved. Also changes to memory, disk, and operating system can have side effects, so modify/write access is also considered ilo access to resources HP has an updated technology brief on ilo, which covers the topic in this section, [14], and [15]. ilo provides limited write access to blade server memory or disk. While ilo does not have direct access to the server blade operating system, it enables access through the KVM console, as discussed below. Access to ilo requires a password or optional trusted certificate. The PCI DSS dictates that the default password should be changed. In addition to direct authentication, ilo firmware can be configured to connect to Microsoft Active Directory, Novell e-directory, or other LDAP 3.0-compliant directory services. From a PCI DSS compliance perspective, it is important to establish and monitor these connection paradigms as system administrative personnel change over time. For ilo to function properly, its configuration changes must be self contained. Just like other service processors this must be accomplished by storing those changes within firmware relevant to the ilo circuitry. Similarly, the interfaces are contained with the same firmware since they have to be self-contained. ilo must function when a server blade is inoperative. The functions built into ilo provide interfaces to and from the management processor. Figure 4: ilo Access ilo provides a virtual KVM, typically used as a remote console. That console enables the administrator to accomplish different tasks. While ilo doesn t directly interface with the operating system, an administrator using the virtual KVM does have operating system access through this console. Of course the administrator will have to login to the operating system to interact with the operating system. Note that to meet PCI DSS requirement 8.3, this administrative connection must be made using two-factor authentication and be made over a secure connection. [1] ilo has an optionally licensed Virtual Media feature, as available in ilo v2 and above. This feature allows a virtual Floppy/CD/DVD to be used to access media located anywhere on the network. This powerful feature can be used to direct a remote host server to boot and use the media from anywhere on the network. The access to Virtual Media within ilo must be granted or restricted through ilo user privileges HP and atsec information security corporation Page 15 of 71

16 ilo has another optionally licensed feature, called Virtual Folder, which allows USB device emulation over the network. A server blade can access the Virtual Folder (with contents loaded by the sysadmin). The folder may only contain pre-loaded content (static) and readonly. Similar to Virtual Media, access must be granted or restricted through ilo user privileges. In summary, the powerful features available to ilo provide the following access: Memory and disk: limited access provided through Virtual Media and Virtual Folder, enabling sysadmin to load new operating system or boot a new operating system Server blade resident operating system: remote operating system access provided, but credentials still required to login and access the operating system. An individual cannot use ilo to inspect an operating system unless they first login to that system The ilo access to BladeSystem servers is powerful. HP has protected this access, requiring sysadmins to have ilo login credentials for ilo access. Additionally, virtual media and folder access requires explicit granting/restriction of those roles associated with the features. HP has also architected ilo to protect access from the server to ilo. Specifically the architecture prohibits access directly from the host operating system to ilo memory and associated circuitry. As a result, an operating system user cannot log in to the ilo host operating system and modify ilo settings reducing the possibility that an attacker could subvert ilo credentials in order to modify ilo access credentials. It is important to consider the PCI DSS requirement 10, [1] for logging. ilo maintains a log of all user access and records of all login events are maintained. Best Practices for ilo Supporting PCI DSS Compliance 1. Read and understand the HP ilo Security Technology brief [13], noting the General security recommendations given in that document. 2. Change default login credentials (Per PCI DSS requirement 2) 3. Establish and maintain ilo login credentials and login methods for sysadmins that meet the requirements of PCI DSS requirement Enable only the features and protocols needed, and disable features and protocols that are insecure, not used or rarely used such as ilo itself or Virtual Folder or Virtual Media. Optionally, only enable these features temporarily when needed. Note that Virtual Media s default is enabled 5. Disable services and protocols that are not used within ilo by port (such as IPMI over LAN, or LDAP) 6. Use two-factor authentication for remote access 7. If the remote console access is not used, then disable the remote console port OA access to resources As mentioned above, OA is designed for managing the BladeSystem enclosure and its components with the intent of local and remote health monitoring, power usage, and cooling of the components. The product is delivered as a physical module and associated firmware, in addition to the LCD monitor on the front of the enclosure. 1 Note that password requirements are specified by PCI DSS include a minimum length of 7 characters, a mix of numeric and alphabetic characters, different from the four previously used passwords. Additionally passwords must be changed at least every 90 days, and that accounts are locked after 6 invalid logon attempts. (See PCI DSS [1], Requirement 8) 2012 HP and atsec information security corporation Page 16 of 71

17 The front enclosure LCD monitor provides access to Insight Display. Through the display, component health can be viewed and enclosure settings can be accomplished. This includes setting an OA IP address. Insight Display does not provide access to memory, disk, or operating system on any of the server blades. There is one default physical OA module provided for installation in the BladeSystem enclosure back. An optional second physical OA module may be added. The physical module is designed with multiple physical network ports as shown in the picture below. The network connectors shown in the figure allow various network connections to be established. Figure 5: Onboard Administrator Module Installed in a BladeSystem Enclosure 1. RJ45 Ethernet access to OA and ilo on each server blade 2. USB 2.0 enclosure KVM access for connecting USB devices 3. RS232 DB-9 serial connector for access to OA CLI 4. VGA DB-15 connector for VGA monitor connected to KVM menu or OA CLI 5. CAT5 connect to enclosure link-up port to enclosure below 6. CAT5 connect to enclosure link-down port on enclosure above KVM and the OA Command Line Interface (CLI) are available through the Enclosure KVM, which requires the monitor, keyboard, and mouse to be connected directly to the physical OA module in the back of the enclosure. The Enclosure KVM enables an administrator to launch and run a server console. The server console and the OA CLI are protected by user logins as well as any physical security surrounding the system. Hence, the server blade host operating system is accessible but requires standard login to gain access to any resources or content on the operating system. BladeSystem memory and disk are not accessible directly from the KVM feature unless a user first logs into the host operating system. There are a number of network configuration commands. However it is important to note these commands are specific to the BladeSystem enclosure and the commands cannot be used to modify the network configuration settings of server blades HP and atsec information security corporation Page 17 of 71

18 The OA CLI can be accessed from the KVM, as well as serial port, management port, or service port on the physical OA module (connectors). A username/password is required to log onto OA and use the CLI. The commands enabled by the CLI provide scriptable interfaces to the commands that can be executed from the GUI with the objective of monitoring health of the various components in the enclosure. The OA CLI does not provide direct access to the server blade host operating system, memory or hard disk. The telnet and SSH interfaces are provided as a method to remotely access OA from outside the enclosure. Alternatively a web browser session (http or https) can be used. These access methods do not provide any access to the hosted server blade, because the access methods only provide access to the OA module/firmware located at the OA IP address within the enclosure. Although these interfaces provide access to OA only, it is best to setup the correct security with each interface. As an example, telnet is a known insecure access method so to achieve PCI DSS compliance restrict OA access via telnet to no access at all, or limited access on a secure dedicated network, and either configure to use SSL V3, or provide channel security for the otherwise unprotected http protocol, An LDAP interface is provided to allow authentication to OA through LDAP or Microsoft Active Directory (AD). This access allows an administrator access to OA and should be restricted to those individuals who need access. The LDAP/AD interface does not in itself provide any further access to server blade resources. Simple Network Management Protocol (SNMP) traps can be issued by OA including interaction with the OA CLI. The community strings should be changed from the default public value. The SNMP trap issuance and receipt cannot be used to access server blade resources, which is consistent with the rest of OA behavior. In summary, the features provided by OA allow an administrator to access and monitor health information for components located within a BladeSystem enclosure. The OA access to server blade resources is limited, and does not allow for unauthenticated access to the operating system on a blade. Nor does OA access allow for disk or memory access unless one is authenticated to an operating system in a server blade. Best Practices for OA Supporting PCI DSS Compliance 1. Provide physical security to limit access to only authorized individuals, in particular to the Insight Display LCD on the front of the enclosure and the OA module(s) and connector jacks in the back of the enclosure. Physical security can be achieved through rack enclosures with door locks, as well as datacenter physical security measures 2. Selectively disable network access to OA as needed for the following interfaces: a. Web access is enabled by default, which utilizes port 80 for http and port 443 for https b. Secure shell (SSH) on port 22 is enabled by default c. Telnet (via port 23) is enabled by default and should be disabled in a PCI environment d. XML reply is enabled by default, enabling XML data to be shared by OA to other tools 3. Enable enforce strong encryption to enforce use of FIPS approved encryption (AES, 3DES, and SHA) for SSH. Note that web GUI sessions use FIPS algorithms regardless of this setting 4. Modify the read and write community strings, which by default are public. In particular the SNMP write capability allows an SNMP management client to clear 2012 HP and atsec information security corporation Page 18 of 71

19 Best Practices for OA Supporting PCI DSS Compliance OA alerts or mark OA alerts as viewed 5. Change the OA default user account Administrator password to a custom password that meets the PCI DSS requirements 1 Ensure that the following configurations are set: 6. SSH is used to ensure secure connectivity 7. TWO FACTOR authentication is configured 8. SET ENCRYPTION is set to STRONG 9. ENABLE STRONG PASSWORDS is configured SET MINIMUM PASSWORD LENGTH is used and a length of at least 7 characters is set. SESSION TIMEOUT is set as 15 minutes 11. HTTPS using SSL V3 is enabled. Note that this is the default setting 12. TELNET is disabled 13. NTP is set up and that the SYSLOG is enabled Virtual Connect Manager (VCM) and VCEM access The features for Virtual Connect Manager and VCEM were mentioned earlier in this document, but to recap, these management interfaces are used to establish and manage server connectivity to different networking technologies. Virtual Connect does not provide external network switch capabilities and is not a network switch. VCM GUI access is achieved through one of two methods: Web browser through HTTPS (port 443) to the primary physical VC Ethernet or VC FlexFabric module OA logon, then navigation to the VCM link through OA The access methods above provide access to the VCM GUI, but login is still required (username/password) to gain access to VCM. Authentication methods include LDAP, RADIUS, and TACACS+. PCI DSS compliance around these authentication technologies should be followed. For example, password changes should be enforced at a maximum of every 90 days, as well as restricting access to only those individuals who need it. VCM CLI access is accomplished through an SSH session or via embedded console access from the OA CLI. Authentication is required, similar to the GUI. The authentication methods include support for LDAP, RADIUS, and TACACS+. VCM CLI offers access to the full VC feature set while allowing for automated configuration via scripts. Role assignment within the VCM allows up to four privilege assignment per administrator within a VC domain: VC Domain and Network settings management Server profile creation, deletion, and updating Storage connection management For PCI DSS compliance, the role assignment to a system administrator should be restricted to job function and allocated to only those privileges needed to accomplish assigned tasks. This should be a consideration when allocating roles and access privileges within VCM. For 2012 HP and atsec information security corporation Page 19 of 71

20 sysadmins which only need view status their role within VCM would not have any of the four roles listed above assigned to the individual s profile. Virtual Connect server profiles are used to establish links between a server and networks and fabrics supported by VC. Protocols include Ethernet, iscsi, FC, and FCoE. Virtual Connect server profiles allow for customization and virtualization of I/O parameters such as IP address, MAC, WWN, and boot parameters. The blade server operating system sees only the virtualized settings of the physical NIC or HBA, allowing for dynamic replacement of blades without affecting network or storage fabric setting. As an example, the MAC address associated with a VC server profile is only maintained for a particular server blade while that server blade resides within a Virtual Connect enclosure. In this example, the MAC address is established and maintained within VC. If the server blade is moved to a non-vc enclosure, then the server blade will revert to its factory-assigned MAC address automatically because the VC configuration of that server blade does not migrate with the server blade. A VC server profile controls settings within a Virtual Connect enclosure but provides no access to resources (memory, disk, or operating system). It is also worth noting that if a server blade is moved to another bay within a VC-controlled enclosure, the server blade will be assigned new addresses associated with the VC server profile associated with that enclosure bay. Therefore, physical server blade or module movements between bays and slots must be planned and approved in advance to avoid unintended configuration changes. Similar to other Virtual Connect settings, network connectivity between a server blade and the external network is controlled through server profiles. This includes boot parameters and PXE settings. It is possible to enable PXE operations through VC and specifically through a VC server profile, overriding BIOS settings if specified. Thus PXE configuration can be set in BIOS or driven through configuration updates from VC server profile. If PXE operations are enabled and used to drive bootup, this will change the boot behavior of a server blade which might already have a bootable operating system on the disk. If PXE is enabled and used to boot a server then the local server blade disk will be readable. It is good practice to limit PXE boot to only those servers needing it. Another good practice is to disable PXE boot once a server has been provisioned with a local bootable operating system (on the native disk). VC domains and networks A single Virtual Connect domain can span up to four linked enclosures and includes the server blades and components contained within each enclosure. VCEM can be used to manage multiple domains. Further information on Multi Enclosure VC Domain Stacking can be found in the HP Virtual Connect Multi-Enclosure Stacking Reference Guide [31]. Within Virtual Connect, storage such as iscsi bays can also be managed, requiring credentials to be entered into VC. Virtual Connect modules can be monitored to produce SNMP traps configured by VCM for use by management software which collects and monitor health status. VCM does not receive configuration changes via SNMP; the information flow is outward. SNMP trap configuration is supported for SNMPv1 or SNMPv2, but not SNMPv3. Within VCM and VCEM, SNMP community strings are set to public by default and should be changed to protect destination security, as well as security of SNMP information retrieval from VC modules in order to meet PCI DSS requirement 2.1. Virtual Connect can be configured to support a variety of networking scenarios. The product supports VLANs, VLAN sharing on one or more ports, host-based VLANs spanning multiple servers and physical NICs, and other scenarios. From a PCI DSS compliance perspective, it is important that each network change is reviewed, documented and approved. Administration of networks should only be assigned to individuals requiring this privilege in their Virtual Connect role. As mentioned above, it should be noted that any VC system administrator can view settings, even if they don t have a particular role (i.e., network) assigned to their profile HP and atsec information security corporation Page 20 of 71

21 VC fabrics VC supports several protocols to establish and maintain fabrics. Fabric support requires an associated VC Fibre Channel Module or a VC FlexFabric Module (shown below). The modules serve as HBA aggregators because each uplink port can handle traffic for multiple HBAs (on the server blades). Figure 6: VC FlexFabric 10Gb/24-port Module The configuration options for SANs within Virtual Connect allow for typical selection of the HBAs and SAN fabric switch WWN, as well as BladeSystem specifics such as SAN bay within an enclosure, For PCI DSS compliance, individuals assigned to the storage role within Virtual Connect should be reviewed periodically because that role has read and write capabilities for SAN configurations. It is important to note that MAC addresses and WWNs (SAN) might revert to factory settings if improper OA module replacement procedures take place. During such procedures it is important to ensure proper network isolation is provided to prevent unauthorized access. Best Practices for VC and VCEM Supporting PCI DSS Compliance 1. Enforce passwords are changed at most every 90 days for all access methods to VC and VCEM, including VC local user accounts as well as LDAP, RADIUS, and TACACS. If storage bays are managed, the 90 day password change applies to those credentials as well 2. Ensure the default Administrator password is changed. System administrators passwords should also be changed every 90 days. (The default Administrator password is posted on a physical label on the primary VC module in an enclosure) 3. Role assignments to VC and VCEM administrators should be restricted to only those roles required to accomplish the assigned tasks 4. For SSL, ensure that Strong SSL ciphers is selected, enforcing strong encryption 2012 HP and atsec information security corporation Page 21 of 71

22 Best Practices for VC and VCEM Supporting PCI DSS Compliance strength of at least 128 bits and that SSL V2 is not used 5. Actively manage, review and document all changes to a BladeSystem enclosure, including VC controlled enclosures a. As an example, manage/monitor configuration changes because some changes will result in network changes b. Another example is to manage enclosure bay changes if a server blade is moved from one bay to another, it may change VC domains in the process. This should be a desired outcome, not an accidental outcome, requiring review and approval of the intended physical blade movement. Other physical component movements to other slots and bays should similarly be reviewed/approved 6. PXE boot: Disable this feature when not in use. Limit PXE boot to only those servers requiring it, and ensure that the networked boot path is authorized. Review and authorize changes to PXE images 7. SNMP community strings should be changed from their default public setting to a password meeting PCI DSS Requirement 8, [1] password length and complexity requirements 3.6 Logging Overview The objective of this section is to show where and how logging can be achieved for BladeSystem and the corresponding components. This serves as a demonstration of compliance to PCI DSS auditing requirements. The logging requirements of PCI DSS are intended to help system administrators track and record configuration changes as well as monitor any changes which could be used to subvert/disable security and enable CHD access. The PCI DSS logging requirements are found in PCI DSS [1] The following will be highlighted: Central logging Utilization of logs that include time stamps and authentication which can be exploited for a PCI DSS-compliant configuration Specification of the granularity of logs (critical vs. non-critical) Information that can be logged Virtual Connect and VCEM For VC, the System Log can be reviewed within the GUI. This is useful for forensics and also to verify that a task was accomplished (i.e., a scheduled trouble ticket completion). The log uses a colon : separated format where the date can be specified in RFC 3164 or ISO 8601 formats. The time/date inclusion in each event supports PCI DSS compliance when used forensically to determine exactly when a configuration change or event occurred. Five severity levels are supported, from Severity_info representing a low-level condition to Severity_Critical representing a critical event that requires immediate attention. PCI DSS logging requirements (PCI DSS [1], Requirement 10) are supported. The System Log is protected from unauthorized users because authentication to Virtual Connect is required to access the log. Logs can be forwarded to one or more recipients, including log aggregator tools. The log configuration allows log severity to be specified with the destination. As an 2012 HP and atsec information security corporation Page 22 of 71

23 example, this log filtering can be used to send Critical events to one group, and less critical events to other group(s). Transmission of the events from the System Log can be encrypted or unencrypted. Best practice indicates that encryption should be selected. VCEM logs are recorded into the Systems Insight Manager Audit log. Since VCEM works across VC domains, typical content will span more than one enclosure. The log characteristics in Systems Insight Manager are similar to VC logs, providing compliance and flexibility in implementing the PCI DSS requirements ilo ilo retains two logs, which are explained below. Both of the logs are accessed only after authentication to ilo has occurred. The logs support the PCI DSS requirement for containing and retaining date and time-stamped information, which can be used for forensics when required. A handy feature for both log types is the ability to save copies of the logs in comma separated value (CSV) files. Subsequent review in a text or similar editor can then be done and selective filtering (or finds) can be done against the aggregate log data such as looking for trends like failed login attempts from a specific client. The Event Log (aka: IPMI System Event Log (SEL)) retains information about major server events, such as a server reset or server power outage. The Event Log can (and should) be configured to optionally record ilo failed authentication logins to ilo, which also captures the client name, computer name, and IP address. As part of failed-login tracking, ilo can send alerts of failed logins to different destinations, such as a remote management console. The failed-login event can have its threshold set so that every second, third, or other numerical value will trigger the event (i.e., enabled every third failure). The Integrated Management Log within ilo records software events as generated from the system ROM (POST codes) or services such as the system management (health) driver. System events such as fan inserted, fan failure, temperature overages, and system shutdowns are recorded into the log Onboard admin Can send syslog to central logging system if they are syslog compliant Can specify granularity The OA System Log (AKA: syslog) captures events from OA using first in, first out data retention to available non volatile memory. As with other HP logs, authentication to OA is required in order to view or clear events from the log. Remote system logging can be enabled to retain larger logs. The protocol for remote system logging follows RFC3164 guidelines. A nice feature with remote system logging is the ability to deploy test messages to ensure the logging is configured and working appropriately. Events that are records to the System Log include enclosure events such as enclosure shutdown, name change, fan status, power supply status, and bay/device insertions and power states. The events are numbered which allows for easy parsing or cataloguing during forensics or event analyses HP and atsec information security corporation Page 23 of 71

24 3.6.4 Logging summary Best Practices for Logging Supporting PCI DSS Compliance Ensure that the following configurations are set: 1. VC - Specify the STunnel option on remote log destinations to ensure encrypted log content transmission 2. Ensure that log access (VC, OA, ilo access) is only granted to those individuals requiring access per their job role. Similarly, ensure authorized log destinations are established for event or log forwarding 3. Ensure that the configuration of remote logging destinations are reviewed periodically to ensure log events are being properly forwarded. (It does no good to rely on remote logging if it is improperly configured) 4. Ensure that the date and timestamp are being recorded with each event as this enables proper forensics if ever needed. Also ensure that the time source is set according to national standard and cannot be altered 3.7 Vulnerabilities Review This section summarizes research of any known or resolved security vulnerabilities related to c-class BladeSystem components. For the few vulnerabilities which are published, HP has already provided resolutions. HP maintains a webpage showing published vulnerabilities and their resolutions. [35] This is the HP Support Center security bulletin list, a comprehensive list of known vulnerabilities. When this paper was finalized the most recent item found (C ) was from The HP webpage above also shows vulnerability scores against CVSS, which could potentially be reused during PCI DSS [1] assessments when ranking vulnerabilities in requirements 6.2 or If you are evaluating vulnerabilities against current or prospective BladeSystem components, the HP BladeSystems Technical Resources page [32] shows the different components and models available in the BladeSystem enclosure. As an example, ProLiant BL680c G7 shows up as a model that is supported. If there is an ilo or other firmware vulnerability, the webpage can be used to determine the component number and see if that vulnerability applies to the component number in question (i.e., ilo v3 is the standard for this BL680c G7, whereas ilo v2 is supported on BL2x220c G5). It is useful to note that server blade model naming nomenclature uses a preface of BL for the model number. Hence BL680c is a blade model, whereas DL170 refers to a non-server blade model. Disclaimer: If you are a PCI DSS assessor evaluating vulnerabilities, the list of published vulnerabilities listed below should not be considered as an alternative to performing a current search. This list was created using common sources of vulnerability information, but other sources may need to be considered or other vulnerabilities may have been published after this document was produced ilo vulnerabilities HP #c , NIST #CVE Affects: ilo (first unlabeled version) firmware v1.7 through v1.87 running on Proliant servers Affects: ilo 2 v1.0 through v1.11 running on Proliant servers 2012 HP and atsec information security corporation Page 24 of 71

25 Impact: The vulnerability allows potential remote exploit to gain unauthorized ilo access Resolution: Install firmware upgrade to ilo v1.88 or above, or to ilo 2 v1.20 or later HP #c , NIST #CVE Affects: HP Integrity server blade model BL860c running ilo-2 MP firmware v T and earlier Impact: The vulnerability could be remotely exploited to cause a Denial of Service (DoS) Resolution: Install T or later Not Applicable: HP #c Note this ilo vulnerability does not apply to server blade components HP #c Note this ilo vulnerability does not apply to server blade components HP #c Note this ilo vulnerability applies to versions of ilo software that predate the current server blade product line OA vulnerabilities HP # c , NIST #CVE Affects: HP Onboard Administrator (OA) v3.21 up to and including v3.31 Impact: Remote unauthorized access Resolution: Update to HP OA v3.32 or later Not Applicable: HP #c Note this OA vulnerability does not apply to server blade components VCM and VCEM vulnerabilities HP # c , NIST #CVE Affects: VCEM v6.0 prior to Insight Software v6.0 Update 2 and VCEM v6.1 prior to Insight Software v6.1 Update 2 Impact: The vulnerability could be remotely exploited for remote arbitrary file download Resolution: Update to VCEM 6.0 or VCEM 6.1 by installing VCEM 6.2 or later HP #c , NIST #CVE Affects: VCEM for all versions prior to v6.1 Impact: Remote cross site scripting (XSS) could be exploited Resolution: Update to VCEM v6.1 or later Not Applicable: HP #c Note this OA vulnerability does not apply to server blade components 2012 HP and atsec information security corporation Page 25 of 71

26 3.7.4 BladeSystem hardware, interconnect modules, and related components There are no known vulnerabilities applicable to these components Related vendor products HP #c , NIST #CVE Affects: Cisco Catalyst Blade Switch 3020/3021 with firmware earlier than v12.2(50) Impact: Following can be exploited - Remote execution of arbitrary code, Denial of Service (DoS) Resolution: Update Cisco firmware to v12.2(50) or later Other vulnerabilities HP # c , NIST #CVE (XSS), CVE (DoS), CVE (CSRF) Affects: HP Insight Control virtual machine management for Windows prior to v6.2 (which can be supplied with HP BladeSystem Matrix Infrastructure) Impact: Following can be exploited - remote cross site scripting (XSS), Denial of Service (DoS), cross site request forgery (CSRF) Resolution: Update to HP Insight Control virtual machine management v6.2 or later Not Applicable: HP #c Note this Integrated Administrator vulnerability does not apply to c-class server blade components (and this paper only addresses c-class components) 2012 HP and atsec information security corporation Page 26 of 71

27 4 Server Blades Several models of server blades can be used, as listed below: ProLiant workstation blades (Intel Xeon) ProLiant server blades (AMD Opteron and Intel Xeon processors) Integrity server blades (Intel Itanium processor) The security considerations of management utilities for server blades were discussed previously. Additional security considerations for server blades are discussed below. 4.1 Security Features of Server and Workstation Blades In this section the security features associated with server blades are discussed. Since there are currently over twenty models of server blades, the reader is encouraged to look at server blade specifications to determine whether a feature is applicable to a particular model. A good reference webpage for many blade models is found on HP's Technical Resources web site for blades [32]. For each of these features, advantages for PCI DSS compliant environments are shown where appropriate. The features in this section are enabled (or configured) through the ROM-Based Setup Utility (RBSU) Trusted Platform Module Trusted Platform Module (TPM) 1.2 is available in select server blade models CPUs as an option, including select Generation 5, 6, and 7 server blades. TPM is an industry initiative to define hardware-level instruction sets to securely store information, such as passwords and encryption keys. TPM for server blades is implemented as a non-replaceable (riveted) part. The Infineon product used in the blades, (SLB9635TT1.2 / m1566a13 HW a13 / FW ) has been evaluated using the Common Criteria standards at EAL 4 + [40]. TPM can be used to perform platform authentication. One example where platform authentication can be used is trusted pathway. Trusted pathway utilizes built-in TPM authentication to ensure trusted boot pathway; or in simpler terms the pathway from the boot sector on the operating system can be authenticated down to the hardware involved in the boot process. This is implemented in Microsoft Windows Server 2008 in the BitLocker TM feature. BitLocker can also use TPM as part of the logical disk drive encryption for those customers who wish to encrypt part or all of a disk drive. For PCI DSS compliance, a suitable encrypted disk can be used to protect contents while in the datacenter. And more effectively, the contents of encrypted disk, which are removed from the datacenter is useless without the decryption password. Note for PCI DSS [1] compliance the use of encryption will include checking that the encryption selected is strong encryption and that key management is performed in a way that ensure the encryption cannot easily be compromised Intel AES-NI Intel AES-NI (Intel Xeon 5600 series and other Xeon processors) for enhanced security is a CPU-implemented encryption instruction set of the Advanced Encryption Standard (AES) algorithm. Customers get an advantage with this implementation because of the faster times for hardware-based AES implementation versus software implementation. Since the algorithm calls are hardware-based, there are fewer CPU cycles involved in the overall encryption of data packets. This implementation enables an environment that is less burdened with encryption operations and the feature benefits customers with the protection of cardholder data where card information must be encrypted. As an example, one can optionally setup full 2012 HP and atsec information security corporation Page 27 of 71

28 disk encryption in Linux (i.e., Ubuntu) which is implemented in the kernel, and accesses AES- NI instructions on the CPU. This CPU feature is found in Intel Xeon and second generation Intel Core processors Power-on and admin passwords Server blades have optional power-on passwords. These passwords can be set in the RBSU, and will take effect on the next boot. In a PCI DSS compliant environment this feature could be used to prevent takeover of a rebooted server. However, one should also consider expected reboot behavior upon datacenter-wide issues. If dozens or hundreds of server blades are waiting for passwords upon reboot, it could be challenging to get the whole datacenter up and running since each server would need an administrator to type in the passwords. Additionally physical security of the datacenter may be considered by the QSA as a compensating control. An administrator password 1 can also be established on each server blade. Once set, the administrative features available within the RBSU can only be changed if the administrator password is provided Network boot One option associated with the embedded NICs on server blades is the ability to accomplish (or not) a network boot. If a network boot is selected per NIC within RBSU, the server can be set up to look for the boot image on the network. This is often associated with Pre-boot Execution Environment (PXE) settings. If a network boot is an undesired option, it should always be disabled to prevent the server from booting from an unauthorized network source USB port control USB ports can be enabled or disabled within RBSU. If USB ports are disabled, it will prevent the possibility of attaching any direct or virtual media to the server blade. If there is no expected use of USB ports the PCI DSS [1] requirement is to disable those ports Network server mode This option can be set within the RBSU, and can be used to enable or disable the server blades keyboard port. The network server mode option is used in conjunction with the poweron password. If disabled, the server operates normally. When enabled, the power-on password must be entered to unlock the local keyboard. This could be a good feature to enable in a PCI DSS compliant environment to reduce the risk of local unauthorized access to the server HP and atsec information security corporation Page 28 of 71

29 5 Storage, Adapters, and Mezzanines In this section, the key security features of components associated with server blades are discussed. In each of these categories, the authors found the devices supported PCI DSS compliant configurations: Storage blades Tape blades BladeSystem interconnects External storage Expansion blades Adapters and mezzanine cards 5.1 Storage Blades Currently there are three storage blade models available from HP for BladeSystem: ProLiant SB460c SAN Gateway Storage Server SB600c All-in-One Storage Blade SB40c Storage Blade Each of the above models are configurable as SAN devices. An administrator first uses Option ROM Configuration for Arrays (ORCA) to configure the first drive in a new server. Then Array Configuration Utility (ACU) can be run as a local application or a remote service to configure the storage. An administrator may alternately use HP Systems Insight Manager to remotely configure storage devices. VC and VCEM may be used to establish SAN connections through SAN fabric options or Server Profiles. While using these tools, administrators must have the storage role assigned to the administrative user to add or modify storage settings. As indicated earlier in this paper, only those administrators needing the storage role should receive this assignment to their profile. In addition to storage and SAN setup and configuration, the following are useful security features available on storage blades. HP Drive Erase is available from ACU as an additional purchased option. The option is driven by GUI or command line to erase the contents of a physical or logical drive with zeros or random 0 s and 1 s. This is a good option available to the administrator in an environment scoped for PCI DSS compliance to ensure CHD or proprietary software/settings are securely erased before reusing storage for other purposes. Selective Storage Presentation (SSP) is available within ACU and determines which host controllers or initiators can access different logical drives on a storage target. The intent of the feature is to prevent data corruption that could occur from different operating systems (on different servers) accessing the same data. As an example, a Microsoft Windows server typically would not access a storage device that is set up with a Linux file system. Best security practice would be to enable SSP across the storage devices used within the CDE to prevent data corruption HP and atsec information security corporation Page 29 of 71

30 5.2 Tape Blades Currently there are two storage blade models available from HP for BladeSystem: HP LTO-5 Ultrium Tape Blade SB3000c (3.0 TB support) HP LTO-4 Ultrium Tape Blade SB1760c (1.6 TB support) The tape blades allow any blade in an enclosure to be backed up to tape onto a tape blade in the same enclosure. The HP Data Protector Express Basic software utility is provided at no additional cost with each tape blade. The software enables backups from a server blade adjacent to the tape blade (to the tape blade). Additional software is required to support network backups. Tape backups can also be driven from multiple software tools including HP Systems Insight Manager, as well as Enterprise Backup Solutions provided from other vendors. Both of the current tape blade models offer AES 256-bit hardware data encryption, enabling data content to be encrypted at the tape head as it is written to tape. This option, along with appropriate key management practices, is highly recommended for card holder data as encryption will prevent unauthorized access to tape cartridge contents. PCI DSS requirements apply to tape access since tapes provide an easy method to store, transport, and retrieve data. Only authorized individuals should have access to tapes, tape hardware, and tape backup software. Processes should be defined and implemented to ensure access restrictions are enforced, thus protecting CHD. These processes should include media handling and protection policies. Some tape backup software (including HP Data Protector Express) can be configured to work with an server to logs and status for tape backup job completions. A consideration for PCI DSS compliance is that this information should be defined as sensitive since it could potentially include server names, IP addresses, and data file/folder names. It is important to restrict the output of the software notifications such that only authorized individuals receive the information. 5.3 BladeSystem Interconnects (Switches and Passthrus) Currently the following classes of interconnects are available for BladeSystem: Ethernet interconnects including: HP ProCurve blade switches HP Ethernet blade switches Cisco Catalyst blade switches Fibre Channel (FC) interconnects Brocade SAN switches Cisco fabric switches InfiniBand Interconnects HP InfiniBand switches HP QLogic InfiniBand switch Passthrus HP 4GB Fibre Channel Passthru module HP 1GB Ethernet Passthru module 2012 HP and atsec information security corporation Page 30 of 71

31 The first three groups (above) of interconnects are switches. The last interconnect group in the list are pass thru modules, which enable direct connection to the mezzanine-installed FC or Ethernet network ports on server blades. The network switches are used to establish connections to/from server blade networking components. It is beyond the scope of this paper to discuss various configurations of network switches. There are multiple methods to configure the switches including the Browser Based Interface (BBI), which is shown below for the HP 10Gb Ethernet BL-c switch. Figure 7: Browser Based Interface for HP BL-c Ethernet Switch There are multiple security features on many of the switches including: Switch function access is protected by required login SSH and SCP (secure copy) access both using secure encrypted tunnels VLAN tags (IEEE 802.1) Authentication and authorization via RADIUS or TACACS+ AAA The following are key PCI DSS [1] related security concepts that apply to the switches and their configuration. Best Practices for Switches and Passthrus Supporting PCI DSS Compliance 1. Determine which access methods will be used (direct login, BBI, CLI, etc.) to 2012 HP and atsec information security corporation Page 31 of 71

32 Best Practices for Switches and Passthrus Supporting PCI DSS Compliance manage and configure the switch. Disable the interfaces which will not be used 2. Passwords (per PCI DSS [1] requirement 8): Change the default administrative password. Maintain passwords per PCI DSS requirements. 1 Establish only the minimal number of administrative accounts needed. For those accounts, establish only the access level needed per the user s administrative role to accomplish their job (per PCI DSS Requirement 7.1.*) a. As an example, on the HP BL-c switch administrators can make permanent configuration changes, but users have read-only access and operators can only make temporary changes that get reset when the switch is rebooted b. Ensure read-level access is only provided to those individuals with a need to know. Network configuration is a prime target for hackers 3. Telnet access is an insecure interface and is not viable for meeting PCI DSS requirements without compensating controls, so it should be disabled 4. SNMP change the default community strings (essentially passwords) for readwrite and read-only to meet the PCI DSS 5. NTP (time settings) should be configured for correctness and consistency per PCI DSS requirement Also the time data should be set to synchronize with designated time servers. HP switches support configuration with an NTP server 6. Optionally, switch ports that are not in use, could be disabled. This method could be used to help reduce the potential for unauthorized network devices (i.e., wireless) to obtain access to the network 5.4 External Storage HP currently supports two blade compatible external storage solutions: HP 6Gb SAS External Storage Solution HP 3Gb SAS External Storage Solution These Serial Attached SCSI (SAS) solutions are intended for installation into either the C3000 or C7000 BladeSystem enclosures. The objective of these solutions is to enable server blades with HP SAS Smart Array controllers to communicate through HP SAS switches to external SAS storage enclosures and tape devices. Configuration of the solutions is accomplished through HP Virtual SAS Manager (VSM), through either a GUI or CLI. The VSM GUI is accessed through the OA application associated with the enclosure where the SAS switch is installed. Since OA has been discussed previously, the security considerations for OA are applicable to the VSM GUI. The VSM CLI is accessed through SSH, thus protecting the interactions through encryption. The authentication requires OA administrator username and password since the CLI is similar to the GUI and uses OA credentials for access. SNMP alerts can be configured. As noted earlier, the default access information should be changed, including community string defaults (passwords). The VSM maintains an event log to record switch and storage enclosure events. A diagnostic log can also be produced, and it includes the event log, topology information, and other diagnostic information. Logs contain configuration information and IP addresses, and should be protected and only be accessible to those individuals needing access to accomplish their job HP and atsec information security corporation Page 32 of 71

33 HP also has external modular storage systems which are rack mountable. These systems include the following: HP 600 Modular Disk System HP 2000sa Modular Smart Array HP MSL2024, MSL4048, and MSL8096 Tape Libraries The list above is not meant to be comprehensive of all HP external storage solutions, and the reader is encouraged to go to the HP website to explore other available products ( The external disk systems have the objective of providing additional disk space and the tape libraries provide backup capabilities. Controls supporting compliance with PCI DSS requirements can be supported while using these devices and their associated management utilities. The security conscious administrator will ensure that default passwords, including SNMP strings, get changed and that only those individuals needing access will have read and/or write administrative control associated with their respective profiles. As noted earlier for tape, it is advisable to use the AES 256-bit tape-head encryption to ensure tapes are fully encrypted. This tape-head encryption feature is available on the three tape library models listed above. It is worth noting the associated HP Secure Key Manager can be used to centralize encryption keys, and this solution is FIPS level 2 validated (certificate #1102). Another feature on the HP tape libraries is the support for HTTPS internet transfer of data over the internet for backups. This ensures encryption of data between the source/target and the HP tape library thus protecting card holder and other sensitive data within locally stored libraries as well as remote storage facilities. 5.5 Adapters and Mezzanine Cards Server blades enable mezzanine adapters, which are installed directly onto the server blade. An example mezzanine card is shown below. Figure 8: HP NC382m PCI Express Dual Port Multifunction Gigabit Server Adapter The classes of mezzanine adapters include: Ethernet adapters 2012 HP and atsec information security corporation Page 33 of 71

34 Multifunction adapter(s) combined Ethernet and TCP/IP offload (TOE), and iscsi boot Fibre Channel HBA adapters Infiniband adapters SAS Mezzanine cards (Smart Array Controllers) FlexFabric adapters when used with FlexFabric module, enables Ethernet, FCoE, and iscsi HP IO Accelerator - solid state storage mezzanine (I/O bus accelerator) These devices supplement server blade hardware and firmware with additional features, primarily for networking. The configuration utilities to setup and maintain these devices have been discussed previously and include OA, VC/VCEM, VSM, ORCA, ACU, as well as HP Insight Manager. PCI DSS compliant settings and recommendations were also previously discussed for the configuration utilities. It is worth a reminder that VC/VCEM can be used to establish server profiles that can be associated with a server blade. Administrators should be aware that a simple physical move of a blade from one slot in an enclosure to another slot may not necessarily migrate the settings associated with that blade and its installed mezzanine components. In some cases the configurations on a server blade and its components may revert back to factory defaults. Hence, careful planning should be done prior to any hardware migrations in order to achieve intended and secure results. When properly planned and executed, a server profile can be established for a new blade slot maintaining the customized settings for the blade and its components, as well as ensuring secure settings are retained, but this needs to be checked after the migration HP and atsec information security corporation Page 34 of 71

35 6 Virtualization Virtualization provides a variety of benefits that many customers are realizing. Chief amongst those benefits is the ability to leverage powerful hardware architectures to support multiple operating system images driven from a single server blade. Many customers are using HP BladeSystems for virtualization for just that purpose to get the most bang for the buck. This paper assumes the reader understands basic computing virtualization concepts where a server blade can be virtualized to host multiple copies of a single operating system, or even virtualized to host multiple operating systems from different vendors (i.e., Windows and Linux). Navigating the PCI DSS V2 [3] says about virtualization: "If virtualization is implemented, all components within the virtual environment will need to be identified and considered in scope for the review, including the individual virtual hosts or devices, guest machines, applications, management interfaces, central management consoles, hypervisors, etc. All intra-host communications and data flows must be identified and documented, as well as those between the virtual component and other system components. The implementation of a virtualized environment must meet the intent of all requirements, such that the virtualized systems can effectively be regarded as separate hardware. For example, there must be a clear segmentation of functions and segregation of networks with different security levels; segmentation should prevent the sharing of production and test/development environments; the virtual configuration must be secured such that vulnerabilities in one function cannot impact the security of other functions; and attached devices, such as USB/serial devices, should not be accessible by all virtual instances. Additionally, all virtual management interface protocols should be included in system documentation, and roles and permissions should be defined for managing virtual networks and virtual system components. Virtualization platforms must have the ability to enforce separation of duties and least privilege, to separate virtual network management from virtual server management. Special care is also needed when implementing authentication controls to ensure that users authenticate to the proper virtual system components, and distinguish between the guest VMs (virtual machines) and the hypervisor." In June of 2011, the PCI SSC published version 2 of an information supplement which provides guidelines to those using, implementing, or assessing a virtualization in a PCI DSS compliant environment [7]. The guidelines provide insights into some of the specific issues related to virtualization. The document discusses and enumerates several risks that ought to be considered in such an environment and provides recommendations that should be considered by implementers of virtualization. The risks include: Physical environment vulnerabilities apply in a virtual environment New attack surface created by hypervisor Increased complexity of virtualized networks and systems Having more than one function per physical system Mixing VMs of different trust levels Lack of separation of duties Dorman virtual machines 2012 HP and atsec information security corporation Page 35 of 71

36 VM snapshots and images Immaturity of monitoring solutions Information leakage between virtual components Information leakage between virtual network segments 6.1 PCI SSC Recommendations Evaluate risks associated with virtual technologies Risks associated with virtualizing system components should be carefully evaluated before selecting or implementing a virtualization solution. Accurate documentation of the flow and storage of cardholder data must be maintained to ensure that all risk areas are identified and mitigated. Virtualization should be used with an understanding of its risks, as well as its benefits and a complete, defined set of system, application, data, and environmental controls. Virtualized environments and system components should be included in the annual riskassessment process. Comprehensive documentation of risk evaluation and management decisions should be kept and supported by business and technical evaluations Understand impact of virtualization to scope of the CDE Entities may now find that they have a complex set of virtual system configurations when using virtualization to consolidate their environment onto one or more physical hardware platforms, which makes it difficult to identify the boundaries or scope of their CDE. The scope of PCI DSS across virtual components must be thoroughly documented and verified, just as with physical systems. The Scope of Assessment for Compliance with PCI DSS Requirements section of the PCI DSS should be used to evaluate the virtual environment. As a recommendation, if any components running on a single hypervisor are in scope, then all components on that hypervisor should be considered in-scope as well. This includes virtual machines, virtual appliances, hypervisor plug-ins, etc. Designing all virtualization components, including those considered out-of-scope, to meet PCI DSS security requirements will provide a secure baseline for the virtual environment, as well as reduce the complexity and risk associated with managing multiple security profiles. This will also lower the overhead and effort required to validate and maintain compliance Restrict physical access Multiple components being hosted on one physical system could increase the potential impact greatly, if an attacker gains physical access to that host system. Therefore, physical access controls are incredibly important in virtualized environments and should be strengthened to mitigate the associated risks. Consider the potential harm of an unauthorized or malicious individual gaining simultaneous access to all networks, VMs, applications, security devices, and hypervisors when assessing physical controls. All unused physical interfaces must be disabled and physical and console-level access monitored and restricted Implement defense in depth A defense-in-depth approach that contains preventive, detective and responsive controls is a best practice in a physical environment, for securing data and other assets. Logical security controls are usually applied at the host, network, application and data layer and physical security controls are used to protect media, systems and facilities from unauthorized physical access. Monitoring the controls and the capacity to respond to a potential breach quickly and effectively are also of great importance. A defense-in-depth approach also includes educating 2012 HP and atsec information security corporation Page 36 of 71

37 and training personnel in the correct use of sensitive assets, identifying potential security threats, and the appropriate action in the event of a breach. A defense-in-depth environment also has a well documented and defined policies, processes and procedures that are known and followed by all personnel. Security controls that provide the same level and depth of security in a physical environment should be identified and implemented in a virtualized environment. Consider how security can be used to protect with layer (i.e., host platform, physical device, hypervisor, application, VMs, perimeter network, intra-host network, etc.). Documented policies and procedures, training of personnel, as well as physical controls should all be a part of a defense-in-depth approach to securing virtual environments Isolate security functions The same process required in the physical world must be implemented for the security functions provided by VMs. It is recommended that this is stringently enforced in virtualized systems because it considerably complicates an attacker s efforts to compromise multiple CDE system components. For example, a network firewall, or other preventive controls, should never be combined on a single logical host with the payment card data it is put in place to protect. Also, log aggregation functions that detect tampering of network segmentation controls and processes that control network segmentation should not be mixed. If they are, the level of isolation between security functions should be such that they can be considered as being installed on separate machines Enforce least privilege and separation of duties Accounts and credentials for administrative access to the hypervisor should be closely controlled. The use of more restrictive hypervisor access controls is often justified, depending on the level of risk. Additional methods should also be considered for securing administrative access. Examples could be two-factor authentication or establishing split-control of passwords between multiple administrators. For both local and remote access to the hypervisor and management system, access controls should be assessed. Functions of the individual virtual components should be given particular attention to ensure that appropriate role-based access controls (RBAC) are in place which would prevent unnecessary access to resources and enforce separation of duties. Administrative privileges also must be separated appropriately. For example, a single-user administrator should not have privileged access to firewalls and monitoring servers for those firewalls. Such access could result in undetected tampering and data loss that could have been prevented if separation of duties was enforced. As a best practice, restrict administrative access by specific VM function, virtual network, hypervisor, application, hardware, and data store Evaluate hypervisor technologies The security of the hypervisor must be thoroughly tested prior to deployment. There should also be appropriate patch management and other controls to respond to exploits and threats. Not all hypervisors or VMs have the functionality to support appropriate security controls, so identifying and implementing technologies that facilitate strong security practices is critical Harden the hypervisor Hypervisor platforms should be deployed in a secure manner according to security guidelines and industry-accepted best practices. Virtual system configurations, patching, and changecontrol processes much be carefully managed to ensure that all hypervisor changes are authorized, tested, and carefully controlled. Whenever new security vulnerabilities are 2012 HP and atsec information security corporation Page 37 of 71

38 discovered, it is essential to deploy patches and other mitigating controls and immediately test for the vulnerability to confirm that the risk has been addressed. The hypervisor represents a single point of failure so a malicious or unauthorized change could threaten the integrity of all hosted systems in the environment. These additional controls are recommended for the hypervisor, as well as significant management tools: Restricted use of administrative functions to endpoint networks and devices (laptops, desktops, etc.) that have been approved for such access Required multi-factor authentication for all administrative functions All changes are implemented and tested properly Administrative functions are separated so that hypervisor administrators cannot modify, delete, or disable hypervisor audit logs Hypervisor logs are sent as quickly as possible to separate and secure storage Audit logs are monitored to identify activities that could indicate a breach in the integrity of segmentation, security controls, or communication channels between workloads Security controls are verified before implementing a virtualization solution to ensure it would minimize the risk of compromise to the hypervisor Harden virtual machines and other components Requirements for security and hardening may differ depending on the specific services or applications running on each virtual component. This means that the appropriate security settings will need to be individually determined. It is also incredibly important that all individual machines are installed and configured securely according to security guidelines and best practices. The recommendations above for hardening the hypervisor are also applicable to VMs and virtual components. Please note that these recommendations may not be applicable for all types of virtual machines or components and implementations should be evaluated to make sure that the following has been considered: All unnecessary interfaces, ports, devices and services are disabled or removed All virtual network interfaces and storage areas are securely configured Limits are established on VM resource usage All operating systems and applications running side the virtual machine are hardened Logs are sent to separate, secured storage as quickly as possible The integrity of the cryptographic key management operations is validated The individual VM virtual hardware and containers are hardened Other security controls as applicable Define appropriate use of management tools Administrators perform such functions as system back-up, restore, remote connectivity, migration, and configuration changes to virtual systems by using management tools. Access to management tools should be limited to job-related needs. It is recommended to segregate roles and responsibilities for management tool functions and their usage should be monitored and logged HP and atsec information security corporation Page 38 of 71

39 Clearly define all hosted virtual services Shared hosting providers sometimes virtualize their offerings, provisioning separate workloads to customers instead of provisioning separate physical systems. Entities thinking about a hosted virtual service should ensure that the offering service enforces process, administrative, and technical segmentation to isolate each hosted entity s environment from other entities. At a minimum, this isolation should include all controls supporting PCI DSS requirements, including segmented authentication, encryption and logging, and network and access controls. It is also critical to ensure that all details of the service are clearly defined and documented in a formal agreement, especially those including responsibilities for maintaining controls which could affect the integrity or security of data or impact PCI DSS compliance Understand the technology Traditional physical environments are very different from virtualized environments and a thorough understanding of virtualization technologies is needed to effectively evaluate and secure any environment. If there are no formal virtualization security standards, entities should familiarize themselves with industry best practices and guidelines for securing virtualized environments. Some helpful resources that may provide guidance include publications from: The Center for Internet Security (CIS) SysAdmin Audit Network Security (SANS) Institute National Institute of Standards Technology (NIST) ISACA (formerly the Information Systems Audit and Control Association) International Organization for Standardization (ISO) 6.2 Recommendations for Mixed-Mode Environments It is recommended that VMs of different security levels are not hosted on the same hypervisor or physical host. A VM with lower security requirements will have lesser security controls, which then could be attacked and provide access to more sensitive VMs on the same system. This notion should also be applied if in-scope and out-of-scope virtual systems are to be located on the same hypervisor or host. As a general rule, any VM or other virtual component that is hosted on the same hypervisor or hardware as an in-scope component would also be in scope for PCI DSS. This is because the hypervisor and underlying host both provide either a physical or logical connection, or both between the virtual components. It may not be possible to achieve an appropriate level of segmentation or isolation between in-scope and out-of-scope components located on the same hypervisor or host. Any hypervisor or host system that houses an in-scope virtual component is also in scope for PCI DSS. VMs must be isolated from each other so that they can be regarded as separate hardware on different network segments with no connectivity to each other in order for inscope and out-of-scope VMs to co-exist on the same hypervisor or host. System components shared by the VMs must not provide an access path between the VMs. If adequate segmentation between virtual components was achieved, the resource effort and administrative overhead required to enforce the segmentation and maintain security levels would still most likely be more burdensome than applying PCI DSS controls to the system as a whole HP and atsec information security corporation Page 39 of 71

40 6.2.1 Segmentation in mixed-mode environments For in-scope and out-of-scope systems on the same host, the level of segmentation must be equal to a level of isolation achievable in the physical world; meaning that segmentation must ensure that out-of-scope workloads or components can t be used to access in-scope components. Network-based segmentation, unlike separate physical systems, cannot isolate in-scope from out-of-scope components by itself in a virtual environment. Segmentation of virtual components must be applied to all virtual communication mechanisms as well, including the hypervisor and underlying host, as well as any other common or shared component. Out-of-band communications can off in virtual environments often via a solution-specific communication mechanism, or through the use of file systems, processors, device drivers, APIs, and other shared resources. Knowledge and understanding of all underlying mechanisms is critical when planning to segment virtual components because out-of-band communication channels are generally specific to the virtualization technology in use. Whether out-of-band channels are actively being used or not, all should be documented and identified and appropriate controls implemented to isolate workloads and virtual components. Physical separation of hardware resources may even be required to prevent hardware from being used as an access path between virtual components, in some instances. Please note that out-of-band channels are often required for specific virtual system functions and is to isolate components from these channels without impacting system operations can be impossible. If it is not workable for an implementation to enforce isolation of in-scope components from out-of-scope components via shared resources or other out-of-band channels, all components accessing such channels should be considered in scope because they are effectively connected to the in-scope component. Process isolation is also an inherent part of segmentation between virtual systems. They hypervisor plays a critical role in enforcing process isolation between the in-scope and out-ofscope systems in a mixed-mode configuration. Therefore, it is critical that these controls are properly functioning and that access to hypervisor functions that could affect these controls is closely monitored and controlled. 6.3 Virtualization in HP BladeSystem Virtualization refers to the logical abstraction of computing resources from physical constraints. Virtualization can be applied to different types of resources, including the physical machines, operating systems, networks, memory and storage. One key item in a successful assessment of a virtualized environment is to be prepared. The following list gives the PCI SSC guidelines for information that helps you understand the virtual environment: Identify all virtualized components, including hypervisors, workloads, hosts, networks, management consoles and other components The physical site details for each component Know the primary functions and assigned owners for each component Understand the details of visibility into and between components Document traffic flows between different components, between components and hypervisors, and between components and underlying host systems or hardware resources should be identified. Especially important is to include the data flows for card holder data 2012 HP and atsec information security corporation Page 40 of 71

41 Identify all intra-host communications and data flows, as well as those between virtual components and other system components Identify all out-of-band communication channels (whether configured to operate or not) that could allow communications between components Maintain details of all management interfaces and hypervisor access mechanisms, including defined roles and permissions Document all virtual and physical hardware components such as removable disk drives and USB, parallel, and serial ports Have details of the number and types of virtual components on each host, types of segmentation between components and hosts, functions and security levels of all virtualized components, etc. Further information on HP tools to deploy and manage virtualized infrastructures is published by HP [36]. HP also has many white papers written on the topic of BladeSystems [9] Virtual machines (VM) One common abstraction is referred to as a virtual machine (VM), which is a software implementation of a physical machine and allows a particular machine to be emulated on different physical hardware. This may include presenting several virtual machines on the same physical hardware, and in this case may include several identical or different virtual machines. Note that according to the PCI SSC virtualization guidelines [7] configuring virtual machines has some repercussions on the scope of a PCI DSS assessment. These are enumerated in section Operating system Operating system (OS) virtualization is normally used to separate the resources running on a single physical server into smaller, multiple partitions, such as virtual environments, virtual private servers, guests, zones, etc. In this common scenario, all partitions would be using the same underlying OS kernel, meaning they would be running the same operating system as the base system, but they could also be running different distributions, libraries, etc. Similarly, application virtualization separates the underlying operating system from the individual instances of an application, which in turn provides a discrete workspace for each user Hardware/platform Hardware virtualization is achieved through hardware partitioning or hypervisor technology. Mediation for all hardware access for the VMs running on the physical platform is done by the hypervisor. There are two types of hardware virtualization: Type 1 Hypervisor: also known as native or bare metal, is a piece of software or firmware that directly runs on the hardware and coordinates access to hardware resources, as well as managing and hosting VMs Type 2 Hypervisor: also known as hosted, runs on an existing operating system as an application. This emulates the physical resources required by each VM and is considered by the OS to be just another application 2012 HP and atsec information security corporation Page 41 of 71

42 6.3.4 Network and storage When connecting server blades to your network, there were traditionally two basic interconnect choices pass-thrus and switches. Pass-thrus are simple but require too many cables and create complexity. Blade switches reduce the number of cables but add more for LAN and SAN administrators to manage. In both cases, multiple people are needed to perform very simple server tasks. HP offers a third choice HP Virtual Connect, which reduces both cabling and management Network Network virtualization differentiates physical from logical networking. For almost every type of physical networking component (i.e., switches, routers, firewalls, load balancers, etc.), there is a logical counterpart available as a virtual appliance. Dissimilar to standalone hosts (such as a workstation or server), network devices operate across the following logical planes: Control Plane: manages traffic, network, and routing information Data Plane: forwards data communications on the network between hosts Management Plane: handles direct communications in the device for device management purposes (i.e., monitoring, configuration, and maintenance) Data storage Virtualized data storage happens when multiple physical storage devices on a network are combined as a single storage device. This consolidation is used in storage area networks (SANs). A benefit of virtualized storage is that the complexity of the infrastructure is hidden and out of the user s sight. This can also present a problem though, for entities that are trying to document and manage their stored data because a particular set of data may be stored across numerous distributed locations at any given time Memory Memory virtualization creates a virtualized pool of memory by consolidating available physical memory from multiple individual systems, which is then shared among system components. The consolidation of multiple physical memory resources into a single virtual resource is similar to virtualized data storage in such a way as it can add complex levels regarding mapping and documenting data locations HP and atsec information security corporation Page 42 of 71

43 7 Encryption and Key Management A key tenet of PCI DSS compliance is "Protect Card Holder Data." This requirement considers that: "Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person." (Navigating the PCI DSS V 2 [3]) The PCI glossary describes strong encryption as: Strong Cryptography - Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or one way ). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication for more information on industry accepted strong cryptography. Earlier versions of OA supported only SSL V2, but since firmware release 2.50 SSL version 3 + TLS is supported. ilo version 2 and 3 use AES encryption, ilo 3 introduced hardware based AES encryption for remote console support, according to the HP Integrated Lights-Out security: technology brief. "The ilo management processor uses 128-bit SSL and SSH frameworks to ensure ilo privacy actions depending on the access modes and types of functions being performed. Within these frameworks, various ciphers can be used for encrypting network traffic. The purpose of a cipher is to make data private so that only parties to the cipher and keys can read the data. The frameworks allow cipher negotiation and secure exchange of keys used to initiate encrypted communication within the cipher algorithm. ilo supports RC4, 3DES, and AES ciphers for encrypting network traffic. Key exchange uses RSA/Diffie-Hellman, and keys are rotated every 3 minutes. Certificates are generated by ilo using 1024-bit RSA keys signed with MD5RSA and using a SHA1 fingerprint. Secure sockets layer (SSL) The ilo management processor encrypts all web pages using 128-bit SSL encryption. This ensures that all information and commands issued through the web browser are private. SSL allows the client (browser) and server (ilo) to compare a list of ciphers. Generally, they negotiate to use the strongest common cipher. A client may include a long list of ciphers, but ilo 2 v1.30 and ilo 3 can restrict the cipher list if desired. AES encryption ilo 2 v1.30 and ilo 3 can restrict ciphers to AES/3DES using browser settings (through the Global Settings page), XML scripting, or SM CLI. The following is a complete list of communication operations that can employ AES encryption: Web browser (UI) The current Mozilla browser, Firefox 2, supports AES Encryption. Internet Explorer 7 is the first Microsoft browser that supports AES encryption. LOCFG/XML A command line switch that lets you select AES encryption and the cipher strength. SSH You can initiate AES sessions with OpenSSH in Linux or PuTTY HP and atsec information security corporation Page 43 of 71

44 LDAP An outbound method of communication where ilo provides client-side communication and the LDAP server provides server-side communication. The web browser, XML, and SSH support popular AES cipher strengths." 7.1 Key Management The private keys for SLL, ilo, VC, etc. are managed within the modules and are kept in a key store that is inaccessible to system users. The TPM can also play a role in protecting keys for blades. All device key management is handled automatically by the various devices and management modules. Therefore there is no need for external key management for the keys for embedded devices. See NIST Special Publication for more information on industry accepted key management techniques HP and atsec information security corporation Page 44 of 71

45 8 Security Assurance Certifications in the BladeSystem Environment Security has been a central focus in the development of BladeSystem. One way to independently verify this statement is to look at the various assurance certifications that have been awarded. In this section of the report, the certifications associated with HP BladeSystem are listed. These certifications support the claim that BladeSystem and associated products are secure, and that these systems can be used to develop a PCI DSScompliant configuration. 8.1 Common Criteria The evaluation of technical components and products against internationally-accepted, standardized criteria allows companies to objectively demonstrate the reliability of security functionality. HP has achieved Common Criteria evaluations for other products in the recent past. HP currently has no Common Criteria certifications for the HP BladeSystem and related components. HP is currently in the process of Common Criteria certifications for products in this area as shown in the Communications Security Establishment Canada Products in Evaluation list. Specifically the following Common Criteria certification is in progress: HP BladeSystem c7000 and c3000 Enclosure with Onboard Administrator (running firmware version 3.6), Virtual Connect (running firmware version 3.7), and HP Integrated Lights-Out (version 1.5) - for EAL 4+ Through discussions with HP personnel involved in the ongoing certification (in November 2011), it was forecasted the firmware versions could change to newer versions. It is beyond the scope of this report to perform a detailed analysis of every potential guest operating system. However, note that many of the security features of several guest operating systems have undergone Common Criteria evaluation and certification and are reported on the Common Criteria Portal. These include: Hewlett Packard HP UX-11i v3 Itanium-based HP Integrity servers Red Hat Enterprise Linux Version 5 Intel Xeon (HP DL360) Intel Xeon EM64T (HP DL360) - dualcore Intel Xeon EM64T (HP DL360) - singlecore AMD Opteron (HP DL 385) singlecore AMD Opteron (HP DL 385) - dualcore AMD Opteron (HP DL 145) - singlecore Intel Itanium 2 (rx 3600) dualcore Intel Itanium 2 (rx 2620) singlecore Red Hat Enterprise Linux AS, Version 3 Update 3 HP AMD Opteron processor based servers: 2012 HP and atsec information security corporation Page 45 of 71

46 HP Proliant DL product line HP Intel Pentium and Xeon processor based servers: HP Proliant DL product line (except AMD based systems) HP Proliant ML product line HP Proliant BL product line HP Intel Itanium2 processor based servers: HP Integrity Superdome product line 8.2 FIPS FIPS is a specification published by National Institute of Standards and Technology (NIST). It is a conformance standard mandatory for any cryptography used by the U.S. Federal Government. HP currently has no FIPS certifications for the HP BladeSystem and related components. HP is currently in the process of FIPS certifications for products in this area as shown in the NIST Modules in Progress status page. 2 Specifically the following FIPS compliance testing projects are in progress: BladeSystem Virtual Connect BladeSystem Onboard Administrator For the potential guest operating systems some FIPS certifications are already made for example the Red Hat Enterprise Linux 5 OpenSSL Cryptographic Module is validated to FIPS certificate # It has been noted through a recent NIST announcement that the NIST Modules in Progress webpage may not be posted or maintained by NIST in the future HP and atsec information security corporation Page 46 of 71

47 9 PCI DSS Requirements in a BladeSystem and VC Environment This chapter describes in more detail the assessment options that a QSA can consider in a BladeSystem and VC environment. The relevant scoping issues are discussed and each PCI DSS requirement is described with respect to the environment. In summary, BladeSystem and VC/VCEM enable support for all PCI DSS requirements. The reader is also encouraged to refer back to Best Practices highlights for different technologies discussed in previous sections. 9.1 Scoping and Scope Reduction The scope of a PCI DSS assessment is a very important issue for consideration by the QSA. On the one hand, it is important to keep the scope as small as possible. A small scope will naturally reduce costs and effort by both the QSA and the subject organization. By combining the narrowest valid scope with the controls specified by the PCI DSS and the organization under assessment, the attack surface can be reduced -- thus making the environment more secure. On the other hand, it is vital for the QSA to accurately define the cardholder data environment as that part of the network that stores, processes, or transmits cardholder or sensitive authentication data. The PCI DSS requirements are applicable to all network components, servers, or applications that are within this cardholder data defined portion of the network Virtual machines As already mentioned in section 6.3.1, according to the PCI SSC virtualization guidelines [7] the configuration of virtual machines may have some repercussions on the scope of a PCI DSS assessment. Specifically if a VM is involved in any way with storing, processing or transmitting cardholder data, or if it connects to or provides an entry to the CDE Card Holder data environment then the whole VM, the hypervisor, and the underlying host system are in scope. The BladeSystem can have multiple blades in one chassis/enclosure whose network/storage connections may be physically and/or logically separated from each other by VC. The VC configuration includes routes from the uplink port to the specific NIC port on a specific server bay. This fact may support an argument in regard to the PCI DSS requirement that requires "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.)" However this requirement is interpreted by QSAs with different degrees of rigor. Encryption facilities with appropriate key management can be used to reduce the scope of PCI DSS compliance. This has already been discussed in section 7, Encryption and Key Management 9.2 PCI DSS Control Objectives in Detail This section will discuss the PCI DSS requirements in more detail, focusing only where requirements may be addressed with special context to HP BladeSystem by a QSA. It is beyond the scope of this report to address specific details of every system s components, but rather, this section will introduce some general concepts that can be extrapolated by QSAs to the HP BladeSystem they are assessing. The following sections do not list each and every PCI DSS requirement, but only notes those which are pertinent HP and atsec information security corporation Page 47 of 71

48 Build and maintain a secure network Requirement 1. Install and maintain a firewall configuration to protect cardholder data. The intent of this requirement is to protect systems within the cardholder data environment from unauthorized access from untrusted networks regardless of the path taken to obtain access. The standard identifies that firewalls are a key protection mechanism to achieve this for any network. This also applies to BladeSystem environments. An important concept to understand is that although the term firewall is used in the standard, any technology providing appropriate restriction of unwanted traffic is applicable including VLANs which are supported in HP switches and VC/VCEM. The PCI SSC updated the standards to explicitly include routers, but other technologies used can be included in the assurance discussion. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 1.1 Establish firewall and router configuration standards. No special considerations in a BladeSystem environment 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. Some BladeSystem configuration utilities such as OA allow telnet as an interface. This interface is a known insecure method and should be disabled in each of the configuration utilities where it is supported. 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. As noted above, VC support VLANS, which can be further configured with the Private Network feature to restrict network traffic between hosts and/or networks. With a set of VLAN definitions on the HP BladeSystem, one could implement above and beyond controls to supplement firewall and DMZ configuration. As a reminder VC VLANs are discussed in chapter 3 section Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks. As discussed above, HP switches and VC can be used to establish VLANs to segregate CHD on some server blades or storage blades from other blade components. A VC VLAN only shares network traffic with another VC VLAN if explicitly configured to accomplish the sharing. As a reminder VC VLANs are maintained within VC and the VC VLAN characteristics are not shared outside of VC. This configuration was discussed in chapter 3, section Do not disclose private IP addresses and routing information to unauthorized parties. VC and other HP BladeSystem configuration utilities implement tiered roles for system administrators, providing only those capabilities needed to accomplish the 2012 HP and atsec information security corporation Page 48 of 71

49 job. All configuration utilities for BladeSystem require authentication, allowing privacy of configuration to be retained and only given to system administrators. In addition, one would expect to find NAT or similar mechanism implemented outside the BladeSystem at the CDE firewall. Requirement 2. Do not use vendor-supplied defaults for system passwords and other security parameters. The objective of this requirement is to ensure default passwords are changed to prevent unauthorized access. Also the requirement ensures secure services are used and that insecure services are disabled. BladeSystem and associated management utilities support this requirement because default passwords can be changed easily (during initial setup), and also secure services such as SSL can be established for interaction with VC, OA, and ilo, as well as other utilities. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 2.1 Attempt to log on with default passwords to system components and servers. The default passwords for VC, ilo, OA, and related configuration utilities should be changed as part of standard security best practices. Default SNMP community strings should also be changed For wireless environments connected to the cardholder data environment... BladeSystem components do not natively support wireless, so this requirement is not applicable with respect to BladeSystem components. 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. VC and VCEM allow administrators to define profiles to apply to installed components including server blades. These profiles could be used as templates for configuration standards as applied within a datacenter. One would also expect to find documentation supporting the defined profiles Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. Server blades are segregated from each other physically. Although they can occupy the same enclosure, CPUs and processing (cycles) are not shared between server blades. Thus implementing one function per server is simply dedicating a server blade to a single role such as web server, database server, etc. In this example, multiple server blades in an enclosure can each be setup and dedicated to individualized functions 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 HP and atsec information security corporation Page 49 of 71

50 VC and related utilities support PCI controls for this requirement. Telnet is insecure and should be disabled. For OA, ensure telnet is disabled, SSH is enabled, and SHTTP is enabled. Similar settings should be established on other utilities including switch management Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. VC and OA management interfaces could be disabled if not needed, although since it is challenging to maintain a server blades enclosure without them an argument that these interfaces are not needed is rare. ilo Virtual Media and Virtual Folder are optional and could be disabled when not in use. Selectively disable services that are not used within ilo (such as IPMI over LAN if unused). Disable remote console for ilo if unused. PXE boot within VC/VCEM should be disabled if unused. 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. Server blade management utilities including VC/VCEM, OA, and ilo support this requirement. For OA, both SSH and HTTPS should be used for secure connectivity, and other best practices as noted in section For ilo, SSL is used for secured connections to directory server. Also for ilo, SSL encryption of HTTP data should be set to one of the strong ciphers such as 256-bit AES. For VC/VCEM, SSL should be used with the Strong SSL ciphers setting. Similar settings should be used for other utilities including the BBI for managing switches. Protect cardholder data Requirement 3. Protect stored cardholder data. The intent of this requirement is to ensure CHD is unreadable during storage. BladeSystem supports this requirement through encryption technologies as noted in the requirements (below). To a large extent, VC, OA, and ilo do not have access to system resources where CHD is stored (temporarily or permanently). HP tape systems are one notable exception, and in this case strong encryption is available to ensure entire tape contents are unreadable. Data erasure can be accomplished through HP Drive Erase for disk drives, and commercial degaussers for tape. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) Implement a data retention and disposal policy that includes: Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements. Processes for secure deletion of data when no longer needed Specific retention requirements for cardholder data A quarterly automatic or manual process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements VC, OA, and ilo do not have CHD access or storage. Storage blades (with hard disks) support HP Drive Erase (available from ACU) 2012 HP and atsec information security corporation Page 50 of 71

51 which can be used to erase contents of associated disk drives. HP Drive Erase will overwrite all file contents and all metadata including RAID, partition, and file system metadata. For tape blades, commercial degausser units are probably best for bulk tape erasure prior to all backups to ensure the tape contents including the tail end of the tape is erased. For disk storage solutions - HP SAS External Storage Solutions and HP external modular storage solutions, HP Drive erase is available for Smart Array controlled drives as mentioned above. For HP Tape Blades and HP External Modular storage solutions which are tape-based, a commercial degausser is the best method to do bulk tape erasures. For permanent media disposal, commercial solutions or services can be used to destroy disks and tapes where CHD was stored. 3.2 Do not store sensitive authentication data after authorization (even if encrypted). There are no special considerations for server blades or associated components. This requirement is most pertinent to payment processing applications. 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). The masking methods used will be pertinent to the O.S. and applications on the server blades. VC, OA, and ilo do not have CHD access. Similarly other HP management utilities do not display PAN data. 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches VC, OA, and ilo do not have CHD access. Similarly other HP management utilities do not have PAN access or storage. Hence log data for these utilities will not include PANs or other CHD. For disk storage, the encryption methods will be pertinent to the O.S. and applications on the server blades. For tape storage including HP Tape Blades and HP External Modular storage solutions which are tape-based, the AES 256-bit hardware-based data encryption option should be used to encrypt tape contents for all PCI data. 3.5 Protect any keys used to secure cardholder data against disclosure and misuse. As noted in 3.4 above this is primarily applicable tape storage solutions. The tape encryption keys will need to be protected procedurally as well as protection of storage locations for keys. Certificates for SSL and SSH as used in management utilities also need to be protected and properly managed, in particular for VC/VCEM, OA, and ilo. The HP Secure Key Manager can be used to centralize and manage encryption keys where appropriate. The solution is FIPS level 2 validated (certificate #1102) HP and atsec information security corporation Page 51 of 71

52 Requirement 4. Encrypt transmission of cardholder data across open, public networks. The intent of this requirement is to prevent disclosure of sensitive information from malicious individuals. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 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. VC, OA, and ilo are not directly involved in application-level or network-level data transmission and have no direct access to CHD. Encryption methods are available and should be used for each utility while managing BladeSystem enclosures. CHD transactions using server blades and related components will rely on application-level encryption methods and there are no special considerations for BladeSystem. Tape backups across the network should only be accomplished within the DMZ containing the CDE, and backups specifically should not be done over public networks. Once the data is streamed to the tape backup unit, encryption of the data to tape should be accomplished Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices There are no special considerations for BladeSystem components since none of them include wireless capabilities natively. Maintain a vulnerability management program Requirement 5. Use and regularly update anti-virus software on all systems commonly affected by malware. This anti-virus requirement has no special consideration for BladeSystem since the requirement is pertinent to O.S.-level operations (Microsoft Windows, Linux, etc.). Customers and reviewers should be aware that the requirement applies wherever CHD is handled including off-blade disks including storage blades and disk arrays which may be file-shared or may provide network-bootable images. Requirement 6. Develop and maintain secure systems and applications. Vendor provided security patches are the main focus for this requirement as applied to BladeSystem. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. This requirement applies to system firmware on BladeSystem components such as VC, ilo, and OA; and also to software updates as applicable to management utilities such as VCEM, HP Insight Manager, and HP Data Protector Express. Known current vulnerabilities for BladeSystem and components was covered in section 3.7 of this whitepaper. The HP weblinks in 2012 HP and atsec information security corporation Page 52 of 71

53 section 3.7 provides access to the most recent updates. VC, OA, and ilo updates from HP are digitally signed and each component validates proper signature from HP before updating itself. BladeSystem hardware components have no known vulnerabilities (currently). For this requirement, it is also important to subscribe to an alerting service which will track and inform of new vulnerabilities that are applicable to HP components in the datacenter Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers. If custom but temporary administrator accounts are established for management utilities such as VC/VCEM, OA, or ilo, these accounts and/or passwords should be purged before moving the hardware into production Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability. For VC/VCEM, there can be quite a bit of customization established for server blade profiles and/or network settings. These customizations should be reviewed to ensure desired consequences are achieved when moving new components from test/staging into production Separate development/test and production environments. For BladeSystem, separation of one server blade from another can easily be achieved within the same enclosure. VC profiles with unique VLAN IDs can be assigned to each blade server network port to accomplish this. VC only shares network traffic between ports that are explicitly configured for the same. Furthermore, VC Network Access Groups and Private LAN features can further isolate traffic and ensure that VLANs requiring separation (i.e., no common uplinks) are kept isolated. In this example, network sharing is not a default configuration but must be explicitly setup. Hence one BladeSystem enclosure could be used to host both development/test and production environments established on different VLANs. A server blade could be staged in test using one profile, then assigned a new server blade profile from VC as the server is put into production Change control procedures for the implementation of security patches and software modifications. As mentioned in (just above), change control procedures for BladeSystem could include the use of server blade profiles. It is important to test the impact of new firmware or management software updates before putting them into production. VC/VCEM could be used for isolating a BladeSystem component to test impact, prior to moving that updated component into production. This would best be achieved with server blade profiles to establish a test configuration and a production configuration. VC or switch VLAN segregation can also be used in a similar manner to stage testing prior to production. Implement strong access control measures Requirement 7. Restrict access to cardholder data by business need-to-know HP and atsec information security corporation Page 53 of 71

54 The intent of this requirement is to reduce access to critical data to only those individuals needing access to accomplish their job. Access privileges should provide the least amount of privilege needed to perform the individual s job role. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 7.1.* Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations including: Restriction of access rights to privileged user IDs to least privileges necessary Assignment of privileges is based on individual personnel s job classification VC/VCEM, OA, and ilo each support multiple login IDs, enabling support of these requirements so that unique login IDs could be assigned to different individuals based on access needs. Other BladeSystem utilities such as BBI (for blade switch management) have similar support. Utilities such as VSM (SAS management) rely on authentication through OA, providing multiple login ID support inherited from OA. VC/VCEM and ilo support roles associated with different features. VC/VCEM supports four different roles as explained in section , which can be assigned depending on an individual s roles as an administrator. Tape backup is often a role assigned to dedicated administrators. In this case, the tape administrators may be given access to tape backup software/media but would not be given access to other management utilities. The size of the datacenter and the media backup procedures would drive this type of role assignment. For tape backup software, HP Data Protector Media Operations supports multiple administrators with unique IDs. The software also supports several role types based on expected functions the administrator will accomplish. For other enterprise tape backup software solutions from other vendors, they may also provide unique ID/role configurations for different administrators Ensure Implementation of an automated access control system. This PCI requirement does not dictate the level of granularity required for the automated access control. Some customers implement automated access controls at the CDE network level, requiring two-factor VPN login to access the CDE network. In this case subsequent logins to servers, network equipment, or systems management utilities might not be controlled by an automated system. For BladeSystem utilities, the following automated access control systems are supported: VC/VCEM LDAP/Active Directory, RADIUS, TACACS OA LDAP/Active Directory ilo LDAP/Active Directory, Novell e-directory BBI (switch mgmt) RADIUS, TACACS+ These access control integration features enable configuration of the BladeSystem utilities with popular access control methods. As an example, when properly configured, authentication to VC would rely on LDAP (or other) authentication. These authentication methods provided by the HP utilities provide direct support for this PCI requirement HP and atsec information security corporation Page 54 of 71

55 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 Coverage of all system components Assignment of privileges to individuals based on job classification and function Default deny-all setting HP BladeSystem provides direct support enabling compliance with this PCI requirement. For HP BladeSystem components require authentication to enable access to the utility (VC/VCEM, etc.) and subsequent access to the component settings for all system components. For As discussed previously, the BladeSystem configuration utilities support privilege assignments based on functions that are needed to conduct an individual s job role. Specifically for VC there are four privilege types: Domain management (covering a single enclosure) Network settings management within a domain Server profile creation, deletion, and updating Storage connection management These privilege types allow assignment of specific privileges associated with an administrator s role(s). Similar settings (different granularities) can be found on the other utilities for BladeSystem. For Once the initial default password is changed on any of the management utilities (VC/VCEM, etc), this effectively serves as a deny-all setting by blocking all unauthorized access to the BladeSystem component utilities since each utility requires authentication to provide access. As noted in PCI #2.1 (a few pages earlier), default passwords should be changed on all BladeSystem utilities. Also, SNMP community string defaults should also be changed to serve as a deny-all setting. Requirement 8. Assign a unique ID to each person with computer access. The intent of this requirement is to ensure no shared IDs are used to access the CDE and associated equipment. When the correct logging is in place, this allows any forensics to be traced to known and authorized users to determine who made changes and when they were made. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 8.1 Assign all users a unique ID before allowing them to access system components or cardholder data. 8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users ( two-factor methods outlined). For 8.1 see the discussion for 7.1 on the previous page. In summary, VC/VCEM, OA, and ilo each support multiple login IDs, enabling support of these requirements so that unique login IDs could be assigned to different individuals based on access needs. Other BladeSystem utilities such as BBI (for blade switch 2012 HP and atsec information security corporation Page 55 of 71

56 management) have similar support. Utilities such as VSM (SAS management) rely on authentication through OA, providing multiple login ID support inherited from OA. For 8.2 see the discussion for on the previous page. In summary, two factor authentication through LDAP/Active Directory, RADIUS, TACACS integration is available on some of the BladeSystem utilities including VC/VCEM. As noted in on the previous page, some customers implement automated access controls at the CDE network level, requiring two-factor VPN login to access the CDE network. In this case subsequent logins to servers, network equipment, or systems management utilities might not be controlled by an automated system, and the PCI requirement is satisfied at the network authentication level prior to accessing BladeSystem utilities. 8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. This PCI requirement does not necessarily have to be implemented at the BladeSystem management utility (VC, etc). See the discussion for on the previous page. In summary, two factor authentication through LDAP/Active Directory, RADIUS, TACACS integration is available on some of the BladeSystem utilities including VC/VCEM. As noted in on the previous page, some customers implement automated access controls at the CDE network level, requiring two-factor VPN login to access the CDE network. In this case subsequent logins to servers, network equipment, or systems management utilities might not be controlled by an automated system, and the PCI requirement is satisfied at the network authentication level prior to accessing BladeSystem utilities. 8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography. BladeSystem utilities including VC/VCEM, OA, and ilo each support encrypted communications through SSH and SHTTP. Insecure protocols such as telnet should be disabled since they do not protect authentication credentials or consequent network traffic during use of the utility. 8.5 Ensure proper user identification and authentication management for nonconsumer users and administrators on all system components This requirement focuses on onsite procedures. VC/VCEM, OA, and ilo each support the requirement through user account administration screens in their respective GUIs. The administration screens can be used to verify which user accounts are setup as well as roles that are established for each account (if needed). Many sub-requirements for #8.5 are procedural in nature and are covered below where appropriate. This group of requirements is about password-related and session controls: Change user passwords at least every 90 days Require a minimum password length of at least seven characters Use passwords containing both numeric and alphabetic characters Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used Limit repeated access attempts by locking out the user ID after not more 2012 HP and atsec information security corporation Page 56 of 71

57 than six attempts Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID If a session has been idle for more than 15 minutes, require the user to reauthenticate to re-activate the terminal or session. These requirements are all for password-related controls. In this discussion BladeSystem compatibility is focused on VC/VCEM, ilo, and OA. For other utilities the reader is referred to respective product manuals. As noted in PCI discussion above, the following automated access control method interfaces are supported: VC/VCEM LDAP/Active Directory, RADIUS, TACACS OA LDAP/Active Directory ilo LDAP/Active Directory, Novell e-directory The best way to programmatically meet these requirements for BladeSystem utilities would be to implement LDAP or Active Directory integration and enforce the controls at the directory authentication level. For utility compliance natively within each utility, some controls are possible. Examples are below. VC/VCEM natively supports: # minimum password length # password complexity rules ilo natively supports: # minimum password length # authentication failure is logged after a set number of tries OA natively supports: # minimum password length # password complexity rules Support for other PCI requirements could also be met at the CDE network login point. This would include setting session idle time logout at 15 minutes (on the network or VPN login) to comply with In addition, each administrative workstation should have all of the items in these requirements met at the client operating system level Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users. Restrict user direct access or queries to databases to database administrators. This requirement does not apply to BladeSystem utilities such as VC/VCEM, ilo, or OA since those utilities are not involved in CHD storage or databases HP and atsec information security corporation Page 57 of 71

58 Requirement 9. Restrict physical access to cardholder data. The intent of this requirement is to control and monitor physical access to the CDE and systems transacting CHD. As such, facility controls are used such as secured doors and video cameras to control and monitor access. Pertinent requirements are highlighted. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 9.9 Maintain strict control over the storage and accessibility of media. VC/VCEM, OA, and ilo are not involved directly with media storage. For tape blades and external tape storage, HP Data Protector can be used as part of the media inventory record flow. Data Protector can be setup to logs and status for tape backup jobs. Subsequently these logs could be used to supplement media inventory records. Since these logs contain sensitive information about tapes with CHD, access to the logs should be restricted to only those administrators needing access to accomplish their jobs Destroy media containing cardholder data when it is no longer needed for business or legal reasons. The intent of this requirement is to render data unrecoverable. As mentioned in PCI #3.1.1 above, the following applies for BladeSystem components. VC, OA, and ilo do not have CHD access or storage. Storage blades (with hard disks) support HP Drive Erase (available from ACU) which can be used to erase contents of associated disk drives. HP Drive Erase will overwrite all file contents and all metadata including RAID, partition, and file system metadata. For tape blades, commercial degausser units are probably best for bulk tape erasure prior to all backups to ensure the tape contents including the tail end of the tape is erased. For disk storage solutions - HP SAS External Storage Solutions and HP external modular storage solutions, HP Drive erase is available for Smart Array controlled drives as mentioned above. For HP Tape Blades and HP External Modular storage solutions which are tapebased, a commercial degausser is the best method to do bulk tape erasures. For permanent media disposal, commercial solutions or services can be used to destroy disks and tapes where CHD was stored. Regularly monitor and test networks Requirement 10. Track and monitor all access to network resources and cardholder data. The intent of this requirement is to establish and maintain audit trails which can subsequently be used to track user activities and/or perform forensics when something goes wrong. (The PCI DSS header Regularly monitor and test networks is a bit misleading because this is not always network specific.) PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 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. VC/VCEM, OA, ilo, and related BladeSystem utilities provide logs that can be 2012 HP and atsec information security corporation Page 58 of 71

59 audited for administrators access and activities. The logs are enabled by default, and details of the different logs were discussed in chapter 3. More details are also discussed in PCI 10.* items below. Each of the logs can be forwarded to a centralized logging facility, providing a central place for reviewing and auditing audit trails. Many of the items in 10.* can be best achieved through the LDAP integration available for VC/VCEM, OA, and ilo which was outlined in more detail in #8.5.9 above Implement automated audit trails for all system components to reconstruct the following events: See below All individual accesses to cardholder data are logged. This is N/A for BladeSystem since CHD access is not directly provided. VC/VCEM, OA, and ilo record all administrator actions All actions taken by any individual with root or administrative privileges are logged. VC/VCEM, OA, and ilo record all administrator actions regardless of level. Similar policy is implemented in related BladeSystem utilities. VC logs user/administrator login events, including timestamp, and the log provides summary information of the events occurring, for example that a user profile was changed or a network was added. For more detailed log information additional utilities may need to be added to supplement this information, for example by adding a utility that logs such information or through having admins log in via an intermediate "gateway" system that logs the commands issues Access to all audit trails is logged. For BladeSystem utilities this activity would have to be done at the centralized syslog, as it receives events from BladeSystem Invalid logical access attempts are logged. As mentioned in PCI #8.5.9 above, ilo records number of invalid login attempts. Compliance with this requirement could best be implemented through domain authentication (LDAP/Active Directory) as integrated with BladeSystem utilities. This domain authentication is supported in VC/VCEM, ilo, and OA, as well as other HP utilities Use of identification and authentication mechanisms is logged. This could best be implemented through domain authentication (LDAP/Active Directory) as integrated with BladeSystem utilities. This domain authentication is supported in VC/VCEM, ilo, and OA, as well as other HP utilities Verify initialization of audit logs is logged. For BladeSystem utilities this activity would have to be done at the centralized syslog, as it receives events from BladeSystem. The BladeSystem utilities would be setup to forward events, and the centralized logging facility would record start 2012 HP and atsec information security corporation Page 59 of 71

60 and stop times for the enclosure logs Verify creation and deletion of system level objects is logged. Each of the utilities VC/VCEM, OA, and ilo record system level objects (add, edit, delete) providing means for meeting this requirement. The nature of the BladeSystem utilities is that they record exactly this system level type of activities, albeit mostly at the hardware and firmware level Record at least the following audit trail entries for all system components for each event: User identification Type of event Date and time Success or failure indication Origination of event Identity or name of affected data, system component, or resource. These items are logged by the BladeSystem utilities VC/VCEM, OA, and ilo. As pointed out in the logging discussions in section 3.6, the utilities comply with RFC3164 formatting for log events Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. OA and ilo enable synchronization with an NTP source as discussed in chapter 3. Also HP switches and passthrus enable synchronization with an NTP source as discussed in chapter 5. Effectively OA and ilo serve as the critical system clocks for BladeSystem Time data is protected. Since each of the BladeSystem components require authentication prior to access, the time data that is setup by an authorized administrator is protected from tampering Secure audit trails so they cannot be altered Limit viewing of audit trails to those with a job-related need Protect audit trail files from unauthorized modifications Promptly back up audit trail files to a centralized log server or media that is difficult to alter Write logs for external-facing technologies onto a log server on the internal LAN. VC/VCEM, OA, and ilo and related BladeSystem utilities provide logs that can be audited for administrators access and activities. The logs are enabled by default, and details of the different logs were discussed in chapter 3. Each of the logs can be forwarded to a centralized logging facility, providing a central place for reviewing and auditing audit trails. This would be the most effective implementation of logging to achieve compliance with PCI 10.5.* requirements. This was discussed in chapter HP and atsec information security corporation Page 60 of 71

61 As mentioned previously, the BladeSystem utilities all require authentication for access thus preventing alteration by unauthorized individuals and enabling compliance with 10.5 and The utilities also provide different levels of access, enabling compliance with Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). There are no special considerations for BladeSystem components. Often a FIM is setup to look at O.S. level files for change detection, as well as changes that will show up in logs. As noted above, BladeSystem utilities can each have their log events forwarded to a centralized log utility, enabling compliance with this requirement Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). As noted in above, There are no special considerations for BladeSystem components. As noted above, BladeSystem utilities can each have their log events forwarded to a centralized log utility, enabling compliance with this requirement Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up). The BladeSystem utilities maintain circular logs in that each log gets overwritten once the storage size limit is achieved. The best way to comply with this requirement is to forward log events from VC/VCEM, OA, and ilo to a centralized log utility where compliance can be achieved on that software. Requirement 11. Regularly test security systems and processes. The objective of this requirement is to ensure security controls are maintained to prevent vulnerabilities from providing an avenue of entry by malicious individuals into the CDE. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) 11.1 Test for the presence of wireless access points and detect authorized access points on a quarterly and 11.3 BladeSystem components do not contain wireless, so there are no special considerations here. As noted in section 5.3, BladeSystem switches can be configured so that inactive switch ports are disabled. This method could be used to help reduce the potential for unauthorized network devices (i.e., wireless) to obtain access to the network Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades) Perform external and internal penetration testing at least once a year and 2012 HP and atsec information security corporation Page 61 of 71

62 after any significant infrastructure or application upgrade or modification and 11.5 The intent of this requirement is to ensure vulnerability profiles of the CDE are not reduced over time or during changes. There are no special considerations for BladeSystem. Changes in network including significant VC network and VLAN configurations should be accompanied by the appropriate testing as specified by the PCI requirements Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic at the perimeter of the cardholder data environment as well as 11.5 Deploy file-integrity monitoring tools to alert personnel to unauthorized modification of critical system file, There are no special considerations for BladeSystem. As noted in chapter 3, Virtual Connect does not provide external switch characteristics at the uplink port. An IDS could be configured to monitor traffic at the uplink ports for critical systems, or for above and beyond PCI implementations. The VC, OA, and ilo configuration files are maintained in firmware, so it is not possible to setup an IDS to monitor changes in those configurations. Maintain an information security policy Requirement 12. Maintain a policy that addresses information security. The intent of this requirement is to ensure security and CHD handling awareness across the organization, as well as maintaining proper data access controls. As a general point, HP BladeSystem is a significant investment for an organization, and is made because of extensive processing that the business requires. PCI # PCI DSS requirement (italicized) HP considerations (non-italics) For the 12.1 security policy, it must Include an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. VC/VCEM, OA, and ilo as well as other BladeSystem components are capable of having vulnerabilities. The known vulnerabilities were reviewed at the end of chapter 3. The security policy and risk assessment should include BladeSystem potential vulnerabilities as part of the assessed risk profile Develop usage policies for critical technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, tablets, personal data/digital assistants (PDAs), usage and Internet usage) and define proper use of these technologies. There are no special considerations for BladeSystem. However, it is typical that an organization acquired BladeSystem for business purposes. One would expect to see the usage policies for the organization to include the CDE components including BladeSystem Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity. At the time this paper was written, BladeSystem utilities do not directly support this, but it is known that future releases will. Many customers control this at the 2012 HP and atsec information security corporation Page 62 of 71

63 CDE network login level as noted in PCI #8.5.15, by setting idle timeouts on the VPN login profile. This could also be implemented with LDAP profiles since VC, OA, and ilo support integrated login via LDAP Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use. BladeSystem utilities support remote access, but do not provide automated user- ID timeouts. This PCI requirement can easily be met by having a policy to disable temporary accounts across all technologies in the CDE including BladeSystem immediately after vendor/partner usage. Alternately if the BladeSystem utilities are integrated with LDAP, the LDAP profile could be deactivated after vendor/partner usage For personnel accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. BladeSystem utilities (VC, OA, ilo) do not provide direct access to CHD. It is possible to access CHD when Virtual Media and Virtual Folder (after authentication to the O.S.), but this would simply be included in the defined policy and there is no special consideration for BladeSystem Implement an incident response plan. Be prepared to respond immediately to a system breach. As noted in chapters 3, 4, and 5, BladeSystem provides rich capabilities in networking. VC and VCEM enable predefined profiles for server blades and networking components. Server blades can established as backups for breached systems, whether local to an enclosure or remote, relying on the profiles established by VC/VCEM. The associated profiles for an enclosure can be shared or exported to another site to aid in incident response recovery. Data backup solutions from HP include tape blades and external tape units as explained in chapters 3, 4, and 5; and these solutions can play a key role in handling incidents HP and atsec information security corporation Page 63 of 71

64 10 Summary/Conclusion This report examined the HP BladeSystem and Virtual Connect and their generalized environments in the context of achieving compliance with the Payment Card Industry Data Security Standard. The conclusions include the following: BladeSystem, Virtual Connect, and related HP technologies support a PCI DSS-compliant environment when configured appropriately. Virtual Connect is currently a BladeSystem-only interconnect, and is a secure traffic manager that has no method to intercept or view network traffic. Virtual Connect, Onboard Administrator, and ilo do not directly provide access to CHD, as these utilities are focused on managing hardware as well as internal networking (VC downlinks). Virtual Connect and BladeSystem enable organizations with PCI DSS compliant environments other benefits such as options for redundancy and configuration portability. These benefits were reviewed in detail in the in-place PCI requirements in chapter 9. Virtual Connect, Onboard Administrator, and ilo and other BladeSystem utilities have been developed with technology extensions such as LDAP integration, event forwarding, and other extensions which allow for seamless integration into many corporate environments. These extensions allow for PCI DSS compliance related controls to be implemented in an automated, auditable fashion which enables monitoring of critical systems and settings HP and atsec information security corporation Page 64 of 71

65 A PCI Compliance Supplement It is assumed that the audience of this document is already familiar with the basics of PCI compliance. This Annex serves as a quick reminder. A.1 PCI Related Terminology Some basic terminology used in the industry that is needed to understand this report is given below. Several of the definitions are reproduced from the PCI Glossary [4]. Acquirer: Also referred to as acquiring bank or acquiring financial institution; Entity that initiates and maintains relationships with merchants for the acceptance of payment cards. Assessor: An organization approved by the PCI SSC to conduct PCI DSS on-site assessments. This may be a QSA or an ISA. Card Holder Data Environment: The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, including any connected system components. ISA: Acronym for Internal Security Assessor, an organization meeting the requirements of the PCI SSC to in order to conduct PCI DSS on-site assessments. Typically this is an internal auditor independent of the subject of the assessment. Merchant: For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard, or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers. QSA: Acronym for Qualified Security Assessor, company approved by the PCI SSC to conduct PCI DSS on-site assessments. Service provider: Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services, as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded. A.2 Standards and Programs The PCI SSC was founded in 2004 by five international payment card brands: American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc. The council s mission is to provide common standards, education, and awareness of data security among merchants, service providers, and acquirers who are active in the industry and who store, process, or transmit cardholder data. The PCI SSC operates a website that provides a great deal of background information and resources. It includes the definitive versions of the standards and many guidance and supporting documents. Each brand operates its own program for security and associated risk reduction, but all do so using a common set of standards developed under the auspices of the PCI SSC. What differs 2012 HP and atsec information security corporation Page 65 of 71

66 between the brands are some interpretations, and some specific program differences, for example when an assessment by a QSA or ISA is necessary. Details of these are found on the website for each program. Card Brand Security Program URL The MasterCard Site Data Protection Program (SDP) dex.html Visa Cardholder Information Security Program (CISP) anagement/cisp_overview.html American Express Data Security Operating Policy Compliance Program (DSOP) Discover Information Security & Compliance (DISC) m/merchant/singlevoice/dsw/frontser vlet?request_type=dsw&pg_nm=spinf o&ln=en&frm=us&tabbed=complien cerequirement dsecurity/disc.html JCB Table 1: Card Brand Security Programs It is the card brands themselves that levy penalties on those who do not comply with the program requirements HP and atsec information security corporation Page 66 of 71

67 B Glossary ACU AD BBI CC CDE CHD CIS CLI CMVP CSRF CSV DoS DSS EAL FIPS GUI HBA HP ilo IPSEC ISA iscsi ISO KVM NIC NIST OA ORCA PCI PCI DSS PCI SSC PXE QSA RBAC RBSU Array Configuration Utility Active Directory Browser Based Interface Common Criteria Cardholder Data Environment Cardholder Data Center for Internet Security Command Line Interface Cryptographic Module Validation Program Cross Site Request Forgery Comma Separated Value Denial of Service Data Security Standard Evaluation Assurance Level Federal Information Processing Standard Graphical User Interface Host Bus Adaptor Hewlett Packard Integrated Lights Out IP Security Internal Security Assessor Internet Small Computer Systems Interface International Organization for Standardization Keyboard Video Mouse Network Interface Controller National Institute of Standards and Technology Onboard Administrator Option ROM Configuration for Arrays Payment Card Industry Payment Card Industry Data Security Standard Payment Card Industry Security Standards Council Pre-boot Execution Environment Qualified Security Assessor Role-Based Access Control ROM-Based Setup Utility 2012 HP and atsec information security corporation Page 67 of 71

68 SAN SEL SNMP SSP SVC TCP TPM VC VCEM VCM VM VLAN XSS Storage Area Network System Event Log Simple Network Management Protocol Selective Storage Presentation Switched Virtual Circuit Transmission Control Protocol Trusted Platform Module Virtual Connect Virtual Connect Enterprise Manager Virtual Connect Manager Virtual Machine Virtual Local Area Network Cross Site Scripting 2012 HP and atsec information security corporation Page 68 of 71

69 C Bibliography & References C.1 PCI SSC Documents [1] PCI SSC. 2010, Payment Card Industry (PCI) Data Security Standard: Requirements and Security Assessment Procedures October 2010 Version [2] PCI SSC. 2010, Payment Card Industry (PCI) Payment Application Data Security Standard: Requirements and Security Assessment Procedures October 2010 Version [3] PCI SSC. 2010, Navigating PCI DSS: Understanding the Intent of the Requirements Version 2.0 October, [4] PCI SSC. 2010, Payment Card Industry (PCI) Data Security Standard (DSS) and Payment Application Data Security Standard (PA-DSS): Glossary of Terms, Abbreviations, and Acronyms October, 2010 Version [5] PCI SSC, 2010, PCI Quick Reference Guide: Understanding the Payment Card Industry Data Security Standard Version %20Guide.pdf [6] PCI SSC List of Validated Payment Applications. Available from [7] PCI SSC Information Supplement: PCI DSS Virtualization Guidelines, June 2011 Version [8] PCI SSC Assessor Newsletter, November C.2 Supporting References [9] HP BladeSystem [10] HP BladeSystems web page [11] HP Onboard Administrator d=reg_r1002_usen [12] HP Virtual Connect Technology [13] HP Integrated Lights-Out Security, 7th Edition (17th March, 2011) n=docindexpdf&prodseriesid=397989&targetpage=http%3a%2f%2fbizsupport1.au stin.hp.com%2fbc%2fdocs%2fsupport%2fsupportmanual%2fc %2fc pdf 2012 HP and atsec information security corporation Page 69 of 71

70 [14] HP Integrated Lights-Out (ilo) Advanced [15] HP ProLiant Integrated Lights-Out 3 v1.20 Scripting and Command Line Guide pdf [16] HP Virtual Connect: Common Myths, Misperceptions, and Objections, Second Edition hires.pdf [17] HP BladeSystem c-class Architecture pdf [18] HP Virtual Connect web page [19] HP Virtual Connect Technology Guide [20] HP BladeSystem c-class Solution Overview c hires.pdf [21] HP BladeSystem Technical Resources for blades [22] HP ProLiant Integrated Lights-Out 3 v1.20 User Guide pdf [23] HP Integrated Lights-Out Security, Technology brief, 7th Edition pdf [24] HP Virtual Connect Enterprise Manager Version User Guide pdf [25] HP Insight Software Virtual Connect Enterprise Manager Command Line Interface Version User Guide pdf [26] HP Virtual Connect for c-class BladeSystem Version 3.30 User Guide pdf [27] HP BladeSystem Onboard Administrator User Guide v pdf [28] HP BladeSystem Onboard Administrator Command Line Interface User Guide v pdf [29] HP Virtual Connect Manager Command Line Interface for c-class BladeSystem Version 3.30 User Guide pdf 2012 HP and atsec information security corporation Page 70 of 71

71 [30] Virtual Connect FlexFabric Cookbook (November 2010) pdf [31] Virtual Connect Multi-Enclosure Stacking Reference Guide pdf [32] HP BladeSystem Technical Resources [33] Management Architecture of HP BladeSystem c-class Systems pdf [34] SLB9635TT1.2 / m1566a13 HW a13 / FW : Common Criteria certification report [35] HP Security Bulletins [36] Server virtualization technologies for x86-based HP BladeSystem and HP ProLiant servers technology brief, 3rd edition pdf [37] HP Integrated Lights-Out security: Technology brief. 7 th edition pdf [38] NIST SP : Recommendation for Key Management [39] CSEC Products in evaluation list [40] The Common Criteria Portal C.3 atsec references and links: [41] Cryptographic Algorithms for the Payment Card Industry, Fiona Pattinson, atsec information security, October 2010 [42] What to expect from a PCI QSA led assessment, Fiona Pattinson, atsec information security, October 2010 C.4 Organizations [43] PCI SSC Payment Card Industry Security Standards Council HP Pub#4AA4-0261ENW 2012 HP and atsec information security corporation Page 71 of 71