matt

The subject of segmentation is and probably always will be a hot topic in the world of PCI. Effective segmentation is the primary subject of conversations as organizations struggle to reduce the scope and the subsequent financial impact of achieving and sustaining PCI compliance.  Due to the massive amount of implementation possibilities, it would be very difficult for the PCI SSC to take a specific stance and define what actually constitutes “effective segmentation.”

So this leaves us with every QSA’s and merchants favorite PCI SSC chant. “It’s up to the QSA.”

One big area of the segmentation discussion surrounds the use of VLAN’s as a part of segmenting the CHD. Dr. W. David Sincoskie and Chase Cotton created and refined the algorithms that eventually became VLAN’s and published their work in the 1988 IEEE Network (http://en.wikipedia.org/wiki/Virtual_LAN). Since then, VLAN’s have become a major part of most networking environments today. However, VLAN’s have been getting a bad rap from the security population in recent years.

The PCI Wireless Guideline information supplement that was published in July of 2009 states:

“Relying on Virtual LAN (VLAN) based segmentation alone is not sufficient. For example, having the CDE on one VLAN and the WLAN on a separate VLAN does not adequately segment the WLAN and take it out of PCI DSS scope. VLANs were designed for managing large LANs efficiently. As such, a hacker can hop across VLANs using several known techniques if adequate access controls between VLANs are not in place."

Relying on VLAN based segmentation is not sufficient? Does this suggest that the only method of proper segmentation would air gapping? Which is to say that each network must completely stand on its own, never traversing a common infrastructure. This common infrastructure would include firewalls, switches and routers.

This approach is not feasible in an enterprise environment, nor do I believe is really the intent of this writing, although I’m at a loss as to how they would suggest that you segment if you are not to use VLAN’s at all.

The issue with segmentation is not with the use of VLAN’s for segmentation. The real concern is with how data is managed that traverses one or more VLAN’s. The devices, technologies and processes that are used to regulate, manage and inspect data that flows from a VLAN of one security level to another should be the focus of concern.

Are access lists ok? What about firewalls? How about Deep Packet Inspection?

Access lists are a common way of managing data flow between VLAN’s. Access lists can be applied to routers, firewalls and switches.  If a standard access list is used to manage traffic, the access must be defined for both ingress and egress. An access list entry must be added to allow traffic to exit a VLAN and another access list is needed to allow the traffic to re-enter the VLAN. These access lists create open persistent “holes” for the traffic to pass through

The security concern with this approach is that defined “open” access might have to be used to allow traffic from a level of lower security to a level of higher security creating a possible attack vector or path to enter the area of higher security.

Reflexive access lists (also known as IP session filtering ACL’s) are designed to alleviate this problem by monitoring the connection state and only allowing return traffic for established sessions. For example, if traffic is exiting VLAN1, destined for VLAN2, the RACL notes the destination address and port and will only allow return traffic from that destination and destined for the defined port. This prevents the need to add an access list for return traffic. In-turn reducing the exposure of the open ports when not needed. It is important to note that RACL’s only provide full session awareness for TCP. With other protocols RACL’s use timeouts to remove idle sessions.

A firewall adds an additional level of security to reflexive access lists by providing full session state monitoring for all protocols as well as deep packet inspection capabilities.  Deep packet inspection takes a further look into the payload of the traffic that is passing through the firewall in order to inspect the content contained within the TCP encapsulation.

PCI DSS requirement 1.2.3 states:

Install perimeter firewalls between  1.2.3 any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

VLAN security has come a long way since the introduction of VLAN hopping or double tagging in 2000. Vendors have increased the level of security features in the switches and routers as well as provided more detailed implementation and configuration instructions. In virtually every case, proper configuration of the networking environment reduces the risk of these vulnerabilities.

VLAN’s are an essential part of managing enterprise networking environments. While the most secure network architecture will be a complete air-gapped environment, chances of you coming across one outside of your local donut shop isn’t very high. Don’t be afraid to roll your sleeves up and get your hands dirty with the details. Grab your QSA and pull them into the ditch with you and force them to think.

How do you think I learned?

For those of you who play along on a daily basis, PCI DSS 2.0 has brought many clarifications and a few changes that merchants and service providers must contend with. And while we don’t see the “relaxing” of requirements very often in PCI, version 2.0 brought a much-needed relaxation in Requirement 3.6.4.

DSS versions prior to 2.0 required a minimum key rotation period of 1 year. So if you had 1 or 100 million records encrypted, you were required by the standard to rotate the key on an annual basis. Version 2.0 requires that you change the keys once they have reached the end of their defined cryptoperiod. And the establishment of this cryptoperiod should be based on industry best practices and cites the NIST Special Publication 800-57.

NIST SP-80057 notes many different factors that should be considered when establishing an appropriate cryptoperiod. Some of these factors may include:

• Volume of information encrypted
• Strength of the cryptographic mechanisms
• Retention period of the data
• Security function (data encrypting, key encrypting)
• Number copies of a key
• Overall architecture or design of the cryptographic solutions in production

In general, as the sensitivity of the data that is being protected by the cryptography increases, the length of the associated cryptoperiod should decrease.

Cryptoperiod: The timespan for which a cryptographic key is authorized for use.

PCI DSS Requirement 3.6.5 notes that cryptographic keys can be “archived” for decryption purposes. This is a very vague, yet important statement. There has never been any clear position taken by the PCI Security Standards Council that specifically states that data re-encryption is required as a part of a key changing process. When merchants or service providers go through a key rotation process they rotate the encrypting key and begin encrypting and decrypting any new data with the new keys.  While moving forward they are encrypting with a new key, but any existing data that is required by the business to be accessed must be decrypted with the old key. Unless all of the data is re-encrypted or otherwise protected, the old key must always be available for decryption as long as there is a business need to access the data up to the end of the retention period for the protected data.

Lets take an example. Say a merchant establishes a two year key rotation cycle for their keys based on risk indicators that are outlined in the NIST special publication. They use key 1 (K₁) to encrypt data for two years. At the end of the second year, they rotate keys to key 2 (K₂). However, as long as there is data that is encrypted with k_1, the key cannot be destroyed. K₁ will have to remain active until there is no longer a business need for the decryption of the data that was encrypted using K₁.

Does this mean that merchants and service providers can continue to rotate encryption keys and never address the topic of legacy keys that are readily available to decrypt legacy data? Let’s look further into that topic…

Key States

There are six different key states that are defined in the NIST SP 800-57 documentation. From pre-activation to compromised and beyond, however, for this post I would like to focus in on three specific key states:

Active Key State: The key may be used to cryptographically protect information or to cryptographically process previously protected information (e.g., decrypt ciphertext or verify a digital signature) or both.

Deactivated Key State: A key whose cryptoperiod has expired but is still needed to perform cryptographic processing is deactivated until it is destroyed. A deactivated key is not used to apply cryptographic protection to information, but in some cases it may be used to process cryptographically protected information. When a key in the deactivated state is no longer required for processing cryptographically protected information, the key is destroyed.

Destroyed Key State: Pretty much self-explanatory.

Table 1: Lifespan of a key

In the above table, we have a current cryptographic process that encrypts data for 2 years. The table indicates that that there is a 9 year data retention policy. Data is encrypted with a specific key for 2 years and then retained for an additional 7 years. As long as there is an immediate need to have access to that data, then the decryption key must still be retained in order to access the encrypted data.

Only when the retained data is no longer needed can we no longer require the decryption key. The true end of a cryptoperiod is not reached until the decryption key can effectively be destroyed.

The NIST special publication 800-57 supplies recommended cryptoperiods for different key types. Cryptoperiods will vary for each organization based upon many different elements that make up the overall risk of the keys and the protected data. But as an example, the document points out that the cryptoperiod is 2 or less years for a symmetric data encrypting and 3 or less years for the data decrypting key. That’s a total cryptoperiod of 3 years. Compare that with our above example of protecting data with a 9 year retention. Something’s got to give!

Data that is required to be maintained longer than the defined cryptoperiod of the keys should be protected with a key that has a new/valid cryptoperiod. That protection could vary depending on the architecture, but could come in the form of re-encryption of all of the data, or the rotation of key encrypting keys for example.

Although the PCI DSS does not require a data re-encryption process for legacy data, I highly recommend that organizations provide the appropriate due diligence in establishing appropriate cryptoperiods. Ensure that your cryptoperiods are in-line with your data retention policies. If you need to retain protected data longer than your cryptoperiod then you should establish a process to protect the retained data with new keys with fresh cryptoperiods. Mileage will vary for different organizations on the most efficient and secure way that you can accomplish this. But as usual, these roads continue to lead us back to the question we should all ask more frequently….”do we really need to keep this data?”