Determining Scope for PCI DSS Compliance

DETERMINING SCOPE

For PCI DSS Compliance

Audio Commentary Available

You can follow along with Jacob Ansari as he

walks you through this presentation:

VIEW WEBINAR >

Agenda• Basics of Scope

• Looking at the Guidance

• Examples

• Open Q&A

Basics of scope• Store, process, transmit cardholder data

• Connected to the above

• Affects the security of the above

• Page 10 of PCI DSS

Where it gets complicated• What is connected to?

• What about connected to connected to?

Some practical examples• A system in the card data environment

communicating with another network

• Shared IT services network

• IT workstations connecting via jump server

• Call center PCs connecting to a Citrix application

What the new guidance says• Definitions for connected to and security

impacting systems

• Guidance for what to do with those

categories of systems

• Examples

Ok, let’s look at the guidance• All of my screen captures come from the document

Well, now everything is in scope• This may very well expand scope from prior years

• Intended to address all of the relevant threats

• Informed by actual security incidents

• Not all bad news

Connected to connected to

So that means…• An AD DC can potentially serve both in-scope and

out-of-scope segments

• An admin workstation is in scope, but not necessarily

all of the other workstations

What about the fine print?• Still very easy to make mistakes

• You have to validate that the out-of-scope systems

truly can’t get access

• Evaluate the effectiveness of segmentation

• Penetration testing in 11.3.4

So now the workstations need FIM?

So now the workstations need FIM?• Evaluate whether the requirements are applicable

• Default is yes

• Justify why it’s not

An example• CCTV system is in scope

• It supports a PCI DSS control

• Maybe it’s an appliance-like device

• Not running on a Windows machine

• Platform security controls may not apply here

Consider these principles• Sober risk assessment for applicability

• Not just “we don’t think an attack can do anything”

• Informed by real threat information

• Solid risk assessment methodology

Let’s look at an example

Let’s look at an example• IT services shared between scope and out

• This segment is in scope

• Non-card network may not be

• Contingent upon controls to restrict access

What are these controls?• Can’t pass through IT network into CDE

• Non-overlapping administrator accounts

• Only administer the IT network locally

• Only administer the CDE from the IT network

• MFA for access into CDE

Other examples worth mentioning• Admin workstations from corporate network

• Call centers connecting to web-based payment application

• Systems fulfilling DSS requirements:

• Patch management

• Physical security controls

So what do we do now?• Identify your scoping pitfalls

• Contact us with questions

• Start working on new segmentation efforts now

• Make sure your penetration testing addresses this

What about penetration testing?• Req 11.3.4 says test your segmentation

• Not just a network port scan

• Identify your specific scope boundaries and segmentation controls• Remote access methods

• Authentication and user controls

What about penetration testing?• Effective segmentation testing addresses

specific cases

• Test report should identify the specific scenarios

• Probably need coordination between QSA,

tester, organization

A few concluding ideas• Intended to close loopholes and protect organizations

• Aligns DSS with doing security correctly

• Clarify ambiguous and problematic situations

THANK YOUwww.schellmanco.com