Allgemeiner Text

Zum Geleit
Vorwort und Management Summary
Zur Version 3 des Informationssicherheitshandbuchs

Management Summary

Hauptquellen und Danksagungen

Einführung
Das Informationssicherheitshandbuch
Ziele des Informationssicherheitshandbuchs
Ziele der Version 3
Anwendungsbereich (Scope)
Neuheiten der Version 3
Quellen, Verträglichkeiten, Abgrenzungen
Informations- versus IT-Sicherheit
Informationssicherheitsmanagement
Ziele des Informationssicherheitsmanagements
Aufgaben des Informationssicherheitsmanagements
Informationssicherheitsmanagementsystem (ISMS)
Der Informationssicherheitsmanagementprozess
Entwicklung einer organisationsweiten Informationssicherheitspolitik
Risikoanalyse
Erstellung eines Sicherheitskonzeptes
Umsetzung des Informationssicherheitsplans
Informationssicherheit im laufenden Betrieb
Erstellung von Sicherheitskonzepten
Auswahl von Maßnahmen
Klassifikation von Sicherheitsmaßnahmen
Ausgangsbasis für die Auswahl von Maßnahmen
Auswahl von Maßnahmen auf Basis einer detaillierten Risikoanalyse
Auswahl von Maßnahmen im Falle eines Grundschutzansatzes
Auswahl von Maßnahmen im Falle eines kombinierten Risikoanalyseansatzes
Bewertung von Maßnahmen
Rahmenbedingungen
Risikoakzeptanz
Sicherheitsrichtlinien
Aufgaben und Ziele
Inhalte
Fortschreibung der Sicherheitsrichtlinien
Verantwortlichkeiten
Informationssicherheitspläne für jedes System
Fortschreibung des Sicherheitskonzeptes
Umsetzung des Informationssicherheitsplans
Implementierung von Maßnahmen
Sensibilisierung (Security Awareness)
Schulung
Akkreditierung
Informationssicherheit im laufenden Betrieb
Aufrechterhaltung des erreichten Sicherheitsniveaus
Wartung und administrativer Support von Sicherheitseinrichtungen
Überprüfung von Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik (Security Compliance Checking)
Fortlaufende Überwachung der IT-Systeme (Monitoring)
Managementverantwortung und Aufgaben beim ISMS
Verantwortung der Managementebene
Generelle Managementaufgaben beim ISMS
Ressourcenmanagement
Bereitstellung von Ressourcen
Schulung und Awareness
Interne ISMS Audits
Planung und Vorbereitung interner Audits
Durchführung interner Audits
Ergebnis und Auswertung interner Audits
Management-Review des ISMS
Management-Review Methoden
Review der Strategie und des Sicherheitskonzepts
Review der Sicherheitsmaßnahmen
Management-Review-Ergebnis und -Auswertung
Verbesserungsprozess beim ISMS
Grundlagen für Verbesserungen
Entscheidungs- und Handlungsbedarf
Risikoanalyse
Risikoanalysestrategien
Detaillierte Risikoanalyse
Abgrenzung des Analysebereiches
Identifikation der bedrohten Objekte (Werte, assets)
Wertanalyse (Impact Analyse)
Festlegung der Bewertungsbasis für Sachwerte
Festlegung der Bewertungsbasis für immaterielle Werte
Ermittlung der Abhängigkeiten zwischen den Objekten
Bewertung der bedrohten Objekte
Bedrohungsanalyse
Identifikation möglicher Bedrohungen
Bewertung möglicher Bedrohungen
Schwachstellenanalyse
Identifikation bestehender Sicherheitsmaßnahmen
Risikobewertung
Auswertung und Aufbereitung der Ergebnisse
Grundschutzansatz
Die Idee des IT-Grundschutzes
Grundschutzanalyse und Auswahl von Maßnahmen
Modellierung
Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen
Vorgehen bei Abweichungen
Dokumentation der Ergebnisse
Kombinierter Ansatz
Festlegung von Schutzbedarfskategorien
Schutzbedarfsfeststellung
Erfassung aller vorhandenen oder geplanten IT-Systeme
Erfassung der IT-Anwendungen und Zuordnung zu den einzelnen IT-Systemen
Schutzbedarfsfeststellung für jedes IT-System
Durchführung von Grundschutzanalysen und detaillierten Risikoanalysen
Akzeptables Restrisiko
Akzeptanz von außergewöhnlichen Restrisiken
Informationssicherheitspolitik
Aufgaben und Ziele einer Informationssicherheitspolitik
Inhalte der Informationssicherheitspolitik
Informationssicherheitsziele und -strategien
Management Commitment
Organisation und Verantwortlichkeiten für Informationssicherheit
Die/Der IT-Sicherheitsbeauftragte
Das Informationssicherheitsmanagement-Team
Die Bereichs-IT-Sicherheitsbeauftragten
Applikations-/Projektverantwortliche
Die/Der Informationssicherheitsbeauftragte
Weitere Pflichten und Verantwortungen im Bereich Informationssicherheit
Informationssicherheit und Datenschutz
Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken
Klassifizierung von Informationen
Definition der Sicherheitsklassen
Festlegung der Verantwortlichkeiten und der Vorgehensweise für klassifizierte Informationen
Erarbeitung von Regelungen zum Umgang mit klassifizierten Informationen
Klassifizierung von IT-Anwendungen und IT-Systemen, Grundzüge der Business Continuity Planung
Überprüfung und Aufrechterhaltung der Sicherheit
Dokumente zur Informationssicherheit
Lifecycle der Informationssicherheitspolitik
Erstellung der Informationssicherheitspolitik
Offizielle Inkraftsetzung der Informationssicherheitspolitik
Regelmäßige Überarbeitung
Organisation
Interne Organisation
Managementverantwortung
Zusammenwirken verantwortliches Management - MitarbeiterInnen - Gremien
Koordination
Definierte Verantwortlichkeiten für Informationssicherheit
Benutzungsgenehmigung für Informationsverarbeitung
Vertraulichkeitsvereinbarungen
Kontaktpflege mit Behörden und Gremien
Unabhängige Audits der Sicherheitsmaßnahmen
Berichtswesen
Zusammenarbeit mit Externen
Outsourcing
Gefährdungen beim Outsourcing
Outsourcing-Planungs- und -Betriebsphasen
Vermögenswerte und Klassifizierung von Informationen
Vermögenswerte
Inventar der Vermögenswerte (Assets) mittels Strukturanalyse
Erfassung von Geschäftsprozessen, Anwendungen und Informationen
Erfassung von Datenträgern und Dokumenten
Erhebung der IT-Systeme
Netzplan
Erfassung der Gebäude und Räume
Aktualisierung der Strukturanalyse
Eigentum von Vermögenswerten
Verantwortliche für Vermögenswerte (Assets)
Aufgaben der Eigentümer und Verantwortlichen
Zulässige Nutzung von Vermögenswerten
Herausgabe einer PC-Richtlinie
Einführung eines PC-Checkheftes
Geeignete Aufbewahrung tragbarer IT-Systeme
Mitnahme von Datenträgern und IT-Komponenten
Verhinderung der unautorisierten Nutzung von Rechnermikrofonen und Videokameras
Absicherung von Wechselmedien
Klassifizierung von Informationen
Personelle Sicherheit
Regelungen für MitarbeiterInnen
Verpflichtung der MitarbeiterInnen zur Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen
Aufnahme der sicherheitsrelevanten Aufgaben und Verantwortlichkeiten in die Stellenbeschreibung
Vertretungsregelungen
Geregelte Verfahrensweise beim Ausscheiden von MitarbeiterInnen
Geregelte Verfahrensweise bei Versetzung von MitarbeiterInnen
Gewährleistung eines positiven Betriebsklimas
Clear-Desk-Policy
Benennung vertrauenswürdiger AdministratorInnen und VertreterInnen
Verpflichtung der PC-BenutzerInnen zum Abmelden
Kontrolle der Einhaltung der organisatorischen Vorgaben
Geregelte Verfahrensweise bei vermuteten Sicherheitsverletzungen
Regelungen für den Einsatz von Fremdpersonal
Regelungen für den kurzfristigen Einsatz von Fremdpersonal
Verpflichtung externer MitarbeiterInnen zur Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen
Beaufsichtigung oder Begleitung von Fremdpersonen
Information externer MitarbeiterInnen über die IT-Sicherheitspolitik
Sicherheitssensibilisierung und -schulung
Geregelte Einarbeitung/Einweisung neuer MitarbeiterInnen
Schulung vor Programmnutzung
Schulung und Sensibilisierung zu IT-Sicherheitsmaßnahmen
Betreuung und Beratung von IT-BenutzerInnen
Aktionen bei Auftreten von Sicherheitsproblemen (Incident Handling-Pläne)
Schulung des Wartungs- und Administrationspersonals
Einweisung in die Regelungen der Handhabung von Kommunikationsmedien
Einweisung in die Bedienung von Schutzschränken
Physische und umgebungsbezogene Sicherheit
Bauliche und infrastrukturelle Maßnahmen
Geeignete Standortauswahl
Anordnung schützenswerter Gebäudeteile
Einbruchsschutz
Zutrittskontrolle
Verwaltung von Zutrittskontrollmedien
Portierdienst
Einrichtung einer Postübernahmestelle
Perimeterschutz
Brandschutz
Einhaltung von Brandschutzvorschriften und Auflagen
Raumbelegung unter Berücksichtigung von Brandlasten
Organisation Brandschutz
Brandabschottung von Trassen
Verwendung von Brandschutztüren und Sicherheitstüren
Brandmeldeanlagen
Brandmelder
Handfeuerlöscher (Mittel der Ersten und Erweiterten Löschhilfe)
Löschanlagen
Brandschutzbegehungen
Rauchverbot
Rauchschutzvorkehrungen
Stromversorgung, Maßnahmen gegen elektrische und elektromagnetische Risiken
Angepasste Aufteilung der Stromkreise
Not-Aus-Schalter
Zentrale Notstromversorgung
Lokale unterbrechungsfreie Stromversorgung
Blitzschutzeinrichtungen (Äußerer Blitzschutz)
Überspannungsschutz (Innerer Blitzschutz)
Schutz gegen elektromagnetische Einstrahlung
Schutz gegen kompromittierende Abstrahlung
Schutz gegen elektrostatische Aufladung
Leitungsführung
Lagepläne der Versorgungsleitungen
Materielle Sicherung von Leitungen und Verteilern
Entfernen oder Kurzschließen und Erden nicht benötigter Leitungen
Auswahl geeigneter Kabeltypen
Schadensmindernde Kabelführung
Vermeidung von wasserführenden Leitungen
Geeignete Aufstellung und Aufbewahrung
Geeignete Aufstellung eines Arbeitsplatz-IT-Systems
Geeignete Aufstellung eines Servers
Geeignete Aufstellung von Netzwerkkomponenten
Nutzung und Aufbewahrung mobiler IT-Geräte
Sichere Aufbewahrung der Datenträger vor und nach Versand
Serverräume
Beschaffung und Einsatz geeigneter Schutzschränke
Weitere Schutzmaßnahmen
Einhaltung einschlägiger Normen und Vorschriften
Regelungen für Zutritt zu Verteilern
Vermeidung von Lagehinweisen auf schützenswerte Gebäudeteile
Geschlossene Fenster und Türen
Alarmanlage
Fernanzeige von Störungen
Klimatisierung
Selbsttätige Entwässerung
Videounterstützte Überwachung
Aktualität von Plänen
Vorgaben für ein Rechenzentrum
Sicherheitsmanagement in Kommunikation und Betrieb
IT-Sicherheitsmanagement
Etablierung eines IT-Sicherheitsmanagementprozesses
Erarbeitung einer organisationsweiten Informationssicherheitspolitik
Erarbeitung von IT-Systemsicherheitspolitiken
Festlegung von Verantwortlichkeiten
Funktionstrennung
Einrichtung von Standardarbeitsplätzen
Akkreditierung von IT-Systemen
Change Management
Reaktion auf Änderungen am IT-System
Softwareänderungskontrolle
Dokumentation
Dokumentation von Software
Sourcecodehinterlegung
Dokumentation der Systemkonfiguration
Dokumentation der Datensicherung
Dokumentation und Kennzeichnung der Verkabelung
Neutrale Dokumentation in den Verteilern
Dienstleistungen durch Dritte (Outsourcing)
Festlegung einer Outsourcing-Strategie
Festlegung der Sicherheitsanforderungen für Outsourcing-Vorhaben
Wahl eines geeigneten Outsourcing-Dienstleisters
Vertragsgestaltung mit dem Outsourcing-Dienstleister
Erstellung eines IT-Sicherheitskonzepts für das Outsourcing-Vorhaben
Notfallvorsorge beim Outsourcing
Schutz vor Schadprogrammen und Schadfunktionen
Erstellung eines Virenschutzkonzepts
Generelle Maßnahmen zur Vorbeugung gegen Virenbefall
Empfohlene Virenschutzmaßnahmen auf Firewall-Ebene
Empfohlene Virenschutzmaßnahmen auf Server-Ebene
Empfohlene Virenschutzmaßnahmen auf Client-Ebene und Einzelplatzrechnern
Vermeidung bzw. Erkennung von Viren durch die BenutzerInnen
Erstellung von Notfallplänen im Fall von Vireninfektionen
Auswahl und Einsatz von Virenschutzprogrammen
Verhaltensregeln bei Auftreten eines Virus
Warnsystem für Computerviren – Aktualisierung von Virenschutzprogrammen
Schutz vor aktiven Inhalten
Sicherer Aufruf ausführbarer Dateien
Vermeidung gefährlicher Dateiformate
Datensicherung
Regelmäßige Datensicherung
Entwicklung eines Datensicherungskonzeptes
Festlegung des Minimaldatensicherungskonzeptes
Datensicherung bei Einsatz kryptographischer Verfahren
Geeignete Aufbewahrung der Backup-Datenträger
Sicherungskopie der eingesetzten Software
Beschaffung eines geeigneten Datensicherungssystems
Datensicherung bei mobiler Nutzung eines IT-Systems
Verpflichtung der MitarbeiterInnen zur Datensicherung
Netzsicherheit
Sicherstellung einer konsistenten Systemverwaltung
Ist-Aufnahme der aktuellen Netzsituation
Analyse der aktuellen Netzsituation
Entwicklung eines Netzkonzeptes
Entwicklung eines Netzmanagementkonzeptes
Sicherer Betrieb eines Netzmanagementsystems
Sichere Konfiguration der aktiven Netzkomponenten
Festlegung einer Sicherheitsstrategie für ein Client-Server-Netz
Wireless LAN (WLAN)
Remote Access (VPN) - Konzeption
Durchführung einer VPN-Anforderungsanalyse
Entwicklung eines VPN-Konzeptes
Auswahl einer geeigneten VPN-Systemarchitektur
Remote Access (VPN) - Implementierung
Sichere Installation des VPN-Systems
Sichere Konfiguration des VPN-Systems
Sicherer Betrieb des VPN-Systems
Entwicklung eines Firewallkonzeptes
Installation einer Firewall
Sicherer Betrieb einer Firewall
Firewalls und aktive Inhalte
Firewalls und Verschlüsselung
Einsatz von Verschlüsselungsverfahren zur Netzkommunikation
Betriebsmittel und Datenträger
Betriebsmittelverwaltung
Datenträgerverwaltung
Datenträgeraustausch
Informationsaustausch/E-Mail
Richtlinien beim Datenaustausch mit Dritten
Festlegung einer Sicherheitspolitik für E-Mail-Nutzung
Regelung für den Einsatz von E-Mail und anderen Kommunikationsdiensten
Sicherer Betrieb eines E-Mail-Servers
Einrichtung eines Postmasters
Geeignete Auswahl eines E-Mail-Clients/-Servers
Sichere Konfiguration der E-Mail-Clients
Verwendung von „Webmail“ externer Anbietern
Internet, Web, E-Commerce, E-Government
Richtlinien bei Verbindung mit Netzen Dritter (Extranet)
Erstellung einer Internetsicherheitspolitik
Festlegung einer WWW-Sicherheitsstrategie
Sicherer Betrieb eines Webservers
Sicherheit von Webbrowsern
Schutz der WWW-Dateien
Einsatz von Stand-alone-Systemen zur Nutzung des Internets
Sichere Nutzung von E-Commerce- bzw. E-Government-Applikationen
Portalverbundsystem in der öffentlichen Verwaltung
Protokollierung und Monitoring
Erstellung von Protokolldateien
Datenschutzrechtliche Aspekte bei der Erstellung von Protokolldateien
Kontrolle von Protokolldateien
Rechtliche Aspekte bei der Erstellung und Auswertung von Protokolldateien zur E-Mail- und Internetnutzung
Audit und Protokollierung der Aktivitäten im Netz
Intrusion Detection Systeme
Zeitsynchronisation
Zugriffskontrolle, Berechtigungssysteme, Schlüssel- und Passwortverwaltung
Zugriffskontrollpolitik
Grundsätzliche Festlegungen zur Rechteverwaltung
Benutzerverwaltung
Vergabe und Verwaltung von Zugriffsrechten
Einrichtung und Dokumentation der zugelassenen BenutzerInnen und Rechteprofile
Organisatorische Regelungen für Zugriffsmöglichkeiten in Vertretungs- bzw. Notfällen
Verantwortung der BenutzerInnen
Regelungen des Passwortgebrauches
Bildschirmsperre
Fernzugriff
Nutzung eines Authentisierungsservers beim Fernzugriff
Einsatz geeigneter Tunnelprotokolle für die VPN-Kommunikation
Einsatz von Modems und ISDN-Adaptern
Geeignete Modemkonfiguration
Aktivierung einer vorhandenen Callback-Option
Zugriff auf Betriebssysteme
Sichere Initialkonfiguration und Zertifikatsgrundeinstellung
Nutzung der BIOS-Sicherheitsmechanismen
Zugriff auf Anwendungen und Informationen
Wahl geeigneter Mittel zur Authentisierung
Regelungen des Gebrauchs von Chipkarten
Nutzung der in Anwendungsprogrammen angebotenen Sicherheitsfunktionen
Mobile Computing und Telearbeit
Mobile IT-Geräte
Laptop, Notebook, Tablet-PC
PDA (Personal Digital Assistant)
Mobiltelefon, Smartphone
Wechselmedien und externe Datenspeicher (USB-Sticks, -Platten, CDs, DVDs)
Geeignete Einrichtung eines häuslichen Arbeitsplatzes
Regelungen für Telearbeit
Regelung des Dokumenten- und Datenträgertransports zwischen häuslichem Arbeitsplatz und Institution
Geeignete Aufbewahrung dienstlicher Unterlagen und Datenträger
Betreuungs- und Wartungskonzept für Telearbeitsplätze
Geregelte Nutzung der Kommunikationsmöglichkeiten
Regelung der Zugriffsmöglichkeiten von TelearbeiterInnen
Sicherheitstechnische Anforderungen an die Kommunikationsverbindung Telearbeitsrechner - Institution
Sicherheitstechnische Anforderungen an den Kommunikationsrechner
Informationsfluss, Meldewege und Fortbildung
Vertretungsregelung für Telearbeit
Entsorgung von Datenträgern und Dokumenten
Sicherheit in Entwicklung, Betrieb und Wartung eines IT-Systems
Sicherheit im gesamten Lebenszyklus eines IT-Systems
IT-Sicherheit in der Systemanforderungsanalyse
Durchführung einer Risikoanalyse und Festlegung der IT-Sicherheitsanforderungen
IT-Sicherheit in Design und Implementierung
Entwicklungsumgebung
Entwicklung eines Testplans für Standardsoftware
Testen von Software
Abnahme und Freigabe von Software
Installation und Konfiguration von Software
Sicherstellen der Integrität von Software
Lizenzverwaltung und Versionskontrolle von Standardsoftware
Deinstallation von Software
Evaluierung und Zertifizierung
Beachtung des Beitrags der Zertifizierung für die Beschaffung
Einsatz von Software
Nutzungsverbot nicht freigegebener Software
Nutzungsverbot privater Hard- und Softwarekomponenten
Überprüfung des Softwarebestandes
Update von Software
Update/Upgrade von Soft- und Hardware im Netzbereich
Softwarepflege- und -änderungskonzept
Korrekte Verarbeitung
Verifizieren der zu übertragenden Daten vor Weitergabe
Sicherheit von Systemdateien
Systemdateien
Sorgfältige Durchführung von Konfigurationsänderungen
Einsatz kryptographischer Maßnahmen
Entwicklung eines Kryptokonzepts
Bedarfserhebung für den Einsatz kryptographischer Verfahren und Produkte
Auswahl eines geeigneten kryptographischen Verfahrens
Auswahl eines geeigneten kryptographischen Produktes
Regelung des Einsatzes von Kryptomodulen
Physikalische Sicherheit von Kryptomodulen
Schlüsselmanagement
Einsatz elektronischer Signaturen
Zertifizierungsdienste
Wartung
Regelungen für Wartungsarbeiten im Haus
Regelungen für externe Wartungsarbeiten
Fernwartung
Wartung und administrativer Support von Sicherheitseinrichtungen
Sicherheitsvorfälle bzw. Informationssicherheitsereignisse (Incident Handling)
Reaktion auf Sicherheitsvorfälle bzw. sicherheitsrelevante Ereignisse (Incident Handling)
Überlegungen zu Informationssicherheitsereignissen
Festlegung von Verantwortlichkeiten bei Informationssicherheitsereignissen
Erstellung eines Incident Handling-Plans und Richtlinien zur Behandlung von Sicherheitsvorfällen
Prioritäten bei der Behandlung von Sicherheitsvorfällen
Meldewege bei Sicherheitsvorfällen
Behebung von Sicherheitsvorfällen
Eskalation von Sicherheitsvorfällen
Nachbereitung von Sicherheitsvorfällen (Lessons Learned)
Computer Emergency Response Team (CERT)
Disaster Recovery und Business Continuity
Informationssicherheits-Aspekte des betrieblichen Kontinuitätsmanagements
Definition von Verfügbarkeitsklassen
Erstellung einer Übersicht über Verfügbarkeitsanforderungen
Benennung einer/eines Notfallverantwortlichen
Erstellung eines Disaster Recovery-Handbuches
Definition des eingeschränkten IT-Betriebs (Notlaufplan)
Regelung der Verantwortung im Notfall
Untersuchung interner und externer Ausweichmöglichkeiten
Alarmierungsplan
Erstellung eines Wiederanlaufplans
Ersatzbeschaffungsplan
Lieferantenvereinbarungen
Abschließen von Versicherungen
Redundante Leitungsführung
Redundante Auslegung der Netzkomponenten
Umsetzung und Test
Durchführung von Disaster Recovery-Übungen
Übungen zur Datenrekonstruktion
Security Compliance
Security Compliance Checking und Monitoring
Einhaltung von rechtlichen und betrieblichen Vorgaben
Überprüfung auf Einhaltung der Sicherheitspolitiken
Auswertung von Protokolldateien
Kontrolle bestehender Verbindungen
Durchführung von Sicherheitskontrollen in Client-Server-Netzen
Kontrollgänge
Fortlaufende Überwachung der IT-Systeme (Monitoring)
Sicherheitsszenarien
Industrielle Sicherheit
Beschreibung der generellen Anforderungen
Rechtlicher Hintergrund
Ausstellung einer Sicherheitsunbedenklichkeitsbescheinigung
Österreichische Sicherheits- und Verteidigungsdoktrin – Teilstrategie IKT-Sicherheit
Sicherheitsfunktionen für E-Government in Österreich
Konzept und Funktionen der Bürgerkarte
Personenkennzeichen und Stammzahlen
Vollmachten
Module für Online-Applikationen (MOA)
MOA-ID (Identifikation)
MOA-SP (Signaturprüfung)/MOA-SS (Signaturerstellung am Server)
MOA-ZS (Zustellung)
MOA-AS (Amtssignatur)
Portalverbund
Sicherheitstechnologien
Kryptographische Methoden
Elemente der Kryptographie
Kryptographische Grundziele
Verschlüsselung
Integritätsschutz
Authentizitätsnachweise
Digitale Signaturen, elektronische Signaturen
Schlüsselmanagement
Schlüsselverteilungszentralen
Tunneling
Tunnelprotokolle für die VPN-Kommunikation
Virtualisierung
Einführung in die Virtualisierung
Anwendungen der Virtualisierungstechnik
Gefährdungen in Zusammenhang mit Virtualisierung
Planung
Rollen und Verantwortlichkeiten bei der Virtualisierung
Anpassung der Infrastruktur im Zuge der Virtualisierung
Aufteilung der Administrationstätigkeiten bei Virtualisierungsservern
Sichere Konfiguration virtueller IT-Systeme
Sicherer Betrieb virtueller Infrastrukturen
Erstellung eines Notfallplans für den Ausfall von Virtualisierungskomponenten
Cloud Computing
Einleitung
Begriffsdefinition
Charakteristiken von Cloud Computing
Servicemodelle des Cloud Computings
Ausprägungen von Cloud Computing
Rechtliche Aspekte/Auswirkungen/Chancen/Risiken
Grundsätzliches
Datenschutzrecht
Vertragsrecht, Haftung und Gewährleistung
Vergaberecht
Strafprozessrecht
Sonderprobleme
Strukturelle Aspekte/Auswirkungen/Chancen/Risiken
Grundsätzliches
Wirtschaftliche Aspekte/Auswirkungen/Chancen/Risiken
Grundsätzliches
Technische Aspekte/Auswirkungen/Chancen/Risiken und Sicherheit
Technische Aspekte
Zusammenfassung der technischen Aspekte
Sicherheit und Technik
Prozesse (Geschäftsprozesse) - Aspekte / Auswirkungen / Chancen / Risiken / Integration
Grundsätzliches
Strategische Aspekte der Prozessveränderung durch Cloud Computing
Cloud Compliance
Entscheidungskriterien zur Auswahl von Cloud-affinen Anwendungen und Services
Mögliche Cloud Services
Analyse-Logik für die Auswahl von Services, die in eine Cloud-Form migriert werden können
Entscheidungsfindungsprozess
Grundsätzliches
Smartphone Sicherheit
Grundlagen
Komponenten einer Smartphone-Infrastruktur
Assets einer Smartphone Infrastruktur
Sicherheitsrelevante Aspekte von Smartphones
Angriffsarten
Gegenmaßnahmen
Bedrohungsanalyse
Daten
Plattformen
Software
Sensoren
Kommunikation
Zentrale Infrastruktur
Schutzfunktionen
Smartphone Plattform
Kommunikation
Zentrale Infrastruktur
Sicherheit in sozialen Netzen
Einführung
Rechtlicher Hintergrund
Datenschutz
Datensicherheit
Protokollierung von Kommunikation in sozialen Netzen
Monitoring
Crossposting
Risikoassessment
Sicherheitseinstellungen und Umgang mit sozialen Netzen
Richtlinie zur Sicherheit in sozialen Netzen
Verantwortlichkeiten
Maßnahmen zum Umgang mit sozialen Netzen
Anforderungen an den Benutzer
Abmelden des Nutzers / Bildschirmsperre
Passwort Policy
Incident Handling
Awarenessbildende Maßnahmen
Geltungsbereich
Muster für Verträge, Verpflichtungserklärungen und Dokumentationen
Wichtige Normen
Brandschutz
Sicherheitstüren und einbruchhemmende Türen
Wertbehältnisse
Vernichtung von Akten und Daten
Informationssicherheit und IT-Sicherheit
Referenzdokumente
Referenztabellen
Version 2.3 nach Version 3.x und ISO/IEC 27xxx
Referenzierte IKT-Board-Beschlüsse und Gesetze
IKT-Board-Beschlüsse
Gesetzestexte
Wichtige Adressen
XML Sicherheitshandbuch content

Zum Geleit

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. Methodisches Sicherheitsmanagement ist zur Gewährleistung umfassender und angemessener Informationssicherheit unerlässlich.

Das nun neu überarbeitete und neu strukturierte „Österreichische Informationssicherheitshandbuch“ beschreibt und unterstützt die Vorgehensweise zur Etablierung eines umfassenden Informationssicherheitsmanagementsystems in Unternehmen und der öffentlichen Verwaltung. Die grundlegende Überarbeitung und Aktualisierung seit der letzten Fassung aus 2007 führte das Bundeskanzleramt in Kooperation mit dem Zentrum für sichere Informationstechnologie - Austria (A-SIT) durch.

Diese Überarbeitung basiert einerseits auf aktuellen internationalen Entwicklungen im Bereich der Informationssicherheit und andererseits auf Kooperationen mit dem deutschen Bundesamt für Sicherheit in der Informationstechnik (BSI) und dem schweizerischen Informatikstrategieorgan des Bundes (ISB). Dabei wird die bisherige Stärke des Österreichischen Sicherheitshandbuchs, eine eigenständige, umfassende und dennoch kompakte Darstellung von Risken, denen Informationen ausgesetzt sind und Gegenmaßnahmen, welche für österreichische Institutionen relevant sind, weiter ausgebaut. Zusätzlich eignet sich das neue Informationssicherheitshandbuch aufgrund seiner neuen Struktur als konkrete Implementierungshilfe für nationale (E-Government) und internationale Normen (z. B. ISO/IEC 27001 und 27002) in der öffentlichen Verwaltung und der Privatwirtschaft.

Aufbau und Inhalt orientieren sich nun an internationalen Vorgaben und erleichtern damit die Umsetzung von Vorgaben aus der ISO/IEC 27000 Normenreihe. Dazu wurden Maßnahmenbausteine entwickelt, die sowohl von der öffentlichen Verwaltung als auch der Wirtschaft zielgruppenorientiert und einfach verwendet werden können. Der Aufbau des neuen Informationssicherheitshandbuchs ermöglicht auch die Berücksichtigung von Querschnittsmaterien nach Vorgabe durch Fachbereiche aus Verwaltung und Wirtschaft.

Die nun erstmals ausschließlich elektronische Umsetzung in Verbindung mit einer kontinuierlichen Wartung durch definierte Autorengruppen mit fachspezifischen Anforderungen ermöglicht eine Aktualität, die gerade in der Informationsverarbeitung besonders wichtig ist. Unterstützt werden auch eigene, lokale Versionen, wobei weiterentwickelte zentrale Bausteine mit Hilfe automatischer Updates eingespielt werden können.

Österreich besitzt mit dem „Österreichischen Informationssicherheitshandbuch“ ein anerkanntes Standardwerk zur Informationssicherheit, das sich an internationalen Vorgaben orientiert und durch seine Kompaktheit auszeichnet. Es leistet einen wesentlichen Beitrag zur Erstellung und Implementierung von umfangreichen Sicherheitskonzepten in der öffentlichen Verwaltung und versteht sich als Hilfestellung für die Wirtschaft.

Vorwort und Management Summary

Zur Version 3 des Informationssicherheitshandbuchs

Herzlich willkommen bei der Lektüre der Version 3 des „Österreichischen Informationssicherheitshandbuchs“. Sie sehen hier das Ergebnis eines ehrgeizigen internationalen Projekts mit dem Ziel, dem bewährten Österreichischen Informationssicherheitshandbuch nicht nur neue Inhalte, sondern auch neue Einsatzgebiete mit Hilfe von interaktiven Funktionalitäten zu geben. Die markantesten Neuheiten sind:
  • Die bisherige Struktur mit 2 Teilen wurde an die Struktur der Normen ISO/IEC 27001 und 27002 angepasst: Es gibt jetzt einen Teil mit 15 Abschnitten und einer Reihe von Anhängen. Damit wird der Einsatz als Implementierungshilfe für ein Informationssicherheitsmanagementsystem (ISMS) gemäß ISO/IEC 27001 erleichtert.
  • Die technische Realisierung unterstützt nun unterschiedliche Sprachen. Damit kann das Sicherheitshandbuch international genutzt werden.
  • Gleichermaßen werden unterschiedliche Textversionen zum gleichen thematischen Inhalt für verschiedene Zielgruppen unterstützt und entwickelt.
  • Eine moderne Web-Benutzeroberfläche erleichtert die Erarbeitung von lokal erzeugten Auswahl- und Checklisten mit eigenen Kommentaren. Damit können „eigene“ Sicherheitshandbücher und -policies erarbeitet werden.
  • Die inhaltliche Wartung erfolgt nun kontinuierlich, um die Aktualität sicherzustellen.
  • Ein Update-Mechanismus vergleicht lokal ergänzte Themen mit allfälligen Änderungen in der zentralen Wissensbasis.

Die nun vorliegende Version 3.1 ist die erste Auflage in der neuen Struktur und bietet eine vollständige Wissensbasis, bestehend aus Bausteinen der bisherigen zweiteiligen Version und neu verfassten Inhalten. Aufgrund der fortschreitenden Entwicklung der Informationstechnologie wird es ein andauender Prozess sein, jeweils aktuelle Themen und Aspekte in das Informationssicherheitshandbuch einzubringen. Unbeschadet dessen sind wir für Feedbacks der Leser und Anwender dankbar.

Feedbacks zum Sicherheitshandbuch können Sie ganz einfach per E-Mail senden an: siha@a-sit.at
Bleibt noch, Ihnen für Ihr Interesse an der neuen Version zu danken und zu hoffen, dass Sie auch der Meinung sind, dass wir damit einen richtigen Weg einschlagen. Wir, das sind die Projektpartner:
  • Bundeskanzleramt Österreich (BKA)
  • Informatikstrategieorgan des Bundes (ISB), Schweiz
  • Zentrum für sichere Informationstechnologie - Austria (A-SIT) - als Projektverantwortliche

Manfred Holzbach,
redaktioneller Leiter

Management Summary

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

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

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 Handbuchs. Ausgehend von seiner ersten Version („IT-Sicherheitshandbuch für die öffentliche Verwaltung“), die sich am Sicherheitsbedürfnis öffentlicher Einrichtungen orientiert hat, wurde beim „Österreichischen Informationssicherheitshandbuch“ zunehmend dem steigenden Interesse aus der Wirtschaft Rechnung getragen.

Weiterentwicklungen betreffen primär 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 BesitzerInnen der Information wie auch für die potenziell 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 sich die NutzerInnen gerade physisch befinden. Ein vorläufiger Höhepunkt dieser Entwicklung wird erreicht sein, wenn „Cloud Computing“ die geschäftliche und auch private Nutzung der Informationstechnologie durchdrungen haben wird.

Zugleich steigt das Risikopotenzial weiter. 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 Phishing-Angriffe nicht so problematisch - obwohl die Mehrheit der BenutzerInnen über die Gefahren Bescheid weiß.

Ein Sicherheitshandbuch erfüllt seinen Zweck nur, wenn es regelmäßig der aktuellen Entwicklung Rechnung trägt und daher immer wieder überarbeitet, ergänzt und ggf. neu ausgerichtet wird. Mit dieser Motivation wurden mit der nun vorliegenden Version 3 neue Wege beschritten:
  • Ein wesentliches Einsatzgebiet ist die Implementierung der für Informationssicherheit wichtigen Normen ISO/IEC 27001 und 27002. Daher wurde die Kapitelstruktur weitgehende diesen Normen angepasst, und es wird in den Texten auf passende Normvorschriften hingewiesen.
  • Mit einer modernen Benutzeroberfläche kann sowohl einfach durch die Themen geblättert, aber auch eigene Auswahl- und Checklisten („eigene“ Sicherheitshandbücher und -policies, Schulungsunterlagen) erzeugt werden.
  • Die inhaltliche Wartung erfolgt ab jetzt nun kontinuierlich, um die Aktualität sicherzustellen.
  • Es werden unterschiedliche Sprachen unterstützt.

Kernelemente des Informationssicherheitshandbuchs sind der Aufbau, die Umsetzung und die Aufrechterhaltung eines Informationssicherheitsmanagementsystems (ISMS). Ein solches ist in ISO/IEC 27001 definiert als „[…] Teil des gesamten Managementsystems, der auf der Basis eines Geschäftsrisikoansatzes die Entwicklung, Implementierung, Durchführung, Überwachung, Überprüfung, Instandhaltung und Verbesserung der Informationssicherheit abdeckt“ bzw. enthält das Managementsystem die Struktur, Grundsätze, Planungsaktivitäten, Verantwortung, Praktiken, Verfahren, Prozesse und Ressourcen der Organisation. (ISO/IEC 27001, Begriffe 3.7)

Informationssicherheit entsteht nicht von selbst aus Technik oder Know-how, sondern zunächst aus dem Bewusstsein des Managements und der MitarbeiterInnen einer Organisation, dass Informationen schützenswerte und gefährdete Werte für alle Beteiligten darstellen. Daher sind auch kontinuierlich Anstrengungen und Kosten für Informationssicherheit in Kauf zu nehmen, um sie zu erhalten. Es ist aber auch bei der Informationssicherheit nicht sinnvoll, über das Ziel zu schießen: 100 % Sicherheit ist nicht erreichbar, wie viel man auch investiert.

Die für das Informationssicherheitsmanagementsystem (ISMS) relevante Norm ISO/IEC 27001 beschreibt Informationssicherheit als „kontinuierlichen Verbesserungsprozess“ (KVP):
  • Planen (Plan): Festlegen des ISMS; also relevante Sicherheitsziele und -strategien ermitteln, eine organisationsspezifische Informationssicherheitspolitik zu erstellen und spezifisch geeignete Sicherheitsmaßnahmen auswählen.
  • Durchführen (Do): Umsetzen und Betreiben des ISMS; also Sicherheitsmaßnahmen realisieren, für ihre Einhaltung sorgen und Informationssicherheit im laufenden Betrieb inklusive in Notfällen zu gewährleisten.
  • Prüfen (Check): Überwachen und Überprüfen des ISMS auf seine Wirksamkeit; das bedeutet Vorhandensein, Sinnhaftigkeit, Einhaltung der Sicherheitsmaßnahmen zu überprüfen, aber auch Kenntnis über Vorfälle sowie üblicher Good-Practices zu erlangen.
  • Handeln (Act): Instandhalten und Verbessern des ISMS; das bedeutet auf erkannte Fehler, Schwachstellen und veränderte Umfeldbedingungen zu reagieren und die Ursachen für Gefährdungen zu beseitigen. Dies bedingt erneutes Planen, womit sich ein ständiger Kreislauf schließt.

Inhalt und Struktur des Informationssicherheitshandbuchs sind an die ISO/IEC-Normen 27001 und 27002 angepasst:
  • ISO/IEC 27001 (Informationssicherheitsmanagementsysteme – Anforderungen) beschreibt die für die Einrichtung, Umsetzung, Durchführung, Überwachung, Überprüfung, Instandhaltung und Verbesserung eines Informationssicherheitsmanagementsystems relevanten Anforderungen. Im Informationssicherheitshandbuch wird darauf in den Kapiteln 2 und 3 Bezug genommen: sie beschreiben den grundlegenden Vorgang, Informationssicherheit in einer Behörde, Organisation bzw. einem Unternehmen zu etablieren und bieten konkrete Anleitungen den umfassenden und kontinuierlichen Sicherheitsprozess zu entwickeln.
  • ISO/IEC 27002 (Leitfaden für das Informationssicherheitsmanagement) beschreibt konkrete Empfehlungen für Aktivitäten zur Realisierung der Maßnahmenziele. Im Informationssicherheitshandbuch beziehen sich die Kapitel 4 bis 15 darauf und entsprechen in ihrer Thematik auch den Kapiteln der Norm. Es werden hier konkrete und detaillierte Einzelmaßnahmen mit Anleitungen zu ihrer korrekten Implementierung auf organisatorischer, personeller, infrastruktureller und technischer Ebene beschrieben. Damit können den spezifischen Bedrohungen angemessene Standardsicherheitsmaßnahmen für Informationssysteme und Informationen entgegengesetzt werden. Es wird auch 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 eigener Abschnitt im Anhang A beschreibt national relevante Sicherheitsmaßnahmen, die nicht in den ISO-Normen abgedeckt sind, wie beispielsweise die „Industrielle Sicherheit“ - dargestellt wird hier die Unterstützung für die Erstellung einer Sicherheitsunbedenklichkeitsbescheinigung und eine Übersicht aller für industrielle Sicherheit relevanten Vorgabedokumente aus dem nationalen, dem EU- und dem NATO-Bereich.

In den Anhängen finden sich schließlich ausgewählte Technologie- und Szenariobeschreibungen sowie Musterdokumente, Literaturhinweise und Hilfsmittel wie Referenzen.

Ausrichtung und Umfang

Von der Ausrichtung versteht sich das Informationssicherheitshandbuch nach wie vor als Sammlung von Leitlinien und Empfehlungen für die Praxis, die entsprechend den spezifischen Anforderungen und Bedürfnissen in einer Einsatzumgebung angepasst werden müssen. Dies wird auch durch die Online-Funktionalitäten wie Checklisten unterstützt. Es soll eine Ergänzung zu den bestehenden Regelungen und Vorschriften (Datenschutzgesetz, Informationssicherheitsgesetz, Verschlusssachenvorschriften, Amtsgeheimnis, …) darstellen und setzt diese weder außer Kraft noch steht es zu ihnen im Widerspruch.

Sein Umfang soll nach wie vor zwei an sich gegenläufige Aspekte vereinen:
  • Die Themen sollen ausreichend konkret und detailliert dargestellt werden, um sie auch in der Tiefe zu verstehen und Maßnahmen (etwa Produkte auswählen, Vorgaben entwickeln) implementieren zu können.
  • Es soll aber auch möglich bleiben, das Gesamtwerk oder größere Teile am Stück zu lesen.

Abschließend drei managementrelevante Passagen (aus Kapitel 3):
  • „Zur Verantwortung der Managementebene gehört neben der Erreichung der geschäftlichen wie unternehmenspolitischen Ziele auch der angemessene Umgang mit Risiken. Sie müssen so früh wie möglich erkannt, eingeschätzt, bewertet und durch Setzen geeigneter und nachhaltiger Maßnahmen auf einen minimalen und akzpetierten Rest reduziert werden. Wegen der immer höheren Abhängigkeit von Information gilt dies besonders für Risiken aus fehlender oder mangelhafter Informationssicherheit.“
  • „Es ist daher eine Managementverantwortung, einen systematischen und dauerhaften Sicherheitsmanagementprozess zu etablieren, zu steuern und zu kontrollieren“
  • „Ein angestrebtes Sicherheitsniveau ist nur dann sinnvoll, wenn es sich wirtschaftlich vertreten lässt und mit den verfügbaren personellen, zeitlichen und finanziellen Ressourcen auch erreicht werden kann.“

Hauptquellen und Danksagungen

Schon lange wurden und werden auf nationaler und internationaler Ebene immer mehr Anstrengungen unternommen, einheitliche methodische Vorgehensweisen zur Etablierung von Informationssicherheit sowie Standardmaßnahmenkataloge zu erarbeiten. Davon sind die Normenreihe ISO/IEC 27000 und der Grundschutz des deutschen Bundesamtes für Sicherheit in der Informationstechnik (BSI) wohl die bekanntesten und bedeutendsten. Ebenso etabliert ist die Arbeit von MELANI (Melde- und Analysestelle Informationssicherung) in der Schweiz und CASES (Cyberworld Awareness Security Enhancement Structure; Luxembourg) in Luxemburg. Im Informationssicherheitshandbuch wurde diesen internationalen Entwicklungen so weit wie möglich Rechnung getragen und auf einige dieser bewährten Quellen zurück gegriffen, wie dann in den einzelnen Textbausteinen auch angeführt. Weiters waren auch die Vorgabedokumente der EU und NATO für Informationssicherheit maßgeblich.

Ausgesprochenen Dank sprechen wir den Organisationen und ihren maßgeblichen Partnern aus, die uns nicht nur ihre Zustimmung zur Nutzung ihrer Unterlagen gegeben, sondern uns bei der Erarbeitung immer wieder mit Rat und Ermunterung unterstützt haben:
  • Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn, Deutschland;
  • Informatikstrategieorgan des Bundes (ISB), Bern, Schweiz;
  • Ministére de l'Economie et du Commerce extérieur, Luxembourg

1 Einführung

1.1 Das Informationssicherheitshandbuch

1.1.1 Ziele des Informationssicherheitshandbuchs

Das „Österreichische Informationssicherheitshandbuch“ positioniert sich in der Mitte zwischen den normativen Vorgaben der ISO/IEC-Normen 27001/27002 und verwandter Standards sowie der Fülle an sehr detaillierten Leitfäden und Handbüchern zur Informationssicherheit, beispielsweise den Grundschutzstandards und -bausteinen des BSI. Einerseits ist es durchaus im Stil einer Vorschrift formuliert, um notwendige Überlegungen und Maßnahmen klar und unzweifelhaft zu darzustellen, andererseits bietet es eine Auswahl an Möglichkeiten und Entscheidungskriterien für die Implementierung in der Praxis. Dabei wurde allerdings auf die die gebotene Kompaktheit geachtet.

Implementierungshilfe zu ISO/IEC 27001:

Viele Organisationen müssen oder wollen IT-Sicherheit gemäß der Norm ISO/IEC 27001 und nachgelagerter Normen etablierten bzw. sicherstellen und ggf. auch zertifizieren lassen. Das Sicherheitshandbuch bietet dazu:
  • Gemäß der Norm geordnete Interpretation der Vorgaben und Prozessbeschreibungen, um den Sicherheitsmanagement-Prozess zu etablieren und aufrecht zu erhalten: „welche Überlegungen sind anzustellen, welche Aktivitäten sind zu planen und zu entscheiden, wo ist Kontrolle nötig?“
  • einen Katalog von konkreten Sicherheitsmaßnahmen, die ausgewählt, umgesetzt und und eingehalten werden sollen: „was gibt es dazu, wie wird es gemacht, worauf ist zu achten?“
Hier ermöglicht es die Auswahl- und Checklistenfunktionalität etwa, ein „maßgeschneidertes“ Sicherheitshandbuch abzuleiten und in Kommentaren die tatsächlich notwendigen Maßnahmen zu beschreiben.

Instrument zur Schulung und Weiterbildung:

  • Die Wissensbasis stellt insgesamt ein ganzheitliches und dennoch kompaktes Werk zur Informationssicherheit dar,
  • hat das Potenzial zielgruppengerecht unterschiedlicher Textierungen,
  • eignet sich auch zum Lesen bzw. Durcharbeiten „am Stück“,
  • und eignet sich daher sowohl als Basis für Schulungs- und Weiterbildungsmaßnahmen bzw. -medien; sowohl modular als auch im Ganzen.
Dafür kann der Inhalt mit der Auswahl- und Checklistenfunktionalität auf die relevanten Themen eingeschränkt und in den Kommentaren etwa Fragen und Antworten dargestellt weren.

Hilfsmittel für Self-Checks:

Als Hilfsmittel für Audits, aber auch einfach zur Selbstkontrolle können die notwendigen Schritte und Maßnahmen ausgewählt und dann mit der Checklistenfunktion der Grad der Erfüllung mitsamt Begründungen festgehalten werden.

1.1.1.1 Ziele der Version 3

Der Relaunch als Version 3 ist motiviert einerseits von der Entwicklung und steigenden Bedeutung der Normenreihe ISO/IEC 27001/27002, andererseits von Erfahrungen und Wünschen der BenutzerInnen der bisherigen Version 2.3 nach flexiblerer Themenauswahl sowie der Möglichkeit zur Formulierung zielgruppengerechter Textierungen. Letzteres wurde vor allem als Wunsch der Wirtschaft geäußert, gilt sinngemaß auch beispielsweise für Schulen. Mit einer Neugestaltung der Datenstruktur und neu entwickelten Zugriffs- und Darstellungsmodulen wurde dem Rechnung getragen.
Es hat sich gezeigt, dass das „Österreichische Informationssicherheitshandbuch“ auch in anderen Ländern beachtet wird. Speziell aus der Schweiz kam der Vorschlag, die Möglichkeit für länderspezifische Varianten - wobei Basiswissen gemeinsam verwaltet werden soll - zu schaffen. Damit verknüpft ist konsequenterweise die Mehrsprachigkeit. Somit kam es auch zur Mitwirkung des schweizerischen ISB am Relaunch-Projekt.

Wichtigstes Ziel der Neuauflage ist selbstverständlich, die Verwendung und Verbreitung des Informationssicherheitshandbuchs zu fördern.

1.1.2 Anwendungsbereich (Scope)

Inhaltlich behandelt das vorliegende Handbuch den gesamten Bereich der Informationssicherheit. Wenn auch ein Schwerpunkt auf IT-gestützter Information liegt, wird Information dennoch umfassend gesehen: in elektronisch gespeicherter oder übertragener Form; sowie auch als schriftliche, gesprochene oder bildhaft dargestellte Informationen.
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 kann nicht immer eindeutig sein, oft gibt es Überschneidungen zwischen den einzelnen Themen. Ist es doch ein Zeil des Handbuchs, Problem- und Lösungspotenzial aus der und für die Praxis zu geben.

Empfehlungen für bestimmte Produkte werden nicht gegeben, und nach Möglichkeit werden Produkt- und Markennamen vermieden. Ausnahmen gibt es allerdings dort, wo die Durchdringung so groß ist, dass das Produkt schon ein Synonym für die Implementierung darstellt, oder ein Produkt ausgesprochen spezifische Sicherheitseigenschaften aufweist bzw. kostenlos angeboten wird.

1.1.3 Neuheiten der Version 3

Struktur

Anpasssung an ISO/IEC 27001/27002: Anstelle der bisher 2 Hauptteile (Sicherheitsmanagement und Sicherheitsmaßnahmen) gibt es jetzt nach dem Management-Summary 15 Abschnitte und eine Reihe von Anhängen:
  • Abschnitt 1 ist eine Einführung sowohl für die Handhabung des Handbuchs als auch in die grundsätzliche Thematik,
  • Abschnitte 2 und 3 beschreiben die für Einrichtung, Umsetzung, Durchführung, Überwachung, Überprüfung, Instandhaltung und Verbesserung eines Informationssicherheitsmanagementsystems relevanten Anforderungen gemäß ISO/IEC 27001 4, 5, 6, 7, 8): es handelt sich dabei um den grundlegenden Vorgang, Informationssicherheit in einer Behörde, Organisation bzw. einem Unternehmen zu etablieren und diese Abschnitte bieten konkrete Anleitungen, den umfassenden und kontinuierlichen Sicherheitsprozess zu entwickeln.
  • Abschnitte 4 bis 15 beschreiben die konkreten Sicherheitsmaßnahmen inkl. der Aktivitäten zu ihrer Umsetzung und Einhaltung. Sie entsprechen in ihrer Reihenfolge und generellen Thematik den Empfehlungen gemäß ISO/IEC 27002 bzw. dem Anhang zu ISO/IEC 27001 - allerdings gibt es keine 1:1-Entsprechung auf der Ebene der einzelnen Details (Textbausteine). Sie erörtern konkrete und detaillierte Einzelmaßnahmen und Anleitungen zu ihrer korrekten Implementierung wärend ihres gesamten Lebenszyklus auf organisatorischer, personeller, infrastruktureller und technischer Ebene. Es wird allerdings auch auf spezifisch österreichische Anforderungen, Regelungen und Rahmenbedingungen eingegangen.
  • In den einzelnen Themenbausteinen werden - soferne zutreffend - Bezüge zu den jeweils zugehörigen Kapiteln der ISO/IEC-Normen 27001 und 27002 dargestellt.
  • In den Anhängen finden sich ausgewählte Szenarien und Technologien losgelöst von zu setzenden Maßnahmen, Muster für Verträge, Anweisungen, Referenzen zu Normen, Gesetzen und verwandter Literatur sowie Quellenhinweise.
Damit geht eine neue Nummerierung der Kapitel und Textbausteine einher.

Inhalte

  • Um alle Themen laut ISO/IEC 27001/27002 abzudecken, gibt es nun neue Kapitel bzw. Themenbausteine etwa zu „Outsourcing“, „Umgang mit Vermögenswerten“, „Interne Audits“, „Verbesserungsprozess“
  • Neue und geänderte Themenbausteine zu veränderten Technologien oder Gefährdungen werden nunmehr kontinuierlich eingearbeitet, bzw. obsolete eleminiert.

Datenbasis (Online-Version)

  • Jeder Textbaustein kann künftig in mehreren unterschiedlichen Ausprägungen (Formulierungen, Vereinfachungen) vorhanden sein und mittels Filteroptionen ausgewählt werden. Damit werden zielgruppenorientierte Darstellungen unterstützt.
  • Filteroptionen werden sowohl für Einsatzgebiete (z. B. Government/Wirtschaft) als auch für Rollen Leserkreise (z. B. Management/Watungspersonal/BenutzerInnen) entwickelt. Die Filterregeln sind nicht a priori festgeschrieben, sondern Gegenstand von Vereinbarungen (in zentralen Autorengruppen oder individuellen Implementierungen) und damit flexibel für Erweiterungen.
  • Mit Filteroptionen werden auch unterschiedliche Sprachen ermöglicht.
  • Links zu österreichischen Gesetzen führen direkt zum entsprechenden Gesetzestext im Rechtsinformationssystem (RIS).
  • Die Datenbasis besteht aus einem Satz von XML-Dateien (extended Markup Language), die mittels geeigneter Transformationen in andere gängige Darstellungs- (HTML - Hypertext Markup Language) oder Textformate (RTF - Rich Text Format, PDF - Portable Document Format) umgewandelt werden können.

Funktionalität (Online-Viewer)

Der neu entwickelte Online-Viewer läuft in einem Standard-Browser und benötigt abgesehen vom Vorhandensein einer Javascript-Unterstützung keine Installation. Er bietet als Hauptfunktionalitäten:
  • Blättern (Browse) im Sicherheitshandbuch: Das kann seriell vom Anfang bis zum Ende, aber auch durch gezielten Sprung auf Kapitel oder Textbausteine erfolgen.
  • Filteroptionen für Einsatzgebiete, Branchen, Rollen, Leserkreise sowie unterschiedliche Sprachen.
  • Zusammenstellung einer Liste, das heißt einer individuelle Auswahl von Themen (ganze Kapitel, Unterkapitel oder Textbausteine). Sie kann lokal abgespeichert und wieder geladen werden.
  • Zusammenstellung einer Checkliste, das ist eine individuelle Auswahl mit der Möglichkeit, pro Textbaustein Checkboxen anzukreuzen sowie Kommentare zu verfassen und lokal abzuspeichern. Einsatzgebiete für Auswahl- oder Checklisten sind beispielsweise das Erstellen eigener Policies, Schulungsunterlagen, Statusberichte (Erfüllungsgrad von Maßnahmen), Self-Checks und Querschnittsmaterien.
  • Druck von Auswahl- oder Checklisten (Online-Version).
  • Transformation von Auswahl- oder Checklisten in PDF-Textdateien.

Update Funktion

Mit ihrer Hilfe können lokal abgespeicherte und verwendete Auswahl- oder Checklisten aktuell gehalten werden:
  • Die lokale Liste enthält mehrere Kapitel oder Bausteine aus der Wissensbasis, die sich inzwischen geändert haben könnten (anhand ihrer jeweiligen Versionsnummer).
  • Beim Blättern in der Liste wird ein entsprechender Warnhinweis gegeben.
  • Wenn gewünscht, können die neuen Versionen aus der Wissensbasis in die lokale Liste übernommen werden.

1.1.4 Quellen, Verträglichkeiten, Abgrenzungen

Normenfamilie ISO/IEC 27000

Aufgrund der Komplexität von Informationstechnik und der Nachfrage nach Zertifizierung sind in den letzten Jahren zahlreiche Anleitungen, Standards und nationale Normen zur Informationssicherheit entstanden. Die internationale Normenfamillie ISO/IEC 27000 gibt einen allgemeinen Überblick über Managementsysteme für Informationssicherheit (ISMS) und über die Zusammenhänge ihrer verschiedenen Einzelnormen. Es finden sich hier die grundlegenden Prinzipien, Konzepte, Begriffe und Definitionen für solche Managementsysteme:
  • Der Standard ISO/IEC 27001 „Information technology - Security techniques - Information security management systems requirements specification“ ist der erste internationale Standard zum Informationssicherheitsmanagement, der auch eine Zertifizierung ermöglicht. ISO/IEC 27001 gibt in 5 konkreten Kapiteln (4, 5, 6, 7, 8) allgemeine Empfehlungen für Managementaktivitäten, um ein ISMS zu planen, etablieren, zu betreiben, zu überwachen und laufend zu verbessern. Ein normativer Anhang verweist auf die Umsetzung gemäß ISO/IEC 27002; ISO/IEC 27001 bietet keine Hilfe für die praktische Umsetzung.
  • ISO/IEC 27002 (vormals ISO 17799) „Information technology – Code of practice for information security management“ befasst sich als Rahmenwerk für das Informationssicherheitsmanagement hauptsächlich mit den erforderlichen Schritten, um ein funktionierendes Informationssicherheitsmanagement aufzubauen und in der Organisation zu verankern. Die erforderlichen Informationssicherheitsmaßnahmen werden eher kurz auf ca. 100 Seiten skizzert angerissen. Die Empfehlungen sind für Managementebenen formuliert und enthalten nur wenige konkrete technische Hinweise. Ihre Umsetzung ist auch nur eine von vielen Möglichkeiten, die Anforderungen des ISO/IEC-Standards 27001 zu erfüllen.
  • ISO/IEC 27005 „Information security risk management“ enthält Rahmenempfehlungen zum Risikomanagement für Informationssicherheit. Unter anderem unterstützt er bei der Umsetzung der Anforderungen aus ISO/IEC 27001. Es wird allerdings keine spezifische Methode für das Risikomanagement vorgegeben. ISO/IEC 27005 löst den bisherigen Standard ISO 13335-2 ab.
  • Weitere Standards der ISO/IEC 27000 Reihe: Langfristig wird die Normenreihe ISO/IEC 27000 voraussichtlich aus den Standards 27000 –27019 und 27030-27044 bestehen. Alle Standards dieser Reihe behandeln verschiedene Aspekte des Sicherheitsmanagements und beziehen sich auf die Anforderungen der ISO/IEC 27001. Die weiteren Standards sollen zum besseren Verständnis und zur praktischen Anwendbarkeit der ISO/IEC 27001 beitragen und beschäftigen sich beispielsweise mit der praktischen Umsetzung der ISO/IEC 27001, also der Messbarkeit von Risiken oder mit Methoden zum Risikomanagement.
Das Informationssicherheitshandbuch geht in Aufbau, Struktur und Abhandlung der generellen Themen konform mit ISO/IEC 27001 und 27002, bietet allerdings in einer kompakten Form auch technische und organisatorische Hinweise und Ratschläge zur Implementierung.

BSI Grundschutz Standards und Maßnahmenbausteine

  • Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) bietet seit 1994 zunächst mit dem Grundschutzhandbuch, später mit den Grundschutz-Standards und Maßnahmenbausteinen eine umfassende und äußerst detaillierte Informationsbasis und daraus etablierte Methoden für eine Vorgehensweise zum Aufbau einer Sicherheitsorganisation sowie für die Risikobewertung, die Überprüfung des vorhandenen Sicherheitsniveaus und die Implementierung der angemessenen Informationssicherheit.
  • Sie hat sich als ganzheitliches Konzept für Informationssicherheit und als Standard etabliert; und das BSI bietet ISO/IEC 27001 Zertifzierungen nach IT-Grundschutz an. Unterschiedliche Zielgruppen werden durch jeweils separate Entwicklungen unterstützt. So richtet sich etwa „BSI für Bürger“ mit kurzen und einfach formulierten Darstellungen an Privatpersonen und KMUs.
Das Österreichische Informationssicherheitshandbuch wird auf Basis einer gelebten Kooperation mit dem BSI immer wieder mit neuen Entwicklungen bei den Grundschutz-Standards und -Bausteinen abgeglichen. Teilweise grenzt es sich diesen gegenüber vor allem durch eine kompaktere Darstellungsweise ab, die mittleren und kleineren Organisationseinheiten entgegenkommt und das Durcharbeiten des Informationssicherheitshandbuchs „am Stück“ nach wie vor ermöglicht. Seine neuen Funktionalitäten wie unterschiedlich formulierte Textbausteine verfolgen auf eigene Weise das Ziel der Ansprache unterschiedlicher Zielgruppen.

MELANI (Melde- und Analysestelle Informationssicherung)

Im Rahmen von MELANI wird in der Schweiz ein CERT (Computer Emergency Response Team) betrieben, aber auch auf einer Homepage Informationen über Gefahren und Maßnahmen, Checklisten, Lageberichte und Schulungsmaßnahmen geboten. Der Anspruch richtet sich auf gezielte und aktuelle Darstellung vor allem von Gefahren und Fehlverhalten, wobei keine ausgesprochenen Zielgruppen definiert sind; beispielsweise wird den Problemen, denen Banken und Finanzinstitutionen ausgesetzt sind, breiter Raum gegeben.
Das Informationssicherheitshandbuch behandelt zum Teil eine ähnliche Thematik, positioniert sich dabei stark an der Implementierung und muss dem Anspruch, sämtliche relevanten Themen anszusprechen, genügen.

CASES (Cyberworld Awareness Security Enhancement Structure

Die vom luxemburgischen Ministerium für Wirtschaft und Außenhandel betriebene Homepage „CASES“ ist in deutscher und französischer Sprache verfügbar und richtet sich zum einen an Klein- und Mittelbetriebe, zum anderen an Schüler und deren Eltern. Auf sehr einfachen und anschaulichen Webseiten wird eine umfassende Darstellung der wesentlichsten Gefahren und Sicherheitsmaßnahmen geboten, Basistechnologien anschaulich beschrieben und auch Anleitungen zur Ausarbeitung einer Sicherheitspolitik speziell für kleine Organisationen gegeben.
Das Informationssicherheitshandbuch hat sich aus dem „IT-Sicherheitshandbuch für die öffentliche Verwaltung“ entwickelt und hat somit bisher als Zielgruppen mittlere bis größere Institutionen mit Bedarf nach knapper, aber vorschrift-ähnlicher Darstellung angesprochen. Mit Hilfe seiner neuen Funktionalitäten wie unterschiedlich formulierbarer Textbausteine und einer informell bereits aufgenommenen Kooperation werden sich nunmehr auch einige Inhalte von CASES im Informationssicherheutshandbuch finden.

1.1.5 Informations- versus IT-Sicherheit

Die 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 und nicht zuletzt in den Normen hat sich in den letzten Jahren eher der Begriff „Informationssicherheit“ als der umfassendere etabliert - daher auch der Name „Informationssicherheitshandbuch“.
[Quelle: BSI Leitfaden Informationssicherheit]

1.2 Informationssicherheitsmanagement

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.
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.
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. 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.
[eh Teil 1 - 1]

1.2.1 Ziele des Informationssicherheitsmanagements

ISO Bezug: 27001 0, 4

Informationssicherheit entsteht nicht von selbst aus Technik oder Know-how, sondern zunächst aus dem Bewußtsein des Management und der MitarbeiterInnen einer Organisation, dass Informationen schützenswerte und gefährdete Werte für alle Beteiligten darstellen. Daher sind auch kontinuierlich Anstrengungen und Kosten für Informationssicherheit in Kauf zu nehmen, um sie zu erhalten. Es muss allerdings ebeso bewusst sein, dass 100 % Sicherheit nicht erreicht werden kann, wie viel man auch investiert. Ziel muss es also sein, ein angemessenes Sicherheitsniveau zu erreichen und dauerhaft zu erhalten.

Durch Etablieren und Erhalten eines Informationssicherheitsmanagementsystems (ISMS) sollen die grundlegenden Ziele der Informationssicherheit erreicht werden:
  • Integrität: Informationen dürfen nur von den vorgesehenen Personen und Prozessen verändert werden,
  • Vertraulichkeit: Informationen dürfen nur für die vorgesehenen Personen und Prozesse offen gelegt werden,
  • Verfügbarkeit: Informationen müssen für die vorgesehenen Personen und Prozesse bereitgestellt sein, wenn diese sie benötigen
Das klingt selbstverständlich und einfach, ist in der Praxis allerdings eine Herausfoderungen für die Organisation, da die Informationen vielfältigsten Gefahren ausgesetzt sind:
  • So ist Integrität von technischen Fehlern, unbefugten Manipulationsversuchen (auch etwa Viren, Würmer), Fahrlässigkeit etc. bedroht,
  • die Vertraulichkeit ist durch Spionageaktivitäten, Datenmißbrauch, aber ebenso von Fehlern und Schlamperei gefährdet,
  • die Verfügbarkeit kann von kleineren und größeren Systemausfällen (z. B. durch Brände oder Katastrophen), aber auch bewußten DoS-Attacken (Denial-of-Service) - bis zum Stillstand - reduziert werden.
[eh Teil 1 - 1.1]

1.2.2 Aufgaben des Informationssicherheitsmanagements

ISO Bezug: 27001 0, 4

Informationssicherheit ist immer eine Managementaufgabe. Nur wenn die Leitung einer Organisation voll hinter den Sicherheitszielen und den damit verbundenen Aktivitäten steht, kann diese Aufgabe erfolgreich wahrgenommen werden.
Die für das Informationssicherheitsmanagement relevante Norm 27001 beschreibt Informationssicherheit als „kontinuierlichen Verbesserungsprozess“ (KVP) in einem Informationssicherheitsmanagementsystem (ISMS) nach dem „Plan-Do-Check-Act“-Modell (PDCA – „Planen, Durchführen, Prüfen, Handeln“):
  • Planen (Plan): Festlegen des ISMS; also relevante Sicherheitsziele und -strategien ermitteln, eine organisationsspezifische Informationssicherheitspolitik erstellen und spezifisch geeignete Sicherheitsmaßnahmen auswählen.
  • Durchführen (Do): Umsetzen und Betreiben des ISMS, also Sicherheitsmaßnahmen realisieren, für ihre Einhaltung sorgen und Informationssicherheit im laufenden Betrieb inklusive in Notfällen gewährleisten.
  • Prüfen (Check): Überwachen und Überprüfen des ISMS auf seine Wirksamkeit, also Vorhandensein, Sinnhaftigkeit, Einhaltung der SIcherheitsmaßnahmen überprüfen, aber auch Kenntnis über Vorfälle sowie üblicher Good-Practices erlangen.
  • Handeln (Act): Instandhalten und Verbessern des ISMS, das bedeutet auf erkannte Fehler, Schwachstellen und veränderte Umfeldbedingungen reagieren und die Ursachen für Gefährdungen beseitigen. Dies bedingt erneutes Planen, womit sich ein ständiger Kreislauf schließt.

Am Beginn stehen Sicherheitsziele, also Erwartungen und Anforderungen der Verantwortlichen und Beteiligten. Durch die Planungs-, Durchführungs-, Prüf- und Verbesserungsprozesse bzw. -handlungen werden sie erfüllt - das schließlich akzeptierte Sicherheitsniveau wird erreicht.

Informationssicherheitsmanagement ist also ein kontinuierlicher Prozess. In den folgenden Kapiteln wird dargestellt, welche Aufgaben eines ISMS umgesetzt und welche Sicherheitsmaßnahmen implementiert werden können zur:
  • Festlegung der Sicherheitsziele und -strategien der Organisation,
  • Ermittlung und Bewertung der Informationssicherheitsrisiken (information security risk assessment),
  • Festlegung geeigneter Sicherheitsmaßnahmen,
  • Überwachung der Implementierung und des laufenden Betriebes der ausgewählten Maßnahmen,
  • Förderung des Sicherheitsbewusstseins innerhalb der Organisation sowie
  • Entdeckung von und Reaktion auf sicherheitsrelevante Ereignisse (information security incident handling).
[eh Teil 1 - 1.1]

2 Informationssicherheitsmanagementsystem (ISMS)

Dieses Kapitel nimmt vor allem Bezug auf ISO/IEC 27001 4 „Informationssicherheitsmanagementsystem“ sowie ISO/IEC 27002 4 „Risikobewertung und -behandlung“.

2.1 Der Informationssicherheitsmanagementprozess

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

Zentrale Aktivitäten im Rahmen des ISMS sind:
  • die Entwicklung einer organisationsweiten Informationssicherheitspolitik
  • die Durchführung einer Risikoanalyse
  • die Erstellung eines Sicherheitskonzeptes
  • die Umsetzung der Sicherheitsmaßnahmen
  • die Gewährleistung der Informationssicherheit im laufenden Betrieb
  • die kontinuierliche Überwachung und Verbesserung des ISMS

Der nachfolgend dargestellte Prozess basiert auf internationalen Standards und Leitlinien zum Informationssicherheitsmanagement, insbesondere den [ISO/IEC 27001], sowie auch noch den „Guidelines on the Management of IT Security (GMITS)“ ( [ISO/IEC 13335]). Er kann sowohl auf eine gesamte Organisation als auch auf Teilbereiche Anwendung finden.

Ü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.
Das nachfolgende Bild zeigt die wichtigsten Aktivitäten im Rahmen des Informationssicherheitsmanagements und die eventuell erforderlichen Rückkopplungen zwischen den einzelnen Stufen.
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 unterschiedliche Organisationseinheiten (Behörden, Unternehmen, Abteilungen, …) gemeint sein können.

Abbildung 1: Aktivitäten im Rahmen des Informationssicherheitsmanagements

Informationssicherheitsmanagement umfasst damit die folgenden Schritte:

2.1.1 Entwicklung einer organisationsweiten Informationssicherheitspolitik

ISO Bezug: 27001 4.1

Als organisationsweite Informationssicherheitspolitik (Corporate Information Security Policy) 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.
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.
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.
[eh Teil 1 - 2]

2.1.2 Risikoanalyse

ISO Bezug: 27001 4.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 Handbuchs werden drei Risikoanalysestrategien behandelt (siehe 4 Risikoanalyse): 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.
[eh Teil 1 - 2]

2.1.3 Erstellung eines Sicherheitskonzeptes

ISO Bezug: 27001 4.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.
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.
In einem Informationssicherheitsplan werden alle kurz-, mittel- und langfristigen Aktionen festgehalten, die zur Umsetzung der ausgewählten Maßnahmen erforderlich sind.
Der Vorgang wird im Detail in 2.2 Erstellung von Sicherheitskonzepten behandelt.
[eh Teil 1 - 2]

2.1.4 Umsetzung des Informationssicherheitsplans

ISO Bezug: 27001 4.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 Informationssicherheitsplans 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.
2.3 Umsetzung des Informationssicherheitsplanes behandelt diese Umsetzungsfragen.
[eh Teil 1 - 2]

2.1.5 Informationssicherheit im laufenden Betrieb

ISO Bezug: 27001 4.1

Umfassendes Informationssicherheitsmanagement beinhaltet nicht zuletzt auch die Aufgabe, die Sicherheit im laufenden Betrieb aufrechtzuerhalten und gegebenenfalls veränderten Bedingungen anzupassen.
Zu den erforderlichen Follow-Up-Aktivitäten zählen (siehe 2.4 Informationssicherheit im laufenden Betrieb):
  • Die Aufrechterhaltung des erreichten Sicherheitsniveaus
    Dies umfasst:
    • Wartung und administrativen Support von Sicherheitseinrichtungen
    • die Messung der Effektivität der ausgewählten Sicherheitsmaßnahmen anhand definierter Kennzahlen (Information Security Measurement)
    • die Überprüfung von Maßnahmen auf Übereinstimmung mit der Informationssicherheitspolitik (Security Compliance Checking) sowie
    • die fortlaufende Überwachung der IT-Systeme (Monitoring)
  • umfassendes Change-Management
  • eine angemessene Reaktion auf sicherheitsrelevante Ereignisse (Incident Handling)
[eh Teil 1 - 2]

2.2 Erstellung von Sicherheitskonzepten

ISO Bezug: 27001 4.2.2, 27002 4.1, 7.1.1, 7.2.1

Ausgehend von den in der Risikoanalyse (siehe 4 Risikoanalyse) ermittelten Sicherheitsanforderungen wird ein Sicherheitskonzept erstellt. Dies erfolgt durch die Auswahl geeigneter Maßnahmen, die die Risiken auf ein akzeptables Maß reduzieren und unter dem Gesichtspunkt von Kosten und Nutzen eine optimale Lösung darstellen.
Ein Sicherheitskonzept enthält:
  • die Beschreibung des Ausgangszustands einschließlich der bestehenden Risiken (Ergebnisse der vorangegangenen Risikoanalyse)
  • die Festlegung der durchzuführenden Maßnahmen
  • die Begründung der Auswahl unter Kosten/Nutzen-Aspekten und hinsichtlich des Zusammenwirkens der einzelnen Maßnahmen
  • eine Abschätzung des Restrisikos sowie eine verbindliche Aussage über die Akzeptanz des verbleibenden Restrisikos
  • die Festlegung der Verantwortlichkeiten für die Auswahl und Umsetzung der Maßnahmen sowie für die regelmäßige Überprüfung des Konzeptes
  • eine Prioritäten-, Termin- und Ressourcenplanung für die Umsetzung

Die Erstellung eines Sicherheitskonzeptes erfolgt in vier Schritten:
  • Schritt 1: Auswahl von Maßnahmen
  • Schritt 2: Prüfung von Restrisiken und Risikoakzeptanz
  • Schritt 3: Erstellung von Sicherheitsrichtlinien
  • Schritt 4: Erstellung eines Informationssicherheitsplans
Diese vier Schritte werden in den folgenden Kapiteln näher beschrieben.

2.2.1 Auswahl von Maßnahmen

ISO Bezug: 27002 4.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.
Sicherheitsmechanismen können:
  • Risiken vermeiden
  • Bedrohungen oder Schwachstellen verkleinern
  • unerwünschte Ereignisse entdecken
  • die Auswirkung eines unerwünschten Ereignisses eingrenzen
  • Risiken überwälzen
  • es möglich machen, einen früheren Zustand wiederherzustellen
[eh Teil 1 - 2.2.1]

2.2.1.1 Klassifikation von Sicherheitsmaßnahmen

ISO Bezug: 27002 4.1
Je nach Betrachtungsweise kann eine Klassifikation von Sicherheitsmaßnahmen hinsichtlich nachfolgender Kriterien getroffen werden.

Klassifikation nach Art der Maßnahmen

Dies ist die „klassische“ Einteilung der Sicherheitsmaßnahmen.
Man unterscheidet:
  • (informations-)technische Maßnahmen
  • bauliche Maßnahmen
  • organisatorische Maßnahmen
  • personelle Maßnahmen

Klassifikation nach Anwendungsbereichen

Man unterscheidet:
  • Maßnahmen, die organisationsweit (oder in Teilen der Organisation) einzusetzen sind. Dazu gehören:
    • Etablierung eines ISMS-Prozesses und Erstellung von Informationssicherheitspolitiken
    • organisatorische Maßnahmen (z. B. Kontrolle von Betriebsmitteln, Dokumentation, Rollentrennung)
    • Überprüfung der IT-Sicherheitsmaßnahmen auf Übereinstimmung mit den Informationssicherheitspolitiken (Security Compliance Checking), Auditing
    • Reaktion auf sicherheitsrelevante Ereignisse (Incident Handling)
    • personelle Maßnahmen (inkl. Schulung und Bildung von Sicherheitsbewusstsein)
    • bauliche Sicherheit und Infrastruktur
    • Notfallvorsorge
  • Systemspezifische Maßnahmen. Die Auswahl systemspezifischer Maßnahmen hängt in hohem Maße vom Typ des zu schützenden IT-Systems ab. Man unterscheidet etwa:
    • Nicht-vernetzte Systeme (Stand-Alone-PCs)
    • Workstations in einem Netzwerk
    • Server in einem Netzwerk

Klassifikation nach Gefährdungen und Sicherheitsanforderungen

Ausgehend von den Grundbedrohungen gegen ein IT-System (Verlust der Vertraulichkeit, Integrität, Verfügbarkeit etc.) werden die typischen Gefährdungen ermittelt.
Man unterscheidet daher:
  • Maßnahmen zur Gewährleistung der Vertraulichkeit (confidentiality)
  • Maßnahmen zur Gewährleistung der Integrität (integrity)
  • Maßnahmen zur Gewährleistung der Verfügbarkeit (availability)
  • Maßnahmen zur Gewährleistung der Zurechenbarkeit (accountability)
  • Maßnahmen zur Gewährleistung der Authentizität (authenticity)
  • Maßnahmen zur Gewährleistung der Zuverlässigkeit (reliability)
  • Maßnahmen zur Gewährleistung der Nichtwiderlegbarkeit (non-repudiation)
Wirksame Informationssicherheit verlangt i. Allg. eine Kombination von verschiedenen Sicherheitsmaßnahmen, wobei auf die Ausgewogenheit von technischen und nicht technischen Maßnahmen zu achten ist.
[eh Teil 1 - 5.1.1]

2.2.1.2 Ausgangsbasis für die Auswahl von Maßnahmen

ISO Bezug: 27002 4.1

Liste existierender bzw. geplanter Sicherheitsmaßnahmen:

Bei der Auswahl von Sicherheitsmaßnahmen zur Verminderung der Risiken wird vorausgesetzt, dass im vorhergehenden Schritt - der Risikoanalyse - die bereits existierenden Sicherheitsmaßnahmen aufgelistet wurden.
Im Fall einer detaillierten Risikoanalyse erfolgt dies im Rahmen der „Identifikation bestehender Schutzmaßnahmen“ (vgl. 4.2.6 Identifikation bestehender Sicherheitsmaßnahmen), die als Ergebnis eine Aufstellung aller existierenden oder bereits geplanten Schutzmaßnahmen mit Angaben über ihren Implementierungsstatus und ihren Einsatz liefern soll. Bei einer Grundschutzanalyse werden die vorhandenen Maßnahmen im Rahmen des Soll-Ist-Vergleiches (vgl. 4.3.2.2 Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen) ermittelt.

Ergebnisse der Risikobewertung:

Die Auswahl der Sicherheitsmaßnahmen, die die Risiken auf ein definiertes und beherrschbares Maß reduzieren, muss auf den Ergebnissen der Risikobewertung basieren.
Diese Auswahl wird von einer Reihe von Faktoren beeinflusst:
  • der Stärke der einzelnen Maßnahmen
  • ihrer Benutzerfreundlichkeit und Transparenz für die AnwenderInnen
  • der Art der Schutzfunktion (Verringerung von Bedrohungen, Erkennen von Verletzungen, …)
In der Regel stehen verschiedene mögliche Sicherheitsmaßnahmen zur Auswahl. Um die sowohl aus Sicherheits- als auch aus Wirtschaftlichkeitsüberlegungen effizienteste Lösung zu finden, kann im Einzelfall eine Kosten-/Nutzen-Analyse bzw. ein direkter Vergleich einzelner Sicherheitsmaßnahmen (trade-off analysis) notwendig sein.
[eh Teil 1 - 5.1.2]

2.2.1.3 Auswahl von Maßnahmen auf Basis einer detaillierten Risikoanalyse

ISO Bezug: 27002 4.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 i. Allg. die für den Auswahlprozess zur Verfügung stehende Information.
In der Mehrzahl der Fälle wird es verschiedene Maßnahmen zur Erfüllung einer bestimmten Sicherheitsanforderung geben, die sich jedoch hinsichtlich ihrer Effizienz und ihrer Kosten unterscheiden. Umgekehrt kann eine Maßnahme gleichzeitig mehrere Sicherheitsanforderungen abdecken.
Welche der in Frage kommenden Maßnahmen tatsächlich ausgewählt und implementiert werden, hängt von den speziellen Umständen ab. Generell ist festzuhalten, dass Sicherheitsmaßnahmen einen oder mehrere der folgenden Aspekte abdecken können:
  • Vorbeugung (präventive Maßnahmen)
  • Aufdeckung (detektive Maßnahmen)
  • Abschreckung
  • Schadensbegrenzung
  • Wiederherstellung eines früheren Zustandes
  • Bildung von Sicherheitsbewusstsein
  • Risikoüberwälzung

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

2.2.1.4 Auswahl von Maßnahmen im Falle eines Grundschutzansatzes

ISO Bezug: 27002 4.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.

Standardwerke zur Auswahl von Maßnahmen:

In diesem Sicherheitshandbuch werden die wichtigsten Grundschutzmaßnahmen für die öffentliche Verwaltung in Österreich angeführt. Alternativ kann auch auf andere bestehende Kataloge zurückgegriffen werden.
Eine sehr umfangreiche Sammlung von Grundschutzmaßnahmen, die kontinuierlich weiterentwickelt werden, findet sich etwa in den IT-Grundschutz-Standards und -Maßnahmenkatalogen des BSI (vgl. 4.3 Grundschutzansatz).
[eh Teil 1 - 5.1.4]

2.2.1.5 Auswahl von Maßnahmen im Falle eines kombinierten Risikoanalyseansatzes

ISO Bezug: 27002 4.1

Im Falle eines kombinierten Ansatzes werden zunächst anhand dieses Handbuchs oder eines Grundschutzkataloges wie z. B. dem des BSI 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.
[eh Teil 1 - 5.1.5]

2.2.1.6 Bewertung von Maßnahmen

ISO Bezug: 27002 4.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 BenutzerInnen 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 BenutzerInnen einsichtig ist.

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

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

2.2.1.7 Rahmenbedingungen

ISO Bezug: 27002 4.1

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

Weitere Einschränkungen können organisatorischer, personeller, gesetzlicher oder sozialer Natur sein.
Auch Rahmenbedingungen können im Laufe der Zeit, durch soziale Veränderungen oder durch Veränderungen im technischen oder organisatorischen Umfeld, einem Wandel unterliegen und sind daher regelmäßig zu überprüfen und zu hinterfragen.
[eh Teil 1 - 5.1.7]

2.2.2 Risikoakzeptanz

ISO Bezug: 27002 4.2, 14.1.1, 14.1.2

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

Schritt 1: Quantifizierung des Restrisikos

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

Schritt 2: Bewertung der Restrisiken

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

Schritt 3: Entscheidung über nicht akzeptable Restrisiken

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

Schritt 4: Akzeptanz von außergewöhnlichen Restrisiken

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

2.2.3 Sicherheitsrichtlinien

ISO Bezug: 27001 4.2.1

Während das Sicherheitsskonzept ganzheitlich Maßnahmen darstellt, um die Risiken auf ein definiertes und beherrschbares Maß zu bringen, sollen für jeweils spezifische Sicherheitsrichtlinien auf die einzelnen wichtigen Systeme eingehen.
[eh Teil 1 - 5.3]

2.2.3.1 Aufgaben und Ziele

ISO Bezug: 27001 4.2.1

Für alle komplexen oder stark verbreiteten IT-Systeme sollten spezifische Sicherheitsrichtlinien erarbeitet werden. Typische Beispiele sind etwa eine PC-Sicherheitsrichtlinie, eine Netzsicherheitsrichtlinie, eine Internetsicherheitsrichtlinie oder eine Richtlinie zum Einsatz mobiler Geräte.
[eh Teil 1 - 5.3.1]

2.2.3.2 Inhalte

ISO Bezug: 27001 4.2.1

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

2.2.3.3 Fortschreibung der Sicherheitsrichtlinien

ISO Bezug: 27001 4.2.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.
Insbesondere ist es von Bedeutung, dass die Liste der existierenden bzw. noch umzusetzenden Sicherheitsmaßnahmen stets dem tatsächlich aktuellen Stand entspricht.
[eh Teil 1 - 5.3.3]

2.2.3.4 Verantwortlichkeiten

ISO Bezug: 27001 4.2.1

Die Verantwortlichkeiten für die Erstellung und Fortschreibung der Sicherheitsrichtlinien sind im Einzelnen in der Informationssicherheitspolitik festzulegen (vgl. dazu 5.2.3 Organisation und Verantwortlichkeiten für Informationssicherheit). I. Allg. 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. Letztere/r hat dafür Sorge zu tragen, dass die einzelnen Sicherheitsrichtlinien mit der organisationsweiten Informationssicherheitspolitik kompatibel sind und auch untereinander ein einheitliches, vergleichbares Niveau aufweisen.
[eh Teil 1 - 5.3.4]

2.2.4 Informationssicherheitspläne für jedes System

ISO Bezug: 27001 4.3

Ein Informationssicherheitsplan beschreibt, wie die ausgewählten Sicherheitsmaßnahmen umgesetzt werden. Er enthält eine Prioritäten- und Ressourcenplanung sowie einen Zeitplan für die Umsetzung der Maßnahmen.
Im Detail sind für jedes System zu erstellen:
  • eine Liste der vorhandenen sowie eine Liste der noch zu implementierenden Sicherheitsmaßnahmen;
    für jede dieser Maßnahmen sollte eine Aussage über ihre Wirksamkeit sowie möglicherweise notwendige Verbesserungen oder Verstärkungen getroffen werden
  • eine Prioritätenreihung für die Implementierung der ausgewählten Sicherheitsmaßnahmen bzw. die Verbesserung bestehender Maßnahmen
  • eine Kosten- und Aufwandsschätzung für Implementierung und Wartung der Maßnahmen
  • Detailplanung für die Implementierung
    Diese soll folgende Punkte umfassen:
    • Prioritäten
    • Zeitplan, abhängig von Prioritäten und Ressourcen
    • Budget
    • Verantwortlichkeiten
    • Schulungs- und Sensibilisierungsmaßnahmen
    • Test- und Abnahmeverfahren und -termine
    • Nachfolgeaktivitäten
  • eine Bewertung des nach der Implementierung aller Maßnahmen zu erwartenden Restrisikos
Weiters sollte der Sicherheitsplan auch die Kontrollmechanismen festlegen, die den Fortschritt der Implementierung der ausgewählten Maßnahmen bewerten, und Möglichkeiten des Eingriffes bei Abweichungen vom vorgesehenen Prozess oder bei notwendigen Änderungen definieren.
[eh Teil 1 - 5.4]

2.2.5 Fortschreibung des Sicherheitskonzeptes

ISO Bezug: 27001 4.2.4

Das Sicherheitskonzept muss laufend fortgeschrieben werden, um an veränderte System- bzw. Umfeldeigenschaften angepasst zu bleiben.
Anlässe für eine neue Untersuchung und das Fortschreiben des Konzeptes können sein:
  • Ablauf eines vorgeschriebenen oder vereinbarten Zeitraumes (z. B. jährliches Update)
  • Eintritt von Ereignissen, die die Bedrohungslage verändern, wie etwa politische oder gesellschaftliche Entwicklungen oder das Bekanntwerden neuer Attacken
  • Eintritt von Ereignissen, die die Werte verändern können, wie etwa die Änderungen von Organisationszielen oder Aufgabenbereichen, Änderungen am Markt oder die Einführung neuer Applikationen
  • Ereignisse, die die Eintrittswahrscheinlichkeit von Bedrohungen verändern, wie etwa die Entwicklung neuer Techniken oder veränderte Einsatzbedingungen (Einsatzort, IT-Ausstattung, …)
  • neue Möglichkeiten für Sicherheitsmaßnahmen, etwa aufgrund von Preisänderungen oder der Verfügbarkeit neuer Technologien
Voraussetzungen für eine effiziente und zielgerichtete Fortschreibung des Sicherheitskonzeptes sind:
  • die laufende Überprüfung von Akzeptanz und Einhaltung der Sicherheitsmaßnahmen
  • die Protokollierung von Schadensereignissen
  • die Kontrolle der Wirksamkeit und Angemessenheit der Maßnahmen
Ob eine neuerliche Risikoanalyse erforderlich ist oder lediglich die Auswahl der Maßnahmen überarbeitet wird, hängt vom Ausmaß der eingetretenen Veränderungen ab.
[eh Teil 1 - 5.5]

2.3 Umsetzung des Informationssicherheitsplans

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 Informationssicherheitsplans ab. Dieser muss gut strukturiert, genau dokumentiert und den tatsächlichen Anforderungen der betroffenen Institution angepasst sein.
Bei der Umsetzung des Plans ist zu beachten, dass
  • Verantwortlichkeiten rechtzeitig und eindeutig festgelegt werden,
  • finanzielle und personelle Ressourcen rechtzeitig zugewiesen werden,
  • die Maßnahmen korrekt umgesetzt werden,
  • die Kosten sich in dem vorher abgeschätzten Rahmen halten,
  • der Zeitplan eingehalten wird.
Gleichzeitig mit der Implementierung der Sicherheitsmaßnahmen sollten auch entsprechende Schulungs- und Sensibilisierungsmaßnahmen gesetzt werden, um die optimale Einhaltung und Akzeptanz der Maßnahmen bei den AnwenderInnen zu erreichen.
Als letzter Schritt der Umsetzung des Informationssicherheitsplans sind die implementierten Maßnahmen in ihrer tatsächlichen Einsatzumgebung auf ihre Auswirkungen zu testen und abzunehmen (Akkreditierung).
Es empfiehlt sich, die Umsetzung des Informationssicherheitsplans im Rahmen eines Projektes abzuwickeln.
[eh Teil 1 - 5.5]

2.3.1 Implementierung von Maßnahmen

ISO Bezug: 27001 4.2.2
Sobald der Informationssicherheitsplan erstellt und verabschiedet wurde, sind die einzelnen Maßnahmen zu implementieren, auf ihre Übereinstimmung mit der Sicherheitspolitik zu überprüfen (Security Compliance Checking) und auf Korrektheit und Vollständigkeit zu testen.
Dabei ist zu beachten, dass ein Teil der Maßnahmen systemspezifisch sein wird, ein anderer Teil aber organisationsweit einzusetzen ist (vgl. dazu auch 2.2.1 Auswahl von Maßnahmen).
Die Abstimmung der einzelnen systemspezifischen Informationssicherheitspläne für die Gesamtorganisation obliegt in der Regel der/dem IT-Sicherheitsbeauftragten. Sie/er hat dafür Sorge zu tragen, dass
  • die systemübergreifenden, organisationsweiten Maßnahmen vollständig und angemessen, sowie nicht redundant oder widersprüchlich sind
  • die systemspezifischen Maßnahmen kompatibel sind und ein einheitliches, angemessenes Sicherheitsniveau haben
Besonderer Wert ist auf eine detaillierte, korrekte und aktuelle Dokumentation dieser Implementierungen zu legen.

Schritt 1: Implementierung der Sicherheitsmaßnahmen

Die Implementierung der ausgewählten Sicherheitsmaßnahmen hat anhand des Informationssicherheitsplans, entsprechend der vorgegebenen Zeitpläne und Prioritäten, zu erfolgen.
Die Verantwortlichkeiten dafür sind im Detail festzulegen.

Schritt 2: Testplan und Tests

Tests sollen sicherstellen, dass die Implementierung korrekt durchgeführt und abgeschlossen wurde.
Es wird empfohlen, für die Tests einen Testplan zu erstellen, der
  • die Testmethoden
  • die Testumgebung
  • die Zeitpläne für die Durchführung der Tests
beinhaltet.
Die durchgeführten Tests sind im Detail zu beschreiben und die Ergebnisse in einem standardisierten Testbericht festzuhalten.
Abhängig von der speziellen Bedrohungslage und der Art der Maßnahmen kann die Durchführung von Penetrationstests erforderlich sein.

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

Security Compliance Checks sind sowohl im Rahmen der Implementierung der Maßnahmen als auch als wiederholte Aktivität zur Gewährleistung der Informationssicherheit im laufenden Betrieb (siehe dazu auch 15.1 Security Compliance Checking und Monitoring) durchzuführen.
Dabei sind zu prüfen:
  • die vollständige und korrekte Umsetzung der Sicherheitsmaßnahmen
  • der korrekte Einsatz der implementierten Sicherheitsmaßnahmen
  • die Einhaltung der organisatorischen Sicherheitsmaßnahmen im täglichen Betrieb
Dokumentation
Die Dokumentation der implementierten Maßnahmen stellt einen wichtigen Teil der gesamten Sicherheitsdokumentation dar und ist notwendige Voraussetzung für die Kontinuität und Konsistenz des Informationssicherheitsprozesses. Die wichtigsten Anforderungen an die Dokumentation sind:
  • Aktualität:
    Alle Sicherheitsmaßnahmen sind stets auf dem aktuellen Stand der Realisierung zu beschreiben.
  • Vollständigkeit
  • Hoher Detaillierungsgrad:
    Die Sicherheitsmaßnahmen sind so detailliert zu beschreiben, dass zum einen eventuell bestehende Sicherheitslücken erkannt werden können, zum anderen ausreichend Information für einen korrekten und effizienten Einsatz der Maßnahmen zur Verfügung steht.
  • Gewährleistung der Vertraulichkeit:
    Dokumentation über Sicherheitsmaßnahmen kann unter Umständen sehr vertrauliche Information enthalten und ist daher entsprechend zu schützen. So weit wie möglich sollte bei der Klassifizierung und Behandlung solcher Dokumente auf die Vorgaben im Rahmen der Informationssicherheitspolitik der Organisation zurückgegriffen werden (vgl. dazu 5.2.5 Klassifizierung von Informationen). Es kann im Einzelfall notwendig sein, weitere Verfahrensweisen zur Erstellung, Verteilung, Benutzung, Aufbewahrung und Vernichtung von sicherheitsrelevanter Dokumentation zu entwickeln. Diese Verfahrensweisen sind ebenfalls entsprechend zu dokumentieren.
  • Konfigurations- und Integritätskontrolle:
    Es ist sicherzustellen, dass keine unauthorisierten Änderungen der Dokumentation erfolgen, die eine - beabsichtigte oder unbeabsichtigte - Beeinträchtigung der implementierten Maßnahmen nach sich ziehen könnten.
[eh Teil 1 - 6.1]

2.3.2 Sensibilisierung (Security Awareness)

ISO Bezug: 27002 5.2.2, 8.2.2
Nur durch Verständnis und Motivation ist eine dauerhafte Einhaltung und Umsetzung der Richtlinien und Vorschriften zur Informationssicherheit zu erreichen. Um das Sicherheitsbewusstsein aller MitarbeiterInnen zu fördern und den Stellenwert der Informationssicherheit innerhalb einer Organisation zu betonen, sollte ein umfassendes, organisationsweites Sensibilisierungsprogramm erstellt werden, das zum Ziel hat, Informationssicherheit zu einem integrierten Bestandteil der täglichen Arbeit zu machen.
Das Sensibilisierungsprogramm sollte systemübergreifend sein. Es ist Aufgabe der dafür verantwortlichen Person - dies wird in der Regel die/der IT-Sicherheitsbeauftragte sein - die Anforderungen aus den einzelnen Teilbereichen und systemspezifische Anforderungen hier einfließen zu lassen und entsprechend zu koordinieren.
Das Sensibilisierungsprogramm sollte folgende Punkte umfassen:
  • Information aller MitarbeiterInnen über die Informationssicherheitspolitik der Organisation. Im Rahmen einer Einführung sollten insbesondere folgende Punkte erläutert werden:
    • die Informationssicherheitsziele und -politik der Organisation sowie deren Erläuterung
    • die Bedeutung der Informationssicherheit für die Organisation
    • Organisation und Verantwortlichkeiten im Bereich der Informationssicherheit
    • die Risikoanalysestrategie
    • die Sicherheitsklassifizierung von Daten
    • ausgewählte Sicherheitsmaßnahmen (insbesondere solche, die für die gesamte Organisation Gültigkeit haben)
  • die wichtigsten Ergebnisse der Risikoanalysen (Bedrohungen, Schwachstellen, Risiken, …)
  • die Pläne zur Implementierung und Überprüfung der Sicherheitsmaßnahmen
  • die Auswirkungen von sicherheitsrelevanten Ereignissen für einzelne Anwender und für die gesamte Institution
  • die Notwendigkeit, Sicherheitsverstöße zu melden und zu untersuchen
  • die Konsequenzen bei Nichteinhaltung von Sicherheitsvorgaben
Zur Sensibilisierung der MitarbeiterInnen können u. a. folgende Maßnahmen beitragen:
  • regelmäßige Veranstaltungen zum Thema Informationssicherheit
  • Publikationen
  • schriftliche Festlegung der Berichtswege und Handlungsanweisungen im Falle eines vermuteten Sicherheitsproblems (z. B. Auftreten eines Virus, Angriff von außen („Hacker“), …)
Das Sensibilisierungsprogramm sollte alle MitarbeiterInnen der Institution auf ihre Verantwortlichkeit für Informationssicherheit hinweisen. Dabei ist insbesondere die Verantwortung des Managements für Informationssicherheit zu betonen („Informationssicherheit als Managementaufgabe“). Die organisationsweite Planung dieser Veranstaltungen sollte die/der IT-Sicherheitsbeauftragte übernehmen. Gegebenenfalls liefern Bereichs-IT-Sicherheitsbeauftragte Informationen, wann und wo solche Veranstaltungen nötig sind.
Die Veranstaltungen zum Sensibilisierungsprogramm sollten in regelmäßigen Zeitabständen wiederholt werden, um das vorhandene Wissen aufzufrischen und neue MitarbeiterInnen zu informieren. Darüber hinaus sollte alle neuen, beförderten oder versetzten MitarbeiterInnen so weit in Fragen der Informationssicherheit geschult werden, wie es der neue Arbeitsplatz verlangt.
Das Sensibilisierungsprogramm ist regelmäßig auf seine Wirksamkeit und Aktualität zu überprüfen und laufend an Veränderungen in der Informationssicherheitspolitik sowie an neue Technologien anzupassen.
[eh Teil 1 - 6.2]

2.3.3 Schulung

ISO Bezug: 27002-5.2.2, 6.1,2, 8.2.1, 8.2.2, 15.1.5

Ü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.
Personen, die in besonderem Maße mit Informationssicherheit zu tun haben, sind speziell dafür auszubilden und zu schulen. Dazu zählen etwa:
  • die/der IT-Sicherheitsbeauftragte und die Bereichs-IT-Sicherheitsbeauftragten
  • die Mitglieder des Informationssicherheitsmanagement-Teams
  • MitarbeiterInnen, die zu als VERTRAULICH, GEHEIM oder STRENG GEHEIM eingestuften Informationen Zugang haben
  • MitarbeiterInnen mit spezieller Verantwortung für die Systementwicklung (z. B. ProjektleiterInnen)
  • MitarbeiterInnen mit spezieller Verantwortung für den Betrieb eines IT-Systems oder einer wichtigen Applikation (z. B. Applikationsverantwortliche)
  • MitarbeiterInnen, die mit Aufgaben der IT-Sicherheitsverwaltung betraut sind (z. B. Vergabe von Zutritts-, Zugangs- und Zugriffsrechten)

Das Schulungsprogramm ist von jeder Organisation spezifisch für ihren eigenen Bedarf zu entwickeln. Besondere Betonung ist dabei auf die Schulung der korrekten Implementierung und Anwendung von Sicherheitsmaßnahmen zu legen. Typische Beispiele für die Themen, die im Rahmen von Schulungsveranstaltungen behandelt werden sollten, sind:
  • Sicherheitspolitik und -infrastruktur:
    Rollen und Verantwortlichkeiten, Organisation des Informationssicherheitsmanagements, Behandlung von sicherheitsrelevanten Vorfällen, regelmäßige Überprüfung von Sicherheitsmaßnahmen und ähnliches
  • Bauliche Sicherheit:
    Schutz von Gebäuden, Serverräumen, Büroräumen und Versorgungseinrichtungen mit besonderer Betonung der Verantwortung der einzelnen MitarbeiterInnen (z. B. Handhabung von Zutrittskontrollmaßnahmen, Brandschutz)
  • Personelle Sicherheit
  • Hardware- und Softwaresicherheit:
    Dazu gehören etwa Identifikation und Authentisierung, Berechtigungssysteme, Protokollierung, Wiederaufbereitung und Virenschutz.
  • Netzwerksicherheit:
    Netzwerkinfrastruktur, LANs, Inter-/Intranets, Verschlüsselung, digitale Signaturen u. ä.
  • Business Continuity-Planung
Schulungs- und Sensibilisierungsveranstaltungen zum Thema Informationssicherheit müssen zeitgerecht geplant und umgesetzt werden, um keine Sicherheitslücken durch mangelndes Wissen oder Sicherheitsbewusstsein entstehen zu lassen.
[eh Teil 1 - 6.3]

2.3.4 Akkreditierung

Unter Akkreditierung eines IT-Systems versteht man die durch eine unabhängige Instanz formal dokumentierte Sicherstellung, dass dieses den Anforderungen der Informationssicherheitspolitik und der Sicherheitsrichtlinien genügt.
Wird ein IT-System akkreditiert, ist insbesondere darauf zu achten, dass seine Sicherheit
  • in einer definierten Betriebsumgebung
  • unter definierten Einsatzbedingungen
  • für eine definierte vorgegebene Zeitspanne
gewährleistet ist.
Erst nach erfolgter Akkreditierung kann ein solches System - oder eine spezifische Anwendung davon - in Echtbetrieb gehen.
Techniken zur Akkreditierung sind:

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

Wesentlich bei der Akkreditierung ist die Anwendung standardisierter und damit vergleichbarer Vorgehens- und Zustandsbeschreibungen sowie standardisierter Vorgaben für Erfüllung und Dokumentation.
[eh Teil 1 - 6.4]

2.4 Informationssicherheit im laufenden Betrieb

Umfassendes Informationssicherheitsmanagement beinhaltet nicht zuletzt auch die Aufgabe, die Informationssicherheit im laufenden Betrieb aufrechtzuerhalten. Ein Sicherheitskonzept ist kein statisches, unveränderbares Dokument, sondern muss stets auf seine Wirksamkeit, Aktualität und die Umsetzung in der täglichen Praxis überprüft werden. Weiters muss eine angemessene Reaktion auf alle sicherheitsrelevanten Änderungen sowie auf sicherheitsrelevante Ereignisse gewährleistet sein.
Ziel aller Follow-Up-Aktivitäten ist es, das erreichte Sicherheitsniveau zu erhalten bzw. weiter zu erhöhen. Verschlechterungen der Wirksamkeit von Sicherheitsmaßnahmen - sei es durch eine Veränderung der Bedrohungslage oder durch falsche Verwendung der implementierten Sicherheitsmaßnahmen - sollen erkannt und entsprechende Gegenmaßnahmen eingeleitet werden.

2.4.1 Aufrechterhaltung des erreichten Sicherheitsniveaus

ISO Bezug: 27001 4.2.4, 6, 8
Das nach der Umsetzung des Informationssicherheitsplans erreichte Sicherheitsniveau lässt sich nur dann aufrechterhalten, wenn Support, Compliance und Monitoring sichergestellt sind:
  • Wartung und administrativer Support der Sicherheitseinrichtungen müssen gewährleistet sein,
  • die realisierten Maßnahmen müssen regelmäßig auf ihre Übereinstimmung mit der Informationssicherheitspolitik geprüft werden (Security Compliance Checking)
  • und die IT-Systeme fortlaufend überwacht werden (Monitoring).
Die Verantwortlichkeiten für diese Aktivitäten müssen im Rahmen der organisationsweiten Informationssicherheitspolitik bzw. in den einzelnen Sicherheitsrichtlinien detailliert festgelegt werden. Generell gilt auch hier, dass die Verantwortung für systemspezifische Maßnahmen bei den einzelnen Bereichs-IT-Sicherheitsbeauftragten - soweit definiert - liegen sollte, die Verantwortung für organisationsweite Sicherheitsmaßnahmen sowie die Gesamtverantwortung bei der/dem IT-Sicherheitsbeauftragten.
Von besonderer Wichtigkeit für die Aufrechterhaltung oder weitere Erhöhung eines einmal erreichten Sicherheitsniveaus ist eine permanente Sensibilisierung aller betroffenen MitarbeiterInnen für Fragen der Informationssicherheit (vgl. dazu auch 2.3.2 Sensibilisierung (Security Awareness)).
[eh Teil 1 - 7.1.1]

2.4.2 Wartung und administrativer Support von Sicherheitseinrichtungen

ISO Bezug: 27001 4.2.4, 6, 8

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

Alle Wartungs- und Supportaktivitäten sollten nach einem detailliert festgelegten Plan erfolgen und regelmäßig durchgeführt werden.
Die Wartung von Sicherheitseinrichtungen hat in Abstimmung mit den Verträgen, die mit den Lieferfirmen geschlossen wurden, zu erfolgen und darf nur durch dafür autorisierte Personen vorgenommen werden.
Die Kosten für Wartungs- und Supportaufgaben können im Einzelfall beträchtlich sein und sollten daher bereits bei der Auswahl der Sicherheitsmaßnahmen bekannt sein und in den Entscheidungsprozess mit einfließen.
Um die Aufrechterhaltung eines einmal erreichten Sicherheitsniveaus zu gewährleisten, ist sicherzustellen, dass
  • die erforderlichen finanziellen und personellen Ressourcen zur Wartung von Sicherheitseinrichtungen zur Verfügung stehen
  • organisatorische Regelungen existieren, die die Aufrechterhaltung der Informationssicherheitsmaßnahmen im laufenden Betrieb ermöglichen und unterstützen
  • die Verantwortungen im laufenden Betrieb klar zugewiesen werden
  • die Maßnahmen regelmäßig daraufhin geprüft werden, ob sie wie beabsichtigt funktionieren
  • Maßnahmen verstärkt werden, falls sich neue Schwachstellen zeigen
Alle Wartungs- und Supportaktivitäten im Sicherheitsbereich sollten protokolliert werden. Der regelmäßigen Auswertung dieser Protokolle kommt besondere Bedeutung für die gesamte Informationssicherheit zu.
[eh Teil 1 - 7.1.1]

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

ISO Bezug: 27001 4.2.4, 15.2.1

Zielsetzung

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

Dabei ist zu prüfen, ob
  • die Sicherheitsmaßnahmen vollständig und korrekt umgesetzt werden
  • der korrekte Einsatz der implementierten Sicherheitsmaßnahmen gewährleistet ist (Stichproben!)
  • die organisatorischen Sicherheitsvorgaben im täglichen Betrieb eingehalten und akzeptiert werden
Weiters sind die getroffenen Maßnahmen regelmäßig auf Übereinstimmung mit gesetzlichen und betrieblichen Vorgaben zu überprüfen.
Die Prüfungen können durch externe oder interne AuditorInnen durchgeführt werden und sollten soweit möglich auf standardisierten Tests und Checklisten basieren.

Zeitpunkte

Security Compliance Checks sollten zu folgenden Zeitpunkten bzw. bei Eintreten folgender Ereignisse durchgeführt werden:
  • für neue IT-Systeme oder relevante neue Anwendungen:
    nach der Implementierung (vgl. dazu auch 15.1 Security Compliance Checking und Monitoring)
  • für bereits in Betrieb befindliche IT-Systeme oder Applikationen:
    nach einer bestimmten, in den Sicherheitsrichtlinien vorzugebenden Zeitspanne (z. B. jährlich) sowie bei signifikanten Änderungen.
[eh Teil 1 - 7.1.2]

2.4.4 Fortlaufende Überwachung der IT-Systeme (Monitoring)

ISO Bezug: 27002 4.2.4

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

Wo technisch möglich und sinnvoll, sollte das Monitoring durch die Ermittlung von Kennzahlen unterstützt werden, die eine rasche und einfache Erkennung von Abweichungen von den Sollvorgaben ermöglichen. Solche Kennzahlen können beispielsweise die Systemverfügbarkeit, die Zahl der Hacking-Versuche über Internet oder die Wirksamkeit des Passwortmechanismus betreffen.
Alle Änderungen der potenziellen Bedrohungen, Schwachstellen, zu schützenden Werte und Sicherheitsmaßnahmen können möglicherweise signifikante Auswirkungen auf das Gesamtrisiko haben. Aus diesem Grund ist eine fortlaufende Überwachung folgender Bereiche erforderlich:
  • Wert der zu schützenden Objekte:
    Sowohl die Werte von Objekten als auch, daraus resultierend, die Sicherheitsanforderungen an das Gesamtsystem können im Laufe des Lebenszyklus eines IT-Projektes oder -Systems erheblichen Änderungen unterliegen. Mögliche Gründe dafür sind eine Änderung der IT-Sicherheitsziele, neue Applikationen oder die Verarbeitung von Daten einer höheren Sicherheitsklasse auf existierenden Systemen oder Änderungen in der Hardwareausstattung.
  • Bedrohungen und Schwachstellen:
    Organisatorisch oder technologisch (hier insbesondere durch neue Technologien in der Außenwelt) bedingt können sowohl die Wahrscheinlichkeit des Eintritts einer Bedrohung als auch die potenzielle Schadenshöhe im Laufe der Zeit starken Änderungen unterliegen und sind daher regelmäßig zu evaluieren. Neue potenzielle Schwachstellen sind so früh wie möglich zu erkennen und abzusichern.
  • Sicherheitsmaßnahmen:
    Die Wirksamkeit der implementierten Sicherheitsmaßnahmen ist laufend zu überprüfen. Es ist sicherzustellen, dass sie einen angemessenen und den Vorgaben der Sicherheitsrichtlinien entsprechenden Schutz bieten. Änderungen in den Werten der bedrohten Objekte, den Bedrohungen und den Schwachstellen, aber auch durch den Einsatz neuer Technologien, können die Wirksamkeit der Sicherheitsmaßnahmen nachhaltig beeinflussen.

Durch ein kontinuierliches Monitoring soll die Leitung der Institution ein klares Bild darüber bekommen, was durch die Sicherheitsmaßnahmen erreicht wurde (Soll-/Ist-Vergleich), ob die Ergebnisse den Sicherheitsanforderungen der Institution genügen sowie über den Erfolg einzelner spezifischer Aktivitäten zur Informationssicherheit.
Werden im Rahmen des kontinuierlichen Monitorings signifikante Abweichungen des tatsächlichen Risikos von dem im Sicherheitskonzept festgelegten akzeptablen Restrisiko festgestellt, so sind entsprechende Gegenmaßnahmen zu setzen.
[eh Teil 1 - 7.1.3]

3 Managementverantwortung und Aufgaben beim ISMS

Dieses Kapitel nimmt Bezug auf ISO/IEC 27001 5 bis 8.
Zur Verantwortung der Managementebene gehört neben der Erreichung der geschäftlichen wie unternehmenspolitischen Ziele auch der angemessene Umgang mit Risiken. Sie müssen so früh wie möglich erkannt, eingeschätzt, bewertet und durch Setzen geeigneter und nachhaltiger Maßnahmen auf einen minimalen und akzeptierten Rest reduziert werden. Wegen der immer höheren Abhängigkeit von Information gilt dies besonders für Risiken aus fehlender oder mangelhafter Informationssicherheit.

3.1 Verantwortung der Managementebene

3.1.1 Generelle Managementaufgaben beim ISMS

ISO Bezug: 27001 5.1

Es ist eine Managementverantwortung, einen systematischen und dauerhaften Sicherheitsmanagementprozess zu etablieren, zu steuern und zu kontrollieren. Wird ein Informationssicherheitsmanagementsystem (ISMS) eingerichtet, so ist es zu planen, zu implementieren, zu betreiben sowie zu kontrollieren und zu verbessern.
Dies bedeutet, dass die Managementebene für die Umsetzung folgender Aufgaben zu sorgen hat:
  • Erarbeitung einer Sicherheitspolitik
  • Erarbeitung der Zielsetzungen und Detailaufgaben des ISMS
  • Benennung von Rollen und verantwortlichen Personen
  • Darstellung, Einschätzung, Bewertung der Risiken, Festlegung von Kriterien für akzeptable Restrisiken
  • Schaffung von Awareness (Bewusstsein) für die Bedeutung und den Nutzen eines angemessenen Informationssicherheitsniveaus bzw. des ISMS
  • Schaffung von Awareness (Bewusstsein) und Motivation für die Notwendigkeit der Einhaltung der Sicherheitsregeln
  • Schaffung von Awareness (Bewusstsein) und Motivation, über Schwachstellen und Sicherheitsvorfälle zu informieren und Verbesserungen vorzuschlagen
  • Bereitstellung ausreichender finanzieller und personeller Ressourcen für Einrichtung und dauerhaften Betrieb des ISMS sowie der Sicherheitsmaßnahmen
  • Durchführung von Audits und Management-Reviews im Rahmen des ISMS
  • Herbeiführung von Entscheidungen über Verbesserungsvorschläge, im positiven Fall jeweils auch Sicherstellung von deren Umsetzung

Wie der Sicherheitsprozess organisiert wird, hängt von seiner Komplexität ab, diese wiederum von Größe und Aufgaben der Organisation. Sehr kleine Organisationen werden fallweise unter der Leitung des Geschäftsführers/der Geschäftsführerin punktuell externe Berater heranziehen, bei größeren Einheiten wird sich ein Mitglied der Managementebene persönlich um das ISMS kümmern bzw. wird ein/e Sicherheitsbeauftragte/r oder mehrere Sicherheitsbeauftragte benannt, welche mit Sicherheitsaufgaben betraut werden und diese ausschließlich oder zusätzlich zu anderen Aufgaben ausüben. Dies kann auch - etwa bei großen Organisationen oder solchen, für die Sicherheit zum Geschäftsmodell gehört - im Rahmen einer eigenen Sicherheitsorganisation erfolgen.

Unbeschadet davon bleibt die Gesamtverantwortung jedoch immer bei der Managementebene. Sie kann diese Verantwortung allerdings nur dann effizient wahrnehmen, wenn sie stetig mit den essentiellen Informationen versorgt wird (analog dazu, dass sie mit Geschäftskennzahlen versorgt werden muss):
  • Sicherheitsanforderungen, die sich aus gesetzlichen oder vertraglichen Verpflichtungen ableiten
  • Aktuelle Sicherheitsrisiken mitsamt ihren möglichen - auch finanziellen - Auswirkungen, sowie ihre voraussichtliche Entwicklung
  • Aufgetretene Schwachstellen oder Sicherheitsvorfälle
  • Auswirkungen von tatsächlichen oder potenziellen Sicherheitsvorfällen auf kritische Geschäftsprozesse
  • Potenzielle Gefährdungen aus veränderten Rahmenbedingungen und zukünftigen Entwicklungen
  • Brauchbare Vorgehensweisen zur Informationssicherheit aus allgemeinen oder branchenüblichen Standards, vergleichbaren Organisationen, Arbeitsgruppen

Es muss laufend überprüft werden, ob und welche Sicherheitsmaßnahmen bzw. Verfahren des ISMS noch wirksam bzw. angemessen sind. Aus diesen Informationen sind von der Managementebene laufend Schlussfolgerungen zu ziehen und Entscheidungen zu treffen: welche Schwachstellen behoben wurden, ob und welche Sicherheitsmaßnahmen zu adaptieren sind und welche Verbesserungsmöglichkeiten umgesetzt werden.

Die Managementebene hat die Aufgabe, die MitarbeiterInnen zur aktiven Mitwirkung am Sicherheitsprozess zu motivieren und für diesbezüglich ausreichende Ausbildungs- und Awarenessmaßnahmen zu sorgen. Nur wenn der Sinn von Sicherheitsmaßnahmen bzw. -vorgaben und -anweisungen verstanden wird, werden diese auch gelebt und Informationen über Schwachstellen gegeben bzw. Verbesserungsvorschläge gemacht. Werden die AnwenderInnen in die Planung und Umsetzung von Maßnahmen einbezogen, werden sie auch von sich aus Ideen einbringen und die Tauglichkeit von Sicherheitsmaßnahmen aus Sicht der täglichen Praxis beurteilen.

Grenzen der Sicherheit:
  • Es muss klar sein, dass Sicherheitsmaßnahmen - oft erhebliche - Kosten verursachen. Diesen sind jene gegenüberstellen, die als Folge eines schweren Sicherheitsvorfalls anfallen würden.
  • Es muss ebenso klar sein, dass es keine absolute Sicherheit geben kann, sondern nur ein akzeptiertes Restrisiko.
  • Es können Verkettungen von Vorfällen auftreten, die niemand vorhersagen kann und die ein höheres Schadenspotenzial als das akzeptierte Restrisiko nach sich ziehen.
Daher macht es Sinn, die Sicherheitsziele so zu definieren, dass sie zwar die Risiken auf das akzeptierte Maß senken, aber mit vertretbarem personellen, zeitlichen und finanziellen Aufwand erreicht werden können. Eine „starke“ Sicherheitsmaßnahme, die nie fertig wird, ist gar keine.
[Quelle: BSI M 2.336]

3.2 Ressourcenmanagement

3.2.1 Bereitstellung von Ressourcen

ISO Bezug: 27001 5.2.1

Aufwand und Nutzen bei der Informationssicherheit

Ein angestrebtes Sicherheitsniveau ist nur dann sinnvoll, wenn es sich wirtschaftlich vertreten lässt und mit den verfügbaren personellen, zeitlichen und finanziellen Ressourcen auch erreicht werden kann. Ist das nicht möglich, dann müssen die Sicherheitsstrategie oder die Geschäftsprozesse bzw. die ihnen zugehörige Informationsverarbeitung geändert werden.
Ab einem bestimmten Niveau rechnet sich der steigende Aufwand für angestrebte noch höhere Sicherheitsniveaus nicht mehr, da der tatsächliche Gewinn an Sicherheit immer geringer wird, bis er gar nicht mehr zunimmt.
Weit verbreitet ist die Ansicht, dass sich Informationssicherheit - insbesondere IT-Sicherheit - vor allem durch technische Maßnahmen bewerkstelligen lässt. Die Erfahrung zeigt allerdings, dass personelle Ressourcen und geeignete - oft sehr einfache - organisatorische Maßnahmen in vielen Fällen am effektivsten sind. Selbstverständlich ist Sicherheitstechnik eine wichtige Lösung und häufig unentbehrlich, aber nur innerhalb eines geeigneten organisatorischen Rahmens und bedient von qualifizierten Menschen.

Ressourcen für die Organisation

Erfahrungsgemäß ist die Benennung eines/einer IT-Sicherheitsbeauftragten eine sehr effiziente Sicherheitsmaßnahme, bei der die Anzahl an Sicherheitsvorfällen signifikant zurückgeht. Ihm/ihr muss allerdings ausreichend Zeit für seine diesbezügliche Tätigkeit zugestanden werden.
Daher ist es in kleineren Organisationen eher möglich, dass er/sie die Sicherheitsaufgaben neben den eigentlichen Tätigkeiten ausübt. Größere Organisationen oder solche mit hohen Ansprüchen an Informationssicherheit, werden entweder hauptamtliche Sicherheitsbeauftragte beschäftigen oder IS-Management-Teams aus mehreren MitarbeiterInnen, welche dies neben ihren eigentlichen Aufgaben wahrnehmen können, zusammenstellen. Für Ad-hoc-Beratungen, Überprüfungen oder Implementierungen kann es sich auch für kleine Organisationen lohnen, kurzfristig externe Sicherheitsexperten heranzuziehen. In einem solchen Fall muss auf den Schutz der Informationen gegenüber Externen geachtet werden (siehe dazu 10.8.1 Richtlinien beim Datenaustausch mit Dritten).

Ressourcen für die Einrichtung des ISMS: IS-Management-Team

Die sorgfältige Einrichtung und Planung des ISMS bedeutet einen erheblichen Zeit- und Arbeitsaufwand für alle mit der Informationssicherheit befassten MitarbeiterInnen, der dennoch in einem eher straffen Terminplan zu erledigen ist. Wenn möglich sollten diese als IS-Management-Team formiert und - zumindest ein Teil von ihnen - während dieser Zeit von ihren sonstigen Aufgaben so weit wie möglich freigestellt werden.
Mit einem solchen Team werden unterschiedliche Organisationseinheiten in den Sicherheitsprozess einbezogen und Kompetenzen gebündelt. Die Informationssicherheit wird dadurch schneller in allen Organisationseinheiten umgesetzt und es gibt weniger Konflikte.
Das IS-Management-Team kann sich etwa - je nach Größe und Art der Organisation - aus folgenden Bereichen zusammensetzen:
  • Informationssicherheit
  • Fachabteilungen
  • Haustechnik
  • Revision
  • IT, Datenschutz
  • Personal
  • Betriebsrat
  • Finanz/Controlling
  • Rechtsabteilung
Für eine kontinuierliche Steuerung des Prozesses sollte ein solches IS-Management-Team regelmäßig zusammenkommen.

Ressourcen für Betrieb und Überprüfung

Ein reibungsloser IT-Betrieb ist zwar eine Voraussetzung für Informationssicherheit, in vielen Fällen aus Ressourcenmangel aber nicht gegeben. Überlastete IT-MitarbeiterInnen, mangelhaft gewartete IT-Einrichtungen, fehlende Ausbildung etc. sind Quellen für plötzlich auftretende Fehler, welche die ohnehin problematische Situation verschärfen. Zusätzlich kann es zu schleichender Demotivierung mit allen negativen Folgen führen.
Daher sollte sich die Managementebene immer wieder vom Ablauf des Betriebs und der Situation der MitarbeiterInnen überzeugen und bei Mängeln für deren rasche Behebung sorgen.
Weiters sind personelle, zeitliche und finanzielle Ressourcen erforderlich und bereitzustellen, um die Wirksamkeit und Eignung der Sicherheitsmaßnahmen systematisch überprüfen zu können. Dabei ist auch laufend zu bewerten:
  • ob der Aufwand jeweils noch im Einklang zum Sicherheitsnutzen steht,
  • welche Alternativen eingesetzt werden könnten,
  • ob die verwendeten Sicherheitsmaßnahmen die zugehörigen Geschäftsprozesse noch unterstützen.
Schließlich sind noch Ressourcen bereitzustellen, um das ISMS selbst auf Konsistenz und Wirksamkeit zu überprüfen (interne/externe Audits, Management-Reviews) und ggf. Verbesserungen einzuleiten. Dies wird in der Regel von entsprechend ausgebildeten MitarbeiterInnen in Zusammenwirken mit der Managementebene durchgeführt.
[Quelle: BSI Standard 100-2]

3.2.2 Schulung und Awareness

ISO Bezug: 27001 5.2.2

Wirksame Informationssicherheitsmaßnahmen benötigen neben ihrer sachlichen Implementierung eine Sicherheitskultur der Organisation, ausgeprägtes Sicherheitsbewußtsein bei den MitarbeiterInnen und deren ausreichende und weiterentwickelte Qualifikation.
Dies ist ein langfristiger und kontinuierlicher Prozeß mit vielschichtigen Effekten:
  • Überzeugung aller MitarbeiterInnen, dass Informationssicherheit ein Erfolgsfaktor ist
  • Überzeugung aller MitarbeiterInnen, dass und warum bestimmte Sicherheitsmaßnahmen notwendig und sinnvoll sind
  • Wissen bei den MitarbeiternInnen über Erwartungen hinsichtlich Informationssicherheit
  • Wissen bei den MitarbeiternInnen, was sie in kritischen Situationen tun bzw. unterlassen sollen
  • Ausreichende Kenntnisse und Fertigkeiten zur Durchführung ihrer Aufgaben
  • Kenntnis der betrieblichen Abläufe
  • Kenntnis der AnsprechpartnerInnen für Sicherheitsfragen oder -probleme

Die Organisation wird ihre geschäftlichen, aber auch sicherheitsrelevanten Ziele wohl nur mit hinreichend ausgebildeten und informierten MitarbeiterInnen erreichen. Das beginnt selbstverständlich schon bei der Auswahl von BewerberInnen bei der Einstellung und setzt dafür genaue und aktuelle Job-Beschreibungen voraus. Die mitgebrachten Kenntnisse und Erfahrungen decken jedoch nur einen Teil des Benötigten für die nunmehrige Tätigkeit ab und werden mit der Zeit weniger aktuell. Laufende Information, Schulung und positive Bewußtseinsbildung vermittelt Kompetenz und ermöglicht den MitarbeiterInnen, die Folgen und Auswirkungen ihrer Tätigkeit im beruflichen und privaten Umfeld einzuschätzen.

Gefährdungen:

Unzureichende Informationen und Kenntnisse können im Bereich der Informationssicherheit eine Reihe von Gefährdungen heraufbeschwören:
  • Vertraulichkeits- oder Integritätsverlust von Daten durch Fehlverhalten (unzureichende Kenntnis der Regelungen, unerlaubte Ausübung von Rechten, Fehlerhafte Nutzung oder Administration von IT-Systemen)
  • Nichtbeachtung von Sicherheitsmaßnahmen
  • Sorglosigkeit im Umgang mit Informationen
  • Mangelhafte Akzeptanz von Informationssicherheit
Weiters kann aus unzureichender Information (etwa wenn dies als böse Absicht des Managements interpretiert wird) im Zusammenwirken mit stetiger Überlastung Frustration entstehen, was mitunter zu vorsätzlichen Handlungen führen kann:
  • Unberechtigte IT-Nutzung
  • Missbrauch von Benutzer- oder Administratorrechten
  • Manipulation an Informationen oder Software
  • Social Engineering
  • Ausspähen von Informationen

Es muss daher im vitalen Interesse der Managementebene liegen, sich der Bedeutung von ausreichender Information, Schulung und Awareness für Informationssicherheit bei den MitarbeiterInnen bewusst zu sein und Schulungs- und Awarenessmaßnahmen nachhaltig zu unterstützen. Selbstverständlich gilt auch hier der Grundsatz der Angemessenheit: Schulungen sind kein Selbstzweck, sondern ein Mittel zur Erreichung der geschäftlichen und sicherheitspolitischen Ziele und unterliegen wie jede andere Maßnahme einer Kosten-/Nutzen Relation.

Schulungs- und Awarenessprogramm:

Optimalerweise wird für umfassende und angemessene Kompetenz ein Schulungs- und Awarenessprogramm aufgebaut und in Schritten durchlaufen. Damit werden Unterschiede im Wissenstand einzelner MitarbeiterInnen - abgesehen von ausgesprochenen Spezialisierungen - ausgeglichen.
Speziell kleine Organisationen werden sich jedoch mitunter auf das Aufspüren und Beheben individueller Kenntnislücken beschränken müssen, haben dafür meist mit geringerer Komplexität zu tun. Die generellen Anforderungen sind jedoch die gleichen wie bei größeren Einheiten.

Planung und Konzeption:

Am Beginn des Programms steht die sorgfältige Planung - diese zahlt sich wörtlich aus, da Schulungen, Seminare etc. erhebliche Kosten verursachen können und den MitarbeiterInnen erhebliche Zeit abverlangen, in der sie für ihre eigentlichen Aufgaben nicht zur Verfügung stehen.
  • Lernziele definieren: Vor allem Sicherheitsziele der eigenen Organisation müssen vermittelt werden, aber auch Basiswissen zu Informationssicherheit und Fertigkeiten für Verhalten in kritischen Situationen.
  • Erfolgskriterien für das Schulungs- und Awarenessprogramm definieren inkl. deren Messung, soweit möglich.
  • Zielgruppen für einzelne Schulungs- und Awarenessmaßnahmen definieren, da diese unterschiedliche Bedürfnisse aber auch Zeitressourcen haben (etwa: Management, BenutzerInnen, AdministratorInnen, Externe).
  • Lernbedarf identifizieren: auf Basis bisheriger Kenntnisse, Spezialisierung (etwa: neue MitarbeiterInnen, Basiswissen, Spezialkenntnisse, neue Abläufe/Systeme).
  • Lerninhalte festlegen: jedenfalls alle Regelungen und Verfahren für den jeweiligen Arbeitsplatz, inkl. Umfeld und Hintergründen. Hier besteht jedoch die Gefahr einer Überfrachtung, so dass dann aus Zeitmangel die Schulung gar nicht vollständig durchgeführt wird. Im IT-Bereich können Sicherheitsschulungen durchaus in IT-Schulungen integriert werden, sofern die TrainerInnen hinreichend qualifiziert sind und der Sicherheit hinreichend Platz eingeräumt wird.
  • Lernmethoden und -medien auswählen: eine wesentliche Entscheidung ist, ob eigene MitarbeiterInnen die Schulungen durchführen oder externe TrainerInnen. Weiters ist zu klären, ob standardisierte Seminare („von der Stange“) ausreichen (dazu sind auch deren Termine zu berücksichtigen), ob und inwieweit individuelle Schulungen notwendig sind oder ob z. B. E-Learning eingesetzt werden kann.
Schulungs- und Awarenessprogramme, die bereits einmal durchgeführt wurden, sollten auf ihren Erfolg und ihre künftige Brauchbarkeit - auch für weitere Programme - untersucht werden. Weiters - vor allem bei E-Learning - muss auf potenzielle Sicherheitsrisiken durch die Schulungsmedien geachtet werden (etwa aktive Inhalte wie Java, Javascript, ActiveX) und ggf. darauf verzichtet oder nur dezidierte Internet-PCs dafür verwendet werden. Findet die Schulung in den eigenen Räumen statt, dann muss für die notwendige Infrastruktur (Konferenzraum, Projektor, Stromanschluss etc.) gesorgt werden.

Durchführung und Kontrolle:

Damit möglichst alle vorgesehenen MitarbeiterInnen effizient geschult werden, ist eine sorgfältige Terminplanung erforderlich. Die zu schulenden MitarbeiterInnen müssen für die Zeit der Schulung möglichst von ihren angestammten Aufgaben freigestellt werden.
Die Lerneinheiten sollten jeweils zeitlich so gestaltet werden, dass die Inhalte auch aufgenommen werden können. Wenn nicht anders möglich, muss ggf. auch Zeit für die Erledigung der wichtigsten Aufgaben verbleiben.

Im Fall externer TrainerInnen muss darauf geachtet werden, dass sie im Zuge der Schulung nicht Kenntnis über sensible Informationen erhalten.

Nach der Schulungs-/Awarenessmaßnahme sollte ihr Erfolg und ihre Effizienz überprüft werden:
  • Wurden alle betroffenen MitarbeiterInnen erreicht?
  • Wurden die Inhalte verstanden?
  • Waren die MitarbeiterInnen mit der Schulungs-/Awarenessmaßnahmen zufrieden?
  • Gibt es (sachlich begründeten) Bedarf für weitere Schulungen?
  • Hat sich die Einstellung der MitarbeiterInnen gegenüber Sicherheitsmaßnahmen positiv geändert? Dies ist allerdings nicht einfach zu ermitteln, da es zu keinen mißbräuchlichen Überwachungsaktionen kommen darf.
Methoden, um den Erfolg nachzuprüfen, können sein:
  • Fragebögen mit Bewertungen der Teilnehmer
  • Fragebögen mit Fragen aus dem gelernten Stoff
  • Diskussionsmeeting Management/Sicherheitsbeauftragte/MitarbeiterInnen nach der Schulungs-/Awarenessmaßnahme

Dokumentation von Schulungs-/Awarenessmaßnahmen:

Am Schluss einer Aus- oder Weiterbildungsmaßnahme sollte jedem Teilnehmer/jeder Teilnehmerin eine Teilnahmebestätigung übergeben werden, ggf. kann auch ein positives Absolvieren dargestellt werden. Die Organisation sollte für alle MitarbeiterInnen im Personalakt festhalten, welche Schulungs-/Awarenessmaßnahmen absolviert wurden.

Flankierende Schulungs- und Awarenessmaßnahmen:

Abgesehen von „klassischen“ Schulungs-/Awarenessmaßnahmen bieten sich zur kontinuierlichen Weiterbildung an:
  • Informationsforum zur Informationssicherheit im Intranet
  • Anmeldebildschirm mit Sicherheitsinformationen resp. 1-2 Quizfragen
  • Rundschreiben, E-Mails, Zeitschriften mit sicherheitsrelevanten Themen
  • Mitarbeiterzeitung, Poster und Broschüren
  • interne Informationsveranstaltungen
  • externe Seminare, Messen und Konferenzen
  • E-Learning-Programme
  • Planspiele zur Informationssicherheit
  • Diskussionsmeetings (Round-Tables)

Flankierende Schulungs- und Awarenessmaßnahmen:

Vor dem Hintergrund ständig neuer Anwendungen, IT-Systemen, Bedrohungen, Schwachstellen und möglicher Abwehrmaßnahmen ist eine ständige Auffrischung und Erweiterung des Wissens über Informationssicherheit erforderlich.
Daher sollte das Schulungsangebot sowohl für neue wie auch für erfahrene MitarbeiterInnen in regelmäßigen Abständen Auffrischungs- und Ergänzungskurse vorsehen. Die Schulungsprogramme selbst müssen regelmäßig aktualisiert und an neue Gegebenheiten angepasst werden.
[Quelle: BSI B 1.13, M 2.312]

3.3 Interne ISMS Audits

Interne Audits dienen zur Überprüfung, ob Ziele, Vorgaben, Maßnahmen und Verfahren innerhalb der eigenen Organisation:
  • die gesetzlichen und normativen Vorschriften erfüllen,
  • nach wie vor geeignet sind, um die Informationssicherheitsziele zu erreichen,
  • korrekt umgesetzt sind und von allen Beteiligten eingehalten werden,
  • einwandfrei funktionieren und wirksam sind.
Interne Audits sind bei Akkreditierungen meist eine notwendige Vorleistung für extern durchgeführte Akkreditierungs- oder Zertifizierungsaudits. Weiterer Nutzen liegt im Erkennen von:
  • Schulungs- und Informationsbedarf der Führungskräfte und MitarbeiterInnen
  • Verbesserungspotenzial bei Geschäftsprozessen und Sicherheitsmaßnahmen
  • Möglichkeiten zur Optimierung der Organisation
  • sowie in der Motivation der MitarbeiterInnen, da sie ihre Gedanken im Rahmen des Audits einbringen können und sollen

3.3.1 Planung und Vorbereitung interner Audits

ISO Bezug: 27001 6

Interne Audits sollten einmal pro Jahr durchgeführt werden und dabei nicht in Zeiten hoher Arbeitsbelastungen (Systemumstellungen, Rechnungsabschlüsse etc.) oder reduzierter Ressourcen (Urlaubszeit) fallen.
Interne Audits können im Vergleich zu zeitlich begrenzteren externen Akkreditierungs- bzw. Zertifizierungsaudits wesentlich umfassender erfolgen, tiefer in die Themen eindringen und können jeweils nach und nach Teilbereiche der Organisation umfassen. Damit können Schwachstellen besser erkannt und zielgerichtete Verbesserungen eingeleitet werden.

Die Managementebene muss den Auditprozess initiieren und mittragen sowie dafür sorgen, dass den AuditorInnen und teilnehmenden MitarbeiterInnen ausreichend Zeit und Sachressourcen (Konferenzraum, PC) zur Verfügung gestellt werden. Das Audit sollte nach einem Auditplan verlaufen, welcher der Managementebene sowie allen Beteiligten bzw. Betroffenen vorab bekannt gegeben wird. Der Auditplan enthält eine konkrete Checkliste, nach der die AuditorInnen die Audit-Themen Punkt für Punkt durchgehen und die u. a. enthält:
  • Datum
  • Zeit
  • Thema
  • Teilnehmer
  • Erledigungsvermerk

Anforderungen an die Durchführung des Audits und die Verantwortlichkeiten sind festzulegen und zu dokumentieren, ebenso die Anforderungen an die Ergebnisdokumentation. Werden im Zuge des Audits vertrauliche Dokumentationen benötigt, so ist für deren ausreichenden Schutz zu sorgen.
Bei der Planung des Auditprogramms ist zu priorisieren, welche Bedeutung die zu untersuchenden Bereiche haben und in welchem Status (Planung/Etablierung/Test/produktiver Betrieb) sie sich befinden; ebenso müssen die Ergebnisse aus früheren Audits einfließen.

Anforderung an AuditorInnen:

Die Managementebene muss einen oder mehrere AuditorInnen benennen, an die allerdings Anforderungen zu stellen sind:
Objektivität und Unparteilichkeit:
  • AuditorInnen dürfen nur Bereiche auditieren, in denen sie nicht selbst tätig sind
  • bzw. für welche sie nicht verantwortlich sind
Fachliche Qualifikationen:
  • ausreichende Schul- und Berufsausbildung um die Geschäftsprozesse und Sicherheitsmaßnahmen zu verstehen
  • Kenntnis der relevanten Gesetze und Normen, inkl. für das Audit relevante Normen (z. B. ISO 19011)
  • Kenntnis der Unternehmens- und Sicherheitsziele sowie der wesentlichen Abläufe und Prozesse
  • Kenntnisse der wesentlichen Themen der Informationssicherheit
  • Schulung um Audits durchführen zu können (Methodik, Fragetechnik, Analyse, Bewertung, Berichtswesen)
Persönliche Fähigkeiten:
  • Klare und verständliche mündliche und schriftliche Ausdrucksweise
  • Aktives Zuhören
  • Ausdauer, Belastbarkeit, Festigkeit auch in Stresssituationen
  • Einfühlungsvermögen zugleich mit Beharrlichkeit
  • Erkennen von größeren Zusammenhängen und Konsequenzen aus Einzelinformationen

3.3.2 Durchführung interner Audits

ISO Bezug: 27001 6

AuditorInnen und Beteiligte aus den zu auditierenden Organisationseinheiten haben sich vorzubereiten (Auditplan, Programm, Checkliste, Handbücher, Systembeschreibungen, Sicherheitskonzept, …). Meist beginnt ein Audit mit einem Gespräch der AuditorInnen und maßgeblichen MitarbeiterInnen. Mitglieder der Managementebene sollten nach Möglichkeit anwesend sein.
Zunächst erklären die AuditorInnen die Zielsetzung des Audits, der vorläufige Zeitplan wird besprochen, vor allem wann welche MitarbeiterInnen zur Verfügung stehen sollen.

Detailüberprüfungen finden meist im Gespräch mit den jeweils befassten MitarbeiterInnen - wenn möglich - an deren Arbeitsplatz statt. Dabei werden die Unterlagen (Vorgaben, Systembeschreibungen, Dokumentationen, Arbeitsanweisungen) durchgegangen und Fragen gestellt/beantwortet. Es ist oft sinnvoll, mit aktuellen Themen zu beginnen. Es liegt an den AuditorInnen, ein konstruktives und positives Klima zu schaffen - etwa indem zu Ideen und Beiträgen für Verbesserungsmaßnahmen ermuntert wird und diese notiert werden. Damit werden auch allfällige Ängste vor Notizen genommen. Werden Abweichungen von einer Vorgabe erkannt, so sollte nach weiteren Beispielen gefragt werden, um allfällige systematische Abweichungen aufzudecken. Diese sind relevant für Verbesserungsmaßnahmen: das Problem kann an der Einhaltung, aber auch an den Vorgaben liegen.

Inhaltliche Grundlage des internen Audits sind die Vorgaben (Gesetze, Normen, Geschäftsziele, Sicherheitspolitik, Sicherheitskonzept, …). Es ist zunächst zu hinterfragen:
  • Sind die Vorgaben geeignet, die relevanten Gesetze einzuhalten und Normen zu erfüllen?
  • Welche Vorgaben sind vorhanden? Sind sie den befassten Personen bekannt und werden sie verstanden?
  • Sind die Vorgaben vollständig und klar formuliert?
  • Gehen aus den Vorgaben die Verantwortlichkeiten und Zuständigkeiten hervor?
  • Beschreiben die Vorgaben jeweils geschlossene Workflows (Eingabe/Verarbeitung/Ausgabe-Ergebnis)?
  • Gibt es Vorgaben zur Protokollierung von Abweichungen/Vorfällen?
  • Wurden allfällige Verbesserungsmaßnahmen aus dem letzten Audit umgesetzt und wie?

Der nächste Fragenkomplex betrifft ihre Einhaltung:
  • Welche Nachweise sind vorgesehen, um die Einhaltung kontrollieren und überprüfen zu können?
  • Gibt es Vorgaben, die nicht angewendet werden?
  • Gibt es umgekehrt durchgeführte Tätigkeiten, für die keine Vorgaben existieren?
  • Wie exakt werden die Vorgaben bei der praktischen Tätigkeit eingehalten?
  • Gab es Sicherheitsvorfälle, konnten solche anhand der Vorgaben behoben werden/musste improvisiert werden?
  • Gab es Änderungen bei den Vorgaben aufgrund von Sicherheitsvorfällen?
  • Werden die jeweiligen Tätigkeiten in der Praxis dokumentiert und wie (Arbeitsaufzeichnungen, Tagesprotokolle, …)?
  • Welche dokumentierten Hinweise über die Wirksamkeit der Vorgaben / Maßnahmen gibt es (verhinderte Eindringversuche, erfolgte Behebung von Störungen, …)?
  • Welche persönliche Meinung haben die befassten MitarbeiterInnen von den Vorgaben? Halten sie die Vorgaben für sinnvoll?
  • Welche Verbesserungsmaßnahmen schlagen die MitarbeiterInnen vor?

Die Fragenkomplexe werden mit Hilfe der Checkliste durchgegangen. Diese dient aber nur als Leitfaden, situationsbezogen müssen ergänzende Fragen gestellt und beantwortet werden, wenn Vertiefung zum Verständnis notwendig wird oder sich ein Verdacht auf Abweichungen ergibt. Die Erkenntnisse für die AuditorInnen ergeben sich aus den Antworten in Relation mit den schriftlichen Unterlagen.
Schon bei der Frage-/Antwortdiskussion müssen die AuditorInnen auf Objektivität und Unparteilichkeit achten. Meinungsäußerungen, ob eine bestimmte Maßnahme gut oder weniger gut umgesetzt ist, bieten Feedback und können zu einer angeregteren Diskussion beitragen, sollten allerdings gezielt eingesetzt werden. Sinnvoll ist es dabei, nach den Gründen für entdeckte nicht eingehaltene Vorgaben zu fragen (nicht verstanden/Überlastung/mangelnde Information, …). AuditorInnen müssen allerdings speziell darauf achten, dass ihre Fragen stets zum Zweck des Audits und keinesfalls zu ihrer eigenen Weiterbildung gestellt werden.

Am Schluss der Durchführungsphase sollte wiederum ein Gespräch der AuditorInnen mit maßgeblichen MitarbeiterInnen und ManagementvertreterInnen stattfinden. Dabei wird den TeilnehmerInnen für ihre Mitwirkung gedankt und eine Vorschau auf das Ergebnis geboten:
  • Vorläufige Erkenntnisse aus der Befragung und den Unterlagen
  • Zeitpunkt und Art der Berichtslegung (Erkenntnisse, Empfehlungen)
  • Allfällige Möglichkeiten zur Stellungnahme
  • Termin für Schlussdokument und Schlusspräsentation

3.3.3 Ergebnis und Auswertung interner Audits

ISO Bezug: 27001 6

Die Erkenntnisse aus den Befragungen werden den einzelnen Vorgaben und Beschreibungen zugeordnet und von den AuditorInnen analysiert. Dabei ist auf Objektivität zu achten, etwa bei den subjektiv empfundenen Gründen für Abweichungen.
Beispiele für Erkenntnisse, welche Maßnahmen nach sich ziehen müssen:
  • Wesentliche Vorgaben für Arbeitsabläufe fehlen, sind falsch oder mangelhaft.
  • Verantwortlichkeiten oder Zuständigkeiten für Prozesse fehlen oder sind falsch.
  • Vorgaben werden regelmäßig oder gar nicht eingehalten.
  • Bei Sicherheitsvorfällen musste improvisiert werden und die Vorgaben wurden nicht entsprechend modifiziert.
  • Wesentliche vorgegebene Dokumentationen oder Protokolle werden nicht verfasst/geführt.
  • Protokolle werden nicht ausgewertet.

aber auch Erkenntnisse zur Erhöhung der Qualität bzw. allgemeinen Verbesserung:
  • Die Vorgaben sind zu wenig bekannt.
  • Nicht benötigte Vorgaben.
  • Ungünstig formulierte Vorgaben mit hohem Schulungsaufwand.
  • Bedarf für Schulung und Awareness.
  • Prozesse und Abläufe, die vereinfacht oder gar eingespart werden könnten.
  • Bereitstellung besserer Arbeitsmittel.

Die nächste Stufe sind Schlussfolgerungen für das Gesamtsystem, indem etwa versucht wird, Abweichungen und Trends zu finden, die sich durch mehrere Bereiche der Organisation ziehen:
  • Gemeinsamkeiten bei mangelhaften Vorgaben (z. B. unverständliche Formulierung, komplizierte Beschaffung),
  • Systematische Nichteinhaltungen,
  • Single Points of Failure: Konzentration von Zuständigkeiten, aber auch Abweichungen an bestimmten Stellen in der Organisation,
  • Schwachstellen bzw. Lücken im System.

Schließlich erfolgt die gesamtheitliche Auswertung nach:
  • Vorhandensein und Qualität der Vorgaben,
  • Grad ihrer Einhaltung,
  • Wirkungsgrad der Maßnahmen,
  • Tatsächliche (historische) oder künftige (potenzielle) Auswirkungen auf das Erreichen der Sicherheitsziele resp. Ziele der Organisation.
sowie zu:
  • Empfehlungen zur Verbesserung der Vorgaben und ihrer Einhaltung,
  • Empfehlungen zur Verbesserung von Prozessen und Maßnahmen.

Interner Audit Bericht

Der Bericht dient vor allem zur Dokumentation erkannter Schwachpunkte und als Checkliste für Verbesserungsmaßnahmen. Er sollte nicht redundanterweise das System, die Vorgaben oder Maßnahmen beschreiben, sondern kann davon ausgehen, das diese in der Organisation bekannt sind.
Der Bericht sollte kompakt, klar und verständlich formuliert sein und seine Gliederung für alle internen Audits möglichst gleich sein, beispielsweise wie folgt:
  • Formalia (Anlass, auditierte Organisationseinheit(en), AuditorIn, Berichtsdatum, Auditzeitraum, verwendete Unterlagen, allfällige Bereiche die nicht geprüft wurden
  • Management Summary der wesentlichsten Erkenntnisse aus Gesamtsicht
Jeweils pro auditierter Vorgabe:
  • Bezeichnung, Inhalt
  • Feststellungen (etwa: erfüllt/teilweise erfüllt/nicht erfüllt/nicht anwendbar im Einzelfall)
  • Begründungen, Aussagen über die Wirksamkeit von Maßnahmen (wenn möglich)
  • Empfehlungen für Maßnahmen (bei mangelhafter Erfüllung) mit Terminhorizonten bzw. allgemeine Verbesserungsvorschläge (wie Schulungsbedarf)
  • Identifizierte Zuständigkeiten für die Umsetzung

sowie als Gesamtergebnis am Schluss:
  • Eindruck der AuditorInnen über den Ablauf des Audits
  • Zusammenfassung der wesentlichsten Erkenntnisse über alle Bereiche
  • Schlussfolgerungen für das Sicherheitsniveau bzw. die Ziele der Organisation
  • Zusammenfassung und Priorisierung der wichtigsten Verbesserungsvorschläge (betreffend Vorgaben wie Umsetzungen und Einhaltung)
  • Zeithorizont für das nächste Audit (ggf. außerplanmäßiges Nach-Audit bei schwerwiegenden Abweichungen)

Stellungnahmen, Schlussbesprechung

Vor der offiziellen Übergabe des Auditberichts an die Managementebene sollen die betroffenen Personen bzw. Stellen Gelegenheit erhalten, zu den Erkenntnissen Stellung zu nehmen. Immerhin kann es im Zuge des Audits zu Missverständnissen oder beim Verfassen des Berichts zu Darstellungen gekommen sein, welche das Bild verzerren würden.
Eine probate Vorgehensweise besteht in der Vorab-Aussendung des Berichts oder der für die Betroffenen relevanten Teile als „Vorversion zur Stellungnahme“. Es sollte eine angemessene, aber nicht zu lange Frist für die Stellungnahmen gesetzt werden und diese sollten nach Möglichkeit schriftlich erfolgen. Es muss allen Beteiligten klar sein, dass Stellungnahmen nur berücksichtigt werden, um falsche Darstellungen im Bericht zu korrigieren, nicht aber um etwa richtigerweise erkannte Schwachstellen oder Abweichungen wegzudiskutieren. Bei größeren Meinungsverschiedenheiten kann auch ein Gespräch mit den Betroffenen sinnvoll sein. Begründete Stellungnahmen werden in die offizielle Version des Berichts eingearbeitet und diese dem Management übergeben.

An der Schlussbesprechung sollten maßgebliche MitarbeiterInnen der auditierten Organisationseinheiten sowie Mitglieder der Managementebene teilnehmen.

Die AuditorInnen präsentieren dabei das Gesamtergebnis laut Auditbericht (Ablauf des Audits, wesentliche Erkenntnisse, Schlussfolgerungen, Verbesserungsvorschläge, nächstes Audit) und sprechen allfälligen Handlungsbedarf der Managementebene an. Die betroffenen Organisationseinheiten haben die Gelegenheit für Stellungnahmen - etwa betreffend Gründe für im Audit gemachte Feststellungen.

Die Managementebene soll zum Ergebnis Stellung nehmen, erfüllte Vorgaben positiv herausstreichen aber auch seine Entschlossenheit zur Umsetzung wichtiger Verbesserungsmaßnahmen zum Ausdruck bringen. Dabei muss vor allem seitens des Managements darauf geachtet werden, dass das Ziel des Audits und der Schlussbesprechung die Optimierung von Vorgaben sowie Abläufen und des Sicherheitsniveaus ist und es sich keinesfalls um ein Tribunal handelt, bei dem MitarbeiterInnen für Nichteinhaltungen angeklagt werden.

Bei der Schlussbesprechung kann seitens des Managements bereits ein Ausblick über die Umsetzung von Verbesserungsvorschlägen samt Zeithorizont gemacht werden. Jedenfalls sollte ein Ergebnisprotokoll geführt und der Auditdokumentation beigelegt werden. Diese Dokumentation - insbesondere der Auditbericht - ist die inhaltliche Grundlage für ein nun folgendes Management-Review.
Prüfergebnisse und -berichte sind in der Regel besonders vertraulich, daher entsprechend zu schützen.

3.4 Management-Review des ISMS

Die Managementebene hat dafür zu sorgen, dass Maßnahmen zur Behebung von erkannten Schwachstellen, Abweichungen, Nichteinhaltung von Vorgaben etc. ergriffen werden oder aber die Ursachen beseitigt werden. Dies hat ohne unbegründete Verzögerung zu erfolgen, wenn es sich um relevante Schwachstellen handelt.
Eine erfolgreiche Steuerung mit den dafür notwendigen Entscheidungen ist allerdings nur möglich, wenn die Managementebene einen Überblick hat, inwieweit die Sicherheitsziele mit Hilfe der eingesetzten Sicherheitsstrategie und den dafür umgesetzten Maßnahmen tatsächlich erreicht werden konnten. Weiters kann die regelmäßige Durchführung von Management-Reviews eine notwendige Voraussetzung für Akkreditierungen darstellen.

Somit muss die Managementebene das ISMS regelmäßig - zumindest einmal jährlich - überprüfen, ob es aktuell und nachhaltig zur Erreichung der Sicherheits- und Geschäftsziele geeignet und wirksam ist. Eine solche Überprüfung wird als Management-Review bezeichnet. Zielsetzungen sind dabei:
  • Erkennen, Abschätzen und Eliminieren von Fehlern und Schwachstellen
  • Optimieren des Informationssicherheitsprozesses hinsichtlich Effizienz
  • Verbesserung von Strategie, Sicherheitspolitik, -konzept, -maßnahmen, -vorgaben und Abläufen hinsichtlich Praxistauglichkeit und Einsparungspotenzial
  • Optimierung von Kompetenz, Awareness der MitarbeiterInnen,
  • Aufwertung der Unternehmenskultur

3.4.1 Management-Review Methoden

ISO Bezug: 27001 7.1

Sie sollen geeignet sein, einerseits den Sicherheitsprozess, andererseits die Umsetzung der Sicherheitsmaßnahmen auf ihre Angemessenheit, Wirksamkeit und Effizienz zu prüfen. Grundsätzliche Aussagen zu einer solchen Überprüfung und ihren Grundlagen sollten sich daher bereits in der Informationssicherheitsstrategie bzw. Sicherheitspolitik finden.
Wie umfassend und damit aufwändig die Grundlagen sind, hängt nicht zuletzt von der Größe und Komplexität der eigenen Organisation ab. Werden regelmäßig interne oder externe Audits durchgeführt, so sind deren Ergebnisse eine gute Grundlage für Management-Reviews. In kleinen Organisationen können ansonsten jährliche Funktionsprüfungen der IT-Systeme, Durchsicht der Dokumentation hinsichtlich Aktualität und Workshops (mit Ergebnisprotokollen) zur Diskussion von Problemen und Erfahrungen schon ausreichend sein.

Wesentlich ist, dass die Managementebene ein Bild über den aktuellen Stand des Sicherheitsniveaus und allfälligen Handlungsbedarf bekommt:
  • Berichte von internen oder externen Audits (resp. vergleichbaren Erhebungen betreffend Vorgaben und deren Erfüllung)
  • Erkennen, Dokumentation, Auswertung von Sicherheitsvorfällen
  • Allfällige Übungen und Tests zur Simulation von Sicherheitsvorfällen und deren Ergebnisse
  • Ereignisse, Trends, Entwicklungen im Umfeld der eigenen Organisation (Gesetze, Technologien, Angriffe)
Für Fragestellungen im Detail zur Erhebung und zum Erkennen von Schwachstellen und Verbesserungsmöglichkeiten siehe 3.3.2 Durchführung interner Audits.

Relevant für das Management-Review sind allerdings nicht nur aktuell erkannte Erhebungen zu Schwachstellen, sondern es müssen die - mitunter strategischen - Ursachen erforscht und Entscheidungen zur Abhilfe getroffen werden.
Für die Durchführung ist es oft zielführend einen Workshop zu veranstalten, an dem Vertreter der Managementebene, Sicherheitsbeauftragte sowie maßgebliche Führungskräfte oder Spezialisten aus den betroffenen Bereichen (etwa der IT) teilnehmen.
[Quelle: BSI-Standard 100-2]

3.4.1.1 Review der Strategie und des Sicherheitskonzepts

ISO Bezug: 27001 7.2

Dies ist zur kontinuierlichen Anpassung an sich laufend ändernde innere wie äußere Rahmenbedingungen notwendig.
Relevante Aspekte:
  • Gerade der IT-Bereich erweist sich als ausgesprochen schnelllebig. Konzepte, Maßnahmen oder Technologien, die noch vor einigen Jahren als sicher galten, können zum heutigen Zeitpunkt sicherheitstechnisch völlig überholt sein und damit gefährliche Schwachstellen darstellen, wenn man sich in trügerischer Weise darauf verläßt.
  • Änderungen von relevanten Gesetzen, Vorschriften oder Normen können erheblichen Einfluss auf die Geschäftsprozesse und damit auf das Sicherheitskonzept haben.
  • Änderungen innerhalb der eigenen Organisation (neue IT-Systeme, Umzug, neue Organisationsstruktur, Outsourcing) müssen schon in der Planungsphase in das Sicherheitskonzept eingearbeitet werden.
  • Die Wirtschaftlichkeit der Sicherheitsstrategie und spezifischer Sicherheitsmaßnahmen - wenn auch Kosten für die Informationssicherheit schwer zu ermitteln sind - sollte regelmäßig untersucht werden: ob die tatsächlich angefallenen Kosten den ursprünglich geplanten Kosten entsprechen oder ob inzwischen ressourcenschonendere Sicherheitsmaßnahmen verfügbar sind und sinnvoll eingesetzt werden können.
  • Rückmeldungen über Fehler und Schwachstellen in den Prozessen (aus Audits, aber auch Feedbacks von MitarbeiterInnen, GeschäftspartnerInnen oder KundInnen. Beschwerden von KundInnen oder MitarbeiterInnen können ein Indikator für Unzufriedenheit sein, die in der Folge eine Gefahr von fahrlässigen oder vorsätzlichen störenden Handlungen heraufbeschwören und jedenfalls die Effizienz mindern.
[Quelle: BSI-Standard 100-2]

3.4.1.2 Review der Sicherheitsmaßnahmen

ISO Bezug: 27001 7.2

Dies ist zur Sicherstellung der Einhaltung von Maßnahmen bei sich laufend ändernde innere wie äußere Rahmenbedingungen notwendig.
Relevante Aspekte:
  • Die Sinnhaftigkeit von Maßnahmen (Beitrag zum Erreichen von Sicherheitszielen) fällt in das Review der Sicherheitsstrategie
  • Für ihre Umsetzung und Einhaltung ist entscheidend, ob ausreichend personelle, zeitliche und finanzielle Ressourcen zur Verfügung gestellt wurden. Der Grund für mangelhaft umgesetzte bzw. nicht eingehaltene Sicherheitsmaßnahmen können Planungsfehler oder gar unrealistische Annahmen oder Elemente der Sicherheitsstrategie bzw. des Sicherheitskonzepts sein.
  • Ein weiterer Hauptgrund für nicht umgesetzte resp. nicht eingehaltene Sicherheitsmaßnahmen liegt in fehlender Akzeptanz seitens der MitarbeiterInnen. Sie kann nicht erzwungen werden, basiert aber oft im Mangel an Information, Schulung bzw. Bewusstseinsbildung.
  • Wurden Vorgaben nicht eingehalten, so ist zu klären ob es an den Vorgaben (fehlend, nicht bekannt, unverständlich, unklar) oder im Bereich der für die Einhaltung Verantwortlichen liegt (Überlastung, mangelnde Motivation, Klima des Improvisierens).
[Quelle: BSI-Standard 100-2]

3.4.2 Management-Review-Ergebnis und -Auswertung

ISO Bezug: 27001 7.3

Ergebnisse sind bewertete Möglichkeiten für Änderungen resp. Verbesserungen des ISMS, der Sicherheitsstrategie, der Sicherheitspolitik und einzelner Sicherheitsmaßnahmen. Ggf. müssen, aufgrund von Veränderungen der eigenen Organisation oder des Umfelds bzw. Erfahrungen von Vorfällen, die Sicherheitsziele abgeändert werden. Jedenfalls müssen die Ergebnisse des Management-Reviews so dokumentiert werden, dass sie für die Entscheidungen und die Umsetzung von Maßnahmen geeignet sind.
Das Änderungs-/Verbesserungspotenzial kann betreffen:
  • Aktualität der erkannten resp. akzeptierten Risiken
  • Wirksamkeit der erkannten resp. akzeptierten Risiken
  • Änderungen von Prozessen, Abläufen aufgrund des Reviews
  • Verfügbarkeit von Ressourcen
  • Schulungs- und Awarenessmaßnahmen, Motivationsförderung
  • Aktualisierung von Dokumentationen
  • Verbesserung der Methoden zur Messung der Wirksamkeit von Maßnahmen
Schließlich sind im Rahmen des Verbesserungsprozesses Entscheidungen zu treffen, ob/wann/welche Verbesserungsmaßnahmen umgesetzt werden, welche Ressourcen ihnen zugeordnet werden und unter welche Verantwortlichkeiten sie fallen.

Es kann sich herausstellen, dass die Sicherheitsziele, die Sicherheitsstrategie oder das Sicherheitskonzept geändert und die Informationssicherheitsorganisation den Erfordernissen angepasst werden sollten.
Unter Umständen ist es sinnvoll, grundlegende Änderungen an der IT-Umgebung vorzunehmen oder Geschäftsprozesse zu verändern, z. B. wenn Sicherheitsziele unter den bisherigen Rahmenbedingungen nicht oder nur umständlich (also mit hohem finanziellen oder personellen Aufwand) erreicht werden können. Wenn solche Veränderungen vorgenommen und Verbesserungen dann umgesetzt werden, schließt sich der Managementkreislauf wieder und es wird erneut mit der Planungsphase begonnen.
[Quelle: BSI-Standard 100-2]

3.5 Verbesserungsprozess beim ISMS

Um das angestrebte und erreichte Sicherheitsniveau dauerhaft zu gewährleisten, müssen alle für die Informationssicherheit relevanten Bereiche einem kontinuierlichen Verbesserungsprozess unterzogen werden:
  • Sicherheitsstrategie, Sicherheitspolitik
  • Sicherheitskonzept
  • Sicherheitsmaßnahmen
  • Abläufe und Verfahren
  • Dokumentation
  • Wissensstand und Awareness bei allen Beteiligten

Ein etablierter und dokumentierter Verbesserungsprozess ist zum einen Voraussetzung für Akkreditierung resp. Zertifizierung, zum anderen darf er nicht als administrativer Overhead gesehen werden, sondern soll alle Aktivitäten und die gesamte Organisation durchdringen. Es handelt sich dabei nicht um eine periodisch wiederkehrende Vorgangsweise, sondern vielmehr um die Summe kleinerer Schritte zur Verbesserung, die vom Management und allen MitarbeiterInnen getragen und umgesetzt werden. Vom Prinzip her ist der Verbesserungsprozess im Bereich der Informationssicherheit vergleichbar mit dem Verbesserungsprozess des Qualitätsmanagements (z. B. nach ISO 9001), der Unterschied liegt in der Sicht auf die behandelten Aspekte und Abläufe (Risikominimierung).

Der Verbesserungsprozess geschieht nicht losgelöst von den Aktivitäten, welche seine Grundlage bilden (Interne ISMS Audits sowie Management Review des ISMS), sondern umfasst vor allem die Umsetzung der dort identifizierten Verbesserungsmaßnahmen.

3.5.1 Grundlagen für Verbesserungen

ISO Bezug: 27001 4.2.4, 8.1, 8.2

Verbesserungen basieren auf Erkenntnissen aus eigenen Betriebsabläufen, Vorschlägen und externen Informationsquellen.
  • Ergebnisse (Berichte, Protokolle) interner und externer Audits
  • Ergebnisse (Berichte, Protokolle) des Management-Reviews
  • Dokumentierte Abwicklungen von Reklamationen bzw. Beschwerden
  • Vorschläge von Sicherheitsbeauftragten
  • Vorschläge von MitarbeiterInnen
  • Erfahrungen anderer vergleichbarer Organisationen
  • Publizierte oder informelle Sicherheitswarnungen
  • Informationen aus Fachpublikationen, Fachtagungen, Mitwirkung in Gremien

Ein Fokus sollte sich auf die Ursachen für erkannte Abweichungen und Gefährdungen richten. Gerade Verbesserungsvorschläge der unmittelbar befassten MitarbeiterInnen bieten ein oft unterschätztes Verbesserungs- bzw. Einsparungspotenzial, darüber hinaus wird die Motivation gestärkt wenn es zur Organisationskultur gehört, dass Mitarbeitervorschläge ernsthaft behandelt werden. Ebenso wertvoll erweisen sich gelebte Kontakte zu Sicherheitsbeauftragten anderer vergleichbarer Organisationen.
[Quelle: BSI M 2.199]

3.5.2 Entscheidungs- und Handlungsbedarf

ISO Bezug: 27001 8.2, 8.3

Dieser ergibt sich für die Managementebene bei:
  • Sicherheitspolitik, Sicherheitskonzept: Aktualisierung, Verbesserung, Anpassung an neue Rahmenbedingungen
  • Sicherheitsmaßnahmen: Eliminieren erkannter Schwachstellen, Umstellung auf alternative Maßnahmen die effizienter sind, in der Praxis besser greifen oder weniger Ressourcen benötigen
  • Implementierung: Verbesserung hinsichtlich korrekter Implementierung und Konfiguration
  • Einhaltung: Organisatorische Maßnahmen, Verbesserung bei Anforderungen, Schulungen, Awareness
  • Auswertung: Verbesserungen bei Protokollierung und Protokollauswertung
  • Mess- und Prüfkriterien: Optimierung der Prozesse, um die Wirksamkeit und Einhaltung von Sicherheitsmaßnahmen feststellen zu können

Korrekturmaßnahmen:

Sie sollen verhindern, dass in der Praxis festgestellte Abweichungen zum Sicherheitskonzept und den Anforderungen erneut auftreten.
Für jede erkannte Abweichung sollte eine Korrekturmaßnahme vorgeschlagen und darüber entschieden werden - inklusive Zeitpunkt und Zuständigkeiten für die Umsetzung. Erkannte Fehler und Schwachstellen müssen ohne unnötigen Verzug eliminiert werden. Dabei kommen je nach Ursache in Frage:
  • Anpassung organisatorischer Maßnahmen und Abläufe.
  • Setzen von personellen Maßnahmen, über Schulungs- bzw. Awarenessprogramme bis hin zu disziplinären Maßnahmen oder Auswechseln von leitenden Personen.
  • Planung von baulichen oder infrastrukturellen Veränderungen.
  • Vornahme von technischen Veränderungen (etwa an Hard- oder Software bzw. Kommunikationseinrichtungen oder Netzwerken).

Umsetzung der Korrekturmaßnahmen:

  • Alle erforderlichen Korrekturmaßnahmen in einem Umsetzungsplan inkl. Terminen festhalten.
  • Im Umsetzungsplan sollen Prioritäten abhängig vom jeweiligen Risiko gesetzt werden.
  • Es müssen jeweils Entscheidungen der Managementebene erfolgen und dokumentiert werden - auch für den Fall, dass eine Korrekturmaßnahme verworfen wird.
  • In der Folge sind jeweils die Verantwortlichen für die Umsetzung zu benennen und mit den notwendigen Ressourcen auszustatten.
  • Kommunikation der umzusetzenden Maßnahmen und Verbesserungen und Abstimmung mit allen Betroffenen.
  • Begleitende Kontrolle, Dokumentation und Information des Managements über Fortschritt, Fertigstellung, allfällige Abänderungen.
  • Möglichst frühzeitige Prüfung der Wirksamkeit.

Vorbeugende Verbesserungsmaßnahmen:

Diese werden aufgrund der Informationslage gemäß 3.5.1 Grundlagen für Verbesserungen festgelegt, obwohl noch keine Schwachstellen wirksam geworden sind. Daher sind sie in vielen Fällen wirtschaftlicher als Korrekturmaßnahmen. Allerdings müssen zuvor nicht nur tatsächlich festgestellte, sondern auch potenzielle Schwachstellen oder Abweichungen untersucht worden sein. Dazu sind insbesondere auch Ergebnisse von:
heranzuziehen.

Ziel ist es, Ursachen für mögliche Abweichungen von den Anforderungen des ISMS zu eliminieren, bevor sie auftreten. Dabei ist wesentlich:
  • Die zu setzenden Maßnahmen müssen in Relation zu den möglichen Auswirkungen des erkannten Problempotenzials stehen, sonst werden sie unwirtschaftlich.
  • Anforderungen an Vorbeugungsmaßnahmen müssen festgelegt werden.
  • Die Art der Maßnahmen entspricht weitgehend dem unter 3.5.2 Entscheidungs- und Handlungsbedarf dargestellten Entscheidungs- und Handlungsbedarf.
  • Ihre Umsetzung entspricht sinngemäß der für Korrekturmaßnahmen.
  • D.h. es sind Umsetzungsplan, Managemententscheidungen, benannte Verantwortliche, bereitzustellende Ressourcen sowie begleitende Kontrolle und Dokumentation notwendig.
Die laufende bzw. erfolgte Umsetzung von Konzeptänderungen oder Maßnahmen zwecks Korrektur oder Vorbeugung ist wiederum Gegenstand des ständigen Verbesserungsprozesses, womit sich der Zyklus schließt.
[Quelle: BSI M 2.199]

4 Risikoanalyse

Dieses Kapitel nimmt Bezug auf ISO/IEC 27002 4 „Risikobewertung und -behandlung“.

Eine wesentliche Voraussetzung für erfolgreiches Informationssicherheitsmanagement ist die Einschätzung der bestehenden Sicherheitsrisiken. In einer Risikoanalyse wird versucht, diese Risiken zu erkennen und zu bewerten und so das Gesamtrisiko zu ermitteln. Ziel ist es, in weiterer Folge dieses Risiko so weit zu reduzieren, dass das verbleibende Restrisiko quantifizierbar und akzeptierbar wird.
Das nachfolgende Kapitel beschreibt die drei heute meist verbreiteten Strategien zur Risikoanalyse - detaillierte Risikoanalyse, Grundschutzansatz und kombinierter Ansatz - und stellt ihre Vor- und Nachteile und ihre typischen Einsatzbereiche gegenüber.

4.1 Risikoanalysestrategien

ISO Bezug: 27002 4.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.
Mögliche Risikoanalysestrategien sind:
  • Detaillierte Risikoanalyse:
    Für alle IT-Systeme wird eine detaillierte Risikoanalyse durchgeführt. Diese Methode führt zu effektiven und angemessenen Sicherheitsmaßnahmen, benötigt jedoch viel Zeit und Aufwand, so dass neben hohen Kosten auch die Gefahr besteht, dass für kritische Systeme nicht schnell genug Schutzmaßnahmen ergriffen werden können.
  • Grundschutzansatz:
    Unabhängig vom tatsächlichen Schutzbedarf wird für alle IT-Systeme von einer pauschalisierten Gefährdungslage ausgegangen. Als Sicherheitsmaßnahmen kommen sog. Grundschutzmaßnahmen (Baseline Security Controls) zum Einsatz. Durch den Verzicht auf eine detaillierte Risikoanalyse spart diese Vorgehensweise Ressourcen und führt schnell zu einem relativ hohen Niveau an Sicherheit. Der Nachteil liegt darin, dass der Grundschutzlevel für das betrachtete IT-System möglicherweise nicht angemessen sein könnte.
  • Kombinierter Ansatz:
    In einem ersten Schritt wird in einer Schutzbedarfsfeststellung (High Level Risk Analysis) der Schutzbedarf für die einzelnen IT-Systeme ermittelt. Für IT-Systeme der Schutzbedarfskategorie „niedrig bis mittel“ wird auf eine detaillierte Risikoanalyse verzichtet. Dies erlaubt eine schnelle und effektive Auswahl von grundlegenden Sicherheitsmaßnahmen bei gleichzeitiger Gewährleistung eines angemessenen Schutzniveaus. IT-Systeme der Schutzbedarfskategorie „hoch bis sehr hoch“ sind einer detaillierten Risikoanalyse zu unterziehen, auf deren Basis individuelle Sicherheitsmaßnahmen ausgewählt werden. Diese Option kombiniert die Vorteile des Grundschutz- und des Risikoanalyseansatzes, da alle IT-Systeme mit hohem Schutzbedarf wirksam und angemessen geschützt werden, und Maßnahmen für die anderen Systeme mit Hilfe des Grundschutzes schnell und effektiv ausgewählt werden können. Sie wird in den meisten Einsatzumgebungen die empfehlenswerte Strategie zur Risikoanalyse darstellen.
Im Folgenden werden die drei angeführten Risikoanalysestrategien näher erläutert.

4.2 Detaillierte Risikoanalyse

ISO Bezug: 27002 4.1

Eine detaillierte Risikoanalyse für ein IT-System umfasst die Identifikation der bestehenden Risiken sowie eine Abschätzung ihrer Größe.
Dazu werden die Werte (Assets), Bedrohungen und Schwachstellen identifiziert und die daraus resultierenden Risiken ermittelt.
Die erstmalige Durchführung einer detaillierten Risikoanalyse und die anschließende Erstellung eines Sicherheitskonzeptes erfordern einen Aufwand, der zumindest im Bereich von Wochen, möglicherweise auch von Monaten liegt.
Eine detaillierte Risikoanalyse umfasst die folgenden Schritte:

Schritt 1: Abgrenzung des Analysebereiches

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

Schritt 2: Identifikation der bedrohten Objekte (Werte, assets)

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

Schritt 3: Wertanalyse (Impact Analyse)

In diesem Schritt wird der Wert der bedrohten Objekte ermittelt.
Die Wertanalyse umfasst im Einzelnen:
  • die Festlegung der Bewertungsbasis für Sachwerte
  • die Festlegung der Bewertungsbasis für immaterielle Werte
  • die Ermittlung der Abhängigkeiten zwischen den Objekten
  • die Bewertung der bedrohten Objekte und der möglichen Schäden (Impact Analyse)

Schritt 4: Bedrohungsanalyse

Die Objekte sind vielfachen Bedrohungen ausgesetzt, die sowohl aus Nachlässigkeit und Versehen als auch aus Absicht resultieren können.
Die Bedrohungsanalyse umfasst:
  • die Identifikation möglicher Bedrohungen (Katastrophen, Fehlbedienung, bewusste Angriffe) und möglicher AngreiferInnen (MitarbeiterInnen, Leasingpersonal, Außenstehende, …)
  • die Ermittlung der Eintrittswahrscheinlichkeiten

Schritt 5: Schwachstellenanalyse

Eine Bedrohung kann nur durch die Ausnutzung einer vorhandenen Schwachstelle wirksam werden. Es ist daher erforderlich, mögliche Schwachstellen des Systems zu identifizieren und ihre Bedeutung zu klassifizieren.
Zu untersuchen sind dabei insbesondere die Bereiche Organisation, Hard- und Software, Personal sowie Infrastruktur.

Schritt 6: Identifikation bestehender Sicherheitsmaßnahmen

Zur Vermeidung unnötiger Aufwände und Kosten sind die bereits existierenden Sicherheitsmaßnahmen zu erfassen und auf ihre Auswirkungen hinsichtlich der Gesamtsystemsicherheit sowie auf korrekte Funktion zu prüfen.
Geplante neue Sicherheitsmaßnahmen müssen mit den existierenden kompatibel sein und eine wirtschaftlich und technisch sinnvolle Ergänzung darstellen.

Schritt 7: Risikobewertung

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

Schritt 8: Auswertung und Aufbereitung der Ergebnisse

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

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

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

4.2.1 Abgrenzung des Analysebereiches

ISO Bezug: 27002 4.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.

4.2.2 Identifikation der bedrohten Objekte (Werte, assets)

ISO Bezug: 27002 4.1

In diesem Schritt sind alle bedrohten Objekte (assets), die innerhalb des festgestellten Analysebereiches liegen, zu erfassen.
Unter den bedrohten Objekten einer Organisation ist alles zu verstehen, was für diese schutzbedürftig ist, also alle Objekte, von denen der Betrieb des IT-Systems und seine Anwendungen und damit die Funktionsfähigkeit der Organisation abhängen. Dazu zählen etwa:
  • physische Objekte:
    beispielsweise Gebäude, Infrastruktur, Hardware, Datenträger, Paperware
  • logische Objekte:
    beispielsweise Software, Daten, Information
  • Personen
  • Fähigkeiten:
    etwa Herstellen eines Produktes oder Erbringen einer Dienstleistung
  • immaterielle Güter:
    beispielsweise Image, Vertrauen in die Institution oder gute Beziehungen zu anderen Organisationen

Zwischen den bedrohten Objekten bestehen grundsätzlich komplexe Abhängigkeiten. Die Vertraulichkeit, Integrität oder Verfügbarkeit eines Objektes setzt vielfach die Vertraulichkeit, Integrität oder Verfügbarkeit eines anderen Objektes voraus. Beispiele dafür sind etwa die Erfordernis einer funktionsfähigen Infrastruktur (Stromversorgung, Klimaanlage, …) für den Betrieb eines IT-Systems oder die Abhängigkeit der Software von unversehrter und verfügbarer Hardware.
Die Identifizierung der bedrohten Objekte sowie ihre nachfolgende Bewertung stellen wesentliche Voraussetzungen für ein erfolgreiches Informationssicherheitsmanagement dar. Dabei ist es den Erfordernissen im Einzelfall anzupassen, in welcher Tiefe und in welchem Detaillierungsgrad die einzelnen Objekte analysiert werden sollen; in vielen Fällen wird eine Zusammenfassung in Gruppen sinnvoll sein und dazu beitragen, den Analyseaufwand zu begrenzen.

4.2.3 Wertanalyse (Impact Analyse)

ISO Bezug: 27002 4.1

In diesem Schritt wird der Wert der im vorangegangenen Schritt identifizierten Objekte ermittelt.
Die Wertanalyse umfasst im Einzelnen:
  • die Festlegung der Bewertungsbasis für Sachwerte
  • die Festlegung der Bewertungsbasis für immaterielle Werte
  • die Ermittlung der Abhängigkeiten zwischen den Objekten
  • die Bewertung der bedrohten Objekte und der möglichen Schäden

4.2.3.1 Festlegung der Bewertungsbasis für Sachwerte

ISO Bezug: 27002 4.1

Zunächst ist zu entscheiden, ob die Bewertung quantitativ oder qualitativ erfolgen soll.
Eine quantitative Bewertung kann etwa beruhen auf
  • dem Zeitwert eines Objektes,
  • dem Wiederbeschaffungswert eines Objektes,
  • dem Wert, den das Objekt für potenzielle AngreiferInnen hätte, oder
  • dem Schaden, der sich aus dem Verlust oder der Modifikation eines zu schützenden Objektes für die betroffene Organisation ergibt.

Eine qualitative Bewertung erfolgt durch Einteilung in Klassen. Beispiele hierfür sind etwa:
  • 3-stufige Bewertung: gering - mittel - hoch
  • 5-stufige Bewertung: unbedeutend - gering - mittel - hoch - sehr hoch
Als Basis für eine qualitative Bewertung ist festzulegen, was die einzelnen Klassen bedeuten bzw. wie sie definiert sind.

4.2.3.2 Festlegung der Bewertungsbasis für immaterielle Werte

ISO Bezug: 27002 4.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.
Eine quantitative Bewertung kann in diesem Fall beruhen auf
  • dem Wert, den das Objekt für einen potenziellen Angreifer hätte (z. B. vertrauliche Information), oder
  • dem Schaden, der sich aus einem Angriff auf das zu schützende Objekt für die betroffene Organisation ergibt.
Es ist zu beachten, dass die potenziellen Schäden den eigentlichen (Zeit- oder Wiederbeschaffungs-)Wert beträchtlich übersteigen können.

4.2.3.3 Ermittlung der Abhängigkeiten zwischen den Objekten

ISO Bezug: 27002 4.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.
So ist etwa die Funktionsfähigkeit der Hardware abhängig von der Funktionsfähigkeit der Stromversorgung und eventuell der Klimaanlage. Die Integrität von Information bedingt die Integrität und Verfügbarkeit der Hard- und Software, die zu ihrer Verarbeitung bzw. Speicherung eingesetzt wird.

4.2.3.4 Bewertung der bedrohten Objekte

ISO Bezug: 27002 4.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.
Durchführung:
  • Die Person, die die Risikoanalyse durchführt, erstellt eine Liste der zu bewertenden Objekte und gibt die Bewertungsbasen vor.
  • Die Bewertung sollte durch die Applikations-/Projektverantwortlichen sowie die betroffenen BenutzerInnen vorgenommen werden.
  • Unterstützung in der Bewertung kann von verschiedenen Abteilungen, etwa Finanzen, Einkauf, IT, … kommen.
  • Es ist Aufgabe derjenigen Person, die die Risikoanalyse durchführt, die einzelnen Bewertungen auf Plausibilität und Konsistenz zu prüfen und ein konsolidiertes Ergebnis zu erarbeiten.

Ergebnis der Wertanalyse:

Aufstellung der bedrohten Objekte und ihrer Werte für die Organisation.

4.2.4 Bedrohungsanalyse

ISO Bezug: 27002 4.1

Lt. [ISO/IEC 13335] ist eine Bedrohung ein „möglicher Anlass für ein unerwünschtes Ereignis, das zu einem Schaden für das System oder die Organisation führen kann“.
Die zu schützenden Objekte sind vielfältigen Bedrohungen ausgesetzt. Im Rahmen der Risikoanalyse müssen diese identifiziert werden, weiters ist ihre Schwere und Eintrittswahrscheinlichkeit abzuschätzen.

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

Für einige umweltbedingte Bedrohungen (etwa Erdbeben, Blitzschlag, Hochwasser, …) liegen statistische Daten vor, die für die Einschätzung hilfreich sein können.
Die Bedrohungsanalyse umfasst im Einzelnen:
  • die Identifikation möglicher Bedrohungen
  • die Ermittlung der Eintrittswahrscheinlichkeiten

4.2.4.1 Identifikation möglicher Bedrohungen

ISO Bezug: 27002 4.1

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

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

4.2.4.2 Bewertung möglicher Bedrohungen

ISO Bezug: 27002 4.1

In diesem Schritt der Risikoanalyse ist zu bestimmen, mit welcher Wahrscheinlichkeit eine Bedrohung im betrachteten Umfeld eintreten wird.
Diese ist abhängig von:
  • der Häufigkeit der Bedrohung (Wahrscheinlichkeit des Auftretens anhand von Erfahrungen, Statistiken, …),
  • der Motivation und den vorausgesetzten Fähigkeiten und Ressourcen einer/eines potenziellen Angreiferin/Angreifers,
  • Einschätzung der Attraktivität und Verwundbarkeit des IT-Systems bzw. seiner Komponenten,
  • Umweltfaktoren und organisationsspezifischen Einflüssen.

Auch die Eintrittswahrscheinlichkeit kann quantitativ oder qualitativ bewertet werden.
Da eine quantitative Bewertung in vielen Fällen eine Genauigkeit vortäuschen könnte, die durch die ungenaue Methode der Schätzung nicht zu rechtfertigen ist, ist in den letzten Jahren ein Trend in Richtung qualitativer Bewertung zu erkennen.
Bewährt haben sich hier etwa drei- bis fünfteilige Skalen, wie beispielsweise:
4: sehr häufig
3: häufig
2: mittel
1: selten
0: sehr selten
Diese allgemeinen Bedeutungen der Skalenwerte sind für den spezifischen Anwendungsbereich zu konkretisieren.
Beispiel:
4: einmal pro Minute
3: einmal pro Stunde
2: einmal pro Tag
1: einmal pro Monat
0: einmal im Jahr

Ergebnis der Bedrohungsanalyse:

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

4.2.5 Schwachstellenanalyse

ISO Bezug: 27002 4.1

Unter einer Schwachstelle (vulnerability) versteht man eine Sicherheitsschwäche eines oder mehrerer Objekte, die durch eine Bedrohung ausgenützt werden kann.
Typische Beispiele für Schwachstellen sind etwa:
  • Mangelnder baulicher Schutz von Räumen mit IT-Einrichtungen
  • Nachlässige Handhabung von Zutrittskontrollen
  • Spannungs- oder Temperaturschwankungen bei Hardwarekomponenten
  • kompromittierende Abstrahlung
  • Spezifikations- und Implementierungsfehler
  • schwache Passwortmechanismen
  • unzureichende Ausbildung, mangelndes Sicherheitsbewusstsein

Eine Schwachstelle selbst verursacht noch keinen Schaden, sie ist aber die Voraussetzung, die es einer Bedrohung ermöglicht, wirksam zu werden und damit ein IT-System zu beeinträchtigen. Auf Schwachstellen, für die eine korrespondierende Bedrohung existiert, sollte daher sofort reagiert werden.
Eine Schwachstellenanalyse ist die Überprüfung von Sicherheitsschwächen, die durch festgestellte Bedrohungen ausgenutzt werden können. Diese Analyse muss sowohl das Umfeld als auch bereits vorhandene Schutzmaßnahmen mit einbeziehen. Es ist wichtig, jede Schwachstelle daraufhin zu bewerten, wie leicht es ist, sie auszunutzen.

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

Ergebnis der Schwachstellenanalyse:

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

4.2.6 Identifikation bestehender Sicherheitsmaßnahmen

ISO Bezug: 27002 4.1

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

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

Wirksame IT-Sicherheit verlangt i. Allg. eine Kombination von verschiedenen Typen von Maßnahmen.
Da die Sicherheitsmaßnahmen, die aufgrund einer Risikoanalyse ausgewählt werden, in der Regel zusätzlich zu bereits bestehenden Maßnahmen eingeführt werden sollen, ist es notwendig, alle bereits existierenden oder geplanten Sicherheitsmaßnahmen zu identifizieren und ihre Auswirkungen zu überprüfen, um unnötigen Aufwand zu vermeiden.

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

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

Ergebnis:

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

4.2.7 Risikobewertung

ISO Bezug: 27002 4.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.
Ziel dieses Schrittes ist es, die Risiken, denen ein IT-System und seine Objekte ausgesetzt sind, zu erkennen und zu bewerten, um auf dieser Basis geeignete und angemessene Sicherheitsmaßnahmen auswählen zu können.

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

Wie diese Größen miteinander verknüpft werden, um die Höhe der Einzelrisiken und des Gesamtrisikos zu bestimmen, ist abhängig von der gewählten Risikoanalysemethode. Wieder können quantitative oder qualitative Bewertungen vorgenommen oder aber beide Möglichkeiten kombiniert werden.
Im Anhang von [ISO/IEC 27005] gibt es vier Beispiele für Methoden zur Risikobewertung.

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

Ergebnis:

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

4.2.8 Auswertung und Aufbereitung der Ergebnisse

ISO Bezug: 27002 4.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.

4.3 Grundschutzansatz

ISO Bezug: 27002 4.1, 4.2

Die im Rahmen dieses Handbuchs 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 sowie den BSI-Katalogen zu Gefährdungen und Sicherheitsmaßnahmen.

4.3.1 Die Idee des IT-Grundschutzes

ISO Bezug: 27002 4.1, 4.2

Ziel des Grundschutzansatzes ist es, den Aufwand für die Erstellung eines Informationssicherheitskonzeptes angemessen zu begrenzen.
Dies wird dadurch erreicht, dass von einer pauschalisierten Gefährdungslage ausgegangen und damit auf eine detaillierte Risikoanalyse verzichtet wird. Die Auswahl der zu realisierenden Sicherheitsmaßnahmen erfolgt auf der Basis vorgegebener Kataloge.

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

Zudem sind Grundschutzmaßnahmen meist stark verbreitet und damit relativ kostengünstig und schnell zu implementieren.
Dem stehen folgende Nachteile gegenüber:
  • Der Grundschutzlevel kann für das betrachtete System zu hoch oder zu niedrig sein. Ist er zu hoch, werden unnötige finanzielle und personelle Ressourcen verbraucht, ist er zu niedrig, bleiben unter Umständen untragbare Risiken bestehen.
  • Aufgrund der fehlenden detaillierten Risikoanalyse kann unter Umständen eine angemessene Reaktion auf sicherheitsrelevante Hard- oder Softwareänderungen schwierig sein.

Die Wahl eines Grundschutzansatzes wird daher in folgenden Fällen empfohlen:
  • Wenn feststeht, dass im betrachteten Bereich nur IT-Systeme mit niedrigem oder mittlerem („normalem“) Schutzbedarf zum Einsatz kommen.
  • Falls in einem Bereich (IT-System, Abteilung, …) noch keine oder offensichtlich zu schwache Sicherheitsmaßnahmen vorhanden sind, kann die Realisierung von Grundschutzmaßnahmen dazu beitragen, rasch ein relativ gutes Niveau an IT-Sicherheit zu erreichen. In diesem Fall sollte aber in einem nachfolgenden Schritt geprüft werden, ob das erreichte Niveau bereits ausreichend ist oder weitere Analysen und Maßnahmen erforderlich sind.
  • Als Teil eines umfassenden Risikoanalysekonzeptes („kombinierter Ansatz“):
    Wird zunächst in einem ersten Schritt festgestellt, welche IT-Systeme besonders schutzbedürftig sind („Schutzbedarfsfeststellung“), so besteht die Möglichkeit, den Arbeitsaufwand für die Risikoanalyse und die Auswahl spezifischer Sicherheitsmaßnahmen auf diese hochschutzbedürftigen Systeme zu konzentrieren. Für alle anderen Systeme können Grundschutzmaßnahmen eingesetzt werden, ohne damit unangemessene Sicherheitsrisiken einzugehen. Details dazu siehe 4.4 Kombinierter Ansatz.

4.3.2 Grundschutzanalyse und Auswahl von Maßnahmen

ISO Bezug: 27002 4.1, 4.2

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

Eine Grundschutzanalyse besteht im Wesentlichen aus den folgenden beiden Teilschritten:
Schritt 1: Nachbildung eines IT-Systems oder eines IT-Verbundes (Kombination mehrerer IT-Systeme) durch vorhandene Bausteine („Modellierung“)
Schritt 2: Soll-Ist-Vergleich zwischen vorhandenen und empfohlenen Maßnahmen

4.3.2.1 Modellierung

ISO Bezug: 27002 4.1, 4.2

Die Modellierung eines IT-Systems oder eines IT-Verbundes ist abhängig vom zugrunde liegenden Baustein- und Maßnahmenkatalog, da versucht werden muss, das System durch die vorhandenen Bausteine möglichst genau nachzubilden.
Eine der umfassendsten und ausgereiftesten Sammlungen von Bausteinen und Maßnahmen stellen die Grundschutz-Standards und -Kataloge des BSI ( [BSI GSHB]) dar. Anhand dieses Werkes soll nachfolgend die Modellierung eines IT-Verbundes beschrieben werden.

Zentrale Aufgabe des Schrittes „Modellierung“ ist es, den betrachteten IT-Verbund mit Hilfe der vorhandenen Bausteine des IT-Grundschutzes nachzubilden. Als Ergebnis wird ein Modell des IT-Verbundes erstellt, das aus verschiedenen, ggf. auch mehrfach verwendeten Bausteinen des Handbuchs besteht und eine Abbildung zwischen den Bausteinen und den sicherheitsrelevanten Aspekten des IT-Verbundes beinhaltet.
Um die Abbildung eines i. Allg. komplexen IT-Verbunds auf die Bausteine des Handbuchs zu erleichtern, bietet es sich an, die Sicherheitsaspekte gruppiert nach bestimmten Themen zu betrachten.

Abbildung 1: Schichten des IT-Grundschutzmodells nach BSI Grundschutz

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

Die in diesem Schritt zu leistende Aufgabe besteht darin, das reale IT-System durch die vorhandenen Bausteine möglichst genau nachzubilden.
Abschließend sollte überprüft werden, ob die Modellierung des Gesamtsystems vollständig ist und keine Lücken aufweist. Es wird empfohlen, hierzu den Netzplan oder eine vergleichbare Übersicht über den IT-Verbund heranzuziehen und die einzelnen Komponenten systematisch durchzugehen. Jede Komponente sollte entweder einer Gruppe zugeordnet oder einzeln modelliert worden sein.
Wichtig ist, dass nicht nur alle Hard- und Softwarekomponenten in technischer Hinsicht nachgebildet sind, sondern dass auch die zugehörigen organisatorischen, personellen und infrastrukturellen Aspekte vollständig abgedeckt sind.

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

ISO Bezug: 27002 4.1, 4.2

Im zweiten Schritt der Grundschutzanalyse wird die Modellierung nach IT-Grundschutz als Prüfplan verwendet, um festzustellen, welche Standardsicherheitsmaßnahmen bereits umgesetzt wurden, bzw. welche nicht oder unzureichend umgesetzt wurden.
Das Soll besteht aus den in den einzelnen Bausteinen empfohlenen Maßnahmen. Der Vergleich mit den vorhandenen Maßnahmen ergibt als Resultat die Maßnahmen, die es noch für den IT-Grundschutz umzusetzen gilt.

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

4.3.3 Vorgehen bei Abweichungen

ISO Bezug: 27002 4.1, 4.2

Für die Errichtung eines IT-Grundschutzes sollten zwar prinzipiell alle im Baustein vorgeschlagenen IT-Grundschutzmaßnahmen umgesetzt werden, es besteht jedoch die Möglichkeit, dass bei bestimmten Einsatzumgebungen empfohlene Grundschutzmaßnahmen nicht umgesetzt werden können oder sollten. Diese Abweichung von der Empfehlung ist dann zu dokumentieren und zu begründen.
An dieser Stelle sollten auch eventuell vorhandene über den IT-Grundschutz hinausgehende IT-Sicherheitsmaßnahmen herausgearbeitet und dokumentiert werden.

4.3.4 Dokumentation der Ergebnisse

ISO Bezug: 27002 4.1, 4.2

Aus der beschriebenen Vorgehensweise soll als Ergebnis eine Liste von Maßnahmen erstellt werden, die es für die Erreichung des IT-Grundschutzes noch umzusetzen gilt.
Zu jeder Maßnahme sollten
  • der Umsetzungsgrad (ja/teilweise/nein/entbehrlich)
sowie, soweit zu diesem Zeitpunkt bereits möglich,
  • die Verantwortlichkeiten für die Umsetzung
  • der Zeitpunkt für die Umsetzung und
  • eine Kostenschätzung
angegeben werden.

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

4.4 Kombinierter Ansatz

ISO Bezug: 27002 4.1, 4.2

Die Stärken beider oben diskutierter Risikoanalysestrategien - Zeit sparende Auswahl kostengünstiger IT-Sicherheitsmaßnahmen durch Grundschutzanalysen und wirksame Reduktion hoher Sicherheitsrisiken durch detaillierte Risikoanalysen - kommen in einem sog. kombinierten Ansatz zum Tragen.
Dabei wird zunächst ermittelt, welche IT-Systeme hohe oder sehr hohe Sicherheitsanforderungen haben, und welche niedrige bis mittlere haben (Schutzbedarfsfeststellung). Das Ergebnis dieses Schrittes ist eine Einteilung in zwei Schutzbedarfskategorien: „niedrig bis mittel“ und „hoch bis sehr hoch“.

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

Alternativ dazu können auch etwa drei Schutzbedarfskategorien gewählt werden (siehe 4.4.1 Festlegung von Schutzbedarfskategorien, 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 (evtl. in verstärktem Maße) anzuwenden, oder es ist eine detaillierte Risikoanalyse durchzuführen. IT-Systeme der Schutzbedarfskategorie „sehr hoch“ sind jedenfalls einer detaillierten Risikoanalyse zu unterziehen, auf deren Basis individuelle Sicherheitsmaßnahmen ausgewählt werden.

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

Vorteile eines kombinierten Ansatzes

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

Empfehlung:

Aus diesen Gründen kann für die Mehrheit der Fälle empfohlen werden, als Risikoanalysestrategie einen kombinierten Ansatz zu wählen.

4.4.1 Festlegung von Schutzbedarfskategorien

ISO Bezug: 27002 4.1, 4.2

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

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

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

Eine andere Möglichkeit besteht darin, drei Schutzbedarfskategorien zu definieren:
Schutzbedarfskategorie „normal“:
Die Schadensauswirkungen sind begrenzt und überschaubar. Maßnahmen des IT-Grundschutzes reichen i. Allg. aus. Diese Kategorie entspricht der obigen Kategorie „niedrig bis mittel“.
Schutzbedarfskategorie „hoch“:
Die Schadensauswirkungen können beträchtlich sein. Wahlweise können weiter (verstärkte) Grundschutzmaßnahmen eingesetzt oder eine detaillierte Risikoanalyse durchgeführt werden.
Schutzbedarfskategorie „sehr hoch“:
Die Schadensauswirkungen können ein existentiell bedrohliches, katastrophales Ausmaß erreichen. IT-Grundschutzmaßnahmen alleine reichen nicht aus, die erforderlichen Sicherheitsmaßnahmen sollten individuell auf Basis einer Risikoanalyse ermittelt werden.

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

4.4.2 Schutzbedarfsfeststellung

ISO Bezug: 27002 4.1, 4.2

Die Schutzbedarfsfeststellung bildet die Grundlage für eine Entscheidung über die weitere Vorgehensweise und ist daher mit entsprechender Sorgfalt durchzuführen.
Die Schutzbedarfsfeststellung erfolgt in 3 Schritten:
  • Schritt 1: Erfassung aller vorhandenen oder geplanten IT-Systeme
  • Schritt 2: Erfassung der IT-Anwendungen und Zuordnung zu den einzelnen IT-Systemen
  • Schritt 3: Schutzbedarfsfeststellung für jedes IT-System

4.4.2.1 Erfassung aller vorhandenen oder geplanten IT-Systeme

ISO Bezug: 27002 4.1, 4.2

Zunächst werden die vorhandenen und geplanten IT-Systeme aufgelistet. Hierbei steht die technische Realisierung eines IT-Systems im Vordergrund, z. B. Stand-Alone-PC, Server, PC-Client, Windows-Server. An dieser Stelle soll nur das System als solches erfasst werden (z. B. Windows-Server), nicht die einzelnen Bestandteile, wie Rechner, Tastatur, Bildschirm, Drucker etc., aus denen das IT-System zusammengesetzt ist.
Zur Reduktion der Komplexität kann man gleiche IT-Systeme zu Gruppen zusammenfassen, wenn von Anwendungsstruktur und -ablauf vergleichbare Anwendungen auf diesen Systemen laufen. Dies gilt insbesondere für PCs, die oft in großer Anzahl vorhanden sind („Sekretariats-PCs“).

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

ISO Bezug: 27002 4.1, 4.2

Ziel dieses Schrittes ist es, alle oder zumindest die wichtigsten auf dem betrachteten IT-System laufenden oder geplanten IT-Anwendungen zu erfassen.
Diese sollten anschließend - soweit zu diesem Zeitpunkt bereits möglich - nach ihrem Sicherheitsbedarf vorsortiert werden. Dabei sind zuerst diejenigen Anwendungen des jeweiligen IT-Systems zu benennen,

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

4.4.2.3 Schutzbedarfsfeststellung für jedes IT-System

ISO Bezug: 27002 4.1, 4.2

In dieser Phase soll die Frage beantwortet werden, welche Schäden zu erwarten sind, wenn Vertraulichkeit, Integrität oder Verfügbarkeit einer IT-Anwendung 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 BenutzerInnen der betrachteten IT-Anwendungen nach ihrer Einschätzung zu befragen.
Als Orientierungshilfe für die Einordnung von IT-Anwendungen in Schutzbedarfskategorien kann die in 4.4.1 Festlegung von Schutzbedarfskategorien angeführte Tabelle dienen. Es ist aber empfehlenswert, eine den spezifischen Anforderungen der betroffenen Organisation entsprechende modifizierte Tabelle zu erstellen.

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

4.4.3 Durchführung von Grundschutzanalysen und detaillierten Risikoanalysen

ISO Bezug: 27002 4.1, 4.2

Für alle IT-Systeme der Schutzbedarfskategorie „niedrig bis mittel“ bzw. „normal“ ist eine Grundschutzanalyse gemäß der in 4.3 Grundschutzansatz beschriebenen Vorgehensweise durchzuführen.
Alle IT-Systeme der Schutzbedarfskategorie „hoch bis sehr hoch“ sind einer detaillierten Risikoanalyse zu unterziehen. Die Auswahl einer konkreten Methode zur Risikoanalyse sowie der eventuelle Einsatz eines Tools zur Unterstützung dieser Analyse bleiben der durchführenden Institution überlassen. Details dazu finden sich in 4.2 Detaillierte Risikoanalyse.

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

4.5 Akzeptables Restrisiko

ISO Bezug: 27002 4.2

Sicherheitsmaßnahmen können für gewöhnlich Risiken nur teilweise mindern. I. Allg. verbleibt ein Restrisiko, dessen Abdeckung wirtschaftlich nicht mehr vertretbar wäre. Es ist notwendig, diese Restrisiken so exakt wie möglich zu quantifizieren und sie dann bewusst zu akzeptieren. Dieser Prozess wird als „Risikoakzeptanz“ bezeichnet.
Um ein organisationsweit einheitliches Niveau des Restrisikos zu gewährleisten, ist es hilfreich, diesen Prozess durch generelle Richtlinien zu unterstützen. Diese sollten im Rahmen der Informationssicherheitspolitik definiert werden (vgl. 5.2.4 Risikoanalysestrategien, akzeptables Restrisiko und Akzeptanz von außergewöhnlichen Restrisiken) und festlegen, welche Risiken die betroffene Organisation generell zu akzeptieren bereit ist.

Dabei ist zu beachten, dass durch Kumulationseffekte oder gegenseitige Beeinflussungen eine Reihe von kleinen Einzelrisiken zu einem inakzeptablen Restrisiko führen kann.
Die Entscheidung über die Akzeptanz von Restrisiken ist daher immer eine für das spezielle System zu treffende Managemententscheidung.

4.6 Akzeptanz von außergewöhnlichen Restrisiken

ISO Bezug: 27002 4.2

Verbleibt nach Durchführung aller vorgesehenen Sicherheitsmaßnahmen ein Restrisiko, das höher ist als das generell akzeptable, so sollten zusätzliche Sicherheitsmaßnahmen vorgesehen und damit das Risiko weiter reduziert werden.
Ist dies technisch nicht möglich oder unwirtschaftlich, so besteht in begründeten Ausnahmefällen die Möglichkeit, dieses erhöhte Restrisiko bewusst anzunehmen.
Die Entscheidung über die Akzeptanz eines außergewöhnlichen Restrisikos ist durch das Management zu treffen, die genauen Verantwortlichkeiten dafür sind in der Informationssicherheitspolitik festzulegen. Die Entscheidung ist schriftlich zu begründen und durch die Leitung der Organisation in schriftlicher Form zu akzeptieren.

5 Informationssicherheitspolitik

Dieses Kapitel nimmt Bezug auf ISO/IEC 27001 - 4 „Informationssicherheitsmanagementsystem“ sowie ISO 27002 - 5 „Sicherheitspolitik“.
Die Informationssicherheitspolitik bildet die Basis für die Entwicklung und die Umsetzung eines risikogerechten und wirtschaftlich angemessenen Informationssicherheitskonzeptes. Sie stellt ein Grundlagendokument dar, das die sicherheitsbezogenen Ziele, Strategien, Verantwortlichkeiten und Methoden langfristig und verbindlich festlegt.
Die organisationsweite Informationssicherheitspolitik soll allgemeine Festlegungen treffen, die den Schutz der Informationen und der IT-Systeme innerhalb einer Organisation gewährleisten. Diese Richtlinien werden in den nachgeordneten Sicherheitsrichtlinien, etwa der E-Mail-Sicherheitsrichtlinie oder der Netzwerksicherheitsrichtlinie, konkret umgesetzt.
Ziel dieses Abschnittes ist es, die Erarbeitung einer Informationssicherheitspolitik zu unterstützen.
Das folgende Kapitel gibt eine Anleitung zur Erstellung einer derartigen Politik und legt die wesentlichen Inhalte fest. Diese sind:
  • Informationssicherheitsziele und -strategien
  • Erklärung der Leitungsebene über die Unterstützung der Ziele des Informationssicherheitsmanagements (Management Commitment)
  • Organisation und Verantwortlichkeiten für Informationssicherheit
  • Risikoanalysestrategien, akzeptables Restrisiko und Risikoakzeptanz
  • Klassifizierung von Daten
  • Klassifizierung von IT-Anwendungen und IT-Systemen, Grundzüge der Business Continuity-Planung
  • Aktivitäten zur Überprüfung und Aufrechterhaltung der Sicherheit
  • Verweise auf weitere Dokumente zum Thema Informationssicherheit, wie etwa Sicherheitsrichtlinien

5.1 Aufgaben und Ziele einer Informationssicherheitspolitik

ISO Bezug: 27001 4.1, 27002 5.1
Eine organisationsweite Informationssicherheitspolitik hat die Aufgabe, die Vertraulichkeit, Integrität und Verfügbarkeit der Information in einer Organisation sicherzustellen.
Dabei gilt:
  • Die Informationssicherheitspolitik wird als schriftliches Dokument erstellt und bildet die Grundlage des Informationssicherheitsmanagements.
  • Die Informationssicherheitspolitik legt Leitlinien fest, schreibt aber keine Implementierung vor.
  • Das Management unterstützt und fördert die Aktivitäten zum Informationssicherheitsmanagement. Die Informationssicherheitspolitik enthält ein explizites Statement des Managements über die Unterstützung der Informationssicherheitsziele (Management Commitment).
  • Die Informationssicherheitspolitik wird offiziell verabschiedet und in Kraft gesetzt.
  • Alle MitarbeiterInnen müssen Kenntnis über die wichtigsten Inhalte der Informationssicherheitspolitik haben. Die direkt mit Informationssicherheit beschäftigten MitarbeiterInnen müssen im Besitz einer aktuellen Version der Informationssicherheitspolitik sein.

Geltungsbereich

Im Bereich der öffentlichen Verwaltung ist zumindest auf Ressortebene eine eigene, ressortspezifische Informationssicherheitspolitik zu erstellen. Bei Bedarf können aus dieser weitere Informationssicherheitspolitiken, etwa auf Behörden- oder Abteilungsebene, abgeleitet werden.
Im Bereich der Privatwirtschaft wird die Erarbeitung einer organisationsweiten Informationssicherheitspolitik zumindest für große bis mittlere Unternehmen empfohlen. Abhängig von der Unternehmensstruktur und den strategischen Zielen kann die Erstellung einer Informationssicherheitspolitik auch für kleinere Unternehmen empfehlenswert sein.

5.2 Inhalte der Informationssicherheitspolitik

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

5.2.1 Informationssicherheitsziele und -strategien

ISO Bezug: 27002 6.1.1

Schritt 1: Festlegung der wesentlichen Informationssicherheitsziele

Im Rahmen der Erstellung der Informationssicherheitspolitik sind zunächst die spezifischen Sicherheitsziele der Organisation zu erarbeiten, die mit dieser Politik erreicht werden sollen.
Beispiele für solche Ziele sind:
  • Gewährleistung der Erfüllung von aus gesetzlichen Vorgaben resultierenden Anforderungen
  • Gewährleistung des Vertrauens der Öffentlichkeit in die betroffene Organisation bzw. die öffentliche Verwaltung i. Allg.
  • Hohe Verlässlichkeit des Handelns, insbesondere in Bezug auf Vertraulichkeit, Richtigkeit und Rechtzeitigkeit.
Dies erfordert:
  • Vertraulichkeit der verarbeiteten Informationen
  • Einhaltung aller Gesetze, Verträge und Regelungen (etwa des Datenschutzgesetzes, des Informationssicherheitsgesetzes, von SLAs - Service Level Agreements - und Normen)
  • Korrektheit, Vollständigkeit und Authentizität der Informationen (Integrität der IT)
  • Rechtzeitigkeit (Verfügbarkeit der Daten und Services)
  • Sicherung der investierten Werte
  • Sicherstellung der Kontinuität der Arbeitsabläufe
  • Reduzierung der im Schadensfall entstehenden Kosten (Schadensvermeidung und Schadensbegrenzung)
  • Gewährleistung des besonderen Prestiges
Neben diesen eher allgemein gültigen Zielen sind die organisationsspezifischen Sicherheitsziele - bezugnehmend auf die spezifischen Aufgaben und Projekte - zu formulieren.
Zur Präzisierung dieser Ziele sind nützlicherweise folgende Fragen zu stellen:
  • Welche Informationen sind besonders schützenswert?
  • Welche Auswirkungen hätte eine gravierende Verletzung der Sicherheit dieser Informationen (Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit)?
  • Welche wesentlichen Entscheidungen hängen von der Genauigkeit, Integrität oder Verfügbarkeit dieser Informationen ab?
  • Welche essentiellen Aufgaben der betreffenden Organisation können bei Kompromittierung dieser Informationen nicht mehr durchgeführt werden?
  • Welche essentiellen Aufgaben der betreffenden Organisation können ohne IT-Unterstützung nicht mehr durchgeführt werden?

Schritt 2: Festlegung des angestrebten Sicherheitsniveaus

In diesem Schritt ist festzulegen, welches Sicherheitsniveau in Bezug auf
  • Vertraulichkeit
  • Integrität und
  • Verfügbarkeit
angestrebt werden soll.

Schritt 3: Ausarbeitung von Strategien für das Informationssicherheitsmanagement

Die Sicherheitsstrategie legt fest, wie die definierten Sicherheitsziele erreicht werden können.
Eine organisationsweite Informationssicherheitspolitik kann und soll lediglich eine High-Level-Beschreibung der gewählten Strategien beinhalten, Detailbeschreibungen sind Aufgabe der nachgeordneten Sicherheitsrichtlinien.
Beispiele für Strategien für das Informationssicherheitsmanagement sind:
  • eine klare Zuordnung aller Verantwortlichkeiten im Informationssicherheitsprozess
  • die Einführung eines QM-Systems
  • die Entwicklung von Sicherheitsrichtlinien für die wichtigsten Systeme, Services und Anwendungen
  • die Etablierung eines organisationsweiten Incident Handling-Plans
  • Orientierung an internationalen Richtlinien und Standards
  • Informationssicherheit als integraler Bestandteil des gesamten Lebenszyklus eines IT-Systems
  • die Förderung des Sicherheitsbewusstseins aller MitarbeiterInnen.

5.2.2 Management Commitment

ISO Bezug: 27002 6.1.2, 6.1.3
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.

5.2.3 Organisation und Verantwortlichkeiten für Informationssicherheit

ISO Bezug: 27002 6.1.3
Um eine Berücksichtigung aller wichtigen Aspekte und eine effiziente Erledigung sämtlicher anfallender Aufgaben zu gewährleisten, ist es erforderlich, die Rollen und Verantwortlichkeiten aller in den Informationssicherheitsprozess involvierten Personen klar zu definieren.
Die Organisation des ISM ist für jede Institution - entsprechend ihrer Größe, Struktur und Aufgaben - spezifisch festzulegen und in der Informationssicherheitspolitik festzuschreiben.
Zentrale Aufgaben im Informationssicherheitsmanagementprozess übernehmen dabei
  • der/die IT-Sicherheitsbeauftragte (zur Wahl der Bezeichnung s. u.)
  • das Informationssicherheitsmanagement-Team
  • die Bereichs-IT-Sicherheitsbeauftragten und
  • die Applikations-/Projektverantwortlichen.
Auf der Ebene der Bundesverwaltung ist zusätzlich in jedem Ressort die Person einer/eines Informationssicherheitsbeauftragten gemäß Informationssicherheitsgesetz einzurichten. Weiters werden für diesen Bereich durch das IKT-Board verbindliche Regelungen zur IKT-Sicherheit vorgegeben.
Es ist zu betonen, dass es sich bei diesen Funktionen bzw. Gremien, die im Folgenden näher beschrieben werden, um Rollen handelt, die - abhängig von der Größe und den Sicherheitsanforderungen einer Organisation - durchaus auch von mehreren Personen wahrgenommen werden können. In diesem Fall ist auf eine genaue Trennung der Kompetenzen und Verantwortlichkeiten Bedacht zu nehmen. Genauso ist es möglich, dass eine Person eine dieser Rollen zusätzlich zu anderen Aufgaben übernimmt. So könnte beispielsweise SystemadministratorInnen als Bereichs-IT-Sicherheitsbeauftragte für dieses System agieren. Dabei ist aber unbedingt darauf zu achten, dass ausreichend Zeit für die sicherheitsrelevanten Tätigkeiten zur Verfügung steht und es zu keinen Kollisionen von Verantwortlichkeiten oder Interessen kommt.
Nachfolgend werden die wichtigsten typischen Aufgaben und Verantwortlichkeiten dieser Funktionen bzw. Gremien kurz beschrieben. Eine detaillierte, auf die speziellen Aufgaben und Anforderungen der betreffenden Organisation abgestimmte Beschreibung ist im Rahmen der organisationsweiten Informationssicherheitspolitik zu geben.

5.2.3.1 Die/Der IT-Sicherheitsbeauftragte

ISO Bezug: 27002 6.1.3
Die/Der IT-Sicherheitsbeauftragte ist die zentrale Ansprechperson für alle Informations- und IT-Sicherheitsfragen innerhalb einer Organisation und trägt die fachliche Verantwortung für diesen Bereich.
Anmerkung: Die Bezeichnung „IT-Sicherheitsbeauftragte/r“ für die Person einer/eines zentralen Sicherheitsverantwortlichen wurde zum einen gewählt, weil es sich um einen in vielen Institutionen sowohl des Behörden- als auch des Privatwirtschaftsbereiches eingeführten Begriff handelt, zum anderen, um diese Rolle gegenüber der Rolle der/des Informationssicherheitsbeauftragten gemäß Informationssicherheitsgesetz abzugrenzen, der/dem ganz spezifische Aufgaben lt. Gesetz zukommen.
Zu den Pflichten der/des IT-Sicherheitsbeauftragten gehören:
  • die verantwortliche Mitwirkung an der Erstellung des Informationssicherheitskonzeptes
  • die Gesamtverantwortung für die Realisierung der ausgewählten Sicherheitsmaßnahmen
  • die Planung und Koordination von Schulungs- und Sensibilisierungsveranstaltungen
  • die Gewährleistung der Informationssicherheit im laufenden Betrieb sowie
  • die Verwaltung der für Informationssicherheit zur Verfügung stehenden Ressourcen.
Die/Der IT-Sicherheitsbeauftragte kann einzelne Aufgaben delegieren, die Gesamtverantwortung für die Informationssicherheit verbleibt aber bei dieser Person.
Der Funktion der/des IT-Sicherheitsbeauftragten kommt eine zentrale Bedeutung zu. Daher sollte diese Rolle in jedem Fall - also auch bei kleinen Organisationen - definiert und klar einer Person, eventuell zusätzlich zu anderen Aufgaben, zugeordnet sein.

5.2.3.2 Das Informationssicherheitsmanagement-Team

ISO Bezug: 27002 6.1.3
Das Informationssicherheitsmanagement-Team ist verantwortlich für die Regelung der organisationsweiten Informationssicherheitsbelange sowie für die Erarbeitung von Plänen, Vorgaben und Richtlinien zur Informationssicherheit.
Zu den Aufgaben des Teams zählen typischerweise:
  • die Festlegung der Informationssicherheitsziele der Organisation
  • die Entwicklung einer organisationsweiten Informationssicherheitspolitik
  • Unterstützung und Beratung bei der Erstellung des Informationssicherheitskonzeptes
  • die Überprüfung des Konzeptes auf Erreichung der Informationssicherheitsziele
  • die Förderung des Sicherheitsbewusstseins in der gesamten Organisation sowie
  • die Festlegung der personellen und finanziellen Ressourcen für Informationssicherheit.
Zusammensetzung des Teams:
Die genaue Festlegung der Zusammensetzung sowie der Aufgaben und Verantwortlichkeiten des Informationssicherheitsmanagement-Teams haben im Rahmen der Informationssicherheitspolitik zu erfolgen.
Generell ist zu empfehlen, dass die IT-Sicherheitsbeauftragten sowie ein/e VertreterIn der IT-AnwenderInnen dem Informationssicherheitsmanagement-Team angehören.

5.2.3.3 Die Bereichs-IT-Sicherheitsbeauftragten

ISO Bezug: 27002 6.1.3
Die Komplexität moderner IT-Systeme erfordert zur Gewährleistung eines angemessenen Sicherheitsniveaus tief gehende Systemkenntnisse. Wenn mehrere unterschiedliche Systemplattformen zum Einsatz kommen, können diese von einer einzelnen Person oft nicht mehr abgedeckt werden. Daher wird es in vielen Fällen empfehlenswert sein, Bereichs-IT-Sicherheitsbeauftragte zu definieren.
Diese haben die fachliche Verantwortung für alle IT-Sicherheitsbelange in einem bestimmten Bereich. Ein Bereich kann beispielsweise ein IT-System oder eine Betriebssystemplattform sein, auch eine Zuordnung nach Abteilungen oder Betriebsstandorten ist denkbar.
Zu den Aufgaben der Bereichs-IT-Sicherheitsverantwortlichen zählen
  • die Mitwirkung bei den ihren Bereich betreffenden Teilen des Informationssicherheitskonzeptes
  • die Erarbeitung eines detaillierten Plans zur Realisierung der ausgewählten Sicherheitsmaßnahmen
  • die Umsetzung dieses Plans
  • die regelmäßige Prüfung der Wirksamkeit und Einhaltung der eingesetzten Sicherheitsmaßnahmen im laufenden Betrieb
  • Information der/des IT-Sicherheitsbeauftragten über bereichsspezifischen Schulungsbedarf sowie
  • Meldungen an die/den IT-Sicherheitsbeauftragten bei sicherheitsrelevanten Ereignissen.

5.2.3.4 Applikations-/Projektverantwortliche

ISO Bezug: 27002 6.1.3
Für jede IT-Anwendung und jedes IT-Projekt ist die fachliche Gesamtverantwortung und damit auch die Verantwortung für deren Sicherheit klar festzulegen.
Zu den Aufgaben der Applikations- oder Projektverantwortlichen zählen insbesondere
  • die Festlegung der Sicherheits- und Qualitätsanforderungen der Applikation bzw. des Projekts
  • die Klassifizierung der verarbeiteten Daten,
  • die Vergabe von Zugriffsrechten sowie
  • organisatorische und administrative Maßnahmen zur Gewährleistung der IT-Sicherheit in der Projektentwicklung und im laufenden Betrieb.
Neben den oben beschriebenen Rollen gibt es im Bereich der Bundesverwaltung eine spezielle, per Gesetz festgelegte Rolle: die/den Informationssicherheitsbeauftragte/n.

5.2.3.5 Die/Der Informationssicherheitsbeauftragte

ISO Bezug: 27002 6.1.3
Auf Ressortebene sind gemäß Informationssicherheitsgesetz Informationssicherheitsbeauftragte zu bestellen.
Aufgaben der/des Informationssicherheitsbeauftragten sind:
  • die Überwachung der Einhaltung der Bestimmungen des Informationssicherheitsgesetzes, der Informationssicherheitsverordnung und der sonstigen Informationssicherheitsvorschriften,
  • die periodische Überprüfung der Sicherheitsvorkehrungen für den Schutz von (lt. Informationssicherheitsgesetz) klassifizierten Informationen,
  • die Berichterstattung darüber an die Informationssicherheitskommission,
  • Behebung von erkannten Mängeln,
  • Sicherheitsüberprüfung von betroffenen Personen gemäß §3 Abs. 1 Z1 und 2 Informationssicherheitsgesetz,
  • Information der Bundesministerin bzw. des Bundesministers des jeweiligen Ministeriums in Angelegenheiten der Informationssicherheit sowie
  • Erstattung von Verbesserungsvorschlägen, falls erforderlich.
Die/Der Informationssicherheitsbeauftragte ist Mitglied der Informationssicherheitskommission.

5.2.3.6 Weitere Pflichten und Verantwortungen im Bereich Informationssicherheit

ISO Bezug: 27002 6.1.3
Sicherheit ist nicht ausschließlich Angelegenheit der damit per Definition betrauten Personen. Alle MitarbeiterInnen, auch wenn sie nicht direkt in den Bereich Informationssicherheit involviert sind, müssen ihre spezifischen Pflichten und Verantwortlichkeiten im Rahmen der Informationssicherheit kennen und erfüllen. Ebenso sind die Rechte und Pflichten von externen Personen, Lieferanten und VertragspartnerInnen festzulegen.
Im Rahmen der organisationsweiten Informationssicherheitspolitik sind daher auch die Aufgaben und Verantwortlichkeiten folgender Personenkreise zu definieren:
  • Management/Behördenleitung („Sicherheit als Managementaufgabe“)
  • Datenverarbeitungs(DV)-Entwicklung und technischer Support
  • DienstnehmerInnen
  • Leasingpersonal, externe MitarbeiterInnen
  • Lieferanten und VertragspartnerInnen

5.2.3.7 Informationssicherheit und Datenschutz

ISO Bezug: 27002 6.1.3, 15.1.4
Auch wenn die Einrichtung einer/eines Datenschutzbeauftragten gesetzlich nicht gefordert ist (vgl. Datenschutzgesetz (DSG 2000)), ist es sinnvoll, in Organisationen, in denen personenbezogene Daten lt. DSG 2000 verarbeitet 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.

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

ISO Bezug: 27002 4.2
Methodisches Risikomanagement ist zur Erarbeitung eines vollständigen und organisationsweiten Informationssicherheitskonzeptes unerlässlich. Um Risiken zu beherrschen, ist es zunächst erforderlich sie zu kennen und zu bewerten. Dazu wird in einer Risikoanalyse das Gesamtrisiko ermittelt. Ziel ist es, dieses Risiko so weit zu reduzieren, dass das verbleibende Restrisiko quantifizierbar und akzeptierbar wird.
In der Informationssicherheitspolitik sollen die Risikoanalysestrategie der Organisation sowie das akzeptable Restrisiko festgelegt werden. Weiters ist die Vorgehensweise bei der Akzeptanz von außergewöhnlichen Restrisiken zu definieren.
Im folgenden Abschnitt werden die wichtigsten Punkte, die im Rahmen der Informationssicherheitspolitik zum Thema Risikoanalyse festgelegt werden sollten, aufgeführt. Details zur Risikoanalyse sind in 4 Risikoanalyse enthalten.

Schritt 1: Festlegung der anzuwendenden Risikoanalysestrategie

Man kann drei Varianten zur Risikoanalysestrategie einer Organisation unterscheiden:
  • Grundschutzansatz:
    Unabhängig von den tatsächlichen Sicherheitsanforderungen werden für alle IT-Systeme Standardsicherheitsmaßnahmen („Grundschutzmaßnahmen“) eingesetzt. Diese Vorgehensweise spart Ressourcen und führt schnell zu einem relativ hohen Niveau an Sicherheit. Der Nachteil liegt darin, dass der Grundschutzlevel für die vorhandenen Geschäftsprozesse und IT-Systeme möglicherweise nicht angemessen sein könnte.
  • Detaillierte Risikoanalyse:
    Für alle Geschäftsprozesse und die sie unterstützenden IT-Systeme wird eine detaillierte Risikoanalyse durchgeführt. Diese Methode gewährleistet die Auswahl von effektiven und angemessenen Sicherheitsmaßnahmen, benötigt jedoch viel Zeit und Aufwand.
  • Kombinierter Ansatz:
    In einem ersten Schritt wird in einer Schutzbedarfsfeststellung (High Level Risk Analysis), ausgehend von den Geschäftsprozessen, der Schutzbedarf für die einzelnen Prozesse, die sie unterstützenden Systeme und die verarbeiteten Informationen ermittelt. Bei normalem Schutzbedarf wird von einer pauschalisierten Gefährdungslage ausgegangen, so dass auf eine detaillierte Risikoanalyse verzichtet und eine Grundschutzanalyse (s. o.) durchgeführt werden kann. Dies erlaubt eine schnelle und effektive Auswahl von grundlegenden Sicherheitsmaßnahmen bei gleichzeitiger Gewährleistung eines angemessenen Schutzniveaus. Bei hohem Schutzbedarf können wahlweise Grundschutzmaßnahmen eingesetzt oder eine detaillierte Risikoanalyse durchgeführt werden. Besteht sehr hoher Schutzbedarf, so sind die betroffenen Geschäftsprozesse und IT-Systeme einer detaillierten Risikoanalyse zu unterziehen, auf deren Basis individuelle Sicherheitsmaßnahmen ausgewählt werden.
Die letzte Option kombiniert die Vorteile des Grundschutzansatzes mit denen einer detaillierten Risikoanalyse und stellt heute die allgemein empfohlene Vorgehensweise dar.

Schritt 2: Festlegung des akzeptablen Restrisikos

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

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

Verbleibt nach Durchführung aller im Sicherheitsplan vorgesehenen Maßnahmen ein Restrisiko, das höher ist als das generell akzeptable und dessen weitere Reduktion technisch nicht möglich oder unwirtschaftlich wäre, so besteht in begründeten Ausnahmefällen die Möglichkeit einer bewussten Akzeptanz des erhöhten Restrisikos.
In der Sicherheitspolitik sind
  • das Vorgehen bei Risiken, die in Abweichung von der generellen Sicherheitspolitik in Kauf genommen werden sollen, sowie
  • die Verantwortlichkeiten dafür
festzulegen.

5.2.5 Klassifizierung von Informationen

ISO Bezug: 27002 7.2
Die Klassifizierung der verarbeiteten, gespeicherten und übertragenen Informationen in Bezug auf ihre Vertraulichkeit und die Datenschutzanforderungen ist wesentliche Voraussetzung für die spätere Auswahl adäquater Sicherheitsmaßnahmen.
Daher sind in der Informationssicherheitspolitik entsprechende Sicherheitsklassen zu definieren und weiters die Verantwortlichkeiten für die Durchführung der Klassifizierung festzulegen.

5.2.5.1 Definition der Sicherheitsklassen

ISO Bezug: 27002 7.2.1

Festlegung von Klassifizierungsstufen bzgl. Vertraulichkeit (Vertraulichkeitsklassen)

Die Vertraulichkeitsklassen können als Maß dafür gesehen werden, welche Auswirkungen ein Missbrauch der Information auf die Institution haben kann.
Im Bereich der Bundesverwaltung sind die unten angeführten hierarchischen Klassen definiert. Diese Klassen sind lt. Informationssicherheitsgesetz gesetzlich festgelegt für „klassifizierte Informationen, die Österreich im Einklang mit völkerrechtlichen Regelungen erhalten hat“.
HINWEIS: Im Sinne der Kompatibilität und Einheitlichkeit erscheint diese Klassifizierung auch für andere Daten im Bereich der Bundesverwaltung sinnvoll.
  • EINGESCHRÄNKT:
    Die unbefugte Weitergabe der Informationen würde den in Art. 20, Abs. 3 B-VG genannten Interessen zuwiderlaufen. [Anmerkung: Alle mit Aufgaben der Bundes-, Landes- und Gemeindeverwaltung betrauten Organe sowie die Organe anderer Körperschaften des öffentlichen Rechts sind, soweit gesetzlich nicht anderes bestimmt ist, zur Verschwiegenheit über alle ihnen ausschließlich aus ihrer amtlichen Tätigkeit bekannt gewordenen Tatsachen verpflichtet, deren Geheimhaltung im Interesse der Aufrechterhaltung der öffentlichen Ruhe, Ordnung und Sicherheit, der umfassenden Landesverteidigung, der auswärtigen Beziehungen, im wirtschaftlichen Interesse einer Körperschaft des öffentlichen Rechts, zur Vorbereitung einer Entscheidung oder im überwiegenden Interesse der Parteien geboten ist (Amtsverschwiegenheit), …]
  • VERTRAULICH:
    Die Informationen stehen nach anderen Bundesgesetzen unter strafrechtlichem Geheimhaltungsschutz und ihre Geheimhaltung ist im öffentlichen Interesse gelegen.
  • GEHEIM:
    Die Informationen sind vertraulich und ihre Preisgabe würde zudem die Gefahr einer erheblichen Schädigung der in Art. 20, Abs. 3 B-VG genannten Interessen schaffen.
  • STRENG GEHEIM:
    Die Informationen sind geheim und ihr Bekanntwerden würde überdies eine schwere Schädigung der in Art. 20, Abs. 3 B-VG genannten Interessen wahrscheinlich machen.
Nicht-klassifizierte Informationen werden nachfolgend auch als „offen“ bezeichnet.
In den übrigen Verwaltungsbereichen und in der Privatwirtschaft ist es jeder Organisation überlassen, in ihrer Informationssicherheitspolitik eine für ihre Zwecke adäquate Definition von Vertraulichkeitsklassen vorzunehmen, sofern es nicht bereits diesbezügliche Regelungen gibt. Aus Gründen der Kompatibilität wird die Anwendung des genannten Schemas in denjenigen Bereichen, in denen nicht zwingende Gründe für ein anderes Klassifizierungsschema bestehen, empfohlen. Allerdings werden Organisationen der Privatwirtschaft, sofern sie nicht besonders strenge Sicherheitsanforderungen haben, i. Allg. mit weniger Klassen (meist 3 oder 4) das Auslangen finden.
Im Rahmen der Informationssicherheitspolitik sollte darauf hingewiesen werden, dass die Klassifizierung der Daten sehr sorgfältig vorzunehmen ist. Nicht nur die Einstufung in eine zu niedrige Vertraulichkeitsklasse ist mit potenziellen 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.

Klassifizierung von Daten in Bezug auf Datenschutz

Werden personenbezogene Daten verarbeitet, so sind die Daten auch dahingehend zu klassifizieren. Die nachfolgende Klassifizierung gemäß Datenschutzgesetz (DSG 2000) gilt sowohl für den Behörden- als auch für den privatwirtschaftlichen Bereich.
  • NUR INDIREKT PERSONENBEZOGEN:
    Der Personenbezug der Daten kann mit rechtlich zulässigen Mitteln nicht bestimmt werden.
  • PERSONENBEZOGEN:
    Angaben über Betroffene (Anmerkung ad Betroffene: Jede vom Auftraggeber verschiedene natürliche oder juristische Person oder Personengemeinschaft, deren Daten verwendet werden), deren Identität bestimmt oder bestimmbar ist.
  • SENSIBEL:
    Daten über rassische und ethnische Herkunft, politische Meinungen, Gewerkschaftszugehörigkeit, religiöse oder philosophische Überzeugungen, Gesundheit oder Sexualleben von natürlichen Personen.

5.2.5.2 Festlegung der Verantwortlichkeiten und der Vorgehensweise für klassifizierte Informationen

ISO Bezug: 27002 7.2.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.
Als allgemeine Richtlinie kann gelten, dass die Klassifizierung einer Information von jener Person vorzunehmen ist, von der diese Information stammt, oder, wenn diese keine eindeutigen Vorgaben gemacht hat, von jener Person in der Organisation, die diese Information von außen erhält.
Weiters ist festzulegen, in welcher Form die Klassifizierung bzw. Deklassifizierung erfolgt und wie klassifizierte Information gekennzeichnet wird.
Die für die Information verantwortlichen MitarbeiterInnen werden oft als „Dateneigner“ oder „Data Owner“ bezeichnet.

5.2.5.3 Erarbeitung von Regelungen zum Umgang mit klassifizierten Informationen

ISO Bezug: 27002 7.2.2
In diesem Schritt ist festzulegen, wie die Information in Abhängigkeit von den Sicherheitsklassen zu behandeln ist.
Werden in einer Organisation häufig klassifizierte Informationen verarbeitet und gespeichert, so empfiehlt sich die Erarbeitung eines eigenständigen Dokumentes, in dem u. a. folgende Fragen behandelt werden:
  • Kennzeichnung klassifizierter Information (sowohl elektronischer als auch nicht elektronischer)
  • Verwahrung klassifizierter Information (Zugriffsberechtigungen, etwaige Vorschriften zur Verschlüsselung)
  • Übermittlung klassifizierter Information (mündliche Weitergabe, persönliche Weitergabe, Versendung durch Post oder Kurier, elektronische Übertragung, über welche Verbindungen, Vorschriften zur Verschlüsselung)
  • Registrierung klassifizierter Information
  • Ausdruck klassifizierter Information (auf welchem Drucker, durch wen)
  • Backup (Klartext, chiffriert, Schutz der Backup-Medien)
  • Aufbewahrung/Wiederverwendung/Vernichtung von Datenträgern mit klassifizierter Information
  • Weitergabe klassifizierter Information (an wen, durch wen, unter welchen Bedingungen)
  • Deklassifizierung klassifizierter Information (wann, durch wen)
Weitere Informationen zum Umgang mit klassifizierten Informationen siehe 7.2 Klassifizierung von Informationen

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

ISO Bezug: 27002 7.2.2
Ziel der Business Continuity-Planung ist es, die Verfügbarkeit der wichtigsten Applikationen und Systeme innerhalb eines definierten Zeitraumes zu gewährleisten sowie Vorkehrungen zur Schadensbegrenzung im Katastrophenfall zu treffen („Gewährleistung eines kontinuierlichen Geschäftsbetriebes“).
Dabei wird unterschieden zwischen der Aufrechterhaltung der Betriebsverfügbarkeit im Fall von Störungen oder Bedienungsfehlern (im Folgenden auch als „Business Contingency-Planung“ bezeichnet) sowie der Gewährleistung eines Notbetriebes und des geordneten Wiederanlaufs im Katastrophenfall (Katastrophenvorsorge, K-Planung).
Im Rahmen der Informationssicherheitspolitik sind die Verfügbarkeitsklassen für IT-Anwendungen und die diesen Anwendungen zugrunde liegenden IT-Systeme sowie der darauf verarbeiteten oder gespeicherten Informationen zu definieren. Die Business Continuity-Planung selbst ist nicht Bestandteil der Informationssicherheitspolitik, sondern muss in den entsprechenden weiteren Aktivitäten erfolgen.
Nachfolgend ein Beispiel für ein solches Klassifizierungsschema – basierend auf den Katastrophenvorsorge- und Ausfallssicherheitsüberlegungen im IT-Bereich des Bundeskanzleramtes [K-Fall]:
  • Betriebsverfügbarkeitskategorie 1 – Keine Vorsorge (unkritisch):
    Für die IT-Anwendung werden keine besonderen Vorkehrungen getroffen. Es ist ein Datenverlust bzw. Ausfall der IT-Anwendung unbestimmter Dauer denkbar. Eine Behinderung in der Wahrnehmung der Aufgaben der betroffenen Verwaltungsstelle entsteht durch den Ausfall bzw. Datenverlust nicht.
  • Betriebsverfügbarkeitskategorie 2 – Offline Sicherung:
    Es sind die gängigen Sicherungsmaßnahmen für die IT-Anwendung vorgesehen, ein Datenverlust ist auszuschließen. Die IT-Anwendung kann bei technischen Problemen erst nach deren Behebung am ursprünglichen Produktivsystem in Betrieb genommen werden. Die Sicherung wird an einen externen Ort ausgelagert.
  • Betriebsverfügbarkeitskategorie 3 – Redundante Infrastruktur:
    Die Infrastruktur für die IT-Anwendung ist derart ausgelegt, dass bei Ausfall einer IT-Komponente der Betrieb durch redundante Auslegung ohne Unterbrechung fortgesetzt werden kann.
  • Betriebsverfügbarkeitskategorie 4 – Redundante Standorte:
    Die IT-Infrastruktur sowie die darauf aufsetzende IT-Anwendung ist auf zwei Standorte verteilt, so dass bei Betriebsunterbrechung des einen Standortes die IT-Anwendung uneingeschränkt am zweiten Standort weiter betrieben werden kann.
Zusätzlich zu den vier genannten Kategorien ist noch die Zusatzqualität „K-Fall sicher“ definiert, welche auch die Anforderungen in Katastrophenfällen berücksichtigt:
  • K-Fall sicher (K2 bis K4):
    Die IT-Anwendung ist derart konzipiert, dass zumindest ein Notbetrieb in einer Zero-Risk-Umgebung möglich ist. Dazu werden die Daten je nach Aktualisierungsgrad laufend in die Zero-Risk-Umgebung transferiert und der Betrieb der IT-Anwendung derart gestaltet, dass ein Wiederaufsetzen eines definierten Notbetriebes in der Zero-Risk-Umgebung umgehend möglich ist.
In Summe ergibt eine derartige Einstufung die Verfügbarkeitsklassen 1 bis 4 und K2 bis K4. Die Zusatzoption „K-Fall sicher“ in Verbindung mit Betriebsverfügbarkeitskategorie 1 ist nicht sinnvoll.
Für nähere Informationen und für Klassifizierungsbeispiele siehe 14.1.1 Definition von Verfügbarkeitsklassen

5.2.7 Überprüfung und Aufrechterhaltung der Sicherheit

ISO Bezug: 27002 5.1.2
Informationssicherheit ist kein durch einmalige Anstrengungen erreichbarer und dann unveränderbarer Zustand. Umfassendes Informationssicherheitsmanagement beinhaltet vielmehr auch die Aufgabe, Informationssicherheit im laufenden Betrieb kontinuierlich zu überprüfen und aufrechtzuerhalten.
Die Informationssicherheitspolitik muss daher Leitlinien und Kennzahlen zur Bewertung der Sicherheit hinsichtlich Angemessenheit, Wirksamkeit und Ordnungsmäßigkeit der eingesetzten Maßnahmen sowie deren Übereinstimmung mit der Informationssicherheitspolitik und dem Informationssicherheits-Konzept vorgeben.

5.2.8 Dokumente zur Informationssicherheit

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

5.3 Lifecycle der Informationssicherheitspolitik

5.3.1 Erstellung der Informationssicherheitspolitik

ISO Bezug: 27002 5.1.1
Die Informationssicherheitspolitik soll von allen MitarbeiterInnen getragen werden. Es ist daher wichtig, dass bei ihrer Erstellung alle wesentlichen Kräfte der Organisation beteiligt werden und das Dokument mit VertreterInnen aller Beteiligten bzw. Betroffenen abgestimmt wird.
Zunächst ist eine verantwortliche Person für die Erstellung der Informationssicherheitspolitik zu nominieren. I. Allg. wird dies, soweit bereits definiert, die/der IT-Sicherheitsbeauftragte sein.
Weiters sollen VertreterInnen folgender Bereiche an der Erstellung der organisationsweiten Informationssicherheitspolitik mitarbeiten bzw. in den Abstimmungsprozess miteinbezogen werden:
  • IT-Abteilung
  • AnwenderInnen
  • Bereichs-IT-Sicherheitsbeauftragte
  • Personalabteilung
  • Gebäudeverwaltung und Infrastruktur
  • Revision
  • Budgetabteilung
Die wesentlichen Inhalte der Informationssicherheitspolitik müssen allen Betroffenen und Beteiligten, also allen MitarbeiterInnen der Organisation, aber auch etwa externen MitarbeiterInnen und Lieferanten, bekannt sein.
Dazu sollten in der Folge die für die einzelnen Personengruppen wichtigsten Richtlinien und Vorgaben der Informationssicherheitspolitik zusammengefasst und allen 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, …).

5.3.2 Offizielle Inkraftsetzung der Informationssicherheitspolitik

ISO Bezug: 27002 5.1.1
Die Informationssicherheitspolitik wird von der Leitung der Organisation offiziell verabschiedet, in Kraft gesetzt und allen MitarbeiterInnen zur Verfügung gestellt.
Wesentliche Voraussetzung für eine erfolgreiche Implementierung und Umsetzung der Informationssicherheitspolitik ist, dass sie die volle und für alle Beteiligten sichtbare Unterstützung durch das Management erhält.

5.3.3 Regelmäßige Überarbeitung

ISO Bezug: 27002 5.1.2
Zwar stellt die Informationssicherheitspolitik ein langfristiges Dokument dar, dennoch ist auch sie regelmäßig auf ihre Aktualität und Übereinstimmung mit den tatsächlichen Anforderungen zu überprüfen und bei Bedarf entsprechend anzupassen.
Als Richtwert hierfür kann ein Zeitraum von zwei bis drei Jahren angesehen werden, nach dem die Informationssicherheitspolitik spätestens überprüft und aktualisiert werden sollte. Kommt es jedoch zwischenzeitlich zu gravierenden Änderungen im IT-System, in der Organisationsstruktur oder in den Bedrohungen, so ist eine sofortige Überarbeitung der Informationssicherheitspolitik in die Wege zu leiten.
Die Verantwortung dafür ist dezidiert festzulegen. I. Allg. wird sie bei der für die IT-Sicherheit beauftragten Person liegen.

6 Organisation

Dieses Kapitel nimmt Bezug auf ISO/IEC 27002 6 „Organisation der Informationssicherheit“.

6.1 Interne Organisation

ISO Bezug: 27002 6.1
In der Folge werden zunächst die Grundsätze und Maßnahmen des Informationssicherheitsmanagements innerhalb der Organisation dargestellt. Voraussetzung dafür ist eine aktive Rolle der Managementebene bei der Implementierung, Kontrolle und Weiterentwicklung der Informationssicherheitsmaßnahmen sowie der Etablierung und Pflege von Kontakten zu Behörden, Sicherheitsexperten und Interessensgruppen.
  • Die Managementebene wird über mögliche Risiken und Konsequenzen aufgrund mangelhafter Informationssicherheit informiert.
  • Sie übernimmt die Gesamtverantwortung für Informationssicherheit.
  • Sie initiiert und steuert den Informationssicherheitsprozess innerhalb der Organisation.

6.1.1 Managementverantwortung

ISO Bezug: 27002 6.1.1
Die oberste Managementebene jeder Behörde und jedes Unternehmens ist dafür verantwortlich, dass alle Geschäftsbereiche zielgerichtet und ordnungsgemäß funktionieren und dass Risiken frühzeitig erkannt und minimiert werden. Dies kann auch, je nach Organisationsform und Geschäftsbereich, in verschiedenen Regelwerken festgelegt sein. Mit der steigenden Abhängigkeit der Geschäftsprozesse von der Informationstechnik steigen auch die Anforderungen, dass die Informationssicherheit nach innen und außen gewährleistet ist.
Ob Informationssicherheit erreicht und erhalten wird, hängt also weitgehend vom Engagement und der Unterstützung des Managements ab. Abgesehen von der Bereitstellung dafür notwendiger finanzieller und personeller Ressourcen müssen klare Ziele und Richtlinien vorgegeben und die jeweiligen Rollen und Verantwortlichkeiten festgesetzt werden. Letztlich kommt es aber auch darauf an, dass die Managementebene die Sicherheitsmaßnahmen auch selbst vorbildlich lebt.
Dazu hat die Managementebene die Aufgabe, Folgendes zu veranlassen:
  • Ermitteln der Sicherheitsrisiken für die Organisation und die Informationen sowie damit verbundene Auswirkungen und Kosten.
  • Darstellung der Auswirkungen von Sicherheitsvorfällen auf die kritischen Geschäftsprozesse.
  • Darstellung der Sicherheitsanforderungen, die sich aus gesetzlichen und vertraglichen Vorgaben ergeben.
  • Identifikation von Informationssicherheits-Zielen.
  • Erarbeitung, Überprüfung und Genehmigung der Informationssicherheitspolitik.
  • Integration der Maßnahmen in die Prozesse der Organisation.
  • Etablierung von Mechanismen, um die Wirksamkeit der Maßnahmen der Informationssicherheitspolitik zu überprüfen.
  • Etablierung von Mechanismen, um das Informationssicherheits-Niveau aufrecht zu erhalten.
Die Managementebene muss allerdings die Informationssicherheitsziele so definieren, dass sie in allen Bereichen mit den verfügbaren Ressourcen (Personal, Zeit, Finanzmittel) erreichbar sind.
Hilfestellungen kann die Managementebene dabei von branchentypischen Standard-Vorgehensweisen zur Informationssicherheit und externen BeraterInnen erhalten. Letztere bieten zusätzlich zum Fachlichen bei der notwendigen Sensibilisierung auch den Nutzen, dass bisweilen den Aussagen unbeteiligter Dritter mehr Gewicht bemessen wird als denen eigener KollegInnen.
[Quelle: BSI-Standard 100-2]

6.1.1.1 Zusammenwirken verantwortliches Management - MitarbeiterInnen - Gremien

ISO Bezug: 27002 6.1.1
Die Managementebene muss den Sicherheitsprozess initiieren, steuern und kontrollieren. Die Verantwortung für Informationssicherheit verbleibt auch dort, die Aufgabe „Informationssicherheit“ wird allerdings typischerweise an eine/n IT-Sicherheitsbeauftragte/n delegiert. Dabei ist eine intensive Beteiligung der Führungsebene im „Managementprozess Informationssicherheit“ erforderlich.
Nur so kann das Informationssicherheitsmanagement sicherstellen, dass keine untragbaren Risiken bestehen und Ressourcen an der richtigen Stelle investiert werden. Die oberste Managementebene ist somit diejenige Instanz, die die Entscheidung über den Umgang mit Risiken trifft und die entsprechenden Ressourcen zur Verfügung stellen muss.
Die Managementebene trägt die Verantwortung für Prävention und Behandlung von Sicherheitsrisiken. Dementsprechend sind die Zuständigkeiten und Verantwortlichkeiten bezüglich Informationssicherheitsthemen zu klären. Allerdings wird rechtzeitige Information über mögliche Risiken beim Umgang mit Informationen, Geschäftsprozessen und IT von der Managementebene häufig als Bringschuld der IT- oder Sicherheitsexperten gesehen, speziell wenn es bereits zu einem Sicherheitsvorfall gekommen ist. Daher sollten diese die Managementebene über mögliche Risiken und Konsequenzen aufgrund mangelhafter Informationssicherheit regelmäßig informieren. Dies enthebt die Managementebene jedoch nicht von ihrer Verantwortung, dass sie von solchen Informationen umfassend und rechtzeitig erreicht wird.
Abhängig von Größe und Struktur der Organisation kann dies durch bestehende oder speziell eingerichtete Managementorgane oder -gremien umgesetzt werden.
Die Leitungsebene trägt zwar die Verantwortung für die Erreichung der Sicherheitsziele, der Sicherheitsprozess muss aber von allen Beschäftigten in einer Organisation mitgetragen und mitgestaltet werden. Idealerweise sollten dabei folgende Prinzipien eingehalten werden:
  • Die Initiative für Informationssicherheit geht von der Managementebene aus.
  • Die Gesamtverantwortung für Informationssicherheit verbleibt bei der obersten Managementebene.
  • Die Aufgabe „Informationssicherheit“ wird durch die Managementebene aktiv unterstützt.
  • Die Managementebene benennt die für Informationssicherheit zuständigen MitarbeiterInnen und stattet diese mit den erforderlichen Kompetenzen und Ressourcen aus.
  • Die Managementebene übernimmt auch im Bereich Informationssicherheit eine Vorbildfunktion, vor allem indem sie selbst die vorgegebenen Sicherheitsregeln beachtet.
Die Managementebene muss sich dafür einsetzen, dass Informationssicherheit in alle relevanten Geschäftsprozesse bzw. Fachverfahren und Projekte integriert wird. Der/Die IT-Sicherheitsbeauftragte braucht hierbei erfahrungsgemäß die volle Unterstützung der Managementebene, um unter dem überall herrschenden Erfolgsdruck von den jeweiligen Fachverantwortlichen in jede wesentliche Aktivität eingebunden zu werden.
[Quelle: BSI-Standard 100-2]

6.1.2 Koordination

ISO Bezug: 27002 6.1.2
Um das angestrebte Sicherheitsniveau zu erreichen, muss der Informationssicherheitsprozess organisationsweit umgesetzt werden. Dazu sind Rollen innerhalb der Organisation festzulegen und diesen entsprechende Aufgaben zuzuordnen. Diese Rollen werden dann qualifizierten MitarbeiterInnen zur Ausführung übertragen. Damit können alle wichtigen Aspekte berücksichtigt und die Aufgaben effizient und effektiv erledigt werden.
Meistens umfasst die Koordination der Informationssicherheit die Zusammenarbeit von ManagerInnen, AdministratorInnen, BenutzerInnen, EntwicklerInnen sowie AuditorInnen und Sicherheitspersonal. Wenn nötig sollten auch FachexpertInnen (Recht, Risikomanagement, Personalwesen) eingebunden werden. Aktivitäten im Rahmen einer solchen Zusammenarbeit sind:
  • Abgleichen der Sicherheitsaktivitäten mit der Informationssicherheitspolitik.
  • Maßnahmen, wenn kein Einklang mit der Informationssicherheitspolitik herstellbar ist.
  • Abstimmung und Beschlusslagen für die erforderlichen Maßnahmen.
  • Identifikation von bestehenden oder sich verändernden Bedrohungen, denen die Informationen und informationsverarbeitenden Einrichtungen ausgesetzt sind.
  • Bewertung der Eignung und Wirksamkeit der Sicherheitsmaßnahmen.
  • Schaffung und Förderung von Awareness und Etablierung von Ausbildungs- und Schulungsmaßnahmen für Informationssicherheit.
  • Schlussfolgerungen und Verbesserungsmaßnahmen aus Informationssicherheits-Vorfällen (in der eigenen oder auch anderen Organisationen)
Wie viele und welche Personen mit Informationssicherheit befasst sind, hängt selbstverständlich von der Größe, Beschaffenheit und Struktur der jeweiligen Organsiation ab. Zumindest sollte es jedoch eine/einen Sicherheitsbeauftragten als zentralen AnsprechpartnerIn für die Koordination des Informationssicherheitsprozesses geben.
Gibt es - etwa in größeren Organisationen - mehrere befasste Personen, kann ein IS-Management-Team aufgebaut werden. Es regelt die übergreifenden Belange der Informationssicherheit und arbeitet Pläne, Vorgaben und Richtlinien aus. Um den direkten Zugang zur obersten Managementebene sicherzustellen, sollten diese Rollen als Stabsstelle organisiert sein. Der/Die Sicherheitsbeauftragte soll direkt einem/einer für Informationssicherheit verantwortlichen ManagerIn berichten.
Unbeschadet davon sind alle MitarbeiterInnen für die Aufrechterhaltung der Informationssicherheit an ihrem Arbeitsplatz und in ihrer Umgebung verantwortlich.
[Quelle: BSI-Standard 100-2]

6.1.3 Definierte Verantwortlichkeiten für Informationssicherheit

ISO Bezug: 27002 6.1.3
Um zu einer umfassenden Gesamtsicherheit zu gelangen, ist die Beteiligung aller MitarbeiterInnen einer Organisation an der Umsetzung der notwendigen Sicherheitsmaßnahmen erforderlich. Es muss festgelegt werden, wer für Informationen, Anwendungen und IT-Komponenten sowie für deren Sicherheit verantwortlich ist. Hierfür sollte immer eine konkrete Person (inklusive VertreterIn) und keine abstrakte Gruppe benannt werden, damit die Zuständigkeit jederzeit deutlich erkennbar ist. Bei komplexeren Informationen, Anwendungen und IT-Komponenten sollten alle Verantwortlichen und deren VertreterInnen namentlich genannt sein.
Umgekehrt sollten natürlich alle MitarbeiterInnen wissen, für welche Informationen, Anwendungen und IT-Komponenten sie in welcher Weise verantwortlich sind.
Alle MitarbeiterInnen sind dabei für das verantwortlich, was in ihrem Einflussbereich liegt, es sei denn, es ist explizit anders geregelt. Beispielsweise ist die Leitungsebene der Organisation verantwortlich für alle grundsätzlichen Entscheidungen bei der Einführung einer neuen Anwendung, der/die LeiterIn der IT zusammen mit dem Informationssicherheitsmanagement für die Ausarbeitung von Sicherheitsvorgaben für die IT-Komponenten, die AdministratorInnen für deren korrekte Umsetzung und die BenutzerInnen für den sorgfältigen Umgang mit den zugehörigen Informationen, Anwendungen und Systemen.
Die Fachverantwortlichen als die „Eigentümer“ von Informationen und Anwendungen müssen sicherstellen, dass
  • der Schutzbedarf der Informationen, Anwendungen und IT-Komponenten korrekt festgestellt wurde,
  • die erforderlichen Sicherheitsmaßnahmen umgesetzt werden,
  • dies regelmäßig (z. B. täglich, wöchentlich, monatlich) überprüft wird,
  • die Aufgaben für die Umsetzung der Sicherheitsmaßnahmen klar definiert und zugewiesen werden,
  • der Zugang bzw. Zugriff zu den Informationen, Anwendungen und IT-Komponenten geregelt ist,
  • Abweichungen, welche die Informationssicherheit gefährden, schriftlich dokumentiert werden.
Die Fachverantwortlichen müssen zusammen mit dem Informationssicherheitsmanagement entscheiden, wie mit eventuellen Restrisiken umgegangen wird.
[Quelle: BSI M 2.225]

6.1.4 Benutzungsgenehmigung für Informationsverarbeitung

ISO Bezug: 27002 6.1.4
Beschaffung, Installation und Betrieb von informationsverarbeitenden Komponenten aller Art muss koordiniert und genehmigt sein. Dies betrifft die geregelte Abnahme, Freigabe, Installation und Benutzung von Komponenten wie auch etwa externen Laufwerken, USB-Sticks, PDAs, Mobiltelefonen und Software.
Die Regelung muss den gesamten Lebenszyklus der jeweiligen Komponente umfassen, also je nach Eigenschaften und Sicherheitsrelevanz:
  • Erstellung eines Anforderungskataloges
  • Auswahl eines geeigneten Produktes
  • Funktions- und Kompatibilitätstest
  • Freigabe
  • Installation
  • Lizenzverwaltung
  • Deinstallation
  • Entsorgung/Vernichtung
Notwendigkeit zur Koordination und Genehmigung betrifft auch Wartungsaktivitäten an bestehenden sicherheitsrelevanten Einrichtungen, wenn sich Änderungen auf die Sicherheit des Gesamtsystems auswirken könnten.
Ebenfalls muss die allfällige Verwendung von persönlichen oder privaten Informationsverarbeitungs-Einrichtungen geregelt werden, wenn sie auch Geschäftsinformationen verarbeiten sollen (weit verbreitet sind Kalender und Telefonlisten auf PDAs bzw. Mobiltelefonen): Diese können erhebliche Schwachstellen bedeuten, weiters ist bei diesen dann oft unklar, wer der Eigentümer der Information ist. Da sie praktisch sind und in vielen Fällen von der Managementebene benutzt werden, sind generelle Verbote ihres Einsatzes zunehmend schwieriger umzusetzten. Statt dessen müssen exakte Policies ihrer Verwendung und notwendiger Maßnahmen (etwa Verschlüsselung) definiert und umgesetzt werden. Siehe dazu auch 11.7.1 Mobile IT-Geräte.
Jedenfalls muss vor der Genehmigung von Komponenten
  • ihre Funktionstüchtigkeit,
  • ihre Sicherheitseigenschaften,
  • mögliche durch ihren Einsatz entstehende Sicherheitsrisiken,
  • allfällige Einsatzbedingungen und zu erarbeitende Installationsanweisungen
bekannt sein.
Während des Genehmigungsverfahrens sollten außerdem Installations- bzw. Konfigurationsanleitungen erarbeitet werden, in denen auch alle sicherheitsrelevanten Einstellungen dokumentiert sind. Auch nach der Erstinstallation von Komponenten müssen diese weitergepflegt werden. Vor der Inbetriebnahme neuer Komponenten sind (sofern erforderlich) die AdministratorInnen bzw. die BenutzerInnen in deren Anwendung zu schulen.
Die Installation und Benutzung nicht freigegebener IT-Komponenten muss verboten und die Einhaltung dieses Verbotes regelmäßig kontrolliert werden.
Siehe dazu auch
[Quelle: BSI M 2.216]

6.1.5 Vertraulichkeitsvereinbarungen

ISO Bezug: 27002 6.1.5
Externe MitarbeiterInnen oder Subunternehmen benötigen und erhalten häufig für die Erfüllung ihrer Aufgaben Zugang zu vertraulichen Informationen oder erzielen Ergebnisse, die vertraulich behandelt werden müssen. In diesen Fällen müssen sie rechtlich bindend verpflichtet werden, diese entsprechend zu behandeln. Hierüber sind Vertraulichkeitsvereinbarungen (Non-Disclosure-Agreements) abzuschließen, die von den externen MitarbeiterInnen unterzeichnet werden.
Eine Vertraulichkeitsvereinbarung bietet die rechtliche Grundlage für die Verpflichtung externer MitarbeiterInnen zur vertraulichen Behandlung von Informationen. Aus diesem Grund muss sie den geltenden Gesetzen und Bestimmungen für die Organisation in dem speziellen Einsatzbereich entsprechen und diese berücksichtigen. Sie muss klar formuliert sein und aktuell gehalten werden.
In einer Vertraulichkeitsvereinbarung sollte beschrieben sein:
  • welche Informationen vertraulich behandelt werden müssen,
  • für welchen Zeitraum diese Vertraulichkeitsvereinbarung gilt bzw. ob die Vertraulichkeit für unbeschränkten Zeitraum sicherzustellen ist,
  • welche Aktionen bei Beendigung dieser Vereinbarung vorgenommen werden müssen, z. B. Vernichtung oder Rückgabe von Datenträgern,
  • wie die Eigentumsrechte an Informationen resp. geistigem Eigentum geregelt sind,
  • welche Verwendung der Informationen zulässig ist,
  • allfällige Kontrollrechte des Urhebers bzw. der überlassenden Organisation,
  • allfällige Regelungen für den Gebrauch und die Weitergabe von vertraulichen Informationen an weitere Partner, etwa Pflicht zur Überbindung der Vertraulichkeitsvereinbarung,
  • welche Konsequenzen bei Verletzung der Vereinbarung eintreten, etwa Strafzahlungen bzw. Haftungen,
  • in welche Gerichtsbarkeit die Vertraulichkeitsvereinbarung fällt.
In der Vertraulichkeitsvereinbarung kann auch auf die relevanten Sicherheitsrichtlinien und weitere Richtlinien der Organisation hingewiesen werden. In dem Fall, dass externe MitarbeiterInnen Zugang zur organisationsinternen IT-Infrastruktur haben, sollten diese neben der Vertraulichkeitsvereinbarung auch die IT-Sicherheitsrichtlinien für die Nutzung der jeweiligen IT-Systeme unterzeichnen.
Es kann sinnvoll sein, verschiedene Vertraulichkeitsvereinbarungen - je nach Einsatzzweck - zu verwenden. In diesem Fall muss klar definiert werden, welche Vereinbarung für welche Fälle notwendig ist.
[Quelle: BSI M 3.55]

6.1.6 Kontaktpflege mit Behörden und Gremien

ISO Bezug: 27002 6.1.6, 6.1.7
Rasche Kontaktaufnahme mit zuständigen Behörden oder Versorgungseinrichtungen (Feuerwehr, Polizei, Aufsicht, aber auch Wasser-, Elektrizitäts- und Gasversorgungsunternehmen sowie Internet- oder Telekombetreiber) ist insbesondere bei Notfällen, Sicherheitsvorfällen oder Verdacht auf kriminelle Handlungen von entscheidender Bedeutung.
Daher sollen zum einen rechtzeitig Pläne, Verfahren und Kontaktlisten erstellt werden, damit rasch und zuverlässig die richtigen AnsprechpartnerInnen kontaktiert und ggf. eingewiesen werden können. Dies ist eine Aufgabe des Incident Handlings (siehe dazu 13.1.4 Prioritäten bei der Behandlung von Sicherheitsvorfällen).
Zum anderen sollten regelmäßige, ggf. auch informelle Beziehungen zu solchen Institutionen gepflegt werden. Damit können beispielsweise Vorsorgemaßnahmen vorab abgestimmt oder relevante Neuerungen bekanntgegeben werden, resp. kann die Organisation auf neue Gegebenheiten (etwa Vorschriften) angepasst werden.
Sinnvoll ist auch die Teilnahme oder Mitgliedschaft in Interessens-, Arbeits- bzw. Expertengremien. Damit wird nicht nur der eigene Wissensstand betreffend Technologien, Produkten, Gefährdungen, Best Practices und anderer Bereiche erhöht, sondern ein gemeinsamer Wissensstand mehrerer Partner aufgebaut, der in der Regel viel umfassender ist. In solchen Gremien sind meist rasch und unkompliziert Sicherheitswarnungen und Informationen über bereits erprobte Behebungsmaßnahmen, resp. generell Zugang zu Expertenwissen, zu bekommen.
Weiters können über solche geeignete Gremien oder Foren neue oder zusätzliche AnsprechpartnerInnen für Problemlösungen bzw. Behandlung von Sicherheitsvorfällen gefunden, bzw. die Kontakte mit ihnen gepflegt werden. Dazu ist es sinnvoll, einen Überblick über passende Gremien und Interessensgruppen zu haben und zu entscheiden, in welchen aktiv mitgearbeitet oder lediglich Ergebnisse beobachtet werden.
Allerdings ist zu beachten, dass sensible Informationen auch gegenüber Gremien oder Kontaktpersonen geschützt bleiben müssen. Entweder dürfen sie also nicht verwendet werden, oder es müssen geeignete Vertraulichkeitsvereinbarungen abgeschlossen werden.

6.1.7 Unabhängige Audits der Sicherheitsmaßnahmen

ISO Bezug: 27002 6.1.8
Das angestrebte Sicherheitsniveau wird in der Regel nicht auf einmal bzw. mit einer einzelnen Maßnahme erreicht, und bleibt nicht ohne Weiteres dauerhaft bestehen. Organisation, Infrastruktur und Umfeld sind immer wieder Änderungen unterworfen.
Dies umfasst:
  • neue Geschäftsprozesse
  • neue Anwendungen
  • neue Hard-, Software
  • neue oder veränderte Infrastrukturen (Gebäude, Büros, Leitungen, Netzwerke)
  • veränderte Organisationen (Outsourcing)
  • neue MitarbeiterInnen in Schlüsselpositionen
oder:
  • neue oder veränderte Gefährdungen (Nachbarfirmen mit Gefährdungspotenzialen)
  • neue Angriffstechnologien
  • veränderte Vermögenswerte und damit neuer Schutzbedarf
  • Kenntnis von neuen Schwachstellen
  • bereits eingetretene Sicherheitsvor- oder Schadensfälle
aber auch:
  • Planungsänderungen, Terminverzug bei der Umsetzung von Sicherheitsmaßnahmen.

Prüfziel und Prüfzweck:

Dies erfordert die regelmäßige Überprüfung (Audit) aller Sicherheitsmaßnahmen. Sie sollte durch eine weitgehend unabhängige und kompetente Stelle (Revisionsabteilung oder spezialisierte externe Gutachter) erfolgen:
  • damit nicht nur die unternehmenseigene Sichtweise zum Tragen kommt,
  • die Ergebnisse nicht angezweifelt werden können und
  • die Gelegenheit zum Einbringen zusätzlicher Expertise genutzt werden kann.
Keinesfalls sollten Personen als Prüfer tätig sein, die am Sicherheitskonzept mitgewirkt haben.
Geprüft werden die Maßnahmen laut Sicherheitskonzept:
  • ob damit die angestrebten Sicherheitsziele erreicht werden können,
  • ob sie zum Zeitpunkt der Prüfung noch umsetzbar, aktuell und vollständig sind,
  • ob bzw. inwieweit sie umgesetzt (vorhanden, wirksam, dokumentiert) sind und auch gelebt werden.

Durchführung der Prüfungen:

Die laufenden Umsetzungsaktivitäten selbst sind hinsichtlich Umsetzungsstatus, Termintreue, Ressourceneinsatz und Kosten zu prüfen.
Solche Prüfungen sollten:
  • vom Management initiiert und begleitet sein
  • regelmäßig durchgeführt werden (zumindest einmal pro Jahr)
  • aber auch zwischenzeitlich und unangekündigt erfolgen, insbesondere bei Änderungen in der Organisation.
Ziel der Prüfung ist nicht Überwachung der MitarbeiterInnen als Selbstzweck oder gar deren Bloßstellung, sondern:
  • Suche nach und Eliminierung von Fehlerquellen, Schwachstellen und Mängeln
  • Abgleich, ob
    • die Sicherheitsmaßnahmen gemäß Sicherheitskonzept umgesetzt sind oder werden
    • technische Maßnahmen korrekt implementiert bzw. konfiguriert sind
    • Auswertungen (etwa von Protokollen) tatsächlich durchgeführt werden und Auffälligkeiten beachtet werden
  • Erkennen von
    • schwachen oder nicht wirksamen Sicherheitsmaßnahmen
    • nicht eingehaltenen Sicherheitsanweisungen und den Ursachen dafür
    • neuen oder veränderten Bedrohungen
  • Anpassungsbedarf für das Sicherheitskonzept bzw. Sicherheitsmaßnahmen (Eignung, die Sicherheitsziele zu erreichen, ob nicht wirtschaftlichere Maßnahmen möglich sind)
  • Schlußfolgerungen aus Sicherheitsvorfällen
  • Verhindern, dass sich Sicherheitsvorfälle wiederholen
  • Aufzeigen von Verbesserungs- und Korrekturmaßnahmen

Wesentlich für den Erfolg der Prüfung im Sinne eines Verbesserungspotenzials ist die Akzeptanz und Offenheit seitens aller Beteiligter. Daher muss ihnen der Nutzen dargestellt und allfällige Ängste vor Schuldzuweisungen genommen werden. Ansonsten würden womöglich bekannte Schwachstellen oder gar Vorfälle verschwiegen oder heruntergespielt.
Die Durchführung der Prüfung muss vom Management wie jedes andere Projekt koordiniert und begleitet werden. Immerhin bedeutet sie eine Zusatzbelastung für die MitarbeiterInnen, die zeitlich bzw. bisweilen auch räumlich ausreichend unterzubringen ist. Es sollte einerseits auf Effizienz geachtet werden (etwa Vermeiden unnötiger ad-hoc Listen und Aufstellungen, wenn sich die Information auch aus Quellen der normalen Tätigkeit gewinnen lässt), andererseits darf kein Bereich ungeprüft bleiben. Auch hier ist darauf zu achten, dass sensible Informationen geschützt bleiben müssen bzw. entsprechende Vertraulichkeitsvereinbarungen abgeschlossen werden. Dies gilt insbesondere auch für eingesetzte Prüfwerkzeuge. Solche dürfen nur von autorisierten Personen verwendet werden und sind selbst vor Missbrauch zu schützen.
Basis für die Prüfung sind primär Sicherheitspolitik, Sicherheitskonzept und dokumentierte Sicherheitsmaßnahmen. Selbstverständlich muss dafür gesorgt sein, dass das Management regelmäßig über Verlauf, Fortschritt, vorläufige Erkenntnisse und allfällige Probleme der Prüfung informiert wird.

Maßnahmen aufgrund der Prüfergebnisse:

Es ist vorab zu definieren, was aufgrund der Ergebnisse der Prüfung geschehen soll. Jedenfalls ist dem Management ein Prüfbericht vorzulegen:
  • Was wurde jeweils im Einzelnen geprüft und von wem
  • Was war die Prüfgrundlage (z. B. Sicherheitskonzept, Norm)
  • Was war im Einzelnen das zu erreichende Prüfziel
  • Inwieweit wurde es erreicht oder welche Abweichungen / Unregelmäßigkeiten wurden festgestellt
  • War jeweils die Implementierung/Konfigurierung/Dokumentation korrekt
  • Wie sind allfällig erkannte Schwachstellen/Unregelmäßigkeiten/neue Gefahren zu quantifizieren und welcher Handlungsbedarf ergibt sich daraus
Es ist dann die Pflicht des Managements, auf Basis der Ergebnisse entsprechende Verbesserungsmaßnahmen einzuleiten. Optimalerweise - bei regelmäßigen Prüfungen - existiert in der Organisation ein periodischer Verbesserungsprozess, im Rahmen dessen die Korrekturmaßnahmen dokumentiert, umgesetzt und ihrerseits wieder überprüft werden.
Verbesserungsmaßnahmen abhängig von der Ursache können sein:
  • ISMS: Anpassung der Sicherheitspolitik oder des Sicherheitskonzepts
  • Organisation: Abänderung organisatorischer Maßnahmen, zusätzliche Kontrollmechanismen, veränderte Zugriffsberechtigungen
  • Personal: Awareness-, Schulungs- oder gar disziplinäre Maßnahmen
  • Infrastruktur: Bauliche Veränderungen, veränderte Leitungsführungen
  • Technik: Hard-, Softwareänderungen, Netzwerk-, Kommunikationsinfrastrukturanpassung
Zu jeder festgestellten Abweichung soll eine Verbesserungsmaßnahme vorgeschlagen werden - inklusive Zeitpunkt, Verantwortung und Ressourcen für ihre Umsetzung. Werden unzulässige Aktivitäten von MitarbeiterInnen entdeckt, sollte die/der jeweilige Vorgesetzte informiert werden, um angemessene Konsequenzen einzuleiten.
Schließlich entscheidet die Managementebene auf Basis der Prüfergebnisse, welche Konsequenzen zu ziehen bzw. Verbesserungsmaßnahmen einzuleiten sind. Dazu wird ein Umsetzungsplan verabschiedet, wobei festgehalten wird:
  • Zeitaufwand und Fertigstellungstermine
  • Verantwortlichkeiten für die Umsetzung
  • Zur Verfügung gestellte Ressourcen
Die Umsetzung der Verbesserungsmaßnahmen ist dann Gegenstand des nächsten Audits.
[Quelle: BSI M 2.199]

6.1.8 Berichtswesen

ISO Bezug: 27002 6.1.8
Die Managementebene benötigt für ihre Entscheidungen aussagekräftige und aufbereitete Informationen. Dies gilt auch für die aktuelle Situation der Informationssicherheit. Um deren Niveau zu halten, ist dieses laufend zu bewerten und der Informationssicherheitsprozess zu steuern. Jede Änderung an den Sicherheitszielen, den Implementíerungen und im Umfeld wirkt sich auf das Sicherheitsniveau aus, daher muss die Managementebene darüber informiert werden.

Regelmäßige Managementberichte

Für die Managementebene sind nicht so sehr die Details, sondern die Eckdaten relevant:
  • Ergebnisse von Audits und Überprüfungen
  • Berichte von Not- oder Sicherheitsvorfällen
  • Berichte über den Status des Informationssicherheitsprozesses (Erledigungen, Verzögerungen, Änderungen, Probleme, Ressourcenbedarf, künftige Planungen)
  • Verbesserungsvorschläge
Dies sollte in regelmäßigen aber kurzen und übersichtlichen Berichten an die Managementebene erfolgen. Auf Aspekte, die bereits in anderen Berichten erörtert wurden, sollte ggf. verwiesen, diese aber nicht wiederholt werden. Die Sprache sollte auch für technisch nicht versierte Leser verständlich sein.

Ad-Hoc-Managementberichte

Im Anlassfall sollten Ad-hoc-Berichte erarbeitet werden, etwa:
  • unerwartete Sicherheitsprobleme,
  • neue Gefährdungspotenziale,
  • neue Gesetze,
  • Probleme die mit den vorgesehenen Ressourcen nicht gelöst werden können,
  • in Massenmedien dargestellte Vorfälle - ob und inwieweit die eigene Organisation betroffen ist.
Abgesehen von bloßen Kenntnisnahmen ist das Ziel solcher Berichte meist eine Entscheidung der Managementebene. Diese wird nur dann erreicht, wenn zu den aufgezeigten Punkten auch klar formulierte Vorschläge für Maßnahmen dargestellt werden - inklusive einer Schätzung des damit verbundenen Aufwands bzw. Ressourcenbedarfs und der jeweiligen Priorität.
[Quelle: BSI M 2.200]

6.2 Zusammenarbeit mit Externen

ISO Bezug: 27002 6.1

6.2.1 Outsourcing

ISO Bezug: 27002 6.2.1, 10.2
Outsourcing bedeutet, dass Arbeits- oder Geschäftsprozesse einer Organisation ganz oder teilweise zu externen Dienstleistern ausgelagert und von diesen durchgeführt werden. Ob dies in den Räumlichkeiten des Auftraggebers oder in einer externen Betriebsstätte des Outsourcing-Dienstleisters geschieht, ist nicht erheblich.
Beispiele:
  • Nutzung und Betrieb von Hardware und Software
  • Betrieb eines Rechenzentrums, einer Applikation, einer Website
  • Wachdienst
Ausgelagerte Dienstleistungen mit Bezug zur IT-Sicherheit heißen „Security Outsourcing“ oder „Managed Security Services“:
  • ausgelagerter Firewall-Betrieb
  • Netzwerküberwachung
  • Virenschutz
  • Betrieb eines Virtual Private Networks (VPN)
Dienstleister, die auf ihren eigenen Systemen Anwendungen für ihre Kunden betreiben, heißen „Application Service Provider“ (ASP):
  • E-Mail
  • SAP-Anwendungen
  • Archivierung
  • Web-Shops
Sind die Anwendungen Eigentum des Kunden, spricht man von „Application Hosting“.
Meist sind Auftraggeber und Dienstleister über das Internet oder ein VPN miteinander verbunden.
Die Erwartung an Outsourcing von Geschäftsprozessen oder Produktionen sind unter Anderem:
  • Konzentration auf Kernkompetenz (Core Business)
  • Kostenersparnis (etwa IT-Systeme samt Personal)
  • Entlastung eigener Ressourcen
  • Flexibilität der Prozesse
Obwohl auch einige Outsourcing-Projekte gescheitert sind, besteht nach wie vor ein Trend zu verstärkter Auslagerung.
Eine Herausforderung für die Informationssicherheit liegt darin, dass die Informationssysteme und Netzwerke der eigenen Organisation und ihrer Dienstleister miteinander verbunden werden. Der Ablauf eigener Geschäftsprozesse wird nun vom Dienstleister gesteuert und es entsteht eine Abhängigkeit von dessen Qualität. Damit ergeben sich eine Reihe von potenziell höchst gefährlichen bzw. existenzgefährdenden Risiken für die auftraggebende Organisation.
Wesentlich sind daher beim Outsourcing die Kenntnis und Behandlung der Gefährdungen bzw. Sicherheitmaßnahmen sowie die Gestaltung vertraglicher Regelungen zwischen Auftraggeber und Dienstleister.
[Quelle: BSI B 1.11]

6.2.2 Gefährdungen beim Outsourcing

ISO Bezug: 27002 6.2.1
Die Gefährdungslage eines Outsourcing-Vorhabens ist ausgesprochen vielschichtig. Die Entscheidung über das Auslagern einer speziellen Aktivität beeinflusst nachhaltig die strategische Ausrichtung der Organisation, die Definition ihrer Kernkompetenzen, die Ausgestaltung der Wertschöpfungskette und betrifft viele weitere wesentliche Belange eines Organisationsmanagements. Es sollten daher alle Anstrengungen unternommen werden, um Fehlentwicklungen der eigenen Organisation frühzeitig zu erkennen und zu verhindern.
Die Gefährdungen können parallel auf physikalischer, technischer und auch menschlicher Ebene existieren und sind nachfolgend in den einzelnen Gefährdungskatalogen aufgeführt. Um die jeweils existierenden Risiken quantitativ bewerten zu können, müssen zuvor die organisationseigenen Werte und Informationen entsprechend ihrer strategischen Bedeutung für die Organisation beurteilt und klassifiziert werden.
  • Höhere Gewalt
  • Ausfall eines Wide Area Netzwerkes
  • Organisatorische Mängel
  • Fehlende oder unzureichende Regelungen
  • Unerlaubte Ausübung von Rechten
  • Fehlendes oder unzureichendes Test- und Freigabeverfahren
  • Ungesicherter Akten- und Datenträgertransport
  • Unzureichendes Sicherheitsmanagement
  • Ungeeignete Verwaltung von Zugangs- und Zugriffsrechten
  • Fehlerhafte Outsourcing-Strategie
  • Unzulängliche vertragliche Regelungen mit einem externen Dienstleister
  • Unzureichende Regelungen für das Ende des Outsourcing-Vorhabens
  • Abhängigkeit von einem Outsourcing-Dienstleister
  • Störung des Betriebsklimas durch ein Outsourcing-Vorhaben
  • Mangelhafte IT-Sicherheit in der Outsourcing-Einführungsphase
  • Schwachstellen bei der Anbindung an einen Outsourcing-Dienstleister
  • Unzureichendes Notfallvorsorgekonzept beim Outsourcing
  • Menschliche Fehlhandlungen
  • Vertraulichkeits- oder Integritätsverlust von Daten durch Fehlverhalten
  • Technisches Versagen
  • Schlechte oder fehlende Authentifikation
  • Ausfall eines Kryptomoduls
  • Ausfall der Systeme eines Outsourcing-Dienstleisters
  • Vorsätzliche Handlungen
  • Missbrauch von Fernwartungszugängen
  • Missbrauch von Administratorrechten
  • Social Engineering
  • Vertraulichkeitsverlust schützenswerter Informationen
  • Integritätsverlust schützenswerter Informationen
  • Weitergabe von Daten an Dritte durch den Outsourcing-Dienstleister
[Quelle: BSI B 1.11]

6.2.3 Outsourcing-Planungs- und -Betriebsphasen

ISO Bezug: 27002 6.2.1
Ein ausgelagerter IT-Verbund kann sowohl aus Komponenten bestehen, die sich ausschließlich im Einflussbereich des Outsourcing-Dienstleisters befinden, als auch aus Komponenten beim Auftraggeber. In der Regel gibt es in diesem Fall Schnittstellen zur Verbindung der Systeme. Für jedes Teilsystem und für die Schnittstellenfunktionen muss das definierte Sicherheitsniveau gewährleistet sein.

Phase 1: Strategische Planung des Outsourcing-Vorhabens

Schon bei der Entscheidung, ob und in welcher Form ein Outsourcing-Vorhaben umgesetzt wird, müssen die sicherheitsrelevanten Gesichtspunkte herausgearbeitet werden.
Outsourcing zieht wirtschaftliche, technische, organisatorische und sicherheitsrelevante Aspekte nach sich und bedingt vorab:
  • Unternehmensstrategie
  • Machbarkeitsstudie mit den Rahmenbedingungen
  • Kosten-Nutzen-Schätzung
  • Welche Anwendungen sollen ausgelagert werden (Kerngeschäft, Routineabläufe)?
  • Wie können weiters Anforderungen an die IT gestellt werden?
  • Was geschieht mit bisher selbst entwickelten IT-Anwendungen?
Wesentlich ist zunächst die Klärung, ob Auslagerungen von Aufgaben rechtlich möglich bzw. aufgrund von Auflagen schwierig sein werden (etwa gesetztlich festgeschriebene Kompetenzen, Gewerbeberechtigungen, Konzessionen, Einschaltung von Aufsichtsbehörden). Es muss klar sein, dass die Verantwortung für Produkte oder Dienstleistungen bei der eigenen Organisation verbleibt, mitunter aber durch Auslagern mit höherem Risiko - sowie weiteren Risiken - verbunden sein kann:
  • Outsourcing kann in der Regel nicht einfach rückgängig gemacht werden, es entsteht eine langfristige Bindung an den Dienstleister.
  • Der Dienstleister hat Zugriff auf Informationen und IT-Ressourcen der eigenen Organisation. Sie verliert die alleinige und vollständige Kontrolle darüber.
  • Datenübertragung vom und zum Dienstleister erzeugt neue Gefährdungen.
  • Meist ist es notwendig, dass MitarbeiterInnen des Dienstleisters oder von Subunternehmen zeitweise in den Räumlichkeiten der eigenen Organisation arbeiten müssen.
  • Im Rahmen des Outsourcing werden neue Prozesse und Arbeitsabläufe entworfen, eingeführt und durchgeführt und bewirken Änderungen des Sicherheitskonzepts und der Implementierungen.
  • Ein häufiger Grund, IT-Dienstleistungen auszulagern, ist die Erwartung von Kostensenkungen - bei gleicher oder gar besserer Qualität. Es muss vorab abgeschätzt werden, wieso das dem Dienstleister gelingen wird, wenn er dabei auch noch einen Gewinn lukriert. Selbstverständlich gibt es viele Fälle, wo dies tatsächlich möglich ist, etwa durch gute Auslastung großer Installationen.
  • Ein gewisser Know-how Transfer zum Dienstleister lässt sich (auch mit „wasserdichten“ Vertraulichkeitsvereinbarungen) nicht verhindern, da bei dessen MitarbeiterInnen entsprechendes Wissen entsteht.
Die IT-Sicherheit sollte keinesfalls bei den strategischen Überlegungen vernachlässigt werden. Daher sollte eine Sicherheitsanalyse durchgeführt werden, um festzustellen, wie bestehende IT-Systeme oder IT-Verbünde abgegrenzt und getrennt werden können, damit Teile davon ausgelagert werden können:
  • IT-Strukturanalyse
  • Schutzbedarfsfeststellung
  • Feststellung des Handlungsbedarfs sowie der Kosten für umzusetzende Maßnahmen
Bei hohem Schutzbedarf wichtiger Systeme oder Anwendungen muss eine ergänzende Sicherheitsanalyse (z. B. Risikoanalyse) durchgeführt werden. Meist wird ein zusätzliches Restrisiko bei der eigenen Organisation verbleiben. Schließlich erfolgt die Dokumentation der Outsourcing-Strategie mit Zielen, Chancen und Risiken sowie den Erfahrungen.
[Quelle: BSI M 2.250]

Phase 2: Definition der wesentlichen Sicherheitsanforderungen

Wenn die Entscheidung zum Outsourcing gefallen ist, müssen die wesentlichen übergeordneten Sicherheitsanforderungen für das Outsourcing-Vorhaben festgelegt werden. Diese Sicherheitsanforderungen sind die Basis für das Ausschreibungsverfahren.
Mit dem ausgelagerten Betrieb ergeben sich neue Sicherheitsanforderungen sowohl an den auszuwählenden Dienstleister wie auch an die eigene Organisation. Diese werden zunächst beginnend mt den gewünschten Sicherheitsniveaus in den betroffenen Bereichen immer weiter verfeinert, um dann konkret genug zu sein, einen geeigneten Dienstleister auszuwählen. Auch nach erfolgter Auswahl wird eine weitere Verfeinerung der Sicherheitsanforderungen bis hin zu den Umsetzungsschritten notwendig sein.
Folgende Aspekte sind in der Regel zu berücksichtigen:
  • Welches Mindestniveau (IT-Grundschutz) ist von beiden Parteien zu erfüllen?
  • Sowohl Dienstleister wie eigene Organisation müssen über ein Sicherheitskonzept verfügen und dieses umgesetzt haben.
  • Es entstehen Schnittstellen zwischen den nun im Verbund wirkenden Aufgaben, Geschäftsprozessen, Anwendungen, Systemen. Diese müssen identifiziert und beschrieben werden.
  • An diese Schnittstellen müssen technische und organisatorische Sicherheitsanforderungen gestellt werden.
  • Strukturanalyse und Schutzbedarfsfeststellung (IT-Systeme, Anwendungen, Kommunikationsverbindungen, Räume) hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit müssen erfolgen.
  • Notwendige Einräumung von Zutritts- und Zugriffsrechten für den Dienstleister.
  • Aufzeigen der Auswirkungen relevanter Gesetze und Vorschriften. Dies kann erheblichen Aufwand verursachen, etwa bei länderübergreifendem Outsourcing oder wenn einer oder beide Partner weltweit tätig sind.
  • Beschreibung der Anforderungen an Infrastruktur, Organisation, Personal und Technik durch das zu erreichende Sicherheitsniveau (etwa auch Alarmierungen, Benennung von Sicherheitsbeauftragten beim Dienstleister).
  • Spezielle Anforderungen an Hard-/Software (etwa zertifizierte Produkte beim Dienstleister).
  • Anforderungen an die Verfügbarkeit von Diensten und IT-Systemen (Service Levels, Lastverteilung etwa bei Web-Servern).
  • Vorgaben an die Mandantenfähigkeit und ggf. Trennung von Hard- und Software (etwa keine Systeme anderer Mandanten im gleichen Raum des Dienstleisters, exklusiv genutzte Hardware in Käfigen).
  • Vorgaben zur Absicherung der Kommunikation zwischen Dienstleister und eigener Organisation (Verschlüsselungs- und Signaturverfahren).
  • Anforderungen zur Qualitätssicherung (etwa Messungen von Reaktionszeiten, Verfügbarkeit).
  • Spezifizieren von gewünschten Verfahren für die Kontrolle und Überwachung (etwa unangekündigte Kontrollen vor Ort, Audits - ggf. durch unabhängige Dritte).
  • Anforderungen an die Protokollierung und Auswertung von Protokolldateien.
[Quelle: BSI M 2.251]

Phase 3: Auswahl des Outsourcing-Dienstleisters

Ihr kommt eine besondere Bedeutung zu, etwa da langfristige Abhängigkeiten entstehen.
Kritische Erfolgsfaktoren dafür, dass sich geeignete Dienstleister bewerben, sind:
  • möglichst detailliertes Anforderungsprofil
  • darauf basierendes Pflichtenheft
Eine bedarfsgerechte Ausschreibung sollte enthalten:
  • Beschreibung des Outsourcing-Vorhabens (Aufgabenbeschreibung und Aufgabenteilung)
  • Beschreibung des geforderten Qualitätsniveaus (dieses kann ggf. anders sein als das der eigenen Organisation)
  • Anforderungen an die Informationssicherheit
  • Kriterien zur Messung von Servicequalität und Sicherheit
  • Anforderungen an die Qualifikation der MitarbeiterInnen. Sicherstellung, dass diese dann tatsächlich tätig sind und dass es geeignete VertreterInnen gibt
  • Bei ausländischen Dienstleistern: Festlegung der Sprache für die gemeinsame Kommunikation und Sicherstellung, dass diese von allen befassten MitarbeiterInnen (auch den eigenen) auch in Detailaspekten beherrscht wird
  • Notwendigkeit bzw. Vorliegen von Sicherheitsüberprüfungen der MitarbeiterInnen des Dienstleisters
Zu beachten ist, dass aus detallierten Sicherheitsanforderungen Schlüsse auf die eigenen Sicherheitsmechanismen und ihre Wirksamkeit gezogen werden können. Daher kann es notwendig sein, diese nur gegen Vertraulichkeitsvereinbarung an den sich bewerbenden Dienstleister zu übermitteln.
[Quelle: BSI M 2.252]

Phase 4: Vertragsgestaltung

Auf Basis des Pflichtenheftes muss nun ein Vertrag mit dem Partner ausgehandelt werden, der die gewünschten Leistungen inklusive Qualitätsstandards und Fristen im Einklang mit der vorhandenen Gesetzgebung festschreibt. Diese Verträge werden häufig als Service Level Agreements (SLAs) bezeichnet. In diesem Vertrag müssen auch die genauen Modalitäten der Zusammenarbeit geklärt sein: Ansprechpartner, Reaktionszeiten, IT-Anbindung, Kontrolle der Leistungen, Ausgestaltung der IT-Sicherheitsvorkehrungen, Umgang mit vertraulichen Informationen, Verwertungsrechte, Weitergabe von Information an Dritte etc.
Dabei ist es empfehlenswert, die vereinbarten Leistungen und Ziele so genau und eindeutig wie möglich vertraglich festzuhalten. Nachträgliche Konkretisierungen und Ergänzungen des Vertrages, die aufgrund unterschiedlicher Interpretationen der beschriebenen Leistungen notwendig werden, sind oftmals mit deutlichen Kostenerhöhungen für den Auftraggeber verbunden. Auch die Erstellung des IT-Sicherheitskonzeptes selbst sollte Vertragsbestandteil sein. Insbesondere ist zu klären, wer für die fachlichen Inhalte verantwortlich ist und welche Mitwirkungspflichten dem Auftraggeber obliegen. Ggf. kann und sollte sich der Auftraggeber ein Mitspracherecht einräumen lassen, welches Personal der Dienstleister einsetzen wird (Qualifikation, Sicherheitsüberprüfung, Sprachkenntnisse).
[Quelle: BSI M 2.253]

Phase 5: Erstellung eines IT-Sicherheitskonzepts für den ausgelagerten IT-Verbund

Auftraggeber und Outsourcing-Dienstleister müssen ein detailliertes Sicherheitskonzept, das auch ein Notfallvorsorgekonzept enthält, erstellen.
Bei Outsourcing-Projekten ergeben sich viele technische und organisatorische Details erst im Laufe der Planung und der Migration der Systeme. Daher wird das Sicherheitskonzept für das Outsourcing-Vorhaben in den wenigsten Fällen gleich vollständig und endgültig sein, sondern muss während der Migration stetig weiterentwickelt und konkretisiert werden.
Sicherheitskonzepte für Outsourcing-Vorhaben unterscheiden sich in einigen Punkten von solchen für eigene Systeme, da in der Regel 3 technische Parteien beteiligt sind:
  • 1. Outsourcing-Auftraggeber
  • 2. Outsourcing-Dienstleister
  • 3. Netzprovider (Anbindung zwischen den Outsourcing-Parteien - zuständig für die Netzanbindung ist in der Regel der Outsourcing-Dienstleister).
Jeder Beteiligte muss ein Sicherheitskonzept in seinem jeweiligen Einflussbereich erstellen und umsetzen (im Fall des Netzproviders sind die Schnittstellen relevant).
Darüber hinaus muss dann ein IT-Sicherheitskonzept für das Gesamtsystem erstellt und mit den Teilkonzepten abgestimmt werden, aus welchem die Sicherheit im Zusammenspiel der Einzelsysteme hervorgeht. Am Sicherheitskonzept des Outsourcing-Dienstleisters ist der Auftraggeber nicht direkt beteiligt, sollte aber in einem Audit - ggf. durch externe Dritte - prüfen, ob es vorhanden und ausreichend ist. Besondere Aufmerksamkeit ist dabei auch auf die Migrationsphase der Aufgaben und Systeme zum Dienstleister zu richten, da während dieser mit Sicherheitsvorfällen gerechten werden muss. Einige Themen und Aspekte für das Outsourcing-Sicherheitskonzept:
Organisation
  • Umgang mit Daten und schützenswerten Betriebsmitteln wie Druckerpapier und Speichermedien, insbesondere Regelungen zum Anfertigen von Kopien und Löschen/Vernichten
  • Festlegung von Aktionen, für die das „Vier-Augen-Prinzip“ anzuwenden ist
Hard-/Software
  • Einsatz gehärteter Betriebssysteme, um Angriffe möglichst zu erschweren
  • Einsatz von Intrusion-Detection-Systemen (IDS), um Angriffe frühzeitig zu erkennen
  • Einsatz von Datei-Integrität-Prüfungssystemen, um Veränderungen z. B. nach erfolgreichen Angriffen, zu erkennen
  • Einsatz von Syslog- und Timeservern, um eine möglichst umfassende Protokollierung zu ermöglichen
  • Einsatz kaskadierter Firewallsysteme zur Erhöhung des Perimeterschutzes auf Seiten des Dienstleisters
  • Sorgfältige Vergabe von Benutzerkennungen, Verbot von Gruppen-IDs für Personal des Dienstleisters
Kommunikation
  • Absicherung der Kommunikation (z. B. durch Verschlüsselung, elektronische Signatur) zwischen Dienstleister und Auftraggeber, um sensitive Daten zu schützen
  • Authentisierungsmechanismen
  • Detailregelungen für weitere Netzanbindungen
  • Detailregelungen für den Datenaustausch
Kontrollen und Qualitätssicherung
  • Detailregelungen (z. B. unangekündigte Kontrollen vor Ort, Zeitintervalle, Zuständigkeiten, Detailgrad) für Kontrollen und Messung von Sicherheit, Dienstqualität, Abläufen und organisatorische Regelungen

Notfallvorsorge

Beim Outsourcing-Betrieb ist auch die Notfallvorsorge auf unterschiedliche Parteien aufgeteilt und die IT-Komponenten sind verteilt.
Notfallvorsorgekonzepte müssen für die Systeme beim Auftraggeber, beim Outsourcing-Dienstleister sowie für die Schnittstellen zwischen Auftraggeber und Dienstleister (z. B. Netzverbindung, Router, Telekommunikationsprovider) existieren und detailliert beschreiben:
  • Regelung und Dokumentation von Zuständigkeiten, Ansprechpartnern und Abläufen
  • Erstellen von Detailregelungen für die Datensicherung (z. B. getrennte Backup-Medien für jeden Klienten, Verfügbarkeit, Vertretungsregelungen, Eskalationsstrategien, Virenschutz)
  • Erstellen von Arbeitsanweisungen mit konkreten Anordnungen für bestimmte Fehlersituationen
  • Konzeption von regelmäßig durchzuführenden Notfallübungen
Eine besodere Problematik kann sich dadurch ergeben, dass das Personal des Dienstleisters meist keine inhaltlichen Kenntnisse über die Anwendungen besitzt, die auf seinen Systemen betrieben werden, aber Fehler beheben soll oder muss. Daher sind genaue Anweisungen seitens des Auftraggebers erforderlich:
  • wie bei Fehlern vorzugehen ist
  • welche Aktionen erlaubt resp. verboten sind
  • auf welche anwendungsspezifischen Informationen zurückgegriffen werden kann
  • ob und welche Schutzmaßnahmen für solche Informationen einzuhalten sind
  • welche Anprechpartner beim Auftraggeber für anwendungsspezifische Probleme zur Verfügung stehen
Ein weiteres Problem kann sich durch Fortpflanzung eines Anwendungsfehlers auf andere Anwendungen ergeben. Die kann der Dienstleister meist nicht selbst abschätzen und muss daher rechtzeitig mit dem Auftraggeber Kontakt aufnehmen.
Phase 5 wird in der Regel erst nach Beendigung der Migrationsphase abgeschlossen werden können, weil sich während der Migration der IT-Systeme und Anwendungen immer wieder neue Erkenntnisse ergeben, die in das IT-Sicherheitskonzept eingearbeitet werden müssen.
[Quelle: BSI M 2.254, M 6.83]

Phase 6: Migration - Übergang der Anwendungen und Systeme zum Dienstleister

Besonders sicherheitskritisch ist die Migrations- oder Übergangsphase, die deshalb einer sorgfältigen Planung bedarf.
In einem zu erarbeitenden vorläufigen Sicherheitskonzept müssen die Test- und Einführungsphase als Teil des gesamten Vorhabens betrachtet werden:
  • in dieser Phase sind zahlreiche Betriebsfremde involviert,
  • es müssen Abläufe etabliert, Aufgaben übertragen und
  • Systeme neu eingerichtet bzw. angepasst werden
Bei Tests in Zeiten großer Arbeitsbelastung werden gerne „quick and dirty“ Lösungen gewählt, die selten sehr sicher sind (z. B. werden Kopien von Produktionsdaten ohne weiteren Schutz verwendet).
In der eigenen Organisation sollte ein Sicherheitsmanagement-Team speziell für die Umstellungsphase eingerichtet werden und schon vor der Umstellung für sicheren IT-Betrieb während der Migrationsphase sorgen. Seine Größe hängt vom Vorhaben ab, zumindest sollte es aus einem Sicherheitsexperten bestehen und hat die Aufgaben:
  • Zusammenstellung eines gemischten Teams aus MitarbeiterInnen des Auftraggebers und des Outsourcing-Dienstleisters, ggf. zusätzlich mit externen ExpertInnen.
  • Erarbeiten eines Sicherheitskonzeptes für die Umstellungsphase.
  • Festlegen der Verantwortlichkeiten für die Umstellungsphase - mit klaren Führungsstrukturen und eindeutigen AnsprechpartnerInnen auf beiden Seiten - auch auf oberer Managementebene.
  • Planung und Durchführung der erforderlichen Tests und Abnahmeprozeduren.
  • Planung der Produktionsumstellung.
  • Auswahl geeigneter interner MitarbeiterInnen für die Test-, die Einführungsphase und den späteren Betrieb (ggf. vertragliches Mitspracherecht des Auftraggebers).
  • Schulung der MitarbeiterInnen des Auftraggebers über Abläufe und Verhalten während und nach der Umstellung. Da sie dabei mit neuen und unbekannten AnsprechpartnerInnen konfrontiert sind, entsteht eine Gefahr des „Social Engineerings“ (z. B. Anruf von vermeintlichen MitarbeiterInnen des Sicherheitsteams des Dienstleisters).
  • Einweisung des Dienstleisters auf die relevanten Abläufe, Applikationen und IT-Systeme des Auftraggebers.
  • Ressourcenplanung und Tests, ohne die laufenden Systeme zu vernachlässigen. Sicherstellung, dass die vorgesehenen MitarbeiterInnen zur Verfügung stehen (ggf. Urlaubssperren). Störungen durch Tests und dabei auftretende Fehler müssen einkalkuliert werden.
  • Prüfung der Dokumentation, die der Dienstleister übernehmen soll, auf Vollständigkeit und Aktualität; ggf. Anpassung auf neue Gegebenheiten durch das Outsourcing.
  • Laufende Überprüfung, ob durch Erkenntnisse aus der Umstellung Verträge (Service Level Agreements) oder vorgesehene Sicherheitsmaßnahmen angepasst werden müssen.
In der Einführungsphase des Outsourcing-Vorhabens und der ersten Zeit des Betriebs muss dem Notfallkonzept besondere Aufmerksamkeit geschenkt werden. Bis sich bei allen Beteiligten die notwendige Routine, beispielsweise in der Behandlung von Fehlfunktionen und sicherheitsrelevanten Vorkommnissen eingestellt hat, sind ggf. MitarbeiterInnen zu zusätzlichen Bereitschaftsdiensten heranzuziehen.
Nach der Umstellung/Migration muss das Sicherheitskonzept auf Basis der Erfahrungen und Änderungen während der Umstellungsphase aktualisiert werden:
  • Konkrete Darstellung aller Sicherheitsmaßnahmen
  • Ansprechpartner und Zuständigkeiten mit Namen und notwendigen Kontaktdaten, Erreichbarkeitszeiten
  • Dokumentation der Systemkonfigurationen inkl. Einstellungen sicherheitsrelevanter Parameter
  • Schulungen für das Personal auf den Regelbetrieb
[Quelle: BSI M 2.255]

Phase 7: Planung und Sicherstellen des laufenden Betriebs

Nach Übernahme der Systeme bzw. der Geschäftsprozesse durch den Outsourcing-Dienstleister sind Maßnahmen zur Gewährleistung der IT-Sicherheit im laufenden Betrieb notwendig und müssen bereits im Vorfeld - inklusive Notfall und Eskalationsszenarien - geplant worden sein. Dies sollte in einem Oursourcing-Betriebskonzept erfolgen.
Die einzelnen Aufgaben unterscheiden sich zwar nicht grundsätzlich vom Betrieb innerhalb der eigenen Organisation, durch die Verteilung auf mehrere Partner und zusätzlichem Abstimm- bzw. Kontrollbedarf entstehen allerdings Besonderheiten:
  • Regelmäßige Aktualisierungen von Richtlinien und Dokumentationen
  • Regelmäßige Überprüfungen der Sicherheitskonzepte aller Beteiligten, ob sie noch aufeinander abgestimmt sind und das gewünschte Sicherheitsniveau gewährleisten
  • Auswirkungen von Änderungen im Einflussbereich des Dienstleisters und Information darüber an den Auftraggeber
Im Rahmen des ausgelagerten Betriebs sind weiters durchzuführen:
Regelmäßige Kontrollen
  • Durchführung der vereinbarten Audits
  • Umsetzungsstand der vereinbarten Sicherheitsmaßnahmen
  • Wartungszustand von Systemen und Anwendungen
  • Rechtezuweisung durch den Dienstleister
  • Einsatz von MitarbeiterInnen, die dem Auftraggeber nicht gemeldet wurden, z. B. Vertretungen
  • Performance, Verfügbarkeit, Qualitätsniveau
  • Datensicherung
Regelmäßige Abstimmungen
  • Informationsaustausch zwischen den Partnern über mögliche Auswirkungen auf die Dienstleistung bzw. Sicherheit (z. B. personelle/organisatorische Änderungen, Gesetzesänderungen, geplante Projekte, vorgesehene Tests und Systemänderungen)
  • Information über aufgetretene Probleme
  • wechselseitiges Feedback und Aufzeigen von Verbesserungspotenzialen
  • Motivation der MitarbeiterInnen (etwa positive Beispiele einer gelungenen Kooperation)
  • Änderungswünsche (Hardware, Software, Ausweitung des Dienstleistungsportfolios, gestiegener Ressourcenbedarf)
Regelmäßige Übungen und Tests
  • Reaktion auf Systemausfälle (Teil- oder Totalausfälle)
  • Wiederanlauf, Wiedereinspielen von Datensicherungen
  • Beherrschung von Sicherheitsvorfällen
[Quelle: BSIM 2.256]

7 Vermögenswerte und Klassifizierung von Informationen

Dieses Kapitel nimmt Bezug auf ISO/IEC 27002 7 „Management von Vermögenswerten“.

7.1 Vermögenswerte

Unter Vermögenswerten sind gemäß ISO 27002 ganz allgemein zu verstehen:
  • Informationen (Daten, Verträge, Vereinbarungen, Dokumentationen, Forschungsergebnisse, Handbücher, Schulungsunterlagen, Verfahrensanleitungen, Pläne, Checklisten, Protokolle, …)
  • Software (System-, Anwendungssoftware)
  • Gebäude, Einrichtungen, Fahrzeuge, Betriebsmittel, Hardware, Datenträger
  • Rechen- und Kommunikationsdienste, Versorgungseinrichtungen
  • MitarbeiterInnen mit ihren Qualifikationen und Erfahrungen
  • Immaterielle Werte, wie z. B. Ruf und Image der Organisation.

Das heißt vereinfacht: Alles was für eine Organisation einen Wert darstellt. Die folgenden Maßnahmen sollen die Vermögenswerte der Organisation schützen. Dazu ist es zunächst notwendig, sie zu klassifizieren, d. h. zu identifizieren, in einem Verzeichnis aufzulisten, jeweils dazu EigentümerInnen sowie Verantwortliche zu benennen und Regeln für den sicheren Umgang damit aufzustellen.
[Quelle: CASES Leitfaden „Klassifikation“]

7.1.1 Inventar der Vermögenswerte (Assets) mittels Strukturanalyse

ISO Bezug: 27002 7.1.1
Mittels Strukturanalyse werden die Geschäftsprozesse und die dafür benötigten Assets (Informationen, Anwendungen, IT-Systeme, Räume, Kommunikationsnetze) erhoben. Zuerst werden geschäftskritische Informationen und Anwendungen ermittelt und die betroffenen IT-Systeme, Räume und Netze erfasst.

Klassische Vorgehensweise ist, zuerst die Anwendungen und ausgehend davon die weiteren betroffenen Objekte zu ermitteln. Allerdings ist es dabei schwierig, abstrakte Anwendungen losgelöst von konkreten technischen Komponenten zu erfassen.
Es kann daher auch zweckmäßig sein, zunächst die IT-Systeme zu erheben. Oft lassen sich dann die Anwendungen anhand der betrachteten IT-Systeme leichter ermitteln.
Eine weitere Vereinfachung des Vorgangs kann sich ergeben, wenn als Datenquellen bereits aktuelle Datenbanken oder Übersichten vorhanden und nutzbar sind (z. B. für die Inventarisierung, das Konfigurationsmanagement oder die Gestaltung von Geschäftsprozessen).
Aktivitäten für eine Strukturanalyse:
  • Erfassung der Geschäftsprozesse, Anwendungen und Informationen im Geltungsbereich,
  • Erhebung von Datenträgern und Dokumenten,
  • Erhebung von IT-Systemen,
  • Erfassung der baulichen Gegebenheiten,
  • Netzplanerhebung.

Dabei ist es oft nicht zweckmäßig, jedes Objekt einzeln zu erfassen. Stattdessen sollten Objekte zu Gruppen zusammengefasst werden, wenn sie folgende Ähnlichkeiten aufweisen:
  • vom gleichen Typ,
  • ähnlich konfiguriert,
  • ähnlich in das Netz eingebunden (z. B. IT-Systeme am gleichen Switch),
  • ähnlichen administrativen und infrastrukturellen Rahmenbedingungen unterworfen,
  • sie dienen ähnlichen Anwendungen,
  • haben den gleichen Schutzbedarf.
Damit wird die Strukturanalyse hinsichtlich Datenmenge und Komplexität handhabbar.

Gruppierung

Bei technischen Komponenten wird durch konsequente Gruppenbildung auch die Administration wesentlich vereinfacht, weil es dann nur wenige Grundkonfigurationen gibt. Durch eine möglichst hohe Standardisierung innerhalb einer IT-Umgebung wird außerdem die Zahl potenzieller Sicherheitslücken reduziert. Eine Stichprobe aus einer Gruppe repräsentiert dann in der Regel den Sicherheitszustand der Gruppe. Sicherheitsmaßnahmen für einen solchen Bereich können ohne Unterscheidung verschiedenster Schwachstellen umgesetzt werden. Überdies können damit auch Kosten gespart werden.
Ein wichtigste Beispiel ist die Zusammenfassung von Clients. In der Regel gibt es in einer Organisation viele Clients, die sich jedoch gemäß obigem Schema in eine überschaubare Anzahl von Gruppen aufteilen lassen (dies gilt analog auch für Räume und andere Objekte; in großen Informationsverbünden, wo viele Server die gleiche Aufgaben wahrnehmen, können auch Server zu Gruppen zusammengefasst werden). Die Teilaufgaben der Strukturanalyse werden nachfolgend beschrieben und durch ein begleitendes Beispiel erläutert. Eine ausführliche Version des Beispiels findet sich in den Hilfsmitteln zum IT- Grundschutz auf den BSI-Webseiten. Bei allen Teilaufgaben sollten jeweils Objekte zu Gruppen zusammengefasst werden, wenn dies sinnvoll und zulässig ist.
[Quelle: BSI-Standard 100-2]

7.1.1.1 Erfassung von Geschäftsprozessen, Anwendungen und Informationen

ISO Bezug: 27002 7.1.1
Anwendungen sind Verfahren, welche Geschäftsprozesse und Fachaufgaben in Organisationen (z. B. Behörden, Unternehmen) unterstützen. Ausgehend von jedem Geschäftsprozess bzw. jeder Fachaufgabe im Geltungsbereich sind die damit zusammenhängenden Anwendungen und Informationen zu identifizieren.
Für die geeignete Granularität ist zwischen einerseits einer für die Feststellung des Schutzbedarfs nötige Detaillierung, andererseits der optimalen Effizienz zu optimieren. Abgesehen von der zuvor beschriebenen Gruppenbildung beschränkt sich die Strukturanalyse auf Anwendungen und Informationen, die für die betrachteten Geschäftsprozesse oder Fachaufgaben erforderlich sind und jedenfalls ein Mindestniveau an
  • Geheimhaltung (Vertraulichkeit) oder
  • Korrektheit und Unverfälschtheit (Integrität) oder
  • Verfügbarkeit
erfordern.

Um dies sicherzustellen, sollten bei der Erfassung der Anwendungen die BenutzerInnen bzw. die für die Anwendung bzw. für den Geschäftsprozess Verantwortlichen nach ihrer Einschätzung befragt werden - ggf. in gemeinsamen Meetings der Fach-, IT-Abteilungen und Anwendungsverantwortlichen. Denn es ist angesichts der steigenden Komplexität oft schwierig, Abhängigkeiten zwischen Geschäftsprozess / Fachaufgabe und einer konkreten Anwendung darzustellen.
  • Es ist also für jede Fachaufgabe festzustellen, welche Anwendungen für ihre Abwicklung notwendig sind und auf welche Daten dabei zugegriffen wird.
  • Wurden alternativ zuerst die IT-Systeme erfasst, empfiehlt es sich oft, an ihnen orientiert die darauf laufenden Anwendungen zusammenzutragen. Dabei sollte mit den Servern begonnen werden.
  • Ergänzt wird die Erhebung mit den Clients und - mitunter mobilen - Einzelplatzsystemen.
  • Schließlich wird noch ermittelt, welche Netzkomponenten welche Anwendungen unterstützen.

pro erfasster Anwendung:

  • Zwecks spätere Zuordnungen sollten die Anwendungen durchnummeriert werden.
  • Für Datenschutzbeauftragte/IT-Sicherheitsbeauftragte: Vermerk, ob die beschriebene Anwendung personenbezogene Daten speichert oder verarbeitet (Schutzbedarf der Information ergibt Schutzbedarf der Anwendung)
  • Unterstützte Geschäftsprozesse
  • Verantwortliche und BenutzerInnen der Anwendung (AnsprechpartnerInnen für Sicherheitsfragen)
Es empfiehlt sich natürlich eine tabellarische Darstellung bzw. die Nutzung geeigneter Software.
[Quelle: BSI-Standard 100-2]

7.1.1.2 Erfassung von Datenträgern und Dokumenten

ISO Bezug: 27002 7.1.1
Bei der Erfassung der Anwendungen sollten auch Datenträger und Dokumente mitbetrachtet werden, sie können wie Anwendungen behandelt werden. Jedoch sind sie dann gesondert in der Strukturanalyse zu erfassen, wenn sie nicht mit einer bestimmten Anwendung oder einem IT-System verknüpft sind. Auch dafür sollten möglichst Gruppen gebildet und nur Datenträger und Dokumente mit einem Mindestschutzbedarf berücksichtigt werden.
Beispiele für gesondert erfasste Datenträger und Dokumente:
  • Archiv- und Backup-Datenträger,
  • Datenträger für den Austausch mit externen Kommunikationspartnern,
  • Externe Festplatten, USB-Sticks, Smartphones für den mobilen Einsatz,
  • Ausgedruckte Notfall- und sonstige Handbücher,
  • wichtige Verträge,
  • Mikrofilme.
Empfehlenswert ist auch die Erfassung der Abhängigkeiten zwischen Anwendungen; so sind beispielsweise Informationen über den Lagerbestand Voraussetzungen für die Verarbeitung von Bestellungen.
[Quelle: BSI-Standard 100-2]

7.1.1.3 Erhebung der IT-Systeme

ISO Bezug: 27002 7.1.1
In ebenso tabellarischer Form wird eine Liste der vorhandenen und geplanten IT-Systeme aufgestellt. Der Begriff „IT-System“ umfasst dabei nicht nur Computer im engeren Sinn, sondern auch aktive Netzkomponenten, Netzdrucker, Telekommunikationsanlagen etc. Im Vordergrund steht dabei die technische Realisierung eines IT-Systems, beispielsweise Einzelplatz-PC, Server bzw. Client mit Betriebssystemangabe.
Allerdings werden Systeme betrachtet und nicht einzelne Bestandteile (CPU, Bildschirm); es sei denn sie werden im normalen Betrieb mit unterschiedlichen Systemen verbunden (etwa externe Laufwerke). Eine vollständige, korrekte und aktuelle Auflistung der IT-Systeme ist auch für deren Überprüfung, Wartung, Fehlersuche und Instandsetzung notwendig.
Zu erfassen sind sowohl die vernetzten als auch die nicht vernetzten IT-Systeme, insbesondere also auch solche, die nicht im Netzplan aufgeführt sind. Wurden IT-Systeme im Netzplan zu einer Gruppe zusammengefasst, können sie weiters als ein Objekt behandelt werden, auch solche, die nicht im Netzplan aufgeführt sind (vgl. 7.1.1 Inventar der Vermögenswerte (Assets) mittels Strukturanalyse ). Informationen pro IT-System:
  • eindeutige Nummerierung, Kürzel oder Bezeichnung des IT-Systems,
  • Beschreibung (Typ und Funktion),
  • Plattform (z. B. Hardwarearchitektur/Betriebssystem),
  • bei Gruppen: Anzahl der zusammengefassten IT-Systeme,
  • Aufstellungsort,
  • Status (in Betrieb, im Test, in Planung),
  • Anwendungen, welche dem IT-System zuzuordnen sind (Datenverarbeitung oder -transfer),
  • BenutzerInnen, AnwenderInnen bzw. AdministratorInnen des IT-Systems.
Auch dafür sollten nach Möglichkeit bereits existierende Datenbanken oder Übersichten über die vorhandenen oder geplanten IT-Systeme genutzt werden. Ergebnis ist eine Übersicht, aus der die Zusammenhänge zwischen den wichtigen Anwendungen und den entsprechenden IT-Systemen hervorgehen.
[Quelle: BSI-Standard 100-2]

7.1.1.4 Netzplan

ISO Bezug: 27002 7.1.1
Ein Netzplan ist eine grafische Übersicht über die im Geltungsbereich eingesetzten Komponenten und deren Vernetzung. Netzpläne oder ähnliche grafische Übersichten sind auch aus betrieblichen Gründen in den meisten Institutionen vorhanden.
Für die Informationssicherheit sind folgende Objekte relevant:
  • IT-Systeme (Client- und Server-Computer), aktive Netzkomponenten (wie Switches, Router, WLAN Access Points), Netzdrucker etc.
  • Netzverbindungen zwischen diesen Systemen: LANs (Ethernet, Token-Ring), WLANs, Backbone-Techniken (FDDI, ATM) etc.
  • Verbindungen nach außen (z. B. Internetzugänge über DSL-Modems, Router, ISDN aber auch Funkstrecken, Mobilfunk sowie Standleitungen zu entfernten Gebäuden oder Liegenschaften etc.
Jedes dargestellte Objekt sollte auch in einem zugehörigen Katalog mit folgenden Elementen eingetragen werden:
  • eindeutige Nummerierung, Kürzel oder Bezeichnung als Referenz zur Grafik,
  • vollständige Bezeichnung (Hostname, Identifikationsnummer),
  • Typ und Funktion (z. B. Datenbank-Server für bestimmte Anwendung Nr. X, …),
  • Plattform (Hardware, Betriebssystem),
  • Standort (Gebäude-, Raumnummer),
  • zuständige AdministratorInnen,
  • vorhandenene Kommunikationsschnittstellen (z. B. Internet, LAN, WLAN, Bluetooth etc.),
  • Art der Netzanbindung und Netzadresse.
Für die Netzverbindungen zwischen den Objekten bzw. nach außen wird eingetragen:
  • Art der Verkabelung bzw. Kommunikationsanbindung (z. B. Lichtwellenleiter, verkabeltes LAN, WLAN etc.),
  • maximale Datenübertragungsrate,
  • auf den unteren Schichten verwendete Netzprotokolle (z. B. Ethernet, TCP/IP),
  • externe Netzanbindungen (z. B. Internet mit Name des Providers).
Virtuelle Netze, z. B. virtuelle IT-Systeme, virtuelle Netzverbindungen, wie virtuelle LANs (Virtual Local Area Networks - VLANs) oder virtuelle private Netze (Virtual Private Networks - VPNs), sollten ebenfalls im Netzplan dargestellt werden, wenn ihre logischen (virtuellen) Strukturen wesentlich von den physischen abweichen. Ggf. kann dafür ein separater Netzplan die Übersichtlichkeit verbessern.
Es empfiehlt sich, Bereiche mit unterschiedlichem Schutzbedarf zu kennzeichnen.
Der Netzplan sollte möglichst in elektronischer Form mit Hilfe geeigneter Tools erstellt und gepflegt werden.
[Quelle: BSI-Standard 100-2]

7.1.1.5 Erfassung der Gebäude und Räume

ISO Bezug: 27002 7.1.1
In ein Sicherheitskonzept müssen alle Liegenschaften und Gebäude einbezogen werden, innerhalb derer die betrachteten Geschäftsprozesse und Fachaufgaben betrieben werden. Dazu gehören Betriebsgelände, Gebäude, Etagen, Räume sowie die Wegstrecke zwischen diesen.
Viele Organisationen nutzen ein Gebäude oder eine Etage allein, aber häufig nutzen Organisationen Liegenschaften, die weit verstreut sind oder mit anderen Nutzern geteilt werden müssen. Oft sind Geschäftsprozesse und Fachaufgaben auch in fremden Räumlichkeiten angesiedelt.
Daher ist es of sinnvoll, eine je nach Gegebenheiten mehr oder weniger umfangreiche Übersicht bzw. einen Plan über die Liegenschaften, vor allem die Räume, zu erstellen, in denen IT-Systeme aufgestellt oder die für den IT-Betrieb genutzt werden:
  • Räume, die ausschließlich dem IT-Betrieb dienen (wie Serverräume, Datenträgerarchive),
  • Räume, in denen unter anderem IT-Systeme betrieben werden (wie Büroräume),
  • Schutzschränke, in denen IT-Systeme untergebracht sind, sind wie Räume zu erfassen,
  • weitere Räume, in denen schutzbedürftige Informationen (Datenträger, aber auch Aktenordner und Mikrofilme) aufbewahrt werden,
  • sowie Wegstrecken, über die Kommunikationsverbindungen laufen.
Dabei sollte auch die Art der in den Räumen jeweils verarbeiteten Informationen nachvollziehbar sein.
[Quelle: BSI-Standard 100-2]

7.1.1.6 Aktualisierung der Strukturanalyse

ISO Bezug: 27002 7.1.1
In der Regel werden die IT- und Netzwerkstrukturen ständig an neue Anforderungen der Organisation angepasst. Nicht in jedem Fall werden solche Änderungen umgehend in den Aufzeichnungen der Erhebung bzw. im Netzplan nachgezogen, da dies meist aufwändig ist. In der Praxis werden oft nur größere Änderungen an der IT-Struktur einzelner Bereiche zum Anlass genommen, den Plan zu aktualisieren. Die Folge ist, dass die Aufzeichnungen dann nicht auf dem aktuellen Stand sind.
Eine häufige Vorgehensweise besteht darin, die vorliegenden Aufzeichnungen periodisch oder anlässlich größerer Änderungen bzw. im Zuge von Audits mit den tatsächlich vorhandenen Strukturen und Objekten abzugleichen und gegebenenfalls auf den neuesten Stand zu bringen:
  • Existierende Übersichten, grafische Darstellungen und Netzpläne sichten,
  • Diese ggf. aktualisieren oder neu erstellen,
  • Existierende Informationen über die enthaltenen IT-Systeme sichten und gegebenenfalls aktualisieren und vervollständigen,
  • Existierende Informationen über die enthaltenen Kommunikationsverbindungen sichten und gegebenenfalls aktualisieren und vervollständigen,
  • Existierende Informationen über Liegenschaften, Gebäude und Wegstrecken sichten und gegebenenfalls aktualisieren und vervollständigen.
Dazu sollten auch die IT-Verantwortlichen und AdministratorInnen der einzelnen Anwendungen bzw. Netze konsultiert werden.
Einige Programme zum zentralisierten Netz- und Systemmanagement unterstützen Objeklisten bzw. Netzpläne, indem sie beispielsweise akive Komponenten automatisch erkennen. Zu beachten ist jedoch, dass solche Funktionen temporär zusätzlichen Netzverkehr erzeugen. Es muss sichergestellt sein, dass dieser Netzverkehr nicht zu Beeinträchtigungen des IT-Betriebs führt. Ebenso sollte das Ergebnis von automatischen bzw. halb-automatischen Erkennungen stets daraufhin geprüft werden, ob wirklich alle relevanten Komponenten ermittelt wurden - etwa solche, die sich zum Zeitpunkt des Erkennungslaufes nicht in Betrieb befunden haben.
[Quelle: BSI-Standard 100-2]

7.1.2 Eigentum von Vermögenswerten

ISO Bezug: 27002 7.1.2
Zu jedem Vermögenswert (Asset) muss es eine klar definierte Verantwortlichkeit geben. Dazu wird in der Organisation jedem Vemögenswert bzw. jeder Art von Vermögenswert ein „Eigentümer“ zugewiesen. Dabei ist normalerweise nicht die Eigentümer oder Inhaber im rechtlichen Sinn gemeint, sondern ManagerInnen bzw. Beauftragte, die die Verantwortung für die Verwaltung dieses Vermögenswertes und somit für dessen Sicherheit tragen. Insbesondere sind sie für die Klassifikation des Vemögenswertes und die darauf anzuwendenden Sicherheitsregeln und -maßnahmen verantwortlich. Dazu müssen sie jedoch auch ausreichende und entsprechende Befugnisse besitzen.
Diese Verantwortung kann zwar nicht delegiert werden, aber Eigentümer können MitarbeiterInnen oder BeraterInnen mit der Verwaltung und Ausarbeitung der Regeln beauftragen und genehmigen schießlich die vorgeschlagenen Regeln.
[Quelle: CASES Leitfaden „Klassifikation“]

7.1.2.1 Verantwortliche für Vermögenswerte (Assets)

ISO Bezug: 27002 7.1.2
Grundsätzlich ist die Beteiligung und Mitwirkung aller MitarbeiterInnen einer Organisation an der Umsetzung der erforderlichen Sicherheitsmaßnahmen erforderlich. Dazu müssen sie allerdings wissen, für welche Informationen, Anwendungen und IT-Komponenten sie in welcher Weise verantwortlich sind.
Alle MitarbeiterInnen sind für das verantwortlich, was in ihrem Einflussbereich liegt (es sei denn, es ist explizit anders geregelt). Beispielsweise ist die Leitungsebene der Organisation verantwortlich für alle grundsätzlichen Entscheidungen bei der Einführung einer neuen Anwendung, die Leitung der IT zusammen mit dem Informationssicherheitsmanagement für die Ausarbeitung von Sicherheitsvorgaben für die IT-Komponenten, die AdministratorInnen für deren korrekte Umsetzung und die BenutzerInnen für den sorgfältigen Umgang mit den zugehörigen Informationen, Anwendungen und Systemen.
Es muss jedoch konkret und exakt für alle Informationen, Anwendungen und IT-Komponenten festgelegt werden, wer für diese und deren Sicherheit verantwortlich ist. Dazu sollte immer eine konkrete Person (inklusive Vertretung) und keine abstrakte Gruppe benannt werden, damit die Zuständigkeit jederzeit deutlich erkennbar ist. Bei komplexeren Informationen, Anwendungen und IT-Komponenten sollten alle Verantwortlichen und deren Vertretungen namentlich genannt sein.
[Quelle: BSI M 2.225]

7.1.2.2 Aufgaben der Eigentümer und Verantwortlichen

ISO Bezug: 27002 7.1.2
Die Fachverantwortlichen als Eigentümer von Informationen und Anwendungen müssen die Sicherheitsmaßnahmen zu deren Schutz sicherstellen, das bedeutet, dass
  • der Schutzbedarf der Informationen, Anwendungen und IT-Komponenten korrekt festgestellt wird,
  • die Aufgaben für die Umsetzung der Sicherheitsmaßnahmen klar definiert und zugewiesen werden,
  • die erforderlichen Sicherheitsmaßnahmen umgesetzt werden,
  • dies regelmäßig überprüft wird,
  • der Zugang bzw. Zugriff zu den Informationen, Anwendungen und IT-Komponenten geregelt ist,
  • die Informationssicherheit gefährdende Abweichungen schriftlich dokumentiert werden.
Die Fachverantwortlichen müssen zusammen mit dem Management über eine Vorgehensweise befinden, wie mit eventuellen Restrisiken umgegangen werden soll. Die veranwortliche Entscheidung obliegt der Managementebene.
[Quelle: BSI M 2.225]

7.1.3 Zulässige Nutzung von Vermögenswerten

ISO Bezug: 27002 7.1.3
BenutzerInnen von Informationen und die sie verarbeitenden Einrichtungen sind dafür verantwortlich, dass diese nur gemäß ihrer vorgesehenen Bestimmung verwendet und vor Verlust, Diebstahl, Beschädigung, Kompromittierung etc. geschützt werden. Selbstverständlich gehört dazu auch ein generell sorgfältiger und schonender Umgang mit Geräten wie etwa PCs.
Speziell AdministratorInnen und IT-Verantwortliche müssen mit den ihnen eingeräumten, oft weitreichenden Privilegien sorgfältig und nur im vorgesehen Ausmaß umgehen - dies gilt auch für Notfälle und Ausnahmesituationen.
Bedeutend ist in diesem Zusammenhang auch eine Clear-Desk-Policy, um Kompromittierungen von gedruckten Informationen zu vermeiden.

7.1.3.1 Herausgabe einer PC-Richtlinie

ISO Bezug: 27002 7.1.3, 11.3.3, 15.2.1
Um einen sicheren und ordnungsgemäßen Einsatz von Personalcomputern in größeren Organisationen zu gewährleisten, sollte eine PC-Richtlinie erstellt werden, in der verbindlich vorgeschrieben wird, welche Randbedingungen eingehalten werden müssen und welche IT-Sicherheitsmaßnahmen zu ergreifen sind. Diese PC-Richtlinie soll zumindest den Einsatz von unvernetzten PCs regeln; werden PCs vernetzt betrieben oder als intelligente Terminals genutzt, ist die Richtlinie um diese meist weiter einschränkenden Punkte zu erweitern.
Im Folgenden wird grob umrissen, welche Inhalte für eine solche PC-Richtlinie sinnvoll sind.
Möglicher inhaltlicher Aufbau einer PC-Richtlinie:
  • Zielsetzung und Begriffsdefinitionen:
    Dieser erste Teil der PC-Richtlinie soll dazu dienen, die PC-AnwenderInnen für IT-Sicherheit zu sensibilisieren und zu motivieren. Gleichzeitig werden die für das gemeinsame Verständnis notwendigen Begriffe definiert und eine einheitliche Sprachregelung geschaffen.
  • Geltungsbereich:
    In diesem Teil muss verbindlich festgelegt werden, für welche Teile des Unternehmens bzw. der Behörde die PC-Richtlinie gilt.
  • Rechtsvorschriften und interne Regelungen:
    Hier wird auf wichtige Rechtsvorschriften (z. B. das Datenschutzgesetz 2000 und das Urheberrechtsgesetz) hingewiesen. Darüber hinaus kann diese Stelle genutzt werden, um alle relevanten betriebsinternen Regelungen aufzuführen.
  • Verantwortungsverteilung:
    In diesem Teil wird definiert, wer im Zusammenhang mit dem PC-Einsatz welche Verantwortung trägt. Dabei sind insbesondere die Funktionen IT-BenutzerInnen, Vorgesetzte, PC-AdministratorInnen, Datenschutz-/IT-Sicherheitsbeauftragte, Bereichs-IT-Sicherheitsbeauftragte und Applikations-/Projektverantwortliche zu unterscheiden.
  • Umzusetzende und einzuhaltende IT-Sicherheitsmaßnahmen:
    Im letzten Teil der PC-Richtlinie ist festzulegen, welche IT-Sicherheitsmaßnahmen von den IT-BenutzerInnen einzuhalten bzw. umzusetzen sind. Es kann je nach Schutzbedarf auch über die IT-Grundschutzmaßnahmen hinausgehen.
Die PC-Richtlinie muss regelmäßig - insbesondere im Hinblick auf die IT-Sicherheitsmaßnahmen - aktualisiert werden.
Es ist dafür Sorge zu tragen, dass alle PC-BenutzerInnen ein Exemplar dieser Richtlinie besitzen und dass die Einhaltung regelmäßig überprüft wird.
Sind TelearbeiterInnen im Unternehmen bzw. in der Behörde beschäftigt, sollte die PC-Richtlinie um die dafür spezifischen Regelungen ergänzt werden. Vgl. dazu 11.7.3 Regelungen für Telearbeit.
[eh SYS 5.1]

7.1.3.2 Einführung eines PC-Checkheftes

ISO-Bezug: 27002 7.1.3, 11.3.2, 11.3.3, 15.2.1
Um die durchgeführten IT-Sicherheitsmaßnahmen am PC zu dokumentieren, kann ein PC-Checkheft eingeführt werden, in dem die PC-NutzerInnen die wichtigsten Angaben zum Gerät dokumentiert. Diese Maßnahme bietet sich in erster Linie für kleine und mittlere Organisationen an, große Organisationen führen und verwalten diese Dokumentationen i. Allg. zentral.
Kommt ein PC-Checkheft zum Einsatz, so sollte es folgende Informationen enthalten:
  • Name der PC-Benutzerin bzw. des PC-Benutzers,
  • Aufstellungsort des PC,
  • Einsatzgebiet (z. B. Kundendienst Inland)
  • Erlaubnis (Notebook) aus dem Betriebsräumen zu entfernen
  • Beschreibung der Konfiguration,
  • Zugangsmittel,
  • eingesetzte Hard- und Software,
  • planmäßige Zeitpunkte für die Datensicherungen,
  • durchgeführte Wartungen und Reparaturen,
  • durchgeführte Virenkontrollen,
  • Zeitpunkt von Passwortänderungen,
  • zur Verfügung stehendes Zubehör,
  • durchgeführte Revisionen,
  • Ansprechpartner für Problemfälle und
  • Zeitpunkte der durchgeführten Datensicherungen.
Das Führen eines solchen PC-Checkheftes erleichtert Kontrolltätigkeiten und unterstützt eine notwendige Selbstkontrolle der PC-BenutzerInnen, damit sie regelmäßig Datensicherungen, Passwortänderungen und Viren-Checks durchführen (sofern dies nicht zentral erfolgt (s. o.)).
[eh SYS 5.2]

7.1.3.3 Geeignete Aufbewahrung tragbarer IT-Systeme

ISO Bezug: 27002 7.1.3 11.7.1
Tragbare IT-Systeme wie Notebooks, Netbooks, Tablet-PCs, PDAs oder Smartphones sind durch ihre Bauform immer beliebte Ziele für Diebstähle und müssen sicher aufbewahrt werden - auch dann, wenn sie sich im vermeintlich sicheren Büro befinden. Weil ein tragbares IT-Systeme besonders leicht zu transportieren und zu verbergen ist, sollte das Gerät außerhalb der Nutzungszeiten (beispielsweise in einem Schrank oder Schreibtisch) weggeschlossen oder angekettet werden.

Bei mobilem Einsatz müssen die BenutzerInnen versuchen, die tragbaren IT-Systeme auch außer Haus sicher aufzubewahren. Vgl. 11.7.1 Mobile IT-Geräte.
Einige Hinweise für die mobile Nutzung:
  • Schutz vor Diebstahl und Verlust:
    • Das Gerät sollte gar nicht oder nur in einem minimalen Zeitraum unbeaufsichtigt sein,
    • bei Aufbewahrung eines tragbaren IT-Systems in einem Kraftfahrzeug sollte das Gerät von außen nicht sichtbar sein (Abdecken oder Einschließen in den Kofferraum),
    • jedenfalls sollte das Gerät nur so kurz wie möglich in einem Kraftfahrzeug aufbewahrt werden (keinesfalls über Nacht),
    • wird das mobile IT-System in einem fremden Büro vor Ort benutzt, so ist entweder dieser Raum nach Möglichkeit auch bei kurzzeitigem Verlassen zu verschließen oder das Gerät mitzunehmen. Zusätzlich ist ein Zugriffschutz zu aktivieren oder das Gerät auszuschalten, um unerlaubte Nutzung zu verhindern,
    • in Hotelzimmern sollte das mobile IT-System nicht offen herumliegen, sondern in einem Schrank verschlossen werden.
    • Bietet das Gerät eine Möglichkeit zum Anketten, sollte sie wo möglich genutzt werden.
    • Zur Beaufsichtigung des Geräts gehört auch, es nicht etwa im Taxi, am Flughafen, im Flugzeug oder im Hotelzimmer zu vergessen.
  • Schutz vor Beschädigung:
    • Ein mobiles IT-System sollte nie extremen Temperaturen ausgesetzt werden. Insbesondere der Akku, aber auch das Display können anderenfalls beschädigt werden. Auch deshalb sollten IT-Geräte (aber auch ihre Akkus) nicht in geparkten Autos zurückgelassen werden.
    • Ebenso sollten mobile Endgeräte vor schädlichen Umwelteinflüssen geschützt werden, also beispielsweise vor Feuchtigkeit durch Regen oder Spritzwasser.
    • Mobile IT-Systeme sind heute zwar robust, aber dennoch sollten sie auch bei kürzeren Transportwegen möglichst stoßgeschützt befördert werden. Bei Notebooks sollte beispielsweise das Gerät zusammengeklappt werden, da sowohl die Scharniere als auch der Bildschirm bei einem Sturz leicht beschädigt werden können. Grundsätzlich ist es immer empfehlenswert, für den Transport ein schützendes Behältnis zu verwenden.
Es ist empfehlenswert, für die BenutzerInnen mobiler IT-Systeme ein Merkblatt zu erstellen, das die wichtigsten Hinweise und Vorsichtsmaßnahmen zur geeigneten Aufbewahrung und zum sicheren Transport der Geräte enthält.
[Quelle: BSI M 1.33, M 1.34]

7.1.3.4 Mitnahme von Datenträgern und IT-Komponenten

ISO Bezug: 27002 - 7.1.3
Datenträger und IT-Komponenten sind meist innerhalb der Liegenschaft(en) der eigenen Organisation hinreichend vor Missbrauch und Diebstahl geschützt. Oft sollen sie aber auch außer Haus eingesetzt werden, z. B. bei Dienstreisen oder Telearbeit. Für einen ausreichenden Schutz muss die Mitnahme von Datenträgern und IT-Komponenten klar geregelt werden.
Dabei muss festgelegt werden
  • welche IT-Komponenten bzw. Datenträger außer Haus mitgenommen werden dürfen,
  • wer IT-Komponenten bzw. Datenträger außer Haus mitnehmen darf,
  • welche grundlegenden IT-Sicherheitsmaßnahmen dabei beachtet werden müssen (Virenschutz, Verschlüsselung sensitiver Daten, Aufbewahrung etc.).
Die Art und der Umfang der anzuwendenden IT-Sicherheitsmaßnahmen für extern eingesetzte IT-Komponenten hängt einerseits vom Schutzbedarf der darauf gespeicherten IT-Anwendungen und Daten und andererseits von der Sicherheit der Einsatz- bzw. Aufbewahrungsorte ab.
Grundsätzlich sollte für alle IT-Komponenten, die extern eingesetzt werden sollen, eine entsprechende Genehmigung eingeholt werden müssen.
Gibt es (z. B. in größeren Organisationen) Zutrittskontrollen durch Portier- oder Wachdienste, kann mittels Stichproben kontrolliert werden, inwieweit die Regelungen für die Mitnahme von Datenträgern und IT-Komponenten eingehalten werden. Dabei ist jedoch darauf zu achten, dass solche Kontrollen nicht in unnötig schikanöse Durchsuchungen ausarten.

Außerhalb der organisationseigenen Büros bzw. Liegenschaften sind die BenutzerInnen für den Schutz der ihnen anvertrauten IT verantwortlich und darauf sowie auf zu ergreifende Vorsichtsmaßnahmen sind sie hinzuweisen, etwa:
  • IT-Systeme müssen stets sicher aufbewahrt werden. Bei Dienstreisen sollten sie nicht unbeaufsichtigt bleiben oder in Fahrzeugen zurückgelassen werden (siehe auch 7.1.3.3 Geeignete Aufbewahrung tragbarer IT-Systeme).
  • IT-Systeme wie Notebooks oder Mobiltelefone und deren Anwendungen können i. Allg. durch PINs oder Passwörter abgesichert werden. Diese Mechanismen sollten auch genutzt werden.
  • IT-Systeme oder Datenträger, die sensitive Daten enthalten, sollten möglichst komplett verschlüsselt werden.
  • Die Verwaltung, Wartung und Weitergabe von extern eingesetzten IT-Systemen sollte geregelt werden.
  • Es sollte protokolliert werden, wann und von wem welche IT-Komponenten außer Haus eingesetzt wurden.
  • Bei Mitnahme ins Ausland ist zu beachten, ob es ein unerlaubter Import von Verschlüsselungstechnik sein könnte.
  • Es ist mit der Offenlegung der Daten vor Zollbeamten zu rechnen.
[Quelle: BSI M 1.218]

7.1.3.5 Verhinderung der unautorisierten Nutzung von Rechnermikrofonen und Videokameras

ISO Bezug: 27002 7.1.3, 9.1.5, 10.8.1
Das Mikrofon bzw. die Videokamera eines vernetzten Rechners kann von denjenigen benutzt werden, die Zugriffsrechte auf die entsprechende Gerätedatei haben. Der Zugriff auf die Gerätedatei sollte nur möglich sein, solange jemand an dem IT-System arbeitet. Wenn die Benutzung eines vorhandenen Mikrofons oder einer Kamera generell verhindert werden soll, müssen diese - wenn möglich - ausgeschaltet oder physikalisch vom Gerät getrennt werden.
Falls das Mikrofon bzw. die Kamera in den Rechner (bzw. den Bildschirm) integriert ist und nur durch Software ein- und ausgeschaltet werden kann, müssen die Zugriffsrechte so gesetzt sein, dass es keine Unbefugten benutzen können.
Es ist zu prüfen, ob Zugriffsrechte und Eigentümer bei einem Zugriff auf die Gerätedatei verändert werden. Falls dies der Fall ist oder falls gewünscht ist, dass alle BenutzerInnen das Mikrofon bzw. die Kamera benutzen können (und nicht nur in Einzelfällen eine Freigabe durch die SystemadministratorInnen erfolgen soll), muss die Systemadministration ein Kommando zur Verfügung stellen, das
  • nur aktiviert werden kann, wenn jemand an dem IT-System angemeldet ist,
  • nur durch diese BenutzerInnen aktiviert werden kann und
  • die Zugriffsberechtigungen den BenutzerInnen nach dem Abmelden wieder entzieht.
Wünschenswert wäre es auch, Mikrofon und Kamera nach einer voreingestellten Zeitspanne ohne Aktivität automatisch abzuschalten (Timeout).
[eh SYS 5.6]

7.1.3.6 Absicherung von Wechselmedien

ISO Bezug: 27002 7.1.3, 10.7.1, 10.8
Wechselmedien, wie etwa USB-Sticks, USB-Festplatten, CD-ROMs, ZIP-Disketten etc., ermöglichen raschen und einfachen Transfer von Daten und Programmen, bringen aber auch eine Reihe von Risiken mit sich.
Als derartige Risiken wären unter anderem zu nennen:
  • unkontrolliertes Booten von Geräten etwa von USB-Sticks, USB Festplatten oder CD-ROM,
  • unautorisierte Installation von Software und
  • unberechtigte Kopien von Daten auf Wechselmedien (Verlust der Vertraulichkeit).
Zur Verringerung dieser Bedrohungen stehen - abhängig von der Art der Wechselmedien und dem zugrunde liegenden Betriebssystem - eine Reihe von Möglichkeiten zur Verfügung, die unten beispielhaft angeführt werden. Es ist aber zu betonen, dass in vielen Fällen eine völlige Sperre der Wechselmedien entweder technisch nicht möglich oder aber aus betrieblichen Gründen nicht durchsetzbar ist. Hier sind zusätzliche personelle (Anweisungen, Verbote, …) und organisatorische Maßnahmen (Kontrollen, …) erforderlich.
Maßnahmen zur Sicherung von Wechselmedien:
  • Verzicht auf USB-, CD-ROM-, …, Laufwerke (bzw. ihr nachträglicher Ausbau)
  • (Physischer) Verschluss von Laufwerken (z. B. durch Einsatz von Diskettenschlössern).
  • (Logische) Sperre von Schnittstellen:
    Viele Betriebssysteme bieten die Möglichkeit, Schnittstellen zu sperren. Dabei ist allerdings zu beachten, dass dies nicht immer technisch möglich (z. B. SCSI-Schnittstellen) und oft auch aus betrieblichen Gründen nicht durchführbar ist (z. B. ist die parallele Schnittstelle oft für den Anschluss eines Druckers offen zu halten).
  • Deaktivierung im BIOS:
    Das BIOS (Basic Input/Output System) bietet Möglichkeiten um nur von bestimmten Laufwerken zu booten. Es muss jedoch auch sichergestellt werden, dass die BenutzerInnen diese Einstellungen nicht mehr verändern können.
  • Verschlüsselung:
    Es existieren verschiedenste Produkte, die Zugriffe ausschließlich auf Datenträger, die mit bestimmten kryptografischen Schlüsseln versehen worden sind, zulassen.
  • Regeln:
    In vielen Fällen ist die Benutzung externer Speichermedien durchaus erlaubt, jedoch bestimmten Regeln unterworfen. Es sollte hierbei jedenfalls das Booten von Wechselmedien im BIOS deaktiviert werden. Solche Regeln könnten etwa Beschränkungen auf die Verwendung bestimmter Dateitypen sein. Die jeweiligen Regeln müssen allen BenutzerInnen bekannt gegeben werden und deren Einhaltung kontrolliert werden.
  • Gegebenenfalls Verblenden und Verplomben von Schnittstellen
    Nach Anschluss aller erforderlichen Schnittstellen wird die Rückseite des Gerätes mit einer speziellen Abdeckung verblendet. Diese wird verplombt, so dass etwaige Manipulationen ersichtlich sind. Diese Vorgehensweise bietet einen relativ hohen Grad an Sicherheit (insbesondere an nachträglichen Nachweismöglichkeiten), es ist aber zu bedenken, dass damit die Flexibilität der Systeme stark eingeschränkt wird. Häufige Übersiedlungen, Konfigurationsänderungen etc. können die Akzeptanz dieser Maßnahme bei BenutzerInnen und Systemverantwortlichen stark reduzieren.
Es ist auch zu bedenken, dass bei IT-Systemen im Netzwerk ein Laden von Treibern etc. etwa über das Internet oder mittels Attachments von E-Mails möglich ist. Hier sind entsprechende Vorkehrungen zu treffen. Vgl. 11.7.1.4 Wechselmedien und externe Datenspeicher.
[eh SYS 5.3]

7.2 Klassifizierung von Informationen

ISO Bezug: 27002 7.2
Die Klassifikation dient zur Identifizierung, Dokumentation und Umsetzung der Regeln für die richtige Verwendung von Informationen durch ihren jeweiligen Eigentümer. Bei der Klassifikation wird jedem Vermögenswert (Asset) eine bestimmte Sicherheitsklasse zugeordnet.
Jede solche Sicherheitsklasse gibt die Anforderungen bezüglich Vertraulichkeit, Integrität und Verfügbarkeit des Assets wieder. Die Klassifikation ist ein umfassender Ansatz, bei dem die einzelnen Assets durch ihre Klassen repräsentiert werden. Somit muss nicht für jedes Asset eine eigene Liste mit Regeln erstellt werden.
Die Herausforderungen bei Klassifikation sind zunächst die richtige Einschätzung der jeweiligen Sicherheitsklasse, aber auch die Gewährleistung einer vollständigen und stimmigen Klassifikation, deren Teilbereiche ja von unterschiedlichen Eigentümern interpretiert werden. Daher sollten Standardmethoden verwendet werden.

Ein Leitfaden zur Klassifizierung nach Vertraulichkeits- und Datenschutzkriterien ist unter 5.2.5 Klassifizierung von Informationen beschrieben.
[Quelle: CASES Leitfaden „Klassifikation“]

8 Personelle Sicherheit

Dieses Kapitel nimmt Bezug auf ISO/IEC 27002 8 „Personelle Sicherheit“.
Die MitarbeiterInnen stellen eine der wichtigsten Ressourcen einer Organisation dar. IT-Sicherheit kann auch bei besten technischen Maßnahmen nur funktionieren, wenn die MitarbeiterInnen ein ausgeprägtes Sicherheitsbewusstsein haben und bereit und fähig sind, die Vorgaben in der täglichen Praxis umzusetzen. Andererseits stellen MitarbeiterInnen auch potenzielle Angriffs- oder Fehlerquellen dar.
Aus diesen Gründen ist der Schulung und Sensibilisierung für Fragen der IT-Sicherheit eine besondere Bedeutung zuzumessen. Darüber hinaus ist es auch notwendig, sich mit den Möglichkeiten und potenziellen Problemen von MitarbeiterInnen auseinander zu setzen („Know your Employee“).
Im Folgenden werden in 8.1 Regelungen für MitarbeiterInnen Regelungen angeführt, die teilweise sinngemäß auch für Fremdpersonal gelten, 8.2 Regelungen für den Einsatz von Fremdpersonal gibt einige spezielle Regelungen für Fremdpersonal.
8.3 Sicherheitssensibilisierung und -schulung schließlich führt Maßnahmen zur Sensibilisierung und Schulung im Bereich IT-Sicherheit auf.

8.1 Regelungen für MitarbeiterInnen

8.1.1 Verpflichtung der MitarbeiterInnen zur Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen

ISO Bezug: 27002 8.1.3
Bei der Einstellung von MitarbeiterInnen sind diese zur Einhaltung einschlägiger Gesetze (z. B. Bundesgesetz über den Schutz personenbezogener Daten (Datenschutzgesetz 2000) § 15 „Datengeheimnis“, § 14 „Datensicherheitsmaßnahmen“ und § 13 „Genehmigungspflichtige Übermittlung und Überlassung von Daten ins Ausland“, sowie dem Informationssicherheitsgesetz für den Bereich der öffentlichen Verwaltung), Vorschriften und interner Regelungen zu verpflichten.
Damit sollen neue MitarbeiterInnen mit den bestehenden Vorschriften und Regelungen zur IT-Sicherheit bekannt gemacht und gleichzeitig zu deren Einhaltung motiviert werden. Dabei ist es sinnvoll, nicht nur die Verpflichtung durchzuführen, sondern auch die erforderlichen Exemplare der Vorschriften und Regelungen auszuhändigen und gegenzeichnen zu lassen bzw. für die MitarbeiterInnen an zentraler Stelle zur Einsichtnahme vorzuhalten.
Neben der Verpflichtung zur Einhaltung von Gesetzen und Vorschriften empfiehlt es sich insbesondere, Regelungen zu folgenden Bereichen zu treffen, die dann auch in eine entsprechende Verpflichtungserklärung aufzunehmen sind:

8.1.2 Aufnahme der sicherheitsrelevanten Aufgaben und Verantwortlichkeiten in die Stellenbeschreibung

ISO Bezug: 27002 8.2.3, 8.1.1
Bei der Erstellung von Stellenbeschreibungen ist dafür Sorge zu tragen, dass alle sicherheitsrelevanten Aufgaben und Verantwortlichkeiten explizit in diese Beschreibungen aufgenommen werden. Anzuführen sind dabei sowohl die allgemein aus der organisationsweiten IT-Sicherheitspolitik abzuleitenden Verpflichtungen als auch spezielle Verantwortlichkeiten auf Grund der Tätigkeit.
Dies gilt in besonderem Maße für MitarbeiterInnen mit speziellen Sicherheitsaufgaben (Mitglieder des IT-Sicherheitsmanagement-Teams, Datenschutzbeauftragte, IT-Sicherheitsbeauftragte, Bereichs-IT-Sicherheitsbeauftragte, Applikations-/Projektverantwortliche).

8.1.3 Vertretungsregelungen

ISO Bezug: 27002 8.1.1
Vertretungsregelungen haben den Sinn, für vorhersehbare (Urlaub, Dienstreise) und auch unvorhersehbare Fälle (Krankheit, Unfall, Kündigung) des Personenausfalls die Fortführung der Aufgabenwahrnehmung zu ermöglichen. Daher muss vor Eintritt eines solchen Falles geregelt sein, wer wen in welchen Angelegenheiten mit welchen Kompetenzen vertritt. Dies ist besonders im Bereich der Informationsverarbeitung von Bedeutung, da dafür meist Spezialwissen sowie eine zeitgerechte Einarbeitung unkundiger MitarbeiterInnen unbedingt erforderlich sind.
Für die Vertretungsregelungen sind folgende Randbedingungen einzuhalten:
  • Die Übernahme von Aufgaben im Vertretungsfall setzt voraus, dass der Verfahrens- oder Projektstand hinreichend dokumentiert ist.
  • Die VertreterInnen müssen so geschult werden, dass sie die Aufgaben jederzeit übernehmen können. Stellt sich heraus, dass es Personen gibt, die aufgrund ihres Spezialwissens nicht kurzfristig ersetzbar sind, so bedeutet deren Ausfall eine gravierende Gefährdung des Normalbetriebes. Hier ist es von besonders großer Bedeutung, VertreterInnen zu schulen.
  • Es muss festgelegt sein, welcher Aufgabenumfang im Vertretungsfall von wem wahrgenommen werden soll.
  • Die VertreterInnen dürfen die erforderlichen Zugangs- und Zutrittsberechtigungen nur im Vertretungsfall erhalten.
  • Ist es in Ausnahmefällen nicht möglich, für Personen kompetente VertreterInnen zu benennen oder zu schulen, sollte frühzeitig überlegt werden, welche externen Kräfte für den Vertretungsfall eingesetzt werden können.
  • Es sollte vermieden werden, dass Vertretungsregeln u.U. vorgesehene Mehraugenprinzipien unterlaufen, z. B. wenn sich zwei kollektiv Berechtigte wechselseitig vertreten.
  • Im Zusammenhang mit der Verwendung von kryptographischen Systemen ist auch über ein Verfahren zur Offenlegung von kryptographischen Schlüsseln im Rahmen des Kryptokonzeptes zu achten (siehe auch 12.6 Kryptographische Maßnahmen).

8.1.4 Geregelte Verfahrensweise beim Ausscheiden von MitarbeiterInnen

ISO Bezug: 27002 8.3
Scheiden MitarbeiterInnen aus, so sollten einige Punkte beachtet werden.
Dies wären:
  • Vor dem Ausscheiden ist eine Einweisung der NachfolgerInnen durchzuführen.
  • Von den Ausscheidenden sind sämtliche Unterlagen, ausgehändigte Schlüssel, ausgeliehene IT-Geräte (z. B. tragbare Rechner, Speichermedien, Dokumentationen) zurückzufordern. Insbesondere sind die Behörden- bzw. Firmenausweise einzuziehen.
  • Es sind sämtliche für die Ausscheidenden eingerichteten Zugangsberechtigungen und Zugriffsrechte zu entziehen bzw. zu löschen. Dies betrifft auch die externen Zugangsberechtigungen via Datenübertragungseinrichtungen. Wurde in Ausnahmefällen eine Zugangsberechtigung zu einem IT-System zwischen mehreren Personen geteilt (z. B. mittels eines gemeinsamen Passwortes), so ist nach Ausscheiden einer der Personen die Zugangsberechtigung zu ändern.
  • Es ist sicherzustellen, dass bei Ausscheidenden keine Unterlagen, Betriebsmittel oder Zugangsmöglichkeiten verbleiden, und diese Nachfolgenden für ihre Tätigkeiten zur Verfügung stehen.
  • Vor der Verabschiedung sollte noch einmal explizit darauf hingewiesen werden, dass alle Verschwiegenheitserklärungen weiterhin in Kraft bleiben und keine im Rahmen der Tätigkeit erhaltenen Informationen weitergegeben werden dürfen.
  • Nach Möglichkeit sollte eine Neuvergabe der User-IDs an andere MitarbeiterInnen vermieden/ausgeschlossen werden.
  • Sind die ausscheidenden Personen FunktionsträgerInnen in einem Notlaufplan, so ist der Notlaufplan zu aktualisieren.
  • Sämtliche mit Sicherheitsaufgaben betrauten Personen, insbesondere der Portierdienst, sind über das Ausscheiden der MitarbeiterInnen zu unterrichten.
  • Ausgeschiedenen MitarbeiterInnen ist der unkontrollierte Zutritt zum Behörden- oder Firmengelände, insbesondere zu Räumen mit IT-Systemen zu verwehren.
  • Optional kann sogar für den Zeitraum zwischen Aussprechen der Kündigung und dem Ausscheiden der Entzug sämtlicher Zugangs- und Zugriffsrechte auf IT-Systeme sowie darüber hinaus auch das Verbot, schützenswerte Räume zu betreten, ausgesprochen werden.
  • Als ein praktikables Hilfsmittel haben sich Laufzettel erwiesen, auf denen die einzelnen Aktivitäten der Ausscheidenden vorgezeichnet sind, die sie vor Verlassen der Behörde bzw. des Unternehmens zu erledigen haben.

8.1.5 Geregelte Verfahrensweise bei Versetzung von MitarbeiterInnen

ISO Bezug: 27002 8.3
Bei Versetzung von MitarbeiterInnen oder einer wesentlichen Änderung ihrer Tätigkeit sind ihre Zugangsberechtigungen sowie Zugriffsrechte auf Übereinstimmung mit den neuen Anforderungen zu überprüfen und gegebenenfalls anzupassen.

8.1.6 Gewährleistung eines positiven Betriebsklimas

ISO Bezug: 27002 8.2.1
Ein positives Betriebsklima motiviert die MitarbeiterInnen einerseits zur Einhaltung von IT-Sicherheitsmaßnahmen und bewirkt andererseits die Reduzierung von fahrlässigen oder vorsätzlichen Handlungen (vgl. § 126a Datenbeschädigung (StGB)), die eine Störung des IT-Betriebs herbeiführen können. Daher sollte auch unter IT-Sicherheitsaspekten versucht werden, ein positives Betriebsklima zu erreichen.
Dazu gehört auch die ergonomische Gestaltung des Arbeitsplatzes. Hierzu besteht eine Reihe von Regelungen und Normen, deren Nichtbeachtung u. a. eventuell zu Sicherheitsproblemen führen kann. Ergonomie ist nicht Gegenstand dieses Handbuches, die Wichtigkeit einer ergonomischen Gestaltung des Arbeitsplatzes sei aber hier nochmals betont.
Weiters ist bei der Ausstattung von Arbeitsplätzen darauf zu achten, dass die Einhaltung von IT-Sicherheitsmaßnahmen unterstützt wird. Dazu gehören etwa verschließbare Schreibtische oder Schränke, in denen Datenträger, Dokumentationen, Unterlagen und Zubehör verschlossen werden können.
Ursache für eine unzureichende Aufgabenerfüllung können oftmals persönliche Probleme von ArbeitnehmerInnen sein. Daher ist es für jede Organisation wichtig, ihre MitarbeiterInnen und eventuelle potenzielle Probleme zu kennen („Know your Employee“). In vielen Fällen kann es hilfreich sein, wenn eine Anlaufstelle zur Verfügung steht, die bei solchen Problemen konkrete Hilfe und Lösungsmöglichkeiten anbieten kann.

8.1.7 Clear-Desk-Policy

ISO Bezug: 27002 8.2.2
Alle MitarbeiterInnen sollten vor ihrer Abwesenheit ihre Unterlagen und den persönlichen Arbeitsbereich verschließen: Schreibtisch, Schrank, PC und Telefon. Dies gilt insbesondere für Großraumbüros, aber auch in den anderen Fällen ist dafür Sorge zu tragen, dass keine unberechtigten Personen (BesucherInnen, Reinigungspersonal, unbefugte MitarbeiterInnen, …) Zugriff zu Schriftstücken, Datenträgern und IT-Komponenten haben.
Ist eine „Clear-Desk-Policy“-Regelung in einer Organisation vorgesehen, so sollte die Einhaltung dieser Regelung in die Verpflichtungserklärung aller MitarbeiterInnen (vgl. 8.1.1 Verpflichtung der MitarbeiterInnen zur Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen) aufgenommen werden.

8.1.8 Benennung vertrauenswürdiger AdministratorInnen und VertreterInnen

ISO Bezug: 27002 8.1.1
AdministratorInnen von IT-Systemen und ihren VertreterInnen müssen vom Betreiber großes Vertrauen entgegengebracht werden können. Sie haben - in Abhängigkeit vom eingesetzten System - weitgehende und oftmals allumfassende Befugnisse. AdministratorInnen und ihre VertreterInnen sind in der Lage, auf alle gespeicherten Daten zuzugreifen, sie ggf. zu verändern und Berechtigungen so zu vergeben, dass erheblicher Missbrauch möglich wäre.
Das hierfür eingesetzte Personal muss sorgfältig ausgewählt werden. Es soll regelmäßig darüber belehrt werden, dass die Befugnisse nur für die erforderlichen Administrationsaufgaben verwendet werden dürfen. Eine regelmäßige Kontrolle von AdministratorInnen - etwa durch Auswertung von Protokollen durch Revisoren - ist vorzusehen.
Darüber hinaus sollte geprüft werden, inwieweit durch technische Maßnahmen - etwa die Verschlüsselung von ausgewählten Daten oder Zugriffsbeschränkungen zu Protokollfiles - die Befugnisse von AdministratorInnen eingeschränkt werden können, ohne deren Aufgabenerfüllung zu beeinträchtigen.

8.1.9 Verpflichtung der PC-BenutzerInnen zum Abmelden

ISO Bezug: 27002 8.1.3
Wird ein PC von mehreren BenutzerInnen genutzt und besitzen die einzelnen BenutzerInnen unterschiedliche Zugriffsrechte auf im PC gespeicherte Daten oder Programme, so kann der erforderliche Schutz mittels einer Zugriffskontrolle nur dann erreicht werden, wenn alle BenutzerInnen sich nach Aufgabenerfüllung bzw. bei Verlassen des Arbeitsplatzes am PC abmelden. Ist es Dritten möglich, an einem PC unter der Identität von Anderen weiterzuarbeiten, so ist jegliche sinnvolle Zugriffskontrolle unmöglich. Daher sind alle PC-BenutzerInnen zu verpflichten, sich bei Verlassen des Arbeitsplatzes abzumelden.
Ist keine Zugriffskontrolle realisiert, so ist die Abmeldung der BenutzerInnen aus Gesichtspunkten der Ordnungsmäßigkeit dennoch vorzuschreiben.
Ist absehbar, dass nur eine kurze Unterbrechung der Arbeit erforderlich ist, kann an Stelle des Abmeldens auch eine manuelle oder nach einer gewissen Zeit automatische Aktivierung der Bildschirmsperre erfolgen.

8.1.10 Kontrolle der Einhaltung der organisatorischen Vorgaben

ISO Bezug: 27002 8.1.3
Mittels Protokollauswertung oder durch Stichproben ist in angemessenen Zeitabständen zu überprüfen, ob die BenutzerInnen eines IT-Systems die organisatorischen Vorgaben (etwa Verpflichtung zur Abmeldung nach Aufgabenerfüllung oder Verbot der Weitergabe von Passwörtern) auch tatsächlich einhalten.
Kontrollen sollten vor allen Dingen darauf ausgerichtet sein, Mängel abzustellen. Für die Akzeptanz von Kontrollen ist es wichtig, dass dies allen Beteiligten als Ziel der Kontrollen erkennbar ist und dass dabei keine Personen bloßgestellt werden oder als „Schuldige“ identifiziert werden. Wenn die MitarbeiterInnen dies befürchten müssen, besteht die Gefahr, dass sie nicht offen über ihnen bekannte Schwachstellen und Sicherheitslücken berichten, sondern versuchen, bestehende Probleme zu vertuschen. Es ist daher sinnvoll, während einer Kontrolle mit den Beteiligten über mögliche Problemlösungen zu sprechen und entsprechende Abhilfen vorzubereiten.
Wenn MitarbeiterInnen eine Regelung ignorieren oder umgehen, ist das meist ein Zeichen dafür, dass diese nicht mit den Arbeitsabläufen vereinbar ist oder durch die MitarbeiterInnen nicht umgesetzt werden kann. Beispielsweise ist eine Anweisung, vertrauliche Schreiben nicht unbeaufsichtigt am Drucker liegen zu lassen, unsinnig, wenn zum Drucken nur ein weit entfernter Netzdrucker zur Verfügung steht.
Wenn bei Kontrollen Mängel festgestellt werden, kommt es nicht darauf an, nur die Symptome zu beseitigen. Vielmehr ist es wichtig, die Ursachen für diese Probleme festzustellen und Lösungen aufzuzeigen. Diese können beispielsweise in der Änderung bestehender Regelungen oder in der Hinzunahme technischer Maßnahmen bestehen.

8.1.11 Geregelte Verfahrensweise bei vermuteten Sicherheitsverletzungen

ISO Bezug: 27002 8.2.3
Die Vorgehensweise zur Untersuchung angeblicher (bewusster oder versehentlicher) Verletzungen von Sicherheitsvorgaben sowie potenzielle Konsequenzen - im Falle interner MitarbeiterInnen können dies beispielsweise disziplinäre Maßnahmen sein, im Falle externer MitarbeiterInnen etwa vertraglich abgeleitete Konsequenzen - sollen festgelegt, vom Management verabschiedet und allen MitarbeiterInnen bekannt sein.
Eine derartig geregelte Verfahrensweise kann einerseits infolge der abschreckenden Wirkung zur Prävention von Sicherheitsverletzungen dienen und gewährleistet andererseits eine korrekte und faire Behandlung von Personen, denen Sicherheitsverletzungen angelastet werden.

8.2 Regelungen für den Einsatz von Fremdpersonal

8.2.1 Regelungen für den kurzfristigen Einsatz von Fremdpersonal

ISO Bezug: 27002 8.2.1
Kurzfristig oder einmalig zum Einsatz kommendes Fremdpersonal ist wie BesucherInnen zu behandeln, d. h. dass also etwa der Aufenthalt in sicherheitsrelevanten Bereichen nur in Begleitung von MitarbeiterInnen der Behörde bzw. des Unternehmens erlaubt ist etc. (vgl. dazu etwa 9.1.6 Portierdienst).

8.2.2 Verpflichtung externer MitarbeiterInnen zur Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen

ISO Bezug: 27002 8.1.3
Externe MitarbeiterInnen, die über einen längeren Zeitraum in einer oder für eine Organisation tätig sind und evtl. Zugang zu vertraulichen Unterlagen und Daten bekommen könnten, sind ebenfalls schriftlich zur Einhaltung der geltenden einschlägigen Gesetze, Vorschriften und internen Regelungen zu verpflichten.
In B Muster für Verträge, Verpflichtungserklärungen und Dokumentationen werden Beispiele für die Formulierung derartiger Verpflichtungserklärungen gegeben.

8.2.3 Beaufsichtigung oder Begleitung von Fremdpersonen

ISO Bezug: 27002 8.1.2
Fremde (BesucherInnen, HandwerkerInnen, Wartungs- und Reinigungspersonal) sollten, außer in Räumen, die ausdrücklich dafür vorgesehen sind, nicht unbeaufsichtigt sein (siehe auch 9.1.4 Zutrittskontrolle und 9.1.6 Portierdienst). Wird es erforderlich, Fremde allein im Büro zurückzulassen, sollte man KollegInnen ins Zimmer oder die BesucherInnen zu KollegInnen bitten.
Ist es nicht möglich, Fremdpersonen (z. B. Reinigungspersonal) ständig zu begleiten oder zu beaufsichtigen, sollte zumindest der persönliche Arbeitsbereich abgeschlossen werden: Schreibtisch, Schrank und PC (Schloss für Diskettenlaufwerk, Tastaturschloss). Siehe auch 8.1.7 Clear-Desk-Policy.
Für den häuslichen Arbeitsplatz gilt, dass Familienmitglieder und BesucherInnen sich nur dann alleine im Arbeitsbereich aufhalten dürfen, wenn alle Arbeitsunterlagen verschlossen aufbewahrt sind und die IT über einen aktivierten Zugangsschutz gesichert ist (vgl. 11.7.2 Geeignete Einrichtung eines häuslichen Arbeitsplatzes und 11.7.3 Regelungen für Telearbeit).
Die Notwendigkeit dieser Maßnahmen ist den MitarbeiterInnen zu erläutern und ggf. in einer Dienstanweisung festzuhalten. Eine Dokumentation über den Aufenthalt von Fremdpersonen kann in einem Besucherbuch geführt werden.

8.2.4 Information externer MitarbeiterInnen über die IT-Sicherheitspolitik

ISO Bezug: 27002 8.2.2
Externe MitarbeiterInnen sind - so weit es zur Erfüllung ihrer Aufgaben und Verpflichtungen erforderlich ist - über hausinterne Regelungen und Vorschriften zur IT-Sicherheit sowie die organisationsweite IT-Sicherheitspolitik zu unterrichten.

8.3 Sicherheitssensibilisierung und -schulung

8.3.1 Geregelte Einarbeitung/Einweisung neuer MitarbeiterInnen

ISO Bezug: 27002 8.2.2
Neuen MitarbeiterInnen müssen interne Regelungen, Gepflogenheiten und Verfahrensweisen im IT-Einsatz bekannt gegeben werden. Ohne eine entsprechende Einweisung kennen sie ihre AnsprechpartnerInnen bzgl. IT-Sicherheit nicht. Sie wissen nicht, welche IT-Sicherheitsmaßnahmen durchzuführen sind und welche IT-Sicherheitspolitik die Behörde bzw. das Unternehmen betreibt. Daraus können Störungen und Schäden für den IT-Einsatz erwachsen. Daher kommt der geregelten Einarbeitung neuer MitarbeiterInnen eine entsprechend hohe Bedeutung zu.
Die Einarbeitung bzw. Einweisung sollte zumindest folgende Punkte umfassen:

8.3.2 Schulung vor Programmnutzung

ISO Bezug: 27002 8.1.1, 8.2.2
Durch unsachgemäßen Umgang mit IT-Anwendungen hervorgerufene Schäden können vermieden werden, wenn die BenutzerInnen eingehend in die IT-Anwendungen eingewiesen werden. Daher ist es unabdingbar, dass die BenutzerInnen vor der Übernahme IT-gestützter Aufgaben ausreichend geschult werden.
Dies betrifft sowohl die Nutzung von Standardprogrammpaketen als auch von speziell entwickelten IT-Anwendungen. Darüber hinaus müssen auch bei umfangreichen Änderungen in einer IT-Anwendung Schulungsmaßnahmen durchgeführt werden.
Stehen leicht verständliche Handbücher zu IT-Anwendungen bereit, so kann an Stelle der Schulung auch die Aufforderung stehen, sich selbstständig einzuarbeiten. Eine wesentliche Voraussetzung dazu ist allerdings die Bereitstellung ausreichender Einarbeitungszeit.

8.3.3 Schulung und Sensibilisierung zu IT-Sicherheitsmaßnahmen

ISO Bezug: 27002 8.2.2
Umfassende IT-Sicherheit kann nur dann gewährleistet werden, wenn alle beteiligten und betroffenen Personen einen angemessenen Kenntnisstand über IT-Sicherheit allgemein und insbesondere über die Gefahren und Gegenmaßnahmen in ihrem eigenen Arbeitsgebiet haben. Es liegt in der Verantwortung der Organisationsleitung, durch geeignete Schulungsmaßnahmen hierfür die nötigen Voraussetzungen zu schaffen. Darüber hinaus sollte alle BenutzerInnen dazu motiviert werden, sich auch in Eigeninitiative Kenntnisse anzueignen.
Angesichts des Umfangs der möglichen Schulungsthemen und der Bedeutung der IT-Sicherheit ist bei der Auswahl der Schulungsinhalte ein koordiniertes Vorgehen erforderlich. Dieses ist in Schulungskonzepten darzulegen und zu dokumentieren.
Es sollte versucht werden, Schulungsthemen zur IT-Sicherheit soweit möglich in andere Schulungskonzepte der betreffenden Organisation, etwa in die IT-Anwenderschulung, zu integrieren. Eine solche Einbindung hat den Vorteil, dass IT-Sicherheit unmittelbar als Bestandteil des IT-Einsatzes wahrgenommen wird.
Insbesondere sollen folgende Themen in der Schulung zu IT-Sicherheitsmaßnahmen vermittelt werden:
  • Sensibilisierung für IT-Sicherheit
    Die überwiegende Zahl von Schäden im IT-Bereich entsteht durch Nachlässigkeit. Um dies zu verhindern, ist jede/r Einzelne zum sorgfältigen Umgang mit der IT zu motivieren. Zusätzlich sind Verhaltensregeln zu vermitteln, die Verständnis für die IT-Sicherheitsmaßnahmen wecken. Alle MitarbeiterInnen sind auf die Notwendigkeit der IT-Sicherheit hinzuweisen. Das Aufzeigen der Abhängigkeit der Organisation und damit der Arbeitsplätze von dem reibungslosen Funktionieren der IT-Systeme ist ein geeigneter Einstieg in die Sensibilisierung. Darüber hinaus ist der Wert von Informationen herauszuarbeiten, insbesondere unter den Gesichtspunkten Vertraulichkeit, Integrität und Verfügbarkeit. Diese Sensibilisierungsmaßnahmen sind in regelmäßigen Zeitabständen zu wiederholen, evtl. auch durch praktische Hinweise z. B. in hausinternen Publikationen, im Intranet oder am „Schwarzen Brett“.
  • Die mitarbeiterInnenbezogenen IT-Sicherheitsmaßnahmen
    Zu diesem Thema sollen die IT-Sicherheitsmaßnahmen vermittelt werden, die in einem IT-Sicherheitskonzept erarbeitet wurden und von den einzelnen MitarbeiterInnen umzusetzen sind. Dieser Teil der Schulungsmaßnahmen hat große Bedeutung, da viele IT-Sicherheitsmaßnahmen erst nach einer entsprechenden Schulung und Motivation effektiv umgesetzt werden können.
  • Die produktbezogenen IT-Sicherheitsmaßnahmen
    Zu diesem Thema sollen die IT-Sicherheitsmaßnahmen vermittelt werden, die inhärent mit einem Softwareprodukt verbunden sind und bereits im Lieferumfang enthalten sind. Dies können neben Passwörtern zur Anmeldung, der Pausenschaltung durch Bildschirmschoner auch Möglichkeiten der Verschlüsselung von Dokumenten oder Datenfeldern sein. Hinweise und Empfehlungen über die Strukturierung und Organisation von Dateien, die anwendungsspezifische Daten enthalten, können die Vergabe von Zugriffsrechten erleichtern und den Aufwand für die Datensicherung deutlich reduzieren.
  • Das Verhalten bei Auftreten eines Schadprogramms auf einem PC
    Hier soll den MitarbeiterInnen vermittelt werden, wie mit Viren umzugehen ist. Mögliche Inhalte dieser Schulung sind (siehe 10.4 Schutz vor Schadprogrammen und Schadfunktionen):
    • Wirkungsweise und Arten von Schadprogrammen
    • Vorbeugende Maßnahmen
    • Erkennen des Schadprogrammbefalls
    • Sofortmaßnahmen im Verdachtsfall
    • Maßnahmen zur Eliminierung des Schadprogrammes
  • Der richtige Einsatz von Zugangscodes und Zugangskontrollmedien
    Hierbei sollen die Bedeutung von Zugangscodes (Passwörtern, PINs, Zugangscodes für Voicemail etc.) und Zugangskontrollmedien (Karten, Token, Bürgerkarte, …) für die IT-Sicherheit erläutert werden. Ebenso sind die Randbedingungen, die einen wirksamen Einsatz von Zugangscodes und Zugangskontrollmedien erst ermöglichen, herauszuarbeiten (vgl. auch 11.3.1 Regelungen des Passwortgebrauches und 11.6.2 Regelungen des Gebrauchs von Chipkarten).
  • Die Bedeutung der Datensicherung und deren Durchführung
    Die regelmäßige Datensicherung ist eine der wichtigsten IT-Sicherheitsmaßnahmen in jedem IT-System. Vermittelt werden sollen das Datensicherungskonzept (siehe 10.5 Datensicherung) der Organisation und die von jeder/jedem Einzelnen durchzuführenden Datensicherungsaufgaben. Besonders bedeutend ist dies für den PC-Bereich, in dem alle BenutzerInnen selbst die Datensicherung verantwortlich durchführen muss.
  • Der geregelte Ablauf eines Datenträgeraustausches
    Die Festlegung, wann welchen KommunikationspartnerInnen welche Datenträger übermittelt werden dürfen, ist allen Beteiligten bekannt zu geben. Werden bestimmte IT-gestützte Verfahren zum Schutz der Daten während des Austausches eingesetzt (wie etwa Verschlüsselung, digitale Signaturen oder Checksummenverfahren), so sind die MitarbeiterInnen in die Handhabung dieser Verfahren ausreichend einzuarbeiten.
  • Der Umgang mit personenbezogenen Daten
    An den Umgang mit personenbezogenen Daten sind besondere Anforderungen zu stellen. MitarbeiterInnen, die mit personenbezogenen Daten (sowohl in IT-Systemen als auch in Akten) arbeiten müssen, sind für die gesetzlich erforderlichen Sicherheitsmaßnahmen zu schulen. Dies betrifft etwa Meldepflichten, den Umgang mit den Rechten von Betroffenen (Auskunft, Richtigstellung, Löschung, Widerspruch, …), Datensicherheitsmaßnahmen sowie Übermittlung und Überlassung von Daten.
  • Die Einweisung in Notfallmaßnahmen
    Sämtliche MitarbeiterInnen (auch nicht unmittelbar mit IT befasste Personen wie Portier oder Wachpersonal) sind in bestehende Notfallmaßnahmen einzuweisen. Dazu gehören die Erläuterung der Fluchtwege, die Verhaltensweisen bei Feuer, der Umgang mit Feuerlöschern, das Notfallmeldesystem (wer als Erstes wie zu benachrichtigen ist) und der Umgang mit dem Disaster Recovery-Handbuch.
  • Richtiges Verhalten bei Auftreten von Sicherheitsproblemen (IHP)
    Die in den Incident Handling-Plänen (IHPs) festgelegten Aufgaben und Verantwortlichkeiten aller MitarbeiterInnen bei Auftreten sicherheitsrelevanter Ereignisse sind allen betroffenen MitarbeiterInnen bekannt zu machen, regelmäßige Schulungen und gegebenenfalls praktische Übungen sind vorzusehen (vgl. auch 8.3.5 Aktionen bei Auftreten von Sicherheitsproblemen (Incident Handling-Pläne))
  • Vorbeugung gegen „Social Engineering“
    Die MitarbeiterInnen sollen auf die Gefahren des „Social Engineerings“ hingewiesen werden. Die typischen Muster solcher Versuche, über gezieltes Aushorchen an vertrauliche Informationen zu gelangen, ebenso wie die Methoden, sich dagegen zu schützen, sollten bekannt gegeben werden. Da „Social Engineering“ oft mit der Vorspiegelung einer falschen Identität einhergeht, sollten MitarbeiterInnen regelmäßig darauf hingewiesen werden, die Identität von GesprächspartnerInnen zu überprüfen und insbesondere am Telefon keine vertraulichen Informationen weiterzugeben.

8.3.4 Betreuung und Beratung von IT-BenutzerInnen

ISO Bezug: 27002 8.2.2
Neben der Schulung, die die IT-BenutzerInnen in die Lage versetzt, die vorhandene Informationstechnik sachgerecht einzusetzen, bedarf es einer Betreuung und Beratung der IT-BenutzerInnen für die im laufenden Betrieb auftretenden Probleme. Diese Probleme können aus Hardwaredefekten, fehlerhaften Softwareinstallationen, aber auch aus Bedienungsfehlern resultieren.
In größeren Behörden bzw. Unternehmen kann es daher sinnvoll sein, eine zentrale Stelle mit der Betreuung der IT-BenutzerInnen zu beauftragen und diese allen MitarbeiterInnen bekannt zu geben („Helpdesk“). Dabei hat sich die Wahl einer besonders leicht zu merkenden Telefonnummer besonders bewährt. Die Einrichtung eines Helpdesk kann sich insbesondere bei einer hohen Zahl dezentraler Systeme wie PCs als vorteilhaft erweisen.
Es muss für alle BenutzerInnen klar ersichtlich sein, an wen sie sich in Problemfällen zu wenden haben.

8.3.5 Aktionen bei Auftreten von Sicherheitsproblemen (Incident Handling-Pläne)

ISO Bezug: 27002 8.2.1
Die Aufgaben und Verantwortlichkeiten aller MitarbeiterInnen bei Auftreten von sicherheitsrelevanten Ereignissen sollten im Rahmen der organisationsweiten IT-Sicherheitspolitik (High-Level-Beschreibung) sowie spezieller „Incident Handling-Pläne“ (IHPs) sowohl für einzelne Bereiche als auch für die gesamte Organisation festgelegt werden (vgl. dazu auch 13.1.3 Erstellung eines Incident Handling-Plans und Richtlinien zur Behandlung von Sicherheitsvorfällen).
Unter sicherheitsrelevanten Ereignissen sind dabei zu verstehen:
  • Angriffe und (vermutete) Angriffsversuche gegen ein IT-System
  • (vermutete) Sicherheitsschwächen
  • Funktionsstörungen von Systemen (etwa durch maliziöse Software)
Incident Handling-Pläne sollen in schriftlicher Form und verbindlich festlegen:
  • wie auf sicherheitsrelevante Ereignisse zu reagieren ist,
  • die Verantwortlichkeiten für die Meldung bzw. Untersuchung sicherheitsrelevanter Vorfälle,
  • die einzuhaltenden Meldewege,
  • die Protokollierung und Dokumentation sicherheitsrelevanter Vorfälle sowie
  • die Ausbildung von Personen, die sicherheitsrelevante Vorfälle behandeln bzw. Gegenmaßnahmen treffen müssen.
IHPs sind allen betroffenen MitarbeiterInnen bekannt zu machen.

8.3.6 Schulung des Wartungs- und Administrationspersonals

ISO Bezug: 27002 8.2.2
Das Wartungs- und Administrationspersonal sollte mindestens so weit geschult werden, dass
  • alltägliche Administrationsarbeiten selbst durchgeführt,
  • einfache Fehler selbst erkannt und behoben,
  • Datensicherungen selbsttätig durchgeführt,
  • Tätigkeiten im Normalbetrieb bis zur Erkennung von Problemen eigenhändig durchgeführt,
  • die Eingriffe von externem Wartungspersonal nachvollzogen und
  • Manipulationsversuche oder unbefugte Zugriffe auf die Systeme erkannt
werden können.

8.3.7 Einweisung in die Regelungen der Handhabung von Kommunikationsmedien

ISO Bezug: 27002 8.2.2
Der Einsatz neuer Medien und Geräte - dazu zählen Fax und Router genauso wie etwa Anrufbeantworter und Voice Mail - erleichtert die Kommunikation, bringt aber auch neue potenzielle Gefährdungen der Vertraulichkeit und Integrität von Informationen mit sich. Alle MitarbeiterInnen sind daher auf die Besonderheiten der Handhabung von solchen Geräten hinzuweisen und für potenzielle Gefahren zu sensibilisieren.
Verständliche Bedienungsanleitungen, Sicherheitshinweise und ggf. auch Dienstanweisungen sind den MitarbeiterInnen zur Kenntnis zu bringen und verfügbar zu halten.
Im Folgenden werden einige Beispiele angeführt, was solche Regelungen umfassen sollten. Sie sind den jeweiligen technischen Anforderungen und Möglichkeiten anzupassen.

Fax (Stand-alone-Gerät)

  • Festlegung von Fax-Verantwortlichen, die für die Verteilung eingehender Fax-Sendungen zuständig sind und als AnsprechpartnerInnen in Fax-Problemfällen fungieren,
  • Festlegung, wer das Faxgerät benutzen darf,
  • Verbot des Versendens von vertraulichen Informationen per Fax (oder besondere technische und organisatorische Vorkehrungen für diesen Fall, wie etwa telefonische Ankündigung eines derartigen Fax),
  • Verwendung einheitlicher Fax-Deckblätter,
  • ggf. Kontrolle von Einzelsendenachweisen.

Fernzugänge

  • Information über mögliche Gefährdungen, einzuhaltende Sicherheitsmaßnahmen und Regelungen beim Betrieb eines Modems oder Routers,
  • Auswirkungen verschiedener Konfigurationen auf die Betriebssicherheit des Modems oder Routers.

Anrufbeantworter

  • Regelung über den Einsatz von Sicherungscodes für die Fernabfrage
  • Vermeidung schutzbedürftiger Informationen auf Anrufbeantwortern,
  • Regelmäßiges Abhören und Löschen aufgezeichneter Gespräche,
  • Abschalten nicht benötigter Leistungsmerkmale.

8.3.8 Einweisung in die Bedienung von Schutzschränken

ISO Bezug: 27002 8.3.3
Nach der Beschaffung eines Schutzschrankes (Serverschrank oder Datensicherungsschrank - vgl. auch 9.5.7 Beschaffung und Einsatz geeigneter Schutzschränke) sind die BenutzerInnen in die korrekte Bedienung einzuweisen. Dies sollte auch bei Neuübertragung einer Aufgabe erfolgen, die die Nutzung eines Schutzschrankes umfasst.
Beispiele für zu vermittelnde Punkte sind:
  • Korrekter Umgang mit dem Schloss des Schutzschrankes: Dabei ist auf typische Fehler hinzuweisen, wie zum Beispiel das Nichtverwerfen von Codeschlössern. Die Regelungen zur Schlüsselverwaltung, Schlüsselhinterlegung und Vertretungsregelung sind aufzuzeigen. Insbesondere ist einzufordern, dass der Schutzschrank bei - auch nur kurzfristiger - Nichtbenutzung verschlossen wird.
  • Im Falle eines Serverschrankes ist darauf hinzuweisen, dass unnötige brennbare Materialien (Ausdrucke, überzählige Handbücher, Druckerpapier) nicht im Serverschrank aufbewahrt werden sollen.
  • Datensicherungsträger des Servers sollten in einem anderen Brandabschnitt bzw. bei Bedarf disloziert gelagert werden. Eine Aufbewahrung im Serverschrank ist daher ungeeignet und nur dann zulässig, wenn eine Kopie der Datensicherungsbestände in einem anderen Brandabschnitt bzw. disloziert ausgelagert ist.
  • Wird ein klimatisierter Serverschrank eingesetzt, sollten dessen Öffnungszeiten minimiert werden. Gegebenenfalls ist sporadisch zu kontrollieren, ob im Serverschrank Wasser kondensiert ist.

9 Physische und umgebungsbezogene Sicherheit

Dieses Kapitel nimmt Bezug auf ISO/IEC 27002 9 „Physische und umgebungsbezogene Sicherheit“.
Die in diesem Abschnitt beschriebenen Maßnahmen dienen dem Schutz von Informationssystemen mittels baulichen und infrastrukturellen Vorkehrungen. Dabei sind verschiedene Schutzebenen zu betrachten, wie etwa Grundstücke, Gebäude oder Räume (Büros, Serverräume, Datenträgerarchiv, Räume für technische Infrastruktur, …).
Die nachfolgenden Fragen können bei der Beurteilung der baulichen und infrastrukturellen Sicherheit hilfreich sein:
  • Lage des Gebäudes: Befindet es sich auf einem eigenen gesicherten Grundstück? Wie sind die benachbarten öffentlichen Verkehrsflächen beschaffen?
  • Steht das Gebäude der betreffenden Organisation zur Alleinbenutzung zur Verfügung oder gibt es andere Mitbenutzer; wenn ja, welche?
  • Wer hat Zutritt zum Gebäude?
  • Gibt es eine physische Zutrittskontrolle? Ist ein Portierdienst eingerichtet?
  • Stärke und Schutz/Überwachung von Wänden, Türen, Fenstern, Lüftungsschächten etc.
  • Infrastruktur (Wasser-, Stromversorgung, Kommunikationsverbindungen, Klimaanlage, USV, …)
  • Welche Bereiche des Grundstückes bzw. des Gebäudes sind sicherheitsrelevant?
Im Folgenden werden eine Reihe von grundlegenden Sicherheitsmaßnahmen angeführt. Welche davon in einem konkreten Fall zum Einsatz kommen, ist abhängig von Größe und Schutzbedarf der Organisation. Nach Möglichkeit sollten bauliche und infrastrukturelle Maßnahmen bereits in der Planungs- bzw. Bauphase Berücksichtigung finden, ein nachträglicher Einbau ist meist teuer oder gar unmöglich.
Weiters ist zu beachten, dass die Bedingungen bzw. Auflagen von etwaigen Versicherungen eingehalten werden.
Wo sinnvoll bzw. hilfreich werden in den nachfolgenden Maßnahmenbeschreibungen Normen beispielhaft herausgegriffen und angeführt. Dabei handelt es sich nicht um eine vollständige Aufzählung aller für einen Bereich relevanten Normen und auch nicht um verbindliche Einsatzempfehlungen, die angeführten Beispiele sollen lediglich einen Hinweis auf existierende, möglicherweise zur Anwendung kommende Normen geben und ein detailliertes Einarbeiten in die Materie erleichtern.

9.1 Bauliche und infrastrukturelle Maßnahmen

9.1.1 Geeignete Standortauswahl

ISO Bezug: 27002
Bei der Planung des Standortes, an dem ein Gebäude angemietet werden oder entstehen soll, empfiehlt es sich, neben den üblichen Aspekten wie Raumbedarf und Kosten auch Umfeldge­gebenheiten, die Einfluss auf die Informationssicherheit haben, zu berücksichtigen:
  • In Zusammenhang mit Schwächen in der Bausubstanz kann es durch Erschütterungen naher Verkehrswege (Straße, Eisenbahn, U-Bahn) zu Beeinträchtigungen der IT kommen. Gebäude, die direkt an Hauptverkehrstrassen (Autobahn, Bundesstraße, Bahn, …) liegen, können durch Unfälle beschädigt werden, für Gebäude in Einflugschneisen von Flughäfen besteht Gefahr durch einen eventuellen Flugzeugabsturz.
  • Die Nähe zu optimalen Verkehrswegen wird in vielen Fällen als Vorteil angesehen werden, kann aber - da diese Verkehrswege auch potenzielle Fluchtwege darstellen können - unter Umständen auch die Durchführung eines Anschlages erleichtern. Vor- und Nachteile sind entsprechend abzuwägen.
  • In der Nähe von Sendeeinrichtungen kann es zu Störungen der IT kommen.
  • Bei Überbauten von U-, S- oder Eisenbahnen kann es zu Störungen von Datenleitungen und CRT-Bildschirmen (Cathode Ray Tube) kommen.
  • In der Nähe von Gewässern und in Niederungen ist mit Hochwasser zu rechnen.
  • In der Nähe von Kraftwerken oder Fabriken kann durch Unfälle oder Betriebsstörungen (Explosion, Austritt schädlicher Stoffe) die Verfügbarkeit des Gebäudes (z. B. durch Evakuierung oder großräumige Absperrung) beeinträchtigt werden.
  • Streunende Haustiere können Fehlalarme von Bewegungsmeldern verursachen und Personen gefährden.

9.1.2 Anordnung schützenswerter Gebäudeteile

Schützenswerte Räume oder Gebäudeteile sollten nicht in exponierten oder besonders gefährdeten Bereichen untergebracht sein. Insbesondere ist zu beachten:
  • Kellerräume sind durch Wasser gefährdet.
  • Räume im Erdgeschoss - zu öffentlichen Verkehrsflächen hin - sind durch Anschlag, Vandalismus und höhere Gewalt (Verkehrsunfälle in Gebäudenähe) gefährdet.
  • Räume im Erdgeschoss mit schlecht einsehbaren Höfen sind durch Einbruch und Sabotage gefährdet.
  • Räume unterhalb von Flachdächern sind durch eindringendes Regenwasser gefährdet.
Als Faustregel kann man sagen, dass schutzbedürftige Räume oder Bereiche im Zentrum eines Gebäudes besser untergebracht sind als in dessen Außenbereichen.
Optimal ist es, diese Aspekte schon in die Bauplanung für ein neues Gebäude oder in die Raumbelegungsplanung bei Einzug in ein bestehendes einzubeziehen.
Besteht die Möglichkeit, auch das Umfeld des Gebäudes in das Sicherheitskonzept einzubeziehen (etwa bei einer eigenen, ausschließlich der betreffenden Organisation gehörigen Liegenschaft), so können zusätzliche bauliche und technische Sicherheitsmaßnahmen getroffen werden („Perimeterschutz“, „Freilandschutz“). Dazu zählen etwa:
  • Zäune und Mauern
  • Tore, Schranken und Fahrzeugsperren
  • Kameraüberwachung und Bewegungsmelder

9.1.3 Einbruchsschutz

ISO Bezug: 27002
Die gängigen Maßnahmen zum Einbruchsschutz sollten den örtlichen Gegebenheiten entsprechend angepasst werden.
Dazu gehören:
  • Sicherungen bei einstiegsgefährdeten Türen oder Fenstern,
  • besondere Schließzylinder, Zusatzschlösser und Riegel,
  • Sicherung von Kellerlichtschächten,
  • Verschluss von nichtbenutzten Nebeneingängen,
  • einbruchgesicherte Notausgänge,
  • Verschluss von Personen- und Lastenaufzügen außerhalb der Dienstzeit.
Den MitarbeiterInnen ist durch Regelungen bekannt zu geben, welche Maßnahmen zum Einbruchsschutz beachtet werden müssen.
In C.1 Wichtige Normen sind relevante ÖNORMEN zum Einbruchsschutz angeführt.

9.1.4 Zutrittskontrolle

Die Überwachung des Zutritts zu Gebäuden, Rechenzentren und sicherheitssensiblen Geräten zählt zu den wichtigsten physischen Schutzmaßnahmen. Ein Zutrittskontrollsystem vereinigt verschiedene bauliche, organisatorische und personelle Maßnahmen.
Das Zutrittskontrollkonzept legt die generellen Richtlinien für den Perimeter-, Gebäude- und Geräteschutz fest. Dazu gehören:
  • Festlegung der Sicherheitszonen:
    Zu schützende Bereiche können etwa Grundstücke, Gebäude, Rechnerräume, Räume mit Peripheriegeräten (Drucker, …), Archive, Kommunikationseinrichtungen und die Haustechnik sein. Die einzelnen Bereiche können unterschiedliche Sicherheitsstufen aufweisen.
  • Generelle Festlegung der Zutrittskontrollpolitik:
    Hier wird grundsätzlich festgelegt, welche Personengruppen (etwa RZ-MitarbeiterInnen, OperatorInnen, FachabteilungsmitarbeiterInnen, KundInnen, Angehörige von Lieferfirmen etc.) Zutritt zu welchen Bereichen benötigen. Um die Zahl der zutrittsberechtigten Personen zu einem Raum möglichst gering zu halten, sollte auch beim IT-Einsatz der Grundsatz der Funktionstrennung berücksichtigt werden. So verhindert beispielsweise eine getrennte Lagerung von Ersatzteilen für IT-Systeme und Datenträgern den unerlaubten Zugriff von WartungstechnikerInnen auf die Datenträger.
  • Bestimmung einer/eines Verantwortlichen für Zutrittskontrolle:
    Diese/r vergibt die Zutrittsberechtigungen an die einzelnen Personen entsprechend den in der Sicherheitspolitik festgelegten Grundsätzen.
  • Dokumentation der Vergabe und Rücknahme von Zutrittsberechtigungen
  • Definition von Zeitabhängigkeiten:
    Es ist zu klären, ob zeitliche Beschränkungen der Zutrittsrechte erforderlich sind. Solche Zeitabhängigkeiten können etwa sein: Zutritt nur während der Arbeitszeit oder befristeter Zutritt bis zu einem fixierten Datum.
  • Festlegung der Zutrittskontrollmedien:
    Es ist festzulegen, ob die Identifikation bzw. die Authentisierung durch Überwachungspersonal (persönlich oder mittels Überwachungskameras) oder durch automatische Identifikations- und Authentisierungssysteme wie Zugangscodes (Passwörter, PINs), Karten oder biometrische Methoden erfolgen soll.
  • Festlegung der Rechteprüfung:
    Im Zutrittskontrollkonzept ist festzulegen, wo, zu welchen Zeiten und unter welchen Randbedingungen eine Rechteprüfung erfolgen muss, sowie welche Aktionen bei versuchtem unerlaubten Zutritt zu setzen sind.
  • Festlegung der Beweissicherung:
    Hier ist zu bestimmen, welche Daten bei Zutritt zu und Verlassen von einem geschützten Bereich protokolliert werden. Dabei bedarf es einer sorgfältigen Abwägung zwischen den Sicherheitsinteressen des Systembetreibers und den Schutzinteressen der Privatsphäre der/des Einzelnen.
  • Behandlung von Ausnahmesituationen:
    Es ist u. a. sicherzustellen, dass im Brandfall die MitarbeiterInnen schnellstmöglich die gefährdeten Zonen verlassen können.
Weiters sind folgende Fragen zu klären:
  • Sind beim Betreten oder Verlassen eines geschützten Bereiches Vereinzelungsmechanismen (Drehtüren, Schleusen, …) notwendig?
  • Welche Maßnahmen sind bei unautorisierten Zutrittsversuchen zu setzen?
  • Ist eine Nullsummenprüfung (Anmerkung - Nullsummenprüfung: Feststellung der Anzahl der im geschützten Bereich befindlichen Personen durch Vergleich der Zu- und Abgänge. Voraussetzung für eine Nullsummenprüfung ist die Installation von Vereinzelungsmechanismen) erforderlich?
  • Ist das Auslösen eines „stillen Alarms“ vorzusehen? Durch Eingabe einer vereinbarten Kennung, etwa einer zusätzlichen Ziffer zur üblichen PIN, wird ein Alarm an einer entfernten Überwachungsstelle (Portier, Polizei) ausgelöst. Eine solche Maßnahme bietet Schutz gegen jemanden, der den Zugang zu geschützten Bereichen gewaltsam erzwingen will.
  • Sperrmöglichkeiten bei Verlust oder Duplizierung des Zutrittskontrollmediums (Schlüssel, Karte, …) und bei Austritt von MitarbeiterInnen.
  • Stehen die Kosten für die Installation, den laufenden Betrieb, die Wartung und die regelmäßige Revision des Zutrittskontrollsystems in vertretbarer Relation zum möglichen Sicherheitsrisiko?
  • Ist die Kapazität des Zutrittskontrollsystems der Größe der Organisation angepasst? Insbesondere ist eine ausreichende Zahl von Kontrollstellen und eventuellen Vereinzelungsmechanismen vorzusehen, um Warteschlangen auch zu Stoßzeiten (Arbeitsbeginn, …) zu vermeiden.
Das Zutrittskontrollkonzept sollte bereits vor der Systemauswahl so detailliert wie möglich feststehen und weitgehend stabil bleiben. Überarbeitungen werden jedoch notwendig, bei
  • Feststellung von Sicherheitsmängeln
  • Erweiterungen des sicherheitsrelevanten Bereiches
  • schlechter Benutzerakzeptanz:
    Die Akzeptanz durch die BenutzerInnen ist ein entscheidendes Kriterium. Mängel im Zutrittskontrollsystem (häufige Fehlalarme, Ausfälle, Wartezeiten, zu restriktive Handhabung, überflüssige bürokratische Abläufe) können dazu führen, dass auch grundsätzlich sicherheitsbewusste Mitarbeiter bereit sind, die Regeln zu verletzen.
Mit der Standard- und Muster-Verordnung 2000 wurde eine neue Musteranwendung „MA002 Zutrittskontrollsysteme“ geschaffen (siehe B.2 Musteranwendung MA002 Zutrittskontrollsysteme), die die Meldung beim Datenverarbeitungsregister erleichtert und daher für die AnwenderInnen hilfreich sein kann.

9.1.5 Verwaltung von Zutrittskontrollmedien

ISO Bezug: 27002
Für alle Schlüssel eines Gebäudes ist ein Schließplan zu fertigen. Die Herstellung, Aufbewahrung, Verwaltung und Ausgabe von Schlüsseln ist zentral zu regeln. Reserveschlüssel sind vorzuhalten und gesichert aufzubewahren.
Zu beachten ist:
  • Ist eine Schließanlage vorhanden, so sind für schutzbedürftige Bereiche eigene Schließgruppen zu bilden, ggf. einzelne Räume aus der Schließgruppe herauszunehmen und mit Einzelschließung zu versehen.
  • Nicht ausgegebene Schlüssel und die Reserveschlüssel sind gegen unbefugten Zugriff geschützt aufzubewahren.
  • Die Ausgabe der Schlüssel erfolgt gegen Quittung und ist zu dokumentieren.
  • Es sind Vorkehrungen zu treffen, wie bei Verlust einzelner Schlüssel zu reagieren ist (Meldung, Ersatz, Kostenerstattung, Austausch des Schlosses, Austausch von Schließgruppen etc.).
  • Bei Zuständigkeitsänderungen von MitarbeiterInnen sind deren Schließberechtigungen zu prüfen und Schlüssel gegebenenfalls einzuziehen.
  • Beim Ausscheiden von MitarbeiterInnen sind alle Schlüssel einzuziehen (Aufnahme der Schlüsselverwaltung in den Laufzettel).
  • Schlösser und Schlüssel zu besonders schutzbedürftigen Bereichen (zu denen nur sehr wenige Schlüssel ausgegeben werden sollten) können bei Bedarf getauscht werden, um so illegal nachgefertigten Schlüsseln die Funktion zu nehmen.
  • Abhängig von der Sensibilität des zu schützenden Bereiches können auch gesperrte Schließsysteme zum Einsatz kommen, die die Anfertigung eines Schlüssels nur unter Vorliegen definierter Bedingungen (etwa schriftliche Zustimmung einer/eines Verantwortlichen) erlauben.
Das Gleiche gilt sinngemäß auch für alle anderen Zutrittskontrollmedien wie Magnetstreifen- oder Chipkarten, bzw. so genannte Multifunktionschipkarten.

9.1.6 Portierdienst

ISO Bezug: 27002
Die Einrichtung eines Portierdienstes hat weit reichende positive Auswirkungen gegen eine ganze Reihe von Gefährdungen.
Voraussetzung ist allerdings, dass bei der Durchführung des Portierdienstes einige Grundprinzipien beachtet werden.
  • Der Portier beobachtet bzw. kontrolliert alle Personenbewegungen am Eingang zum Gebäude bzw. sicherheitsrelevanten Bereich.
  • Unbekannte Personen haben sich beim Portier zu legitimieren.
  • Der Portier hält vor Einlassgewährung von BesucherInnen bei den Besuchten Rückfrage.
  • Die BesucherInnen werden zu den Besuchten begleitet oder am Eingang abgeholt.
  • Dem Portier müssen die MitarbeiterInnen bekannt sein. Scheiden MitarbeiterInnen aus, ist auch der Portier zu unterrichten, ab wann diesen MitarbeiterInnen der Einlass zu verwehren ist.
  • Abhängig von der Sensibilität des Bereiches sind die Führung eines Besucherbuches, in dem der Zutritt von Fremdpersonen zum Gebäude dokumentiert werden kann, sowie die Ausgabe von Besucherausweisen oder Besucherbegleitscheinen zu erwägen.
Die Aufgabenbeschreibung muss verbindlich festschreiben, welche Aufgaben dem Portier im Zusammenspiel mit weiteren Schutzmaßnahmen zukommen (z. B. Gebäudesicherung nach Dienst- oder Geschäftsschluss, Scharfschaltung der Alarmanlage, Kontrolle der Außentüren und Fenster).

9.1.7 Einrichtung einer Postübernahmestelle

ISO Bezug: 27002
Die Übernahme von Briefen und Paketen sollte durch eine zentrale Stelle unter Beachtung von für die betreffende Organisation adäquaten Sicherheitsregeln erfolgen.
Solche Regeln können etwa sein:
  • Pakete, die von einem Botendienst o.ä. gebracht werden, dürfen erst nach Rücksprache mit den namentlich angeführten EmpfängerInnen oder berechtigten VertreterInnen übernommen werden.
  • Pakete, die ohne namentlich angeführte EmpfängerInnen an die Organisation adressiert sind und von einem Paket- oder Botendienst bzw. von einer Privatperson gebracht werden, sind nicht zu übernehmen.
  • Wird außerhalb der Amts- bzw. Bürostunden ein Brief oder ein Paket abgegeben, so ist von der Dienst habenden Mitarbeiterin bzw. vom Dienst habenden Mitarbeiter (z. B. Portier, Operator, …) bei den EmpfängerInnen rückzufragen, ob eine Sendung erwartet wird. Ist dies nicht der Fall oder sind die EmpfängerInnen nicht erreichbar, so ist die Sendung nicht anzunehmen.
  • Für größere Organisationseinheiten ist die Beschaffung von Geräten zum Durchleuchten von Postsendungen zu erwägen.

9.1.8 Perimeterschutz

ISO Bezug: 27002
Sofern es die Gegebenheiten und die Infrastruktur zulassen, sollten bereits auf dem Grundstück der Organisation zusätzliche Sicherheitseinrichtungen installiert werden, um äußeren Gefährdungen entgegenzuwirken.
Je nach Art und Topologie der Infrastruktur bzw. des Grundstückes können folgende Vorkehrungen sinnvoll sein:
  • Einfriedung des Grundstückes
    z. B. Zaunanlage, Schutzmauer
  • Freiland Sicherungsmaßnahmen
    z. B. entsprechende Geländegestaltung, geeignete Beleuchtung, Detektionssensorik, Schutz durch Bewachungsunternehmen
  • äußere Zutrittskontrollmechanismen
    z. B. Videoüberwachung, Personen- oder Fahrzeugschleusen
Entscheidend ist, dass der Perimeterschutz in ein stimmiges Gesamtschutzkonzept eingebettet ist, in dem die Verhältnismäßigkeiten der einzelnen Schutzmaßnahmen aufeinander abgestimmt sind.

9.2 Brandschutz

Brandschutz stellt die Gesamtheit aller Maßnahmen dar, die die Entstehung und Ausbreitung von Bränden verhindern und die Bekämpfung von Bränden gewährleisten.
Grundsätzlich ist davon auszugehen, dass die ArbeitgeberInnen und ArbeitnehmerInnen alle Maßnahmen zu ergreifen haben, um das Risiko einer Brandentstehung zu minimieren.

9.2.1 Einhaltung von Brandschutzvorschriften und Auflagen

Die gesetzlichen Brandschutzvorschriften und die Auflagen der zuständigen Baubehörde sowie der örtlichen Feuerwehr sind unbedingt einzuhalten.
Brandverhütungsstellen oder BrandschutzexpertInnen können und sollen bei der Brandschutzplanung hinzugezogen werden.
In C.1 Wichtige Normen sind eine Reihe von wichtigen Normen zum Thema Brandschutz angeführt.
Ebenso ist es notwendig, die allgemeinen und speziellen Bestimmungen des Arbeitnehmerschutzes und die Arbeitsstättenverordnung bei der Errichtung und beim Betrieb zu beachten, insbesondere
und die dazu ergangenen Verordnungen.
Es ist empfehlenswert, weitere Hinweise zum Brandschutz zu beachten, wie sie zum Beispiel in den Publikationen des Verbands der Schadensversicherer (VdS) in Deutschland zu finden sind (Adresse siehe F Wichtige Adressen).

9.2.2 Raumbelegung unter Berücksichtigung von Brandlasten

Eine Brandlast entsteht durch alle brennbaren Stoffe, die ins Gebäude eingebracht werden. Sie ist von der Menge und vom Heizwert der Stoffe abhängig. IT-Geräte und Leitungen stellen ebenso eine Brandlast dar wie Möbel, Fußbodenbeläge, Gardinen und dergleichen.
Bei der Unterbringung von IT-Geräten, Datenträgern etc. sollte eine vorherige Beachtung der vorhandenen Brandlasten im selben Raum und in den benachbarten Räumen erfolgen. So sollte etwa das Datenträgerarchiv nicht in der Nähe von oder über einem Papierlager oder Räumen mit erhöhter Brandlast untergebracht sein.

9.2.3 Organisation Brandschutz

Brandschutz umfasst sowohl präventive Maßnahmen, die die Möglichkeit einer Brandentstehung minimieren sollen, als auch Maßnahmen zur Brandbekämpfung und Evakuierung.
Präventive Maßnahmen
können sowohl technischer (z. B. Ersatz leicht entzündlicher Arbeitsstoffe) als auch organisatorischer Natur sein.
Organisatorische Maßnahmen
umfassen personenbezogene Unterweisungen (keine Zigaretten in den Papierkorb, keine Verwendung von Heizstrahlern, Ausschalten von Kaffeemaschinen bei Dienstende, …) sowie die Erstellung einer Brandschutzordnung.
Die Brandschutzordnung ist im Falle von erhöhtem Brandschutz zu erstellen und umfasst die zur Brandverhütung erforderlichen technischen und organisatorischen Vorkehrungen und Maßnahmen. Sie ist allen Bediensteten jährlich einmal nachweislich zur Kenntnis zu bringen.
Maßnahmen zur Brandbekämpfung und Evakuierung beinhalten u. a.
  • die Bestellung von Brandschutzbeauftragten,
  • die Unterweisung der ArbeitnehmerInnen über die Verwendung der Feuerlöscheinrichtungen,
  • die Ausarbeitung eines Evakuierungsplanes und
  • regelmäßige Brandschutzübungen

9.2.4 Brandabschottung von Trassen

Bei Gebäuden mit mehreren Brandabschnitten lässt es sich kaum vermeiden, dass Trassen durch Brandwände und Decken führen. Die Durchbrüche sind nach Verlegung der Leitungen entsprechend dem Brandwiderstandswert der Wand bzw. Decke zu schotten (wieder zu verschließen). Um die Nachinstallation zu erleichtern, können geeignete Materialien verwendet werden. Entsprechende Richtlinien und Normen (etwa ÖNORM B 3836 und B 3850, siehe A.1 Sicherheitsszenarien) sind dabei zu beachten.
Brandabschottungen sind bautechnische Maßnahmen, die einen Durchbruch durch einen Brandabschnitt über eine bestimmte Zeitdauer gegen Durchtritt eines Brandes abdichten (z. B. bei Leitungs- oder Kabeldurchführungen).
Es sind hier verschiedene Systeme wie z. B. Brandschutzziegel, Brandschutzkissen oder Spachtelmassen am Markt. Wichtig ist neben einer Zulassung des Systems auch eine genaue Einhaltung der Verarbeitungsanleitungen.
Die Nichtabschottung von nachträglichen Verkabelungen ist ein immer wieder anzutreffender Schwachpunkt im baulichen Brandschutz.
Die angeführten Themenbereiche finden u. a. in den jeweiligen Bauordnungen der Länder, den Arbeitnehmerschutzvorschriften und in den behördlichen Vorschreibungen und Genehmigungen ihren Niederschlag.
Bei der Trassenplanung sollte die für den Brandschutz verantwortliche Person hinzugezogen werden.

9.2.5 Verwendung von Brandschutztüren und Sicherheitstüren

Brandschutztüren sind Brandschutzabschlüsse, welche hinsichtlich ihrer Brandwiderstandsdauer der ÖNORM B 3850 entsprechen müssen.
Im Regelfall ist bei der Bildung eines Brandabschnittes bezüglich der Tür eine geringere Brandwiderstandsklasse gefordert als bei der Brandwand (meistens F90 für Wände und T30 für Türen).
Brandschutztüren auf Verkehrswegen sind bei Vorhandensein einer Brandmeldeanlage an diese anzuschließen, um ein Aufkeilen zu verhindern. Ansonsten sollten bei solchen Türen Feststellanlagen mit oder ohne eigene Branderkennung (Brandmelder) installiert werden.
Sicherheitstüren, wie z. B. Stahlblechtüren, bieten gegenüber normalen Bürotüren Vorteile:
  • Sicherheitstüren (einbruchhemmende Türen) bieten aufgrund ihrer Stabilität einen höheren Schutz gegen Einbruch (z. B. bei Keller- und Lieferanteneingängen).
  • Brandschutztüren verzögern die Ausbreitung eines Brandes.
Wichtige ÖNORMEN dazu werden in C.1 Wichtige Normen angeführt.
Der Einsatz von Sicherheitstüren ist über den von der Feuerwehr vorgeschriebenen Bereich hinaus (vgl. 9.2.1 Einhaltung von Brandschutzvorschriften und Auflagen) besonders bei schutzbedürftigen Räumen wie Serverraum, Beleg- oder Datenträgerarchiv vorzusehen.
Es ist dafür zu sorgen, dass Brand- und Rauchschutztüren auch tatsächlich geschlossen und nicht (unzulässigerweise) z. B. durch Keile offen gehalten werden. Alternativ können Türen mit Anschluss an die Brandmeldeanlage und einem automatischen Schließmechanismus, der im Alarmfall aktiviert wird, eingesetzt werden.

9.2.6 Brandmeldeanlagen

Brandmeldeanlagen (BMA) dienen zur Überwachung eines bestimmten, besonders gefährdeten Bereiches oder eines gesamten Gebäudes. Derartige Brandmeldeanlagen können mit einer TUS-Leitung (Tonfrequentes Übertragungssystem) direkt mit der Feuerwehr verbunden sein oder intern auf einer kompetenten, ständig besetzten Stelle auflaufen.
Entsprechend den Anschlussbedingungen müssen alle neuen Brandmeldeanlagen über eine Interventionsschaltung verfügen, was bedeutet, dass nach dem ersten Brandalarm 3 bis 6 Minuten Zeit verbleiben um die Meldung zu überprüfen. Wird diese Brandmeldung in der vorgesehenen Zeit nicht quittiert, bzw. gelangen während der Überprüfungszeit eine oder mehrere weitere Meldungen zur Brandmeldeanlage, werden diese sofort an die Feuerwehr weitergeleitet.
Bereits in Betrieb befindliche Brandmeldeanlagen mit einem TUS-Anschluss müssen, je nach Größe des Überwachungsbereiches, umgebaut werden und eine Interventionsschaltung aufweisen.
Derartige Anlagen werden von der Behörde vorgeschrieben und sind nach der TRVB S 123 (Brandmeldeanlagen) und TRVB S 114 (Anschaltebedingungen von Brandmeldeanlagen an öffentliche Feuerwehren) zu errichten. Sie sind jährlich durch eine Wartungsfirma und alle 2 Jahre durch eine autorisierte Prüfstelle zu überprüfen.

9.2.7 Brandmelder

Brandmelder dienen zur Früherkennung von Brandgefahren und werden in automatische und nichtautomatische Melder unterschieden, welche an einer Brandmeldeanlage hängen oder als Einzelmelder fungieren.
Bei automatischen Brandmeldern unterscheidet man:
  • Ionisationsrauchmelder
    Bei Ionisationsrauchmeldern erfolgt die Branderkennung durch die Änderung des Stromflusses in der Ionisationskammer. Dieser Stromfluss wird durch Ionisation der Luft in der Messkammer erzeugt. Dringen nun Rauchpartikel, welche Träger der ionisierten Luftmoleküle sind, in die Kammer ein, ändert sich der Stromfluss.
  • Streulichtmelder
    Die Erkennungsgröße ist bei diesem Melder die Streuung eines definierten Lichtstrahles durch eindringenden Rauch.
  • Wärmemelder (Maximal- oder Differentialmelder)
    Als Kriterium wird entweder eine definierte Maximaltemperatur bzw. ein Temperaturanstieg herangezogen.
  • Flammenmelder
    Bei Flammenmeldern erfolgt die Branderkennung durch die von Bränden ausgehende Strahlung. Sie können auch bei starken Luftbewegungen eingesetzt werden und haben eine große Überwachungsfläche.
Nichtautomatische Brandmelder:
  • Druckknopfmelder
    Durch Drücken des Melders wird die Brandmeldung über die Brandmeldeanlage direkt - ohne Verzögerung - an die Feuerwehr weitergeleitet.
Bei der Auswahl der Brandmelder sind folgende Kriterien zu beachten
  • Art des Brandverlaufes
  • Rauchentwicklung
  • Rascher Temperaturanstieg
  • Täuschungsanfälligkeit (z. B. Teeküchen - Aerosolbildung)
  • Raumhöhen
  • Überwachungsflächen

9.2.8 Handfeuerlöscher (Mittel der Ersten und Erweiterten Löschhilfe)

Die meisten Brände entstehen aus kleinen, anfangs noch gut beherrschbaren Brandherden. Besonders in Büros findet das Feuer reichlich Nahrung und kann sich sehr schnell ausbreiten. Der Sofortbekämpfung von Bränden kommt also ein sehr hoher Stellenwert zu.
Diese Sofortbekämpfung ist nur möglich, wenn entsprechende Handfeuerlöscher in der jeweils geeigneten Brandklasse (ÖNORM EN 2:1993 02 01) in ausreichender Zahl und Größe im Gebäude zur Verfügung stehen. Dabei ist die räumliche Nähe zu schützenswerten Bereichen und Räumen wie Serverraum, Raum mit technischer Infrastruktur oder Belegarchiv anzustreben.
Pulverlöscher mit Eignung für Brandklasse E bis 1000 V sind für elektrisch betriebene Peripheriegeräte geeignet, für elektronisch gesteuerte Geräte, z. B. Rechner, sollten Kohlendioxyd-Löscher (Brandklasse B) zur Verfügung stehen.
Dabei ist zu beachten:
  • Die Feuerlöscher müssen regelmäßig geprüft und gewartet werden.
  • Die Feuerlöscher müssen so angebracht werden, dass sie im Brandfall leicht erreichbar sind.
  • Die Beschäftigten haben sich über die Standorte der nächsten Feuerlöscher zu informieren.
  • Bei entsprechenden Brandschutzübungen sind die MitarbeiterInnen in der Handhabung der Handfeuerlöscher zu unterweisen.

9.2.9 Löschanlagen

Löschanlagen der verschiedensten Ausführungen sind meistens mit einer Brandmeldeanlage gekoppelt und werden im Bedarfsfall von dieser selbstständig ausgelöst. Diese werden meistens von der Behörde bei Vorlage einer erhöhten Brandgefährdung vorgeschrieben, um Entstehungsbrände effizient zu bekämpfen bzw. eine Ausbreitung zu unterbinden.
Sprinkleranlagen
Sprinkleranlagen sind automatisch wirkende Löschanlagen mit dem Löschmittel Wasser. Die Auslösung der Anlage erfolgt durch thermische Zerstörung der Sprinklerkopfabschlüsse (im Normalfall alkoholgefüllte Glasviolen). Dadurch wird der Austritt von Wasser durch den Sprinklerkopf freigegeben.
Bei der Auslegung der Anlage (Löschwasserleistung, Wirkfläche und Löschwasserbevorratung) ist die Brandbelastung des jeweils betroffenen Bereiches zu berücksichtigen.
CO2-Löschanlagen
CO2-Löschanlagen sind Gaslöschanlagen mit dem Löschmittel CO2. Bei der Planung ist neben der brandschutztechnisch richtigen Auslegung die erstickende Wirkung des CO2 als wesentlicher Faktor zu berücksichtigen. Es muss daher nach Branderkennung eine sofortige Alarmierung der betroffenen Personen und eine Schließung des Flutungsbereiches erfolgen. Die Einleitung des CO2 darf erst nach ausreichender Verzögerung zum Zwecke des Verlassens des Bereiches erfolgen. Die Auslösung des Löschmittels muss händisch unterbrechbar sein.
(ehemals) Halonlöschanlagen
Seit 2004 gilt in der EU ein Verbot von Halon betriebenen Löschgeräten (FCKW, welches die Ozonschicht zerstört). Als Ersatz werden natürliche oder chemische Löschmittel sowie Sprinkleranlagen verwendet.
Schaumlöschanlagen
Schaumlöschanlagen sind Löschanlagen mit dem Löschmittel Schaum, welche ähnlich wie Sprinkleranlagen funktionieren.

9.2.10 Brandschutzbegehungen

Die Erfahrungen zeigen, dass im täglichen Betrieb die Vorschriften und Regelungen zum Brandschutz immer nachlässiger gehandhabt werden - oft bis hin zur völligen Ignoranz.
Einige Beispiele dazu:
  • Fluchtwege werden blockiert, z. B. durch Möbel und Papiervorräte.
  • Brandabschnittstüren werden durch Keile offen gehalten.
  • Zulässige Brandlasten werden durch anwachsende Kabelmengen oder geänderte Nutzungen überschritten.
  • Brandabschottungen werden bei Arbeiten beschädigt und nicht ordnungsgemäß wiederhergerichtet.
Aus diesem Grund sollten ein- bis zweimal im Jahr Brandschutzbegehungen - angekündigt oder unangekündigt - erfolgen. Vorgefundene Missstände müssen dazu Anlass geben, die Zustände und deren Ursachen unverzüglich zu beheben.
Im Wiederholungsfall oder bei besonders eklatanten Verstößen gegen die Brandschutzvorschriften sind auch entsprechende Sanktionen vorzusehen.

9.2.11 Rauchverbot

In Räumen mit IT oder Datenträgern (Serverraum, Datenträgerarchiv, aber auch Belegarchiv), in denen Brände oder Verschmutzungen zu hohen Schäden führen können, sollte ein Rauchverbot erlassen werden. Dieses Rauchverbot dient gleicherweise dem vorbeugenden Brandschutz wie der Betriebssicherheit von IT mit mechanischen Funktionseinheiten.
Die Einhaltung des Rauchverbotes ist zu kontrollieren.

9.2.12 Rauchschutzvorkehrungen

Im Brandfall geht von der damit verbundenen Rauchentwicklung sowohl für Mensch als auch für IT-Gerätschaften eine erhebliche Gefahr aus. Ein umfassender Rauchschutz ist daher vorzusehen.
In diesem Sinne ist zu gewährleisten, dass
  • rauchdichte Brandschutztüren verwendet werden (vgl. 9.2 Brandschutz),
  • Rauchschutztüren verwendet werden, die ggf. bei Rauchentwicklung selbsttätig geschlossen werden und die Rauchausbreitung verhindern,
  • die Lüftungsanlage eine Ablüftung von Rauch vornehmen kann und
  • die Lüftungs- und Klimaanlage selbsttätig auf Rauchentwicklung reagiert.

9.3 Stromversorgung, Maßnahmen gegen elektrische und elektromagnetische Risiken

9.3.1 Angepasste Aufteilung der Stromkreise

Die Raumbelegung und die Anschlusswerte, für die eine Elektroinstallation ausgelegt wurde, stimmen erfahrungsgemäß nach einiger Zeit nicht mehr mit den tatsächlichen Gegebenheiten überein. Es ist also unerlässlich, bei Änderungen der Raumnutzung und bei Änderungen und Ergänzungen der technischen Ausrüstung (IT, Klimaanlage, Beleuchtung etc.) die Elektroinstallation zu prüfen und ggf. anzupassen. Das kann durch Umrangierung von Leitungen geschehen. Andernfalls kann die Neuinstallation von Einspeisung, Leitungen, Verteilern etc. erforderlich werden.

9.3.2 Not-Aus-Schalter

Bei Räumen, in denen elektrische Geräte in der Weise betrieben werden, dass z. B. durch deren Abwärme, durch hohe Gerätedichte oder durch Vorhandensein zusätzlicher Brandlasten ein erhöhtes Brandrisiko besteht, ist nach Möglichkeit die Installation eines Not-Aus-Schalters vorzusehen. Mit Betätigung des Not-Aus-Schalters wird dem Brand eine wesentliche Energiequelle genommen, was bei kleinen Bränden zu deren Verlöschen führen kann. Zumindest ist aber die Gefahr durch elektrische Spannungen beim Löschen des Feuers beseitigt.
Zu beachten ist, dass lokale unterbrechungsfreie Stromversorgungen (USV) nach Ausschalten der externen Stromversorgung die Stromversorgung selbsttätig übernehmen und die angeschlossenen Geräte unter Spannung bleiben. Daher ist bei der Installation eines Not-Aus-Schalters zu beachten, dass auch die USV abgeschaltet und nicht nur von der externen Stromversorgung getrennt wird (siehe auch 9.3.4 Lokale unterbrechungsfreie Stromversorgung).
Der Not-Aus-Schalter sollte innerhalb des Raumes neben der Eingangstür (evtl. mit Lagehinweis außen an der Tür) oder außerhalb des Raumes neben der Tür angebracht werden. Dabei ist allerdings zu bedenken, dass dieser Not-Aus-Schalter auch unnotwendigerweise versehentlich oder absichtlich betätigt werden kann.

9.3.3 Zentrale Notstromversorgung

In Bereichen, in denen die Stromversorgung bei Ausfällen des öffentlichen Netzes über einen längeren Zeitraum aufrechtzuerhalten ist - dies kann sowohl für die Versorgung von IT-Anlagen als auch der Infrastruktur gelten - ist eine zentrale Notstromversorgung vorzusehen.
Diese wird in der Regel als Diesel-Notstrom-Aggregat realisiert. In einzelnen Fällen, wo die Verfügbarkeitsanforderungen es zulassen, kann die Notstromversorgung auch in Form einer zweiten Energieeinspeisung aus dem Netz eines zweiten Energieversorgungsunternehmens (EVU) realisiert werden.

9.3.4 Lokale unterbrechungsfreie Stromversorgung

Mit einer unterbrechungsfreien Stromversorgung (USV) kann ein kurzzeitiger Stromausfall überbrückt werden oder die Stromversorgung solange aufrechterhalten werden, dass ein geordnetes Herunterfahren angeschlossener Rechner möglich ist.
Dies ist insbesondere dann sinnvoll, wenn
  • im Rechner umfangreiche Daten zwischengespeichert werden (z. B. Cache-Speicher im Netz-Server), bevor sie auf nichtflüchtige Speicher ausgelagert werden,
  • beim Stromausfall ein großes Datenvolumen verloren gehen würde und nachträglich nochmals erfasst werden müsste,
  • die Stabilität der Stromversorgung nicht ausreichend gewährleistet ist.
Drei Arten der USV sind zu unterscheiden:
  • Off-line-USV: Hierbei werden die angeschlossenen Verbraucher im Normalfall direkt aus dem Stromversorgungsnetz gespeist. Erst wenn dieses ausfällt, schaltet sich die USV selbsttätig zu und übernimmt die Versorgung.
  • Netzinteraktive USV: Eine Weiterentwicklung der off-line-USV, bei der die eingehende Netzspannung über einen automatischen Spannungsregelkreis (AVR) direkt an den Verbraucher weitergeleitet wird. Wird von der USV-Elektronik ein Netzausfall erkannt, schaltet sie den bereits netzsynchron mitlaufenden Wechselrichter von Netzversorgung auf Batterieeinspeisung um.
  • On-line-USV: Hier ist die USV ständig zwischen Netz und Verbraucher geschaltet. Die gesamte Stromversorgung läuft immer über die USV.
Alle 3 USV-Arten können neben der Überbrückung von Totalausfällen der Stromversorgung und Unterspannungen auch (mehr oder weniger gut) dazu dienen, Überspannungen zu glätten.
Bei der Dimensionierung einer USV kann man i. d. R. von einer üblichen Überbrückungszeit von ca. 10 bis 15 Minuten ausgehen. Die Mehrzahl aller Stromausfälle ist innerhalb von 5 bis 10 Minuten behoben, so dass nach Abwarten dieser Zeitspanne noch 5 Minuten übrig bleiben, um die angeschlossene IT geordnet herunterfahren zu können, sollte der Stromausfall länger andauern. Die meisten modernen USV-Geräte bieten Rechnerschnittstellen an, die nach einer vorher festgelegten Zeit, entsprechend dem Zeitbedarf der IT und der Kapazität der USV, ein rechtzeitiges automatisches Herunterfahren (Shut-down) einleiten können. Für spezielle Anwendungsfälle (z. B. TK-Anlagen) kann die erforderliche Überbrückungszeit auch mehrere Stunden betragen.
Um die Schutzwirkung aufrechtzuerhalten, ist eine regelmäßige Wartung der USV vorzusehen.
Falls die Möglichkeit besteht, die Stromversorgung unterbrechungsfrei aus einer anderen Quelle zu beziehen (z. B. durch Anschluss an eine zentrale USV), so stellt dies eine Alternative zur lokalen USV dar.
Weiters ist zu beachten:
  • Die USV ist regelmäßig - entsprechend den Angaben des Herstellers - zu warten.
  • Die Wirksamkeit der USV ist regelmäßig zu testen.
  • Im Falle von Veränderungen ist zu überprüfen, ob die vorgehaltene Kapazität der USV noch ausreichend ist.
In diesem Zusammenhang ist auch 9.3.2 Not-Aus-Schalter zu beachten.

9.3.5 Blitzschutzeinrichtungen (Äußerer Blitzschutz)

Die direkten Auswirkungen eines Blitzeinschlages auf ein Gebäude (Beschädigung der Bausubstanz, Dachstuhlbrand u. ä.) lassen sich durch die Installation einer Blitzschutzanlage verhindern.
Über diesen „äußeren Blitzschutz“ hinaus ist fast zwingend der „innere Blitzschutz“, der Überspannungsschutz, erforderlich. Denn der äußere Blitzschutz schützt die elektrischen Betriebsmittel im Gebäude nicht. Dies ist nur durch einen Überspannungsschutz möglich (siehe dazu 9.3.6 Überspannungsschutz (Innerer Blitzschutz), dessen hohe Kosten dem Schutzgut gegenüber gerechtfertigt sein müssen).

9.3.6 Überspannungsschutz (Innerer Blitzschutz)

Je nach Qualität und Ausbau des Versorgungsnetzes des Energieversorgungsunternehmens und des eigenen Stromleitungsnetzes, abhängig vom Umfeld (andere Stromverbraucher) und von der geographischen Lage, können durch Induktion oder Blitzschlag Überspannungsspitzen im Stromversorgungsnetz entstehen.
Überspannungen durch Blitz haben i. d. R. ein recht hohes zerstörerisches Potenzial, während Überspannungen anderer Ursachen geringer sind, aber trotzdem ausreichen können, um Mikroelektronikgeräte zu stören oder zu zerstören.
Der Überspannungsschutz wird in der Regel in drei voneinander abhängigen Stufen aufgebaut:
  • Grobschutz:
    Geräte für den Grobschutz vermindern Überspannungen, wie sie durch direkten Blitzschlag entstehen, und begrenzen sie auf ca. 6000V. Für die Auswahl des Grobschutzes ist es bedeutend, ob ein äußerer Blitzschutz vorhanden ist oder nicht.
  • Mittelschutz:
    Der Mittelschutz begrenzt die verbleibende Überspannung auf ca. 1500 V und ist auf die Vorschaltung eines Grobschutzes angewiesen.
  • Feinschutz:
    Geräte für den Feinschutz senken Überspannungen so weit herab, dass sie auch für empfindliche Bauteile mit Halbleiterbauelementen ungefährlich sind.
Weiters ist zu beachten:
  • Blitz- und Überspannungsschutzeinrichtungen sollten periodisch und nach bekannten Ereignissen geprüft und ggf. ersetzt werden.
  • Potenzialausgleich: Nur wenn alle Schutzeinrichtungen sich auf das gleiche Potenzial beziehen, ist ein optimaler Schutz möglich. Bei Nachinstallationen ist darauf zu achten, dass der Potenzialausgleich mitgeführt wird.

9.3.7 Schutz gegen elektromagnetische Einstrahlung

Die Funktion informationstechnischer Geräte kann durch die elektromagnetische Strahlung benachbarter Einrichtungen beeinträchtigt werden. Mögliche Ursachen für solche Störstrahlungen sind Radarstrahlung, Mobilfunk-, Rundfunk- und Fernsehsender, Richtfunkanlagen, Hochspannungsleitungen, Maschinen, von denen elektromagnetische Störungen ausgehen können (Schweißgeräte, Anlagen mit starken Elektromotoren, Mikrowellenherde usw.) oder atmosphärische Entladungen.
So weit möglich, sollten solche Störquellen bereits bei der Planung berücksichtigt bzw. ausgeschaltet werden. Als nachträgliche Maßnahmen bleiben etwa:
  • die Verwendung von Schutzschränken mit speziellen Filtern und Türdichtungen oder
  • die Abschirmung durch beschichtete Wände.
Anmerkung: Diese Maßnahme behandelt den Schutz gegen Störstrahlung im täglichen Umfeld. Schutz gegen einen elektromagnetischen Puls (EMP) als Folge kriegerischer Handlungen gehen über den mittleren Schutzbedarf hinaus und sind daher nicht Gegenstand des vorliegenden Handbuches.

9.3.8 Schutz gegen kompromittierende Abstrahlung

Überall dort, wo Information elektronisch übertragen, verarbeitet oder dargestellt wird, ist die Gefahr der kompromittierenden Abstrahlung gegeben. Bildschirme, Tastaturen, Drucker, Modems, Graphikkarten, LAN-Komponenten, Fax-Geräte und ähnliche Geräte geben elektromagnetische Wellen ab, die noch in einer Entfernung von mehreren Metern - bei Monitoren bis zu mehreren hundert Metern - aufgefangen und analysiert werden können (Side-Channel-Attacken). In der Nähe geführte Leitungen (Heizkörper, Wasserleitungen, …) können diese Abstrahlung beträchtlich verstärken.

Abwehrmaßnahmen

Möglichkeiten, den Verlust der Vertraulichkeit von Daten durch kompromittierende Abstrahlung zu verhindern, sind etwa:
  • Auswahl des Standortes (innerhalb eines Gebäudes):
    Bereits eine geeignete Aufstellung von IT-Komponenten, die entsprechend vertrauliche Daten verarbeiten oder übertragen und bei denen die Gefahr einer kompromittierenden Abstrahlung besteht, kann das potenzielle Risiko durch kompromittierende Abstrahlung in erheblichem Maße verringern. Daher sollten, soweit baulich, technisch und organisatorisch möglich, potenziell gefährdete Komponenten in Räumen untergebracht werden, die möglichst weit entfernt von Straßenfronten und Gebäuden mit Fremdfirmen sind. Weiters ist eine Aufstellung in der Nähe von Leitungen (Heizungsrohre, Heizkörper, Wasserleitungen, …) zu vermeiden.
  • Schirmung von Geräten:
    Diese erfolgt durch die Verwendung spezieller Materialien. Solche abstrahlsichere Hardwarekomponenten werden in Anlehnung an den englischen Fachausdruck meist als „tempest-proof“ oder „tempest-gehärtet“ bezeichnet. [Anmerkung: Für die Bedeutung des Wortes TEMPEST werden verschiedene Erklärungen genannt, z. B. „Temporary Emission and Spurious Transmission“, „Transient Electromagnetic Pulse Emanation Surveillance Technology“ oder „Transient Electromagnetic Pulse Emanations Standard“. Es wird auch die Meinung vertreten, dass es sich nicht um ein Akronym, sondern um einen Codenamen ohne besondere Bedeutung handelt.]
  • Schirmung von Räumen und Gebäuden:
    Anstelle eines Schutzes auf Geräteebene ist - bei entsprechenden Gegebenheiten - auch ein Schutz auf Raum- oder Gebäudeebene möglich. Dabei werden Wände, Böden und Decken entsprechend abgeschirmt. Auch Spezialglas, das mit einem transparenten Metallfilm beschichtet ist, wird am Markt angeboten, da selbstverständlich Fenster in den Schutz mit einzubeziehen sind. Eine Raumschirmung schützt i. Allg. auch gegen Störstrahlung von außen.
  • Überlagerung der kompromittierenden Abstrahlung:
    Durch Senden von Stördaten in einer bestimmten Frequenzbreite können die Emissionen der DV-Geräte überlagert werden.
Selbst bei der Verwendung von kleinsten Geräten wie beispielsweise Kryptomodulen oder Smartcards ist auf deren kompromittierende Strahlung zu achten. Gerade bei sicherheitsrelevanten Anwendungen (Zugangssystemen, kryptographische Anwendungen etc.) ist deren Schutzbedarf immens. In diesem Zusammenhang sind die Möglichkeiten von Side-Channel-Attacken (Differential Power Analysis - DPA, Differential Electro-Magnetic Analysis - DEMA) zu berücksichtigen. Demnach sind bereits bei der Anschaffung von Geräten jene mit entsprechenden Gegenmaßnahmen zu bevorzugen.
Auch das Überkoppeln auf Leitungen ist eine Auswirkung von kompromittierender elektromagnetischer Strahlung. Wird ein Signal leitungsgebunden übertragen, so ist der elektrische Leiter mit einem elektromagnetischen Feld umgeben. Dieses Feld erzeugt auf in unmittelbarer Umgebung des Leiters verlegten Kabeln Spannungen und Ströme, aus denen das Signal des ursächlichen Leiters wiedergewonnen werden kann. Dabei spielt es keine Rolle, ob es sich um eine analoge oder digitale Nachrichtenübertragung handelt. In beiden Fällen kann mit recht einfachen Maßnahmen das ursprüngliche Signal wiederaufbereitet werden. Geeignete Schutzmaßnahmen sind:
  • Wahl geeigneter Kabeltypen wie beispielsweise Koaxial- oder Twisted-Pair-Kabeln
  • Achten auf hochwertige Schirmung der Kabel (vorzugsweise ist doppelte Schirmung zu verwenden - Kombination aus Folien- und Geflechtschirmung)
  • Verlegung parallel geführter Kabel in ausreichendem Abstand zueinander
  • Verringerung des Signal-Oberwellengehaltes durch elektrische Filterung (besonders bei digitalen Übertragungen)
  • Vorzugsweise Verwendung von Lichtwellenleitern (Gefahr des Übersprechens deutlich geringer aber in Folge mechanischer Beschädigungen des Kabels ebenfalls möglich)

9.3.9 Schutz gegen elektrostatische Aufladung

Elektrostatische Aufladungen können Schäden an Bauteilen, Programmstörungen oder Datenverluste verursachen. Aus diesem Grund wird für Komponenten, die in ungeschützter Umgebung eingesetzt werden, eine relativ hohe Widerstandsfähigkeit gegen elektrostatische Aufladung gefordert.
Zieht man allerdings in Betracht, dass abhängig von Bodenbeschaffenheit - hier stellen insbesondere Teppichböden eine Gefahrenquelle dar - und Schuhwerk die elektrostatische Aufladung von gehenden Personen 10 kV und mehr betragen kann, so zeigt sich die Notwendigkeit von Maßnahmen zur Vermeidung und Eliminierung elektrostatischer Aufladungen.
Solche Maßnahmen sind etwa:
  • die Gewährleistung einer relativen Luftfeuchtigkeit von mindestens 50 %,
  • die Verwendung geeigneter Werkstoffe (Bodenbeläge, …),
  • Erdungsmaßnahmen,
  • der Einsatz von Antistatikmitteln.

9.4 Leitungsführung

9.4.1 Lagepläne der Versorgungsleitungen

Es sind genaue Lagepläne aller Versorgungsleitungen (Strom, Wasser, Gas, Telefon, Gefahrenmeldung etc.) im Gebäude und auf dem dazugehörenden Grundstück zu führen und alle die Leitungen betreffenden Sachverhalte aufzunehmen:
  • genaue Führung der Leitungen (Einzeichnung in bemaßte Grundriss- und Lagepläne),
  • genaue technische Daten (Typ und Abmessung),
  • evtl. vorhandene Kennzeichnung,
  • Nutzung der Leitungen (Nennung der daran angeschlossenen Netzteilnehmer, soweit möglich und zweckmäßig),
  • Gefahrenpunkte und
  • vorhandene und zu prüfende Schutzmaßnahmen.
Es muss möglich sein, sich anhand der Pläne einfach und schnell ein genaues Bild der Situation zu machen. Nur so kann das Risiko, dass Leitungen bei Arbeiten versehentlich beschädigt werden, auf ein Mindestmaß reduziert werden. Eine Schadstelle ist schneller zu lokalisieren, die Störung schneller zu beheben.
Weiters ist zu beachten:
  • Alle Arbeiten an Leitungen sind rechtzeitig und vollständig zu dokumentieren.
  • Die Pläne sind gesichert aufzubewahren, der Zugriff darauf ist zu regeln, da sie schützenswerte Informationen beinhalten.
  • Die Verantwortlichkeiten für Aktualisierung und Aufbewahrung der Pläne sind festzulegen.

9.4.2 Materielle Sicherung von Leitungen und Verteilern

In Räumen mit Publikumsverkehr oder in unübersichtlichen Bereichen eines Gebäudes und zugehöriger Bereiche ist es sinnvoll, Leitungen und Verteiler zu sichern.
Dies kann auf verschiedene Weise erreicht werden, etwa:
  • Verlegung der Leitungen unter Putz,
  • Nagetierschutz,
  • Verlegung der Leitungen in Stahl- oder Kunststoffpanzerrohren,
  • Verlegung der Leitungen in mechanisch festen und abschließbaren Kanälen,
  • Verschluss von Verteilern und
  • bei Bedarf zusätzlich elektrische Überwachung von Verteilern und Kanälen.
Bei Verschluss sind Regelungen zu treffen, die die Zutrittsrechte, die Verteilung der Schlüssel und die Zugriffsmodalitäten festlegen. Weitere Angaben zur geeigneten Aufstellung und Aufbewahrung von IT-Systemen sind unter 9.5 Geeignete Aufstellung und Aufbewahrung zu finden.

9.4.3 Entfernen oder Kurzschließen und Erden nicht benötigter Leitungen

Nicht mehr benötigte Leitungen sollten nach Möglichkeit entfernt werden.
Ist dies aufgrund der damit verbundenen Beeinträchtigung des Dienstbetriebes (Öffnen von Decken, Fensterbank- und Fußbodenkanälen) nicht möglich, sind folgende Maßnahmen sinnvoll:
  • Kennzeichnen der nicht benötigten Leitungen in der Revisionsdokumentation und Löschen der Eintragungen in der im Verteiler befindlichen Dokumentation,
  • Auftrennen aller Rangierungen und Verbindungen der freien Leitungen in den Verteilern (soweit möglich),
  • Kurzschließen der freien Leitungen an beiden Kabelenden und in allen berührten Verteilern,
  • Auflegen der freien Leitungen auf Erde (Masse) an beiden Kabelenden und in allen berührten Verteilern; bei dadurch entstehenden Masse-Brumm-Schleifen ist nur einseitig zu erden,
  • Gewährleisten, dass nicht mehr benötigte Leitungen bei ohnehin anstehenden Arbeiten im Netz entfernt werden.

9.4.4 Auswahl geeigneter Kabeltypen

Bei der Auswahl von Kabeln ist neben der Berücksichtigung von übertragungstechnischen Anforderungen und Umfeldbedingungen auch die Frage nach den Sicherheitsanforderungen zu stellen.
Herkömmliche Kupferleitungen bieten ein potenzielles Ziel für aktive und passive Angriffe. Abhilfe kann hier entweder die Verwendung mehrfach geschirmter Leitungen oder der Einsatz von Lichtwellenleitern bringen.
Lichtwellenleiter sind unempfindlich gegen elektrische und elektromagnetische Störungen und bieten Schutz gegen (aktives und passives) Wiretapping auf der Leitung. Ein potenzielles Angriffsziel stellen aber die Schnittstellen (etwa Verstärker) dar, hier sind bei Bedarf entsprechende Schutzvorkehrungen zu treffen.

9.4.5 Schadensmindernde Kabelführung

Bei der Planung von Kabeltrassen ist darauf zu achten, dass erkennbare Gefahrenquellen umgangen werden. Grundsätzlich sollen Trassen nur in den Bereichen verlegt werden, die ausschließlich den BenutzerInnen zugänglich sind. Ein übersichtlicher Aufbau der Trassen erleichtert die Kontrolle. Trassen und einzelne Kabel sollen immer so verlegt werden, dass sie vor direkten Beschädigungen durch Personen, Fahrzeuge und Maschinen geschützt sind.
Der Standort von Geräten sollte so gewählt werden, dass Kabel nicht im Lauf- oder Fahrbereich liegen. Ist dies nicht zu vermeiden, sind die Kabel den zu erwartenden Belastungen entsprechend durch geeignete Kanalsysteme zu schützen.
In Tiefgaragen ist darauf zu achten, dass durch Trassen im Fahrbereich die zulässige Fahrzeughöhe nicht unterschritten wird, und dass Fremdpersonen keinen unautorisierten Zugriff zu den - in der Regel in geringer Deckenhöhe verlaufenden - Trassen erhalten.
Bei gemeinsam mit Dritten genutzten Gebäuden ist darauf zu achten, dass Kabel nicht in Fußbodenkanälen durch deren Bereiche führen. Fußboden- und Fensterbank-Kanalsysteme sind gegenüber den fremdgenutzten Bereichen mechanisch fest zu verschließen. Besser ist es, sie an den Bereichsgrenzen enden zu lassen.
Bereiche mit hoher Brandgefahr sind zu meiden. Ist dies nicht möglich und ist der Betriebserhalt aller auf der Trasse liegenden Kabel erforderlich, ist der entsprechende Trassenbereich mit Brandabschottung (siehe auch 9.2.4 Brandabschottung von Trassen) zu versehen. Ist der Betriebserhalt nur für einzelne Kabel erforderlich, ist dafür ein entsprechendes Kabel zu wählen.
In Produktionsbetrieben ist mit hohen induktiven Lasten und daraus resultierenden Störfeldern zu rechnen. Auch diese sind bei der Trassen- und Kabelverlegung zu berücksichtigen. Für den Schutz der Kabel gilt sinngemäß das Gleiche wie bei der Brandabschottung.
Bei Erdtrassen ist ca. 10 cm über der Trasse ein Warnband zu verlegen. Bei einzelnen Kabeln (ohne Rohr) ist der Einbau von Kabelabdeckungen sinnvoll.

9.4.6 Vermeidung von wasserführenden Leitungen

In Räumen oder Bereichen, in denen sich IT-Geräte mit zentralen Funktionen (z. B. Server) befinden, sollten wasserführende Leitungen aller Art vermieden werden. Die einzigen wasserführenden Leitungen sollten, wenn unbedingt erforderlich, Kühlwasserleitungen, Löschwasserleitungen und Heizungsrohre sein. Zuleitungen zu Heizkörpern sollten mit Absperrventilen, möglichst außerhalb des Raumes/Bereiches, versehen werden. Außerhalb der Heizperiode sind diese Ventile zu schließen.
Sind Wasserleitungen unvermeidbar, kann als Minimalschutz eine Wasserauffangwanne oder -rinne unter der Leitung angebracht werden, deren Ablauf außerhalb des Raumes führt. Günstig ist es, dazu den Flur zu nutzen, da so ein eventueller Leitungsschaden früher entdeckt wird.
Optional können Wassermelder mit automatisch arbeitenden Magnetventilen eingebaut werden. Diese Magnetventile sind außerhalb des Raumes/Bereiches einzubauen und müssen stromlos geschlossen sein.
Als zusätzliche oder alternative Maßnahme empfiehlt sich ggf. eine selbsttätige Entwässerung.

9.5 Geeignete Aufstellung und Aufbewahrung

Bei der Aufstellung eines IT-Systems sind verschiedene Voraussetzungen zu beachten, die die Sicherheit des Systems gewährleisten bzw. erhöhen sollen. Über diese Sicherheitsaspekte (die naturgemäß den Schwerpunkt des vorliegenden Handbuches bilden) hinaus, sollen durch eine geeignete Aufstellung auch die Lebensdauer und Zuverlässigkeit der Technik sowie die Ergonomie des Systems verbessert werden.
Im Folgenden werden generelle Hinweise für die Aufstellung von IT-Systemen und Komponenten gegeben, wie sie für die mittlere Datenverarbeitung typisch sind. Dabei wird unterschieden zwischen:
Wie für das gesamte Handbuch zutreffend und bereits in der Einleitung ausgeführt, wird auch hier nicht auf den Bereich des klassischen Rechenzentrums eingegangen, da hier i. Allg. sehr produkt- und herstellerspezifische Anforderungen bestehen und diese zudem über die Maßnahmen für den mittleren Schutzbedarf hinausgehen und damit den Rahmen der vorliegenden Arbeit sprengen würden.
Es ist festzuhalten, dass eine generelle Klassifikation aller IT-Komponenten in eine der oben genannten Gruppen nicht möglich ist. So kann ein Faxgerät etwa als Stand-alone-Gerät betrachtet werden, oder aber als Teil eines Arbeitsplatz-IT-Systems, falls die Möglichkeit besteht, ein Fax direkt vom PC zu versenden.
Die unten angeführten Maßnahmen sind daher als allgemeine Hinweise zu verstehen, die auf die Bedürfnisse des speziellen Falles abzubilden sind.

9.5.1 Geeignete Aufstellung eines Arbeitsplatz-IT-Systems

Unter Arbeitsplatz-IT-Systemen sind etwa PCs, Notebooks oder Terminals/„Thin Clients“ zu verstehen.
Bei der Aufstellung eines Arbeitsplatz-IT-Systems sollten - zusätzlich zu den von den Herstellern festgeschriebenen Vorgaben und Hinweisen sowie ergonomischen Gesichtspunkten - unter anderem folgende Voraussetzungen beachtet werden:
  • der Standort in der Nähe eines Fensters oder einer Tür erhöht die Gefahr des Beobachtens von außerhalb,
  • das System sollte nicht in unmittelbarer Nähe der Heizung aufgestellt werden (Vermeidung von Überhitzung, aber auch kompromittierender Abstrahlung, vgl. 9.3.8 Schutz gegen kompromittierende Abstrahlung),
  • das System sollte soweit möglich und erforderlich, physisch gesichert sein (Diebstahlschutz, versperrbare Diskettenlaufwerke, …, vgl. auch 8.1.7 Clear-Desk-Policy).

9.5.2 Geeignete Aufstellung eines Servers

Unter Servern sind in diesem Zusammenhang etwa Datenbank-, Programm- und Kommunikationsserver, aber auch TK-Anlagen zu verstehen.
Um Vertraulichkeit, Integrität und Verfügbarkeit im Betrieb von Servern sicherzustellen, ist es zwingend erforderlich, diese in einer gesicherten Umgebung aufzustellen.
Diese kann realisiert werden als:
  • Serverraum (vgl. 9.5.6 Serverräume):
    Raum zur Unterbringung von Servern, serverspezifischen Unterlagen, Datenträgern in kleinem Umfang sowie weiterer Hardware (etwa Drucker oder Netzwerkkomponenten). Im Serverraum ist i. Allg. kein ständig besetzter Arbeitsplatz eingerichtet, er wird nur sporadisch und zu kurzfristigen Arbeiten betreten.
  • Serverschrank, wenn kein separater Serverraum zur Verfügung steht (vgl. 9.5.7 Beschaffung und Einsatz geeigneter Schutzschränke):
    Serverschränke dienen zur Unterbringung von IT-Geräten und sollen den Inhalt sowohl gegen unbefugten Zugriff als auch gegen die Einwirkung von Feuer oder schädigenden Stoffen (Staub, Gase, …) schützen.
Details zu den technischen und organisatorischen Sicherheitsmaßnahmen bei Serverräumen und Serverschränken finden sich in 9.5.6 Serverräume und 9.5.7 Beschaffung und Einsatz geeigneter Schutzschränke.
Generell ist zu beachten:
  • Der Zugang und Zugriff zu Servern darf ausschließlich autorisierten Personen möglich sein.
  • Eine Vertretungsregelung muss sicherstellen, dass der Zugriff zum Server auch im Vertretungsfall geregelt möglich ist, und unautorisierte Zugriffe auch in Ausnahmesituationen nicht vorkommen können.

9.5.3 Geeignete Aufstellung von Netzwerkkomponenten

Unter Netzwerkkomponenten sind beispielsweise Modems, Switches/Router und Verteilerschränke zu verstehen.
Um den Missbrauch von Netzwerkkomponenten zu verhindern, muss sichergestellt werden, dass nur Berechtigte physikalischen Zugriff darauf haben. So bedeutet etwa der Missbrauch eines Modems zum einem die Durchführung unbefugter Datenübertragungen, durch die Kosten verursacht, Viren eingeschleppt oder Interna nach außen transferiert werden können, zum anderen das unbefugte Ändern oder Auslesen der Modemkonfiguration, wodurch Sicherheitslücken entstehen können.
Steht ein Modem direkt an einem Arbeitsplatz-IT-System zur Verfügung, so ist der physikalische Zugriff darauf abzusichern (z. B. durch Versperren des Raumes, vgl. auch 9.5.1 Geeignete Aufstellung eines Arbeitsplatz-IT-Systems).
Wenn über ein Modem oder einen Modempool Zugänge zum internen Netz geschaffen werden, ist darauf zu achten, dass keine Umgehung einer bestehenden Firewall geschaffen wird. Sollen mit einem Modempool weitere externe Zugänge zu einem durch eine Firewall geschützten Netz geschaffen werden, muss dieser auf der unsicheren Seite der Firewall aufgestellt werden.
Netzwerkkomponenten sollten wie Server in einem gesicherten Serverraum oder einem Schutzschrank aufgestellt sein. Die entsprechenden Maßnahmen 9.5.6 Serverräume und 9.5.7 Beschaffung und Einsatz geeigneter Schutzschränke sind zu beachten.
Auch hier ist sicherzustellen:
  • Der Zugang und Zugriff zu Netzwerkkomponenten darf ausschließlich autorisierten Personen möglich sein.
  • Eine Vertretungsregelung muss sicherstellen, dass der Zugriff zu Netzwerkkomponenten auch im Vertretungsfall geregelt möglich ist und unautorisierte Zugriffe auch in Ausnahmesituationen nicht vorkommen können.

9.5.4 Nutzung und Aufbewahrung mobiler IT-Geräte

Unter mobilen IT-Geräten sind alle für einen mobilen Einsatz geeigneten Geräte zu verstehen, so etwa Notebooks, Personal Digital Assistants (PDAs), Tablet-PCs und Smartphones.
Da die Umfeldbedingungen bei mobilem Einsatz meist außerhalb der direkten Einflussnahme der BenutzerInnen liegen, müssen sie versuchen, mobile IT-Geräte auch außer Haus sicher aufzubewahren. Hierfür können nur einige Hinweise gegeben werden, die bei der mobilen Nutzung zu beachten sind:
  • Die BenutzerInnen mobiler IT-Geräte sind über die potenziellen Gefahren bei Mitnahme und Nutzung eines solchen Gerätes außerhalb der geschützten Umgebung eingehend zu informieren und zu sensibilisieren. Soweit möglich sollten solche Informationen in schriftlicher Form - etwa als Merkblätter - an die MitarbeiterInnen verteilt werden. Dabei ist auch auf die besonderen Gegebenheiten in verschiedenen Zielgebieten und in speziellen Situationen (etwa bei einer besonders eingehenden Zollkontrolle) hinzuweisen.
  • Werden auf mobilen IT-Geräten eingeschränkte, vertrauliche, geheime oder streng geheime bzw. personenbezogene oder sensible Daten (siehe 5.2.5.1 Definition der Sicherheitsklassen) gespeichert und verarbeitet, so ist die Installation eines Zugriffsschutzes (über Passwort oder Chipkarte) sowie einer Festplatten- oder Dateiverschlüsselung dringend zu empfehlen (vgl. auch 7.1.3.1 Herausgabe einer PC-Richtlinie). Dabei ist zu beachten, dass die Zulässigkeit von Verschlüsselungstechnologien in den einzelnen Staaten unterschiedlich geregelt ist.
  • Soweit möglich, sollten auch mobile Datenträger (z. B. USB-Sticks, Disketten und Streamerbänder) ausschließlich chiffrierte Daten enthalten; werden in Ausnahmefällen unverschlüsselte Datenträger im mobilen Einsatz verwendet, so sollten diese keinesfalls unbeaufsichtigt (etwa im Hotel oder in einem Fahrzeug) zurückgelassen werden.
  • Nach Möglichkeit sollten die Zeiten, in denen das Gerät unbeaufsichtigt bleibt, minimiert werden.
  • Werden mobile IT-Geräte in einem Kraftfahrzeug aufbewahrt, so sollten diese Geräte von außen nicht sichtbar sein. Das Abdecken der Geräte oder das Einschließen in den Kofferraum bieten Abhilfe.
  • Wird ein mobiles IT-Gerät in fremden Büroräumen vor Ort benutzt, so ist dieser Raum nach Möglichkeit auch bei kurzzeitigem Verlassen zu verschließen. Wird der Raum für längere Zeit verlassen, sollte zusätzlich das Gerät ausgeschaltet werden, um über das Bootpasswort die unerlaubte Nutzung zu verhindern.
  • In Hotelräumen sollte ein mobiles IT-Gerät nicht offen aufliegen. Das Verschließen des Gerätes in einem Schrank behindert Gelegenheitsdiebe.
  • Einige neuere Geräte bieten zusätzlich die Möglichkeit zum Anketten des Gerätes. Der Diebstahl setzt dann den Einsatz von Werkzeug voraus.

9.5.5 Sichere Aufbewahrung der Datenträger vor und nach Versand

Vor dem Versand eines Datenträgers ist zu gewährleisten, dass für den Zeitraum zwischen dem Speichern der Daten auf dem Datenträger und dem Transport ein ausreichender Zugriffsschutz besteht. Beschriebene Datenträger sollten bis zum Transport in entsprechenden Behältnissen (Schrank, Tresor) verschlossen aufbewahrt werden. Die für den Transport oder für die Zustellung Verantwortlichen (z. B. Poststelle) sind auf die sachgerechte und sichere Aufbewahrung und Handhabung von Datenträgern hinzuweisen.
Alternativ oder ergänzend kann auch eine verschlüsselte Speicherung der Daten vorgenommen werden.
Weitere Maßnahmen dazu finden sich in 10.7 Betriebsmittel und Datenträger.

9.5.6 Serverräume

Ein Serverraum dient zur Unterbringung eines oder mehrerer Server sowie serverspezifischer Unterlagen. Darüber hinaus können dort auch Datenträger (in kleinerem Umfang) sowie zusätzliche Hardware, wie etwa Protokolldrucker oder Klimatechnik, vorhanden sein.
Im Serverraum ist kein ständig besetzter Arbeitsplatz eingerichtet, er wird nur sporadisch und zu kurzfristigen Arbeiten betreten. Zu beachten ist jedoch, dass im Serverraum aufgrund der Konzentration von IT-Geräten und Daten ein deutlich höherer Schaden eintreten kann als beispielsweise in einem Büroraum.
Für den Schutz von Serverräumen sind die entsprechenden baulichen und infrastrukturellen Maßnahmen, die in 9.1 Bauliche und infrastrukturelle Maßnahmen beschrieben werden, zur Anwendung zu bringen. Besondere Beachtung ist dabei folgenden Maßnahmen zu widmen:

9.5.7 Beschaffung und Einsatz geeigneter Schutzschränke

Schutzschränke können ihren Inhalt gegen die Einwirkung von Feuer bzw. gegen unbefugten Zugriff schützen.
Je nach angestrebter Schutzwirkung sind bei der Auswahl geeigneter Schutzschränke folgende Hinweise zu beachten:
  • Schutz gegen Feuereinwirkung:
    Bei Schutzschränken unterscheidet man bezüglich Schutz gegen Feuereinwirkung die Güteklassen S60 und S120 nach ÖNORM EN 1047-1. In diesen Güteklassen werden die Schutzschränke darauf geprüft, ob in ihnen bis zu einer Beflammungszeit von 60 bzw. 120 Minuten während eines normierten Testes für die geschützten Datenträger verträgliche Temperaturen erhalten bleiben. Durch Zusätze in der Klassifizierung werden die zu schützenden Datenträger bezeichnet. Die Kürzel bedeuten im Einzelnen: P = Papier aller Art,
    D = Datenträger (z. B. Magnetbänder, Filme),
    DIS = Disketten und Magnetbandkassetten einschließlich aller anderen Datenträger.
    Die Unterschiede zwischen den Klassen liegen in der Isolationsleistung, die bei DIS-Schränken am höchsten ist. Für den IT-Grundschutz sollten bei Schutz gegen Feuer Schutzschränke der Güteklasse S60 ausreichend sein. Zu beachten bleibt, dass solche Schränke damit Schutz gegen Feuer für einen gewissen Zeitraum bieten, so dass Datenträger nicht zerstört werden, jedoch ist davon auszugehen, dass im Brandfall der Betrieb eines in einem Serverschrank untergebrachten Servers nicht aufrechterhalten werden kann. Bei Schutzschränken, die zum Schutz vor Feuer und Rauch dienen, sollte eine Vorrichtung zum automatischen Schließen der Türen im Brandfall vorgesehen werden. Die Schließung sollte lokal durch Rauchgasmelder oder extern durch ein Signal einer Brandmeldeanlage (soweit vorhanden) ausgelöst werden können.
  • Schutz gegen unbefugten Zugriff:
    Der Schutzwert gegen unbefugten Zugriff wird neben der mechanischen Festigkeit des Schutzschrankes entscheidend durch die Güte des Schlosses beeinflusst. Für den IT-Grundschutz sollten Wertschränke nach RAL-RG 627 [Anmerkung - RAL: Deutsches Institut für Gütesicherung und Kennzeichnung e.V. Bonn] geeignet sein. Sind Zugriffsschutz und Brandschutz in Kombination erforderlich, so können Datensicherungsschränke nach RAL-RG 626/9 verwendet werden.
Weitere relevante Normen und Informationen sind Z. B. VDMA 24992 für Stahlschränke des Verbandes deutscher Maschinen- und Anlagenbau e.V. (VDMA). Hilfestellung bei der Bewertung des Widerstandswertes verschiedener Schutzschränke gibt das VDMA-Einheitsblatt 24990, in dem Sicherheitsmerkmale von Schutzschränken kurz beschrieben werden.
Bei der Auswahl von Schutzschränken ist auch die zulässige Deckenbelastung am Aufstellungsort zu berücksichtigen. Schutzschränke, die aufgrund ihrer geringen Größe relativ einfach weggetragen werden könnten, sollten in der Wand oder im Boden verankert werden.
Nach diesen Auswahlkriterien für den Schutzwert des Schutzschrankes ist als Nächstes die Ausstattung des Schrankes bedarfsgerecht festzulegen. Dazu sollte vor der Beschaffung eines Schutzschrankes festgelegt werden, welche Geräte bzw. welche Arten von Datenträgern in ihm aufbewahrt werden sollen. Die Innenausstattung des Schutzschrankes ist dieser Festlegung angemessen auszuwählen. Nachrüstungen sind in der Regel schwierig, da der Schutzwert des Schrankes und seine spezifische Zulassung beeinträchtigt werden können. Es sollte auch Raum für zukünftige Erweiterungen mit eingeplant werden.
Serverschränke:
Schutzschränke, in denen wichtige IT-Komponenten (also im Regelfall Server) untergebracht sind, werden auch als Serverschränke bezeichnet. In diesen sollte außer für den Server und eine Tastatur auch Platz für einen Bildschirm und weitere Peripheriegeräte wie z. B. Bandlaufwerke vorgesehen werden, damit Administrationsarbeiten vor Ort durchgeführt werden können. Dazu ist zu beachten, dass die Ausstattung ergonomisch gewählt ist, damit Administrationsarbeiten am Server ungehindert durchgeführt werden können. So ist zum Beispiel ein ausziehbarer Boden für die Tastatur wünschenswert, der in einer Höhe angebracht wird, dass AdministratorInnen Arbeiten sitzend durchführen können. Je nach Nutzung des Schrankes können auch eine Klimatisierung oder eine USV-Versorgung erforderlich sein. Die entsprechenden Geräte sollten dann im Schrank mit untergebracht werden. Andernfalls muss zumindest eine Lüftung vorhanden sein. Die Ausstattung des Schrankes mit einem lokal arbeitenden Brandfrüherkennungssystem, das im Brandfall die Stromzufuhr der Geräte unterbricht (auf der Eingangs- und der Ausgangsseite der USV, sofern diese vorhanden ist), ist empfehlenswert.
Nicht im gleichen Schrank untergebracht werden sollten Backup-Datenträger und Protokolldrucker. Backup-Datenträger würden im Falle einer Beschädigung des Servers vermutlich ebenfalls beschädigt. Die Protokollierung der Aktionen am Server dient auch zur Kontrolle der AdministratorInnen. Es ist also nicht sinnvoll, ihnen, ggf. sogar als Einzigen, Zugriff auf die Protokollausdrucke zu gewähren.
Verschluss von Schutzschränken:
Generell sind Schutzschränke bei Nichtbenutzung zu verschließen. Werden Arbeiten, die ein Öffnen des Schutzschrankes erfordern, unterbrochen, so ist auch bei kurzfristigem Verlassen des Raumes der Schutzschrank zu verschließen.
Werden Schutzschränke mit mechanischen oder elektronischen Codeschlössern verwendet, so muss der Code für diese Schlösser geändert werden
  • nach der Beschaffung,
  • bei Wechsel der BenutzerInnen,
  • nach Öffnung in Abwesenheit der BenutzerInnen,
  • wenn der Verdacht besteht, dass der Code Unbefugten bekannt wurde und
  • mindestens einmal alle zwölf Monate.
Der Code darf nicht aus leicht zu ermittelnden Zahlen (z. B. persönliche Daten, arithmetische Reihen) bestehen.
Die jeweils gültigen Codes von Codeschlössern sind aufzuzeichnen und gesichert zu hinterlegen. Zu beachten ist, dass eine Hinterlegung im zugehörigen Schutzschrank sinnlos ist.
Wenn der Schutzschrank neben einem Codeschloss ein weiteres Schloss besitzt, so ist abzuwägen, ob Code und Schlüssel gemeinsam hinterlegt werden, was im Notfall einen schnelleren Zugriff erlauben würde, oder getrennt hinterlegt werden, so dass es für AngreiferInnen schwieriger ist, sich Zugriff zu verschaffen.

9.6 Weitere Schutzmaßnahmen

9.6.1 Einhaltung einschlägiger Normen und Vorschriften

Für nahezu alle Bereiche der Technik gibt es Normen bzw. Vorschriften, z. B. der ÖNORM und des ÖVE. Diese Regelwerke tragen dazu bei, dass technische Einrichtungen ein ausreichendes Maß an Schutz für die BenutzerInnen und Sicherheit für den Betrieb gewährleisten. Bei der Planung und Errichtung von Gebäuden, bei deren Umbau, beim Einbau technischer Gebäudeausrüstungen (z. B. interne Versorgungsnetze wie Telefon- oder Datennetze) und bei Beschaffung und Betrieb von Geräten sind entsprechende Normen und Vorschriften unbedingt zu beachten.
In A.1 Sicherheitsszenarien werden einige dieser Normen beispielhaft angeführt.

9.6.2 Regelungen für Zutritt zu Verteilern

Die Verteiler (z. B. für Energieversorgung, Datennetze, Telefon) sind nach Möglichkeit in Räumen für technische Infrastruktur unterzubringen. Die dort geforderten Maßnahmen sind zu berücksichtigen.
Der Zutritt zu den Verteilern aller Versorgungseinrichtungen (Strom, Wasser, Gas, Telefon, Gefahrenmeldung, Rohrpost etc.) im Gebäude muss möglich und geordnet sein.
Mit „möglich“ ist gemeint, dass
  • Verteiler nicht bei Malerarbeiten mit Farbe oder Tapeten so verklebt werden, dass sie nur noch mit Werkzeug zu öffnen oder unauffindbar sind,
  • Verteiler nicht mit Möbeln, Geräten, Paletten etc. zugestellt werden,
  • für verschlossene Verteiler die Schlüssel verfügbar sind und die Schlösser funktionieren.
Mit „geordnet“ ist gemeint, dass festgelegt ist, wer welchen Verteiler öffnen darf. Verteiler sollten verschlossen sein und dürfen nur von den für die jeweilige Versorgungseinrichtung zuständigen Personen geöffnet werden. Die Zugriffsmöglichkeiten können durch unterschiedliche Schlüssel und entsprechende Schlüsselverwaltung geregelt werden (siehe dazu 9.1.4 Zutrittskontrolle).

9.6.3 Vermeidung von Lagehinweisen auf schützenswerte Gebäudeteile

Schützenswerte Gebäudeteile sind z. B. Rechenzentrum, Serverraum, Datenträgerarchiv, Klimazentrale, Verteilungen der Stromversorgung, Schalträume, Ersatzteillager. Solche Bereiche sollten nach Möglichkeit keinen Hinweis auf ihre Nutzung tragen. Türschilder wie z. B. „Rechenzentrum“ oder „EDV-Archiv“ geben einem potenziellen Angreifer, der zum Gebäude Zutritt hat, Hinweise, um seine Aktivitäten gezielter und damit Erfolg versprechender vorbereiten zu können.
Ist es unvermeidbar, IT in Räumen oder Gebäudebereichen unterzubringen, die für Fremde leicht von außen einsehbar sind (siehe auch 9.1.2 Anordnung schützenswerter Gebäudeteile), so sind geeignete Maßnahmen zu treffen, um den Einblick zu verhindern oder so zu gestalten, dass die Nutzung nicht offenbar wird. Dabei ist darauf zu achten, dass z. B. nicht nur ein Fenster einer ganzen Etage mit einem Sichtschutz versehen wird.

9.6.4 Geschlossene Fenster und Türen

Fenster und nach außen gehende Türen (Balkone, Terrassen) sind in Zeiten, in denen ein Raum nicht besetzt ist, zu schließen. Im Keller- und Erdgeschoss und, je nach Fassadengestaltung, auch in den höheren Etagen bieten sie EinbrecherInnen auch während der Betriebszeiten eine ideale Einstiegsmöglichkeit. Während normaler Arbeitszeiten und sichergestellter kurzer Abwesenheit der MitarbeiterInnen kann von einer zwingenden Regelung für Büroräume abgesehen werden. Auch nach innen gehende Türen nicht besetzter Räume sollten i. Allg. abgeschlossen werden. Dadurch wird verhindert, dass Unbefugte Zugriff auf darin befindliche Unterlagen und IT-Einrichtungen erlangen.
In manchen Fällen, z. B. in Großraumbüros, ist der Verschluss des Büros nicht möglich. In diesem Fall sollte alternativ sämtliche MitarbeiterInnen vor ihrer Abwesenheit Unterlagen und den persönlichen Arbeitsbereich (Schreibtisch, Schrank und PC (Schloss für Diskettenlaufwerk, Tastaturschloss, Telefon) verschließen (siehe auch 8.1.7 Clear-Desk-Policy).
Bei laufendem Rechner kann auf das Abschließen der Türen verzichtet werden, wenn eine Sicherungsmaßnahme installiert ist, mit der die Nutzung des Rechners nur unter Eingabe eines Passwortes weitergeführt werden kann (passwortunterstützte Bildschirmschoner), der Bildschirminhalt gelöscht wird und das Booten des Rechners die Eingabe eines Passwortes verlangt.
Bei ausgeschaltetem Rechner kann auf das Verschließen des Büros verzichtet werden, wenn die Inbetriebnahme des Gerätes die Eingabe eines Passwortes verlangt und sichergestellt ist, dass keine schutzbedürftigen Gegenstände wie Unterlagen oder Datenträger offen aufliegen.
Es muss auf jeden Fall sichergestellt werden, dass die Passworteingabe keinesfalls umgangen werden kann.

9.6.5 Alarmanlage

Ist eine Alarmanlage für Einbruch oder Brand vorhanden und lässt sich diese mit vertretbarem Aufwand entsprechend erweitern, ist zu überlegen, ob zumindest die Kernbereiche der IT (Serverräume, Datenträgerarchive, Räume für technische Infrastruktur u. ä.) in die Überwachung durch diese Anlage mit eingebunden werden sollen. So lassen sich Gefährdungen wie Feuer, Einbruch, Diebstahl frühzeitig erkennen und Gegenmaßnahmen einleiten. Um die Schutzwirkung aufrechtzuerhalten, ist eine regelmäßige Wartung und Funktionsprüfung der Alarmanlage vorzusehen.
Ist keine Alarmanlage vorhanden oder lässt sich die vorhandene nicht nutzen, kommen als Minimallösung lokale Melder in Betracht. Diese arbeiten völlig selbstständig, ohne Anschluss an eine Zentrale. Die Alarmierung erfolgt vor Ort oder mittels einer einfachen Zweidrahtleitung (evtl. Telefonleitung) an anderer Stelle.
Weiters ist zu beachten:
  • Die Alarmanlage muss regelmäßig gewartet bzw. geprüft werden.
  • Die zuständigen Personen sind über die im Alarmfall einzuleitenden Schritte zu unterrichten.
  • Besonders wirksam ist „Stiller Alarm mit Rückfrage“, dies erfordert jedoch zusätzlichen organisatorischen Aufwand.

9.6.6 Fernanzeige von Störungen

IT-Geräte und Supportgeräte, die keine oder nur seltene Bedienung durch eine Person erfordern, werden oft in ge- und verschlossenen Räumen untergebracht (z. B. Serverraum). Das führt dazu, dass Störungen, die sich in ihrem Frühstadium auf die IT noch nicht auswirken und einfach zu beheben sind, erst zu spät, meist durch ihre Auswirkungen auf die IT, entdeckt werden. Feuer, Funktionsstörungen einer USV oder der Ausfall eines Klimagerätes seien als Beispiele für solche „schleichenden“ Gefährdungen angeführt.
Durch eine Fernanzeige ist es möglich, solche Störungen früher zu erkennen. Viele Geräte, auf die man sich verlassen muss, ohne sie ständig prüfen oder beobachten zu können, haben heute einen Anschluss für Störungsfernanzeigen. Die technischen Möglichkeiten reichen dabei von einfachen Kontakten, über die eine Warnlampe eingeschaltet werden kann, bis zu Rechnerschnittstellen mit dazugehörigem Softwarepaket für die gängigen Betriebssysteme. Über die Schnittstellen ist es oft sogar möglich, jederzeit den aktuellen Betriebszustand der angeschlossenen Geräte festzustellen und so Ausfällen rechtzeitig begegnen zu können.

9.6.7 Klimatisierung

Um den zulässigen Betriebstemperaturbereich von IT-Geräten zu gewährleisten, reicht der normale Luft- und Wärmeaustausch eines Raumes manchmal nicht aus, so dass der Einbau einer Klimatisierung erforderlich wird. Deren Aufgabe ist es, die Raumtemperatur durch Kühlung unter dem von der IT vorgegebenen Höchstwert zu halten.
Werden darüber hinaus Forderungen an die Luftfeuchtigkeit gestellt, kann ein Klimagerät durch Be- und Entfeuchtung auch diese erfüllen. Dazu muss das Klimagerät allerdings an eine Wasserleitung angeschlossen werden. 9.4.6 Vermeidung von wasserführenden Leitungen ist zu beachten.
Zusätzlich ist zu beachten, dass die Luftumwälzung durch eine Klimaanlage auch Emissionen aus der Umgebung in die Nähe von empfindlichen IT-Komponenten bringen kann. So ist etwa bei baulichen Maßnahmen, insbesondere bei Umbauarbeiten in bestehenden Räumen und Gebäuden, darauf zu achten, dass Kleber, Anstriche etc. säurefrei sind, um eine Korrosion von IT-Bauteilen durch vorbeigeführte Luft aus der Klimaanlage zu vermeiden.
Um die Schutzwirkung aufrechtzuerhalten ist eine regelmäßige Wartung der Klimatisierungseinrichtung vorzusehen.

9.6.8 Selbsttätige Entwässerung

Alle Bereiche, in denen sich Wasser sammeln und stauen kann oder in denen fließendes oder stehendes Wasser nicht oder erst spät entdeckt wird und in denen das Wasser Schäden verursachen kann, sollten mit einer selbsttätigen Entwässerung und ggf. mit Wassermeldern ausgestattet sein. Zu diesen Bereichen gehören u. a. Keller, Lufträume unter Doppelböden, Lichtschächte und Heizungsanlagen.

9.6.9 Videounterstützte Überwachung

Zur besseren Absicherung der Infrastruktur sollte bei Bedarf auf ein videounterstütztes Überwachungssystem zurückgegriffen werden.
Derartige Überwachungssysteme stellen eine sinnvolle Ergänzung der bestehenden Maßnahmen (vgl. 9.6 Weitere Schutzmaßnahmen) dar. Bei geeigneter Aufstellung ist auch die von Überwachungskameras ausgehende Abschreckung ein Vorteil derartiger Systeme. Im Zuge der Konzeption und Installation müssen Personal sowie zusätzliche technische und infrastrukturelle Vorkehrungen zur Auswertung vorgesehen werden.
Die Wahl der Aufstellungsplätze der Kameras sollte unter Beiziehung des Betriebsrates und unter Berücksichtigung des Datenschutzes erfolgen.

9.6.10 Aktualität von Plänen

Sämtliche Pläne sind aktuell zu halten und an geeigneten Stellen zu deponieren.
Nach jedem Eingriff der eine Aktualisierung der Pläne erforderlich macht (bauliche Maßnahmen o.ä.), sind diese umgehend auf den aktuellen Stand zu bringen. In diesem Zuge sind auch alle in Umlauf befindlichen Kopien der Pläne durch aktualisierte Kopien zu ersetzen.

9.6.11 Vorgaben für ein Rechenzentrum

Ein Rechenzentrum gilt als schützenswert und sollte daher im Sinne eines Sicherheitsbereiches konzipiert sein.
In diesem Zusammenhang sind die in 9.1 Bauliche und infrastrukturelle Maßnahmen getroffenen Maßnahmen von besonderer Bedeutung. Aus diesem Katalog sollten folgende Punkte besonders beachtet werden:
Weiters ist zu beachten:

10 Sicherheitsmanagement in Kommunikation und Betrieb

Dieses Kapitel nimmt Bezug auf ISO/IEC 27002 10 „Management der Kommunikation und des Betriebs“.

10.1 IT-Sicherheitsmanagement

Informationssicherheitsmanagement steht für eine kontinuierliche Planungs- und Lenkungsaufgabe zur Umsetzung eines wirksamen Prozesses mit dem Ziel, ein umfassendes, angemessenes und konsistentes Informationssicherheitsniveau für die gesamte Organisation herzustellen und zu erhalten. Die Umsetzung der in diesem Kapitel angeführten Maßnahmen soll dies gewährleisten.

10.1.1 Etablierung eines IT-Sicherheitsmanagementprozesses

ISO Bezug: 27002 10.1
Methodisches Sicherheitsmanagement ist zur Gewährleistung umfassender und angemessener IT-Sicherheit unerlässlich. Der IT-Sicherheitsmanagementprozess ist daher ein integraler Bestandteil der organisationsweiten IT-Sicherheitspolitik (vgl. 10.1.2 Erarbeitung einer organisationsweiten IT-Sicherheitspolitik, und in dem Zusammenhang auch [IKTB-170902-8] ). Dabei handelt es sich um einen kontinuierlichen Prozess, der die Vertraulichkeit, Integrität, Verfügbarkeit, Zurechenbarkeit, Authentizität und Zuverlässigkeit von IT-Systemen gewährleisten soll. Dieser Prozess ist zumindest auf Ebene der Gesamtorganisation zu etablieren, über eine Durchführung auf der Ebene einzelner Organisationseinheiten ist im Einzelfall zu entscheiden.
Zu den Aufgaben des IT-Sicherheitsmanagements gehören:
  • Festlegung der IT-Sicherheitsziele, -strategien und -politiken der Organisation,
  • Festlegung der IT-Sicherheitsanforderungen,
  • Ermittlung und Analyse von Bedrohungen und Risiken,
  • Festlegung geeigneter Sicherheitsmaßnahmen,
  • Überwachung der Implementierung und des laufenden Betriebes der ausgewählten Maßnahmen,
  • Förderung des Sicherheitsbewusstseins innerhalb der Organisation sowie
  • Entdecken von und Reaktion auf sicherheitsrelevante Ereignisse.
Die folgende Graphik zeigt die wichtigsten Aktivitäten im Rahmen des Informationssicherheitsmanagements und die eventuell erforderlichen Rückkopplungen zwischen den einzelnen Stufen. In 2.1 Informationssicherheitsmanagement-Prozess werden die zur Etablierung eines umfassenden Informationssicherheitsmanagementprozesses erforderlichen Schritte detailliert beschrieben.

Abbildung 1: Aktivitäten im Rahmen des IT-Sicherheitsmanagements

[eh SMG 1.1]

10.1.2 Erarbeitung einer organisationsweiten Informationssicherheitspolitik

ISO Bezug: 27001 4.1
Als organisationsweite IT-Sicherheitspolitik 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 IT-Sicherheit festlegen.
Ressorts in der öffentlichen Verwaltung werden auf Basis des IKT-Board-Beschlusses [IKTB-170902-8] explizit zur Umsetzung einer Sicherheitspolitik angehalten.
Jede Organisation sollte eine in schriftlicher Form vorliegende IT-Sicherheitspolitik erarbeiten, die als langfristig gültiges Dokument zu betrachten ist.
Die organisationsweite Informationssicherheitspolitik soll allgemeine Festlegungen treffen, die für alle Einsatzbereiche der Informationstechnologie innerhalb einer Organisation zur Anwendung kommen und folgende Inhalte umfassen:
  • Grundsätzliche Ziele und Strategien
  • Organisation und Verantwortlichkeiten für IT-Sicherheit
  • Risikoanalysestrategien, akzeptables Restrisiko und Risikoakzeptanz
  • Klassifikation von Daten
  • Organisationsweite Richtlinien zu Sicherheitsmaßnahmen
  • Disaster Recovery-Planung
  • Nachfolgeaktivitäten zur Überprüfung und Aufrechterhaltung der Sicherheit
Details und Anleitungen zur Erstellung einer organisationsweiten IT-Sicherheitspolitik finden sich in 5 Informationssicherheitspolitik.
In diesem Zusammenhang sei auch auf die Österreichische Sicherheits- und Verteidigungsdoktrin – Teilstrategie IKT-Sicherheit [OESVD-IT] hingewiesen.
[eh SMG 1.2]

10.1.3 Erarbeitung von IT-Systemsicherheitspolitiken

ISO Bezug: 27001 4.1
Für jedes IT-System sollte eine IT-Systemsicherheitspolitik erarbeitet werden, welche
  • die grundlegenden Vorgaben und Leitlinien zur Sicherheit in diesem System definiert,
  • Details über die ausgewählten Sicherheitsmaßnahmen beschreibt und
  • die Gründe für die Auswahl der Sicherheitsmaßnahmen dargelegt.
Die IT-Systemsicherheitspolitik sollte Aussagen zu folgenden Bereichen treffen:
  • Definition und Abgrenzung des Systems, Beschreibung der wichtigsten Komponenten
  • Definition der wichtigsten Ziele und Funktionalitäten des Systems
  • Festlegung der IT-Sicherheitsziele des Systems
  • Abhängigkeit der Organisation vom betrachteten IT-System
  • Investitionen in das System
  • Risikoanalysestrategie
  • Werte, Bedrohungen und Schwachstellen lt. Risikoanalyse
  • Sicherheitsrisiken
  • Beschreibung der bestehenden und der noch zu realisierenden Sicherheitsmaßnahmen
  • Gründe für die Auswahl der Maßnahmen
  • Kostenschätzungen für die Realisierung und Wartung (Aufrechterhaltung) der Sicherheitsmaßnahmen
  • Verantwortlichkeiten
Details und Anleitungen zur Erstellung von IT-Systemsicherheitspolitiken finden sich in 5 Informationssicherheitspolitik.
[eh SMG 1.3]

10.1.4 Festlegung von Verantwortlichkeiten

ISO Bezug: 27002 10.1.1, 10.1.3
Um eine Berücksichtigung aller wichtigen Sicherheitsaspekte und eine effiziente Erledigung sämtlicher anfallender Aufgaben zu gewährleisten, ist es erforderlich, die Rollen aller in den IT-Sicherheitsprozess involvierten Personen klar zu definieren.
Diese Festlegung erfolgt zweckmäßig im Rahmen der organisationsweiten IT-Sicherheitspolitik (vgl. 10.1.2 Erarbeitung einer organisationsweiten Informationssicherheitspolitik und 5 Informationssicherheitspolitik).
Es empfiehlt sich, darüber hinaus detaillierte Regelungen zu folgenden Bereichen zu treffen:
  • Datensicherung,
  • Datenarchivierung,
  • Datenübertragung,
  • Dokumentation von IT-Verfahren, Software, IT-Konfiguration,
  • Zutritts-, Zugangs- und Zugriffsberechtigungen,
  • Datenträger- und Betriebsmittelverwaltung,
  • Anwendungsentwicklung,
  • Kauf und Leasing von Hardware und Software,
  • Abnahme und Freigabe von Software,
  • Wartungs- und Reparaturarbeiten,
  • Datenschutz,
  • Schutz gegen Software mit Schadensfunktion (Viren, Würmer, trojanische Pferde, …)
  • Revision,
  • Notfallvorsorge und
  • Vorgehensweise bei Verletzung der Sicherheitspolitik.
Nähere Erläuterungen dazu finden sich in den nachfolgenden Maßnahmenbeschreibungen.
Weiters ist zu beachten:
  • Die Regelungen sind den betroffenen MitarbeiterInnen in geeigneter Weise bekannt zu geben.
  • Sämtliche Regelungen sind in der aktuellen Form an einer Stelle vorzuhalten und bei berechtigtem Interesse zugänglich zu machen.
  • Es empfiehlt sich, die Bekanntgabe zu dokumentieren.
  • Die getroffenen Regelungen sind regelmäßig zu aktualisieren, um Missverständnisse, ungeklärte Zuständigkeiten und Widersprüche zu verhindern.
[eh SMG 1.4]

10.1.5 Funktionstrennung

ISO Bezug: 27002 10.1.3, 10.1.4
Im Rahmen der Zuordnung von Aufgaben und Verantwortlichkeiten ist auch festzulegen, welche Funktionen nicht miteinander vereinbar sind, also auch nicht von einer Person gleichzeitig wahrgenommen werden dürfen („Funktionstrennung“).
Vorgaben hierfür können aus den Aufgaben selbst oder aus gesetzlichen Bestimmungen resultieren. Beispiele dafür sind:
  • Rechteverwaltung und Revision,
  • Netzadministration und Revision,
  • Programmierung und Test bei eigenerstellter Software,
  • Datenerfassung und Zahlungsanordnungsbefugnis,
  • Revision und Zahlungsanordnungsbefugnis.
Insbesondere wird deutlich, dass meistens operative Funktionen nicht mit kontrollierenden Funktionen vereinbar sind.
Nach der Festlegung der einzuhaltenden Funktionstrennung kann die Zuordnung der Funktionen zu Personen erfolgen. Die dabei getroffenen Festlegungen sind zu dokumentieren und bei Veränderungen im IT-Einsatz zu aktualisieren. Sollte bei dieser Zuordnung eine Person miteinander unvereinbare Funktionen wahrnehmen müssen, so ist dies in einer entsprechenden Dokumentation über die Funktionsverteilung besonders hervorzuheben.
[eh SMG 1.5]

10.1.6 Einrichtung von Standardarbeitsplätzen

ISO Bezug: 27002 10.1.1
Ein Standardarbeitsplatz ist gekennzeichnet durch einheitliche Hardware und Software sowie deren Konfiguration. Die Planung und Einrichtung erfolgt üblicherweise unter den Aspekten der Aufgabenstellung, Zuverlässigkeit, Ergonomie, Geschwindigkeit und Wartbarkeit. Sie wird durch fachkundiges Personal durchgeführt.
In Anlehnung an den IKT-Board-Beschluss vom 17.09.2002 [IKTB-170902-7] wird die Verwendung und Umsetzung einer sicheren Initialkonfiguration bei der Auslieferung von Systemen im Bundesbereich empfohlen. Dadurch soll das Vertrauen in das Grundsystem gestärkt werden.
Die Einrichtung von Standardarbeitsplätzen ist in mehrfacher Hinsicht vorteilhaft:
IT-Sicherheit:
  • Standardarbeitsplätze sind leichter in Sicherheitskonzepte einzubinden.
  • Der Aufwand für die Dokumentation des IT-Bestandes wird reduziert.
IT-Management:
  • Die Beschaffung größerer Stückzahlen gleicher Komponenten ermöglicht Preisvorteile.
  • Der Einsatz nicht zulässiger Software ist einfacher festzustellen.
  • Durch gleiche IT-Ausstattung entfallen „Neidfaktoren“ zwischen den einzelnen BenutzerInnen.
IT-NutzerInnen:
  • Bei Gerätewechsel ist keine erneute Einweisung in die IT-Konfiguration erforderlich, Ausfallzeiten werden somit minimiert.
  • Bei Fragen zu Hard- und Software können sich AnwenderInnen gegenseitig helfen.
Systemadministration bei Installation und Wartung:
  • Eine gewissenhaft geplante und getestete Installation kann fehlerfrei und mit geringem Arbeitsaufwand installiert werden.
  • Die einheitliche Arbeitsumgebung erleichtert Wartung und Support.
Schulung:
  • Die TeilnehmerInnen werden in dem Umfeld geschult, das sie am Arbeitsplatz vorfinden.
[eh SMG 1.6]

10.1.7 Akkreditierung von IT-Systemen

ISO Bezug: 27002 10.3.2
Für jedes IT-System ist sicherzustellen, dass es den Anforderungen der IT-Systemsicherheitspolitik genügt.
Dabei ist insbesondere darauf zu achten, dass die Sicherheit des Systems
  • in einer bestimmten Betriebsumgebung,
  • unter bestimmten Einsatzbedingungen und
  • für eine bestimmte vorgegebene Zeitspanne
gewährleistet ist.
Erst nach erfolgter Akkreditierung kann das System - oder gegebenenfalls eine spezifische Anwendung - in Echtbetrieb gehen.
Techniken zur Akkreditierung sind:
Ä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 der IT-Systemsicherheitspolitik festgelegt werden.
[eh SMG 1.7]

10.1.8 Change Management

ISO Bezug: 27002 10.1.2, 12.5
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.
Im Rahmen des Konfigurationsmanagements ist sicherzustellen, dass Änderungen an einem IT-System nicht zu einer Verringerung der Effizienz von einzelnen Sicherheitsmaßnahmen und damit einer Gefährdung der Gesamtsicherheit führen.
[eh T2 6.3]

10.1.8.1 Reaktion auf Änderungen am IT-System

ISO Bezug: 27002 10.1.2
Es ist dafür Sorge zu tragen, dass auf alle sicherheitsrelevanten Änderungen angemessen reagiert wird.
Dazu gehören zum Beispiel:
  • Änderungen des IT-Systems (neue Applikationen, neue Hardware, neue Netzwerkverbindungen, …),
  • Änderungen in der Aufgabenstellung oder in der Wichtigkeit der Aufgabe für die Institution,
  • Änderungen in der Benutzerstruktur (neue, etwa externe oder anonyme, Benutzergruppen),
  • räumliche Änderungen, z. B. nach einem Umzug,
  • Änderungen in der Bewertung der eingesetzten IT, der notwendigen Vertraulichkeit, Integrität oder Verfügbarkeit und
  • Änderungen bei Bedrohungen oder Schwachstellen.
Alle Änderungen und die dazugehörigen Entscheidungsgrundlagen sind schriftlich zu dokumentieren.
Abhängig von der Bedeutung des Systems und dem Grad der Änderung kann eine neuerliche Durchführung vorangegangener Aktivitäten im Sicherheitsprozess (vgl. 10.1.1 Etablierung eines IT-Sicherheitsmanagementprozesses erforderlich werden.
Eine Änderung des IT-Systems oder seiner Einsatzbedingungen kann also
  • Änderungen in der Umsetzung des Informationssicherheitsplans,
  • die Erstellung eines neuen Sicherheitskonzeptes,
  • eine neue Risikoanalyse oder sogar
  • die Überarbeitung der organisationsweiten Informationssicherheitspolitik
erforderlich machen.
[eh BET 3.1]

10.1.8.2 Softwareänderungskontrolle

ISO Bezug: 27002 10.1.2, 10.2.3, 12.5.1, 12.5.2
Softwareänderungskontrolle (Software Change Control) ist der Teil des Change Managements, der sich auf die Gewährleistung der Integrität von Software bei Änderungen bezieht.
Es ist sicherzustellen, dass
Für komplexe Eigenentwicklungen empfiehlt sich die Erstellung eines „Softwarepflege- und -änderungskonzeptes“ (SWPÄ-Konzept, vgl. 12.3.6 Softwarepflege- und -änderungskonzept).
[eh BET 3.2]

10.2 Dokumentation

Die im Folgenden angeführten Maßnahmen geben grobe Richtlinien zu den Anforderungen an die Dokumentation. Dabei wird insbesondere auf die sicherheitsspezifischen Fragen im Rahmen der Dokumentation eingegangen. Die Ausführungen orientieren sich an den „Allgemeinen Vertragsbedingungen der Republik Österreich für IT-Leistungen“ [AVB-IT], dem „Vorgehensmodell für die Entwicklung von IT-Systemen des Bundes“ [IT-BVM] sowie den [Common Criteria]. In den genannten Dokumenten finden sich auch weitere Details.

10.2.1 Dokumentation von Software

ISO Bezug: 27002 10.1.1, 10.7.4
Für jede Softwarekomponente ist die Verfügbarkeit der zu ihrer Nutzung erforderlichen und zweckmäßigen Dokumentation sicherzustellen.
Dabei ist zu achten auf:
  • die Vollständigkeit und Korrektheit der gelieferten Dokumentation und
  • die laufende Aktualisierung der Dokumentation während der gesamten Nutzungsdauer der Software.
Die Dokumentation muss zumindest beinhalten:
  • Benutzerdokumentation
  • Dokumentation für Installation und Administration
Darüber hinaus können je nach Bedarf folgende Anforderungen bestehen:
  • technische Dokumentation
  • Entwicklungsdokumentation

Benutzerdokumentation:

Bei der Benutzerdokumentation (in den [IT-BVM] als „Anwendungshandbuch“ bezeichnet) handelt es sich um Information über die Software, die die EntwicklerInnen den BenutzerInnen zur Verwendung bereitstellen.
Die Benutzerdokumentation hat alle für die laufende Arbeit notwendigen Abläufe so zu beschreiben, dass sie für eine eingeschulte Person verständlich sind. Daneben hat die Dokumentation typische und vorhersehbare Fehlersituationen und deren Behebung zu beschreiben.
Aus sicherheitstechnischer Sicht soll die Benutzerdokumentation den EndbenutzerInnen helfen,
  • die Sicherheitseigenschaften der Software sowie
  • den Beitrag der EndbenutzerInnen zur Gewährleistung der Sicherheit bei der Verwendung der Software
zu verstehen.
Die Benutzerdokumentation sollte in deutscher Sprache vorliegen. Dies kann und sollte auch vertraglich festgelegt werden (vgl. etwa [AVB-IT]).
Ebenso empfiehlt sich eine Vereinbarung über die Lieferung der Dokumentation zusätzlich in maschinenlesbarer Form, so dass diese an definierten Arbeitsplätzen während der Arbeit abgerufen werden kann.

Dokumentation für Installation und Administration:

Bei dieser Dokumentation handelt es sich um Information über die erforderlichen Maßnahmen zur Aufnahme des Betriebs, zur Durchführung und Überwachung des Betriebs und zur Unterbrechung und Beendigung des Betriebs. Sie soll AdministratorInnen helfen, die Software in einer sicheren Art und Weise zu installieren, zu konfigurieren und zu bedienen.
Die Dokumentation für die Installation und Administration (im Folgenden kurz als „Administratordokumentation“, in den [IT-BVM] als „Betriebshandbuch“ bezeichnet) hat alle für die Installation und die laufende Verwaltung des Systems notwendigen Abläufe so zu beschreiben, dass sie für eine eingeschulte Person verständlich sind. Daneben hat die Dokumentation typische und vorhersehbare Fehlersituationen und deren Behebung zu beschreiben.
Aus sicherheitstechnischer Sicht muss die Administratordokumentation die sicherheitsspezifischen Funktionen darlegen, die für AdministratorInnen von Bedeutung sind. Darüber hinaus muss sie Richtlinien zur konsistenten und wirksamen Nutzung der Sicherheitseigenschaften der Software enthalten und darlegen, wie solche Eigenschaften zusammenwirken.

Technische Dokumentation:

Diese muss den zum Zeitpunkt der Installation der Software üblichen Standards entsprechen und so gestaltet sein, dass sie für mit ähnlichen Komponenten vertraute ExpertInnen verständlich und verwertbar ist.
[eh ENT 2.1]

10.2.2 Sourcecodehinterlegung

ISO Bezug: 27002 10.1.1, 12.4.3
Im Falle einer Lieferung von Software, bei der der Sourcecode nicht mitgeliefert wird, sollte nach Möglichkeit - insbesondere bei der Entwicklung von Individualsoftware - Sourcecodehinterlegung vereinbart werden.
Diese soll die Möglichkeit einer weiteren Fehlerbehebung, Änderung und Wartung von Software für den Fall der Handlungsunfähigkeit des Softwareherstellers und den Fall der Einstellung der Weiterentwicklung oder Wartung sicherstellen.

Durchführung:

Die AuftragnehmerInnen (SW-Hersteller) stellen die Software auf einem Datenträger, der auf dem System der/des Auftraggeberin/Auftraggebers gelesen werden kann, in der Quellensprache bereit, übersetzen sie in Maschinencode und nehmen die Installation auf dem System vor.
Nach der Installation wird der Datenträger mit dem Quellencode samt der dazugehörigen Dokumentation (Inhalt und Aufbau des Datenträgers, Programm und Datenflusspläne, Testverfahren, Testprogramme, Fehlerbehandlung usw.) von den AuftragnehmerInnen versiegelt und bei den AuftraggeberInnen oder vertrauenswürdigen Dritten (z. B. NotarInnen) hinterlegt.
Tritt beim Hersteller Handlungsunfähigkeit (etwa Liquidation, Eröffnung eines Konkursverfahrens, …) ein oder stellt sie/er entgegen anders lautenden Vereinbarungen die Weiterentwicklung oder Wartung der Software ein, so sind die AuftraggeberInnen berechtigt, die hinterlegten Datenträger zu entnehmen und entweder ein sachkundiges Unternehmen mit den erforderlichen weiteren Arbeiten (Wartung, Fehlerbehebung, …) zu beauftragen oder diese selbst durchzuführen.
Dabei ist zu beachten:
  • Der Datenträger muss die Software in den ursprünglichen Programmiersprachen zum Zeitpunkt der Installation einschließlich aller seitherigen Änderungen enthalten.
  • Der Datenträger muss die in maschinenlesbarer Form vorliegende Dokumentation enthalten.
  • Es ist eine Aufstellung der versiegelt hinterlegten Gegenstände sowie eine Anweisung über die Handhabung des Datenträgers und die Installation der Software beizulegen.
  • Die Hinterlegung muss bei jeder Lieferung einer neuen Version wiederholt werden, auf die Aktualität aller Komponenten sowie der Dokumentation ist zu achten.
Ein Vorschlag zur Formulierung einer entsprechenden vertraglichen Vereinbarung findet sich in den Allgemeinen Vertragsbedingungen der Republik Österreich für IT-Leistungen [AVB-IT] (siehe B.1 Sourcecodehinterlegung (Muster, aus AVB-IT)).
[eh ENT 2.2]

10.2.3 Dokumentation der Systemkonfiguration

ISO Bezug: 27002 10.1.1, 10.7.4
Planung, Steuerung, Kontrolle und Notfallvorsorge des IT-Einsatzes basieren auf einer aktuellen Dokumentation des vorhandenen IT-Systems. Nur eine aktuelle Dokumentation der Systemkonfiguration ermöglicht im Notfall einen geordneten Wiederanlauf des IT-Systems.
Bei einem Netzbetrieb sind sowohl die physikalische Netzstruktur (vgl. 10.2.5 Dokumentation und Kennzeichnung der Verkabelung) als auch die logische Netzkonfiguration zu dokumentieren. Dazu gehören auch die Zugriffsrechte der einzelnen BenutzerInnen (siehe 11.2.2 Einrichtung und Dokumentation der zugelassenen BenutzerInnen und Rechteprofile) und der Stand der Datensicherung.
Dabei ist zu beachten:
  • Die Dokumentation muss aktuell und verständlich sein, damit auch VertreterInnen die Administration jederzeit weiterführen können. Dies gilt insbesondere für Änderungen an Systemverzeichnissen und -dateien.
  • Bei Installation neuer Betriebssysteme oder bei Updates sind die vorgenommenen Änderungen besonders sorgfältig zu dokumentieren. Möglicherweise kann durch die Aktivierung neuer oder durch die Änderung bestehender Systemparameter das Verhalten des IT-Systems (insbesondere auch von Sicherheitsfunktionen) maßgeblich verändert werden.
  • Um das Vertrauen in Betriebssysteme zu sichern, ist generell eine so genannte Vertrauenseinstellung im Zuge der Neuinstallation/-konfiguration vorzunehmen. Speziell im Bundesbereich ist gemäß [IKTB-170902-7] eine definierte sichere Initialkonfiguration zu verwenden. Deren Anwendung ist allerdings auch generell zu empfehlen. Eine entsprechend dokumentierte Initialkonfiguration wird im Rahmen des Online-Angebotes des Chief Information Office des Bundes zur Verfügung stehen. In diesem Zusammenhang: siehe auch 11.5.1 Sichere Initialkonfiguration und Zertifikatsgrundeinstellung.
  • Die Unterlagen sind gesichert aufzubewahren, so dass ihre Verfügbarkeit im Bedarfsfall gewährleistet ist.
[eh ENT 2.3]

10.2.4 Dokumentation der Datensicherung

ISO Bezug: 27002 10.5.1
In einem Datensicherungskonzept muss festgelegt werden, wie die Dokumentation der Datensicherung zu erfolgen hat (vgl. 10.5 Datensicherung).
Zur Gewährleistung einer ordnungsgemäßen und funktionierenden Datensicherung ist eine Dokumentation erforderlich, die für jedes IT-System zumindest folgendes umfassen soll:
  • das Datum der Datensicherung,
  • der Datensicherungsumfang (welche Dateien/Verzeichnisse wurden gesichert),
  • der Datenträger, auf dem die Daten im operativen Betrieb gespeichert sind,
  • der Datenträger, auf dem die Daten gesichert wurden,
  • die für die Datensicherung eingesetzte Hard- und Software (mit Versionsnummer) und
  • die bei der Datensicherung gewählten Parameter (Art der Datensicherung usw.).
Darüber hinaus bedarf es einer Beschreibung der Vorgehensweise, die sachverständigen Dritten eine Wiederherstellung eines Datensicherungsbestandes erlaubt. Auch hier muss eine Beschreibung der erforderlichen Hard- und Software, der benötigten Parameter und der Vorgehensweise, nach der die Datenrekonstruktion zu erfolgen hat, erstellt werden.
[eh ENT 2.6]

10.2.5 Dokumentation und Kennzeichnung der Verkabelung

ISO Bezug: 27002 10.1.1, 9.2.3
Für Wartung, Fehlersuche, Instandsetzung und für erfolgreiche Überprüfung der Verkabelung ist eine gute Dokumentation und eindeutige Kennzeichnung aller Kabel erforderlich. Die Güte dieser Revisionsdokumentation ist abhängig von der Vollständigkeit, der Aktualität und der Lesbarkeit.
In dieser Dokumentation (auch Bestandsplan genannt) sind alle das Netz betreffenden Sachverhalte aufzunehmen:
  • genauer Kabeltyp,
  • nutzungsorientierte Kabelkennzeichnung,
  • Standorte von zentralen Knoten und Verteilern mit genauen Bezeichnungen,
  • genaue Führung von Kabeln und Trassen in der Liegenschaft (Einzeichnung in bemaßte Grundriss- und Lagepläne),
  • Trassendimensionierung und -belegung,
  • Belegungspläne aller Rangierungen und Verteiler,
  • Nutzung aller Leitungen, Nennung der daran angeschlossenen NetzteilnehmerInnen,
  • technische Daten von Anschlusspunkten,
  • Gefahrenpunkte,
  • vorhandene und zu prüfende Schutzmaßnahmen.
Es muss möglich sein, sich anhand dieser Dokumentation einfach und schnell ein genaues Bild über die Verkabelung zu machen.
Da es mit zunehmender Größe eines Netzes nicht möglich ist, alle Informationen in einem Plan unterzubringen, ist eine Aufteilung der Informationen sinnvoll. Tatsächliche Lageinformationen sind immer in maßstäbliche Pläne einzuzeichnen, andere Informationen können in Tabellenform geführt werden. Wichtig dabei ist eine eindeutige Zuordnung aller Angaben untereinander.
Um die Aktualität der Dokumentation zu gewährleisten, ist sicherzustellen, dass alle Arbeiten am Netz denjenigen rechtzeitig und vollständig bekannt werden, die die Dokumentation führen. Es ist z. B. denkbar, die Ausgabe von Material, die Vergabe von Fremdaufträgen oder die Freigabe gesicherter Bereiche von der Mitzeichnung dieser Personen abhängig zu machen.
Da diese Dokumentation schutzwürdige Informationen beinhaltet, ist sie sicher aufzubewahren und der Zugriff darauf zu regeln.
[eh ENT 2.4]

10.2.6 Neutrale Dokumentation in den Verteilern

ISO Bezug: 27002 10.1.1, 9.2.3
In jedem Verteiler sollte sich eine Dokumentation befinden, die den aktuellen Stand von Rangierungen und Leitungsbelegungen wiedergibt. Diese Dokumentation ist möglichst neutral zu halten. Nur bestehende und genutzte Verbindungen sind darin aufzuführen. Es sollen, soweit nicht ausdrücklich vorgeschrieben (z. B. für Brandmeldeleitungen) keine Hinweise auf die Nutzungsart der Leitungen gegeben werden. Leitungs-, Verteiler-, und Raumnummern reichen in vielen Fällen aus. Alle weitergehenden Informationen sind in einer Revisionsdokumentation aufzuführen.
Es ist auf Aktualität, Vollständigkeit und Korrektheit dieser Information zu achten.
[eh ENT 2.5]

10.3 Dienstleistungen durch Dritte (Outsourcing)

ISO Bezug: 27002 10.2
Beim Outsourcing werden Arbeits- oder Geschäftsprozesse einer Organisation ganz oder teilweise zu externen Dienstleistern ausgelagert. Outsourcing kann sowohl Nutzung und Betrieb von Hardware und Software, aber auch Dienstleistungen betreffen. Dabei ist es unerheblich, ob die Leistung in den Räumlichkeiten des Auftraggebers oder in einer externen Betriebsstätte des Outsourcing-Dienstleisters erbracht wird. Typische Beispiele sind der Betrieb eines Rechenzentrums, einer Applikation, einer Webseite oder des Wachdienstes.

Outsourcing ist ein Oberbegriff, der oftmals durch weitere Begriffe ergänzt wird: Tasksourcing bezeichnet das Auslagern von Teilbereichen. Werden Dienstleistungen mit Bezug zur IT-Sicherheit ausgelagert, wird von Security Outsourcing oder Managed Security Services gesprochen. Beispiele sind die Auslagerung des Firewall-Betriebs, die Überwachung des Netzes, Virenschutz oder der Betrieb eines Virtual Private Networks (VPN). Unter Application Service Provider (ASP) versteht man einen Dienstleister, der auf seinen eigenen Systemen einzelne Anwendungen oder Software für seine Kunden betreibt (E-Mail, SAP-Anwendungen, Archivierung, Web-Shops, Beschaffung). Auftraggeber und Dienstleister sind dabei über das Internet oder ein VPN miteinander verbunden. Beim Application Hosting ist ebenfalls der Betrieb von Anwendungen an einen Dienstleister ausgelagert, jedoch gehören im Gegensatz zum ASP-Modell die Anwendungen noch dem jeweiligen Kunden. Da die Grenzen zwischen klassischem Outsourcing und reinem ASP in der Praxis zunehmend verschwimmen, wird im Folgenden nur noch der Oberbegriff Outsourcing verwendet. Das Auslagern von Geschäfts- und Produktionsprozessen ist ein etablierter Bestandteil heutiger Organisationsstrategien. Speziell in den letzten beiden Jahrzehnten hat sich der Trend zum Outsourcing enorm verstärkt, und dieser scheint auch für die nächste Zukunft ungebrochen. Es gibt aber inzwischen auch publizierte Beispiele für gescheiterte Outsourcing-Projekte, wo der Auftraggeber den Outsourcing-Vertrag gekündigt hat und die ausgelagerten Geschäftsprozesse wieder in Eigenregie betreibt (Insourcing). Die Gründe für Outsourcing sind vielfältig: die Konzentration einer Organisation auf ihre Kernkompetenzen, die Möglichkeit einer Kostenersparnis (z. B. keine Anschaffungs- oder Betriebskosten für IT-Systeme), der Zugriff auf spezialisierte Kenntnisse und Ressourcen, die Freisetzung interner Ressourcen für andere Aufgaben, die Straffung der internen Verwaltung, die verbesserte Skalierbarkeit der Geschäfts- und Produktionsprozesse, die Erhöhung der Flexibilität sowie der Wettbewerbsfähigkeit einer Organisation sind nur einige Beispiele. Beim Auslagern von IT-gestützten Organisationsprozessen werden die IT-Systeme und Netze der auslagernden Organisation und ihres Outsourcing-Dienstleisters in der Regel eng miteinander verbunden, so dass Teile von internen Geschäftsprozessen unter Leitung und Kontrolle eines externen Dienstleisters ablaufen. Ebenso findet auf personeller Ebene ein intensiver Kontakt statt. Durch die enge Verbindung zum Dienstleister und die entstehende Abhängigkeit von der Dienstleistungsqualität ergeben sich Risiken für den Auftraggeber, durch die im schlimmsten Fall sogar die Geschäftsgrundlage des Unternehmens oder der Behörde vital gefährdet werden können (beispielsweise könnten sensitive Organisationsinformationen gewollt oder ungewollt nach außen preisgegeben werden). Der Betrachtung von Sicherheitsaspekten und der Gestaltung vertraglicher Regelungen zwischen Auftraggeber und Outsourcing-Dienstleister kommt im Rahmen eines Outsourcing-Vorhabens somit eine zentrale Rolle zu. Den Schwerpunkt dieses Bausteins bilden daher Maßnahmen, die sich mit IT-Sicherheitsaspekten des Outsourcings beschäftigen. Dazu zählen ebenfalls geeignete Maßnahmen zur Kontrolle der vertraglich vereinbarten Ziele und Leistungen sowie der IT-Sicherheitsmaßnahmen.

Die Gefährdungslage eines Outsourcing-Vorhabens ist ausgesprochen vielschichtig, siehe dazu 6.2.2 Gefährdungen beim Outsorcing.

10.3.1 Festlegung einer Outsourcing-Strategie

ISO Bezug: 27002 10.2
Die Bindung an einen Outsourcing-Dienstleister erfolgt auf lange Sicht, ist zunächst kostenintensiv und mit Risiken verbunden. Eine gute Planung des Outsourcing-Vorhabens ist daher wichtig. Dabei müssen neben den wirtschaftlichen, technischen und organisatorischen Randbedingungen auch die sicherheitsrelevanten Aspekte bedacht werden.

Folgende Gesichtspunkte sollten betrachtet werden:
  • Unternehmensstrategie (Flexibilität, Abhängigkeiten, zukünftige Planungen),
  • Machbarkeitsstudie mit Zusammenstellung der Rahmenbedingungen,
  • betriebswirtschaftliche Aspekte mit Kosten-Nutzen-Abschätzung.

Nach ersten strategischen Überlegungen muss zunächst geklärt werden, welche Aufgaben oder IT-Anwendungen generell für Outsourcing in Frage kommen.
Dabei darf die Bedeutung der rechtlichen Rahmenbedingungen nicht unterschätzt werden. Gesetze könnten beispielsweise das Auslagern bestimmter Kernaufgaben einer Institution generell verbieten oder zumindest weitreichende Auflagen enthalten und die Beteiligung von Aufsichtsbehörden vorschreiben. In der Regel bleibt der Auftraggeber weiterhin gegenüber seinen Kunden oder staatlichen Stellen voll verantwortlich für Dienstleistungen oder Produkte, unabhängig davon, ob einzelne Aufgabenbereiche ausgelagert wurden.

Die IT-Sicherheit wird leider häufig zu Beginn der Planung vernachlässigt, obwohl ihr eine zentrale Bedeutung zukommt. Dies gilt sowohl für technische als auch organisatorische Sicherheitsaspekte, denen im Outsourcing-Szenario eine entscheidende Rolle zukommt. Generell ist nämlich zu bedenken:
  • Die Entscheidung zum Outsourcing ist in der Regel nicht einfach zu revidieren. Die Bindung an den Dienstleister erfolgt unter Umständen sehr langfristig.
  • Der Dienstleister hat Zugriff auf Daten und IT-Ressourcen des Auftraggebers. Der Outsourcing-Auftraggeber verliert dadurch die alleinige und vollständige Kontrolle über Daten und Ressourcen. Je nach Outsourcing-Vorhaben betrifft dies dann auch Daten mit hohem Schutzbedarf.
  • Für die technische Umsetzung des Outsourcing-Vorhabens ist es notwendig, dass zwischen Auftraggeber und Dienstleister Daten übertragen werden. Dadurch ergibt sich automatisch ein erhöhtes Gefahrenpotenzial.
  • In der Regel ist es erforderlich, dass Mitarbeiter oder Subunternehmer des Outsourcing-Dienstleisters (und damit Betriebsfremde) zeitweise in den Räumlichkeiten des Auftraggebers arbeiten müssen. Auch dadurch ergibt sich ein erhöhtes Gefahrenpotenzial.
  • Im Rahmen eines Outsourcing-Vorhabens müssen neue Prozesse und Arbeitsabläufe entworfen, eingeführt und durchgeführt werden. Die Folgen der notwendigen Umstellungen müssen geklärt und abgeschätzt werden.
  • Für jeden Outsourcing-Dienstleister besteht ein nicht zu unterschätzender Interessenskonflikt: Einerseits muss er die Dienstleistung möglichst kostengünstig erbringen, um seinen Gewinn zu maximieren, andererseits erwartet der Auftraggeber hohe Dienstleistungsqualität, Flexibilität und kundenfreundliches Verhalten. Dieser Punkt ist erfahrungsgemäß der am häufigsten unterschätzte. Während IT-ManagerInnen in der Regel sehr kritisch und kostenbewusst sind und Versprechungen von Herstellern und Beratern mit großer Skepsis begegnen, ist beim Outsourcing leider oft das Gegenteil zu beobachten. Allzu leicht verfällt hier der Auftraggeber den Werbeaussagen der Dienstleister in der frohen Erwartung, seine IT-Kosten signifikant senken zu können. Die Praxis lehrt jedoch, dass höchstens die Dienstleistungen in der Zukunft erbracht werden, die von Anfang an vertraglich fixiert worden sind. Stellt sich heraus, dass die Dienstleistungsqualität unzureichend ist, weil der Auftraggeber Leistungen erwartet, die er - im Gegensatz zum Outsourcing-Dienstleister - als selbstverständlich erachtet, sind Nachbesserungen in der Regel ohne hohe zusätzliche Kosten nicht zu erwarten. Alle IT-ManagerInnen, die über Outsourcing nachdenken, sollten sich die Mühe machen nachzurechnen, zu welchen Kosten ein Dienstleister die vereinbarte Leistung erbringen muss, damit Auftraggeber und Auftragnehmer beide von dem Vertragsverhältnis profitieren. Bei dieser Rechnung stellt sich vielleicht heraus, dass eine seriöse Leistungserbringung zu den versprochenen niedrigen Kosten höchst unwahrscheinlich ist.

Um die Outsourcing-Strategie festzulegen, muss daher immer eine individuelle Sicherheitsanalyse durchgeführt werden. Nur so kann letztendlich festgestellt werden, wie bestehende IT-Systeme abgegrenzt und getrennt werden können, damit Teile davon ausgelagert werden können. In dieser frühen Projektphase wird das Sicherheitskonzept naturgemäß nur Rahmenbedingungen beschreiben und keine detaillierten Maßnahmen enthalten. Sind die sicherheitsrelevanten Gefährdungen analysiert worden, kann festgelegt werden, ob und wie diesen begegnet werden soll. Schlussendlich wird dennoch ein gewisses Restrisiko durch den Outsourcing-Auftraggeber zu tragen sein. Die Ergebnisse der Sicherheitsanalyse gehen unmittelbar in die Kosten-Nutzen-Abschätzung ein.

Das Management darf bei der Entwicklung einer erfolgversprechenden, langfristigen Outsourcing-Strategie den Blick nicht nur auf die Einsparung von Kosten richten. Die Auswirkungen eines Outsourcing-Vorhabens auf die Aufgabenerfüllung, das Geschäftsmodell und das Dienstleistungs- oder Produktportfolio müssen ebenfalls berücksichtigt werden. Sollen Standardabläufe oder Kerngeschäftsprozesse ausgelagert werden? Wichtig ist in diesem Zusammenhang, dass die Fähigkeit, Anforderungen an die IT selbst zu bestimmen und zu kontrollieren in ausreichendem Maße erhalten werden. Insbesondere an die Weiterentwicklung und Pflege selbstentwickelter IT-Systeme und Anwendungen sollte gedacht werden.

Die nachfolgenden Hinweise beleuchten Vor- und Nachteile von Outsourcing mit Bezug zur IT-Sicherheit.
  • Vorteil: Es besteht die Möglichkeit, neue Dienstleistungen (z. B. durch Diversifikation oder Ausweitung der Produktpalette) zu etablieren. In der Folge muss das festgelegte Sicherheitsniveau jedoch auch für das ausgeweitete Angebot sichergestellt werden.
  • Vorteil: Es besteht mehr Flexibilität, beispielsweise können Systeme, Ressourcen oder der Personalbedarf schneller angepasst bzw. erweitert werden, da dies vom Outsourcing-Dienstleister unter Umständen auch kurzfristig eingekauft werden kann. Fixe Kosten können so in variable umgewandelt werden. In Folge können sich jedoch durch die Erweiterungen (z. B. von IT-Systemen) auch neue Sicherheitsprobleme ergeben.
  • Vorteil: Im Idealfall kann durch das Outsourcing-Vorhaben ein besseres IT-Sicherheitsniveau erreicht werden, da der Dienstleister Spezialisten beschäftigt, so dass dadurch auch neue, sicherheitskritische Anwendungen betrieben werden können. Gerade in der IT-Sicherheit ist es sehr zeitaufwändig und benötigt viel technisches Wissen, regelmäßig die Flut an Sicherheitshinweisen, Security-Bulletins, Updatemeldungen und Bug-Reports auszuwerten, ihre Relevanz zu erkennen und bei Bedarf rasch die richtigen Schritte einzuleiten. Zunehmende Komplexität der angebotenen Hard- und Softwarelösungen, immer kürzere Produktzyklen, steigende Vernetzung und steigende Anforderungen der Nutzer machen es zudem außerordentlich schwierig, immer wieder die richtige Balance zwischen Sicherheit und „mehr Funktionalität“ zu finden.
  • Vorteil: Gerade in Unternehmen oder Behörden mit kleiner IT-Abteilung haben einzelne MitarbeiterInnen oft einen hohen Stellenwert. Stehen sie einmal nicht zur Verfügung (Krankheit, Urlaub) oder verlassen die Institution, können sich gravierende Sicherheitsprobleme ergeben, weil es keinen gleichwertigen Vertreter gibt. Dienstleister hingegen können in der Regel auf mehrere gleich qualifizierte ExpertInnen zurückgreifen, die sich gegenseitig vertreten können.
  • Vorteil: Von einigen Institutionen wird Outsourcing häufig als vielleicht einzige Möglichkeit gesehen, eine Neugestaltung ihrer IT-Systeme und Anwendungen gegen interne Widerstände durchzusetzen. Im Zuge des Outsourcings soll eine heterogene Systemlandschaft aufgeräumt und standardisiert werden.
  • Nachteil: Wenn das Know-how der vom Outsourcing-Dienstleister eingesetzten SpezialistInnen nicht angemessen ist, so können dadurch gravierende IT-Sicherheitslücken entstehen. Ist zusätzlich intern nicht mehr das Fachwissen vorhanden, um das Sicherheitsniveau beim Outsourcing-Dienstleister zu kontrollieren, werden Sicherheitslücken womöglich nicht einmal entdeckt.
  • Nachteil: Eine Ausweitung des Dienstleistungsangebots oder die Erweiterung von IT-Systemen ist nicht mehr allein eine Entscheidung des eigenen Managements. Der Outsourcing-Dienstleister muss immer an der Diskussion beteiligt werden. Dienstleister kompensieren nicht selten günstige Konditionen bei Vertragsabschluss durch hohe Forderungen bei späteren Sonderwünschen oder neuen Anforderungen des Auftraggebers. Der dann entstehende Kostendruck führt oftmals zu Einsparungen bei der IT-Sicherheit.
  • Nachteil: Der Aufwand für die Kontrolle der Dienstleistungsqualität darf nicht unterschätzt werden. Sollten hierbei Defizite festgestellt werden, können diese schwierig und zeitaufwendig zu beheben sein, vor allem wenn es zu Meinungsverschiedenheiten zwischen Auftraggeber und Dienstleister kommt. Wenn Fragen der IT-Sicherheit dann nicht zeitnah gelöst werden, können sich Sicherheitslücken ergeben.

Eine umfassende Kosten-Nutzen-Analyse jedes Outsourcing-Vorhabens ist essentiell für den strategischen und wirtschaftlichen Erfolg. Es ist daher wichtig, alle Parameter zu kennen und auch richtig einzuschätzen.

Der strategische Wert der folgenden Ressourcen muss unter den Rahmenbedingungen des Outsourcing-Vorhabens eingeschätzt werden:
  • Know-how
  • MitarbeiterInnen
  • IT-Systeme und Anwendungen

Bei der Kosten-Nutzen-Analyse können Studien und Erfahrungsberichte anderer Institutionen wertvolle Informationen liefern.

Abschließend ist die Outsourcing-Strategie zu dokumentieren. Die Ziele, Chancen und Risiken des Outsourcing-Vorhabens sollten eindeutig beschrieben werden. Es empfiehlt sich unter diesem Gesichtspunkt außerdem, die im Rahmen eines laufenden Outsourcing-Vorhabens gemachten Erfahrungen in die Dokumentation der Outsourcing-Strategie zu integrieren. Es sollte dabei auch auf Fehlentscheidungen und daraus abgeleitete Empfehlungen für die Zukunft hingewiesen werden.

10.3.2 Festlegung der Sicherheitsanforderungen für Outsourcing-Vorhaben

ISO Bezug: 27002 10.2
Wenn eine Outsourcing-Strategie festgelegt wurde, müssen die IT-Sicherheitsanforderungen so konkret ausgearbeitet werden, dass auf ihrer Basis der geeignete Dienstleister ausgesucht werden kann. Dabei sind Sicherheitsanforderungen an den Outsourcing-Dienstleister selbst, die benutzte Technik (inklusive Kommunikationswege und -dienste), aber auch an die eigene Organisation zu stellen.

Die Erstellung eines detaillierten Sicherheitskonzeptes, das auf den hier formulierten Anforderungen aufbaut und nach Auswahl des Dienstleisters ausgearbeitet wird, wird in 10.3.5 Erstellung eines IT-Sicherheitskonzepts für das Outsourcing-Vorhaben beschrieben.

Es ist zu bedenken, dass das Festlegen von IT-Sicherheitsanforderungen ein iterativer Prozess ist:
  • Zunächst werden die gewünschten IT-Sicherheitsanforderungen durch den Auftraggeber spezifiziert.
  • Danach wird in der Angebotsphase abgeglichen, wie und ob die gewünschten IT-Sicherheitsanforderungen durch die anbietenden Dienstleister geleistet werden können (siehe auch 10.3.3 Wahl eines geeigneten Outsourcing-Dienstleisters).
  • Ist ein Dienstleister ausgewählt, so muss mit diesem die weitere Verfeinerung der IT-Sicherheitsanforderungen (z. B. basierend auf den eingesetzten Betriebssystemen oder Sicherheitsmechanismen) erarbeitet werden.
  • In der Endphase dieses Abstimmungsprozesses müssen dann auch die Sicherheitsanforderungen für die konkrete Umsetzung definiert werden.

Generell ergeben sich für Outsourcing-Szenarien folgende Mindestsicherheitsanforderungen:
  • Die Umsetzung der Anforderungen des Sicherheitshandbuchs ist eine Minimalforderung an beide Outsourcing-Parteien. Zusätzlich müssen sowohl Outsourcing-Dienstleister als auch der Auftraggeber selbst ein IT-Sicherheitskonzept besitzen und dieses umgesetzt haben.
  • Es ist wichtig, die relevanten IT-Verbünde genau abzugrenzen (z. B. nach Fachaufgabe, Geschäftsprozess, IT-Systemen), so dass alle Schnittstellen identifiziert werden können. An die Schnittstellen können dann entsprechende technische Sicherheitsanforderungen gestellt werden.
  • Es muss eine Ist-Strukturanalyse von IT-Systemen und Anwendungen (siehe auch 10.3.1 Festlegung einer Outsourcing-Strategie) erfolgen.
  • Es muss eine Schutzbedarfsfeststellung (z. B. von Anwendungen, Systemen, Kommunikationsverbindungen, Räumen) bezüglich Vertraulichkeit, Integrität und Verfügbarkeit erfolgen (siehe auch 10.3.1 Festlegung einer Outsourcing-Strategie).

Natürlich sind auch relevante Gesetze und Vorschriften zu beachten. Dies kann besonders in Fällen, in denen Auftraggeber oder Dienstleister länderübergreifend oder weltweit operieren, aufwendig sein.

Im Rahmen der IT-Sicherheitsanforderungen ist festzulegen, welche Rechte (z. B. Zutrittsrechte, Zugriffsrechte auf Daten und Systeme) dem Outsourcing-Dienstleister vom Auftraggeber eingeräumt werden.

Die Anforderungen an Infrastruktur, Organisation, Personal und Technik müssen beschrieben werden. Es genügt hier oftmals die Verpflichtung auf ein Sicherheitsniveau, das diesem Sicherheitshandbuch entspricht. Sollten darüber hinausgehende Anforderungen bestehen, müssen diese detailliert beschrieben werden. Dies hängt entscheidend von der Sicherheitsstrategie und bereits vorhandenen Systemen und Anwendungen ab. Beispielsweise könnten folgende Punkte in Abhängigkeit vom Outsourcing-Vorhaben detailliert werden:
  • Anforderungen an sicherheitskritische organisatorische Prozesse (z. B. Zeitrestriktionen für den Alarmierungsplan) können spezifiziert werden.
  • Spezielle Anforderungen an bestimmte Rollen können festgelegt werden. Es kann beispielsweise gefordert werden, dass ein IT-Sicherheitsbeauftragter/eine IT-Sicherheitsbeauftragte mit speziellen Kenntnissen (z. B. Host-Kenntnissen) beim Outsourcing-Dienstleister benannt werden muss
  • Der Einsatz zertifizierter Produkte (z. B. gemäß [Common Criteria]) beim Outsourcing-Dienstleister kann gefordert werden.
  • Anforderungen an die Verfügbarkeit von Diensten und IT-Systemen können gestellt werden. Beispielsweise kann in diesem Zusammenhang der Grad und die Methode der Lastverteilung (z. B. für Web-Server mit Kundenzugriff bei sehr vielen Kunden) vorgegeben werden.
  • Vorgaben an die Mandantenfähigkeit sowie die diesbezügliche Trennung von Hard- und Software können formuliert werden. Beispielsweise kann festgelegt werden, dass keine IT-Systeme des Auftraggebers in Räumen untergebracht werden dürfen, in denen bereits Systeme anderer Mandanten des Dienstleisters stehen.
  • Spezielle Verfahren zur Absicherung der Kommunikation zwischen Dienstleister und Auftraggeber wie Einsatz von Verschlüsselungs- und Signaturverfahren können fest vorgegeben werden.
  • Allgemeine Anforderungen bezüglich Kontrolle und Messung von Sicherheit, Qualität oder auch Abläufen und organisatorischen Regelungen können festgelegt werden, z. B. Zeitintervalle, Zuständigkeiten.
  • Gewünschte Verfahren oder Mechanismen für die Kontrolle und Überwachung, wie unangekündigte Kontrollen vor Ort, Audits (unter Umständen durch unabhängige Dritte) können spezifiziert werden.
  • Anforderungen an die Protokollierung und Auswertung von Protokolldateien können festgelegt werden.

Generell bilden die festgelegten IT-Sicherheitsanforderungen eine der Grundlagen für die Wahl eines geeigneten Outsourcing-Dienstleisters. Spezielle IT-Sicherheitsanforderungen müssen jedoch eventuell an das von Dienstleistern umsetzbare IT-Sicherheitsniveau angepasst werden.

10.3.3 Wahl eines geeigneten Outsourcing-Dienstleisters

ISO Bezug: 27002 10.2
Bei der Wahl eines geeigneten Outsourcing-Dienstleisters sind ein möglichst detailliertes Anforderungsprofil und ein darauf basierendes Pflichtenheft entscheidende Erfolgsfaktoren. Nur so kann eine bedarfsgerechte Ausschreibung erfolgen, auf die sich auch geeignete Dienstleister bewerben.

die Ausschreibung sollte
  • die Beschreibung des Outsourcing-Vorhabens (Aufgabenbeschreibung und Aufgabenteilung) sowie
  • die Beschreibungen zum geforderten Qualitätsniveau, welches nicht zwangsläufig dem Niveau des Auftraggebers entsprechen muss,
enthalten.

Weiters müssen den potenziellen Dienstleistern auch möglichst detailliert
  • die IT-Sicherheitsanforderungen und
  • die Kriterien zur Messung von Servicequalität und Sicherheit
mitgeteilt werden (siehe 10.3.2 Festlegung der Sicherheitsanforderungen für Outsourcing-Vorhaben). In Einzelfällen kann es notwendig sein, die Detailanforderungen bezüglich Sicherheit nur gegen eine Vertraulichkeitsvereinbarung (Non-Disclosure-Agreement) an Dienstleister herauszugeben, da sich daraus Hinweise auf existierende oder geplante Sicherheitsmechanismen ableiten lassen.

Das Anforderungsprofil hängt stark von der Art des Outsourcing-Vorhabens ab. Als wichtige grundsätzliche Bewertungskriterien für Dienstleister und dessen Personal können gelten:
  • Bei ausländischen Dienstleistern müssen besondere Aspekte bedacht werden. Dazu gehören beispielsweise: fremde Gesetzgebung, andere Haftungsregelungen, Spionagerisiko, andere Sicherheitskultur, im Partnerunternehmen bzw. durch die landesspezifische Gesetzgebung zugelassene und verwendbare Sicherheitsmechanismen.
  • Die Größe des Dienstleisters kann bei der Auswahl ein Argument sein. Bei kleinen Unternehmen könnte das Insolvenzrisiko höher sein. Bei großen Unternehmen ist zu bedenken, dass diese sehr viele Auftraggeber und Projekte haben, so dass ein einzelner Auftraggeber nur einer unter vielen ist und keine bevorzugte Stellung einnimmt.
  • Der Dienstleister sollte Referenzen für ähnliche Outsourcing-Vorhaben aufweisen können. Dabei ist auf Interessenskonflikte durch Geschäftsbeziehungen zu Konkurrenten des Auftraggebers und auf die Unabhängigkeit von bestimmten Herstellern (z. B. Zulieferer, die Konkurrenten des Auftraggebers sind) zu achten.
  • Die Organisationsform eines Dienstleisters kann in Betracht gezogen werden, da dies z. B. die Haftungsgrenzen beeinflussen kann. Die Eigentümerstruktur sollte recherchiert werden, um mögliche Einflussfaktoren im Vorfeld abzuklären.
  • Die Kundenstruktur sollte beachtet werden, da dies darauf hinweist, in welchem Wirtschaftssektor der Anbieter seine Stärken hat.
  • Ein Qualitätsnachweis bzw. eine Zertifizierung, z. B. nach ISO/IEC 27001 oder ISO 9000, ist eine sinnvolle Forderung.
  • Auskünfte über die aktuelle wirtschaftliche Lage sowie Erwartungen an die zukünftige Geschäftsentwicklung der Dienstleister sollten eingeholt werden.

Auch an die MitarbeiterInnen eines Dienstleisters sind diverse Anforderungen zu stellen (siehe auch 8.2 Regelungen für den Einsatz von Fremdpersonal).
  • Die Qualifikation der MitarbeiterInnen muss in die Bewertung der Angebote einfließen. Es ist nach der Projektvergabe darauf zu achten, dass die im Angebot genannten MitarbeiterInnen auch später tatsächlich eingesetzt werden.
  • Die Anzahl der verfügbaren MitarbeiterInnen muss bewertet werden. Dabei sollten auch die Vertretungsregelungen und die Arbeitszeiten hinterfragt werden.
  • Bei der Wahl ausländischer Partner muss eine gemeinsame Sprache für die Kommunikation zwischen den eigenen MitarbeiterInnen und denen des Dienstleisters festgelegt werden. Hierbei sollte auch hinterfragt werden, ob die vorhandenen Sprachkenntnisse für die Klärung von Detailproblemen ausreichen. Die Erfahrungen zeigen, dass viele Personen aus Angst, sich zu blamieren, lieber zu wichtigen Fragen schweigen, wenn sie ihre Sprachfähigkeiten als nicht perfekt einschätzen.
  • Entsprechend dem erforderlichen Sicherheitsniveau für das Outsourcing-Vorhaben sollte in die Bewertung der Angebote mit aufgenommen werden, ob eine Sicherheitsüberprüfung der MitarbeiterInnen vorliegt bzw. eine solche durchgeführt werden kann.

10.3.4 Vertragsgestaltung mit dem Outsourcing-Dienstleister

ISO Bezug: 27002 10.2
Nachdem ein Outsourcing-Dienstleister ausgewählt wurde, müssen alle Aspekte des Outsourcing-Vorhabens vertraglich in sogenannten Service Level Agreements (SLAs) festgehalten und geregelt werden. Die Aspekte, die im Folgenden beschrieben werden, sind als Hilfsmittel und Checkliste bei der Vertragsgestaltung zu sehen. Art, Umfang und Detaillierungsgrad der vertraglichen Regelungen hängen immer vom speziellen Outsourcing-Projekt ab. Je höher der Schutzbedarf der ausgelagerten IT-Systeme und Anwendungen ist, desto sorgfältiger und detaillierter muss der Vertrag zwischen Auftraggeber und Dienstleister ausgehandelt werden.

Der Dienstleister sollte zur Einhaltung des Sicherheitshandbuchs und auf die vom Auftraggeber vorgegebenen Sicherheitsanforderungen verpflichtet werden (siehe 10.3.2 Festlegung der Sicherheitsanforderungen für Outsourcing-Vorhaben). Dazu gehört natürlich, dass der Outsourcing-Dienstleister sich verpflichtet, ein IT-Sicherheitskonzept inklusive eines Notfallvorsorgekonzepts zu erstellen und Sicherheitsmaßnahmen sowie Systeme und Anwendungen zu dokumentieren.

Zusätzlich zur allgemeinen Leistungsbeschreibung empfiehlt es sich jedoch immer, auch eine genaue quantitative Leistungsbeschreibung vertraglich zu fixieren, z. B. zu Verfügbarkeitsanforderungen, Reaktionszeiten, Rechenleistung, zur Verfügung stehendem Speicherplatz, Anzahl der MitarbeiterInnen, Supportzeiten.

Generell wäre eine allgemeine Verpflichtung auf die Einhaltung des Sicherheitshandbuchs zwar zufriedenstellend, es empfiehlt sich jedoch immer, alle vereinbarten Leistungen so genau und eindeutig wie möglich vertraglich festzuhalten. Dadurch lassen sich später Streitigkeiten zwischen den Parteien vermeiden. Nachträgliche Konkretisierungen und Ergänzungen des Vertrages, die aufgrund unterschiedlicher Interpretationen der beschriebenen Leistungen notwendig werden, sind oftmals mit deutlichen Kostenerhöhungen für den Auftraggeber verbunden. Auch die Erstellung des IT-Sicherheitskonzeptes selbst sollte Vertragsbestandteil sein. Insbesondere ist zu klären, wer für die fachlichen Inhalte verantwortlich ist und welche Mitwirkungspflichten dem Auftraggeber obliegen.

Im Folgenden findet sich eine Themenliste von Aspekten, die aus Sicherheitssicht geregelt werden sollten:

Infrastruktur

  • Absicherung der Infrastruktur des Dienstleisters (z. B. Zutrittskontrolle, Brandschutz, …)

Organisatorische Regelungen/Prozesse

  • Festlegung von Kommunikationswegen und Ansprechpartnern
  • Festlegung von Prozessen, Arbeitsabläufen und Zuständigkeiten
    • Verfahren zur Behebung von Problemen, Benennung von AnsprechpartnerInnen mit den nötigen Befugnissen
    • regelmäßige Abstimmungsrunden
  • Archivierung und Löschung von Datenbeständen (insbesondere bei Beendigung des Vertragsverhältnisses)
  • Zugriffsmöglichkeiten des Dienstleisters auf IT-Ressourcen des Auftraggebers: Wer greift wie auf welches System zu? Wie sind die Zuständigkeiten und Rechte?
  • Zutritts- und Zugriffsberechtigungen für MitarbeiterInnen des Dienstleisters zu den Räumlichkeiten und IT-Systemen des Auftraggebers
  • Zutritts- und Zugriffsberechtigungen für MitarbeiterInnen des Auftraggebers zu den Räumlichkeiten und IT-Systemen des Dienstleisters

Personal

  • Gestaltung der Arbeitsplätze von externen MitarbeiterInnen (Einhalten von Computerarbeitsplatzrichtlinien)
  • Festlegung und Abstimmung von Vertretungsregelungen
  • Verpflichtung zu Fortbildungsmaßnahmen

Notfallvorsorge

  • Kategorien zur Einteilung von Fehlern und Störfällen nach Art, Schwere und Dringlichkeit
  • erforderliche Handlungen beim Eintreten eines Störfalls
  • Reaktionszeiten und Eskalationsstufen
  • Mitwirkungspflicht des Auftraggebers bei der Behebung von Notfällen
  • Art und zeitliche Abfolge von regelmäßigen und adäquaten Notfallübungen
  • Art und Umfang der Datensicherung
  • Vereinbarung, ob bzw. welche Systeme redundant ausgelegt sein müssen
  • Von besonderer Bedeutung können Regelungen im Fall höherer Gewalt sein. Es sollte beispielsweise geklärt sein, wie bei einem Streik des Personals des Dienstleisters die Verfügbarkeit von Daten und Systemen sichergestellt werden kann. Besonders wenn Dienstleister und Auftraggeber unterschiedlichen Branchen angehören oder ihren Sitz in verschiedenen Ländern haben, kann der Auftraggeber von derartigen Vorkommnissen gänzlich überrascht werden.

Haftung, juristische Rahmenbedingungen

  • Eine Verpflichtung auf die Einhaltung von geltenden Normen und Gesetzen sowie der vereinbarten Sicherheitsmaßnahmen und sonstigen Rahmenbedingungen ist vertraglich zu regeln. Ebenso sind Vertraulichkeitsvereinbarungen (Non-Disclosure-Agreements) vertraglich zu fixieren.
  • Die Einbindung Dritter, Subunternehmer und Unterauftragnehmer des Dienstleisters ist zu regeln. In der Regel empfiehlt es sich nicht, diese grundsätzlich auszuschließen, sondern sinnvolle Regelungen festzulegen.
  • Die Eigentums- und Urheberrechte an Systemen, Software und Schnittstellen sind festzulegen. Es ist auch zu klären, ob der Dienstleister bereits bestehende Verträge mit Dritten (Hardwareausstattung, Serviceverträge, Softwarelizenzen etc.) übernimmt.
  • Die Weiterverwendung der vom Dienstleister eingesetzten Tools, Prozeduren, Skripte, Batchprogramme ist für den Fall der Beendigung des Dienstleistungsverhältnisses zu regeln.
  • Regelungen für das Ende des Outsourcing-Vorhabens, z. B. für einen Wechsel oder bei Insolvenz des Dienstleisters, können spezifiziert werden. Auf ein ausreichend flexibles Kündigungsrecht ist zu achten.
  • Der Auftragnehmer ist zu verpflichten, nach Beendigung des Auftrags alle Hard- und Software inklusive gespeicherter Daten, die dem Auftraggeber gehören, zurückzugeben. Alle vorhandenen Daten inklusive Datensicherungen sind ebenfalls zurückzugeben oder (je nach Vereinbarung) zu vernichten.
  • Die Aufteilung von Risiken zwischen Auftraggeber und Dienstleister muss bedacht werden.
  • Haftungsfragen im Schadensfall sind zu klären.
  • Sanktionen oder Schadensersatz bei Nichteinhaltung der Dienstleistungsqualität müssen festgelegt werden. Die Bedeutung von Schadensersatzzahlungen und juristischen Konsequenzen sollte dabei nicht überschätzt werden. Zu bedenken sind nämlich die folgenden Punkte
    1. Quantifizierbarkeit des Schadens
      • Wie wird beispielsweise ein Imageschaden gemessen?
      • Wie ist es zu bewerten, wenn gravierende Pflichtverletzungen aufgedeckt werden, die nur zufällig nicht zu einem größeren Schaden geführt haben?
    2. Insolvenz des Dienstleisters
      Das Recht auf Schadensersatzzahlungen ist wertlos, wenn diese die Zahlungsfähigkeit des Dienstleisters übersteigen und dieser Insolvenz anmeldet. Nachfolgend fallen dann mindestens Kosten für den Umzug zu einem neuen Dienstleister an.
    3. Katastrophale Schäden
      Eine Konventionalstrafe kommt zu spät, wenn der Auftraggeber durch das Ausmaß des Schadensereignisses seiner Geschäftsgrundlage beraubt wird und im schlimmsten Fall durch die Schadensfolgen die Zahlungsunfähigkeit eintritt.
    4. Kann ein Schaden nachgewiesen bzw. der Verursacher überführt werden (z. B. Nachweis von Spionage oder Manipulationen)?
    Es ist immer zu bedenken, dass Schadensersatzzahlungen nur das allerletzte Mittel sind und nicht dazu führen dürfen, dass aus Kostengründen andere Sicherheitsmaßnahmen vernachlässigt werden. Sicherheit lässt sich nicht mit juristischen Mitteln erzielen.

Mandantenfähigkeit

  • Die notwendige Trennung von IT-Systemen und Anwendungen verschiedener Kunden muss vereinbart werden.
    • Es ist sicherzustellen, dass Probleme bei anderen Kunden nicht die Abläufe und Systeme des Auftraggebers beeinrächtigen.
    • Es ist sicherzustellen, dass Daten des Auftraggebers unter keinen Umständen anderen Kunden des Outsourcing-Dienstleisters zugänglich werden.
  • Falls notwendig, muss die physikalische Trennung (d. h. dezidierte Hardware) vereinbart werden.
  • Falls notwendig, muss vereinbart werden, dass die vom Dienstleister eingesetzten Mitarbeiter nicht für andere Auftraggeber eingesetzt werden. Es kann auch sinnvoll sein, diese auf Verschwiegenheit zu verpflichten, so dass die eingesetzten MitarbeiterInnen nicht mit anderen MitarbeiterInnen des Dienstleisters auftraggeberbezogene Informationen austauschen dürfen.

Änderungsmanagement und Testverfahren

  • Es müssen Regelungen gefunden werden, die es ermöglichen, dass der Auftraggeber immer in der Lage ist, sich neuen Anforderungen anzupassen. Dies gilt insbesondere, wenn beispielsweise gesetzliche Vorgaben geändert wurden. Es ist festzulegen, wie auf Systemerweiterungen, gestiegene Anforderungen oder knapp werdende Ressourcen reagiert wird.
  • In diesem Zusammenhang ist auch die Betreuung und Weiterentwicklung bereits vorhandener Systeme zu regeln. Nicht selten übernimmt der Dienstleister selbstentwickelte Systeme oder Software vom Auftraggeber, der damit die Fähigkeit verliert, diese in seinem Sinne weiterzuentwickeln. Der Evolutionspfad von Systemen muss daher geregelt werden.
  • Eine kontinuierliche Verbesserung der Dienstleistungsqualität und des IT-Sicherheitsniveaus sollte bereits in den SLAs (Service Level Agreements) festgeschrieben werden.
  • Der Zeitrahmen für die Behebung von Fehlern ist festzulegen.
  • Testverfahren für neue Soft- und Hardware sind zu vereinbaren. Dabei sind folgende Punkte einzubeziehen:
    • Regelungen für Updates und Systemanpassungen
    • Trennung von Test- und Produktionssystemen
    • Zuständigkeiten bei der Erstellung von Testkonzepten
    • Festlegen von zu benutzenden Testmodellen
    • Zuständigkeiten bei Auftraggeber und Dienstleister bei der Durchführung von Tests (z. B. Mitarbeit oder Hilfestellung des Auftraggebers, Abnahme- und Freigabeprozeduren)
    • Informationspflicht und Absprache vor wichtigen Eingriffen ins System (Negativbeispiel: Der Dienstleister spielt ein neues Betriebssystem auf dem Server ein. Durch unerwartete Fehler dabei werden wichtige Anwendungen gestört, ohne dass der Auftraggeber sich vorbereiten konnte.)
    • Genehmigungsverfahren für die Durchführung von Tests
    • Festlegung zumutbarer Qualitätseinbußen während der Testphase (z. B. Verfügbarkeit)

Kontrollen

  • Dienstleistungsqualität und IT-Sicherheit müssen regelmäßig kontrolliert werden. Der Auftraggeber muss die dazu notwendigen Auskunfts-, Einsichts-, Zutritts- und Zugangsrechte besitzen. Wenn unabhängige Dritte Audits oder Benchmark-Tests durchführen sollen, muss dies bereits im Vertrag geregelt sein.
  • Allen Institutionen, die beim Auftraggeber Prüfungen durchführen müssen (z. B. Aufsichtsbehörden) müssen auch beim Outsourcing-Dienstleister die entsprechenden Kontrollmöglichkeiten (z. B. Zutrittsrechte, Dateneinsicht) eingeräumt werden.

10.3.5 Erstellung eines IT-Sicherheitskonzepts für das Outsourcing-Vorhaben

ISO Bezug: 27002 10.2
Für jedes Outsourcing-Vorhaben muss ein IT-Sicherheitskonzept existieren. Dieses kann unter anderem auf Grundlage dieses Sicherheitshandbuchs erstellt sein. Outsourcing-Projekte sind dadurch gekennzeichnet, dass sich viele technische und organisatorische Details erst im Laufe der Planung und bei Migration der Systeme ergeben. Das IT-Sicherheitskonzept, das nach Beauftragung eines Dienstleisters erarbeitet wird, wird daher in den wenigsten Fällen gleich vollständig und endgültig sein und muss während der Migrationsphase von allen Beteiligten stetig weiterentwickelt und konkretisiert werden.

Generell unterscheiden sich IT-Sicherheitskonzepte für Outsourcing-Vorhaben nur wenig von IT-Sicherheitskonzepten für selbstbetriebene IT-Systeme. Es ergeben sich jedoch folgende Besonderheiten, die berücksichtigt werden müssen:
  • Am Outsourcing-Vorhaben sind aus technischer Sicht in der Regel drei Parteien beteiligt:
    1. der Outsourcing-Auftraggeber,
    2. der Dienstleister und
    3. der Netzprovider (dieser stellt die Anbindung zwischen den Outsourcing-Parteien bereit. Die Zuständigkeit für die Netzanbindung fällt dabei in der Regel dem Outsourcing-Dienstleister zu).
  • Jeder Beteiligte muss ein eigenes IT-Sicherheitskonzept erstellen und umsetzen, welches auch das spezielle Outsourcing-Vorhaben umfasst. Damit sind IT-Sicherheitskonzepte erforderlich:
    • für den Einflussbereich des Outsourcing-Dienstleisters,
    • für den Einflussbereich des Auftraggebers sowie
    • für die Schnittstellen und die Kommunikation zwischen diesen Bereichen.
  • Zusätzlich zu den Einzelkonzepten ist ein IT-Sicherheitskonzept für das Gesamtsystem zu erstellen, welches die Sicherheit im Zusammenspiel der Einzelsysteme betrachtet.
  • Die verschiedenen Teil-Konzepte müssen zwischen Auftraggeber und Dienstleistern abgestimmt werden. Dabei ist der Auftraggeber am IT-Sicherheitskonzept des Outsourcing-Dienstleisters nicht direkt beteiligt, sollte aber in einem Audit prüfen, ob es vorhanden und ausreichend ist. Für das Audit kann der Auftraggeber dabei auch auf externe Dritte zurückgreifen.

Die in 10.3.2 Festlegung der Sicherheitsanforderungen für Outsourcing-Vorhaben und 10.3.4 Vertragsgestaltung mit dem Outsourcing-Dienstleister genannten Sicherheitsanforderungen bilden dabei die Basis für das IT-Sicherheitskonzept. Aufbauend auf den dort beschriebenen grundlegenden Anforderungen muss im IT-Sicherheitskonzept die detaillierte Ausgestaltung erfolgen, wobei beispielsweise die Maßnahmen konkretisiert und Ansprechpartner namentlich festgelegt werden.

Erfahrungsgemäß ist der Übergang (Migration) von Aufgaben und IT-Systemen vom Auftraggeber zum Outsourcing-Dienstleister eine Projektphase, in der verstärkt mit Sicherheitsvorfällen zu rechnen ist. Aus diesem Grund müssen im Sicherheitskonzept Regelungen und Maßnahmen zur Migration behandelt werden:
  • Es ist ein gemischtes Team aus MitarbeiterInnen des Auftraggebers und des Outsourcing-Dienstleisters zu bilden. Dieses kann auch durch externe ExpertInnen verstärkt werden, um spezielles Know-how verfügbar zu machen.
  • Für die Migrationsphase muss eine IT-Sicherheitskonzeption erstellt werden.
  • Die Verantwortlichkeiten und Hierarchien für die Migrationsphase sind festzulegen. Dabei ist es wichtig, dass klare Führungsstrukturen geschaffen und auf beiden Seiten eindeutige AnsprechpartnerInnen definiert werden. Zusätzlich ist darauf zu achten, dass auf beiden Seiten Verantwortlichkeiten auch auf hohen Ebenen definiert werden. Nur so kann sichergestellt werden, dass im Zweifelsfall mit entsprechendem Nachdruck gehandelt werden kann.
  • Die erforderlichen Tests müssen geplant und durchgeführt werden, Abnahmeprozeduren erarbeitet und die Produktionseinführung geplant werden.
  • Es sind geeignete interne MitarbeiterInnen für die Test-, Einführungsphase und den späteren Betrieb auszuwählen. Vertraglich kann sich ein Auftraggeber natürlich auch ein Mitspracherecht bei der Personalauswahl des Outsourcing-Dienstleisters einräumen lassen.
  • Die MitarbeiterInnen des Auftraggebers sind zum Verhalten während und nach der Migrationsphase zu schulen. In der Regel sind die MitarbeiterInnen dabei mit neuen und unbekannten AnsprechpartnerInnen konfrontiert. Dies birgt die Gefahr des „Social Engineerings“ (z. B. Anruf eines vermeintlichen Mitglieds des Sicherheitsteams des Dienstleisters).
  • Der Dienstleister muss die relevanten Abläufe, Applikationen und IT-Systeme des Auftraggebers genau kennen lernen und dahingehend eingewiesen werden.
  • Der störungsfreie Betrieb ist durch genaue Ressourcenplanung und Tests sicherzustellen. Die produktiven Systeme dürfen dabei nicht vernachlässigt werden. Dazu ist im Vorfeld zu überprüfen, ob die vorgesehenen MitarbeiteInnenr zur Verfügung stehen. Zusätzlich müssen Störungen durch notwendige Tests einkalkuliert werden.
  • Anwendungen und IT-Systeme, die der Dienstleister übernehmen soll, müssen ausreichend dokumentiert sein. Die Prüfung der Dokumentation auf Vollständigkeit muss dabei ebenso bedacht werden wie das Anpassen der vorhandenen Dokumentation auf die veränderten Randbedingungen durch das Outsourcing-Vorhaben. Die Dokumentation neuer Systeme oder Teilsysteme muss dabei ebenfalls sichergestellt sein.
  • Während der Migration muss ständig überprüft werden, ob die SLAs oder die vorgesehenen IT-Sicherheitsmaßnahmen angepasst werden müssen.

In der Einführungsphase des Outsourcing-Vorhabens und der ersten Zeit des Betriebs muss dem Notfallkonzept besondere Aufmerksamkeit geschenkt werden. Bis sich bei allen Beteiligten die notwendige Routine, beispielsweise in der Behandlung von Fehlfunktionen und sicherheitsrelevanten Vorkommnissen eingestellt hat, sind verstärkt MitarbeiterInnen zu Bereitschaftsdiensten zu verpflichten.

Nach Abschluss der Migration muss sichergestellt werden, dass das IT-Sicherheitskonzept aktualisiert wird, da sich erfahrungsgemäß während der Migrationsphase immer Änderungen ergeben. Dies bedeutet insbesondere:
  • Alle Sicherheitsmaßnahmen müssen konkretisiert werden.
  • AnsprechpartnerInnen und Zuständigkeiten werden mit Namen und notwendigen Kontaktdaten (Telefon, Zeiten der Erreichbarkeit, eventuell erforderliche Zuordnungsbegriffe wie Kundennummern) dokumentiert.
  • Die Systemkonfigurationen ist zu dokumentieren, wobei auch die eingestellten sicherheitsrelevanten Parameter zu erfassen sind.
  • Das Personal ist durch Schulungsmaßnahmen auf den Regelbetrieb vorzubereiten.

Als letzte Aufgabe muss das Outsourcing-Vorhaben nach der Migrationsphase in den sicheren Regelbetrieb überführt werden. Dabei ist vor allem darauf zu achten, dass alle Ausnahmeregelungen, die während der Migrationsphase notwendig waren, wie z. B. erweiterte Zugriffsrechte, aufgehoben werden.

Im Folgenden sind einige Aspekte und Themen aufgelistet, die im IT-Sicherheitskonzept im Detail beschrieben werden sollten. Da die Details eines IT-Sicherheitskonzeptes direkt vom Outsourcing-Vorhaben abhängen, ist die Liste als Anregung zu verstehen und erhebt keinen Anspruch auf Vollständigkeit. Neben einem Überblick über die Gefährdungslage, die der Motivation der Sicherheitsmaßnahmen dient, und den organisatorischen, infrastrukturellen und personellen Sicherheitsmaßnahmen können Maßnahmen aus folgenden Bereichen sinnvoll sein:

Organisation

  • Umgang mit Daten und schützenswerten Betriebsmitteln wie Druckerpapier und Speichermedien, insbesondere Regelungen zum Anfertigen von Kopien und Löschen/Vernichten
  • Festlegung von Aktionen, für die das „Vier-Augen-Prinzip“ anzuwenden ist

Hard-/Software

  • Einsatz gehärteter Betriebssysteme, um Angriffe möglichst zu erschweren
  • Einsatz von Intrusion-Detection-Systemen (IDS), um Angriffe frühzeitig zu erkennen
  • Einsatz von Datei-Integrität-Prüfungssystemen, um Veränderungen z. B. nach erfolgreichen Angriffen, zu erkennen
  • Einsatz von Syslog- und Timeservern, um eine möglichst umfassende Protokollierung zu ermöglichen
  • Einsatz kaskadierter Firewallsysteme zur Erhöhung des Perimeterschutzes auf Seiten des Dienstleisters
  • sorgfältige Vergabe von Benutzerkennungen, Verbot von Gruppen-IDs für Personal des Dienstleisters

Kommunikation

Kontrollen und QS

  • Detailregelungen (z. B. unangekündigte Kontrollen vor Ort, Zeitintervalle, Zuständigkeiten, Detailgrad) für Kontrollen und Messung von Sicherheit, Dienstqualität, Abläufen und organisatorische Regelungen

Notfallvorsorge

10.3.6 Notfallvorsorge beim Outsourcing

ISO Bezug: 27002 10.2
Für die Notfallvorsorge beim Outsourcing gelten grundsätzlich die gleichen Anforderungen wie beim nicht ausgelagerten Betrieb von IT-Systemen. Die Besonderheiten beim Outsourcing-Betrieb ergeben sich dadurch, dass auch die Notfallvorsorge auf unterschiedliche Parteien aufgeteilt ist und durch die Verteilung der IT-Komponenten auch zusätzliche Komponenten neu hinzukommen.

Generell müssen Notfallvorsorgekonzepte für die Systeme beim Auftraggeber, beim Outsourcing-Dienstleister sowie für die Schnittstellen zwischen Auftraggeber und Dienstleister (z. B. Netzverbindung, Router, Telekommunikationsprovider) existieren. In 10.3.4 Vertragsgestaltung mit dem Outsourcing-Dienstleister sind einige Hinweise gegeben, welche Aspekte bereits im Service Level Agreement geregelt werden sollten. Im Notfallvorsorgekonzept müssen diese Vorgaben genau spezifiziert und im Detail beschrieben werden:
  • Zuständigkeiten, AnsprechpartnerInnen und Abläufe müssen klar geregelt und vollständig dokumentiert werden.
  • Detailregelungen für die Datensicherung sind zu erstellen (z. B. getrennte Backup-Medien für jeden Klienten, Verfügbarkeit, Vertretungsregelungen, Eskalationsstrategien, Virenschutz).
  • Detaillierte Arbeitsanweisungen mit konkreten Anordnungen für bestimmte Fehlersituationen sind zu erstellen.
  • Ein Konzept für Notfallübungen, die regelmäßig durchgeführt werden müssen, muss erarbeitet werden.

Die IT-Sicherheit hängt in Notfällen entscheidend von der Qualität der Arbeitsanweisungen für das Personal des Outsourcing-Dienstleisters ab. Oftmals werden die Systeme des Auftraggebers von Personal des Dienstleisters betrieben, das keine Detailkenntnisse über die Anwendungen besitzt, die auf den IT-Systemen betrieben werden. Die Verantwortung für die Anwendung liegt dennoch ausschließlich beim Auftraggeber. Tritt ein Fehler in der Anwendung auf, muss der Outsourcing-Dienstleister unter Umständen eine Fehlerbehebung herbeiführen, ohne umfangreiche Kenntnisse über das System zu besitzen. Durch das Notfallvorsorgekonzept müssen dem Outsourcing-Dienstleister daher genaue Anweisungen zur Verfügung gestellt werden, wie er dabei vorgehen darf. Es kann dabei auch sinnvoll sein, Aktionen zu definieren, die explizit verboten sind (z. B. Reboot einer Maschine).

Ein Fehlverhalten einer Anwendung kann technische Ursachen haben (z. B. Datenträger voll, Netzprobleme) oder anwendungsspezifische (z. B. Verarbeitung eines falschen Datensatzes, Programmfehler, falsche Parametereinstellung).

Bei technischen Fehlern ohne Auswirkungen auf andere Anwendungen wird der Outsourcing-Dienstleister den Fehler zwar selbst beheben können. Meist ist aber dennoch eine Kooperation mit dem Auftraggeber notwendig, um ungewünschte Seiteneffekte auf Applikationsebene zu verhindern.

Liegen anwendungsspezifische Probleme vor, benötigt der Outsourcing-Dienstleister detaillierte und umfangreiche Anweisungen sowie Listen mit Ansprechpartnern auf Seiten des Auftraggebers, damit er richtig reagieren kann. Besonders bei Problemen mit komplizierten Anwendungen oder bei umfangreichen Batch-Prozessen sind häufig Kenntnisse erforderlich, die nur beim Auftraggeber vorhanden sind.

Wichtig ist in diesem Fall auch, dem Dienstleister Informationen bezüglich des Schutzbedarfs der betroffenen Daten und Systeme zur Verfügung zu stellen, damit mit angemessener Umsicht gehandelt werden kann.

10.4 Schutz vor Schadprogrammen und Schadfunktionen

ISO Bezug: 27002 10.4
Computerviren (im Rahmen dieses Handbuchs der Einfachheit halber als Viren bezeichnet) gehören zu den „Programmen mit Schadensfunktionen“ („maliziöse Software“). Dies sind Programme, die verdeckte Funktionen enthalten und damit durch Löschen, Überschreiben oder sonstige Veränderungen unkontrollierbare Schäden an Programmen und Daten bewirken können. Damit verursachen sie zusätzliche Arbeit und Kosten und haben einen negativen Einfluss auf die Vertraulichkeit, Integrität und Verfügbarkeit von Daten oder Programmen.
Zu den Programmen mit Schadensfunktionen gehören:
Viren:
Nichtselbstständige, in andere Programme oder Dateien eingebettete Programmroutinen, die sich selbst reproduzieren und dadurch von den AnwenderInnen nicht kontrollierbare Manipulationen in Systembereichen, an anderen Programmen oder deren Umgebung vornehmen.
Trojanische Pferde:
Selbständige Programme mit verdeckter Schadensfunktion, ohne Selbstreproduktion. Trojanische Pferde dienen vor allem dazu, Computer auszuspionieren.
Logische Bomben:
Programme, deren Schadensfunktion von einer logischen Bedingung gesteuert wird, beispielsweise dem Datum oder einer bestimmten Eingabe.
Würmer:
Selbständige, selbstreproduzierende Programme, die sich in einem System (vor allem in Netzen) ausbreiten.
Verbreitung:
Während früher Viren meist durch den Austausch „verseuchter“ Datenträger verbreitet wurden, wird heute zunehmend die Verbreitung über Internet bzw. E-Mail zum Problem. Bei den meisten über E-Mail verbreiteten „Viren“ handelt es sich eigentlich um Würmer, die - unabhängig von der eigentlichen Schadensfunktion - schon durch ihr massenhaftes Auftreten und ihre rasante Verbreitung großes Aufsehen erregen und zu hohen Schäden führen (vgl. dazu auch [NSA-EEC1]).
Das nachfolgende Kapitel beschäftigt sich vorwiegend mit dem Schutz gegen Viren und Würmer, die zur Vereinfachung im Folgenden generell als „Viren“ bezeichnet werden. Die angeführten Maßnahmen sind großteils auch gegen andere Arten von Software mit Schadensfunktion, wie z. B. Trojanische Pferde anwendbar.

10.4.1 Erstellung eines Virenschutzkonzepts

ISO Bezug: 27002 10.4, 11.7
Um für ein komplexes IT-System oder eine gesamte Organisation einen effektiven Virenschutz zu erreichen, ist ein mehrstufiges Schutzkonzept erforderlich, bei dem in jeder Stufe angemessene und aufeinander abgestimmte Schutzmaßnahmen realisiert werden.
Schutzmaßnahmen sind zu treffen:
  • auf Ebene der Firewall
  • auf Server-Ebene
  • auf Client-Ebene
Neben den technischen Schutzmaßnahmen sind auch organisatorische und personelle Maßnahmen erforderlich, um einem Virenbefall so weit wie möglich vorzubeugen, bzw. im Falle eines Virenbefalls den Schaden möglichst zu begrenzen.
Die nachfolgenden Maßnahmen geben eine Reihe von generellen Empfehlungen zum Virenschutz, die an die Erfordernisse der betroffenen Institution anzupassen sind. Je mehr bzw. je exakter die Empfehlungen umgesetzt werden, desto geringer wird das allgemeine Risiko. Allerdings können ggf bestimmte (auch notwendige/vorgesehene) Funktionen nicht mehr oder zumindest weniger produktiv durchgeführt werden. Die anzuwendenden Maßnahmen sind daher vor dem Hintergrund des Gesamtsystems und der jeweils gültigen Policy vorzuschreiben. Für die Effizienz des Virenschutzkonzeptes sind dabei nicht nur die ausgewählten Maßnahmen selbst von Bedeutung, sondern auch die Abstimmung dieser Maßnahmen aufeinander.
[eh SYS 4.1]

10.4.2 Generelle Maßnahmen zur Vorbeugung gegen Virenbefall

ISO Bezug: 27002 10.4.1,
Die nachfolgend angeführten Maßnahmen dienen einer Vorbeugung gegen Virenbefall bzw. einer Verringerung des Schadens im Falle eines Befalls.
  • Regelmäßige Durchführung einer Datensicherung (vgl. 10.5.1 Regelmäßige Datensicherung).
  • Sichere Aufbewahrung der Sicherheitskopien von Datenträgern (vgl. 10.5.5 Geeignete Aufbewahrung der Backup-Datenträger).
  • Setzen eines Schreibschutzes bzw. Nutzung von nur einmal beschreibbaren Medien bei allen Datenträgern, auf die nicht geschrieben werden muss (gilt insbesondere für Datenträger, die Programme beinhalten) und bei allen ausgehenden Datenträgern.
  • Überprüfung aller ein- und ausgehenden Datenträger (vgl. auch 10.7.3 Datenträgeraustausch).
  • Überprüfung aller vorinstallierten Neugeräte und gewarteten Geräte.
  • Überprüfung aller ein- und ausgehenden Dateien über externe Netzwerke (E-Mails, Internet) (s. u.).
  • Als vorbeugende Maßnahme gegen Virenbefall empfiehlt es sich, in der Boot-Reihenfolge die Systemfestplatte an erster Stelle einzustellen bzw. das Booten von externen Datenträgern (CD, DVD, USB-Stick etc.) ganz zu unterbinden.
  • Die Unterteilung der Festplatte in mehrere Partitionen kann die Rekonstruktion von Daten nach einem Virus-Schaden erleichtern (Anmerkung: Dies gilt auch bei einem Headcrash).
  • Es sollten nur vertrauenswürdige Programme zugelassen sein, die auch über entsprechende Sicherheitsfunktionen verfügen. Dies gilt in besonderem Maße für E-Mail-Programme. „Private“ Insellösungen auf einzelnen Arbeitsplatzrechnern sollten nicht zugelassen werden, um die Sicherheit des Gesamtsystems nicht zu gefährden.
  • Für Probleme sollten zentrale AnsprechpartnerInnen (E-Mail-Adresse, Telefon- und Fax-Nummer) benannt werden.
[eh SYS 4.2]

10.4.3 Empfohlene Virenschutzmaßnahmen auf Firewall-Ebene

ISO Bezug: 27002 10.4.1
Viele Schadfunktionen (Nachladen von Code aus dem Internet; Übermittlung von vertraulichen Informationen aus dem geschützten Netz) benötigen definierte Verbindungswege in das Internet (Ports, Adressen), um ihre Wirkung entfalten zu können. Daher ist durch eine restriktive Politik bei den Filterregeln der Firewalls eine wesentliche Erhöhung der Sicherheit erreichbar.
Gateways bieten meist auch Möglichkeiten ohne teure Zusatzprodukte Maßnahmen zu setzen, die der Verbreitung von Schadprogrammen entgegenwirken. Dabei können Dateitypen (z. B. *.VBS, *.WSH, *.BAT, *.EXE), die im täglichen Arbeitsablauf nicht als Anhänge von E-Mails vorkommen, gleich zentral blockiert werden.
Der Einsatz spezieller Rechner, die den Datenverkehr auf Viren und auch den Inhalt der E-Mails scannen können, ist in Form einer erweiterten Gatewayfunktionalität oder der Einbindung über eigene Protokolle (z. B. Content Vectoring Protocol) möglich. Dabei können E-Mails mittels Virenscanner verschiedener Hersteller überprüft werden und - sogar vor dem Vorliegen der neuen Virensignaturen - durch das Filtern entsprechender Textbegriffe die Ausbreitung neuer Schadsoftware gestoppt werden.
Sollten Informationen blockiert werden, empfiehlt es sich, den AbsenderInnen einer solchen E-Mail eine automatisierte Nachricht zukommen zu lassen, dass ihre E-Mails nicht zugestellt werden konnten oder (besser) einen SMTP-Error zu erzeugen und somit den zustellenden Server über die Nichtzustellung zu informieren.
[eh SYS 4.3]

10.4.4 Empfohlene Virenschutzmaßnahmen auf Server-Ebene

ISO Bezug: 27002 10.4.1
Auf E-Mail-Servern und allen Servern, die zum Datenaustausch genutzt werden, sollten Virenschutzprogramme zur zentralen Überprüfung des E-Mail-Verkehrs und der ausgetauschten Dateien installiert werden (vgl. dazu auch 10.4.8 Auswahl und Einsatz von Virenschutzprogrammen).
Dabei ist auf eine regelmäßige Aktualisierung der eingesetzten Programme zu achten.
[eh SYS 4.4]

10.4.5 Empfohlene Virenschutzmaßnahmen auf Client-Ebene und Einzelplatzrechnern

ISO Bezug: 27002 10.4.1, 10.4.2, 11.7.2
  • Aktivierung aller vorhandenen Sicherheitsfunktionen des Rechners (Passwort-Schutz, Bildschirmschoner mit Passwort etc.), damit während der Abwesenheit der berechtigten BenutzerInnen Unbefugte keine Möglichkeit haben, durch unbedachte oder gewollte Handlungen den Rechner zu gefährden.
  • Einsatz eines aktuellen Virenschutzprogrammes mit aktuellen Signaturdateien, das im Hintergrund läuft (resident) und bei bekannten Viren Alarm schlägt. (Auch wenn am E-Mail-Server bereits ein Virenschutzprogramm zum Einsatz kommt, empfiehlt sich die Installation dezentraler Virenschutzprogramme, um beispielsweise auch Schutz bei verschlüsselter Kommunikation zu erreichen.)
  • Aktivierung der Anzeige aller Dateitypen im Browser bzw. E-Mail-Programm.
  • Aktivierung des Makrovirenschutzes von Anwendungsprogrammen (MS Word, Excel, Powerpoint etc.) und Beachtung von Warnmeldungen.
  • Sofern möglich: Wahl der höchsten Stufen in den Sicherheitseinstellungen von Internet-Browsern (Deaktivieren von aktiven Inhalten (ActiveX, Java, JavaScript) und Skript-Sprachen (z. B. Visual Basic Script, VBS) aus unbekannten Quellen etc.).
  • Keine Nutzung von Applikationsverknüpfungen für Anwendungen mit potenziell aktivem Code (MS-Office) im Browser, keine Aktivierung von Anwendungen über Internet.
  • Die Ausführung von aktiven Inhalten in E-Mail-Programmen immer unterbinden (entsprechende Optionen setzen).
  • Durch den Einsatz eines Firewall-Produkts auf den Einzelplatzrechnern (Personal Firewalls), die regeln, welche Programme auf das Internet zugreifen dürfen, kann der Schadsoftware ebenfalls gezielt entgegen gewirkt werden. Dadurch wird die zentrale Firewall, die keine Informationen über die aufrufenden Programme hat, wirkungsvoll ergänzt (vgl. 10.6.15 Sicherer Betrieb einer Firewall).
[eh SYS 4.5]

10.4.6 Vermeidung bzw. Erkennung von Viren durch die BenutzerInnen

ISO Bezug: 27002 10.4.1, 10.4.2
Die Sensibilisierung der EndanwenderInnen für die Virenproblematik stellt eine wichtige Komponente beim Schutz gegen Viren dar. Daher sollte in Schulungen regelmäßig auf die Gefahr von Viren, die Möglichkeiten zu ihrer Erkennung und Vermeidung sowie die notwendigen Handlungsanweisungen im Falle eines (vermuteten) Virenbefalls hingewiesen werden. Auch laufende Informationen zu diesem Thema, etwa über das Intranet oder in Form interner Publikationen, sind empfehlenswert.
Erkennen potenzieller Gefahren bei eingehender E-Mail und Abwehrmaßnahmen:
  • Bei E-Mail auch von vermeintlich bekannten bzw. vertrauenswürdigen AbsenderInnen prüfen, ob der Text der Nachricht auch zu den AbsenderInnen passt (englischer Text von deutscher Partnerin bzw. deutschem Partner, zweifelhafter Text oder fehlender Bezug zu konkreten Vorgängen etc.) und ob die Anlage (Attachment) auch erwartet wurde.
  • Vorsicht bei mehreren E-Mails mit gleichlautendem Betreff.
  • Kein „Doppelklick“ bei ausführbaren Programmen (*.COM, *.EXE) oder Script-Sprachen (*.VBS, *.BAT etc.) (sofern sie nicht bereits auf Firewall-Ebene gefiltert wurden).
  • Vorsicht auch bei Dateien von Anwendungsprogrammen (Office etc.) sowie Bildschirmschonern (*.SCR).
  • Auch eine E-Mail im HTML-Format kann aktive Inhalte mit Schadensfunktion enthalten.
  • Nur vertrauenswürdige E-Mail-Attachments öffnen (z. B. in letzter Konsequenz sogar nach telefonischer Absprache). Es ist zu beachten, dass die Art des Dateianhangs (Attachment) bei Sabotageangriffen oft getarnt ist und über ein Icon nicht sicher erkannt werden kann.
  • Die Konfiguration der E-Mail-Clients sollte so eingestellt sein, dass Attachments nicht automatisch geöffnet werden. Außerdem sollten als E-Mail-Editor keine Programme mit der Funktionalität von Makrosprachen (z. B. MS Word) oder Scripts eingesetzt werden. Bei der Verwendung des HTML-Formates ist ebenfalls Vorsicht geboten.

Empfohlene Verhaltensregeln im Verdachtsfall:

Verdächtige E-Mails bzw. deren Attachments sollten auf keinen Fall von den EndanwenderInnen geöffnet werden.
Im Privatbereich und evtl. auch in Teilen des kommerziellen Bereiches wird ein sofortiges Löschen von offensichtlich unsinnigen oder irgendwie verdächtigen E-Mails empfehlenswert sein, um der Gefahr einer Vireninfektion zu begegnen. In Bereichen, wo dies entweder aufgrund gesetzlicher Vorschriften oder kommerzieller Überlegungen nicht möglich ist, ist dafür zu sorgen, dass verdächtige E-Mails in entsprechend sicherer Umgebung geöffnet und analysiert werden können. Dazu sind sog. „Quarantänebereiche“ einzurichten, in denen die E-Mails von SpezialistInnen bzw. Spezialisten untersucht und weiterbehandelt werden können. BenutzerInnen müssen wissen, wie sie diese SpezialistInnen erreichen oder E-Mails an solche Bereiche weiterleiten können.

Maßnahmen bei ausgehender E-Mail:

Durch Beachtung der nachfolgenden Maßnahmen kann die Gefahr reduziert werden, dass EndanwenderInnen unabsichtlich Viren verteilen:
  • Vermeidung aktiver Inhalte in E-Mails.
  • Keine unnötigen E-Mails mit Scherzprogrammen und ähnlichem versenden, da diese evtl. einen Computervirus enthalten können.
  • Keinen Aufforderungen zur Weiterleitung von Warnungen, E-Mails oder Anhängen an FreundInnen bzw. Freunde, Bekannte oder KollegInnen folgen, sondern direkt nur an die IT-Sicherheitsbeauftragten senden. Es handelt sich nämlich meist um irritierende und belästigende E-Mails mit Falschmeldungen (Hoax oder „elektronische Ente“, Kettenbrief).
  • Gelegentlich prüfen, ob E-Mails im Postausgang stehen, die nicht selbst verfasst wurden.

Verhalten bei Downloads aus dem Internet:

Daten und Programme, die aus dem Internet abgerufen werden, stellen einen Hauptverbreitungsweg für Viren und „Trojanische Pferde“ dar, die verwendet werden um Benutzerdaten auszuspähen, weiterzuleiten, zu verändern oder zu löschen. Es muss darauf hingewiesen werden, dass auch Dateien von Office- und anderen Anwendungsprogrammen (Text-, Tabellen- und Präsentationsdateien, PDF etc.) Makroviren bzw. Scripts mit Schadensfunktion enthalten können.
  • Programme sollten nur von vertrauenswürdigen Seiten geladen werden, also insbesondere von den Originalseiten der HerstellerInnen. Private Homepages, die bei anonymen Webspace-Providern eingerichtet werden, stellen hierbei eine besondere Gefahr dar.
  • Die Angabe der Größe von Dateien, sowie einer evtl. auch angegebenen Prüfsumme, sollte nach einem Download immer überprüft werden. Bei Abweichungen von der vorgegebenen Größe oder Prüfsumme ist zu vermuten, dass unzulässige Veränderungen, meist durch Viren, vorgenommen worden sind. Daher sollten solche Dateien sofort gelöscht werden.
  • Mit einem aktuellen Virenschutzprogramm sollten vor der Installation die Dateien immer überprüft werden.
  • Gepackte (komprimierte) Dateien sollten erst entpackt und auf Viren überprüft werden. Installierte Entpackungsprogramme sollten so konfiguriert sein, dass zu entpackende Dateien nicht automatisch gestartet werden.
[eh SYS 4.6]

10.4.7 Erstellung von Notfallplänen im Fall von Vireninfektionen

ISO Bezug: 27002 12.6, 13, 14.1.3
  • Die Informationswege für Notfälle sind zu planen, die zuständigen Funktionen oder Personen zu definieren, Ausweichwege für die Kommunikation und Vertretungsregeln festzulegen.
  • Je nach vorliegendem Schadprogramm sind Verfahren zur differenzierten E-Mail-Filterung (z. B. Größenbeschränkung, keine Attachments, nur Posteingang, Filterung von bestimmten Betreffen) vorzubereiten und auch zu testen. Da E-Mail mittlerweile das zentrale Informationsmedium geworden ist, dürfen diese Systeme allenfalls kurzzeitig deaktiviert werden, damit nach wie vor Warnungen möglich sind.
  • Es muss sichergestellt sein, dass bei Vorliegen eines neuen Virus die Updates der Virenschutzprogramme möglichst rasch auf Servern, Gateways und Clients eingestellt werden. Die entsprechenden Verteilwege und Maßnahmen sind vorzubereiten und selbstverständlich auch regelmäßig zu testen.
  • Sollten durch einen neuen Virus die üblichen Informationswege nicht verfügbar sein, sind alternative Verfahren zur zeitnahen Warnung vorzusehen (z. B. notfalls auch durch Fax, SMS, Telefon- und Informationsdisplays, Lautsprecherdurchsagen).
  • Für den Notfall sind Backup- und Restore-Strategien zu erarbeiten, die festlegen, welche Rechner in welcher Reihenfolge in betriebsbereiten Zustand zu bringen sind, damit in kürzester Zeit eine, wenn auch eingeschränkte, Funktionsfähigkeit hergestellt werden kann.
[eh SYS 4.7]

10.4.8 Auswahl und Einsatz von Virenschutzprogrammen

ISO Bezug: 27002 10.4.1
Zum Schutz vor Viren können unterschiedliche Wirkprinzipien genutzt werden.
Programme, die Speichermedien nach bekannten Viren durchsuchen, haben sich in der Vergangenheit als effektivstes und wirksamstes Mittel in der Virenbekämpfung erwiesen. Von Vorteil ist, dass neu erhaltene Software oder Datenträger schon vor dem ersten Einsatz geprüft werden können. Man kann daher eine Infektion mit bekannten Viren grundsätzlich vermeiden. Ein weiterer Vorteil ist, dass man durch das Virenschutzprogramm eine genauere Information über den jeweils entdeckten Virus erhält. Die bekannten Viren sind durch SpezialistInnen analysiert worden, so dass man weiß, ob und welche Schadensfunktionen vorhanden sind. Ein gutes Virenschutzprogramm muss daher nicht nur in der Lage sein, viele Viren zu finden, sondern sie auch möglichst exakt zu identifizieren. Zahlreiche Programme bieten auch die Möglichkeit einer Entfernung gefundener Viren an. Hierbei ist zu beachten, dass die Qualität dieser Entfernungsroutinen sehr unterschiedlich ist. Wenn immer möglich, sollten mit der Entfernung SpezialistInnen betraut werden.
Zu beachten ist, dass Virenschutzprogramme mit der Zeit ihre Wirksamkeit verlieren, da sie nur die zu ihrem Erstellungszeitpunkt bekannten Viren berücksichtigen, neu hinzugekommene jedoch meist nicht erkennen können. Daher ist eine regelmäßige Aktualisierung des Virenschutzprogramms erforderlich.
Ebenso wie andere Programme können sie durch Aufruf (transient) oder im Hintergrund (resident) genutzt werden. Die Betriebsart des Virenschutzprogramms hat entscheidenden Einfluss auf die Akzeptanz bei den AnwenderInnen und damit auf die tatsächlich erreichte Schutzfunktion.
Beim transienten Betrieb wird das Programm aufgerufen, durchsucht die eingestellten Teile des Computers, beendet seine Arbeit danach und macht den Speicher wieder frei. Meist lösen die AnwenderInnen den Aufruf aus.
Beim residenten Betrieb wird das Virenschutzprogramm beim Start des Rechners in den Speicher geladen und verbleibt dort aktiv bis zum Ausschalten. Es verrichtet seine Tätigkeit, ohne dass die AnwenderInnen dabei mitwirken, sie können inzwischen ihre eigentliche Arbeit, z. B. das Schreiben von Texten, ausführen.
Eine weitere präventive Maßnahme ist der Einsatz von Checksummen-Prüfprogrammen. Hierbei werden zum Schutz vor Veränderung von den zu prüfenden Dateien oder Systembereichen (z. B. Boot- und Partition-Sektor) Prüfsummen berechnet, die regelmäßig kontrolliert werden. Auf diese Weise können nicht nur Verseuchungen mit bisher unbekannten Viren erkannt werden, sondern auch andere unberechtigte Veränderungen an Dateien.
Im Wesentlichen sollte ein Virenschutzprogramm folgende Eigenschaften erfüllen:
  • Der Umfang der erkannten Viren sollte möglichst groß sein und dem aktuell bekannten Bestand entsprechen, insbesondere müssen alle sehr stark verbreiteten Viren erkannt werden.
  • Eine ständige Aktualisierung bezüglich neuer Viren muss vom Hersteller sichergestellt sein.
  • Das Programm sollte Viren auch in komprimierter Form finden, wobei alle gängigen Komprimierungsfunktionen (wie z. B. PKZIP) unterstützt werden sollten.
  • Gefundene Viren müssen mit einer vollständigen Pfad-Angabe angezeigt werden.
  • Das Programm muss seine eigene Virenfreiheit feststellen, bevor die Suchfunktion ausgeführt wird.
  • Nach Möglichkeit muss das Produkt als residentes Programm eine permanente Virenkontrolle ermöglichen.
  • Sinnvoll ist eine Funktionalität, die es erlaubt, erkannte Viren zu entfernen, ohne weitere Schäden an Programmen oder Daten zu verursachen.
  • Das Programm sollte über eine Protokollierungsfunktion verfügen, die folgende Daten festhält:
    • Versionsstand des Programms,
    • Datum und Uhrzeit der Überprüfung,
    • Angabe aller benutzten Parameter,
    • Prüfergebnis mit Prüfumfang,
    • Anzahl und Identifikation der Dateien und Objekte, die nicht geprüft werden konnten.
  • Das Programm sollte eine Warnung ausgeben, wenn es feststellt, dass es offensichtlich nicht aktualisiert wurde.
  • Das Programm sollte eine Liste der erkennbaren Viren und ihre Beschreibung beinhalten. Darüber hinaus sind jeweils Beschreibungen von Sofortmaßnahmen und Maßnahmen zum Entfernen des Virus anzugeben.
[eh SYS 4.8]

10.4.9 Verhaltensregeln bei Auftreten eines Virus

ISO Bezug: 27002 10.4.1, 13 teilweise
Gibt es Anzeichen, dass ein Rechner von einem Virus befallen ist (z. B. Programmdateien werden länger, unerklärliches Systemverhalten, nicht auffindbare Dateien, veränderte Dateiinhalte, ständige Verringerung des freien Speicherplatzes, ohne dass etwas abgespeichert wurde), so sind zur Feststellung des Virus und zur anschließenden Beseitigung folgende Schritte durchzuführen.
Grundregel: Falls möglich, sollten fachkundige BetreuerInnen (AdministratorInnen, Bereichs-IT-Sicherheitsverantwortliche, Helpdesk) zu Hilfe geholt werden.
Falls dies nicht möglich ist, sollten folgende Schritte durchgeführt werden:
  1. Beenden der laufenden Programme und Abschalten des Rechners.
  2. Booten des Rechners von einer einwandfreien, geprüften Notfall-CD (evtl. vorher Boot-Reihenfolge im BIOS-Setup ändern, siehe 10.4.2 Generelle Maßnahmen zur Vorbeugung gegen Virenbefall).
  3. Überprüfen des Rechners mit einem aktuellen Virenschutzprogramm um festzustellen, ob tatsächlich ein Virus aufgetreten ist und um welchen Virus es sich ggf. handelt.
  4. Entfernen des Virus abhängig vom jeweiligen Virustyp.
  5. Erneute Überprüfung der Festplatte mit dem Virensuchprogramm.
  6. Untersuchung aller anderen Datenträger (USB-Sticks, Wechselplatten etc.) auf Virenbefall und Entfernung eventuell vorhandener Viren.
  7. Es sollte versucht werden, die Quelle der Vireninfektion festzustellen. Ist die Quelle auf Originaldatenträger zurückzuführen, dann sollte der Hersteller informiert werden. Liegt die Quelle in Dateien oder E-Mail, so sind die ErstellerInnen der Datei zu unterrichten.
  8. Warnung an andere IT-BenutzerInnen, wenn ein Datenaustausch vom infizierten Rechner erfolgte.
Sollte der Virus Daten gelöscht oder verändert haben, so muss versucht werden, die Daten aus den Datensicherungen und die Programme aus den Sicherungskopien der Programme (vgl. 10.5.6 Sicherungskopie der eingesetzten Software) zu rekonstruieren.
Anschließend ist das wiederhergestellte System noch einmal auf Schadsoftware zu überprüfen.
[eh SYS 4.9]

10.4.10 Warnsystem für Computerviren – Aktualisierung von Virenschutzprogrammen

Im Zusammenhang mit Computerviren ist die permanente Aktualität des verwendeten Virenschutzprogrammes von größter Wichtigkeit. Bereits bei der Beschaffung von Virenschutzprogrammen ist daher für die Aktualisierbarkeit und die Versorgung von entsprechenden Updates durch den Hersteller Sorge zu tragen. Darüber hinaus sind die Verantwortlichkeiten für die regelmäßig durchzuführenden Aktualisierungen innerhalb der Organisation zu definieren.
Neben der Aktualisierung der eingesetzten Software ist auch die Information über neue Computerviren, sowie Informationen über empfohlene aktive und passive Gegenmaßnahmen, besonders wichtig. Dabei genügt es oft nicht, sich nur auf die periodischen Updates des Virenschutzprogrammherstellers zu verlassen. Im Bereich der öffentlichen Verwaltung wurde ein eigenes Government Computer Emergency Response Team (GovCERT.AT) eingerichtet. Dieses wird in Kooperation mit CERT.at zur Behandlung beziehungsweise Verhinderung von Sicherheitsvorfällen im Bereich der Informations- und Kommunikationstechnologien betrieben. Dabei wird u. a. mit einem Warnsystem für Computerviren und sonstigen schädigenden Inhalten eine Informationsbasis und ein Verteilsystem für derartige Informationen geschaffen, welches den geeigneten Stellen der öffentlichen Verwaltung und der Wirtschaft zur Verfügung steht.
[eh SYS 4.10]

10.4.11 Schutz vor aktiven Inhalten

ISO Bezug: 27002 10.4.2
Eines der größten Probleme bei der Konzeption eines Sicherheitsgateways (Firewall) ist die Behandlung der Probleme, die durch die Übertragung aktiver Inhalte zu den Rechnern im zu schützenden Netz entstehen. Derzeit existieren noch keine brauchbaren Programme, die eine ähnlich wirksame Erkennung von Schadfunktionen in ActiveX-Controls, Java-Applets oder Scripting-Programmen ermöglichen, wie sie im Bereich der Computerviren möglich ist.
Die Größe der Gefährdung, die von aktiven Inhalten für die Rechner im zu schützenden Netz ausgeht, lässt sich anhand des folgenden Beispiels darstellen: Ein Java-Applet bzw. der Browser darf gemäß der Java-Spezifikationen eine Netzverbindung zu dem Server aufbauen, von dem es geladen worden ist. Diese zur Zeit noch recht wenig benutzte Möglichkeit ist eine zentrale Voraussetzung, wenn Netz-Computer (NC) oder ähnliches eingesetzt werden sollen, die auch ohne spezielle Initiierung durch den/die AnwenderIn Programme vom Server laden müssen. Um diese Eigenschaft trotz der Verwendung eines Paketfilters vollständig unterstützen zu können, müssen sehr viel mehr Ports freigeschaltet werden oder es muss ein dynamischer Paketfilter eingesetzt werden. Ist das der Fall, können Java-Applets verwendet werden, um kaum zu kontrollierende IP-Verbindungen aufbauen zu können.
Die Kontrolle aktiver Inhalte kann auf verschiedene Weise geschehen:
  1. Zentrale Filterung der aktiven Inhalte auf der Firewall
    Sämtliche als schädlich eingestuften Inhalte werden von einer Komponente der Firewall gefiltert, so dass keine potenziell schädlichen Programme mehr auf den Client-Rechnern eintreffen. Aktive Inhalte werden über spezielle Tags innerhalb einer HTML-Seite eingebunden. In der Regel werden aktive Inhalte anhand der entsprechenden Tags aus einer HTML-Seite erkannt und gelöscht, oder sie werden durch einen Textbaustein ersetzt, der dem Anwender einen Hinweis über die Tatsache der Filterung gibt. Das Problem besteht dabei darin, dass wegen der komplexen Möglichkeiten der aktuellen HTML-Spezifikation oft nicht alle zu löschenden Tags von den Sicherheitsproxies erkannt werden. Weiters ist problematisch, dass beispielsweise Java-Applets nicht notwendigerweise als Datei mit der Endung .class verschickt werden müssen. Stattdessen können auch komprimierte Dateien eingesetzt werden, die z. B. die Endung .jar (Java-Archive) haben. Das bedeutet, dass ein Java-Filter auch alle von den verwendeten Browsern unterstützten Dateiendungen für Java-Dateien kennen muss. Zusätzliches Schadenspotenzial resultiert auch aus der Möglichkeit, JavaScript aus Java heraus auszuführen. Ähnliche Probleme existieren im Zusammenhang mit Flash-Objekten, .NET Assemblies und anderen aktiven Inhalten. Es sollte unbedingt beachtet werden, dass auch aktive Inhalte außerhalb von Webseiten gefiltert werden müssen, beispielsweise in HTML-E-Mails.
  2. Dezentrale Abwehr auf den angeschlossenen Clients
    Die Ausführung aktiver Inhalte sollte normalerweise durch entsprechende Einstellungen im Browser unterbunden werden. Die Umsetzung einer Whitelist-Strategie für aktive Inhalte wird von verschiedenen Browsern in unterschiedlicher Weise und mehr oder weniger gut unterstützt (Beispiele: Zonenmodell des Microsoft Internet Explorers, Browser-Profile bei Mozilla Firefox). Idealerweise sollte ein Browser die Möglichkeit bieten, die Ausführung bestimmter Typen aktiver Inhalte getrennt für einzelne Server oder Domains freigeben oder verbieten zu können. Dabei ist allerdings zu beachten, dass es aufgrund von Schwachstellen in den Browsern Angreifern möglich sein kann, entsprechende Einschränkungen zu umgehen. Java-Applets, Acitve-X Objekte und mit Einschränkungen auch Javascript können mit einer digitalen Signatur versehen werden. Die Signatur dient dazu, die Integrität und Authentizität des jeweiligen aktiven Inhalts zu schützen. Werden ausschließlich signierte aktive Inhalte zugelassen, so bietet dies eine erhöhte Sicherheit vor Schadfunktionen. Diese Sicherheit ist jedoch nur indirekt, da der Nutzer auf die Vertrauenswürdigkeit der Signaturstelle, die in Zusammenarbeit mit dem Anbieter der aktiven Inhalte die Signatur erstellt, angewiesen ist. Selbst die vollständige Deaktivierung der Ausführung aktiver Inhalte bietet aber nur einen begrenzten Schutz vor bösartigen aktiven Inhalten. Aufgrund der Vielzahl von Softwareschwachstellen in den Browsern können die Sicherheitseinstellungen umgangen werden, so dass der intendierte Schutz tatsächlich nicht oder nicht in vollem Umfang existiert.
  3. Installation von Antivirensoftware und Personal Firewalls auf den Clients
    Antivirenprodukte können vor Viren, Makroviren und Trojanischen Pferden schützen, die durch aktive Inhalte automatisch heruntergeladen wurden. Sie bieten einen guten Schutz vor bereits bekannten Schadprogrammen. Personal Firewalls sind Programme, die auf dem Client-Rechner installiert werden und dort meist mehrere Funktionen wahrnehmen. Sie bieten meist neben der Funktion eines lokalen Paketfilters weitere Funktionen an. Beispielsweise bieten einige Personal Firewalls die Möglichkeit einer Überwachung anderer Programme, die versuchen eine Netz-Verbindung aufzubauen. Solche Verbindungsaufnahmen können dann meist entweder automatisch anhand festgelegter Regeln oder im Einzelfall vom Benutzer selbst erlaubt oder verboten werden. In einigen Fällen bieten sie auch sogenannte „Sandboxen“, die die Ausführung aktiver Inhalte kontrollieren und auf unbedenkliche Operationen beschränken können. Personal Firewalls bieten zusammen mit Antivirenprogrammen einen recht guten Schutz vor bösartigen aktiven Inhalten. Allerdings muss berücksichtigt werden, dass die richtige Konfiguration dieser Programme zusätzlichen Administrationsaufwand erfordert, und dass Personal Firewalls selbst Sicherheitslücken aufweisen können, die das System gefährden.
Bei allen drei Optionen ist eine Sensibilisierung der BenutzerInnen zusätzlich notwendig. Zudem muss sichergestellt werden, dass die Einstellungen auf den Clients bei allen unter Punkt 2 und 3 genannten Schutzvorkehrungen nicht versehentlich oder absichtlich von den BenutzerInnen deaktiviert oder umgangen werden können.
Die Entscheidung, wie mit aktiven Inhalten in Webseiten umgegangen wird, hängt in erster Linie vom Schutzbedarf der betreffenden Clients ab.
Die Entscheidung für eine bestimmte Vorgehensweise und die Gründe, die dafür ausschlaggebend waren, sollten nachvollziehbar dokumentiert werden.
Eine zu „liberale“ Einstellung oder gar eine generelle Freigabe aktiver Inhalte ist auch bei normalem Schutzbedarf nicht zu empfehlen. Die möglichen Schäden, die durch bösartige aktive Inhalte in Verbindung mit Schwachstellen in Webbrowsern oder im unterliegenden Betriebssystem entstehen können, sind dafür zu gravierend. Falls für bestimmte Anwendungen aktive Inhalte zwingend nötig sind, sollten sie nur für die betreffenden Server freigegeben werden.
Bei Neuentwicklungen browserbasierter Anwendungen oder bei einer Weiterentwicklung einer bestehenden Anwendung, die aktive Inhalte im Browser benötigt, sollte kritisch hinterfragt werden, ob die Verwendung der aktiven Inhalte wirklich notwendig ist. Oft lassen sich aktive Inhalte bei gleichwertiger Funktionalität durch serverseitig dynamisch erzeugte Webseiten ersetzen.

Empfehlungen für normalen Schutzbedarf:
  • Deaktivierung aktiver Inhalte im Browser und Freischaltung nur für vertrauenswürdige Websites.
  • Virenscanner auf dem Client.
  • Eine Filterung aktiver Inhalte auf dem Sicherheitsgateway mit Freischaltung für vertrauenswürdige Websites (Whitelist).
Empfehlungen für hohen Schutzbedarf (zusätzlich zu den o. g. Empfehlungen für normalen Schutzbedarf):
  • Filterung von Cookies (Whitelist).
  • Die Kriterien, für welche Websites aktive Inhalte freigeschaltet werden, sollten deutlich restriktiver sein.
  • Eine ergänzende Sicherheitsanalyse wird empfohlen, um sicher zu stellen, dass ein angemessenes Sicherheitsniveau erreicht wurde
[eh SYS 8.5]

10.4.12 Sicherer Aufruf ausführbarer Dateien

ISO Bezug: 27002 10.4
Ausführbare Dateien können direkt gestartet werden. Im Gegensatz hierzu können Anwendungsdaten, wie Textdateien, nur über ein entsprechendes Programm angesehen werden. Unter Windows sind ausführbare Dateien an ihrer Dateiendung (beispielsweise .exe, .com, .vbs, .bat, .cmd) und unter Unix oder Linux durch Dateirechte (x-Flag) erkennbar.
Es muss sichergestellt werden, dass nur freigegebene Versionen ausführbarer Dateien und keine eventuell eingebrachten modifizierten Versionen (insbesondere Trojanische Pferde) aufgerufen werden (siehe auch 12.1.7 Abnahme und Freigabe von Software).
AngreiferInnen könnten ausführbare Dateien soweit verändern, dass sie die Privilegien der BenutzerInnen erhalten, die die Datei ausführen. Um dies zu verhindern, dürfen ausführbare Dateien nur lesbar sein. Ein Schreibzugriff darf nur AdministratorInnen gestattet werden
Ausführbare Dateien, für die Schreibrechte benötigt werden, z. B. weil sie sich in der Entwicklung befinden, dürfen nur in separaten Bereichen verwendet werden. Dasselbe gilt für neue Software, die für einen späteren Einsatz auf einem Produktivsystem getestet werden soll. Hierfür können beispielsweise separate Testsysteme eingesetzt werden oder spezielle Benutzerkonten ohne weitere Privilegien. Nur so kann verhindert werden, dass diese Applikationen Schaden anrichten.
Auch bereits getestete Software kann die Sicherheit beeinträchtigen. Dies betrifft vor allem sehr komplexe Anwendungen wie zum Beispiel Webserver. Schon beim Start von Anwendungen muss sichergestellt werden, dass jeder Prozess nur so viele Rechte erhält, wie unbedingt notwendig sind. So kann bei einem erfolgreichen Angriff der eintretende Schaden begrenzt werden. Diese Dienste dürfen, wenn möglich, nicht mit Administratorrechten gestartet werden. Hierfür eignen sich ebenfalls Benutzerkonten mit eingeschränkten Privilegien. Über klare Trennungen von Rechten, unter Unix oder Linux beispielsweise durch chroot-Umgebungen, die den eintretenden Schaden begrenzen können, muss nachgedacht werden.
Im Weiteren muss sichergestellt werden, dass nur die gewünschte, freigegebene Version ausgeführt werden kann. AngreiferInnen könnten sonst eine modifizierte Datei mit dem selben Namen in ein Verzeichnis kopieren, auf das sie Schreibrechte haben. Wird beim Aufruf in den Verzeichnissen nach der Datei gesucht, könnte die modifizierte statt der gewünschten Datei ausgeführt werden.
Bei vielen Betriebssystemen werden die Verzeichnisse, in denen nach den ausführbaren Dateien gesucht werden soll, in der entsprechenden Reihenfolge in der PATH-Variable eingetragen. Die Anzahl der angegebenen Verzeichnisse sollte gering und überschaubar gehalten werden. Relative Verzeichnisangaben, die das jeweils aktuelle Arbeitsverzeichnis enthalten, dürfen als Angabe in der PATH-Variable nicht enthalten sein. Ausführbare Dateien sollen nur in dafür vorgesehenen Verzeichnissen gespeichert sein. In den in einer PATH-Variable enthaltenen Verzeichnissen darf nur der jeweilige Eigentümer Schreibrechte erhalten. Dies muss regelmäßig überprüft werden.

10.4.13 Vermeidung gefährlicher Dateiformate

ISO Bezug: 27002 10.4
E-Mail ist einer der wichtigsten Übertragungswege für Computerviren und -würmer. Eine rein textbasierte E-Mail ohne Anhänge ist dabei ungefährlich. Gefährlich wird es erst, wenn E-Mail-Anhänge ausgeführt werden oder die E-Mail HTML-basiert ist (siehe unten). Prinzipiell können E-Mails Anhänge in beliebiger Art und Menge beigefügt werden. Durch ein Zuviel an Anhängen kann die Verfügbarkeit eines E-Mail-Clients oder des E-Mail-Servers beeinträchtigt werden. Die größere Gefahr sind aber Anhänge, die ausführbaren Code enthalten und damit ungeahnte Nebeneffekte auslösen können.
Der E-Mail-Client sollte so eingestellt sein, dass Anhänge nicht versehentlich gestartet werden können, sondern das Programm vor der Ausführung warnt bzw. zumindest nachfragt, ob die Datei geöffnet werden soll. Das Betriebssystem bzw. der E-Mail-Client sollte außerdem so eingerichtet sein, dass Dateien zunächst nur in Viewern oder anderen Darstellungsprogrammen angezeigt werden, die eventuell in den Dateien enthaltenen Programmcode, wie Makros oder Skripte, nicht ausführen.
Vor dem Absenden einer E-Mail sollte sich jeder überlegen, ob es wirklich nötig ist, ein Attachment anzuhängen, oder ob die Informationen nicht genauso gut als Text in die E-Mail direkt eingefügt werden kann. Ansonsten sollten Dateien in möglichst „ungefährlichen“ Formaten weitergegeben werden. Wenn sich die Versendung von Dateien in „gefährlichen“ Formaten nicht vermeiden lässt, sollte überlegt werden, den Empfänger mit einer kurzen E-Mail darauf hinzuweisen, dass als nächstes eine E-Mail mit solchen Attachments zu erwarten ist.
Für den Umgang mit Dateiformaten, die als potenziell problematisch eingeschätzt werden, können verschiedene Regelungen getroffen werden. Wichtig ist aber auf jeden Fall, dass alle Betroffenen sich der Problematik bewusst sind und entsprechend vorsichtig mit diesen Dateiformaten umgehen.
Die restriktivste Form ist es, das Öffnen aller als problematisch eingestuften Dateiformate zu verbieten bzw. diese am E-Mail-Gateway herauszufiltern. Dies führt allerdings erfahrungsgemäß zu großen Akzeptanzproblemen seitens der KundInnen und der MitarbeiterInnen. Besser ist es im allgemeinen, einerseits die MitarbeiterInnen für die Problematik zu sensibilisieren und zum Mitdenken anzuregen und sie andererseits technisch zu unterstützen, indem die Gefährdungspotenziale durch entsprechende Konfiguration und Sicherheitswerkzeuge minimiert werden.
Im Folgenden werden einige Einschätzungen verschiedener Dateiformate gegeben. Diese können sich allerdings jederzeit ändern, wenn z. B. ein Hersteller seinem Produkt neue Features hinzufügt, die ungeplante Nebenwirkungen haben, bzw. SoftwareanalystInnen solche Nebenwirkungen herausfinden.
  • Als weitgehend harmlos gelten bisher ASCII-, GIF-, JPEG-formatierte Dateien.
  • Als möglicherweise gefährlich sollten die folgenden Dateiformate behandelt werden: alle Dateiformate von Office-Paketen wie Microsoft Office, LibreOffice oder OpenOffice.org mit integrierter Makrosprache, z. B. Word, Excel, Powerpoint (.DOC, .XLS, .PPT, SDW, SXW usw.). Besonders kritisch sind alle ausführbaren Programme (wie .COM, .EXE, .PIF) oder Skript-Sprachen (.VBS, .JS, .BAT unter Windows, ebenso wie Perl- oder Shellskripte unter Unix), Registrierungsdateien (.REG) sowie Bildschirmschoner (.SCR). Vorsichtshalber sollte für alle diese Dateitypen eine „ungefährliche“ Standardapplikation festgelegt werden, mit der diese zwar geöffnet werden, innerhalb deren aber eventuelle Computerviren keinen Schaden auslösen können. Beispielsweise sollten Dateitypen wie *.VBS, *.JS oder *.BAT grundsätzlich mit einem einfachen, nicht makrofähigen Texteditor geöffnet werden. Windows-Betriebssysteme sollten außerdem so konfiguriert sein, dass bei Registrierungsdateien (.REG) als Standardvorgang „Bearbeiten“ statt „Zusammenführen“ eingestellt ist. Dadurch wird die Datei zunächst in einem Editor dargestellt und nicht der Registrierungsdatenbank hinzugefügt, wenn sie aktiviert wird.
  • Mit Zusatzmaßnahmen als vertretbar angesehen werden können: HTML, wenn ein JavaScript-Filter oder andere Sicherheitsvorkehrungen eingesetzt werden, RTF (mit COM-Object-Filter), ZIP (hier sollten die BenutzerInnen allerdings gewarnt werden, dass die enthaltenen Dateien problematisch sein können), PDF (dabei ist darauf zu achten, dass z. B. die Software „PDF Reader“ auf dem Endgerät als Standard installiert ist und nicht „Adobe Acrobat“).
Immer mehr E-Mails sind heutzutage auch HTML-formatiert. Dies ist einerseits oft lästig, weil nicht alle E-Mail-Clients dieses Format anzeigen können. Andererseits kann dies aber auch dazu führen, dass bereits bei der Anzeige solcher E-Mails auf dem Client ungewollte Aktionen ausgelöst werden, da HTML-Mails eingebetteten JavaScript- oder VisualBasic-Skript-Code enthalten können.
Durch Kombination verschiedener Sicherheitslücken in E-Mail-Clients und Browsern ist es in der Vergangenheit immer wieder zu Sicherheitsproblemen mit HTML-formatierten E-Mails gekommen.
Generell sollten möglichst keine HTML-formatierten E-Mails oder solche mit aktiven Inhalten versendet werden. Außerdem sollte die Möglichkeit überprüft werden, in eingehenden E-Mails enthaltene aktive Inhalte herauszufiltern, beispielsweise an der Firewall.
Weiters sollten E-Mail-Clients gewählt werden, bei denen HTML-formatierte E-Mails als solche zu erkennen sind, damit die BenutzerInnen diese nicht unbewusst öffnen.
Generell sollte eine Vorgabe innerhalb einer Organisation zum Umgang mit HTML-formatierten E-Mails erstellt werden. Beim Empfang von HTML-formatierten E-Mails sollte festgelegt werden, ob diese
  • unverändert an die BenutzerInnen weitergeleitet und die BenutzerInnen für den verantwortungsvollen und vorsichtigen Umgang mit solchen E-Mails geschult und sensibilisiert werden,
  • mit Hilfe von serverseitigen Tools in ein reines Textformat umgewandelt und danach mit einem entsprechenden Hinweis an die Benutzer weitergeleitet werden (dabei können allerdings Informationen verloren gehen),
  • nicht direkt an die BenutzerInnen weitergeleitet werden, sondern an einen besonderen Arbeitsplatz, wo sie mit besonderen Sicherheitsvorkehrungen von den EmpfängerInnen eingesehen werden können (je nach E-Mail-Aufkommen kann dies allerdings einen nicht akzeptablen Aufwand mit sich bringen).
Grundsätzlich sollten alle BenutzerInnen für diese Problematik sensibilisiert sein.

10.5 Datensicherung

Unabdingbare Voraussetzung für jeden Business Continuity Plan ist die Planung und Durchführung einer ordnungsgemäßen Datensicherung.

10.5.1 Regelmäßige Datensicherung

ISO Bezug: 27002 10.5.1
Zur Vermeidung von Datenverlusten müssen regelmäßige Datensicherungen durchgeführt werden. In den meisten Rechnersystemen können diese weitgehend automatisiert erfolgen. Es sind Regelungen zu treffen, welche Daten von wem wann gesichert werden. Empfehlenswert ist die Erstellung eines Datensicherungskonzeptes (vgl. 10.5.2 Entwicklung eines Datensicherungskonzeptes).
Abhängig von der Menge und Wichtigkeit der laufend neu gespeicherten Daten und vom möglichen Schaden bei Verlust dieser Daten ist Folgendes festzulegen:
  • Umfang der zu sichernden Daten:
    Am einfachsten ist es, Partitionen bzw. Verzeichnisse festzulegen, die bei der regelmäßigen Datensicherung berücksichtigt werden. Eine geeignete Differenzierung kann die Übersichtlichkeit vergrößern sowie Aufwand und Kosten sparen helfen. Z. B.: Sicherung der selbsterstellten Dateien und der individuellen Konfigurationsdateien.
  • Zeitintervall:
    z. B. täglich, wöchentlich, monatlich
  • Zeitpunkt:
    z. B. nachts, freitags abends
  • Anzahl der aufzubewahrenden Generationen:
    bei täglicher Komplettsicherung werden z. B. die letzten sieben Sicherungen aufbewahrt, außerdem die Freitagabendsicherungen der letzten zwei Monate.
  • Speichermedien (abhängig von der Datenmenge):
    z. B. Bänder, DVDs, Wechselplatten etc.
  • Wiederaufbereitung der Datenträger (Löschung vor Wiederverwendung)
  • Zuständigkeit für die Durchführung (Systemadministration, BenutzerIn)
  • Zuständigkeit für die Überwachung der Sicherung, insbesondere bei automatischer Durchführung (Fehlermeldungen, verbleibender Platz auf den Speichermedien)
  • Dokumentation der erstellten Sicherungen (Datum, Art der Durchführung der Sicherung, gewählte Parameter, Beschriftung der Datenträger)
Wegen des großen Aufwands können Komplettsicherungen in der Regel höchstens einmal täglich durchgeführt werden. Die seit der letzten Sicherung erstellten Daten können nicht wiedereingespielt werden. Daher und zur Senkung der Kosten sollen zwischen den Komplettsicherungen regelmäßig inkrementelle Sicherungen durchgeführt werden, das heißt, nur die seit der letzten Komplettsicherung neu erstellten Daten werden gesichert. Werden zwischen zwei Komplettsicherungen mehrere inkrementelle Sicherungen durchgeführt, können auch jeweils nur die seit der letzten inkrementellen Sicherung neu erstellten Daten gesichert werden.
Eine inkrementelle Sicherung kann häufiger erfolgen, zum Beispiel sofort nach Erstellung wichtiger Dateien oder mehrmals täglich. Die Vereinbarkeit mit dem laufenden Betrieb ist sicherzustellen.
Für eingesetzte Software ist in der Regel die Aufbewahrung der Originaldatenträger und deren Sicherungskopien ausreichend. Sie braucht dann von der regelmäßigen Datensicherung nicht erfasst zu werden.
Alle BenutzerInnen sollten über die Regelungen zur Datensicherung informiert sein, um ggf. auf Unzulänglichkeiten (zum Beispiel zu geringes Zeitintervall für ihren Bedarf) hinweisen oder individuelle Ergänzungen vornehmen zu können (zum Beispiel zwischenzeitliche Spiegelung wichtiger Daten auf der eigenen Platte). Auch die Information der BenutzerInnen darüber, wie lange die Daten wiedereinspielbar sind, ist wichtig. Werden zum Beispiel bei wöchentlicher Komplettsicherung nur zwei Generationen aufbewahrt, bleiben in Abhängigkeit vom Zeitpunkt des Verlustes nur zwei bis drei Wochen Zeit, um die Wiedereinspielung vorzunehmen.
Falls bei vernetzten Rechnern nur die Server-Platten gesichert werden, ist sicherzustellen, dass die zu sichernden Daten regelmäßig von den BenutzerInnen oder automatisch dorthin überspielt werden.
[eh BCP 1.1]

10.5.2 Entwicklung eines Datensicherungskonzeptes

ISO Bezug: 27002 10.5.1
Die Verfahrensweise der Datensicherung wird von einer großen Zahl von Einflussfaktoren bestimmt. Das IT-System, das Datenvolumen, die Änderungsfrequenz der Daten und die Verfügbarkeitsanforderungen sind einige dieser Faktoren. Im Datensicherungskonzept gilt es, eine Lösung zu finden, die diese Faktoren berücksichtigt und gleichzeitig unter Kostengesichtspunkten wirtschaftlich vertretbar ist. Diese Lösung muss auch jederzeit aktualisierbar und erweiterbar sein. Weiters ist dafür Sorge zu tragen, dass alle betroffenen IT-Systeme im Datensicherungskonzept berücksichtigt werden und das Konzept stets den aktuellen Anforderungen entspricht.
Ein möglicher Aufbau eines Datensicherungskonzeptes ist in B Muster für Verträge, Verpflichtungserklärungen und Dokumentationen angeführt.
Einzelne Punkte eines Datensicherungskonzeptes werden in den nachfolgenden Maßnahmen näher ausgeführt.
Für die Gewährleistung einer funktionierenden Datensicherung müssen praktische Übungen zur Datenrestaurierbarkeit verpflichtend vorgesehen sein (siehe 14.2.2 Übungen zur Datenrekonstruktion).
[eh BCP 1.2]

10.5.3 Festlegung des Minimaldatensicherungskonzeptes

ISO Bezug: 27002 10.5.1
Für eine Organisation ist festzulegen, welche Minimalforderungen zur Datensicherung eingehalten werden müssen. Damit können viele Fälle, in denen eingehende Untersuchungen und die Erstellung eines Datensicherungskonzeptes zu aufwendig sind, pauschal behandelt werden. Weiterhin ist damit eine Grundlage gegeben, die generell für alle IT-Systeme gültig ist und damit auch für neue IT-Systeme, für die noch kein Datensicherungskonzept erarbeitet wurde. Ein Beispiel soll dies erläutern.
Minimaldatensicherungskonzept (Beispiel):
  • Software:
    Sämtliche Software, also sowohl Eigenentwicklungen als auch Standardsoftware, ist einmalig mittels einer Vollsicherung zu sichern.
  • Systemdaten:
    Systemdaten sind mindestens einmal monatlich mit einer Generation zu sichern.
  • Anwendungsdaten:
    Alle Anwendungsdaten sind mindestens einmal monatlich mittels einer Vollsicherung im Drei-Generationen-Prinzip zu sichern.
  • Protokolldaten:
    Sämtliche Protokolldaten sind mindestens einmal monatlich mittels einer Vollsicherung im Drei-Generationen-Prinzip zu sichern.
[eh BCP 1.3]

10.5.4 Datensicherung bei Einsatz kryptographischer Verfahren

ISO Bezug: 27002 10.5.1, 12.3.2
Beim Einsatz kryptographischer Verfahren darf die Frage der Datensicherung nicht vernachlässigt werden. Neben der Frage, wie eine Datensicherung der verschlüsselten Daten sinnvollerweise erfolgen sollte, muss auch überlegt werden, ob und wie die benutzten kryptographischen Schlüssel gespeichert werden sollen. Daneben ist es auch zweckmäßig, die Konfigurationsdaten der eingesetzten Kryptoprodukte zu sichern.

Datensicherung der Schlüssel

Es muss sehr genau überlegt werden, ob und wie die benutzten kryptographischen Schlüssel gespeichert werden sollen, da jede Schlüsselkopie eine potenzielle Schwachstelle ist.
Trotzdem kann es aus verschiedenen Gründen notwendig sein, kryptographische Schlüssel zu speichern.
Es gibt unterschiedliche Methoden der Schlüsselspeicherung:
  • die Speicherung zu Transportzwecken auf einem transportablen Datenträger, z. B. Chipkarte, USB-Stick (dient vor allem zur Schlüsselverteilung bzw. zum Schlüsselaustausch, siehe 12.6.7 Schlüsselmanagement),
  • die Speicherung in IT-Komponenten, die dauerhaft auf kryptographische Schlüssel zugreifen müssen, also z. B. zur Kommunikationsverschlüsselung,
  • die Schlüsselhinterlegung als Vorbeugung gegen Schlüsselverlust oder im Rahmen von Vertretungsregelungen.
Hierbei ist grundsätzlich zu beachten:
  • Kryptographische Schlüssel sollten so gespeichert bzw. aufbewahrt werden, dass Unbefugte sie nicht unbemerkt auslesen können. Beispielsweise könnten Schlüssel in spezieller Sicherheitshardware gespeichert werden, die die Schlüssel bei Angriffen automatisch löscht. Falls sie in Software gespeichert werden, sollten sie auf jeden Fall in verschlüsselter Form gespeichert werden. Hierbei ist zu bedenken, dass die meisten Standardanwendungen, bei denen Schlüssel oder Passwörter in der Anwendung gespeichert werden, dies i. Allg. mit leicht zu brechenden Verfahren tun. Als weitere Variante kann auch das Vier-Augen-Prinzip bei der Schlüsselspeicherung benutzt werden, also die Speicherung eines Schlüssels in Schlüsselhälften oder Schlüsselteilen.
  • Von Kommunikationsschlüsseln und anderen kurzlebigen Schlüsseln sollten keine Kopien erstellt werden. Damit eine unautorisierte Nutzung ausgeschlossen ist, sollten auch von privaten Signaturschlüsseln i. Allg. keine Kopien existieren. Falls jedoch für die Schlüsselspeicherung eine reine Softwarelösung gewählt wurde, d. h. wenn keine Chipkarte o.ä. verwendet wird, ist das Risiko des Schlüsselverlustes (etwa durch Bitfehler oder Festplattendefekt) erhöht. In diesem Fall ist es unter Umständen weniger aufwendig, eine ausreichend gesicherte Möglichkeit der Schlüsselhinterlegung zu schaffen, als bei jedem Schlüsselverlust alle Kommunikationspartner zu informieren.
  • Von langlebigen Schlüsseln, die z. B. zur Archivierung von Daten oder zur Generierung von Kommunikationsschlüsseln eingesetzt werden, sollten auf jeden Fall Sicherungskopien angefertigt werden.

Datensicherung der verschlüsselten Daten

Besondere Sorgfalt ist bei der Datensicherung von verschlüsselten Daten bzw. beim Einsatz von Verschlüsselung während der Datenspeicherung notwendig. Treten hierbei Fehler auf, sind nicht nur einige Datensätze, sondern meist alle Daten unbrauchbar.
Die Langzeitspeicherung von verschlüsselten oder signierten Daten bringt viele zusätzliche Probleme mit sich. Hierbei muss nicht nur sichergestellt werden, dass die Datenträger regelmäßig aufgefrischt werden und jederzeit noch die technischen Komponenten zum Verarbeiten dieser zur Verfügung stehen, sondern auch, dass die verwendeten kryptographischen Algorithmen und die Schlüssellänge noch dem Stand der Technik entsprechen. Bei der langfristigen Archivierung von Daten kann es daher sinnvoller sein, diese unverschlüsselt zu speichern und dafür entsprechend sicher zu lagern, also z. B. in Tresoren.
Die verwendeten Kryptomodule sollten vorsichtshalber immer archiviert werden, da die Erfahrung zeigt, dass auch noch nach Jahren Daten auftauchen, die nicht im Archiv gelagert waren.

Datensicherung der Konfigurationsdaten der eingesetzten Produkte

Bei komplexeren Kryptoprodukten sollte nicht vergessen werden, deren Konfigurationsdaten zu sichern. Die gewählte Konfiguration sollte dokumentiert sein, damit sie nach einem Systemversagen oder einer Neuinstallation schnell wieder eingerichtet werden kann.
[eh BCP 1.4]

10.5.5 Geeignete Aufbewahrung der Backup-Datenträger

ISO Bezug: 27002 10.5.1
Backup-Datenträger unterliegen besonderen Anforderungen hinsichtlich ihrer Aufbewahrung:
  • Der Zugriff auf diese Datenträger darf nur befugten Personen möglich sein, so dass eine Entwendung ausgeschlossen werden kann.
  • Ein ausreichend schneller Zugriff im Bedarfsfall muss gewährleistet sein.
  • Für den Katastrophenfall müssen die Backup-Datenträger räumlich getrennt vom Rechner - auf jeden Fall in einem anderen Brandabschnitt, wenn möglich disloziert - aufbewahrt werden.
Zu beachten sind auch die Anforderungen aus 10.7.2 Datenträgerverwaltung.
Je nach Anforderungen und geforderte Ausfallsicherheit (Katastrophenvorsorge – vgl. 14.1.1 Definition von Verfügbarkeitsklassen) kann es notwendig sein das Datenarchiv an einem gänzlich anderen Ort zu halten. Damit wird sichergestellt, dass der Datenbestand eines derartigen Notfallarchivs nicht aufgrund der gleichen Schadensursache zerstört wird, und dass im Falle der Unzugänglichkeit der Infrastruktur (beispielsweise aufgrund von Verschüttungen, o.ä.) der Datensicherungsbestand zur Verfügung steht.
[eh BCP 1.5]

10.5.6 Sicherungskopie der eingesetzten Software

ISO Bezug: 27002 10.5.1
Von den Originaldatenträgern von Standardsoftware bzw. von der Originalsoftware bei Eigenentwicklungen ist - sofern möglich - eine Sicherungskopie zu erstellen, von der bei Bedarf die Software wieder eingespielt werden kann. Die Originaldatenträger und die Sicherungskopien sind getrennt voneinander aufzubewahren. Es ist darauf zu achten, dass der physikalische Schreibschutz des Datenträgers ein versehentliches Löschen oder Überschreiben der Daten verhindert.
Ein unerlaubter Zugriff, z. B. zur Erstellung einer Raubkopie, muss ausgeschlossen sein.
[eh BCP 1.6]

10.5.7 Beschaffung eines geeigneten Datensicherungssystems

ISO Bezug: 27002 10.5.1
Ein Großteil der Fehler, die beim Erstellen oder Restaurieren einer Datensicherung auftreten, sind Fehlbedienungen. Daher sollte bei der Beschaffung eines Datensicherungssystems nicht allein auf dessen Leistungsfähigkeit geachtet werden, sondern auch auf seine Bedienbarkeit und insbesondere auf seine Toleranz gegenüber Benutzerfehlern.
Bei der Auswahl von Sicherungssoftware sollte darauf geachtet werden, dass sie die folgenden Anforderungen erfüllt:
  • Die Datensicherungssoftware sollte ein falsches Medium ebenso wie ein beschädigtes Medium im Sicherungslaufwerk erkennen können.
  • Sie sollte mit der vorhandenen Hardware problemlos zusammenarbeiten.
  • Es sollte möglich sein, Sicherungen automatisch zu vorwählbaren Zeiten bzw. in einstellbaren Intervallen durchführen zu lassen, ohne dass hierzu manuelle Eingriffe (außer dem eventuell notwendigen Bereitstellen von Sicherungsdatenträgern) erforderlich wären.
  • Es sollte möglich sein, ausgewählte BenutzerInnen automatisch über das Sicherungsergebnis und eventuelle Fehlermeldungen per E-Mail oder ähnliche Mechanismen zu informieren. Die Durchführung von Datensicherungen inklusive des Sicherungsergebnisses und möglicher Fehlermeldungen sollten in einer Protokolldatei abgespeichert werden.
  • Die Sicherungssoftware sollte die Sicherung des Backup-Mediums durch ein Passwort oder, je nach Vertraulichkeitsanforderungen, durch Verschlüsselung unterstützen. Weiters sollte sie in der Lage sein, die gesicherten Daten in komprimierter Form abzuspeichern.
  • Durch Vorgabe geeigneter Include- und Exclude-Listen bei der Datei- und Verzeichnisauswahl sollte genau spezifiziert werden können, welche Daten zu sichern sind und welche nicht. Es sollte möglich sein, diese Listen zu Sicherungsprofilen zusammenzufassen, abzuspeichern und für spätere Sicherungsläufe wieder zu benutzen.
  • Es sollte möglich sein, die zu sichernden Daten in Abhängigkeit vom Datum ihrer Erstellung bzw. ihrer letzten Modifikation auszuwählen.
  • Die Sicherungssoftware sollte die Erzeugung logischer und physischer Vollkopien sowie inkrementeller Kopien (Änderungssicherungen) unterstützen.
  • Die zu sichernden Daten sollten auch auf Festplatten und Netzlaufwerken abgespeichert werden können.
  • Die Sicherungssoftware sollte in der Lage sein, nach der Sicherung einen automatischen Vergleich der gesicherten Daten mit dem Original durchzuführen und nach der Wiederherstellung von Daten einen entsprechenden Vergleich zwischen den rekonstruierten Daten und dem Inhalt des Sicherungsdatenträgers durchzuführen.
  • Bei der Wiederherstellung von Dateien sollte es möglich sein auszuwählen, ob die Dateien am ursprünglichen Ort oder auf einer anderen Platte bzw. in einem anderen Verzeichnis wiederhergestellt werden. Ebenso sollte es möglich sein, das Verhalten der Software für den Fall zu steuern, dass am Zielort schon eine Datei gleichen Namens vorhanden ist. Dabei sollte man wählen können, ob diese Datei immer, nie oder nur in dem Fall, dass sie älter als die zu rekonstruierende Datei ist, überschrieben wird, oder dass in diesem Fall eine explizite Anfrage erfolgt.
Falls mit dem eingesetzten Programm die Datensicherung durch ein Passwort geschützt werden kann, sollte diese Option genutzt werden.
[eh BCP 1.7]

10.5.8 Datensicherung bei mobiler Nutzung eines IT-Systems

ISO Bezug: 27002 9.2.5, 10.5.1, 10.7.1, 10.8.1 teilweise, 11.7.1
IT-Systeme im mobilen Einsatz (z. B. Notebooks, Tablet-PCs) sind in aller Regel nicht permanent in ein Netz eingebunden. Der Datenaustausch mit anderen IT-Systemen erfolgt üblicherweise über Datenträger oder über temporäre Netzanbindungen. Letztere können beispielsweise durch Remote Access oder direkten Anschluss an ein LAN nach Rückkehr zum Arbeitsplatz realisiert sein. Anders als bei stationären Clients ist es daher bei mobilen IT-Systemen meist unvermeidbar, dass Daten zumindest zeitweise lokal anstatt auf einem zentralen Server gespeichert werden. Dem Verlust dieser Daten muss durch geeignete Datensicherungsmaßnahmen vorgebeugt werden.
Generell bieten sich folgende Verfahren zur Datensicherung an:

Datensicherung auf externen Datenträgern

Der Vorteil dieses Verfahrens ist, dass die Datensicherung an nahezu jedem Ort und zu jeder Zeit erfolgen kann. Nachteilig ist, dass ein geeignetes Laufwerk und genügend Datenträger mitgeführt werden müssen und dass für die BenutzerInnen zusätzlicher Aufwand für die ordnungsgemäße Handhabung der Datenträger entsteht.
Die Datenträger sollten eine ausreichende Speicherkapazität besitzen, so dass die BenutzerInnen nicht mehrere Datenträger pro Sicherungsvorgang in das Laufwerk einlegen müssen. Bei unverschlüsselter Datenhaltung ergibt sich außerdem die Gefahr, dass Datenträger abhanden kommen und dadurch sensitive Daten kompromittiert werden können. Die Datenträger und das mobile IT-System sollten möglichst getrennt voneinander aufbewahrt werden, damit bei Verlust oder Diebstahl des IT-Systems die Datenträger nicht ebenfalls abhanden kommen.
Nach Rückkehr zum Arbeitsplatz müssen die Datensicherungen auf den Datenträgern in das Backup-System oder in das Produktivsystem bzw. die zentrale Datenhaltung der Organisation eingebracht werden.

Datensicherung über temporäre Netzverbindungen

Wenn die Möglichkeit besteht, das IT-System regelmäßig an ein Netz anzuschließen, beispielsweise über Remote Access, kann die Sicherung der lokalen Daten auch über die Netzanbindung erfolgen. Vorteilhaft ist hier, dass die BenutzerInnen keine Datenträger verwalten und auch kein entsprechendes Laufwerk mitführen müssen. Weiters lässt sich das Verfahren weitgehend automatisieren, beispielsweise kann die Datensicherung beim Einsatz von Remote Access nach jedem Einwahlvorgang automatisch gestartet werden.
Entscheidend bei der Datensicherung über eine temporäre Netzverbindung ist, dass deren Bandbreite für das Volumen der zu sichernden Daten ausreichen muss. Die Datenübertragung darf nicht zu lange dauern und nicht zu übermäßigen Verzögerungen führen, wenn die BenutzerInnen gleichzeitig auf entfernte Ressourcen zugreifen müssen. Bei manchen Zugangstechnologien (z. B. Modem, Mobiltelefon) bedeutet dies, dass nur geringe Datenmengen pro Sicherungsvorgang transportiert werden können. Einige Datensicherungsprogramme bieten daher die Möglichkeit an, lediglich Informationen über die Änderungen des Datenbestands seit der letzten Datensicherung über die Netzverbindung zu übertragen. In vielen Fällen kann hierdurch das zu transportierende Datenvolumen stark reduziert werden.
Eine wichtige Anforderung an die zur Datensicherung verwendete Software ist, dass unerwartete Verbindungsabbrüche erkannt und ordnungsgemäß behandelt werden. Die Konsistenz der gesicherten Daten darf durch Verbindungsabbrüche nicht beeinträchtigt werden.
Bei beiden Verfahren zur Datensicherung ist es wünschenswert, das Volumen der zu sichernden Daten zu minimieren. Neben dem Einsatz verlustfreier Kompressionsverfahren, die in viele Datensicherungsprogrammen integriert sind, können auch inkrementelle oder differentielle Sicherungsverfahren zum Einsatz kommen, hierdurch erhöht sich jedoch u.U. der Aufwand für die Wiederherstellung einer Datensicherung.
[eh BCP 1.8]

10.5.9 Verpflichtung der MitarbeiterInnen zur Datensicherung

ISO Bezug: 27002 8.2.2, 10.5.1
Da die Datensicherung eine wichtige IT-Sicherheitsmaßnahme darstellt, sollten die betroffenen MitarbeiterInnen - vorzugsweise in schriftlicher Form - zur Einhaltung des Datensicherungskonzeptes bzw. des Minimaldatensicherungskonzeptes verpflichtet werden. Eine regelmäßige Motivation zur Datensicherung und Kontrolle auf Einhaltung ist empfehlenswert.
[eh BCP 1.9]

10.6 Netzsicherheit

Zur Unterstützung der System-/Netzwerkadministration ist der Einsatz von entsprechenden Tools (z. B. CAD-Programmen, speziellen Tools für Netzpläne, Kabelmanagementtools im Zusammenhang mit Systemmanagementtools o.ä.) empfehlenswert. Eine konsequente Aktualisierung aller Informationen bei Umbauten oder Erweiterungen ist ebenso zu gewährleisten wie eine eindeutige und nachvollziehbare Dokumentation (vgl. auch 9.4.1 Lagepläne der Versorgungsleitungen).
Gerade im Zusammenhang mit dem Absichern von Netzwerken gibt es eine Reihe weiterführender Literatur. Exemplarisch sei an dieser Stelle „The 60 Minute Network Security Guide“ der NSA [NSA-SD7] genannt.

10.6.1 Sicherstellung einer konsistenten Systemverwaltung

ISO Bezug: 27002 6.1.2, 10.10.1,10.10.2, 10.10.4, 11.1.1, 11.5.2, 12.4.1
In vielen komplexen IT-Systemen gibt es eine Administratorrolle, die keinerlei Beschränkungen unterliegt. Durch fehlende Beschränkungen ist die Gefahr von Fehlern oder Missbrauch besonders hoch.
Um Fehler zu vermeiden, soll unter dem Super-User-Login nur gearbeitet werden, wenn es notwendig ist. Andere Arbeiten sollen auch die AdministratorInnen nicht unter der Administratorkennung erledigen. Insbesondere dürfen keine Programme anderer BenutzerInnen unter der Administratorkennung aufgerufen werden. Ferner sollte die routinemäßige Systemverwaltung (z. B. Backup, Einrichten neuer BenutzerInnen) nur menügesteuert durchgeführt werden können.
Für alle AdministratorInnen sind zusätzliche Benutzerkennungen einzurichten, die nur über die eingeschränkten Rechte verfügen, die die AdministratorInnen zur Aufgabenerfüllung außerhalb der Administration benötigen. Für Arbeiten, die nicht der Administration dienen, sollen die AdministratorInnen ausschließlich diese zusätzlichen Benutzerkennungen verwenden.
Falls das Betriebssystem erlaubt, sollten die AdministratorInnen grundsätzlich nicht als Superuser, sondern unter ihrer persönlichen Benutzerkennung einsteigen und erst dann in die Superuser-Rolle wechseln.
Bekannte Kennungen, wie etwa root, guest oder administrator, sind zu löschen, stillzulegen oder nach Bedarf zu modifizieren. Bekannte Passwörter (Firmenkennungen und Firmen-Passwörter) sind zu löschen bzw. zu ändern, insbesondere bei Netzwerkkomponenten (Router, Switches, …).
Alle durchgeführten Änderungen sollten dokumentiert werden, um diese nachvollziehbar zu machen und die Aufgabenteilung zu erleichtern.
[eh SYS 6.1]

10.6.2 Ist-Aufnahme der aktuellen Netzsituation

ISO Bezug: 27002 6.2.1, 7.1.1, 10.6.2, 11.4
Die Bestandsaufnahme der aktuellen Netzsituation ist Voraussetzung für
  • eine gezielte Sicherheitsanalyse des bestehenden Netzes sowie für
  • die Erweiterung eines bestehenden Netzes.
Hierzu ist eine Ist-Aufnahme mit einhergehender Dokumentation der folgenden Aspekte, die z.T. aufeinander aufbauen, notwendig:
  • Netztopographie,
  • Netztopologie,
  • verwendete Netzprotokolle,
  • Kommunikationsübergänge im LAN und zum WAN sowie
  • Netzperformance und Verkehrsfluss.
Unter der Topographie eines Netzes wird die rein physikalische Struktur eines Netzes in Form der Kabelführung verstanden. Im Gegensatz dazu handelt es sich bei der Netztopologie um die logische Struktur eines Netzes. Die Topographie und Topologie eines Netzes sind nicht notwendig identisch.
[eh SYS 6.3]

10.6.3 Analyse der aktuellen Netzsituation

ISO Bezug: 27002 7.1.1, 10.6.2, 11.4, 11.4.7, 12.6.1
Diese Maßnahme baut auf den Ergebnissen der Ist-Aufnahme nach 10.6.2 Ist-Aufnahme der aktuellen Netzsituation auf und erfordert spezielle Kenntnisse im Bereich der Netztopologie, der Netztopographie und von netzspezifischen Schwachstellen. Darüber hinaus ist Erfahrung bei der Beurteilung der eingesetzten individuellen IT-Anwendungen hinsichtlich Vertraulichkeit, Integrität bzw. Verfügbarkeit notwendig.
Eine Analyse der aktuellen Netzsituation besteht im Wesentlichen aus einer Strukturanalyse, einer Schutzbedarfsfeststellung und einer Schwachstellenanalyse.

Strukturanalyse

Diese besteht aus einer Analyse der nach 10.6.2 Ist-Aufnahme der aktuellen Netzsituation angelegten Dokumentationen. Die Strukturanalyse muss von einem Analyseteam durchgeführt werden, das in der Lage ist, alle möglichen Kommunikationsbeziehungen nachzuvollziehen oder auch herleiten zu können.
Als Ergebnis muss das Analyseteam die Funktionsweise des Netzes verstanden haben und über die prinzipiellen Kommunikationsmöglichkeiten informiert sein. Häufig lassen sich bei der Strukturanalyse bereits konzeptionelle Schwächen des Netzes identifizieren.

Detaillierte Schutzbedarfsfeststellung

Bei besonders schutzwürdigen Applikationen sind in einer detaillierten Schutzbedarfsfeststellung zusätzlich die Anforderungen an Vertraulichkeit, Verfügbarkeit und Integrität in einzelnen Netzbereichen bzw. Segmenten zu berücksichtigen.
Hierzu ist es notwendig festzustellen, welche Anforderungen aufgrund der verschiedenen IT-Verfahren bestehen und wie diese auf die gegebene Netzsegmentierung Einfluss nehmen. Als Ergebnis muss erkenntlich sein, in welchen Netzsegmenten besondere Sicherheitsanforderungen bestehen.

Analyse von Schwachstellen im Netz

Basierend auf den bisher vorliegenden Ergebnissen erfolgt eine Analyse der Schwachpunkte des Netzes.
Hierzu gehört insbesondere bei entsprechenden Verfügbarkeitsanforderungen die Identifizierung von nicht redundant ausgelegten Netzkomponenten (Single-Point-of-Failures). Weiters müssen die Bereiche benannt werden, in denen die Anforderungen an Verfügbarkeit, Vertraulichkeit oder Integrität nicht eingehalten werden können bzw. besonderer Aufmerksamkeit bedürfen. Zudem ist festzustellen, ob die gewählte Segmentierung hinsichtlich Bandbreite und Performance geeignet ist.
Es ist zu beachten, dass diese Maßnahme insbesondere in der Designphase für ein neues Netz oder einen neuen Netzteil sinnvoll ist, Änderungen in bestehenden Netzen können aus wirtschaftlichen Aspekten oft sehr schwierig sein.
[eh SYS 6.4]

10.6.4 Entwicklung eines Netzkonzeptes

ISO Bezug: 27002 10.6.1, 11.4
Um den Anforderungen bezüglich Verfügbarkeit (auch Bandbreite und Performance), Vertraulichkeit und Integrität zu genügen, muss der Aufbau, die Änderung bzw. die Erweiterung eines Netzes sorgfältig geplant werden. Hierzu dient die Erstellung eines Netzkonzeptes.
Die Entwicklung eines Netzkonzeptes unterteilt sich in einen analytischen und einen konzeptionellen Teil:

Analyse

Zunächst ist zu unterscheiden, ob ein bestehendes Netz zu erweitern bzw. zu verändern ist oder ob das Netz vollständig neu aufgebaut werden soll.
Im ersten Fall sind vorab die Maßnahmen 10.6.2 Ist-Aufnahme der aktuellen Netzsituation und 10.6.3 Analyse der aktuellen Netzsituation zu bearbeiten. Im zweiten Fall entfallen diese Maßnahmen. Stattdessen sind die Anforderungen an die Netzkommunikation zu ermitteln sowie eine Schutzbedarfsfeststellung des zukünftigen Netzes durchzuführen.
Zur Ermittlung der Kommunikationsanforderungen ist der zukünftig zu erwartende Daten- und Verkehrsfluss zwischen logischen oder organisatorischen Einheiten festzustellen, da die zu erwartende Last die Segmentierung des zukünftigen Netzes beeinflussen muss. Die notwendigen logischen bzw. physikalischen Kommunikationsbeziehungen (dienste-, anwender-, gruppenbezogen) sind ebenfalls zu eruieren und die Kommunikationsübergänge zur LAN/LAN-Kopplung oder über ein WAN zu ermitteln.
Die Schutzbedarfsanforderungen des Netzes werden aus denen der geplanten oder bereits bestehenden IT-Verfahren abgeleitet. Daraus werden physikalische und logische Segmentstrukturen gefolgert, so dass diesen Anforderungen (z. B. hinsichtlich Vertraulichkeit) durch eine Realisierung des Netzes Rechnung getragen werden kann. Zum Beispiel bestimmt der Schutzbedarf einer IT-Anwendung die zukünftige Segmentierung des Netzes.
Schließlich muss versucht werden, die abgeleiteten Kommunikationsbeziehungen mit den Schutzbedarfsanforderungen zu harmonisieren. Unter Umständen sind hierzu Kommunikationsbeziehungen einzuschränken, um dem festgestellten Schutzbedarf gerecht zu werden.
Abschließend sind die verfügbaren Ressourcen zu ermitteln. Hierzu gehören sowohl Personalressourcen, die erforderlich sind, um ein Konzept zu erstellen und umzusetzen bzw. um das Netz zu betreiben, als auch die hierfür notwendigen finanziellen Ressourcen.
Die Ergebnisse sind entsprechend zu dokumentieren.

Konzeption

Im nächsten Schritt sind die Netzstruktur und die zu beachtenden Randbedingungen zu entwickeln. Dabei sind neben den oben genannten Gesichtspunkten auch die künftig zu erwartenden Anforderungen (z. B. hinsichtlich Bandbreite) sowie die örtlichen Gegebenheiten zu berücksichtigen.
Die Erstellung eines Netzkonzeptes erfolgt analog 10.6.2 Ist-Aufnahme der aktuellen Netzsituation und besteht danach prinzipiell aus den folgenden Schritten, wobei diese Schritte nicht in jedem Fall streng aufeinander folgend ausgeführt werden können. In einigen Teilen beeinflussen sich die Ergebnisse der Schritte gegenseitig, so dass eine regelmäßige Überprüfung und Konsolidierung der Teilergebnisse vorgenommen werden muss.
  1. Konzeption der Netztopographie und der Netztopologie, der physikalischen und logischen Segmentierung
  2. Konzeption der verwendeten Netzprotokolle
  3. Konzeption von Kommunikationsübergängen im LAN und WAN
[eh SYS 6.5]

10.6.5 Entwicklung eines Netzmanagementkonzeptes

ISO Bezug: 27002 10.6.1, 10.10
Netzmanagement umfasst die Gesamtheit der Vorkehrungen und Aktivitäten zur Sicherstellung des effektiven Einsatzes eines Netzes. Hierzu gehört beispielsweise die Überwachung der Netzkomponenten auf ihre korrekte Funktion, das Monitoring der Netzperformance und die zentrale Konfiguration der Netzkomponenten.
Netzmanagement ist in erster Linie eine organisatorische Problemstellung, deren Lösung mit technischen Mitteln - einem Netzmanagementsystem - lediglich unterstützt werden kann. Abzugrenzen vom Netzmanagement ist das Systemmanagement, welches sich in erster Linie mit dem Management verteilter Systeme befasst. Hierzu gehören beispielsweise eine zentrale Verwaltung der BenutzerInnen, Softwareverteilung, Management der Anwendungen usw. In einigen Bereichen, wie z. B. dem Konfigurationsmanagement (dem Überwachen und Konsolidieren von Konfigurationen eines Systems oder einer Netzkomponente) sind Netz- und Systemmanagement nicht klar zu trennen. In der ISO/IEC-Norm 7498-4 bzw. als X.700 der ITU-T ( [ITU-T]) ist ein Netz- und Systemmanagement-Framework definiert.
Vor der Beschaffung und dem Betrieb eines solchen Netzmanagementsystems ist im ersten Schritt ein Konzept zu erstellen, in dem alle Sicherheitsanforderungen an das Netzmanagement formuliert und angemessene Maßnahmen für den Fehler- oder Alarmfall vorgeschlagen werden. Dabei sind insbesondere die folgenden Bestandteile eines Netzmanagementkonzeptes bei der Erstellung zu berücksichtigen und in einem Gesamtzusammenhang darzustellen:
  • Performancemessungen zur Netzanalyse (siehe 10.6.3 Analyse der aktuellen Netzsituation),
  • Reaktionen auf Fehlermeldungen der überwachten Netzkomponenten,
  • Fernwartung/Remote-Control, insbesondere der aktiven Netzkomponenten,
  • Generierung von Trouble-Tickets und Eskalation bei Netzproblemen,
  • Protokollierung und Audit (online oder offline),
  • Einbindung eventuell vorhandener proprietärer Systeme bzw. von Systemen mit unterschiedlichen Managementprotokollen (z. B. im Telekommunikationsbereich),
  • Konfigurationsmanagement aller im Einsatz befindlichen IT-Systeme,
  • verteilter Zugriff auf die Netzmanagementfunktionalitäten. (Für die Administration oder für das Audit kann ein Remotezugriff auf die Netzmanagementfunktionalitäten notwendig sein. Hier ist insbesondere eine sorgfältige Definition und Vergabe der Zugriffsrechte notwendig.)
[eh SYS 6.6]

10.6.6 Sicherer Betrieb eines Netzmanagementsystems

ISO Bezug: 27002 10.6.1, 10.6.2
Für den sicheren Betrieb eines Netzmanagementtools oder eines komplexen Netzmanagementsystems, welches beispielsweise aus mehreren verschiedenen Netzmanagementtools zusammengesetzt sein kann, ist die sichere Konfiguration aller beteiligten Komponenten zu überprüfen und sicherzustellen. Hierzu gehören die Betriebssysteme, auf denen das oder die Netzmanagementsysteme betrieben werden, die zumeist notwendigen externen Datenbanken für ein Netzmanagementsystem, das verwendete Protokoll und die aktiven Netzkomponenten selbst. Vor dem Betrieb eines Netzmanagementsystems muss die Ermittlung der Anforderungen an den Betrieb und die Erstellung eines Netzmanagementkonzeptes stehen (siehe 10.6.5 Entwicklung eines Netzmanagementkonzeptes).
Für den sicheren Betrieb eines Netzmanagementsystems sind folgende Daten relevant:
  • Konfigurationsdaten des Netzmanagementsystems, die sich in entsprechend geschützten Verzeichnissen befinden müssen.
  • Konfigurationsdaten der Netzkomponenten (Metakonfigurationsdateien), die sich ebenfalls in entsprechend geschützten Verzeichnissen befinden müssen.
  • Passwortdateien für das Netzmanagementsystem. Hierbei ist beispielsweise auf die Güte des Passwortes und die Möglichkeit einer verschlüsselten Speicherung des Passwortes zu achten.
  • Eine Administration der aktiven Netzkomponenten über das Netz sollte dann eingeschränkt werden und eine Administration über die lokalen Schnittstellen erfolgen, wenn die Erfüllung der Anforderungen an Vertraulichkeit und Integrität der Netzmanagementinformationen nicht gewährleistet werden kann. In diesem Fall ist auf ein zentrales Netzmanagement zu verzichten.
[eh SYS 6.7]

10.6.7 Sichere Konfiguration der aktiven Netzkomponenten

ISO Bezug: 27002 10.6.1, 11.4.4, 11.7.2
Neben der Sicherheit von Serversystemen und Endgeräten wird die eigentliche Netzinfrastruktur mit den aktiven Netzkomponenten in vielen Fällen vernachlässigt. Gerade zentrale aktive Netzkomponenten müssen jedoch sorgfältig konfiguriert werden. Denn während durch eine fehlerhafte Konfiguration eines Serversystems nur diejenigen BenutzerInnen betroffen sind, die die entsprechenden Dienste dieses Systems nutzen, können bei einer Fehlkonfiguration eines Routers/Switches größere Teilnetze bzw. sogar das gesamte Netz ausfallen oder Daten unbemerkt kompromittiert werden.
Im Rahmen des Netzkonzeptes (siehe 10.6.4 Entwicklung eines Netzkonzeptes) sollte auch die sichere Konfiguration der aktiven Netzkomponenten festgelegt werden. Dabei gilt es insbesondere Folgendes zu beachten:
  • Für Router und Layer-3-Switching muss ausgewählt werden, welche Protokolle weitergeleitet und welche nicht durchgelassen werden. Dies kann durch die Implementation geeigneter Filterregeln geschehen.
  • Es muss festgelegt werden, welche IT-Systeme in welcher Richtung über die Router kommunizieren. Auch dies kann durch Filterregeln realisiert werden.
  • Sofern dies von den aktiven Netzkomponenten unterstützt wird, sollte festgelegt werden, welche IT-Systeme Zugriff auf die Ports der Switches und Hubs des lokalen Netzes haben. Hierzu wird die MAC-Adresse (Media Access Control) des zugreifenden IT-Systems ausgewertet und auf ihre Berechtigung hin überprüft.
Für aktive Netzkomponenten mit Routing-Funktionalität ist außerdem ein geeigneter Schutz der Routing-Updates erforderlich. Diese sind zur Aktualisierung der Routing-Tabellen erforderlich, um eine dynamische Anpassung an die aktuellen Gegebenheiten des lokalen Netzes zu erreichen. Dabei kann man zwei verschiedene Sicherheitsmechanismen unterscheiden:
  • Passwörter
    Die Verwendung von Passwörtern schützt die so konfigurierten Router vor der Annahme von Routing-Updates durch Router, die nicht über das entsprechende Passwort verfügen. Hierdurch können also Router davor geschützt werden, falsche oder ungültige Routing-Updates anzunehmen. Der Vorteil von Passwörtern gegenüber den anderen Schutzmechanismen ist ihr geringer Overhead, der nur wenig Bandbreite und Rechenzeit benötigt.
  • Kryptographische Prüfsummen
    Prüfsummen dienen zur Wahrung der Integrität von gültigen Routing-Updates, bzw. Message Authentication Codes schützen vor deren unbemerkten Veränderungen. Dies wird in der Regel bereits durch das Routing Protokoll gewährleistet.
Vgl. auch den NSA „Router Security Configuration Guide“ [NSA-CIS2].
[eh SYS 6.8]

10.6.8 Festlegung einer Sicherheitsstrategie für ein Client-Server-Netz

ISO Bezug: 27002 6.2.3, 8.2.2, 8.3.3, 10.1, 10.6, 10.9, 10.10, 11.1, 11.2, 11.4.1, 11.5, 11.7.1
Nachfolgend wird eine methodische Vorgehensweise aufgezeigt, mittels derer eine umfassende Sicherheitsstrategie für ein Client-Server-Netz entwickelt werden kann. Abhängig vom verwendeten Betriebssystem und den eingesetzten Konfigurationen ist für die jeweilige Ausprägung individuell zu entscheiden, welche der beschriebenen Schritte anzuwenden sind.
In der Sicherheitsstrategie muss aufgezeigt werden, wie ein Client-Server-Netz für die jeweilige Organisation sicher aufgebaut, administriert und betrieben wird. Nachfolgend werden die einzelnen Entwicklungsschritte einer solchen Strategie vorgestellt:
  1. Definition der Client-Server-Netzstruktur
    Im ersten Schritt sind die logische Struktur des Client-Server-Netzes, insbesondere die Zuordnung der Server und der Netz-Domänen festzulegen. Nach Möglichkeit sollte auf die Verwendung von Peer-to-Peer-Funktionalitäten verzichtet werden, da diese die Sicherheit des Client-Server-Netzes beeinträchtigen können. Sofern sich dies jedoch nicht vermeiden lässt, sind verbindliche Regelungen für die Nutzung von Peer-to-Peer-Funktionalitäten zu treffen.
  2. Regelung der Verantwortlichkeiten
    Ein Client-Server-Netz sollte von geschulten (Netz-)AdministratorInnen nebst StellvertreterInnen sicher betrieben werden. Diese allein dürfen Sicherheitsparameter im Client-Server-Netz verändern. Sie sind z. B. dafür zuständig, auf den Servern den entsprechenden Verantwortlichen Administrationsrechte und -werkzeuge zur Verfügung zu stellen, damit diese die Vergabe von Datei- und Verzeichnisberechtigungen, die Freigabe der von anderen benötigten Verzeichnisse bzw. Anwendungen, den Aufbau von Benutzergruppen und -accounts sowie die Einstellung der Systemrichtlinien für BenutzerInnen, Zugriffskontrolle und Überwachung vornehmen können. Die Verantwortlichkeiten der einzelnen BenutzerInnen im Client-Server-Netz sind unter Schritt 11 dargestellt.
  3. Festlegung von Namenskonventionen
    Um die Verwaltung des Client-Server-Netzes zu erleichtern, sollten eindeutige Namen für die Rechner, Benutzergruppen und die BenutzerInnen verwendet werden. Zusätzlich sollten Namenskonventionen für die Freigabenamen von Verzeichnissen oder Druckern eingeführt werden. Sollen keine Rückschlüsse auf den Inhalt eines freigegebenen Verzeichnisses möglich sein, sind entsprechende Pseudonyme zu verwenden.
  4. Festlegung der Regeln für Benutzeraccounts
    Vor der Einrichtung von Benutzeraccounts sollten die Restriktionen, die für alle bzw. für bestimmte dieser Accounts gelten sollen, festgelegt werden. Dies betrifft insbesondere die Regelungen für Passwörter und für die Reaktion des Systems auf fehlerhafte Login-Vorgänge.
  5. Einrichtung von Gruppen
    Zur Vereinfachung der Administration sollten Benutzeraccounts, für die die gleichen Anforderungen gelten, zu Gruppen zusammengefasst werden. Benutzerrechte sowie Datei-, Verzeichnis- und Freigabeberechtigungen und ggf. weitere vordefinierte Funktionen werden dann den Gruppen und nicht einzelnen Benutzeraccounts zugeordnet. Die Benutzeraccounts erben die Rechte und Berechtigungen der Gruppen, denen sie angehören. So ist es z. B. denkbar, alle MitarbeiterInnen einer Abteilung in einer Gruppe zusammenzufassen. Eine Zuweisung von Benutzerrechten und -berechtigungen an einzelne BenutzerInnen sollte nur erfolgen, wenn dies ausnahmsweise unumgänglich ist.
  6. Festlegung von Benutzerrechten
    Rechte gestatten den BenutzerInnen die Ausführung bestimmter Aktionen auf dem System. Sie beziehen sich auf das gesamte System, sind keinem speziellen Objekt zugeordnet und können die Berechtigungen für ein Objekt außer Kraft setzen, da ein Recht Vorrang vor allen Datei- und Verzeichnisberechtigungen haben kann.
  7. Festlegung der Vorgaben für Protokollierung
    Bei der Konfiguration der Protokollierung ist zu beachten, dass ein Mehr an Protokollierung nicht unbedingt auch die Sicherheit des überwachten Systems erhöht. Protokolldateien, die nicht ausgewertet werden oder die aufgrund ihres Umfangs nur mit großem Aufwand auswertbar sind, führen nicht zu einer besseren Kontrolle der Systemabläufe, sondern sind letztlich nutzlos. Aus diesen Gründen sollte die Protokollierung so eingestellt werden, dass sie im Normalfall nur die wirklich bedeutsamen Ereignisse aufzeichnet. Dabei sind selbstverständlich die gesetzlichen Vorgaben, insbesondere die Anforderungen aus dem Datenschutzgesetz, vorrangig zu beachten (vgl. dazu auch 10.10 Protokollierung und Monitoring).
  8. Regelungen zur Datenspeicherung
    Es ist festzulegen, wo Benutzerdaten gespeichert werden. So ist denkbar, dass Benutzerdaten nur auf einem Server abgelegt werden. Eine Datenspeicherung auf der lokalen Festplatte ist bei diesem Modell nicht erlaubt. Möglich ist aber auch, bestimmte Benutzerdaten nur auf der lokalen Festplatte abzulegen. Nach welcher Strategie verfahren werden soll, muss jeweils im konkreten Einzelfall festgelegt werden. Eine generelle Empfehlung ist hier nicht möglich.
  9. Einrichtung von Projektverzeichnissen
    Um eine saubere Trennung von benutzer- und projektspezifischen Daten untereinander sowie von den Programmen und Daten des Betriebssystems durchzusetzen, sollte eine geeignete Verzeichnisstruktur festgelegt werden, mit der eine projekt- und benutzerbezogene Dateiablage unterstützt wird. So können beispielsweise zwei Hauptverzeichnisse „Projekte“ und „Benutzer“ angelegt werden, unter denen dann die Dateien und Verzeichnisse der Projekte bzw. BenutzerInnen in jeweils eigenen Unterverzeichnissen abgelegt werden.
  10. Vergabe der Zugriffsrechte
    Es ist festzulegen, welche Verzeichnisse und evtl. welche Dateien für den Betrieb freizugeben und welche Zugriffsrechte ihnen zuzuweisen sind. Dies gilt analog für die Freigabe von Druckern.
  11. Verantwortlichkeiten für AdministratorInnen und BenutzerInnen im Client-Server-Netz
    Neben der Wahrnehmung der Netzmanagementaufgaben (siehe Pkt. 2) müssen weitere Verantwortlichkeiten festgelegt werden. Es ist festzulegen, welche Verantwortung die einzelnen AdministratorInnen im Client-Server-Netz übernehmen müssen. Dies können zum Beispiel Verantwortlichkeiten sein für
    • die Auswertung der Protokolldateien auf den einzelnen Servern oder Clients,
    • die Vergabe von Zugriffsrechten,
    • das Hinterlegen und den Wechsel von Passwörtern und
    • die Durchführung von Datensicherungen.
    Auch die EndbenutzerInnen müssen in einem Client-Server-Netz bestimmte Verantwortlichkeiten übernehmen, sofern ihnen Rechte zur Ausführung administrativer Funktionen gegeben werden. In der Regel beschränken sich diese Verantwortlichkeiten jedoch auf die Vergabe von Zugriffsrechten auf die eigenen Dateien, sofern diese explizit festgelegt und nicht von Voreinstellungen des übergeordneten Verzeichnisses übernommen werden.
  12. Schulung
    Abschließend muss festgelegt werden, welche BenutzerInnen zu welchen Punkten geschult werden müssen. Erst nach ausreichender Schulung kann der Echtbetrieb aufgenommen werden. Insbesondere die AdministratorInnen sind hinsichtlich der Verwaltung und der Sicherheit des Systems gründlich zu schulen.
Die so entwickelte Sicherheitsstrategie ist zu dokumentieren und im erforderlichen Umfang den BenutzerInnen des Client-Server-Netzes mitzuteilen. Weiters ist sie laufend etwaigen Veränderungen im Einsatzumfeld anzupassen.
[eh SYS 6.10]

10.6.9 Wireless LAN (WLAN)

ISO Bezug: 27002 10.6.2 (teilweise), 11.4
Drahtlose Netzwerke bzw. so genannte Wireless LAN (WLAN) – Lösungen ergänzen zunehmend LANs. Zum einen bieten sie Flexibilität bei der Arbeitsplatzgestaltung und zum anderen sind für deren Aufbau keine aufwendigen Verkabelungsarbeiten notwendig. Die steigende Zahl von portablen Computern (Notebooks, PDAs, Smartphones etc.) unterstreicht die Forderung nach einem WLAN. Sicherheitstechnisch entstehen neue Gefährdungen und es sind einige Maßnahmen zu beachten, um nicht durch die Einführung von WLANs die Sicherheit des gesamten lokalen Netzwerkes zu kompromittieren.
Folgende Maßnahmen sind zu beachten, wenn es um die Installation und Konfiguration eines WLANs geht:
  • Geeignete Positionierung und Ausrichtung der Zugriffspunkte und Antennen:
    Die Ausstrahlung über die Organisationsgrenzen hinweg soll weitgehend verhindert werden. Der Einsatz von Richtantennen hilft dabei die unbeabsichtigte räumliche Ausstrahlung zu unterbinden.
  • Testen des Umkreises:
    Der mögliche Empfang im Umkreis der Organisation muss überprüft werden. Bei unerwünschten Reichweiten müssen entsprechende Gegenmaßnahmen ergriffen werden.
  • Deaktivieren des Sendens der Service Set ID:
    Die Service Set ID (SSID) ist der Name des WLANs, über den Clients ein bestimmtes Netz erkennen. Die Bekanntgabe an Knoten, die diese eindeutige SSID nicht kennen, ist zu verhindern, d. h. das Senden der SSID ist zu deaktivieren (auch wenn das eigentlich keine echte Erhöhung der Sicherheit bedeutet).
  • Geeignete Verschlüsselungsoptionen aktivieren:
    Verschlüsselungsoptionen wie WiFi Protected Access 2 (WPA2) bieten Schutz vor Zugriffen durch Dritte. Bei WEP (Wired Equivalent Privacy) wird nur ein einziger, statischer Schlüssel verwendet, d. h. in jeder WLAN-Komponente in einem Netz muss derselbe WEP-Schlüssel eingetragen sein. Weiters sieht WEP kein dynamisches Schlüsselmanagement vor, so dass die Schlüssel manuell administriert werden müssen. Da WEP-Schlüssel in kürzester Zeit kompromittiert werden können, sollte WEP nicht mehr eingesetzt werden. Bei der Schlüssellänge ist es sinnvoll den Schlüssel mit der größten Länge zu wählen, sofern die verwendeten Endgeräte dies zulassen. Die verwendbaren Schlüssellängen sollten demnach bei der Anschaffung der WLAN-Komponenten bereits berücksichtigt werden. Bei WPA wird TKIP (Temporal Key Integrity Protocol) eingesetzt, das die Nutzung dynamischer kryptographischer Schlüssel statt ausschließlich statischer bei WEP erlaubt. Bei IEEE (Institute of Electrical and Electronics Engineers) 802.11i (WPA2) kommt zusätzlich CCMP (Counter-Mode/CBC-Mac Protocol) als kryptographisches Verfahren zur Integritätssicherung und zur Verschlüsselung der Nutzdaten hinzu. TKIP und CCMP sind symmetrische Verfahren, alle Kommunikationspartner müssen daher einen gemeinsamen Schlüssel konfiguriert haben. Dieser Schlüssel wird als Pairwise Master Key (PMK) bezeichnet. Der PMK kann über zwei verschiedene Wege auf die beteiligten WLAN-Komponenten gelangen:
    • Statische Schlüssel: Der PMK kann (analog zu WEP) manuell als ein statischer Schlüssel, als Pre-Shared Key (PSK) bezeichnet, auf Access Points und Clients konfiguriert werden. Es besteht meist die Möglichkeit den gemeinsamen geheimen Schlüssel auch über Passwörter festzulegen. Diese Passwörter werden über Hash-Funktionen in den PMK umgerechnet. Hat ein solcher PSK eine zu geringe Komplexität (im Sinne der Länge des Schlüssels und der Zufälligkeit der Zeichen), ist er anfällig gegenüber Wörterbuch- bzw. Dictionary-Attacken. Daher sollten diese Passwörter eine hohe Komplexität und eine Länge von mindestens 20 Stellen besitzen. Ab einer gewissen Größe eines WLANs ist das Ausrollen eines neuen Schlüssels mit erheblichen Problemen verbunden. Die Nutzung der PSK ist in der Kombination mit WPA bzw. WPA2 möglich. Sollte WPA-PSK bzw. WPA2-PSK verwendet werden, ist zu empfehlen, die Schlüssel zum Schutz der Kommunikation oder zur Authentisierung mindestens alle drei bis sechs Monate zu wechseln.
    • Dynamische Schlüssel: Eine höhere Sicherheit bietet ein Mechanismus zur dynamischen Schlüsselverwaltung und -verteilung, der dafür sorgt, dass regelmäßig und insbesondere nach einer erfolgreichen Authentifizierung des WLAN-Clients am Access Point ein neuer Schlüssel (PMK) bereitgestellt wird. Für diese Schlüsselverwaltung und -verteilung greift IEEE 802.11i auf einen anderen Standard zurück und zwar auf IEEE 802.1X. Dieser Standard ist zur portbasierten Netzzugangskontrolle in kabelbasierten Netzen entworfen worden. Grundsätzliche Idee in IEEE 802.1X ist, dass die Freischaltung eines Netzports erst dann erfolgt, wenn der Nutzer sich erfolgreich dem Netz gegenüber authentisiert hat. Die Authentisierung erfolgt also auf Schicht 2. Damit so etwas überhaupt funktioniert, spezifiziert IEEE 802.1X eine Schnittstelle zwischen Client, Netzelement und einem Authentisierungssystem. Diese Schnittstelle basiert auf dem Extensible Authentication Protocol (EAP) und einer Adaptierung dieses Protokolls für die Übertragung auf Layer 2 in LAN (als EAP over LAN, EAPOL bezeichnet). Hand in Hand geht damit die Festlegung einer Funktion zur Schlüsselverwaltung und -verteilung.
    Generell sollten in regelmäßigen Abständen, mindestens jedoch vierteljährlich, die Schlüsselinformationen bei allen WLAN-Komponenten ausgetauscht werden. Bei größeren Installationen sollte hierfür eine geeignete Funktion in der zentralen WLAN-Managementlösung enthalten sein, um den Arbeitsaufwand gering zu halten. Der Wechsel der Schlüsselinformationen an allen WLAN-Komponenten sollte bereits während der Planungsphase genau getestet werden, um dadurch eventuell auftretende Schwierigkeiten zu erkennen. Darüber hinaus sind zusätzliche Maßnahmen sinnvoll (z. B. VPN - siehe weiter unten).
  • Authentifikation der Knoten:
    Möglichkeiten der Authentifikation der Knoten sind zu aktivieren, etwa nach IEEE 802.1X.
  • Einsatz einer zusätzlichen Firewall:
    Eine Firewall zwischen dem Zugriffspunkt und dem eigentlichen Netzwerk kann die Sicherheit erhöhen.
  • Direkten Zugriff auf das Intranet über das WLAN sperren:
    Ist der Zugang über WLAN nicht durch starke Methoden der Authentifikation der Knoten und Verschlüsselung gesichert, ist er als RAS (Remote Access Service) anzusehen (vgl. 10.6.10 Remote Access (VPN) - Konzeption).
  • Ändern von Standardeinstellungen (Passwörtern):
    Standardeinstellungen der Zugriffspunkte – etwa Service Set ID (SSID), SNMP Community String, Administratorpasswort – sind werksseitig voreingestellt und müssen sofort geändert werden, da die Standardpasswörter AngreiferInnen durchaus bekannt sind (vgl. 11.3.1 Regelungen des Passwortgebrauches).
  • MAC-Adressfilterung am Zugriffspunkt:
    Der Zugang zu Zugriffspunkten kann bei vielen Geräten auch über die MAC-Adresse (Media Access Control) kontrolliert werden. Dies sollte nach Möglichkeit genutzt werden.
  • Nutzung eines Virtual Private Networks (VPN):
    Im WLAN sollte möglichst ein VPN etabliert werden, wodurch die vertraulichen Inhalte mittels IPsec oder SSL/TLS geschützt werden. Dies bietet über WEP/WEP+/WPA/WPA2/o.ä. hinausgehend eine Ende-zu-Ende Verschlüsselung.
  • Für den Bereich der öffentlichen Verwaltung sind entsprechende Vorgaben und WLAN-Policies der Stabsstelle IKT-Strategie des Bundes (CIO) zu beachten (z. B.: [IKT-WLAN], [IKT-CLWLAN]).
Weiterführende Informationen, speziell aber nicht nur für die Organisationen der öffentlichen Verwaltung, sind den von der Stabsstelle IKT-Strategie des Bundes (CIO) herausgegebenen Empfehlungen zur Verwendung von WLANs ( [IKT-WLAN]) zu entnehmen. In Ergänzung zu diesen allgemeine Informationen zu WLANs in der Verwaltung wurde von der Stabsstelle IKT-Strategie des Bundes (CIO) die so genannte „Checkliste WLAN“ [IKT-CLWLAN] veröffentlicht. Diese Erweiterung berücksichtigt aktuelle Weiterentwicklungen und Marktveränderungen im Bereich WLAN. Die darin enthaltene Checkliste ermöglicht ein einfaches und pragmatisches Anwenden der Empfehlungen.
[eh SYS 6.14]

10.6.10 Remote Access (VPN) - Konzeption

ISO Bezug: 10.6.2, 11.4.2, 11.7.2

Im Folgenden ist mit „Remote Access“ generell jede Art von Fernzugriff auf Geschäftsinformationen (mit z. B. auch Mobile-Computing-Geräten) über ein unsicheres resp. öffentliches Netz gemeint.

Durch Remote Access wird es den BenutzerInnen ermöglicht, sich mit einem lokalen Rechner an ein entferntes Rechnernetz zu verbinden und dessen Ressourcen zu nutzen, als ob eine direkte LAN-Koppelung bestehen würde. Dies wird meist mittels einer VPN-Verbindung zwischen einzelnen IT-Systemen, verschiedenen Standorten einer Institution oder auch zu Kunden erreicht.

Die Vernetzung vorhandener Teilnetze mit globalen Netzen wie dem Internet führt zu einem neuen Informationsangebot, lässt aber auch neue Gefährdungen entstehen, da prinzipiell nicht nur ein Informationsfluss von außen in das zu schützende Netz stattfinden kann, sondern auch in die andere Richtung. Darüber hinaus gefährdet die Möglichkeit remote, d. h. von einem entfernten Rechner aus (z. B. aus dem Internet), Befehle auf Rechnern im lokalen Netz ausführen zu lassen, die Integrität und die Verfügbarkeit der lokalen Rechner und dadurch indirekt auch die Vertraulichkeit der lokalen Daten.

Ein zu schützendes Teilnetz sollte daher nur dann an ein anderes Netz angeschlossen werden, wenn dies unbedingt erforderlich ist. Dies gilt insbesondere für Anschlüsse an das Internet. Dabei ist auch zu prüfen, inwieweit das zu schützende Netz in anschließbare, nicht anschließbare und bedingt anschließbare Teile segmentiert werden muss.

Generell lassen sich für den Einsatz von entfernten Zugängen im Wesentlichen folgende Szenarien unterscheiden:
  • das Anbinden einzelner stationärer Arbeitsplatzrechner (z. B. für Telearbeit einzelner MitarbeiterInnen),
  • das Anbinden mobiler Rechner (z. B. zur Unterstützung von MitarbeiterInnen im Außendienst oder auf Dienstreise),
  • das Anbinden von ganzen LANs (z. B. zur Anbindung von lokalen Netzen von Außenstellen oder Filialen),
  • der Managementzugriff auf entfernte Rechner (z. B. zur Fernwartung).

Für diese Szenarien bieten VPN-Technolgien eine einfache Lösung: entfernte BenutzerInnen verbinden sich über das Internet mit Hilfe von VPN-Clients mit dem Firmennetz. Alternative Möglichkeiten, die heute nur mehr wenig genutzt werden, sind RAS-Zugänge über Standleitungen oder Modemeinwahl.

Unter dem Gesichtspunkt der Sicherheit sind für entfernte Zugänge folgende Sicherheitsziele zu unterscheiden:
  1. Zugangssicherheit:
    Entfernte BenutzerInnen müssen durch das VPN- bzw. RAS-System eindeutig zu identifizieren sein. Ihre Identität muss jeweils durch einen Authentisierungsmechanismus bei jedem Verbindungsaufbau zum lokalen Netz sichergestellt werden. Im Rahmen des Systemzugangs müssen weitere Kontrollmechanismen angewandt werden, um den Systemzugang für entfernte BenutzerInnen reglementieren zu können (z. B. zeitliche Beschränkungen oder Einschränkung auf erlaubte entfernte Verbindungspunkte).
  2. Zugriffskontrolle:
    Sind die entfernten BenutzerInnen authentisiert, so muss das System in der Lage sein, ihre Remote-Zugriffe auch zu kontrollieren. Dazu müssen die Berechtigungen und Einschränkungen, die für lokale Netzressourcen durch befugte AdministratorInnen festgelegt wurden, auch für entfernte BenutzerInnen durchgesetzt werden.
  3. Kommunikationssicherheit:
    Bei einem Remote-Zugriff auf lokale Ressourcen sollen i. Allg. auch über die aufgebaute VPN- bzw. RAS-Verbindung Nutzdaten übertragen werden. Generell sollen auch für Daten, die über VPN- oder RAS-Verbindungen übertragen werden, die im lokalen Netz geltenden Sicherheitsanforderungen bezüglich Kommunikationsabsicherung (Vertraulichkeit, Integrität, Authentizität) durchsetzbar sein. Der Absicherung der VPN- bzw. RAS-Kommunikation kommt jedoch eine besondere Bedeutung zu, da zur Abwicklung der Kommunikation verschiedene Kommunikationsmedien in Frage kommen, die in der Regel nicht dem Hoheitsbereich des Betreibers des lokalen Netzes zuzurechnen sind.
  4. Verfügbarkeit:
    Wird der entfernte Zugang im produktiven Betrieb genutzt, so ist die Verfügbarkeit des Zugangs von besonderer Bedeutung. Der reibungslose Ablauf von Geschäftsprozessen kann bei Totalausfall oder bei Verbindungen mit nicht ausreichender Bandbreite unter Umständen beeinträchtigt werden. Durch die Nutzung von alternativen oder redundanten VPN-(bzw. RAS)Zugängen kann diese Gefahr bis zu einem gewissen Grad verringert werden. Dies gilt insbesondere für entfernte Zugänge, die das Internet als Kommunikationsmedium nutzen, da hier in der Regel keine Verbindungs- oder Bandbreitengarantien gegeben werden.

Ein VPN (RAS)-System besteht aus mehreren Komponenten, die zunächst als Einzelkomponenten abgesichert werden sollten. Zusätzlich zu der Absicherung der Systemkomponenten muss jedoch auch ein VPN (RAS)-Sicherheitskonzept erstellt werden, das sich in das bestehende Sicherheitskonzept eingliedert: das VPN (RAS)-System muss einerseits bestehende Sicherheitsforderungen umsetzen und erfordert andererseits das Aufstellen neuer, VPN (RAS)-spezifischer Sicherheitsregeln.

[eh Teil 2 5.7]

10.6.10.1 Durchführung einer VPN-Anforderungsanalyse

ISO Bezug: 27002 10.6.2, 11.4
Bevor eine VPN- (oder RAS-)Verbindung zwischen einzelnen IT-Systemen, verschiedenen Standorten einer Institution oder auch zu Kunden eingerichtet wird, sollte eine Anforderungsanalyse durchgeführt werden. Ziel der Anforderungsanalyse ist es einerseits, alle im konkreten Fall in Frage kommenden Einsatzszenarien zu bestimmen und andererseits daraus Anforderungen an die benötigten Hardware- und Softwarekomponenten abzuleiten. Durch das Aufstellen und Durchspielen von Nutzungsszenarien können spezielle Anforderungen an die VPN-Architektur oder die VPN-Komponenten aufgedeckt werden.
Im Rahmen der Anforderungsanalyse sind u. a. folgende Fragen zu klären:
  • Festlegung der Geschäftsprozesse: Als erstes muss geklärt werden, für welche Geschäftsprozesse das virtuelle private Netz (VPN) genutzt und welche Informationen darüber kommuniziert werden sollen. Aus den Ergebnissen müssen die benötigten Anforderungen ermittelt und gemäß ihrer Bedeutung für das Unternehmen oder die Behörde priorisiert werden. Neben den Geschäftsprozessen müssen auch die Anwendungen, die die jeweiligen Prozesse unterstützen, betrachtet werden. Hierbei muss auch erfasst werden, welche der betroffenen Anwendungen zeitkritisch oder bandbreitenintensiv sind.
  • Festlegung der Anwendungszwecke: Es gibt viele unterschiedliche Nutzungsszenarien für VPNs, wie die Durchführung von Fernwartungstätigkeiten, die Anbindung einzelner Mitarbeiter oder ganzer Standorte. Daher muss geklärt werden, welche Einsatzzwecke unterstützt werden sollen und welche VPN-Typen dafür eingesetzt werden (z. B. Site-to-Site-, End-to-End- und End-to-Site-VPNs).
  • Festlegung der BenutzerInnen: Es ist zu klären, welche Arten von BenutzerInnen mit welchen Berechtigungen und welchen Vorkenntnissen das VPN nutzen sollen (z. B. AußendienstmitarbeiterInnen, MitarbeiterInnen auf Dienstreise, MitarbeiterInnen einer Zweigstelle). Dabei ist auch zu klären, wie diese sicher identifiziert und authentisiert werden sollen.
  • Regelung von Zuständigkeiten: Auch VPN-Komponenten müssen durch fachkundiges Personal administriert und gewartet werden. Bei der Durchführung einer VPN-Anforderungsanalyse sollte daher festgelegt werden, wer für die Administration und den Betrieb des VPNs zuständig ist - und zwar auf beiden Seiten des VPNs. Im Weiteren muss geklärt werden, wer zu benachrichtigen ist, wenn das VPN ausfällt oder wenn Anzeichen für einen Sicherheitsvorfall entdeckt werden. Hierfür muss Fachpersonal vorhanden sein, das über entsprechendes Wissen verfügt.
  • Vertraulichkeit und Integrität: Je nach Schutzbedarf bezüglich der Vertraulichkeit und Integrität werden häufig besondere Anforderungen an das VPN gestellt, die i. Allg. durch zusätzliche Sicherheitsmaßnahmen abgedeckt werden können. In vielen Fällen existieren hierzu übergeordnete Regelungen oder Richtlinien, die bei der Beschaffung und beim Betrieb von VPN-Komponenten berücksichtigt werden müssen. Um Informationen mit hohem Schutzbedarf bezüglich Vertraulichkeit oder Integrität zu übertragen, empfiehlt es sich, gemäß den [Common Criteria] zertifizierte VPN-Komponenten einzusetzen.
  • Verfügbarkeit: Besonders bei einer Standortvernetzung wird häufig gewünscht, dass zu jeder Zeit ausreichend schnell Informationen über das VPN ausgetauscht werden können. Besitzen die betroffenen Anwendungen einen höheren Schutzbedarf bezüglich der Verfügbarkeit, sollte dies bei der Anforderungsanalyse berücksichtigt werden. Erhöhte Anforderungen an die Verfügbarkeit lassen sich bei VPNs nicht immer durch technische Sicherheitsmaßnahmen abdecken, da VPNs oft über Netze aufgebaut werden, die nicht unter der eigenen Kontrolle stehen und somit nicht beeinflusst werden können.
  • Beschränkung der Netze: Mit VPNs können verschiedene Netze durch Nutzung einer sicheren Verbindung zu einem logischen Netz zusammengefasst werden. Je nach Konfiguration können dadurch alle IT-Systeme eines Netzes auf alle IT-Systeme oder nur auf bestimmte IT-Systeme der anderen Netze zugreifen. Bei der VPN-Anforderungsanalyse sollte entschieden werden, von wo über das jeweilige VPN auf welches Netz und auf welche IT-Systeme zugegriffen werden darf.
  • Auswahl der genutzten Applikationen und -protokolle: Über ein VPN können unterschiedliche Arten von Informationen versendet und empfangen werden. Beispielsweise können E-Mails übertragen, Dateien kopiert oder auf einen Webserver zugegriffen werden. Neben diesen klassischen Diensten kann auch auf einem Terminalserver gearbeitet oder über VoIP telefoniert werden. Es sollte daher festgelegt werden, welche Applikationen über ein VPN genutzt werden dürfen und welche nicht. Es muss nicht nur entschieden werden, welche Applikationen eingesetzt werden dürfen, sondern auch die Protokolle, mit denen die Informationen übertragen werden können. Beispielsweise kann festgelegt werden, dass Netzfreigaben nur über SMB (Server Message Block) statt NFS (Network File System) eingebunden werden dürfen.
  • Bandbreite und Verzögerung: Ein VPN ermöglicht es, auf Applikationen in einem entfernten Netz zuzugreifen. Da VPN-Verbindungen oft über ein WAN aufgebaut werden, müssen für zeitkritische Anwendungen spezielle Voraussetzungen berücksichtigt werden, besonders im Hinblick auf die verfügbare Bandbreite und Verzögerungen bei der Übertragung. Dies betrifft beispielsweise Zugriffe auf Terminalserver oder die Telefonie über VoIP. Für die VPN-Anforderungsanalyse sollten die benötigten Bandbreiten, die zulässige Verzögerung sowie gegebenenfalls weitere Qualitätsmerkmale des Netzes berücksichtigt werden.
  • Geographische Beschränkungen: Ein VPN kann dazu dienen, dass sich mobile Mitarbeiter von beliebigen Orten unterwegs ins Institutions-LAN einwählen können. Wenn dies aber nicht gewünscht wird, sollte festgelegt werden, von wo auf das LAN zugegriffen werden darf. Dies kann auch technisch unterstützt werden. Beispielsweise könnte nur der IP-Adressbereich eines oder weniger Provider zugelassen werden. Bei einer Wählverbindung könnte anhand der Ländervorwahl gefiltert werden. Zu beachten ist jedoch, dass diese technischen Zugriffsbeschränkungen nicht absolut zuverlässig sind. Zusätzlich müssen also den BenutzerInnen entsprechende organisatorische Vorgaben gemacht werden.
Diese Punkte müssen nicht zwangsläufig pauschal für die gesamte Institution betrachtet, sondern können auch differenziert auf einzelne Standorte oder Anwendungszwecke angewendet werden. Besonders bei der Vernetzung von mehreren Standorten kommt häufig nicht jeder Liegenschaft die gleiche Priorität zu. An kleine Vertriebsbüros werden beispielsweise meist andere Anforderungen bezüglich Verfügbarkeit gestellt als an Unternehmenszentralen. Ebenso bestehen an End-to-End-VPNs andere Anforderungen als an Site-to-Site-VPNs. Als Lösungsansatz könnten die verschiedenen Anwendungszwecke zum Beispiel bezüglich ihrer Anforderungen an Bandbreite, Verfügbarkeit, Vertraulichkeit, Integrität und Dienstgüte (Quality of Service oder kurz QoS) klassifiziert werden.
Die Anforderungen für die geplanten Szenarien sind zu dokumentieren und mit den NetzadministratorInnen und dem technischen Personal abzustimmen.
[eh SYS 7.1]

10.6.10.2 Entwicklung eines VPN-Konzeptes

ISO Bezug: 27002 10.6.2, 11.4
Ein VPN-Konzept kann grob in drei Teilbereiche unterteilt werden:
  • Organisatorisches Konzept
  • Technisches Konzept
  • Sicherheitskonzept
Im Folgenden werden jeweils die wesentlichen Fragestellungen aufgezeigt, die im Rahmen der Teilkonzepte beantwortet werden müssen. Je nach konkreter Situation ergibt sich naturgemäß ein speziell auf die jeweiligen organisatorischen und technischen Gegebenheiten zugeschnittener zusätzlicher Abstimmungsbedarf.
Das organisatorische Konzept sollte folgende Punkte beinhalten bzw. regeln:
  • Es sollten die Verantwortlichkeiten für das jeweilige VPN festgelegt werden (Installation, Verwaltung, Überprüfung, Überwachung). Je nach organisatorischer Struktur müssen die Verantwortlichkeiten existierender Rollen erweitert oder neue Rollen geschaffen werden.
  • Es muss festgelegt werden, wie und von wem die Benutzerkonten und die Zugriffsberechtigungen verwaltet und administriert werden (Berechtigungskonzept). Ein per Extranet angebundener Lieferant muss beispielsweise andere Zugriffrechte als eine angebundene Zweigstelle haben. Es empfiehlt sich, für den VPN-Zugang unterschiedliche Benutzergruppen mit verschiedenen Berechtigungen zu definieren. Die Gruppenzugehörigkeit von einzelnen BenutzerInnen sollte durch ein entsprechendes Anforderungsprofil geregelt werden, das festlegt, welche Voraussetzungen für die Mitgliedschaft in einer Gruppe erfüllt werden müssen. Mögliche Voraussetzungen sind der Einsatzzweck (z. B. Telearbeit, Außendienst-Tätigkeiten, Wartungsarbeiten), Nachweis bestimmter Kenntnisse (z. B. Teilnahme an Schulungen) und eine Zustimmung durch Vorgesetzte. Wie die Erlaubnis zum entfernten Zugriff reglementiert werden soll, muss jeweils innerhalb der Institution entschieden werden. Oft existieren schon ähnliche Regelungen, z. B. für die Erlaubnis zur Nutzung von Internetzugängen, die dann adaptiert werden können. Die erteilten Zugangs- und Zugriffsberechtigungen müssen dokumentiert und bei Änderungen fortgeschrieben werden.
  • Für feste entfernte Standorte (wie Telearbeitsplätze) müssen Anforderungen festgelegt werden, die beschreiben, welchen Ansprüchen (z. B. in Bezug auf Sicherheit und technischer Ausstattung) der entfernte Arbeitsplatz genügen muss, damit von dort VPN-Verbindungen in das LAN der Institution erlaubt werden können. Das Konzept kann eine anfängliche sowie eine periodisch wiederkehrende Überprüfung der Räumlichkeiten und dortigen Technik vorsehen und regeln, wie und durch wen diese erfolgt. Die Betriebsorte von VPN-Clients unterliegen häufig nicht der Kontrolle des LAN-Betreibers und besitzen daher auch ein besonderes Gefährdungspotenzial. Gegenüber stationären Clients kommen bei mobilen Clients weitere Gefährdungen hinzu. Nicht jeder Ort, an dem die technischen Voraussetzungen zum VPN-Verbindungsaufbau vorhanden sind, ist dafür geeignet. Daher müssen Regelungen getroffen werden, von welchen Standorten aus VPN-Verbindungen zum Ziel-LAN aufgebaut werden dürfen. Je nach geplantem Einsatzszenario kann es zweckmäßiger sein, eine Negativliste von besonders ungeeigneten Standorten zu führen. Dazu können z. B. Hotel-Foyers, Hotel-Business-Center oder öffentliche Verkehrsmittel gehören.
  • Wird die Sicherheit von VPN-Zugängen verletzt, kann dies unter Umständen die Kompromittierung des gesamten LANs nach sich ziehen. Für die VPN-Administration sollten deshalb Verfahren festgelegt werden, die beschreiben, wie Änderungen an der VPN-Konfiguration durchzuführen sind (Beispiel: Beantragung, Überprüfung der geplanten Konfiguration, Durchführung, Überprüfung der durchgeführten Veränderung).
  • Ein weiterer wichtiger Punkt bei der Konzeption ist die grundsätzliche Frage, ob eine Eigenrealisierung bzw. Eigenbetrieb des VPNs notwendig ist oder ob auf Fremdrealisierung bzw. -betrieb zurückgegriffen wird. Viele Dienstleister verfügen über hohe Kompetenz und Erfahrung in Bezug auf die Planung, Einrichtung und den Betrieb von VPNs. Allerdings ist es nicht immer vorteilhaft oder erwünscht, den kompletten Betrieb eines VPNs aus der Hand zu geben. Bei Fremdbetrieb eines VPNs müssen die Anforderungen aus 10.3 Outsourcing beachtet werden.
  • Der Schutzbedarf für das VPN muss ermittelt werden. Dieser leitet sich aus dem Schutzbedarf der darüber übertragenen Informationen sowie der damit verbundenen IT-Komponenten ab. In diesem Zusammenhang muss auch ermittelt werden, wie sich eine Nichtverfügbarkeit des Systems auswirkt und welche Ausfallzeiten hingenommen werden können. Die Anforderungen an die VPN-Sicherheitsmechanismen (z. B. Authentisierung und Integritätssicherung) müssen definiert werden. Hierbei muss hinterfragt werden, ob starke Kryptographie an allen beteiligten Standorten rechtlich eingesetzt werden darf.
  • Haben externe Zulieferer oder Kunden eine Anbindung an das VPN, so müssen unterschiedliche Sicherheitszonen definiert werden. Aus den Sicherheitszonen heraus dürfen nur die Zugriffe erlaubt werden, die tatsächlich für die BenutzerInnen erforderlich sind.
  • Um einem Missbrauch vorzubeugen, müssen in der VPN-Sicherheitsrichtlinie die Rechte und Pflichten von VPN-BenutzerInnen festgelegt werden. Diese müssen entsprechend verbindlich verpflichtet werden, die Sicherheitsregelungen einzuhalten.
  • Da beim entfernten Zugriff auf ein LAN besondere Sicherheitsrisiken durch die meist ungesicherte Umgebung eines VPN-Clients bestehen, sollte alle VPN-BenutzerInnen eine besondere Schulung erhalten. Im Rahmen dieser Schulung sollen die BenutzerInnen einerseits für die spezifischen VPN-Gefährdungen sensibilisiert und andererseits im Umgang mit den technischen Geräten und der Software unterrichtet werden. Falls Authentisierungstoken zum Einsatz kommen sollen, müssen die BenutzerInnen über deren ordnungsgemäße Handhabung informiert werden. Ebenso müssen auch die AdministratorInnen sowohl für die eingesetzten Produkte gründlich ausgebildet als auch über VPN-Sicherheitsrisiken und Sicherheitsmaßnahmen aufgeklärt werden.
  • Den AdministratorInnen muss nicht nur für den Betrieb des VPNs ausreichend Zeit zur Verfügung stehen, sondern auch für die Suche nach Informationen über aktuelle VPN-Sicherheitslücken, die Konzeption von Maßnahmen zur Steigerung der Informationssicherheit beim VPN-Betrieb und die Einarbeitung in neue Komponenten.
Das technische Konzept sollte folgende Punkte beinhalten bzw. regeln:
  • Es sollte beschrieben sein, wie das VPN durch Hardware- und Softwarekomponenten technisch realisiert ist. Die Komponenten werden lediglich durch ihre Funktion definiert. Im Rahmen einer nachgeschalteten Analyse vorhandener Systemkomponenten und am Markt beschaffbarer neuer Komponenten können die Elemente des Konzeptes tatsächlichen Geräten und Softwareprodukten zugeordnet werden.
  • Alle potenziellen VPN-Endpunkte, die die Einwahl in das LAN ermöglichen, und die dafür verwendeten Zugangsprotokolle sind zu beschreiben.
  • Im Rahmen der Sicherheitskonzeption sind alle VPN-Zugangspunkte zum lokalen Netz zu erfassen und es ist zu beschreiben, wie diese Zugangspunkte an das LAN angeschlossen werden. Das Sicherheitskonzept muss aufbauend auf der aktuellen Netzstruktur analysieren, welche Teilnetze bei Nutzung eines VPN-Zugangs erreichbar sind. Es sollte überlegt werden, dedizierte Zugangsnetze (Access Networks) zu bilden, aus denen nur kontrolliert (über Router, Paketfilter bzw. interne Firewall) in das produktive Netz zugegriffen werden kann. Die Bildung von Zugangsnetzen erfordert dabei die Anschaffung und Wartung zusätzlicher Hard- und Software.
  • Alle Dienste und Protokolle, die über den VPN-Zugang zugelassen werden, sowie die darüber zugreifbaren Ressourcen sind zu dokumentieren. Die Auswahl ist davon abhängig, welche Applikationen eingesetzt werden sollen. Für einen zeitkritischen Datenverkehr werden eventuell QoS (Quality of Service), MPLS (Multi Protocol Label Switching) oder dedizierte Leitungen benötigt.
  • Es müssen geeignete Verschlüsselungsverfahren zum Schutz der Daten festgelegt werden. Relevant sind hier unter anderem:
    • Tunneling: Die Kommunikation kann auf niedriger Protokollebene verschlüsselt werden (so genanntes Tunneling). Dazu muss ein geeignetes Verfahren ausgewählt werden. Die herkömmlichen VPNs stellen solche Verfahren standardmäßig, jedoch in unterschiedlicher Zahl und Ausprägung zur Verfügung.
    • SSL/TLS-Verschlüsselung: Zur Verschlüsselung kann auch SSL/TLS eingesetzt werden, wenn von der Verschlüsselung auf niedriger Protokollebene aus bestimmten Gründen kein Gebrauch gemacht werden kann. Dies gilt besonders für Zugriffe auf Webserver oder E-Mail-Server über Browser, die standardmäßig SSL/TLS-gesicherte Kommunikation unterstützen.
    • Verschlüsselung durch Netzkoppelelemente: Neben der Absicherung der Kommunikation durch Software kann auch der Einsatz von verschlüsselnden Netzkoppelelementen (Router, Modems) erwogen werden. Diese sind besonders für den stationären Einsatz und zur Anbindung mehrerer Rechner sinnvoll, da die Verschlüsselung transparent erfolgt und die Endsysteme nicht belastet werden. Zu beachten ist jedoch, dass die Netzkoppelelemente sorgfältig konfiguriert und gewartet werden müssen. Auch bei direkten Einwahlverfahren beispielsweise über analoge Telefonnetze oder ISDN ist eine Verschlüsselung zum Schutz der Daten erforderlich.
  • Es gibt verschiedene Arten von VPNs (Site-to-Site, End-to-End, End-to-Site), anhand der Anforderungen muss entschieden werden, welcher VPN-Typ realisiert werden soll.
  • Es muss entschieden werden, ob die Verbindung über dedizierte Carrier-Leitungen realisiert werden muss. Diese Entscheidung hat in der Regel erheblichen Einfluss auf die Kosten.
  • Um einen stabilen Betrieb und eine kontinuierliche Verbesserung gewährleisten zu können, sollten geeignete Monitoring-Systeme eingeplant werden. Die aus den Monitoring-Systemen gewonnenen Erkenntnisse tragen wesentlich zur Feinabstimmung des VPN-Betriebs bei.
Das VPN-Sicherheitskonzept sollte folgende Punkte beinhalten bzw. regeln:
  • Für den Einsatz von VPN-Komponenten in Behörden und Unternehmen müssen geeignete Sicherheitsrichtlinien aufgestellt werden. Diese VPN-spezifischen Sicherheitsrichtlinien müssen konform zum generellen Sicherheitskonzept und den allgemeinen Sicherheitsrichtlinien der Institution sein. Sie müssen regelmäßig auf Aktualität überprüft und gegebenenfalls angepasst werden. Die VPN-spezifischen Vorgaben können in den vorhandenen Richtlinien ergänzt oder in einer eigenen Richtlinie zusammengefasst werden.
  • Es sollte beschrieben sein, wer in der Institution VPN-Komponenten installieren, konfigurieren und benutzen darf. Dazu sind auch eine Vielzahl von Randbedingungen festzulegen wie z. B.
    • welche Informationen über VPNs übertragen werden dürfen,
    • wo die VPN-Komponenten benutzt werden dürfen,
    • auf welche anderen internen oder externen Netze oder IT-Systeme über ein VPN zugegriffen werden darf.
  • Für alle VPN-Komponenten sollten Sicherheitsmaßnahmen und eine Standard-Konfiguration festgelegt werden.
  • Alle VPN-BenutzerInnen sollten darauf hingewiesen werden, dass bei einem Verdacht auf Sicherheitsprobleme ein Sicherheitsverantwortlicher hierüber informiert werden muss, damit dieser weitere Schritte unternehmen kann.
  • AdministratorInnen, aber auch BenutzerInnen von VPN-Komponenten sollten über VPN-Gefährdungen und die zu beachtenden Sicherheitsmaßnahmen informiert bzw. geschult werden.
  • Die korrekte Umsetzung der in der VPN-Sicherheitsrichtlinie beschriebenen Sicherheitsmaßnahmen sollte regelmäßig kontrolliert werden.
  • Um BenutzerInnen nicht mit zu vielen Details zu belasten, kann es sinnvoll sein, eine eigene VPN-BenutzerInnenrichtlinie zu erstellen, z. B. in Form eines Merkblattes. In einer solchen BenutzerInnenrichtlinie sollten dann kurz die Besonderheiten bei der VPN-Nutzung beschrieben werden, wie z. B.
    • an welche anderen internen und externen Netze oder IT-Systeme der VPN-Client gekoppelt werden darf,
    • unter welchen Rahmenbedingungen sie sich an einem internen oder externen VPN anmelden dürfen,
    • welche Schritte bei (vermuteter) Kompromittierung des VPN-Clients zu unternehmen sind, vor allem, wer zu benachrichtigen ist.
  • BenutzerInnen sollten darauf hingewiesen werden, dass VPNs nur von geeigneten Standorten und mit von der Institution dafür zugelassenen IT-Komponenten aufgebaut werden dürfen. Ungeeignete Standorte können je nach Einsatzzweck z. B. Hotel-Foyers, Hotel-Business-Center oder öffentliche Verkehrsmittel sein, fremd-administrierte IT-Systeme können ebenso ungeeignet sein. Wichtig ist auch, dass klar beschrieben wird, wie mit Client-seitigen Sicherheitslösungen umzugehen ist. Dazu gehört beispielsweise, dass
    • keine sicherheitsrelevanten Konfigurationen verändert werden dürfen,
    • Passwörter nicht auf dem Client gespeichert werden dürfen, es sei denn mit von dafür freigegebenen Passwort-Speicher-Tools,
    • stets ein Virenscanner aktiviert sein muss,
    • eine vorhandene Personal Firewall nicht abgeschaltet werden darf,
    • die Konfiguration der VPN-Clients nicht von den BenutzerInnen verändert werden darf, sondern nur durch die hierfür benannten AdministratorInnen, und
    • alle Freigaben von Verzeichnissen oder Diensten deaktiviert oder zumindest durch gute Passwörter geschützt sind.
  • Außerdem sollte die BenutzerInnenrichtlinie Angaben dazu enthalten, welche Daten im VPN genutzt und übertragen werden dürfen und welche nicht. Hierzu gehört vor allem der Umgang mit klassifizierten Informationen, beispielsweise Verschlusssachen. BenutzerInnen sollten für VPN-Gefährdungen sowie für Inhalte und Auswirkungen der VPN-Richtlinie sensibilisiert werden.
  • Daneben sollte eine VPN-spezifische Richtlinie für AdministratorInnen erstellt werden, die auch als Grundlage für die Schulung der AdministratorInnen dienen kann. Darin sollte festgelegt sein, wer für die Administration der unterschiedlichen VPN-Komponenten zuständig ist, welche Schnittstellen es zwischen den am Betrieb beteiligten AdministratorInnen gibt, und wann welche Informationen zwischen den Zuständigen fließen müssen. So ist es durchaus üblich, dass für den Betrieb der serverseitigen Komponenten eine andere Organisationseinheit zuständig ist als für die Betreuung der VPN-Clients oder für das Identitäts- und Berechtigungsmanagement. Die VPN-Richtlinie für AdministratorInnen sollte weiters die wesentlichen Kernaspekte zum Betrieb einer VPN-Infrastruktur umfassen, wie z. B.
    • Festlegung einer sicheren VPN-Konfiguration und Definition von sicheren Standard-Konfigurationen,
    • geeignete Verwaltung aller VPN-Komponenten,
    • Auswahl und Einrichtung von Kryptoverfahren inklusive Schlüsselmanagement,
    • regelmäßige Auswertung von Protokolldateien, zumindest auf den Servern,
    • Inbetriebnahme von Ersatzsystemen,
    • Maßnahmen bei Kompromittierung des VPNs.
  • Alle VPN-AnwenderInnen, egal ob BenutzerInnen oder AdministratorInnen, sollten mit ihrer Unterschrift bestätigen, dass sie den Inhalt der VPN-Sicherheitsrichtlinie gelesen haben und die darin definierten Anweisungen auch einhalten. Ohne diese schriftliche Bestätigung sollte niemand VPNs nutzen dürfen. Die unterschriebenen Erklärungen sind an einem geeigneten Ort, beispielsweise in der Personalakte, aufzubewahren.
Die VPN-Planung muss der Leitungsebene zur Entscheidung vorgelegt werden. Alle Entscheidungen müssen nachvollziehbar dokumentiert werden.
[eh SYS 7.2]

10.6.10.3 Auswahl einer geeigneten VPN-Systemarchitektur

ISO Bezug: 27002 10.6.2, 11.4
Unternehmen und Behörden haben vielfältige Anforderungen an Netze, wie beispielsweise die Vernetzung unterschiedlicher Standorte und die Anbindung mobiler MitarbeiterInnen oder TelearbeiterInnen an das interne Netz. Dementsprechend unterscheiden sich die Anforderungen der Institutionen und müssen bei der Auswahl von VPN-Produkten berücksichtigt werden.
Typische VPN-Nutzungsszenarien
Nachfolgend werden einige Einsatzszenarien, in denen VPNs üblicherweise eingesetzt werden, beschrieben.
  • Mobile MitarbeiterInnen:
    Mobile MitarbeiterInnen arbeiten an wechselnden Arbeitsplätzen in unterschiedlichen Umgebungen und benötigen dabei unter Umständen einen Fernzugriff auf Daten im LAN innerhalb der Institution. Neben der Absicherung solcher Verbindungen muss auch die Sicherheit des Endgeräts sowie dessen Einsatzumgebung beachtet werden. Je nach Aufgabengebiet kann es sein, dass sich die MitarbeiterInnen von beliebigen Arbeitsorten, z. B. einem Hotel oder Flughafen, ins interne Netz einwählen möchten. Die Endgeräte der Mitarbeiter sind typischerweise Notebooks oder PDAs.
  • Telearbeitsplatz:
    Bei der Anbindung eines Telearbeitsplatzes greift ein Client-System von einem festen Arbeitsort außerhalb der Büroumgebung auf das interne Netz einer Institution zu. Die Kommunikation zwischen Telearbeitsrechner und LAN erfolgt normalerweise über unsichere, öffentliche Netze. Die IT-Systeme des Telearbeitsplatzes sollten zentral administriert werden.
  • Standortvernetzung:
    Bei der Standortvernetzung werden Teilnetze an unterschiedlichen Standorten einer Institution miteinander verbunden. Hierbei werden die vertrauenswürdigen LANs, die unter eigener Kontrolle stehen, häufig über ein unsicheres öffentliches Transportnetz verbunden. In diesem Szenario ist besonders der Transportkanal abzusichern. Zusätzlich müssen die Netze und die Client-Systeme der Standorte mittels Sicherheitsgateways gegen Angriffe aus dem Internet gesichert werden.
  • Kunden- und Partner-Anbindung:
    Häufig sollen Kunden oder Partner an das interne Netz einer Institution angebunden werden. Folgende Szenarien sind typisch
    • Es sollen bestimmte interne Informationen bereitgestellt werden, so dass diese aus einem nur eingeschränkt vertrauenswürdigen Netz, d. h. von „außen“, abgerufen werden können.
    • Aus dem vertrauenswürdigen Netz heraus, d. h. von „innen“, sollen externe Datenbanken abgefragt werden, z. B. um Waren aussuchen und bestellen zu können.
    • Auf internen Systemen soll durch externe Firmen Software entwickelt werden.
    Da die IT-Systeme der Kunden oder der Partner nicht unter der Kontrolle der Institution stehen, muss gewährleistet werden, dass nur auf die freigegebenen Ressourcen zugegriffen werden kann. Beispielsweise könnten alle IT-Systeme, auf die Kunden oder Partner zugreifen können, in einem separaten Netz betrieben werden, dass mit einem Sicherheitsgateway (Firewall) vom LAN der Institution getrennt ist.
  • Fernwartung:
    Bei der Durchführung von Fernwartungstätigkeiten sind privilegierte Administratorzugänge auf interne Systeme erforderlich. Die Fernwartung (Wartung, Support und Betrieb) interner Systeme kann durch eigene oder fremde MitarbeiterInnen durchgeführt werden. In beiden Fällen bestehen hohe Anforderungen an die Authentisierung der entfernten BenutzerInnen, die Datenflusskontrolle und die Verfügbarkeit der Anbindung. Werden fremde MitarbeiterInnen beauftragt, die IT-Systeme zu warten, müssen die Empfehlungen aus 10.3 Outsourcing berücksichtigt werden.
VPNs werden häufig auch verwendet, um die Kommunikation einzelner Protokolle und Anwendungen zu schützen. Unterstützen beispielsweise die vorhandenen WLAN-Komponenten selbst keine sichere Verschlüsselung, könnte die gesamte WLAN-Kommunikation mit einem VPN, das unabhängig vom WLAN ist, verschlüsselt übertragen werden. Die Signalisierung und der Medientransport einer VoIP-Verbindung könnten ebenfalls in einem VPN-Tunnel gebündelt und verschlüsselt werden.
VPN-Endpunkte
Bei den VPN-Endpunkten wird grundsätzlich zwischen VPN-Server und VPN-Client unterschieden. Derjenige Endpunkt, zu dem die Verbindung aufgebaut wird, fungiert als VPN-Server. Der initiierende Endpunkt wird als VPN-Client bezeichnet. VPN-Endpunkte lassen sich entweder per Software oder per Hardware realisieren. Bei MitarbeiterInnen im Außendienst besteht der VPN-Client in der Regel aus einer Softwareapplikation auf einem mobilen IT-System. Ein derartiger VPN-Client greift oft sehr stark in das installierte Betriebssystem ein. Die parallele Installation mehrerer unterschiedlicher VPN-Clients auf einem Endgerät sollte daher vermieden werden. Die Vernetzung der einzelnen VPN-Endpunkte untereinander muss anhand der Ergebnisse der Anforderungsanalyse durchgeführt werden. Bei den VPN-Endpunkten muss für eine sichere Authentisierung gesorgt werden, damit nur Berechtigte sich über das VPN einwählen können. Hierbei ist, je nach Anwendungsgebiet, auch der Einsatz eines Authentisierungsservers, beispielsweise eines RADIUS-Servers (Remote Authentication Dial In User Service), denkbar.
VPN-Typen
VPNs können eingesetzt werden, um entfernte physische Netze zu einem logischen zusammenzufassen oder um einzelne Endgeräte, die sich in unsicheren Netzen befinden, über einen geschützten Kanal an ein zentrales LAN anzubinden. Je nachdem, welche Systeme den Endpunkt der VPN-Verbindung darstellen, wird zwischen Site-to-Site-, End-to-End- und End-to-Site-VPNs unterschieden.
  • Site-to-Site-VPN
    Mit Site-to-Site-VPNs werden Netze gekoppelt, um gemeinsame Anwendungen betreiben bzw. nutzen zu können. Es werden netzübergreifende Zugriffe benötigt. Der Transportkanal wird durch VPN-Gateways in den angeschlossenen Netzen gesichert. Eine typische Verwendung für Verbindungen zwischen LANs ist die Anbindung von Außenstellen oder Filialen an das institutionsinterne Netz.
  • End-to-End-VPN
    End-to-End-VPNs werden meist für die Nutzung einzelner Anwendungen verwendet. Die Verbindungen lassen sich auf spezielle Systeme und Dienste beschränken. Typische Verwendungen für End-to-End-VPNs sind:
    • Fernwartung dedizierter Systeme, bei der Zugriffe auf Administratorebene erforderlich sind.
    • Zugriffe auf einzelne Anwendungen oder Datenbanken. Hierbei sind Berechtigungen auf Administrator- bzw. Systemebene häufig nicht erforderlich.
    • Zugriffe über Terminalserver. Durch Fernzugriff auf ein entferntes System können viele dort installierte Anwendungen genutzt werden. Berechtigungen auf Administrator- bzw. Systemebene auf dem Terminalserver sind dafür normalerweise nicht erforderlich.
    • Integration von Geschäftspartnern oder Kunden in Teilbereiche des zentralen Datennetzes einer Institution.
  • End-to-Site-VPN (Remote-Access-VPN)
    End-to-Site-VPNs werden auch als Remote-Access-VPN (RAS-VPN) bezeichnet. Solche VPNs werden für Zugriffe eines Clients auf mehrere Anwendungen verwendet, die auf unterschiedlichen IT-Systemen im LAN einer Institution liegen. Dadurch wird Zugriff auf das gesamte Netz benötigt, so dass meist VPN-Software auf dem Client-System und ein VPN-Gateway/-Konzentrator im LAN den Transportkanal sichern. TelearbeiterInnen und mobile BenutzerInnen werden in der Regel mit End-to-Site-VPNs in das LAN integriert.
VPN-Varianten
Der Begriff VPN wird oft als Synonym für verschlüsselte Verbindungen verwendet. VPN-Varianten werden häufig auch nach dem eingesetzten VPN-Protokoll benannt, wie beispielsweise SSL/TLS-VPN oder IPsec-VPN. Zur Absicherung des Transportkanals können jedoch auch andere Methoden eingesetzt werden, wie beispielsweise spezielle Funktionen des genutzten Transportprotokolls. Zusätzlich werden zwei grundlegende VPN-Varianten unterschieden: Trusted-VPN und Secure-VPN.
VPNs werden als Trusted-VPN bezeichnet, wenn die VPN-Verbindung zwischen verschiedenen Standorten durch vertrauenswürdige externe VPN-Dienstleister gewährleistet wird. Dabei werden die Daten aus dem vertrauenswürdigen Netz in der Regel unverschlüsselt über einen dedizierten Kommunikationskanal zu einem Gateway-Router des Anbieters geleitet. Die Bildung des VPNs erfolgt durch logische Abschottung des VPN-Datenverkehrs vom übrigen Datenverkehr (z. B. mittels Multiprotocol Label Switching, MPLS). Für mobile NutzerInnen stellen Dienstleister zudem VPNs über Gateway-Router bereit, die nur über spezielle Einwahl-Knoten erreicht werden können, die vor unberechtigtem Zugriff geschützt sind.
Wird ein externer Dienstleister beauftragt, ein Trusted-VPN zur Verfügung zu stellen, sollte zusätzlich 10.3 Outsourcing berücksichtigt werden.
Für vertrauliche Daten sind Trusted-VPNs ohne zusätzliche Verschlüsselung auf der Anwendungsschicht nicht geeignet, da die Sicherheit solcher Verbindungen ausschließlich in Händen des VPN-Dienstleisters liegt. So bietet ein Trusted-VPN zum Beispiel keinen Schutz gegen Innentäter des Anbieters. Für die vertrauliche Datenkommunikation empfiehlt sich daher ein Secure-VPN.
Die Abhängigkeit von Dritten in Bezug auf Vertraulichkeit kann vermieden werden, wenn die Kommunikation an den Endpunkten der Verbindung durch Verschlüsselung geschützt wird, die im eigenen Verantwortungsbereich des VPN-Nutzers liegt. Diese Lösung wird auch als Secure-VPN bezeichnet.
Werden für die Realisierung des VPNs dedizierte Carrier-Leitungen eingesetzt, handelt es sich um eine Sonderform eines Trusted-VPNs. Auch in diesem Fall müssen vertrauliche Daten vor der Übertragung durch Verschlüsselung geschützt werden, die im eigenen Verantwortungsbereich des VPN-Nutzers liegt. Die Verschlüsselung kann an den VPN-Endpunkten auf Transportebene (Secure-VPN) oder auf Anwendungsebene erfolgen.
VPN-Geräte
Grundsätzlich muss eine Entscheidung darüber getroffen werden, ob das gewählte VPN-Produkt ein dediziertes VPN-Gerät, ein Kombi-Gerät oder eine software-basierte VPN-Lösung auf Standard-IT-Systemen (z. B. Linux mit IPsec) sein soll:
  • Dedizierte VPN-Gateways (Appliances):
    Diese VPN-Produkte dienen ausschließlich der Realisierung von VPN-Verbindungen und bieten keine darüber hinausgehenden Funktionalitäten, wie beispielsweise Inhaltsfilterung auf Anwendungsebene. VPN-Appliances haben den Vorteil, dass sie für den VPN-Einsatz optimiert sind und die sichere Konfiguration vereinfacht wird, da beispielsweise das Betriebssystem bereits gehärtet ist.
  • Kombi-Geräte:
    Integrierte VPN-Geräte können beispielsweise Router und andere Komponenten von Sicherheitsgateways (z. B. Application Level Gateways, ALGs) darstellen, die über eine VPN-Funktionalität verfügen oder entsprechend erweitert werden können. Kombi-Geräte haben neben den finanziellen Aspekten oft den Vorteil, dass die unterschiedlichen Funktionalitäten gemeinsam an einer Stelle administriert werden können. Die Kombination verschiedener Funktionalitäten auf einem Gerät kann jedoch zu Lasten der Performance gehen. Bei einer intensiven VPN-Nutzung ist daher zu prüfen, ob aus Gründen der Verfügbarkeit oder des Durchsatzes eigenständige VPN-Komponenten vorzuziehen sind. Manche Kombi-Geräte bieten die Möglichkeit, (auch nachträglich) spezielle Hardwareverschlüsselungsmodule zur Steigerung der Performance einzubauen.
  • VPNs auf Basis von Standard-IT-Systemen:
    VPN-Geräte können mit frei verfügbaren oder kommerziellen Softwarekomponenten selbst zusammengestellt werden. Diese Komponenten können oft auf handelsüblicher Hardware mit Standardbetriebssystemen installiert werden. Zusammengestellte VPN-Geräte bieten eine hohe Flexibilität und sind für viele Anwendungsfälle gut geeignet. Die Installation und Integration der benötigten Komponenten kann jedoch fehlerträchtig sein. Daraus können sich Sicherheitsrisiken beim Einsatz eines zusammengestellten VPN-Gerätes ergeben. Ein weiterer Nachteil ist, dass bei Support-Anfragen meist unterschiedliche Ansprechpartner für die einzelnen Komponenten des VPN-Gerätes (z. B. Hardware, Betriebssystem, VPN-Software) kontaktiert werden müssen.
Folgende Sicherheitsgrundfunktionen müssen bei der Auswahl von VPN-Produkten erfüllt werden:
  • Identifikation, Authentisierung und Autorisierung:
    Hierunter fallen die Identifikation und Authentisierung von Systemen untereinander, von Systemen gegenüber BenutzerInnen und von BenutzerInnen gegenüber Systemen. Es muss möglich sein, verschiedene Benutzerkennungen mit unterschiedlichen Rechteprofilen einzurichten. Es sollten ausreichend starke anerkannte Authentisierungsverfahren vorhanden sein. Remote-Zugriffe sollten durch eine starke Authentisierung abgesichert werden. Es muss außerdem möglich sein, die festgelegten Zugriffsrechte auf den VPN-Komponenten abbilden zu können.
  • Dienstgüte (Quality of Service, QoS):
    Im Zusammenhang mit Netzübergängen ist der Begriff Dienstgüte als Überwachung und Steuerung der Kommunikation zu verstehen, die über ein Sicherheitsgateway erfolgen darf. Ein geeignetes Produkt muss die bei der VPN-Konzeption ermittelten Anforderungen erfüllen können und eine Priorisierung von geschäftskritischen Applikationen ermöglichen.
  • Übertragungssicherung:
    Zur Übertragungssicherung kommen Funktionen zum Einsatz, welche die Vertraulichkeit und Integrität der Daten sichern. Außerdem muss die Authentizität der Kommunikationspartner gewährleistet werden. Wichtig ist dabei, dass das Produkt sichere kryptographische Mechanismen bietet, die dem Stand der Technik entsprechend. Bei der Planung und Realisierung des VPNs muss außerdem die Integration der VPN-Endpunkte in ein Sicherheitsgateway berücksichtigt werden.
  • Schlüsselmanagement:
    Zum Schlüsselmanagement müssen geeignete Funktionen vorhanden sein, um geheime und öffentliche Schlüssel für die kryptographischen Mechanismen verwalten, verteilen und eventuell auch erzeugen zu können. Die ausgewählten Produkte sollten dabei möglichst flexibel sein und eine nahtlose Integration verschiedenster Techniken ermöglichen.
Die nun folgende Liste gibt einen Überblick über mögliche allgemeine Bewertungskriterien, erhebt jedoch keinen Anspruch auf Vollständigkeit und kann um weitere allgemeine Anforderungen erweitert werden. Neben den hier aufgeführten Kriterien müssen weitere spezifische Anforderungen erarbeitet werden, die aus den geplanten konkreten Einsatzszenarien resultieren. Allgemeine Kriterien
  • Performance und Skalierbarkeit
    • Kann das Produkt den Ansprüchen an die Performance gerecht werden?
    • Bietet das Produkt Funktionen zur Lastverteilung?
    • Können die Produkte die zu übertragenen Informationen komprimieren und dekomprimieren?
    • Kann das Produkt einem zukünftigen Wachstumsbedarf gerecht werden (z. B. durch modularen Systemaufbau, einfaches Einbinden neuer VPN-Server, gemeinsame Benutzerverwaltung für alle VPN-Zugänge)?
  • Wartbarkeit
    • Ist das Produkt einfach wartbar?
    • Bietet der Hersteller regelmäßige Software-Updates an?
    • Wird für das Produkt ein Wartungsvertrag angeboten?
    • Können im Rahmen der Wartungsverträge maximale Reaktionszeiten für die Problembehebung festgelegt werden?
    • Bietet der Hersteller einen kompetenten technischen Kundendienst (Call-Center, Hotline) an, der in der Lage ist, bei Problemen sofort zu helfen?
  • Zuverlässigkeit/Ausfallsicherheit
    • Wie zuverlässig und ausfallsicher ist das Produkt?
    • Bietet der Hersteller auch Hochverfügbarkeitslösungen an?
    • Ist das Produkt im Dauerbetrieb einsetzbar?
  • Benutzerfreundlichkeit
    • Lässt sich das Produkt einfach installieren, konfigurieren und nutzen? Genügt das Produkt den geltenden Ergonomievorschriften?
    • Ist insbesondere für den VPN-Client die Benutzerführung so gestaltet, dass auch ungeübte BenutzerInnen damit arbeiten können, ohne Abstriche in der Sicherheit in Kauf nehmen zu müssen (z. B. durch kontextsensitive Hilfen, Online-Dokumentation, detaillierte Fehlermeldungen)?
    • Ist die Nutzung des VPN-Clients so konfigurierbar, dass die BenutzerInnen möglichst wenig mit technischen Details belastet werden? Ist die Sicherheit dabei trotzdem immer gewährleistet?
Funktion
  • Installation und Inbetriebnahme
    • Kann die Installation der VPN-Client-Software automatisiert mit vorgegebenen Konfigurationsparametern erfolgen?
    • Ist die Installation der VPN-Client-Software auch für weniger versierte MitarbeiterInnen durchführbar?
    • Können wichtige Konfigurationsparameter vor Veränderungen durch BenutzerInnen geschützt werden?
    • Arbeitet das Produkt mit gängiger Hard- und Software zusammen (Betriebssysteme, Einsteckkarten, Treiber)?
    • Ist das VPN mit gängigen Systemmanagementsystemen kompatibel?
  • Verhalten im Fehlerfall
    • Bleibt die Sicherheit des VPN-Zugangs auch nach einem kritischen Fehler gewährleistet?
    • Kann konfiguriert werden, wie sich das System nach einem kritischen Fehler verhalten soll? Kann z. B. eingestellt werden, dass nach einem kritischen Fehler automatisch ein Neustart durchgeführt oder die AdministratorInnen benachrichtigt werden?
  • Administration
    • Enthält die mitgelieferte Produktdokumentation eine genaue Darstellung aller technischen und administrativen Details?
    • Kann die Administration über eine graphische Benutzeroberfläche erfolgen, die sich intuitiv bedienen lässt? Ist die administrative Schnittstelle so gestaltet, dass auf fehlerhafte, unsichere oder inkonsistente Konfigurationen hingewiesen wird oder diese verhindert werden?
    • Wird neben der graphischen Administrationsoberfläche auch eine kommandozeilenbasierte Schnittstelle angeboten?
    • Sind die administrativen Funktionen durch eine adäquate Zugriffskontrolle geschützt?
  • Protokollierung
    • Bietet das Produkt geeignete Funktionen zur Protokollierung an?
    • Ist konfigurierbar, wie detailliert die Protokollierung erfolgt und welche Arten von Ereignissen aufgezeichnet werden? Werden durch die Protokollierung alle relevanten Daten erfasst?
    • Ist die Protokollierung in der Weise möglich, dass die Daten nach unterschiedlichen Kategorien erfasst werden können (z. B. verbindungsorientiert, benutzerorientiert, protokollorientiert, dienstorientiert)?
    • Sind die Protokolldaten mit einem Zugriffsschutz versehen?
    • Können die Protokolldaten nicht nur lokal gespeichert werden, sondern auch auf entfernten Rechnern (zentrales Protokoll)? Werden für die entfernte Speicherung gängige Verfahren angeboten, so dass auch Fremdsysteme zur Protokollierung benutzt werden können (z. B. syslog)? Können die Protokolldaten abgesichert übertragen werden?
    • Bietet das Produkt leicht bedienbare Funktionen zur Auswertung der Protokolldaten an?
    • Kann die Protokollierung mit dem eingesetzten Systemmanagementsystem zusammenarbeiten, insbesondere hinsichtlich Übertragungsformat und Übertragungsprotokoll?
    • Bietet das Produkt die Möglichkeit an, beim Auftreten bestimmter Ereignisse die AdministratorInnen zu informieren oder auch geeignete Schutzmaßnahmen automatisch durchzuführen? Beispielsweise ist es oft sinnvoll, ein Benutzerkonto zu sperren, wenn mehrere fehlgeschlagene Authentisierungsversuche in Folge für das jeweilige Benutzerkonto festgestellt werden.
    • Kann die Protokollierung an die spezifischen Bestimmungen des Datenschutzes, die für und in der Institution gelten, angepasst werden?
  • Kommunikation und Datenübertragung
    • Unterstützt das VPN-Produkt LAN-seitig alle relevanten Netzwerktechnologien (z. B. Ethernet, ATM)?
    • Unterstützt das VPN-Produkt WAN-seitig alle geplanten Zugangstechnologien (z. B. ISDN, Mobiltelefon, analoge Telefonleitung, X.25)?
    • Ist die Anzahl der VPN-Clients, die sich gleichzeitig in den VPN-Server einwählen können, ausreichend?
    • Unterstützt das VPN-Produkt die gängigen Protokolle für den entfernten Zugang über Telekommunikationsnetze (z. B. PPP, SLIP)?
    • Unterstützt das VPN-Produkt die gängigen Dienstprotokolle für den entfernten Zugriff (z. B. TCP/IP)?
    • Werden für den internetbasierten Zugriff die gängigen Tunnelprotokolle (z. B. PPTP (Point-to-Point Tunneling Protocol), L2F (Layer 2 Forwarding), IPsec (Internet Protocol Security), SSL/TLS (Secure Sockets Layer/Transport Layer Security)) unterstützt?
    • Bietet das VPN-Produkt je nach verwendeter Zugangstechnologie zusätzliche, technologieabhängige Mechanismen (z. B. Kanalbündelung für ISDN (Integrated Services Digital Network), Rückruf des VPN-Clients durch den VPN-Server) an?
  • Sicherheit: Kommunikation, Authentisierung und Zugriff
    • Bietet das Produkt geeignete Funktionen zur gesicherten Datenübertragung an?
    • Erfolgt die Absicherung der Kommunikation durch standardisierte Mechanismen?
    • Sind alle verwendeten kryptographischen Verfahren etabliert, und entsprechen sie dem Stand der Technik?
    • Erlaubt die Produktarchitektur eine nachträgliche Installation neuer Sicherheitsmechanismen?
    • Bietet das Produkt geeignete Funktionen zur Authentisierung der BenutzerInnen, bevor ihnen Zugang zu lokalen Ressourcen gewährt wird?
    • Können mehrere Authentisierungsmechanismen miteinander verknüpft werden?
    • Ist die Systemarchitektur so aufgebaut, dass neue Authentisierungsmechanismen nachträglich integriert werden können?
    • Erlaubt das VPN die Nutzung eines oder mehrerer gängiger externer Authentisierungsdienste, z. B. SecureID, TACACS+ (Terminal Access Controller Access-Control System Plus), RADIUS (Remote Authentication Dial In User Service)?
    • Ist es möglich, zusätzliche externe Authentisierungsdienste (z. B. MOA-ID) einzubinden?
Sind alle Anforderungen an das zu beschaffende Produkt dokumentiert, so müssen die am Markt erhältlichen Produkte dahingehend untersucht werden, inwieweit sie diese Anforderungen erfüllen. Es ist zu erwarten, dass nicht jedes Produkt alle Anforderungen gleichzeitig oder gleich gut erfüllt. Daher sollten die einzelnen Anforderungen entsprechend ihrer Relevanz für die Institution gewichtet werden. Analog kann auch der Erfüllungsgrad einer Anforderung durch das jeweilige Produkt in mehrere Stufen eingeteilt werden. Auf der Grundlage der durchgeführten Produktbewertung kann dann eine fundierte Kaufentscheidung getroffen werden.
Vor der Installation muss überprüft werden, ob die ausgewählten Produkte tatsächlich die Anforderungen ausreichend erfüllen und kompatibel mit den vorgesehenen Technologien sind. Die Auswahl der VPN-Geräte stellt einen wesentlichen Aspekt für den reibungslosen Betrieb eines VPNs dar. Die Entscheidung muss daher gut überlegt sein, da spätere Änderungen oft mit hohen Kosten oder auch mit Sicherheitseinbußen verbunden sind.
[eh SYS 7.3]

10.6.11 Remote Access (VPN) - Implementierung

ISO Bezug: 27002 10.6.2, 11.4
Mit dem Aufbau eines VPNs kann begonnen werden, sobald die erforderlichen Komponenten dafür beschafft worden sind (vgl. voranstehende Maßnahmen). Grundvoraussetzung für den sicheren VPN-Betrieb ist, dass die Installation und Konfiguration aller Komponenten gewissenhaft erfolgt und sich mit den gewählten VPN-Produkten auch tatsächlich die geforderten Sicherheitsfunktionen umsetzen lassen.
Zusätzlich muss die Sicherheit der IT-Systeme gewährleistet werden, auf denen die VPN-Komponenten eingesetzt werden. Dies betrifft besonders IT-Systeme, auf denen ein Standard-Betriebssystem installiert ist und das als VPN-Endpunkt betrieben wird (Beispiel: Linux-System mit VPN-Unterstützung). Daher sind zunächst die generellen Sicherheitsmaßnahmen für jedes dieser Betriebssysteme umzusetzen, wie sie in den jeweiligen Bausteinen der IT-Grundschutz-Kataloge beschrieben werden. Es gibt auch VPN-Komponenten, bei denen die Konfiguration der Plattform vom Hersteller vorgegeben ist und nicht geändert werden kann (VPN-Appliances). Der Einsatz solcher VPN-Geräte spart einerseits Zeit und es wird im Gegensatz zu einer individuellen Lösung weniger fachkundiges IT-Personal benötigt, z. B. für die Konfiguration des Betriebssystems. Andererseits muss beim Einsatz von Appliances den Vorgaben des Herstellers vertraut werden.

10.6.11.1 Sichere Installation des VPN-Systems

ISO Bezug: 27002 10.6.2, 10.10, 11.4
Zusätzlich zu den generellen Sicherheitsmaßnahmen, die für die IT-Komponenten zu beachten sind, sollten im Rahmen der Installation eines VPN-Systems folgende Punkte Beachtung finden:
  • Während der Installationsphase sollten weder BenutzerInnen noch Dritte auf das VPN oder Teile davon zugreifen dürfen. Es dürfen in dieser Phase also keine Verbindungen zu anderen Netzen vorhanden sein.
  • Es muss sichergestellt werden, dass die Installation aller VPN-Komponenten durch qualifiziertes Personal durchgeführt wird. Dies kann vor allem dann schwierig sein, wenn die zu vernetzenden Standorte geografisch weit voneinander entfernt sind. Beispielsweise muss geklärt werden, ob die nötigen Personalressourcen für eine VPN-Installation auch in anderen Ländern zur Verfügung stehen. Auch VPN-Endpunkte auf mobilen IT-Systemen, beispielsweise Notebooks von AußendienstmitarbeiterInnen, dürfen nur von qualifiziertem IT-Personal installiert werden.
  • Die Installation und Konfiguration der VPN-Komponenten ist zu dokumentieren. Dies kann entweder durch eine separate Installationsdokumentation erfolgen oder aber durch eine Bestätigung, dass die Installation mit den Planungsvorgaben übereinstimmt. Abweichungen von der festgelegten Systemarchitektur (beispielsweise zusätzliche Verbindungen) müssen hierbei begründet und dokumentiert werden. Die Qualität der Dokumentation spielt im Hinblick auf die kontinuierliche Verbesserung des VPNs eine wesentliche Rolle.
  • Die korrekte Funktion jeder einzelnen Komponente muss überprüft werden (z. B. durch Funktionsprüfungen bzw. Selbsttests oder Lasttests).
  • Bei den eingesetzten Produkten müssen vor der Inbetriebnahme alle aktuellen sicherheitsrelevanten Patches bzw. Firmware-Updates eingespielt werden.
  • Für jede sicherheitsrelevante Einstellung muss ein Funktionstest der Sicherheitsmechanismen durchgeführt werden. Beispielsweise sollten die Verschlüsselung der Verbindung sowie die eingesetzten Authentisierungsfunktionen mittels eines Netzanalyse-Tools überprüft werden.
  • Bevor das System in den Produktiveinsatz genommen wird, muss es in einer vom Produktivnetz getrennten Umgebung aufgebaut und entsprechend getestet werden. Ebenfalls ist es empfehlenswert, bereits in der Testumgebung Performance-Messungen und einen Testlauf der Schlüsselverteilung durchzuführen. Nach Abschluss der Installation ist die korrekte Funktion des Gesamtsystems zu überprüfen (Abnahme und Freigabe der Installation). Bei allen durchgeführten Tests ist darauf zu achten, dass nur die zum Test befugten Personen Zugriff auf das VPN erhalten.
Ist die grundlegende Installation erfolgt, so kann mit der in der Folge beschriebenen sicheren Konfiguration des VPNs begonnen werden. Diese muss das System in einen sicheren Betriebszustand überführen, damit anschließend der laufende Betrieb aufgenommen werden kann. Für den reibungslosen Betrieb des VPNs sind die in 10.6.12 Sicherer Betrieb des VPN-Systems erwähnten Handlungsweisen essenziell. Die dabei gewonnenen Erkenntnisse und Korrekturmaßnahmen müssen angemessen dokumentiert und in das Feinkonzept eingearbeitet werden.
[eh SYS 7.4]

10.6.11.2 Sichere Konfiguration des VPN-Systems

ISO Bezug: 27002 10.6.2, 11.4
Alle VPN-Komponenten müssen sorgfältig konfiguriert werden, da es durch eine ungeeignete Konfiguration von VPN-Komponenten zu einem Verlust der Verfügbarkeit des Netzes oder Teilen davon kommen kann. Der Verlust der Vertraulichkeit von Informationen oder der Datenintegrität ist ebenfalls denkbar. Unabhängig davon, ob es sich bei VPN-Komponenten um dedizierte Hardware (Appliances) oder softwarebasierte Systeme handelt, spielt daher die korrekte Konfiguration der beteiligten Komponenten eine wesentliche Rolle. Da ein VPN aus mehreren Komponenten und deren Konfiguration besteht, ergibt sich eine erhöhte Komplexität der Gesamtkonfiguration. Das Ändern eines Konfigurationsparameters bei einer Komponente kann im Zusammenspiel mit den anderen Komponenten zu Sicherheitslücken, Fehlfunktionen oder Ausfällen führen.
Da die Konfiguration eines VPN-Systems in der Regel Veränderungen unterworfen ist (z. B. durch Personaländerungen, neue Nutzungsszenarien, Systemerweiterungen), kann nicht davon ausgegangen werden, dass es genau eine sichere (und statische) Konfiguration gibt, die einmal eingestellt und nie wieder verändert wird. Vielmehr wird die Konfiguration üblicherweise fortlaufend geändert. Es ist Aufgabe der für das VPN zuständigen AdministratorInnen, dass jeweils nur sichere Versionen der Systemkonfiguration definiert werden und das System von einer sicheren Konfiguration in die nachfolgende sichere Konfiguration überführt wird. Alle Änderungen und die jeweils aktuelle Einstellungen müssen nachvollziehbar dokumentiert sein.
Generell kann zwischen den folgenden Konfigurationskategorien unterschieden werden:
  • Die Default-Konfiguration ergibt sich durch die vom Hersteller voreingestellten Werte für die Konfigurationsparameter. Die Grundeinstellungen, die vom Hersteller oder Distributor einer VPN-Komponente vorgenommen werden, sind nicht unbedingt auf Sicherheit, sondern auf eine einfache Installation und Inbetriebnahme optimiert. Der erste Schritt bei der Grundkonfiguration muss daher sein, die Grundeinstellungen zu überprüfen und entsprechend den Vorgaben der Sicherheitsrichtlinie anzupassen. Standardpasswörter müssen durch eigene, ausreichend komplexe Passwörter ersetzt werden
  • Nach der Installation und vor der Inbetriebnahme muss - ausgehend von der Default-Konfiguration - eine sichere Anfangskonfiguration durch die AdministratorInnen eingestellt werden. Hier sollten möglichst restriktive Einstellungen gelten, so dass nur die berechtigten AdministratorInnen Veränderungen vornehmen können, um z. B. eine erste Betriebskonfiguration einzustellen, die das geplante Sicherheitskonzept umsetzt.
  • Die sicheren Betriebskonfigurationen ergeben sich aus den jeweiligen Konfigurationen im laufenden Betrieb. Hier muss auch regelmäßig überprüft werden, ob neu bekannt gewordene Sicherheitslücken Anpassungen erfordern.
  • Schließlich sollten sichere Notfallkonfigurationen im Rahmen der Notfallplanung definiert und dokumentiert werden. Sie dienen dazu, auch bei eingeschränkter Betriebsfähigkeit die Sicherheit aufrechtzuerhalten. In der Regel werden durch die Notfallplanung mehrere Notfallsituationen definiert. Es empfiehlt sich, für jede der definierten Situationen eine adäquate Notfallkonfiguration festzulegen. Im einfachsten Fall besteht die Notfallkonfiguration darin, den Zugang zum VPN-System zu sperren.
[eh SYS 7.5]

10.6.12 Sicherer Betrieb des VPN-Systems

ISO Bezug: 27002 10.6.2, 11.4, 11.5, 11.6, 11.7, 12.3
VPNs sind aufgrund der übertragenen Daten und der Möglichkeit ins interne Netz einzudringen attraktive Ziele für Angreifer und müssen daher sicher betrieben werden. Voraussetzungen hierfür sind die sichere Installation (vgl. 10.6.11.1 Sichere Installation des VPN-Systems) und Konfiguration (vgl. 10.6.11.2 Sichere Konfiguration des VPN-Systems) der beteiligten Hard- und Softwarekomponenten. Zusätzlich müssen alle organisatorischen Abläufe definiert und umgesetzt worden sein (z. B. Meldewege und Zuständigkeiten). Weiters ist zu beachten, dass die angestrebte Systemsicherheit nur gewährleistet werden kann, wenn auch die physikalische Sicherheit der beteiligten Hardwarekomponenten sichergestellt ist.
Die Sicherheit eines VPN-Systems lässt sich grob in drei Bereiche aufteilen:
  • die Sicherheit des VPN-Servers,
  • die Sicherheit der VPN-Clients und
  • die Sicherheit der Datenübertragung.
Im Umfeld des Servers sind folgende Empfehlungen für den sicheren Betrieb zu berücksichtigen:
  • Der VPN-Zugang sollte durch den Einsatz von Protokollierungs- und Managementwerkzeugen einer ständigen Überwachung unterliegen.
  • Die im Rahmen der Überwachung gesammelten Informationen sollten regelmäßig durch geschulte AdministratorInnen kontrolliert werden. Sie sollten dabei nach Möglichkeit durch eine Software zur Auswertung von Protokollierungsdaten unterstützt werden. Die Bestimmungen des Datenschutzes sind zu beachten.
  • Werden Sicherheitsvorfälle festgestellt, so sind sofort die vorher festgelegten Maßnahmen zu ergreifen.
  • Damit eine geregelte Benutzerauthentisierung beim VPN-Zugriff möglich ist, muss die Konsistenz der Authentisierungsdaten sichergestellt sein. Dies kann durch zentrale Verwaltung der Daten (Authentisierungsserver) oder durch periodischen Abgleich geschehen.
  • Für jede Verbindungsaufnahme ist immer die Benutzerauthentisierung über den gewählten Mechanismus durchzuführen.
  • Für jede Verbindung sollte die Absicherung der Kommunikation durch eines der im VPN-Sicherheitskonzept erlaubten Verfahren erzwungen werden, damit die übertragenen Daten geschützt sind.
  • Revision: Das VPN-System sollte in regelmäßigen Abständen einer Revision unterzogen werden. Die Rollen Administrator und Revisor dürfen nicht der gleichen Person zugeordnet werden.
Da VPN-Clients in der Regel in nicht vollständig kontrollierten Umgebungen betrieben werden, müssen für diesen Fall spezielle Mechanismen, Verfahren und Maßnahmen zum Einsatz kommen, die den Schutz des Clients gewährleisten können. Insbesondere mobile Clients sind hier einer besonderen Gefahr ausgesetzt, da diese physikalisch besonders leicht anzugreifen sind (Diebstahl, Vandalismus). Ist ein Client kompromittiert, so besteht die Gefahr, dass dadurch auch die Sicherheit des LANs beeinträchtigt wird.
Für den sicheren Betrieb von VPN-Clients sind daher folgende Aspekte zu berücksichtigen:
  • Die Grundsicherheit des IT-Systems muss gewährleistet sein.
  • Da mobile VPN-Clients größeren Risiken ausgesetzt sind als stationäre, sollten sie durch zusätzliche Maßnahmen gesichert werden. Hierzu bietet sich eine Festplattenverschlüsselung an, um sicherzustellen, dass von abhanden gekommenen Geräten weder Daten ausgelesen noch unbefugt eine VPN-Verbindung aufgebaut werden kann.
  • Insbesondere beim Zugriff über Internetverbindungen ist die Installation von Virenschutzprogrammen auf allen VPN-Clients notwendig.
  • Es sollte überlegt werden, auf den VPN-Clients so genannte PC-Firewalls einzusetzen und so vor unberechtigten Zugriffen aus dem Internet durch Dritte zu schützen. Ähnlich wie herkömmliche Firewalls (siehe 10.6.13 Entwicklung eines Firewallkonzeptesff.) filtern PC-Firewalls die Pakete der Netzkommunikationsprotokolle. Die Filterregeln können jedoch meist dynamisch durch die BenutzerInnen erzeugt werden. Hierzu wird bei jedem Zugriff, für den noch keine Regel vorliegt, eine Auswahl an möglichen Reaktionen (z. B. erlauben, ablehnen, bedingte Verarbeitung) angeboten, um eine neue Regel zu definieren. Da es für die BenutzerInnen jedoch in vielen Fällen schwierig ist, zwischen erlaubten und unberechtigten Zugriffen zu unterscheiden, sollte der Regelsatz durch die AdministratorInnen vorinstalliert werden.
  • Auch VPN-Clients sollten in das Systemmanagement einbezogen werden, soweit dies möglich ist. Dies erlaubt einerseits die Überwachung der Clients im Rahmen der Aufrechterhaltung des laufenden Betriebes. Andererseits können so einfach Software-Updates (Virendatenbanken, Anwendungsprogramme) auf geregeltem Weg eingespielt werden. Entfernte Rechner stellen jedoch erhöhte Anforderungen an das Systemmanagement, da diese nicht permanent mit dem Netz der Organisation verbunden sind, so dass die Rechner regelmäßig auf (unzulässige) Konfigurationsveränderungen untersucht werden müssen.
  • Falls TCP/IP als Protokoll verwendet wird, sollte überlegt werden, für VPN-Clients feste IP-Adressen zu benutzen und diese nicht dynamisch zu vergeben. Dieses Vorgehen bedeutet zwar einen höheren administrativen Aufwand (Wartung der Zuordnungstabellen), erlaubt jedoch eine eindeutige Zuordnung von Netzadresse und Rechner. Der Nachteil bei einer dynamischen Vergabe der Netzadressen besteht darin, dass protokolliert werden muss, welchem VPN-Client zu welchem Zeitpunkt eine bestimmte Netzadresse zugewiesen wurde. Anderenfalls ist es meist nicht möglich festzustellen, welcher VPN-Client eine bestimmte Aktion ausgeführt hat.
Die Kommunikationsverbindung zwischen VPN-Client und VPN-Server wird in der Regel über Netze von Dritten aufgebaut. Die dabei benutzten Netzkomponenten unterliegen meist nicht der Kontrolle durch den Betreiber des LANs, mit dem die Verbindung aufgebaut werden soll. Es muss weiter davon ausgegangen werden, dass die Daten nicht nur über das Telekommunikationsnetz eines Anbieters übertragen werden, sondern dass auch die Netze von Kooperationspartnern des Telekommunikationsanbieters benutzt werden. Dies gilt insbesondere beim Zugriff auf ein LAN aus dem Ausland. Um dem Schutzbedarf der so übertragenen Daten gerecht zu werden, müssen Sicherheitsmaßnahmen getroffen werden, die z. B. die Vertraulichkeit der Daten sicherstellen. Daher gilt für die Datenübertragung:
  • Die Nutzung der Datenverschlüsselung für alle übertragenen Daten ist für den sicheren Betrieb zwingend erforderlich.
  • Es sollten Signaturmechanismen eingesetzt werden, um die Authentizität und Integrität der Daten sicherzustellen.
Um diesen Anforderungen an den Schutz der Daten gerecht zu werden, können verschiedene Sicherungsmechanismen für VPN-Verbindungen benutzt werden. Relevant sind hier unter anderem:
  • Tunneling:
    Die Kommunikation kann auf niedriger Protokollebene verschlüsselt werden (so genanntes Tunneling, siehe auch 11.4.2 Einsatz geeigneter Tunnelprotokolle für die VPN-Kommunikation). Dazu muss ein geeignetes Verfahren ausgewählt werden. Die herkömmlichen VPN-Systeme stellen solche Verfahren (z. B. IPsec) standardmäßig, jedoch in unterschiedlicher Zahl und Ausprägung zur Verfügung.
  • SSL/TLS-Verschlüsselung:
    Zur Verschlüsselung kann auch SSL/TLS eingesetzt werden, wenn von der Verschlüsselung auf niedriger Protokollebene aus bestimmten Gründen kein Gebrauch gemacht werden kann. Dies gilt besonders für Zugriffe auf Webserver oder E-Mail-Server über Clients, die standardmäßig SSL/TLS-gesicherte Kommunikation unterstützen.
  • Verschlüsselung durch Netzkoppelelemente:
    Neben der Absicherung der Kommunikation durch Software kann auch der Einsatz von verschlüsselnden Netzkoppelelementen (Routern, Modems) erwogen werden. Diese sind besonders für den stationären Einsatz und zur Anbindung mehrerer Rechner sinnvoll, da die Verschlüsselung transparent erfolgt und die Clients und Server nicht belastet werden. Zu beachten ist jedoch, dass die Geräte sorgfältig konfiguriert und gewartet werden müssen.
  • E-Mail-Verschlüsselung:
    Für den Austausch von E-Mails über unsichere Kanäle kann die Nutzung von E-Mail-Verschlüsselung sinnvoll sein.
[eh SYS 7.6]

10.6.13 Entwicklung eines Firewallkonzeptes

ISO Bezug: 27002 10.6.2, 11.4.5
IT-Systeme, die zeitweise oder dauernd an Produktionsnetze angeschlossen sind, dürfen nur unter Verwendung ausreichender Sicherheitseinrichtungen mit Fremdnetzen verbunden werden. Diese Sicherheitseinrichtungen, die i. Allg. aus einem zwei- oder mehrstufigen System bestehen, werden als „Firewalls“ bezeichnet.
Um die Sicherheit des zu schützenden Netzes zu gewährleisten, muss eine geeignete Firewall eingesetzt werden. Damit eine Firewall effektiven Schutz bieten kann, müssen folgende grundlegende Bedingungen erfüllt sein.
Die Firewall muss
  • auf einer umfassenden Sicherheitspolitik aufsetzen (vgl. 10.9.2 Erstellung einer Internetsicherheitspolitik),
  • in der IT-Sicherheitspolitik und dem IT-Sicherheitskonzept der Organisation eingebettet sein,
  • korrekt installiert und
  • korrekt administriert werden.
Der Anschluss an ein Fremdnetz darf erst dann erfolgen, wenn überprüft worden ist, dass mit dem gewählten Firewallkonzept sowie den personellen und organisatorischen Randbedingungen alle Risiken beherrscht werden können.
Die Aufgaben und Anforderungen an die Firewall müssen in der Internetsicherheitspolitik festgelegt werden.
Damit eine Firewall einen wirkungsvollen Schutz eines Netzes gegen Angriffe von außen bietet, müssen einige grundlegende Voraussetzungen erfüllt sein:
  • Jede Kommunikation zwischen den beiden Netzen muss ausnahmslos über die Firewall geführt werden. Dafür muss sichergestellt sein, dass die Firewall die einzige Schnittstelle zwischen den beiden Netzen darstellt. Es müssen Regelungen getroffen werden, dass keine weiteren externen Verbindungen unter Umgehung der Firewall geschaffen werden dürfen.
  • Eine Firewall darf ausschließlich als schützender Übergang zum internen Netz eingesetzt werden, daher dürfen auf einer Firewall nur die dafür erforderlichen Dienste verfügbar sein und keine weiteren Dienste wie z. B. ein Webserver, angeboten werden.
  • Ein administrativer Zugang zur Firewall darf nur über einen gesicherten Weg möglich sein, also z. B. über eine gesicherte Konsole, eine verschlüsselte Verbindung oder ein separates Netz. Eine Konsole sollte in einem Serverraum aufgestellt sein.
  • Eine Firewall baut auf einer für das zu schützende Netz definierten Sicherheitspolitik auf und gestattet nur die dort festgelegten Verbindungen. Diese Verbindungen müssen gegebenenfalls sehr detailliert (bis hin zu einer individuellen Angabe von IP-Adresse, Dienst, Zeit, Richtung und BenutzerIn getrennt) festgelegt werden können.
  • Jede Sicherheitspolitik muss konzeptionell auf bestmögliche Reduktion des eventuellen Schadensfalles ausgelegt sein (Betrieb von Teilnetzen, frühzeitiger Einsatz von Routern, …). In diesem Zusammenhang ist auch der Raum, in dem die Firewall betrieben wird, zusammen mit den Netzwerkeinrichtungen (wie z. B. Routern) einer besonderen Zugangskontrolle zu unterwerfen (vgl. 9.1.4 Zutrittskontrolle und 9.5.6 Serverräume).
  • Es ist zu entscheiden, ob besonders sensible Daten im Netz besser und kostengünstiger durch organisatorische als durch technische Maßnahmen geschützt werden sollen.
  • Für die Konzeption und den Betrieb einer Firewall muss geeignetes Personal zur Verfügung stehen. Der zeitliche Aufwand für den Betrieb einer Firewall darf nicht unterschätzt werden. Alleine die Auswertung der angefallenen Protokolldaten nimmt erfahrungsgemäß viel Zeit in Anspruch. Firewall-AdministratorInnen müssen fundierte Kenntnisse über die eingesetzten IT-Komponenten besitzen und auch entsprechend geschult werden.
  • Das Firewallkonzept muss sich permanent an Betriebserfahrungen der Firewall sowie aktuellen Entwicklungen orientieren und bei Bedarf unverzüglich angepasst werden.
  • Die BenutzerInnen des lokalen Netzes sollten durch den Einsatz einer Firewall möglichst wenig Einschränkungen hinnehmen müssen.
Eine Firewall kann das interne Netz vor vielen Gefahren beim Anschluss an das Internet schützen, aber nicht vor allen. Beim Aufbau einer Firewall und der Erarbeitung einer Firewall-Sicherheitspolitik sollte man sich daher die Grenzen einer Firewall verdeutlichen:
  • Es werden Protokolle überprüft, nicht die Inhalte. Eine Protokollprüfung bestätigt beispielsweise, dass eine E-Mail mit ordnungsgemäßen Befehlen zugestellt wurde, kann aber keine Aussagen zum eigentlichen Inhalt der E-Mail machen.
  • Die Filterung von aktiven Inhalten ist unter Umständen nur teilweise erfolgreich.
  • Sobald BenutzerInnen eine Kommunikation über eine Firewall herstellen dürfen, können sie über das verwendete Kommunikationsprotokoll beliebige andere Protokolle tunneln. Damit könnten InnentäterInnen Externen den Zugriff auf interne Rechner ermöglichen.
  • Eine Einschränkung der Internetzugriffe auf festgelegte Webserver ist in der Realität unmöglich, da zu viele Webserver auch als Proxies nutzbar sind, so dass eine Sperrung bestimmter IP-Adressen leicht umgangen werden kann.
  • Die Filtersoftware ist häufig noch unausgereift. Beispielsweise ist es möglich, dass nicht alle Arten der Adressierung erfasst werden. Zudem können URL-Filter durch Nutzung von „Anonymizern“ umgangen werden.
  • Die Filterung von Spam-E-Mails ist noch nicht 100 % ausgereift. Keine Firewall kann zweifelsfrei feststellen, ob eine E-Mail vom Empfänger erwünscht ist oder nicht. Spam-E-Mails dürften erst dann verschwinden, wenn die Absender zweifelsfrei nachweisbar sind. Dies ist aber mit dem herkömmlichen Protokoll SMTP alleine nicht realisierbar.
  • Firewalls schützen nicht vor allen Denial-of-Service-Attacken. Wenn AngreiferInnen z. B. die Anbindung zum Provider lahm legt, kann auch die beste Firewall nicht helfen. Außerdem gibt es immer wieder Implementationsfehler von Protokollen auf Endgeräten, die eine Firewall nicht abfangen kann.
  • Leider ermöglichen viele Firewalls es nicht, durch Hintereinanderschaltung von verschiedenen Firewalls eine erhöhte Sicherheit zu erlangen. Gerade in größeren Firmen ist dies problematisch, wenn innerhalb der Firma Firewalls z. B. auch zur Bildung von abgesicherten Teilnetzen eingesetzt werden.
  • Eine Firewall kann zwar einen Netzübergang sichern, sie hat aber keinen Einfluss auf die Sicherheit der Kommunikation innerhalb dieser Netze!
  • Auch die speziell unter Sicherheitsaspekten entwickelten Komponenten von Firewalls können trotz großer Sorgfalt Programmierfehler enthalten.
  • Firewalls können nur begrenzt gegen eine absichtliche oder versehentliche Fehlkonfiguration der zu schützenden Clients und Server schützen.
  • Eingebaute Hintertüren in der verwendeten Software können eventuell auch durch eine Firewall hindurch ausgenutzt werden. Im Extremfall kann die Software der Firewall selbst Hintertüren enthalten.
  • Die korrekte Konfiguration der Komponenten der Firewall ist oft sehr anspruchsvoll. Fehler in der Konfiguration können zu Sicherheitslücken oder Ausfällen führen.
  • Ist die Dokumentation der technischen Ausstattung der Firewall durch den Hersteller mangelhaft, so begünstigt dies Fehler bei Konfiguration und Administration.
  • Wenn die Komponenten der Firewall falsch dimensioniert sind, kann die Verfügbarkeit beeinträchtigt werden. Wird beispielsweise der Rechner, auf dem ein HTTP-Sicherheitsproxy läuft, zu schwach dimensioniert (zu wenig Arbeitsspeicher, zu langsamer Prozessor), so kann dies die Geschwindigkeit des Internetzugriffes stark beeinträchtigen.
  • Es kann nicht verhindert werden, dass Angreifer die Komponenten der Firewall mit Hilfe von Schwachstellenscannern analysieren.
  • Eine Firewall kann nicht gegen die bewusste oder unbewusste Missachtung von Sicherheitsrichtlinien und -konzepten durch die Anwender schützen.
  • Eine Firewall schützt nicht vor dem Missbrauch freigegebener Kommunikation durch Innentäter („Insider-Angriffe“).
  • Eine Firewall schützt nicht vor Social Engineering.
  • Werden mobile Endgeräte (Notebook, PDA etc.), die von Mitarbeitern auch extern benutzt werden, an das interne Netz angeschlossen, so kann auf diese Weise Schadsoftware (Viren, Würmer, Trojanische Pferde) in das vertrauenswürdige Netz eingeschleppt werden.
  • Eine Firewall schützt auch nicht davor, dass Schadprogramme auf Austauschmedien, z. B. externe Festplatten, CD-ROM, USB-Stick, …, in das vertrauenswürdige Netz eingeschleppt werden.
[eh SYS 8.2]

10.6.14 Installation einer Firewall

ISO Bezug: 27002 10.2., 10.3, 10.6.2, 11.4, 11.6, 12.1
Bei der Installation einer Firewall sind folgende Schritte in der angegebenen Reihenfolge zu setzen (vgl. [KIT S04]):
  1. Festlegen der Sicherheitspolitik sowie der Benutzungsordnung durch organisatorisch und technisch Verantwortliche in Zusammenarbeit mit BenutzervertreterInnen (vgl. auch 8.1.1 Verpflichtung der MitarbeiterInnen zur Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen)
  2. Bestimmung der Sicherheitsverantwortlichen (Datenschutz-/IT-Sicherheitsbeauftragte/r (soweit nicht bereits nominiert) und Bereichs-IT-Sicherheitsbeauftragte („Internetsicherheitsbeauftragte/r“)
  3. Definition der angebotenen und anzufordernden Dienste
  4. Analyse der Hard- und Softwarevoraussetzungen im internen Netz
  5. Auswahl geeigneter Produkte
  6. Installation und Konfiguration der Firewall
    Der administrative Zugang zur Sicherheitseinrichtung darf nur über einen gesicherten Weg möglich sein.
  7. Überprüfung der Installation durch Querlesen der Definitionen und Funktionskontrolle
  8. Dokumentation der Installation zum Zweck der Nachvollziehbarkeit, der Wartung und der Validierung
  9. Laufende Beobachtung und Wartung
  10. Periodische Sicherheitsüberprüfung durch befugte Externe zu nicht angekündigten Zeitpunkten mindestens einmal im Quartal („Screening“, vgl. 10.6.15 Sicherer Betrieb einer Firewall) sowie Weitermeldung der erhobenen Fakten an die Vorgesetzten
  11. Revision der Behebung der bei den Sicherheitstests erhobenen Mängel
  12. Sammlung der relevanten Projekterfahrungen als Grundlage für eine Weiterentwicklung der Internetsicherheitspolitik und des Firewallkonzeptes. Im Bereich der öffentlichen Verwaltung sollten diese Projekterfahrungen an die IKT-Koordinierungsstelle weitergegeben werden.
  13. Aus- und Weiterbildung des administrierenden Personals
[eh SYS 8.3]

10.6.15 Sicherer Betrieb einer Firewall

ISO Bezug: 27002 10.6.2, 11.4, 11.6, 12.4, 13.1, 13.2.1, 14.1.1, 15.1.5, 15.2
Für einen sicheren Betrieb einer Firewall sind eine fachgemäße Administration sowie eine regelmäßige Überprüfung auf die korrekte Einhaltung der umgesetzten Sicherheitsmaßnahmen (Screening) erforderlich.
Insbesondere müssen die für den Betrieb der Firewall getroffenen organisatorischen Regelungen regelmäßig oder zumindest sporadisch auf ihre Einhaltung überprüft werden. Es sollte in zyklischen Abständen kontrolliert werden, ob neue Zugänge unter Umgehung der Firewall geschaffen wurden. Alle Sicherheitskontrollen sollten zumindest teilweise auch durch Externe vorgenommen werden.

Administration

Die Administration einer Firewall umfasst die nachfolgend angeführten Aufgaben:
  • Anlegen und Entfernen von BenutzerInnen, Profilen, Filtern etc.,
  • Ändern von Berechtigungen, Funktionen etc.,
  • Kontrolle und Auswertung der Logfiles,
  • Einschränken und Beenden des Internetzugangs,
  • Weiterleitung sicherheitsrelevanter Beobachtungen an die in der Sicherheitspolitik definierten Instanzen,
  • Benachrichtigung der zuständigen Instanzen bei Entdecken von Angriffen aus dem Internet,
  • Verfolgen der aktuellen Entwicklungen im Bereich Sicherheit (z. B. durch Lesen der entsprechenden Newsletter) sowie entsprechende Weiterbildung.
Durch eine angemessene Stellvertreterregelung (und eine entsprechende Schulung der StellvertreterInnen) ist eine kontinuierliche Administration zu gewährleisten.

Regelmäßige Überprüfung

Zusätzlich zu den regelmäßigen Wartungsaktivitäten ist es erforderlich, eine Firewall regelmäßig (etwa einmal pro Quartal) durch eine geeignete Instanz kontrollieren zu lassen. Sicherheitsrelevante Änderungen erfordern zusätzlich „ad hoc“-Kontrollen. Diese Kontrollen sollten vorzugsweise durch eine vertrauenswürdige externe Instanz erfolgen, da die Gefahr besteht, dass Firewall-AdministratorInnen durch Gewöhnungseffekte und Routinearbeit bestimmte Sicherheitslücken übersehen könnten, die neutralen BeobachterInnen mit hoher Wahrscheinlichkeit auffallen. (Vgl. auch Screening, Security Compliance Checking.)
Eine derartige Prüfung ist wie folgt durchzuführen:
  • Überprüfung der Installation von außen,
  • interne Überprüfung der Internetsicherheitspolitik,
  • interne Überprüfung der Konfiguration,
  • interne Durchführung eventuell notwendiger Korrekturen,
  • erneute Prüfung von außen.
Dabei sind die folgenden Punkte zu beachten:
  • Alle Filterregeln müssen korrekt umgesetzt sein. Dabei ist zu testen, dass nur die Dienste zugelassen werden, die in der Sicherheitspolitik vorgesehen sind.
  • Die Defaulteinstellung der Filterregeln und die Anordnung der Komponenten müssen sicherstellen, dass alle Verbindungen, die nicht explizit erlaubt sind, blockiert werden. Dies muss auch bei einem völligen Ausfall der Firewall-Komponenten gelten.
  • Es muss die Regel „Alles, was nicht ausdrücklich erlaubt ist, ist verboten“ realisiert sein. So dürfen z. B. BenutzerInnen, die keinen Eintrag in einer Access-Liste haben, keine Möglichkeit haben Dienste des Internets zu benutzen.
  • Um ein Mitlesen oder Verändern der Authentisierungsinformationen zu verhindern, dürfen sich AdministratorInnen und Revisor nur über einen vertrauenswürdigen Pfad authentisieren. Dies könnte z. B. direkt über die Konsole, eine verschlüsselte Verbindung oder ein separates Netz erfolgen.
  • Es müssen in regelmäßigen Abständen Integritätstests der eingesetzten Software durchgeführt werden. Im Fehlerfall ist die Firewall abzuschalten.
  • Die Firewall muss auf ihr Verhalten bei einem Systemabsturz getestet werden. Insbesondere darf kein automatischer Neustart möglich sein, und die Access-Listen müssen auf einem schreibgeschützten Medium speicherbar sein. Die Access-Listen sind die wesentlichen Daten für den Betrieb der Firewall und müssen besonders gesichert werden, damit keine alten oder fehlerhaften Access-Listen bei einem Neustart benutzt werden, der durch AngreiferInnen provoziert wird.
  • Bei einem Ausfall der Firewall muss sichergestellt sein, dass in dieser Zeit keine Netzverbindungen aus dem zu schützenden Netz heraus oder zu diesem aufgebaut werden können.
  • Auf den eingesetzten Komponenten dürfen nur Programme, die für die Funktionsfähigkeit der Firewall nötig sind, vorhanden sein. Der Einsatz dieser Programme muss ausführlich dokumentiert und begründet werden. Beispielsweise sollten die Software für die graphische Benutzeroberfläche sowie alle Treiber, die nicht benötigt werden, entfernt werden. Diese sollten auch aus dem Betriebssystem-Kern entfernt werden. Das Verbleiben von Software muss dokumentiert und begründet werden.
  • Beim Wiedereinspielen von gesicherten Datenbeständen muss darauf geachtet werden, dass für den sicheren Betrieb der Firewall relevante Dateien wie Access-Listen, Passwortdateien oder Filterregeln auf dem aktuellsten Stand sind.
Falls nachträgliche Änderungen der Sicherheitspolitik erforderlich sind, müssen diese streng kontrolliert und insbesondere auf Seiteneffekte überprüft werden.
[eh SYS 8.4]

10.6.16 Firewalls und aktive Inhalte

ISO Bezug: 27002 10.4, 10.6.2, 10.10, 11.6, 11.7
Eines der größten Probleme bei der Konzeption einer Firewall ist die Behandlung der Probleme, die durch die Übertragung aktiver Inhalte zu den Rechnern im zu schützenden Netz entstehen. Hierunter fällt nicht nur die Erkennung und Beseitigung von Viren, die verhältnismäßig einfach auch auf den Rechnern der AnwenderInnen durchgeführt werden kann, sondern auch das weit schwieriger zu lösende Problem der Erkennung von ActiveX-Controls, Java-Applets oder Scripting-Programmen mit einer Schadfunktion.
Die Kontrolle aktiver Inhalte kann auf verschiedene Weise geschehen. Eine der Möglichkeiten ist die Filterung durch eine Firewall. Siehe dazu: 10.4.11 Schutz vor aktiven Inhalten.
[eh SYS 8.5]

10.6.17 Firewalls und Verschlüsselung

ISO Bezug: 27002 10.4.2, 10.6.2, 11.4.6, 11.4.7, 12.3
Da im Internet die Daten über nicht vorhersagbare Wege und Knotenpunkte verschickt werden, sollten die zu versendenden Daten möglichst nur verschlüsselt übertragen werden. Hierbei wäre es sinnvoll, wenn entsprechende Mechanismen schon in den unteren Schichten des Protokolls vorgesehen würden.
Zunächst sollte aber unterschieden werden zwischen
  • Verschlüsselung auf der Firewall bzw. auf Netzkoppelelementen, die zum Aufbau sicherer Teilnetze eingesetzt werden, und
  • Verschlüsselung auf den Endgeräten, die z. B. von BenutzerInnen bedarfsabhängig eingesetzt wird.

Verschlüsselung auf der Firewall:

Um mit externen Kommunikationspartnern Daten über ein offenes Netz auszutauschen und /oder diesen Zugriff auf das eigene Netz zu geben, kann der Aufbau von virtuellen privaten Netzen (VPNs) sinnvoll sein. Dafür sollten alle Verbindungen von und zu diesen Partnern verschlüsselt werden, damit Unbefugte keinen Zugriff darauf nehmen können. Zum Aufbau von verschlüsselten Verbindungen können eine Vielzahl von Hard- und Softwarelösungen eingesetzt werden. Sollen hierbei nur wenige Liegenschaften miteinander verbunden werden, sind insbesondere Hardwarelösungen basierend auf symmetrischen kryptographischen Verfahren eine einfache und sichere Lösung.
Die Ver- bzw. Entschlüsselung kann auf verschiedenen Geräten erfolgen. So könnte eine Hardwarelösung im Paketfilter als Schlüsselgerät arbeiten. Dies ist insbesondere dann sinnvoll, wenn keine unverschlüsselte Kommunikation über dieses Gerät gehen soll. Die Integration der Verschlüsselung auf dem Application-Gateway hat dagegen den Vorteil einer leichteren Benutzerverwaltung. Zudem können AngreiferInnen, die einen externen Informationsserver unter ihre Kontrolle gebracht haben, die verschlüsselte Kommunikation nicht belauschen.

Verschlüsselung auf den Endgeräten:

Zum Schutz der Vertraulichkeit bestimmter Daten, insbesondere bei der Versendung von E-Mails, bietet sich auch der Gebrauch von Mechanismen an, die eine Ende-zu-Ende-Verschlüsselung ermöglichen. Hierfür wird zum Beispiel häufig das frei verfügbare Programmpaket PGP (Pretty Good Privacy) eingesetzt. Für eine vertrauenswürdige Datenübertragung mit ausgewählten Partnern im Internet sollten Programme wie SSH oder SFTP eingesetzt werden, die eine Verschlüsselung der übertragenen Daten (z. B. mittels SSL/TLS) unterstützen.
Die Verschlüsselung auf den Endsystemen wird auf absehbare Zeit noch applikationsgebunden sein, z. B. durch den Einsatz von S/MIME (Secure/Multipurpose Internet Mail Extensions), SSL/TLS oder PGP. Die Verschlüsselung von Daten stellt andererseits aber auch ein großes Problem für den wirksamen Einsatz von Firewalls dar, d. h. den Filtern. Wenn die Übertragung verschlüsselter Daten über die Firewall zugelassen wird (z. B. SSL/TLS), sind Filter auf der Anwendungsschicht nicht mehr in der Lage, die Nutzdaten z. B. in Hinblick auf Viren oder andere Schadprogramme zu kontrollieren. Auch die Protokollierungsmöglichkeiten werden durch eine Verschlüsselung stark eingeschränkt. Eine erste ad-hoc-Lösung könnte darin bestehen, nur von bestimmten internen Rechnern den Aufbau von SSL/TLS-Verbindungen zu erlauben, u.U. nur zu ausgewählten Zielsystemen. Andererseits sind die Daten selbst dann geschützt, wenn AngreiferInnen das Application-Gateway unter ihre Kontrolle gebracht haben.
Eine temporäre Entschlüsselung auf einer Filterkomponente zu Analysezwecken ist weder praktikabel noch wünschenswert.
Eine generelle Empfehlung für oder gegen den Einsatz von Verschlüsselung über oder an der Firewall kann nicht gegeben werden, dies hängt von den Anforderungen im Einzelfall ab.
[eh SYS 8.6]

10.6.18 Einsatz von Verschlüsselungsverfahren zur Netzkommunikation

ISO Bezug: 27002 10.6.1, 10.6.2, 12.2.3, 10.7.3
Kommunikationsnetze transportieren Daten zwischen IT-Systemen. Dabei werden die Daten selten über eine dedizierte Kommunikationsleitung zwischen den an der Kommunikation beteiligten Partnern übertragen. Vielmehr werden die Daten über viele Zwischenstationen geleitet. Je nach Kommunikationsmedium und verwendeter Technik können die Daten von den Zwischenstationen unberechtigt abgehört werden, oder auch von im jeweiligen Vermittlungsnetz angesiedelten Dritten (z. B. bei der Verwendung des Ethernetprotokolls ohne Punkt-zu-Punkt-Vernetzung). Da die zu übertragenden Daten nicht von unberechtigten Dritten abgehört, verändert oder zur späteren Wiedereinspeisung in das Netz (Replay-Attacke) benutzt werden sollen, muss ein geeigneter Mechanismus eingesetzt werden, der dies verhindert. Verschlüsselung der Daten mit - wenn nötig - gegenseitiger Authentifizierung der Kommunikationspartner kann diese Gefahr (je nach Stärke des gewählten Verschlüsselungsverfahrens sowie der Sicherheit der verwendeten Schlüssel) reduzieren.
In der Regel kommunizieren Anwendungen miteinander, um anwendungsbezogene Informationen auszutauschen. Die Verschlüsselung der Daten kann nun auf mehreren Ebenen erfolgen:
  • Auf Applikationsebene:
    Die kommunizierenden Applikationen müssen dabei jeweils über die entsprechenden Ver- und Entschlüsselungsmechanismen verfügen.
  • Auf Betriebssystemebene:
    Die Verschlüsselung wird vom lokalen Betriebssystem durchgeführt. Jegliche Kommunikation über das Netz wird automatisch oder auf Anforderung verschlüsselt.
  • Auf Netzkoppelelementebene:
    Die Verschlüsselung findet zwischen den Netzkoppelelementen (z. B. Router) statt.
Die einzelnen Mechanismen besitzen spezifische Vor- und Nachteile. Die Verschlüsselung auf Applikationsebene hat den Vorteil, dass die Verschlüsselung vollständig der Kontrolle der jeweiligen Applikation unterliegt. Ein Nachteil ist, dass zur verschlüsselten Kommunikation nur eine mit demselben Verschlüsselungsmechanismus ausgestattete Partnerapplikation in Frage kommt. Weiters können entsprechende Authentifizierungsmechanismen zwischen den beiden Partnerapplikationen zur Anwendung kommen.
Im Gegensatz dazu findet die Verschlüsselung im Fall der Verschlüsselung auf Betriebssystemebene transparent für jede Applikation statt. Jede Applikation kann mit jeder anderen Applikation verschlüsselt kommunizieren, sofern das Betriebssystem, unter dem die Partnerapplikation abläuft, über den Verschlüsselungsmechanismus verfügt. Nachteilig wirkt sich hier aus, dass bei einer Authentifizierung lediglich die Rechner gegenseitig authentifiziert werden können, und nicht die jeweiligen Partnerapplikationen.
Der Einsatz von verschlüsselnden Netzkoppelelementen besitzt den Vorteil, dass applikations- und rechnerseitig keine Verschlüsselungsmechanismen vorhanden sein müssen. Die Verschlüsselung ist auch hier transparent für die Kommunikationspartner, allerdings findet die Kommunikation auf der Strecke bis zum ersten verschlüsselnden Netzkoppelelement unverschlüsselt statt und birgt damit ein Restrisiko. Authentifizierung ist hier nur zwischen den Koppelelementen möglich. Die eigentlichen Kommunikationspartner werden hier nicht authentifiziert.
Werden sensitive Daten über ein Netz (auch innerhalb des Intranets) übertragen, empfiehlt sich der Einsatz von Verschlüsselungsmechanismen. Bieten die eingesetzten Applikationen keinen eigenen Verschlüsselungsmechanismus an oder wird das angebotene Verfahren als zu schwach eingestuft, so sollte von der Möglichkeit der betriebssystemseitigen Verschlüsselung Gebrauch gemacht werden. Hier bieten sich z. B. Verfahren wie SSL/TLS an, die zur transparenten Verschlüsselung auf Betriebssystemebene entworfen wurden. Je nach Sicherheitspolitik können auch verschlüsselnde Netzkoppelelemente eingesetzt werden, etwa um ein virtuelles privates Netz (VPN) mit einem Kommunikationspartner über das Internet zu realisieren. Entsprechende Softwaremechanismen sind in der Regel auch in Firewall-Systemen verfügbar.
Erfolgt der Zugang auf sensible Daten über einen externen Zugang, so sind kryptographische Einmalverfahren mit einer Besitzkomponente einzusetzen. Wegen der einheitlichen Administrierbarkeit wird empfohlen für den Zugang die Bürgerkarte/Dienstkarte und MOA-ID zu verwenden [IKTB-140605-01] .
Beim Einsatz von verschlüsselter Kommunikation und gegenseitiger Authentifizierung sind umfangreiche Planungen im Rahmen der Sicherheitspolitik eines Unternehmens bzw. einer Behörde nötig. Im Rahmen der hier angesprochenen Kommunikationsverschlüsselungen sind insbesondere folgende Punkte zu beachten:
  • Welche Verfahren sollen zur Verschlüsselung benutzt werden bzw. werden angeboten (z. B. in Routern)?
  • Unterstützen/Nutzen die eingesetzten Verschlüsselungsmechanismen existierende oder geplante Standards (IPsec, IPv6, IKE; SSL/TLS); vgl. dazu auch 10.8.6 Geeignete Auswahl eines E-Mail-Clients/-Servers zu Zugang zu E-Mail.
  • Sind gemäß der Sicherheitspolitik ausreichend starke Verfahren und entsprechend lange Schlüssel gewählt worden?
  • Werden die Schlüssel sicher aufbewahrt?
  • Werden die Schlüssel in einer sicheren Umgebung erzeugt, und gelangen sie auf sicherem Weg zum notwendigen Einsatzpunkt (Rechner, Softwarekomponente)?
  • Sind Schlüssel-Recovery-Mechanismen nötig?
Ähnliche Fragestellungen sind bei der Nutzung von Zertifikaten zur Authentifizierung von Kommunikationspartnern zu beachten.
Im Bereich der öffentlichen Verwaltung sind außerdem bezüglich der Verschlüsselung des E-Mail-Verkehrs entsprechende Vorgaben, wie etwa die Vorgabe der Eigenschaften von Verschlüsselungszertifikaten gemäß des IKT-Board-Beschlusses [IKTB-181202-1] zu beachten.
[eh SYS 8.17]

10.7 Betriebsmittel und Datenträger

In diesem Kapitel werden generelle Richtlinien zum Umgang mit Betriebsmitteln und Datenträgern gegeben. Der Umgang mit Datenträgern und den darauf gespeicherten Informationen ist in der „Informationssicherheitspolitik“ einer Organisation festzulegen (vgl. dazu 5.2.5 Klassifizierung von Informationen). Diese Klassifikation und die damit verbundene Festlegung der Verantwortlichkeiten und Vorgehensweisen stellen eine wesentliche Grundlage für die IT-Sicherheit einer Organisation dar.
Insbesondere sei darauf hingewiesen, dass einerseits die Klassifizierung der Daten national durch das Datenschutzgesetz 2000 sowie durch das Informationssicherheitsgesetz geregelt wird. International bzw. im EU-Raum ist der „Beschluss des Rates vom 19. März 2001 über die Annahme der Sicherheitsvorschriften des Rates“ (2001/264/EG) einzuhalten, der die Verbindung zwischen den nationalen Klassifizierungen und Richtlinien darstellt. Dies ist gegebenenfalls in der Informationssicherheitspolitik zu berücksichtigen.

10.7.1 Betriebsmittelverwaltung

ISO Bezug: 27002 7.1, 10.7.2
Betriebsmittel für den IT-Einsatz sind alle erforderlichen Mittel wie Hardwarekomponenten (Rechner, Tastatur, Drucker, …), Software (Systemsoftware, Individualprogramme, Standardsoftware u. ä.), Verbrauchsmaterial (Papier, Toner, Druckerpatronen), Datenträger (Magnetbänder, Disketten, Streamertapes, Festplatten, Wechselplatten, CD-ROMs u. ä.).
Die Betriebsmittelverwaltung umfasst folgende Aufgaben:
  • Beschaffung,
  • Prüfung vor Einsatz,
  • Kennzeichnung,
  • Bestandsführung und
  • Außerbetriebnahme.

Beschaffung:

Neben reinen Wirtschaftlichkeitsaspekten kann durch ein geregeltes Beschaffungsverfahren auch die Neu- und Weiterentwicklung im Bereich der Informationstechnik stärker berücksichtigt werden. Eine zentrale Beschaffung sichert auch die Einführung und Einhaltung eines „Hausstandards“ und vereinfacht damit die Schulung der MitarbeiterInnen und die Wartung.

Prüfverfahren vor Einsatz:

Mit einem geregelten Prüfverfahren vor Einsatz der Betriebsmittel lassen sich unterschiedliche Gefährdungen abwenden.
Beispiele dafür sind:
  • Überprüfung der Vollständigkeit von Lieferungen (z. B. Handbücher), um die Verfügbarkeit aller Lieferteile zu gewährleisten,
  • Test neuer PC-Software sowie neuer vorformatierter Datenträger mit einem Virensuchprogramm,
  • Testläufe neuer Software auf speziellen Testsystemen,
  • Überprüfung der Kompatibilität neuer Hardware- und Softwarekomponenten mit den vorhandenen.

Bestandsführung:

Alle wesentlichen Betriebsmittel sollten mit eindeutigen Identifizierungsmerkmalen gekennzeichnet werden. Zusätzlich sollten die Seriennummern vorhandener Geräte wie Bildschirm, Drucker, Festplatten etc. dokumentiert werden, damit sie nach einem Diebstahl identifiziert werden können.
Für die Bestandsführung müssen die Betriebsmittel in Bestandsverzeichnissen aufgelistet werden. Ein solches Bestandsverzeichnis muss Auskunft geben können über Identifizierungsmerkmale, Beschaffungsquellen, Lieferzeiten, Verbleib der Betriebsmittel, Lagerhaltung, Aushändigungsvorschriften, Wartungsverträge und Wartungsintervalle.
Eine ordnungsgemäße Bestandsführung erleichtert nicht nur die Verbrauchsermittlung und Veranlassung von Nachbestellungen, sondern ermöglicht auch Vollständigkeitskontrollen, die Überprüfung des Einsatzes von nicht genehmigter Software oder die Feststellung der Entwendung von Betriebsmitteln.
Im Bundesbereich gibt es Vorschriften über die Bestandsführung, die „Richtlinien für die Inventar- und Materialverwaltung (RIM)“. Die dort vorgesehenen Aufzeichnungen reichen aber für einen sicheren EDV-Betrieb nicht aus. Die für den sicheren Betrieb zuständige Organisationseinheit muss daher eigene, entsprechend erweiterte Aufzeichnungen führen.
[eh SYS 2.1]

10.7.2 Datenträgerverwaltung

ISO Bezug: 27002 10.7.1
Die Datenträgerverwaltung stellt einen Teil der Betriebsmittelverwaltung dar. Ihre Aufgabe ist es, den Zugriff auf Datenträger im erforderlichen Umfang und in angemessener Zeit zu gewährleisten.
Neben den in 10.7.1 Betriebsmittelverwaltung angeführten Maßnahmen ist für die Verwaltung von Datenträgern zusätzlich zu beachten:
  • Die äußerliche Kennzeichnung von Datenträgern soll deren schnelle Identifizierung ermöglichen, jedoch für Unbefugte keine Rückschlüsse auf den Inhalt erlauben (z. B. die Kennzeichnung eines Datenträgers mit dem Stichwort „Gehaltsdaten“), um einen Missbrauch zu erschweren. Eine festgelegte Struktur von Kennzeichnungsmerkmalen (z. B. Datum, Ablagestruktur, lfd. Nummer) erleichtert die Zuordnung in Bestandsverzeichnissen.
  • Für eine sachgerechte Behandlung von Datenträgern sind die Herstellerangaben zu beachten.
  • Hinsichtlich der Aufbewahrung von Datenträgern sind einerseits Maßnahmen zur Lagerung (magnetfeld-/staubgeschützt, klimagerecht) und andererseits Maßnahmen zur Verhinderung des unbefugten Zugriffs (geeignete Behältnisse, Schränke, Räume) zu treffen.
  • Versand und Transport: Die Verpackung des Datenträgers ist an seiner Schutzbedürftigkeit auszurichten. Hier sind die in der Informationssicherheitspolitik festzulegenden Regeln umzusetzen (etwa Versand nur in verschlossenen/versiegelten Behältnissen, durch Kurierdienst, in chiffrierter Form etc.).
  • Der Datenträger darf über die zu versendenden Daten hinaus keine „Restdaten“ enthalten. Dies kann durch physikalisches Löschen erreicht werden (siehe auch unten „Wiederaufbereitung“).
  • Vor Versand oder Weitergabe wichtiger Datenträger sollte eine Sicherungskopie erstellt werden. Das Anfertigen von Kopien ist zu dokumentieren und die Kopien sind als solche zu kennzeichnen.
  • Wiederaufbereitung:
    Eine geregelte Vorgehensweise für die Löschung bzw. Wiederaufbereitung von Datenträgern verhindert den Missbrauch der gespeicherten Daten. Vor der Wiederverwendung von Datenträgern, die schutzwürdige Daten enthalten haben, müssen diese Daten in irreversibler Form gelöscht werden.
  • Außerbetriebnahme, Reparaturtausch: Datenträger, die schutzwürdige Daten enthalten und außer Betrieb genommen oder im Zuge einer Reparatur ausgetauscht werden sollen, sind mechanisch zu zerstören (vgl. dazu auch ÖNORM S 2109 Akten- und Datenvernichtung sowie 12.7 Wartung).
Für den Fall, dass von Dritten erhaltene Datenträger eingesetzt werden, sind Regelungen über deren Behandlung vor dem Einsatz zu treffen. Werden zum Beispiel Daten für PCs übermittelt, sollte generell ein Viren-Check des Datenträgers erfolgen. Dies gilt entsprechend auch vor dem erstmaligen Einsatz neuer Datenträger. Es ist empfehlenswert, nicht nur beim Empfang, sondern auch vor dem Versenden von Datenträgern diese auf Viren zu überprüfen. Vgl. dazu auch 10.4 Schutz vor Schadprogrammen und Schadfunktionen.
[eh SYS 2.2]

10.7.3 Datenträgeraustausch

ISO Bezug: 27002 10.7.3, 10.8.2, 10.8.3

Kennzeichnung der Datenträger beim Versand

Neben den in 10.7.2 Datenträgerverwaltung dargestellten Umsetzungshinweisen ist bei einer ausreichenden Kennzeichnung von auszutauschenden Datenträgern darauf zu achten, dass AbsenderIn und (alle) EmpfängerInnen unmittelbar zu identifizieren sind. Die Kennzeichnung muss den Inhalt des Datenträgers eindeutig für die EmpfängerInnen erkennbar machen. Es ist jedoch bei schützenswerten Informationen wichtig, dass diese Kennzeichnung für Unbefugte nicht interpretierbar ist.
Darüber hinaus sollten die Datenträger mit den für das Auslesen notwendigen Parametern gekennzeichnet werden. Das Versanddatum, eventuelle Versionsnummern oder Ordnungsmerkmale können gegebenenfalls nützlich sein.

Regelung des Datenträgeraustausches

Sollen zwischen zwei oder mehreren Kommunikationspartnern Datenträger ausgetauscht werden, so sind zum ordnungsgemäßen Austausch einige Punkte zu beachten.
Zum Beispiel:
  • Die Adressierung muss eindeutig erfolgen, um eine fehlerhafte Zustellung zu vermeiden. So sollte neben dem Namen der Empfängerin bzw. des Empfängers auch die Organisationseinheit und die genaue Bezeichnung der Behörde/des Unternehmens angegeben sein. Entsprechendes gilt für die Adresse der Absenderin/des Absenders.
  • Dem Datenträger sollte (optional) ein Datenträgerbegleitzettel beigelegt werden, der AbsenderIn, EmpfängerIn, Art des Datenträgers, Seriennummer, Identifikationsmerkmale für den Inhalt des Datenträgers, Datum des Versandes, ggf. Datum bis wann der Datenträger spätestens die EmpfängerInnen erreicht haben muss, sowie Parameter, die zum Lesen der Informationen benötigt werden (z. B. Bandgeschwindigkeit), enthält.
  • Bei regelmäßigem Austausch von Datenträgern zwischen den gleichen Partnern empfiehlt es sich, dafür stets die gleichen Datenträger zu verwenden, so dass bei einem evtl. Fehler bei der Wiederaufbereitung (vgl. 10.7.2 Datenträgerverwaltung) die potenziellen Auswirkungen möglichst gering gehalten werden.
  • Abhängig von den Regelungen der Informationssicherheitspolitik sind Datenträger, die Daten hoher Vertraulichkeitsstufen enthalten, beim Transport durch Dritte entweder zu verschlüsseln, oder in entsprechend versperrten Behältnissen zu transportieren
Nicht vermerkt werden sollte,
  • welches Passwort für die eventuell geschützten Informationen vergeben wurde,
  • welche Schlüssel ggf. für eine Verschlüsselung der Informationen verwendet wurde,
  • welchen Inhalt der Datenträger hat.
Der Versand des Datenträgers kann (optional) dokumentiert werden. Für jede stattgefundene Übermittlung ist dann in einem Protokoll festzuhalten, wer wann welche Informationen erhalten hat. Je nach Schutzbedarf beziehungsweise Wichtigkeit der übermittelten Informationen ist der Empfang zu quittieren und ein Quittungsvermerk dem erwähnten Protokoll beizufügen.
Es sind jeweils Verantwortliche für den Versand und für den Empfang zu benennen.
[eh SYS 2.3]

10.8 Informationsaustausch/E-Mail

Der Austausch von Informationen zwischen Organisationen und Organisationseinheit bedarf der Entwicklung geeigneter Richtlinien und der Anwendung sicherer Verfahren zum Schutz der ausgetauschten Informationen und der dabei verwendeten Datenträger. Austauschvereinbarungen mit den KommunikationspartnerInnen und die einschlägigen Gesetze sind dabei einzuhalten.

10.8.1 Richtlinien beim Datenaustausch mit Dritten

ISO Bezug: 27002 6.2.2, 6.2.3, 10.8.1, 10.8.2
Beim regelmäßigen Datenaustausch mit Dritten ist die Festlegung von Richtlinien bzw. der Abschluss von Vereinbarungen mit allen Beteiligten sinnvoll. Dabei spielt es keine Rolle, wie der Datenaustausch selbst erfolgt (Datenträgeraustausch, E-Mail etc.).
In einer derartigen Vereinbarung können Angaben zu folgenden Punkten enthalten sein:
  • Bestimmung der Verantwortlichen.
  • Benennung von AnsprechpartnerInnen (in technischen, organisatorischen und sicherheitstechnischen Belangen).
  • Existiert ein Non-Disclosure-Agreement (NDA)?
  • Festlegung der Datennutzung.
  • Welche Anwendungen und Datenformate sind zu verwenden?
  • Wie und wo erfolgt die Prüfung auf Virenfreiheit?
  • Wann dürfen Daten gelöscht werden?
  • Regelung des Schlüsselmanagements, falls erforderlich und
  • Einhaltung einschlägiger Gesetze (bspw. Datenschutzgesetz 2000 etc.).
Weitere Punkte, die in eine solche Vereinbarung aufgenommen werden sollten, finden sich in 10.7.2 Datenträgerverwaltung und 10.7.3 Datenträgeraustausch.
[eh SYS 1.9]

10.8.2 Festlegung einer Sicherheitspolitik für E-Mail-Nutzung

ISO Bezug: 27002 10.4, 10.8, 10.9, 11.4
Vor der Freigabe von E-Mail-Systemen sollte festgelegt werden, für welchen Einsatz E-Mail vorgesehen ist. Abhängig davon differieren auch die Ansprüche an Vertraulichkeit, Verfügbarkeit, Integrität und Verbindlichkeit der zu übertragenden Daten sowie des eingesetzten E-Mail-Programms. Es muss geklärt werden, ob über E-Mail ausschließlich unverbindliche oder informelle Informationen weitergegeben werden sollen oder ob einige oder sogar alle der bisher schriftlich bearbeiteten Geschäftsvorfälle nun per E-Mail durchgeführt werden sollen. Bei letzterem ist zu klären, wie Anmerkungen an Vorgängen wie Verfügungen, Abzeichnungen oder Schlusszeichnungen, die bisher handschriftlich angebracht wurden, elektronisch abgebildet werden sollen. Weiters ist festzulegen, ob und in welchem Rahmen eine private Nutzung von E-Mail erlaubt ist.
Die Organisation muss eine E-Mail-Sicherheitspolitik festlegen, in der folgende Punkte beschrieben sind:
  • Wer einen E-Mail-Anschluss erhält,
  • welche Regelungen von den E-Mail-AdministratorInnen und den E-Mail-BenutzerInnen zu beachten sind (vgl. 10.8.3 Regelung für den Einsatz von E-Mail und anderen Kommunikationsdiensten),
  • bis zu welchem Vertraulichkeits- bzw. Integritätsanspruch Informationen per E-Mail versandt werden dürfen,
  • ob und unter welchen Rahmenbedingungen eine private Nutzung von E-Mail erlaubt ist,
  • wie die BenutzerInnen geschult werden und
  • wie jederzeit technische Hilfestellung für die BenutzerInnen gewährleistet wird.
Durch organisatorische Regelungen oder durch die technische Umsetzung sind dabei insbesondere die folgenden Punkte zu gewährleisten:
  • Für Organisationen im öffentlichen Bereich sind die im Rahmen der Internet-Policy [IKT-IPOL] enthaltenen E-Mail-Richtlinien [IKT-MPOL] gemäß IKT-Board-Beschluss vom 17.09.2002 [IKTB-170902-1] umzusetzen.
  • Die E-Mail-Progamme der BenutzerInnen müssen durch die Systemadministration so vorkonfiguriert sein, dass ohne weiteres Zutun der BenutzerInnen maximale Sicherheit erreicht werden kann (siehe auch 10.8.7 Sichere Konfiguration der E-Mail-Clients).
  • Für E-Mail-Adressen sind Namenskonventionen festzulegen. Insbesondere ist darauf zu achten, dass Sonderzeichen (Umlaute, …) vermieden werden, da diese inhaltlich nicht einheitlich codiert sind. (vgl. E-Mail-Richtlinien [IKT-MPOL] im Rahmen der Internet-Policy [IKT-IPOL] gemäß [IKTB-170902-1] für Organisationen der öffentlichen Verwaltung zur Anwendung empfohlen)
  • Für E-Mail-Adressen in Behörden bzw. in Organisationen der öffentlichen Verwaltung ist die in der anzuwendenden E-Mail-Policy enthaltene Naming-Policy (gemäß [IKTB-170902-1] ) empfohlen.
  • Neben personenbezogenen E-Mail-Adressen können auch organisations- bzw. funktionsbezogene E-Mail-Adressen eingerichtet werden. Dies ist insbesondere bei zentralen Anlaufstellen wichtig.
  • Die Übermittlung von Daten darf erst nach erfolgreicher Identifizierung und Authentisierung des Senders beim Übertragungssystem möglich sein.
  • Die BenutzerInnen müssen vor erstmaliger Nutzung von E-Mail in die Handhabung der relevanten Applikationen eingewiesen werden. Die organisationsinternen Benutzerregelungen zur Dateiübermittlung müssen ihnen bekannt sein.
  • Zur Beschreibung des Absenders werden bei E-Mails so genannte Signatures (Absenderangaben) an das Ende der E-Mail angefügt. Der Inhalt einer Signature sollte dem eines Briefkopfs ähneln, also Name, Organisationsbezeichnung und Telefonnummer u. ä. enthalten. Eine Signature sollte nicht zu umfangreich sein, da dies nur unnötig Übertragungszeit und Speicherplatz kostet. Die Behörde bzw. das Unternehmen sollte einen Standard für die einheitliche Gestaltung von Signatures festlegen.
  • Von den eingesetzten Sicherheitsmechanismen hängt es ab, bis zu welchem Vertraulichkeit