ComplyingPaymentCardIndustryDataSecurity_WP_(EN)_web

Complying with the Payment Card Industry Data Security Standard WHITE PAPER

Retailers, financial institutions, service providers, and any other businesses that handle credit card holder data today must adhere to the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS outlines policies for ensuring that cardholder data is secured at all times. While the mandate features rules on everything from changing employee passwords regularly to deploying firewalls, many rules focus on the security of data while it is stored within the enterprise.

SafeNet can help address many of the critical challenges of adhering to PCI DSS relating to the security of payment data within the enterprise. Further, SafeNet solutions help organizations take a comprehensive, information-centric approach to security that not only helps address near-term compliance objectives, but ensures the security of sensitive assets in the long term. SafeNet offers solutions that are efficient, flexible, and adaptable, enabling businesses to address dynamic security threats and evolving business objectives.

In the pages that follow, we provide some specific requirements from the PCI DSS, version 2.0, and illustrate how SafeNet can help address these specific mandates.

Regulations

How SafeNet Addresses

Requirement: 2.2.1.b

Virtual instances, whether in cloud or other virtualized environments, can be susceptible to an array of threats, including data comingling, administrators exploiting super user privileges, and more. SafeNet ProtectV Instance enables organizations to encrypt entire virtual instances, and secure them against such threats.

If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device.

With ProtectV Instance, security teams can logically separate the virtual instances that hold sensitive data from other instances in the environment, and so guard against inadvertent data comingling—even in multi-tenant cloud environments. In addition, the solution enables organizations to implement granular access controls that mitigate the threat of potential hackers who might breach cloud hypervisors, and from the cloud super-users who administer the virtual environment.

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

With DataSecure, the only way to access administrative controls is via a secure Web-management console, a command line interface over SSH, or a direct console connection. The platform can be configured so that individual administrators are only granted access to areas for which they are responsible. Administrative activities are logged and digitally signed in an audit log.

Complying with the Payment Card Industry Data Security Standard White Paper

1

SafeNet DataSecure delivers encryption capabilities that ensure the security of sensitive data, supporting standard, robust encryption algorithms. Encryption is a critical component of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person.

Requirement 3 Protect stored cardholder data

In addition, SafeNet offers a tokenization solution that complements these encryption capabilities. With the SafeNet Tokenization Manager, organizations can effectively and efficiently reduce the scope of their PCI DSS audits.

SafeNet’s format preserving tokenization technology converts the PAN to an encrypted token in the same format, allowing associated applications to operate seamlessly. SafeNet Tokenization Manager facilitates transparent end-user operation, while keeping encrypted information secure in one central location.

Because SafeNet Tokenization Manager replaces sensitive data in databases and applications with token values, there are fewer servers to audit.

Requirement 3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.

DataSecure supports strong encryption algorithms, including 3DES and AES 256-bit. In addition, by supporting encryption of unstructured files, columns in databases, applications, and more, DataSecure enables organizations to granularly protect PCI-regulated records and files, and ensure they remain encrypted even as they are saved to external storage media, USB drives, and more.

Furthermore, DataSecure features secure key generation, secure key storage, and secure key management via a hardened hardware platform that supports compliance with PCI. SafeNet Tokenization Manager also supports Requirement 3.4, rendering PAN unreadable by replacing it with token values.

Requirement 3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.

DataSecure centralizes the storage and management of encryption keys on a single appliance (or more typically an integrated cluster of dedicated security appliances) —where all keys are stored encrypted and integrity checked within the platform, and are never available in plaintext to anyone. Keys are encrypted using a multi-layered hierarchy of key encryption keys. The DataSecure appliance adheres to the FIPS 140-2 Level 2 standard, which supports U.S. government requirements for ensuring that key management is tamper resistant.

Encryption keys are also handled securely from an operations perspective. For example, when keys are replicated across clustered DataSecure devices or with remote DataSecure devices configured for disaster recovery, the keys are always encrypted. When keys are backed up, the keys—and any other DataSecure configuration details—are additionally encrypted in the backup configuration file.

Complying with the Payment Card Industry Data Security Standard White Paper

2

Requirement 3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following: • 3.6.1 Generation of strong cryptographic keys • 3.6.2 Secure cryptographic key distribution • 3.6.3 Secure cryptographic key storage • 3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

• 3.6.5 Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key), or keys are suspected of being compromised.

• 3.6.6 If manual clear-text cryptographic key management operations are used, these operations must be managed using split knowledge and dual control (for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key).

• 3.6.7 Prevention of unauthorized substitution of cryptographic keys.

• 3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.

With DataSecure, cryptographic keys never leave the hardware appliance. The only way to access the appliance is at the administrator level, via a secure Web management console, a command line interface over SSH, or a direct console connection. The platform can be configured so that individual administrators are granted access only to areas for which they are responsible.

The DataSecure appliance is designed to the FIPS 140-2 Level 2 standard, which supports U.S. government requirements for ensuring that key management is tamper resistant. Following are some additional details around how DataSecure addresses specific requirements: 3.6.1—Using DataSecure administration tools, either via CLI or admin GUI, administrators can generate strong keys using the hardware-based random number generation capabilities provided by the cryptographic accelerators on the DataSecure device. The steps and procedures involved can easily be included in any security policy procedures.

3.6.2—With the DataSecure solution, cryptographic keys never leave the hardware appliance. Encryption keys are generated and always reside on the hardened appliance, and since cryptographic operations are performed on the appliance, keys need not be distributed or stored on Web, application, or database servers. DataSecure also provides secure replication and secure backup mechanisms, such that keys do not leave the DataSecure platform in the clear.

3.6.3—Keys are always stored securely on the DataSecure platform. Encryption keys themselves are encrypted using a multi-layered hierarchy of key encryption keys. With the DataSecure appliance, encryption keys are stored in a tamperresistant hardware security module (HSM).

3.6.4—DataSecure provides a key rotation mechanism that allows customers to efficiently rotate keys according to security policy.

3.6.5—Keys are always stored on the DataSecure device in an encrypted form.

3.6.6—Split knowledge for key creation and deletion/access is supported through DataSecure’s 20+ administrative access control lists (ACLs). Security teams can require that two administrators must approve certain types of actions—i.e. key creation, etc.

Additionally, split knowledge control of keys is often employed in situations in which raw key bits are stored, exposed, or accessed in the clear. DataSecure provides a more secure key storage mechanism in that the raw key bits may never be stored, exposed, or accessed in the clear.

With the DataSecure solution, authorized users of encryption keys have access to cryptographic operations, but not access to the raw key bits. Cryptographic operations are performed only with keys to which an authorized DataSecure user has access.

Finally, there are ways to require that information must be shared across multiple DataSecure administrators before key-specific administrative operations are performed. Administrators can also enforce policies that require multiple authentication levels to be met before cryptographic operations are performed with specific encryption keys.

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

DataSecure supports SSL for transport encryption between database or application servers and the DataSecure appliance. The preference ordering of acceptable SSL ciphers and key sizes may be configured on the DataSecure appliance, so, for example, only 128-bit or higher key sizes are allowed. SafeNet generally recommends as part of our best practices to use SSL for transport encryption, however since the network connection between the DataSecure appliance and database server or application server is typically over the customer’s private network, and not a public network, not all customers implement SSL.

Complying with the Payment Card Industry Data Security Standard White Paper

3

Requirement 6 Develop and maintain secure systems and applications 6.3 Develop software applications (internal and external, and including web-based administrative access to applications) in accordance with PCI DSS (for example, secure authentication and logging), and based on industry best practices. Incorporate information security throughout the software development life cycle.

Without assurance of an application’s integrity, and without knowing who published an application, it’s difficult for end users to know how much to trust software. Digital signatures help maintain the electronic integrity and authenticity of code by associating it with an application vendor’s unique signature. A certificate is a set of data that completely identifies an entity, and is issued by a certification authority (CA). The data set includes the entity’s public cryptographic key. To obtain a certificate from a CA, an application provider must meet the criteria for a commercial publishing certificate. It is recommended that applicants generate and store their private key using a dedicated hardware solution, such as an HSM. The HSM protects the identity, whether it is a server, virtualization server, or the user. SafeNet HSMs take this level of security one step further by storing the signing material in a hardware device, thus ensuring the authenticity and integrity of a code file.

For payment application vendors, SafeNet’s Sentinel Security Products allow security teams to carefully control and regulate software distribution channels through the use of Distributor Keys. Administrators can assign and securely embed encryption keys during the manufacturing process in order to control the creation of licenses.

Requirement 8.2 8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users: • Something you know, such as a password or passphrase • Something you have, such as a token device or smart card • Something you are, such as a biometric

Not only does this requirement mandate that a unique ID be issued to each person, but that either passwords, token devices, or biometrics are used for authentication. If remote access is necessary, then the requirement further specifies that two-factor authentication must be used.

Storing “digital identities” on a secured device, such as a smart card or token, is emerging as a preferred method for positive employee identification. SafeNet authentication tokens are secure devices that enable positive user identification.

Private information never leaves the card and is protected by two-factor security—something that is owned (the smart card) and something that is known (the smart card passphrase).

In addition, with DataSecure, the only way to access the administrative level is via a secure Web management console, a command line interface over SSH, or a direct console connection. The platform can be configured so that individual administrators are granted access only to areas for which they are responsible.

Administrative activities are logged and digitally signed in an audit log.

Administrators may be granted permissions in 16 different categories based on their roles and responsibilities, thus enabling fine-grained administrative control. Two-factor authentication for administrative access may be enabled and enforced using digital certificates in conjunction with passwords. All administrator passwords are hashed and never exist on the DataSecure device in the clear.

Requirement 8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

Requirement 8.5 Ensure proper user identification and authentication management for nonconsumer users and administrators on all system components as follows:

Passwords are encrypted via SSL when authentication to the DataSecure appliance is performed. Within the platform, passwords are hashed so that they can never be inadvertently exposed.

SafeNet supports best practices around credential management for authentication to the DataSecure platform. The platform also has an advanced set of password management options for expiry, password history, password length, and character set.

Complying with the Payment Card Industry Data Security Standard White Paper

4

Requirement 9 Restrict physical access to cardholder data

SafeNet offers effective capabilities for addressing these access requirements.

SafeNet smart cards can be integrated with various building access technologies in order to function as both an employee’s physical and digital ID. The same smart card that is used for network and computer security can be personalized and printed with ID pictures to function as an employee’s ID badge. Fitted with a magnetic stripe or RF proximity technology, the card can also be used for door access systems. Smart ID badges can be issued using the same technology that issues standard ID badges today; existing badge printers would simply need to be upgraded to accept the smart card chip.

Further, SafeNet delivers comprehensive capabilities for managing user access, authentication, and access control between application servers and the DataSecure platform.

The only way to access the DataSecure platform is at the administrator level via a secure Web management console, a command line interface over SSH, or a direct console connection. The platform can be configured so that individual administrators are granted access only to areas for which they are responsible.

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

DataSecure maintains an extensive set of centralized log files that can be used to track administrator and user activities. Log files are time stamped and include specific administrator or user identification information. Log files are digitally signed to prevent tampering.

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

Requirement 10.2 Implement automated audit trails for all system components to reconstruct the following events: • 10.2.1 All individual accesses to cardholder data • 10.2.2 All actions taken by any individual with root or administrative privileges

DataSecure log files may be individually configured for a desired rotation schedule and for the number of log files to be archived, both on the DataSecure device and for automatic off-device log transfers using secure copy (SCP) or FTP. Synchronization with other devices, such as database or application servers, may be achieved through the use of Network Time Protocol (NTP). The DataSecure device can be configured to point to an NTP source, such as a router or other network device.

• 10.2.3 Access to all audit trails • 10.2.4 Invalid logical access attempts • 10.2 5 Use of identification and authentication mechanisms • 10.2.6 Initialization of the audit logs • 10.2.7 Creation and deletion of system-level objects

Requirement 10.5 Secure audit trails so they cannot be altered.

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

As mentioned above, DataSecure’s log files are digitally signed to prevent tampering. Plus, as part of the flexible set of log configuration options, DataSecure enables log files to be automatically rotated to a backup or archiving log server. As a result, an audit trail can be effectively maintained to meet audit history and legal regulations.

• 10.5.2 Protect audit trail files from unauthorized modifications.

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

• 10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN. • 10.5.5 Use file-integrity monitoring or changedetection 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).

Contact Us: For all office locations and contact information, please visit www.safenet-inc.com Follow Us: www.safenet-inc.com/connected ©2011 SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. All other product names are trademarks of their respective owners. WP (EN)-02.15.11

Complying with the Payment Card Industry Data Security Standard White Paper

5