In the last post I discussed what the SOC reports are and what, in general, to look for in a SOC 2/3 report. Now I want to take you through the more detailed analysis of the SOC reporting so that you can understand why it might not give you the result you desire and how to address that fact.
How Do I Analyze The SOC Report?
Based on the testing in the ‘Information Provided by Independent Service Auditor’ section, you are going to need to map that testing into the PCI ROC tests, if they even fit. I typically use the Prioritized Approach spreadsheet to do this as it provides a way of documenting the requirements covered and a quick dashboard regarding what is covered.
As you reviewed the domains listed under the SOC 3 report, I am sure you thought; “What is not to like? It looks like most of what I need for PCI is covered.” But you would be wrong. You will find after you map the controls from any SOC 2 report that covers all the TSP domains into the Prioritized Approach that the report will likely only cover around 20% to 25% of the PCI DSS requirements. That is because the level of detail in the SOC tests are just not as detailed as they are in the PCI DSS. As a result, SOC 2 reporting does not provide the kind of reliance you need to respond to all of the relevant PCI DSS requirements.
For example, while SOC will likely test that password controls are in place, you will be unable to ascertain if the organization enforces seven character or greater password lengths, password complexity, nor if they require passwords to be changed every 90 days or less. Let alone if the special requirements for vendor password management are enforced. It is these missing details that create the coverage problems with using the SOC reporting results.
The same can be said for change management. When tested, the SOC report will likely call out a lot about change management, but not at the level of detail required in the PCI DSS for requirements under 6.4. You will also find that coverage in requirements 1 and 2 regarding network and server configurations will be lacking in specificity to meet the PCI DSS testing.
Now as a QSA, you have a decision to make. Can you accept only 20% to 25% of coverage of PCI DSS requirements as being PCI compliant? I know I cannot. I need much more to work with before I can get comfortable that a SOC report provides the necessary coverage for PCI compliance.
Now What?
You and your client have expended all this effort and are no closer to the result desired than when this process started.
So, what to do next?
Work with your service providers that provide you SOC reports to include testing that adds the PCI DSS details that are missing. There will likely be a bit of push back from these service providers because adding testing to their SOC reports will cause the cost of their SOC reports to increase, sometimes significantly. So be prepared for it.
What you need to do is to have their auditors add the necessary testing details to the description of controls and then have them test that they are in place. Examples include:
- Password length, complexity, change frequency and the procedures followed to perform a password reset.
- Details surrounding privileged and general user management including provisioning, management approvals, users are implemented with least privilege and users are disabled or removed when terminated.
- Changes tested for segregation of duties between developers and operations, segregation of test, QA and production environments, production data not used for testing, developers do not have unrestricted access to production, test data and accounts removed before applications are promoted to production, changes document impact, they are appropriately authorized, they have been tested, they have been vulnerability assessed and they document backout procedures.
- If encryption is used to protect data, document the algorithms used, are key custodian agreements in place, are split key processes in place if performing manual key management, indicate if a hardware security module (HSM) is used and are keys changed when their crypto-periods expire or they are believed to be compromised.
- Document the configuration standards that are followed by device classes such as firewalls, switches, servers and test that they have been implemented.
- Document that anti-virus is implemented on systems commonly affected by viruses and malware, what the anti-virus solution is that is implemented, the anti-virus solution cannot be disabled and that the anti-virus solution is actively running on all systems it is installed.
- Document that vulnerability scanning is performed, how often scanning is performed and that vulnerabilities are remediated.
- Document that penetration testing is performed, how often penetration testing is performed and that findings are remediated.
- Document that log data is collected from all devices, it is reviewed at least daily and that it contains a date/time stamp, device name, type of log entry and other relevant information.
There are a lot of other areas that could be added to the SOC report, but these are, in my opinion, the bare minimum that need to be added to make the SOC report more relevant for PCI. I am trying to balance the amount of additional information needed versus the cost of providing it in the SOC report.
By adding all of this will it cover all of the gaps between SOC and PCI? No. But it should give your QSA significantly more comfort that the controls in place to meet PCI than what is currently being provided by CPAs.
PCI Guru 