Nebst den verschiedenen technischen Arbeiten in der Informatik, mag ich den Teil der IT-Philosophie. Das Wie und Warum hat mich schon seit jeher fasziniert und gerade die Informatik, als noch relativ junger Bereich, bietet viel Stoff für Fragen.

Auf der anderen Seite haben sich schon gewisse Meinungen etabliert, die ich zwar gerne hinterfrage, bei denen es aber fast nichts zu rütteln gibt. Ein Beispiel dafür ist, dass eine Firewall das interne Netzwerk vor Eindringlingen aus dem Internet schützt und deshalb unverzichtbar ist.

Solche Meinungen findet man dann meistens auch in den Sicherheitsrichtlinien der verschiedensten Firmen wieder. Was mich, vor allem als Engineer, immer wieder mal gestört hatte, war die Tatsache, dass Sicherheitsrichtlinien meistens nicht verhandelbar waren. Was mich wiederum zum Thema meines Artikels führt:

Wie statisch sollten Sicherheitsrichtlinien sein?

Der folgende Beitrag wiederspiegelt meine Gedanken zu diesem Thema und stellt eine von vielen Möglichkeiten dar, sich mit dem Thema Sicherheitsrichtlinie zu befassen. Es würde mich natürlich freuen wenn es dem einen oder anderen Leser als Gedankenanregung dienen würde.

Ausgangslage

In meinen nunmehr 15 Jahren, in denen ich im Bereich der Informatik tätig bin, habe ich die eine oder andere IT-Sicherheitsrichtlinie durchgelesen. Es ist immer wieder spannend zu sehen wie sich die Richtlinien von Firma zu Firma unterscheiden. Mal passen die Richtlinien auf eine A4-Seite, mal können sie im Umfang mit der _Herr der Ringe_-Trilogie konkurrieren. Meistens bewegt sich der Umfang aber in einem angemessenen Rahmen.

Über die Jahre wurden immer mehr Bereiche der Informatik in die internen Sicherheitsrichtlinien aufgenommen und durch sie geregelt. Eine der ersten und wohl am meist vorkommende ist, die Passwort Richtlinie. Nun frage ich Sie, wann wurde diese Richtlinie erstellt und wann und wie oft wurde sie geändert? Und was war der Grund für diese Änderung?

Ich denke mal dass die Häufigkeit der Änderungen sich eher im tiefen, einstelligen Bereich befindet. Und der Grund für die Änderungen waren wahrscheinlich neue Erkenntnisse Rund um das Thema Password Cracking. Aber gehören diese Änderungen in eine Sicherheitsrichtlinie?

Meiner Meinung nach definiert eine IT-Sicherheitsrichtlinie den grössten gemeinsamen Nenner der einzelnen Komponenten einer IT-Infrastruktur, womit ich die vorhergehende Frage verneinen würde. Ebenfalls sind Änderungen an der Sicherheitsrichtlinie meist mit langwierigen Prozessen verbunden, was ein schnelles Reagieren auf Änderungen erschwert.

Einflüsse auf die Sicherheitsrichtlinie

Wenn wir die verschiedenen Einflüsse auf die Sicherheitsrichtlinie anschauen, dann sehen wir, dass wir nicht immer nur von dem Bedürfnis den Betrieb sicherzustellen angetrieben werden. Je nach Branche kommen nebst regionalen Auflagen auch noch Bestimmungen durch Regulatoren hinzu.

Nehmen wir hier als Beispiel eine Schweizer Bank. Nebst den lokalen Datenschutzbestimmungen muss eine Schweizer Bank auch die Regulationen der FINMA einhalten. Tut sie dies nicht, kann es bis zum Entzug der Banklizenz kommen. Was die FINMA aber nicht macht, ist die Frage zu klären, wie etwas erreicht werden kann. Wenn die Frage des Wie nicht von der FINMA geklärt wird, warum sollte denn dieser Teil ein Bestandteil unserer Sicherheitsrichtlinie werden?

Das Passwortrichtlinien Beispiel

Kommen wir zurück zum Beispiel mit der Passwortrichtlinie. Haben Sie die obenstehende Frage zur Änderungshäufigkeit der Richtlinie mit mindestens ein Mal beantwortet, dann sind Sie eventuell verwundert, wenn ich Ihnen sage, dass diese Änderung nicht nötig gewesen wäre.

Wenn ich mich nämlich frage, warum ich eine Passwortrichtlinie habe, komme ich zum Schluss, dass es mir um eine sichere Anmeldung an dem jeweiligen System geht. Und dies wiederum resultiert aus dem Bedürfnis, dass nur autorisierte Benutzer auf die entsprechenden Ressourcen zugreifen dürfen. Wenn ich also ein Passwort wählen würde, das einfach zu erraten oder zu knacken wäre, würde ich mich der Gefahr aussetzten, dass unautorisierte Benutzer auf meine Ressourcen zugreifen könnten. Nun steigt die Rechenleistung eines Computers Jahr für Jahr an. Dies kann natürlich direkte Auswirkungen auf das Knacken eines Passworts haben. Was gestern noch als sicheres Passwort galt, kann heute schon als unsicher gelten. Sofort die Sicherheitsrichtlinie anpassen, oder doch nicht?

Eine Anmeldung mittels Passwort ist nur eine von mehreren Möglichkeiten, um einen Benutzer an einem System zu authentifizieren. Muss ich nun jede Möglichkeit einer Authentisierung in der Sicherheitsrichtlinie definieren?

Sowas gehört meiner Meinung nach, in diesem Beispiel, nicht in die Sicherheitsrichtlinie. Wenn die Richtlinie den grössten gemeinsamen Nenner definiert, könnte das in etwa so aussehen:

Der Zugriff auf eine IT-Ressource muss durch den Gebrauch eines sicheren Authentisierungsmechanismus gesichert werden.

Wenn man diese Richtlinie vor 20 Jahren so definiert hätte, sie hätte noch heute ihre Gültigkeit. Aber wo werden aber die Änderungen an der Definition von sicher abgehandelt?

Für diesen Zweck haben uns verschiedene Frameworks eine interessante Möglichkeit gegeben: Das Definieren von Controls. Ein Control ist ein Werkzeug, um das Einhalten der Richtlinien zu messen – vorzugsweise durch IT Auditors und IT Risk Manager. Bei dem Beispiel mit der Passwortrichtlinie, könnte ein einfacher Control in etwa so aussehen:

Wurde der Gebrauch eines sicheren Passwort durchgesetzt?

Nun kann man diesen Control mit der aktuellen Definition eines sicheren Passworts ergänzen. Dieser Control wäre einer von mehreren Controls, um die Richtlinie zu messen.

Eine noch elegantere Lösung wäre das Einführen einer zusätzlichen Ebene mit Unter-Controls. Der Control selbst würde einfach die Sicherheitsrichtlinie in die Frageform bringen:

Wurde die IT Ressource durch einen Authentisierungsmechanismus gesichert?

Und der Control betreffend dem sicheren Passwort würde zu einem Unter-Control.

Vor allem mit dem zweiten Ansatz erhalte ich eine hoch flexible Lösung, welche es mir ermöglicht, auf neue Gegebenheiten (Regulationen, Gesetze, Erkenntnisse im Bereich IT Sicherheit etc.) zu reagieren, indem ich bestehende Unter-Controls anpasse, ergänze oder entferne oder hinzufüge. Dies alles ohne nur einmal meine Sicherheitsrichtlinie zu ändern. Diese hohe Flexibilität ermöglicht es Security Engineers, schneller auf die neusten Entwicklungen zu reagieren und trotzdem gemäss den Sicherheitsrichtlinien zu handeln.

Fazit

Wenn man öfters die Sicherheitsrichtlinie anpassen muss, könnte man die nächste Änderung als Anlass nehmen, um die Richtlinie auf eine höhere Stufe zu bringen und dafür Controls definieren, die das Wie klären. Dies hilft die IT Sicherheitsrichtlinie selbst relativ statisch zu halten, was dazu beiträgt, eine Kontinuität in Bezug auf Sicherheit zu gewährleisten. Auf der anderen Seite hat man mit den Controls, die Flexibilität schnell auf Änderungen in der schnelllebigen Welt der Regulationen und Sicherheitsansprüche zu reagieren, ohne immer gleich das ganze Sicherheitskonzept zu überdenken.