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 (K1) to encrypt data for two years. At the end of the second year, they rotate keys to key 2 (K2). However, as long as there is data that is encrypted with k1, the key cannot be destroyed. K1 will have to remain active until there is no longer a business need for the decryption of the data that was encrypted using K1.
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…
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?”
As many organizations improve the maturity level of their IT compliance departments, many still struggle with how to translate compliance requirements to tactical operations. Sure, compliance gets it, audit understands it, but this must somehow translate to how the developer actually writes his code or the accountant stores their files. Companies still seem to approach IT compliance in a break-fix fashion and fail to implement the requirements as operational standards.
Similar to many facets of the IT world, compliance departments arose to prominence out of a necessity to fix a big problem fast. Many compliance departments are staffed with the hard working folks that were able to find fixes to the hard problems in a pinch. And as with many areas of IT, there has never been time to think beyond break/fix. Essentially, there was a hole in the bucket and a patch was needed. Unfortunately, the bucket continues to sprout holes in many different places. The problem is that we just keep patching the same old bucket.
Why can’t we find a way to build a bucket that doesn’t leak?
In order for compliance to scale within an organization, accountability for compliance cannot be handled in a centralized manner. We must find a way for the entire organization to bear the burden of compliance. Each team that interfaces with any portion of compliance should have a clear understanding of each of the requirements that affect them and be held accountable for operating within those guidelines. So easy to say, so hard to accomplish.
As a leader in your compliance group, you seem to be stuck in a state of running around policing the organization. You are trying to ensure that the whole company is conforming to the guidelines and standards that they need to be. Just as soon as you are able to get one group of cats back on track, the other group has decided to get crazy with the catnip and raid the fridge for snacks.
The key is clear, concise communication and accountability. It seems like we continue to push the organization, “patch these servers, stop developing bad code, and test the incident response plan.” But did we ever take the time to clearly communicate the expectations to that team? How can we expect to hold them accountable if we never clearly communicated our expectations?
Let’s take a specific example. Like clockwork, it’s two weeks before the end of the quarter and over at Joe Bob’s Online Widget Shop the web server team is struggling to meet the deadlines on remediating their PCI quarterly scan findings. While the team received their scan results at the beginning of the quarter, they are struggling to meet the end-of-quarter deadline. The team is understaffed and over utilized and they just don’t have the budget or time to get it done. The compliance team is forced to work very hard to ensure that the web server team meets their remediation deadlines quarter after quarter.
How can we break this cycle?
In this case, the compliance team should draft up an annual work schedule. This schedule should include each of the PCI requirements that pertain to the team and what their responsibilities surrounding those requirements are. This work schedule would include information on each requirement surrounding the quarterly PCI scanning. It would define when the team can expect scan findings to be delivered, how to engage compliance for re-testing and when the deadlines are for full remediation. These work plans should be presented to the team’s management in order to obtain the proper support.
A solid annual compliance work plan will include the following:
Detailed explanation of each requirement
The work plan should contain a detailed explanation of every requirement that has an impact on each team. This explanation should be provided in clear terms and should indicate the reason or intent of each requirement. Each person affected by compliance should fully understand the requirements that they will be held accountable to.
Calendar of deliverables
The work plan should also include a calendar of deliverables for at least one forward-looking year. This is where the periodic elements of compliance and deliverables are clearly laid out. Examples of periodic compliance elements may include:
- Quarterly firewall and router review
- Quarterly audit inactive user accounts
- Annual off-site storage review
- Annual media inventories
- Quarterly vulnerability scanning
This calendar can be planned out to the day or week and should also define what the deliverable should be.
Now the team and their management are aware of the work effort that is needed in order to support the company’s compliance efforts. The team can now be held accountable for this work throughout the year. If we take it one step further, the team now sees that the level of work will continue to be high unless they implement some proactive measures. So instead of waiting for compliance to deliver the scan findings, they are monitoring the security lists for the versions of software that they support and implementing change in line with expectations. Now the compliance findings are very minimal if they even find anything.
This type of planning, communication and accountability is key to establishing a sustainable compliance program. The communication of expectations and deliverables should be documented and delivered to every team that is impacted by compliance. Once in place, this type of framework allows the compliance organization to measure the consistency of the work produced by the organization as a whole as well as provide the method to hold them accountable.
Don’t rely on the tail wagging the dog approach. You will always find yourself running around in an ever-losing attempt to police the entire organization. Similar to most IT initiatives, in most companies, the compliance group was born out of necessity and like IT are run in a very reactive manner in most cases. Don’t allow the compliance group to get stuck in a constantly reactive mode. Stop reacting and build a plan to make your group proactive. Reporting compliance may be your job, but sustaining compliance is EVERYONE’S job. Build a plan to establish accountability throughout the organization. Communicate it, measure it, improve it. Rinse and repeat.