Software Sicherheit – wir haben es ignoriert

Arnold

Ich habe mich im letzten Sommer ein wenig mit den Grundlagen der Kryptografie beschäftigt. Inzwischen ist Kryptografie nicht nur mehr die Lehre des Verschlüsselns, sondern weit mehr [1][2]. Neben der Kryptografie hab ich auch noch ein anderes Schlagwort gefunden: Security Engineering [3]. Vorweg: die Ganze Thematik ist extremst komplex aus meiner Sicht. Betrachten wir nur Mal die Kryptografie. Ein paar Schlagworte (jemand, der von Kryptografie Ahnung hat, wird an dieser Stelle lachen – für einen Newcomer doch sehr viel Information zum Verarbeiten):

Nicht zu erwähnen ist, dass das nicht Mal die Spitze des Eisbergs ist.

Too many engineers consider cryptography to be a sort of magic security dust that they can sprinkle over their hardware or software, and which will imbue those products with the mythical property of “security.” Too many consumers read product claims like “encrypted” and believe in that same magic security dust. – Bruce Schneier

D.h., alleine wenn wir Kryptografie in unser Softwareprodukt anwenden wollen, ist es nicht damit getan, ein Library zu referenzieren und „enrypt“ aufzurufen. Die Probleme die ich sehe:

  • Die kryptologische Werkzuegpallete ist sehr breit
  • Die Thematik ist sehr komplex. Bei vielen anderen Problemen genügt es eine Library einzubinden, um den Funktionsumfang zu erweitern. Bei Kryptografie ist das der unwesentlichste Schritt.
    • An welchen Stellen muss ich welches Werkzeug / Protokoll ansetzen?
    • Man wird mit einer Fülle von Problemen konfrontiert. E.g. Known-Key-Attacke: Wie schaut es mit Forward Security und Backward Security aus? Wie und wie oft wechsele ich die Schlüssel?
    • 1000 andere Fragen
  • Welcher Library traue ich?
    • Ist der Algorithmus richtig implementiert?
    • Werden schwache Schlüssel erkannt / vermieden?
    • 1000 andere Fragen
  • Wie verteile ich das Wissen auf die Entwickler?
    • Wie ist der Impact auf die Software Architektur?
  • 1000 andere Fragen

Security engineering is about building systems to remain dependable (betriebssicher, zuverlässig) in the face of malice, error, or mischance. As a discipline, it focuses on the tools, processes, and methods needed to design, implement, and test complete systems, and to adapt existing systems as their environment evolves.– Ross Anderson

Das zweite Schlagwort war Security Engineering. Hier sehe ich u.a. einen großen Impact im Requirements Engineering. Ross Anderson stellt ein Security Engineering Analysis Framework mit vier Eckpfeilern auf:

  • Policy: E.g. 9/11. Die Terroristen sind mit Messer an Board gekommen, weil die Policy Messer mit 3inch Klinge erlaubt hat. Es war also ein Policy Fehler und nicht ein Fehler im System - die Kontrollen haben ja funktioniert. Ebenfalls wurde Geld in die Kontrollen gesteckt als e.g. in sichere Cockpittüren - ebenfalls auch eine schlechte Policy Wahl.
  • Mechanism: Hilfsmittel um die Policy zu erreichen. Messer aus Composite-Materialien können nicht aufgespürt werden.
  • Assurcance: Wieviel Vertrauen kann man auf die einzelnen Mechanismen geben?
  • Incentive: Der Anreiz, den Leute haben müssen, welche das System in Schuss halten bzw. das Motiv, welches der Angreifer haben muss, um das System zu attackieren

Ein anderes Beispiel ist eine Policy die besagt: “Alle Türen zusperren” - wenn das Büro aber über unsichere Doppeldecken oder einen Klimaschacht verfügt, kommt man trotzdem in das Büro, da der Mechanismus schlecht ist. In Security Engineering sollte man sich also immer fragen, was schief gehen kann. Das erfordert natürlich ein tiefes Verständnis und Erfahrung (vergangene Attacken etc). Und das ist Aufgabe des Requirements Engineerings / Business Analysis.

pixabay.com

Will man also “Sicherheit” in sein Softwareprojekt bringen, so bedarf es eines großen Aufwands. Wahrscheinlich ist auch das der Grund, warum viele Firmen dieses Thema auch gerne “postponen” und gekonnt aussitzen. Wie Spezialisten allerdings immer wieder erwähnen: entweder von Anfang an oder man wird viel Schmerzen erleiden. Welche Gründe könnte also ein Angreifer haben, einen Angriff zu starten?

  • Wirschaftsspionage
    • Wieviel hat die Konkurrenz bei der Ausschreibung geboten?
    • Wie hat die Konkurrenz ein Problem gelöst? Siehe Siemens Skandal
    • Alle Informationen, welche irgendwie zu einem Vorteil führen könnten
  • Konkurrenz schlecht machen. E.g. einen Trojaner in deren Software einschleusen - wird dieser in einem sicherheitskritischen Umfeld deplyoed, ist das der Untergang einer Firma. Siehe Stuxnet
  • Die Privatsphäre ausspionieren – aus Eigeninteresse oder Fremdinteresse einer Organisation
  • Ich vermute auch, um einen Kick zu erleben bzw. ein Zeichen zu setzen. Siehe Anonymous

Design Impact auf Software Sicherheit

Sicherheit kann man nicht einfach an der äußersten Schicht (e.g. Kommunikation zum Message Broker) anschalten. Einfach mal TLS einschalten und sich entspannt zurücklegen – Fehlanzeige. Sicherheit muss vom ganzen Entwicklerteam gelebt werden. Techniken wie Defensives Programmieren sind auch schon aus der Fault Tolerance Ecke bekannt. .NET bietet hierzu Code Contracts an. Selbst machen diese Contracts nicht viel – aber mit den passenden Tools kann man e.g.

  • Runtime Checking
  • Static Checking
  • Documentation Generation

betreiben. Postsharp bietet eine tolle Technik, um Parameter effizient zu überprüfen. Zu beachten ist allerdings der Einsatz (meine Sichtweise):

  • Business Validation sollten im Code geschrieben werde
  • Technische Validation per Aspekte

Will man also sicher programmieren, sollte man bei jedem Vorgang sehr kritisch sein und hinterfragen, was passieren könnte. Und das geht auch e.g. in den Bereich der nicht-funktionalen Anforderungen. Ein brechen der Anforderungen könnte bei einem Angriff auch schon den gewünschten Erfolg haben (e.g. Ausfall der Infrastruktur – öfters im Netz zu lesen durchgeführt mit Hilfe von “DDOS-Attacken”).

Auch zu diesem Thema kann man wieder Bücher füllen.

Auswirkungen auf den Entwicklungsprozess

Mit der Zertifizierung des CSSLP - Certified Secure Software Lifecycle Professional wird fast das ganze Spektrum eines Projekts abgedeckt. Bücher, welche den Inhalt abdecken findet man zu Genüge. Auch zeigt es den Impact auf das Projekt.

Den Kopf in den Sand stecken?

Ich glaube, das sollte man nicht und es ist nicht erforderlich. Aus meiner jetzigen Sicht besteht die Kunst darin, die richtige Anwendungsebene zu finden. Man muss seinen Werkzeugkasten kennen um ihn effektiv einsetzen zu können – aber speziell im Bereich der Kryptografie kann man so in die Tiefe gehen, dass man womöglich keine Zeit für andere Dinge mehr hat. Und kann man am Ende des Tages feststellen, ob AES wirklich sicher ist? Unwahrscheinlich. Und selbst wenn man es auf theoretischer Ebene kann so kann die Implementierung fehlerhaft sein. Mein Fazit ist also: 100% Sicherheit gibt es nicht. Man kann nur kritisch entwickeln und designen und Gegenmaßnahmen (e.g. Monitoring) betreiben, welche das Leben des Angreifers schwer macht.

Mein persönlicher Werkzeugkasten folgt in eine der nächsten Posts (er ist derzeit noch recht bescheiden – aber kommt Zeit – kommen die Werkzeuge).

Die Zukunft? Terminator?

Auf der Uni die Bibel der Informatik Studenten: Artificial Intelligence: A Modern Approach, Russel & Norvig. Das Buch zeigt Hilfsmittel, um Agenten “intelligent” Aufgaben erledigen zu lassen. Die Methoden sind facettenreich, aber als Leser einleuchtend – einfach gesagt: an Terminator und Co denkt man da nicht ;-) Allerdings neigt der Mensch bekanntlich dazu Dinge über das sinnvolle Maß hinaus zu nutzen. Daher glaube ich, dass die Gefahr besteht, dass Maschinen eines Tages „zu intelligent“ werden. Der Open Letter on Artificial Intelligence zeigt auch, dass viele Experten beunruhigt sind. Es gibt auch schon ein Wort dafür: AI takeover

AI takeover refers to an hypothetical scenario in which artificial intelligence becomes the dominant form of intelligence on Earth, with the computers or robots that possess it (AI) taking control of the planet away from the human race, potentially including wiping them out.

Terminator-Szenarien sind also möglich.

[1] Ferguson, Niels, Bruce Schneier, and Tadayoshi Kohno. Cryptography engineering: design principles and practical applications. John Wiley & Sons, 2011.
[2] Schmeh, Klaus. Kryptografie: Verfahren, Protokolle, Infrastrukturen. dpunkt. verlag, 2013.
[3] Anderson, Ross. “Security engineering: A guide to building dependable distributed systems. 2010.”