Pomerium Has SOC2, and So Could You!

SOC2 is one of the most pervasive security audits in tech and sets a benchmark that a company is legit and not just a herd of cats on laptops (or at least the cat’s acceptable behavior is documented in policies and noted in risk assessments).

Given SOC2’s ubiquity, we wanted to share our rationale, decision-making process, and tips to help you successfully implement SOC2. Here’s a synopsis of our journey, and what you might want to consider when starting your own SOC2 journey.

I’m a Pomerium Zero user, why should I care? 

There’s two types of SOC2 audits, often done in sequence. Type 1 is a point in time measure of company policies and procedures, which indicates the company has the necessary scaffolding to be secure. Type 2 is performed over an observation window and tests whether a company is both following its policies and demonstrating security through its combined policies. 

SOC2 type 2 certification is an indicator that Pomerium has effective baseline policies and procedures to keep your data safe and that these controls were both followed and effective over a period of time. It backs up the promises we make in the privacy policy and indicates that we can be trusted with your data. 

More about SOC2:

• SOC2 is “high level”. It touches on aspects like access control to hosts, git branch protection and software updates, but nothing below that. For example, it has no opinion on which ciphers are allowed for a TLS 1.2 connection. It’s up to the company to set good policies that lead to good technical decisions. 

• SOC2 is about determining if the security of the company is adequate, and it doesn’t say anything about the security of the product, like a pentest, or vulnerability scanner would. Of course, we do both and more to ensure the security of Pomerium Zero. 

• Unlike a technical audit like code analysis, penetration test, or a red team exercise, SOC2 is a paper audit where we provide evidence of our controls to the auditors in the form of documents, integrations with a compliance platform, and yes, some screenshots. 

How we approached SOC2 

Any audit is a resource intensive process and SOC2 is no exception. 

For us, SOC2 was driven by customer demand: customers were directly asking for our report and security questionnaires were asking questions that we would need to have answered for the audit. Since we had the capacity to take on the project, we looked for tools, templates, and vendors that would help us automate or offload many of the time consuming parts of the audit. 

Pomerium did not get a SOC2 type 1 report because we were confident that we were doing enough to succeed and did not see enough value in the report to justify the cost of the report. 

Pro tip: some companies use SOC2 type 1 report as a self-check to find gaps and fix them before starting a type 2 report. Self-assessments are available for a more modest cost, and many security contracting firms can help determine your company’s readiness—which may be better than jumping in the deep end. 

If SOC2 has the potential to be in your future, start the work now. Don’t wait for the decision to get SOC2 to enable branch protection or restrict access to a database. Best practices will make your audit much easier if you’re already in the habit. Getting buy-in for adding friction to your developers, or enabling two-step verification is best done well in advance. If you’re already in a good place, not a lot will change in the day to day work of most people. 

When we got into implementation, we took note any time we found ourselves being aspirational in policy, procedure, or technical control to help us stay grounded in what was achievable and focused on what we needed to demonstrate. We noted where we were aspirational as future projects for improvement. Having a VP already on board with future security projects is very helpful because policy writing gets them thinking about an ideal world. 

Decisions Decisions Decisions

Decisions we made and Decisions we did not

One of the earliest decisions we made was to go with a GRC platform. There’s two major players in the space, Drata and Vanta. As a small team and an operations team of 1, we wanted as much structure as we could get, so we opted for Vanta—but this might not be the right decision for you. From templates for required policies and in-platform approvals to automatically testing controls in other platforms, Vanta minimized the amount of busy work by turning the long slog of spreadsheets and screenshots to a few short requests from the auditors and only a handful of screenshots. 

We defined a complete system without including everything and the kitchen sink. We applied the controls across the board, but focused on our SaaS product and everything that interacted with it. This gave us a clear picture of what was in-scope and saved a lot of discussion on individual pieces. When building new tools, the engineering team was able to be more self-sufficient because it was clear whether something should be in-scope or out-of-scope without having to discuss. 

We did not use any virtual CISO offerings based on existing compliance, security and technical knowledge on the team. Writing effective, right-sized policies from the templates is key to implementing technical controls and writing detailed procedures that keep us in compliance. We found that explaining enough about our company, its values, and topics like Zero Trust was more work than fumbling through the first few iterations of the policies. 

We did not compromise on zero trust. While many template policies and default controls rely on traditional network topologies to meet their goals, we wrote our policies based on the zero trust principles. We ensured encryption is applied to all traffic, keys are unique between environments and systems, and identity is verified for users of the system. These policy measures and their corresponding controls were sufficient to convince our auditors of the security. We didn’t have to resort to a VPN, or expensive invasive tooling like VPC flow log analysis to achieve those goals. 

Reflections

Things we wished we would have done differently

Many of our team members had been through a SOC2 audit before, but none of us had been in the hot seat. Although we learned quickly and relied on past experiences to be successful, there were certainly things we would have done differently having been through it. 

If we had known what we know now, we would have…

1. Adjusted our policy to allow for some sort of post-facto reviews for a subset of changes and teams. In the vast majority of the cases, we were already requiring code review prior to merging to main and subsequently putting code into production. For the few places that the maintainers were a team of 1, this poses a problem of who reviews the code. Our workaround was to deputize some engineers to review changes, but this was far from ideal. 

2. Started writing our policies much sooner. Formalizing what we have been doing and closing the few gaps turned out to be a lot more writing than we expected. Vanta did a good job with helping with the boiler plate, but it was a lot of review. 

3. Turned off the Vanta alerts from the start and only turned them back on when we were close to our audit window. The platform alerts take the perspective an auditor would, which is great once you’re in compliance. In the early stages, it’s worse than useless to have a flood of alerts because a myriad of things are slightly out of compliance during roll-out. 

And that’s it for now! The kitties are hard at work making improvements for next year's audit!