Richtlinien & Co.: Tipps zur Dokumentation beim Management der Informationssicherheit (Teil 1)

Die Dokumentation von Soll-Zuständen ist im Bereich der IT- und Informationssicherheit oftmals ein ungeliebtes Kind. Wenn man das Thema strukturiert und mit Augenmaß angeht, kann es aber auch mit eingeschränkten Ressourcen bewältigt werden.

Eine an sich niedrige, aber für manche Autoren schwer überwindbare Hürde sind die formellen Anforderungen. In jedem Dokument müssen dessen Zielsetzung, Zielgruppen und sein Geltungsbereich angegeben sein. Der Dokumentenname muss eindeutig sein und einem standardisierten Schema folgen. Wichtig sind auch eine Versionshistorie sowie eine Liste weiterführender und mitgeltender Dokumente im Anhang. Diese und weitere Formalien müssen durch die Organisation vorgegeben werden, idealerweise in Form einer verbindlichen Dokumentenvorlage bzw. der Vorgabe für ein Medium – letzteres kann auch das Intranet oder ein Wiki sein.

Hierarchie

Es empfiehlt sich, in jedem Dokument dessen Position innerhalb der Dokumentenhierarchie zu spezifizieren. Diese Hierarchie muss zunächst einmal erarbeitet und festgelegt werden. Für eine größere Organisation können beispielsweise folgende Hierarchieebenen sinnvoll sein:

Die Leitlinie, im englischen Sprachgebrauch als „Policy“ zu übersetzen, gibt den strategischen Rahmen vor. Sie hat typischerweise eine hohe Lebensdauer und muss nur durch weitreichende Veränderungen angepasst werden, zum Beispiel Änderungen in der Unternehmensstrategie, M&A-Aktivitäten, neue regulatorische Anforderungen oder auch die Gründung neuer Geschäftsfelder. Eine Leitlinie wird immer durch eine Person aus der Geschäftsführung oder dem Vorstand unterzeichnet und freigegeben.

Richtlinien werden oftmals auch als „Standards“ oder „Specifications“ betitelt. Eine Richtlinie setzt die Leitplanken für bestimmte Themen, i.d.R. ohne auf spezifische Technologien oder Produkte einzugehen. Im „denglischen“ Sprachgebrauch verwendet man „Richtlinie“ aber auch gerne synonym mit „Policy“. Das muss kein Problem sein – Hauptsache, man hat intern geklärt, wie die Hierarchie aussieht und die Begrifflichkeiten gehandhabt werden.

Auf Richtlinienebene empfiehlt sich die Orientierung an Standards – im privaten Sektor insbesondere dem Annex 1 der ISO 27001:2013. Der Bezug zu einzelnen ISO 27001 Controls sollte im Dokument nachvollziehbar sein.

Eine Richtlinie hat je nach Thema eine Haltbarkeit von 3 bis 5 Jahren. Änderungen werden beispielsweise bei gravierenden Veränderungen der Bedrohungs- und Schwachstellen-Szenarien, Technologien oder Arbeitsmodellen notwendig.

Arbeitsanweisungen („Procedures“) als dritte Hierarchieebene sind in der Regel deutlich organisationsspezifischer ausgeprägt. Die Vorgaben einer Arbeitsanweisung sind auch wesentlich konkreter und beziehen sich oft auf spezifische Technologien, Zielgruppen oder sonstige Bereiche wie Anwendungen. Sie zielen darauf, durch eine starke Einschränkung der Freiheitsgrade das Umsetzen ganz konkreter Anforderungen zu erzwingen. Zwischen Arbeitsanweisung und Richtlinie übrigens findet man in einigen Unternehmen begriffliche Verwirrung vor.

„Guidelines“ sind im deutschen Sprachgebrauch nicht Richtlinien, sondern vielmehr Umsetzungsempfehlungen, die keinen verbindlichen Charakter haben. Wer pragmatisch ist, integriert solche Umsetzungsempfehlungen in Arbeitsanweisungen.

Sicherheitskonzepte stellen die konkreteste Vorgabe dar. Im Gegensatz zu den oben genannten Dokumenten geht es bei Sicherheitskonzepten um die Erfüllung eines ganz konkreten Ziels, nämlich der Reduzierung von Risiken für ein IT-System, eine Anwendung oder einen IT-Verbund auf ein „akzeptables“ Maß. Zumeist, aber nicht immer, wird man die vorgenannten Richtlinien und Arbeitsanweisungen einhalten.

Lesen Sie am 19.03.2014 in Teil 2 weiter, was sich in der Praxis bewährt hat!