Seth Peter CTO, NetSPI November 2009 Contents Why Mistakes Occur 2 Background 2 PCI DSS A Moving Target 3 Many requirements require some interpretation 3 Common Mistakes 5 Firewall rulesets 5 System hardening 6 Application development practices 7 Penetration Testing 8 Third-party service providers 9 Auditing & logging 10 Audit Prep 12 What to expect within an audit 12
Why Mistakes Occur Background Even though the Payment Card Industry (PCI) Data Security Standard (DSS) is one of the most detailed information security program standards in existence, there is still much room for interpretation, and unfortunately, misinterpretation. In conducting numerous DSS security assessments, I have encountered a theme of recurring requirements where the auditor and the merchant/service provider have a difference of opinion. Furthermore, I would fully expect these opinions would differ even more if you were to pull in a second or third auditor. One general consensus is that the DSS is a very explicit and prescriptive stan-dard, even though it has claims to being a risk-based standard. A majority of the requirements are well defined and easy to understand; an audit failure on these requirements is typically based on the assumption that partial credit would be considered and whether or not the amount of partial is enough to sway the auditor s opinion. These are the not the mistakes we are talking about in this whitepaper. We want to discuss the gray areas of the standard, where the understanding of compliant or not is typically obtained through an open dialog with the auditor. These are the requirements where a risk-based approach does apply. This whitepaper is meant to present one auditor s perspective on what it means to soundly meet the gray requirements; which includes firewall rulesets, system hardening, SDLC, penetration testing, service party due diligence, auditing, and logging. Even if by chance I am not your auditor, some general guidance on these topics will certainly better prepare you for your next discussion with your QSA. 2
PCI DSS A Moving Target There is another element of gray areas that must be considered, and that has to do with the standard itself. The DSS is not a static requirement for a number of different reasons. Here are some things you should know about the DSS: The PCI SSC has adopted a two-year lifecycle process for PCI DSS. Therefore, plan accordingly for an update in 2010, 2012, 2014, etc. One thing to be aware of: when the standard changes ever so slightly, there is a resounding impact to the entire PCI community. Minor changes on paper can mean major technology changes or upgrades. Also, with every new change, there are sure to be new audit procedures, and new gray areas. DSS changes are based on input from five major card brands and about 550 participating PCI organizations. The card brands try to accommodate their clients requests. DSS changes incorporate lessons learned from recent breaches. When a new attack designed to steal cardholder data is discovered, the standard will likely be revised as a preventive measure to keep the attack from im-pacting the industry as a whole. The DSS is a technical standard. When technology changes, the DSS must be updated accordingly. We have seen this with encryption and wireless technologies. Out with the old (and vulnerable) and in with the new. Finally, the DSS is a relatively new audit program. Just this year the SSC rolled out a new QA program for its QSA firms. This is a subtle change with a major impact to the audits themselves. The SSC made significant strides to level the audit field and ensure more consistency across all QSAs. While this is a great step forward for the program, it likely means your audit this year and next may be stricter and require more informa-tion than in previous years. There is another element of gray areas that must be considered, and that has to do with the standard itself. The DSS is not a static requirement for a number of different reasons. Many requirements require some interpretation So what exactly is meant by gray areas? To put it in perspective, consider the following two DSS requirements: 1.1.3 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone VS 1.1.5 Documentation and business justification for use of all services, pro-tocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure Requirement 1.1.3 is pretty straightforward; you need to put a stateful inspec-tion firewall in place where the standard calls it out. Firewalls are nothing new to us; they have been around for well over a decade (even if they haven t been installed at your organization that long). But Requirement 1.1.5 asks for some-thing altogether different, 3
a document with a varying amount of detail and an interpretation of which protocols you and your auditor collectively consider to be deemed insecure. Just to make sure we all see a pattern here, let s look at another example: 2.1 Always change vendor-supplied defaults before installing a system on the network VS 2.2.1 Implement only one primary function per server OR 2.2.3 Configure system security parameters to prevent misuse So clearly it s an understandable and easy task to change well-known vendor defaults. I understand it sometimes gets missed and therefore it s an important thing to call out. But, what exactly is meant by one primary function? I know I have my opinion and I m certain you have one as well; are they the same? Likely not, but they could become closer together with some open dialog. The last requirement here (2.2.3) is a classic example of keeping the audit standard at a consistent level, which is a good thing, but it s like an open-ended question. Which parameters should you worry about? Once again, clearly a shade of gray. 4
Common Mistakes So, let s get to the heart of the issue. This chapter covers in excruciating detail (for some) the most common set of requirements that I see as an auditor requiring some discussion. Along with those requirements is a snippet of help to get you started on thinking like an auditor, which should help you better prepare for an audit. Whether your audit is done internally or by a QSA, these requirements still apply, so there is a benefit for everyone to understand things as an auditor might. Firewall rulesets Requirement 1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed Whether your audit is done internally or by a QSA, these requirements still apply, so there is a benefit for everyone to understand things as an auditor might. What level of detail is required for your documentation depends on the complexity and size of your firewall ruleset. At a minimum I suggest every firewall rule should be itemized down to the source and destination IP ad-dress and destination protocols/ports. At this level, include a documented reason why the rule exists and be sure to call out if the protocol is en-crypted or not. Encryption is one measure of determining if an application is risky or not. Requirement 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment Requirement 1.3.1 Implement a DMZ to limit inbound and outbound traffic to only protocols that are necessary for the cardholder data envi-ronment If you ve done your homework for Requirement 1.1.5, you should be well on your way to limiting unnecessary traffic through your firewall. Firewalls were first implemented to keep the bad guy out; the more difficult shift here is to accept that the bad guy could also be inside (as has often been the case thanks to malware). In general, be sure to avoid: Overly permissive outbound rules remember, for a breach to be successful, the data has to leave somehow. Overlapping rules not only does it demonstrate poor rule con-struction, but could create a justification conflict. IP-based rules without port restrictions in troubleshooting rules, it is far too common to just allow all traffic between devices with the intent of restricting 5
later; unfortunately, it s actually much more difficult to do this later than it is now. Uses of protocol ranges use a range of ports only if your applica-tion absolutely requires it, and document your reasons behind it. Requirement 1.3.5 Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ This is a fundamental shift from how we ve historically managed outbound traffic, but the bottom line is: don t allow your back-end systems to ac-cess the Internet, period. If they must process over the Internet, whitelist your processor IPs and required ports and document all supporting con-trols. System hardening Requirement 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vul-nerabilities and are consistent with industryaccepted system hardening standards The points in question here are always what standards are acceptable and how closely must you adhere to them. There are a few standards men-tioned in the audit procedures, which are obviously a good starting point. However, whatever standard you choose to adopt, ensure that your ver-sion of the configuration standard is mapped to the external standard and note any document variations. Simple advice is to spend the time and ef-fort to create your standard; don t just download a guideline and call it your own; an auditor will easily find settings to demonstrate that a down-loaded standard is not properly implemented. Be prepared to demonstrate how you ve implemented the standard. This could be done with a configu-ration and compliance tool or by the results of an internal audit. Finally, itemize all third-party software applications and components, and include them in your standards documentation; many applications have their own security configuration options. Requirement 2.2.1 Implement only one primary function per server If you can describe the one primary function of a server in two words or less, you are probably ok. Ensure the services running on your system are all related to its primary function. Especially avoid the failing examples cited within the DSS audit procedures under this requirement. 6
Requirement 2.2.2 Disable all unnecessary and insecure services and protocols Requirement 2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers Conduct an inventory of all running or installed services and system func-tionality and remove anything unrelated or auxiliary. Especially avoid unencrypted protocols and applications with known vulnerabilities (such as older versions). Requirement 2.2.3 Configure system security parameters to prevent misuse Review the standards document you created to satisfy Requirement 2.2; if it is comprehensive, you should see a number of security parameter settings. Be sure you document and understand all configurable applica-tion or service parameters. Expect to be interviewed on this topic as a measure of implementation. Application development practices Requirement 6.3 Develop software applications in accordance with PCI DSS and based on industry best practices, and incorporate informa-tion security throughout the software development life cycle Map your development standards to both PCI requirements and an Indus-try Best Practice. Consider reviewing the PA-DSS requirements to understand what applicationspecific requirements are applicable. Ensure your SDLC documentation incorporates security throughout all stages. Items that an auditor will look for include: security requirements, risk/threat modeling, code review, security testing (both vulnerability and business logic). Requirement 6.3.7 Review of custom code prior to release to produc-tion or customers in order to identify any potential coding vulnerability Just knowing that code reviews are mandatory won t help you accomplish this colossal task any more easily. If you are not currently doing security code reviews, this will be a tough step to implement, trust me. Consider using a qualified third party for code review, or be sure to document your code review checks and processes. Ensure your developers and/or code reviewers are trained in conducting security code review. Review 7
the OWASP Code Review guide for some assistance in getting this program going. Requirement 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project Guide. Don t just list the OWASP Top 10 in your coding standards, and if you do list them, ensure they are current. OWASP will be releasing a new top 10 for 2010. I suggest included more of the in-depth OWASP information that supports the top ten such as the Cross- Site Request Forgery (CSRF) Prevention Cheat Sheet or the SQL Injection Prevention Cheat Sheet. Requirement 6.6 For public-facing web applications either: Do an application vulnerability security assessment Place application behind a web-application firewall If you choose to conduct application assessments, ensure you are testing all application functionality as an authenticated user, not just running a web application scanner against it once or twice. Also, include manual authorization and authentication checks, as using a scanning product is only one part of the process. Manual testing can have access to valid pa-rameters and account-related business information. In many cases, a tester can do a more effective job of evaluating output to the screen than an automated scanner can. If you choose to implement a web application firewall, ensure you are vali-dating the ruleset applied against your applications and that you have a process in place for updating rules based on your web server, third-party components, and application functionality. If you choose to do both, ensure you are doing at least one of them right. Partial credit for two categories does not equal an automatic pass. Penetration Testing Requirement 11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the envi-ronment). These penetration tests must include the following: 8
Requirement 11.3.1 Network-layer penetration tests Requirement 11.3.2 Application-layer penetration tests Penetration testing is often misunderstood; this confusion stems from the fact that security professionals interchanged the terms vulnerability as-sessment and penetration test for years. That is clearly a shame on us. Despite that fact, it is important to understand: A penetration test is not a vulnerability assessment; tests should attempt to exploit vulnerabilities and weaknesses at the network and application level. An internal penetration test means that it occurs from within your cardholder environment, not just an internal network segment. When you conduct your penetration test, start with a threat discussion and model your tests accordingly. You need to demonstrate that you ve exhausted all high-risk attack vectors. This is a specialized activity, so consider using a third party or, at a minimum, ensure your tester is ade-quately trained. The end goal is to determine if unauthorized access can be achieved. If you can demonstrate it cannot be achieved and your tester is qualified, you should be able to pass this requirement. Third-party service providers Requirement 12.8 If cardholder data is shared with service providers, maintain and implement policies and procedures to manage service pro-viders, to include the following: Requirement 12.8.3 Ensure there is an established process for engag-ing service providers including proper due diligence prior to engagement Due diligence is a new term for many PCI merchants and service provid-ers; but it is an old term for most financial service providers. Consider creating a third-party risk assessment program based on something that already exists, similar to BITS (financial services) or ISO: 27002 (the backbone of nearly every other program). It should include: An assessment questionnaire that you provide to all PCI-related third parties. Interview questions that a risk assessor (third-party or internal) uses to evaluate the third party. Onsite review if the risk or relationship warrants it. Consider your confidence in the provider s ability to satisfy PCI requirement 9. 9
You must establish risk decision criteria that are based on your question-naire, interviews, and onsite review. Determine if you are willing to accept a risk or require the third party to mitigate the risk. Ensure that these risks are dealt with prior to your audit. If you are provided a third-party audit report or ROC, ensure that the scope includes your specific solution. Far too often I see an organization claiming to be PCI-compliant, but when asked about the audit scope, it does not include the service provider solution. Requirement 12.8.4 Maintain a program to monitor service providers PCI DSS compliance status I include this requirement because ongoing assessment programs are harder to implement then they sound. Be sure you conduct this activity on an annual basis, and be prepared to terminate a contract if your secu-rity requirements are not being maintained. Auditing & logging Requirement 5.2 Ensure that all anti-virus mechanisms are capable of generating audit logs Anti-virus systems are often managed by some desktop support function and therefore often left out of the PCI logging effort. Consider sending your AV logs to the centralized log server to adequately meet this re-quirement. Requirement 10.1 Establish a process for linking all access to system components to each individual user If you re asking yourself, should I log this, that, and the other thing, the short answer is yes. Activity logging should include network, system, ap-plication, database, and pretty much anything else you can think of. Requirement 10.5.4 Write logs for external-facing technologies onto an internal log server Another missed component is to include all external systems logs as an-other feed into the internal log server. The DSS is really looking to have all your logs, from everything, in a few consolidated (yet protected) loca-tions. Requirement 10.5.5 Use file-integrity monitoring or change-detection software on logs In order to preserve evidence in the event of a breach, you must treat your logs some- 10
what as if they were live credit cards. Your FIM must be in-stalled and configured to monitoring your centralized log files. Ensure alerting is enabled for log file changes or deletions. Requirement 10.6 Review logs for all system components at least daily Realistically speaking, in order to satisfy daily log review, you must im-plement a rules engine of sorts. Whether you choose to build it or buy it is up to you. To get started, think about your threats to cardholder data and ensure your log file review is triggering on those what if scenarios. Requirement 11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configura-tion files, or content files Far too often, we see FIM solutions only monitoring systems using their default settings. Your FIM deployment must monitor not only system files, but also application files and other areas where cardholder data is stored (databases, transaction logs, etc.) In case you haven t picked up on this yet, monitoring and logging access to cardholder data is a truly massive undertaking. If nothing else, find comfort in the fact you are not alone in this journey to compliance. 11
Chapter 3: Audit Prep In closing, I wanted to offer some helpful tips I have gathered over time to better prepare organizations for an audit. This is yet another gray area that is not even defined within the standard itself. What you choose to do to prepare for an audit will certainly have an impact on how your audit goes. Yet, I also understand that IT staff are constrained with many other pressures and demands, so being efficient in your audit prep is equally important. Engage your auditor early and obtain its detailed project plans, evidence requirements, and planned interview topics. Make a list of all your questionable areas or assumptions, and validate with your assessor prior to an onsite. If you are being audited for the first time or being audited with a new DSS version, consider conducting a gap analysis prior to an audit to under-stand how the new requirements will affect your audit. Organize your artifacts and be prepared to: Show your documentation Discuss how you are meeting the requirement Demonstrate how your technology or process meets the require-ment Your auditor will need to document multiple validation criteria for each re-quirement. What you choose to do to prepare for an audit will certainly have an impact on how your audit goes. What to expect within an audit Unfortunately, gaps happen. To avoid missing audit deadlines: Inquire about any identified gaps daily during your audit or pre-audit Discuss options with your auditor, and try to find the common ground between compliant and business-justifiable To simplify thing, work off of one common gap report that contains your remediation plan and tracking. A Better Approach to Risk, Compliance, and Security Consulting NetSPI focuses on customized, responsive, product-independent consulting. Teams of security professionals with deep technical expertise and specific industry knowledge provide a range of advisory, assessment, and audit services that deliver objective, strategic, actionable results.the result is objective, strategic guidance for your security and compliance needs. 800 Washington Avenue North, Suite 670, Minneapolis, Minnesota 55401 Telephone 888.270.0317 Toll free 612.455.6988 Facsimile 12 6
Revision History Version Date Author Comments 1.0 11/23/2009 NetSPI Document Created 2009, NetSPI All rights reserved. Duplication, distribution, or modification of this document without prior written permission of NetSPI is prohibited. All trademarks used in this document are the properties of their respective owners. 13