Schwachstellenbewertung (IT)

aus SecuPedia, der Plattform für Sicherheits-Informationen

Anzeige
Wechseln zu: Navigation, Suche

Im Rahmen einer Schwachstellenanalyse werden Schwachstellen eines IT-Produktes/Systems identifiziert und bewertet, um festzustellen, ob es Schwachstellen gibt, die beim vorgesehenen Einsatz des Produktes/Systems ausgenutzt werden könnten.

Grundlagen

Ausgangspunkt für eine Schwachstellenbewertung sind Annahmen zum vorgesehen Einsatz des Produktes. Diese schließen die vorgesehene Art der Nutzung, die vorgesehene Einsatzumgebung und bei Produkten die angenommenen Bedrohungen ein. Bei Systemen sind dagegen die Einsatzbedingungen besser bekannt, so dass hier weniger von Annahmen ausgegangen werden muss.

Von diesen Annahmen können die Fachkenntnisse, die Ausrüstung und die Gelegenheiten, die einem potentiellem Angreifer zur Verfügung stehen könnten, abgeleitet werden.


Verfahren

Davon ausgehend, werden zunächst alle Wege gesucht, die es einem Angreifer erlauben würden, die Sicherheitsfunktionen des Produktes/Systems zu deaktivieren, zu umgehen, zu verändern, direkt anzugreifen oder anderweitig außer Kraft zu setzen.

Anschließend werden alle identifizierten Schwachstellen hinsichtlich des Aufwandes, der jeweils für die Ausnutzung der Schwachstelle erforderlich ist, bewertet. Der ermittelte Aufwand schließt die erforderlichen Fachkenntnisse, die Ausrüstung, den Zeitaufwand, die Zugriffsmöglichkeiten auf das Produkt jeweils für die Identifikation der Schwachstelle, der Vorbereitung sowie der Durchführung des Angriffs ein. Die Ausnutzbarkeit von Schwachstellen kann theoretisch und/oder anhand von Penetrationstests nachgewiesen werden.

Der Aufwand für die Ausnutzung einer Schwachstelle muss stets höher sein, als das für den vorgesehenen Einsatz des Produktes angenommene Bedrohungspotential, andernfalls gilt diese Schwachstelle als ausnutzbar.

Darüber hinaus ist auch zu berücksichtigen, inwieweit durch den Entwicklungs-/ und Produktionsprozess sowie durch das Auslieferungsverfahren sichergestellt ist, dass das Produkt integer und authentisch beim Benutzer ankommt.

Während des Produkteinsatzes sollte fortlaufend weiter beobachtet werden, ob neue Schwachstellen bzw. einfachere Angriffe zu den bereits analysierten Schwachstellen bekannt geworden sind.

Der Evaluator muss für die Schwachstellenbewertung alle Informationsquellen berücksichtigen, die er für eine ausreichende Analyse vor dem Hintergrund der getroffenen Annahmen benötigt. Das können u. a. sein:

  • Handbücher (Benutzer, Administrator)
  • Designdokumente (z. B. Schnittstellenbeschreibungen)
  • Source code (Quellcode) bzw. Schaltpläne
  • Informationen zum Auslieferungsverfahren
  • Informationen zur Entwicklungs- und Produktionsumgebung
  • Schwachstelleninformationen (z.B. aus öffentlichen Schwachstellendatenbanken).


Ursachen von Schwachstellen

  • Fehler in den Anforderungen
    Ein Produkt/System enthält Schwachstellen, obwohl es seine Spezifikationen erfüllt, da die Anforderungen in Bezug auf die Sicherheit falsch oder unvollständig sind.
  • Fehler in der Konstruktion
    Ein Produkt/System erfüllt nicht seine Spezifikationen, weil Schwachstellen infolge niedriger Konstruktionsstandards oder falscher Entwurfsentscheidungen eingebracht wurden.
  • Fehler im Betrieb
    Ein Produkt/System wurde korrekt gemäß einer korrekten Spezifikation konstruiert, aber es wurden Schwachstellen infolge unangemessener Betriebskontrollen eingeführt.


Arten von Schwachstellen

  • Konstruktionsbedingte Schwachstellen
    Schwachstellen, die während der Entwicklung des Produktes eingeführt wurden.
  • Direkt angreifbare Sicherheitsfunktionen
    Sicherheitsfunktionen, die auf einem Wahrscheinlichkeits- oder Permutationsmechanismus (z. B. Passwort- oder Hashfunktion) beruhen, können selbst dann, wenn sie nicht umgangen, deaktiviert oder verändert werden können, durch einen direkten Angriff überwunden werden (z. B. eine Passwortfunktion durch das Ausprobieren aller möglichen Passwörter).
  • Verdeckte Kanäle
    Unerwünschte Kommunikationskanäle, die für Angriffe ausgenutzt werden könnten.
  • Mangelnde Benutzerfreundlichkeit
    Ein Produkt kann in einer Weise konfiguriert oder benutzt werden, die unsicher ist, bei der aber ein Administrator oder ein Benutzer vernünftigerweise davon ausgeht, dass sie sicher ist.


Siehe übergeordnete Stichworte


Siehe auch




Diese Seite wurde zuletzt am 24. April 2012 um 03:43 Uhr von Peter Hohl geändert. Basierend auf der Arbeit von Oliver Wege, Admin und Christian Krause.

Anzeigen