Patch me if you can: Kann Elon Musk ein Vorbild für die IT-Sicherheit sein?
Um die IT-Security zu verbessern, sollte kein Weg zu schwer und keine Methode zu abwegig sein. Als Inspiration können die Erfolgsrezepte anderer dienen.
- David Fuhr
Berühmte Menschen sind nicht selten umstritten. Manche von ihnen werden sowohl gottgleich verehrt und beneidet als auch verlacht, ob nun zu Recht oder nicht.
Der milliardenschwere Tausendsassa Elon Musk etwa ist für vieles bekannt – und für nicht weniges gehasst. Auch wenn er von märkischer Gewässerkunde wenig verstehen mag, ist er eines jedoch ganz bestimmt: ein erstklassiger Ingenieur. Was jedoch macht etwa sein Raumfahrtunternehmen SpaceX so anders? Und was passiert, wenn wir sein Patentrezept für Designprozesse – ob für Raketen oder für Elektroautos – auf die Security anwenden? Zeit für ein Gedankenexperiment.
Folgende fünf Regeln sieht Musk als Kern seines ingenieurtechnischen Erfolgs. Dabei kommt es, wie wir noch sehen werden, entscheidend auf die Reihenfolge an.
Mache erstens die Anforderung weniger idiotisch. Zweitens lösche möglichst viele Schritte des Prozesses. Drittens vereinfache und optimiere. Viertens verringere die Durchlaufzeit. Fünftens automatisiere. Schauen wir uns das im Einzelnen an.
Entdummung
Häufig machen wir den Fehler, Anforderungen als absolut zu nehmen. Das „Wie“ versuchen wir nach irgendwelchen Maßstäben optimal umzusetzen, während wir das „Was“ nicht hinterfragen.
Beispiel: Die Norm will regelmäßigen anlasslosen Passwortwechsel erzwingen? Eigentlich geht es doch um den Schutz vor Brute Force. Das Protokoll soll „verschlüsselt“ sein? Was wirklich benötigt wird, ist ein Integritätsschutz; den erledigt ein HMAC (Hash-basierter Message Authentication Code) viel schneller und einfacher.
Laut Musk sind Anforderungen übrigens besonders dann gefährlich, wenn sie von intelligenten Leuten kommen. Denn dann hinterfragen wir sie vielleicht nicht genug.
Ausmisten
Der nächste Kardinalfehler ist es, an dieser Stelle bereits mit der Optimierung anzufangen. Schon Donald Knuth wusste, dass Premature Optimization die Wurzel allen Übels ist. Also erst einmal gnadenlos wegstreichen, sonst kriegt man nie ein sicheres System zum Abheben. Bevor wir eine Web Application Firewall einbauen, überlegen wir erst einmal, ob es überhaupt einer Webanwendung bedarf. Und das sicherste Passwort ist eines, das man gar nicht braucht.
Keep it simple, Süße/-r!
Erst dann dürfen wir optimieren – aber nur, indem wir vereinfachen. Mehr Komplexität ist keine Verbesserung! Die Wahl zwischen AES 256 und einem Dutzend weiterer symmetrischer Verschlüsselungsverfahren zu lassen, schafft nur Raum für Angriffsfläche und Implementierungsfehler.
Ab die Post
Jetzt – und wirklich erst jetzt! – dürfen, nein, müssen wir Tempo machen. Es geht darum, die Durchlaufzeit zu verkürzen, um aus mehr Zyklen lernen zu können. Eine USV oder eine andere Redundanz, die nie getestet wird, ist nichts wert – lieber zweimal im Jahr den Stecker ziehen. Und wenn die Angreifer so selten vorbeikommen, dass wir nicht aus ihren Tricks lernen können, müssen wir uns Angreifer anmieten (Pentest, Red Teaming) oder Angriffe anderweitig üben (Planspiele).
Beim Space Shuttle war das Problem, dass durch die stets bemannten Flüge kein Raum für Verbesserungen war: Jede kleine Veränderung am System hätte eine Katastrophe auslösen können, und so wurden zur Sicherheit bekannte Fehler und Altlasten beibehalten, anstatt aufzuräumen. Wir brauchen für Security aber eher Systeme wie das Starship von SpaceX, das mangels Besatzung auch mal in die Luft fliegen (kleiner Kalauer …) darf.
Das Prinzip ist als Chaos Engineering auch für die IT beschrieben, wird aber bisher eher homöopathisch angewandt. Dabei könnte man auch Honeypots dazuzählen: Systeme, die möglichst häufig angegriffen werden, damit wir daraus lernen können. Oder aber Container mit „Selbstheilungskräften“.
Automatisch
„Klar, Security Automation!“, möchte man jetzt ausrufen – endlich! Und riefe damit an der offensichtlichen Sache vorbei: Wenn wir brav den vorigen vier Schritten gefolgt sind und ein potenziell sicheres System designt haben, müssen wir jetzt die Produktion automatisieren. Wie viel ist – an Effizienz und an Security! – gewonnen, wenn alle VMs immer aus den gleichen zwei, drei sorgsam gehärteten Images entstehen. Und wie viel fehlerträchtige Arbeit kann mir eine geschickte CI/CD- oder Build-Pipeline abnehmen, sodass ich nicht jedes Mal den Linter für eine Codeanalyse anwerfen muss (beziehungsweise dies vergesse).
Ein weiterer Tipp von Ingenieur Musk ist zumindest eine Überlegung wert: Nur wenn jede und jeder „Chief Engineer“ ist, verstehen alle das Gesamtsystem und können beurteilen, was gute Optimierungen sind – oder aber schlechte, wie die Webbrowser, die versucht haben, Cross-Site-Scripting-Code aus Webseiten herauszulöschen, und dabei noch größere Lücken gerissen haben.
Klar ist: Wenn unsere IT-Systeme mit Sicherheit mit zum Mars fliegen wollen, müssen wir noch etwas experimentieren.
Diese Kolumne ist in iX 09/2021 erschienen und wurde für die Online-Ausgabe aktualisiert.
(ur)
