Ein Angebot von

Qualitätssicherung

Wie verwundbar sind Sie? Lücken im Code effektiv ermitteln

| Autor / Redakteur: Bill Graham * / Franz Graser

Überblick: Schema eines einfachen Prozesses für den Einsatz statischer Analysetools bei Security-Audits und anschließenden Verbesserungen der Sicherheit. Am Anfang sollte eine ausführliche Bedrohungsanalyse stehen. Daraus ergibt sich dann der Einsatz der Tools.
Überblick: Schema eines einfachen Prozesses für den Einsatz statischer Analysetools bei Security-Audits und anschließenden Verbesserungen der Sicherheit. Am Anfang sollte eine ausführliche Bedrohungsanalyse stehen. Daraus ergibt sich dann der Einsatz der Tools. (Bild: GrammaTech)

Dieser Artikel beschreibt eine Methode, wie man Schwachstellen in der Software verstehen und die statische Analyse als Teil eines kontinuierlichen Verbesserungsprozesses nutzen kann.

Die Wahrscheinlichkeit dafür, dass ein Gerät Opfer einer Cyber-Attacke wird, hängt von den potenziellen Auswirkungen einer Attacke ebenso ab, wie davon, ob ein solcher Angriff möglich ist. Also nimmt man 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: Kennt man die Quellen von Angriffen und ihre Motivationen, lässt sich leichter verstehen, welche Ziele eine Attacke haben kann, und ob ein Angriff einer solchen Gruppe erfolgreich sein könnte.
  • Rollen und Privilegien autorisierter Nutzer: Die Identifikation von Benutzern und ihren Zugriffsrechten ist entscheidend für die Durchsetzung des elementaren Least-Privilege-Prinzips. Die Beschränkung der Zugriffsberechtigungen der betrieblichen Nutzer mit dem Ziel, gefährliches Verhalten zu unterbinden, hindert Insider und Angreifer am Zugang zu mehr, als ihnen gemäß ihren Zugriffsberechtigungen zusteht.
  • Identifikation potenzieller 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 ist.
  • 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. Attacken von außerhalb des zu verteidigenden Netzwerksegments, die große Auswirkungen und einen geringen Schwierigkeitsgrad haben, wird eine hohe Bedrohungsmetrik zugewiesen. Jede Kombination aus Quelle und Motivation, Angriffsvektor und Schwierigkeitsgrad des Angriffs muss eine Bewertungsziffer erhalten.

Tools für die statische Analyse richtig konfigurieren

Fortschrittliche statische Analysetools 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, doch handelt es sich dabei nicht unbedingt immer um diejenigen Defekte, die für den Einzelfall relevant 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, empfiehlt sich, 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 Maßnahmen ergriffen werden.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44602395 / Test & Qualität)