Systeme mit Schwachstellen stellen dummerweise keine Seltenheit dar. Die meisten IT-Infrastrukturen müssen hiermit kämpfen und in manchen Bereichen wie beispielsweise in der Industrial IT kann dies durchaus extreme Formen annehmen. Mit dem exponentiellen Wachstum des Internet of Things (IoT) und der Vielzahl an unsicheren Endgeräten im IoT hat dieser Problembereich inzwischen sogar erschreckende Dimensionen angenommen.
Die wesentliche Strategie, um das Schwachstellenproblem anzugehen, ist Security by Design, d.h. Informationssicherheit als integraler Bestandteil von Produktentwicklung und Maintenance. Das Ergebnis wären dann im Idealfall Systeme, die aus sich selbst heraus angemessen abgesichert sind und die von vorneherein berücksichtigen, dass etwaige später festgestellte Schwachstellen schnell und einfach gepatcht werden können. Security by Design bedeutet, dass Informationssicherheit systematisch im Entwicklungsprozess von der ersten Anforderung an eine Software (oder Hardware) bis zum Lebensende der Software (oder Hardware) berücksichtigt wird. Dies beinhaltet unter anderem die folgenden Punkte [1]:
- Analyse der Daten hinsichtlich Anforderungen an Vertraulichkeit und Integrität, Verwendung von angemessener Authentisierung und Verschlüsselung nach dem Stand der Technik
- Systematische Vermeidung von Schwachstellen an Schnittstellen (z.B. Buffer Overflow) durch Input Validation, d.h. Prüfung der Daten, die an einer Schnittstelle übergeben werden
- Systematische Prüfung von Spezifikationen, Modellen und Code auf Schwachstellen
- Durchführung von Security-Tests in allen Ebenen der Entwicklung, inklusive Penetration-Tests.
Würde es nun ausreichen, wenn wir ausschließlich Produkte verwenden, die by Design sicher sind? Dann könnten wir doch auf den ganzen anderen Rest an schrecklichen Sicherheitsmaßnahmen verzichten! Die Antwort auf diese Frage ist leider: Nein.
Erstens sichert auch Security by Design keine Fehlerfreiheit einer Komponente zu (und wir wissen nun einmal, dass Software – fast – nie fehlerfrei ist). Zweitens können ein unsicherer Betrieb und eine unsichere Nutzung auch die beste Sicherheit eines IT-Systems zunichtemachen.
Außerdem funktioniert Security by Design nur dann gut, wenn sich alle an einer Lösung beteiligten Mitspieler auch an die Regeln halten. In der Softwareentwicklung wird aber sehr häufig auf Komponenten zurückgegriffen, die von Dritten entwickelt worden sind und wenn diese bei der Entwicklung schlampen, kann es passieren, dass sich trotzdem unangenehme Schwachstellen in das eigene Produkt hineinschmuggeln. Außerdem erhöht Security by Design den Aufwand der Entwicklung, was sich bei immer kürzer werdenden Entwicklungszyklen, wie in der agilen Softwareentwicklung, besonders unangenehm auswirken kann, und letztendlich würde wahrscheinlich der erhöhte Aufwand dann auch in Form eines höheren Preises an den Kunden weitergegeben werden.
Es wird also bis auf Weiteres leider dabei bleiben, dass Security by Design insbesondere im Consumer-Bereich eine Ausnahme ist. Jedoch würde man zumindest im professionellen Einsatz von IT eigent-lich erwarten, dass zumindest ein Mindestumfang der Regeln für Security by Design in der Entwicklung befolgt wird. Gerade bei Cloud-Diensten der Form Software as a Service (SaaS) wäre Security by Design eigentlich zwingend erforderlich. Jedoch ist hier der Markt voller Kleinanbieter von SaaS und es kommt leider immer wieder vor, dass ein SaaS-Anbieter ausschließlich auf die Güte der Informationssicherheit in der genutzten Plattform (z.B. AWS oder Microsoft Azure) vertraut und in dem eigenen Anteil der Software die Informationssicherheit nicht weiter berücksichtigt.
Das bedeutet für den Anwender, dass bei Beschaffungen systematisch abgefragt werden muss, mit welchen Maßnahmen ein Hersteller das gewünschte Sicherheitsniveau der angebotenen Lösung nachhaltig sicherstellt. Das Vorweisen eines Zertifikats der Form ISO 27001 reicht hier nicht, da es viel zu allgemein ist und sich der Geltungsbereich des Zertifikats ggf. auch nicht richtig auf das angebotene Produkt erstreckt. Interessanterweise haben wir seit Jahren einen Standard in Verbindung mit einer Zertifizierung, der genau auf Security by Design abzielt, nämlich die Common Criteria [2]. Hier kann ein Hersteller über einen Evaluation Assurance Level (EAL) auf einer Skala von 1 bis 7 nachweisen, wie stark die Informationssicherheit in die Prozesse der Entwicklung, Auslieferung und Wartung integriert sind. Nur ist ein solcher Nachweis aufwändig und teuer, was dazu führt, dass immer mehr Hersteller eine solche Zertifizierung scheuen. Es bleibt also dabei, dass man sich als Kunde vor der Beschaffung selbst genau Gedanken machen muss, was die an ein Produkt gestellten Kriterien für Security by Design sind. Dies gilt insbesondere auch für eine Auftragsentwicklung. Wenn hier nicht die Informationssicherheit entsprechend vertraglich verankert wird, darf man sich nicht wundern, wenn der Entwickler ausgesprochen sparsam mit der Sicherheit umgeht.
Nebenbei: Es gibt eigentlich kaum eine Institution, die nicht auch selber Software ent-wickelt. Ein Beispiel sind die ganzen Scripts und selbst gebauten Werkzeuge, mit denen sich Administratoren das Leben erleichtern.
Dies ist nichts als Software. Wie ist es hier mit der Qualität und der Informationssicher-heit? Es passiert immer wieder, dass ein Script eines Administrators unzureichend getestet in der Produktivumgebung eingesetzt und einen Major Incident verursacht. Das würde mit Security by Design nicht oder zumindest viel seltener passieren.
[1] Siehe hierzu auch https://www. owasp.org/index.php/Security_by_De-sign_Principles
[2] Siehe https://www.commoncriteria-portal.org/
