This document discusses determining scope for PCI DSS compliance. It begins by outlining the basics of scope, including systems that store, process, or transmit cardholder data and systems connected to or affecting the security of those systems. It then discusses examples of systems that could fall into these categories, including shared network infrastructure. The document reviews new guidance from PCI that provides definitions and examples to help determine what systems are in scope. It emphasizes the need to properly assess risk and validate any systems considered out of scope. The document concludes by discussing penetration testing requirements and reiterating the goal of the new guidance to close security loopholes.

1. DETERMINING
SCOPE
For PCI DSS Compliance

2. Audio Commentary Available
You can follow along with Jacob Ansari as he
walks you through this presentation:
VIEW WEBINAR >

3. Agenda
• Basics of Scope
• Looking at the Guidance
• Examples
• Open Q&A

4. Basics of scope
• Store, process, transmit cardholder data
• Connected to the above
• Affects the security of the above
• Page 10 of PCI DSS

5. Where it gets complicated
• What is connected to?
• What about connected to connected to?

6. 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

7. What the new guidance says
• Definitions for connected to and security
impacting systems
• Guidance for what to do with those
categories of systems
• Examples

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

10. 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

11. Connected to connected to

12. 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

13. 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

14. So now the workstations need FIM?

15. So now the workstations need FIM?
• Evaluate whether the requirements are applicable
• Default is yes
• Justify why it’s not

16. 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

17. 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

18. Let’s look at
an example

19. 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

20. 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

21. 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

22. 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

23. 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

24. What about penetration testing?
• Effective segmentation testing addresses
specific cases
• Test report should identify the specific scenarios
• Probably need coordination between QSA,
tester, organization

25. A few concluding ideas
• Intended to close loopholes and protect organizations
• Aligns DSS with doing security correctly
• Clarify ambiguous and problematic situations

26. THANK YOU
www.schellmanco.com