The SOC2 Starting Seven

- 17 minutes read - 3604 words

So, you plan to sell your startup’s product to big companies one day. Congratu-dolences!

Really, that’s probably the only reason you should care about this article. If that’s not you, go forth and live your life! We’ll ask no more of your time.

For the rest of you: Industry people talk about SOC2 a lot, and it’s taken on a quasi-mystical status, not least because it’s the product of the quasi-mystical accounting industry. But what it all boils down to is: eventually you’ll run into big-company clients demanding a SOC2 report to close a sale. You know this and worry about it.

Here’s how we’ll try to help: with Seven Things you can do now that will simplify SOC2 for you down the road while making your life, or at least your security posture, materially better in the immediacy.

We’ll cut to the chase and list them out, and then dig into explanations.

#1: Single Sign-On

You’re going to sign up for Okta or Google Cloud Identity, tie as many of your applications (first- and third-party) into it, and force 2FA.

#2: PRs, Protected Branches, and CI/CD

You’re already doing this, but just to be sure: you’re going to lock your deploy branch and require PRs approval to merge to it, and you’re going to automate deployment.

#3: Centralized Logging

You’re going to pick a logging service with alerting and use it for as close to everything as possible.

#4: Terraform Or Something

You’re going to do all your cloud provisioning with something like Terraform and keep the configs in Github, using the same PR process as you do for code.

#5: CloudTrail And AssumeRole

You’re going to set up CloudTrail logs and require your team to use AssumeRole to get to anything interesting in your AWS configuration.

#6: MDM

You’re going to pick an MDM system – it’s probably going to be Jamf Pro – and install it on all your desktops and laptops, and then use it to make sure everyone’s got encrypted disks and up-to-date patches.

#7: VendorSec

You’re going to start tracking all the software you subscribe to, buy, or install in a spreadsheet and start doing some simple risk tracking.

You do these Seven Things, then write some basic policy documentation, and you’re at approximately the maturity level of the firms we’ve talked to or worked with that are SOC2-certified. Since these are all things you should be doing anyways, you might as well do them early, when they’re easy to roll out. We’ve been through the “retrofit Single Sign On” or “change the way all the logs are collected 3 years in” exercises, and they are avoidable nightmares, so avoid them.

…

Now, before we get into the details of the Seven Things, some thoughts about SOC2.

First: for us, SOC2 is about sales. You will run into people with other ideas of what SOC2 is about. Example: “SOC2 will help you get your security house in order and build a foundation for security engineering”. No. Go outside, turn around three times, and spit. Compliance is a byproduct of security engineering. Good security engineering has little to do with compliance. And SOC2 is not particularly good. So keep the concepts separate.

This is not an instruction guide for getting SOC2-certified. Though: that guide would be mercifully short: “find $15,000, talk to your friends who have gotten certified, get referred to the credible auditor that treated your friends the best, and offer them the money, perhaps taped to the boom box playing Peter Gabriel you hold aloft outside their offices”.

If there is one thing to understand about SOC2 audits, it’s: SOC2 is about documentation, not reality. SOC2 audits are performed by accountants, not pentesters. You’ll tell your audit team what security things you try to do. They’ll call upon the four cardinal directions of ontology in a ceremony of shamanic accountancy. They’ll tell you those security things are just fine. Then they’ll give you a 52,000-line questionnaire called the Information Request List (IRL), based in some occult way on what you told them you’re doing. And you’ll fill it out. You’ll have a few meetings and then write them a check. They’ll put your company name on a report.

We are close to a point where we can offer you some practical SOC2 advice, but before we can, you need two more concepts.

See, there’s two kinds of SOC2 audits startups undergo: the Type 1 and Type 2. The subject matter of both audits is the same. The difference is that Type 1 audits set a standard for your company, and Type 2 audits measure how well you complied with that standard. Type 1 audits are the “easy” audits and the only ones many startups care about at first.

And, there are several different SOC2 audit “scopes”. You should focus on “security” and “confidentiality”. A SOC2 audit is going to involve a bunch of business documentation, no matter how you set it up. We don’t care about that stuff here; we’re security engineers talking to other engineers. So we’re just going to focus on the security details; and, anyways, security is all your big-company sales prospects care about when they ask for SOC2 reports.

Now, the practical advice: your Type 1 audit sets a bar for your future Type 2 audits. Eventually, you will meet an angry bear in the woods who will withhold your pilot project purchase order until you produce a Type 2. When that day comes, you will likely be happier if you did things in your Type 1 to make the Type 2 simpler. It is easy to add new security controls after your Type 1. To an auditor, more controls are more good. It is not as easy to remove security controls from your Type 1. The auditors may ask why you did that.

The obvious conclusion is that you should consider minimizing, within reason, the security controls you choose to surface in your Type 1.

At any rate, if you’re eventually going to SOC2, there’s an easy way to judge the ROI on security tasks: you want things that (1) are generally valuable in their own right, (2) things you can keep doing indefinitely, and (3) generate lots of evidence for the IRL.

…

Single Sign-On

Set up Okta. Link all your third party applications to it. Turn on mandatory 2FA. Disable non-Okta sign-ins on as many of the applications you can. Now write a short onboarding/offboarding script and keep a spreadsheet recording who you’ve offboarded.

It doesn’t have to be Okta. It can be GSuite, or, if you’re a glutton for punishment, you can even run your own Shibboleth instance. What’s important is that there’s just one of them, and that as many of your applications as possible are linked to it.

We would tell you to do this even if you weren’t SOC2’ing. You need an inventory of your applications, a single place to disable access for users, and a way to force 2FA in as many places as possible. The alternative is madness. Every CSO we’ve asked has SSO in their top 5 “first things they’d do at a new company”.

We’re aware: this costs money. Okta will charge you per-user. They might even charge more for 2FA. And your SAAS subscriptions will tax you for asking for SSO . This is annoying. But the money probably isn’t material, and you should just spend it.

As to why it matters for SOC2: it will probably address dozens of “Access Control” line items in the IRL. And “Access Control” is most of the audit. A big chunk of the meetings you take with your auditors might just be walking through your Okta setup, and many of them (like password lockout) are things your SSO will configure properly by default.

PRs, Protected Branches, and CI/CD

Enable Protected Branches for your master/deployment branches in Github. Set up a CI system and run all your deploys through it. Require reviews for PRs that merge to production. Make your CI run some tests; it probably doesn’t much matter to your auditor which tests.

We probably didn’t even need to tell you this. It’s how most professional engineering shops already run. But if you’re a 3-person team, get it set up now and you won’t have to worry about it when your team sprawls and new process is a nightmare to establish.

If most of the SOC2 security audit is about Access Control, most of the rest of it is about “Change Management”. The sane way to address Change Management is just to get everything into Github, and then use Github features.

An easy bonus point you can pick up here: write a simple PR security checklist. “PRs need an extra sign-off if they involve changing any SQL queries” is an example of what might go on that checklist. Or, “extra review if this PR calls dangerouslySetInnerHTML”. It doesn’t matter how detailed the checklist is now; you just want to get the process started. You’ll learn (from your mistakes) what belongs on it over the long haul.

Centralized Logging

Sign up for or set up a centralized logging service. It doesn’t matter which. Pipe all your logs to it. Set up some alerts – again, at this stage, it doesn’t matter which; you just want to build up the muscle.

Over the long term, a lot of your security monitoring is going to involve log munching. There are things you’ll want to build, like customer fraud detection, that will be much simpler if you can set up a log-grepping alert that just spits things onto a Slack channel. I feel like I shouldn’t need to sell anyone on centralized logging, but, here I am doing that.

If most of SOC2 is Access Control and most of the rest of it is Change Management, then most of the rest of the rest is “Monitoring of Controls”, and a flexible centralized logging system is going to answer every monitoring control item your auditor asks about.

If you have a control check that runs regularly and produces a file or some JSON, you can also just put it in S3, and then go turn versioning on. Presto: a fossil record. We do this for a lot of Latacora’s controls and auditors seem to love it. Does your policy say you’ll review it every X time? Great, have a separate CloudTrail with less retention with S3 read events.

Terraform or Something

I’m assuming you’re using AWS, but you can transliterate to GCP in your head; it’s all the same.

The AWS console is evil. Avoid the AWS console.

Instead, deploy everything with Terraform (or whatever the cool kids are using, but it’s probably still just Terraform). Obviously, keep your Terraform configs in Github.

You want all your infrastructure changes tracked, documented, and to be repeatable. This is why people use Terraform in the first place. Even for spare-time solo projects, Terraform is worth it. It will gross you out at times; it grosses everyone out, and they still use it, because it’s better than not having it.

Of course, what we’re doing here for SOC2 is ensuring that your infrastructure work can draft off the Access Control and Change Management your development work already uses.

CloudTrail and AssumeRole

Turn on CloudTrail . Use IAM accounts exclusively. Minimize the access you give directly to users, and use role assumption wherever possible . Users will call assume-role to get an AWS session that can do anything meaningful in AWS.

You now have an audit log for engineering changes to AWS that in some sense signals the intent the engineer had when making the change. You also have a straightforward way to review the permissions each engineer has.

There are bonus points to be had here as well:

First, set up multiple AWS Accounts; make CloudTrail logs from your sub-accounts feed into a parent account to which you grant limited access. The parent account doesn’t do much and is unlikely to be compromised. The sub-accounts do lots of random things and are where an AWS compromise is likely to actually happen. You’re now resilient to some of what might happen in a compromise.

Second, force AWS MFA, and get your engineering team to use aws-vault . aws-vault stores AWS credentials in your OS keychain and mints new sessions from them as needed. It’s actually easier to use than the AWS “credentials” file, and much more secure.

Honestly, you probably don’t have to do all of this stuff to clear a SOC2 audit. We’ve seen organizations where everyone just has AdministratorAccess clear audits without a problem. But that just goes to our theme: things that have high value for a startup, from the jump, and will address auditor questions. This stuff has high ROI and you should just do it.

MDM

You’re probably all Macbooks. So install Jamf Pro on all your laptops. Use it to require hard disk encryption and push out OS updates and whatever standard security tooling you come up with.

Unlike the previous item, which wasn’t a requirement for SOC2, this probably is. Or rather, something like it is, and MDM (which is what Jamf is) is the friendliest way to satisfy the requirements.

From both a security and a compliance perspective, you need a way to keep a handle on all your endpoints. And it should go without saying that all your endpoints are owned by your startup, and nobody is using their personal laptops to get to AWS or your admin consoles. A basic rule of startup security engineering is that you want to minimize the number of situations where you could be demanding an after-incident filesystem image of an employee’s personal device, because, uncomfortable.

For SOC2 purposes, MDM will address a lot of fiddly endpoint security questions. Simple example: your OS will have basic anti-malware controls. SOC2 cares about anti-malware (it’s one of the few technical security issues SOC2 knows about). You’d rather address auditor concerns by documenting how Jamf configures everyone’s OS to enable anti-malware, than by demonstrating that you’ve installed some god-awful Mac AV program on all your desktops.

Another bonus point: standardize everyone on Chrome. We don’t have to grumble about why; we’ll just observe that this is what almost every security team does anyways. Now you can use Jamf to inventory all the Chrome Extensions that your team is running. Also, you get to be a lot less worried about browser exploits.

Vendorsec

And, speaking of Chrome Extensions, our last item: standing up a vendorsec program.

Vendorsec sounds cool and mysterious but at this stage of the game it’s really just a fancy way to refer to a spreadsheet you’re going to keep. That spreadsheet will inventory all the third party applications – SAAS subscriptions, desktop applications, Chrome Extensions, and pretty much every other piece of software you use other than software development libraries.

As you sign up for more SAAS subscriptions, start asking for security documentation. Two reasonable things to ask for: the report from their last public penetration test, and their SOC2 report (SOC2 is infectious, like the GPL; your auditors will want to see SOC2 reports from your vendors). Collect them in a Google Drive folder.

You want to start thinking about how you’re going to vet vendors. For instance: you can come up with some basic rules about Chrome Extensions; “if it gets access to the DOM, it has to be run in its own Chrome Profile”. Or for desktop applications: “if it binds a local port, that port has to be covered in the machine’s firewall rules”. This is all good stuff and you should do as much of it as you can; you’ll thank yourself later.

But to start with, you just want to be documenting things. Your auditor’s IRL will absolutely ask you for evidence about which third-party applications you’ve signed up for, and how you made decisions about them. Your vendorsec spreadsheet will also be a pretty valuable part of your “Risk Assessment”, which is itself just a big spreadsheet.

…

There are other reasonable security engineering things you could get an early start on, and many of them would play well in an especially diligent SOC2 audit. For instance:

VPN to Admin Console and SSH

You could put your admin consoles behind a VPN, link the VPN to your SSO system, and then nobody gets any admin rights anywhere without going through SSO.

Vulnerability Management

You could start tracking the alerts Github gives you for vulnerable dependencies. Most won’t apply to you even if you run the affected component; track them anyways in a spreadsheet or something. Do some dry-run base image updates.

Pentesting

You could get a third-party penetration test. Any test will count as far as auditors are concerned. You can spend more to get an assessment that will actually matter for your team and find real bugs.

Security Policy

You could get boilerplate security policies and an employee handbook (your payroll provider may be able to give you a handbook). Most of the policies don’t matter in their particulars (it’s more important to have them than to have them be precisely tuned), but the Incident Response policy does matter; review and customize it. Get the policies and handbook signed by employees.

Incident Response

Any time anything security relevant happens, you could make a private Slack channel named for the incident. The most common incident will be “employee lost phone” or something, and the response will be “didn’t matter because phone was encrypted and access was revoked and logs were reviewed”.

Access Reviews

You could start holding a monthly meeting, recorded in a spreadsheet or whatever, reviewing everyone’s access to things (hopefully this is just a walk of your SSO config and IAM role permissions).

This is all good stuff, and may be helpful while you’re getting audited (though again remember not to set a bar for yourself you don’t want to clear next year). But you don’t have to do all of these just to get a Type 1 Report.

…

There are security things you can do that are great, but aren’t going to matter at all for SOC2. Do them when they make sense. Don’t do them because you think you have to in order to get SOC2’d.

…

There are security engineering things that are bad, and, like capitalist and communist and lots of things they’ve heard about, your SOC2 auditor might bring up.

Here it’s worth remembering the basic idea behind a SOC2: you are going to tell your auditors the security things you do. They are going to enact a sacred ritual written on vellum in blood on the windy heath where Coopers first met Lybrand, and then give you a questionnaire to fill out. When your auditor asks about these things, or puts them on your IRL, you are allowed to say “we don’t do that thing, and here is why”. You know more than they do about security engineering.

Some of those things include: