Build and Maintain a Secure Network

No major updates here in PCI DSS 2.0. Requirement 1.1.6 requires a review of all firewall and router rules and configurations every six months. That means that when your annual assessment is due, you should have documentation from at least two of these reviews; that is what your QSA will be asking for. The reviews should be detailed enough to show that an engineer checked every item and validated that it was still needed.

Your assessor will also review documentation for two other requirements in this domain, and while they may not have to be updated through a formal process, many companies have failed parts of their PCI Assessment because they forgot to do something simple like update a configuration standard that referenced outdated, or known vulnerable software. Requirements 1.1 and 2.2 fall into this category. Be sure that during your normal review for Requirement 1.1.6, you review and update your firewall and router configuration standards for Requirement 1.1. Do the ruleset review first and note anything that is not in the standard, then go update the standard so that it matches what is in the ruleset. While it may seem overly picky, an assessor would be right if he noted outdated configuration standards for Requirement 1.1.

In addition, go back through all of your in-scope system types and ensure that their configuration is up-to-date for Requirement 2.2. Most companies fall short on this requirement when they reference out-of-date software packages or versions that have security vulnerabilities in them. For example, if your configuration standards still say to start with a stock build of Sendmail 8.9, an outdated and vulnerable version of Sendmail, you would not be able to pass that requirement.

Protect Cardholder Data

Requirement 3 has two key items to address, and one that may just need to have a fresh set of eyes. First off, Requirement 3.1 mandates that you create retention requirements for cardholder data. Requirement 3.1 has a quarterly requirement to purge old data by way of manual review or automated disposal process. Even if your process is 100% automated, take the time each quarter to make sure that the processes are in fact functioning correctly. During your assessment, expect your assessor to ask you to produce your oldest set of retained data. They will then check to make sure that it does not exceed the retention requirements set forth in the aforementioned review.

Consider expanding that quarterly process to include a review of the actual requirements to retain data. The business, regulatory, and legal environments can easily change more than annually (maybe not all at the same time, but one of the three will happen at least more than annually), so use that time to be sure that you do not need to alter your data retention requirements. If you do, republish the information and perform a new review to make sure you are in compliance with your own policy.

PCI DSS 2.0 gave us some reprieve on key rotation. Requirement 3.6.4 now states that keys should be rotated once they have “reached the end of their cryptoperiod (e.g. after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines.” This formerly was an annual requirement to rotate all keys used for the encryption of in-scope data. Expect some challenges with your assessor here. They may still want to see annual changes, and you may need to educate him on what an acceptable cryptoperiod is for your particular implementation. Your assessor will first look at your key management processes and make sure the requirement to rotate is documented, and then will check your implementation to see if you actually did rotate the key per the document. This becomes challenging on new installations with longer cryptoperiods (say a new installation with a three year rotation requirement), so again, expect an education session. While you are reviewing your documentation for this, take a look at the overall key management processes and procedures and ensure they are up-to-date for Requirement 3.6. Common gotcha’s here include forgetting to update the key management processes when you change encryption technologies. That’s a big, red flag for an assessor, and it is pretty easy to spot.

Maintain a Vulnerability Management Program

Vulnerability management is a task that is easily seen as ongoing. New vulnerabilities and viruses are found every day, and companies need to take the appropriate precautions to ensure that they are protected. Requirement 5.2 has one of those few pesky occurrences of the word “periodic” in it as a carryover from older PCI DSS versions. To comply with this requirement, you must perform periodic scans of your in-scope machines.

With the ever-changing landscape of attacks and malware, you should probably scan your systems at least once a month, and likely more frequently. More of the quality vulnerability vendors offer unlimited scanning; you can use freeware tools such as Nessus as well for internal scans and “unofficial” external scans (those not performed by an ASV). To determine how often you should scan your systems, perform a risk analysis of these systems and include elements such as the criticality of the systems, amount of processing power, business hours and uptime requirements, bandwidth, and the frequency by which you update your antivirus definitions. Such risk analysis is in fact prescribed in Requirement 12.1.2. (Security policy must include “an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment”). PCI DSS does not give you a time period for performing a full scan, but most assessors would probably accept quarterly as an acceptable period if you were including on-demand scanning as well. It’s a slippery slope with many variables, but more frequent scanning followed by the ongoing remediation is clearly better. If you do your homework, you can take your assessor on a journey through your logic, with documentation to back it up.

Security patches must be installed within one month of their release. This particular requirement will quickly ruffle the feathers of system administrators, and particularly those of mainframes and large databases. These systems have high availability requirements and typically are not brought down frequently to install patches. When looking at Requirement 6.1, be sure that the patches you are considering installing are actually security related. Only those patches must be installed according to this schedule. Alternatively, if you have a way to mitigate the vulnerability without installing the patch, do that. Since PCI DSS version 1.2, the note below Requirement 6.1 allows you to take a risk-based approach on your patches, and prioritize critical systems first. Then you can patch the remaining systems within three months (quarterly) or longer instead of one.

Finally, be sure that you scan your public-facing Web applications at least annually, or after any changes for Requirement 6.6. Your assessor will review your policy and procedure documents, as well as review the output from processes like the above to make sure it is occurring as prescribed. If you do not want to go through this process, Requirement 6.6 allows you to use a Web Application Firewall (WAF) in lieu of the above process. Most companies end up choosing a hybrid of the two. They may have a WAF protecting their applications, and also perform an automated web application security scanning as needed. Keep in mind that both scanning and WAF monitoring are ongoing tasks; scanning is periodic while WAF management is continuous. Also, keep in mind that scanning is not terribly useful unless vulnerabilities found by the scanner are actually fixed!

Implement Strong Access Control Measures

Strong access controls are key to preventing unauthorized access to your data. While Requirement 7 does not specifically have a mandate to review access granted to cardholder data, consider adding it to your quarterly Sarbanes–Oxley review (or if you do not do these, review cardholder access quarterly). This will help to keep only those with a business or job-related requirement to access in-scope data part of the access groups that grant this type of privilege.

For those that do have a requirement to access in-scope data, be sure that users inactive for more than 90 days are disabled or removed (Requirement 8.5.5). To save time, build an automated process to do this, and assess the process quarterly. Be sure to document everything you find! While you are doing this, think back to the last time you changed your password. Did all systems you access force you to do it at least quarterly? If not, follow up on that now. Don’t wait for your annual assessment to learn that your systems are not requiring quarterly password changes (Requirement 8.5.9).

Do you use off-site storage for tape backups or hard copy media? If so, be sure you visit it at least annually and review its security.¹ Some of these facilities have annual assessments performed and can provide the documentation to you upon request. If they do this, be sure you have a chance to review the methodology used by the assessment company, and it includes common security controls in the scope of the review. SSAE 16 assessment reports are often provided for this type of due diligence. You may want to do this in conjunction with your annual media inventory process for Requirement 9.1.1.

Finally, one of those requirements without a stated review period is Requirement 9.2. You developed procedures to visually distinguish identification provided to both visitors and employees. Make sure it is up-to-date, addresses all personnel, and is still accurate as part of the hire and fire process.

Regularly Monitor and Test Networks

It’s time for one of our more frequent periodic review elements—daily log review for Requirement 10.6. Chances are you don’t have a team of people driving themselves insane by reading every log generated by every in-scope device. You most likely have some tools to collect, aggregate, normalize, and correlate these logs. As part of that process, the log management tool should be intelligent enough to find items that are not part of normal operations and create alerts to your staff for follow-up. Have your internal assessment group periodically assess this process to make sure it is working as designed. It is more important to review an ongoing process for log review and to make sure it is current and active than to review every single log manually.

Next comes Requirement 11. Almost all subrequirements under Requirement 11 have some kind of periodic action associated with them. Starting with Requirement 11.1, quarterly running a wireless analyzer at all of your locations to search for unauthorized wireless activity. As we discussed in Chapter 7, “Using Wireless Networking,” doing a quarterly walk-through may not be the best idea from a resource and threat mitigation perspective. If you only have one location the logistics might work, but from a security protection perspective you are not doing everything you should. If you have chosen to deploy Wireless IDS/IPS technology instead, perform a quarterly assessment of the systems to ensure they are properly alerting and deploying defense and containment measures that you configured.

Next comes the quarterly scans. Requirement 11.2 requires that both internal and external scans are performed at least quarterly, with clean scans being the desired outcome for both of those operations. Save each of those clean quarterly scans in a special place because your assessor will need them as part of the on-site assessment review. Here is another requirement that can benefit from network segmentation as a scope reduction exercise. Companies are required to scan all in-scope internal systems, and all external IP Addresses. PCI DSS scoping instructions state that systems connected to networks that process cardholder data are in-scope for PCI DSS, even if they do not process or store cardholder data themselves. Thus, putting firewalls between these systems will reduce the amount of work you need to do for your internal scans. Externally, you can reduce the scope of your scans by air-gapping networks (meaning that the networks that process cardholder data externally are physically disconnected from ones that do not) or other strong segmentation techniques. Every situation is slightly different, so it is best to check with your QSA or ISA on which method works best for you.

Although those quarterly scans should address most of your vulnerabilities, you must also perform a deeper inspection of your systems and applications at least annually with a Penetration Test (Requirement 11.3). Two common mistakes companies make are forgetting to include applications (Requirement 11.3.2) and neglecting to perform the penetration test from an internal perspective as well as an external perspective. The penetration test is one of the most critical periodic requirements used by PCI DSS. The quality of your assessment will directly impact the likelihood of being caught up in a breach due to an external (or internal) attack. Your penetration test should include the following elements:

Once your test is performed, be sure to address any findings and have them rechecked to make sure your fixes worked.

Finally, Requirement 11.5 has two distinctly different periodic requirements to consider. The first is to perform critical file comparisons at least weekly, meaning that all in-scope machines (including the Point of Sale) should have some kind of file integrity monitoring run on its files. Whether you go with a commercial solution, or script something using a hashing utility like sha5sum, be sure that you run those comparisons at least weekly and for the second part of the review, follow up with any exceptions that come out of the process. The only reason an exception would be generated by the file integrity process is if you deployed a system update or patch and can track the exception back to a change control ticket, or if something bad was happening (maliciously or not) to the system. Both should be followed up on and closed appropriately.

Maintain an Information Security Policy

If you have not had enough with documentation, here’s some more periodic requirements specifically for your information security policy and framework. Requirement 12.1 has two subrequirements with an annual review requirement, Requirement 12.1.2 mandating an annual risk assessment, and potentially as a part of that, Requirement 12.1.3 mandates a policy review. Your organization probably already performs some kind of annual risk assessment as a part of normal operations. You may be able to tag along with that, but be sure to include an assessment of risks relevant to PCI DSS. If you ignore all in-scope systems and don’t include the risks associated with storing cardholder data, the risk assessment is not much help to your PCI efforts. Including your policies in the risk assessment might be a nice way to kill two birds with one stone. Be sure to update your policies to address findings in the risk assessment! Your assessor will look for this!

One of the more abstract requirements deals with daily operational security procedures (Requirement 12.2). This should include (but not be limited to) things like following up on log alerts, searching for new threats to systems, and checking on vulnerability data. Your assessor will want to see your definition of these items, and will want to see evidence that you are following the process. A simple (but probably not scalable) way to do this is to have a ‘SOC Analyst Diary’, a text file on a shared drive or other common area where personnel write to when they check things—even when nothing out of the ordinary is found.

Security awareness training is something that is often overlooked, but critical to maintaining a secure company (Requirement 12.6.1.b). You must demonstrate this ongoing educational process occurs at least annually and for all new hires. Limiting this type of training to only once per year will meet PCI DSS, but it is a bit too relaxed to be considered a security best practice. Find fun ways to engage your employees on information security. Do demonstrations or exercises often. Consider posting things in break rooms or common areas where employees congregate. Add something to their pay stub. Or even involve them in a demonstration like “Find the Bad Guy” where you have an employee walking around with a fake badge, or maybe no badge at all. Offer prizes like Starbucks or iTunes gift cards. You will be amazed at how well this will improve the weakest link in your security chain: people.

None of us want to invoke an incident response policy, but like your last will and testament, it needs to be defined and planned in case something bad happens. Requirement 12.9.2 mandates annual testing of the incident response policy. Instead of hiring someone to steal something from your company, consider doing a table-top exercise whereby you simulate a relevant and creative incident, and walk through all the steps in your plan. This will help your employees understand their roles and will ferret out problems or gaps in the process. In addition to doing this, you must train your staff with security breach responsibilities so they have the specific skills needed to respond. This may include sending key employees to forensics training, or Continuing Professional Education (CPE) classes around breaches and their aftermath.

The Case of the Compliant Company

Peggy’s Pad Thai Palace, a national Thai food chain, enjoyed quick success with its multiple brands and quality food. Peggy’s vision was to create two sides to the business and started with a high-quality dining experience in freestanding restaurants. Once she had her recipes down, she figured out how to prepare something very close to the same quality and taste in a mass-produced way, and opened hundreds of stores in shopping malls across the country. Her success spread like a wildfire, and before she knew it, she was managing a billion-dollar enterprise with more than 3000 locations.

She began accepting credit cards in her mall locations five years ago, and quickly ascended through the levels to become a Level 1 merchant. Before she became a Level 1 merchant, she attended many conferences and seminars geared toward restaurateurs, and heard alarming stories about how people lost their restaurants because a hacker breached their point of sale systems and stole credit card data. Peggy was determined not to let that happen to her.

Peggy began investing in security soon after hearing these stories and had a full enterprise security assessment performed to see how she stood up against the ISO Standards on information security (17799 at the time, 27002 now). She further invested in a framework to address the gaps discovered during the assessment, and within two years had a mature ISO program, complete with compliance management. She hired a small staff of individuals to handle her information security and compliance needs, and after completing several internal assessments against PCI DSS, she set out to find a QSA.

Her QSA came on board during the next quarter, and was duly impressed at how organized her processes and systems were. Through segmentation and other scope reduction techniques, Peggy had reduced the scope to the POS terminals and one additional machine per store, three machines at the corporate office, and a few routers and switches in between. Overall, it was less than 1% of her total infrastructure. She also was sure to complete internal preassessments before the QSA arrived, and had all the documentation built and ready to go.

Peggy approached compliance as a cost of doing business, and was sure that she invested in security to cover her compliance needs. Her company went into each assessment KNOWING the outcome would be positive, and never had an issue passing her compliance assessment, and building security best practices to cover security threats where PCI DSS did not.