Warum das Triage-Verfahren bald überflüssig sein könnte

Wenn es einen Bereich gibt, in dem sich die Sicherheit insgesamt verbessern lässt, dann ist es ihr Ruf, Unternehmen auszubremsen.

Einer der Hauptgründe für diesen Ruf ist das „Triage-Verfahren“ – dabei wird geprüft, ob eine Sicherheitswarnung Ihr Unternehmen tatsächlich betrifft, das geschätzte Ausmaß bewertet und eine Lösung ermittelt.

In diesem Artikel untersuchen wir, warum die Triage für Unternehmen schnell zum Engpass werden kann, und zeigen, warum wir alle darauf hinarbeiten sollten, sie zu überspringen und uns stattdessen auf die Behebung von Schwachstellen zu konzentrieren.

Ein beispielhafter Triage-Workflow

Stellen wir uns vor, wie ein Triage-Workflow für eine neu gemeldete Sicherheitslücke aussehen könnte.

Nehmen wir als Beispiel die jüngste RCE-Schwachstelle (Remote Code Execution) in Apache Struts, die letztlich im Equifax-Fall ausgenutzt wurde. Man kann sich vorstellen, wie ein Unternehmen dieser Größe mit einer solchen Schwachstelle umgehen könnte:

• Eine Person aus dem Sicherheitsteam erhält eine Warnung, dass die Schwachstelle existiert. Vorausgesetzt, sie hat relevante Mailinglisten abonniert oder nutzt Tools, die sie auf diese Schwachstelle aufmerksam machen – und liest die Warnungen auch!

• Diese Person aus dem Sicherheitsteam würde eine Engineering-Fachkraft bitten, einen Bericht über alle Anwendungen im Unternehmensportfolio zu erstellen, die Apache Struts verwenden. Das ist für sich genommen schon keine einfache Aufgabe, denn Bestands- und Zusammensetzungsverwaltung ist eine große Herausforderung – besonders für Unternehmen, die schon lange bestehen. Noch schwieriger wird es für Unternehmen, die im Laufe der Jahre Fusionen und Übernahmen durchgeführt und mehrere Teams mit unterschiedlichen Tech-Stacks übernommen haben. Nehmen wir dennoch an, das Unternehmen könnte einen Bericht über 100 Projekte erstellen, die Apache Struts verwenden.

• Die Person aus dem Sicherheitsteam würde dann 100 Jira-Tickets mit dem Schweregrad „kritisch“ erstellen und die unternehmensweite Alarmbereitschaft ausrufen, damit das Problem sofort behoben wird.

• 100 Engineering-Fachkräfte aus verschiedenen Bereichen des Unternehmens müssten ermittelt und mit der Behebung dieser Schwachstelle beauftragt werden.

Sehen wir uns nun an, wie die Situation aus Sicht der Entwicklerinnen und Entwickler aussieht. Wahrscheinlich arbeitet die jeweilige Person gerade an einer wichtigen Funktion und möchte sie schnell fertigstellen, um einen zentralen Meilenstein oder Termin zu erreichen. Trotzdem handelt es sich um eine wichtige Sicherheitswarnung, die sie bearbeiten muss. Dazu wären folgende Schritte nötig:

• Informationen zur jeweiligen Schwachstelle lesen.

• Sich mit Remote Code Execution und der Art der Schwachstelle vertraut machen.

• Herausfinden, ob die Schwachstelle die eigene Anwendung betrifft. Dazu könnte man versuchen, den konkreten Exploit zu finden und zu prüfen, ob er anwendbar ist.

• Die möglichen Behebungen der Schwachstelle recherchieren.

• Die Behebungen anwenden.

• Bestätigen, dass die Schwachstelle behoben wurde.

Das ist eine Menge Arbeit, und manches davon erfordert fundiertes Sicherheitswissen. Der gesamte Triage-Workflow kann Tage, Wochen oder sogar Monate dauern – je nachdem, wie aufwendig die internen Abläufe Ihres Unternehmens sind. Das ist nicht gut.

Können wir Software entwickeln, die bei der Triage hilft?

Wahrscheinlich! Mit Code-Instrumentierung und maschinellem Lernen könnten wir ein System entwickeln, das Ihnen mitteilt, ob Codepfade die anfällige Methode in den betroffenen Bibliotheken verwenden. Wenn die Ergebnisse präzise sind – also nur wenige falsch positive und falsch negative Meldungen auftreten –, ließen sich einige Triage-Schritte für Entwicklerinnen und Entwickler einsparen. Doch selbst wenn wir nachweisen, dass sich die Schwachstelle in unserem Kontext ausnutzen lässt, müsste die Entwicklungsfachkraft immer noch herausfinden, wie sie behoben werden kann!

Noch gefährlicher ist es oft, wenn Tools nahelegen, dass im aktuellen Kontext möglicherweise keine Datenflüsse existieren, die eine Ausnutzung ermöglichen. In solchen Fällen unterdrücken oder ignorieren viele Unternehmen die Warnung – und genau darin liegt die Gefahr.

Dass der Code derzeit möglicherweise keine anfälligen Datenflüsse aufweist, bedeutet nicht, dass das morgen auch noch so ist. Eine Methode, die heute nicht aufgerufen wird, könnte nach dem nächsten Commit einer anderen Entwicklungsfachkraft aufgerufen werden. Die nächste Person, die am Code arbeitet, weiß wahrscheinlich nicht, dass sich in der verwendeten Bibliothek eine anfällige Methode verbirgt und die Warnung dazu unterdrückt wurde, weil diese Methode bisher nicht aufgerufen wurde. Die Sicherheitsstrategie auf die Annahme zu stützen, dass die Methode heute nicht aufgerufen wird, grenzt an Leichtsinn.

Im Großen und Ganzen ist die Triage nur eine Vorstufe zur Behebung von Schwachstellen. Sie wird eingesetzt, weil die Behebung als schwierig und aufwendig gilt. Aber was wäre, wenn wir statt Software zur Unterstützung der Triage einzusetzen, all das überspringen und die Behebung mithilfe von Software automatisieren?

Snyk-Warnungen per Pull Request beheben – großartig!

Wenn Sie Ihre Projekte zu Snyk hinzufügen, führen wir ein präzises, kontinuierlich aktualisiertes Inventar all Ihrer Abhängigkeiten. Deshalb können wir Sie in Echtzeit über wichtige Schwachstellen wie die Apache-Struts-RCE informieren. Noch wichtiger: Wir können Ihnen genau sagen, welche Ihrer Anwendungen betroffen ist. Wenn Sie Snyk mit Ihrer Quellcodeverwaltung verbinden, etwa mit Github, Gitlab oder BitBucket, können wir noch mehr tun und direkt in Ihren betroffenen Repositories einen Pull Request mit der Behebung erstellen.

Um die Schwachstelle aus Ihrem Code zu entfernen, müssen Sie nur den Pull Request genehmigen. Die Schwachstelle zu beheben, ist in jedem Fall die richtige Entscheidung – unabhängig davon, ob Ihr Code heute über Ihre Datenflüsse ausgeführt wird oder nicht.

So lässt sich nicht nur der gesamte Triage-Prozess durch einen einzigen Klick auf „Annehmen“ im Pull Request ersetzen, sondern auch der erforderliche Umfang an Sicherheitsexpertise im Unternehmen reduzieren. Sicherheit einfach und schnell gemacht – ziemlich cool.