View a markdown version of this page

Unterdrückungsregeln in GuardDuty - Amazon GuardDuty
Verwendung von Unterdrückungsregeln mit Extended Threat DetectionHäufige Anwendungsfälle für Unterdrückungsregeln und Beispiele

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Unterdrückungsregeln in GuardDuty

Eine Unterdrückungsregel ist eine Reihe von Kriterien, die zum Filtern von Erkenntnissen verwendet werden, indem neue Erkenntnisse, die den angegebenen Kriterien entsprechen, automatisch archiviert werden. Unterdrückungsregeln können verwendet werden, um Ergebnisse mit niedrigem Wert, falsch positive Ergebnisse oder Bedrohungen zu filtern, auf die Sie nicht reagieren möchten, sodass die Sicherheitsbedrohungen mit den meisten Auswirkungen auf Ihre Umgebung leichter zu erkennen sind.

Nachdem Sie eine Unterdrückungsregel erstellt haben, werden neue Ergebnisse, die den in der Regel definierten Kriterien entsprechen, automatisch archiviert, solange die Unterdrückungsregel gültig ist. Sie können einen vorhandenen Filter verwenden, um eine Unterdrückungsregel zu erstellen, oder einen neuen Filter für die Unterdrückungsregel definieren, während Sie sie erstellen. Sie können Unterdrückungsregeln so konfigurieren, dass ganze Ergebnistypen unterdrückt werden, oder detailliertere Filterkriterien definieren, damit nur bestimmte Instances eines bestimmten Ergebnistyps unterdrückt werden. Sie können die Unterdrückungsregeln jederzeit bearbeiten.

Unterdrückte Ergebnisse werden nicht an Amazon Simple Storage Service AWS Security Hub CSPM, Amazon Detective oder Amazon gesendet. Dadurch wird das Störgeräusch reduziert EventBridge, wenn Sie die GuardDuty Ergebnisse über Security Hub CSPM, ein SIEM eines Drittanbieters oder andere Warn- und Ticketing-Anwendungen nutzen. Wenn Sie diese Option aktiviert habenMalware-Schutz für EC2, wird aufgrund der unterdrückten GuardDuty Ergebnisse kein Malware-Scan ausgelöst.

GuardDuty generiert weiterhin Ergebnisse, auch wenn sie Ihren Unterdrückungsregeln entsprechen. Diese Ergebnisse werden jedoch automatisch als archiviert markiert. Das archivierte Ergebnis wird 90 Tage lang gespeichert und kann in GuardDuty diesem Zeitraum jederzeit eingesehen werden. Sie können die unterdrückten Ergebnisse in der GuardDuty Konsole anzeigen, indem Sie in der Ergebnistabelle die Option Archiviert auswählen, oder verwenden Sie die ListFindings API mit dem findingCriteria Kriterium „Wahrservice.archived“. GuardDuty

Anmerkung

In einer Umgebung mit mehreren Konten kann nur der GuardDuty Administrator Unterdrückungsregeln erstellen.

Verwendung von Unterdrückungsregeln mit Extended Threat Detection

GuardDuty Extended Threat Detection erkennt automatisch mehrstufige Angriffe, die sich über Datenquellen, mehrere Arten von AWS Ressourcen und Zeiträume erstrecken, innerhalb eines AWS-Konto. Es korreliert Ereignisse aus verschiedenen Datenquellen, um Szenarien zu identifizieren, die sich als potenzielle Bedrohung für Ihre AWS Umgebung darstellen, und generiert dann eine Analyse der Angriffssequenz. Weitere Informationen finden Sie unter So funktioniert Extended Threat Detection.

Wenn Sie Unterdrückungsregeln erstellen, mit denen Ergebnisse archiviert werden, kann Extended Threat Detection diese archivierten Ergebnisse nicht verwenden, um Ereignisse für Angriffssequenzen zu korrelieren. Umfassende Unterdrückungsregeln können die Fähigkeit beeinträchtigen, Verhaltensweisen GuardDuty zu erkennen, die mit der Erkennung mehrstufiger Angriffe einhergehen. Ergebnisse, die aufgrund von Unterdrückungsregeln archiviert werden, gelten nicht als Signale für Angriffssequenzen. Wenn Sie beispielsweise eine Unterdrückungsregel erstellen, die alle EKS-Cluster-bezogenen Ergebnisse archiviert, anstatt auf bestimmte bekannte Aktivitäten abzuzielen, können Sie diese Ergebnisse GuardDuty nicht verwenden, um eine Angriffssequenz zu erkennen, bei der ein Bedrohungsakteur einen Container ausnutzt, privilegierte Token erhält und auf vertrauliche Ressourcen zugreift.

Beachten Sie die folgenden Empfehlungen von: GuardDuty

  • Verwenden Sie weiterhin Unterdrückungsregeln, um Warnmeldungen aufgrund bekannter vertrauenswürdiger Aktivitäten zu reduzieren.

  • Konzentrieren Sie sich bei den Unterdrückungsregeln auf bestimmte Verhaltensweisen, für die Sie keine Ergebnisse generieren GuardDuty möchten.

Häufige Anwendungsfälle für Unterdrückungsregeln und Beispiele

Die folgenden Ergebnisarten haben häufig Anwendungsfälle für die Anwendung von Unterdrückungsregeln. Wählen Sie den Namen des Ergebnisses aus, um mehr über das Ergebnis zu erfahren. Lesen Sie die Beschreibung des Anwendungsfalls, um zu entscheiden, ob Sie eine Unterdrückungsregel für diesen Befundtyp erstellen möchten.

Wichtig

GuardDuty empfiehlt, Unterdrückungsregeln reaktiv und nur für Ergebnisse zu erstellen, für die Sie in Ihrer Umgebung wiederholt Fehlalarme identifiziert haben.

  • UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS – Verwenden Sie eine Unterdrückungsregel, die automatisch Erkenntnisse archiviert, die generiert werden, falls das VPC-Netzwerk so konfiguriert ist, dass der Internet-Datenverkehr über ein On-Premises-Gateway anstelle eines VPC-Internet-Gateways weitergeleitet wird.

    Diese Erkenntnis wird generiert, wenn das Netzwerk so konfiguriert ist, dass der Internetverkehr von einem On-Premises-Gateway und nicht von einem VPC Internet Gateway (IGW) ausgeht. Geläufige Konfigurationen, z. B. die Verwendung von AWS Outposts, oder VPC-VPN-Verbindungen, können dazu führen, dass Datenverkehr auf diese Weise weitergeleitet wird. Wenn dieses Verhalten erwartet wird, wird empfohlen, Unterdrückungsregeln zu verwenden und eine Regel zu erstellen, die aus zwei Filterkriterien besteht. Das erste Kriterium ist der Erkenntnistyp, der UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS sein sollte. Das zweite Filterkriterium ist die IPv4-Adresse des API-Aufrufers mit der IP-Adresse oder dem CIDR-Bereich Ihres On-Premises-Internet-Gateways. Das folgende Beispiel stellt den Filter dar, den Sie verwenden würden, um diesen Erkenntnistyp auf der Grundlage der IP-Adresse des API-Aufrufers zu unterdrücken.

    Finding type: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS API caller IPv4 address: 198.51.100.6
    Anmerkung

    Um mehrere API-Aufrufer-IPs einzubeziehen, können Sie jede IP-Adresse zur Werteliste für Gleich oder NotEquals Bedingungen hinzufügen oder Platzhaltermuster für Übereinstimmungen oder Bedingungen verwenden. NotMatches

  • Recon:EC2/Portscan – Verwenden Sie eine Unterdrückungsregel, um Erkenntnisse automatisch zu aktivieren, wenn Sie eine Anwendung für Schwachstellenanalysen verwenden.

    Die Unterdrückungsregel sollte aus zwei Filterkriterien bestehen. Das erste Kriterium sollte das Attribut Erkenntnistyp mit dem Wert Recon:EC2/Portscan verwenden. Das zweite Filterkriterium sollte den Instances entsprechen, die diese Tools zur Schwachstellenanalyse hosten. Sie können entweder das Attribut Instance-Image-ID oder das Attribut Tag verwenden, abhängig davon, welches Kriterium mit den Instances identifiziert werden kann, die diese Tools hosten. Das folgende Beispiel stellt den Filter dar, den Sie verwenden würden, um diesen Erkenntnistyp auf der Grundlage von Instances mit einem bestimmten AMI zu unterdrücken.

    Finding type: Recon:EC2/Portscan Instance image ID: ami-999999999

  • UnauthorizedAccess:EC2/SSHBruteForce – Verwenden Sie eine Unterdrückungsregel, um Erkenntnisse, die sich auf Bastion-Instances beziehen, automatisch zu archivieren.

    Wenn das Ziel des Brute-Force-Versuchs ein Bastion-Host ist, kann dies das erwartete Verhalten in Ihrer Umgebung darstellen. AWS In diesem Fall sollten Sie für diese Erkenntnis eine Unterdrückungsregel einrichten. Die Unterdrückungsregel sollte aus zwei Filterkriterien bestehen. Das erste Kriterium sollte das Attribut Erkenntnistyp mit dem Wert UnauthorizedAccess:EC2/SSHBruteForce verwenden. Das zweite Filterkriterium sollte der oder den Instances entsprechen, die als Bastion-Host eingesetzt werden. Sie können entweder das Attribut Instance-Image-ID oder das Attribut Tag verwenden, abhängig davon, welches Kriterium mit den Instances identifiziert werden kann, die diese Tools hosten. Das folgende Beispiel stellt den Filter dar, den Sie verwenden würden, um diesen Erkenntnistyp auf der Grundlage von Instances mit einem bestimmten Instance-Tag-Wert zu unterdrücken.

    Finding type: UnauthorizedAccess:EC2/SSHBruteForce Instance tag value: devops

  • Recon:EC2/PortProbeUnprotectedPort – Verwenden Sie eine Unterdrückungsregel, um Erkenntnisse automatisch zu archivieren, wenn sie auf absichtlich exponierte Instances ausgerichtet ist.

    In einigen Fällen werden Instances absichtlich exponiert, weil sie beispielsweise Webserver hosten. Wenn dies in Ihrer AWS Umgebung der Fall ist, empfehlen wir Ihnen, eine Unterdrückungsregel für diesen Befund einzurichten. Die Unterdrückungsregel sollte aus zwei Filterkriterien bestehen. Das erste Kriterium sollte das Attribut Erkenntnistyp mit dem Wert Recon:EC2/PortProbeUnprotectedPort verwenden. Das zweite Filterkriterium sollte der oder den Instances entsprechen, die als Bastion-Host eingesetzt werden. Sie können entweder das Attribut Instance-Image-ID oder das Attribut Tag verwenden, abhängig davon, welches Kriterium mit den Instances identifiziert werden kann, die diese Tools hosten. Das folgende Beispiel stellt den Filter dar, den Sie verwenden würden, um diesen Erkenntnistyp auf der Grundlage von Instances mit einem bestimmten Instance-Tag-Schlüssel in der Konsole zu unterdrücken.

    Finding type: Recon:EC2/PortProbeUnprotectedPort Instance tag key: prod

Empfohlene Unterdrückungsregeln für Ergebnisse der Laufzeitüberwachung

  • PrivilegeEscalation:Runtime/DockerSocketAccessed wird generiert, wenn ein Prozess in einem Container mit dem Docker-Socket kommuniziert. Möglicherweise gibt es Container in Ihrer Umgebung, die aus legitimen Gründen auf den Docker-Socket zugreifen müssen. Der Zugriff von solchen Containern generiert PrivilegeEscalation:Runtime/DockerSocketAccessed-Erkenntnisse. Wenn dies in Ihrer AWS Umgebung der Fall ist, empfehlen wir Ihnen, eine Unterdrückungsregel für diesen Ergebnistyp einzurichten. Das erste Kriterium sollte das Attribut Erkenntnistyp mit dem Wert PrivilegeEscalation:Runtime/DockerSocketAccessed verwenden. Das zweite Filterkriterium ist das Feld Ausführbarer Pfad mit einem Wert, der dem Wert des Prozesses executablePath in der generierten Erkenntnis entspricht. Alternativ kann das zweite Filterkriterium das SHA-256 Feld Ausführbar verwenden, dessen Wert dem Wert des Prozesses executableSha256 im generierten Ergebnis entspricht.

  • Kubernetes-Cluster führen ihre eigenen DNS-Server als Pods aus, z. B. coredns. Daher werden bei jeder DNS-Suche aus einem Pod zwei DNS-Ereignisse GuardDuty erfasst — eines aus dem Pod und das andere aus dem Server-Pod. Dadurch können Duplikate für die folgenden DNS-Erkenntnisse generiert werden:

    Die doppelten Erkenntnisse umfassen Pod-, Container- und Prozessdetails, die Ihrem DNS-Server-Pod entsprechen. Sie können mithilfe dieser Felder eine Unterdrückungsregel einrichten, um diese doppelten Erkenntnisse zu unterdrücken. Die ersten Filterkriterien sollten das Feld Erkenntnistyp verwenden, dessen Wert einem DNS-Erkenntnistyp aus der Liste der Erkenntnisse entspricht, die weiter oben in diesem Abschnitt bereitgestellt wurde. Das zweite Filterkriterium könnte entweder der Pfad der ausführbaren Datei mit dem Wert Ihres DNS-Servers executablePath oder die Ausführbare Datei SHA-256 mit einem Wert sein, der dem Wert Ihres DNS-Servers executableSHA256 im generierten Ergebnis entspricht. Als optionales drittes Filterkriterium können Sie das Feld Kubernetes-Container-Image verwenden, dessen Wert dem Container-Image Ihres DNS-Server-Pods in der generierten Erkenntnis entspricht.