Foto: Anucha Cheechang - shutterstock.com
Da manche Software-Fehler zu Sicherheitslücken führen, ist es vor allem bei ERP-Anwendungen wichtig, das Problem zu verstehen und die richtigen Maßnahmen zu ergreifen. Ein Stillstand der ERP-Systeme (wir nehmen hier stellvertretend SAP Systeme unter die Lupe), der Diebstahl von Daten oder die Manipulation von Geschäftsprozessen kann schnell zu Schäden, oder auch Strafen, in Millionenhöhe führen.
Was ist ein Zero Day Exploit?
Was genau Zero Day, Zero-Day-Schwachstelle, Exploit und Angriff bedeuten, wurde von Josh Fruhlinger in seinem Artikel "Was ist ein Zero Day Exploit?" umfassend beschrieben. Kurz gesagt handelt es sich um eine Schwachstelle, die gerade eben (Tag 0) entdeckt und erstmals veröffentlicht wurde, wenn auch nur in kleinstem Kreis. Der Artikel stellt generische Maßnahmen zum Umgang mit Zero-Day-Schwachstellen vor. Am Ende dieses Beitrags finden Sie eine ergänzte Zusammenfassung von möglichen Maßnahmen.
Das "Window of Exposure"
Im Jahr 2000 betrachtete der Sicherheitsexperte Bruce Schneider die sichtbare Entwicklung, die eine gefundene Schwachstelle von deren Entdeckung bis zur Installation eines Patches auf der Anwenderseite nimmt. Er nannte die fünf Phasen das "Window of Exposure". Dieses Bild trifft perfekt auf die SAP-Welt zu.
Laut Schneier steigt das Risiko, je mehr eine Schwachstelle der Öffentlichkeit bekannt ist. Ironischerweise wird dies etwas verstärkt, wenn ein Patch veröffentlicht wird. Dann weiß faktisch jeder, dass es die Schwachstelle gibt - aber eben auch, wie sie ausgenutzt werden kann. Das ist in der Regel der veröffentlichten Reparaturanleitung zu entnehmen. Streng genommen handelt es sich dann nicht mehr um eine Zero-Day-Schwachstelle.
Fokus SAP-Systeme
SAP-Systeme stellen das Rückgrat der Prozesse dar, in dem die Wertschöpfung eines Unternehmens stattfindet. Sicherheitsvorfälle in einem solchen System können daher zu gefährlichen Risiko-Auswirkungen für ein Unternehmen führen. Im Folgenden stellen wir Wege vor, um über allgemein zugängliche Quellen an Infos zu SAP-Exploits zu gelangen. Die Analyse beginnt, nachdem die Schwachstelle entdeckt wurde (Zero Day) und nach und nach an den üblichen Stellen auftaucht.
In Code Repositories wie Github lässt sich leicht nach Exploit oder so genanntem "Proof of Concept" Code suchen. Die Ergebnisse von Suchbegriffen wie "SAP exploit github" können gute Informationen liefern und Nutzen bringen.
In speziellen Suchmaschinen wie beispielsweise Shodan lässt sich gezielt nach anfälligen Systemen suchen. Hier stehen unzählige Filter einschließlich der Suche nach Schwachstellen - etwa in SAP Systemen, die online sind - zur Verfügung. Umfassende Filterergebnisse liefert der Anbieter jedoch nur Nutzern mit einem kostenpflichtigen Account.
Noch einen Schritt weiter gehen Hacker-Tools wie Metasploit, für die es ganze Module gezielt für Plattformen wie SAP gibt.
Maßnahmen des Herstellers SAP
SAP selbst hat bereits 2011 damit begonnen, Sicherheitsthemen systematisch anzugehen. Beispiele dafür sind:
Threat Modelling,
sichere Codierungsrichtlinien,
Tool-Unterstützung oder
Quality Gates.
Auch Lücken, die Forscher finden und an SAP im Rahmen des Security Response Prozesses melden, behebt der Hersteller. Patches, bei SAP "Security Notes" genannt, werden jeden zweiten Dienstag im Monat veröffentlicht. Die Erfolgsbilanz der neuesten Patches ist öffentlich verfügbar.
Die Situation bei den Anwendern
Um einen fortlaufenden, möglichst reibungslosen Betrieb zu gewährleisten, müssen auf Anwenderseite Prozesse vorhanden sein, um die verfügbaren Patches zeitnah einzuspielen. Spätestens mit der Veröffentlichung des Patches weiß jeder, dass eine Schwachstelle vorhanden ist.
An sich ist das Patchen eines SAP-Systems kein Hexenwerk. Es ist eine Frage von Know-how, Ressourcen, Prozessen und vor allem Prioritäten. Vor einigen Jahren erwähnte eine Studie, dass nur 30 Prozent der Kunden Patches innerhalb von drei Monaten installieren. Wir gehen davon aus, dass dieser Wert mittlerweile höher liegt, aber noch weit davon entfernt, ein Best-Practice-Niveau zu erreichen.
Fragwürdiger Umgang mit ZeroDay-Veröffentlichungen
Viele Forscher und Organisationen haben zur Sicherheit des SAP-Standards beigetragen, indem sie die Erkenntnisse über neue Schwachstellen übermittelt haben. Anschließend stellt der Hersteller, wenn nötig, im Zuge des SAP Security-Response-Prozesses die entwickelten Patches zur Verfügung.
Allerdings orchestrieren einige Forscher oder Organisationen buchstäblich eine globale Marketingkampagne, die am Tag der Patch-Veröffentlichung gestartet wird. Während Transparenz über Patches eine gute Sache ist, ist dieser Ansatz fragwürdig, denn
durch das offensive "Vermarkten" einer Schwachstelle wird deren Sichtbarkeit dramatisch erhöht und
noch mehr Druck auf die SAP-Kunden ausgeübt, einen Patch buchstäblich am Tag der Veröffentlichung zu installieren - was nahezu ein Ding der Unmöglichkeit ist.
Dieses Vorgehen widerspricht auch den Vorgaben von SAP für verantwortungsvolle Offenlegung ("Responsible Disclosure"). Hier heißt es aus gutem Grund, dass nach Veröffentlichung eines Patches für drei Monate Stillschweigen zu wahren ist, sowie keinerlei Marketing-Aktivitäten erlaubt sind.
Checkliste: die 3 zusätzlichen Maßnahmen für SAP System
In dem eingangs genannten Artikel zu Zero Days werden vier Maßnahmen aufgeführt: Tiefgehendes Defensiv-Training, Wachsames Auge, Netzwerke absichern, und Backup ist Pflicht. Dies unterschreiben wir uneingeschränkt, wollen jedoch drei Aspekte hervorheben bzw. ergänzen:
Es sollte klar sein, wer im Unternehmen die Verantwortung für Patch-Prozesse im Allgemeinen und wer SAP-Paches verantwortet. Sollte es sich nicht um die gleiche Person oder Abteilung handeln, prüfen Sie, wie die IT-Organisation mit der SAP-Abteilung im Bereich Patching zusammenarbeitet und welche Richtlinien für ihr Unternehmen passen. Dies gilt vor allem für regulierte Unternehmen, bei denen Patches im ERP-Umfeld eine besondere Relevanz haben.
Ein wachsames Auge haben bedeutet heute, durch den Einsatz von SIEM-Systemen die verdächtigten Aktivitäten und Anomalien zu erkennen und im Security Operation Center (SOC) entsprechende Maßnahmen einzuleiten. Prüfen Sie, ob ihr SIEM-System SAP-Ereignisse erkennen kann und ob ihr SOC-Team weiß, wie darauf zu reagieren ist.
Backups gehören zum Pflichtprogramm. In diesem Zusammenhang sollte auch regelmäßig geprüft werden, ob diese Backups in einem angemessenen Zeitrahmen auch wieder eingespielt werden können. Prüfen Sie, wer für Backup und Restore oder alternativ eine redundante Systemlandschaft verantwortlich ist und ob es regelmäßig einen "Feuerübung" gibt. (bw)