Customers frequently tell us that they want to be fully secure when they migrate to AWS. As anyone with a good security background would tell you, being "fully secure" is a relative thing. For example, the level of security for our publishing clients is probably not the same level of security for our financial clients. Their risk tolerance related to security have two vastly different profiles.
On one end of the spectrum we have customers that are perfectly happy with the bare minimums delivered at the lowest possible cost and the least management and user burden. We have other customers where security is job #1. Cost is no object to protect their assets. Many of these firms have regulatory requirements that force them to implement various security measures.
In this post I wanted to cover this security spectrum at a high level from security basics to what can be done for the most extreme security conscious firm. We work with our customers to find the most appropriate spot for them on this spectrum.
The Basics
Any AWS account that Blumetech sets up and manages for you will include all the following:
- Strong passwords on all IAM accounts
- Dedicated IAM accounts for roles, e.g. Billing Admin, Read-Only User, etc. We use IAM profiles to enforce the standard "least-privilege" model
- A battle-tested VPC design that we have used successfully for years at dozens of customers
- Secure private dedicated networks for instances that are unreachable from the Internet
- Enable CloudTrail to monitor and log all AWS API calls
- Create an S3 Logging Bucket with an appropriate policy for security and retention to hold all incoming logs
- Use AWS Security Groups to enforce "least-privilege" at the network layer for each instance
Advanced
"The Basics" cover roughly 60% of our customer base. Some customers want to leverage more advanced features that come natively on the AWS platform. For those customers that want additional security controls, we typically recommend a combination of the following additions to "The Basics"
- Lock away root account credentials. Store the credentials in a safe place never to be used except in an emergency. Use IAM accounts instead
- Remove all API access keys to the root account
- Enable Multi-Factor Authentication on IAM accounts. This can be for all IAM accounts or a privileged subset
- Enable Multi-Factor Authentication on AWS Workspaces login
- Enable periodic password rotation on IAM accounts.
- Use IAM Profiles for all application. If not possible, force periodic API access key rotation.
- Enable EBS volume encryption at rest using AWS Key Management Service
- Enable S3 encryption at rest using AWS Key Management Service
- Run periodic vulnerability scans of Internet facing instances
Expert
Rarely we run into customers who need additional security controls. Typically when we get to this level we will require some kind of custom solution tailored to either the customer's own needs or some regulatory requirement, e.g. HIPPA. At this level there aren't any simple "cookie-cutter" solutions. An in depth analysis is required to understand what security features are necessary.
In some cases the discussion moves into whether or not the customer trusts the AWS platform itself. This lack of trust may become apparent in either a lack of trust in AWS security itself, i.e. AWS's own security and compliance procedures, and/or a lack of trust in the platform, e.g. a customer may be concerned that in a multi-tenant environment other AWS customers may be able to access their data.
In these situations we may recommend any of the following security controls :
- Implementing a Security and Compliance 3rd Party, e.g. Evident.IO
- Implement a Bring-Your-Own-Key security model where customers provide their own data encryption keys
- Implement SafeNet to encrypt data at rest for any instances
- Use dedicated hosts to avoid any fear of "cross-talk" between instances from other customers.
- Implement Web Application Firewalls from TrendMicro, AWS, etc.
- Implement Intrusion Detection and Intrusion Prevention Systems (IDS/IPS)
- Build a DevSecOps practice to automatically monitor, alert, and respond to security related events
Comments