jonrau1/syntheticsun
Serverless AWS-Sicherheitsautomatisierungs-Framework, das Bedrohungsinformationen aufnimmt, ML-basierte Anomalieerkennung (RCF, IP Insights) anwendet und Sicherheitstelemetriedaten in Kibana anreichert, um automatisierte Bedrohungsprävention, -erkennung und -reaktion zu ermöglichen.
SyntheticSun ist ein Sicherheitsautomatisierungs- und Überwachungsframework mit verteidigungstiefem Ansatz, das Bedrohungsinformationen, maschinelles Lernen, verwaltete AWS-Sicherheitsdienste und serverlose Technologien nutzt, um Bedrohungen kontinuierlich zu verhindern, zu erkennen und darauf zu reagieren.
You sleep in fragmented glass
With reflections of you,
But are you feeling alive?
Yeah let me ask you,
Are you feeling alive?
- Norma Jean, 2016
SyntheticSun basiert auf der Nutzung der Malware Information Sharing Platform (MISP) und Anomali's LIMO, die gemeinschaftsgetriebene Threat-Intelligence-Plattformen (TIPs) sind und verschiedene Arten von Indikatoren der Kompromittierung (IoC) bereitstellen. Normalisierte und deduplizierte Threat-Intelligence wird nahezu in Echtzeit abgeglichen, um bekannte Bedrohungen in verschiedenen Arten von Netzwerkverkehr schnell zu identifizieren. Um die Identifizierung potenzieller Bedrohungen dynamischer zu gestalten, werden IP-Insights-Modelle bereitgestellt, um Anomalien (und darin enthaltene potenzielle Bedrohungen) zwischen der Zuordnung von IP-Adressen und Entitäten (wie IAM-Prinzipal-IDs, User-Agents usw.) zu finden. Native RCF-Detektoren werden ebenfalls in Elasticsearch verwendet, um Anomalien in nahezu Echtzeit-Sicherheitstelemetrie zu finden, während diese in Kibana gestreamt wird. Um die Nutzung und Feinabstimmung von ML-Modellen innerhalb von Sicherheitsteams zu demokratisieren, werden Dienstprogramme zum Trainieren von IP-Insights-Modellen als Ergänzung zur Kernlösung bereitgestellt.
Für die Orchestrierung und Automatisierung sowie die Extraktion, Transformation und das Laden (ETL) von Sicherheitstelemetrie in Kibana werden verschiedene AWS-Serverless-Technologien wie AWS Lambda, Amazon DynamoDB und AWS CodeBuild verwendet. Serverlose Technologien wie diese werden wegen ihrer Skalierbarkeit, Benutzerfreundlichkeit und relativ geringen Kosten im Vergleich zu schweren MapReduce- oder Glue-ETL-basierten Lösungen eingesetzt. Ein Großteil der Lösung wird über CloudFormation bereitgestellt, mit Hilfsskripten in Python und Shell, die in den verschiedenen Phasen bereitgestellt werden, um die Übernahme und potenzielle Bereitstellung in Continuous-Integration-Pipelines zu fördern.
Um die "Eingeweide" der Lösung so schlank wie möglich zu halten, führen grundlegende Python-Module wie boto3, requests, json, ipaddress, socket und re den Großteil der Extraktion, Transformation und des Ladens (ETL) in nachgelagerte Dienste durch. Da alle Geolokalisierungsinformationen von ip-api.com bereitgestellt werden, sind weder ein Konto noch kostenpflichtige Stufen erforderlich, und es gibt eine großartige API, die Drosselungsinformationen in ihren Antwort-Headern enthält. Ein Großteil der Abhängigkeiten von Elasticsearch und Kibana wird ebenfalls im Code bereitgestellt (Indizes, Mappings, Visualisierungen usw.), um eine aufwändige manuelle Konfiguration zu vermeiden.
SyntheticSun verteilt sich aufgrund der Größe der Lösung und der erforderlichen Abhängigkeiten auf drei Phasen. Alle Architektur- und Installationsanweisungen (sowie FAQs, wo angebracht) befinden sich in ihrer eigenen Phase. Ergänzungsmodule (Anhang genannt) werden ebenfalls bereitgestellt, um die Funktionalität zu erweitern; diese haben ihre eigene Architektur und Installationsanweisungen lokalisiert.
SyntheticSun ist, da es etwas ist, das Sie auf GitHub gefunden haben, ein Proof-of-Concept, daher habe ich für die erste Version nicht die Extrameile gegangen, um alles absolut zu härten. Angenommen, Sie lesen dies zu einem Zeitpunkt, an dem ich die notwendigen Änderungen noch nicht vorgenommen habe, beachten Sie bitte Folgendes, bevor Sie diese Lösung in einer Produktionsumgebung (oder einer Umgebung mit erhöhten Sicherheitsanforderungen) bereitstellen. Ich werde diese Punkte in eine Roadmap aufnehmen und sie bei Bedarf aktualisieren.
SyntheticSun ist ein einfacher Weg, um Cyber Threat Intelligence und maschinelles Lernen für Ihre Edge-Protection-Sicherheitsanwendungsfälle auf der AWS Cloud zu nutzen, ohne in ein oder mehrere kommerzielle Tools investieren oder einen Data Scientist für Ihr Sicherheitsteam einstellen zu müssen (obwohl Sie idealerweise letzteres tun sollten). Diese Lösung ist nach der anfänglichen Konfiguration vollständig automatisiert, sodass Sie Bedrohungen mit Maschinengeschwindigkeit identifizieren und darauf reagieren können. Schließlich bietet diese Lösung grundlegende Visualisierungen für Ihr Incident-Response-Team zur Bedrohungsabwehr, wie z. B. erlaubte eingehende oder ausgehende Verbindungen oder DNS-Abfragen zu und von IP-Adressen oder Domänen, die als bösartig eingestuft wurden. Der Kern der Lösung basiert auf sehr leichten Automatisierungs- und Daten-Engineering-Pipelines, die theoretisch für andere Zwecke wiederverwendet werden können, bei denen mehrstufige Normalisierung und Anreicherung oder geplante, schnelle Batch-Jobs benötigt werden.
Erstens, wenn Sie Amazon GuardDuty und/oder AWS WAF nutzen, könnte es sinnvoll sein, diese Lösung zu evaluieren – es ist aber auch eine Voraussetzung. Offensichtliche Personas, die davon profitieren können, sind Produktteams, die für die Sicherung ihres gesamten Stacks verantwortlich sind und nicht über das Kapital oder das Fachwissen verfügen, um Algorithmen des maschinellen Lernens zu modellieren, zu trainieren und bereitzustellen oder Cyber-Threat-Intelligence-Feeds sinnvoll zu operationalisieren. Diese oben genannten Personas sind wahrscheinlich Sicherheitsingenieure, SecOps / SOC-Analysten und -Ingenieure oder DevSecOps-Ingenieure; diese Liste ist jedoch nicht abschließend und sie müssen nicht produkt-/anwendungsorientiert sein, da auch zentrale Teams diese nutzen können. Eine weitere Verwendung ist für dieselben Personas (SecOps, Sicherheitsingenieure), die für ein zentrales Team arbeiten und eine dynamische Blockierliste für Firewalls und Intrusion-Prevention-Systeme erstellen möchten; die CodeBuild-Projekte können umfunktioniert werden, um CSV- oder Flatfiles an fast jeden Ort zu dropen (z. B. Palo Alto Firewalls, Squid Forward Proxy URL-Filter usw.).
SyntheticSun deckt derzeit nicht alle Hauptlogquellen vollständig ab – insbesondere S3 Access Logs und CloudFront Access Logs, die für die Art und Weise, wie viele Leute Dienste bereitstellen (insbesondere für SPAs auf S3-Buckets), wesentlich sind. Die Anomalieerkennung erstreckt sich aufgrund meiner Besessenheit mit IP Insights und dem völligen Fehlen jeglicher Data-Science-Ausbildung (im Ernst, ich weiß nicht einmal, wie man pandas oder numpy verwendet) nicht über WAF, API Gateway Access Logs oder CloudTrail hinaus. Es gibt keine eingehende Analyse der rohen Threat-Intelligence-IoCs, außer dem Versuch, sie in den Logs zu matchen.
Der einfachste Weg, diese Lösung für eine Organisation bereitzustellen, besteht darin, sie in einem zentralen Sicherheitsservicekonto bereitzustellen. Für die niedrigere Telemetrie wie VPC Flow Logs und WAF Logs sollten Sie erwägen, Hilfsskripte oder CloudFormation-Vorlagen über AWS Service Catalog bereitzustellen, um die Aktivierung in niedrigeren Umgebungen zu fördern. Sie müssen Ihren Shard-Verbrauch und die Indexrotation des Elasticsearch Service sowie die Berechtigungen evaluieren, wenn Sie kontenübergreifende Kinesis Data Firehose Delivery Streams haben, die in einen zentralen Ort veröffentlichen. Ich habe diese Lösung in meinem persönlichen Sandbox-Konto erstellt, daher habe ich keine der oben genannten Überlegungen in die Lösung eingebaut; ich werde mich gerne mit einem Pull Request befassen, der dies berücksichtigt, und könnte es in Zukunft selbst tun.
Seit dem 31. JULI 2020 unterstützen AWS Firewall Manager Policies die Multi-Account-Aggregation des WAF-Loggings, was Sie einen Schritt näher daran bringt, dies wesentlich weniger schmerzhaft zu machen …
EINSCHRÄNKUNGEN: Ich bin kein Data Scientist und das wird eine lange Antwort. Tl;dr: Es ist ein Anomaliefinder, und ich denke schon?
Da ich nicht annähernd ein Data Scientist bin oder eine entsprechende Ausbildung habe, sind Sie besser bedient, die Dokumentation zu diesem Thema zu lesen. Dennoch hier mein Laienversuch: IP Insights ist ein unüberwachter Algorithmus des maschinellen Lernens, der die Beziehung zwischen einer IPv4-Adresse und einer Entität (z. B. Kontonummer, Benutzername, User-Agent) lernt. IP Insights versucht dann zu bestimmen, wie wahrscheinlich es ist, dass die Entität diese IPv4-Adresse verwendet. Hinter den Kulissen von IP Insights verbirgt sich ein neuronales Netzwerk, das die latente Vektorrepräsentation dieser Entitäten und IPv4-Adressen lernt. Der Abstand zwischen diesen vektorisierten Darstellungen ist kennzeichnend dafür, wie anomal (oder nicht) es ist, dass eine Entität mit einer IPv4-Adresse assoziiert ist (z. B. eine Anfrage von dieser Adresse sendet).
Neuronale Netzwerke sind fast genau das, wonach sie klingen; sie bilden ein System des maschinellen Lernens, das entwickelt wurde, um sich ähnlich wie das menschliche Gehirn zu verhalten, komplett mit computerisierten Neuronen und Synapsen. Beim unüberwachten maschinellen Lernen kann der Algorithmus herausfinden, was "gut" (d. h. True Negative) im Vergleich zu "schlecht" (d. h. True Positive) aussieht, indem er die Assoziation zwischen allen IPv4-Adressen und ihren gepaarten Entitäten betrachtet. Diese Assoziation wird ausgewertet, um zu identifizieren, welche Vektoren ähnlich zu anderen sind, basierend auf ihrem "Abstand". Im Fall von IP Insights wird ein vorgebauter Encoder bereitgestellt, der nach IPv4-Adressen sucht und dann alle Entitäten in Cluster hasht. Er iteriert dann über sie mittels Vektorisierung. Vektorisierung ist eine Möglichkeit, Berechnungen als Matrix durchzuführen, anstatt über sie zu loopen (denken Sie an eine "For"-Schleife für eine Liste mit zig Millionen Werten).
Wenn Sie ein IP-Insights-Modell trainieren, erzeugt es sich tatsächlich selbst False Positives, indem es IPv4-Adressen mit Entitäten paart, die einen großen Abstand haben (d. h. hochgradig anomal) und in der Realität weniger wahrscheinlich vorkommen; das Modell kann nun zwischen True Positives, False Positives und True Negatives unterscheiden. Dies geschieht, um einen weiteren verrückten Begriff namens "Cross Entropy" zu verhindern (auch als "Log Loss" bekannt, als ob das besser wäre), und führt einen weiteren Begriff ein: binäre Klassifikation. IP Insights fragt im Wesentlichen: "Wie hoch ist die Wahrscheinlichkeit, dass diese mit dieser Entität gepaarte IP-Adresse anomal ist?" Das macht es meiner Meinung nach binär, also "ja, es ist schlecht" oder "nein, es ist nicht". Die Wahrscheinlichkeit wird als Wert zwischen 0 und 1 dargestellt, das Ziel aller Modelle des maschinellen Lernens ist es, diesen so nahe wie möglich an 0 zu bringen. Das Vorhersagen eines Werts von 0,01 für etwas, das tatsächlich 1 ist (bekanntes True Positive), würde zu einem sehr hohen Log Loss führen. Mit alledem gesagt, hilft IP Insights durch die absichtliche Erstellung von Müll-Daten, diesen Log Loss (d. h. schlechte Vorhersagen) während des Trainings zu reduzieren.
Das bringt uns zur Ausgabe des Endpunkts. Wenn Sie ihn abfragen (entweder in Batches oder nahezu in Echtzeit über die InvokeEndpoint-API), ist die Antwort ein unbegrenzter Float, der negativ oder positiv sein kann. Je höher er über 0 liegt, desto wahrscheinlicher ist er anomal, und hier beginnt Ihre Arbeit. Für diese Lösung habe ich alles über 0,03 gewählt, was weitgehend fiktiv ist. Um der Wahrheit näher zu kommen, sollten Sie dem Endpunkt True Positives bereitstellen und sehen, wie Ihre Antwort ausfällt. Basierend auf diesen Erkenntnissen könnten Sie einen abgestuften Ansatz konfigurieren, bei dem Ihre Anwendung je nach Score eine Zweitfaktor-Herausforderung ausgibt, einen Alarm auslöst oder den Zugriff vollständig blockiert. Die Antwort auf den zweiten Teil der Frage lautet "Ja, ich denke schon"; das Trainieren des Modells mit User-Agents, die mit einer IP gepaart sind, ist tatsächlich ziemlich bedenklich. Für andere weniger volatile Entitäten (Kontonummer, Benutzername, IAM-Benutzer) fühlt es sich nach der beabsichtigten Verwendung an.
In der Lösung stelle ich einige Beispiel-Feeds bereit, die Sie verwenden sollten; einige sind ziemlich offensichtlich, wie der Cybercrime-Domain-Feed, Emerging Threats und CI-badguys. In meinem richtigen Job arbeite ich mit einem der talentiertesten Cyber-Threat-Intelligence-Spezialisten der Welt (kein Scherz, sie ist großartig!), der auch die Auswahl beeinflusst hat. Wie bei Modellen des maschinellen Lernens und allem anderen, das Sie bauen werden, sollten Sie Ihre Threat-Intelligence-Feeds und -Aggregation an Ihre aktuelle Bedrohungsumgebung anpassen. Duplikate werden in MISP identifiziert, und in den DynamoDB-Tabellen wird nur ein Hash-Schlüssel angegeben, um die Eindeutigkeit zu erzwingen. Selbst wenn also 5 Feeds über dieselbe IPv4-Adresse berichten, gelangt nur eine in die Tabelle.
Sie können auch eigene kommerzielle Threat-Intelligence-Plattformen und -Feeds wie InfoBlox oder Recorded Future in diese Lösung einbinden, indem Sie sie mit ähnlicher Syntax auf die DynamoDB-Tabellen ausrichten.
Die meisten Logzustellungen von AWS erfolgen nach dem "Best-Effort"-Prinzip, daher gibt es keine offizielle SLA-Veröffentlichung; ich würde jedoch annehmen, dass sie bei etwa 99,5 - 99,9 % liegt, wobei alles in den letzten 0,5 - 0,1 % nicht zugestellt wird. "Produktions"-Datenverkehr hat bei AWS ebenfalls Vorrang; wenn es Netzwerkbandbreitenbeschränkungen gibt, wird standardmäßig die Konnektivität zu Clients wiederhergestellt, anstatt Logs zu senden. Das wahrscheinlichere Ereignis ist, dass die rohe Logdatei zu groß war, als dass Lambda sie rechtzeitig verarbeiten konnte; das sieht man oft, wenn man von einem DOS oder Crawler von derselben Client-IP überschwemmt wird. WAF und ALB bündeln Logdateien nach dem Aufrufer (soweit ich das beurteilen kann). Wenn Sie also Hunderte von Anfragen absorbieren, kann die Logdatei sehr groß sein.
Ja, jedoch müssen Sie eine der folgenden Maßnahmen ergreifen:
Es fallen zusätzliche Kosten an. Lambda in einer VPC, insbesondere bei Dutzenden von gleichzeitigen Aufrufen, wird wahrscheinlich zu mehr Problemen durch ENIs führen, die herumhängen und Ihren RFC1918-Adressraum verbrauchen. Es sei denn, Sie müssen aus Compliance-Gründen unbedingt den gesamten Datenverkehr innerhalb Ihrer VPC isolieren, würde ich diesen Weg nicht gehen.
Ja, dies ist erreichbar, indem Sie die Lösung modifizieren, um die endgültig formatierten Logs in Kinesis Data Firehose zu veröffentlichen und diese auf Splunk auszurichten.
Ich hoffe, in Zukunft Unterstützung für Route 53 DNS Logs, S3 Access Logs, CloudFront Access Logs und API Gateway Access Logs sowie vielleicht einige andere hostbasierte Logs zu haben.
Ich hätte ehrlich gesagt den Kinesis Data Agent bevorzugt, aber ich habe viele Probleme damit festgestellt: Er ist standardmäßig nicht in Amazon Linux 2 enthalten, und da Ubuntu 18.04 LTS-AMIs jetzt mit Java 11 vorinstalliert kommen, hatte ich Rückwärtskompatibilitätsprobleme mit dem Agent, da der Build fehlschlägt, wenn Sie nicht OpenJDK 8 oder 9 verwenden. Es war viel einfacher, den CloudWatch Agent zu installieren, da er häufig mit neuen Funktionen aktualisiert wird und Systems Manager Document Support für die Konfiguration bietet; er hat sogar einen Assistenten für die Installation. Wenn AWS jemals den Kinesis Data Agent Support so ernst nimmt wie den CloudWatch Agent, könnte ich wechseln, da ich für bestimmte hostbasierte Logs (Suricata, Squid, Nginx, Apache) viel lieber direkt in Kinesis Data Firehose veröffentlichen würde, anstatt CloudWatch Logs als Zwischenstation zu nutzen.
Ich nehme gerne Pull Requests für Punkte an, die in Issues oder im Project Board als "Help Wanted" gekennzeichnet sind. Ich werde auch alle anderen vorgeschlagenen PRs überprüfen, sofern sie dem Geist des Projekts entsprechen.
Besonderer Dank an David Dorsey und Ryan Nolette, die wertvolles Feedback, Tests und Beiträge zur Feinabstimmung von SyntheticSun geleistet haben.
Diese Bibliothek ist lizenziert unter der GNU General Public License v3.0 (GPL-3.0). Siehe die LICENSE-Datei.
