Mehr denn je ist uns bewusst: Informationen sind Werte. Wir besitzen sie aus unterschiedlichen Gründen - weil wir für ihre Verwahrung oder Verarbeitung Verantwortung tragen, weil wir aus ihnen einen Vorteil ziehen, weil ihre Kenntnis uns vor Schaden bewahrt und noch viel mehr. Gehen sie uns verloren, werden sie gestohlen, sind sie falsch oder einfach nicht auffindbar, wenn wir sie benötigen, dann erleiden wir Schaden - die Palette reicht von geringfügig bis existenzbedrohend.

Das ist zwar nichts Neues, dennoch ist es der zentrale und immer wichtiger werdende Aspekt der Informationssicherheit. Niemand bestreitet das, aber wie viel sind wir bereit, in den Schutz unserer Informationen zu investieren und was ist im speziellen Fall die optimale Lösung? Hier wird es schon differenzierter, das zeigen entsprechende Umfragen immer wieder.

Information stellt heute sowohl für die öffentliche Verwaltung als auch für Organisationen der Privatwirtschaft einen wichtigen Wert dar. Die Erfüllung der Geschäftsprozesse ist ohne die Korrektheit, Vertraulichkeit und Verfügbarkeit der Informationen oft nicht mehr möglich. Information kann dabei in unterschiedlicher Form existieren – elektronisch gespeichert oder übertragen, geschrieben, als Bild oder in gesprochener Form. Die Tatsache, dass weite Bereiche des täglichen Lebens ohne den Einsatz von informationstechnischen Systemen heute nicht mehr funktionsfähig sind, rückt die Frage nach der Sicherheit der Informationen und der Informationstechnologie zunehmend in den Brennpunkt des Interesses.

3 Entwicklung einer organisationsweiten Informationssicherheitspolitik

Die Informationssicherheitspolitik bildet die Basis für die Entwicklung und die Umsetzung eines risikogerechten und wirtschaftlich angemessenen Informationssicherheitskonzeptes. Sie stellt ein Grundlagendokument dar, das die sicherheitsbezogenen Ziele, Strategien, Verantwortlichkeiten und Methoden langfristig und verbindlich festlegt.

Die organisationsweite Informationssicherheitspolitik soll allgemeine Festlegungen treffen, die den Schutz der Informationen und der IT-Systeme innerhalb einer Organisation gewährleisten. Diese Richtlinien werden in den nachgeordneten Sicherheitsrichtlinien, etwa der E-Mail-Sicherheitsrichtlinie oder der Netzwerksicherheitsrichtlinie, konkret umgesetzt.

Ziel dieses Abschnittes ist es, die Erarbeitung einer Informationssicherheitspolitik zu unterstützen.

Das folgende Kapitel gibt eine Anleitung zur Erstellung einer derartigen Politik und legt die wesentlichen Inhalte fest. Diese sind:

Informationssicherheitsziele und -strategien
Erklärung der Leitungsebene über die Unterstützung der Ziele des Informationssicherheitsmanagements (Management Commitment)
Organisation und Verantwortlichkeiten für Informationssicherheit
Risikoanalysestrategien, akzeptables Restrisiko und Risikoakzeptanz
Klassifizierung von Daten
Klassifizierung von IT-Anwendungen und IT-Systemen, Grundzüge der Business Continuity Planung
Aktivitäten zur Überprüfung und Aufrechterhaltung der Sicherheit
Verweise auf weitere Dokumente zum Thema Informationssicherheit, wie etwa Sicherheitsrichtlinien

3.1 Aufgaben und Ziele einer Informationssicherheitspolitik

Eine organisationsweite Informationssicherheitspolitik hat die Aufgabe, die Vertraulichkeit, Integrität und Verfügbarkeit der Information in einer Organisation sicherzustellen.

Dabei gilt:

Die Informationssicherheitspolitik wird als schriftliches Dokument erstellt und bildet die Grundlage des Informationssicherheitsmanagements.
Die Informationssicherheitspolitik legt Leitlinien fest, schreibt aber keine Implementierung vor.
Das Management unterstützt und fördert die Aktivitäten zum Informationssicherheitsmanagement. Die Informationssicherheitspolitik enthält ein explizites Statement des Managements über die Unterstützung der Informationssicherheitsziele (Management Commitment).
Die Informationssicherheitspolitik wird offiziell verabschiedet und in Kraft gesetzt.
Jede/r Mitarbeiter/in muss Kenntnis über die wichtigsten Inhalte der Informationssicherheitspolitik haben. Die direkt mit Informationssicherheit beschäftigten Mitarbeiter/innen müssen im Besitz einer aktuellen Version der Informationssicherheitspolitik sein.

Geltungsbereich

Im Bereich der öffentlichen Verwaltung ist zumindest auf Ressortebene eine eigene, ressortspezifische Informationssicherheitspolitik zu erstellen. Bei Bedarf können aus dieser weitere Informationssicherheitspolitiken, etwa auf Behörden- oder Abteilungsebene, abgeleitet werden.

Im Bereich der Privatwirtschaft wird die Erarbeitung einer organisationsweiten Informationssicherheitspolitik zumindest für große bis mittlere Unternehmen empfohlen. Abhängig von der Unternehmensstruktur und den strategischen Zielen kann die Erstellung einer Informationssicherheitspolitik auch für kleinere Unternehmen empfehlenswert sein.

3.2 Die Inhalte der Informationssicherheitspolitik

Der folgende Abschnitt beschreibt, welche Themenbereiche im Rahmen der Informationssicherheitspolitik in jedem Fall angesprochen werden sollten, und gibt Anleitungen zur Erstellung dieses Dokumentes. Über die angeführten Themenbereiche hinaus können organisationsspezifisch weitere wichtige Sicherheitsthemen in die Informationssicherheitspolitik aufgenommen werden.

3.2.1 Informationssicherheitsziele und -strategien

Schritt 1: Festlegung der wesentlichen Informationssicherheitsziele

Im Rahmen der Erstellung der Informationssicherheitspolitik sind zunächst die spezifischen Sicherheitsziele der Organisation zu erarbeiten, die mit dieser Politik erreicht werden sollen.

Beispiele für solche Ziele sind:

Gewährleistung der aus gesetzlichen Vorgaben resultierenden Anforderungen
Gewährleistung des Vertrauens der Öffentlichkeit in die betroffene Organisation bzw. die öffentliche Verwaltung im Allgemeinen
Hohe Verlässlichkeit des Handelns, insbesondere in Bezug auf Vertraulichkeit, Richtigkeit und Rechtzeitigkeit.

Dies erfordert:

Vertraulichkeit der verarbeiteten Informationen
Einhaltung aller Gesetze, Verträge und Regelungen (etwa des Datenschutzgesetzes, des Informationssicherheitsgesetzes, von SLAs und Normen)
Korrektheit, Vollständigkeit und Authentizität der Informationen (Integrität der IT)
Rechtzeitigkeit (Verfügbarkeit der Daten und Services)
Sicherung der investierten Werte
Sicherstellung der Kontinuität der Arbeitsabläufe
Reduzierung der im Schadensfall entstehenden Kosten (Schadensvermeidung und Schadensbegrenzung)
Gewährleistung des besonderen Prestiges

Neben diesen eher allgemein gültigen Zielen sind die organisationsspezifischen Sicherheitsziele - bezugnehmend auf die spezifischen Aufgaben und Projekte - zu formulieren.

Zur Präzisierung dieser Ziele können folgende Fragen hilfreich sein:

Welche Informationen sind besonders schützenswert?
Welche Auswirkungen hätte eine gravierende Verletzung der Sicherheit dieser Informationen (Verlust von Vertraulichkeit, Integrität und/oder Verfügbarkeit)?
Welche wesentlichen Entscheidungen hängen von der Genauigkeit, Integrität oder Verfügbarkeit dieser Informationen ab?
Welche essentiellen Aufgaben der betreffenden Organisation können bei Kompromittierung dieser Informationen nicht mehr durchgeführt werden?
Welche essentiellen Aufgaben der betreffenden Organisation können ohne IT-Unterstützung nicht mehr durchgeführt werden?

Schritt 2: Festlegung des angestrebten Sicherheitsniveaus

In diesem Schritt ist festzulegen, welches Sicherheitsniveau in Bezug auf

Vertraulichkeit,
Integrität und
Verfügbarkeit

angestrebt werden soll.

Schritt 3: Ausarbeitung von Strategien für das Informationssicherheitsmanagement

Die Sicherheitsstrategie legt fest, wie die definierten Sicherheitsziele erreicht werden können.

Eine organisationsweite Informationssicherheitspolitik kann und soll lediglich eine High-Level-Beschreibung der gewählten Strategien beinhalten, Detailbeschreibungen sind Aufgabe der nachgeordneten Sicherheitsrichtlinien.

Beispiele für Strategien für das Informationssicherheitsmanagement sind:

eine klare Zuordnung aller Verantwortlichkeiten im Informationssicherheitsprozess,
die Einführung eines QM-Systems,
die Entwicklung von Sicherheitsrichtlinien für die wichtigsten Systeme, Services und Anwendungen
die Etablierung eines organisationsweiten Incident Handling Plans,
Orientierung an internationalen Richtlinien und Standards,
Informationssicherheit als integraler Bestandteil des gesamten Lebenszyklus eines IT-Systems,
die Förderung des Sicherheitsbewusstseins aller Mitarbeiter/innen.

3.2.2 Management Commitment

Die Leitungsebene soll im Rahmen der Informationssicherheitspolitik ein klares Bekenntnis zur Bedeutung der Informationssicherheit für die Institution abgeben. Dazu zählen insbesondere die Unterstützung der Ziele und Prinzipien der Informationssicherheit und die Erklärung ihrer Übereinstimmung mit den Geschäftszielen und -strategien.

3.2.3 Organisation und Verantwortlichkeiten für Informationssicherheit

Um eine Berücksichtigung aller wichtigen Aspekte und eine effiziente Erledigung sämtlicher anfallender Aufgaben zu gewährleisten, ist es erforderlich, die Rollen und Verantwortlichkeiten aller in den Informationssicherheitsprozess involvierten Personen klar zu definieren.

Die Organisation des ISM ist für jede Institution - entsprechend ihrer Größe, Struktur und Aufgaben - spezifisch festzulegen und in der Informationssicherheitspolitik festzuschreiben.

Zentrale Aufgaben im Informationssicherheitsmanagementprozess übernehmen dabei

das Informationssicherheitsmanagement-Team,
die IT-Sicherheitsbeauftragten (zur Wahl der Bezeichnung s. unten),
die Bereichs-IT-Sicherheitsbeauftragten und
die Applikations-/Projektverantwortlichen.

Auf der Ebene der Bundesverwaltung ist zusätzlich in jedem Ressort die Person einer/eines Informationssicherheitsbeauftragten gemäß Informationssicherheitsgesetz (InfoSiG), BGBl. I Nr. 23/2002 , § 7 idgF, einzurichten. Weiters werden für diesen Bereich durch das IKT-Board verbindliche Regelungen zur IKT-Sicherheit vorgegeben.

Es ist zu betonen, dass es sich bei diesen Funktionen bzw. Gremien, die im Folgenden näher beschrieben werden, um Rollen handelt, die - abhängig von der Größe und den Sicherheitsanforderungen einer Organisation - durchaus auch von mehreren Personen wahrgenommen werden können. In diesem Fall ist auf eine genaue Trennung der Kompetenzen und Verantwortlichkeiten Bedacht zu nehmen. Genauso ist es möglich, dass eine Person eine dieser Rollen zusätzlich zu anderen Aufgaben übernimmt. So könnte beispielsweise ein Systemadministrator als Bereichs-IT-Sicherheitsbeauftragte/r für dieses System agieren. Dabei ist aber unbedingt darauf zu achten, dass ausreichend Zeit für die sicherheitsrelevanten Tätigkeiten zur Verfügung steht und es zu keinen Kollisionen von Verantwortlichkeiten oder Interessen kommt.

Nachfolgend werden die wichtigsten typischen Aufgaben und Verantwortlichkeiten dieser Funktionen bzw. Gremien kurz beschrieben. Eine detaillierte, auf die speziellen Aufgaben und Anforderungen der betreffenden Organisation abgestimmte Beschreibung ist im Rahmen der organisationsweiten Informationssicherheitspolitik zu geben.

Die/der IT-Sicherheitsbeauftragte

Die/der IT-Sicherheitsbeauftragte ist die zentrale Ansprechperson für alle Informations- und IT-Sicherheitsfragen innerhalb einer Organisation und trägt die fachliche Verantwortung für diesen Bereich.

Anmerkung: Die Bezeichnung "IT-Sicherheitsbeauftragte/r" für die Person einer/eines zentralen Sicherheitsverantwortlichen wurde zum einen gewählt, weil es sich um einen in vielen Institutionen sowohl des Behörden- als auch des Privatwirtschaftsbereiches eingeführten Begriff handelt, zum anderen, um diese Rolle gegenüber der Rolle der/des Informationssicherheitsbeauftragten gemäß InfoSiG abzugrenzen, der/dem ganz spezifische Aufgaben lt. Gesetz zukommen.

Zu den Pflichten der/des IT-Sicherheitsbeauftragten gehören:

die verantwortliche Mitwirkung an der Erstellung des Informationssicherheitskonzeptes,
die Gesamtverantwortung für die Realisierung der ausgewählten Sicherheitsmaßnahmen,
die Planung und Koordination von Schulungs- und Sensibilisierungsveranstaltungen,
die Gewährleistung der Informationssicherheit im laufenden Betrieb sowie
die Verwaltung der für Informationssicherheit zur Verfügung stehenden Ressourcen.

Die/der IT-Sicherheitsbeauftragte kann einzelne Aufgaben delegieren, die Gesamtverantwortung für die Informationssicherheit verbleibt aber bei dieser Person.

Der Funktion der/des IT-Sicherheitsbeauftragten kommt eine zentrale Bedeutung zu. Daher sollte diese Rolle in jedem Fall - also auch bei kleinen Organisationen - definiert und klar einer Person, eventuell zusätzlich zu anderen Aufgaben, zugeordnet sein.

Das Informationssicherheitsmanagement-Team

Das Informationssicherheitsmanagement-Team ist verantwortlich für die Regelung der organisationsweiten Informationssicherheitsbelange sowie für die Erarbeitung von Plänen, Vorgaben und Richtlinien zur Informationssicherheit.

Zu den Aufgaben des Teams zählen typischerweise:

die Festlegung der Informationssicherheitsziele der Organisation,
die Entwicklung einer organisationsweiten Informationssicherheitspolitik,
Unterstützung und Beratung bei der Erstellung des Informationssicherheitskonzeptes,
die Überprüfung des Konzeptes auf Erreichung der Informationssicherheitsziele,
die Förderung des Sicherheitsbewusstseins in der gesamten Organisation sowie
die Festlegung der personellen und finanziellen Ressourcen für Informationssicherheit.

Zusammensetzung des Teams:
Die genaue Festlegung der Zusammensetzung sowie der Aufgaben und Verantwortlichkeiten des Informationssicherheitsmanagement-Teams haben im Rahmen der Informationssicherheitspolitik zu erfolgen.

Generell ist zu empfehlen, dass die/der IT-Sicherheitsbeauftragte sowie ein/e Vertreter/in der IT-Anwender/innen dem Informationssicherheitsmanagement-Team angehören.

Die Bereichs-IT-Sicherheitsbeauftragten

Die Komplexität moderner IT-Systeme erfordert zur Gewährleistung eines angemessenen Sicherheitsniveaus tief gehende Systemkenntnisse. Wenn mehrere unterschiedliche Systemplattformen zum Einsatz kommen, können diese von einer einzelnen Person oft nicht mehr abgedeckt werden. Daher wird es in vielen Fällen empfehlenswert sein, Bereichs-IT-Sicherheitsbeauftragte zu definieren. Diese haben die fachliche Verantwortung für alle IT-Sicherheitsbelange in einem bestimmten Bereich. Ein Bereich kann beispielsweise ein IT-System oder eine Betriebssystemplattform sein, auch eine Zuordnung nach Abteilungen oder Betriebsstandorten ist denkbar.

Zu den Aufgaben einer/eines Bereichs-IT-Sicherheitsverantwortlichen zählen

die Mitwirkung bei den ihren/seinen Bereich betreffenden Teilen des Informationssicherheitskonzeptes,
die Erarbeitung eines detaillierten Planes zur Realisierung der ausgewählten Sicherheitsmaßnahmen,
die Umsetzung dieses Planes,
die regelmäßige Prüfung der Wirksamkeit und Einhaltung der eingesetzten Sicherheitsmaßnahmen im laufenden Betrieb,
Information der/des IT-Sicherheitsbeauftragten über bereichsspezifischen Schulungsbedarf sowie
Meldungen an die/den IT-Sicherheitsbeauftragten bei sicherheitsrelevanten Ereignissen.

Applikations-/Projektverantwortliche

Für jede IT-Anwendung und jedes IT-Projekt ist die fachliche Gesamtverantwortung und damit auch die Verantwortung für deren Sicherheit klar festzulegen.

Zu den Aufgaben einer/eines Applikations- oder Projektverantwortlichen zählen insbesondere

die Festlegung der Sicherheits- und Qualitätsanforderungen der Applikation bzw. des Projektes,
die Klassifizierung der verarbeiteten Daten,
die Vergabe von Zugriffsrechten sowie
organisatorische und administrative Maßnahmen zur Gewährleistung der IT-Sicherheit in der Projektentwicklung und im laufenden Betrieb.

Neben den oben beschriebenen Rollen gibt es im Bereich der Bundesverwaltung eine spezielle, per Gesetz festgelegte Rolle - die/den Informationssicherheitsbeauftragte/n.

Die/der Informationssicherheitsbeauftragte

Auf Ressortebene sind gemäß Informationssicherheitsgesetz (InfoSiG), BGBl. I Nr. 23/2002 idgF, Informationssicherheitsbeauftragte zu bestellen.

Aufgaben der/des Informationssicherheitsbeauftragten sind:

die Überwachung der Einhaltung der Bestimmungen des Informationssicherheitsgesetzes (InfoSiG), BGBl. I Nr. 23/2002 idgF,, der Informationssicherheitsverordnung (InfoSiV), BGBl. I Nr. 548/2003 idgF, und der sonstigen Informationssicherheitsvorschriften,
die periodische Überprüfung der Sicherheitsvorkehrungen für den Schutz von (lt. (InfoSiG), BGBl. I Nr. 23/2002 idgF,) klassifizierten Informationen,
die Berichterstattung darüber an die Informationssicherheitskommission,
Behebung von erkannten Mängeln,
Sicherheitsüberprüfung von betroffenen Personen gemäß §3 Abs. 1 Z1 und 2 (InfoSiG), BGBl. I Nr. 23/2002 idgF,,
Information der Bundesministerin bzw. des Bundesministers des jeweiligen Ministeriums in Angelegenheiten der Informationssicherheit sowie
Erstattung von Verbesserungsvorschlägen, falls erforderlich.

Die/der Informationssicherheitsbeauftragte ist Mitglied der Informationssicherheitskommission.

Weitere Pflichten und Verantwortungen im Bereich Informationssicherheit

Sicherheit ist nicht ausschließlich Angelegenheit der damit per Definition betrauten Personen. Jede/r Mitarbeiter/in, auch wenn sie/er nicht direkt in den Bereich Informationssicherheit involviert ist, muss ihre/seine spezifischen Pflichten und Verantwortlichkeiten im Rahmen der Informationssicherheit kennen und erfüllen. Ebenso sind die Rechte und Pflichten von externen Personen, Lieferanten und Vertragspartnern festzulegen.

Im Rahmen der organisationsweiten Informationssicherheitspolitik sind daher auch die Aufgaben und Verantwortlichkeiten folgender Personenkreise zu definieren:

Management/Behördenleitung ("Sicherheit als Managementaufgabe")
DV-Entwicklung und technischer Support
Dienstnehmer
Leasingpersonal, externe Mitarbeiter/innen
Lieferanten und Vertragspartner

Informationssicherheit und Datenschutz

Auch wenn die Einrichtung einer/eines Datenschutzbeauftragten gesetzlich nicht gefordert ist (vgl. Datenschutzgesetz (DSG 2000), BGBl. I Nr. 165/1999 idgF,), ist es sinnvoll, in Organisationen, in denen personenbezogene Daten lt. DSG 2000 verarbeiten werden, die datenschutzbezogenen Aufgaben zu konzentrieren und die erforderlichen Tätigkeiten zuzuordnen. Es ist aber zu betonen, dass die Gesamtverantwortung für die Datenschutzbelange bei der Geschäftsführung verbleibt und nicht delegiert werden kann.

3.2.4 Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken

Methodisches Risikomanagement ist zur Erarbeitung eines vollständigen und organisationsweiten Informationssicherheitskonzeptes unerlässlich. Um Risiken zu beherrschen, ist es zunächst erforderlich, sie zu kennen und zu bewerten. Dazu wird in einer Risikoanalyse das Gesamtrisiko ermittelt. Ziel ist es, dieses Risiko so weit zu reduzieren, dass das verbleibende Restrisiko quantifizierbar und akzeptierbar wird.

In der Informationssicherheitspolitik sollen die Risikoanalysestrategie der Organisation sowie das akzeptable Restrisiko festgelegt werden. Weiters ist die Vorgehensweise bei der Akzeptanz von außergewöhnlichen Restrisiken zu definieren.

Im folgenden Abschnitt werden die wichtigsten Punkte, die im Rahmen der Informationssicherheitspolitik zum Thema Risikoanalyse festgelegt werden sollten, aufgeführt. Details zur Risikoanalyse sind in Kapitel Risikoanalyse enthalten.

Schritt 1: Festlegung der anzuwendenden Risikoanalysestrategie

Die heute gängige Praxis unterscheidet drei Varianten zur Risikoanalysestrategie einer Organisation:

Grundschutzansatz:
Unabhängig von den tatsächlichen Sicherheitsanforderungen werden für alle IT-Systeme Standardsicherheitsmaßnahmen ("Grundschutzmaßnahmen") eingesetzt. Diese Vorgehensweise spart Ressourcen und führt schnell zu einem relativ hohen Niveau an Sicherheit. Der Nachteil liegt darin, dass der Grundschutzlevel für die vorhandenen Geschäftsprozesse und IT-Systeme möglicherweise nicht angemessen sein könnte.

Detaillierte Risikoanalyse:
Für alle Geschäftsprozesse und die sie unterstützenden IT-Systeme wird eine detaillierte Risikoanalyse durchgeführt. Diese Methode gewährleistet die Auswahl von effektiven und angemessenen Sicherheitsmaßnahmen, benötigt jedoch viel Zeit und Aufwand.

Kombinierter Ansatz:
In einem ersten Schritt wird in einer Schutzbedarfsfeststellung ( High Level Risk Analysis ) ausgehend von den Geschäftsprozessen der Schutzbedarf für die einzelnen Prozesse, die sie unterstützenden Systeme und die verarbeiteten Informationen ermittelt. Bei normalem Schutzbedarf wird von einer pauschalisierten Gefährdungslage ausgegangen, so dass auf eine detaillierte Risikoanalyse verzichtet und eine Grundschutzanalyse (s. o.) durchgeführt werden kann. Dies erlaubt eine schnelle und effektive Auswahl von grundlegenden Sicherheitsmaßnahmen bei gleichzeitiger Gewährleistung eines angemessenen Schutzniveaus. Bei hohem Schutzbedarf können wahlweise Grundschutzmaßnahmen eingesetzt oder eine detaillierte Risikoanalyse durchgeführt werden. Besteht sehr hoher Schutzbedarf, so sind die betroffenen Geschäftsprozesse und IT-Systeme einer detaillierten Risikoanalyse zu unterziehen, auf deren Basis individuelle Sicherheitsmaßnahmen ausgewählt werden.

Diese Option kombiniert die Vorteile des Grundschutzansatzes mit denen einer detaillierten Risikoanalyse und stellt heute die allgemein empfohlene Vorgehensweise dar.

Schritt 2: Festlegung des akzeptablen Restrisikos

Nach Durchführung aller ausgewählten Sicherheitsmaßnahmen verbleibt im Allgemeinen ein Restrisiko, dessen Abdeckung wirtschaftlich nicht mehr vertretbar wäre. In der Informationssicherheitspolitik sind diese akzeptablen Restrisiken so exakt wie möglich zu quantifizieren.

Schritt 3: Festlegung der Vorgehensweise zur Akzeptanz von außergewöhnlichen Restrisiken

Verbleibt nach Durchführung aller im Sicherheitsplan vorgesehenen Maßnahmen ein Restrisiko, das höher ist als das generell akzeptable und dessen weitere Reduktion technisch nicht möglich oder unwirtschaftlich wäre, so besteht in begründeten Ausnahmefällen die Möglichkeit einer bewussten Akzeptanz des erhöhten Restrisikos.

In der Sicherheitspolitik sind

das Vorgehen bei Risiken, die in Abweichung von der generellen Sicherheitspolitik in Kauf genommen werden sollen, sowie
die Verantwortlichkeiten dafür

festzulegen.

3.2.5 Klassifizierung von Informationen

Die Klassifizierung der verarbeiteten, gespeicherten und übertragenen Informationen in Bezug auf ihre Vertraulichkeit und Datenschutzanforderungen ist wesentliche Voraussetzung für die spätere Auswahl adäquater Sicherheitsmaßnahmen.

Daher sind in der Informationssicherheitspolitik entsprechende Sicherheitsklassen zu definieren und weiters die Verantwortlichkeiten für die Durchführung der Klassifizierung festzulegen.

3.2.5.1 Definition der Sicherheitsklassen

A) Festlegung von Klassifizierungsstufen bzgl. Vertraulichkeit (Vertraulichkeitsklassen)

Die Vertraulichkeitsklassen können als Maß dafür gesehen werden, welche Auswirkungen ein Missbrauch der Information auf die Institution haben kann.

Im Bereich der Bundesverwaltung sind die unten angeführten hierarchischen Klassen definiert. Diese Klassen sind lt. Informationssicherheitsgesetz (InfoSiG), BGBl. I Nr. 23/2002 idgF, gesetzlich festgelegt für "klassifizierte Informationen, die Österreich im Einklang mit völkerrechtlichen Regelungen erhalten hat".

HINWEIS: Im Sinne der Kompatibilität und Einheitlichkeit erscheint diese Klassifizierung auch für andere Daten im Bereich der Bundesverwaltung sinnvoll. Zum Zeitpunkt der Erstellung dieser Version des Sicherheitshandbuches ist jedoch eine neue Geheimschutzverordnung zu national klassifizierten Informationen in Arbeit. Dieser soll nicht vorgegriffen werden, weshalb hier keine Vorgaben gemacht werden.

EINGESCHRÄNKT:
Die unbefugte Weitergabe der Informationen würde den in Art. 20, Abs. 3 B-VG genannten Interessen zuwiderlaufen. [ Anmerkung: Alle mit Aufgaben der Bundes-, Landes- und Gemeindeverwaltung betrauten Organe sowie die Organe anderer Körperschaften des öffentlichen Rechts sind, soweit gesetzlich nicht anderes bestimmt ist, zur Verschwiegenheit über alle ihnen ausschließlich aus ihrer amtlichen Tätigkeit bekannt gewordenen Tatsachen verpflichtet, deren Geheimhaltung im Interesse der Aufrechterhaltung der öffentlichen Ruhe, Ordnung und Sicherheit, der umfassenden Landesverteidigung, der auswärtigen Beziehungen, im wirtschaftlichen Interesse einer Körperschaft des öffentlichen Rechts, zur Vorbereitung einer Entscheidung oder im überwiegenden Interesse der Parteien geboten ist (Amtsverschwiegenheit). ...]
VERTRAULICH:
Die Informationen stehen nach anderen Bundesgesetzen unter strafrechtlichem Geheimhaltungsschutz und ihre Geheimhaltung ist im öffentlichen Interesse gelegen.
GEHEIM:
Die Informationen sind vertraulich und ihre Preisgabe würde zudem die Gefahr einer erheblichen Schädigung der in Art. 20, Abs. 3 B-VG genannten Interessen schaffen.
STRENG GEHEIM:
Die Informationen sind geheim und ihr Bekannt werden würde überdies eine schwere Schädigung der in Art. 20, Abs. 3 B-VG genannten Interessen wahrscheinlich machen.

Nicht-klassifizierte Informationen werden nachfolgend auch als "OFFEN" bezeichnet.

In den übrigen Verwaltungsbereichen und in der Privatwirtschaft ist es jeder Organisation überlassen, in ihrer Informationssicherheitspolitik eine für ihre Zwecke adäquate Definition von Vertraulichkeitsklassen vorzunehmen, sofern es nicht bereits diesbezügliche Regelungen gibt. Aus Gründen der Kompatibilität wird die Anwendung des genannten Schemas in denjenigen Bereichen, in denen nicht zwingende Gründe für ein anderes Klassifizierungsschema bestehen, empfohlen. Allerdings werden Organisationen der Privatwirtschaft, sofern sie nicht besonders strenge Sicherheitsanforderungen haben, im Allgemeinen mit weniger Klassen (meist 3 oder 4) das Auslangen finden.

Im Rahmen der Informationssicherheitspolitik sollte darauf hingewiesen werden, dass die Klassifizierung der Daten sehr sorgfältig vorzunehmen ist. Nicht nur die Einstufung in eine zu niedrige Vertraulichkeitsklasse ist mit potentiellen Gefahren verbunden, auch die leichtfertige Einstufung in eine zu hohe Vertraulichkeitsklasse ist zu vermeiden, da etwa die Behandlung von geheimen Daten durchwegs mit erheblichem Aufwand verbunden ist.

B) Klassifizierung von Daten in Bezug auf Datenschutz

Werden personenbezogene Daten verarbeitet, so sind die Daten auch dahingehend zu klassifizieren. Die nachfolgende Klassifizierung gemäß Datenschutzgesetz (DSG 2000), BGBl. I Nr. 165/1999 idgF, gilt sowohl für den Behörden- als auch für den privatwirtschaftlichen Bereich.

NUR INDIREKT PERSONENBEZOGEN:
Der Personenbezug der Daten kann mit rechtlich zulässigen Mitteln nicht bestimmt werden.

PERSONENBEZOGEN:
Angaben über Betroffene [ Anmerkung -: Betroffene: Jede vom Auftraggeber verschiedene natürliche oder juristische Person oder Personengemeinschaft, deren Daten verwendet werden.], deren Identität bestimmt oder bestimmbar ist.

SENSIBEL:
Daten über rassische und ethnische Herkunft, politische Meinungen, Gewerkschaftszugehörigkeit, religiöse oder philosophische Überzeugungen, Gesundheit oder Sexualleben von natürlichen Personen.

3.2.5.2 Festlegung der Verantwortlichkeiten und der Vorgehensweise

Im Rahmen der Informationssicherheitspolitik ist generell festzulegen, wer die Klassifizierung der Daten vorzunehmen hat. Dies kann in den einzelnen Organisationen unterschiedlich sein und auch von IT-System zu IT-System differieren.

Als allgemeine Richtlinie kann gelten, dass die Klassifizierung einer Information von jener Person vorzunehmen ist, von der diese Information stammt, oder, wenn diese keine eindeutigen Vorgaben gemacht hat, von jener Person in der Organisation, die diese Information von außen erhält.

Weiters ist festzulegen, in welcher Form die Klassifizierung bzw. Deklassifizierung erfolgt und wie klassifizierte Information gekennzeichnet wird.

Die/der für die Information verantwortliche Mitarbeiter/in wird oft als "Dateneigner" oder "Data Owner" bezeichnet.

3.2.5.3 Erarbeitung von Regelungen zum Umgang mit klassifizierten Informationen

In diesem Schritt ist festzulegen, wie die Information in Abhängigkeit von den Sicherheitsklassen zu behandeln ist.

Werden in einer Organisation häufig klassifizierte Informationen verarbeitet und gespeichert, so empfiehlt sich die Erarbeitung eines eigenständigen Dokumentes, in dem u.a. folgende Fragen behandelt werden:

Kennzeichnung klassifizierter Information (sowohl elektronischer als auch nicht-elektronischer)
Verwahrung klassifizierter Information (Zugriffsberechtigungen, etwaige Vorschriften zur Verschlüsselung)
Übermittlung klassifizierter Information (mündliche Weitergabe, persönliche Weitergabe, Versendung durch Post oder Kurier, elektronische Übertragung, über welche Verbindungen, Vorschriften zur Verschlüsselung)
Registrierung klassifizierter Information
Ausdruck klassifizierter Information (auf welchen Drucker, durch wen)
Backup (Klartext, chiffriert, Schutz der Backup-Medien)
Aufbewahrung / Wiederverwendung / Vernichtung von Datenträgern mit klassifizierter Information
Weitergabe klassifizierter Information (an wen, durch wen, unter welchen Bedingungen)
Deklassifizierung klassifizierter Information (wann, durch wen)

Näheres zum Umgang mit klassifizierten Informationen siehe Kapitel 8.

3.2.6 Klassifizierung von IT-Anwendungen und IT-Systemen, Grundzüge der Business Continuity Planung

Ziel der Business Continuity Planung ist es, die Verfügbarkeit der wichtigsten Applikationen und Systeme innerhalb eines definierten Zeitraumes zu gewährleisten sowie Vorkehrungen zur Schadensbegrenzung im Katastrophenfall zu treffen ("Gewährleistung eines kontinuierlichen Geschäftsbetriebes").

Dabei wird unterschieden zwischen der Aufrechterhaltung der Betriebsverfügbarkeit im Fall von Störungen oder Bedienungsfehlern (im Folgenden auch als Business Contingency Planung bezeichnet) sowie der Gewährleistung eines Notbetriebes und des geordneten Wiederanlaufs im Katastrophenfall (Katastrophenvorsorge, K-Planung).

Im Rahmen der Informationssicherheitspolitik sind die Verfügbarkeitsklassen für IT-Anwendungen und die diesen Anwendungen zugrunde liegenden IT-Systeme sowie der darauf verarbeiteten oder gespeicherten Informationen zu definieren. Die Business Continuity Planung selbst ist nicht Bestandteil der Informationssicherheitspolitik, sondern muss in den entsprechenden weiteren Aktivitäten erfolgen.

Nachfolgend ein Beispiel für ein solches Klassifizierungsschema – basierend auf den Katastrophenvorsorge- und Ausfallssicherheitsüberlegungen im IT-Bereich des Bundeskanzleramtes [K-Fall]:

Betriebsverfügbarkeitskategorie 1 – Keine Vorsorge (unkritisch):
Für die IT-Anwendung werden keine besonderen Vorkehrungen getroffen. Es ist ein Datenverlust bzw. Ausfall der IT-Anwendung unbestimmter Dauer denkbar. Eine Behinderung in der Wahrnehmung der Aufgaben der betroffenen Verwaltungsstelle entsteht durch den Ausfall bzw. Datenverlust nicht.
Betriebsverfügbarkeitskategorie 2 – Offline Sicherung:
Es sind die gängigen Sicherungsmaßnahmen für die IT-Anwendung vorgesehen, ein Datenverlust ist auszuschließen. Die IT-Anwendung kann bei technischen Problemen erst nach deren Behebung am ursprünglichen Produktivsystem in Betrieb genommen werden. Die Sicherung wird an einen externen Ort ausgelagert.
Betriebsverfügbarkeitskategorie 3 – Redundante Infrastruktur:
Die Infrastruktur für die IT-Anwendung ist derart ausgelegt, dass bei Ausfall einer IT-Komponente der Betrieb durch redundante Auslegung ohne Unterbrechung fortgesetzt werden kann.
Betriebsverfügbarkeitskategorie 4 – Redundante Standorte:
Die IT-Infrastruktur sowie die darauf aufsetzende IT-Anwendung ist auf zwei Standorte verteilt, so dass bei Betriebsunterbrechung des einen Standortes die IT-Anwendung uneingeschränkt am zweiten Standort weiter betrieben werden kann.

Zusätzlich zu den vier genannten Kategorien ist noch die Zusatzqualität „K-Fall sicher“ definiert, welche auch die Anforderungen in Katastrophenfällen berücksichtigt:

K-Fall sicher (K2 bis K4):
Die IT-Anwendung ist derart konzipiert, dass zumindest ein Notbetrieb in einer Zero-Risk-Umgebung möglich ist. Dazu werden die Daten je nach Aktualisierungsgrad laufend in die Zero-Risk-Umgebung transferiert und der Betrieb der IT-Anwendung derart gestaltet, dass ein Wiederaufsetzen eines definierten Notbetriebes in der Zero-Risk-Umgebung umgehend möglich ist.

In Summe ergibt eine derartige Einstufung die Verfügbarkeitsklassen 1 bis 4 und K2 bis K4. Die Zusatzoption „K-Fall sicher“ in Verbindung mit Betriebsverfügbarkeitskategorie 1 ist nicht sinnvoll.

Für nähere Informationen und für Klassifizierungsbeispiele siehe Abschnitt 7.2 im 2.Teil des vorliegenden Handbuches, KIT-S02,.

3.2.7 Überprüfung und Aufrechterhaltung der Sicherheit

Informationssicherheit ist kein durch einmalige Anstrengungen erreichbarer und dann unveränderbarer Zustand. Umfassendes Informationssicherheitsmanagement beinhaltet vielmehr auch die Aufgabe, Informationssicherheit im laufenden Betrieb kontinuierlich zu überprüfen und aufrechtzuerhalten.

Die Informationssicherheitspolitik muss daher Leitlinien und Kennzahlen zur Bewertung der Sicherheit hinsichtlich Angemessenheit, Wirksamkeit und Ordnungsmäßigkeit der eingesetzten Maßnahmen sowie deren Übereinstimmung mit der Informationssicherheitspolitik und dem Informationssicherheitskonzept vorgeben.

3.2.8 Dokumente zur Informationssicherheit

Abschließend sollte ein Verweis auf die wichtigsten Dokumente zum Informationssicherheitsmanagement (Sicherheitsrichtlinien, Informationen über spezielle Sicherheitsmaßnahmen oder -systeme, organisatorische Regelungen …) gegeben werden.

3.3 Life Cycle der Informationssicherheitspolitik

3.3.1 Erstellung

Die Informationssicherheitspolitik soll von allen Mitarbeiterinnen/Mitarbeitern getragen werden. Es ist daher wichtig, dass bei ihrer Erstellung alle wesentlichen Kräfte der Organisation beteiligt werden und das Dokument mit Vertreterinnen/Vertretern aller Beteiligten bzw. Betroffenen abgestimmt wird.

Zunächst ist eine verantwortliche Person für die Erstellung der Informationssicherheitspolitik zu nominieren. Im Allgemeinen wird dies, soweit bereits definiert, die/der IT-Sicherheitsbeauftragte sein.

Weiters sollen Vertreter/innen folgender Bereiche an der Erstellung der organisationsweiten Informationssicherheitspolitik mitarbeiten bzw. in den Abstimmungsprozess miteinbezogen werden:

IT-Abteilung
Anwender/innen
Bereichs-IT-Sicherheitsbeauftragte
Personalabteilung
Gebäudeverwaltung und Infrastruktur
Revision
Budgetabteilung

Die wesentlichen Inhalte der Informationssicherheitspolitik müssen allen Betroffenen und Beteiligten, also allen Mitarbeiterinnen/Mitarbeitern der Organisation, aber auch etwa externen Mitarbeiterinnen/Mitarbeitern und Lieferanten, bekannt sein.

Dazu sollten in der Folge die für die einzelnen Personengruppen wichtigsten Richtlinien und Vorgaben der Informationssicherheitspolitik zusammengefasst und jeder/jedem Betroffenen in schriftlicher Form zur Kenntnis gebracht werden. Wo nötig, sind das Einverständnis mit diesen Vorgaben und die Kenntnis der daraus erwachsenden Verpflichtungen auch durch eine Unterschrift bestätigen zu lassen (etwa Verpflichtung auf das Datengeheimnis, Ergänzungen zu Dienstverträgen, Geheimhaltungsverpflichtungen von externen Personen, ...)

3.3.2 Offizielle Inkraftsetzung

Die Informationssicherheitspolitik wird von der Leitung der Organisation offiziell verabschiedet und in Kraft gesetzt.

Wesentliche Voraussetzung für eine erfolgreiche Implementierung und Umsetzung der Informationssicherheitspolitik ist, dass sie die volle und für jede/n Beteiligte/n sichtbare Unterstützung durch das Management erhält.

3.3.3 Regelmäßige Überarbeitung

Zwar stellt die Informationssicherheitspolitik ein langfristiges Dokument dar, dennoch ist auch sie regelmäßig auf ihre Aktualität und Übereinstimmung mit den tatsächlichen Anforderungen zu überprüfen und bei Bedarf entsprechend anzupassen.

Als Richtwert hierfür kann ein Zeitraum von zwei bis drei Jahren angesehen werden, nach dem die Informationssicherheitspolitik spätestens überprüft und aktualisiert werden sollte. Kommt es jedoch zwischenzeitlich zu gravierenden Änderungen im IT-System, in der Organisationsstruktur oder in den Bedrohungen, so ist eine sofortige Überarbeitung der Informationssicherheitspolitik in die Wege zu leiten.

Die Verantwortung dafür ist dezidiert festzulegen. Im Allgemeinen wird sie bei der für die IT-Sicherheit beauftragten Person liegen.

4 Risikoanalyse

Eine wesentliche Voraussetzung für erfolgreiches Informationssicherheitsmanagement ist die Einschätzung der bestehenden Sicherheitsrisiken. In einer Risikoanalyse wird versucht, diese Risiken zu erkennen und zu bewerten und so das Gesamtrisiko zu ermitteln. Ziel ist es, in weiterer Folge dieses Risiko so weit zu reduzieren, dass das verbleibende Restrisiko quantifizierbar und akzeptierbar wird.

Das nachfolgende Kapitel beschreibt die drei heute meist verbreiteten Strategien zur Risikoanalyse - detaillierte Risikoanalyse, Grundschutzansatz und kombinierter Ansatz - und stellt ihre Vor- und Nachteile und ihre typischen Einsatzbereiche gegenüber.

4.1 Risikoanalysestrategien

Es ist empfehlenswert, eine Strategie zur Risikoanalyse festzulegen. Diese sollte für die gesamte Organisation gültig sein und festlegen, wie die Ziele der Risikoanalyse - Erkennen und Bewerten von Einzelrisiken und Gesamtrisiko - erreicht werden sollen.

Mögliche Risikoanalysestrategien sind:

Detaillierte Risikoanalyse:
Für alle IT-Systeme wird eine detaillierte Risikoanalyse durchgeführt. Diese Methode führt zu effektiven und angemessenen Sicherheitsmaßnahmen, benötigt jedoch viel Zeit und Aufwand, so dass neben hohen Kosten auch die Gefahr besteht, dass für kritische Systeme nicht schnell genug Schutzmaßnahmen ergriffen werden können.

Grundschutzansatz:
Unabhängig vom tatsächlichen Schutzbedarf wird für alle IT-Systeme von einer pauschalisierten Gefährdungslage ausgegangen. Als Sicherheitsmaßnahmen kommen sog. Grundschutzmaßnahmen ( Baseline Security Controls ) zum Einsatz. Durch den Verzicht auf eine detaillierte Risikoanalyse spart diese Vorgehensweise Ressourcen und führt schnell zu einem relativ hohen Niveau an Sicherheit. Der Nachteil liegt darin, dass der Grundschutzlevel für das betrachtete IT-System möglicherweise nicht angemessen sein könnte.
Kombinierter Ansatz:
In einem ersten Schritt wird in einer Schutzbedarfsfeststellung ( High Level Risk Analysis ) der Schutzbedarf für die einzelnen IT-Systeme ermittelt. Für IT-Systeme der Schutzbedarfskategorie "niedrig bis mittel" wird auf eine detaillierte Risikoanalyse verzichtet. Dies erlaubt eine schnelle und effektive Auswahl von grundlegenden Sicherheitsmaßnahmen bei gleichzeitiger Gewährleistung eines angemessenen Schutzniveaus. IT-Systeme der Schutzbedarfskategorie "hoch bis sehr hoch" sind einer detaillierten Risikoanalyse zu unterziehen, auf deren Basis individuelle Sicherheitsmaßnahmen ausgewählt werden. Diese Option kombiniert die Vorteile des Grundschutz- und des Risikoanalyseansatzes, da alle IT-Systeme mit hohem Schutzbedarf wirksam und angemessen geschützt werden, und Maßnahmen für die anderen Systeme mit Hilfe des Grundschutzes schnell und effektiv ausgewählt werden können. Sie wird in den meisten Einsatzumgebungen die empfehlenswerte Strategie zur Risikoanalyse darstellen.

Im Folgenden werden die drei angeführten Risikoanalysestrategien näher erläutert.

4.2 Detaillierte Risikoanalyse

Eine detaillierte Risikoanalyse für ein IT-System umfasst die Identifikation der bestehenden Risiken sowie eine Abschätzung ihrer Größe.

Dazu werden die Werte (Assets), Bedrohungen und Schwachstellen identifiziert und die daraus resultierenden Risiken ermittelt.

Die erstmalige Durchführung einer detaillierten Risikoanalyse und die anschließende Erstellung eines Sicherheitskonzeptes erfordern einen Aufwand, der zumindest im Bereich von Wochen, möglicherweise auch von Monaten liegt.

Eine detaillierte Risikoanalyse umfasst folgende Schritte:

Schritt 1:

Hier sind die zu analysierenden IT-Systeme zu spezifizieren und anzugeben, ob und in welchem Maße auch andere Objekte (z.B. Gebäude und Infrastruktur) in die Analyse einbezogen werden sollen.

Schritt 2:

Ziel dieses Schrittes ist die Erfassung aller bedrohten Objekte, die innerhalb des im vorangegangenen Schritt festgesetzten Analysebereiches liegen.

Schritt 3:

In diesem Schritt wird der Wert der bedrohten Objekte ermittelt.

Die Wertanalyse umfasst im Einzelnen:

die Festlegung der Bewertungsbasis für Sachwerte
die Festlegung der Bewertungsbasis für immaterielle Werte
die Ermittlung der Abhängigkeiten zwischen den Objekten
die Bewertung der bedrohten Objekte und der möglichen Schäden (Impact Analyse)

Schritt 4:

Die Objekte sind vielfachen Bedrohungen ausgesetzt, die sowohl aus Nachlässigkeit und Versehen als auch aus Absicht resultieren können.

Die Bedrohungsanalyse umfasst:

die Identifikation möglicher Bedrohungen (Katastrophen, Fehlbedienung, bewusste Angriffe) und möglicher Angreifer/innen (Mitarbeiter/innen, Leasingpersonal, Außenstehende, ...)
die Ermittlung der Eintrittswahrscheinlichkeiten

Schritt 5:

Eine Bedrohung kann nur durch die Ausnutzung einer vorhandenen Schwachstelle wirksam werden. Es ist daher erforderlich, mögliche Schwachstellen des Systems zu identifizieren und ihre Bedeutung zu klassifizieren.

Zu untersuchen sind dabei insbesondere die Bereiche Organisation, Hard- und Software, Personal sowie Infrastruktur.

Schritt 6:

Zur Vermeidung unnötiger Aufwände und Kosten sind die bereits existierenden Sicherheitsmaßnahmen zu erfassen und auf ihre Auswirkungen hinsichtlich der Gesamtsystemsicherheit sowie auf korrekte Funktion zu prüfen.

Geplante neue Sicherheitsmaßnahmen müssen mit den existierenden kompatibel sein und eine wirtschaftlich und technisch sinnvolle Ergänzung darstellen.

Schritt 7:

In diesem Schritt werden die Einzelrisiken und das Gesamtrisiko ermittelt und bewertet.

Schritt 8:

Eine Auswertung und Aufbereitung des Ergebnisses schließt die Risikoanalyse ab.

Bei der Durchführung einer Risikoanalyse sind folgende Prinzipien zu beachten:

Das gesamte Verfahren muss transparent gemacht werden.
Es dürfen keine versteckten Annahmen gemacht werden, die z.B. dazu führen, dass Bedrohungen unbetrachtet bleiben.
Alle Bewertungen müssen begründet werden, um subjektive Einflüsse zu erkennen und so weit wie möglich zu vermeiden.
Alle Schritte müssen so dokumentiert werden, dass sie später auch für andere nachvollziehbar sind. Ein derartiges Vorgehen erleichtert auch eine spätere Überarbeitung des Informationssicherheitskonzeptes.
Der Aufwand für die Durchführung des Verfahrens sollte dem Wert der IT-Anwendungen und den Werten der Institution im Allgemeinen angemessen sein.

In den nachfolgenden Kapiteln werden die einzelnen Schritte einer Risikoanalyse detailliert behandelt. Das vorliegende Handbuch gibt Hinweise und Unterstützung zur Durchführung dieser Schritte. Die Wahl einer konkreten Risikoanalysemethode sowie ein etwaiger Einsatz von Tools zur Unterstützung dieser Analyse bleiben der durchführenden Institution überlassen. Wichtig ist, dass alle der im Folgenden angeführten Schritte durchgeführt werden und die geforderten Ergebnisse liefern.

4.2.1 Abgrenzung des Analysebereiches

Vor Beginn einer Risikoanalyse ist es erforderlich, den zu analysierenden Bereich genau abzugrenzen. Dabei ist anzugeben, ob sich die Analyse auf Hardware, Software und Daten des betrachteten IT-Systems beschränkt oder ob und in welchem Ausmaß andere Werte wie Gebäude und Infrastruktur, Personen, immaterielle Güter, Fähigkeiten und Leistungen einbezogen werden sollen.

4.2.2 Identifikation der bedrohten Objekte (Werte, assets)

In diesem Schritt sind alle bedrohten Objekte ( assets ), die innerhalb des festgestellten Analysebereiches liegen, zu erfassen.

Unter den bedrohten Objekten einer Organisation ist alles zu verstehen, was für diese schutzbedürftig ist, also alle Objekte, von denen der Betrieb des IT-Systems und seine Anwendungen und damit die Funktionsfähigkeit der Organisation abhängen. Dazu zählen etwa:

physische Objekte:
beispielsweise Gebäude, Infrastruktur, Hardware, Datenträger, Paperware
logische Objekte:
beispielsweise Software, Daten, Information
Personen
Fähigkeiten:
etwa Herstellen eines Produktes oder Erbringen einer Dienstleistung
immaterielle Güter:
beispielsweise Image, Vertrauen in die Institution oder gute Beziehungen zu anderen Organisationen

Zwischen den bedrohten Objekten bestehen grundsätzlich komplexe Abhängigkeiten. Die Vertraulichkeit, Integrität oder Verfügbarkeit eines Objektes setzt vielfach die Vertraulichkeit, Integrität oder Verfügbarkeit eines anderen Objektes voraus. Beispiele dafür sind etwa die Erfordernis einer funktionsfähigen Infrastruktur (Stromversorgung, Klimaanlage, ...) für den Betrieb eines IT-Systems oder die Abhängigkeit der Software von unversehrter und verfügbarer Hardware.

Die Identifizierung der bedrohten Objekte sowie ihre nachfolgende Bewertung stellen wesentliche Voraussetzungen für ein erfolgreiches Informationssicherheitsmanagement dar. Dabei ist es den Erfordernissen im Einzelfall anzupassen, in welcher Tiefe und in welchem Detaillierungsgrad die einzelnen Objekte analysiert werden sollen; in vielen Fällen wird eine Zusammenfassung in Gruppen sinnvoll sein und beitragen, den Analyseaufwand zu begrenzen.

4.2.3 Wertanalyse (Impact Analyse)

In diesem Schritt wird der Wert der im vorangegangenen Schritt identifizierten Objekte ermittelt.

Die Wertanalyse umfasst im Einzelnen:

die Festlegung der Bewertungsbasis für Sachwerte
die Festlegung der Bewertungsbasis für immaterielle Werte
die Ermittlung der Abhängigkeiten zwischen den Objekten
die Bewertung der bedrohten Objekte und der möglichen Schäden

4.2.3.1 Festlegung der Bewertungsbasis für Sachwerte

Zunächst ist zu entscheiden, ob die Bewertung quantitativ oder qualitativ erfolgen soll.

Eine quantitative Bewertung kann etwa beruhen auf

dem Zeitwert eines Objektes,
dem Wiederbeschaffungswert eines Objektes,
dem Wert, den das Objekt für eine/n potentielle/n Angreifer/in hätte, oder
dem Schaden, der sich aus dem Verlust oder der Modifikation eines zu schützenden Objektes für die betroffene Organisation ergibt.

Eine qualitative Bewertung erfolgt durch Einteilung in Klassen. Beispiele hierfür sind etwa:

3-stufige Bewertung: gering - mittel - hoch
5-stufige Bewertung: unbedeutend - gering - mittel - hoch - sehr hoch

Als Basis für eine qualitative Bewertung ist festzulegen, was die einzelnen Klassen bedeuten bzw. wie sie definiert sind.

4.2.3.2 Festlegung der Bewertungsbasis für immaterielle Werte

Auch für immaterielle Werte, wie etwa Bewahrung des guten Rufes oder Gewährleistung der Vertraulichkeit, kann eine quantitative oder eine qualitative Bewertungsbasis festgelegt werden.

Eine quantitative Bewertung kann in diesem Fall beruhen auf

dem Wert, den das Objekt für einen potentiellen Angreifer hätte (z.B. vertrauliche Information), oder
dem Schaden, der sich aus einem Angriff auf das zu schützende Objekt für die betroffene Organisation ergibt.

Es ist zu beachten, dass die potentiellen Schäden den eigentlichen (Zeit- oder Wiederbeschaffungs-)Wert beträchtlich übersteigen können.

4.2.3.3 Ermittlung der Abhängigkeiten zwischen den Objekten

Es ist wichtig, auch die gegenseitige Abhängigkeit von Objekten festzustellen, da diese Einfluss auf die Bewertung der einzelnen zu schützenden Objekte haben kann.

So ist etwa die Funktionsfähigkeit der Hardware abhängig von der Funktionsfähigkeit der Stromversorgung und eventuell der Klimaanlage. Die Integrität von Information bedingt die Integrität und Verfügbarkeit der Hard- und Software, die zu ihrer Verarbeitung bzw. Speicherung eingesetzt wird.

4.2.3.4 Bewertung der bedrohten Objekte

Mit Ausnahme der Festsetzung von Zeit- oder Wiederbeschaffungswert wird die Bewertung von bedrohten Objekten in der Regel sehr subjektiv sein. Es ist daher notwendig, im Rahmen der Analyse möglichst genaue Bewertungsbasen und Regeln vorzugeben und diese eventuell durch Beispiele zu illustrieren sowie möglichst viele unterschiedliche Personen nach ihrer Einschätzung zu befragen.

Durchführung:

Die Person, die die Risikoanalyse durchführt, erstellt eine Liste der zu bewertenden Objekte und gibt die Bewertungsbasen vor.
Die Bewertung sollte durch die Applikations-/Projektverantwortlichen sowie die betroffenen Benutzer/innen vorgenommen werden.
Unterstützung in der Bewertung kann von verschiedenen Abteilungen, etwa Finanzen, Einkauf, IT, ... kommen.
Es ist Aufgabe derjenigen Person, die die Risikoanalyse durchführt, die einzelnen Bewertungen auf Plausibilität und Konsistenz zu prüfen und ein konsolidiertes Ergebnis zu erarbeiten.

Ergebnis der Wertanalyse:

Aufstellung der bedrohten Objekte und ihres Wertes für die Organisation.

4.2.4 Bedrohungsanalyse

Lt. [ISO/IEC 13335] ist eine Bedrohung ein "möglicher Anlass für ein unerwünschtes Ereignis, das zu einem Schaden für das System oder die Organisation führen kann".

Die zu schützenden Objekte sind vielfältigen Bedrohungen ausgesetzt. Im Rahmen der Risikoanalyse müssen diese identifiziert werden, weiters ist ihre Schwere und Eintrittswahrscheinlichkeit abzuschätzen.

Bedrohungen sind charakterisiert durch:

ihren Ursprung:
Bedrohungen durch die Umwelt oder durch den Menschen, wobei letztere wieder in absichtliche oder zufällige Bedrohungen zu unterteilen sind. Im Falle absichtlicher Bedrohungen ist zwischen Innentätern und Außentätern zu unterscheiden.
die Motivation:
Motivation für (absichtliche) Bedrohungen können etwa finanzielle Gründe, Wettbewerbsvorteile, Rache, aber auch Geltungssucht oder erhoffte Publicity sein.
die Häufigkeit des Auftretens,
die Größe des Schadens, der durch diese Bedrohung verursacht werden kann.

Für einige umweltbedingte Bedrohungen (etwa Erdbeben, Blitzschlag, ...) liegen statistische Daten vor, die für die Einschätzung hilfreich sein können.

Die Bedrohungsanalyse umfasst im Einzelnen:

die Identifikation möglicher Bedrohungen
die Ermittlung der Eintrittswahrscheinlichkeiten

4.2.4.1 Identifikation möglicher Bedrohungen

Bedrohungen können unterteilt werden in:

Höhere Gewalt
(etwa Blitzschlag, Feuer, Erdbeben, Personalausfall)
Organisatorische Mängel
(etwa fehlende oder unzureichende Regelungen für Wartung, Dokumentation, Test und Freigabe, fehlende Auswertung von Protokolldaten, mangelhafte Kennzeichnung von Datenträgern)
Menschliche Fehlhandlungen
(etwa fehlerhafte Systemnutzung oder -administration, fahrlässige Zerstörung von Geräten oder Daten, Nichtbeachtung von Sicherheitsmaßnahmen)
Technisches Versagen
(etwa Ausfall von Versorgungs- und Sicherheitseinrichtungen, Softwarefehler, defekte Datenträger)
Vorsätzliche Handlungen
(etwa Manipulation/Zerstörung von Geräten, Manipulation an Daten oder Software, Viren, trojanische Pferde, Abhören, Wiedereinspielen von Nachrichten, Nichtanerkennen einer Nachricht, Maskerade)

Es ist wichtig, alle wesentlichen Bedrohungen zu erfassen, da andernfalls Sicherheitslücken bestehen bleiben können.

Bei der Identifikation von möglichen Bedrohungen können Bedrohungskataloge hilfreich sein, die den Charakter von Checklisten haben. Solche Kataloge finden sich etwa in [BSI 7105], S 207 ff und in [ISO/IEC 27005]. In den IT-Grundschutzkatalogen des BSI gibt es eine umfangreiche Sammlung von so genannten "Gefährdungen", die ihrerseits eine Kombination aus Bedrohungen und Schwachstellen darstellen. Es ist jedoch zu betonen, dass keine derartige Liste vollständig sein kann, und darüber hinaus auch Bedrohungen einem ständigen Wandel und einer ständigen Weiterentwicklung unterworfen sind. Es ist daher immer erforderlich, über Bedrohungskataloge hinaus auch die Möglichkeit weiterer Bedrohungen in Betracht zu ziehen.

4.2.4.2 Ermittlung der Eintrittswahrscheinlichkeiten

In diesem Schritt der Risikoanalyse ist zu bestimmen, mit welcher Wahrscheinlichkeit eine Bedrohung im betrachteten Umfeld eintreten wird.

Diese ist abhängig von:

der Häufigkeit der Bedrohung (Wahrscheinlichkeit des Auftretens anhand von Erfahrungen, Statistiken, ...),
der Motivation und den vorausgesetzten Fähigkeiten und Ressourcen einer/eines potentiellen Angreiferin/Angreifers,
Einschätzung der Attraktivität und Verwundbarkeit des IT-Systems bzw. seiner Komponenten,
Umweltfaktoren und organisationsspezifischen Einflüssen.

Auch die Eintrittswahrscheinlichkeit kann quantitativ oder qualitativ bewertet werden.

Da eine quantitative Bewertung in vielen Fällen eine Genauigkeit vortäuschen könnte, die durch die ungenaue Methode der Schätzung nicht zu rechtfertigen ist, ist in den letzten Jahren ein Trend in Richtung qualitativer Bewertung zu erkennen.

Bewährt haben sich hier etwa drei- bis fünfteilige Skalen, wie beispielsweise:

4: sehr häufig
3: häufig
2: mittel
1: selten
0: sehr selten

Diese allgemeinen Bedeutungen der Skalenwerte sind für den spezifischen Anwendungsbereich zu konkretisieren.

Beispiel:

4: einmal pro Minute
3: einmal pro Stunde
2: einmal pro Tag
1: einmal pro Monat
0: einmal im Jahr

Ergebnis der Bedrohungsanalyse:

Liste von Bedrohungen, der von ihnen bedrohten Objekte, und ihrer Eintrittswahrscheinlichkeiten.

4.2.5 Schwachstellenanalyse

Unter einer Schwachstelle ( vulnerability ) versteht man eine Sicherheitsschwäche eines oder mehrerer Objekte, die durch eine Bedrohung ausgenützt werden kann.

Typische Beispiele für Schwachstellen sind etwa:

Mangelnder baulicher Schutz von Räumen mit IT-Einrichtungen
Nachlässige Handhabung von Zutrittskontrollen
Spannungs- oder Temperaturschwankungen bei Hardwarekomponenten
kompromittierende Abstrahlung
Spezifikations- und Implementierungsfehler
schwache Passwortmechanismen
unzureichende Ausbildung, mangelndes Sicherheitsbewusstsein

Eine Schwachstelle selbst verursacht noch keinen Schaden, sie ist aber die Voraussetzung, die es einer Bedrohung ermöglicht, wirksam zu werden und damit ein IT-System zu beeinträchtigen. Auf Schwachstellen, für die eine korrespondierende Bedrohung existiert, sollte daher sofort reagiert werden.

Eine Schwachstellenanalyse ist die Überprüfung von Sicherheitsschwächen, die durch festgestellte Bedrohungen ausgenutzt werden können. Diese Analyse muss sowohl das Umfeld als auch bereits vorhandene Schutzmaßnahmen mit einbeziehen. Es ist wichtig, jede Schwachstelle daraufhin zu bewerten, wie leicht es ist, sie auszunutzen.

Beispielhafte Auflistungen von Schwachstellen, die auf typische Problembereiche hinweisen, finden sich etwa in [ISO/IEC 27005], Annex D sowie in [BSI 7105], S 199 ff.

Ergebnis der Schwachstellenanalyse:

Liste von potentiellen Schwachstellen mit Angaben darüber, wie leicht diese für einen Angriff ausgenützt werden können.

4.2.6 Identifikation bestehender Sicherheitsmaßnahmen

Sicherheitsmaßnahmen sind Verfahrensweisen, Prozeduren und Mechanismen, die eine oder mehrere der nachfolgenden Funktionen erfüllen:

Vermeidung von Risiken,
Verkleinerung von Bedrohungen oder Schwachstellen,
Entdeckung unerwünschter Ereignisse,
Eingrenzung der Auswirkungen eines unerwünschten Ereignisses,
Überwälzung von Risiken oder
Wiederherstellung eines früheren Zustandes.

Wirksame IT-Sicherheit verlangt im Allgemeinen eine Kombination von verschiedenen Typen von Maßnahmen.

Da die Sicherheitsmaßnahmen, die aufgrund einer Risikoanalyse ausgewählt werden, in der Regel zusätzlich zu bereits bestehenden Maßnahmen eingeführt werden sollen, ist es notwendig, alle bereits existierenden oder geplanten Sicherheitsmaßnahmen zu identifizieren und ihre Auswirkungen zu überprüfen, um unnötigen Aufwand zu vermeiden.

Stellt sich heraus, dass eine bereits existierende oder geplante Maßnahme ihren Anforderungen nicht gerecht wird, so ist zu prüfen, ob sie ersatzlos entfernt, durch andere Maßnahmen ersetzt oder aus Kostengründen belassen werden soll.

Im Rahmen dieses Schrittes sollte auch geprüft werden, ob die bereits existierenden Sicherheitsmaßnahmen korrekt zum Einsatz kommen. Falsch oder unvollständig eingesetzte Sicherheitsmaßnahmen stellen eine zusätzliche potentielle Schwachstelle eines Systems dar.

Ergebnis:

Aufstellung aller bereits existierenden oder geplanten Sicherheitsmaßnahmen mit Angaben über ihren Implementierungsstatus und ihren Einsatz.

4.2.7 Risikobewertung

Ein Risiko ist die Möglichkeit, dass eine Bedrohung unter Ausnutzung einer Schwachstelle Schaden an einem Objekt oder den Verlust eines Objektes und damit direkt oder indirekt einen Schaden verursacht.

Ziel dieses Schrittes ist es, die Risiken, denen ein IT-System und seine Objekte ausgesetzt sind, zu erkennen und zu bewerten, um auf dieser Basis geeignete und angemessene Sicherheitsmaßnahmen auswählen zu können.

Risiken sind eine Funktion folgender Parameter:

Wert der bedrohten Objekte (Schadensausmaß),
Möglichkeit, eine Schwachstelle durch eine Bedrohung auszunutzen,
Eintrittswahrscheinlichkeit einer Bedrohung,
bereits existierende oder geplante Sicherheitsmaßnahmen, die dieses Risiko reduzieren könnten.

Wie diese Größen miteinander verknüpft werden, um die Höhe der Einzelrisiken und des Gesamtrisikos zu bestimmen, ist abhängig von der gewählten Risikoanalysemethode. Wieder können quantitative oder qualitative Bewertungen vorgenommen oder aber beide Möglichkeiten kombiniert werden.

[ISO/IEC 27005] gibt im Anhang vier Beispiele für Methoden zur Risikobewertung.

Es ist zu beachten, dass jegliche Änderung an Werten, Bedrohungen, Schwachstellen oder Sicherheitsmaßnahmen bedeutenden Einfluss auf die Einzelrisiken und auf das Gesamtrisiko haben kann.

Ergebnis:

Quantitative oder qualitative Bewertung von Einzelrisiken und Gesamtrisiko für den betrachteten Analysebereich.

4.2.8 Auswertung und Aufbereitung der Ergebnisse

Der adäquaten Aufbereitung, Auswertung und Interpretation der Ergebnisse einer Risikoanalyse kommt wachsende Bedeutung zu. Da die Risikoanalyse auch als Grundlage für weitreichende weiterführende Entscheidungen dient, ist auf eine klare Darstellung der Situation sowie eine umfassende Ergebnisdarstellung zu achten. Hilfreich dabei sind graphische und tabellarische Darstellungen.

4.3 Grundschutzansatz

Die im Rahmen dieses Handbuches empfohlene Vorgehensweise zur Grundschutzanalyse folgt im Wesentlichen den Vorgaben zum IT-Grundschutz des BSI. In diesem Kapitel wird eine kurze Zusammenfassung des Verfahrens, angepasst an die Erfordernisse der öffentlichen Verwaltung in Österreich, gegeben. Details zum Verfahren finden sich im BSI-Standard 100-2 [BSI 100-2], Kataloge zu Gefährdungen und Sicherheitsmaßnahmen in [BSI-1] bzw. [BSI-2].

4.3.1 Die Idee des IT-Grundschutzes

Ziel des Grundschutzansatzes ist es, den Aufwand für die Erstellung eines Informationssicherheitskonzeptes angemessen zu begrenzen.

Dies wird dadurch erreicht, dass von einer pauschalisierten Gefährdungslage ausgegangen und damit auf eine detaillierte Risikoanalyse verzichtet wird. Die Auswahl der zu realisierenden Sicherheitsmaßnahmen erfolgt auf der Basis vorgegebener Kataloge.

Die Vorteile dieser Vorgehensweise sind:

Der Aufwand für die Risikoanalyse wird stark reduziert.
Der Einsatz von Grundschutzmaßnahmen führt schnell zu einem relativ hohen Niveau an Sicherheit gegen die häufigsten Bedrohungen.

Zudem sind Grundschutzmaßnahmen meist stark verbreitet und damit relativ kostengünstig und schnell zu implementieren.

Dem stehen folgende Nachteile gegenüber:

Der Grundschutzlevel kann für das betrachtete System zu hoch oder zu niedrig sein. Ist er zu hoch, werden unnötige finanzielle und personelle Ressourcen verbraucht, ist er zu niedrig, bleiben unter Umständen untragbare Risiken bestehen.
Aufgrund der fehlenden Risikoanalyse kann unter Umständen eine angemessene Reaktion auf sicherheitsrelevante Hard- oder Softwareänderungen schwierig sein.

Die Wahl eines Grundschutzansatzes wird daher in folgenden Fällen empfohlen:

Wenn feststeht, dass im betrachteten Bereich nur IT-Systeme mit niedrigem oder mittlerem ("normalem") Schutzbedarf zum Einsatz kommen.

Falls in einem Bereich (IT-System, Abteilung, ...) noch keine oder offensichtlich zu schwache Sicherheitsmaßnahmen vorhanden sind, kann die Realisierung von Grundschutzmaßnahmen dazu beitragen, rasch ein relativ gutes Niveau an IT-Sicherheit zu erreichen. In diesem Fall sollte aber in einem nachfolgenden Schritt geprüft werden, ob das erreichte Niveau bereits ausreichend ist oder weitere Analysen und Maßnahmen erforderlich sind.

Als Teil eines umfassenden Risikoanalysekonzeptes ("kombinierter Ansatz"):
Wird zunächst in einem ersten Schritt festgestellt, welche IT-Systeme besonders schutzbedürftig sind ("Schutzbedarfsfeststellung"), so besteht die Möglichkeit, den Arbeitsaufwand für die Risikoanalyse und die Auswahl spezifischer Sicherheitsmaßnahmen auf diese hochschutzbedürftigen Systeme zu konzentrieren. Für alle anderen Systeme können Grundschutzmaßnahmen eingesetzt werden, ohne damit unangemessene Sicherheitsrisiken einzugehen. Details dazu s. Kapitel Kombinierter Ansatz.

4.3.2 Grundschutzanalyse und Auswahl von Maßnahmen

Im Folgenden wird ein reiner Grundschutzansatz beschrieben, d.h. es wird davon ausgegangen, dass entweder bereits eine Schutzbedarfsfeststellung erfolgt ist und damit die IT-Systeme identifiziert sind, für die der IT-Grundschutz zu konzipieren ist, oder dass bewusst (zunächst) ein reiner Grundschutzansatz gewählt wird. Ein kombinierter Ansatz und die Stellung des IT-Grundschutzes in einem solchen werden im nachfolgenden Kapitel beschrieben.

Eine Grundschutzanalyse besteht im Wesentlichen aus den folgenden beiden Teilschritten:

Schritt 1: Nachbildung eines IT-Systems oder eines IT-Verbundes (Kombination mehrerer IT-Systeme) durch vorhandene Bausteine ("Modellierung")

Schritt 2: Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen

4.3.2.1 Modellierung

Die Modellierung eines IT-Systems oder eines IT-Verbundes ist abhängig vom zugrunde liegenden Baustein- und Maßnahmenkatalog, da versucht werden muss, das System durch die vorhandenen Bausteine möglichst genau nachzubilden.

Eine der umfassendsten und ausgereiftesten Sammlungen von Bausteinen und Maßnahmen stellt das IT-Grundschutzhandbuch des BSI dar ( [BSI GSHB]). Anhand dieses Werkes soll nachfolgend die Modellierung eines IT-Verbundes beschrieben werden.

Zentrale Aufgabe des Schrittes "Modellierung" ist es, den betrachteten IT-Verbund mit Hilfe der vorhandenen Bausteine des IT-Grundschutzes nachzubilden. Als Ergebnis wird ein Modell des IT-Verbundes erstellt, das aus verschiedenen, ggf. auch mehrfach verwendeten Bausteinen des Handbuchs besteht und eine Abbildung zwischen den Bausteinen und den sicherheitsrelevanten Aspekten des IT-Verbundes beinhaltet.

Um die Abbildung eines im Allgemeinen komplexen IT-Verbunds auf die Bausteine des Handbuchs zu erleichtern, bietet es sich an, die Sicherheitsaspekte gruppiert nach bestimmten Themen zu betrachten.

Abbildung 4.1: Schichten des IT-Grundschutzmodells nach [BSI GSHB]

Die Sicherheitsaspekte eines IT-Verbunds werden wie folgt den einzelnen Schichten zugeordnet:

Schicht 1 umfasst sämtliche übergreifenden Sicherheitsaspekte, die für sämtliche oder große Teile des IT-Verbunds gleichermaßen gelten. Dies betrifft insbesondere übergreifende Konzepte und die daraus abgeleiteten Regelungen.Typische Bausteine der Schicht 1 sind unter anderem Informationssicherheitsmanagement, Organisation, Datensicherungskonzept und Computer-Virenschutzkonzept.
Schicht 2 befasst sich mit den baulich-technischen Gegebenheiten, in der Aspekte der infrastrukturellen Sicherheit zusammengeführt werden. Dies betrifft insbesondere die Bausteine Gebäude, Räume, Schutzschränke und häuslicher Arbeitsplatz.
Schicht 3 betrifft die einzelnen IT-Systeme des IT-Verbunds, die ggf. in Gruppen zusammengefasst wurden. Hier werden die Sicherheitsaspekte sowohl von Clients als auch von Servern, aber auch von Stand-alone-Systemen behandelt. In die Schicht 3 fallen damit beispielsweise die Bausteine Unix-System, Tragbarer PC, Windows NT Netz und TK-Anlage.
Schicht 4 betrachtet die Kommunikations- und Vernetzungsaspekte der IT-Systeme, wie etwa die Bausteine Netz- und Systemmanagement und Firewalls.
Schicht 5 schließlich beschäftigt sich mit den eigentlichen IT-Anwendungen, die im IT-Verbund genutzt werden. In dieser Schicht können unter anderem die Bausteine E-Mail, WWW-Server, Faxserver und Datenbanken zur Modellierung verwendet werden.

Die in diesem Schritt zu leistende Aufgabe besteht darin, das reale IT-System durch die vorhandenen Bausteine möglichst genau nachzubilden.

Abschließend sollte überprüft werden, ob die Modellierung des Gesamtsystems vollständig ist und keine Lücken aufweist. Es wird empfohlen, hierzu den Netzplan oder eine vergleichbare Übersicht über den IT-Verbund heranzuziehen und die einzelnen Komponenten systematisch durchzugehen. Jede Komponente sollte entweder einer Gruppe zugeordnet oder einzeln modelliert worden sein.

Wichtig ist, dass nicht nur alle Hard- und Software-Komponenten in technischer Hinsicht nachgebildet sind, sondern dass auch die zugehörigen organisatorischen, personellen und infrastrukturellen Aspekte vollständig abgedeckt sind.

4.3.2.2 Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen

Im zweiten Schritt der Grundschutzanalyse wird die Modellierung nach IT-Grundschutz als Prüfplan verwendet, um festzustellen, welche Standardsicherheitsmaßnahmen bereits umgesetzt wurden, bzw. welche nicht oder unzureichend umgesetzt wurden.

Das SOLL besteht aus den in den einzelnen Bausteinen empfohlenen Maßnahmen. Der Vergleich mit den vorhandenen Maßnahmen ergibt als Resultat die Maßnahmen, die es noch für den IT-Grundschutz umzusetzen gilt.

Der eigentliche Soll-Ist-Vergleich soll mittels Interviews und stichprobenartiger Kontrollen durchgeführt werden.

Vorgehen bei Abweichungen

Für die Errichtung eines IT-Grundschutzes sollten zwar prinzipiell alle im Baustein vorgeschlagenen IT-Grundschutzmaßnahmen umgesetzt werden, es besteht jedoch die Möglichkeit, dass bei bestimmten Einsatzumgebungen empfohlene Grundschutzmaßnahmen nicht umgesetzt werden können oder sollten. Diese Abweichung von der Empfehlung ist dann zu dokumentieren und zu begründen.

An dieser Stelle sollten auch eventuell vorhandene über den IT-Grundschutz hinausgehende IT-Sicherheitsmaßnahmen herausgearbeitet und dokumentiert werden.

Dokumentation der Ergebnisse

Zu jeder Maßnahme sollten

der Umsetzungsgrad (ja/teilweise/nein/entbehrlich) sowie, soweit zu diesem Zeitpunkt bereits möglich,
die Verantwortlichkeiten für die Umsetzung
der Zeitpunkt für die Umsetzung und
eine Kostenschätzung

angegeben werden.

Für die Durchführung einer Grundschutzanalyse in einer komplexen Einsatzumgebung empfiehlt sich der Einsatz eines Tools. Bekanntestes Beispiel ist das im Auftrag des BSI entwickelte "IT-Grundschutz-Tool". Hierdurch ergeben sich komfortable Möglichkeiten zur Auswertung und Revision der Ergebnisse, beispielsweise die Suche nach bestimmten Einträgen, der Generierung benutzerdefinierter Reports sowie Statistikfunktionen.

Ergebnis

Die beschriebene Vorgehensweise liefert als Ergebnis eine Liste von Maßnahmen, die es für die Erreichung des IT-Grundschutzes noch umzusetzen gilt.

4.4 Kombinierter Ansatz

Die Stärken beider oben diskutierter Risikoanalysestrategien - Zeit sparende Auswahl kostengünstiger IT-Sicherheitsmaßnahmen durch Grundschutzanalysen und wirksame Reduktion hoher Sicherheitsrisiken durch detaillierte Risikoanalysen - kommen in einem sog. kombinierten Ansatz zum Tragen.

Dabei wird zunächst ermittelt, welche IT-Systeme hohe oder sehr hohe Sicherheitsanforderungen haben, und welche niedrige bis mittlere haben (Schutzbedarfsfeststellung). Das Ergebnis dieses Schrittes ist eine Einteilung in zwei Schutzbedarfskategorien: "niedrig bis mittel" und "hoch bis sehr hoch".

IT-Systeme der Schutzbedarfskategorie "niedrig bis mittel" werden einer Grundschutzanalyse unterzogen, während IT-Systeme der Schutzbedarfskategorie "hoch bis sehr hoch" einer detaillierten Risikoanalyse zu unterziehen sind, auf deren Basis individuelle Sicherheitsmaßnahmen ausgewählt werden.

Alternativ dazu können auch etwa drei Schutzbedarfskategorien gewählt werden (s. Kap. 4.4.1, zweites Beispiel). Dabei werden IT-Systeme der Schutzbedarfskategorie "normal" einer Grundschutzanalyse unterzogen. IT-Systeme der Schutzbedarfskategorie "hoch" sind einer eingehenderen Betrachtung zu unterziehen. Wahlweise sind auch hier Grundschutzmaßnahmen (ev. in verstärktem Maße) anzuwenden, oder es ist eine detaillierte Risikoanalyse durchzuführen. IT-Systeme der Schutzbedarfskategorie "sehr hoch" sind jedenfalls einer detaillierten Risikoanalyse zu unterziehen, auf deren Basis individuelle Sicherheitsmaßnahmen ausgewählt werden.

Generell empfiehlt es sich, zunächst eine Grundschutzanalyse für alle Systeme durchzuführen anschließend eine eventuelle erforderliche detaillierte Risikoanalyse für Systeme höherer Schutzbedarfskategorien.

Vorteile eines kombinierten Ansatzes

Die Vorgehensweise ermöglicht es, rasch einen relativ guten Sicherheitslevel für alle IT-Systeme zu realisieren.
Die in der Schutzbedarfsfeststellung erarbeiteten Erkenntnisse können die Grundlage für eine Prioritätenreihung für die nachfolgenden Aktivitäten bilden.
Der Aufwand kann auf hochsicherheitsbedürftige Systeme konzentriert werden.
Das Verfahren findet im Allgemeinen hohe Akzeptanz, da es mit verhältnismäßig geringem Initialaufwand rasch sichtbare Erfolge bringt.

Empfehlung:

Aus diesen Gründen wird empfohlen, als Risikoanalysestrategie einen kombinierten Ansatz zu wählen.

4.4.1 Festlegung von Schutzbedarfskategorien

Voraussetzung für eine Schutzbedarfsfeststellung ist die Festlegung von Schutzbedarfskategorien.

Die nachfolgende Tabelle gibt eine Orientierungshilfe für die Festlegung der Schutzbedarfskategorien und damit die Klassifizierung der Anwendungen anhand der maximal möglichen Schäden anhand von Grenzwerten. Diese sind jedoch nur als Beispiele zu sehen. Jede Organisation sollte für sich prüfen, ob diese Klassifizierung ihren Anforderungen entspricht und gegebenenfalls eigene Grenzwerte und Einordnungen festlegen.

Weiters ist darauf hinzuweisen, dass die in der Tabelle angeführten sieben Schadenskategorien nicht vollständig sein müssen. Für alle Schäden, die sich nicht in diesen Kategorien abbilden lassen, ist ebenfalls eine Aussage zu treffen, wo die Grenze zwischen "niedrig bis mittel" und "hoch bis sehr hoch" zu ziehen ist.

	Schutzbedarfskategorie "niedrig bis mittel"	Schutzbedarfskategorie "hoch bis sehr hoch"
1. Verstoß gegen Gesetze, Vorschriften oder Verträge	Verstöße gegen Vorschriften und Gesetze mit geringfügigen Konsequenzen Geringfügige Vertragsverletzungen mit geringen Konventionalstrafen Ein möglicher Missbrauch personenbezogener Daten hat nur geringfügige Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse der/des Betroffenen.	Schwere Verstöße gegen Gesetze und Vorschriften (Strafverfolgung) Vertragsverletzungen mit hohen Konventionalstrafen oder Haftungsschäden Ein möglicher Missbrauch personenbezogener Daten hat erhebliche Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse der/des Betroffenen (Verlust der Vertraulichkeit oder Integrität sensibler Daten)
2. Beeinträchtigung der persönlichen Unversehrtheit	Eine Beeinträchtigung erscheint nicht möglich.	Eine über Bagatellverletzungen hinausgehende Beeinträchtigung der persönlichen Unversehrtheit kann nicht absolut ausgeschlossen werden.
3. Beeinträchtigung der Aufgabenerfüllung	Es kann zu einer leichten bis maximal mittelschweren Beeinträchtigung der Aufgabenerfüllung kommen. Eine Zielerreichung ist mit vertretbarem Mehraufwand möglich.	Es kann zu einer schweren Beeinträchtigung der Aufgabenerfüllung bis hin zur Handlungsunfähigkeit der betroffenen Organisation kommen. Bedeutende Zielabweichung in Qualität und/oder Quantität.
4. Vertraulichkeit der verarbeiteten Information	Es werden nur Daten der Sicherheitsklassen OFFEN und EINGESCHRÄNKT verarbeitet bzw. gespeichert.	Es werden auch Daten der Sicherheitsklassen VERTRAULICH, GEHEIM und/oder STRENG GEHEIM verarbeitet bzw. gespeichert.
5. Dauer der Verzichtbarkeit	Die maximal tolerierbare Ausfallszeit der Anwendung beträgt mehrere Stunden bis mehrere Tage.	Die maximal tolerierbare Ausfallszeit des Systems beträgt lediglich einige Minuten.
6. Negative Außenwirkung	Eine geringe bzw. nur interne Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.	Eine breite Beeinträchtigung des Vertrauens in die Organisation oder ihr Ansehen ist zu erwarten.
7. Finanzielle Auswirkungen	Der finanzielle Schaden ist kleiner als (z.B.) Euro 50.000.--.	Der zu erwartende finanzielle Schaden ist größer als (z.B.) Euro 50.000.--.

Tabelle 4.1: Beispiel für die Festlegung der Schutzbedarfskategorien

Eine andere Möglichkeit besteht darin, drei Schutzbedarfskategorien zu definieren:

Schutzbedarfskategorie "normal":
Die Schadensauswirkungen sind begrenzt und überschaubar. Maßnahmen des IT-Grundschutzes reichen im Allgemeinen aus. Diese Kategorie entspricht der obigen Kategorie "niedrig bis mittel".

Schutzbedarfskategorie "hoch":
Die Schadensauswirkungen können beträchtlich sein. Wahlweise können weiter (verstärkte) Grundschutzmaßnahmen eingesetzt oder eine detaillierte Risikoanalyse durchgeführt werden.

Schutzbedarfskategorie "sehr hoch":
Die Schadensauswirkungen können ein existentiell bedrohliches, katastrophales Ausmaß erreichen. IT-Grundschutzmaßnahmen alleine reichen nicht aus, die erforderlichen Sicherheitsmaßnahmen sollten individuell auf Basis einer Risikoanalyse ermittelt werden.

Schutzbedarfskategorie "hoch":
Die nachfolgende Tabelle gibt eine Orientierungshilfe für die Festlegung der Schutzbedarfskategorien und damit die Klassifizierung der Anwendungen anhand der oben angeführten Einteilungen. Diese sind wiederum als Beispiele zu sehen. Jede Organisation sollte für sich prüfen, ob diese Klassifizierung ihren Anforderungen entspricht und gegebenenfalls eigene Grenzwerte und Einordnungen festlegen.

	Schutzbedarfskategorie "normal"	Schutzbedarfskategorie "hoch"	Schutzbedarfskategorie "sehr hoch"
1. Verstoß gegen Gesetze, Vorschriften oder Verträge	Verstöße gegen Vorschriften und Gesetze mit geringfügigen Konsequenzen Geringfügige Vertragsverletzungen mit keinen oder geringen Konventionalstrafen Ein möglicher Missbrauch personenbezogener Daten hat nur geringfügige Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse der/des Betroffenen.	Verstöße gegen Vorschriften und Gesetze mit erheblichen Konsequenzen Vertragsverletzungen mit hohen Konventionalstrafen Ein möglicher Missbrauch personenbezogener Daten hat erhebliche Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse der/des Betroffenen.	Schwere Verstöße gegen Gesetze und Vorschriften (Strafverfolgung) Vertragsverletzungen, deren Haftungsschäden ruinös sind Ein möglicher Missbrauch personenbezogener Daten würde für die/den Betroffene/n den gesellschaftlichen oder wirtschaftlichen Ruin bedeuten.
2. Beeinträchtigung der persönlichen Unversehrtheit	Eine Beeinträchtigung erscheint nicht möglich.	Eine Beeinträchtigung der persönlichen Unversehrtheit kann nicht absolut ausgeschlossen werden.	Gravierende Beeinträchtigungen der persönlichen Unversehrtheit sind möglich. Gefahr für Leib und Leben
3. Beeinträchtigung der Aufgabenerfüllung	Es kann zu einer leichten bis maximal mittelschweren Beeinträchtigung der Aufgabenerfüllung kommen. Eine Zielerreichung ist mit vertretbarem Mehraufwand möglich.	Es kann zu einer schweren Beeinträchtigung der Aufgabenerfüllung kommen. Bedeutende Zielabweichung in Qualität und/oder Quantität.	Es kann zu einer sehr schweren Beeinträchtigung der Aufgabenerfüllung bis hin zur Handlungsunfähigkeit der betroffenen Organisation kommen.
4. Vertraulichkeit der verarbeiteten Information	Es werden nur Daten der Sicherheitsklassen OFFEN und EINGESCHRÄNKT verarbeitet bzw. gespeichert.	Es werden auch Daten der Klasse VERTRAULICH verarbeitet bzw. gespeichert.	Es werden auch Daten der Klassen GEHEIM und/oder STRENG GEHEIM verarbeitet bzw. gespeichert.
5. Dauer der Verzichtbarkeit	Die maximal tolerierbare Ausfallszeit der Anwendung beträgt mehr als 24 Stunden.	Die maximal tolerierbare Ausfallszeit des Systems liegt zwischen einer und 24 Stunden.	Die maximal tolerierbare Ausfallszeit des Systems ist kleiner als eine Stunde.
6. Negative Außenwirkung	Eine geringe bzw. nur interne Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.	Eine breite Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.	Eine landesweite breite Ansehens- oder Vertrauensbeeinträchtigung, evtl. sogar existenzgefährdender Art, ist zu erwarten.
7. Finanzielle Auswirkungen	Der finanzielle Schaden liegt unter (z.B.) Euro 50.000.--.	Der Schaden bewirkt beachtliche finanzielle Verluste, ist jedoch nicht existenzbedrohend.	Der finanzielle Schaden ist für die Institution existenzbedrohend.

Tabelle 4.2: Beispiel für die alternative Festlegung der Schutzbedarfskategorien

4.4.2 Schutzbedarfsfeststellung

Die Schutzbedarfsfeststellung bildet die Grundlage für eine Entscheidung über die weitere Vorgehensweise und ist daher mit entsprechender Sorgfalt durchzuführen.

Die Schutzbedarfsfeststellung erfolgt in 3 Schritten:

Schritt 1: Erfassung aller vorhandenen oder geplanten IT-Systeme
Schritt 2: Erfassung der IT-Anwendungen und Zuordnung zu den einzelnen IT-Systemen
Schritt 3: Schutzbedarfsfeststellung für jedes IT-System

4.4.2.1 Erfassung aller vorhandenen oder geplanten IT-Systeme

Zunächst werden die vorhandenen und geplanten IT-Systeme aufgelistet. Hierbei steht die technische Realisierung eines IT-Systems im Vordergrund, z.B. Stand-Alone-PC, Server, PC-Client, Windows-Server. An dieser Stelle soll nur das System als solches erfasst werden (z.B. Windows-Server), nicht die einzelnen Bestandteile, wie Rechner, Tastatur, Bildschirm, Drucker etc., aus denen das IT-System zusammengesetzt ist.

Zur Reduktion der Komplexität kann man gleiche IT-Systeme zu Gruppen zusammenfassen, wenn von Anwendungsstruktur und -ablauf vergleichbare Anwendungen auf diesen Systemen laufen. Dies gilt insbesondere für PCs, die oft in großer Anzahl vorhanden sind.

4.4.2.2 Erfassung der IT-Anwendungen und Zuordnung zu den einzelnen IT-Systemen

Ziel dieses Schrittes ist es, alle oder zumindest die wichtigsten auf dem betrachteten IT-System laufenden oder geplanten IT-Anwendungen zu erfassen.

Diese sollten anschließend - soweit zu diesem Zeitpunkt bereits möglich - nach ihrem Sicherheitsbedarf vorsortiert werden. Dabei sind zuerst diejenigen Anwendungen des jeweiligen IT-Systems zu benennen,

deren Daten/Informationen und Programme den höchsten Bedarf an Vertraulichkeit haben,
deren Daten/Informationen und Programme den höchsten Bedarf an Integrität aufweisen,
die die kürzeste tolerierbare Ausfallszeit haben.

4.4.2.3 Schutzbedarfsfeststellung für jedes IT-System

In dieser Phase soll die Frage beantwortet werden, welche Schäden zu erwarten sind, wenn Vertraulichkeit, Integrität oder Verfügbarkeit einer IT-Anwendung und/oder der zugehörigen Informationen ganz oder teilweise verloren gehen. Die zu erwartenden Schäden bestimmen den Schutzbedarf. Dabei ist es unbedingt auch erforderlich, die Applikations-/Projektverantwortlichen und die Benutzer/innen der betrachteten IT-Anwendungen nach ihrer Einschätzung zu befragen.

Als Orientierungshilfe für die Einordnung von IT-Anwendungen in Schutzbedarfskategorien kann die in Abschnitt 4.4.1 angeführte Tabelle dienen. Es ist aber empfehlenswert, eine den spezifischen Anforderungen der betroffenen Organisation entsprechende modifizierte Tabelle zu erstellen.

Die Ermittlung des Schutzbedarfes erfolgt nach dem Maximum-Prinzip. Ist für alle auf einem System laufenden Anwendungen ein normaler Schutzbedarf erhoben worden, so ist das gesamte System in die Schutzbedarfskategorie "normal" einzuordnen. Die Realisierung von Grundschutzmaßnahmen bietet hier in der Regel einen ausreichenden Schutz. Wurde dagegen mindestens eine Applikation mit hohem oder sehr hohem Schutzbedarf ermittelt, so ist das gesamte IT-System in die Schutzbedarfskategorie "hoch" bzw. "sehr hoch" einzuordnen.

4.4.3 Durchführung von Grundschutzanalysen und detaillierten Risikoanalysen

Für alle IT-Systeme der Schutzbedarfskategorie "niedrig bis mittel" bzw. "normal" ist eine Grundschutzanalyse gemäß der in Kapitel Grundschutzansatz beschriebenen Vorgehensweise durchzuführen.

Alle IT-Systeme der Schutzbedarfskategorie "hoch bis sehr hoch" sind einer detaillierten Risikoanalyse zu unterziehen. Die Auswahl einer konkreten Methode zur Risikoanalyse sowie der eventuelle Einsatz eines Tools zur Unterstützung dieser Analyse bleiben der durchführenden Institution überlassen. Details dazu finden sich in Kapitel Detaillierte Risikoanalyse dieses Handbuches.

Geht man von drei Schutzbedarfskategorien aus, so ist für IT-Systeme der Schutzbedarfskategorie "hoch" zu überlegen, ob mit (ev. verstärkten) Grundschutzmaßnahmen das Auslangen gefunden werden kann, oder eine detaillierte Risikoanalyse erforderlich ist. IT-Systeme der Schutzbedarfskategorie "sehr hoch" sind jedenfalls einer detaillierten Risikoanalyse zu unterziehen.

4.5 Akzeptables Restrisiko

Sicherheitsmaßnahmen können für gewöhnlich Risiken nur teilweise mindern. Im Allgemeinen verbleibt ein Restrisiko, dessen Abdeckung wirtschaftlich nicht mehr vertretbar wäre. Es ist notwendig, diese Restrisiken so exakt wie möglich zu quantifizieren und sie dann bewusst zu akzeptieren. Dieser Prozess wird als "Risikoakzeptanz" bezeichnet.

Um ein organisationsweit einheitliches Niveau des Restrisikos zu gewährleisten, ist es hilfreich, diesen Prozess durch generelle Richtlinien zu unterstützen. Diese sollten im Rahmen der Informationssicherheitspolitik definiert werden (vgl. Kapitel Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken) und festlegen, welche Risiken die betroffene Organisation generell zu akzeptieren bereit ist.

Dabei ist zu beachten, dass durch Kumulationseffekte oder gegenseitige Beeinflussungen eine Reihe von kleinen Einzelrisiken zu einem inakzeptablen Restrisiko führen kann.

Die Entscheidung über die Akzeptanz von Restrisiken ist daher immer eine für das spezielle System zu treffende Managemententscheidung.

4.6 Akzeptanz von außergewöhnlichen Restrisiken

Verbleibt nach Durchführung aller vorgesehenen Sicherheitsmaßnahmen ein Restrisiko, das höher ist als das generell akzeptable, so sollten zusätzliche Sicherheitsmaßnahmen vorgesehen und damit das Risiko weiter reduziert werden.

Ist dies technisch nicht möglich oder unwirtschaftlich, so besteht in begründeten Ausnahmefällen die Möglichkeit, dieses erhöhte Restrisiko bewusst anzunehmen.

Die Entscheidung über die Akzeptanz eines außergewöhnlichen Restrisikos ist durch das Management zu treffen, die genauen Verantwortlichkeiten dafür sind in der Informationssicherheitspolitik festzulegen. Die Entscheidung ist schriftlich zu begründen und durch die Leitung der Organisation in schriftlicher Form zu akzeptieren.

5 Erstellung von Sicherheitskonzepten

Ausgehend von den in der Risikoanalyse ermittelten Sicherheitsanforderungen wird ein Sicherheitskonzept erstellt. Dies erfolgt durch die Auswahl geeigneter Maßnahmen, die die Risiken auf ein akzeptables Maß reduzieren und unter dem Gesichtspunkt von Kosten und Nutzen eine optimale Lösung darstellen.

Ein Sicherheitskonzept enthält

die Beschreibung des Ausgangszustandes einschließlich der bestehenden Risiken (Ergebnisse der vorangegangenen Risikoanalyse),
die Festlegung der durchzuführenden Maßnahmen,
die Begründung der Auswahl unter Kosten/Nutzen-Aspekten und hinsichtlich des Zusammenwirkens der einzelnen Maßnahmen,
eine Abschätzung des Restrisikos sowie eine verbindliche Aussage über die Akzeptanz des verbleibenden Restrisikos,
die Festlegung der Verantwortlichkeiten für die Auswahl und Umsetzung der Maßnahmen sowie für die regelmäßige Überprüfung des Konzeptes sowie
eine Prioritäten-, Termin- und Ressourcenplanung für die Umsetzung.

Die Erstellung eines Sicherheitskonzeptes erfolgt in vier Schritten:

Schritt 1: Auswahl von Maßnahmen
Schritt 2: Prüfung von Restrisiken und Risikoakzeptanz
Schritt 3: Erstellung von Sicherheitsrichtlinien
Schritt 4: Erstellung eines Informationssicherheitsplanes

Diese vier Schritte werden in den folgenden Kapiteln näher beschrieben.

5.1 Auswahl von Maßnahmen

Sicherheitsmaßnahmen sind Verfahrensweisen, Prozeduren und Mechanismen, die die Sicherheit von Informationen und der sie verarbeitenden IT-Systeme erhöhen. Dies kann auf unterschiedliche Arten erreicht werden.

Sicherheitsmechanismen können

Risiken vermeiden,
Bedrohungen oder Schwachstellen verkleinern,
unerwünschte Ereignisse entdecken,
die Auswirkung eines unerwünschten Ereignisses eingrenzen,
Risiken überwälzen oder
es möglich machen, einen früheren Zustand wiederherzustellen.

5.1.1 Klassifikation von Sicherheitsmaßnahmen

Je nach Betrachtungsweise kann eine Klassifikation von Sicherheitsmaßnahmen hinsichtlich nachfolgender Kriterien getroffen werden.

5.1.1.1 Klassifikation nach Art der Maßnahmen

Dies ist die "klassische" Einteilung der Sicherheitsmaßnahmen.

Man unterscheidet:

(informations-)technische Maßnahmen
bauliche Maßnahmen
organisatorische Maßnahmen
personelle Maßnahmen

5.1.1.2 Klassifikation nach Anwendungsbereichen

Man unterscheidet:

Maßnahmen, die organisationsweit (oder in Teilen der Organisation) einzusetzen sind.

Dazu gehören:

Etablierung eines ISM-Prozesses und Erstellung von Informationssicherheitspolitiken
organisatorische Maßnahmen (z.B. Kontrolle von Betriebsmitteln, Dokumentation, Rollentrennung)
Überprüfung der IT-Sicherheitsmaßnahmen auf Übereinstimmung mit den Informationssicherheitspolitiken (Security Compliance Checking), Auditing
Reaktion auf sicherheitsrelevante Ereignisse (Incident Handling)
personelle Maßnahmen (incl. Schulung und Bildung von Sicherheitsbewusstsein)
bauliche Sicherheit und Infrastruktur
Notfallvorsorge

Systemspezifische Maßnahmen.

Die Auswahl systemspezifischer Maßnahmen hängt in hohem Maße vom Typ des zu schützenden IT-Systems ab. Man unterscheidet etwa:

Nicht-vernetzte Systeme (Stand-Alone-PCs)
Workstations in einem Netzwerk
Server in einem Netzwerk

5.1.1.3 Klassifikation nach Gefährdungen und Sicherheitsanforderungen

Ausgehend von den Grundbedrohungen gegen ein IT-System (Verlust der Vertraulichkeit, Integrität, Verfügbarkeit, etc.) werden die typischen Gefährdungen ermittelt.

Man unterscheidet daher:

Maßnahmen zur Gewährleistung der Vertraulichkeit ( confidentiality )
Maßnahmen zur Gewährleistung der Integrität ( integrity )
Maßnahmen zur Gewährleistung der Verfügbarkeit ( availability )
Maßnahmen zur Gewährleistung der Zurechenbarkeit ( accountability )
Maßnahmen zur Gewährleistung der Authentizität ( authenticity )
Maßnahmen zur Gewährleistung der Zuverlässigkeit ( reliability )

Wirksame Informationssicherheit verlangt im Allgemeinen eine Kombination von verschiedenen Sicherheitsmaßnahmen, wobei auf die Ausgewogenheit von technischen und nicht-technischen Maßnahmen zu achten ist.

5.1.2 Ausgangsbasis für die Auswahl von Maßnahmen

Liste existierender bzw. geplanter Sicherheitsmaßnahmen:

Bei der Auswahl von Sicherheitsmaßnahmen zur Verminderung der Risiken wird vorausgesetzt, dass im vorhergehenden Schritt - der Risikoanalyse - die bereits existierenden Sicherheitsmaßnahmen aufgelistet wurden.

Im Fall einer detaillierten Risikoanalyse erfolgt dies im Rahmen der "Identifikation bestehender Schutzmaßnahmen" (vgl. Kapitel Identifikation bestehender Sicherheitsmaßnahmen), die als Ergebnis eine Aufstellung aller existierenden oder bereits geplanten Schutzmaßnahmen mit Angaben über ihren Implementierungsstatus und ihren Einsatz liefern soll. Bei einer Grundschutzanalyse werden die vorhandenen Maßnahmen im Rahmen des Soll-Ist-Vergleiches (vgl. Kapitel Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen) ermittelt.

Ergebnisse der Risikobewertung:

Die Auswahl der Sicherheitsmaßnahmen, die die Risiken auf ein definiertes und beherrschbares Maß reduzieren, muss auf den Ergebnissen der Risikobewertung basieren.

Diese Auswahl wird von einer Reihe von Faktoren beeinflusst:

der Stärke der einzelnen Maßnahmen
ihrer Benutzerfreundlichkeit und Transparenz für die Anwender/innen
der Art der Schutzfunktion (Verringerung von Bedrohungen, Erkennen von Verletzungen, ...)

In der Regel stehen verschiedene mögliche Sicherheitsmaßnahmen zur Auswahl. Um die sowohl aus Sicherheits- als auch aus Wirtschaftlichkeitsüberlegungen effizienteste Lösung zu finden, kann im Einzelfall eine Kosten-/Nutzen-Analyse bzw. ein direkter Vergleich einzelner Sicherheitsmaßnahmen ( trade-off analysis) notwendig sein.

5.1.3 Auswahl von Maßnahmen auf Basis einer detaillierten Risikoanalyse

Wurde eine detaillierte Risikoanalyse durchgeführt, so stehen für die Auswahl von geeigneten Sicherheitsmaßnahmen detailliertere und spezifischere Informationen zur Verfügung als im Fall einer Grundschutzanalyse. Je genauer und aufwändiger die Risikoanalyse durchgeführt wurde, desto qualifizierter ist im Allgemeinen die für den Auswahlprozess zur Verfügung stehende Information.

In der Mehrzahl der Fälle wird es verschiedene Maßnahmen zur Erfüllung einer bestimmten Sicherheitsanforderung geben, die sich jedoch hinsichtlich ihrer Effizienz und ihrer Kosten unterscheiden. Umgekehrt kann eine Maßnahme gleichzeitig mehrere Sicherheitsanforderungen abdecken.

Welche der in Frage kommenden Maßnahmen tatsächlich ausgewählt und implementiert werden, hängt von den speziellen Umständen ab. Generell ist festzuhalten, dass Sicherheitsmaßnahmen einen oder mehrere der folgenden Aspekte abdecken können:

Vorbeugung (präventive Maßnahmen)
Aufdeckung (detektive Maßnahmen)
Abschreckung
Schadensbegrenzung
Wiederherstellung eines früheren Zustandes
Bildung von Sicherheitsbewusstsein
Risikoüberwälzung

Welche dieser Eigenschaften notwendig bzw. wünschenswert ist, ist vom spezifischen Fall abhängig. In der Regel wird man Maßnahmen bevorzugen, die mehrere dieser Aspekte abdecken. Es ist aber auch darauf zu achten, dass die Gesamtheit der ausgewählten Maßnahmen ein ausgewogenes Verhältnis der einzelnen Aspekte aufweist, dass also nicht beispielsweise ausschließlich detektive oder ausschließlich präventive Maßnahmen zum Einsatz kommen.

5.1.4 Auswahl von Maßnahmen im Falle eines Grundschutzansatzes

Grundsätzlich ist die Auswahl von Sicherheitsmaßnahmen im Falle eines Grundschutzansatzes relativ einfach. In Maßnahmenkatalogen wird eine Reihe von Schutzmaßnahmen gegen die meisten üblichen Bedrohungen angeführt. Die betreffenden Bedrohungen werden a priori, d.h. ohne weitere Risikoanalyse, als relevant für die durchführende Organisation angenommen. Die empfohlenen Maßnahmen werden mit den existierenden oder bereits geplanten Maßnahmen verglichen. Die noch nicht existierenden bzw. geplanten Maßnahmen werden in eine Liste von noch zu realisierenden Maßnahmen zusammengefasst.

Standardwerke zur Auswahl von Maßnahmen:

In Teil 2 dieses Sicherheitshandbuches werden die wichtigsten Grundschutzmaßnahmen für die öffentliche Verwaltung in Österreich aufgeführt. Alternativ kann auch auf andere bestehende Kataloge zurückgegriffen werden.

Eine sehr umfangreiche Sammlung von Grundschutzmaßnahmen, die kontinuierlich weiterentwickelt werden, findet sich etwa in den Maßnahmenkatalogen zum IT-Grundschutz des BSI (vgl. Kapitel Grundschutzansatz dieses Handbuches). Die Unterstützung durch das "IT-Grundschutz-Tool" erleichtert die Auswahl, Dokumentation und Verwaltung der Maßnahmen.

5.1.5 Auswahl von Maßnahmen im Falle eines kombinierten Risikoanalyseansatzes

Im Falle eines kombinierten Ansatzes werden zunächst anhand eines Grundschutzkataloges (etwa [BSI GSHB] oder spezifische Maßnahmenkataloge) entsprechende Schutzmaßnahmen ausgewählt und umgesetzt, die einerseits ein adäquates Sicherheitsniveau für Systeme der Schutzbedarfsklasse "niedrig bis mittel" gewährleisten, andererseits auch für hochschutzbedürftige Systeme bereits ein gewisses Maß an Schutz bieten. Anschließend werden die noch fehlenden Sicherheitsmaßnahmen für IT-Systeme mit hohen bis sehr hohen Sicherheitsanforderungen ausgewählt.

5.1.6 Bewertung von Maßnahmen

Unabhängig von der verfolgten Strategie ist es in jedem Fall notwendig, die Auswirkungen der ausgewählten Maßnahmen zu analysieren. Damit soll gewährleistet werden, dass die zusätzlichen Maßnahmen mit dem IT-Gesamtkonzept und den bereits bestehenden Sicherheitsmaßnahmen verträglich sind, d.h. dass sie einander ergänzen und unterstützen und sich nicht etwa gegenseitig behindern oder in ihrer Wirkung schwächen. In diesem Stadium ist auch die Einbeziehung der betroffenen Benutzer/innen zu empfehlen, da die Wirksamkeit von Sicherheitsmaßnahmen stark davon abhängt, in welchem Maß sie akzeptiert oder aber abgelehnt oder umgangen werden. Die Akzeptanz von Maßnahmen steigt, wenn ihre Notwendigkeit für die Benutzer/innen einsichtig ist.

Zur Bewertung von Sicherheitsmaßnahmen ist wie folgt vorzugehen:

Erfassung aller Bedrohungen, gegen die die ausgewählten Maßnahmen wirken,
Beschreibung der Auswirkung der Einzelmaßnahmen,
Beschreibung des Zusammenwirkens der ausgewählten und der bereits vorhandenen Sicherheitsmaßnahmen,
Überprüfung, ob und inwieweit die Maßnahmen zu Behinderungen beim Betrieb des IT-Systems führen können,
Überprüfung der Vereinbarkeit der Maßnahmen mit geltenden rechtlichen Vorschriften und Richtlinien und
Bewertung, in welchem Ausmaß die Maßnahmen eine Reduktion der Risiken bewirken.

Bevor die Maßnahmen umgesetzt werden, sollte die Leitungsebene entscheiden, ob die Kosten für die Realisierung der Maßnahmen im richtigen Verhältnis zur Reduzierung der Risiken stehen und ob die Risiken auf ein akzeptables Maß beschränkt werden.

5.1.7 Rahmenbedingungen

Bei der Auswahl und Umsetzung von Sicherheitsmaßnahmen sind stets auch Rahmenbedingungen ( constraints ) zu berücksichtigen, die entweder durch das Umfeld vorgegeben oder durch das Management festgelegt werden.

Beispiele für solche Rahmenbedingungen sind:

Zeitliche Rahmenbedingungen
Etwa: Wie schnell ist auf ein erkanntes Risiko zu reagieren? Wann kann/muss eine Maßnahme realisiert sein?
Finanzielle Rahmenbedingungen
Im Allgemeinen werden budgetäre Einschränkungen existieren. Die Kosten für Sicherheitsmaßnahmen müssen in einem angemessenen Verhältnis zum Wert der zu schützenden Objekte stehen.
Umweltbedingungen
Auch durch das Umfeld vorgegebene Rahmenbedingungen, wie etwa die Lage eines Gebäudes, klimatische Bedingungen und Platzangebot können die Auswahl von Sicherheitsmaßnahmen beeinflussen.
Technische Rahmenbedingungen
z.B. Kompatibilität von Hard- und/oder Software

Weitere Einschränkungen können organisatorischer, personeller, gesetzlicher oder sozialer Natur sein.

Auch Rahmenbedingungen können im Laufe der Zeit, durch soziale Veränderungen oder durch Veränderungen im technischen oder organisatorischen Umfeld, einem Wandel unterliegen und sind daher regelmäßig zu überprüfen und zu hinterfragen.

5.2 Risikoakzeptanz

Absolute Sicherheit ist nicht erreichbar - auch nach Auswahl und Umsetzung aller angemessenen Sicherheitsmaßnahmen verbleibt im Allgemeinen ein Restrisiko. Um zu entscheiden, ob dieses für die betreffende Organisation tragbar ist oder weitere Maßnahmen zu veranlassen sind, ist wie folgt vorzugehen:

Schritt 1: Quantifizierung des Restrisikos

In diesem ersten Schritt ist das Restrisiko so exakt wie möglich zu ermitteln. Dabei bedient man sich am besten der Verfahren und Erkenntnisse aus der vorangegangenen Risikoanalyse.

Schritt 2: Bewertung der Restrisiken

Die verbleibenden Restrisiken sind als "akzeptabel" oder "nicht-akzeptabel" zu klassifizieren. Die Entscheidungsgrundlage dafür sollte in der (organisationsweiten) Informationssicherheitspolitik festgelegt sein (vgl. Kapitel Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken, Schritt 2, sowie Kapitel Akzeptables Restrisiko). Akzeptable Restrisiken können in Kauf genommen werden, nicht-akzeptable bedürfen einer weiteren Analyse.

Schritt 3: Entscheidung über nicht-akzeptable Restrisiken

Die weitere Behandlung von nicht-akzeptablen Restrisiken sollte stets eine Management-Entscheidung sein. Es besteht die Möglichkeit, zu untersuchen, wie weit und mit welchen Kosten nicht-akzeptable Restrisiken weiter verringert werden können, und zusätzliche, eventuell mit hohen Kosten verbundene Maßnahmen auszuwählen. Die Alternative dazu ist eine bewusste und dokumentierte Akzeptanz des erhöhten Restrisikos.

Schritt 4: Akzeptanz von außergewöhnlichen Restrisiken

Ist eine weitere Reduktion des Restrisikos nicht möglich, unwirtschaftlich oder aufgrund gegebener Rahmenbedingungen nicht wünschenswert, so besteht in begründeten Ausnahmefällen die Möglichkeit einer bewussten Akzeptanz dieses erhöhten Restrisikos. Das Vorgehen dabei und die Verantwortlichkeiten dafür sind in der Informationssicherheitspolitik festzulegen (vgl. Kapitel Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken, Schritt 3 und Kapitel Akzeptanz von außergewöhnlichen Restrisiken).

5.3 Sicherheitsrichtlinien

5.3.1 Aufgaben und Ziele

Für alle komplexen oder stark verbreiteten IT-Systeme sollten spezifische Sicherheitsrichtlinien erarbeitet werden. Typische Beispiele sind etwa eine PC-Sicherheitsrichtlinie, eine Netzsicherheitsrichtlinie oder eine Internet-Sicherheitsrichtlinie.

5.3.2 Inhalte

Eine Sicherheitsrichtlinie sollte Aussagen zu folgenden Bereichen treffen:

Definition und Abgrenzung des Systems, Beschreibung der wichtigsten Komponenten
Definition der wichtigsten Ziele und Funktionalitäten des Systems
Festlegung der Informationssicherheitsziele des Systems
Abhängigkeit der Organisation vom betrachteten IT-System;
dabei ist zu untersuchen, wie weit die Aufgabenerfüllung der Organisation durch eine Verletzung der Vertraulichkeit, Verfügbarkeit oder Integrität des Systems oder darauf verarbeiteter Information gefährdet wird.
Investitionen in das System
(Entwicklungs-, Beschaffungs- und Wartungskosten, Kosten für den laufenden Betrieb)
Risikoanalysestrategie
Werte, Bedrohungen und Schwachstellen lt. Risikoanalyse
Sicherheitsrisiken
Beschreibung der bestehenden und der noch zu realisierenden Sicherheitsmaßnahmen
Gründe für die Auswahl der Maßnahmen
Kostenschätzungen für die Realisierung und den laufenden Betrieb (Wartung) der Sicherheitsmaßnahmen
Verantwortlichkeiten

5.3.3 Fortschreibung der Sicherheitsrichtlinien

Auch eine Sicherheitsrichtlinie stellt kein einmal erstelltes, unveränderbares Dokument dar, sondern ist regelmäßig auf Aktualität zu überprüfen und bei Bedarf entsprechend anzupassen.

Insbesondere ist es von Bedeutung, dass die Liste der existierenden bzw. noch umzusetzenden Sicherheitsmaßnahmen stets dem tatsächlich aktuellen Stand entspricht.

5.3.4 Verantwortlichkeiten

Die Verantwortlichkeiten für die Erstellung und Fortschreibung der Sicherheitsrichtlinien sind im Einzelnen in der Informationssicherheitspolitik festzulegen (vgl. dazu Kapitel Organisation und Verantwortlichkeiten für Informationssicherheit). Im Allgemeinen wird diese Verantwortung bei der/dem für das gegenständliche System zuständigen Bereichs-IT-Sicherheitsbeauftragten liegen, die/der sie mit der/dem IT-Sicherheitsbeauftragten abstimmen wird. Letzterer hat dafür Sorge zu tragen, dass die einzelnen Sicherheitsrichtlinien mit der organisationsweiten Informationssicherheitspolitik kompatibel sind und auch untereinander ein einheitliches, vergleichbares Niveau aufweisen.

5.4 Informationssicherheitsplan

Der Informationssicherheitsplan beschreibt, wie die ausgewählten Sicherheitsmaßnahmen umgesetzt werden. Er enthält eine Prioritäten- und Ressourcenplanung sowie einen Zeitplan für die Umsetzung der Maßnahmen.

Im Detail sind für jedes System zu erstellen:

eine Liste der vorhandenen sowie eine Liste der noch zu implementierenden Sicherheitsmaßnahmen;
für jede dieser Maßnahmen sollte eine Aussage über ihre Wirksamkeit sowie möglicherweise notwendige Verbesserungen oder Verstärkungen getroffen werden.
eine Prioritätenreihung für die Implementierung der ausgewählten Sicherheitsmaßnahmen bzw. die Verbesserung bestehender Maßnahmen
eine Kosten- und Aufwandsschätzung für Implementierung und Wartung der Maßnahmen
Detailplanung für die Implementierung
Diese soll folgende Punkte umfassen:
- Prioritäten
- Zeitplan, abhängig von Prioritäten und Ressourcen
- Budget
- Verantwortlichkeiten
- Schulungs- und Sensibilisierungsmaßnahmen
- Test- und Abnahmeverfahren und -termine
- Nachfolgeaktivitäten
eine Bewertung des nach der Implementierung aller Maßnahmen zu erwartenden Restrisikos

Weiters sollte der Sicherheitsplan auch die Kontrollmechanismen festlegen, die den Fortschritt der Implementierung der ausgewählten Maßnahmen bewerten, und Möglichkeiten des Eingriffes bei Abweichungen vom vorgesehenen Prozess oder bei notwendigen Änderungen definieren.

5.5 Fortschreibung des Sicherheitskonzeptes

Auch das Sicherheitskonzept muss laufend fortgeschrieben werden.

Anlässe für eine neue Untersuchung und das Fortschreiben des Konzeptes können sein:

Ablauf eines vorgeschriebenen oder vereinbarten Zeitraumes (z.B. jährliches Update)
Eintritt von Ereignissen, die die Bedrohungslage verändern, wie etwa politische oder gesellschaftliche Entwicklungen oder das Bekannt werden neuer Attacken
Eintritt von Ereignissen, die die Werte verändern können, wie etwa die Änderungen von Organisationszielen oder Aufgabenbereichen, Änderungen am Markt oder die Einführung neuer Applikationen
Ereignisse, die die Eintrittswahrscheinlichkeit von Bedrohungen verändern, wie etwa die Entwicklung neuer Techniken oder veränderte Einsatzbedingungen (Einsatzort, IT-Ausstattung, ...)
neue Möglichkeiten für Sicherheitsmaßnahmen, etwa aufgrund von Preisänderungen oder der Verfügbarkeit neuer Technologien

Voraussetzungen für eine effiziente und zielgerichtete Fortschreibung des Sicherheitskonzeptes sind

die laufende Überprüfung von Akzeptanz und Einhaltung der Sicherheitsmaßnahmen
die Protokollierung von Schadensereignissen
die Kontrolle der Wirksamkeit und Angemessenheit der Maßnahmen

Ob eine neuerliche Risikoanalyse erforderlich ist oder lediglich die Auswahl der Maßnahmen überarbeitet wird, hängt vom Ausmaß der eingetretenen Veränderungen ab.

6 Umsetzung des Informationssicherheitsplanes

Die korrekte und effiziente Implementierung von Sicherheitsmaßnahmen und ihr zielgerichteter Einsatz hängen in hohem Maße von der Qualität des im vorangegangenen Schritt erstellten Informationssicherheitsplanes ab. Dieser muss gut strukturiert, genau dokumentiert und den tatsächlichen Anforderungen der betroffenen Institution angepasst sein.

Bei der Umsetzung des Planes ist zu beachten, dass

Verantwortlichkeiten rechtzeitig und eindeutig festgelegt werden,
finanzielle und personelle Ressourcen rechtzeitig zugewiesen werden,
die Maßnahmen korrekt umgesetzt werden,
die Kosten sich in dem vorher abgeschätzten Rahmen halten und
der Zeitplan eingehalten wird.

Gleichzeitig mit der Implementierung der Sicherheitsmaßnahmen sollten auch entsprechende Schulungs- und Sensibilisierungsmaßnahmen gesetzt werden, um die optimale Einhaltung und Akzeptanz der Maßnahmen bei den Anwenderinnen/Anwendern zu erreichen.

Als letzter Schritt der Umsetzung des Informationssicherheitsplanes sind die implementierten Maßnahmen in ihrer tatsächlichen Einsatzumgebung auf ihre Auswirkungen zu testen und abzunehmen (Akkreditierung).

Es empfiehlt sich, die Umsetzung des Informationssicherheitsplanes im Rahmen eines Projektes abzuwickeln.

6.1 Implementierung von Maßnahmen

Sobald der Informationssicherheitsplan erstellt und verabschiedet wurde, sind die einzelnen Maßnahmen zu implementieren, auf ihre Übereinstimmung mit der Sicherheitspolitik zu überprüfen ( Security Compliance Checking) und auf Korrektheit und Vollständigkeit zu testen.

Dabei ist zu beachten, dass ein Teil der Maßnahmen systemspezifisch sein wird, ein anderer Teil aber organisationsweit einzusetzen ist (vgl. dazu auch Kapitel Auswahl von Maßnahmen).

Die Abstimmung der einzelnen systemspezifischen Informationssicherheitspläne für die Gesamtorganisation obliegt in der Regel der/dem IT-Sicherheitsbeauftragten. Sie/er hat dafür Sorge zu tragen, dass

die systemübergreifenden, organisationsweiten Maßnahmen vollständig und angemessen, sowie nicht redundant oder widersprüchlich sind, und
die systemspezifischen Maßnahmen kompatibel sind und ein einheitliches, angemessenes Sicherheitsniveau haben.

Besonderer Wert ist auf eine detaillierte, korrekte und aktuelle Dokumentation dieser Implementierungen zu legen.

Schritt 1: Implementierung der Sicherheitsmaßnahmen

Die Implementierung der ausgewählten Sicherheitsmaßnahmen hat anhand des Informationssicherheitsplanes, entsprechend der vorgegebenen Zeitpläne und Prioritäten, zu erfolgen.

Die Verantwortlichkeiten dafür sind im Detail festzulegen.

Schritt 2: Tests

Tests sollen sicherstellen, dass die Implementierung korrekt durchgeführt und abgeschlossen wurde.

Es wird empfohlen, für die Tests einen Testplan zu erstellen, der

die Testmethoden,
die Testumgebung sowie
die Zeitpläne für die Durchführung der Tests

beinhaltet.

Die durchgeführten Tests sind im Detail zu beschreiben und die Ergebnisse in einem standardisierten Testbericht festzuhalten.

Abhängig von der speziellen Bedrohungslage und der Art der Maßnahmen kann die Durchführung von Penetrationstests erforderlich sein.

Schritt 3: Prüfung der Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik (Security Compliance Checking)

Security Compliance Checks sind sowohl im Rahmen der Implementierung der Maßnahmen als auch als wiederholte Aktivität zur Gewährleistung der Informationssicherheit im laufenden Betrieb (s. dazu auch Kapitel IT-Sicherheit im laufenden Betrieb) durchzuführen.

Dabei sind zu prüfen:

die vollständige und korrekte Umsetzung der Sicherheitsmaßnahmen
der korrekte Einsatz der implementierten Sicherheitsmaßnahmen
die Einhaltung der organisatorischen Sicherheitsmaßnahmen im täglichen Betrieb

Dokumentation

Die Dokumentation der implementierten Maßnahmen stellt einen wichtigen Teil der gesamten Sicherheitsdokumentation dar und ist notwendige Voraussetzung für die Kontinuität und Konsistenz des Informationssicherheitsprozesses. Die wichtigsten Anforderungen an die Dokumentation:

Aktualität:
Alle Sicherheitsmaßnahmen sind stets auf dem aktuellen Stand der Realisierung zu beschreiben.
Vollständigkeit
Hoher Detaillierungsgrad:
Die Sicherheitsmaßnahmen sind so detailliert zu beschreiben, dass zum einen eventuell bestehende Sicherheitslücken erkannt werden können, zum anderen ausreichend Information für einen korrekten und effizienten Einsatz der Maßnahmen zur Verfügung steht.
Gewährleistung der Vertraulichkeit:
Dokumentation über Sicherheitsmaßnahmen kann unter Umständen sehr vertrauliche Information enthalten und ist daher entsprechend zu schützen. So weit wie möglich sollte bei der Klassifizierung und Behandlung solcher Dokumente auf die Vorgaben im Rahmen der Informationssicherheitspolitik der Organisation zurückgegriffen werden (vgl. dazu Kapitel Klassifizierung von Informationen). Es kann im Einzelfall notwendig sein, weitere Verfahrensweisen zur Erstellung, Verteilung, Benutzung, Aufbewahrung und Vernichtung von sicherheitsrelevanter Dokumentation zu entwickeln. Diese Verfahrensweisen sind ebenfalls entsprechend zu dokumentieren.
Konfigurations- und Integritätskontrolle:
Es ist sicherzustellen, dass keine unauthorisierten Änderungen der Dokumentation erfolgen, die eine - beabsichtigte oder unbeabsichtigte - Beeinträchtigung der implementierten Maßnahmen nach sich ziehen könnten.

6.2 Sensibilisierung (Security Awareness)

Nur durch Verständnis und Motivation ist eine dauerhafte Einhaltung und Umsetzung der Richtlinien und Vorschriften zur Informationssicherheit zu erreichen. Um das Sicherheitsbewusstsein aller Mitarbeiter/innen zu fördern und den Stellenwert der Informationssicherheit innerhalb einer Organisation zu betonen, sollte ein umfassendes, organisationsweites Sensibilisierungsprogramm erstellt werden, das zum Ziel hat, Informationssicherheit zu einem integrierten Bestandteil der täglichen Arbeit zu machen.

Das Sensibilisierungsprogramm sollte systemübergreifend sein. Es ist Aufgabe der dafür verantwortlichen Person - dies wird in der Regel die/der IT-Sicherheitsbeauftragte sein - die Anforderungen aus den einzelnen Teilbereichen und systemspezifische Anforderungen hier einfließen zu lassen und entsprechend zu koordinieren.

Das Sensibilisierungsprogramm sollte folgende Punkte umfassen:

Information aller Mitarbeiter/innen über die Informationssicherheitspolitik der Organisation. Im Rahmen einer Einführung sollten insbesondere folgende Punkte erläutert werden:
- die Informationssicherheitsziele und -politik der Institution sowie deren Erläuterung,
- die Bedeutung der Informationssicherheit für die Institution,
- Organisation und Verantwortlichkeiten im Bereich der Informationssicherheit,
- die Risikoanalysestrategie,
- die Sicherheitsklassifizierung von Daten,
- ausgewählte Sicherheitsmaßnahmen (insbesondere solche, die für die gesamte Organisation Gültigkeit haben),
die wichtigsten Ergebnisse der Risikoanalysen (Bedrohungen, Schwachstellen, Risiken, ...),
die Pläne zur Implementatierung und Überprüfung der Sicherheitsmaßnahmen,
die Auswirkungen von sicherheitsrelevanten Ereignissen für einzelne Anwender und für die gesamte Institution,
die Notwendigkeit, Sicherheitsverstöße zu melden und zu untersuchen, und
die Konsequenzen bei Nichteinhaltung von Sicherheitsvorgaben.

Zur Sensibilisierung der Mitarbeiter/innen können u.a. folgende Maßnahmen beitragen:

regelmäßige Veranstaltungen zum Thema Informationssicherheit
Publikationen
schriftliche Festlegung der Berichtswege und Handlungsanweisungen im Falle eines vermuteten Sicherheitsproblems (z.B. Auftreten eines Virus, Hacker-Angriff, ...)

Das Sensibilisierungsprogramm sollte jede/n Mitarbeiter/in der Institution auf ihre/seine Verantwortlichkeit für Informationssicherheit hinweisen. Dabei ist insbesondere die Verantwortung des Managements für Informationssicherheit zu betonen ("Informationssicherheit als Managementaufgabe"). Die organisationsweite Planung dieser Veranstaltungen sollte die/der IT-Sicherheitsbeauftragte übernehmen. Gegebenenfalls liefern Bereichs-IT-Sicherheitsbeauftragte Informationen, wann und wo solche Veranstaltungen nötig sind.

Die Veranstaltungen zum Sensibilisierungsprogramm sollten in regelmäßigen Zeitabständen wiederholt werden, um das vorhandene Wissen aufzufrischen und neue Mitarbeiter/innen zu informieren. Darüber hinaus sollte jede/r neue, beförderte oder versetzte Mitarbeiter/in so weit in Fragen der Informationssicherheit geschult werden, wie es der neue Arbeitsplatz verlangt.

Das Sensibilisierungsprogramm ist regelmäßig auf seine Wirksamkeit und Aktualität zu überprüfen und laufend an Veränderungen in der Informationssicherheitspolitik sowie an neue Technologien anzupassen.

6.3 Schulung

Über das allgemeine Sensibilisierungsprogramm hinaus sind spezielle Schulungen zu Teilbereichen der Informationssicherheit erforderlich, wenn sich durch Sicherheitsmaßnahmen einschneidende Veränderungen, z.B. im Arbeitsablauf, ergeben.

Weiters sind Personen, die in besonderem Maße mit Informationssicherheit zu tun haben, speziell dafür auszubilden und zu schulen. Dazu zählen etwa:

die/der IT-Sicherheitsbeauftragte und die Bereichs-IT-Sicherheitsbeauftragten
die Mitglieder des Informationssicherheitsmanagement-Teams
Mitarbeiter/innen, die zu VERTRAULICH, GEHEIM oder STRENG GEHEIM eingestuften Informationen Zugang haben
Mitarbeiter/innen mit spezieller Verantwortung für die Systementwicklung (z.B. Projektleiter/innen)
Mitarbeiter/innen mit spezieller Verantwortung für den Betrieb eines IT-Systems oder einer wichtigen Applikation (z.B. Applikationsverantwortliche)
Mitarbeiter/innen, die mit Aufgaben der IT-Sicherheitsverwaltung betraut sind (z.B. Vergabe von Zutritts-, Zugangs- und Zugriffsrechten)

Das Schulungsprogramm ist von jeder Organisation spezifisch für ihren Bedarf zu entwickeln. Besondere Betonung ist dabei auf die Schulung der korrekten Implementierung und Anwendung von Sicherheitsmaßnahmen zu legen. Typische Beispiele für die Themen, die im Rahmen von Schulungsveranstaltungen behandelt werden sollten, sind:

Sicherheitspolitik und -infrastruktur:
Rollen und Verantwortlichkeiten, Organisation des Informationssicherheitsmanagements, Behandlung von sicherheitsrelevanten Vorfällen, regelmäßige Überprüfung von Sicherheitsmaßnahmen und ähnliches
Bauliche Sicherheit:
Schutz von Gebäuden, Serverräumen, Büroräumen und Versorgungseinrichtungen mit besonderer Betonung der Verantwortung der einzelnen Mitarbeiter/innen (z.B. Handhabung von Zutrittskontrollmaßnahmen, Brandschutz)
Personelle Sicherheit
Hardware- und Softwaresicherheit:
Dazu gehören etwa Identifikation und Authentisierung, Berechtigungssysteme, Protokollierung, Wiederaufbereitung und Virenschutz.
Netzwerksicherheit:
Netzwerkinfrastruktur, LANs, Inter-/Intranets, Verschlüsselung, digitale Signaturen u.ä.
Business Continuity Planung

Schulungs- und Sensibilisierungsveranstaltungen zum Thema Informationssicherheit müssen zeitgerecht geplant und umgesetzt werden, um keine Sicherheitslücken durch mangelndes Wissen oder Sicherheitsbewusstsein entstehen zu lassen.

6.4 Akkreditierung

Unter Akkreditierung eines IT-Systems versteht man die Sicherstellung, dass dieses den Anforderungen der Informationssicherheitspolitik und der Sicherheitsrichtlinien genügt.

Dabei ist insbesondere darauf zu achten, dass die Sicherheit des Systems

in einer bestimmten Betriebsumgebung,
unter bestimmten Einsatzbedingungen und
für eine bestimmte vorgegebene Zeitspanne

gewährleistet ist.

Erst nach erfolgter Akkreditierung kann das System - oder eine spezifische Anwendung - in Echtbetrieb gehen.

Techniken zur Akkreditierung sind:

Prüfung der Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik ( Security Compliance Checking), vgl. auch Kapitel Implementierung von Maßnahmen und Überprüfung von Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik (Security Compliance Checking)
Tests
Evaluation und Zertifizierung von Systemen

Änderungen der eingesetzten Sicherheitsmaßnahmen oder der Betriebsumgebung können eine neuerliche Akkreditierung des Systems erforderlich machen. Die Kriterien, wann eine Neuakkreditierung durchzuführen ist, sollten in den zugehörigen Sicherheitsrichtlinien festgelegt werden.

7 Informationssicherheit im laufenden Betrieb

Umfassendes Informationssicherheitsmanagement beinhaltet nicht zuletzt auch die Aufgabe, die Informationssicherheit im laufenden Betrieb aufrechtzuerhalten. Ein Sicherheitskonzept ist kein statisches, unveränderbares Dokument, sondern muss stets auf seine Wirksamkeit, Aktualität und die Umsetzung in der täglichen Praxis überprüft werden. Weiters muss eine angemessene Reaktion auf alle sicherheitsrelevanten Änderungen sowie auf sicherheitsrelevante Ereignisse gewährleistet sein.

Ziel aller Follow-Up-Aktivitäten ist es, das erreichte Sicherheitsniveau zu erhalten bzw. weiter zu erhöhen. Verschlechterungen der Wirksamkeit von Sicherheitsmaßnahmen - sei es durch eine Veränderung der Bedrohungslage oder durch falsche Verwendung der implementierten Sicherheitsmaßnahmen - sollen erkannt und entsprechende Gegenmaßnahmen eingeleitet werden.

7.1 Aufrechterhaltung des erreichten Sicherheitsniveaus

Das nach der Umsetzung des Informationssicherheitsplanes erreichte Sicherheitsniveau lässt sich nur dann aufrechterhalten, wenn

Wartung und administrativer Support der Sicherheitseinrichtungen gewährleistet sind,
die realisierten Maßnahmen regelmäßig auf ihre Übereinstimmung mit der Informationssicherheitspolitik geprüft ( Security Compliance Checking ) und
die IT-Systeme fortlaufend überwacht werden ( Monitoring ).

Die Verantwortlichkeiten für diese Aktivitäten müssen im Rahmen der organisationsweiten Informationssicherheitspolitik bzw. in den einzelnen Sicherheitsrichtlinien detailliert festgelegt werden. Generell gilt auch hier, dass die Verantwortung für systemspezifische Maßnahmen bei den einzelnen Bereichs-IT-Sicherheitsbeauftragten - soweit definiert - liegen sollte, die Verantwortung für organisationsweite Sicherheitsmaßnahmen sowie die Gesamtverantwortung bei der/dem IT-Sicherheitsbeauftragten.

Von besonderer Wichtigkeit für die Aufrechterhaltung oder weitere Erhöhung eines einmal erreichten Sicherheitsniveaus ist eine permanente Sensibilisierung aller betroffenen Mitarbeiter/innen für Fragen der Informationssicherheit (vgl. dazu auch Kapitel Sensibilisierung (Security Awareness)).

7.1.1 Wartung und administrativer Support von Sicherheitseinrichtungen

Viele Sicherheitsmaßnahmen erfordern zur Gewährleistung ihrer einwandfreien Funktionsfähigkeit Wartung und administrativen Support. Zu diesen Aufgaben zählen etwa die regelmäßige Auswertung und Archivierung von Protokollen, Backup und Restore sowie die Wartung von sicherheitsrelevanten Komponenten, die Überprüfung der Parametereinstellungen und eventueller Rechte auf mögliche nichtautorisierte Änderungen, die Reinitialisierung von Startwerten oder Zählern sowie Updates der Sicherheitssoftware, wenn verfügbar (besonders, aber nicht ausschließlich, im Bereich Virenschutz).

Alle Wartungs- und Supportaktivitäten sollten nach einem detailliert festgelegten Plan erfolgen und regelmäßig durchgeführt werden.

Die Wartung von Sicherheitseinrichtungen hat in Abstimmung mit den Verträgen, die mit den Lieferfirmen geschlossen wurden, zu erfolgen und darf nur durch dafür authorisierte Personen vorgenommen werden.

Die Kosten für Wartungs- und Supportaufgaben können im Einzelfall beträchtlich sein und sollten daher bereits bei der Auswahl der Sicherheitsmaßnahmen bekannt sein und in den Entscheidungsprozess mit einfließen.

Um die Aufrechterhaltung eines einmal erreichten Sicherheitsniveaus zu gewährleisten, ist sicherzustellen, dass

die erforderlichen finanziellen und personellen Ressourcen zur Wartung von Sicherheitseinrichtungen zur Verfügung stehen,
organisatorische Regelungen existieren, die die Aufrechterhaltung der Informationssicherheitsmaßnahmen im laufenden Betrieb ermöglichen und unterstützen,
die Verantwortungen im laufenden Betrieb klar zugewiesen werden,
die Maßnahmen regelmäßig daraufhin geprüft werden, ob sie wie beabsichtigt funktionieren und
Maßnahmen verstärkt werden, falls sich neue Schwachstellen zeigen.

Alle Wartungs- und Supportaktivitäten im Sicherheitsbereich sollten protokolliert werden. Der regelmäßigen Auswertung dieser Protokolle kommt besondere Bedeutung für die gesamte Informationssicherheit zu.

7.1.2 Überprüfung von Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik (Security Compliance Checking)

Zielsetzung

Zur Gewährleistung eines angemessenen und gleich bleibenden Sicherheitsniveaus ist dafür Sorge zu tragen, dass alle Maßnahmen so eingesetzt werden, wie es im Sicherheitskonzept und im Informationssicherheitsplan vorgesehen ist. Dies muss für alle IT-Systeme, -Projekte und Applikationen sowohl während der Planungsphase als auch im laufenden Betrieb und letztlich auch bei der Außerbetriebnahme sichergestellt sein.

Dabei ist zu prüfen,

ob die Sicherheitsmaßnahmen vollständig und korrekt umgesetzt werden,
der korrekte Einsatz der implementierten Sicherheitsmaßnahmen gewährleistet ist (Stichproben!) und
die organisatorischen Sicherheitsvorgaben im täglichen Betrieb eingehalten und akzeptiert werden.

Weiters sind die getroffenen Maßnahmen regelmäßig auf Übereinstimmung mit gesetzlichen und betrieblichen Vorgaben zu überprüfen.

Die Prüfungen können durch externe oder interne Auditoren durchgeführt werden und sollten soweit möglich auf standardisierten Tests und Checklisten basieren.

Zeitpunkte

Security Compliance Checks sollten zu folgenden Zeitpunkten bzw. bei Eintreten folgender Ereignisse durchgeführt werden:

für neue IT-Systeme oder relevante neue Anwendungen:
nach der Implementierung (vgl. dazu auch Kap. 5.1 und Kap. 5.4)
für bereits in Betrieb befindliche IT-Systeme oder Applikationen:
nach einer bestimmten, in den Sicherheitsrichtlinien vorzugebenden Zeitspanne (z.B. jährlich) sowie bei signifikanten Änderungen.

7.1.3 Fortlaufende Überwachung der IT-Systeme (Monitoring)

Monitoring ist eine laufende Aktivität mit dem Ziel, zu überprüfen, ob das IT-System, seine Benutzer/innen und die Systemumgebung das im Informationssicherheitsplan festgelegte Sicherheitsniveau beibehalten. Dazu wird ein Plan für eine kontinuierliche Überwachung der IT-Systeme im täglichen Betrieb erstellt.

Wo technisch möglich und sinnvoll, sollte das Monitoring durch die Ermittlung von Kennzahlen unterstützt werden, die eine rasche und einfache Erkennung von Abweichungen von den Sollvorgaben ermöglichen. Solche Kennzahlen können beispielsweise die Systemverfügbarkeit, die Zahl der Hacking-Versuche über Internet oder die Wirksamkeit des Passwortmechanismus betreffen.

Alle Änderungen der potentiellen Bedrohungen, Schwachstellen, zu schützenden Werte und Sicherheitsmaßnahmen können möglicherweise signifikante Auswirkungen auf das Gesamtrisiko haben. Aus diesem Grund ist eine fortlaufende Überwachung folgender Bereiche erforderlich:

Wert der zu schützenden Objekte:
Sowohl die Werte von Objekten als auch, daraus resultierend, die Sicherheitsanforderungen an das Gesamtsystem können im Laufe des Lebenszyklus eines IT-Projektes oder -Systems erheblichen Änderungen unterliegen. Mögliche Gründe dafür sind eine Änderung der IT-Sicherheitsziele, neue Applikationen oder die Verarbeitung von Daten einer höheren Sicherheitsklasse auf existierenden Systemen oder Änderungen in der HW-Ausstattung.
Bedrohungen und Schwachstellen:
Organisatorisch oder technologisch (hier insbesondere durch neue Technologien in der Außenwelt) bedingt können sowohl die Wahrscheinlichkeit des Eintritts einer Bedrohung als auch die potentielle Schadenshöhe im Laufe der Zeit starken Änderungen unterliegen und sind daher regelmäßig zu evaluieren. Neue potentielle Schwachstellen sind so früh wie möglich zu erkennen und abzusichern.
Sicherheitsmaßnahmen:
Die Wirksamkeit der implementierten Sicherheitsmaßnahmen ist laufend zu überprüfen. Es ist sicherzustellen, dass sie einen angemessenen und den Vorgaben der Sicherheitsrichtlinien entsprechenden Schutz bieten. Änderungen in den Werten der bedrohten Objekte, den Bedrohungen und den Schwachstellen, aber auch durch den Einsatz neuer Technologien, können die Wirksamkeit der Sicherheitsmaßnahmen nachhaltig beeinflussen.

Durch ein kontinuierliches Monitoring soll die Leitung der Institution ein klares Bild darüber bekommen, was durch die Sicherheitsmaßnahmen erreicht wurde (Soll-/Ist-Vergleich), ob die Ergebnisse den Sicherheitsanforderungen der Institution genügen sowie über den Erfolg einzelner spezifischer Aktivitäten zur Informationssicherheit.

Werden im Rahmen des kontinuierlichen Monitoring signifikante Abweichungen des tatsächlichen Risikos von dem im Sicherheitskonzept festgelegten akzeptablen Restrisiko festgestellt, so sind entsprechende Gegenmaßnahmen zu setzen.

7.2 Change Management

Aufgabe des Change Managements ist es, neue Sicherheitsanforderungen zu erkennen, die sich aus Änderungen am IT-System ergeben. Sind signifikante Hardware- oder Softwareänderungen in einem IT-System geplant, so sind die Auswirkungen auf die Gesamtsicherheit des Systems zu untersuchen.

Es ist dafür Sorge zu tragen, dass auf alle sicherheitsrelevanten Änderungen angemessen reagiert wird. Dazu gehören zum Beispiel:

Änderungen in der Aufgabenstellung oder in der Wichtigkeit der Aufgabe für die Institution,
räumliche Änderungen, z.B. nach einem Umzug,
Änderungen in der Bewertung der eingesetzten IT, der notwendigen Vertraulichkeit, Integrität oder Verfügbarkeit und
Änderungen bei Bedrohungen oder Schwachstellen.

Alle Änderungen und die dazugehörigen Entscheidungsgrundlagen sind schriftlich zu dokumentieren.

Abhängig von der Bedeutung des Systems und dem Grad der Änderung kann eine neuerliche Risikoanalyse erforderlich werden.

7.3 Reaktion auf sicherheitsrelevante Ereignisse ( Incident Handling )

Unter sicherheitsrelevanten Ereignissen sind alle Vorkommnisse zu verstehen, die Sicherheitsprobleme aufdecken oder nach sich ziehen. Dazu zählen etwa Einbruchsversuche in das System (Hacking), das Auftreten von Viren oder das Ausspähen von Passwörtern.

Auch bei Vorhandensein wirksamer Sicherheitsmaßnahmen und eines hohen Sicherheitsniveaus ist das Auftreten solcher Ereignisse nicht gänzlich zu verhindern. Jede Institution muss ein vitales Interesse daran haben, dass auf sicherheitsrelevante Ereignisse so schnell und effektiv wie möglich reagiert wird. Darüber hinaus können und sollen Informationen über derartige Vorkommnisse der Vorbeugung künftiger Schadensereignisse dienen.

Daher sind alle Mitarbeiter/innen über ihre Verantwortung bei Eintreten sicherheitsrelevanter Ereignisse, die vorgesehenen Meldewege und zu setzenden Aktionen zu unterrichten.

Incident Handling Plan

Zur Sicherstellung einer angemessenen Behandlung von sicherheitsrelevanten Ereignissen ist es empfehlenswert, detaillierte Vorgaben in Form eines " Incident Handling Planes" (IHP) auszuarbeiten und allen Mitarbeiterinnen/Mitarbeitern bekannt zu machen.

Der Incident Handling Plan legt in schriftlicher Form und verbindlich fest:

wie auf sicherheitsrelevante Ereignisse zu reagieren ist,
die Verantwortlichkeiten für die Meldung bzw. Untersuchung sicherheitsrelevanter Vorfälle,
die einzuhaltenden Meldewege,
die Protokollierung und Dokumentation sicherheitsrelevanter Vorfälle sowie
die Ausbildung von Personen, die sicherheitsrelevante Vorfälle behandeln bzw. Gegenmaßnahmen treffen müssen.

Einrichtung von CERTs

Ein CERT (Computer Emergency Response Team) ist eine Gruppe von Personen, die

die Ursachen und Auswirkungen von sicherheitsrelevanten Vorfällen untersucht,
Vorfälle aufzeichnet und auswertet,
Hilfestellung bei der Behandlung von sicherheitsrelevanten Vorfällen gibt.

Ob innerhalb einer Institution ein (oder ev. auch mehrere) CERT(s) eingerichtet wird, hängt in erster Linie von der Größe dieser Institution und der erwarteten Anzahl und Schwere der Vorfälle ab. In kleineren Institutionen wird eine Behandlung und Aufzeichnung der sicherheitsrelevanten Vorfälle durch eine in der Informationssicherheitspolitik zu benennende Person - dies wird im Allgemeinen die/der IT-Sicherheitsbeauftragte sein - angemessen sein, in großen oder besonders sicherheitssensiblen Institutionen ist die Einrichtung von CERTs zu empfehlen.

Darüber hinaus besteht auch die Möglichkeit, institutionsübergreifende CERTs einzurichten, die es ermöglichen, Daten über sicherheitsrelevante Vorfälle auszutauschen und damit auf eine breitere Information, etwa über die Häufigkeit des Eintretens von Bedrohungen oder über neue Angriffe, zurückzugreifen. In diesem Fall sollten gemeinsame Protokollierungsvorgaben, Formulare, Bewertungsmethoden und Datenbankstrukturen erarbeitet werden, die den Austausch und die Auswertung von Information erleichtern.

Im Rahmen eines Public-Privat-Partnership wurde vom Bundeskanzleramt in Zusammenarbeit mit dem Zentrum für sichere Informationstechnik - Austria (A-SIT) und der ISPA (Internet Service Providers Austria) eine Plattform zur Kommunikation und Handlungsabstimmung bei sicherheitsrelevanten Vorfällen erstellt. Sie trägt den Namen CIRCA (Computer Incidents Response and Coordination Austria) und ist unter http://www.circa.at erreichbar.

8 Industrielle Sicherheit

Im Zusammenhang mit Informationssicherheit werden unter dem Begriff „Industrielle Sicherheit“ Regelungen für den Umgang mit klassifizierten Informationen (das sind gemäß Informationssicherheitsgesetz EINGESCHRÄNKT, VERTRAULICH, GEHEIM, oder STRENG GEHEIM klassifizierte Dokumente) in Unternehmen bzw. in der Industrie verstanden. Diese Regelungen sehen unter anderem vor, dass die Sicherheit der betroffenen Unternehmen, Einrichtungen und Anlagen sowie ihres Personals im Rahmen einer so genannten Sicherheitsüberprüfung (Facility Clearance) überprüft wird.

Für die Teilnahme österreichischer Unternehmen an manchen Forschungsprogrammen wie zum Beispiel der Europäischen Weltraumagentur (ESA) ist die Vorlage solch einer staatlichen Bescheinigung erforderlich, wonach das Unternehmen und die Forschungseinrichtung die verlangten Standards der Geheimhaltung erfüllen (Sicherheitsunbedenklichkeitsbescheinigung).

Betroffen sind alle Unternehmen, welche Aufträge im Zusammenhang mit klassifizierten Informationen ausführen wollen bzw. sich an Ausschreibungsverfahren zu derartigen Aufträgen beteiligen wollen.

Im Rahmen eines Vertrages verpflichtet sich das Unternehmen die entsprechenden Rechtsvorschriften und internationalen Standards für die Behandlung klassifizierter Dokumente einzuhalten.

8.1 Beschreibung der generellen Anforderungen

Auf Grund der diversen rechtlichen Grundlagen müssen die Sicherheitsmaßnahmen

alle Personen, die Zugang zu klassifizierten Informationen haben, die Träger von klassifizierten Informationen und alle Gebäude, in denen sich derartige klassifizierte Informationen und wichtige Einrichtungen befinden, umfassen;
so ausgelegt sein, dass Personen, die aufgrund ihrer Stellung die Sicherheit von klassifizierten Informationen und wichtigen Einrichtungen, in denen klassifizierte Informationen aufbewahrt werden, gefährden könnten, erkannt und vom Zugang ausgeschlossen oder fern gehalten werden;
verhindern, dass unbefugte Personen Zugang zu klassifizierten Informationen oder zu Einrichtungen, in denen klassifizierte Informationen aufbewahrt werden, erhalten;
dafür sorgen, dass klassifizierte Informationen nur unter Beachtung des für alle Aspekte der Sicherheit grundlegenden Prinzips „Kenntnis nur wenn nötig“ (Need-to-know Prinzip) verbreitet werden;
die Integrität (d. h. Verhinderung von Verfälschungen, unbefugten Änderungen oder unbefugten Löschungen) und die Verfügbarkeit (d. h. keine Verweigerung des Zugangs für Personen, die ihn benötigen und dazu befugt sind) aller Informationen gewährleisten.

Alle Gebäude, Bereiche, Büros, Räume, Kommunikations- und Informationssysteme usw. in denen als klassifiziert eingestufte Informationen und/oder ihr Material aufbewahrt werden und / oder in denen damit gearbeitet wird, müssen durch geeignete Maßnahmen des Geheimschutzes gesichert werden. Die Maßnahmen des Schutzes zielen darauf ab, das Eindringen unbefugter Personen von außen zu verhindern, von Tätigkeiten illoyaler Angehöriger des Personals (Spionage von innen) abzuschrecken bzw. diese zu verhindern und aufzudecken.

Im Wesentlichen werden dafür abgesicherte Sicherheitsbereiche eingerichtet und der Zugang zu diesen kontrolliert. Für die Lagerung von klassifizierten Informationen werden Sicherheitsbehältnisse (z. B. Tresore) vorgesehen. Weiters sind Maßnahmen zum Sicht und Abhörschutz zu treffen. Außerdem ist zu dokumentieren, wann wer welche klassifizierte Information erhält. Die Gestaltung der Maßnahmen im Einzelnen ist von der Klassifizierungsstufe abhängig.

Personen-Zertifizierung

Alle Personen, die Zugang zu Informationen haben, welche als „VERTRAULICH“ oder höher eingestuft sind, müssen einer Sicherheitsüberprüfung unterzogen werden, bevor sie Zugangsermächtigung erhalten.

8.2 Rechtlicher Hintergrund

Rechtsgrundlagen

Als Rechtsgrundlagen sind zu nennen:

Informationssicherheitsgesetz [InfoSiG]
Informationssicherheitsverordnung [InfoSiV]
Sicherheitspolizeigesetz [SPG]
Militärbefugnisgesetz [MBG]
Verordnung des Bundesministers für Verkehr, Innovation und Technologie über die Kostenersatzpflicht für die Ausstellung einer Sicherheitsunbedenklichkeitsbescheinigung [BMVIT]
Verordnung des Bundesministers für Landesverteidigung über die Ausstellung von Sicherheitsunbedenklichkeitsbescheinigungen [SUBV]
Sicherheitsgebühren-Verordnung [SGV]

Informationssicherheitsgesetz [InfoSiG] und –verordnung [InfoSiV] regeln den nationalen Umgang mit klassifizierten Informationen.

Für die Personen-Überprüfung sind das Sicherheitspolizeigesetz [SPG] mit seinen Verordnungen, insbesondere die Sicherheitsgebühren-Verordnung und die Verordnung, mit der Form und Inhalt der Sicherheitserklärung einschließlich der Zustimmungserklärung erlassen und die Sicherheitsgebühren-Verordnung geändert werden [SEV] und das Militärbefugnisgesetz [MBG] relevant.

Die Verordnungen [BMVIT] und BMLV [SUBV] regeln die Kosten für die Ausstellung von Sicherheitsunbedenklichkeitsbescheinigungen.

Beschlüsse der ISK:

Beschluss über die Verwendung von Sicherheitsbehältnissen für klassifizierte Dokumente [TRES]

EU-Ratsbeschlüsse:

Beschluss des Rates vom 19. März 2001 über die Annahme der Sicherheitsvorschriften des Rates (2001/264/EG) [EU2001]
Beschluss des Rates vom 10. Februar 2004 zur Änderung des Beschlusses 2001/264/EG über die Annahme der Sicherheitsvorschriften des Rates (2004/194/EG) [EU2004]
Beschluss des Rates vom 20. Dezember 2005 zur Änderung des Beschlusses 2001/264/EG über die Annahme der Sicherheitsvorschriften des Rates (2005/952/EG) [EU2005]

Mit dem Ratsbeschluss 2001/246/EG [EU2001] wurde festgelegt, wie EU-Verschlusssachen in den öffentlichen Einrichtungen der Mitgliedsstaaten zu behandeln sind. Der materielle Geheimschutz wird definiert in Abschnitt IV: „Hauptziel der Maßnahmen des materiellen Geheimschutzes ist es, zu verhindern, dass Unbefugte Zugang zu EU Verschlusssachen erhalten.“

Im Ratsbeschluss 2004/194/EG [EU2004] werden die Anhänge 1 (Verzeichnis der nationalen Sicherheitsbehörden) und 2 (Vergleichstabelle der nationalen Sicherheits¬ein-stufungen) des Ratsbeschlusses [EU2001] ergänzt.

Der Ratsbeschluss 2005/952/EG [EU2005] legt fest, dass die Bestimmungen des Ratsbeschlusses [EU2001] auch anzuwenden sind, wenn industrielle oder andere Einrichtungen vertraglich mit Aufgaben betraut werden, bei denen EU-Verschlusssachen relevant sind.

Beschlüsse der Kommission:

Beschluss der Kommission vom 1. Februar 2005, 2001/844/EC, ECSC, Euratom in der sich diese inhaltlich an den Ratsbeschluss anlehnen
Beschluss der Kommission vom 2. August 2006, 2006/548/EC, ECSC, Euratom hinsichtlich industrieller Sicherheit

Beschlüsse der NATO [NATO39]:

[NATO] Security Committee, Directive on Industrial Security, „Security Policy“, AC735-D/2003-REV1, 26. Juli 2005 [NATO35]
North Atlantic Council, C-M(2002)49, Security within the North Atlantic Treaty Organisation (NATO) mit den Subdokumenten [NATO49]
- AC/35-D/2000 directive on Personnel Security
- AC/35-D/2001 Directive on Physical Security
- AC/35-D/2002 Directive on Security of Information
- AC/35-D/2003 Directive on Industrial Security
- AC/35-D/2004 Primary Directive on INFOSEC
- AC/35-D/2005 INFOSEC Management Directive for CIS

Beschlüsse der Multinational Industrial Security Working Group [MISWG]

Doc. Number 1: Arrangements for the International Hand Carriage of Classified Documents, Equipment and/or Components
Doc. Number 3: Use of Cryptographic Systems
Doc. Number 4: Security Clauses
Doc. Number 5: Program/Project Security Instruction
Doc. Number 6: Procedures for the Protection of Restricted Information
Doc. Number 7: International Visit Procedures
Doc. Number 8: Controlled Unclassified Information Clauses
Doc. Number 9: Security Education and Awareness
Doc. Number 10: Transportation Plan for the Movement of Classified Material as Freight
Doc. Number 11: Control of Security Cleared Facilities
Doc. Number 12: Facility Security Clearance Information Sheet
Doc. Number 13: Protection of Information Handled in it and Communication Systems
Doc. Number 14: Contract Security Clauses
Doc. Number 15: International Transportation by Commercial Carriers of Classified Documents and Equipment or Components as Freight
Doc. Number 16: Guidelines for Assessing Protection and Control of Classified Information in a Multinational Non-NATO Cooperative Defence Program
Doc. Number 17: International Hand Carriage of Classified Documents, Equipment and /of Components by Visitors
Doc. Number 18: International Industrial Security Requirements Guidance Annex
Doc. Number 19: Personal Security Clearance Information Sheet
Doc. Number 20: International Transfer of Material Classified Restricted by Express Commercial Couriers
Doc. Number 21: Role of the Facility Security Officer

8.3 Ausstellung einer Sicherheitsunbedenklichkeitsbescheinigung

8.3.1 Ablauf

Anträge auf Ausstellung einer Sicherheitsunbedenklichkeitsbescheinigung sind beim zuständigen Ministerium einzubringen: Dabei handelt es sich um jenes Ministerium in dessen Zuständigkeitsbereich die betreffende industrielle Tätigkeit oder Forschungstätigkeit laut Bundesministeriengesetz fällt.
Das Unternehmen verpflichtet sich gegenüber der Republik Österreich vertraglich zur Einhaltung der einschlägigen gesetzlichen Bestimmungen. Alle Personen, die im Unternehmen mit klassifizierten Informationen befasst werden sollen, sind gem. § 6 InfoSiV zu unterweisen. Die Nachweise der durchgeführten Unterweisungen sind an das zuständige Ministerium zu übermitteln.
Personelle Sicherheitsüberprüfung (Personenzertifizierung): Alle Personen, die im Unternehmen Informationen erhalten sollen, welche als „VERTRAULICH“ oder höher (bzw. in einer äquivalenten ausländischen Klassifizierungsstufe eingestuft sind), werden einer Sicherheitsüberprüfung unterzogen. Das Unternehmen beantragt eine Überprüfung für jede/n betroffene/n Mitarbeiter/in. Die Sicherheitsüberprüfung wird gemäß §§ 55 bis 55 b SPG vom BMI oder im Falle der Zuständigkeit des BMLV die einer Sicherheitsüberprüfung analoge Verlässlichkeitsprüfung nach den §§ 23 und 24 [MBG] vom BMLV durchgeführt.
Materielle Sicherheitsüberprüfung
- Erstellen eines Sicherheitskonzeptes (inkl. der „Systemspezifischen Sicherheitsanforderungen“ [SSRS] für IT-Anwendungen) durch das Unternehmen
- Umsetzen des Sicherheitskonzeptes und Dokumentation derselben (für IT-Anwendungen „SecOPs“ [SECOPS]) durch das Unternehmen
- Überprüfung durch das BMI bzw. BMLV
Ausstellung der Sicherheitsunbedenklichkeitsbescheinigung durch die/den Leiter/in der ISK bei zivilen Projekten bzw. die/den Leiter/in des Abwehramtes bei militärisch klassifizierten Projekten. Diese Bestätigung über die erfolgreiche Sicherheitsüberprüfung bezieht sich nur auf das konkrete Projekt, für welches die Überprüfung beantragt wurde und gilt für den angegebenen Zeitraum.
In der Folge über die komplette Projektdauer: regelmäßige Überprüfung durch das zuständige Ministerium, Kommunikation mit dem ISB (z.B. bei Änderungen, Besuchsverfahren)

8.3.2 Verantwortlichkeiten und Kontakte

Antragstellung

Der Antrag auf Ausstellung einer Sicherheitsunbedenklichkeitsbescheinigung ist beim zuständigen Ministerium einzubringen. Dabei handelt es sich um jenes Ministerium in dessen Zuständigkeitsbereich der Auftragsgegenstand fällt. Unter http://www.austria.gv.at/ ist eine Liste der Ministerien zu finden. Bei Unklarheiten in der Zuständigkeit wird durch das ISB die Federführung festgelegt.

Durchführung der Sicherheitsüberprüfung und Ausstellung der Sicherheitsunbedenklichkeitsbescheinigung

Büro der Informationssicherheitskommission (ISB), Bundeskanzleramt, Ballhausplatz 2, 1014 Wien
Bundesministerium für Inneres, BVT/3, Herrengasse 7, Postfach 100, 1014 Wien
Bundesministerium für Landesverteidigung, Abwehramt, Postfach 888, 1035 Wien

Durchführung der personellen Sicherheitsüberprüfung, Verlässlichkeitsprüfung

Bundesministerium für Inneres, BVT, Herrengasse 7, Postfach 100, 1014 Wien
Bundesministerium für Landesverteidigung, Abwehramt, Postfach 888, 1035 Wien

Verantwortlichkeiten im Unternehmen

Im Unternehmen sind eine Stelle (SOA - System Operational Authority) und eine verantwortliche Person (Informationssicherheitsbeauftragte/r) zu definieren, die für alle Sicherheitsmaßnahmen und für die Erstellung und Einhaltung der SSRS und der SecOPs verantwortlich sind.

Geheimhaltungsgrade und Kennzeichnungen

Österreich:	STRENG GEHEIM (SG)	GEHEIM (G)	VERTRAULICH (V)	EINGESCHRÄNKT (E)
EU Einstufung:	TRES SECRET UE EU TOP SECRET	SECRET UE	CONFIDENTIEL UE	RESTREINT UE
NATO:	Cosmic Top Secret	NATO Secret	NATO Confidential	NATO Restricted

Tabelle 8.3: Geheimhaltungsgrade und Kennzeichnung

Für einen kompletten Vergleich nationaler Sicherheitseinstufungen der EU-Mitgliedsstaaten, siehe Ratsbeschluss 2001/264/EG [EU2004] Abschnitt II.

Anhang A: Anhang

A.1 Literatur

[BS 7799-1]	British Standards Institute: "Code of practice for information security management", 1999 (entspricht [ISO/IEC 17799])
[BS 7799-2]	British Standards Institute: "Specification for information security management systems", 2002
[BSI 7105]	Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn: "IT-Sicherheitshandbuch", BSI 7105
[BSI 100-1]	Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn: "Managementsysteme für Informationssicherheit (ISMS)"
[BSI 100-2]	Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn: "IT-Grundschutz-Vorgehensweise"
[BSI 100-3]	Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn: "Risikoanalyse auf der Basis von IT-Grundschutz"
[BSI-1]	Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn: "Gefährdungskatalog", www.bsi.de
[BSI-2]	Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn: "Maßnahmenkataloge", www.bsi.de
[KFall]	Bundeskanzleramt: "Katastrophenvorsorge- und Ausfallssicherheitsüberlegungen im IT-Bereich", vom Oktober 2002 (nicht öffentlich)
[OECD-02]	Organisation for Economic Co-operation and Development (OECD): "Guidelines for the Security of Information Systems and Networks", 2002
[MISWG]	Beschlüsse der Multinational Industrial Security Working Group (MISWG) (siehe: http://www.avanco.com/n/ips_miswg.html)

Tabelle A.4: Literaturverweise

A.2 Gesetzestexte

Die zitierten Gesetzestexte können online über das Rechtsinformationssystem des Bundes unter folgender URL abgerufen werden:

http://www.ris.bka.gv.at

Die Bundesgesetzblätter sind bei der Wiener Zeitung Digitale Publikationen GmbH (vormals Österreichische Staatsdruckerei - Wiener Zeitung), die Landesgesetzblätter bei den Ämtern der Landesregierungen erhältlich.

[DSG 2000]	"Bundesgesetz über den Schutz personenbezogener Daten" (Datenschutzgesetz 2000 - DSG 2000), BGBl. I Nr. 165/1999 i.d.g.F.
[InfoSiG]	Bundesgesetz über die Umsetzung völkerrechtlicher Verpflichtungen zur sicheren Verwendung von Informationen (Informationssicherheitsgesetz, InfoSiG), BGBl. I Nr. 23/2002 i.d.g.F.
[InfoSiV]	Informationssicherheitsverordnung (InfoSiV), BGBl. I Nr. 23/2002
[BMVIT]	Verordnung des Bundesministers für Verkehr, Innovation und Technologie über die Kostenersatzpflicht für die Ausstellung einer Sicherheitsunbedenklichkeitsbescheinigung, BGBl. II, Nr. 393/2004
[EU2001]	Beschluss des Rates vom 19. März 2001 über die Annahme der Sicherheitsvorschriften des Rates (2001/264/EG), ABl. L 101 vom 11.4.2001, S. 1
[EU2004]	Beschluss des Rates vom 10. Februar 2004 zur Änderung des Beschlusses 2001/264/EG über die Annahme der Sicherheitsvorschriften des Rates (2004/194/EG), ABl. L 63 vom 28.2.2004, S. 48
[EU2005]	Beschluss des Rates vom 20. Dezember 2005 zur Änderung des Beschlusses 2001/264/EG über die Annahme der Sicherheitsvorschriften des Rates (2005/952/EG), ABl. L 346 vom 29.12.2005, S. 18
[MBG]	Bundesgesetz, mit dem ein Bundesgesetz über Aufgaben und Befugnisse im Rahmen der militärischen Landesverteidigung (Militärbefugnisgesetz - MBG) eingeführt sowie das Sperrgebietsgesetz 1995 geändert werden, BGBl. I Nr. 86/2000 in der Fassung BGBl. I Nr. 115/2006
[NATO35]	North Security Committee, Directive on Industrial Security, "Security Policy", AC735-D/2003-REV1, 26. Juli 2005
[NATO49]	North Atlantic Council, C-M/2002)49, Security within the North Atlantic Treaty Organisation (NATO) mit den Subdokumenten (siehe http://www.statewatch.org/news/2006/sep/nato-sec-classifications.pdf))
[SPG]	Bundesgesetz über die Organisation der Sicherheitsverwaltung und die Ausübung der Sicherheitspolizei (Sicherheitspolizeigesetz - SPG), BGBl. I Nr. 566/1991 in der Fassung BGBl. I. Nr. 56/2006
[SGV]	Verordnung des Bundesministers für Inneres über die Höhe der Gebühren für Sicherheitsüberprüfungen, Sicherheitsgebühren-Verordnung 389/1996 idF. 399/2001
[SEV]	Verordnung des Bundesministeriums für Inneres, mit der Form und Inhalt der Sicherheitserklärung einschließlich der Zustimmungserklärung erlassen und die Sicherheitsgebühren-Verordnung geändert werden BGBl 114/2000
[SUBV]	Verordnung des Bundesministers für Landesverteidigung über die Ausstellung von Sicherheitsunbedenklichkeitsbescheinigungen (SUBV), BGBl. II Nr. 195/2006
[KO2005]	Beschluss der Kommission vom 1. Februar 2005, 2001/844/EC, ECSC, Euratom
[KO2006]	Beschluss der Kommission vom 2. August 2006, 2006/548/EC, ECSC, Euratom
[SSRS]	Infosec Office, Februar 2003, Guidelines for the development of Security requirements
[SECOPS]	Infosec Office, Februar 2003, Guidelines for the structure and content of Security Operation Procedures (SecOPs)
[TRES]	Beschluss der ISK über die Verwendung von Sicherheitsbehältnissen für klassifizierte Dokumente

Tabelle A.5: Gesetzestexte

A.3 Glossar

Akkreditierung (accreditation)	Verfahren, das ein IT-System zum Betrieb in einer speziellen Umgebung freigibt
Applikation (application)	(auch: IT-Applikation, Anwendung, IT-Anwendung)Einsatz eines IT-Systems zur Erfüllung von Aufgaben, die in einem eingegrenzten fachlichen Bereich liegen und durch gemeinsame Merkmale ausgezeichnet sind
Auswirkung (impact)	Folgen eines unerwünschten Vorfalls
Authentizität (authenticity)	Eigenschaft, die sicherstellt, dass die von einem Subjekt oder einer Ressource behauptete Identität zutrifft. Authentizität betrifft Entitäten wie Benutzer, Prozesse, Systeme und Informationen.
Authentisierung (authentication)	Nachweis der angegebenen Identität
Bedrohung (threat)	möglicher Anlass für ein unerwünschtes Ereignis, das zu einem Schaden des Systems oder der Organisation führen kann
bedrohtes Objekt (asset)	(auch als "Wert" bezeichnet)alles, was für die Organisation schutzbedürftig ist
CERT	Computer Emergency Response Team;Gruppe von Personen, die die Ursachen und Auswirkungen von sicherheitsrelevanten Vorfällen aufzeichnet und analysiert und Hilfestellung bei ihrer Behandlung gibt.
Entität (entity)	genau abgrenzbares Exemplar von Personen, Systemen, Begriffen etc.
Evaluation (evaluation)	Prüfung und Bewertung eines IT-Systems oder eines IT-Produktes anhand definierter Evaluationskriterien (z.B. ITSEC, Common Criteria)
FIS (Facility Security Clearance Information Sheet)	Die Bestätigung über den positiven Abschluss der Sicherheitsüberprüfung. Die Sicherheitsunbedenklichkeitsbescheinigung wird durch das ISB ausgestellt.
Grundschutz (baseline security)	Schutzmaßnahmen, die ein angemessenes Sicherheitsniveau für IT-Systeme mit mittlerem Schutzbedarf gewährleisten
Grundschutzanalyse	Risikoanalyse für IT-Systeme, die von einer pauschalisierten Gefährdungslage ausgeht; Ergebnis ist eine Liste von umzusetzenden Standardsicherheitsmaßnahmen
Identifikation (identification)	Bestimmung der Identität eines Subjektes bzw. Objektes
Informationssicherheit (information security)	Sammelbegriff aller Aspekte zum Schutz von Information vor Verlust, unbefugter Veränderung und unbefugter Kenntnisnahme; umfasst sowohl elektronisch gespeicherte und verarbeitete Information als auch Information in verbaler oder schriftlicher Form
Integrität (integrity)	Unverfälschtheit und Korrektheit von Daten bzw. Systemen
ISB	Büro der Informationssicherheitskommission, Bundeskanzleramt, 1014 Wien, Ballhausplatz 2
ISK	Informationssicherheitskommission, Bundeskanzleramt, 1014 Wien, Ballhausplatz 2
IT-Sicherheit (IT security)	alle Aspekte in Verbindung mit der Definition, Erreichung und Aufrechterhaltung von Vertraulichkeit, Integrität, Verfügbarkeit, Zurechenbarkeit, Authentizität und Zuverlässigkeit in einem IT-System
IT-Sicherheitspolitik, organisationsweite (IT security policy, corporate)	Leitlinien und Vorgaben, die grundlegende Ziele, Strategien, Verantwortlichkeiten und Methoden für die Gewährleistung der Informationssicherheit in einer Organisation festlegen
IT-Sicherheitskonzept (IT security concept)	Summe von (geplanten und realisierten) Maßnahmen verschiedener Art, die erst in ihrer Kombination die gewünschte Schutzwirkung ergeben; die Erstellung eines IT-Sicherheitskonzeptes umfasst Festlegung von Maßnahmen, Restrisikoakzeptanz und Erstellung von Sicherheitsrichtlinien und eines Sicherheitsplanes
ITSOA, SOA (IT - System Operational Authority)	Verantwortliche Stelle für Implementierung und Betrieb eines (IT-)Systems innerhalb eines Unternehmens. Die SOA ist für alle Sicherheitsmaßnahmen und für die Erstellung der SSRS und der SecOPs verantwortlich.
IT-System (IT system)	Kombination von Hard- und Software mit einem bestimmten Zweck und einer spezifischen Betriebsumgebung
Objekt (object)	passive Entität, die Informationen enthält oder empfängt
Objekt, bedrohtes	s. bedrohtes Objekt
Restrisiko (residual risk)	Risiko, das nach der Umsetzung von Schutzmaßnahmen verbleibt
Risiko (risk)	Maß für die Gefährdung, die von einer Bedrohung ausgeht
Risikoanalyse (risk analysis)	Prozess, der die Sicherheitsrisiken identifiziert, ihre Größenordnung bestimmt und die Bereiche identifiziert, die Schutzmaßnahmen erfordern
Risikomanagement (risk management)	Methodisches Vorgehen zur Erkennung, Bewertung, Handhabung und Reduktion von Risiken
SAA (Security Accreditation Authority)	Akkreditierungsstelle für IT-Sicherheit; Sie hat unter anderem die Aufgabe, die Verarbeitung von EU-Verschlusssachen zu genehmigen. In Österreich wird die Funktion der SAA von der ISK / Büro der Informationssicherheitskommission (ISB) wahrgenommen. Das Verzeichnis der nationalen Sicherheitsbehörden der EU-Mitgliedsstaaten kann dem Ratsbeschluss [EU2004] entnommen werden.
SAL (Security Aspects Letter)	In den Vertragsbeziehungen zwischen Auftraggeber und Auftragnehmer, bzw. Subauftragnehmern, werden alle Sicherheitsanforderungen in einem sogenannten „Security Aspects Letter“ (SAL) festgelegt. Dieser kann je nach Projekt unterschiedliche Anforderungen beinhalten. Als Beispiel wird ein SAL der NATO in Anhang 1 wiedergegeben.
Schaden (damage)	Minderung des Wertes eines Objektes bei Eintritt einer Bedrohung
Schutzbedarf	Maß für die möglichen Schäden, die beim IT-Einsatz entstehen können, und für die Notwendigkeit, den Eintritt solcher Schäden zu verhindern
Schutzbedarfsfeststellung (high level risk analysis)	Ermittlung des Schutzbedarfes für ein IT-System; im Fall eines kombinierten Risikoanalyse-Ansatzes können etwa die Schutzbedarfskategorien "niedrig bis mittel" und "hoch bis sehr hoch" oder "normal", "mittel" und "hoch" unterschieden werden.
Schutzmaßnahme (safeguard)	Verfahrensweise oder Mechanismus zur Verringerung von Risiken
Schwachstelle (vulnerability)	Sicherheitsschwäche eines oder mehrerer Objekte, die durch eine Bedrohung ausgenutzt werden kann
SecOP (Security Operating Procedures)	Sicherheitsbezogene Betriebsverfahren mit einer detaillierten Beschreibung der vorgesehenen Abläufe, der Sicherheitseigenschaften eines Systems und der Verantwortlichkeiten des Personals. SecOPs bilden die Grundlage einer Akkreditierung.
Sicherheitsmanagement (security management)	kontinuierlicher Prozess zur Gewährleistung von Vertraulichkeit, Integrität, Verfügbarkeit, Zurechenbarkeit, Authentizität und Zuverlässigkeit von IT-Systemen
Sicherheitsmaßnahme (safeguard)	s. Schutzmaßnahme
Sicherheitsrichtlinie	Leitlinien, Regeln und Praktiken, die vorschreiben, in welcher Weise sensitive Informationen und Betriebsmittel innerhalb eines bestimmten IT-Systems behandelt, geschützt und verteilt werden
Sicherheitsunbedenklichkeitsbescheinigung	s. FIS (Facility Security Clearance Information Sheet)
SSRS (System-Specific Security Requirement Statement)	Systemspezifische Sicherheitsanforderungen; Die SSRS wird zwischen der für den Betrieb des Systems zuständigen Stelle (SOA) und der SAA verbindlich vereinbart und bei der Akkreditierung des Systems zugrunde gelegt. Die SSRS ist eine vollständige und ausführliche Festlegung der einzuhaltenden Sicherheitsgrundsätze und der zu erfüllenden Sicherheitsanforderungen. Eine SSRS bezieht sich immer auf ein bestimmtes konkretes Projekt.
Subjekt (subject)	aktive Entität, normalerweise in der Form einer Person, eines Prozesses oder von Geräten
Verfügbarkeit (availability)	Eigenschaft, auf Verlangen einer berechtigten Entität zugreifbar und benutzbar zu sein
Vertraulichkeit (confidentiality)	Eigenschaft, dass Information nur befugten Entitäten in der zulässigen Weise zugänglich ist
Vertrauenswürdigkeit (assurance)	Eigenschaft, die das Maß an Vertrauen ausdrückt, das man in die Sicherheit eines IT-Systems haben kann
Virus (virus)	(auch: Computer-Virus) Nicht selbständige Programmroutine, die sich selbst reproduziert und dadurch vom Anwender nicht kontrollierbare Manipulationen in Systembereichen, an anderen Programmen oder deren Umgebung vornimmt
Zertifizierung (certification)	Formale Erklärung, die die Ergebnisse einer Evaluierung und die ordnungsgemäße Anwendung der benutzten Evaluationskriterien bestätigt
Zugriff (access)	Vorgang, der einem Nutzer Daten, Programme oder Ressourcen eines IT-Systems zugänglich macht. Dieser Vorgang kann beispielsweise lesend, schreibend oder ausführend erfolgen.
Zurechenbarkeit (accountability)	Eigenschaft, die sicherstellt, dass die Aktivitäten einer Entität eindeutig auf diese Entität zurückgeführt werden können
Zutritt (access)	Betreten von Bereichen (z.B. Räumen), in denen Teile des IT-Systems aufgestellt sind, durch Personen
Zuverlässigkeit (reliability)	Eigenschaft eines gleich bleibenden, beabsichtigten Verhaltens und Ergebnisses

Tabelle A.6: Glossar

Österreichisches Informationssicherheitshandbuch

Teil 1: Informationssicherheitsmanagement

Inhalt

Vorwort (Management Summary)

Neuerungen in der Version 2.3

Anwendungsbereich

Kompatibilität mit internationalen Aktivitäten

Sicherstellung der Aktualität

1 Informationssicherheitsmanagement in der Praxis

1.1 Ziele und Aufgaben des Informationssicherheitsmanagements

1.2 Zielsetzungen des Handbuches

Einige generelle Anmerkungen:

2 Der Informationssicherheitsmanagement-Prozess

Entwicklung einer organisationsweiten Informationssicherheitspolitik

Risikoanalyse

Erstellung eines Sicherheitskonzeptes

Umsetzung des Informationssicherheitsplans

Informationssicherheit im laufenden Betrieb