Securing your cloud assets can be a minefield of different tools, methods and applications and ensuring you have covered all the bases can prove to be an elusive aim. However, all the major public cloud providers have created baseline security centres tailored to their infrastructure. These provide a continuous security monitoring service to analyse and process events and incidents within your cloud estate and alert you where appropriate.
This is the first in a series of articles where we look at each of the tools in some detail for AWS, Azure and Google and give you some detail about how to leverage the most out of them.
AWS Guard Duty What is it? – It sits at the top level of your account collating logs from various sources like CloudTrail events, VPC flow logs and DNS logs from your environment. It also brings in feeds from other sources like blacklists of malicious IPs, domains, port scans and other threat intelligence. It then uses a wide array of machine learning routines to identify unexpected and potentially unauthorized and malicious activity within your AWS environment. At the VPC level, there are a wide range of events that it looks for including exposed credentials, unusual connection patterns to remote or incoming ports, privilege escalation and communication with unexpected or known malicious IPs, domains and URLs, unusual network flow patterns and traffic.
AWS account usage is also monitored for unusual behaviour including API calls that may compromise security. Examples include removing MFA as a requirement or implementing a password policy change that reduces password strength. Snapshotting a database, DNS changes or disabling CloudTrail events are other examples that would be flagged.
Infrastructure changes are also monitored for like deploying new instances in a different region to hide them from the default region GUI screen. A classic use case of something like this would be to deploy hidden instances to serve malware or as part of a command and control network for a DDOS attack or even mining cryptocurrency. These events are all monitored in real-time to give you a 24/7 Security Operations Centre (SOC) base to build the human level of knowledge. The alerts appear in CloudWatch and in the GuardDuty console. You can then match this with something like AWS SNS and AWS Lambda procedures to tie in with your ticketing or alerting system.
It’s relatively cheap and like all AWS managed services, you only pay for what you use. It’s priced based on the number of events and the size of the VPC and DNS logs, so the busier the infrastructure the more it costs but then if your infrastructure is busy then your site is doing well. Because it’s an AWS managed service it also scales itself under the hood.
The three main tenets of a SOC are to detect reconnaissance or active attack of your network, to detect virtual machine compromise and to find account level IAM compromise or attempts. It does all these very well using machine learning and incoming data feeds. Overall it removes the heavy lifting required to build out an in house SOC while retaining the human element of control. Best Practices with AWS GuardDuty Enable it in all regions.
For global services such as AWS IAM (our blog discusses best practice IAM here), AWS STS, Amazon CloudFront, and Route 53, events are delivered to any CloudTrail that includes global services and are logged as occurring in US East (N. Virginia) Region. Additionally, deployments into other regions can be caught this way. Enable CloudTrail. GuardDuty is heavily tied to CloudTrail – See the blog on CloudTrail. CloudTrail logs and records management events and data events, currently only management events are fully analysed.
The best news is that CloudTrail is free. Upload custom whitelists and threat lists. As a human, you get used to filtering out known false positives because you know your environment and how it communicates with the outside world. By uploading custom lists to GuardDuty you can whitelist the expected connections for your environment, See upload lists in GuardDuty. Restrict access to GuardDuty. Only enable GuardDuty access to those individuals who need it, there are some AWS managed CloudDuty policies that can be applied to give everything from full admin to read only. Understand the AWS GuardDuty severity levels. A “Low” severity level indicates suspicious or malicious events that were detected and blocked before it could compromise your infrastructure. A “Medium” severity level indicates suspicious activity that deviates from normal behaviour and should be looked at further. A “High” level means a resource has been compromised and is being used for unauthorized purposes.
Make sure you’re watching the watcher to find out if it’s ever disabled or changed. Even with only trusted users accessing it, suspending GuardDuty or worse disabling it (all of your historical data and settings are lost when its disabled) should be immediately notified to key people via an instant alerting system. Conclusion AWS GuardDuty is a very useful tool in the armoury of a Cloud Security Operations Centre (SOC).
It’s a great base to build from for AWS deployments and as they expand the offering of what it analyses and also the threat intelligence feeds, your environment can only benefit from the added protection. More details on the terminology and concepts can be found here Next up is Azure Security Centre – due mid-July If you’d like to find out more about the right security tools to keep your business secured online, then call us today and speak to one of our craftsmen.
We are ISO 27001 accredited and Cyber Essentials Plus verified which means we deliver security with trust for businesses.
