Retailers, fi nancial 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 fi rewalls, many rules focus on the security of data while it is stored within the enterprise.

1. 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
If virtualization technologies are used, verify that only exploiting super user privileges, and more. SafeNet ProtectV Instance enables
one primary function is implemented per virtual system organizations to encrypt entire virtual instances, and secure them against
component or device. such threats.
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 With DataSecure, the only way to access administrative controls is via a
secure Web-management console, a command line interface over SSH,
Encrypt all non-console administrative access using or a direct console connection. The platform can be configured so that
strong cryptography. Use technologies such as SSH, individual administrators are only granted access to areas for which they are
VPN, or SSL/TLS for web-based management and other responsible. Administrative activities are logged and digitally signed in an
non-console administrative access. audit log.
Complying with the Payment Card Industry Data Security Standard White Paper 1

2. Requirement 3 SafeNet DataSecure delivers encryption capabilities that ensure the security of
sensitive data, supporting standard, robust encryption algorithms. Encryption is a
Protect stored cardholder data 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.
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 DataSecure supports strong encryption algorithms, including 3DES and AES
256-bit. In addition, by supporting encryption of unstructured files, columns
Restrict access to cryptographic keys to the fewest in databases, applications, and more, DataSecure enables organizations to
number of custodians necessary. 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 DataSecure centralizes the storage and management of encryption keys on a
single appliance (or more typically an integrated cluster of dedicated security
Store cryptographic keys securely in the fewest possible appliances) —where all keys are stored encrypted and integrity checked within
locations and forms. 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

3. Requirement 3.6 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
Fully document and implement all key-management management console, a command line interface over SSH, or a direct console
processes and procedures for cryptographic keys connection. The platform can be configured so that individual administrators are
used for encryption of cardholder data, including the granted access only to areas for which they are responsible.
following:
The DataSecure appliance is designed to the FIPS 140-2 Level 2 standard, which
• 3.6.1 Generation of strong cryptographic keys supports U.S. government requirements for ensuring that key management is
• 3.6.2 Secure cryptographic key distribution tamper resistant. Following are some additional details around how DataSecure
addresses specific requirements:
• 3.6.3 Secure cryptographic key storage
3.6.1—Using DataSecure administration tools, either via CLI or admin GUI,
• 3.6.4 Cryptographic key changes for keys that administrators can generate strong keys using the hardware-based random
have reached the end of their cryptoperiod (for number generation capabilities provided by the cryptographic accelerators on the
example, after a defined period of time has passed DataSecure device. The steps and procedures involved can easily be included in
and/or after a certain amount of ciphertext has any security policy procedures.
been produced by a given key), as defined by the
associated application vendor or key owner, and 3.6.2—With the DataSecure solution, cryptographic keys never leave the
based on industry best practices and guidelines (for hardware appliance. Encryption keys are generated and always reside on the
example, NIST Special Publication 800-57). hardened appliance, and since cryptographic operations are performed on
the appliance, keys need not be distributed or stored on Web, application, or
• 3.6.5 Retirement or replacement (for example, database servers. DataSecure also provides secure replication and secure
archiving, destruction, and/or revocation) of keys backup mechanisms, such that keys do not leave the DataSecure platform in the
as deemed necessary when the integrity of the key clear.
has been weakened (for example, departure of an
employee with knowledge of a clear-text key), or 3.6.3—Keys are always stored securely on the DataSecure platform. Encryption
keys are suspected of being compromised. keys themselves are encrypted using a multi-layered hierarchy of key encryption
keys. With the DataSecure appliance, encryption keys are stored in a tamper-
• 3.6.6 If manual clear-text cryptographic key resistant hardware security module (HSM).
management operations are used, these operations
must be managed using split knowledge and dual 3.6.4—DataSecure provides a key rotation mechanism that allows customers to
control (for example, requiring two or three people, efficiently rotate keys according to security policy.
each knowing only their own key component, to 3.6.5—Keys are always stored on the DataSecure device in an encrypted form.
reconstruct the whole key).
3.6.6—Split knowledge for key creation and deletion/access is supported through
• 3.6.7 Prevention of unauthorized substitution of DataSecure’s 20+ administrative access control lists (ACLs). Security teams can
cryptographic keys. require that two administrators must approve certain types of actions—i.e. key
• 3.6.8 Requirement for cryptographic key custodians creation, etc.
to formally acknowledge that they understand and Additionally, split knowledge control of keys is often employed in situations in
accept their key-custodian responsibilities. 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 DataSecure supports SSL for transport encryption between database or
application servers and the DataSecure appliance. The preference ordering of
Use strong cryptography and security protocols (for acceptable SSL ciphers and key sizes may be configured on the DataSecure
example, SSL/TLS, IPSEC, SSH, etc.) to safeguard appliance, so, for example, only 128-bit or higher key sizes are allowed. SafeNet
sensitive cardholder data during transmission over open, generally recommends as part of our best practices to use SSL for transport
public networks. 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

4. Requirement 6 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
Develop and maintain secure systems and applications trust software. Digital signatures help maintain the electronic integrity and
6.3 Develop software applications (internal and external, authenticity of code by associating it with an application vendor’s unique
and including web-based administrative access to signature. A certificate is a set of data that completely identifies an entity, and is
applications) in accordance with PCI DSS (for example, issued by a certification authority (CA). The data set includes the entity’s public
secure authentication and logging), and based on cryptographic key. To obtain a certificate from a CA, an application provider must
industry best practices. Incorporate information security meet the criteria for a commercial publishing certificate. It is recommended
throughout the software development life cycle. 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 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
8.2 In addition to assigning a unique ID, employ at least authentication. If remote access is necessary, then the requirement further
one of the following methods to authenticate all users: specifies that two-factor authentication must be used.
• Something you know, such as a password or Storing “digital identities” on a secured device, such as a smart card or token, is
passphrase emerging as a preferred method for positive employee identification. SafeNet
• Something you have, such as a token device or authentication tokens are secure devices that enable positive user identification.
smart card 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
• Something you are, such as a biometric (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 Passwords are encrypted via SSL when authentication to the DataSecure
appliance is performed. Within the platform, passwords are hashed so that they
Render all passwords unreadable during transmission can never be inadvertently exposed.
and storage on all system components using strong
cryptography.
Requirement 8.5 SafeNet supports best practices around credential management for
authentication to the DataSecure platform. The platform also has an advanced
Ensure proper user identification and authentication set of password management options for expiry, password history, password
management for nonconsumer users and administrators length, and character set.
on all system components as follows:
Complying with the Payment Card Industry Data Security Standard White Paper 4

5. Requirement 9 SafeNet offers effective capabilities for addressing these access requirements.
SafeNet smart cards can be integrated with various building access technologies
Restrict physical access to cardholder data 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 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
Track and monitor all access to network resources and specific administrator or user identification information. Log files are digitally
cardholder data 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 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
Implement automated audit trails for all system device and for automatic off-device log transfers using secure copy (SCP) or FTP.
components to reconstruct the following events:
Synchronization with other devices, such as database or application servers, may
• 10.2.1 All individual accesses to cardholder data be achieved through the use of Network Time Protocol (NTP). The DataSecure
• 10.2.2 All actions taken by any individual with root device can be configured to point to an NTP source, such as a router or other
or administrative privileges 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 As mentioned above, DataSecure’s log files are digitally signed to prevent
tampering. Plus, as part of the flexible set of log configuration options,
Secure audit trails so they cannot be altered. DataSecure enables log files to be automatically rotated to a backup or archiving
• 10.5.1 Limit viewing of audit trails to those with a log server. As a result, an audit trail can be effectively maintained to meet audit
job-related need. 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 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).
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