We are in the business of identity and access governance for cloud native applications and have built a SaaS platform to offer our solution. We understand the importance of security and wanted to start with SOC-2 compliance to implement basic security for our environment.
Until now, I knew about SOC-2 compliance and was involved in the process in bits and pieces. But as CISO at Stack Identity, I own the complete responsibility of security and had to learn more about SOC-2. After reading through a few articles and talking to friends who had achieved SOC-2 compliance for their respective companies, I thought of dividing SOC-2 compliance into 3 areas:
- Governance – this involves defining different policies that your organization will follow
- Administration – this is all about gathering the important metadata as required by your policies and retaining it over a period of time
- Audit – the external auditor might ask questions about the policies you have defined and ask you for evidence that you are following the defined policies
Governance: Defining Policies
SOC-2 compliance doesn’t have an expiration date, but it is tied to the organization’s controls at a specific point in time. As your organization’s environment evolves, you have to undergo an annual audit process to demonstrate ongoing compliance and provide updated reports to your customers.
For whatever policies you define, you need to make sure you have the ability to administer those policies for your environment. For example, we defined a policy to support business continuity and disaster recovery for our environment. We needed to have a continuous backup solution, ability to quickly restore from the backup data with the defined RPO/RTO as well as full infrastructure level automation to create the entire environment from scratch.
While we implemented what we defined in the governance part, I felt the most important aspect of the compliance process was to collect and store the required metadata as well as present that data during the audit process.
Administration: Preparation, Metadata Collection and Retention
Before we started to collect the required metadata, we needed to do some preparatory work on the metadata. Specifically,
- Identify where the customer data is stored
- Classify the data stores as appropriate
We followed the tagging approach to identify customer data and classify it. While our environment was small we knew exactly which new data sources were being introduced and could monitor them. I can imagine how difficult this would be to continuously monitor new data sources being created by bigger teams. Most companies would need a defined process to understand creation of new data sources and have some approval process in place.
Once the metadata preparation is done, it’s relatively easy to monitor the controls around it. There are a lot of open source and commercially available tools that can collect and store the data for you.
We took automation very seriously – right from implementing VAPT runs through our CI pipeline to fully automate the infrastructure creation.
We knew that the metadata we collected would serve as evidence for the audit process.
The audit is the last and the most important part of getting SOC-2 certified and is done by an external certified auditor. There are two parts to the audit. The SCO Type-1 compliance only checks for the governance – whether you have defined all the necessary policies for your environment. The SOC Type-2 audit runs over a period of time and checks if you are really following all the defined processes.
Since we defined a way to collect and store metadata, we didn’t find it challenging to present this information to the auditor.
The auditor may ask you questions like,
- Where is your customer data?
- Is the customer data PII/PCI/PHI?
- Who created a given identity?
- Who gave this identity access to customer data?
- Who approved the provided access?
- When was the access given?
The governance (defining policies) and administration (ability to follow the defined policies) processes you define would help you understand what data you need to collect. But that’s not sufficient to answer these kinds of audit questions.
We defined (and followed) a policy to raise a service request for every identity creation as well as every access required. The hard part was correlating the service tickets with the identity or data creation or the access change events.
We needed a system in place where we not only collect all the necessary data, but are also needed to be able to correlate this data and eventually query it to quickly answer any questions during the audit process.
SOC-2, Security and The Need for an Identity-First Approach
Although one has to consider different security aspects such as network security and application security, identities and their access remains most crucial from my perspective, especially in a cloud native world. Your identities could be defined in multiple systems and you need to have an identity centric visibility into your environment. Even if you have SSO implemented for all your systems, you need to understand what access each identity has in a given system.
SOC-2 certification is an important validation of a service organization’s controls and processes, though it does not guarantee that a system is fully secure. Organizations should view SOC-2 certification as one aspect of their overall security strategy and continue to assess and improve their controls to maintain a secure environment.
Calling all CISOs: What is your SOC-2 experience and would automation change your approach?
As both a co-founder and CISO at Stack Identity, I’d like to invite fellow CISOs to share their experiences, feedback and learnings on best practices and automation with respect to the SOC-2 progress. From my experience, the SOC-2 process can be streamlined through automation and simultaneously SOC-2 can now become an operational foundation that enables continuous monitoring of cloud security risks, and not just a static exercise for compliance purposes. Connect with me on LInkedIn or email Stack Identity directly at firstname.lastname@example.org.
By: Sanjay Kale, CISO