Lessons Learned from SOC2 Compliance Projects

Sam Currie

2020-03-24T00:00:00.000Z

Helpful insight for preparing for the audit or just upgrading the security culture of your business

Gearing up for a SOC2 certification?

Here's a couple of helpful things to noodle over that I've taken away from consulting on compliance projects. Remember that the compliance landscape includes technology and people; if you do one without the other your security is just wishful thinking. I'm including here some of the more important takeaways to doing both - solid infrastructure with the organizational insight to make it work.

Containers are your friend

Yeah spinning up an EC2 instance and manually configuring your app is an easy way to get up and running...but does it scale? Is it secure? Can you prove it?

That last point is important - it's important because the point of the SOC2 is that you CAN prove it. How do you prove it? By gathering access logs, application logs, network logs, root access accounts, SSH accounts, backup retention policies, backup recovery plans, access keys, key rotation plans, etc, etc. Manually configured server instances require a lot of evidence gathering to convince an auditor (or your customers) that the service is secure. On the other hand, an auto-scaling container instance with ephemeral storage, no SSH or RDP access, and doesn't have publicly exposed ports because you have a load balancer doing that for you is a lot easier to document and lock down. This sort of application architecture additionally forces you to have a solid deployment pipeline in place and centralized logging - both of which are good for your business by saving engineering time and reducing frustration.

Evidence NeededVMs/Bare MetalContainer Service
Root/Sudo Accounts✔️
SSH Access✔️
SSH Key Rotation✔️
Automated Backups✔️
Backup Retention Policy✔️
Anti-Virus✔️
Change Management Policy✔️✔️
Security Groups / Firewall✔️✔️
Authorized Personel for Infrastructure Updates✔️✔️

Risk Assessments aren't so bad

Completing a series of risk assessments regarding your business, vendors, and technology use is a big part of the compliance process - it's a slog but you'll know a lot more about the services and companies that your business relies on at the end. For instance, did you know that last year Adobe Creative Cloud left an internal Elasticsearch instance exposed online without a password that exposed millions of user's information?

One of the excercises you will be doing as part of the process is putting together a table listing every vendor and service provider your business uses and then methodically researching each of them for security incidents as well as the company security policy (and keep in mind, if your product is used by other businesses, they will be scrutinizing your own company in the same manner). You may not change your mind about what vendors you're using (hopefully they learn from their mistakes, right?) but you'll at least be aware how many of your company email addresses are on phishing lists, you'll know which of your vendors takes privacy and security seriously, and you will have a good perspective on the more common exploits that your team needs to be thinking about.

Business Continuity for Developers

Business continuity is a fancy MBA term for what to do when an earthquake and a hurricane simultaneously hit the datacenter(s) hosting your services. The Business Continuity Plan (BCP) should nominally include: 1. A bus factor plan - i.e. when the senior engineer who got everything working that one time departs the company, gets hit by a bus, goes on vacation camping at Zion, or is otherwise unable to tell you what to do in the event of an emergency - you should still have a plan for fixing shit 2. The actual disaster plan - the applicable scenario is basically that your cloud vendor or your on-prem datacenter is out of commission, services are down, and now you need to get back up and running, probably on a completely different cloud vendor. Go.

Documenting plans for these scenarios is time consuming but provides a couple of bonuses everyone can get behind. First, if you are an engineer, documenting a bus factor plan means that your vacation isn't going to get interupted because someone thought they knew how security groups worked. As a leader in a company, having the plan means staff turnover is less expensive (and you don't have to call your engineers while they're on vacation, which increases staff turnover). Moreover, creating the plan means at least superficially testing that it works - and this can bring all kinds of surprises to light that are far easier to deal with now than during critical moments. Are your backup images larger than the cloud provider can handle when spinning up new instances? If you have to restore from a backup, how much data are you losing? Can you even transfer an image between vendors? Good questions to know now, not later.

Penetration Testing

Penetration testing is about more than checking off a list of OWASP items - performing even a light penetration test that includes network and serving probes tells you a lot about how your systems are working. If you have an intrusion detection system in place on your app or monitoring your network, the pen test will tell you how well it's working. Post-test, you should run through the logs you are collecting - access, application and network logs - to see what got picked up; use the test as an opportunity to make sure your diagnostics are working as expected and have enough coverage to actually investigate a security incident - even if the pen test doesn't reveal any vulnerabilities take the opportunity to make sure you have the tools to respond to an incident or breach.

A few good tools tools to check out for running internal pen tests:

  • GoVangaurd Legion - implements nmap and nikto for penetration testing and provides a nifty brute force password attack feature
  • OWASP ZAP - test your clients against OWASP best practices, super easy to install and use
  • SecLists - resources for penetration testing including lots of passwords

Legion at work on my Chromebook, it'll kick off a few thousand requests so your IDS better catch it: Legion at Work

I use a Chromebook with an Ubuntu image running on Crouton loaded up with the above for penetration testing. Its cheap, easy to setup, and if I lose it at the airport I won't be too sad.

Docs, docs, docs

At the end of the field audit when the certifying body issues you a shiny new SOC2 report, you'll look back at the process and realize you have a lot of documents. Hundreds of pages of policies and risk assessments. Well, unless you have an easy way for your team to access and sort through the docs, they ain't getting read. Before commiting to writing and maintaining all of these policies, try and think what the best format is for your organization.

  • Are you a small startup with two people and a dog? Do a Wiki on Github using markdown files.
  • Are you a small business running GSuites? Make a dedicated folder with a directory document linking to all the relevant policies.
  • Are you an enterprise with an internal website? Take a note from Glitch (formerly Fog Creek, the company that made Trello and Stack Overflow) and make an employee handbook that everyone can access through a browser.

Remember that no one is realistically going to crack your AES-256 encryption or brute force your 2048-bit SSH keys; social engineering is likely the biggest vulnerability in any organization and if all the goodness in your security policies takes even the slightest effort to find and digest, it just isn't going to be read. So make it easy.