So verwenden Sie die statische Analyse richtig

Jetzt sprechen immer mehr Menschen über statische Analysen, um nach Schwachstellen als notwendigem Entwicklungsstand zu suchen. Viele sprechen jedoch über die Probleme der statischen Analyse. Wir haben in den vergangenen Tagen der Positive Hack viel darüber gesprochen und basierend auf den Ergebnissen dieser Diskussionen bereits darüber geschrieben, wie der statische Analysator funktioniert. Wenn Sie ein ernsthaftes Tool ausprobiert haben, könnten Sie durch lange Berichte mit verwirrenden Empfehlungen, Schwierigkeiten bei der Einrichtung des Tools und Fehlalarmen abgeschreckt werden. Ist also noch eine statische Analyse erforderlich?

Unsere Erfahrung zeigt, was benötigt wird. Und viele der Probleme, die beim ersten Blick auf das Tool auftreten, lassen sich durchaus lösen. Ich werde versuchen, Ihnen zu sagen, was der Benutzer tun kann und wie der Analysator aussehen sollte, damit seine Verwendung nützlich ist, und nicht "ein weiteres unnötiges Tool einführen, das Sicherheitspersonal benötigt".

Über statische Analyse

Wir haben also bereits über die theoretischen Grenzen der statischen Analyse gesprochen. Zum Beispiel versucht eine tiefe statische Analyse, Probleme zu lösen, deren Komplexität exponentiell ist. Daher sucht jedes Tool nach einem Kompromiss zwischen der benötigten Zeit, den aufgewendeten Ressourcen, der Anzahl der gefundenen Schwachstellen und der Anzahl der Fehlalarme.

Warum brauchen wir eine eingehende Analyse? Jede IDE findet sehr schnell Fehler, manchmal sogar sicherheitsrelevante - was sind im Allgemeinen exponentielle Probleme? Ein klassisches Beispiel ist die SQL-Injection (und jede andere Injection wie XSS, RCE und dergleichen), die mehrere Funktionen durchläuft (dh das Lesen von Daten vom Benutzer und das Ausführen der Abfrage erfolgt in verschiedenen Funktionen). Seine Suche erfordert eine interprozedurale Analyse des Datenstroms, und dies ist eine Aufgabe von exponentieller Komplexität. Stimmen Sie zu, ohne nach solchen Schwachstellen zu suchen, kann die Analyse nicht als tiefgreifend angesehen werden. Aus dem gleichen Grund müssen Sie den Code in seiner Gesamtheit und nicht in Teilen analysieren - andernfalls könnten Sicherheitslücken zwischen den Prozessen übersehen werden.

In den letzten Jahren habe ich viel Erfahrung in der Kommunikation mit (potenziellen) Kunden verschiedener statischer Analysegeräte gesammelt. Insbesondere diskutieren wir Ansprüche an die Werkzeuge basierend auf den Ergebnissen der ersten Verwendung (Pilot). Die meisten Behauptungen ergeben sich auf die eine oder andere Weise aus den theoretischen Grenzen der Technologie. Darüber hinaus verfügen Tools möglicherweise einfach nicht über die Funktionen, die der Benutzer benötigt. Meiner Meinung nach können sich Analysegeräte jedoch auf den Benutzer zubewegen (und bewegen sich), um die unten angegebenen Probleme zu lösen. Sie müssen jedoch auch in der Lage sein, Analysegeräte zu verwenden, um die Folgen derselben Probleme auszugleichen - wie sich herausstellt, ist dies nicht so schwierig. Lass uns in Ordnung gehen.

Sie können sich eine Modellsituation vorstellen: Sie entscheiden sich, die Technologie in Aktion auszuprobieren oder einen statischen Analysator zu wählen - geben Sie einen Piloten aus. Natürlich vertrauen Sie den Testfällen des Anbieters nicht und möchten versuchen, Ihren Code zu analysieren (gleichzeitig können Sie echte Schwachstellen finden und beheben). Sie erhalten für kurze Zeit ein Installationsprogramm oder eine fertige virtuelle Maschine mit einem System.

Führen Sie die Analyse aus

Zuerst müssen Sie die Analyse ausführen. Sie gehen zur Benutzeroberfläche und alles scheint klar zu sein: Laden Sie das Archiv mit dem Quellcode in das Formular hoch und klicken Sie auf „Analysieren“. Aber nein: Sie erhalten mehrere Formulare mit unterschiedlichen Feldern, die irgendwie ausgefüllt werden müssen. Es ist erforderlich, Programmiersprachen und einige Analyseeinstellungen festzulegen, Schwachstellenpakete auszuwählen (woher wissen Sie, was darin enthalten ist?) Und so weiter. Sie bestehen diesen Test und die Analyse beginnt. Ah, nein - ein Scanfehler. "Das Format entspricht nicht den Anforderungen", "Für diese Sprache ist eine Code-Assembly erforderlich", "Dateien zum Scannen wurden nicht gefunden" ... Wenn Sie diesen Code nicht selbst geschrieben haben, müssen Sie sich dennoch an die Entwickler wenden, um Hilfe zu erhalten.


Der Entwickler übergibt den Quellcode zum Testen

Besonderes Augenmerk wird auf die Anforderungen an die Bauordnung gelegt. Die meisten Analysatoren für eine Reihe von Sprachen erfordern, dass während der Analyse Code gesammelt wird (JVM-Sprachen - Java, Scala, Kotlin und dergleichen, C / C ++, Objective-C, C #). Sie verstehen, wie schmerzhaft es ist: die Umgebung eines großen Projekts für die Montage auf einer neuen Maschine zu reproduzieren. Andererseits sind diese Anforderungen gerechtfertigt, sie ergeben sich aus der Analysetechnologie und den Besonderheiten dieser Sprachen.

Wie lösen Analysatoren diese Probleme? Erstens machen sie den Start der Analyse so automatisiert wie möglich. Im Idealfall reicht es aus, eine Datei eines beliebigen Formats herunterzuladen, und der Analysator selbst muss verstehen, welche Sprachen vorhanden sind, wie versucht wird, die restlichen Einstellungen zu erstellen und die restlichen Einstellungen standardmäßig festzulegen, damit die Ergebnisse so vollständig wie möglich sind. Es ist klar, dass es unmöglich ist, alles vorherzusehen - Sie können jedoch versuchen, die meisten Fälle zu behandeln.

Die Montageanforderungen müssen so weich wie möglich sein. Für JVM-Sprachen müssen Sie beispielsweise während der Analyse keine Assemblierung benötigen. Bitten Sie lediglich darum, Artefakte zu laden, dh den zusammengestellten Code zusammen mit den Quellen (was viel einfacher ist). Bei Xcode kann im Fall von Objective-C die Montage in den meisten Fällen automatisiert werden. Wenn der Code nicht erfasst werden konnte, versucht der Analysator möglicherweise, eine Teilanalyse durchzuführen. Die Ergebnisse werden nicht so vollständig sein, aber es ist besser als gar keine Ergebnisse. Es ist auch praktisch, wenn das Analysemodul auf dem Computer an den Entwickler gesendet werden kann, wo die Code-Assembly bereits konfiguriert ist, während die Architektur die Übertragung der anderen Module und des Schnittstellenteils auf einen anderen Computer ermöglichen sollte.

Schließlich sollte der Analysator die Anforderungen an das weichste Format stellen und sich mit den Eingabedateien selbst befassen. Ein Archiv mit Quellcode, verschachtelten Archiven, einem Archiv aus einem Repository, einem Link zu einem Repository, einem Archiv aus einem Produkt, einer ausführbaren Datei aus einem Produkt - es ist gut, wenn der Analysator all dies unterstützt.

Vergessen Sie jedoch nicht, dass der Analysator keine künstliche Intelligenz besitzt und nicht alles vorhersehen kann. Wenn daher Fehler auftreten, sollten Sie sich mit dem Handbuch vertraut machen. Es gibt viele nützliche Dinge, um den Code für die Analyse vorzubereiten. Nun, all diese Arbeiten zum Starten eines Scans während der Implementierung des Analysators werden nur einmal für jede Codebasis ausgeführt. Meistens ist der Analysator in der Regel in den CI-Zyklus integriert, dh es treten keine Probleme mit der Montage auf.

Analyseprozess

Okay, der Scan hat begonnen. Eine Stunde vergeht - keine Ergebnisse. Der Fortschrittsbalken hängt irgendwo in der Mitte, es ist nicht klar, mit welchem ​​Prozentsatz und welcher Prognose abgeschlossen ist. Die zweite Stunde vergeht - der Fortschritt hat sich um 99 Prozent bewegt und hängt seit einer halben Stunde dort. Die dritte Stunde vergeht und der Analysator stürzt ab und meldet einen RAM-Mangel. Oder hängt noch eine Stunde und endet. Sie können erwarten, dass die Analyse mit der gleichen Geschwindigkeit wie Ihr Checkstyle durchgeführt wird, und hier weichen die Erwartungen stark von der Realität ab.


Ja, ein guter statischer Analysator kann viele Ressourcen verbrauchen. Ich habe einen der oben genannten Gründe genannt: Das Auffinden komplexer Schwachstellen ist eine exponentiell schwierige Aufgabe. Je mehr Ressourcen vorhanden sind und je mehr Zeit zur Verfügung steht, desto bessere Ergebnisse werden erzielt (natürlich mit einem guten Motor). Es ist wirklich schwierig, sowohl die Analysezeit als auch die erforderlichen Ressourcen vorherzusagen - die Betriebszeit der statischen Analysealgorithmen hängt stark von Sprachkonstrukten, der Komplexität des Codes und der Tiefe der Aufrufe ab - von Merkmalen, die im Voraus schwer zu berechnen sind.

Das Problem mit den Ressourcen ist ein notwendiges Übel. Sie müssen bei der Zuweisung der erforderlichen Ressourcen vorsichtig sein, geduldig auf den Abschluss des Scans warten und auch verstehen, dass niemand die für den Analysator erforderlichen Ressourcen selbst bei einer bestimmten Codebasis genau vorhersagen kann, und Sie müssen bereit sein, diese Parameter zu ändern. Darüber hinaus können sich die erforderlichen Parameter auch ohne Aktualisierung der Codebasis ändern - aufgrund des Analysator-Updates.

Trotzdem kann der Analysator bei diesem Problem ein wenig helfen. Es ist in der Lage, den ressourcenintensiven Teil (Engines) und die Schnittstelle in verschiedene Maschinen aufzuteilen. Auf diese Weise können Sie keine Maschinen mit unnötigen Programmen laden, die ihre Arbeit verlangsamen, während Sie die Systemschnittstelle für jede Arbeitslast bei Scans verwenden können (z. B. zum Anzeigen und Bearbeiten von Ergebnissen). Dies erleichtert auch die Skalierung, ohne das gesamte System neu zu installieren (wir erhöhen den Analysator auf einer neuen virtuellen Maschine, geben die IP der Hauptmaschine an - und voila).

Darüber hinaus können Sie mit dem Analysegerät die Analysetiefe auswählen, umfangreiche Überprüfungen deaktivieren und inkrementelle Analysen verwenden (bei denen nicht der gesamte Code überprüft, sondern nur geändert wird). Diese Dinge müssen sehr vorsichtig verwendet werden, da sie die Scanergebnisse stark beeinflussen können. Wenn Sie solche Funktionen verwenden, wird empfohlen, in bestimmten Abständen eine vollständige Analyse durchzuführen.

Analyseergebnisse

Fahren wir mit den Scan-Ergebnissen fort (wir sind lange zu ihnen gegangen). Sie warten voller Angst auf die Anzahl der Schwachstellen im Analysefenster und sind sehr überrascht, dies zu sehen. 156 kritisch, 1260 mittel und 3210 niedrig. Sie gehen zur Ergebnisseite und ertrinken in der Anzahl der gefundenen Probleme. Sie laden einen PDF-Bericht herunter und sehen mehrere tausend Seiten Text. Ratet mal, was der Codeentwickler sagen wird, wenn er eine solche Leinwand sieht?


Der Sicherheitsbeamte übermittelt dem Entwickler einen Schwachstellenbericht

Aber versuchen wir trotzdem, die Ergebnisse zu sehen und ihm eine Chance zu geben. Nachdem Sie Dutzende von Ereignissen sorgfältig untersucht haben, beginnen Sie zu verstehen, warum es so viele Sicherheitslücken gibt. Einige Schwachstellen sehen wirklich ernst aus. Sie verstehen, dass sie behoben werden müssen. Sie finden jedoch sofort etwa ein Dutzend falsch. Und auch - eine große Anzahl von Schwachstellen im Code von Bibliotheken. Sie werden Bibliotheken nicht korrigieren! Und dann verstehen Sie, wie viel Zeit Sie für die Analyse der Ergebnisse aufwenden werden. Und dieser Vorgang muss jeden Tag, jede Woche oder zumindest jede Veröffentlichung wiederholt werden. (Eigentlich nicht).

Falsch positive Ergebnisse können zunächst auf sehr unterschiedliche Weise verstanden werden. Jemand wird nicht nur kritische Schwachstellen als falsch betrachten, die jetzt ausgenutzt werden können. Jemand wird nur explizite Fehler des Analysators als falsch betrachten. Viel hängt davon ab, was Sie vom Tool erwarten. Wir empfehlen, dass Sie fast alle Vorkommnisse berücksichtigen, da selbst eine Sicherheitsanfälligkeit auf niedriger Ebene, die derzeit nicht ausgenutzt werden kann, morgen zu einem ernsthaften Problem werden kann, beispielsweise aufgrund von Änderungen im Code und externen Bedingungen.

Ok, Sie müssen sich alle Einträge ansehen, aber das ist immer noch eine Menge Arbeit. Und hier können die Analysatoren sehr gut helfen. Die wichtigste Funktion des Analysators ist die Fähigkeit, Schwachstellen zwischen Scans eines Projekts zu verfolgen, während die Verfolgung dieser Schwachstellen gegen kleine Änderungen resistent ist, die für die Codeentwicklung Standard sind. Dadurch wird das Problem behoben, dass eine lange Analyse von Schwachstellen wiederholt werden muss: Wenn Sie zum ersten Mal mehr Zeit damit verbringen, Fehlalarme zu entfernen und die Kritikalität von Ereignissen zu ändern, müssen Sie sich nur neue Schwachstellen ansehen, die um ein Vielfaches kleiner sind.

Gut, aber ist es notwendig, alle Schwachstellen zum ersten Mal zu überprüfen? Wir empfehlen dies, aber im Allgemeinen ist dies nicht erforderlich. Erstens können Sie mit Analysatoren Ergebnisse nach Verzeichnissen und Dateien filtern: Wenn Sie beispielsweise einen Scan starten, können Sie Komponenten, Bibliotheken und Testcode sofort von der Analyse ausschließen. Dies wirkt sich auf die Analysegeschwindigkeit aus. Zweitens können Sie mit Analysegeräten die Ergebnisse nach Schwachstellen filtern. Wenn Sie also mit dem Scannen beginnen, können Sie die Anzahl der Schwachstellen begrenzen. Zusätzlich zur Kritikalität kann der Analysator so etwas wie die Wahrscheinlichkeit einer falschen Sicherheitsanfälligkeit (dh das Vertrauen in diese Sicherheitsanfälligkeit) erzeugen. Mit dieser Metrik können Sie die Ergebnisse filtern.

Unabhängig davon ist die Technologie der Software-Kompositionsanalyse erwähnenswert (sie wird jetzt zunehmend von einer zunehmenden Anzahl von Instrumenten auf verschiedenen Ebenen unterstützt). Mit dieser Technologie können Sie die Verwendung von Bibliotheken in Ihrem Code erkennen, Namen und Versionen ermitteln, bekannte Schwachstellen sowie Lizenzen anzeigen. Diese Technologie kann den Bibliothekscode von Ihrem eigenen trennen, wodurch auch die Ergebnisse gefiltert werden können.

Es stellt sich heraus, dass Sie sich mit dem Problem der reichlichen Analyseergebnisse befassen können, und dies ist nicht sehr schwierig. Und obwohl das erste Anzeigen der Ergebnisse tatsächlich einige Zeit in Anspruch nehmen kann, wird es beim Scannen immer weniger ausgegeben. Ich stelle jedoch erneut fest, dass Sie beim Filtern von Ergebnissen vorsichtig sein sollten - Sie können die Sicherheitsanfälligkeit überspringen. Selbst wenn die Bibliothek bekannt ist, bedeutet dies nicht, dass sie keine Sicherheitslücke aufweist. Wenn diese Sicherheitsanfälligkeit jetzt nur unzureichend erkannt wird (das Tool zeigt viele Fehlalarme für diese Sicherheitsanfälligkeit an) und Sie sie deaktivieren, können Sie beim Aktualisieren des Analysators die tatsächliche Sicherheitsanfälligkeit überspringen.

Überprüfen Sie den Analysator

Verstanden mit einem großen Bericht und falsch positiven Ergebnissen. Sie möchten jedoch noch weiter gehen - um sicherzustellen, dass der Analysator die Schwachstellen findet, von denen Sie sicher wissen (Sie hätten sie absichtlich legen oder ein anderes Tool finden können).


Zunächst ist es wichtig zu verstehen, dass der Analysator die Sicherheitsanfälligkeit aus verschiedenen Gründen nicht finden konnte. Das Einfachste ist, dass der Scan falsch konfiguriert wurde (Sie müssen auf die Fehlermeldungen achten). Aus Sicht der Analysetechnologie können die Gründe jedoch unterschiedlich sein. Ein statischer Analysator besteht aus zwei wichtigen Komponenten: einer Engine (die die gesamte algorithmische Komplexität und Mathematik enthält) und einer Basis von Regeln für die Suche nach Sicherheitslücken. Eine Situation besteht darin, dass Sie mit der Engine eine Sicherheitsanfälligkeit dieser Klasse finden können, die Regelbasis jedoch keine Sicherheitsanfälligkeit enthält. In diesem Fall ist das Hinzufügen einer Regel normalerweise nicht schwierig. Eine ganz andere Situation, wenn die Engine solche Schwachstellen im Prinzip nicht unterstützt - hier kann die Überarbeitung sehr bedeutsam sein. Ich habe am Anfang des Artikels ein Beispiel gegeben: SQL-Injection kann ohne Algorithmen zur Datenflussanalyse niemals gefunden werden.

Ein statischer Analysator sollte eine Reihe von Algorithmen in der Engine implementieren, die die verfügbaren Schwachstellenklassen für eine bestimmte Programmiersprache abdecken (Analyse des Kontrollflusses, Datenflusses, Intervallanalyse usw.). Ein wichtiger Punkt ist die Möglichkeit, dem Tool eigene Regeln für die Suche nach Sicherheitslücken hinzuzufügen. Dadurch wird der erste Grund für das Fehlen einer Sicherheitslücke beseitigt.

Wenn Sie also in den Scanergebnissen keine vorhandene Sicherheitsanfälligkeit gefunden haben, müssen Sie zuerst den Grund für das Überspringen herausfinden. In der Regel kann ein Anbieter dabei helfen. Wenn der Grund in der Regelbasis oder in der Scan-Konfiguration liegt, kann die Situation ganz einfach beseitigt werden. Das Wichtigste ist, die Tiefe der Analyse zu bewerten, dh im Prinzip können Sie nach der Engine suchen.

Kompetenzen

Nachdem Sie den Artikel an dieser Stelle gelesen haben, können wir davon ausgehen, dass für die Arbeit mit dem Tool ein tiefes Fachwissen des Entwicklers erforderlich ist, da Sie verstehen müssen, welche Antworten falsch und welche wahr sind. Meiner Meinung nach hängt alles davon ab, wie freundlich sich das Instrument verhält. Wenn es bequeme und verständliche Funktionen, verständliche Beschreibungen von Schwachstellen mit Beispielen, Links und Empfehlungen in verschiedenen Sprachen bietet und das Tool Spuren von Schwachstellen im Zusammenhang mit der Analyse des Datenflusses anzeigt, müssen Sie nicht über umfassende Kenntnisse des Entwicklers verfügen, um alle Feinheiten der Programmiersprache und zu verstehen Frameworks. Es sollte jedoch einen minimalen Hintergrund in der Entwicklung geben, um den Code lesen zu können.

Integration in den Entwicklungsprozess

Am Ende des Artikels gehen wir kurz auf eines der wichtigsten Probleme bei der Verwendung des Tools ein und werden es in den folgenden Artikeln ausführlich behandeln. Angenommen, Sie entscheiden sich für einen statischen Analysator. Sie haben jedoch einen etablierten Entwicklungsprozess, sowohl technologisch als auch organisatorisch, und Sie möchten ihn nicht ändern (niemand wird ihn geben).

Das Tool sollte über eine vollständige nicht grafische Oberfläche (z. B. CLI oder REST-API) verfügen, mit der Sie den Analysator in jeden Ihrer Prozesse integrieren können. Es ist gut, wenn der Analysator vorgefertigte Integrationen mit verschiedenen Komponenten hat: Plug-Ins für IDE- oder Build-Systeme, Integrationen mit Versionskontrollsystemen, Plug-Ins für CI / CD-Server (Jenkins, TeamCity), Integration mit Projektmanagementsystemen (JIRA) oder Arbeit mit Benutzern ( Active Directory).

Die Integration der statischen Analyse in den Entwicklungsprozess (das sogenannte SDLC) ist der effektivste Weg, sie zu verwenden, wenn der Prozess gut etabliert ist und alle Teilnehmer zustimmen und wissen, warum dies notwendig ist. Durch die ständige Analyse des Codes nach Änderungen oder Aktualisierungen des Analysators können Sie Schwachstellen so früh wie möglich erkennen. Die Trennung der Rollen von Entwicklern und Spezialisten für Informationssicherheit, ein klarer Hinweis auf die Anforderungen an Informationssicherheit und die weiche Integration in den aktuellen Prozess (zum Beispiel zunächst - der beratende Charakter des Systems) ermöglicht es Ihnen, das Tool schmerzlos und nützlich zu verwenden. Allerdings hat niemand die manuelle Verwendung des Tools abgebrochen, wenn Ihr Entwicklungsmodell keinen ähnlichen Prozess impliziert.

Zusammenfassung

Der Artikel enthält grundlegende Empfehlungen für die Verwendung eines statischen Analysegeräts. Ein guter Analysator arbeitet um eine Größenordnung besser als jeder leichte Prüfer und sucht nach Problemen mit einer grundlegend anderen Komplexität. Daher ist es notwendig, mit den Merkmalen der statischen Analyse als Technologie zu rechnen, aber gleichzeitig ein bestimmtes Werkzeug auszuwählen, damit seine Funktionalität alle diese Merkmale maximal glättet.