Your Vendor's SOC 2 Report may be Inadequate

It took a year and a half, but the market finally understood that SOC 1 (aka SSAE 16) cannot be relied upon for assurance regarding security, availability, processing integrity, confidentiality, or privacy (SAPICP).  The misuses of SOC 1 that I chronicled since December of 2011 have started to taper off, and people are asking for SOC 2, the correct report for assurance regarding SAPICP.  Great.  

Now the challenge for everyone receiving SOC 2 reports from their vendors is the question of adequacy.  For example, take a look at your vendor's controls associated with Security Principle 1.2d "Preventing Unauthorized Access."  This control is a good indicator of whether the company had a thorough assessment of their internal controls or not.

One company's failure to prevent unauthorized access was what enabled a U.S. developer to outsource his own job to China.  The point of failure in this case was the company's lack of VPN concentrator log reviews.  Does your vendor's internal control associated with Security 1.2d or 4.1 include a daily review of VPN connections to the network by a competent and independent person?  What are the criteria that would trigger an investigation?  Keep in mind that internal threats are just as important to consider as external ones.

It is a good idea to compare your own organization's security controls with those listed in your vendor's SOC 2.  If your vendor's SOC 2 does not measure up, their SOC 2 report is inadequate.  Consider sending your security questionnaire to your vendor, and asking them to explain how each control in their SOC 2 maps to your questionnaire.  Below are some control areas that should be addressed in Security 1.2d 

• Remote access controls (including monitoring of logs)
• System account creation, modification, or deletion
• Root admin accounts usage (Unix/Linux environments)
• Service account controls
• Network equipment access controls
• Domain administrator access controls
• Inactivity timer/ automatic log-off
• Account lockout 
• Account re-certification 
• Disabling accounts inactive more than 90 days 
• Sharing of user accounts and passwords
• First time passwords 
• Password history, aging, and length
• Requests for user password reset 
• Password exceptions – non-expiring passwords
• Storing passwords in readable form
• Password complexity

Even within the control areas above, there is opportunity for weak security controls.  One of my favorite vulnerabilities to point out is the minimum password age setting.  For example, if you require password changes every 90 days, and have a 5 passwords remembered policy, but have a minimum password age set to 0, then I can simply change my password 6 times every 90 days, and get back to the password I like.  There are a million examples like this where seemingly secure control environments can be bypassed.

If you are a service organization seeking to provide your customers with a SOC 2 report that will not be rejected as inadequate, I recommend choosing a CPA firm that has security as one their core competencies, or one who has partnered with a security firm like CompliancePoint.


1 comment: