This is the second post in the series “Where do I start with AWS?”. In this blog post, we will turn our focus on securing our data.
So, we have previously discussed best practises in regards to setting up and governing a new, secure multi-account AWS environment and a framework that is being used to deliver our Infrastructure-as-Code (IaC), as well as application code.
If you haven’t read this blogpost, you can find it here: Where do I start with AWS?
It’s now time to take care of securing our state of the art infrastructure and how we can start automating security incidents that might occur.
Blog post agenda:
- Fundamentals of security in your AWS environment
- Where to start with security practice?
- Introduction to AWS Security Hub
- How to start with AWS Security Hub
Fundamentals of security in your AWS environment
Amazon Web Services has a concept they call the Shared Responsibility Model. In this model the responsibility is, as the name implies, a responsibility between you – the customer, the consumer of the services and AWS themselves, the provider of the services.
Below picture describes the Shared Responsibility Model.
As the picture implies, you can say that “You are responsible for what is running ON the cloud. AWS is responsible for running the cloud.”
Let’s take an example related to configuration management stated on the compliance page related to the Shared Responsibility Model at AWS.
“Configuration Management: AWS maintains the configuration of its infrastructure devices, but businesses are responsible for configuring their own guest operating systems, databases, and applications.”
Source: aws.amazon.com
Above example is somewhat related to AWS IaaS services. AWS does however have a lot of other services, services which you don’t have to manage other than providing your code and some minor configuration related to that.
A service like that is AWS Lambda. The AWS Shared Responsibility Model for Lambda sees another level of layer peeled away. Instead of having to manage, maintain and run a EC2 Instance to run their code, or having to track software dependencies in a user-managed container, Lambda allows organizations to upload their code and let AWS figure out how to run it at scale.
Below is a picture of the AWS Shared Responsibility Model for Lambda.
To learn more about the Shared Responsibility Model, please visit the official compliance page at AWS: Shared Responsibility Model.
Where to start with security practice?
Now that we have learned about what we have to take in consideration and what we are responsible for when running workloads in AWS, it is time to actually start with our security practice.
Setting up a baseline
When setting up a baseline for your security practice it is important to first identify which data is important for your business. Classifying data does not only enable you to understand, categorize, label and protect data today, but also in the future when preparing new data structures, regulations and compliance frameworks etc. that might come in your way. Without proper classification, no proper protection.
Get to know what your organization’s “Sacred data”, i.e. the crown jewel data that is of greatest value to your business and would cause the most damage if compromised. Every organization has different needs, and will therefore also have different sacred data. This data will need the most restrictive controls applied to it and should be protected at all cost.
Organizations should create classification categories that make sense for its needs, basically classifying data for what it is worth.
A common method being used is a green, yellow and red color model. As you might think, the color-coded scale depends on the data value and the importance of it.
An example of this could be:
Green data: Likely related to data that is publicly available or confidential company records, not something that would impact a stock price for example but would be a minor reputation hit.
Yellow data: Would be something that is very concerning for your business, sensitive customer data leakage for example.
Red data: Big news event, extreme fines and loss of customer trust, something that might take your business to bankruptcy.
Next steps would be to secure your data according to its classification. When you are aware of the importance levels of your data, you can work backwards to employ security controls that are aligned with its criticality. In this way you can minimize the probability of breaches happening and ask appropriate questions related to your data.
Examples of those questions could be:
- What systems is processing red data?
- Does this data need encryption in-transit and at-rest?
- Who has access to encryption keys?
- Are there systems that inappropriately move red data over to systems with fewer security controls, such as systems built for green or yellow data?
- Are you working with least privilege access to your data?
Data classification is a start with the goal of reaching compliance, but there are other things to take in consideration as well. Security is also a people process and needs ongoing collaborative dialog in your organization. You need to grow security awareness within your Operations and Cloud Development teams as a solid understanding and awareness of the implications of running software in the cloud is crucial. If you have a base set of guardrails it becomes important to train your developers to take the responsibility themselves. This could be considered as a “Trust but verify” approach, where you have baseline guardrails in place, but you also provide reviews to the teams to ensure they are compliant with the expectations. This can be a tough thing, and it’s important to work together with teams and be there to support them in succeeding, rather than to be a control mechanism that prevents progress (this is what you are, but it’s all in the attitude towards your coworkers).
Before continuing I would like to say that there are tons of security solutions that can accomplish the same tasks out there, and you might already have one in place that cover some of your needs. I will in this blogpost go through a AWS-based alternative related to security, which is a cost efficient alternative to other more license-heavy solutions out there.
Introduction to AWS Security Hub
At the General Availability announcement of AWS Security Hub, Dan Plastina, Vice President for External Security Services at AWS stated:
“AWS Security Hub is the glue that connects what AWS and our security partners do to help customers manage and reduce risk,” said Dan Plastina, Vice President for External Security Services at AWS. “By combining automated compliance checks, the aggregation of findings from more than 30 different AWS and partner sources, and partner-enabled response and remediation workflows, AWS Security Hub gives customers a simple way to unify management of their security and compliance.”
What is Dan Plastina really talking about here?
AWS Security Hub gives you a broad view of your security alerts and security aspect across your AWS accounts. Powerful security tools such as firewalls and endpoint protection to vulnerability and compliance scanners are all available in this single service which makes this a quite powerful one.
Security Hub is this neat single place that aggregates, organizes and prioritizes your security alerts and findings from AWS services such as Amazon GuardDuty, Amazon Inspector, Amazon Macie, AWS Identity and Access Management (IAM) Access Analyzer, AWS Firewall Manager and other AWS Partner solutions.
AWS Security Hub continuously monitors your environment using automated security checks based on the AWS best practices and industry standards that your organization follows.
You can also take action by using other AWS services such as Amazon Detective or sending findings to your own ticketing system/chat of choice using CloudWatch Event rules. If you are using your own incident management tools, Security Information and Event Management (SIEM) or Security Orchestration Automation and Response (SOAR) it is possible to act on Security Hub findings in these systems as well.
You do also have the ability to develop your own custom remediation actions called playbooks that act on events you define. AWS have released a solution for developing playbooks that remediates security events related to security standards defined as part of the CIS AWS Foundations Benchmark.
The solution is also all serverless, no servers to manage, which means more time for fika or other useful things 😉
You can find this solution at below link:
AWS Security Hub Automated Response and Remediation
I want AWS Security Hub! How and where do I deploy it?
Alright alright, easy now.. We do first need an AWS account suitable for this kind of service, it is after all a critical component and something you only want the Security Team or other people in similar roles to see.
The account that acts as the Security Hub master should be an account that is responsible for security tools. The same account should also be the aggregator account for AWS Config.
It is also important to note that after you have enabled Security Hub in your account that is acting as the Security Hub master, you would also need to enable Security Hub in the other member accounts and then, from the Security Hub that is acting the master, invite the other member accounts. You will then be able to see all security findings related to your accounts in one place i.e. the Security Hub master account.
There is also a script available for deploying security hub in an multi-account environment at below link:
AWS Security Hub Multiaccount Scripts
For those who are using Control Tower, the Security Hub master account would be the shared account named Audit.
There is also an version of above multi-account script that is modified to work with Control Tower that you can find at below link:
AWS Control Tower Security Hub Enabler
Conclusion
In essence Security Hub is a SIEM aggregator, with remediation tips thrown in too. You can make use of a lot of mature AWS services such as CloudWatch and Lambda etc. which makes it very flexible. It can help you understand activity happening in your AWS environment and take appropriate action on this, as well as understand and monitor critical components of your environment.
When integrated with other services such as Amazon GuardDuty, Amazon Macie and Amazon Detective you will have a great toolset to put you in great advantage in terms of your security posture.
Security Hub has a very competitive pricing model and is beneficial for companies looking to get further insight in their AWS workloads.
Security Hub does also have integrations with a lot of third-party providers and is like many other AWS services, developed in an impressive phase as new features are added regularly.
Below is an monthly pricing example of an organization that uses 2 regions and 20 accounts, a quite large organization in other words.
500 security checks per account/region/month
10,000 finding ingestion events per account/region/month
Monthly charges = 500 * $0.0010 * 2 * 20 (first 100,000 checks/account/region/month)
+ 10,000 * $0 * 2 * 20 (first 10,000 events/account/region/month)
= $20 per month
Besides pricing, Security Hub is simple to use and provides several frameworks ready for use out-of-the-box. Security Hub is getting traction among larger respected players such as Splunk, Rackspace, GoDaddy for these reasons and is by no doubt a great service.
Security should be one of the top priorities among organizations but that is not usually the case. When investing in security solutions one organization should first estimate how much a security breach will cost them and which implications it might have and then use this information to set aside a budget dedicated to this field. Classify your data and think about how this data is being processed or used in-transit and at-rest, this can lead to great insights and should not be underestimated.
You will probably have a hard time finding a solution that provides more bang for the buck than Security Hub in regards to securing your AWS resources.
If you have any questions or just want to get in contact with me or any of my colleagues, I’m reachable on any of the following channels.
Mail: christoffer.pozeus@tiqqe.com
LinkedIn: Christoffer Pozeus
