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.
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.
1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.
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 3.2.
1.3.7 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 3.2.
1.3.8 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
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.
2.1.1 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.
2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server.
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.
2.2.2 Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.
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.
2.2.4 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 3.5.1.2. 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)
3.1.1 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 dataA 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)
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 140-2 level 2 validated
(certificate #1102).
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.
4.1.1 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
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.
6.3.1 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.
6.3.2 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.
6.4.1 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.
6.4.5 Change control procedures for the implementation of security patches and software modifications.
As mentioned in 6.4.2 (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.
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:
1.1.1 Restriction of access rights to privileged user IDs to least privileges necessary
1.1.2 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 3.5.1.3, 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.
7.1.4 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.
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.
7.2.1 Coverage of all system components
7.2.2 Assignment of privileges to individuals based on job classification and function
7.2.3 Default “deny-all” setting
HP BladeSystem provides direct support enabling compliance with this PCI
HP BladeSystem provides direct support enabling compliance with this PCI