Was bleibt, wenn der sichere Entwicklungsprozess funktioniert?

Meinen letzten Blog-Beitrag habe ich mit den Worten „Ungeachtet möglicher Restrisiken...“ begonnen. Genau auf diese Restrisiken möchte ich mich heute konzentrieren. Dazu werde ich zunächst definieren, wann wir von Restrisiken sprechen können, um dann genau diese etwas näher zu beleuchten.

Restrisiken - eine kurze Definition

Im ökonomischen Sinne kann man Restrisiken definieren als die Risiken, die ich als Unternehmen oder als Person tragen kann. Das heißt, „meine“ Risikoexposition ist für mich akzeptabel und der Eintritt eines solchen Risikos mag zwar schmerzhaft sein, hat aber keine gravierenden Auswirkungen auf mein Unternehmen oder mich als Person. Dies ist im Wesentlichen das Ziel eines Risikomanagementprozesses. Interessant sind natürlich die Fälle, wo einem katastrophalen Ereignis eine sehr, sehr geringe Eintrittswahrscheinlichkeit gegenübersteht, zum Beispiel die Wahrscheinlichkeit, dass mir ein Meteorit auf den Kopf fällt. Aber dazu ein anderes Mal mehr.

Auf diesen ökonomischen Aspekt möchte ich nicht weiter eingehen - auch wenn er streng genommen für meine weiteren Ausführungen relevant ist. Denn natürlich ist die Entwicklung und der Betrieb von Software auch ein Teil des ökonomischen Risikomanagements.

Mich interessiert vielmehr die Maximalperspektive: Was bleibt an Risiko übrig, wenn ich alle technischen und organisatorischen Möglichkeiten konsequent ausschöpfe? Ich bin mir bewusst, dass ich damit wahrscheinlich die Grenze des Notwendigen überschreite.

Im nächsten Schritt möchte ich kurz diskutieren, was überhaupt getan werden müsste, damit ich von technisch und organisatorisch unvermeidbaren Risiken sprechen kann.

Voraussetzung für die Erreichung des Minimal-Risikos

Eine Voraussetzung dafür ist die Implementierung eines sicheren Softwareentwicklungsprozesses und eines möglichst sicheren Betriebs (in Kombination oft auch als DevSecOps bezeichnet). Dazu gehören - ohne zu sehr ins Detail zu gehen - folgende Aspekte:

• Vollständige Kenntnis der Sicherheitsanforderungen und Umsetzung der entsprechenden Maßnahmen.
• Durchführung einer Designanalyse oder eines Bedrohungsmodells (gerne auch mehrfach).
• Durchführung von toolgestützten statischen Code-Analysen und punktuelle Ergänzung durch manuelle Code-Reviews sowie Behebung von möglichen Schwachstellen.
• Ein kontinuierliches Dependency Management (manchmal auch Software Composition Analysis genannt), um verwendete 3rd Party Libraries mit Schwachstellen möglichst innerhalb von 24 Stunden zu patchen.
• Eine gehärtete Betriebs- und Netzwerkumgebung.
• Sicherheitsgeprüfte Konfigurationen.
• Sicherer Umgang mit Schlüsseln und Credentials.
• Definierte, implementierte und getestete Wiederherstellungszeiten (etwa RPO, RTO oder WRT).
• Ein adäquates Berechtigungskonzept.
• Ein umfassendes Security-Testkonzept - inklusive möglicher dynamischer Analysen und Penetrationstests.
• Nicht zu vergessen die Expertise in der Bewertung von Sicherheitsmechanismen, Schwachstellen und möglichen Lösungen.
• Maßnahmen zum Schutz vor DDoS- und DoS-Angriffen.

Die Darstellung ist sicherlich etwas verkürzt, soll aber zeigen, dass einfach alle bekannten Maßnahmen mit Expertise umgesetzt werden.

Bleiben da überhaupt noch Rest-Risiken?

Die einfache Antwort lautet „Ja“. Noch einmal, ohne Anspruch auf Vollständigkeit, einige der verbleibenden Risiken:

• Zero-Days (wie in meinem letzten Blog-Beitrag erwähnt), also Schwachstellen vor allem in 3rd-Party-Bibliotheken, die bekannt werden, ohne dass direkt ein Patch verfügbar ist.
• Eine kritische Schwachstelle in einer indirekt verwendeten Bibliothek.
• False Negatives - beispielsweise Schwachstellen im Code, Viren etc., die durch Tests und Checks nicht erkannt werden.
• Fehlentscheidungen, Fehleinschätzungen - zum Beispiel True Positives, die falsch interpretiert werden.
• Rechtemissbrauch, das heißt, ein Mitarbeitender nutzt seine Rechte für einen Betrugsversuch oder auch die verschärfte Variante der betrügerischen Absprache.
• Menschliches Versagen - ein Mitarbeitender macht aus Unachtsamkeit oder in Eile einen schwerwiegenden Fehler.
• DDoS- / DoS-Angriffe mit sehr hohem Volumen.

Für die meisten dieser Restrisiken gibt es natürlich im Idealfall bereits Kompensationsmaßnahmen. Beispielsweise kann man bei der Triage von Schwachstellen im Team agieren oder kritische Prozesse überwachen, um Betrugsversuche im Nachhinein zu erkennen. Allen gemeinsam ist aber meines Erachtens, dass sie nicht vollständig eliminiert werden können.

Hier kommt die wirtschaftliche Betrachtung ins Spiel. In den meisten Fällen dürfte das Restrisiko in einem akzeptablen Rahmen liegen.

Wie sieht die Realität aus?

Mein Steckenpferd ist die Erstellung von Gefährdungsmodellen und Risikoanalysen, so dass ich im Laufe der Zeit einige Projekte unterstützen konnte. In den fast 15 Jahren, in denen ich das nun mache, hat sich schon einiges getan, aber man muss auch sagen, dass in den allermeisten Projekten das oben beschriebene Niveau noch nicht erreicht ist.

Wie immer gibt es aber auch sehr positive Beispiele. Ganz konkret hatte ich in den letzten Monaten zwei Kunden, die ich tatsächlich sehr nahe an diesem „Optimum“ sehen würde. Aber was macht man, wenn man schon sehr gut aufgestellt ist?

Zunächst einmal gilt natürlich, dass Sicherheit ein Prozess ist, das heißt, man darf in seiner Sorgfalt und seinen Anstrengungen nicht nachlassen. Um die Gefahr zu verringern, dass man zu routiniert mit Sicherheitsfragen umgeht, empfehle ich typischerweise folgende Maßnahmen:

1) Vertiefende Schulungen, also neben den eher allgemeinen Awareness-Maßnahmen tatsächlich Schulungen mit neuen Inhalten für die Teams durchführen. So kann man zum Beispiel statt der Wiederholung des klassischen OWASP TOP TEN Secure Coding Trainings durchaus auch ein Hacking Training für Entwickler empfehlen.

2) Gezielt einzelne „Ecken“ beleuchten. Mit meinen Threat Models bin ich oft zunächst auf einer höheren Flughöhe unterwegs. Die Idee ist nun, sich iterativ gezielt einzelne Funktionen anzuschauen - das kann ein Code Review, ein vertieftes Threat Model oder ein ganz spezifischer Whitebox Pentest sein.

3) Rollen- und Perspektivenwechsel durchführen. Um Routine zu vermeiden, bietet es sich beispielsweise an, Security-Expertiinen und -Experten in einer Art Rotationsverfahren in Projekten einzusetzen. Ich persönlich lerne immer sehr gerne von der Erfahrung und auch vom Austausch mit anderen Kollegen, die oft Detailwissen haben, das mir fehlt. Eine neue Sicherheitsexpertin oder ein neuer Sicherheitsexperte bringt mit ihrem/seinem Wissen neue Fragestellungen und Perspektiven ein.

4) Neue Methoden ausprobieren. Red- und Blue-Teaming mit einem Gaming-Aspekt über Projekte hinweg ist eine schon länger bekannte Möglichkeit. Oder man kann zum Beispiel die Threat-Model-Methode abwandeln, wenn man „manuelle“ Methoden bevorzugt, auch mal ein Tool einsetzen oder das Elevation of Privileges Kartenspiel spielen.

5) Loben und anerkennen. Manchmal kann es schon ausreichen, gute Arbeit im Bereich Security positiv zu erwähnen. Schlechte Nachrichten gibt es in diesem Bereich genug.

Fazit

Mein Fazit sollte nicht überraschen. Eine hundertprozentige Sicherheit gibt es nicht, ganz gleich, wie sehr wir uns darum bemühen. Man kann aber mit vernünftigen Prozessen und genügend Expertise ein recht gutes Niveau erreichen, das man auch halten sollte. Grundsätzlich glaube ich, dass wir in der IT-Branche auf dem richtigen Weg sind. Technologietrends wie AI in der Sicherheit können uns helfen, aber leider sitzen wir oft noch auf einem großen Berg technischer Sicherheitsschulden. Es gibt noch viel zu tun, let’s keep on marching.

Ihr möchtet gern mehr über Security-Themen bei adesso erfahren und wissen, mit welchen Services wir Unternehmen unterstützen? Dann werft doch einen Blick auf unsere Website.