Getting Started with AWS GuardDuty with Best Practices.

What is AWS GuardDuty?

AWS GuardDuty, a formidable guardian in the realm of cybersecurity, stands as an indispensable threat detection service within the vast landscape of cloud security. With its vigilant eyes trained on Foundational data sources such as AWS CloudTrail event logs, AWS CloudTrail management events, Amazon VPC Flow Logs, and DNS logs, GuardDuty keeps a watchful gaze over our digital stronghold. But its prowess doesn't end there; GuardDuty possesses the ability to delve even deeper into the intricacies of your digital ecosystem, offering a comprehensive shield for cloud infrastructure. By enabling features such as Kubernetes audit logs, RDS login activity, S3 logs, EBS volumes, Runtime monitoring, and Lambda network activity logs, GuardDuty transforms into an agile sentinel, arming us with the intelligence to defend your digital assets. In this blog, we will explore how GuardDuty harnesses these data sources and features to generate critical security findings for our AWS account, ensuring your fortress remains impenetrable in the face of evolving threats.

AWS GuardDuty is a Regional service which means, we're emphasizing that it functions independently within each AWS region. AWS, as a global cloud computing platform, is distributed across various geographical regions, each hosting its data centers and infrastructure. AWS services, including GuardDuty, are typically confined to specific regions, and they don't inherently share data or settings across different regions.

So, here's the critical implication: if we have AWS resources or assets spread across multiple regions and wish to benefit from GuardDuty's protective capabilities, we must configure GuardDuty separately in each of those regions. In other words, GuardDuty doesn't automatically extend its protective reach across diverse AWS regions. Instead, we must ensure it's actively safeguarding our resources in every region where we have a digital presence.

Best Practice of AWS GuardDuty.

Any user with administrator privileges in an AWS account can enable GuardDuty, however, following the security best practice of least privilege.

- Allow users to view their own permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

- Custom IAM policy to grant read-only access to GuardDuty

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "guardduty:ListMembers",
                "guardduty:GetMembers",
                "guardduty:ListInvitations",
                "guardduty:ListDetectors",
                "guardduty:GetDetector",
                "guardduty:ListFindings",
                "guardduty:GetFindings",
                "guardduty:ListIPSets",
                "guardduty:GetIPSet",
                "guardduty:ListThreatIntelSets",
                "guardduty:GetThreatIntelSet",
                "guardduty:GetMasterAccount",
                "guardduty:GetInvitationsCount",
                "guardduty:GetFindingsStatistics",
                "guardduty:DescribeMalwareScans",
                "guardduty:UpdateMalwareScanSettings",
                "guardduty:GetMalwareScanSettings"
            ],
            "Resource": "*"
        }
    ]
}

- Deny Access to GuardDuty findings

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "guardduty:CreateDetector",
                "guardduty:DeleteDetector",
                "guardduty:UpdateDetector",
                "guardduty:GetDetector",
                "guardduty:ListDetectors",
                "guardduty:CreateIPSet",
                "guardduty:DeleteIPSet",
                "guardduty:UpdateIPSet",
                "guardduty:GetIPSet",
                "guardduty:ListIPSets",
                "guardduty:CreateThreatIntelSet",
                "guardduty:DeleteThreatIntelSet",
                "guardduty:UpdateThreatIntelSet",
                "guardduty:GetThreatIntelSet",                      
                "guardduty:ListThreatIntelSets",
                "guardduty:ArchiveFindings",
                "guardduty:UnarchiveFindings",
                "guardduty:CreateSampleFindings",
                "guardduty:CreateMembers",
                "guardduty:InviteMembers",
                "guardduty:GetMembers",
                "guardduty:DeleteMembers",
                "guardduty:DisassociateMembers",
                "guardduty:StartMonitoringMembers",
                "guardduty:StopMonitoringMembers",
                "guardduty:ListMembers",
                "guardduty:GetMasterAccount",
                "guardduty:DisassociateFromMasterAccount",
                "guardduty:AcceptAdministratorInvitation",
                "guardduty:ListInvitations",
                "guardduty:GetInvitationsCount",
                "guardduty:DeclineInvitations",
                "guardduty:DeleteInvitations"
            ],
            "Resource": "*"
        }, 
         {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "arn:aws:iam::123456789012:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty",
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName": "guardduty.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:PutRolePolicy",
                "iam:DeleteRolePolicy"
            ],
            "Resource": "arn:aws:iam::123456789012:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty"
        }
    ]
}

- Using a custom IAM policy to limit access to GuardDuty resources

We can use all GuardDuty API actions in our custom IAM policies, except the following operations:

• guardduty:CreateDetector
• guardduty:DeclineInvitations
• guardduty:DeleteInvitations
• guardduty:GetInvitationsCount
• guardduty:ListDetectors
• guardduty:ListInvitations

We can use the following operations in an IAM policy to define a user's access to GuardDuty based on the IPSet ID and ThreatIntelSet ID:

guardduty:DeleteIPSet
guardduty:DeleteThreatIntelSet
guardduty:GetIPSet
guardduty:GetThreatIntelSet
guardduty:UpdateIPSet
guardduty:UpdateThreatIntelSet

When we enable GuardDuty for the first time in any AWS Region, it automatically activates all available protection types supported in that Region, including the vital Malware Protection.

This default setting ensures that GuardDuty, our steadfast guardian, starts working on our behalf right from the get-go. It equips you with a comprehensive security shield without the need for manual configuration. Among the suite of protection types, Malware Protection is particularly crucial. It's our first line of defense against malicious software and code that could compromise the integrity of our AWS resources.

In addition to activating these protection types, GuardDuty orchestrates another crucial aspect of its operation. It creates a service-linked role named "AWSServiceRoleForAmazonGuardDuty" within our AWS account. This role is like a specialized tool in GuardDuty's arsenal, designed to carry out specific tasks that are essential for GuardDuty's operation.

AWSServiceRoleForAmazonGuardDuty includes both permissions and trust policies. The permissions allow GuardDuty to consume and analyze events directly from the Foundational data sources, which are the core data streams used to generate security findings. These data sources include AWS CloudTrail event logs, AWS CloudTrail management events, Amazon VPC Flow Logs, and DNS logs. By having access to these foundational data sources, GuardDuty can detect and respond to security threats effectively.

The trust policies establish a relationship of trust between GuardDuty and the AWS account, ensuring that GuardDuty can securely perform its duties. This means that GuardDuty has the necessary permissions to access and analyze the data it needs without compromising the security of your AWS resources.

AWS GuardDuty's Malware Protection emerges as a powerful sentinel against the ever-present threat of malicious software. Malware Protection goes a step further to ensure the integrity of our AWS resources. One of the key mechanisms it employs is the creation of a service-linked role dedicated to its specific functions, aptly named "AWSServiceRoleForAmazonGuardDutyMalwareProtection".

This specialized role is a linchpin in Malware Protection's arsenal, armed with both permissions and trust policies. These elements work in tandem to empower Malware Protection to perform a critical task: agentless scans to detect malware lurking within your GuardDuty account. Agentless scans are a non-intrusive method of inspecting resources for malware without the need to install additional software or agents.

The permissions granted to AWSServiceRoleForAmazonGuardDutyMalwareProtection allow it to conduct these scans effectively. It can inspect various aspects of our AWS resources, seeking out signs of malicious code or files that might compromise your security. This proactive approach ensures that our resources remain untarnished by malware.

Additionally, this service-linked role enables GuardDuty to take another important action - creating an Amazon Elastic Block Store (EBS) volume snapshot in the AWS account. EBS volumes are block storage devices that store data for your EC2 instances, and snapshots capture the state of these volumes at a particular moment. GuardDuty uses this snapshot to preserve a record of the detected malware, providing valuable insights for later analysis and mitigation.

But that's not all. GuardDuty goes a step further by sharing this EBS volume snapshot with the GuardDuty service account. This collaborative approach enhances the security posture, as it allows GuardDuty's central service account to access and analyze the snapshot data. This analysis enables GuardDuty to provide us with actionable security findings, giving you a clear picture of any malware-related threats and facilitating an informed response.

Conclusion

AWS GuardDuty is not just a cybersecurity service; it's our steadfast sentinel in the ever-evolving realm of cloud security. With its unwavering vigilance over Foundational data sources and its ability to unlock the potential of additional features, GuardDuty provides us with the intelligence and capabilities needed to safeguard our digital fortress. As we've discovered, GuardDuty's reach extends to every corner of our AWS environment. However, it's crucial to remember that GuardDuty operates independently in each AWS region, ensuring that our protection remains thorough and comprehensive. To truly fortify our cloud infrastructure, we must configure GuardDuty separately in every region where we have a presence, reinforcing our defenses and ensuring our digital assets are secure. By harnessing the power of GuardDuty and adhering to best practices, we can rest assured that our cloud infrastructure remains impenetrable, fortified against the most cunning of threats. In a world where cybersecurity threats are constantly evolving, AWS GuardDuty stands as our unwavering guardian, protecting our digital assets with precision and diligence.