Trey Ford raises some good questions that are very much the same as asking about systems that may (or do not have) cardholder data but are important enough to beg scope creep analysis.
Of course it’s easy for us to say “test all of them” when we sell security testing services. However, in my experience explaining ways to reduce scope without increasing risk are far more popular. :)
Security managers are not always blessed with a budget that can afford a “test all” approach. They usually only get support to build a keep smaller than the entire castle, if you will. Although you hinted at it, I would add that PCI DSS compliance should come from a risk-based approach. This is how to safely reduce scope as well as costs for validation.
Note that DSS 1.2 changed Requirement 6 to say “a risk-based approach may be used to prioritize patch installation”. Can the same be said for selecting sites and systems to be in scope? If cardholder data is transmitted, processed or stored, then it’s for sure in scope, if it doesn’t exist, then the asset value, frequency and likelihood of compromise related to the non-CHD could bring them into scope. Know your sites, but more importantly know your processes.
Back to my cheesy castle example, this is like saying if you are someone within the walls who has access or potential access to the king, then you also should be within scope of a keep security assessment. Your identity and your possessions are important to know, but your routine (processes) are also a key to understand (pun intended). The king’s security should assess the risk from this perspective and consider changing to a more isolated routine, which would thus reduce the scope/cost of protection.
All that being said, I noted a curious mistake in Trey’s writing:
Four good questions ome
Don’t you just hate when that happens? Automated checks, visual cues (e.g. code highlight)…and yet bugs still creep into web sites, even those of web security experts.
