Hör auf, deine eigene Verschlüsselung zu erfinden

Security by Design bedeutet, dass die IT-Sicherheit während des gesamten Softwareentwicklungslebenszyklus eine zentrale Anforderung ist und nicht erst am Ende eines Projekts behandelt wird. Zu den wichtigsten Grundsätzen gehören Defense in Depth (die Schichtung unabhängiger Sicherheitsmechanismen), die Verwendung etablierter Bibliotheken statt der Entwicklung eigener Sicherheitstechnologien, die Validierung aller an den Schnittstellen eingehenden Daten, die Anwendung sicherer Standardeinstellungen und das sichere Fehlschlagen von Komponenten, wenn diese nicht funktionieren.

Das Wichtigste in Kürze

• Sicherheit, die in den letzten zehn Prozent eines Projekts behandelt wird, führt zu zehn Prozent IT-Sicherheit, so dass eine frühzeitige Einbindung der einzige zuverlässige Weg zu einem sicheren System ist.
• Die Modellierung von Bedrohungen ist keine Übung nur für Spezialisten: Jedes Team kann sich hinsetzen, herausfinden, was in seinem System wertvoll ist, und systematisch ausarbeiten, wer es darauf abgesehen hat und wie er es angreifen würde.
• Der Aufbau eigener IT-Sicherheitsmechanismen, einschließlich Verschlüsselung oder Authentifizierung, führt zu Schwachstellen, die selbst von Experten entwickelte Sicherheitstechnologien regelmäßig aufweisen und für deren Befund den meisten Teams die Ressourcen fehlen.
• Wenn eine Komponente wie ein Audit Trail oder ein Authentifizierungsdienst fehlgeschlagen ist, muss das System die Fortsetzung der Verarbeitung verweigern und darf nicht auf eine offene Position zurückfallen.
• Tester sind eine natürliche Triebfeder für das Sicherheitsbewusstsein, denn ihre Kernkompetenz ist es, zu hinterfragen, was schief gehen kann, und durch ihre frühzeitige Einbindung werden umgangene IT-Sicherheitskontrollen aufgedeckt, bevor sie die Produktion erreichen.

IT-Sicherheit ist das, was du zuerst baust, nicht das, was du zuletzt anbringst

Wenn du erst in den letzten zehn Prozent eines Projekts an die IT-Sicherheit denkst, bekommst du nur zehn Prozent Sicherheit. Dieser Satz bringt auf den Punkt, warum so viele Systeme mit einem schwachen Schutz ausgeliefert werden: Die Arbeit wurde aufgeschoben, bis sich fast nichts mehr ändern konnte.

Die IT-Sicherheit teilt dieses Schicksal mit der Leistung, der Ausfallsicherheit und der Verfügbarkeit. Alle sind sich einig, dass diese Qualitäten wichtig sind. Fast niemand schenkt ihnen frühzeitig Aufmerksamkeit, weil der Plan ist, sie “irgendwann” zu erledigen. Irgendwann kommt selten in guter Verfassung an.

Wenn du der IT-Sicherheit einen hohen Stellenwert einräumst, solltest du sie nicht als abschließende Aufgabe behandeln, sondern sie in die Entwicklung einbeziehen. Du entscheidest, wie sich ein System verteidigt, während du es noch gestaltest, wenn eine Änderung der Struktur billig ist.

Warum Teams die IT-Sicherheit immer noch als nachträgliche Aufgabe behandeln

Die meisten Softwareingenieure verfügen nur über abstraktes IT-Sicherheitswissen, und diese Lücke drängt das Thema an den Rand. Sie kennen die Begriffe: Authentifizierung, Berechtigung, Audit. Was sie in einem realen System damit anfangen sollen, ist weit weniger klar.

Es gibt eine echte Veränderung, die es wert ist, benannt zu werden. Vor zehn Jahren kamen zu einem Vortrag über IT-Sicherheit fünf Personen, die alle bereits im Sicherheitsbereich arbeiteten. Heute füllt sich der Raum mit Ingenieuren, die etwas lernen wollen. Das Interesse ist da. Das praktische Know-how ist oft nicht vorhanden.

Das andere Hindernis ist ein Kulturkonflikt. Wenn sich ein Team schließlich an IT-Sicherheitsspezialisten wendet, trifft es auf sehr kluge Leute, die nichts anderes als Sicherheit machen. Viele kommen aus dem Infrastrukturbereich und wissen wenig über Softwareentwicklung. Sie sprechen eine andere Sprache und neigen dazu, ein Team unter einer Liste von zwingenden, dringenden, katastrophalen oder anderen Forderungen zu begraben.

Diese Sichtweise ist irreführend, denn nichts in der IT-Sicherheit ist absolut. Alles ist ein Gleichgewicht. Ein Team, das nur hört: “Mach das alles jetzt oder du fehlgeschlagen”, hat keine Möglichkeit, Aufwand und Risiko abzuwägen.

Designprinzipien geben Ingenieuren einen brauchbaren Ausgangspunkt

Prinzipien funktionieren, weil sie kurz genug sind, um sich zu merken, und breit genug, um echte Entscheidungen zu treffen. Eoin Woods hat zehn Prinzipien entwickelt, nachdem er festgestellt hatte, dass die bestehenden Sammlungen entweder zu dünn oder zu groß waren: Sie reichten von acht oder neun Einträgen bis zu mehreren hundert. Alle sind gültig, aber keiner ist in den Extremen brauchbar.

Der Sinn einer kompakten Sammlung ist es, die Menschen dazu zu bringen, früher über IT-Sicherheit nachzudenken. Du musst die Kryptografie nicht beherrschen, um dich zu fragen, ob dein Entwurf auf eine einzige Fehlerwirkung angewiesen ist. Du brauchst nur eine Handvoll Fragen, die in deinen Kopf passen, während du die Architektur skizzierst.

Im Folgenden sind die Prinzipien aufgeführt, die in der alltäglichen Entwurfsarbeit das meiste Gewicht haben.

Verteidigung in der Tiefe: Verlasse dich nie auf einen einzigen Mechanismus

Gehe davon aus, dass jeder einzelne IT-Sicherheitsmechanismus überwunden werden kann. Raffinierte Angreifer knacken eine Verschlüsselung oder schlüpfen an einem Authentifizierungssystem vorbei, und wenn das alles war, haben sie jetzt alles.

Fast jeder Mechanismus hat Schwachstellen oder wird mit Fehlern angewendet. Das Ziel ist also ein mehrschichtiger, unabhängiger Schutz. In den Systemen, die die Regierungen verteidigen, hat jede Ebene ihre eigenen Kontrollen, die ineinandergreifen. Wenn man in eine Ebene einbricht, hat der Angreifer dasselbe Problem noch einmal.

Das Ziel ist es, ein Eindringen teuer zu machen. Jede unabhängige Ebene erhöht die Kosten, was oft die realistischste Form der Verteidigung ist, die man aufbauen kann.

Erfinde nicht deine eigene IT-Sicherheitstechnologie

Eine eigene IT-Sicherheitstechnologie zu entwickeln ist viel schwieriger, als es aussieht, und die Falle schnappt erfahrene Ingenieure. Viele fähige Entwickler lesen ein Buch über Verschlüsselung und beschließen, ihren eigenen Passwort-Tresor zu bauen. Der ehrliche Rat lautet: Tu es nicht.

Die gleiche Vorsicht gilt für die Authentifizierung und Berechtigung. Die Integration mit OAuth sieht einfach aus, aber der richtige Schritt ist, eine Bibliothek zu finden, die das schon kann.

Hier ist der Grund dafür im Klartext. IT-Sicherheitstechnologie, die von Fachleuten entwickelt wurde, hat immer noch Schwachstellen. Sobald sie auf den Markt kommt, werden sie von erfahrenen Testern auf Herz und Nieren geprüft, und sie finden immer wieder Probleme. Die Wahrscheinlichkeit, dass deine selbst entwickelte Version keine hat, ist gering.

Das erste, was sie tun, wenn sie es produzieren, ist, es mit all den erfahrenen IT-Sicherheitstestern zu testen, und sie finden immer wieder Probleme damit. Wie stehen die Chancen, dass du mit deiner Version keine Probleme hast? Sie ist ziemlich gering.

• Eoin Woods

Ob Open Source oder Closed Source ist kontextabhängig, und keiner von beiden hat ein Monopol auf gute IT-Sicherheit. Open Source bringt Transparenz und eine Menge unabhängiger Forscher. Für manche Märkte ist ein Closed-Source-Produkt tatsächlich das bessere Angebot. Stelle dem Anbieter die richtigen Fragen und passe die Wahl an das an, was du bauen willst.

Vertraue vorsichtig, vor allem dem, was in dein System kommt

Behandle jede Eingabe und jede Komponente als etwas, das du überprüfen musst, anstatt es zu akzeptieren. Netzwerkverbindungen sollten nicht ohne Berechtigung und Authentifizierung hergestellt oder akzeptiert werden. Das ist die offensichtliche Hälfte des Prinzips.

Die subtilere Hälfte ist das, was du in das System einbringst. Daten verdienen Misstrauen, denn viele Exploits funktionieren, indem sie bösartige Daten in ein System einspeisen, das sie ungeprüft verarbeitet. Das Gleiche gilt für das, worauf du aufbaust: Open-Source-Bibliotheken, kommerzielle Bibliotheken, kommerzielle Plattformen. Wie sicher sind sie, und woher weißt du, ob sie einen Zero-Day enthalten?

Verwende sichere Standardeinstellungen und scheitere sicher

Standard-Anmeldeinformationen sind eine altbekannte Quelle für Sicherheitslücken. Jahrelang wurden Oracle-Installationen mit mächtigen Konten und Standardpasswörtern ausgeliefert, und mit dem Scott/Tiger-Demo-Login konnte man sich in fast jedes System einloggen. Oracle hat das behoben, aber ein großer Teil der Cloud-Demo-Software und der Netzwerkhardware in Unternehmen wird immer noch mit freigeschalteten Standardbenutzern und -passwörtern ausgeliefert. Bequem und gefährlich.

Sicheres Fehlgeschlagen ist die andere Seite der gleichen Idee: Wenn etwas kaputt geht, darf das System nicht in einen offenen Zustand fallen. Ein Datenbankanbieter, der auf Leistung bedacht ist, hat einen manipulationssicheren Audit-Trail erstellt und dann die Ingenieure veranlasst, das Auditing zu deaktivieren und die Verarbeitung fortzusetzen, wenn er voll war. Ein Kunde hat das in der Beta-Phase entdeckt. Der Kompromiss erschien den Autoren vernünftig, aber er war genau falsch.

Moderne Versionen dieses Problems sind leiser. Muss sich in einem nachrichtengesteuerten System, das sich von einer Fehlerwirkung mehrerer Komponenten erholt, jeder Teil neu authentifizieren und die Verarbeitung verweigern, bis die IT-Sicherheit wiederhergestellt ist? Oder beginnt die Verarbeitung opportunistisch, weil die IT-Sicherheitsdienste noch nicht bereit waren?

IT-Sicherheit bereits in der Entwurfsphase

Sorge dafür, dass die IT-Sicherheit Teil der Arbeitsweise des Teams ist und nicht nur eine Notiz auf einem Whiteboard, die niemand während der täglichen Arbeit liest. Designprinzipien leiten die einzelnen Entscheidungen. Sie allein führen nicht dazu, dass ein Team sicher arbeitet.

Dafür brauchst du einen sicheren Softwareentwicklungslebenszyklus, was einfach bedeutet, dass du dich während des gesamten Prozesses um die IT-Sicherheit kümmerst und nicht erst am Ende. Du musst ihn nicht erfinden. OWASP bietet ein gut entwickeltes Modell an, und mehrere staatliche Stellen veröffentlichen ihr eigenes. Beginne mit einem etablierten Modell und passe es an, so wie jedes Team seinen Lebenszyklus anpasst.

Warum Tester hier die natürlichen Verbündeten sind

Tester denken bereits darüber nach, was schief gehen kann - genau die Denkweise, die die IT-Sicherheit braucht. Das ist genau die Denkweise, die Sicherheit braucht. Architekten versuchen auch so zu denken, aber sie sind menschlich und stehen oft unter dem Druck von neuen Funktionen oder einem einzigen Qualitätsziel wie dem Durchsatz für die nächsten Sprints.

Das ist der Punkt, an dem ein Tester sein Geld verdient. Wenn du feststellst, dass eine neue Funktion eine IT-Sicherheitskontrolle zu umgehen scheint, dann ist das genau das, wofür Tester bezahlt werden sollten. Die Aufgabe des Teams ist es, diese Frage zu unterstützen, und nicht, den Tester dafür unbeliebt zu machen, dass er sie stellt. Die richtige Reaktion ist Dankbarkeit, denn die Alternative wäre gewesen, den Fehler auszuliefern.

Wenn du die Tester früh in das Team aufnimmst, ändert sich dies noch weiter. Wenn die Tester die letzte Person waren, die die Software gesehen hat, war die Reaktion “Oh mein Gott, was hast du getan?” Durch ihre frühe Einbindung helfen sie, das Problem zu verhindern, anstatt es zu entdecken.

Abuser Stories und Bedrohungsmodellierung, einfach gehalten

Bringe die IT-Sicherheit in Form von Angreifergeschichten in das Backlog ein: Wie würde jemand dieses System angreifen? Das ist ein vereinfachter Einstieg in die Bedrohungsmodellierung, eine Technik, die kompliziert klingt, es aber nicht ist.

Die Bedrohungsmodellierung ist ein strukturiertes Gespräch. Das Team setzt sich zusammen und fragt sich, was wertvoll ist, wer es haben will und wie er es angreifen würde, um es zu bekommen. Bei dem Wertvollen kann es sich um Daten, eine Finanztransaktion oder eine Operation handeln, die ein Angreifer aktivieren oder deaktivieren will. Gehe methodisch vor und mach es nicht zu kompliziert, so wie es die Experten raten.

Das spiegelt wider, wie du über hohe Verfügbarkeit nachdenkst. Du zählst auf, was alles schief gehen könnte und was passiert, wenn die einzelnen Teile fehlgeschlagen sind. Wenn du das getan hast, weißt du, wie robust das System wirklich ist.

Zero-Days und Abhängigkeiten brauchen Automatisierung, keine Heldentaten

Mit Komponenten auf dem neuesten Stand zu bleiben, ist ein Prozessproblem, das du nicht von Hand lösen kannst. In Ökosystemen mit feinkörnigen Abhängigkeiten wie Node.js ist die einzige realistische Möglichkeit, über bekannte Schwachstellen auf dem Laufenden zu bleiben, die automatische Unterstützung.

Defense in depth” ist auch hier wichtig. Wenn du dich stark auf eine Komponente verlässt, um dich zu schützen, und diese Komponente eine Zero-Day-Schwachstelle hat, wird jemand sie ausnutzen. Verteile das Vertrauen, damit eine einzige Schwachstelle nicht alles öffnet.

Zero-Days sind ein hartnäckiges Problem, auch weil es einen Schwarzmarkt für sie gibt, so dass es schwierig ist, überhaupt zu wissen, dass sie existieren. Du kannst diese Lücke nicht vollständig schließen. Du kannst wissen, was sich in deinem System befindet, und die Suche nach Schwachstellen in deinen Open-Source-Komponenten automatisieren, denn dort sammelt sich das meiste Risiko an.

Lose Schnittstellen sind eine getarnte IT-Sicherheitsentscheidung

Freizügige APIs, die alles durchlassen, sind ein IT-Sicherheitsrisiko, nicht nur eine Bequemlichkeit. Eine Anwendungslandschaft, die mit lazy contracts verkabelt ist, lässt eine Infektion von System zu System wandern, bis sie irgendwo landet, wo es wichtig ist.

Der einfachste Weg ist der kleinste gemeinsame Nenner: alles zu einem String machen, nichts zurückweisen, später übersetzen. Der Preis dafür ist, dass Angreifer missgebildete Strings erstellen, die der String-Prozessor als gut akzeptiert, und dann eine Fehlerwirkung verursachen, wenn sie von einem anderen System interpretiert werden. Dabei kann es sich um eine Dienstblockade handeln oder um eine absichtliche Befehlsausführung.

Stark typisierte Schnittstellen sind der Kompromiss. Es dauert länger, sie zu erstellen, sie sind weniger flexibel und lassen sich schwieriger weiterentwickeln, weshalb man sich für lose Schnittstellen entscheidet. Die Warnung gilt immer noch: Sobald du große Mengen nicht validierter Daten akzeptierst, hast du ein potenzielles IT-Sicherheitsproblem, also validiere sorgfältig.