So far in this series we have looked at a number of foundational services. We have discussed how you can make sure that they are securely configured and generating insights. Having visibility of your AWS resources is one thing. Managing threats to your workloads is another thing all together! Fortunately, AWS has a number of services which should be used to further enhance your security posture for your Cloud environments.
Managing threats
Managing threats can be classified under 3 broad categories – threat detection, threat intelligence and threat hunting. There are some nuances in definitions and definitely some overlap in the categories!
What is threat detection?
Threat detection is the monitoring of various data sources for potential security issues. You should use defensive systems like firewalls and anti-malware tools to automatically stop most of the frequent known threats targeted at your network.
What is threat intelligence?
Put simply, threat intelligence is information you can use to understand the threats that have, will, or are currently targeting your environments. This information is used to prevent and identify threats looking to compromise your Cloud resources.
Threat intelligence supports a pro-active approach to security, ensure defences deal with current threats. It enables an evidence based prioritisation of resources, such as focussing on known weaknesses. This will also include intelligence on the most severe or exploitable vulnerabilities in your environments.
What is threat hunting?
Threat Hunting is actively seeking out and investigating threats rather than relying upon a threat detection system. As malicious actors find new ways to attack and new vulnerabilities are discovered, threat hunting allows you to look for that specific activity (or potential for the activity) in your environments.
If this all sounds important but a lot to take in, fear not! AWS has a number of solutions that we can easily get up and running.
We will look at some of the key ones in this post. Note that many of the services we have already covered in this series, such as AWS Cloudtrail, are excellent tools to help with your threat detection.
Amazon GuardDuty
Category: threat detection
One of the easiest and quickest places to start is with Amazon GuardDuty. Much like AWS CloudTrail, that we discussed in a previous blog, it’s such a simple and powerful tool for managing threats that you will wonder why you didn’t use it earlier!
Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorised access attempts. It uses machine learning, anomaly detection and threat intelligence to identify and prioritise potential threats to your AWS based environments.
Getting started with GuardDuty is as simply as heading to the GuardDuty console and clicking on Get started followed by Enable GuardDuty.
Once GuardDuty is running, go to Settings. Change the Findings export options as follows.
- Findings are automatically sent to CloudWatch Events. Change the frequency to every 15 minutes;
- Setup an S3 bucket to store findings for long term. Use either an existing S3 bucket or create a new one;
- Finally, choose a KMS key for encrypting the logs. Much like CloudTrail logs, we recommend that you use a customer managed key so that logs can be shared between accounts, if required;
- Click on Save.
If you have a multi-account AWS environment under an AWS Organization, we recommend that you setup a GuardDuty master account and consolidate findings to a single account. You will also need to enable GuardDuty in each region of interest.
Once setup you can generate sample findings. Within 15 mins, you will have the findings in your S3 bucket. They will immediately appear under Findings in the console.
GuardDuty will now report on any threats it finds in your environment.
Amazon Macie
Category: threat intelligence
Amazon Macie is a service that can detect potential issues with your S3 bucket configuration. It also uses machine learning to detect sensitive information in your S3 buckets. This is particularly relevant to understand where your sensitive data is stored and who has access.
Like GuardDuty, getting stated is as simple as heading to the Macie console and clicking on Get started followed by Enable Macie. Once enabled, it will scan your bucket configurations and report on buckets that are
- publicly accessible;
- not encrypted;
- shared with external parties.
You can optionally add buckets to scan for sensitive data under Jobs. Note that there can be significant costs in scanning large buckets. Macie pricing is based on the number of buckets and the amount of data scanned. If you add buckets to be scanned, it will provide you an estimate of costs before you enable the new job! Make sure you pay attention before enabling the job!
It’s a little confusing in the way that findings work!
- For bucket configuration, they are send to Amazon EventBridge. From EventBridge, you can define rules to send the findings on to SNS (and to email) or to Lambda to perform an action, for example;
- For sensitive data, findings are also sent to EventBridge. However, Macie can also be configured to send these findings to an S3 bucket (like GuardDuty above).
Finally, Macie supports AWS Organizations. If you have a multi-account setup, delegate a Macie master to consolidate findings. Like GuardDuty, you will also need to enable it in each region of interest.
Amazon Inspector
Category: threat intelligence
Endpoint security should be a key part of a layered security defence for managing theats. Knowing that your EC2 instances are appropriately configured and most importantly patched is critical to a secure workload. After all, a significant proportion of breaches result from old versions of software with known and exploitable vulnerabilities. More on patching in a coming blog!
Amazon Inspector is a service you can use to assess the security of your EC2 instances. It allows you to check for unintended network accessibility to your Amazon EC2 instances and for vulnerabilities in the operating system and software on those instances.
Agentless scanning
Without an Inspector agent, you can run network reachability scanning against your instances. This scans your VPC configuration including Internet access, Security Groups and route tables. It also checks the open ports on your instances. Note that without the agent, Inspector cannot determine if there is a process listening on the port. The network reachability test will report on potential access to your instances and can be used to refine your security groups, firewall rules etc.
To set it Inspector:
- First setup an assessment target group. You can use a tag define the EC2 instances in the assessment group. If you were planning on agent based scans, you can even get Inspector to automatically install the Inspector agent for instances in this group. This assumes the Systems Manager (SSM) agent is already installed. You can click on the Preview button to see what instances will be in the group;
- Next, we create an assessment template. Select the assessment target we just created. Select the Network-Reachability rules package. You can also setup an SNS topic to send details of assessment runs, including the findings. Finally, you can define how often the assessment should run (in days). If you want more control of when your assessments run, you will need to use a Lambda function.
Once you click Create and run, the assessment will run and findings will appear in the console.
Agent based scanning
For agent based scanning, we can test for common vulnerabilities and exposures, CIS Benchmarks for OSs and AWS Security best practice. Of course, we need the Inspector agent installed for this type of scanning.
An agent based scan is setup in the same way as the agentless scanning above. This time, pick one or more of the three rules packages mentioned here. As with the agentless scanning, once you click Create and run, the scanning will start.
Findings
Findings are presented in the Inspector. As above, when setting up the assessment template, you can configure an SNS topic for the findings as well. It’s a noisy services so you will want to store those findings somewhere. We use a Lambda function to push them into our security monitoring and remediation platform. You can also store them in S3 using a Lambda function.
IAM Access Manager
Category: threat intelligence
There’s a handy tool in the IAM console that analyses access to IAM roles or S3 buckets. IAM Access Manager can be used to help in managing threats from external access provided to buckets and roles.
Click on Access Analyzer in the IAM console.
You will find a bunch of findings as Access Analyzer automatically scans your IAM roles and S3 buckets in the account. Like many AWS services, if you are using AWS Organizations, you can delegate a master account for IAM Access Analyzer and setup an organization wide analyzer (like other services, analyzers need to be created in each region where you may have resources).
The findings show all the resources that have been granted access to an external entity. If you click on a finding, it will show you the access that has been provided and the external party. If the access is intentional, you can click on Archive to remove the finding. Otherwise, you may want to remediate the access!
IAM Access Analyzer will also perform policy validation when you create or modify new policies. This includes IAM policies, resource policies and service control policies. In the console, when you create or edit a policy, you will see any identified issues in the bottom bar. It categorises the issues into one of four categories – security, error, general and suggestions.
You can also test a policy before it is deployed using the ValidatePolicy API. This is a great option for managing threats via your deployment pipeline!
Note that in the S3 console you might see the Access Analyzer for S3. It’s actually a different view of the IAM Access Analyzer. One of the neat features though it that you can preview access changes as you modify bucket policies!
What about threat hunting?
We’ve looked at some services for threat detection and intelligence. Threat hunting has traditionally been a manual intensive process. With all the AWS services, there is a vast ocean of security data that can be used to identify potential threats. You’ll need to use modern automated security techniques such as anomaly detection and UEBA (User and Entity Behaviour Analytics) to identify the “non-normal” that traditional approaches to security fail to deal with.
In some ways, tools such as GuardDuty perform some of the elements of threat hunting. Once your organisation has reached a level of maturity in your detect, respond and remediate processes, it may be time to consider threat hunting. Honeypots are a great tool for understanding threat actor behaviour and there is a heap of excellent research data available, such as Rapid7’s Project Sonar.
Of course, there are a number of tools that operate in this space. We use solutions from Sumologic and Rapid7. AWS even has its own tools, Amazon Detective, that is rapidly evolving.
Wrapping up
Threats are real but you don’t need to lie awake at night worrying about what might happen. On top of the rich visibility provided by AWS services, there are a number of AWS services that will tell you about threats and vulnerabilities in your AWS configuration.
If you want to understand more about managing threats in your AWS environment, please get in contact with us at RedBear.
