Einleitung
In vielen Unternehmen wird bereits seit Jahren das Application Security Monitoring eingeführt, ausgebaut und betrieben. Idealerweise werden diese Daten im SIEM des Unternehmens mit allen anderen sicherheitsrelevanten Daten verknüpft, um ein möglichst umfangreiches Monitoring zu erzielen. Denn nur dann sind Korrelationen von Ereignissen relativ einfach möglich und damit die möglichst schnelle Erkennung von Angriffen sowie die Analyse von Beginn und Auslöser dieser Ereignisse.
Hierzu schreiben die Applikationen sicherheitsrelevante Vorgänge in ihre Log Dateien. Doch das liest sich einfacher, als es umgesetzt ist, denn in der Realität sind etliche Klippen zu umschiffen, um zu sinnvollen und effizienten Ergebnissen zu kommen.
Aus der mehrjährigen Praxis im Bereich Application Security Monitoring in Unternehmen verschiedener Branchen lassen sich die folgenden Faktoren als Hauptprobleme beim Aufbau eines unternehmenseinheitlichen Monitorings erkennen:
- uneinheitliches Log Format
- mehrfache Änderung des zu verwendenden Formats in wenigen Jahren
- Mischung "normaler" und sicherheits-relevanter Ereignisse in einem Log
- Fehl-Interpretationen der Bedeutung verschiedener Felder im CEF und anderen Formaten
- Fehl-Interpretationen beim Mapping auf Felder des SIEM
- fehlende oder widersprüchliche Basis Informationen in den Log Dateien
- Zeitsynchronisation, korrekte Zeitzone der beteiligten Server
- fehlende Maintenance bei Legacy-Applikationen oder solchen, die „demnächst“ deaktiviert werden dann aber noch Jahre weiter produktiv sind
- Fehlende oder inakkurate Informationen in der CMDB
[Update 04.04.20]
Zusätzliche Probleme entstehen dann noch, wenn Applikationen über den syslog daemon loggen: Satzlängenbeschränkungen von syslog waren nicht bekannt was dazu führt das der daemon zu lange Sätze in 2 Zeilen aufbricht, die dann vom SIEM nicht mehr richtig erkannt wurden. Außerdem ist natürlich in sicherheitskritischen Umgebungen ein Logging über das zustandslose Protokoll UDP ohnehin generell in Frage zu stellen.
[Ende Update]
All dies macht die Entwicklung einheitlicher Use Cases für Threat Analysis und Cyber Hygiene nahezu unmöglich oder führt zu einer hohen Anzahl von False Positives oder nicht erkannten Ereignissen. Oder es entsteht die Situation, dass ein verdächtiges Ereignis stattfand, es kann nur nicht ermittelt werden wo (auf welchem System) und/oder von wem.
Beispiele:
Ob das Ausführen der administrativen Funktion „User Profile Change“ berechtigt oder unberechtigt erfolgte, lässt sich nicht automatisiert prüfen, solange die Informationen für „effective Account“ und „affected Account“ nicht korrekt geloggt werden. Darüber hinaus sind auch die Informationen der beteiligten „Privilege Class“ beider Accounts notwendig.
Die Prüfung auf das Ereignis „Suspicious Account Takeover“ ist ebenso nur möglich, wenn beide Accounts, beide „Privilege Class“ und „source_host“ Informationen vorhanden sind.
Auch die CMDB Daten sind hilfreich bis notwendig, um festzustellen, ob beteiligte Systeme tatsächlich End User Devices, Server, Produktiv- oder Entwicklungssysteme sind. Was auf Entwicklungssystemen möglich sein darf - ein „Account Takeover“ von ein und demselben „source_host“, sollte in der Produktion nicht vorkommen und daher differenzierbar sein.
Leider werden CMDB Daten aus verschiedenen Gründen (ein UAT System wird kurzfristig in die Produktion verschoben, um Engpässe zu vermeiden und keinen neuen Bestellvorgang auslösen zu müssen; CMDB Maintenance wird schlicht vergessen oder als "nicht ganz so wichtig" immer wieder hintan gestellt) nicht immer korrekt gepflegt. Was wiederum zu False Positives führen wird.
Diese kurze Liste von Praxisbeispielen ließe sich beliebig fortführen.
Fazit
Ein Application Security Monitoring ist nicht einfach mal so aus dem Boden gestampft. Wie nahezu alles in der IT benötigt es ein gründlich erarbeitetes Konzept, die Einbindung der richtigen Stellen im Unternehmen und die Bereitschaft seitens der Verantwortlichen ggf. eine große Menge Geld zur Beseitigung nicht-zielführender Altlasten in die Hand zu nehmen.
Ich habe es erlebt, dass ein solches Projekt aufgrund eines externen Audits innerhalb der Organisationseinheit Information Security Operations aufgesetzt, begonnen und durchgezogen wurde, obwohl die Anforderungen an das ASM nicht einmal mit den Analysten im Threat Center besprochen wurden. Einfachste Beispiel-Logs hätten schon aufgezeigt, dass diese den Anforderungen nicht entsprechen.
Statt dessen wurde im Interesse der Beseitigung des Prüfberichts nur an das Onboarding der Logs in das SIEM gedacht. Der Erfolg wurde nicht an der Qualität der Daten, und damit an deren Auswertbarkeit gemessen, sondern ausschließlich an der Anzahl übernommener Applikationen. Der Erfolg waren 400-500 Mio. Events pro Tag in einem ohnehin schon überlasteten SIEM System, von denen gerade mal 100-150 Mio sinnvoll nutzbar waren.
Dieses Szenario führt zu hohen und unnötigen Folgekosten in Form von
- Aufrüstung der Infrastruktur der Analyse Plattform
- Lizenzkosten für die Analyse Plattform
- verschwendete Arbeitszeit an zahlreichen Arbeitsplätzen durch unnötig lange Wartezeiten für selbst einfachste Reports.
Und das eigentliche Ziel des Projekts, möglichst alle sicherheits-relevanten Ereignisse zu erfassen wird nicht erreicht.
Sollte sich auch Ihr Unternehmen mit Auf- oder Ausbau des Application Security Monitorings beschäftigen, versuchen Sie diese Anregungen aufzugreifen und in Ihrer Planung entsprechend zu berücksichtigen. Gern können Sie mich auch diesbezüglich kontaktieren.
Vielen Dank auch an Christoph Gruber, der weitere Herausforderungen beigesteuert hat :-)