Chapter 5 Protect Cardholder Data

Protecting Cardholder Data

The Payment Card Industry (PCI) Data Security Standard (DSS) requirement to protect cardholder data encompasses two elements:

• Protect stored cardholder data
• Encrypt transmission of cardholder data across open, public networks

The processes and activities necessary to meet these requirements and the specific sub-items spelled out by the PCI DSS, are simply the implementation of some of the fundamental components of a sound information security program. If you have already put into place the pieces of a solid information assurance program, or you are in the process of doing so, there won’t be a great deal of extra work to do. Your current processes and technology may very well serve to quickly allow you to comply with these requirements without a great deal of additional effort or cost.

In the arena of Information Security (Infosec) there are three fundamental tenets that form the basis for evaluating the effectiveness of the security controls we employ to protect our data. These three tenets are Confidentiality, Integrity, and Availability (CIA). Let’s discuss these briefly, as we will refer to them as we delve into the specifics of protecting cardholder data.

The CIA Triad

These three tenets of information security are referred to as a triad, because they are most commonly illustrated as three points of a triangle. (See Figure 1.1) All three principles must be considered as you manage your data. An undue degree of emphasis on one can lead to a deficiency in one of the others.

• Confidentiality Strives to ensure that information is disclosed to only those who are authorized to view it.
• Integrity Strives to ensure that information is not modified in ways that it should not be. This can refer to modification by either people or processes.
• Availability Strives to ensure that data is available to the authorized parties in a reliable and timely fashion.

PCI Requirement 3: Protect Stored Cardholder Data

The most effective means of insuring that stored cardholder data is not exposed to unauthorized parties (confidentiality) is the encryption of that data. When implemented properly, the value of encryption is that even if an intruder is able to gain access to your network and your data, without access to the proper encryption keys, that data is still unreadable.

PCI standards dictate that stored cardholder data be rendered unreadable (encrypted), but allow you to implement compensating controls to mitigate the risk if you are unable to meet this requirement. Since encryption is such an effective and critical part of protecting data, we will discuss some of the details of encryption methods and the associated advantages and disadvantages.

Encryption Methods for Data at Rest

Disk encryption software can be broken down into two high level categories:

• File- or folder-level encryption
• Full disk encryption

Another option for encryption of key cardholder data is database (column-level) encryption.

Let’s examine the advantages and disadvantages of each as you consider how and where they might fit into your program for protecting cardholder data.

File- or Folder-level Encryption

File- or folder-level encryption (or file system level) is an encryption system where specific folders, files, or volumes are encrypted by a third-party software package or a feature of the file system itself.

Advantages

• More granular control over what specific information needs to be encrypted can be accomplished. Items that you desire to be encrypted can be stored in a particular folder or volume, and data that does not need to be protected can be stored elsewhere.
• Many file-level encryption products allow you to integrate access level restrictions. This allows you to manage who has access to what.
• When data is encrypted on a file level and is moved off the storage location, it is moved encrypted. This maintains the confidentiality of the data when it is moved to a backup tape.
• Less invasive to a database than column-level encryption. The schema of the database does not need to be modified and the access of data by authorized personnel (based on access control) is not hindered when querying and other management activities take place. This is an aspect of availability, one of the three tenets of the CIA triad.
• Tends to consume less resource overhead, thus less impact on system performance.
• Logging and auditing capabilities. Some file-level encryption systems offer the capability to track who attempts to access a file and when. Since the majority of data breaches are internal to the network, this kind of information is good to have.

Disadvantages

• Can cause performance issues for backup processes, especially with relational databases.
• Requires extra resources for key management.
• May not be granular enough when access to certain columns of a database is desired, but others need to be restricted.
• Possibility of encrypting more data than is necessary for PCI compliance.

Full Disk Encryption

Full disk encryption (FDE) or “whole disk” encryption methods encrypt every file stored on the drive (or drives), including the operating system/file system. This is usually done on a sector-by-sector basis. A filter driver that is loaded into memory at boot, encrypts every file as it is written to disk, and decrypts any file that is moved off of the disk. This happens transparently to the end user or the application generating the files.

Advantages

• Everything on the drive (or drives) is encrypted, including temporary files and swap space, increasing security of your data.
• Encryption of data is enforced on end user, alleviating decisions on what or what not to encrypt.
• Encryption/decryption is transparent. When information needs to be accessed, it can be saved off of the system and is automatically decrypted.
• Most FDE systems offer support for pre-boot authentication, which can add another layer of protection to the method.
• Since all data on the drive is encrypted, even if an alternative boot media is used against an encrypted system, the data on the drive is unreadable and therefore useless to the thief.
• Hard tokens, soft tokens, or passwords can be used in most cases for the pre-boot authentication process that allows access to the system.

Disadvantages

• Some FDE programs can cause an increase in data access times. Slight delays in writing and reading data can occur, especially with very large files.
• When FDE systems encrypt on a sector-by-sector basis, fragmentation on the drive can cause significant problems.
• Encryption key management has to be considered. If a key for recovery of data is stored offline, end user support processes for recovery of data need to be put in place.
• Password management processes have to be defined and put into place. If a user loses their password that grants access to the encrypted system, they have no access to their data. This would impact the availability of the data as referenced in the CIA triad model.
• With FDE systems, once a user is authenticated to the system via the password used for the encryption software, full access to all data is achieved. This puts increased emphasis on insuring that strong password or pass phrases are utilized for the pre-boot authentication.
• If the encryption software becomes corrupted or otherwise fails and can’t be recovered with the unique recovery key, the data on the drives cannot be recovered. The only option is to reformat the drive. While this protects the data, it tends not to be very popular with end users.

Implications

In order to ensure that stored cardholder data is protected from access by unauthorized parties, it is likely you will need to utilize both file-level encryption and FDE in your enterprise environment. In addition, access controls around databases and possible column-level database encryption may be needed. Every environment is different. What you need to do will be dependent upon your network and your current design.

FDE is more suited to protecting data on workstations and mobile devices, whereas file-level encryption is more useful as a method on storage devices. A well-designed information assurance program will prohibit storage or transfer of sensitive data to an employee’s laptop or desktop. While this kind of policy and practice would seem intuitive and obvious, it is abundantly clear that such practices are not always followed strictly. The much publicized cases of database managers or analysts putting thousands of clients at risk, because a laptop was stolen which had been used to download large volumes of sensitive data from a storage device, only serves to demonstrate this fact.

Figure 5.2 illustrates the difference in architecture between file-level encryption and FDE.

Database (Column-level) Encryption

Ultimately, the most crucial element of cardholder data that needs to be rendered “unreadable” wherever it is stored, is what PCI DSS refers to as the Personal Account Number (PAN). This is the full account number that identifies both the issuer of the card and the cardholder account. PCI DSS 3.4 states “The MINIMUM account information that must be rendered unreadable is the PAN.”

This is not to say that other elements of cardholder data would not benefit from being encrypted. But since this data is necessary to be stored, it needs to be protected. Other items of data pulled from a card during normal business are never to be stored, and thus should not be residing in a stored database.

Column-level encryption allows a more granular approach to rendering the key cardholder data unreadable, by focusing on the specific data that needs to be protected.

Advantages

• When a table is queried for data in a non-encrypted column, no performance impact is seen. Since no decryption activity is taking place, no delay in reading/writing and no performance hit by system due to encryption software activity is seen
• When a query for a record with data from an encrypted field is performed, the overhead is minimal. Since the decryption activity only has to take place on the individual field or fields that are encrypted, there is much lower overhead.
• It can be used in conjunction with other controls to protect data from administrators. Separation of duties between security administrators and database administrators reduces the risk presented, by allowing a database administrator (DBA) unlimited access to the data you need to secure for PCI compliance.

Disadvantages

• Requires tight integration with the database.
• It is highly invasive to the database design. To implement column-level encryption protection after the fact you will likely have to change the following:
  • Data type of the field being encrypted.
  • References to, and queries of the encrypted field(s) will have to be modified to limit access. Middleware and other applications that interact with the database will have to be comprehended and possibly reconfigured.
• Key management has to be well planned. If the encryption key is hard-coded into scripts, it defeats the security. Keys themselves must be stored in an encrypted state and access controls placed around them.
• Employing column-level encryption can lead to a false sense of security. Merchants and service providers who perform batch processing will commonly end up storing sensitive data in flat files. Additionally, sensitive data is often found in debug and transaction logs. The column-level encryption does not protect this; only file-level encryption would. It has to be remembered that the column that the sensitive data is entered into may not be the only place it is stored. PCI DSS requires it to be rendered unreadable wherever it is stored.

Overview

The pursuit of protecting data from being exposed to unauthorized parties is rarely accomplished on a single level. As will all strong information assurance programs, the best approach is to think “defense-in-depth.” Multiple layers of protection are what guard you from having your plan and procedures defeated through a single point of failure. Column-level encryption might be the answer for a piece of your overall plan for compliance to protecting cardholder data, but it is unlikely to be the entire plan.

Other Encryption Method Considerations

File-based encryption, FDE, and column-level encryption are the most well understood and the most commonly employed types of data encryption at this time. There are other possible solutions you need to be aware of, although the cost and design implementations may be more prohibitive.

Storage-level Encryption

Storage-level encryption is a hardware-based solution and is beneficial for encryption on the file level and directory level, and lends itself well to encryption of removable media and tape media. If your concern is that you are storing sensitive data and you don’t want or need to have the granularity of what is or is not encrypted, this could be of benefit.

Encryption Appliances

If you choose to implement a hardware-based solution for simply protecting tape storage or to encrypt data as it flows between multiple devices, the one advantage that it brings is the reduction of resources for key management. Keys never leave the encryption appliance. Scalability is also a factor, as additional appliances can be added to the locations desired ad design and growth change.

PCI Requirement 4—Encrypt Transmission of Cardholder Data Across Open, Public Networks

As in the case of protecting stored data, the most reliable and efficient way to ensure that your transmitted data is not intercepted (confidentiality) or modified (integrity), is to encrypt it during transmission. PCI Requirement 4 spells out some specific details as it relates to these procedures for communication.

Let’s take a look at some of the specific PCI DSS sub-items in order to illuminate some of the terminology and the implications.

Requirement 4.1—Cryptography and Protocols

This requirement states “Use strong cryptography and security protocols such as secure socket layer (SSL)/transport layer security (TLS) and Internet protocol security (IPSec) to safeguard sensitive cardholder data during transmission over open, public networks.”

An open, public network is essentially any network that contains any kind of gateway device that provides clients on that network wired connectivity to the Internet at large. This describes the networks of pretty much every business today. Anytime your cardholder data is transmitted over the Internet or any network you are unsure is secure, that data has to be protected.

The PCI DSS documentation specifically refers to the following as examples of open, public networks:

• The Internet
• Wireless Fidelity (WiFi)
• Global System for Mobile Communications (GSM)
• General Packet Radio Service (GPRS)

Let’s take a look at the specific protocols involved with securing data when transmitted over these various types of networks, and the way they are applied.

SSL/TLS

SSL refers to a protocol for message transmission known as secure sockets layer, and TLS refers to the protocol that recently superseded it known as transport layer security.

SSL on Web Servers

If you are hosting sensitive data on your Web site, you can protect the data by acquiring a digital Web server certificate and installing it on the Web server. Then you must be sure to allow traffic through your firewall on port 443, as this is the default port that SSL communications use.

SSL on E-mail Servers

SSL protocol can also be used to secure e-mail. This also entails the process of installing a digital certificate on your e-mail server. It’s important to remember that this only causes your Simple Mail Traffic Protocol (SMTP) traffic to be encrypted in transit. The actual e-mail message and attachment will not be. This is where file-based encryption would be of value.

About TLS

Describing the technical differences between TLS and SSL is beyond the scope of this chapter. However, it works in much the same fashion as SSL does, and it is important to be aware of the following:

• TLS is the successor of SSL.
• TLS is best for direct SMTP communication between two e-mail gateways. The contents of the e-mails as well as the communication stream between them are encrypted.
• Most modern Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) e-mail client programs also support TLS. If the client is utilizing TLS, the contents of their messages are also encrypted when sending e-mail to your TLS-enabled e-mail server.

Securing Wireless Networks Transmitting Cardholder Data

Wireless networks are becoming much more common in the business (and home) community. Unfortunately, the security of the communication protocols was not nearly the priority that efficiency and ease of use were to developers of this technology. Things have progressed in recent years, but you have to be careful with wireless technology and be sure you have implemented encryption of the transmissions.

Section 4.1.1 of the PCC DSS specifically states, “For wireless networks transmitting cardholder data, encrypt the transmissions by using WiFi Protected Access (WPA or WPA2) technology, IPSec, Virtual Private Network (VPN), or SSL/TLS. Never rely on Wired Equivalent Privacy (WEP) to protect confidentiality and access to a wireless local area network (LAN).”

Defining WiFi

WiFi refers to particular types of wireless local area networks (WLANs), which utilize any of the 802.11 specifications of the Institute of Electrical and Electronics Engineers (IEEE). This covers pretty much any kind of modern wireless router, including ones designed for small office/home office (SOHO) use.

WPA and WPA2

Earlier versions of the 802.11 specifications for wireless communications used a technology know as WEP, which was found to be woefully inadequate as its encryption scheme was easily broken, and intercepting transmissions was a fairly trivial exercise for experienced hackers. WPA and WPA2 have both been implemented in versions of the 802.11 standards of 802.11i and beyond. WPA makes use of improved encryption standards and authentication methods. WPE should not be utilized, even though PCI DSS provides a list of compensation controls that should be utilized if it is employed.

IPSEC VPNs

IPsec is technically not just a protocol, but a framework or set of security protocols that operate at the Network layer of the Open Systems Interconnection (OSI) model. What this means in basic terms is that IPSec operates at the level of the network where devices that manage the destination of packets (like routers) operate. Accordingly, IPsec is well suited for securing the communication over a VPN.

A VPN can be described as a network that uses public infrastructure (like the Internet) to create a connection between a remote host or network to an organization’s main or home network. This is a much less expensive proposition than using dedicated leased lines to provide this kind of privacy. The way a VPN works is to set up a private “tunnel” using certain protocols, which causes the data to be encrypted at the sending end and decrypted at the receiving end. It can be configured in different ways, but typically involves the installation of connection software on the client, which establishes the secure tunnel to the home network, and network devices on the home network end to serve as the secure gateway.

Another option for VPN is SSL VPN. The main advantage of an SSL VPN solution is that it does not require any additional or specialized software package on the client end. A modern standard Web browser is all that is needed, which utilizes a small plug-in to the browser to configure it.

GSM and GPRS

GSM refers to the communication system that is utilized to support mobile phone networks. GPRS is a wireless communication service that provides connection to the Internet for data transfer for mobile phones and computers. Where this might affect a wireless network and transmission of card data, would be the circumstances of utilizing a GSM/GPRS modem card in a laptop for connection to the Internet. If the requirements for implementation of the VPN and wireless protocols have been observed, it will satisfy issues related to these cards as well.

Using Compensating Controls

The PCI DSS indicates that when you are unable to render cardholder data unreadable (encrypted) “due to business or technical constraints,” you may consider utilizing compensating controls to achieve compliance. Implementing such compensating controls as an alternative to encryption is no small task, however. The amount of planning and management that it will involve can end up being more costly than the investment and work of encryption. You should do a very careful cost/benefit analysis before you decide that attempting to implement the compensating controls listed in Appendix B of the PCI DSS is the way you want to go.

At a very general infosec level, a compensating control can be thought of as an internal control (which can be technical or procedural), which reduces the risk of a potential or existing vulnerability or weakness.

In terms of specific PCI context, this means making sure that locations and databases that are storing cardholder data, are segmented or protected from an organizations other systems by creating a perimeter around that stored data.

The PCI DSS requirement, which is spelled out in Section 3.4.1, however, refers us to Appendix B, which details the following specific requirements which must be met if compensation controls are utilized instead of encryption:

Compensating Controls for Requirement 3.4

“Compensating controls may consist of either a device or combination of devices, applications, and controls that meet all of the following conditions:

• Provide additional segmentation/abstraction (e.g., at the network layer)
• Provide ability to restrict access to cardholder data or databases based on the following criteria:
  • Internet Protocol (IP) address/Media Access Control (MAC) address
  • Application/service
  • User accounts/groups
  • Data type (packet filtering)
• Restrict logical access to the database
  • Control logical access to the database independent of Active Directory or Lightweight Directory Access Protocol (LDAP)
  • Prevent/detect common application or database attacks (e.g., Structured Query Language [SQL] injection)

Let’s break this down a bit and discuss what each of these mean and how you might approach implementation.

Provide Additional Segmentation/Abstraction (e.g., at the Network Layer)

Remember that the key objective is to restrict the access to systems that house cardholder data to only those users and systems that require it.

Segmentation

Segmentation essentially means separating, putting more things in front of those systems. Putting the cardholder data systems in a separate subnet segregated from other parts of the network, is the kind of action that you could take.

Abstraction

Abstraction of data refers to the process of distilling data down to its essentials. In the PCI context, implementation of this would again be to pursue putting more layers in front of the data. A database, for example, could be set up to only have access through another piece of software that queries it, in which case, you could also put logical controls on who can utilize the software making the queries to the database.

Provide Ability to Restrict Access to Cardholder Data or Databases

IP Address/Mac Address

Restricting access based on the IP address or MAC address would involve a network-level device such as a firewall. Systems that need access to a database are identified and included in an Access Control List (ACL), which allows them access. Restricting by IP address can be more difficult when utilizing Dynamic Host Control Protocol (DHCP), where the host IP changes versus the static IP addresses.

Another approach could be to utilize Network Access Control (NAC) methods. NAC technology exists in both hardware and software forms. It is a method where the NAC control sits in front of the subnet you are protecting. Security controls can be enforced and multiple checks for security requirements can be made. If the end point seeking admission to the subnet does not meet the requirement, it is denied access.

Application/Service

The implementation methods referenced in the previous section can also be utilized to restrict access to specific applications or services. Care should be taken here; methods targeted at such a low level can often backfire. Restricting based on a port that an application uses or a services, ends up causing some other application or service to fail which was not comprehended. A thorough researching of details should be made so as to not impact existing operational and network activities.

Data Type (Packet Filtering)

Packet filtering is a network-level activity, typically the work of a firewall. It is the process of dropping or allowing packets based on what the packet header says about its destination, source, its targeted port, or the protocol being used. Again, great care needs to be taken when working on this level. Some things can be identified easily as dangerous or unwanted, but simply “dropping” certain packets can often lead to applications not working, and it being difficult to determine the cause of the issue until someone thinks to examine firewall logs.

User Accounts/Groups

Even if your organization has the most fundamental information assurance program, it is likely that thought has been given to the organization of varying privileges and access based on user accounts and the groups they belong in. All operating systems and databases have the capability to restrict or allow users based on accounts and groups. This is a matter of designing the architecture, documenting it, and implementing it. Any good information assurance program starts with creating rules for access, procedures to demonstrate need for access, and implementation of auditing around when it is granted and when access is removed. No entity should have access to cardholder data without an express need for it.

Restrict Logical Access to the Database

Control Logical Access to the Database Independent of Active Directory or LDAP

This particular requirement is a bit difficult to achieve. It is essentially implying that any centralized directory for user groups and control is untrustworthy. This may or may not be the case in your environment, but the requirement pushes you in the direction of managing access locally. Most enterprise networks are designed to centrally manage accounts, and to grant access to resources based on domain accounts. Therefore it would entail a good deal of process work regarding procedures, documentation, and process to enforce management of accounts locally on the database server or on a dedicated (segmented) Active Directory. Care must also be taken to ensure that the local accounts comply with your own corporate requirements for password compliance as well as with the PCI DSS.

Prevent/Detect Common Application or Database Attacks

The most likely candidate for a technical solution for this requirement is a network-based or host-based Intrusion Prevention System (IPS). This may be technology you already have invested in for your network, as the technology is of benefit for protection and detection of all manner of threats on the network.

IPSes monitor network traffic and take actions according to predefined rules if the traffic activity it sees meets criteria that it deems to be malicious. Many organizations also employ security event management tools. This type of technology gathers information regarding activity on the network from various sources such as event logs, firewalls, IPSes, and Intrusion Detection Systems (IDSes), and aggregates the data to detect suspicious or harmful activity on the network. The operative word in most of these technologies and approaches is prevention. As it relates to detection of attacks, this also assumes that in addition to technology that detects activity (such as IDS and AntiVirus) that procedures are in place where logs are reviewed so that it can be determined if attempts at compromise have taken place.

Overview

The primary requirement in PCI DSS regarding cardholder data is to render the data unreadable. While encryption of data on your network may be expensive, or in some cases technically impractical, it should be pursued if at all possible. The alternative measures required to meet the standards in the form of compensating controls are not trivial to achieve. They essentially require you to put into place a significant amount of internal controls and additional layers of separation from the databases that house cardholder data. Implementing and maintaining the hardware, software, policies, and procedures necessary for this additional internal perimeter could become an odious task. Without great care in implementation, you could still end up not passing a PCI audit, and in the process could break necessary internal data flows, which are required for your processes to work.

Mapping Out a Strategy

Now that we’ve looked at the particulars of the PCI requirements for protecting cardholder data, and discussed some of the technologies and methods available to achieve compliance, let’s take a step back and briefly discuss your approach.

In many cases, organizations involved in handling PCI data existed and were involved with it before the PCI DSS came out. So, networks and architecture processes already existed. If you were designing your network and your plan from the ground up with PCI DSS in mind, you’d do it differently. Attempting to apply specific security standards after the fact is a different (and more difficult) proposition.

By utilizing some of the fundamental principles of developing a sound information management practice, you can avoid a haphazard approach that can lead to problems such as inefficiency, unnecessary cost, insufficient controls, or controls that are more restrictive than necessary.

Step 1—Identify and Classify Information

The first step in achieving your data privacy goals is to identify what data you have and classify it in terms of its sensitivity. There are multiple levels that data can be classified on, but for the purposes of PCI, you need to determine what is and is not cardholder data, and then break down the elements further in terms of sensitivity. You might break it down such as:

• Customer Information
• PAN
• Personal Identification Number (PIN) number
• Non-customer-related data

You can classify your data in any way that makes sense to you, but the most important thing to be aware of is the requirements in PCI DSS Requirement 3 in terms of what is required to be treated as sensitive or not. Your subsequent steps of organization will be based on your decisions here.

Step 2—Identify Where the Sensitive Data is Located

Databases will house cardholder data, but where else might it be? Flat files that are results of batch processing, log files, backup tapes, and storage networks may all house sensitive information.

Ask the following questions:

• Where is it located?
• What format is it in (e.g., database, flat file)?
• What is the size of the data?

Answers to these questions will determine if you have to make changes in your architecture to minimize the cost and work to protect the data.

Step 3—Determine Who and What Needs Access

Too often, data breaches take place simply because people and applications have access to data they do not need. You have to balance the need for access with the proper control on that access to keep doing business. Answer these questions:

• Who currently has access to sensitive data?
• Do they need access to do their job?
• What format is it in (e.g., database, flat file)?
• What is the size of the data?
• What applications such as backup applications or Web sites need access?

Step 4—Develop Policies Based On What You Have Identified

Now that you have identified what data you have, where your data is located, and who and what needs to access it, you can define information-handling policies based on what, where, who, and how. This is where you establish such things as policies, standards, guidelines, and procedures. The details of implementing this are beyond the scope of this book, but numerous resources exist which provide help on how to approach this in an organized way. It may also be of help for you to engage a professional organization or consultant versed in this to help you write and publish these. This will be the cornerstone of your approach to your information assurance plan.

The Absolute Essentials

We’ve approached the protection of the cardholder data from PCC DSS from a high-level, principle-driven approach. The PCI data security standards are published and available, and you need to be familiar with them in detail to insure you are compliant.

Let’s take a moment to review what would be considered the absolutes detailed in Requirement 3.

Keep Cardholder Storage to a Minimum

As part of your development of policies, you will establish a data retention policy. This is a crucial piece of an information assurance plan. There is no need to store sensitive data longer than business, legal, and regulatory requirements dictate.

Do Not Store Sensitive Authentication Data Subsequent to Authorization

Once a transaction has been authorized or “cleared,” there is no justification for storing any of the following sensitive data:

• Full contents of any track from the magnetic stripe on the back of the card
• Card verification code
• PIN
• PIN block (encrypted pin block)

Mask the PAN When Displayed

The first six digits and the last four digits are the maximum that can be displayed. (Point of Sale restriction may be more demanding that this standard.) This is focused on the storage, retrieval, and display of the number.

Render PAN (at Minimum) Unreadable Anywhere it is Stored

This requirement is most easily achieved by encryption. But other methods are allowed, such as a one-way hash, truncating, and padding.

Protect Encryption Keys Used for Encryption of Cardholder Data Against Both Disclosure and Misuse

PCI DSS details 12 different items for the proper management of encryption keys. These will not be detailed here other than to point out that this is again something that would be included in your policies. They include processes, procedures, and who the custodian of these keys would be. The management of encryption keys is probably the most resource-intensive aspect of encryption. Some methods of encryption make this simpler than others. Consider this aspect and make sure you ask the right questions of potential vendors when considering your encryption solution(s).

Summary

Complying with the PCI DSS requirements is not a trivial task. Many organizations are still not compliant and risk fines and data breaches as a consequence. With the proper preparation and execution of your plan, you can protect the information you have been entrusted with. Keep these key components in mind:

• Identify where the sensitive data is on the network, and establish sound policies for handling it based on that identification.
• Securing data at rest can involve encryption or compensating controls, but attempting to segregate sensitive cardholder data by logical and physical controls only can be very tricky.
• Securing data in-transit is important to your organization, regardless of the business you are in. As it relates to PCI standards, it is crucial. When sending data over an open, public network, the data stream must be secured or you risk exposing cardholder data to attackers. One single instance of failure could be the point where you are exploited, such as a wireless router utilizing old and exploitable encryption.
• The place to start to protect yourself and your data is to ensure that you do not store any sensitive cardholder data after a transaction has been authorized. It is not necessary.

Solutions Fast Track

Protecting Data at Rest

• The most sure way of protecting sensitive cardholder data stored on your network is by using encryption.
• Multiple methods for encryption exist including file- or folder-level encryption, full disk encryption, and database (column-level) encryption. Each have their own advantages and disadvantages
• If encryption is not an option, specific compensating controls can me implemented, but they are not trivial to employ.

Protecting Data in Transit

• When cardholder data is transmitted across an open, public network, it must be encrypted.
• IPSec VPN technology is a common way to establish a secure “tunnel” between trusted networks.
• Web servers and e-mail servers need to be configured to utilize secure communication protocols when transmitting cardholder data.
• WiFi network devices need to be secured by current, secure encryption protocols, such as WPA or WPA2.

Compensating Controls

• If an organization cannot utilize encryption to render cardholder data unreadable, it is allowable to utilize compensation controls to provide segregation of the sensitive data.
• Putting a perimeter around storage locations that house sensitive data, can be achieved through various methods of segmentation and abstraction as defined by PCI DSS.
• The ability to restrict access to locations and databases that house cardholder data, must be provided. This can be done on various levels, including restricting access-based IP or MAC addresses, applications or services, data types, users, or accounts.
• Logical access to databases that house cardholder data must be implemented independent of Active Directory or LDAP groups and accounts.

Starting With a Strategy

• Identifying and classifying the data on your network in terms of its sensitivity, is the first step in mapping out your plan of attack for securing it.
• Once you have identified the data types you have, identifying where it is located and what form it is in follows.
• You need to determine what people and what applications need access to your data to fulfill your organization’s business requirements.
• Having established the who, what, and where of your data, you can then develop roles, polices, procedures, and guidelines to manage that data and ensure you have consistent practices

The Absolute Essentials

• Storage of cardholder data needs to be kept to the absolute minimum required to do business.
• Sensitive cardholder authentication data is not to be stored after authorization has taken place.
• The PAN should be masked whenever it is displayed.
• The PAN (at the very minimum) needs to be rendered unreadable wherever it is stored. This can be accomplished by encryption, one-way hashes, and other methods.
• PCI DSS outlines several specific requirements for how encryption keys used for encryption of cardholder data must be managed.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.