Upload
schellman-company
View
43
Download
0
Embed Size (px)
Citation preview
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