The move to a risk-based approach to PCI-DSS rather than a compliance-based approach would enable the transformation of PCI-DSS from a compliance standard to a security standard. On the other hand, the PCI-SSC avoids conflict with other industry security standards, guidance, and recommended best practices by NOT trying to be a security standard. That much is true up to now.
For example, in the case of annual key rotation requirements in section 3.6, there is little ambiguity in v1.2.1, where an annual key rotation is required. If an entity feels that quarterly or monthly encryption key rotations are appropriate, then they have met and exceeded that standard. If the cryptographic cycle is longer than one year, then that organization has not met the standard.
In most cases, the real risk of compromise to otherwise protected data lies not in the age of the encryption key, but rather in the balance of section 3.6 requirements that are NOT addressed by key rotation – specifically the key generation, storage, distribution, and revocation requirements. Generate weak encryption keys, implement weak cipher strength, get sloppy with storage and distribution and allow anyone to arbitrarily change keys at whim – and the frequency at which you rotate keys matters little, even if you change them daily.
But is a QSA empowered to make risk-based decisions regarding the suitability of a client’s key rotation interval? Version 2.0 suggests this: conceivably a QSA may reject the practice of annual key rotation on the grounds that risk factors suggest a more frequent key rotation schedule, perhaps quarterly. If the organization does not meet the schedule mandated by the QSA, then that organization may fail the audit until such time that it meets the “QSA requirement.” The target organization may in turn argue that it has met the standard of PCI-DSS by implementing (and demonstrating) annual key rotation. They will cite “contempt of QSA” as the reason for their failure to comply with PCI-DSS. Who will referee this dispute? What recourse does either the target organization or the QSA have available to them, and what actions might they take to address the conflict?
Similarly, a QSA may determine that an interval of less than one year is appropriate, and that the cryptographic cycle should be five years. How has this met the standard? By the arbitrary judgment of the same QSA who insisted on quarterly key rotations for that (other) organization? If the QSA can demonstrate the risk-based approach used to determine the cryptographic cycle, would this be acceptable? How can this be demonstrated with a high degree of confidence? That is, how do we know that the QSA did not fudge some “voodoo” numbers to support his or her “risk-based” analysis? How will this be communicated to the Acquirers and/or Card Brands?
The only vehicle currently available to communicate deviations from the standard is the Compensating Control worksheet. In its current form, one can well imagine what such a worksheet would look like. But one would be hard-pressed to imagine that such a Compensating Control would convey a strong and convincing argument supporting a lengthy cryptographic cycle well below the minimums established in the PCI-DSS.
As an information security professional, my experience within the payment card security industry has taught me that credit card fraud is not just an information security or information technology issue, but increasingly also a financial one.
In order to process payment cards, organizations must execute agreements with financial institutions (“acquirers”) that legally obligate them to put in place appropriate controls to protect the underlying data. In most organizations, it is the finance and accounting teams that are most familiar with the business processes involved with the acceptance, chargeback and settlement of credit card payment data. Therefore, it is very important that the CFO and finance teams be involved in any effort to construct a sound credit card security program or approach. Such a program should seek to both minimize the risk and the cost of compliance.?The payments community has learned that stolen credit card data is a valuable commodity among criminals; just ask the folks at TJX or Heartland Payment Systems, where breaches resulted in the exposure of credit card data for millions of people.
PCI DSS
The compliance requirements (and the fines for noncompliance) are starting to be pushed down from the credit card companies to financial institutions or acquirers who are, in turn, pushing down to their customers (“merchants” and or “service providers”), contractually requiring organizations to become PCI-compliant. Organizations that have one acceptance channel for credit cards (e.g., a POS or via the web) and use third-party software should self-assess via the Self Assessment Questionnaire (SAQ). Financial professionals should use the published prioritized approach from the PCI Security Standards Council (SSC) to address specific risk areas within their organizations regarding credit card data. Those organizations that have multiple acceptance channels (storefront, Point of Sale and/or via the web) and that store credit card data should involve a Qualified Security Assessor (QSA) if assistance is needed.
Upcoming dates for the standard
There are two important PCI-related dates that are fast approaching, which finance people should be aware of.
July 2010 marks the date after which all merchants must use certified payment applications. A payment application is any application that accepts, transmits or processes credit card data. An example of a payment application is a card swipe machine at a grocery store or a pay at the pump application at a gas station.
September 2010 involves the PCI DSS itself, which will have updates to the standard released that month. These updates will take effect in January 2011.
As an organization that performs a large volume of code reviews and penetration tests, NetSPI is frequently asked which type of application assessment is the best option. Your primary options are a code review or a web application penetration test. Both are recommended and both find many of the vulnerabilities commonly found in web applications as defined by the Open Web Application Security Project (OWASP) Top 10 (http://www.owasp.org). By themselves, neither a code review nor a web application penetration test find all of the vulnerabilities that threaten the application.
Why perform them?
Many regulations either require them or highly recommend them. For example, Payment Card Industry Data Security Standard (PCI-DSS) requires that either a code review or a web application vulnerability security assessment (web application penetration test) is performed annually on any web application that stores, processes or transmits credit cards (PCI Requirement 6.6). In addition, for payment application vendors (i.e. point-of-sale application, etc.) the PCI Payment Application Data Security Standard (PA-DSS) requires a code review and a penetration test targeting the OWASP Top 10.
Picking one over the other
Even though code reviews and web application penetration tests can find most of the same vulnerabilities, they look at the application differently and as a result their findings can differ. Typically both approaches find OWASP Top 10 issues such as SQL Injection, cross-site scripting (XSS), etc. However, the efficiency and effectiveness how each method finds these vulnerabilities can differ. For example, code reviews are better at finding most instances of input validation issues (i.e. XSS or SQL Injection). All of the automated code scanning tools NetSPI uses trace the data within the application from its entry point to its exit point. A web application penetration test can find these instances but it could take days or weeks to prove they exist in the application.
Web application penetration testing
A web application penetration test can uncover vulnerabilities from the outside looking in. These vulnerabilities can be related to configuration or versions. An example might be an older version of Apache with a chunked encoding overflow vulnerability (http://osvdb.org/838). Web application penetration tests can also uncover vulnerabilities that are related to the operation of the application, such as default or easily guessed credentials. Other types of vulnerabilities found by a web application penetration test include:
Access control (forced browsing, etc.)
Session hijacking
Vulnerabilities related to business logic
In addition, web application penetration testing can find these instances easier than a code review. This being said, I am talking about a third-party code review, not a code review done by a person or person familiar with the code or the company’s development processes. Automated source code analysis tools do not find these types of vulnerabilities. Manual testing can be done but could greatly inflate the cost of the code review.
Code Reviews
A code review looks at the application from the inside out. Vulnerabilities commonly found in a code review that cannot be easily found in an application penetration test include logging of sensitive data or application backdoors, as they are not exposed to the outside. Other types of vulnerabilities found by a code review include:
Denial of services caused by not releasing resources
Buffer overflows
Missing or poor error handling
Dangerous functions
Hardcoded password or keys in the source code
Code implementation problems
Missing or poor logging
Look at the statistics
NetSPI has found through our own experience that only a small subset of vulnerabilities found by code reviews and application penetration tests overlap. In NetSPI’s analysis, only 18% of the overall vulnerabilities found were discovered in both the code review and the web application penetration test where both services were performed on the same application (see Code Review Percentages pie chart below). Of the vulnerabilities found in the web application penetration tests, only 14% of the findings are found by both the web application penetration test and a code review (see Pen Test Percentages pie chart below).
Final Thoughts The most comprehensive approach to finding security vulnerabilities in web applications is performing both a code review and a web application penetration test. For critical applications, performing only one of these services can result in many vulnerabilities remaining within the application and unacceptable risk to the organization.
Many brick-and-mortar merchants maintain some type of e-commerce environment. For those of you experienced in management of PCI, this has obvious implications: assessment of infrastructure, firewalls, web servers, server administration, access controls, cardholder data encryption, storage, retention and transmission, database administration and management procedures, web application development processes, logging/auditing, file integrity monitoring, and physical security of the hosted environment – and that’s just what applies directly to the e-commerce environment. A full PCI assessment of the organization would include significantly more, and would be subject to the architecture and the specific nature of that organization’s business models. Basically, that’s a mouthful for saying that e-commerce would require a lot of work during a PCI assessment.
Some organizations that operate an e-commerce environment might find that it is a significant chunk of their business compared with their retail operations. Others find that it’s a very small part. A brick-and-mortar retailer that sells gift cards on the web is an e-commerce retailer, even if this amounts to less than 1% of their revenue. In my travels, I’ve run across this model of e-commerce operations quite often. In other experiences, I’ve seen the opposite extreme – a mixed retailer that derives a significant portion of their revenue from e-commerce operations such as direct fulfillment, store pickup and personal shopper services. In all cases, the responsibility for protecting cardholder data in the e-commerce environment is the same – and frequently utilizes the same or similar technologies, regardless of scale.
Given the amount of attention that e-commerce operations draw during a PCI assessment (which is not in any way meant to detract from the amount of attention drawn to retail POS systems, back office operations and ancillary systems), it is no wonder that there is lots of conversation around the outsourcing of the e-commerce environment. Like anything else treated by PCI DSS – the workload is dramatically reduced through the reduction in scope. Take e-commerce out of scope, and the organization’s PCI DSS program is free to focus on other areas of compliance.
But what parts of an e-commerce environment may be taken out of scope? And is it possible to take the entire e-commerce environment out of scope? The answer is both: “It depends” and “It varies” just as surely as e-commerce environments themselves both depend and vary according to their architecture. But before we can tackle this, let’s be sure that we understand what an e-commerce environment actually is.
We are all familiar with the large e-tailer environment – the ones with the popular web pages that have categories upon categories of items for sales, shopping carts and secure transaction pages for placing orders. We also touched on the retail sites that allow you to purchase gift cards, or to order merchandise or to pre-order items for in-store fulfillment. Clearly, these are also e-commerce operations. In all of these cases, a website at some point completes a purchase by collecting cardholder data from a buyer and then enters order information into some type of an order fulfillment or an order management system. This much is clear. What is also clear is what most often is NOT an e-commerce site: Any site that does not prompt for payment, and doesn’t allow you to purchase anything. There may be catalog items, and pricing information, even product availability information that lets you look up store stock in real-time – but the site never handles any cardholder data. Lots of content and pretty pictures, perhaps flashy videos, but no cardholder data. No, not within scope of PCI. But what about the web site that has a combination of both? It has all of the flash, the ads, the interactive product guides and also allows for you to purchase items – right from your browser. Definitely an e-commerce site and definitely in scope for PCI? Right? Once again, the answer is “It depends” and “It varies.”
In the next blog post, we will examine the implications of distributing these systems across multiple architectures, and the impact that outsourcing some or all of this will have on the PCI scope.
In late March Thales released an interesting report on the state of PCI – “PCI DSS Trends 2010: QSA Insights Report.” The report was written by the Ponemon Institute and it highlights the difficulty of taking into account risk, security and subjectivity within the PCI DSS compliance standard. If you haven’t read it, here’s a link: http://iss.thalesgroup.com/l/program/pcitrendsreport.aspx.
First, the insight that only 2% of organizations fail their PCI audits should raise some eyebrows. Taking it at face value (and there’s certainly room for discussion about that) it indicates that, in general, retailers and payment processing related organizations are taking PCI compliance seriously. However, when combined with another observation in the report, that about 40% of organizations are relying on compensating controls, it illustrates the subjectivity of the standard and of the “auditing” process. There are a number of other conclusions that can be drawn from this high pass rate, and hopefully, the Council will look into them.
Second, the report says that over 50% of the QSAs surveyed observe that information security is still not being taken seriously by the organizations they are auditing. Even though almost all of the organizations covered in the review are addressing PCI, most are not truly addressing security and, by extension, risk – which is a level of maturity that usually requires enlightened management or a breach. This finding further highlights how important it is for audits to be done by competent and honest auditors. Like the point above, this gets at the core of PCI – the standard and the associated subjectivity should evolve to ensure that security and risk be addressed, not just compliance.
Finally, the report states that QSAs feel that firewalls and encryption are the most effective technologies used to protect cardholder data. The number of organizations that think they are doing one thing (with technology) and are actually doing another is amazing. ASV scanning is a very important component of verifying technical compliance, but with self-attestation for many internal components it doesn’t cover nearly enough. With this in mind, the PCI Council should implement further verification to ensure that technology and controls are implemented properly. This would continue to drive the convergence of compliance and security. More reviews – especially third-party – would also help organizations better understand risk and develop mechanisms to mitigate it programmatically.
Overall, the report says as much about the state of the PCI standard as it does about the organizations it covers. Some of the more interesting insights are the implications surrounding PCI’s subjectivity and maturity. The positive take away from the report is that it appears organizations affected by the initial PCI focus (retailers and payment processing-related firms) are taking PCI compliance seriously. To achieve the common goal of reducing IT risk related to PCI data, hopefully the Council will be able use this report (and other similar reports) to enhance the standard to cover more security and risk.
