An accountant and a security expert walk into a bar… SOC2 is no joke.
Regardless of whether you own a private or publicly traded company, it is worth considering a Service Organization Controls audit. For publicly held companies, these reports are required by the Securities and Exchange Commission (SEC) and executed by a Certified Public Accountant (CPA). However, customers often ask for SOC2 reports as part of their vendor due diligence process.
Out of the three types of SOC reports, SOC2 is the standard to successfully pass regulatory requirements and signals high security and resilience within the organization — and is based on the American Institute of Certified Public Accountants (AICPA) attestation requirements. The purpose of this report is to evaluate an organization’s information systems relevant to security, availability, processing integrity, confidentiality, and privacy — over a period of time (roughly six to twelve months).
As part of a SOC2 audit, it is necessary to conduct security checks across the company’s SaaS stack that will look for misconfigured settings such as detection and monitoring to ensure continued effectiveness of information security controls and prevent unauthorized/ inappropriate access to physical and digital assets and locations.
If you’re beginning or on a SOC2 audit journey, then an SSPM (SaaS Security Posture Management) solution can streamline the process and shorten the time it takes to pass a SOC2 audit successfully, fully covering your SaaS Security posture.
What are the AICPA Trust Services Criteria?
When external auditors engage in a SOC 2 audit, they need to compare what you’re doing to a long list of established requirements from AICPA TSC. These “Common Controls”, are divided into five categories :
- Security – Includes sub controls of the Logical and Physical Access (CC6)
- Availability – Includes sub controls of the System Operations (CC7)
- Processing integrity: Includes sub controls of the System Operations (CC7)
- Confidentiality: Includes sub controls of the Logical and Physical Access (CC6)
- Privacy – Includes sub controls of the Monitoring Activities (CC4)
Within each common control are a set of sub controls that turn the overarching standard into actionable tasks.
Passing a SOC 2 audit takes a lot of time, effort, and documentation. During a SOC2 audit, you not only need to show that your controls work during the audit period, but you also need to show that you have the ability to continuously monitor your security.
Going through the entire TSC framework is too long for a blog post. However, a quick look into a couple of controls of Logical and Physical Access (CC6) and System Operations (CC7) gives you an idea of what some of the controls look like and how you can utilize an SSPM to ease the SOC2 audit.
Logical and Physical Access Controls
This section sets out the types of controls needed to prevent unauthorized or inappropriate access to physical and digital assets and locations. Managing user access permissions, authentication, and authorization across the SaaS estate poses many challenges. As you try to protect your cloud apps from the dangers of distributed users, managing different access policies and their management becomes more difficult.
Under CC6. 1 control, entities need to:
- Identify, classify, and manage information assets
- Restrict & manage user access
- Consider network segmentation
- Register, authorize, and document new infrastructure
- Supplement security by encrypting data-at-rest
- Protect encryption keys
The department using a SaaS application is usually the one who purchases it and makes its implementation. Marketing might implement a SaaS solution for monitoring leads while sales implements the CRM. Each application is unique in its access rights and configurations. These SaaS owners might not have security training or be able to monitor each app’s security settings continuously, so security teams may lose visibility. At the same time, the security team may not know the inner workings of the SaaS like the owner so they may not understand more complex cases which could lead to a security breach.
An SSPM solution, maps out all the user permissions, encryption, certificates and all security configurations available for each SaaS app. In addition to the visibility, the SSPM solution helps correct any misconfiguration in these areas, taking into consideration each SaaS app’s unique features and usability.
In CC.6. 2 control, entities need to:
- Create asset access credentiations based on authorization from the system’s asset owner or authorized custodian
- Establish processes for removing credential access when the user no longer requires access
- Periodically review access for unnecessary and inappropriate individuals with credentials
Permission drifts occur when a user has certain permissions as part of a group membership, but then gets assigned a specific permission that is more privileged than what the group has. Over time many users get extra permissions. This undermines the idea of provisioning using groups.
Classic issues with deprovisioning, an SSPM system can detect inactive users, and allow organizations to swiftly remediate or alert security personnel to the problem.
Under CC.6. 3 control, entities need to:
- Establish processes for creating, modifying or removing access to protected information and assets
- Use role-based access controls (RBAC)
- Periodically review access roles and access rules
You might be managing 50,000 users across five SaaS applications, meaning the security team needs to manage a total of 250,000 identities. Each SaaS offers a unique way for users to identify themselves, view their identities and protect identities. Adding to the risk, SaaS applications don’t always integrate with each other which means users can find themselves with different privileges across different systems. This then leads to unnecessary privileges that can create a potential security risk.
An SSPM solution provides visibility to user privileges across connected SaaS applications, highlighting deviations from profiles and permission groups.
This section is about monitoring and detection to maintain effective information security control across all systems and networks. These requirements are difficult to meet due to the variety of SaaS applications and possible misconfigurations.
In CC7. 1 control, entities need to:
- Define configuration standards
- Monitor infrastructure and software for noncompliance with standards
- Establish change-detection mechanisms to aler personnel to unauthorized modification for critical system, configuration, or content files
- Establish procedures for detecting the introduction of known or unknown components
- Conduct periodic vulnerability scans to detect potential vulnerabilities or misconfigurations
It is unrealistic to expect from the security team to define a “configuration standard” that complies with SOC2 without comparing against a built-in knowledge base of all relevant SaaS misconfigurations and to continuously comply with SOC2 without using an SSPM solution.