An accountant and a security expert walk into a bar… SOC2 is no joke.
Whether you’re a publicly held or private company, you are probably considering going through a Service Organization Controls (SOC) 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 (TSC)?
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. The “Common Controls” fall into five groups:
- 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. In fact, as you look to secure your cloud apps, the distributed nature of users and managing the different access policies becomes increasingly challenging.
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 that utilizes a SaaS app is often the one that purchases and implements it. Marketing might implement a SaaS solution for monitoring leads while sales implements the CRM. Meanwhile, each application has its own set of access capabilities and configurations. However, these SaaS owners may not be trained in security or able to continuously monitor the app’s security settings so the security team loses 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 deprovisioning issues, an SSPM solution can spot inactive users and help organizations to quickly remediate, or at the very least, alert the security team to the issue.
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. Meanwhile, each SaaS has a different way to define identities, view them, and secure 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 allows visibility into user privileges and sensitive permission across all connected SaaS apps, highlighting the deviation from permission groups and profiles.
This section focuses on detection and monitoring to ensure continued effectiveness of information security controls across systems and networks, including SaaS apps. The diversity of SaaS apps and potential for misconfigurations makes meeting these requirements challenging.
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.