ZenGRC

Simply Powerful GRC

PCI

PCI Penetration Testing: Understanding the Objectives, Components, & Methodology

· ·

Organizations that process credit card payments must comply with the Payment Card Industry Data Security Standard (PCI DSS) to protect cardholder data—and while PCI DSS requirements include many prescriptive elements, one that often confounds businesses is penetration testing. To achieve PCI DSS compliance, businesses have to find penetration testing methods that prove the organization’s security controls protect the cardholder data environment.

What Is PCI Penetration Testing?

A penetration test (commonly known as a “pen test”) is an exercise where a security professional attempts to exploit vulnerabilities and gain unauthorized access to your critical systems. These contractors are also known as “ethical hackers,” since they use techniques similar to real phishing schemes or cyber-attacks. The only difference is they are acting with your permission, to discover areas in your network where information security should be tightened. 

Three types of pen testing exist for PCI DSS:

  • Black-box assessments, where the client company provides no information to the tester before the pen test starts;
  • White-box assessments, where the client provides network and application details to the pen tester; and 
  • Grey-box assessments, which provide some information about target security systems, but not all.

White-box or grey-box assessments offer organizations better insight into their environments. That preliminary information the client company provides also streamlines the testing process, which means less cost and fewer demands on resources and time.

How Do I Pass a PCI Compliance Scan?

The Payment Card Industry Security Standards Council (PCI SSC) was created by the major credit card service providers to establish security standards (that is, PCI DSS) for all companies that process credit card information. The standards stress the need for frequent compliance scans to identify and remedy any potential vulnerabilities.

Depending on a company’s merchant level, however, it might not need a penetration test to be compliant. Some categories of self-assessment questionnaire (SAQ) don’t require a pen test, so be sure to understand which PCI security standards apply to your business before you begin your risk assessment.

The official requirement for organizations that do need penetration testing is a passing scan every 90 days. A business must also submit to additional testing if there are any changes to its cardholder data environment (CDE). Passing these scans indicates that your IT controls work and that the security protections you have in place satisfy the standards required of your particular organization.

If a company doesn’t pass its pen testing, the business must correct the failure as quickly as possible and run another scan to prove compliance.

Non-compliance with PCI DSS can carry serious consequences, including the loss of your credit card processing privileges. So it’s critical that you resolve any security issues a pen test might uncover. Passing a penetration test means the tester was unable to exploit any aspects of your system.

How Do a Penetration Test and a Vulnerability Scan Differ?

Vulnerability scans are meant to identify, rank, and report security vulnerabilities that can compromise a system. Traditionally, organizations must engage in vulnerability scans every quarter or after making significant changes to the data environment. Most often, vulnerability scans use automated tools followed up with manual verification of issues.

Penetration testing, however, purposefully seeks to exploit vulnerabilities in security controls by seeking out gaps in security features. Pen testing is an active process of trying to break a system, while vulnerability scanning passively reviews a landscape for potential problems. The manual nature of pen testing takes more time, provides a more comprehensive resource, and therefore, only needs to occur annually rather than quarterly.

Penetration testing’s depth and cost also mean that organizations must limit the time spent on the task while meeting PCI DSS requirements. Meanwhile, vulnerability scanning limits a company’s insights to the point in time during which the scan was run.

What Are the Qualifications of a Good Penetration Tester?

According to PCI guidance, pen tests can be run by either a qualified internal assessor or an outside contractor. Some certifications for pen testers do exist; examples include the CEH (Certified Ethical Hacker) or the OSCP (Offensive Security Certified Professional). Beyond these certifications, the PCI DSS also offers a list of penetration testing requirements and necessary qualifications for penetration testers.

When hiring a penetration tester, ask for examples of their previous work. You will want someone who has experience testing your particular industry and software. Discuss what parts of your environment should be tested, and what your tester should do if a vulnerability is found. You’ll also want your tester to be in touch with you regularly throughout the process.

Finally, you’ll want to make sure that security testing will not interrupt your organization’s day-to-day operations. Make sure that the tester’s efforts will not cause any damage to your system components or inconvenience your customers.

ZenGRC’s monitoring abilities provide updated, in-the-moment insights that let an organization respond to changing threats and vulnerabilities in a constantly evolving threat environment. Moreover, organizations can store their penetration test and audit findings on the ZenGRC platform to drive better cross-enterprise outcomes.

For more information about how ZenGRC can help ease the pain of PCI DSS penetration testing, schedule a demo today.

Preparing for a PCI DSS Audit

· ·

An audit of your cybersecurity according to the Payment Card Industry Data Security Standard (PCI DSS) is a complicated but necessary procedure for modern commerce. While PCI data security can be confusing at first, it’s vital to protect your customers’ sensitive data from theft and your organization from potential penalties and lawsuits.

Whether you’re submitting to an external audit from a qualified security assessor (QSA) or performing a self-assessment questionnaire (SAQ), you can prepare for a successful audit in four steps: examine the PCI requirements; determine the scope of your network; build a system of record; and test your existing controls.

Determine the Applicability of Requirements

The PCI DSS requirements were designed by the major payment card service providers to create a system where any company that handles cardholder data can demonstrate compliance. As such, not every requirement will apply to every business. The size of your company, the volume of your annual credit card transactions, and the systems you use to process credit card data are all factors that determine which PCI DSS guidelines will apply to your specific business. Non-compliance with these guidelines can cause your credit card processing privileges to be revoked, so knowing which compliance requirements apply to your organization is critical.

The PCI framework is complex at first glance but becomes easier to navigate once you study it. There are four merchant levels as determined by the PCI Security Standards Council (PCI SSC), which are grouped by annual volume of credit card transactions; companies with more transactions are subject to more requirements. There are 12 primary requirements:

  1. Protect cardholder data (CHD) with well-maintained firewalls. 
  2. Don’t use default passwords or security measures.
  3. Make sure that any CHD you store is also protected.
  4. CHD should be encrypted across open networks.
  5. Install anti-virus programs and protections against malware. 
  6. Confirm that all systems and applications are secure. 
  7. Allow staff to access CHD only on a need-to-know basis.
  8. Create unique IDs and passwords for any employee who needs to access CHD.
  9. Minimize physical access to CHD whenever possible. 
  10. Assure that all access to CHD and the network is tracked and monitored.
  11. Test all systems and controls regularly. 
  12. Train all staff to be aware of the importance of information security and the controls that are in place. 

Within these 12 requirements are 251 sub-requirements—but not every sub-requirement applies to every business that handles CHD. It’s important to know before your audit what specific requirements your business will need to satisfy to prove compliance. By determining your merchant level and examining the requirements before your audit, you can narrow your focus and save time moving forward.

Determine Network Scope and Reduce Where Possible

The scope of your audit is defined by how much of your network processes, transmits, or stores cardholder data. Any server, point-of-sale system, mobile device, or computer that accesses cardholder information is considered in scope; so are any web applications that are connected to these devices. The more devices and applications within your scope, the more vulnerable you are to a potential data breach.  

One way to your scope is through network segmentation. Network segmentation uses firewalls to separate the PCI portions of your company’s network from other necessary devices and applications. This separation makes it much easier (and cheaper) to maintain PCI compliance. Another way to reduce scope is to avoid storing cardholder data whenever possible. Data storage increases the number of devices that have access to CHD and creates more of a compliance burden. So the less cardholder data you store, the fewer devices are within the scope of the PCI DSS audit. 

Wireless networks can be a particular point of contention for PCI compliance. Minimize the number of wireless networks that are integrated with your cardholder data environment (CDE), leaving only those that are necessary for processing transactions. You can also implement point-to-point encryption (P2PE), which renders cardholder data unreadable once it has been processed—which, in turn, leaves point-of-sale devices out of scope.

Building Your System of Record

A System of Record (SOR) refers to a storage system for information that is the definitive, most accurate source for a particular data element. In our PCI context, your System of Record documents your network configuration, the PCI controls you have in place, and the ways in which you audit those controls. By examining these controls beforehand and creating a system of record, you can locate opportunities to further minimize your audit scope and prepare for any documentation you might need moving forward. 

A good way to minimize your scope before an audit is to identify common controls between sites or facilities. Any controls that apply to multiple branches of your CDE can be tested once, saving time overall. Controls that apply only to a particular portion of your security system will need to be tested separately. 

Larger companies may need to submit a Report on Compliance (RoC), which isn’t required of organizations with fewer transactions. Your System of Record can be useful for your PCI system assessor, who will need to prove your organization’s compliance after your audit.

Test Your Existing PCI Controls

The criteria for testing have been defined by the PCI DSS, and it may be less challenging than you might expect. The testing procedures include a description of each requirement, how it should be tested, and what constitutes acceptable evidence of compliance. You can use this information to prepare for your audit by determining what areas of your system might need more attention, and which areas are already compliant. 

PCI DSS compliance also requires penetration testing, a process that actively searches for security vulnerabilities in your system that could be exploited. Because penetration testing can disrupt your day-to-day processes, it’s important to set aside appropriate time for these tests or to create an environment specifically for testing that accurately reflects the system components of your actual CDE.

Information security is complex, but a security audit doesn’t need to be an overwhelming experience. Security awareness and a secure network can go a long way towards making a PCI audit easier. By examining the requirements and your existing controls in advance, you can ensure that your security policies are effective and that your PCI audit will be as smooth as possible.

December 2020: Compliance Certification Roundup

· ·

Each month, ZenGRC highlights companies that have earned compliance certifications for information security frameworks.

Here’s our December 2020 roundup of recent compliance certification news from around the United States and the world.

PCI Certification 

PCI certification and compliance are two different, but related, designations.
PCI certification is a more rigorous process. It involves an intensive audit performed by a Qualified Security Assessor (QSA).
PCI compliance means a company follows best practices to help protect Cardholder Data (CHD) following the guidelines set by the PCI Council.

ISO Certification 

ISO standards concern many industries. The three primary ISO standards that help organize compliance for companies looking to create IT programs: IT, ISO 27001, ISO 31000, and ISO 9001.

SOC 2 Certification

SOC 2 concerns all organizations and enterprises providing services that process and store customer data. SOC 2 reports are based on five Trust Services Criteria: security, availability, confidentiality, processing integrity, and privacy.

FedRAMP Certification

The Federal Risk and Authorization Management Program (FedRAMP), is a government program that determines if the cloud products and services offered by cloud service providers are secure enough to be used by federal agencies. 

HIPAA Compliance

Compliance with the Federal Health Insurance Portability and Accountability Act (HIPAA) ensures that health care organizations protect the privacy, security, and integrity of protected health information.

Meaningful Changes to Expect in PCI 4.0

· ·

The PCI Security Standards Council (PCI SSC) is developing the fourth iteration of its data security standard, commonly known as PCI DSS. This version 4.0 won’t arrive until the middle of 2021, and many of the details are speculative right now. Still, compliance and security professionals should anticipate the changes likely to come, and allow ample time to bring your company into compliance with these new expectations. 

The PCI DSS was last updated in 2018. Since then, the PCI council has expanded its feedback system to solicit more feedback from stakeholders. That feedback takes time to digest, but it also gives participating organizations an opportunity to communicate their needs to the PCI council and play a more active part in the revision process. 

Any organization that’s interested can offer feedback during these requests for comment. PCI stakeholders include qualified security assessors (QSAs), service providers, industry experts, and PCI vendors, among others. Participants can offer feedback via requests for comment or in community meetings the PCI holds around the world. The process allows anyone involved in the payment card industry to have a voice in how version 4.0 will take shape. The process considers both existing PCI standards that need revision, as well as new standards that might be created in the future. 

The PCI SSC held its first request for comment (RFC) for the 4.0 update in 2019. More RFCs were held in September and October of 2020. Stakeholders have expressed numerous concerns that will likely be addressed in version 4.0 somehow

  • Increased guidance for authentication protocols, particularly with regards to NIST and multi-factor authentication passwords;
  • Increased ability to encrypt cardholder data;
  • Ongoing monitoring of past requirements, to ensure that they are evolving alongside new technology;
  • Increased testing and the potential to elevate some lesser requirements and apply them to a larger group of organizations. 

Meanwhile, the PCI council has stated that PCI DSS 4.0 will focus primarily on security and flexibility. The stated priorities are:

  • Maintain the current foundation for data security as it applies to current technological trends; and 
  • Create more flexibility for organizations that are using new methods to achieve compliance with the PCI DSS objectives.

These security objectives were largely chosen to ensure that the methodology behind the PCI DSS can evolve alongside advancements in both technology and cyber attacks. The planned updates in version 4.0 will create new requirements that will protect payment card data from risks and threats as they evolve; and reconsider existing requirements to ensure that those standards still support organizations meeting them through evolving methodology. 

For example, this new version could see a more consistent and thorough approach to data encryption might apply to more businesses at all levels. The existing Designated Entities Supplemental Validation (DESV) requirements might also be required of a broader range of organizations, which could mean that companies must revise their approaches to security controls and scope validation.

The 12 core PCI DSS requirements are not expected to change, although updates to supporting documents such as self-assessment questionnaires (SAQs) and reports on compliance (ROC) will be forthcoming. After the release there will be an 18-month transition period where PCI DSS version 3.2.1 will remain active, giving organizations time to update their forms and make the necessary shifts to move to 4.0. 

It’s also expected that many requirements will be future-dated; which will give companies time to adjust their compliance until the implementation deadline arrives. The completion of this process—and full adherence to the requirements of version 4.0—is expected by early 2024.

The best way to prepare for PCI DSS 4.0 is to maintain the compliance your company already has in place. The security council has urged companies to wait until the new version is complete rather than try to achieve PCI compliance based on drafts that are still in progress, and therefore subject to change.

PCI DSS Risk Assessment Guidelines

· ·

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for companies that handle credit and debit cards from the major card brands, whether via e-commerce or in in-person transactions, and those that store or process payment card data.

PCI DSS Requirement 12.2 requires that organizations annually perform formal risk assessments to identify threats, vulnerabilities, and risks to the business, particularly risks to debit and credit card data and their environments. This requirement can help you identify, prioritize, and manage your information security risks.

If you don’t want to get hit with a data breach, you’ll need to close security and PCI DSS compliance gaps. A risk assessment can help you figure out which vulnerabilities you should address first.

A risk assessment helps you anticipate threats and the vulnerabilities associated with those threats that can harm your business. A risk assessment also helps you determine how to implement the controls that can ward off those threats or lessen their effects on your company if they do arise.

Conducting a risk assessment at least annually keeps you up to date with changes in your business. It also enables you to consider those changes in light of new threats, new technologies, and emerging trends. These changes might include introducing a new software application to your cardholder data environment or launching new products or services.  A risk assessment should also be performed when there are significant changes to your organization’s environment such as relocation, merger, or acquisition.

There are a number of industry-accepted risk assessment methodologies that you can use to develop your risk assessment process, according to the PCI Data Security Standard. These include OCTAVE, ISO 27005, and NIST SP 800-30.

Assessing Your PCI DSS Risks

Your PCI DSS risk assessment should include:

  • The types of risk that may exist in your systems, applications, or processes
  • Company assets that need protection from these risks
  • Your entity’s level of vulnerability to each risk 
  • The likelihood that each risk will materialize (that a threat will occur)
  • The impact on your organization if a threat should occur
  • How your company can reduce the likelihood of threats and their impact. 

According to the PCI Security Standards Council, these are the steps you should follow when conducting your PCI DSS risk assessment:

  1. Develop a Risk Assessment Team and Methodology. Establish a risk assessment team with people from every department, including those that process, store, and transmit cardholder data. Appoint a team leader who understands the PCI DSS requirements and the risk assessment methodology.

    Adopt a methodology that fits with your company’s culture and the current business climate so you can be sure to meet your risk objectives.
  2. Identify Your Risks.  “Risk” refers to the likelihood that a threat will materialize, often due to a vulnerability. “Risk level” refers to the potential impact that threat will have on your company and your customers.

    For example, a system that employs weak passwords is vulnerable to the threat that a bad actor could compromise user credentials and break into the system. Your company is at risk if you store cardholder data that are not encrypted in your system.

    When threats are likely to take advantage of a vulnerability, therein lies your risk.

The PCI Security Standards Council (PCI SSC) lists four areas of focus in the risk-identification process:

  • Context establishment: Understanding the “the organization’s hierarchy, business processes, cardholder data (CHD) flows, and any associated system components”
  • Asset identification: The “the people, processes, and technologies that are involved in the processing, storage, transmission, and protection of CHD.” This step also involves identifying who is responsible for protecting each critical asset and may include assigning a value to each depending on its importance to the business.
  • Threat identification: Anyone or anything that could cause harm to the organization is a threat. The PCI SSC suggests talking with people throughout the company to compile a comprehensive list. Reviewing past threats can also help pinpoint those most likely to occur in the future.
  • Vulnerability identification: Part of vulnerability management, this step involves pinpointing weaknesses or potential weaknesses that threat actors could exploit, such as payment channels and devices. The PCI SSC recommends using vulnerability assessment reports, penetration-testing reports, and technical security audits such as firewall rule reviews, secure code reviews, and database configuration reviews.
  1. Determine Your Risk Levels. Which risks stand to affect your organization? Prioritizing these risks and their potential impacts is a key part of your risk assessment, ultimately guiding your risk management strategy.

The PCI SSC recommends ranking risks according to:

  • The ability of the “threat agent” to carry out the threat
  • The threat agent’s intent
  • The threat’s relevance to the enterprise
  • The likelihood of its occurring
  • The damage that it could cause to the organization.

Next, assign a risk level to every vulnerability and every threat that’s associated with the vulnerability, i.e., high, medium, or low risk. For additional information on the various risk evaluation methods, i.e., quantitative vs. qualitative, see the PCI Security Standards Council’s  PCI DSS Risk Assessment Guidelines.

4. Mitigate Your Risks. It’s nearly impossible to eliminate all your risks. That’s why it’s important to apply controls to reduce the risks to acceptable levels.

Mitigation often includes taking steps to reduce the likelihood that a risk will occur or lessen the severity of loss if it does happen or both. These steps can include implementing operational or technical controls or making changes to your physical environment. For example, you can mitigate the risk of malware by installing anti-malware software. The level of risk that remains is often referred to as “residual risk.”

Mitigation can take several forms: avoiding the risk, perhaps by discontinuing the activity that has created it; transferring the risk, for instance with insurance; reducing the risk, or accepting the risk, especially if the likelihood of its occurring or its potential impact on your business is low.

Reporting the Results

Each risk assessment should result in a risk assessment report that details the risk you’ve identified, including those affecting the cardholder data environment (CDE). The goal of the report is to clearly state the various risks that concern your company. The report may also explain the actions you took to remediate these risks.

Your PCI risk assessment report should include the following information:

Scope of your risk assessment: Describe your company as well as the internal and external guidelines you considered when you defined the scope of your risk assessment.

For the purpose of PCI DSS requirements, you can also include an overview of your cardholder data environment and the companies that support and process your cardholder data.

Asset inventory: Create a thorough list of assets that are in the scope of the risk assessment, for example, hardware, software, networking, and communications infrastructure, and employees.

Threats: List the threats that can harm your assets. You can also include a description of each threat that you’ve identified to spell out their characteristics.

Vulnerabilities: List the vulnerabilities related to technology and to your organization that can affect your assets.

Risk evaluation: Describe the technique you used to measure the risks you’ve identified so you can prioritize them.

Risk treatment (mitigation): Document the list of actions you’ve taken for each of the risks you’ve identified, along with how you handled those risks.

Version history: You might want to include the date, author, and the approver of the document.

Executive summary: This details your company’s overall risk posture before and after risk mitigation.

Get Help If You Need It

You should perform an annual risk assessment, at least, and another after you make any significant changes in your network. The risk assessment can offer direction on the vulnerabilities you should address first.

Conducting a risk assessment is often a long process, and only the first step toward PCI compliance. Meeting all the PCI requirements can take many months. Using quality governance, risk management, and compliance software can ease these tasks.

ZenGRC can help you track and manage your risks and to know where you are compliant with PCI DSS, where you fall short, and how to fill gaps. And its “single source of truth” repository keeps all your documentation in one place for easy retrieval at audit time.

Worry-free PCI DSS compliance is the Zen way. Contact us today for your free consultation.