Most penetration testers are focused on one thing and one thing only: compromising the client. Heck, that's what they are being paid for, right?
That doesn't even make my top four goals. I see a penetration test as a building block for a larger security program.
My goals are simple:
- Deliver a Penetration Test Report that the client can understand.
- Deliver a Penetration Test Report that provides clear, prioritized recommendations.
- Deliver a Penetration Test Report that helps a client fulfill their compliance requirements.
- Don't bring down the network or interrupt business.
If I manage to compromise a system along the way, that's an added bonus.
Recently, I was performing a penetration test for a client who processes a significant amount of credit card transactions. The organization is required to undergo a formal PCI audit annually using a PCI Qualified Security Assessor (QSA). Now, I am not this organization's QSA. I do, however, perform their annual PCI Penetration Test to meet requirement 11.3 of the PCI DSS.
The report I deliver to the client goes directly to their QSA for inclusion in the audit, and for this reason it is imperative their PCI Penetration Test is audit-ready. It was during this penetration test that I uncovered the client had made a major scoping mistake that would prevent the resulting report from being audit-ready.
Here's how it went down. During the kickoff, I was given two scopes to work with. The PCI Scope was all assets in-scope for the PCI Penetration Test (or so they thought). The Non-PCI Scope was all assets not in scope for PCI. Two reports were requested. The PCI Scope report would be given to the PCI QSA in support of their audit, while the Non-PCI Scope report would be disseminated internally. The idea here is to only give the QSA information relevant to PCI compliance. I fully support this approach, even though it means I have to write two reports instead of one.
As I was working on the Non-PCI Scope penetration test, I was able to compromise a ManageEngine Desktop Central server. I was logged in as admin. With this level of access I can remotely install software, make configuration changes, and remotely login to managed systems. Then, I looked at the list of managed systems. I found many systems from the PCI Scope in the list. The ManageEngine Desktop Central could essentially remotely control systems in the CDE.
The client had made a scoping error. Key systems had been omitted from their PCI Scope including systems management servers, Active Directory domain controllers, and antivirus management servers. Even though these systems were outside the CDE, they could still affect the security of the CDE.
According to official PCI Guidance, "The scope of a penetration test, as defined in PCI DSS Requirement 11.3, must include the entire CDE perimeter and any critical systems that may impact the security of the CDE as well as the environment in scope for PCI DSS."
As originally scoped, the PCI Scope left out critical systems that could impact the security of the CDE. This omission could have caused the client to fail Requirement 11.3. I quickly brought this scoping issue to the attention of the client, we made some adjustments, and they are now in a much better position to pass their audit.
Are you confident in your PCI Penetration Test scope?