Risikomanagement in einer SOA-Welt

Der Einsatz moderner Technologien wie SOA führt immer wieder zu kontroversen und detailbelasteten Diskussio-nen. Trotz aller Versuche, Risiken möglichst objektiv darzu-stellen, entbrennen immer wieder regelrechte Glaubens-kriege zwischen der Fach- und der IT-Seite. Nicht selten führen diese zu einer Blockade von neuen Technologien beziehungsweise stehen ihrer geordneten Einführung im Wege, ohne sie jedoch verhindern zu können. Kristallisa-tionspunkt des Streites sind regelmäßig die empfohlenen organisatorischen und technischen Maßnahmen sowie ein fehlendes gemeinsames Verständnis der Ziele. Sehr häufig fehlt der übergeordnete strategische und orga-nisatorische Rahmen, um für die fachlichen Aspekte der Geschäftsseite und die fachlichen Aspekte der IT-Seite gleichermaßen belastbare Entscheidungen zu erhalten.

PEP PEP PEP

Policies Policies Policies

PAP

PEP PEP PEP

Policies

PAP

PEP PEP PEP

PAP

Policies Policies Policies

Policies

Gerade im Kontext SOA wird dies verstärkt deutlich. SOA ist geeignet, Geschäftsprozesse in einem bisher schwer erreichbaren Ausmaß mit der IT verwachsen zu lassen.

Ein gemeinsames Verständnis der Geschäftsprozesse ist einfacher erreichbar als in bisherigen IT-Lösungsansätzen, so ist ein effizienterer Einsatz der IT möglich. Die IT wan-delt sich von einem reinen Stützprozess zum integrierten Bestandteil des Geschäftsprozesses. Gegenseitige Abhän-gigkeiten nehmen stark zu. Um eine effizientere Nutzung der IT im Rahmen von “Business Alignment” zu erreichen,

ist dies sogar explizites Ziel von SOA. Als zwingende Folge ist auch das klassische Risikomanagement für die Geschäftsprozesse mit dem IT-Sicherheitsmanagement enger zu verzahnen. Bleibt dies aus, sind Missverständ-nisse und unnötige Reibereien zwischen den Trägern des fachlichen Geschäfts und der Informationstechnologie unvermeidbar. Schlimmer noch, tatsächlich existierende Risiken werden falsch oder gar nicht bewertet, potenzielle Chancen werden dagegen verpasst.

■ Financial Risk Management

■ Compliance Management

■ Industrial Safety Regulations

■ Data Protection Law

■ Fraud Management

■ … IT Application Security

IT Infrastructure Security

Information Security Business Continuity Desaster Recovery+

IT Continuity Desaster Recovery+ Risk Management

Schutzbedarf

Um die aus SOA erwachsenden Risiken bewerten zu können, muss allen Beteiligten bekannt sein, vor wel-chen „Gefahren“ man sich eigentlich schützen will. Diese scheinbar einfache Frage nach dem Schutzbedarf ist eine der am schwierigsten zu beantwortenden Fragen über-haupt. Der Schutzbedarf ergibt sich letzten Endes aus den einem Prozess zugrunde liegenden Informationen. Hier bedarf es einer intensiven Abstimmung von Fach- und IT-Seite unter Koordination des Risikomanagements.

Bedrohungen

Es ist wichtig zu verstehen, dass SOA nicht eine fixierte Technologie ist, sondern vielmehr eine natürliche, evolu-tionäre Sichtweise auf Software-Architektur „verkörpert“.

Dementsprechend liegen die neuen Bedrohungen nicht in völlig neuen technologischen Herausforderungen,

sondern darin, in einer veränderten Kultur Software zu erstellen und diese Software in diese neue Kultur zu integrieren. Diese neue Kultur muss in den beteiligten Köpfen umgesetzt werden. Um es zu wiederholen: Neu ist an dieser Stelle die geforderte stärkere Einbeziehung der geschäftsfachlichen Seite. Die Bedrohungen durch neue Protokolle und Technologien bedürfen zwar ebenfalls einer gründlichen Würdigung, sie sind aber in großen Bereichen durch seit Jahren verfügbare Checklisten behandelbar.

Risiken

Risiken ergeben sich aus den möglichen Bedrohungen, dem Schadensmaß und dessen Eintrittswahrscheinlich-keit. Genauso wenig wie das dogmatische Ausblenden der “nur” stützenden IT im fachlichen Risikomanage-ment des Unternehmens die Lösung ist, ist dass Auf-zählen von technologischen und organisatorischen

Abbildung 49: Risk Management

Verwundbarkeiten seitens des IT-Security-Managements die richtige Antwort auf Bedrohungen. Von dem Umgang mit Risiken handelt das Risikomanagement. Dieses muss die entstehenden Risiken ganzheitlich und interdiszipli-när bewerten und Vorgaben machen, die auch für die IT gelten und umsetzbar sind.

Für die an die Geschäftsprozesse anwachsende Infor-mationstechnologie bedeutet dies eine Ausweitung der einzubeziehenden Schadensdimensionen bei ihren Sicherheitsanalysen. Die zu betrachtenden Risiken werden vielfältiger in ihrer Art, teilweise sind sie losgelöst von der zugrunde liegenden Technologie und Organisation.

Ein einfaches Formulieren der Sicherheitsanforderungen in Form eines Service-Levels für die Verfügbarkeit durch die Geschäftsseite reicht häufig nicht aus.

Wie mit diesen Risiken umgegangen wird, hängt maß-geblich davon ab, ob die tatsächlich relevanten Scha-densaspekte erkannt werden und ihre Auswirkungen in Form der möglichen Verlusthöhe und der zu erwartenden Verlusthäufigkeit richtig eingeschätzt werden. Hierzu müssen Fach- und IT-Experten interdisziplinär gemein-same Ergebnisse finden.

Abbildung 50: Handlungsmöglichkeiten zum Umgang mit Risiken

Mögliche zu berücksichtigende Schäden lassen sich dabei grob in vier Gruppen fassen:

„ direkter monetärer Schaden (z. B. Systemausfälle, Umsatzeinbußen, Vertragsstrafen)

„ indirekter monetärer Schaden (z. B. Verlust an Kun-den, Rufschädigung, Schädigung der Allgemeinheit, Schadensersatzklagen, notwendige PR-Maßnahmen, kostenintensive nachträgliche Korrektur)

„ Verstoß gegen gesetzliche und regulative Auflagen (z. B. strafrechtliche Verfolgung oder Ausschluss aus Märkten, Kosten für die juristische Aufbereitung von Verstößen)

„ Schäden an Personen (z. B. durch fehlerhafte Produkte oder Arbeitsabläufe)

Die zu berücksichtigenden Risiken werden in der klassi-schen Organisation des Risikomanagements häufig von spezialisierten Einheiten mit wenig Kontakt untereinan-der betrachtet. Das Gewicht untereinan-der Informationstechnologie und damit die Abhängigkeit der Geschäftsprozesse von der IT wachsen jedoch rasant; die daraus bedingte enge Verzahnung von Fach- und IT-Seite ist häufig noch nicht ideal bzw. scheitert vielfach am Fehlen einer gemeinsa-men Sprache bzw. Metrik zur Bewertung von Schäden und Risiken.

Das IT Continuity Management zeigt einen brauchbaren Weg, den Prozessgedanken im Risikomanagement der IT zu stärken. Wichtig ist hierbei, tatsächlich den zu schüt-zenden Prozess zu betrachten und nicht ausschließlich in technologischen Lösungen zur Erhöhung der Redundanz wie zum Beispiel Raid-Systemen oder Server-Clustern zu denken.

Versichern

Reduzieren Vermeiden

Akzeptieren

Verlusthäufigkeit

Verlusthöhe

niedrig hoch

niedrig hoch

Ideen für ein modernes Risikomanagement in einer SOA-Welt:

„ Eine moderne Sicherheitsorganisation orientiert sich an den Geschäftsprozessen der Unternehmung, der sie dienen soll. Ändern sich Prozesse, so muss die Organisation diese Veränderungen angemes-sen reflektieren. Die Kommunikation zwischen den beteiligten Sicherheitsorganisationen der Fach- und IT-Seite muss gefordert und gefördert werden.

„ SOA verlangt die Betonung des Prozessgedankens in der IT-Sicherheit. Das Denken in klassischen Katego-rien der IT-Infrastruktur und IT-Organisation deckt nur noch einen Teil der Anforderungen ab. SOA basiert auf Prinzipien, die zu einer transparenteren und standardisierten Sicherheitslage führen. Die Umset-zung gelingt am besten durch den Ansatz „Sicherheit als ein Service“ innerhalb einer SOA. Der Service-Gedanken von SOA sollte daher konsequent auf Ihre IT-Sicherheitsorganisation überragen werden.

„ Alle Formen von möglichen Schäden müssen in einer Sicherheitsanalyse berücksichtigt werden. Alle Diszi-plinen einer Organisation sollten am Sicherheitsteam beteiligt werden. Hieraus ergibt sich ein stark wach-sender Bedarf der Kommunikationsfähigkeit auf der Fach- und IT-Seite.

„ Bei Bedarf sollte auch auf Expertise von extern zurück-gegriffen werden. Die zwangsläufig „subjektiven“

Ergebnisse eines externen Sicherheitsberaters müssen durch das eigene Risikomanagement gewichtet wer-den. Diese für ein Unternehmen spezifische Gewich-tung muss auf einer schriftlich fixierten Strategie, Vorgehensweise und zugehörigen Metriken basieren.

Fehlt dieser Rahmen, werden Strategie und Vorge-hensweise zuerst erstellt!

„ Eine Prozessorientierung in der Sicherheit lässt sich vergleichsweise einfach über das Thema Business Continuity und Desaster Recovery angehen. Welche Verbindung gibt es zwischen Business Continuity, Information Security und Risikomanagement in einer Organisation? Woran merkt man, dass eine ausrei-chende Abstimmung erfolgt?

„ Technisch/organisatorische Richtlinien sind sicher ein Muss, sie sollten aber nicht das alleinige Verständ-nis einer IT-SicherheitsorgaVerständ-nisation ausmachen. Für einen ersten schnellen Check der Ausrichtung einer IT-Sicherheitsorganisation könnte man beispielsweise deren wesentliche Publikationen betrachten. Findet sich hier neben technisch/organisatorischen Check-listen auch der Gedanke eines Security Service für das Geschäft einer Unternehmung? Gibt es zielgruppen-bezogene Dokumente für die Fachseite? Wie wird der Service-Gedanke ausgelegt? Wird er gelebt?

„ Nach welchen Kriterien, Metriken und nach welcher Methodik werden Maßnahmen zum Umgang mit Risiken innerhalb der IT-Sicherheitsorganisation bewertet. Um dies herauszufinden, sollte mit allen

“Teilen” einer Sicherheits-Organisation geredet wer-den. Werden zumindest vergleichbare Kriterien, Met-riken sowie ein vergleichbare Methodik eingesetzt?

Kann man die Arbeitsgrundlage vereinheitlichen?

„ Versteht sich eine Sicherheitsorganisation eher als Revision, die Vorgaben macht und gegen diese prüft, oder ist sie service-orientiert, eher beratend und unterstützend unterwegs?

Prevention Reaction Recovery

IT Security Management IT Crisis Management IT Disaster Recovery IT Continuity Planning Desaster IT Continuity Service IT Continuity Service IT Continuity Management

Time

Abbildung 51: IT Continuity Management