The Top 8 Requirements Your Assessor Misses
The QSA community at large received the May edition of the assessor update from the council on Friday. In it, Troy Leach is giving us hints on which requirements assessors are messing up the most. Keep in mind, he is speaking about this from the Quality Assurance process, and not from watching assessors conduct assessments. The reason I make this distinction is that your assessor COULD be evaluating the criteria mentioned and not documenting it properly in the ROC.
Here ya go, here's the top 8 (from the May 2009 Assessor Update) copied right from the update.
- Requirement 2.2.4 - "For a sample of components...", often there is no sampling defined or components listed
- Requirement 3.2 - Few if any of the bulleted items in subrequirements of system components are addressed
- Requirement 4.1.a - The 4-7 bullets of evidence are often neglected
- Requirement 5.2 - Automatic updates and periodic scans of the anti-virus solutions are not addressed
- Requirement 6.3.6 - The requirement to demonstrate custom accounts are removed before system is released is often not documented
- Requirement 11.2.a - QSA only documents the external ASV scan and internal scans are not addressed
- Requirement 11.3 - There is seldom documentation that the process of penetration test is in place.
- Requirement 11.4.b - There is seldom documentation that the QSA reviewed the IDS/IPS to verify the solution alerts personnel of suspected compromises
While some of these seem to expand beyond the scope of what the requirement is asking for (such as 11.3, unless I misunderstand what he is saying), but some of these are blaring examples of the gloss-over effect that an assessor might fall victim to if they do not do a thorough assessment. Of course all companies have A/V, right?
Comments
11.3 = proof that the company does penetration testing from outside the firewall as well as from inside the business network to find network and application vulns, right? Way more in-depth than the more simplistic 11.2 quarterly ASV scans, since a true pen-test should mimic more advanced methods that a human attacker would employ. I would think this is one of the most important parts of the PCI DSS in terms of real-world impact on preventing total ownage. It seems understandable that they would complain if they're not seeing enough proof in a submitted ROC. Many businesses get compromised due to a public-facing vulnerability like SQL Injection or remote access with weak passwords. The attacker then spreads through the business network like cancer, using the compromised server as a pivot point to attack from inside the perimeter firewall (candy bar/crustacean/armadillo security).
Posted by: Lucas | June 2, 2009 12:20 PM
Here's the best part... PCI does not require the scans performed under 11.2 to be authenticated! That means that there are huge sections of your web app that go un-scanned. Hello SQL Injection!
Posted by: Branden Williams
|
June 3, 2009 5:57 AM