Hinterher hat man es meist vorher gewusst

Dirk Schadt Cloud Computing, Compliance, Datenpanne / Data Breach, Datenschutz, Gastbeitrag, Kommentar, Sicherheit / Security Leave a Comment

So wie Horst Evers das fürs Leben beschreibt, so geht es auch in der Informationssicherheit meist um Vorfälle, die wenn sie eintreten doch so zu erwarten waren. Dann kommen die Experten und erklären wie es dazu gekommen ist, wer was falsch gemacht hat und dass das doch alles vermeidbar war.

So hat zuletzt der US Kongress der Wirtschaftsauskunftei Equifax bescheinigt, der Megahack in 2017 wäre „absolut vermeidbar“ gewesen.

Woran liegt das?

Sicherheitsthemen sind unbequem und keiner kann im Vorfeld mit „Bedenkenträgerei“ punkten. Gefühlt werden Projekte verzögert, weil keiner sagen kann, ob die vorgeschlagenen Maßnahmen überhaupt wirken und Schaden vermeiden oder nur rausgeschmissenes Geld sind.

Bei Marketing weiß man auch nicht welcher Teil der Investition wirkt, aber da kurbelt man den Produktvertrieb an und eine Messung ist einfacher. Ernste Sicherheitsvorfälle tauchen meist erst sehr viel später auf, meist erst dann, wenn die Verantwortlichen für die Produkte und Infrastrukturarchitektur nicht mehr in der Verantwortung stehen.

Und die Sicherheitsexperten helfen da auch nicht immer, sind sie doch weit weg gehalten vom jeweiligen Geschäftsziel der Projekte oder sowieso eher reaktiv und technikverliebt unterwegs.

Man sollte meinen, so langsam hätte die Branche gelernt besser damit umzugehen und Wege zu finden Planbarkeit in Produktdesign einzubauen. Der exponentielle Anstieg an ernsthaften Sicherheitsvorfällen zeigt aber einen anderen Weg. Gründe hierfür sind vielfältig, meist sehr menschlich. Im Vorfeld zu raten, was genau eingebaut werden muss um einen Vorfall zu vermeiden ist schwer ohne sich mit den interagierenden komplexen IT-Systemen tiefer auseinanderzusetzen. Kommt es dann aber zum Vorfall übernimmt niemand gerne die Schuld. Also wird schon frühzeitig dafür gesorgt die Schuld nicht zugewiesen zubekommen. Vor allem in Führungsetagen greift eher das persönliche Risikomanagement als Schaden vom Unternehmen abzuwenden. Und das Gefühl dann „alles im Griff zu haben“ grenzt gerne an Selbstgefälligkeit.

Zudem muss heute schneller und/oder billiger am Markt agiert werden können, agil ist die Devise. Und die Devise verleugnet gerne, dass für Agilität hohe Disziplin in Planung und Tests nötig ist ohne die eine Automatisierung gar nicht stabil funktioniert.

Und einen potentiellen Schaden kalkuliert man auch nicht gerne als Budgetposten für das Projekt ein, aus der Glaskugel lesen erscheint da einfacher. Ein paar wenige offensichtliche Szenarien müssen ausreichen.

Den meisten Vorfällen gemein ist tatsächlich, dass man aus Fehlern Anderer hätte lernen können und besser hätte planen können. Leider sind die Vorfälle immer etwas unterschiedlich und zeigen, dass es sich auch um ein Katz und Maus Spiel mit Angreifern handelt.

Sicher kann man Gemeinsamkeiten bei Angriffsmethoden entdecken und als Gegenmittel Verfahren einsetzen, welche von den Experten quasi wie ein Mantra runtergebetet werden.

Das wäre beispielsweise alle IT-Systeme zeitnah aktuell zu halten und Berechtigungen nach dem Minimalprinzip zu vergeben oder Passwörter sicherer zu gestalten und auch schon mal zu wechseln. Ein IT Betrieb muss dagegen jedoch Einsparungen aufzeigen und da wird leichter an Stellen gespart, die nicht so schnell auffallen. Log-Daten auswerten ist nicht wirklich schwer, aber solange alles läuft…

Was ist dagegen das Geheimnis, dass so manches Unternehmen, welches quasi nur aus Informationstechnologie besteht und durch das „böse“ Internet seinen Geschäftsbetrieb rechtfertigt, eben nicht mit Sicherheitsvorfällen bekannt geworden ist?

Nun, da wird Informationssicherheit als essentieller Teil der Produktentwicklung und des IT Betriebes gesehen und entsprechend organisiert. Wichtig ist hierbei der Selbstzweck Kunden ein robustes und vertrauenswürdige Produkt liefern zu können und nicht, wie so manches reguliertes Unternehmen annimmt, „compliant“ zu sein. Regulatorische Vorgaben stellen immer nur ein pauschalisiertes Grundschutzniveau dar, was motivierte Angreifer nicht abhalten kann.

Ein Regularium, nämlich die Datenschutzgrundverordnung, greift hier ein Element erneut auf, welches Unternehmen in die Lage versetzen kann vom reaktiven in einen aktiven Modus zu wechseln, damit gestalterisch zu wirken und Maßnahmenplanung vorab auf Wirksamkeit zu evaluieren.

In Artikel 32 Abs. 1 EU DSGVO wird die Sicherheit der Verarbeitung in definiertem Umfang eingefordert zur angemessenen und belastbaren Gewährleistung der Schutzziele der IT-Sicherheit: Vertraulichkeit, Integrität und Verfügbarkeit. Hierbei soll Stand der Technik berücksichtigt werden genauso wie angemessene Implementierungskosten zulässig sind.

Faktisch läuft das auf ein projektbegleitendes Planungsdokument heraus, was als Sicherheitskonzept bezeichnet werden kann. Sicherheitsexperten kennen das schon lange, wird doch durch BSI Grundschutz und ISO27001 immer Schutzbedarfsanalyse und Sicherheitskonzept mit risikomindernden Maßnahmen eingefordert.

Robustes Produktdesign ist jedoch nur ein Teil der Wahrheit, den IT-Produkte müssen auch sicher laufen. Hierzu ist es hilfreich, wenn ein sicherer Betrieb definiert ist, die Betriebsprozesse Kontrollen ermöglichen und ein Überblick über den aktuellen Risikostatus geliefert werden kann.

Jetzt kommt mancher auf die Idee, dass könne ein Dienstleister oder Cloudanbieter übernehmen und man wäre eine Sorge los. Leider funktioniert das so nicht, bleibt ein Produktanbieter doch immer selbst in der Verantwortung und muss seinen beauftragten Dienstleister auch überwachen, nötigenfalls zu Korrekturen bewegen.

Und dafür ist üblicherweise eher mehr Abstimmung und Kommunikation nötig als weniger. Eine ähnliche Herausforderung erleben Unternehmen, welche ihre IT in Silos zerstückelt haben, also kleine Einheiten als Spezialisten wie am Fließband Aufgaben in einem definierten Zustand übernehmen und weiterveredelt an die nächste Abteilung oder Dienstleister übergeben.

Jeder dieser Silos ist ein Ergebnis geschuldet und wird gerne an den Kosten gemessen. An den Übergabepunkten lauern jedoch erhebliche Qualitäts- und Sicherheitsdefizite, wenn die Akzeptanzkriterien nicht auf angemessenem Niveau definiert sind und das sind sie leider selten.

Es gibt aber durchaus Hoffnung. Viele IT-Produkte und Anwendungen werden heute mit agilen Entwicklungs- und Projektmethoden erstellt. Der für die Schnelligkeit nötige hohe Automatisierungsgrad zwingt geradezu zum automatisierten Testen in jeder Phase. Integriert man verbindliche Sicherheitstest in jede dieser Phasen kommt zwangsläufig ein robustes Produkt dabei heraus, welches sowohl sicher – das erwartet der Kunde implizit – als auch compliant ist.

Eine der agilen Strategien lautet „shift left“. Sie besagt, dass je weiter vorne im Prozess Fehlervermeidung adressiert werden kann, desto schneller und preiswerter kann ein qualitätsgesichertes Produkt entstehen.

Implizit werden Mehrkosten vermutet da man ja vorne im Prozess weitaus mehr Sorgfalt walten lassen muss. Häufig hat man aber bereits Kosten z.B. im Support- oder Beschwerdemanagement bis hin zum Kundenverlust, die nicht der Entwicklung und Produktplanung zugeordnet sind, aber dort die Ursache zu suchen wäre. Ein höheres Maß an Fehlervermeidung oder zumindest frühzeitiger Fehlererkennung verlagert solche Opportunitätskosten dann nach links und kann im optimalen Fall gesamtheitlich betrachtet sogar weitaus preiswerter ausfallen und ermöglicht schneller am Markt agieren. [1]

Und ganz links ist immer der Mensch beteiligt und das wissende, bewusste und verantwortliche Handeln alle Beteiligten, vom Betreiber nach links zum Entwickler nach links zum Auftraggeber und Verantwortlichen.

Einer der Vorreiter ist Microsoft, welcher bereit 1999 mit SDL [2] eine Methodik geschaffen und verpflichtend eingeführt hat, Sicherheitskriterien bereits im Softwaredesign zu modellieren und konsequent Fehlervermeidung in der Entwicklung anzuwenden.  Es werden zwar Aufwände ebenfalls nach links, also in die voranzustellende strukturierte Fehlervermeidung investiert, aber die internen Studien haben beim ersten voll angewendeten Produkt Vista aufgezeigt, dass die Supportaufwände für Fehlerkorrekturen und Patches sowie Kundenkommunikation im Gegenzug um ein vielfaches gesunken sind und beherrschbarer wurden.

Die OWASP Community [3] hat sich der Methodik ebenfalls angenommen und heute gibt es bereits mit SAMM [4] einen methodischen Rahmen, der Entwicklern und Produktmanagern helfen kann, konsequent sicherere Produkte zu bauen.

In einem weiteren Artikel werde ich darauf eingehen, wie man so ein Sicherheitskonzept entwickelt und bei Veränderungen anpasst, wie man daraus Planungssicherheit im Projekt bezüglich Terminen und Kosten transparenter macht sowie für den Betrieb des Produktes die wichtigsten Rahmenbedingungen den Betreiber oder Clouddienstleister mitgeben kann.


Links

  • [1] s.a. https://olev.de/0/10er-regl.htm
  • [2] SDL steht für Trustworthy Computing Security Development Lifecycle, zu Deutsch Entwicklungszyklus für vertrauenswürdigen Computereinsatz
  • [3] https://www.owasp.org
  • [4] https://owaspsamm.org

Gastbeitrag von Dirk Schadt

Dirk Schadt beschäftigt sich seit über 20 Jahren mit Informationssicherheit und Datenschutz. Ursprünglich hat er als Ingenieur und Systemarchitekt für ein Systemhaus Sicherheitssysteme implementiert, später als Business Development Manager den Aufbau der eigenen Fachbereiche vorangetrieben. Er hatte daneben lange Zeit einen Lehrauftrag zu KRITIS, war und ist in unterschiedlichen Interessensverbänden wie der GI eV. aktiv und veröffentlich unregelmäßig auch Artikel. Seit 2007 ist Dirk Schadt selbständiger Berater und begleitet vor allem Innovations-, Reorganisations- und Strategieprojekte sowie Interimsmandate, die einen engen Bezug zu Informationsmanagement und mit dessen Risiken zu tun haben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.