When you think of PCI DSS, you probably don’t automatically think of drawing diagrams. But diagrams are vital to understanding your scope, understanding your environment, and are two of the PCI requirements that may apply to you.

PCI DSS requires three types of diagrams:

• High-level network diagrams.
• Detailed network diagrams.
• Cardholder data flow diagrams.

In this article we’ll talk about what what each of those diagrams are and the kinds of details that they need. While this page focuses on the details from the Report on Compliance (RoC) template, the same approach should be taken even if you are using a Self-Assessment Questionnaire (SAQ).

High-Level network Diagrams

The Report on Compliance (RoC) template details the exact types of information that are expected in a high-level network diagram on page 11. A high-level network diagram is expected to show:

• The overall architecture of the environment being assessed
• A summary of all:
  • Locations,
  • Key systems, and
  • Boundaries between the above
• All connections into and out of the network, including the CDE to other networks, VLANs, or zones
• Includes all critical components within the CDE, such as:
  • POS / POI devices
  • Systems
  • Databases
  • Webservers
  • Other components (as applicable)
• Includes all other necessary payment components.

The high-level network diagram should be the 10,000 foot view of your environment showing all the possible connections into and out of the environment to help you and your assessor to understand how things fit together. This means your high-level network diagram should include things like where your test and development environments are to understand any connectivity to the CDE / production environments.

Detailed Network Diagram

The detailed network diagram takes the high-level view and zooms in to the CDE and the supporting environments with a focus on the environments that are in-scope for PCI. The detailed network diagram needs to show:

• All boundaries of the CDE
• Network segmentation points the tare used to reduce the scope of the assessment
• Boundaries between trusted and untrusted networks
• Wireless and wired networks
• Any other connection points that are applicable to the environment.

While this may seem similar to the high-level network diagram, the diagram is expected to have much more detail to it so that you and your QSA can understand how each communication point functions and how it is secured. This may include detail such as:

• The type of device(s)
• The device interfaces
• Network technologies
• Protocols
• Security controls

With the amount of detail that is required here, you may find that some of this information needs to be in supporting documents. However, if you do use a supporting document, make sure that it is kept up to date and referenced in your network diagram.

It may be possible that your detailed and high level network diagrams are the same if your environment is small. The important thing is to make sure that you have all the required detail in your network diagrams.

Below is an example of a network diagram that may get you started when trying to diagram your own network.

As you can see, it includes information about the servers, the ports and how they connect, the network devices providing segmentation and the wireless networks.

Cardholder Data Flow Diagrams

Cardholder data flow diagrams need to exist for every process where you store, process, or transmit cardholder data so that it is possible to understand the lifecycle of a payment. This means that your cardholder data flow should include everything from the time a customer is able to provide you with a payment, through any processes where you use that card number (for example tokenisation), and when it leaves your environment for further processing, settlement, or fraud activities.

By understanding your cardholder data flows, you can better understand and explain your scope. To understand and explain your cardholder data flows, you need to be able to show not only where cardholder data flows (e.g. where is it stored, processed, or transmitted internally or externally)but also what parts of the cardholder data are involved in the flow (e.g. PAN, SAD, Name, Expiry, etc.) and how it is protected (e.g. TLS, VPN, truncation, application layer encryption, etc.).

This diagram shows an example of one way you can illustrate your cardholder data flows.

It contains information about how data is protected at rest, where it is stored, and what is stored. It also shows how cardholder data is sent from the time a customer provides a credit card number through the transaction process including transmitting the cardholder data out to the payment gateway.

Remember to Include Supporting Systems

PCI DSS is not just the systems that store, process, or transmit cards. It is also the systems that support the PCI DSS requirements. This means you should ensure that your network diagrams also include systems used for patching, antivirus, log servers, file integrity monitoring, admin workstations, and other systems that support PCI. Even though these are not part of the cardholder data environment (or CDE), they are still part of your in-scope environment and your assessor will want to see these on your diagram so they know what systems they will need to review.

Need Help?

Confide can help you with not only understanding your scope, but making sure that your documentation clearly reflects your scope. Contact us to find out how Confide can help.

Two of the terms that frequently get misused (and often are interchanged) are vulnerability scanning and penetration testing. These two items are different and meet different parts of the PCI requirement. In fact, these terms get confused so often that the PCI SSC even published information on the differences between them.

In this article we break down the differences between vulnerability scanning and penetration testing.

The PCI SSC published an information supplement on penetration testing in 2017. In it, they summarised the key differences between vulnerability scans and penetration tests which is summarised below.

Vulnerability Scans

Vulnerability scans are required to be performed at least quarterly. External vulnerabilities scans must be performed using an ASV. Internal vulnerability scans do not have to be performed by an ASV, but many ASVs offer these services.

Vulnerability scans need to be carried out at least quarterly to meet PCI requirements, but we recommend monthly so that you have time to fix any findings and still get a passing scan during the quarter.

Vulnerability scans are a primarily automated process. Although someone is required to schedule, configure, and run the scans the work behind the scenes is done by your vulnerability scanning vendor.

Penetration Testing

Penetration testing is a primarily manual process. Vulnerability scanning may be used as an initial step in the penetration testing process, but penetration generally depends on a person taking information about vulnerabilities and trying to exploit them to see how they can bypass security controls. The testing may chain together different types of attacks and different vulnerabilities to reach their goal over time.

While vulnerability scanning primarily focuses on whether a vulnerability might exist, penetration testing goes one step further and tests to see if and how that vulnerability can be exploited.

Need Help with Vulnerability Scanning?

If you need help with your vulnerability scanning, Confide has experts who are qualified and certified in using vulnerability scanning tools. Read more about our Managed Vulnerability Scanning Service or contact us to find out more.

PCI DSS requires you to regularly understand and review the risks that are applicable to your environment. There area number of different ways that you can understand and document your risks, including OCTAVE, ISO 27005, and NIST SP 800-30. This article explains one way that you can approach understanding and documenting your risks, but you should make sure that the method you use fits your organisation and is useful.

Risk assessments may need to be carried out at different levels because a business risk assessment is likely to be very different from a technical risk assessment. PCI risks cover both organisational and technical risks.

When Do You Have to Do A Risk Assessment?

Requirement 12.2 requires that you complete a risk assessment :

• At least annually, and
• Upon significant changes to the environment (for example, acquisition, merger, relocation, etc.)

Other examples of significant changes that might require a risk assessment could include significant changes to your architecture (for example, migrating to the cloud) or adding new payment channels.

Risk assessments are just one part of significant changes.

How Do You Perform a Risk Assessment?

Step 1: Define Your Process

Our example here uses a modified approach based on NIST SP 800-30. You might have a different process. This is just one example of how you might conduct a risk assessment and the steps you might follow. Remember, whatever process you follow, you need to have the process and the outcome documented for your organisation.

1. Identify and document your critical assets, including people, technology and data.
2. Identify and document threat sources, including both internal and external threats.
3. Identify and document the vulnerabilities in your environment related to the people, processes, technology, and data.
4. Determine and document the likelihood of the event occurring. This could be based on the frequency of the event occurring or based on the likelihood of it occurring during a set timeframe.
5. Determine and document the impact if the risk occurs. This could be the financial impact, the impact to compliance, or another impact that applies to your organisational goals.
6. Determine and document the controls that apply to each of the risks and how they can mitigate the risk.
7. Determine and document the resulting residual risk after the controls have been applied.
8. Assign the risk owners.

Step 2: Conduct the Risk Assessment

If you feel like you’re at a loss for how to start your risk assessment, NIST SP 800-30 provides a great starting point in Appendices  D through I for risks that should be considered. Do you have to consider all of the? Absolutely not! You should be focusing on the threats and vulnerabilities that apply to your environment and the risks that your organisation actually faces. Follow your process and start documenting the risks that apply to your business.

There are a few specific risks that we would recommend considering as part of your risk assessment.

Risk of Non-Compliance

It seems obvious that there is a business risk if you are unable to demonstrate compliance with PCI DSS. In most cases, you have a contractual obligation to your bank to be PCI compliant. The result of non-compliance could include revoking your ability to process card transactions, extended remediation times and costs, and even fines imposed by the card brands. But understanding the results of non-compliance does not help address the root cause. Non-compliance could be caused by a lot of different things, including staff turnover, hardware or software going end of life or becoming non-supported, or missing standard BAU processes required by PCI, the non-compliance of service providers. While it’s useful to understand the result of non-compliance, addressing the potential causes is vital.

Logging and Monitoring

As part of the logging and monitoring requirements, you need to be considering how often you review logs that are not part of your daily log review. While some logs have to be reviewed daily, other logs can be reviewed less frequently. But these logs and the frequency of the reviews need to be considered as part of your risk assessment.

Other Areas to Consider

Other areas to consider for your PCI risk assessment might also include:

• Review of cryptographic algorithms and ciphers used to protect cardholder data to ensure they are considered strong.
• Review of insecure services and protocols used in the cardholder data environment.
• How frequently to conduct device inspections for card-present / retail staff.

Step 3: Assign Risk Owners

If nobody is responsible for managing your risks, you add a new risk that nothing will happen to address them. To manage risk effectively, someone needs to take responsibility for each. Not every risk can be mitigated, but every risk needs to have an owner.

Step 4: Track Your Risk Over Time

If you want to effectively understand how your risks are changing and how effective you are at managing your risks, you need to track your risks over time. This gives you a better understanding of what risks are increasing and which are decreasing and helps allocate your resources better. For example, you might have a very low risk of systems being unsupported right after you purchase them, but the risk of them being unsupported increases over time.

Need Help with Your Risk Assessment?

If you need help conducting your risk assessment or need an independent view on what your risks might be, contact us and find out how Confide can help.

One of the worst things you can hear during your PCI assessment (aside from maybe finding out about unprotected cardholder data) is your service provider saying “That’s not my responsibility”. Suddenly, you find yourself pushing your service provider to do things differently, facing unforeseen costs, and facing a potentially long remediation period.

Having a responsibility matrix isn’t a silver bullet to avoiding this sort of thing happening, but it’s a good starting point and service providers are often a vital part of your PCI. So it’s important that both you and your service providers understand what their responsibilities are.

One of the key things to understand from PCI DSS is that every requirement must be met by at least one party. SAQs only show some of the requirements because as part of the SAQ you are attesting that you meet all the requirements for having third parties that look after the requirements that have been excluded.

In this article, we use the term responsibility matrix, but you may also hear it referred to as a RACI matrix or by another term. What’s important is that you understand how your PCI DSS requirements and service providers fit together.

Why Does PCI Care?

Regardless of what type of assessment you are doing, every self-assessment questionnaire (SAQ) and report on compliance (RoC) requires you to have a programme for managing your service providers. Specifically:

Requirement 12.8.1: Maintain a list of service providers including a description of the service provided.

Requirement 12.8.5: Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

PCI cares about service provider management because so many organisations use service providers, and so many of these service providers could affect the security of the cardholder data environment. Almost everyone has heard of the Target breach where credentials were stolen from a third-party service provider and used to attack the system, but in New Zealand, the government is cracking down on web hosting providers for government sites because of the risk, and third parties have been responsible for other recent data breaches in New Zealand. Service providers not only have access to your sensitive data, but many customers sensitive data making them a prime target. Even if it’s your service provider that is ultimately responsible for the breach, the reputation damage is usually not just limited to them. So it’s important to pick service providers who can demonstrate a commitment to security.

Shared Versus Sole Responsibility

PCI has over 250 individual requirements, so understanding who is responsible for each of them is vital. There are a few different ways that responsibilities can be separated:

• Sole responsibility of your organisation (whether you are a merchant or service provider).
• Sole responsibility of your service provider.
• Shared responsibility between you and your service provider where you are individually responsible for different parts of the requirement.
• Responsibility of both you and your service provider where you are both responsible for meeting the requirement.

Sole Responsibility: An Example

One example of a sole responsibility for you as a service provider might be your responsibility for creating a cryptographic architecture (Requirement 3.5.1) for the protection of your keys. Even if you are using a cloud service, the underlying architecture, design, and management of the keys as well as the documentation is your sole responsibility as the cloud service provider would not have any insight into how you have configured your cryptographic processes.

An example of a sole responsibility for a cloud service provider may be ensuring that anti-spoofing is configured for network connections (Req. 1.3.3) and that there is no way for the customer to change or disable this.

Shared Responsibility: An Example

Consider the example of a hosting provider where there is a shared responsibility for change management. The customer is responsible for submitting the change and ensuring that it has appropriate approval within the organisation and documenting the impact, while the service provider is responsible for verifying that the change came from the expected organisation, that the change has been tested, and the change has been implemented. In this situation, both parties have responsibilities under the same requirement, but not for the same parts of the requirement.

Responsibilities of Both Parties: An Example

Regardless of the service you provide, there is almost always going to be a requirement to ensure that general security awareness training (Req. 12.6) is carried out. And in many cases, there will also be a responsibility by both parties to ensure that personnel are screened and background checks are carried out (Req. 12.7). Both the customer and the organisation would need to ensure that their personnel meet these requirements, and it is unlikely (though not impossible) that both organisations would need to carry these tasks out individually.

How Do You Figure Out Who is Responsible?

This part of the process can be very easy or potentially difficult.

Check the Attestation of Compliance (AoC)

If your service provider has an Attestation of Compliance (or AoC), check the AoC to verify what requirements have been excluded from their testing. They will usually tell you if something has been excluded from their service and if it is the sole responsibility of their customers.

Sometimes things you might expect to be covered are not. We often see that data centres do not conduct rogue wireless scanning (Req. 11.1) on behalf of their customers. This means that in order to meet this requirement, the customer must have processes in place to check for rogue access points at least quarterly.

If the service is not covered in the AoC, you will need to do more work.

What if there Isn’t an Attestation of Compliance?

If there isn’t an attestation of compliance, and your service provider is non-compliant, then you need to work with your service provider to understand:

• Exactly what services they provide for you.
• Which PCI requirements are the responsibilities of each party.

In a perfect world, you would go through each of the requirements to understand which requirements (and sub-requirements) are the responsibilities of each party. But start at the high level of the 12 primary requirements. Understand which requirements might be applicable to each provider, and then within those start looking at the detail. It can be a long process, but once you have this documented your assessment will be smoother and you and your service providers will have a better understanding of who is responsible for what.

What Next?

Eventually you will need to get to a point in the process where you have documented who is responsible for each of the requirements (your responsibility matrix).

The next step is to have a process for getting a written agreement with your service providers including their acknowledgement of their responsibilities. This might be as part of your contract, or it might be a separate acknowledgement on behalf of the customer. The form and wording of the agreement isn’t mandated as part of PCI, so it will depend on what is right for you and your service providers. The important thing is that they understand what they are agreeing to.

It’s not necessarily a short or easy process, but it will pay off in the long run when you avoid running into situations where someone says “That’s not my responsibility!”

Need More Help?

Confide can help you map your service providers and understand how they affect the scope of your PCI DSS. Contact us for more information.

One of the most frequent questions we get is what the term “Significant Change” means for PCI. In this article we try to demystify this term a little and help you understand the various ways that the term is used in PCI DSS.

What is Significant Change?

The PCI SSC says that a significant change varies depending on your environment and your organisation (What is a “significant change” for PCI DSS Requirements 11.2 and 11.3?).

They help by providing some examples of things that are considered as the minimums for significant change, which are:

• Changes affecting access to cardholder data
• Changes affecting the security of the cardholder data environment

And examples of the above may include, but are not limited to:

• Network upgrades
• Additions or updates to firewalls or routing devices
• Upgrades to servers

Even with these examples of significant changes, the key thing to keep in mind is that you and your organisation need to have a clear definition of what constitutes a significant change so that changes can be identified and analysed to determine if they meet the criteria for a significant change. If you don’t have a documented common understanding of what represents a significant change in your environment, there may be a significant risk that someone else in your organisation doesn’t identify a change as significant and some of the PCI requirements that apply could be missed.

What Does This Actually Mean?

What this actually means for your environment is not as straight forward. There are five key requirements in the PCI Report on Compliance (RoC) and Self-Assessment Questionnaires (SAQs) that relate to significant changes, one part of the AoC that relates to significant changes, and two additional requirements in the Supplemental Report on Compliance / Designated Entities Supplemental Validation (S-RoC / DESV) that relate to significant changes.

• Requirement 6.4.6: Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.
• Requirement 11.2.3: Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.
• Requirement 11.3.1: Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
• Requirement 11.3.2: Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment)
• Requirement 12.2: Implement a risk-assessment process that:
  • Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.)
  • Identifies critical assets, threats, and vulnerabilities, and
  • Results in a formal, documented analysis of risk.
• Requirement A3.2.1 (DESV): Document and confirm the accuracy of PCI DSS scope at least quarterly and upon significant changes to the in-scope environment.
• Requirement A3.2.5 (DESV): Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN at least quarterly and upon significant changes to the cardholder data environment or processes.
• Part 3a (AoC): If my environment changes, I recognise that I must reassess my environment and implement any additional PCI DSS requirements that apply.

What you will need to do to meet each of these requirements varies from performing an out of cycle vulnerability scan through to performing a full re-assessment of your environment.

Documenting Significant Changes

The starting point for understanding what it means for your environment though is Requirement 6.4.6 which focuses on ensuring that you have a process to identify significant changes and that your change management process includes documenting the supporting evidence for the steps you have taken in relation to a significant change.

The guidance in Requirement 6.4.6 states:

A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process. Examples of PCI DSS requirements that could be impacted include, but are not limited to:

• Network diagram is updated to reflect changes.
• Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled.
• Systems are protected with required controls – e.g. file integrity monitoring (FIM), antivirus, patching, audit logging.
• Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data-retention policies and procedures.
• New systems are included in the quarterly vulnerability scanning processes.

These examples are not meant to be exhaustive, but should provide a starting point for how you can review your changes to first understand if they are significant and next to understand what additional steps you need to take for them.

We recommend storing all the associated evidence with the significant change to make it easier for your team to locate the evidence when requested by the QSA.

We also recommend considering how you can template certain types of significant changes so that everyone involved in the change understands what further steps need to be taken. But to do this, you need to understand what kinds of events will be considered significant changes for your organisation.

Common Challenges

The most common thing that we come across is that people do not want to consider a change as significant or do not have a clear definition of a significant change. The result is that staff don’t understand what PCI considers as a baseline significant change, and tasks may not be completed. For example:

• Vulnerability scans may be missed or not occur as part of the change
• Penetration testing may not be completed or may be booked significantly after the change has occurred.
• PCI controls may not be applied and not discovered until the PCI assessment
• Firewall rules for decommissioned servers may not be removed.
• Documents may not be updated and network diagrams may be missing new systems or showing systems that were removed.
• Change documentation may not show all the detail required for Requirement 6.4.6.

We’ve repeated it a lot in this article, but the best way to avoid these challenges is to remove the stigma of a significant change by:

• breaking down what is required for types of significant changes, and
• making sure that the definition of a significant change is clear to the staff who are working with these changes on a daily basis.

Make sure that key staff are involved in the discussion of what a significant change is so that you have something that works within your organisation and develop processes that minimise the challenge of identifying what steps to take if you have a significant change.

A change might be significant, but if you’ve set up your processes well, a significant change can become just another part of your business as usual (BAU) activities.

Thinking of Making a Change?

If you’re thinking of making a significant change to your environment, Confide can help review it and make sure that it won’t negatively affect your PCI DSS compliance. Contact us to find out more.