Category: PCI

If you are struggling with understanding the “Scope” of your cardholder data environment (CDE), refer to the PCI SSC scoping guidance document (https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf). This is to help entities appropriately scope their cardholder data environment for PCI DSS.

Why publish?

Many entities still struggle with determining the scope for various factors, which may include:

• Many interpretations of adequate segmentation.
• Motivations for reducing scope.

Why scope is important?

Scoping is still a hot topic. Improper scoping may result in not identifying cardholder data (CHD) or intended/accidental cardholder data leakage. An unidentified cardholder data area is a desirable area for hackers and may lead to a breach.

The scope for PCI DSS includes systems within the cardholder data environment (CDE) that process, store or transmit CHD, connect to the CDE, or impact the security of the CDE.

Conversely, bad interpretations can lead to over scoping which is unnecessary and results in ineffective use of resources.

The first stage is to identify the critical people, processes and technology in-scope. Only then can you apply the relevant PCI DSS requirements. Believe me, this is never ever a trivial exercise and again we emphasise the need for good interpretation.

What is in-scope for PCI DSS?

We can be here for a long time, so I’m just going to summarise the document:

• CDE system: The system processes, stores or transmits cardholder data (CHD); OR a system is in the same network (e.g. VLAN) as systems that store, process or transmit CHD.
• Connected-System OR a security-impacting system: Something that connects inside to the CDE, or could impact the security of the CDE.

Sometimes the above may be too generic to apply security controls. Here is a possible category method of what in-scope for your PCI DSS assessment by categorising them:

• Type 1a (Systems that process, store or transmit CHD): This should be self-explanatory. These are systems whereby cardholder data is present and could be stolen.
• Type 1b (Systems inside the CDE): These systems are in the same network segments as Type 1 systems and can be used as an attack vector to steal cardholder data.
• Type 2a (Connected To): Systems directly accesses the CDE via controlled access boundary systems (e.g. firewalls, routers etc.). These systems establish a connection into the CDE or receive communication from the CDE.
• Type 2b (Connected To): Systems that indirectly accesses the CDE via controlled access boundary systems (e.g. an administrator workstation that indirectly uses a jump server).
• Type 2c (Impacts Security of CDE): Any system that could impact the CDE, such as systems that control access, segmentation, patch distribution, logging and monitoring tools.

Controlled access

Controlled access from say “zone A” into the CDE does not mean the network is fully segmented. However, this also does not mean every single system component in zone A is in scope! It means that these communications are more secure than uncontrolled systems. These restricted communications should be considered in-scope.

Any segmentation controls to fully restrict access must be penetration tested at least annually as per PCI DSS requirement 11.3.4 to ensure segmentation is still effective.

The following statement is interesting:

“It is important to understand the risks and impacts if connected-to system components are excluded or overlooked from PCI DSS scope.”

The way I read this is if a connected-to system is excluded from PCI DSS scope, the risk and impact should be determined first. Let’s consider this scenario:

• A large bank whereby there are 15,000+ user workstations all connecting into a virtualised environment.
• The virtualised environment supports the core banking system (that may process CHD) and non-CHD processing systems.
• A smaller proportion of 2,000 only access the core banking system via secured applications or secured browser (HTTPS), presented on their desktop via role-based access virtualised system.

The virtualised environment is in-scope as it supports the core banking system and card-processing applications.  Does the 15,000+ workstations connecting into the virtualised environment mean all 15,000+ workstations are in scope?  Maybe “yes” as each workstation is accessing the virtualised environment hosting the CDE, but maybe “no” as controls may be in place to restrict the presentation of access and applications on the desktop where the user role requires it.

Shared services

There are some systems components that may provide a service to the corporate network and CDE. I consider these “management systems”, which provide management or security functions such as:

• Directory and authentication (Active Directory, LDAP, AAA etc.)
• SMTP
• Anti-virus
• Logging and monitoring
• Bastion Host/Jumpbox

For this reason, you do not want the full corporate network being able to communicate with these management systems – these management systems / shared services should be in their own management zone:

• Only those components within the management zone can then connect into the CDE.
• Corporate LAN can connect to the management zone / shared services.

Administrator workstations are categorised as a “Connected To” device, perhaps see Type 2b above and are in-scope for PCI DSS review.

Who is responsible for determining scope?

We must reminds ourselves that the assessor is independent. The responsibility for determining the scope is the entity being assessed. The entity should confirm the people, process and technology in scope and retain documentation how this was determined. The assessed entity is responsible for annually determining the scope.

The assessor trusts, but verifies this to confirm the scope is defined and documented properly. However, should the scope not be correct, the assessor must work with the entity to determine the correct scope prior to the assessment to determine boundaries and applicable requirements.

Conclusions

Scoping will always be down to interpretation and the scoping guidelines published from the PCI SSC will help. Therefore, the opinions in this document are mine alone. You need to work with your assessor to determine their interpretation of the standard and scoping. Please see key findings below:

• Connected-to systems has more clarity of what is in-scope. Any systems to be excluded for scope and must be evaluated and risk assessed.
• Administrator workstations connecting directly or indirectly to the CDE are always in-scope.
• Important to note no solution eliminates all PCI DSS requirements. The applicability of requirements depends on the system function.
• Review the types/categories of systems in scope and review third party access against this.
• All segmentation controls must be penetration tested at least annually.

Finally, even if your environment may in principle seem a typical environment, your scope is likely to be different because of different people, processes and technology. What is your scope? I will put on my QSA hat on and say “It depends”!

Did you find this post useful? Feel free to share and link to this article.

A gap assessment is reviewing how a system or process is against your checklist/benchmark, in order to identify any gaps.

Whenever doing a gap assessment, in my experience there is always going to be one general area a company is almost certainly lacking.  It’s that dreaded word (and not just dreaded by programmers only)… Yes, it’s documentation!

NOTE: My apologies to programmers. I used to be (and I still am though scrappy now) a programmer. I know how you feel. I felt the same way. I hated documentation. But I’ve seen the light being on the other side of the fence and it’s for the greater good. Trust me.

Companies are generally missing documentation and whenever doing PCI-related assessments documentation is key. We have a problem.

Never fear, this is easier to fix that expected as in many cases the companies are doing things in a PCI DSS (or other PCI-type assessment) compliant manner, but it’s just not documented. Often, I find they do not understand the difference between a policy, process and procedure and don’t know where to begin.

PCI policies, processes and procedures?

PCI DSS v3.0 is great as it clearly spells out in the reporting requirements whether a documented policy, or documented process/procedure is required. My suggestion is you do them all in a certain order as follows:

•  Write your policy: Business rules and guidelines – the high level objectives you want to meet. Don’t include the how (process/procedure).
• Write your process: These are the activities to produce a specific output.
• Write your procedure: These are the underlying tasks that result in your process being fulfilled.

I still do not understand, can you give me an example?

As an example:

Policy: All system components must be hardened according to their respective hardening guides.

So let us assume you have firewalls. You need your own firewall hardening guide.

• Process: Prevent internal addresses coming from the outside.
  • Type command XXXXXXXXXX (task/procedure)
  •  Type command XXXXXXXXXX (task/procedure)
• Process: Remove the default password.
  • Type command XXXXXXXXXX (task/procedure)
  • Type command XXXXXXXXXX (task/procedure)

There are many ways to write your documentation, and I’d encourage you to split them into appropriate documents.

NOTE: In the past I’ve seen some companies just have few large documents just to satisfy PCI DSS – please split the documents up that is workable for your business.

Scope?

Your document is not intended to be read by everyone. The document has an intended audience, so make it clear by writing an introduction. For example:

“The scope of this document applies to firewall administrators.”

Roles and Responsibilities?

Of course, PCI DSS wants to know the roles and responsibilities. For example:

“Firewall administrators are responsible for applying this hardening document to all firewalls prior to installation into the production environment. All firewall administrators will need written approval before installing any firewall into the production system. Firewall administrators are required to test all firewalls after making changes to firewalls.

The owner of this document is the <insert title> who will ensure this document is kept up to date.”

Versioning?

You need to demonstrate that you update documents at specific times as addressed by the PCI DSS. There are some ways to meet this. I strongly encourage you to use a versioning table. Consider including:

• Version
• Last modified date
• Changes made
• Reviewed/approved

You will then be able to demonstrate how frequently it was reviewed:

Hint: Stick in a policy somewhere to confirm the frequency:

“This document will be reviewed every x months”

(where x is the frequency required)

So, what is the benefit of this framework?

• Confirms roles/responsibilities: Personnel know who is responsible for what device/process/system.
• Mitigates ambiguity in configuration: Follow the step by step procedures as detailed in the documents and in principle your system components should be hardened to the same level.
• Faster implementation: Often, you can copy/paste the commands into your system components and execute the command. This reduces human error/typos.
• Reviews: You can demonstrate required review periods and updates made according to your business or changes to the standards.

Summary

In summary, documentation is a key element to passing an assessment. Documentation determines correct business objectives, correct and consistent configuration, clear roles and responsibilities and also Business As Usual (maintain compliance by following compliant practices in a timely manner).

This is not an easy task to do, but once you got it, you won’t need to rewrite it again! But remember, documents will need to be demonstrated to be reviewed at various times throughout the year in order to maintain compliance.

Action:

• Document your policy
• Document your procedure
• Document your tasks to meet your procedure(s)
• Include a scope section
• Include a roles/responsibilities section
• Include a version table
• Document the frequency to review and update the document.

Once you have written your documents (and had them checked), go and relax. You deserve it!

If you still need policies, simply subscribe to my newsletter. Then get in contact.

#cyberattack, #cybersecurity, #dataprotection, #datasecurity, #datasecuritybreach, 

#gdpr, #gdprcompliance, #informationsecurity, #infosec, #pcidss, #personaldata, 

#security