With surge in globally connected systems and cloud computing, lot of sensitive data is stored and processed which makes it more important than ever for organizations to focus on protecting it from increasingly sophisticated cyber-attacks.
To detect threats and protect infrastructure as well as workloads, one has to deploy additional software and additional infrastructure with appliances, sensors and agents, then set them up across all accounts, then continuously monitor and protect those accounts. It means collecting and analyzing tremendous amount of data. Then accurately detect threats based on data analysis, prioritize, and respond to alerts. And when all this is required at scale, we need to ensure that business functions and environments are not disrupted or impede the flexibility in cloud.
This requires lot of expertise, time and upfront cost. There are some third-party managed tools available like CheckPoint, CloudGuard, Dome9 and Paulo Alto Prisma cloud but they can be costly for small to medium scale environments and require specific skillset to deploy and manage.
AWS GuardDuty is a cloud scale, easier, smarter and cost effective managed intelligent threat detection and notification service to protect AWS environments and workloads.
It is a managed service that constantly monitors AWS environment to find unusual or malicious behavior, filter out noise and prioritize critical findings. Or in other words, helps in finding the needle in haystack so that security team can focus on hardening AWS environment and quickly respond to suspicious or malicious activity or behaviour.
In the context of NIST framework for cloud security, it fits under “detect” as it is AWS’s primary threat detection tool.
Most of the threat detection services focus on network traffic to identify malicious activities however GuardDuty also analyses unusual API calls and potential unauthorized deployments indicating possibly compromised account and instances within AWS to detect anomalies.
AWS GuardDuty analyses output from three primary data sources to detect threats. They are VPC flow logs, DNS logs and AWS CloudTrail and then applies machine learning, anomaly detection and integrated threat intelligence across multiple data sources to identify, prioritize and notify potential threats.
Enabling VPC flow logs for a large environment can be very expensive. The good news is that GuardDuty doesn’t require any of these services to be enabled rather the data and logs required are gathered through an independent channel in backend directly from these services. So as soon as GuardDuty is enabled, a parallel stream of data feeds into GuardDuty backend.
Following are few characteristics of GuardDuty :-
- Simplicity - There is no architectural or performance impact of enabling GuardDuty on existing environment.
- Continuous monitoring of AWS account and resources - Since there is no agent to be installed, as soon as any resource is created in a region protected by GuardDuty it is automatically covered.
- GuardDuty detects known threats like API calls coming from known malicious IP addresses based on threat intelligence from various up to date sources like AWS security intelligence, CrowdStrike and Proofpoint. It also detects unknown threats like unusual data access, mining of crypto-currency based on machine learning and behaviour of users as well as instances.
GuardDuty findings are classified as either stateless, which are independent of server or service state like IP match to a known malicious IP address or stateful which are more of behavioural detections that require state of EC2 instance or IAM user or role to be contained to analyse deviation from usual behaviour.
These findings are segregated into high, medium and low severity levels based on the threat severity value associated with them. This threat severity value defined by AWS reflects the potential risk with each finding. Severity value falls between 0.1 to 8.9 with higher the value greater is the risk. AWS has reserved values 0 and 9 to 10 for future use.
GuardDuty supports master and member account structure. Many member accounts can be associated to a master account enabling enterprise wide consolidation and management. So, in a large environment, hundreds of member accounts can be associated to a master account. While individual teams or account owners can look at the findings within their own account, centralized security team only need to look at master account to get the wholistic view and also, they can create policies applicable across accounts like IP whitelisting and suppression filtering of certain findings as well as prevent individual accounts to apply independent policies. This way the control is in the hands of centralized security team.
Filtering noise: While GuardDuty provides important insights, it is equally important to segregate between genuine and insignificant alerts and prioritize accordingly. Some of the alerts require immediate response, however many of them are worth ignoring as these can be an unnecessary panic and overhead. For example, false positive alarm, but they are very rare. Another example is an alert generated for an activity which is expected, like a vulnerability scanning software deployed for port scaling will result in a “port scanning” finding when it performs scanning. While this alert is genuine, it is an expected activity. Or port scanning from a non-malicious IP on the intentionally opened port of a web server or SSH on the bastion. In such scenarios either not much can be done or if the risk is accepted, the user may want to avoid getting notifications.
The solution is to create automatic filters by creating “suppression rules”. When suppression rule is created the findings are still listed in GuardDuty console but it is not sent to CloudWatch event to avoid any downstream action.
While only master GuardDuty account can create suppression filters, those are automatically applied to all member accounts. This allows centralized security team to control suppression across enterprise and also reduce efforts required in applying them in individual accounts.
Conclusion- GuardDuty service is very quick and easy to deploy. Though it takes only AWS services logs into account but it still generates lots of valuable information to avoid possible attacks and helps in zeroing down to compromised server during cyber forensic activities.
Reference: -
https://aws.amazon.com/guardduty/
https://d1.awsstatic.com/whitepapers/compliance/NIST_Cybersecurity_Framework_CSF.pdf
https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html
https://www.nist.gov/cyberframework/online-learning/five-functions
Top comments (0)