Passwörter: Sicherheitsvorgaben vs. Realität

Ist "admin" ein sicheres Passwort? Sie werden mir vermutlich zustimmen, dass dies nicht so ist und dennoch weichen Theorie und Praxis bei Passwörtern häufig voneinander ab.

Schon 2016 schrieben Pöpping, Rohr und Schneider in ihrem Artikel "Sicherheit agil verankern" für das Java Magazin:

"Sicherheitsvorgaben beschreiben, welche Sicherheitsmaßnahmen im Endeffekt einzuhalten und umzusetzen sind. An diesen mangelt es grade in großen Unternehmen nur selten, doch sind sie vielfach sehr abstrakt. Das ist grundsätzlich auch richtig, da Vorgaben letztlich aus der Sicherheitsrichtlinie abgeleitet und vom Chief Information Security Officer (CISO) verantwortet werden müssen. Andererseits sollten Sicherheitsvorgaben auch für diejenigen zu verstehen sein, die sie umsetzen sollen – also für Entwickler."

Wie weit Sicherheitsvorgaben von der gelebten Praxis abweichen können, hat sich kürzlich bei einem unserer Kunden gezeigt: Durch einen Sicherheitsvorfall wurden alle Kennwörter für technische Benutzer überprüft und geändert. Diese technischen Nutzer werden in Anwendungen oder Batches verwendet um mit anderen Servern oder Anwendungen Daten auszutauschen, also z.B. einen Webservice zur Datenbeschaffung aufzurufen. Dabei sind an verschiedenen Stellen und oft mehrfach erstaunliche Fälle zutage getreten:

• Verwendung derselben Nutzer für Test- und Produktionsumgebung
• Verwendung derselben Nutzer für verschiedene Anwendungen
• in Verbindung mit einer Häufung von Rechten an verschiedenen Nutzern
• und fehlender Dokumentation, welche Rechte für welche Funktion verwendet werden
• Verwendung derselben Passwörter für Test und Produktion
• Verwendung von Passwörtern, die sich nur im Suffix voneinander unterscheiden (-Test / -Prod)
• Verwendung von (minimal abgewandelten) Nutzernamen als Passwort
• Ablage von (Produktions-)Passwörtern im Code, in Konfigurationsdateien und weiteren Stellen, die von jedem Entwickler des Unternehmens eingesehen werden können

Dabei wurden die erzwungenen Richtlinien (Passwort-Policy) erfüllt, aber sämtliche weitere Regeln und Best Practices, wie sichere Passwörter, Minimierung von Rechten, passwortlose Authentifizierung oder keine Weiterverwendung von Nutzern oder Passwörtern, ignoriert. Obwohl dies natürlich in den entsprechenden Leitfäden zur Informationssicherheit vermerkt ist.

Was kann aus diesem Vorfall gelernt werden:

• Eine gute Ausbildung und Sensibilisierung für Entwickler ist essenziell. Nur wenn ich weiß, welcher Schaden durch die oben genannten Fehler entstehen kann und ich die Best Practices kenne, werde ich diesem Thema Zeit widmen und nicht die Abkürzung nehmen (z.B. Wiederverwendung eines bestehenden Nutzers oder Ablage von Zugangsdaten im Code-Repository).
• Die Sicherheitsprozesse müssen etabliert und gelebt werden. Dies erfordert mehr als nur Regeln niederzuschreiben.
• Technische Maßnahmen, wie eine Prüfung gegen Passwort Blacklists oder das Setzen von Credentials zur Laufzeit, können anders als organisatorische Prozesse nicht ignoriert werden
• Sicherheitsleitfäden verstauben in der Praxis nur im Regal und helfen hauptsächlich nach dem Motto "Wer schreibt, der bleibt". In einer "Blameless"-Kultur sollte es aber nicht das primäre Ziel sein, die Schuld an Sicherheitsvorfällen loszuwerden, sondern gemeinsam die Sicherheit der Anwendungslandschaft hochzuhalten. Hier helfen 10 Stichpunkte für Anwender und eine offene Anlaufstelle mehr als der 85-seitige Leitfaden für IT-Sicherheit.

Kommen Ihnen die oben genannten Fehler auch aus Ihrem Unternehmen bekannt vor? Benötigen Sie Hilfe bei der Umsetzung von technischen oder organisatorischen IT-Sicherheitsmaßnahmen? Sprechen Sie uns an!