Viele Anwendungen sind hinsichtlich Sicherheit und des Umgangs mit sensiblen, insbesondere privaten Daten ("Privacy") nicht so gut, wie man das erwarten würde. Ein dafür immer wieder ins Feld geführte Ausrede ist die Benutzerfreundlichkeit. Ein falsches Argument, weil es nur über die Schwächen in Softwaredesign und -entwicklung oder die Ignoranz bei der Sicherheit hinwegtäuschen soll.
Im Gespräch mit Softwareherstellern zur Sicherheit in deren Anwendungen wird der Autor häufig mit schwachen Authentifizierungsmechanismen, einem nur grob granularen Berechtigungskonzept, unzureichenden Log-Mechanismen und andern Schwächen konfrontiert: Es gibt keine Möglichkeit, flexibel andere, starke Authentifizierungsmechanismen einzubinden. Es gibt keine Unterstützung für Federation-Standards. LDAP wird immerhin schon oft, aber keineswegs immer unterstützt, um auf bestehende Verzeichnisse zuzugreifen. Bei den Berechtigungen gibt es häufig nur wenige fest definierte "Rollen" mit fest zugewiesenen Berechtigungen. Und Log-Dateien sind ebenfalls vielfach nicht so, dass man mit den darin enthaltenen Informationen beispielsweise in SIEM-Produkten (Security Information and Event Management) etwas Sinnvolles anfangen könnte.
Ein beachtlicher Anteil von Software ist also weiterhin "insecure by design". Aufschrecken lassen aber auch die Antworten, die Softwarehersteller bei Fragen nach den Gründen liefern. Eine oft gehörte Antwort ist, dass bisher noch kein Kunde danach gefragt habe. Kaum anzunehmen, dass das wirklich so ist. Und selbst wenn es so wäre: Inzwischen müsste jeder gemerkt haben, dass die Sicherheitsanforderungen steigen, und jeder sollte vorausschauend handeln.
Wenn es um die Unterstützung unterschiedlicher Sicherheitsmechanismen geht, ist ein anderes Argument ist, dass ein ausgefeilteres Sicherheitskonzept zu komplex wäre. Nun, wenn ein sinnvolles Verfahren als Standard eingerichtet ist, muss es nur den Kunden kümmern, der etwas anderes möchte.
Mit der Benutzerfreundlichkeit argumentieren Softwarehersteller aber vor allem, wenn es um das Berechtigungsmanagement in der Anwendung geht. Es spricht nichts dagegen, einige Standardrollen mit zugeordneten Berechtigungen anzubieten. Das bedeutet aber nicht, dass der Kunde nicht in der Lage sein sollte, sein eigenes, feingranulares Konzept mit weiteren Rollen umzusetzen und mit einer genauen Steuerung dessen, welcher Task von wem ausgeführt werden darf. Es sollte auch nicht daran hindern, diese Sicherheit von außen steuerbar zu machen, also beispielsweise XACML (Extensible Access Control Markup Language) zu unterstützen. Denn es ist nicht allzu schwierig, ein flexibles Modell mit Standardwerten zu konfigurieren – ein starres Modell lässt sich aber nicht anpassen.
Das eigentliche Problem der Ausreden ist, dass es relativ einfach ist, ausgefeilte und flexible Sicherheitskonzepte im Grunddesign einer Anwendung anzulegen. Es ist auch einfach, dass so zu parametrisieren, dass die Anwendung "out of the box" mit einer Basiskonfiguration der Sicherheit nutzbar ist, die gleichermaßen sicher wie benutzerfreundlich ist. Gute Sicherheit lässt sich aber nachträglich ohne massive Eingriffe in Anwendungen, oft bis hin zur Neuentwicklung, kaum umsetzen. Deshalb sollte man nicht nach Ausreden suchen, sondern von Beginn an Anwendungen so entwickeln, dass sie auch mit wachsenden Sicherheitsanforderungen der Kunden (und Analysten) mithalten können. Benutzerfreundlichkeit ist jedenfalls eines der absurdesten Argumente gegen sichere Anwendungen.