The Payment Card Industry Data Security Standard (PCI DSS) contains more than just recommended best practices—they are required policies, procedures, and technical requirements for businesses that use payment cards. The PCI Security Standards Council provides a number of documents that describe requirements in detail along with FAQs and guidelines; these are available in the council's documents library. This chapter highlights key compliance areas with a focus on the use of SSL certificates, including:
Before delving into the details of how to use SSL certificates to meet PCI DSS requirements, we will discuss the self‐assessment process.
For all but the smallest merchants, self‐assessments are required annually, and they are highly structured and must include the detailed testing procedures prescribed in the PCI documentation. In this chapter, we will consider elements of self‐assessments. This is not a complete discussion but considers five broad areas:
The goal of the following discussion is to consider the main requirements in each area. These checklists are not a substitute for an audit; instead they are intended as a guide to important topics that will be tested during an audit.
Data collection and storage practices cover how you handle payment card information, including account numbers and authentication data. The general rule is that you should not store data unless it is needed for a well‐defined business reason and when data is stored, it should be encrypted.
As part of the self‐assessment, you should verify the following requirements for storing payment card data:
When sensitive data is stored, it should be protected with encryption, and when it is displayed, subsets of the data should be masked in order to prevent inadvertent disclosure. As part of the self‐assessment, you should verify the following requirements for encrypting and masking sensitive information:
Networks supporting payment card applications must be secured using a number of security controls. The following checklist highlights major requirements:
It should be noted that many network security practices, such as encryption between clients and servers, utilize SSL certificates. The broad use of SSL certificates offers an example of a common occurrence in IT: A technology or service critical to the implementation of a higher‐level function is often out of sight and, potentially, out of mind. It is important to maintain an awareness of the underlying technologies that enable security, such as SSL certificates, so that we plan for and manage their use properly.
Payment card applications run on servers that must be secured. This security entails a combination of application configuration, OS configurations, and security services, such as antivirus and firewalls. As part of the process of ensuring payment card applications and their servers are secure, consider the following checklist items:
Even with established procedures to protect data, secure networks and servers, and applications, it is important to monitor the function of these procedures.
Monitoring a payment card application largely depends on the ability to collect information about significant events in application logs. The following checklist highlights steps you can take to ensure compliance with logging requirements:
In addition to these checklist items, you should make sure that log files are secured and the risk of tampering is mitigated through the use of strong access controls and the transmission of log entries to a central server as soon as possible.
Policies specify what a business does as a matter of practice, and in the case of security, what is required to meet business objectives regarding protecting data and IT resources. The PCI DSS has a number of requirements with regards to policies. The following checklist highlights important topics addressed:
The details of most of these policies are beyond the scope of this guide, but several are related to the use of SSL certificates and will be considered in more detail in a later section. The next section will delve deeper into checklist items specifically related to the use of SSL certificates.
The PCI DSS standards documentation mentions the use of strong encryption in several places. What does this mean from an operational perspective? In part it means:
Strong encryption is a somewhat imprecise term but it is generally used to describe an algorithm that is highly resistant to deciphering without an encryption key. In the simplest sense, an encryption algorithm is strong if the number of possible keys is so large there is no practical way to use a brute‐force search of all possible keys to find the deciphering key. Strong cryptography is not as vulnerable to analytic techniques either.
Cryptanalysis can be done in many ways. For example, an early form of cryptanalysis looked at the frequency with which characters appeared in the encrypted text in order to correlate those with the frequency of characters one would find in plain text. Using a more advanced technique known as differential cryptanalysis, someone could apply an encryption algorithm to a large number of input texts and study the resulting output in an effort to detect how differences in input affect the resulting output. Strong encryption algorithms are considered less likely than weak encryption algorithms to be compromised by such techniques.
The strength of an encryption algorithm is a product of the key length that is used. When considering the strength of an encryption algorithm, be sure to include the length of the encryption key.
The PCI DSS Glossary includes the following examples of strong cryptography:
Advances in cryptanalysis may one day eliminate one or more of these algorithm‐key length pairs from the list of accepted strong cryptography. The Digital Encryption Standard (DES), for example, was once a standard encryption algorithm in widespread use starting in the mid‐1970s. However, by 1999, a group of cryptography researchers demonstrated DES encryption could be broken in less than 24 hours using a brute‐force search on a custom‐built device dubbed "Deep Cracker." It is also possible that cryptanalysis will discover weaknesses in any of these algorithms that may be compensated for with the use of longer keys. In such cases, the algorithms may still be used in applications requiring strong cryptography as long as keys are sufficiently long.
Using strong encryption requires the use of sound key management practices. Key management is a complex process that includes:
Protocols, in this discussion, are agreed upon procedures for exchanging data. Many of the widely used protocols are defined by the Internet Engineering Task Force (IETF—see the list of Official Internet Protocol Standards examples). Some of the protocols are designed with less concern for security than others. In some cases, this is not an issue because the protocols are low‐level network protocols designed for minimum overhead; the User Datagram Protocol (UDP) is a case in point. In other cases, less secure protocols are coupled with more secure versions, such as the insecure FTP and the more secure versions FTPS or the alternative protocol SSH File Transfer Protocol. When assessing network communications for use with payment card applications, strong protocols are preferable to weak protocols.
Weak protocols do not employ security measures found in strong protocols. Strong measures include:
The problem with weak protocols can be seen with basic HTML form authentication in which passwords are passed in plain text. An application user navigates to the authentication page of an application and enters a username and password. The username and password may be passed to the application server in clear text or encoded using a simple scheme such as base64 encoding. There is no encryption, so the username and password are available for capture by someone sniffing network traffic. There is no way to authenticate where the username and password originated, so the username and password may be used by someone other than the legitimate user. In addition, as there is no way to verify the integrity of the data that is passed, the data may be changed by someone using a man‐in‐the‐middle attack.
Another example of a weak protocol is authenticating based on the contents of an HTTP referrer, which is metadata about an HTTP request that identifies the requestor. Like the example provided earlier, there is no encryption, reliable authentication, or ability to detect tampering with the contents of the HTTP referrer data.
Strong protocols should be used when transmitting payment card data.
Not surprisingly, strong protocols avoid the vulnerabilities of weak protocols using cryptographic techniques, including:
Often when SSL certificates are used for authentication, it is only servers that are authenticated. This setup is understandable when the objective is to assure users that they are communicating with legitimate servers belonging to the business the users are attempting to work with. In the case of payment card data processing, it is important to authenticate any device that receives payment card data. Even when you use strong protocols, you should keep in mind that some configurations, early versions of the protocols, or implementations may harbor weaknesses.
One of the targets of cryptanalysis is weaknesses in cryptographic algorithms, but those algorithms are only part of the process of establishing secure communications. There are other steps, such as starting a session, deciding which algorithms to use for encryption and message digests, acknowledging responses to requests, and so on. These steps are all defined in protocols, such as the SSL/TLS protocols, and the sequences of steps defined in the protocols may be vulnerable to attack.
An example of a protocol weakness is the SSL renegotiation vulnerability, which creates a vulnerability that could be exploited for a man‐in‐the‐middle attack. Renegotiation is the process of carrying out the SSL handshake over an established SSL connection. Prior to 2010 when the vulnerability became widely known, commonly used SSL implementations allowed for unsecure renegotiations by default. It is now considered a safe practice to use secure renegotiation by default. SSL protocols should be configured by default to use secure renegotiation.
More recently, security researchers have demonstrated how to exploit a vulnerability in the TLS 1.0 protocol. The attack, known as Browser Exploit Against SSL/TLS (BEAST) exploits a weakness in the way a cipher is implemented. Version 1.1 of TLS introduced more randomization into the way CBCs are used and is not vulnerable to the BEAST attack.
The key point to remember here is that even strong encryption algorithms can be used in vulnerable protocols. In order to protect sensitive and confidential information, it is important to be aware of vulnerabilities in protocols and in particular implementations of those protocols. The BEAST attack took advantage of a weakness in the TLS protocol that could be exploited in any implementation of the TLS 1.0 protocol. In addition to vulnerabilities in protocols, which affect all implementations, there may be vulnerabilities introduced by the way a protocol is implemented. For example, there may be a bug in a program that implements part of the SSL/TLS protocol in a browser. This requires a patch to the browser but does not warrant changing the protocol. From an operations perspective, it is important to be aware of both protocol and implementation vulnerabilities.
Security policies define rules that must be followed with regards to implementing information security. The range of security policies includes acceptable use, physical security, wireless security and desktop security. Policies that influence the use of SSL certificates, and PCI DSS compliance, include:
Policy documents typically include brief definitions of the scope, intended audience, and purpose of the policy. The core of any policy document is the policy statement that defines the rules to be followed with regard to the subject of the policy.
Encryption policies should define several aspects of encryption use within a business setting, including:
Within each of these sections, the policy should define high‐level requirements, perhaps referencing government or industry standards. Policy documents tend to be brief because they only specify what needs to be done, they do not describe how to implement these requirements or elaborate on why a particular choice was made about each rule. However, policy writers sometimes include a brief description of the motivation for the need for a particular set of rules.
Data at rest is data that is stored on fixed or mobile storage devices. The data at rest section of the policy should specify under what conditions data needs to be encrypted and can include:
The policy may specify if full‐disk encryption is required and if so how authentication should be implemented. This specification is particularly important with respect to the PCI DSS because it explicitly states that the authentication system for full‐disk encryption should be separate from the OS's authentication mechanism.
The policy may also include rules for the use of encryption on mobile devices, particularly how access controls are implemented on mobile storage devices. For example, a policy may specify that a passphrase must meet several criteria (for example, length, combination of character types, and so on) for acceptable use. It may also include rules about how long confidential data can remain on a mobile device, who may physically possess mobile media with confidential information, limits on where the mobile device may be taken, etc.
Encrypting data during transmission is clearly an important aspect of the PCI DSS regulations. Policies on this area should meet the minimal standards specified in the PCI DSS. In addition to stating the need for strong encryption anytime payment card data is transmitted, the policy may explicitly state the need for additional measures to ensure the standards are met. For example, the policy may specify that SSL software be configured to negotiate the use of only strong cipher suites. This is implied in the PCI DSS requirement and boarders on an implementation issue, but it is an important point and explicitly stating it in the policy can help educate the audience about a potential weakness in an SSL configuration.
The PCI DSS documentation provides examples of strong cryptography algorithms and key lengths. They can be included in the encryption policy. The list may change over time, so part of the regular reviews of security policies should include a review of the list of algorithms and key lengths considered acceptable by the PCI Security Standards Council.
The key management section of the encryption policy should include rules about who is allowed to generate new keys, separation of duty and job rotation requirements for personnel with key management responsibilities, and the need for separate keys for separate functions. Key management is such a complex task that this subject is a good candidate for referencing external guidelines, such as the NIST guidelines on key management.
Businesses need to control who has access to their data and applications, and access control policies specify the rules for this. In practice, you may find the need for multiple access control policies, such as remote access control, application access control, and physical access control policies. In general, these policies define the actions that people in particular roles can perform on the network, with data, or with regard to physical access to IT infrastructure.
Some of the topics that may be included are:
As with other policies, there may be a discussion of separation of duties and job rotation requirements.
The PCI DSS regulations make reference to payment card data and cardholder data when specifying the types of controls that must in place to protect this information. This kind of data warrants a particular set of controls. Even within the PCI DSS standard, authentication data, such as card not present verification data, is subject to even stricter limits on storage than other data, such as the payment account number. These rules highlight an implicit data classification scheme within the PCI DSS regulations, but the data classification is generally applicable to all business data.
A data classification policy defines the different types of data and the types of security controls that should be in place to protect the different types. A basic data classification scheme might include four categories:
Private data may be data about customers, employees, or others. The business maintains this data as part of normal business operations, but it is not considered to be data about the business. Private data can include name, address, health records, credit scores, etc. The data classification policy may specify that private data must not be released to unauthorized users; it also defines rules for determining what constitutes an authorized user.
Confidential data is similar to private data in that it is not to be disclosed unless necessary. Unlike private data, confidential data is about business operations and includes topics such as strategic plans, non‐public financial statements, legal opinions, etc. The data classification should include rules for protecting this type of data, such as the need for using encryption to transmit data and only transmitting data between devices that are mutually authenticated using SSL certificates.
Sensitive data is business data that should not be disclosed but if it were it would not cause substantial harm to the business. This category might include mid‐level manager's schedules and HR policy documents. The data classification policy might indicate that such documents do not need to be encrypted when at rest but should be encrypted when transmitted over public networks.
Public information is any information that can be disclosed outside the company without harm. Press releases, product catalogs, and marketing material are examples of public data. The data classification policy may not require any security controls on this data.
Policies governing monitoring and auditing describe the scope of logging activity required, including:
The PCI DSS documentation includes requirements for logging activity that should be addressed in the monitoring and auditing policy.
Another aspect of PCI DSS compliance is ensuring that security controls built on SSL certificates are maintained by procedures, including SSL certificate life cycle management.
SSL certificates are assets that must be managed like any other. The basic operations in SSL certificate life cycle management are:
The first step in the life cycle management process is selecting the right types of SSL certificates for your requirements.
SSL certificate vendors offer a number of types of SSL certificates for different needs. Some SSL certificates are designed for a single server or other device, some are designed to be used with multiple devices on the same domain, and still others can be used on multiple servers with different names. (The latter are known as Subject Alternate Name—SAN—SSL certificates). Determining which option is best for you will depend on a few factors:
Your answers to these questions can help guide the selection of the type of SSL certificate you should use.
In addition to the different ways SSL certificates can be associated with servers, there are two levels of verification and assurance that SSL certificate vendors provide. A conventional SSL certificate is granted to a business or other entity that demonstrates it is actually that entity according to the criteria established by the vendor. These criteria could be as simple as having an email address at the domain specified in the SSL certificate request or it could be much more rigorous. The SSL certificate industry established standards for an alternative verification regime and created the Extended Validation (EV) SSL certificate. The industry established common standards for verifying the identity of an EV SSL certificate requestor and ensuring it is a legitimate business. EV SSL certificates are designed to give customers, business partners, and others additional assurance that they are dealing with a legitimate and authenticated business.
SSL certificates are valid for a predefined period of time and at the end of that period, the SSL certificate must be renewed. Tracking SSL expiration dates can be done either on a server‐by‐server basis using OS tools, such as Microsoft Windows Management Console (Figure 4.1) or with SSL certificate management consoles provided by SSL certificate vendors (Figure 4.2).
Figure 4.1: Microsoft Windows OS provides a certificate management snapin for the Microsoft Management Console (MMC).
Figure 4.2: Example console for managing multiple SSL certificates across an enterprise.
Another general task in the SSL certificate life cycle management process is tracking inventory of SSL certificates. Enterprise management consoles are helpful for this task, especially in businesses with Windows, Linux, Unix, and other OSs each of which have its own methods and procedures for managing SSL certificates. By tracking SSL certificates, you might be able to better understand your needs. This understanding can lead to more efficient use of domain certificates, SAN certificates, and other options for reducing management overhead and reducing the cost of purchasing large numbers of SSL certificates.
The PCI DSS defines a range of security requirements for protecting payment card and cardholder data. SSL certificates play important roles in a number of PCI DSS requirements, including authentication and encryption services. This chapter has provided a high‐level checklist for assessing compliance with key requirements. It also provided a more detailed look at policies and SSL management practices that support your efforts to meet PCI DSS requirements.