WHITE PAPER
By: Chris Goodwin, Co-founder and CTO, LockPath
Leveraging GRC for
PCI DSS Compliance
The Payment Card Industry Data Security Standard (“PCI DSS”) is set forth by a consortium of payment
card brands (credit card companies). The standard is comprised of 12 requirements that are further
articulated in more than 200 detailed requirements and associated testing procedures.
These requirements can be roughly sub-divided into two groups: policies and practices. Policies
are generally self-evident, such as described in Requirement 12 (“Maintain a policy that addresses
information security for all personnel.”), whereas practice statements tend to mandate explicit
security solutions (e.g., Requirement 8.3 states the requirement to “Incorporate two-factor
authentication for remote access… to the network by employees, administrators, and third parties.”).
Almost all practice requirements will have an implicit policy requirement.
A Quick PCI DSS Primer
There are many misconceptions surrounding PCI DSS. As such, it is first important to level-set the discussion by summarizing a few key points. Following are some key acronyms, roles and concepts that are important to understand:
• Card Brands, Acquirers, Processors and Merchants: There are three major players in the PCI DSS system. At the top of the heap are the Card Brands. They maintain the card system itself. Next down are the Acquirers, who play mediary between the Brands and the Merchants. Last are the Merchants, who initiate transactions (at the behest of customers) through Acquirers to the Brands. There is one additional player that may also be involved: the Processor. Processors serve as an additional middleman in transactions, providing added value such as aggregating payment card types (e.g., American Express and Discover Card are traditionally “closed” systems, and thus are not necessarily packaged by Acquirers).
• Merchant Levels 1-4: There are up to four (4) levels of Merchant. Level 1 Merchants are the largest and Level 4 Merchants are the smallest (by number of annual transactions per Brand). Each Card Brand maintains their own system for determining Merchant Level, and may not have four levels. In general, the level determines the extent of attestation requirements that must be met annually.
• QSAs and ISAs: A “Qualified Security Assessor” (QSA) is an external auditor who evaluates the conformance of a Merchant to the PCI DSS standard. “Internal Security Assessor” (ISA) is a relatively new designation, and represents an internal auditor who has completed QSA-like formal training. It is a misconception that a QSA is required to complete the annual assessment and attestion process.
• AOC, ROC and SAQ: Merchants are minimally required to file an “Attestation of Compliance” (AOC) on an annual basis to complete the validation process. This filing is typically accompanied by four quarterly “passing” vulnerability scans of in-scope systems. The filing may also include an official “Report on Compliance” that enumerates conformance status for all detailed requirements based on the outcome of an on-site assessment. Alternatively, a “Self-Assessment Questionnaire” (SAQ), which is a more limited report designed for Merchants that are not required to complete an on-site assessment, may instead be required. It is worth noting that on average only Level 1 Merchants are required to complete a ROC and, by extension, an on-site assessment (which can be completed by either a QSA or ISA).
• Enforcement Authority: The Card Brands are ultimately responsible for enforcing their respective security programs. The PCI Council, which maintains PCI DSS and related standards, does not itself have any enforcement authority. This represents another common misconception about PCI DSS. The standard itself is referenced by each Card Brands’ security program, but the contractual relationship is generally between the Brands and the Acquirers, and in turn between the Acquirers and the Merchants . In the event of a cardholder data breach, the card brands will assess a fee to the Acquirer, which will in turn assess an additional fee to the Merchant. There is rarely a direct interaction between the Card Brands and the Merchants.
• Whose Risk Management Program?: PCI DSS is maintained by a consortium of Card Brands as part of their own risk management programs. From the Brands’ perspective, Merchants are as much a part of the threat community as
hackers. As such, one key misconception that Merchants must understand is that PCI DSS does not exist directly for their own benefit and protection, but rather as a risk management treatment (remediation action) initiated by the Card Brands as part of their own risk management programs. It is of the utmost importance that Merchants account for this perspective when incorporating PCI DSS requirements into their own risk management programs, as maintaining the wrong perspective could have a detrimental impact. It is also worth noting that several U.S. states have adopted part or all of PCI DSS as law.
The Role of GRC
It is worthwhile to consider two perspectives when discussing how governance, risk management and compliance (GRC) can assist with PCI DSS conformance. On the one hand, GRC as a discipline provides a fundamental regime that allows for incorporating the PCI requirements into an established risk and compliance management framework. On the other hand, GRC solutions can help with collecting and aggregating various types and sources of data toward helping ease the overhead burden associated with compliance initiatives.
At the end of the day, having a solid GRC program2 allows an
organization to properly frame and address responsibilities without creating the one-off scenario discussed in the next section. Such a program allows the organization to manage its own risk rather than having a risk management approach dictated to them.
The PCI DSS One-Off: A Failed Approach
Historically, one of the biggest problems with PCI DSS compliance initiatives has been conducting it as a one-off security effort, treating the standard as a unique and independent set of requirements instead of integrating the requirements into a holistic GRC program. This one-off approach neglects the reality that PCI DSS is part of the Card Brands’ risk management program, leading to poor scoping of efforts and, in the end, data breaches. One need only look at the examples of TJX3 and Heartland Payment Systems4 to see what happens
when organizations focus their security efforts only on in-scope systems instead of working to secure the entire enterprise. When PCI DSS was first released, most organizations immediately shifted to an approach that had been used for
compliance with the Sarbanes-Oxley Act of 2002 (“SOX”)5, which
meant limiting audits and security efforts to only those systems and applications that were directly in-scope, without providing meaningful security improvements across the entire enterprise. Unfortunately, whereas data contained within “financially significant systems” (as impacted by SOX) may or may not have held much value for outside attackers, systems accepting and processing credit cards for payments absolutely held intrinsic value. As such, attacks on these systems have increased significantly over the past 10+ years, often exposing weaknesses in this one-off security approach.
This one-off approach is most noted by the holes it leaves in the overall defenses of the organization. Systems and applications
considered in-scope for handling cardholder data are often relatively well secured, but surrounding systems are typically less secured. In practice, this merely leads hackers (who operate on efficiency principles) to attack the weakest links (internal, non-PCI DSS systems) in order to gain access to the more tightly controlled cardholder environment without having to defeat it head-on. In many cases this attack approach is even more challenging to detect because internal access to the cardholder environment can be more difficult to monitor, since access is often expected and allowed.
Historically, one of the
biggest problems with PCI
DSS compliance initiatives
has been conducting it as
a one-off security effort,
treating the standard as a
unique and independent set
of requirements instead of
integrating the requirements
into a holistic GRC program.
1 Note that the Processor may also be in the chain, such as aggregating support for American Express (Amex) or Discover Card. Additionally, because of the closed network design, some
Merchants may have a direct relationship with Amex or Discover, though this tends to be the exception to the rule today.
2 Speaking of GRC as a discipline here, not as a technology solution.
3 See http://www.priv.gc.ca/cf-dc/2007/TJX_rep_070925_e.cfm for full details.
4 See http://www.philadelphiafed.org/payment-cards-center/publications/discussion-papers/2010/D-2010-January-Heartland-Payment-Systems.pdf for full details.
The failure in this approach is in focusing too heavily on securing the cardholder environment and in not investing adequate efforts into securing the rest of the computing environment. Moreover, PCI DSS is particularly prescriptive, causing organizations to invest heavily in specific areas without extending key functionality to the rest of the enterprise. This failure is particularly magnified by inadequate extension of monitoring and response capabilities, which are particularly important in reducing the negative impact of a data breach. In an age where major security firms are counted among the compromised6, it is imperative to accept the mantra “Failure
Happens: fail fast, recover faster”.7 This objective can only be
achieved by organizations managing their own risks and meeting PCI DSS requirements through an integrated, holistic approach to enterprise security.
The GRC Approach to PCI DSS
Demonstrably, the one-off approach to PCI DSS compliance is at best ineffective, and at worst likely to lead to increased risk liability and a data breach event. Instead, it is important to adopt a comprehensive approach that allows the business to proactively align PCI requirements to its own risk management program, rather than reactively aligning itself to PCI DSS. LockPath Keylight provides several capabilities that enable businesses to setup and manage an effective and unobtrusive GRC program that meets such an objective.
Policies & Controls
Rather than building your GRC program to fit PCI DSS, it is instead recommended to build it to match the needs of your organization. To that end, the policy and controls frameworks provide a common starting point for defining and articulating the structure and details of that program. Keylight Compliance Manager provides key capabilities that support this approach. If an organization has an existing set of policies and controls, then enabling and configuring those directly within Compliance Manager represents the first step. If those sets do not exist, then the approach may vary, such as starting with enabling UCF8 controls by activating the regulations and standards
that are applicable to your organization (e.g., PCI DSS, ISO 27001/27002, HIPAA, SOX, GLBA). Activating authority documents (i.e., regulations and standards derived from UCF content) in this manner will automatically activate associated controls, which can then be customized accordingly. Similarly,
if policies do not exist, or if a “green field” approach is chosen, template policies associated with those activated controls and authority documents can also be leveraged.
Once a start has been made on policies and controls, the next step is to iterate through the controls, customizing them to your environment. Keylight maintains an auditable history of changes made in both controls and policy documents. The scoping activities should be conducted in a manner that tailor both frameworks to your specific environment, rather than simply trying to adopt PCI DSS requirements without evaluating their appropriateness. Part of the iterative scoping and editing
process should include a risk analysis step that helps weigh the impact of a given control or policy on the business.
Compliance Manager is specifically designed to ease the burden of development of policy and controls frameworks, as well as to expedite the integration of additional requirements, such as from standards like PCI DSS. Furthermore, Compliance Manager can be leveraged to conduct awareness events for users (helping meet security awareness requirements) and to conduct security assessments, as will be discussed below.
Mandated Practices
PCI DSS is considered to be a prescriptive standard, which means that it articulates specific technical measures that must be implemented in order to achieve full compliance. Whereas Keylight does not necessarily support directly implementing these measures, it does provide a ready capability for documenting requirements, issuing awareness events to affected teams and conducting routine assessments 6See http://www.matrixgp.com/Files/StormShield/RSA_Whitepaper_Aug_2011.pdf.
7Source: https://twitter.com/#!/mortman/statuses/171616239087652864. 8 See https://www.unifiedcompliance.com/ for more information.
Adopt a comprehensive
approach that allows the
business to proactively align
PCI requirements to its own
risk management program,
rather than reactively
to ensure that the practices are, in fact, being implemented as required.
As discussed in the previous section, documentation of controls and policies can be performed within Keylight Compliance Manager. It can also be used to conduct assessments to measure conformance with requirements. Vulnerability scan data can also be imported within Keylight Security Manager to help monitor the state of compliance with key directives. And, lastly, Keylight Incident Manager and Keylight Risk Manager can be used to capture deficiencies in practices, as well as to actively manage remediation activities.
Risk Management
A goal for your organization may be to develop and manage its own risk profile, rather than being cajoled into managing to the risk profile of other organizations. To that end, Keylight Risk Manager can be leveraged to identify, assess and manage treatment of risk areas. Risk Manager also provides the ability to track exceptions and follow-up on associated remediation activities. Risk Manager can be used alone, or it can be used in conjunction with other Keylight products to correlate risk items with other content (e.g., policies and controls in Compliance Manager, asset and vulnerability scan data in Security Manager).
The availability of Dynamic Content Framework (DCF) tables within Risk Manager provides the means to create additional
sets of records for managing unique aspects of the risk management program. For example, it may be useful to
break-out risk areas that correspond directly to PCI DSS compliance efforts in order to more efficiently track and report on status (of particular value when tracking remediation activities toward minimizing fines due to non-compliance).
Testing
In an ideal world, all testing could be automated with minimal need for manual input or intervention. However, that time has not yet arrived, which means there is a need for optimizing manual testing activities. Keylight can help manage the testing burden in two key areas.
First, Keylight Security Manager can be used to track
vulnerability scan results. These scans are typically performed on at least a quarterly basis, and remediation of findings must be completed in a reasonable period of time in order to allow for a re-scan that produces a result of “passed.”
Vulnerability scan data can be combined with asset information within Security Manager to help provide a more complete device security history. Additionally, Keylight Incident Manager can be leveraged in documenting deficiencies and tracking remediation status. Security Manager also supports DCF tables, which can be custom-built to support other technical testing activities as well. Second, Keylight – via Security Manager, Risk Manager, Incident Manager and Compliance Manager – can be leveraged for conducting continuous monitoring and testing to ensure that compliance is not only achieved once per year, but is in fact maintained in a reasonably high state year-round. Moreover, Keylight Vendor Manager can be used to assess third parties as part of the overall GRC program to help ensure that any risks represented by these external entities are properly tracked and managed.
Validation
Validation requirements vary depending on the Merchant Level. As was noted in the introduction, Level 1 Merchants are required to complete the Report on Compliance (ROC) that reflects the results of the on-site assessment, as well as to submit the Attestation of Compliance (AOC) and the last four quarterly vulnerability scans (all with passing scores). For non-Level 1 Merchants, a Self-Assessment Questionnaire may be sufficient, along with the AOC and vulnerability scan reports.
Of the three main reports required by PCI DSS, the ROC is the most onerous to complete. It must follow a specific format and contain answers to each of the more than 200 testing procedures.
A one-off approach to PCI
DSS compliance often results
in increased risk factors
for affected organizations
by creating discrepancies
in security levels between
different environments within
the shared network.
11880 College Blvd, Suite 200, Overland Park, KS 66210 / TEL 913.601.4800 / FAX 913.601.4800 / www.lockpath.com
About LockPath
LockPath helps companies of all sizes address the increasingly complex issues of regulatory compliance and risk
management. Its innovative software provides keen insight by correlating security information from multiple data sources with current regulations and policies to gauge risk. Easy to install and manage, the Keylight platform empowers people at every level in an organization to take control and make better business decisions. Founded and led by governance, risk and compliance industry veterans, LockPath is backed by a strong mix of venture capital and technology executives with deep operational expertise across the enterprise, cloud and security industries. The company is headquartered in Kansas City.
Whereas it is desirable to automatically generate a ROC, there is not a convenient way to do so today. Instead, key aspects of the ROC can be collected through various techniques (e.g., assessments within Compliance Manager) and then exported from Keylight and integrated into a properly formatted report.
Both the AOC and SAQ are easily completed outside of the Keylight platform. Nonetheless, by integrating the policies and controls frameworks within Compliance Manager, and by making use of UCF content, most of the AOC and SAQ can be generated within Keylight and then exported for integration into the final document.
Conclusion
A one-off approach to PCI DSS compliance often results in increased risk factors for affected organizations by creating discrepancies in security levels between different environments within the shared network. Such an approach can be overcome by instead focusing on a central GRC program that is designed to manage the organization’s own risk profile, rather than the risk profile of the Card Brands. LockPath Keylight provides several capabilities to help optimize and reduce the overhead burden associated with PCI DSS conformance. Specifically, Keylight can help improve the management of policies and controls, mandated practices, risk management, testing and validation.
