Your PCI Risk Assessment in Five Steps

Read to learn about risk assessment and risk management strategy basics and how to develop your own risk management strategy.

How To Conduct Your Risk Assessment And Develop Your Risk Management Strategy 

This post contains the text from the White Paper: Your PCI Risk Assessment in Five Steps.

Download the PDF.

Introduction

PCI DSS Requirement 12.2 requires that all entities annually perform a formal risk assessment that identifies vulnerabilities, threats, and risks to their organization, especially their cardholder data environment (CDE). This requirement helps organizations identify, prioritize, and manage information security risks. 

Organizations that take a proactive approach to security will use internal and external resources to identify critical assets, assess vulnerability threats against those assets, and implement a risk management strategy to mitigate those threats. 

In this white paper, you will learn risk assessment and risk management strategy basics, plus five tips to help you conduct your own risk assessment and develop your own risk management strategy.

The purpose of the risk assessment is to help organizations document potential security vulnerabilities, threats, and risks. 

Conduct Your Risk Assessment

A risk assessment should occur at least annually and after significant changes in your network (i.e., an upgrade or modification that allows access to cardholder data or affects CDE security). This will help provide direction on what vulnerabilities you should address first. Addressing vulnerabilities reduces the time an attacker can compromise the system (i.e., window of compromise). 

Remember, just because a system is vulnerable doesn’t mean it’s exploitable or even likely to be exploited. Some vulnerabilities may require so many preconditions that the chance of a successful attack is virtually nonexistent. Identifying the differing levels of exploitability should help an organization prioritize the actions it will take to enhance its IT security based on each identified vulnerability’s perceived threat and risk level. 

In your risk assessment, make sure to include the following information:

  • Vulnerabilities/threat identification
  • Assessment of current security measures 
  • Likelihood of threat occurrence
  • Potential impact of threat
  • Risk level
  • Scope analysis
  • Data collection
  • Periodic review/update as needed

Step 1: Identify Vulnerabilities, Threats, and Risks

Start your risk assessment by finding the problems within your environment, specifically: 

  • What vulnerabilities exist in the system, application, or process?
  • What threats—internal, external, environmental and physical—exist for each of those vulnerabilities?
  • What is the risk probability that specific threats may take advantage of vulnerabilities?

Consider these categories in particular as you think about your vulnerabilities, threats, and risks: 

  • Digital (e.g., weak passwords)  
  • Physical (e.g., not shredding physical card data)  
  • Internal (e.g., employees)  
  • External (e.g., hackers)  
  • Environmental (e.g., fires)  
  • Negligent (e.g., unknowing employee)  
  • Willful (e.g., disgruntled former employee)  

What are Your Vulnerabilities? 

A vulnerability is a flaw in components, procedures, design, implementation, or internal controls. A vulnerability might be a flaw in your building layout that could lead to card data theft. 

Vulnerabilities can be grouped into two general categories: organizational and technological. Organizational vulnerabilities can include ineffective or nonexistent policies and procedures. Technical vulnerabilities may include flaws or weaknesses in information systems development and implementation.

Some examples of vulnerabilities are: 

  • Unpatched operating system software  
  • Website coded incorrectly  
  • No office security policies  
  • Misconfigured or no firewall  
  • Insecure POS devices 

What Are Your Threats? 

A threat is the potential for someone or something to cause a vulnerability. Physical location, organization size, and systems all have the potential to be a threat. 

Examples of threats can be: 

  • Geological threats, such as landslides, earthquakes, and floods  
  • Hackers downloading malware onto a system  
  • Inadvertent data entry or deletion of data  
  • Power failures  
  • Chemical leakage  
  • Employees
  • Third-party vendors

What Are Your Risks? 

Risks are a measure of the probability that a particular threat will take advantage of a particular vulnerability and the potential impact on your organization and customers.

For example, a system that allows weak passwords is vulnerable to attack. The threat is that a hacker could crack the password and break into the system. The risk is storing unencrypted cardholder data in your system. 

Here are examples of possible risks: 

  • External or removable media: executed from removable media (e.g., flash drive, CD)  
  • Attrition: employs brute force methods (e.g., DDoS, password cracking)  
  • Web: executed from a site or web-based app (e.g., drive-by download)  
  • Email security: executed via email message or attachment (e.g., malware)  
  • Impersonation: replacement of something benign with something malicious (e.g., SQL injection attacks, rogue wireless access points)  
  • Loss or theft: loss of computing device or media (e.g., laptop, smartphone)

A risk example would be when remote access is connected to your CDE without using multi-factor authentication. There is an extremely high probability (high risk) that an external hacker will brute force the password and gain access to the system. 

When threats are likely to take advantage of a vulnerability, that equals your risk.

Step 2: Analyze Your Risk Levels

You need to decide what risks can and will impact your organization. This risk and impact prioritization is a crucial part of your risk assessment that will eventually translate to your risk management strategy. 

To analyze your risk level, consider the following: 

  • Likelihood of happening: Just because you are threatened by something, doesn’t necessarily mean it will have an impact on you. For example, while organizations in Oklahoma and Utah could technically both be affected by a tornado, Oklahoma-based organizations have a higher tornado risk level.  
  • Potential impact: How could this risk uniquely affect your organization? For example, the greatest risk for an organization that processes data online might come from improper coding, while a mom-and-pop shop’s biggest risk might come from physical security issues.

Every vulnerability and associated threat should be given a risk level. The typical designations are ‘high,’ ‘medium,’ and ‘low’ risk. Documenting this information gives you a prioritized list of security issues.  

Step 3: Map Out Your Card Data Flow

After organizational threats have been identified and remediation has been assigned, check if any processes or policies impact your CDE and if additional changes need to be made. 

Identify your scope (i.e., the areas of your organization you need to secure) and map how cardholder data flows within your organization. If you know all the places cardholder data is housed, transmitted, and stored, you’ll be able to better safeguard those potentially vulnerable places (e.g., by encrypting cardholder data). 

Start with the assumption that everything is in scope until you’ve verified otherwise. Verifying that a system is out of scope requires that you confirm proper network segmentation and make sure necessary controls are in place. 

To accurately craft your card data flow diagram, ask yourself:

  • What device(s) am I using for transactions? A virtual terminal? POS system?
  • What happens to the card data after a transaction?
  • Is data encrypted? When is data encrypted?
  • Do I store card data before it’s sent to the processor for approval?
  • How does settlement occur? Real time or end of day?
  • How is data authorized and returned by the processor?
  • Is card data backed up on my system? Are backups encrypted? Is my backup server at a different data location?
  • Where might card data be transferred or moved in processes not part of authorization and settlement?

In addition to this, there are four main parts to consider when defining your scope: 

  • Where CHD starts or enters your entity  
  • What happens to it in your system  
  • Where CHD leaves your environment  
  • Where potential or existing leaks may be  

Where Does Card Data Enter Your Environment?

Identify where all payment card data enters or is created. By doing this, you know exactly where security should begin.

Determine and document how you receive cardholder data, such as the following circumstances:

  • Point of sale (POS) system
  • Mobile POS system
  • Ecommerce website
  • Mail order telephone systems
  • Virtual terminals
  • Outsourced procedures processing under your merchant ID

What Happens to Card Data Inside Your Environment?

You need to know what happens to payment data once it enters your environment. Is it automatically stored in your CDE? Does it go directly to accounting for billing? 

Consider what happens to cardholder data in the following situations:

  • Third-party hosted website
  • Internally-hosted website(s)
  • System batches
  • Terminal connections (e.g., Internet, cellular, analog)

Additionally, you must record all hardware, software, devices, systems, and data storage locations that touch your CDE in any way. 

Knowing where cardholder data is stored helps you to confirm whether or not your CDE is what you think it is.

How Does Card Data Leave Your Environment?

When card data leaves your organization, it’s your job to ensure data is transmitted or destroyed in the most secure way possible. 

Here are some common areas where cardholder data is sent after payment: 

  • Processor
  • Backhouse server
  • Backup server
  • Third party that stores or handles PAN
  • Outsourced management of your systems or infrastructure

Verify Your CDE

You need to know where payment data is stored because it helps you identify what needs to be changed in your card flow process.

Here are common places cardholder data is stored: 

  • Filing cabinets  
  • Workstations  
  • Computers  
  • Servers  
  • Laptops  
  • Email  
  • Applications  
  • Mobile devices  
  • Operating systems  
  • Calendar software  
  • Encryption software

To help discover payment card data you might not know about, regularly run a cardholder data discovery tool (such as PANscan®). These tools help identify the location of unencrypted PAN data.

For example, in a recent study, PANscan results from scans conducted on more than 3,600 computers and 7,011,170 GBs were analyzed, with these scans discovering over 330 million unencrypted payment cards. In this study, 85% of PANscan users stored unencrypted PAN and 5% stored track data (i.e., data inside magnetic stripe) on their network.

After using a cardholder data discovery tool, you can determine whether to fix or add processes to your regular business routine. For example, you might want to securely delete or encrypt the located unencrypted payment data. 

In our recent study, 85% of PANscan users found unencrypted PAN on their network.

Step 4: Create Your Risk Management Strategy

The risk assessment outcome should directly feed into your risk management strategy. 

There are many ways to approach the risk management strategy, but ultimately the process will consist of three main steps: 

  1. Plan how you will evaluate, prioritize, and implement security controls. 
  2. Implement security measures that address the greatest areas of risk first. 
  3. Test the security controls you’ve implemented and be sure to keep an eye out for new areas of risk.

You’re required to complete the risk assessment and risk management strategy at least once a year. 

Although specific items included in a risk management strategy vary, the following points are industry best practices: 

  • Risk level: Each vulnerability discovered should be assigned a risk level. You can get some of this information from your risk assessment, but may have to estimate the rest based on current breach and hacker activity.  
  • Date completed: Including a completion date is great for both PCI documentation and your own records. 
  • Completed by: This is great for organizations where two or more people are completing a risk management strategy together. 
  • Comments: Include a comments section next to each requirement, especially what policy and procedure the item is associated with and how you will implement the task.

It’s difficult, if not impossible, to find every weakness in your organization on your own. To take your security to the next level and to avoid weaknesses in your system, consider implementing additional services such as: 

  • Internal and external vulnerability scans: automated testing for weaknesses inside and outside your network  
  • Penetration tests: live, hands-on testing of your system’s weaknesses and vulnerabilities  
  • Nmap scanning: a simple network scan that identifies open ports and services on your network  
  • Gap analysis: consultation on where your gaps in security and compliance exist and what steps need to occur next

A complete and thorough risk assessment is the launching pad for securing your card data. 

Conclusion

A risk assessment should occur at least annually and after significant changes in your network. It should also help provide direction on what vulnerabilities you should address first. Addressing vulnerabilities reduces the time an attacker can compromise the system (i.e., window of compromise). 

Risk assessments can be a lengthy process, so start by identifying (and resolving) your organization’s top weaknesses, and repeat the risk assessment process for medium and low risks. Then in your risk management strategy, determine and document necessary actions to secure your network.

About SecurityMetrics

We help customers close security and compliance gaps to avoid data breaches. Our forensic, penetration testing, and audit teams identify best security practices and simplify compliance mandates (PCI DSS, HIPAA, HITRUST, GDPR). As an Approved Scanning Vendor, Qualified Security Assessor, Certified Forensic Investigator, we have tested over 1 million systems for security. 

https://www.securitymetrics.com/pci-audit