IT-Sicherheit und der korrekte Umgang mit personenbezogenen und anderen sensitiven Daten ist nicht nur eine Frage der Konfiguration, des Verhaltens und von speziellen Tools. Es ist auch eine Frage der Softwareentwicklung. Viele Probleme werden dort bereits geschaffen – oft unabsichtlich, manchmal aber auch absichtlich.
Wenn man Softwareentwicklungsprojekte betrachtet, dann ist es auch heute noch so, dass Sicherheit meist ein ungeliebtes, notwendiges Übel ist. Sicherheit wird immer noch viel zu oft am Schluss hinzugefügt. Das kann aber nicht gut funktionieren. Sicherheit muss von Beginn an ein zentraler Bestandteil der Anwendungsarchitektur sein und bei der Codierung immer berücksichtigt werden. Sicherheit nachträglich zu implementieren führt immer zu Krückenlösungen.
Sicherheit muss geplant werden. Und Sicherheit muss standardisiert werden. Das Zauberwort heißt (schon seit Jahren) Anwendungssicherheitsinfrastrukturen. Es geht um standardisierte Infrastrukturen, die Dienste für die Entwickler bereitstellen. Dienste, um Identitätsdaten zu speichern. Dienste, um Benutzer zu authentifizieren. Dienste, um die Autorisierung zu steuern. Dienste, um Audit-Informationen standardisiert bereitzustellen. Dienste für die Verschlüsselung von Informationen.
Diese Dienste müssen, soweit vorhanden, Standards nutzen. Dazu gehören Standards wie LDAP, SAML, XACML und einige weitere. Sie müssen aber vor allem auch für die Entwickler in einfacher Weise verfügbar gemacht werden, so dass sie eine Erleichterung und nicht eine zusätzliche Last in den zeitlich ohnehin meist knappen Projektplänen für die Softwareentwicklung darstellen.
Die Vorgaben müssen aber in gleicher Weise auch für die Beschaffung von Software gelten. Auch diese Systeme müssen die Sicherheitsinfrastruktur unterstützen. Gerade hier sind Standards von zentraler Bedeutung, um Systeme flexibel einbinden zu können.
Nicht immer ist es aber das Ziel der Entwickler, das zu erreichen. Wenn man viele der sozialen Netzwerke betrachtet, geht es ja genau nicht darum. Hier wird Sicherheit oft als Gefahr für das Geschäftsmodell verstanden, auch wenn immer deutlicher wird, dass das Fehlen von Sicherheit und Kontrolle über die eigenen Daten auf Dauer das viel größere Risiko für solche Geschäftsmodelle ist.
Auch beim Blick auf das Verhalten von Mobiltelefonen wird deutlich, dass dort oft genau die möglichst umfassende Weitergabe von Informationen an Dienstanbieter, Apps und so weiter das Ziel ist. Und gerade weil man die Konzepte dort so angelegt hat, dauert es dann auch, bis Patches verfügbar sind, wenn fragwürdige Funktionsweisen von Systemen wie vor einiger Zeit mit den Ortungsdaten beim iPhone publik werden. Denn statt einfach einen Schalter zu ändern, muss man viel tiefer in die Software einzugreifen. Auch das ist ein Mangel an „Security by Design“.
Wenn man verschiedene Funktionsweisen in Bezug auf die Sicherheit als konfigurierbare Optionen realisiert, ist man später viel flexibler. Das mag am Anfang nach mehr Aufwand aussehen und ein häufiges Gegenargument ist, dass es für den Nutzer zu komplex würde. Ersteres gilt aber nur, wenn man die Konzepte für die Entwickler nicht gut vorbereitet und unterstützt. Wer nur standardisierte Funktionen nutzen muss, wird sich damit leichter tun.
Gute Anwendungssicherheitsarchitekturen und deren Schnittstellen machen dem Entwickler die Arbeit einfacher. Letzteres, also die Komplexität für den Nutzer, gilt nur dann, wenn man keine gute Basiskonfiguration liefert. Man kann auch granulare Sicherheitsmodelle mit wenig Konfigurationsaufwand für die Masse der Nutzer verfügbar machen – mit Standardeinstellungen, mit mehreren Sicherheitsniveaus als durchdachte Optionen. Die, die mehr brauchen, können sich dann immer noch mit Details beschäftigen.
Aber nur dann, wenn Software als sichere Software entwickelt wird und Sicherheit ebenso wie „Privacy“ wesentliche Designkriterien von Beginn an sind, wird man schnell auf neue Anforderungen, neue Sicherheitsbedrohungen und den wachsenden Bedarf an sicherer Software bei Kunden reagieren können.