Security is a shared responsibility when you run your business on Amazon Web Services (AWS). To hold up your end of the bargain, there are many best practices at companies should be employing early on (but often don’t) to ensure that they’re maintaining security and that it can scale as the company grows.
During a webinar we presented yesterday with AWS Solution Architect, Scott Ward, and Threat Stack’s VP of Engineering, Chris Gervais, we discussed what these best practices are and how to implement them in AWS.
You can listen to the full webinar recording above. We’ve also prepared the following overview of the key topics covered in the webinar.
Translating the AWS Shared Responsibility Model
Whether you’re already running in AWS or considering how to transition, you should be familiar with the Shared Responsibility Model. This model delineates the role of security as follows:
- AWS is responsible for the security of the cloud (e.g., global infrastructure, storage, databases, networking, compute, etc.)
- You are responsible for security in the cloud (e.g., data, platforms, applications, operating systems, firewalls, etc.)
This model makes the roles quite clear, especially for companies that are new to the nuances of security in the cloud. Many of Threat Stack’s features can make scaling securely easier for you, as we explained in the webinar. Threat Stack automates a broad range of security requirements in one platform, so your team can stay focused only on the pieces that truly require human input and insight, such as building your security strategy, training employees, and responding to threats.
Knowing exactly what you need to do can help you pinpoint where to get started and how that maps to your security strategy. Specifically, there are four best practices all companies should implement in AWS to meet their requirements and maintain a solid security posture.
Best Practices for Implementing & Scaling Security in AWS
1. Utilize Identity and Access Management (IAM)
As you move to the cloud, you quickly realize that the range of roles and permissions is much more complex because you can connect to more things. Scott recommends that companies implement a least privilege access policy whereby users and groups are only given access to data and systems when they absolutely need it to get work done.
As an example, consider your engineers who are on-call. Your on-call rotation schedule lets you know exactly who needs access to what and when, and by leveraging IAM in AWS, you can specify this exact permission schedule. This is a powerful way to enable your team while maintaining security.
By default, AWS accounts come with deny-only permissions, meaning that permissions are only granted when you manually enable them.
2. Encrypt Sensitive Information
AWS always encourages customers to encrypt data, and contrary to popular belief, encryption won’t slow anything down. Enabling encryption in AWS is as simple as checking a box if you choose their native encryption, which provides end-to-end SSL/TLS and HTTPS for AWS Service APIs.
Additionally, you may want to implement scalable key management to create, rotate, define, and audit your encryption keys in one place.
3. Implement API Activity Auditing
As you grow in the cloud and more users are doing more things against your AWS account, you need visibility into API calls to see who did what. It’s best to implement this from the get-go in order to establish a baseline of activity (so you can quickly identify abnormal activity) and instill auditing as a core security function early on.
Scott and Chris recommend starting by creating an ideal instance of an operating system and using this as the “golden image,” or baseline, of an OS. Then, as additional compute resources are created, they can be mimicked to look like the golden one.
Of course, baselines will shift over time as your environment matures and the company grows. Threat Stack can map this baseline to changes and deviations in activity over time, continuously learning what is “normal” for your system at any given point in time. This way, you’ll only be alerted when true threats arise, such as a new vulnerability found in a package, not a routine operation.
AWS CloudTrail gives you many of the basic building blocks of API call auditing; many customers opt to add on Threat Stack’s CloudTrail integration for even deeper insights to get you answers to the who, what, when, where, and why of a security threat faster.
4. Define Your Virtual Public Cloud (VPC)
AWS users should also take the time to define their network infrastructure (their private cloud). Specifically, you will need to:
- Determine what gets in and out of your VPC (inbound and outbound controls)
- Implement network routing (this will differ if you’re running hybrid vs. all-cloud, as it dictates what talks to what in your network)
- Define one or many subnets
- Extend your reach with VPN or Direct Connect
- Implement an IDS/IPS and/or firewall
- Monitor network activity
To monitor network activity, AWS recommends using a third-party cloud security solution like Threat Stack that can provide detailed connection information around the network infrastructure on EC2 so you have deep visibility into exactly what’s going on across your network.
Ensuring Complete Visibility Into Your People, Processes, & Technology
As an AWS customer, you have a lot of options for configuring security. Often these options can be overwhelming, especially to a company just starting off with AWS. Chris and Scott both emphasize the importance of implementing the above security measures as early as possible so you can take full advantage of the speed and scale of the cloud in a secure way.
With a process in place for who can access what and visibility into the resulting activity, you can be sure that, as you grow, security will grow right along with you, not stand as a roadblock to progress.