• Jim Seaman

PCI DSS: Make It A Risk Business


For any business that is looking to enhance their payment card security or make preparations for what the release of PCI DSS version 4.0 might bring, there are less productive things you could do than to familiarise yourselves with NIST's Risk Management Framework (RMF).

What is the RMF?

The RMF sets out a process for integrating security privacy and cyber supply chain risk management activities, through the application of a risk-based approach to control selection and specification considers effectiveness, efficiency, and constraints due to applicable laws, directives, Executive Orders, policies, standards, or regulations.

Managing organizational risk is paramount to an effective PCI DSS compliance program; the RMF approach can be applied to new and legacy systems, any type of system or technology, and within any type of organization regardless of size or sector.

Just like any process, the RMF has defined the steps needed for success:

  1. Prepare. Essential activities to prepare the organization to manage security and privacy risks.

  2. Categorize. Categorize the system and information processed, stored, and transmitted based on impact analysis.

  3. Select. Select the set of mitigation security controls (e.g. PCI DSS, SP800-53, etc.) to protect the system based on risk assessment(s).

  4. Implement. Implement the controls and document how controls are deployed.

  5. Assess. Assess to determine if the controls are in place, operating as intended, and producing the desired results.

  6. Authorize. Senior official makes a risk-based decision to authorize the system (to operate).

  7. Monitor. Continuously monitor control implementation and risks to the system.

Benefits of the RMF for PCI DSS

Whereas traditionally the PCI DSS has identified the threats and risks to payment card operations and have provided businesses with a catalog of security controls to help mitigate these risks, it has been intimidated that v4.0 will be more risk-focused (being able to show how their specific implementation meets the intent and addresses the risk) and will have the following key high-level goals:

  • Ensure the standard continues to meet the security needs of the payments industry.

  • Add flexibility and support of additional methodologies to achieve security.

  • Promote security as a continuous process.

  • Enhance validation methods and procedures.

Consequently, by adopting the RMF approach across an organization, you will gain a better understanding of the threats, risks and how your security controls are helping to mitigate these.

Applying the RMF across your Enterprise

In light of the ever-evolving regulatory and legal demands, as well as the growing cybercriminal threats, it is increasingly likely that your business will have more than just the payment card operations that they value and which could present an impact on the business - should they be compromised for Confidentiality, Integrity or Availability (CIA).

Therefore, by starting to prepare the organization to evaluate the risks across your whole organization, you can start to identify the risks and proportionate mitigation controls that can applied against the same category of assets.

Across your organization, you will benefit from creating a network of individuals with defined risk roles and responsibilities, in support of the RMF:

For example,

Where you wish to manage the risks from existing or emerging, vulnerabilities you may choose to implement the NIST SP800-53 RA-5 controls:

a. Monitor and scan for vulnerabilities in the system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system are identified and reported;
b. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
1. Enumerating platforms, software flaws, and improper configurations;
2. Formatting checklists and test procedures; and
3. Measuring vulnerability impact;
c. Analyze vulnerability scan reports and results from vulnerability monitoring;
d. Remediate legitimate vulnerabilities [Assignment: organization-defined response times] in accordance with an organizational assessment of risk;
e. Share information obtained from the vulnerability monitoring process and control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other systems; and
f. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned.
Discussion: Security categorization of information and systems guides the frequency and comprehensiveness of vulnerability monitoring (including scans). Organizations determine the required vulnerability monitoring for system components, ensuring that the potential sources of vulnerabilities—such as infrastructure components (e.g., switches, routers, guards, sensors), networked printers, scanners, and copiers—are not overlooked. The capability to readily update vulnerability monitoring tools as new vulnerabilities are discovered and announced and as new scanning methods are developed helps to ensure that new vulnerabilities are not missed by employed vulnerability monitoring tools. The vulnerability monitoring tool update process helps to ensure that potential vulnerabilities in the system are identified and addressed as quickly as possible. Vulnerability monitoring and analyses for custom software may require additional approaches, such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can use these analysis approaches in source code reviews and in a variety of tools, including web-based application scanners, static analysis tools, and binary analyzers.
Vulnerability monitoring includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for flow control mechanisms that are improperly configured or operating incorrectly.
Vulnerability monitoring may also include continuous vulnerability monitoring tools that use instrumentation to continuously analyze components. Instrumentation-based tools may improve accuracy and may be run throughout an organization without scanning. Vulnerability monitoring tools that facilitate interoperability include tools that are Security Content Automated Protocol (SCAP)- validated. Thus, organizations consider using scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that employ the Open Vulnerability Assessment Language (OVAL) to determine the presence of vulnerabilities. Sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). Control assessments, such as red team exercises, provide additional sources of potential vulnerabilities for which to scan.
Organizations also consider using scanning tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS). Vulnerability monitoring includes a channel and process for receiving reports of security vulnerabilities from the public at-large. Vulnerability disclosure programs can be as simple as publishing a monitored email address or web form that can receive reports, including notification authorizing good-faith research and disclosure of security vulnerabilities. Organizations generally expect that such research is happening with or without their authorization and can use public vulnerability disclosure channels to increase the likelihood that discovered vulnerabilities are reported directly to the organization for remediation. Organizations may also employ the use of financial incentives (also known as “bug bounties”) to further encourage external security researchers to report discovered vulnerabilities. Bug bounty programs can be tailored to the organization’s needs. Bounties can be operated indefinitely or over a defined period of time and can be offered to the general public or to a curated group. Organizations may run public and private bounties simultaneously and could choose to offer partially credentialed access to certain participants in order to evaluate security vulnerabilities from privileged vantage points."

By adopting and implementing a single vulnerability management practice against your various higher-risk assets, you employ a single suite of vulnerability management practices to help reduce the risks to your higher category assets, and can use this against other compliance initiatives, e.g.,

  • PCI DSS:

  • 6.1. Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

  • 6.2. Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release. (Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.)

  • 11.2. Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

  • ISO/IEC 27001:2013 - A.12.6.1 Management of technical vulnerabilities.

  • NIST Cybersecurity Framework and NIST Privacy Framework - ID.RA-1: Asset vulnerabilities are identified and documented.


Rather than waiting for the release of PCI DSS v4.0 (now delayed until Q4 2021), why not start looking at your organization from a business risk perspective to identify what is important for your business and which need to be afforded proportionate and appropriate security controls to help reduce any identified risks, to within acceptable tolerance levels.

Try to change your way of thinking from being compliance-focused to being risk-focused, so that rather than thinking:

  • 'What is the minimum amount of work, time, effort and costs do I need to apply to Tick the PCI DSS box?'

To one more aligned to:

  • 'How much is that business process/operation worth?'

  • 'What will it cost the business, in the event that it suffers a CIA compromise?'

  • 'Are the security controls proportionate to the risks?'

  • 'As a key stakeholder of the business, am I comfortable with the level of residual risks that remains, once the mitigation security controls have been applied?'


Many organizations may be dreading the changes and difficulties that may come with the significant overhaul of the PCI DSS controls framework (v4.0). However, for too long PCI DSS has been compliance-focused, rather than risk-focused, which is almost like putting the cart before the horse. https://www.tamr.com/blog/carts-horses-building-foundations-digital-transformation-published-datanami/

  • It's naturally easier for a horse to pull the cart, rather than for the horse to push the cart along and there's a greater chance of reducing the probability/likelihood of hitting an obstacle or pothole and causing significant damage to the cart, or disruption to the journey.

Previous PCI DSS models have created a 'tick box' culture and an increasing number of businesses failing to achieve or maintain PCI DSS compliance, as part of their business as usual activities:

Let's hope that a greater focus on identifying and appropriately mitigating risks, let's hope there's an improved business understanding and embracement for securing payment card data operations, which results in improved security cultures and profiles to make it more difficult for today's opportunist criminals.