Wie läuft ein OSSTMM Security Audit ab?

Open Source Security Testing Methodology Manual – kurz OSSTMM – ist eine wissenschaftliche Methodik, um die Sicherheit von Websites, Webapplikationen, Datenbanken, IT-Infrastrukturen und vielem mehr zu klassifizieren. Die Methodologie gibt vor, wie ein Security Audit geplant, durchgeführt und korrekt dokumentiert werden sollte.

Entwickelt wurde OSSTMM vom Institute for Security and Open Methodologies (ISECOM). OSSTMM ist frei verfügbar und inzwischen ein De-facto-Standard für Sicherheitsprüfungen.

Die 10 Operational Controls als Schutzmechanismen

Beim Security Audit nach OSSTMM betrachten Security Tester die Angriffsfläche (Attack Surface) eines Assets (Vermögenswert).

Die Angriffsfläche ist die Basis für jede Risikobeurteilung, denn sie zeigt, wie verwundbar ein Asset ist und wie es angegriffen werden kann.

Die operative Sicherheit dient der Prävention von Angriffen. Sie setzt nicht-interaktive Grenzen, um Interaktionen und unberechtigte Zugriffe zu verhindern. Dabei klassifiziert sie Interaktionen in:

• Visibilities (Sichtbarkeiten)
• Accesses (Interaktionen von ausserhalb des Scopes)
• und Trust (Interaktionen zwischen Entitäten innerhalb des Scopes).

Die OSSTMM-Methodik kennt für das Setzen der nicht-interaktiven Grenzen zehn Operational Controls, die als Schutzmechanismen für ein System dienen. Diese zehn Operational Controls sind:

1. Authentication = Abfrage von Anmeldeinformationen
2. Indemnification = Sichtbare Warnungen bei unberechtigten Zugriffen
3. Resilience = Resilienz des Systems; bei einem Fehlerfall darf nicht automatisch das ganze System freigeschaltet werden
4. Subjection = Unterjochung; Interaktionen dürfen nur nach definierten Prozessen stattfinden
5. Continuity = Kontinuität des Systems; die Interaktivität mit dem Asset muss im Falle eines Angriffs aufrechterhalten bleiben
6. Non-Repudiation = Nicht-Verleugnung; betrifft alles, was mit Logging zu tun hat
7. Confidentiality = Vertraulichkeit, Verschlüsselungen
8. Privacy = Datenschutz, z.B. Port-Knocking
9. Integrity = Integrität gewährleisten, z.B. durch Signaturen
10. Alarm = Steuerung, um eine Interaktion zu melden

Die 5 Kategorien von Sicherheitslücken

Wie gut die Operational Controls funktionieren, hängt von fünf Limitations ab. Limitations sind die Sicherheitslücken eines Systems, die je nach Schweregrad in fünf Kategorien eingeteilt werden können:

1 Vulnerability = Lücke im Sicherheitsmechanismus
2 Weakness = Schwachstelle in der Plattform
3 Concern = keine direkte Bedrohung, entspricht aber nicht den Best Practices
4 Exposure = Preisgabe von Informationen
5 Anomaly = Unbekannte im System

Um die Angriffsfläche bei einem Security Audit nach OSSTMM zu messen, prüfen die Security Tester, ob die zehn Operational Controls eingehalten werden und ob Limitations vorhanden sind. Pluspunkte im Test gibt es, wenn die Controls vorhanden und gut sind, Minuspunkte, wenn Angreifer sie umgehen können.

Alles wird gegeneinander aufgerechnet und am Ende der Rechnung steht der Risk Assesment Value (RAV). Dieser setzt die Angriffsfläche ins Verhältnis zu den Sicherheitsmassnahmen und gibt so Auskunft über das aktuelle Sicherheitsniveau eines Systems.

Ein Beispiel: Security Audit einer Website nach OSSTMM

Im DigiSnack-Webinar «Zuverlässige Security Tests mit der OSSTMM-Methodologie» hat Senior Penetration Tester Yves Kraft ein Security Audit einer E-Commerce-Website nach OSSTMM im Schnelldurchlauf (ca. 15 Minuten) durchgeführt.

Sehen Sie sich den Ablauf des Security Audits im obigen Video an oder lesen Sie unten, welche Erkenntnisse das Quick-Audit gebracht hat:

• Die Website läuft auf einem Server.
• Es gibt drei offene Ports (Webports und einen Remotezugang).
• Nicht nur TSP (Telecom Service Provider), sondern auch ISP (Internet Service Provider) ist gegeben.
• Um ein Produkt zu kaufen, muss man sich anmelden. Die Operational Control Authentication ist somit gegeben.
• Impressum, Datenschutzbestimmungen, AGB und Cookie-Einstellungen sind vorhanden, somit auch viermal die Operational Control Indemnification.
• Wenn die Benutzerinnen und Benutzer die Website über das http-Protokoll aufrufen, werden sie auf https umgeleitet. Damit ist die Control Subjugation gegeben.
• Die Website verfügt über verschlüsselte Verbindungen, nämlich https und SSH. Die Controls Confidentiality und Integrity sind erfüllt.
• Es gibt ein Wildcard-Zertifikat, daher liegt die Limitation Weakness vor.
• Der HSTS-Header istgesetzt, aber nicht vollständig konfiguriert. Die Limitation Concern ist in diesem Fall gegeben.
• Die Versionsinformationen für den Webserver, SSH und das Betriebssystem sind auf dem Printscreen ersichtlich. Somit ist die Limitation Exposure erfüllt.

So wird der Risk Assessment Value (RAV) berechnet

Die gesammelten Erkenntnisse ergeben im RAV-Calculator folgende Berechnung:

Der RAV ist zwar kein Prozentwert, aber hinter der Berechnung steht eine logische Formel auf der Basis von 10, die einen Wert zwischen 0 und 100 Prozent nahelegt.

Ein Wert von 100 Prozent wäre das perfekte Gleichgewicht zwischen Angriffsfläche und Sicherheitsmassnahmen.

Werte unter 80 Prozent deuten auf eine potenziell grosse Angriffsfläche hin.

Werte zwischen 85 und 90 Prozent sind gut für eine E-Commerce-Website.

Für die Beispielseite ergibt sich aus den Berechnungen ein Wert von 89 Prozent.

Der Nutzen von OSSTMM und RAV

Das Security Audit nach OSSTMM liefert eine objektive und eindeutige Aussage zur Sicherheit eines Systems und kann regelmässig unter den gleichen Bedingungen wiederholt werden, um den Erfolg von Sicherheitsmassnahmen zu überprüfen.

Der aus dem Security Audit nach OSSTMM resultierende RAV beantwortet folgende Fragen:

• Wie viel (mehr) Geld soll für die Sicherheit des Systems ausgegeben werden?
• Was soll zuerst gesichert werden?
• Welche Schutzlösungen braucht das System und wie sollten diese für den maximalen Schutz aufgestellt werden?
• Wie viel Verbesserung wird durch die spezifische Sicherheitsbeschaffung und die Prozesse erreicht?
• Wie messen Sie die periodischen Sicherheitsanstrengungen und -Verbesserungen?
• Sind Ihre Assets exponiert? Werden potenzielle Bedrohungen reduziert?
• Wie gut widersteht Ihr System Angriffen?
• Entspricht das System den Auflagen und Regularien?