[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"next-aws-certified-cloudops-engineer-associate-security-and-compliance-data-protection-secrets-management-en":4,"prev-aws-certified-cloudops-engineer-associate-security-and-compliance-data-protection-secrets-management-en":1048,"lesson-aws-certified-cloudops-engineer-associate-security-and-compliance-data-protection-secrets-management-en":1060},null,{"locked":5,"reason":3,"meta":6,"item":19},false,{"title":7,"description":8,"isFree":9,"estimatedMinutes":10,"difficulty":11,"learningObjectives":12},"Amazon GuardDuty and Amazon Inspector","The two detection services answer different questions: GuardDuty watches behavior in your logs to find attacks in progress, and Inspector scans your workloads to find the weaknesses an attacker would use. This lesson covers what each one sees, how to read their findings, and how suppression differs between them.",true,26,"intermediate",[13,14,15,16,17,18],"Distinguish GuardDuty threat detection from Inspector vulnerability management by the question each service answers","Identify the 3 GuardDuty foundational data sources and explain why none of them require you to enable logging first","Decode a GuardDuty finding type from its name and map a severity value to its level","Compare GuardDuty suppression rules with Inspector suppression rules and predict what each does to downstream delivery","Choose between Inspector agent-based and agentless scanning for a given instance","Configure both services across an organization, accounting for their Regional and delegated administrator rules",{"id":20,"title":7,"body":21,"description":8,"difficulty":11,"estimatedMinutes":10,"extension":943,"infographics":944,"isFree":9,"learningObjectives":958,"meta":959,"navigation":9,"path":960,"quiz":961,"seo":1045,"stem":1046,"__hash__":1047},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/04-threat-detection-and-response/01-guardduty-and-inspector.md",{"type":22,"value":23,"toc":929},"minimark",[24,28,31,36,39,127,130,134,137,173,176,183,186,190,201,279,286,293,308,319,323,326,336,351,356,359,377,441,444,505,508,512,523,538,544,567,570,574,580,583,633,640,647,650,654,657,675,706,712,715,722,733,737,740,822,829,833,836,866,876,880,926],[25,26,27],"p",{},"At 03:00 an EC2 instance in your production account opens a connection to an IP address in a country where you run nothing. Nobody deployed anything. Separately, that same instance has been running a version of a system library with a published CVE for 5 weeks.",[25,29,30],{},"Two facts about one instance, and 2 different questions. The first is \"is something bad happening right now?\" The second is \"what could an attacker use if they got in?\" AWS answers them with 2 different services, and the exam spends most of its detection questions on which service answers which question. Skill 4.2.5 asks you to configure reports and remediate findings from AWS Security Hub, Amazon GuardDuty, AWS Config, Amazon Inspector, and AWS Security Agent. This lesson takes the first 2 detectors in that list.",[32,33,35],"h2",{"id":34},"behavior-versus-state","Behavior versus state",[25,37,38],{},"The cleanest way to hold these apart is that GuardDuty reads activity and Inspector reads inventory.",[40,41,42,57],"table",{},[43,44,45],"thead",{},[46,47,48,51,54],"tr",{},[49,50],"th",{},[49,52,53],{},"Amazon GuardDuty",[49,55,56],{},"Amazon Inspector",[58,59,60,72,83,94,105,116],"tbody",{},[46,61,62,66,69],{},[63,64,65],"td",{},"Question answered",[63,67,68],{},"Is someone attacking or already inside?",[63,70,71],{},"What is exploitable if they get in?",[46,73,74,77,80],{},[63,75,76],{},"Input",[63,78,79],{},"CloudTrail management events, VPC flow logs, DNS query logs, plus optional log sources",[63,81,82],{},"Software inventory on EC2, ECR container images, Lambda functions, source code",[46,84,85,88,91],{},[63,86,87],{},"Detection basis",[63,89,90],{},"Threat intelligence feeds, machine learning, anomaly baselines",[63,92,93],{},"CVE databases, network path analysis, code analysis",[46,95,96,99,102],{},[63,97,98],{},"Nature of a finding",[63,100,101],{},"An event that happened",[63,103,104],{},"A condition that exists",[46,106,107,110,113],{},[63,108,109],{},"When it clears",[63,111,112],{},"You archive it or it ages out at 90 days",[63,114,115],{},"Inspector detects the remediation and closes it automatically",[46,117,118,121,124],{},[63,119,120],{},"Typical response",[63,122,123],{},"Contain the resource, rotate credentials, investigate",[63,125,126],{},"Patch, rebuild the image, redeploy",[25,128,129],{},"That last row is the practical difference. A GuardDuty finding is a report about the past that never fixes itself; an Inspector finding is a description of the present that disappears when you patch. Keep that in mind when a question describes a finding \"that closed on its own\" or one \"that stayed open after the instance was terminated\".",[32,131,133],{"id":132},"guardduty-reads-logs-you-never-had-to-turn-on","GuardDuty reads logs you never had to turn on",[25,135,136],{},"Enable GuardDuty in a Region and it immediately starts consuming 3 foundational data sources:",[138,139,140,161,167],"ul",{},[141,142,143,147,148,152,153,156,157,160],"li",{},[144,145,146],"strong",{},"AWS CloudTrail management events",", the control plane calls such as ",[149,150,151],"code",{},"AttachRolePolicy",", ",[149,154,155],{},"CreateSubnet",", and ",[149,158,159],{},"CreateTrail",".",[141,162,163,166],{},[144,164,165],{},"VPC Flow Logs"," from the EC2 instances in the account.",[141,168,169,172],{},[144,170,171],{},"Route 53 Resolver DNS query logs",", the name lookups your instances perform.",[25,174,175],{},"Here is where a predictable misconception starts. It is tempting to assume you must create a CloudTrail trail and enable VPC flow logs first, the way you would for most log-consuming services. You do not. GuardDuty consumes each of these through an independent, duplicated stream. Your CloudTrail configuration does not affect what GuardDuty sees, and GuardDuty does not affect your CloudTrail configuration. Disabling flow logs on a VPC does not blind GuardDuty. There is also no extra charge for the log access itself; you pay GuardDuty's own pricing after the 30-day free trial.",[25,177,178,179,182],{},"The DNS source carries the one real dependency, and it is a favorite exam detail. GuardDuty reads DNS queries through the internal AWS DNS resolvers. If your instances use the AWS-provided resolver, which is the default, GuardDuty sees the queries. If you point them at OpenDNS, Google DNS, or a resolver you run yourself, ",[144,180,181],{},"GuardDuty cannot access that data at all",", and every DNS-based finding type goes quiet. Enabling Route 53 Resolver query logging does not fix it, because GuardDuty uses a separate stream rather than that feature.",[25,184,185],{},"One more behavior worth knowing before you decide which Regions to enable. Global service events, from IAM, AWS STS, S3, CloudFront, and Route 53, are recorded by CloudTrail in one Region but matter everywhere. GuardDuty replicates those events and processes them in every Region where you have it enabled, which is how it keeps a user and role profile per Region. That is the argument for turning GuardDuty on even in Regions where you deploy nothing: an attacker who creates resources in an unused Region is exactly the case those profiles catch.",[32,187,189],{"id":188},"protection-plans-widen-the-surface","Protection plans widen the surface",[25,191,192,193,196,197,200],{},"The 3 foundational sources are the baseline. Everything else GuardDuty can watch comes from an optional ",[144,194,195],{},"protection plan",", which the API calls a ",[144,198,199],{},"feature",". Each one adds a log or event source:",[40,202,203,213],{},[43,204,205],{},[46,206,207,210],{},[49,208,209],{},"Protection plan",[49,211,212],{},"What it adds",[58,214,215,223,231,239,247,255,263,271],{},[46,216,217,220],{},[63,218,219],{},"S3 Protection",[63,221,222],{},"S3 data events from CloudTrail",[46,224,225,228],{},[63,226,227],{},"EKS Protection",[63,229,230],{},"EKS audit logs",[46,232,233,236],{},[63,234,235],{},"Runtime Monitoring",[63,237,238],{},"OS-level, network, and file events from a security agent on EKS, ECS on Fargate, and EC2",[46,240,241,244],{},[63,242,243],{},"Malware Protection for EC2",[63,245,246],{},"Scans of EBS volumes attached to EC2 instances and container workloads",[46,248,249,252],{},[63,250,251],{},"Malware Protection for S3",[63,253,254],{},"Scans of newly uploaded S3 objects",[46,256,257,260],{},[63,258,259],{},"RDS Protection",[63,261,262],{},"Login activity on supported Aurora and RDS engine versions",[46,264,265,268],{},[63,266,267],{},"Lambda Protection",[63,269,270],{},"Lambda network activity logs",[46,272,273,276],{},[63,274,275],{},"AI Protection",[63,277,278],{},"CloudTrail data events from Amazon Bedrock, Bedrock AgentCore, and SageMaker AI",[25,280,281,282,285],{},"Two details about how these switch on. When you enable GuardDuty for the first time, all protection plans ",[144,283,284],{},"except Runtime Monitoring"," are enabled automatically and included in the 30-day free trial. If you were already a GuardDuty customer when a plan launched, that plan is not enabled automatically and you have to opt in, which is why long-lived accounts often have coverage gaps that new accounts do not.",[25,287,288,289,292],{},"Malware Protection for S3 is the one exception to the whole model: you can use it on its own ",[144,290,291],{},"without enabling the GuardDuty service at all",". Every other protection plan requires GuardDuty.",[25,294,295,296,299,300,303,304,307],{},"Malware Protection for EC2 comes in 2 flavors that scenario questions like to separate. A ",[144,297,298],{},"GuardDuty-initiated malware scan"," fires automatically when a finding suggests malware on an instance, runs at most once every 24 hours per resource, and has its own 30-day free trial. An ",[144,301,302],{},"on-demand malware scan"," is one you start yourself with an instance ARN, requires no feature-level configuration beyond GuardDuty being enabled, can be repeated on the same resource 1 hour after the previous scan started, and has no free trial. Both honor the global ",[149,305,306],{},"GuardDutyExcluded"," tag. Snapshots of the scanned volumes are retained only when malware is found, and only if you configured retention.",[25,309,310,311,314,315,318],{},"Sitting above all of this is ",[144,312,313],{},"Extended Threat Detection",". It correlates events across data sources, resource types, and time inside one account to spot multi-stage attacks, then writes an ",[144,316,317],{},"attack sequence"," finding. It costs nothing extra, needs no protection plan, and is enabled automatically with GuardDuty. It is also the reason attack sequence findings land in the Critical band while individual signals sit lower: each event alone looked survivable, and the sequence did not.",[32,320,322],{"id":321},"reading-a-finding-type-without-opening-the-finding","Reading a finding type without opening the finding",[25,324,325],{},"GuardDuty names every finding type with the same grammar:",[327,328,333],"pre",{"className":329,"code":331,"language":332},[330],"language-text","ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact\n","text",[149,334,331],{"__ignoreMap":335},"",[25,337,338,339,342,343,346,347,350],{},"Walk one real type through it. ",[149,340,341],{},"CryptoCurrency:EC2/BitcoinTool.B!DNS"," says: the adversary's purpose is cryptocurrency activity, the affected resource type is an EC2 instance, the family of activity is a known Bitcoin tool, ",[149,344,345],{},".B"," is the detected variant, and ",[149,348,349],{},"!DNS"," names the artifact, meaning the instance was talking to a known Bitcoin-related domain.",[352,353],"infographic",{"alt":354,"slug":355},"A breakdown of the GuardDuty finding type CryptoCurrency:EC2/BitcoinTool.B!DNS showing what each segment of the name means.","guardduty-finding-type-anatomy",[25,357,358],{},"Two values in the DetectionMechanism position carry extra meaning:",[138,360,361,369],{},[141,362,363,368],{},[144,364,365],{},[149,366,367],{},".Custom"," means the match came from a threat list you uploaded, not from AWS threat intelligence.",[141,370,371,376],{},[144,372,373],{},[149,374,375],{},".Reputation"," means a domain reputation score model produced the match.",[25,378,379,380,152,383,152,386,152,389,152,392,152,395,152,398,152,401,152,404,152,407,152,410,152,413,152,416,152,419,152,422,152,425,152,428,156,431,434,435,437,438,440],{},"The ThreatPurpose values are worth skimming once because several map directly onto MITRE ATT&CK tactics: ",[149,381,382],{},"Backdoor",[149,384,385],{},"Behavior",[149,387,388],{},"CredentialAccess",[149,390,391],{},"Cryptocurrency",[149,393,394],{},"DefenseEvasion",[149,396,397],{},"Discovery",[149,399,400],{},"Execution",[149,402,403],{},"Exfiltration",[149,405,406],{},"Impact",[149,408,409],{},"InitialAccess",[149,411,412],{},"Pentest",[149,414,415],{},"Persistence",[149,417,418],{},"Policy",[149,420,421],{},"PrivilegeEscalation",[149,423,424],{},"Recon",[149,426,427],{},"Stealth",[149,429,430],{},"Trojan",[149,432,433],{},"UnauthorizedAccess",". You do not need to memorize the list, but you should recognize that ",[149,436,418],{}," means a best-practice violation rather than an attack, and that ",[149,439,412],{}," means the activity looks like known penetration testing tools, which GuardDuty cannot tell apart from an actual adversary using the same freely available tools.",[25,442,443],{},"Severity is a number from 1.0 to 10.0, split into 4 bands:",[40,445,446,459],{},[43,447,448],{},[46,449,450,453,456],{},[49,451,452],{},"Level",[49,454,455],{},"Value range",[49,457,458],{},"What it means",[58,460,461,472,483,494],{},[46,462,463,466,469],{},[63,464,465],{},"Critical",[63,467,468],{},"9.0 to 10.0",[63,470,471],{},"An attack sequence may be in progress or recently happened across one or more resources",[46,473,474,477,480],{},[63,475,476],{},"High",[63,478,479],{},"7.0 to 8.9",[63,481,482],{},"The resource is compromised and actively being used for unauthorized purposes",[46,484,485,488,491],{},[63,486,487],{},"Medium",[63,489,490],{},"4.0 to 6.9",[63,492,493],{},"Suspicious behavior that deviates from the baseline and may indicate compromise",[46,495,496,499,502],{},[63,497,498],{},"Low",[63,500,501],{},"1.0 to 3.9",[63,503,504],{},"Attempted activity that did not compromise anything, such as a port scan",[25,506,507],{},"Scenario questions usually hand you the number, not the label, so the boundary values are the part to hold.",[32,509,511],{"id":510},"aggregation-archiving-and-the-delay-that-surprises-people","Aggregation, archiving, and the delay that surprises people",[25,513,514,515,518,519,522],{},"GuardDuty does not create a new finding for every packet. When it detects new activity tied to the same security issue, it ",[144,516,517],{},"updates the original finding"," and increments the ",[149,520,521],{},"Count",", replacing the details with the most recent occurrence. Repeated SSH brute force attempts against one instance stay a single finding; the same attack against a second instance creates a second finding with its own ID, because that is a distinct security issue with a distinct resource.",[25,524,525,526,529,530,533,534,537],{},"That aggregation has a delivery consequence. New active findings reach EventBridge within about ",[144,527,528],{},"5 minutes",". Updates to existing findings follow a separate setting, ",[144,531,532],{},"Frequency for updated findings",", which defaults to ",[144,535,536],{},"every 6 hours"," and can be set to 15 minutes or 1 hour. So an ongoing attack, which arrives as updates rather than new findings, can sit for hours before your remediation Lambda hears about it. If a question describes automation that \"fired late\" on a continuing incident, this setting is the answer.",[25,539,540,543],{},[144,541,542],{},"Suppression rules"," are how you cut noise. A rule is filter criteria plus a value, and new findings matching it are automatically archived. Three properties matter:",[545,546,547,554,561],"ol",{},[141,548,549,550,553],{},"Suppressed findings are ",[144,551,552],{},"not sent to Security Hub CSPM, Amazon S3, Amazon Detective, or EventBridge",", and they do not trigger Malware Protection for EC2 scans. This is the point: it silences the SIEM, not just the console.",[141,555,556,557,560],{},"The findings are still generated and stored in GuardDuty for ",[144,558,559],{},"90 days",", viewable by filtering on Archived.",[141,562,563,564,160],{},"In a multi-account setup, ",[144,565,566],{},"only the GuardDuty administrator can create suppression rules",[25,568,569],{},"There is a cost to suppressing broadly that is easy to miss. Archived findings are not used as signals when Extended Threat Detection correlates events into attack sequences. Suppress every EKS cluster finding and you have also removed GuardDuty's ability to notice a chain where an attacker exploits a container, grabs a privileged token, and reaches sensitive resources. AWS's own guidance is to build suppression rules reactively, for specific behaviors you have repeatedly confirmed as false positives, never as a blanket filter.",[32,571,573],{"id":572},"inspector-scans-what-you-deployed","Inspector scans what you deployed",[25,575,576,577,160],{},"Amazon Inspector discovers workloads on its own and scans them continuously. There is no assessment to schedule and no scan window to plan. When a resource changes, when you install a package, or when a new CVE relevant to that resource is published, Inspector rescans. When you fix the problem, it detects the remediation and ",[144,578,579],{},"closes the finding for you",[25,581,582],{},"It produces 3 finding types:",[40,584,585,598],{},[43,586,587],{},[46,588,589,592,595],{},[49,590,591],{},"Finding type",[49,593,594],{},"Applies to",[49,596,597],{},"Detects",[58,599,600,611,622],{},[46,601,602,605,608],{},[63,603,604],{},"Package vulnerability",[63,606,607],{},"EC2 instances, ECR container images, Lambda functions",[63,609,610],{},"Software packages exposed to published CVEs",[46,612,613,616,619],{},[63,614,615],{},"Code vulnerability",[63,617,618],{},"Lambda functions (code scanning), Code Security",[63,620,621],{},"Exploitable lines of code: missing encryption, data leaks, injection flaws, weak cryptography",[46,623,624,627,630],{},[63,625,626],{},"Network reachability",[63,628,629],{},"EC2 instances only",[63,631,632],{},"Open TCP and UDP paths reachable from a VPC edge such as an internet gateway, peering connection, or virtual gateway",[25,634,635,636,639],{},"Network reachability is the one that catches people out on 2 counts: it is EC2 only, and it runs on a ",[144,637,638],{},"12-hour"," cycle rather than continuously.",[25,641,642,643,646],{},"Severity deserves a note because Inspector does something Config and GuardDuty do not. It takes the National Vulnerability Database CVSS base score and adjusts it for your environment, producing the ",[144,644,645],{},"Amazon Inspector score",". A network-exploitable vulnerability on an instance with no open path to the internet scores lower than the same CVE on an internet-facing instance. Two accounts can hold the same CVE at different severities and both be correct.",[25,648,649],{},"Retention rules follow the state model. Findings for deleted, terminated, or no-longer-eligible resources are closed automatically and deleted after 3 days. Findings closed for any other reason are deleted after 30 days. A remediated finding that reappears within 7 days is reopened rather than recreated. Findings on stopped instances stay active, because a stopped instance still has the vulnerable package on disk.",[32,651,653],{"id":652},"agent-based-agentless-and-how-inspector-picks","Agent-based, agentless, and how Inspector picks",[25,655,656],{},"Package vulnerability scanning on EC2 uses one of 2 collection methods, and the choice per instance is not arbitrary.",[25,658,659,662,663,666,667,670,671,674],{},[144,660,661],{},"Agent-based scanning"," collects the software inventory through the SSM Agent. The instance must be a ",[144,664,665],{},"managed instance in Systems Manager"," in the same account, which in practice means the SSM Agent installed and running plus an instance profile granting SSM permission (the ",[149,668,669],{},"AmazonSSMManagedInstanceCore"," managed policy covers everything Inspector needs). Inspector creates its own SSM associations, with names ending in ",[149,672,673],{},"-do-not-delete",", to install collection plugins and pull inventory. This method scans continuously: at launch, when new software is installed on Linux and Mac, and when a newly published CVE affects the instance. It is also the method that supports Inspector deep inspection for application programming language packages on Linux.",[25,676,677,680,681,684,685,152,688,691,692,695,696,152,699,691,702,705],{},[144,678,679],{},"Agentless scanning"," needs nothing on the instance. Inspector snapshots every attached EBS volume, tags the snapshot with ",[149,682,683],{},"InspectorScan",", reads it through the EBS direct APIs, generates findings, then deletes the snapshot. An instance is eligible when it has a supported OS, has a status of ",[149,686,687],{},"Unmanaged EC2 instance",[149,689,690],{},"Stale inventory",", or ",[149,693,694],{},"No inventory",", is EBS backed with an ",[149,697,698],{},"ext3",[149,700,701],{},"ext4",[149,703,704],{},"xfs"," file system, has fewer than 8 attached volumes totaling 1200 GB or less, and is not excluded by tag.",[25,707,708,711],{},[144,709,710],{},"Hybrid scanning mode"," combines the 2 and is what activating EC2 scanning enrolls you in: SSM managed instances go the agent-based route, and eligible unmanaged instances get agentless coverage. Agentless scans run every 24 hours, and Inspector looks for newly eligible instances every hour. A standalone account or the Inspector delegated administrator can change the scan mode, and when the delegated administrator sets it, the mode applies to every member account in the organization.",[25,713,714],{},"One consequence to expect rather than debug: the same instance can produce different findings depending on which method scanned it. On Linux, agentless scanning inspects all available paths for language packages, while agent-based scanning covers the default paths plus any extra paths you configured for deep inspection.",[25,716,717,718,721],{},"To take an instance out of scanning entirely, tag it with the key ",[149,719,720],{},"InspectorEc2Exclusion",". The tag key is case-insensitive and the value is optional. Excluded instances are not charged.",[25,723,724,725,728,729,732],{},"Beyond package scanning, Inspector also runs ",[144,726,727],{},"CIS scans"," against EC2 operating systems. These target instances by tag, need the instance to be SSM managed with the ",[149,730,731],{},"AmazonInspector2ManagedCisPolicy"," permissions attached, and run once on demand or on a daily, weekly, or monthly schedule. You pick CIS Benchmark Level 1 for baseline settings that should not disrupt service, or Level 2 for high-security environments, where Level 2 includes everything in Level 1.",[32,734,736],{"id":735},"suppression-means-2-different-things","Suppression means 2 different things",[25,738,739],{},"This is the boundary most worth carrying out of the lesson, because both services use the same word for genuinely different behavior.",[40,741,742,754],{},[43,743,744],{},[46,745,746,748,751],{},[49,747],{},[49,749,750],{},"GuardDuty suppression rule",[49,752,753],{},"Inspector suppression rule",[58,755,756,767,778,789,800,811],{},[46,757,758,761,764],{},[63,759,760],{},"Effect on the finding",[63,762,763],{},"Archived",[63,765,766],{},"Hidden from the default console view only",[46,768,769,772,775],{},[63,770,771],{},"Sent to Security Hub CSPM and EventBridge?",[63,773,774],{},"No",[63,776,777],{},"Yes, delivery is unaffected",[46,779,780,783,786],{},[63,781,782],{},"Closes or remediates?",[63,784,785],{},"No, and the finding ages out at 90 days",[63,787,788],{},"No, and Inspector explicitly states rules cannot close or remediate",[46,790,791,794,797],{},[63,792,793],{},"How it clears",[63,795,796],{},"You unarchive it",[63,798,799],{},"The underlying vulnerability is remediated",[46,801,802,805,808],{},[63,803,804],{},"Who can create it",[63,806,807],{},"The GuardDuty administrator in a multi-account setup",[63,809,810],{},"Standalone accounts and the Inspector delegated administrator only",[46,812,813,816,819],{},[63,814,815],{},"Time to take effect",[63,817,818],{},"Immediate for new findings",[63,820,821],{},"Up to 24 hours",[25,823,824,825,828],{},"Delete an Inspector suppression rule and the matching findings return to ",[149,826,827],{},"Active"," and are published to Security Hub CSPM and EventBridge again. Delete a GuardDuty suppression rule and future matches simply stop being archived; the ones already archived stay archived until you unarchive them.",[32,830,832],{"id":831},"running-both-across-an-organization","Running both across an organization",[25,834,835],{},"Both services integrate with AWS Organizations through a delegated administrator, and both are Regional, but the details differ enough to be tested.",[25,837,838,839,842,843,846,847,850,851,854,855,858,859,861,862,865],{},"For ",[144,840,841],{},"GuardDuty",", the Organizations management account designates the delegated administrator, and enabling it there activates GuardDuty in that Region only. The rule that trips people is a pair: the designation is ",[144,844,845],{},"per Region",", and it must be the ",[144,848,849],{},"same account in every Region",". Designate account 111122223333 in Ireland and you cannot designate 555555555555 in Canada. Auto-enable preferences let the administrator cover ",[149,852,853],{},"NEW"," member accounts only or ",[149,856,857],{},"ALL"," accounts including existing ones, and the ",[149,860,853],{}," setting has an ordering trap in opt-in Regions: the member must opt into the Region before joining the organization, or it is no longer new. One administrator manages a maximum of ",[144,863,864],{},"50,000 member accounts",". Removing the delegated administrator removes the member associations but leaves GuardDuty enabled in those accounts.",[25,867,838,868,871,872,875],{},[144,869,870],{},"Inspector",", the delegated administrator can activate the service for the whole organization in one step and set automatic activation for accounts that join later. It can view aggregated findings for all members, activate or deactivate scans for them, set the EC2 scan mode for the entire organization, and own CIS scan configurations at the organization level. There is one privacy boundary: the delegated administrator ",[144,873,874],{},"cannot view code snippets"," belonging to member accounts, because code vulnerability findings include captured source.",[32,877,879],{"id":878},"exam-tips","Exam tips",[138,881,882,885,888,891,894,901,904,911,914,917,923],{},[141,883,884],{},"\"Is someone attacking?\" points at GuardDuty. \"What is vulnerable or exposed?\" points at Inspector. A question mentioning CVEs, patch levels, or container images is Inspector even when it uses security language.",[141,886,887],{},"Nothing needs to be enabled before GuardDuty. If an option says \"first enable VPC flow logs\" or \"first create a CloudTrail trail\", it is wrong.",[141,889,890],{},"The exception is DNS. A non-AWS resolver means no DNS findings, and no setting anywhere fixes it.",[141,892,893],{},"Malware Protection for S3 works without GuardDuty enabled. Every other protection plan requires it.",[141,895,896,897,900],{},"Runtime Monitoring is the one protection plan ",[144,898,899],{},"not"," enabled automatically on first activation.",[141,902,903],{},"Severity boundaries: Low 1.0-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0. Critical implies an attack sequence from Extended Threat Detection.",[141,905,906,907,910],{},"New findings hit EventBridge in about 5 minutes; ",[144,908,909],{},"updates"," follow the export frequency, default 6 hours. Late automation on an ongoing attack is almost always this setting.",[141,912,913],{},"GuardDuty suppression stops downstream delivery. Inspector suppression does not. Do not let the shared word merge them.",[141,915,916],{},"Inspector network reachability is EC2 only, every 12 hours. Agentless package scanning is every 24 hours. Different numbers, different mechanisms.",[141,918,919,920,922],{},"Hybrid mode: SSM managed goes agent-based, unmanaged and EBS backed goes agentless. Exclude with the ",[149,921,720],{}," tag.",[141,924,925],{},"GuardDuty delegated administrator: per Region, same account everywhere, 50,000 member ceiling, designated only by the Organizations management account.",[25,927,928],{},"The thing to carry forward is the split in the first table: GuardDuty tells you something happened, Inspector tells you something is possible. Neither one ranks the two against each other, deduplicates them, or does anything about them. A GuardDuty High on an instance that Inspector already flagged with a remotely exploitable CVE is a different situation from either finding alone, and no single detector can say so. That correlation, and the automation that acts on it, is what the next lesson builds with Security Hub.",{"title":335,"searchDepth":930,"depth":930,"links":931},3,[932,934,935,936,937,938,939,940,941,942],{"id":34,"depth":933,"text":35},2,{"id":132,"depth":933,"text":133},{"id":188,"depth":933,"text":189},{"id":321,"depth":933,"text":322},{"id":510,"depth":933,"text":511},{"id":572,"depth":933,"text":573},{"id":652,"depth":933,"text":653},{"id":735,"depth":933,"text":736},{"id":831,"depth":933,"text":832},{"id":878,"depth":933,"text":879},"md",[945],{"slug":355,"concept":946,"style":947,"aspectRatio":948,"labels":949},"A single-row anatomical breakdown of one real GuardDuty finding type string, CryptoCurrency:EC2/BitcoinTool.B!DNS, rendered large in monospace across the top with each segment visually separated by its delimiter. Callout lines drop from each segment to a short caption explaining what that position means. Two smaller side notes cover the special DetectionMechanism values. A takeaway strip runs along the bottom. Emphasis goes on the delimiters, because the delimiters are what let a reader parse an unfamiliar finding type on sight.","diagram","16:9",[341,950,951,952,953,954,955,956,957],"ThreatPurpose: what the adversary is trying to accomplish","ResourceTypeAffected: which resource type is the target","ThreatFamilyName: the specific malicious activity detected","DetectionMechanism: the variant or the method that caught it","Artifact: a resource owned by the attacker's tooling, optional",".Custom means your own threat list produced the match",".Reputation means a domain reputation model produced the match","Read the type left to right and you have the incident before you open the finding",[13,14,15,16,17,18],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/04-threat-detection-and-response/01-guardduty-and-inspector",{"passingScore":962,"questions":963},70,[964,973,983,991,999,1007,1015,1023,1031,1037],{"question":965,"type":966,"options":967,"correctAnswer":970,"explanation":972},"Your EC2 instances are configured to use a self-managed DNS resolver running in your VPC instead of the Amazon-provided resolver. What effect does this have on GuardDuty?","single",[968,969,970,971],"GuardDuty falls back to reading Route 53 Resolver query logging if you enable it in the Route 53 console","No effect, because GuardDuty inspects DNS traffic directly from VPC flow logs","GuardDuty cannot access or process DNS query data for those instances, so DNS-based finding types will not fire","GuardDuty generates a Policy finding warning that DNS monitoring is degraded","GuardDuty reads Route 53 Resolver DNS query logs through the internal AWS DNS resolvers, so the data exists only when your instances use the AWS resolvers, which is the default. With OpenDNS, Google DNS, or your own resolver, that stream is simply absent, and enabling Route 53 Resolver query logging does not help because GuardDuty uses its own independent stream rather than that feature. VPC flow logs record connections, not DNS names, so they cannot substitute.",{"question":974,"type":975,"options":976,"correctAnswers":981,"explanation":982},"Which statements about GuardDuty foundational data sources are correct? (Choose 2.)","multiple",[977,978,979,980],"You must create a CloudTrail trail before GuardDuty can analyze management events","GuardDuty consumes CloudTrail management events and VPC flow logs through independent, duplicated streams","You are not charged extra for the log data GuardDuty consumes from the foundational data sources","Disabling VPC flow logs on a VPC stops GuardDuty from analyzing network traffic for instances in that VPC",[978,979],"GuardDuty reads these sources through its own duplicated streams, so your CloudTrail and VPC flow log configuration neither enables nor blocks its analysis, and there is no additional cost for the log access itself. This is why the correct answer to 'what do I enable first' is nothing: turning GuardDuty on is the whole setup. You still pay GuardDuty's own per-volume pricing after the 30-day free trial.",{"question":984,"type":966,"options":985,"correctAnswer":986,"explanation":990},"A finding arrives with the type Backdoor:EC2/C&CActivity.B!DNS. What does the segment after the exclamation mark tell you?",[986,987,988,989],"The artifact involved, in this case a domain owned by the attacker's tooling","The severity band assigned to the finding","The detection mechanism, meaning a custom threat list matched","The AWS Region where the activity was observed","The format is ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact, so everything after the exclamation mark names a resource owned by the tool used in the activity. The detection mechanism sits after the period, not the exclamation mark, and values like .Custom and .Reputation live there. Severity and Region are fields in the finding body, never encoded in the type name.",{"question":992,"type":966,"options":993,"correctAnswer":997,"explanation":998},"A GuardDuty finding has a severity value of 8.2. Which severity level is that, and what does GuardDuty recommend?",[994,995,996,997],"Critical, indicating an attack sequence may be in progress across multiple resources","Medium, indicating behavior that deviates from the baseline and should be reviewed at your earliest convenience","Low, indicating attempted activity that did not compromise the environment","High, indicating the resource is compromised and actively being used for unauthorized purposes, so remediate immediately","GuardDuty splits the 1.0 to 10.0 range into Low (1.0 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9), and Critical (9.0 to 10.0), so 8.2 is High. Critical is reserved for attack sequence findings from Extended Threat Detection, where several correlated events suggest an attack spanning resources and time. Knowing the boundary values matters because scenario questions often give you a number rather than a label.",{"question":1000,"type":966,"options":1001,"correctAnswer":1003,"explanation":1006},"Your team creates a GuardDuty suppression rule for Recon:EC2/Portscan findings coming from the vulnerability scanner AMI. A colleague asks whether the findings will still appear in your SIEM, which reads from Security Hub CSPM. What do you tell them?",[1002,1003,1004,1005],"Yes, suppression only changes the console view and downstream delivery is unaffected","No, suppressed findings are archived and are not sent to Security Hub CSPM, S3, Detective, or EventBridge","Yes, but only for the first 90 days, after which delivery stops","No, and the findings are also deleted immediately rather than retained","A GuardDuty suppression rule auto-archives matching new findings, and archived findings are held out of every downstream integration, which is exactly why it reduces SIEM noise. The findings are still generated and stored in GuardDuty for 90 days, viewable by filtering on Archived, so nothing is lost for later investigation. Note the side effect: archived findings are not used as signals for Extended Threat Detection attack sequences, so broad suppression rules blind the correlation engine.",{"question":1008,"type":966,"options":1009,"correctAnswer":1012,"explanation":1014},"Which statement correctly contrasts Inspector suppression rules with GuardDuty suppression rules?",[1010,1011,1012,1013],"Both archive the finding and stop publication to Security Hub CSPM and EventBridge","Inspector suppression closes the finding, while GuardDuty suppression only hides it","Inspector suppression only hides findings from view and never closes or remediates them, and deleting the rule republishes them to Security Hub CSPM and EventBridge","Inspector suppression can be created by any member account, while GuardDuty suppression requires the administrator","Inspector explicitly states that suppression rules have no impact on the findings themselves and cannot close or remediate them; a suppressed finding closes only when the underlying vulnerability is actually remediated. GuardDuty goes further by archiving and cutting downstream delivery. Both services restrict rule creation to standalone accounts and the delegated administrator, so the last option describes neither.",{"question":1016,"type":966,"options":1017,"correctAnswer":1019,"explanation":1022},"An EC2 instance is not managed by Systems Manager, is EBS backed with an xfs file system, and has 2 attached volumes totaling 300 GB. Your account uses hybrid scanning mode. How does Inspector scan it for package vulnerabilities?",[1018,1019,1020,1021],"It skips the instance until you install and register the SSM Agent","It uses the agentless method, creating EBS snapshots, reading them through the EBS direct APIs, then deleting the snapshots","It uses the agent-based method through an SSM association installed at launch","It generates only network reachability findings for the instance","Hybrid mode routes SSM managed instances to agent-based scanning and unmanaged, stale-inventory, or no-inventory instances to agentless scanning, and this instance meets every agentless requirement: supported file system, fewer than 8 volumes, and 1200 GB or less in total. Agentless scans run every 24 hours, while agent-based scans are continuous and react to new packages and newly published CVEs. Network reachability findings are produced for EC2 instances regardless of the package scan method.",{"question":1024,"type":966,"options":1025,"correctAnswer":1028,"explanation":1030},"Which Inspector finding type applies only to EC2 instances, and on what schedule is it produced?",[1026,1027,1028,1029],"Package vulnerability, produced continuously as new CVEs are published","Code vulnerability, produced whenever a function is updated","Network reachability, produced by a scan that runs every 12 hours","Network reachability, produced by a scan that runs every 24 hours","Network reachability findings identify open TCP and UDP paths from VPC edges such as internet gateways, peering connections, and virtual gateways, and Inspector produces them only for EC2 instances on a 12-hour cycle. Package vulnerability findings cover EC2, ECR container images, and Lambda functions, and code vulnerability findings come from Lambda code scanning and Code Security. The 24-hour interval belongs to agentless package scanning, which is a different mechanism.",{"question":1032,"type":966,"options":1033,"correctAnswer":1035,"explanation":1036},"True or False: an organization can designate one account as the delegated GuardDuty administrator in us-east-1 and a different account in eu-west-1.",[1034,1035],"True","False","GuardDuty is Regional, so the Organizations management account must designate the delegated administrator separately in every Region, but it must be the same account each time. The Regional part of the rule catches people who assume a single global designation, and the same-account part catches people who assume Regional means independent. A GuardDuty administrator can manage a maximum of 50,000 member accounts.",{"question":1038,"type":966,"options":1039,"correctAnswer":1041,"explanation":1044},"A GuardDuty finding fired at 09:00 and your remediation Lambda ran at 15:00. The finding was an update to an existing SSHBruteForce finding rather than a new one. What is the most likely cause?",[1040,1041,1042,1043],"The EventBridge rule was throttled by the Lambda concurrency limit","The frequency for exporting updated findings is set to the default of 6 hours","GuardDuty batches all findings into a single hourly export","The finding was archived by a suppression rule and released later","New active findings are exported to EventBridge within about 5 minutes, but updates to existing findings follow the export frequency setting, which defaults to every 6 hours and can be changed to 15 minutes or 1 hour. Because GuardDuty aggregates repeated activity against the same resource into the original finding rather than creating new ones, ongoing attacks arrive as updates and inherit that delay. An archived finding would not have been delivered at all.",{"title":7,"description":8},"courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/04-threat-detection-and-response/01-guardduty-and-inspector","r-GDaRGtnYa3ZcwbCUhZpoJYa8XPFoSNV-vNQVN9spc",{"locked":9,"reason":1049,"meta":1050,"item":3},"paywall",{"title":1051,"description":1052,"isFree":5,"estimatedMinutes":10,"difficulty":11,"learningObjectives":1053},"Encryption in Transit with ACM","How to get TLS certificates that renew themselves, why some ACM certificates quietly do not, and how to terminate and enforce TLS across load balancers, CloudFront, and S3.",[1054,1055,1056,1057,1058,1059],"Describe what ACM manages and where an ACM certificate can and cannot be used","Compare DNS, email, and HTTP domain validation and explain the renewal consequence of each","Determine whether a given certificate is eligible for ACM managed renewal","Select and interpret an ELB security policy for a TLS requirement","Enforce HTTPS end to end across a load balancer, CloudFront, and Amazon S3","Diagnose common certificate request, validation, and renewal failures",{"locked":9,"reason":1049,"meta":1061,"item":3},{"title":1062,"description":1063,"isFree":5,"estimatedMinutes":10,"difficulty":11,"learningObjectives":1064},"Secrets Management","Where credentials belong on AWS and why: Parameter Store tiers and SecureString, Secrets Manager rotation and staging labels, cross-account access, and the failures each design produces.",[1065,1066,1067,1068,1069,1070],"Choose between Secrets Manager, Parameter Store, and AppConfig for a stated requirement","Apply Parameter Store's standard and advanced tier limits to a design decision","Trace a secret through the 4 rotation steps and the AWSCURRENT, AWSPENDING, and AWSPREVIOUS staging labels","Compare single user and alternating users rotation, and identify when managed rotation applies","Configure cross-account and cross-Region access to a secret, including the KMS key requirement","Diagnose common secret retrieval, rotation, and deletion failures"]