01750 Sicherheit im Rechenzentrum – Grundlagen und Anforderungen
|
Dieser Beitrag gibt einen Überblick über das Spektrum der RZ-Sicherheit und ihre Bedeutung für das betreibende Unternehmen. RZ-Sicherheit sollte Bestandteil eines unternehmensweiten Managements von Informationssicherheit sein, um auf einheitliche Strategien, Analysen, Konzepte und Verfahren zurückgreifen zu können. Dazu sollte sie in das unternehmensweite Anforderungs- und Risikomanagement eingebunden sein, mit Schwerpunkt auf der Verfügbarkeit der RZ-Ressourcen, dem Notfallmanagement sowie speziellen Dienstleistungsvereinbarungen. Daraus resultieren bauliche, infrastrukturelle, aber auch prozessorientierte und organisatorische Maßnahmen, um einen RZ-Betrieb mit entsprechenden Dienstleistungen gemäß bestehenden Verpflichtungen und Service Levels zu gewährleisten. Dabei stehen etablierte Normen, Standards und Kriterienwerke als Hilfestellung und ggf. Zertifizierungsgrundlage zur Verfügung, die sowohl unternehmensweite IS-Aspekte als auch spezielle Eigenschaften des RZ adressieren. Dieser Beitrag stellt relevante Standards vor und vergleicht diese. Arbeitshilfen: von: |
1.1 Ziele
In der Verantwortung eines RZ-Managers liegt die Sicherstellung der Qualität von RZ-Dienstleistungen gemäß den Anforderungen von internen oder externen Kunden. Ein wichtiger Qualitätsaspekt ist dabei die Sicherheit von Infrastruktur, Systemen, Prozessen und beteiligten Personen innerhalb des RZ-Bereichs, nachfolgend als RZ-Sicherheit bezeichnet.
In diesem Beitrag und in weiteren wird ein Überblick über das Spektrum der RZ-Sicherheit und seine strategische Bedeutung für das Unternehmen vermittelt. Dabei orientieren sich die Beiträge an folgenden Aussagen:
| Thesen zum Thema | |
| • | Erfolgreiche RZ-Sicherheit sollte Teil eines unternehmensweiten Managements von Informationssicherheit (IS) sein, damit Strategien, Anforderungen, Risiken und Maßnahmen nach einheitlichen Kriterien analysiert und behandelt sowie durch ein durchgängiges IS-Management überwacht und verbessert werden. |
| • | Etablierte Standards können dabei wertvolle Hilfestellung leisten, wenn sie bedarfsgerecht ausgewählt werden und sich in Ihr Unternehmensumfeld mit seinen Verfahren und Richtlinien integrieren lassen. Daher werden Sie mit den wichtigsten Normen und Standards zur RZ-Sicherheit vertraut gemacht (s. Abschnitt 4). |
| • | Als Voraussetzung zur Auswahl und Gestaltung geeigneter Maßnahmen und Verfahren zur RZ-Sicherheit sollten zuvor sämtliche relevanten Anforderungen und Risiken ermittelt, bewertet und in angemessene IS-Ziele und -Strategien umgesetzt worden sein. Dazu bedarf es geeigneter Vorgehensweisen. |
| • | Die Detaillierung einer Strategie zur RZ-Sicherheit in anforderungsgerechte und effiziente Konzepte und Betriebsprozesse sowie der qualitätsorientierte Betrieb stellen eine große Herausforderung dar, da eine Fülle von Einzelaspekten zu berücksichtigen ist. Es bieten neben den bereits erwähnten Normen und Standards weitere Orientierungshilfen eine willkommene Unterstützung, z. B. Publikationen von Interessenverbänden wie BITKOM oder spezielle Kriterienkataloge zur RZ-Sicherheit, insbesondere bei dem Ziel einer Zertifizierung dieses Bereichs [1] [2]. |
| • | Die Aufrechterhaltung von RZ-Funktionen auch nach Notfällen/Katastrophen mit hohem Schadensvolumen ist für alle RZ-Nutzer wesentlich, damit Ausfälle kein kritisches, d. h. existenzbedrohendes Ausmaß erreichen. Damit wird deutlich, dass Notfallmanagement ein wesentlicher Bestandteil von RZ-Sicherheit ist. |
1.2 Rolle der Informations- und RZ-Sicherheit
Die erste These in der vorangehenden Liste formuliert bereits eine wichtige Aussage zum Titel dieses Abschnitts.
Werte und Schutzbedarf
Unternehmenswerte (Assets) müssen entsprechend den an sie gestellten Anforderungen und ihrer Bedeutung (Schutzbedarf) sowie den analysierten Risiken zur Beeinträchtigung des Schutzbedarfs angemessen geschützt werden. Zu den Assets zählen Informationen, Hard- und Software, Infrastruktur, Dienstleistungen, Mitarbeiter und Know-how, aber auch Reputation und Image des Unternehmens. Die Gewährleistung dieses Schutzes ist die Aufgabe von Informationssicherheit (IS) im Allgemeinen und RZ-Sicherheit im Besonderen.
Unternehmenswerte (Assets) müssen entsprechend den an sie gestellten Anforderungen und ihrer Bedeutung (Schutzbedarf) sowie den analysierten Risiken zur Beeinträchtigung des Schutzbedarfs angemessen geschützt werden. Zu den Assets zählen Informationen, Hard- und Software, Infrastruktur, Dienstleistungen, Mitarbeiter und Know-how, aber auch Reputation und Image des Unternehmens. Die Gewährleistung dieses Schutzes ist die Aufgabe von Informationssicherheit (IS) im Allgemeinen und RZ-Sicherheit im Besonderen.
Der RZ-Bereich umfasst naturgemäß eine hohe Konzentration von schutzbedürftigen Informationen, IT-Systemen und damit verbundenen Organisations- und Prozessstrukturen.
Er ist damit einem sehr hohen Bedrohungs- und Schadenspotenzial ausgesetzt, besonders aufgrund technischen Versagens, vorsätzlicher Angriffe und höherer Gewalt.
RZ-Sicherheit im engeren Sinn setzt den Schwerpunkt auf eine ausreichende Absicherung von Gelände, Gebäuden, Räumen und deren Infrastruktur.
Im erweiterten Sinn kommt die Betriebssicherheit aller technischen Komponenten im RZ (Infrastruktur und IT) entsprechend den Anforderungen der bereitzustellenden RZ-Dienstleistungen hinzu.
Bedeutung von RZ-Sicherheit
Damit wird die Bedeutung des RZ als integraler Bestandteil der Wertschöpfungskette des Unternehmens offensichtlich. Dies findet seinen Niederschlag in der RZ-Sicherheit durch entsprechend sichere Ausgestaltung von Organisationsstrukturen, Planungs- und Betriebsprozessen sowie Mitarbeitern.
Damit wird die Bedeutung des RZ als integraler Bestandteil der Wertschöpfungskette des Unternehmens offensichtlich. Dies findet seinen Niederschlag in der RZ-Sicherheit durch entsprechend sichere Ausgestaltung von Organisationsstrukturen, Planungs- und Betriebsprozessen sowie Mitarbeitern.
Die Verfügbarkeit von Geschäftsprozessen und beteiligten IT-Infrastrukturen entsprechend den internen und externen Anforderungen sowie die sichere Verarbeitung sensibler Informationen sind heutzutage strategische Wettbewerbsfaktoren für ein Unternehmen. Informationssicherheit (IS) inklusive RZ-Sicherheit ist daher eine wesentliche Komponente des unternehmensweiten Risikomanagements, insbesondere vor dem Hintergrund wachsender Globalisierung, Vernetzung und Mobilität sowie immer komplexerer Angriffsszenarien.
Beiträge zum Unternehmensziel
IS ist eng mit den Zielen und der Wertschöpfungskette des Unternehmens verzahnt und liefert dazu folgende Beiträge:
IS ist eng mit den Zielen und der Wertschöpfungskette des Unternehmens verzahnt und liefert dazu folgende Beiträge:
| • | Schutz von Informationen, Infrastrukturen und IT-Systemen entsprechend ihrem Wert und Risikoreduzierung auf ein akzeptables Niveau |
| • | Schaffung von Vertrauen zu Banken, Versicherungen, Kunden und Lieferanten; dadurch z. B. besseres Rating, geringere Beiträge, Umsatzsteigerungen, Erschließung neuer Märkte |
| • | Wertschöpfung durch unternehmerische Leistungen, die ohne Informationssicherheit nicht möglich wären, z. B. Öffnung des Unternehmens, Kosteneinsparungen, Qualitätsverbesserungen oder Produktivitätssteigerungen |
ISMS und Risikomanagement
IS im Unternehmen braucht das Bekenntnis und aktive Engagement der Unternehmensleitung. Ständiger Motor unternehmensweiter IS sind ein IS-Managementsystem (ISMS) sowie ein ernst genommenes Risikomanagement, zu dem Vorstände und Geschäftsführer ohnehin gesetzlich angehalten werden. Zusammen mit der Kenntnis relevanter Anforderungen können daraus eine geeignete IS-Strategie sowie angemessene Konzepte und Maßnahmen abgeleitet werden.
IS im Unternehmen braucht das Bekenntnis und aktive Engagement der Unternehmensleitung. Ständiger Motor unternehmensweiter IS sind ein IS-Managementsystem (ISMS) sowie ein ernst genommenes Risikomanagement, zu dem Vorstände und Geschäftsführer ohnehin gesetzlich angehalten werden. Zusammen mit der Kenntnis relevanter Anforderungen können daraus eine geeignete IS-Strategie sowie angemessene Konzepte und Maßnahmen abgeleitet werden.
Schadenskategorien
IS ist also der Schutzschild für Ihre Informationswerte im Unternehmen und Teil des unternehmensweiten Risikomanagements für die Klasse der sogenannten operationellen Risiken. Diese Risikoklasse lässt sich z. B. anhand der möglichen Auswirkungen von Sicherheitsvorfällen veranschaulichen. Es können auftreten:
IS ist also der Schutzschild für Ihre Informationswerte im Unternehmen und Teil des unternehmensweiten Risikomanagements für die Klasse der sogenannten operationellen Risiken. Diese Risikoklasse lässt sich z. B. anhand der möglichen Auswirkungen von Sicherheitsvorfällen veranschaulichen. Es können auftreten:
| • | Imageschaden |
| • | Umsatzeinbußen |
| • | Einschränkung/Ausfall des produktiven Betriebs |
| • | Verlust von Information und Know-how-Vorsprung |
| • | unzufriedene Kunden und Geschäftspartner |
| • | Schwächung der Marktposition |
Auch ein ungewollter Gesetzesverstoß ist dem Image Ihres Unternehmens nicht förderlich und kann sogar zur Strafverfolgung führen. Daher gehört zum Management von IS ebenfalls die Kenntnis und Beachtung des rechtlichen Rahmens.
1.3 Management von IS: das ISMS
In diesem Abschnitt werden nur die wichtigsten Inhalte zusammengefasst:
Managementsystem
Ein Unternehmen besitzt ein definiertes Geschäftsziel und eine Strategie, um dieses Ziel zu erreichen. Die Unternehmensleitung verantwortet, dass diese Strategie von allen Mitarbeitern so konsequent und umfassend wie möglich verfolgt wird.
Ein Unternehmen besitzt ein definiertes Geschäftsziel und eine Strategie, um dieses Ziel zu erreichen. Die Unternehmensleitung verantwortet, dass diese Strategie von allen Mitarbeitern so konsequent und umfassend wie möglich verfolgt wird.
Dies geschieht idealerweise durch:
| Plan, Do, Check, Act | |
| • | klare Planungen, Vorgaben und Konzepte („Plan”) |
| • | ausreichende Ressourcen und Skills zu deren Umsetzung („Do”) |
| • | regelmäßige Überprüfungen und Soll-Ist-Vergleiche („Check”) |
| • | Anpassung von Planung und ggf. auch Strategie aufgrund interner Prüfungsergebnisse, veränderter Anforderungen, Unternehmensentwicklungen etc. („Act”) |
Weitere Erfolgsfaktoren sind z. B.:
| • | Transparenz und Nachvollziehbarkeit der Bedeutung der Ziele |
| • | etablierter Code of Conduct (Verhaltenskodex) im Unternehmen |
| • | Glaubwürdigkeit und Vorbildfunktion der Personen, die Ziele und Strategien repräsentieren und daraus eine positive Motivation der Mitarbeiter generieren können |
| • | aktuelle, vollständige und verfügbare Dokumentation wichtiger Informationen |
Die Gesamtheit dieser Komponenten bildet das Managementsystem einer Organisation, das für die Steuerung zur Erreichung der Geschäftsziele sorgt.
IS-Management
Nicht anders ist es im Bereich der IS. Auch hier müssen zunächst innerhalb einer IS-Leitlinie Ziel und Strategie definiert und dann durch ein adäquates Managementsystem gewährleistet werden. Dieses wird als Informationssicherheitsmanagementsystem (ISMS) bezeichnet.
Nicht anders ist es im Bereich der IS. Auch hier müssen zunächst innerhalb einer IS-Leitlinie Ziel und Strategie definiert und dann durch ein adäquates Managementsystem gewährleistet werden. Dieses wird als Informationssicherheitsmanagementsystem (ISMS) bezeichnet.
Ein ISMS legt fest, mit welchen Verfahren und Werkzeugen die unternehmensweite Informationssicherheit auf der Basis der IS-Leitlinie angemessen und nachvollziehbar geplant, etabliert, überwacht, aufrechterhalten und dokumentiert wird. Es orientiert sich dabei oft am PDCA-Prozessmodell.
ISMS-Aufgaben
Die Aufgaben eines ISMS lassen sich wie folgt beschreiben:
Die Aufgaben eines ISMS lassen sich wie folgt beschreiben:
| • | Verankerung und Aufrechterhaltung von IS im Unternehmen |
| • | Analyse von Sicherheitsanforderungen und Festlegung einer Risikostrategie |
| • | Identifizierung und Bewertung von Risiken und deren Auswirkungen |
| • | Identifikation, Umsetzung, Kontrolle und ggf. Verbesserung geeigneter Maßnahmen |
Komponenten
Das Spektrum der IS umfasst die Komponenten
Das Spektrum der IS umfasst die Komponenten
| • | Informationen, |
| • | Prozesse, |
| • | Organisation, |
| • | Gebäude und |
| • | Infrastruktur, |
| • | Technologien und Personal. |
Informationen
Informationen müssen, wie bereits dargestellt, bzgl. ihres Schutzbedarfs an Vertraulichkeit, Integrität und Verfügbarkeit kategorisiert werden. Die Ergebnisse sind dann auf alle übrigen beteiligten Komponenten zu übertragen.
Informationen müssen, wie bereits dargestellt, bzgl. ihres Schutzbedarfs an Vertraulichkeit, Integrität und Verfügbarkeit kategorisiert werden. Die Ergebnisse sind dann auf alle übrigen beteiligten Komponenten zu übertragen.
Prozesse und Organisationsstrukturen
Prozesse und Organisationsstrukturen spielen über das ISMS hinaus eine wichtige Rolle bei der Verankerung von IS im Unternehmen. So werden zur IS-Strategie und den daraus entwickelten Konzepten entsprechende Maßnahmen festgelegt, die in bestehende Organisationsstrukturen, Geschäfts-und IT-Service-Prozesse oder RZ-Betriebsabläufe zu integrieren sind.
Prozesse und Organisationsstrukturen spielen über das ISMS hinaus eine wichtige Rolle bei der Verankerung von IS im Unternehmen. So werden zur IS-Strategie und den daraus entwickelten Konzepten entsprechende Maßnahmen festgelegt, die in bestehende Organisationsstrukturen, Geschäfts-und IT-Service-Prozesse oder RZ-Betriebsabläufe zu integrieren sind.
Infrastruktur und Technologien
Im Bereich von Infrastruktur und Technologien werden aus der Fülle verfügbarer Schutzsysteme geeignete Lösungen identifiziert, ggf. konfektioniert sowie konfiguriert und getestet. Anschließend erfolgt ihre Einführung in den operativen Betrieb, in der Regel Hand in Hand mit flankierenden organisatorischen, personellen und prozessorientierten Maßnahmen.
Im Bereich von Infrastruktur und Technologien werden aus der Fülle verfügbarer Schutzsysteme geeignete Lösungen identifiziert, ggf. konfektioniert sowie konfiguriert und getestet. Anschließend erfolgt ihre Einführung in den operativen Betrieb, in der Regel Hand in Hand mit flankierenden organisatorischen, personellen und prozessorientierten Maßnahmen.
Personelle Maßnahmen
Ohne geeignete personelle Maßnahmen werden jedoch alle anderen Bestandteile der IS nur Stückwerk bleiben. Der wesentliche Erfolgsfaktor unternehmensweiter IS ist und bleibt der verantwortungsbewusste, motivierte und sensibilisierte Mitarbeiter. Daher ist es von großer Wichtigkeit, die Akzeptanz der Mitarbeiter für die Notwendigkeit einer angemessenen IS zu erreichen, auch wenn dies für sie mit Einschränkungen, Zusatzaufwand oder der Aufgabe angestammter Rechte verbunden ist. Bewährte Formen von Awareness-Kampagnen sowie Informations- und Schulungskonzepten bieten sich Ihnen hier als wertvolle Hilfe an.
Ohne geeignete personelle Maßnahmen werden jedoch alle anderen Bestandteile der IS nur Stückwerk bleiben. Der wesentliche Erfolgsfaktor unternehmensweiter IS ist und bleibt der verantwortungsbewusste, motivierte und sensibilisierte Mitarbeiter. Daher ist es von großer Wichtigkeit, die Akzeptanz der Mitarbeiter für die Notwendigkeit einer angemessenen IS zu erreichen, auch wenn dies für sie mit Einschränkungen, Zusatzaufwand oder der Aufgabe angestammter Rechte verbunden ist. Bewährte Formen von Awareness-Kampagnen sowie Informations- und Schulungskonzepten bieten sich Ihnen hier als wertvolle Hilfe an.
RZ-Sicherheit ist ein Prozess
Charakteristisch für unternehmensweite IS und RZ-Sicherheit ist:
Charakteristisch für unternehmensweite IS und RZ-Sicherheit ist:
| • | Sicherheit ist kein konfektioniertes Produkt!
| ||||||
| • | Sicherheit ist kein zeitlich begrenztes Projekt!
| ||||||
| • | Sicherheit ist ein Prozess, der definiert, implementiert, überwacht, aufrechterhalten und kontinuierlich verbessert werden muss! |
2.1 Einführung und Anforderungsmanagement
Die Anforderungen an RZ-Sicherheit leiten sich von den bestehenden Anforderungen und Verpflichtungen der unternehmensweiten IS ab, mit besonderer Betonung der Verfügbarkeit von RZ-Ressourcen sowie des Notfallmanagements.
In jedem Unternehmen existiert eine Reihe von Anforderungen, die direkt oder indirekt Auswirkungen auf das IS-Management haben. Einige Beispiele dazu:
| • | Gesetzliche Anforderungen
| ||||
| • | Vertragliche Anforderungen
| ||||
| • | Sonstige Anforderungen
|
Diese Anforderungen sind je nach Branche, Land und anderen Rahmenbedingungen unterschiedlich. Außerdem unterliegt z. B. eine Behörde anderen externen Regelungen als eine Aktiengesellschaft. Die Unternehmensleitung muss die Einhaltung relevanter Anforderungen durch angemessene Überwachungsmaßnahmen sicherstellen (Compliance).
Für die RZ-Sicherheit sei besonders auf die Vielzahl zu erfüllender Normen im physischen und infrastrukturellen Bereich hingewiesen (s. Arbeitshilfe), die sich in jeder der drei oben genannten Kategorien wiederfinden.
Anforderungsmanagement
Aufgrund der Komplexität und Dynamik der Anforderungen empfiehlt sich für jedes Unternehmen die Einrichtung eines Anforderungsmanagements. Ziel des Anforderungsmanagements ist es, jederzeit den Überblick über die verschiedenen Anforderungen an die einzelnen Unternehmensbereiche zu haben und geeignete Maßnahmen zu identifizieren und umzusetzen, um Verstöße gegen diese Anforderungen zu vermeiden.
Aufgrund der Komplexität und Dynamik der Anforderungen empfiehlt sich für jedes Unternehmen die Einrichtung eines Anforderungsmanagements. Ziel des Anforderungsmanagements ist es, jederzeit den Überblick über die verschiedenen Anforderungen an die einzelnen Unternehmensbereiche zu haben und geeignete Maßnahmen zu identifizieren und umzusetzen, um Verstöße gegen diese Anforderungen zu vermeiden.
2.2 Anforderung: Verfügbarkeit des RZ
Kontinuierliche Verfügbarkeit unverzichtbar
Die fortschreitende Entwicklung und Integration der IT in alle Geschäftsbereiche bedeutet, dass sich heutzutage kein Unternehmen mehr einen ungeplanten IT-Ausfall leisten kann. Noch vor wenigen Jahren konnten viele Unternehmen auch mit einem mehrstündigen Ausfall ihrer IT-Infrastruktur „überleben”. Heute steigt die Zahl derer, für die eine kontinuierliche Verfügbarkeit der IT unverzichtbar ist, stark an. Ein zehntägiger Ausfall geschäftskritischer IT-Systeme kann ein Unternehmen so nachhaltig schädigen, dass es mit 50 % Wahrscheinlichkeit innerhalb der nächsten drei bis fünf Jahre vom Markt verschwindet.
Die fortschreitende Entwicklung und Integration der IT in alle Geschäftsbereiche bedeutet, dass sich heutzutage kein Unternehmen mehr einen ungeplanten IT-Ausfall leisten kann. Noch vor wenigen Jahren konnten viele Unternehmen auch mit einem mehrstündigen Ausfall ihrer IT-Infrastruktur „überleben”. Heute steigt die Zahl derer, für die eine kontinuierliche Verfügbarkeit der IT unverzichtbar ist, stark an. Ein zehntägiger Ausfall geschäftskritischer IT-Systeme kann ein Unternehmen so nachhaltig schädigen, dass es mit 50 % Wahrscheinlichkeit innerhalb der nächsten drei bis fünf Jahre vom Markt verschwindet.
Verfügbarkeit
Der Begriff Verfügbarkeit bezeichnet nach DIN ISO/IEC 27000 die Eigenschaft eines Systems, für berechtigte Aufgaben und Anwender auf Verlangen zugänglich und nutzbar zu sein. Das heißt, das System sollte im Rahmen seiner vorgesehenen Nutzung (z. B. beschrieben durch vereinbarte Service Levels) zu einem gegebenen Zeitpunkt wie geplant funktionieren.
Der Begriff Verfügbarkeit bezeichnet nach DIN ISO/IEC 27000 die Eigenschaft eines Systems, für berechtigte Aufgaben und Anwender auf Verlangen zugänglich und nutzbar zu sein. Das heißt, das System sollte im Rahmen seiner vorgesehenen Nutzung (z. B. beschrieben durch vereinbarte Service Levels) zu einem gegebenen Zeitpunkt wie geplant funktionieren.
Klassen
Damit ist Verfügbarkeit ein quantitativ bestimmbares Maß, das in Klassen unterteilt und als Qualitätsmerkmal eines Systems oder eines IT-Service interpretiert werden kann. Typischerweise wird die Verfügbarkeit als Verhältnis aus fehlerbedingter Ausfallzeit und Betrachtungszeit eines Systems nach folgender Formel ermittelt:
Damit ist Verfügbarkeit ein quantitativ bestimmbares Maß, das in Klassen unterteilt und als Qualitätsmerkmal eines Systems oder eines IT-Service interpretiert werden kann. Typischerweise wird die Verfügbarkeit als Verhältnis aus fehlerbedingter Ausfallzeit und Betrachtungszeit eines Systems nach folgender Formel ermittelt:
Verfügbarkeit [%] = (1 – Ausfallzeit : Betrachtungszeit) × 100
Das US Uptime Institute [3] hat folgende Verfügbarkeitsklassen für Rechenzentren definiert:
| Tier I | einfacher Stromversorgungspfad; einfache Kälteversorgung; keine redundanten Komponenten; 99,671 % Verfügbarkeit => max. 28,8 h Downtime pro Jahr |
| Tier II | einfacher Stromversorgungspfad, einfache Kälteversorgung, redundante Komponenten, 99,741 % Verfügbarkeit => max. 22,7 h Downtime pro Jahr |
| Tier III | mehrere Stromversorgungspfade vorhanden, aber nur einer aktiv; redundante Komponenten; Wartung ohne Unterbrechung möglich; 99,982 % Verfügbarkeit => max. 1,6 h Downtime pro Jahr |
| Tier IV | mehrere aktive Strom- u. Kaltwasserverteilungspfade; redundante Komponenten; Fehlertoleranz; 99,995 % Verfügbarkeit => max. 25 min. Downtime pro Jahr |
Darüber hinaus sind in der Norm DIN EN 50600-2-x vier qualitative Verfügbarkeitsklassen VK1 bis VK4 definiert (vgl. Kap. 07470).
Maximal tolerierbare Ausfallzeiten
Da die Realisierung derart hoher Anforderungen signifikante Investitionen und laufende Betriebskosten erfordert, die durch einen gewünschten Nutzen oder die erforderliche Erfüllung von Verpflichtungen getragen werden müssen, beginnen strategische Überlegungen zur RZ-Verfügbarkeit sinnvollerweise mit folgender Frage:
Da die Realisierung derart hoher Anforderungen signifikante Investitionen und laufende Betriebskosten erfordert, die durch einen gewünschten Nutzen oder die erforderliche Erfüllung von Verpflichtungen getragen werden müssen, beginnen strategische Überlegungen zur RZ-Verfügbarkeit sinnvollerweise mit folgender Frage:
„Wie groß sind – unter Berücksichtigung aller bestehenden Verpflichtungen des Unternehmens sowie der Kritikalität der eigenen IT-gestützten Geschäftsprozesse – die maximal tolerierbaren Ausfallzeiten der RZ-Komponenten?”
Damit sind wir gleichzeitig am Beginn des Prozesses Continuity Management (auch Notfallmanagement), den wir noch diskutieren werden. Zur qualifizierten Beantwortung dieser Frage sind drei Komponenten erforderlich:
| • | Vollständige Kenntnis aller aktuellen Anforderungen und Verpflichtungen des Unternehmens (vgl. Abschnitt 2.1) |
| • | Durchführung einer Business-Impact-Analyse (BIA), die die Auswirkungen unterschiedlicher IT-Ausfallzeiten auf die unterstützten Geschäftsprozesse des Unternehmens ermittelt |
| • | Durchführung einer Risikoanalyse (RA), um Bedrohungen und Schwachstellen, die sich negativ auf die Verfügbarkeit von RZ-Komponenten auswirken können, zu ermitteln, zu bewerten und geeignet zu behandeln (vgl. Abschnitt 3.2) |
BSI-Hilfsmittel
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt Hilfsmittel zum Verfügbarkeitsdesign bereit.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt Hilfsmittel zum Verfügbarkeitsdesign bereit.
HV-Kompendium
Zum einen steht mit dem Hochverfügbarkeits-Kompendium (HV-Kompendium) [4] ein Planungs- und Realisierungsinstrument als Ergänzung zum IT-Grundschutz zur Verfügung, das von der Analyse kritischer Geschäftsprozesse und ihrer Anforderungen über die Ableitung geeigneter IT-Architekturen bis hin zu konkreten Maßnahmenkatalogen reicht (vgl. Abschnitt 4.2.3).
Zum einen steht mit dem Hochverfügbarkeits-Kompendium (HV-Kompendium) [4] ein Planungs- und Realisierungsinstrument als Ergänzung zum IT-Grundschutz zur Verfügung, das von der Analyse kritischer Geschäftsprozesse und ihrer Anforderungen über die Ableitung geeigneter IT-Architekturen bis hin zu konkreten Maßnahmenkatalogen reicht (vgl. Abschnitt 4.2.3).
HVB-kompakt
Weiterhin existiert ein Hochverfügbarkeits-Benchmark kompakt (HVB-kompakt) [5] des BSI als Teil eines BSI-Mindeststandards zur Ermittlung des IT-Sicherheitsniveaus von Rechenzentren. Dabei handelt es sich um ein Benchmarkverfahren, mit dem Reifegrade und Potenzialstufen erreicht werden können. Der Mindeststandard legt für die 34 Indikatoren des HVB-kompakt Mindestwerte fest, die bei der Anwendung des HVB-kompakt aus Sicht des BSI mindestens erreicht werden müssen.
Weiterhin existiert ein Hochverfügbarkeits-Benchmark kompakt (HVB-kompakt) [5] des BSI als Teil eines BSI-Mindeststandards zur Ermittlung des IT-Sicherheitsniveaus von Rechenzentren. Dabei handelt es sich um ein Benchmarkverfahren, mit dem Reifegrade und Potenzialstufen erreicht werden können. Der Mindeststandard legt für die 34 Indikatoren des HVB-kompakt Mindestwerte fest, die bei der Anwendung des HVB-kompakt aus Sicht des BSI mindestens erreicht werden müssen.
3 Schutzbedarfs- und Risikoanalyse
Risiken nachhaltig begrenzen
Neben der kontinuierlichen Erfüllung von Anforderungen existiert mit der nachhaltigen Begrenzung von Risiken eine weitere Motivation für IS im Unternehmen. Beide Motivationen sind durchaus voneinander abhängig, da gesetzliche Verpflichtungen zum Management von Risiken existieren, die den Fortbestand des Unternehmens gefährden (Notfallmanagement).
Neben der kontinuierlichen Erfüllung von Anforderungen existiert mit der nachhaltigen Begrenzung von Risiken eine weitere Motivation für IS im Unternehmen. Beide Motivationen sind durchaus voneinander abhängig, da gesetzliche Verpflichtungen zum Management von Risiken existieren, die den Fortbestand des Unternehmens gefährden (Notfallmanagement).
Bedrohungen und Schwachstellen
Risiken entstehen durch das Zusammenspiel von Bedrohungen und Schwachstellen.
Risiken entstehen durch das Zusammenspiel von Bedrohungen und Schwachstellen.
Eine Bedrohung ist nach ISO/IEC 27000 eine mögliche Ursache eines unerwünschten Vorfalls, der einem System oder einer Organisation einen Schaden zufügen kann. Unter einer Schwachstelle wird eine Eigenschaft eines schutzwürdigen Gutes verstanden, die von einer oder mehreren Bedrohungen für eine Schadenswirkung ausgenutzt werden kann.
Bedrohungskategorien
Bedrohungen werden gemäß BSI-Grundschutz (vgl. Abschnitt 4.2.2) in die folgenden Kategorien eingeteilt:
Bedrohungen werden gemäß BSI-Grundschutz (vgl. Abschnitt 4.2.2) in die folgenden Kategorien eingeteilt:
| • | Höhere Gewalt |
| • | Organisatorische Mängel |
| • | Menschliche Fehlhandlungen |
| • | Technisches Versagen |
| • | Vorsätzliche Handlungen |
Reihenfolge der Gefahrenbereiche
Informationen über die Gefahrenbereiche stellt z. B. das BSI in seinem regelmäßigen Lagebericht zur Informationssicherheit zur Verfügung [6]. In Tabelle 1 finden Sie eine Rangfolge der Gefahrenbereiche in absteigender Reihenfolge. Sie basiert auf der aktuellen <kes>/Microsoft Sicherheitsstudie 2018 [7], die eine Momentaufnahme der Informationssicherheit in Unternehmen im deutschsprachigen Raum widerspiegelt. Erkennbar ist u. a., dass der Risikofaktor Mensch – gleich hinter Malware – auf Platz 2 nach wie vor von größter Bedeutung ist.
Informationen über die Gefahrenbereiche stellt z. B. das BSI in seinem regelmäßigen Lagebericht zur Informationssicherheit zur Verfügung [6]. In Tabelle 1 finden Sie eine Rangfolge der Gefahrenbereiche in absteigender Reihenfolge. Sie basiert auf der aktuellen <kes>/Microsoft Sicherheitsstudie 2018 [7], die eine Momentaufnahme der Informationssicherheit in Unternehmen im deutschsprachigen Raum widerspiegelt. Erkennbar ist u. a., dass der Risikofaktor Mensch – gleich hinter Malware – auf Platz 2 nach wie vor von größter Bedeutung ist.
Tabelle 1: Bedeutung der Gefahrenbereiche
Vorhersage 2016 | Bedeutung heute | aktuelle Prognose | ||||
Rang | Priorität | Rang | Priorität | Rang | Priorität | |
Malware (Viren, Würmer, Trojaner …) | 1 | 1,43 | 1 | 1,19 | 1 | 1,18 |
Irrtum und Nachlässigkeit eigener Mitarbeiter | 3 | 0,70 | 2 | 0,93 | 2 | 0,71 |
Mängel der Dokumentation | 5 | 0,53 | 3 | 0,58 | 7 | 0,46 |
Hacking (Vandalismus, Probing, Missbrauch, …) | 2 | 0,78 | 4 | 0,56 | 4 | 0,67 |
Softwaremängel/-defekte | 7 | 0,48 | 5 | 0,55 | 5 | 0,63 |
Unbefugte Kenntnisnahme, Informationsdiebstahl, Wirtschaftsspionage | 4 | 0,63 | 6 | 0,53 | 3 | 0,69 |
Hardwaremängel/-defekte | 10 | 0,24 | 7 | 0,38 | 8 | 0,36 |
Unbeabsichtigte Fehler von Externen | 8 | 0,30 | 8 | 0,37 | 10 | 0,35 |
Sabotage (inkl. DoS) | 6 | 0,49 | 9 | 0,35 | 6 | 0,47 |
Manipulation zum Zweck der Bereicherung | 9 | 0,28 | 10 | 0,34 | 9 | 0,35 |
höhere Gewalt (Feuer, Wasser, …) | 11 | 0,09 | 11 | 0,16 | 11 | 0,12 |
Sonstiges | 12 | 0,05 | 12 | 0,04 | 12 | 0,01 |
3.1 Ermittlung des Schutzbedarfs
Der Schutzbedarf von Informationen und beteiligten Komponenten ist das Ergebnis einer Analyse und Bewertung relevanter Risiken, insbesondere operationeller Risiken, denen die vorher identifizierten Unternehmenswerte ausgesetzt sind. Diese Risiken resultieren aus der kombinierten Analyse von Bedrohungen, die auf die jeweiligen Objekte einwirken können, und objekteigenen Schwachstellen, die den Bedrohungen das Angriffsleben mehr oder weniger leicht machen.
IS-Schutzziele
Der Schutzbedarf und damit die Sicherheitsanforderungen an Informationen und beteiligte Komponenten werden unter Verwendung der IS-Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit beschrieben.
Der Schutzbedarf und damit die Sicherheitsanforderungen an Informationen und beteiligte Komponenten werden unter Verwendung der IS-Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit beschrieben.
Die Frage zur Ermittlung des Schutzbedarfs lautet:
„Welcher Schaden kann entstehen, wenn für einen gegebenen Unternehmenswert je eines der drei IS-Schutzziele verletzt wird?”
Schadensszenarien
Um die Antwort zu erleichtern und die Ergebnisse vergleichbar zu machen, existieren folgende etablierte Schadensszenarien zur Beschreibung der Wirkung eines Schadens:
Um die Antwort zu erleichtern und die Ergebnisse vergleichbar zu machen, existieren folgende etablierte Schadensszenarien zur Beschreibung der Wirkung eines Schadens:
| • | Verstoß gegen Gesetze, Vorschriften, Verträge |
| • | Beeinträchtigung des informationellen Selbstbestimmungsrechts |
| • | Beeinträchtigung der persönlichen Unversehrtheit |
| • | Beeinträchtigung der Aufgabenerfüllung |
| • | negative Innen- oder Außenwirkung |
| • | finanzielle Auswirkungen |
Schadenskategorien
Darüber hinaus sollten im Unternehmen angemessene Schadenskategorien (Anzahl und Abgrenzung) definiert sein, die die Höhe eines Schadens beschreiben. Nachfolgend ein allgemeines Beispiel für drei Schadenskategorien, das Sie auf jeden Fall vor der Anwendung weiter präzisieren sollten:
Darüber hinaus sollten im Unternehmen angemessene Schadenskategorien (Anzahl und Abgrenzung) definiert sein, die die Höhe eines Schadens beschreiben. Nachfolgend ein allgemeines Beispiel für drei Schadenskategorien, das Sie auf jeden Fall vor der Anwendung weiter präzisieren sollten:
| Normal: | Schadensauswirkungen sind begrenzt und überschaubar. |
| Hoch: | Schadensauswirkungen können beträchtlich sein. |
| Sehr hoch: | Schadensauswirkungen können ein existenziell bedrohliches, katastrophales Ausmaß erreichen. |
Damit sind Sie in der Lage, jedem als kritisch identifizierten Unternehmenswert einen individuellen Schutzbedarf zuzuordnen.
Sinnvollerweise beginnen Sie mit der Analyse kritischer Geschäftsprozesse und den zugehörigen Informationen und IT-Anwendungen. Den ermittelten Schutzbedarf übertragen Sie auf die beteiligten IT-Systeme und Netzwerke und in einem nächsten Schritt auf die Räume, Gebäude und vorhandene Infrastruktur. Natürlich sollten Sie auch die involvierten Mitarbeiter nicht vergessen!
3.2 Risikoanalyse nach ISO/IEC 27001 und ISO/IEC 27005
Die nachfolgende Darstellung der einzelnen Schritte einer Risikoanalyse basiert auf den ISO-Standards ISO/IEC 27001 und ISO/IEC 27005. Das BSI hat in seinem Standard 200-3 eine weitere Methode zur Risikoanalyse beschrieben, die mithilfe des IT-Grundschutzkompendiums umgesetzt werden kann und mit vergleichsweise wenig Aufwand zu konkreten IS-Maßnahmen führt, sofern ohnehin die Vorgehensweise nach IT-Grundschutz angewendet wird.
Der Standard ISO 27001:2013 fordert explizit, dass die Organisation einen Prozess zur Bewertung und Behandlung von IS-Risiken definieren und anwenden muss. Die hier dargestellte Vorgehensweise orientiert sich an der ISO 27005.
Aufgaben der Risikoanalyse
Daraus resultieren folgende Aufgaben:
Daraus resultieren folgende Aufgaben:
| • | Auswahl einer Methode zur Risikobewertung |
| • | Klassifizierung von Risiken |
| • | Identifizierung und Bewertung von Risiken |
| • | Festlegung einer Risikostrategie |
| • | Behandlung der Risiken entsprechend der Bewertung und gewählten Risikostrategie |
3.2.1 Auswahl einer Methode zur Risikobewertung
Die Methode zur Risikobewertung ist ein wichtiger Bestandteil jedes ISMS und muss entsprechend dokumentiert werden. Zur Bestimmung eines Risikos müssen relevante Bedrohungen ermittelt und deren Schadenspotenziale und Eintrittswahrscheinlichkeiten bewertet werden. Abhängig von der betrachteten Unternehmensumgebung und dem angestrebten IS-Niveau sind unterschiedliche Methoden zur Risikobewertung möglich, die sich im erforderlichen Aufwand erheblich unterscheiden können. Daher sollte eine Methode ausgewählt werden, die für die Größe und Komplexität der betrachteten Umgebung angemessen ist.
3.2.2 Klassifizierung von Risiken
Nach der Auswahl einer geeigneten Methode zur Risikobewertung muss festgelegt werden, wie die aus Bedrohungen, Schadenspotenzialen und Eintrittswahrscheinlichkeiten resultierenden Risiken geeignet zu klassifizieren sind, um sie danach bewerten zu können.
Schadenspotenzial und Eintrittswahrscheinlichkeit
In der Praxis sind häufig keine zuverlässigen Werte für Schadenspotenzial und Eintrittswahrscheinlichkeit einzelner Risiken von vorneherein vorhanden. Es muss oft gerade beim ersten Durchlauf der Risikoanalyse auf mehr oder weniger scharfe Erfahrungswerte oder Aufzeichnungen über Sicherheitsvorfälle und deren Ursachen zurückgegriffen werden. Daher hat es sich bewährt, für beide Parameter mit einer überschaubaren Zahl von Kategorien (drei bis maximal fünf) zur „Sortierung” der Risiken zu arbeiten, z. B. für
In der Praxis sind häufig keine zuverlässigen Werte für Schadenspotenzial und Eintrittswahrscheinlichkeit einzelner Risiken von vorneherein vorhanden. Es muss oft gerade beim ersten Durchlauf der Risikoanalyse auf mehr oder weniger scharfe Erfahrungswerte oder Aufzeichnungen über Sicherheitsvorfälle und deren Ursachen zurückgegriffen werden. Daher hat es sich bewährt, für beide Parameter mit einer überschaubaren Zahl von Kategorien (drei bis maximal fünf) zur „Sortierung” der Risiken zu arbeiten, z. B. für
| • | die Eintrittswahrscheinlichkeit EW = {gering, mittel, hoch}, |
| • | das Schadenspotenzial SP = {gering, mittel, hoch, sehr hoch}. |
Wichtig!
Definieren Sie die Kategorien für EW und SP möglichst genau und messbar unter Bezug auf die betrachtete Unternehmensumgebung, sodass die spätere Risikobewertung nachvollziehbar und ggf. korrigierbar ist!
Definieren Sie die Kategorien für EW und SP möglichst genau und messbar unter Bezug auf die betrachtete Unternehmensumgebung, sodass die spätere Risikobewertung nachvollziehbar und ggf. korrigierbar ist!
3.2.3 Risikoidentifizierung und -bewertung
Hier verbirgt sich die eigentliche Hauptarbeit der Risikoanalyse. Sie lässt sich in folgende Einzelmaßnahmen aufteilen:
| • | Identifizierung der schützenswerten Informationen, Geschäftsprozesse, Infrastrukturen, IT-Systeme, Mitarbeiter und ihres Schutzbedarfs – Schutzbedarfsanalyse (vgl. Abschnitt 3.1) |
| • | Identifizierung relevanter Bedrohungen und Schwachstellen für die schützenswerten ObjekteFür jeden ermittelten Wert werden Bedrohungen und Schwachstellen identifiziert unter Berücksichtigung bereits existierender Sicherheitsmaßnahmen. Bedrohungen sollten auf der Basis von Interviews, Erfahrungen (auch der Erfahrungen anderer Organisationen) und Katalogen festgestellt werden. Wichtig ist aber immer der Bezug zum Unternehmen und seinen Gegebenheiten.Schwachstellen, die von den Bedrohungen ausgenutzt werden können und Schaden an Werten oder sogar der Organisation verursachen können, sollten als Nächstes identifiziert werden. Dabei sollten nicht nur die Werte selbst betrachtet werden, sondern auch ihre Umgebung, d. h. die IT und die Netze genauso wie die Benutzer und die Arbeitsprozesse. Auch dazu können bestehende Kataloge bzw. Informationskanäle (z. B. CERT-Organisationen, Supplier) benutzt werden. Eine Einschätzung der spezifischen Gegebenheiten der Organisation ist jedoch unumgänglich. |
| • | Festlegung des Schadenspotenzials (SP) und der Eintrittswahrscheinlichkeit (EW)Jedes Risiko wird durch jeweils eine EW- und SP-Kategorie wie oben dargestellt beschrieben. |
| • | Feststellung und Bewertung des RisikosBildung von Risikoklassen durch Zusammenfassen möglicher SP/EW-Kombinationen, um die Bewertung und Behandlung zu vereinfachen |
3.2.4 Festlegung einer Risikostrategie
Optionen zur Risikobehandlung
Im diesem Schritt wird in einem sog. Risikobehandlungsplan für jede Risikoklasse eine bestimmte Vorgehensweise zur Risikobehandlung festgelegt und dokumentiert. Dabei gibt es folgende Möglichkeiten:
Im diesem Schritt wird in einem sog. Risikobehandlungsplan für jede Risikoklasse eine bestimmte Vorgehensweise zur Risikobehandlung festgelegt und dokumentiert. Dabei gibt es folgende Möglichkeiten:
| • | Reduzieren von RisikenDie Risiken werden durch geeignete IS-Maßnahmen reduziert. Dies kann durch die Reduktion der Eintrittswahrscheinlichkeit und/oder der Auswirkungen des Risikos geschehen. Zur Risikoreduktion können zum Beispiel Maßnahmen aus ISO/IEC 27002 oder dem IT-Grundschutz herangezogen werden. |
| • | Vermeiden von RisikenRisiken können durch organisatorische oder technische Veränderungen (Umstrukturierung, Systemwechsel, Aufgabe einer Tätigkeit etc.) vermieden werden. Es sollte geprüft werden, inwieweit durch diese Veränderungen neue Risiken entstehen. |
| • | Übertragen von RisikenRisiken können durch Outsourcing, Ressourcen-Sharing oder Abschluss entsprechender Versicherungen auf andere Instanzen übertragen werden – allerdings nicht zum Nulltarif. |
| • | Akzeptieren von RisikenEin Unternehmen kann Risiken auch akzeptieren, wenn sie oberhalb der festgelegten Akzeptanzschwelle liegen. Dies kann zum Beispiel der Fall sein, wenn alle anderen Risikobehandlungsoptionen mehr Kosten verursachen würden, als das Risiko rechtfertigt. Wichtig ist in solchen Fällen, dass die Akzeptanz eine bewusste Entscheidung ist, die von der Leitungsebene getragen und dokumentiert wird. |
Ressourcen/Restrisiko
Zur Umsetzung der Strategie müssen die notwendigen Ressourcen geplant und zur Verfügung gestellt werden. Neben den Kosten ist auch das verbleibende Restrisiko ein wesentliches Entscheidungskriterium, das die Unternehmensleitung berücksichtigen muss. Es muss ebenfalls bewertet und dokumentiert werden.
Zur Umsetzung der Strategie müssen die notwendigen Ressourcen geplant und zur Verfügung gestellt werden. Neben den Kosten ist auch das verbleibende Restrisiko ein wesentliches Entscheidungskriterium, das die Unternehmensleitung berücksichtigen muss. Es muss ebenfalls bewertet und dokumentiert werden.
3.2.5 Auswahl von Maßnahmen zur Risikobehandlung
Sie halten nun eine Auflistung von bewerteten IS-Risiken in den Händen, die sie über die Zuordnung zu einer Risikoklasse bereits mit einer grundsätzlichen Behandlungsstrategie verknüpft haben.
Nun geht es darum, im Rahmen dieser Behandlungsstrategie für jedes Risiko geeignete Maßnahmen auszuwählen, die Sie einerseits Ihrem angestrebten IS-Niveau näherbringen, andererseits aber auch Aspekte wie Kosten-Nutzen-Relation oder Praxistauglichkeit in geeigneter Weise berücksichtigen.
IS-Maßnahmen
Der Standard ISO/IEC 27001 stellt Ihnen dazu in 14 Themenbereichen insgesamt 114 generische IS-Maßnahmen in eher knapper Form bereit, die jeweils einem IS-Ziel zugeordnet sind. In der Regel müssen diese Maßnahmen von Ihnen an die individuelle Risikosituation angepasst werden. Dazu eignen sich als Unterstützung z. B. die ISO/IEC 27002 und weitere Standards aus der ISO 270xx-Familie, die ergänzende Umsetzungshinweise und Branchenspezifika enthalten.
Der Standard ISO/IEC 27001 stellt Ihnen dazu in 14 Themenbereichen insgesamt 114 generische IS-Maßnahmen in eher knapper Form bereit, die jeweils einem IS-Ziel zugeordnet sind. In der Regel müssen diese Maßnahmen von Ihnen an die individuelle Risikosituation angepasst werden. Dazu eignen sich als Unterstützung z. B. die ISO/IEC 27002 und weitere Standards aus der ISO 270xx-Familie, die ergänzende Umsetzungshinweise und Branchenspezifika enthalten.
Detaillierter und stärker strukturiert präsentieren sich die Anforderungen des IT-Grundschutz-Kompendiums. Innerhalb eines Schichtenmodells zur Funktionsorientierung sind Prozess- und Systembausteine angeordnet. Deren Anforderungen sind nach Schutzbedarfskategorien und Priorität gegliedert, konkreter ausgestaltet als in ISO 27001 und um detaillierte Umsetzungshinweise analog zu ISO 27002 ergänzt.
Methoden und Tools
Eine von vielen guten praxisorientierten Methoden zum Risikomangement ist OCTAVE, die auch als deutsche, ISO/IEC-27001-kompatible Version verfügbar ist (weitere Infos dazu: [8].
Eine von vielen guten praxisorientierten Methoden zum Risikomangement ist OCTAVE, die auch als deutsche, ISO/IEC-27001-kompatible Version verfügbar ist (weitere Infos dazu: [8].
3.2.6 Risikokommunikation, -überwachung, -überprüfung
Eine regelmäßige Kommunikation zwischen Entscheidungsträgern und den am RM-Prozess beteiligten Personen ist sehr wichtig, um ein kontinuierliches und aktuelles Risikomanagement zu ermöglichen. Sie sollte Informationen über Existenz, Auftreten, Wahrscheinlichkeit, Tragweite, Auswirkungen, Behandlungsmöglichkeiten und Akzeptanz von Risiken umfassen. Dazu müssen Risiken überwacht und ihre Bewertung muss ggf. angepasst werden.
Gründe für Anpassungen
Gründe für solche Anpassungen können z. B. sein:
Gründe für solche Anpassungen können z. B. sein:
| • | Veränderungen der Werte, Bedrohungen oder Schwachstellen, z. B. Austausch/Migration von RZ-Systemen oder -Infrastrukturen |
| • | neue Erkenntnisse zur Risikobewertung |
| • | Berücksichtigung der Wirksamkeit implementierter IS-Maßnahmen |
| • | Aufnahme neuer Geschäftsaktivitäten, z. B. Angebot von RZ-Services |
4 Normen und Standards zur RZ-Sicherheit
Hilfestellung bei Anforderungen, Hinweise und Verfahren
Bei der Planung und Gestaltung sicherer Rechenzentren kommt eine große Zahl von Sicherheitsstandards zum Einsatz. Sie stellen eine wichtige Hilfestellung für den verantwortlichen RZ-Manager dar, indem sie einerseits wichtige Anforderungen definieren und andererseits Hinweise und Verfahren zu deren Umsetzung bereithalten.
Bei der Planung und Gestaltung sicherer Rechenzentren kommt eine große Zahl von Sicherheitsstandards zum Einsatz. Sie stellen eine wichtige Hilfestellung für den verantwortlichen RZ-Manager dar, indem sie einerseits wichtige Anforderungen definieren und andererseits Hinweise und Verfahren zu deren Umsetzung bereithalten.
In diesem Abschnitt lernen Sie vor allem management- und prozessorientierte Standards kennen. Daneben existiert eine Fülle von system- bzw. produktorientierten Standards, insbesondere im Bereich der physischen RZ-Sicherheit, mit dem Ziel, die Sicherheitsqualität bestimmter Systeme/Komponenten zu erhöhen bzw. zu bewerten.
Eine tabellarische Übersicht relevanter Normen und Richtlinien zur physischen RZ-Sicherheit finden Sie in der beigefügten Arbeitshilfe. Dabei ist ggf. zu prüfen, ob sich für ein konkretes Thema zusätzliche europäische Normen etabliert haben.[
01750_a.docx]
01750_a.docx]4.1 Die Normenreihe ISO/IEC 27000 ff.
Um die ursprünglichen Kernelemente herum, die beiden Standards ISO/IEC 27001 und ISO/IEC 27002, ist eine Normenreihe ISO/IEC 27000 ff. mit dem Titel „Information technology – Security techniques – Information Security Management Systems” entstanden.
Zielsetzung der Standards
Die Standards dieser Normenreihe heißen derzeit ISO/IEC 27000 bis 27103,
Die Standards dieser Normenreihe heißen derzeit ISO/IEC 27000 bis 27103,
| • | beziehen sich auf die Anforderungen der ISO/IEC 27001, |
| • | spezifizieren in der Regel keine weiteren Anforderungen über die der ISO/IEC 27001 hinaus, |
| • | sondern tragen zum besseren Verständnis und zur praktischen Anwendbarkeit bei, |
| • | bieten direkte Unterstützung und detaillierte Hilfestellungen für die Implementierung des in ISO/IEC 27001 definierten PDCA-Prozesses und |
| • | sind prozessorientiert. |
Ergänzende Standards
Ergänzend sind weitere Kategorien von Standards vorgesehen:
Ergänzend sind weitere Kategorien von Standards vorgesehen:
| • | maßnahmenspezifische (Control Specific) Standards, die die Umsetzung der ISO/IEC 27002 auf Applikations- und Serviceebene unterstützen, |
| • | technologiespezifische (Technology Specific) Standards, die als technische IS-Standards für Applikations- und Systemkomponenten dienen. |
Eine Übersicht der zurzeit veröffentlichten bzw. geplanten Standards dieser Normenreihe finden Sie in der Arbeitshilfe. Weitere Informationen zu den ISO-Standards und ihrem aktuellen Bearbeitungsstand finden Sie unter: www.iso.org (s. a. Kap. 07359 ff.).
4.1.1 ISO/IEC 27001
Der Standard ISO/IEC 27001:2013 Information technology – Security techniques – Information security management systems – Requirements ist der erste internationale Standard zum IS-Management, der eine Auditierung und Zertifizierung eines ISMS ermöglicht (s. a. Kap. 07361).
Der Standard spezifiziert
| • | Anforderungen für Planung, Implementierung, Überwachung und Verbesserung eines ISMS (Normkapitel 4–10), |
| • | Referenzmaßnahmen und -ziele (Anhang A). |
Generische Anforderungen
Die Anforderungen sind generisch formuliert, sodass sie auf jede Organisation unabhängig von Art, Größe und Geschäftsprozessen anwendbar sind. Für Details zu den Anforderungen und abgeleiteten Maßnahmen wird auf weitere Standards der Normenreihe verwiesen.
Die Anforderungen sind generisch formuliert, sodass sie auf jede Organisation unabhängig von Art, Größe und Geschäftsprozessen anwendbar sind. Für Details zu den Anforderungen und abgeleiteten Maßnahmen wird auf weitere Standards der Normenreihe verwiesen.
Der Aufbau und kontinuierliche Betrieb eines ISMS als Prozess ist von zentraler Bedeutung für die IS einer Organisation und wird durch die ISO/IEC 27001 beschrieben.
Die Kompatibilität mit anderen Standards zu Managementsystemen (z. B. ISO 9001, ISO 14001, ISO 50001, ISO 22301, ISO 20000) unterstützt die Möglichkeit einheitlicher integrierter Managementsysteme im Unternehmen.
4.1.2 ISO/IEC 27002
Der Standard ISO/IEC 27002:2013 „Information technology – Security techniques – Code of practice for information security controls” (s. a. Kap. 07362) versteht sich als Leitfaden zum Management von Informationssicherheit. Sein Ziel ist es, ein praxisbezogenes Rahmenwerk für den Aufbau eines unternehmensweiten IS-Managements und für seine Verankerung in der Unternehmensorganisation zu definieren. Damit richtet er sich an Verantwortliche für IS im Unternehmen.
14 Control Clauses
Der Hauptteil des Standards (ab Kapitel 5) besteht aus den 14 Themenbereichen der ISO 27001 und den dort dargestellten 114 Controls. Die Nummerierung des Annex A aus ISO 27001 entspricht vollständig der Kapitelnummerierung der ISO 27002.
Der Hauptteil des Standards (ab Kapitel 5) besteht aus den 14 Themenbereichen der ISO 27001 und den dort dargestellten 114 Controls. Die Nummerierung des Annex A aus ISO 27001 entspricht vollständig der Kapitelnummerierung der ISO 27002.
Struktur der Maßnahmen
Die Beschreibung der Maßnahmen folgt dieser Struktur:
Die Beschreibung der Maßnahmen folgt dieser Struktur:
| • | Darstellung der Maßnahme mit Blick auf die Zielerreichung (Control) |
| • | ergänzende Informationen zur Implementierung (Implementation Guidance) |
| • | zusätzliche Informationen, z. B. zu Rahmenbedingungen, rechtlichen Aspekten etc. (Other Information) |
Die Maßnahmen der ISO/IEC 27002 orientieren sich an einer Baseline Security, also den Anforderungen eines normalen Schutzbedarfs, sind jedoch grundsätzlich nicht auf ein bestimmtes Sicherheitsniveau beschränkt. Der Standard geht – im Gegensatz zum IT-Grundschutz – in jedem Fall von der Durchführung einer individuellen Risikoanalyse aus.
4.1.3 ISO/IEC 27005
Methodenwahl dem Anwender überlassen
Der Standard ISO/IEC 27005 stellt Richtlinien für das IS-Risikomanagement auf der Basis von ISO/IEC 27001 zur Verfügung. Diese Richtlinien dienen als Anleitung; sie sind nicht bindend und nicht zertifizierungsrelevant. ISO/IEC 27005 beschreibt keine spezielle Methode für IS-Risikomanagement, sondern definiert erforderliche Komponenten. Die Methodenwahl ist Ihnen als Anwender überlassen.
Der Standard ISO/IEC 27005 stellt Richtlinien für das IS-Risikomanagement auf der Basis von ISO/IEC 27001 zur Verfügung. Diese Richtlinien dienen als Anleitung; sie sind nicht bindend und nicht zertifizierungsrelevant. ISO/IEC 27005 beschreibt keine spezielle Methode für IS-Risikomanagement, sondern definiert erforderliche Komponenten. Die Methodenwahl ist Ihnen als Anwender überlassen.
Ziel des Standards
Ziel des Standards ist es, die Umsetzung von IS im Unternehmen mit einem Risikomanagementprozess zu unterstützen (vgl. Abschnitt 3.2). Dieser Ansatz ist notwendig, damit relevante Risiken präzise identifiziert und in IS-Prozesse und -Maßnahmen übersetzt werden, die zu Ihrem Unternehmen passen.
Ziel des Standards ist es, die Umsetzung von IS im Unternehmen mit einem Risikomanagementprozess zu unterstützen (vgl. Abschnitt 3.2). Dieser Ansatz ist notwendig, damit relevante Risiken präzise identifiziert und in IS-Prozesse und -Maßnahmen übersetzt werden, die zu Ihrem Unternehmen passen.
Der Risikomanagementprozess nach ISO/IEC 27005 umfasst folgende Komponenten:
Festlegung des Kontextes (Context Establishment)
| • | Risikoabschätzung (Risk Assessment), unterteilt in
| ||||||
| • | Risikobehandlung (Risk Treatment) und Risikoakzeptanz (Risk Acceptance) | ||||||
| • | Risikokommunikation (Risk Communication), -überwachung (Risk Monitoring) und -überprüfung (Risk Review) |
4.2 BSI-Grundschutz
Unter dem Begriff BSI-Grundschutz sind derzeit u. a. folgende wesentlichen Komponenten zusammengefasst:
| • | BSI-Standards 200-{1,2,3}x sowie 100-4mit Empfehlungen zu Methoden, Prozessen Vorgehensweisen und Maßnahmen mit Bezug zur Informationssicherheit, |
| • | IT-Grundschutz-Kompendiumals modernisierte Fassung der früheren IT-Grundschutz-Kataloge. |
Trennung zwischen Methodik und Vorgehensweise
Damit existiert eine klare Trennung zwischen Methodik und Vorgehensweise als Inhalt der BSI-Standards sowie der Darstellung elementarer Gefährdungen und umfangreicher, gut strukturierter Bausteine mit differenzierten Anforderungskatalogen im IT-Grundschutz-Kompendium. Dies erleichtert Ihnen die Anwendung des IT-Grundschutzes.
Damit existiert eine klare Trennung zwischen Methodik und Vorgehensweise als Inhalt der BSI-Standards sowie der Darstellung elementarer Gefährdungen und umfangreicher, gut strukturierter Bausteine mit differenzierten Anforderungskatalogen im IT-Grundschutz-Kompendium. Dies erleichtert Ihnen die Anwendung des IT-Grundschutzes.
Das BSI stellt auf seinen Internetseiten umfangreiche Informationen zum BSI-Grundschutz kostenlos zur Verfügung [9].
Tipp:
Für hoch schutzbedürftige Bereiche wie ein RZ sollten die Anforderungen der Bausteine in jedem Fall auf Eignung überprüft und ggf. durch ergänzende Risikoanalysen/Maßnahmen angepasst werden.
Für hoch schutzbedürftige Bereiche wie ein RZ sollten die Anforderungen der Bausteine in jedem Fall auf Eignung überprüft und ggf. durch ergänzende Risikoanalysen/Maßnahmen angepasst werden.
4.2.1 BSI-Standards
BSI 200-1: Managementsysteme für Informationssicherheit (ISMS)
Der BSI-Standard 200-1 „Managementsysteme für Informationssicherheit (ISMS)” definiert allgemeine Anforderungen an ein Managementsystem für Informationssicherheit und zeigt die Zusammenhänge zu den Standards ISO/IEC 27001 und ISO/IEC 27002, zu denen er kompatibel ist. Er bietet Ihnen eine leicht verständliche, systematische Einführung und Anleitung, unabhängig davon, mit welcher Methode Sie die Anforderungen umsetzen möchten.
Zentrale Komponenten eines ISMS
Als zentrale Komponenten eines ISMS definiert BSI 200-1:
Als zentrale Komponenten eines ISMS definiert BSI 200-1:
| • | Managementprinzipien | ||||||
| • | Ressourcen | ||||||
| • | Mitarbeiter | ||||||
| • | Sicherheitsprozess mit den Bestandteilen
|
Sicherheitskonzept und -organisation sind Hilfsmittel zur Umsetzung der Sicherheitsstrategie und nutzen ihrerseits die Inhalte der übrigen BSI-Standards sowie des IT-Grundschutz-Kompendiums (vgl. folgende Abschnitte).
BSI 200-2: IT-Grundschutz-Methodik
Im BSI-Standard 100-2 „IT-Grundschutz-Methodik” wird Schritt für Schritt beschrieben, wie ein IS-Management und der Sicherheitsprozess auf der Basis von IT-Grundschutz in der Praxis aufgebaut und betrieben werden können.
Vorgehensweisen
Der Standard geht ausführlich darauf ein, wie ein Sicherheitskonzept Schritt für Schritt in der Praxis erstellt werden kann, wie angemessene Sicherheitsmaßnahmen ausgewählt werden können und was bei der Umsetzung des Sicherheitskonzepts zu beachten ist. Dabei wird zwischen den drei Vorgehensweisen
Der Standard geht ausführlich darauf ein, wie ein Sicherheitskonzept Schritt für Schritt in der Praxis erstellt werden kann, wie angemessene Sicherheitsmaßnahmen ausgewählt werden können und was bei der Umsetzung des Sicherheitskonzepts zu beachten ist. Dabei wird zwischen den drei Vorgehensweisen
| • | Basis-Absicherung |
| • | Standard-Absicherung |
| • | Kern-Absicherung |
unterschieden. Auch die Frage, wie Informationssicherheit im laufenden Betrieb aufrechterhalten und verbessert werden kann, wird beantwortet. Die Abbildung 3 verdeutlicht die einzelnen Aktivitäten bei der Erstellung eines Sicherheitskonzepts für die Standard-Absicherung nach BSI 200-2.
Erstellung eines Sicherheitskonzepts für Standard-Absicherung
BSI 200-2 unterstützt Sie bei der Umsetzung mit vielen Hinweisen, Hintergrundinformationen und Beispielen. Im Zusammenspiel mit dem IT-Grundschutz-Kompendium wird im Standard nicht nur erklärt, was gemacht werden sollte, sondern es werden auch konkrete Hinweise gegeben, wie eine Umsetzung (auch auf technischer Ebene) aussehen kann.
BSI 200-3: Risikoanalyse auf der Basis von IT-Grundschutz
Bei hohen oder sehr hohen Sicherheitsanforderungen
Das IT-Grundschutz-Kompendium enthält typischerweise Anforderungen für den normalen Schutzbedarf gemäß dem aktuellen Stand der Technik. Zu jedem Baustein werden darüber hinaus exemplarische Vorschläge für Anforderungen aufgeführt, die über das dem Stand der Technik entsprechende Schutzniveau hinausgehen und bei erhöhtem Schutzbedarf in Betracht gezogen werden sollten.
Das IT-Grundschutz-Kompendium enthält typischerweise Anforderungen für den normalen Schutzbedarf gemäß dem aktuellen Stand der Technik. Zu jedem Baustein werden darüber hinaus exemplarische Vorschläge für Anforderungen aufgeführt, die über das dem Stand der Technik entsprechende Schutzniveau hinausgehen und bei erhöhtem Schutzbedarf in Betracht gezogen werden sollten.
Generell sieht die Methodik des Standard BSI 200-2 vor, für Bereich mit hohen oder sehr hohen Sicherheitsanforderungen eine zusätzliche Risikoanalyse vorzunehmen. Dafür wurde als eine Möglichkeit zur Umsetzung der Standard BSI 200-3 „Risikoanalyse auf der Basis von IT-Grundschutz” erarbeitet. Diese Vorgehensweise bietet sich an, wenn Unternehmen bereits erfolgreich mit den IT-Grundschutz arbeiten und möglichst nahtlos eine ergänzende Risikoanalyse anschließen möchten.
Dafür kann es verschiedene Gründe geben:
| Mögliche Gründe | |
| • | Es besteht für einzelne Bereiche ein hoher oder sehr hoher Schutzbedarf. |
| • | Das Unternehmen betreibt wichtige Anwendungen oder Komponenten, die noch nicht in den IT-Grundschutz-Katalogen des BSI behandelt werden. |
| • | Die schutzbedürftigen Objekte werden in Einsatzszenarien (Umgebung, Anwendung) betrieben, die im Rahmen des IT-Grundschutzes nicht vorgesehen sind. |
Der Standard beschreibt detailliert den Schritt „Risikoanalyse” in obiger Abbildung. Die Vorgehensweise ist als Richtschnur zu verstehen. Sie bietet Ihnen eine vereinfachte Analyse von IT-Risiken mithilfe der in den IT-Grundschutz-Katalogen aufgeführten Gefährdungen an. Dabei werden Eintrittswahrscheinlichkeiten nur implizit bei der Ermittlung und Bewertung von Gefährdungen betrachtet. Es erfolgt keine separate Untersuchung von Bedrohungen, Schwachstellen und Risiken.
BSI 100-4: Notfallmanagement
Ziel
Das Ziel dieses Standards ist es, eine Methodik zur Etablierung und Aufrechterhaltung eines unternehmensweiten internen Notfallmanagements vorzustellen, um zu gewährleisten, „dass wichtige Geschäftsprozesse selbst in kritischen Situationen nicht oder nur temporär unterbrochen werden und die wirtschaftliche Existenz der Institution auch bei einem größeren Schadensereignis gesichert bleibt”.
Das Ziel dieses Standards ist es, eine Methodik zur Etablierung und Aufrechterhaltung eines unternehmensweiten internen Notfallmanagements vorzustellen, um zu gewährleisten, „dass wichtige Geschäftsprozesse selbst in kritischen Situationen nicht oder nur temporär unterbrochen werden und die wirtschaftliche Existenz der Institution auch bei einem größeren Schadensereignis gesichert bleibt”.
Methodik des BSI 100-4
Die Methodik des Standards basiert auf der im BSI-Standard 100-2 beschriebenen IT-Grundschutz-Vorgehensweise. Darüber hinaus stützt sich der BSI 100-4 auf etablierte internationale Standards, z. B.
Die Methodik des Standards basiert auf der im BSI-Standard 100-2 beschriebenen IT-Grundschutz-Vorgehensweise. Darüber hinaus stützt sich der BSI 100-4 auf etablierte internationale Standards, z. B.
| • | ISO 22301 und ISO 22313 – Business Continuity Management (s. Kap. 07342 und s. Kap. 07345) |
| • | Good Practice Guidelines (GPG) des BCI (Business Continuity Institute) [11] |
| • | ISO/IEC 27031 – Leitfaden für die Bereitschaft von Informations- und Kommunikationstechnologien für Business Continuity [12] (s. Kap. 07391) |
| • | ITIL-Prozess IT Service Continuity Management (ITSCM) |
Notfallmanagement
Unter Notfallmanagement wird ein Managementprozess verstanden, der das Ziel hat, „gravierende Risiken für eine Institution, die das Überleben gefährden, frühzeitig zu erkennen und Maßnahmen dagegen zu etablieren. … Das Notfallmanagement umfasst das geplante und organisierte Vorgehen, um die Widerstandsfähigkeit der (zeit-)kritischen Geschäftsprozesse einer Institution nachhaltig zu steigern, auf Schadensereignisse angemessen reagieren und die Geschäftstätigkeiten so schnell wie möglich wieder aufnehmen zu können”.
Unter Notfallmanagement wird ein Managementprozess verstanden, der das Ziel hat, „gravierende Risiken für eine Institution, die das Überleben gefährden, frühzeitig zu erkennen und Maßnahmen dagegen zu etablieren. … Das Notfallmanagement umfasst das geplante und organisierte Vorgehen, um die Widerstandsfähigkeit der (zeit-)kritischen Geschäftsprozesse einer Institution nachhaltig zu steigern, auf Schadensereignisse angemessen reagieren und die Geschäftstätigkeiten so schnell wie möglich wieder aufnehmen zu können”.
BCM
Das Notfallmanagement wird auch als Business Continuity Management (BCM) oder Betriebliches Kontinuitätsmanagement bezeichnet [13].
Das Notfallmanagement wird auch als Business Continuity Management (BCM) oder Betriebliches Kontinuitätsmanagement bezeichnet [13].
Der Standard beschreibt ausführlich einen Notfallmanagementprozess zusammen mit einem Managementsystem zu dessen Etablierung und Aufrechterhaltung.
Prozessphasen
Der Prozess besteht aus den Phasen:
Der Prozess besteht aus den Phasen:
| • | Initiierung des Notfallmanagements |
| • | Konzeption |
| • | Umsetzung des Notfallvorsorge-Konzepts |
| • | Notfallbewältigung |
| • | Test und Übungen |
| • | Aufrechterhaltung und kontinuierliche Verbesserung |
4.2.2 IT-Grundschutz-Kompendium
Standardisierte Sicherheitsanforderungen
Im IT-Grundschutz-Kompendium werden standardisierte Sicherheitsanforderungen für typische Geschäftsprozesse, Anwendungen und IT-Systeme in einzelnen Bausteinen beschrieben. Ziel ist es, durch geeignete Kombination von organisatorischen, personellen, infrastrukturellen und technischen Sicherheitsanforderungen ein Sicherheitsniveau zu erreichen, das für den jeweiligen Schutzbedarf angemessen und ausreichend ist, um geschäftsrelevante Informationen zu schützen. Darüber hinaus bilden die Anforderungen des IT-Grundschutz-Kompendiums nicht nur eine Basis für hochschutzbedürftige IT-Systeme und Anwendungen, sondern erläutern an vielen Stellen, wie ein höheres Sicherheitslevel erreichbar ist.
Im IT-Grundschutz-Kompendium werden standardisierte Sicherheitsanforderungen für typische Geschäftsprozesse, Anwendungen und IT-Systeme in einzelnen Bausteinen beschrieben. Ziel ist es, durch geeignete Kombination von organisatorischen, personellen, infrastrukturellen und technischen Sicherheitsanforderungen ein Sicherheitsniveau zu erreichen, das für den jeweiligen Schutzbedarf angemessen und ausreichend ist, um geschäftsrelevante Informationen zu schützen. Darüber hinaus bilden die Anforderungen des IT-Grundschutz-Kompendiums nicht nur eine Basis für hochschutzbedürftige IT-Systeme und Anwendungen, sondern erläutern an vielen Stellen, wie ein höheres Sicherheitslevel erreichbar ist.
Nach der Erläuterung von IT-Grundschutz, Schichtenmodell, Modellierung, Rollen sowie der Darstellung der 47 elementaren Gefährdungen folgt der wesentliche Inhalt des IT-Grundschutz-Kompendiums: die Bausteine.
Stand der Technik
Sie bilden den Stand der Technik ab, basierend auf den Erkenntnissen zum Zeitpunkt der Veröffentlichung. Die dort formulierten Anforderungen beschreiben, was generell umzusetzen ist, um mit geeigneten Sicherheitsmaßnahmen den Stand der Technik zu erreichen.
Sie bilden den Stand der Technik ab, basierend auf den Erkenntnissen zum Zeitpunkt der Veröffentlichung. Die dort formulierten Anforderungen beschreiben, was generell umzusetzen ist, um mit geeigneten Sicherheitsmaßnahmen den Stand der Technik zu erreichen.
IT-Grundschutz-Bausteine
Schichtenmodell
Die Anordnung der Bausteine folgt einem Schichtenmodell, s. Abbildung 2. Um die Auswahl zu erleichtern, sind die Bausteine zunächst aufgeteilt in prozess- und systemorientierte Bausteine.
Die Anordnung der Bausteine folgt einem Schichtenmodell, s. Abbildung 2. Um die Auswahl zu erleichtern, sind die Bausteine zunächst aufgeteilt in prozess- und systemorientierte Bausteine.
Prozess-Bausteine gelten in der Regel für sämtliche oder große Teile des Informationsverbunds gleichermaßen. System-Bausteine lassen sich in der Regel auf einzelne Objekte oder Gruppen von Objekten anwenden. Die Prozess- und System-Bausteine bestehen wiederum aus weiteren Teilschichten.
Aufbau
Die Bausteine enthalten jeweils eine Beschreibung der betrachteten Komponente, Vorgehensweisen und IT-Systeme, gefolgt von einem kurzen Überblick über spezifische Gefährdungen sowie konkreten Anforderungen, um die Komponente abzusichern. Die Bausteine sind in die folgenden Schichten gruppiert:
Die Bausteine enthalten jeweils eine Beschreibung der betrachteten Komponente, Vorgehensweisen und IT-Systeme, gefolgt von einem kurzen Überblick über spezifische Gefährdungen sowie konkreten Anforderungen, um die Komponente abzusichern. Die Bausteine sind in die folgenden Schichten gruppiert:
Prozess-Bausteine
| ISMS | Sicherheitsmanagement |
| ORP | Organisation und Personal |
| CON | Konzepte und Vorgehensweisen |
| OPS | Betrieb |
| DER | Detektion & Reaktion |
System-Bausteine
| APP | Anwendungen |
| SYS | IT-Systeme |
| IND | Industrielle IT |
| NET | Netze und Kommunikation |
| INF | Infrastruktur |
Gefährdungslage
Der Aufbau jedes Bausteins ist identisch. Nach Zielsetzung und Abgrenzung wird in Kapitel Gefährdungslage (2) dargestellt, welche spezifische Bedrohungen und Schwachstellen für den Baustein von besonderer Bedeutung sind.
Der Aufbau jedes Bausteins ist identisch. Nach Zielsetzung und Abgrenzung wird in Kapitel Gefährdungslage (2) dargestellt, welche spezifische Bedrohungen und Schwachstellen für den Baustein von besonderer Bedeutung sind.
Anforderungen
Auf die spezifischen Gefährdungen folgen die Anforderungen. Diese sind in drei Kategorien gegliedert:
Auf die spezifischen Gefährdungen folgen die Anforderungen. Diese sind in drei Kategorien gegliedert:
| • | Basis- und |
| • | Standard-Anforderungen sowie |
| • | Anforderungen bei erhöhtem Schutzbedarf |
Basis-Anforderungen müssen vorrangig umgesetzt werden, da sie mit geringem Aufwand den größtmöglichen Nutzen erzielen. Gemeinsam mit den Basis-Anforderungen erfüllen die Standard-Anforderungen den Stand der Technik und adressieren den normalen Schutzbedarf. Ergänzend dazu bieten die Bausteine des IT-Grundschutz-Kompendiums Vorschläge für Anforderungen bei erhöhtem Schutzbedarf.
In den Bausteinen werden die Prüfaspekte in den Anforderungen entspr. RFC 2119 unter Nutzung der Modalverben MUSS und SOLLTE sowie der zugehörigen Verneinungen formuliert, um die jeweiligen Anforderungen eindeutig zu kennzeichnen.
Referenzierung
Zur Referenzierung sind die Anforderungen bausteinübergreifend eindeutig nummeriert, z. B. SYS.3.4.A2. Über dieses Schema wird zunächst die Schicht (im Beispiel „SYS”) benannt, dann die Nummern der jeweiligen Teilschichten und des Bausteins (im Beispiel „3.4”) und schließlich die Anforderung selbst (im Beispiel „A2”). Gibt es passende Umsetzungshinweise, trägt die dort aufgeführte Maßnahme zu einer Anforderung „A” die gleiche Nummer mit einem vorangestellten Buchstaben „M”, im Beispiel also „SYS.3.4.M2”.
Zur Referenzierung sind die Anforderungen bausteinübergreifend eindeutig nummeriert, z. B. SYS.3.4.A2. Über dieses Schema wird zunächst die Schicht (im Beispiel „SYS”) benannt, dann die Nummern der jeweiligen Teilschichten und des Bausteins (im Beispiel „3.4”) und schließlich die Anforderung selbst (im Beispiel „A2”). Gibt es passende Umsetzungshinweise, trägt die dort aufgeführte Maßnahme zu einer Anforderung „A” die gleiche Nummer mit einem vorangestellten Buchstaben „M”, im Beispiel also „SYS.3.4.M2”.
Weitere Informationen
Weiterführende Informationen in Kapitel 4 sowie eine Kreuzreferenztabelle zu elementaren Gefährdungen in Kapitel 5 beschließen die Darstellung eines Bausteins.
Weiterführende Informationen in Kapitel 4 sowie eine Kreuzreferenztabelle zu elementaren Gefährdungen in Kapitel 5 beschließen die Darstellung eines Bausteins.
HV-Kompendium des BSI
Hochverfügbarkeit
Als Ergänzung zum IT-Grundschutz für Hochverfügbarkeitslösungen stellt das BSI mit dem HV-Kompendium Instrumente zur Verfügung, die bei der Identifikation kritischer Geschäftsprozesse und der Ermittlung ihrer Qualitätsanforderungen ansetzen und daraus Vorschläge für ein anforderungskonformes Service-Design ableiten. Neben einem Kanon von verfügbarkeitsoptimierten HV-Architekturen werden geeignete IT-Prozesse definiert, die eine IT-Service-Optimierung im Hinblick auf hohe und höchste Verfügbarkeit gewährleisten. Zur Zielkontrolle werden Indikatoren eingeführt, die mit dem Verfügbarkeitsaspekt korrelieren und das Reifegradmodell für die Bewertung und Steuerung ergänzen.
Als Ergänzung zum IT-Grundschutz für Hochverfügbarkeitslösungen stellt das BSI mit dem HV-Kompendium Instrumente zur Verfügung, die bei der Identifikation kritischer Geschäftsprozesse und der Ermittlung ihrer Qualitätsanforderungen ansetzen und daraus Vorschläge für ein anforderungskonformes Service-Design ableiten. Neben einem Kanon von verfügbarkeitsoptimierten HV-Architekturen werden geeignete IT-Prozesse definiert, die eine IT-Service-Optimierung im Hinblick auf hohe und höchste Verfügbarkeit gewährleisten. Zur Zielkontrolle werden Indikatoren eingeführt, die mit dem Verfügbarkeitsaspekt korrelieren und das Reifegradmodell für die Bewertung und Steuerung ergänzen.
Vier Bände
Das Kompendium ist in vier Bänden strukturiert:
Das Kompendium ist in vier Bänden strukturiert:
| Band G | beschreibt die Ansätze für eine Analyse kritischer Geschäftsprozesse, für das Design hochverfügbarer IT-Services und für eine IT-Steuerung auf der Grundlage von Reifegradmodellen. |
| Band B | liefert Bausteine mit Architekturen und Maßnahmenempfehlungen zur Realisierung hoher Verfügbarkeit. |
| Band M | stellt Maßnahmenempfehlungen komprimiert in einem Maßnahmenkatalog dar. Die Maßnahmenempfehlungen werden um ein Reifegradmodell ergänzt, das die Grundlage für die Bewertung, Steuerung und Optimierung der IT-Prozesse liefert. Die Maßnahmenempfehlungen enthalten Hochverfügbarkeitsmaßnahmen in diversen Bereichen (Meta-Ebene, HV-Organisation, Netzwerk, Cluster, Server, Speicher, IT-Dienste, Datenbanken, Software, Überwachung und Infrastruktur). |
| Band AH | umfasst Architekturmodelle, Steuerungsinstrumente und weitere Hilfsmittel. |
VK 0 bis 5
Das Kompendium enthält u. a. eine Definition von Verfügbarkeitsklassen und deren Zuordnung zur Anwendbarkeit des IT-Grundschutzes wie nachfolgend dargestellt.
Das Kompendium enthält u. a. eine Definition von Verfügbarkeitsklassen und deren Zuordnung zur Anwendbarkeit des IT-Grundschutzes wie nachfolgend dargestellt.
Tabelle 2: Typische Verfügbarkeitsklassen und ihre Ausfallzeiten ( [4])
Verfügbarkeitsklasse | Bezeichnung | Minimale Verfügbarkeit | Nichtverfügbarkeit | Ausfallzeit pro Monat | Ausfallzeit pro Jahr |
VK 0 | Standard-IT-System ohne Anforderungen an die Verfügbarkeit | ˜95 % | ˜5 % | 1 Tag | Mehrere Tage |
VK 1 | Standard-Sicherheit nach IT-Grundschutz bei normalem Verfügbarkeitsbedarf | 99 % | 1 % | < 8 h | < 88 h |
VK 2 | Standard-Sicherheit nach IT-Grundschutz bei erhöhtem Verfügbarkeitsbedarf | 99,9 % | 0,1 % | < 44 min | < 9 h |
VK 3 | Hochverfügbar nach IT-Grundschutz für spezifische IT-Ressourcen; BSI-Standard 100-3 | 99,99 % | 0,01 % | < 5 min | < 53 min |
VK 4 | Höchstverfügbar | 99,999 % | 0,001 % | < 26 s | < 6 min |
VK 5 | Desaster-Tolerant | max. Verfügbarkeit | 0 | 0 | 0 |
4.3 DIN EN 50600-x
Motivation
Mit der Normenreihe DIN EN 50600 – Einrichtungen und Infrastrukturen von Rechenzentren – werden erstmals sämtliche Aspekte im Lebenszyklus eines Rechenzentrums in einer Norm berücksichtigt (s. a. Kap. 07470). Damit bietet sie allen mit der Auslegung, Planung, Beschaffung, Integration, dem Betrieb und der Instandhaltung von Einrichtungen und Infrastrukturen innerhalb von Rechenzentren befassten Parteien einen ganzheitlichen Ansatz zur Planung und zum Betrieb eines dem Stand der Technik entsprechenden, zukunftssicheren Rechenzentrums.
Mit der Normenreihe DIN EN 50600 – Einrichtungen und Infrastrukturen von Rechenzentren – werden erstmals sämtliche Aspekte im Lebenszyklus eines Rechenzentrums in einer Norm berücksichtigt (s. a. Kap. 07470). Damit bietet sie allen mit der Auslegung, Planung, Beschaffung, Integration, dem Betrieb und der Instandhaltung von Einrichtungen und Infrastrukturen innerhalb von Rechenzentren befassten Parteien einen ganzheitlichen Ansatz zur Planung und zum Betrieb eines dem Stand der Technik entsprechenden, zukunftssicheren Rechenzentrums.
Design-Ansatz
Die Norm verfolgt einen geschäftsorientierten Design-Ansatz mit den Komponenten
Die Norm verfolgt einen geschäftsorientierten Design-Ansatz mit den Komponenten
| • | Geschäftsrisikoanalyse |
| • | Betriebskostenanalyse |
| • | Energieeffizienz-Maßstäbe |
| • | Lokale Regeln und Vorschriften |
Leitlinien
Daraus werden Leitlinien für das RZ-Design abgeleitet in Form von
Daraus werden Leitlinien für das RZ-Design abgeleitet in Form von
| • | Verfügbarkeitsklassen |
| • | Schutzklassen |
| • | Betriebsprozessen |
| • | Befähigung zur Energieeffizienz |
Diese Leitlinien berücksichtigen wichtige Aspekte zur RZ-Sicherheit. Damit schafft die EN 50600 Transparenz und Sicherheit für RZ-Planer, -Errichter, -Betreiber und -Dienstleister. Darüber hinaus erhalten RZ-Nutzer eine nachvollziehbare Aussage über die Normenkonformität des von ihnen genutzten Rechenzentrums.
4.4.1 ITIL: die Kurzvorstellung
Sofern Ihr Unternehmen als IT-Dienstleister am Markt agiert oder auch im Innenverhältnis Wert auf ein effizientes IT Service Management mit entsprechenden Strategie-, Planungs- und Betriebsprozessen legt, sind Sie sicher bereits mit ITIL in Berührung gekommen.
Die IT Infrastructure Library (ITIL) ist der De-facto-Standard zum IT Service Management mit dem Ziel, ein umfassendes Prozessmodell für die effiziente Planung und den Betrieb von IT Services auf der Basis von Best Practices zur Verfügung zu stellen. ITIL wurde Ende der 80er-Jahre von der britischen Regierung entwickelt und ist weiterhin Eigentum des Office of Government Commerce (OGC). Weiterentwicklung und Verbreitung erfolgen zusammen mit Herstellern und Anwendern, z. B. durch das IT Service Management Forum [14]. Eine Zertifizierung von Personen ist möglich.
ITIL v2
Im ITIL-Framework der Version 2 standen vor allem die Prozessbeschreibungen zu Strategie, Planung und Betrieb von IT Services im Mittelpunkt. Daraus resultierten u. a. je fünf Planungsprozesse (Service Delivery), Betriebsprozesse (Service Support) sowie der Prozess Security Management.
Im ITIL-Framework der Version 2 standen vor allem die Prozessbeschreibungen zu Strategie, Planung und Betrieb von IT Services im Mittelpunkt. Daraus resultierten u. a. je fünf Planungsprozesse (Service Delivery), Betriebsprozesse (Service Support) sowie der Prozess Security Management.
ITIL v3
Die ITIL-Version 3 (ITIL v3), seit März 2007 verfügbar, vollzog u. a. einen wichtigen Strukturwechsel, indem sich die Inhalte nun am Lebenszyklus des IT Service orientieren und wesentlich einheitlicher und übersichtlicher dokumentiert sind.
Die ITIL-Version 3 (ITIL v3), seit März 2007 verfügbar, vollzog u. a. einen wichtigen Strukturwechsel, indem sich die Inhalte nun am Lebenszyklus des IT Service orientieren und wesentlich einheitlicher und übersichtlicher dokumentiert sind.
Die fünf Bücher entsprechend dem definierten Service Lifecycle sind:
| • | Service Strategy |
| • | Service Design |
| • | Service Transition |
| • | Service Operation |
| • | Continual Service Improvement |
Bestandteil des Buchs Service Design sind auch die für RZ-Sicherheit wichtigen Prozesse
| • | IT Service Continuity Management (ITSCM) und |
| • | Information Security Management (ISM). |
Der ISM-Prozess orientiert sich stark an der bereits vorgestellten ISO 27001.
Bei der Weiterentwicklung von ITIL zur v3 standen neben dem Lebenszyklusmodell folgende Aspekte im Vordergrund:
| • | stärkere Ausrichtung auf den Businessnutzen von IT Services |
| • | Unterstützung von Compliance-Anforderungen (SOX, Basel II etc.) |
| • | Grundlage für Balanced Scorecard |
| • | Qualitätsmanagement auf der Basis des Deming Quality Cycle (ISO 9001) |
| • | Harmonisierung mit etablierten Standards (z. B. ISO/IEC 27001, ISO/IEC 20000) |
ITIL 2011 Edition
Ende Juli 2011 wurde die ITIL 2011 Edition veröffentlicht. Sie enthält mehr als 500 verarbeitete Verbesserungsvorschläge, die seit Erscheinen der ITIL v3 von Anwendern und Trainingsorganisationen eingereicht wurden und vor allem der Fehlerreduzierung, Übersichtlichkeit und Konsistenz der Darstellung zugutekamen. Auf die Versionsangabe wird in Zukunft verzichtet. Die Gültigkeit von ITIL-v3-Zertifikaten bleibt unverändert bestehen.
Ende Juli 2011 wurde die ITIL 2011 Edition veröffentlicht. Sie enthält mehr als 500 verarbeitete Verbesserungsvorschläge, die seit Erscheinen der ITIL v3 von Anwendern und Trainingsorganisationen eingereicht wurden und vor allem der Fehlerreduzierung, Übersichtlichkeit und Konsistenz der Darstellung zugutekamen. Auf die Versionsangabe wird in Zukunft verzichtet. Die Gültigkeit von ITIL-v3-Zertifikaten bleibt unverändert bestehen.
ITIL orientiert sich an dem durch IT-Service-Leistungen erbrachten wirtschaftlichen Mehrwert für den Kunden. Dabei werden die notwendigen Maßnahmen zu ihrer Planung, Erbringung, Unterstützung und Effizienzoptimierung als relevante Faktoren zur Erreichung der Geschäftsziele eines Unternehmens betrachtet.
ITIL 4
Die aktuelle ITIL Version 4 – wurde im Februar 2019 veröffentlicht. Diese erste umfangreiche Überarbeitung des ITIL-Frameworks seit 2011 geht vor allem auf die neuesten Trends aus den Bereichen Softwareentwicklung und IT-Betrieb ein.
Die aktuelle ITIL Version 4 – wurde im Februar 2019 veröffentlicht. Diese erste umfangreiche Überarbeitung des ITIL-Frameworks seit 2011 geht vor allem auf die neuesten Trends aus den Bereichen Softwareentwicklung und IT-Betrieb ein.
Darüber hinaus wurden die bestehenden Prozessbeschreibungen beibehalten, aber mit mehr Entscheidungsspielraum für den Anwender bei der Entwicklung individueller Prozesse versehen, inkl. neuer Inhalte, um sicherzustellen, dass die Anwender die wichtigen Prinzipien und Konzepte im Service Management besser verstehen. Zentrale Begriffe sind z. B. „Mehrwert” und „erwünschte Ergebnisse aus Kundensicht”. Der neue ITIL-Fokus liegt vor allem auf gesundem Pragmatismus bei der Anwendung des Frameworks. Außerdem enthält die neue ITIL-Edition auch Ratschläge zur Integration von ITIL mit anderen Frameworks und Methoden, wie z. B. DevOps, Lean und Agile.
Qualifizierung und Zertifizierung
Im Rahmen von ITIL ist eine Qualifizierung und Zertifizierung von Personen möglich. Typische Qualifikationsstufen sind: Foundation, Expert, Practitioner.
Im Rahmen von ITIL ist eine Qualifizierung und Zertifizierung von Personen möglich. Typische Qualifikationsstufen sind: Foundation, Expert, Practitioner.
Unternehmen, die die ITIL-Richtlinien im IT Service Management befolgen, können eine Zertifizierung nach ISO/IEC 20000 anstreben. Ein Rechenzentrum nimmt typischerweise die Rolle einer Serviceorganisation wahr, indem es interne wie externe Kunden mit Dienstleistungen einer definierten Qualität und Wirtschaftlichkeit bedient. Diese Dienste sollen dann auf Kundenseite einen spezifischen Mehrwert generieren. Daher ist der Aufbau eines IT Service Management nach ITIL im RZ-Bereich sehr zu empfehlen. In vielen Ausschreibungen wird dessen Nachweis in Form eines ISO-20000-Zertifikats bereits vorausgesetzt. Darüber hinaus vereinfacht eine Prozessstruktur nach ITIL auch die Abnahme nicht direkt verwandter Audits, z. B. Compliance Audits des Sarbanes-Oxley Act.
Für die Realisierung der erforderlichen RZ-Sicherheit leisten bestehende und effizient kooperierende ITIL-Prozesse einen wesentlichen Beitrag, da so viele IS-Aufgaben durch bereits bestehende Verfahren und Zuständigkeiten mit geringem Mehraufwand realisiert werden können.
4.4.2 Information Security Management nach ITIL
Im Sinne der oben formulierten ITIL-Philosophie betrachtet auch der Prozess Information Security Management (ISM) das Thema aus der Sicht der Gewährleistung einer nutzenorientierten Beziehung zwischen Kunde und IT-Dienstleister, indem anforderungsgerechte, kostengünstige und wohl definierte IT Services bereitgestellt werden.
ITIL-Prozess ISM
Die Vereinbarung solcher IT Services erfolgt üblicherweise in Service Level Agreements (SLA), in denen alle relevanten technischen, organisatorischen und finanziellen Serviceaspekte möglichst in messbaren Größen im Sinne eines Vertrags beschrieben werden. Dies ermöglicht eine definierte und nachweisbare Servicequalität mit der Möglichkeit einer gezielten und bedarfsgerechten Anpassung, falls erforderlich.
Die Vereinbarung solcher IT Services erfolgt üblicherweise in Service Level Agreements (SLA), in denen alle relevanten technischen, organisatorischen und finanziellen Serviceaspekte möglichst in messbaren Größen im Sinne eines Vertrags beschrieben werden. Dies ermöglicht eine definierte und nachweisbare Servicequalität mit der Möglichkeit einer gezielten und bedarfsgerechten Anpassung, falls erforderlich.
Zu diesen Serviceaspekten gehört auch die Gewährleistung der erforderlichen Vertraulichkeit, Integrität und Verfügbarkeit für alle am Service beteiligten Informationen und Systeme.
Aufgaben
Der ITIL-Prozess ISM hat damit folgende Aufgaben:
Der ITIL-Prozess ISM hat damit folgende Aufgaben:
| 1. | Erfüllung von Sicherheitsanforderungen an IT Services durch Gewährleistung des in den SLAs definierten Grades an Vertraulichkeit, Integrität und Verfügbarkeit |
| 2. | Planung proaktiver und reaktiver Maßnahmen |
| 3. | Ergänzung der übrigen ITIL-Prozesse um sicherheitsrelevante Prozessaktivitäten und Sicherheitsmaßnahmen gemäß ISO/IEC 27002 |
| 4. | Koordination und Überwachung aller sicherheitsrelevanten Aktivitäten |
Aus den dargestellten Aufgaben wird deutlich:
| • | ITIL will ganz im Sinne der Best Practices das ISM-Rad nicht neu erfinden, sondern adaptiert bewährte Verfahren und Maßnahmen des IS Managements auf die speziellen Gegebenheiten des IT Service Management. |
Voraussetzungen
Zur vollen Entfaltung seiner Stärken benötigt der ITIL-ISM-Prozess in Ihrem Unternehmen zwei wichtige Voraussetzungen:
Zur vollen Entfaltung seiner Stärken benötigt der ITIL-ISM-Prozess in Ihrem Unternehmen zwei wichtige Voraussetzungen:
| • | Existenz einer prozess- und Service-Level-orientierten IT-Organisation |
| • | Integration aller relevanten Sicherheitsanforderungen in die SLAs der beteiligten IT Services |
4.4.3 ISO/IEC 20000
ISO/IEC 20000
Der Standard ISO/IEC 20000 hat, genau wie ISO/IEC 27001, seine Wurzeln in einem British Standard. Als BS 15000 wurde er entwickelt und dient als messbarer Qualitätsstandard für das IT Service Management (ITSM). Dazu werden die notwendigen generischen Prozesse spezifiziert, die eine Organisation etablieren muss, um IT Services in definierter Qualität bereitstellen und managen zu können. Die Prozessbeschreibungen orientieren sich an ITIL.
Der Standard ISO/IEC 20000 hat, genau wie ISO/IEC 27001, seine Wurzeln in einem British Standard. Als BS 15000 wurde er entwickelt und dient als messbarer Qualitätsstandard für das IT Service Management (ITSM). Dazu werden die notwendigen generischen Prozesse spezifiziert, die eine Organisation etablieren muss, um IT Services in definierter Qualität bereitstellen und managen zu können. Die Prozessbeschreibungen orientieren sich an ITIL.
Eine Reihe von Kurzbeiträgen bietet Ihnen einen ausführlichen Überblick über die einzelnen Teile von ISO/IEC 20000 (s. Kap. 07301 ff.).
4.5 COBIT
EGIT Framework
Die von der Information Systems Audit and Control Association (ISACA) spezifizierten Control Objectives for Information and related Technology (COBIT) bilden das international anerkannte Framework zur IT Governance mit Namen „Enterprise Governance of Information Technology (EGIT) ”. COBIT stellt ein Modell zum Management IT-gestützter Geschäftsprozesse bereit, das eine Vielzahl von Sicherheits- und Kontrollanforderungen etablierter Standards und Methoden der IT integriert hat (u. a. ISO, ITSEC, ITIL, Common Criteria u. v. a.).
Die von der Information Systems Audit and Control Association (ISACA) spezifizierten Control Objectives for Information and related Technology (COBIT) bilden das international anerkannte Framework zur IT Governance mit Namen „Enterprise Governance of Information Technology (EGIT) ”. COBIT stellt ein Modell zum Management IT-gestützter Geschäftsprozesse bereit, das eine Vielzahl von Sicherheits- und Kontrollanforderungen etablierter Standards und Methoden der IT integriert hat (u. a. ISO, ITSEC, ITIL, Common Criteria u. v. a.).
COBIT stellt ein universell anwendbares Kontrollumfeld für die IT bereit, das Sicherheitsaspekte mit einschließt. Darüber hinaus umfasst COBIT Mechanismen, um die Vollständigkeit und Effektivität eines solchen Kontrollumfelds zur Begrenzung der entstehenden Risiken prüfen zu können. Die COBIT-Zielgruppen umfassen sowohl das Management als auch Prüfer und Prozess- oder IT-Verantwortliche. COBIT ist zurzeit in der Version 2019 verfügbar.
4.6.1 Sarbanes-Oxley Act
SOX
Der Sarbanes-Oxley Act of 2002 (SOX) ist ein US-Bundesgesetz, das als Reaktion auf Bilanzskandale von Unternehmen wie Enron oder WorldCom die Verlässlichkeit der Berichterstattung von Unternehmen, die den öffentlichen Kapitalmarkt der USA in Anspruch nehmen, verbessern soll. Es hat nicht nur Auswirkungen auf Finanzdaten, sondern fordert auch die Sicherheit im IT-Bereich. Das Gesetz gilt für alle an amerikanischen Börsen sowie für US-ausländische Unternehmen, die eine an einer amerikanischen Börse notierte Mutter- oder Tochtergesellschaft haben.
Der Sarbanes-Oxley Act of 2002 (SOX) ist ein US-Bundesgesetz, das als Reaktion auf Bilanzskandale von Unternehmen wie Enron oder WorldCom die Verlässlichkeit der Berichterstattung von Unternehmen, die den öffentlichen Kapitalmarkt der USA in Anspruch nehmen, verbessern soll. Es hat nicht nur Auswirkungen auf Finanzdaten, sondern fordert auch die Sicherheit im IT-Bereich. Das Gesetz gilt für alle an amerikanischen Börsen sowie für US-ausländische Unternehmen, die eine an einer amerikanischen Börse notierte Mutter- oder Tochtergesellschaft haben.
SOX und RZ-Sicherheit
Im Rahmen von SOX müssen Unternehmensprozesse beschrieben, definiert und Kontrollverfahren festgelegt werden, die das Risiko eines falschen Bilanzausweises minimieren sollen. Insbesondere in der Section 404 werden umfangreiche Anforderungen an ein internes Risikomanagementsystem gestellt. Dazu gehört auch die Existenz eines umfassenden ISMS! SOX verweist explizit auf etablierte Best Practices wie ISO 27001 und verlangt die Umsetzung der Sicherheitsziele Vertraulichkeit, Integrität und Verfügbarkeit sowie eine umfassende Dokumentation der IT-Infrastruktur.
Im Rahmen von SOX müssen Unternehmensprozesse beschrieben, definiert und Kontrollverfahren festgelegt werden, die das Risiko eines falschen Bilanzausweises minimieren sollen. Insbesondere in der Section 404 werden umfangreiche Anforderungen an ein internes Risikomanagementsystem gestellt. Dazu gehört auch die Existenz eines umfassenden ISMS! SOX verweist explizit auf etablierte Best Practices wie ISO 27001 und verlangt die Umsetzung der Sicherheitsziele Vertraulichkeit, Integrität und Verfügbarkeit sowie eine umfassende Dokumentation der IT-Infrastruktur.
Die Prüfung von Unternehmen erfolgt nach Kriterien, die im Wesentlichen auf COBIT basieren. Daher ist die Kombination von ISO 27001 und COBIT zur Erfüllung der SOX-Anforderungen sicher keine schlechte Wahl!
SOX-verpflichtete Unternehmen, die ihre IT ganz oder teilweise ausgelagert haben, müssen ihrer Gesamtverantwortung durch Prüfung der beteiligten Service Provider (z. B. Service-Rechenzentrum) nach SAS 70 (vgl. Abschnitt 4.5.2) gerecht werden!
In diesem Fall prüfen entweder die Wirtschaftsprüfer des Kunden beim Service Provider, oder – viel effizienter! – dieser lässt die Prüfung in Eigenregie für seine gesamte Organisation durchführen und erwirbt damit ein SAS-70-Zertifikat, das für alle Kunden gilt. Der Bericht des Wirtschaftsprüfers darf nicht älter als sechs Monate ab Zeitpunkt des Jahresabschlusses des Kunden sein. SOX-Prüfungen müssen daher praktisch zweimal jährlich durchgeführt werden.
4.6.2 ISAE 3402
Der International Standard on Assurance Engagements 3402, abgekürzt als ISAE 3402, ist ein von der International Federation of Accountants (IFAC) veröffentlichter internationaler Prüfungsstandard, in dem die Prüfung eines Internen Kontrollsystems (IKS) bei einem Dienstleistungsunternehmen inklusive Berichterstattung durch einen Wirtschaftsprüfer geregelt ist. Er ist insbesondere relevant für die Prüfung von Service Providern, die z. B. Hosting- oder Outsourcing-Aufgaben für andere Unternehmen übernehmen, da deren Auftraggeber im Einzelfall diese Prüfberichte benötigen.
ISAE 3402 löst den früheren US-Standard SAS 70 ab und ist international anerkannt. Der direkte Nachfolger des SAS 70, der auch die US-amerikanische Version des ISAE 3402 dargestellt, heißt SSAE 16. Die Unterschiede zu ISAE 3402 sind nur gering. In Deutschland wurde daraus der Prüfungsstandard IDW PS 951 als Anpassung der Anforderungen an die deutschen Prüfungsvorschriften entwickelt. Dieser geht stellenweise über die Anforderungen des ISAE 3402 hinaus.
Quellen
1
BITKOM (Hrsg.): Betriebssicheres Rechenzentrun, Leitfaden, Eigenverlag, Berlin 2013www.bitkom.org/Bitkom/Publikationen/Betriebssicheres-Rechenzentrum.html
2
BITKOM, DIN (Hrsg.): Kompass Informationssicherheit und Datenschutz Webkatalogwww.kompass-sicherheitsstandards.de
4
Bundesamt für Sicherheit in der Informationstechnik (BSI): Hochverfügbarkeits(HV)-Kompendium, V1.6www.bsi.bund.de/DE/Themen/Sicherheitsberatung/Hochverfuegbarkeit/HVKompendium/hvkompendium_node.html
12
ISO/IEC 27031:2011 – Informationstechnik – IT-Sicherheitsverfahren – Leitfaden für die Bereitschaft von Informations- und Kommunikationstechnologien für Business Continuity (Englischer Titel: Guidelines for information and communication technology readiness for business continuity)
13
Rössing, von, R.: Betriebliches Kontinuitätsmanagement, Mitp-Verlag, 2005
15
Bundesministerium des Innern: Schutz Kritischer Infrastrukturen: Basisschutzkonzept – Empfehlungen für Unternehmen. www.kritis.bund.de/DE/AufgabenundAusstattung/KritischeInfrastrukturen/Publikationen/Basisschutzkonzept_BMI.html
