Der Begriff "nutzbare Sicherheit" (Usable Security) liegt in aller Munde, und es scheint Einigkeit in zwei Dingen zu bestehen: erstens, dass Sicherheitskontrollen die Benutzerfreundlichkeit und Unfreundlichkeit von Systemen nicht unnötig beeinträchtigen sollten. Und zweitens sollte das einfach zu bedienende System bevorzugt werden, da es das Risiko von Fehlern minimiert, die die Ursache für Sicherheitsvorfälle wie Datenlecks sein können.
Aber es scheint auch überraschend zu sein (zumindest für Sicherheitsexperten), dass Softwareentwickler immer (noch) so viele vermeidbare Fehler machen, die dann zu unsicheren Softwaresystemen führen. Tatsächlich sind viele der großen Sicherheitsvorfälle der letzten Wochen/Monate/Jahre auf scheinbar "einfach zu behebende" Programmierfehler zurückzuführen.
Wenn man beide Beobachtungen zusammenfasst, sollte es offensichtlich sein, dass wir brauchbare und entwicklerfreundliche Sicherheitskontrollen und Frameworks benötigen, die es einfach machen, sichere Systeme aufzubauen. Dennoch sieht die Realität anders aus: Viele Programmiersprachen, APIs und Frameworks bieten komplexe Schnittstellen, die eigentlich schwer sicher zu bedienen sind. Tatsächlich sind sie weit davon entfernt, brauchbare Sicherheit für Entwickler zu bieten.
In diesem Vortrag werde ich Beispiele für komplexe und "nicht nutzbare" Sicherheit für Entwickler wie APIs diskutieren, die tatsächlich (fast) nicht sicher nutzbar sind oder die ein Verständnis von Sicherheitsthemen erfordern, die die meisten Sicherheitsexperten nicht haben (und somit von Softwareentwicklern nicht kennen).
// Achim D. Brucker
leitet das Software Assurance & Security Research Team (https://logicalhacking.com) der Universität Sheffield. Davor war Dr. Brucker (https://www.brucker.ch) im Bereich statische und dynamische Sicherheitstests bei der SAP SE tätig. Unter anderem hat er die Securitytest-Strategie der SAP definiert sowie Sicherheitstest im Inbound und Outbound Open Source Process der SAP durchgeführt.