IT-Security Budget
Dieser "Brückenschlag zum internen Kunden" erfordert im Zweifel auch einen kleinen Paradigmenwechsel. In dem Sinne, dass die IT(-Security) ihre Leistungen den internen Kunden "verkauft". Eine Entwicklung, die auch durch die mittlerweile etablierten Standards zu IT-Prozessen (z.B. ITIL) entsprechend gestützt und eingefordert wird. Interne IT-Kundenmanager beraten die Fachabteilungen und sorgen dafür, dass die Anforderungen der fachlichen Kunden an die IT systematisch kanalisiert und dokumentiert werden. Diese interne Dienstleistungsmentalität, im Sinn der internen bedarfsorientierten Beratung und Betreuung des Kunden, sollte auch durch die IT-Security erfolgen. Denn dies schafft bedarfsorientierte Budgets, sensibilisiert die Kunden für IT-Sicherheit und sorgt zudem für besseres Verständnis und eine bessere Akzeptanz der IT(-Security).
Folgendes praxiserprobtes und unter anderem auch durch Standards und Normen zur IT-Sicherheit definierte Vorgehen ist hierfür von Nöten (ein pragmatischer Überblick):
a.) Für den laufenden Betrieb von IT-Security
- Bei Projekten oder Planungen zur Anschaffung für neue Anwendungen bzw. Software müssen Sie sicherstellen, dass die IT-Security bereits im Planungsstadium zwingend einbezogen wird
Hier liegt der Hebel, um bereits im Planungsstadium bedarfsgerechte Budgets für IT-Sicherheit zu implementieren. Es gilt u.a. die Fragestellung, wie wichtig die Sicherheit im Bezug auf die neue Anwendung aus fachlicher Sicht ist (im Bezug auf Berechtigungen, Integrität der Daten etc.). Hierbei wird mit der Fachlichkeit ermittelt, welche wie schutzbedürftigen Daten in dem jeweiligen Prozess mit der Anwendung ver- oder bearbeitet werden. Hieraus leitet sich dann u.a. der Grad an IT-Sicherheit ab, der bei dieser neuen Anwendung (und auch bei den diese Anwendung stützenden weiteren IT-Komponenten) angelegt werden muss, um im Sinne der Fachlichkeit ausreichende IT-Sicherheit zu gewährleisten. Kombiniert werden muss eine solche Erhebung (Schutzbedarfsanalyse, z.B. in Anlehnung an BSI - Bundesanstalt für Sicherheit in der Informationstechnik) auch mit der Fragestellung, was passiert in dem Geschäftsprozess konkret, wenn diese Anwendung ausfällt (<1 Stunde...). Neben der Tatsache, dass diese Informationen auch für die Auslegung der Verfügbarkeit und den Notfall wichtig ist, wird hierbei die Fachlichkeit nachhaltig dafür sensibilisiert, wie ggf. elementar eine IT-Anwendung für das Funktionieren des Geschäftsprozesses ist. In einem nächsten Step leiten Sie argumentativ ab, welchen möglichen Sicherheitsrisiken die neue Anwendung ggf. ausgesetzt ist. Und Sie zeigen dann auf, dass und ggf. welche entsprechenden absichernden Maßnahmen hier aus Sicht der IT-Security zu installieren sind. Sie müssen hierbei ein Stückweit auch "interner Verkäufer" der IT-Security sein. Sie müssen Ihrem fachlichen Ansprechpartner verdeutlichen und ihn darüber aufklären, was passieren kann, wenn ggf. auch Sicherheits-Maßnahmen in unterschiedlichen Qualitäts-Abstufungen definiert werden.
Ein Beispiel hierzu wäre, dass bei einer servicebasierten Web-Anwendung mit der wichtige Kundendaten bearbeitet werden und z.B. über Web-Services Daten mit externen Partnern ausgetauscht werden, zwingend Codeanalysen und Penetrationstest durchgeführt werden sollten. Ansonsten riskiert der fachlich für den Prozess verantwortliche, dass z.B. im Falle einer Korrumption von Partner- oder Kundendaten, aufgrund nicht durchgeführter Absicherungsmaßnehmen, immens hohe wirtschaftliche und Imageschäden eintreten können. Dies sollte natürlich nicht nur besprochen, sondern auch entsprechende dokumentiert und protokolliert werden. Hierzu ist eine entsprechende systematische Vorbereitung, z.B. in Form von Gesprächen oder Kurzworkshops, und ein ziegerichtetes Vorgehen wichtig.
Dieses Vorgehen sorgt nicht nur für ein "Verstehen" und ggf. "Umdenken" auf fachlicher Ebene, sondern sensibilisiert auch nachhaltig den internen Kunden für das Thema IT-Security und die IT im allgemeinen. Zudem stellt dies auch eine nötige Absicherung der IT(-Security) in dem Sinne dar, als das der fachliche Kunde darüber aufgeklärt worden ist, welche Möglichkeiten er hat und welche Konsequenzen er ggf. trägt, wenn er Variante A oder B wählt. Und Sie definieren den Bedarf an IT-Sicherheit über und mit dem fachlichen Kunden. Die Anforderung für das entsprechende Budget für IT-Security muss dann auch entsprechend vom Kunden, ggf. über ein Projekt mit eingeplant und angefordert werden.
Die oben beschriebenen Aspekte können und müssen Sie natürlich in Abhängigkeit von der Größe und Struktur Ihres Unternehmens ganz individuell ausgestalten. Dieser Prozess wird ggf. in einer mehr hierarchischen Organisationsstruktur in einem großen Unternehmen sicher etwas anders aussehen, als in einem mittelständischen Unternehmen mit flacheren Hierarchien. In dem einen Fall wird es ggf. ganz klare Richt- und Leitlinien geben, wie die IT-Security und auch entsprechende Sicherheits-Maßnahmen initiiert werden müssen, in dem anderen Fall muss die IT-Security ggf. mehr der Verkäufer und Berater der IT sein, der den Kunden (die Fachlichkeit) berät, aufklärt und sensibilisiert. Optimal ist hierbei sicher eine Mischung aus beidem. Auch wenn es entsprechende Richtlinien gibt, so sollten Sie doch auch diese IT-Leistung Ihrem internen Kunden gegenüber verargumentieren und gemeinsam abstimmen. - Das oben beschrieben gilt auch z.B. für den Fall, dass neue fachliche Geschäftsprozesse initiiert werden oder auch fachliche oder auch IT-Prozesse ausgelagert werden
Sie müssen als interner Berater der fachlichen Kunden deutlich machen, dass die (IT-)Risiken bei einer Auslagerung von Prozessen nicht auf den externen Partner übertragen werden können. Wenn der externe (Sourcing-)Partner in seinen Anwendungen und Systemen keine ausreichende Sicherheit besitzt, dann kann dies nachhaltige Folgen für die fachlichen Geschäftsprozesse und damit für das Business haben. Es ist hierbei extrem wichtig, dass Sie zusammen mit Ihrem fachlichen Ansprechpartner hier den auszulagernden Prozess, wie bereits schon oben dargestellt, genau betrachten und daraus die Anforderungen an die IT-Sicherheit des externen Partners definieren.
Bei grösseren Unternehmen die überwachenden Organen unterliegen (z.B. die Banken und Versicherungen der BaFin), gibt es eine Verpflichtung dies zu tun, sich hiervon zu vergewissern und dies auch zu kontrollieren! Im Ansatz sollte dieses Vorgehen aber auch für alle anderen Unternehmen, die relevante Prozesse auslagern, schon aus dem Eigeninteresse heraus gelten.
b.) Für eine grundsätzliche Bestandsaufnahme über alle Geschäftsprozesse hinweg
Das, was unter Punkt a.) pragmatisch für die laufenden und neuen Aktivitäten beschrieben wurde, muss auch für alle bestehenden Geschäftsprozesse erfolgen. Sie müssen, natürlich abhängig von den zur Verfügung stehenden Kapazitäten, ggf. auch sukzessive die einzelnen Geschäftsprozesse aus Sicht der IT-Security "unter die Lupe" nehmen.
Sinnvoll ist es in jedem Fall, die fachlichen Prozesse nach deren Kritikalität abzuarbeiten. Wie Sie die kritischen Geschäftsprozesse erheben und wie Sie das Vorgehen verargumentieren und vorbereiten können, dazu in einem kommenden Artikel mehr.
Wichtige Praxis-Anmerkung zu Standards und Normen zur Informationssicherheit:
Wenn man sich die Standards zur IT-Sicherheit (ISO oder auch BSI-Grundschutz) ansieht, dann fragt man sich natürlich als erstes wie man dies in der Gänze umsetzen und womit man im Zweifel anfangen soll. Standards, wie bspw. der BSI-Grundschutz, fordern u.a. eine quasi IT-Inventarisierung und eine Darstellung der Abhängigkeiten der IT-Komponenten voneinander ein. In der Praxis ergeben sich hierbei natürlich sehr viele Fragen zur Umsetzung.
Große Unternehmen haben die Möglichkeit, ggf. auch durch externe Unterstützung, solch ein Thema ganzheitlich anzugehen und z.B. in Form eines Projektes umzusetzen. Dort wo diese Möglichkeit nicht gegeben ist, sollte man ganz einfach pragmatisch, aber dennoch systematisch und sukzessive im Sinne von geltenden IT-Sicherheits-Standards beginnen.
Wie Sie ein solches Vorgehen zielgerichtet umsetzen können (gestützt durch Checklisten, Tools etc.) dazu erfahren Sie in Kürze in einem Beitrag.
Autor: Michael Scholz, August 2009
| < Zurück |
|---|




