Automatisierte Reaktion auf Sicherheitsvorfälle

Datenschutz in Clouds und digitalen Plattformen ist unsere Kernaufgabe bei Alice&Bob.Company. Wir versuchen, jeden Aspekt Ihrer Cloud-Infrastruktur abzusichern, damit Sie Ihre Anwendungen schnell, zuverlässig und so sicher wie möglich bereitstellen können. Einer der wichtigsten Schritte zum Erreichen dieser Ziele besteht darin, bei der Denkweise aller Beteiligten anzusetzen. Sicherheit sollte nicht als Zustand betrachtet werden, sondern als kontinuierlicher Prozess. Selbst wenn alle Best Practices befolgt werden und das ausgefeilteste Intrusion Prevention-System vorhanden ist, kann ein System immer noch unbekannten Zero-Day-Exploits, schwerwiegenden Bugs oder einfach menschlicher Unachtsamkeit zum Opfer fallen. Eine strenge und gut gepflegte Sicherheitslage kann mögliche Schäden minimieren, aber dennoch ist ein Plan zum Umgang mit Verstößen absolut notwendig (obwohl hoffentlich nie nötig!).

Da wir also anerkennen, dass es Verstöße geben kann, müssen wir jetzt im Voraus planen, wie wir reagieren und diese so schnell wie möglich schließen können. Wenn Sie sich umsehen, werden Sie feststellen, dass die durchschnittliche Entdeckungs- und Reaktionszeit in der Branche oft in Tagen gemessen wird … was sehr beängstigend ist! Für alle anderen mag dies eine Fülle von mehr oder weniger verständlichen Gründen haben, aber da wir Cloud Native sind und über einen gut ausgestatteten Werkzeugkasten verfügen, ist alles, was länger als ein paar Minuten dauert, nicht akzeptabel.

Wir werden mehrere von AWS angebotene Tools und APIs verwenden, um einen eigenen automatisierten Incident-Response-Prozess aufzubauen. Wir werden Verstöße automatisch erkennen, kompromittierte Instanzen isolieren, den aktuellen Status als Beweis speichern, die Instanz herunterfahren, eine dedizierte Forensik-Maschine starten und die infizierten Volumes für weitere Untersuchungen anschließen.

‍

Intelligente Bedrohungserkennung und kontinuierliche Überwachung mit Amazon GuardDuty

Der erste Schritt ist die Erkennung, unterstützt durch GuardDuty. GuardDuty bietet einen zentralen Ort zum Verwalten und Erkennen einer breiten Palette von Bedrohungen, von Spam-Aktivitäten bis hin zum Krypto-Mining. GuardDuty scannt CloudTrail-Protokolle, Flow-Protokolle und DNS-Protokolle, ohne dass eine Konfiguration auf Ihrer Seite erforderlich ist. Sollte eine Ihrer Instanzen einen Befund produzieren, kann GuardDuty ein Ereignis an CloudWatch senden.

Der wichtigste Schritt besteht nun darin, auf der Grundlage dieser Informationen zu handeln. Wir werden eine AWS-Lambda-Funktion verwenden, um automatisch auf diesen Vorfall zu reagieren.

AWS Lambda führt die automatische Reaktion auf den Vorfall aus

Zuerst isolieren wir diese VM, indem wir alle Sicherheitsgruppen entfernen und ihr eine Sicherheitsgruppe zuweisen, die allen ausgehenden und eingehenden Datenverkehr explizit verweigert, mit Ausnahme unserer Quellen, die für forensische Zwecke benötigt werden:

‍

region = 'eu-central-1'
ec2 = boto3.client('ec2', region_name=region)
ec2_res = boto3.resource('ec2')
instance = ec2_res.Instance(instance_id)
security_group_id = <Ihre Isolations-SG>

def lambda_handler(event, context):

#Instanz isolieren, Instanz-ID aus Ereignisnachricht abrufen
try:
sg_resp = instance.modify_attribute(Groups=[security_group_id])
print("Isolations-SG {} an {} zugewiesen".format(security_group_id, instance_id))

‍

Der nächste Schritt besteht darin, die Maschine sofort zum Absturz zu bringen, um weitere Änderungen zu verhindern, insbesondere von Prozessen oder Mechanismen, die versuchen könnten, ihre Spuren zu verwischen, sobald sie den Kontakt zu ihrem C&C-Server verlieren oder der Host heruntergefahren wird. Mit nur geringfügigen Änderungen können wir eine Instanz so vorbereiten, dass sie auf diesen plötzlichen Absturz in der von uns benötigten Weise reagiert – indem sie den aktuellen Status erfasst und gleichzeitig weitere Manipulationen verhindert. Die AWS-API bietet die Möglichkeit, einen Interrupt zu senden, um den Absturz auszulösen. Während all dem können wir bereits damit beginnen, eine Ersatzinstanz hochzufahren, um den Betrieb aufrechtzuerhalten.

‍

diag_resp = ec2.send_diagnostic_interrupt(InstanceId=instance_id)

#gewähre etwas Nachfrist für das Schreiben des Kernel- und Mem-Dumps
time.sleep(30)

stop_resp = ec2.stop_instances(InstanceIds=[instance_id])
print("Stopping VM {},preventing reboot".format(instance_id))
instance.wait_until_stopped()

‍

Dies sendet einen nicht maskierbaren Interrupt (NMI), um die Instanz zum Absturz zu bringen. Das detaillierte Verhalten ist konfigurierbar, aber das Wichtigste ist, ein Tool zum Erfassen des aktuellen Status zu haben. kdump ist ein Tool, das dazu in der Lage ist. Es ermöglicht uns, während des Bootens einen zusätzlichen Dump-Capture-Kernel zu laden, der übernimmt, wenn das Hauptbetriebssystem abstürzt. Dies ist im Allgemeinen ein sehr nützliches Debugging-Tool, aber für uns besonders hilfreich, um das System zum Absturz bringen und trotzdem den aktuellen Status auf die Festplatte schreiben zu können. Für weitere Details zum Diagnose-Interrupt können wir das AWS-Blog empfehlen.

Jetzt wird die kompromittierte Instanz heruntergefahren und isoliert. Von der Meldung des Vorfalls bis zur Isolierung und Herunterfahren der Instanz vergingen nur Sekunden. Der nächste Schritt besteht darin, herauszufinden, wie sich dieses Ereignis in Zukunft verhindern lässt. Wir bereiten die Maschine und die Daten für die Analyse durch ein Forensikteam vor. Indem wir zunächst Snapshots der kompromittierten AMI-Volumes erstellen, stellen wir sicher, dass alle Beweise für die Untersuchung gesichert sind. Das ursprüngliche Volume kann dann von der VM getrennt werden:

‍

#create snapshots
ebs_list = instance.block_device_mappings
for ebs_dict in ebs_list:
vol_id = ebs_dict['Ebs']['VolumeId']
volumes.append(vol_id)
snap_id = ec2_res.create_snapshot(VolumeId=vol_id)
print("Volume-Snapshot erstellt")

#detach volumes
for v in volumes:
vol = ec2_res.Volume(v)
vol.detach_from_instance()
print("Getrennte Volumes {} von {}".format(volumes, instance_id))

Schließlich können wir eine dedizierte Forensik-VM starten, die mit allen benötigten Tools vorinstalliert ist, und das Volume anhängen.

ami = '<Ihr Forensik-AMI>'
iamRole = {'Arn': 'arn:aws:iam::0123456789:instance-profile/ForensicsProfile', 'Id': 'someID'}
forensic_vm = ec2.run_instances(ImageId=ami, SecurityGroupIds=[ security_group_id ], InstanceType = 't3.micro', MinCount=1, MaxCount=1,'IamInstanceProfile': iamRole)
forensic_vm_id = forensic_vm['Instances'][0]['InstanceId']
fm = ec2_res.Instance(forensic_vm_id)
fm.wait_until_running()
fm.attach_volume(Device='/dev/sdf', VolumeId=volumes[0])

‍

‍

Forensik-Experten können sich nun bei der Maschine anmelden, die angeschlossenen Volumes mounten und mit ihrer Untersuchung beginnen.

Zusammenfassend lässt sich sagen: Wir haben eine kleine Anzahl gebrauchsfertiger AWS-Dienste, eine integrierte Integration und nur eine geringfügige Vorbereitung der Instanzen verwendet, um:

• kompromittierte Instanzen zu erkennen
• kompromittierte Instanzen zu isolieren
• weitere Manipulationen zu verhindern
• alle Beweise sicher aufzubewahren
• eine dedizierte Forensik-Instanz zu starten, um erfasste Beweise auszuwerten
• eine Ersatzinstanz zu starten, um den Betrieb fortzusetzen

in nur wenigen Minuten.