What if you don’t have the luxury of a greenfield. You are looking at an already built application, and asking yourself, how do I secure this?
Join 35,000 others and follow Sean Hull on twitter @hullsean.
One can think of it as a giant labyrinth, with many turns and many paths. Some of those paths have not had light shining in them for some time. So you’ll need to be cautious, thorough, and vigilant.
Here are some notes on where to start.
1. Scanning – code
One area you’ll need to dig into is the application code itself. If you don’t have the luxury to push new code, you’ll need to verify what version is deployed, and scan the repository for keys or passwords. You can also scan on the server itself. Better to double your efforts.
Read: What do the best engineers do better?
2. Scanning – network
Your VPC is obviously your first layer of defense. Scan the routing table policies, to make sure there aren’t open ports or whitelisted IPs.
Do the same sort of review for security groups, as those are an alternative method for configuring access to servers.
AWS has a service called Flowlogs, which can be enabled. These give you detailed network layer logging, which you can then scan for trouble.
Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?
3. Scanning – IAM, keys & console
Your existing devs probably have keys to some or all of the EC2 boxes. If you don’t want to relaunch all of these boxes with new keys, or don’t have the luxury to do that, you’ll need to lock down the security groups, whitelisted IPs and VPC routing rules.
You’ll also need to carefully review IAM roles & policies. Amazon Inspector may be a useful tool to scan your environment, and find glaring holes and enforce best practices. But you’ll also want to do your own scanning both automated and manually eyeballing the accounts.
You’ll also want to lock down console access, especially the root account, and any others that have adminstrator privileges. Enable password policies and password rotation, as well as multi-factor authentication. There is also a nice toggle for “alert on login”. You certainly want to know about those!
Related: What mistakes did you make when starting as a consultant?
4. Scanning – services
Review all of the AWS services that are deployed. Ask yourself some of these questions:
o which regions & availability zones am I deployed in?
o what elastic IPs do I have configured where?
o what IAM roles & policies do I have created?
o what databases, API gateways & S3 buckets are configured
o etc…
Cloudtrail can be a great help here as it can log all sorts of useful information. You can then scan those logs for problems.
Related: Why did mailchimp fraudulently charge my credit card?
5. Rebuilding
The scanning approach can work, but there is a strong need to be thorough. If you miss one whitelisted IP or existing ssh key, you can leave the whole network open to a crafty intruder.
Another option is to rebuild the whole application. This gives you the time to:
o automate the whole stack with terraform
o test that everything is working
o plan for failover
o ensure that every bucket is secure with lifecycle policies enabled
o ensure that every EBS volume is encrypted
o enabled cloudtrail, cloudwatch etc
o potentially setup in a *brand new* aws account, for even more confidence
o backup all the pieces of the application as you go
Read: Did Disney+ have to fail?