It feels like everyone is getting SOC2 earlier these days. It has become table-stakes for any B2B SaaS company. From signing all of the paperwork to get started, to receiving our clean audit report, the process took under 2 months. We're still in our audit window for SOC2 Type 2 but we want to share the things we did to make our SOC2 painless.

If you've never been through SOC2 or a security audit then it can be seriously intimidating. There are spreadsheets, policies, policies about who can approve new policies, pentests, and it feels like if you miss one single thing you'll immediately fail. It's overwhelming at first.

I've been a part of countless security audits in my career and there's two really important things I've learned:

• Put most of your effort into a small set of controls that will most meaningfully improve your security. This seems obvious, but with dozens of things to do, it's easy to try to do everything perfectly, and end up doing it all poorly.
• Communicate what is important to you to your auditors. It's likely some controls you don't want to worry about or don't fully make sense for your company. You should be direct and communicate that with your auditors ahead of your audit, so you have time to brainstorm other ways to meet what the standard wants.

As a small company, these were the areas we put most of our efforts into to make our audit painless.

FIDO2, Webauthn, Passwordless, Oh my!

In 2023, multifactor authentication is still the most important security control at your company. At RunReveal, every employee has a yubikey in their laptops at all times (except for when taking this picture) and we use it as our secure second factor when authenticating to our systems.

Security keys make phishing and account takeovers a relic of the past. The last few years have seen many mature companies with big security budgets breached if they were relying on other forms of multifactor auth. Tools like evilginx have also shown how easy setting up a pixel perfect phishing site can be, and attackers have noticed.

The longer you wait to adopt webauthn, the harder it is to move to later, so RunReveal adopted security keys from day one. Moving to webauthn will not only make you significantly more secure, it's an important piece of your security story that will delight your auditors, nearly eliminate the risk of phishing, and make your identity and access management requirements easier to meet.

Security monitoring and alerting that just works

A huge part of any security audit is collecting logs, visibility into your systems, and knowing when things go wrong. Unfortunately, this can be expensive and hard to set up. For our SOC2, we used our own product to make this process easy, and show we had visibility into the things that matter.

We monitor from where in the world people log in, access our systems, use AWS keys, use IAM role credentials, download or access our Google Docs, and when code is pushed to production and deployed. We give all of our customers the same alerting when they sign up, too.

Using RunReveal, our security logs are stored, used for custom visualizations we built around our most important assets, and queried on a schedule every few minutes to look for unexpected activity.

Even without a security operations center or a mature dedicated security function, there's no reason you can't monitor what matters. Can you answer which google docs or drive assets were shared publicly in the last month? Or what an IAM key usually does versus what it's done the past 24 hours?

Being able to show your auditors that you know how to answer security critical questions from your logs, with some basic alerting, is a huge sign of maturity. If you're going through an audit, make sure to sign up for RunReveal because we offer these capabilities out of the box to all of our customers.

No containers, simple infrastructure, and automatic patching

There's no shortage of scanners to buy, and there's no shortage of places that you could be "adding coverage" with more scanners. For many security teams, adding and removing scanners is a Sisyphean task. Mature security organizations will have authenticated host-based scanners, cloud posture scanners, network vulnerability scanners, static analysis, web vulnerability scanners, etc.

The principle goal of all of these scanners is more of less to alert you when you are impacted by CVEs (i.e. known vulnerabilities) in your infrastructure. But as the saying goes, an ounce of prevention is worth a pound of cure. Detecting vulnerabilities that are in your systems is a headache, usually involves deploying specialized agents, and we didn't want to run complicated scanners that give us more work.

To handle this we wanted our infrastructure to be as simple as possible. We avoided using containers, and have a single node type that each runs all of our software. Each node runs:

• rrq, Our main data process that receives data, runs our customer's wasm functions, and stores our customer's data in clickhouse.
• rrsched, the process responsible for running our customers scheduled queries at a time interval.
• api, the control plane and where customers query their data and configure their RunReveal account.

In addition to these processes we also run nginx and tailscale on each node. Nginx sits in front of our api and rrq, while tailscale is the access broker we use to access our production systems.

Because our infrastructure is designed to be simple with few moving parts we were able to avoid implementing scanners or introducing new tools into our infra. The two key things that we did implement.

• unattended-upgrades. All of our hosts will automatically update system packages when security updates become available.
• dependabot. Updates our code's dependencies and submits helpful pull requests directly in our Github.

We don't have numerous node types, containers that our applications run in that may have their own system dependencies, and we only write our core applications in Go. The simplicity and homogeneity is what gives our infrastructure the ability to horizontally scale, and provides us with a very simple security story.

When you're planning what scanners and patching capabilities you need for your audit, having as few languages, environments, node types, and methods for deployment as possible will reduce the work you need to do. The security coverage you need increases exponentially as you write in more languages, deploy to more places, and add more layers of abstraction. Beware of complexity.

The cherry on top is the simpler your systems are, the easier it is to write your SOC2 System Description document. In a complicated environment it can take a lot of effort to be complete and accurate, but when all your nodes do the same thing the system description document is a node description, and a proof by induction that it's true for the rest of your nodes too.

Automate the low hanging fruit

Companies like Vanta, Drata, and Secureframe can help you set up the baseline of policies, documentation, and evidence collection that you need to get your compliance started.

These "audit in a box" companies work a lot better for companies solely using AWS and GCP, and bigger companies are likely to outgrow them once they have a dedicated security or GRC function that is more than a handful of people. The changes they ask you to implement are best practices that you can (usually) quickly fix. They poll your cloud services to collect information and show you if things drift away from being in a good state, and they can show the list of documentation you may need to scramble to find and collect for your audit.

We worked with one of the "audit in a box" firms for our audit and found it useful to show our good practices, and have a single place to collect our evidence, and it was useful to make sure we weren't forgetting anything.

Go beyond the compliance

Companies go through audits for their customers but an audit is only one piece of what your customers need to know about your security.  We've all gotten an email after a breach disclosure that says "We take our customer's security seriously" and muttered to ourselves, "Yeah right.." as we delete it.

The best way to show your customers that you care about security is to be proactive and transparent about communicating your security practices directly to them. The first time your customers read about your security practices shouldn't be when they are reading about an incident you handled. Most of your customers won't read your entire SOC2 report, but they will note blogs, webpages, and more that share the details of how your systems work. The more detailed the better. Compliance serves a different purpose and can show that your company is approaching security in a holistic way, it can add credibility to your narrative around security, and allows your customers to validate your practices in a standard way.

Without compliance standards we don't have a shared language around security controls or even shared understanding of what basic security requirements need to be met. Without other types of collateral and transparency, your compliance effort amounts to just a badge on your website. You need both!

Sign up for RunReveal today, and make your customers proud of your security.