Laut Best-Practice-Leitfaden ITIL ist eine Störung „ein Ereignis, das nicht zum standardmäßigen Betrieb eines Services gehört und das eine Unterbrechung oder eine Minderung der Qualität verursacht.“ Im Ernstfall kommt es auf jede Sekunde an, um ein Ausbreiten des Schadens zu verhindern. Doch IT-Abteilungen sind oft überlastet. In diesem Leitfaden erklären wir, wie Sie mit der Self-Service-Ressourcenisolierung den Aufwand deutlich reduzieren.
Ressourcenisolierung ist eine Methode zur Behebung von Sicherheitsvorfällen in der IT und auch in der AWS Cloud Best Practice. Sicherheitsvorfälle können dabei in zwei Domänen auftreten, der Service- und der Infrastrukturdomain. Auch mit einigen bestehenden Services kann AWS Cloud-Aktivitäten protokollieren, überwachen und sicherheitsrelevante Ereignisse erkennen, etwa mit Amazon CloudTrail, Amazon CloudWatch, Amazon S3-Zugriffsprotokolle, VPC-Flussprotokolle, Amazon GuardDuty, Amazon Detective, AWS Security Hub und Amazon Macie.
Security Orchestration, Automation and Response, kurz SOAR, ist der Schlüssel zum effektiven Incident Management. SOAR-Funktionen bestehen aus drei Komponenten für effizientere Security Operations: dem Bedrohungs- und Schwachstellenmanagement, einer standardisierten Reaktion auf Sicherheitsvorfälle, dem sogenannten Runbook, und der Automatisierung von Sicherheitsoperationen. Genau diese leistet auch die automatische Ressourcenisolierung in der AWS Cloud.
Die Auswirkungen eines Vorfalls in der Servicedomain können schwerwiegend sein und zu Unterbrechungen wichtiger Dienste, enormen Unannehmlichkeiten für Endbenutzer und oft sogar Imageschäden für Unternehmen führen. Im Amazon-Kosmos können sich Servicedomain-Vorfälle auf das AWS-Konto eines Kunden auswirken, aber auch auf Berechtigungen aus dem Identity und Access Management (IAM), auf Metadaten von Ressourcen und die Abrechnung. Wenn Angreifer Zugriff auf das IAM-Konto erhalten, können sie auch APIs, also zwischengeschaltete Programmier-Schnittstellen zum Datenaustausch (von Englisch Application Programming Interface) missbrauchen, um das bestehende Setup zu stören.
Zu den möglichen Folgen eines Vorfalls in der Infrastrukturdomain zählen Betriebsausfälle, Datendiebstahl und Compliance-Verstöße. Das kann IT-Infrastrukturen, aber auch IT-Prozesse umfassen. Je nachdem, wie schwer der Verstoß war und welche Branche betroffen ist, können solche Vorfälle gemäß Datenschutz-Grundverordnung (DSGVO) meldepflichtig sein und erhebliche Geldbußen durch die EU-Datenschutzbehörden nach sich ziehen. Entsprechende Vorfälle umfassen daten- oder netzwerkbezogene Aktivitäten, wie den Verkehr zu Amazon EC2-Instanzen innerhalb der VPC, Prozesse und Daten auf Amazon EC2-Instanzen und andere Bereiche und Services, etwa Container.
Wurde ein Leck entdeckt und es kommt zur Untersuchung durch das IT Incident Management, kann es helfen, wenn wir betroffene Ressourcen gezielt isolieren. So werden die potenziellen Auswirkungen im Idealfall gemindert und Angreifer können nicht auf weitere Ressourcen zugreifen. Vermeiden lässt sich so auch, Daten unbeabsichtigt offen zu legen oder anderen den Zugriff darauf zu ermöglichen.
Mithilfe einer Sicherheits-API und manuell kodierter Schritte ist es möglich, den Aufwand für Mitarbeitende der IT-Abteilung und die benötigte Zeit erheblich zu reduzieren. Die Reaktionsteams können dann die API aufrufen, um das Problem zu beheben. Im Laufe der Zeit können wir dann per SOAR weitere Schritte automatisieren und weitere Runbooks implementieren. Schließlich lassen sich auf diese Weise verschiedene Klassen von häufigen Vorfällen automatisch verarbeiten.
Im Zentrum der Lösung steht die Isolierung von IAM-Benutzern und EC2-Ressourcen in AWS-Konten. Die Basis dafür: hochsichere REST-APIs, die Standardbenachrichtigungen für Betriebsteams sowie Konto- und Anwendungsbesitzer integrieren. Die Lösung setzt einen standardisierten Bereitstellungsworkflow ein und verwaltet die Ressourcen als Infrastruktur as Code (IaC). Das heißt: Die eingesetzte Hardware wird in maschinenlesbarem Code beschrieben. So lassen sich Aufbau und Management der IT-Infrastruktur, Cyber Security und Incident Management stark automatisieren, zum Beispiel um schneller auf neue Anforderungen reagieren zu können. Das folgende Architektur-Flussdiagramm veranschaulicht den Lösungsansatz.
On receiving an incident for resource isolation:
Das passiert, wenn es zu einem Vorfall mit Ressourcenisolierung kommt:
Das Architektur-Flussdiagramm zeigt, dass die API-basierte Lösung auf verschiedenen AWS-Ressourcen fußt. Diese werden mit Terraform als IaC bereitgestellt und verwaltet. Wir definieren einen Standard-CI/CD-Ansatz mit unterschiedlichen Umgebungen für Entwicklung, Tests und Produktionseinsatz. Den gesamten, in der Entwicklungsumgebung entwickelten und geprüftem Code führen wir korrekt zusammen und stellen ihn in der Testumgebung bereit, um die Lösung mit funktionalen Testfällen zu validieren. Sind die Tests erfolgreich, wird das ganze Setting in der Produktionsumgebung ausgeführt. Anschließend wird die Self-Service-API für die Reaktion auf Sicherheitsvorfälle aktiviert.
Indem wir Incident Response Runbooks für Nutzer kodieren und gültigen Nutzern die API oder Anwendungen bereitstellen, erzielen wir folgende Vorteile bei der Reaktion auf Sicherheits-Zwischenfälle für das Incident Management:
AWS CAF, der AWS Security Incident Response Guide und das Well-Architected Framework empfehlen Kunden, bekannte Verfahren für die Reaktion auf Vorfälle zu formulieren und ihre Runbooks schon vor einer Störung oder einem Problem zu testen. Die Prozesse präventiv zu testen, verkürzt die Reaktionszeit in einer Produktionsumgebung und kann so große Schäden verhindern.
Wenn Unternehmen Prozesse in festgelegten Code und Infrastruktur kodieren, können Sie sich schon beim Sammeln von Artefakten auf die Datenerfassung vorbereiten. Die Kodierung standardisiert den Erfassungsprozess und sorgt für eine wiederholbare und überprüfbare Abfolge: Welche Informationen wurden wann und wie erfasst? So wird weniger wahrscheinlich, dass es für zukünftige Untersuchungen an Daten mangelt. Die richtigen Analytics sind elementar für eine umfassende Threat Intelligence und reaktionsschnelles Incident Management.
Wir haben den Isolierungsprozess für IAM-Benutzer und EC2-Instanzen für den aktuellen Status entwickelt. Zudem können wir weiter Runbooks automatisieren und als weiteres Feature implementieren. Indem wir verschiedene Funktionen in dieselbe API integrieren, schaffen wir einheitliche Sicherheitskonfigurationen und Entwicklungsprozesse. So können wir alle Funktionen als REST-APIs bereitstellen und in andere Anwendungen und Systeme integrieren.
