Autor: Dr. Ulrich Bieberich
Das Thema Sicherheit ist mittlerweile von regulatorischen Dokumenten umzingelt. Etwa die „Verordnung 2016/679 vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten” der EU oder die Veröffentlichungen des National Institute of Standards and Technology (NIST). Zum Beispiel die Special Publication 80053 „Security and Privacy Control for Federal Information Systems and Organizations”.
Um diese und noch viele andere Verordnungen einhalten zu können, sind Sicherheitstests unumgänglich. Andererseits hat der Testing Guide 4 des Open Web Application Security
Projects (OWASP) schon 2013 festgestellt, dass zwar die Zeit zwischen der Entdeckung einer Gefährdung und ihrem Patch gleich bleibt, die Zeit bis zur aktiven Ausnutzung jedoch immer kürzer wird [1]. Umso notwendiger wird die Durchführung angemessener
Schritte zur Risikoanalyse und der regelmäßige Test des Produkts auf Sicherheitslücken.
Secure Development Life Cycle
Wenn wir von Sicherheit reden, dann müssen wir zwei Themen unterscheiden: Sicherheitstest einer Firma und ihrer Infrastruktur oder Sicherheitstest eines Produkts.
Der klassische Software Development Lifecycle erfuhr mittlerweile eine Erweiterung und wurde zum Secure Development Lifecycle (SDLC) [2]. Er enthält eine ganze Reihe von Arbeitsschritten, die Sicherheit gewährleisten sollen. Einige unerlässliche, aber bei weitem nicht alle, sollen hier kurz angerissen werden [3]:
Bei der Projekt-Klassifizierung geht es unter anderem um die Analyse der folgenden Punkte:
- Gibt es Anfragen von Kunden bzw. Behörden zur Sicherheit des Produkts?
- Gibt es regulatorische Anforderungen?
- Will ein Kunde eigene Sicherheitstests durchführen?
- Welche Aufmerksamkeit erreichen erfolgreiche Angriffe auf das Produkt und wie groß ist der Imageverlust für den Produzenten oder hat er rechtliche Konsequenzen?
Im Schritt Bestimmung der Assets/ Firmenwerte geht es darum, welche Werte gefährdet sein könnten und was die wertvollen Eigenschaften des Produkts sind. Die Risikoanalyse beschäftigt sich mit Fragen wie:
- Wer ist daran beteiligt?
- Wann wird sie zum ersten Mal durchgeführt und wie oft wird sie wiederholt?
- Welche Methode wird verwendet?
- Welche Risiken enthält das Produkt, wie wahrscheinlich ist es, dass sie auftreten und welche Folgen hat ihr Eintreten?
- Welche der erkannten Risiken können zu welchem Zeitpunkt und mit welchem Aufwand beseitigt werden? [4]
Es gilt Programmierrichtlinien zu erarbeiten. Dabei werden mindestens Schulungen für die Entwickler angesetzt, über die Programmiersprache entschieden, Design-Richtlinien, Zeitpunkt und Methode der Code Analyse festgelegt. Sehr viele Produkte enthalten zudem
Fremdsoftware. Deren aktive Entwicklung ist zu hinterfragen. Die Veröffentlichung von Verwundbarkeiten und Patches durch den Anbieter der Fremdsoftware sind Basis, um über deren Sicherheit entscheiden zu können. Bei der Festlegung von Sicherheitsanforderungen werden Meilensteine in der Entwicklung definiert, zu denen
Sicherheitsanforderungen zu verwirklichen sind. Außerdem werden Konsequenzen und Maßnahmen festgehalten, wie die Entwicklung weitergehen kann, wenn die Sicherheitsanforderungen nicht eingehalten werden können. Außerdem muss eine Konfiguration und System-Härtung erfolgen. Es muss unter anderem geprüft werden, ob kritische Daten auf dem System und beim Versenden verschlüsselt werden. Ob es Standard-Passwörter zum Einrichten des Produkts beim Kunden gibt und wie diese nach der Konfiguration geändert werden. Aber nicht nur das eigene Produkt, sondern auch das Betriebssystem ist auf seine Härtung zu prüfen. Offene Schnittstellen wie FTP sprechen nicht für ein gehärtetes System. Im Hotfix/Patch Prozess wird geprüft, wie oft das Produkt Sicherheitspatches erhält und wie diese installiert werden. Schließlich erfolgt die Bewertung des Restrisikos. Was bedeutet es für das Produkt, wenn nicht alle Risiken beseitigt werden können? [5] Und wer bewertet das Restrisiko und wann? Die Antworten auf solche Fragen bestimmen und strukturieren den Test, der die Entwicklung des Produkts begleitet. Auf der Ebene der Software-Entwicklung läuft der Test unter dem Stichwort „statische Code Analyse“, die eigentlich keine statische mehr ist, sondern begleitend zur Software-Entwicklung den nichtkompilierten Code nach Fehlern untersucht. Dieser Test ist bei größeren Produkten nur als automatischer Test mit Werkzeugunterstützung möglich.
STIG und CVE
Alle anderen Punkte der Sicherheitsanforderungen müssen explizit getestet werden. Dafür gibt es zwei Hilfsmittel, die die Planung und Durchführung des Tests erleichtern: die STIGs und die CVE. Das Department of Defence der USA hat 2002 die Entwicklung von Security
Technology Implementation Guides (STIGs) angestoßen. STIGs sind Listen mit Sicherheitsanforderungen für mittlerweile zirka 450 Produkte. Abgedeckt werden aktuelle Betriebssysteme, viel genutzte Software-Produkte, mobile Geräte, Netzwerk-Produkte. [6] Zwei Beispiele: der Windows 10 STIG enthält 280, der Red Hat Linux STIG 259 Anforderungen. Die für das Produkt passenden STIGs müssen zum Teil von Hand getestet
werden, der andere Teil kann mit verschiedenen Werkzeugen automatisch ausgeführt werden. Die Sicherheitsanforderungen der STIGs sind nicht statisch: Viermal im Jahr werden sie aktualisiert. Das zweite Standbein des Sicherheitstests ist die Datenbank der „Common Vulnerabilities and Exposure” (CVE). Hier werden alle bekannten und geschlossenen Verwundbarkeiten verzeichnet. Sie wird beim NIST als „National Vulnerability Database“ (NVD) gespiegelt. [7] Diese Datenbank muss regelmäßig nach den Patchdays der großen Produkthersteller abgearbeitet werden. Auch dafür gibt es Werkzeugunterstützung.
Passive und aktive Sicherheit
Alle bisher aufgezählten Schritte der Planung und eingeleitete Maßnahmen können nur passive Sicherheit gewährleisten. Denn bisher wurden Sicherheitsaspekte betrachtet, die allgemeiner Natur sind oder sicherheitsrelevante Fehler, die andere schon gefunden haben. Das Reagieren auf Patchdays von Software-Herstellern ist ein eindeutiges Zeichen für diesen Zustand des Tests. Unentdeckte Fehler im eigenen Produkt werden dadurch
nicht berücksichtigt. Aktive Sicherheit kann nur durch produktspezifische Tests erreicht werden. Aktive Sicherheit heißt, proaktiv und explorativ mögliche Schwachstellen und Angriffsszenarien zu finden und wenn möglich zu schließen. Erst Fuzzing und Penetrationstests können aktive Sicherheit gewährleisten. Fuzzing ist eine Methode, bei der die Schnittstellen eines Produkts mit gezielten, unerwarteten Daten auf Robustheit
getestet werden. Für gängige Protokolle, wie Imap, Pop3, http, https, dicom, smb, TLS, wifi und viele mehr gibt es Werkzeugunterstützung. Der Penetrationstest, der Test mit Werkzeugen und Methoden eines Hackers, ist das Herzstück des Sicherheitstests. Im Gegensatz zum Angriff auf das Produkt von außen (der Hacker weiß nicht genau,
was er vor sich hat), wird der Penetrationstest gerne als „grey box test“ gefahren. Der Tester kennt zwar nicht den SourceCode, aber die Systemarchitektur des Produkts. Ein solcher Test ist ein „negativer” Test, er will nachweisen, dass das Produkt böswilligen Angriffen standhält. [8]
Kontrollierte Sicherheit
Vollständige Sicherheit des Produkts kann ein Test niemals erreichen. Das Ziel des Tests ist es „kontrollierte Sicherheit” zu gewährleisten.
Kontrollierte Sicherheit ist der Zustand, wenn das Produkt nur noch ein akzeptables Risiko aufweist. [9] Wann das erreicht ist, darauf muss wiederum der Software Development Life Cycle, insbesondere die Risiko Analyse und die Bestimmung der Assets, Antwort geben. Der Test zur Produkt-Sicherheit ist keine einmalige Angelegenheit. Jede Änderung im Produkt, etwa neue Funktionen oder das Aufspielen von Patches, erfordert ein erneutes Abarbeiten des Prozesses von der Risikoanalyse zur Testplanung, Durchführung und Bewertung.
Eine abschließende Bemerkung:
„Functionality testing does not test a
product’s security. Even if a vulnerability is difficult to discover, someone will
discover it given enough time. Various
types of people test software security:
security testers who work for software
development companies, malicious
users who hunt for security vulnerabilities so that they can commit crimes or
spy, security consultants who are hired
to break into a target, and hobbyists
who do it for fun and profit.” [10]
Quellen:
1 https://www.owasp.org/images/1/19/OTGv4.pdf page 12f
2 https://www.microsoft.com/en-us/download/details.aspx?id=29884 http://www.microsoft.com/en-us/SDL
3 Welche Arbeitsschritte des SDLC essenziell sind, welche Werkzeuge Unterstützung bieten, wie sie dokumentiert werden können, wie der Test sie wiederum beeinflusst, welche Maßnahmen sich daraus ableiten, kann hier nicht tiefer betrachtet werden.
4 Meltdown (CVE-2017-5754) und Spectre (CVE-2017-5753) sind zwei Risiken, die im eigenen Produkt mit eigenen Mitteln nicht beseitigt werden können.
5 Das ist eigentlich immer so; alle Schwachstellen und Verwundbarkeiten sind niemals bekannt.
6 https://iase.disa.mil/stigs/Pages/index.aspx
7 https://nvd.nist.gov/ ; https://cve.mitre.org/index.html
8 T.Gallagher, Hunting Security Bugs, Microsoft Press 2006 schreibt pointiert „the tester verifies that bad things don’t happen“
9 FDA, Postmarket Management of Cybersecurity in Medical Devices, 9
10 T.Gallagher, Hunting Security Bugs, Microsoft Press 2006, 9
[/sq_restrict_content]
