It’s a chore, but these days every serious SaaS company has to do it: obtaining or renewing your SOC 2 compliance certification. Especially for new startups that have recently grown enough to merit extensive security audits, the SOC 2 process can be confusing, grinding, and just generally time-consuming to get through. A developer tasked with helping to achieve compliance might despair that they have no clear guidelines or route to ensure their success, that the process is consuming too much of their productive time, or that implementing the proper security stack will send them way over budget.
At Sym, we have banged our knees on every hurdle a SOC 2 audit can put up. Our product is all about finding a synergy between elegant compliance and developer-friendly tools that are clean to install and use.
With the capabilities to authorize any AWS-ecosystem use case your team might have, extensive SOC 2-compliant logging systems, and a security-infrastructure-as-code philosophy that makes your security protocols legible and convincing to auditors, Sym just might be the solution for your SOC 2 AWS access management headache.
The trouble with preparing for a SOC 2 audit is that there is no hard-and-fast rubric that your auditors will apply. “SOC 2 auditors are not testing against some standard checklist that applies to all companies,“ says Ben Thomas, Sym’s Chief Information Security Officer (CISO), who’s been through the SOC 2 audit with over a hundred companies. “The auditors have more broad criteria that they check for, and how you fulfill those criteria is completely up to you. It’s both the beauty and the downfall of SOC 2.”
The ambiguity can make it hard for you to prepare for your audit, especially if you work for a startup that’s moving fast. Your company might be working with data in a novel way, tapping engineers with little compliance experience to prepare for the audit, or having to create entire compliance systems at the last minute.
In these situations, it can be useful to approach your compliance goals from the perspective of the auditor. An auditor wants to see that a company has clear internal guidelines for safe data handling and, more importantly, that these guidelines are consistently implemented and observed.
Above all, for an auditor, documentation is everything. Nothing can be proved from a handbook, so they want to see the logs, and be able to search for specific security events during the audit period. Can you pull up database access from June 10th, 2022? Do you have a list of users with current privileges for that deprecated dataset with no public-facing web access?
Common layout for a security auditor’s home.
Even if you are renewing a SOC 2 certification, moving to tools and procedures that adhere to the above principles can reduce the burden of this year’s audit and make demonstrations of continued compliance more routine. Implementing a new tool can also satisfy the auditor’s requirement to see progress made over the previous year.
Everyone who has a functioning company has some sort of security in place to prevent major breaches. If your company is mature and enduring enough to need SOC 2 compliance, those organically emerging security protocols might even work well enough to ward off the attacks that every company is constantly enduring. It’s not likely though – companies as established as Uber, Dropbox, and Twilio fell victim to access credential theft last year.
If your security stack really locks users down, slowdowns to development can be nearly as harmful as data breaches. In general, we find that companies use one of two archetypal approaches for access control, each of them only solving half the problem of access management:
This is the approach typical of fast-growing companies. Startups with low cost of scaling are a bit like molting crustaceans: as they expand, they find it necessary to constantly shed their armor in order to be comfortable. A new project gets spun up and needs to be deployed rapidly. Maybe a single senior dev has permanent admin privileges and people in the office just ask them in person when they need to pull from the database. Maybe in more sophisticated models there’s a central Slack channel where everyone can make requests and get auth tokens DMed directly.
No matter the particulars, companies that put a premium on speed tend to avoid the dreary, sticky business of building an airtight security stack – but when it's time for their product to mature and get SOC 2 certification, this debt comes due. There might be too many accounts with privileges for the auditor to stomach, or gaps in logging that make it hard to prove that access is controlled. Institutional turnover is a big risk with this model as well — many are the
tales of the senior dev with crucial privileges burning out and suddenly moving to an off-grid beach, a vital secret key floating away on the sea breeze.
Access keys can go missing in all sorts of ways.
So, as companies grow, they tend to mature out of these early security stacks and into a more steadfast, reliable system. But that comes with its own problems…
Fortune 500 companies don’t like the system described above. They have legal departments, acres of office space devoted to compliance management, and boards of directors asking pointed questions about risk. That’s why large, established companies tend to have concrete protocols for access management. This is often a ticketing system where access is requested in a central, maybe even proprietary, program. There might be some role-based access, where each team is endowed with a responsible senior – but their access won’t be a single point of failure in case they decide to ditch their pension and take up surfing. You can be sure that all access is logged and that protocols exist and are observed. Auditors love this stuff.
For the upwardly mobile company, AWS is a common method for approaching these types of security designs. IAM delivers features like those discussed above: seniority and position can be used to determine access, and temporary permission escalation is possible, if not trivial. But even with AWS as a security backbone, there are still clear disadvantages to this model of access management.
The most awkward aspect of such an administrative filter is the expense of installing and maintaining the system. And it's not just the cost of the bureaucracy itself: developers are dragged down by constrictive access protocols, and spend their valuable work time negotiating internal infrastructure rather than building profitable systems for clients. This sort of friction can be an existential threat to fast-moving companies, and creates unprofitable drag even in the behemoths that tend towards this model of security.
So, in traditional SOC 2 compliance, you are faced with a pair of grim options. But rest assured: these aren’t the only archetypes to build compliance. There is a better way!
What you’re looking for is a tool that structures, enforces, and records data access to your AWS ecosystem. Developer velocity is a premium for you, and you’re turned off by the way many tools slow your developers down — technology should speed us up! You also need a persistent scaffold that can endure through institutional churn and is clear to new users or administrators of your security stack.
What’s more, if you’re reading this article, you probably need that tool in a hurry. Luckily, new access control technologies tick all these boxes. Read on for our guide for SOC 2-compliant AWS access management, ready in under 30 minutes.
The solution we’re sharing here uses our own Sym software. We decided to build Sym because we saw the tension between the needs to stay compliant and to move quickly in modern software organizations.
At the core of Sym is a Slack bot. Why Slack, you might ask? In our opinion, Slack is the right medium for access control procedures because of the balance between low toil and reasonable design for security.
What can Sym do that tickets don't do?
“Tickets log very well, they keep things organized, but tickets don't actually perform that access update,“ says Ben Thomas, our CISO. “What Sym does is give you the flexibility of a ticket and a faster way to create it, while also performing the access update on the proper user for a temporary period — for example, five or ten minutes."
In concert with your organization’s existing Slack and AWS workspaces, Sym can quickly enable authentication, logging, and an extensible backbone of permissions management. This can be used to run all kinds of access procedures from simple approvals to more complex AWS Lambda functions, integrate with on-call apps, and more.
We promised you a 30-minute solution for SOC 2 compliance, so with the theory behind us it’s time to deliver on that promise.
Sym runs on Terraform, so you should have Terraform installed and some basic familiarity with infrastructure-as-code in .tf files. You will also need an existing Slack workspace and AWS resources to access.
You’ll need to install our Sym Slack app and Symflow CLI package.
With all the resources in place – a Sym account, Slack workspace, and the Symflow CLI — it’s a breeze to run through this 10-minute quickstart. It serves as a proof of concept for the connection between Sym, Slack, and how we deploy security as code.
This is really as simple as running symflow generate aws-iam.As long as you are authenticated to AWS in your terminal, the resulting Terraform code, once applied, will allow any user in your Slack to request timed power user status. A more detailed tutorial is available, but that will throw off our timing, so investigate only if you won’t keep us to our 30 minute promise.
With the core concept in place, it's time to follow a more advanced guide for your particular AWS resources. Maybe you want to temporarily escalate SSO privileges for a given user or alter their IAM group. You can grant access to a Postgres database, reduce stress on your PagerDuty on-call, and more. It’s easy to extend Sym to meet whatever needs you have, but if you want inspiration check out our whole repo of example flows.
So now you’re all set up with a basic Sym flow and the tools to get started integrating all your AWS cloud management into Sym. The basic example actually came in comfortably under 30 minutes (but if you’re anything like us, your Symflow install had to wait for a grueling package update that pushed the whole time for this tutorial to 30 minutes).
Theory is one thing, but it's helpful to understand how tools work in practice. Luckily, we have a great case study in bringing in Sym to handle SOC 2 compliance. The quick-growing B2B company Jellyfish was able to unwind inefficiencies created by attempting to retrofit compliance, assure customers of their security practices, and even expand their access control tooling beyond what was called for by the audit.
To learn more about Sym, you can easily sign up for our free tier and start learning the ropes. If you’d like a more personal touch, you can drop in for a meeting with our experienced technical team.
Even if you don’t feel the need to reach out just now — good luck with your SOC 2 audit!
