![[Foto: SAP]](06-5-006-0.jpg)
SAP hat als schnell wachsende globale Unternehmensgruppe hohe Anforderungen an Prozesse mit steuerndem Charakter, zu denen auch das Sicherheits-Management zählt: Sie müssen sprunghaftem Wachstum und schwindenden Informationsgrenzen im Umfeld eines globalen Konzerns gerecht werden. Heute stellen rund 75 000 Rechner und 600 Mio. E-Mails pro Jahr den IT-Bereich vor Herausforderungen, in Support und Consulting werden Kundendaten höchster Sensitivität gehandhabt, die Softwareentwicklung als Kernbereich arbeitet mit der Zukunft der rund 37 000 Mitarbeiter.
Gleichzeitig steigt die Zahl der Outsourcing-Partner und außerdem gibt es mehrere tausend Partner, die Leistungen für den Konzern oder seine Kunden anbieten.
Nicht zu vergessen sind dabei Herausforderungen, die durch die vielfach gelobte Unternehmenskultur entstehen: Offenheit, Schlichtheit, flache Hierarchien, hohe Eigenverantwortung und "Kommunikation ohne Grenzen" bilden den Rahmen, der das Unternehmen zum Erfolg geführt hat. Aus Sicht des Informationsschutzes gilt es, daraus resultierenden potenziellen Gefahren zu begegnen – und diese Kultur zu schützen und zu nutzen.
Beim Stichwort Sicherheits-Management geht es um Planung, Steuerung und Kontrolle aller sicherheitsrelevanten Belange. Kein Wunder, dass jede Unternehmenskultur seine Ausprägung maßgeblich beeinflusst. Bei SAP will das Sicherheits-Management nicht Aufpasser sein, sondern Ratgeber – nicht Zeigefinger hebender Mahner, sondern geschäftspolitisch versiert abwägender Sachverständiger.
Dazu gehört auch, hohe Eigenverantwortung in den Fachbereichen und Standorten zu belassen. Von zentraler Seite werden hingegen globale Definitionen und Kommunikationsrichtlinien vorgegeben. Außerdem werden von dort programmatische Impulse und Beratungsleistungen im Bedarfsfall erwartet und letztlich dienen zentrale Strukturen als finale Eskalationsstelle.
Richtungsweisende Impulse liefert das Security Steering Committee (SSC), das oberste Gremium in Sicherheitsfragen. Es definiert den übergeordneten Prozess zum Sicherheits-Management und ist Entscheidungsträger für die Festlegung aller grundlegenden Anforderungen, vor allem der Security Policy. Außerdem bewilligt und überwacht es Schlüsselprojekte.
Weit reichende Verantwortung übergab das SSC an den Chief Security Officer (CSO) und seine Abteilung Corporate Security. Der CSO ist für alle Sicherheitsbelange zuständig und berichtet direkt an den Vorstand. Gegenüber dem SSC fungiert er mit seinem Team als Berater, legt den aktuellen Sicherheitsstatus dar, schlägt Projekte vor und dient als primärer Kontakt bei Zwischenfällen und Krisen.
Daraus entsteht aus Sicht des Unternehmens eine umfassende organisierende und strategische Ausrichtung der Abteilung. Das wird auch in der Vision deutlich, die sie sich gab: "Bei SAP ist Sicherheit ein Bestandteil von allem, was wir tun." Der Leitspruch beschreibt die Aufgabe vollständig, enthält allerdings keine konkrete Handlungsanweisung. Sie kommt dazu, sieht man sich die nach innen gerichteten Ziel-Ansagen an:
Corporate Security ist hierzu der Treiber, allerdings nur als Teil eines Netzwerks interner Gruppen, die sich mit unterschiedlichen operativen Schwerpunkten der Sicherheit beschäftigen.
Die Aufgabe eines sich ausschließlich um Informationssicherheit kümmernden Chief Information Security Officer (CISO) ist zwar in die Rolle des CSO eingegliedert. Gleichwohl gibt es eine Abteilung innerhalb von SAP IT, die sich mit Qualitäts- und Sicherheitsbelangen beschäftigt – sie arbeitet eher operativ und taktisch. Ähnlich sieht die Verteilung zum Gebäudeschutz und zur physischen Sicherheit aus: In der Walldorfer Zentrale, dem immer noch größten Standort, gibt es zur Behandlung dieser Themen den Bereich "Security Engineering".
![[Illustration]](06-5-006-1.jpg)
Abbildung 1: Die SAP-Security-Organisation in vereinfachter Darstellung – das Bindeglied zwischen Strategie und Umsetzung liegt in mehreren global verteilten, virtuellen Teams.
Der Abgleich von Strategie und Bedarf, Anspruch und Umsetzung geschieht über mehrere virtuelle Teams (vgl. Abb. 1). Zwei seitens Corporate Security organisierte Gruppen behandeln globale Themen: Zunächst ist ein Gremium zu nennen, in das Vertreter aus allen Geschäftsbereichen entsandt werden. Es befindet beispielsweise über Änderungen der Security Policy und hat Mitspracherecht bei strategischen Entscheidungen. Monatliche Treffen stellen die wichtigste Basis zum Informationsaustausch zwischen den Geschäftsbereichen dar.
Orthogonal dazu ist eine dezentrale Struktur aus Vertretern der Standorte aufgebaut: In der Regel handelt es sich dabei um die lokal verantwortlichen Security Officer. Die Rolle wird an großen Standorten hauptamtlich, an kleineren von entsprechend ausgebildeten Mitarbeitern als Nebenaufgabe wahrgenommen. Die Aufgabe ist schnell erklärt und dennoch umfangreich: die Umsetzung der Security Policy am jeweiligen Standort sicherstellen.
Die Mitglieder der Gremien stimmen sich regelmäßig in regionalen und globalen Treffen ab. Sie verbleiben jedoch in ihren jeweiligen Berichtslinien – die Gremienarbeit geschieht als Teil der Zielvereinbarung. Diese Kombination aus direkter und "dotted line"-Verantwortung hat sich aus Sicht des Sicherheits-Managements bewährt. Sie verhindert, dass Strategien sich vom realen Bedarf "verabschieden" und fördert die operative Umsetzung. Ein gutes Beispiel für die erfolgreiche Zusammenarbeit aller Gruppen liefert das Stichwort Zertifizierungen: SAP IT ist gemäß ISO/IEC 27001:2005 zertifiziert.
Die Aufgabenfelder einzelner Gruppen sind über so genannte Engagement Models abgesteckt. Hier sind Verantwortlichkeiten und Berichtswege definiert und bei möglichen Überlappungen ist der jeweilige Fokus festgelegt. Regelmäßige Aktualisierungen der Modelle sorgen dafür, dass neue Aufgabenfelder eindeutig adressiert werden, und gewährleisten die systematische Zuordnung benötigter Fachkompetenz.
Engagement Models existieren auch zwischen Corporate Security und Governance-Funktionen wie dem Risikomanagement und der Innenrevision. Beispielsweise ist hier geregelt, dass interne Audits im Sicherheitsumfeld nicht seitens Corporate Security durchzuführen sind. Damit wird eine durchgehende Gewaltenteilung ermöglicht.
Das über Engagement Models initiierte Sicherstellen der führenden Fachkompetenz aller Beteiligten stellt den ersten Prozessteil zum Sicherheits-Management der SAP dar (siehe Abb. 2). Der nächste Schritt liegt in der Festlegung des Sicherheits- und Schutzbedarfs. Grundsätzlich erscheint es sinnvoll, über die gesamte Wertschöpfungskette des Unternehmens das gleiche Sicherheitsniveau zu fordern (nicht umsonst etabliert sich das Schlagwort von der "Supply Chain Security"). Organisatorisch muss man dabei zwischen konzerninternen Vorgaben und Richtlinien für externe Dienstleistungspartner unterscheiden.
![[Illustration]](06-5-006-2.jpg)
Abbildung 2: Der Security-Management-Prozess wurde vom höchsten für Sicherheit verantwortlichen Gremium definiert, dem Security Steering Committee (SSC). Teile des Prozesses veranwortet die strategisch ausgerichtete Abteilung Corporate Security.
Mit Blick nach innen erfolgte die Festlegung grundlegender Sicherheitsanforderungen in Form einer global einheitlichen Security Policy. Als Grundlage bei ihrer Erstellung dienten die üblichen Standards – Erweiterungen aufgrund der spezifischen SAP-Geschäftsfelder wurden mit Vertretern der Unternehmensbereiche besprochen.
Erwähnenswert ist, dass die eigentliche Security Policy nur ein kurzes Dokument darstellt, das generische und strategische Ziele der Unternehmens-Sicherheit beschreibt: Sie stellt die Spitze eines Regelwerks aus Sicherheitsstandards und lokal gültigen Verfahren dar, das einen deutlich größeren Tiefgang hat (siehe Abb. 3). Umgangssprachlich wird hingegen der gesamte Katalog als "Security Policy" bezeichnet.
![[Illustration]](06-5-006-3.jpg)
Abbildung 3: Die eigentliche Security Policy stellt nur die Spitze eines umfassenden Regelwerks dar, mit dem globale und lokale Sicherheitsanforderungen beschrieben werden und das auch umsetzende Maßnahmen definiert.
Im Laufe der Zeit wird so mancher "Sonderfall" an das Sicherheits-Management herangetragen mit der – in fast allen Fällen wirtschaftlich begründeten – Bitte, Teile der Security Policy außer Kraft zu setzen. Als Beispiel sei hier der pragmatisch getriebene Aufbau eines neuen Standorts genannt. SAP hat in solchen Fällen gute Erfahrungen mit Checklisten gesammelt, die dem lokal verantwortlichen Management an die Hand gegeben werden: Sie weisen auf Notwendigkeiten und Herausforderungen hin und können eine direkte Verknüpfung zum Risikomanagement herstellen. Den Aufwand zum Erstellen solcher Checklisten sollte man nicht unterschätzen. Andererseits stellen sie aber eine ausgezeichnete Chance dar, Business und Security miteinander ins Gespräch und auch in Einklang zu bringen. Vermutlich sind sie eine der wirksamsten Awareness-Maßnahmen, die man sich vorstellen kann.
So gut eine Security Policy innerhalb eines Unternehmens den Schutzbedarf auch zu definieren vermag – nach außen hat sie nur eingeschränkte Wirkung. In Zeiten neuer Outsourcing-Partner und immer tiefer verwobener Daten-Beziehungen müssen aber auch dort Spielregeln festgelegt werden. Idealerweise gehören sicherheitsrelevante Regeln in alle Partnerverträge, leider zeigt die Realität jedoch ein anderes Bild: Welcher Vertrag – zum Beispiel über Marketing-Kampagnen – regelt schon Anforderungen an die Verfügbarkeit der Viren-Scanner des Service-Providers? SAP löst diesen Anspruch durch Security Service Level Agreements (SSLAs). Sie werden als Vertragsanhang an alle Partner gegeben, die sensitive Daten handhaben.
Bei der Erstellung von SSLAs gilt es, besondere Aufmerksamkeit auf die Granularität der Anforderungen zu legen. Sie müssen für unterschiedlichste Partner Gültigkeit haben und ein ähnliches Sicherheitsniveau fordern, wie es intern im Unternehmen gewünscht wird. Zugleich dürfen die Anforderungen nicht so hoch sein, dass die eigentlichen Dienstleistungen sich unangemessen verteuern. Und das gesamte Regelwerk muss handhabbar bleiben. Das gilt nicht nur für die Sicherheitsorganisation, sondern auch für den Einkauf, der in der Regel erster Anlaufpunkt des Partners ist. Eine sehr enge Kooperation zwischen Sicherheitsorganisation und globalen oder lokalen Einkaufsabteilungen ist entscheidend für den Erfolg eines SSLA-Projekts.
Ähnliche Anforderungen gelten für die Integration neuer Gesellschaften in den Konzern: Hier ist der Übergang zu schaffen von einer – im besten Fall bereits durch vorher abgeschlossene SSLAs geklärten – externen Blickweise hin zu internen Strukturen. Je näher SSLAs und Security Policy aufeinander abgestimmt sind, desto einfacher ist dies.
Das Sicherheits-Management hat weiterhin die Aufgabe, den Sicherheitsstatus zu ermitteln. Dazu zählt auch – und das ist meist der schwierigste Teil – die geeignete Darstellung des aktuellen Status gegenüber dem Management. Sicherheitsberichte sollten sich nicht damit zufrieden geben anzuprangern, dass Viren-Scanner veraltet sind oder Türen zu oft unverschlossen bleiben. Vielmehr geht es darum Fragen zu beantworten wie die folgenden:
Nun kann man schlecht den Administrator eines Viren-Scanners nach dem Einfluss seiner Arbeit auf den Vertriebsprozess befragen – sehr wohl kann er aber die Wirksamkeit des Virenschutzes einschätzen. Genau hier setzt eine Methodik an, die SAP erfolgreich umsetzt: Sie zielt darauf ab, aus dem Status von Maßnahmen auf ein quantifizierbares Risiko für verschiedenste schützenswerte Güter zu schließen.
Dazu wird mithilfe bekannter Bedrohungen eine Liste so genannter atomarer Risiken erzeugt. Ein solches atomares Risiko sagt aus, wie hoch der voraussichtliche Verlust sein wird, wenn eine Bedrohung in einem Land in einer Geschäftseinheit auf eine Klasse von Gütern wirkt. Güter sind dabei nicht nur Gebäude und PCs, sondern beispielsweise auch Informationen, die Produktivität oder der Markenname; das höchstwertige Gut sind die Mitarbeiter.
Die Abbildung der atomaren Risiken umfasst bei SAP derzeit rund 90 000 Einträge. Interessant wird dieser Ansatz durch Betrachtung der Maßnahmen, welche die atomaren Risiken vermindern: Dies sind so genannte Sicherheits-Controls, deren Status regelmäßig von etwa einhundert Mitarbeitern abgefragt wird. Die Maßnahme "Virenschutz" vermindert beispielsweise die Wirkung verschiedener virenartiger Bedrohungen; diese wiederum haben (unter anderem) Einfluss auf Daten und die Produktivität des Unternehmens.
![[Illustration]](06-5-006-4.jpg)
Abbildung 4: SAP nutzt eine selbst entwickelte Methodik zur quantifizierenden Risikoanalyse: Bedrohungsdaten sowie Informationen über Güter und den Status von Sicherheitsmaßnahmen erzeugen eine Liste bezifferbarer atomarer Risiken, die sich auf vielfältige Weise auswerten lassen.
Letztlich ergibt sich damit ein quantifiziertes Bild von Risiken auf Gütern innerhalb von Ländern und Geschäftsbereichen. Die einzelnen Risiken lassen sich nach Belieben zusammenfassen und statistisch zu einem kumulierten, vom Status der Maßnahmen abhängigen verbleibenden Risiko addieren. Legt man neben dem Wert eines Guts auch Akzeptanzschwellen für Risiken fest, so lässt sich die Frage nach akzeptablen Risiken beantworten. Wächst eine Bedrohung (z. B. Krieg) in einem Land, so lassen sich die Auswirkungen auf alle Güter sofort ermitteln: Man sieht unmittelbar, an welchen Stellen Akzeptanzschwellen überschritten werden.
Diese Methodik liefert auch Ergebnisse für einen viel diskutierten Begriff: Return on Security Investment (ROSI). Ein Projekt verändert Güter und den Status von Maßnahmen. Schätzt man diese Veränderungen ab, so ergibt sich ein neuer Wert für das verbleibende Restrisiko. Vergleicht man diesen mit dem vorher ermittelten Wert, so ergibt sich der ROSI als Differenz.
Dieser Ansatz funktioniert auch für Projekte, die nicht sicherheitsgetrieben sind: Würde beispielsweise ein Outsourcing-Projekt Informationen und Mitarbeiter in ein Land mit einem anderen Bedrohungsstatus verschieben, so kann die zu erwartende Veränderung des sicherheitsbezogenen Risikos seitens des Managements als Entscheidungshilfe pro oder contra Projektdurchführung herangezogen werden.
Darüber hinaus ergibt sich unmittelbar eine Liste von Maßnahmen, deren mangelnde Umsetzung Risiken unangemessen erhöhen. Sie dient als Basis für die Festlegung zukünftiger Aktivitäten.
Stand heute benutzt SAP die hier (stark vereinfacht) beschriebene Methodik nur mit Daten aus internen Quellen. Es ist jedoch geplant, auch die wichtigsten Service-Provider mit in die Berichtswege aufzunehmen, sodass sich dann ein Status auch über die Partner-Landschaft hinweg ermitteln lässt. Zudem sollen Informationen von Auditoren und Benchmarking-Daten das Bild in naher Zukunft abrunden.
Ein primäres Ziel der beschriebenen Status-Ermittlung ist die Feststellung notwendiger Abhilfemaßnahmen, um Sicherheitsrisiken auf ein akzeptables Niveau zu bringen. Darin besteht der nächste Prozess-Schritt im Security-Management: Die geeignete Unterstützung von Schlüsselprojekten.
Die Form solcher "geeigneten Unterstützung" zu finden ist gerade bei beschränkten Ressourcen nicht immer einfach. In der Regel sind sicherheitsrelevante Projekte in mehreren Geschäftsbereichen angesiedelt und haben beträchtliche Laufzeiten. Dem zentralen Sicherheits-Management, bei SAP in Form von Corporate Security, fällt dann die Rolle eines Förderers und teilweise auch eines Projektleiters zu. Förderung heißt in diesem Zusammenhang, die Projektdefinition zu unterstützen, bei der Beschaffung notwendiger Ressourcen zu assistieren und die Kommunikation über Geschäftsbereiche hinweg zu stärken.
In jedem Fall muss die zentrale Funktion berichtsfähig über die Lage der Schlüsselprojekte sein. Dies betrifft auch die Änderungen im Sicherheitsstatus des Unternehmens, die aufgrund der Projektergebnisse zu erwarten sind. Die hierzu notwendige Dokumentation erfolgt bei SAP über drei Tools: den Strategic Business Plan, eine Security Balanced Scorecard und eine Projekt- und Serviceübersicht.
Der Strategic Business Plan bedient sich der bereits genannten Ziele der Sicherheitsorganisation und versieht sie mit messbaren Kennzahlen für die kommenden drei Jahre. Er umfasst zwar keine einzelnen Projekte, jedoch werden Messgrößen großer Projekte zur Ermittlung der Zielerfüllung herangezogen. Ein Beispiel eines solchen Wertes ist das bereits erwähnte verbleibende Restrisiko. Es wird für Geschäfts- oder Themenbereiche wie "Outsourcing" oder "Schutz von Kundendaten" getrennt ausgewertet und dient als wichtige Basis für Reifegradbetrachtungen.
Die Security Balanced Scorecard bezieht sich hingegen auf das aktuelle Geschäftsjahr. In ihr werden vier verschiedene Blickwinkel auf den Sicherheitsstatus angenommen: finanzielle Sicht, Kundensicht, operative und innovative Sicht. Im Wesentlichen finden sich hierin die Ziele des Business-Plans wieder, ergänzt um sehr konkrete und in ihrem Status messbare Parameter. Zur Statusbestimmung werden einerseits die Ergebnisse der globalen Statusbestimmung, andererseits der Stand von Schlüsselprojekten und von Services herangezogen, welche die Sicherheitsorganisation anbietet. Die Balanced Scorecard wird von Corporate Security erstellt und liefert damit auch den Status von laufenden Projekten und Services dieser Abteilung. Sie stellt bewusst ein Medium dar, das den aktuellen Status der Konzernsicherheit und der Abteilungsergebnisse einheitlich widerspiegelt. Der Grund ist einfach: Aus Sicht der Unternehmensführung ist beides identisch.
Die Balanced Scorecard liefert allerdings keine Historie zu Projekten oder detaillierte Sicht auf Meilensteine. Hierzu wird bei SAP ein internes Tool genutzt, das neben dem Projekt- und Servicestatus auch Eskalations- und Entscheidungsbedarf übersichtlich darstellt. Der CSO hat damit die Chance, über viele Projekte hinweg gezielt einzugreifen. Er validiert den jeweiligen Status, bevor dieser in Balanced Scorecard oder Strategic Business Plan weiter verarbeitet wird.
In naher Zukunft wird sich das Zusammenspiel der beschriebenen Tools deutlich ändern: Durch die Einführung des neuen, SAP-eigenen Produkts Governance, Risk & Compliance Management (GRC) wird es dann eine integrierte Plattform für zahlreiche Aufgaben geben.
Trotz bester Planung: Verletzungen der Security Policy gibt es in jedem Unternehmen. Das Security-Management muss hierfür Eskalationsstellen und Prozesse bereitstellen, die eine schnelle Auswertung der Zwischenfälle und eine angemessene Antwort im Bedarfsfall gewährleisten. Bei SAP kann jeder Mitarbeiter in einem internen Portal sicherheitsbezogene Zwischenfälle melden, sowohl anonym als auch personalisiert.
Die Auswertung geschieht mehrstufig: Zunächst überprüft der lokal verantwortliche Security Officer die Meldung und vervollständigt sie gegebenenfalls. Er entscheidet über Reaktions- und Eskalationsbedarf. Im Eskalationsfalle wird auch Corporate Security eingeschaltet, deren Mitarbeiter über weitere Schritte von zentraler Seite entscheiden. Gleichzeitig werden auch Querverbindungen zu anderen Zwischenfällen gesucht. Ziel ist dabei, Hinweise auf eine sich entwickelnde Krise zu finden. In diesem Fall entscheidet der CSO, ob ein abteilungsübergreifendes Krisenmanagement-Team mit der weiteren Bearbeitung betraut wird und wie es aufgebaut ist. Die statistische Auswertung wird in jedem Fall von Corporate Security übernommen. Die ermittelten Daten dienen auch zur Eichung der beschriebenen Risikoanalysen und zur Optimierung von Business-Continuity-Prozessen.
Meldewege zu Sicherheits-Zwischenfällen werden überdies auch seitens der Rechtsabteilung zur Meldung von Betrugsfällen genutzt: Das sich regelmäßig treffende Fraud Evaluation Team sucht dabei nach Verbindungen zwischen beiden Meldungsarten und schlägt dem Management reaktive Maßnahmen vor. Die gemeinsame Auswertung von Sicherheits- und Betrugs-Zwischenfällen hat sich mehrfach bewährt. Die Ergebnisse liefern dem Sicherheits-Management eine gute Datenbasis zur eigenen Weiterentwicklung.
Sicherheits-Management ist auch bei SAP auf den Schutz bestehender Werte ausgelegt. Doch wie in anderen, schnell wachsenden Unternehmen ist der Bestandsschutz nur ein Teilaspekt: Erst Flexibilität ermöglicht künftiges Wachstum. Anpassungsfähigkeit ist gefragt, wo Geschäftsfelder entstehen oder neue Tochtergesellschaften einzugliedern sind.
Bestandsschutz versus Anpassungsfähigkeit – das mag sich nach Spagat anhören, doch will man Sicherheit "managen", so muss man sich dieser Herausforderung stellen. Bei SAP sind es CSO und Corporate Security, die als vorstandsnahe und zentral aufgestellte Organisation diese Hürde nehmen müsssen. Der Weg führt dabei weg von einer konservativen Aufpasser-Rolle hin zum anerkannten und gefragten Ratgeber. Sicherheits-Management kann in sich schnell ändernden Umgebungen nicht darauf zielen, Dinge zu verbieten. Es muss vielmehr zeigen, an welchen Stellen Risiken akzeptabel sind oder durch welche Maßnahmen sie akzeptabel werden können.
Von nicht zu unterschätzender Bedeutung ist das Thema Awareness. Bei Mitarbeitern und Führung muss das Bewusstsein ausgeprägt sein, dass Sicherheit ein Kernthema bei allen geschäftlichen Entscheidungen, Plänen und Vorhaben ist. Nur dann werden die für Sicherheit verantwortlichen Strukturen aktiv von allen Geschäftsbereichen angefragt. Erleichtert wird dies beispielsweise durch das Einrichten von Services, aus denen alle Unternehmensbereiche Nutzen ziehen. Die angesprochenen Security-SLAs sind ein solcher Service; Risikoanalysen zu geplanten Projekten oder maßgeschneiderte Statusberichte auf Länder- oder Organisationsebene können weitere sein.
Aktive Anfragen aus den Geschäftsbereichen gilt es zu unterstützen. Nach Möglichkeit sollte man den Zufriedenheitsgrad solcher internen Kunden messen (beispielsweise über Fragebogen). Lässt die Nachfrage zu Serviceleistungen nach, so sollte sich die Sicherheitsorganisation fragen, ob sie noch die richtigen Umsetzungswege zu ihren Strategien verfolgt. Das sichere Ende aktiver Anfragen kann allerdings auch durch die Sicherheitsorganisation selbst kommen: Um das zu vermeiden, muss sie zeigen, dass sie in der Lage ist, unternehmerische Entscheidungen durch Abwägen von Sicherheits- und Geschäftsinteressen zu treffen. Sie muss dies auch mit verständlichen Begriffen nachweisen können, wozu die Betrachtung von Sicherheitsrisiken ein guter Ansatz ist.
Modernes Sicherheits-Management ist gelebtes Risiko-Management. Es muss sich der Aufgabe stellen, nicht nur ein sinnvolles Sicherheitsniveau zu verfolgen, sondern auch ein sinnvolles Risikoniveau mit den Verantwortlichen der Geschäftsbereiche abzustimmen. Dieses Niveau akzeptabler Risiken dient gemeinsam mit dem Katalog des grundlegenden Schutzbedarfs als Basis für Entscheidungsempfehlungen und Projektvorschläge. Gelingt es, diesen Ansatz im Unternehmen verständlich zu machen, so steigert sich die Akzeptanz der Sicherheitsorganisation deutlich – und mit ihr die Sicherheit selbst.
Hier schließt sich der Kreis auch zum Thema Unternehmenskultur: Ein hoher interner Kommunikationsgrad stellt weniger eine Gefahr dar als vielmehr eine Chance der Sicherheitsorganisation, über ihr Wirken zu diskutieren. Vorbei sind die Zeiten von "Security by Obscurity" – stattdessen stellt der offene Austausch die Basis dessen dar, was hier als Sicherheits-Management beschrieben wurde.
Guido Wagner (guido.wagner@sap.com) ist bei SAP Prozesseigner zum Sicherheits-Management. Der gelernte Physiker verantwortet außerdem Projekte zur Risikoanalyse.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2006#5, Seite 6
| 