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.
# Beispiele für die Suche und Behebung von Sicherheitslücken
Dieser Abschnitt enthält Beispiele für den Triage-Prozess für die Sicherheits-, Cloud- und Anwendungsteams. Es werden die Arten von Ergebnissen erörtert, mit denen sich jedes Team üblicherweise befasst, und es wird ein Beispiel dafür gegeben, wie darauf reagiert werden kann. Umfassende Anleitungen zur Problembehebung sind ebenfalls enthalten.
**Topics**
+ [Beispiel für ein Sicherheitsteam: Erstellen einer Security Hub CSPM-Automatisierungsregel](security-team-example.md)
+ [Beispiel für ein Cloud-Team: VPC-Konfigurationen ändern](cloud-team-example.md)
+ [Beispiel für ein Anwendungsteam: Eine Regel erstellen AWS Config](application-team-example.md)
# Beispiel für ein Sicherheitsteam: Erstellen einer Security Hub CSPM-Automatisierungsregel
Das Sicherheitsteam erhält Erkenntnisse im Zusammenhang mit der Erkennung von Bedrohungen, einschließlich der GuardDuty Ergebnisse von Amazon. Eine vollständige Liste der GuardDuty Findetypen, die nach AWS Ressourcentyp kategorisiert sind, [finden Sie in der GuardDuty Dokumentation unter Finding types](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html). Sicherheitsteams müssen mit all diesen Befundtypen vertraut sein.
In diesem Beispiel akzeptiert das Sicherheitsteam die Höhe des damit verbundenen Risikos für Sicherheitslücken in einer Anlage AWS-Konto , die ausschließlich zu Lernzwecken verwendet wird und keine wichtigen oder sensiblen Daten enthält. Der Name dieses Kontos ist`sandbox`, und die Konto-ID ist`123456789012`. Das Sicherheitsteam kann eine AWS Security Hub CSPM Automatisierungsregel erstellen, die alle GuardDuty Ergebnisse dieses Kontos unterdrückt. Sie können entweder eine Regel anhand einer Vorlage erstellen, die viele gängige Anwendungsfälle abdeckt, oder sie können eine benutzerdefinierte Regel erstellen. In Security Hub CSPM empfehlen wir, eine Vorschau der Ergebnisse der Kriterien anzuzeigen, um sicherzustellen, dass die Regel die beabsichtigten Ergebnisse zurückgibt.
**Anmerkung**
Dieses Beispiel verdeutlicht die Funktionalität von Automatisierungsregeln. Wir empfehlen nicht, alle GuardDuty Ergebnisse für ein Konto zu unterdrücken. Der Kontext ist wichtig, und jedes Unternehmen muss anhand von Datentyp, Klassifizierung und Schutzmaßnahmen entscheiden, welche Ergebnisse unterdrückt werden sollen.
Die folgenden Parameter wurden verwendet, um diese Automatisierungsregel zu erstellen:
+ **Regel:**
+ **Der Name der Regel** ist `Suppress findings from Sandbox account`
+ **Die Beschreibung der Regel** ist `Date: 06/25/23 Authored by: John Doe Reason: Suppress GuardDuty findings from the sandbox account`
+ **Kriterien:**
+ `AwsAccountId` = `123456789012`
+ `ProductName` = `GuardDuty`
+ `WorkflowStatus` = `NEW`
+ `RecordState` = `ACTIVE`
+ **Automatisierte Aktion:**
+ `Workflow.status` ist `SUPPRESSED`
Weitere Informationen finden Sie unter [Automatisierungsregeln](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html) in der Security Hub CSPM-Dokumentation. Sicherheitsteams haben viele Möglichkeiten, die Ergebnisse erkannter Bedrohungen zu untersuchen und zu korrigieren. Umfassende Anleitungen finden Sie im [Leitfaden zur Reaktion auf AWS Sicherheitsvorfälle](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html). Wir empfehlen, diesen Leitfaden zu lesen, um sicherzustellen, dass Sie über solide Verfahren zur Reaktion auf Vorfälle verfügen.
# Beispiel für ein Cloud-Team: VPC-Konfigurationen ändern
Das Cloud-Team ist dafür verantwortlich, Sicherheitsfeststellungen zu analysieren und zu korrigieren, die gemeinsame Trends aufweisen, wie z. B. Änderungen der AWS Standardeinstellungen, die möglicherweise nicht zu Ihrem Anwendungsfall passen. Diese Ergebnisse wirken sich in der Regel auf viele AWS-Konten unserer Ressourcen aus, z. B. VPC-Konfigurationen, oder sie beinhalten eine Einschränkung, die für die gesamte Umgebung gelten sollte. In den meisten Fällen nimmt das Cloud-Team manuelle, einmalige Änderungen vor, z. B. das Hinzufügen oder Aktualisieren einer Richtlinie.
Nachdem Ihr Unternehmen eine AWS Umgebung für einige Zeit genutzt hat, stellen Sie möglicherweise fest, dass sich eine Reihe von Anti-Pattern-Angriffen herausbilden. Ein *Anti-Pattern* ist eine häufig verwendete Lösung für ein wiederkehrendes Problem, bei dem die Lösung kontraproduktiv, ineffektiv oder weniger wirksam als eine Alternative ist. Als Alternative zu diesen Anti-Pattern kann Ihr Unternehmen umgebungsweite Einschränkungen verwenden, die effektiver sind, wie z. B. Richtlinien zur AWS Organizations Dienststeuerung (SCPs) oder IAM Identity Center-Berechtigungssätze. SCPs und Berechtigungssätze können zusätzliche Einschränkungen für Ressourcentypen vorsehen, z. B. verhindern, dass Benutzer einen öffentlichen Amazon Simple Storage Service (Amazon S3) -Bucket konfigurieren. Obwohl es verlockend sein kann, alle möglichen Sicherheitskonfigurationen einzuschränken, gibt es doch Größenbeschränkungen für Richtlinien SCPs und Berechtigungssätze. Wir empfehlen einen ausgewogenen Ansatz für präventive und detektive Kontrollen.
Im Folgenden sind einige Kontrollen aus dem [FSBP-Standard ( AWS Security Hub CSPM Foundational Security Best Practices) aufgeführt](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html), für die das Cloud-Team möglicherweise verantwortlich ist:
+ [[EC2.2] Die VPC-Standardsicherheitsgruppe sollte keinen eingehenden und ausgehenden Datenverkehr zulassen](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)
+ [[EC2.6] Die VPC-Flow-Protokollierung sollte in allen aktiviert sein VPCs](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-6)
+ [[EC2.23] Amazon EC2 Transit Gateways sollte VPC-Anhangsanfragen nicht automatisch akzeptieren](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-23)
+ [[CloudTrail.1] CloudTrail sollte aktiviert und mit mindestens einem multiregionalen Trail konfiguriert sein, der Lese- und Schreibverwaltungsereignisse umfasst](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudtrail-controls.html#cloudtrail-1)
+ [[Config.1] AWS Config sollte aktiviert sein](https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html#config-1)
In diesem Beispiel befasst sich das Cloud-Team mit einem Ergebnis für die FSBP-Kontrolle EC2 .2. In der [Dokumentation](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2) zu diesem Steuerelement wird empfohlen, nicht die Standardsicherheitsgruppe zu verwenden, da sie einen breiten Zugriff über die Standardregeln für eingehende und ausgehende Nachrichten ermöglicht. Da die Standardsicherheitsgruppe nicht gelöscht werden kann, wird empfohlen, die Regeleinstellungen zu ändern, um den eingehenden und ausgehenden Verkehr einzuschränken. Um dieses Problem effizient zu lösen, sollte das Cloud-Team etablierte Mechanismen verwenden, um die Sicherheitsgruppenregeln für alle zu ändern, VPCs da jede VPC über diese Standardsicherheitsgruppe verfügt. In den meisten Fällen verwalten Cloud-Teams VPC-Konfigurationen mithilfe von [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)Anpassungen oder einem IaC-Tool (Infrastructure as Code) wie oder. [https://www.terraform.io/](https://www.terraform.io/)
# Beispiel für ein Anwendungsteam: Eine Regel erstellen AWS Config
Im Folgenden finden Sie einige Kontrollen aus dem Sicherheitsstandard [FSBP (Foundation Security Best Practices) von Security](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) Hub CSPM, für die das Anwendungs- oder Entwicklungsteam möglicherweise verantwortlich ist:
+ [[CloudFront.1] Für CloudFront Distributionen sollte ein Standard-Root-Objekt konfiguriert sein](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1)
+ [[EC2.19] Sicherheitsgruppen sollten keinen uneingeschränkten Zugriff auf Ports mit hohem Risiko zulassen](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)
+ [[CodeBuild.1] CodeBuild GitHub oder das Bitbucket-Quell-Repository sollte Folgendes verwenden URLs OAuth](https://docs.aws.amazon.com/securityhub/latest/userguide/codebuild-controls.html#codebuild-1)
+ [[ECS.4] ECS-Container sollten ohne Zugriffsrechte ausgeführt werden](https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-4)
+ [[ELB.1] Application Load Balancer sollte so konfiguriert sein, dass alle HTTP-Anfragen an HTTPS umgeleitet werden](https://docs.aws.amazon.com/securityhub/latest/userguide/elb-controls.html#elb-1)
In diesem Beispiel befasst sich das Anwendungsteam mit einem Ergebnis für FSBP Control .19. EC2 Dieses Steuerelement prüft, ob uneingeschränkter eingehender Verkehr für die Sicherheitsgruppen über die angegebenen Ports mit dem höchsten Risiko zugänglich ist. Diese Kontrolle schlägt fehl, wenn eine der Regeln in einer Sicherheitsgruppe eingehenden Datenverkehr von `0.0.0.0/0` oder `::/0` für diese Ports zulässt. In der [Dokumentation](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19) zu diesem Steuerelement wird empfohlen, die Regeln zu löschen, die diesen Datenverkehr zulassen.
Dies geht nicht nur auf die individuelle Sicherheitsgruppenregel ein, sondern ist auch ein hervorragendes Beispiel für ein Ergebnis, das zu einer neuen AWS Config [Regel](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) führen sollte. Durch die Verwendung des [proaktiven Testmodus](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html#aws-config-rules-evaluation-modes) können Sie verhindern, dass in future riskante Sicherheitsgruppenregeln eingesetzt werden. Im proaktiven Modus werden Ressourcen vor ihrer Bereitstellung bewertet, sodass Sie falsch konfigurierte Ressourcen und die damit verbundenen Sicherheitserkenntnisse verhindern können. Bei der Implementierung eines neuen Dienstes oder einer neuen Funktionalität können Anwendungsteams im Rahmen ihrer CI/CD-Pipeline (Continuous Integration and Continuous Delivery) Regeln im proaktiven Modus ausführen, um Ressourcen zu identifizieren, die nicht den Vorschriften entsprechen. Die folgende Abbildung zeigt, wie Sie eine proaktive AWS Config Regel verwenden können, um zu überprüfen, ob die in einer AWS CloudFormation Vorlage definierte Infrastruktur konform ist.
![\[Eine proaktive AWS Config Regel, die eine AWS CloudFormation Vorlage auf Konformität überprüft\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/vulnerability-management/images/cloudformation-config-proactive-workflow.png)
In diesem Beispiel kann eine weitere wichtige Effizienz erzielt werden. Wenn ein Anwendungsteam eine proaktive AWS Config Regel erstellt, kann es sie in einem gemeinsamen Code-Repository teilen, sodass andere Anwendungsteams sie verwenden können.
Jedes Ergebnis, das mit einem Security Hub CSPM-Steuerelement verknüpft ist, enthält Details zum Ergebnis und einen Link zu Anweisungen zur Behebung des Problems. Cloud-Teams können zwar auf Ergebnisse stoßen, die gegebenenfalls eine manuelle, einmalige Behebung erfordern, wir empfehlen jedoch, proaktive Prüfungen durchzuführen, um Probleme so früh wie möglich im Entwicklungsprozess zu identifizieren.