-<booklet uid="9" uv="1" xsi:schemaLocation="http://www.a-sit.at/siha ..\xsd\OE_IT_SIHB_UPDATE_OE.xsd" xmlns="http://www.a-sit.at/siha" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns="http://www.a-sit.at/siha">

-<meta uid="10" uv="1">

<booktitle>Österreichisches Informationssicherheitshandbuch</booktitle>

<booksubtitle>Teil 1: Informationssicherheitsmanagement</booksubtitle>

<bookdate>27.April 2007</bookdate>

</meta>

-<chapter uid="11" uv="1" version="2.1.001">

-<title uid="12" uv="1">

<name>Vorwort (Management Summary)</name>

</title>

<abstract uid="51" uv="1">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. </abstract>

<abstract uid="51" uv="1">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.</abstract>

<detailed uid="15" uv="1">Aus der Fülle möglicher Bedrohungen und der Fülle möglicher Gegenmaßnahmen methodisch diejenigen identifizieren zu helfen, welche für ein spezielles Szenario beachtet werden sollen bzw. müssen, war von Beginn an die Zielsetzung dieses Handbuches. Ausgehend von seiner ersten Version („IT-Sicherheitshandbuch für die öffentliche Verwaltung“), die sich am Sicherheitsbedürfnis öffentlicher Einrichtungen orientiert hat, wurde beim „Österreichischen IT-Sicherheits¬handbuch“ dem steigenden Interesse aus der Wirtschaft Rechnung getragen, um in der vorliegenden Version „Österreichisches Informationssicherheitshandbuch“ auf die umfassende Bedeutung von Information - unabhängig von ihrer Gestalt - einzugehen.</detailed>

<detailed uid="2100" uv="1">Selbstverständlich betreffen solche Weiterentwicklungen vor allem die Inhalte: Ist es doch die rasante Entwicklung im Bereich der Informationstechnologie (IT), welche sowohl in der öffentlichen Verwaltung als auch in der Privatwirtschaft zu bemerkenswerten Innovationsschüben führt, sowohl für die rechtmäßigen Besitzer/innen der Information wie auch für die potentiell unrechtmäßigen. Es gibt nicht nur immer wieder neue Technologien, sondern auch völlig neue Anwendungsgebiete wie z.B. E-Government. Die steigende Vernetzung führt dazu, dass Information „ortslos“ wird - es ist unerheblich wo diese bzw. ihr/e Nutzer/in sich gerade physisch befinden. </detailed>

<detailed uid="2101" uv="1">Gleichzeitig steigt das Risikopotential. Am Beispiel der Spam-E-Mails kann man erkennen, wie schnell ein zunächst harmlos erscheinendes Phänomen zu einem massiven Problem wurde. Und schließlich ist es immer noch die Person, der besonderes Augenmerk zu schenken ist - sie entwickelt sich nicht so rasant weiter wie die Technik; auf „typische“ Verhaltensmuster ist Verlass - sonst wären E-Mail-Würmer oder die jüngsten Phishing-Angriffe nicht so problematisch.</detailed>

<detailed uid="2102" uv="1">Ein Sicherheitshandbuch kann somit seinen Zweck nur dann erfüllen, wenn es regelmäßig der aktuellen Entwicklung Rechnung trägt und daher immer wieder überarbeitet, ergänzt und ggf. neu ausgerichtet wird. Das war die Motivation, die vorliegende Version herauszugeben.</detailed>

<detailed uid="2103" uv="1">Schwerpunktmäßig soll damit Unterstützung geboten werden, um:</detailed>

-<itemize uid="16" uv="1">

<item>relevante Sicherheitsziele und -strategien zu ermitteln,</item>

<item>eine organisationsspezifischen Informationssicherheitspolitik zu erstellen,</item>

<item>spezifisch geeignete Sicherheitsmaßnahmen auszuwählen und zu realisieren,</item>

<item>Informationssicherheit im laufenden Betrieb zu gewährleisten,</item>

<item>Kenntnis international üblicher Good-Practices im Bereich der Informationssicherheit zu erlangen.</item>

</itemize>

<detailed uid="17" uv="1">Das Informationssicherheitshandbuch besteht aus zwei Teilen:</detailed>

-<detailed uid="18" uv="1">

Der erste Teil

<emphasize level="0">"Informationssicherheitsmanagement"</emphasize>

beschreibt den grundlegenden Vorgang, Informationssicherheit in einer Behörde, Organisation bzw. einem Unternehmen zu etablieren und bietet eine konkrete Anleitung, den

<emphasize level="0">umfassenden und kontinuierlichen Sicherheitsprozess</emphasize>

zu entwickeln.

</detailed>

-<detailed uid="19" uv="1">

Der zweite Teil mit dem Titel

<emphasize level="0">"Informationssicherheitsmaßnahmen"</emphasize>

beschreibt die konkreten Einzelmaßnahmen auf organisatorischer, personeller, infrastruktureller und technischer Ebene, sodass den spezifischen Bedrohungen

<emphasize level="0">angemessene Standardsicherheitsmaßnahmen</emphasize>

für IT-Systeme und Informationen entgegengesetzt werden können. Dabei wird besonders auf die spezifisch österreichischen Anforderungen, Regelungen und Rahmenbedingungen, aber auch auf die durchgängige Einbeziehung des gesamten Lebenszyklus der jeweiligen Systeme, von der Entwicklung bis zur Beendigung des Betriebs, eingegangen. Ein eigenes Kapitel wurde der "Industriellen Sicherheit" gewidmet, das Unterstützung für die Erstellung einer Sicherheitsunbedenklichkeitsbescheinigung und eine Übersicht aller für industrielle Sicherheit relevanten Vorgabedokumente aus dem nationalen, EU- und NATO-Bereich gibt. Als komfortable Erleichterung bietet die elektronische Version des Handbuchs die Möglichkeit, automatisiert die für spezielle Szenarien notwendigen bzw. maßgeblichen Kapitel auswählen zu lassen, indem zuvor organisationsbedingte Parameter vorgegeben werden.

</detailed>

-<paragraph uid="2105" uv="1" version="2.3.000">

-<title uid="2106" uv="1">

<name>Neuerungen in der Version 2.3</name>

</title>

<detailed uid="2107" uv="1">Das frühere IT-Sicherheitshandbuch wurde zum Informationssicherheitshandbuch weiterentwickelt. Das primäre Thema ist daher die Sicherheit der Information unter Verwendung sicherer Technologien, welche auch über die reine Informationstechnologie hinausgehen. Informationssicherheit bedeutet auch Umgang mit klassifizierten Informationen (nach nationalen, EU- und NATO-Vorgaben). Hievon sind vor allem Behörden und solche Unternehmen betroffen, welche bei Ausschreibungen mit klassifizierten Informationen zu tun haben. Die industrielle Sicherheit wird in einem eigenen Kapitel des Informationssicherheitshandbuches behandelt.</detailed>

<detailed uid="2108" uv="1">Die Bedürfnisse der Wirtschaft bzw. Industrie werden in allen Teilen berücksichtigt: so wurde die elektronische Form so umgestaltet, dass eine einfache Anpassung und Adaptierung an die Anforderungen von Unternehmen möglich ist. Die Maßnahmen für Checklisten können nun auf drei Detaillierungsebenen ausgewählt werden. Die elektronische Version kann nun noch einfacher lokal auf einem Anwender-PC oder in einem Behörden- oder Firmennetzwerk installiert werden. Mit der Einarbeitung der aktuellen IKT-Board Beschlüsse ist nun auch der Teil 2 wieder auf dem aktuellsten Stand für den Einsatz in der Verwaltung. </detailed>

</paragraph>

-<paragraph uid="20" uv="1" version="2.1.001">

-<title uid="21" uv="1">

<name>Anwendungsbereich</name>

</title>

<detailed uid="22" uv="1">Das Informationssicherheitshandbuch versteht sich als Sammlung von Leitlinien und Empfehlungen, die entsprechend den spezifischen Anforderungen und Bedürfnissen in einer Einsatzumgebung angepasst werden müssen. Es stellt eine Ergänzung zu den bestehenden Regelungen und Vorschriften (Datenschutzgesetz, Informationssicherheitsgesetz, Verschlusssachenvorschriften, Amtsgeheimnis, ...) dar und setzt diese weder außer Kraft noch steht es zu ihnen im Widerspruch.</detailed>

-<detailed uid="23" uv="1">

Durch die Aktualisierung und Erweiterung auf Informationssicherheit stellt das Informationssicherheitshandbuch nun für eine noch breitere Zielgruppe das ideale Informationssicherheits-Werkzeug dar.

</detailed>

</paragraph>

-<paragraph uid="24" uv="1" version="2.1.001">

-<title uid="25" uv="1">

<name>Kompatibilität mit internationalen Aktivitäten</name>

</title>

<detailed uid="26" uv="1">Seit einigen Jahren werden auf nationaler und internationaler Ebene verstärkt Anstrengungen unternommen, einheitliche methodische Vorgehensweisen zur Etablierung von Informationssicherheit sowie Standard-Maßnahmenkataloge zu erarbeiten. Im Informationssicherheitshandbuch wird versucht, diesen internationalen Entwicklungen so weit wie möglich Rechnung zu tragen. Bei der Erstellung der Vorgehensweisen und Maßnahmenbeschreibungen wurde daher auch auf bewährte und etablierte Quellen zurückgegriffen, die im Einzelnen im Anhang des Handbuches angeführt sind. Insbesondere darf dem deutschen Bundesamtes für Sicherheit in der Informationstechnik (BSI) für dessen Zustimmung zur Nutzung des Grundschutzhandbuches gedankt werden, das eine wichtige Basis für das vorliegende Handbuch darstellt. Im Bereich der Informationssicherheit bzw. für die industrielle Sicherheit sind die Vorgabedokumente der EU und NATO maßgeblich.</detailed>

</paragraph>

-<paragraph uid="27" uv="1" version="2.1.001">

-<title uid="28" uv="1">

<name>Sicherstellung der Aktualität</name>

</title>

<detailed uid="29" uv="1">Um die Aktualität der beschriebenen Maßnahmen sicherzustellen, wird das Österreichische Informationssicherheitshandbuch regelmäßig überarbeitet und aktualisiert. Von besonderer Bedeutung ist dabei ein Feedback über die Erfahrungen mit der Anwendung des Handbuches in der Praxis. Alle Personen, die das Handbuch anwenden, werden daher eingeladen, diesbezügliche Anregungen und Erfahrungen jenen, die das Handbuch verfasst haben, mitzuteilen.</detailed>

</paragraph>

</chapter>

-<chapter uid="49" uv="1" version="2.3.001">

-<title uid="50" uv="1">

<name>Informationssicherheitsmanagement in der Praxis</name>

</title>

<abstract uid="51" uv="1">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. </abstract>

<detailed uid="52" uv="1">Dabei darf sich Sicherheit nicht auf einzelne Teilaspekte, wie die Verschlüsselung vertraulicher Daten oder die Installation von Firewalls beschränken, sondern muss integraler Bestandteil eines modernen IKT-(Informations- und Kommunikationstechnologie-)Konzeptes sein. Methodisches Sicherheitsmanagement ist zur Gewährleistung umfassender und angemessener Informationssicherheit unerlässlich.</detailed>

<detailed uid="53" uv="1">Das gegenständliche Handbuch beschreibt die Vorgehensweise zur Etablierung eines umfassenden Informationssicherheitsmanagementsystems (ISMS). Dabei wird Information unabhängig von ihrer Darstellungsform betrachtet, also elektronisch gespeicherte und verarbeitete Information genauso wie Information in schriftlicher oder gesprochener Form. </detailed>

<detailed uid="2000" uv="1">Die hier dargestellte Vorgehensweise wird für die österreichische Bundesverwaltung sowie für andere Bereiche der öffentlichen Verwaltung bzw. für die Privatwirtschaft zur Anwendung empfohlen.</detailed>

-<section uid="54" uv="1" version="2.3.001">

-<title uid="55" uv="1">

<name>Ziele und Aufgaben des Informationssicherheitsmanagements</name>

</title>

-<role uid="56" uv="1">

</role>

<abstract uid="57" uv="1">Informationssicherheitsmanagement ist ein kontinuierlicher Prozess, der die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen in einer Organisation gewährleisten soll. Dies soll durch die Etablierung eines Informationssicherheitsmanagementsystems (ISMS) erreicht werden. </abstract>

<detailed uid="58" uv="1">Zu den Aufgaben des Informationssicherheitsmanagements gehören:</detailed>

-<itemize uid="59" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="60" uv="1">

</role>

Festlegung der Sicherheitsziele und -strategien der Organisation,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="61" uv="1">

</role>

Ermittlung und Bewertung der Informationssicherheitsrisiken (information security risk assessment),

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="63" uv="1">

</role>

Festlegung geeigneter Sicherheitsmaßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="64" uv="1">

</role>

Überwachung der Implementierung und des laufenden Betriebes der ausgewählten Maßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="65" uv="1">

</role>

Förderung des Sicherheitsbewusstseins innerhalb der Organisation sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="66" uv="1">

</role>

Entdecken von und Reaktion auf sicherheitsrelevante Ereignisse ( information security incident handling ).

</item>

</itemize>

<detailed uid="67" uv="1">Informationssicherheit ist immer eine Management-Aufgabe. Nur wenn die Leitung einer Organisation voll hinter den Sicherheitszielen und den damit verbundenen Aktivitäten steht, kann diese Aufgabe erfolgreich wahrgenommen werden.</detailed>

</section>

-<section uid="68" uv="1" version="2.3.001">

-<title uid="69" uv="1">

<name>Zielsetzungen des Handbuches</name>

</title>

-<role uid="70" uv="1">

</role>

<abstract uid="71" uv="1">Das vorliegende Informationssicherheitshandbuch soll es Sicherheitsverantwortlichen und Führungskräften ermöglichen, die für ihren Bereich relevanten Informationssicherheitsziele und -strategien zu ermitteln, eine organisationsweite Informationssicherheitspolitik zu erstellen, geeignete und angemessene Sicherheitsmaßnahmen auszuwählen und zu realisieren sowie Informationssicherheit im laufenden Betrieb zu gewährleisten. Darüber hinaus soll das Handbuch dazu beitragen, eine einheitliche Vorgehensweise und Sprachregelung im Bereich der Informationssicherheit zu entwickeln, wobei aber größtmögliche Flexibilität zur Umsetzung der unterschiedlichen Sicherheitsanforderungen der einzelnen Organisationen bzw. Organisationseinheiten (OEs) gewahrt bleiben soll.</abstract>

<detailed uid="72" uv="1">Ziel ist es, Informationssicherheit zu einem integralen Bestandteil der Geschäftsprozesse einer Organisation zu machen.</detailed>

-<paragraph uid="73" uv="1" version="2.3.001">

-<title uid="74" uv="1">

<name>Einige generelle Anmerkungen:</name>

</title>

<detailed uid="2001" uv="1"> Abgrenzung IT-Sicherheit und Informationssicherheit: </detailed>

<detailed uid="75" uv="1">Die Frage der Definition dieser beiden Begriffe und ihrer Abgrenzung voneinander war in den vergangenen Jahren oft Gegenstand lebhafter Diskussionen. Dabei ist auch ein gewisser Bedeutungswandel bei diesen Begriffen festzustellen: Verstand man von einigen Jahren unter "IT-Sicherheit" im Wesentlichen den Schutz von IT-Systemen (und damit den auf ihnen verarbeiteten Informationen) und unter "Informationssicherheit" den Schutz von Informationen unabhängig von ihrer Darstellungsform (also elektronisch, schriftlich, bildhaft oder gesprochen), so sind diese beiden Begriffe mittlerweile fast synonym zu sehen: auch in der IT-Sicherheit sind Fragen zu behandeln, wie Information an sich geschützt werden kann (etwa wie mit Papierausdrucken von vertraulichen Informationen umzugehen ist), während umgekehrt die Sicherheit von elektronisch gespeicherten und verarbeiteten Informationen ohne die technische Sicherung der zugrunde liegenden IKT-(Informations- und Kommunikationstechnologie-)Systeme nicht zu erreichen ist. Die Grenzen sind also fließend. International hat sich in den letzten Jahren eher der Begriff "Informationssicherheit" als der umfassendere etabliert. Dieser Entwicklung Rechnung tragend wird das bisherige "Österreichische IT-Sicherheitshandbuch" mit der vorliegenden Version in "Österreichisches Informationssicherheitshandbuch" umbenannt.</detailed>

<detailed uid="2002" uv="1">Scope:</detailed>

<detailed uid="76" uv="1">Inhaltlich behandelt das vorliegende Handbuch den gesamten Bereich der Informationssicherheit. Information wird dabei wie oben diskutiert umfassend gesehen: in elektronisch gespeicherter oder übertragener Form, sowie auch schriftliche, gesprochene oder bildhaft dargestellte Information. Betrachtet werden dabei auch die Sicherheit von Hardware und Software, die zur Speicherung, Verarbeitung und Übertragung von Informationen dient, sowie organisatorische, bauliche und personelle Fragen, soweit sie in direktem Zusammenhang mit der Sicherheit von IKT-Systemen und den von ihnen verarbeiteten Informationen stehen. Die Abgrenzung zu verwandten Gebieten, wie Brandschutz, Objektsicherheit, Sicherheit von kritischen Infrastrukturen oder Datenschutz ist nicht immer eindeutig, oft gibt es Überschneidungen zwischen den einzelnen Themen. Das vorliegende Handbuch geht hier einen pragmatischen Weg und versucht, Lösungen und Anleitung für die in der Praxis auftretenden Probleme zu geben.</detailed>

<detailed uid="2003" uv="1">Neu gegenüber den Vorgängerversionen ist ein spezielles Kapitel zum Thema "industrielle Sicherheit", das die Anforderungen an Firmen, die sich um Aufträge bewerben, in denen EU-klassifizierte Informationen verarbeitet werden, darstellt.</detailed>

</paragraph>

</section>

</chapter>

-<chapter uid="83" uv="1" version="2.3.001">

-<title uid="84" uv="1">

<name>Der Informationssicherheitsmanagement-Prozess</name>

</title>

<abstract uid="85" uv="1">Informationen und die sie verarbeitenden Prozesse, Systeme und Netzwerke sind wichtige Werte jeder Organisation, sowohl in der öffentlichen Verwaltung als auch in der Privatwirtschaft. Informationssicherheitsmanagement (ISM) soll die Vertraulichkeit, Integrität und Verfügbarkeit der Informationen und der sie verarbeitenden Systeme gewährleisten. Fallweise können auch weitere Anforderungen wie Zurechenbarkeit, Authentizität und Zuverlässigkeit bestehen.</abstract>

<detailed uid="86" uv="1">Informationssicherheitsmanagement ist ein kontinuierlicher Prozess, dessen Strategien und Konzepte ständig auf ihre Leistungsfähigkeit und Wirksamkeit zu überprüfen und bei Bedarf fortzuschreiben sind.</detailed>

<detailed uid="87" uv="1">Zentrale Aktivitäten im Rahmen des ISM sind: </detailed>

-<itemize uid="88" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="89" uv="1">

</role>

die Entwicklung einer organisationsweiten Informationssicherheitspolitik

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="90" uv="1">

</role>

die Durchführung einer Risikoanalyse

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="91" uv="1">

</role>

die Erstellung eines Sicherheitskonzeptes

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="92" uv="1">

</role>

die Umsetzung der Sicherheitsmaßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="93" uv="1">

</role>

die Gewährleistung der Informationssicherheit im laufenden Betrieb

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2010" uv="1">

</role>

die kontinuierliche Überwachung und Verbesserung des ISMS

</item>

</itemize>

-<detailed uid="94" uv="1">

Der nachfolgend dargestellte Prozess basiert auf internationalen Standards und Leitlinien zum Informationssicherheitsmanagement, insbesondere den "Guidelines on the Management of IT Security (GMITS)" ([ISO/IEC TR 13335]) (

-<link uid="95" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

) sowie ISO/IEC 27001(

-<link uid="2011" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

). Er kann sowohl auf eine gesamte Organisation als auch auf Teilbereiche Anwendung finden.

</detailed>

<detailed uid="97" uv="1">Über die Anwendung auf Ebene einzelner Behörden, Abteilungen oder anderer Organisationseinheiten ist dann im spezifischen Zusammenhang - abhängig vom IT-Konzept und den bestehenden Sicherheitsanforderungen - zu entscheiden. </detailed>

<detailed uid="98" uv="1">Die nachfolgende Graphik zeigt die wichtigsten Aktivitäten im Rahmen des Informationssicherheitsmanagements und die eventuell erforderlichen Rückkopplungen zwischen den einzelnen Stufen.</detailed>

<detailed uid="99" uv="1">Im Folgenden wird, wenn nicht ausdrücklich anders angeführt, allgemein der Begriff "Organisation" (oder synonym dazu "Institution") verwendet, wobei aber zu beachten ist, dass damit beliebige Organisationseinheiten gemeint sein können.</detailed>

<detailed uid="101" uv="1">Informationssicherheitsmanagement umfasst damit folgende Schritte:</detailed>

-<paragraph uid="102" uv="1" version="2.3.001">

-<title uid="103" uv="1">

<name>Entwicklung einer organisationsweiten Informationssicherheitspolitik</name>

</title>

-<abstract uid="104" uv="1">

Als organisationsweite Informationssicherheitspolitik (

<emphasize level="0">Corporate Information Security Policy</emphasize>

) bezeichnet man die Leitlinien und Vorgaben innerhalb einer Organisation, die unter Berücksichtigung gegebener Randbedingungen grundlegende Ziele, Strategien, Verantwortlichkeiten und Methoden für die Gewährleistung der Informationssicherheit festlegen.

</abstract>

<detailed uid="105" uv="1">Die organisationsweite Informationssicherheitspolitik (im Folgenden der Einfachheit halber als "Informationssicherheitspolitik" bezeichnet) stellt ein langfristig orientiertes Grundlagendokument dar, auf dessen Basis die Informationssicherheit einer Organisation aufgebaut wird. Details zu Sicherheitsmaßnahmen und deren Umsetzung sind nicht Bestandteil der organisationsweiten Informationssicherheitspolitik, sondern sind im Rahmen einzelner systemspezifischer Sicherheitsrichtlinien zu behandeln.</detailed>

<detailed uid="107" uv="1">Die Informationssicherheitspolitik ist eingebettet in eine Hierarchie von Regelungen und Leitlinien. Abhängig vom IT-Konzept und den Sicherheitsanforderungen kann es auch notwendig werden, eine Hierarchie von Informationssicherheitspolitiken für verschiedene Organisationseinheiten (etwa Abteilungen, nachgeordnete Dienststellen, ...) zu erstellen.</detailed>

</paragraph>

-<paragraph uid="108" uv="1" version="">

-<title uid="109" uv="1">

<name>Risikoanalyse</name>

</title>

-<abstract uid="110" uv="1">

Eine wesentliche Aufgabe des Informationssicherheitsmanagements ist das Erkennen und Einschätzen von Sicherheitsrisiken und deren Reduktion auf ein tragbares Maß. Dieses "Informationsrisikomanagement" oder auch "Informationssicherheitsrisikomanagement" sollte Teil des generellen Risikomanagements einer Organisation und mit der dort gewählten Vorgehensweise kompatibel sein. Aus Gründen der besseren Lesbarkeit wird im Folgenden, wenn nicht explizit anders erwähnt, der Begriff "Risiko" stets im Sinne von "Informationssicherheitsrisiko" verwendet, ebenso Risikoanalyse und Risikomanagement im Sinne von Informationssicherheitsrisikoanalyse und –management.Im Rahmen des vorliegenden Handbuches werden drei Risikoanalysestrategien behandelt (s. Kapitel

-<link uid="111" uv="1">

-<intern>

<name>Risikoanalyse</name>

<source>#CHAPTER 4</source>

</intern>

</link>

): Detaillierte Risikoanalyse, Grundschutzansatz und Kombinierter Ansatz. Die Festlegung einer geeigneten Risikoanalysestrategie sollte im Rahmen der Informationssicherheitspolitik erfolgen, um ein organisationsweit einheitliches Vorgehen zu gewährleisten.

</abstract>

</paragraph>

-<paragraph uid="112" uv="1" version="2.3.001">

-<title uid="113" uv="1">

<name>Erstellung eines Sicherheitskonzeptes</name>

</title>

<abstract uid="114" uv="1">Abhängig von den Ergebnissen der Risikoanalyse werden in einem nächsten Schritt Maßnahmen ausgewählt, die die Risiken auf ein definiertes und beherrschbares Maß reduzieren sollen. Im Anschluss daran ist das verbleibende Restrisiko zu ermitteln und zu prüfen, ob dieses für die Organisation tragbar ist oder weitere Maßnahmen zur Risikoreduktion erforderlich sind.</abstract>

<detailed uid="115" uv="1">Für wichtige IT-Systeme und Anwendungen wird die Erstellung eigener Sicherheitsrichtlinien (auch als "IT-Systemsicherheitspolitiken" bezeichnet) empfohlen. Diese sollen die grundlegenden Leitlinien zur Sicherheit eines konkreten IT-Systems bzw. einer Anwendung vorgeben sowie konkrete Sicherheitsmaßnahmen und ihre Umsetzung beschreiben. Die Sicherheitsrichtlinien müssen mit der organisationsweiten Informationssicherheitspolitik kompatibel sein.</detailed>

<detailed uid="116" uv="1">In einem Informationssicherheitsplan werden alle kurz-, mittel- und langfristigen Aktionen festgehalten, die zur Umsetzung der ausgewählten Maßnahmen erforderlich sind. </detailed>

-<detailed uid="117" uv="1">

Die Erstellung von Sicherheitskonzepten wird in Kapitel

-<link uid="118" uv="1">

-<intern>

<name>Erstellung von Sicherheitskonzepten</name>

<source>#CHAPTER 5</source>

</intern>

</link>

behandelt.

</detailed>

</paragraph>

-<paragraph uid="119" uv="1" version="2.3.001">

-<title uid="120" uv="1">

<name>Umsetzung des Informationssicherheitsplans</name>

</title>

<abstract uid="121" uv="1">Bei der Implementierung der ausgewählten Sicherheitsmaßnahmen ist zu beachten, dass die meisten technischen Sicherheitsmaßnahmen ein geeignetes organisatorisches Umfeld brauchen, um vollständig wirksam zu sein. Unabdingbare Voraussetzung für eine erfolgreiche Umsetzung des Informationssicherheitsplanes in der Praxis sind auch entsprechende Sensibilisierungs- und Schulungsmaßnahmen. Weiters ist festzulegen, wie die Effizienz und Effektivität der ausgewählten Sicherheitsmaßnahmen beurteilt werden kann. Dies erfolgt durch die Definition geeigneter Kennzahlen.</abstract>

-<detailed uid="122" uv="1">

Kapitel

-<link uid="123" uv="1">

-<intern>

<name>Umsetzung des Informationssicherheitsplanes</name>

<source>#CHAPTER 6</source>

</intern>

</link>

des vorliegenden Handbuches behandelt diese Umsetzungsfragen.

</detailed>

</paragraph>

-<paragraph uid="124" uv="1" version="2.3.001">

-<title uid="125" uv="1">

<name>Informationssicherheit im laufenden Betrieb</name>

</title>

<abstract uid="126" uv="1">Umfassendes Informationssicherheitsmanagement beinhaltet nicht zuletzt auch die Aufgabe, die Sicherheit im laufenden Betrieb aufrechtzuerhalten und gegebenenfalls veränderten Bedingungen anzupassen.</abstract>

-<detailed uid="127" uv="1">

Zu den erforderlichen Follow-Up-Aktivitäten zählen (s. Kapitel

-<link uid="128" uv="1">

-<intern>

<name>Informationssicherheit im laufenden Betrieb</name>

<source>#CHAPTER 7</source>

</intern>

</link>

</detailed>

-<itemize uid="129" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="130" uv="1">

</role>

<emphasize level="2">Die Aufrechterhaltung des erreichten Sicherheitsniveaus</emphasize>

<emphasize level="2">Dies umfasst:</emphasize>

-<itemize uid="1523" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

<role/>

Wartung und administrativen Support von Sicherheitseinrichtungen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

<role/>

die Messung der Effektivität der ausgewählten Sicherheitsmaßnahmen anhand definierter Kennzahlen (

<emphasize level="0">Information Security Measurement</emphasize>

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

<role/>

die Überprüfung von Maßnahmen auf Übereinstimmung mit der InformationssT-Sicherheitspolitik (

<emphasize level="0">Security Compliance Checking</emphasize>

) sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

<role/>

die fortlaufende Überwachung der IT-Systeme (

<emphasize level="0">Monitoring </emphasize>

)

</item>

</itemize>

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2012" uv="1">

</role>

umfassendes Change Management

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="131" uv="1">

</role>

eine angemessene Reaktion auf sicherheitsrelevante Ereignisse (

<emphasize level="0">Incident Handling</emphasize>

)

</item>

</itemize>

</paragraph>

</chapter>

-<chapter uid="133" uv="1" version="2.3.001">

-<title uid="134" uv="1">

<name>Entwicklung einer organisationsweiten Informationssicherheitspolitik</name>

</title>

<abstract uid="135" uv="1">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.</abstract>

<detailed uid="136" uv="1">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.</detailed>

<detailed uid="137" uv="1">Ziel dieses Abschnittes ist es, die Erarbeitung einer Informationssicherheitspolitik zu unterstützen. </detailed>

<detailed uid="138" uv="1">Das folgende Kapitel gibt eine Anleitung zur Erstellung einer derartigen Politik und legt die wesentlichen Inhalte fest. Diese sind:</detailed>

-<itemize uid="139" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="140" uv="1">

</role>

Informationssicherheitsziele und -strategien

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2013" uv="1">

</role>

Erklärung der Leitungsebene über die Unterstützung der Ziele des Informationssicherheitsmanagements (Management Commitment)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="141" uv="1">

</role>

Organisation und Verantwortlichkeiten für Informationssicherheit

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="142" uv="1">

</role>

Risikoanalysestrategien, akzeptables Restrisiko und Risikoakzeptanz

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="143" uv="1">

</role>

Klassifizierung von Daten

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="144" uv="1">

</role>

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

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="145" uv="1">

</role>

Aktivitäten zur Überprüfung und Aufrechterhaltung der Sicherheit

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2014" uv="1">

</role>

Verweise auf weitere Dokumente zum Thema Informationssicherheit, wie etwa Sicherheitsrichtlinien

</item>

</itemize>

-<section uid="146" uv="1" version="2.1.003">

-<title uid="147" uv="1">

<name>Aufgaben und Ziele einer Informationssicherheitspolitik</name>

</title>

-<role uid="148" uv="1">

</role>

<abstract uid="149" uv="1">Eine organisationsweite Informationssicherheitspolitik hat die Aufgabe, die Vertraulichkeit, Integrität und Verfügbarkeit der Information in einer Organisation sicherzustellen.</abstract>

<detailed uid="150" uv="1">Dabei gilt:</detailed>

-<itemize uid="151" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="152" uv="1">

</role>

Die Informationssicherheitspolitik wird als schriftliches Dokument erstellt und bildet die Grundlage des Informationssicherheitsmanagements.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="153" uv="1">

</role>

Die Informationssicherheitspolitik legt Leitlinien fest, schreibt aber keine Implementierung vor.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2015" uv="1">

</role>

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).

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="154" uv="1">

</role>

Die Informationssicherheitspolitik wird offiziell verabschiedet und in Kraft gesetzt.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="155" uv="1">

</role>

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.

</item>

</itemize>

-<paragraph uid="156" uv="1" version="2.3.001">

-<title uid="157" uv="1">

<name>Geltungsbereich</name>

</title>

<abstract uid="158" uv="1">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.</abstract>

<detailed uid="159" uv="1">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.</detailed>

</paragraph>

</section>

-<section uid="160" uv="1" version="2.3.001">

-<title uid="161" uv="1">

<name>Die Inhalte der Informationssicherheitspolitik</name>

</title>

-<role uid="162" uv="1">

</role>

<abstract uid="163" uv="1">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.</abstract>

-<subsection uid="164" uv="1" version="2.3.001">

-<title uid="165" uv="1">

<name>Informationssicherheitsziele und -strategien</name>

</title>

-<role uid="166" uv="1">

</role>

-<paragraph uid="167" uv="1" version="2.3.001">

-<title uid="168" uv="1">

<name>Schritt 1: Festlegung der wesentlichen Informationssicherheitsziele</name>

</title>

<abstract uid="169" uv="1">Im Rahmen der Erstellung der Informationssicherheitspolitik sind zunächst die spezifischen Sicherheitsziele der Organisation zu erarbeiten, die mit dieser Politik erreicht werden sollen.</abstract>

<detailed uid="170" uv="1">Beispiele für solche Ziele sind:</detailed>

-<itemize uid="171" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="172" uv="1">

</role>

Gewährleistung der aus gesetzlichen Vorgaben resultierenden Anforderungen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="173" uv="1">

</role>

Gewährleistung des Vertrauens der Öffentlichkeit in die betroffene Organisation bzw. die öffentliche Verwaltung im Allgemeinen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="174" uv="1">

</role>

Hohe Verlässlichkeit des Handelns, insbesondere in Bezug auf Vertraulichkeit, Richtigkeit und Rechtzeitigkeit.

</item>

</itemize>

-<!--

 2006.10.29, EN

-->

<detailed>Dies erfordert:</detailed>

-<itemize uid="175" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="176" uv="1">

</role>

Vertraulichkeit der verarbeiteten Informationen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2016" uv="1">

</role>

Einhaltung aller Gesetze, Verträge und Regelungen (etwa des Datenschutzgesetzes, des Informationssicherheitsgesetzes, von SLAs und Normen)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="177" uv="1">

</role>

Korrektheit, Vollständigkeit und Authentizität der Informationen (Integrität der IT)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="178" uv="1">

</role>

Rechtzeitigkeit (Verfügbarkeit der Daten und Services)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="180" uv="1">

</role>

Sicherung der investierten Werte

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="181" uv="1">

</role>

Sicherstellung der Kontinuität der Arbeitsabläufe

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="182" uv="1">

</role>

Reduzierung der im Schadensfall entstehenden Kosten (Schadensvermeidung und Schadensbegrenzung)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="183" uv="1">

</role>

Gewährleistung des besonderen Prestiges

</item>

</itemize>

<detailed uid="184" uv="1">Neben diesen eher allgemein gültigen Zielen sind die organisationsspezifischen Sicherheitsziele - bezugnehmend auf die spezifischen Aufgaben und Projekte - zu formulieren.</detailed>

<detailed uid="185" uv="1">Zur Präzisierung dieser Ziele können folgende Fragen hilfreich sein:</detailed>

-<itemize uid="186" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="187" uv="1">

</role>

Welche Informationen sind besonders schützenswert?

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="188" uv="1">

</role>

Welche Auswirkungen hätte eine gravierende Verletzung der Sicherheit dieser Informationen (Verlust von Vertraulichkeit, Integrität und/oder Verfügbarkeit)?

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="189" uv="1">

</role>

Welche wesentlichen Entscheidungen hängen von der Genauigkeit, Integrität oder Verfügbarkeit dieser Informationen ab?

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="190" uv="1">

</role>

Welche essentiellen Aufgaben der betreffenden Organisation können bei Kompromittierung dieser Informationen nicht mehr durchgeführt werden?

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2017" uv="1">

</role>

Welche essentiellen Aufgaben der betreffenden Organisation können ohne IT-Unterstützung nicht mehr durchgeführt werden?

</item>

</itemize>

</paragraph>

-<paragraph uid="191" uv="1" version="2.1.000">

-<title uid="192" uv="1">

<name>Schritt 2: Festlegung des angestrebten Sicherheitsniveaus </name>

</title>

<detailed uid="193" uv="1">In diesem Schritt ist festzulegen, welches Sicherheitsniveau in Bezug auf</detailed>

-<itemize uid="194" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="195" uv="1">

</role>

Vertraulichkeit,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="196" uv="1">

</role>

Integrität und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="197" uv="1">

</role>

Verfügbarkeit

</item>

</itemize>

<detailed uid="198" uv="1">angestrebt werden soll.</detailed>

</paragraph>

-<paragraph uid="199" uv="1" version="2.3.001">

-<title uid="200" uv="1">

<name>Schritt 3: Ausarbeitung von Strategien für das Informationssicherheitsmanagement</name>

</title>

<abstract uid="201" uv="1">Die Sicherheitsstrategie legt fest, wie die definierten Sicherheitsziele erreicht werden können. </abstract>

<detailed uid="202" uv="1">Eine organisationsweite Informationssicherheitspolitik kann und soll lediglich eine High-Level-Beschreibung der gewählten Strategien beinhalten, Detailbeschreibungen sind Aufgabe der nachgeordneten Sicherheitsrichtlinien.</detailed>

<detailed uid="203" uv="1">Beispiele für Strategien für das Informationssicherheitsmanagement sind:</detailed>

-<itemize uid="204" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="206" uv="1">

</role>

eine klare Zuordnung aller Verantwortlichkeiten im Informationssicherheitsprozess,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="207" uv="1">

</role>

die Einführung eines QM-Systems,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="208" uv="1">

</role>

die Entwicklung von Sicherheitsrichtlinien für die wichtigsten Systeme, Services und Anwendungen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="209" uv="1">

</role>

die Etablierung eines organisationsweiten Incident Handling Plans,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="210" uv="1">

</role>

Orientierung an internationalen Richtlinien und Standards,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="211" uv="1">

</role>

Informationssicherheit als integraler Bestandteil des gesamten Lebenszyklus eines IT-Systems,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="212" uv="1">

</role>

die Förderung des Sicherheitsbewusstseins aller Mitarbeiter/innen.

</item>

</itemize>

</paragraph>

</subsection>

-<subsection uid="2018" uv="1" version="2.3.001">

-<title uid="2019" uv="1">

<name>Management Commitment</name>

</title>

-<role uid="2020" uv="1">

</role>

<abstract uid="2021" uv="1">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.</abstract>

</subsection>

-<subsection uid="213" uv="1" version="2.3.001">

-<title uid="214" uv="1">

<name> Organisation und Verantwortlichkeiten für Informationssicherheit </name>

</title>

-<role uid="215" uv="1">

</role>

<abstract uid="216" uv="1">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. </abstract>

<detailed uid="217" uv="1">Die Organisation des ISM ist für jede Institution - entsprechend ihrer Größe, Struktur und Aufgaben - spezifisch festzulegen und in der Informationssicherheitspolitik festzuschreiben. </detailed>

<detailed uid="225" uv="1">Zentrale Aufgaben im Informationssicherheitsmanagementprozess übernehmen dabei</detailed>

-<itemize uid="226" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="227" uv="1">

</role>

das Informationssicherheitsmanagement-Team,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="228" uv="1">

</role>

die IT-Sicherheitsbeauftragten (zur Wahl der Bezeichnung s. unten),

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="229" uv="1">

</role>

die Bereichs-IT-Sicherheitsbeauftragten und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="230" uv="1">

</role>

die Applikations-/Projektverantwortlichen.

</item>

</itemize>

-<detailed uid="2022" uv="1">

Auf der Ebene der Bundesverwaltung ist zusätzlich in jedem Ressort die Person einer/eines Informationssicherheitsbeauftragten gemäß

-<link uid="283" uv="1">

-<law>

<name>Informationssicherheitsgesetz</name>

<shortname>InfoSiG</shortname>

<source>#SECTION A.2</source>

</law>

</link>

einzurichten. Weiters werden für diesen Bereich durch das IKT-Board verbindliche Regelungen zur IKT-Sicherheit vorgegeben.

</detailed>

<detailed uid="232" uv="1">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.</detailed>

<detailed uid="233" uv="1">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.</detailed>

-<paragraph uid="234" uv="1" version="2.3.001">

-<title uid="235" uv="1">

<name>Die/der IT-Sicherheitsbeauftragte</name>

</title>

<abstract uid="236" uv="1">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. </abstract>

<detailed uid="2023" uv="1">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. </detailed>

<detailed uid="237" uv="1">Zu den Pflichten der/des IT-Sicherheitsbeauftragten gehören:</detailed>

-<itemize uid="238" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="239" uv="1">

</role>

die verantwortliche Mitwirkung an der Erstellung des Informationssicherheitskonzeptes,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="240" uv="1">

</role>

die Gesamtverantwortung für die Realisierung der ausgewählten Sicherheitsmaßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="241" uv="1">

</role>

die Planung und Koordination von Schulungs- und Sensibilisierungsveranstaltungen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="242" uv="1">

</role>

die Gewährleistung der Informationssicherheit im laufenden Betrieb sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="243" uv="1">

</role>

die Verwaltung der für Informationssicherheit zur Verfügung stehenden Ressourcen.

</item>

</itemize>

<detailed uid="244" uv="1">Die/der IT-Sicherheitsbeauftragte kann einzelne Aufgaben delegieren, die Gesamtverantwortung für die Informationssicherheit verbleibt aber bei dieser Person.</detailed>

<detailed uid="245" uv="1">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.</detailed>

</paragraph>

-<paragraph uid="246" uv="1" version="2.3.001">

-<title uid="247" uv="1">

<name>Das Informationssicherheitsmanagement-Team</name>

</title>

<abstract uid="248" uv="1">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.</abstract>

<detailed uid="249" uv="1">Zu den Aufgaben des Teams zählen typischerweise:</detailed>

-<itemize uid="250" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="251" uv="1">

</role>

die Festlegung der Informationssicherheitsziele der Organisation,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="252" uv="1">

</role>

die Entwicklung einer organisationsweiten Informationssicherheitspolitik,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="253" uv="1">

</role>

Unterstützung und Beratung bei der Erstellung des Informationssicherheitskonzeptes,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="254" uv="1">

</role>

die Überprüfung des Konzeptes auf Erreichung der Informationssicherheitsziele,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="255" uv="1">

</role>

die Förderung des Sicherheitsbewusstseins in der gesamten Organisation sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="256" uv="1">

</role>

die Festlegung der personellen und finanziellen Ressourcen für Informationssicherheit.

</item>

</itemize>

-<detailed uid="257" uv="1">

<emphasize level="2">Zusammensetzung des Teams:</emphasize>

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

</detailed>

<detailed uid="258" uv="1">Generell ist zu empfehlen, dass die/der IT-Sicherheitsbeauftragte sowie ein/e Vertreter/in der IT-Anwender/innen dem Informationssicherheitsmanagement-Team angehören.</detailed>

</paragraph>

-<paragraph uid="259" uv="1" version="2.3.001">

-<title uid="260" uv="1">

<name>Die Bereichs-IT-Sicherheitsbeauftragten</name>

</title>

<abstract uid="261" uv="1">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. </abstract>

<detailed uid="262" uv="1">Zu den Aufgaben einer/eines Bereichs-IT-Sicherheitsverantwortlichen zählen</detailed>

-<itemize uid="263" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="264" uv="1">

</role>

die Mitwirkung bei den ihren/seinen Bereich betreffenden Teilen des Informationssicherheitskonzeptes,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="265" uv="1">

</role>

die Erarbeitung eines detaillierten Planes zur Realisierung der ausgewählten Sicherheitsmaßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="266" uv="1">

</role>

die Umsetzung dieses Planes,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="267" uv="1">

</role>

die regelmäßige Prüfung der Wirksamkeit und Einhaltung der eingesetzten Sicherheitsmaßnahmen im laufenden Betrieb,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="268" uv="1">

</role>

Information der/des IT-Sicherheitsbeauftragten über bereichsspezifischen Schulungsbedarf sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="269" uv="1">

</role>

Meldungen an die/den IT-Sicherheitsbeauftragten bei sicherheitsrelevanten Ereignissen.

</item>

</itemize>

</paragraph>

-<paragraph uid="270" uv="1" version="2.1.000">

-<title uid="271" uv="1">

<name>Applikations-/Projektverantwortliche</name>

</title>

<abstract uid="272" uv="1">Für jede IT-Anwendung und jedes IT-Projekt ist die fachliche Gesamtverantwortung und damit auch die Verantwortung für deren Sicherheit klar festzulegen.</abstract>

<detailed uid="273" uv="1">Zu den Aufgaben einer/eines Applikations- oder Projektverantwortlichen zählen insbesondere</detailed>

-<itemize uid="274" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="275" uv="1">

</role>

die Festlegung der Sicherheits- und Qualitätsanforderungen der Applikation bzw. des Projektes,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="276" uv="1">

</role>

die Klassifizierung der verarbeiteten Daten,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="277" uv="1">

</role>

die Vergabe von Zugriffsrechten sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="278" uv="1">

</role>

organisatorische und administrative Maßnahmen zur Gewährleistung der IT-Sicherheit in der Projektentwicklung und im laufenden Betrieb.

</item>

</itemize>

<detailed uid="279" uv="1">Neben den oben beschriebenen Rollen gibt es im Bereich der Bundesverwaltung eine spezielle, per Gesetz festgelegte Rolle - die/den Informationssicherheitsbeauftragte/n. </detailed>

</paragraph>

-<paragraph uid="280" uv="1" version="2.3.001">

-<title uid="281" uv="1">

<name>Die/der Informationssicherheitsbeauftragte </name>

</title>

-<abstract uid="282" uv="1">

Auf Ressortebene sind gemäß

-<link uid="283" uv="1">

-<law>

<name>Informationssicherheitsgesetz</name>

<shortname>InfoSiG</shortname>

<source>#SECTION A.2</source>

</law>

</link>

Informationssicherheitsbeauftragte zu bestellen.

</abstract>

<detailed uid="284" uv="1">Aufgaben der/des Informationssicherheitsbeauftragten sind:</detailed>

-<itemize uid="285" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="286" uv="1">

</role>

die Überwachung der Einhaltung der Bestimmungen des

-<link uid="287" uv="1">

-<law>

<name>Informationssicherheitsgesetzes</name>

<shortname>InfoSiG</shortname>

<source>#SECTION A.2</source>

</law>

</link>

, der

-<link uid="288" uv="1">

-<law>

<name>Informationssicherheitsverordnung</name>

<shortname>InfoSiV</shortname>

<source>#SECTION A.2</source>

</law>

</link>

und der sonstigen Informationssicherheitsvorschriften,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="289" uv="1">

</role>

die periodische Überprüfung der Sicherheitsvorkehrungen für den Schutz von (lt.

-<link uid="290" uv="1">

-<law>

<name/>

<shortname>InfoSiG</shortname>

<source>#SECTION A.2</source>

</law>

</link>

) klassifizierten Informationen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="291" uv="1">

</role>

die Berichterstattung darüber an die Informationssicherheitskommission,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="292" uv="1">

</role>

Behebung von erkannten Mängeln,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="293" uv="1">

</role>

Sicherheitsüberprüfung von betroffenen Personen gemäß §3 Abs. 1 Z1 und 2

-<link uid="294" uv="1">

-<law>

<name/>

<shortname>InfoSiG</shortname>

<source>#SECTION A.2</source>

</law>

</link>

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="295" uv="1">

</role>

Information der Bundesministerin bzw. des Bundesministers des jeweiligen Ministeriums in Angelegenheiten der Informationssicherheit sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="296" uv="1">

</role>

Erstattung von Verbesserungsvorschlägen, falls erforderlich.

</item>

</itemize>

<detailed uid="297" uv="1">Die/der Informationssicherheitsbeauftragte ist Mitglied der Informationssicherheitskommission.</detailed>

</paragraph>

-<paragraph uid="298" uv="1" version="2.3.001">

-<title uid="299" uv="1">

<name>Weitere Pflichten und Verantwortungen im Bereich Informationssicherheit</name>

</title>

<abstract uid="300" uv="1">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.</abstract>

<detailed uid="301" uv="1">Im Rahmen der organisationsweiten Informationssicherheitspolitik sind daher auch die Aufgaben und Verantwortlichkeiten folgender Personenkreise zu definieren:</detailed>

-<itemize uid="302" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="303" uv="1">

</role>

Management/Behördenleitung ("Sicherheit als Managementaufgabe")

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="304" uv="1">

</role>

DV-Entwicklung und technischer Support

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="305" uv="1">

</role>

Dienstnehmer

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="306" uv="1">

</role>

Leasingpersonal, externe Mitarbeiter/innen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="307" uv="1">

</role>

Lieferanten und Vertragspartner

</item>

</itemize>

</paragraph>

-<paragraph uid="308" uv="1" version="2.3.001">

-<title uid="309" uv="1">

<name>Informationssicherheit und Datenschutz </name>

</title>

-<abstract uid="310" uv="1">

Auch wenn die Einrichtung einer/eines Datenschutzbeauftragten gesetzlich nicht gefordert ist (vgl.

-<link uid="311" uv="1">

-<law>

<name>Datenschutzgesetz</name>

<source>#SECTION A.2</source>

</law>

</link>

), 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.

</abstract>

</paragraph>

</subsection>

-<subsection uid="313" uv="1" version="2.3.001">

-<title uid="314" uv="1">

<name>Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken</name>

</title>

-<role uid="315" uv="1">

</role>

<abstract uid="316" uv="1">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.</abstract>

<detailed uid="317" uv="1">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.</detailed>

-<detailed uid="318" uv="1">

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

-<link uid="319" uv="1">

-<intern>

<name>Risikoanalyse</name>

<source>#CHAPTER 4</source>

</intern>

</link>

enthalten.

</detailed>

-<paragraph uid="320" uv="1" version="2.3.001">

-<title uid="321" uv="1">

<name>Schritt 1: Festlegung der anzuwendenden Risikoanalysestrategie </name>

</title>

<detailed uid="322" uv="1">Die heute gängige Praxis unterscheidet drei Varianten zur Risikoanalysestrategie einer Organisation: </detailed>

-<itemize uid="323" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="324" uv="1">

</role>

<emphasize level="2">Grundschutzansatz:</emphasize>

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.

</item>

</itemize>

-<itemize uid="325" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="326" uv="1">

</role>

<emphasize level="2">Detaillierte Risikoanalyse:</emphasize>

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.

</item>

</itemize>

-<itemize uid="327" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="328" uv="1">

</role>

<emphasize level="2">Kombinierter Ansatz:</emphasize>

In einem ersten Schritt wird in einer Schutzbedarfsfeststellung (

<emphasize level="0">High Level Risk Analysis</emphasize>

) 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.

</item>

</itemize>

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

</paragraph>

-<paragraph uid="329" uv="1" version="2.3.001">

-<title uid="330" uv="1">

<name>Schritt 2: Festlegung des akzeptablen Restrisikos</name>

</title>

<detailed uid="331" uv="1">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.</detailed>

</paragraph>

-<paragraph uid="332" uv="1" version="2.3.001">

-<title uid="333" uv="1">

<name>Schritt 3: Festlegung der Vorgehensweise zur Akzeptanz von außergewöhnlichen Restrisiken</name>

</title>

<detailed uid="334" uv="1">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.</detailed>

<detailed uid="335" uv="1">In der Sicherheitspolitik sind</detailed>

-<itemize uid="336" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="337" uv="1">

</role>

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

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="338" uv="1">

</role>

die Verantwortlichkeiten dafür

</item>

</itemize>

<detailed uid="339" uv="1">festzulegen.</detailed>

</paragraph>

</subsection>

-<subsection uid="340" uv="1" version="2.3.001">

-<title uid="341" uv="1">

<name>Klassifizierung von Informationen</name>

</title>

-<role uid="342" uv="1">

</role>

<abstract uid="343" uv="1">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.</abstract>

<detailed uid="344" uv="1">Daher sind in der Informationssicherheitspolitik entsprechende Sicherheitsklassen zu definieren und weiters die Verantwortlichkeiten für die Durchführung der Klassifizierung festzulegen.</detailed>

-<subsubsection uid="345" uv="1" version="2.1.00">

-<title uid="346" uv="1">

<name>Definition der Sicherheitsklassen</name>

</title>

-<role uid="347" uv="1">

</role>

-<paragraph uid="348" uv="1" version="2.3.002">

-<title uid="349" uv="1">

<name>A) Festlegung von Klassifizierungsstufen bzgl. Vertraulichkeit (Vertraulichkeitsklassen)</name>

</title>

<abstract uid="350" uv="1">Die Vertraulichkeitsklassen können als Maß dafür gesehen werden, welche Auswirkungen ein Missbrauch der Information auf die Institution haben kann. </abstract>

-<detailed uid="353" uv="1">

Im Bereich der Bundesverwaltung sind die unten angeführten hierarchischen Klassen definiert. Diese Klassen sind lt.

-<link uid="354" uv="1">

-<law>

<name>Informationssicherheitsgesetz</name>

<shortname>InfoSiG</shortname>

<source>#SECTION A.2</source>

</law>

</link>

gesetzlich festgelegt für "klassifizierte Informationen, die Österreich im Einklang mit völkerrechtlichen Regelungen erhalten hat".

</detailed>

<detailed> 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. </detailed>

-<itemize uid="355" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="356" uv="1">

</role>

<emphasize level="2">EINGESCHRÄNKT:</emphasize>

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). ...]

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="357" uv="1">

</role>

<emphasize level="2">VERTRAULICH:</emphasize>

Die Informationen stehen nach anderen Bundesgesetzen unter strafrechtlichem Geheimhaltungsschutz und ihre Geheimhaltung ist im öffentlichen Interesse gelegen.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="358" uv="1">

</role>

<emphasize level="2">GEHEIM:</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="359" uv="1">

</role>

<emphasize level="2">STRENG GEHEIM:</emphasize>

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.

</item>

</itemize>

<detailed uid="360" uv="1">Nicht-klassifizierte Informationen werden nachfolgend auch als "OFFEN" bezeichnet.</detailed>

<detailed uid="2024" uv="1">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.</detailed>

<detailed uid="361" uv="1">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. </detailed>

</paragraph>

-<paragraph uid="362" uv="1" version="2.1.000">

-<title uid="363" uv="1">

<name>B) Klassifizierung von Daten in Bezug auf Datenschutz</name>

</title>

-<abstract uid="364" uv="1">

Werden personenbezogene Daten verarbeitet, so sind die Daten auch dahingehend zu klassifizieren. Die nachfolgende Klassifizierung gemäß

-<link uid="365" uv="1">

-<law>

<name>Datenschutzgesetz</name>

<source>#SECTION A.2</source>

</law>

</link>

gilt sowohl für den Behörden- als auch für den privatwirtschaftlichen Bereich.

</abstract>

-<itemize uid="366" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="367" uv="1">

</role>

<emphasize level="2">NUR INDIREKT PERSONENBEZOGEN:</emphasize>

Der Personenbezug der Daten kann mit rechtlich zulässigen Mitteln nicht bestimmt werden.

</item>

</itemize>

-<itemize uid="368" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="369" uv="1">

</role>

<emphasize level="2">PERSONENBEZOGEN:</emphasize>

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.

</item>

</itemize>

-<itemize uid="370" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="371" uv="1">

</role>

<emphasize level="2">SENSIBEL:</emphasize>

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

</item>

</itemize>

</paragraph>

</subsubsection>

-<subsubsection uid="372" uv="1" version="2.3.001">

-<title uid="373" uv="1">

<name>Festlegung der Verantwortlichkeiten und der Vorgehensweise</name>

</title>

-<role uid="374" uv="1">

</role>

<abstract uid="375" uv="1">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. </abstract>

<detailed uid="376" uv="1">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.</detailed>

<detailed uid="378" uv="1">Weiters ist festzulegen, in welcher Form die Klassifizierung bzw. Deklassifizierung erfolgt und wie klassifizierte Information gekennzeichnet wird.</detailed>

<detailed uid="2025" uv="1">Die/der für die Information verantwortliche Mitarbeiter/in wird oft als "Dateneigner" oder "Data Owner" bezeichnet.</detailed>

</subsubsection>

-<subsubsection uid="379" uv="1" version="2.3.001">

-<title uid="380" uv="1">

<name>Erarbeitung von Regelungen zum Umgang mit klassifizierten Informationen </name>

</title>

-<role uid="381" uv="1">

</role>

<abstract uid="382" uv="1">In diesem Schritt ist festzulegen, wie die Information in Abhängigkeit von den Sicherheitsklassen zu behandeln ist. </abstract>

<detailed uid="383" uv="1">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:</detailed>

-<itemize uid="384" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="385" uv="1">

</role>

Kennzeichnung klassifizierter Information (sowohl elektronischer als auch nicht-elektronischer)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="386" uv="1">

</role>

Verwahrung klassifizierter Information (Zugriffsberechtigungen, etwaige Vorschriften zur Verschlüsselung)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="387" uv="1">

</role>

Übermittlung klassifizierter Information (mündliche Weitergabe, persönliche Weitergabe, Versendung durch Post oder Kurier, elektronische Übertragung, über welche Verbindungen, Vorschriften zur Verschlüsselung)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2026" uv="1">

</role>

Registrierung klassifizierter Information

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="388" uv="1">

</role>

Ausdruck klassifizierter Information (auf welchen Drucker, durch wen)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="389" uv="1">

</role>

Backup (Klartext, chiffriert, Schutz der Backup-Medien)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="390" uv="1">

</role>

Aufbewahrung / Wiederverwendung / Vernichtung von Datenträgern mit klassifizierter Information

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="391" uv="1">

</role>

Weitergabe klassifizierter Information (an wen, durch wen, unter welchen Bedingungen)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="392" uv="1">

</role>

Deklassifizierung klassifizierter Information (wann, durch wen)

</item>

</itemize>

<detailed uid="2027" uv="1">Näheres zum Umgang mit klassifizierten Informationen siehe Kapitel 8.</detailed>

</subsubsection>

</subsection>

-<subsection uid="393" uv="1" version="2.3.001">

-<title uid="394" uv="1">

<name>Klassifizierung von IT-Anwendungen und IT-Systemen, Grundzüge der Business Continuity Planung</name>

</title>

-<role uid="395" uv="1">

</role>

<abstract uid="396" uv="1">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").</abstract>

<abstract uid="397" uv="1">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).</abstract>

<abstract uid="398" uv="1">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.</abstract>

-<detailed uid="399" uv="1">

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

-<link uid="400" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

</detailed>

-<itemize uid="401" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="402" uv="1">

</role>

-<emphasize level="2">

<emphasize level="1">Betriebsverfügbarkeitskategorie 1 – Keine Vorsorge (unkritisch):</emphasize>

</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="403" uv="1">

</role>

-<emphasize level="2">

<emphasize level="1">Betriebsverfügbarkeitskategorie 2 – Offline Sicherung:</emphasize>

</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="404" uv="1">

</role>

-<emphasize level="2">

<emphasize level="1">Betriebsverfügbarkeitskategorie 3 – Redundante Infrastruktur:</emphasize>

</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="405" uv="1">

</role>

-<emphasize level="2">

<emphasize level="1">Betriebsverfügbarkeitskategorie 4 – Redundante Standorte:</emphasize>

</emphasize>

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.

</item>

</itemize>

<detailed uid="406" uv="1">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:</detailed>

-<itemize uid="407" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="408" uv="1">

</role>

-<emphasize level="2">

<emphasize level="1">K-Fall sicher (K2 bis K4):</emphasize>

</emphasize>

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.

</item>

</itemize>

<detailed uid="409" uv="1">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.</detailed>

-<detailed uid="410" uv="1">

Für nähere Informationen und für Klassifizierungsbeispiele siehe

-<link uid="411" uv="1">

-<otherlink>

<name>Abschnitt 7.2 im 2.Teil des vorliegenden Handbuches</name>

<source>OE-SIHA_II.html#SECTION 7.2</source>

</otherlink>

</link>

</detailed>

</subsection>

-<subsection uid="412" uv="1" version="2.3.001">

-<title uid="413" uv="1">

<name>Überprüfung und Aufrechterhaltung der Sicherheit</name>

</title>

-<role uid="414" uv="1">

</role>

<abstract uid="415" uv="1">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.</abstract>

<detailed uid="416" uv="1">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.</detailed>

</subsection>

-<subsection uid="2027" uv="1" version="2.3.000">

-<title uid="2028" uv="1">

<name>Dokumente zur Informationssicherheit</name>

</title>

-<role uid="2029" uv="1">

</role>

<abstract uid="2030" uv="1">Abschließend sollte ein Verweis auf die wichtigsten Dokumente zum Informationssicherheitsmanagement (Sicherheitsrichtlinien, Informationen über spezielle Sicherheitsmaßnahmen oder -systeme, organisatorische Regelungen …) gegeben werden.</abstract>

</subsection>

</section>

-<section uid="434" uv="1" version="2.3.001">

-<title uid="435" uv="1">

<name>Life Cycle der Informationssicherheitspolitik</name>

</title>

-<role uid="436" uv="1">

</role>

-<subsection uid="437" uv="1" version="2.3.001">

-<title uid="438" uv="1">

<name>Erstellung</name>

</title>

-<role uid="439" uv="1">

</role>

<abstract uid="440" uv="1">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.</abstract>

<detailed uid="441" uv="1">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.</detailed>

<detailed uid="442" uv="1">Weiters sollen Vertreter/innen folgender Bereiche an der Erstellung der organisationsweiten Informationssicherheitspolitik mitarbeiten bzw. in den Abstimmungsprozess miteinbezogen werden:</detailed>

-<itemize uid="443" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="444" uv="1">

</role>

IT-Abteilung

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="445" uv="1">

</role>

Anwender/innen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="446" uv="1">

</role>

Bereichs-IT-Sicherheitsbeauftragte

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="447" uv="1">

</role>

Personalabteilung

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="448" uv="1">

</role>

Gebäudeverwaltung und Infrastruktur

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="449" uv="1">

</role>

Revision

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="450" uv="1">

</role>

Budgetabteilung

</item>

</itemize>

<detailed uid="451" uv="1">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. </detailed>

<detailed uid="452" uv="1">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, ...)</detailed>

</subsection>

-<subsection uid="453" uv="1" version="2.3.001">

-<title uid="454" uv="1">

<name>Offizielle Inkraftsetzung</name>

</title>

-<role uid="455" uv="1">

</role>

<abstract uid="456" uv="1">Die Informationssicherheitspolitik wird von der Leitung der Organisation offiziell verabschiedet und in Kraft gesetzt. </abstract>

<detailed uid="457" uv="1">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.</detailed>

</subsection>

-<subsection uid="458" uv="1" version="2.1.000">

-<title uid="459" uv="1">

<name>Regelmäßige Überarbeitung</name>

</title>

-<role uid="460" uv="1">

</role>

<abstract uid="461" uv="1">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.</abstract>

<detailed uid="462" uv="1">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. </detailed>

<detailed uid="463" uv="1">Die Verantwortung dafür ist dezidiert festzulegen. Im Allgemeinen wird sie bei der für die IT-Sicherheit beauftragten Person liegen.</detailed>

</subsection>

</section>

</chapter>

-<chapter uid="464" uv="1" version="2.3.001">

-<title uid="465" uv="1">

<name>Risikoanalyse</name>

</title>

<abstract uid="466" uv="1">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.</abstract>

<detailed uid="467" uv="1">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. </detailed>

-<section uid="468" uv="1" version="2.3.001">

-<title uid="469" uv="1">

<name>Risikoanalysestrategien</name>

</title>

-<role uid="470" uv="1">

</role>

<abstract uid="471" uv="1">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.</abstract>

<detailed uid="472" uv="1">Mögliche Risikoanalysestrategien sind:</detailed>

-<itemize uid="473" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="474" uv="1">

</role>

<emphasize level="2">Detaillierte Risikoanalyse:</emphasize>

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.

</item>

</itemize>

-<itemize uid="475" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="476" uv="1">

</role>

<emphasize level="2">Grundschutzansatz:</emphasize>

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 (

<emphasize level="0">Baseline Security Controls</emphasize>

) 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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="477" uv="1">

</role>

<emphasize level="2">Kombinierter Ansatz:</emphasize>

In einem ersten Schritt wird in einer Schutzbedarfsfeststellung (

<emphasize level="0">High Level Risk Analysis</emphasize>

) 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.

</item>

</itemize>

<detailed uid="478" uv="1">Im Folgenden werden die drei angeführten Risikoanalysestrategien näher erläutert.</detailed>

</section>

-<section uid="479" uv="1" version="2.3.001">

-<title uid="480" uv="1">

<name>Detaillierte Risikoanalyse</name>

</title>

-<role uid="481" uv="1">

</role>

<abstract uid="482" uv="1">Eine detaillierte Risikoanalyse für ein IT-System umfasst die Identifikation der bestehenden Risiken sowie eine Abschätzung ihrer Größe.</abstract>

<detailed uid="2031" uv="1">Dazu werden die Werte (Assets), Bedrohungen und Schwachstellen identifiziert und die daraus resultierenden Risiken ermittelt.</detailed>

<detailed uid="483" uv="1">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.</detailed>

<detailed uid="487" uv="1">Eine detaillierte Risikoanalyse umfasst folgende Schritte:</detailed>

-<paragraph uid="488" uv="1" version="2.3.001">

-<title uid="489" uv="1">

<name>Schritt 1: </name>

</title>

<abstract uid="490" uv="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.</abstract>

</paragraph>

-<paragraph uid="491" uv="1" version="2.1.000">

-<title uid="492" uv="1">

<name>Schritt 2: </name>

</title>

<abstract uid="493" uv="1">Ziel dieses Schrittes ist die Erfassung aller bedrohten Objekte, die innerhalb des im vorangegangenen Schritt festgesetzten Analysebereiches liegen.</abstract>

</paragraph>

-<paragraph uid="494" uv="1" version="2.3.001">

-<title uid="495" uv="1">

<name>Schritt 3: </name>

</title>

<abstract uid="496" uv="1">In diesem Schritt wird der Wert der bedrohten Objekte ermittelt.</abstract>

<detailed uid="497" uv="1">Die Wertanalyse umfasst im Einzelnen:</detailed>

-<itemize uid="498" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="499" uv="1">

</role>

die Festlegung der Bewertungsbasis für Sachwerte

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="500" uv="1">

</role>

die Festlegung der Bewertungsbasis für immaterielle Werte

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="501" uv="1">

</role>

die Ermittlung der Abhängigkeiten zwischen den Objekten

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="502" uv="1">

</role>

die Bewertung der bedrohten Objekte und der möglichen Schäden (Impact Analyse)

</item>

</itemize>

</paragraph>

-<paragraph uid="503" uv="1" version="2.1.000">

-<title uid="504" uv="1">

<name>Schritt 4: </name>

</title>

<abstract uid="505" uv="1">Die Objekte sind vielfachen Bedrohungen ausgesetzt, die sowohl aus Nachlässigkeit und Versehen als auch aus Absicht resultieren können.</abstract>

<detailed uid="506" uv="1">Die Bedrohungsanalyse umfasst:</detailed>

-<itemize uid="507" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="508" uv="1">

</role>

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

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="509" uv="1">

</role>

die Ermittlung der Eintrittswahrscheinlichkeiten

</item>

</itemize>

</paragraph>

-<paragraph uid="510" uv="1" version="2.1.000">

-<title uid="511" uv="1">

<name>Schritt 5: </name>

</title>

<abstract uid="512" uv="1">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.</abstract>

<detailed uid="513" uv="1">Zu untersuchen sind dabei insbesondere die Bereiche Organisation, Hard- und Software, Personal sowie Infrastruktur.</detailed>

</paragraph>

-<paragraph uid="514" uv="1" version="2.1.000">

-<title uid="515" uv="1">

<name>Schritt 6: </name>

</title>

<abstract uid="516" uv="1">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.</abstract>

<detailed uid="517" uv="1">Geplante neue Sicherheitsmaßnahmen müssen mit den existierenden kompatibel sein und eine wirtschaftlich und technisch sinnvolle Ergänzung darstellen.</detailed>

</paragraph>

-<paragraph uid="518" uv="1" version="2.1.000">

-<title uid="519" uv="1">

<name>Schritt 7: </name>

</title>

<abstract uid="520" uv="1">In diesem Schritt werden die Einzelrisiken und das Gesamtrisiko ermittelt und bewertet.</abstract>

</paragraph>

-<paragraph uid="521" uv="1" version="2.1.000">

-<title uid="522" uv="1">

<name>Schritt 8:</name>

</title>

<abstract uid="523" uv="1">Eine Auswertung und Aufbereitung des Ergebnisses schließt die Risikoanalyse ab. </abstract>

</paragraph>

<detailed uid="527" uv="1">Bei der Durchführung einer Risikoanalyse sind folgende Prinzipien zu beachten:</detailed>

-<itemize uid="528" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="529" uv="1">

</role>

Das gesamte Verfahren muss transparent gemacht werden.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="530" uv="1">

</role>

Es dürfen keine versteckten Annahmen gemacht werden, die z.B. dazu führen, dass Bedrohungen unbetrachtet bleiben.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="531" uv="1">

</role>

Alle Bewertungen müssen begründet werden, um subjektive Einflüsse zu erkennen und so weit wie möglich zu vermeiden.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="532" uv="1">

</role>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="533" uv="1">

</role>

Der Aufwand für die Durchführung des Verfahrens sollte dem Wert der IT-Anwendungen und den Werten der Institution im Allgemeinen angemessen sein.

</item>

</itemize>

<detailed uid="534" uv="1">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. </detailed>

-<subsection uid="535" uv="1" version="2.1.000">

-<title uid="536" uv="1">

<name>Abgrenzung des Analysebereiches</name>

</title>

-<role uid="537" uv="1">

</role>

<abstract uid="538" uv="1">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.</abstract>

</subsection>

-<subsection uid="539" uv="1" version="2.3.001">

-<title uid="540" uv="1">

<name>Identifikation der bedrohten Objekte (Werte, assets)</name>

</title>

-<role uid="541" uv="1">

</role>

-<abstract uid="542" uv="1">

In diesem Schritt sind alle bedrohten Objekte (

<emphasize level="0">assets</emphasize>

), die innerhalb des festgestellten Analysebereiches liegen, zu erfassen.

</abstract>

<detailed uid="543" uv="1">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:</detailed>

-<itemize uid="544" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="545" uv="1">

</role>

<emphasize level="2">physische Objekte:</emphasize>

beispielsweise Gebäude, Infrastruktur, Hardware, Datenträger, Paperware

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="546" uv="1">

</role>

<emphasize level="2">logische Objekte:</emphasize>

beispielsweise Software, Daten, Information

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="547" uv="1">

</role>

Personen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="548" uv="1">

</role>

<emphasize level="2">Fähigkeiten:</emphasize>

etwa Herstellen eines Produktes oder Erbringen einer Dienstleistung

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="549" uv="1">

</role>

<emphasize level="2">immaterielle Güter:</emphasize>

beispielsweise Image, Vertrauen in die Institution oder gute Beziehungen zu anderen Organisationen

</item>

</itemize>

<detailed uid="550" uv="1">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. </detailed>

<detailed uid="551" uv="1">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. </detailed>

</subsection>

-<subsection uid="552" uv="1" version="2.3.001">

-<title uid="553" uv="1">

<name>Wertanalyse (Impact Analyse)</name>

</title>

-<role uid="554" uv="1">

</role>

<abstract uid="555" uv="1">In diesem Schritt wird der Wert der im vorangegangenen Schritt identifizierten Objekte ermittelt.</abstract>

<detailed uid="556" uv="1">Die Wertanalyse umfasst im Einzelnen:</detailed>

-<itemize uid="557" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="558" uv="1">

</role>

die Festlegung der Bewertungsbasis für Sachwerte

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="559" uv="1">

</role>

die Festlegung der Bewertungsbasis für immaterielle Werte

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="560" uv="1">

</role>

die Ermittlung der Abhängigkeiten zwischen den Objekten

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="561" uv="1">

</role>

die Bewertung der bedrohten Objekte und der möglichen Schäden

</item>

</itemize>

-<subsubsection uid="562" uv="1" version="2.1.000">

-<title uid="563" uv="1">

<name>Festlegung der Bewertungsbasis für Sachwerte</name>

</title>

-<role uid="564" uv="1">

</role>

<abstract uid="565" uv="1">Zunächst ist zu entscheiden, ob die Bewertung quantitativ oder qualitativ erfolgen soll.</abstract>

<detailed uid="566" uv="1">Eine quantitative Bewertung kann etwa beruhen auf </detailed>

-<itemize uid="567" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="568" uv="1">

</role>

dem Zeitwert eines Objektes,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="569" uv="1">

</role>

dem Wiederbeschaffungswert eines Objektes,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="570" uv="1">

</role>

dem Wert, den das Objekt für eine/n potentielle/n Angreifer/in hätte, oder

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="571" uv="1">

</role>

dem Schaden, der sich aus dem Verlust oder der Modifikation eines zu schützenden Objektes für die betroffene Organisation ergibt.

</item>

</itemize>

<detailed uid="572" uv="1">Eine qualitative Bewertung erfolgt durch Einteilung in Klassen. Beispiele hierfür sind etwa:</detailed>

-<itemize uid="573" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="574" uv="1">

</role>

3-stufige Bewertung: gering - mittel - hoch

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="575" uv="1">

</role>

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

</item>

</itemize>

<detailed uid="576" uv="1">Als Basis für eine qualitative Bewertung ist festzulegen, was die einzelnen Klassen bedeuten bzw. wie sie definiert sind.</detailed>

</subsubsection>

-<subsubsection uid="577" uv="1" version="2.3.001">

-<title uid="578" uv="1">

<name>Festlegung der Bewertungsbasis für immaterielle Werte</name>

</title>

-<role uid="579" uv="1">

</role>

<abstract uid="580" uv="1">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.</abstract>

<detailed uid="581" uv="1">Eine quantitative Bewertung kann in diesem Fall beruhen auf </detailed>

-<itemize uid="582" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="583" uv="1">

</role>

dem Wert, den das Objekt für einen potentiellen Angreifer hätte (z.B. vertrauliche Information), oder

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="584" uv="1">

</role>

dem Schaden, der sich aus einem Angriff auf das zu schützende Objekt für die betroffene Organisation ergibt.

</item>

</itemize>

<detailed uid="585" uv="1">Es ist zu beachten, dass die potentiellen Schäden den eigentlichen (Zeit- oder Wiederbeschaffungs-)Wert beträchtlich übersteigen können. </detailed>

</subsubsection>

-<subsubsection uid="586" uv="1" version="2.1.000">

-<title uid="587" uv="1">

<name>Ermittlung der Abhängigkeiten zwischen den Objekten</name>

</title>

-<role uid="588" uv="1">

</role>

<abstract uid="589" uv="1">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. </abstract>

<detailed uid="590" uv="1">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. </detailed>

</subsubsection>

-<subsubsection uid="591" uv="1" version="2.1.000">

-<title uid="592" uv="1">

<name>Bewertung der bedrohten Objekte</name>

</title>

-<role uid="593" uv="1">

</role>

<abstract uid="594" uv="1">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.</abstract>

<detailed uid="595" uv="1">Durchführung:</detailed>

-<itemize uid="596" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="597" uv="1">

</role>

Die Person, die die Risikoanalyse durchführt, erstellt eine Liste der zu bewertenden Objekte und gibt die Bewertungsbasen vor.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="598" uv="1">

</role>

Die Bewertung sollte durch die Applikations-/Projektverantwortlichen sowie die betroffenen Benutzer/innen vorgenommen werden.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="599" uv="1">

</role>

Unterstützung in der Bewertung kann von verschiedenen Abteilungen, etwa Finanzen, Einkauf, IT, ... kommen.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="600" uv="1">

</role>

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.

</item>

</itemize>

-<paragraph uid="601" uv="1" version="2.1.000">

-<title uid="602" uv="1">

<name>Ergebnis der Wertanalyse: </name>

</title>

<abstract uid="603" uv="1">Aufstellung der bedrohten Objekte und ihres Wertes für die Organisation.</abstract>

</paragraph>

</subsubsection>

</subsection>

-<subsection uid="604" uv="1" version="2.1.000">

-<title uid="605" uv="1">

<name>Bedrohungsanalyse</name>

</title>

-<role uid="606" uv="1">

</role>

-<abstract uid="607" uv="1">

Lt.

-<link uid="608" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

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".

</abstract>

<detailed uid="609" uv="1">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.</detailed>

<detailed uid="610" uv="1">Bedrohungen sind charakterisiert durch:</detailed>

-<itemize uid="611" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="612" uv="1">

</role>

<emphasize level="2">ihren Ursprung:</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="613" uv="1">

</role>

<emphasize level="2">die Motivation:</emphasize>

Motivation für (absichtliche) Bedrohungen können etwa finanzielle Gründe, Wettbewerbsvorteile, Rache, aber auch Geltungssucht oder erhoffte Publicity sein.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="614" uv="1">

</role>

die Häufigkeit des Auftretens,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="615" uv="1">

</role>

die Größe des Schadens, der durch diese Bedrohung verursacht werden kann.

</item>

</itemize>

<detailed uid="616" uv="1">Für einige umweltbedingte Bedrohungen (etwa Erdbeben, Blitzschlag, ...) liegen statistische Daten vor, die für die Einschätzung hilfreich sein können.</detailed>

<detailed uid="617" uv="1">Die Bedrohungsanalyse umfasst im Einzelnen:</detailed>

-<itemize uid="618" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="619" uv="1">

</role>

die Identifikation möglicher Bedrohungen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="620" uv="1">

</role>

die Ermittlung der Eintrittswahrscheinlichkeiten

</item>

</itemize>

-<subsubsection uid="621" uv="1" version="2.3.001">

-<title uid="622" uv="1">

<name>Identifikation möglicher Bedrohungen</name>

</title>

-<role uid="623" uv="1">

</role>

<detailed uid="624" uv="1">Bedrohungen können unterteilt werden in:</detailed>

-<itemize uid="625" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="626" uv="1">

</role>

<emphasize level="2">Höhere Gewalt</emphasize>

(etwa Blitzschlag, Feuer, Erdbeben, Personalausfall)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="627" uv="1">

</role>

<emphasize level="2">Organisatorische Mängel</emphasize>

(etwa fehlende oder unzureichende Regelungen für Wartung, Dokumentation, Test und Freigabe, fehlende Auswertung von Protokolldaten, mangelhafte Kennzeichnung von Datenträgern)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="628" uv="1">

</role>

<emphasize level="2">Menschliche Fehlhandlungen</emphasize>

(etwa fehlerhafte Systemnutzung oder -administration, fahrlässige Zerstörung von Geräten oder Daten, Nichtbeachtung von Sicherheitsmaßnahmen)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="629" uv="1">

</role>

<emphasize level="2">Technisches Versagen</emphasize>

(etwa Ausfall von Versorgungs- und Sicherheitseinrichtungen, Softwarefehler, defekte Datenträger)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="630" uv="1">

</role>

<emphasize level="2">Vorsätzliche Handlungen</emphasize>

(etwa Manipulation/Zerstörung von Geräten, Manipulation an Daten oder Software, Viren, trojanische Pferde, Abhören, Wiedereinspielen von Nachrichten, Nichtanerkennen einer Nachricht, Maskerade)

</item>

</itemize>

<detailed uid="631" uv="1">Es ist wichtig, alle wesentlichen Bedrohungen zu erfassen, da andernfalls Sicherheitslücken bestehen bleiben können. </detailed>

-<detailed uid="632" uv="1">

Bei der Identifikation von möglichen Bedrohungen können Bedrohungskataloge hilfreich sein, die den Charakter von Checklisten haben. Solche Kataloge finden sich etwa in

-<link uid="633" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

, S 207 ff und in

-<link uid="634" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

. 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.

</detailed>

</subsubsection>

-<subsubsection uid="635" uv="1" version="2.3.001">

-<title uid="636" uv="1">

<name>Ermittlung der Eintrittswahrscheinlichkeiten </name>

</title>

-<role uid="637" uv="1">

</role>

<abstract uid="638" uv="1">In diesem Schritt der Risikoanalyse ist zu bestimmen, mit welcher Wahrscheinlichkeit eine Bedrohung im betrachteten Umfeld eintreten wird.</abstract>

<detailed uid="639" uv="1">Diese ist abhängig von:</detailed>

-<itemize uid="640" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="641" uv="1">

</role>

der Häufigkeit der Bedrohung (Wahrscheinlichkeit des Auftretens anhand von Erfahrungen, Statistiken, ...),

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="642" uv="1">

</role>

der Motivation und den vorausgesetzten Fähigkeiten und Ressourcen einer/eines potentiellen Angreiferin/Angreifers,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="643" uv="1">

</role>

Einschätzung der Attraktivität und Verwundbarkeit des IT-Systems bzw. seiner Komponenten,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="644" uv="1">

</role>

Umweltfaktoren und organisationsspezifischen Einflüssen.

</item>

</itemize>

<detailed uid="645" uv="1">Auch die Eintrittswahrscheinlichkeit kann quantitativ oder qualitativ bewertet werden. </detailed>

<detailed uid="646" uv="1">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.</detailed>

<detailed uid="647" uv="1">Bewährt haben sich hier etwa drei- bis fünfteilige Skalen, wie beispielsweise:</detailed>

-<detailed uid="648" uv="1">

<emphasize level="2">4: sehr häufig</emphasize>

<emphasize level="2">3: häufig </emphasize>

<emphasize level="2">2: mittel </emphasize>

<emphasize level="2">1: selten </emphasize>

<emphasize level="2">0: sehr selten</emphasize>

</detailed>

<detailed uid="649" uv="1">Diese allgemeinen Bedeutungen der Skalenwerte sind für den spezifischen Anwendungsbereich zu konkretisieren. </detailed>

<detailed uid="650" uv="1">Beispiel:</detailed>

-<detailed uid="651" uv="1">

<emphasize level="2">4: einmal pro Minute </emphasize>

<emphasize level="2">3: einmal pro Stunde </emphasize>

<emphasize level="2">2: einmal pro Tag </emphasize>

<emphasize level="2">1: einmal pro Monat </emphasize>

<emphasize level="2">0: einmal im Jahr</emphasize>

</detailed>

-<paragraph uid="653" uv="1" version="2.1.000">

-<title uid="654" uv="1">

<name>Ergebnis der Bedrohungsanalyse:</name>

</title>

<abstract uid="655" uv="1">Liste von Bedrohungen, der von ihnen bedrohten Objekte, und ihrer Eintrittswahrscheinlichkeiten.</abstract>

</paragraph>

</subsubsection>

</subsection>

-<subsection uid="656" uv="1" version="2.1.000">

-<title uid="657" uv="1">

<name>Schwachstellenanalyse</name>

</title>

-<role uid="658" uv="1">

</role>

-<abstract uid="659" uv="1">

Unter einer Schwachstelle (

<emphasize level="0">vulnerability</emphasize>

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

</abstract>

<detailed uid="660" uv="1">Typische Beispiele für Schwachstellen sind etwa:</detailed>

-<itemize uid="661" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="662" uv="1">

</role>

Mangelnder baulicher Schutz von Räumen mit IT-Einrichtungen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="663" uv="1">

</role>

Nachlässige Handhabung von Zutrittskontrollen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="664" uv="1">

</role>

Spannungs- oder Temperaturschwankungen bei Hardwarekomponenten

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="665" uv="1">

</role>

kompromittierende Abstrahlung

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="666" uv="1">

</role>

Spezifikations- und Implementierungsfehler

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="667" uv="1">

</role>

schwache Passwortmechanismen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="668" uv="1">

</role>

unzureichende Ausbildung, mangelndes Sicherheitsbewusstsein

</item>

</itemize>

<detailed uid="669" uv="1">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.</detailed>

-<detailed uid="670" uv="1">

Eine

<emphasize level="0">Schwachstellenanalyse</emphasize>

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.

</detailed>

-<detailed uid="671" uv="1">

Beispielhafte Auflistungen von Schwachstellen, die auf typische Problembereiche hinweisen, finden sich etwa in

-<link uid="672" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

, Annex D sowie in

-<link uid="673" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

, S 199 ff.

</detailed>

-<paragraph uid="674" uv="1" version="2.1.000">

-<title uid="675" uv="1">

<name>Ergebnis der Schwachstellenanalyse:</name>

</title>

<abstract uid="676" uv="1">Liste von potentiellen Schwachstellen mit Angaben darüber, wie leicht diese für einen Angriff ausgenützt werden können.</abstract>

</paragraph>

</subsection>

-<subsection uid="677" uv="1" version="2.1.000">

-<title uid="678" uv="1">

<name>Identifikation bestehender Sicherheitsmaßnahmen</name>

</title>

-<role uid="679" uv="1">

</role>

<detailed uid="680" uv="1">Sicherheitsmaßnahmen sind Verfahrensweisen, Prozeduren und Mechanismen, die eine oder mehrere der nachfolgenden Funktionen erfüllen:</detailed>

-<itemize uid="681" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="682" uv="1">

</role>

Vermeidung von Risiken,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="683" uv="1">

</role>

Verkleinerung von Bedrohungen oder Schwachstellen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="684" uv="1">

</role>

Entdeckung unerwünschter Ereignisse,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="685" uv="1">

</role>

Eingrenzung der Auswirkungen eines unerwünschten Ereignisses,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="686" uv="1">

</role>

Überwälzung von Risiken oder

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="687" uv="1">

</role>

Wiederherstellung eines früheren Zustandes.

</item>

</itemize>

<detailed uid="688" uv="1">Wirksame IT-Sicherheit verlangt im Allgemeinen eine Kombination von verschiedenen Typen von Maßnahmen. </detailed>

<detailed uid="689" uv="1">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.</detailed>

<detailed uid="690" uv="1">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. </detailed>

<detailed uid="691" uv="1">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.</detailed>

-<paragraph uid="692" uv="1" version="2.1.000">

-<title uid="693" uv="1">

<name>Ergebnis:</name>

</title>

<abstract uid="694" uv="1">Aufstellung aller bereits existierenden oder geplanten Sicherheitsmaßnahmen mit Angaben über ihren Implementierungsstatus und ihren Einsatz.</abstract>

</paragraph>

</subsection>

-<subsection uid="695" uv="1" version="2.3.001">

-<title uid="696" uv="1">

<name>Risikobewertung</name>

</title>

-<role uid="697" uv="1">

</role>

<abstract uid="698" uv="1">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.</abstract>

<detailed uid="699" uv="1">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. </detailed>

<detailed uid="700" uv="1">Risiken sind eine Funktion folgender Parameter:</detailed>

-<itemize uid="701" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="702" uv="1">

</role>

Wert der bedrohten Objekte (Schadensausmaß),

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="703" uv="1">

</role>

Möglichkeit, eine Schwachstelle durch eine Bedrohung auszunutzen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="704" uv="1">

</role>

Eintrittswahrscheinlichkeit einer Bedrohung,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="705" uv="1">

</role>

bereits existierende oder geplante Sicherheitsmaßnahmen, die dieses Risiko reduzieren könnten.

</item>

</itemize>

<detailed uid="706" uv="1">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.</detailed>

-<detailed uid="707" uv="1">

-<link uid="708" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

gibt im Anhang vier Beispiele für Methoden zur Risikobewertung.

</detailed>

<detailed uid="711" uv="1">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.</detailed>

-<paragraph uid="712" uv="1" version="2.1.000">

-<title uid="713" uv="1">

<name>Ergebnis:</name>

</title>

<abstract uid="714" uv="1">Quantitative oder qualitative Bewertung von Einzelrisiken und Gesamtrisiko für den betrachteten Analysebereich.</abstract>

</paragraph>

</subsection>

-<subsection uid="715" uv="1" version="2.3.001">

-<title uid="716" uv="1">

<name>Auswertung und Aufbereitung der Ergebnisse</name>

</title>

-<role uid="717" uv="1">

</role>

<abstract uid="718" uv="1">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.</abstract>

</subsection>

</section>

-<section uid="719" uv="1" version="2.3.001">

-<title uid="720" uv="1">

<name>Grundschutzansatz</name>

</title>

-<role uid="721" uv="1">

</role>

-<abstract uid="722" uv="1">

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

-<link uid="724" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

, Kataloge zu Gefährdungen und Sicherheitsmaßnahmen in

-<link uid="725" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

bzw.

-<link uid="726" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

</abstract>

-<subsection uid="728" uv="1" version="2.3.001">

-<title uid="729" uv="1">

<name>Die Idee des IT-Grundschutzes</name>

</title>

-<role uid="730" uv="1">

</role>

<abstract uid="731" uv="1">Ziel des Grundschutzansatzes ist es, den Aufwand für die Erstellung eines Informationssicherheitskonzeptes angemessen zu begrenzen. </abstract>

<detailed uid="732" uv="1">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.</detailed>

<detailed uid="733" uv="1">Die Vorteile dieser Vorgehensweise sind:</detailed>

-<itemize uid="734" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="735" uv="1">

</role>

Der Aufwand für die Risikoanalyse wird stark reduziert.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="736" uv="1">

</role>

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

</item>

</itemize>

<detailed uid="737" uv="1">Zudem sind Grundschutzmaßnahmen meist stark verbreitet und damit relativ kostengünstig und schnell zu implementieren.</detailed>

<detailed uid="738" uv="1">Dem stehen folgende Nachteile gegenüber:</detailed>

-<itemize uid="739" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="740" uv="1">

</role>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="741" uv="1">

</role>

Aufgrund der fehlenden Risikoanalyse kann unter Umständen eine angemessene Reaktion auf sicherheitsrelevante Hard- oder Softwareänderungen schwierig sein.

</item>

</itemize>

<detailed uid="742" uv="1">Die Wahl eines Grundschutzansatzes wird daher in folgenden Fällen empfohlen:</detailed>

-<itemize uid="743" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="744" uv="1">

</role>

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

</item>

</itemize>

-<itemize uid="745" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="746" uv="1">

</role>

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.

</item>

</itemize>

-<itemize uid="747" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="748" uv="1">

</role>

<emphasize level="2">Als Teil eines umfassenden Risikoanalysekonzeptes ("kombinierter Ansatz"):</emphasize>

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

-<link uid="749" uv="1">

-<intern>

<name>Kombinierter Ansatz</name>

<source>#SECTION 4.4</source>

</intern>

</link>

</item>

</itemize>

</subsection>

-<subsection uid="750" uv="1" version="2.3.001">

-<title uid="751" uv="1">

<name>Grundschutzanalyse und Auswahl von Maßnahmen</name>

</title>

-<role uid="752" uv="1">

</role>

<abstract uid="753" uv="1">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.</abstract>

<detailed uid="754" uv="1">Eine Grundschutzanalyse besteht im Wesentlichen aus den folgenden beiden Teilschritten:</detailed>

<detailed uid="755" uv="1">Schritt 1: Nachbildung eines IT-Systems oder eines IT-Verbundes (Kombination mehrerer IT-Systeme) durch vorhandene Bausteine ("Modellierung")</detailed>

<detailed uid="756" uv="1">Schritt 2: Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen</detailed>

-<subsubsection uid="759" uv="1" version="2.3.001">

-<title uid="760" uv="1">

<name>Modellierung</name>

</title>

-<role uid="761" uv="1">

</role>

<abstract uid="762" uv="1">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. </abstract>

-<detailed uid="763" uv="1">

Eine der umfassendsten und ausgereiftesten Sammlungen von Bausteinen und Maßnahmen stellt das IT-Grundschutzhandbuch des BSI dar (

-<link uid="764" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

). Anhand dieses Werkes soll nachfolgend die Modellierung eines IT-Verbundes beschrieben werden.

</detailed>

<detailed uid="765" uv="1">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.</detailed>

<detailed uid="767" uv="1">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.</detailed>

<detailed uid="769" uv="1">Die Sicherheitsaspekte eines IT-Verbunds werden wie folgt den einzelnen Schichten zugeordnet:</detailed>

-<itemize uid="770" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="771" uv="1">

</role>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="772" uv="1">

</role>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="773" uv="1">

</role>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="774" uv="1">

</role>

Schicht 4 betrachtet die Kommunikations- und Vernetzungsaspekte der IT-Systeme, wie etwa die Bausteine Netz- und Systemmanagement und Firewalls.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="775" uv="1">

</role>

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.

</item>

</itemize>

<detailed uid="776" uv="1">Die in diesem Schritt zu leistende Aufgabe besteht darin, das reale IT-System durch die vorhandenen Bausteine möglichst genau nachzubilden. </detailed>

<detailed uid="777" uv="1">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. </detailed>

<detailed uid="778" uv="1">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. </detailed>

</subsubsection>

-<subsubsection uid="779" uv="1" version="2.1.000">

-<title uid="780" uv="1">

<name>Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen</name>

</title>

-<role uid="781" uv="1">

</role>

<abstract uid="782" uv="1">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. </abstract>

<detailed uid="783" uv="1">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.</detailed>

<detailed uid="784" uv="1">Der eigentliche Soll-Ist-Vergleich soll mittels Interviews und stichprobenartiger Kontrollen durchgeführt werden. </detailed>

-<paragraph uid="785" uv="1" version="2.1.000">

-<title uid="786" uv="1">

<name>Vorgehen bei Abweichungen</name>

</title>

<abstract uid="787" uv="1">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. </abstract>

<detailed uid="788" uv="1">An dieser Stelle sollten auch eventuell vorhandene über den IT-Grundschutz hinausgehende IT-Sicherheitsmaßnahmen herausgearbeitet und dokumentiert werden.</detailed>

</paragraph>

-<paragraph uid="789" uv="1" version="2.3.001">

-<title uid="790" uv="1">

<name>Dokumentation der Ergebnisse</name>

</title>

<detailed uid="791" uv="1">Zu jeder Maßnahme sollten </detailed>

-<itemize uid="792" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="793" uv="1">

</role>

der Umsetzungsgrad (ja/teilweise/nein/entbehrlich) sowie, soweit zu diesem Zeitpunkt bereits möglich,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="794" uv="1">

</role>

die Verantwortlichkeiten für die Umsetzung

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="795" uv="1">

</role>

der Zeitpunkt für die Umsetzung und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="796" uv="1">

</role>

eine Kostenschätzung

</item>

</itemize>

<detailed uid="797" uv="1">angegeben werden.</detailed>

<detailed uid="798" uv="1">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.</detailed>

</paragraph>

-<paragraph uid="799" uv="1" version="2.1.000">

-<title uid="800" uv="1">

<name>Ergebnis</name>

</title>

<abstract uid="801" uv="1">Die beschriebene Vorgehensweise liefert als Ergebnis eine Liste von Maßnahmen, die es für die Erreichung des IT-Grundschutzes noch umzusetzen gilt.</abstract>

</paragraph>

</subsubsection>

</subsection>

</section>

-<section uid="802" uv="1" version="2.3.001">

-<title uid="803" uv="1">

<name>Kombinierter Ansatz</name>

</title>

-<role uid="804" uv="1">

</role>

<abstract uid="805" uv="1">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.</abstract>

<detailed uid="806" uv="1">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".</detailed>

<detailed uid="807" uv="1">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.</detailed>

<detailed uid="809" uv="1">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.</detailed>

<detailed uid="2032" uv="1">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.</detailed>

-<paragraph uid="811" uv="1" version="2.1.000">

-<title uid="812" uv="1">

<name>Vorteile eines kombinierten Ansatzes</name>

</title>

-<itemize uid="813" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="814" uv="1">

</role>

Die Vorgehensweise ermöglicht es, rasch einen relativ guten Sicherheitslevel für alle IT-Systeme zu realisieren.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="815" uv="1">

</role>

Die in der Schutzbedarfsfeststellung erarbeiteten Erkenntnisse können die Grundlage für eine Prioritätenreihung für die nachfolgenden Aktivitäten bilden.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="816" uv="1">

</role>

Der Aufwand kann auf hochsicherheitsbedürftige Systeme konzentriert werden.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="817" uv="1">

</role>

Das Verfahren findet im Allgemeinen hohe Akzeptanz, da es mit verhältnismäßig geringem Initialaufwand rasch sichtbare Erfolge bringt.

</item>

</itemize>

</paragraph>

-<paragraph uid="819" uv="1" version="2.1.000">

-<title uid="820" uv="1">

<name>Empfehlung:</name>

</title>

<abstract uid="821" uv="1">Aus diesen Gründen wird empfohlen, als Risikoanalysestrategie einen kombinierten Ansatz zu wählen.</abstract>

</paragraph>

-<subsection uid="822" uv="1" version="2.3.001">

-<title uid="823" uv="1">

<name>Festlegung von Schutzbedarfskategorien</name>

</title>

-<role uid="824" uv="1">

</role>

<abstract uid="825" uv="1">Voraussetzung für eine Schutzbedarfsfeststellung ist die Festlegung von Schutzbedarfskategorien.</abstract>

<detailed uid="830" uv="1">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.</detailed>

<detailed uid="831" uv="1">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.</detailed>

-<table border="1" title="Beispiel für die Festlegung der Schutzbedarfskategorien" uid="832" uv="1">

-<header>

<td width="67">Schutzbedarfskategorie "niedrig bis mittel"</td>

<td width="67">Schutzbedarfskategorie "hoch bis sehr hoch"</td>

</header>

-<tr>

<td>1. Verstoß gegen Gesetze, Vorschriften oder Verträge</td>

-<td>

-<itemize uid="833" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="834" uv="1">

</role>

Verstöße gegen Vorschriften und Gesetze mit geringfügigen Konsequenzen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="835" uv="1">

</role>

Geringfügige Vertragsverletzungen mit geringen Konventionalstrafen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="836" uv="1">

</role>

Ein möglicher Missbrauch personenbezogener Daten hat nur geringfügige Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse der/des Betroffenen.

</item>

</itemize>

</td>

-<td>

-<itemize uid="837" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="838" uv="1">

</role>

Schwere Verstöße gegen Gesetze und Vorschriften (Strafverfolgung)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="839" uv="1">

</role>

Vertragsverletzungen mit hohen Konventionalstrafen oder Haftungsschäden

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="840" uv="1">

</role>

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)

</item>

</itemize>

</td>

</tr>

-<tr>

<td>2. Beeinträchtigung der persönlichen Unversehrtheit</td>

-<td>

-<itemize uid="841" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="842" uv="1">

</role>

Eine Beeinträchtigung erscheint nicht möglich.

</item>

</itemize>

</td>

-<td>

-<itemize uid="843" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="844" uv="1">

</role>

Eine über Bagatellverletzungen hinausgehende Beeinträchtigung der persönlichen Unversehrtheit kann nicht absolut ausgeschlossen werden.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>3. Beeinträchtigung der Aufgabenerfüllung</td>

-<td>

-<itemize uid="845" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="846" uv="1">

</role>

Es kann zu einer leichten bis maximal mittelschweren Beeinträchtigung der Aufgabenerfüllung kommen.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="847" uv="1">

</role>

Eine Zielerreichung ist mit vertretbarem Mehraufwand möglich.

</item>

</itemize>

</td>

-<td>

-<itemize uid="848" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="849" uv="1">

</role>

Es kann zu einer schweren Beeinträchtigung der Aufgabenerfüllung bis hin zur Handlungsunfähigkeit der betroffenen Organisation kommen.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="850" uv="1">

</role>

Bedeutende Zielabweichung in Qualität und/oder Quantität.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>4. Vertraulichkeit der verarbeiteten Information</td>

-<td>

-<itemize uid="851" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="852" uv="1">

</role>

Es werden nur Daten der Sicherheitsklassen OFFEN und EINGESCHRÄNKT verarbeitet bzw. gespeichert.

</item>

</itemize>

</td>

-<td>

-<itemize uid="853" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="854" uv="1">

</role>

Es werden auch Daten der Sicherheitsklassen VERTRAULICH, GEHEIM und/oder STRENG GEHEIM verarbeitet bzw. gespeichert.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>5. Dauer der Verzichtbarkeit</td>

-<td>

-<itemize uid="855" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="856" uv="1">

</role>

Die maximal tolerierbare Ausfallszeit der Anwendung beträgt mehrere Stunden bis mehrere Tage.

</item>

</itemize>

</td>

-<td>

-<itemize uid="857" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="858" uv="1">

</role>

Die maximal tolerierbare Ausfallszeit des Systems beträgt lediglich einige Minuten.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>6. Negative Außenwirkung</td>

-<td>

-<itemize uid="859" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="860" uv="1">

</role>

Eine geringe bzw. nur interne Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.

</item>

</itemize>

</td>

-<td>

-<itemize uid="861" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="862" uv="1">

</role>

Eine breite Beeinträchtigung des Vertrauens in die Organisation oder ihr Ansehen ist zu erwarten.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>7. Finanzielle Auswirkungen</td>

-<td>

-<itemize uid="863" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="864" uv="1">

</role>

Der finanzielle Schaden ist kleiner als (z.B.) Euro 50.000.--.

</item>

</itemize>

</td>

-<td>

-<itemize uid="865" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="866" uv="1">

</role>

Der zu erwartende finanzielle Schaden ist größer als (z.B.) Euro 50.000.--.

</item>

</itemize>

</td>

</tr>

</table>

<detailed uid="2033" uv="1">Eine andere Möglichkeit besteht darin, drei Schutzbedarfskategorien zu definieren:</detailed>

-<detailed uid="2034" uv="1">

<emphasize level="2">Schutzbedarfskategorie "normal":</emphasize>

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

</detailed>

-<detailed uid="2035" uv="1">

<emphasize level="2">Schutzbedarfskategorie "hoch":</emphasize>

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

</detailed>

-<detailed uid="2036" uv="1">

<emphasize level="2">Schutzbedarfskategorie "sehr hoch":</emphasize>

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.

</detailed>

-<detailed uid="2037" uv="1">

<emphasize level="2">Schutzbedarfskategorie "hoch":</emphasize>

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.

</detailed>

-<table border="1" title="Beispiel für die alternative Festlegung der Schutzbedarfskategorien" uid="2038" uv="1">

-<header>

<td width="45">Schutzbedarfskategorie "normal"</td>

<td width="45">Schutzbedarfskategorie "hoch"</td>

<td width="45">Schutzbedarfskategorie "sehr hoch"</td>

</header>

-<tr>

<td>1. Verstoß gegen Gesetze, Vorschriften oder Verträge</td>

-<td>

-<itemize uid="2039" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2040" uv="1">

</role>

Verstöße gegen Vorschriften und Gesetze mit geringfügigen Konsequenzen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2041" uv="1">

</role>

Geringfügige Vertragsverletzungen mit keinen oder geringen Konventionalstrafen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2042" uv="1">

</role>

Ein möglicher Missbrauch personenbezogener Daten hat nur geringfügige Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse der/des Betroffenen.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2043" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2044" uv="1">

</role>

Verstöße gegen Vorschriften und Gesetze mit erheblichen Konsequenzen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2045" uv="1">

</role>

Vertragsverletzungen mit hohen Konventionalstrafen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2046" uv="1">

</role>

Ein möglicher Missbrauch personenbezogener Daten hat erhebliche Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse der/des Betroffenen.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2047" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2048" uv="1">

</role>

Schwere Verstöße gegen Gesetze und Vorschriften (Strafverfolgung)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2049" uv="1">

</role>

Vertragsverletzungen, deren Haftungsschäden ruinös sind

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2050" uv="1">

</role>

Ein möglicher Missbrauch personenbezogener Daten würde für die/den Betroffene/n den gesellschaftlichen oder wirtschaftlichen Ruin bedeuten.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>2. Beeinträchtigung der persönlichen Unversehrtheit</td>

-<td>

-<itemize uid="2051" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2052" uv="1">

</role>

Eine Beeinträchtigung erscheint nicht möglich.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2053" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2054" uv="1">

</role>

Eine Beeinträchtigung der persönlichen Unversehrtheit kann nicht absolut ausgeschlossen werden.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2055" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2056" uv="1">

</role>

Gravierende Beeinträchtigungen der persönlichen Unversehrtheit sind möglich.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2057" uv="1">

</role>

Gefahr für Leib und Leben

</item>

</itemize>

</td>

</tr>

-<tr>

<td>3. Beeinträchtigung der Aufgabenerfüllung</td>

-<td>

-<itemize uid="2058" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2059" uv="1">

</role>

Es kann zu einer leichten bis maximal mittelschweren Beeinträchtigung der Aufgabenerfüllung kommen.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2060" uv="1">

</role>

Eine Zielerreichung ist mit vertretbarem Mehraufwand möglich.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2061" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2062" uv="1">

</role>

Es kann zu einer schweren Beeinträchtigung der Aufgabenerfüllung kommen.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2063" uv="1">

</role>

Bedeutende Zielabweichung in Qualität und/oder Quantität.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2064" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2065" uv="1">

</role>

Es kann zu einer sehr schweren Beeinträchtigung der Aufgabenerfüllung bis hin zur Handlungsunfähigkeit der betroffenen Organisation kommen.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>4. Vertraulichkeit der verarbeiteten Information</td>

-<td>

-<itemize uid="2067" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2068" uv="1">

</role>

Es werden nur Daten der Sicherheitsklassen OFFEN und EINGESCHRÄNKT verarbeitet bzw. gespeichert.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2069" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2070" uv="1">

</role>

Es werden auch Daten der Klasse VERTRAULICH verarbeitet bzw. gespeichert.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2071" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2072" uv="1">

</role>

Es werden auch Daten der Klassen GEHEIM und/oder STRENG GEHEIM verarbeitet bzw. gespeichert.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>5. Dauer der Verzichtbarkeit</td>

-<td>

-<itemize uid="2073" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2074" uv="1">

</role>

Die maximal tolerierbare Ausfallszeit der Anwendung beträgt mehr als 24 Stunden.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2075" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2076" uv="1">

</role>

Die maximal tolerierbare Ausfallszeit des Systems liegt zwischen einer und 24 Stunden.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2077" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2078" uv="1">

</role>

Die maximal tolerierbare Ausfallszeit des Systems ist kleiner als eine Stunde.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>6. Negative Außenwirkung</td>

-<td>

-<itemize uid="2079" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2080" uv="1">

</role>

Eine geringe bzw. nur interne Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2081" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2082" uv="1">

</role>

Eine breite Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2083" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2084" uv="1">

</role>

Eine landesweite breite Ansehens- oder Vertrauensbeeinträchtigung, evtl. sogar existenzgefährdender Art, ist zu erwarten.

</item>

</itemize>

</td>

</tr>

-<tr>

<td>7. Finanzielle Auswirkungen</td>

-<td>

-<itemize uid="2085" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2086" uv="1">

</role>

Der finanzielle Schaden liegt unter (z.B.) Euro 50.000.--.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2087" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2088" uv="1">

</role>

Der Schaden bewirkt beachtliche finanzielle Verluste, ist jedoch nicht existenzbedrohend.

</item>

</itemize>

</td>

-<td>

-<itemize uid="2089" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2090" uv="1">

</role>

Der finanzielle Schaden ist für die Institution existenzbedrohend.

</item>

</itemize>

</td>

</tr>

</table>

</subsection>

-<subsection uid="867" uv="1" version="2.1.000">

-<title uid="868" uv="1">

<name>Schutzbedarfsfeststellung</name>

</title>

-<role uid="869" uv="1">

</role>

<abstract uid="870" uv="1">Die Schutzbedarfsfeststellung bildet die Grundlage für eine Entscheidung über die weitere Vorgehensweise und ist daher mit entsprechender Sorgfalt durchzuführen.</abstract>

<detailed uid="871" uv="1">Die Schutzbedarfsfeststellung erfolgt in 3 Schritten:</detailed>

-<detailed uid="872" uv="1">

<emphasize level="2">Schritt 1: Erfassung aller vorhandenen oder geplanten IT-Systeme</emphasize>

<emphasize level="2">Schritt 2: Erfassung der IT-Anwendungen und Zuordnung zu den einzelnen IT-Systemen</emphasize>

<emphasize level="2">Schritt 3: Schutzbedarfsfeststellung für jedes IT-System</emphasize>

</detailed>

-<subsubsection uid="873" uv="1" version="2.1.000">

-<title uid="874" uv="1">

<name>Erfassung aller vorhandenen oder geplanten IT-Systeme</name>

</title>

-<role uid="875" uv="1">

</role>

<abstract uid="876" uv="1">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.</abstract>

<detailed uid="877" uv="1">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.</detailed>

</subsubsection>

-<subsubsection uid="878" uv="1" version="2.1.000">

-<title uid="879" uv="1">

<name>Erfassung der IT-Anwendungen und Zuordnung zu den einzelnen IT-Systemen</name>

</title>

-<role uid="880" uv="1">

</role>

<abstract uid="881" uv="1">Ziel dieses Schrittes ist es, alle oder zumindest die wichtigsten auf dem betrachteten IT-System laufenden oder geplanten IT-Anwendungen zu erfassen.</abstract>

<detailed uid="882" uv="1">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, </detailed>

-<itemize uid="883" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="884" uv="1">

</role>

deren Daten/Informationen und Programme den höchsten Bedarf an Vertraulichkeit haben,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="885" uv="1">

</role>

deren Daten/Informationen und Programme den höchsten Bedarf an Integrität aufweisen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="886" uv="1">

</role>

die die kürzeste tolerierbare Ausfallszeit haben.

</item>

</itemize>

</subsubsection>

-<subsubsection uid="887" uv="1" version="2.3.001">

-<title uid="888" uv="1">

<name>Schutzbedarfsfeststellung für jedes IT-System</name>

</title>

-<role uid="889" uv="1">

</role>

<abstract uid="890" uv="1">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.</abstract>

-<detailed uid="891" uv="1">

Als Orientierungshilfe für die Einordnung von IT-Anwendungen in Schutzbedarfskategorien kann die in

-<link uid="892" uv="1">

-<intern>

<name>Abschnitt 4.4.1</name>

<source>#SUBSECTION 4.4.1</source>

</intern>

</link>

angeführte Tabelle dienen. Es ist aber empfehlenswert, eine den spezifischen Anforderungen der betroffenen Organisation entsprechende modifizierte Tabelle zu erstellen.

</detailed>

<detailed uid="893" uv="1">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.</detailed>

</subsubsection>

</subsection>

-<subsection uid="894" uv="1" version="2.3.001">

-<title uid="895" uv="1">

<name>Durchführung von Grundschutzanalysen und detaillierten Risikoanalysen</name>

</title>

-<role uid="896" uv="1">

</role>

-<abstract uid="897" uv="1">

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

-<link uid="898" uv="1">

-<intern>

<name>Grundschutzansatz</name>

<source>#SECTION 4.3</source>

</intern>

</link>

beschriebenen Vorgehensweise durchzuführen.

</abstract>

-<detailed uid="899" uv="1">

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

-<link uid="900" uv="1">

-<intern>

<name>Detaillierte Risikoanalyse</name>

<source>#SECTION 4.2</source>

</intern>

</link>

dieses Handbuches.

</detailed>

<detailed uid="2091" uv="1">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. </detailed>

</subsection>

</section>

-<section uid="901" uv="1" version="2.3.001">

-<title uid="902" uv="1">

<name>Akzeptables Restrisiko</name>

</title>

-<role uid="903" uv="1">

</role>

<abstract uid="904" uv="1">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.</abstract>

-<detailed uid="905" uv="1">

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

-<link uid="906" uv="1">

-<intern>

<name>Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken</name>

<source>#SUBSECTION 3.2.4</source>

</intern>

</link>

) und festlegen, welche Risiken die betroffene Organisation generell zu akzeptieren bereit ist.

</detailed>

<detailed uid="907" uv="1">Dabei ist zu beachten, dass durch Kumulationseffekte oder gegenseitige Beeinflussungen eine Reihe von kleinen Einzelrisiken zu einem inakzeptablen Restrisiko führen kann. </detailed>

<detailed uid="908" uv="1">Die Entscheidung über die Akzeptanz von Restrisiken ist daher immer eine für das spezielle System zu treffende Managemententscheidung. </detailed>

</section>

-<section uid="909" uv="1" version="2.1.000">

-<title uid="910" uv="1">

<name>Akzeptanz von außergewöhnlichen Restrisiken</name>

</title>

-<role uid="911" uv="1">

</role>

<abstract uid="912" uv="1">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.</abstract>

<detailed uid="913" uv="1">Ist dies technisch nicht möglich oder unwirtschaftlich, so besteht in begründeten Ausnahmefällen die Möglichkeit, dieses erhöhte Restrisiko bewusst anzunehmen.</detailed>

<detailed uid="914" uv="1">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.</detailed>

</section>

</chapter>

-<chapter uid="915" uv="1" version="2.3.001">

-<title uid="916" uv="1">

<name>Erstellung von Sicherheitskonzepten</name>

</title>

<abstract uid="917" uv="1">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.</abstract>

<detailed uid="918" uv="1">Ein Sicherheitskonzept enthält</detailed>

-<itemize uid="919" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="920" uv="1">

</role>

die Beschreibung des Ausgangszustandes einschließlich der bestehenden Risiken (Ergebnisse der vorangegangenen Risikoanalyse),

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="921" uv="1">

</role>

die Festlegung der durchzuführenden Maßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="922" uv="1">

</role>

die Begründung der Auswahl unter Kosten/Nutzen-Aspekten und hinsichtlich des Zusammenwirkens der einzelnen Maßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="923" uv="1">

</role>

eine Abschätzung des Restrisikos sowie eine verbindliche Aussage über die Akzeptanz des verbleibenden Restrisikos,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="924" uv="1">

</role>

die Festlegung der Verantwortlichkeiten für die Auswahl und Umsetzung der Maßnahmen sowie für die regelmäßige Überprüfung des Konzeptes sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="925" uv="1">

</role>

eine Prioritäten-, Termin- und Ressourcenplanung für die Umsetzung.

</item>

</itemize>

<detailed uid="926" uv="1">Die Erstellung eines Sicherheitskonzeptes erfolgt in vier Schritten:</detailed>

-<detailed uid="927" uv="1">

<emphasize level="2">Schritt 1: Auswahl von Maßnahmen</emphasize>

<emphasize level="2">Schritt 2: Prüfung von Restrisiken und Risikoakzeptanz</emphasize>

<emphasize level="2">Schritt 3: Erstellung von Sicherheitsrichtlinien</emphasize>

<emphasize level="2">Schritt 4: Erstellung eines Informationssicherheitsplanes</emphasize>

</detailed>

<detailed uid="928" uv="1">Diese vier Schritte werden in den folgenden Kapiteln näher beschrieben.</detailed>

-<section uid="929" uv="1" version="2.3.001">

-<title uid="930" uv="1">

<name>Auswahl von Maßnahmen</name>

</title>

-<role uid="931" uv="1">

</role>

<abstract uid="932" uv="1">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. </abstract>

<detailed uid="933" uv="1">Sicherheitsmechanismen können</detailed>

-<itemize uid="934" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="935" uv="1">

</role>

Risiken vermeiden,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="936" uv="1">

</role>

Bedrohungen oder Schwachstellen verkleinern,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="937" uv="1">

</role>

unerwünschte Ereignisse entdecken,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="938" uv="1">

</role>

die Auswirkung eines unerwünschten Ereignisses eingrenzen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="939" uv="1">

</role>

Risiken überwälzen oder

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="940" uv="1">

</role>

es möglich machen, einen früheren Zustand wiederherzustellen.

</item>

</itemize>

-<subsection uid="941" uv="1" version="2.3.001">

-<title uid="942" uv="1">

<name>Klassifikation von Sicherheitsmaßnahmen</name>

</title>

-<role uid="943" uv="1">

</role>

<abstract uid="944" uv="1">Je nach Betrachtungsweise kann eine Klassifikation von Sicherheitsmaßnahmen hinsichtlich nachfolgender Kriterien getroffen werden.</abstract>

-<subsubsection uid="945" uv="1" version="2.1.000">

-<title uid="946" uv="1">

<name>Klassifikation nach Art der Maßnahmen</name>

</title>

-<role uid="947" uv="1">

</role>

<abstract uid="948" uv="1">Dies ist die "klassische" Einteilung der Sicherheitsmaßnahmen.</abstract>

<detailed uid="949" uv="1">Man unterscheidet:</detailed>

-<itemize uid="950" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="951" uv="1">

</role>

(informations-)technische Maßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="952" uv="1">

</role>

bauliche Maßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="953" uv="1">

</role>

organisatorische Maßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="954" uv="1">

</role>

personelle Maßnahmen

</item>

</itemize>

</subsubsection>

-<subsubsection uid="956" uv="1" version="2.3.001">

-<title uid="957" uv="1">

<name>Klassifikation nach Anwendungsbereichen</name>

</title>

-<role uid="958" uv="1">

</role>

<detailed uid="959" uv="1">Man unterscheidet: </detailed>

-<detailed uid="960" uv="1">

<emphasize level="0">Maßnahmen, die organisationsweit (oder in Teilen der Organisation) einzusetzen sind.</emphasize>

</detailed>

<detailed uid="961" uv="1">Dazu gehören:</detailed>

-<itemize uid="962" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="963" uv="1">

</role>

Etablierung eines ISM-Prozesses und Erstellung von Informationssicherheitspolitiken

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="964" uv="1">

</role>

organisatorische Maßnahmen (z.B. Kontrolle von Betriebsmitteln, Dokumentation, Rollentrennung)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="965" uv="1">

</role>

Überprüfung der IT-Sicherheitsmaßnahmen auf Übereinstimmung mit den Informationssicherheitspolitiken (Security Compliance Checking), Auditing

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="966" uv="1">

</role>

Reaktion auf sicherheitsrelevante Ereignisse (Incident Handling)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="967" uv="1">

</role>

personelle Maßnahmen (incl. Schulung und Bildung von Sicherheitsbewusstsein)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="968" uv="1">

</role>

bauliche Sicherheit und Infrastruktur

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="969" uv="1">

</role>

Notfallvorsorge

</item>

</itemize>

-<detailed uid="970" uv="1">

<emphasize level="0">Systemspezifische Maßnahmen.</emphasize>

</detailed>

<detailed uid="971" uv="1">Die Auswahl systemspezifischer Maßnahmen hängt in hohem Maße vom Typ des zu schützenden IT-Systems ab. Man unterscheidet etwa:</detailed>

-<itemize uid="973" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="974" uv="1">

</role>

Nicht-vernetzte Systeme (Stand-Alone-PCs)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="975" uv="1">

</role>

Workstations in einem Netzwerk

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="976" uv="1">

</role>

Server in einem Netzwerk

</item>

</itemize>

</subsubsection>

-<subsubsection uid="977" uv="1" version="2.3.001">

-<title uid="978" uv="1">

<name>Klassifikation nach Gefährdungen und Sicherheitsanforderungen</name>

</title>

-<role uid="979" uv="1">

</role>

<abstract uid="980" uv="1">Ausgehend von den Grundbedrohungen gegen ein IT-System (Verlust der Vertraulichkeit, Integrität, Verfügbarkeit, etc.) werden die typischen Gefährdungen ermittelt.</abstract>

<detailed uid="981" uv="1">Man unterscheidet daher:</detailed>

-<itemize uid="982" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="983" uv="1">

</role>

Maßnahmen zur Gewährleistung der Vertraulichkeit (

<emphasize level="0">confidentiality</emphasize>

)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="984" uv="1">

</role>

Maßnahmen zur Gewährleistung der Integrität (

<emphasize level="0">integrity</emphasize>

)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="985" uv="1">

</role>

Maßnahmen zur Gewährleistung der Verfügbarkeit (

<emphasize level="0">availability</emphasize>

)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="986" uv="1">

</role>

Maßnahmen zur Gewährleistung der Zurechenbarkeit (

<emphasize level="0">accountability</emphasize>

)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="987" uv="1">

</role>

Maßnahmen zur Gewährleistung der Authentizität (

<emphasize level="0">authenticity</emphasize>

)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="988" uv="1">

</role>

Maßnahmen zur Gewährleistung der Zuverlässigkeit (

<emphasize level="0">reliability</emphasize>

)

</item>

</itemize>

<detailed uid="989" uv="1">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.</detailed>

</subsubsection>

</subsection>

-<subsection uid="990" uv="1" version="2.1.000">

-<title uid="991" uv="1">

<name>Ausgangsbasis für die Auswahl von Maßnahmen</name>

</title>

-<role uid="992" uv="1">

</role>

-<paragraph uid="993" uv="1" version="2.1.000">

-<title uid="994" uv="1">

<name>Liste existierender bzw. geplanter Sicherheitsmaßnahmen:</name>

</title>

<abstract uid="995" uv="1">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. </abstract>

-<detailed uid="996" uv="1">

Im Fall einer detaillierten Risikoanalyse erfolgt dies im Rahmen der "Identifikation bestehender Schutzmaßnahmen" (vgl. Kapitel

-<link uid="997" uv="1">

-<intern>

<name>Identifikation bestehender Sicherheitsmaßnahmen</name>

<source>#SUBSECTION 4.2.6</source>

</intern>

</link>

), 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

-<link uid="998" uv="1">

-<intern>

<name>Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen</name>

<source>#SUBSUBSECTION 4.3.2.2</source>

</intern>

</link>

) ermittelt.

</detailed>

</paragraph>

-<paragraph uid="999" uv="1" version="2.1.000">

-<title uid="1000" uv="1">

<name>Ergebnisse der Risikobewertung:</name>

</title>

<abstract uid="1001" uv="1">Die Auswahl der Sicherheitsmaßnahmen, die die Risiken auf ein definiertes und beherrschbares Maß reduzieren, muss auf den Ergebnissen der Risikobewertung basieren.</abstract>

<detailed uid="1002" uv="1">Diese Auswahl wird von einer Reihe von Faktoren beeinflusst:</detailed>

-<itemize uid="1003" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1004" uv="1">

</role>

der Stärke der einzelnen Maßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1005" uv="1">

</role>

ihrer Benutzerfreundlichkeit und Transparenz für die Anwender/innen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1006" uv="1">

</role>

der Art der Schutzfunktion (Verringerung von Bedrohungen, Erkennen von Verletzungen, ...)

</item>

</itemize>

-<detailed uid="1007" uv="1">

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 (

<emphasize level="0">trade-off analysis</emphasize>

) notwendig sein.

</detailed>

</paragraph>

</subsection>

-<subsection uid="1008" uv="1" version="2.3.001">

-<title uid="1009" uv="1">

<name>Auswahl von Maßnahmen auf Basis einer detaillierten Risikoanalyse</name>

</title>

-<role uid="1010" uv="1">

</role>

<abstract uid="1011" uv="1">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. </abstract>

<detailed uid="1012" uv="1">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.</detailed>

<detailed uid="1013" uv="1">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: </detailed>

-<itemize uid="1014" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1015" uv="1">

</role>

Vorbeugung (präventive Maßnahmen)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1016" uv="1">

</role>

Aufdeckung (detektive Maßnahmen)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1017" uv="1">

</role>

Abschreckung

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1018" uv="1">

</role>

Schadensbegrenzung

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1019" uv="1">

</role>

Wiederherstellung eines früheren Zustandes

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1020" uv="1">

</role>

Bildung von Sicherheitsbewusstsein

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1021" uv="1">

</role>

Risikoüberwälzung

</item>

</itemize>

<detailed uid="1022" uv="1">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.</detailed>

</subsection>

-<subsection uid="1023" uv="1" version="2.3.001">

-<title uid="1024" uv="1">

<name>Auswahl von Maßnahmen im Falle eines Grundschutzansatzes</name>

</title>

-<role uid="1025" uv="1">

</role>

<abstract uid="1026" uv="1">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.</abstract>

-<paragraph uid="1027" uv="1" version="2.3.001">

-<title uid="1028" uv="1">

<name>Standardwerke zur Auswahl von Maßnahmen: </name>

</title>

<abstract uid="1029" uv="1">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.</abstract>

-<detailed uid="1030" uv="1">

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

-<link uid="1031" uv="1">

-<intern>

<name>Grundschutzansatz</name>

<source>#SECTION 4.3</source>

</intern>

</link>

dieses Handbuches). Die Unterstützung durch das "IT-Grundschutz-Tool" erleichtert die Auswahl, Dokumentation und Verwaltung der Maßnahmen.

</detailed>

</paragraph>

</subsection>

-<subsection uid="1034" uv="1" version="2.1.000">

-<title uid="1035" uv="1">

<name>Auswahl von Maßnahmen im Falle eines kombinierten Risikoanalyseansatzes</name>

</title>

-<role uid="1036" uv="1">

</role>

-<abstract uid="1037" uv="1">

Im Falle eines kombinierten Ansatzes werden zunächst anhand eines Grundschutzkataloges (etwa

-<link uid="1038" uv="1">

-<literature>

<name/>

<source>#SECTION A.1</source>

</literature>

</link>

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.

</abstract>

</subsection>

-<subsection uid="1039" uv="1" version="2.1.000">

-<title uid="1040" uv="1">

<name>Bewertung von Maßnahmen</name>

</title>

-<role uid="1041" uv="1">

</role>

<abstract uid="1042" uv="1">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.</abstract>

<detailed uid="1043" uv="1">Zur Bewertung von Sicherheitsmaßnahmen ist wie folgt vorzugehen:</detailed>

-<itemize uid="1044" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1045" uv="1">

</role>

Erfassung aller Bedrohungen, gegen die die ausgewählten Maßnahmen wirken,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1046" uv="1">

</role>

Beschreibung der Auswirkung der Einzelmaßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1047" uv="1">

</role>

Beschreibung des Zusammenwirkens der ausgewählten und der bereits vorhandenen Sicherheitsmaßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1048" uv="1">

</role>

Überprüfung, ob und inwieweit die Maßnahmen zu Behinderungen beim Betrieb des IT-Systems führen können,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1049" uv="1">

</role>

Überprüfung der Vereinbarkeit der Maßnahmen mit geltenden rechtlichen Vorschriften und Richtlinien und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1050" uv="1">

</role>

Bewertung, in welchem Ausmaß die Maßnahmen eine Reduktion der Risiken bewirken.

</item>

</itemize>

<detailed uid="1051" uv="1">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.</detailed>

</subsection>

-<subsection uid="1052" uv="1" version="2.1.000">

-<title uid="1053" uv="1">

<name>Rahmenbedingungen </name>

</title>

-<role uid="1054" uv="1">

</role>

-<abstract uid="1055" uv="1">

Bei der Auswahl und Umsetzung von Sicherheitsmaßnahmen sind stets auch Rahmenbedingungen (

<emphasize level="0">constraints</emphasize>

) zu berücksichtigen, die entweder durch das Umfeld vorgegeben oder durch das Management festgelegt werden.

</abstract>

<detailed uid="1056" uv="1">Beispiele für solche Rahmenbedingungen sind:</detailed>

-<itemize uid="1057" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1058" uv="1">

</role>

<emphasize level="2">Zeitliche Rahmenbedingungen</emphasize>

Etwa: Wie schnell ist auf ein erkanntes Risiko zu reagieren? Wann kann/muss eine Maßnahme realisiert sein?

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1059" uv="1">

</role>

<emphasize level="2">Finanzielle Rahmenbedingungen</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1060" uv="1">

</role>

<emphasize level="2">Umweltbedingungen</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1061" uv="1">

</role>

<emphasize level="2">Technische Rahmenbedingungen</emphasize>

z.B. Kompatibilität von Hard- und/oder Software

</item>

</itemize>

<detailed uid="1062" uv="1">Weitere Einschränkungen können organisatorischer, personeller, gesetzlicher oder sozialer Natur sein. </detailed>

<detailed uid="1063" uv="1">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.</detailed>

</subsection>

</section>

-<section uid="1064" uv="1" version="2.1.000">

-<title uid="1065" uv="1">

<name>Risikoakzeptanz</name>

</title>

-<role uid="1066" uv="1">

</role>

<abstract uid="1067" uv="1">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:</abstract>

-<paragraph uid="1068" uv="1" version="2.1.000">

-<title uid="1069" uv="1">

<name>Schritt 1: Quantifizierung des Restrisikos</name>

</title>

<detailed uid="1070" uv="1">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.</detailed>

</paragraph>

-<paragraph uid="1071" uv="1" version="2.3.001">

-<title uid="1072" uv="1">

<name>Schritt 2: Bewertung der Restrisiken</name>

</title>

-<detailed uid="1073" uv="1">

Die verbleibenden Restrisiken sind als "akzeptabel" oder "nicht-akzeptabel" zu klassifizieren. Die Entscheidungsgrundlage dafür sollte in der (organisationsweiten) Informationssicherheitspolitik festgelegt sein (vgl. Kapitel

-<link uid="1074" uv="1">

-<intern>

<name>Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken</name>

<source>#SUBSECTION 3.2.4</source>

</intern>

</link>

, Schritt 2, sowie Kapitel

-<link uid="1075" uv="1">

-<intern>

<name>Akzeptables Restrisiko</name>

<source>#SECTION 4.5</source>

</intern>

</link>

). Akzeptable Restrisiken können in Kauf genommen werden, nicht-akzeptable bedürfen einer weiteren Analyse.

</detailed>

</paragraph>

-<paragraph uid="1076" uv="1" version="2.1.000">

-<title uid="1077" uv="1">

<name>Schritt 3: Entscheidung über nicht-akzeptable Restrisiken</name>

</title>

<detailed uid="1078" uv="1">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.</detailed>

</paragraph>

-<paragraph uid="1079" uv="1" version="2.3.001">

-<title uid="1080" uv="1">

<name>Schritt 4: Akzeptanz von außergewöhnlichen Restrisiken </name>

</title>

-<detailed uid="1081" uv="1">

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

-<link uid="1082" uv="1">

-<intern>

<name>Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken</name>

<source>#SUBSECTION 3.2.4</source>

</intern>

</link>

, Schritt 3 und Kapitel

-<link uid="1083" uv="1">

-<intern>

<name>Akzeptanz von außergewöhnlichen Restrisiken</name>

<source>#SECTION 4.6</source>

</intern>

</link>

</detailed>

</paragraph>

</section>

-<section uid="1084" uv="1" version="2.3.001">

-<title uid="1085" uv="1">

<name>Sicherheitsrichtlinien</name>

</title>

-<role uid="1086" uv="1">

</role>

-<subsection uid="1087" uv="1" version="2.3.001">

-<title uid="1088" uv="1">

<name>Aufgaben und Ziele</name>

</title>

-<role uid="1089" uv="1">

</role>

<abstract uid="1090" uv="1">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. </abstract>

</subsection>

-<subsection uid="1099" uv="1" version="2.3.001">

-<title uid="1100" uv="1">

<name>Inhalte </name>

</title>

-<role uid="1101" uv="1">

</role>

<detailed uid="1102" uv="1">Eine Sicherheitsrichtlinie sollte Aussagen zu folgenden Bereichen treffen:</detailed>

-<itemize uid="1103" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1104" uv="1">

</role>

Definition und Abgrenzung des Systems, Beschreibung der wichtigsten Komponenten

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1105" uv="1">

</role>

Definition der wichtigsten Ziele und Funktionalitäten des Systems

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1106" uv="1">

</role>

Festlegung der Informationssicherheitsziele des Systems

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1107" uv="1">

</role>

<emphasize level="2">Abhängigkeit der Organisation vom betrachteten IT-System;</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1108" uv="1">

</role>

<emphasize level="2">Investitionen in das System</emphasize>

(Entwicklungs-, Beschaffungs- und Wartungskosten, Kosten für den laufenden Betrieb)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1109" uv="1">

</role>

Risikoanalysestrategie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1110" uv="1">

</role>

Werte, Bedrohungen und Schwachstellen lt. Risikoanalyse

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1111" uv="1">

</role>

Sicherheitsrisiken

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1112" uv="1">

</role>

Beschreibung der bestehenden und der noch zu realisierenden Sicherheitsmaßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1113" uv="1">

</role>

Gründe für die Auswahl der Maßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1114" uv="1">

</role>

Kostenschätzungen für die Realisierung und den laufenden Betrieb (Wartung) der Sicherheitsmaßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1115" uv="1">

</role>

Verantwortlichkeiten

</item>

</itemize>

</subsection>

-<subsection uid="1116" uv="1" version="2.3.001">

-<title uid="1117" uv="1">

<name>Fortschreibung der Sicherheitsrichtlinien</name>

</title>

-<role uid="1118" uv="1">

</role>

<abstract uid="1119" uv="1">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.</abstract>

<detailed uid="1120" uv="1">Insbesondere ist es von Bedeutung, dass die Liste der existierenden bzw. noch umzusetzenden Sicherheitsmaßnahmen stets dem tatsächlich aktuellen Stand entspricht.</detailed>

</subsection>

-<subsection uid="1121" uv="1" version="2.1.000">

-<title uid="1122" uv="1">

<name>Verantwortlichkeiten</name>

</title>

-<role uid="1123" uv="1">

</role>

-<abstract uid="1124" uv="1">

Die Verantwortlichkeiten für die Erstellung und Fortschreibung der Sicherheitsrichtlinien sind im Einzelnen in der Informationssicherheitspolitik festzulegen (vgl. dazu Kapitel

-<link uid="1125" uv="1">

-<intern>

<name>Organisation und Verantwortlichkeiten für Informationssicherheit</name>

<source>#SUBSECTION 3.2.2</source>

</intern>

</link>

). 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.

</abstract>

</subsection>

</section>

-<section uid="1126" uv="1" version="2.3.001">

-<title uid="1127" uv="1">

<name>Informationssicherheitsplan</name>

</title>

-<role uid="1128" uv="1">

</role>

<abstract uid="1129" uv="1">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.</abstract>

<detailed uid="1130" uv="1">Im Detail sind für jedes System zu erstellen:</detailed>

-<itemize uid="1131" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1132" uv="1">

</role>

<emphasize level="2">eine Liste der vorhandenen sowie eine Liste der noch zu implementierenden Sicherheitsmaßnahmen;</emphasize>

für jede dieser Maßnahmen sollte eine Aussage über ihre Wirksamkeit sowie möglicherweise notwendige Verbesserungen oder Verstärkungen getroffen werden.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1133" uv="1">

</role>

eine Prioritätenreihung für die Implementierung der ausgewählten Sicherheitsmaßnahmen bzw. die Verbesserung bestehender Maßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1134" uv="1">

</role>

eine Kosten- und Aufwandsschätzung für Implementierung und Wartung der Maßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1135" uv="1">

</role>

<emphasize level="2">Detailplanung für die Implementierung</emphasize>

Diese soll folgende Punkte umfassen:

-<itemize uid="1136" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1137" uv="1">

</role>

Prioritäten

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1138" uv="1">

</role>

Zeitplan, abhängig von Prioritäten und Ressourcen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1139" uv="1">

</role>

Budget

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1140" uv="1">

</role>

Verantwortlichkeiten

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1141" uv="1">

</role>

Schulungs- und Sensibilisierungsmaßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1142" uv="1">

</role>

Test- und Abnahmeverfahren und -termine

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1143" uv="1">

</role>

Nachfolgeaktivitäten

</item>

</itemize>

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1144" uv="1">

</role>

eine Bewertung des nach der Implementierung aller Maßnahmen zu erwartenden Restrisikos

</item>

</itemize>

<detailed uid="1145" uv="1">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.</detailed>

</section>

-<section uid="1146" uv="1" version="2.3.001">

-<title uid="1147" uv="1">

<name>Fortschreibung des Sicherheitskonzeptes</name>

</title>

-<role uid="1148" uv="1">

</role>

<abstract uid="1149" uv="1">Auch das Sicherheitskonzept muss laufend fortgeschrieben werden.</abstract>

<detailed uid="1150" uv="1">Anlässe für eine neue Untersuchung und das Fortschreiben des Konzeptes können sein:</detailed>

-<itemize uid="1151" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1152" uv="1">

</role>

Ablauf eines vorgeschriebenen oder vereinbarten Zeitraumes (z.B. jährliches Update)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1153" uv="1">

</role>

Eintritt von Ereignissen, die die Bedrohungslage verändern, wie etwa politische oder gesellschaftliche Entwicklungen oder das Bekannt werden neuer Attacken

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1154" uv="1">

</role>

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

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1155" uv="1">

</role>

Ereignisse, die die Eintrittswahrscheinlichkeit von Bedrohungen verändern, wie etwa die Entwicklung neuer Techniken oder veränderte Einsatzbedingungen (Einsatzort, IT-Ausstattung, ...)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1156" uv="1">

</role>

neue Möglichkeiten für Sicherheitsmaßnahmen, etwa aufgrund von Preisänderungen oder der Verfügbarkeit neuer Technologien

</item>

</itemize>

<detailed uid="1157" uv="1">Voraussetzungen für eine effiziente und zielgerichtete Fortschreibung des Sicherheitskonzeptes sind </detailed>

-<itemize uid="1158" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1159" uv="1">

</role>

die laufende Überprüfung von Akzeptanz und Einhaltung der Sicherheitsmaßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1160" uv="1">

</role>

die Protokollierung von Schadensereignissen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1161" uv="1">

</role>

die Kontrolle der Wirksamkeit und Angemessenheit der Maßnahmen

</item>

</itemize>

<detailed uid="1162" uv="1">Ob eine neuerliche Risikoanalyse erforderlich ist oder lediglich die Auswahl der Maßnahmen überarbeitet wird, hängt vom Ausmaß der eingetretenen Veränderungen ab.</detailed>

</section>

</chapter>

-<chapter uid="1163" uv="1" version="2.3.001">

-<title uid="1164" uv="1">

<name>Umsetzung des Informationssicherheitsplanes</name>

</title>

<abstract uid="1165" uv="1">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. </abstract>

<detailed uid="1166" uv="1">Bei der Umsetzung des Planes ist zu beachten, dass</detailed>

-<itemize uid="1167" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1168" uv="1">

</role>

Verantwortlichkeiten rechtzeitig und eindeutig festgelegt werden,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1169" uv="1">

</role>

finanzielle und personelle Ressourcen rechtzeitig zugewiesen werden,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1170" uv="1">

</role>

die Maßnahmen korrekt umgesetzt werden,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1171" uv="1">

</role>

die Kosten sich in dem vorher abgeschätzten Rahmen halten und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1172" uv="1">

</role>

der Zeitplan eingehalten wird.

</item>

</itemize>

<detailed uid="1173" uv="1">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.</detailed>

<detailed uid="1174" uv="1">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).</detailed>

<detailed uid="1175" uv="1">Es empfiehlt sich, die Umsetzung des Informationssicherheitsplanes im Rahmen eines Projektes abzuwickeln.</detailed>

-<section uid="1176" uv="1" version="2.3.001">

-<title uid="1177" uv="1">

<name>Implementierung von Maßnahmen</name>

</title>

-<role uid="1178" uv="1">

</role>

-<abstract uid="1179" uv="1">

Sobald der Informationssicherheitsplan erstellt und verabschiedet wurde, sind die einzelnen Maßnahmen zu implementieren, auf ihre Übereinstimmung mit der Sicherheitspolitik zu überprüfen (

<emphasize level="0">Security Compliance Checking</emphasize>

) und auf Korrektheit und Vollständigkeit zu testen.

</abstract>

-<detailed uid="1180" uv="1">

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

-<link uid="1181" uv="1">

-<intern>

<name>Auswahl von Maßnahmen</name>

<source>#SECTION 5.1</source>

</intern>

</link>

</detailed>

<detailed uid="1182" uv="1">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 </detailed>

-<itemize uid="1183" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1184" uv="1">

</role>

die systemübergreifenden, organisationsweiten Maßnahmen vollständig und angemessen, sowie nicht redundant oder widersprüchlich sind, und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1185" uv="1">

</role>

die systemspezifischen Maßnahmen kompatibel sind und ein einheitliches, angemessenes Sicherheitsniveau haben.

</item>

</itemize>

<detailed uid="1186" uv="1">Besonderer Wert ist auf eine detaillierte, korrekte und aktuelle Dokumentation dieser Implementierungen zu legen.</detailed>

-<paragraph uid="1187" uv="1" version="2.1.000">

-<title uid="1188" uv="1">

<name>Schritt 1: Implementierung der Sicherheitsmaßnahmen</name>

</title>

<abstract uid="1189" uv="1">Die Implementierung der ausgewählten Sicherheitsmaßnahmen hat anhand des Informationssicherheitsplanes, entsprechend der vorgegebenen Zeitpläne und Prioritäten, zu erfolgen. </abstract>

<detailed uid="1190" uv="1">Die Verantwortlichkeiten dafür sind im Detail festzulegen.</detailed>

</paragraph>

-<paragraph uid="1191" uv="1" version="2.1.000">

-<title uid="1192" uv="1">

<name>Schritt 2: Tests</name>

</title>

<abstract uid="1193" uv="1">Tests sollen sicherstellen, dass die Implementierung korrekt durchgeführt und abgeschlossen wurde. </abstract>

<detailed uid="1194" uv="1">Es wird empfohlen, für die Tests einen Testplan zu erstellen, der </detailed>

-<itemize uid="1195" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1196" uv="1">

</role>

die Testmethoden,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1197" uv="1">

</role>

die Testumgebung sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1198" uv="1">

</role>

die Zeitpläne für die Durchführung der Tests

</item>

</itemize>

<detailed uid="1199" uv="1">beinhaltet.</detailed>

<detailed uid="1200" uv="1">Die durchgeführten Tests sind im Detail zu beschreiben und die Ergebnisse in einem standardisierten Testbericht festzuhalten. </detailed>

<detailed uid="1201" uv="1">Abhängig von der speziellen Bedrohungslage und der Art der Maßnahmen kann die Durchführung von Penetrationstests erforderlich sein.</detailed>

</paragraph>

-<paragraph uid="1202" uv="1" version="2.3.001">

-<title uid="1203" uv="1">

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

</title>

-<abstract uid="1204" uv="1">

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

-<link uid="1205" uv="1">

-<intern>

<name>IT-Sicherheit im laufenden Betrieb</name>

<source>#CHAPTER 7</source>

</intern>

</link>

) durchzuführen.

</abstract>

<detailed uid="1206" uv="1">Dabei sind zu prüfen:</detailed>

-<itemize uid="1207" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1208" uv="1">

</role>

die vollständige und korrekte Umsetzung der Sicherheitsmaßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1209" uv="1">

</role>

der korrekte Einsatz der implementierten Sicherheitsmaßnahmen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1210" uv="1">

</role>

die Einhaltung der organisatorischen Sicherheitsmaßnahmen im täglichen Betrieb

</item>

</itemize>

-<detailed uid="1211" uv="1">

<emphasize level="0">Dokumentation</emphasize>

</detailed>

<detailed uid="1212" uv="1">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:</detailed>

-<itemize uid="1213" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1214" uv="1">

</role>

<emphasize level="2">Aktualität:</emphasize>

Alle Sicherheitsmaßnahmen sind stets auf dem aktuellen Stand der Realisierung zu beschreiben.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1215" uv="1">

</role>

Vollständigkeit

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1216" uv="1">

</role>

<emphasize level="2">Hoher Detaillierungsgrad:</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1217" uv="1">

</role>

<emphasize level="2">Gewährleistung der Vertraulichkeit:</emphasize>

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

-<link uid="1219" uv="1">

-<intern>

<name>Klassifizierung von Informationen</name>

<source>#SUBSECTION 3.2.5</source>

</intern>

</link>

). 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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1220" uv="1">

</role>

<emphasize level="2">Konfigurations- und Integritätskontrolle:</emphasize>

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.

</item>

</itemize>

</paragraph>

</section>

-<section uid="1221" uv="1" version="2.3.001">

-<title uid="1222" uv="1">

<name>Sensibilisierung (Security Awareness)</name>

</title>

-<role uid="1223" uv="1">

</role>

<abstract uid="1224" uv="1">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.</abstract>

<detailed uid="1225" uv="1">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. </detailed>

<detailed uid="1226" uv="1">Das Sensibilisierungsprogramm sollte folgende Punkte umfassen:</detailed>

-<itemize uid="1227" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1228" uv="1">

</role>

Information aller Mitarbeiter/innen über die Informationssicherheitspolitik der Organisation. Im Rahmen einer Einführung sollten insbesondere folgende Punkte erläutert werden:

-<itemize uid="1229" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1230" uv="1">

</role>

die Informationssicherheitsziele und -politik der Institution sowie deren Erläuterung,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1231" uv="1">

</role>

die Bedeutung der Informationssicherheit für die Institution,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1232" uv="1">

</role>

Organisation und Verantwortlichkeiten im Bereich der Informationssicherheit,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1233" uv="1">

</role>

die Risikoanalysestrategie,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1234" uv="1">

</role>

die Sicherheitsklassifizierung von Daten,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1235" uv="1">

</role>

ausgewählte Sicherheitsmaßnahmen (insbesondere solche, die für die gesamte Organisation Gültigkeit haben),

</item>

</itemize>

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1236" uv="1">

</role>

die wichtigsten Ergebnisse der Risikoanalysen (Bedrohungen, Schwachstellen, Risiken, ...),

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1237" uv="1">

</role>

die Pläne zur Implementatierung und Überprüfung der Sicherheitsmaßnahmen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1238" uv="1">

</role>

die Auswirkungen von sicherheitsrelevanten Ereignissen für einzelne Anwender und für die gesamte Institution,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1239" uv="1">

</role>

die Notwendigkeit, Sicherheitsverstöße zu melden und zu untersuchen, und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1240" uv="1">

</role>

die Konsequenzen bei Nichteinhaltung von Sicherheitsvorgaben.

</item>

</itemize>

<detailed uid="1241" uv="1">Zur Sensibilisierung der Mitarbeiter/innen können u.a. folgende Maßnahmen beitragen:</detailed>

-<itemize uid="1242" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1243" uv="1">

</role>

regelmäßige Veranstaltungen zum Thema Informationssicherheit

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1244" uv="1">

</role>

Publikationen

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1245" uv="1">

</role>

schriftliche Festlegung der Berichtswege und Handlungsanweisungen im Falle eines vermuteten Sicherheitsproblems (z.B. Auftreten eines Virus, Hacker-Angriff, ...)

</item>

</itemize>

<detailed uid="1246" uv="1">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.</detailed>

<detailed uid="1247" uv="1">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. </detailed>

<detailed uid="1248" uv="1">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.</detailed>

</section>

-<section uid="1249" uv="1" version="2.3.001">

-<title uid="1250" uv="1">

<name>Schulung</name>

</title>

-<role uid="1251" uv="1">

</role>

<abstract uid="1252" uv="1">Ü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. </abstract>

<detailed uid="1253" uv="1">Weiters sind Personen, die in besonderem Maße mit Informationssicherheit zu tun haben, speziell dafür auszubilden und zu schulen. Dazu zählen etwa:</detailed>

-<itemize uid="1254" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1255" uv="1">

</role>

die/der IT-Sicherheitsbeauftragte und die Bereichs-IT-Sicherheitsbeauftragten

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1256" uv="1">

</role>

die Mitglieder des Informationssicherheitsmanagement-Teams

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="2092" uv="1">

</role>

Mitarbeiter/innen, die zu VERTRAULICH, GEHEIM oder STRENG GEHEIM eingestuften Informationen Zugang haben

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1257" uv="1">

</role>

Mitarbeiter/innen mit spezieller Verantwortung für die Systementwicklung (z.B. Projektleiter/innen)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1258" uv="1">

</role>

Mitarbeiter/innen mit spezieller Verantwortung für den Betrieb eines IT-Systems oder einer wichtigen Applikation (z.B. Applikationsverantwortliche)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1259" uv="1">

</role>

Mitarbeiter/innen, die mit Aufgaben der IT-Sicherheitsverwaltung betraut sind (z.B. Vergabe von Zutritts-, Zugangs- und Zugriffsrechten)

</item>

</itemize>

<detailed uid="1260" uv="1">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:</detailed>

-<itemize uid="1261" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1262" uv="1">

</role>

<emphasize level="2">Sicherheitspolitik und -infrastruktur:</emphasize>

Rollen und Verantwortlichkeiten, Organisation des Informationssicherheitsmanagements, Behandlung von sicherheitsrelevanten Vorfällen, regelmäßige Überprüfung von Sicherheitsmaßnahmen und ähnliches

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1263" uv="1">

</role>

<emphasize level="2">Bauliche Sicherheit:</emphasize>

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)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1264" uv="1">

</role>

Personelle Sicherheit

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1265" uv="1">

</role>

<emphasize level="2">Hardware- und Softwaresicherheit:</emphasize>

Dazu gehören etwa Identifikation und Authentisierung, Berechtigungssysteme, Protokollierung, Wiederaufbereitung und Virenschutz.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1266" uv="1">

</role>

<emphasize level="2">Netzwerksicherheit:</emphasize>

Netzwerkinfrastruktur, LANs, Inter-/Intranets, Verschlüsselung, digitale Signaturen u.ä.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1267" uv="1">

</role>

Business Continuity Planung

</item>

</itemize>

<detailed uid="1268" uv="1">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.</detailed>

</section>

-<section uid="1269" uv="1" version="2.3.001">

-<title uid="1270" uv="1">

<name>Akkreditierung</name>

</title>

-<role uid="1271" uv="1">

</role>

<abstract uid="1272" uv="1">Unter Akkreditierung eines IT-Systems versteht man die Sicherstellung, dass dieses den Anforderungen der Informationssicherheitspolitik und der Sicherheitsrichtlinien genügt. </abstract>

<detailed uid="1273" uv="1">Dabei ist insbesondere darauf zu achten, dass die Sicherheit des Systems </detailed>

-<itemize uid="1274" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1275" uv="1">

</role>

in einer bestimmten Betriebsumgebung,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1276" uv="1">

</role>

unter bestimmten Einsatzbedingungen und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1277" uv="1">

</role>

für eine bestimmte vorgegebene Zeitspanne

</item>

</itemize>

<detailed uid="1278" uv="1">gewährleistet ist. </detailed>

<detailed uid="1279" uv="1">Erst nach erfolgter Akkreditierung kann das System - oder eine spezifische Anwendung - in Echtbetrieb gehen. </detailed>

-<detailed uid="1280" uv="1">

<emphasize level="1">Techniken</emphasize>

zur Akkreditierung sind:

</detailed>

-<itemize uid="1281" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1282" uv="1">

</role>

Prüfung der Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik (

<emphasize level="0">Security Compliance Checking</emphasize>

), vgl. auch Kapitel

-<link uid="1283" uv="1">

-<intern>

<name>Implementierung von Maßnahmen</name>

<source>#SECTION 6.1</source>

</intern>

</link>

und

-<link uid="1284" uv="1">

-<intern>

<name>Überprüfung von Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik (Security Compliance Checking)</name>

<source>#SUBSECTION 7.1.2</source>

</intern>

</link>

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1285" uv="1">

</role>

Tests

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1286" uv="1">

</role>

Evaluation und Zertifizierung von Systemen

</item>

</itemize>

<detailed uid="1287" uv="1">Ä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.</detailed>

</section>

</chapter>

-<chapter uid="1288" uv="1" version="2.3.001">

-<title uid="1289" uv="1">

<name>Informationssicherheit im laufenden Betrieb</name>

</title>

<abstract uid="1290" uv="1">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. </abstract>

<abstract uid="1291" uv="1">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. </abstract>

-<section uid="1292" uv="1" version="2.3.001">

-<title uid="1293" uv="1">

<name>Aufrechterhaltung des erreichten Sicherheitsniveaus</name>

</title>

-<role uid="1294" uv="1">

</role>

<detailed uid="1295" uv="1">Das nach der Umsetzung des Informationssicherheitsplanes erreichte Sicherheitsniveau lässt sich nur dann aufrechterhalten, wenn </detailed>

-<itemize uid="1296" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1297" uv="1">

</role>

Wartung und administrativer Support der Sicherheitseinrichtungen gewährleistet sind,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1298" uv="1">

</role>

die realisierten Maßnahmen regelmäßig auf ihre Übereinstimmung mit der Informationssicherheitspolitik geprüft (

<emphasize level="0">Security Compliance Checking</emphasize>

) und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1299" uv="1">

</role>

die IT-Systeme fortlaufend überwacht werden (

<emphasize level="0">Monitoring</emphasize>

</item>

</itemize>

<detailed uid="1300" uv="1">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.</detailed>

-<detailed uid="1301" uv="1">

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

-<link uid="1302" uv="1">

-<intern>

<name>Sensibilisierung (Security Awareness)</name>

<source>#SECTION 6.2</source>

</intern>

</link>

</detailed>

-<subsection uid="1303" uv="1" version="2.3.001">

-<title uid="1304" uv="1">

<name>Wartung und administrativer Support von Sicherheitseinrichtungen</name>

</title>

-<role uid="1305" uv="1">

</role>

<abstract uid="1306" uv="1">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).</abstract>

<detailed uid="1307" uv="1">Alle Wartungs- und Supportaktivitäten sollten nach einem detailliert festgelegten Plan erfolgen und regelmäßig durchgeführt werden. </detailed>

<detailed uid="1308" uv="1">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.</detailed>

<detailed uid="1309" uv="1">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.</detailed>

<detailed uid="1310" uv="1">Um die Aufrechterhaltung eines einmal erreichten Sicherheitsniveaus zu gewährleisten, ist sicherzustellen, dass </detailed>

-<itemize uid="1311" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1312" uv="1">

</role>

die erforderlichen finanziellen und personellen Ressourcen zur Wartung von Sicherheitseinrichtungen zur Verfügung stehen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1313" uv="1">

</role>

organisatorische Regelungen existieren, die die Aufrechterhaltung der Informationssicherheitsmaßnahmen im laufenden Betrieb ermöglichen und unterstützen,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1314" uv="1">

</role>

die Verantwortungen im laufenden Betrieb klar zugewiesen werden,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1315" uv="1">

</role>

die Maßnahmen regelmäßig daraufhin geprüft werden, ob sie wie beabsichtigt funktionieren und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1316" uv="1">

</role>

Maßnahmen verstärkt werden, falls sich neue Schwachstellen zeigen.

</item>

</itemize>

<detailed uid="1317" uv="1">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.</detailed>

</subsection>

-<subsection uid="1318" uv="1" version="2.3.001">

-<title uid="1319" uv="1">

<name>Überprüfung von Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik (Security Compliance Checking)</name>

</title>

-<role uid="1320" uv="1">

</role>

-<paragraph uid="1321" uv="1" version="2.1.000">

-<title uid="1322" uv="1">

<name>Zielsetzung</name>

</title>

<abstract uid="1323" uv="1">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. </abstract>

<detailed uid="1324" uv="1">Dabei ist zu prüfen,</detailed>

-<itemize uid="1325" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1326" uv="1">

</role>

ob die Sicherheitsmaßnahmen vollständig und korrekt umgesetzt werden,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1327" uv="1">

</role>

der korrekte Einsatz der implementierten Sicherheitsmaßnahmen gewährleistet ist (Stichproben!) und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1328" uv="1">

</role>

die organisatorischen Sicherheitsvorgaben im täglichen Betrieb eingehalten und akzeptiert werden.

</item>

</itemize>

<detailed uid="1329" uv="1">Weiters sind die getroffenen Maßnahmen regelmäßig auf Übereinstimmung mit gesetzlichen und betrieblichen Vorgaben zu überprüfen. </detailed>

<detailed uid="1330" uv="1">Die Prüfungen können durch externe oder interne Auditoren durchgeführt werden und sollten soweit möglich auf standardisierten Tests und Checklisten basieren.</detailed>

</paragraph>

-<paragraph uid="1331" uv="1" version="2.3.001">

-<title uid="1332" uv="1">

<name>Zeitpunkte</name>

</title>

<detailed uid="1333" uv="1">Security Compliance Checks sollten zu folgenden Zeitpunkten bzw. bei Eintreten folgender Ereignisse durchgeführt werden:</detailed>

-<itemize uid="1334" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1335" uv="1">

</role>

<emphasize level="2">für neue IT-Systeme oder relevante neue Anwendungen:</emphasize>

nach der Implementierung (vgl. dazu auch Kap. 5.1 und Kap. 5.4)

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1336" uv="1">

</role>

<emphasize level="2">für bereits in Betrieb befindliche IT-Systeme oder Applikationen:</emphasize>

nach einer bestimmten, in den Sicherheitsrichtlinien vorzugebenden Zeitspanne (z.B. jährlich) sowie bei signifikanten Änderungen.

</item>

</itemize>

</paragraph>

</subsection>

-<subsection uid="1337" uv="1" version="2.3.001">

-<title uid="1338" uv="1">

<name>Fortlaufende Überwachung der IT-Systeme (Monitoring)</name>

</title>

-<role uid="1339" uv="1">

</role>

<abstract uid="1340" uv="1">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.</abstract>

<detailed uid="1341" uv="1">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.</detailed>

<detailed uid="1342" uv="1">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:</detailed>

-<itemize uid="1343" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1344" uv="1">

</role>

<emphasize level="2">Wert der zu schützenden Objekte:</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1345" uv="1">

</role>

<emphasize level="2">Bedrohungen und Schwachstellen:</emphasize>

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.

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1346" uv="1">

</role>

<emphasize level="2">Sicherheitsmaßnahmen:</emphasize>

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.

</item>

</itemize>

<detailed uid="1347" uv="1">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.</detailed>

<detailed uid="1348" uv="1">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.</detailed>

</subsection>

</section>

-<section uid="1349" uv="1" version="2.3.001">

-<title uid="1350" uv="1">

<name>Change Management</name>

</title>

-<role uid="1351" uv="1">

</role>

<abstract uid="1352" uv="1">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. </abstract>

<detailed uid="1353" uv="1">Es ist dafür Sorge zu tragen, dass auf alle sicherheitsrelevanten Änderungen angemessen reagiert wird. Dazu gehören zum Beispiel:</detailed>

-<itemize uid="1354" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1355" uv="1">

</role>

Änderungen in der Aufgabenstellung oder in der Wichtigkeit der Aufgabe für die Institution,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1356" uv="1">

</role>

räumliche Änderungen, z.B. nach einem Umzug,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1357" uv="1">

</role>

Änderungen in der Bewertung der eingesetzten IT, der notwendigen Vertraulichkeit, Integrität oder Verfügbarkeit und

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1358" uv="1">

</role>

Änderungen bei Bedrohungen oder Schwachstellen.

</item>

</itemize>

<detailed uid="1359" uv="1">Alle Änderungen und die dazugehörigen Entscheidungsgrundlagen sind schriftlich zu dokumentieren.</detailed>

<detailed uid="1360" uv="1">Abhängig von der Bedeutung des Systems und dem Grad der Änderung kann eine neuerliche Risikoanalyse erforderlich werden.</detailed>

</section>

-<section uid="1361" uv="1" version="2.1.000">

-<title uid="1362" uv="1">

<name>Reaktion auf sicherheitsrelevante Ereignisse ( Incident Handling )</name>

</title>

-<role uid="1363" uv="1">

</role>

<abstract uid="1364" uv="1">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.</abstract>

<detailed uid="1365" uv="1">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.</detailed>

<detailed uid="1366" uv="1">Daher sind alle Mitarbeiter/innen über ihre Verantwortung bei Eintreten sicherheitsrelevanter Ereignisse, die vorgesehenen Meldewege und zu setzenden Aktionen zu unterrichten.</detailed>

-<paragraph uid="1367" uv="1" version="2.1.000">

-<title uid="1368" uv="1">

<name>Incident Handling Plan</name>

</title>

-<abstract uid="1369" uv="1">

Zur Sicherstellung einer angemessenen Behandlung von sicherheitsrelevanten Ereignissen ist es empfehlenswert, detaillierte Vorgaben in Form eines "

<emphasize level="0">Incident Handling Planes</emphasize>

" (IHP) auszuarbeiten und allen Mitarbeiterinnen/Mitarbeitern bekannt zu machen.

</abstract>

<detailed uid="1370" uv="1">Der Incident Handling Plan legt in schriftlicher Form und verbindlich fest:</detailed>

-<itemize uid="1371" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1372" uv="1">

</role>

wie auf sicherheitsrelevante Ereignisse zu reagieren ist,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1373" uv="1">

</role>

die Verantwortlichkeiten für die Meldung bzw. Untersuchung sicherheitsrelevanter Vorfälle,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1374" uv="1">

</role>

die einzuhaltenden Meldewege,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1375" uv="1">

</role>

die Protokollierung und Dokumentation sicherheitsrelevanter Vorfälle sowie

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1376" uv="1">

</role>

die Ausbildung von Personen, die sicherheitsrelevante Vorfälle behandeln bzw. Gegenmaßnahmen treffen müssen.

</item>

</itemize>

</paragraph>

-<paragraph uid="1377" uv="1" version="2.3.001">

-<title uid="1378" uv="1">

<name>Einrichtung von CERTs</name>

</title>

<detailed uid="1379" uv="1">Ein CERT (Computer Emergency Response Team) ist eine Gruppe von Personen, die </detailed>

-<itemize uid="1380" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1381" uv="1">

</role>

die Ursachen und Auswirkungen von sicherheitsrelevanten Vorfällen untersucht,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1382" uv="1">

</role>

Vorfälle aufzeichnet und auswertet,

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1383" uv="1">

</role>

Hilfestellung bei der Behandlung von sicherheitsrelevanten Vorfällen gibt.

</item>

</itemize>

<detailed uid="1384" uv="1">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.</detailed>

<detailed uid="1385" uv="1">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.</detailed>

-<detailed uid="1386" uv="1">

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

-<link uid="1404" uv="1">

-<href>

<name>http://www.circa.at</name>

<source>http://www.circa.at</source>

</href>

</link>

erreichbar.

</detailed>

</paragraph>

</section>

</chapter>

-<!--

 Updated, 26.04.2007, uid="1405" - uid="1522"

-->

-<chapter uid="1405" uv="1" version="2.3.021">

-<title uid="1406" uv="1">

<name>Industrielle Sicherheit</name>

</title>

<abstract uid="1407" uv="1"> 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. </abstract>

<abstract uid="1408" uv="1"> 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). </abstract>

<detailed uid="1409" uv="1"> 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. </detailed>

<detailed uid="1410" uv="1"> Im Rahmen eines Vertrages verpflichtet sich das Unternehmen die entsprechenden Rechtsvorschriften und internationalen Standards für die Behandlung klassifizierter Dokumente einzuhalten. </detailed>

-<section uid="1411" uv="1" version="2.3.021">

-<title uid="1412" uv="1">

<name>Beschreibung der generellen Anforderungen</name>

</title>

-<role uid="1413" uv="1">

</role>

<detailed uid="1414" uv="1"> Auf Grund der diversen rechtlichen Grundlagen müssen die Sicherheitsmaßnahmen </detailed>

-<itemize uid="1415" uv="1">

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1416" uv="1">

</role>

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;

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1417" uv="1">

</role>

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;

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1418" uv="1">

</role>

verhindern, dass unbefugte Personen Zugang zu klassifizierten Informationen oder zu Einrichtungen, in denen klassifizierte Informationen aufbewahrt werden, erhalten;

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1419" uv="1">

</role>

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;

</item>

-<item egovernment="NOT_SET" industry="NOT_SET" orgsize="NOT_SET">

-<role uid="1420" uv="1">

</role>

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äh