What we learned about cloud security running a SaaS in AWS for 5 years - Part 1

This is the first in a series of posts on how we ran a SaaS in AWS that stored highly sensitive enterprise user data and not only had a good story to tell but also did right by our customers. There are several frameworks for cloud security (e.g. NIST, CSA, etc.) and some blog posts out there that talk about specific security controls. In this series of posts we describe what we learned about AWS security during the time we ran ThreatSim. I am also including some of the business and sales techniques we used to achieve commercial success. Some of the concepts here are based on tried and true security concepts. Some are a little novel and specific to AWS.

We have broken down our AWS security controls into the following areas:

• AWS Account Security
• Identity and Access Management (IAM)
• Network Security
• EC2 Instance Security
• Access Security
• Availability
• Monitoring & Logging
• Privacy & Data Protection
• Incident Response

In this series, we will be providing details on what controls we applied in each area above. Most of the security controls are free or take advantage of security features in AWS. Some are 3rd party vendor solutions that we really like. We don't sell any of these tools, but think highly of them as they worked well for us.

First, a little history###

In 2011, Stratum Security conducted a security assessment for a long-time customer in the financial industry. This customer had been conducting pen-testing and application security assessments for years but were still dealing with security incidents; so they wanted to try something different. The customer wanted to know two key things:

• How are attackers getting in?
• How are attackers getting data out?

Trivia: These two questions were the inspiration for the ThreatSim logo's two arrows:

So we conducted a phishing attack that targeted a large number of employees. We had so much data that we created a custom .Net app to send the emails, track who clicked, serve our own Metasploit and custom malware, etc. We ran the app out of AWS since EC2 IPs are not attributable and in case that our IP address was blocked, we could just grab a new elastic IP and keep going. This was literally our initial reason for using AWS - anonymity and the ability to change IPs quickly if we were blocked by our customer.

After the engagement was over we figured we'd put a login page on the .Net app, charge people via PayPal and have a neat little threat simulation tool.

We puttered along for a while and then things really took off. We re-wrote the entire app in Rails, hired a team, scaled the app to hundreds of enterprise customers, and became profitable. Fast-forward to October 2015 and ThreatSim was acquired. It was a good day.

But how did we get there? We knew that if we were going to be able to survive, let alone be successful we needed to put our security experience to work and do AWS right. Not only did we need a good story to tell, we needed to actually run a secure system in AWS.

Fast forward to 2017 - Stratum is building out the other side of the double-arrow ThreatSim logo by building our next SaaS XFIL, a data exfiltration and breach simulation platform.

How we used security to sell to the enterprise customer###

Most large enterprises use a procurement process that includes a due diligence process before the vendor can store, process, or transmit sensitive corporate data. Any large-ish enterprise will also have a 3rd party security questionnaire to fill out. These vary in length and complexity. One advantage of running a SaaS is that we got to skip over any parts about on-premise installed software.

If you are building or running an app in AWS we can help! Please contact us!

Get to the part where you actually do AWS security###

Go to Part 2: AWS Account Security.