Security is one pillar of building in the cloud, not the only one
Building in the cloud isn’t just about making something work. Yes, that’s step one but actually solving the business problem is only one concern among several. Your solution needs to be reliable, operable, and deliver consistent results safely. This can be a difficult balance to strike.
AWS has documented these concerns under the AWS Well-Architected Framework. This framework illustrates the principles required to build resilient solutions in the AWS Cloud.
Balance through smart trade offs
The framework centers around six pillars. These pillars are the primary areas of concern when building and running a solution. They are;
In an ideal world, you’d be able to build a solution that’s effortless to operate, extremely reliable, highly performant, very low cost, secure, and sustainable. If you’ve been in technology for longer than a day, you know that’s simply not possible.
The framework is the tool you need to not only understand these concerns but to make informed decisions in order to align your solution with your business needs.
Security in context
The AWS Well-Architected Framework is a great reminder that security is just one of several concerns. The question now becomes, how can we maximize the effectiveness of our security work while leaving time and resources to address the other pillars?
The deceptively short answer is, “Automation.”
But to get to the automation step, you need to follow the simple path of visibility, insights, and action. Gaining visibility into what your teams are doing in your AWS environment is critical to understanding where to prioritize your security efforts.
Visibility in AWS starts with AWS CloudTrail. This core AWS service logs nearly every interaction with your accounts. It’s on by default in every region and can be configured for multiple accounts with AWS Organizations.
CloudTrail provides some rudimentary search functionality but also logs the events to an Amazon S3 bucket for further analysis. You can do some basic analysis yourself using Amazon QuickSight or more advanced analysis with third party tools.
Editors note: For third party analysis, might we suggest the Polygraph Data Platform from Lacework? ????.
Insights drive action via automation
We’ve discussed before how important it is to use the visibility you’ve gained to derive insights and then drive actions in response to issues that pop up.
What that means in practical terms is using automated triggers based on specific events or insights.
In the AWS Cloud, this typically happens through Amazon EventBridge triggering an AWS Lambda function in response to an incoming event. This pattern is extremely powerful and very simple to set up. Let’s walk through an example to see the power of this pattern.
CloudTrail events line up with actions taken in the AWS Cloud. We want to ensure that when a new user is created in an account, we have a little safety check in place to make sure we know who it is.
The action we’re looking for is CreateUser. Anytime this action is taken, we want to trigger this pattern. So we create a rule in Amazon EventBridge as follows;
“detail-type”: [“AWS API Call via CloudTrail”],
This will trigger anytime anyone calls the CreateUser action in the Identity and Access Management service. We then tell EventBridge to trigger a customer AWS Lambda function.
This function receives the event and would send it along to a tool like Slack where we’ll inform the rest of the team.
Our action start to finish
With a few simple steps, we’ve managed to connect visibility to insights to drive an action.
We gained visibility through the use of AWS CloudTrail events. We’ve manually searched that data (once!) in order to act on an insight (a new user being created) and drive an action as a result of that insight (alert the team).
As our security practice grows, we’re going to need more robust tools to pull insights from CloudTrail and over visibility data sources. This pattern however, remains.
This pattern helps keep the operational impact of security low. After identifying an area of concern (the creation of a new user), this automation helps monitor the situation.
This is the type of security win that you need to build out a successful cloud practice. It allows you to add more value to the security pillar of the AWS Well-Architected Framework without compromising other areas.
You’re able to reduce the cost of security by following the path of visibility, insights, actions path.
The pattern discussed here is one of many simple, scalable security automation that you can implement with minimal overhead.
You’re constantly iterating when you’re building in the cloud. On each change, you need to evaluate the balance of the six pillars in the AWS Well-Architected Framework. Did that performance improvement come with more operational overhead? Maybe that extra redundancy increased your costs.
None of these are bad as long as you’ve made an explicit decision to make that tradeoff. That’s where the Framework really shines.
For more on the security big picture, check out the first post in this series, “Focus on your business, not IT for ITs sake” and our ebook aimed at helping you improve your security practice, “ Simplify AWS security for small businesses.