Wie konfiguriert man mit Terraform eine automatisierte Reaktion auf Sicherheitsvorfälle in Amazon GuardDuty?

Einführung

In diesem Tutorial lernen Sie, wie Sie eine AWS-Sicherheitslösung mit Terraform konfigurieren. Sie verwenden dazu die Dienste Amazon GuardDuty, Amazon SNS, AWS Lambda und Amazon EvenBridge.

Die Erkennung von Bedrohungen und die Reaktion auf Sicherheitsvorfälle (TDIR) können für viele Organisationen zeitaufwändig und manuell sein. Dies führt zu inkonsistenten Reaktionsprozessen, uneinheitlichen Sicherheitsergebnissen und einem erhöhten Risiko. In diesem Tutorial erfahren Sie, wie Sie die Erkennung von Bedrohungen und Ihren Prozess der Reaktion auf Sicherheitsvorfälle automatisieren und so die Reaktionszeit verkürzen. Da viele Organisationen standardisierte Infrastructure-as-Code (IaC)-Tools für konsistente Konfigurationen über verschiedene Anbieter hinweg bevorzugen, zeigt dieses Tutorial, wie Sie diese Lösung mit Terraform konfigurieren.

Voraussetzungen

• AWS-Konto

Über Amazon GuardDuty

Bevor wir mit dem Tutorial beginnen, ist es hilfreich, die grundlegende Funktionsweise einiger der verwendeten Tools zu verstehen. Amazon GuardDuty bietet Bedrohungserkennung, mit der Sie AWS-Konten, Workloads und in Amazon Simple Storage Service (S3) gespeicherte Daten kontinuierlich überwachen und schützen können. GuardDuty analysiert kontinuierlich Metadatenströme Ihres Kontos sowie Netzwerkaktivitäten aus AWS CloudTrail-Ereignissen, Amazon Virtual Private Cloud (VPC)-Flow-Logs und DNS-Logs. GuardDuty nutzt außerdem integrierte Bedrohungsdaten wie bekannte schädliche IP-Adressen, Anomalieerkennung und maschinelles Lernen (ML), um Bedrohungen präziser zu identifizieren.

GuardDuty arbeitet völlig unabhängig von Ihren Ressourcen, sodass weder die Leistung noch die Verfügbarkeit Ihrer Workloads beeinträchtigt werden. Der Service ist vollständig verwaltet und beinhaltet integrierte Bedrohungsanalysen, Anomalieerkennung und maschinelles Lernen. Amazon GuardDuty liefert präzise, umsetzbare Warnmeldungen, die sich nahtlos in bestehende Ereignismanagementsysteme und Workflows integrieren lassen. Es fallen keine Vorabkosten an; Sie zahlen nur für analysierte Ereignisse. Zusätzliche Software oder Abonnements für Bedrohungsdaten-Feeds sind nicht erforderlich.

Über Terraform und Cloud9

Terraform ist ein Infrastructure-as-Code (IaC)-Tool von HashiCorp, mit dem Sie Infrastrukturen mithilfe von Konfigurationsdateien anstelle einer Benutzeroberfläche verwalten können. Mit Terraform können Sie Ihre Infrastruktur mithilfe von lesbaren, deklarativen Konfigurationsdateien erstellen, ändern und löschen. Ja, Sie können mit Terraform auch AWS-Infrastruktur erstellen, ändern und löschen – mithilfe eines Terraform-Plugins namens Provider. Der AWS Provider ermöglicht Terraform die Interaktion mit der AWS-Programmierschnittstelle (API).

Dieses Tutorial verwendet AWS Cloud9 zur Terraform-Konfiguration. AWS Cloud9 ist eine cloudbasierte integrierte Entwicklungsumgebung (IDE), mit der Sie Ihren Code direkt im Browser schreiben, ausführen und debuggen können. Sie umfasst einen Code-Editor, einen Debugger und ein Terminal. Cloud9 enthält bereits die wichtigsten Tools für gängige Programmiersprachen wie JavaScript, Python, PHP und Terraform. Sie müssen daher keine Dateien installieren oder Ihren Entwicklungsrechner konfigurieren, um mit diesem Workshop zu beginnen. Cloud9 läuft auf einer EC2-Instanz, die für Sie zu Beginn des Workshops erstellt wird.

Was Sie tun werden

1. Ein “Kontakt”-Host interagiert mit einem “gefährdeten” Host, was GuardDuty veranlasst, einen entsprechenden Befund zu melden.
2. Dieser Befund wird in einer EventBridge-Regel abgebildet, die Sie mit Terraform erstellen werden. Die EventBridge-Regel bewirkt zwei Dinge:
3. Erstellt eine SNS-Regel, die Sie mit Terraform erstellen. Diese SNS-Regel sendet eine E-Mail mit einem lesbaren Text, der die Ergebnisse erläutert, an einen festgelegten Administrator.
4. Es löst eine Lambda-Funktion aus, die Sie mit Terraform erstellen. Die Lambda-Funktion übergibt den kompromittierten Host an eine forensische Sicherheitsgruppe, wo er zur weiteren Untersuchung isoliert wird.

Schritt 1. Laden Sie die Ersteinstellungen herunter

Dieses Tutorial verwendet eine AWS CloudFormation-Vorlage zur Bereitstellung der initialen Ressourcen. So können Sie sich ganz auf die grundlegende Konfiguration Ihrer Sicherheitslösung konzentrieren. Die CloudFormation-Vorlage erstellt einen Stack. Dieser Stack besteht aus einer AWS Cloud9 IDE-Instanz. Wir verwenden diese Cloud9-Instanz, um allen Teilnehmenden dieses Tutorials die gleiche Bearbeitungs- und Bereitstellungserfahrung zu bieten. Wenn Sie den Stack in der Region US-WEST-2 bereitstellen, stellen Sie außerdem sicher, dass eine t3.small-Instanz vorhanden ist. Wird die Vorlage in anderen Regionen bereitgestellt, müssen Sie sie gegebenenfalls anpassen, um einen anderen Instanztyp zu verwenden, falls t3.small nicht verfügbar ist.

1.1. Gehen Sie in der AWS Management Console zu AWS CloudFormation und erstellen Sie einen Stack, indem Sie auf die Schaltfläche "Stack erstellen" klicken.

1.2. Wählen Sie „Vorlagendatei hochladen“ und laden Sie die Datei gd-iac-initial.yml aus dem oben angegebenen Beispielcode-Repository hoch. Klicken Sie anschließend auf „Weiter“.

1.3. Geben Sie einen Stapelnamen ein und klicken Sie auf Weiter.

1.4. Klicken Sie auf der Seite "Stack-Optionen konfigurieren" auf "Weiter".

1.5. Scrollen Sie auf der Übersichtsseite nach unten und aktivieren Sie das Kontrollkästchen, um zu bestätigen, dass AWS CloudFormation IAM-Ressourcen erstellen darf. Klicken Sie anschließend auf Weiter.

1.6. Stellen Sie sicher, dass sich der Stack in einem vollständig erstellten Zustand befindet.

An diesem Punkt haben Sie die initialen Ressourcen bereitgestellt, die Sie benötigen, um diesem Tutorial selbstständig zu folgen. Im nächsten Schritt greifen Sie auf die Cloud9-Instanz zu, die den Stack erstellt hat, und initialisieren Terraform.

Schritt 2. Greifen Sie auf Cloud9 zu und starten Sie Terraform.

2.1. Öffnen Sie AWS Cloud9 in der AWS Management Console und öffnen Sie die Umgebung in der Cloud9 IDE.

2.2. Deaktivieren Sie in den Cloud9-Einstellungen die Verwendung von AWS-verwalteten temporären Anmeldeinformationen.

2.3. Simulieren Sie vom Terminal auf der Cloud9-Instanz aus das Quellcode-Repository.

git clone https://github.com/build-on-aws/automating-amazon-guardduty-with-iac.git

2.4. Wechseln Sie in das Verzeichnis automating-amazon-guardduty-with-iac und führen Sie terraform init, terraform plan und terraform apply aus.

Eine erfolgreiche Anfrage sieht folgendermaßen aus:

2.5. Überprüfen Sie, ob zwei neue EC2-Instanzen vorhanden sind, eine mit dem Namen IAC Tutorial: Compromised Instance und die andere mit dem Namen IAC Tutorial: Malicious Instance.

Sie haben nun eine VPC und zwei EC2-Instanzen bereitgestellt. Die beiden EC2-Instanzen kommunizieren miteinander. Wenn Sie später eine IP-Adresse einer der EC2 Elastic-Instanzen zur Bedrohungsliste hinzufügen, löst dies in GuardDuty eine Sicherheitswarnung aus. Ab diesem Zeitpunkt erstellen Sie alle Ressourcen, die Teil Ihrer eigentlichen Sicherheitslösung sind.

Schritt 3: Erstellen Sie einen S3-Bucket zum Speichern der Bedrohungsliste

GuardDuty kann auf zwei Arten von Listen zugreifen: eine Liste vertrauenswürdiger IP-Adressen und eine Liste mit Bedrohungs-IP-Adressen. GuardDuty erstellt keine Meldungen für IP-Adressen, die in Listen vertrauenswürdiger IP-Adressen enthalten sind, wohl aber für IP-Adressen in Listen mit Bedrohungs-IP-Adressen. Da wir in diesem Tutorial eine Meldung erzwingen möchten, verwenden wir eine Liste mit Bedrohungs-IP-Adressen.

3.1. Erstellen Sie zunächst eine Variable für vpc_id in modules/s3/variables.tf.

variable "vpc_id" {
}

3.2. Anschließend wird in der Datei modules/s3/main.tf die aktuelle AWS-Kontonummer ermittelt und eine S3-Bucket-Ressource erstellt.

# GET CURRENT AWS ACCOUNT NUMBER
data "aws_caller_identity" "current" {}
# CREATE TWO S3 BUCKETS
resource "aws_s3_bucket" "bucket" {
bucket = "guardduty-example-${data.aws_caller_identity.current.account_id}-us-east-1"
force_destroy = true
}
resource "aws_s3_bucket" "flow-log-bucket" {
bucket = "vpc-flow-logs-${data.aws_caller_identity.current.account_id}-us-east-1"
force_destroy = true
}

3.3. Aktivieren Sie anschließend die VPC-Flow-Protokolle im S3-Bucket. Dies ist zwar nicht zwingend erforderlich, ermöglicht uns aber, die Protokolle einzusehen, die auch GuardDuty erfasst.

# VPC FLOW LOGS
resource "aws_flow_log" "flow_log_example" {
log_destination = aws_s3_bucket.flow-log-bucket.arn
log_destination_type = "s3"
traffic_type = "ALL"
vpc_id = var.vpc_id
}

3.4. Zum Schluss werden die Werte für bucket_id und bucket_arn in der Datei modules/s3/outputs.tf ausgegeben.

# S3 Bucket id
output "bucket_id" {
value = aws_s3_bucket.bucket.id
description = "Output of s3 bucket id."
}
# S3 Bucket arn
output "bucket_arn" {
value = aws_s3_bucket.bucket.arn
description = "Output of s3 bucket arn."
}

3.5. Gehen Sie nun zurück zur Datei root/main.tf und fügen Sie den S3-Bucket hinzu.

# CREATES S3 BUCKET
module "s3_bucket" {
source = "./modules/s3"
vpc_id = module.iac_vpc.vpc_attributes.id
}

Sie haben nun zwei S3-Buckets erstellt. Falls Sie diese selbst überprüfen möchten: Ein Bucket enthält VPC-Flow-Logs. Der andere Bucket enthält die Bedrohungsliste, die Sie im nächsten Schritt erstellen werden.

Schritt 4: GuardDuty Terraform-Module erstellen

4.1. Die GuardDuty-Moduldateien wurden bereits erstellt, sind aber wie die S3-Dateien leer. Beginnen Sie mit der Datei modules/guardduty/variables.tf. Hier müssen Sie zwei Variablen anlegen. Die erste Variable heißt „bucket“ und dient zur Definition der Details der Bedrohungsliste im S3-Bucket. Die zweite Variable enthält die schädliche IP-Adresse, die wir dem Bucket hinzugefügt haben.

variable "bucket" {
}
variable "malicious_ip" {
}

4.2. Gehen Sie anschließend zur Datei modules/guardduty/main.tf.

In dieser Datei fügen Sie drei Datenquellen hinzu. Die erste Quelle ist der GuardDuty-Detektor. Wie Sie in der Dokumentation des Anbieters sehen, sind alle Optionen optional – außer der Angabe der Datenquelle ist nichts weiter erforderlich. In unserem Beispiel setzen wir den Wert für „enabled“ auf „true“ und ändern die „finding_publishing_frequency“ auf 15 Minuten. Der Standardwert ist eine Stunde.

# ENABLE THE DETECTOR
resource "aws_guardduty_detector" "gd-tutorial" {
enable = true
finding_publishing_frequency = "FIFTEEN_MINUTES"
}

4.3. Als Nächstes laden wir eine Datei in den im vorherigen Schritt erstellten S3-Bucket hoch. Dies ist zwar nicht zwingend erforderlich, aber zu Demonstrationszwecken verwenden wir die IP-Adresse einer der EC2-Instanzen, um sicherzustellen, dass die Ergebnisse dieses Tutorials generiert werden. Im folgenden Code laden wir eine Textdatei in unseren S3-Bucket hoch, die wir „MyThreatIntelSet“ nennen. Der Inhalt dieser Datei ist die in der Variable „var.malicious_ip“ gespeicherte IP-Adresse.

# ADD THE EIP/MALICIOUS IP TO THE BUCKET AS A TEXT FILE.
resource "aws_s3_object" "MyThreatIntelSet" {
content = var.malicious_ip
bucket = var.bucket
key = "MyThreatIntelSet"
}

4.4. Abschließend erstellen wir eine Ressource namens aws_guardduty_threatintelset, die GuardDuty anweist, die Datei am definierten Speicherort zu verwenden (genau das bewirkt activate = true).

# HAVE GUARDDUTY LOOK AT THE TEXT FILE IN S3
resource "aws_guardduty_threatintelset" "Example-Threat-List" {
activate = true
detector_id = aws_guardduty_detector.gd-tutorial.id
format = "TXT"
location = "https://s3.amazonaws.com/${aws_s3_object.MyThreatIntelSet.bucket}/${aws_s3_object.MyThreatIntelSet.key}"
name = "MyThreatIntelSet"
}

4.5. Öffnen Sie anschließend die Datei root/main.tf und rufen Sie das GuardDuty-Modul auf. Sie benötigen die Bucket-ID und die IP-Adresse des Angreifers. Diese Daten stammen vom S3-Modul und dem Compute-Modul.

# Enable GuardDuty
module "guardduty" {
source = "./modules/guardduty"
bucket = module.s3_bucket.bucket_id
malicious_ip = module.compute.malicious_ip
}

In diesem Abschnitt haben Sie GuardDuty aktiviert, die Bedrohungsliste erstellt und die Elastic IP-Adresse der schädlichen EC2-Instanz zu dieser Liste hinzugefügt. Als Nächstes erstellen wir eine SNS-Regel.

Schritt 5: Erstellen Sie das SNS-Terraform-Modul

In diesem Abschnitt erstellen wir mit Terraform eine SNS-Regel. SNS ist ein einfacher Benachrichtigungsdienst, mit dem Sie Benachrichtigungen versenden können, sobald bestimmte Kriterien erfüllt sind. SNS selbst bietet keine Möglichkeit, eine Nachricht zu senden. Dafür verwenden wir EventBridge. Da EventBridge jedoch eine Regel zum Senden von Benachrichtigungen benötigt, müssen wir zunächst die SNS-Regel erstellen.

5.1. Zuerst müssen Sie in der Datei modules/sns/variables.tf zwei Variablen erstellen:

1. sns_name, um das SNS-Thema zu benennen, das wir erstellen werden.
2. E-Mail-Adresse zur Speicherung der E-Mail-Adresse, die wir für das Abonnieren unserer Benachrichtigungen verwenden.

Nachfolgend ein Beispiel unserer Variablen für SNS.

variable "sns_name" {
description = "Name of the SNS Topic to be created"
default = "GuardDuty-Example"
}
variable "email" {
description = "Email address for SNS"
}

5.2. Anschließend erstellen wir das SNS-Thema und das Abonnement in der Datei modules/sns/main.tf.

Erstellen Sie zunächst eine Themenressource.

# Create the SNS topic
resource "aws_sns_topic" "gd_sns_topic" {
name = var.sns_name
}

Im obigen Code erstellen Sie mit Terraform eine Ressource namens gd_sns_topic. In der AWS-Konsole heißt sie “GuardDuty-Example”. Das liegt daran, dass wir die Variable var.sns_name verwenden, die standardmäßig auf “GuardDuty-Example” gesetzt ist.

5.3. Erstellen Sie als Nächstes eine SNS-Richtlinienressource. Die Werte für ARN und Richtlinie sind erforderlich. Die hier erstellte Richtlinie ist ein AWS-IAM-Richtliniendokument. Dieses Richtliniendokument erlaubt dem Dienstprinzipal events.amazonaws.com, Beiträge im betreffenden Thema zu veröffentlichen.

resource "aws_sns_topic_policy" "gd_sns_topic_policy" {
arn = aws_sns_topic.gd_sns_topic.arn
policy = jsonencode(
{
Id = "ID-GD-Topic-Policy"
Statement = [
{
Action = "sns:Publish"
Effect = "Allow"
Principal = {
Service = "events.amazonaws.com"
}
Resource = aws_sns_topic.gd_sns_topic.arn
Sid = "SID-GD-Example"
},
]
Version = "2012-10-17"
}
)
}

5.4. Als Nächstes erstellen Sie das Themenabonnement. Dieses Abonnement ruft den ARN auf, legt das zu verwendende Protokoll fest – in diesem Fall E-Mail – und die E-Mail-Adresse, an die die Benachrichtigung gesendet wird. Die E-Mail-Adresse ist hier fest codiert, Sie können sie aber so konfigurieren, dass sie bei der Anwendung von Terraform abgefragt wird. Wenn Sie `endpoint_auto_confirm` auf `false` setzen, erhält der E-Mail-Inhaber eine E-Mail mit einem Link, über den er die Benachrichtigungen abonnieren kann.

# Create the topic subscription 
resource "aws_sns_topic_subscription" "user_updates_sqs_target" {
topic_arn = aws_sns_topic.gd_sns_topic.arn
protocol = "email"
endpoint = var.email
endpoint_auto_confirms = false
}

5.5. Als Nächstes möchten wir in der Datei modules/sns/outputs.tf den Topic-ARN ausgeben, damit wir ihn in der EventBridge-Konfiguration, die wir später vornehmen werden, referenzieren können.

output "sns_topic_arn" {
value = aws_sns_topic.gd_sns_topic.arn
description = "Output of ARN to call in the eventbridge rule."
}

5.6. Gehen Sie abschließend zurück zur Datei root/main.tf und fügen Sie das SNS-Thema hinzu. Hier geben Sie die E-Mail-Adresse für das Abonnement an.

# Creates an SNS Topic
module "guardduty_sns_topic" {
source = "./modules/sns"
email = "[email protected]"
}

In diesem Abschnitt haben Sie SNS-Themen erstellt, sodass Ihnen eine E-Mail zugesendet wird, wenn ein bestimmtes Ergebnis generiert wird.

Schritt 6: Erstellen Sie das EventBridge Terraform-Modul

In diesem Abschnitt erstellen Sie mithilfe von Terraform eine EventBridge-Regel. Die EventBridge-Regel verbindet die beiden Elemente dieser Lösung.

Wie funktioniert EventBridge? EventBridge empfängt ein Ereignis – einen Indikator für eine Änderung in der Umgebung – und leitet es mithilfe einer Regel an ein Ziel weiter. Regeln ordnen Ereignisse Zielen basierend auf der Ereignisstruktur (Ereignismuster) oder einem Zeitplan zu. In diesem Fall generiert GuardDuty ein Ereignis für Amazon EventBridge, sobald sich die Ergebnisse ändern. Das Ereignis wird zugeordnet, und Amazon EventBridge leitet die Regel an ein Ziel weiter. In diesem Fall ist das Ziel der Regel ein SNS-Dienst. Die SNS-Regel verwendet die gefundenen Daten und generiert eine E-Mail-Benachrichtigung an den Abonnenten.

6.1. Die EventBridge-Regel benötigt Informationen zu GuardDuty und SNS. Erstellen Sie zunächst eine Variable, die für den SNS-Subjekt-ARN verwendet werden kann. Fügen Sie dies in die Datei modules/eventbridge/variables.tf ein.

variable "sns_topic_arn" {
}

6.2. Erstellen Sie anschließend eine Ereignisregelquelle in der Datei modules/eventbridge/main.tf. Definieren Sie dazu die Quelle und den Typ des gewünschten Ereignisses.

 # EVENT RULE RESOURCE
resource "aws_cloudwatch_event_rule" "GuardDuty-Event-EC2-MaliciousIPCaller" {
name = "GuardDuty-Event-EC2-MaliciousIPCaller"
description = "GuardDuty Event: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom"
event_pattern = <<EOF
{
"source": ["aws.guardduty"],
"detail": {
"type": ["UnauthorizedAccess:EC2/MaliciousIPCaller.Custom"]
}
}
EOF
}

6.3. Definieren Sie als Nächstes die Ereigniszielquelle. Beim Erstellen dieser Quelle können Sie die Lesbarkeit der E-Mail-Benachrichtigung verbessern, indem Sie einen Eingabetransformator definieren. Dieser passt an, was EventBridge an das Ereignisziel sendet. Im Folgenden ermitteln wir die GuardDuty-ID, die Region und die EC2-Instanz-ID und erstellen eine Eingabevorlage, die die Nachricht kurz erläutert. Unten sehen Sie, dass wir eine Eingabevorlage erstellt haben, die die detaillierten Informationen aus dem GuardDuty-Ergebnis in der gesendeten E-Mail verwendet.

# EVENT TARGET RESOURCE FOR SNS NOTIFICATIONS
resource "aws_cloudwatch_event_target" "sns" {
rule = aws_cloudwatch_event_rule.GuardDuty-Event-EC2-MaliciousIPCaller.name
target_id = "GuardDuty-Example"
arn = var.sns_topic_arn
input_transformer {
input_paths = {
gdid = "$.detail.id",
region = "$.detail.region",
instanceid = "$.detail.resource.instanceDetails.instanceId"
}
input_template = "\"First GuardDuty Finding for the GuardDuty-IAC tutorial. | ID:<gdid> | The EC2 instance: <instanceid>, may be compromised and should be investigated. Go to https://console.aws.amazon.com/guardduty/home?region=<region>#/findings?macros=current&fId=<gdid>\""
}
}

6.4. In der ersten von uns erstellten Ereignisregel suchen wir nach dem Ereignis „GuardDuty-Event-EC2-MaliciousIPCaller“. Erstellen Sie eine zweite Ereignisregel, die nach dem Ereignis „GuardDuty-Event-IAMUser-MaliciousIPCaller“ sucht und auch hierfür eine E-Mail-Benachrichtigung versendet.

# EVENT RULE RESOURCE
resource "aws_cloudwatch_event_rule" "GuardDuty-Event-IAMUser-MaliciousIPCaller" {
name = "GuardDuty-Event-IAMUser-MaliciousIPCaller"
description = "GuardDuty Event: UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom"
event_pattern = <<EOF
{
"source": ["aws.guardduty"],
"detail": {
"type": ["UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom", "Discovery:S3/MaliciousIPCaller.Custom"]
}
}
EOF
}
#EVENT TARGET RESOURCE FOR SNS NOTIFICATIONS
resource "aws_cloudwatch_event_target" "iam-sns" {
rule = aws_cloudwatch_event_rule.GuardDuty-Event-IAMUser-MaliciousIPCaller.name
target_id = "GuardDuty-Example"
arn = var.sns_topic_arn
input_transformer {
input_paths = {
gdid = "$.detail.id",
region = "$.detail.region",
userName = "$.detail.resource.accessKeyDetails.userName"
} 
input_template = "\"Second GuardDuty Finding for the GuardDuty-IAC tutorial. | ID:<gdid> | AWS Region:<region>. An AWS API operation was invoked (userName: <userName>) from an IP address that is included on your threat list and should be investigated.Go to https://console.aws.amazon.com/guardduty/home?region=<region>#/findings?macros=current&fId=<gdid>\""
}
}

6.5. Sobald die Ressourcen im Modul erstellt wurden, gehen Sie zurück zur Datei root/main.tf und fügen Sie die EventBridge-Regel hinzu.

# Create the EventBridge rule
module "guardduty_eventbridge_rule" {
source = "./modules/eventbridge"
sns_topic_arn = module.guardduty_sns_topic.sns_topic_arn
}

In diesem Abschnitt haben Sie eine EventBridge-Regel erstellt, die das von Ihnen erstellte SNS-Thema verwendet, um eine E-Mail zu versenden, wenn GuardDuty-Ergebnisse übereinstimmen. Im nächsten Abschnitt erweitern Sie diese Funktionalität mithilfe von Lambda.

Schritt 7: Erstellen Sie das Lambda-Terraform-Modul

In diesem Abschnitt erstellen wir mithilfe von Terraform eine Lambda-Funktion, die eine Behebungsmaßnahme in unserer Umgebung durchführt. Ziel dieses Tutorials ist es, den kompromittierten Host in eine neue Sicherheitsgruppe zu verschieben. Ähnlich wie EventBridge SNS zur E-Mail-Generierung verwendet hat, kapselt EventBridge die Lambda-Funktion.

Wichtig ist, dass es hier viele Lösungsansätze gibt. Weitere Informationen finden Sie in der Dokumentation zu „Benutzerdefinierte Antworten auf GuardDuty-Ergebnisse mit Amazon CloudWatch Events erstellen“ und „Verdächtigen Datenverkehr mit AWS Network Firewall und Amazon GuardDuty automatisch blockieren“.

Bevor wir anfangen, wollen wir uns ansehen, was geschehen muss, damit dies gelingt.

Aktuell werden unsere GuardDuty-Ergebnisse einer EventBridge-Regel mit einem Ziel zugeordnet – derzeit einer SNS-Regel, die eine E-Mail versendet. Um diese Funktionalität zu verbessern, verwendet EventBridge AWS Lambda als Ziel.

Da wir im Namen von AWS Lambda auf andere Ressourcen zugreifen möchten, müssen wir eine IAM-Rolle erstellen, um dem Dienst Berechtigungen zu erteilen. Diese Rolle wird als Dienst bezeichnet, und AWS Lambda übernimmt diese Rolle, sobald wir die Sicherheitsgruppe unserer EC2-Instanz ändern.

Das Bild unten zeigt, wie die ersten drei Codeblöcke zusammenwirken, um dem AWS Lambda-Dienst die Übernahme einer Rolle zu ermöglichen, die Änderungen an den EC2-Instanzen zugewiesenen Sicherheitsgruppen vornehmen kann.

7.1. Erstellen Sie zunächst das IAM-Richtliniendokument in modules/lambda/main.tf. Dies ist die Vertrauensbeziehung für die Richtlinie.

data "aws_iam_policy_document" "GD-EC2MaliciousIPCaller-policy-document" {
statement {
effect = "Allow"
actions = ["sts:AssumeRole"]
principals {
type = "Service"
identifiers = ["lambda.amazonaws.com"]
}
}
}

7.2. Erstellen Sie anschließend eine Inline-Richtlinie, die für die Rolle gilt, die AWS Lambda übernehmen soll.

resource "aws_iam_role_policy" "GD-EC2MaliciousIPCaller-inline-role-policy" {
name = "GD-EC2MaliciousIPCaller-inline-role-policy"
role = aws_iam_role.GD-Lambda-EC2MaliciousIPCaller-role.id
policy = jsonencode({
"Version" : "2012-10-17",
"Statement" : [
{
"Action" : [
"ssm:PutParameter",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress",
"ec2:DescribeInstances",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress",
"ec2:DescribeVpcs",
"ec2:ModifyInstanceAttribute",
"lambda:InvokeFunction",
"cloudwatch:PutMetricData",
"xray:PutTraceSegments",
"xray:PutTelemetryRecords"
],
"Resource" : "*",
"Effect" : "Allow"
},
{
"Action" : [
"logs:*"
],
"Resource" : "arn:aws:logs:*:*:*",
"Effect" : "Allow"
},
{
"Action" : [
"sns:Publish"
],
"Resource" : var.sns_topic_arn,
"Effect" : "Allow"
} 
]
})
}

7.3. Und nun erstellen Sie die IAM-Rolle, die AWS Lambda übernehmen soll.

resource "aws_iam_role" "GD-Lambda-EC2MaliciousIPCaller-role" {
name = "GD-Lambda-EC2MaliciousIPCaller-role1"
assume_role_policy = data.aws_iam_policy_document.GD-EC2MaliciousIPCaller-policy-document.json
}

7.4. Erstellen Sie eine Datenquelle, die auf den Code verweist.

data "archive_file" "python_lambda_package" {
type = "zip"
source_file = "${path.module}/code/index.py"
output_path = "index.zip"
}

7.5. Als Nächstes müssen wir EventBridge Zugriff auf Lambda gewähren.

resource "aws_lambda_permission" "GuardDuty-Hands-On-RemediationLambda" {
statement_id = "GuardDutyTerraformRemediationLambdaEC2InvokePermissions"
action = "lambda:InvokeFunction"
function_name = aws_lambda_function.GuardDuty-Example-Remediation-EC2MaliciousIPCaller.function_name
principal = "events.amazonaws.com"
}

Der obige Block ermöglicht es EventBridge, die Lambda-Funktion aufzurufen.

7.6. Abschließend erstellen wir den Quellcode der Lambda-Funktion. Dazu benötigen wir einige Variablen, die es uns ermöglichen, Informationen zu übergeben. Bearbeiten Sie die Datei modules/lambda/variables.tf mit den folgenden Variablen:

variable "sns_topic_arn" {
}
variable "compromised_instance_id" {
}
variable "forensic_sg_id" {
}

7.7. Gehen Sie anschließend zurück zur Datei modules/lambda/main.tf und erstellen Sie den Quellcode der Lambda-Funktion. Beachten Sie, dass wir im folgenden Codeblock Python 3.9 verwenden. Wir referenzieren außerdem den Python-Code, den wir in index.zip gepackt haben. Abschließend definieren wir im Quellcode die Umgebungsvariablen INSTANCE_ID, FORENSICS_SG und TOPIC_ARN. Diese werden von den erstellten Variablen an die Umgebung unserer Lambda-Funktion übergeben.

# Create the Lambda function Resource
resource "aws_lambda_function" "GuardDuty-Example-Remediation-EC2MaliciousIPCaller" {
function_name = "GuardDuty-Example-Remediation-EC2MaliciousIPCaller"
filename = "index.zip"
source_code_hash = data.archive_file.python_lambda_package.output_base64sha256
role = aws_iam_role.GD-Lambda-EC2MaliciousIPCaller-role.arn
runtime = "python3.9"
handler = "index.handler"
timeout = 10
environment {
variables = {
INSTANCE_ID = var.compromised_instance_id
FORENSICS_SG = var.forensic_sg_id
TOPIC_ARN = var.sns_topic_arn
}
}
}

7.8. Rufen Sie in der Datei root/main.tf das Lambda-Modul auf und legen Sie den SNS-Subjekt-ARN, die ID der kompromittierten Instanz und die Gruppe „Forensische Sicherheit“ fest. Beachten Sie, dass diese Werte vom GuardDuty-Modul, dem Compute-Modul und dem VPC-Modul stammen.

# CREATE THE LAMBDA FUNCTION
module "lambda" {
source = "./modules/lambda"
sns_topic_arn = module.guardduty_sns_topic.sns_topic_arn
compromised_instance_id = module.compute.compromised_instance_id
forensic_sg_id = module.forensic-security-group.security_group_id
}

7.9. Es wurde noch keine Rechtssicherheitsgruppe erstellt. Fügen Sie eine Sicherheitsgruppe hinzu, die verwendet werden soll.

# CREATES THE FORENSICS_SG SECURITY GROUP
module "forensic-security-group" {
source = "terraform-aws-modules/security-group/aws"
version = "4.17.1"
name = "FORENSIC_SG"
description = "Forensic Security group "
vpc_id = module.iac_vpc.vpc_attributes.id
}

7.10. Um auf die Gruppe „security-legal“ zuzugreifen, muss deren ID ausgegeben werden. Fügen Sie dazu die Datei „root/outputs.tf“ hinzu.

output "forensic_sg_id" {
value = module.forensic-security-group.security_group_id
description = "Output of forensic sg id created - to place the EC2 instance(s)."
}

7.11. Nun müssen wir die EventBridge-Regel so konfigurieren, dass die gefundenen Daten an Lambda gesendet werden. Dies geschieht im nächsten Abschnitt. Öffnen Sie die Datei modules/eventbridge/main.tf. Fügen Sie eine Ereigniszielquelle für die Lambda-Funktion hinzu, die die Regel aws_cloudwatch_event_rule.GuardDuty-Event-EC2-MaliciousIPCaller.name prüft, und setzen Sie die Ziel-ID auf GuardDuty-Example-Remediation. Hierfür benötigen Sie den ARN der Lambda-Funktion. Dieser kann vom Lambda-Modul ausgegeben werden.

#EVENT TARGET RESOURCE FOR LAMBDA REMEDIATION FUNCTION
resource "aws_cloudwatch_event_target" "lambda_function" {
rule = aws_cloudwatch_event_rule.GuardDuty-Event-EC2-MaliciousIPCaller.name
target_id = "GuardDuty-Example-Remediation"
arn = var.lambda_remediation_function_arn
}

7.12. Falls Sie dies noch nicht getan haben, fügen Sie die Ausgabe dem Lambda-Modul hinzu (modules/lambda/outputs.tf).

output "lambda_remediation_function_arn" {
value = aws_lambda_function.GuardDuty-Example-Remediation-EC2MaliciousIPCaller.arn
}

7.13. Diese Variable sollte auch im EventBridge-Modul (modules/eventbridge/variables.tf) angewendet werden.

variable "lambda_remediation_function_arn" {
}

7.14. Fügen Sie abschließend `lambda_remediation_function_arn` zur Datei `root/main.tf` hinzu. Dies gehört in die zuvor erstellte EventBridge-Regel. Die folgende Ausgabe zeigt den gesamten Codeblock, von dem Teile bereits vorhanden sind. Achten Sie darauf, nur den Code `lambda_remediation_function_arn = module.lambda.lambda_remediation_function_arn` zum bestehenden Block hinzuzufügen.

module "guardduty_eventbridge_rule" {
source = "./modules/eventbridge"
sns_topic_arn = module.guardduty_sns_topic.sns_topic_arn
lambda_remediation_function_arn = module.lambda.lambda_remediation_function_arn
}

In diesem Abschnitt haben Sie eine Lambda-Funktion erstellt, die einen gefährdeten Host in eine separate Sicherheitsgruppe verschiebt. Diese Lambda-Funktion wird von EventBridge aufgerufen, wenn ein GuardDuty-Ergebnis mit einer EventBridge-Regel übereinstimmt. Im nächsten Abschnitt wenden Sie die gesamte Konfiguration an.

Schritt 8: Wenden Sie die Einstellungen auf Ihr AWS-Konto an.

8.1. Führen Sie `terraform init` aus. Dadurch werden alle Module initialisiert, die Sie in diesem Code-Tutorial hinzugefügt haben. Die Ausgabe sollte wie folgt aussehen.

8.2. Erstellen Sie einen Grundriss.

8.3. Um die Änderungen auf AWS anzuwenden, führen Sie eine Terraform-Anwendung aus. Nach der Anwendung sollte Ihre Ausgabe wie folgt aussehen:

In diesem Abschnitt haben Sie die Terraform-Konfiguration auf Ihr AWS-Konto angewendet. Aktuell kommunizieren zwei EC2-Instanzen miteinander. Eine davon ist bösartig, und ihre IP-Adresse wurde unserer Liste verdächtiger IP-Adressen hinzugefügt. Sobald GuardDuty feststellt, dass diese IP-Adresse mit unserer kompromittierten Instanz kommuniziert, wird ein entsprechender Befund erstellt. Eine EventBridge-Regel, die diesem Befund entspricht, führt zwei Aktionen aus: Erstens wird uns eine E-Mail mit dem Vorfall gesendet, und zweitens wird eine Lambda-Funktion aufgerufen, um die Sicherheitsgruppe des kompromittierten Hosts zu ändern. Im nächsten Abschnitt überprüfen wir die Konfiguration in unserer AWS-Konsole.

Schritt 9: Überprüfen Sie die Lösung in der AWS-Managementkonsole.

In diesem Abschnitt werden wir die gesamte Lösung in der AWS-Konsole überprüfen und sicherstellen, dass die Sicherheitsgruppe migriert wurde, wenn die Ergebnisse in GuardDuty angezeigt werden und EventBridge die Lambda-Funktion auslöst.

Sie sollten außerdem eine E-Mail zur Bestätigung Ihres Abonnements erhalten haben. Denken Sie daran, dass Sie sich anmelden müssen, um die von Ihnen konfigurierten Benachrichtigungen zu erhalten.

Nach der Anmeldung sollten Sie in der AWS Management Console überprüfen, ob zwei EC2-Instanzen vorhanden sind und ob sich beide in der primären Sicherheitsgruppe befinden.

Zuerst sollte geprüft werden, ob die Hosts kompromittiert sind.

Überprüfen Sie anschließend, ob schädliche Hosts vorhanden sind.

Stellen Sie anschließend sicher, dass GuardDuty die Ergebnisse meldet.

Überprüfen Sie nun, was die EventBridge-Regel gefunden hat.

Überprüfen Sie anschließend das EventBridge-Regelziel. Dort sollten Sie ein SNS-Ziel und ein Lambda-Ziel sehen.

Prüfen Sie die SNS-Regel, um deren Funktion zu verstehen. Sie sollte eine E-Mail an die von Ihnen angegebene Adresse senden.

Überprüfen Sie anschließend die Lambda-Funktion. Sie können diese über die EventBridge-Regel oder direkt über die Navigation erreichen.

Überprüfen Sie abschließend, ob die Lambda-Funktion den kompromittierten Host in eine neue Sicherheitsgruppe verschoben hat.

Je nachdem, wie lange Sie gewartet haben, und falls Ihre Konfiguration mit den obigen Screenshots übereinstimmt, haben Sie erfolgreich eine vollständige AWS-Sicherheitslösung mit Terraform erstellt.