Doppelt effizient Einsparpotenzial durch gemeinsame Strukturen in IT-Qualitäts- und -Sicherheitsmanagement

Ordnungsmerkmale

erschienen in: <kes> 2007^#1, Seite 18

Zusammenfassung: Bestimmte Aspekte des IT-Sicherheits- und -Qualitäts-Managements bergen erhebliche Synergien. Besonders rein formale Management-Aufgaben wie Verwaltung, Berichtswesen und Organsisation lassen sich häufig über beide Gebiete zusammenfassen, was erhebliche Einsparungen bewirken kann.

Autor: Von Mark Schenkl, München

Betrachtet man das (funktionelle) IT-Sicherheitsmanagement im Sinne eines Leitungsprozesses, so ergeben sich viele Analogien zum IT-Qualitätsmanagement. Bei entsprechender Auslegung eröffnen sich vielfältige, bisher meist ungenutzte Synergien. Unter IT-Sicherheitsmanagement soll hier genauer gesagt derjenige Teil der IT-Sicherheit verstanden werden, der sich mit ihrer Planung, Steuerung und Kontrolle befasst. Der Begriff "IT-Risikomanagement" wird hier nicht explizit definiert und erwähnt, da dieses lediglich als integraler Teilaspekt der IT-Sicherheit verstanden wird.

Obwohl die IT-Sicherheit seit einigen Jahren als Top-Thema in den deutschen Unternehmen gilt, kann dieser Achtungsgewinn dennoch nicht darüber hinwegtäuschen, dass sie aus Unternehmenssicht originär als Kostenfaktor auftritt. Speziell in Zeiten schrumpfender IT-Budgets entwickelt sich hieraus häufig ein Widerspruch zur Bedeutung des Themas. Das Sparen an konkreten Sicherheitsmaßnahmen führt jedoch schnell zu ungewollten Risiken, deshalb sollte man zunächst versuchen den Verwaltungsaufwand der IT-Sicherheit zu senken, das heißt beim IT-Sicherheitsmanagement nach Sparpotenzial zu suchen.

Einen interessanten Ansatz bietet hierzu das IT-Qualitätsmanagement, das ebenfalls zu den "notwendigen Kostentreibern" im Unternehmen gehört und von den prinzipiellen Abläufen her eng mit dem IT-Sicherheitsmanagement verwandt ist. Diese Verwandtschaft äußert sich unter anderem darin, dass die International Organization for Standardization (ISO) Prozesse sowohl für das Qualitäts- wie auch das Sicherheitsmanagement definiert hat, die beide auf dem so genannten PDCA-Zyklus basieren: Plan, Do, Check, Act. Für die Zukunft plant die ISO sogar eine noch weitere Vereinheitlichung der verschiedenen Managementstandards zu Qualitäts- (ISO 9001), Sicherheits- (ISO 27001) und Umwelt-Management (ISO 14001).

Auch wenn der Autor der Meinung ist, dass das IT-Sicherheitsmanagement nicht adäquat durch plandeterminierte PDCA-Zyklen darstellbar ist (vgl. Kasten), so ist das Vorgehen der ISO doch ein Indiz für die Ähnlichkeit der beiden Managementaufgaben. Ein weiteres Indiz liefert die Diskussion, ob denn IT-Sicherheit ein Qualitätsmerkmal oder doch eher die Qualität ein Sicherheitsmerkmal sei.

Egal welcher Argumentation man eher folgen mag – in der Nutzung gemeinsamer Managementmethoden, -werkzeuge und Organisationsstrukturen liegt ein bisher meist ungenutztes Potenzial für Einsparungen. Dabei gilt: Je formaler die Aufgabe, desto leichter lässt sie sich durch gemeinsame Methoden und Strukturen abbilden. Welche Aufgaben sich hier im Einzelnen anbieten, wird von Unternehmen zu Unternehmen variieren. Einige Beispiele sind im Folgenden aufgeführt.

Überschneidungen formalisierbarer Aufgaben aus IT-Sicherheits- und -Qualitätsmanagement

Reporting

Eine Trennung der Organisationseinheiten IT-Qualitätsmanagement und IT-Sicherheitsmanagement bedingt meist auch ein unabhängiges Reporting des IT-Sicherheits- und des Qualitätsstatus an das Management. Ein dedizierter IT-Sicherheitsbericht verschwendet jedoch nicht nur unnötig Ressourcen, sondern verhindert auch eine integrative Gesamtsicht auf das Thema IT, zu der die IT-Sicherheit nach wie vor dazugehört. Die unabhängige Betrachtung von IT-Qualität und -Sicherheit ist nicht in der Lage, ein schlüssiges Bild der Gesamtlage der IT darzustellen. Hinzu kommt, dass das Management meist derart mit Informationen überschüttet wird, dass "noch ein" zusätzlicher Bericht kaum Beachtung findet.

Zielführender ist die Integration der aktuellen Erkenntnisse zum Thema IT-Sicherheit als Parameter in ein konsolidiertes Reporting für das (institutionelle) Management.

Kennzahlen

Zum Reporting gehört – wenngleich nicht zwangsläufig – die Erhebung von Kennzahlen. Sofern die Erhebung von IT-Sicherheitskennzahlen überhaupt sinnvoll ist, sollten ihre Definition und Auswertung in einem Gesamtkontext mit anderen IT-Steuergrößen erfolgen. Eine isolierte Betrachtung der Sicherheitskennzahlen ist nicht sinnvoll, da der Gesamtkontext verloren geht und damit komplexe Abhängigkeiten und Zusammenhänge leicht übersehen werden.

Darüber hinaus dürfte es bei vielen Kennzahlen schwierig sein, sie eindeutig der IT-Sicherheit zuzurechnen (z. B. Verfügbarkeitskennzahlen). Das Erheben und Nutzen von IT-Kennzahlen lebt aber gerade davon, eine themenübergreifende Sicht auf unterschiedlichste Sachverhalte zu generieren (vgl. Business Intelligence) und sollten deshalb in einem möglichst umfassenden Kontext erfolgen. Dies lässt sich am einfachsten über die Steuerung durch eine einzige Managementgruppe realisieren (d. h. eines vereinten IT-Sicherheits- und Qualitätsmanagements).

Leider passiert es häufig, dass die Managementgruppe die Kennzahlen nicht nur erhebt, sondern diese auch gleich bewertet. Speziell für die Konsolidierung und Prüfung der Ergebnisse auf Kausalität darf man jedoch nicht auf das (kombinierte) Wissen der jeweiligen Experten verzichten. Ansonsten bekommt die "zusammengeschriebene" Kennzahlensammlung leicht einen Informationsgehalt vergleichbar einem Sudoku-Rätsel.

Organisation

Der Aufbau und die Pflege eines IT-Sicherheitsnetzwerks und die Verankerung der IT-Sicherheit in der Organisation (z. B. durch geeignete Gremien, Schulungs- und Awareness-Maßnahmen) erzeugen im Rahmen des IT-Sicherheitsmanagements vermutlich den größten Verwaltungsaufwand. Dennoch sind derartige Strukturen notwendig, um das Thema IT-Sicherheit in der Organisation und letztendlich auch in den Köpfen der Mitarbeiter und des (institutionellen) Managements zu verankern.

Da Vergleichbares für die in der Regel bereits seit mehreren Jahren vorhandenen Strukturen gilt, mit denen sich das IT-Qualitätsmanagement in der Organisation verankert, ergeben sich hier weitere Synergien. Dies soll im Folgenden beispielhaft an den Managementgremien und konkreten Rollen (QS-Beauftragte und IT-Sicherheitsbeauftragte im Projekt) verdeutlicht werden.

Kreise und Gremien

Sofern das IT-Qualitäts- und -Sicherheits-Management auf gleicher Ebene verankert sind (beides sind schließlich Führungsaufgaben), bietet es sich an, die Verantwortung für die skizzierten Aufgaben einem gemeinsamen Entscheiderkreis zu übertragen – dazu gehören Aufbau und Pflege eines Netzwerks, Verankerung von IT-Sicherheit und Qualität in der Organisation, Diskussion von Berichten und Kennzahlen et cetera. Damit lässt sich zum einen "Managerzeit" sparen, zum anderen entstehen durch die Bündelung in einem Personenkreis zwangsläufig Synergien bei der Diskussion der Themen.

QS- und IT-Sicherheitsbeauftragte im IT-Projekt

Die Verantwortung für die IT-Qualität und die IT-Sicherheit hat immer der Projektleiter. Der QS- beziehungsweise IT-Sicherheits-Beauftragte unterstützt ihn lediglich bei der Wahrnehmung seiner Verantwortung. So prüft der QS-Beauftragte die Einhaltung formaler Projektmanagementvorgaben, wie das Vorliegen bestimmter Dokumente, die Durchführung von Abnahmeverfahren und unterstützt methodisch zum Thema IT-Qualität et cetera.

Der IT-Sicherheitsbeauftragte kontrolliert die Einhaltung formaler IT-Sicherheitsvorgaben wie die Prüfung, ob Risiken identifiziert wurden, ein IT-Sicherheitskonzept existiert oder ein Penetrationstest durchzuführen ist. Im Idealfall ist auch er in der Lage methodisch zu unterstützen.

Beide Rollen sind geprägt von formalen Kontrollaufgaben, die kein tiefes inhaltliches Know-how erfordern. Deshalb können sie einem Skill-Profil zugemutet, und damit auch in einer Rolle vereint werden. Hierdurch spart man neben dem Aufwand für die Pflege zweier Rollen auch Schnittstellen im Projekt.

IT-Policies

Jedes Unternehmen verfügt über Policies (Regeln, Vorgaben), welche den Umgang mit der IT regeln. Diese Richtlinien werden von verschiedenen Stellen mit unterschiedlichen Aufgaben und Zielsetzungen herausgegeben (z. B. QS, IT-Sicherheit, Produkt-und Systemverantwortliche, IT-Architekten, Personalabteilung, Betriebsrat und Juristen zum Thema Internetnutzung). Dank der Vorgaben durch ISO 17799 (bzw. ISO 27002) hat sich in den meisten Unternehmen – zumindest was die IT-Sicherheit angeht – ein "Standardwerk" etabliert, in dem man Sicherheitsthemen sammelt.

Aus für den IT-Nutzer nur schwer nachvollziehbaren Gründen existiert jedoch meist keine Gesamtsicht auf alle für ihn maßgeblichen IT-Regeln. Den Nutzer interessiert jedoch nicht, welchen Ursprung die einzelnen Vorgaben haben, sondern nur, welche für ihn gemäß seiner jeweiligen Rolle relevant sind (IT-Administrator, Anwender, Projektleiter etc.). Das Ziel sollte daher sein, verschiedene Sichten auf alle durch die IT motivierten Vorgaben zu generieren. Diese Sichten können in verschiedene Kategorien unterteilt werden wie Zielgruppe oder Themen (IT-Sicherheit, QS, Betrieb, Internet).

Eventuell ist bei den IT-Sicherheitsregeln eine zusätzliche Zuordnung zu ISO-17799/27002-Controls sinnvoll, um eine unternehmensübergreifende Vergleichbarkeit verschiedener Regelwerke zu vereinfachen. Hier bietet sich die Ablage der einzelnen Regeln in einer Datenbank oder einem Dokumentenmanagementsystem mit entsprechenden Such- und Sortierparametern an (z. B. "alle für Endanwender relevanten Vorgaben zur Internetnutzung").

Aus Sicht der Zielgruppen ist das gesonderte Bereitstellen von IT-Sicherheits- und QS-Vorgaben wie angemerkt wenig sinnvoll; gewünscht ist die Integration in ein "Gesamtwerk". Die Aufgabe, alle IT-Policies zu kommunizieren und zu koordinieren (d. h. Regelungswidersprüche erkennen und auflösen) sollte dabei von einer Managementstelle übernommen werden. Andererseits kann man einer reinen Managementstelle nicht die inhaltliche Verantwortung für die IT-Policies übergeben – hier ist wieder das Know-how der jeweiligen Experten gefragt.

Meist stellt zudem die inhaltliche und redaktionelle Arbeit an den Policies bis zur Abstimmung einen erheblichen Aufwand dar. Hier könnte man sich an der Wikipedia orientieren und die Diskussion und Formulierung der einzelnen Regeln mittels eines (moderierten) WIKI unterstützen (vgl.  http://de.wikipedia.org/wiki/Wiki).

Fazit

Diese Aufzählung soll nicht besagen, dass die IT-Sicherheit lediglich ein Teil des Qualitätsmanagements ist! Das IT-Qualitätsmanagement ist jedoch dem IT-Sicherheitsmanagement um circa 15 Jahre voraus und hatte genug Zeit, in vielen Unternehmen effiziente Strukturen auszubilden. Aus diesem Grund kann das IT-Sicherheitsmanagement durchaus davon profitieren, wenn auf bereits vorhandene Managementstrukturen aufgesetzt wird. Thematisch sollte man es aber gleichberechtigt neben dem IT-Qualitätsmanagement verankern – weder das Eine noch das Andere kann hier eine intellektuelle Führerschaft beanspruchen, dazu decken letztendlich beide inhaltlich zu verschiedene Bereiche ab.

Um die hier skizzierten Synergien und Einsparpotenziale zu nutzen, ist es natürlich sinnvoll, eine das IT-Qualitäts- und -Sicherheitsmanagement vereinende Funktion außer mit IT-Qualitätswissen auch mit IT-Sicherheitswissen auszustatten. Obgleich das nicht ohne Aufwand durchführbar ist, ist dies doch deutlich ressourcenschonender als die Schaffung und der Unterhalt einer komplett eigenständigen Querschnittsfunktion "IT-Sicherheitsmanagement" inklusive aller notwendigen Managementkonstrukte, die strukturell lediglich eine Kopie des IT-Qualitätsmanagements mit Instanziierung als IT-Sicherheitsmanagement darstellen.

Der genannte Wissensbeitrag sollte zwar durch IT-Sicherheitsexperten mit mehrjähriger Berufserfahrung erfolgen. Der Großteil des Tagesgeschäfts im IT-Sicherheitsmanagement ist bei sorgfältiger Aufgabendefinition (Prozessbeschreibungen) jedoch eine reine Verwaltungsaufgabe und verlangt eher nach einem "IT-Sicherheits-Sachbearbeiter".

Kompetenz begrenzen

Je nach Ausrichtung und Besetzung dieser "Verwaltungsstelle" muss man beachten, ihr nicht zu viele inhaltliche Kompetenzen zur IT-Sicherheit zu übertragen. So ist es beispielsweise nicht sinnvoll, ihr (also letztendlich den Sicherheitssachbearbeitern) die komplette IT-Sicherheitsplanung zu überlassen. Auch wenn Managementabteilungen (häufig als Stabsstellen geführt) in besonderer Weise mit den Instrumenten und Methoden der Planung vertraut sein mögen und so den Planungsprozess kompetent anleiten könnten, erweist sich doch die Übertragung der gesamten Planungsarbeiten – aufgrund fehlenden Wissens aus dem operativen Tagesgeschäft – in vielen Fällen als Fehlschlag.

Die IT-Sicherheitsplanung muss in den Händen derjenigen Leute liegen, die über die relevanten Informationen aus dem operativen Geschäft verfügen und später die Pläne umzusetzen haben oder zumindest daran mitwirken. Die Kluft zwischen Handlungswissen und Methodenwissen lässt sich an dieser Stelle durch ein Team aus operativen Linienmanagern und IT-Sicherheitsmanagern überbrücken.

Das gilt ebenso für eine Reihe weiterer IT-Sicherheitsaufgaben, für die das Befolgen eines Prozesses unter Einbezug des (in der Regel) punktuell vorhandenen Laienwissens – "da Verschlüsselung, dort starke Authentifizierung einsetzen" – nicht ausreicht. Hier ist der komplexe Sachverstand von IT-Sicherheitsexperten notwendig! Zu solchen Aufgaben gehören beispielsweise das IT-Security-Engineering (Erstellen von IT-Sicherheitskonzepten), die inhaltliche Gestaltung von IT-Sicherheitsregeln, die Verankerung der IT-Sicherheit im Projektmanagement und die fachliche Beratung zum Thema in Projekten.

Die wohl größte Gefahr besteht in diesem Zusammenhang darin, dass IT-Leiter glauben könnten, mit einem effizienten IT-Sicherheitsmanagement das Gesamtthema IT-Sicherheit ausreichend zu behandeln. Frei nach dem Motto: "Wir verwalten die IT-Sicherheit effizient – aber wie es inhaltlich darum steht, kann keiner sagen".

Dipl.-Inf. Mark Schenkl (CISSP) ist IT-Sicherheitsmanager bei der BMW AG.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007^#1, Seite 18
tag:kes.info,2007:art:2007-1-018