Suchen

Expertenbeitrag

Mark Hermeling

Mark Hermeling

Senior Director Product Marketing, GrammaTech, Inc., GrammaTech, Inc.

Software Sicherheit im Fokus

Wie verwundbar ist Ihre Software?

| Autor/ Redakteur: Mark Hermeling / Redaktion IoT

Die Verheißungen der statischen Analyse sind zweifellos überzeugend, doch die meistgestellte Frage lautet: „Wo fangen wir an?“ Weil das Thema Security allerhöchste Priorität hat, heißt es auch oft: „Wie verwundbar ist unsere Software, und wo setzen wir an, um die Schwachstellen zu beseitigen?“ Dieser Text beschreibt einen sinnvollen Ansatzpunkt und eine Vorgehensweise, wie man bestehende Schwachstellen verstehen und die statische Analyse als Bestandteil eines kontinuierlichen Verbesserungsprozesses nutzen kann.

Firma zum Thema

Ohne geeignete Sicherheitsmaßnhamen bieten IT-Strukturen viele Einfallstore für Datenklau und Malware.
Ohne geeignete Sicherheitsmaßnhamen bieten IT-Strukturen viele Einfallstore für Datenklau und Malware.
( gemeinfrei/Pixabay )

Wo beginnt man mit dem Einsatz statischer Analysetools im Rahmen von Security-Audits?

Wie bei jedem automatisierten Softwaretool ist es auch hier wichtig zu wissen, wonach man eigentlich sucht. Geht es um das Aufdecken der Sicherheitslücken in einem System ist ein Security-Audit sinnvoll. Hierzu müssen allerdings vorab einige manuelle Hausaufgaben gemacht werden: Sollte es zum Beispiel für das System keine formelle Bedrohungs-Analyse geben, ist es nun an der Zeit, eine solche durchzuführen, denn für ein Security-Audit ist es entscheidend, dass man über das Bedrohungsumfeld und die Angriffsoberflächen des eigenen Systems Bescheid weiß.

Bedrohungsmodell und Angriffsoberfläche

Die Wahrscheinlichkeit dafür, dass ein Gerät von einer Cyber-Attacke betroffen wird, hängt von den potenziellen Auswirkungen einer Attacke ebenso ab wie davon, ob eine solche Attacke möglich ist. Man nimmt nunmehr eine Beurteilung der Bedrohungslage vor, um ein Bedrohungsmodell zu erstellen und die Angriffsoberfläche zu ermitteln. Zu betrachten sind hierfür die Motivationen und Absichten potenzieller Angriffe ebenso wie die Wege, über die sie das System angreifen, und die Wahrscheinlichkeit für erfolgreiche Attacken:

  • Angriffsquellen und Motivationen – Insider, Aktivisten, Terroristen, Kriminelle, staatlich finanzierte Akteure oder auch Konkurrenten stellen potenzielle Bedrohungen dar. Kennt man die Quellen von Angriffen und ihre Motivationen, lässt sich leichter verstehen, welche Ziele eine Attacke haben kann, und ob eine solche Gruppe mit einem Angriff durchkommen könnte.
  • Rollen und Privilegien autorisierter Nutzer – Die Identifikation von Benutzern und ihren Zugriffsrechten ist entscheidend für die Durchsetzung des elementaren Least-Privilege-Prinzip Die Beschränkung der Zugriffsberechtigungen der betrieblichen Nutzer mit dem Ziel, gefährliche Verfahrensweisen oder das Hinausschleusen sensibler Daten zu unterbinden, hindert Insider und Angreifer am Zugang zu mehr, als ihnen gemäß ihren Zugriffsberechtigungen zusteht.
  • Identifikation potenzieller elektronischer Angriffsvektoren – Meist sind es Netzwerkverbindungen und andere I/O-Ressourcen, die Angreifern den Zugang eröffnen. In einigen Fällen kann der Angriffsvektor intern von einem lokalen Zugang zur Benutzeroberfläche oder einem lokalen Netzwerk ausgehen, während in anderen Situationen sogar der Zugriff per WAN oder Internet möglich sein kann.
  • Beurteilung der Schwierigkeit eines Angriffs – Aus der Verlustabschätzung lässt sich ersehen, welche Dienste und Funktionen von einer Attacke am meisten beeinträchtigt würden. Die relative Schwierigkeit dieser Angriffe muss auf der Grundlage der Angreifer und ihres Angriffsvektors beurteilt werden.
  • Zuweisung einer Bedrohungsmetrik – Jeden Angriff vorherzusehen, ist unmöglich. Ineffizient ist auch der Versuch, sich gegen jeden möglichen Angriff zu wappnen. Angriffen von außerhalb des zu verteidigenden Netzwerksegments etwa, die große Folgewirkungen hätten und einen geringen Schwierigkeitsgrad haben, würde eine hohe Bedrohungsmetrik zugewiesen. Jede Kombination aus Quelle und Motivation, Angriffsvektor und Schwierigkeitsgrad des Angriffs muss eine Bewertungsziffer erhalten.

 

Eine gründliche Bedrohungs-Analyse vermittelt ein Verständnis dafür, welche externen Schnittstellen die größten Angriffsrisiken bergen. Gleichzeitig macht diese Information deutlich, welche Schnittstellen und welche Arten von ‚Tainted Data‘ (vom Eingang) das Ausnutzen von Sicherheitslücken erlauben. Fortschrittliche statische Analysetools eignen sich insbesondere zum Aufdecken von Schwachstellen im Quellcode, darunter auch potenziell gefährliche Datenflüsse. Wenn man weiß, welche Schnittstellen analysiert werden müssen (z. B. das Netzwerk), lässt sich der Umfang der durchzuführenden Analyse bereits eingrenzen.

 

Die Konfiguration statischer Analysetools

Fortschrittliche statische Analysetools wie CodeSonar von GrammaTech bringen in ihrer Grundausstattung eine ganze Reihe von Warn- und Fehlermeldungen mit. Damit werden zwar die entscheidendsten und sinnvollsten Qualitäts- und Security-Defekte abgedeckt, die die Kunden benötigen, doch handelt es sich dabei nicht unbedingt immer um diejenigen Defekte, die für den Einzelfall am relevantesten sind. Bei der Durchführung frühzeitiger Security-Audits kommt es vielmehr auf das Eingrenzen der Analyse an, damit sich der Umfang der auszuwertenden Fehler- und Warnmeldungen auf ein sinnvolles Maß reduziert. Dies geschieht durch Anpassung der folgenden Parameter:

  • Warnungsklassen: Bei den meisten statischen Analysetools lassen sich Checker und Warnungen einzeln ein- und ausschalten. Da die Voreinstellungen für ein Security-Audit möglicherweise nicht ideal sind, wird empfohlen, die wichtigsten Fehlerklassen zu aktivieren, die weniger essenziellen Klassen dagegen zu beschränken.
  • Tainted-Data-Typen: Nicht alle Datenquellen sind potenzielle Angriffsvektoren oder in allen Systemen vorhanden. Zum Beispiel sind Netzwerk-Datenquellen bei vernetzten Geräten die Regel, während es Anwender- oder Dateieingaben nicht sind. Wichtig sind hier die Bedrohungsanalyse und die Angriffsoberfläche aus dem vorigen Schritt. Durch Beschneiden der analysierten Quellen reduziert man die Zahl der Falsch-Positivmeldungen und der Reports.
  • Uninteressanter Code: Subsysteme lassen sich so einschränken, dass unerwünschter Code aus der Analyse herausgehalten wird. Da die Tools die Intention der Software nicht verstehen, lässt sich durch manuelles Beschneiden des Codes die Analyse gezielt auf die wichtigen Abschnitte des Systems richten.
  • Abwägung zwischen Gründlichkeit und Zeitaufwand: Gelegentlich ist die Tiefe der Analyse einstellbar. Hier sollte für ein Security-Audit der höchstmögliche Wert gewählt werden. Es kommt darauf an, dass die Analyse so vollständig wie möglich ist, bevor hinsichtlich der aufgedeckten Schwachstellen irgendwelche Maßnahmen ergriffen werden.

Das Eingrenzen der Analyse auf die wichtigsten Schwachstellen ist wichtig, um einen ersten Überblick über die Sicherheitslage zu bekommen. Mit der Zeit lassen sich diese Parameter für ein umfassenderes Audit verändern, wie die folgende Grafik zeigt:

 

Grammatech

Auswertung der Ergebnisse

Mit den im vorigen Schritt konfigurierten, eingegrenzten Ergebnissen kann die eigentliche Analyse beginnen. Indem man die Resultate nach Priorität ordnet, lässt sich die Arbeit auf die wirklich kritischen Schwachstellen fokussieren. Zum Beispiel werden Pufferüberlauf-Fehler als kritischer angesehen als eine Warnung zum Programmierstil. Deshalb wird zu folgender Vorgehensweise geraten:

  • Priorisierung: Ordnen Sie die Fehler nach ihrer Priorität, bevor Sie ihre Gültigkeit analysieren. Es besteht die Möglichkeit, dass sich Falsch-Positiv-Meldungen in die Reports eingeschlichen haben. Um aber Zeit zu sparen, empfiehlt es sich zunächst die Fehler mit der höchsten Priorität zu analysieren. Möglicherweise bedürfen die Reports mit der geringsten Priorität gar keiner Überprüfung (sodass sie wahrscheinlich, wie oben beschrieben, komplett deaktiviert werden sollten).
  • Evaluierung: An dieser Stelle müssen die von den Tools gelieferten Reports in der Reihenfolge ihrer Priorität überprüft werden. Gravierende Fehler und der mit ihnen zusammenhängende Datenfluss sollten detailliert gecheckt werden. Die von Tools wie CodeSonar erzeugten detaillierten Reports helfen bei der Verifikation eines jeden Fehlers mit der Möglichkeit, sie jeweils als wahr oder falsch zu markieren und gegebenenfalls Bemerkungen anzufügen.
  • Kommentierung und Report: Die meisten fortschrittlichen statischen Analysetools liefern Reports zu jedem Analyselauf des Quellcodes. Sind die kritischen Schwachstellen validiert und kommentiert, ist der Security-Audit zum Quellcode fertig.
  • Ein fertiggestelltes Security-Audit kann für das weitere Risikomanagement, Abhilfemaßnahmen und Tests verwendet werden und lässt sich auch für die Gegenüberstellung mit Folgeversionen der Software nutzen. Es kommt darauf an, dass die statische Analyse zum Bestandteil eines iterativen Konzepts zur Verbesserung der Sicherheit wird.

Fazit

Statische Analysetools sind ein wirksames Hilfsmittel zur Verbesserung der Sicherheit. Die Einführung dieser Tools aber und die Festlegung eines Startpunkts für Ihr Team können zunächst schwierig erscheinen. Das Verstehen der Zielsetzungen ihres Security-Audits und Ihrer Bedrohungsbeurteilung kann bei der Einengung des Fokus helfen, wodurch die Analyseergebnisse an Relevanz und Nützlichkeit gewinnen. Durch Konfigurieren der Tools und Gliedern der Resultate nach Wichtigkeit wird der Audit-Prozess gestrafft, sodass er belastbare Ergebnisse hervorbringt.

Über den Autor

Mark Hermeling

Mark Hermeling

Senior Director Product Marketing, GrammaTech, Inc., GrammaTech, Inc.

Photo by israel palacio on Unsplash; www.pexels.com; gemeinfrei; Quelle: Flexera; Shutterstock; gemeinfrei/Pixabay; Bild: GrammaTech; Analyse von Binär-Code: Den Drittanbietern auf die Finger schauen (Bild: GrammaTech); Bild: Pixabay; Avnet Integrated; fischertechnik; Axians; Medisana/Oliver Eltinger; Vogel Communications Group