Amazon SCS-C02: Bedreigingsdetectie en Alarmering — Studiegids

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Onderdeel van de AWS Security Specialty SCS-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

GuardDuty Centraliseren Binnen een Organisatie

Amazon GuardDuty is een continue service voor dreigingsdetectie die CloudTrail management- en data-events, VPC Flow Logs, DNS-querylogs, EKS-auditlogs, RDS-loginactiviteit en runtime-telemetrie analyseert. Het produceert bevindingen die zijn geclassificeerd op basis van dreigingsdoel (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact) en resourcetype (EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime).

GuardDuty per account beheren is niet schaalbaar. De juiste architectuur in een AWS Organizations-omgeving is om een gedelegeerde beheerder (delegated administrator) aan te wijzen — meestal het toegewijde security- of audit-account — via het managementaccount van Organizations. Vanuit de gedelegeerde beheerder schakel je GuardDuty organisatiebreed in en activeer je auto-enable zodat nieuwe lidaccounts en nieuwe regio’s automatisch worden beschermd zodra ze worden aangemaakt. Zonder auto-enable blijft een nieuw aangemaakt account onzichtbaar totdat een operator handmatig detectie inschakelt, wat precies de kwetsbaarheid is die aanvallers misbruiken tijdens het onboarden.

Praktijkprobleem: Use-Case Scenario

Scenario: Meridian Financial beheert een multi-account AWS-omgeving met 28 accounts voor productie, dev en gedeelde services. Hun managementaccount beheert de accounts via AWS Organizations, met gecentraliseerde CloudTrail- en S3-logging, maar beveiligingswaarschuwingen en onderzoeksdata zijn verspreid over de lidaccounts, wat de triage van incidenten traag en inconsistent maakt.

Uitdaging: Een recente detectie van laterale beweging (lateral movement) in één account produceerde GuardDuty-bevindingen die niet snel genoeg zichtbaar waren voor de centrale SOC-tools, wat de indamming en het forensisch onderzoek vertraagde.

Aanbevolen Aanpak:

Wijs een gedelegeerde GuardDuty-beheerder aan in het managementaccount en schakel GuardDuty in voor de hele organisatie via AWS Organizations, zodat alle lidaccounts bevindingen doorsturen naar een centrale detector.
Activeer de gecentraliseerde AWS Security Hub in het managementaccount als de aggregator en schakel Security Hub in voor alle accounts en regio’s om GuardDuty-bevindingen te normaliseren naast andere beveiligingsstandaarden.
Configureer Amazon EventBridge-regels in het managementaccount om GuardDuty- en Security Hub-bevindingen op te vangen en door te sturen naar gecentraliseerde doelen zoals Amazon SNS voor paging, Amazon Kinesis Data Firehose naar S3 voor archivering, of directe levering aan uw SIEM.
Implementeer Lambda-responders die worden getriggerd door EventBridge voor geautomatiseerde indammingsacties (bijvoorbeeld, een EC2-instance isoleren via de EC2 API en een AWS Systems Manager-incident aanmaken) en tag bevindingen voor onderzoek.
Integreer Amazon Detective voor gecentraliseerd onderzoek en stuur gearchiveerde bevindingen in S3 door naar uw analytics/SIEM voor langetermijncorrelatie en rapportage.

Rationale: Het gebruik van een gedelegeerde GuardDuty-beheerder met Security Hub en EventBridge centraliseert detectie, normaliseert waarschuwingen en maakt geautomatiseerde, auditeerbare reacties mogelijk volgens de best practices van AWS voor organisatiebrede dreigingsdetectie en tijdige incidentrespons.

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDuty is regionaal, dus de relatie met de gedelegeerde beheerder en de auto-enable-instellingen moeten in elke regio waarin u actief bent, worden ingesteld. Dit is een veelvoorkomende oorzaak van blinde vlekken — een team schakelt GuardDuty in us-east-1 in en gaat uit van wereldwijde dekking.

Servicespecifieke Beveiligingen

De basisversie van GuardDuty dekt fundamentele databronnen, maar verschillende beveiligingsplannen moeten expliciet worden ingeschakeld omdat ze extra kosten en aanvullende telemetrie-ingestie met zich meebrengen:

RDS Protection: profileert loginactiviteit voor Aurora MySQL/PostgreSQL en RDS-engines, en genereert bevindingen zoals CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin wanneer onbekende gebruikers zich authenticeren bij een DB-eindpunt. Dit is de juiste bron voor het detecteren van verdachte database-logins — bouw geen aangepaste CloudWatch-metriekfilters op DB-auditlogs wanneer RDS Protection de bevinding al native uitzendt.
EKS Protection: verwerkt Kubernetes-auditlogs om anomale API-toegang, het aanmaken van geprivilegieerde pods en het gebruik van blootgestelde dashboards te detecteren.
Runtime Monitoring: implementeert een lichtgewicht, op eBPF gebaseerde agent op EC2, ECS/Fargate of EKS om proces-, bestands- en netwerkgebeurtenissen aan het licht te brengen — vereist voor het detecteren van ‘fileless’ malware of reverse shells tijdens runtime.
Malware Protection: scant via snapshots EBS-volumes die zijn gekoppeld aan instances die door andere bevindingen zijn gemarkeerd, of scant on-demand S3-objecten bij het uploaden.
Lambda Protection en S3 Protection: dekken respectievelijk patronen in functie-aanroepen en data-plane S3-toegang.

Alleen de basisdienst inschakelen en verwachten dat DB-loginanomalieën verschijnen, is een veelvoorkomende misconfiguratie — de typen bevindingen worden simpelweg niet geproduceerd totdat de corresponderende functie is ingeschakeld.

Security Hub als de Aggregatielaag

Security Hub neemt bevindingen op van GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health en ISV-producten van derden, en normaliseert deze naar het AWS Security Finding Format (ASFF). Het voert ook zijn eigen compliancestandaarden uit (AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53).

Om te centraliseren binnen een Organization:

Schakel Security Hub als een service in binnen Organizations en wijs een gedelegeerde beheerder (delegated administrator) aan (meestal hetzelfde security-account als voor GuardDuty).
Schakel auto-enable new accounts in zodat leden automatisch worden toegevoegd.
Configureer een finding aggregation Region (ook wel de home Region genoemd) en koppel alle andere Regions hieraan. Zonder cross-Region-aggregatie heeft elke Region een onafhankelijke Security Hub-instantie en moeten analisten wisselen tussen consoles.

Het patroon voor een wereldwijde uitrol binnen de organisatie vereist dus twee gecoördineerde instellingen: de koppeling van de aggregatie-Region en de organisatiebrede auto-enable-schakelaar. Als je de ene inschakelt zonder de andere, blijven nieuwe accounts ongedekt of raken nieuwe Regions geïsoleerd.

Een belangrijke beperking: Security Hub aggregeert en prioriteert, maar voert geen herstelacties (remediation) uit. Het behandelen als een herstelplatform is een categoriefout — de herstelacties vinden downstream plaats via EventBridge.

EventBridge als de Automatiseringslaag

Zowel GuardDuty als Security Hub publiceren bevindingen naar de standaard event bus. aws.guardduty zendt GuardDuty Finding-events uit, en aws.securityhub zendt Security Hub Findings - Imported (aangemaakt/bijgewerkt door Hub) en Security Hub Findings - Custom Action (door een operator geactiveerd) uit.

Te algemene regels zoals {"source": ["aws.securityhub"]} roepen targets aan bij elke update van een bevinding van elke provider, waardoor SNS-topics snel vollopen en on-call engineers worden bestookt met informatieve ruis. De juiste aanpak is om te filteren op severity.Label, ProductArn, Types, of specifieke Title-waarden:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }],
    "type": [{ "prefix": "CredentialAccess:RDS/" }]
  }
}

Voor een Security Hub-gericht patroon dat alleen wordt geactiveerd bij GuardDuty-bevindingen met een hoge ernstgraad, terwijl luidruchtige ISV-producten van derden worden genegeerd:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Veelvoorkomende targets zijn een SNS-topic voor e-mail/SMS/Slack-notificaties, een Lambda-functie die een instance isoleert door de security group te verwisselen, een SSM Automation runbook, of een Step Functions state machine die een respons in meerdere stappen orkestreert. Voor de use case van een inlogafwijking bij Aurora is het pad met de minste inspanning: GuardDuty RDS Protection → EventBridge-regel gefilterd op het RDS-bevindingstype → SNS-topic met e-mailabonnement. Geen custom polling, geen Lambda en geen SIEM van derden nodig.

Security Hub Custom Actions

Custom actions zijn door een operator aangestuurde triggers. In de Security Hub-console selecteert een analist een of meer bevindingen en kiest een custom action (bijvoorbeeld “Quarantine EC2”). Security Hub zendt een Security Hub Findings - Custom Action-event uit met de ARN’s van de geselecteerde bevindingen; een EventBridge-regel matcht op de ARN van de custom action en roept een Lambda aan die de respons uitvoert. Dit geeft je een ‘human-in-the-loop’-knop zonder dat je een op maat gemaakte UI hoeft te bouwen:

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

De resulterende ARN (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) wordt de match-waarde in het resources-veld van de EventBridge-regel.

Onderdrukking en Signaalbeheer

Ruisbeheer is een discipline, geen eenmalig filter. Gebruik Security Hub automation rules of GuardDuty suppression rules om bevindingen die bekend staan als goedaardig (known-benign) automatisch te archiveren (bijvoorbeeld een verwachte Recon:EC2/Portscan-bevinding van een penetratietesttool). Filter EventBridge-regels op ProductArn om een luidruchtige integratie van derden stil te leggen zonder deze volledig uit te schakelen. Combineer Severity.Label met Workflow.Status = NEW zodat heropende of reeds gemelde bevindingen niet opnieuw een melding veroorzaken. Het doel is dat elke waarschuwing die een mens bereikt, een bruikbare gebeurtenis met een hoge betrouwbaarheid (high-confidence) vertegenwoordigt — al het andere ondermijnt de paraatheid om te reageren.

Onderzoekspivot

Wanneer een bevinding met een hoge ernstgraad wordt geactiveerd — bijvoorbeeld Backdoor:EC2/C&CActivity.B!DNS — is het snelste onderzoekspad niet het handmatig schrijven van Athena-queries voor CloudTrail en Flow Logs. Amazon Detective, indien ingeschakeld naast GuardDuty, bouwt vooraf entiteitsgrafieken (entity graphs) op basis van CloudTrail, VPC Flow Logs en GuardDuty-bevindingen. Door vanuit de bevinding direct te ‘pivotten’ naar de IAM-rol of het EC2-instanceprofiel in Detective, worden API-activiteit, netwerk-peers en het aantal geslaagde versus mislukte verbindingen binnen het relevante tijdvenster zichtbaar, zonder dat er aangepaste queries nodig zijn.

← Identiteit en Toegangsbeheer · Alle domeinen · Logging →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →