Geht es um die Sicherheit von Software, so beschränken sich die Aufgaben des Kunden nicht auf das simple Einspielen von Updates. Er muss Sicherheit einfordern, schon bei der Entwicklung der Programme, sagt Prof. Dr. Sachar Paulus.
Sichere Software, so die landläufige Meinung, liegt in der Verantwortung des Software-Herstellers. Der Kunde hat keinen Einfluss darauf – er ist dem Hersteller auf Gedeih und Verderb ausgeliefert. Der Kunde muss Patches einspielen und reagieren, wenn der Hersteller – mal wieder – ein Sicherheitsproblem in einem seiner Produkte gemeldet bekommen hat.Das ist beim Cloud Computing scheinbar noch mehr der Fall, denn dort ist man dem Lieferanten der verwendeten Services in Bezug auf Sicherheit viel stärker ausgeliefert.
Doch das muss nicht sein. Genau so, wie man in Bezug auf Performance und Verfügbarkeit Anforderungen an einen Software-Service-Lieferanten mit einem Service-Level-Agreement (SLA) stellen kann, so kann man auch für die Sicherheit der Software Anforderungen an den Lieferanten von Software und Cloud Services stellen.
Dabei bedient man sich der ersten Schritte für eine sichere Software-Entwicklung. Die wichtigsten Maßnahmen für eine sichere Software-Entwicklung sind: Anforderungsdefinition, Bedrohungsmodellierung, sicherer Software-Entwurf, sichere Programmierung, Sicherheitstests, sichere Einrichtung und Anpassung und Reaktionsfähigkeit auf Sicherheitsprobleme. Ein sicherheitsbewusster Hersteller von Software führt entsprechende Maßnahmen ein, damit die produzierte Software den aktuellen Sicherheitsanforderungen entsprechen kann.
Bei diesem Prozess ist man als Kunde nicht nur Zuschauer, sondern kann aktiv in diese Schritte eingreifen, damit die eigenen Sicherheitsanforderungen beachtet werden. Typischerweise findet das ja auch oft schon bei den Sicherheitstests und bei der sicheren Einrichtung und Anpassung statt, wenn Kunden bestimmte Sicherheitstests vorgeben oder bei der Anpassung und Konfiguration von Sicherheitsoptionen mitarbeiten.
Die Möglichkeit besteht aber, dass man als Kunde schon bei der Anforderungsdefinition und bei der Bedrohungsmodellierung für Sicherheitsmaßnahmen mitarbeitet beziehungsweise diese Arbeit übernimmt. Dabei sammelt man nicht nur die üblichen Anwendungsfälle (»use cases«), sondern auch Missbrauchsfälle (»misuse cases«), die beschreiben, was ein Angreifer tun würde. Für diese Missbrauchsfälle werden Anforderungen für die Sicherheit des Software beziehungsweise des Services abgeleitet.
Da diese Anforderungen meist nicht-funktional sind, also nicht einfach durch eine Funktion abgebildet werden können (wie etwa Verschlüsselung), muss man zusätzlich für diese Anforderungen Akzeptanzkriterien bilden, unter welchen testbaren Bedingungen man von der Erfüllung der Anforderung ausgehen kann. Durch die Testbarkeit der Akzeptanzkriterien kann der Kunde die Erfüllung der Anforderungen durch den Hersteller beziehungsweise Lieferanten überprüfen.
Missbrauchsfälle sind aber nicht die einzigen Möglichkeiten, Sicherheitsanforderungen zu erzeugen. Eine sehr gute Technik besteht in der Durchführung einer Bedrohungsmodellierung.
Bei einer Bedrohungsmodellierung wird die Software in einem frühen Architekturstadium in zusammenhängende, sich vertrauende Softwarekomponenten zerlegt. Dann wird mit verschiedenen Techniken untersucht, wo und wie ein Angreifer ansetzen würde, um einen Angriff auf die Software durchführen zu können. Diese Angriffe werden nach bestimmten Aspekten, die Wahrscheinlichkeit und Schadensausmaß eines Angriffs versuchen zu schätzen, bewertet. Für die kritischsten Angriffe werden Gegenmaßnahmen identifiziert und diese in die Anforderungsliste mit aufgenommen.
Diese Techniken ermöglichen einem – zugegebenermaßen IT-affinen – Kunden, seinem Cloud-Service-Lieferanten eine sehr konkrete Liste mit Sicherheitsanforderungen zu präsentieren. Wie diese Anforderungen vertraglich eingefordert werden, ist dann über die üblichen Prozesse realisierbar.