![[Bild 1]](6-1.jpg)
Bild 1: Der IT-Risikomanagementprozess
Information hat sich im Rahmen des ökonomischen Strukturwandels in fast allen Industrienationen zum vierten Produktionsfaktor neben Arbeit, Kapital und Boden entwickelt. Die Wertschöpfung verlagert sich in vielen Unternehmen von der Produktion hin zur Dienstleistung. Insbesondere dienstleistungsorientierte Unternehmen, aber auch produzierende Betriebe sind somit für ihren wirtschaftlichen Erfolg zunehmend auf den Werterhalt und die Wertsteigerung der erzeugten, verarbeiteten, gelagerten und transportierten Informationen angewiesen. Die Förderung und Sicherung des wirtschaftlichen Erfolgs auf Basis der Produktionsfaktoren eines Unternehmens ist eine der vorrangigsten Aufgaben des Managements. In der Folge ist auch das Erkennen und Steuern von Risiken, die sich im Zusammenhang mit dem Produktionsfaktor Information ergeben, der so genannte Risikomanagementprozess, eine Aufgabe, mit der die EDV-Abteilung nicht allein gelassen werden sollte.
Der IT-Risikomanagementprozess umfasst alle Aktivitäten zum systematischen, strukturierten und effizienten Umgang mit Risiken, die der Einsatz von Informationstechnologie bedingt. Zu diesem Prozess gehören die Identifikation, Analyse, Bewältigung und Steuerung der IT-Risiken im Unternehmen, die institutionalisierte Überwachung des Erfolgs von Maßnahmen zur Risikominimierung sowie die Überwachung der Effektivität IT-Risikomanagementmaßnahmen. Diese Überwachung fördert durch entsprechende Rückkopplung zu den übrigen Prozessschritten die Stabilität, Flexibilität und Fortschreibung des IT-Risikomanagementprozesses. Die Überwachung des IT-Risikomanagementsystems muss operativ durch die Geschäftsleitung und strategisch durch Aufsichtsgremien erfolgen.
Der IT-Risikomanagementprozess beginnt mit der Festschreibung von Informationsschutz als Unternehmensziel. Dies wird in der Regel durch einen Beschluss des Vorstandes oder der Geschäftsführung eines Unternehmens vorgenommen. Ein solcher Beschluss sollte beispielsweise durch die Verabschiedung von Grundprinzipien dokumentiert werden: etwa der Festschreibung einer klaren Aufteilung von Verantwortlichkeiten und der fortdauernden Entwicklung des IT-Risikomanagementprozesses gemäß den geschäftlichen Anforderungen oder auch durch die explizite Anerkenntnis einer Verantwortung für die Informationen, Systeme und Güter.
Anschließend werden Schutzziele und Schutzzonen definiert: Das Unternehmen muss feststellen, welche schützenswerten Informationen im Unternehmen existieren oder seine Grenzen passieren, welcher Schutzbedarf dafür in Bezug auf Integrität, Authentizität und Vertraulichkeit angemessen und welche Verfügbarkeit notwendig ist. Diesbezügliche Regelungen trifft eine so genannte Klassifikationsrichtlinie.
Bild 1: Der IT-Risikomanagementprozess
Im Rahmen einer Systemanalyse wird alsdann die technische und organisatorische Infrastruktur aufgenommen und in der Folge einer Bedrohungsanalyse mit Risikobewertung unterzogen. Das Unternehmen untersucht mögliche Maßnahmen und Kosten zur Risikominimierung oder Risikoübertragung. Die Unternehmensleitung entscheidet sich anschließend für das gewünschte Verhältnis aus Kosten für Maßnahmen und akzeptiertes Restrisiko. Auf der Basis dieser Entscheidung wird ein Gesamtkonzept erstellt und in der Folge umgesetzt.
Entscheidend ist letztlich die regelmäßige Fortschreibung des Gesamtkonzepts, welche auch durch Einflüsse wie beispielsweise Systemänderungen, Risikoereignisse oder neue Technologien und Produkte angestoßen werden kann.
Der Schutz von Information setzt zwingend Verantwortlichkeiten voraus. Unabhängig vom spezifischen Geschäftsmodell eines Unternehmens sowie den verarbeiteten Informationen gibt es generische Rollen, die verschiedene Aufgaben implizieren. Für alle Informationen muss es einen benannten Eigentümer geben. Der Informationseigentümer ist verantwortlich für:
Bei der Festlegung des erforderlichen Sicherheits- und Kontrollumfangs muss der Informationseigentümer berücksichtigen, wie Informationen erzeugt und verwaltet werden. Ferner fließt die geschäftliche Relevanz der Informationen, ihre Sensitivität, die erforderliche Vertrauenswürdigkeit, ihre Verfügbarkeit und Nicht-Ablehnbarkeit seitens der Empfänger (Verbindlichkeit) in die Beurteilung ein. Der Informationseigentümer ist für den gewährten Zugriff auf seine Informationen verantwortlich und muss ihre Zugänglichkeit sowie den Umfang und die Art der Autorisierung des Zugriffes definieren. Bei diesen Entscheidungen sind zudem Aufbewahrungsvorschriften sowie die mit den Informationen verbundenen (aufsichts)rechtlichen Anforderungen zu berücksichtigen.
Bei den Informationseigentümern muss es sich nicht notwendigerweise um Einzelpersonen handeln. Vielmehr können durchaus auch ein Lenkungsausschuss, eine Prüfkommission oder eine andere offizielle Einrichtung diese Funktion übernehmen. Dabei sollte man bedenken, dass das Verwenden und das Sammeln von Informationen im Zuge ihrer Bearbeitung oder Übertragung zu einem neuen Informationseigentümer führen kann.
Für die Wahrung der Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität, Rechenschaftspflicht und Verbindlichkeit der Informationen in dem vom Informationseigentümer festgelegten Umfang ist ein Informationstreuhänder verantwortlich; er wird beispielsweise per Servicevertrag (Service Level Agreement oder Vollmacht) ernannt. Der Informationstreuhänder ist verpflichtet, den Informationseigentümer über die Risiken zu informieren, die sich durch getroffene Kontroll- und Sicherheitsentscheidungen ergeben. Wenn ein und derselbe Nutzer Informationen sowohl erzeugt als auch verwaltet, gilt er als Informationseigentümer und gleichzeitig als Informationstreuhänder.
Informationsnutzer (Mitarbeiter, Vertragspartner, Berater usw.) sind bei der Erstellung, Nutzung und Verwaltung von Informationen verpflichtet, die geltenden Informationssicherheitsstandards einzuhalten. Jeder Einzelne ist für sämtliche Maßnahmen verantwortlich, die er bei der Nutzung von Informationen und der damit verbundenen Systeme ergreift. Die Nutzer müssen verstehen, wann und warum Informationen, die von ihrem Unternehmen zur Durchführung ihrer Geschäfte verwendet werden, durch angemessene Kontrollen geschützt werden müssen.
Um diese Kontrollen durchzuführen, sind sie verpflichtet, angemessene Unterstützung einzuholen. Das Unternehmen sollte den Nutzern entsprechende Schulungen und Beratung über Informationssicherheit anbieten. Nutzer, die eine Verletzung der geltenden Informationssicherheitsstandards vermuten oder Kenntnis davon erlangt haben oder annehmen, dass Informationen nicht in geeigneter Weise geschützt sind, müssen dies unverzüglich ihrem Vorgesetzten oder einer (lokal oder global) zuständigen Sicherheitskontaktstelle melden.
Damit Entscheidungen und Aufgaben, die Personen in den genannten Rollen durchzuführen haben, einem einheitlichem Maßstab folgen, sind Vorgaben des Unternehmens notwendig. Sowohl die intern verarbeiteten Informationen als auch Informationen, die das Unternehmen über eine geeignete Schnittstelle passieren, werden Informationsklassen zugeordnet: beispielsweise Personaldaten, Entwicklungsunterlagen, Besprechungsprotokolle, Vorstandsvorlagen, Betriebskonzepte, Planungsdaten, operationelle Daten, Anwendungsdokumentation, Kundendaten oder Bilanzierungsdaten.
Die Informationen einer Informationsklasse besitzen alle denselben Schutzbedarf jeweils bezüglich Vertraulichkeit und Integrität. Kategorien für Vertraulichkeit, aus der sich der entsprechende Schutzbedarf ergibt, können sein:
Die Kategorien für Integrität folgen aus dem Maß, mit dem eine Manipulation der Daten verhindert werden muss. Man unterscheidet hier beispielsweise
In Einzelfällen kann die Authentizität von Informationen ein Qualitäts- oder Verwertbarkeitskriterium sein. Da dieses zurzeit jedoch vorwiegend noch für nicht-elektronisch gelagerte Informationen zutrifft (z. B. Verträge), wird diese Eigenschaft im IT-Risikomanagement bislang eher selten betrachtet. Im Rahmen der Etablierung digitaler Signaturen kann die Authentizität elektronischer Daten zukünftig jedoch eine größere Rolle spielen.
Sowohl Investitionen als auch laufende Kosten für Maßnahmen zur Risikominimierung steigen mit deren Wirksamkeit. Daher ist es sinnvoll, innerhalb des Unternehmens Zonen zu bilden, in denen ein einheitlicher Schutzbedarf für Informationen vorhanden ist, etwa nach folgenden Kriterien:
Welche Schutzzonen im Einzelnen gebildet werden und wie ihr Schutzbedarf anzusetzen ist, beschreibt in der Regel eine separate Richtlinie.
Ein im IT-Risikomanagement häufig anzutreffender Fehler ist die unstrukturierte Betrachtung von Komponenten, ohne dabei das eigentliche Ziel – die Sicherung des geschäftlichen Erfolges – im Auge zu behalten. Letztlich hängt der unternehmerische Erfolg von der effizienten Durchführung von Geschäftsprozessen ab. Im Umkehrschluss beschäftigt sich das IT-Risikomanagement mit den Ereignissen und Einflüssen, die IT-begründet die Durchführung der Geschäftsprozesse be- oder verhindern. Die Aufgabe der Systemanalyse besteht in der Erfassung aller maßgeblichen Prozesse sowie der unterstützenden Anwendungen, Prozessschnittstellen und Komponenten.
Für die darauf folgende Bedrohungsanalyse bezüglich der Risiken, welche die Betriebssicherheit beeinträchtigen, kann eine Priorisierung hilfreich sein. Dazu werden zunächst die Prozesse gemäß ihres Schadenspotenzials bewertet. Das Schadenspotenzial eines Prozesses ergibt sich aus der zu erwartenden Schadenshöhe pro Zeiteinheit, die sich aus mangelnder Verfügbarkeit oder schlechter Ergebnisqualität ergibt. Als Schaden wird dabei der unmittelbare finanzielle Verlust durch den Ausfall eines Prozesses verstanden, aber auch zusätzliche finanzielle Aufwendungen, die zur Aufrechterhaltung eines beeinträchtigten Prozesses notwendig sind. Das Schadenspotenzial wird vom jeweiligen Geschäftsprozessverantwortlichen festgelegt.
Ein Prozess wird als Kernprozess bezeichnet, wenn sein Schadenspotenzial so hoch ist, dass sein Ausfall oder eine wesentliche Beeinträchtigung kurz- oder mittelfristig zur Bestandsgefährdung des Unternehmens führen kann. Wenn ein IT-Risikomanagement lediglich die Anforderungen des Gesetzes für Kontrolle und Transparenz im Unternehmensbereich (KonTraG) erfüllen soll, kann es genügen, nur Kernprozesse zu betrachten.
Den Prozessen werden anschließend die jeweils unterstützenden Anwendungen einschließlich deren Unterstützungsgrad und einer Verfügbarkeitsanforderung zugeordnet sowie Prozessschnittstellen identifiziert. Der Unterstützungsgrad kann dabei wie folgt definiert werden:
Als Prozessschnittstellen werden der Ein- und Ausgang eines Prozesses sowie Übergänge zwischen Anwendungen verstanden. Prozessschnittstellen sind in der Regel (aber nicht notwendigerweise) IT-unterstützt. Für jede Prozessschnittstelle sollte man daher, falls erforderlich, das unterstützende IT-System erfassen (z. B. LAN, WAN, DFÜ-Verbindung, E-Mail, Telefon, Fax, Dateisystem, Datenbank usw.).
Schließlich werden die physischen Komponenten erfasst, die zum Betrieb der jeweiligen Anwendung oder Prozessschnittstelle notwendig sind: Arbeitsplatzrechner, Server, Host, Netzwerkkomponente, Automat, Verkabelung, TK-Anlage, Gebäude, Drucker/Plotter, Datenträger, tragbare Rechner, Fax-Gerät, Telefon usw.
![[Bild 2]](6-2.jpg)
Bild 2: Systemanalyse im IT-Risikomanagement
Insgesamt ergibt sich eine so genannte "Top-Down" Systemanalyse (vgl. Bild 2). Darüber hinaus ist es hilfreich für alle Anwendungen, Prozessschnittstellen und Komponenten
idealerweise unter Verwendung einer geeigneten DV-Anwendung zu erfassen. Dadurch werden bereits häufig anzutreffende Lücken im IT-Risikomanagement, die durch fehlende Verantwortlichkeiten und Dokumentation entstehen, geschlossen.
Im Anschluss an die Systemanalyse werden IT-Risiken identifiziert und bewertet. Auf jeder Ebene (Prozess, Anwendung, Schnittstelle, Komponente) sind Bedrohungsszenarien zu erarbeiten, die eine präzise und nachvollziehbare Beschreibung möglicher Angriffe oder Sicherheitsereignisse und ihrer Durchführbarkeit abgeben. Als Grundlage für die Ermittlung der Bedrohungen und Schwachstellen dient eine schnittstellenorientierte Analyse der untersuchten Objekte sowie der Informationsflüsse. Die Bedrohungsanalyse weist nach, welche Bedrohungen möglich sind und wie sie eintreten können. Die infrage kommenden Gefährdungen können beispielsweise dem Grundschutzhandbuch des Bundesamts für Sicherheit in der Informationstechnik entnommen werden (www.bsi.bund.de/gshb/).
Eine so genannte Business Impact Analysis stellt fest, inwiefern die ermittelten Bedrohungen die Erreichung der definierten Geschäfts- und Sicherheitsziele gefährden. Falls möglich wird die Stärke der Auswirkungen quantifiziert; dies ist jedoch nur machbar, wenn sowohl die Eintrittswahrscheinlichkeit eines Ereignisses als auch eine Schadenshöhe bestimmbar sind. Hierdurch wird ein Handlungsbedarf zur Risikobewältigung definiert und mit Prioritäten belegt. Objektivierung, Kumulation und Vergleichbarkeit von Risiken sind dann qualitativ (über Restrisiko) und/oder quantitativ (über das Produkt aus Eintrittswahrscheinlichkeit und Schadenshöhe) möglich.
Bei jeder Zuordnung einer Anwendung oder Prozessschnittstelle zu einem Prozess ist eine Verfügbarkeitsanforderung des Prozessverantwortlichen vorgegeben. Sie bestimmt auch die zu fordernden Verfügbarkeiten der darunter liegenden IT-Komponenten. Falls die Anwendung, Prozessschnittstelle oder IT-Komponente fremdbetrieben ist, muss die Verfügbarkeit über ein geeignetes Service Level Agreement mit dem Betreiber sichergestellt werden. Die Verfügbarkeit ist definiert als der Anteil der Dauer eines fehlerfreien Betriebs bezogen auf die gesamte Betriebszeit; z. B. bedeutet eine Verfügbarkeit von 99 % maximal drei Stunden monatliche Ausfallzeit bei täglichem Betrieb von 8 bis 18 Uhr. Das Risiko mangelnder Verfügbarkeit wird dann externalisiert und eine Bedrohungsanalyse ist im Detail nicht erforderlich. Bei Eigenbetrieb sind die Risiken mangelnder Verfügbarkeit über eine Risikomatrix zu bestimmen (vgl. Tabelle 1). Sie bestimmt systematisch entsprechend der fünf bekannten Bedrohungsarten alle Gefährdungen, die die Verfügbarkeit beeinträchtigen können.
| Höhere Gewalt | Organisatorische Mängel | Menschliche Fehlhandlungen | Technisches Versagen | Vorsätzliche Handlungen |
|---|---|---|---|---|
| Blitzschlag | Fehlende Regelungen | Fahrlässige Zerstörung | Defekte Datenträger | Diebstahl |
| Feuer | Unzureichende Regelungen | Fehlbedienung | Ausfall der Stromversorgung | Sabotage |
| Wasser | Personalausfall |
Tabelle 1: Risikomatrix für mangelnde Verfügbarkeit
Nach der Zusammenstellung der Risikomatrix für mangelnde Verfügbarkeit werden die einzelnen Gefährdungen über das Produkt aus Eintrittswahrscheinlichkeit und Schadenshöhe quantifiziert und daraufhin priorisiert. Dabei sollte man zur zuverlässigeren Einschätzung auf Vergangenheitsdaten, beispielsweise die Häufigkeit von Ausfällen, zurückgreifen.
Die Zuordnung von Informationsklassen zu einer Anwendung oder Prozessschnittstelle bestimmt den Schutzbedarf für Informationssicherheit. Falls die Ressource fremdbetrieben ist, schreibt man die Vertraulichkeit und den Integritätsschutz von Informationen in einem Service Level Agreement oder Non-Disclosure Agreement fest. Bei Eigenbetrieb sind die Risiken mangelnder Vertraulichkeit oder Integrität über eine Risikomatrix zu bestimmen (vgl. Tabelle 2).
| Höhere Gewalt | Organisatorische Mängel | Menschliche Fehlhandlung | Technisches Versagen | Vorsätzliche Handlungen | |
|---|---|---|---|---|---|
| Vertraulichkeit | entfällt | Fehlende Klassifizierung | Unautorisierte Weitergabe | Softwarefehler | Spionage |
| Integrität | entfällt | Unkoordinierte Rechtevergabe | Fehlbedienung | Alterung von Datenträgern | Sabotage |
Tabelle 2: Risikomatrix für mangelnde Vertraulichkeit und Integrität
Da eine Quantifizierung von Risiken bezüglich der Informationssicherheit in der Regel nicht möglich ist, bewertet und priorisiert man diese Gefährungen qualitativ-deskriptiv anhand des möglichen Schadens durch ein Sicherheitsereignis.
Für die Vielzahl von möglichen technischen und organisatorischen Maßnahmen können hier nur einige Beispiele angegeben werden. Technische Maßnahmen können etwa sein:
Organisatorische Maßnahmen können sein (sind aber nicht beschränkt auf):
Die Entscheidung über die tatsächlich umzusetzenden Maßnahmen zur Risikominderung wird vom Lenkungsausschuss des Unternehmens getroffen (in kleineren Unternehmen direkt von der Geschäftsleitung). Gleichzeitig ist mit dieser Entscheidung die Akzeptanz des Restrisikos verbunden, welches auch durch die möglichen aber nicht umgesetzten Maßnahmen bestimmt wird. Das Restrisiko sollte stets schriftlich dokumentiert und die Kenntnisnahme von der Geschäftsführung bestätigt werden.
Die Umsetzung der technischen und organisatorischen Maßnahmen sollte projektorientiert erfolgen. Demnach besitzt jede umzusetzende Maßnahme
Aufgrund der Vielzahl von Einzelmaßnahmen, deren jeweiliger Aufwand meist sehr gering ist, besteht für den IT-Sicherheitsbeauftragten die Gefahr den Überblick zu verlieren. Daher empfiehlt es sich auch hier auf geeignete DV-Anwendung zur Unterstüztung des Projektmanagements zurückzugreifen.
Ein Bestandteil der Risikokontrolle ist die regelmäßige Auditierung und Überprüfung übergreifender Konzepte, Anwendungen, Prozessschnittstellen und IT-Komponenten. Die Risikokontrolle sollte im Rahmen eines Auditierungsplanes geregelt sein. Die Auditierung kann aber auch ereignisabhängig vorgenommen werden
Das Ergebnis der Auditierung ist ein Gutachten, welches den Ist-Zustand des Auditierungsobjektes beschreibt und gegebenenfalls Korrekturen oder Ergänzungen fordert.
Um Schäden durch das Eintreten von Sicherheitsereignissen oder den Ausfall von Komponenten zu vermeiden oder zumindest gering zu halten, kann ein geeignetes Frühwarnsystem zur Prognose und Erkennung von Sicherheitsereignissen oder unerwünschten Tendenzen implementiert werden. Es benötigt zum einem geeignete Indikatoren, die an repräsentativen Stellen der IT-Landschaft den aktuellen Zustand aufnehmen, und zum anderen ein Meldesystem, das die Werte der Indikatoren aufnimmt, regelbasiert auswertet und bei Überschreiten eines Schwellwertes eine Meldung produziert. Geeignete Indikatoren zur Früherkennung können beispielsweise Systemausfälle, Störungen, Problem-Reports, Sicherheitsereignisse und Pressemeldungen über Sicherheitslücken sein.
Das von KonTraG vorgeschriebene Überwachungssystem zur Früherkennung bestandsgefährdender Entwicklungen ist in vielen Unternehmen bisher nur rudimentär implementiert. Ein praxisrelevantes Modell eines strategischen Frühwarnsystems sollte in der Lage sein:
Der Teilnehmerkreis im IT-Risikomanagement ist in der Regel immer das gesamte Unternehmen, da jede für das Unternehmen handelnde Person mit Informationen umgeht und damit jede Handlung mehr oder weniger hohe Gefährdungen und Risiken für die Informationen mit sich bringt. Praktikabel ist die Bildung eines Lenkungsausschusses für das IT-Risikomanagement, der sich aus Geschäftsleitung, IT-Sicherheitsbeauftragtem, Personalvertretung, Datenschutzbeauftragtem, IT-Leitung und einigen Anwendern zusammensetzen sollte. Der Lenkungsausschuss beschließt Maßnahmen zur Risikominderung und ist das Kontrollgremium des IT-Sicherheitsbeauftragten.
Die Kostenproblematik beim IT-Risikomanagement hat viele Unternehmen in den letzten Jahren abgehalten, umfassende Maßnahmen zur Reduktion von IT-Risiken zu treffen. Die hat unter anderem zwei wesentliche Gründe: Einerseits führte die "Jahr 2000"-Problematik zu einem spezifischen Risiko der Betriebssicherheit mit einem definierten und nicht diskutierbaren Termin zur Validierung der getroffenen Vorkehrungen. Dadurch war das IT-Budget vieler Unternehmen bereits erschöpft.
Zum anderen impliziert das IT-Risikomanagement in der Regel keine neue oder zusätzliche Funktionalität im Unternehmen. Kosten für die Betriebssicherheit lassen sich nur schwer mit einem "Return of Investment" verrechnen. Eine Ersparnis durch Maßnahmen zur Verbesserung der Informationssicherheit zu errechnen, ist praktisch unmöglich.
Es gehört daher zum Grundverständnis des IT-Risikomanagements, dass mit diesbezüglichen Maßnahmen die Qualität der unternehmerischen Tätigkeit erhöht wird, jedoch nicht notwendigerweise höhere Erträge im operativen Geschäft anfallen. Demzufolge lautet das betriebswirtschaftliche Ziel, mit möglichst geringen Kosten ein für das Unternehmen angemessenes Sicherheitsniveau zu erreichen.
![[Bild 3]](6-3.jpg)
Bild 3: Kosten vs. Sicherheit im IT-Risikomanagement
Dabei lässt sich schon mit relativ wenig Aufwand eine deutliche Anhebung des Sicherheitsniveaus und somit eine Risikominderung erreichen. Oft sind es nur technische oder organisatorische Kleinigkeiten, die eine Systemkonfiguration absichern oder eine Lücke in einem Geschäftsprozess füllen. 100%-ige Sicherheit ist jedoch mit endlich hohem Aufwand nicht zu erreichen. Jedes Geschäft, das auf Ertrag ausgelegt ist, birgt ein gewisses Risiko. Entscheidend ist daher nicht, das Risiko auf Null zu senken, sondern unternehmerisch damit umzugehen.
In jedem Fall sollte die Kosten-Nutzen-Analyse keine Variable "Sicherheitsniveau" enthalten. Das Sicherheitsniveau ist eine Größe, die man stets unabhängig von Kostenaspekten festlegen sollte, um anschließend das festgeschriebene Niveau kostenoptimal umzusetzen.
Modernes IT-Risikomanagement ist als aktiv einzusetzendes Instrumentarium zur Unternehmenssteuerung zu verstehen. Nur durch aktives Management der IT-Risiken ist ein Unternehmen langfristig in der Lage, seinen Wert zu erhalten und zu steigern.
Dazu ist eine integrierte Herangehensweise erforderlich, mit deren Hilfe die verschiedenen Bedrohungen und die resultierenden Risiken über sämtliche Unternehmensbereiche, Verantwortlichkeiten und Aggregationsebenen hinweg zusammengeführt werden können. Dies gilt unabhängig von Zugehörigkeit des Unternehmens zur einer Branche und seiner Größe. IT-Risikomanagement sollte keine "lästige Pflichtübung" sein, es ist als wirkungsvolles wenn nicht gar notwendiges Mittel zur Erhaltung und Verbesserung der Wettbewerbsfähigkeit eines Unternehmens anzusehen.
Wesentliche Erfolgsfaktoren eines wirkungsvollen IT-Risikomanagements sind die Festschreibung des IT-Risikomanagements als Unternehmensziel und die Unterstützung durch eine geeignete DV-Anwendung, Bewusstseinsbildung bei allen Mitarbeitern sowie die Schaffung einer technischen und organisatorischen Infrastruktur. Eine streng methodische Vorgehensweise hilft, die unterschiedlichen Interessen verschiedener Fachabteilungen zu konsolidieren. Letztlich bestimmen die Motivation und das Zusammenspiel der Mitarbeiter die Qualität des IT-Risikomanagements und damit den Erfolg des Unternehmens.
Dr. Gerald Spiegel ist Senior Architect IT-Security & IT Risk Management bei der SerCon GmbH, Eschborn.
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 4/2001, Seite 6
