3/21/2020 Latacora - The SOC2 Starting Seven

Latacora About Archive

The SOC2 Starting Seven

Mar 12, 2020

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 ( rst- 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

https://latacora.singles/2020/03/12/the-soc-starting.html 1/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 con gs 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 con guration.

#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 rms we’ve talked to or
worked with that are SOC2-certi ed. 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 “retro t 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.

https://latacora.singles/2020/03/12/the-soc-starting.html 2/13
3/21/2020 Latacora - The SOC2 Starting Seven

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-certi ed. Though: that guide
would be mercifully short: “ nd $15,000, talk to your friends who have gotten
certi ed, 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 of ces”.

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 ne. 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
ll 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 rst.

And, there are several different SOC2 audit “scopes”. You should focus on
“security” and “con dentiality”. 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
https://latacora.singles/2020/03/12/the-soc-starting.html 3/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 inde nitely, 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
https://latacora.singles/2020/03/12/the-soc-starting.html 4/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 “ rst 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 con gure 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
https://latacora.singles/2020/03/12/the-soc-starting.html 5/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 exible 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 le 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 con gs in
Github.

https://latacora.singles/2020/03/12/the-soc-starting.html 6/13
3/21/2020 Latacora - The SOC2 Starting Seven

You want all your infrastructure changes tracked, documented, and to be

repeatable. This is why people use Terraform in the rst 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” le, 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
https://latacora.singles/2020/03/12/the-soc-starting.html 7/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 lesystem image of an employee’s
personal device, because, uncomfortable.

For SOC2 purposes, MDM will address a lot of ddly 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 con gures 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.
https://latacora.singles/2020/03/12/the-soc-starting.html 8/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 Pro le”. Or for desktop
applications: “if it binds a local port, that port has to be covered in the
machine’s rewall 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:
https://latacora.singles/2020/03/12/the-soc-starting.html 9/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 nd 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

https://latacora.singles/2020/03/12/the-soc-starting.html 10/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 con g 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.

An SSH CA: The cool kids use CAs instead of ad-hoc SSH keypairs to gate
access to servers. This generates evidence, demonstrates control, and
streamlines engineering. SSH CA’s are great. But almost every SOC2’d
company doesn’t have one.

Customer-Facing Security Features: If it makes sense, MFA for all

customers is a great feature, but it’s not something you’re likely to get
dinged for by auditors.

Host Hardening: You should harden your hosts, set up auditd or EBPF perf
events, and tune up a seccomp-bpf pro le. But your auditor won’t even
know what you’re talking about when you try to explain this stuff.

Flow Logs: AWS will give you ne-grained connection logs of all the traf c
between your instances. They cost money. If you have an actual plan for
what you’re going to do with those logs so that they’re actually helpful to
you, enable them. But auditors don’t know what ows are.

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.
https://latacora.singles/2020/03/12/the-soc-starting.html 11/13
3/21/2020 Latacora - The SOC2 Starting Seven

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 rst met
Lybrand, and then give you a questionnaire to ll 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:

IDS/IPS: Don’t install an IDS. You have logs and MDM and security groups
and the evidence they generate will satisfy this concern. AWS GuardDuty
pricing is ridiculous but, if worse comes to worst, it will emphatically satisfy
this if someone complains. Your SOC2 auditor probably won’t, but some
fussbudgety Fortune 500 compliance person will. Or, use the scrappy
startup version: something like StreamAlert: much cheaper, a little less
turnkey, and fussbudget reviewers can’t tell the two apart. Either way: not a
priority for SOC2.

Firewalls: You’re in AWS; it’s built in and, in the common case, probably
default-deny already.

Web Application Firewalls: Most SOC2’d rms don’t use them, and most
WAFs don’t work at all.

Endpoint Protection and AV: You have MDM and macOS/Windows full
complement of security features and a way to force them enabled, you’re
covered. AV software is a nightmare; avoid it while you can.

Data Loss Prevention: You keep production data in your prod environment
and document the cases where it leaves. You therefore have better DLP
than Fortune 500 companies with expensive DLP tools. The DLP tools are
awful; avoid them.

Threat Management Tools: Most of the people who tell you that threat
feeds are important for SOC2 are selling threat feeds. Most of the rest are
https://latacora.singles/2020/03/12/the-soc-starting.html 12/13
3/21/2020 Latacora - The SOC2 Starting Seven

rationalizing a threat tool they purchased. Let that be their problem.

Risk Management Platforms: Risk management tools are essentially the

SOC2 IRL made esh. If you derive pleasure from lling out questionnaires,
don’t let us yuck your yum. But you don’t need anything more formal than a
spreadsheet and a git history to track the things that SOC2 auditors are
going to ask about.

Follow @latacora on Micro.blog.

https://latacora.singles/2020/03/12/the-soc-starting.html 13/13