What SOC reports won’t tell you (and what you need to do about it)

As a security professional, you’ve no doubt heard about Service Organizational Control (SOC) Reports in security conversations. When the need arises for determining how “secure” prospective vendors’ and business partners’ data centers are, simply ask for their SOC 1 or SOC 2 report. That is, if it hasn’t already been shoved in your face.

SOC 1 reports (typically the Type II version) are the go-to documents for seemingly all things security related. The problem is they’re creating a false sense of security. I’ve seen this first-hand time and time again, going back to the SOC’s predecessor, the SAS70. SOC 1 and SOC 2 audits/reports most definitely have their place in business, and the AICPA has done a good job developing these standards and there are many capable auditors performing the audits. The problem is not with the SOC audits or reports themselves but rather with those who are reading them.

The trouble begins when non-technical – and sometimes technical – managers and executives review SOC reports to, presumably, help them make informed decisions about who they’re doing business with. You see, every SOC report I’ve ever reviewed, and no doubt most of the others that are floating around, paint a positive picture of security. Everything, or at least most things, look good, on these reports. Therefore all must be well. Not so fast. Security goes much deeper and you need to be prepared to see, as Paul Harvey used to say, the rest of the story.

Here are just four examples of security flaws that will likely never be documented in a SOC report but can create immeasurable security risks for all parties involved:

• Missing patches on critical servers involving SSL, SSH, and DNS that provide remote command prompt access or facilitate denial of service attacks
• Weak passwords in a website that provides an attacker with full access into the environment
• Open network services, such as a SQL Server, that exposes critical business systems
• SQL injection on a Web page that permits undetectable database dumps/deletions remotely over the Internet

These items can create way more risk than any higher-level administrative, physical, and incident management policies and procedures reviewed by SOC auditors.

So before you assume all is well with the security based on a vendor’s SOC reports, you have to dig in deeper. Ask to see their latest penetration test or vulnerability assessment report. Look at the technical issues even more closely that you would higher-level policies and procedures.

If you skip over the technical issues, there’s no way to truly understand the security posture of the environment in question. You can’t afford a security vulnerability that flies under the radar, especially once the flaw gets exploited and you get called out. Ensure that everything that matters is found and fixed, and not just the tip of the iceberg.