Accomplishing SOC 2 Type II in the Cloud-Native Kubernetes Era

We’re excited to announce that ShiftLeft has achieved Service Organization Control 2 Type II compliance with zero exceptions. We began this compliance effort 10 months ago. Back in May 2019, we achieved SOC 2 Type I compliance. While this was an important milestone, having also obtained Type II compliant status within seven months is simply sensational.

What is Type I vs. Type II?

First, a little explanation of the difference between Type I and II is in order. Think of Type I as a snapshot in time. By achieving this, we’ve effectively demonstrated to independent auditors our ability to design and implement sound security controls and policies governing our development, production, and customers’ data during the audit period. Specifically, these controls apply to the way we manage and enforce information security within our organization. For example, this includes, but not limited to, the CI/CD pipeline, pull requests, and production infrastructure. Beyond establishing these Type I controls and policies, successful application on a daily basis is the gold standard.

Going one step further, Type II is more meticulous than Type I. This is where the rubber meets the road. Type II delves deeper into the day-to-day operations and details of the established security controls and policies of ShiftLeft to ensure we rigorously apply and adhere to those standards without exceptions.

Simply put, Type I is talking the talk while Type II is walking the walk.

Trust Service Criteria

Illustration of SOC 2 Type 2 Trust Services Criteria
Diagram 1: Trust Services Criteria

These are the trust services criteria we had to design our security controls and policies upon. Starting at the bottom of box 1, this consists of employee roles and responsibilities. Box 2 includes vulnerability management and infrastructure monitoring. In the middle of the pyramid is box 3, which is for identity access management and role-based access control. Near the top, box 4 involves software, system, and infrastructure change management, security alerting and monitoring. Finally, box 5 at the top consists of risk management and mitigation, and business continuity.

Assembly Required

Illustration of Infrastructure with multiple tools, services, and cloud providers
Diagram 2: Multiple Tools, Services, and Cloud Providers

Rolling up our sleeves, we dived right into designing and rolling out all the controls and policies based on the trust services criteria to the various tools, services, and systems in our dynamic and virtualized infrastructure, as illustrated in diagram 2. Being a cloud-first startup, it means we have various tools, services, and systems distributed across multiple locations, networks, and cloud providers. Each of these vendors and third-party tools has its own authentication methods, some more strict than others. In order for us to be able to effectively establish sound controls around all these components is a challenge in it of itself but to design and implement it in such a way that will allow fluid day-to-day operations is quite difficult. Challenge accepted!

We began by running a thorough assessment of all of our HR, development, operation, and security processes and were honest with ourselves in determining what works and what doesn’t. The ones which didn’t work or were irrelevant to our mission were discarded. The working ones were improved upon to ensure it would stand up to rigorous SOC 2 auditing and testing.

We then moved on to the logical and physical security portion. This included all the tools and systems depicted as rectangular boxes in diagram 2. As illustrated in this diagram, we treated these boxes as logical and physical layers. We then designed and enforced RBAC on each of the layers, starting at the lowest level and working our way up to the birds-eye view level of the infrastructure.

Employing such principles and industry best practices, we were able to design controls and policies that will give us optimal security at every level of all the tools, services, and systems we interact with.

ShiftLeft’s SOC 2 Compliance Commitment

By achieving SOC 2 Type II, ShiftLeft has demonstrated its commitment to keeping our customers’ data secure. This will enable our customers to confidently use our products and services.

Accomplishing SOC 2 Type II in the Cloud-Native Kubernetes Era was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog – Medium authored by Davy Hua. Read the original post at:—-86a4f941c7da—4