IT-Sicherheit für Dummies 9783527833573

Table of contents :
Titelblatt
Impressum
Über die Autoren
Einleitung
Über dieses Buch
Törichte Annahmen über den Leser
Was Sie nicht lesen müssen
Wie dieses Buch aufgebaut ist
Symbole, die in diesem Buch verwendet werden
Konventionen in diesem Buch
Wie es weitergeht
Teil I: Informationssicherheit, IT-Sicherheit und Datenschutz
Kapitel 1: Irrtümer und häufige Fehler
Internet-Sicherheit
Mobile und Cloud-Sicherheit
Endgerätesicherheit
E-Mail-Sicherheit
Kapitel 2: Grundlagen der Informationssicherheit
Was ist Informationssicherheit?
Was ist IT-Sicherheit?
Was ist Cybersicherheit?
Klassische Schutzziele der Informationssicherheit
Authentizität
Verantwortlichkeit
Benutzbarkeit
Weitere Schutzziele
Kapitel 3: Bausteine der Informationssicherheit
Risikomanagement
Meldepflichten bei Vorfällen
Einhaltung von Sicherheitsstandards
Nachweis der Einhaltung durch Audits
Kapitel 4: Datenschutz und technisch-organisatorische Maßnahmen
Teil II: Rechtliche Anforderungen
Kapitel 5: Die DS-GVO und das BDSG
Die acht Gebote des Datenschutzes (BDSG a. F.)
Stand der Technik
Implementierungskosten
Gewährleistungsziele des Datenschutzes
Kapitel 6: Gesetze zur IT-Sicherheit
NIS-Richtlinie (EU)
Rechtsakt zur Cybersicherheit (EU)
eIDAS-Verordnung (EU)
Single-Digital-Gateway-(SDG-)Verordnung (EU)
BSI-Gesetz (D)
BSI-Kritisverordnung (D)
Geschäftsgeheimnisgesetz (D)
Onlinezugangsgesetz (D)
Sozialgesetzbuch V (D)
TKG, TMG und TTDSG (D)
Kapitel 7: ISO-Normen
ISO/IEC 270xx Informationssicherheit
ISO/IEC 27701 Datenschutz
Kapitel 8: BSI und Grundschutz
IT-Grundschutz
Standard-Datenschutzmodell und IT-Grundschutz
Technische Richtlinien des BSI
Kapitel 9: Weitere Standards
Prozessorientierte Standards
Vorgaben für die öffentliche Verwaltung
Technikorientierte Standards
ITIL
Kapitel 10: Technisch-organisatorische Maßnahmen (TOM)
Vertraulichkeit
Integrität
Verfügbarkeit und Belastbarkeit
Auftragskontrolle, Lieferantenbeziehungen
Überprüfung, Bewertung und Evaluierung der Wirksamkeit der TOM
Teil III: Organisation der Informationssicherheit
Kapitel 11: Organisation im Unternehmen
Verantwortung für die Informationssicherheit
Organisatorische Strukturen
Richtlinien und Regeln
Kapitel 12: Der Deming-Kreis (PDCA) und die ständige Verbesserung
Kapitel 13: Risikoanalyse und Kronjuwelen
Klassifizierung der Daten
Klassifizierung der Systeme
Bedrohungsanalyse
Metriken und Bewertung
Kapitel 14: Grundlegende Dokumentation
Asset- und Konfigurationsmanagement
Nutzermanagement und Zugriffskontrolle
Kapitel 15: Meldepflichten und Vorfallsmanagement
Datenschutzvorfälle
IT-Sicherheitsvorfälle
Angriffserkennung
Security Information and Event Management (SIEM)
Kapitel 16: Awareness und Beschäftigte
Teil IV: Bausteine der technischen IT-Sicherheit
Kapitel 17: Grundlagen der Verschlüsselung
Symmetrische Verschlüsselung
Betriebsarten der Blockverschlüsselung
Asymmetrische Verschlüsselung
Hybride Verschlüsselung
Hashfunktionen
Digitale und elektronische Signaturen
Elliptische-Kurven-Kryptografie
DLIES und ECIES
Vertrauensmodelle
Kryptograpische Forschung
Kapitel 18: Biometrie
Hautleisten
Venenmuster
Iris-Scan
Gesichtserkennung
Kapitel 19: Chipkarten und Secure Hardware Token
Einmalpasswort-Token
Teil V: Lösungen und Umsetzungen
Kapitel 20: Backup & Co.
Datensicherung
Aufbewahrungspflichten
Archivierung
Redundanz
Kapitel 21: Netzwerksicherheit
Grundlagen
Sicherheitserweiterungen von Netzwerkprotokollen
Netzwerkzugang
Netzwerksegmentierung
Denial-of-Service-Angriffe
Anonymisierung in Netzwerken
Funknetze
Das sichere Internet der Zukunft
Kapitel 22: Firewalls
Grundlagen von Firewalls
Packet Filter
Stateful Inspection Firewall
Network Address Translation (NAT)
Proxy-Server und Application Layer Firewall
NG Firewall und Deep Packet Inspection
Firewall in der Cloud
Kapitel 23: Verschlüsselung im Einsatz
Daten in Ruhe
Daten in Bewegung
Kapitel 24: Monitoring
Metriken der IT-Sicherheit
Angriffserkennungssysteme
Managed Security
Schadsoftware
Kapitel 25: Patch Management
Kapitel 26: Zugangssicherung und Authentisierung
Passwörter im Unternehmen
Zwei-Faktor-Authentisierung
Biometrie
Single Sign-on
Kapitel 27: Anwendungssicherheit
Chat
E-Mail
Videokonferenzen
Webanwendungen
Datenbanken
Cloud
Blockchain
Künstliche Intelligenz
Teil VI: Der Top-Ten-Teil
Kapitel 28: Zehn Maßnahmen für den technischen Basisschutz
Backup
Schutz vor Schadsoftware
Netzwerkschutz
Firewall
Patch-Management
Verschlüsselt speichern
Verschlüsselt kommunizieren
Passwort-Management
Biometrie und Zwei-Faktor-Authentifikation
Spam-Abwehr
Kapitel 29: Zehn Maßnahmen für den organisatorischen Überbau
Übernahme der Verantwortung
Leitlinie zur Informationssicherheit
Richtlinien zur Informationssicherheit
Definition und Besetzung der Rollen
Definition der fundamentalen Prozesse
Risikobetrachtung
Klassifizierung der Daten und Systeme
Awareness
Krisenmanagement
Regelmäßige Überprüfung
Literaturverzeichnis
Abbildungsverzeichnis
Stichwortverzeichnis
End User License Agreement

Citation preview

IT-Sicherheit für Dummies

Schummelseite DEUTSCHE GESETZE In der Informationssicherheit sind die nachfolgenden Gesetze von besonderer Relevanz: BSI-Gesetz Telekommunikationsgesetz (TKG) Bundesdatenschutzgesetz (BDSG) Telemediengesetz (TMG) Telekommunikation-Telemedien-Datenschutzgesetz (TTDSG) Geschäftsgeheimnisgesetz §§ 75b und 75c Sozialgesetzbuch V (SGB V)

WICHTIGE NORMEN Die folgenden Normen sind Orientierungen bei der Gestaltung der Informationssicherheit: ISO-27000-Reihe BSI-Standards BSI-Grundschutzkompendium VdS-10000-Reihe TISAX CISIS 12 DIN 66398 und 66399 Common Criteria PCI-DSS ITIL

EUROPÄISCHE REGELUNGEN Diese Verordnungen und Richtlinien spielen auf europäischer Ebene eine wichtige Rolle: Datenschutz-Grundverordnung Netzwerk- und Informationssicherheitsrichtlinie ePrivacy-Richtlinie Cybersecurity-Verordnung

SONSTIGE DOKUMENTE Diese Standards und Dokumente machen spezifische Vorgaben, sind aber trotzdem von allgemeinem Interesse: Federal Information Processing Standards (FIPS) Branchenspezifische Sicherheitsstandards (B3S) nach § 8a Abs. 2 BSI-Gesetz Leitlinie für die Informationssicherheit in der öffentlichen Verwaltung 2018 VDA-ISA-Katalog Informationssicherheitsmanagement – Grundsatzpapier der Rechnungshöfe des Bundes und der Länder Richtlinie nach § 75b SGB V über die Anforderungen zur Gewährleistung der IT-Sicherheit

MERKBLÄTTER FÜR BESCHÄFTIGTE Diese Merkblätter sollten den jeweiligen Beschäftigten übergeben werden: IT-Sicherheitsleitlinie des Unternehmens Passwortrichtlinie Nutzerordnung Merkblatt für Dienstreisen mit IT-Geräten Merkblatt zur Verschlüsselung von E-Mails Merkblatt zum Umgang mit Geschäftsgeheimnissen Datenschutzmerkblatt

Meldung von Sicherheitsvorfällen

ROLLEN IN DER IT-SICHERHEIT Die folgenden Rollen und Gremien sollten im Unternehmen beschrieben und besetzt werden: Informationssicherheitsbeauftragte/r Datenschutzbeauftragte/r Chief Information Officer Chief Digital Officer IT-Leiter Krisenstab

PC FÜR DAS HOME OFFICE Diese Maßnahmen sollten für einen PC im Home Office konfiguriert werden: VPN konfigurieren Token für 2FA beim VPN übergeben Festplattenverschlüsselung mit Pre-Boot Authentication einrichten automatische Aktualisierung des Virenscanners aktivieren Bildschirmschoner nach 5 Minuten konfigurieren

NOTEBOOK FÜR DIENSTREISE Diese Maßnahmen sollten für ein Notebook für Dienstreisen konfiguriert werden: VPN konfigurieren Token für 2FA beim VPN übergeben Festplattenverschlüsselung mit Pre-Boot Authentication einrichten automatische Aktualisierung des Virenscanners aktivieren Bildschirmschoner nach 5 Minuten konfigurieren

Sichtschutzfolie am Bildschirm anbringen Desktop-Firewall konfigurieren Kabel mit Schloss bereitstellen

IT-Sicherheit für Dummies Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2022 Wiley-VCH GmbH, Boschstraße 12, 69469 Weinheim, Germany All rights reserved including the right of reproduction in whole or in part in any form. This book published by arrangement with John Wiley and Sons, Inc. Alle Rechte vorbehalten inklusive des Rechtes auf Reproduktion im Ganzen oder in Teilen und in jeglicher Form. Dieses Buch wird mit Genehmigung von John Wiley and Sons, Inc. publiziert. Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission. Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern. Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung. Coverfoto: © Jonathan Schöps – stock.adobe.com

Korrektur: Matthias Delbrück, Dossenheim/Bergstraße Print ISBN: 978-3-527-71852-8

ePub ISBN: 978-3-527-83357-3

Über die Autoren Rainer W. Gerling beschäftigt sich seit über 40 Jahren beruflich mit Informationstechnologie und hat bereits 1986 einen der ersten Artikel in Deutschland über Computerviren veröffentlicht. Nach dem Studium der Physik an der Universität Dortmund von 1974 bis 1979 schloss er 1981 seine Promotion und 1986 seine Habilitation an der Universität Erlangen-Nürnberg ab. Von 1981 bis 1993 war er wissenschaftlicher Assistent und Privatdozent an der Universität Erlangen-Nürnberg. Nach seiner Tätigkeit als Wissenschaftler war Rainer W. Gerling von 1993 bis 2013 Datenschutzbeauftragter und von 2006 bis 2020 ITSicherheitsbeauftragter der Max-Planck-Gesellschaft. Seit 1994 ist er Lehrbeauftragter an der Hochschule München und wurde 2006 zum Honorarprofessor für IT-Sicherheit an der Hochschule München ernannt. Er ist seit 2012 stellvertretender Vorsitzender des Vorstands der Gesellschaft für Datenschutz und Datensicherheit e.V. (GDD). Als Mitbegründer und von 2008 bis 2020 als Vorsitzender des Arbeitskreises Informationssicherheit der deutschen Forschungseinrichtungen (AKIF) hat er maßgeblich die Behandlung des Themas Informationssicherheit an deutschen Hochschulen und Forschungseinrichtungen mitgeprägt. Darüber hinaus ist er seit 1996 freiberuflicher Trainer und Berater für Datenschutz und IT-Sicherheit. Sebastian R. Gerling beschäftigt sich seit über 20 Jahren beruflich mit Informationstechnologie und ganzheitlicher Strategieentwicklung im Umfeld von Hochschulen und Forschungseinrichtungen. Erfahrungen sammelte er dabei seit 2000 insbesondere in der Abteilung Informationsund Kommunikationstechnologie in der Generalverwaltung der MaxPlanck-Gesellschaft, den Max-Planck-Instituten für Informatik und Softwaretechnik, der Universität des Saarlandes, dem »CISPA – Center for IT-Security, Privacy and Accountability« und dann am »CISPA – Helmholtz-Zentrum für Informationssicherheit« sowie der Universität Hamburg.

Nach dem Bachelor-und Masterstudium der Informatik an der Universität des Saarlandes zwischen 2004 und 2009, schloss er im Rahmen eines Promotionsstipendiums der International Max Planck Research School for Computer Science 2014 die Promotion an der Universität des Saarlandes ab. Nach seiner Tätigkeit als wissenschaftlicher Mitarbeiter an der Universität des Saarlandes 2012 bis 2014 war er von 2012 bis 2017 administrativer Leiter des »CISPA – Center for IT-Security, Privacy and Accountability«. Von 2018 bis 2019 war er Leiter der Stabsstelle Wissenschaftsstrategie und Technologietransfer erst am »CISPA – Center for IT-Security, Privacy and Accountability« und dann am »CISPA – Helmholtz-Zentrum für Informationssicherheit«, im Anschluss war er von 2019 bis 2020 Leiter Wissenschaftsstrategie am »CISPA – Helmholtz-Zentrum für Informationssicherheit«. Seit 2021 ist Sebastian Gerling der Chief Digital Officer (CDO) der Universität Hamburg. Darüber hinaus ist er seit 2011 freiberuflicher Berater für IT-Sicherheit und Digitalisierung sowie freiberuflicher Referent für IT-Sicherheitsschulungen und Vorträge. Darüber hinaus ist er Autor von zahlreichen Fachartikeln im Bereich der IT-Sicherheit.

Inhaltsverzeichnis Cover Titelblatt Impressum Über die Autoren Einleitung Über dieses Buch Törichte Annahmen über den Leser Was Sie nicht lesen müssen Wie dieses Buch aufgebaut ist Symbole, die in diesem Buch verwendet werden Konventionen in diesem Buch Wie es weitergeht

Teil I: Informationssicherheit, IT-Sicherheit und Datenschutz Kapitel 1: Irrtümer und häufige Fehler Internet-Sicherheit Mobile und Cloud-Sicherheit Endgerätesicherheit E-Mail-Sicherheit

Kapitel 2: Grundlagen der Informationssicherheit Was ist Informationssicherheit? Was ist IT-Sicherheit? Was ist Cybersicherheit? Klassische Schutzziele der Informationssicherheit Authentizität Verantwortlichkeit Benutzbarkeit

Weitere Schutzziele

Kapitel 3: Bausteine der Informationssicherheit Risikomanagement Meldepflichten bei Vorfällen Einhaltung von Sicherheitsstandards Nachweis der Einhaltung durch Audits

Kapitel 4: Datenschutz und technischorganisatorische Maßnahmen Teil II: Rechtliche Anforderungen Kapitel 5: Die DS-GVO und das BDSG Die acht Gebote des Datenschutzes (BDSG a. F.) Stand der Technik Implementierungskosten Gewährleistungsziele des Datenschutzes

Kapitel 6: Gesetze zur IT-Sicherheit NIS-Richtlinie (EU) Rechtsakt zur Cybersicherheit (EU) eIDAS-Verordnung (EU) Single-Digital-Gateway-(SDG-)Verordnung (EU) BSI-Gesetz (D) BSI-Kritisverordnung (D) Geschäftsgeheimnisgesetz (D) Onlinezugangsgesetz (D) Sozialgesetzbuch V (D) TKG, TMG und TTDSG (D)

Kapitel 7: ISO-Normen ISO/IEC 270xx Informationssicherheit ISO/IEC 27701 Datenschutz

Kapitel 8: BSI und Grundschutz IT-Grundschutz Standard-Datenschutzmodell und IT-Grundschutz Technische Richtlinien des BSI

Kapitel 9: Weitere Standards Prozessorientierte Standards Vorgaben für die öffentliche Verwaltung Technikorientierte Standards ITIL

Kapitel 10: Technisch-organisatorische Maßnahmen (TOM) Vertraulichkeit Integrität Verfügbarkeit und Belastbarkeit Auftragskontrolle, Lieferantenbeziehungen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der TOM

Teil III: Organisation der Informationssicherheit Kapitel 11: Organisation im Unternehmen Verantwortung für die Informationssicherheit Organisatorische Strukturen Richtlinien und Regeln

Kapitel 12: Der Deming-Kreis (PDCA) und die ständige Verbesserung Kapitel 13: Risikoanalyse und Kronjuwelen Klassifizierung der Daten Klassifizierung der Systeme Bedrohungsanalyse Metriken und Bewertung

Kapitel 14: Grundlegende Dokumentation Asset- und Konfigurationsmanagement Nutzermanagement und Zugriffskontrolle

Kapitel 15: Meldepflichten und Vorfallsmanagement Datenschutzvorfälle IT-Sicherheitsvorfälle Angriffserkennung

Security Information and Event Management (SIEM)

Kapitel 16: Awareness und Beschäftigte Teil IV: Bausteine der technischen IT-Sicherheit Kapitel 17: Grundlagen der Verschlüsselung Symmetrische Verschlüsselung Betriebsarten der Blockverschlüsselung Asymmetrische Verschlüsselung Hybride Verschlüsselung Hashfunktionen Digitale und elektronische Signaturen Elliptische-Kurven-Kryptografie DLIES und ECIES Vertrauensmodelle Kryptograpische Forschung

Kapitel 18: Biometrie Hautleisten Venenmuster Iris-Scan Gesichtserkennung

Kapitel 19: Chipkarten und Secure Hardware Token Einmalpasswort-Token

Teil V: Lösungen und Umsetzungen Kapitel 20: Backup & Co. Datensicherung Aufbewahrungspflichten Archivierung Redundanz

Kapitel 21: Netzwerksicherheit Grundlagen Sicherheitserweiterungen von Netzwerkprotokollen Netzwerkzugang

Netzwerksegmentierung Denial-of-Service-Angriffe Anonymisierung in Netzwerken Funknetze Das sichere Internet der Zukunft

Kapitel 22: Firewalls Grundlagen von Firewalls Packet Filter Stateful Inspection Firewall Network Address Translation (NAT) Proxy-Server und Application Layer Firewall NG Firewall und Deep Packet Inspection Firewall in der Cloud

Kapitel 23: Verschlüsselung im Einsatz Daten in Ruhe Daten in Bewegung

Kapitel 24: Monitoring Metriken der IT-Sicherheit Angriffserkennungssysteme Managed Security Schadsoftware

Kapitel 25: Patch Management Kapitel 26: Zugangssicherung und Authentisierung Passwörter im Unternehmen Zwei-Faktor-Authentisierung Biometrie Single Sign-on

Kapitel 27: Anwendungssicherheit Chat E-Mail Videokonferenzen Webanwendungen

Datenbanken Cloud Blockchain Künstliche Intelligenz

Teil VI: Der Top-Ten-Teil Kapitel 28: Zehn Maßnahmen für den technischen Basisschutz Backup Schutz vor Schadsoftware Netzwerkschutz Firewall Patch-Management Verschlüsselt speichern Verschlüsselt kommunizieren Passwort-Management Biometrie und Zwei-Faktor-Authentifikation Spam-Abwehr

Kapitel 29: Zehn Maßnahmen für den organisatorischen Überbau Übernahme der Verantwortung Leitlinie zur Informationssicherheit Richtlinien zur Informationssicherheit Definition und Besetzung der Rollen Definition der fundamentalen Prozesse Risikobetrachtung Klassifizierung der Daten und Systeme Awareness Krisenmanagement Regelmäßige Überprüfung

Literaturverzeichnis Abbildungsverzeichnis Stichwortverzeichnis

End User License Agreement

Tabellenverzeichnis Kapitel 3 Tabelle 3.1: Die expliziten gesetzlichen Vorgaben für Unternehmen bezüglich der M...

Kapitel 6 Tabelle 6.1: Die Regelungen der §§ 165–169 TKG haben vier unterschiedliche Gruppe...

Kapitel 7 Tabelle 7.1: Änderungen und Ergänzungen der Abschnitte der ISO/IEC 27001/27002 du...

Kapitel 8 Tabelle 8.1: Die 47 elementaren Gefährdungen der IT-Sicherheit (ITGrundschutzkom... Tabelle 8.2: Kreuztabelle für den Baustein »SYS.2.3: Clients unter Linux und Unix... Tabelle 8.3: Zusammenfassung der wesentlichen empfohlenen Verfahren und Mindestsc...

Kapitel 14 Tabelle 14.1: Die Unterschiede zwischen einem Inventarverzeichnis und einer CMDB...

Kapitel 16 Tabelle 16.1: Die drei Phasen einer Awareness-Kampagne. (nach SP 80016)

Kapitel 17 Tabelle 17.1: Die sechs Prinzipien (Anforderungen) des Auguste Kerckhoffs von Nie... Tabelle 17.2: Bekannte Hashfunktionen mit Blocklänge, der Länge des Hashwerts und... Tabelle 17.3: Vergleich der Schlüssellängen für verschiedene Verschlüsselungsverf... Tabelle 17.4: Die wesentlichen Datenfelder der Datenstruktur zur Speicherung des ...

Kapitel 21 Tabelle 21.1: Übersicht über das OSI-Referenzmodell im Vergleich zum TCP/IP-Model...

Illustrationsverzeichnis Kapitel 2 Abbildung 2.1: Anzahl der aktuellen (2012, 2016 und 2019) und veralteten (2003, 2...

Kapitel 3 Abbildung 3.1: Das Risiko wird häufig als das Produkt aus Schadenshöhe und Eintri... Abbildung 3.2: Durch die Risikostrategien Vermeiden, Reduzieren und Delegieren ka...

Kapitel 5 Abbildung 5.1: Die beispielhafte Auswertung der Fragebögen zur Bewertung des Stan...

Kapitel 6 Abbildung 6.1: Die gesetzlichen Vorgaben zur IT-Sicherheit in den unterschiedlich... Abbildung 6.2: Das fünfstufige Reifegradmodell zur OZG-Umsetzung der Verwaltungsv... Abbildung 6.3: Die Priorisierung P1 bis P4 sowie die Zahl der Maßnahmen für klein... Abbildung 6.4: Je nach Größe einer ärztlichen beziehungsweise zahnärztlichen Prax...

Kapitel 7 Abbildung 7.1: Übersicht über die ISO-Normen der ISO/IEC 27000er Standard-Familie...

Kapitel 9 Abbildung 9.1: Grobe qualitative Darstellung des Aufwands und des typisch zu erre... Abbildung 9.2: Tabellarische Übersicht über das Ergebnis einer Selbsteinschätzung...

Kapitel 10

Abbildung 10.1: Beispiele für Identifikatoren, Teil-Identifikatore... Abbildung 10.2: Office-Dokumente können in den Desktopversionen von Microsoft Off... Abbildung 10.3: Die Konfiguration der Verschlüsselung eines Webser... Abbildung 10.4: Der Greenbone-Schwachstellenscanner bewertet die g...

Kapitel 11 Abbildung 11.1: Die Regelungspyramide, die die zeitlichen Änderungsskalen und die...

Kapitel 12 Abbildung 12.1: Der Deming- oder PDCA-Zyklus als vierstufiger Prozess der ständig...

Kapitel 13 Abbildung 13.1: Auszug aus der Log-Datei auth.log eines Servers. Hier sind die un...

Kapitel 15 Abbildung 15.1: Der Anfang eines TLP:WHITE-Dokuments des BSI mit einer Warnung vo...

Kapitel 17 Abbildung 17.1: Kommunikationsmodell eines symmetrischen Verschlüsselungssystem. Abbildung 17.2: Symmetrische Verschlüsselung Abbildung 17.3: Die Verschlüsselung zweier Blöcke im ECB- (links) und CBC-Modus (... Abbildung 17.4: Das Logo der Buchreihe (oberes Bild) wurde mit AES... Abbildung 17.5: Das Verschlüsselungsschema ist beim CFB-, OFB- und CTR-Modus glei... Abbildung 17.6: Bei einem Man-in-the-Middle-(MITM-)Angriff klinkt sich Mallory ak... Abbildung 17.7: Die Verschlüsselung erfolgt mit dem öffentlichen Schlüssel des Em... Abbildung 17.8: Zur Erzeugung von Schlüsselpaaren werden im Wesentliche... Abbildung 17.9: Ein Briefkasten ist eine Analogie zur asymmetrischen Verschlüssel... Abbildung 17.10: Bei der Hybridverschlüsselung wird der Schlüssel mittels asymmet...

Abbildung 17.11: Bei der Merkle-Damgård-Konstruktion besteht die Hashfunktion aus... Abbildung 17.12: Wir können uns die Bildung eines Hashwerts wie die Faltung einer... Abbildung 17.13: Beispiele für die verschiedenen Padding-Verfahren. Der... Abbildung 17.14: Ein Schaukasten im Unternehmen hat eine Funktion, die der digita... Abbildung 17.15: Schematische Darstellung einer digitalen Signatur und ihrer Über... Abbildung 17.16: Darstellung der Addition zweier Punkt auf einer elliptischen Kur... Abbildung 17.17: Beim ersten Verbindungsaufbau zu einem SSH-Server muss der Schlü... Abbildung 17.18: Anforderungen an die Größe von Quantencomputern. Der graue Berei...

Kapitel 18 Abbildung 18.1: Die Abhängigkeit der False Acceptance Rate (FAR) und der False Re...

Kapitel 19 Abbildung 19.1: Die Chipkartenformate mit Kontaktfeld (von links): ID-1, ID000, ... Abbildung 19.2: Schematischer Aufbau einer Speicherchipkarte (a) und einer Prozes... Abbildung 19.3: Aus einer Token-abhängigen individuellen Zufallszahl, die bei der... Abbildung 19.4: Aus der Domain des Login-Servers, einer Zufallszahl (Nonce) und d...

Kapitel 20 Abbildung 20.1: Die Darstellung der Datensicherungsarten. a) Vollsicherung; b) Di... Abbildung 20.2: Schematische Darstellung eines RAID-1- und eines RAID5-System mi...

Kapitel 21 Abbildung 21.1: Der Ablauf der DNS-Auflösung mit normalen DNS (a) und DoT/DoH (b)... Abbildung 21.2: Darstellung des Zusammenspiels von Supplicant, Authenticator und ...

Abbildung 21.3: Segmentierung eines Netzwerks. Abbildung 21.4: VLAN-Beispiele.

Kapitel 22 Abbildung 22.1: Beispiel für eine Firewall mit vier Sicherheitszonen: Extern, Int... Abbildung 22.2: Beispielhafte Übersetzung der IP-Adressen mit NAT ...

Kapitel 23 Abbildung 23.1: Es gibt vier Konzepte, wie Dateien auf einem Datenträger verschlü... Abbildung 23.2: Dialog zum Einrichten der Datenträgerverschlüsselung Bitlocker un... Abbildung 23.3: Schmatische Darstellung der Hardware-Verschlüsselung oder Device ... Abbildung 23.4: Die unterschiedlichen verschlüsselten Datenströme bei einer Ende-... Abbildung 23.5: Die Verbindung von einem Client zu einem Server (Ziel) über eine ... Abbildung 23.6: Der gleichzeitige Aufruf einer Webseite zum Anzeigen der eigenen ... Abbildung 23.7: OpenVPN läuft im User Space und transportiert Daten zwischen eine...

Kapitel 24 Abbildung 24.1: Ein Spinnennetzdiagramm erlaubt den quantitativen Vergleich mehre... Abbildung 24.2: Die fehlgeschlagenen SSH-Anmeldeversuche mit der Nutzerin pi auf ...

Kapitel 25 Abbildung 25.1: Die monatliche Zahl der Schwachstellenwarnungen und Updates der W...

Kapitel 27 Abbildung 27.1: Ein Verschlüsselungs-Proxy übernimmt die Ver- und Entschlüsselung... Abbildung 27.2: Die Kommunikationsflüsse bei einer Videokonferenz ... Abbildung 27.3: Die Kommunikationsflüsse bei einer Videokonferenz ... Abbildung 27.4: Die Kommunikationsflüsse bei einer Videokonferenz ... Abbildung 27.5: Die verkette Listenstruktur einer Blockchain.

Abbildung 27.6: Die Verwendung von Algorithmen und Daten beim Maschinellen Lernen...

Einleitung Informationssicherheit stellt eine der elementaren Grundlagen für eine gesetzeskonforme und verlässliche Nutzung von Informationstechnologien und der digitalen Transformation dar. Wer sich heute für Informationssicherheit interessiert, muss sich sowohl mit den organisatorischen als auch mit den technischen Grundlagen der Informationssicherheit befassen. Moderne Vorlesungen zur Informationssicherheit decken nicht nur den technischen Teil ab, sondern widmen sich genauso umfangreich den organisatorischen Strukturen. Leider fehlt es in der Informatikerausbildung aber häufig noch an der fachbereichsübergreifenden Darstellung und die IT-Sicherheit wird rein technisch gelehrt. Das ist sicherlich mit ein Grund dafür, dass die Informationssicherheit noch lange nicht flächendeckend auf dem Niveau ist, auf dem sie sein sollte. Auch die regulatorischen Vorgaben durch den Gesetzgeber werden mehr. Die DS-GVO und die IT-Sicherheitsgesetzgebung fordern heute deutlich mehr IT-Sicherheit und technisch-organisatorische Maßnahmen als noch vor ein paar Jahren. Auch der IT-Planungsrat kümmert sich um einheitliche Informationssicherheitsvorgaben für Behörden. Tangiert wird das außerdem auch von den Rechnungshöfen des Bundes und der Länder, die im Rahmen ihrer Wirtschaftlichkeitsprüfungen auch die Informationssicherheit prüfen. Das weltumspannende Internet sollten wir sicher nutzen können, deshalb benötigen wir eine einheitliche Regulierung der Informationssicherheit. Die Gültigkeit nationalen Rechts endet an der Landesgrenze. Internationale Regelungen, wie sie die EU schafft, vereinheitlichen die Vorgaben. Hier bedarf es noch weiterer internationaler Anstrengungen.

Über dieses Buch Wir stellen im Buch die organisatorischen und die technischen Grundlagen der Informationssicherheit gemeinsam dar. Das Buch gibt

eine umfassende Orientierung zur Einordnung der Informationssicherheit in das regulatorische Umfeld (Deutschland, EU), die erforderlichen organisatorischen Strukturen im Unternehmen beziehungsweise in der Behörde und die technischen Grundlagen der Informationssicherheit.

Törichte Annahmen über den Leser Sie wollen Informationssicherheit lernen. Das ist gut und Sie sind hier richtig. Sie haben kein Vorwissen. Kein Problem! Die Inhalte werden so präsentiert, dass sie im Wesentlichen ohne Vorwissen verständlich sind. Sie studieren Informatik, Mathematik oder Jura. Sie denken darüber nach, eine Berufslaufbahn in der Informationssicherheit einzuschlagen. Dann sollten Sie neben den technischen Grundlagen der Informationssicherheit (eher Informatik-Themen) auch die rechtlichen und organisatorischen Grundlagen (eher juristische, Wirtschafts- und Wirtschaftsinformatik-Themen) beherrschen. Das Buch führt das erforderliche Wissen aus den Schnittstellen zu den relevanten Fachgebieten (Informatik, Rechtswissenschaften, Wirtschaftswissenschaften und Wirtschaftsinformatik) zusammen und stellt es einheitlich dar.

Was Sie nicht lesen müssen Wenn Sie beginnen, ein Kapitel zu lesen, und Sie den Inhalt schon kennen, überspringen Sie das Kapitel. Bei einem Querschnittthema mit juristischen, technischen und betrieblichen Inhalten ist es unvermeidbar, dass Sie, je nach Ausbildung, in dem einen oder anderen dieser Themen schon Vorkenntnisse haben. Die Juristen unter Ihnen kennen sich mit den Gesetzen aus und die Mathematiker oder Informatiker unter Ihnen wissen vermutlich schon einiges über Verschlüsselung. Beispiele und Anekdoten können Sie überspringen, wenn Sie den Sachverhalt auch so verstehen oder der Hintergrund für Sie nicht so

wichtig ist.

Wie dieses Buch aufgebaut ist Wie jedes Buch der »… für Dummies«-Reihe ist auch dieses Buch in mehrere große Teile gegliedert. Die Einführung der grundlegenden Begriffe und Anforderungen geschieht in Teil I. In Teil II lernen Sie die rechtlichen und regulatorischen Anforderungen kennen. Die Organisation im Unternehmen ist der Schwerpunkt von Teil III. Teil IV soll Ihnen die technischen Grundlagen und Bausteine vermitteln. Aus den Bausteinen bauen wir dann im Teil V das IT-Sicherheitshaus auf.

Teil I: Informationssicherheit, IT-Sicherheit und Datenschutz IT-Sicherheit und Informationssicherheit ist das nicht dasselbe? Und was hat Datenschutz damit zu tun? Sie lernen die Definitionen und Unterschiede der Begriffe der Informationssicherheit, nämlich die klassischen Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit kennen. Wenn Sie sich mit der Umsetzung von Informationssicherheit beschäftigen wollen, müssen Sie zuerst lernen, was Informationssicherheit ist. Erstaunlicherweise finden Sie diese Grundbegriffe nicht nur in Lehrbüchern und Standarddokumenten zur Informationssicherheit, sondern zunehmend auch in Gesetzen. Die immer weiter gehende Digitalisierung führt auch zu vermehrten Anforderungen an die Informationssicherheit. Von der Praxis Ihres Hausarztes bis zur Steuerung der Energieversorgung Ihrer Wohnung: überall werden Computer eingesetzt. Und wenn die Computer gestört sind, fällt die Dienstleistung oder Versorgungsleistung aus. Im Juli 2021 wurde in Deutschland erstmalig der Cyberkatastrophenfall ausgelöst, und zwar im Landkreis Anhalt-Bitterfeld. Störungen der Informationssicherheit können tatsächlich katastrophale Auswirkungen haben. Deshalb muss Informationssicherheit nicht nur Schutz vor Angriffen, sondern auch Vorsorge vor Katastrophen und Unfällen sein.

Die vier Begriffe Risikomanagement, Meldepflichten, Sicherheitsstandards und Audits ziehen sich wie ein roter Faden durch alle Regelungen zur IT-Sicherheit. Sie werden lernen, was es damit auf sich hat. Und mit den technisch-organisatorischen Maßnahmen, kurz TOM, kommt dann auch der Datenschutz ins Spiel. Um den technischen Schutz der personenbezogenen Daten zu gewährleisten, sind TOMs erforderlich. Datenschutz braucht unterstützend die IT-Sicherheit, auch wenn die Datenschutzziele nicht allein durch IT-Sicherheitsmaßnahmen erreicht werden können.

Teil II: Rechtliche Anforderungen Da Computer und Digitalisierung immer weiter in unser Leben vordringen und deshalb die Informationssicherheit immer wichtiger wird, regelt der Gesetzgeber in immer mehr Gesetzen und Verordnungen die Anforderungen an die Informationssicherheit. Viele Unternehmen müssen sich intensiv um Informationssicherheit kümmern. Dabei spielt es keine Rolle, ob ihnen das wichtig ist oder nicht: Es ist ihnen gesetzlich vorgeschrieben. Sie erfahren, welche europäischen Vorschriften (Netzwerk- und Informationssicherheits-Richtlinie, Rechtsakt zur Cybersicherheit, Datenschutz-Grundverordnung) und welche deutschen Vorschriften (BSI-Gesetz, Geschäftsgeheimnisgesetz, Telekommunikationsgesetz und etliche andere) den Unternehmen Vorgaben zur IT-Sicherheit machen. Neben den rechtlichen Vorgaben lernen Sie auch die Standards und Normen zur Informationssicherheit (ISO-Normen, BSI-Grundschutz und andere) kennen. Diese Standards sind wichtig, da sich die rechtlichen Vorgaben teilweise für die Umsetzung auf diese Standards beziehen. Gesetze haben eine deutliche längere Lebensdauer als IT-Systeme. Deshalb ist es für den Gesetzgeber schwer, IT in Gesetzen detailliert zu regeln. Der Bezug auf Standards, die sich schneller aktualisieren lassen, ist der Ausweg aus diesem Dilemma. Und nochmal Datenschutz: Wie strukturieren Sie im Unternehmen die TOMs? Wir schauen uns gemeinsam an, was bei den TOMs wichtig ist.

Teil III: Organisation der Informationssicherheit Ein Unternehmen muss seine Prozesse durch interne Vorgaben und Regeln gestalten. Teilweise sind das relativ banale Dinge, wie eine Nutzerordnung oder eine Passwortrichtlinie. Welche Regeln und vor allem welche Inhalte der Regeln wollen Sie als zukünftige Expertin oder zukünftiger Experte für Informationssicherheit Ihrem Unternehmen empfehlen? Sie lernen in diesem Teil, was Sie regeln sollen und wie Sie es regeln sollen. Wer hat im Unternehmen welche Aufgaben in der Informationssicherheit? Vom Chef über den Informationssicherheitsbeauftragten und den IT-Leiter bis zur Nutzerin, jede und jeder trägt seinen Teil zur Bewältigung der Aufgabe »Informationssicherheit« bei. Wie machen Sie eine Risikoanalyse? Was sind die Kronjuwelen im Unternehmen? Was dürfen die Nutzerinnen? Wie gehen Sie mit Sicherheitsvorfällen um? Mit all diese Fragen beschäftigen wir uns in diesem dritten Teil. Eine der wichtigsten organisatorischen Fragen beschäftigt sich mit der alten Frage: »Wie sag ich es meinen Mitarbeitern?« Awareness und Schulung sind wichtige Maßnahmen, die Sie kennenlernen werden.

Teil IV: Bausteine der technischen IT-Sicherheit Im vierten Teil, zugegeben ein ziemlich anspruchsvoller Abschnitt, spielen die technischen Grundlagen der IT-Sicherheit die Hauptrolle. Einen breiten Raum nehmen die Grundlagen der Verschlüsselung ein. Ganz ohne Mathematik geht es nicht, aber die Anschaulichkeit steht im Vordergrund. Ein weiteres wichtiges Thema ist die Biometrie. Eine Anmeldung am Smartphone mit Fingerabdruck oder Gesichtserkennung haben Sie bestimmt schon gemacht. Türöffnung im Sicherheitsbereich mit IrisScan ist in manchen Rechenzentren Pflicht. Sie lernen die Grundlagen der Biometrie kennen und wir schauen uns auch die damit verbundenen Risiken an.

Außerdem beschäftigen wir uns noch mit Chipkarten und Sicherheitstoken. Vom neuen Personalausweis über die Girocard bis zur SIM-Karte im Smartphone haben Sie sicher schon persönliche Erfahrungen gemacht im Umgang mit den kleinen Geräten. Wir schauen uns an, wie sie funktionieren und was sie können.

Teil V: Lösungen und Umsetzungen Aufbauend auf den Bausteinen, die Sie im vierten Teil kennengelernt haben, schauen wir uns dann die Lösungen zur IT-Sicherheit an. Backup, Verschlüsselung von Daten auf Datenträgern und bei der Übertragung, Netzwerksicherheit, Firewalls und Zugangssicherung sind Lösungen, die Sie kennenlernen werden. Wie überwachen und messen Sie die IT-Sicherheit im Unternehmen? Was sind geeignete Metriken, um die Qualität Ihrer IT-Sicherheit zu messen? Was ist ein Patch-Management? Sie wollten sicher immer schon mal wissen, wie eine Blockchain funktioniert und was es mit Künstlicher Intelligenz auf sich hat. Auch das werden Sie in diesem Teil lernen. Alle diese Lösungen dienen zur technischen Unterstützung der organisatorischen Prozesse im Unternehmen.

Teil VI: Der Top-Ten-Teil Im Top-Ten-Teil geht es nochmal um die wichtigsten Begriffe und die wichtigsten organisatorischen und technischen Maßnahmen. Quasi das Take-away in aller Kürze.

Symbole, die in diesem Buch verwendet werden Neben dem Fernglas finden Sie Beispiele, die Ihnen helfen, das Gelernte an einer konkreten Situation besser zu verstehen.

Neben der Lupe finden Sie Definitionen von Begriffen. Häufig stammen diese aus offiziellen Normen, Standards oder Gesetzen. Wenn Sie erst in das Thema einsteigen und noch nicht so viele Erfahrungen haben, hilft der eine oder andere Tipp. Bevor Sie einen typischen Fehler machen oder einem gängigen Irrtum unterliegen, lesen Sie die mit diesem Symbol gekennzeichneten Warnungen. Manchmal erzählen wir Ihnen eine Anekdote. Im Gegensatz zu einem Beispiel ist es nicht das Hauptziel einer Anekdote, Sie beim Verstehen eines Sachverhalts zu unterstützen, sondern sie gibt eine Erklärung zum Hintergrund oder zur Entstehung eines Aspekts oder auch spannende Einblicke in das reale Leben der IT-Sicherheit.

Konventionen in diesem Buch In diesem Buch verwenden wir aus Gründen der Lesbarkeit für Rollen sowohl die männliche als auch die weibliche Form. Dazu haben wir für alle Rollen jeweils ein Geschlecht definiert und verwenden dies dann durchgehend: der Informationssicherheitsbeauftragte, die Datenschutzbeauftragte, der Angreifer, die Nutzerin. Des Weiteren verwenden wir den Begriff »Unternehmen« und meinen damit jeweils sowohl Organisationen beliebiger Rechtsform wie Unternehmen jeder Art, aber auch Behörden, Universitäten, Forschungseinrichtungen, Vereine und so weiter. Wir verwenden in diesem Buch die folgenden Begriffe und orientieren uns dabei an den Formulierungen des BSI-Grundschutz-Kompendiums: »MUSS« oder »DARF NUR«: Diese beiden Formulierungen werden verwendet, wenn etwas unbedingt getan werden muss, da es

vorgeschrieben ist. In diesem Fall gibt es eine rechtliche Vorschrift (zum Beispiel die DS-GVO oder das BSI-Gesetz), die die Maßnahme verlangt. »DARF NICHT« oder »DARF KEIN«: Diese beiden Formulierungen beschreiben das Gegenteil, dass etwas auf keinen Fall getan werden darf, da es zum Beispiel gesetzlich oder regulatorisch (zum Beispiel im Strafgesetzbuch) untersagt ist. »SOLLTE«: Diese Formulierung besagt, dass es geboten ist, etwas zu tun. Es kann jedoch gute Gründe geben, es trotzdem nicht zu machen. Diese Abweichung muss gut überlegt und nachvollziehbar begründet werden. Außerdem ist die Ausnahme ausführlich zu dokumentieren. »SOLLTE NICHT« oder »SOLLTE KEIN«: Diese Formulierung besagt, dass nicht geboten ist, etwas zu tun. Es kann jedoch gute Gründe geben, es trotzdem zu machen. Diese Abweichung muss gut überlegt und nachvollziehbar begründet werden. Außerdem ist die Ausnahme ausführlich zu dokumentieren. »KANN«: Diese Formulierung besagt, dass etwas getan werden kann oder auch nicht. Weder für die eine noch die andere Option ist eine explizite Begründung erforderlich.

Wie es weitergeht Wir hoffen, Sie sind jetzt richtig neugierig geworden und fangen gleich an zu lesen! Wenn Sie Informationssicherheit dauerhaft betreiben wollen, dann dürfen Sie nach dem Durcharbeiten dieses Buches nicht aufhören. Die technischen Herausforderungen ändern sich ständig. Ständig werden neue Angriffstechniken bekannt, auf die reagiert werden muss. Die Regularien ändern sich und erfordern eine Anpassung der Organisation im Unternehmen. Standards und Normen werden an die sich weiter entwickelnde Technik angepasst. Es gibt kaum ein anderes Gebiet, wo es so wichtig ist, immer am Ball zu bleiben und sich ständig weiterzubilden.

Wer sich mit Informationssicherheit beschäftigt, muss sich auf die ständigen Änderungen einlassen. »Das haben wir schon immer so gemacht!« ist ein Argument, das Sie vergessen müssen. Aber Informationssicherheit macht auch Spaß: Es ist spannend, an vorderster Front dabei zu sein und die Entwicklung im Unternehmen mitzugestalten. Die Sorge, dass das Thema in ein paar Jahren vom Tisch ist, müssen Sie nicht haben. Informationssicherheit ist eines der großen Themen unserer Zeit, das immer wichtiger wird. Damit wird Ihnen nie langweilig! Dieses Buch berücksichtigt bei Darstellungen der Rechtslage in Deutschland und in der Europäischen Union den Stand der Gesetzgebung bis Herbst 2021. Gesetze (wie zum Beispiel TKG, TTDSG), die bis Mitte 2021 beschlossen wurden, aber erst am 1. Dezember 2021 in Kraft getreten sind, sind in der Fassung vom 1. Dezember 2021 berücksichtigt. Aktualisierte Links, weitere Informationen und Errata finden Sie auf der Website https://www.it-sfd.de.

Teil I

Informationssicherheit, ITSicherheit und Datenschutz

IN DIESEM TEIL … Sie lernen die grundlegenden Definitionen und Schutzziele der Informationssicherheit wie Verfügbarkeit, Integrität und Vertraulichkeit kennen. Außerdem beschäftigen Sie sich mit den Bausteinen des Informationssicherheitsmanagements. Risikomanagement, Meldepflichten, Sicherheitsstandards und Audits sind die vier grundlegenden Elemente, die die Organisation der Informationssicherheit und die daraus folgenden technischen Maßnahmen treiben. Auch der Datenschutz in Form der europäischen Datenschutzgrundverordnung (DS-GVO) ist durch seine Forderung nach »geeigneten technischen und organisatorischen Maßnahmen« zum Schutz der personenbezogenen Daten eng mit der Informationssicherheit verwoben.

Kapitel 1

Irrtümer und häufige Fehler IN DIESEM KAPITEL Typische Fehleinschätzungen der Nutzerinnen Fehler der Administratoren Fake News der IT-Sicherheit

Um die IT-Sicherheit ranken sich viele Mythen. Die Nutzerinnen der IT haben teilweise seltsame Vorstellungen, wie Informationstechnik (IT) und IT-Sicherheit funktioniert. Es gibt Nutzerinnen, die unterschätzen das Risiko. Äußerungen im Bekannten- und Kollegenkreis, die Sie alle schon gehört haben, sind »Ich kann mit meinem Windows 7 ins Internet gehen, wenn ich immer nur kurz im Internet bin. Bei weniger als zehn Minuten kann nichts passieren.« »Solange ich nicht auf zwielichtigen Seiten surfe, kann ich mir keinen Virus einfangen.« »Eine E-Mail, in der sich ein Virus verbirgt, erkenne ich sofort.« »Ein Passwort zum Anmelden am Rechner benötige ich nur im Büro.« »Ich habe nichts zu verbergen.« »Wer interessiert sich schon für meine Daten?« Andere Nutzerinnen überschätzen das Risiko. »Ich mache kein Online-Banking. Das ist viel zu gefährlich.« »Ich will kein Smartphone, da werde ich nur ausspioniert.« »Die Geheimdienste können mich dann komplett verfolgen.« Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt auf der Webseite für Verbraucherinnen und Verbraucher (https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-undVerbraucher/Informationen-und-Empfehlungen/Cyber-

Sicherheitsempfehlungen/Sicherheitsirrtuemer/sicherheitsirrtu emer_node.html)

gängige IT-Sicherheitsirrtümer zusammen, die wir zu vier mal fünf häufigen Irrtümern ergänzt haben und im Folgenden in vier Kategorien vorstellen.

Internet-Sicherheit Sie surfen wahrscheinlich auch regelmäßig im Internet und wollen sich dabei schützen. Einige Nutzerinnen haben seltsame Vorstellungen, wie man sich schützt und was die Schutzmechanismen leisten können. Eine Firewall schützt vor allen Angriffen aus dem Internet. Eine Firewall schützt unsere Rechner erst einmal überhaupt nicht. Erst das Regelwerk der Firewall erzeugt den Schutz. Je nach Firewall gibt es im Lieferumfang unter Umständen ein DefaultRegelwerk. Gerade im Privatbereich ist dieses jedoch nicht auf maximalen Schutz ausgelegt, sondern eher auf Vermeidung von Support-Anrufen. Eine Firewall als virtueller Pförtner lässt immer einigen Datenverkehr passieren, zum Beispiel E-Mail-Empfang und Web-Surfen, und damit kann auch Schadsoftware durch die Firewall gelangen. Für einen IT-Laien ist eine sichere Konfiguration einer Firewall nicht leistbar, da sie ein gutes technisches Verständnis der Internet-Protokolle voraussetzt. Wenn das Virenschutzprogramm aktuell ist, muss ich Updates für andere Software nicht sofort installieren. Ein kostenloses Virenschutzprogramm ist völlig ausreichend. Virenschutzprogramme erkennen nicht alle Schadsoftware. Gerade aktuelle, neue Viren werden nicht sofort erkannt. Deswegen müssen wir trotz Virenscanner Softwareupdates immer unverzüglich einspielen. Windows 7 ist mittlerweile auch mit einem aktuellen Virenscanner unsicher. Kostenlose Virenschutzprogramme haben häufig eine geringere Funktionalität als die kostenpflichtigen Versionen und eine geringere Updatefrequenz, denn der Hersteller lebt vom Verkauf der Software. Die in der freien Version fehlende Funktionalität ist aber der innovative Teil des Virenscanners, den Sie

gerne zum Schutz Ihres Rechners nutzen würden. In Unternehmen ist der Einsatz kostenloser Virenschutzprogramme aus lizenzrechtlichen Gründen nicht möglich, da die kostenlosen Varianten überwiegend nur für einen nicht-kommerziellen Einsatz lizenziert werden. Ein einziges langes und komplexes Passwort reicht für alle meine Internet-Dienste vollkommen aus. Es ist keine gute Idee, wenn wir für alle Dienste, die wir nutzen, immer dasselbe Passwort verwenden. Bei vielen Diensten wird als Nutzername eine E-Mail-Adresse verwendet. Werden der Nutzername und das zugehörige Passwort bei einem Dienst von Kriminellen gestohlen, ist es dann auch bei allen anderen Diensten kompromittiert, denn da funktioniert in diesem Fall dieselbe Kombination aus E-Mail-Adresse und Passwort! Und wenn Sie dann auch noch dasselbe Passwort bei Ihrem E-Mail-Anbieter nutzen, hat der Angreifer auch Zugriff auf all Ihre E-Mails. Anbieter wie »';– have i been pwnded« (https://haveibeenpwned.com/) zeigen, wie oft und in welchem Umfang dies geschieht. Nur wenn Sie für jeden (!) Dienst ein eigenes Passwort verwenden, können Sie im Falle des Falles den Schaden auf den Anbieter des kompromittierten Dienstes begrenzen. Ich surfe nur auf seriösen Webseiten, darum kann mir nichts passieren. Auch das Webangebot eines vertrauenswürdigen Anbieters kann gehackt sein – dann wird über diese scheinbar ganz seriöse Webseite Schadsoftware verbreitet. Viele Anbieter finanzieren ihre Webangebote über Werbung. Die Werbeanzeigen werden dabei direkt von den Werbeanbietern geladen. Und auch diese können gehackt werden und mit der Werbung Schadsoftware verteilen. Auch Browser können Sicherheitslücken haben, über welche sich Ihr Rechner hacken lässt. Letztendlich gibt es keine Garantie, dass eine Webseite dauerhaft frei von Schadsoftware bleibt, egal wie gut ihr Ruf ist. Die Nutzung eines Virtual Private Networks (VPN) erlaubt eine anonyme und sichere Internetnutzung.

Wenn Sie das VPN eines kommerziellen Anbieters verwenden, nutzen Sie das Internet mit einer IP-Adresse des Anbieters. Ihr Internet-Provider kann nicht mehr analysieren, welche Seiten Sie im Internet aufrufen. Dafür sieht jedoch der VPN-Anbieter alles, was Sie im Internet über das VPN so anstellen. Da dieser Dienst bezahlt wird, ist dem Anbieter in der Regel auch Ihre echte Identität bekannt. Damit erfolgt keine anonyme, sondern nur eine pseudonyme Nutzung des Internets. Es hängt vom Anbieter ab, ob er Ihre Identität auf Nachfrage von Dritten (zum Beispiel von Sicherheitsbehörden) offenlegt. Ein VPN stellt die Vertraulichkeit der Kommunikation in unsicheren Netzen, beispielsweise in einem öffentlichen WLAN, sicher. Es ist kein Anonymisierungsdienst. Ein VPN verschlüsselt ausschließlich den Datenverkehr zwischen Ihrem PC und dem VPN-Server und schützt damit vor dem Abhören Ihrer Kommunikation in nicht-vertrauenswürdigen Netzen. Ein VPN schützt Sie nicht vor dem Download von Schadsoftware und nur eingeschränkt vor unberechtigten Zugriffen auf Ihren PC. In einem öffentlichen WLAN kann je nach Konfiguration Schutz vor Zugriffen durch andere gleichzeitige Nutzerinnen des WLANs möglich sein.

Mobile und Cloud-Sicherheit Einige Nutzerinnen haben recht naive Vorstellungen, was ein CloudDienstleister leisten kann, insbesondere, wenn der Kunde die Dienstleistung kostenlos in Anspruch nimmt. Auch beim sicheren Umgang mit Smartphones gibt es bei manchen Nutzerinnen einige Unklarheiten. Meine in der Cloud gespeicherten Daten sind vor einem Fremdzugriff sicher geschützt. Schützen Sie auch den Zugriff auf Ihre Daten in der Cloud nur durch ein Passwort? Wird Ihr Passwort einem Dritten bekannt, so ist für den Dritten der Zugriff auf Ihre Daten möglich. Außerdem haben die Administratoren und möglicherweise andere Beschäftigte des Cloud-

Anbieters Zugriff auf Ihre Daten. Dieser Zugriff ist den Beschäftigten zwar untersagt, aber er ist in der Regel nicht technisch unterbunden. Wenn ich meine Daten in der Cloud speichere, benötige ich kein Backup. Gerade kostenloser Speicherplatz in der Cloud ist nicht immer mit umfangreichen automatischen Backups versehen. Schließlich kostet ein Backup Geld, was mit dem kostenlosen Angebot nicht verdient wird. Auch Cloud-Anbieter haben schon Daten verloren oder mussten sogar danach ihr Geschäft aufgegeben. Und dann sind Ihre Daten, die Sie bei dem Cloud-Anbieter gespeichert haben, unter Umständen nicht mehr zugreifbar. Zwei Kopien der Daten, auf Ihrem Rechner und in der Cloud sind zu wenig für ein verlässliches Backup. Ein Großbrand in einem Straßburger Rechenzentrum eines großen französischen Cloud-Anbieters im Frühjahr 2021 führte vielen Kunden vor Augen, dass die Daten, die in der Cloud gespeichert sind, verloren gehen können. Diese Erfahrung wollen Sie bestimmt nicht machen. Ein Backup basiert auf der Idee, das Sie mehrere Kopien einer Datei so speichern, dass eine Beschädigung oder Zerstörung einer Datei die Kopie dieser Datei in der Cloud nicht betrifft. Da die gängigen Cloud-Speicher die lokale Kopie der Datei auf Ihrem PC mit der Cloud-Kopie automatisch synchronisieren, führt die Beschädigung Ihrer lokalen Kopie automatisch auch zur Beschädigung der CloudKopie, wenn der Cloud-Dienst keine Versionierung der Dateien unterstützt. Das Surfen in öffentlichen WLANs kostet mich kein Geld und ist zusätzlich auch noch sicher. Öffentliche WLANs sind in der Regel unverschlüsselt. Auch wenn nach § 202b StGB das »Abfangen von Daten (…) aus einer nichtöffentlichen Datenübermittlung« verboten ist und bestraft wird, ist dies wegen der fehlenden Verschlüsselung technisch problemlos möglich. Der Rechner, mit dem Sie in dem öffentlichen WLAN

eingebucht sind, kann auch recht leicht angegriffen werden, da Ihr Rechner im WLAN von den Rechnern der anderen Nutzerinnen in dem WLAN einfach zu erreichen ist. Die meisten WLAN-Anbieter verhindern dies nicht. Der Schutz einer dedizierten Firewall, wie Sie ihn an Ihrem Arbeitsplatz im Unternehmens-LAN oder in Ihrem Heimnetz haben, fehlt. Sie sind allein auf die Schutzwirkung Ihrer Desktop-Firewall angewiesen. Haben Sie die dafür richtig konfiguriert? Wenn nicht, ist Ihr Rechner im WLAN allen anderen Rechnern im gleichen WLAN weitgehend schutzlos ausgeliefert. Wenn ich mir ein neues Smartphone zulege, habe ich immer auch ein sicheres Gerät. Nicht jedes aktuell verkaufte Smartphone wird mit der aktuellsten Version des Betriebssystems ausgeliefert. Die Sicherheit Ihres neuen Smartphones hängt aber wesentlich von der Aktualität der Software (Betriebssystem und Anwendungen) ab. Gerade bei günstigen Geräten ist es häufig nicht möglich, die Software zu aktualisieren, da der Hersteller nie ein Update ausliefert. Der Hersteller hat hier zulasten des Kunden am falschen Ende gespart. Ich habe alle automatischen Updates und Aktualisierungen des Betriebssystems und meiner Apps aktiviert, daher brauche ich mich um keine Schwachstellen und Sicherheitslücken zu kümmern. Zum einen müssen Sie regelmäßig kontrollieren, ob das Einspielen der Updates auch funktioniert hat, zum anderen sind alle Geräte irgendwann End-of-Life (das heißt, sie werden vom Hersteller nicht mehr mit Aktualisierungen unterstützt) und werden dann eben nicht mehr aktualisiert. Vom Bekanntwerden einer Sicherheitslücke bis zur Verfügbarkeit des Updates, das die Sicherheitslücke behebt, für Ihr Gerät kann es im Extremfall ein paar Wochen dauern. So lange müssen Sie sich mit einem provisorischen Workaround schützen, der in der Regel manuell einzurichten ist.

Endgerätesicherheit

Die Rechner der Nutzerinnen werden mittlerweile flächendeckend von Kriminellen angegriffen. Dadurch wird ein Grundrauschen erzeugt, in dem zielgerichtete Angriffe kaum noch auffallen. Manche Einschätzung der damit verbundenen Gefahren ist deutlich durch Unkenntnis geprägt. Wenn ich mir doch mal einen Virus oder eine andere Schadsoftware auf dem Computer einfange, bemerke ich dies sofort. Die Erfahrung in Unternehmen zeigt, dass ein Befall mit einer Schadsoftware nicht sofort bemerkt wird. Destruktive Schadsoftware, wie zum Beispiel ein Verschlüsselungstrojaner, wird dabei noch am schnellsten festgestellt. Bei ausgefeilter Spionagesoftware dauert es dagegen im Mittel etliche Monate, bis die Infektion im Unternehmen bemerkt wird – manchmal nur durch Zufall. Und auch dann wird der Befall häufig erst nach Hinweisen Dritter gefunden. Wenn aber die IT-Profis die Infektion durch eine Schadsoftware nicht sofort bemerken, wie sollen IT-Laien oder normale Verbraucher das dann schaffen? Ich habe nichts zu verbergen und meine Daten sind völlig uninteressant, also bin ich doch kein lohnendes Ziel für Angreifer. Deshalb benötige ich auch keinen Schutz. Sie haben bestimmt, wie jeder andere auch, auf Ihrem Rechner wichtige vertrauliche Daten. Die Zugangsdaten zu Ihrem Bankkonto, Ihre Verträge, Ihre Steuererklärungen, Kommunikation mit Ihren Ärzten und so weiter. Das sind Daten, die Sie sicher ungern in der Öffentlichkeit sehen würden. Und damit bieten diese Daten zumindest die Basis für eine Erpressung, sei es durch eine Verschlüsselung Ihrer Daten (Ransomware) oder durch die Drohung, Ihre Daten zu veröffentlichen. Ich habe alle Zugriffsmöglichkeiten auf meinen Computer umkonfiguriert, die findet niemand mehr. Das Prinzip heißt »Security by Obscurity« und ist leider überhaupt nicht sicher. Warum legen Sie Ihren Haustürschlüssel nicht unter die Fußmatte? Weil jemand den Schlüssel dort finden könnte, ist die typische Antwort. Niemand kommt auch auf die Idee, dass Sie Ihre

Girocard-PIN als Telefonnummer im Adressbuch stehen haben, oder? Egal wie Sie Dienste umkonfigurieren, also Ihren Webserver, den Remotedesktop-Zugriff und andere Dienste, wenn Sie die Dienste aus dem Internet erreichbar machen, findet ein Angreifer die Dienste auch. Insbesondere, wenn Sie für die Umkonfiguration eine gängige Anleitung aus dem Internet benutzt haben, können Sie davon ausgehen, dass Angreifer diese mindestens so gut kennen wie Sie. Wenn Sie den Dienst aber wirklich gut abgesichert haben, dann müssen Sie ihn nicht verstecken. Wenn ich alle Daten von meinem Gerät lösche und dann auich noch den Papierkorb leere, dann kann niemand mehr auf meine Daten zugreifen. Aus Geschwindigkeitsgründen wird, wenn Sie eine Datei löschen, oft nur der Verzeichniseintrag der Datei entfernt, woraufhin die Datei Ihnen nicht mehr angezeigt wird. Der Inhalt der Datei wird beim Löschen dagegen nicht verändert. Diese Dateireste auf dem Datenträger werden erst im Laufe der Zeit, wenn der Speicherplatz für andere Dateien benötigt wird, überschrieben. Mit einfachen Softwarewerkzeugen (sogenannte Unerase-Programme) lässt sich die Datei, solange sie nicht überschrieben wurde, wiederherstellen. Daten auf einer klassischen Festplatte müssen Sie komplett mit anderen Daten überschreiben, Daten auf einem Solid State Drive (SSD) müssen Sie mit speziellen Befehlen löschen oder Sie müssen den Datenträger physisch zerstören, damit die Daten wirklich gelöscht sind. Never touch a running system. Wenn Ihr sorgfältig konfiguriertes IT-System einmal stabil läuft, möchten Sie es möglichst nicht mehr ändern. Das Risiko, dass es nach der Änderung nicht mehr läuft, erscheint Ihnen zu hoch. Dabei ist es zwingend erforderlich, dass Sie sicherheitsrelevante Updates installieren. Gegebenenfalls überlegen Sie auf Basis der Updatebeschreibung und der Beschreibung der Sicherheitslücken sorgfältig, ob die zugrundeliegende Bedrohung bei Ihrem System gegeben ist. Wenn die Sicherheitslücke zum Beispiel den Bluetooth-

Funk betrifft, Sie aber Bluetooth deaktiviert haben, können Sie das Update überspringen. Sie dürfen dann aber, wenn Sie Bluetooth doch aktivieren, nicht vergessen, das Update eben doch zu installieren!

E-Mail-Sicherheit Auf Grund des fehlenden technischen Verständnisses schätzen viele Nutzerinnen die Risiken bei der E-Mail-Nutzung völlig falsch ein. Wenn ich den Anhang einer E-Mail nicht öffne, sondern nur den Mailtext lese, kann mir nichts passieren. Da E-Mail-Programme Ihnen ein Vorschaufenster zum Betrachten der E-Mail bieten und viele E-Mails, damit sie schöner aussehen, als HTML-Mails verschickt werden, können Sie auch durch das Anschauen einer E-Mail bereits eine Schadsoftware starten. Insbesondere Glückwunsch- und Weihnachtskarten und dergleichen sind da ein besonderes Risiko, da sie mit viel Aufwand (und entsprechend viel ausführbarem Code in der E-Mail) daherkommen. Auf eine Spam-Mail kann ich gefahrlos antworten, ich auch den Link zum Löschen aus dem Verteiler nutzen. Durch die Antwort auf solch eine E-Mail oder einen Klick auf den Link darin unterstützen Sie den Spammer. Er erhält die Bestätigung, dass Ihre E-Mail-Adresse aktiv genutzt wird, und damit steigt der Wert Ihrer E-Mail-Adresse für ihn. Nur seriöse Verteilerlisten erlauben es Ihnen als Abonnenten der Mailing-Liste, sich auszutragen. Gerade das Anklicken eines Links in einer nichtvertrauenswürdigen E-Mail stellt immer ein hohes Risiko für Sie dar, da Sie nie wissen, ob dadurch nicht ein schädliches Programm auf ihrem Endgerät gestartet wird. Eine E-Mail wurde immer von der Adresse versandt, die mir im Absender-Feld angezeigt wird. Die Ihnen von Ihrem Mail-Programm angezeigte E-Mail-Adresse des Absenders hat technisch nichts mit dem tatsächlichen Absender zu tun. Sie kann mehr oder weniger frei gewählt werden. Der

tatsächliche Absender steht zwar häufig auch in der E-Mail (genauer im E-Mail-Header), dieser E-Mail-Header wird Ihnen aber von Ihrem Mail-Programm standardmäßig nicht angezeigt. Und auch wenn es etwas aufwendiger ist, lassen sich auch Einträge im E-MailHeader manipulieren. Das gilt übrigens auch für das An-Feld in der E-Mail. Der tatsächliche Empfänger und der angezeigte Empfänger sind zwei verschiedene Adressen. Das kennen Sie von E-Mails, bei denen Sie die Mail per Blind Carbon Copy (BCC, so viel wie »unsichtbare Kopie«) erhalten. Sie bekommen die E-Mail, aber weder im An-Feld noch im cc-Feld steht ihre E-Mail-Adresse. Phishing-Mails erkenne ich auf den erstten Blick. Schlecht gemachte Phishing-E-Mails erkennen Sie leicht, wenn Sie wissen, woran Sie diese erkennen können. Wirklich gute Phishing-EMails sind jedoch auch für erfahrene IT-Sicherheitsexperten allein durch normales Öffnen und Betrachten sehr schwer zu erkennen. Zum Glück sind diese selten, da sie aufwendig zu erstellen sind. Für nicht so erfahrene Nutzerinnen sind allerdings auch durchschnittliche Phishing-E-Mails im beruflichen Alltagsstress nicht immer direkt zu erkennen. Eine E-Mail ist beim Transport vor unbefugten Zugriffen geschützt. Der Vergleich der Vertraulichkeit einer E-Mail mit einer Postkarte ist Ihnen sicher bekannt. Aktuell können Sie nur dann sicher sein, dass eine E-Mail »unterwegs« geschützt ist, wenn Sie sie mit einem geeigneten Verfahren (S/MIME oder OpenPGP) verschlüsseln. Häufig, aber leider nicht immer, wird der Transport einer E-Mail von Mail-Server zu Mail-Server durch eine solche Verschlüsselung geschützt. Ob eine solche Transportverschlüsselung genutzt wird, entscheiden aber die Betreiber der Mail-Server und nicht Sie als Absender oder Empfänger der E-Mail. Die Transportverschlüsselung schützt nur vor dem Abhören der Übertragung zwischen den Mail-Servern durch Dritte. Eine unverschlüsselte E-Mail ist für den Betreiber eines Mail-Servers

grundsätzlich zugänglich. Der Zugriff ist rechtlich nur eng beschränkt zulässig, aber rein technisch eben durchaus möglich. Sie haben jetzt schon einige Begriffe und Konzepte der IT-Sicherheit kennengelernt. Begriffe wie Backup, Cloud, LAN, Schadsoftware oder Verschlüsselung haben Sie im normalen IT-Leben wohl auch schon einmal gehört. Speziellere Begriffe wie S/MIME, OpenPGP oder Transportverschlüsselung sind dagegen vielleicht völlig neu für Sie. Beim weiteren Studium des Buches werden Sie diese Begriffe im Detail kennenlernen und die Konzepte dahinter verstehen.

Kapitel 2

Grundlagen der Informationssicherheit IN DIESEM KAPITEL Grundkonzepte der Informationssicherheit Vertraulichkeit, Integrität und Verfügbarkeit Authentizität und weitere Schutzziele Technik allein genügt nicht!

Bevor wir uns mit den Details der IT-Sicherheit beschäftigen, müssen wir definieren, was IT-Sicherheit, Informationssicherheit oder Cybersicherheit jeweils ist. Es stellt sich die Frage, ob diese Begriffe Synonyme sind oder ob es Unterschiede zwischen ihnen gibt. In vielen Fachbüchern finden Sie natürlich entsprechende Definitionen im jeweiligen Kapitel über IT-Sicherheit. In der Regel sind diese aber stark durch eine technische Sichtweise geprägt.

Was ist Informationssicherheit? Informationssicherheit ist weit mehr als IT-Sicherheit und schließt ganz wesentlich auch organisatorische Aspekte mit ein. Sie beschäftigen sich in der Informationssicherheit grundsätzlich mit dem Schutz von Informationen, unabhängig davon, wo die Informationen gespeichert sind. Es kann Ihnen dabei egal sein, ob die Informationen digital auf elektronischen Datenträgern, analog auf Papier oder nur in den Köpfen der Beschäftigten vorhanden sind. In der IT-Sicherheit geht es im Gegensatz dazu nur um die Sicherheit der IT und der dort hinterlegten digitalen Informationen.

Was ist IT-Sicherheit? Erstaunlicherweise finden Sie eine in diesem Sinne nahezu vollständige Definition der IT-Sicherheit in einem deutschen Gesetz, dem Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, oder kurz BSI-Gesetz. Das BSI ist die Behörde in Deutschland, die sich um die Informationssicherheit im Regierungsnetz und im Bereich der kritischen Infrastruktur (kurz KRITIS, siehe Kapitel 6, Abschnitt BSI-Gesetz) sowie generell um die Förderung der Informationssicherheit kümmert. Im BSI-Gesetz finden wir die nachfolgende Definition der IT-Sicherheit (in der folgenden Definition sind die Satznummern angegeben, damit Sie sich leichter tun, wenn wir uns auf die Sätze beziehen): » Informationen sowie informationsverarbeitende Systeme, Komponenten und Prozesse sind besonders schützenswert. Der Zugriff auf diese darf ausschließlich durch autorisierte Personen oder Programme erfolgen. Die Sicherheit in der Informationstechnik und der damit verbundene Schutz von Informationen und informationsverarbeitenden Systemen vor Angriffen und unautorisierten Zugriffen im Sinne dieses Gesetzes erfordert die Einhaltung bestimmter Sicherheitsstandards zur Gewährleistung der informationstechnischen Grundwerte und Schutzziele. Sicherheit in der Informationstechnik … bedeutet die Einhaltung bestimmter Sicherheitsstandards, die die Verfügbarkeit, Integrität oder Vertraulichkeit von Informationen betreffen, durch Sicherheitsvorkehrungen 1. in informationstechnischen Systemen, Komponenten oder Prozessen oder 2. bei der Anwendung von informationstechnischen Systemen, Komponenten oder Prozessen.«

§ 2 Abs. 2 BSI-Gesetz (BGBl. I S. 2821, zuletzt geändert durch Art. 1 des Gesetzes vom 18. Mai 2021 (BGBl. I S. 1122)

Die Gültigkeit dieser Definition in Satz 4 ist auf den Geltungsbereich des BSI-Gesetzes eingeschränkt. Diese Einschränkung haben wir weggelassen und durch »…« ersetzt. Ohne diese Einschränkung wäre das eine allgemeine rechtliche Definition der IT-Sicherheit. Lassen Sie uns diese Definition nun interpretieren, um sie im Detail zu verstehen. Die Sätze 1 bis 3 wurden erst 2021 durch das sogenannte ITSicherheitsgesetz 2.0 zur Erläuterung in das BSI-Gesetz eingefügt, »um den Inhalt der Schutzziele der Informationssicherheit näher zu bestimmen«. So finden Sie die Begründung der Ergänzung in der Bundestagsdrucksache. Sie müssen nicht nur die Informationen schützen, sondern auch die informationsverarbeitenden Systeme. Informationstechnische Systeme sind technische Anlagen, »die der Informationsverarbeitung dienen und eine abgeschlossene Funktionseinheit bilden. Typische IT-Systeme sind Server, Clients, Einzelplatzcomputer, Mobiltelefone, Router, Switches und Sicherheitsgateways.« [BMI16] Satz 2 fordert, dass nur berechtige Personen und Programme auf die Informationen zugreifen dürfen. Dass unberechtigte Personen nicht zugreifen dürfen, ist Ihnen sofort klar. Aber eine Schadsoftware ist keine unberechtigte Person, sondern ein unberechtigtes Programm und darf auch nicht auf die Informationen zugreifen. Diese Klarstellung in Satz 2 ist nachvollziehbar und sinnvoll. Satz 3 geht vom Schutz vor Angriffen und unberechtigten Zugriffen aus. Die Definition greift dabei zu kurz, da sie nur auf den Schutz vor Angriffen (beabsichtigte Störungen, englisch security) abzielt und die unbeabsichtigten Störungen (englisch safety) außen vor lässt. Dabei müssen Sie in einem umfassenden Informationssicherheitskonzept auch den Schutz vor Störungen durch Naturgewalten und Unfälle (zum Beispiel Brand im Rechenzentrum, Stromausfall, Hochwasser) berücksichtigen. Ihnen kann es als Nutzerin egal sein, ob Ihr

Internetzugang im Home Office wegen eines Hackerangriffs auf den Provider oder wegen eines Stromausfalls beim Provider ausgefallen ist. In beiden Fällen können Sie nicht arbeiten. In der IT-Sicherheit müssen Sicherheitsstandards eingehalten werden, das heißt, ohne Sicherheitsstandards, also ohne Vorgaben, gibt es keine Informationssicherheit. Durch die Sicherheitsstandards wird der SollZustand vorgegeben. Abweichungen des Ist-Zustands vom Soll-Zustand werden als Sicherheitsvorfälle bezeichnet. Der Begriff Standard ist hier nicht nur im Sinne von ISO-Standards, DIN-Normen oder BSIGrundschutz zu verstehen. Jede Passwortrichtlinie und jede Nutzerordnung in Ihrem Unternehmen oder Ihrer Behörde ist ein interner Sicherheitsstandard im Sinne einer solchen Vorgabe. Laut Satz 4 sollen Sicherheitsmaßnahmen in den Systemen (Nummer 1) und bei der Nutzung der Systeme (Nummer 2) getroffen werden. Lassen Sie uns das an einem einfachen, analogen Beispiel verdeutlichen. Stellen Sie sich ein Bürogebäude vor, in dem die Türen keine Schlösser haben. Die Türen stehen ständig offen und die auf den Schreibtischen liegenden Dokumente sind dem Zugriff Unbefugter ausgesetzt, wenn ein Beschäftigter das Büro verlassen hat. Die Unternehmensleitung möchte die Sicherheit erhöhen und lässt deswegen Schlösser in die Türen einbauen. Das Ergebnis ist aber, dass trotz eingebauter Schlösser die Türen ständig offenstehen. Daraufhin erlässt die Unternehmensleitung eine Dienstanweisung, dass beim Verlassen des Büros die Bürotür abgeschlossen werden muss. Die technische Maßnahme »Schloss« allein löste das Problem nicht. Erst die ergänzende organisatorische Maßnahme »Dienstanweisung« über den Umgang mit dem Schloss schafft den gewünschten Erfolg. Da sich nicht alle Beschäftigten zu 100 Prozent an die Dienstanweisung halten, müssen zusätzlich regelmäßige Kontrollen die Regeleinhaltung sicherstellen. Entsprechendes gilt auch in der digitalen Welt. Es ist zum Beispiel nicht hinreichend, wenn Sie ein Betriebssystem einsetzen, das eine Anmeldung mit Benutzername und Passwort ermöglicht. Es sind auch verbindliche Regeln (typisch Passwort-Policy oder Passwortrichtlinie) im Unternehmen erforderlich, die einen vernünftigen Umgang mit

Passwörtern vorgeben, etwas in puncto Mindestlänge, Komplexität und Wechselhäufigkeit. Hand aufs Herz: Nutzen Sie bei allen Ihren Rechnern ein sicheres Passwort? In der Definition lesen Sie auch erstmals die Begriffe »Verfügbarkeit, Integrität oder Vertraulichkeit« als etwas, das Sie sicherstellen müssen. Diese Begriffe, die auch Schutzziele genannt werden, müssen wir uns im weiteren Verlauf dieses Kapitels noch genauer anschauen. Nicht nur der deutsche Gesetzgeber definiert Informationssicherheit, sondern auch der europäische. 2016 trat die Richtlinie über Maßnahmen zur Gewährleistung eines hohen gemeinsamen Sicherheitsniveaus von Netz- und Informationssystemen in der Union, kurz NIS-Richtlinie, in Kraft (siehe Kapitel 6). Auch hier finden Sie in Artikel 4 eine Definition der »Sicherheit von Netz- und Informationssystemen«. »›Sicherheit von Netz- und Informationssystemen‹ [ist] die Fähigkeit von Netz- und Informationssystemen, auf einem bestimmten Vertrauensniveau alle Angriffe abzuwehren, die die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit gespeicherter oder übermittelter oder verarbeiteter Daten oder entsprechender Dienste, die über diese Netz- und Informationssysteme angeboten werden beziehungsweise zugänglich sind, beeinträchtigen; « Art. 4 Nr. 2 NIS-Richtlinie, ABl. L 194 vom 19.7.2016, S. 1–30

Sie finden hier den zusätzlichen Begriff der »Authentizität« bei den Schutzzielen. Wenn Sie das BSI-Gesetz von Anfang bis Ende lesen, stoßen Sie auf diesen Begriff auch dort in zahlreichen Paragraphen (genauer in den Paragraphen 2, 8a, 8b und 8f). Diese Absätze wurden allerdings alle erst nachträglich in das BSI-Gesetz eingefügt. Hier sehen Sie, wie ein Begriff aus der europäischen Gesetzgebung dann bei der Anpassung der deutschen Gesetze an die europäischen Vorgaben in den deutschen Gesetzen auftaucht.

In der NIS-Richtlinie finden Sie eine Definition der Sicherheit als Fähigkeit von Systemen, Angriffe auf Daten, Dienste und Systeme abzuwehren. In dieser Definition fehlt Schutz vor Störungen durch Naturgewalten und Unfälle vollständig. Die NIS-Richtlinie regelt den Bereich der sogenannten »kritischen Infrastruktur«, also den Bereich, der bei einem Ausfall unser gesellschaftliches Leben erheblich beeinträchtigen kann. Darüber hinaus sind dort auch die digitalen Dienste, das sind Online-Suchmaschinen, Online-Marktplätze und Cloud-Computing-Dienste, geregelt. Gerade bei der kritischen Infrastruktur ist der Schutz vor den Auswirkungen von Katastrophen extrem relevant.

Was ist Cybersicherheit? 2019 trat die EU-Verordnung über die ENISA (Agentur der Europäischen Union für Cybersicherheit) und über die Zertifizierung der Cybersicherheit von Informations- und Kommunikationstechnik (Rechtsakt zur Cybersicherheit) in Kraft. In dieser Verordnung finden Sie den für uns jetzt neuen Begriff »Cybersicherheit«. In der Definition taucht dann der Begriff »Cyberbedrohung« auf, der dort ebenfalls definiert ist. »›Cybersicherheit‹ bezeichnet alle Tätigkeiten, die notwendig sind, um Netz- und Informationssysteme, die Nutzer solcher Systeme und andere von Cyberbedrohungen betroffene Personen zu schützen; ›Cyberbedrohung‹ bezeichnet einen möglichen Umstand, ein mögliches Ereignis oder eine mögliche Handlung, der/das/die Netzund Informationssysteme, die Nutzer dieser Systeme und andere Personen schädigen, stören oder anderweitig beeinträchtigen könnte;« Art. 2 Nr. 1 und Nr. 8 Rechtsakt zur Cybersicherheit, ABl. L 151 vom 7.6.2019, S. 15–69

In diesem Rechtsakt zur Cybersicherheit finden Sie keine vorgegebenen Schutzziele, vielmehr ist alles, was zum Schutz der Systeme und Nutzerinnen erforderlich ist, durch die Definition erfasst. Diese Definition ist sehr viel abstrakter, aber auch umfassender. Nachdem in den deutschen Gesetzen, Normen und in der Fachliteratur über einen längeren Zeitraum der Wechsel von IT-Sicherheit zur Informationssicherheit weitgehend vollzogen wurde, kündigt sich jetzt der Begriff Cybersicherheit an und weitet den Anwendungsbereich nochmals aus. Auch wenn es modern ist, von »Cyber« zu reden, ist Ihnen vielleicht auf den ersten Blick nicht klar, was damit gemeint ist. Cyberabwehr, Cyberkrieg, Cyberspionage, Cybercrime, Abwehr von Cyberangriffen, diese Schlagworte finden Sie zum Beispiel auch zuhauf auf den Seiten des Verteidigungsministeriums [BMVG]. Der »Cyberraum« oder auch der »Cyber- und Informationsraum« beschreibt als Sammelbegriff die gesamte digital vernetzte Welt: also das weltumspannende Internet mit all seinen Facetten – inklusive des Darknets, eines verborgenen Teils des Internets, der nur mit spezieller Software zugänglich ist. Alle Bedrohungen, die aus dem Cyberraum kommen, sind Cyberangriffe und der Schutz vor diesen Bedrohungen und die Abwehr solcher Angriffe machen die Cybersicherheit aus. Während IT-Sicherheit sich technisch auf den Schutz der informationstechnischen Systeme fokussiert, bezieht Informationssicherheit zusätzlich den Schutz von Informationen losgelöst von der Technik mit ein. »Cyber-Sicherheit ist die ITSicherheit der im Cyber-Raum auf Datenebene vernetzten bzw. vernetzbaren informationstechnischen Systeme.« [BMI16] International, insbesondere im englischsprachigen Raum und im politischen Sprachgebrauch, ist Cybersicherheit bzw. Cybersecurity der relevante Begriff. Er wird allerdings häufig synonym mit IT-Sicherheit verwendet. [CBL14]

Klassische Schutzziele der Informationssicherheit Auf Grund der englischen Begriffe Confidentiality, Integrity und Availability wird auch gerne die Abkürzung »CIA« für diese drei grundlegenden Schutzziele gewählt.

Verfügbarkeit Der Einstieg in die Diskussion über die Verfügbarkeit erfolgt am einfachsten durch die Frage: »Leidet Ihre Arbeit, wenn Sie vorübergehend nicht an Ihre Daten kommen?«. Wenn Sie diese Frage mit »ja« beantworten, wird es Zeit, dass Sie sich Gedanken über die Verfügbarkeit Ihrer Daten und Systeme machen. Beispiele im persönlichen Bereich gibt es viele. Einem Doktoranden wird drei Tage vor der Abgabe der Dissertation das Notebook aus dem Auto gestohlen. Die einzige Kopie des Werkes war auf der Festplatte des Notebooks. Der Rechner eines Handwerkers wird von einer Ransomware befallen, die alle Daten auf der Festplatte verschlüsselt, um ein Lösegeld zu erpressen. Der Betrieb hat auf keinerlei Kundendaten mehr Zugriff. Ein wichtiger Aspekt, den wir bei der Verfügbarkeit gerne übersehen, ist die Aktualität der eingesetzten Software. Anbieter bringen regelmäßig neue Versionen einer Software auf den Markt und stellen dann die Pflege der alten Versionen ein. Zur Pflege der Software gehört aber auch das Beheben von Sicherheitslücken. Veraltete Software hat Sicherheitslücken, die nie mehr behoben werden. Diese Sicherheitslücken sind dann das Einfallstor für Schadsoftware oder Angreifer. Sie sehen mit dieser Argumentation, dass veraltete Software Auswirkungen auf die Verfügbarkeit Ihrer IT-Systeme haben kann. Daher muss eine IT-Abteilung veraltete (das heißt vom Hersteller nicht mehr unterstützte) Versionen von Software regelmäßig durch aktuelle ersetzen. Dass dies nicht im ausreichenden Maß geschieht, ist schon mehrfach durch Untersuchungen belegt. Ein bescheidenes Bild (aus

Sicht der IT-Abteilungen) bietet eine Studie von Kwan Lin der Fa. Rapid7 aus dem Oktober 2020 am Beispiel von aus dem Internet erreichbaren Windows-Servern (siehe Abbildung 2.1).

Abbildung 2.1: Anzahl der aktuellen (2012, 2016 und 2019) und veralteten (2003, 2008) Windows Server Versionen. (Quelle: Rapid7 Blog, Oktober 2020)

Es sind deutlich mehr veraltete Versionen des Windows-ServerBetriebssystems aus dem Internet erreichbar, als aktuelle von Microsoft noch gepflegte Versionen. Sie sehen zwar in der Abbildung 2.1, dass die Zahl der veralteten Server abnimmt, aber schnell geschieht das nicht. Der Support für Windows Server 2003 wurde im Juli 2015 und der für Windows Server 2008 und 2008 R2 im Januar 2020 eingestellt. Um die Verfügbarkeit der Daten und/oder Systeme sicherzustellen, bieten sich zum Beispiel folgende Maßnahmen an: Backup der Daten, um diese bei Verlust oder Zerstörung wiederherstellen zu können. Redundanz der Server, damit der Ausfall eines Servers durch einen anderen Server kompensiert werden kann.

Redundanz des Internetzugangs, damit beim Ausfall eines InternetProviders der Internetzugang über einen anderen Provider aufrechterhalten werden kann. Software durch Sicherheitsupdates aktuell halten, damit nicht behobene Sicherheitslücken keine Angriffsmöglichkeiten bieten. Schutz vor Schadsoftware, damit Daten nicht durch Schadsoftware zerstört werden und Rechner nicht durch Schadsoftwarebefall lahmgelegt werden. Dabei reicht meistens eine Maßnahme allein nicht aus, sondern es müssen mehrere Maßnahmen aufeinander abgestimmt ergriffen werden.

Integrität Der Einstieg in die Diskussion des Begriffs »Integrität« erfolgt am einfachsten über die Frage: »Sind Sie sich sicher, dass Ihre Daten unverändert sind?«. Haben Sie auch, wie viele ihrer Mitmenschen, ein gesundes Vertrauen in die Korrektheit der Daten in Ihren IT-Systemen? Aber es ist immer wieder möglich, dass sich Daten verändern. Dies kann beabsichtigt durch Hacker oder eine Schadsoftware geschehen oder auch unbeabsichtigt durch einen technischen Fehler. Gerade ältere Datenträger wie Disketten, Festplatten oder Magnetbänder können durch äußere Magnetfelder beschädigt werden. In großen Archiven ist es üblich, Magnetbänder zur Vorbeugung regelmäßig auf neue Bänder zu kopieren, um die Daten zu erhalten. Selbst bei relativ langlebigen Datenträgern wie CD-ROM, DVD oder Blu-Ray Disc können die gespeicherten Daten durch klimatische Einflüsse (insbesondere Luftfeuchtigkeit, Wärme und helles Licht) verändert werden. Deshalb ist es notwendig, durch geeignete Maßnahmen zumindest die Veränderung zu erkennen. Geeignete Maßnahmen, die Sie treffen können, sind zum Beispiel: Backup der Daten, um im Falle einer Veränderung den alten Stand wieder herstellen zu können. Schutz vor Schadsoftware, damit die Daten nicht durch eine Schadsoftware unbemerkt verändert werden.

Berechnung von Prüfsummen und/oder Hash-Werten, um prüfen zu können, ob die Daten verändert wurden. Digitale beziehungsweise elektronische Signaturen, um zu prüfen, ob die Daten verändert und von wem sie erstellt wurden.

Vertraulichkeit Die Diskussion über die Vertraulichkeit beginnen wir am einfachsten mit der Frage: »Ist es akzeptabel, wenn Dritte Ihre Daten sehen?«. Wenn Sie diese Frage mit »ja« beantworten, müssen Sie sich weiter keine Gedanken machen. Aber kaum jemand wird diese Frage mit »ja« beantworten. Wenn Sie die Daten Dritter verarbeiten, seien es nun personenbezogene oder technische Daten, kann die Antwort auch nicht leichtfertig »ja« sein, denn hier gibt es klare gesetzliche Vorgaben. Schützenswerte Daten müssen durch geeignete technische und/oder organisatorische Maßnahmen vor unberechtigter Kenntnisnahme geschützt werden. Natürlich können Sie Ihre Daten auf einen Datenträger kopieren und sie dann in einen Tresor einschließen. Aber darunter leidet die Benutzbarkeit der Daten ganz erheblich. Trotzdem kann der Tresor unter Umständen eine geeignete technische Maßnahme sein. Eine technisch sinnvollere Methode, wenn man mit den Daten regelmäßig arbeiten will, ist es, die Daten zu verschlüsseln. Situationen, in denen Sie Ihre Daten verschlüsseln sollten, sind: Festplatten in Notebooks, da Notebooks typischerweise das Betriebsgelände verlassen und damit ein Verlustrisiko besteht, mobile Datenträger, da diese auf Grund ihrer Größe leicht verloren gehen können, E-Mails, da diese sich während des Transports leicht abfangen lassen, Zugriff auf Webseiten, da insbesondere bei der Anmeldung an Portalen häufig Passwörter übertragen werden, VoIP-Telefonie, da es möglich ist, die Sprachkommunikation im Netz abzuhören,

Netzwerkverkehr in fremden Netzen (zum Beispiel WLAN im Hotel oder ICE) per VPN, da die anderen Nutzer des Netzes den Datenverkehr abfragen können.

Authentizität Ein weiteres Schutzziel, dass wir in den Regelungen gesehen haben, ist »Authentizität«. Der Begriff stammt aus dem Griechischen und Lateinischen und bedeutet soviel wie »Echtheit« oder »Verbürgtheit«. Im RFC 4949 wird der englische Begriff »authenticity« als »the property of being genuine and able to be verified and be trusted« definiert, also »die Eigenschaft, echt zu sein, überprüft werden zu können und vertrauenswürdig zu sein«. In der Informationssicherheit verwenden wir Authentizität überwiegend als »tatsächlich vom Urheber oder Autor stammend«. Wird eine Nachricht, ein Text oder ein Dokument mit einem Urheber oder Absender verknüpft, so können Sie die Authentizität als einen Teilaspekt der Integrität betrachten.

Verantwortlichkeit Die Verantwortlichkeit (englisch Accountability) beschreibt, dass wir der Nutzerin oder auch dem Anbieter Handlungen belastbar zuschreiben können. Wahrscheinlich können Sie sich auch Situationen vorstellen, wo es für Sie erstrebenswert ist, dass Ihnen Ihre Handlungen nicht zugeordnet werden können (plausible deniability). Gerade Whistleblower oder Regimekritiker in undemokratischen Ländern setzen sich einem hohen Verfolgungsdruck aus, wenn ihnen jede Handlung gerichtsfest zugeordnet werden kann. Die Verantwortlichkeit oder auch Nichtabstreitbarkeit können wir als einen Teilaspekt des Schutzziels Integrität betrachten, wenn wir einer Handlung oder einer Information die Identität des Urhebers hinzufügen. Wird die Identität des Urhebers mit der Information so verknüpft, dass die Verknüpfung nicht mehr aufgelöst werden kann, so lässt sich die Urheberschaft nicht mehr abstreiten. Der Urheber muss die

Verantwortung für die Information übernehmen. Technisch lässt sich dies durch eine digitale Signatur erreichen. Eine digitale Signatur ist ein technisches (genauer ein kryptografisches) Verfahren, das sicherstellt, dass ein Dokument nicht mehr verändert werden kann. Der Ersteller versiegelt das Dokument so, dass Veränderungen bemerkt werden. Eine elektronische Signatur dagegen ist ein rechtlicher Begriff aus der europäischen Verordnung über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt (eIDAS-Verordnung, ABl. L 257 vom 28.8.2014, S. 73). Eine elektronische Signatur kann unter anderem mittels einer digitalen Signatur erzeugt werden. Wenn Sie einen Vertrag schriftlich schließen, ist aufgrund des von allen Vertragsparteien unterschriebenen Dokuments klar, was genau der Vertragsinhalt ist, da Sie es »schwarz auf weiß besitzen«. Jeder von uns hat schon mal die Erfahrung gemacht, wie schwierig es ist, bei einen telefonischen Vertragsabschluss die Konditionen verbindlich geklärt zu bekommen oder nachträglich beweisen zu können. Sie können nicht ohne Weiteres belegen, was die andere Partei gesagt hat. Ein elektronisches Dokument (genauer Textform, siehe § 126b BGB) ist in der Beweiskraft irgendwo zwischen einem mündlichen Vertrag und einem schriftlichen Vertrag angesiedelt. Der Gesetzgeber verlangt bei der Textform lediglich, dass in der Erklärung die Person des Erklärenden genannt wird und dass der Empfänger die Datei auf einem dauerhaften Datenträger für einen angemessen Zeitraum speichert und dass die Datei unverändert wiedergegeben werden kann. Durch geeignete IT-Sicherheitsmaßnahmen muss sichergestellt werden können, dass eine textliche Äußerung auch dem Urheber der Äußerung rechtsverbindlich zugeordnet werden kann. Dabei ist es egal, ob es sich um einen Vertrag per E-Mail handelt oder um eine Hassrede in einem sozialen Medium. Gesetzlich ist die elektronische Form in § 126a BGB geregelt. Soll die elektronische Form die Schriftform ersetzen, muss das Dokument mit einer

qualifizierten elektronischen Signatur im Sinne der eIDASVerordnung versehen werden.

Benutzbarkeit Ist ein System so komplex in der Benutzung (oder auch nur in der Konfiguration), dass ein normaler Nutzer nicht mehr damit klarkommt, kann das System nicht sicher sein. Autos haben eine weitgehend herstellerunabhängige Nutzeroberfläche, das heißt, die Anordnung der Bedienelemente wie Lenkrad, Pedale oder Schalthebel sind so weit vereinheitlicht, dass man auch mit einem unbekannten Auto ganz gut zurechtkommt. Davon sind die Nutzeroberflächen in der IT noch weit entfernt. Viele IT-Systeme werden in einem Zustand ausgeliefert, der keinen sicheren Betrieb zulässt. Die Sicherheitsfunktionen müssen erst eingeschaltet oder angepasst werden. Vielen Nutzerinnen fehlt jedoch das Wissen, diese Konfigurationen vorzunehmen. Der Anbieter hat auch eher ein Interesse an dem reibungslosen Funktionieren seiner Hard- oder Software als an der Sicherheit. Microsoft Office 365 (Desktop-Komponenten) beziehungsweise Microsoft Office 2019/2021 kann über Gruppenrichtlinien konfiguriert und angepasst werden. Insgesamt gibt es in den entsprechenden Vorlagen von Microsoft (Version 5035.1000) 2898 Einstellungen, die Sie vornehmen können. Zum Glück sind nicht alle davon sicherheitsrelevant. Das BSI hat im September 2019 Empfehlungen für die sichere Konfiguration von Office 2013/2016/2019 herausgegeben. Insgesamt sind in diesen Empfehlungen immer noch 457 Einstellungen enthalten. Selbst die Umsetzung dieser doch schon deutlich weniger Einstellmöglichkeiten überfordert viele Nutzerinnen. Typische wichtige Einstellmöglichkeiten, die im Unternehmen (und auch im Privatbereich) vorgenommen werden sollten:

Einschränkung der Übertragung von sogenannten Telemetriedaten (das sind Daten über Ihre Nutzung der Software) in Betriebssystemen und Anwendungen, Festlegen der Firewall-Einstellungen in Routern und bei Betriebssystemen (insbesondere bei mobilen Geräten), Sicherheitseinstellungen in Mail-Programmen und Browsern, Deaktivieren nicht benötigter Dienste, Deinstallation aller nicht benötigten Programme, Änderung aller voreingestellten Passwörter.

Weitere Schutzziele Häufig werden auch noch weitere Schutzziele betrachtet. Gebräuchliche weitere Schutzziele sind Compliance, Datenschutz, Qualität, Resilienz, Verbindlichkeit oder Zuverlässigkeit. Eine Besonderheit stellen hier die Begriffe Compliance und Datenschutz dar. Beides sind eher rechtliche Konzepte. Compliance bedeutet die Einhaltung aller rechtlichen Vorgaben durch ein Unternehmen oder ein Individuum. Soweit Gesetze rechtliche Vorgaben zur IT-Sicherheit machen, ist das Thema Compliance, also die Einhaltung dieser Vorgaben, unmittelbar für die Informationssicherheit relevant. In Teil II dieses Buches werden wir uns die entsprechenden Gesetze näher anschauen. Darüber hinaus gibt es Gesetze, die indirekte Vorgaben machen. So bestehen zum Beispiel gesetzliche Aufbewahrungsfristen für Steuerunterlagen. Für die Dauer der Aufbewahrungspflicht muss die Informationssicherheit die Integrität und Verfügbarkeit der Unterlagen sicherstellen. Datenschutz schützt die Betroffenen – das sind natürliche Personen – davor, dass ihre Rechte und Freiheiten durch die Verarbeitung ihrer Daten verletzt werden. Dabei macht die Verordnung zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr (Datenschutz-Grundverordnung, DS-GVO) auch Vorgaben zur Informationssicherheit, um dieses Schutzziel zu

erreichen. Damit ist die Einhaltung des Datenschutzes für Unternehmen ein Aspekt der Compliance. Die konkreten technisch-organisatorischen Vorgaben, die sich aus der DS-GVO ergeben, betrachten wir im Kapitel 10 ausführlich. Die übrigen Schutzziele lassen sich aus den drei grundlegenden Schutzzielen ableiten, sie bündeln zum Teil auch Aspekte unterschiedlicher Schutzziele. Qualität und Zuverlässigkeit beschreiben sehr ähnliche Schutzziele. Dabei spielen sowohl Aspekte der Verfügbarkeit als auch der Integrität eine Rolle. Ein informationsverarbeitendes System ist zuverlässig und qualitativ hochwertig, wenn es nicht ausfällt (Verfügbarkeit) und die Informationen richtig sind (Integrität). Resilienz beschreibt die Fähigkeit eines technischen Systems, bei einem Teilausfall nicht vollständig zu versagen. Robustheit, Belastbarkeit oder Widerstandsfähigkeit sind Begriffe, die »Resilienz« recht gut umschreiben. Resilienz ist auch ein spezieller Aspekt der Verfügbarkeit. Vorausschauend werden die Komponenten bei der Planung so gestaltet und dimensioniert, dass ein Teilversagen – gegebenenfalls auch nur mit verminderter Leistung – kompensiert werden kann. Ein Automotor ist resilient, wenn er beim Ausfall einer Zündkerze mit verminderter Leistung weiter läuft. Nach dem Austausch der Zündkerze ist die volle Leistung wieder da. Eine Fabrikhalle ist resilient, wenn Sie nach der Beschädigung eines Stützpfeilers durch einen Gabelstapler nicht einstürzt, da das Dach durch die anderen Pfeiler noch hinreichend getragen wird. Nach der Reparatur des beschädigten Pfeilers hat das Dach wieder die volle Belastbarkeit.

Kapitel 3

Bausteine der Informationssicherheit IN DIESEM KAPITEL Was ist ein Risiko? Was muss wann gemeldet werden? Was sind Sicherheitsstandards? Wie funktioniert ein Audit?

In den rechtlichen Vorgaben sowohl zur Informationssicherheit als auch zum Datenschutz finden Sie sehr ähnliche Strukturen. Sie können vier Bausteine herausarbeiten, die in den rechtlichen Vorgaben immer wieder auftauchen: Risikomanagement, zum Beispiel in § 8a Abs. 1 BSI-Gesetz, §§ 75b und 75c SGB V sowie Art. 25 und Art. 32 DS-GVO, Meldepflichten bei Vorfällen, zum Beispiel in § 8b Abs. 4 BSIGesetz, §§ 168 und 169 TKG, Art. 14 NIS-Richtlinie und Art. 33f DS-GVO, Einhaltung von Sicherheitsstandards, zum Beispiel in § 8, § 8a Abs. 2 und Abs. 5 BSI-Gesetz, §§ 75b und 75c SGB V, Art 16 NISRichtlinie sowie Art. 40 DS-GVO, Nachweis der Einhaltung durch Audits, zum Beispiel in § 8a Abs. 3 ff. BSI-Gesetz, §§ 75b und 75c SGB V, Art. 15 NISRichtlinie und Art. 41 f. DS-GVO.

Diese vier Bausteine werden uns auf lange Zeit begleiten und eine wichtige Basis für die Gestaltung der Informationssicherheit sein. Bei zukünftigen Novellierungen der einschlägigen Gesetze (zuletzt konnten Sie das bei der Novellierung des TKG im Jahr 2021 sehen) werden diese vier Bausteine weiter ausgebaut werden. Deshalb müssen wir uns mit ihnen im Folgenden eingehender beschäftigen.

Risikomanagement Am Anfang der Informationssicherheit und der technischorganisatorischen Maßnahmen im Datenschutz steht eine sorgfältige Analyse des Risikos. Bei einer Risikoanalyse werden Schwachstellen und Bedrohungen ermittelt. Dazu müssen Sie zuerst eine Gefährdungsübersicht erstellen. Im BSI-Standard 200-3 »Risikoanalyse auf der Basis von IT-Grundschutz« werden 47 elementare Gefährdungen der Schutzziele Vertraulichkeit, Verfügbarkeit und Unversehrtheit beschrieben. Es handelt sich sowohl um Naturgefahren wie Feuer und Wasser als auch um spezielle IT-Bedrohungen wie Verlust von ITGeräten, Schadsoftware und Social Engineering. Nehmen Sie diese Liste als Einstieg in eine Risikobewertung. Die Gefährdungen werden dann nach »direkt relevant«, »indirekt relevant« und »nicht relevant« klassifiziert. Eventuell identifizieren Sie auch noch eine oder mehre weitere Gefährdungen. Für die weitere Risikobetrachtung beschäftigen Sie sich nur noch mit den direkt relevanten Gefährdungen. Für jede direkt relevante Gefährdung erfolgt dann die Risikoeinstufung, indem Sie die resultierende Schadenshöhe für Ihr Unternehmen und die Eintrittswahrscheinlichkeit der Gefährdung betrachten. Bei der Klassifizierung von Schadenshöhe und Eintrittswahrscheinlichkeit sollten Sie nicht auf »Heller und Pfennig« den Schaden bestimmen, sondern nur mit so wenigen qualitativen Klassifizierungen wie möglich arbeiten. Nur dann ist die Klassifizierung in der Durchführung für Sie machbar. Mit diesem Argument sollten Sie eigentlich nur drei Klassen nehmen. Die Psychologie empfiehlt eine Einteilung in vier Klassen. Mehr Klassen sollten es aber auf keinen Fall sein.

Psychologie des Klassifizierens Bei der Bemessung von Schadenshöhe und Eintrittswahrscheinlichkeit sollten Sie nur so wenige Klassen wie möglich nutzen. Nur dann ist es für die Person, die die Klassifizierung durchführt, einfach. Damit bieten sich drei Klassen an. Nur kann sich in dem Fall die Person das Klassifizieren einfach machen und immer die mittlere Klasse wählen. Bei vier Klassen muss die Person sich immer für einen Trend nach oben oder unten entscheiden. Insofern ist von der Psychologie her eine Einteilung in vier Klassen besser. Mehr sollten es aber auf keinen Fall sein, um den Prozess nicht zu aufwendig zu gestalten. Die unterste Klasse darf auch keine diskriminierende Bezeichnung wie zum Beispiel »geringer Schutzbedarf« oder »kein Schutzbedarf« erhalten. Besser sind hier neutrale Begriffe wie »normaler Schutzbedarf«. Sie möchten Ihre eigenen Daten bei der Klassifizierung ja ungern als »wertlos« oder »minderwertig« einstufen.

Verwenden Sie für die Schadenshöhe die Begriffe »geringfügig«, »begrenzt«, »erheblich« und »existenzbedrohend« und für die Eintrittswahrscheinlichkeit die Begriffe »unwahrscheinlich«, »selten«, »häufig« und »sehr häufig«. Hinterlegt man die Begriffe jeweils mit den Werten 1 bis 4, so berechnen Sie das Risiko zu einem Wert zwischen 1 und 16. Teilen Sie die Werte in gering: 1 bis 2 mittel: 3 bis 6 hoch: 7 bis 10 sehr hoch: 11 bis 16 ein, erhalten Sie die Risikokarte in Abbildung 3.1. In dieser Risikokarte können Sie jetzt für Systeme aus Gefährdungen der Schutzziele die Risikoklasse bestimmen.

Abbildung 3.1: Das Risiko wird häufig als das Produkt aus Schadenshöhe und Eintrittswahrscheinlichkeit betrachtet.

In § 8a Abs. 1 BSI-Gesetz heißt es »Organisatorische und technische Vorkehrungen sind angemessen, wenn der dafür erforderliche Aufwand nicht außer Verhältnis zu den Folgen eines Ausfalls oder einer Beeinträchtigung der betroffenen Kritischen Infrastruktur steht.« Der Betreiber einer kritischen Infrastruktur muss also die Folgen eines ITSicherheitsvorfalls und den daraus folgenden Schaden betrachten. Das Risiko ergibt sich aus dem Schaden multipliziert mit der Wahrscheinlichkeit, dass das Schadensereignis eintritt. Der Schaden

wird aus der Sichtweise des Unternehmens beziehungsweise der Behörde ermittelt. Es ist sowohl der finanzielle als auch der ideelle Schaden, zum Beispiel eine Rufschädigung, zu betrachten. Sie müssen eine wichtige vertrauliche Arbeit erstellen. Sie erwarten, dass Sie etwa drei Monate daran arbeiten werden. Als sicherheitsbewusster Mensch haben Sie schon länger Bitlocker zur Festplattenverschlüsselung auf Ihrem Windows-Rechner installiert. Für Sie sind Vertraulichkeit und Verfügbarkeit die dominanten Schutzziele. Sie schätzen die Gefährdung, dass Sie Ihr Notebook verlieren oder dass es Ihnen gestohlen wird, als selten ein (Wert: 2). Schließlich ist es schon sechs Jahre alt. Der Schaden bezüglich der Vertraulichkeit ist bei Verlust geringfügig (Wert: 1), da Sie ja die Festplatte verschlüsselt haben. Das Risiko ist gering. Bei der Verfügbarkeit sieht es etwas anders aus. Die Wahrscheinlichkeit bleibt gleich, den Schaden stufen Sie aber in der höchsten Stufe (Wert: 4) ein, da dann alle Arbeit verloren ist. Hier ist das Risiko dann mittel (Wert: 4). Anders sieht es bezüglich der Verfügbarkeit bei einem Hardwaredefekt aus. Die Wahrscheinlichkeit dafür ist bei Ihrem sechs Jahre alten Notebook häufig. Der Schaden bleibt in der höchsten Stufe. Das Risiko ist , also ist das Risiko sehr hoch. Als Maßnahme zur Reduktion des Risikos entscheiden Sie sich doch schlussendlich für ein Backup. Dadurch sinkt der mögliche Schaden bei Verlust oder Defekt auf geringfügig (Wert: 1) und damit sinkt das Risiko der Verfügbarkeit bei Verlust auf gering (Wert: 1) beziehungsweise bei Defekt auf mittel (Wert: 3). Und mit so einem Risiko können Sie leben. Die DS-GVO gibt Ihnen in den Art. 25 und 32 eine völlig andere Perspektive der Risikobetrachtung vor: Es sind hier die »Risiken für die Rechte und Freiheiten natürlicher Personen« zu betrachten. Dies ist eine völlig andere Perspektive als in der Informationssicherheit: die Risikobetrachtung erfolgt ausschließlich aus der Sicht der Betroffenen und auf keinen Fall aus der Sicht des Unternehmens. Die falsche

Perspektive der Risikobetrachtung ist ein häufiger Fehler, den Verantwortliche begehen und der regelmäßig von Aufsichtsbehörden beanstandet wird. Die Landesbeauftragte für den Datenschutz in Niedersachsen führte 2019 eine branchenübergreifende Prüfung zur Umsetzung der DS-GVO bei 20 großen und 30 mittelgroßen niedersächsischen Unternehmen durch. Am Ende der Prüfung erhielten neun Unternehmen das Prädikat Grün, 32 Unternehmen das Prädikat Gelb und neun Unternehmen das Prädikat Rot. Bei allen neun Unternehmen mit dem Prädikat Rot wurden fehlende oder unzureichende technisch-organisatorische Maßnahmen, also unzureichende Informationssicherheit, beanstandet. Besonders gravierend fand die Landesbeauftragte auch die Tatsache, dass zum Teil bei der Risikobeurteilung der Fokus auf die Risiken für das Unternehmen und nicht, wie in der DS-GVO gefordert, auf die Risiken für die Rechte und Freiheiten der Betroffenen gelegt wurde. [LfDN19] Die Vorgaben zur Meldepflicht in Art. 33 f. der DS-GVO schreiben Ihnen für die Risikobewertung konkret drei Risikoklassen vor: »kein Risiko«, ein »Risiko« und ein »hohes Risiko«. In der Informationssicherheit wird dagegen, wie Sie gesehen haben, aus guten Gründen häufig mit vier Risikoklassen gearbeitet: »geringes Risiko«, »mittleres Risiko«, »hohes Risiko«und »sehr hohes Risiko«. Wenn Sie die gleichen Schemata bei der Risikobetrachtung in der Informationssicherheit und im Datenschutz verwenden wollen, bleibt Ihnen nichts anderes übrig, als in der Informationssicherheit mit drei Risikoklassen zu arbeiten. Für die Höhe und für die Häufigkeit des Eintritts eines Schadens können Sie aber weiterhin vier Kategorien verwenden. Die Bereiche mit einem sehr hohen Risiko müssen vorrangig behandelt werden. Durch geeignete Maßnahmen wird das Risiko vermindert. Vorrangig sollten Risiken vermieden werden. Unvermeidbare Risiken, die sich nicht durch technisch-organistorsiche Maßnahmen reduzieren

lassen, müssen delegiert (zum Beispiel an eine Versicherung) oder als Restrisiko getragen werden (siehe Abbildung 3.2). Die Entscheidung, welche Risiken delegiert und welche getragen werden, trifft letztendlich die Geschäftsleitung.

Abbildung 3.2: Durch die Risikostrategien Vermeiden, Reduzieren und Delegieren kann das Gesamtrisiko auf ein tragbares Restrisiko vermindert werden.

Eine Betrachtung der Risiken müssen Sie regelmäßig wiederholen, um eventuelle zwischenzeitlich veränderte Aspekte berücksichtigen zu können. Außerdem müssen Sie alle Überlegungen zu den Risiken dokumentieren, damit die Klassifizierungen und die daraus folgenden Entscheidungen jederzeit nachvollzogen werden können.

Meldepflichten bei Vorfällen Kommt es zu einem Datenschutz- oder IT-Sicherheitsvorfall, müssen Sie ab einer gewissen Schwelle die Vorfälle an die zuständigen Behörden melden. Im Bereich der kritischen Infrastruktur müssen Sie Sicherheitsvorfälle an das BSI melden. Bei Datenschutzvorfällen müssen Sie in Abhängigkeit vom Risiko die Datenschutzaufsichtsbehörden und bei einem hohen Risiko sogar die betroffenen Personen informieren.

Durch eine Unachtsamkeit beim Bearbeiten von eingehenden EMails kommt es in einer Arztpraxis zu einer SchadsoftwareInfektion. Alle Patientendaten werden durch die Schadsoftware verschlüsselt, um ein Lösegeld zu erpressen. Auch wenn die Schadsoftware keine Daten kopiert hat, handelt es sich um einen Datenschutzvorfall, da die Verfügbarkeit der Patientendaten nicht mehr gegeben ist. Sie müssen prüfen, ob der Vorfall meldepflichtig ist. Wenn es ein Backup gibt und die Praxis nach kurzer Zeit wieder voll funktionsfähig ist, besteht kein Risiko für die Patienten. Also muss der Vorfall zwar dokumentiert, aber nicht gemeldet werden. Wenn es kein Backup gibt, und alle Patientendaten damit verloren sind, entstünde ein hohes Risiko für die Patienten, da ihre Behandlungshistorie nicht mehr existiert. Deshalb müssen Sie in diesem Fall neben der Aufsichtsbehörde auch die Patienten informieren. Die Meldung muss nach dem BSI-Gesetz und dem TKG unverzüglich und im Fall von Datenschutzverstößen innerhalb von 72 Stunden erfolgen. Eine Nicht-Meldung ist bußgeldbewehrt. Wer einen Sicherheitsvorfall nach § 8a Abs. 4 BSI-Gesetz »vorsätzlich oder fahrlässig …nicht richtig, nicht vollständig oder nicht rechtzeitig« meldet, erhält ein Bußgeld bis zu fünfhunderttausend Euro. Wer einen Datenschutzvorfall nach Art 33 DS-GVO nicht meldet, muss mit »Geldbußen von bis zu zehn Millionen Euro oder im Fall eines Unternehmens von bis zu 2 % seines gesamten weltweit erzielten Jahresumsatzes des vorangegangenen Geschäftsjahrs« rechnen. Es gilt die jeweils höhere Grenze für die Festsetzung des Bußgelds. In Deutschland wird eine Öffnungsklausel der DS-GVO genutzt, sodass gegen Behörden und sonstige öffentliche Stellen kein Bußgeld verhängt wird (§ 43 Abs. 3 BDSG und vergleichbare Regelungen in den Landesdatenschutzgesetzen). Sofern eine öffentliche Stelle unter den Anwendungsbereich der EURichtlinie 2016/680 (das sind für die Verhütung, Ermittlung, Aufdeckung oder Verfolgung von Straftaten oder die Strafvollstreckung

zuständige Behörden) fällt, ist eine entsprechende Meldepflicht in § 65 BDSG geregelt. § 65 BDSG gilt für die entsprechenden Landesbehörden der Rechtspflege, soweit in den Landesdatenschutzgesetzen nichts anderes geregelt ist. Relativ neu ist die Meldepflicht nach § 168 TKG für ein Unternehmen, das ein »öffentliches Telekommunikationsnetz betreibt oder öffentlich zugängliche Telekommunikationsdienste erbringt«. Ein derartiges Unternehmen muss einen »Sicherheitsvorfall mit beträchtlichen Auswirkungen auf den Betrieb der Netze oder die Erbringung der Dienste« unverzüglich dem BSI sowie der Bundesnetzagentur (BNA) als für die Telekommunikation zuständige Aufsichtsbehörde mitteilen. In § 169 TKG ist eine Meldepflicht für die Erbringer öffentlich zugänglicher Telekommunikationsdienste im Fall der Verletzung des Schutzes personenbezogener Daten aufgenommen worden. Auch hier erfolgt die Meldung nicht nur an den Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI), wie bereits nach der DS-GVO erforderlich, sondern zusätzlich auch wieder an die Bundesnetzagentur. Im TKG wird sowohl für Sicherheitsvorfälle als auch für Datenschutzvorfälle der Inhalt der Meldepflicht detailliert festgelegt. Tabelle 3.1 zeigt eine Übersicht über den Inhalt der Meldepflichten im BSI-Gesetz, im TKG und in der DS-GVO. Zwei der Vorgaben beziehen sich auf IT-Sicherheitsvorfälle (§ 8b Abs. 4 BSI-Gesetz und § 168 Abs. 1 f. TKG) und zwei auf Datenschutzvorfälle (§ 169 Abs. 1 f. TKG und Art. 33 Abs. 3 DS-GVO). Die Tabelle zeigt, dass die Ausgestaltung der Meldepflicht in unterschiedlichen Gesetzen sehr unterschiedlich ist. Inhalt Meldepflicht

§ 8b BSIG

§ 168 TKG

§ 169 TKG

IT-Sicherheit

Datenschutz

Ausmaß

-

-

Zahl der betroffenen Personen

-

-

Art. 33 DSGVO

Beschreibung Vorfall -

Inhalt Meldepflicht

§ 8b BSIG

§ 168 TKG

§ 169 TKG

Art. 33 DSGVO

IT-Sicherheit

Datenschutz

-

-

-

-

-

-

-

geografische Ausdehnung

-

-

Ursache

-

-

Zahl der betroffenen Systeme betroffene Technik/Dienste Dauer des Vorfalls

-

Folgen

-

Maßnahmen

-

-

Kontakt für Nachfragen

-

-

Meldefrist

unverzüglich unverzüglich unverzüglich 72 Stunden

Meldestelle

BSI

BNA, BSI

BNA, BfDI

DS-Aufsicht

Tabelle 3.1: Die expliziten gesetzlichen Vorgaben für Unternehmen bezüglich der Meldepflicht eines IT-Sicherheits- beziehungsweise Datenschutzvorfalls.

Das BSI hat auf Basis des § 8b Abs. 4 ein siebenseitiges Meldeformular erstellt, das sehr detailliert die Einzelheiten eines Vorfalls (»Angaben zur Störung«) erhebt. Auch die Datenschutzaufsichtsbehörden haben Papieroder Web-Formulare zur Erhebung von meldepflichtigen Datenschutzverletzungen erstellt. Diese Formulare bieten Ihnen eine gute Orientierung für die Erstellung eigener, organisationsinterner Meldeformulare. Hierauf gehen wir in Kapitel 15 noch detailliert ein. Die Meldepflichten sollen den Druck auf Unternehmen und Behörden erhöhen, die Vorgaben auch ernst zu nehmen. Hinzu kommt, dass das BSI regelmäßig Lagebilder zur Situation der IT-Sicherheit in Deutschland erstellt. Auch hierzu werden Daten über Vorfälle benötigt. Der Austausch von Informationen zu Vorfällen kann bisher nicht betroffenen Unternehmen helfen, sich selber besser aufzustellen. Der Austausch und das Voneinander-Lernen sind ein wesentlicher Aspekt der

Verbesserung der Informationssicherheit, auf den wir im Kapitel 15 ausführlich eingehen. Im Rahmen der Evaluierung der NIS-Richtlinie war die Europäische Kommission unzufrieden mit der Bandbreite der Umsetzungen der Meldepflicht in den verschiedenen Mitgliedsländern. Unternehmen, die in Ländern mit weniger stringenten Vorgaben ansässig sind, haben Wettbewerbsvorteile, da die weniger aufwendigen Meldevorgaben weniger Kosten verursachen. Unternehmen, die in mehreren Mitgliedsländern tätig sind, müssen die unterschiedlichen Meldepflichten beachten und haben dadurch Nachteile. Insofern will die Kommission die Vorgaben zur Meldepflicht stringenter fassen und damit vereinheitlichen.

Einhaltung von Sicherheitsstandards Einzuhaltende Sicherheitsstandards werden vorgegeben, damit für Ihr Unternehmen oder Ihre Behörde zweifelsfrei klar ist, welche ITSicherheitsregeln eingehalten werden müssen. Die gesetzlichen Vorgaben sind sehr knapp und abstrakt, damit sie nicht zu häufig an technische Entwicklungen angepasst werden müssen. Zur Konkretisierung werden sowohl im BSI-Gesetz (§ 8a Abs. 2) als auch in der DS-GVO (Art. 40 Abs. 2 lit. h) branchenspezifische ITSicherheitsstandards (kurz B3S) vorgesehen. Diese Standards müssen vom BSI beziehungsweise den Datenschutzaufsichtsbehörden genehmigt werden. Das BSI bezieht sich bei Vorgaben natürlich gerne auf seinen eigenen Standard, den IT-Grundschutz (siehe Kapitel 8). Die DS-GVO schreibt in Art 40 Abs. 4 DS-GVO vor, dass die Standards (in der deutschen Fassung der DS-GVO unglücklich »Verhaltensregeln« genannt) zwingend Regelungen zur »obligatorischen Überwachung der Einhaltung ihrer Bestimmungen durch die Verantwortlichen oder die Auftragsverarbeiter, die sich zur Anwendung der Verhaltensregeln verpflichten« enthalten müssen. Die Verhaltensregeln können neben dem

technisch-organisatorischen Vorgehen auch die rechtlichen Rahmenbedingungen für die Verarbeitung personenbezogener Daten konkretisieren und gestalten. Eine Verhaltensregel zur IT-Sicherheit und zum technisch-organisatorischen Datenschutz sollte unabhängig von den anderen materiell-rechtlichen Regelungsbereichen sein. Dadurch werden die Zeitskalen für erforderliche Aktualisierungen getrennt. Technik entwickelt sich im Allgemeinen schneller als rechtliche Vorgaben. Mit dem § 75b wurde Ende 2019 eine Vorschrift zur Sicherstellung der IT-Sicherheit in ärztlichen, psychotherapeutischen und zahnärztlichen Praxen in das SGB V aufgenommen. Danach müssen von den Kassenärztlichen Bundesvereinigungen »Richtlinien zur IT-Sicherheit in der vertragsärztlichen und vertragszahnärztlichen Versorgung« erstellt werden. Diese wörtlich identischen Richtlinien sind Anfang 2021 in Kraft getreten. Der etwas später in das SGB-V eingefügte § 75c macht Vorgaben zur ITSicherheit in Krankenhäusern, die nicht unter die KRITIS-Regeln fallen (das sind kleinere Krankenhäuser mit weniger als 30.000 stationären Aufnahmen pro Jahr). Diese Vorgaben müssen seit dem 1. Januar 2022 von den kleineren Krankenhäusern eingehalten werden. Damit sind im medizinischen Bereich rechtliche Vorgaben zur ITSicherheit von der kleinsten Praxis bis zum größten Universitätsklinikum vorhanden. Die Vorgaben sind nicht einheitlich und leider über zwei Gesetze verteilt. Auf Dauer ist es nicht sinnvoll, die rechtlichen Vorgaben zur IT-Sicherheit in branchenspezifische Spezialgesetze wie zum Beispiel das SGB V zu schreiben. Es ist besser, wie auch im Datenschutz, sie in einem Gesetz branchenübergreifend zu bündeln. Neuere Gesetze (zum Beispiel das TKG) werden in ihren Vorgaben deutlich konkreter. Im Bereich Telekommunikation kann die Bundesnetzagentur in Abstimmung mit dem BSI und dem Bundesbeauftragten für Datenschutz und Informationsfreiheit einen »Katalog von Sicherheitsanforderungen für das Betreiben von Telekommunikations- und Datenverarbeitungssystemen sowie für die Verarbeitung personenbezogener Daten« (§ 167 TKG) festlegen. Falls

Sie sich wundern, dass die Datenschutzaufsichtsbehörden der Länder außen vor sind: Die Datenschutzaufsicht im Telekommunikationsbereich ist schon länger beim BfDI angesiedelt. Für Betreiber öffentlicher Telekommunikationsnetze und Anbieter öffentlich zugänglicher Telekommunikationsdienste empfiehlt das TKG den Einsatz von Systemen zur Angriffserkennung (Intrusion Detection Systems). Für TK-Betreiber mit erhöhtem Gefährdungspotenzial werden Systeme zur Angriffserkennung ab dem 1. Dezember 2022 zwingend vorgeschrieben (§ 165 Abs. 3 in Verbindung mit § 230 Abs. 12 TKG). Welche Unternehmen TK-Betreiber mit erhöhtem Gefährdungspotenzial sind, wird von der Bundesnetzagentur durch eine Allgemeinverfügung festgelegt. Die Tatsache, dass in einem Gesetz derart konkrete Sicherheitsmaßnahmen vorgeschrieben werden, ist ungeschickt. Die konkreten Vorgaben sollten durch Verordnungen oder Allgemeinverfügungen geregelt werden. Das Gesetz sollte nur die Ermächtigung zum Erlass der konkreten Regeln enthalten. Je konkreter eine Vorgabe ist, je häufiger muss sie an technische Entwicklungen angepasst werden. Dieser Anpassungsprozess ist bei Gesetzen zu aufwendig und zu langwierig. Trotzdem müssen Sie sich, wenn Sie in den entsprechenden Branchen tätig sind, mit der rechtlichen Situation arrangieren.

Nachweis der Einhaltung durch Audits Bei einem Audit unterziehen ein oder mehrere Prüfer den Prüfgegenstand einer systematischen Prüfung. Der Prüfer muss für diesen Prüfvorgang zugelassen (zertifiziert) sein. Die Zertifizierung des Prüfers setzt den Nachweis des erforderlichen Fachwissens voraus, das durch eine Ausbildung und praktische Erfahrung erworben wird. Die Details für die Ausbildung und Prüfung sowie die Zulassung sind detailliert geregelt.

Wenn Sie sich als Auditor zertifizieren lassen wollen, müssen Sie zuerst ein Verfahren zur Überprüfung Ihrer Fachkunde (Kompetenzfeststellung) erfolgreich durchlaufen. Danach folgt die dreijährige Zertifizierungsphase. Das BSI beobachtet Sie bei der Ausübung Ihrer Tätigkeit. Bei Kompetenzmängeln oder Verstößen gegen Auditregeln kann das BSI Ihr Zertifikat vorzeitig widerrufen. Nach Ablauf der Zertifizierungsphase ist eine Rezertifizierung möglich und üblich. Ähnlich wie Piloten, die zum Erhalt ihrer Fluglizenz regelmäßig Flugstunden absolvieren müssen, müssen Sie als Auditor während der Zertifizierungsphase auch regelmäßig Audits durchführen. [BSI19b] Im BSI-Gesetz ist geregelt, dass das BSI die »Ausgestaltung des Verfahrens der Sicherheitsaudits, Prüfungen und Zertifizierungen« und die »Anforderungen an die Art und Weise der Durchführung, an die hierüber auszustellenden Nachweise sowie fachliche und organisatorische Anforderungen an die prüfende Stelle nach Anhörung von Vertretern der betroffenen Betreiber und der betroffenen Wirtschaftsverbände« festlegt (§ 8a Abs. 5). In der DS-GVO erfolgt die Zulassung der Zertifizierungsstellen durch die DatenschutzAufsichtsbehörden. In anderen Bereichen gibt es entsprechende Regelungen. Die in den Anwendungsbereich des BSI-Gesetzes fallenden Unternehmen müssen alle zwei Jahre durch Audits nachweisen, dass sie die IT-Sicherheitsvorgaben einhalten. Hierzu müssen die Audit-Berichte externer zertifizierter Prüfer dem BSI vorgelegt werden. Auch die DS-GVO sieht Audits, hier Zertifizierungen genannt, als hilfreich an. Verantwortliche Stellen sollen sich freiwillig zertifizieren lassen, um nachzuweisen, dass sie alle datenschutzrechtlichen Vorgaben einhalten. Die DS-GVO sieht vor, dass eine Zertifizierung für maximal drei Jahre gültig sein darf. Die Zertifizierung kann sowohl von der Zertifizierungsstelle als auch von den Aufsichtsbehörden vorzeitig widerrufen werden. Bei der Anerkennung der Zertifizierung ist die DS-GVO sehr vorsichtig. »Die Einhaltung genehmigter Verhaltensregeln gemäß Artikel 40 oder eines genehmigten Zertifizierungsverfahrens gemäß Artikel 42 kann als

Faktor herangezogen werden, um die Erfüllung der in Absatz 1 des vorliegenden Artikels genannten Anforderungen nachzuweisen.« Muss ein Unternehmen die Einhaltung der Sicherheit der Verarbeitung nach Art. 32 DS-GVO der Aufsichtsbehörde nachwiesen, ist die Zertifizierung ein Anhaltspunkt für die Einhaltung der Vorgaben. Theoretisch kann sich ein Unternehmen auch freiwillig auditieren lassen. Dies ist aber wegen des damit verbundenen Aufwands nur üblich, wenn damit gegenüber den Kunden wettbewerbliche Vorteile möglich sind, also letztendlich die Vorteile den Aufwand rechtfertigen. Ein Audit läuft in vier wesentlichen Stufen ab: Festlegung des räumlichen und sachlichen Prüfgegenstands, Prüfung der Dokumentation (Soll-Zustand), Vor-Ort Prüfung der Umsetzung (Ist-Zustand) durch Interviews und Begehungen, Präsentation der Ergebnisse und Maßnahmenempfehlungen. Sie wählen einen IT-Sicherheits-Dienstleister, der für den Audit-Zweck, den Sie anstreben, zugelassen ist. Wenn Sie als Unternehmen des KRITIS-Bereichs regelmäßig ein Audit machen müssen, wählen Sie einen Dienstleister, der hierzu zugelassen und anerkannt ist. Das dafür erforderliche Verfahren ist seitens des BSI detailliert geregelt und dokumentiert. Der Zweck eines Audits wird zu Beginn des Audits vom Auftraggeber definiert. Dazu legen Sie fest, welcher Teil des Unternehmens auditiert werden soll. Es macht keinen Sinn das gesamte Unternehmen zu auditieren, da das viel zu aufwendig ist. Je nach Zweck des Audits lassen Sie die Kundendatenverarbeitung, den Forschungs- und Entwicklungsbereich oder einen anderen Unternehmensbereich auditieren. Das entscheiden Sie auf Basis Ihres Bedarfs oder der externen Anforderungen. Die Auditoren werden zuerst die Dokumentation zur IT-Sicherheit, also den Soll-Zustand prüfen. Dabei wird die Dokumentation auch auf

Vollständigkeit und Sinnhaftigkeit geprüft. Wenn die Auditoren die ITSicherheitsorganisation und die technischen IT-Sicherheitsstrukturen in Ihrem Unternehmen verstanden haben, werden die Auditoren vor Ort durch Begehungen und Interviews mit den Beteiligten überprüfen, ob die Papierform mit der tatsächlichen Situation übereinstimmt. Sie wissen ja, Papier ist geduldig. Selbst wenn Sie als Buchhalterin oder Sachbearbeiter im Unternehmen arbeiten, kann es Ihnen passieren, dass ein Auditor mit Ihnen spricht. Dabei geht es um so einfache Fragen wie: »Kennen Sie die ITSicherheitsregeln? Wie wurden Sie damit vertraut gemacht? Verschlüsseln Sie Ihre E-Mail? Klappt das reibungslos?« – Denn was nutzen die besten Regeln, wenn die Nutzerinnen sie nicht kennen? Auch wenn die Umsetzung so kompliziert für die Nutzerinnen ist, dass »kreative Workarounds« gefunden werden, ist das wichtig für die Auditoren. Diese wollen ein echtes Bild der Situation im Unternehmen und keinen Hochglanzprospekt. Aus alle Erkenntnissen wird dann ein Abschlussbericht erstellt, der mit dem Unternehmen besprochen wird. Dabei geht es aber nicht nur um Kritik im Sinne einer Aufzählung, was alles falsch läuft. Es geht auch um eine Strategie zur Verbesserung der IT-Sicherheit. Welche Maßnahmen sind jetzt erforderlich? Bis wann sollten diese umgesetzt sein? Was ist eine sinnvolle Priorisierung für die Umsetzung der verschiedenen Maßnahmen? Gute Auditoren helfen Ihnen mit ihren Hinweisen und Empfehlungen, besser zu werden. Bei der Präsentation des Abschlussberichts und der daraus folgenden Diskussion der zu ergreifenden Maßnahmen muss die Geschäftsleitung dabei sein. Auch wenn Sie der Meinung sind, die Geschäftsleitung kennt das alles, weil Sie es schon oft genauso gesagt haben. Denken Sie daran, in der Regel gilt der Prophet nichts im eigenen Land. Wenn das Ergebnis von einem externen Experten vorgestellt wird, hört Ihre Geschäftsführung höchstwahrscheinlich eher darauf. Und dann haben Sie etwas erreicht.

Damit Sie im Unternehmen einen möglichst vorurteilsfreien Blick auf die IT-Sicherheit erhalten, empfiehlt es sich, von Zeit zu Zeit das (interne) Auditoren-Team zu wechseln. Irgendwann werden die Auditoren betriebsblind, weil sie nur noch die Umsetzung ihrer eigenen Empfehlungen aus dem letzten Audit prüfen. Ein neues Auditoren-Team bringt neue Blickwinkel und frischen Wind in das Audit. Das wird zu Ihrem Vorteil sein. Schließlich wollen Sie ja die IT-Sicherheit verbessern.

Kapitel 4

Datenschutz und technischorganisatorische Maßnahmen IN DIESEM KAPITEL Die Vorgaben von Artikel 32 DS-GVO Schutzziele der DS-GVO Die Betroffenen stehen im Mittelpunkt

Die DS-GVO verlangt in Art. 32 Abs. 1 von der verantwortlichen Stelle technisch-organisatorische Maßnahmen (TOM), um den Datenschutz zu gewährleisten. »Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten; diese Maßnahmen schließen gegebenenfalls unter anderem Folgendes ein: a) die Pseudonymisierung und Verschlüsselung personenbezogener Daten; b) die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung auf Dauer sicherzustellen;

c) die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen; d) ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung.« Art. 32 Abs. 1 Datenschutz-Grundverordnung

Im ersten Halbsatz des Absatzes finden Sie eine Vorgabe zu den vier Kriterien, die die verantwortliche Stelle abwägen muss. Im Grunde ist es die detaillierte Ausgestaltung des Erforderlichkeitsprinzips, das im BDSG alter Fassung noch als »erforderlich sind Maßnahmen nur, wenn ihr Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht.« (§ 9 BDSG a. F.) formuliert wurde. Bei dieser Abwägung sollen Sie die folgenden Aspekte berücksichtigenden: Stand der Technik (state of the art), Implementierungskosten (cost of implementation), Art, Umfang, Umstände und Zwecke der Verarbeitung (nature, scope, context and purposes of processing), Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen (risk of varying likelihood and severity for the rights and freedoms of natural persons). In der Aufzählung der Maßnahmenkategorien im Gesetz werden beispielhaft und keineswegs abschließend einige technische Maßnahmen zum Schutz der Rechte und Freiheiten der Betroffenen genannt. Wie immer, wenn eine Reihenfolge in einem Gesetz vorgegeben ist, dürfen Sie nicht davon ausgehen, dass die Reihenfolge der Maßnahmen eine Priorisierung darstellt. Leider trifft man in der Praxis häufig Datenschutzbeauftragte, die dieser Meinung sind. Dann wird auch noch die Pseudonymisierung als erste Maßnahme genannt und dann prompt von vielen als die wichtigste und primär anzuwendende

Schutzmaßnahme angesehen. In Kapitel 10 werden wir sehen, dass eine gute Pseudonymisierung durchaus schwierig ist. In Kapitel 3 haben wir gelernt, dass das Risiko sich aus der Schadenshöhe und der Eintrittswahrscheinlichkeit ergibt. Deshalb macht die Formulierung »unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos« in Art. 32 DS-GVO wenig Sinn. In Art. 32 Abs. 1 ist als Schutzziel bei Vorfällen die Vermeidung von Beeinträchtigungen der Rechte und Freiheiten natürlicher Personen festgelegt. Sie müssen im Datenschutz die Risikobetrachtung nicht aus der Sicht des Unternehmens, sondern aus der Sicht der Betroffenen machen. Zu den klassischen Schutzzielen IT-Sicherheit, Vertraulichkeit, Integrität und Verfügbarkeit kommt noch die Belastbarkeit hinzu. In der englischen Version der DS-GVO (quasi der Originalversion, da in dieser Sprache der Text verhandelt wurde) finden Sie die Formulierung »resilience of processing systems and services«. In der NIS-Richtlinie wird in dem Erwägungsgrund 13 die Formulierung »resilience of network and information systems« mit »Robustheit von Netz- und Informationssystemen« übersetzt. Diese Übersetzung dürfte näher an dem beabsichtigten Schutzziel liegen. Im Entwurf der »Richtlinie über die Resilienz kritischer Einrichtungen« der Europäischen Kommission wurde »resilience« mit »Widerstandsfähigkeit« übersetzt. IT-Systeme müssen eine gewisse Widerstandsfähigkeit gegen Störungen aufweisen, damit sie bei einem Vorfall nicht sofort ausfallen oder versagen. Im Grunde ist dies ein spezieller Teilaspekt der Verfügbarkeit. Einige Fachleuten vertreten auch die Meinung, dass damit die »Business Continuity« gemeint ist. Die Unternehmen und Organisationen sollen die IT so betreiben, dass die Geschäftsprozesse stabil laufen und Störungen der IT abgefangen werden können, ohne dass die Geschäftsprozesse beeinflusst werden. Unter Buchstabe c des Art. 32 Abs. 1 werden Maßnahmen zum schnellen Wiederanlauf der IT – und damit der schnellen Wiederherstellung der Verfügbarkeit – nach Störungen gefordert. Auch dies ist ein Teilaspekt der Verfügbarkeit.

Ein wichtiger und in der bisherigen Datenschutzregulierung nicht ganz neuer Aspekt ist die »regelmäßige Überprüfung, Bewertung und Evaluierung der IT-Sicherheitsmaßnahmen«. Gerade vor dem Hintergrund sich ständig weiter entwickelnder IT und einer sich verändernden Risikolage ist eine regelmäßige Neubewertung sinnvoll und geboten. In einem Unternehmen wurden Chipkarten zur Anmeldung am PC eingeführt. Jeder PC wurde mit einen Chipkartenleser erweitert und alle Beschäftigten erhielten je eine personalisierte Chipkarte. Eine Dienstanweisung gab vor, dass beim Verlassen des Arbeitsplatzes die Chipkarte gezogen und mitgenommen werden muss. Das Ziehen der Chipkarte aktivierte den Bildschirmschoner und sperrte so den PC. Nach 6 Monaten wurde eine Evaluierung vorgenommen. Bei einer Begehung der Arbeitsplätze außerhalb der Arbeitszeit wurde festgestellt, dass bei fast 60 % der PCs entgegen der Dienstanweisung die Chipkarte im Leser steckte, ob wohl die Nutzerin des PCs nicht im Raum war. Bei einer weiteren Stichprobe ein paar Wochen später während der Mittagspause wurde zufällig herausgefunden, dass in zwei Bereichen die Beschäftigten sich auf ein »Bereichspasswort« geeinigt hatten, sodass jeder jederzeit an jedem PC im Bereich arbeiten konnte. Sie sehen: Die Evaluierung deckt manchmal auch Mängel in der organisatorischen Umsetzung der Nutzung der technischen Sicherheitsmaßnahmen auf. Eine Evaluierung kann auch mit technischen Mitteln durchgeführt werden. Mit geeigneter Prüfsoftware können Sie regelmäßig die Aktualität der technischen Implementierung von Sicherheitsmaßnahmen überprüfen. Gerade wenn die IT-Technik dezentral implementiert wird, die Verantwortung für Datenschutz und Informationssicherheit aber zentral ist, sind derartige Überprüfungen sinnvoll.

Natürlich können je nach den Umständen des IT-Einsatzes weitere Maßnahmen erforderlich sein. In einem größeren Netzwerk ist ein System zur Angriffserkennung (Intrusion Detection System, IDS), also zur kontinuierlichen und frühzeitigen Erkennung von Hackerattacken, sinnvoll und in bestimmten Branchen für einige Unternehmen (kritische Infrastruktur ab 1. Mai 2023, § 8a Abs. 1a BSI-Gesetz und Anbieter öffentlich zugänglicher Telekommunikationsdienste ab 1. Dezember 2022, § 165 Abs. 3 TKG) sogar gesetzlich vorgeschrieben. Im Artikel 25 der DS-GVO finden Sie noch eine neue Sicht auf die technisch-organisatorischen Maßnahmen. Der etwas sperrige deutsche Titel des Artikels ist »Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen«. Im englischen können wir das etwas knackiger formulieren: »Privacy by Design« und »Privacy by Default«. Sie müssen als Betreiber bereits zum »Zeitpunkt der Festlegung der Mittel für die Verarbeitung« den technischorganisatorischen Datenschutz gestalten. Diese etwas abstrakte Formulierung bedeutet, dass Sie datenschutzfreundliche Software oder IT-Systeme auswählen müssen. In Erwägungsgrund 78 der DS-GVO wird dies deutlich: »In Bezug auf Entwicklung, Gestaltung, Auswahl und Nutzung von Anwendungen, Diensten und Produkten, die entweder auf der Verarbeitung von personenbezogenen Daten beruhen oder zur Erfüllung ihrer Aufgaben personenbezogene Daten verarbeiten, sollten die Hersteller der Produkte, Dienste und Anwendungen ermutigt werden, das Recht auf Datenschutz bei der Entwicklung und Gestaltung der Produkte, Dienste und Anwendungen zu berücksichtigen und unter gebührender Berücksichtigung des Stands der Technik sicherzustellen, dass die Verantwortlichen und die Verarbeiter in der Lage sind, ihren Datenschutzpflichten nachzukommen.« Sie sehen, der europäische Gesetzgeber will die Hersteller in die Richtung von datenschutzfreundlichen Produkten pushen. Für die Verantwortlichen im Unternehmen heißt dies, dass bereits die Produktauswahl unter technisch-organisatorischen Datenschutzaspekten zu treffen und zu dokumentieren ist. Sie müssen sowohl die Datenschutzgrundsätze wie Datenminimierung, Intervenierbarkeit (Löschen, Korrektur), Zweckbindung und

Transparenz als auch die Schutzziele der IT-Sicherheit wie Verfügbarkeit, Vertraulichkeit und Integrität bei Produkt- und Dienstleiterauswahl berücksichtigen. Die gerade erwähnten Datenschutzgrundsätze betrachten wir noch ausführlicher in Kapitel 5.

Teil II

Rechtliche Anforderungen

IN DIESEM TEIL … Der europäische und der deutsche Gesetzgeber regeln in immer mehr Gesetzen und Verordnungen die Anforderungen an die Informationssicherheit und den Datenschutz. Dabei finden wir in der Datenschutzgesetzgebung auch starke Anforderungen an die IT-Sicherheit, indem technisch-organisatorische Maßnahmen vorgegeben werden. Unternehmen müssen sich darum, ob sie wollen oder nicht, mit der Informationssicherheit beschäftigen. Sie lernen in den folgenden Kapiteln die rechtlichen Vorschriften und deren Vorgaben kennen. Je nach Branche gibt es sehr unterschiedliche Anforderungen für Ihr Unternehmen.

Kapitel 5

Die DS-GVO und das BDSG IN DIESEM KAPITEL Forderungen der DS-GVO und des BDSG zur IT-Sicherheit Was ist Stand der Technik? Schutzziele des Datenschutzes

Wie Sie schon gesehen haben, verlangt die DS-GVO in Artikel 32 Abs. 1 technisch-organisatorische Maßnahmen nach dem Stand der Technik. In Ihr Verzeichnis der Verarbeitungstätigkeiten (VVT) müssen Sie »eine allgemeine Beschreibung der technischen und organisatorischen Maßnahmen gemäß Artikel 32 Absatz 1« aufnehmen (Art. 30 Abs. 1 lit. g DS-GVO). Auch in den Verträgen zur »Gemeinsamen Verantwortlichkeit« (Art. 26 DS-GVO) und zur »Verarbeitung im Auftrag« (Art. 28 DS-GVO) müssen Sie geeignete technische und organisatorische Maßnahmen festlegen. Damit Sie nicht jedes Mal von vorn beginnen müssen, sollten Sie dabei immer die gleiche Strukturierung verwenden. Wir wollen uns im Folgenden eine geeignete Strukturierung überlegen.

Die acht Gebote des Datenschutzes (BDSG a. F.) Im BDSG a. F. (gültig bis 24. Mai 2018) gab es die Anlage zu § 9, in der die Schutzziele der technisch-organisatorischen ITSicherheitsmaßnahmen vorgegeben wurden. Diese Schutzziele können als Strukturelemente zur Gliederung der konkreten Maßnahmen verstanden werden. Bei einer Ablage der Papierdokumente in einem

Ordner würden Sie diese Begriffe zur Beschriftung der Trennblätter verwenden. Sie bilden das Inhaltsverzeichnis oder die Struktur der Maßnahmen. Dies waren im Einzelnen die Schutzziele: 1. »Zutrittskontrolle: Unbefugten muss der Zutritt zu Datenverarbeitungsanlagen, mit denen personenbezogene Daten verarbeitet oder genutzt werden, verwehrt werden. 2. Zugangskontrolle: Es muss verhindert werden, dass Datenverarbeitungssysteme von Unbefugten genutzt werden können. 3. Zugriffskontrolle: Es ist zu gewährleisten, dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können und dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können. 4. Weitergabekontrolle: Es ist zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können und dass überprüft und festgestellt werden kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Datenübertragung vorgesehen ist. 5. Eingabekontrolle: Es ist zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind. 6. Auftragskontrolle: Es ist zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können. 7. Verfügbarkeitskontrolle: Es ist zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust geschützt sind.

8. [Trennungskontrolle]: Es ist zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können.« Bereits im ersten BSDG von 1977 (BGBl. I S. 201) war eine Version der – damals noch – zehn Gebote des Datenschutzes in einer Anlage enthalten. Diese waren noch am klassischen Rechenzentrumsbetrieb mit Großrechnern und an konkreter Technik orientiert. Es herrschte die Vorstellung, dass personenbezogene Daten gut geschützt waren, wenn sie in einem Rechenzentrum verarbeitet werden, das Unbefugte nicht betreten durften. So waren zum Beispiel die getrennten Punkte der Abgangskontrolle (unberechtigtes Entfernen von Datenträgern) und der Transportkontrolle (Schutz von Datenträgern beim Transport) enthalten. Datentransfer über das Internet, wie wir ihn heute kennen, gab es 1977 noch nicht. Der Transport von Daten war der Transport von Datenträgern. Dies ist seit 2001 im BDSG (BGBl. I S. 904) aktualisiert und unter »Weitergabekontrolle« zusammengefasst worden. Im Zeitalter von Cloud-Computing ist die damals zugrundeliegende Vorstellung des ersten BDSG von zentraler Datenverarbeitung im Rechenzentrum wirklich nicht mehr realistisch. Diese Kontrollen orientieren sich im Wesentlichen am Verarbeitungsbegriff und damit am Lebenszyklus der Daten des alten BDSG: Daten werden erfasst (= eingegeben), verändert, übermittelt, verarbeitet und gelöscht. Gerade mit den ersten drei Kontrollen werden Maßnahmen in einem Schalenmodell der Annäherung an die Daten beschrieben. Die Zutrittskontrolle soll verhindern, dass Unbefugte zu den Rechnern vordringen können. Die Zugangskontrolle soll sicherstellen, dass jemand, der zwar zu den Rechnern darf, sich aber nicht an den Rechnern anmelden soll, das auch nicht kann. Für Personen, die an den Rechnern zum Beispiel auf Betriebssystemebene arbeiten, muss sichergestellt werden, dass sie nicht an die Daten kommen. Die Kontrollen der Anlage zu § 9 BDSG a. F. »leben« in Form von 14 Kontrollen im § 64 Abs. 3 BDSG fort. Dieser Teil des BDSG gilt allerdings nur für bestimmte Behörden, die für die Verhütung,

Ermittlung, Aufdeckung, Verfolgung oder Ahndung von Straftaten oder Ordnungswidrigkeiten zuständig sind. Die Begriffe »Zutritt«, »Zugang« und »Zugriff« werden im Englischen einheitlich mit »Access« übersetzt. Um auch in englischen Dokumenten die Abstufung zu erreichen, sollten die Übersetzungen »physical access « (eventuell auch »equipment access«), »logical access« und »data access« verwendet werden. Die DS-GVO regelt die Informationssicherheit im Art. 32 sehr viel abstrakter, aber auch näher an den klassischen Schutzzielen Vertraulichkeit, Verfügbarkeit und Integrität der Informationssicherheit (siehe Kapitel 2).

Stand der Technik Im Art. 32 DS-GVO taucht der Begriff »Stand der Technik« auf. Dies ist die aktuelle Messlatte für die Qualität von IT-Sicherheitsmaßnahmen. Den Begriff »Stand der Technik« finden Sie aber auch in zahlreichen anderen rechtlichen Regelungen. Neben der DS-GVO kommt er zum Beispiel noch in diesen Rechtsvorschriften vor: § 8a Abs. 1. BSI-Gesetz: »… Dabei soll der Stand der Technik eingehalten werden …« § 75b Abs. 3 SGB V: »… festzulegenden Anforderungen müssen dem Stand der Technik entsprechen …« § 75c Abs. 1 SGB V:»… nach dem Stand der Technik angemessene organisatorische und technische Vorkehrungen …« § 165 Abs. 1 TKG:»… Dabei ist der Stand der Technik zu berücksichtigen …« und Abs. 2 »… Bei diesen Maßnahmen ist der Stand der Technik zu berücksichtigen …« § 6 Abs. 2 TTDSG: »…Soweit es im Hinblick auf den angestrebten Schutzzweck erforderlich ist, sind die Maßnahmen dem jeweiligen Stand der Technik anzupassen …«

§ 19 Abs. 4 TTDSG: »… Vorkehrungen nach Satz 1 müssen den Stand der Technik berücksichtigen …« Art. 14 Abs. 1 und Art. 16 Abs. 1 NIS-Richtlinie: »… Diese Maßnahmen müssen unter Berücksichtigung des Stands der Technik ein Sicherheitsniveau der Netz- und Informationssysteme gewährleisten, das dem bestehenden Risiko angemessen ist …« Art. 52 Abs. 7 CyberSecurity-Verordnung: »… die erforderlichen Sicherheitsfunktionen entsprechend dem neuesten Stand der Technik ordnungsgemäß durchführen …« In den Formulierungen sehen Sie auch die unterschiedliche Intensität der gesetzlichen Forderung. Es ist ein Unterschied, ob der Stand der Technik »berücksichtigt« oder »eingehalten« werden muss. Vor allem müssen wir uns diese Frage stellen: Was ist eigentlich der »Stand der Technik«? Diese Frage wurde vom Bundesverfassungsgericht bereits 1978 in der sogenannten »Kalkar-Entscheidung« (Kalkar I, BVerG 49, 89) aufgegriffen. Nach der von Breuer [Bre76] 1976 entwickelten und vom Bundesverfassungsgericht angewandten Drei-Stufen-Theorie kann auf die folgenden drei Stufen der erforderlichen technischen Maßnahmen zurückgegriffen werden: »allgemein anerkannte Regeln der Technik«, »Stand der Technik« und »Stand von Wissenschaft und Technik«.

Im allgemeinen Sprachgebrauch reden wir häufig vom »Stand von Wissenschaft und Forschung«. Das Bundesverfassungsgericht hat aber tatsächlich den Begriff »Stand von Wissenschaft und Technik« verwendet. Da es hier um die Technikgestaltung geht, macht das Sinn. »Durch die Verwendung unbestimmter Rechtsbegriffe werden die Schwierigkeiten der verbindlichen Konkretisierung und der laufenden Anpassung an die wissenschaftliche und technische Entwicklung mehr

oder weniger auf die administrative und – soweit es zu Rechtsstreitigkeiten kommt – auf die judikative Ebene verlagert. Behörden und Gerichte müssen mithin das Regelungsdefizit der normativen Ebene ausgleichen.«, schreibt das Bundesverfassungsgericht in seinem Beschluss (RdNr. 104; die Randnummern beziehen sich auf die Kalkar-Entscheidung des Bundesverfassungsgerichts). Als Informationssicherheits- oder Datenschutzbeauftragter ist es Ihre Aufgabe, diese unbestimmten Rechtsbegriffe im Unternehmen mit Leben zu füllen, denn die Formulierung des Bundesverfassungsgerichts gilt auch für Unternehmen. Auch Unternehmen müssen die Regelungsdefizite des Gesetzgebers ausgleichen. Die Entscheidung des Bundesverfassungsgerichts gibt dabei eine Orientierung. Das sollten Sie übrigens nicht nur negativ sehen. Die Alternative wäre eine detaillierte Technikgestaltung durch den Gesetzgeber und damit eine Einschränkung der Gestaltungsmöglichkeiten der Unternehmen. Den unbestimmten Rechtsbegriff »allgemein anerkannte Regeln der Technik« finden Sie erstmalig im § 3 Abs. 1 des Gesetzes über technische Arbeitsmittel (Maschinenschutzgesetz; mittlerweile außer Kraft) von 1968. Der Rechtsbegriff ist außerdem im Baurecht üblich. Hier gibt es sogar den Straftatbestand der »Baugefährdung« (§ 319 StGB), wenn die »Planung, Leitung oder Ausführung eines Baues oder des Abbruchs eines Bauwerks« nicht den allgemein anerkannten Regeln der Technik entspricht. Die Informationssicherheits- und Datenschutzbeauftragten können sich bei den »anerkannten Regeln der Technik« darauf beschränken, die herrschende Meinung der technischen Fachleute auf ihrem Gebiet und den Grad der Bewährung in der Praxis festzustellen. Nachteilig ist jedoch, »daß die Rechtsordnung mit dem Maßstab der allgemein anerkannten Regeln [der Technik] stets hinter einer weiterstrebenden technischen Entwicklung herhinkt«. (RdNr. 105 der Urteils des BVerfG) Der Rechtsbegriff »Stand der Technik« wird erstmalig im § 5 Nr. 2 (heute § 5 Abs. 1 Nr. 2) des Bundes-Immissionsschutzgesetzes von 1974 benutzt. Der Begriff stellt nicht mehr auf die Mehrheitsmeinung der technischen Fachleute ab. Vielmehr ist der aktuelle Stand der

technischen Entwicklung zu berücksichtigen. Hier müssen Sie in Ihrer Beurteilung auch die unterschiedlichen Meinungen der technischen Fachleute berücksichtigen, um aus der Würdigung der Argumente zu einer (eigenen) Meinung zu kommen. Maßstab der Meinungsbildung ist, was technisch als Maßnahme notwendig, geeignet und angemessen ist beziehungsweise was als Störung vermeidbar ist (vgl. R. Breuer, aaO). (RdNr. 106) Der Rechtsbegriff »Stand von Wissenschaft und Technik« bezieht sich auf Maßnahmen nach neuesten Erkenntnissen des aktuellen Stands der wissenschaftlichen und technischen Entwicklung. Der Begriff wird im § 7 Abs. 2 Nr. 3 Atomgesetz verwendet, wo verlangt wird, »die nach dem Stand von Wissenschaft und Technik erforderliche Vorsorge gegen Schäden durch die Errichtung und den Betrieb der Anlage« zu treffen. Aspekte wie Bewährung in der Praxis und mehrheitliche Meinung der Experten spielen keine Rolle mehr. »Es muß diejenige Vorsorge gegen Schäden getroffen werden, die nach den neuesten wissenschaftlichen Erkenntnissen für erforderlich gehalten wird.« (RdNr. 107 f.) Eine Datenschutzaufsichtsbehörde darf von Unternehmen im Bereich ITSicherheit keine Maßnahmen nach »Stand von Wissenschaft und Technik« verlangen. Deutlich wurde dies im Jahr 2020 bei der Diskussion zwischen Unternehmen und Aufsichtsbehörden über Endezu-Ende-verschlüsselte Videokonferenzen [GGHP20]. In einer solchen Diskussion muss dann eine Aufsichtsbehörde unter sinngemäßer Anwendung des Beschlusses des Bundesverfassungsgerichts in eine Prüfung und Einstufung der technisch-organisatorischen Maßnahmen eintreten. Dies ist auch für eine Aufsichtsbehörde eine technisch aufwendige Beurteilung. Der Bundesverband IT-Sicherheit e.V. (TeleTrusT) (https://www.teletrust.de) hat in der Arbeitsgruppe »Stand der Technik« eine Handreichung zum »Stand der Technik« erstellt, die bei der Einstufung einer IT-Sicherheitstechnik hilft. Dazu werden per Fragebogen Fachleute befragt. Diese stufen eine Technik nach Grad der Bewährung in der Praxis und nach Grad der Anerkennung

durch Fachleute jeweils auf einer Skala von null bis fünf ein. Dabei werden die Schutzziele Verfügbarkeit, Integrität, Vertraulichkeit und Authentizität betrachtet. Abschließend wird der Mittelwert über die Antworten gebildet. Bei einem Wert von null bis 1,5 für beide Dimension handelt es sich um den »Stand von Wissenschaft und Technik« (SvWuT), von 1,5 bis 3,5 ist es »Stand der Technik« (SdT) und oberhalb von 3,5 sind es »allgemein anerkannte Regeln der Technik« (aaRdT). Die Beurteilung stellt sich dann als ein Punkt in einem Diagramm dar (siehe Abbildung 5.1). In der Handreichung sind gängige technische Themen von Passwortsicherheit über Verschlüsselung und Netzwerksicherheit bis zu Überwachung von Verzeichnisdiensten und identitätsbasierter Segmentierung nach dieser Methode bewertet.

Abbildung 5.1: Die beispielhafte Auswertung der Fragebögen zur Bewertung des Stands der Technik einer bestimmten Technik (nach TeleTrusT, Handreichung zum Stand der Technik).

Im Jahr 2020 war Ende-zu-Ende-Verschlüsselung bei Videokonferenzen definitiv nicht Stand der Technik. Es gab Meinungen, dass in dem Moment, wo ein Hersteller ein Produkt am Markt hat, das die funktionalen Anforderungen erfüllt, diese Umsetzung Stand der Technik sei. Beziehen wir uns auf das Kalkar-Urteil, ist dem sicher nicht so. Es muss schon mehrere Produkte geben, welche die fragliche Funktionalität beherrschen.

Implementierungskosten Die Berücksichtigung von Implementierungskosten ist eine neue Formulierung, die eine Verhältnismäßigkeit zwischen Schutzbedarf der Daten und dem finanziellen Aufwand für den Schutz erlaubt. Die Liste der Käufer eines Buches über Informationssicherheit ist sicher weniger sensibel als die Liste der Mitglieder einer Selbsthilfegruppe zum Thema »Burn-out«. Der technische Aufwand zum Schutz der Buchkäuferliste darf geringer sein und damit weniger Kosten verursachen als beim Mitgliederverzeichnis der Selbsthilfegruppe. Eine interessante und spannende Frage hat das Oberste Verwaltungsgericht (Varhoven administrativen Sad) von Bulgarien im Juni 2021 dem Europäischen Gerichtshof vorgelegt. Reicht als Beweis für unzureichende technisch-organisatorische Maßnahmen im Datenschutz bereits aus, dass Dritte unbefugt an die personenbezogenen Daten gekommen sind? Oder muss im Einzelfall im Detail geprüft werden, ob die vom Unternehmen getroffenen technisch-organisatorischen Maßnahmen den Anforderungen der DS-GVO genügten? [Vas21] Im Bereich der Informationssicherheit ist es für Sie relativ einfach, die Kosten für eine Sicherheitsmaßnahme als angemessen zu beurteilen. Sie vergleichen die Betriebskosten der Sicherheitslösung mit dem mittleren Schaden pro Jahr, der ohne die Sicherheitslösung entstehen würde. Ist der abgeschätzte Schaden pro Jahr höher als die Betriebskosten pro Jahr, fällt die Entscheidung für die Sicherheitslösung leicht. In Anlehnung an die klassische Rentabilitätsbetrachtung »Return on Investment« (RoI), die in der Betriebswirtschaftslehre etabliert ist, definieren wir einen »Return on Security Investment« (RoSI) [ENISA12]. Beim RoI werden die Kosten der Investition mit dem Ertrag der Investition verglichen. Bei RoSI vergleicht man die Kosten der Investition mit dem verhinderten Schaden.

Die Kosten der Investition in eine Sicherheitslösung, sei es nun die Beschaffung einer Firewall, einer Antivirenlösung oder einer Festplattenverschlüsselung, können Sie sehr gut beziffern. Der Anschaffungspreis steht auf der Rechnung und die Kosten des Rollouts sowie die jährlichen Betriebskosten sind auch bestimmbar. Das Finanzcontrolling beziehungsweise das IT-Controlling sollte da gute Zahlen liefern können. Schwieriger wird es, den verhinderten Schaden zu bestimmen. Sie können sich dort nur auf veröffentlichte Statistiken anderer Unternehmen beziehen, da Ihnen ja die eigenen Zahlen fehlen. Nehmen wir an, ein Unternehmen hat 1000 Notebooks im Einsatz. Aus Erfahrung ist bekannt, dass etwa 30 Notebooks pro Jahr verloren gehen oder gestohlen werden. Der Missbrauch der auf den Notebooks gespeicherten Daten wird mit 8.000 € pro abhandengekommenen Notebook abgeschätzt. Deshalb soll eine Festplattenverschlüsselung eingeführt werden. Die Lizenzkosten sind pro Notebook einmalig 100 €. Der Rollout der Verschlüsselungslösung inklusive Betriebskosten liegt im ersten Jahr bei 40.000 € und die Betriebskosten in den Folgejahren sind mit 20.000 € zu beziffern. Damit ergibt sich folgende Rechnung: 1. Jahr

2. Jahr

3. Jahr

4. Jahr

verhinderter Schaden 240.000 € 240.000 € 240.000 € 240.000 € Lizenzkosten

100.000 € -

-

-

Betrieb und Rollout

40.000 €

20.000 €

20.000 €

RoSI

100.000 € 220.000 € 220.000 € 220.000 €

20.000 €

Bereits im ersten Jahr ergibt sich ein RoSI von 100.000 €. In den folgenden Jahren sind es sogar 220.000 €. Also eine lohnende Investition in die Sicherheit. Wichtig ist natürlich, dass Sie bei derartigen Rechnungen mit realistischen Zahlen rechnen. Die Kosten für die verlorenen Notebooks und die Ersatzbeschaffungen müssen Sie bei dieser Betrachtung nicht

berücksichtigen, da die Verschlüsselungslösung den Verlust der Notebooks nicht beeinflusst. Die Lösung verhindert nur den Missbrauch der Daten auf den verlorenen Notebooks. Höchstens wenn die Daten auf den Notebooks so wertvoll sein sollten, dass die Notebooks wegen der Daten gestohlen werden, beeinflusst die Verschlüsselungslösung vielleicht doch die Diebstahlrate. Den einfachen quantitativen Kostenvergleich zur Bestimmung des RoSI können Sie im Bereich Datenschutz nicht anwenden. Das Schutzziel, das Sie in der Abwägung betrachten, ist das Risiko für die Rechte und Freiheiten der betroffenen Personen. Das ist eher ein qualitativer Vergleich. Die Implementierungskosten sind nicht nur die Kosten der Beschaffung der Sicherheitslösung, sondern auch die Kosten für deren Betrieb. Nicht zu den Implementierungskosten der Sicherheitslösung gehören die Kosten der eigentlichen Verarbeitung, also zum Beispiel die Beschaffungs- und Betriebskosten der Server für die Verarbeitung, der zugehörigen Datenbanksoftware und so weiter. Nur die Kosten der Sicherheitsmaßnahmen, die zusätzlich beschafft und betrieben werden, dürfen Sie berücksichtigen. Grundsätzlich dürfen Sie jedoch, wenn es mehrere Maßnahmen gibt, die den gleichen Schutz liefern, die günstigste der Maßnahmen auswählen. Die schlichte Tatsache, dass Schutzmaßnahmen Kosten verursachen, ist kein Grund, von Schutzmaßnahmen abzusehen. Wenn sie personenbezogene Daten verarbeiten, müssen sie die Kosten der Schutzmaßnahmen tragen.

Sie müssen im Unternehmen personenbezogene Daten länger geschützt (Schutzziel Vertraulichkeit) auf einer Blu-ray aufbewahren. Es gibt zwei Möglichkeiten, dies zu tun. Sie können die unverschlüsselten Daten auf der Blu-ray für die Dauer der Aufbewahrung in einen Tresor legen. Alternativ können Sie die Daten verschlüsselt auf der Blu-ray speichern und die Blu-ray »normal« aufbewahren. Lediglich der Schlüssel wird, zum Beispiel ausgedruckt, in einem verschlossen Umschlag im Tresor aufbewahrt. Da beide Methoden einen vergleichbaren Schutz bieten, dürfen Sie die kostengünstigere Methode wählen. Sie müssen noch einen weiteren wichtigen Aspekt berücksichtigen: Wenn die Implementierungskosten der Sicherheitsmaßnahmen den Wert, den Sie den personenbezogenen Daten zurechnen, oder den potenziellen Schaden für Ihr Unternehmen übersteigen, müssen Sie diese trotzdem in Kauf nehmen, wenn das Risiko für die Rechte und Freiheiten der Betroffenen entsprechend hoch ist. Geht es nur um materielle Schäden für die Betroffenen, sind Sie wieder im Bereich eines quantitativen Vergleichs. Spielen jedoch zusätzlich immaterielle Schäden für die Betroffenen (zum Beispiel schwerwiegende Rufschädigungen) eine Rolle, ist ein alleiniger quantitativer Vergleich nicht mehr möglich. Um hier eine ordentliche Risikobetrachtung zu »erzwingen«, ist bei hohen Risiken eine Datenschutzfolgenabschätzung (DSFA) gemäß Art. 35 DS-GVO vor Aufnahme der Verarbeitungstätigkeit verbindlich vorgeschrieben. Dabei sind neben der Herausarbeitung und Bewertung der Risiken auch eine Beschreibung der zur Bewältigung der Risiken geplanten Maßnahmen ein erforderlicher Inhalt. Darüber hinaus müssen Sie aufschreiben, warum die Verarbeitung notwendig und verhältnismäßig ist. Eine DSFA muss vor Beginn der Verarbeitung erstellt werden.

Gewährleistungsziele des Datenschutzes Aus den Vorgaben zur Rechtmäßigkeit in der DS-GVO beziehungsweise im BDSG lassen sich zusätzlich zu den klassischen Schutzzielen der ITSicherheit auch Gewährleistungsziele des Datenschutzes ableiten (in Klammern die wesentlichen Paragraphen): Datenminimierung (Art. 5 Abs. 1 lit. c DS-GVO), Nichtverkettung (Zweckbindung: Art. 5 Abs. 1 lit. b DS-GVO), Transparenz (Art. 5 Abs. 1 lit. a DS-GVO, Art 12 ff. DS-GVO), Intervenierbarkeit (Richtigkeit: Art. 5 Abs. 1 lit. d DS-GVO, Art. 15 ff. DS-GVO). Datenminimierung bedeutet, dass nur so wenig Daten wie nötig verarbeitet werden. Daten die nicht erforderlich sind, werden auch nicht verarbeitet. »Erforderlich« heißt dabei, dass der Zweck der Verarbeitung ohne die Daten nicht erreichbar ist. Dass es praktisch wäre, die Daten zu haben, ist kein Argument zur Erforderlichkeit. Wenn Sie einen Newsletter per E-Mail verschicken wollen, benötigen Sie die E-Mail-Adressen der Abonnenten. Die E-MailAdresse ist hier also erforderlich. Weitere Angaben wie Name, Vorname, Anrede und so weiter sind nicht erforderlich. Dafür ist dann eine freiwillige Einwilligung erforderlich. Besser ist es, die Daten gar nicht erst zu erheben. Die Nichtverkettbarkeit oder Zweckbindung bedeutet, dass Daten, die zu unterschiedlichen Zwecken erhoben wurden, nicht verknüpft werden dürfen. Aus der Zusammenführung unterschiedlicher Datenbestände kann eine völlig neue Qualität der Datenauswertung entstehen.

Ein IT-Dienstleister verarbeitet im Rahmen von Auftragsverarbeitung die Daten des Sozialamts von Musterstadt und die Buchungsdaten einer örtlichen Autovermietung. Er bietet an, die Daten der Autovermietung mit den Daten des Sozialamts abzugleichen, um herauszufinden, welche Leistungsempfänger regelmäßig Kleintransporter mieten, da dies den Verdacht einer gewerblichen Tätigkeit nahelegen könnte. Das Transparenzgebot soll sicherstellen, dass die von der Datenverarbeitung Betroffenen genau wissen, welches Unternehmen welche Daten über sie verarbeitet. Nur wenn die Betroffenen wissen, wer ihre Daten verarbeitet, können Sie ihre Rechte als Betroffene wahrnehmen. Sie müssen von den Unternehmen informiert werden, dass ihre Daten dort verarbeitet werden, solange es ihnen nicht sowieso bekannt ist. Sie bestellen bei einem Versandhändler eine Ware. Damit ist Ihnen bekannt, dass die zur Bestellabwicklung erforderlichen Daten von dem Versandhändler verarbeitet werden. Er muss Sie nicht mehr explizit informieren. Um mehr Geld zu verdienen, verkauft der Händler Ihre Adresse an andere Händler. Das ist etwas, was Sie nicht wissen können, hierüber müssen Sie informiert werden. Und damit kommen wir zum vierten Gewährleistungsziel im Datenschutz: der Intervenierbarkeit. Dies bedeutet, dass Sie einen Anspruch haben, dass falsche Daten korrigiert werden und dass nicht (mehr) erforderliche Daten gelöscht werden. Als Sie Ihre Ware vom Versandhändler erhalten, stellen Sie fest, dass die Sendung an Herrn Erika Mustermann adressiert ist. Außerdem gibt es einen Zahlendreher in der Hausnummer. Sie haben einen Anspruch darauf, dass diese beiden Fehler in Ihren Daten korrigiert werden.

Das von der Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder entwickelte Standard-Datenschutzmodell (SDM) ist ein Beratungs- und Prüfkonzept, das über die klassischen Schutzziele der IT-Sicherheit hinaus diese vorgestellten vier Gewährleistungsziele des Datenschutzes formuliert hat [SDM20]. Wir werden uns in Kapitel 8 noch ausführlicher mit dem SDM und der Einbindung des SDM in den IT-Grundschutz beschäftigen.

Kapitel 6

Gesetze zur IT-Sicherheit IN DIESEM KAPITEL Europäische Richtlinien und Verordnungen zur IT-Sicherheit Deutsche Gesetze zur IT-Sicherheit

Sowohl der europäische als auch der deutsche Gesetzgeber regeln die Informationssicherheit in besonders sensiblen Bereichen. Als besonders sensibel gilt dabei der Bereich, der unser aller Zusammenleben direkt betrifft: die sogenannte kritische Infrastruktur. Wir schauen uns im Folgenden an, was diese kritische Infrastruktur ist und was dort die gesetzlichen Vorgaben sind. Dabei beginnen wir mit den europäischen Vorgaben, da sich die deutschen Regelungen daraus ableiten. Mit der fortschreitenden Digitalisierung wird eine solide Gesetzgebung zur Informationssicherheit immer wichtiger. Und das betrifft nicht nur Unternehmen und Behörden. Auch wir als Privatpersonen und Verbraucher brauchen gesetzliche Vorgaben zu unserem Schutz. Hersteller müssen verpflichtet werden, möglichst sichere informationstechnische Geräte zu bauen. Auch die Digitalisierung von Verwaltungsprozessen und im Gesundheitswesen verlangt Informationssicherheit. Schließlich sollen unsere persönlichen Daten optimal geschützt sein, wenn sie in diesen sensiblen Bereichen verarbeitet werden. Wir schauen uns jetzt, das heißt in diesem Kapitel, die wichtigsten EUVerordnungen, EU-Richtlinien und deutschen Gesetze an. Sie lernen dabei auch, wie der Rechtsrahmen für die Informationssicherheit in deutschen Behörden geregelt ist.

NIS-Richtlinie (EU) Die Richtlinie über Maßnahmen zur Gewährleistung eines hohen gemeinsamen Sicherheitsniveaus von Netz- und Informationssystemen in der Union (NIS-Richtlinie) aus dem Jahr 2016 macht den Betreibern wesentlicher Dienste und den Anbietern von digitalen Diensten Vorgaben in Bezug auf Sicherheitsanforderungen und Meldepflichten. Ziel ist, dass die Betreiber ein Risikomanagement einführen und die gravierendsten Sicherheitsvorfälle melden. Da es sich um eine Richtlinie handelt, musste sie zunächst noch in nationales Recht umgesetzt werden. Durch das IT-Sicherheitsgesetz von 2015 war Deutschland bezüglich der Umsetzung schon gut aufgestellt. Es mussten daher lediglich einige noch fehlende Regelungen durch das Gesetz zur Umsetzung der NISRichtlinie ergänzt werden, was 2017 erfolgte. Wesentliche Dienste im Sinne der NIS-Richtlinie sind öffentliche oder private Einrichtungen in den folgenden, die im Anhang der Richtlinie aufgeführten Sektoren: Energie: Elektrizität, Erdöl, Erdgas; Verkehr: Luftverkehr, Schienenverkehr; Schifffahrt, Straßenverkehr; Bankwesen; Finanzmarktinfrastrukturen; Gesundheitswesen: Einrichtungen der medizinischen Versorgung (einschließlich Krankenhäuser und Privatkliniken); Trinkwasserlieferung und -versorgung; digitale Infrastruktur. Dies sind die Sektoren der kritischen Infrastruktur, das heißt die Sektoren, in denen erhebliche Störungen das Zusammenleben in unser Gesellschaft wesentlich beeinträchtigen. Digitale Dienste im Sinne der Richtlinie (nicht zu verwechseln mit der digitalen Infrastruktur aus der obigen Aufzählung) sind OnlineMarktplätze, Online-Suchmaschinen und Cloud-Computing-Dienste.

Wenn Sie auf der Webseite Ihres Unternehmens Ihre eigenen Produkte verkaufen, ist das kein Online-Marktplatz. Ein Online-Marktplatz bietet vielmehr eine Handelsplattform für Dritte an, wie zum Beispiel eBay Inc. Von den Mitgliedstaaten der EU wurde im Rahmen der Richtlinie die Erstellung einer »Nationalen Strategie für die Sicherheit von Netz- und Informationssystemen« (Art. 7) gefordert. In Deutschland ist dies in der »Cybersicherheitsstrategie für Deutschland« umgesetzt, welche zuletzt 2021 aktualisiert wurde. Außerdem muss eine »Nationale zuständige Behörde« – in Deutschland das Bundesamt für Sicherheit in der Informationstechnik (BSI) – benannt werden (Art. 8). Das BSI ist auch die zentrale Anlaufstelle für die grenzüberschreitende Zusammenarbeit der zuständigen Behörden. Außerdem müssen nationale ComputerNotfallteams (Computer Security Incident Response Teams, CSIRT) – häufig auch Computer Emergency Response Teams (CERT) – eingerichtet werden (Art. 9). Die nationalen CSIRTs und die national zuständige Behörde müssen zusammenarbeiten. Bei dieser Zusammenarbeit geht es insbesondere auch um den Austausch von Informationen über Vorfälle und Sicherheitslücken. Auch die CSIRTs sollen sich zum Zweck des Informationsaustausches international vernetzen. Eine Kooperationsgruppe aus Vertretern der Mitgliedstaaten, der EU-Kommission und der Europäischen Agentur für Cybersicherheit (ENISA, siehe nachfolgenden Abschnitt) dient der strategischen Zusammenarbeit (Art. 11) auf dem Gebiet der Informationssicherheit in der EU. Die Mitgliedstaaten müssen sicherstellen, dass die Betreiber wesentlicher Dienste geeignete und verhältnismäßige technische und organisatorische Maßnahmen ergreifen und dass die zuständige Behörde deren Durchsetzung forcieren kann. Meldungen über Sicherheitsvorfälle erfolgen an die zuständige Behörde (Art. 14 f.), in Deutschland also an das BSI. Ähnliche Vorgaben gelten auch für die Anbieter digitaler Dienste. Die EU-Kommission hat in einem Rechtsakt (Durchführungsverordnung 2018/151) Vorschriften für die Anwendung der NIS-Richtlinie

»hinsichtlich der weiteren Festlegung der von Anbietern digitaler Dienste beim Risikomanagement in Bezug auf die Sicherheit von Netzund Informationssystemen zu berücksichtigenden Elemente und der Parameter für die Feststellung erheblicher Auswirkungen eines Sicherheitsvorfalls« erlassen. In diesem Rechtsakt wird auch definiert, wann ein Sicherheitsvorfall erhebliche Auswirkungen hat. Insbesondere ist der Schwellenwert für die Anzahl der betroffen Nutzerinnen deutlich niedriger (100.000 Betroffene) als in der deutschen BSIKritisverordnung (meist 500.000 Betroffene). Die EU-Kommission hat die NIS-Richtlinie im Jahr 2020 evaluiert und ist zu dem Ergebnis gekommen, dass es Nachbesserungsbedarf gibt. Zum einen ist die NIS-Richtlinie im Anwendungsbereich auf die KRITIS-Sektoren beschränkt, zum anderen ist der Umsetzungsgrad in den Mitgliedsländern sehr unterschiedlich. Letzteres betrifft den Anwendungsbereich, die Durchsetzung der IT-Sicherheitsvorgaben innerhalb der Länder und die Ausstattung der nationalen Informationssicherheitsbehörden mit personellen und finanziellen Ressourcen. Auch lässt nach Meinung der Kommission der Austausch von Informationen zwischen den Beteiligten zu wünschen übrig. Deshalb plant die Kommission eine Neuauflage der NIS-Richtlinie als »NIS-2-Richtlinie«. Sie hat dazu im Dezember 2020 den Entwurf einer neuen »Richtlinie über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union« vorgelegt. Außerdem wurde zeitgleich ein Entwurf für eine »Richtlinie über die Resilienz kritischer Einrichtungen« vorgestellt. Beide Entwürfe decken eine Vielzahl von Bereichen ab und haben zum Ziel, aktuelle und künftige Risiken online und offline – von Cyberangriffen bis hin zu Kriminalität und Naturkatastrophen – auf eine systematische Weise zu bewältigen.

Rechtsakt zur Cybersicherheit (EU) Die Verordnung über die ENISA (Agentur der Europäischen Union für Cybersicherheit) und über die Zertifizierung der Cybersicherheit von Informations- und Kommunikationstechnik (Rechtsakt zur Cybersicherheit) regelt die Kompetenzen der ENISA neu. Die ENISA

war 2004 als »Europäische Agentur für Netz- und Informationssicherheit« gegründet worden. Sie muss nicht nur in Fragen der Cybersicherheit beraten und fördern, sondern sie spielt auch eine wesentliche Rolle bei der operativen Zusammenarbeit der Mitgliedstaaten in diesem Bereich. Die Agentur soll regelmäßig Cybersicherheitsübungen durchführen und nimmt die koordinierenden Sekretariatsaufgaben bei der Zusammenarbeit des CSIRT-Netzwerks wahr. Sie ist auch zuständig für die Entwicklung und Förderung der Cybersicherheitszertifizierung von IT-Produkten. Die organisatorischen Strukturen der ENISA bis hin zur Haushalts- und Personalausstattung sind natürlich auch in der Verordnung geregelt. Für uns Verbraucher ist der Zertifizierungsrahmen für die Cybersicherheitszertifizierung relevant. Sie werden in Zukunft auf ITProdukten Sicherheitslabel finden. Ähnlich wie bei Kühlschränken die Label über den Energieverbrauch die Kaufentscheidung beeinflussen, soll das Label mit der Sicherheitszertifizierung die Kaufentscheidung bei IT-Geräten beeinflussen. In Art. 51 des Rechtsakts werden zehn minimale Sicherheitsziele (Funktionalitäten) ausführlich definiert. Im Art. 52 finden Sie dann die Vorgaben für die folgenden drei Vertrauenswürdigkeitsstufen: niedrig: »…die bekannten grundlegenden Risiken für Sicherheitsvorfälle und Cyberangriffe möglichst gering zu halten.« mittel: »…bekannte Cybersicherheitsrisiken und das Risiko von Cybersicherheitsvorfällen und Cyberangriffen seitens Akteuren mit begrenzten Fähigkeiten und Ressourcen möglichst gering zu halten.« hoch: »…das Risiko von dem neuesten Stand der Technik entsprechenden Cyberangriffen durch Akteure mit umfangreichen Fähigkeiten und Ressourcen möglichst gering zu halten.« Das Konzept der Trennung von Sicherheitszielen (Funktionalität) und Vertrauenswürdigkeit (Qualität) der Maßnahmen finden Sie auch in

technischen Sicherheitsstandards wie den Common Criteria (siehe Kapitel 9). Es folgen in dem Rechtsakt weitere Vorgaben für die Gestaltung des Zertifizierungsrahmens. Wir dürften in Zukunft alle als Endnutzerinnen davon profitieren, dass die Hersteller oder Anbieter von zertifizierten ITProdukten »Leitlinien und Empfehlungen zur Unterstützung der Endnutzerinnen bei der sicheren Konfiguration, der Installation, der Bereitstellung, dem Betrieb und der Wartung der IKT-Produkte oder Dienste« zur Verfügung stellen müssen. Mit dem sogenannten IT-Sicherheitsgesetz 2.0 und einer zugehörigen Rechtsverordnung (BSI-ITSiKV, BGBl. I S. 4978) hat das Bundesministerium des Innern, für Bau und Heimat die Vorgaben zu dieser Sicherheitszertifizierung Ende 2021 in Deutschland in Form eines freiwilligen IT-Sicherheitskennzeichens umgesetzt. Die ersten Geräte beziehungsweise Dienste, die eine solche Kennzeichnung erhalten können, sollen Breitband-Router und E-Mail-Dienste sein. Basis für das Sicherheitskennzeichen sind die technischen Richtlinien BSI TR-3148 beziehungsweise BSI TR-3108. Das Kennzeichen wird auf Basis einer Selbsterklärung des Herstellers beim BSI beantragt. Das BSI prüft die Produkte oder Dienstleistungen jedoch nicht. Das BSI kann also nicht garantieren, dass zertifizierte IT-Produkte oder Dienste »absolut sicher« sind. Ob das Sicherheitskennzeichen »etwas bringt«, bleibt abzuwarten. Die Vergabe des Kennzeichens auf Basis einer Selbsterklärung des Herstellers kann nur ein Anfang sein. Auf Dauer muss eine unabhängige Prüfung die Grundlage für die Vergabe des Sicherheitskennzeichens sein. Führt das Kennzeichen zu einer Verteuerung der Produkte, müssen wir abwarten, ob der Markt es annimmt.

eIDAS-Verordnung (EU) Die Verordnung über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt (eIDAS-Verordnung) regelt unter anderem die »elektronische Signatur«.

Nach der Definition in Art. 3 Nr. 10 besteht eine elektronische Signatur aus »Daten in elektronischer Form, die anderen elektronischen Daten beigefügt oder logisch mit ihnen verbunden werden und die der Unterzeichner zum Unterzeichnen verwendet«. Diese einfachste Form der elektronischen Signatur – auch »(einfache) elektronische Signatur« – kann ohne (!) Anwendung kryptografischer Verfahren erstellt werden. Bereits eine E-Mail, die mit einer üblichen Grußformel, dem Namen und den Kontaktdaten (Anschrift, Telefon, EMail) versehen ist, erfüllt die Anforderungen an eine (einfache) elektronische Signatur und entfaltet bereits eine Rechtswirkung. Art. 25 der Verordnung sagt »Einer elektronischen Signatur darf die Rechtswirkung und die Zulässigkeit als Beweismittel in Gerichtsverfahren nicht allein deshalb abgesprochen werden, weil sie in elektronischer Form vorliegt oder weil sie die Anforderungen an qualifizierte elektronische Signaturen nicht erfüllt.« Jedwede Anwendung einer digitalen Signatur (siehe Kapitel 17) unabhängig von der Art der Speicherung des privaten Schlüssels erfüllt alle Voraussetzungen der (einfachen) elektronischen Signatur. Wenn Sie sich über diese vermeintliche Haarspalterei wundern: Die elektronische Signatur ist ein Rechtskonzept. Die digitale Signatur ein kryptografisches, also ein technisches Konzept. Eine »fortgeschrittene elektronische Signatur« muss nach Art. 26 eIDAS-Verordnung vier Anforderungen erfüllen: a. »Sie ist eindeutig dem Unterzeichner zugeordnet.« Die fortgeschrittene elektronische Signatur enthält Daten, die nur der Unterzeichner erzeugen kann. b. »Sie ermöglicht die Identifizierung des Unterzeichners.« Die Daten erlauben direkt oder indirekt eine Zuordnung zum Unterzeichner. c. »Sie wird unter Verwendung elektronischer Signaturerstellungsdaten erstellt, die der Unterzeichner mit einem hohen Maß an Vertrauen unter seiner alleinigen Kontrolle verwenden kann.« Hierunter fällt die Verwendung des privaten Schlüssels (»elektronischer

Signaturerstellungsdaten«) und der private Schlüssel muss zumindest durch ein Passwort, das nur der Unterzeichner kennt (»unter seiner alleinigen Kontrolle«), geschützt sein. d. »Sie ist so mit den auf diese Weise unterzeichneten Daten verbunden, dass eine nachträgliche Veränderung der Daten erkannt werden kann.« Die Hash-Funktion, die bei der Erstellung der digitalen Signatur genutzt wurde, stellt sicher, dass eine Veränderung der signierten Daten oder der Signatur erkannt wird. Die Anforderungen an die Sicherheit der Speicherung und der Nutzung der privaten Schlüssel zur Erstellung einer »qualifizierten elektronischen Signatur« sind deutlich höher, da eine qualifizierte Signatur eine höhere Rechtswirkung hat. Rein technisch ist die qualifizierte Signatur nichts anderes als die fortgeschrittene Signatur. »Eine qualifizierte elektronische Signatur hat die gleiche Rechtswirkung wie eine handschriftliche Unterschrift« (Art. 15 Abs. 2 eIDAS-Verordnung). Die technischen und organisatorischen Anforderungen sind in einen Anhang der eIDAS-Verordnung ausgelagert. Damit ist die eher technische Spezifikation getrennt von dem juristischen Text der Verordnung. Der Anhang I der Verordnung regelt die Anforderungen an die »Qualifizierten Zertifikate für elektronische Signaturen«. Er liest sich wie eine abstrakte Beschreibung eines X.509-Zertifikats und ist dadurch offener. Im Anhang II finden Sie die »Anforderungen an qualifizierte elektronische Signaturerstellungseinheiten«. Eine qualifizierte elektronische Signaturerstellungseinheit ist eine konfigurierte Software oder Hardware, die zum Erstellen einer elektronischen Signatur verwendet wird und die die Anforderungen von Anhang II erfüllt. »Qualifizierte elektronische Signaturerstellungseinheiten müssen durch geeignete Technik und Verfahren zumindest gewährleisten, dass a. die Vertraulichkeit der zum Erstellen der elektronischen Signatur verwendeten elektronischen Signaturerstellungsdaten angemessen sichergestellt ist,

b. die zum Erstellen der elektronischen Signatur verwendeten elektronischen Signaturerstellungsdaten praktisch nur einmal vorkommen können, c. die zum Erstellen der elektronischen Signatur verwendeten elektronischen Signaturerstellungsdaten mit hinreichender Sicherheit nicht abgeleitet werden können und die elektronische Signatur bei Verwendung der jeweils verfügbaren Technik verlässlich gegen Fälschung geschützt ist, d. die zum Erstellen der elektronischen Signatur verwendeten elektronischen Signaturerstellungsdaten vom rechtmäßigen Unterzeichner gegen eine Verwendung durch andere verlässlich geschützt werden können.« In der Praxis werden die Anforderungen mit Chipkarten (siehe Kapitel 19) umgesetzt, wobei die digitalen Signaturen in der Chipkarte erzeugt werden. Der private Schlüssel darf dann nie die Chipkarte verlassen. Der Anbieter zum Beispiel von qualifizierten X.509-Zertifikaten (= elektronischen Signaturerstellungsdaten) muss eine hohe Sicherheit bieten und deshalb für seine Tätigkeit zugelassen sein. Für die Zulassung muss er die Einhaltung der Sicherheitsvorgaben nachweisen. Regelmäßige Audits stellen die Erfüllung der Sicherheitsanforderungen dauerhaft sicher. Eine aktuell gepflegte Liste der qualifizierten Vertrauensdiensteanbieter in der europäischen Union finden Sie im Trusted List Browser der Europäischen Kommission (https://esignature.ec.europa.eu/efda/tl-browser).

Single-Digital-Gateway(SDG-)Verordnung (EU) Die Verordnung über die Einrichtung eines »einheitlichen digitalen Zugangstors« beziehungsweise »Single Digital Gateways« (SDGVerordnung) regelt »die Einrichtung und den Betrieb eines einheitlichen

digitalen Zugangstors, um Bürgern und Unternehmen einfachen Zugang zu hochwertigen Informationen, effizienten Verfahren und wirksamen Hilfs- und Problemlösungsdiensten im Zusammenhang mit Unions- und nationalen Vorschriften für Bürger und Unternehmen, die ihre Rechte aus dem Unionsrecht im Bereich Binnenmarkt … ausüben oder ausüben wollen, zu verschaffen« (Art. 1 Abs. 1 Lit. a SDG-Verordnung). Informationen können direkt abgerufen und Dienstleistungen mit einer Authentifizierung genutzt werden. In zwei ausführlichen Anhängen der Verordnung finden Sie Listen von Informationen und von Dienstleistungen (zum Beispiel: Meldung einer Adressänderung), die online verfügbar sein müssen. Im Grunde ist diese Verordnung das europäische Online-Zugangsgesetz. Das Portal ist über https://europa.eu/youreurope/ zugänglich. Derzeit sind aber nur Informationen ohne Anmeldung abrufbar. Der Zugang zu den Online-Verfahren soll ab Dezember 2023 möglich sein. Was hat dieses Portal mit IT-Sicherheit zu tun? Einiges, da über das Portal auch massiv personenbezogene Daten verarbeitet werden. In den Anwendungen hinter dem Portal wird das »Once-Only-Prinzip« angewandt (Grundsatz der einmaligen Erfassung, das heißt, alle Daten – auch die personenbezogenen – werden nur einmal gespeichert). Nur die Behörde, die ein Verfahren betreibt, speichert die Daten (zum Beispiel das Finanzamt die Steuerdaten). Benötigt eine Behörde zur Bearbeitung eines Antrags eines Bürger oder Unternehmens Daten von einer andern Behörde, greift die Behörde online auf die Daten zu. Dabei kommt es notwendigerweise zu einem intensiven Austausch von personenbezogenen und anderen vertraulichen Daten über Netze. Deshalb finden Sie in Art. 14 der Verordnung auch abstrakte Vorgaben zur IT-Sicherheit (Abs. 3 lit. e und h). Abs. 9 enthält eine Ermächtigung der Kommission zum Erlass von Durchführungsakten zu technischen Spezifikationen, die dann auch Regelungen zur Cybersicherheit enthalten müssen. Es wird Sie nicht wundern, dass dieser Datenaustausch (»Übermittlung von Nachweisen«) innerhalb der EU auch grenzüberschreitend stattfinden soll.

BSI-Gesetz (D) Das Gesetz über das Bundesamt für die Sicherheit in der Informationstechnik (BSI-Gesetz) definierte ursprünglich die Aufgaben des BSI. Durch das Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme (IT-Sicherheitsgesetz) vom 17. Juli 2015 (BGBL I, S. 1324) wurden die Aufgaben des BSI als Zentralstelle für die IT-Sicherheit erheblich erweitert. Das BSI wurde Meldestelle für IT-Sicherheitsvorfälle für Unternehmen der kritischen Infrastruktur. Mit der Erweiterung der Aufgaben des BSI wurden gleichzeitig die ITSicherheitsvorgaben für KRITIS-Unternehmen in das Gesetz geschrieben. Welche Unternehmen genau unter die KRITIS-Regelung fallen, ist in der BSI-Kritisverordnung festgelegt, siehe den nachfolgenden Abschnitt. Gegenüber der NIS-Richtlinie ergänzt das BSI-Gesetz die Bereiche Versicherungen, Ernährung und Siedlungsabfallentsorgung. Zwei Sektoren, die auch den kritischen Infrastrukturen zugerechnet werden, fehlen im BSI-Gesetz: »Staat und Verwaltung« und »Medien und Kultur«. Auf Basis des Vertrags über die Errichtung des IT-Planungsrats und über die Grundlagen der Zusammenarbeit beim Einsatz der Informationstechnologie in den Verwaltungen von Bund und Ländern (IT-Staatsvertrag) arbeiten der Bund und die Länder bei IT-Fragen im ITPlanungsrat zusammen. Dort werden auch Themen zur IT-Sicherheit behandelt. Die Rahmenvorgaben zur IT-Sicherheit werden in der »Leitlinie für die Informationssicherheit in der öffentlichen Verwaltung« festgehalten. Auf dieser Basis erstellen die Länder eigene Richtlinien zur IT-Sicherheit in der jeweiligen Landesverwaltung. Am 19. Juli 2017 hat die Bundesregierung die Neukonzeption des »Umsetzungsplan Bund 2017 zur Steuerung und Umsetzung der Informationssicherheit in der Bundesverwaltung« (UP Bund) beschlossen. Dieser UP Bund ist die Umsetzung der Leitlinie für Informationssicherheit in der Bundesverwaltung.

Einige Länder sind weiter gegangen und haben die IT-Sicherheit mehr oder weniger umfangreich in Landesgesetzen verankert (zum Beispiel Baden-Württemberg, Bayern, Niedersachsen, Saarland und Sachsen). Baden-Württemberg hat eine Cybersicherheitsagentur als Landesoberbehörde für Cybersicherheit im Ländle gegründet. Bayern hat sogar ein Landesamt für Informationssicherheit ins Leben gerufen. Hessen wiederum hat das Hessen Cyber Competence Center (Hessen3C) gegründet und Sachsen das Amt eines Beauftragten für Informationssicherheit des Landes geschaffen. Die Mediengesetzgebung fällt in die Kompetenz der Länder. Damit müsste es einen IT-Sicherheitsstaatsvertrag für Medien geben. Diesen gibt es jedoch bisher nicht. Die Notwendigkeit ist aber, wie Vorfälle gezeigt haben, durchaus gegeben. Anfang April 2015 wurde der Sendebetrieb des französischen Fernsehsenders TV5 Monde durch einen Hackerangriff über Stunden lahmgelegt. Auch die Internet-, Facebook- und Twitterauftritte des Senders waren betroffen. Im Dezember 2020 wurde die deutsche Funke Mediengruppe Opfer eines Hackerangriffs, sodass deren Zeitungen mehrere Tage gar nicht beziehungsweise nur mit Notausgaben erscheinen konnten. Im April 2021 war die Verlagsgruppe Madsack von einer Ransomware-Attacke betroffen. Zur Madsack-Mediengruppe gehören zahlreiche Tageszeitungen in mehreren Bundesländern. Nach verschiedenen Meldungen soll die Produktion einer Wochenendausgabe beeinträchtigt gewesen sein. Durch das Gesetz zur Umsetzung der NIS-Richtlinie vom 30. Juni 2017 (BGBL I, S. 1885) kamen in § 8c noch »Besondere Anforderungen an die Anbieter digitaler Dienste« hinzu. Digitale Dienste sind – wie zuvor bereits dargestellt – Online-Marktplätze, Online-Suchmaschinen und Cloud-Computing-Dienste. Das Zweite Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme vom 18. Mai 2021 (BGBL I, S. 1122) fügte dann noch

»Unternehmen im besonderen öffentlichen Interesse« hinzu, die keine Unternehmen aus dem KRITIS-Bereich sind. Es handelt sich im Einzelnen um Unternehmen, die 1. Kriegswaffen nach Teil B der Kriegswaffenliste oder IT-Systeme zur Verarbeitung von Verschlusssachen herstellen, 2. die nach ihrer inländischen Wertschöpfung zu den größten Unternehmen in Deutschland gehören und daher von erheblicher volkswirtschaftlicher Bedeutung für die Bundesrepublik Deutschland sind oder 3. die Betreiber eines Betriebsbereichs der sogenannten »oberen Klasse« im Sinne der Störfall-Verordnung sind (Gifte, Explosiv- und brennbare sowie umweltgefährdende Stoffe). Auch hierzu muss das Bundesministerium des Innern, für Bau und Heimat noch eine konkretisierende Verordnung erlassen. Die Abbildung 6.1 gibt eine Übersicht über die IT-Sicherheitsregelungen in deutschen Gesetzen. Es fehlt noch eine Verordnungen zu Schwellenwerten bei Unternehmen im besonderen öffentlichen Interesse und es gibt auch noch einen völlig ungeregelten Bereich, nämlich die IT-Sicherheit bei Medien und Kultur.

Abbildung 6.1: Die gesetzlichen Vorgaben zur IT-Sicherheit in den unterschiedlichen Sektoren. Die »??« kennzeichnen eine noch nicht existierende Verordnung. »DRA. d. K.« ist der Durchführungsrechtsakt 2018/151 der Europäischen Kommission.

Nach der Novellierung des BSI-Gesetzes im Jahr 2021 hat das BSI nun die folgenden Aufgaben: Das BSI ist für die Kontrolle der Kommunikationstechnik von Bundesbehörden im Inland zuständig. (§ 4a) das BSI darf Mindeststandards für die Sicherheit und technische Richtlinien für Bundesbehörden erlassen (§ 8). Diese haben auch Bedeutung (wenn auch keine unmittelbarer Verbindlichkeit) außerhalb der Bundesbehörden. Das BSI sammelt als zentrale Meldestelle alle Informationen zu Sicherheitslücken, Schadprogrammen und versuchten oder erfolgten Angriffen. Diese Informationen werden zur Warnung Dritter, insbesondere auch der Öffentlichkeit, genutzt. Das BSI darf explizit vor Produkten oder Diensten warnen. (§ 4b und § 7 Abs. 2; Anmerkung: Datenschutzaufsichtsbehörden dürfen dies eher nicht!)

Das BSI darf Protokolldaten im Regierungsnetz auswerten. Der Umgang mit den Protokolldaten, die automatisierte Auswertung, Speicherfristen oder Pseudonymisierung sind geregelt. (§ 5 f.) Das BSI darf zur Aufgabenerfüllung von TK-Anbietern Stammdatenauskünfte einholen. (§ 5c) Das BSI darf bei Bundesbehörden, Betreibern kritischer Infrastruktur, Anbietern digitaler Dienste und Unternehmen im besonderen öffentlichen Interesse Portscans durchführen und Honeypots betreiben. Feststellungen müssen an die Systemverantwortlichen weitergegeben werden. (§ 7b) Das BSI darf gegenüber Diensteanbietern (§ 7c) und Anbietern von Telemedien (§ 7d) Anordnungen zur Gefahrenabwehr erlassen. Das BSI ist für die Aufsicht über die IT-Sicherheit bei Unternehmen der kritischen Infrastruktur, der Anbieter digitaler Dienste und den Unternehmen im besonderen öffentlichen Interesse zuständig. (§§ 8a–f) Einige dieser Punkte sind für Sie insofern interessant, als sie zeigen, was heute sinnvollerweise an Maßnahmen gemacht wird, wie etwa die Auswertung von Protokolldateien, Portscans, Systeme zur Angriffserkennung oder das Sammeln von Sicherheitsinformationen. Die Ausgestaltung der Rechte liefert Ihnen auch Hinweise, wie Sie im Unternehmen damit umgehen. Außerdem sind natürlich die Standards und technischen Richtlinien, zumindest als Good-Practice-Beispiele, für Sie bedeutsam. Das BSI ist weiterhin die für die Cybersicherheitszertifizierung zuständige Stelle (siehe auch Abschnitt Rechtsakt zur Cybersicherheit der EU in diesem Kapitel) und führt das freiwillige ITSicherheitskennzeichen für Verbraucher ein. (§ 9b f.) Unternehmen, die unter die Regelungen des BSI-Gesetzes fallen, müssen ab 1. Mai 2023 Systeme zur Angriffserkennung und eventuellen Angriffsabwehr (»… Bedrohungen … vermeiden …«) einsetzen (§ 8a Abs. 1a). Systeme zur Angriffserkennung sind »durch technische Werkzeuge und organisatorische Einbindung unterstützte Prozesse zur

Erkennung von Angriffen auf informationstechnische Systeme. Die Angriffserkennung erfolgt dabei durch Abgleich der in einem informationstechnischen System verarbeiteten Daten mit Informationen und technischen Mustern, die auf Angriffe hindeuten« (§ 2 Abs. 9b). Informatiker nennen so etwas Intrusion Detection System (IDS) beziehungsweise Intrusion Prevention System (IPS). Es ist erstaunlich, dass derart konkrete Maßnahmen in einem Gesetz vorgeschrieben werden. Vor dem Hintergrund der öffentlichen Diskussion über den Einsatz von fernöstlichen Komponenten in Unternehmen erhält das Bundesministerium des Innern, für Bau und Heimat das Recht, den Einsatz kritischer Komponenten zu untersagen (auch als Lex Huawei bezeichnet) (§ 9b). Der § 9b regelt Kompetenzen des Bundesministeriums des Innern, für Bau und Heimat ohne Bezug zum BSI. Eine fachliche Abstimmung findet nur mit Ministerien, nicht aber mit dem BSI, statt. Das BSI-Gesetz erscheint im Moment als Sammelbecken für alle ITSicherheitsregelungen, die sich nicht in Spezialgesetzen unterbringen lassen. Es ist auf Dauer sicher besser, wenn alle gesetzlichen Regelungen zur Informationssicherheit in einem dedizierten »Informationssicherheitsgesetz« zusammengeführt werden.

BSI-Kritisverordnung (D) Die Verordnung zur Bestimmung kritischer Infrastrukturen nach dem BSI-Gesetz (BSI-Kritisverordnung) regelt die Kriterien, nach denen ein Unternehmen als kritische Infrastruktur gilt. Die Bereiche (Sektoren) der kritischen Infrastruktur, wie sie in der BSI-Kritisverordnung aufgeführt sind, sind: Sektor Energie mit Stromversorgung, Gasversorgung, Kraftstoff- und Heizölversorgung und Fernwärmeversorgung, Sektor Wasser mit Trinkwasserversorgung und Abwasserbeseitigung, Sektor Ernährung mit Lebensmittelversorgung,

Sektor Informationstechnik und Telekommunikation mit Sprach- und Datenübertragung sowie Datenspeicherung und -verarbeitung, Sektor Gesundheit mit stationärer medizinischer Versorgung, der Versorgung mit unmittelbar lebenserhaltenden Medizinprodukten, die Verbrauchsgüter sind, der Versorgung mit verschreibungspflichtigen Arzneimitteln und Blut- und Plasmakonzentraten zur Anwendung im oder am menschlichen Körper und der Laboratoriumsdiagnostik, Sektor Finanz- und Versicherungswesen mit Bargeldversorgung, dem kartengestützten Zahlungsverkehr, dem konventionellen Zahlungsverkehr, Handel, Verrechnung und Abwicklung von Wertpapier- und Derivatgeschäften sowie Versicherungsdienstleistungen und Sozialleistungen, Sektor Transport und Verkehr mit dem Personen- und Güterverkehr. Der 2021 neu in das BSI-Gesetz aufgenommene Sektor Siedlungsabfallentsorgung ist noch nicht in die BSI-Kritisverordnung aufgenommen worden. Auf Grund von Erfahrungen mit Naturkatastrophen gilt ein Ausfall, der weniger als 500.000 Menschen betrifft, als beherrschbar. Deshalb wurde der Schwellenwert für die Einstufung als kritische Infrastruktur bei 500.000 Betroffenen gewählt. Eine Person verbraucht im Jahr im Mittel 869 kg Lebensmittel. Damit verbrauchen 500.000 Personen 434,5 t Lebensmittel pro Jahr. Jeder Hersteller, Großhändler oder Händler, der mehr Lebensmittel herstellt oder vertreibt, ist damit kritische Infrastruktur. Der Schwellenwert für Krankenhäuser beträgt 30.000 vollstationäre Fälle pro Jahr. Diese Zahl wird in der Verordnung nicht begründet. Bahnhöfe sind kritische Infrastruktur, wenn sie in der höchsten Kategorie 1 eingestuft sind. Dies sind derzeit 21 Personenbahnhöfe der Deutschen Bahn.

Damit kann jedes Unternehmen aus den entsprechenden Sektoren selbst klären, ob es sich unterhalb oder oberhalb des Schwellenwerts befindet.

Geschäftsgeheimnisgesetz (D) Das Gesetz zum Schutz von Geschäftsgeheimnissen (Geschäftsgeheimnisgesetz) vom 18. April 2019 (BGBl. I S. 466) schützt Geschäftsgeheimnisse vor »unerlaubter Erlangung, Nutzung und Offenlegung«. Dabei definiert das Gesetz ein Geschäftsgeheimnis als eine Information, die »Personen in den Kreisen, die üblicherweise mit dieser Art von Informationen umgehen, [nicht] allgemein bekannt oder ohne Weiteres zugänglich ist und daher von wirtschaftlichem Wert ist«. Außerdem muss ein berechtigtes Interesse an der Geheimhaltung bestehen. Das Gesetz fordert, dass ein Geschäftsgeheimnis »Gegenstand von den Umständen nach angemessenen Geheimhaltungsmaßnahmen durch ihren rechtmäßigen Inhaber« sein muss. Sie können Geschäftsgeheimnisse durch unterschiedliche Arten technisch-organisatorischer Maßnahmen schützen. Welche Maßnahmen Sie auswählen, hängt von dem zu schützenden Geschäftsgeheimnis ab. Von vertraglichen Vereinbarungen über Maßnahmen zum Zugriffsschutz bis hin zur Verschlüsselung der Geschäftsgeheimnisse gibt es viele Möglichkeiten. Organisatorische Maßnahmen können auch schon Klauseln im Arbeitsvertrag oder sogenannte NDAs (Non Disclosure Agreements, Vertraulichkeitsvereinbarungen) in Werkverträgen sein. Damit diese gelten, müssen sie sich jedoch hinreichend konkret auf die Situation im Unternehmen beziehen (so zum Beispiel: LAG Düsseldorf, Urteil vom 03.06.2020, 12 SaGa 4/20) und dürfen nicht zu allgemein sein (sogenannten Catch-all-Klauseln). Der Mindeststandard ist, dass schützenswerte Informationen nur den Personen zugänglich gemacht werden, die die Informationen für ihre Tätigkeit benötigen und die auf Verschwiegenheit verpflichtet sind. Die Personen müssen auch von der Verschwiegenheitsverpflichtung wissen. Weitere zusätzliche Maßnahmen müssen unter Würdigung der

Gesamtumstände in Betracht gezogen werden. (OLG Stuttgart vom 19.11.2020, 2 U 575/19) Je nach Wert und Bedeutung des Geschäftsgeheimnisses müssen auch technische Maßnahmen getroffen werden.

Onlinezugangsgesetz (D) Das Gesetz zur Verbesserung des Onlinezugangs zu Verwaltungsleistungen (Onlinezugangsgesetz – OZG) vom 14. August 2017 (BGBl. I S. 3122, 3138) verpflichtet Bund, Länder und Kommunen bis Ende 2022 Verwaltungsdienstleistungen auch vollständig digital anzubieten. Dies hat auch Auswirkungen auf die IT-Sicherheit, da Verwaltungsdaten über das Internet sicher erreichbar sein müssen. Die Vertraulichkeit und die Integrität der Verwaltungsdaten muss auf Dauer sichergestellt werden. Dieses Gesetz dient auch der Umsetzung der EUVerordnung über die Einrichtung eines einheitlichen digitalen Zugangstors zu Informationen, Verfahren, Hilfs- und Problemlösungsdiensten (Single-Digital-Gateway-Verordnung – SDGVO) vom 2. Oktober 2018. Das OZG sieht vor, dass die IT-Sicherheits-Standards in einer Rechtsverordnung des Bundesministeriums des Innern, für Bau und Heimat vorgegeben werden (§ 5 OZG). Diese Rechtsverordnung liegt Ende 2021, über vier Jahre nach Inkrafttreten des Gesetzes, nur im Entwurf vor. Der Entwurf der IT-Sicherheitsverordnung Portalverbund sieht vor, dass zur »Gewährleistung der IT-Sicherheit Maßnahmen nach dem Stand der Technik zu treffen« sind. Die Einhaltung des Stands der Technik wird unterstellt, wenn entsprechende technische Richtlinien des BSI eingehalten werden. Darüber hinaus muss der IT-Grundschutz gewährleistet werden. Besonders kritische Komponenten (Nutzerkonto, elektronischer Bezahldienst, Postfach und Datensafe) müssen einem Penetrationstest und einem Webcheck nach den Vorgaben des BSI unterzogen werden. Der Entwurf bezieht sich auf einen BSI Standard »200-4 Notfallmanagement«, den es allerdings nicht gibt. Entweder ist

der ältere »100-4 Notfallmanagement« oder der neue »200-4 Business Continuity Management« (Ende 2021 noch im Entwurfsstadium) gemeint. »Die Umsetzung der Maßnahmen ist durch eine jährliche Eigenerklärung der für die jeweilige IT-Komponente verantwortlichen Stelle zu dokumentieren.« heißt es in § 2 Abs. 8 des Entwurfs. Ob eine Eigenerklärung in diesem Bereich ein geeignetes Mittel ist, dürfen wir durchaus anzweifeln. Zur besseren Vergleichbarkeit der Umsetzung des Verwaltungsverfahren wurde ein fünfstufiges Reifegradmodell (siehe Abbildung 6.2) entwickelt. Stufe 0 bedeutet, dass auf den Webseiten der Behörden keinerlei Information zu einem Verwaltungsverfahren zu finden ist (das wären zum Beispiel die Beantragung von Wohngeld oder eines Ausweises oder die Ummeldung eines Kraftfahrzeugs). Stufe 1 ist erfüllt, wenn eine elektronische Information als Text oder PDF-Datei zum Verwaltungsverfahren auf der Webseite zu finden ist. Gibt es ein PDF- oder HTML-Formular, das nach dem Ausfüllen ausgedruckt und (als Papierausdruck) eingeschickt werden kann, ist Stufe 2 erreicht. Bei Stufe 3 und 4 kann der Prozess nach Authentifizierung inklusive Rückübermittlung des Bescheids komplett online abgewickelt werden. Bei Stufe 3 muss ein Nachweis zum Beispiel als PDF-Datei vom Bürger hochgeladen werden. Ist zum Beispiel für ein Antragsverfahren als Einkommensnachweis der letzte Steuerbescheid erforderlich, muss in Stufe 3 eine Kopie (als Scan) hochgeladen werden. In Stufe 4 greift die Behörde nach Freigabe durch den Bürger direkt auf den Datenbestand des Finanzamts zu und »holt sich« den Steuerbescheid. Daten der Bürger werden nur noch einmal gespeichert (Once-Only-Prinzip) und andere Behörden greifen – falls erforderlich und nach Freigabe durch den betroffenen Bürger – darauf zu.

Abbildung 6.2: Das fünfstufige Reifegradmodell zur OZG-Umsetzung der Verwaltungsverfahren durch deutsche Behörden. (basiert auf Digitalisierungsleitfaden Bund)

Eine solche Vernetzung zwischen Bundesbehörden, Landesbehörden und Kommunen stellt hohe Anforderungen an Vertraulichkeit und Integrität der Daten. Auch müssen die Verfahren für die Bürger nachvollziehbar (Anforderung Transparenz) sein. Die Bürger müssen nicht nur wissen, von wo nach wo die Daten fließen. Sie müssen auch wissen, welche Daten fließen. Für die Behörden stellt das OZG ebenfalls eine große Herausforderung und einen fundamentalen Paradigmenwechsel dar. Der Fax-Versand von ausgedruckten Excel-Tabellen (Excel-over-FAX, EoF) ist sicher nicht OZG-konform. Da nicht nur Bürger, sondern auch Unternehmen Verwaltungsverfahren anstoßen können, ist das OZG auch für Unternehmen relevant. Ob es sich um die Online-Verifikation von (Hoch-)Schulzeugnissen (statt beglaubigter Kopien) bei Bewerbern oder um die elektronische Übermittlung von Steuererklärungen handelt, ein Unternehmen muss sich mit dem OZG und den damit verbundenen Anforderungen an eine sichere Integration der neuen Online-Dienste in die Unternehmens-IT auseinander setzen. Gerade die Erfahrungen mit ELSTER haben gezeigt, dass Unternehmen wegen ihres vermuteten größeren IT- und ITSicherheits-Know-hows hier sogar eher in die Pflicht genommen werden als die Bürger. Die sichere Integration der OZG-Verfahren in die

Unternehmensprozesse stellt in den nächsten Jahren eine erhebliche Herausforderung für Unternehmen dar.

Sozialgesetzbuch V (D) Durch das Digitale-Versorgungs-Gesetz vom 9. Dezember 2019 (BGBl. I S. 2562) wurde der § 75b in das SGB V eingefügt. Dieser Paragraph gab den kassenärztlichen Bundesvereinigungen auf, bis zum 30. Juli 2020 in einer Richtlinie die Anforderungen zur Gewährleistung der ITSicherheit in Arzt- und Zahnarztpraxen festzulegen. Die beiden wörtlich identischen Richtlinien sind Anfang 2021 in Kraft getreten. Die Anforderungen in den Richtlinien für die IT-Sicherheit in ärztlichen und zahnärztlichen Praxen müssen dem Stand der Technik entsprechen und sind jährlich an den Stand der Technik und an das Gefährdungspotenzial anzupassen. Die Anpassungen müssen dabei »im Einvernehmen mit dem Bundesamt für Sicherheit in der Informationstechnik sowie im Benehmen mit dem oder der Bundesbeauftragten für den Datenschutz und die Informationsfreiheit, der Bundesärztekammer, der Bundeszahnärztekammer, der Deutschen Krankenhausgesellschaft und den für die Wahrnehmung der Interessen der Industrie maßgeblichen Bundesverbänden aus dem Bereich der Informationstechnologie im Gesundheitswesen« sowie »im Benehmen mit der Gesellschaft für Telematik« erfolgen. Das ist – betrachtet man die Verzögerungen beim erstmaligen Erstellen der Richtlinien – zeitlich fast nicht zu leisten, da es zeitaufwendig ist, den erforderlichen Konsens zwischen den Beteiligten herzustellen. Die Richtlinie und damit die Umsetzung der Maßnahmen in der Richtlinie ist für die Praxen verpflichtend, die Nicht-Umsetzung wird jedoch nicht sanktioniert. Eine indirekte Sanktionierung dürfte trotzdem erfolgen. Kommt es in einer Praxis zu einem Datenschutz- oder ITSicherheitsvorfall, wird die Höhe eines Bußgelds oder eine zivilrechtliche Haftung von der Umsetzung der Vorgaben der Richtlinie abhängen, welche damit dann doch finanzielle Konsequenzen hätte.

Auch wenn die Richtlinie noch Optimierungspotenzial hat, zeigt sie doch, wie man dem Risiko angemessen und auf die Größe der Praxis abgestimmt Maßnahmen vorgibt. Die Praxisgrößen sind: (kleine) Praxis mit bis zu fünf ständig mit der Datenverarbeitung betrauten Personen, mittlere Praxis mit sechs bis 20 ständig mit der Datenverarbeitung betrauten Personen, große Praxis mit mehr als 20 ständig mit der Datenverarbeitung betrauten Personen oder mit einem über die normale Datenübermittlung hinausgehenden Umfang der Datenverarbeitung. Jede Praxis muss auch die Maßnahmen der kleineren Praxen umsetzen. Für Großgeräte wie Computertomografen und die Geräte der TelematikInfrastruktur (Konnektoren; das sind spezielle Geräte für VPNVerbindungen) sind spezielle Maßnahmen vorgesehen. Die Priorisierung erfolgt über das Umsetzungsdatum. Je schneller eine Maßnahme umgesetzt werden muss, je höher ist die Priorität. Die Vorgaben waren P1 bis zum 1. April 2021, P2 bis zum 1. Juli 2021, P3 bis zum 1. Januar 2022 und P4 bis zum 1. Juli 2022. Während Arztpraxen insgesamt nicht auf Basis dieser Richtlinie zertifiziert werden können, gibt es jedoch eine Zertifizierungsrichtlinie für Beschäftigte von IT-Dienstleistern für Arztpraxen. Setzt eine Arztpraxis nur Dienstleister mit zertifizierten Beschäftigten ein, kann im ersten Augenschein dargelegt werden, dass der Praxisinhaber sich um die IT-Sicherheit bemüht. In Abbildung 6.3 sind zusätzlich zur Priorisierung auch die Zahl der Maßnahmen aufgelistet. »P1-3« heißt drei Maßnahmen mit Priorität 1. Insgesamt ist die Richtlinie ein gutes Beispiel, wie Sie bei der Erstellung einer internen Richtlinie vorgehen können. Die konkreten technischen

Maßnahmen sind allerdings noch optimierungsbedürftig. Es fehlen zum Beispiel Vorgaben zur Verschlüsselung von Datenträgern in Rechnern.

Abbildung 6.3: Die Priorisierung P1 bis P4 sowie die Zahl der Maßnahmen für kleine, mittlere und große Praxen. (GG = Großgeräte; TI = Telematik-Infrastruktur)

Durch das Gesetz zum Schutz elektronischer Patientendaten in der Telematik-Infrastruktur (Patientendaten-Schutz-Gesetz) vom 14. Oktober 2020 (BGBl I S. 2115) wurde der § 75c in das SGB V eingefügt. Danach müssen kleine Krankenhäuser, das heißt Krankenhäuser mit weniger als 30.000 stationären Fällen pro Jahr, »nach dem Stand der Technik angemessene organisatorische und technische

Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität und Vertraulichkeit sowie der weiteren Sicherheitsziele ihrer informationstechnischen Systeme, Komponenten oder Prozesse treffen, die für die Funktionsfähigkeit des jeweiligen Krankenhauses und die Sicherheit der verarbeiteten Patienteninformationen maßgeblich sind«. Diese Vorgaben können insbesondere durch die Einhaltung der Vorgaben nach § 8a BSI-Gesetz eingehalten werden. Damit ergibt sich für die medizinische Versorgung in Deutschland eine Verteilung der IT-Sicherheitsvorgaben über zwei verschiedene Gesetze mit unterschiedlichen Regelungskonzepten. Krankenhäuser müssen angemessene IT-Sicherheitsvorgaben einhalten. Große Krankenhäuser müssen alle zwei Jahre Audit-Reports über die Einhaltung der ITSicherheitsvorgaben beim BSI einreichen. Solche großen Krankenhäuser können auch sanktioniert werden, wenn sie die Vorgaben nicht einhalten. Kleine Krankenhäuser müssen ihre informationstechnischen Systeme spätestens alle zwei Jahre an den aktuellen Stand der Technik anpassen. Hier sind ähnlich wie bei Arztpraxen keine Nachweise und keine Sanktionen vorgesehen. Sie können aber davon ausgehen, dass sich dies ändert, wenn die Umsetzung zu wünschen übrig lässt. Eine wesentliche Rolle bei den IT-Sicherheitsvorgaben spielt der »Branchenspezifische Sicherheitsstandard für die Gesundheitsversorgung im Krankenhaus« der Deutschen Krankenhausgesellschaft. Dieser B3S ist vom BSI genehmigt. Abbildung 6.4 zeigt eine Übersicht über die unterschiedlichen Regelungsbereiche in der medizinischen Versorgung.

Abbildung 6.4: Je nach Größe einer ärztlichen beziehungsweise zahnärztlichen Praxis oder eines Krankenhauses gelten unterschiedliche gesetzliche Vorgaben.

Die unterschiedlichen zeitlichen Vorgaben (»alle zwei Jahre« und »jährlich«) sollten vereinheitlicht werden. Auch die Vorgabe der Schutzziele »Verfügbarkeit, Integrität und Vertraulichkeit sowie der weiteren Sicherheitsziele« ist letztendlich unbestimmt und offen. Auch der Schutzgegenstand ist unterschiedlich geregelt: Es geht um angemessene organisatorische und technische Vorkehrungen zur Vermeidung von »Störungen der informationstechnischen Systeme, Komponenten oder Prozesse« »der vertragsärztlichen Leistungserbringer« (Arzt- und Zahnarztpraxen, §75b SGB V), »die für die Funktionsfähigkeit des jeweiligen Krankenhauses und die Sicherheit der verarbeiteten Patienteninformationen maßgeblich sind« (kleine Krankenhäuser, §75c SGB V) und »die für die Funktionsfähigkeit der von ihnen betriebenen kritischen Infrastrukturen maßgeblich sind« (große Krankenhäuser, §8a BSIGesetz). Diese Formulierungen beschreiben zwar sehr ähnliche Schutzgegenstände, eine Vereinheitlichung der Formulierungen würde jedoch sicherlich zu mehr Klarheit und Transparenz beitragen.

TKG, TMG und TTDSG (D) Der Bundestag hat im Jahr 2021 ein neues Telekommunikationsgesetz (TKG) (BGBL I, S. 1858) beschlossen. Auch im TKG werden detaillierte Vorgaben zur IT-Sicherheit (§§ 165 ff. TKG) gemacht. Die Regelungen gelten für Unternehmen, die Telekommunikationsdienste erbringen oder daran mitwirken, öffentliche Telekommunikationsdienste erbringen oder öffentliche Telekommunikationsnetze betreiben. Je nach Gruppe gelten unterschiedliche Vorgaben, die Tabelle 6.1 zusammenfasst. TK-Dienste

öffentliche TK-Netze

erbringen daran mitwirken öffentliche erbringen

betreiben

Fernmeldegeheimnis Schutz personenbezogener Daten KRITIS-Registrierung (BSI-Gesetz) KRITIS-Registrierung (BSI-Gesetz) Schutz gegen Störungen Beherrschung der Risiken Systeme zur Angriffserkennung Sicherheitsbeauftragter Ansprechpartner innerhalb EU Sicherheitskonzept Meldung Sicherheitsvorfall Meldung DS-Vorfall Tabelle 6.1: Die Regelungen der §§ 165–169 TKG haben vier unterschiedliche Gruppen von Adressaten. Auch das BSI-Gesetz gilt bis auf die §§ 8a und 8b Abs. 4 und 4a.

Entsprechend große Unternehmen können auch zum KRITIS-Bereich gehören, allerdings gelten für »Betreiber kritischer Infrastrukturen, soweit sie ein öffentliches Telekommunikationsnetz betreiben oder öffentlich zugängliche Telekommunikationsdienste erbringen« die §§ 8a und 8b Abs. 4 und 4a des BSI-Gesetzes nicht. Hier gehen die entsprechenden Regeln des TKG vor. Diese Ausnahmen bezüglich der Geltung zeigen auch wieder, dass ein vereinheitlichtes Informationssicherheitsgesetz sinnvoll wäre. Was ist mit den Betreibern von »Callshops, Internetcafés, Hotels/Restaurants mit WLAN-Angebot, Hotspots und vergleichbaren Angeboten«? Diese bieten ja möglicherweise TK-Dienste für die Öffentlichkeit an. Hierzu hat die Bundesnetzagentur in ihrer Mitteilung 149/2015 klargestellt, dass diese Betreiber lediglich an der Erbringung von (öffentlichen) Telekommunikationsdiensten mitwirken. Deshalb gelten für sie die Vorgaben für Erbringer öffentlicher TK-Dienste nicht. Das TKG ist das einzige Gesetz in Deutschland, in dem ein (IT-)Sicherheitsbeauftragter und ein (IT-)Sicherheitskonzept für Unternehmen, die öffentliche TK-Dienste erbringen, explizit vorgeschrieben sind. Das Sicherheitskonzept ist der Bundesnetzagentur vorzulegen – inklusive einer Erklärung, dass die Maßnahmen umgesetzt sind. Auch im TKG gibt es eine Regelung zum Einsatz von Angriffserkennungssystemen, und zwar in § 165 Abs. 3. Betreibern öffentlicher TK-Netze und Anbietern öffentlicher TK-Dienste wird der Einsatz empfohlen (»können … einsetzen«). Existiert ein erhöhtes Gefährdungspotenzial, müssen die Betreiber (»haben … einzusetzen«) ein Angriffserkennungssystem einsetzen. Das TMG enthält keine Regelungen mit Relevanz zur IT-Sicherheit mehr, da diese in das TTDSG verschoben wurden. Das TKG a. F. und das TMG sind noch vor der DS-GVO entstanden und in dem ersten und dem zweiten Gesetz zur Anpassung des Datenschutzrechts an die DS-GVO (DSAnpUG-EU) nicht angepasst worden. Da gleichzeitig die Unterscheidung in Telekommunikation und

Telemedien immer mehr verschwimmt, wurden die Datenschutzregelungen von TKG und TMG im TelekommunikationsTelemedien-Datenschutz-Gesetz (TTDSG) zusammengeführt und gleichzeitig an die DS-GVO angepasst. Das TTDSG ist am 1. Dezember 2021 in Kraft getreten. Das wichtige »Fernmeldegeheimnis« ist jetzt in § 3 TTDSG wortgleich wie vorher im TKG geregelt. In Abs. 2 ist eine für die IT-Sicherheit wichtige Ausnahme geregelt: Sie dürfen Daten, die dem Fernmeldegeheimnis unterliegen, im erforderlichen Umfang für den Schutz der eigenen technischen Systeme verarbeiten. Gemeint sind damit die Systeme, die Daten verarbeiten, welche dem Fernmeldegeheimnis unterliegen. Sie dürfen auch (§ 12 Abs. 1) Verkehrs- und Steuerdaten (damit sind zum Beispiel Protokolldaten gemeint) zur Eingrenzung von Störungen und Fehlern verarbeiten. Auch in diesem Fall gilt der Grundsatz der Erforderlichkeit. Ein wenig bekannter Paragraf ist § 8 TTDSG. Danach ist es Ihnen verboten, eine Telekommunikationsanlage zu besitzen, die sich als Alltagsgegenstand tarnt, und die in der Lage ist, Ton oder Bild aufzunehmen. Die berühmte Anziehpuppe mit eingebauter Webcam zur Überwachung der eigenen Kinder ist also rechtswidrig. § 19 macht noch einige technische und organisatorische Vorgaben für Anbieter von Telemedien (das sind auch Sie, wenn Sie zum Beispiel Webseiten anbieten). Abs. 4 fordert von Ihnen technische und organisatorische Vorkehrungen nach dem Stand der Technik zum Schutz Ihrer technischen Systeme (zum Beispiel Webserver) vor unerlaubtem Zugriff, Störungen und äußeren Angriffen. Ein »als sicher anerkanntes Verschlüsselungsverfahren« wird Ihnen explizit nahegelegt. Daraus können Sie direkt folgern, dass Webserver mit TLS-Verschlüsselung zu betreiben sind.

Als die Regelung des § 19 Abs. 4 TTDSG ursprünglich als § 13 Abs. 7 in das TMG eingefügt wurde, hat die Bundesregierung das wie folgt begründet (Bundestagsdrucksache 18/4096): »Ein wesentliches Ziel der Regelung ist es, einen der Hauptverbreitungswege von Schadsoftware einzudämmen: das unbemerkte Herunterladen allein durch das Aufrufen beziehungsweise Nutzen einer dafür von Angreifern präparierten Website (sogenannte Drive-by-Downloads). Bereits durch eine regelmäßige Aktualisierung der für das Telemedienangebot verwendeten Software (Einspielen von Sicherheitspatches) seitens der Webseitenbetreiber könnten zahlreiche dieser Angriffe vermieden werden. Kompromittierungen können zudem auch durch Inhalte erfolgen, auf die der Diensteanbieter keinen unmittelbaren technischen Einfluss hat (zum Beispiel über kompromittierte Werbebanner, die auf der Webseite eingebunden sind). Dagegen sind organisatorische Vorkehrungen zu treffen. Hierzu zählt beispielsweise, Werbedienstleister, denen Werbefläche eingeräumt wird, vertraglich zu notwendigen Schutzmaßnahmen zu verpflichten. Die entsprechenden Maßnahmen sind im Rahmen der jeweiligen Verantwortlichkeit zu treffen.« Das TMG enthält umfangreiche Auskunftspflichten (§§ 22 ff.) gegenüber Sicherheitsbehörden, die sehr ähnlich auch im TKG (§§ 173 ff.) enthalten sind. Die Auskunftung von Zugangsdaten (zum Beispiel Passwörtern) ist allerdings für Telekommunikationsanbieter (§ 174 TKG) und Anbieter von Telemedien (§ 23 TTDSG) unterschiedlich geregelt. Bei den Auskunftspflichten hat die Zusammenführung noch nicht ganz funktioniert. In den §§ 25 f. finden Sie dann so etwas wie eine nationale MiniePrivacy-Regelung. Dort geht es um die Speicherung von und den Zugriff auf Informationen in Endgeräten. Damit sind definitiv auch Cookies gemeint, die Formulierung ist aber sehr viel weiter gefasst.

Insgesamt sind die gesetzlichen Vorgaben zur Informationssicherheit in Deutschland über zu viele Gesetze verteilt. Auch die Tatsache, dass die IT-Sicherheitsgesetzgebung zu einem großen Teil im BSI-Gesetz stattfindet, ist ungewöhnlich. In einem Gesetz für die Behörde BSI sollten nur die Aufgaben des BSI geregelt werden. Die Vorgaben für die Unternehmen gehören in ein eigenes Gesetz. Der § 8d BSI-Gesetz sagt im Wesentlichen, dass die §§ 8a und b BSI-Gesetz nicht für KRITIS-Unternehmen gelten, für die Regelungen zur Informationssicherheit in einem speziellen Gesetz stehen (TKG, Atom-Gesetz, Energiewirtschaftsgesetz und so weiter). Das ist ein ziemliches Hin und Her, wenn Sie sich mit der Rechtslage vertraut machen wollen.

Kapitel 7

ISO-Normen IN DIESEM KAPITEL Inhalte der ISO-Normen 270xx Anforderungen und Leitfäden Datenschutz nach ISO

Die Geschichte der IT-Sicherheitsstandards begann im Jahr 1985 mit den Trusted Computer System Evaluation Criteria (TCSEC), besser bekannt als Orange Book. Dieser Standard wurde vom Amerikanischen Verteidigungsministerium veröffentlicht. Darin wurde das ITSicherheitsniveau »C2« definiert. In Europa wurden 1990 die Information Technology Security Evaluation Criteria (ITSEC) veröffentlicht. Und 1996 wurden TCSEC und ITSEC durch den internationalen Standard »Common Criteria« abgelöst. Aktuell ist Common Criteria in der Version 3.1 Release 5 aus dem Mai 2017. Mit zeitlichem Verzug werden die Änderungen in den ISO Standard 15408 übernommen. Allen diesen Standards ist gemein, dass sie für Bewertung und Prüfung der IT-Sicherheit von IT-Geräten gemacht sind. »Microsoft Windows NT ist C2-zertifiziert.« Mit dieser Aussage begründeten früher IT-Administratoren die Sicherheit ihrer NT-4Domain. Keiner der Administratoren hatte jemals das Zertifikat (CSC-FER-95/003 vom 29. April 1996) gesehen, geschweige denn gelesen. Zertifiziert waren Windows NT 3.5 Service Pack 3 in den Versionen Workstation und Server. Aber nur in einer bestimmten Softwarekonfiguration (OS/2 und Posix Subsystem deaktiviert) und wenn keine (!) Netzwerkkarte im Rechner steckte.

NT 4 war nie zertifiziert und Netzwerkkarten hatten die WindowsNT-4-Rechner alle. Die Konfiguration, die zertifiziert war, hatte nichts mit der Konfiguration zu tun, die genutzt wurde! Was lernen wir daraus: Bevor Sie sich auf eine Zertifizierung berufen, lesen Sie den Zertifizierungsreport … In Großbritannien wurde in den 1990er Jahren der erste Standard zur guten Praxis der Einführung und Organisation von IT-Sicherheit in Unternehmen geschrieben. Dabei ging es darum, die Informationsverarbeitungsprozesse im Unternehmen sicher zu gestalten. 1998 veröffentlichte die British Standard Institution (BSI, nicht zu verwechseln mit dem deutschen Bundesamt) die Normen BS7799-1 und BS7799-2, die von der ISO unter ISO 17799 und ISO 27001 aufgegriffen wurden. Die ISO 17799 wurde später umbenannt in ISO 27002. Allen IT-Sicherheitsstandards ist gemein, dass sie die Einführung und gegebenenfalls auch die Prüfung von IT-Sicherheit systematisieren und methodisch sauber gestalten wollen. IT-Sicherheit sollte nicht mehr von der zufälligen Expertise der Personen vor Ort abhängen, sondern vereinheitlicht werden. Die Einheitlichkeit ermöglicht Ihnen auch eine Vergleichbarkeit der IT-Sicherheit, sowohl mit anderen Unternehmen aber auch zu verschiedenen Zeitpunkten in der eigenen Organisation.

ISO/IEC 270xx Informationssicherheit Die Standard-Familie ISO/IEC 270xx besteht aus über 30 Einzelnormen, darunter ISO/IEC 27000:2018 Überblick und Terminologie, ISO/IEC 27001:2013cor2 Anforderungen an ein Informationssicherheits-Managementsystems (ISMS), ISO/IEC 27002:2013cor2 Leitfaden für Maßnahmen zur Informationssicherheit (basiert auf BS 7799-1),

ISO/IEC 27003:2017 Leitfaden zur Umsetzung der 27001, ISO/IEC 27004:2016 Messen, Analyse und Evaluierung des ISMS, ISO/IEC 27005:2018 Risikomanagement (analog zu BS 7799-3), ISO/IEC 27006:2015 Anforderungen an Prüfstellen, ISO/IEC-27006-2:2021 Anforderungen an Prüfstellen, Teil 2: PIMS, ISO/IEC 27007:2020 Leitfaden für die Durchführung von Audits, ISO/IEC 2701x weitere branchenspezifische Standards, ISO/IEC 27701:2019 Erweiterung zu ISO/IEC 27001 und ISO/IEC 27002 für das Datenschutzmanagement – Anforderungen und Leitfaden, ISO 27799 Anforderungen an den Gesundheitssektor, Standards zu speziellen Maßnahmen: ISO/IEC 2702x, 2703x, 2704x und 2710x. Abbildung 7.1 gibt noch einmal eine Übersicht zur Einordnung der ISO/IEC 27000er Standard-Familie. Bei den Normen wird nach der Nummer durch einen Doppelpunkt getrennt das Jahr der Veröffentlichung angegeben. Sind Korrekturen erfolgt, wird dies als Korrektur 1 oder 2 (oben cor2) hinter der Jahreszahl angegeben. Die vorstehend angegebenen Jahreszahlen beziehen sich auf die englischen Ausgaben der Standards. Die deutschen Übersetzungen, die es nicht für alle Standards gibt, haben unter Umständen abweichende Jahreszahlen. Die ISO/IEC 27701 ist zweimal aufgeführt, da der Abschnitt 5 (A5) Anforderungen stellt und der Abschnitt 6 (A6) einen Leitfaden vorgibt.

Abbildung 7.1: Übersicht über die ISO-Normen der ISO/IEC 27000er Standard-Familie; TR: technische Richtlinie. (Quelle: basiert auf ISO/IEC 27000:2018)

ISO-Normen lesen ISO-Normen sind bis auf wenige Ausnahmen weder in englischer noch in deutscher Sprache kostenlos erhältlich. Lediglich die Inhaltsverzeichnisse und der »informative Teil« (meist Abschnitte 1 bis 3) sind frei zugänglich. Im Abschnitt 3 finden Sie dann auch in der Regel die Begriffsbestimmungen. Damit ist es schwierig, für ein Selbststudium an den eigentlichen Inhalt der Normen zu kommen. Aus der 27000er Familie sind nur die 27000 und die 27036 in englischer Sprache vollständig frei verfügbar. Soweit die ISO-Normen auch als DIN-Normen verfügbar sind (27000, 27001, 27002 und 27701 sind als DIN-Normen in deutscher Sprache erhältlich), können Sie diese an sogenannten Normen-Infopoints (Auslegestellen) kostenlos einsehen (ausdrucken oder kopieren ist nicht möglich). Diese Infopoints sind in der Regel in großen (Universitäts-)Bibliotheken. Studierende können für Studienzwecke oft DIN-Normen als PDF-Dateien über ihre Universitätsbibliothek herunterladen.

Mit der ISO/IEC 27000, die in englischer Sprache frei verfügbar ist, können Sie sich sehr gut mit den (englischen) Begrifflichkeiten der ISOReihe vertraut machen. Insgesamt werden 77 Begriffe von »abgeleitete Messgröße« (»derived measure«) über »Risiko« (risk) bis »Zuverlässigkeit« (reliablility) abstrakt definiert. Diese Norm beschreibt in Abschnitt 4 einführend und kurz die Zwecke und den fortlaufenden Betrieb eines InformationssicherheitsManagementsystems (ISMS). Das gibt Ihnen die Möglichkeit sich mit

dem Sprachstil und der Darstellungsweise einer ISO-Norm auseinander zu setzen. Die ISO/IEC 27000 gibt in Abschnitt 5 auch eine Kurzübersicht über »Anwendungsbereiche« (Scope) und »Zwecke« (Purpose) der anderen Normen in der 27000er Familie. Wenn Sie in Ihrem Unternehmen zweisprachig agieren, zum Beispiel auf Deutsch und Englisch, so empfiehlt es sich, ein eigenes Wörterbuch mit den wichtigsten Begriffen der Informationssicherheit zu erstellen. Nur so ist gewährleistet, dass Sie die Begriffe immer identisch übersetzen. Die ISO/IEC 27000 ist in Deutsch und in Englisch verfügbar und liefert damit eine gute Grundlage zum Erstellen einer derartigen Übersetzungshilfe.

Anforderungsnormen Drei Normen der ISO 27000 Reihe geben Anforderungen vor. Die ISO/IEC 27001 definiert die Anforderungen für die Einrichtung, die Umsetzung, den laufenden Betrieb und die ständige Verbesserung eines ISMS. Diese Anforderungen decken die folgenden Bereiche ab: Einbettung des ISMS in die Organisation des Unternehmens (Abschnitt 4), Verantwortung der Leitung des Unternehmens für die Informationssicherheit (Abschnitt 5), Planung des ISMS (Abschnitt 6), Unterstützung und Ressourcen (Abschnitt 7), laufender Betrieb des ISMS (Abschnitt 8), Bewertung der erreichten Informationssicherheit (Abschnitt 9), Verbesserung der Informationssicherheit (Abschnitt 10), Ziele der und Vorgaben zu den Standardmaßnahmen (Anhang A).

Der Anhang A dieser Norm ist eine Kurzfassung der ISO/IEC 27002. Er beginnt in der Nummerierung deshalb auch mit Nummer 5, um den direkten Bezug zur 27002 zu behalten. Ihr Unternehmen muss die Anforderungen der Abschnitte 4 bis 10 vollständig umgesetzt haben, damit Ihr Unternehmen sich als ISO 27001-konform bezeichnen kann. Dabei sind die grundlegenden Anforderungen an ein Managementsystem unabhängig davon, ob es sich um ein ISMS, ein Qualitätsmanagementsystem (QM-System) wie in der ISO 9001 oder um ein Umweltmanagementsystem wie in der ISO 14001 handelt. ISO 9001 und ISO 14001 verwenden die gleiche Methodik und haben einen mit den hier vorgestellten Abschnitten 4 bis 10 identischen Aufbau. Die Anforderungen an ein Managementsystem orientieren sich dabei an dem PDCA-Zyklus (siehe Kapitel 12) mit der folgenden Zuordnung: Plan: Abschnitte 4 bis 6, Do: Abschnitte 7 bis 8, Check: Abschnitt 9, Act: Abschnitt 10. Die Einhaltung der ISO/IEC 27001 kann, genau wie bei der ISO 9001 durch ein Audit zertifiziert werden. Sie müssen dabei klar unterscheiden zwischen dem Managementsystem (ISO/IEC 27001, ISO 9001 oder ISO 14001), das zertifiziert werden kann, und der Umsetzung der technischorganisatorischen Maßnahmen (entspricht zum Beispiel der Produktqualität beim Qualitätsmanagement), die sich nicht zertifizieren lässt. Überspitzt können wir das so formulieren: Der Managementprozess zur Erreichung der Informationssicherheit kann zertifiziert werden, die Qualität und Sinnhaftigkeit der technischen Maßnahmen zur Umsetzung der Informationssicherheit können es nicht. Der Anhang A der ISO/IEC 27001 listet kurz die Maßnahmen zu den folgenden Regelungsbereichen auf:

A.5

Richtlinien zur Informationssicherheit; 2 Maßnahmen

A.6

Informationssicherheitsorganisation; 7 Maßnahmen

A.7

Sicherheitsaspekte beim Personal; 6 Maßnahmen

A.8

Management der Vermögenswerte; 10 Maßnahmen

A.9

Steuerung des Zugangs; 14 Maßnahmen

A.10 Kryptografie; 2 Maßnahmen A.11 Physische Sicherheit und Sicherheit der Umgebung; 15 Maßnahmen A.12 Sicherheit des Betriebs; 14 Maßnahmen A.13 Sicherheit der Kommunikation; 7 Maßnahmen A.14 Beschaffung, Entwicklung und Instandhaltung von Systemen; 13 Maßnahmen A.15 Beziehungen zu Lieferanten; 5 Maßnahmen A.16 Umgang mit Informationssicherheitsvorfällen; 7 Maßnahmen A.17 Informationssicherheit beim Business Continuity Management; 4 Maßnahmen A.18 Compliance; 8 Maßnahmen

Die aufgelisteten Regelungsbereiche haben jeweils noch zwei weitere Unterebenen der Konkretisierung. Die Maßnahmen sind in der ISO/IEC 27001 in der Umsetzung formuliert (zum Beispiel: »Es wird ausreichend Kontakt mit zuständigen Behörden unterhalten.«), während sie in der ISO/IEC 27002 als Anforderungen (zum Beispiel: »Es soll ausreichend Kontakt mit den zuständigen Behörden unterhalten werden.«) formuliert sind. Bei den Kontrollzielen überlappen sich die Anforderungen an die technisch-organisatorischen Maßnahmen nach der DS-GVO und dem BDSG. DS-GVO/BDSG

ISO 27001/27002

Zutrittskontrolle

Physische Sicherheit und Sicherheit der Umgebung

Zugangs-/Zugriffskontrolle Verschlüsselung Weitergabekontrolle

Steuerung des Zugangs Kryptografie Sicherheit der Kommunikation

DS-GVO/BDSG Verfügbarkeitskontrolle Auftragskontrolle

ISO 27001/27002 Informationssicherheit beim BCM Beziehungen zu Lieferanten

Während die DS-GVO lediglich in der Aufgabenbeschreibung der Datenschutzbeauftragten eine Schulungsverpflichtung für die Beschäftigten der verantwortlichen Stelle festschreibt (Art. 39 Abs. 1 Lit. a), fordert die ISO/IEC 27001 unter »Sicherheitsaspekte beim Personal« hier deutlich mehr und zwar sowohl vor und während des Beschäftigungsverhältnisses als auch bei Beendigung des Beschäftigungsverhältnisses. Zum Beispiel werden vor dem Beschäftigungsverhältnis die Themen Sicherheitsüberprüfung und Arbeitsvertragsinhalt diskutiert. Die ISO/IEC 27006 legt die Anforderungen fest, die ein Unternehmen erfüllen muss, um als Zertifizierungsstelle ein ISMS nach ISO/IEC 27001 auditieren und zertifizieren zu dürfen. Die ISO/IEC 27009 definiert die Anforderungen an einen branchenspezifischen Standard und richtet sich an Gremien, Organisationen oder Verbände, die selber Standards erstellen wollen. Sie ist für normale Unternehmen kaum von Bedeutung.

Leitfäden Neben der ISO/IEC 27001 ist die Norm ISO/IEC 27002 eine der Wichtigeren. Sie ist der Leitfaden zur Umsetzung der IT-Sicherheit. Jeder der 14 Regelungsbereiche ist nochmals in ein bis sieben Kategorien unterteilt. Für jede Kategorie gibt es ein definiertes Ziel. So lautet zum Beispiel das Ziel der Kategorie »9.3 Verantwortlichkeit des Benutzers« in Worten: »Benutzer sind auf den notwendigen Schutz Ihrer Anmeldedaten (zum Beispiel Passwörter) hingewiesen worden.« Hierzu gibt es dann eine Maßnahme »9.3.1 Gebrauch geheimer Anmeldedaten«. Die Nutzerinnen sollen verpflichtet werden, die Regeln zum Umgang mit vertraulichen Anmeldedaten einzuhalten. Diese Maßnahme entspricht im Anhang der ISO/IEC 27001 der Nummer A.9.3.1.

Neben der Kurzbeschreibung einer Maßnahme gibt es dann jeweils eine Rubrik »Anleitung zur Umsetzung« sowie eine Rubrik »Weitere Informationen«. In der Rubrik »Anleitung zur Umsetzung« erhalten Sie sehr detaillierte Empfehlungen zur Umsetzung der Maßnahme. Im konkreten Beispiel der Anmeldedaten werden die Punkte aufgelistet, die Sie beim Erstellen einer Passwort-Richtlinie für Ihr Unternehmen beachten müssen. In der Rubrik »Weitere Informationen« werden einige Punkte genannt, die Sie möglichst beachten sollten. Im konkreten Beispiel ist dies der Hinweis, dass sich die Zahl der Passwörter, mit denen die Nutzerinnen umgehen müssen, zwar durch Single Sign-on (SSO) reduzieren lässt. Gleichzeitig steigt jedoch das Risiko, dass eine Kompromittierung des SSO-Passworts weitreichendere Folgen hat, da der Zugang zu mehr als einem System möglich sein kann. Eine Zertifizierung nach ISO/IEC 27002 ist nicht möglich. Die ISO/IEC 27003 gibt eine Anleitung zur Spezifikation und zur Umsetzung eines ISMS-Einführungsprojekts im Unternehmen. In der ISO/IEC 27004 lernen Sie, wie Sie die Effektivität Ihres ISMS und Ihrer Maßnahmen messen und dann auch verbessern können. Der Anhang B listet 37 Beispiele zum Messen, Analysieren und Berichten auf. Die ISO/IEC 27005 beschäftigt sich mit dem Risikomanagement in der Informationssicherheit. Sie erfahren in dem Standard, wie Sie ein Risikomanagement aufziehen und wie Sie durch Risikoüberwachung auch Veränderungen beim Risiko in den Griff bekommen. Die ISO/IEC 27006 wird ergänzt durch die ISO/IEC 27007, die beschreibt, wie ein ISMS auditiert wird. Dieser Leitfaden orientiert sich im Wesentlichen an der ISO 19011, einem generischen Leitfaden zur Auditierung von Managementsystemen. Es gibt einige bereichsspezifische Leitfäden, die die Besonderheiten von Branchen oder Situationen berücksichtigen. Dies sind im Einzelnen diese Standards:

ISO/IEC 27010: Diese Leitlinie beschäftigt sich mit dem Teilen von IT-Sicherheitsinformationen mit Partnern innerhalb oder außerhalb der eigenen Branche (Information Sharing). ISO/IEC 27011: In dieser Leitlinie geht es um ITSicherheitsmaßnahmen für Telekommunikationsunternehmen. ISO/IEC 27017: Diese Leitlinie erweitert die ISO/IEC 27002 um Maßnahmen für die IT-Sicherheit bei Cloud-Diensten. ISO/IEC 27018: In dieser Leitlinie geht es um den Schutz personenbezogener Daten in öffentlich zugänglichen CloudDiensten. Sie basiert auf der ISO/IEC 29100, einer Rahmennorm zum Datenschutz in der Informationstechnik. ISO/IEC 27019: Diese Leitlinie beschäftigt sich mit der ITSicherheit der informationstechnischen System in der Energieversorgung, soweit sie nicht mit Nukleartechnik zu tun hat. ISO/IEC 27799: Diese Leitlinie beschäftigt sich mit dem ISMS im Gesundheitswesen. Sie ergänzt die ISO/IEC 27002 für diesen Bereich. IT-Grundschutz und die ISO/IEC 27000er Familie haben ein sehr ähnliches Vorgehen. Ausgehend von einer Betrachtung der Gefährdungen und dem potenziellen Schaden kommen wir zu dem Schutzbedarf der Daten oder Systeme. Um den Gefährdungen zu begegnen, gibt es Maßnahmen. Je nach Höhe des Schutzbedarfs kommen unterschiedliche Maßnahmen zum Einsatz. Das ist ein an sich gradliniger Prozess, dessen Tücken allerdings im Detail stecken. Der konkrete Umgang im Unternehmen mit der Analyse der Gefährdungen und der Beurteilung der Schäden (Modellierung), um zum Schutzbedarf zu kommen, ist aufwendig. Eine Orientierung an den ISO-Normen ist allen Unternehmen nahezulegen, die IT-Sicherheit in einem internationalen Kontext betreiben und nachweisen müssen. Ist ein Unternehmen ausschließlich in Deutschland tätig oder sind die wesentlichen Kunden öffentliche Stellen, ist eine Orientierung am IT-Grundschutz möglich. Eine zwingende Vorgabe zum Einhalten dieser Standards gibt es nicht. Aus den Vorgaben

in den verschiedenen Rechtsvorschriften, sich am berühmten »Stand der Technik« zu orientieren, lässt sich die Orientierung an den Standards herleiten, da diese den »Stand der Technik« abbilden. Die auf dem Konsens der Beteiligten beruhende Aktualisierung der Standards führt zu Zeitskalen (typisch alle fünf Jahre eine Aktualisierung), die nicht kompatibel mit den Zeitskalen der ITEntwicklung (alle zwei Jahre eine neue IT-Generation) sind. Hier werden wir über eine Beschleunigung der Fortschreibung der Normen nachdenken müssen. Und außerdem: müssen Normen eigentlich immer als statische Papier- oder PDF-Dokumente vorliegen oder lässt sich das dynamisieren, indem einzelne Absätze oder Abschnitte, die aktualisiert sind, sofort verfügbar gemacht werden?

ISO/IEC 27701 Datenschutz Der Standard ISO/IEC 27701 erweitert die Standards ISO/IEC 27001 um Anforderungen und die ISO/IEC 27002 um Leitlinien zum Management des Datenschutzes. In dem Standard wird das ISMS zu einem Datenschutz-Managementsystem (Personal Information Management System, PIMS) erweitert. Personenbezogene Daten werden in der englischen Version als »Personally Identifiable Information« (PII) bezeichnet. Die Abkürzung PII finden Sie auch in der deutschen Fassung. Der Standard besteht aus vier wesentlichen Abschnitten (die Nummerierung der Abschnitte wurde beibehalten): 5. Ergänzende Anforderungen des Datenschutzes zur ISO/IEC 27001 6. Ergänzende Leitlinien zur ISO/IEC 27002 7. Ergänzende Leitlinie für verantwortliche Stellen zur ISO/IEC 27002 8. Ergünzende Leitlinie für Auftragsverarbeiter zur ISO/IEC 27002 Der Abschnitt 5 hat die gleiche Gliederung wie ISO/IEC 27001 und der Abschnitt 6 die gleiche wie ISO/IEC 27002. Die Abbildung der Abschnitte aus der ISO/IEC 27701 auf die ISO/IEC 27001/2 erfolgt wie in Tabelle 7.1 gezeigt.

Zusätzlich zu diesen Änderungen und Ergänzungen aus Tabelle 7.1 verlangt die ISO/IEC 27701, dass die ISO/IEC 27001 und 27002 so gelesen werden, dass »Informationssicherheit« durch »Informationssicherheit und Datenschutz« ersetzt wird. Von den Anhängen sind Anhang A mit den »datenschutz-spezifischen Zielen der und Vorgaben zu den Standardmaßnahmen (für die verantwortliche Stelle)« sowie Anhang B mit den »datenschutzspezifischen Zielen der und Vorgaben zu den Standardmaßnahmen (für Auftragsverarbeiter)« für Sie von Interesse. ISO 27001

ISO 27701

4

Einbettung des ISMS in die Organisation des Unternehmens  5.2

ja

5

Verantwortung der Leitung des Unternehmens für die Informationssicherheit  5.3

–

6

Planung des ISMS  5.4

ja

7

Unterstützung und Ressourcen  5.5

–

8

laufender Betrieb des ISMS  5.6

–

9

Bewertung der erreichten Informationssicherheit  5.7

–

10 Verbesserung der Informationssicherheit  5.8

–

ISO 27002

ISO 27701

5

Richtlinien zur Informationssicherheit  6.2 

ja

6

Informationssicherheitsorganisation  6.3 

ja

7

Sicherheitsaspekte beim Personal  6.4 

ja

8

Management der Vermögenswerte  6.5 

ja

9

Steuerung des Zugangs  6.6 

ja

10 Kryptografie  6.7 

ja

11 Physische Sicherheit und Sicherheit der Umgebung  6.8 

ja

12 Sicherheit des Betriebs  6.9 

ja

13 Sicherheit der Kommunikation  6.10

ja

Änderungen

Ergänzungen

ISO 27001 14

Beschaffung, Entwicklung und Instandhaltung von Systemen  6.11

ISO 27701 ja

15 Beziehungen zu Lieferanten  6.12

ja

16 Umgang mit Informationssicherheitsvorfällen  6.13

ja

17

Informationssicherheit beim Business Continuity Management  6.14

18 Compliance  6.15

Änderungen

– ja

Tabelle 7.1: Änderungen und Ergänzungen der Abschnitte der ISO/IEC 27001/27002 durch die ISO/IEC 27701.

Im Anhang A (für die verantwortliche Stelle) finden Sie die folgenden Ziele der Maßnahmen: A.7.1

Vorgaben für die Erhebung und Verarbeitung personenbezogener Daten; 8  Maßnahmen

A.7.3 Pflichten gegenüber den betroffenen Personen; 10 Maßnahmen A.7.4

Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen; 9 Maßnahmen

A.7.5

Weitergabe, Übermittlung und Veröffentlichung von personenbezogenen Daten; 4 Maßnahmen

Im Anhang B (für Auftragsverarbeiter) finden Sie die folgenden: B.8.2

Vorgaben für die Erhebung und Verarbeitung personenbezogener Daten; 4  Maßnahmen

B.8.3 Pflichten gegenüber den betroffenen Personen; 1 Maßnahme B.8.4

Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen; 3 Maßnahmen

B.8.5

Weitergabe, Übermittlung und Veröffentlichung von personenbezogenen Daten; 8 Maßnahmen«

Wenn Sie geglaubt haben, die ISO/IEC 27701 beschäftige sich nur mit technisch-organisatorischen Schutzmaßnahmen, haben Sie jetzt gesehen,

dass Sie dort sehr wohl auch Maßnahmen zur Sicherstellung der rechtlichen Zulässigkeit der Verarbeitung personenbezogener Daten finden. Außerdem ist der Anhang D der Norm mit der Zuordnung der Unterabschnitte der Norm zu den einzelnen Regelungen der DS-GVO sehr hilfreich. Die Zuordnung erfolgt nicht nur grob zu den Paragraphen, sondern sehr genau bis hin zu einzelnen Buchstaben einer Aufzählung. Hier sehen Sie am Beispiel des Art. 32 Abs. 1 die Zuordnung der Maßnahmen zu den vier Buchstaben des Artikels: Lit. a

6.5.3.1 Umgang mit Wechseldatenträgern 6.5.3.3 Transport von Datenträgern 6.7.1.1 Richtlinie zum Einsatz von Kryptografie 6.11.1.2 Sicherheit von Anwendungen und Diensten in öffentlichen Netzen 6.12.1.2 Sicherheit in Verträgen mit Lieferanten 7.4.5 Anonymisieren und Löschen nicht mehr benötigter personenbezogener Daten

Lit. b

5.4.1.2 Bewertung von Risiken der Informationssicherheit 5.4.1.3 Behandlung von Risiken der Informationssicherheit 6.15.1.1 Einhaltung der Gesetze und der vertraglichen Vereinbarungen

Lit. c

6.9.3.1 Schutz von Informationen

Lit. d

6.15.2.1 Auditierung der Sicherheit der Informationstechnik 6.15.2.3 Kontrolle der Einhaltung von technischen Vorgaben

Kapitel 8

BSI und Grundschutz IN DIESEM KAPITEL lernen wir die BSI-Standards kennen beschäftigen wir uns mit dem IT-Grundschutz-Kompendium Was sind die Technische Richtlinien des BSI?

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) veröffentlichte 1994 in Kooperation mit Wirtschaftsunternehmen die erste Version des IT-Grundschutz-Handbuchs. Es umfasste die grundlegende Vorgehensweise nach IT-Grundschutz und die ersten ITGrundschutz-Bausteine und wurde der Standard für das ITSicherheitsmanagement in Deutschland. Der IT-Grundschutz wird auch heute noch kontinuierlich weiterentwickelt.

IT-Grundschutz Seit 2002 sind auch Zertifizierungen nach IT-Grundschutz möglich. Die IT-Grundschutz-Zertifizierung beinhaltet eine Zertifizierung des ISMS nach ISO/IEC 27001 Standard. 2005 erschien eine grundlegend überarbeitete Version des ITGrundschutzes, in der die Vorgehensweise nach dem IT-GrundschutzHandbuch in drei BSI-Standards überführt wurde: BSI-Standard 100-1 Managementsysteme für Informationssicherheit, BSI-Standard 100-2 IT-Grundschutz-Vorgehensweise und BSI-Standard 100-3 Risikoanalyse auf der Basis von ITGrundschutz.

Die IT-Grundschutzbausteine wurden in die IT-Grundschutz-Kataloge überführt. 2008 folgte der BSI-Standard 100-4 Notfallmanagement. 2017 wurde der IT-Grundschutz abermals überarbeitet und an die aktuelle IT-Entwicklung angepasst. Derzeit besteht der IT-Grundschutz aus vier BSI-Standards und dem Kompendium: BSI-Standard 200-1 Managementsysteme für Informationssicherheit (ISMS), BSI-Standard 200-2 IT-Grundschutz-Methodik, BSI-Standard 200-3 Risikomanagement; BSI-Standard 100-4 Notfallmanagement (im Entwurf BSI-Standard 200-4: Business Continuity Management) und IT-Grundschutz-Kompendium. Das IT-Grundschutz-Kompendium, das die Anforderungen enthält und damit der technischen IT-Entwicklung am nächsten ist, wird regelmäßig überarbeitet und ergänzt.

BSI-Standards Der BSI-Standard 200-1 Managementsysteme für Informationssicherheit (ISMS) definiert die allgemeinen Anforderungen, die ein ISMS erfüllen muss. Dabei hat ein ISMS erst einmal nichts mit einer digitalen Umsetzung des Systems zu tun, gemeint ist vielmehr die Menge aller organisatorischen Maßnahmen, die einen systematischen und dokumentierten Umgang mit der Informationssicherheit ermöglichen. Ab einem gewissen Umfang bietet sich allerdings die Umsetzung mittels eines IT-Systems an. Im Zentrum des IT-Grundschutzes steht der BSI-Standard 200-2. Er erläutert, wie sich ein ISMS solide aufbauen lässt. Je nach Sicherheitsanforderungen kann mit einer von drei unterschiedlichen Vorgehensweisen begonnen werden: Es wird je nach Sicherheitsanforderung zwischen Basis-, Kern- und StandardAbsicherung unterschieden.

Der erste Schritt im Rahmen der Einführung ist es, den Geltungsbereich des ISMS (in der Sprache des BSI den Informationsverbund) zu definieren. In aller Regel wird das ISMS im ersten Schritt nicht auf das gesamte Unternehmen angewandt. Es muss also klar definiert werden, was der räumliche und sachliche Anwendungsbereich ist. Ein Softwarehaus bekommt von einer Behörde einen Entwicklungsauftrag für eine Software zur Überwachung der Dienstgebäude der Behörde. Die genaue Leistungsfähigkeit der geplanten Software ist als vertraulich (aber nicht als Verschlusssache) eingestuft. Deshalb verpflichtet sich das Softwarehaus, die Entwicklung in einer Umgebung durchzuführen, die den Anforderungen des IT-Grundschutzes entspricht. Durch ein ISMS soll die Erfüllung der Anforderungen sichergestellt und dokumentiert werden. Da weitere Bereiche des Softwarehauses diese Anforderungen nicht erfüllen müssen, wird der Anwendungsbereich des ISMS auf das Projektteam, dessen Räume und dessen IT-Systeme inklusive Server eingeschränkt. Der BSI-Standard 200-3 beinhaltet alle Arbeitsschritte, die sich auf das Risikomanagement beziehen. Der Standard bietet sich an, wenn Unternehmen oder Behörden bereits erfolgreich mit der IT-GrundschutzMethodik arbeiten und eine Risikoanalyse durchführen möchten. Der BSI-Standard 100-4 Notfallmanagement beschreibt, wie Sie systematisch ein Notfallmanagementsystem im Unternehmen aufbauen. Der Standard 100-4 gehört noch zur vorletzten Generation der BSIStandards. Der modernisierte Nachfolgestandard 200-4 Business Continuity Management befindet sich noch in der Entwurfsphase. Grundlegende Begriffe des Notfallmanagements sind: Störung: einzelne Prozesse oder Ressourcen stehen nicht wie gewohnt zur Verfügung. Die Situation ist innerhalb der tolerierbaren Ausfallzeit im Normalbetrieb mit der normalen Organisationsstruktur beherrschbar.

Notfall: ein kritischer Geschäftsprozess steht länger als die tolerierbare Ausfallzeit nicht zur Verfügung. Die Situation ist im Normalbetrieb innerhalb der tolerierbaren Ausfallzeit mit der normalen Organisationsstruktur nicht beherrschbar. Die Notfallpläne decken den Bereich ab. Krise: Eine Situation, die sich in massiver Weise auf große Teile oder das gesamte Unternehmen auswirkt und die nicht im Normalbetrieb mit der normalen Organisationsstruktur beherrscht werden kann. Es gibt keine Notfallpläne für die Situation. Externe Hilfe kann erforderlich sein. Katastrophe: Eine Situation, die über das Unternehmen hinaus das Leben oder die Gesundheit einer Vielzahl von Menschen, ihre natürlichen Lebensgrundlagen oder bedeutende Sachwerte erheblich gefährdet. Externe Unterstützung von Behörden und Organisationen ist erforderlich (Definition in Anlehnung an das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe). Das Notfallmanagement definiert eine besondere Aufbauorganisation, die sich um die Bewältigung des Notfalls kümmert. Typisch wird dazu ein Stab auf strategischer Ebene definiert (häufig Krisenstab genannt). Dort sind alle strategisch relevanten Positionen (Rollen) vertreten. Hierzu gehört ein Vertreter der Geschäftsleitung. Ist die Geschäftsleitung nicht vertreten, muss der Stab entsprechende Kompetenzen erhalten. Auch die Unternehmenskommunikation gehört dazu. Sie werden den Vorfall irgendwann nach draußen kommunizieren müssen! Darunter ist eine taktische Ebene angesiedelt, die über Maßnahmen entscheidet, diese delegiert und die Umsetzung überwacht. Darüber hinaus muss es ein Team für die Umsetzung der Maßnahmen geben. Das fängt bei einer Werksfeuerwehr an und endet bei IT-Teams zum Wiederherstellen der Funktionalität. Neben diesen Rollen müssen aber auch Meldeprozesse (Wie wird bekannt, dass ein Notfall vorliegt?), Aktivierungsprozess (Wer ruft den Notfall aus?) und Kompetenzen (Wer darf was entscheiden?) definiert werden. Die Prozesse müssen außerdem auch eingeübt werden. Das ist

wie bei der Feuerwehr oder dem Technischen Hilfswerk: Nur wer regelmäßig übt, weiß sofort, was er zu tun hat, wenn es ernst wird. Bedenken Sie, dass in Notfallsituationen extremer Stress herrscht. Der Notfall muss dokumentiert werden, damit er im Nachhinein aufgearbeitet werden kann. Dazu gehören so banale Dinge wie die Protokollierung aller Besprechungen oder das genaue Festhalten der Uhrzeiten von Ereignissen oder Entscheidungen. Der kommende BSI-Standard 200-4 enthält Checklisten und zeigt Ihnen, woran Sie im Vorfeld denken müssen. Nicht jeder hat eine umfangreiche Notfallerfahrung, sodass er alles schon aus eigenem Erleben kennt. Wenn Sie aufgrund schlechter Strukturen einen Notfall nicht in den Griff bekommen, wird daraus schnell eine Krise. Und das wollen Sie definitiv vermeiden.

IT-Grundschutz-Kompendium In einem Unternehmen müssen im Rahmen des Risikomanagements die Gefährdungen betrachtet werden. Um den Unternehmen hier die Arbeit zu erleichtern, hat das BSI eine generische Gefährdungsanalyse erstellt und 47 elementare Gefährdungen (nummeriert als G 0.x) bestimmt und aufgelistet (siehe Tabelle 8.1). Im Rahmen der Gefährdungsanalyse werden für ein Unternehmen nicht zutreffende Gefährdungen gestrichen und zusätzliche Gefährdungen aufgenommen (nummeriert als G z.x), die für das Unternehmen relevant sind.

In einem Krankenhaus befinden sich in jedem Krankenzimmer Netzwerksteckdosen, damit gegebenenfalls medizinische Geräte, die einen Netzzugang benötigen, dort angeschlossen werden können. Diese Netzwerksteckdosen sind auch Patienten und deren Angehörigen physisch zugänglich. Daraus ergibt sich eine zusätzliche Gefährdung »G z.1 Netzzugang durch Patienten und deren Angehörige«. Diese zusätzliche Gefährdung konkretisiert die elementaren Gefährdungen »G 0.15 Abhören«, »G 0.19 Offenlegung schützenswerter Informationen«, »G 0.22 Manipulation von Hard- und Software« und »G 0.38 Missbrauch personenbezogener Daten«. Dieser zusätzlichen Gefährdung muss durch entsprechende Anforderungen begegnet werden. Auf der Hand liegt als Anforderung die Kontrolle des Netzwerkzugangs. Im Grundschutzkompendium werden die möglichen Anforderungen, die den Schutz vor den Gefährdungen sicherstellen sollen, ausführlich vorgestellt. Dabei werden die folgenden Prozess-Bausteine und SystemBausteine genutzt (in Klammern ist jeweils die Anzahl der Bausteine angegeben): Prozess-Bausteine ISMS: Sicherheitsmanagement (1) ORP: Organisation und Personal (5) CON: Konzeption und Vorgehensweise (8) OPS: Betrieb (11) DER: Detektion und Reaktion (7) G 0.1 Feuer

G 0.25 Ausfall von Geräten oder Systemen

G 0.2 Ungünstige klimatische Bedingungen

G 0.26 Fehlfunktion von Geräten oder Systemen

G 0.3 Wasser

G 0.27 Ressourcenmangel

G 0.4 Verschmutzung, Staub, Korrosion

G 0.28 Software-Schwachstellen oder -Fehler

G 0.5 Naturkatastrophen

G 0.29 Verstoß gegen Gesetze oder Regelungen

G 0.6 Katastrophen im Umfeld

G 0.30 Unberechtigte Nutzung oder Administration von Geräten und Systemen

G 0.7 Großereignisse im Umfeld

G 0.31 Fehlerhafte Nutzung oder Administration von Geräten und Systemen

G 0.8 Ausfall oder Störung der Stromversorgung

G 0.32 Missbrauch von Berechtigungen

G 0.9 Ausfall oder Störung von Kommunikationsnetzen

G 0.33 Personalausfall

G 0.10 Ausfall oder Störung von Versorgungsnetzen

G 0.34 Anschlag

G 0.11 Ausfall oder Störung von Dienstleistern

G 0.35 Nötigung, Erpressung oder Korruption

G 0.12 Elektromagnetische Störstrahlung

G 0.36 Identitätsdiebstahl

G 0.13 Abfangen kompromittierender Strahlung

G 0.37 Abstreiten von Handlungen

G 0.14 Ausspähen von Informationen G 0.38 Missbrauch personenbezogener Daten (Spionage) G 0.15 Abhören

G 0.39 Schadprogramme

G 0.16 Diebstahl von Geräten, Datenträgern oder Dokumenten

G 0.40 Verhinderung von Diensten (Denial of Service)

G 0.17 Verlust von Geräten, Datenträgern oder Dokumenten

G 0.41 Sabotage

G 0.18 Fehlplanung oder fehlende Anpassung

G 0.42 Social Engineering

G 0.19 Offenlegung schützenswerter Informationen

G 0.43 Einspielen von Nachrichten

G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle

G 0.44 Unbefugtes Eindringen in Räumlichkeiten

G 0.21 Manipulation von Hard- oder Software

G 0.45 Datenverlust

G 0.22 Manipulation von Informationen

G 0.46 Integritätsverlust schützenswerter Informationen

G 0.23 Unbefugtes Eindringen in ITSysteme

G 0.47 Schädliche Seiteneffekte IT-gestützter Angriffe

G 0.24 Zerstörung von Geräten oder Datenträgern Tabelle 8.1: Die 47 elementaren Gefährdungen der IT-Sicherheit (ITGrundschutzkompendium 2021)

System-Bausteine APP: Anwendungen (18) SYS: IT-Systeme (21) IND: Industrielle IT (6) NET: Netze und Kommunikation (10) INF: Infrastruktur (10) In Summe ergibt dies die derzeit 97 IT-Grundschutz-Bausteine des ITGrundschutz-Kompendiums. Aktuell in der Entwicklung sind vier weitere Bausteine: OPS.1.1.7 Systemmanagement APP.3.7 NTP-Zeitsynchronisation SYS.1.2.3 Windows Server 2019 SYS.1.6 Container Die Bausteine sind immer gleich aufgebaut: Die Beschreibung definiert den Baustein und grenzt ihn gegen andere Bausteine ab. Zum Beispiel werden in einem Baustein für ein Betriebssystem weder die Hardware, auf der das Betriebssystem läuft, noch die Anwendungen, die unter dem Betriebssystem laufen, betrachtet. Hier wird gegebenenfalls auf die entsprechenden Bausteine verwiesen. Danach wird auf die Gefährdungslage eingegangen und dargestellt, welche Gefährdungen eine besondere Rolle spielen. Im Anforderungsteil wird die Zuständigkeit (Geschäftsleitung, ITBetrieb, Nutzerinnen) für den Baustein angegeben. Danach werden die Anforderungen aufgelistet und beschrieben. In der Beschreibung wird

viel Wert auf eine klare Darstellung der Vorgaben gelegt (siehe Anmerkungen zur Verwendung von Modalverben in der Einleitung). Die Anforderungen sind in drei Stufen vorgegeben: Basisanforderungen stellen das Minimum dessen dar, was sinnvollerweise umgesetzt werden muss. Standardanforderungen sollten grundsätzlich erfüllt werden, um den Stand der Technik bei der IT-Sicherheit zu erreichen. Anforderungen bei erhöhtem Schutzbedarf sollten bei erhöhtem Schutzbedarf in Betracht gezogen und im Rahmen einer Risikoanalyse festgelegt werden. Für eine Zertifizierung nach ISO 27001 auf Basis des IT-Grundschutzes müssen die Basis- und Standardanforderungen erfüllt sein. Ein ISO/IEC27001-Zertifikat bescheinigt, das ein ISMS vorhanden ist. Die BSIZertifizierung bescheinigt zusätzlich, dass die Maßnahmen der Basisund Standardanforderungen erfüllt sind. Den Schluss eines Bausteins bilden die Kreuzreferenztabellen zu den elementaren Gefährdungen. Sie beschreiben, welche Anforderungen bei welchen elementaren Gefährdungen Schutz bieten. Schauen wir uns das am Beispiel des Bausteins »SYS.2.3: Clients unter Linux und Unix« an. Die Gefährdungslage sieht als Bedrohungen die Installation von »Software aus Drittquellen«, die »Ausnutzbarkeit der Skriptumgebung«, das »Dynamische Laden von gemeinsam genutzten Bibliotheken« und eine »Fehlerhafte Konfiguration«. Die Anforderungen adressieren als grundsätzlich zuständig den ITBetrieb und für einige Anforderungen zusätzlich die Nutzerin. Die Anforderungen sind im Einzelnen (die Zuständigkeit des Benutzers ist explizit angeben): für die Basisanforderungen »SYS.2.3.A1 Authentisierung von Administratoren und Benutzern [Benutzer],

SYS.2.3.A2 Auswahl einer geeigneten Distribution, SYS.2.3.A3 (entfallen), SYS.2.3.A4 Kernel-Aktualisierungen auf unixartigen Systemen, SYS.2.3.A5 Sichere Installation von Software-Paketen;« für die Standardanforderungen »SYS 2.3.A6 Kein automatisches Einbinden von Wechsellaufwerken [Benutzer], SYS.2.3.A7 Restriktive Rechtevergabe auf Dateien und Verzeichnisse, SYS.2.3.A8 Einsatz von Techniken zur Rechtebeschränkung von Anwendungen, SYS.2.3.A9 Sichere Verwendung von Passwörtern auf der Kommandozeile [Benutzer], SYS.2.3.A10 (entfallen), SYS.2.3.A11 Verhinderung der Überlastung der lokalen Festplatte, SYS.2.3.A12 Sicherer Einsatz von Appliances;« für die Anforderungen bei erhöhtem Schutzbedarf »SYS.2.3.A13 (entfallen), SYS.2.3.A14 Absicherung gegen Nutzung unbefugter Peripheriegeräte, SYS.2.3.A15 Zusätzlicher Schutz vor der Ausführung unerwünschter Dateien, SYS.2.3.A16 (entfallen), SYS.2.3.A17 Zusätzliche Verhinderung der Ausbreitung bei der Ausnutzung von Schwachstellen, SYS.2.3.A18 Zusätzlicher Schutz des Kernels, SYS.2.3.A19 Festplatten- oder Dateiverschlüsselung,

SYS.2.3.A20 Abschaltung kritischer SysRq-Funktionen.« Die elementaren Gefährdungen für diesen Systembaustein »Klient unter Linux oder Unix« sind: »G 0.19 Offenlegung schützenswerter Informationen, G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle, G 0.21 Manipulation von Hard- oder Software, G 0.22 Manipulation von Informationen, G 0.23 Unbefugtes Eindringen in IT-Systeme, G 0.25 Ausfall von Geräten oder Systemen, G 0.28 Software-Schwachstellen oder -Fehler, G 0.30 Unberechtigte Nutzung oder Administration von Geräten und Systemen, G 0.31 Fehlerhafte Nutzung oder Administration von Geräten und Systemen, G 0.32 Missbrauch von Berechtigungen, G 0.39 Schadprogramme, G 0.45 Datenverlust, G 0.46 Integritätsverlust schützenswerter Informationen.« Zusammen mit den Grundwerten Vertraulichkeit (C), Integrität (I) und Verfügbarkeit (A) führt das zu der Kreuztabelle in Tabelle 8.2. Die Maßnahmen zur Umsetzung des Grundschutzes sind häufig in ein zusätzliches Dokument »Umsetzungshinweise« ausgelagert. Diese gibt es für viele Bausteine des IT-Grundschutz-Kompendiums. Die Umsetzungshinweise können Sie im PDF und im MS-Word-Format herunterladen. Anf.\ Gef. SYS.2.3.A1

CIA × × ×

Anf.\ Gef.

CIA

SYS.2.3.A2

× ×

×

SYS.2.3.A4

× ×

× ×

×

SYS.2.3.A5

× ×

×

×

SYS.2.3.A6

× × × ×

×

SYS.2.3.A7

×

× ×

× × ×

SYS.2.3.A8

×

× ×

× × ×

× × ×

× × ×

SYS.2.3.A9 SYS.2.3.A11 SYS.2.3.A12

×

× × × ×

× × × × × × × × × × × × ×

SYS.2.3.A14 CIA

× ×

SYS.2.3.A15 CI

× × ×

SYS.2.3.A17 CI

×

× × ×

SYS.2.3.A18 CI

× × ×

× × × × × ×

× ×

×

SYS.2.3.A19 CI SYS.2.3.A10 CIA

×

×

×

×

× ×

Tabelle 8.2: Kreuztabelle für den Baustein »SYS.2.3: Clients unter Linux und Unix« (ITGrundschutzkompendium 2021).

Standard-Datenschutzmodell und IT-Grundschutz Das Modul CON.2 Datenschutz verbindet den IT-Grundschutz mit Datenschutzvorgaben des Standard-Datenschutzmodells (SDM). Die Gefährdungslage besteht nur aus zwei Punkten: »Missachtung von Datenschutzgesetzen oder Nutzung eines unvollständigen Risikomodells«, da die zusätzlichen Risiken, die sich aus der Verarbeitung der personenbezogenen Daten ergeben, nicht berücksichtigt werden.

»Festlegung eines zu niedrigen Schutzbedarfs«, da der Schutzbedarf der personenbezogenen Daten nicht betrachtet wurde. Es gibt genau eine (Basis-)Anforderung: »CON.2.A1 Umsetzung Standard-Datenschutzmodell«. Berücksichtigt man das SDM nicht, muss dies begründet werden. Auch die Kreuztabelle ist hier sehr kompakt. Das Konzept des SDM wiederum ist recht gradlinig. Aus den Artikeln der DS-GVO werden 23 plus 2 (diese zwei sind Einwilligungsmanagement und Umsetzung aufsichtsbehördlicher Anordnungen) Anforderungen kondensiert. Diese Anforderungen werden dann auf sieben Gewährleistungsziele abgebildet: 1. Verfügbarkeit (IT-Sicherheit), 2. Integrität (IT-Sicherheit), 3. Vertraulichkeit (IT-Sicherheit), 4. Nichtverkettung (Datenschutz), 5. Transparenz (Datenschutz), 6. Intervenierbarkeit (Datenschutz), 7. Datenminimierung (Datenschutz). Die Reihenfolge der Gewährleistungsziele variiert im SDM. An dieser Stelle haben wir die Reihenfolge aus dem Kapitel »Praktische Umsetzung« gewählt. Dabei sind einige dieser Abbildungen nicht offensichtlich. So wird zum Beispiel die »Fehler- und Diskriminierungsfreiheit beim Profiling« (Art. 22 Abs. 3 f.) auf das Gewährleistungsziel »Integrität« abgebildet. In Kapitel D werden dann die Gewährleistungsziele mit generischen Maßnahmen hinterlegt. Auch da finden wir einige Ungereimtheiten. Unter Integrität gibt es die generische Maßnahmen »dokumentierte Zuweisung von Berechtigungen und Rollen« und unter Vertraulichkeit gibt es »Festlegung eines Berechtigungs- und Rollenkonzeptes nach dem Erforderlichkeitsprinzip auf der Basis eines Identitätsmanagements durch die verantwortliche Stelle«. Unter Nichtverkettung gibt es dann

noch eine dritte Formulierung. In allen Fällen ist aber immer dasselbe gemeint: ein Berechtigungs- und Rollenkonzept, das den Schutzzielen und dem Schutzbedarf gerecht wird. Für konkrete Maßnahmen wird im SDM auf einen Referenzmaßnahmenkatalog im Anhang verwiesen, den es im Dokument nicht gibt. Es gibt allerdings bisher nur acht Bausteine eines bisher unvollständigen Maßnahmenkatalogs (Nummerierung der Bausteine wie im Original): 11 Aufbewahren, 41 Planen und Spezifizieren, 42 Dokumentieren, 43 Protokollieren, 50 Trennen, 60 Löschen und Vernichten, 61 Berichtigen, 62 Einschränken der Verarbeitung. Die beschriebenen Maßnahmen nehmen keinen Bezug zum BSIGrundschutz, auch wenn das SDM betont, eng mit dem IT-Grundschutz verzahnt zu sein. So finden Sie bei hohem Schutzbedarf im Baustein 11 Aufbewahren die Maßnahme »M11.S18 Zwei-Faktor-Authentisierung« und in den Grundschutz-Umsetzungshinweisen zum Baustein: ORP.4. Identitäts- und Berechtigungsmanagement die Maßnahme »ORP.4.M21 Mehr-Faktor-Authentisierung«. Ein Verweis wäre hier sicher besser gewesen. Das Konzept der ISO-Normen, wo die ISO/IEC 27701 die ISO/IEC 27001/27002 modifiziert und ergänzt, ist in diesem Punkt besser. Für eine wirklich sinnvolle Verzahnung des SDM mit dem IT-Grundschutz fehlen im SDM noch bessere Konzepte für die Verzahnung.

Technische Richtlinien des BSI

Das BSI stellt zahlreiche technische Richtlinien zur Verfügung. Diese haben Empfehlungscharakter und müssen im Unternehmen durch eine interne Richtlinie verbindlich gemacht werden. Grundsätzlich bieten Ihnen die technischen Richtlinien aber eine gute Orientierung und die Möglichkeit, den »Stand der Technik« abzuschätzen. Sie finden eine aktuelle Liste der Technischen Richtlinien des BSI an dieser Stelle: https://www.bsi.bund.de/DE/Themen/Unternehmen-undOrganisationen/Standards-und-Zertifizierung/TechnischeRichtlinien/technische-richtlinien_node.html.

Für Sie sind im täglichen Umgang vermutlich die folgenden Richtlinien besonders interessant: BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen, BSI TR-03108 Sicherer E-Mail-Transport, BSI TR-03111 Elliptische-Kurven-Kryptographie (ECC), BSI TR-03138 Ersetzendes Scannen (RESISCAN), BSI TR-03148 Sichere Breitband-Router. Die TR-02102 besteht aus vier Dokumenten. Im ersten Dokument (TR02102-1) lernen Sie die grundlegenden Empfehlungen zu Algorithmen und Schlüssellängen kennen. Die Empfehlungen lassen sich wie in Tabelle 8.3 zusammenfassen. Darüber hinaus gibt Ihnen die Richtlinie umfangreiche Hintergrundinformationen und Erläuterungen der Empfehlungen. Die technische Richtlinie TR-02102-2 gibt Empfehlungen zum Einsatz von Transport Layer Security (TLS). Nach dieser Empfehlung sollten Sie nur TLS 1.2 und TLS 1.3 einsetzen. Die älteren Verfahren (SSL 2 bis TLS 1.1) werden ausdrücklich nicht mehr empfohlen. Algorithmus

Schlüssellänge oder Verfahren

AES

128, 192 oder 256 Bit

RSA

2000 (bis Ende 2022), 3000 Bit

Algorithmus

Schlüssellänge oder Verfahren

Eliptic Curve (EC) 250 Bit Betriebsart

CCM, GCM, CBC oder CTR

Padding

ISO/IEC 9797-1 M 2, RFC 5652 A 6.3, RFC 4303 A 2.4

Eliptic Curve (EC) Brainpool-Kurven mit 256, 320, 384 und 512 Bit Hashing

SHA-256, SHA-512/256, SHA-384 oder SHA-512 SHA3-256, SHA3-384 oder SHA3-512

Signaturen

RSA, DSA, ECDSA

Tabelle 8.3: Zusammenfassung der wesentlichen empfohlenen Verfahren und Mindestschlüssellängen der Richtlinie TR-02102-1 (siehe auch Kapitel 17).

Wenn Sie die Empfehlungen der TR-02102-2 zu TLS folgen, sperren Sie Anwender alter Software aus. Dies sind insbesondere ältere Android- (vor Version 4.4.2) oder iOS-Versionen (vor Version 6.01) und ältere Browser (zum Beispiel Firefox vor 27, Chrome vor 31). Das ist in Ihrem Unternehmen wahrscheinlich irrelevant, aber Sie sollten es trotzdem mit Unternehmenskommunikation und IT-Abteilung abklären, welche Auswirkungen der Ausschluss dieser alten Softwareversion hat. Falls es sehr wichtige Argumente für die weitere Nutzung von TLS 1.0 und TLS 1.1 gibt, muss die Weiternutzung im Rahmen einer detaillierten Risikobetrachtung entschieden werden. Außerdem gibt es in der Richtlinie ausführliche Empfehlungen für sogenannten Kryptosuites, dass heißt, für eine detaillierte Konfiguration der Krypoeinstellungen auf Webservern und anderen Servern, die TLS nutzen (zum Beispiel Mail-Server oder Videokonferenzserver). Diese Detailempfehlungen sollten Sie an die zuständigen Administratoren geben, welche dann die korrekte Konfiguration vornehmen. Die beiden letzten Dokumente geben Empfehlungen zum Einsatz von VPN, genauer IPsec (TR-02102-3), und zur Verwendung von Secure Shell (SSH) (TR-02102-4). VPN nutzen Sie, wenn sie sich remote, also

aus dem Homeoffice oder während einer Dienstreise, ins Unternehmen einwählen. SSH nutzen primär Administratoren, um aus der Ferne Server zu konfigurieren. Darüber hinaus ist es in der Wissenschaft und bei Entwicklern sehr verbreitet. Die TR-03108 adressiert die Verschlüsselung des Transports von EMails zwischen zwei Mail-Servern und richtet sich primär an Betreiber von E-Mail-Diensten (zum Beispiel GMX, Web.de oder die Telekom). Das von manchen völlig zu Unrecht oft belächelte »E-Mail made in Germany« garantiert genau diese Transportverschlüsselung zwischen den teilnehmenden Dienstleistern. Wenn Ihr Unternehmen einen eigenen Mail-Server betreibt, sollten Sie diese Richtlinie umsetzen, um den verschlüsselten Transport Ihrer E-Mails so weit es geht zu gewährleisten. Die Datenschutzaufsichtsbehörden fordern von den Unternehmen den Einsatz dieser Transportverschlüsselung. Diese Forderung ist gerechtfertigt, da es sich um eine Maßnahme nach dem Stand der Technik handelt. Im Sommer 2021 haben Wissenschaftler der TH Nürnberg untersucht, ob sich die Aufsichtsbehörden an ihre eigenen Empfehlungen halten. Das Ergebnis war nicht überzeugend. Nur drei der 18 Aufsichtsbehörden akzeptierten ausschließlich Verbindungen mit mindestens TLS 1.2. Drei Aufsichtsbehörden akzeptieren auch noch SSL 3. [PD21] Die TR-03111 gibt eine ausführliche englischsprachige Einführung in die mathematischen Grundlagen der Elliptische-Kurven-Kryptografie (ECC). Wenn Sie über die mathematischen Grundkenntnisse verfügen, ist das ein sehr empfehlenswertes Dokument. Die ECC wird immer wichtiger, da sie ein effizientes Verfahren zur asymmetrischen Verschlüsselung ist. Eine kurze, weniger mathematische Einführung in ECC und asymmetrische Verschlüsselung finden Sie in Kapitel 17. Das ersetzende Scannen ist interessant, um den Papierberg im Unternehmen zu reduzieren und trotzdem die rechtlichen Vorgaben zur rechtssicheren Aufbewahrung von Dokumenten zu gewährleisten. Die TR-03138 hilft Ihnen, die Prozesse und Systeme im Unternehmen so zu

gestalten, dass Sie die technischen und organisatorischen Anforderungen erfüllen. Neben der Richtlinie werden auch Anwendungshinweise und Praxisbeispiele zur Verfügung gestellt. Die Richtlinie TR-03418 definiert die Anforderungen an marktübliche Breitband-Router im Consumerbereich. Es geht also um die FritzBox oder den Speedport bei Ihnen zuhause und nicht um hochperformante Businessgeräte in Unternehmen. Mit dem freiwilligen Sicherheitskennzeichen (siehe Rechtsakt zur Cybersicherheit und BSIGesetz in Kapitel 6) werden als erstes wohl Breitband-Router versehen. Die Grundlage für deren »technische Prüfung« bietet genau diese technische Richtlinie.

Kapitel 9

Weitere Standards IN DIESEM KAPITEL Alternativen zu ISO und Grundschutz Technische Standards

Es gibt noch weitere Standards, die entweder als prozessorientierte Standards eher auf kleine oder mittlere Unternehmen (KMU) zielen, wie zum Beispiel VDS 10000 oder CISIS12, oder aber branchenspezifisch ausgerichtet sind, wie zum Beispiel TISAX. Auch die öffentliche Verwaltung hat eigene Vorgaben zur Umsetzung der Informationssicherheit. Darüber hinaus gibt es technische Standards, die eine Produktzertifizierung ermöglichen, wie die Common Criteria oder Federal Information Processing Standards (FIPS). Wir wollen uns in diesem Kapitel mit diesen Standards beschäftigen, um für Sie den Überblick über die Sicherheitsstandards abzurunden.

Prozessorientierte Standards Neben den »großen« Standards ISO 27000 und dem IT-Grundschutz des BSI gibt es auch noch »kleinere« Standards, die mehr auf kleine und mittlere Unternehmen zielen. Die weiteren hier vorgestellten Standards orientieren sich an der ISO beziehungsweise dem Grundschutz, um als Einstieg dienen zu können. Wollen Sie zum Beispiel von der VdS 10000 auf ISO 27000 wechseln, müssen Sie nicht bei null neu anfangen. Sie können Ihre Vorarbeiten weiter nutzen und darauf aufbauend Ihre Maßnahmen erweitern.

Abbildung 9.1 zeigt eine grobe qualitative Darstellung des Aufwands in Abhängigkeit vom typisch zu erreichenden Sicherheitsniveau. Diese Abschätzung kann sicher diskutiert werden. Sie beruht auf dem Umfang der zu erfüllenden Maßnahmen. Es ist für Sie wichtig zu wissen, dass CISIS12, VdS 10000 und TISAX kompatibel zur Standard-Familie ISO/IEC 27000 sind.

Abbildung 9.1: Grobe qualitative Darstellung des Aufwands und des typisch zu erreichenden Sicherheitsniveaus bei den verschiedenen Informationssicherheitsstandards.

VdS 10000: ISMS für KMU Die VdS Schadenverhütung GmbH ist eine Tochter des Gesamtverbands der Deutschen Versicherungswirtschaft und bietet Dienstleistungen im Bereich Brandschutz, Einbruchschutz (Security) und auch Informationssicherheit an. Das Institut hat Richtlinien zur Informationssicherheit für kleinere und mittlere Unternehmen (KMU) entwickelt. Dies sind im Einzelnen: VdS 10000:2018-12 – Informationssicherheits-Managementsystem (ISMS) für kleine und mittlere Unternehmen (KMU),

VdS 10001:2019-11 – VdS Quick-Audit, VdS 10002:2019-11 – Zertifizierung von Managementsystemen für KMU (Informationssicherheit und Datenschutz), VdS 10005:2021-07 – Mindestanforderungen an die Informationssicherheit von Klein- und Kleinstunternehmen, VdS 10006:2021-07 – Testierung der IT-Sicherheit von Klein- und Kleinstunternehmen, VdS 10010:217-12 – VdS-Richtlinien zur Umsetzung der DS-GVO, Anforderungen, VdS 10020:2020-04 – Cyber Security für kleine und mittlere Unternehmen (KMU), Leitfaden zur Interpretation und Umsetzung der VdS 10000 für Industrielle Automatisierungssysteme. Die Zielsetzung dieser Richtlinien ist es, KMUs zu helfen, da diese häufig kein dediziertes Personal haben, das sich um ihre Informationssicherheit kümmern kann. Die Richtlinien orientieren sich sprachlich und inhaltlich an der ISO-27000-Reihe und am ITGrundschutz des BSI. Das Ziel ist es, ein KMU mit weniger Aufwand als bei der Einhaltung der kompletten ISO-Normen zu einem ISMS zu verhelfen. Gleichzeitig ist gewährleistet, dass bei wachsenden Anforderungen an die IT-Sicherheit ein »Upgrade« auf die ISO/IEC 27000 oder den IT-Grundschutz möglich ist, ohne wieder bei null anfangen zu müssen. Eine Zertifizierung nach VDS 10000 ist möglich und bietet einen einfacheren Einstieg, als sofort mit einer ISO/IEC 27001-Zertifizierung zu beginnen. Nach eigenen Angaben der VdS erfordert eine VDS10000-Zertifizierung etwa 20 % des Aufwands einer ISO-27001Zertifizierung. Da die VdS ihre Wurzeln in der Versicherungswirtschaft hat, sind die Zertifizierungen bei den Versicherungen »etwas wert«. Der einfache Einstieg beginnt mit einer Selbsteinschätzung in einem Quick-Check (https://www.vds-quick-check.de). Im Quick-Check werden Sie in den drei Bereichen Informationssicherheit, Datenschutz

und Sicherheit von Produktionsanlagen durch einen Fragebogen geführt, der zu einer qualitativen Selbsteinschätzung führt (siehe Abbildung 9.2).

Abbildung 9.2: Tabellarische Übersicht über das Ergebnis einer Selbsteinschätzung der Informationssicherheit im VdS-Quick-Check. (Quelle: Screenshot VdS-Quick-Check)

Im Fragebogen werden für alle Fragen die Antwortmöglichkeiten »Ja«, »Nein«, »Trifft nicht zu« und »Keine Angabe« angeboten. Grundsätzlich zeigt das Vorgehen, dass mit einfachen Fragen und einfachen Antworten schon eine sinnvolle Aussage möglich ist. Auch die Unterscheidung zwischen »Trifft nicht zu« und »Keine Angabe« ist wichtig. So besteht für kleinste Unternehmen keine Pflicht, einen Datenschutzbeauftragten zu bestellen, und die korrekte Antwort auf die Farge »Ist ein Datenschutzbeauftragter bestellt?« wäre in dem Fall »Trifft nicht zu«. Ist bei einer Frage dagegen die Antwort nicht bekannt, muss die Antwort »Keine Angabe« lauten. Auf europäischer Ebene gibt es von der Confederation of Fire Protection Association Europe die CFP A-E Guideline No 11:2018 S »Guideline on Cyber Security for Small and Medium-sized Enterprises«, die ähnlich zur VDS 10000 aufgebaut ist. Die Dokumente zur VDS 10000 sind kostenpflichtig und auch der Quick-Check kostet einem minimalen Betrag.

ISIS12 wird CISIS12

Das Informations-Sicherheitsmanagement-System in 12 Schritten, kurz ISIS12, ist vom Bayerischen IT-Sicherheitscluster e.V. speziell für kleine und mittlere Organisationen entwickelt worden, um einfach und schnell Ergebnisse zu erzielen. ISIS12 in den Versionen 1.x und 2.x ist in einer Übergangsfrist und läuft aus. Es wird durch ISIS12 in der Version 3 ersetzt, das in CISIS12 (Compliance-Informations-Sicherheitsmanagement-System in 12 Schritten) umbenannt wurde. Die 12 Schritte sind im Einzelnen: 1. Informationssicherheits-Leitlinie erstellen 2. Beschäftigte für das Thema sensibilisieren 3. Informationssicherheitsteam aufbauen 4. Struktur der IT-Dokumentation festlegen 5. IT-Servicemanagement-Prozesse einführen 6. kritische Applikationen und Prozesse identifizieren 7. IT-Struktur analysieren 8. Risikomanagement 9. Soll-Ist-Vergleich 10. Umsetzung planen und Umsetzung 11. internes Audit durchführen 12. Revision Ein Unternehmen wird bei der Umsetzung von einem geschulten Berater begleitet. Es gibt knapp 100 Berater für ISIS12 beziehungsweise CISIS12. Auch wenn der Standard nicht auf Bayern beschränkt ist, liegt der Schwerpunkt der Anwendung im blau-weißen Freistaat. Die CISIS12 Dokumente sind für Kommunen kostenlos und für Unternehmen kostenpflichtig verfügbar.

TISAX

Trusted Information Security Assessment Exchange (TISAX; https://portal.enx.com/de-DE/TISAX/) ist ein von der deutschen Automobilindustrie im Jahr 2017 ins Leben gerufener Standard für die Informationssicherheit. Der Standard ist heute unter dem Dach der im Jahr 2000 gegründeten ENX Association angesiedelt. Die ENX Association ist wiederum ein Zusammenschluss von Automobilherstellern, Zulieferern und vier nationalen Automobilverbänden. Die TISAX-Prüfung basiert auf dem Anforderungskatalog »VDA Information Security Assessment« (VDA ISA). VDA ISA basiert auf der ISO 27001, wurde aber um branchenspezifische Aspekte (zum Beispiel Schutz von Prototypen) ergänzt. Der TISAX-Standard entspricht vom Umfang etwa der Hälfte der ISO 27001. Der Auditor lädt die Prüfergebnisse auf die TISAX-Plattform. Dort sind sie zuerst nur dem geprüften Unternehmen zugänglich. Das Unternehmen kann nun seinerseits die Prüfergebnisse komplett veröffentlichen und sie damit allen TISAX-Teilnehmern zugänglich machen. Alternativ können die Prüfergebnisse auch nur bestimmten Teilnehmern bekanntgegeben werden. Dieser eingebaute Austausch unterscheidet TISAX von der ISO. Im Kontext der Automobilindustrie macht er Sinn, da so ein Zulieferer seinen Kunden direkt die Prüfergebnisse zugänglich machen kann, um nachzuweisen, dass er die Vorgaben des Kunden einhält. Nach Angaben der ENX Association wird TISAX von mehr als 2500 Unternehmen in über 40 Ländern genutzt. Wenn Sie branchenspezifische Informationssicherheitsstandards einsetzen, sollten Sie in jedem Fall auch prüfen, wie diese sich zur ISO/IEC 27000er Familie verhalten: bauen sie darauf auf, ergänzen sie diese oder sind sie unabhängig davon? Gegebenenfalls müssen Sie zusätzlich zum Branchenstandard noch eine ISO-Zertifizierung anstreben.

Finanzstandards

Wirtschaftsprüfer auditieren und bestätigen (testieren) Statements zur Finanzlage eines Unternehmens: Bilanzen, Kreditwürdigkeit oder Jahresberichte. Alle Wirtschaftszahlen eines Unternehmens werden heute aus Computern abgerufen. Damit ist die Integrität der IT von besonderer Bedeutung. Deswegen beschäftigen sich Wirtschaftsprüfer auch mit der IT und der Informationssicherheit. Die sogenannten Basel-Vorschriften (Basel I bis Basel III) sind Eigenkapitalvorschriften für Geldinstitute, die vom Baseler Ausschuss für Bankenaufsicht veröffentlicht wurden. Es handelt sich um Empfehlungen, die noch in nationales Recht umgesetzt werden müssen. Basel III wurde durch die Eigenkapitalrichtlinie der EU umgesetzt. Diese Vorgaben haben nur indirekt mit Informationssicherheit zu tun. Im Rahmen einer Risikobetrachtung bei der Kreditvergabe an Unternehmen spielt die Verlässlichkeit des Berichtswesens auch eine wichtige Rolle. Die Insolvenz des US-amerikanischen Enron-Konzerns im Jahr 2001 erschütterte die Finanzwelt erheblich und vernichtete viele Anlagen auch von Privatanlegern. Vorausgegangen waren erhebliche Bilanzfälschungen. Der Enron-Skandal führte zu geänderter Gesetzgebung zur Verlässlichkeit der Finanzberichterstattung von börsennotierten Unternehmen (Sarbanes-Oxley Act, SOX oder Abschlussprüfungsrichtlinie der EU, EuroSOX). Auch der Insolvenz der deutschen Wirecard AG im Jahr 2020 gingen Ungereimtheiten bei der Bilanz voraus. Treuhandkonten mit Guthaben im Wert von einem Viertel der Bilanzsumme waren nach Presseberichten nicht auffindbar. International Standard on Assurance Engagements (ISAE) 3000 und 3402 sind Standards der International Federation of Accountants (IFAC) und beschäftigen sich mit der Wirtschaftsprüfung von Unternehmen außerhalb der normalen Abschlussprüfungen (3000) oder von Dienstleistungsunternehmen (3420) bezüglich des internen Kontrollsystems durch Wirtschaftsprüfer. In Deutschland sind sie in die

Prüfungsstandards PS 860 und PS 951 des Instituts der Wirtschaftsprüfer in Deutschland e. V. übernommen. Die beiden ISAE definieren zwei Reports, den SOC 1 (Finanzberichterstattung, 3402) und den SOC 2 (IT-SicherheitsRisikomanagement, 3000). Bei beiden gibt es einen sogenannten TYP-IReport, in dem das Konzept und das Vorhandensein des internen Kontrollsystems geprüft wird. Zusätzlich hat man auch noch einen TypII-Report, bei dem Funktion und Einhaltung des internen Kontrollsystems überprüft werden. Auch wenn Sie durch ein gute Informationssicherheit Bilanzfälschungen nicht verhindern können, so können Sie damit Manipulationen in den Systemen zumindest erschweren. Ein an US-amerikanischen Börsen gelistetes Unternehmen ist durch die Sarbanes-Oxley Gesetzgebung verpflichtet, von seinen Dienstleistern einen SOC-1-Report anzufordern. Deutsche Unternehmen, die Dienstleister für entsprechende US-Unternehmen sind, müssen diese Reports auch liefern. SOC-2-Reports sind heute besonders für CloudDienstleister relevant. Sie werden von Kunden im Rahmen von deren eigenem Risikomanagement eingefordert.

Vorgaben für die öffentliche Verwaltung Im IT-Planungsrat arbeiten die Verwaltungen von Bund und Länder in IT-Fragen zusammen. Die rechtliche Grundlage bildet der »ITStaatsvertrag über die Errichtung des IT-Planungsrats und über die Grundlagen der Zusammenarbeit beim Einsatz der Informationstechnologie in den Verwaltungen von Bund und Ländern«. Die rechtliche Grundlage für diese Zusammenarbeit ergibt sich aus Art. 91c Grundgesetz. Zur Zusammenarbeit gehören auch einheitliche Vorgaben zur Informationssicherheit für Bund und Länder. Auf Bundesebene sind die Vorgaben der »Leitlinie für die Informationssicherheit in der öffentlichen Verwaltung« im

»Umsetzungsplan Bund 2017 – Leitlinie für Informationssicherheit in der Bundesverwaltung« umgesetzt. Die sechzehn Bundesländer müssen eigene Umsetzungen schaffen. Um den Erfolg zu messen, sind im Umsetzungsplan der Leitlinie für die Jahre 2020–2025 Metriken zur Erfassung des Standes der Umsetzung der Maßnahmen definiert. Die erreichte Umsetzungsgrad der Maßnahmen im Zeitraum 2013–2018 war 67 %. Die Rechnungshöfe des Bundes und der Länder prüfen nicht nur den wirtschaftlichen Umgang der öffentlichen Verwaltung mit den Steuergeldern, sondern in diesem Zusammenhang auch die Informationssicherheit in den Behörden. Ein Grundsatzpapier der Rechnungshöfe des Bundes und der Länder zum Informationssicherheitsmanagement enthält einen umfangreichen Fragenkatalog zum Status des Informationssicherheitsmanagements in der geprüften Behörde. Ohne ein Informationssicherheitsmanagement können die Verwaltungen mit den aktuellen Bedrohungen der Informationssicherheit nicht angemessen umgehen. »Der digitale Verwaltungsvollzug und die damit verbundenen erheblichen Investitionen der öffentlichen Verwaltungen in ihre IT-Ausstattungen sind ohne ausreichende Informationssicherheit gefährdet. Angemessene Informationssicherheit ist daher auch ein Gebot der Wirtschaftlichkeit.« heißt es in der Präambel. Diese Aussage gilt uneingeschränkt auch für nicht-staatliche Organisationen. Das Grundsatzpapier enthält einen umfangreichen Fragenkatalog zum Informationssicherheitsmanagement. Die Fragen gliedern sich in die fünf Kategorien Informationssicherheitsmanagement (78 Fragen), Absicherung der Netzinfrastruktur (51 Fragen), Sicherheitsstandards für Ebenen-übergreifende IT-Verfahren (16 Fragen), gemeinsame Abwehr von IT-Angriffen (26 Fragen) und IT-Notfallmanagement (32 Fragen).

Die meisten Fragen können recht einfach mit »Ja« oder »Nein« beantwortet werden. Obwohl dieser Fragenkatalog für die öffentliche Verwaltung erstellt wurde, liefert er auch gute Ansätze für die Anpassung an andere Organisationen.

Technikorientierte Standards Sie haben bisher nur Standards wie die ISO/IEC 27000 und den ITGrundschutz des BSI kennengelernt, die sich mit der Ausgestaltung eines ISMS beschäftigen, dass heißt mit der Gestaltung der Prozesse zur Steuerung der Informationssicherheit. Parallel dazu müssen wir uns aber auch mit der konkreten Technik befassen. Wann ist eine Chipkarte sicher? Welcher Verschlüsselungsalgorithmus ist sicher genug? Ist in einer Software der Verschlüsselungsalgorithmus korrekt implementiert? Auch bei der Beantwortung dieser Fragen helfen uns Standards.

Common Criteria Die »Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik« (Common Criteria for Information Technology Security Evaluation, CC) sind ein wichtiger, weltweit angewandter Standard zur Bewertung der Sicherheit von IT-Technik. Sie sind im Bundesanzeiger offiziell veröffentlicht und auch in Form einer ISONorm als ISO/IEC 15408 etabliert. Die Prüftiefe einer CC-Prüfung wird als Evaluation Assurance Level (EAL) bezeichnet. Die Stufen gehen von EAL 1 bis EAL 7. EAL 4 setzt zwingend die Untersuchung des Quellcodes voraus und ab EAL 5 muss die Sicherheit durch formale Spezifikations- und Verifikationsmethoden nachgewiesen werden. Das ist deutlich mehr als normale Softwareentwicklung. Die sieben Level sind: EAL 1 funktionell getestet (functionally tested) EAL 2 strukturell getestet (structurally tested) EAL 3 methodisch getestet und geprüft (methodically tested and checked)

EAL methodisch entwickelt, getestet und nachgeprüft (methodically designed, tested,

4

and reviewed)

EAL semiformal entworfen und getestet (semiformally designed and tested) 5 EAL semiformal verifizierter Entwurf und getestet (semiformally verified design and 6 tested) EAL formal verifizierter Entwurf und getestet (formally verified design and tested) 7

Der Hersteller eines Produkts beschreibt die funktionalen Sicherheitsanforderungen (Security Functional Requirements, SFR) für sein zu prüfendes Produkt (Target of Evaluation, TOE). Dabei legt er die Version und die genaue Konfiguration fest. Und nur diese Kombination wird geprüft, sie ist in den Sicherheitszielen (Security Target, ST) im Zertifikat dokumentiert. Für die Prüfung ist damit genau vorgegeben, welche Funktionalitäten geprüft werden müssen. Die funktionalen Sicherheitsanforderungen sind in elf Klassen (zum Beispiel FCS: Kryptografie) eingeteilt, die wieder aus funktionalen Familien (hier zwei: FCS_CKM Schlüsselmanagement und FCS_COP Betrieb) bestehen. Die funktionalen Familien bestehen dann aus Komponenten. Das Schlüsselmanagement etwa gliedert sich in die vier Komponenten FCS_CKM.1 Schlüsselerzeugung, FCS_CKM.2 Schlüsselverteilung, FCS_CKM.3 Schlüsselzugriff und FCS_CKM.4 Schlüsselvernichtung. Der Betrieb besteht nur aus einer Komponente FCS_COP.1 Betrieb. Zu jeder Komponente ist dann festgelegt, wie eine Prüfung durchzuführen ist.

Gegenseitiges Vertrauen

International gibt es Abkommen, welche EAL-Stufen gegenseitig anerkannt werden. Es gibt ein europäisches Abkommen, dass EAL1 bis EAL4 (SOGIS-MRA v3) von den Unterzeichnern des Abkommens (Deutschland, Frankreich, Großbritannien, Italien und 13 weitere Länder) gegenseitig anerkannt werden. Ein entsprechendes internationales – über Europa hinausgehendes – Abkommen zur gegenseitigen Anerkennung durch die Unterzeichner (Australien, Deutschland, Indien, Kanada, USA und weitere 26 Länder) gilt nur für EAL1 und EAL2 (CCRA-2014). Die entsprechende Gültigkeit eines Zertifikats unter diesen Abkommen ist in dem Zertifikat angegeben. Wenn das überwiegende öffentliche Interesse (dies betrifft insbesondere nationale sicherheitspolitische Aspekte) es verlangt, kann das Bundesministerium des Innern, für Bau und Heimat die Ausstellung von Zertifikaten untersagen (§ 9 Abs. 4 Nr. 2 BSIG). Dies ist derzeit in Deutschland der Fall bei der Beurteilung der Stärke und Implementierung kryptografischer Verfahren.

In einem Protection Profile (Schutzprofil) werden die funktionalen Anforderungen für ein Objekt definiert. Im Prinzip kann jeder ein Schutzprofil schreiben. Damit es in Prüfungen genutzt werden kann, muss es jedoch in Deutschland vom BSI zugelassen sein. In dem Schutzprofil können Sie neue funktionale Familien und Komponenten definieren oder bestehende erweitern und konkretisieren. Ein Common-Criteria-Zertifikat bezieht sich auf ein Protection Profile und gibt eine Vertrauenswürdigkeitsstufe an. So wurde Windows 2000 Professional Server gegen das Protection Profile »Controlled Access Protection Profile Version 1.d« der NSA geprüft und mit »EAL4 erweitert« in der Vertrauenswürdigkeit bestätigt. Auf der Webseite des BSI finden Sie im Herbst 2021 knapp 70 vom BSI zugelassene Schutzprofile. Das Spektrum reicht von Chipkartenbetriebssystemen über verschlüsselte USB-Sticks und die Gesundheitskarte bis hin zu smarten Energiezählern. Sie finden durchaus auch Kritik an den CC (zum Beispiel bei Ross Anderson [And20]). Eine Zertifizierung dauert sehr lange (bis zu zwei Jahre) und ist sehr kostenaufwendig (durchaus deutlich mehr als 100.000 €). Außerdem spielen Aspekte wie die Bedienbarkeit keine Rolle (»Das System ist so sicher, das es nicht mehr bedienbar ist.«). Bei EAL6 und EAL7 dürfte dies ein relevanter Aspekt sein. Gängige Produkte sind häufig bis maximal EAL4 zertifiziert. Außerdem ist eine CCZertifizierung – wie andere Zertifizierungen auch – eine

Momentaufnahme eines Produkts zum Zeitpunkt der Zertifizierung und berücksichtigt Änderungen und Weiterentwicklungen nach dem Zeitpunkt der Prüfung nicht. Dies gilt auch für nachträglich verfügbare Sicherheitsupdates. Die elektronische Gesundheitskarte (eGK), die Sie alle von Ihrer Krankenkasse bekommen haben, dürfte die am weitesten verbreitete Produktklasse der nach Common Criteria zertifizierten Produkte sein. Smart Meter Gateways, elektronische Fahrtenschreiber und sichere Signaturerstellungseinheiten sind weitere IT-Komponenten, die zur Zulassung eine Common-CriteriaZertifizierung benötigen. Die verschiedenen Dokumente des Common-Criteria-Standards sind kostenfrei in englischer Sprache verfügbar (https://www.commoncriteriaportal.org).

PCI-DSS Der Payment Card Industry Data Security Standard (PCI-DSS) ist ein Standard, in dem der Umgang beim Speichern, Verarbeiten und Übertragen von Zahlungsdaten (zum Beispiel bei Kreditkartenzahlungen) geregelt wird. Die Version 1.0 des Standards stammt aus dem Jahr 2004, die aktuelle Version 3.2.1 ist von 2018. Neben den großen Herausgebern von Kreditkarten sind auch viele Banken und große Händler im PCI Security Standards Council (PCI SSC) organisiert. Der Standard gilt dabei nicht nur im Bankenumfeld, sondern im Prinzip für alle, die Zahlungen mit einer Zahlungskarte abwickeln. Der Standard macht in sechs Hauptgruppen und zwölf Abschnitten technische und organisatorische Vorgaben. Die Vorgaben sind durchaus auch für normale Unternehmen als Ideengeber für eigene Maßnahmen interessant, da sie sehr viel konkreter als in einer ISO/IEC-27002Vorgabe formuliert sind. Die Abschnitte sind noch weiter in Anforderungen unterteilt. Die Zahl der Anforderungen der Abschnitte ist in Klammern angeben.

Erstellung und Wartung sicherer Netzwerke und Systeme 1. Installation und Wartung einer Firewall-Konfiguration zum Schutz von Karteninhaberdaten (19) 2. Keine vom Anbieter gelieferten Standardeinstellungen für Systemkennwörter und andere Sicherheitsparameter verwenden (10) Schutz von Karteninhaberdaten 3. Schutz gespeicherter Karteninhaberdaten (19) 4. Verschlüsselung bei der Übertragung von Karteninhaberdaten über offene öffentliche Netze (3) Unterhaltung eines Anfälligkeits-Managementprogramms 5. Schutz sämtlicher Systeme vor Malware und regelmäßige Aktualisierung von Antivirensoftware und Programmen (5) 6. Entwicklung und Wartung sicherer Systeme und Anwendungen (25) Implementierung starker Zugriffskontrollmaßnahmen 7. Beschränkung des Zugriffs auf Karteninhaberdaten je nach Geschäftsinformationsbedarf (7) 8. Zugriff auf Systemkomponenten identifizieren und authentifizieren (21) 9. Physischen Zugriff auf Karteninhaberdaten beschränken (20) Regelmäßige Überwachung und regelmäßiges Testen von Netzwerken 10. Verfolgung und Überwachung des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten (26) 11. Regelmäßiges Testen der Sicherheitssysteme und -prozesse (12) Befolgung einer Informationssicherheitsrichtlinie 12. Verwaltung einer Informationssicherheitsrichtlinie für das gesamte Personal (33)

In Anhängen (aktuell drei) werden zusätzliche Anforderungen für bestimmte Einrichtungen festgeschrieben. Der PCI-DSS wurde bekannt, weil hier schon sehr früh (2015) eine Migration (und die damit verbundene Abschaltung der älteren Versionen) nach TLS 1.2 festgeschrieben wurde. Bereits im April 2015 wurde im PCI-DSS 3.1 festgelegt, »dass SSL und frühe TLS-Versionen nicht mehr als starke Verschlüsselung betrachtet werden« und für eine sichere Übertragung von Zahlungsdaten ab dem 30. Juni 2016 nicht mehr eingesetzt werden sollen. Da die Dokumente des PCI-DSS frei heruntergeladen werden können, ist er für alle Unternehmen eine nützliche Sammlung von Dokumenten (https://www.pcisecuritystandards.org/document_library). Insbesondere die zu jeder Anforderung im Standard PCI-DSS festgelegten Prüfverfahren liefern Ihnen gute Hilfestellungen für eigene Prüfungen. Viele der Anforderungen sind generisch und nicht nur für die Verarbeitung von Zahlungskarten verwendbar. Es gibt dort auch noch weitere Standards, zum Beispiel für Kartenhersteller (Card Producer, PCI-CP). Diesen können Sie zu Rate ziehen, wenn es um besonders schützenswerte Daten geht.

FIPS Die Federal Information Processing Standards (FIPS) sind wichtige Standards des US-amerikanischen National Instituts of Standards and Technolgy (NIST). Sie sind somit offizielle Standards der USRegierung, die auch häufig bei IT-Ausschreibungen die technischen Anforderungen abbilden. Damit sind es Anforderungen, die die großen (US-amerikanischen) IT-Hersteller mit ihren Produkten einhalten. Gerade auch im Bereich der Kryptografie (siehe Kapitel 17) gibt es zahlreiche relevante Standards. Einige der wichtigeren Standards sind: 46

Data Encryption Standard, DES (1977, inzwischen ungültig);

81

DES Modes of Operation (1980, inzwischen ungültig);

140-3 Security Requirements for Cryptographic Modules (2019); 180-4 Secure Hash Standard, SHS (2015); 197

Advanced Encryption Standard, AES (2001);

198-1 The Keyed-Hash Message Authentication Code, HMAC (2008); 202

Secure Hash Algorithm 3, SHA-3 (2015).

In den Standards werden aktuell der AES-Algorithmus und die Hashfunktionen SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 und SHA-3 definiert. Auch das HMAC-Verfahren ist in einem FIPSStandard beschrieben. Kryptografische Module können nach FIPS 140-3 (und den darin enthaltenen Verweisen auf andere Standards) zertifiziert werden. Ein bekanntes Beispiel ist die FIPS-140-2-Zertifizierung eines speziellen Teils von OpenSSL im Jahr 2006 (die Vorgängerversion von FIPS 1403). Zertifiziert wurde dabei ein spezielles Modul (OpenSSL FIPS Object Module 2.0), das kompatibel mit OpenSSL 1.0.2 ist. Die Zertifizierung bezieht sich dabei ausschließlich auf die Kryptoalgorithmen. Es soll auch ein nach FIPS 140-2 zertifiziertes OpenSSL FIPS Object Module 3.0 geben, das mit OpenSSL 3.x verwendet werden kann. Das NIST veröffentlicht auch weitere Standards, wie die Reihe Special Publications 800 (SP-800). Hier sind die SP-800-12rev1 »An Introduction to Information Security«, SP-800-30rev1 »Guide for Conducting Risk Assessments« sowie die SP-800-38A bis 38G »Recommendation for Block Cipher Modes of Operation« interessant. Die SP-800-38x Dokumente haben den FIPS 81 Standard abgelöst. Da Sie alle NIST-Dokumente kostenfrei erhalten (https://csrc.nist.gov/publications), sind diese eine praktische Informationsquelle. Leider gibt es keine deutschen Fassungen, sondern nur die englischen Versionen der Dokumente.

ITIL

Eigentlich ist die Information Technology Infrastructure Library (ITIL) kein IT-Sicherheitsstandard, sondern ein Leitfaden zum IT-ServiceManagement. Wir erwähnen den Standard hier kurz, da er häufig im Kontext der Informationssicherheit erwähnt wird. Aktuell ist ITIL 4 aus den Jahren 2019/20. Ursprünglich wurde ITIL in den 1980er Jahren von britischen Regierungsstellen geschaffen. Mitarbeiter eines Unternehmens können eine ITIL-Zertifizierung bekommen. Unternehmen können nicht nach ITIL zertifiziert werden. Unternehmen, die ihr IT-Service-Management ITIL-konform betreiben, können aber leicht nach ISO/IEC 20000 zertifiziert werden. In der ITIL wird darauf hingewiesen, dass Sie bei der Gestaltung Ihrer IT-Prozesse auch an die Informationssicherheit denken müssen. Entsprechend wird zum IT-Sicherheitsmanagement die ISO/IEC 27000 empfohlen. Die Prozesse des IT-Servicemanagements nach ITIL und des Informationssicherheitsmanagements nach der ISO/IEC 27000 sollten eng miteinander verzahnt sein.

Kapitel 10

Technisch-organisatorische Maßnahmen (TOM) IN DIESEM KAPITEL IT-Sicherheit unterstützt den Datenschutz Kernelemente des technischen Datenschutzes

Im Bereich der technisch-organisatorischen Maßnahmen treffen sich Datenschutz und Informationssicherheit. Der Datenschutz fordert die Einhaltung von Schutzzielen und die Informationssicherheit liefert die technisch-organisatorische Umsetzung. In diesem Kapitel finden Sie die Vorgaben der Anlage zu § 9 BDSG a. F. eingeordnet in die Vorgaben des Art. 32 Abs. 1 DS-GVO. Bei einigen Punkten finden Sie auch noch die passenden Punkte aus der ISO/IEC 27002. Wir haben bewusst auch acht Kontrollen aus der Anlage des alten BDSG benutzt, da viele Datenschutzbeauftragte diese Struktur die letzten zwanzig Jahre vor der DS-GVO genutzt haben.

Vertraulichkeit Die Regelungen zum Schutzziel Vertraulichkeit im BDSG a. F. gingen von einem Schalenmodell aus. Wer sich »Zutritt« zum Rechnerraum oder zum Büro verschaffen kann, kann den Rechner berühren. »Zugang« beschreibt die Möglichkeit, sich an dem Rechner anzumelden und das Betriebssystem zu nutzen. »Zugriff« ist schließlich das Recht, auf die Daten zuzugreifen. Auch wenn dieses Schalenmodell seine Wurzel in der MainframeRechnerarchitektur der 1960er Jahre hat, ist es für Rechenzentren und

Server immer noch geeignet. Bei Desktoprechnern und insbesondere bei Notebooks und anderen mobilen Geräten stößt es jedoch an seine Grenzen.

Zutrittskontrolle, physische und umgebungsbezogene Sicherheit … Unbefugten den Zutritt zu Dateiverarbeitungsanlagen, mit denen personenbezogene Daten verarbeitet oder genutzt werden, zu verwehren (Nr. 1 Anlage zu § 9 BDSG a. F.) Der wichtigste Punkt für eine Zutrittskontrolle sind verschlossene Türen mit einem klaren Konzept der Schließberechtigungen. Wenn Sie heute ein Schließsystem im IT-Bereich einführen, spricht viel für ein elektronisches Schließsystem, da es unter Sicherheitsgesichtspunkten viele Vorteile bietet. Wird ein digitaler Schlüssel verloren, können Sie ihn sperren. Außerdem lassen sich Türöffnungen protokollieren und über den Schlüssel einer Person zuordnen. (Hinweis: Da durch ein digitales Schließsystem potenziell eine Kontrolle der Beschäftigten möglich ist, sollten Sie vor der Einführung mit Ihrem Betriebs- oder Personalrat reden.) Bei mechanischen Schlüsseln lassen sich Türen mit entsprechenden Sensoren überwachen und bei Öffnung (zum Beispiel außerhalb der Dienstzeit) ein Alarm auslösen. Das Schließsystem muss mit allen Berechtigungen dokumentiert sein und es muss jederzeit eine Liste aller Personen geben, die über einen Schlüssel verfügen. Zutrittsberechtigungen könne über unterschiedliche Schließberechtigungen abgebildet werden. Rechnerräume dürfen nur von berechtigten Personen betreten werden. Idealerweise hat ein Rechnerraum keine Fenster und einbruchssichere Türen. Gibt es doch Fenster, müssen Sie sich Gedanken machen, wie die Fenster einbruchssicher ausgerüstet werden können. In Deutschland gibt es Normen zur Widerstandsfähigkeit von Fenstern, wie zum Beispiel die europäische EN 1627:2011 (in Deutschland als DIN-Norm EN 1627:2011-09). Diese Normen bieten beim Einbruchsschutz eine gute Orientierung.

Nach oben gibt es für die Gestaltung der Zutrittssicherung keine Grenzen. Die Rechenzentren großer Cloud-Anbieter stehen in der Sicherung mit Zäunen, Videoüberwachung und Kontrollen am Eingang militärischen Sicherheitsbereichen in nichts nach. Das sind Maßnahmen, die Sie in Ihrem Unternehmen mit hoher Wahrscheinlichkeit nicht treffen müssen. In einer kleinen Arztpraxis oder Anwaltskanzlei gibt es häufig nicht einmal einen Rechnerraum. Aber auch hier können Rechner weggeschlossen werden. Es gibt abschließbare Rechnerschränke, in denen Server, Firewall und Router eingeschlossen werden können. Und wenn die Rechnerschränke dann auch wirklich dauerhaft abgeschlossen sind, gibt das eine akzeptable Zutrittskontrolle. Von Zeit zu Zeit sollten Sie eine Inventarkontrolle im Rechnerraum beziehungsweise im Rechnerschrank machen. Sind alle Geräte noch vorhanden? Gibt es neue Geräte, von denen niemand etwas weiß? Ist die Verkabelung noch so, wie sie sein soll? Und natürlich müssen Sie diese Kontrolle im Rahmen Ihrer Nachweispflichten dokumentieren.

Zugangskontrolle, Zugangssteuerung … zu verhindern, dass Datenverarbeitungssysteme von Unbefugten genutzt werden können (Nr. 2 Anlage zu § 9 BDSG a. F.) Jedes IT-technische System muss eine sichere Anmeldung bieten. Ausnahmen sind lediglich die Geräte, die technisch keine Anmeldemöglichkeit benötigen, da sie nicht konfiguriert werden, wie zum Beispiel nicht-managebare Switches, Medienkonverter oder Repeater. Die höchste Sicherheit haben Sie natürlich, wenn Sie zur Administration physisch zum System hingehen müssen, um sich direkt am System anzumelden. Das ist heute nicht zeitgemäß und bei Servern im Rechenzentrum eines Dienstleisters auch gar nicht möglich. Hier sollte vielmehr darauf geachtet werden, dass das Management über ein getrenntes Netz erfolgt. Bei Netzwerkkomponenten oder IoT-(Internetof-Things-)Geräten ist die direkte Zugänglichkeit meist schwierig.

Bei Ihrer privaten Heizungssteuerung oder Ihrem DSL-Router können Sie sich nur über eine Netzwerkverbindung anmelden, da diese Geräte keinen Anschluss für Tastatur und Monitor haben. Deshalb müssen Sie hier auf eine Anmeldung über eine verschlüsselte Verbindung (im Privatbereich fast immer https) achten. Auch im Unternehmen gibt es zahlreiche IT-Geräte, an denen Sie keine Tastatur und keinen Monitor anschließen können. Die Heizungsteuerung gehört zur Gebäudeleittechnik und Router gibt es auch im Unternehmen. Manchmal gibt es bei den Profigeräten noch eine Anschlussmöglichkeit über eine sogenannte serielle Schnittstelle für Notfälle. Auch bei der direkten Anmeldung müssen Sie auf qualitativ gute Passwörter achten. Sichere Anmeldung über das Netz bedeutet, dass die Kommunikation zwischen Ihrem Rechner, von dem Sie sich anmelden, und dem System, auf dem Sie sich anmelden, verschlüsselt erfolgt, das heißt, dass https oder SSH und nicht http oder telnet genutzt werden. Auch die Anmeldung über Dienste wie Remotedesktop, X11 oder VNC muss über einen verschlüsselten Kanal laufen. Es muss sichergestellt werden, dass kein Man-in-the-Middle-Angriff möglich ist. In größeren Unternehmen macht es Sinn, für die Administration ein eigenes Netz zu verwenden, dass von dem normalen Netz komplett getrennt ist und das keine Verbindung zum Internet hat. Alle Administrationsaufgaben werden nur in diesem Netz durchgeführt. Schafft es ein Angreifer, sich auf einem Rechner eines Beschäftigten einzunisten, hat er keinen Zugriff auf die Administration, da diese komplett getrennt ist. Administratoren kann es zugemutet werden, besonders komplexe Passwörter (Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen sowie Mindestlänge 12 Zeichen) zu verwenden. Sie sollten zusätzlich eine Zwei-Faktor-Authentisierung (2FA) verwenden. Es gibt zahlreiche Verfahren zur Realisierung einer 2FA. In Kapitel 19 schauen wir uns einige davon genauer an.

Damit Angreifer sich nicht passwortlos oder per Rechteausweitung (Privilege Escalation) über Sicherheitslücken anmelden können, sind flankierende Maßnahmen erforderlich. Alle aktuellen Sicherheitsupdates müssen eingespielt werden. Auf allen Rechnern sollte ein Virenschutz installiert sein. Auf allen virengefährdeten Systemen (derzeit Windows und macOS) muss ein Virenschutz installiert sein. Auch eine weitgehende Datenträgerverschlüsselung auf den Arbeitsplatzrechnern und Servern ist wichtig, damit Unbefugte nicht die Inhalte der Festplatten bei ausgeschaltetem Rechner manipulieren können. Auch ein netzwerktechnischer Zugangsschutz mit Firewalls, Angriffserkennungs- und Angriffsverhinderungssystemen ist erforderlich. Diese Maßnahmen ergänzen die Netztrennung von Betriebs- und Administrationsnetz. Bei fehlender Netztrennung sind diese Systeme umso wichtiger.

Zugriffskontrolle … zu gewährleisten, dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können und dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können (Nr. 3 Anlage zu § 9 BDSG a. F.) Die Zugriffskontrolle verlangt ein Berechtigungskonzept. Sie muss genau festlegen, welche Beschäftigen auf welche Daten oder Systeme zugreifen dürfen. Wie Berechtigungskonzepte aussehen, schauen wir uns in Kapitel 14 genauer an. Voraussetzung für ein Berechtigungskonzept ist ein Nutzermanagement. Jede Person im Unternehmen, die die IT nutzt, hat ein Nutzerkonto. Umgekehrt ist jedes Nutzerkonto einer verantwortlichen Person zugeordnet. Eine Anmeldung an einem System darf nur mit einer Nutzerkennung geschehen, die einer Person gehört. Um sicherzustellen, dass niemand sich mit einer fremden Kennung anmeldet, müssen Sie die

Weitergabe der Passwörter und PINs verbieten. Dass Person M sich mit dem Nutzerkonto der Person A anmeldet, können Sie technisch nur durch biometrische Verfahren (siehe Kapitel 18) sicherstellen. Bei anderen Anmeldeverfahren können Sie das nur organisatorisch gewährleisten, das heißt durch Verbote. Zur Zugriffskontrolle gehören auch Regelungen, welche Daten wie (zum Beispiel nur verschlüsselt) und auf welchen Datenträgern gespeichert werden dürfen. Personenbezogene und andere vertrauliche Daten dürfen auf mobilen Datenträger nur verschlüsselt abgelegt werden. Mobile Datenträger sind alle Datenträger, die per USB an einen Rechner angeschlossen werden können, optische Datenträger, wie zum CD-ROM, DVD oder Blu-ray, aber auch Speicherkarten wie zum Beispiel CompactFlash, SD- oder microSD-Karten. Sie müssen auch regeln, welche Daten auf Smartphones oder Notebooks gespeichert werden dürfen und welche Daten im Unternehmen bleiben müssen. Dass Daten im Unternehmen bleiben müssen, bedeutet unter Umständen dann auch, dass Sie nicht von außerhalb des Unternehmens, zum Beispiel aus dem Homeoffice, darauf zugreifen dürfen. Und da wir nicht nur IT-Sicherheit, sondern Informationssicherheit betreiben wollen – welche Papiere dürfen das Unternehmen verlassen? Eine Regelung, die gerne vergessen wird. Sie müssen Daten im Unternehmen sicher aufbewahren. Besonders wichtig ist das Backup. Dieses ist oft unverschlüsselt, um die Wiederherstellbarkeit der Daten zu gewährleisten. Sie haben immer mindestens eine Kopie des Backups, die Sie räumlich getrennt lagern. Da müssen Sie sich über einen Zugriffsschutz Gedanken machen. Sie müssen auch das Löschen oder Vernichten der Daten planen. Unter dem Gesichtspunkt »Zugriffskontrolle« geht es einerseits um Daten, die auf die Entsorgung warten und andererseits um Daten auf Rechnern, wenn die Rechner entsorgt oder an andere Nutzerinnen zur weiteren Nutzung übergeben werden.

[Trennungskontrolle], Nichtverkettbarkeit

… zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können (Nr. 8 Anlage zu § 9 BDSG a. F.) Daten, die im Unternehmen zu unterschiedlichen Zwecken erhoben werden, dürfen nicht ohne Weiteres zusammengeführt werden (Art. 5 Abs. 1 Lit. b DS-GVO). Ein Beispiel wären Unternehmen, bei denen die Beschäftigten auch gleichzeitig Kunden sein können. Hier dürfen die Daten aus den beiden Bereichen nicht einfach so zusammengeführt werden. Beim Outsourcing, egal ob in die Cloud oder klassisch bei einem Dienstleister, verarbeitet der Dienstleister Daten unterschiedlicher Kunden in seinen Systemen. Dieser Dienstleister muss sicherstellen, dass die Daten der verschiedenen Kunden nicht vermischt werden. Als Kunde des Dienstleisters müssen Sie sich Gedanken machen, wie weit die Trennung Ihrer Daten von den Daten anderer Kunden gehen soll. Wollen Sie Ihre eigene Hardware, also Ihren eigenen Rechner, um von anderen Kunden des Dienstleisters abgeschottet zu sein? Oder reicht Ihnen die Mandantentrennung in einer Anwendung wie Salesforce, SAP oder ServiceNow? Eine wichtige Voraussetzung ist, dass keine mandantenübergreifenden Auswertungen möglich sind. Wenn Sie Ihre Unternehmens-E-Mail an einen der großen E-Mail-Hoster auslagern, können Sie nicht davon ausgehen, dass dieser für Sie einen eigenen Mail-Server aufsetzt. Die Vorteile, die Sie durch das Outsourcen der E-Mail haben wollen, erreichen Sie auch nur, wenn Sie die E-MailInfrastruktur des Anbieters nutzen. Speichern Sie Daten in der Cloud, wird die Deduplizierung (siehe Kasten »Deduplizierung«) zu einem wichtigen Thema. Die einzige technische Maßnahme, die Ihnen da hilft, ist die Verschlüsselung der in der Cloud gespeicherten Daten.

Deduplizierung

Wenn wir die Festplatte unseres Rechners untersuchen, werden wir feststellen, dass wir zahlreiche Dateien mehrfach gespeichert haben. Gehen Sie einen Schritt weiter und schauen Sie sich im Unternehmen die Daten an, werden Sie noch mehr Duplikate finden. Da es völlig ausreichend ist, eine Kopie einer Datei zu haben, sollten wir alle Duplikate (bis auf die Kopien im Backup) löschen. Diesen Vorgang nennt man Deduplizierung. Durch die Deduplizierung wird auch die Größe des Backups reduziert, da nicht zahlreiche Kopien einer Datei ins Backup gesichert werden müssen. Es gibt Dateisysteme, die eine Deduplizierung eingebaut haben, zum Beispiel beherrschen APFS (Apple File System seit macOS 10.13), ZFS und eingeschränkt Btrfs (B-Tree File System) die Deduplizierung. Die Deduplizierung arbeitet typisch nicht auf Dateiebene, sondern auf der Ebene des darunter liegenden Datenträgers. Die Deduplizierung erfordert einiges an Verwaltungsoverhead, sodass es immer ein Abwägen gibt: weniger Speicherplatz oder mehr Geschwindigkeit. Die großen Anbieter von Cloud-Speicher (zum Beispiel Dropbox) nutzen Deduplizierung teilweise sogar nutzerübergreifend. Laden zwei Nutzerinnen mit unterschiedlichen Konten zwei identische Dateien hoch, wird nur eine Datei gespeichert. Gerade bei Files, die extrem oft in der Cloud gespeichert werden, wie Musikdateien oder Videoclips, spart das extrem viel Speicherplatz. Verschlüsselung ist der Feind der Deduplizierung. Wird eine identische Datei von zwei Nutzerinnen verschlüsselt gespeichert, werden tatsächlich zwei Dateien gespeichert. Der Cloud-Anbieter kann auf Grund der Verschlüsselung nicht mehr feststellen, dass die Ursprungsdateien identisch waren.

Sie können eine sofortige Löschung bei in der Cloud gespeicherten Daten nicht garantieren. Gibt es die Datei noch bei einem anderen Kunden des Dienstleisters, bleibt die Datei erhalten. Ein »anderer Kunde« könnte auch das private Konto eines Beschäftigten sein, in das er die dienstliche Datei verbotenerweise kopiert hat. Nur die Verbindung zu Ihrem Unternehmen wird gelöscht. Die Deduplizierung macht eine DS-GVO-konforme Nutzung der CloudSpeicherung für Unternehmen ohne Verschlüsselung der Daten nahezu unmöglich. Dieses Thema wurde bisher so gut wie nicht von Datenschützern diskutiert.

Pseudonymisierung … Daten so zu verarbeiten, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer

spezifischen betroffenen Person zugeordnet werden können (Art. 4 Nr. 5 DS-GVO) Bei personenbezogenen Datensätzen können Sie zwischen Identifikatoren, Teil-Identifikatoren und den potenziell sensiblen Attributen unterschieden (siehe Abbildung 10.1). Identifikatoren wie zum Beispiel die Personalnummer im Unternehmen erlauben Ihnen die direkte Zuordnung zu einer Person. Sie müssen bei der Pseudonymisierung alle Identifikatoren aus dem Datensatz entfernen und durch ein Pseudonym ersetzen. Die Tabelle mit der Zuordnung Pseudonym zu Identifikatoren müssen Sie getrennt von den eigentlichen Daten aufbewahren. Wird diese Zuordnungstabelle vernichtet, sprechen wir von anonymen Daten.

Abbildung 10.1: Beispiele für Identifikatoren, Teil-Identifikatoren und potenziell kritische Attribute im Umfeld von Beschäftigtendaten. (Darstellung in Anlehnung an S. Ecker, Masterarbeit Hochschule München 2021)

Bei den Teil-Identifikatoren erlaubt Ihnen jeder einzelne für sich keine Zuordnung zu einer Person. In Kombination oder als Verbindungsglied zu anderen Datenbeständen ermöglichen sie Ihnen jedoch potenziell die

Identifikation der Person. So sind PLZ, Geburtsdatum und Geschlecht jeweils allein nicht ausreichend, um eine Person zu identifizieren. In Kombination und insbesondere mit Zusatzwissen reichen sie jedoch häufig aus. Als Zusatzwissen reicht Ihnen in Ihrem Unternehmen oft schon die Tatsache, dass es sich um Beschäftigte handelt. Auch über eine Verknüpfung zu Social-Media-Profilen können Sie über solche QuasiIdentifikatoren unter Umständen zu einer Aufdeckung des Pseudonyms kommen. Es gibt einige berühmte Beispiel von erfolgreichen Deanonymisierungsangriffen. Die anonymisierte Entlassungsdatenbank von Krankenhäusern in Massachusetts wurde durch Zusammenführung mit den Wählerverzeichnissen des Bundesstaats deanonymisiert [Swe97]. Ein von AOL veröffentlichter anonymisierter Datensatz mit 20 Millionen Suchanfragen von 658.000 Nutzerinnen konnte erfolgreich deanonymisiert werden [Han06]. Netflix veröffentlichte anonymisierte Filmbewertungen von 500.000 Kunden. Auch hier war ein Deanonymisierungsangriff erfolgreich [NS08]. Ein erfolgreicher Angriff kann im Allgemeinen nicht alle Datensätze deanonymisieren, aber doch einen gewissen Teil. Als Attribute (der Person) werden die Daten bezeichnet, die etwas über die Person aussagen. Das können medizinische Diagnosen, Finanzdaten oder auch Daten über das Verhalten der Person sein. Sinn der Pseudonymisierung ist es, mit den Attributen zu arbeiten oder Auswertungen zu erstellen, ohne dass Ihnen offengelegt wird, um welche Person es sich jeweils handelt. Damit die Qualität der Pseudonymisierung objektiv beurteilt werden kann, gibt es verschiedene Verfahren, um dies quantitativ messbar zu machen. k-Anonymität (k-Anonymity) ist ein Konzept, das 2002 von Latanya Sweeny eingeführt wurde [Swe02]. Dabei müssen Sie die Identifikatoren so verallgemeinern, dass keine Einzelpersonen mehr ausgewählt werden können. Jedes Kriterium zur Selektion ergibt als Antwort immer mindestens k Personen (Datensätze). Verallgemeinern heißt dabei zum

Beispiel, dass Sie das Geburtsdatum auf das Geburtsjahr oder Geburtsjahrgänge reduzieren oder die PLZ auf den Kreis oder den Bezirk vergröbern. Konkret müssen Sie im Einzelfall analysieren, was eine geeignete Verallgemeinerung ist. Dabei müssen Sie gleichzeitig verifizieren, inwieweit die Qualität der Auswertung der pseudonymisierten Daten im Vergleich zu den nicht-anonymisierten Daten leidet. Bei der k-Anonymität ist die geringste Qualität der Anonymität für den Wert gegeben: In allen Gruppen gibt es dann mindestens zwei unterschiedliche Wert für ein kritisches Feld. Innerhalb einer Gruppe von k Datensätzen müssen Sie darauf achten, dass die Attribute innerhalb der Gruppe hinreichend unterschiedlich sind. Um einen Angriff über die Homogenität der Attribute zu vermeiden, sind weitere Konzepte nötig. Auf der Abiturfeier berichtet der Direktor, dass es bei den männlichen Abiturienten sechsmal die Note befriedigend und bei den weiblichen Abiturienten einmal die Note sehr gut, zweimal die Note gut und viermal die Note ausreichend gab. Hier wurden, trotz der versuchten Anonymisierung, die Noten der männlichen Abiturienten offengelegt, da es in dieser Gruppe nur einen Wert (befriedigend) für das Attribut Note gab. Die l-Diversität (l-Diversity) ist ein Konzept zur Messung der Varietät (Unterschiedlichkeit) der Werte eines Attributs in einer Gruppe, das 2006 von Ashwin Machanavajjhala und Mitarbeitern eingeführt wurde [MGKV06]. Nach diesem Modell müssen Sie in jeder Gruppe mindestens l unterschiedliche Werte eines Attributs haben. Ein Problem beim Messen der Diversität ist, dass zwei Werte als unterschiedlich betrachtet werden, obwohl sie semantisch nahe zusammen sind (zum Beispiel Bluthochdruck und Hypertonie). Da eine vernünftige l-Diversität häufig schwer zu erreichen ist, entwickelten Ninghui Li und Mitarbeiter 2007 das Konzept der tÄhnlichkeit (t-Closeness) [LLV07]. Dabei wird die Verteilung der Werte in der betrachteten Gruppe mit der Verteilung der Werte in der

Gesamtheit verglichen. Die beiden Verteilungen dürfen sich nur um das Maß t unterscheiden. Den Unterschied der Verteilungen messen Sie mit einer geeigneten Metrik. Bei der Pseudonymisierung dürfen Sie auf keinen Fall einfach einen Hashwert über die Identifikatoren bilden. Sind die Identifikatoren bekannt, könnte dann ein Dritter jederzeit testen, ob eine bestimmte Person zu den betroffenen Personen gehört. Er muss lediglich die Werte der zu testenden Person in die Identifikatoren einsetzen und dann den Hashwert berechnen und vergleichen. Insbesondere wenn der Wertevorrat der (Teil-)Identifikatoren klein ist (zum Beispiel KfzKennzeichen, Geburtsdatum) ist ein Brute-Force-Angriff gegen den Hashwert möglich. Deshalb dürfen Sie nur Hashfunktionen mit Passwort verwenden und müssen dann das Passwort unbedingt geheim halten. Alternativ können Sie auch die Identifikatoren durch Zufallszahlen ersetzen, die keinen Bezug zum Wert des Identifikators haben. Sie sehen, richtiges Pseudonymisieren ist richtig schwierig. Deswegen ist es schade, dass Pseudonymisierung an erster Stelle bei den Maßnahmen in Art. 32 Abs. 1 DS-GVO genannt wird. Damit wir uns nicht falsch verstehen, richtige Pseudonymisierung ist ein guter Schutz zur Gewährleistung der Vertraulichkeit. Wenn Sie aber in einem Sicherheitskonzept für einen E-Mail-Server lesen, dass alle personenbezogenen Daten auf dem E-Mail-Server pseudonymisiert werden sollen, dann ist das schwer vorstellbar. Wie wollen Sie die EMails so pseudonymisieren, das die E-Mail noch funktioniert und die EMail-Inhalte noch sinnvoll gelesen werden können?

Verschlüsselung, Kryptografie … die Verwendung von dem Stand der Technik entsprechenden Verschlüsselungsverfahren (Anlage zu § 9 BDSG a. F.) Wenn Sie Verschlüsselung nach dem Stand der Technik einsetzen wollen, müssen Sie prüfen, was die aktuellen Verschlüsselungsstandards sind, damit Sie keine veralteten Verfahren einsetzen. Auch den Einsatz von nicht anerkannten Verschlüsselungsverfahren müssen Sie

vermeiden. Technische Details zu Verschlüsselungsverfahren finden Sie im Kapitel 17. Erste Wahl bei den symmetrischen Verfahren ist der AES-Algorithmus. Bei den asymmetrischen Verfahren kommen RSA oder Verfahren auf Basis standardisierter elliptischer Kurven infrage. Bei den HashFunktionen sollten die Familien SHA-2 und SHA-3 eingesetzt werden. In der technischen Richtlinie TR-02102 des BSI finden Sie weitergehende sinnvolle Empfehlungen. Bleibt die Frage, was muss verschlüsselt werden. Alle Datenträger, die das Unternehmen verlassen, sollten verschlüsselt werden. Betrachten Sie Notebooks und Smartphones auch als Datenträger im Sinne einer solchen Vorgabe. Außerdem sollten Sie alle Daten verschlüsseln, auf die Dienstleister potenziell zugreifen können. Eine Behörde hat eine IT-Dienstleister, der alle Server betreut. Dazu gehören auch die File- und Backup-Server, auf denen alle Daten der Behörde gespeichert sind. Technisch hat der Dienstleister Zugriff auf alle Daten. Der Vertrag mit dem Dienstleister läuft aus und muss neu ausgeschrieben werden. Die zuständigen Beschäftigen beginnen, die Ausschreibung vorzubereiten, und sammeln die Anforderungen der Fachabteilungen ein. Alle Dateien werden in einem Verzeichnis mit dem Namen neuausschreibung_IT-dienstleistung_2021 gespeichert. Den Zuschlag erhielt der bisherige Dienstleister, der das am besten passende Angebot abgeben hat. Ein Mitbewerber ficht das Vergabeverfahren an, da der bisherige IT-Dienstleister durch den Zugriff auf die Ausschreibungsdateien einen ungerechtfertigten Vorteil gehabt habe. Durch eine Verschlüsselung der Daten hätte dieses Einspruchsverfahren vermieden werden können.

Den Zugriff von außen, sei es aus dem Homeoffice, während einer Dienstreise aus dem Hotel oder durch einen Dienstleister im Rahmen einer Fernwartung, müssen Sie durch Verschlüsselung der Netzwerkverbindung (zum Beispiel ein VPN oder einen SSH-Tunnel) absichern. Nur dann ist gewährleistet, dass niemand die Verbindung abhören kann. Gerade auch wenn Beschäftigte mit ihren dienstlichen ITGeräten fremde Netze (zum Beispiel Hotel-WLAN, WLAN im ICE oder jedes andere von jedermann nutzbare WLAN) nutzen, ist es sinnvoll, den Datenverkehr durch ein VPN zu schützen. Es ist eine gute Angewohnheit, wenn Sie auch bei der Nutzung öffentlicher WLANs mit Ihren privaten IT-Geräten einen VPNClient nutzen. Technisch versierte Zeitgenossen mit einem schnellen Internetanschluss nutzen dafür häufig ihren eigenen VPN-Server zuhause. Es gibt aber auch kostenlose und kostenpflichtige VPN-Anbieter mit Sitz in der Europäischen Union, die Ihnen die private Nutzung eines VPN ermöglichen. Ihr Unternehmen sollte alle Web-Dienste nur verschlüsselt anbieten. Das ist heute mit vertretbarem Aufwand möglich. Als Stand der Technik gelten hierbei die Protokolle TLS 1.2 und TLS 1.3. Alle älteren Varianten von SSL 2 bis TLS 1.1 gelten als unsicher und sollten nicht mehr genutzt werden. Das Mozilla-Projekt stellt unter https://wiki.mozilla.org/Security/Server_Side_TLS eine ausführliche Anleitung zur Konfiguration von TLS für alle gängigen Webserver zur Verfügung. Die TLS-Verschlüsselung spielt auch bei der E-Mail-Kommunikation eine wichtige Rolle. Es ist Stand der Technik, dass zwei Mail-Server die E-Mails über eine verschlüsselte Verbindung austauschen (SMTPS statt SMTP). Auch hier sollte eine entsprechende gute TLS-Verschlüsselung genutzt werden. Aktuelle Untersuchungen [PD21] zeigen, dass das nicht immer so ist. Wenn Sie sich vertiefend für das Thema interessieren, empfehlen wir Ihnen die Webseite https://mail-sicherheit.jetzt.

Auch die Telefonie mittels VoIP erfolgt normalerweise unverschlüsselt. Es ist aber möglich, eine Verschlüsselung der VoIP-Telefonie einzurichten. Das ist keine (!) Verschlüsselung von Telefon zu Telefon, sondern nur zwischen Telefon und Telefonanlage. Wenn Sie eine Verschlüsselung von Telefon zu Telefon wollen, benötigen Sie spezielle abhörsichere Telefone. Die Verschlüsselung der Gespräche funktioniert dann aber auch nur zwischen den speziellen Telefonen.

Integrität Auch Integrität ist ein Schutzziel im Datenschutz, das häufig nicht beachtet wird, da beim Datenschutz meist nur die Vertraulichkeit der personenbezogenen Daten gesehen wird. Dabei ist die Bedeutung der Korrektheit von Daten nicht zu unterschätzen. Wer hat den konkreten Wert der Daten in den Rechnern eingegeben? Was ist mit den Daten beim Transport passiert? Wer hat die Daten gelöscht? Das sind wichtige Fragen, die die verantwortliche Stelle beantworten können muss. Ob Daten richtig sind oder nicht, ist keine Frage der Integrität der Daten, sondern eine Frage der Korrektheit der Daten. Das StandardDatenschutzmodell (SDM) ordnet die Anforderung aus Art. 5 Abs. 1 lit. d. DS-GVO »Richtigkeit« fälschlicherweise dem Gewährleistungsziel Integrität zu (siehe Tabelle unter C.2 im SDM). Die Integrität gewährleistet, dass sich Daten nicht ungewollt ändern oder von Angreifer unbemerkt manipuliert werden. Die Korrektur von Daten nach einer Intervention eines Betroffenen ist ein Verarbeitungsschritt und keine Frage der Integrität.

Eingabekontrolle … zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind (Nr. 5 Anlage zu § 9 BDSG a. F.)

Bei personenbezogenen Daten spielt auch die Herkunft der Daten eine wichtige Rolle. Im Rahmen der Qualitätssicherung können Sie über die Herkunft abschätzen, wie verlässlich und korrekt die Daten sind. Deshalb ist es wichtig, nachvollziehen zu können, wer ein konkretes Datum in das System eingegeben hat. Auch bei technischen Daten ist die Korrektheit von Daten wichtig. Durch falsche Daten kann ein Schaden entstehen. Damit Sie überhaupt nachvollziehen können, wer etwas eingeben hat, müssen Sie die Nutzerinnen authentisieren. Ein gutes Benutzermanagement ist eine Voraussetzung für eine funktionierende Eingabekontrolle. In einem weiteren Schritt müssen Sie protokollieren, wer was eingeben hat. Sie müssen nicht jeden Tastendruck eines Beschäftigten protokollieren. Da wären auch Konflikte mit der Personalvertretung in Ihrem Unternehmen vorprogrammiert. Wenn ein Datenfeld gespeichert wird, müssen Sie wissen, wer den Wert eingegeben und gespeichert hat. Auch dazu müssen Sie nicht die komplette Änderungshistorie vorhalten. Es reicht, wenn Sie bei jedem Datenfeld nachvollziehen können, wer wann den aktuellen Inhalt eingegeben hat. Da Sie Protokolle, aus denen sich Aktivitäten der Beschäftigten ableiten lassen, auch immer zur Verhaltens- und Leitungskontrolle benutzen können, kommt hier die Mitbestimmung zum Tragen (§ 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz oder vergleichbare Regelungen in den Personalvertretungsgesetzen des Bundes und der Länder). Sie sollten Protokollierungen und den Zugriff auf die Protokolle mit Ihrer Personalvertretung, Betriebsrat oder Personalrat, abstimmen. Protokolle sollten immer zugriffsgeschützt aufbewahrt werden, sodass nur Berechtigte darauf zugreifen können. Ziel bei der Protokollierung ist immer: so wenig wie möglich, aber so viel wie nötig. Sie sollten klare Regeln aufstellen, welche personenbezogenen Daten in welches System eingeben werden dürfen und welche nicht. Insbesondere

Freitextfelder für Kommentare sind bei personenbezogenen Daten kritisch, da Sie nur schwer kontrollieren können, was dort eingeben wird.

Digitale Signatur, Hashfunktionen … zu gewährleisten, dass festgestellt werden kann, wenn sich personenbezogene Daten beim Transport oder bei ihrer Speicherung verändert haben Sie haben eine Datei von einem Rechner auf einen alten USB-Stick kopiert, um diese Datei auf einen anderen Rechner zu übertragen. Jetzt wollen Sie wissen, ob die Datei auf den beiden Rechnern gleich ist, oder ob etwas beim Kopieren schiefgegangen ist. Um hier die Gleichheit zu prüfen, rechnen Sie auf beiden Rechnern eine Prüfsumme (genauer Hashwert, siehe Kapitel 17) der Datei aus. Sind die beiden Werte gleich, sind auch die Dateien gleich. Unter einem aktuellen Windows 10 oder 11 können Sie in einer Powershell einfach den SHA256-Hashwert berechnen. Mit dem Kommando Get-Filehash c:\windows\system32\notepad.exe | Format-List erhalten Sie die Ausgabe:

Der Hashwert ist hier verkürzt. Den Hashwert müssen Sie allerdings »mit Ihren Augen« vergleichen. Da der Hashwert von der genauen Dateiversion abhängt, kann auf Ihrem System ein anderer Hashwert angezeigt werden. Mit dem Programm sha256sum, das es für Windows, macOS und Linux gibt, sind Sie flexibler. Das Programm kann eine Datei mit den Hashwerten vieler Dateien erzeugen und diese später auch in einem Rutsch überprüfen. So können Sie zum Beispiel die

Hashwerte aller Dateien, die Sie ins Backup schreiben, in einer Datei speichern und damit das Backup jederzeit überprüfen. Hashwerte sind eine sichere Methode, um Dateien zu vergleichen. Digitale Signaturen gehen ein Stück weiter, indem ein verschlüsselter Hashwert (das heißt eine digitale Signatur) erzeugt wird, um auch den Ersteller der digitalen Signatur festzuhalten. Wegen des größeren Rechenaufwands zur Absicherung der Korrektheit von Dateien, zum Beispiel beim Kopieren, sind digitale Signaturen dabei weniger gebräuchlich. Es macht allerdings durchaus Sinn, beim Archivieren (siehe Kapitel 20) von allen Dateien die Hashwerte zu berechnen und diese in einer Datei zu speichern. Die Datei mit den Hashwerten erhält dann eine digitale Signatur, um das Archivieren des Dateipakets abzuschließen und festzuhalten, wer das Archiv erzeugt hat.

Weitergabekontrolle, Kommunikationssicherheit … zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können und dass überprüft und festgestellt werden kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Datenübertragung vorgesehen ist (Nr. 4 Anlage zu § 9 BDSG a. F.) Natürlich beinhaltet die Weitergabekontrolle auch die Verschlüsselung der Kommunikation. Das haben wir schon unter dem Punkt »Verschlüsselung, Kryptografie« diskutiert. Der erste Halbsatz der vorstehenden Definition ist dadurch im Wesentlichen abgedeckt. Wir müssen uns nur noch mit ein paar Punkten beschäftigten, die nichts mit der Verschlüsselung auf dem Kommunikationsweg zu tun haben. Ein technischer Punkt ist der Umgang mit den diversen Schnittstellen eines Computers. Über die Schnittstellen können Daten abfließen. Ein Beschäftigter steckt seinen USB-Stick in den USB-Port seines Rechners und kopiert verbotenerweise Daten auf den Stick.

Die sicherste Art, das zu verhindern, ist es, die USB-Ports mit Kunstharz unbenutzbar zu machen. Besser sind aber intelligente Lösungen. So kann man USB-Ports auch per Software kontrollieren. Das hat den Vorteil, dass USB-Ports sich für andere Dinge noch nutzen lassen. Außerdem können wir dann einzelnen Personen eine eingeschränkte Nutzung erlauben. Die fortschrittlichsten Lösungen haben den Namen »Data Leakage Prevention«. Im Grunde ist das ein Konzept wie die Spam-Abwehr. Bei der Spam-Abwehr wollen Sie per Software gute und schlechte E-Mails unterscheiden. Gute E-Mails werden zugestellt, schlechte E-Mails kommen in Quarantäne oder den Junk-Mail-Ordner. Bei der Data Leakage Prevention ist es genau umgekehrt: Sie versuchen, die wertvollen und zu schützenden Dateien zu erkennen und diese zu blockieren. Die harmlosen, unkritischen Daten dürfen gerne kopiert werden. Die Firma Microsoft bietet ihren Unternehmenskunden zur Kontrolle der Daten ein Digitales Rechtemanagement (DRM) an. Dabei werden die Inhalte der Dateien verschlüsselt, sodass niemand an die Daten kommt. Die Berechtigungen werden über die Zugänglichkeit von Schlüsseln gesteuert. Kopiert ein Beschäftigter eine derart geschützte Datei auf einen USB-Stick, so kann er die Datei auf einem anderen Rechner nicht öffnen. Abbildung 10.2 zeigt den Auswahldialog zu den Beschränkungen, die dabei für ein Dokument vergeben werden können. Unter dem Punkt »Zugriff einschränken« können Sie dann eine der im Unternehmen konfigurierten Zugriffsrichtlinien auswählen.

Abbildung 10.2: Office-Dokumente können in den Desktopversionen von Microsoft Office mit unterschiedlichen Einschränkungen versehen werden.

So ein DRM ist flexibel und erlaubt es Ihnen auch, Rechte unterschiedlich einzustellen. Allerdings: je ausdifferenzierter Sie ein solches System anwenden, je aufwendiger wird die Konfiguration. Es muss zum Beispiel genau festgelegt werden, welcher Beschäftigte welche Daten wie weitergeben darf.

Eventuell müssen Sie auch protokollieren, wer welche Daten zum Beispiel aus einer Datenbank exportiert hat. Zur Rechenschaftspflicht im Datenschutz gehört unter Umständen, dass Sie zeigen können, dass Daten nicht bei Ihnen kopiert wurden. Ein derartiger Nachwies ist oft schwer zu führen. Es ist leicht zu beweisen, dass ich etwas habe: ich muss es nur vorzeigen. Aber wie beweist man, dass man etwas nicht hat?

Löschkontrolle (»Recht auf Vergessen werden«) … Daten so zu verarbeiten, dass die Daten einer spezifischen betroffenen Person jederzeit gelöscht werden können Das Löschen von Daten ist in der DIN 66398 »Leitlinie zur Entwicklung eines Löschkonzepts mit Ableitung von Löschfristen für personenbezogene Daten« aus dem Jahr 2016 ausführlich beschrieben. Auch die ISO/IEC 27001 regelt in Anhang A.8.3.2: »Nicht mehr benötigte Datenträger werden sicher und unter Anwendung formaler Verfahren entsorgt.« Außerdem findet sich in der ISO/IEC 21964-1/2 die internationale Version der DIN 66398. Darüber hinaus gibt es noch zwei US-amerikanische Publikationen: die NIST Special Publication 800-88 »Guidelines for Media Sanitization« und das NSA/CSS Policy Manual 9-12 »Storage Device Sanitization and Destruction Manual«. Das NSA-Manual ist eher für als hochsicher klassifizierte Datenträger gedacht. Sie finden in den Dokumenten viele technische Details zum Zerstören von Hardware bis hin zur Angabe von Mindesttemperaturen beim Verbrennen. Es wird dort zwischen Löschen (erase), Bereinigen (purge) und Zerstören (destroy) von Datenträgern unterschieden. Das kryptografische Löschen (cryptographic erase) ist bei Datenträgern, die nur verschlüsselt benutzt werden können, eine legitime Option. Beim kryptografischen Löschen wird der Schlüssel vernichtet, sodass die Daten nicht mehr entschlüsselt werden können. Aktuelle iPhones und iPads unterstützen kryptografisches Löschen.

Die britische Zeitung »The Guardian« berichtet ausführlich über die Zerstörung einiger Macbook Air's, auf denen Material von Edward Snowdon verarbeitet wurde, unter Aufsicht der britischen Sicherheitsbehörde GCHQ. Neben den Festplatten wurden auch alle Computerchips, in denen Informationen gespeichert werden können, mit einer Bohrmaschine zerstört. Dazu zählten der Trackpad-Controller, der Stromversorgungs-Controller, Tastaturen, CPUs, Wechselrichter und andere. Bitte vergessen Sie beim Löschen auch nicht Papier und Mikrofilme! Auch hier gibt es in den Standards detaillierte Vorgaben zu Partikelgrößen beim Schreddern in Abhängigkeit von der Vertraulichkeit der Daten. In Deutschland beschäftigt sich die DIN 66399 mit den Verfahren zur Zerstörung von Datenträgern. In Abhängigkeit vom Vertraulichkeitsgrad wird festgelegt, wie die Zerstörung zu erfolgen hat. Bei Papier ist zum Beispiel die Größe der Papierschnipsel nach dem Schreddern definiert.

Verfügbarkeit und Belastbarkeit Daten müssen verfügbar sein, wenn sie benötigt werden. Bei der Verfügbarkeit spielen neben den Störungen durch Angriffe und vorsätzliches Handeln auch Störungen durch Katastrophen und Unfälle sowie Ausfälle eine Rolle. Im Deutschen kennen wir nur den Begriff »Sicherheit«. Im Englischen wird zwischen »security«, das heißt Schutz vor »beabsichtigten Störungen« oder Angriffen und »safety«, das heißt Schutz vor »unbeabsichtigten Störungen« oder Unfällen unterschieden. In der IT-Sicherheit darf die »Safety« nicht vergessen werden.

Verfügbarkeitskontrolle und Informationssicherheitsaspekte beim Business Continuity Management … zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust geschützt sind (Nr. 7 Anlage zu § 9 BDSG a. F.) und dass Systeme, Dienste und Netze genutzt werden können, wenn sie benötigt werden Die Definition der Verfügbarkeitskontrolle im BDSG a. F. greift zu kurz, da sie nur auf die Verfügbarkeit der personenbezogenen Daten abstellt. Sie müssen aber auch sicherstellen, dass die Systeme, Dienste und Netze funktionsfähig sind und bleiben. Da IT-technische Systeme Strom benötigen, ist die Sicherstellung der Stromversorgung enorm wichtig. Gerade im medizinischen Bereich ist Verfügbarkeit wichtig, auch wenn keine personenbezogene Daten auf dem System verarbeitet werden. Der Ausfall eines Beatmungsgeräts beeinträchtigt den Menschen, der beatmet wird, erheblich. Für kurzfristige Stromausfälle sind Batteriespeicher geeignet und daher häufig als unterbrechungsfreie Stromversorgung (USV) im Einsatz. Bei längeren Stromausfällen sorgen sie für die Extrazeit zum geordneten Herunterfahren der Rechner. Sobald die Batterien leer sind, hilft eine USV nicht mehr. Im Small-Office-/Homeoffice-Bereich hat eine USV als Zusatzfunktion oft auch noch einen Überspannungsschutz eingebaut. Wenn eine längerfristige Stromversorgung aufrechterhalten werden muss, hilft nur ein Dieselaggregat, das einen Generator zur Stromerzeugung antreibt. Ein Problem, das bleibt, ist die Sicherstellung des Dieselnachschubs. Ein solches Notstromaggregat muss darüber hinaus regelmäßig getestet werden, damit es im Falle des Falles auch sicher anspringt.

Eine gängige Möglichkeit, um die Ausfallsicherheit von Systemen zu gewährleisten, ist Redundanz (siehe auch Kapitel 20). Alle kritischen Systeme und Komponenten sollten redundant ausgelegt werden. Fällt eine Komponente aus, kann die andere Komponente – gegebenenfalls mit weniger Leistung – die Funktion sicherstellen. Wenn die Systeme sich über eine spezielle Verbindung (Heart Beat genannt) gegenseitig über den Betriebszustand informieren, sodass bei einem Ausfall eines Geräts die anderen die Aufgabe mitübernehmen können, sprechen wir von einem automatischen Fail-over. Sie betreiben im Unternehmen Ihre Web-Angebote auf zwei Webservern, die sich die Arbeit teilen. Sie sind über eine spezielle Heart-Beat-Verbindung gekoppelt, um sich gegenseitig zu überwachen. Sobald einer der beiden Server ausfällt, bemerkt der »überlebende« Server dies an der ausbleibenden Antwort auf seine Heart-Beat-Anfrage. Es erfolgt eine automatische Konfigurationsanpassung, sodass der »überlebende« Server die Arbeit allein leistet. Häufig bestehen Anwendungen nicht nur aus zwei Servern, sondern aus mehreren. Wir sprechen dann von einem Cluster. Auch hier ist eine Überwachung per automatischem Heart Beat möglich, wenn auch in der Realisierung komplexer. Eine einfache Form von Redundanz wäre das Vorhalten von Ersatzgeräten. Im einfachsten Fall (Cold Standby) legen wir das fertig konfigurierte Gerät in den Schrank. Es wird bei Bedarf ans Netz und an den Strom angeschlossen und gestartet. Ein Schritt weiter geht der Hot Standby. Das Gerät ist an den Strom angeschlossen und eingeschaltet, nicht aber ans Netz angeschlossen. Im Falle eines Ausfalls wird es an Netz angeschlossen und in Betrieb genommen. Beide Lösungen sind nicht wirklich wirtschaftlich, da durch die Beschaffung der Geräte Kapital gebunden wird. Wenn die Geräte beschafft sind, sollten sie auch betrieben werden.

Um die Verfügbarkeit zu gewährleisten, ist die Überwachung von Temperatur, Feuchtigkeit und so weiter erforderlich. So können Sie bereits frühzeitig reagieren. Es dürfte Ihnen klar sein, dass auch eine angemessene Klimatisierung für Rechnerräume erforderlich ist. ITGeräte wandeln einen Großteil der elektrischen Energie in Wärme um, die dann abgeführt werden muss. Und zur Sicherstellung der Verfügbarkeit gehört natürlich auch ein gutes Backupkonzept (siehe Kapitel 20). Wichtig ist, dass Sie mindestens ein Backup außerhalb des »Schuttkegels« aufbewahren. In einem kleineren Unternehmen können Sie zum Beispiel ein Backup in einem Bankschließfach (oder einem vergleichbar sicheren Ort) aufbewahren. Wenn Ihr Unternehmen über mehrere Standorte verfügt, können Sie jeweis ein Backup an einem der anderen Standorte aufbewahren.

Auftragskontrolle, Lieferantenbeziehungen … zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können (Nr. 6 Anlage zu § 9 BDSG a. F.) Neben den rechtlichen Vorgaben zur Datenverarbeitung im Auftrag nach der DS-GVO spielen auch Vorfälle mit der Lieferkette eine Rolle. Wenn die Integrität der Lieferkette nicht gewährleistet werden kann, haben Sie ein Problem. Der Inhalt eines Vertrags zur Auftragsverarbeitung ist in Art. 28 DSGVO detailliert vorgegeben. In Abs. 3 Lit. c ist die Vorgabe, dass der Vertrag den Auftragsverarbeiter verpflichten muss, »alle gemäß Artikel 32 erforderlichen Maßnahmen« zu ergreifen. Die datenschutzrechtliche Verantwortung dafür liegt beim Auftraggeber. Alle technischorganisatorischen Konzepte, die wir in diesem Kapitel besprechen, müssen auch in einem Vertrag zur Auftragsverarbeitung enthalten sein.

Diese Vorgabe gilt für alle Dienstleistungen, bei denen personenbezogene Daten betroffen sind. Sie dürfen das Löschen und Vernichten von personenbezogenen Daten durch Dienstleister nicht vergessen. Manchmal hören wir von Auftragnehmern, dass ein Vertrag zur Auftragsverarbeitung nicht erforderlich sei, da der Auftragnehmer datenschutzkonform arbeite. Diese Auffassung ist falsch. Würde der Auftragnehmer nicht datenschutzkonform arbeiten, dürften Sie ihn gar nicht beauftragen. Ein heikles Thema sind Unterauftragnehmer, also diejenigen Dienstleister, die Ihr Auftragsverarbeiter seinerseits als Subunternehmer beschäftigt. Sie benötigen als Auftraggeber bei Vertragsabschluss eine vollständige Liste der Subunternehmer. Einen Wechsel eines Subunternehmers müssen Sie vorab genehmigen (Art. 28 Abs. 2 DSGVO). Sie haben alle die Diskussion 2019/2020 in den Medien mitbekommen, inwieweit bestimmte ausländische Hersteller von der Lieferung bestimmter Komponenten ausgeschlossen werden dürfen. Das ist grundsätzlich eine legitime Diskussion, die Sie unter Umständen auch in Ihrem Unternehmen führen müssen. Politisch führte die Diskussion zur Schaffung des § 9b BSI-Gesetz (Lex Huawei). Solange Sie kein Betreiber kritischer Infrastruktur sind, sind Sie davon nicht betroffen. Grundsätzlich sollten Sie bei außereuropäischen Dienstleistern und Lieferanten prüfen, ob deren Dienste gesetzeskonform und ohne Gefährdung Ihrer Sicherheit genutzt werden können. Das gilt nicht nur für Hardware-, sondern auch für Softwarelieferanten und Dienstleister. In einem Vertrag zur Auftragsverarbeitung müssen Sie auch regeln, in welcher Form (schriftlich, textlich, mündlich) und von wem (namentliche Nennung von Beschäftigten) Weisungen gegeben werden dürfen. Dabei müssen Sie inhaltlich differenzieren: Die

Gehaltszahlungen dürfen nur von Beschäftigten der Personalabteilung freigegeben werden und eine Änderung an der Konfiguration einer Hard- oder Software nur von der IT-Abteilung. Sie sind in der Wahl der Form frei. Deshalb bietet es sich hier an, auf Effizienz zu setzen und zum Beispiel elektronisch signierte E-Mails als Form zu vereinbaren. Dabei sind einfache oder fortgeschrittene elektronische Signaturen gemäß eIDAS-Verordnung (siehe Kapitel 6) eine gute Wahl. Im BDSG a. F. wurde verlangt, dass der Auftraggeber »vor Beginn der Datenverarbeitung und sodann regelmäßig« beim Auftragsverarbeiter die Einhaltung der TOM kontrolliert und das Ergebnis dokumentiert. Diese Regel sah den Auftraggeber in der Verantwortung. Art. 28 Abs. 1 Lit. h. sieht die Verantwortung beim Auftragnehmer. Er muss »alle erforderlichen Informationen zum Nachweis der Einhaltung … Pflichten zur Verfügung« stellen und Überprüfungen dulden. Der Auftragnehmer kann also übliche Zertifizierungen nach üblichen Standards (siehe Kapitel 8 bis 9) vorlegen. Sie können sich je nach Situation mit den Nachweisen zufrieden geben. Sind die Nachweise allerdings unvollständig oder widersprüchlich, dann müssen sie aktiv werden. [SJTH20]

Überprüfung, Bewertung und Evaluierung der Wirksamkeit der TOM … ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung (Art. 32 Abs. 1 Lit. d DS-GV) Eine Überprüfung der korrekten und sinnvollen Konfiguration von Rechnern und Servern erfolgt mittels entsprechender Software, wie

Netzwerkscanner, Schwachstellenscanner und dergleichen. Die schriftlichen Konfigurationsvorgaben werden in eine maschinenlesbare Form »übersetzt«, die dann zur Steuerung der Prüfprogramme dient. Die Überprüfung erfolgt dann erstmalig im Rahmen der Freigabe eines neuen Servers oder PCs und danach regelmäßig. Prüfprogramme überprüfen, ob die vorgegebene Konfiguration gemäß der Unternehmensstandards auch erfolgt ist. Wenn die Vorgabe im Unternehmen ist, dass Webseiten nur über https-Verbindungen verschlüsselt angeboten werden und nur die Protokollvarianten TLS 1.2 und TLS 1.3 angeboten werden, so kann dies einfach automatisch überprüft werden. Das Prüfprotokoll ist dann auch gleichzeitig Teil der Datenschutzdokumentation. Ein einfacher Einstieg ist der Cloud-Dienst SSL Labs (https://www.ssllabs.com/ssltest, siehe Abbildung 10.3). Eine Prüfung eines öffentlichen Webservers ist durch die Eingabe des Domain-Namens schnell erfolgt, die Ergebnisseite dokumentiert die Qualität der Konfiguration. In der Auswertung des Reports von SSL Labs ist die Anzeige, ab welcher Browser-Version die Seite angezeigt wird, sehr hilfreich. Mit einem Netzwerkscanner wie nmap ist es grundsätzlich möglich, eine Bestandsaufnahme im Netz zu machen. Hierbei werden alle IPAdressen, auf denen ein Rechner antwortet, identifiziert und Sie erkennen auch die auf den jeweiligen Rechnern laufenden Dienste. Ein solcher Netzwerkscanner ist eine einfache Möglichkeit, eine Inventur im eigenen Netz zu machen. Prinzipiell liefert nmap auch Informationen über die Versionen der gefundenen Software. Ob diese Software veraltet ist oder gar Sicherheitslücken hat, muss man dann aber selbst herausfinden. Der Mehrwert eines guten Schwachstellenscanners ist es, dass er einem diese Arbeit abnimmt. Dazu enthält ein Schwachstellenscanner eine umfangreiche Datenbank nahezu aller bekannten Schwachstellen. Schwachstellenscanner wie Nessus, Greenbone (siehe Abbildung 10.4), OpenVAS, Qualyss oder andere versuchen auch, aus dem Netz die

angebotenen Netzwerkdienste zu erkennen und sowohl das Betriebssystem als auch die genauen Softwareversionen zu bestimmen. Danach gleichen sie diese Versionen mit einer Datenbank ab, in der für jede Softwareversion die vorhandenen Schwachstellen aufgelistet sind. Da jeden Tag neue Schwachstellen gefunden werden, muss die Schwachstellendatenbank auch – wie die Signaturdatenbank eines Virenscanners – nahezu täglich aktualisiert werden.

Abbildung 10.3: Die Konfiguration der Verschlüsselung eines Webservers wird bei SSL Labs mit amerikanischen Schulnoten bewertet. »A+« ist dabei die beste Note.

Abbildung 10.4: Der Greenbone-Schwachstellenscanner bewertet die gefundenen Schwachstellen nach dem »Common Vulnerability Scoring System« (CVSS) auf einer Skala von 0 bis 10.

Die Datenbank »Common Vulnerabilities and Exposures« (CVE) ist ein De-facto-Industriestandard, der eine vereinheitlichte Beschreibung aller bekannten Schwachstellen bietet. Ein Schwachstellenscanner gleicht im Wesentlichen die Versionen der auf einem Rechner gefundene Software mit den zu dieser Version bekannten Schwachstellen in dieser Datenbank ab. Darüber hinaus kennt ein Schwachstellenscanner noch andere typische Sicherheitslücken. Hierzu gehören zum Beispiel Default-Passwörter, schwache kryptografische Schlüssel und schlecht konfigurierte Verschlüsselungsverfahren. Wird beim Scannen zum Beispiel ein Raspberry Pi gefunden, wird eine Anmeldung mit der Default-PasswortKombination pi/raspberry als Benutzername/Passwort versucht. Ist diese Anmeldung erfolgreich, wird die Sicherheitslücke angezeigt. Falls nötig, versucht sich ein Schwachstellenscanner auch mit definierten Benutzername-Passwort-Kombinationen an einem Dienst anzumelden, um aus der Fehlermeldung auf die Softwareversion zu schließen. Bei allen gefundenen Sicherheitslücken wird die Schwere auf einer Skala von 0 bis 10 bewertet. Hinter dieser Bewertung steckt das

»Common Vulnerability Scoring System« (CVSS), eine Standardmetrik zur Bewertung der Auswirkungen von Sicherheitslücken. Ein Schwachstellenscanner behebt keine Sicherheitslücken, sondern liefert nur eine Liste der Schwachstellen, die dann typischerweise von der IT-Abteilung zu beheben sind. Den Erfolg dieser Maßnahmen können Sie dann durch einen weiteren Scan überprüfen und dokumentieren. Ein Einstieg in das Schwachstellenscannen wäre eine Überprüfung aller aus dem Internet erreichbaren Dienste des Unternehmens. Hierzu gehören mindestens die diversen Webseiten, die E-Mail-Dienste, der VPN-Zugang und weitere erforderliche Dienste Ihrer Organisation. Letztendlich trägt ein regelmäßiges (zum Beispiel wöchentlich) Schwachstellenscannen zur Erfüllung Ihrer Pflicht zur Einrichtung eines Verfahrens »zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung« nach Art. 32 DS-GVO. Erheblich weiter als ein Schwachstellenscan geht ein Penetrationstest (Pentest). Hierbei beauftragen Sie eine Person oder ein Team, mit den Methoden eines Angreifers in das eigene Unternehmen einzubrechen. Ohne Ihren Auftrag würde sich der Pentester strafbar machen. Er hat also schon aus Gründen des Selbstschutzes ein großes Interesse an einem ordentlichen Vertrag. Für das Unternehmen ist es wichtig, dass die vereinbarten Vorgaben des Pentests genau festgehalten werden. Sie wollen feststellen, wie weit ein echter Angreifer ins Unternehmen eindringen könnte. Sie wollen aber nicht, dass der Pentester dabei Zugriff auf Ihre Geschäftsgeheimnisse erhält. Diese Grenzen müssen Sie so genau wie möglich im Vertrag mit dem Pentester regeln. Bei manchen Unternehmen gehört ein Pentest zum Standartrepertoire der Überprüfungsmethoden der Informationssicherheit. Bitte glauben Sie nicht, dass Sie einen Pentest selber durchführen können. Da Sie Ihre eigenen Informationssicherheitsprozesse und Konfigurationen

(hoffentlich!) sehr genau kennen, können Sie einen Pentest nicht unvoreingenommen durchführen.

Teil III

Organisation der Informationssicherheit

IN DIESEM TEIL … In diesem Teil beschäftigen wir uns damit, wie die Informationssicherheit im Unternehmen zu organisieren ist. Wer ist verantwortlich für die Initiierung des Informationssicherheitsprozesses? Welche Rollen sind in dem Prozess relevant? Wir werden sehen, dass Informationssicherheit ein kontinuierlicher Prozess der ständigen Verbesserung ist. Sie können sich zu keinem Zeitpunkt auf dem Erreichten ausruhen. Von der Risikoanalyse bis zur Meldepflicht müssen alle Prozesse und Ereignisse dokumentiert werden. Unter Umständen führt ein Vorfall sogar zur vorgeschriebenen Meldung an eine Behörde. Zu guter Letzt werden wir uns mit der Frage beschäftigen, wie man den Beschäftigten Informationssicherheit nahebringt und sie in den Informationssicherheitsprozess einzubinden.

Kapitel 11

Organisation im Unternehmen IN DIESEM KAPITEL Verantwortung im Unternehmen Organisationseinheiten der Informationssicherheit

Unternehmen müssen Informationssicherheit als wesentlichen Aspekt Ihrer Prozessqualität begreifen. Dies ist ihnen nicht nur rechtlich (DSGVO, IT-Sicherheitsgesetzgebung) vorgegeben, sondern es ist auch eine unternehmerische Gestaltungsaufgabe im Rahmen der GovernanceStrukturen. Ohne Informationssicherheit ist weder eine hochwertige Produktion noch eine verlässliche Verwaltung oder Dienstleistung auf Dauer möglich.

Verantwortung für die Informationssicherheit Die Verantwortung der Unternehmensleitung für die Informationssicherheit im Unternehmen bedeutet vor allem, funktionierende Strukturen für Planung, Umsetzung, Überprüfung und Verbesserung der Informationssicherheit herzustellen – international bekannt als Plan, Do, Check, Act, kurz PDCA oder Deming-Kreis. In diesen Prozessstrukturen müssen die Fachabteilungen und die Betreiber der informationstechnischen Infrastruktur zusammenwirken. Ebenso müssen auch die Beziehungen zu und zwischen Datenschutz, ITSicherheit, IT-Abteilung, Rechtsabteilung, Unternehmenskommunikation und Vorfallsmeldestrukturen geregelt sein. Für die Erreichung des angestrebten Sicherheitsniveaus im

Unternehmen müssen ausreichende personelle und finanzielle Ressourcen zur Verfügung stehen.

Organisatorische Strukturen Die unterschiedlichen Rollen im Unternehmen, zum Beispiel Geschäftsleitung, Informationssicherheitsbeauftragter oder IT-Leitung haben unterschiedliche Verantwortung bei der Umsetzung der Informationssicherheit. Betrachten wir im Folgenden die einzelnen Rollen.

Geschäftsleitung Im Kontext der IT-Governance sind Regelungen zum Informationssicherheitsrisiko- sowie InformationssicherheitsManagementsystem (ISMS) erforderlich. IT-Governance umfasst dabei die Führung und die organisatorischen Strukturen und Prozesse, welche sicherstellen, dass die unternehmerischen Ziele durch den IT-Einsatz unterstützt und vorangetrieben werden. IT-Governance ist eine strategische Aufgabe der Leitung des Unternehmens und sie muss die Informationssicherheits-Leitlinie sowie Richtlinien, Kriterien und Standards zur Entscheidungsfindung, Überwachung, Messung, Weiterentwicklung und Verbesserung der Leistung der IT und insbesondere auch für das Informationssicherheitsrisiko- sowie Informationssicherheits-Management vorgeben.

Chief Information Officer/Chief Digital Officer Der Chief Information Officer (CIO) – beziehungsweise als Gestalter der Veränderungen der Digitalisierung der Chief Digial Officer (CDO) – nimmt in einem Unternehmen die strategische Leitung der IT wahr. Er ist für die IT-Planung (»Business and IT-Vision«) und die Auswahl geeigneter Technologien (»Design of IT-Architecture«) verantwortlich. Der CIO/CDO ist für das Innovation Management in der IT verantwortlich und berät das Unternehmen in strategischen IT-Fragen. Häufig ist der CIO/CDO Mitglied der Unternehmensleitung. [CIO]

Der CIO/CDO vertritt auch die strategischen IT-Belange des Unternehmens nach außen, etwa in strategischen Arbeitskreisen, die sowohl regional als auch branchenspezifisch häufig zu finden sind. Die Rolle des CIO/CDO gibt es formal in vielen Unternehmen und Behörden nicht. Seine Aufgaben werden bis zu einem gewissen Punkt vom jeweiligen IT-Leiter wahrgenommen. Die Gestaltung der strategischen IT-Sicherheit in einem Unternehmen kann nur in einem intensiven Austausch mit der Gestaltung der ITStrategie und damit mit dem CIO/CDO stattfinden. Dieser Austausch setzt damit entsprechende Strukturen zur IT-Strategie voraus.

Informationssicherheitsbeauftragter Der Informationssicherheitsbeauftragte (Chief Information Security Officer, CISO) unterstützt und koordiniert die Organe und die Einrichtungen des Unternehmens bei der Erfüllung ihrer Aufgaben im Bereich der Informationssicherheit. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gibt im BSI-Standard 200-2 zur Aufgabenbeschreibung des CISO Folgendes vor: Steuerung und Koordinierung des Informationssicherheitsprozesses, Unterstützung der Leitungsebene bei der Erstellung der Leitlinie zur Informationssicherheit, Erstellung des IT-Sicherheitskonzepts, des Notfallvorsorgekonzepts und anderer Teilkonzepte; Koordinierung der Erstellung der SystemSicherheitsrichtlinien sowie Erlass weiterer Richtlinien und Regelungen zur Informationssicherheit, Erstellung des Realisierungplans für die IT-Sicherheitsmaßnahmen und Überprüfung der Realisierung, Berichterstattung an die Leitungsebene und das IS-ManagementTeam über den Status quo der Informationssicherheit, Koordinierung IT-sicherheitsrelevanter Projekte und Sicherstellung des Informationsflusses zwischen Bereichs-IT-, Projekt- sowie ITSystem-Sicherheitsbeauftragten,

Untersuchung IT-sicherheitsrelevanter Zwischenfälle, Initiierung von Sensibilisierungs- und Schulungsmaßnahmen zur Informationssicherheit. Ein Unternehmen sollte heute keinen IT-Sicherheitsbeauftragten bestellen, sondern einen Informationssicherheitsbeauftragten. Dies entspricht der neuen Sprachregelung im IT-Grundschutz und der ISO 270xx-Reihe, die den sprachlichen und inhaltlichen Schwenk von der ITSicherheit zur Informationssicherheit vollzogen haben. Auch der Informationssicherheitsbeauftragte vertritt das Unternehmen zum Beispiel in regionalen oder branchenspezifischen Arbeitskreisen. Ganz wesentlich unterstützt und berät der Informationssicherheitsbeauftragte auch die Datenschutzbeauftragte des Unternehmens in Fragen des technischen Datenschutzes. Im Gegensatz zur Datenschutzbeauftragten (Art. 37 DS-GVO i. V. m. § 28 Abs. 1 BDSG) ist der Informationssicherheitsbeauftragte in Deutschland nicht gesetzlich vorgeschrieben. Die einzige Ausnahme ist der § 166 Abs. 1 TKG, der die Ernennung eines »Sicherheitsbeauftragten« (gemeint ist wohl ein ITSicherheitsbeauftragter) vorschreibt, wenn das Unternehmen »ein öffentliches Telekommunikationsnetz betreibt oder öffentlich zugängliche Telekommunikationsdienste erbringt«. Die in § 8b Abs. 3 BSI-Gesetz vorgeschriebene »Kontaktstelle« ist keine Vorgabe zur Bestellung eines Informationssicherheitsbeauftragten. Gleichwohl wird ein vorhandener Informationssicherheitsbeauftragter sinnvollerweise die Aufgaben der Kontaktstelle wahrnehmen.

IT-Leitung Der IT-Leiter nimmt im Unternehmen die operative Leitung der IT wahr. Er ist verantwortlich für den IT-Betrieb (»Delivery of IT-Services«). Folglich zählen zur Rolle der IT-Leitung in erster Linie operative Funktionen, die den reibungslosen Betrieb der unternehmensinternen ITSysteme sicherstellen.

Die IT-Strukturen zur Steuerung der Produktionsprozesse und die Verwaltungs- beziehungsweise Rechenzentrums-IT-Strukturen stehen häufig mehr oder weniger unkorreliert nebeneinander. Dies ist auf Dauer nicht sinnvoll, da zentrale Systeme wie zum Beispiel das Identitätsmanagement übergreifend organisiert werden müssen. Auch in Unternehmen muss das Once-Only-Prinzip bei der Speicherung von Daten umgesetzt werden. Relevante Informationen werden nur einmal gespeichert und jeder Abteilung, die sie benötigt, zur Verfügung gestellt. Um konsensfähige Strukturen aufzubauen, muss hier eine gegenseitige Einbindung der unterschiedlichen Verantwortlichen erfolgen.

Computer Emergency Response Team (CERT) Im Englischen und in den europäischen Regularien wird auch häufig von einem »Computer Security Incident Response Team« (CSIRT) gesprochen. Ein CERT hat in der IT-Sicherheit ähnliche Aufgaben wie die Feuerwehr beim Brandschutz. Eine wesentliche Aufgabe ist die Unterstützung (reaktive Komponente) bei einem konkreten IT-Sicherheitsvorfall. Dazu gehört die Schadensbegrenzung durch Abwehr des Angreifers und die forensische Untersuchung der betroffenen IT-Komponenten. Ziel ist es akut den Vorfall zu begrenzen und danach genau zu verstehen, was passiert ist und wie es dazu kommen konnte. Im Einzelnen sind die Aufgaben eines CERT (nach Art. 10 Abs. 2 Entwurf NIS-2-Richtlinie): Überwachung und Beobachtung von Cyberbedrohungen, schwachstellen und -vorfällen, Bereitstellung von Frühwarnungen, Warnungen und Ankündigungen sowie die Verbreitung von Informationen über Cyberbedrohungen, schwachstellen und -vorfällen an wesentliche und wichtige Stellen im Zuständigkeitsbereich, Reaktion auf Vorfälle im Rahmen der Zuständigkeit, Bereitstellung einer dynamischen Risiko- und Vorfallsanalyse und eines Situationsbewusstseins in Bezug auf Informationssicherheit,

proaktive Überprüfung des Netzes – nach formaler Beauftragung durch eine Stelle innerhalb der Zuständigkeit – und der Informationssysteme, die für die Erbringung ihrer Dienste genutzt werden, Teilnahme an CERT-Netzwerken und gegenseitige Unterstützung der anderen Mitglieder des Netzwerks auf deren Bitte um Unterstützung. Durch die Bearbeitung entsteht im CERT umfangreiches Wissen über Sicherheitsvorfälle. Hieraus lassen sich Empfehlungen und vorbeugende Maßnahmen (präventive Komponente) herleiten, die mittelfristig das Sicherheitsniveau erhöhen. In Deutschland gibt es knapp 30 CERTs, die im deutschen CERTVerbund (https://www.cert-verbund.de) kooperieren. Eine übergeordnete Rolle hat das CERT-Bund beim BSI. Das älteste CERT in Deutschland ist das DFN-CERT beim Deutschen Forschungsnetz, das die Hochschul- und Wissenschaftslandschaft unterstützt. Darüber hinaus gibt es auf Landesebene (zum Beispiel in Baden-Württemberg, Bayern oder Niedersachsen) und bei Unternehmen (zum Beispiel BMW, Lufthansa, Siemens, Sparkassen-Finanzgruppe, Telekom, Volkswagen) eigene CERTs. Es gibt auch darauf spezialisierte Unternehmen, die CERT-Dienstleistungen für Dritte anbieten. International arbeiten CERTs im »Forum of Incident Response and Security Teams« (FIRST) zusammen. Das erste CERT war das CERT/CC; es wurde 1988 als Reaktion auf den Morris-Computerwurm an der Carnegie Mellon University, Pittsburgh (USA) gegründet. Das Israel National Cyber Directorate hat das Israeli Cyber Emergency Response Team eingerichtet, das jeder Bürger und jedes Unternehmen in Israel unter der Telefonnummer 119 um Hilfe bei IT-Sicherheitsvorfällen bitten kann. In Deutschland gibt es in Baden-Württemberg mit der Cyberwehr BW (https://cyberwehr-bw.de) ein Konzept, um über eine Notfall-Hotline eine Anlaufstelle für kleine und mittelständige Unternehmen bei ITSicherheitsvorfällen zu schaffen.

Das BSI betreibt ein Informationsangebot für Verbraucherinnen und Verbraucher (früher »BSI für Bürger«) mit umfangreichen Informationsangeboten zur IT-Sicherheit. Der »Bürger-CERTNewsletter« erscheint alle 14 Tage und kann dort abonniert werden. Sie finden dort aber auch Checklisten, Hinweise zum Umgang mit Sicherheitsvorfällen und vieles andere mehr. (https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-undVerbraucher/verbraucherinnen-und-verbraucher_node.html) Große Unternehmen oder Konzerne haben tendenziell ein eigenes CERT. Kleine und mittelständische Unternehmen fahren mit branchenspezifischen CERT-Organisationen oder entsprechenden Dienstleistern besser. Wichtig ist, dass die Strukturen existieren und nicht erst bei einem Vorfall ins Leben gerufen werden.

Informationssicherheitsausschuss Um die Aufgaben der Informationssicherheit im Konsens aller Beteiligten zu gestalten, sollte ein Informationssicherheitsausschuss eingerichtet werden. Wie Sie ihn konkret nennen, spielt dabei keine große Rolle. Zu den Aufgaben dieses Ausschusses gehört es, möglichst alle Beteiligten (Stakeholder) ins Boot zu holen und einen breiten Konsens anzustreben. In dem Ausschuss sollten mindestens vertreten sein: Informationssicherheitsbeauftragter, Chief Information Officer/Chief Digitalisation Officer, IT-Leitung. Datenschutzbeauftragte, Vertreter der Anwender. Richtlinien zur Informationssicherheit werden von diesem Ausschuss beschlossen und haben damit eine breitere Legitimation und Akzeptanz, als wenn der Informationssicherheitsbeauftragte sie allein in Kraft setzt.

Richtlinien und Regeln Es empfiehlt sich, in internen Regelungen eine klare Sprachdefinition zu haben, damit es nicht zu Missverständnissen kommt. Nicht umsonst wird in vielen Standards jeweils zu Beginn das Vokabular definiert. So findet sich am Anfang der seit Jahrzehnten üblichen RFC-Dokumente (in denen die Standards des Internets definiert sind) häufig die Formulierung »The key words ›MUST‹, ›MUST NOT‹, ›REQUIRED‹, ›SHALL‹, ›SHALL NOT‹, ›SHOULD‹, ›SHOULD NOT‹, ›RECOMMENDED‹, ›MAY‹, and ›OPTIONAL‹ in this document are to be interpreted as described in RFC 2119«. Im Text werden diese Worte dann auch in Großbuchstaben geschrieben, um den Formalismus deutlich zu machen. Im Unternehmen müssen Sie einiges an Regelungen erstellen. Die wichtigste Regel ist eine Informationssicherheitsleitlinie, die in allen Standards gefordert wird. Darin legen Sie die grundlegenden Anforderungen und Ziele der Informationssicherheit im Unternehmen fest. Die Verantwortung für das Erstellen dieser Leitlinie liegt bei der Geschäftsleitung. Die Leitlinie muss im Unternehmen allen Beschäftigten bekannt gegeben werden. Es bietet sich an, die wichtigsten Rollen in Bezug auf die Informationssicherheit im Unternehmen in dieser Leitlinie zu definieren. Insbesondere sollten Sie die Rolle des Informationssicherheitsbeauftragten hier festlegen, da diese wichtige Rolle im Gegensatz zur Datenschutzbeauftragten nicht gesetzlich vorgeschrieben ist. Dazu reichen drei Sätze: »Der Informationssicherheitsbeauftragte des Unternehmens wird von der Geschäftsleitung bestellt und berichtet direkt an diese. Er ist Mitglied des Informationssicherheitsausschusses und unterstützt die Einheiten des Unternehmens bei der Erfüllung ihrer Aufgaben im Bereich der Informationssicherheit. Ihm werden die erforderlichen Befugnisse und Ressourcen zur Verfügung gestellt.« Sie sollten in der Leitlinie aber auch die Rolle einer Nutzerin definieren. »Jede Nutzerin der Informations- und Kommunikationstechnik im

Unternehmen ist für die Sicherheit und den Schutz der Daten in ihrem Verantwortungsbereich verantwortlich. Sie ist verpflichtet, bei der Erfüllung der Aufgabe ›Informationssicherheit‹ kooperativ und verantwortungsbewusst mitzuwirken.« Neben dieser Leitlinie müssen Sie auch eine oberste Richtlinie zur Informationssicherheit in Kraft setzen. In dieser werden (mittlere Ebene in Abbildung 11.1) konkretere Vorgaben als in der Leitlinie gemacht. In der Leitlinie steht zum Beispiel nichts zum Thema Virenschutz. In der Richtlinie schreiben Sie dagegen beispielsweise vor: »Auf virengefährdeten Betriebssystemen muss eine Software zum Schutz vor Schadsoftware eingesetzt werden.« Was ein virengefährdetes Betriebssystem ist und welche Schutzsoftware in welcher Konfiguration eingesetzt wird, dass wird auf der untersten Ebene in einem »Schutzkonzept gegen Schadsoftware« geregelt. Die Abbildung 11.1 zeigt auch, dass die Zeitskalen (Änderungshäufigkeit) und der Detaillierungsgrad voneinander abhängen. Die Leitlinie auf der obersten Ebene ist so abstrakt, dass Sie fünf bis zehn Jahre unverändert bleiben kann. Trotzdem sollten Sie die Leitlinie regelmäßig auf Aktualisierungsbedarf prüfen. Die mittlere Ebene (Richtlinie) sollte etwa alle zwei bis vier Jahre angepasst werden. Die konkreten Vorgaben der untersten Ebene müssen je nach Bedarf – mindestens jährlich eventuell öfter – angefasst und aktualisiert werden.

Abbildung 11.1: Die Regelungspyramide, die die zeitlichen Änderungsskalen und die unterschiedlichen Detaillierungsgrade trennt. (nach BSI)

Zu den dringendsten Regelungen, die auf der untersten Ebene zu treffen sind, gehören: Organisation: Erstellen der Informationssicherheitsleitlinie, Bestellung des Informationssicherheitsbeauftragten und Schaffung der weiteren Strukturen, Erstellen eines Backupkonzepts, Konzept zur Klassifizierung der Daten und der Assets, physische Sicherheitsmaßnahmen, Konzept zur Netzwerksicherheit, Umgang mit Sicherheitsupdates (Patchmanagement), Nutzerordnung und Passwortregeln,

Virenschutzkonzept, Regeln zur Verschlüsselung. Die Erstellung dieser Dokumente erfolgt zentral unter der Leitung des Informationssicherheitsbeauftragten. Die Umsetzung erfolgt zum Teil durch die IT, zum Teil aber auch wesentlich durch die Fachabteilungen. Insbesondere die Klassifizierung der Daten kann nur durch die Fachabteilungen erfolgen, da nur diese um den Schutzbedarf ihrer Daten wissen.

Kapitel 12

Der Deming-Kreis (PDCA) und die ständige Verbesserung IN DIESEM KAPITEL PDCA: das Hamsterrad der IT-Sicherheit Der Prozess der ständigen Verbesserung

Qualitätsmanagement ist ein wichtiger Teil der Prozessteuerung bei der Leitung eines Unternehmens. Der amerikanische Physiker William Edwards Deming (1900–1993) gilt als der Vater einer prozessorientierten Betrachtungsweise der Aktivitäten in einem Unternehmen. Diese Sichtweise auf den Managementprozess bildet heute die Basis für viele Qualitätsmanagement-Normen und -Standards. Ausgehend von Konzepten seines Doktorvaters Walter Andrew Shewhart (1891–1967) entwickelte er den dreistufigen Shewhart-Zyklus (Spezifikation–Produktion–Kontrolle) zu dem heutigen Plan–Do– Check–Act-(PDCA-)Zyklus weiter. Die Idee, den Prozess als Kreis darzustellen, soll uns verdeutlichen, dass dieser Prozess kontinuierlich ist – wir dürfen uns niemals auf dem Erreichten ausruhen, sondern müssen uns stetig weiterentwickeln. [MN09] Abbildung 12.1 zeigt den Zyklus, wie ihn Deming 1951 als »Design– Produce–Sell–Research« vorstellte. Die heute gebräuchliche Bezeichnung der vier Phasen entstand in Japan. Deming war mit dem Begriff »Check« nicht einverstanden. Er wollte die Bezeichnung »Study« verwenden, da ihm der Begriff »Check« zu sehr mit »bremsen« oder »aufhalten« verbunden war. Sein Vorschlag, den Kreis in »PDSAZyklus« umzubenennen, hat sich aber nicht durchgesetzt. [MN09]

Die vier Phasen des PDCA-Zyklus sind hier jetzt etwas ausführlicher dargestellt: 1. Plan: Planung. Was wollen wir erreichen? Wie wollen wir das erreichen? 2. Do: Umsetzung. Das Geplante wird umgesetzt und getan. 3. Check: Überprüfung. Was hat es gebracht? Hat es funktioniert? Was ergibt der Soll-Ist-Vergleich? 4. Act: Verbesserung. Was können wir besser machen? Was haben wir aus den aufgetretenen Problemen gelernt? Danach folgt im Grunde eine fünfte Phase, die aber identisch ist mit der ersten Phase eines zweiten beziehungsweise des nächsten Durchlaufs. Sie müssen nun planen (umsetzen, prüfen, verbessern, planen, …), wie die Verbesserungen, die Sie in Phase 4 erarbeitet haben, umgesetzt werden.

Abbildung 12.1: Der Deming- oder PDCA-Zyklus als vierstufiger Prozess der ständigen Verbesserung.

Dieser iterative Prozess ist heute die Basis aller Qualitätsmanagementkonzepte, egal ob es sich um die Produktqualität, um Qualität im Umweltmanagement, die Qualität von Arbeitsabläufen oder eben Qualität in der Informationssicherheit handelt. In der ISO/IEC 27000 wird dieser Managementprozess »fortlaufende Verbesserung« (Continual Improvement) genannt. Der Prozess besteht in der Norm aus den Schritten

1. Identifizierung von Informationssicherheitsanforderungen und Beurteilung von Informationssicherheitsrisiken, 2. Behandlung von Informationssicherheitsrisiken sowie Auswahl und Umsetzung von Maßnahmen, 3. Überwachung und Aufrechterhaltung der Wirksamkeit des Informationssicherheitsmanagements (ISMS), 4. Verbesserung der Wirksamkeit des ISMS. Die klare einfache Struktur des PDCA-Zyklus macht es Ihnen im Unternehmen recht einfach, sich danach zu richten. Ob es sich um eine Pilotimplementierung eines neuen IT-Sicherheitsprozesses oder um das finale Rollout eines Prozesses handelt, Sie können sich immer an diesem Schema orientieren. Und wenn die erste Implementierung des Pilotprozesses noch nicht richtig funktioniert, stellen Sie dies in der Check-Phase fest und erarbeiten die erforderlichen Optimierungen in der Act-Phase. Die verbesserte Implementierung der Pilotimplementierung durchläuft dann wieder einen PDCA-Zyklus. Im Grunde agieren Sie häufig bereits nach dem Deming-Prozess, ohne es sich direkt bewusst zu machen. Sie stellen ein Problem fest und planen die Lösung (Plan). Sie bauen oder implementieren die Lösung (Do). Sie stellen im Betrieb fest, dass es noch nicht so läuft, wie Sie wollen (Check). Dann überlegen Sie sich, wie Sie es besser machen können (Act).

Kapitel 13

Risikoanalyse und Kronjuwelen IN DIESEM KAPITEL Kennen Sie Ihre Kronjuwelen? Kennen Sie Ihre Gefährdungen?

Im Rahmen eines Risikomanagements (siehe Kapitel 3) müssen nicht nur Gefährdungen untersucht werden, sondern auch die Sensibilität von Daten und Systemen. Es wird Daten geben, die völlig unkritisch sind, und andere, die Sie extrem schützen müssen. Diese bezeichnen wir im Allgemeinen als die »Kronjuwelen« des Unternehmens. Im Unternehmen müssen Sie wissen, welche Daten das sind. Im Folgenden wollen wir uns damit beschäftigen, wie Sie eine derartige Klassifizierung vornehmen.

Klassifizierung der Daten Eien Klassifizierung Ihrer Daten erfolgt bezüglich der klassischen Schutzziele der Informationssicherheit: Verfügbarkeit, Integrität und Vertraulichkeit. Verabschieden Sie sich von dem Gedanken, dass eine Datenart bezüglich aller drei Schutzziele den gleichen Schutzbedarf hat. Nehmen wir als Beispiel den Webauftritt Ihres Unternehmens. Sie präsentieren dort Ihr Unternehmen und Ihre Produkte, verkaufen dort aber nichts, also ist der Webauftritt ein reines Informationsangebot. Im Datenschutz (Art. 33 f. DS-GVO, Risikostufen bei der Vorfallsmeldung) und im IT-Grundschutz (BSI-Standard 200-1) werden drei Schutzstufen verwendet. Dann kommen Sie mit diesen drei Stufen des Schutzbedarfs (normal, hoch, sehr hoch) vielleicht zu der folgenden Klassifizierung:

Verfügbarkeit: hoch, da Sie allenfalls damit leben können, wenn der Webauftritt kurzzeitig nicht zur Verfügung steht. Integrität: sehr hoch, da Sie auf jeden Fall verhindern wollen, dass ein Unbefugter Ihren Webauftritt verunstaltet oder gar falsche oder rufschädigende Informationen präsentiert. Vertraulichkeit: normal, da Ihr Webauftritt von jedermann angeschaut werden soll. Nichts ist dort geheim. Eine derartige Klassifizierung nimmt weder der Informationssicherheitsbeauftragte noch die Datenschutzbeauftragte oder gar die IT-Abteilung vor. Zuständig für die Klassifizierung ist die zuständige Fachabteilung, in unserem Beispiel also die Unternehmenskommunikation. Der Informationssicherheitsbeauftragte, beziehungsweise die Datenschutzbeauftragte bei personenbezogenen Daten, stoßen den Prozess der Klassifizierung an und gestalten ihn. Sie »nerven« bei der Durchführung die Fachabteilungen, bis sie diese Klassifizierung tatsächlich durchführen. Im Sinne des PDCA-Zyklus (siehe Kapitel 12) und der ständigen Verbesserung von allem sollte regelmäßig, zum Beispiel alle zwei Jahre, ein Review der Klassifizierung erfolgen. Dabei geht es darum zu prüfen, ob die Klassifizierung noch aktuell ist. Sie müssen im Unternehmen festlegen, wie die Schutzbedarfskategorien in Ihrem Unternehmen definiert sind. In einem kleinen Unternehmen ist ein möglicher Schaden eines IT-Sicherheitsvorfalls von 50.000 € schon als »hoch« klassifiziert, in einem großen Unternehmen eher in die Kategorie »normal«(beziehungsweise Portokasse). Insofern müssen Sie ein Klassifizierungsformular erstellen, das von den Fachabteilungen auszufüllen ist. Ob Sie das Formular auf Papier oder als Onlineformular aufsetzen, bleibt Ihnen überlassen. Je größer und räumlich verteilter ein Unternehmen ist, umso wichtiger wird jedoch ein Onlineformular.

Dieses Formular muss eine Erläuterung der Bedeutung der Schutzbedarfskategorien enthalten, eine Beschreibung der Datenart und eine einfache Tabelle zum Ausfüllen. Sie sollten auch die Klassifizierung der Datenarten unter den Gesichtspunkten Informationssicherheit und Datenschutz jeweils separat erfassen. Es »gewinnt« immer die höhere der beiden Klassifizierungen. Dass Sie trotzdem beide Klassifizierungen und nicht nur die höhere der beiden erfassen, ist für die vollständige Dokumentation wichtig. Sie können so jederzeit belegen, dass Sie über beide Aspekte – Informationssicherheit und Datenschutz – nachgedacht haben.

Klassifizierung der Systeme Nicht nur die Daten, sondern auch die informationstechnischen Systeme, also Rechner, Anwendungen und auch Netze beziehungsweise Netzbereiche müssen klassifiziert werden. Auch hierbei kommen wieder die klassischen Schutzziele ins Spiel. In einer IT-gesteuerten Fertigung mit vernetzten Produktionsmaschinen besteht ein sehr hoher Schutzbedarf bezüglich Integrität und Verfügbarkeit. Bei fehlender Integrität werden unter Umständen fehlerhafte Produkte hergestellt und bei fehlender Verfügbarkeit steht die Produktion. Schwieriger ist es, den Schutzbedarf der Vertraulichkeit zu beurteilen. Wenn sich aus den für die Produktion benötigten Daten Geschäftsgeheimnisse ableiten lassen (zum Beispiel besonderes Knowhow für die Fertigung) oder wenn die Produktion personenbezogene Daten erfordert (zum Beispiel bei der Produktion individuell angefertigter medizinischer Hilfsmittel), ergibt sich auch bezüglich der Vertraulichkeit ein hoher bis sehr hoher Schutzbedarf.

Eine besondere Situation liegt in der medizinischen Versorgung vor. Vom Computertomografen über Röntgengeräte bis zu Beatmungsgeräten sind fast alle Geräte mit einem Netzwerkanschluss und entsprechender IT-basierter Steuerung ausgerüstet. Aufgrund der besonderen Situation haben Sie bezüglich aller drei Schutzziele einen sehr hohen Schutzbedarf. Gleichzeitig sind aber zahlreiche Geräte unbeaufsichtigt im Zugriff von Patienten und deren Besuchern. Auch das Netz ist bei Weitem nicht so abgeschottet, wie es sein sollte. Bezüglich der Sicherheitsausstattung sind viele medizinische Geräte nicht auf dem Stand der Technik. Dies hat einen besonderen Grund: medizinische Geräte (offiziell Medizinprodukte) benötigen eine spezielle Konformitätsprüfung (siehe dazu die europäische Verordnung 2017/745 über Medizinprodukte). Diese Zulassung beinhaltet auch die Software, die das Gerät steuert. Nach einer Änderung der Software ist eine erneute Konformitätsprüfung erforderlich. Da medizinische Geräte länger eingesetzt werden als die im normalen IT-Betrieb eingesetzten Softwareprodukte, ist die Software dann irgendwann veraltet. Vom Hersteller nicht explizit freigegebene Softwareupdates dürfen bei Medizingeräten nicht installiert werden. Sie finden im Unternehmen natürlich auch Software, Dienste und Netze, die in der Verantwortung der IT-Abteilung sind. Einige wichtige Beispiele sind: Backupsystem: für alle drei Schutzziele sehr hoher Schutzbedarf E-Mail-System: für alle drei Schutzziele sehr hoher Schutzbedarf Datenbankserver: für alle drei Schutzziele sehr hoher Schutzbedarf DNS-Server: für Verfügbarkeit und Integrität sehr hoher und für Vertraulichkeit hoher Schutzbedarf

Identitätsmanagement: für alle drei Schutzziele sehr hoher Schutzbedarf Firewallsystem: für alle drei Schutzziele sehr hoher Schutzbedarf Internetzugang: für Verfügbarkeit sehr hoher und für Integrität und Vertraulichkeit hoher Schutzbedarf Administrationsnetz: für Verfügbarkeit hoher und für Integrität und Vertraulichkeit sehr hoher Schutzbedarf Die hier aufgeführten Schutzbedarfseinstufungen sind Beispiele. Sie können in Ihrem Unternehmen auch zu anderen Ergebnissen kommen. Die Klassifizierung der Vertraulichkeit ergibt sich unmittelbar aus der Klassifizierung der Daten, die auf dem System verarbeitet werden. Ein besonderer Fall sind alle Protokolldateien sowie die Rechner, auf denen diese verarbeitet werden. Soweit Einträge in Protokolldateien personenbezogen sind, gilt ein sehr hoher Schutzbedarf für die Vertraulichkeit. Bezüglich Verfügbarkeit und Integrität gilt jedoch immer ein sehr hoher Schutzbedarf. Die Inhalte der Protokolldateien liefern wichtige Informationen zur Untersuchung von Vorfällen. Sie müssen sich deshalb darauf verlassen können, dass sie sich nicht verändert haben. Auch müssen die Protokolldateien sofort greifbar sein, wenn Sie diese benötigen. Je nach Vorfall brauchen Sie die Informationen sehr dringend. Wenn ein Angreifer die Verfügbarkeit Ihrer Protokollierung beeinflussen kann, kann er Sie blind machen. Mangels Verfügbarkeit der Protokollierung würden Sie seinen Angriff in den Protokolldateien nicht finden. Gleichzeitig müssen Sie auch die Integrität der Protokolldateien gewährleisten, damit ein Angreifer seine Spuren dort nicht entfernen kann. Auch Manipulationen der Protokolldateien durch Innentäter müssen verhindert werden.

Bedrohungsanalyse

Der große Vorteil des IT-Grundschutzes gegenüber der ISO/IEC 27000er Reihe und den anderen Normen ist die eingebaute Risikobetrachtung. Dazu hat das BSI eine Analyse möglicher Bedrohungen vorgenommen und eine Liste von 47 Gefährdungen erstellt (siehe Tabelle 8.1 in Kapitel 8). Damit müssen Sie nicht bei null anfangen. In einem ersten Schritt gehen Sie einfach diese Gefährdungen der Reihe nach durch. Die Gefährdungen sind relativ abstrakt formuliert und Sie müssen sie entsprechend von Ihrer konkreten Situation her denken. Die Gefährdung »G 0.14 Ausspähen von Informationen (Spionage)« zum Beispiel ist zu abstrakt. Sie überlegen bei der Analyse, ob in Ihrem Unternehmen Spionage ein Thema sein könnte. Einige Mittelständler, die sogenannten »Hidden Champions«, verfügen durchaus über Know-how, das ein weltweites Alleinstellungsmerkmal ist. Bei diesen Unternehmen ist Konkurrenzspionage, aber auch staatliche Spionage (im Rahmen der »Förderung« der heimischen Wirtschaft der angreifenden Länder) ein Thema. Als im Werk eines niederbayerischen Betonherstellers, der über spezielles Fertigungs-Know-how für Glasfaserbetonplatten verfügte, der Geschäftsführer eines potenziellen chinesischen Kunden herumgeführt wurde, fiel einem Beschäftigen der eigenartige Umgang des Gastes mit seiner Gürtelschnalle auf. Die herbeigerufene Polizei fand eine Kamera in der Gürtelschnalle. Der Hersteller war international bekannt geworden, weil er die Fassadenplatten für das WM-Stadion Soccer City in Johannesburg zur Fußball-Weltmeisterschaft 2010 geliefert hatte. [Sti18] Denken Sie bei Spionage nicht nur an High-Tech. Es wird auch im Bereich politischer und ökonomischer Forschung spioniert. Denn die Spezialisten auf diesen Gebieten beraten auch politische Entscheidungsträger. Und selbst im Bereich der Züchtung von Nutzpflanzen zur Ertragsverbesserung hat es schon Spionage gegeben. Eine Regierung muss, wenn ihr Land autark sein soll, hinreichend Nahrung für die Bevölkerung produzieren können. In Zeiten von

Klimaveränderungen und Bevölkerungswachstum ist das durchaus ein Problem. Sie werden bei der Analyse von Gefährdungen unter Umständen aufgrund der speziellen Umstände in Ihrem Unternehmen unter Umständen auch auf eine oder mehrere Gefährdungen stoßen, die das BSI noch nicht berücksichtigt hat. Diese nehmen Sie zusätzlich in Ihren individuellen Gefährdungskatalog auf. Wenn eine oder mehrere Gefährdungen aus dem Katalog bei Ihnen keine Rolle spielen, dann lassen Sie diese weg, dokumentieren aber natürlich die Gründe für das Weglassen. Diese Gefährdungsbetrachtung wiederholen Sie regelmäßig und bei Bedarf. Auch hier kommt wieder unser PDCA-Zyklus mit der stetigen Verbesserung zum Tragen. Nach der Hochwasserkatastrophe in Nordrhein-Westfalen und Rheinland-Pfalz im Sommer 2021 sollten Unternehmen, die bis jetzt die Gefährdung »G 0.3 Wasser« wegdiskutiert haben, weil sie sich für nicht betroffen hielten, diese Gefährdung neu bewerten. Es ist gut möglich, dass die Gefährdung für Sie nicht relevant ist, aber im Sinne eine guten Bedrohungsanalyse müssen Sie solche Ereignisse zum Anlass für eine Überprüfung nehmen. Wenn sich die Gefährdungslage für Ihr Unternehmen geändert hat, müssen Sie aktiv werden. Ansonsten haben Sie das gute Gefühl, Ihre Hausaufgaben gemacht zu haben. Und wie immer: die Neubewertung muss unabhängig vom Ergebnis dokumentiert werden. Und, wo wir gerade dabei sind: Nehmen Sie den Großbrand im Straßburger Rechenzentrum des Hosters OVH im März 2021 zum Anlass, sich erneut mit der Gefährdung »G 0.1 Feuer« zu beschäftigen. Vielleicht haben Sie diese Gefährdung ja bisher unterschätzt.

Metriken und Bewertung Sie wollen objektiv messen, wie groß Ihre Bedrohungen sind? Dazu benötigen Sie verlässliche Informationen über Ereignisse und ihre Ausmaße.

Verläuft bei Ihnen in der Nähe ein Fluss? Dann gibt es bestimmt auch einen Pegel, der die Höhe seines Wasserstands misst. Diese Information können Sie selbst überwachen, da solche Informationen in der Regel im Internet abrufbar sind. Die Stadt Köln hat eine ausführliche Informationsseite zum Hochwasserschutz ([StK]). Sie finden dort die Information über hohe Pegelstände und deren Häufigkeit sehr gut aufbereitet: häufiges Ereignis: Pegelstand 9,60 m, mittleres Ereignis: Pegelstand 11,30 m, seltenes Ereignis: Pegelstand 11,90 m, extremes Ereignis: Pegelstand 12,90 m. Der Hochwasserschutz der Stadt ist auf maximal 11,90 m Pegelstand ausgelegt. Wenn Sie jetzt wissen, ab welchem Pegelstand Ihre IT betroffen ist, können Sie planen. Die aktuell für Sie relevanten Pegelstände können Sie automatisiert auslesen und mit entsprechenden Schwellenwerten in Ihr normales Monitoring aufnehmen. Über viele andere Parameter im Umfeld Ihres Unternehmens können Sie sich ebenfalls nützliche Informationen beschaffen. Wie stabil ist die Stromversorgung? Gibt es häufig Blitzeinschläge (Gefahr von Überspannung in der Stromversorgung)? Was sind die Höchsttemperaturen im Sommer (danach müssen Sie die Klimatisierung der Rechnerräume auslegen)? Wie hoch ist das Einbruchsrisiko in Ihrer Gegend? Sie können aber auch im eigenen Unternehmen Gefährdungen messen. Abbildung 13.1 zeigt für einen Server die unberechtigten LoginVersuche (etwa zehn pro Stunde). Dieses »Grundrauschen« ist nicht besorgniserregend. Nimmt es in der Häufigkeit deutlich zu und Sie sehen als Login-Namen die Namen von bei Ihnen tatsächlich existierenden Nutzerkonten, dann müssen Sie sich darum kümmern. Anzeichen für die

Gefährdung »G 0.23 Unbefugtes Eindringen in IT-Systeme« können Sie jedenfalls aus dem Beispiel in Abbildung 13.1 nicht herauslesen. Was für Ihr Unternehmen ein typisches Grundrauschen ist, können Sie selbst leicht messen.

Abbildung 13.1: Auszug aus der Log-Datei auth.log eines Servers. Hier sind die unberechtigten Anmeldeversuche innerhalb von drei Stunden zu sehen.

Kapitel 14

Grundlegende Dokumentation IN DIESEM KAPITEL Grundkonzepte und Begriffe im IT-Servicemanagement Dokumentation als Grundlage für Informationssicherheitsprozesse Assetmanagement: Inventar, Eigenschaften und Konfigurationen Rollen und Rechte für die Zugriffskontrolle

Wir beschäftigen uns jetzt mit einigen Grundkonzepten und Begriffen des IT-Servicemanagements. Dies ist notwendig, da die IT-Sicherheit auf die Informationen aus dem IT-Servicemanagement angewiesen ist. Damit die Übersicht über die Informations- und Kommunikationstechnik (IuK) in einem Unternehmen nicht verloren geht, müssen alle ITKomponenten und IT-Prozesse dokumentiert werden. Dabei sind mehrere Gruppen von Komponenten zu berücksichtigen: aktive Hardwarekomponenten, passive Hardwarekomponenten, Software, Konfigurationen, Nutzerinnen. Alle Komponenten müssen dokumentiert sein: das heißt, es muss entsprechende Listen, Beschreibungen und eventuell auch Datenbanken geben. Dabei lassen sich die verschiedenen Komponenten auf zweierlei Weise behandeln (siehe Tabelle 14.1):

Die Kaufleute pflegen ein Inventarverzeichnis, um die Vermögenswerte (Assets) des Unternehmens darzustellen. Hierbei wird den Assets ein eindeutiges Ordnungskriterium, die Inventarnummer, zugeordnet. Ein Gerät wird in das Inventarverzeichnis aufgenommen, wenn es geliefert wurde. Die IT führt ein Verzeichnis der Komponenten, um die sie sich kümmern muss, das heißt der Geräte, die sie konfigurieren muss (Configuration Item, CI). Diese Datenbank wird üblicherweise CMDB (Configuration Management Database) genannt. Eine Komponente wird in dieses Verzeichnis aufgenommen, wenn sie in Betrieb genommen wird. Die Inbetriebnahme ist in der Sprache von ITIL auch ein Change-Request, also eine Veränderungsanforderung. Insofern wird die Änderung der CMDB-Einträge mit der Bearbeitung der Change-Requests verbunden. Die IT-Sicherheit benötigt für ihre Tätigkeit unverzichtbar eine CMDB, da nur so die Übersicht über den Soll-Zustand der IT gewonnen werden kann.

Hersteller Klasse Anschaffungsjahr Kaufpreis Abschreibung

Inventarverzeichnis

CMDB

Dell

Dell

Notebook

Notebook

2019

2019

1600,00 € 3 Jahre

IP-Adresse

10.20.30.42

CPU

Intel Core i7

Speicher

4 GByte

Netzwerk

Realtek 8821

Verantwortlicher Nutzerin

Personalabteilung Maxima Mustermann

Tabelle 14.1: Die Unterschiede zwischen einem Inventarverzeichnis und einer CMDB mit einigen Beispieleinträgen.

Die Kaufleute können helfen Im Rahmen einer ordnungsgemäßen Buchführung muss auch ein Inventarverzeichnis geführt werden. Alle langlebigen Wirtschaftsgüter müssen darin aufgenommen werden. Dies gilt sowohl für Unternehmen mit einer doppelt-kaufmännischen Buchführung als auch für die Behörden, die noch eine kameralistische Buchführung pflegen. Damit gibt es im Unternehmen schon einen Grundstock an Aufzeichnung des Inventars. Auch wenn die Kriterien zur Erstellung unterschiedlich sind, ist es ein erster Einstieg. Dieser Grundstock an Informationen muss dann um die Komponenten ergänzt werden, bei denen die IT-Relevanz nicht offensichtlich aus der Buchführung ersichtlich ist. Das Unternehmen beschafft zum Beispiel eine Werkzeugmaschine mit numerischer Steuerung. Zur Programmierung hat sie einen Netzwerkanschluss, ist also für die ITAbteilung relevant. Häufig werden Rechner mit einer Lizenz für ein Betriebssystem ausgeliefert. Diese Lizenz erscheint nicht immer auf der Rechnung, ist aber vorhanden. Einer IT-Abteilung kann nur empfohlen werden, sich aus der Buchführung alle ITrelevanten Beschaffungen exportieren zu lassen und diese Daten regelmäßig zu synchronisieren, um damit die eigenen Listen, nach Möglichkeit automatisiert, abzugleichen.

Die IT-Dokumentation sollte nicht nur auf Papier erfolgen. Es sollte immer auch eine digitale Version vorhanden sein. Die digitale Version der Dokumentation darf aber nicht nur in einer großen zentralen Datenbank im eigenen Netz gespeichert sein, sie muss im Störungsfall ohne funktionierendes Unternehmensnetz zugänglich sein. Ein Notebook oder ein Standalone-Rechner mit einer aktuellen Kopie der Datenbank oder die Nutzung einer Cloud-Anwendung sind erforderlich. Im Störungsfall muss man von einem beliebigen Ort aus auf die Konfigurationsinformation zugreifen können.

Großbrände in Rechenzentren, wie das Feuer im OVHRechenzentrum in Straßburg im Frühjahr 2021, oder Hochwasser wie im Sommer 2021 in Nordrhein-Westfalen und Rheinland-Pfalz zeigen, dass Kopien wichtiger Informationen in größerer Entfernung vom Unternehmen oder auf leicht zu transportierenden mobilen Geräten hilfreich sind. Die grundlegende Dokumentation zur IT des Unternehmens muss im Störungsfall unmittelbar zugänglich sein. Schon die Wiederherstellung aus einem Backup kann in der Stresssituation eines Katastrophenfalls ein Schritt zu viel sein. Das BSI gibt in seinem Dokument »Kriterien für die Standortwahl von Rechenzentren« [BSI19a] klare Empfehlungen für die Mindestentfernung von Rechenzentren zu Gefahrenquellen und Zweitrechenzentren. Zwei Rechenzentren eines Unternehmens sollten mindestens 200 km auseinander liegen. Eine regelmäßige Inventur im Netzwerk zum Soll-Ist-Abgleich ist mit technischen Mitteln leicht umzusetzen. Die Erfahrung zeigt, dass bei einer derartigen Inventur sowohl Komponenten gefunden werden, die noch nicht bekannt sind, als auch Komponenten nicht gefunden werden, die da sein sollten. In der Praxis heißt dies, dass zum Beispiel ein Rechner an der IT vorbei in Betrieb genommen wurde (Schatten-IT oder »Bring Your Own Device«) oder ein Rechner unter der Hand aussortiert oder im Extremfall sogar entwendet wurde. Hierbei sind allerdings die gesetzlichen Regelungen zur verpflichtenden Mitbestimmung in den Personalvertretungsgesetzen zu beachten. Diese verbieten ohne Zustimmung der Personalvertretung eine Verhaltens- und Leistungskontrolle mit technischen Mitteln (zum Beispiel § 87 Abs. 1 Nr. 6 BetrVG, § 80 Abs. 1 Nr. 21 BPersVG oder entsprechende Regelungen in den Landespersonalvertretungsgesetzen). Diese Regelungen greifen allerdings nur, wenn es um die technische Kontrolle von Geräten oder Konfigurationen geht, die Nutzerinnen zugeordnet sind oder zugeordnet werden können. Ein Scan über das Netz der Server, um das Vorhandensein oder die Konfiguration der Server zu erheben,

fällt nicht unter die Mitbestimmung, ein entsprechender Netzwerkscan im Client-Netz mit den Desktoparbeitsplätzen der Beschäftigten sehr wohl. Bei Bedarf ist eine Betriebs- oder Dienstvereinbarung abzuschließen.

Inventur mit Nmap Der freie Open-Source-Netzwerkscanner Nmap ist für alle wichtigen Betriebssysteme verfügbar. Es ist ein ausgesprochen mächtiges Werkzeug für IT-Administratoren. Mit Nmap lässt sich eine Inventur im Netzwerk recht einfach durchführen. Beispielsweise lassen sich mit nmap -sn 10.2.3.0/24 alle laufenden Rechner im Netz finden. Dabei ist die Netzwerkadresse 10.2.3.0/24 (auch in den folgenden Beispielen) an das eigene Netz anzupassen. Das Ergebnis ist eine Liste der gefundenen Rechner mit IP- und MAC-Adresse. Mit nmap 10.2.3.0/24 erhalten wir zusätzlich für jeden Rechner eine Liste der im Netz angebotenen Dienste. Allerdings werden nur die wichtigsten 1000 Dienste geprüft. Mit nmap -p- -T4 -A -v 10.2.3.0/24 werden dagegen wirklich alle Dienste geprüft und gleichzeitig wird versucht festzustellen, welche Software in welcher Version den Dienst erbringt. Wegen der umfangreicheren Prüfungen verlängert sich die Laufzeit hierdurch natürlich erheblich. Neben der kommandozeilenbasierten Version gibt es mit Zenmap auch eine grafische Nutzeroberfläche, die die Bedienbarkeit vereinfacht und die Ergebnisse optisch besser aufbereitet. Neben diesem freien Tool ist auch einiges an kommerzieller Software am Markt, womit man deutlich komfortabler Inventur machen kann. Bekannt sind zum Beispiel die Scanner von Greenbone, Nessus oder Qualys.

Asset- und Konfigurationsmanagement Der englische Begriff »Assets« bezeichnet eigentlich die Vermögenswerte eines Unternehmens. Mit dem Assetmanagement ist also die Verwaltung der Vermögenswerte gemeint. In der IT geht es dabei jedoch naheliegenderweise nur um die Verwaltung der Hard- und Software im Unternehmen. Ein Verzeichnis aller Assets ist die Basis für

das Management der IT und stellt quasi die Stammdaten für die Configuration Management Database (CMDB) dar. Für einen DesktopPC sind dies typischerweise: CPU mit Zahl der Cores, Ausstattung mit RAM (Typ, Größe), Ausstattung mit Datenträgern (Kapazität, Typ, Schnittstellen), Ausstattung mit Hardwarekomponenten (Grafik, Netzwerk, MacAdressen, USB, Sound …), Grafik und Bildschirmausstattung, BIOS inklusive Funktionalität und Version, Besonderheiten (Chipkartenleser, Kamera, …). Die IT benötigt diese Angaben, um die Konfiguration des Rechners und der darauf laufenden Software (zum Beispiel Treiberausstattung im Betriebssystem) festzulegen. Bei Sicherheitswarnungen, zum Beispiel bei dringend erforderlichen BIOS-Updates, muss leicht feststellbar sein, welche Rechner dieses Update benötigen. In einer CMDB sollten auch die Beziehungen (Relationen) zwischen Rechnern festgehalten werden. Zum Beispiel benötigt der Webserver Zugriff auf eine Datenbank. Dementsprechend muss beim Webserver eingetragen werden, mit welchem Datenbankserver er kommuniziert. So benötigen Sie zum Beispiel, wenn der Datenbankserver kompromittiert wurde, die Information, welche anderen Anwendungen davon betroffen sind. Zur Systematisierung empfiehlt sich eine Einteilung in Geräteklassen, wie sie auch beispielsweise im IT-Grundschutz vorgenommen wird. Die folgenden Klassen stellen eine gute Ausgangsbasis dar: Server, stationäre Client-Rechner, mobile Client-Rechner,

Smartphones und Tablets, Prozesssteuerung in der Produktion (im Privatbereich IoT), Gebäudeleittechnik (im Privatbereich IoT), Firewall und VPN-Gateways, Netzwerkkomponenten (Router, Switches, Repeater, WLAN, Verkabelung), IP-Telefonie. Je nach Unternehmensgröße und der damit verbundenen Zahl an Geräten können die Klassen noch weiter aufgespalten oder zusammengefasst werden. Auf jedem Rechner läuft Software, vom Betriebssystem bis zur Anwendung. Software muss lizenziert werden und schon deshalb braucht ein Unternehmen eine saubere Softwareinventarisierung. Die IT benötigt bei der Software auch Informationen zur Lizenz (zum Beispiel die Laufzeit) und zu den eingesetzten Versionen. Deshalb gehört zur Softwareinventarisierung auch eine genaue Erfassung, welche Versionen lizenziert sind und welche Versionen einer Software tatsächlich installiert sind. Auch die Bestandsaufnahme bei der Software lässt sich automatisiert per Software durchführen. Im Gegensatz zur Inventarisierung der Hardware ist eine automatische Softwareerfassung auf den Rechnern nur per speziellem Agent (eine Softwarekomponente zu Erfassung der installierten Software auf den Endgeräten) möglich, da über das Netzwerk nicht für jede Software feststellbar ist, welche Software installiert ist. Bitte beachten sie gerade beim Einsatz von Agenten auf Arbeitsplatzrechnern auch die Mitbestimmung.

Globale Softwareanbieter wie Microsoft, Oracle oder VMware, um nur einige zu nennen, führen in größeren Unternehmen immer mal wieder ein Software-Audit durch. Dabei wird die Anzahl der installierten und genutzten Software mit der Anzahl der Lizenzen abgeglichen. Hat ein Unternehmen zu wenig Lizenzen, muss es nachlizenzieren und die Kosten des Audits tragen. Nur wer sein Lizenzmanagement im Griff hat, verschwendet kein Geld durch Überlizenzierung oder bekommt bei so einem Audit keine Probleme wegen Unterlizenzierung. Im Bereich der eigentlichen Informationssicherheit interessiert der Compliance-Aspekt einer sauberen Lizenzierung nur eingeschränkt. Die IT-Sicherheit interessiert sich allerdings sehr für die jeweils installierten Softwareversionen. Gibt es eine Sicherheitswarnung für eine bestimme Softwareversion, dann ist es gut, wenn die IT-Sicherheit schnell und verlässlich nachschauen kann, ob die Software in der unsicheren Version installiert ist oder nicht. Alle IT-Geräte, die als Einheit aus Hard- und Software (Appliance) geliefert werden, also zum Beispiel Firewalls, Router oder VPNGateways, müssen verlässlich erfasst sein. In solchen Fällen lassen sich einzelne Softwarekomponenten nicht ohne Weiteres aktualisieren, da der Hersteller die Firmware als Gesamtpaket liefert und updatet. Es kann durchaus vorkommen, dass der Hersteller einer solchen Appliance ein kritisches Sicherheitsupdate zur Verfügung stellt und alle Kunden auffordert, dies unverzüglich einzuspielen. In der Praxis scheitern Kunden aber am Update, da sich zum Beispiel die Anforderungen an den Speicherausbau der Appliance geändert haben. An sich ist es einfach, ein zusätzliches Speichermodul einzubauen, aber aufgrund der Situation ist der Markt wie leergefegt und viele Kunden bekommen die notwendige Speichererweiterung nicht.

Auch das nach Art. 30 DS-GVO vorzuhaltende »Verzeichnis von Verarbeitungstätigkeiten« (VVT) ist im Grunde ein Teil des Assetmanagements oder zumindest eng mit diesem verzahnt. Der Datenschutz schaut jedoch eher aus einer Prozessperspektive auf die Verarbeitung. Hier interessiert nicht primär das Gerät, auf dem die Verarbeitung stattfindet, sondern der Prozess der Verarbeitung. Grundsätzlich, losgelöst vom Datenschutz, muss ein Unternehmen immer wissen, welche Daten zu welchen Zwecken verarbeitet werden. Das VVT ist durch die DS-GVO ein vorgeschriebener Standard bezüglich der Verarbeitung personenbezogener Daten. Der Art. 30 schreibt folgende Inhalte vor: Namen und die Kontaktdaten des Verantwortlichen sowie einer etwaigen Datenschutzbeauftragten, Zwecke der Verarbeitung, Beschreibung der Kategorien betroffener Personen und der Kategorien personenbezogener Daten, Kategorien von Empfängern, gegenüber denen die personenbezogenen Daten offengelegt worden sind oder noch offengelegt werden, einschließlich Empfänger in Drittländern oder internationalen Organisationen, gegebenenfalls Übermittlungen von personenbezogenen Daten an ein Drittland oder an eine internationale Organisation, einschließlich der Angabe des betreffenden Drittlands oder der betreffenden internationalen Organisation, sowie (falls erforderlich) die Dokumentation der geeigneten Garantien, vorgesehene Fristen für die Löschung der verschiedenen Datenkategorien, eine allgemeine Beschreibung der technischen und organisatorischen Maßnahmen gemäß Artikel 32 Absatz 1. Diese Aufzählung lässt sich leicht zu einem minimalen Standard für die Dokumentation der IT-Prozesse verallgemeinern. Mindestens sollten erfasst werden:

Zweck der Verarbeitung, Beschreibung der verarbeiteten Daten inklusive des Schutzbedarfs, wohin und an wen die Daten gegebenenfalls übermittelt werden, Beschreibung der technisch-organisatorischen Maßnahmen zum Schutz der Daten. Sieht man von einigen Besonderheiten für personenbezogene Daten ab (zum Beispiel den Drittlandtransfer), ist ein VVT genau die prozessorientierte Dokumentation der Datenverarbeitung, die die Informationssicherheit etwa für eine Gefährdungsanalyse oder Risikobetrachtung benötigt. Die ersten drei Punkte dieser Minimaldokumentation müssen die zuständigen Fachabteilungen der Informationssicherheit zuliefern. Nur die Finanzabteilung kennt die eigenen Prozesse und Verarbeitungen sowie den jeweiligen Schutzbedarf ihrer Daten wirklich (siehe Kapitel 13). Die Erfahrung in vielen Unternehmen zeigt, dass es ein mühsamer Prozess ist, diese Informationen aus den Fachabteilungen zu bekommen. Einen einzelnen Rechner zu konfigurieren, bekommen wir mit einigem Aufwand hin. Einen zweiten Rechner identisch zu konfigurieren, ist eine Herausforderung, da kaum jemand die Konfiguration seines Rechners hinreichend gut und vollständig dokumentiert. Auch wenn wir unseren Rechner, zum Beispiel nach einem Befall mit Schadsoftware, neu aufsetzen müssen, tun wir uns schwer, den Rechner identisch mit dem Ausgangszustand einzurichten. In Unternehmen mit vielen Rechnern und unterschiedlichen Klassen von Rechnern ist das Problem noch ein Vielfaches größer. Um auf Dauer Ihre IT sicher betrieben zu können, müssen Sie in der Lage sein, auf einem beliebigen Rechner eine definierte Version des Betriebssystems und alle erforderlichen Anwendungen automatisiert zu installieren und eine vorgegebene Konfiguration des Betriebssystems und der Anwendungen automatisiert einzuspielen.

Dies lässt sich nur erreichen, wenn die Installation über eine Softwareverteilung erfolgt und die Konfigurationen über geeignete Managementsysteme vorgenommen werden. Gerade auch bei Virtualisierung, Cloud-Nutzung und Betriebsmodellen wie Continuous Delivery sind derartige Automatismen unerlässlich.

Virtualisierung und die Cloud Die Nutzung der Cloud ist ohne Virtualisierung praktisch unmöglich. Das schnelle Aufsetzen eines neuen Rechners aus einer Verwaltungsoberfläche ist nur machbar, wenn der Prozess vollständig in Software abläuft. Auch Skaleneffekte lassen sich nur per Software erzielen. Zur Virtualisierung gibt es unterschiedliche Ansätze. Grundsätzlich hat man jedoch ein Gast-Betriebssystem (Guest), das in der virtuellen Umgebung läuft, und das Gastgeber-Betriebssystem (Host), unter dem die Virtualisierungssoftware läuft. Bei der vollständigen Virtualisierung wird die Hardware eines Rechners komplett virtuell dargestellt. Auf diesem virtuellen Rechner wird dann ein beliebiges Betriebssystem installiert. Typische Vertreter dieser Virtualisierung sind Microsoft HyperV, Oracle VirtualBox, Corel Parallels, QEMU oder VMware im Desktopbereich. Im Serverbereich sind es HyperV, ProxMox, QEMU, VMware ESX oder XEN. Als Paravirtualisierung wird eine Unterart der Virtualisierung bezeichnet, bei der der Guest auf die physikalische Hardware des Hosts zugreift. Hierzu muss das Guest-Betriebssystem angepasst werden. Die genannten Softwaresysteme unterstützen zum Teil auch Paravirtualisierung. Die Paravirtualisierung bietet Performancevorteile. Eine andere Variante der Virtualisierung ist die Containerisierung. Bei der Containerisierung müssen Host und Guest zwingend dasselbe Betriebssystem nutzen, da der Guest den Betriebssystemkern des Hosts mitbenutzt. Bekannte Produkte in diesem Bereich sind LXC, KVM oder OpenVZ, aber auch Docker. Während Container wie LXC, KVM oder OpenVZ auf Langlebigkeit ausgelegt sind und einen Neustart unter Erhalt der im Container gespeicherten Daten erlauben, ist Docker nur für einen Start ausgelegt. In einem Docker-Container können keine Daten gespeichert werden, die einen Neustart überstehen müssen. Bei einem Docker-Container wird eine Anwendung in ihre einzelnen Komponenten zerlegt, es laufen dort also zum Beispiel Webserver und Datenbank in separaten Containern. Die persistente Datenhaltung der Datenbank geschieht außerhalb des Datenbank-Containers. Einzelne Container können neu gestartet werden, um sie zu aktualisieren. Die Kommunikation zwischen den Containern funktioniert über ein virtuelles Netzwerk. In einer derartigen Umgebung sind ein automatisiertes Konfigurationsmanagement und eine automatisierte Konfigurationskontrolle unerlässlich.

Die Minimalversion eines Konfigurationsmanagements ist die zentrale Speicherung der Konfigurationsdateien. Dies ist relativ einfach, wenn es sich um Textdateien handelt. Hierzu bietet sich ein System mit einer Versionsverwaltung wie SVN oder GIT an. Bei binären Dateien können zwar die gleichen Versionsverwaltungssysteme zur Speicherung genutzt werden, es besteht jedoch kein unmittelbarer Zugriff auf die Unterschiede der einzelnen Konfigurationsversionen. Nutzt man eine Konfigurationsmanagement-Software, kann die Konfiguration auch in der Metasprache der Software gespeichert werden, da eindeutig ist, wie daraus die konkrete Konfiguration erzeugt wird. Bei der Nutzung eines Versionsverwaltungssystems zum Konfigurationsmanagement besteht das Risiko, dass im Störungsfall kein Zugriff auf die Daten besteht. Es muss sichergestellt werden, dass es immer einen Zugriff auf die aktuelle Version der gesamten Konfigurationsinformation gibt. Dies muss auch von einem Gerät möglich sein, das unabhängig vom Unternehmensnetz betrieben werden kann. Hierzu muss die Konfiguration zum Beispiel auf einem Notebook synchronisiert werden.

Wo werden Konfigurationsdaten gespeichert? Der primäre Speicherort der Konfigurationsdateien eines Unix-/Linux-Systems sind das Verzeichnis /etc und seine Unterverzeichnisse. Hiervon wird allerdings gerade bei eingebetteten (embedded) Systemen auch abgewichen. Benutzerspezifische Konfigurationen befinden sich im Heimatverzeichnis der Nutzerin, zum Beispiel die Konfiguration der BASH in der Datei $HOME/.bashrc oder die SSH-Konfiguration im Verzeichnis $HOME/.ssh. Die lokale Windowskonfiguration befindet sich hauptsächlich in der Registrierungsdatenbank. Nicht alle Programme benutzen jedoch diesen Speicherort. Weitere Ablageorte für Konfigurationsdaten sind das Verzeichnis %ALLUSERSPROFILE%, meist \ProgramData, und für die benutzerspezifischen Einstellungen diverse Verzeichnisse unter %USERPROFILE%. Darüber hinaus lässt sich ein Windowssystem über

Gruppenrichtlinien verwalten (gilt nicht für die Home-Variante). Es sind sowohl lokale als auch zentrale Gruppenrichtlinien möglich. In einem Unternehmen werden die Gruppenrichtlinien auf dem Domain-Controller in der zentralen Konfigurationsdatenbank »Active Directory« verwaltet.

Viele Appliances können ihre Konfiguration nur als Ganzes exportieren und importieren. Wenn die Konfigurationsdatei nicht aus einer Managementlösung erzeugt werden kann, bleibt nur die Speicherung der exportierten Konfigurationsdateien. Etliche Hersteller bieten Webbasierte Managementlösungen für ihre Appliances an. Dies beinhaltet eine Cloud-basierte Speicherung der Konfigurationsdateien beim Hersteller oder bei einem Cloud-Dienstleister, bei dem der Hersteller seine Anwendung betreibt.

Nutzermanagement und Zugriffskontrolle Alle Beschäftigten eines Unternehmens, die aufgrund ihrer Tätigkeit die Berechtigung haben, die IT zu nutzen, müssen eine Nutzerberechtigung erhalten. Dazu legt die IT für jede Nutzerin ein Konto an und erteilt über dieses Konto die Berechtigungen. Es empfiehlt sich, nur Konten anzulegen, die einer Person zugeordnet sind, da unter Umständen nachvollzogen werden muss, wer was wann gemacht hat. Damit die Benutzerberechtigungen eindeutig und einheitlich sind, sollte eine zentrale Nutzerdatenbank geführt werden. Die beste und vollständigste Information über die Beschäftigten und ihre organisatorische Einbindung im Unternehmen hat die Personalabteilung. Deshalb muss die IT in Onboarding-, Offboarding- und Versetzungsprozesse eingebunden werden. Diese Einbindung ist bidirektional. Die IT wird über die Veränderungen informiert und generiert zum Beispiel beim Onboarding die E-Mail-Adresse, das Nutzerkonto, stellt einen Rechner mit der erforderlichen Software zur Verfügung und so weiter. Die E-Mail-Adresse muss dann zurück in das Personalverwaltungssystem gespielt werden. Bei der Versetzung werden Berechtigungen angepasst und erforderliche Änderungen an der

Ausstattung vorgenommen. Beim Offboarding müssen die E-MailAdresse und das Nutzerkonto gesperrt, die IT-Ausstattung zurückgegeben und die Daten aufgeräumt und übergeben werden. Alles was mit E-Mail-Adresse, Benutzerkonto und Berechtigung zu tun hat, findet in der Regel im sogenannten Identitätsmanagement, also der zentralen Benutzerverwaltung statt. Alles was mit der IT-Ausstattung zu tun hat, findet im Asset- und Konfigurationsmanagement statt. Wenn das Identitätsmanagement auch als zentraler Authentisierungsdienst dient, müssen keine Nutzerkonten auf den einzelnen Systemen angepasst werden. Gleichzeitig bietet ein Identitätsmanagementsystem der Nutzerin die Möglichkeit, ihr Passwort zentral zu ändern oder eine Selfservice-Passwortrücksetzung durchzuführen. Für jede Nutzerin müssen entsprechende Berechtigungen gepflegt werden. Einige Grundberechtigungen müssen an alle Nutzenden vergeben werden, zum Beispiel Nutzung der E-Mail, Drucken oder Zugriff auf das Employee-Selfservice-Portal. Andere Berechtigung hängen von der Funktion im Unternehmen (Rolle) ab. Eine Beschäftigte in der Finanzabteilung darf auf andere Systeme zugreifen als eine Beschäftigte der Personalabteilung. Ein Berechtigungskonzept sollte rollenbasiert sein. Der Aufwand, Rollen festzulegen, ist nicht zu unterschätzen, aber auf lange Sicht bietet ein Rollenkonzept Vorteile. Wenn die Rollen festgelegt und auditiert sind, ist der nächste Schritt, die Zuordnung der Rollen zu den Beschäftigten, einfacher und auch einfacher zu auditieren. Würden jeder Beschäftigten ihre Rechte individuell zugewiesen, wäre die Überprüfung erheblich aufwendiger und dazu für jede einzelne Beschäftigte erforderlich. Wenn wir über Zugriff reden, müssen wir genauer definieren, was Zugriff heißt. Dabei lässt sich die Art und Weise des Zugriffs auf wenige Kernfunktionen reduzieren: Lesen (Read, r): Der Inhalt eins Objekts darf angeschaut werden. Schreiben (Write, w): Der Inhalt eins Objekts darf verändert werden. Diese Funktion kann weiter unterteilt werden:

Erzeugen (Create): Ein Objekt darf erstellt werden. Ändern (Change, Alter): Der Inhalt eins Objekts darf verändert werden. Dies beinhaltet auch das Löschen des Objekts. Ergänzen (Append, a): Der vorhandene Inhalt darf nicht geändert werden; es darf aber neuer Inhalt hinzugefügt werden. Ausführen (Exceute, e oder x): Der Inhalt darf als Prozess ausgeführt werden. Vielfach wird davon ausgegangen, dass das Recht »Ausführen« das Recht »Lesen« beinhaltet. Kontrollieren (Control, c): Das Recht, die Rechte eines Objekts zu ändern. Formal gesehen führen Subjekte (zum Beispiel Nutzerinnen, Prozesse, …) Transaktionen auf Objekten aus (zum Beispiel Dateien, Geräten, Tabellen, …). Für die Transaktionen sind bestimmte Rechte (zum Beispiel lesen, schreiben, löschen, …) erforderlich. Um die Zugriffskontrolle systematisch im Rahmen von Sicherheitsrichtlinien festzulegen, bedarf es noch einer weiteren Formalisierung. Die drei wichtigsten Zugriffskontrollkonzepte sind: Die systembestimmte Zugriffskontrolle (mandatory access control, MAC) hat ihre Wurzeln in der Abbildung militärischer Geheimhaltungsstufen und entsprechender Freigaben der Nutzerinnen (TCSEC, 1985). Die benutzerbestimmbare Zugriffskontrolle (discretionary access control, DAC) eignet sich für Unternehmen und zivile Anwendungen in Behörden (TCSEC, 1985). Die rollenbasierte Zugriffskontrolle (role-based access control, RBAC) wurde eingeführt, um die Zugriffskontrolle von der Aufgabenerfüllung her gedacht zu regeln (Ferraiolo und Kuhn, 1992).

Voraussetzung für eine Zugangskontrolle ist die Identifizierung der Nutzerinnen. Bei der systembestimmten Zugriffskontrolle werden die Objekte und Subjekte nach hierarchischen Geheimhaltungsstufen klassifiziert. Die Regeln orientieren sich vorrangig an der Vertraulichkeit der Daten. Dazu werden alle Objekte mit einem Label versehen. Gleichzeitig haben alle Subjekte eine Freigabe für die entsprechenden Stufen. Durch die hierarchische Ordnung ergeben sich die Zugriffsregeln: »no read up«, das heißt jede Nutzerin darf nur Daten innerhalb ihrer eigenen Geheimhaltungsstufe oder einer niedrigeren lesen. Dadurch wird verhindert, dass Nutzerinnen für sie nicht freigegebene Informationen lesen können. »no write down«, das heißt jede Nutzerin darf nur Daten innerhalb ihrer eigenen Geheimhaltungsstufe oder einer höheren schreiben. Dadurch wird verhindert, dass Nutzerinnen mit höheren Zugangsrechten Informationen nach unten weitergeben. Dieses Zugriffsmodell zielt ausschließlich auf die Vertraulichkeit. Es wurde 1973 von David Elliott Bell und Leonard J. LaPadula im Auftrag der US Air Force entwickelt und ist unter dem Namen Bell-LaPadulaModell bekannt. Diese Zugriffskontrolle wird durch das System vorgegeben und ist durch die Nutzerinnen nicht anpassbar. Auch bei der benutzerbestimmbaren Zugriffskontrolle ergeben sich die Zugriffsrechte ausschließlich aus der Identität des Subjekts (zum Beispiel Nutzerin). Für jedes Objekt wird eine Liste geführt (Access Control List, ACL), in der vermerkt ist, welche Rechte welches Subjekt hat. Jede Nutzerin hat eine User-Id, die in der ACL verwendet wird. Die Nutzerin mit der User ID 0, das ist root, darf alles. Der Zugriff auf ein Objekt (zum Beispiel eine Datei) kann für root nicht eingeschränkt werden.

Zugriffsrechte unter Unix

Unix kennt für Objekte die Rechte Lesen (r), Schreiben (w) und Ausführen (x). Unix kennt weiterhin Nutzerinnen und Gruppen. Eine Gruppe hat als Mitglieder mehrere Nutzerinnen. Eine Berechtigungsstruktur besteht aus den drei – erteilten oder verneinten – Rechten rwx jeweils für die Besitzerin, für die Gruppe und für den Rest der Welt. Die gesamten Rechte eines Subjekts wären also rwxrwxrwx. Eine Datei, die nur von ihrer Besitzerin geändert, von allen anderen dagegen nur gelesen werden darf, hätte dann die Rechte rw-r--r--. Um eine Datei ausführen zu können, muss zusätzlich zum Recht der Ausführung auch das Leserecht vorhanden sein: r-x. Die Datei, in der die verschlüsselten Passwörter der Nutzerinnen gespeichert sind, darf von normalen Nutzerinnen nicht einmal gelesen werden. Wie ändern wir dann unser Passwort? Es gibt ein spezielles Recht, dass zusätzlich gesetzt werden kann, das sogenannte SetUID Bit. Wird ein solches Programm gestartet, hat es nicht die Rechte der startenden Nutzerin, sondern die des root-Users, also des mächtigsten Administrators. Und der darf natürlich die Passwortdatei ändern. Da es kein Kontrollrecht gibt, kann jede Nutzerin die Zugriffsrechte ihrer eigenen Dateien ändern. Es gibt zwar eine im System festgelegte Voreinstellung für Zugriffsrechte bei einer neuen Datei, die Zugriffsrechte können jedoch von der Besitzerin jederzeit geändert werden. Mit Zusatzwerkzeuge wie AppArmor oder SELinux lässt sich ein erweitertes Rechtemanagement installieren.

Zugriffsrechte unter Windows Microsoft Windows kennt ebenfalls Zugriffsrechte auf Basis von Access Control Lists. Allen Objekten (zum Beispiel Drucker, Dateien, …) werden Attribute zugewiesen, aus denen sich ergibt, wer auf diese zugreifen darf. Das Rechtemanagement bei Windows basiert aber nicht auf Nutzer- oder Gruppennamen, sondern auf Security IDs (SID). Es gibt einige vordefinierte Benutzer und Gruppen mit ihren SIDs, die auf allen Windowssystemen gleich sind: Administratoren S-1-5-32-544 Benutzer

S-1-5-32-545

Gäste

S-1-5-32-546

Hauptbenutzer S-1-5-32-547 Alle anderen SIDs enthalten eine rechnerindividuelle Komponente. Da der Administrator keine spezielle Nutzerin ist, fügt sie sich wie jeder andere Nutzerin in das Rechtemanagement ein. Der Nutzerin Administrator kann der Zugriff auf die Dateien

der Nutzerinnen entzogen werden. Zugriffsrechte auf ein Objekt können einzelnen Nutzerinnen, aber auch Gruppen gegeben werden. Windows kennt die Rechte »Vollzugriff«, »Ändern«, »Lesen, Ausführen«, »Lesen«, »Schreiben« und »spezielle Berechtigungen«. Ein Recht kann zugelassen, aber auch explizit verweigert werden. Kollidieren »zulassen« und »verweigern«, dann gewinnt »verweigern«. Nur wer »Vollzugriff« auf ein Objekt hat, kann auch die Zugriffsrechte auf das Objekt ändern. Damit lassen sich die Dateirechte vergeben, die von normalen Nutzerinnen nicht geändert werden können.

Bei der rollenbasierten Zugriffskontrolle werden Zugriffsrechte (Permissions) zu Rollen zusammengefasst. Rollen orientieren sich dabei an Tätigkeitsbeschreibungen. So können Sie zum Beispiel die Rolle »Buchhalterin« schaffen. Darin sind alle Berechtigungen gebündelt, die eine Buchhalterin für ihre Tätigkeit benötigt. Wesentlich ist dabei, dass eine beliebige n:n-Zuordnung möglich ist: Eine Rolle kann mehrere Berechtigungen enthalten und eine Berechtigung kann mehreren Rollen zugewiesen werden. Auch kann eine Rolle mehreren Nutzern zugewiesen werden und eine Nutzerin kann mehrere Rollen zugeschrieben bekommen. Insgesamt besteht die Role-based Access Control (RBAC) des NIST aus vier aufeinander aufbauenden Stufen: flache rollenbasierte Zugriffskontrolle (flat RBAC), hierarchische rollenbasierte Zugriffskontrolle (hierachical RBAC), eingeschränkte rollenbasierte Zugriffskontrolle (constrained RBAC), symmetrische rollenbasierte Zugriffskontrolle (symmetric RBAC). Bei der flachen rollenbasierte Zugriffskontrolle erhält eine Nutzerin ihre Rollen unmittelbar zugewiesen. Es muss dabei eine Möglichkeit geben, die Zuordnungen zwischen Rollen und Nutzerinnen anzuzeigen und zu überprüfen. Dies ist bei Änderungen der Rollenzuordnung wichtig, damit man sehen kann, was geändert werden muss beziehungsweise worden ist. Es gibt in diesem Modell übrigens keine Vererbungen. Bei der hierarchischen rollenbasierten Zugriffskontrolle gibt es Vererbungen von Rechten über Rollenhierachien. Die Rolle

Hauptbuchhalterin erbt alle Rechte der Rolle Buchhalterin. Die Rolle Buchhalterin erbt aber keine Rechte der Rolle Hauptbuchhalterin. Ändern sich die Rechte der Rolle Buchhalterin, so ändert sich über die Vererbung automatisch auch die Rolle Hauptbuchhalterin. In einem gewissen Sinne spiegelt die Hierarchie der Rollen die Hierarchie der Stellen wider. Die eingeschränkte rollenbasierte Zugriffskontrolle ermöglicht es, ein Vier-Augen-Prinzip (separation of duties) abzubilden. In der statischen Variante gibt es feste Regeln, welche Rollen nicht gleichzeitig an Beschäftige vergeben werden dürfen. Die Rolle Zahlungsbuchung darf nicht zusammen mit der Rolle Zahlungsfreigabe an dieselbe Person vergeben werden. Dies ist relativ unflexibel, da dadurch mehr Personal benötigt wird. Bei der dynamischen Variante dürfen beide Rollen an eine Person vergeben werden. Die Einschränkung stellt dann aber sicher, dass eine Nutzerin nur die Zahlungen freigeben darf, die sie nicht selbst gebucht hat. Mit einem solchen Einschränkungsmechanismus können Sie Ihr Personal viel flexibler einsetzen. Die symmetrische rollenbasierte Zugriffskontrolle verlangt zusätzlich eine Möglichkeit, die Zuordnung der Zugriffsrechte zu den Rollen ähnlich wie die Zuordnung Rolle–Nutzerin anzuzeigen und zu überprüfen. Was genau ein Zugriffsrecht ist, lässt das Konzept der rollenbasierten Zugriffskontrolle offen. Die Verwaltung der Zuordnungen zwischen Rollen und Nutzerinnen erfolgt in der Regel in einem Identitätsmanagementsystem. Eine Nutzerin kann mehrere Rollen haben. In einer Sitzung müssen aber nicht alle Rollen gleichzeitig aktiv sein. Ein typisches Beispiel wäre eine Beschäftigte, die neben ihrer normalen Aufgabe auch noch ITAdministratorin ist. Die Administratorinnen-Rolle ist üblicherweise nicht aktiv. Die Nutzerin kann diese Rolle jedoch jederzeit aktivieren (zum Beispiel unter Unix durch das Kommando su). Es entspricht guter Praxis, Rollen mit hochwertigen Rechten, die nur selten benötigt werden, nicht standardmäßig aktiv zu halten.

Kapitel 15

Meldepflichten und Vorfallsmanagement IN DIESEM KAPITEL Wie Sie mit IT-Sicherheitsvorfällen umgehen Threat-Informationen Die Bedeutung von Threat Intelligence

Wenn Sie einen Datenschutz- oder IT-Sicherheitsvorfall im Unternehmen feststellen, muss ein definierter Prozess gestartet werden. Dazu müssen aber alle Beschäftigten im Unternehmen wissen, was sie tun müssen, wenn sie einen möglichen Vorfall bemerken. Da die Meldepflichten zum Teil Fristen vorgeben, müssen Sie den Prozess so gestalten, dass die Meldefristen eingehalten werden können. Die Frist beginnt immer in dem Moment, in dem ein Beschäftigter einen Vorfall bemerkt.

Datenschutzvorfälle Ein Datenschutzvorfall liegt vor, wenn es zu einem Vorfall mit personenbezogenen Daten gekommen ist. Es kann sich um einen unberechtigten Zugriff (Vertraulichkeit), eine nicht gewollte Zerstörung der Daten (Verfügbarkeit) oder eine unzulässige Veränderung der Daten (Integrität) handeln. Wird ein solcher Vorfall bemerkt, müssen Sie prüfen, ob sich aus dem Vorfall ein Risiko für die Rechte und Freiheiten der betroffenen Personen ergibt. Besteht nach Einschätzung der verantwortlichen Stelle kein Risiko für die Rechte und Freiheiten der Betroffenen, ist es

ausreichend, den Vorfall zu dokumentieren. Dies gilt insbesondere für die Risikobewertung, die zu dieser Beurteilung geführt hat. Besteht dagegen ein Risiko für die Rechte und Freiheiten der Betroffenen, so ist der Vorfall binnen 72 Stunden an die zuständige Aufsichtsbehörde zu melden. Die Frist beginnt mit der Entdeckung des Vorfalls im Unternehmen durch einen Beschäftigten. Kann die Frist nicht eingehalten werden, so ist die Nichteinhaltung der Frist gegenüber der Aufsichtsbehörde zu begründen. Besteht für die Rechte und Freiheiten der Betroffenen ein hohes Risiko, so ist der Vorfall zusätzlich auch den Betroffen mitzuteilen. Ein Beschäftigter der Personalabteilung hat das Gefühl, er hätte besser nicht auf den Link geklickt, auf den er gerade geklickt hat. Irgendetwas war komisch. Er ruft beim Helpdesk an und meldet seinen Verdacht. Noch während des Telefonats verändert sich sein Bildschirm und es wird die Erpressermeldung einer Ransomware angezeigt. Damit ist ein Datenschutzvorfall eingetreten, da auf dem Rechner Personaldaten verarbeitet werden. Durch die erpresserische Verschlüsselung sind die Personaldaten nicht mehr zugreifbar. Damit sind die Verfügbarkeit der Daten und die Integrität des Computers (möglicherweise der gesamten IT, wenn die Schadsoftware sich im Unternehmen ausbreitet) nicht mehr gegeben. Da Ransomware oft vor der Verschlüsselung der Daten eine Kopie an die Erpresser übermittelt, besteht auch eine mögliche Bedrohung der Vertraulichkeit der Daten. Neben einer schnellen Reaktion der IT zur Eingrenzung des Schadens greift hier auch die Meldepflicht. Bei Datenschutzvorfällen müssen IT-Sicherheit, IT und Datenschutz eng zusammenarbeiten, um den Vorfall zu verstehen und zu beurteilen. Auf Basis der Fakten und der rechtlichen Bewertung wird dann der Geschäftsleitung eine Empfehlung zur Meldung des Vorfalls ausgesprochen. Die Entscheidung über eine Meldung trifft jedoch die

Geschäftsleitung und nicht die Datenschutzbeauftragte oder der Informationssicherheitsbeauftragte. Auch die Entscheidung der Geschäftsleitung ist zu dokumentieren. Theoretisch ist es möglich, dass die Beauftragten eine Meldung für erforderlich halten, die Leitung sich aber dagegen entscheidet. Gerade in dem Fall ist es besonders wichtig, dass Sie den Entscheidungsprozess gut dokumentiert haben. Die praktische Durchführung der Meldung, das heißt das Ausfüllen des Meldeformulars, kann die Datenschutzbeauftragte übernehmen. Alle Datenschutzaufsichtsbehörden in Deutschland haben Formulare zur Meldung von Datenschutzvorfällen. Einige haben PDF-Formulare, andere Web-Formulare. Schauen Sie sich das Formular Ihrer zuständigen Aufsichtsbehörde an. Die Informationen, die Sie dort angeben müssen, sollten Sie auch intern im Rahmen der Vorfallbearbeitung erheben. Sie benötigen die Daten spätestens bei der Meldung. Typische Angaben in einer Meldung einer Datenschutzverletzung nach Art. 33 DS-GVO sind: verantwortliche Organisation und meldende Person oder Ansprechpartner; Details zur Datenschutzverletzung: Was ist passiert? Anzahl der betroffenen Personen, Art der betroffenen Daten, zum Beispiel Gesundheitsdaten, Adressdaten und so weiter, Kategorien der betroffenen Personen, zum Beispiel Beschäftigte, Kunden, Patienten und so weiter; Folgen der Datenschutzverletzung: Welche Schutzziele wurden verletzt? Folgen für die betroffenen Personen, zum Beispiel: finanzieller Schaden, Rufschädigung und so weiter,

Risikoeinschätzung; getroffene Abhilfemaßnahmen.

IT-Sicherheitsvorfälle Ein Datenschutzvorfall kann auch ein IT-Sicherheitsvorfall sein. Darüber hinaus sind alle Vorfälle, bei denen keine personenbezogenen Daten betroffen sind, IT-Sicherheitsvorfälle. Auch diese unterliegen je nach Branche einer Meldepflicht (siehe Kapitel 3). Unabhängig von einer Meldepflicht an Behörden benötigen Sie eine unternehmensinterne Meldepflicht für Vorfälle. Wenn eine Nutzerin bemerkt, dass sich ihr Computer »komisch« verhält, sollte die IT informiert werden. Es gibt Länder (zum Beispiel China, Israel, Nordkorea, Russland oder USA), in denen Einreisebeamte das Recht haben, die ITGeräte (Laptop, Tablets, Smartphones, Datenträger) von Einreisenden zu durchsuchen. Sind die Daten verschlüsselt, muss der Reisende unter Umständen (in Großbritannien und den Niederlanden zum Beispiel auch im Rahmen von Ermittlungsverfahren) den Schlüssel eingeben. Es wird immer wieder von Reisenden berichtet, dass Ihnen die Geräte unter einem Vorwand vorübergehend abgenommen wurden. Es wird vermutet, das während dieser Zeit Kopien der Datenträger angefertigt werden. Ein solcher Vorfall muss im Unternehmen nach der Rückkehr meldepflichtig sein. Noch besser ist es natürlich, während einer Reise in entsprechende Länder nur »leere« Geräte (Reisenotebook) dabei zu haben. Ausgehend von den Meldepflichten haben die Behörden, an die Sie Meldungen abgeben müssen, Meldeformulare entwickelt. So ein Meldeformular ist ein guter Ausgangspunkt für die Entwicklung eines eigenen Meldeformulars und der Vorfallsdokumentation.

Sie benötigen im Unternehmen eine offene Fehlerkultur. Gerade in der Informationssicherheit müssen Sie die Beschäftigten dazu bringen, auch eigene Fehler zu melden. Dies funktioniert nur, wenn der Meldung eines Fehlers keine Sanktion folgt. Der Informationssicherheitsbeauftragte benötigt die Information zu einem Vorfall sehr zeitnah, um rasch mit den Gegenmaßnahmen zu beginnen. Wenn die Nutzerin, die den Fehler gemacht hat, mit Sanktionen aus der Meldung rechnen muss, wird sie sich eher für das Vertuschen entscheiden. Das muss auf alle Fälle vermieden werden. Die folgenden Daten sollten Sie erheben (die Auflistung orientiert sich grob am Meldeformular gemäß § 8b Absatz 4 BSIG des BSI): Informationen zum Meldenden; Informationen zum Vorfall; Beschreibung der Störung: Welche Schutzziele sind betroffen? Was ist geschehen? Wann ist die Störung aufgetreten? Wie wurde die Störung bemerkt? vermutete oder tatsächliche Ursachen: physikalische Schäden, technisches Versagen, organisatorische Ursachen, Versagen der genutzten Infrastruktur, technischer Angriff; Informationen zum informationstechnischen Angriff: Handelt es sich um einen gezielten Angriff? Vermutete Motivation des Angreifers? Informationen zum Ausfall beziehungsweise zur Beeinträchtigung: Welche Dienste oder Systeme sind betroffen?

Wer ist betroffen? Dauer der Beeinträchtigung. Im ersten Moment der internen Meldung werden Ihnen noch nicht alle Informationen vorliegen. Es ist also normal, diese Liste in der Folge noch zu ergänzen.

Angriffserkennung Wichtig ist, dass Sie im Unternehmen Angriffe möglichst zeitnah erkennen. Dazu müssen Sie ein entsprechendes Monitoring betreiben. Sogenannte Angriffserkennungssysteme helfen Ihnen dabei. Wie diese funktionieren, lernen Sie in Kapitel 24. Neben der technischen Erkennung ist es auch wichtig, Hinweise von Beschäftigten und Dritten ernst zu nehmen. Niemand macht sich die Mühe, sie auf eine Auffälligkeit aufmerksam zu machen, wenn er nicht von dieser Einschätzung überzeugt ist. Auch wenn Sie zum Beispiel mit einem CERT zusammenarbeiten, erhalten Sie immer mal wieder Hinweise auf Auffälligkeiten ihrer Systeme. Diesen Hinweisen müssen Sie nachgehen. Es ist immer schön, wenn Sie dann feststellen, dass es ein falscher Alarm war. Aber Sie dürfen solche Tipps nicht von vornherein als falschen Alarm abtun. Wenn Sie eine Beschwerde eines Dritten erhalten, dass er von Ihrem Mail-Server eine Spam-Mail bekommen hat, dann prüfen Sie das nach. Reden Sie mit der Inhaberin der E-Mail-Adresse. Dass solch ein Gespräch vorsichtig und sensibel geführt werden muss, ist Ihnen sicher bekannt. IM RFC 4142 sind einige E-Mail-Adressen festgelegt, die ein Unternehmen für jede Domain, die es besitzt, haben sollte. Haben Sie die Domains firma.de und firma.eu, so sollte es diese Adresse für beide Domains geben.

Besonders wichtig ist die Abuse-Adresse, also in unserem Beispiel [email protected] und [email protected]. An diese Adressen können Dritte ihre Beschwerden schicken. Wenn Sie ein Unternehmen auf eine Auffälligkeit seiner IT hinweisen wollen, ist die AbuseAdresse erste Wahl. Leider gibt es immer noch Unternehmen, die diese Adresse nicht eingerichtet haben. Eingehende E-Mails an diese Adressen müssen unbedingt bearbeitet werden. Und es ist ein Akt der Höflichkeit, sich bei dem Hinweisgeber zu bedanken und eine kurze Rückmeldung zu geben. Das motiviert den Hinweisgeber, sich bei der nächsten Auffälligkeit wieder zu melden. Ein kritischer Punkt sind Hinweise auf »geleakte Credentials«, das heißt auf gestohlene Benutzername-Passwort-Paare. Auf Grund der E-MailAdressen ist die Zugehörigkeit zu Ihrem Unternehmen gegeben. Diese Hinweise sind abhängig von der Quelle des Leaks nicht unkritisch. 2012 wurden Credentials der Nutzerinnen von Dropbox gestohlen. Wenn Sie die Liste Ihrer betroffenen Beschäftigten erhalten haben, dann konnten Sie sehen, welche Beschäftigten mit Ihrer dienstlichen E-Mail-Adresse ein (möglicherweise privates) Dropbox-Konto erstellt hatten. Wenn heute ein Beschäftigter sich mit der Unternehmens-E-Mail bei einem Dating-Portal anmeldet, würden Sie über ein Daten-Leak bei dem Portal davon erfahren. Der Umgang mit gestohlenen Benutzerdaten ist sensibel. Sie müssen die betroffenen Beschäftigten darüber informieren, damit diese Ihr Passwort ändern. Solange die betroffenen Beschäftigten ihr Passwort nicht geändert haben, besteht ein erhebliches Risiko für Ihr Unternehmen. Da Sie die Passwörter Ihrer Beschäftigten nicht kennen, wissen Sie nicht, ob das Unternehmenspasswort der betroffenen Person nicht dasselbe ist wie das beim Dating-Portal. Passwörter aus dem Unternehmen zu nutzen haben Sie untersagt, aber die private Nutzung der E-Mail war auch untersagt. Und daran hat sich die Beschäftigte ja offensichtlich schon mal nicht gehalten.

Security Information and Event Management (SIEM) Der Begriff SIEM, das heißt »Security Information and Event Management«, wurde erstmalig von Amrit T. Williams und Mark Nicolett im Jahr 2005 in einem Bericht von Gartner verwendet ([WN05]). Ein SIEM ermöglicht Ihnen eine automatische Verarbeitung der Protokolldaten in Echtzeit. Dazu werden anfallende Daten aus den unterschiedlichsten Systemen aufbereitet und in ein möglichst einheitliches Format konvertiert. Die aufbereiteten Daten werden in einer Datenbank gespeichert. Somit können Sie neben der Echtzeitanalyse auch historische Daten in Ihre Analysen einbeziehen. Da ein SIEM 24 Stunden am Tag und sieben Tage in der Woche arbeitet, sollten Sie auch 24/7 darauf reagieren können. Weil aber vor allem kleinere Unternehmen dies auf Grund knapper Personalressourcen nicht können, wird diese Dienstleistung gerne an ein Security Operation Center (SOC) vergeben. Ein derartiges Outsourcing setzt aber trotzdem eine entsprechende Vorbereitung im Unternehmen voraus. Sie müssen technisch in der Lage sein, die erforderlichen Protokolldaten an das SOC zu liefern. Im Falle einer Alarmierung müssen Sie ansprechbar sein und schnellstmöglich auf den Vorfall reagieren können. Ein Outsourcing an ein SOC macht keinen Sinn, wenn Sie nur an Werktagen von 9:00 bis 17:00 Uhr kontaktiert werden können. Angreifer halten sich nun mal nicht an Ihre Arbeitszeiten. Sie sollten mit einem potenziellen Anbieter offen klären, ob Ihr Unternehmen die technischen und organisatorischen Strukturen hat, die für einen sinnvollen SOC-Betrieb erforderlich sind. In einem SIEM führen Sie alle Informationen zusammen, die beim ITBetrieb und der Vorfallsuntersuchung anfallen. Dies sind: alle anfallenden Protokoll-Dateien, alle Informationen über gefundene Schwachstellen in Ihren Systemen und

alle Erkenntnisse und Daten aus der forensischen Untersuchung von Vorfällen. Da Sie die einlaufenden Daten chronologisch ordnen müssen, ist eine gute Zeitsynchronisation auf allen Systemen, die Daten liefern, zwingend erforderlich. Wenn Sie den Umfang der Protokollierung zum Beispiel aus Datenschutzgründen reduziert haben, müssen Sie sich Gedanken machen, wie Sie das Ausmaß der Protokollierung wieder erhöhen. Sie benötigen für aussagekräftige Auswertungen mindestens die folgenden Daten: die Protokolldateien der Firewallsysteme, die Protokolldateien aller Server, die sogenannten Netflow-Daten aus Ihren Routern, die Meldungen Ihrer Antivirensoftware. Die Netflow-Daten sind die Informationen wann (Uhrzeit) werden wie viele (Volumina) Daten von wo nach wo (Quell- und Ziel-IP-Adressen) mit welchen Diensten (zum Beispiel http oder https) und welchen Protokollen (zum Beispiel tcp oder udp) verschickt. Die Informationen über diese Datenströme erlauben das Erkennen von Anomalien. Gerade auch die Korrelation der Ereignisse erlaubt die Vorfallserkennung: die Antivirensoftware meldet eine Virenbefall, in den Netflow-Daten sehen Sie ein Anwachsen des Datenverkehrs von dem betroffenen Rechner und die Firewall blockiert einige Verbindungsversuche von dem Rechner. Diese automatische Korrelation ist die Stärke eines SIEM.

Dokumentation von Vorfällen und Forensik Alle Datenschutz- und IT-Sicherheitsvorfälle müssen dokumentiert werden. Die erwähnten Meldeformulare helfen dabei. Auch alle Erkenntnisse, die Sie bei der Untersuchung des Vorfalls gewinnen, sollten dokumentiert werden.

Die Informationen zum Erkenntnisgewinn zu haben ist das eine, aber wenn die Sache ernst ist, wollen Sie auch eine Strafanzeige stellen. Dann müssen die ganzen Fakten gerichtsfest erhoben und gespeichert werden. Wenn Sie das nicht regelmäßig machen, kommt es leicht zu Fehlern. Deshalb sollten Sie die forensische Analyse erfahrenen Experten überlassen. Sie kennen den Begriff Forensik sicherlich aus der Kriminalistik und genauso sorgfältig müssen Sie in der IT bei der Untersuchung eines Vorfalls sein. In einem Unternehmen wurde bei der Fehlersuche an einem PC ein Hardware-Keylogger gefunden. Dabei handelt es sich um einen kleinen »Zwischenstecker« zwischen Tastatur und Rechner, der alle Tastaturanschläge speichert. Der heimliche Einsatz eines HardwareKeyloggers ist nach § 202a StGB als »Ausspähen von Daten« strafbar. Der IT-Mitarbeiter entfernte den Keylogger und zeigte ihn seinen Kollegen. Danach war eine Untersuchung des Key-Loggers auf Fingerabdrücke durch die Polizei und eine Identifizierung des Täters auf diesem Wege nicht mehr möglich. Auch bei der Untersuchung von digitalen Spuren muss man auf viele Kleinigkeiten achten. Das Fachwissen dafür hat nicht jeder ITMitarbeiter. Wenn Sie keinen IT-Forensiker im Unternehmen haben, ziehen Sie rechtzeitig externe Fachleute hinzu. Dokumentieren Sie alles. Fotografieren Sie den Bildschirm des betroffenen Rechners, damit klar ist, was dort zu sehen war. Sichern Sie Datenträger in verschlossenen Umschlägen, sodass eindeutig klar ist, dass niemand sie verändern konnte. Zu so einer Dokumentation gehört dann auch, den genauen Zeitpunkt (minutengenau) und den Bearbeiter festzuhalten. Idealerweise haben Sie eine Checkliste für die IT, wie in solchen Fällen vorzugehen ist.

Sharing von Threat-Informationen Informationen über Sicherheitsvorfälle und die Erkenntnisse aus den Analysen der Vorfälle teilt man sinnvollerweise in seiner Community (zum Beispiel Branchenverbänden), damit auch andere davon profitieren können. Dieser Informationsaustausch ist losgelöst von Meldepflichten und gegebenenfalls Strafanzeigen gegen Täter. Es geht um die gegenseitige Unterstützung und Warnung. Ein Einzelkämpfer hat es sehr viel schwerer als jemand, der sich in einer Community austauschen kann. Es fällt vielen schwer, sich auf einen derartigen offen Austausch einzulassen, da die Sorge besteht, sich selber oder sein Unternehmen in ein schlechtes Licht zu stellen. Deshalb ist es üblich, dass der Austausch unter einer geregelten Verschwiegenheit stattfindet. Die formalsten Regeln sind die staatlichen Vorschriften zur Geheimhaltung. Nach § 4 Abs. 2 des Sicherheitsüberprüfungsgesetzes (SÜG) werden in Deutschland »Verschlusssachen entsprechend ihrer Schutzbedürftigkeit von einer amtlichen Stelle des Bundes oder auf deren Veranlassung in folgende Geheimhaltungsgrade eingestuft: 1. STRENG GEHEIM, wenn die Kenntnisnahme durch Unbefugte den Bestand oder lebenswichtige Interessen der Bundesrepublik Deutschland oder eines ihrer Länder gefährden kann, 2. GEHEIM, wenn die Kenntnisnahme durch Unbefugte die Sicherheit der Bundesrepublik Deutschland oder eines ihrer Länder gefährden oder ihren Interessen schweren Schaden zufügen kann, 3. VS-VERTRAULICH, wenn die Kenntnisnahme durch Unbefugte für die Interessen der Bundesrepublik Deutschland oder eines ihrer Länder schädlich sein kann, 4. VS-NUR FÜR DEN DIENSTGEBRAUCH, wenn die Kenntnisnahme durch Unbefugte für die Interessen der Bundesrepublik Deutschland oder eines ihrer Länder nachteilig sein kann.« Den Umgang mit Verschlusssachen regelt die »Allgemeine Verwaltungsvorschrift zum materiellen Geheimschutz«

(Verschlusssachenanweisung – VSA) vom 10. August 2018 (GMBl. 2018 Nr. 44–47, S. 826). Zugang zu einer Verschlusssache erhält eine Person nur, wenn die Kenntnis der Information erforderlich ist und wenn sie eine formale Freigabe dazu hat. Für die unterste Stufe (VS-NfD) reichen eine förmliche Verpflichtung und die Aushändigung eines offiziellen Merkblatts. Für die drei anderen Stufen ist eine formale Sicherheitsüberprüfung der zugriffsberechtigten Personen nach dem SÜG erforderlich. Vor der Bearbeitung oder Speicherung von als VS-NfD eingestuften Dokumenten ist sicherzustellen, dass das Gerät oder das interne Netzwerk nicht unmittelbar (zum Beispiel ohne Schutz durch eine Firewall) mit dem Internet verbunden ist, sofern nicht weitergehende Maßnahmen ergriffen worden sind. Ähnliche Geheimhaltungsstufen existieren auch für Verschlusssachen internationaler Organisationen wie der EU oder der NATO sowie auch von anderen Staaten. Die USA kennen die unterste Geheimhaltungsstufe nicht, sondern haben nur die Stufen CONFIDENTIAL, SECRET und TOP SECRET. Beim Abbilden der Regelungen wird deshalb beim Information Sharing zwischen Staaten und mit internationalen Organisationen die unterste Stufe auf die nächsthöhere Stufe abgebildet. Die staatlichen Vorschriften sind für Unternehmen ungeeignet, da zu formal. Sie sind für Unternehmen nur dann relevant, wenn diese Unternehmen mit staatlichen Stellen in den Anwendungsbereichen der Geheimschutzvorschriften zusammenarbeiten. Deshalb haben sich außerhalb des Geheimschutzbereichs etwas weniger formale Regeln etabliert. Für das Information Sharing zwischen Unternehmen und zum Teil auch mit staatlichen Stellen bietet es sich an, auf solche etablierten Regeln zurückzugreifen, die auch formal, aber praktikabler sind. Das Traffic Light Protocol (TLP) ist ein vom britischen National Infrastructure Security Coordination Centre (NISCC) zu Beginn dieses Jahrhunderts entworfenes Protokoll, welches die Weitergabe von nichtöffentlichen und vertraulichen Informationen unterhalb der staatlichen Geheimhaltungsvorschriften innerhalb eines Informationsverbunds regelt. Die vom Ersteller eines Dokuments adressierten Empfänger

haben sich im Vorfeld schriftlich verpflichtet, das TLP zu beachten und das Dokument entsprechend den »Ausführungsbestimmungen zum sicheren Informationsaustausch mit TLP« zu verarbeiten, aufzubewahren, weiterzugeben und zu vernichten. Sollte sich jemand nicht an die Regelungen halten, wird er in dem Informationsverbund keine weiteren Informationen erhalten. Das BSI definiert diese Stufen in seinem TLP-Merkblatt von 2018 (Version 17-11) wie folgt: »TLP:WHITE: Unbegrenzte Weitergabe Abgesehen von urheberrechtlichen Aspekten dürfen Informationen der Stufe TLP:WHITE ohne Einschränkungen frei weitergegeben werden. TLP:GREEN: Organisationsübergreifende Weitergabe Informationen dieser Stufe dürfen innerhalb der Organisationen und an deren Partner frei weitergegeben werden. Die Informationen dürfen jedoch nicht veröffentlicht werden. TLP:AMBER: Eingeschränkte interne und organisationsübergreifende Verteilung Informationen dieser Stufe darf der Empfänger innerhalb seiner Organisation auf Basis »Kenntnis nur wenn nötig« weitergeben. Der Empfänger darf die Informationen zudem an Dritte weitergeben, soweit diese die Informationen zum Schutz des Empfängers oder zur Schadensreduktion beim Empfänger benötigen. Hierfür muss er sicherstellen, dass die »Dritten« das TLP kennen und die damit verbundenen Regeln einhalten. Der Informationsersteller kann weitergehende oder zusätzliche Einschränkungen der Informationsweitergabe festlegen. Diese müssen eingehalten werden. TLP:RED: Persönlich, nur für benannte Empfänger Informationen dieser Stufe sind auf den Kreis der Anwesenden in einer Besprechung oder Video-/Audiokonferenz beziehungsweise auf die direkten Empfänger bei schriftlicher Korrespondenz

beschränkt. Eine Weitergabe ist untersagt. Meistens werden TLP:RED-Informationen mündlich oder persönlich übergeben.« Alle Schriftstücke mit einer TLP-Klassifizierung müssen diese Klassifizierung auf jeder Seite aufweisen. Abbildung 15.1 zeigt als Beispiel den Anfang einer Schwachstellenwarnung des BSI. Bei der mündlichen Weitergabe von TLP-klassifizierten Informationen ab der Stufe »TLP:GREEN« dürfen nur entsprechend verpflichtete Personen im Raum anwesend sein.

Abbildung 15.1: Der Anfang eines TLP:WHITE-Dokuments des BSI mit einer Warnung vor einer Schwachstelle. Alle Warnungen des BSI verwenden diesen Aufbau. (Quelle: BSI)

Dokumente der Stufen TLP:AMBER und TLP:RED müssen nach Stand der Technik verschlüsselt gespeichert oder in einem verschlossenen Behältnis aufbewahrt werden. Bei Dateien empfiehlt sich das PDFFormat mit einem Passwortschutz. Das Passwort muss entsprechend sicher gewählt werden. Die TLP-Dokumentation wird derzeit vom CERT-Verbund FIRST (https://www.first.org) gepflegt und im Austausch von Informationen im internationalen CERT-Verbund eingesetzt. Auch das BSI verwendet diese Protokoll sowohl im Informationsaustausch im KRITIS-Bereich als auch innerhalb der Allianz für Cybersicherheit. Es empfiehlt sich, alle IT-sicherheitsrelevanten Dokumente nach dem Traffic Light Protocol zu klassifizieren. Dies Empfehlung gilt sowohl innerhalb eines Unternehmens oder Unternehmensverbunds als auch in unternehmensübergreifenden Arbeitskreisen. Auch die ISO 27010 »Informationssicherheitsmanagement für sektorund organisationsübergreifende Kommunikation« beschäftigt sich mit der organisationsübergreifenden Informationsweitergabe. Sie bezieht sich im Anhang C auf das Traffic Light Protocol. Die Chatham House Rule wurde 1927 vom Royal Institute of International Affairs in Großbritannien veröffentlicht und 1992 und 2002 überarbeitet. Der Name leitet sich vom Sitz des Instituts im Chatham House ab. Die Regel wird weltweit verwendet. Sie soll offene Gespräche ermöglichen, ohne dass das Gesagte gegen die Sprecherin verwendet werden kann: »When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.« ([CHR]). Die Teilnehmer müssen vor dem Beginn des Gesprächs über die Anwendung der Regel informiert werden (typische Bezeichnung: vertrauliches Hintergrundgespräch). Die Inhalte der Gespräche dürfen frei verwendet werden, aber die Identität und die Zugehörigkeit der anderen Teilnehmer bleiben vertraulich.

Gerade in unternehmensübergreifenden Arbeitskreisen ist die Verwendung dieser Regel sehr empfehlenswert, wenn es um den offenen Austausch von IT-Sicherheitsinformationen geht. Es ist allerdings erforderlich, dass ein Verstoß gegen die Regeln sanktioniert wird. Die Art der Sanktionierung steht im Ermessen des jeweiligen Veranstalters oder Organisators. Ein übliches Vorgehen ist, dass derjenige, der die Regeln missachtet, von zukünftigen Treffen ausgeschlossen wird. Ein wichtiger Aspekt ist das gegenseitige Vertrauen der beteiligten Parteien. Üblich ist, dass jemand Neues über einen »Trusted Introducer« eingeführt wird. Da sich Vertrauen, wie im normalen Leben, auch hier nur langsam aufbaut, bedarf es häufig einer gewissen Zeit, bis der vertrauensvolle Austausch funktioniert. Die formalen Regeln helfen beim Umgang mit Informationen, sodass die Teilnehmer wissen, was sie mit den Informationen tun dürfen. Die Regeln helfen nicht beim Aufbau von Vertrauen. Die Arbeit wird Ihnen erheblich vereinfacht, wenn Sie Ihre Vorfallsinformation in einer Anwendung dokumentieren, die gleichzeitig den Austausch mit anderen unterstützt. Eine häufig eingesetzte Software ist MISP (Malware Information Sharing Projekt). Heute heißt das Projekt »Open Source Threat Intelligence Platform«. Das Programm wird vom luxemburgischen CERT (CIRCL) und der EU finanziert und von vielen Freiwilligen entwickelt. MISP ist gleichzeitig auch ein Standard-Datenformat zum Austausch von Vorfalls- und SchadsoftwareInformationen. Mittlerweile hat sich MISP zu einem Programm entwickelt, in dem Sicherheitsvorfälle umfassend dokumentiert werden können. Sie können damit genau festlegen, welche Information mit wem automatisiert geteilt wird. Nach eigenen Angaben wird MISP von mehr als 6000 Institutionen auf der Welt genutzt, darunter die NATO, das BSI und zahlreiche deutsche CERTs. Seine Flexibilität konnte MISP beweisen, als es in der COVID-19Pandemie auch zum Austausch von medizinischen Informationen sowie

über Bedrohungen durch COVID-19-bezogene Cyberkriminalität und Falschinformationen genutzt wurde.

Kapitel 16

Awareness und Beschäftigte IN DIESEM KAPITEL Awareness ist Erziehung Aufbau einer Awareness-Kampagne Reden Sie darüber!

Sie alle kennen den Spruch »Wie sag' ich's meinem Kinde?«. Und genau wie in dem Film von 1971 geht es bei der IT-Sicherheits-Awareness darum, ein heikles Thema an eine sensible Zielgruppe zu vermitteln. Das Wort »Awareness« bedeutet auf Deutsch so viel wie »Bewusstsein«. Das ist definitiv etwas anderes – vielleicht auch etwas mehr – als »Wissen«. Awareness ist für die IT-Sicherheit von zentraler Bedeutung, da die IT von Menschen bedient und genutzt wird. Der Mensch ist eine wesentliche Schwachstelle in der IT. Er macht Fehler. Das können wir nicht absolut verhindern. Fehlbedienungen aus Unkenntnis lassen sich reduzieren, indem wir die Unkenntnis beseitigen, also die Beschäftigen in der Nutzung der IT schulen. Die Beschäftigen, die nicht in der IT arbeiten, haben nicht immer ein tiefes IT-Verständnis. Für diese Beschäftigten ist die IT ein Mittel zur effizienten Aufgabenerfüllung. Eine Buchhalterin oder ein Einkäufer wollen ihren Job machen. Deren primäres Interesse – und da sind sie auch Fachleute – ist ihr Fachgebiet. Irgendwie müssen wir sie überreden, sich für Informationssicherheit zu interessieren, in diesem für sie fremden Fachgebiet etwas zu lernen und das Gelernte dann auch anzuwenden. Eigentlich wollen Sie ja sogar noch einen Schritt weiter gehen. Sie wollen das Bewusstsein, die innere Einstellung zur Informationssicherheit verändern. Sie wollen nicht, dass die

Beschäftigten das Gelernte gezielt und bewusst anwenden. Sie wollen das Bewusstsein so verändern, dass die Beschäftigen die Informationssicherheitsregeln ohne darüber nachzudenken, also automatisch und unbewusst anwenden. Das ist eine große Aufgabe. Wenn Sie darüber nachdenken, hat das viel mit Erziehung zu tun. Kinder erziehen und Informationssicherheits-Awareness schaffen sind sehr ähnliche Prozesse. Ein wichtiger Punkt bei der Erziehung ist das Vorleben. Sie können Kindern kein Verhalten beibringen, dass Sie nicht selbst zeigen. Wenn Sie an der Fußgängerampel bei Rot nicht stehen bleiben, wie sollen Ihre Kinder lernen, dass sie dort stehen bleiben und auf Grün warten sollen? Das ist im Unternehmen auch so. Wenn die Führungsriege die Informationssicherheit ignoriert, werden die Beschäftigen deren Erforderlichkeit wohl kaum begreifen. Der erste Schritt für Sie ist es, Ihre Unternehmensleitung zum Vorleben der Sicherheitsmaßnahmen zu bewegen. Das ist oft eine echte Herausforderung. Für alle Maßnahmen gibt es einen wichtigen Grundsatz: Machen Sie die Beschäftigten betroffen, aber blamieren Sie die Beschäftigten nicht. Zeigen Sie ihnen zum Beispiel, wie einfach ein simples Passwort geknackt werden kann. Aber führen Sie sie nicht vor, indem Sie ihnen nachweisen, dass sie ein schlechtes Passwort haben. Nutzen Sie für Awareness-Maßnahmen »Gedenktage«. Das sorgt für einen Verstärkungseffekt, den Sie kostenlos mitnehmen können. Im Idealfall wird der Gedenktag auch in den Abendnachrichten angesprochen und Sie erzielen einen gewissen Nachbrennereffekt. Die folgenden Gedenktage sind zum Beispiel geeignet: 28. Januar Europäischer Datenschutztag (Europa) 1. Februar Ändere Dein Passwort Tag (Welt) im Februar Safer Internet Day (Europa) 31. März

World Backup Day

Oktober

European Cyber Security Month

Häufig bieten Verbände oder Organisationen Awareness-Material zu diesen Gedenktagen an. Die ENISA stellt auf ihrer Webseite https://www.enisa.europa.eu/media/multimedia/material/ma terial-de

kurze Videos und Poster für Awareness-Maßnahmen zur

Verfügung. Die NIST SP 800-50 »Building an Information Technology Security Awareness and Training Program« aus dem Jahr 2003 und SP 800-16 »Information Technology Security Training Requirements: a Role- and Performance-Based Model« aus dem Jahr 1998 beschäftigen sich mit Fragen der Planung und Durchführung von Awareness- und Trainingsmaßnahmen. Eine Awareness-Kampagne besteht aus drei Abschnitten [Fox03]: Aufmerksamkeit und Interesse erwecken, Wissen vermitteln und Einstellung verändern, Verstärkung und Vertiefung des Gelernten, langfristige Verhaltensänderung. Ein paar Vorüberlegungen müssen Sie anstellen. Wer ist Ihre Zielgruppe? Je zielgruppengerechter die Ansprache erfolgt, desto besser erreichen Sie die Zielgruppe. Wer führt die Kampagnen durch? Die ITAbteilung, der Informationssicherheitsbeauftragte? Das sollte vorab geklärt werden. Welches Budget steht zur Verfügung? Danach richtet sich, was Sie alles tun können. Welche Kommunikationsmittel wollen Sie nutzen? Live-Vorträge, Videovorträge, Podcasts, eLearning, Flyer, Poster, alles ist möglich, aber die Ansprache der Beschäftigten ist nicht immer perfekt. Denken Sie auch an das benötigte Zeitfenster. Mehrere kurze Podcasts erreichen vielleicht mehr Personen als ein 60-minütiger Vortrag. Aufmerksamkeit und Interesse wecken ist noch kein Lernen. Sie wollen den Fokus der Zielgruppe auf das Thema lenken. Da hilft Ihnen oft ein bisschen Show, wie zum Beispiel ein Live-Hacking-Event. Das Thema

darf aber nicht im Showeffekt untergehen. Auch ein Bericht in einem unternehmensweiten Kommunikationsmedium, in dem Sie den letzten IT-Sicherheitsvorfall erklären, erzeugt Betroffenheit. Das »Bei uns passiert so etwas doch nicht!« wird damit durchbrochen. Bitte klären Sie vorab mit der Unternehmensleitung, ob diese eine solche interne Darstellung von Vorfällen mitträgt. Danach beginnt die Phase der Wissensvermittlung. Dazu können Sie, falls vorhanden, das eLearning-System einsetzen. Das erlaubt es, die Teilnahme zu dokumentieren und unter Umständen sogar eine Lernzielkontrolle durchzuführen. Aber auch klassische Fortbildungsseminare sind ein gute (aber aufwendige) Möglichkeit. In alle Schulungen zur IT-Nutzung oder Software-Anwendung gehört ein Block zur Informationssicherheit. Es macht keinen Sinn, zum Beispiel eine Schulung zum Umgang mit E-Mail zu machen, ohne über Informationssicherheit und Datenschutz bei der E-Mail-Nutzung zu sprechen (Themen: E-Mail-Verschlüsselung, digitale Signatur und Phishing). In der Phase der Vertiefung und der langfristigen Verhaltensänderung müssen Sie die Themen präsent halten. Dabei hilft eine ständige Präsenz, zum Beispiel durch Poster. Am besten ist aber eine Maßnahme, bei der die Beschäftigen aktiv werden müssen, zum Beispiel ein Workshop mit intensiven Diskussionen oder auch mal ein Phishing-Test Test. Aber, wie schon gesagt, blamieren und brüskieren Sie die Beschäftigten nicht. In Tabelle 16.1 finden Sie nochmal ein kurze Zusammenfassung der Phasen. Aufmerksamkeit Frage Lernziel

Medium

Zeitskala

Wissenvermittlung Bewusstsein

Was?

Wie?

Warum?

Wahrnehmung,

Fachwissen,

Verständnis,

Problembewusstsein

Handlungswissen

Handeln

Vortrag, Flyer,

eLearning

Workshop,

Live-Hacking

Seminar

Phishing-Test

kurzfristig

mittelfristig

langfristig

Tabelle 16.1: Die drei Phasen einer Awareness-Kampagne. (nach SP 800-16)

Die NIST Publikation SP 800-16 zitiert ein chinesisches Sprichwort: »Ich höre etwas und ich vergesse es wieder; ich sehe etwas und ich erinnere mich daran; ich tue etwas und ich verstehe es.« Bringen Sie Ihre Beschäftigten zum verständigen Handeln! Die Marketingabteilung kümmert sich um das Marketing für die Produkte Ihres Unternehmens. Die wissen, wie ein Produkt beworben und dann verkauft wird. Lassen Sie sich von diesen Experten eine Marketingkampagne für das Produkt »Informationssicherheit« entwerfen. Wenn Ihr Unternehmen ein starkes Markenbewusstsein hat, passt die Kampagne dann genau dazu. Vielleicht macht das den Marketingspezialisten ja sogar Spaß und es wird eine längere Zusammenarbeit daraus. Planen Sie für eine nachhaltige Awareness-Kampagne mehrere Jahre ein. Beginnen Sie bei neuen Beschäftigten im Onboarding-Prozess. Im verpflichtenden eLearning-Block für neue Beschäftigte muss der Informationssicherheitsblock enthalten sein. Gleiches gilt für den Einführungstag für neue Beschäftigte. Auch dort brauchen Sie Ihren Zeitslot für die Informationssicherheit. Machen Sie allen Neuen klar: Informationssicherheit ist Teil der Unternehmenskultur. Klinken Sie sich in die internen Weiterbildungsveranstaltungen der Fachabteilungen ein. Gerade dort können Sie Ihre Botschaften zielgruppengerecht vermitteln. Wenn die Beschäftigten das Gelernte aktiv und selbstverständlich anwenden, dann haben Sie Ihr Ziel erreicht. Da es ein anspruchsvolles Ziel ist, verzweifeln Sie nicht, wenn es lange dauert. Nach außen können Sie eine erfolgreiche Awareness-Kampagne auch imagefördernd präsentieren. Zeigen Sie Ihren Kunden, wie toll Sie in der Informationssicherheit sind. Gemäß dem Motto »Tue Gutes und rede darüber« müssen Sie Ihre Erfolge auf diesem Gebiet nicht verstecken. Sie reden nicht nur über Informationssicherheit, sondern Sie tun aktiv etwas dafür.

Teil IV

Bausteine der technischen ITSicherheit

IN DIESEM TEIL … Die technischen Maßnahmen der IT-Sicherheit wenden einige grundlegende Bausteine in vielen Variationen an. In diesem Teil lernen Sie die wichtigsten dieser Bausteine kennen. Den größten Teil nimmt das Kapitel über die Grundlagen der Verschlüsselung ein, denn diese wird in den unterschiedlichsten Varianten bei technischen Maßnahmen eingesetzt. Da müssen Sie sich mit einigen Grundbegriffen vertraut machen. Ganz ohne Mathematik geht es nicht, aber wir haben sie auf das Minimum reduziert. Wir werden uns auch mit zukünftigen Entwicklungen wie homomorpher Verschlüsselung und Post-Quantenkryptografie beschäftigen. Ein weiter wichtiger – aber nicht ganz unumstrittener – Baustein sind die biometrischen Verfahren. Sie werden lernen, was Biometrie ist, wo die Probleme stecken und wo man sie sinnvoll einsetzen kann. Zum Ende des Teils beschäftigen wir uns noch mit ganz kleinen Computern: Chipkarten und USB-Token. Diese »Nanorechner« wenden auch wieder Kryptografie an.

Kapitel 17

Grundlagen der Verschlüsselung IN DIESEM KAPITEL lernen wir die verschiedenen Verschlüsselungsverfahren kennen Das organisatorische Umfeld der Verschlüsselung Verschlüsselung der Zukunft

Das Bedürfnis, eine Nachricht an eine andere Person zu senden, ohne dass Unberechtigte diese Nachricht mitlesen oder verändern können, gibt es schon seit vielen Jahrhunderten. Etwa 400 v. Chr. gab es mit der »Skytale« von Sparta ein erstes mechanisches Verschlüsselungsverfahren. Ein Papierstreifen wurde um einen Stab gewickelt und entlang des Stabes beschrieben. Nach dem Abwickeln des Papierstreifens war der Text nicht mehr zu lesen, da die Reihenfolge der Buchstaben vertauscht (permutiert) wurde. Der Durchmesser des Stabes ist der Schlüssel. Nur wenn der Stab den richtigen Durchmesser hat, stehen nach dem erneuten Aufwickeln die Buchstaben wieder »richtig« nebeneinander. In der Sprache der modernen Kryptografie handelt es sich um eine Permutationsverschlüsselung: die Buchstaben werden nicht ersetzt, sondern nur vertauscht. Julius Caesar (100–44 v. Chr.) verwendete ein grundsätzlich anderes Verschlüsselungsverfahren, bei dem jeder Buchstabe durch einen anderen Buchstaben ersetzt (substituiert) wurde. Dazu schrieb Caesar unter die 26 Buchstaben des Alphabets ein um drei Positionen verschobenes Alphabet. Der Schlüssel von Caesar war die Zahl drei. Für das Verschlüsseln und das Entschlüsseln wurden unterschiedliche Tabellen verwendet: war zum Verschlüsseln die Verschiebung drei Positionen nach rechts, so waren es zum Entschlüsseln drei Positionen nach links. Diese Substitutionsverschlüsselung ist heute als Caesar-Verschlüsselung oder Caesar-Chiffre bekannt.

Caesar verschlüsselte einen Text, indem er eine Verschlüsselungstabelle aus zwei verschobenen Alphabeten benutzte. Caesar benutzte den Schlüssel 3, das heißt, die beiden Alphabete waren um drei Positionen verschoben:

Aus heutiger Sicht ist dieser Algorithmus nicht sicher, da er die statistischen Eigenschaften des Textes nicht ändert. Im Deutschen ist der häufigste Buchstabe ein . Verschlüsselt man einen Text mit der Caesar-Chiffre, ist im verschlüsselten Text der häufigste Buchstabe ein . Überlegen Sie warum! Durch schlichtes Zählen der Buchstabenhäufigkeit lässt sich der Schlüssel bestimmen, da der häufigste Buchstabe des verschlüsselten Textes in der Verschlüsselungstabelle unter dem stehen muss. Jetzt haben Sie schon eine erste Kryptoanalyse durchgeführt. Nachdem Caesar tot war, nutzte sein Nachfolger Augustus einen – seiner Meinung nach – sichereren Schlüssel, nämlich vier. Ordnet man den Buchstaben A, B, …, Z die Zahlen 0, 1, … , 25 zu, kann man die Verschlüsselung in moderner Notation auch als schreiben. sind die Klartextbuchstaben, Buchstaben oder Geheimtextbuchstaben und bei Caesar 3, bei Augustus 4.

die verschlüsselten ist der Schlüssel, also

Ein wichtiger Meilenstein in der Geschichte der Kryptografie ist die im Januar 1883 erschienene Arbeit »La Cryptographie Militaire« von Auguste Kerckhoffs von Nieuwenhof (1835–1903). Er stellt in dieser Arbeit sechs Prinzipien (Anforderungen) für Verschlüsselungssysteme auf (siehe Tabelle 17.1). Diese Anforderungen wurden vor dem Hintergrund mechanischer Kryptogeräte, militärischer Anwendungen und Kommunikation per Telegrafie aufgestellt. Sie gelten jedoch

uneingeschränkt bis heute, sofern man die Bezüge zur zeitgenössischen Technik anpasst und aktualisiert. Als »Kerckhoffs' Prinzip« gilt dabei die zweite Anforderung, aber auch die anderen fünf sind immer noch beachtenswert. Gegen Ende des 19. Jahrhunderts begann die Kryptografie, eine immer größere Rolle für die vertrauliche militärische und diplomatische Kommunikation zu spielen. Dementsprechend entwickelte sich auch die Kryptoanalyse, das »Knacken« von Verschlüsselungen, zu einer wichtigen Disziplin. Die moderne Kryptografie beginnt im Jahr 1949 mit dem Artikel »Communication Theory of Secrecy Systems« von Claude Shannon (1916–2001). Shannon entwickelte hier die mathematischen Grundlagen moderner kryptografischer Systeme. Das allgemeine Kommunikationsmodell bei einer verschlüsselten Nachricht ist in Abbildung 17.1 dargestellt: Der Absender verschlüsselt einen Text und verschickt dann den verschlüsselten Text über einen unsicheren Kanal. Der Schlüssel wird über einen anderen, sicheren Kanal ausgetauscht. Der Angreifer bestimmt im Rahmen seiner Kryptoanalyse einen Schlüssel und entschlüsselt damit eine Nachricht . Er kann sich nicht sicher sein, dass ist. Entsprechend weiß er auch nicht, ob die entschlüsselte Nachricht die tatsächliche Nachricht ist. Stellen wir uns einen Geheimagenten vor, der aus seiner Geheimdienstzentrale (Entschlüsselungsstelle) seine Schlüssel sicher zum Einsatzort (Verschlüsselungsstelle) mitnehmen kann, aber der danach nur noch über einen unsicheren Kanal vom Einsatzort zur Zentrale verfügt, um seine Spionageergebnisse nach Hause zu schicken. Dann müssten die Schlüssel in der Geheimdienstzentrale erzeugt werden. Original text Le système doit être matériellement, sinon 1. mathématiquement, indéchiffrable;

Übersetzung

Moderne Interpretation

Das System muss materiell, wenn nicht sogar mathematisch, unentzifferbar sein;

Das System muss mindestens praktisch sicher sein.

Original text

Übersetzung

Es darf keine Geheimhaltung Il faut qu'il n'exige pas le erfordern, und es muss dem secret, et qu'il puisse sans 2. Feind ohne inconvénient tomber entre Unannehmlichkeiten in die les mains de l'ennemi; Hände fallen können; La clef doit pouvoir en être communiquée et retenue sans le secours de notes 3. écrites, et être changée ou modifiée au gré des correspondants;

Der Schlüssel muss ohne Hilfe von schriftlichen Notizen kommuniziert und beibehalten werden können und nach dem Ermessen der Korrespondenten geändert oder modifiziert werden;

Moderne Interpretation Die Sicherheit hängt nur von der Geheimhaltung des Schlüssels ab und nicht von der Geheimhaltung des Algorithmus. Der Schlüssel kann jederzeit von den Nutzern geändert werden, und man kann ihn sich merken.

Il faut qu'il soit applicable à Es muss auf den 4. la correspondance telegrafischen Schriftverkehr télégraphique; anwendbar sein;

Die Verfahren müssen bei den aktuellen technischen Kommunikationsverfahren einsetzbar sein.

Il faut qu'il soit portatif, et que son maniement ou son 5. fonctionnement n'exige pas le concours de plusieurs personnes;

Es muss tragbar sein, und seine Handhabung oder Bedienung darf nicht die Hilfe mehrerer Personen erfordern;

Das System ist einfach zu implementieren und in gängige Systeme integrierbar.

Enfin, il est nécessaire, vu les circonstances qui en commandent l'application, que le système soit d'un 6. usage facile, ne demandant ni tension d'esprit, ni la connaissance d'une longue série de règles à observer.

Schließlich ist es angesichts der Umstände, die seine Anwendung erfordern, notwendig, dass das System einfach zu handhaben ist und weder geistige Anstrengung noch die Kenntnis einer langen Reihe von zu beachtenden Regeln erfordert.

Die Benutzung des Systems muss auch für IT-Laien ohne Weiteres möglich sein, ohne dass es einer umfangreichen Schulung bedarf.

Tabelle 17.1: Die sechs Prinzipien (Anforderungen) des Auguste Kerckhoffs von Nieuwenhof für ein Verschlüsselungssystem. (La Cryptographie Militaire, 1883)

Shannon unterstellte in seiner Arbeit, dass der Schlüssel bei der Stelle, die verschlüsselt, generiert wird. Damit ist die Richtung des sicheren Kanals von der Verschlüsselungsstelle zur Entschlüsselungsstelle. Wir werden im Abschnitt »Hybride Verschlüsselung« sehen, dass das bei diesem Verfahren exakt so ist. Es ist aber auch möglich, dass der sichere Kanal nur in der umgekehrten Richtung existiert, zum Beispiel, wenn ein

Geheimagent den Schlüssel aus der Geheimdienstzentrale mit zu seinem Spionageort nimmt. Dann wird der Schlüssel bei der entschlüsselnden Stelle erzeugt, da der sichere Kanal nur in einer Richtung – von der Entschlüsselungsstelle zur Verschlüsselungsstelle – existiert. Dies ist in Abbildung 17.1 durch die alternative, ausgegraute »Schlüsselquelle« dargestellt.

Abbildung 17.1: Kommunikationsmodell eines symmetrischen Verschlüsselungssystem. = Nachricht, = verschlüsselte Nachricht, = Schlüssel. (Shannon, 1949)

Kryptografie galt viele Jahre als eine Spezialität der Geheimdienste und auch heute noch kämpft man beim Einsatz kryptografischer Verfahren manchmal gegen das Vorurteil »das ist doch ein Relikt aus dem Kalten Krieg und nicht mehr zeitgemäß«. Heute gilt jedoch mehr als zuvor, dass Kryptografie ein Teilgebiet der modernen Mathematik und Informatik und damit ein Gegenstand offener freiheitlicher wissenschaftlicher Forschung ist. Das Grundgesetz der Bundesrepublik Deutschland schützt sowohl das Briefgeheimnis als auch das Post- und Fernmeldegeheimnis. Beide Geheimnisse haben die Aufgabe, die Kommunikationsinhalte der Bürgerinnen und Bürger in unserem Staat zu schützen. Bisher mussten Sie darauf vertrauen, dass der Staat die Vertraulichkeit der Kommunikation seiner Bürger durch organisatorische Maßnahmen (Gesetze) sicherstellte. Die Kryptografie stellt jedoch Methoden zur Verfügung, die erstmals (durch die freie Verfügbarkeit von benutzbarer Verschlüsselungssoftware für die Bürgerinnen und Bürger) die Möglichkeit bieten, dass Sie durch eigene technische Maßnahmen (Verschlüsseln) in eigener Verantwortung

Ihr Kommunikationsgeheimnis sicherstellen können. Sie müssen sich nicht mehr auf den Staat verlassen. Die zivile Nutzung und Anwendung der Kryptografie hilft damit den Bürgerinnen und Bürgern, ihre verfassungsmäßigen Grundfreiheiten zu sichern. Da sichere Verschlüsselung verhindert, dass staatliche Stellen die Kommunikationsinhalte der Bürgerinnen und Bürger sehen, können auch die Strafverfolgungsbehörden die Kommunikation von Straftätern nicht mehr lesen. Deshalb wird in der Bundesrepublik Deutschland – wie in andern Ländern auch – immer mal wieder diskutiert, ob der Staat den Einsatz von Kryptografie einschränken soll (Kryptodebatte oder Crypto Wars). Ende 2020 beschloss der Rat der Europäischen Union die Entschließung »Sicherheit durch Verschlüsselung und Sicherheit trotz Verschlüsselung« (Ratsdokument 13084/1/20), in der Verschlüsselungsverfahren gefordert werden, die gegen bösartigen Angriffe schützen, aber staatlichen Stellen unproblematischen Zugriff auf die verschlüsselten Inhalte ermöglichen. Eine Forderung, die ohne ernsthafte Schwächung der Verschlüsselung, nicht erfüllbar ist.

Nur das One-Time-Pad ist wirklich sicher Im Jahr 1882 schlug Frank Miller (1842–1925) das One-Time-Pad zur Verschlüsselung vor. Der Vorschlag wurde vergessen und das Verfahren erst 1917 von Gilbert Vernam (1890–1960) wiederentdeckt und patentiert. Das One-Time-Pad ist das einzige Verschlüsselungsverfahren, das mathematisch beweisbar sicher ist. Der Beweis wurde 1949 von Claude Shannon geführt. Wir können das One-Time-Pad als

schreiben. Das ist genau die Caesar-Verschlüsselung, nur dass sich der Schlüsselbuchstabe jedes Mal ändert. Wenn der Schlüssel (das heißt die komplette Buchstabenfolge) wirklich zufällig ist und nie zweimal verwendet wird, ist das Verfahren sicher. Der Nachteil ist, dass der Schlüssel genau so lang ist wie der Klartext. Schauen wir uns ein Beispiel an: C = WMYCFBRNCGRDVNYEHORBO

K = WZSLXWMFQUDMPJLYQOXXB M = ANGRIFFIMMORGENGRAUEN Aus demselben Geheimtext kann mit anderen Schlüsseln ein anderer Klartext entschlüsselt werden. Sie können nicht entscheiden, welcher Schlüssel und damit welcher Klartext der richtige ist. Hier als Beispiel zwei weitere Entschlüsselungen desselben Geheimtexts: C   = WMYCFBRNCGRDVNYEHORBO K' = WZSLXWMTQONBOVEXQPNUB M' = ANGRIFFUMSECHSUHRZEHN oder C   = WMYCFBRNCGRDVNYEHORBO K" = AEOUQXOFCBJQSJLIZXLHV M" = WIKIPEDIAFINDENWIRGUT Wenn wir heute mit binären Werten arbeiten und die Bits verknüpfen, schreiben wir das One-Time-Pad als

Das steht für die Operation Schlüssel wird mit dem Klartext per

und das ist die bitweise Addition modulo zwei. Der verknüpft, um den Geheimtext zu erhalten.

Symmetrische Verschlüsselung Die sogenannten »symmetrischen Verschlüsselungsverfahren« (siehe Abbildung 17.2) nutzen für Verschlüsselung und Entschlüsselung den gleichen Schlüssel. Bekannte Algorithmen dieser Klasse sind DES (veraltet und unsicher), 3DES, IDEA und AES.

Abbildung 17.2: Symmetrische Verschlüsselung

Der Data Encryption Standard (DES) war von 1977 bis 2005 (FIPS PUB 46) der Verschlüsselungsstandard in den USA. Er gilt heute als veraltet und wegen seiner auf 56 Bit beschränkten Schlüssellänge mittlerweile als unsicher. TripleDES oder 3DES hat eine effektive Schlüssellänge von 112 Bit und wird auch nicht mehr empfohlen. Die Designprinzipien des DES-Algorithmus sind bis heute nicht vollständig bekannt. Dies hat immer wieder zu Spekulationen und Gerüchten über Hintertürchen für die NSA im DES-Algorithmus geführt. Es kann heute davon ausgegangen werden, dass die NSA und andere ähnlich finanzstarke Organisationen mit ähnlichen Aufgaben in der Lage sind, DES zu brechen. Selbst ohne Hintertür ist es aufgrund der geringen Schlüssellänge möglich, einfach alle Schlüssel durchzuprobieren. Bereits 1999 wurde ein DES-Schlüssel von Wissenschaftlern mit einem Spezialcomputer (Deep Crack, 250.000 US-$ Herstellungskosten) und einem Netz von knapp 100.000 PCs in 22 Stunden und 15 Minuten gefunden. Deep Crack allein benötigt etwa 56 Stunden zum Finden eines DES-Schlüssels [SMBP]. Der International Data Encryption Algorithm (IDEA) wurde 1990 von James L. Massey und Xueija Lai an der ETH Zürich entwickelt. Er ist ein etablierter Algorithmus, der aber in allen wichtigen Industrieländern der Welt patentiert war und deshalb für kommerzielle Zwecke nicht ohne Weiteres eingesetzt werden konnte. Die Patente sind 2011 erloschen. IDEA galt als Ersatz für DES. Die feste Schlüssellänge von 128 Bit ist die Mindestschlüssellänge, die das Bundesamt für Sicherheit in der Informationstechnik (BSI) im Frühjahr 2021 empfiehlt.

Der Advanced Encryption Standard (AES) ist seit 2001 der in den USA standardisierte symmetrische Verschlüsselungsalgorithmus (FIPS 197). Er gilt als sicher. Das BSI empfiehlt für symmetrische Verfahren ausschließlich den Einsatz von AES. Weitere symmetrische Algorithmen, die als sicher gelten, sind der ältere Blowfish- und der Twofish-Algorithmus (beide von Bruce Schneier und Mitarbeitern entwickelt) sowie der Camelia-Algorithmus. In Deutschland spielte der Chiasmus-Algorithmus eine besondere Rolle. Er wurde vom BSI entwickelt und ist nicht veröffentlicht. Es handelt sich um eine Blockverschlüsselung mit der Blocklänge 64 Bit und einer effektiven Schlüssellänge von 128 Bit. Er war bis Ende 2021 für Verschlusssachen der Stufe VS-NfD zugelassen. Es wird heute zwischen zwei verschiedenen Methoden zur symmetrischen Verschlüsselung unterschieden: der Blockverschlüsselung und der Stromverschlüsselung. Bei der Blockverschlüsselung wird der Klartext in Blöcke fester Länge unterteilt. Beim DES war die Blocklänge 64 Bit, beim AES ist die Blocklänge 128 Bit. Eine Blockverschlüsselung bildet einen Klartextblock fester Länge auf einen Geheimtextblock fester Länge ab. In der Regel sind Blocklängen bei Klartext und Geheimtext gleich. Eine solche Verschlüsselung wird nicht-expandierend genannt. Eine Blockverschlüsselung nutzt einen Schlüssel fester Länge. Bei DES ist die Schlüssellänge 56 Bit und bei AES sind 128 Bit, 192 Bit und 256 Bit Schlüssellänge möglich. Bei einer Stromverschlüsselung wird jedes Zeichen des Klartexts mit einem Zeichen des Schlüsselstroms verknüpft. Der Schlüsselstrom ist genauso lang wie der Klartext (siehe Kasten »Nur das One-Time-Pad ist wirklich sicher«). Der Schlüsselstrom wird meist aus einem Schlüssel fester Länge durch wiederholtes Anwenden einer Funktion erzeugt (zum Beispiel der Schlüssel ist der Startwert eines guten Zufallszahlengenerators). Bezeichnen wir eine Folge von Blöcken (Klartext) als Schlüssel als , so können wir dies mit einer Funktion

und einen zum

Geheimtext

verschlüsseln und mit der Umkehrfunktion wieder entschlüsseln.

Verschlüsseln: Entschlüsseln:

Die Länge des Schlüssels variiert: die 56 Bit des DES gelten als zu wenig. Da eine Blockverschlüsselung kein internes Gedächtnis hat, das heißt, jeder Block unabhängig von den vorhergehenden Blocken verschlüsselt wird, gilt

syed Dadurch kann es vorkommen, dass auch ein starker Algorithmus die interne Struktur einer Nachricht nicht verbirgt (siehe Abbildung 17.3). Um dieses Manko zu beheben, gibt man dem Algorithmus ein Gedächtnis. Sie haben beim One-Time-Pad gesehen, dass der Schlüssel so lang wie der Klartext ist (siehe Kasten »Nur das One-Time-Pad ist wirklich sicher«). Dies wird nachempfunden, indem aus einem kürzeren Schlüssel mit einer Funktion ein langer Schlüssel erzeugt wird. Dazu wird aus dem eigentlichen Schlüssel ein Ausgangsschlüssel erzeugt. Bei jedem Verschlüsselungsschritt wird zusätzlich der Schlüssel für den nächsten Schritt verändert. Verschlüsseln:

und

Entschlüsseln:

und

Die Qualität oder kryptografische Stärke einer Stromverschlüsselung hängt von der Nichtvorhersagbarkeit der Funktion ab. Naive Implementierungen, die einen Pseudozufallszahlengenerator für die Funktion verwenden, scheitern an der Vorhersagbarkeit solcher Zufallszahlengeneratoren. Die Verschlüsselungs- beziehungsweise Entschlüsselungsfunktion kann bei einer Stromverschlüsselung sehr

einfach gewählt werden; im Allgemeinen wird dafür aus Geschwindigkeitsgründen wie beim One-Time-Pad der -Operator verwendet. Der sich ständig ändernde Schlüssel wird mit dem Klartext per verknüpft, um den Geheimtext zu ergeben. Um ein systematisches Verfahren zu haben, das aus eine Blockverschlüsselung (zum Beispiel DES, IDEA oder AES) eine Stromverschlüsselung macht, wurden die sogenannten Betriebsarten definiert. Diese schauen wir uns jetzt im Detail an.

Betriebsarten der Blockverschlüsselung 1980 wurden im Rahmen der Standardisierung von DES erstmalig auch sogenannte Betriebsarten (FIPS PUB 81) definiert. Weitere Betriebsarten wurden später ergänzt (NIST SP800-38A, SP800-38C und SP800-38D). Heute sind die folgenden Betriebsarten standardisiert und spielen in verschiedenen Standards eine Rolle: Electronic Code Book (ECB) Modus, Cipher Block Chaining (CBC) Modus, Cipher Feedback (CFB) Modus, Output Feedback (OFB) Modus, Counter (CTR) Modus, Counter mit CBC-MAC (CCM) Modus, Galois/Counter Modus (GCM). Mit Ausnahme des ECB-Modus machen alle Modi aus der zugrundeliegenden Blockverschlüsselung eine Stromverschlüsselung. Der ECB-Modus verwendet die Blockverschlüsselung ohne Besonderheiten (siehe Abbildung 17.3 links). Jeder Block wird unabhängig von allen anderen Blöcken verschlüsselt.

Abbildung 17.3: Die Verschlüsselung zweier Blöcke im ECB- (links) und CBC-Modus (rechts; = ).

Der ECB-Modus hat deutliche Schwächen, da er aufgrund der Eigenschaft, dass aus auch folgt, Strukturen innerhalb des Klartexts im Geheimtext nicht verbirgt. Das obere Bild in Abbildung 17.3 zeigt das unverschlüsselte Logo dieser Buchreihe. Das mittlere Bild ist das Ergebnis der Verschlüsselung des oberen Bildes mit dem AES-128Algorithmus im ECB-Modus. Der Schriftzug ist noch relativ klar zu erkennen. Im unteren Teil des Bildes erfolgte die Verschlüsselung des Logos mit dem AES-128-Algorithmus im OFB Modus. In beiden Fällen wurde derselbe Schlüssel verwendet. Wegen dieser offensichtlichen Schwächen sollte der ECB-Modus nicht verwendet werden. Der CBC-Modus koppelt den verschlüsselten Text zurück zum Klartext, in dem der Output der Verschlüsselung des -ten Blockes mit dem folgenden -ten Klartextblock per verknüpft wird, bevor das Ergebnis des (siehe Abbildung 17.3 rechts) verschlüsselt wird. Dies macht effektiv aus der Blockverschlüsselung eine Stromverschlüsselung. Da beim ersten Block noch kein Verschlüsselungsergebnis des vorherigen Blockes vorliegt, wird hier ein Initialisierungswert (Initialisation Vector, IV) verwendet. Welcher Wert dafür verwendet wird, ist nicht so wichtig, solange ein IV nicht mehrfach bei einem Schlüssel verwendet wird. Der IV muss nicht geheim gehalten werden. Es ist zum Beispiel bei Datenbanken üblich, als IV der Nummer des Datensatzes oder bei Datenträgern die Sektornummer des Sektors zu verwenden.

Abbildung 17.4: Das Logo der Buchreihe (oberes Bild) wurde mit AES-128 mit demselben Schlüssel verschlüsselt, einmal im ECB-Modus (mittleres Bild) und einmal im OFB-Modus (unteres Bild).

Die drei Modi CFB-, OFB- und CTR-Modus unterscheiden sich in der wesentlichen Ablaufstruktur nicht. Hier wird mithilfe des eigentlichen Verschlüsselungsalgorithmus – also DES, IDEA oder AES – eine Art Zufallsschlüsselgenerator betrieben, der für jeden Klartextblock einen neuen Schlüssel generiert. Dieser Schlüssel wird – wie beim One-TimePad – mit dem Klartextblock per zum Geheimtext verknüpft. Der Klartext wird nicht mehr direkt mit dem eigentlichen Verschlüsselungsalgorithmus verschlüsselt. In Abbildung 17.5 sehen Sie, dass der eigentliche Verschlüsselungsalgorithmus quasi neben der Verschlüsselung des Klartexts betreiben wird. Der eigentliche Verschlüsselungsalgorithmus verschlüsselt einen Input und der so erzeugte Output wird mit dem Klartext per verknüpft, um den Geheimtext zu erhalten (siehe Abbildung 17.5). Der Unterschied der drei Modi besteht darin, was als »Input n« für die eigentliche Verschlüsselung verwendet wird. Beim CFB-Modus wird der Geheimtext (Ciphertext) des vorherigen Verschlüsselungsschritts (»Geheimtextblock

«) dort als Input (»Input «) hinein »gefüttert« (Feedback). Beim ersten Schritt wird als (»Input 1«) ein Initialisierungsvektor (IV) verwendet, da es den »Geheimtextblock 0« nicht gibt.

Abbildung 17.5: Das Verschlüsselungsschema ist beim CFB-, OFB- und CTR-Modus gleich. Lediglich der Wert, der für »Input n« verwendet wird, unterscheidet sich bei den drei Modi ( = ).

Beim OFB-Modus wird der Output der vorherigen Verschlüsselungsoperation (»Output «) in den »Input « zurückgekoppelt. Auch hier dient beim ersten Schritt ein IV als (»Input 1«). Im Grunde wird die Verschlüsselung wie ein Pseudozufallszahlengenerator mit dem Startwert IV verwendet und die so erzeugten Zufallszahlen werden mit dem Klartext per verknüpft. Der Klartext wirkt sich auf die generierten »Zufallszahlen« nicht aus. Beim CTR-Modus nimmt man als »Input « einen Wert, der sich aus einer Nonce (Abkürzung für »Number used once«, einmal verwendete Zahl) und einem Zähler zusammensetzt. Wichtig ist, dass eine konkrete Nonce niemals mit dem gleichen Zählerwert mehrfach verwendet wird. Der Zähler wird bei jedem Klartextblock inkrementiert, die Nonce bleibt gleich. Auch beim CTR-Modus wirkt sich der Klartext auf die generierten »Zufallszahlen« nicht aus. Der OFB- und der CTR-Modus haben eine Schwäche. Stellen Sie sich vor, ein Angreifer möchte den verschlüsselten Klartext verändern, obwohl er den Schlüssel und den Klartext nicht kennt. Das Ziel kann eine Sabotage sein (er macht den Klartext kaputt) oder auch eine gezielte Veränderung. Letzteres setzt voraus, dass der Angreifer die Struktur des Klartexts kennt, zum Beispiel weil die Struktur immer gleich ist.

Beim OFB- und CTR-Modus lassen sich Veränderungen am Klartext vornehmen, ohne dass der Angreifer den Schlüssel oder den Klartext kennen muss. Wie geht das? Bei beiden Modi wird eine Zufallszahl per Klartextblock zum Geheimtext verknüpft:

mit dem

Das Symbol steht wieder für das . Der Angreifer möchte jetzt den Wert mit dem Klartext per verknüpfen. Dann verknüpft er den Geheimtext mit dem Wert :

Wenn der Empfänger den Geheimtext noch nicht kennt, fällt ihm diese Veränderung des Geheimtexts nicht auf. Somit ist der Angreifer zum Beispiel in der Lage, zum Beispiel ein Bit an einer bestimmten Position im Klartext gezielt zu verändern. Deshalb muss bei diesen beiden Modi sichergestellt werden, dass eine Veränderung des Geheimtexts erkannt wird. Dies lässt sich zum Beispiel mit einer kryptografisch gesicherten Prüfsumme erreichen. Die beiden Modi CCM und GCM leisten genau dies. Parallel zur Verschlüsselung im CTR-Modus wird eine kryptografische Prüfsumme berechnet. Die Art der Prüfsummenberechnung unterscheidet sich bei den beiden Modi. Zusätzlich gehen assoziierte Daten (associated Data) in die Prüfsummenberechnung ein. Dies sind Daten, die nicht verschlüsselt werden (können), aber zur Authentisierung beitragen. Zum Beispiel können bei Netzwerkdatenpaketen die IP-Adressen nicht verschlüsselt werden, aber sie können in die Authentisierung einbezogen werden. Diese Kombination wird auch als »authenticated encryption with associated data« (AEAD) bezeichnet.

Bei der Verwendung von TLS 1.2/1.3 werden als »associated Data« die Sequenznummer, der Typ, die Versionsnummer, die Länge und die Fragmentinformation des TLS-Records für die Prüfsummenberechnung benutzt. Damit ist die Verschlüsselung an die Details des Pakets gebunden. Der CCM-Modus berechnet die Prüfsumme über die Authentisierungsdaten und die Klartextnachricht, das heißt, dass die Prüfsumme erst nach dem Entschlüsseln überprüft werden kann. Im GCMModus wird die Prüfsumme über die verschlüsselte Nachricht gebildet, das heißt, die Nachricht muss nicht entschlüsselt werden, um die Integrität zu verifizieren. Beide Modi sind nicht für die Verschlüsselung kontinuierlicher Datenströme geeignet, da die Prüfsumme erst zum Schluss übertragen wird und erst nach Ende des verschlüsselten Datenblocks geprüft werden kann. Der CCM-Modus benötigt pro Block zwei Aufrufe der Verschlüsselungsfunktion, einen für die Verschlüsselung und einen für die Prüfsummenberechnung. Der GCM-Modus benötigt pro Block einen Aufruf der Verschlüsselungsfunktion für die Verschlüsselung und einen Aufruf einer speziellen Hash-Funktion für die Prüfsummenfunktion. Da die Hash-Funktion schneller ist als die Verschlüsselungsfunktion, ist der GCM-Modus performanter als der CCM-Modus. Das BSI empfiehlt den Einsatz des CBC- oder CTR-Modus oder, falls eine Datenauthentisierung erforderlich ist, den CCM- oder GCM-Modus. Es gibt noch weitere Betriebsmodi für Verschlüsselungsalgorithmen, die hier nicht weiter betrachtet werden, da sie in den derzeitigen Standardanwendungen keine Rolle spielen.

Asymmetrische Verschlüsselung Bei der symmetrischen Verschlüsselung gibt es einen einzigen Schlüssel, der zum Verschlüsseln und zum Entschlüsseln verwendet wird. 1976 schlugen Witfield Diffie und Martin E. Hellman in ihrer berühmten Arbeit »New Directions of Cryptography« neue Konzepte für die Verschlüsselung vor. Bei dem Versuch, diesen Vorschlag zu widerlegen, fanden R. L. Rivest, A. Shamir und L. Adleman das nach ihnen benannte RSAVerfahren.

Diffie-Hellman-Merkle-Schlüsselaustausch Stellen Sie sich vor, Alice und Bob wollen einen Schlüssel verabreden, um zukünftige Nachrichten zu verschlüsseln. Die beiden müssen davon ausgehen, dass Eve (von englisch eavesdropper, »Lauscher«) ihre Schlüsselvereinbarung komplett abhört. Ihr Bauchgefühl sagt Ihnen wahrscheinlich, dass es nicht möglich sein kann, einen Schlüssel zu verabreden, ohne dass ein Lauscher ihn mitbekommt. Diffie, Hellman und Merkle zeigten, dass das mit ein bisschen Mathematik doch geht. Der Trick besteht darin, den Schlüssel nicht zu übertragen, sondern nur Zahlen, aus denen der Schlüssel berechnet werden kann. Alice und Bob einigen sich auf eine Zahl und eine Primzahl . Diese beiden Zahlen müssen nicht geheim gehalten werden. Alice wählt jetzt eine geheime Zahl und berechnet Entsprechend wählt Bob eine geheime Zahl Alice schickt Ihre Zahl Wenn jetzt Alice

und berechnet

an Bob und Bob seine Zahl

an Alice.

und Bob berechnet, haben beide den gleichen Schlüssel berechnet. Versuchen Sie zur Übung nachzuvollziehen, dass Alice und Bob in der Tat das gleiche berechnen. Eve ist nicht in der Lage, aus den vier Zahlen , , und das zu berechnen, solange und geheim gehalten werden. Dieser Diffie-Hellman-Schlüsselaustausch lässt sich auch mit Elliptische-KurvenKryptografie (siehe später in diesem Kapitel) durchführen. In dieser Form nutzen Sie ihn, ohne es vielleicht zu wissen, jeden Tag, wenn Sie Webseiten mit https aufrufen.

beziehungsweise beziehungsweise

sind die privaten (= geheimen) Schlüssel und die öffentlichen Schlüssel von Alice und Bob.

Der Diffie-Hellman-Merkle-Schlüsselaustausch kann von Mallory (von englisch malicious, »bösartig«) angegriffen werden. Er setzt sich in die Mitte und gibt sich gegenüber Alice als Bob aus und gegenüber Bob als Alice (siehe Abbildung 17.6). Alice vereinbart mit Mallory den Schlüssel und glaubt, das sei der Schlüssel . Bob vereinbart mit Mallory den Schlüssel und glaubt ebenfalls das sei der Schlüssel . Alice und Bob können die Existenz von Mallory in diesem Schlüsselaustausch nicht feststellen.

Abbildung 17.6: Bei einem Man-in-the-Middle-(MITM-)Angriff klinkt sich Mallory aktiv in die Kommunikation von Alice und Bob ein.

Sie benötigen einen zusätzlichen Weg, um sich gegenseitig von ihren Identitäten zu überzeugen. Dazu werden heute bei der Schlüsselvereinbarung zusätzliche Authentifizierungsverfahren eingesetzt. Im Grunde würde es reichen, wenn Alice und Bob über einen anderen Kanal (out of band) ihre Identitäten bestätigen. Wie kann Alice feststellen, dass Bob wirklich Bob ist? Mit dem Thema beschäftigen wir uns im Teil »Vertrauensmodelle« in diesem Kapitel.

Das RSA-Verfahren Bei dem Verschlüsselungsverfahren von Rivest, Shamir und Adleman gibt es zwei Schlüssel, ein Schlüsselpaar. Der eine verschlüsselt den Klartext, der andere entschlüsselt den Geheimtext (siehe Abbildung 17.7). Der Schlüssel, mit dem entschlüsselt wird, wird privater Schlüssel genannt, der andere Schlüssel heißt öffentlicher Schlüssel. Der private Schlüssel muss vom Eigentümer geheim gehalten werden, der öffentliche Schlüssel kann

ohne Risiko veröffentlicht werden. Zur Unterscheidung werden symmetrische Verschlüsselungsverfahren auch als »Secret-Key-Verfahren« und die asymmetrischen Verschlüsselungsverfahren auch als »Public-KeyVerfahren« bezeichnet. Wenn man sich nicht nähert mit der Mathematik dieser Verfahren beschäftigt, ist es nicht ganz leicht nachzuvollziehen, dass es tatsächlich unmöglich ist, einen mit dem öffentlichen Schlüssel verschlüsselten Geheimtext ohne Kenntnis des privaten Schlüssels wieder zu entschlüsseln.

Abbildung 17.7: Die Verschlüsselung erfolgt mit dem öffentlichen Schlüssel des Empfängers, die Entschlüsselung mit dem privaten Schlüssel des Empfängers.

Die beiden Schlüssel müssen nach einem mathematischen Verfahren generiert werden. Anders als bei den symmetrischen Verfahren kann man hier den Schlüssel nicht zum Beispiel aus einem Passwort generieren oder das Passwort direkt als Schlüssel verwenden. Beim RSA-Verfahren werden zwei zufällig ausgewählte Primzahlen und als Basis der Schlüsselerzeugung benötigt. Daraus wird durch Multiplizieren die Zahl berechnet. Danach werden zwei Zahlen und bestimmt, die beide kleiner als sein müssen und die die Gleichung

erfüllen. Dann sind das Zahlenpaar der private Schlüssel. Zu jedem die die Bedingung erfüllen.

der öffentliche und das Paar gibt es viele Paare und ,

Häufig wird für den Exponenten des öffentlichen Schlüssels die Fermatsche Zahl , also gewählt, da dann das Verschlüsseln schneller geht. Die öffentlichen Schlüssel unterscheiden sich trotzdem, da sich die Zahlen unterscheiden. Die Zahl 65537 ist der kleinste Exponent, den das BSI in der TR-02102-1 empfiehlt. Der private Schlüssel ( ) darf nicht so klein gewählt werden, da dann ein BruteForce-Angriff auf den privaten Schlüssel möglich wäre. Verschlüsselt wird der Klartext

zum Geheimtext

mit

und die Entschlüsselung geschieht gemäß Wir wollen an dieser Stelle nicht weiter auf den mathematischen Beweis eingehen. Hierzu lesen Sie bitte die entsprechende Literatur. Es gibt eine Diskrepanz an dieser Stelle. Das RSA-Verfahren rechnet mit Zahlen, wir wollen aber in aller Regel Texte verschlüsseln. Wie ist das möglich? Im Computer werden Texte und Zahlen gleichermaßen als Bitmuster abgelegt. Es liegt am Programm, ob ein Bitmuster als Zahl oder als Text interpretiert wird. Wir schreiben einen Text, dieser wird als Bitmuster gespeichert, das Verschlüsselungsprogramm interpretiert das Bitmuster als Zahlen und kann so mit dem Text »rechnen«.

Gute Schlüssel brauchen guten Zufall Die Erzeugung eines Schlüsselpaars benötigt Zufall, genauer Zufallszahlen (Abbildung 17.8). Die Erzeugung guter zufälliger Zufallszahlen auf einem deterministischen Computer ist nicht einfach. Die Zufallszahlengeneratoren gängiger Programmiersprachen sind bei Weitem nicht gut genug, da die Anforderungen der Kryptografie höher sind. Wir nennen Zufallszahlengeneratoren auf deterministischen Computern auch Pseudozufallszahlengeneratoren.

Abbildung 17.8: Zur Erzeugung von Schlüsselpaaren werden im Wesentlichen gute Zufallszahlen benötigt. So listet das BSI in einer technischen Richtlinie Empfehlungen zur Erzeugung guter Zufallszahlen auf (BSI, TR-02102-1, Kapitel 9). Auch das US-amerikanische NIST gibt Empfehlungen hierzu (NIST SP800-90A, -90B und -90C). 2007 wurde bekannt, dass der Zufallszahlengenerator Dual_EC_DRBG kryptografische Schwächen hat. 2014 wurde dieser aus den Standardisierungsdokument wieder entfernt. Angeblich haben US-amerikanische Firmen eine großzügige Förderung durch die NSA erhalten, wenn sie diesen Generator gezielt in ihren Produkten implementiert haben. Wenn der Zufallszahlengenerator Mängel bei der Zufälligkeit hat, werden nicht alle möglichen Schlüsselpaare erzeugt, sondern nur einige. Damit muss jemand, der eine Verschlüsselung brechen will, nicht mehr alle Schlüssel durchprobieren, sondern nur noch die, die potenziell erzeugt werden können. Dies reduziert den Aufwand des Brechens der Verschlüsselung erheblich. Heute bieten Betriebssysteme Zufallsquellen (unter Linux zum Beispiel /dev/random), die dann dem Zufallszahlengenerator als Basis zur weiteren Verarbeitung genutzt wird.

Das Wort »Hallo!« wird über die ASCII-Codes der Zeichen (ein Byte oder 8 Bit pro Zeichen) als Bitmuster gespeichert. Die binäre Darstellung benötigt sechs Byte. Das resultierende Bitmuster kann zum Beispiel als die drei 16-Bit-Zahlen 18529, 27756 und 28449 interpretiert werden. Mit denen kann dann gerechnet werden – zum Beispiel können wir sie mit dem RSA-Verfahren verschlüsseln, hier im Beispiel unter Verwendung kleiner Zahlen. Aus den Primzahlen 211 und 233 lässt sich ein öffentlicher Schlüssel ( , ) bestimmen. Damit wird die Nachricht zu 19383, 20602 und 37717 verschlüsselt. Diese Zahlen können nicht als Text dargestellt werden. Versuchen Sie das nachzuvollziehen, indem Sie den privaten Schlüssel bestimmen und damit die Nachricht entschlüsseln. Die beim RSA-Verfahren heute üblichen Schlüssellängen von 2048 oder 4096 Bit entsprechen etwa Textblöcken von 256 oder 512 Zeichen, die als Zahlen interpretiert werden. Um das RSA-Verfahren zu brechen, müssen Sie die Zahl in ihre Primfaktoren und zerlegen. Mit kleinen Zahlen ist das einfach, aber mit großen Zahlen wird das numerisch sehr aufwendig. Die schnellsten Rechner der Welt schaffen das nicht in einer sinnvollen Zeit. Der längste bisher faktorisierte RSA-Schlüssel (soweit öffentlich bekannt) ist 795 Bit lang. Der Aufwand für das Faktorisieren entsprach etwa 900 Jahren Rechenzeit auf einem 2.1 GHz Intel Xeon Gold Kern [Sch19]. Die asymmetrische Verschlüsselung lässt sich gut mit einem Briefkasten (Abbildung 17.9) vergleichen. Wenn der Empfänger keinen Briefkasten hat, können wir ihm auch keinen Brief schicken. Wenn der Empfänger keinen öffentlichen Schlüssel hat, können wir ihm keine verschlüsselte Nachricht schicken, da wir sie nicht verschlüsseln können.

Abbildung 17.9: Ein Briefkasten ist eine Analogie zur asymmetrischen Verschlüsselung: Jeder kann etwas durch den Schlitz hineinwerfen, aber nur der Besitzer hat den Schlüssel, um etwas herauszunehmen. (Abbildung: BURG-WÄCHTER KG)

Der Schlitz im Briefkasten entspricht in seiner Funktionalität dem öffentlichen Schlüssel. Jeder kann einen Brief in den Schlitz einwerfen und unmittelbar nach dem Einwerfen ist der Brief nicht mehr zugänglich. Sobald wir etwas mit dem öffentlichen Schlüssel des Empfängers verschlüsselt haben, ist es für uns und für Dritte nicht mehr zugreifbar, da wir es nicht entschlüsseln können.

Der Besitzer des Briefkastens jedoch nutzt seinen (privaten) Briefkastenschlüssel und kann damit problemlos das kleine Schloss öffnen und den Inhalt des Briefkastens entnehmen. Ganz analog kann der Empfänger der verschlüsselten Nachricht mit seinem privaten Schlüssel die Nachricht problemlos entschlüsseln und dann lesen.

Die Geheimdienste kannten es schon Ende April 2021 wurde von der NSA auf Basis einer Anfrage nach dem »Freedom of Information Act« nach über elf (!) Jahren das Dokument »NSA comes out of the closet: The Debate over public Cryptography in the Inman Era« herausgegeben. Bobby Ray Inman war von 1977 bis 1981 Direktor der NSA. Dieses Dokument aus dem Jahr 1996 gibt Einblicke in den Stand des Wissens über Kryptografie bei der NSA. Die Grundlagen der Arbeit von Diffie und Hellman (1976) waren der NSA schon früher bekannt und als geheim eingestuft (»… were both known and classified by NSA.«). Zu der RSA-Veröffentlichung von 1977 heißt es in dem Dokument: »… it duplicated NSA research results obtained more than five years earlier.«. Zusätzlich beklagt sich die NSA, dass sie von der »ärgerlichen« (»especially troubling«) RSA-Veröffentlichung erst nach dem Erscheinen erfuhr. Ein dem RSA-Verfahren (1977) sehr ähnliches Verfahren wurde von Clifford C. Cooks vom britischen GCHQ bereits 1973 beschrieben (»A Note on Non-Secret Encryption«). Es basierte auf Vorarbeiten des GCHQ-Kryptografen James H. Ellis, »The Possibility of Secure Non-Secret Digital Encryption« von 1970. Auch dieses Wissen wurde als geheim eingestuft. Ellis schrieb 1987 einen Bericht über »The Story of Non-Secret Encryption«, der aber erst 1997 nach seinem Tod veröffentlicht wurde. Als in der zweiten Hälfte der 1970er Jahre freie wissenschaftliche Forschung auf dem Gebiet der Kryptografie an Universitäten und Forschungseinrichtungen begann, wurde die NSA davon überrascht. Sie versuchte, Veranstalter von Tagungen zu bewegen, Beiträge zur Kryptografie nicht anzunehmen, und Forschungsförderer sollten den Geldhahn für Kryptoforscher zudrehen. Beides misslang jedoch glücklicherweise. Heute ist freie Kryptoforschung an Universitäten und Forschungseinrichtungen akzeptiert und die NSA und andere Dienste haben sich damit arrangiert. Das heißt aber immer noch nicht, dass die Dienste ihr Kryptowissen mit der Forschung teilen.

Neben dem vorgestellten RSA-Schema gibt es noch weitere asymmetrische Verfahren. Durch den Einsatz in den Softwarepaketen PGP und GnuPG erlangte das Elgamal-Verfahren (von Tahar Elgamal, 1985) eine gewisse Bekanntheit.

Hybride Verschlüsselung Wir haben gesehen, das beim RSA-Verfahren mit sehr großen Zahlen (2048–4096 Bit, das entspricht Zahlen mit 600 bis 1200 Ziffern) gerechnet wird. Dementsprechend langsam sind die Verschlüsselungsoperationen. Die symmetrischen Verschlüsselungsverfahren sind sehr viel schneller, haben aber den Nachteil, dass man den Schlüssel sicher verteilen muss. Um die Geschwindigkeit der symmetrischen Verschlüsselungsverfahren mit der Eleganz des Umgangs mit den Schlüsseln bei der asymmetrischen Verschlüsselung zu kombinieren, wurden die »hybriden Verschlüsselungsverfahren« entwickelt. Abbildung 17.10 zeigt den grundsätzlichen Ablauf der Hybridverschlüsselung.

Abbildung 17.10: Bei der Hybridverschlüsselung wird der Schlüssel mittels asymmetrischer Verschlüsselung ausgetauscht. Der Klartext wird jedoch symmetrisch verschlüsselt.

Das Verschlüsselungssystem generiert einen zufälligen symmetrischen Schlüssel, den Session Key (und wieder spielen hochwertige Zufallszahlen

eine wichtige Rolle!) Der Klartext wird mit diesem Zufallsschlüssel verschlüsselt. Um den Geheimtext entschlüsseln zu können, benötigt der Empfänger den zufälligen symmetrischen Schlüssel. Darum wird nur der zufällige Schlüssel, der im Vergleich zur Nachricht kurz ist, mit dem öffentlichen Schlüssel des Empfängers verschlüsselt. Geheimtext und verschlüsselter Zufallsschlüssel werden an den Empfänger geschickt. Der Empfänger kann mit seinem privaten Schlüssel den zufällig generierten Schlüssel entschlüsseln. Und mit dem entschlüsselten Schlüssel kann er dann den Geheimtext entschlüsseln, um den Klartext zu bekommen. Klingt kompliziert, aber das müssen wir nicht manuell machen, sondern das Verschlüsselungssystem erledigt das für uns ganz automatisch. Die hybride Verschlüsselung hat einen weiteren Vorteil. Wollen wir einen Klartext verschlüsselt an mehrere Empfänger schicken, so wird der Klartext einmal mit dem zufälligen Schlüssel verschlüsselt. Dann wird der Zufallsschlüssel einmal mit dem öffentlichen Schlüssel des ersten Empfängers verschlüsselt. Danach wird der Zufallsschlüssel ein weiteres Mal mit dem öffentlichen Schlüssel des zweiten Empfängers verschlüsselt und so weiter. Wir haben also den verschlüsselten Klartext und -mal den verschlüsselten Zufallsschlüssel, für jeden der Empfänger individuell verschlüsselt. Aus dem verschlüsselten Klartext und den verschlüsselten Schlüsseln bauen wie ein Objekt, zum Beispiel eine Datei oder eine EMail. Dieses Objekt schicken wir an alle Empfänger. Jeder Empfänger kann nun mit seinem privaten Schlüssel den für ihn verschlüsselten Zufallsschlüssel entschlüsseln und damit dann den Geheimtext. Dieses Verfahren ist sehr effizient. Nehmen wir an, eine Nachricht hat 10.000 Zeichen. Ein symmetrischer Schlüssel mit 256 Bit Länge ist 32 Byte (Zeichen) lang. Mit dem langsamen asymmetrischen Verfahren müssen also nur 32 Byte pro Empfänger verschlüsselt werden. Die Länge des verschlüsselten Objekts beträgt bei der Hybridverschlüsselung und Empfängern lediglich Zeichen und nicht Zeichen.

Hashfunktionen

Eine Hashfunktion »zerhackt« (to hash, »zerhacken«) einen Text oder eine Datei in Blöcke fester Länge und mischt die Stücke so zusammen, dass eine Zahl fester Länge (der Hashwert) übrig bleibt. Eine Hash-Funktion muss dabei die folgenden kryptografischen Anforderungen erfüllen: Es muss leicht sein, den Hashwert eines Objekts (Datei, Text) zu berechnen. Es muss nahezu unmöglich sein, aus dem Hashwert das Objekt zu rekonstruieren. Es muss nahezu unmöglich sein, ein zweites Objekt zu finden, das denselben Hashwert wie das erste Objekt hat. Eine Hashfunktion wird häufig nach der Merkle-Damgård-Konstruktion aufgebaut (siehe Abbildung 17.11). Dabei wird die Nachricht in Blöcke fester Länge zerlegt. Die Blocklänge ist für eine Hashfunktion fest definiert (siehe Tabelle 17.2).

Abbildung 17.11: Bei der Merkle-Damgård-Konstruktion besteht die Hashfunktion aus der wiederholten Anwendung eines elementaren Hash-Moduls. Name

Blocklänge

Hashlänge

Status

MD4

512

128

unsicher

MD5

512

128

unsicher, Hash zu kurz

RIPEMD

512

160

unsicher, Hash zu kurz

SHA

512

160

zurückgezogen, unsicher

SHA-1

512

160

unsicher, Hash zu kurz

SHA-2

512

224, 256, 384, 512 sicher

SHA-3

1152, 1088, 832, 576 224, 256, 384, 512 sicher

CBC–MAC abhängig vom zugrundeliegenden Verschlüsselungsalgorithmus

Tabelle 17.2: Bekannte Hashfunktionen mit Blocklänge, der Länge des Hashwerts und dem Sicherheitsstatus (Längenangaben in Bit).

Eine Hashfunktion ist eine »Einwegfunktion«. Es ist leicht, zum Klartext den Hashwert zu berechnen, aber es sollte nahezu unmöglich sein aus dem Hashwert den Klartext zu berechnen. Nur wenn der gehashte Wert nur wenige mögliche Werte hat, kann über einen Brute-Force-Angriff, das heißt das Durchprobieren aller möglichen Werte, der zum Hashwert gehörende Klartext gefunden werden. In einem Unternehmen mit 50.000 Beschäftigten werden Daten zu den Beschäftigten an den Betriebsrat gegeben. Um den datenschutzrechtlichen Vorgaben zu genügen, werden die Daten anonymisiert, in dem die Vorname-Nachname-Kombinationen durch den SHA256-Hash ersetzt werden. Ein Betriebsratsmitglied möchte wissen, wer sich jeweils hinter den Daten verbirgt. Er nimmt das unternehmensinterne Telefonbuch und hasht alle VornameNachname-Kombinationen darin. Aufgrund der geringen Zahl von möglichen Kombinationen ist der Angriff – also die eigentlich unmögliche Rückrechnung – in weniger als einer Sekunde erledigt. In einer Statistik erscheinen Daten zu Kraftfahrzeugen. Um die Eigentümer zu schützen, wurden die Kfz-Kennzeichen durch einen SHA256-Hash ersetzt. Es gibt in Deutschland derzeit zwischen 800 und 1000 verschiedene Buchstabenkombinationen für den Kreis beziehungsweise die Stadt, dann folgen ein bis zwei Buchstaben und dann eine maximal vierstellige Zahl. Das sind mögliche Kennzeichen, also rund 6,7 Milliarden Kennzeichenkombinationen. Um für alle diese möglichen Kennzeichen die Hashwerte zu berechnen, braucht ein aktueller PC ca. 1000 Sekunden. Anmerkung: Die Geschwindigkeit wurde mit dem Speed-Befehl von OpenSSL auf einem aktuellen PC abgeschätzt. Stellen wir uns eine Folie vor, auf der ein Text, zum Beispiel ein Vertrag geschrieben ist. Jetzt falten wir dir Folie. Und dann falten wir immer weiter. Abbildung 17.12 zeigt die ersten vier Faltungen. Der

(Farb-)Klecks, der dabei entsteht, entspricht dem Hashwert des Textes. Es ist einfach, durch Falten vom Text zum Klecks zu gelangen, es ist aber unmöglich, aus dem Klecks den Text zu rekonstruieren. Zwei verschiedene Texte werden aber in jedem Fall verschiedene Kleckse erzeugen. Insofern ist der Klecks repräsentativ für den Text.

Abbildung 17.12: Wir können uns die Bildung eines Hashwerts wie die Faltung einer Folie mit Text vorstellen.

Die Hashwerte des Textes »for dummies« mit unterschiedlichen kryptografischen Hashfunktionen sind: md4:

b54ba9b999f9015d68d5d38e87074e48

md5:

603d85efd3871e802f6c273327a4b6b2

ripemd160: 31a4732a4b71f849fd30e47d6f4f8a0e02dfc749 sha1:

1d1ec55fa216b6de84bcb49ba382ae66869e6108

sha256:

8478a5fe20d675d98ef4168da305e75da06213862ac37e4a21f09cd64fae3677

sha3-256:

658fa9a833bcf5e2c962cad594298aec0e3e6f1da41d684209719a8b432994e4

Mit einer kleinen Änderung (»for Dummies«), ändert sich der Hashwert erheblich. Der sha1-Hash mit dem großen »D« ist: dc8e29eec775a26f5f98dcca21c889e1789ba6d6. Die anderen Hashwerte ändern sich natürlich auch.

Mit dem Hashwert einer Datei lässt sich die Existenz einer Datei beweisen, ohne dass der Inhalt der Datei offengelegt werden muss. Dies kann zum Beispiel ein Sicherheitsforscher nutzen, um zu beweisen, dass er als erster eine Sicherheitslücke dokumentiert hat: er veröffentlicht den Hashwert des Dokuments. Das Dokument veröffentlicht er erst später. Jeder kann überprüfen, dass das Dokument am Tag der Veröffentlichung des Hashwerts bereits fertig war.

Padding Sowohl bei symmetrischer Verschlüsselung als auch beim Hashen wird der Input in Blöcke fester Länge zerlegt. Nun wird es häufig dazu kommen, dass im letzten Block noch Platz ist, da nicht jeder Klartext exakt ein Vielfaches der Blocklänge ist. Wir benötigen also ein Verfahren, um den letzten Block aufzufüllen. Dafür gibt es zahlreiche Möglichkeiten, die größtenteils standardisiert sind. Den Vorgang nennt man Padding. Wichtig ist, dass man eindeutig trennen kann, wo der Klartext aufhört und wo das Padding beginnt. Die einfachste Möglichkeit des Paddings ist, den letzten Block mit 0-Bits (0-Bytes) aufzufüllen. Hierbei ist das Ende des Klartexts nicht sicher feststellbar, wenn der Klartext mit 0 Bits (0-Bytes) endet (Nullpadding). Deshalb ist ein besseres Verfahren, ein 1-Bit an den Klartext zu hängen und den Rest mit 0-Bits aufzufüllen. Bei dem Verfahren ist das Ende des Klartexts eindeutig. (Padding nach ISO/IEC 9797-1, Methode 2) Ein weiteres Verfahren füllt die Blocklänge so auf, dass bei einem Byte der Wert 01 (in hexadezimaler Notation), bei zwei Bytes der Wert 0202, bei drei Bytes 030303 und so weiter angehängt wird. Dies funktioniert bis Blocklängen von 255 Bytes, da 255 die größte Zahl ist, die in einem Byte gespeichert werden kann. Um eindeutig das Ende des Klartexts feststellen zu können, muss aber in jedem Fall ein Padding durchgeführt werden. Ist die Länge des Klartexts genau ein Vielfaches der Blocklänge, wird trotzdem ein kompletter Padding-Block angehängt (Padding nach RFC 5652, Abschnitt 6.2). Es ist auch möglich, die Bytefolge 0102030405…(in hexadezimaler Notation) und so weiter anzuhängen, bis der Block vollständig ist. Hierbei steht automatisch im letzten Byte die Länge des Paddings. Dieses Verfahren funktioniert bis Blockgrößen von 255 Byte (Padding nach RFC 4303, Abschnitt 2.4). Beim Hashen ist es sinnvoll, die Länge des zu hashenden Klartexts mit zu hashen, um Angriffe, die die Länge des Klartexts variieren, zu erschweren. Dazu wird üblicherweise am Ende des letzten Blockes ein Feld für die Länge vorgesehen. Für die Länge sind 64 oder 128 Bit reserviert. Die Länge wird in Bit angegeben. Dies erlaubt bei 64 Bit eine maximale Länge des Klartexts von zwei Exabytes. Die Bits zwischen Ende des Klartexts und dem Feld für Länge werden dann geeignet aufgefüllt. Das BSI empfiehlt in der TR-02102-1 »Kryptografische Verfahren: Empfehlungen und Schlüssellängen« Padding nach ISO/IEC 9797-1, Methode 2, nach RFC 5652, Abschnitt

6.2 und nach RFC 4303, Abschnitt 2.4. Abbildung 17.13 zeigt für eine Blocklänge von 64 Bit und einen 11 Zeichen langen Klartext (»for dummies«) die verschiedenen PaddingMethoden.

Abbildung 17.13: Beispiele für die verschiedenen Padding-Verfahren. Der PaddingBereich ist weiß hinterlegt. Die vier Längenbytes sind schwarz hinterlegt.

Digitale und elektronische Signaturen Bei der asymmetrischen Verschlüsselung haben wir mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und der Empfänger konnte die Nachricht mit seinem privaten Schlüssel entschlüsseln. Bei der digitalen Signatur ist es in Bezug auf die Verwendung der Schlüssel genau umgekehrt: Der Absender erzeugt die digitale Signatur mit seinem privaten Schlüssel. Der Empfänger verifiziert die Signatur mit dem öffentlichen Schlüssel des Absenders. Aus den Eigenschaften des Signaturverfahrens folgt somit auch, dass eine Signatur, die mit dem öffentlichen Schlüssel des Absenders verifiziert werden kann, mit dem entsprechenden privaten Schlüssel des Absenders erstellt worden sein muss. Da der Absender die alleinige Kontrolle über seinen privaten Schlüssel hat, ist die Identität des Absenders und damit die Authentizität der Nachricht bestätigt. Das ist wie eine unterschriebene Urkunde und deshalb wird dies auch als digitale Signatur oder digitale Unterschrift bezeichnet.

Während die digitale Signatur ein technisches Verfahren ist, ist eine elektronische Signatur ein juristisches Konstrukt. Dies wurde in Kapitel 6 vorgestellt. Die digitale Signatur funktioniert ähnlich wie ein Schwarzes Brett (siehe Abbildung 17.14). Jeder kann die Dokumente lesen, die dort ausgehängt sind. Die Glasscheibe schützt die Dokumente und entspricht dem öffentlichen Schlüssel. Da aber nur der Chef und sein Sekretariat über den »privaten« Schlüssel zum Schaukasten verfügen, ist alles, was dort aushängt, verlässlich authentisch. Wenn etwas in dem Kasten hängt, müssen es der Chef oder das Sekretariat dort platziert haben.

Abbildung 17.14: Ein Schaukasten im Unternehmen hat eine Funktion, die der digitalen Signatur entspricht. (Foto: R. W. Gerling)

Das Argument, dass die asymmetrischen Verschlüsselungsverfahren langsam beim Verschlüsseln sind, gilt auch hier. Darüber hinaus soll der Mehraufwand bei der zusätzlichen Datenübertragung aufgrund der

digitalen Signatur für die Kommunikation klein gehalten werden. Deshalb wird in der Praxis ein ähnlicher Trick wie bei der Hybridverschlüsselung verwendet, wo ja zusätzlich zur asymmetrischen Verschlüsselung eine symmetrische Verschlüsselung zum Einsatz kommt. Zum Erstellen der digitalen Signatur wird zu Beginn der Hashwert der Nachricht berechnet. Nur dieser Hashwert wird zum Erstellen der digitalen Signatur mit dem privaten Schlüssel des Absenders verarbeitet und das Ergebnis der Verarbeitung der Nachricht hinzugefügt. Zum Prüfen der Signatur berechnet der Empfänger seinerseits den Hashwert über die empfangene Nachricht und verwendet den Hashwert, den öffentlichen Schlüssel des Absenders sowie die Signatur aus der Nachricht, um die Gültigkeit der digitalen Signatur zu verifizieren. Ist die Prüfung der digitalen Signatur in Ordnung, bedeutet dies, dass die Nachricht nicht manipuliert wurde und der Absender authentisiert ist. Abbildung 17.15 zeigt den Ablauf schematisch.

Abbildung 17.15: Schematische Darstellung einer digitalen Signatur und ihrer Überprüfung.

Mit digitalen Signaturen lässt sich das Schutzziel Integrität erfüllen. Da auch die Identität des Unterschreibenden in die Signatur einfließt, ist auch die Authentizität gewährleistet. Damit kann die Urheberschaft des Dokuments nicht abgestritten werden. Eine digital signierte E-Mail wird im Klartext verschickt und kann deshalb immer gelesen werden. Eine digitale Signatur gewährleistet damit keine Vertraulichkeit.

Elliptische-Kurven-Kryptografie Ein Nachteil der asymmetrischen Verfahren, die auf dem Faktorisierungsproblem oder dem diskreten Logarithmus (dazu gleich mehr) beruhen, ist, dass die Schlüssellänge und damit die Rechenzeit mit wachsenden Sicherheitsanforderungen schneller als linear wächst. Tabelle 17.3 zeigt einen Vergleich der Schlüssellängen aus dem Bericht »Algorithms, Key Size and Protocols Report« der ECRYPT Coordination & Support Action von 2018. Auch das BSI veröffentlicht regelmäßig Aussagen zu empfohlenen Schlüssellängen. symmetrisch asymmetrisch elliptische Kurven Hash Veraltet

80

1024

160

160

Aktuell

128

3072

256

256

15360

512

512

Zukünftig 256

Tabelle 17.3: Vergleich der Schlüssellängen für verschiedene Verschlüsselungsverfahren. (Quelle: ECRYPT Coordination & Support Action)

Ein Teil der bisher vorgestellten asymmetrischen Verfahren beruhen auf dem Faktorisierungsproblem. Große Zahlen (zum Beispiel das Produkt zweier Primzahlen wie beim RSA-Verfahren) sind nur schwer in ihre Primfaktoren zu zerlegen. Das Ausmultiplizieren der Primzahlen zur großen Zahl ist jedoch einfach. Eine andere Klasse asymmetrischer Verfahren (zum Beispiel der DiffieHellman-Schlüsselaustausch und das Elgamal-Signaturverfahren) basiert auf der Schwierigkeit, einen diskreten Logarithmus zu berechnen. So kann die diskrete Exponentialfunktion leicht berechnet werden, aber es ist derzeit kein mathematisches Verfahren bekannt, mit dem sich effizient berechnen ließe. Die Elliptische-Kurven-Kryptografie basiert auf der Schwierigkeit, einen diskreten Logarithmus auf diskreten elliptischen Kurven zu berechnen. Unter einer elliptischen Kurve verstehen wir generell die Menge aller Punkte, die

mit

erfüllen. Zusätzlich muss erfüllt sein, damit die Kurve an jedem Punkt eine Tangente hat. Abbildung 17.16 zeigt eine elliptische Kurve (graue Kurve) mit den Parametern und . Auf der Kurve können nun Rechenoperationen wie die Addition zweier Punkt und anch dem Schema und die Multiplikation eines Punktes mit einer Zahl via durchgeführt werden. Diese Rechenoperationen sind dabei wie folgt definiert: Addition: Die Gerade durch die beiden Punkte und schneidet die Kurve im Punkt . Um den Punkt zu erhalten, muss der Punkt noch an der -Achse gespiegelt werden (siehe Abbildung 17.16). Die Gerade durch und schneidet die Kurve kein drittes Mal, sondern ergibt . Dieses » « ist das neutrale Element. Multiplikation: Die Multiplikation mit einem Skalar ist die -fache Addition des Punktes. Für wird die Tangente an den Punkt gelegt. Der Schnittpunkt der Tangente mit der Kurve ist die Verdoppelung des Punktes. Schneidet die Tangente die Kurve nicht, ist das Ergebnis .

Abbildung 17.16: Darstellung der Addition zweier Punkt auf einer elliptischen Kurve.

Ist ein Punkt auf der elliptischen Kurve (der nicht ist), so lässt sich jeder Punkt auf der Kurve als schreiben. heißt der erzeugende Punkt. Kennt man und , ist leicht zu berechnen. Kennt man jedoch und , so ist nur äußerst schwer herauszubekommen. Die bisherige Beschreibung ging von elliptischen Kurven über reelle Zahlen aus. Bei der Elliptische-Kurven-Kryptografie wird jedoch mit ganzen Zahlen, also in einer endlichen Gruppe, gerechnet. Aus der Kurve wird dann eine Punktwolke. Die Rechenvorschriften bleiben aber im Wesentlichen erhalten. Dies ist das Problem, das dem diskreten Logarithmus entspricht, bei elliptischen Kurven. Alle asymmetrischen Verfahren, die auf dem diskreten Logarithmus beruhen, können durch eine einfache Änderung vom diskreten

Logarithmus auf diskrete elliptische Kurven übertragen werden. Dazu wird die Multiplikation durch die Addition zweier Punkte ersetzt und die Exponentiation durch die skalare Multiplikation einer Zahl mit einem Punkt. Es gibt mehrere standardisierte ECC-Verfahren. Bekannt sind die folgenden: NIST-Kurven. Sie wurden von der NSA empfohlen und sind in den USA genormt (FIPS 186-4), die Kurven über Primzahl-Galois-Felder heißen P-192, P-224, P-256, P-384 und P-521, die Brainpool-Kurven vom BSI und TeleTrusT (RFC 5639), Curve25519 von Dan J. Bernstein (RFC 7748), Curve448 die sogenannte Goldilocks-Kurve (RFC 7748). Verschlüsselungsoperationen mit elliptischen Kurven sind heute in allen Kryptobibliotheken enthalten und in vielen Standardanwendungen im Einsatz. Das Konzept der Elliptische-Kurven-Kryptografie wurde Mitte der 1980er Jahre von Victor S. Miller und unabhängig von ihm von Neal Koblitz vorgeschlagen.

DLIES und ECIES Bei den in diesem Kapitel vorgestellten Hybridverfahren wurde der symmetrische Schlüssel mit einem asymmetrischen öffentlichen Schlüssel verschlüsselt. Eine Art hybrides Verfahren können wir auch auf eine andere Weise realisieren. Dabei wird anstelle des zufälligen Sitzungsschlüssels für jede zu verschlüsselnde Datei ein lokaler DiffieHellman-Schlüsselaustausch zur Bestimmung eines Sitzungsschlüssels durchgeführt. Dies wird als integriertes Verschlüsselungsschema (Integrated Encryption Scheme, IES) bezeichnet. Es gibt zwei Varianten des IES: basierend auf dem diskreten Logarithmus das Discrete Logarithm Integrated Encryption Scheme (DLIES) und

basierend auf elliptischer Kurven Kryptografie das Elliptic Curve Integrated Encryption Scheme (ECIES). Alice will eine Datei für Bob verschlüsseln. Sie verfügt über den authentisierten öffentlichen Schlüssel (Diffie-Hellman oder ECC) von Bob. Bob verfügt über seinen zugehörigen privaten Schlüssel. Alice generiert on the Fly ein Schlüsselpaar zur einmaligen Verwendung. Aus dem öffentlichen Schlüssel von Bob und dem gerade von ihr generierten privaten Schlüssel (siehe Beschreibung des Diffie-Hellman-Verfahrens in diesem Kapitel) erzeugt Alice einen Sitzungsschlüssel. Mit diesem Sitzungsschlüssel verschlüsselt Alice die Datei. Dann schickt Alice neben der Datei auch den frisch erzeugten öffentlichen Schlüssel der Datei an Bob. Bob kann aus seinem privaten Schlüssel und dem öffentlichen Schlüssel der Datei ebenfalls den Sitzungsschlüssel berechnen und anschließend die Datei damit entschlüsseln. Nach dem Versand der Datei löscht Alice den privaten Schlüssel. Damit Bob sicher sein kann, dass die Datei von Alice kommt, muss Alice noch die Authentizität bestätigen. Sie kann zum Beispiel den temporären öffentlichen Schlüssel, den sie an Bob schickt, mit ihrem zertifizierten Langzeitschlüssel digital signieren. Bei diesen Verfahren werden symmetrische Verschlüsselungsverfahren mit integrierter Hash-Berechnung (AEAD) eingesetzt.

Vertrauensmodelle Ein öffentlicher Schlüssel ist im Grunde nur eine Bitfolge. Da aber eine digitale Signatur auch zur Bestätigung der Identität des Signierenden genutzt wird, muss der öffentliche Schlüssel mit einer Identität verknüpft werden. Als führendes Identitätsmerkmal bei Menschen wird dazu die EMail-Adresse genutzt, da diese nur einmal existiert. Über die Zeit gesehen, kann sich die Zuordnung ändern. So kann die Adresse [email protected] nach dem Ausscheiden von Max Mustermann nach einiger Zeit einem Namensvetter gehören. Die E-Mail-Adresse kann aber nur einmal existieren. Damit die Zuordnung von Schlüssel zu Identität gespeichert werden kann, muss es eine Datenstruktur dazu geben. Derzeit gibt es zwei wesentliche Formate dazu: X.509 und OpenPGP. Leider sind die beiden Formate

inkompatibel, obwohl es problemlos möglich ist, einen Schlüssel in beiden Formaten zu speichern. Es ist jedoch leider nicht möglich, das eine Format in das andere Format zu überführen, ohne alle Signaturen neu zu berechnen. Grundsätzlich kann jeder eine X509- oder OpenPGP-Struktur mit einem Schlüssel und einer beliebigen Identität erzeugen. Damit die Zuordnung Schlüssel–Identität verlässlich ist, das heißt, damit man ihr vertrauen kann, sind formale Vertrauensmodelle erforderlich. Technisch erfolgt die Bestätigung der Verknüpfung von Identität und Schlüssel durch eine oder mehrere digitale Signaturen. Diese digitalen Signaturen werden von einem oder mehreren vertrauenswürdigen Dritten ausgestellt. Die Tabelle 17.4 zeigt einen Vergleich der wesentlichen Datenfelder in den beiden Formaten für den öffentlichen Schlüssel. X.509

OpenPGP

aktuelle Versionsnummer

3

4

Seriennummer

Zufallszahl

–

Schlüssel-ID

Hashwert

Hashwert

Generierungsdatum –

Datum

Gültigkeit von

Datum

-

Gültigkeit bis

Datum

-

Algorithmus

RSA, …

RSA, …

Schlüssel

Binärdaten

Binärdaten

Verwendungszweck

Verschlüsseln, Signieren, Authentisieren, Zertifizieren

Verschlüsseln, Signieren, Authentisieren, Zertifizieren

Zertifikatinhaber

Identitätsdaten

Name, Kommentar, E-Mail

Anzahl der Inhaberfelder

mehrere (über SAN-Feld)

mehrere, mindestens eines

Unterschlüssel

–

mehrere

Aussteller

Identitätsdaten

Schlüssel-ID des Ausstellers

Signatur Algorithmus

RSA-SHA256, …

RSA-SHA256, …

Signatur Erstelldatum

X.509

OpenPGP

–

Datum

Dauer der Gültigkeit –

Zeitdauer in Sekunden

Signaturdaten

Binärdaten

Binärdaten

Anzahl der Signaturen

eine

mehrere bei Hauptschlüssel; eine bei Unterschlüssel

Tabelle 17.4: Die wesentlichen Datenfelder der Datenstruktur zur Speicherung des öffentlichen Schlüssels im Format X.509 beziehungsweise OpenPGP.

In Unternehmen wird das X.509-Format favorisiert. Die klare hierarchische (Baum-)Struktur, bei der ein X.809-Zertifikat durch eine Zertifizierungsinstanz bestätigt wird, kommt den IT-Strukturen in Unternehmen entgegen. Die X.509-Zertifikate der Nutzerinnen werden von einer Instanz ausgestellt. Nur diese Instanz muss als vertrauenswürdig akzeptiert werden. Im Gegensatz dazu ist das OpenPGP-Format flexibler, lebt allerdings mehr vom Verständnis der Strukturen durch die einzelne Nutzerin. Der Erfinder von PGP, Phil Zimmermann, hat bei der Einführung von PGP die Begriffe »Vertrauen in den Inhaber« (owner trust) und »Vertrauen in den Schlüssel« (key trust) eingeführt. Die Verwendung des Begriffs »Vertrauen« für zwei völlig verschiedene Dinge hat bei den Nutzerinnen bis heute viel Verwirrung gestiftet. Das »Vertrauen in den Schlüssel« bezeichnet eigentlich nur die Gültigkeit des Schlüssels. Wir bezeichnen einen Schlüssel als »gültig« (key validity), wenn er die digitale Signatur eines vertrauenswürdigen Dritten (trusted third party) hat. Ist der Schlüssel gültig, wissen wir, dass Schlüssel und Identität zusammengehören und jemand das belastbar geprüft hat. Eine dritte Partei ist vertrauenswürdig, wenn wir davon überzeugt sind, dass sie verlässlich ist und eine Identität auch belastbar geprüft hat, wenn sie die digitale Signatur unter Schlüssel und Identität setzt und damit ein Zertifikat erzeugt. Genau wie im analogen Leben wird es im digitalen Leben Dritte geben, denen wir vertrauen und andere, denen wir nicht

vertrauen. Vertrauen ist eine persönliche subjektive Angelegenheit. Per Definition vertrauen wir uns selbst. Es gibt im analogen Leben vorgegebenes Vertrauen. Wir vertrauen überwiegend darauf, dass die Identität, die durch ein staatliches Ausweisdokument (Zertifikat) belegt wird, sorgfältig geprüft wurde. Die Behörden, die die Prüfung (Identitätsfeststellung) durchführen, sind geschult und durch organisatorische Regeln gebunden, sodass der Prozess maximal zuverlässig ist. Ähnliche Regelwerke gibt es auch für Zertifizierungsstellen. Diese werden im sogenannten CA/Browser Forum (https://cabforum.org/), einem Zusammenschluss von Browserherstellern, Zertifizierungsstellen und weiteren Organisationen festgelegt. Nachdem Missbrauchsfälle aufgetreten sind, wurde der Prozess durch zusätzliche Maßnahmen (zum Beispiel Transparenzregister) optimiert. Es hat sich eingebürgert (ursprünglich eher aus Marketinggründen), dass wir Zertifikate in vier Klassen einteilen, um deutlich zu machen, wie intensiv und belastbar die Identität geprüft wurde. Klasse 1: Vor der Ausstellung des Zertifikats wird lediglich die Kontrolle über die E-Mail-Adresse oder die Domain geprüft. Bei der E-Mail-Adresse wird überprüft, ob der Antragsteller auf ein Geheimnis, das an die E-Mail-Adresse geschickt wurde, zugreifen kann. Das Zertifikat enthält als Identität dann auch nur die E-MailAdresse. Bei einer Domain wird überprüft, ob man ein Geheimnis auf der Webseite platzieren oder ins DNS eintragen kann. Ein Beispiel im Domain-Bereich wäre die Zertifizierungsstelle Let's Encrypt. Klasse 2: Vor der Ausstellung des Zertifikats wird die Identität des Antragssteller schriftlich überprüft. Dies erfolgt in der Regel bei Personen durch die zusätzliche Vorlage einer Ausweiskopie und die gleiche Prüfung wie bei einem Klasse-1-Zertifikat. Klasse 3: Vor der Ausstellung des Zertifikats wird auf Basis von Dokumenten die Echtheit der Identität überprüft. Bei Personen wird

hierfür zum Beispiel das Postident- oder ein Videoident-Verfahren verwendet. Bei einem Unternehmen erfolgt die Überprüfung zum Beispiel anhand eines Handelsregisterauszugs. Auch die Verwendung der Online-Ausweisfunktion des neuen Personalausweises (nPA), des elektronischen Aufenthaltstitels oder der eID-Karte sind möglich. Beispiele für die Verwendung der Online-Funktionalität der Ausweisdokumente zur Identitätsfeststellung wären die Zertifizierungsstelle Volksverschlüsselung, die von der FraunhoferGesellschaft und der Telekom AG gemeinsam betreiben wird, oder die Beglaubigung eines OpenPGP-Schlüssels durch die Governikus KG. Klasse 4: Vor der Ausstellung des Zertifikats wird die Identität des Betroffenen auf Basis amtlicher Dokumente bei einem persönlichen Kontakt (Face-2-Face) überprüft. Ein Beispiel für dieses Verfahren wäre die DFN-PKI im Deutschen Forschungsnetz (in der CoronaPandemie wurde hier auf das Videoident-Verfahren ausgewichen). Zu welcher Klasse ein Zertifikat gehört, wird üblicherweise nicht im Zertifikat vermerkt, sondern – wenn überhaupt – nur im Namen des Ausstellers. Das ist aber nicht zwingend. Die Zuordnung der Zertifikatsklassen zu den unterschiedlichen Versionen elektronischer Signaturen nach der eIDAS-Verordnung ist wie folgt möglich: Einfache Signatur: ab Klasse 1, keine Anforderungen an die technische Infrastruktur; eine einfache Signatur kann auch ohne digitale Signatur erstellt werden. Fortgeschrittene Signatur: ab Klasse 2, keine besonderen Anforderungen an die technische Infrastruktur. Der private Schlüssel muss durch ein gutes Passwort geschützt sein. Qualifizierte Signatur: ab Klasse 3, der private Schlüssel sollte in einer sicheren Signaturerstellungseinheit (typisch Chipkarte oder ähnlich mit PIN- oder biometrischem Schutz) gespeichert werden. Außerdem muss der Anbieter ein qualifizierter Vertrauensdiensteanbieter sein.

Technisch sind fortgeschrittene und qualifizierte Signaturen vom kryptografischen Verfahren her identische digitale Signaturen. Die Sicherheit der Speicherung des privaten Schlüssels ist unterschiedlich.

Persönlicher Kontakt Im einfachsten Vertrauensmodell vertrauen wir nur uns selbst. Bei jedem einzelnen Schlüssel wird die Identität des Inhabers persönlich verifiziert. Danach signieren wir den Schlüssel mit unserem eigenen Schlüssel digital. Nur Schlüssel, die wir selbst digital signiert haben, sind gültig. Leider sind wir nur zu oft bereit, weil etwas schnell funktionieren muss, unsere eigenen Regeln zu brechen. Dieses Vertrauensmodel funktioniert nur in einem überschaubaren Umfeld mit einer begrenzten Anzahl an Kontakten, da es zu aufwendig ist. Es skaliert schlecht. Die Chat-App Threema setzt dieses Verfahren technisch elegant um. Wir können uns im Threema einen QR-Code anzeigen lassen, der beim persönlichen Kontakt gegenseitig eingescannt wird. Damit sind die Schlüssel für die sichere Ende-zu-Ende-Verschlüsselung verifiziert. Der Versuchung, Screenshots per E-Mail auszutauschen und einzuscannen, sollten wir aus grundsätzlichen Erwägungen widerstehen. Das Risiko dabei ist, dass beim Austausch unsignierter E-Mails (leider immer noch die Mehrheit) der gescannte Code unbemerkt ausgetauscht werden kann.

Zertifizierungsstellen Wir erzeugen uns ein Schlüsselpaar und bereiten den öffentlichen Schlüssel als Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) auf. Ein CSR in der X.509-Welt ist eine Datenstruktur ähnlich zu einem X.509-Zertifikat. In der OpenPGP-Welt gibt es keinen speziellen CSR, da der öffentliche Schlüssel immer mindestens eine Signatur, nämlich die eigene, enthält.

Es ist auch denkbar, dass die Zertifizierungsstelle unser Schlüsselpaar für uns generiert. Dies wird häufig angewandt, wenn das Schlüsselpaar in einer Chipkarte gespeichert wird. Dann wird das Schlüsselpaar in der Chipkarte generiert. Der öffentliche Schlüssel kann zur weiteren Verarbeitung ausgelesen werden, der private Schlüssel ist unauslesbar in der Chipkarte gespeichert. Die Zertifizierungsstelle (Certificate Authority, CA) nimmt den CSR entgegen und überprüft, ob die im CSR enthalte Identität auch die des Antragstellers ist (Registrierungsstelle beziehungsweise Registration Authority, RA). Für die Intensität der Prüfung gibt es die vorgestellte Einteilung in die Klassen 1 bis 4. Nach dieser Prüfung wird die eigentliche Zertifizierung, das heißt die digitale Signatur der CA für unseren CSR erstellt und damit das X.509-Zertifikat erzeugt. Danach kann das X.509Zertifikat verteilt werden (Verzeichnisdienst = Directory Service, DS). Eine CA benötigt für das Ausstellen unseres Zertifikats ihrerseits ein Schlüsselpaar, also einen privaten Schlüssel und ein zugehöriges X.509Zertifikat. Dieses Zertifikat wird Wurzelzertifikat genannt. Es ist insofern etwas besonders, da es mit dem zugehörigen privaten Schlüssel unterschrieben wurde (Selbstsignatur). Die Gültigkeit und Echtheit eines Wurzelzertifikats einer CA muss auf andere Art (siehe Kasten) sichergestellt werden. Falls wir unseren privaten Schlüssel löschen oder versehentlich veröffentlichen, muss das zugehörige Zertifikat für ungültig erklärt werden. Dies erfolgt über eine Zertifikatsperrliste (Certificate Revocation List, CRL). Dazu generiert die CA regelmäßig (üblich ist einmal pro Woche) eine digital signierte Liste der für ungültig erklärten Schlüssel-IDs. Die URL, von der diese Liste heruntergeladen werden kann, ist in jedem Zertifikat enthalten. Damit kann (und muss) bei jeder Verwendung des Zertifikats geprüft werden, ob das Zertifikat zurückgerufen und damit ungültig gemacht wurde.

Vertrauen in eine CA herstellen

Damit wir einer Zertifizierungsstelle vertrauen können, muss deren Wurzelzertifikat gegenüber Betriebssystem oder Software als vertrauenswürdig deklariert werden. Wie machen wir das? Wir müssen das Wurzelzertifikat in unserem Speicher für vertrauenswürdige Zertifizierungsstellen (ein Teilbereich des Zertifikatsspeichers) speichern. Im Grunde bedeutet dies, dass das Wurzelzertifikat am richtigen Speicherort auf unserem Endgerät gespeichert sein muss. Diese Speicherorte gibt es für Betriebssysteme (Windows, Linux, macOS, iOS und Android) sowie für einzelne Software (Mozilla, Java). Alle diese Produkte werden mit einem mehr oder weniger gefüllten Speicher für Wurzelzertifikate vertrauenswürdiger Zertifizierungsstellen ausgeliefert. Die Anzahl der Wurzelzertifikate variiert zwischen knapp 100 (Java) und über 400 (Windows). Diesen »mitgelieferten« Zertifizierungsstellen vertrauen wir automatisch. Ein Unternehmen kann jederzeit weitere Wurzelzertifikate, zum Beispiel das der eigenen Zertifizierungsstelle, dort speichern und damit Vertrauen in die Zertifizierungsstelle herstellen. In einem Unternehmen sollte die Liste der mitgelieferten vertrauenswürdigen Zertifizierungsstellen sorgfältig und kritisch geprüft werden. Zertifikate nicht vertrauenswürdiger Zertifizierungsstellen können die Vertraulichkeit und Integrität unserer Kommunikation untergraben. Gegebenenfalls sind Zertifizierungsstellen aus Ländern, denen wir nicht vertrauen, zu entfernen. Alle Zertifizierungsstellen zu löschen, ist allerdings nicht empfehlenswert, da zum Beispiel Windows dann nicht mehr bootet. Es gibt auch wichtige Zertifizierungsstellen, deren Wurzelzertifikate nicht mitgeliefert werden. Dies sind zum Beispiel die »Volksverschlüsselung« und die Zertifikate der öffentlichen Verwaltung (Verwaltungs-PKI). Diese müssen bei Bedarf selbst installiert werden. In der OpenPGP-Welt geht jedes Vertrauen in Zertifizierungen von der Nutzerin aus. Dort wird Vertrauen in eine Zertifizierungsstelle oder eine Person durch eine entsprechende digitale Signatur unter dem Schlüssel erzeugt. In diesem Umfeld kann keine Software mit vorgegebenem Vertrauen in Zertifizierungsstellen ausgeliefert werden (Web of Trust).

Es gibt einen weiteren Mechanismus zur Prüfung eines Zertifikats, das Online-Zertifikatstatusprotokoll (Online Certificate Status Protocol, OCSP). Damit kann in Echtzeit die Gültigkeit eines Zertifikats überprüft werden. Die Antwort des OCSP-Servers von der CA ist digital signiert. Die wichtigsten Browser (Ausnahme Google Chrome) unterstützen die Überprüfung eines Zertifikats per OCSP und haben diesen Dienst per Default auch aktiviert. Beim Abrufen von TLS-verschlüsselten Webseiten (Aufruf per https://) wird so die Gültigkeit des Zertifikats zur Identitätsprüfung der Webseite überprüft.

Da die CA hierdurch mitbekommt, welche verschlüsselten Webseiten wir aufrufen, wird mit dem sogenannten OCSP Stapling (OCSPStapel) eine spezielle OCSP-Antwort der CA vom Web-Server mit ausgeliefert. Diese spezielle OCSP-Antwort ist von der CA signiert und nicht vom Webserver. Alle gängigen Webserver und Webbrowser unterstützen OCSP Stapling.

Web of Trust In der OpenPGP-Welt gibt es keine Zertifizierungsstellen, obwohl dies organisatorisch möglich wäre. Der Ansatz, den OpenPGP verfolgt, ist eher basisdemokratisch: Jede Nutzerin von PGP kann auch Zertifizierungsstelle sein, indem sie einen Schlüssel unterschreibt und damit bestätigt, dass die E-Mail-Adresse (Identität) und der Schlüssel zusammengehören. Es ist nur nicht ersichtlich, wie seriös die Nutzerin die Überprüfung gemacht hat. Deshalb muss jede Nutzerin jede andere Nutzerin bezüglich des Vertrauens (Owner Trust) einstufen. In der Praxis wird dies nur von wenigen gelebt. Beim Web of Trust gibt es die folgenden Vertrauensstufen in den Schlüsselinhaber (in Klammern der englische Bezeichnung): absolut (ultimate), sollte nur der eigene Schlüssel haben; vollständig (fully), jeder mit diesem Schlüssel signierte Schlüssel ist gültig; marginal (mariginal), jeder Schlüssel, der von drei Schlüsseln mit marginalem Vertrauen signiert wurde, ist gültig; kein Vertrauen (never), da wir der Nutzerin explizit das Vertrauen entzogen haben, hat die Signatur keine Auswirkungen auf die Gültigkeit; unbekannt (unknown), da wir über die Nutzerin nichts wissen, hat die Signatur keine Auswirkungen auf die Gültigkeit. Damit dem Inhaber eines Schlüssels das vollständige oder marginale Vertrauen ausgesprochen werden kann, muss der Schlüssel gültig sein. Die Gültigkeit eines Schlüssels ergibt sich aus dem Vertrauen in die Schlüsselinhaber, die den Schlüssel unterschrieben haben. Da vielen Nutzerinnen dieses »Finetuning« zu komplex ist, gilt OpenPGP als

kompliziert. In der Praxis signieren viele alle Schlüssel selbst oder verzichten auf die Gültigkeitsprüfung der Schlüssel. Wird schon gut gehen… Die eigene Signatur unter dem eigenen Schlüssel (self signature) hat eine zeitliche Gültigkeit. Nach Erreichen dieses Datums ist der Schlüssel ungültig. Die Dauer der Gültigkeit kann allerdings »für immer« sein, das heißt, der Schlüssel ist dann doch dauerhaft gültig. Dies ist nicht zu empfehlen, da technischer Fortschritt die Anforderungen an die Länge und die Algorithmen der Schlüssel ändert. Ein OpenPGP-Schlüssel etwa sollte maximal fünf Jahre gültig sein.

OpenPGP: Schlüssel finden Wie finden wir den OpenPGP-Schlüssel einer Nutzerin? Der Kern der Identität eines OpenPGP-Schlüssels ist die E-Mail-Adresse der Nutzerin oder der Organisation. Die beste Möglichkeit, nach einem OpenPGP-Schlüssel zu suchen, ist der relativ neue Schlüsselserver https://keys.openpgp.org/ des OpenPGP-Keyserver-Projekts, da er nur Schlüssel zum Download anbietet, für die die E-Mail-Adresse verifiziert wurde. Der Schlüsselserver https://keyserver.ubuntu.com/ ist Teil des alten SKS-KeyserverNetzes. Da dieses Serverbetriebsmodell keinerlei Verifikation der Identität durchführt, sind hier viele Testschlüssel oder Spam-Schlüssel enthalten. Viele Organisationen bieten ihre OpenPGP-Schlüssel auch auf der eigenen Homepage zum Download. Prominente Beispiele sind die sechzehn Landesdatenschutzaufsichtsbehörden und der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit. Diese siebzehn Schlüssel können über den Kontakt-Link oder im Impressum der Webseiten heruntergeladen werden. Um den Download zu vereinheitlichen, versucht das Web Key System einen definierten Ort festzulegen, sodass aus der E-Mail-Adresse der Speicherort maschinell bestimmt werden kann und der Schlüssel automatisch gefunden und heruntergeladen wird. GnuPG unterstützt dieses System seit der Version 2.2.12. Und dann bleibt natürlich noch der Weg, dass sich Nutzer Ihre öffentlichen OpenPGPSchlüssel per E-Mail zusenden. Egal wie man an einen Schlüssel gekommen ist, man muss sorgfältig prüfen, ob Schlüssel und Identität zusammengehören. Im Zweifelsfall muss man den Fingerprint des Schlüssels per Telefon überprüfen. Wie wir sicherstellen, ob wir mit der richtigen Person telefonieren, ist ein anderes Problem.

Trust on First Use Ein weiteres gebräuchliches Vertrauensmodell ist »Trust on First Use« (TOFU). Dies bedeutet so viel wie: »Vertrauen wird beim ersten Kontakt hergestellt«. Verbreitet ist dieses Vertrauensmodell bei der Anwendung Secure Shell (SSH). Bei der ersten Verbindung zu einem Server wird der Fingerabdruck des Server-Schlüssels angezeigt. Die Nutzerin muss diesen prüfen und bestätigen. Nach der erfolgten Bestätigung wird der ServerSchlüssel in eine lokale Datenbank als vertrauenswürdig für diesen Server eingetragen. Ändert sich der Schlüssel des Servers, wird der Verbindungsaufbau verweigert, bis die Nutzerin den neuen Schlüssel als vertrauenswürdig bestätigt. Das Modell TOFU steht und fällt mit dem Verhalten der Nutzerin. Wird bei der ersten Nutzung die Überprüfung des Schlüssels sorgfältig durchgeführt, ist dies durchaus ein starkes Vertrauensmodell. Hierzu muss allerdings die Software so aufgebaut sein, dass sie der Nutzerin eine sorgfältig Prüfung »aufzwingt«. Die bisherigen Implementierungen machen es einer Nutzerin zu leicht, diese Prüfung nicht ernst zu nehmen (siehe Abbildung 17.17).

Abbildung 17.17: Beim ersten Verbindungsaufbau zu einem SSH-Server muss der Schlüssel (hier per SHA256-Fingerprint) überprüft werden. Meist wird »yes« getippt.

TOFU wurde im Dezember 2015 mit der Version 2.1.10 in GnuPG als neues Vertrauensmodell eingeführt. Erhält die Nutzerin erstmalig eine signierte Nachricht, werden die E-Mail-Adresse (Identität) und der Schlüssel automatisch mit einer schwachen Gültigkeit in die lokale Datenbank eingetragen. Erhält die Nutzerin zu derselben E-Mail-Adresse einen zweiten Schlüssel, gibt es eine Sicherheitswarnung.

Kryptograpische Forschung Im Zeitalter des Cloud-Computing stellt sich auch die Frage: Warum müssen Daten vor der Verarbeitung in der Cloud entschlüsselt werden?

Können Daten nicht verschlüsselt verarbeitet werden? Kryptoforscher beschäftigen sich auch mit den Auswirkungen der Quantencomputer auf die Sicherheit der aktuellen Algorithmen und mit der Entwicklung neuer Algorithmen, die mit Quantencomputern nicht gebrochen werden können. Mit beiden in der Zukunft relevanten Themen wollen wir uns am Ende dieses langen Kapitels noch kurz beschäftigen. Sie können diese beiden Abschnitte aber auch erst einmal überspringen.

Homomorphe Verschlüsselung Sollen verschlüsselt gespeicherte Daten verarbeitet werden, müssen diese zuerst entschlüsselt werden. Dazu muss auf dem System, auf dem die Verarbeitung stattfindet, der Schlüssel zugreifbar und benutzbar sein. Dies führt bei der Cloud-Nutzung zu Problemen, wenn sichergestellt werden soll, dass der Cloud-Anbieter nicht selbst auf die Daten zugreifen kann. Die Idee der homomorphen Verschlüsselung kam etwa 1978 auf. Man unterscheidet zwischen additiven homomorphen, multiplikativen homomorphen und voll homomorphen Verschlüsselungssystemen. Für ein additiv homomorphes System gilt wobei die Operation auf den verschlüsselten Daten ist, die der Addition der Daten ohne Verschlüsselung einspricht, und der Schlüssel ist. Entsprechend wäre ein System mit der Eigenschaft multiplikativ homomorph. Wirklich interessant sind voll homomorphe Verschlüsselungssysteme (Fully Homomorphic Encryption, FHE). Heute sind mehrere additive und multiplikative homomorphe Verschlüsselungssysteme bekannt. Einige Beispiele sind hier aufgelistet: RSA Verfahren, 1977, multiplikativ, Goldwasser-Micali-Kryptosystem, 1982,

,

ElGamal Verfahren, 1985, multiplikativ, Benaloh-Kryptosystem, 1994 additiv, Okamoto-Uchiyama-Kryptosystem, 1998, additiv, Paillier-Kryptosystem, 1999, additiv, Damgård-Jurik-Kryptosystem, 2001, additiv.

Die Verschlüsselung des RSA-Verfahrens lässt sich als schreiben. Und mit

lässt sich beweisen, dass

Zwei mit dem RSA-Verfahren und dem gleichen Schlüssel verschlüsselte Zahlen können multipliziert werden, ohne dass es einer Entschlüsselung bedarf. Damit ist das RSA-Verfahren ein multiplikativ homomorphes Verschlüsselungssystem. Bei den additiven Systemen werden häufig die verschlüsselten Zahlen multipliziert, um die unverschlüsselten Zahlen zu addieren. Es dauerte über 30 Jahre, bis 2009 Graig Gentry in seiner Dissertation »A Fully Homomorphic Encryption Scheme« einen wahrscheinlichen Kandidaten für ein solches Verschlüsselungssystem vorschlug. Die gängigen voll homomorphen Systeme sind: das BGV-System (Brakerski, Gentry und Vaikuntanathan, 2011), das BFV-System (Fan und Vercauteren, 2012), das FHEW-System (Ducas und Micciancio, 2014), das TFHE-System (Chillotti, Gama, Georgieva und Izabachene 2016) und das CKKS-System (Cheon, Kim, Kim und Song, 2017). Microsoft veröffentlichte 2015 eine Open-Source-Bibliothek »Simple Encrypted Arithmetic Library« (SEAL) und Google stellte 2021 eine

Sammlung von Softwarebibliotheken und Entwickler-Tools zur homomorphen Verschlüsselung bereit. Beide Systeme gelten als Proof of Concept und nicht als produktionsreif. IBM bietet bei seinen Cloud Services eine vollhomomorphe Verschlüsselung auf Basis der eigenen Bibliothek HElib an. Mit die breiteste Unterstützung für FHE-Systeme bietet die Bibliothek PALISADE. Der Microsoft Passwort Monitor im Edge-Browser dürfte eine der ersten Anwendungen sein, die homomorphe Verschlüsselung in einem Endkundenprodukt einsetzt. Durch die homomorphe Verschlüsselung wird sichergestellt, dass niemand mitbekommt, welches Nutzerinnen-Passwort mit der Datenbank der kompromittierten Passwörter abgeglichen wird und ob es eine Übereinstimmung gibt oder nicht. Ein voll homomorphes Verschlüsselungssystem mit entsprechender Performance wird die Lösung für die Verarbeitung sensibler Daten bei nicht vertrauenswürdigen Cloud-Anbietern sein. Davon sind wir noch weit entfernt. Die derzeitigen Systeme sind in der Anwendung eher ein Proof of Concept als eine produktionsreife Anwendung. Bezüglich Performance oder Skalierbarkeit sind die Systeme noch nicht so weit, dass sie eingesetzt werden können. Und es fehlt natürlich auch noch eine Standardisierung wie beim AES-Algorithmus.

Post-Quantenkryptografie Ein klassischer Computer arbeitet nach den Gesetzen der klassischen Physik. Ein Bit wird durch ein elektrisches Potenzial, zum Beispiel 0 V für »0« und 5 V für »1« dargestellt. Das lässt sich, weil es sich noch relativ nah an der Vorstellung unserer Lebenswirklichkeit befindet, verstehen. Die Zustände »0« und »1« sind definiert und in der Zelle des Speichers ist immer eindeutig einer der beiden Werte vorhanden. Ein Quantencomputer arbeitet nach den Gesetzen der Quantenphysik. In der Quantenmechanik, die sich unserer unmittelbaren Wahrnehmung entzieht, gibt es zwischen den Zuständen gleichzeitig auch beliebige Überlagerungen der Zustände. Ein Qubit, die kleinste Einheit, ist ein solcher Überlagerungszustand. Mehrere Qubits werden dann zu Registern zusammengefasst. Ein Verarbeitungsbefehl wirkt sich auf alle gleichzeitigen Überlagerungszustände aus. Deshalb hat ein

Quantencomputer eine intrinsische Parallelität. Die derzeit verfügbaren Quantencomputer haben etwa 50 bis 100 QuBits. Von Quantenüberlegenheit sprechen wir, wenn ein Quantencomputer ein Problem schneller lösen kann als ein klassischer Computer. Der Begriff Quantenüberlegenheit wurde 2012 von John Preskill eingeführt. Im Oktober 2019 hatte Google gemeldet, in einem Fall Quantenüberlegenheit mit einem System mit 53 QuBits gezeigt zu haben. Nach Angaben von Google wurde ein Problem in 200 Sekunden mit einem Quantencomputer gelöst, für das ein klassischer Computer 10.000 Jahre gebraucht hätte. John Preskill kritisierte, dass Google ein Problem gewählt habe, mit dem die Quantenüberlegenheit besonders einfach zu zeigen sei, aber keinerlei praktische Bedeutung habe. Trotzdem bezeichnete Preskill den erreichten Fortschritt als beeindruckend. Alle kryptografischen Verfahren, die auf Faktorisierung großer Zahlen (zum Beispiel das RSA-Verfahren) oder einem diskreten Algorithmus (zum Beispiel Diffie-Hellman-Schlüsselaustausch oder ElliptischeKurven-Kryptografie) beruhen, können mit dem Shor-Quantenalgorithmus (Peter Shor, 1994) auf einem Quantencomputer effizienter gebrochen werden als auf einem beliebigen klassischen Computer. Derzeit sind für klassische Computer keine effizienten Verfahren zur Faktorisierung großer Zahlen bekannt. Der Shor-Algorithmus benötigt dagegen auf einem idealen, das heißt fehlerfreien Quantencomputer, eine Rechenzeit, die bloß proportional zu der Zahl der Bits der zu faktorisierenden Zahl anwächst. Auf einem fehlerbehaften Quantencomputer (wir können davon ausgehen, dass das alle Quantencomputer sein werden) wird ein zusätzlicher großer, aber von unabhängiger Faktor die Laufzeit wegen der erforderlichen Fehlerkorrekturen verlängern. Das BSI hat 2020 in einer aktualisierten Studie zum Entwicklungsstand der Quantencomputer eine Abschätzung für die Zahl der physikalischen Anzahl der QuBit bei heutiger Fehlerrate vorgenommen. Danach wäre zur Faktorisierung und damit dem Brechen eines RSA-2048 Schlüssels in 100 Tagen etwa eine Million physikalische Qubits in 1 Stunde etwa eine Milliarde physikalische Qubits

erforderlich. Die Abbildung 17.18 zeigt den aktuellen Stand der Forschung und die Abschätzung für eine Faktorisierung sowie das Brechen des diskreten Logarithmus. Der graue Bereich in der Abbildung 17.18 zeigt den aktuellen Stand der Forschung, also den Bereich, den die derzeit verfügbaren Systeme abdecken. Einige ausgewählte Meilensteine sind eingetragen. Die Kurven zeigen den Aufwand für die Faktorisierung (gestrichelte Kurven für 1024 und 15.360 Bit) und das Brechen des diskreten Logarithmus (durchgezogene Kurven für 160 und 512 Bit).

Abbildung 17.18: Anforderungen an die Größe von Quantencomputern. Der graue Bereich markiert den Stand der Forschung, die Symbole markieren einzelne Experimente. (Quelle: BSI; Darstellung nach [BSI20a])

Auch symmetrische Algorithmen wie AES können durch Quantencomputer effizienter gebrochen werden. Hier kann man allerdings die Sicherheit durch eine größere Schlüssellänge »retten«.

Insgesamt können wir festhalten, dass Quantencomputer insbesondere die Sicherheit der derzeitigen asymmetrischen Kryptoalgorithmen ernsthaft bedrohen. Die Bedrohung liegt in der Zukunft und ist nach derzeitigem Stand nicht innerhalb weniger Jahre zu erwarten. Trotzdem muss die Entwicklung beobachtet werden. Im August 2021 veröffentlichte die NSA die »Quantum Computing and Post-Quantum Cryptography FAQs«, die mit einer Aussage zum Cryptographically Relevant Quantum Computer (CRQC) sehr zurückhaltend ist: »NSA does not know when or even if a quantum computer of sufficient size and power to exploit public key cryptography (a CRQC) will exist.« Wir benötigen asymmetrische Kryptoalgorithmen, die mit Quantencomputern nicht gebrochen werden können. Diese müssen zeitnah entwickelt werden, damit sie zur Verfügung stehen, wenn künftige Quantencomputer in der Lage sind, unsere aktuellen asymmetrischen Verfahren zu brechen. Das NIST hat im Februar 2016 einen offenen Wettbewerb zur Standardisierung von Post-Quanten-Algorithmen begonnen. Derartige Wettbewerbe wurden schon zur Standardisierung von AES (1997–2001, 21 Einreichungen) und von SHA-3 (2007–2012, 64 Einreichungen) durchgeführt. Mit dem Abschluss des derzeitigen Wettbewerbs wird nach dem Zeitplan des NIST etwa 2022 bis 2024 mit den Entwürfen zu den Standard-Dokumenten gerechnet. In dem aktuellen Wettbewerb zur Post-Quantenkryptografie werden Algorithmen zur Public-Key-Verschlüsselung, zur Schlüsselvereinbarung und zum Erstellen digitaler Signaturen gesucht. Es gab insgesamt 69 eingereichte Algorithmen. Davon wurden 26 für eine zweite Runde ausgesucht. In der dritten Runde sind noch sieben Finalisten und acht Alternativen. Die Algorithmen fallen im Wesentlichen in drei Gruppen basierend auf unterschiedlichen mathematischen Problemen: gitterbasierte Kryptosysteme verwenden Rechenoperationen auf mehrdimensionalen Gittern,

codebasierte Kryptosysteme basieren auf der Anwendung bekannter Verfahren zur Fehlerkorrektur, multivariate Kryptosysteme nutzen die Schwierigkeit aus, quadratische Polynome auf endlichen Gruppen zu lösen.

Kapitel 18

Biometrie IN DIESEM KAPITEL Was bedeutet Biometrie? Anmelden mit dem Finger Ihr Gesicht sagt, wer Sie sind

Biometrie ist die Wissenschaft von der Erfassung und Messung von Lebewesen und ihren Eigenschaften. Biometrische Merkmale versprechen einige Vorteile für die Identifizierung von Lebewesen, welche informationstechnische Geräte nutzen: Sie sind fest mit dem Körper »verbunden« und können deswegen nicht vergessen oder (zumindest überwiegend) auch nicht verloren gehen. Wenn Sie auf eine Geschäftsreise gehen und die Chipkarte zum Hochfahren Ihres Notebooks zuhause vergessen haben, dann wünschen Sie sich, dass das Anmelden am Rechner mit einem biometrischen Merkmal (zum Beispiel per Fingerabdruck) möglich wäre. Ihre Finger haben Sie hoffentlich dabei … Die DS-GVO definiert »biometrische Daten« als »mit speziellen technischen Verfahren gewonnene personenbezogene Daten zu den physischen, physiologischen oder verhaltenstypischen Merkmalen einer natürlichen Person, die die eindeutige Identifizierung dieser natürlichen Person ermöglichen oder bestätigen, wie Gesichtsbilder oder daktyloskopische Daten« (Art. 4 Nr. 14). In Art. 9 Abs. 1 wird die Verarbeitung »biometrischen Daten zur eindeutigen Identifizierung einer natürlichen Person« ausdrücklich verboten. Lediglich in Ausnahmefällen, zum Beispiel mit Einwilligung (Art. 9 Abs. 2), ist dies zulässig.

Dieser strenge Umgang ist nachvollziehbar. Wenn Ihr Passwort kompromittiert wird, setzen Sie ein neues. Wenn ein biometrisches Merkmal kompromittiert wird, geht das nicht (Ausnahme: Beim Fingerabdruck haben Sie noch neun »Backup Devices«). In amtlichen Ausweisen werden schon lange (wenn auch nicht digital gespeichert) biometrische Merkmale aufgeführt: Körpergröße, Passfoto, Augenfarbe, Unterschrift. In dem RFID-Chip des Reisepasses wird seit dem 1. November 2005 das Foto und ab 1.11.2007 zwei Fingerabdrücke gespeichert. Für die internationale Vereinheitlichung von Reisedokumenten ist die Zivilluftfahrtorganisation der Vereinten Nationen (International Civil Aviation Organization, ICAO) zuständig. Sie empfiehlt zusätzlich zum Foto ein weiteres biometrisches Merkmal. Im neuen Personalausweis (nPA) sind seit dem 1. November 2010 im RFID-Chip neben dem Foto auch zwei Fingerabdrücke gespeichert. Bis zum 1. August 2021 war diese Speicherung freiwillig, seitdem ist die Speicherung von zwei Fingerabdrücken verpflichtend. In der elektronischen Funktionalität identisch zum nPA sind seit dem 1. September 2010 der elektronische Aufenthaltstitel (eAT) als Aufenthaltserlaubnis und seit dem 1. Januar 2021 die eID-Karte für Bürgerinnen und Bürger der EU und des EWR. Die Arbeit mit einem biometrischen Merkmal beginnt mit dem Erfassen des Merkmals. Dieser Vorgang wird als »Enrollment« bezeichnet. Danach wird das Merkmal verarbeitet. Dabei werden die für die spätere Erkennung relevanten Details extrahiert und so aufbereitet, dass eine effiziente Erkennung möglich ist. Das so aufbereitete Merkmal bezeichnen wir als »Template«. Dieses wird gespeichert. Datenschutzrechtlich bedenklich ist immer die zentrale Speicherung solcher Templates in einer Datenbank. Insofern ist die dezentrale Speicherung in den deutschen Ausweispapieren die datenschutzfreundlichere Lösung. Wird der Ausweis verloren oder

zerstört, ist dann natürlich ein erneutes Enrollment nötig. Für Nutzungsszenarien wie die am Bahnhof Berlin Südkreuz 2017/18 getestete Gesichtserkennung kommt man allerdings um zentrale Datenbanken doch nicht herum. Ziel des Gesichtserkennungsversuchs war eine Identifikation von Passanten. Auf mit Kameras erfassten Bildern sollten Personen identifiziert werden. Dies ist deutlich anspruchsvoller als eine Verifikation. Bei einer Verifikation wird die Identität vorgegeben – zum Beispiel durch Auslesen des nPA – und dann »nur« überprüft, ob die untersuchte Person die Richtige ist. Für eine Identifikation ist eine zentrale Speicherung der Templates erforderlich. Bei der Verifikation reicht eine dezentrale Speicherung. Ein iPhone speichert die Templates der Fingerabdrücke oder die Daten für die Gesichtserkennung von zugelassenen Nutzerinnen lokal. Sie verlassen das iPhone nicht. In deutschen Ausweisdokumenten werden entsprechend Bilder der erfassten Fingerabdrücke gespeichert. Im Dezember 2017 berichtete der britische Guardian, dass die chinesische Regierung biometrische Daten aller Uiguren zwischen 12 und 65 Jahre erhoben habe. Dabei handelt es sich um Fingerabdrücke, Iris-Scans, Gesichtsfoto, Blutgruppe und DNSProben. Die Daten wurden laut dem Bericht zeitweise im Rahmen kostenloser gesundheitlicher Untersuchungen gesammelt. Insbesondere die Gesichtsfotos werden den Berichten zufolge zum Erstellen von Bewegungsprofilen mittels Gesichtserkennung genutzt. Das europäische Parlament forderte im Oktober 2021 in einer Entschließung (P9_TA(2021)0405) »das dauerhafte Verbot der Verwendung einer automatisierten Analyse und/oder Erkennung anderer menschlicher Merkmale, wie Gangart, Fingerabdrücke, DNS, Stimme und anderer biometrischer und verhaltensbezogener Signale, in öffentlich zugänglichen Räumen«.

Zwei weitere wichtige Begriffe, die Sie in diesem Zusammenhang kennen sollten, sind die False Acceptance Rate (FAR) und die False Rejection Rate (FRR). Ist die FAR hoch, werden viele Personen bei der biometrischen Prüfung als Berechtigte ausgewiesen, obwohl sie es nicht sind. Die FRR gibt wiederum an, wie oft eine berechtigte Person fälschlicherweise zurückgewiesenen wird. Das ideale biometrische Merkmal hat eine sehr kleine FAR (sicher) und eine sehr kleine FRR (komfortabel). Leider ist es in der Praxis anders. Abbildung 18.1 zeigt vereinfacht das Dilemma: stellen wir die Systemparameter so ein, dass die FAR klein wird, wird gleichzeitig die FRR groß. Umgekehrt ist es genauso: machen wir die FRR klein, wird die FAR groß. Die Abbildung 18.1 zeigt der Übersichtlichkeit halber die Abhängigkeit von nur einem Systemparameter. In der Realität sind es zahlreiche Systemparameter, die eingestellt werden können und müssen.

Abbildung 18.1: Die Abhängigkeit der False Acceptance Rate (FAR) und der False Rejection Rate (FRR) von einem fiktiven Systemparameter.

Zwei Parameterbereiche bieten sich für einen Realbetrieb an: Legt man Wert auf maximale Sicherheit, muss vor allem die FAR klein sein. Die Berechtigten müssen akzeptieren, dass sie den Prozess der Identifikation oder Verifikation unter Umständen mehrfach durchlaufen müssen, bevor das System sie als berechtigt akzeptiert. Der zweite Bereich ist der Punkt der gleichen Fehlerrate. Er ist so etwas wie der optimale Parametersatz. Geeignete physiologische Merkmale sind zum Beispiel Gesicht, Fingerabdruck, Venenmuster der Hand, Iris und die DNS. Um in der alltäglichen IT-Sicherheit eine Rolle zu spielen, muss dabei eine einfache Erfassung möglich sein. Deswegen wird die DNS (obwohl in anderen Bereichen sehr verlässlich) hier nicht genutzt. Verhaltensmuster wie die Anschlagdynamik beim Tippen, die Dynamik der Unterschrift oder die Stimme können auch genutzt werden. Wir können hieraus vier Anforderungen an ein biometrisches Merkmal stellen: Universalität (bei jedem Menschen vorhanden), Einzigartigkeit (bei jedem Menschen verschieden), Beständigkeit (ohne Veränderungen über die Zeit), Erfassbarkeit (quantitativ und einfach messbar). Die ISO/IEC Normen 19749 (Generation 1) und ISO/IEC 39794 (Generation 2) legen Datenaustauschformate für biometrische Daten fest. Damit soll die Interoperabilität zwischen Erfassungsgeräten unterschiedlicher Hersteller gewährleistet werden. Die ISO-Standards der ersten Generation waren nicht erweiterbar, ohne die Abwärtskompatibilität der Formate zu gefährden. Deshalb wurden die Standards der 2. Generation von vornherein auf Erweiterbarkeit angelegt. Die Standards der 1. Generation bleiben weiterhin gültig. Beide Standardfamilien sind inhaltlich gleich strukturiert und bestehen aus mehreren Teilen. In Teil 1 wird jeweils das Rahmenwerk, auf das sich die weiteren merkmalspezifischen Teile stützen, beschrieben. [Hen20]

Im deutschen Reisepass sowie in nPA, eAT und der eID-Karte sind das Passbild und die Fingerabdrücke jeweils als Bild gemäß ISO/IEC 19749:2005 Teil 5 beziehungsweise Teil 4 gespeichert. Schauen wir uns im Folgenden die Verwendung einiger biometrischer Merkmale in der IT-Sicherheitstechnik näher an.

Hautleisten Die Innenflächen der Hand und die Fußsohlen bilden Papillarleisten, die selbst bei eineiigen Zwillingen unterschiedlich sind. Besondere Bedeutung haben dabei die Papillarleisten der Fingerkuppen, deren Abdruck wir als Fingerabdruck kennen. Außerdem bleiben die Papillarleisten (sofern Sie sich nicht in den Finger schneiden) ein Leben lang im Wesentlichen unverändert. In der Forensik werden Fingerabdrücke seit rund 130 Jahren zur Identifikation von Tätern eingesetzt. Der erste Mörder, der mithilfe von Fingerabdrücken überführt wurde, ging im Jahr 1892 dem Kroaten Ivan Vucetic in La Plata, Argentinien, ins Netz. Vucetic nannte seine neue Methode Daktyloskopie (aus dem Griechischen: »Fingerbeschau«). Moderne Fingerabdruckscanner scannen nicht nur die Hautleisten, sondern versuchen auch eine Lebenderkennung, indem sie den Puls prüfen und die Temperatur messen. Dies soll dem Betrug mit Attrappen vorbeugen. Eine Lebenderkennung ist mit kapazitiven, Infrarot- und Ultraschallscannern möglich. Sie kennen optische Verfahren zur Pulsmessung und Bestimmung der Blutsauerstoffsättigung vielleicht schon von Ihrem Fitnessarmband oder Ihrer Smartwatch. Einfache optische Scanner, die nur ein Foto der Fingerkuppe aufnehmen, sind nicht mehr zeitgemäß. Im Gegensatz zur daktyloskopischen Fingerabdruckabnahme, bei der die gesamte Fingerkuppe abgerollt wird, nimmt ein Fingerabdruckscanner übrigens nur eine kleine Fläche der Fingerkuppe auf. Die allgemeinen Anforderungen an Fingerabdruckscanner sind in der technischen Richtlinie TR-03104 Annex 2 »Qualitätsanforderungen bei

der Erfassung und Übertragung der Fingerabdrücke als biometrische Merkmale für elektronische Pässe« (QS-Finger) festgelegt. Bezüglich der technischen Anforderungen an die Erfassungsgeräte (Fingerabdruckscanner) verweist das BSI auf den Anhang F der FBI Electronic Fingerprint Transmission Specification. Der jeweilige Teil 3 der beiden ISO-Standardfamilien beschreibt das Format der Fingerabdruck-Templates, also der verarbeiten Bilder von Fingerabdrücken. Im jeweiligen Teil 4 sind Bildformate beschrieben, also Fingerabdruckbilder, die Sie ausdrucken können.

Venenmuster Für die Erfassung des Venenmuster der Handinnenfläche wird diese mit infrarotem Licht beleuchtet. Dabei ist das Venenmuster gut zu erkennen, weil das sauerstoffärmere Blut der Venen das Infrarotlicht absorbiert, während der restliche Handbereich diese Strahlung reflektiert. Bei einem Finger muss mit Durchlicht gearbeitet werden. Auch hier erscheinen die Venen wegen der Absorption des infraroten Lichtes dunkler. Diese Venenmuster sind bei Menschen hinreichend charakteristisch und stabil, sodass sie zur Identifizierung genutzt werden können. Da der Venenscann berührungslos erfolgt, bestehen keine hygienischen Bedenken wie zum Beispiel beim Fingerabdruck, wo der Scanner berührt werden muss.

Iris-Scan Bei der Iris-Erkennung wird das Auge mit infrarotem Licht beleuchtet und dann eine Aufnahme des Auges gemacht. Grundsätzlich ist ein IrisMuster auch im sichtbaren Bereich erkennbar, ja nach Augenfarbe ist jedoch der Kontrast des Musters im infraroten Licht besser. Zur Templategenerierung wird ein Iris-Segment entzerrt und zu einem Rechteck transformiert. Durch Mittelwertbildung wird das Muster zu einem groben grauwertigen Pixelbild. Dieses wird in ein

Schwarzweißbild überführt. Die Verteilung der schwarzen und weißen Pixel bildet das Template. Da bei der Iris-Erkennung das Auge beleuchtet wird, haben manche Bürgerinnen und Bürger Vorbehalte wegen einer möglichen Gefährdung des Augenlichts. Ablagerungen von Stoffwechselprodukten in der Iris bei einigen Krankheiten führen außerdem zu datenschutzrechtlichen Problemen, da unter Umständen solche Krankheiten aus einem Iris-Scan abgelesen werden könnten. Die Smartphones Samsung Galaxy S8, S8+, Note 8 oder Note 9 nutzen beispielsweise einen Iris-Scanner zur Anmeldung der Nutzerin.

Gesichtserkennung Die Gesichtserkennung stand in dem Ruf, technisch sehr einfach realisierbar zu sein, da heute praktisch jeder Computer über eine Kamera für Videokommunikation verfügt. In der Praxis zeigt sich, dass der Aufwand doch etwas größer ist. So verwendet Microsoft Hello eine Infrarotkamera zur Gesichtserkennung. Dazu enthält eine mit Windows Hello kompatible Kamera zwei Sensoren, einen im sichtbaren Bereich für die Webcam-Funktion und einen im Infrarotbereich zur Gesichtserkennung. Bei der Gesichtserkennung wird zuerst nach einem Gesicht, also der typischen ovalen Form im Bild gesucht. Danach werden die Augen gesucht, da diese die markanteste Form im Gesicht sind. Danach werden ausgehend von den Augen die anderen markanten Punkte des Gesichts (Nase, Mund, Kinnpartie) ausgemacht. Es gibt verschiedene Verfahren, wie aus einem unbearbeiteten Gesichtsfoto ein Template abgeleitet wird. Bei dem »Verfahren der elastischen Graphen« wird ein Gitter über markante Punkte des Gesichts gelegt. Dann wird das Gesicht mit einem Referenzgitter verglichen und die erforderliche Verformung (Streckung, Stauchung und so weiter) des Gitters zur Überführung in das Gitter des Referenzgesichts bestimmt. Diese Parameter bilden dann das Template.

Beim »Eigenface-Verfahren« werden standardisierte Basisgesichter so kombiniert, dass das aktuelle Gesicht möglichst präzise nachgebildet wird. Die Parameter der optimalen Kombination bilden das Template. Da das Gesicht in der Öffentlichkeit frei gezeigt wird, bietet sich die Gesichtserkennung zur Identifizierung von Passanten im öffentlichen Raum an. Aus diesem Grund wird die Gesichtserkennung von vielen Menschen als sehr kritisch gesehen. Die Grenzen zwischen einer Videoüberwachung zur Erhöhung der Sicherheit in einigen kritischen Bereichen des öffentlichen Raumes und der Totalüberwachung der Bürger verschwimmen. Die DS-GVO enthält keine spezielle Regelung zur Videoüberwachung. Die Videoüberwachung öffentlich zugänglicher Räume ist im § 4 BDSG und in den Landesdatenschutzgesetzen geregelt. Spezialgesetze zum Beispiel für Strafverfolgungsbehörden enthalten auch Berechtigungen zur Videoüberwachung, wenn es deren Aufgabenerfüllung dient.

Kapitel 19

Chipkarten und Secure Hardware Token IN DIESEM KAPITEL Welche Chipkartenarten gibt es? Unterschiede zwischen RFID und NFC TPM und Sicherheitstoken

Als Erfinder der Chipkarten gilt Helmut Gröttrup (1916–1981). Er meldete 1966 in Deutschland ein entsprechendes Patent an. Jürgen Dethloff (1924–2002) wird als Erfinder der Mikroprozessorkarte (Smartcard) und Mitentwickler der Chipkarte angesehen. Als weiterer Erfinder gilt Roland Moreno (1945–2012), der unter anderem ein Patent (Anmeldung 1975) auf eine PIN-geschützte Chipkarte erhielt. 1979 fertigte das Münchener Unternehmen Giesecke+Devrient die erste Chipkarte im heute gebräuchlichen Format (ID-1) mit einem SiemensChip. Lediglich die Position der Kontakte war noch anders als heute. Heute sind die Formate der Chipkarten (ID-1 und ID-000) in der ISO/IEC 7810:2019 Norm beziehungsweise (Micro- und Nano-Sim) in der Norm ETSI TS 102 221 festgelegt. Es gibt im Wesentlichen vier gebräuchliche Formate: ID-1: »Scheckkarte« oder Kreditkarte, ID-000: SIM-Karte, Micro-SIM und Nano-SIM.

Abbildung 19.1 zeigt einen Größenvergleich der vier Chipkartenformate. Von der Kontaktfläche sind nur fünf Kontakte (1,2,3, 5 und 7) in Benutzung. Die Stromversorgung erfolgt über die Kontakte 1 und 5. Als Spannung sind 5 V, 3,3 V und 1,8 V spezifiziert. Kontakt 2 ist der ResetKontakt. Am Kontakt 3 wird der Takt angelegt und über Kontakt 7 werden Daten seriell in die Chipkarte geschrieben und ausgelesen. Alternativ können Chipkarten auch mit einer »Spule« ausgestattet sein. Dann erfolgen die Stromversorgung und die Kommunikation mittels eines speziellen Lesegeräts über diese Spule. Im Grunde können Sie sich das (grob vereinfacht) wie bei der Primärwicklung (Lesegerät) und der Sekundärwicklung (Chipkarte) eines Transformators vorstellen. Die Reichweite, über die die Kommunikation funktioniert, wird im Wesentlichen durch die Größe der Spule im Lesegerät bestimmt, da die Spule in der Chipkarte in ihrer Größe begrenzt ist. Dieses Verfahren wird als Radio Frequenzy Identifikation (RFID) bezeichnet.

Abbildung 19.1: Die Chipkartenformate mit Kontaktfeld (von links): ID-1, ID-000, Micro-SIM und Nano-SIM. Rechts oben die Kontaktbelegung.

Eine RFID-Karte »meldet« sich beim Lesegerät mit einer ID-Nummer. Über diese Nummer kann das Lesegerät eine RFID-Karte gezielt ansprechen, etwa wenn mehrere in der Nähe sind. Meldet sich eine RFID-Karte immer mit derselben ID, lässt sich das zum Tracking des Kartenbesitzers missbrauchen.

Die einfachste Art einer Chipkarte sind Speicherchipkarten. Diese finden Sie in zwei Ausprägungen: Die eine Variante kann nur gelesen werden, das heißt, alle Werte werden bei der Produktion unveränderbar in die Chipkarte geschrieben. Das Mindeste, was auslesbar ist, ist eine Art Seriennummer. Dieser Code wird dann von dem auslesenden System für Berechtigungen (zum Beispiel Zugangskontrolle) oder Datenbankzugriffe (um an die eigentliche Information zu kommen) benutzt. Die nicht zu verändernden Werte sind in einem Read-only Memory (ROM) gespeichert. In der anderen Variante können Sie die Daten auch löschen, verändern oder neue Daten speichern. Im Unterschied zu einem USB-Stick ist allerdings die Speicherkapazität sehr viel geringer (typisch einige KByte). Die ersten Krankenversichertenkarten (1995–2014) waren derartige Speicherkarten, in die beim Personalisieren der Chipkarte die Stammdaten des Versicherten geschrieben wurden. Die veränderbaren Werte werden im Electrically Erasable Programmable Read-Only Memory (EEPROM) gespeichert, quasi der Festplatte der Chipkarte. Dieser Speicher behält seinen Inhalt auch ohne Stromversorgung (siehe Abbildung 19.2a). Bei den Prozessorchipkarten handelt es sich im Grunde um kleine Rechner (siehe Abbildung 19.2b). In der Chipkarte ist jetzt zusätzlich noch ein kleiner Arbeitsspeicher (Random Access Memory, RAM) vorhanden. Im ROM ist ein Betriebssystem (eventuell auch nur Teile davon, der Rest ist dann im EEPROM gespeichert. Es gibt zahlreiche Betriebssysteme (Card Operation System, COS) für Prozessorchipkarten wie zum Beispiel CardOS, Javacard, SiCOS, STARCOS oder TCOS. Betriebssysteme für Prozessorchipkarten sind häufig nach Common Criteria zertifiziert.

Abbildung 19.2: Schematischer Aufbau einer Speicherchipkarte (a) und einer Prozessorchipkarte (b). Optionale Bausteine sind jeweils gestrichelt dargestellt.

Prozessorchipkarten (Smartcards) haben, wenn sie für kryptografische Zwecke eingesetzt werden, einen Kryptoprozessor, der darauf optimiert ist, bestimmte kryptografische Verfahren (RSA und ECC, siehe Kapitel 17) besonders schnell auszuführen. Gleichzeitig hat er bestimmte Funktionen, die die Sicherheit der Kryptografie erhöhen. Dies sind insbesondere ein Hardwarezufallszahlengenerator und ein sicherer Speicher für den privaten Schlüssel. Bei der Personalisierung wird in der Chipkarte ein Schlüsselpaar generiert – der öffentliche Schlüssel kann ausgelesen werden, der private Schlüssel ist von außerhalb der Karte nicht zugänglich und kann nur für Krypto-Operationen genutzt werden. Wenn Sie die Kryptochipkarte für eine digitale Signatur nutzen wollen, wird der Hashwert der Nachricht in die Chipkarte übertragen und dort mit dem privaten Schlüssel verarbeitet. Danach wird der verarbeitete Hashwert zurück an die Anwendung übertragen. Beim Entschlüsseln einer verschlüsselten Nachricht wird der verschlüsselte Sitzungsschlüssel in die Chipkarte übertragen und dort mit dem privaten Schlüssel entschlüsselt. Dann wird der entschlüsselte Sitzungsschlüssel zurück an die Anwendung übertragen.

Wenn der private Schlüssel unauslesbar in der Smartcard gespeichert ist, ist er unwiederbringlich verloren, wenn die Chipkarte defekt wird oder verloren geht. Sind mit diesem Schlüssel Daten verschlüsselt worden, sind auch diese Daten verloren! Sind die Daten dagegen mit dem Schlüssel nur signiert worden, gibt es kein Problem. Deshalb sollten Verschlüsselungsschlüssel immer außerhalb einer Chipkarte generiert werden. Dann können Sie die Schlüssel sicher in einer Datensicherung speichern. Der Schlüssel kann dann in die Smartcard geschrieben werden und ist dort gut geschützt. Eine defekte Karte kann dann durch eine neue Karte mit demselben Schlüssel ersetzt werden. Bankkarten, PayTV-Karten, Signatur-Karten und auch SIM-Karten sind Prozessorchipkarten mit Kryptoprozessor. Es gibt auch Prozessorchipkarten mit Kryptoprozessor als RFID-Karten. Die bekannteste Variante ist der neue Personalausweis (nPA). Der nPA hat aus Datenschutzgründen das Feature, dass er sich bei jedem Verbindungsaufbau mit einer anderen ID meldet. Damit kann er nicht getrackt werden. Um die Nutzung einfacher zu gestalten, kamen Hersteller auf die Idee, den Chip einer Chipkarte direkt mit der Elektronik eines Chipkartenlesers zu verbinden. Das Ergebnis war kompakt und wir kennen es als kleinen Sicherheitstoken für den USB-Port. Der USBToken kann, wenn denn der USB-Port passt, an einen Rechner gesteckt werden. Er wird dann benutzt wie eine Chipkarte im Lesegerät. Wenn ein Gerät sich sowohl als RFID-Karte als auch als RFID-Leser ausgeben kann, spricht man von »Near Field Communication« (NFC). Sie kennen das wahrscheinlich alle, wenn die Daten Ihrer Zahlungskarte im Smartphone gespeichert werden und das Smartphone sich dann zum Bezahlen im Supermarkt gegenüber dem Lesegerät als Chipkarte ausgibt (Card Emulation). Die Übertragungstechnik und die verwendeten Protokolle sind beim NFC identisch mit der RFID-Technik.

Die NFC-Technik lässt sich auch zum Datenaustausch zwischen zwei NFC-fähigen Geräten nutzen, zum Beispiel zwischen zwei Smartphones. Mit der AusweisApp2 kann ein Smartphone den nPA auslesen. Es gibt sich gegenüber dem nPA als Lesegerät aus. Derzeit ist eine digitale Version des Personalausweises, der auf dem Smartphone gespeichert wird, in Planung. Bei dem kontaktlosen Einlesen der Daten aus dem digitalen Ausweis gibt sich das Smartphone gegenüber dem Lesegerät als RFID-Karte aus. Die Kommunikationshardware für Lesegerät und Chipkarte ist sehr ähnlich und die Software entscheidet, ob wir eine Karte oder ein Lesegerät mit dem Smartphone emulieren wollen.

Einmalpasswort-Token Wir haben alle Probleme, uns gute Passwörter zu merken. Deshalb werden häufig schlechte Passwörter verwendet. Und es wurde (und es wird immer noch) über Alternativen nachgedacht. Eine Idee ist die Verwendung von Einmalpasswörtern: damit können Sie sich einmal anmelden und danach ist das Passwort sofort ungültig. Das Konzept und das Interface zum Computer ist bei den üblichen Einmalpasswort-Verfahren relativ einfach. Ein Gerät zeigt einen Code (typisch eine sechsstellige Zahl), die sich alle 30 oder 60 Sekunden ändert. Die gerade angezeigt Zahl wird ergänzt um einen Code, den die Nutzerin sich gemerkt hat, und dann als Passwort eingegeben. Die Anmeldemaske muss dazu nicht einmal verändert werden, man muss lediglich die Passwortüberprüfung im Hintergrund anpassen. Die »Initiative for Open Authentication« (OATH) hat ein Verfahren in verschiedenen Ausprägungen entwickelt. Abbildung 19.3 zeigt die Grundidee: Jedes Gerät zur Einmalpasswort-Generierung benötigt eine individuelle Zufallszahl, die aber dem Server zur Anmeldung bekannt sein muss. Die Zufallszahl wird bei der Herstellung in das Gerät geschrieben. Die Länge der Zufallszahl ist verfahrensabhängig.

Zusätzlich wird der Wert eines Zählers benötigt. Hierbei unterscheiden sich die Verfahren: HOTP (HMAC-Based One-Time Password) Algorithm, der Zähler ist eine Zahl, die hochgezählt wird – RFC 4226; TOTP (Time-Based One-Time Password) Algorithm, der Zähler ist die aktuelle Zeit – RFC 6238; OCRA (OATH Challenge-Response) Algorithm, der Zähler ist eine Zahl oder »Challenge«, die der Anmeldeserver geschickt hat – RFC 6287.

Abbildung 19.3: Aus einer Token-abhängigen individuellen Zufallszahl, die bei der Herstellung in den Token geschrieben wird, und einem Zähler wird das Einmalpasswort berechnet.

Für die Verarbeitung werden verschiedene Hashverfahren oder Einwegverschlüsselungen genutzt. Die Zeit (TOTP) oder der Zähler (HOTP) müssen zwischen dem Nutzergerät und dem Überprüfungsserver synchronisiert werden. Die Details der Verarbeitung sind jeweils in den angegebenen RFC-Standards (https://tools.ietf.org) festgelegt. Die Zufallszahl muss mindestens 128 Bit (empfohlen 160 Bit) lang sein. Ein prominenter Verstoß gegen diese Mindestlänge ist der Google Authenticator, der nur eine 80 Bit lange Zufallszahl nutzt und das TOTPVerfahren verwendet. Alle zum Google Authenticator kompatiblen Anwendungen begehen den gleichen Verstoß. Trotzdem ist die Verwendung des Google Authenticators besser, als einfach nur ein Passwort zu nutzen. Da viele große (Cloud-)Anbieter wie Dropbox, GMX, Google, Twitter oder XING den Google Authenticator als zweiten

Faktor unterstützen, können Sie die Anmeldung mit einer Zwei-FaktorAuthentifizierung (2FA) leicht ausprobieren. In Unternehmen werden eher Hardwaretoken eingesetzt. Die bekannten Hardwaretoken wie Kobil SecOVID, OneSpan (früher Vasco) Digipass oder RSA SecureID nutzen alle – zum Teil proprietäre – Varianten des TOTP-Verfahrens. Teilweise bieten die Unternehmen auch zusätzliche Softwarevarianten ihrer Lösungen für das Smartphone an. Aktuell finden Sie auch noch USB-Token auf der Basis von U2F (Universal Second Faktor), einem Verfahren der FIDO Alliance, das von allen wesentlichen Browsern zur Authentifizierung unterstützt wird. U2F basiert auf einer digitalen Signatur einer Challenge, die der Server an den Client schickt. Details zur digitalen Signatur finden Sie im Kapitel 17. Damit ein Webseiten-übergreifendes Tracking einer Nutzerin über den öffentlichen Schlüssel nicht möglich ist, wird für jede Webseite ein eigenes Schlüsselpaar verwendet. Es leuchtet Ihnen sicherlich sofort ein, dass wir ein Speicherplatzproblem haben, wenn wir auf dem USB-Token beliebig viele Schlüsselpaare speichern müssen. Hier nutzen wir einen Trick. Während zum Beispiel beim RSAVerfahren der private Schlüssel spezielle Kriterien erfüllen muss, ist bei der Elliptische-Kurven-Verschlüsselung (ECC) der private Schlüssel eine Zahl. Deshalb verwendet U2F die ECC. Beim U2F-Verfahren wird der private Schlüssel aus einer Zufallszahl (Nonce), der Domain der Webseite und einer geheimen Zahl (Geheimnis) auf dem Token mittels einer Hashfunktion (HMAC) berechnet (durchgezogene Linien in Abbildung 19.4). Aus der Domain, dem Geheimnis und dem privaten Schlüssel wird zusätzlich mit der Hashfunktion (HMAC) ein Message Authentication Code (MAC) berechnet (gestrichelte Linien in Abbildung 19.4). Die Zufallszahl wird zusammen mit dem öffentlichen Schlüssel und dem MAC-Wert (einer Art Prüfsumme) bei der Registrierung an den Server geschickt und dort gespeichert.

Abbildung 19.4: Aus der Domain des Login-Servers, einer Zufallszahl (Nonce) und dem »Geheimnis« werden das Schlüsselpaar und ein MAC in dem U2F-Token berechnet.

Bei der Anmeldung mit U2F schickt der Server eine Challenge sowie die vom Client erhaltene Zufallszahl (Nonce) und den MAC-Wert. Der Client reicht diese Daten und zusätzlich den Domain-Namen des Anmeldeservers an den U2F-Token weiter. Dieser berechnet erneut aus dem Domain-Namen, der Zufallszahl (Nonce) und seinem Geheimnis den privaten Schlüssel. Dann wird der MAC neu berechnet und mit dem zugeschickten verglichen. Stimmen sie nicht überein, wird der Vorgang abgebrochen. Damit kann sich ein Fake-Server, der die Nutzerdaten eines Servers abgegriffen hat, nicht als der Originalserver ausgeben, da die Domains nicht übereinstimmen. Damit sind der private Schlüssel und der MACWert unterschiedlich. Stimmt alles, wird die Challenge mit dem privaten Schlüssel signiert und zum Server zurückgeschickt. Die Signatur kann mit dem öffentlichen Schlüssel, den der Server seit der Registrierung gespeichert hat, verifiziert werden. Ist die Signatur der Challenge in Ordnung, war die Anmeldung erfolgreich. Das aktuelle Anmeldeverfahren, das von allen aktuellen Browsern unterstützt wird, ist Webauthn. Es basiert auf nahezu identischen kryptografischen Verfahren der FIDO Alliance. Bei einer derartigen kryptografischen Anmeldung wird lediglich der öffentliche Schlüssel der Nutzerinnen auf dem Anmeldeserver gespeichert. Damit können keine sicherheitsrelevanten Daten vom Server gestohlen oder vom Anbieter weitergegeben werden. Zur

Anmeldung ist immer der private Schlüssel erforderlich. Und der kann nicht aus den auf dem Server gespeicherten Daten berechnet werden.

Teil V

Lösungen und Umsetzungen

IN DIESEM TEIL … Sie haben im vorhergehenden Teil die theoretischen Grundlagen der wichtigsten Bausteine für IT-Sicherheitslösungen kennengelernt. Nun lernen Sie die Lösungen und Umsetzungen kennen, die darauf aufbauen. Es geht dabei um die sichere mittelfristige und langfristige Speicherung sowie den sicheren Transport von Daten. Am kürzesten werden Backups aufbewahrt; sie dienen dem schnellen Wiederherstellen von Daten nach technischen Ausfällen. Rechtliche Vorgaben verlangen eine mittelfristige Aufbewahrung von Daten, damit Geschäftsprozesse rechtskonform ablaufen können. Daten, die Sie nicht mehr benötigen, die Sie aber trotzdem aufheben möchten, zum Beispiel um die Geschichte des Unternehmens oder der Behörde zu bewahren, werden langfristig archiviert. Für die verschlüsselte Speicherung von Daten gibt es die Möglichkeit, den kompletten Datenträger zu verschlüsseln, nur eine Daten-Partition zu verschlüsseln, eine Containerverschlüsselung einzusetzen oder gezielt einzelne Dateien zu verschlüsseln. Sie lernen die Vor- und Nachteile dieser Lösungen kennen (Kapitel 23). Neben der Absicherung von Daten fällt ein besonderes Augenmerk auf die Absicherung von Netzwerken und den Systemen in unseren Netzwerken. Neben den direkten Absicherungsmaßnahmen befassen sich die folgenden Kapitel damit, wie der Zugang zu Netzwerken und Systemen abgesichert, eingeschränkt und überwacht werden kann und welche besonderen Sicherheitsvorkehrungen für die Systeme und auf der Anwendungsseite relevant sind. Auch hier lernen Sie die verschiedensten Ansätze mit ihren Vorund Nachteilen kennen.

Kapitel 20

Backup & Co. IN DIESEM KAPITEL Warum ist eine Datensicherung wichtig? Welche Daten soll ich aufbewahren? Archivierung Doppelt hält besser: Redundanz

Wichtige Zeugnisse, Urkunden und Fotos (alle auf Papier) heben wir privat sorgfältig auf. Es sind Originale und wir benötigen diese Originale zwar nicht ständig, aber immer mal wieder. Einige werden die Dokumente eingescannt haben und die Scans auf ihrem Rechner aufheben. Das Verb »aufheben« ist allerdings technisch überhaupt nicht präzise. Sie verstehen bestimmt alle etwas Unterschiedliches darunter. Deshalb müssen wir den Begriff präzisieren und wir verwenden bewusst drei unterschiedliche Worte für unterschiedliche Dinge: Datensicherung (Backup), Aufbewahrung und Archivierung. Diese drei Worte bezeichnen nicht das Gleiche! In diesem Kapitel werden wir die Begriffe präzisieren und uns mit der Umsetzung beschäftigen. Am 31. März eines jeden Jahres ist seit 2011 der »World Backup Day«, der internationale Tag der Datensicherung. Geschäftlich wie im Privaten ist allerdings eine Datensicherung einmal im Jahr – selbst am 31. März – viel zu wenig. Dieser Tag ist also vor allem für publikumswirksame PR-Aktionen gedacht. Die Webseite http://www.worldbackupday.com/de/ gibt Ihnen Tipps rund um die Datensicherung für private Zwecke. Wir verwenden die drei angesprochenen Begriffe wie folgt:

Datensicherung: ein kurzfristige Speicherung bis zur nächsten Datensicherung um Betriebssicherheit, Integrität und Verfügbarkeit zu gewährleisten; Aufbewahrung: eine mittel- bis langfristige Speicherung aufgrund rechtlicher Vorgaben, um rechtskonforme Geschäftsprozesse und die Erfüllung gesetzlicher Pflichten zu gewährleisten; Archivierung: die dauerhafte Speicherung nicht mehr benötigter Daten aus eigenem Interesse, zum Beispiel um die Firmengeschichte darzustellen oder wichtige Informationen für die Nachwelt zu erhalten. Im Weiteren scheuen wir uns diese drei Punkte genauer an.

Datensicherung Das BSI behandelt im IT-Grundschutz die Datensicherung ausführlich im Prozessbaustein CON.3. Dabei wird die Datensicherung klar von Aufbewahrungspflichten und freiwilliger Archivierung (OPS.1.2.2) unterschieden. Warum machen wir eigentlich eine Datensicherung? In der IT kann immer mal etwas schiefgehen. Die Hardware erleidet einen Defekt. Durch einen Mausklick an der falschen Stelle löschen wir versehentlich wichtige Dateien. Oder ein Schadenereignis wie Feuer, Hochwasser, Blitzschlag oder Stromausfall zerstört unsere Dateien. Alle diese Ereignisse treten nicht täglich ein, aber Murphys Gesetz (»Anything that can go wrong will go wrong.«) erinnert uns daran, dass es irgendwann dann doch passiert – meist dann, wenn es uns am wenigsten in den Kram passt. Die Datensicherung hilft, mit den Folgen eines solchen Ereignisses besser umgehen zu können. Eine Datensicherung erstellt eine Kopie der Daten, die gesichert werden. Wenn das Original der Datei durch ein Schadensereignis (Hochwasser, Feuer, Hardwaredefekt, Ransomware und anderes) zerstört wird, haben wir immer noch die Kopie. Das Schadensereignis wird durch die Datensicherung nicht verhindert, aber die Folgen werden gemildert. Zum

Glück ist bei Dateien die Kopie nicht vom Original zu unterscheiden. Bei Kopien von Papierdokumenten ist das anders; hier sind Original und Kopie unterscheidbar. Jetzt einfach wild Kopien von Dateien anzufertigen, hilft auch nicht. Wir brauchen eine Systematik, um die Folgen eines Datenverlusts zu minimieren und um im Fall des Falles die verlorenen oder defekten Dateien wiederherstellen zu können. Zuerst müssen Sie sich überlegen, wovon Sie eine Datensicherung erstellen. Wollen Sie nur die Daten sichern oder wollen Sie eine komplette Kopie eines Systems (Daten, Programme und Betriebssystem) erstellen, um es bei einem Hardwaredefekt auf neuer Hardware wiedererstehen zu lassen? Eine weitere wichtige Frage, die Sie sich stellen müssen: Was bedeutet es für Ihr Unternehmen, wenn Sie einen Teil Ihrer Daten oder gar alle verlieren? Wenn Sie diese Frage beantwortet haben, können Sie weitere Fragen stellen. Wie viele Kopien wollen Sie erstellen? Reicht eine Kopie oder sollen es mehrere sein? Auf welchen Speichermedien wollen Sie die Kopien speichern? Wo sollen die Kopien aufbewahrt werden? Wenn Sie alle diese Punkte und noch ein paar mehr geklärt haben, haben Sie ein Datensicherungskonzept erstellt. Das müssen Sie schriftlich dokumentieren, damit Sie und andere die Ausgestaltung und die Verantwortlichkeiten dieses wichtigen IT-Sicherheitsprozesses nachvollziehen können. Anschließend machen Sie sich Gedanken über den Umfang der Datensicherung. Wie viele Daten müssen gesichert werden? Wie viele Daten ändern sich regelmäßig? Wann ändern sie sich? Wie schnell müssen Sie bei einem Datenverlust die Daten wiederherstellen können? Wie sicher wollen Sie sein, dass Sie nur unveränderte Daten wieder einspielen? Sie können die Daten auf drei verschiedene Arten sichern: Vollsicherung Sie sichern alle Daten, die laut Datensicherungskonzept zu sichern sind, vollständig. Auch wenn sich seit der letzten Sicherung nur wenige Dateien geändert haben, sichern Sie immer alles. Der

Nachteil ist der große Verbrauch an Speicherplatz und die lange Dauer der Sicherung. Der Vorteil: bei einer Wiederherstellung spielen Sie relativ einfach die letzte Sicherung wieder ein. Differenzielle Sicherung Sie erstellen zu Beginn eine Vollsicherung. Danach sichern Sie bei jeder weiteren Sicherung nur noch die Daten, die sich seit der letzten Vollsicherung geändert haben. Sie speichern also bei jeder Datensicherung die »Differenz« zur letzten Vollsicherung. Der Vorteil ist, dass Sie weniger Speicherplatz für die Datensicherung benötigen und dass die Datensicherung schneller geht. Der Nachteil ist, dass sie neben der letzten Vollsicherung auch die aktuellste differenzielle Datensicherung einspielen müssen. Außerdem benötigen Sie eine gewisse Buchführung, welche Daten sich geändert haben und deshalb gesichert werden müssen. Inkrementelle Sicherung Sie erstellen zu Beginn eine Vollsicherung. Bei der ersten Sicherung nach der Vollsicherung sichern Sie alle Daten, die sich seit der Vollsicherung geändert haben. Danach sichern Sie nur noch die Daten, die sich seit der letzten inkrementellen Sicherung geändert haben. Sie speichern bei jeder Datensicherung also immer nur die Änderung seit der letzten Datensicherung. Die inkrementelle Sicherung benötigt noch weniger Speicherplatz und Laufzeit als die differenzielle. Das sind klare Vorteile. Die Buchführung der geänderten Daten wird aber schnell ziemlich komplex und Sie müssen im Falle des Falles zuerst die Vollsicherung wieder einspielen und dann der Reihe nach alle inkrementellen Sicherungen bis zum Wiederherstellungspunkt. Das ist dann schon ein Nachteil. Diese drei Sicherungskonzepte können Sie nicht nur auf Dateien, sondern auch auf andere Datenstrukturen anwenden, zum Beispiel auf die Datenblöcke einer Festplatte. Sie speichern dann nach der Vollsicherung der Festplatte immer nur die geänderten Datenblöcke der Festplatte.

Abbildung 20.1 zeigt einen Datenträger mit vier Dateien A, B, C und D, die von Sonntag bis Samstag gesichert werden sollen. In den Kästen ist für jeden Tag angegeben, welche Dateien zu sichern sind. Die geänderte Datei B wird als B.v1 bezeichnet. B.v2 ist die geänderte Datei B.v1. Jeden Sonntag wird eine Vollsicherung erstellt und danach werden die Sicherungen nach dem jeweiligen Verfahren weitergeführt. Die tägliche Vollsicherung muss – in dem Beispiel – in der Woche 28 Dateien sichern. Die differenzielle Sicherung 18 Dateien und die inkrementelle Sicherung nur 11 Dateien. Sie sehen in der Abbildung 20.1 auch, dass bei jedem Sicherungskonzept der Zustand an einem beliebigen Tag wiederhergestellt werden kann. Sie müssen beim Wiederherstellen der Dateien (im Beispiel findet die Wiederherstellung am Samstag statt) jeweils die grau hinterlegten Datensicherungen neu einspielen. Und am Sonntag erfolgt wieder eine Vollsicherung und der Datensicherungszyklus beginnt von vorne.

Abbildung 20.1: Die Darstellung der Datensicherungsarten. a) Vollsicherung; b) Differenzielle Sicherung; c) Inkrementelle Sicherung.

Insbesondere bei der Vollsicherung nutzt man gerne das sogenannte »Großvater-Vater-Sohn-Prinzip«. Es existieren dann zu jedem Zeitpunkt drei Versionen der Datensicherung. Bei jeder neuen Datensicherung wird die älteste Kopie überschrieben. Dieses rotierende Verfahren führt automatisch dazu, dass die Datensicherungen nicht zu lange aufbewahrt werden und außerdem der Speicherplatz nicht überläuft.

Ein IT-Leiter bewahrt Datensicherungen fünf Jahre auf. Er hat mehrfach erlebt, dass eine Nutzerin mit der Bitte um Hilfe zur IT kam, da sie eine Datei dringend benötigte, die sie vor drei Jahre bereits gelöscht hatte. Aber gerade heute benötigt sie die Datei auf einmal doch. Das ist keine rechtskonforme Verwendung einer Datensicherung, sondern eher ein Problem der Aufbewahrung von Daten (siehe Aufbewahrungspflichten). Eine häufige Datenschutzfrage: Wenn ich ein Löschverlangen einer betroffenen Person habe, wie lösche ich die Daten in der Datensicherung, damit ich diese Daten nicht versehentlich wieder einspiele? In einer Datensicherung werden keine Daten gelöscht, da das die Integrität der Datensicherung gefährden würde. Da Datensicherungen nur kurzzeitig aufbewahrt werden, löst sich das Problem zeitnah. Darüber hinaus können Sie im Löschprozess vorsehen, dass beim Wiedereinspielen von Daten aus der Datensicherung die wieder eingespielten Daten erneut gelöscht werden. Mit weniger als drei Kopien sollte Sie bei einer Datensicherung nicht arbeiten. Diese drei Kopien dürfen sich nicht an einem Ort befinden. Im Unternehmen ist das absolute Minimum, dass die Kopien sich in verschiedenen Brandabschnitten befinden. Besser ist es, wenn sich mindestens eine Kopie außerhalb des »Schuttkegels« befindet, also so weit weg, dass die Kopie die vollständige Zerstörung des Gebäudes unversehrt übersteht. Es gibt mit modernen Systemen auch die Möglichkeit der kontinuierlichen Datensicherung (Synchronisierung): jede veränderte Datei wird sofort in die Datensicherung geschrieben. Ein derartiges System ist nicht ohne Risiko. Wenn eine Ransomware einen Rechner befällt und die Dateien zu verschlüsseln beginnt, synchronisiert die Datensicherungssoftware sofort die böswillig veränderten Dateien in die Datensicherung. Ohne weitere Maßnahmen wäre die Datensicherung dann auch verschlüsselt. Ein solches System muss mindestens eine

Versionierung der Dateien bieten, damit dann auf die letzte unverschlüsselte Version zurückgegriffen werden kann. Wann immer Sie eine Datensicherung durch Kopieren der Dateien auf ein weiteres Laufwerk (zum Beispiel USB-Festplatte, Netzwerklaufwerk) erstellen, besteht bei einer Infektion mit einer Ransomware das Risiko, dass die Daten auf dem Datensicherungslaufwerk auch verschlüsselt werden. Der schreibende Zugriff auf die Datensicherung muss über ein anderes technisches Verfahren (zum Beispiel über eine Webschnittstelle oder einen sftpServer) erfolgen, damit eine Ransomware die Daten nicht verschlüsseln kann. Beim Wiedereinspielen sollten Sie die Wiederherstellungslaufwerke schreibgeschützt nutzen. Sie lesen in der Fachliteratur häufig, dass eine Datensicherung bei einem Cloud-Dienstleister nur verschlüsselt erstellt werden dürfe. Das ist eine zweischneidige Sache, denn Vertraulichkeit und Verfügbarkeit mögen sich nicht. Durch die Verschlüsselung wird die Vertraulichkeit gewährleistet, aber die Verfügbarkeit reduziert. Mögliche Komplikationen beim Entschlüsseln machen die Datensicherung unter Umständen unbrauchbar. Hier müssen im Rahmen des Risikomanagements zusätzliche Maßnahmen geplant werden, die die Gefahr von Entschlüsselungsproblemen reduzieren. Daten einfach nur in der Cloud zu speichern, ist keine Datensicherung. Sie können aber die Datensicherung in der Cloud speichern, wenn die Randbedingungen zu Ihrer Zufriedenheit geklärt sind. Hier müssen Sie eine Abwägung zwischen den Anforderungen an die Vertraulichkeit der personenbezogenen Daten nach DS-GVO und der praktischen Verfügbarkeit Ihrer Datensicherung treffen. Es empfiehlt sich, für die Datensicherung eine bewährte Software einzusetzen oder sogar ein Komplettsystem aus Hard- und Software zu beschaffen. Bastellösungen machen keinen Sinn, dazu sind die Daten Ihres Unternehmens zu wichtig. Datensicherungen müssen auch immer wieder getestet werden. Die regelmäßige Verifikation der Funktionalität ist ein wesentlicher Bestandteil des Datensicherungskonzepts.

Die Datensicherung ist eine Ihrer wichtigsten IT-Sicherheitsmaßnahmen. Deswegen genießen die Einführung und der Betrieb einer guten Datensicherung höchste Priorität!

Kontrollfragen Um für Ihr Unternehmen ein gutes Backupkonzept zu erstellen, sollten Sie sich die folgenden Fragen stellen (und beantworten): Welche Daten sollen wann, wie oft und wo gesichert werden? Gibt es ein dokumentiertes Datensicherungskonzept? Finden regelmäßige Wiederherstellungstests statt? Sind Datenträger und Aufbewahrungsort für den Zweck geeignet? Sind die rechtlichen Rahmenbedingungen hinreichend beachtet? Reicht der Speicherplatz für die Datensicherung aus? Die aufgeschriebenen Antworten bilden den Grundstock für Ihr dokumentiertes Backupkonzept. In den USA gibt es T-Shirts zu kaufen, die bei Administratoren und IT-lern beliebt sind. Die Aufschrift lautet: »No Backup? No Mercy.«. Die Zeitschrift c't produzierte daran angelehnt Sticker mit der Aufschrift: »Kein Backup? Kein Mitleid!«. Auch diese erfreuen sich großer Beliebtheit. Nehmen Sie die Datensicherung ernst!

Aufbewahrungspflichten Es gibt zahlreiche gesetzliche Regelungen, die die Aufbewahrung von Daten vorschreiben. Da Sie im Unternehmen die Geschäftsprozesse gemäß dieser Vorgaben gestalten, müssen Sie solche Daten entsprechend aufbewahren. Diese Vorschriften stehen auch nicht im Widerspruch zum Datenschutz, denn Art. 6 Abs. 1 Lit. c) erlaubt die Verarbeitung, wenn »die Verarbeitung zur Erfüllung einer rechtlichen Verpflichtung erforderlich ist, der der Verantwortliche unterliegt«. Auf der anderen

Seite müssen Sie alle personenbezogenen Daten löschen, die Sie für Ihre Geschäftsprozesse nicht mehr erforderlich sind. Ihnen dürften beispielsweise die folgenden Aufbewahrungspflichten bekannt sein: Handels- und Geschäftsbriefe: sechs Jahre (§ 147 AO), Rechnungen: zehn Jahre (§ 147 AO), Patientenakten: zehn Jahre (§ 630f Abs. 3 BGB), Aufzeichnungen über Röntgenbehandlungen: 30 Jahre (§ 28 Abs. 3  RöV) und Rechnungen für Leistungen im Zusammenhang mit einem Grundstück: zwei Jahre für Privatleute (§ 14b UStG); für Unternehmen wie normale Rechnungen. Die Liste zeigt nur Beispiele und ist bei Weitem nicht vollständig. Der letzte Punkt zeigt Ihnen, dass es auch für Privatleute gesetzliche Aufbewahrungspflichten gibt. Sie müssen im Unternehmen ein Aufbewahrungskonzept erstellen. Je nach Branche des Unternehmens und der Abteilung kommen da sehr unterschiedliche Aufbewahrungspflichten und damit auch Aufbewahrungszeiten zusammen. An dieser Fleißaufgabe führt leider kein Weg vorbei. Unabhängig davon, ob es sich um eine Papier- oder elektronische Rechnung handelt, schreibt der Gesetzgeber die Verfügbarkeit und Integrität der gespeicherten Rechnung vor. Damit gelten auch hier die Schutzziele der Informationssicherheit. Das Umsatzsteuergesetz (UStG) schreibt in § 14b Abs. 2 in Verbindung mit § 146 Abs. 2 AO vor, dass im Inland ansässige Unternehmen alle Papierrechnungen im Wesentlichen im Inland aufzubewahren haben. Werden die Rechnungen elektronisch gespeichert und sind sie per Fernabfrage zugänglich, dürfen sie auch im europäischen Gemeinschaftsgebiet gespeichert werden. Das zuständige Finanzamt kann auf schriftlichen Antrag andere

Aufbewahrungsorte genehmigen (§ 146 Abs. 2b AO). Diese Regeln sind bei Cloud-Lösungen zur Speicherung von Buchführungsunterlagen besonders relevant. Grundsätzlich gelten für alle Aufbewahrungsprozesse die Schutzziele Verfügbarkeit und Integrität. Bei personenbezogenen und anderen sensiblen Daten gilt zusätzlich auch die Vertraulichkeit. Ist die Aufbewahrungszeit abgelaufen, greift bei personenbezogenen Daten die Löschpflicht aufgrund der Vorgaben der DS-GVO. Bei anderen Daten wird man auch nach Ablauf der Aufbewahrungszeit häufig löschen, weil man nicht alles dauerhaft speichern will (oder kann). Außerdem ist die Speicherung größerer Datenmengen auch mit Kosten verbunden. Selbstverständlich müssen die aufbewahrten Daten während der Aufbewahrungszeit in die Datensicherung einbezogen werden, da wir sonst die Verfügbarkeit nicht gewährleisten können. Dummerweise hat es sich eingebürgert, die Software, die wir zur Erfüllung der Aufbewahrungspflichten einsetzen, als Archivierungssoftware zu bezeichnen. Das sorgt häufig für Verwirrung.

Archivierung Bei der Archivierung geht es um die dauerhafte Speicherung von Daten, die im Unternehmen nicht mehr benötigt werden. Die Unternehmensleitung möchte solche Daten zum Beispiel zur Dokumentation der Unternehmensgeschichte aufbewahren. Für Bundes- und Landesbehörden ist die rechtliche Situation einfach, da es für sie ein Bundes- (BArchG) und sechzehn Landesarchivgesetze gibt. Das BArchG definiert als »Unterlagen von bleibendem Wert« diejenigen Dokumente, denen »insbesondere wegen ihrer politischen, rechtlichen, wirtschaftlichen, sozialen oder kulturellen Inhalte besondere Bedeutung zukommt«.

Gibt zum Beispiel eine Bundesbehörde archivwürdige personenbezogene Daten an das Bundesarchiv ab und löscht diese dann, gelten die Daten datenschutzrechtlich als gelöscht. Die abgebende Behörde hat dann keinen Zugriff mehr auf diese Daten. Lediglich Zugriffe auf die Archivdaten, die jedem anderen auch möglich wären, sind für die Behörde noch möglich. Das heißt bei personenbezogenen Daten, dass die abgebende Behörde auch eventuelle Schutzfristen abwarten muss (siehe zum Beispiel § 15 Abs. 2 BArchG). Leider gelten diese Archivgesetze nur für Behörden und nicht für Unternehmen. Bei Daten, die nicht personenbezogenen sind, ist eine dauerhafte Aufbewahrung rechtlich kein Problem. Bei personenbezogenen Daten können Sie im Unternehmen eine Archivierung nur verbunden mit einer Interessenabwägung machen (Art. 6 Abs. 1 Lit. f DS-GVO). Hierzu empfiehlt es sich, eine »Archivordnung« für das Unternehmen zu erstellen und die berechtigten Interessen der Betroffenen durch geeignete Schutzmaßnahmen zu berücksichtigen. Inhalte, die zu beachten sind, sind eine fachkundige Betreuung des Unternehmensarchivs, die Definition des archivwürdigen Materials sowie angemessene Schutzfristen (zum Beispiel 20 Jahre nach dem Tod des Betroffenen) für die personenbezogen Daten. Hier orientieren wir uns an den Inhalten der Archivgesetze und versuchen, die Inhalte im Unternehmen so sinnvoll wie möglich nachzubilden. Bei der Planung eines digitalen Archivs müssen Sie die Lebensdauer von Datenträgern und Datenformaten besonders berücksichtigen. In einem digitalen Archiv muss es natürlich auch eine Datensicherung geben. Aufgrund der Langfristigkeit der Speicherung müssen wir uns ganz besonders mit der Haltbarkeit der verwendeten Speichermedien auseinandersetzen. Magnetische Speichermedien müssen alle paar Jahre umkopiert werden, da sie sonst nicht mehr lesbar sind. Hier kann es auch Softwareprobleme geben, etwa wenn die ursprünglich eingesetzte Software auf dem aktuellen Betriebssystem oder auf aktueller Hardware nicht mehr läuft oder die mittlerweile veralteten Speichermedien nicht

mehr unterstützt werden. Hier müssen Sie den technologischen Wandel mitdenken. Bei den Datenformaten sind einfache, gut dokumentierte Datenformate besonders wichtig. Eine Word-Datei ist zur langfristigen Aufbewahrung relativ ungeeignet. Eine PDF/A-Datei eignet sich sehr viel besser. Wenn nur der Text relevant ist, ist auch eine einfache Textdatei oder in Kombination mit Metadaten als XML-Datei empfehlenswert. Ist eine bildliche Wiedergabe erforderlich, wäre ein einfaches TIFF-Format sinnvoller als eine ausgefeilte Komprimierung der Bilddaten. Hier können Sie viel von Wissenschaftlern lernen, die sich viele Gedanken über eine sinnvolle dauerhafte Aufbewahrung von wissenschaftlichen Daten gemacht haben und immer noch machen.

Redundanz Wir haben bisher nur über Daten gesprochen. Aber auch Hardware benötigt eine hinreichende Ausfallsicherheit zur Sicherstellung der Verfügbarkeit Ihrer Systeme. Wir sprechen dann insbesondere vom Konzept der Redundanz. Typischerweise wird Redundanz in folgenden Bereichen angestrebt: doppelte Netzwerkanbindung zum Provider oder zu zwei verschiedenen Providern, doppelte oder mehrfache Ausführung von Servern und redundante Speicherung von Daten auf mehreren Datenträgern (RAID). Um sicherzustellen, dass der Zugriff auf das Internet auch dann noch klappt, wenn zum Beispiel ein Bagger das Kabel des Internetzugangs beschädigt hat, legen Unternehmen ihre Anbindung an den oder die Provider häufig über zwei räumlich getrennte Kabel aus. Durch eine geeignete Konfiguration des Netzwerks wird sichergestellt, das im Normalbetrieb beide Anschlüsse genutzt werden, um den Datenverkehr

zu verteilen. Im Störungsfall fällt man dann auf den verbleibenden, noch intakten Anschluss zurück. Da zwei Internetanschlüsse in der Regel doppelt so viel kosten, müssen die Geschäftsprozesse diese Verfügbarkeit erfordern. Gerade bei einer intensiven Nutzung von Cloud-Diensten, die ohne Internetverbindung nicht möglich ist, ergibt sich eine immer stärkere Notwendigkeit für solche Lösungen. Wenn ein Unternehmen den kompletten Serverbetrieb outgesourct hat und es im Unternehmen nur noch Client-Rechner gibt, ist eine redundante Anbindung erst recht unverzichtbar. Um bei Servern (zum Beispiel Fileservern, E-Mail-Servern, Webservern, Terminalservern oder Virtualisierungsservern, aber auch Firewalls) die Ausfallsicherheit zu erhöhen, ist eine übliche Lösung der parallele Betrieb von zwei oder mehr Servern. Die Server teilen sich im Normalbetrieb die Arbeit und sobald einer ausfällt, arbeiten der oder die verbleibenden Server mit reduzierter Leistungsfähigkeit weiter. Damit bemerken die Nutzerinnen den Ausfall eines Systems oft gar nicht. Viele Anwendungen unterstützen heute einen fehlertoleranten Clusterbetrieb, das heißt einen Betrieb im Verbund mehrerer Server, von denen auch mal einer ausfallen darf. Ein »Redundant Array of Independent Disks« (RAID) verteilt die gespeicherte Information über mehrere Festplatten oder SSDs. Der einfachste Fall ist ein Spiegeln der Daten (RAID 1), das heißt, die Daten werden parallel auf zwei Festplatten geschrieben. Fällt eine aus, können Sie die defekte Platte austauschen und die Daten werden automatisch vom zweiten System auf die neue Platte kopiert. Während dieser Kopierphase haben Sie dann zwar keine Ausfallsicherheit, das System kann aber weitergenutzt werden. Die nutzbare Gesamtkapazität eines RAID-1-Systems ist die Kapazität der kleineren der beiden Festplatten. Sie haben also bei zwei gleich großen Festplatten 50 % Kapazitätsverlust verglichen mit dem Betrieb beider Festplatten. Bei RAID 5 werden die Daten blockweise auf mehrere Platten verteilt und um eine Paritätsinformation ergänzt. Abbildung 20.2 zeigt die

Verteilung der Blöcke und der Paritätsinformationen über die Festplatten.

Abbildung 20.2: Schematische Darstellung eines RAID-1- und eines RAID-5-System mit den jeweiligen Datenblöcken ( =A B C, =D E F, =G H I und = XOR).

Die Gesamtkapazität des RAID-5-Verbunds ist bei gleichgroßen Festplatten das -Fache der Kapazität einer Festplatte. Das System kann den Ausfall einer Festplatte problemlos kompensieren, denn der Inhalt der ausgefallen Platte lässt sich aus den Inhalten der intakten Platten rekonstruieren. Ein RAID-5-Verbund besteht aus mindestens drei Festplatten; gebräuchlich sind vier oder fünf Platten. RAID 1 und RAID 5 sind die beiden am häufigsten eingesetzten Versionen. Es gibt aber weitere Möglichkeiten, insbesondere auch Kombinationen der RAID-Varianten. Ein RAID-System erhöht die Ausfallsicherheit und damit die Verfügbarkeit eines Rechners. Ein RAID-System ist kein Ersatz für eine Datensicherung!

Kapitel 21

Netzwerksicherheit IN DIESEM KAPITEL Was dem Netz zugrunde liegt Kernelemente der Netzwerksicherheit Sicherheit von Standardprotokollen Netzwerkzugang und Netzwerksegmentierung Sicherheit von Funknetzen, zum Beispiel WLAN mit WPA3

Netzwerke bilden die Kerninfrastruktur für unsere heutige Kommunikation. Wir fokussieren uns in diesem Kapitel primär auf IPbasierte Netzwerke, wie wir sie im Internet, im Unternehmensnetzwerk oder auch von zuhause kennen. Darüber hinaus betrachten wir ein paar alltägliche Spezialfälle bei Funknetzen, wie zum Beispiel die Sicherheit von Bluetooth oder RFIDs. Heute besteht das Internet aus einem weltumspannenden Netzwerk von Netzwerken, die miteinander hierarchisch verbunden sind und in denen Teilnehmer dynamisch hinzukommen und das Netz auch jederzeit wieder verlassen können. Eine der zentralen Herausforderungen ist und bleibt die Frage, wie Datenpakete zuverlässig und effizient vom Absender zum Empfänger kommen können und wie eine funktionierende Adressierung gelingt. Betrachten Sie die Standards, die unserer heutigen Kommunikation und dem Internet zugrunde liegen, sehen Sie, dass diese teilweise schon aus dem Jahr 1981 stammen und in den Grundgedanken sogar noch älter sind. Sie wurden vor einem ganz anderen Hintergrund entwickelt und waren nie für etwas wie die heutigen Anforderungen an unsere Kommunikation geschaffen. Von unseren aktuellen Schutzzielen der

Informationssicherheit war als einziges die Verfügbarkeit von Belang, aber eher im Sinne von klassischer Ausfallsicherheit und nicht mit Blick auf aktive Angreifer wie zum Beispiel im Kontext von Denial-ofService-Angriffen, bei denen Angreifer gezielt versuchen, Systeme und Netzwerke durch Überlastung an der Kommunikation zu hindern (siehe den Abschnitt zu Denial-of-Service-Angriffen).

Entwicklung des Internets Der Vorgänger des Internets, das Arpanet, ging bereits 1969 in Betrieb [Abb99] und vernetzte mit Unterstützung des Verteidigungsministeriums nach und nach die USamerikanischen Universitäten. Mit dem Arpanet ging ein fundamentaler Paradigmenwechsel einher, der heute immer noch Grundlage unserer Netzwerke ist. Von der ursprünglichen Leitungsvermittlung, bei der eine Leitung exklusiv zwischen zwei Kommunikationspartnern geblockt ist, ging es zur Paketvermittlung, dem »packet switching«. Damit wurde sukzessive auch die Datenübermittlung über Funk und Satelliten möglich. Die paketbasierte Kommunikation schickt einzelne Datenpakete vom Absender zum Empfänger, die unabhängig voneinander transportiert werden. Damit können die Pakete mehrerer Verbindungen über eine Leitung laufen. Jedes Paket trägt die Information über Absender und Empfänger mit sich und wird von den Vermittlungsstationen auf Basis dieser Information weitergereicht. Um unabhängiger von der Technologie zu sein, wurde ein Schichtenmodell für die Kommunikation eingeführt. Initial gab es im Arpanet nur 2 Schichten (Layer): »Hosts« und »Communications«. 1973 kam eine weitere Schicht hinzu, der »Application Layer« ([Abb99]). Der Application Layer ist für die Aktivitäten der Nutzerinnen wie den Zugriff aus der Ferne oder den Dateitransfer zuständig, der Host Layer ist für die Initiierung und Aufrechterhaltung von Verbindungen zwischen den jeweiligen Hostprozessen da und der Communications Layer schlussendlich kümmert sich um das Bewegen von Datenpaketen durchs Netzwerk. Aus diesen Erfahrungen haben sich in der Folge auch das bis heute verwendete TCP/IP-Protokoll und der OSI-Standard für gelayerte Kommunikationsprotokolle entwickelt. 1977 waren nach den schrittweisen Erweiterungen bereits 111 Computer an verschiedensten Standorten miteinander vernetzt und TCP/IP entwickelte sich in der 1980er Jahren zum Standard und der Grundlage des heutigen Internets.

Es gab damals noch kein E-Business und Vertrauensstellungen und digitale Identitäten existierten in der Form ebenfalls noch nicht. Heute sind Sie gleichzeitig Anbieter und Konsument von Informationen, das heißt, Sie benötigen Möglichkeiten, um sich zuverlässig und vertraulich

mit den richtigen Kommunikationspartnern auszutauschen. Sie wollen die Echtheit von Informationen überprüfen können und das Ganze sollte idealerweise selbst dann noch funktionieren, wenn Angreifer es bewusst auf Ihre Kommunikation abgesehen haben. Dies sind die typischen Ziele von Angreifern: Mitlesen von Daten: Sind Daten bei der Übertragung im Klartext lesbar beziehungsweise welchen Aufwand hat ein Angreifer, um diese zu lesen? Verhindern von Kommunikation: Kann ich eine unterbundene Datenübertragung erkennen? Umleiten von Daten: Kann ein Angreifer die Adressierung manipulieren? Ersetzen von Daten: Kann ich als Empfänger Veränderungen der Daten erkennen? Zumüllen mit Daten: Kann ein Angreifer meine Verbindung/Infrastruktur überlasten? Fälschen von Identitäten: Kann ein Angreifer den Absender fälschen? Die hierfür benötigten Schutzmechanismen wurden in den letzten 25 Jahren nach und nach ergänzt, waren aber in den verschiedenen Protokollen und Lösungen ursprünglich nicht enthalten. Zu den Ergänzungen gehören Methoden zur Authentifikation von Kommunikationspartnern und Daten, Vertrauensanker, die Verschlüsselung von Inhalten und vieles mehr. In Bezug auf die Schutzziele für die Informationssicherheit kann dies grundsätzlich wie folgt erreicht werden: Vertraulichkeit: durch Verschlüsselung, Integrität: durch digitale Signaturen und Hashwerte, Authentifizierung: durch Authentifikationsprotokolle, Non-Repudiation: durch digitale Signaturen,

Verfügbarkeit: redundante Verteilung der Daten oder IT-Systeme, Zugangskontrolle: durch Firewalls, Anonymität: zum Beispiel durch Onion-Routing – Tor-Netzwerk.

Grundlagen Bevor wir uns mit den konkreten Sicherheitserweiterungen auseinandersetzen, ist es wichtig, nochmal die Grundlagen unserer Netzwerkinfrastruktur zu betrachten. Unsere heutige Kommunikation richtet sich weitestgehend nach dem OSI-Referenzmodell [ITU94], allerdings mit TCP/IP nach einem vereinfachten Modell mit weniger Schichten. Die Zuordnung ist in Tabelle 21.1 dargestellt. Wir unterscheiden beim TCP/IP-Modell die physikalische Schicht (Physical Layer), die Netzzugangsschicht (Link Layer), die Netzwerkschicht (Network Layer), die Transportschicht (Transport Layer) und die Anwendungsschicht (Application Layer). Netzwerkprotokolle regeln dabei auf den verschiedenen Schichten den Zugang zum Netzwerkmedium, die Kommunikation zwischen zwei Netzwerkgeräten, das Routing (also die Routenplanung) und die Übermittlung von Paketen zwischen Start- und Zielgerät. Darüber hinaus werden auf Ebene der Anwendungsschicht über verschiedenste Protokolle Anwendungen auf Basis der Paketverbindung definiert. Die Netzwerkprotokolle sind als Standards über sogenannte Requests for Comments (RFCs) oder vergleichbare Dokumente definiert und beschreiben detailliert, wie ein Nachrichteninhalt, Absender, Empfänger und viele weitere Aspekte auszusehen haben. Auf allen Ebenen bis auf Layer 1 (physikalisch) gibt es inzwischen technische beziehungsweise protokollarische Erweiterungen, um die Schutzziele der Informationssicherheit für die Kommunikation zu gewährleisten. Beim physikalischen Layer kann der Zugang zum Medium auch nur physikalisch verhindert werden (siehe Tabelle 21.1).

OSISchicht

Hardware

7 Anwendung Rechner

TCP/IPSchicht

Beispiele

Anwendung

Browser, Mail-Programm

6 Präsentation Gateway, Proxy

Formate, Kodierung

5 Sitzung

http, https, ssh, telnet, smtp, imap

4 Transport

Transport

TCP, UDP

3 Netzwerk

Router

Netzwerk

IP, IPsec, ICMP

2 Verbindung

Bridge, Switch

Netzzugang

802.3 Ethernet

802.11 WLAN, ARP

1 physikalisch

Glas, Kupfer, Funk, Repeater

1000BASE-T, DSL

Tabelle 21.1: Übersicht über das OSI-Referenzmodell im Vergleich zum TCP/IP-Modell.

Sicherheitserweiterungen von Netzwerkprotokollen Im Folgenden beschäftigen wir uns mit die wichtigsten Sicherheitserweiterungen für die verschiedenen Netzwerkprotokolle und Schichten.

DNS, Anwendungsschicht Wenn Sie in Ihren Browser eine Adresse eintippen, zum Beispiel https://www.rainer-gerling.de, dann kann Ihr Rechner den Server nicht kontaktieren, denn dazu benötigt er die IP-Adresse des Servers. Zuständig zur Übersetzung eines Namens in die IP-Adresse ist der Domain Name Service (DNS). Wenn dieser Dienst ausfällt, können Rechner im Internet nicht mehr ohne Weiteres adressiert werden. Wenn Sie jetzt glauben, dass dieser fundamentale Dienst extrem sicher ist, werden Sie enttäuscht. Es gibt praktisch keine Sicherheit beim DNS. Die Datenpakete sind unverschlüsselt und nicht digital signiert. Die einzige »Sicherheit« ist eine 16-Bit-Zahl, die bei einer Anfrage mitgeschickt wird und die auch in der Antwort stehen muss.

Das Rückgrat des DNS-Dienstes sind 13 Root-Server (tatsächlich verbirgt sich dahinter eine verteilte Serverfarm mit mehr als 1500 Rechnern). Es gibt zwei Arten von normalen DNS-Servern: DNSResolver und DNS-Relays. Relays kennen einen oder zwei andere DNSServer und leiten eine Anfrage an diese weiter. Resolver können die IPAdresse tatsächlich finden. Wie geht das? Der Resolver fragt einen der Root-Server nach der IP-Adresse zum Rechnernamen www.rainer-gerling.de. Der Root-Server antwortet: »Keine Ahnung, aber frag mal a.dns.net«. Das ist einer der sieben für die Top-Level-Domain .de zuständigen DNS-Server. Also geht die Anfrage an den. Der antwortet dann: »Auch keine Ahnung, aber frag mal ns1034.ui-dns.de«. Das ist einer der Nameserver des Hosters. Und der antwortet auf die Anfrage erfreulicherweise »Ja, weiß ich, die IPAdresse ist 217.160.0.147«. So eine rekursive Abfragefolge läuft immer, wenn Sie einen Domain-Namen in ein Programm eingeben (siehe Abbildung 21.1a).

Abbildung 21.1: Der Ablauf der DNS-Auflösung mit normalen DNS (a) und DoT/DoH (b).

Alle Antworten, die ein Resolver bekommt, speichert er für einige Zeit in seinem Cache. Kommt die Anfrage nochmal, beantwortet er sie aus seinem Cache. Die DNS-Kommunikation läuft über den UDP-Port 53, bei größeren Paketen auch über den TCP-Port 53.

Wegen der fehlenden Sicherheitsfunktionen ist der DNS leicht anzugreifen. Ein Rechner glaubt die DNS-Antwort, die als erste Antwort kommt. Damit muss ein Angreifer nur schneller antworten. Folgt eine zweite, richtige Antwort wird sie verworfen. Da die falsche Antwort auch im Cache gespeichert wird, bleibt diese Antwort sogar für einige Zeit gültig. Deshalb muss DNS abgesichert werden. Es gibt zwei Möglichkeiten, den DNS doch abzusichern: DNSsec – das ist ein Verfahren, um DNS-Antworten digital zu signieren, damit die Antwort nicht manipuliert werden kann (Integrität). Die Root-Server und die .de-Server unterstützen DNSsec. Viele Unternehmen leider noch nicht. DNScrypt, DoH, DoT – das sind drei Verfahren zur DNSVerschlüsselung, um die Vertraulichkeit zu gewährleisten. Die RootServer unterstützen diese Verfahren nicht. Während klassisches DNS ein Dienst ist, den das Betriebssystem für die Anwendungen betreibt, gibt es einen Trend, das verschlüsselte DNS in den Anwendungen zu betreiben. Die Browser Chrome, Edge und Firefox unterstützen DoH am Betriebssystem vorbei. Und wie Sie in Abbildung 21.1b sehen, auch an der Unternehmensinfrastruktur vorbei! Die Browser senden DNS-Anfragen direkt an große Cloud-Provider. Was nun für die Privatsphäre besser ist, wenn andere Unternehmen oder der Provider die DNS-Anfrage sehen oder wenn ein US-amerikanischer Cloud-Provider die Anfrage bekommt, müssen Sie für sich selbst entscheiden. Wie gehen Sie im Unternehmen mit DNS um? Sie betreiben sicherlich einen eigenen DNS-Server, um Ihre internen Rechnernamen aufzulösen. Auf diesem sollten Sie DNSsec aktivieren. Dazu benötigen Sie keine PKI oder dergleichen. Das Modell der digitalen Signaturen im DNS ist genauso hierarchisch aufgebaut wie das DNS selbst. Die Schlüssel der .de-Nameserver sind von den Root Servern signiert. Ihre Schlüssel werden von den .de-Nameservern signiert. Mit Ihren Schlüsseln signieren Sie dann Ihre DNS-Eintrage.

Im DNS können Sie neben der IPv4-Adresse (A-Record) auch die IPv6Adresse (AAAA-Record), den Mail-Server Ihrer Domain (MX-Record), die DNSec-Schlüssel (DNSKEY-Record), die DNS-Signaturen (RRSIGRecord), Informationen zur TLS-Zertifikat-Verwaltung (DNS-Based Authentication of Named Entities, DANE) für Ihre Domain (TLSARecord) und ein universelles Feld (TXT-Record) abrufen. Der DNS ist eine verteilte Datenbank, die Informationen zu Ihrer Domain zur Verfügung stellt. Wegen der Verfügbarkeit sollten Sie für Ihre Domain mindestens zwei Name-Server betreiben. Die sollten nicht im gleichen Netz betrieben werden. Steht einer im Unternehmen, sollte der andere bei einem Provider angesiedelt sein (zum Beispiel ein virtueller Server in der Cloud).

HTTPS, SMTPS, Anwendungsschicht Auf der Ebene der Anwendungsschicht werden die gängigen Protokolle durch die Verwendung von SSL (früher) beziehungsweise TLS abgesichert und so um eine Transportverschlüsselung ergänzt (siehe hierzu Kapitel 23 und Kapitel 27 für weitere Details). TLS ermöglicht neben der Verschlüsselung auch die Authentifikation der Kommunikationspartner und schützt somit die Integrität der übermittelten Daten.

TCP und UDP, Transportschicht Eine Möglichkeit, Daten während des Transports zu verschlüsseln, nutzen wir fast jeden Tag: Immer wenn wir eine Webseite mit https:// aufrufen oder E-Mail-Server die Transportverschlüsselung SMTPS nutzen, sowie in zahlreichen anderen Fällen wird TLS verwendet. TLS ist die Transportverschlüsselung für eine TCP-Verbindung. Für UDPbasierte Verbindungen gibt es DTLS, das wiederum auf TLS basiert. Secure Socket Layer (SSL) 2.0 wurde 1995 veröffentlicht. SSL 1.0 wurde nie veröffentlicht. Bei SSL handelt sich um einen Vorläufer von TLS. SSL 3.1 wurde in TLS 1.0 umbenannt und

erschien 1999. Mittlerweile sollten alle Versionen von SSL 2.0 bis TLS 1.1 nicht mehr benutzt werden, da sie nicht sicher sind (RFC 6176, 7568, 8996). Auch das BSI empfiehlt nur noch den Einsatz von TLS 1.2 und TLS 1.3. Beide Protokolle gelten als sicher, sie unterscheiden sich in der Art der genutzten Verschlüsselung. Beim Verbindungsaufbau per TLS prüft der Client die Identität des Servers, woraufhin Client und Server Schlüssel vereinbaren zur Verschlüsselung des eigentlichen Datenaustauschs. Schauen wir uns das Protokoll an: 1. Der Client schickt die »Client Hello«-Nachricht an den Server. Diese enthält eine Liste der vom Client unterstützen TLS-Versionen und Verschlüsselungsalgorithmen sowie eine Zufallszahl client_random. Die Zufallszahl enthält die aktuelle Uhrzeit und das aktuelle Datum, um zu verhindern, dass dieselbe Zufallszahl nochmals verwendet werden kann. Dieses Datenpaket wird unverschlüsselt geschickt. 2. Der Server antwortet mit der »Server Hello«-Nachricht. Diese enthält die vom Server ausgewählte TLS-Version und die ausgewählten Verschlüsselungsalgorithmen. Zusätzlich schickt der Server sein X.509-Zertifikat, das seinen öffentlichen Schlüssel enthält, und die X.509-Zertifikate der ausstellenden Zertifizierungsstelle. Auch der Server schickt eine Zufallszahl server_random. Diese Nachricht ist auch unverschlüsselt. 3. Der Client prüft das Zertifikat und generiert eine weitere Zufallszahl, das pre_master_secret. Beim RSA-Schlüsselaustausch wird jetzt die Zufallszahl mit dem öffentlichen Schlüssel des Servers aus dem X.509-Zertifikat verschlüsselt. Dies ist die erste Verschlüsselungsoperation, sie findet auf dem Client statt. Der Client schickt die verschlüsselte Zufallszahl an den Server. Danach berechnet der Client aus dem client_random, dem server_random und dem pre_master_secret das master_secret mithilfe einer speziellen kryptografischen Funktion. Aus dem master_secret werden dann die Schlüssel für die eigentliche Verschlüsselung der Daten berechnet.

4. Der Server entschlüsselt mit seinem privaten Schlüssel das pre_master_secret und berechnet dann ebenso das master_secret und daraus die Schlüssel für die Datenverschlüsselung. Wenn der Client jetzt das erste Datenpaket erhält und dieses sich entschlüsseln lässt, weiß der Client, dass er mit dem richtigen Server redet. Ein Angreifer könnte das ganze Protokoll mitspielen und sich als der Server ausgeben. Der Angreifer kann sich auch problemlos das X.509Zertifikat des Servers beschaffen. Überlegen Sie sich, warum! Er kann nur das pre_master_secret nicht entschlüsseln, da er den privaten Schlüssel des Servers nicht kennt. Würde der Angreifer das pre_master_secret raten und daraus die weiteren Schlüssel berechnen, könnte der Client die Daten nicht entschlüsseln. Sie sehen hier einen indirekten Beweis für den Besitz des privaten Schlüssels. Dieses Protokoll funktioniert leider nur so lange, wie auf dem Server nur eine Webseite angeboten wird. Werden auf einem Server mehrere Webseiten angeboten und hat jede ihr eigenes X.509-Zertifikat, dann weiß der Server nicht, welches X.509-Zertifikat er an den Client schicken soll. Da benötigt der Server einen Tipp vom Client. Im »Client Hello« wird dazu der Name des gewünschten Servers – als ServerName-Indication-(SNI-)Feld – im Klartext mitgeschickt. Dieser beschriebene Austausch hat aber auch so noch ein Problem: Stellen Sie sich vor, eine Drei-Buchstaben-Behörde überwacht ein EMail-Portal und speichert die komplette abgehörte und verschlüsselte Kommunikation. Irgendwann kommt die Behörde in den Besitz des privaten Schlüssels des E-Mail-Portals. Da auch alle Daten dieser TLSAushandlung gespeichert wurden, können alle (!) pre_master_secretFelder entschlüsselt werden. Damit lassen sich dann auch alle aufgezeichneten Daten entschlüsseln. Es gibt zum Glück eine Lösung für das Problem. Schauen wir uns die Lösung an. Neben der beschriebenen RSA-Schlüsselvereinbarung gibt es auch noch die Diffie-Hellman-(DH-)Schlüsselvereinbarung. Den DHAustausch haben Sie in Kapitel 17 kennengelernt.

1. Der Client schickt die »Client Hello«-Nachricht an den Server. Das Datenpaket ist inhaltlich identisch zur RSA-Schlüsselaushandlung. 2. Der Server antwortet auch mit der »Server Hello«-Nachricht. Das Paket enthält den gleichen Inhalt wie zuvor. Zusätzlich werden jedoch das client_random und der Diffie-Hellman-Parameter des Servers mitgeschickt. Über die beiden Secrets und den DiffieHellman-Parameter des Servers wird eine digitale Signatur berechnet. 3. Der Client prüft das Zertifikat und verifiziert die Signatur. Damit ist der Server direkt identifiziert. Der Client schickt seinen DiffieHellman-Parameter an den Server. 4. Danach berechnen der Client und der Server aus den DH-Parametern das pre_master_secret. Aus diesem und dem client_random sowie dem server_random wird dann das master_secret mithilfe einer speziellen kryptografischen Funktion berechnet. Aus dem master_secret ergerben sich dann die Schlüssel für die eigentliche Verschlüsselung der Daten. Beim Diffie-Hellman-Schlüsselaustausch haben Sie zwei Möglichkeiten: Es wird ein statischer privater Schlüssel generiert und der wird langfristig benutzt. Das führt schon zu unterschiedlichen Verschlüsselungsschlüsseln für jede Sitzung. Aber hier gilt dasselbe wie beim RSA-Schlüsselaustausch: Wenn der private Diffie-HellmanSchlüssel des Servers kompromittiert ist, können alle verschlüsselten Verbindungen zu dem Server entschlüsselt werden. Diese Problem löst die »Perfect Forward Secrecy«: der Server generiert bei jeder Verbindung einen neuen privaten Schlüssel. Wir reden dann von einem »ephemeral« (flüchtigen) Diffie-Hellman-Schlüsselaustausch. Der private Schlüssel wird nur im RAM (das ist bekanntlich ein flüchtiger Speicher) gehalten und nie auf einem Datenträger gespeichert. Eine wichtige Änderung brachte im Jahr 2020 TLS 1.3. Es ist nun nur noch ein Schlüsselaustausch mit »Perfect Forward Secrecy« zulässig. Damit gibt es bei TLS 1.3 keinen RSA-Schlüsselaustausch mehr.

Zusätzlich wurde die Schlüsselvereinbarung optimiert, sodass es nur noch zwei Phasen gibt: 1. Der Client schickt die »Client Hello«-Nachricht an den Server. Das Datenpaket enthält eine Liste der unterstützen Algorithmen sowie seinen Diffie-Hellman-Parameter. Der Client weiß zu diesem Zeitpunkt noch nicht, welchen Algorithmus der Server auswählt, aber er schickt prophylaktisch einen Diffie-Hellman-Parameter für den Algorithmus, den er als favorisiert gekennzeichnet hat. Meistens geht das gut und spart Zeit. 2. Der Server schickt sein X.509-Zertifikat und seinerseits seinen Diffie-Hellman-Parameter. Das X.509-Zertifikat wird verschlüsselt gesendet, da im Zertifikat der Name der Webseite enthalten ist. Außerdem schickt er eine Signatur über das Datenpaket, damit der Client die Authentizität verifizieren kann. Client und Server können jetzt aus den Diffie-Hellman-Parametern die Schlüssel für die Datenverschlüsselung berechnen. Während TLS 1.2 noch 37 verschiedene Cyphersuiten (RFC 5246) verwendete, gibt es bei TLS 1.3 nur noch fünf (RFC 8446). Sie sehen, die Auswahl der kryptografischen Algorithmen wurde verschlankt, oder besser: »ausgemistet«. Eine Cyphersuite ist eine Kombination von Algorithmen für Schlüsselvereinbarung, Signatur, Datenverschlüsselung und Hashfunktion. Jede Cyphersuite hat einen offiziellen Namen. Der beginnt mit TLS und listet dann die vier Algorithmen. Wenn RSA sowohl für den Schlüsselaustausch als auch für die Signatur benutzt wird, wird es nur einmal aufgeführt. Hier einige Beispiele für TLS 1.2: TLS_RSA_WITH_AES_128_CBC_SHA256, RSASchlüsselvereinbarung, RSA-Signatur, AES im CBC-Modus mit 128 Bit Schlüssellänge und die Hashfunktion SHA 256, nicht vom BSI empfohlen; TLS_RSA_WITH_AES_256_CBC_SHA256, RSASchlüsselvereinbarung, RSA-Signatur, AES im CBC-Modus mit

256 Bit Schlüssellänge und die Hashfunktion SHA 256, nicht vom BSI empfohlen; TLS_DH_RSA_WITH_AES_256_CBC_SHA256, Diffie-HellmanSchlüsselvereinbarung, RSA Signatur, AES im CBC-Modus mit 256 Bit Schlüssellänge und die Hashfunktion SHA 256, vom BSI als Notlösung empfohlen, falls DHE nicht möglich; TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, Diffie-Hellman ephemeral Schlüsselvereinbarung, RSA Signatur, AES im CBCModus mit 256 Bit Schlüssellänge und die Hashfunktion SHA 256, vom BSI empfohlen; TLS_ECDH_RSA_WITH_AES_256_CBC_SHA256, ECC DiffieHellman-Schlüsselvereinbarung, RSA Signatur, AES im CBCModus mit 256 Bit Schlüssellänge und die Hashfunktion SHA 256, vom BSI als Notlösung empfohlen, falls DHE nicht möglich; TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256, ECC DiffieHellman ephemeral Schlüsselvereinbarung, RSA Signatur, AES im CBC-Modus mit 256 Bit Schlüssellänge und die Hashfunktion SHA 256, vom BSI empfohlen. Bei TLS 1.3 werden immer ein ECDH-Schlüsselaustausch und ein ECSignaturverfahren verwendet und deshalb nicht mehr aufgelistet. Angeben werden nur zwei Parameter: die Verschlüsselungsfunktion mit kombinierter Integritäts-Hashfunktion und eine Hashfunktion zur Verwendung in der Schlüsselaufbereitung. TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, TLS_AES_128_CCM_8_SHA256. Die beiden Cipher Suiten TLS_CHACHA20_POLY1305_SHA256 und TLS_AES_128_CCM_8_SHA256 werden vom BSI nicht empfohlen.

Ausführliche Empfehlungen zum Einsatz von TLS 1.2 und 1.3 finden Sie in der technischen Richtlinie TR-02102-2 des BSI.

IP und IPsec, Netzwerkschicht Auf der Network-Layer-Ebene betrachten wir Besonderheiten von IP Version 4 (IPv4) nach RFC 791 und IP Version 6 (IPv6) nach RFC2460. Da die IPv4-Adresse 32 Bit lang ist, gibt es für die heutige Anzahl an Geräten viel zu wenig IP-Adressen, genauer gesagt nur 4.294.967.296  Stück. Die Zahl der möglichen IP-Adressen ist so »klein«, dass Sie bei guten Internetanbindungen (1–10 GBit) einen vollständigen Scan aller IP-Adressen im Internet durchführen könnten, zum Beispiel um Schwachstellen zu finden. Um mit den viel zu wenigen IP-Adressen auszukommen, wird das NAT-Protokoll eingesetzt (siehe Kapitel 22), um die öffentliche IP-Adresse am Router in private IP-Adressen umzusetzen. Neben der Tatsache, dass dies eine Art Firewall liefert, schützt es auch die Privatsphäre der Clients hinter dem Router, da alle Clients nach außen mit der gleichen IP-Adresse kommunizieren. Dies ändert sich mit IPv6, da die Adresse nun 128 Bit lang ist, das heißt, es gibt rund 340 Sextillionen Adressen, das sind 667 Billiarden Adressen pro mm Erdoberfläche. Somit wird NAT hier nicht mehr benötigt. Die ersten 64 Bit der Adresse beschreiben das Netzwerk, die folgenden 64 Bit die Netzwerkschnittstelle, die bei einer Autokonfiguration aus der MAC-Adresse abgeleitet wird. Damit ändert sich bei einer IPv6-Adresse eines Geräts nur der vordere Teil der IP-Adresse, was ein Tracken der Nutzerinnen zunächst erleichtert. Deshalb gibt es zusätzlich die Möglichkeit, sogenannte Privacy Extensions einzusetzen, wodurch wird der hintere Teil der IP-Adresse bei jedem Start des Geräts zufällig gewählt wird. Wenn ein Rechner bei jedem Start eine andere IP-Adresse hat, ist zwar ein Tracking nicht mehr möglich, allerdings erschwert es auch der IT-Administration die Fehlersuche, wenn Probleme auftreten. Auf der Ebene der Netzwerkschicht gibt es zusätzlich mit IPsec eine Sicherheitsarchitektur für das IP-Protokoll, die eine verschlüsselte Kommunikation ermöglicht und zum Beispiel zum Aufbau von virtuellen privaten Netzwerken (VPN) verwendet werden kann. IPsec ist Bestandteil des IPv6-Protokolls und in der Variante, in der wir es heute

nutzen, eine Rückportierung nach IPv4. IPsec ersetzt auf der Netzwerkschicht die IP-Schicht und kann damit für alle Netzwerkkommunikation aus den darüber liegenden Schichten verwendet werden. Da IPsec nur eine Möglichkeit zum Aufbau von VPNs ist, beschreiben wir IPsec im Detail zusammen mit den anderen VPN-Lösungen in Kapitel 23.

ARP und 802.1X, Verbindungsschicht Auf der Ebene des Netzzugangs (Link Layer) geht es aus Sicherheitssicht primär darum, den Zugang zum Netzwerkmedium im lokalen Netzwerk auf Protokollebene zu regeln. Einige von Ihnen kennen vielleicht vom WLAN-Router zuhause die Zugangskontrolle auf Basis der Media-Access-Control-Adresse (MAC-Adresse). Diese liefert aber aus verschiedenen Gründen nicht die stärksten Sicherheitsgarantien, da zum Beispiel versierte Nutzerinnen die MAC-Adresse auf den Endgeräten normalerweise leicht anpassen können. Somit würde die Kenntnis eine erlaubten MAC-Adresse bereits ausreichen, um diesen Schutz zu überlisten. Während Kommunikation wird im lokalen Netzwerk das Address Resolution Protocol (ARP) verwendet- um IPv4-Adressen in Hardwareadressen, also MAC-Adressen zu übersetzen. Aufgrund fehlender Sicherheitsmechanismen gibt es auch hier Risiken, die als ARP-Spoofing und ARP-Cache-Poisioning bekannt sind. Hier senden Angreifer manipulierte Anfragen über das ARP-Protokoll, um falsche Adressen in den ARP-Caches der Geräte zu etablieren und darüber Kommunikationsinhalte als »Man-in-the-Middle« zu sich selbst umzulenken. Mit dem Port-based Network Access Control Protocol (802.1X) ist es möglich, den Netzzugang portbasiert einzuschränken. Um Zugang zu LAN und WLAN zu erhalten, fragen Sie (als Supplicant) passwort- oder zertifikatsbasiert beim Authenticator den Zugriff zum Netzwerk an (als Authenticator kann zum Beispiel ein Switch oder ein WLAN Access Point dienen, der 802.1X unterstützt). Der Authenticator fragt dann beim Authentication-Server (also einem Server zur Authentifikation der Nutzerinnen wie zum Beispiel der Remote Authentication Dial-in User

Service, kurz RADIUS) an, vergleiche Abbildung 21.2. Als Authentifikationsprotokoll wird in der Regel das Extensible Authentication Protokoll (EAP) verwendet. 802.1X wird von einer Vielzahl von Geräten unterstützt, für Windows, macOS und Linux gibt es Lösungen. Eine Herausforderung ist allerdings, dass noch immer nicht alle gewünschten Geräte (wie zum Beispiel manche Drucker) 802.1X unterstützen.

Abbildung 21.2: Darstellung des Zusammenspiels von Supplicant, Authenticator und Authentication-Server.

Zusätzlicher Schutz kann im Rahmen des 802.1X-Standards (aktuell 802.1X-2020) darüber gewonnen werden, dass die Kommunikation zwischen den Ports von Supplicant und Authenticator mithilfe des MACSec Key Agreement Protocol (MKA) und dem MACSec-Standard 802.1AE verschlüsselt wird. Die Garantien im Rahmen der Authentifikation lassen sich noch zusätzlich stärken, indem 802.1AR2018 sogenannte Secure Device Identifiers (DevIDs) liefert, also eindeutige Geräte-IDs für die Authentifikation per EAP, die im Gegensatz zur MAC-Adresse nicht trivial manipuliert werden können beziehungsweise nicht wie Passwörter oder Schlüssel im normalen EAPVerfahren gegebenenfalls über 802.1X kopiert oder ausgelesen werden können.

Netzwerkzugang Ohne besondere Vorkehrungen zu treffen, ist bei kabelgebundener Kommunikation im Netzwerk der Zugang zu einer Netzwerkdose gleichbedeutend mit dem Zugriff auf das Netzwerk. Netzwerkports sind häufig in »öffentlichen Räumen« frei zugänglich oder zumindest für den an sich gewünschten Publikumsverkehr erreichbar. Ein typisches Beispiel sind hier Krankenzimmer im Krankenhaus, hier waren in der Vergangenheit häufig Netzwerkdosen für medizinische Geräte ohne

weiteren Schutz zugänglich. Der Zugang zu Ihrem Netzwerk sollte also grundsätzlich gegen unbefugten Zugriff geschützt sein. Physikalisch könnte man den Zugang bereits über Port-Schlösser lösen, diese bieten aber in der Regel keine hohe Sicherheit. Alternativen sind Gehäuse mit robusten Schlössern oder abschließbare Netzwerkschränke, diese sind aber auch unter praktischen und optischen Gesichtspunkten außerhalb von Netzwerkverteilerräumen oder Serverräumen keine sinnvolle Lösung. Sollten also Unbefugte prinzipiell physikalischen Zugang zum Medium bekommen können, benötigen Sie alternative Schutzmechanismen. Viele von Ihnen kennen hier sicherlich die Schutzmechanismen Ihres häuslichen WLAN-Routers oder WLAN-Access-Points: Häufig gibt es eine MAC-Adresskontrolle in den WLAN-Zugangsgeräten, sodass nur darüber der Zugang zum WLAN gewährt wird. Hinzu kommt die WLAN-Verschlüsselung »Wi-Fi Protected Access 3« (WPA3), die entweder ein Passwort als sogenannten Pre-shared Key (WPA3Personal) oder Authentifikationsinformationen zur Authentifikation über 802.1X mit EAP benötigt (WPA3-Enterprise) [WFA20]. Betrachtet man die MAC-Adress-Filterung, muss man sagen, dass dies leider nur eine trügerische Sicherheit bietet: Ein Angreifer muss nur eine gültige MACAdresse in Erfahrung bringen und bei sich selbst konfigurieren. Die kryptografische Sicherheit von »WPA3-Personal« ist sehr gut. Allerdings ist der Umgang mit dem »WLAN-Passwort« bei zahlreichen Nutzerinnen zu locker, da das Passwort oft weitergegeben wird. In vielen Besprechungsräumen hängt das »WLAN-Passwort« sogar an der Wand und ist somit jeder Besucherin ersichtlich. »WPA3-Enterprise« verwendet ein individuelles Passwort pro Nutzerin. Bei der Anmeldung am WLAN verwendet also jede Nutzerin ihr eigenes Passwort, das gegen eine Nutzerdatenbank verifiziert wird.

MAC-Adressen Die Media Access Control-Adresse, kurz MAC-Adresse [Soc17], wird zwar grundsätzlich weltweit bei der Herstellung von Hardware eindeutig zugeordnet und

sollte unveränderbar sein, sie lässt sich aber durch die Nutzerin ändern und wird heute häufig über Software beziehungsweise die Firmware in der Hardware festgelegt. Die Adressierung im Ethernet geschieht auf Basis von MAC-Adressen. Betrachten wir beispielsweise die MAC-Adresse b8:27:eb:02:25:49, hierbei handelt es sich um die hexadezimale Darstellung von 48 Bit. Die ersten drei Paare (24 Bit) sind Herstellern zugewiesen und können zum Beispiel über die IEEE nachgeschlagen werden [Soc17]. In unserem Beispiel stehen die erste drei Paare, b8:27:eb, für die Raspberry Pi Foundation. Die Vergabe dieser »Herstellerkennung« erfolgt durch die IEEE. Die folgenden drei Paare in der Adresse werden zur Durchnummerierung der Geräte des Herstellers verwendet.

Das Address Resolution Protocol (ARP) verknüpft eine IPv4-Adresse mit der MAC-Adresse. Ein Gerät schickt dafür zum Beispiel einen Broadcast à la: »Wer hat die IP-Adresse 192.168.1.108?«. Darauf antwortet das Gerät mit dieser Adresse: »Ich! Meine MAC-Adresse lautet b8:27:eb:02:25:52.«. Jedes Gerät speichert diese in seiner »ARP-Tabelle«, die sukzessive gelernt wird. Ausgelesen wird die ARPTabelle, der sogenannte ARP-Cache, unter Windows und macOS in der Kommandozeile/Terminal durch arp -A. Im Fall von IPv6 wird dies nicht vom ARP-Protokoll übernommen, sondern vom Neighbor Discovery Protocol (NDP). Das ARP bietet keinerlei Sicherheitsfunktionalität. Insbesondere Angreifer, die sich im lokalen Netz befinden, könne die ARP-Tabellen der dortigen Rechner manipulieren (ARP-Poisening). Derartige Angriffe sind aber zumindest über das Monitoring des ARP-Datenverkehrs detektierbar. Dies sollte ein Unternehmen tun. Die IP-Adresse wird vom DHCP-Server ebenfalls auf Basis der MACAdresse zugeteilt. Im Rahmen einer dynamischen DHCP-Konfiguration bekommt jedes Gerät ohne weitere Zugangsbeschränkungen eine IPAdresse für eine bestimmte Zeitdauer zugeteilt (Lease-Zeit). Bei statischem DHCP erhält jeder Rechner auf Basis der MAC-Adresse eine vorher definierte IP-Adresse. Im Hinblick auf die Sicherheit hat statisches DHCP aber keinen nennenswerten Effekt, da eine IP-Adresse und die notwendigen Parameter auch manuell am Client konfiguriert werden könnten und dann ebenfalls eine Kommunikation im Netzwerk

ermöglichen würden. Statisches DHCP hilft hier vor allem der Übersichtlichkeit und Organisation der Geräteadministration.

Netzwerksegmentierung Ein weiterer wichtiger Sicherheitsaspekt innerhalb von Netzwerken bezieht sich auf die Segmentierung von Netzwerken. Nicht alle Nutzerinnen und Geräte im Netzwerk benötigen Zugriff auf jeden Dienst und jeden Server. Auf Basis der identifizierten Kronjuwelen, der Rollen und Berechtigungskonzepte sowie einer Risikobewertung wird ein Netzwerk in unterschiedliche Bereiche aufgeteilt (siehe Abbildung 21.3).

Abbildung 21.3: Segmentierung eines Netzwerks.

Eine Segmentierung kann einerseits natürlich physikalisch erfolgen, das heißt Netzwerkports sind nach Zugriffsrechten fest auf die passenden Switches aufgeteilt und Router und Firewalls schränken die unterschiedlichen Zugriffe ein. Dies ist aber in der Regel viel zu unflexibel, da je nach Client und Raum unter Umständen am gleichen Port unterschiedliche Netzwerke benötigt werden. Das einfachste Beispiel sind hier sicherlich Besprechungsräume, die vielfältig genutzt werden, zum Beispiel von verschiedenen Abteilungen und auch von Gästen. Gästen wird gegebenenfalls nur ein sehr eingeschränkter Zugriff gewährt, andere Nutzerinnen benötigen eventuell ihr spezielles Abteilungsnetz.

Die gängige Lösung, die auch gleichzeitig die gewünschte Flexibilität liefert, ist eine virtuelle Aufteilung der Netzwerke in einer physischen Installation. Grundlage hierfür sind sogenannte Virtual Local Area Networks (VLANs), sie sind im IEEE-Standard 802.1Q definiert. Die Identifikation des richtigen VLANs erfolgt über ein Feld im Header eines Ethernet-Frames und die Konfiguration der VLANs passiert in den Switches. Insgesamt sind auf Basis des Standards maximal 4096 unterschiedliche VLANs in einem Netzwerk möglich. Ein für Firmen typisches Beispiel ist, dass die VoIP-basierte Telefonie mit stationären Telefonen über ein eigenes VLAN läuft. Am Ende können nur Geräte im gleichen VLAN miteinander kommunizieren. An sogenannten Trunk Ports sind alle VLANs vorhanden (siehe Abbildung 21.4). Router können Pakete zwischen den unterschiedlichen VLANs versenden. VLANs bieten eine gute logische Trennung der Netze, aber am Ende keine 100%ige Sicherheit. Insbesondere Konfigurationsfehler und Softwarebugs können hier zu Problemen führen, die bei einer kompletten physischen Trennung gar nicht erst vorkommen können.

Abbildung 21.4: VLAN-Beispiele.

Denial-of-Service-Angriffe Denial-of-Service-Angriffe (DoS-Angriffe) haben das Ziel, die Server eines Opfers zu überlasten und damit die von ihm angebotene Dienstleistung zu unterbinden. Um dies zu erreichen, versuchen Angreifer, an einen Server oder einen Dienst so viele Anfragen zu senden, dass der überfordert ist und in die Knie geht. Ein typisches Beispiel hierfür ist die Verbindungsinitialisierung mithilfe von SYN-

Paketen, also den ersten Paketen beim Aufbau einer TCP/IP-Verbindung. Durch eine gefälschte Absenderadresse des Angreifers antwortet der angegriffene Server an eine falsche Antwortadresse und wartet vergeblich auf die Antwort des Clients, während er die Verbindung und den dafür reservierten Speicher aufrecht hält. Durch sehr viele unvollständige Verbindungsaufbauten verbraucht der Server zu viel Speicher und kann nicht mehr reagieren Allerdings wird es für einen Angreifer heute immer schwieriger, von einem einzigen Rechner aus einen Server zu überlasten. Mit den heutigen Bandbreiten und Berechnungskapazitäten wird dies selbst bei mittelklassigen Servern für Angreifer sehr aufwendig, zumal normale DoS-Angriffe sich recht leicht erkennen und abwehren lassen [BSI21]. Das Grundinteresse von Angreifern bei Denial-of-Service-Angriffen ist es daher, selbst weniger Ressourcen in Form von Bandbreite und zur Berechnung beziehungsweise Erstellung von Anfragen einsetzen zu müssen, als der angegriffene Server bei der Verarbeitung benötigt. Daher ist die heute viel gängigere Variante des Denial-of-Service-Angriffs der sogenannte Distributed-Denial-of-Service-Angriff, also der »verteilte DoS-Angriff«. Hierbei kommen eine Vielzahl an Angriffsrechnern zum Einsatz, die die Bemühungen des Angreifers vervielfachen sollen. Diese gehören den Angreifern in der Regel nicht selbst, sondern es handelt sich häufig um gehackte Rechner (Bots) in Botnetzen. Diese erhöhen die Möglichkeiten der Angreifer erheblich, zusätzlich werden häufig auch Dienste ausgenutzt, die noch eine zusätzliche Verstärkung (Amplification) ermöglichen. Ein solche Verstärkung kann in Einzelfällen bis zu Faktoren von über 50.000 (Größenfaktor zwischen Anfrage und Antwort) führen. Zu Diensten, die in der Vergangenheit für Amplification-Angriffe genutzt wurden, gehört zum Beispiel DNS mit der sogenannten DNS Amplification Attack [KMGG07], die zu den Distributed-ReflectedDenial-of-Service-Angriffen gehört. Ziel einer DNS Amplification Attack ist es, mithilfe des DNS Antworten von DNS-Resolvern in Richtung der Opfer zu leiten, die wesentlich größer sind als die, die der Angreifer verwendet hat. Dies ist bei normalen DNS bis zu einem Faktor

von 60 und bei verschiedenen Antworttypen sogar bis 72 [VE06], [CISA19] bereits gezeigt worden. Durch die gefälschte Absenderadresse wird die Vielzahl der Antworten, die die Bots auf Befehl ausgelöst haben, an den angegriffenen Server weitergeleitet und zwingen ihn so in die Knie. Bei der Nutzung von DNSSEC waren sogar Verstärkungsfaktoren bis zu 179 möglich, was natürlich nicht bedeutet, dass DNSSEC nicht eingesetzt werden sollte. Im Gegenteil, es muss bloß richtig konfiguriert sein und man muss sich auch hier gegebenenfalls mit Gegenmaßnahmen auseinandersetzen. Die Software Memcached (eine Caching-Lösung für Datenbanken im Webanwendungskontext) konnte vor der Version 1.5.6 aufgrund eines Softwarefehlers ebenfalls für einen Amplification-Angriff herangezogen werden. Der Anbieter Cloudflare berichtet hier von einem Faktor von 51.200, der beobachtet wurde [Maj18], [Mem18]. Die Angriffe unterscheiden sich also deutlich im Hinblick auf die Risikobetrachtung: Manchmal werden Protokolle aufgrund Ihrer gewünschten Eigenschaften für einen solchen Angriff missbraucht. Dann ist eine Lösung häufig deutlich komplexer, da Protokolle nicht immer einfach und schnell geändert werden können, während ein Softwarefehler als Ursache oft mit einem Patch behoben werden kann. Bei einem Smurf-Angriff steht der Ping-Befehl im Fokus. Mit dem PingBefehl können Sie unter Angabe des Zielrechners (Hostname oder IPAdresse) überprüfen, ob dieser gerade im Netzwerk erreichbar ist. Ist er verfügbar, erhalten Sie eine Antwort mit der Angabe, wie lange das Datenpaket hin und zurück benötigt. Grundlage für den Ping-Befehl ist das ICMP-Protokoll mit den Funktionen »Echo Request« und »Echo Reply«. Der Angreifer schickt dabei einen »Echo Request« an einen Zielrechner und gibt dabei als gefälschte Absenderadresse die des Opfers an. Der Zielrechner verarbeitet den »Echo Request« und schickt aufgrund der gefälschten Absenderadresse den »Echo Reply« an das Opfer. Die Effizienz dieses Angriffs lässt sich deutlich steigern, wenn als Adresse für den Zielrechner eine sogenannte Broadcast-Adresse angegeben wird. Damit wird der »Echo Request« dann an alle Rechner in dieser Broadcastdomäne weitergeleitet und produziert damit auch auf

jedem aktiven Rechner eine Antwort an das Opfer und damit ein vervielfachtes Bombardement [Kum07]. Eine besondere Herausforderung stellen im Kontext von Malware und Botnetzen, die für DDoS-Angriffe herangezogen werden, Geräte aus dem Internet der Dinge (IoT-Geräte) dar. Sie werden in der Regel aus Kostengründen sehr einfach produziert und verfügen oft nicht über hochwertige Software, die insbesondere auch keine Möglichkeiten für (Sicherheits-)Updates bietet. Und selbst wenn sich Mühe gegeben wurde, ist die Verfügbarkeit von Updates für diese Geräte deutlich beschränkt. Geräte wie Webcams, Funksteckdosen und so weiter werden in der Regel dennoch über recht lange Zeiträume eingesetzt – das sollte also auch für Sie ein Kriterium beim Kauf sein. Ähnlich, aber nicht ganz so schlimm, ist es bei vielen Smartphones, bei denen (Sicherheits-)Updates nur über einen viel zu kurzen Zeitraum nach dem Kauf angeboten werden, auch wenn die Geräte oft über 3–5 Jahre verwendet werden. Diese Gerätetypen sind einfache und lohnende Ziele für Angreifer, welche leicht zu kompromittierende Geräte für ihr Botnetz benötigen. Selbst große Anbieter wie Google und Amazon Web Services sind von DDoS-Angriffen betroffen. Einer der größten bekannten DDoS-Angriffe traf 2017 Google und erreichte in der Spitze den gigantischen Umfang von 2,5 Terabit/Sekunde. 2020 registrierte Google erstmals Angriffe mit 690 Millionen Netzwerkpaketen pro Sekunde sowie einen mit mehr als 6 Millionen HTTPS-Anfragen pro Sekunde [Men21]. Nachdem wir schon ein paar Beispiele für Angriffe kennengelernt haben, stellen Sie sich sicherlich die Frage, was Sie dagegen tun können. Können wir so einen Angriff nicht technisch verhindern? Das ist in der Tat gar nicht so einfach, insbesondere nicht, wenn bisher unbekannte Dienste genutzt werden. Für die bekannten Angriffe und ihre Muster kann man moderne Firewalls (vergleiche Kapitel 22) einsetzen, die in der Regel zusätzliche Schutzfunktionen hierfür anbieten. Der effizienteste Schutz ist aber neben aktiven Gegenmaßnahmen zu Beginn eines Angriffs die Möglichkeit, extrem gut skalieren zu können und Ihre Dienste gegebenenfalls sogar über verteilte georedundante Angebote

anzubieten (zum Beispiel über Akamai). Das erhöht die Chancen, durch ein effizientes Fail-over die Dienste am Laufen zu halten und erhöht den Aufwand für Angreifer nochmal deutlich. Am Ende landen wir aber auch hier wieder bei einer Risikoabwägung – wie wahrscheinlich ist es, dass Sie von wirklich großen professionell betriebenen DDoS-Angriffen betroffen sind wie zuletzt Google? Und wie kritisch ist ein Angebotsausfall für Ihr Geschäft? Auch hier wird ein Onlineshop sicherlich anders bewertet als eine informative Firmenwebseite. Bei wirklich professionellen Angriffen wie dem auf Google ist der organisatorische und finanzielle Aufwand für präventive Maßnahmen enorm, aber Sie werden wahrscheinlich auch kein so attraktives Ziel wie Google sein.

Anonymisierung in Netzwerken Wenn Sie die normale Infrastruktur des Internets verwenden, ist Ihre Kommunikation, also dass Sie einen bestimmten Server kontaktieren beziehungsweise mit ihm kommunizieren, transparent für alle Beteiligten. Selbst wenn Sie zum Beispiel eine Ende-zu-EndeVerschlüsselung (siehe Kapitel 17) über TLS für Ihren Dienst verwenden und Ihre Kommunikationsinhalte verbergen, so sind dennoch die Metadaten der Verbindung offensichtlich. Wenn Sie jedoch Informationen und Daten von einem Dienst abrufen möchten, ohne Ihre Identität in Form Ihrer IP-Adresse preiszugeben, benötigen Sie einen Anonymisierungsdienst. Die bekannteste Möglichkeit zur Anonymisierung im Internet ist der Tor-Dienst [Tor21], für dessen Nutzung in allen gängigen Betriebssystemen der Tor-Browser zur Verfügung steht. Die Grundidee des Tor-Dienstes geht auf das sogenannte Onion-Routing zurück. Grundidee dabei ist, dass auf Basis unterschiedlicher Schichten einer asymmetrischen Verschlüsselung (wie bei einer Zwiebel) ein Knoten im Netzwerk immer nur den Kommunikationspartner direkt vor und direkt nach sich kennt. Ziel ist es, hierdurch den ursprünglichen Absender und das Ziel eines Datenpakets zu verschleiern. Der Tor-Dienst wählt hierzu für eine Verbindung eine zufällige Route durch die Knoten des Tor-

Netzwerks inklusive eines Eingangs- und eines Ausgangsknotens. Das Tor-Netzwerk hat 2002 zum ersten Mal den Betrieb aufgenommen und wurde 2004 im Detail vorgestellt [DMS04], damals verfügte es bereits über etwa 40 Knoten. Heute hat das Tor-Netzwerk mehr als 6000 Knoten und über 2 Millionen gleichzeitig Nutzende (Stand 10. Oktober 2021). die Anzahl der Knoten ist natürlich für die zufälligen Routen und die Anzahl der Knoten in einer zufälligen Route relevant. Die Sicherheit des Anonymisierungsdienstes ist Teil verschiedenster wissenschaftlicher Evaluationen und hängt maßgeblich davon ab, wie viele Knoten ein Angreifer im Netzwerk etablieren kann, um eine konkrete anonyme Route im Netzwerk offenlegen zu können. Richtig starke Garantien gegenüber mächtigen Angreifern wie Geheimdiensten kann auch das Tor-Netzwerk nicht liefern.

Funknetze Im Folgenden zeigen wir die wichtigsten Sicherheitsaspekte der gängigsten und Ihnen vermutlich geläufigen Funknetze auf: WLAN, Bluetooth und NFC.

WLAN Wireless Local Area Networks (WLANs), also lokale Funknetze, hat sicherlich jeder von Ihnen schon mal zuhause oder unterwegs in Form von Hotspots mit einem mobilen Endgerät verwendet. Die zugrunde liegenden Protokolle und Techniken sind in den 802.11-Standards der IEEE festgelegt. Die Konformität mit diesen Standards können sich Hersteller von der WI-FI Alliance, einem weltweiten Herstellerverbund, zertifizieren lassen. Im Rahmen der 802.11-Standards für die Funkkommunikation geht es bei der IT-Sicherheit insbesondere um zwei Themen: den Netzwerkzugang auf Basis der Authentifikation und die Verschlüsselung der Funkverbindung zum Schutz gegen das Abhören von Gesprächen oder Abfangen von Datenübertragungen. Letzteres inkludiert neben dem direkten Mitlesen der Kommunikation auch den Schutz vor einem »Man in the Middle«, der sich unbemerkt in die

Kommunikation klinkt und als Teil des Protokollablaufs Dinge mitlesen kann. Viele von Ihnen kennen auch schon die Schutzmechanismen, welche der häusliche WLAN-Router oder WLAN-Access Point bietet: Häufig gibt es eine MAC-Adresskontrolle, mit der Geräten explizit Zugang gewährt oder verweigert werden kann (siehe Abschnitt zum Netzwerkzugang). Darüber hinaus lässt sich in vielen Routern/Access Points die SSID beziehungsweise ESSID verstecken, in dem das Aussenden der Netzwerkinformationen (Beacon) unterlassen wird. Dies bringt aber keine zusätzliche Sicherheit, eher im Gegenteil: Einerseits können versierte Angreifer beim Betreten des Netzwerks diese durch den Datenverkehr anderer aktiver Teilnehmer herausfinden. Andererseits versuchen Rechner, in denen das versteckte Netzwerk konfiguriert ist, dieses auch regelmäßig zu finden. Dies geschieht auch außerhalb der Umgebung, in der das eigentlich Netzwerk sich befindet, wodurch Angreifende wiederum ein potenziell passendes Fake-Netzwerk anbieten können. Hilfreich kann es auch sein, die vorkonfigurierte SSID des Herstellers zu ändern, da sie Angreifern häufig bereits erste Informationen zum Hersteller (zum Beispiel Fritzbox) liefert und die Suche nach Sicherheitslücken potenziell erleichtert. Denken Sie bei der Neuvergabe auch daran, dass jeder in der Nähe den Namen sehen kann, und schützen Sie Ihre Privatsphäre außerdem dadurch, dass sie Ihren Namen oder persönliche Details nicht preisgeben. Wichtig im Kontext von WLANs ist auch das Thema der ClientIsolation, die in den meisten Access Points aktiviert werden kann. Normalerweise befinden sich alle mit einem WLAN verbundenen Geräte im gleichen Netz und können auch untereinander kommunizieren. Zuhause und im Firmennetz ist dies vielleicht auch gewünscht, wenn zum Beispiel Dateien direkt ausgetauscht werden sollen oder ein gemeinsam genutzter Drucker per WLAN angebunden ist. Anders sieht dies allerdings in öffentlichen WLANs aus, hier möchten Sie dies in der Regel nicht. Andere Teilnehmer sollen nicht auf Ihre potenziell auch unverschlüsselte Kommunikation oder Ihr System zugreifen können. Sie wissen ja nie, mit wem Sie das Netzwerk gerade teilen! Abhilfe schafft hier zum Beispiel eine VPN-Verbindung zu einem vertrauenswürdigen

Endpunkt: auf Firmengeräten in Ihr Firmennetzwerk, privat potenziell zu Ihrer Fritzbox. Es gibt auch Anbieter wie die Telekom, welche im Rahmen Ihrer Dienste Lösungen hierfür anbieten (zum Beispiel Telekom Connect App). Den hauptsächlichen Schutz bietet die WLAN-Verschlüsselung Wi-Fi Protected Access 3 (WPA3), die zuhause auf Basis des geteilten Passworts den Zugang gewährt (in der Regel über WPA3-Personal). Weit verbreitet ist auch noch die Vorgängerversion WPA2, für die auf Basis der aktuellen Patches zur Entstehungszeit dieses Buches auch keine fundamentalen Lücken bekannt sind. Allerdings fing die Sicherheit von WPA2 an, erste Risse zu bekommen, ein Beispiel hierfür sind die Key Reinstallation Attacks (KRACK) im Jahr 2017 [VP17], die aber vollständig behoben werden konnten. Dennoch bietet WPA3 einen stärkeren Schutz, obwohl es kein gänzlich neues Protokoll darstellt, da zusätzliche Maßnahmen im Protokoll, die vorher nur optional waren, nun verpflichtend sind und nicht mehr aktuelle Techniken nicht mehr verwendet werden dürfen. Die Vorgängerversion WPA und WEP, die manche von Ihnen vielleicht noch aus den Einstellungsoptionen Ihrer Router kennen, gelten als unsicher und sollten nicht mehr verwendet werden, auch nicht im Mischbetrieb (zum Beispiel WPA und WPA2). WPA3 unterscheidet im Einsatz zwei unterschiedliche Einsatzszenarien, Personal und Enterprise, die sich dann auch im konkreten Verfahren und der Authentifikation unterscheiden. Neben der Nutzung stärkerer Kryptoverfahren wurden mit WPA3 sogenannte Management Frames verschlüsselt. Unverschlüsselte Management Frames erlauben Denial-ofService-Angriffe gegen das WLAN und seine Teilnehmer. WPA3-Personal setzt auf das Verfahren »Simultaneous Authentication of Equals« (SAE; es wurde ursprünglich mit 802.11s im Kontext von Mesh-Netzwerken eingeführt) [Har08] und gewinnt damit im Vergleich zu WPA2 [WFA21] Perfect Forwards Secrecy (siehe Kapitel 23) und einen besseren Schutz gegen passive und aktive Angreifer (siehe Kapitel 17) sowie Wörterbuchangriffe. Bei WPA2 wurde statt SAE ein Preshared-Key-Austausch verwendet, bei dem neben dem geteilten Passwort auch die SSID des WLANs in die Schlüsselerstellung

eingingen, und damit auch Informationen, die für einen Angreifer leicht herauszufinden waren und erste Vorteile für einen Angriff bieten. WPA3-Personal unterscheidet folgende zwei Modi: WPA3-Personal only mode und WPA3-Personal transition mode. Der »WPA3-Personal only mode« ermöglicht ausschließlich die Nutzung von WPA3, während der »WPA3-Personal transition mode« auch noch den Rückfall auf WPA2 für einen Übergangszeitraum zulässt. Es gibt weltweit noch viel zu viele Geräte, die bisher kein WPA2 unterstützen und sich gegebenenfalls auch nicht mehr updaten lassen. Das ist also auch eine Abwägung bei Ihnen zuhause. Wie bei WPA2Personal nutzt auch WPA3-Personal ein gemeinsames Passwort für alle Nutzerinnen und keine individuellen Accounts. WPA3-Enterprise kennt drei Modi: WPA3-Enterprise only mode, WPA3-Enterprise transition mode und WPA3-Enterprise 192-bit mode. Die WPA3-Enterprise-Familie unterscheidet sich maßgeblich dadurch, dass Sie wie auch schon die WPA2-Enterprise-Familie eine individuelle Authentifikation über EAP (IEEE 802.1X) bietet (siehe Abschnitt zu ARP). Der »WPA3-Enterprise only mode« ermöglicht wie bei der Personal-Mode-Familie ausschließlich die Nutzung von WPA3, während der »WPA3-Enterprise transition mode« auch noch den Rückfall auf WPA2 für einen Übergangszeitraum erlaubt. Der »WPA3-Enterprise 192-bit mode« nutzt noch einmal stärkere Kryptografie als der normale Modus und erlaubt bei EAP nur drei Verschlüsselungsvarianten. Eine umfassende Analyse des WPA3-Protokolls wurde auf Basis der Erfahrungen mit Krack in 2019 durchgeführt und führte auch bei WPA3 zu Verbesserungsempfehlungen, um den Schutz insbesondere auch vor Seitenkanalangriffen zu stärken [VR19].

Seitenkanalangriffe nutzen Nebeneffekte eines Algorithmus oder einer Technik aus, um Vorteile bei einem Angriff zu gewinnen. Hierzu gehören unter anderem akustische Emissionen (zum Beispiel für die Rekonstruktion des gedruckten Textes bei Nadeldruckern aus dem Druckgeräusch), optische Reflexionen, kaum wahrnehmbare Vibrationen (zum Beispiel Chipstüte, Pflanzen oder auch Wasseroberflächen durch Schallwellen), elektromagnetische Emissionen und verschiedene Analysen des Stromverbrauchs, aber auch eine Analyse des Zeitverhaltens und von Abläufen.

Bluetooth Bluetooth wird durch die Bluetooth Special Interest Group spezifiziert. Die aktuelle Spezifikation ist Version 5.3 aus dem Juli 2021 [BSIG21]. Auch die IEEE hatte den Standard einmal als IEEE 802.15.1 eingeführt, er existiert aber nicht mehr auf einem aktuellen Stand. Seit der Einführung 1999 hat sich der Standard deutlich weiterentwickelt. Nicht zuletzt aufgrund diverser Angriffe (es gab selbst Computerviren, die sich über Bluetooth-Verbindungen verbreiten) wurden zahlreiche Verbesserungen für die Sicherheit eingeführt. So wurde zum Beispiel mit Version 2.1 2007 erstmals ein sicheres Verbinden (Pairing) von Geräten eingeführt. Im Folgenden bekommen Sie sowohl einen Einblick in die aktuellen Sicherheitsmechanismen als auch Hinweise zu den aktuellsten und bekanntesten Angriffen auf Bluetooth. Bluetooth unterscheidet im aktuellsten Standard vor allem zwei Betriebsmodi, einmal den Bereich der Basic Rate (BR) beziehungsweise Enhanced Data Rate (EDR) und den Bereich Low Energy (LE). Für diese beiden Bereiche BR/EDR und LE unterscheiden sich auch die eingesetzten Sicherheitsmethoden leicht. Die Bluetooth-Spezifikation 5.3 kennt fünf Sicherheitsmechanismen [BSIG21], die das Ziel verfolgen, einerseits die Vertraulichkeit zu wahren und andererseits Man-in-the-Middle-Angriffe zu verhindern. Der Standard erläutert diese wie folgt:

Pairing: dies bezeichnet den Prozess, in dem ein oder mehrere Shared Secret Keys zwischen zwei Geräten erstellt werden. Bonding: das Speichern der Schlüssel aus dem Pairing-Prozess, um diese in zukünftiger Kommunikation mit paarweise vertrauenswürdigen Geräten zu verwenden. Device authentication: das Sicherstellen, dass zwei Geräte über den gleichen Schlüssel verfügen. Encryption: Vertraulichkeit von Nachrichten. Message integrity: der Schutz vor Manipulation von Nachrichten. Sollten Sie schon einmal zwei Bluetooth-Geräte miteinander verbunden haben, dürfte Ihnen der Pairing-Prozess bekannt sein. Sie schalten Ihre Geräte in den Discovery-Modus, in dem Geräte für andere sichtbar sind, und dann wird – eventuell unter Eingabe/Abgleich eines Codes – eine sichere Verbindung hergestellt. Beide Geräte speichern die Verbindung und auch die Schlüssel, die für diese Verbindung notwendig sind. Die Datenübertragung innerhalb einer eingerichteten Verbindung erfolgt verschlüsselt. Wichtig im Hinblick auf den Discovery-Modus ist auch, dass Sie diesen wirklich nur beim Verbinden zweier Geräte einschalten. Sollte dieser dauerhaft aktiviert sein, ist Ihr Gerät auch dauerhaft für andere sichtbar und man könnte zum Beispiel in der Öffentlichkeit über verteilte Empfänger Ihre Bewegungen nachvollziehen. Auf AppleGeräten ist der Discovery Modus zum Beispiel in der Regel nur aktiv, wenn Sie sich in den Bluetooth-Einstellungen befinden, um sich andere sichtbare Geräte anzeigen zu lassen. Der LE-Modus hat zusätzliche Schutzmaßnahmen, die die Privatsphäre schützen und ein Tracking erschweren sollen. Hierzu gehört unter anderem eine Veränderung der Geräteadresse in gewissen Zeitabständen, um eine permanente Zuordnung zu verhindern. Dies benötigt aber wieder zusätzliche Maßnahmen, damit die gewünschten bekannten und gepairten Geräte sich weiterhin finden können. Für den BR/EDR-Betriebsmodus werden aktuell das Legacy Pairing, das Secure Simple Pairing und Secure Connections unterstützt, welche, wie die Namen bereits vermuten lassen, unterschiedlich starke

Sicherheitsgarantien bieten. Beim Secure Simple Pairing werden zum Beispiel vier Fälle für die Verknüpfung von Geräten unterschieden (Association Modes): Numeric Comparison: beide Geräte müssen 6 Ziffern zum Abgleich darstellen können. Just Works: ein Gerät kann nichts anzeigen, daher muss nur die Verbindung akzeptiert werden. Out of Band (OOB): der Austausch von Informationen und Schlüsseln erfolgt nicht über Bluetooth, sondern zum Beispiel über NFC. Encryption: Vertraulichkeit von Nachrichten. Passkey Entry: ein Gerät unterstützt die Eingabe, ein anderes die Ausgabe. Dies kennen Sie zum Beispiel von Tastaturen. Der LE Betriebsmodi unterstützt im LE Legacy Pairing eine ähnliche Vorgehensweise wie beim Secure Simple Pairing BR/EDR. Trotz all der Sicherheitsmaßnahmen kommt es natürlich auch heute immer wieder zu Angriffen auf Bluetooth-Verbindungen. 2021 haben die Braktooth-Angriffe gezeigt, wie sich DoS-Angriffe auf zahlreiche Bluetooth-Geräte ausführen lassen, die im Extremfall sogar zur Ausführung von Schadcode auf IoT-Geräten genutzt werden konnten [GCB+21]. 2019 wurde die Angriffsmethode BIAS vorgestellt, bei der nach dem Belauschen des Pairing-Vorgangs von zwei in der Nähe befindlichen Geräten ein Angreifer sich gegenüber einem der Geräte als das andere ausgeben und eine Verbindung herstellen konnte [ATR20]. In der Vergangenheit gab es eine Vielzahl weiterer Angriffe, zu den bekanntesten gehören [PBB+17]: Bluesnarfing: Fehler in der Firmware ermöglichten Angreifern den Zugriff auf Geräte mit aktiviertem Bluetooth, sodass sie auf Daten wie die IMEI des Geräts zugreifen konnten.

Bluejacking: Ermöglichte es Angreifern, unaufgefordert Nachrichten an Geräte wie Mobiltelefone zu senden, die Bluetooth aktiviert hatten. Je nach Nachrichteninhalt konnte dies zu Schaden führen, wenn die Mobiltelefonnutzende mit der Nachricht interagierten. Bluebugging: Fehler in der Firmware erlaubten Angreifern den Zugriff auf Geräte mit aktiviertem Bluetooth, hierzu gehörte der Zugriff auf Daten, aber auch die Möglichkeit, zum Beispiel Anrufe zu starten.

NFC, RFID Systeme mit Radio Frequency Identification (RFID) ermöglichen das kontaktlose Auslesen von Informationen aus einem Transponder. Transponder verfügen in der Regel über einen Chip mit geringem Energieverbrauch, der mit einer verhältnismäßig »großen« Antenne ausgestattet ist, die einerseits zur Kommunikation dient und andererseits induktiv für die Stromversorgung sorgt. Transponder gibt es in verschiedenen Varianten von lesbar über les- und beschreibbar bis hin zur Ausstattung mit einer CPU zur Verarbeitung von Daten. Einfach Tags dienen lediglich dem Tracking (Logistik) oder Identifizieren von Gegenständen (RFID-Chip im Schlüssel für die Wegfahrsperre von Fahrzeugen), Transponder mit CPU wie im neuen deutschen Personalausweis nPA können aber auch ganz andere Funktionen erlauben, da energieeffiziente kryptografische Operationen möglich sind. Der Zugriff kann je nach Bauform und Einsatzszenario aus nur wenigen Zentimetern Entfernung erfolgen, bei größerer Antenne oder eigener Stromversorgung sind aber auch einige Meter Abstand möglich. RFID-Transponder sind für verschiedene Einsatzzwecke in den verschiedensten Industriestandards definiert, zum Beispiel »ISO/IEC 14443 (all parts), Cards and security devices for personal identification – Contactless proximity objects« oder »ISO/IEC 15693 (all parts), Cards and security devices for personal identification – Contactless vicinity objects«.

Near-Field-Communication (NFC) basiert auf den RFID-Protokollen (zum Beispiel ISO/IEC 14443 oder ISO/IEC 15693) mit dem Unterschied, dass ein NFC-Gerät nicht nur als Lese- beziehungsweise Schreibgerät, sondern durch den Card Emulation Mode auch als Tag agieren kann. Darüber hinaus werden Peer-to-Peer-Verbindungen zwischen zwei NFC-Geräten möglich. NFC wurde inzwischen durch den »ISO/IEC 18092 Near Field Communication – Interface and Protocol« (NFCIP-1) standardisiert. Im Hinblick auf die Sicherheit von NFC-Systemen unterscheidet das BSI drei Bereiche [BSI20b]: die Kommunikationsschicht, die Anwendungsschicht und Hintergrundsysteme. Die Kommunikationsschicht ist grundsätzlich unsicher, da prinzipiell die Funkkommunikation immer erst einmal angestoßen werden muss. Eine Authentifizierung oder Verschlüsselung ist auf dieser Schicht nicht vorgesehen, sondern erfolgt zum Beispiel beim nPA erst auf der Anwendungsschicht. Dies ist aber immer anwendungsabhängig und kann in verschiedensten Ausprägungen und Sicherheitsniveaus vorkommen. Bei Bankkarten zum Beispiel ist ein Schutz wie beim nPA nicht der Fall. Das BSI beschreibt hierzu folgendes Beispiel [BSI20b]: Wenn ein Angreifer sich über einen Zahlungsdienstleister ein zugelassenes Zahlungsterminal besorgt und einen Betrag eingibt, der aufgrund der geringen Höhe (zum Beispiel 25 EUR) automatisch autorisiert wird, muss er nur nahe genug an die Bankkarte des Opfers kommen, um die Transaktion durchzuführen. Ein wirksamer Schutz ist hier nur die konsequente Abschirmung der Karte durch das Opfer und eine erhöhte Aufmerksamkeit. Einen einfachen Zugriffsschutz auf einen RFID/NFC-Transponder und gleichzeitig auch einen passenden Trackingschutz für eine bessere Privatsphäre erreicht man nach dem Prinzip des faradayschen Käfigs. Neben abschirmenden Schutzhüllen gibt es zum Beispiel Geldbeutel, die einen integrierten Schutz vor unbefugtem Auslesen der Karten haben. Blockerkarten, wie sie ebenfalls angeboten werden, können zwar häufig mit eigenen Signalen die Kommunikation stören oder überlagern, sie können aber potenziell selbst für ein Tracking ausgenutzt werden. Darüber hinaus erschweren mehrere eigene RFID/NFC-fähige Karten im Geldbeutel bereits die

Kommunikation, da sie sich gegenseitig überlagern und blockieren. Natürlich kann das Opfer, sofern es die Abbuchung rechtzeitig bemerkt, diese auch stornieren. Solch ein verhältnismäßig kleiner Betrag könnte jedoch von vielen Personen schlicht übersehen werden. Ebenfalls von Bedeutung sind potenziell die Hintergrundsysteme, wenn zum Beispiel mehrere einzelne Leser miteinander verknüpft sind. Hier können zusätzliche Sicherheitschecks hilfreich sein. So könnte bei der Zutrittskontrolle, wenn der gleiche Transponder zu schnell an zwei verhältnismäßig weit voneinander entfernten Orten auftaucht, ein sogenannter Relay-Angriff vorliegen. In der Vergangenheit wurden trotz der geringen Reichweite solche Relay-Angriffe nachgewiesen. Bei schneller Übertragung könnte man zum Beispiel beim Bezahlen die Kommunikation mit der Kasse abfangen und versuchen, mithilfe einer zweiten Person aus geringer Entfernung die Kommunikation an die Bankkarte eines Opfers weiterzuleiten [DM07]. Das BSI hat mit der technischen Richtlinie »TR/03126 sicherer RFIDEinsatz« (TR RFID) einen Leitfaden für die Anwendungsgebiete eTicketing im öffentlichen Personenverkehr, eTicketing für Veranstaltungen (Event-Ticketing), NFC-basiertes Ticketing, Handelslogistik und elektronischer Mitarbeiterausweis die jeweiligen Sicherheitsaspekte untersucht [BSI13]. Eine Zerstörung von nicht mehr benötigten RFID-Chips ist zum Beispiel mithilfe einer Überspannung oder durch physisches Zerstören der Antenne mit einem Messer möglich.

Das sichere Internet der Zukunft Die Wissenschaft schlägt aufgrund der beschriebenen Probleme unserer heutigen Internet-Architektur radikale Alternativen vor, um die historisch bedingten Nachteile von zum Beispiel IP und BGP zu adressieren. Die bekannteste Alternative, die diese Anforderungen von vornherein mitdenkt, ist das SCION-Projekt [PSRC17], das eine alternative Infrastruktur für das Internet vorschlägt. Das Projekt geht unter anderem auf Adrien Perrig zurück. Das Akronym steht für

Scalability, Control, and Isolation on Next-Generation Networks. Kernziele von SCION sind laut den Autoren die Verfügbarkeit in Anwesenheit von Angreifern, Transparenz und Kontrolle, Effizienz, Skalierbarkeit und Erweiterbarkeit, Unterstützung für globale, aber heterogene Vertrauensstellungen und die Ausrollbarkeit. Diese Funktionen reflektieren die gemachten Erfahrungen seit der Entstehung des Internets und versuchen die Probleme der heutigen Infrastruktur zu lösen, einer Infrastruktur, die für die heutigen Anwendungsfälle gar nicht entworfen wurde.

Kapitel 22

Firewalls IN DIESEM KAPITEL lernen Sie, was eine Firewall ist … … und welche Firewalls Ihre System schützen können

Eine Firewall lässt sich am ehesten mit dem Pförtner am Firmentor vergleichen [Poh03]. Der reale Pförtner kontrolliert – je nach Unternehmensvorgaben unterschiedlich intensiv – wer das Firmengelände betreten und verlassen darf. Genauso kontrolliert der virtuelle Pförtner »Firewall« am virtuellen Firmeneingang, welche Netzwerkpakete rein oder raus dürfen. Die konkrete Ausgestaltung von Firewallsystemen kann sehr unterschiedlich sein. Auch reale Firmeneingänge sind in der Regel sehr verschieden voneinander. Es gibt sie mit und ohne Schranke, mit und ohne Drehkreuze für Personen und im Extremfall mit aufwendigen Sperren, die sogar das gewaltsame Durchbrechen von Fahrzeugen verhindern. Genauso verhält es sich mit der Unternehmensfirewall. Je nach Anforderungen gibt es unterschiedlichste Varianten eine Firewall zu implementieren.

Grundlagen von Firewalls Eines haben alle Firewalls gemeinsam: Der gesamte Datenverkehr in das Unternehmen und aus dem Unternehmen heraus muss die Firewall passieren. Deswegen hat eine Firewall meist mindesten zwei Netzwerkanschlüsse: einen nach innen und einen nach außen. Die Software in der Firewall entscheidet nach vorgegeben Regeln, welche

Datenpakete zwischen den beiden Anschlüssen hin- und hertransportiert werden. Dabei wird nicht nur eingehender, sondern auch ausgehender Datenverkehr unterbunden. Sie wollen nicht nur unerwünschte Datenpakete draußen halten, Sie wollen auch verhindern, dass unerwünschter Datenverkehr nach draußen geht. Sie können zwischen zwei grundlegenden Betriebskonzepten unterscheiden: Alles was nicht verboten ist, ist erlaubt. Alles was nicht erlaubt ist, ist verboten. Es versteht sich von selbst, dass auf Dauer zur Erreichung einer hohen Sicherheit nur das zweite Betriebskonzept Sinn macht. Sie sperren den gesamten Datenverkehr und erlauben nur die erforderlichen Ausnahmen. In einigen Umgebungen – zum Beispiel Hochschulen, in denen Studierende extensiv BYOD betreiben – kann allerdings auch die erste Regel Sinn machen. In der Praxis wird eine Firewall mehr als zwei Netzwerkanschlüsse haben, damit Sie eine bessere Segmentierung Ihrer Netzstruktur leisten können. Abbildung 22.1 zeigt ein Beispiel mit vier Zonen: Extern, Intern, WLAN und Demilitarisierte Zone (DMZ).

Abbildung 22.1: Beispiel für eine Firewall mit vier Sicherheitszonen: Extern, Intern, WLAN und Demilitarisierte Zone (DMZ).

Zur Definition dieser Zonen gehört auch ein Diagramm, das die möglichen Datenflüsse festlegt: von

Extern

Intern

DMZ

WLAN

Extern

–

nein

kontrolliert

nein

Intern

nein

isoliert

kontrolliert

nein

isoliert

nein

DMZ WLAN

kontrolliert kontrolliert ja

nein

kontrolliert isoliert

Das Wort »kontrolliert« in der Übersicht bedeutet, dass die Firewall Regeln hat, die festlegen, welche konkreten Dienste erlaubt sind. Die Einträge »isoliert« für die zoneninterne Kommunikation bedeuten, dass die Rechner in der Zone nur miteinander kommunizieren dürfen, wenn es erforderlich ist. Das bremst Schadsoftware aus.

Darüber hinaus kann das interne Netz mit internen Firewalls noch weiter strukturiert werden. Typische Sicherheitszonen, die Sie einrichten sollten, sind: Servernetz: in diesem Segment sind alle internen Server. Administrationsnetz: in diesem Netz können die Administratoren auf die Administrationsoberflächen der IT-Geräte zugreifen. Produktion: hier sind alle Rechner zur Steuerung der Produktion. Telefonie: in diesem Bereich sind alle VoIP-Telefone. Gebäudeleittechnik: in diesem Netz befinden sich die Rechner der Gebäudeleittechnik. Bürokommunikation: in diesem Netz arbeiten alle Verwaltungsrechner. Die Segmentierung mit definierten und kontrollierten Übergängen reduziert das Risiko, das von unberechtigten Zugriffen ausgeht, und dämmt die Ausbreitung von Schadsoftware ein. Sie sollten in der Firewall Ihres Unternehmens eine Grundhygiene einführen. Diese Regelungen können Sie planen, ohne sich Gedanken über die konkreten Anforderungen Ihres Unternehmens zu machen, da sie so allgemein sind, dass sie überall eingesetzt werden können. Sperren Sie alle Verbindungen, die logisch nicht möglich sein können. Sperren Sie die folgenden Verbindungen: ausgehende Verbindungen, die eine Quell-IP-Adresse enthalten, die es im Unternehmen nicht gibt, eingehende Verbindungen, die eine Quell-IP-Adresse enthalten, die es im Unternehmen gibt, alle Verbindungen, die als Quell- oder Ziel-IP-Adresse eine private IP-Adresse enthalten, alle Verbindungen, die als Quell- oder Ziel-IP-Adresse eine Localhost-Adresse (127.0.0.0/8) enthalten.

Alle diese Verbindungen kann es als legitimen Datenverkehr nicht geben. Deshalb gibt es durch diese Blockaden auch keine Funktionseinschränkungen. Genauso sollten Sie einige Ports (Dienste) sperren, von denen bekannt ist, dass sie missbraucht werden können. Port 25 (smtp): Wenn der Mail-Server im Unternehmen steht, darf nur er über diesen Port kommunizieren. Steht der Mail-Server bei einem Dienstleister, dürfen die Rechner im Unternehmen nur dorthin kommunizieren. Dies verhindert, dass sich Schadsoftware unkontrolliert per E-Mail verbreitet. Port 587 (Mail Submission): E-Mails dürfen nur an den eigenen Mail-Server eingeliefert werden. Port 53 (DNS): Nur der eigene DNS-Resolver darf über diesen Port nach außen kommunizieren. Port 123 (NTP): Nur der Zeitserver darf nach außen kommunizieren. Das NTP-Protokoll wird oft missbraucht. Ports 135, 137, 139 und 445 (Microsoft Netbios und SMB-Ports): Diese Dienste sollten nur intern oder über VPN genutzt werden. Auch besteht ein Missbrauchsrisiko.

Packet Filter Ein Packet Filter ist die einfachste Firewall. Sie kann sogar auf handelsüblichen Routern über sogenannte Access-Controll-Listen realisiert werden. Die Filterung erfolgt nur auf Basis von wenigen Angaben aus dem Header des Datenpakets: Quell- und Ziel-IPAdressen, Quell- und Ziel-Port und Übertragungsprotokoll (zum Beispiel TCP oder UDP). Da jedes Datenpaket unabhängig von den anderen gefiltert wird, gibt es keine Sitzungsinformationen. Deshalb müssen Regeln sowohl für den eingehenden als auch den ausgehenden Datenverkehr definiert werden.

Ein Packet Filter sollte immer auf dem äußersten Router (Edge-Router) installiert werden, um damit eine erste Verteidigungslinie zu bauen. Die Filterregeln eines Packet Filters werden der Reihe nach abgearbeitet. Sobald eine Regel zutrifft, wird diese angewandt und weitere Regeln nicht mehr geprüft. Damit kann die Reihenfolge der Regeln für die Performance der Firewall relevant sein. Das letzte Statement eines Regelsatzes ist immer ein »Alles-verboten«-Statement (Deny Statement), demzufolge alles verboten ist, was nicht erlaubt ist. Die umgekehrte Logik wäre, mit einzelnen Statements Dienste zu unterbinden und als letzte Regel »alles erlaubt« zu setzen. Ein Packet Filter entspricht in dem Pförtnerbild einem Pförtner, der nur prüft, ob Anschrift und Absender auf dem Lieferschein korrekt sind.

Stateful Inspection Firewall Eine wesentliche Verbesserung ist das Konzept der Statefull Inpection Firewall. Diese Firewall untersucht nur noch das erste Paket einer Verbindung beim Verbindungsaufbau. Dieses Paket ist durch ein Flag im Header (SYN-Flag) leicht zu erkennen. Ist die Verbindung erlaubt, »merkt« sich die Firewall die Parameter der Verbindung in einer Tabelle. Alle weiteren Pakete einer Verbindung werden nur noch gegen diese Tabelle geprüft. Sie müssen beim Entwurf der Regeln auch nicht mehr beide Richtungen berücksichtigen. Die Firewall erkennt automatisch alle aus- und eingehenden Pakete einer Verbindung. Verbindungslose Protokolle wie UDP oder ICMP werden über Zeitfenster geregelt. Schicken Sie einen PING-Befehl zu einem Rechner, öffnet sich die Firewall einen Moment lang für eingehende Verbindungen. Kommt die Antwort innerhalb des Zeitfensters zurück, wird sie durchgelassen, kommt die Antwort zu spät, wird die Antwort blockiert. Besonders effizient wird die Stateful Inspection Firewall bei komplexen Protokollen. Schauen wir uns zum Beispiel das File Transfer Protocol

(ftp) an. Eine ausgehende Kontrollverbindung wird zu einem Server über Port 21 aufgebaut. Wollen Sie per ftp eine Datei herunterladen, wird über die Kontrollverbindung ein Port auf dem Client vereinbart, zu dem der Server ausgehend von Port 20 eine Datenverbindung aufgebaut. Da diese Vereinbarung dynamisch getroffen wird, ist sie in einem Packet Filter schwer zu definieren. Da die ftp-Verbindung unverschlüsselt ist, kann die Stateful Inspection Firewall den Datenverkehr mitlesen. Sie fischt die nötigen Informationen aus der Datenverbindung heraus, um die eingehende ftp-Datenverbindung zuzulassen. Diese eingeschränkte Analyse der Paketinhalte macht die Konfiguration solch einer Firewall recht einfach. In unserem Pförtnerbild entspricht eine Stateful Inspection Firewall einem Pförtner, der prüft, ob es zu dem Lieferschein eine Bestellung gibt. Heute betreibt man auf einem Desktoprechner oder einem Notebook –unabhängig vom Betriebssystem – eine DesktopFirewall. Dies sind in der Regel Stateful Inspection Firewalls. Sie haben einen Vorteil, da sie auch auswerten können, welche konkrete Anwendung eine Datenverbindung versucht. Damit ist es möglich einem Browser die Nutzung der Ports 80 und 443 zu erlauben, allen anderen Programmen aber nicht. Grundsätzlich ist es auf einem Desktop nicht sinnvoll, eine Anwendung wie etwa einen Webserver zu betreiben, welche Dienste für das Netz anbietet. Will man den Dienst nicht, soll der Zugriff darauf per Firewall blockiert werden. Da wäre es sinnvoller, den Desktop so zu konfigurieren, dass er nur die gewünschten Dienste anbietet.

Network Address Translation (NAT) Network Address Translation (NAT) und eine Stateful Inspection Firewall sind beide vom Ergebnis ähnlich. Die zugrunde liegenden Mechanismen sind aber unterschiedlich.

Ein NAT-Gerät hat nach außen eine öffentliche IP-Adresse und intern meist einen privaten IP-Adressbereich. Erreicht ein nach außen gerichtetes Datenpaket das NAT-Gerät, wird die interne Quell-IP durch die externe IP-Adresse des NAT-Geräts ausgetauscht und der Quell-Port wird ebenfalls ersetzt. Diese Umsetzung merkt sich das NAT-Gerät. Kommt das Antwortpaket, wird die Rückübersetzung vorgenommen und das Paket intern zugestellt. Diese so gelernte NAT-Tabelle wird als dynamisches NAT bezeichnet (siehe Abbildung 22.2). Man kann aber auch manuell Einträge in die NAT-Tabelle schreiben (in Konfigurationsoberflächen oft Port-Forwarding genannt). Diese werden genauso verarbeitet wie die dynamischen Einträge. Dynamische Einträge werden durch ausgehende Verbindungen erzeugt; statische Einträge kümmern sich um eingehende Verbindungen.

Abbildung 22.2: Beispielhafte Übersetzung der IP-Adressen mit NAT (zusammengehörende Einträge sind gleich hinterlegt).

Kommt ein Datenpaket an, für das es keinen Eintrag in der NAT-Tabelle gibt, wird das Paket verworfen, da es nicht zugestellt werden kann. NAT ist ursprünglich entstanden, um mit dem Mangel an IPv4-Adressen umgehen zu können. Es wird mit IPv6 an Bedeutung verlieren, da es dann keinen Mangel an IP-Adressen mehr gibt. Bei IPv6 wird deswegen der Einsatz einer Firewall wichtiger werden. NAT hat auch eine Bedeutung für die Privatsphäre der Beschäftigten. Nutzt ein Unternehmen NAT, haben alle Datenpakete, die das Unternehmensnetz verlassen, dieselbe IP-Adresse. Die interne Netzstruktur wird damit verschleiert. In den Protokolldateien des NAT-

Geräts kann die Internetnutzung der Beschäftigten allerdings nachvollzogen werden.

Proxy-Server und Application Layer Firewall Ein Proxy ist ein Stellvertreter, der die Anfrage eines Clients annimmt und dann an das eigentliche Ziel weiterleitet. Proxys werden häufig eingesetzt, um in den heruntergeladenen Daten nach Schadsoftware zu suchen. Insofern filtert ein Proxy den Datenverkehr. Ursprünglich wurden Proxys eingeführt, um den Internetanschluss zu entlasten, indem abgerufene Daten vorübergehend zwischengespeichert (»gecachet«) wurden. Es gibt Proxys, die nur ein einziges Protokoll beherrschen, wie zum Beispiel http/https oder ftp. Und es gibt generische Proxys, die alle Verbindungen weiterleiten können. Insbesondere SOCKS4 und SOCKS5 sind hier populär. SOCKS5 bietet als Besonderheit eine Nutzerauthentisierung. Damit können Regeln benutzerabhängig formuliert werden. Obwohl ein Proxy-Server eigentlich keine Firewall ist, können dort Einschränkungen definiert werden. Der Vorteil ist, dass auch Regeln auf Domainnamen-Basis erstellt werden können. Das ist ein großer Vorteil, da heute bei den Massenhostern oft auf einer IP-Adresse mehrere hundert Webseiten betrieben werden. Wird die IP-Adresse geblockt, sind alle Webseiten auf dem Server nicht mehr erreichbar. Auf dem Proxy können Sie gezielt eine Domain blockieren. Ein Proxy muss in der Anwendung konfiguriert werden. Diese Konfiguration kann manuell erfolgen oder auch automatisch durch das Web Proxy Autodiscovery Protocol (WPAD). Bei der automatischen Konfiguration teilt entweder der DHCP-Server dem Client die Adresse eines Webservers mit oder ein Programm versucht, über das DNS den Server zu finden. Der Domainname eines WPAD-Servers beginnt mit »wpad.«, zum Beispiel wpad.firma.de. Der Client kann von dem Server

eine Datei namens wpad.dat herunterladen. In dieser Datei steht dann die eigentliche Proxy-Konfiguration. Die Konfiguration ist ein Javascript-Programm, das in der Anwendung (zum Beispiel dem Webbrowser) ausgeführt wird. Wer es schafft, einem Rechner einen gefälschten WPAD-Server unterzujubeln, kann auf dem Rechner ein Programm ausführen. Sie müssen also sicherstellen, dass keine DNSAnfragen mit dem Namensbestandteil »wpad« an DNS-Server außerhalb des Unternehmens geschickt werden, denn sonst könnte ein bösartiger WPAD-Server angesprochen werden. Das WPAD-Protokoll gilt als nicht wirklich sicher. Der Schritt vom Proxy zur Application Layer Firewall ist klein. Eine Application Layer Firewall untersucht die Datenverbindung auch auf Anwendungsebene. Die Application Layer Firewall ist für Anwendungen transparent, da durch netzinterne Umleitungen des Datenverkehrs die Datenpakete auf der Firewall landen. Insgesamt können mit einer derartigen Firewall sehr gezielt Filterungen vorgenommen werden. Der Nachteil ist, dass diese Art der Filterung sehr rechenintensiv ist und deshalb deutlich höhere Kosten verursacht. Eine Application Layer Firewall benötigt für jeden Dienst, den sie detailliert kontrollieren soll, ein eigenes Modul, das die Details des Datenverkehrs dieses Dienstes versteht. Damit auch Dienste behandelt werden können, für die es keine angepassten Module gibt, gibt es ein generisches Modul, das aber keine inhaltlichen Kontrollen vornehmen kann. Bei der Konfiguration einer Application Layer Firewall denken Sie in Portnummern (zum Beispiel Port 22 für SSH) und kontrollieren gezielt den Datenverkehr der einzelnen Protokolle auf der Application Layer Firewall. In unserem Pförtnerbild entspricht eine Application Layer Firewall einem Pförtner, der jede Position auf dem Lieferschein mit dem Inhalt der Pakete auf dem LKW abgleicht.

NG Firewall und Deep Packet Inspection Unter dem Begriff Next Generation Firewall (NG Firewall) versteht man ein aktuelles Firewallkonzept, das über bisherige Konzepte hinausgeht. Das Konzept der Kontrolle von Ports (Packet Filter und Stateful Inspection) und Protokollen (Proxy und Application Level Firewall) wird durch Deep Packet Inspection ergänzt beziehungsweise ersetzt. Bei der Deep Packet Inspection untersucht die Firewall den Inhalt der Datenpakete. Dabei soll nicht der Nutzerinhalt, sondern das Protokoll erkannt werden. Alle Protokolle (auch verschlüsselte) verwenden am Beginn der Verbindung charakteristische Sequenzen, die zum Verbindungsaufbau erforderlich sind. So hat SSH in der ersten Payload etwa beim OpenSSH für Windows den Klartext SSH-2.0OpenSSH_for_Windows_8.1. Der Server antwortet mit einem ähnlichen Text. Danach werden zur Vereinbarung der Verschlüsselung weitere definierte Informationen im Klartext ausgetauscht. Daran kann die Firewall das Protokoll eindeutig erkennen. Auch wenn es nicht bei jedem Protokoll so eindeutig ist wie bei SSH, hat praktisch jedes Protokoll solche Charakteristika, an denen es erkannt werden kann. Der Vorteil dieser Vorgehensweise ist, dass unabhängig davon, auf welchen Port eine SSH-Verbindung aufzubauen versucht wird, die NG Firewall die Verbindung blockiert, wenn SSH gesperrt ist. Damit können Sie beim Konfigurieren der NG Firewall in Anwendungen denken und müssen nichts mehr über Ports wissen. Bekannte NG Firewalls werden zum Beispiel von Barracuda oder Fortinet geliefert.

Firewall und Verschlüsselung Ein grundsätzliches Problem bei einer Firewall sind verschlüsselte Verbindungen. Diese müssen entweder unkontrolliert durch die Firewall gelassen werden, da der Schlüssel zum Entschlüsseln fehlt, oder die Firewall muss sich als Man-in-the-Middle

beim Verbindungsaufbau in die Verbindung einklinken. Das ist natürlich eine unsaubere Lösung. Eine geschickte Lösung wäre es hingegen, eine VPN-Verbindung in der DMZ enden zu lassen und den Datenverkehr zu entschlüsseln. Der entschlüsselte Datenverkehr kann dann anschließend beim nochmaligen Passieren der Firewall untersucht werden.

Firewall in der Cloud In Unternehmen werden heute immer mehr Dienste in die Cloud ausgelagert. Das führt dazu, dass wesentliche interne Dienste aus Netzwerksicht effektiv vor der Firewall betrieben werden. Das gestiegene Arbeitsaufkommen im Homeoffice hat uns auch gezeigt, dass es keine gute Idee ist, wenn Sie vom Homeoffice aus eine VPNVerbindung in Ihr Unternehmen aufbauen, um dann den Cloud-Dienst Ihres Unternehmens zu nutzen. Das belastet den Internetanschluss Ihres Unternehmens doppelt. Es wäre viel geschickter, wenn Sie die Verbindung aus dem Homeoffice direkt zum Cloud-Dienst aufbauen. Nun möchte Ihr Unternehmen den Cloud-Dienst natürlich nicht jedermann zur Verfügung stellen und ihn daher angemessen schützen. Ob Ihr Unternehmen nun ein virtuelles Netz mit ein paar Rechnern oder eine einzelne Cloud-Anwendung betreibt, Sie können den notwendigen Schutz hier mit einer Cloud-Firewall umsetzen. Eine Cloud-Firewall muss in die Infrastruktur des Cloudanbieters integriert werden können. Das ist bei virtuellen IT-Umgebungen (Infrastructure as a Service, IaaS) wie Amazon AWS, der Google Cloud Platform oder Microsoft Azure relativ einfach. Bei Platform as a Service muss die Firewall in die Plattform integrierbar sein. Häufig bieten auch die Cloud-Anbieter Firewall-Services an. Der Vorteil einer Cloud-Firewall eines etablierten Firewall-Anbieters ist die bessere Integration in die bereits vorhandene Firewall (vom gleichen Hersteller) Ihres Unternehmens. Auch können Sie dann für alle Firewalls dieselben Managementwerkzeuge nutzen. Wenn Sie die Cloud-Dienste Ihres Unternehmens aus dem Homeoffice nutzen wollen, müssen Sei sich gegenüber der Cloud-Firewall als

berechtigt ausweisen. Dazu wird häufig eine Softwarekomponente auf dem Client-Rechner installiert, die mit der Cloud-Firewall »zusammenarbeitet«. Auch wenn Sie webbasierte Dienste in der Cloud betreiben, ist es sinnvoll, diese mit einer Web-Firewall vor missbräuchlicher Nutzung zu schützen. In der Cloud haben Sie ja häufig auch Administrationsinterfaces in Ihrer Unternehmensanwendung, die Sie im Unternehmen hinter der Firewall verbergen können. Das ist in der Cloud nicht möglich, außer Sie nutzen auch dort eine Firewall.

Kapitel 23

Verschlüsselung im Einsatz IN DIESEM KAPITEL Verschlüsselung von Daten auf Datenträgern E-Mail-Verschlüsselung Wie Sie Daten bei der Übertragung verschlüsseln

In diesem Kapitel lernen Sie die unterschiedlichen Einsatzmöglichkeiten der Verschlüsselung kennen. Mithilfe von Verschlüsselungstechniken lassen sich nicht nur Daten auf Datenträgern schützen, sondern auch bei der Übertragung innerhalb eines Netzwerks wie zum Beispiel im Internet. Die grundlegenden Konzepte der Verschlüsselungsverfahren sind weitgehend ähnlich, ihr Schutzzweck ist jedoch sehr unterschiedlich. Auch ein Anwender sollte idealerweise verstanden haben, welchen Schutz eine Verschlüsselung bietet und welchen Schutz sie nicht bieten kann, damit er die angemessene Lösung für den Schutzbedarf seiner Daten wählen kann.

Daten in Ruhe Auf der Festplatte – hiermit sind sowohl klassische Festplatten als auch Solid State Drives (SSD) gemeint – eines Arbeitsplatzrechners oder auch eines mobilen Endgeräts sind in Form von Textverarbeitungsdateien, Tabellenkalkulationsdateien, Datenbanken, E-Mails und vielen anderen Formen sowohl personenbezogene als auch andere vertrauliche Daten aus einem Unternehmen, einer Behörde oder dem privaten Bereich gespeichert. Das Ziel der Verschlüsselung ist es, diese Daten effektiv gegen den unberechtigten Zugriff zu schützen. Je nach Angriffsszenario benötigen Sie hierfür unterschiedliche Schutzmaßnahmen. Ein Dieb

eines Rechners könnte – außer der Verschlüsselung – alle Schutzmaßnahmen wie zum Beispiel eine gesicherte Bootkette umgehen, indem er die Festplatte des Rechners aus- und dann in einen anderen Rechner einbaut und dort ausliest. Um den Zugriff beim Diebstahl von Datenträgern zu verhindern, hilft also nur die vollständige Verschlüsselung der Daten auf den Datenträgern. Auch Konfigurationsdateien auf dem Rechner können bei einem direkten Zugriff auf die Festplatte leicht durch Unberechtigte geändert werden (zum Beispiel durch das Starten des Computers von einem USBStick mit einem anderen Betriebssystem in Abwesenheit der Nutzerin). Bei Windows- und Unix-/Linux-Rechnern können Sie durch Veränderungen der Datei, in der die verschlüsselten Anmeldepasswörter gespeichert werden, sogar die Nutzerpasswörter inklusive Administratorkennwort ändern. Mit einer vollständigen Verschlüsselung der Festplatte lassen sich diese Veränderungen verhindern. Die verschlüsselte Speicherung der Daten gewährt die Vertraulichkeit der Daten. Die Verschlüsselung kann auch Integritätsverletzungen erkennen, jedoch keine Verfügbarkeit garantieren. Insbesondere können verschlüsselte Daten immer noch gelöscht und geändert werden. Wenn eine verschlüsselte Datei durch einen Unbefugten, der den zugehörigen Schlüssel nicht hat, geändert wird, lässt sie sich nicht mehr fehlerfrei entschlüsseln, da die Datei beschädigt ist. Damit werden unbefugte Veränderungen zwar erkannt, aber nicht verhindert. Es gibt Verschlüsselungssoftware, die den Zugriff auf Dateien sperrt, wenn die Nutzerin nicht über den entsprechenden Schlüssel verfügt. Dies funktioniert jedoch nur, wenn die Software läuft. Es ist derzeit nicht möglich, durch Veränderungen der verschlüsselten Datei gezielte Änderungen in der Klartext-Datei zu erzeugen. Die Verschlüsselung der Daten auf dem Datenträger schützt die Daten bei ausgeschaltetem Rechner beziehungsweise bei externen Datenträgern, solange diese nicht mit einem Rechner verbunden sind. Sobald Sie das Passwort zum Öffnen der Verschlüsselung eingegeben haben und die Daten benutzt werden können, ist die Verschlüsselung völlig transparent, das heißt die Nutzerin merkt nicht, dass die Dateien

im Hintergrund automatisch ver- und entschlüsselt werden. Wenn der Schlüssel eingeben wurde, sind die verschlüsselten Dateien zugreifbar. Die völlige Transparenz der Verschlüsselung ist einerseits praktisch, da sie bei der Arbeit am Rechner nicht stört. Allerdings schützt sie anderseits nicht vor Zugriffen zum Beispiel durch eine Schadsoftware, die im Hintergrund läuft. Deshalb sind neben dem Einsatz einer Datenträger- beziehungsweise Datenverschlüsselung immer auch weitere Schutzmaßnahmen notwendig. So ist zum Beispiel auch ein Schutz vor Schadsoftware nötig, um das Einnisten von Malware auf dem Rechner zu verhindern. Auch eine automatische Bildschirmsperre ist sinnvoll, damit niemand den laufenden Rechner benutzen beziehungsweise manipulieren kann, wenn die Nutzerin den Computer für einen Moment verlässt. Bei den ergänzenden Schutzmaßnahmen geht es also um eine Vervollständigung des Schutzes gegen lokale und entfernte Angreifer im Betrieb des Computers, da die Verschlüsselung von Daten allein häufig nicht hilft. Die Verschlüsselung einer Festplatte sollte immer durch flankierende Maßnahmen begleitet und ergänzt werden, um sich gegen lokale und entfernte Angreifer zu schützen: eine sichere Bootkette (zum Beispiel Secure Boot) einrichten, um Manipulationen des Boot-Prozesses zu verhindern; die zeitgesteuerte automatische Bildschirmsperre aktivieren, um Zugriffe in Abwesenheit der Nutzerin zu verhindern; den Schutz vor Malware einrichten, um den Zugriff und Manipulationen durch Schadsoftware zu verhindern; Netzwerkzugriffe kontrollieren (zum Beispiel mit einer Desktop-Firewall), um unberechtigte Zugriffe über das Netzwerk zu verhindern. Wird ein Rechner ausgemustert und zum Beispiel an Beschäftige oder gemeinnützige Einrichtungen weitergegeben, hilft die Verschlüsselung auch. Es muss nicht zeitaufwendig der komplette Datenträger

überschrieben werden (siehe Löschkontrolle in Kapitel 10), sondern es reicht den Anfang des Datenträgers zu überschreiben, um den dort gespeicherten Schlüssel dauerhaft zu vernichten. Nach Art. 42 DS-GVO gibt es eine Meldepflicht für Datenschutzvorfälle. Der Verlust eines Datenträgers oder Notebooks mit personenbezogenen Daten ist grundsätzlich erst einmal ein Datenschutzvorfall. Es spielt dabei keine Rolle, ob der Datenträger gestohlen oder verloren wurde. Nur wenn »voraussichtlich kein Risiko für die Rechte und Freiheiten der Betroffen« besteht, kann auf die Meldung verzichtet werden. Ist der Datenträger auf einem Kreuzfahrtschiff ins Meer gefallen, besteht wohl kein Risiko, dass irgendjemand Zugriff auf die Daten erhält. Haben Sie das Notebook irgendwo liegen gelassen, sieht das anders aus. Sind die personenbezogenen Daten jedoch durch eine Verschlüsselung nach Stand der Technik und ein sicheres Verschlüsselungspasswort geschützt, kann davon ausgegangen werden, dass voraussichtlich kein Risiko besteht und damit muss der Vorfall zwar intern dokumentiert, aber nicht an die Aufsichtsbehörde gemeldet werden. Hier bringt Ihnen die Verschlüsselung der Daten einen echten Vorteil. Insgesamt unterscheidet man vier Konzepte zur Verschlüsselung von Daten auf Datenträgern (vergleiche Abbildung 23.1): die Datenträgerverschlüsselung, bei der der gesamte Datenträger verschlüsselt wird, die Partitionsverschlüsselung, bei der eine oder mehrere Partitionen der Festplatte verschlüsselt werden, die Containerverschlüsselung, bei der ein Container als Laufwerk oder Ordner zur Verfügung gestellt werden kann, in dem dann alle Dateien verschlüsselt sind, oder die Dateiverschlüsselung, bei der einzelne Dateien separat verschlüsselt werden.

Alle vier Konzepte werden im Folgenden detailliert beschrieben.

Abbildung 23.1: Es gibt vier Konzepte, wie Dateien auf einem Datenträger verschlüsselt werden können.

Datenträgerverschlüsselung Bei der Datenträgerverschlüsselung (englisch: Full Disc Encryption, FDE) wird der gesamte Datenträger, also zum Beispiel die Festplatte oder der USB-Stick, verschlüsselt. Hierbei werden alle Daten und gegebenenfalls auch das komplette Betriebssystem auf dem Datenträger verschlüsselt. Eine Datenträgerverschlüsselung nutzt aus Geschwindigkeitsgründen in der Regel ein symmetrisches Verschlüsselungsverfahren (siehe Kapitel 17). Das Schlüsselmanagement erfolgt in einem zweistufigen Verfahren. Der Schlüssel, der die Daten verschlüsselt, wird Data Encryption Key (DEK, Datenverschlüsselungsschlüssel) genannt. Dieser Schlüssel wird vom System zufällig generiert und geschützt innerhalb eines weiteren, speziell verschlüsselten Bereichs des Datenträgers gespeichert. Dieser weitere Bereich für die Ablage des Data Encryption Key wird je nach Produkt und Anwendungsszenario unterschiedlich geschützt. Es kann zum einen ein aus einem Nutzerpasswort abgeleiteter Key Encryption Key (KEK, Schlüsselverschlüsselungsschlüssel) für ein symmetrisches Verschlüsselungsverfahren für den Schlüssel verwendet werden. Dann muss die Nutzerin das Passwort zum Entschlüsseln eingeben. Es kann auch ein öffentlicher Schlüssel eines asymmetrischen Verschlüsselungsverfahrens benutzt werden. Dies nennt man im Englischen Key Wrapping (Schlüsselverhüllung). Dieses würde man

zum Beispiel bei der Nutzung einer Chipkarte zur Entschlüsselung nutzen. Die Nutzerin muss dann zusätzlich die PIN der Chipkarte eingeben. Der Vorteil dieser zweistufigen Schlüsselspeicherung zeigt sich zum Beispiel bei der Änderung des Nutzerpassworts. In dem Fall muss nur der Data Encryption Key neu verschlüsselt werden und nicht der komplette Datenträger. Mit dem Verfahren ist es auch möglich, dass mehrere Nutzerinnen mit ihrem jeweiligen persönlichen Passwort die Entschlüsselung einleiten können. Der eigentliche Verschlüsselungsschlüssel wird mehrfach gespeichert und dabei jeweils mit dem individuellen Passwort der verschiedenen autorisierten Nutzerin geschützt. Es muss sichergestellt sein, dass ein Angreifer das Datenfeld mit dem verschlüsselten Data Encryption Key nicht kopieren und bei Bedarf wieder einspielen kann. Damit könnte er Passwortänderungen de facto rückgängig machen oder entzogene Zugriffsberechtigungen wiederherstellen. Da Kopieren lässt sich bei einer Datei nicht ohne weiteres verhindern. Das Wiedereinspielen lässt sich aber durch eine sichere Bootkette erkennen. Ein verschlüsseltes Systemlaufwerk hat zwingend immer auch einen kleinen unverschlüsselten Teil. Auf dem unverschlüsselten Teil befindet sich die Software, die dafür sorgt, dass der zur Entschlüsselung erforderliche Schlüssel zur Verfügung gestellt wird und das Betriebssystem booten kann. Gegebenenfalls wird von dieser Software auch das Passwort zur Freigabe des Schlüssels abgefragt. Gleichzeitig ist dieser unverschlüsselte Festplattenbereich mit der BootSoftware aber auch eine Sicherheitslücke, da sie von einem Angreifer manipuliert werden kann. Deshalb muss dieser Bereich geeignet abgesichert werden, damit Manipulationen erkannt werden. Unter Windows 10 dient dazu der Secure Boot Mechanism. Hierbei werden Prüfsummen, unter anderem auch über diesen unverschlüsselten Bereich der Festplatte, sicher gespeichert und bei jedem Boot geprüft. Stimmt etwas nicht, kann die Festplatte nicht entschlüsselt werden.

Die polnische IT-Sicherheitsspezialistin Joanna Rutkowska hat mit dem sogenannten Evil-Maid-Angriff einen prototypischen Angriff gegen die Verschlüsselungssoftware TrueCrypt implementiert. Bei dem Angriffsszenario geht ein Geschäftsmann zum Frühstück und lässt sein Notebook, das durch eine Datenträgerverschlüsselung geschützt ist, im Hotelzimmer offen liegen. Das Putzpersonal bootet das Notebook von einem USB-Stick und manipuliert den unverschlüsselten Bootbereich der Festplatte, danach wird das Notebook zurückgelegt. Der Geschäftsmann nutzt dann sein Notebook, wobei die manipulierte Software sein eingegebenes Verschlüsselungspasswort auf die Festplatte schreibt. Bei der nächsten Gelegenheit wird das Notebook gestohlen und kann dank des gespeicherten Passworts entschlüsselt werden. Dieser Angriff funktioniert grundsätzlich auch gegen den TrueCrypt-Nachfolger Veracrypt, Bitlocker und andere DatenträgerVerschlüsselungssoftware. Mechanismen wie Secure Boot sorgen dafür, dass solch ein Angriff bemerkt wird, indem der unverschlüsselte Teil der Festplatte auf Veränderungen überprüft wird. TrueCrypt sollte heute nicht mehr eingesetzt werden, da es auch aus anderen Gründen als unsicher gilt. Die Betriebssysteme Apple und Microsoft Windows liefern mittlerweile out of the box eine Verschlüsselung der Datenträger mit: FileVault 2 bei Apple beziehungsweise Bitlocker bei Microsoft (siehe Abbildung 23.2). Unter Windows 10/11 kann auch die Open-Source-Software VeraCrypt zur Verschlüsselung der gesamten Festplatte eingesetzt werden. Auch unter Linux gibt es Möglichkeiten zur Verschlüsselung der Festplatte, zum Beispiel mit der Software dm-crypt, die in den Kernel integriert ist. Ein kommerzielles Produkt, das in Deutschland bis 2019 vielfach von Behörden eingesetzt wurde, war Safeguard Easy von Utimaco, später von Sophos.

Abbildung 23.2: Dialog zum Einrichten der Datenträgerverschlüsselung Bitlocker unter Windows 10.

Auch Android verschlüsselt in aktuellen Versionen den Flashspeicher. Hierbei kommt dm-crypt zum Einsatz. Leider bietet Android keine Möglichkeit, ein separates Passwort für diese Verschlüsselung zu verwenden. Es wird zwingend das Benutzerpasswort genutzt. Damit sind die Anmeldung am System und die Freigabe der Verschlüsselung durch dasselbe Passwort geregelt und finden bei der Anmeldung gleichzeitig statt. Apple hat seit der Einführung des iPhone 3GS (beziehungsweise iPad) eine hardwarebasierte Verschlüsselung in seine iOS-Endgeräte eingebaut. Zwischen dem Arbeitsspeicher und der Flash-basierten Festplatte sitzt eine Hardware-Verschlüsselungseinheit, die sicherstellt, dass der Flash-Speicher vollständig mit 256 Bit AES-verschlüsselt ist (Abbildung 23.3). Der Schlüssel ist nicht auslesbar in der Hardware

gespeichert und steht automatisch zur Verfügung, sobald das Gerät startet. Lötet ein Angreifer nun zum Beispiel die Flash-Speicherchips aus und versucht sie auszulesen, so kann er nur auf verschlüsselte Daten zugreifen. Da der Schlüssel nicht passwortgeschützt ist, bietet diese Verschlüsselung keinen (!) Zugriffsschutz über das Anmeldepasswort hinaus. Die Verschlüsselung dient in erster Linie dem schnellen Löschen (kryptografisches Löschen) von iPhone und iPad durch die Nutzerin oder den Administrator. Soll das System gelöscht werden, wird einfach der Schlüssel für die Verschlüsselung des Dateisystems durch einen neu generierten Schlüssel überschrieben. Um auf »alte« Daten dennoch zugreifen zu können, müsste daher die Verschlüsselung selbst geknackt werden.

Abbildung 23.3: Schmatische Darstellung der Hardware-Verschlüsselung oder Device Encryption des Flash-Speichers bei iPhone (5s oder neuer) und iPad (Air oder neuer).

Damit ist es bei den wichtigsten Betriebssystemen schon in der üblichen Standardinstallation problemlos möglich, die Datenträger zu verschlüsseln. Situationen, in denen das Wiederherstellungspasswort benötigt werden kann, sind zum Beispiel ein BIOS-Update des Rechners, die Änderung der Bootreihenfolge des Rechners oder der Austausch von Hardwarekomponenten. Bei der Installation beziehungsweise Aktivierung der Datenträgerverschlüsselung Bitlocker wird der

Nutzerin angeboten, ein Wiederherstellungspasswort zu speichern. Dabei gibt es drei Möglichkeiten: den Ausdruck auf Papier, die Speicherung auf einem USB-Stick oder die Speicherung auf OneDrive. Dort hat potenziell Microsoft Zugriff auf den Schlüssel. Letzteres ist auf privaten Systemen die Default-Einstellung. In einer Domain-Umgebung wird der Schlüssel im Active Directory gespeichert. Ein Backup des Wiederherstellungspassworts muss auch gemacht werden. Es gibt immer wieder Situationen, in denen dieses Passwort benötigt wird. Für private Anwender ist es am besten, den Schlüssel auszudrucken und diesen Ausdruck sicher aufzubewahren. Haben Sie den Schlüssel in einer Situation, in der er benötigt wird, nicht mehr zur Verfügung, sind die Daten unwiederbringlich verloren. Eine sichere Verschlüsselung ist mit vertretbarem Aufwand nicht zu knacken. Im privaten Umfeld muss der Anwender entscheiden, ob er in eigener Verantwortung das Wiederherstellungspasswort aufbewahrt (und das Risiko des Verlierens eingeht) oder ob er den bequemeren Weg geht und das Wiederherstellungspasswort bei Microsoft in der Cloud speichert und damit das Risiko eingeht, dass Microsoft potenziell das Passwort kennt.

Partitionsverschlüsselung Ein Datenträger wird häufig in mehrere Partitionen unterteilt. Das Betriebssystem wird auf einer Partition installiert und die Nutzerdaten landen auf einer anderen Partition. Dies ergibt Vorteile beim Umgang mit den unterschiedlichen Dateien wie Nutzerdaten, Software und Konfigurationsdateien. Unter Windows erhält häufig jede Partition einen eigenen Laufwerksbuchstaben. Bei Apple, Linux oder Unix werden die Partitionen über Verzeichnisse bereitgestellt. Die Nutzerin eines LinuxSystems kann nicht unterscheiden, ob alle Daten auf einer Partition gespeichert werden, oder ob der Verzeichnisbaum /home mit den Nutzerdaten auf einer eigenen Partition gespeichert ist. Eine Partitionsverschlüsselung verschlüsselt den Inhalt einer Partition komplett. Sie ist also ähnlich einer Komplettverschlüsselung eines Datenträgers, bloß eingeschränkt auf eine oder mehrere Partitionen. Es

bietet sich zum Beispiel unter Windows an, nur die Partition mit den Nutzerdaten zu verschlüsseln. Eine Partitionsverschlüsselung wird häufig eingesetzt, wenn aus Sorge vor Performanceverlusten durch die Verschlüsselung das Betriebssystem nicht verschlüsselt werden soll. Auf einem Server kann eine Partitionsverschlüsselung sinnvoll sein, wenn dadurch die Administratoren vom Zugriff auf die Daten, die in einer verschlüsselten Partition gespeichert sind, abgehalten werden. Da eine Nutzerin mit ihren Rechten eine Partition nicht löschen kann, gibt es leichte Vorteile gegenüber der Containerverschlüsselung, um die es im nächsten Abschnitt geht.

Containerverschlüsselung Bei der Containerverschlüsselung wird auf dem Datenträger ein Bereich (meist eine spezielle Datei) angelegt. Diese Datei wird der Nutzerin über eine Software – nach Eingabe des Passworts – als Laufwerk oder Verzeichnis zur Verfügung gestellt. Alle Dateien, die auf dieses Laufwerk oder in dieses Verzeichnis geschrieben werden, landen verschlüsselt in der Containerdatei. Diese speziellen Containerdateien können auf der lokalen Festplatte, einem Netzwerklaufwerk oder auch in der Cloud gespeichert werden. Auch bei einer Containerverschlüsselung kann die zweistufige Schlüsselspeicherung genutzt werden. Eine Containerverschlüsselung ist keine gute Lösung für die Zusammenarbeit in Teams, obwohl die Speicherung der Containerdateien auf Netzlaufwerken dies auf den ersten Blick nahelegt. Aus Sicht des Betriebssystems ist ein Container eine normale Datei. Sobald die Datei durch die Verschlüsselungssoftware zum Schreiben von einem Teammitglied geöffnet wird, wird der Schreibzugriff für alle anderen Teammitglieder gesperrt und der Zugriff auf alle Dateien im Container blockiert. Damit ist diese Variante der Verschlüsselung in einem Team nicht sinnvoll nutzbar. Eine Containerverschlüsselung macht nur dann Sinn, wenn der Container immer nur von einer Person geöffnet wird. Dies ist eigentlich nur bei Nutzung durch Einzelpersonen der Fall. Der Schutz von Daten auf einem USB-Stick ist ein wichtiges Anwendungsszenario, da dann zusätzlich zum Container mit den

verschlüsselten Daten auch noch unverschlüsselte Daten (zum Beispiel Präsentationen) auf dem USB-Stick gespeichert werden können. Auf die verschlüsselten Daten hat man nur vom eigenen Rechner aus Zugriff, auf die unverschlüsselten Dateien kann auch von anderen Rechnern (zum Beispiel vom Präsentationsrechner während eines Seminars) zugegriffen werden. Damit muss das Passwort der Verschlüsselung nicht an fremden Rechnern eingeben werden. Das Konzept der Containerverschlüsselung wurde von vielen Produkten umgesetzt. Mit zu den ersten Programmen am Markt gehörten PGPdisk (1998, kommerzielles Produkt) und TrueCrypt (2004, mittlerweile eingestellt). Seit Windows 7 gibt es mit Bitlocker To Go eine Containerverschlüsselung von Microsoft zur Verschlüsselung von USBSticks. Im unverschlüsselten Bereich des Sticks wird eine Software gespeichert, mit der auf alten Windows Systemen die verschlüsselten Daten gelesen werden können. Im Behördenbereich ist noch TrustedDisk im Einsatz, eine proprietäre Weiterentwicklung von TrueCrypt, die für die unterste behördliche Geheimhaltungsstufe (VS-NfD) zugelassen ist. Apple verwendete mit FileVault 1 eine Variante der Containerverschlüsselung, um die Nutzerverzeichnisse im Mac OS zu verschlüsseln.

Dateiverschlüsselung Die einfachste Art der Verschlüsselung einer einzelnen Datei ist die manuelle Verschlüsselung mit einem entsprechenden Programm. Dies ist zum Beispiel mit GnuPG, OpenSSL oder AxCrypt möglich. Aufgrund der manuellen Verschlüsselung wird so eine Software nur bei der Verschlüsselung weniger Dateien oder bei der gelegentlichen, fallweisen Verschlüsselung sinnvoll sein. Sollen Dateien systematisch und transparent verschlüsselt werden, setzt man eine Software ein, die den Zugriff auf die Dateien überwacht und sich um die Verschlüsselung kümmert. Jede Datei, die einem konfigurierten Muster entspricht, wird unabhängig vom Speicherort beim Schreiben verschlüsselt und beim Lesen entschlüsselt. Der Verschlüsselungsschlüssel (Data Encryption Key) wird bei fast allen Systemen für jede Datei individuell generiert und in einem Datei-Header

mit einem weiteren Schlüssel (Key Encyption Key) verschlüsselt gespeichert. Dies hat auch den Vorteil, dass die Information über die Verschlüsselung mit der Datei zum Beispiel in das Backup kopiert wird. Die zweistufige Verschlüsselung dient auch dem Zugriffsmanagement (zum Beispiel Gruppenschlüssel). Eine Nutzerin kann auf alle Dateien zugreifen, von denen sie den entsprechenden Key Encryption Key hat. Zu einer transparenten Dateiverschlüsselung gehört in der Regel auch eine Softwarekomponente zum automatischen Management der Key Encryption Keys. Bei der Zusammenarbeit in Teams ist die Dateiverschlüsselung die Lösung der Wahl, da sie die Zusammenarbeit und das gemeinsame Arbeiten mit verschlüsselten Dateien am wenigsten einschränkt. Eine Dateiverschlüsselung gibt es seit Windows NT von Microsoft mit dem Encrypted File System (EFS). Es hat aber im Management durchaus seine Tücken. Im Behördenbereich spielte Utimaco LanCrypt eine gewisse Rolle. Dem Digital Rights Management (DRM) von Microsoft liegt auch eine Dateiverschlüsselung zugrunde. Bei der Datenspeicherung in der Cloud gibt es zum Beispiel mit BoxCryptor und Cryptomator Anwendungen, die eine Dateiverschlüsselung umsetzen. Apple nutzt unter iOS ebenfalls eine Dateiverschlüsselung mit einem ausgefeilten Schlüsselmanagement. Dieses stellt sicher, das Daten unterschiedlicher Vertraulichkeitsstufe mit unterschiedlichen Schlüsseln verschlüsselt werden. Die Vertraulichkeitsstufen wurden von Apple festgelegt. Es gibt dabei einen Schlüssel, in den das Nutzerpasswort eingeht, das heißt, der Schlüssel kann nur genutzt werden, wenn die Nutzerin am Gerät angemeldet ist. Mit diesem Schlüssel werden zum Beispiel E-Mails verschlüsselt gespeichert. Ein anderer Schlüssel ist immer verfügbar, wenn das Gerät in Betrieb ist. Die Details hierzu hat Apple dokumentiert.

Daten in Bewegung Werden Daten nicht auf Datenträgern gespeichert, sondern zum Beispiel im Netzwerk übertragen, wird von »Daten in Bewegung« gesprochen.

Auch in diesem Fall ist eine Verschlüsselung erforderlich, da Datenverkehr im Netzwerk (sowohl im WLAN als auch über das Netzwerkkabel) abgehört werden kann. Standardmäßig ist keine automatische Verschlüsselung im Internet vorgesehen. Sie muss durch geeignete Konfiguration der Geräte oder aktives Handeln der Nutzerinnen aktiviert werden. Wird eine Webseite über http (das heißt unverschlüsselt) und über https (das heißt verschlüsselt) angeboten, muss die Nutzerin durch den entsprechenden Aufruf der Webseite festlegen, ob die Daten unverschlüsselt oder verschlüsselt übertragen werden. Der Betreiber der Webseite kann durch eine Konfiguration zum Beispiel festlegen, dass alle, die die unverschlüsselte Webseite per http aufrufen, automatisch auf die verschlüsselte Version umgeleitet werden.

Transportverschlüsselung Werden Daten im Internet zwischen Absender und Empfänger verschlüsselt transportiert und ist ein Transportserver an der Kommunikation zwischen Absender und Empfänger beteiligt, gibt es zwei Möglichkeiten (siehe Abbildung 23.4) der Verschlüsselung beim Transport: Der Absender verschlüsselt die Daten und die Daten werden von den Transportservern ohne Entschlüsselung zum Empfänger transportiert und erst dort entschlüsselt (Abbildung 23.4a). Sie sprechen dann von einer Ende-zu-Ende-Verschlüsselung (E2E-Verschlüsselung). Der Betreiber des Transportservers kann nicht auf die Daten zugreifen. Wenn man ihm nicht vertraut, ist dies das geeignete Kommunikationsmodell. Wenn der Transportserver beim Transport jedoch die Daten verarbeiten muss, benötigt er sie im Klartext. Der Absender verschlüsselt die Daten für den Transport zum Transportserver und der Transportserver entschlüsselt die Daten zur Verarbeitung. Danach werden die Daten vom Transportserver erneut verschlüsselt und zum Empfänger transportiert, wo sie entschlüsselt werden. Während der beiden Transportphasen sind die Daten verschlüsselt, auf dem Transportserver jedoch nicht (Abbildung 23.4b). Man

bezeichnet dies als Transportverschlüsselung. Da der Betreiber des Servers auf die Daten zugreifen kann, muss dieser vertrauenswürdig sein.

Abbildung 23.4: Die unterschiedlichen verschlüsselten Datenströme bei einer Ende-zu-Ende-Verschlüsselung (a) und einer Transportverschlüsselung (b).

Auch wenn die Verschlüsselung den Transport der Daten schützt, bleibt die Frage der gegenseitigen Verifikation von Absender und Empfänger. Dies ist eine der größten Herausforderungen im Schlüsselmanagement, da nur durch die korrekte Zuordnung von Schlüsseln zu Identitäten sichergestellt werden kann, dass kein Angreifer sich in die Kommunikation eingeklinkt hat (Man-In-The-Middle-Angriff) und diese mitliest und manipuliert, ohne dass Sender und Empfänger Kenntnis davon erlangen. Transportverschlüsselung wird heute zum Beispiel beim Transport von E-Mails, beim Abruf von Webseiten oder bei Videokonferenzen eingesetzt. Während bei Videokonferenzen eine Transportverschlüsselung fast immer eingesetzt wird, ist die Situation bei E-Mails anders. Ein E-Mail-Client nutzt bei der Kommunikation mit seinem E-Mail-Server fast immer eine Transportverschlüsselung (zum Beispiel über IMAPS, SMTPS, ActiveSync über TLS). E-Mail-Server untereinander nutzen jedoch noch viel zu selten Transportverschlüsselung (SMTPS). Es gibt Initiativen, dies zu verbessern, wie zum Beispiel »E-Mail made in Germany«.

E-Mail-Verschlüsselung Bei der klassischen papierbasierten Post kennen Sie auch mindestens zwei Vertraulichkeitsstufen: den Brief und die Postkarte. Jeder von uns hat ein Gefühl dafür, welche Informationen einen Brief, das heißt einen verschlossenen Umschlag, erfordern und welche auf eine Postkarte geschrieben werden können. Diese Einschätzung unterliegt auch einem Wandel. In den sechziger Jahren des 20. Jahrhunderts wurden Verrechnungschecks häufig per Postkarte verschickt. In den zwanziger Jahren des letzten Jahrhunderts (zur Blütezeit der Naturwissenschaften in Deutschland) wurde die wissenschaftliche Kommunikation auch häufig über Postkarten abgewickelt. Heute würde man (zumindest in der analogen Welt) solch eine Kommunikation als zu offen empfinden. In der digitalen Welt wird die E-Mail-Kommunikation überwiegend als Postkarte verschickt, das heißt ohne schützenden virtuellen Briefumschlag. Die meisten werden in Schulungen zum Umgang mit EMail schon den Postkartenvergleich bei unverschlüsselter E-Mail gehört haben. Der virtuelle Briefumschlag wird bei der E-Mail durch Verschlüsselung sichergestellt. Zur Verschlüsselung von E-Mails gibt es zwei wesentliche Verfahren: S/MIME und OpenPGP. Die beiden Verfahren beschreiben den genauen Aufbau einer verschlüsselten und einer digital signierten E-Mail sowie das Schlüsselmanagement (beide Verfahren nutzen die HybridVerschlüsselung, siehe Kapitel 17). Die Datei- beziehungsweise Nachrichtenformate von verschlüsselten und signierten E-Mails sind inkompatibel. Auch das Schlüsselmanagement ist unterschiedlich. S/MIME arbeitet mit baumartigen Vertrauensstellungen, bei denen die Verknüpfung von Schlüssel und Identität (Zertifizierung) durch vertrauenswürdige Dritte (Trustcenter) erfolgt (Public Key Infrastructure, X.509). OpenPGP nutzt ein Web-of-Trust, bei dem die Zertifizierung durch persönliche Kontakte erfolgt. Die Nutzung des Web-of-Trust verlangt vom Anwender ein tieferes, formales Verständnis der Vertrauensbeziehungen. Es gibt auch Software, zum Beispiel GnuPG, die beide Dateiformate erzeugen und verarbeiten kann.

Es gibt zahlreiche E-Mail-Programme, zum Beispiel Microsoft Mail, Microsoft Outlook, Mozilla Thunderbird oder Apple Mail, die von Haus aus E-Mails verschlüsseln können; in der Regel kommt hier das S/MIME-Verfahren zum Einsatz. Noch nicht allgemein üblich ist der Umgang mit verschlüsselten und signierten E-Mails in webbasierten EMail-Oberflächen (zum Beispiel Outlook Web Access oder Google Mail). Microsoft unterstützt im Outlook Web Access verschlüsselte oder signierte E-Mails nur über ein S/MIME-Steuerelement in Microsoft Edge oder im Chrome-Browser von Google. Zur Nutzung des S/MIMESteuerelements sind Einstellungen über Gruppenrichtlinien in einer Windows-Domain erforderlich. Damit wird S/MIME im Outlook Web Access nur für größere Installationen unterstützt. Freiberufler, kleine Betriebe und auch Privatpersonen sind ausgeschlossen.

Virtuelle private Netzwerke (VPN) Als virtuelles privates Netz (VPN) bezeichnet wir verschlüsselte Netzwerkverbindungen, die es uns erlauben, einen Rechner über die verschlüsselte Verbindung mit einem geschützten Netz zu verbinden. Gerade in der Corona-Pandemie war das die einzige Möglichkeit, aus dem Homeoffice IT-Ressourcen im Unternehmen sicher und abhörsicher zu benutzen. Dienstreisende Beschäftigte kennen solche Zugriffe schon länger, wenn sie während der Dienstreise aus dem Hotel auf die ITRessourcen des Unternehmens zugreifen. Aber auch Unternehmen mit mehreren Standorten koppeln ihre Netze an den verschiedenen Standorten über VPN-Verbindungen. Damit können alle Beschäftigten standortübergreifend ein Netz nutzen. Beim VPN unterscheiden wir zwischen der kompletten Verschlüsselung des Netzwerkverkehrs und der gezielten Nutzung eines Proxys für einzelne Dienste, welcher den Verkehr verschlüsselt weiterleitet.

Ist ein VPN anonym? Immer wieder können Sie in Zeitschriften lesen, dass ein VPN eine anonyme Internetnutzung ermöglichen würde. Diese Behauptung ist falsch! Ein VPN sorgt dafür,

dass die Verbindung zwischen den beiden Endpunkten (also zum Beispiel zwischen Ihrem PC und dem VPN-Server) verschlüsselt wird und niemand diese Verbindung belauschen kann. Der VPN-Anbieter sieht zumindest die IP-Adresse des Clients (zum Beispiel die IPAdresse Ihres Rechners). Bei den meisten VPN-Anbietern müssen Sie ein Konto haben oder sogar für die Nutzung bezahlen. Wenn Sie den VPN-Anbieter klassisch per Kreditkarte oder Abbuchung bezahlen, kennt er Ihre Identität. Und damit haben Sie eine pseudonyme Nutzung. Um das Internet über ein VPN anonym zu nutzen, müssen Sie mehrere Voraussetzungen erfüllen: Sie benötigen eine IP-Adresse, die Ihnen nicht zugeordnet werden kann. Dies erreichen Sie zum Beispiel in einem offenen WLAN, das Sie ohne Registrierung nutzen können. Sie müssen ein Nutzerkonto bei einem VPN-Anbieter mit einem anonymen Mail-Konto eröffnen oder einen VPN-Anbieter nutzen, den Sie ohne Nutzerkonto nutzen können. Sie müssen die Gebühren anonym bezahlen, das heißt zum Beispiel per Bitcoin. Sie müssen dem Anbieter vertrauen. Wenn Sie wirklich anonym surfen wollen, müssen Sie Dienste wie den TOR-Browser verwenden, die mehrere hintereinander geschaltete Server zur Anonymisierung nutzen.

Bei der verschlüsselten Netzwerkanbindung wird Ihr Rechner so mit dem Firmennetz verbunden, dass er die Unternehmensressourcen im Prinzip genau wie die Rechner am Unternehmensstandort nutzen kann. Dies stellt ein erhöhtes Risiko dar, da ein Rechner außerhalb des Unternehmens behandelt wird, als wäre er innerhalb. In der Regel wird man deshalb über Firewallregeln den allzu freien Zugriff einschränken. Bei dem Zugriff über einen Proxy können Sie im Unternehmen gezielt die Dienste zulassen, die genutzt werden sollen. Alle anderen sind dann gesperrt.

Secure Shell Die unter IT-lern beliebteste einfache Methode zur Realisierung eines VPN ist der Einsatz des Programms »Secure Shell« (SSH). Eigentlich ist SSH eine Programm, um über das Netz auf einen entfernten Rechner eine Eingabeaufforderung beziehungsweise ein Kommandozeile

(Remote-Terminal-Sitzungen) zu öffnen. SSH verschlüsselt den kompletten Datenverkehr und erlaubt eine Anmeldung am entfernten Rechner mittels kryptografischer Schlüssel. Ursprünglich wurde SSH entwickelt, um die unsicheren, da unverschlüsselten Programme Remote Shell (rsh) und Telnet abzulösen. Bei Remote-Terminal-Sitzungen ist SSH Stand der Technik. Außerdem ist SSH für alle Betriebssysteme verfügbar. Die Beliebtheit kommt daher, dass SSH über die bestehende verschlüsselte Verbindung andere Datenverbindungen tunneln kann (Port Forwarding). So kann ein SSH-Tunnel im Browser als Proxy genutzt oder eine Remote-Desktop-Verbindung zu einem entfernten Rechner über SSH getunnelt werden.

Abbildung 23.5: Die Verbindung von einem Client zu einem Server (Ziel) über eine SSHVerbindung.

Abbildung 23.5 zeigt den schematischen Aufbau einer Verbindung über einen SSH-Tunnel per Port Forwarding. Die Anwendung auf dem Client muss entsprechend konfiguriert werden, damit sie den Tunnel nutzt. Der Administrator des SSH-Servers konfiguriert, ob die Funktionalität »Port Forwarding« aktiviert wird. Die konkrete Konfiguration, welche Ports weitergeleitet werden, erfolgt dann auf dem Client. Dies setzt ein hohes Verantwortungsbewusstsein bei den Nutzerinnen voraus, da SSHPort-Forwarding eine elegante Möglichkeit ist, eine Firewall zu umgehen (falls die Firewall SSH zulässt). Eine Besonderheit sind sogenannte Remote-Tunnel. Dabei wird eine Verbindung vom SSH-Server zum SSH-Client hergestellt. Damit ist es grundsätzlich möglich, eine Verbindung ins Unternehmen aufzubauen,

auch wenn die Firewall dies eigentlich nicht zulässt. Auch wenn der Remote-Tunnel eine Verbindung von außen nach innen zulässt, ist die SSH-Verbindung von innen nach außen aufgebaut worden. RemoteTunnel lassen sich deaktivieren. Dies sollte der Standard bei einem SSHServer sein.

WebSSL Ein WebSSL-Server bietet eine Web-Oberfläche, um darüber Webseiten aufzurufen. Ihr Webbrowser stellt die Verbindung zum WebSSL-Server her und ruft dann aus dieser Oberfläche die eigentliche Webseite auf. Da die Links in der aufgerufen Webseite umgeschrieben werden, können Sie ganz normal auf die Webseite klicken. Im Grunde ist das ein spezialisierter Proxy zum Websurfen. Diese Variante wird auch als »clientless SSL-VPN« bezeichnet. Wenn zusätzlich ein Plug-in im Browser installiert wird oder ein entsprechendes Javscript-Programm läuft, kann der Browser als Proxy für andere Anwendungen und für sich selber agieren. Die Softwarekomponente im Browser baut eine TLS-Verbindung zu ihrem Server und tunnelt den Datenverkehr darüber. Viele kommerzielle VPNAnbieter bieten ihren Kunden diese Möglichkeit, um über die VPNVerbindung zu surfen, ohne einen »richtigen« VPN-Client zu installieren. Diese Variante wird auch als Thin-SSL-VPN bezeichnet. Abbildung 23.6 zeigt, dass die IP-Adresse des VPN-Servers beim Betreiber einer Webseite angezeigt wird, wenn der Datenverkehr über das Plug-in umgeleitet wird. Der gleichzeitige Aufruf aus einem zweiten Browser ohne das VPN-Plug-in zeigt die IP-Adresse des Providers.

Abbildung 23.6: Der gleichzeitige Aufruf einer Webseite zum Anzeigen der eigenen IPAdresse mit zwei Browsern auf einem Rechner (hier: Anzeige über Heise Netze/Meine IPAdresse).

Einige Hersteller bieten auch eine zu installierende Software als WebSSL-Client an. Prominente Beispiele sind Anyconnect von Cisco, Network Connect von Juniper, SSL-VPN von Fortinet oder F5 oder auch die Open-Source-Implementierung OpenConnect. Diesen Produkten ist gemeinsam, dass sie bevorzugt eine Verbindung über DTLS versuchen und erst, wenn das nicht möglich ist, auf TLS über Port 443 ausweichen. DTLS ist ein Verschlüsselungsstandard, der auf TLS basiert, aber über das Protokoll UDP funktioniert. UDP ist ein Netzwerkprotokoll, dass im Gegensatz zu TCP keine Eingangsbestätigungen für Datenpakete nutzt. Damit ist UDP schneller als TCP, aber auch anfälliger für Paketverluste. Während TCP bei ausbleibender Empfangsbestätigung ein Paket nochmals sendet, passiert bei UDP in so einem Fall nichts, da der Absender keine Information über fehlende Pakete beim Empfänger erhält. Das Standardprotokoll TLS verlässt sich auf die gesicherte Übertragung der Pakete durch TCP beim Verbindungsaufbau. DTLS muss sich selbst

um den Umgang mit fehlenden Paketen kümmern. Der Unterschied zwischen TLS und DTLS ist der Umgang mit Paketverlusten.

OpenVPN OpenVPN ist ein (auch bei den Anbietern von VPN-Diensten) beliebtes Produkt, da es eine lizenzkostenfreie Open-Source-Version gibt. Eine TAP/TUN-Treiber erzeugt auf einem System ein virtuelles Netzwerk-Interface (Netzwerk-Socket, zum Beispiel tun0) und ein dazugehöriges Gerät (device, /dev/tun0). Eine Anwendung kommuniziert mit dem virtuellen Interface. Die OpenVPN-Software liest beziehungsweise schreibt den Datenverkehr über das zugehörige Gerät. Dann werden die Daten durch die OpenVPN-Software verbeziehungsweise entschlüsselt. Die Kommunikation nach außen erfolgt dann über das physikalische Netzwerk-Interface (zum Beispiel eth0). Abbildung 23.7 zeigt, wie die OpenVPN-Anwendung die Daten zwischen dem physischen Netzwerk und den virtuellen Netzwerkwerktreibern (TAP/TUN-Device) transportiert.

Abbildung 23.7: OpenVPN läuft im User Space und transportiert Daten zwischen einem physischen Netzwerk-Interface (Netzwerk-Socket) und einem TUN Device, das mit einem virtuellen Netzwerkinterface (TUN Socket) verbunden ist.

Der TAP-Treiber erzeugt ein Interface auf Ethernet-Ebene, der TUNTreiber auf IP-Ebene. Über den TAP-Treiber können zwei Netzwerke verbunden werden, sodass alle Geräte in beiden Netzen erreicht werden können. Ein TUN-Treiber erlaubt es, Datenverkehr über Routing zu transportieren.

Standardmäßig verschickt OpenVPN die verschlüsselten Pakete über UDP. Es kann aber auch TCP verwendet werden. OpenVPN nutzt entweder statische Schlüssel (mit optionaler Benutzerauthentifizierung) mit symmetrischer Verschlüsselung oder TLS mit zertifikatbasierter Authentisierung zur Verschlüsselung der Daten. Für die Implementierung der Verschlüsselungsoperationen nutzt OpenVPN die Kryptobibliothek OpenSSL. OpenVPN ist für alle wesentlichen Betriebssysteme verfügbar.

IPsec IPsec ist fester Bestandteil des IPv6-Protokolls. In der Variante, in der wir es heute nutzen, ist es eine Rückportierung nach IPv4. IPsec ersetzt auf OSI-Schicht 3 (siehe Kapitel 21), also die IP-Schicht. Es kann damit für alle Netzwerkkommunikation oberhalb von OSI-Schicht 3 genutzt werden. Eigentlich besteht IPsec aus den beiden Protokollen »Authentication Header« (AH, Protokoll 51) und »Encapsulating Security Payload« (ESP, Protokoll 50). Das Protokoll AH bietet nur eine schlüsselbasierte Prüfsumme (HMAC) zur Integritätssicherung der Datenpakete. Der Inhalt bleibt unverschlüsselt. Der Integritätscheck bezieht alle Daten, die sich normalerweise innerhalb eines Datenpakets nicht ändern, mit ein. Felder, die sich ändern (wie die TTL, Time to Live, die von jedem Router dekrementiert wird) werden nicht berücksichtigt. Die Teile, die bei der Network Adresss Translation (NAT) geändert werden (Quell-IP, Quell-Port), gehören eigentlich zu den nicht änderbaren Feldern. Deshalb sind IPsec AH und NAT inkompatibel. Das Protokoll ESP verschlüsselt zusätzlich zur Integritätssicherung den Inhalt des Datenpakets. Die Integritätssicherung berücksichtigt den IPHeader nicht. Deswegen könnte die Quell-IP geändert werden. Das aber der TCP-/UDP-Header verschlüsselt wird, kann der Quell-Port nicht geändert werden. Damit ist auch ESP inkompatibel mit NAT. Lediglich eine IPsec-Verbindung kann über ein NAT-Gerät abgewickelt werden. Allerdings wird das nicht von allen NAT-Geräten unterstützt. Ausgehend von der proprietären Cisco-Erweiterung »NAT-Traversal« ist die Nutzung von ESP über NAT dann aber doch möglich (RFC 3948). Dazu

wird das komplette IPsec-Paket in ein UDP-Paket gepackt, diese UDPPakete überstehen den NAT-Prozess unbeschadet. Am Ziel wird das ESP-Paket wieder ausgepackt. Es gibt zwei grundsätzlich unterschiedliche Modi der IPsecKommunikation: Transportmodus: Im Transportmodus wird ein zusätzlicher Header, der IPsec-Header, zwischen IP-Header und TCP-/UDP-Header eingefügt. Der originale IP-Header bleibt erhalten. Dieser Modus wird zwischen zwei Endpunkten, typischerweise Rechner, eingesetzt. Tunnelmodus: Im Tunnelmodus werden dem IPsec-Paket ein neuer IP-Header und ein IPsec-Header vorangestellt. Dieser Modus ist primär für den Einsatz zwischen zwei Gateways gedacht. Der innere IP-Header (bei ESP verschlüsselt) enthält die Quell- und Ziel-IPAdressen der beiden kommunizierenden Rechner. Der äußere IPHeader enthält die IP-Adressen der beiden Gateways. Damit sieht ein Außenstehender nur Datenpakete zwischen den Gateways. Die Netzund Kommunikationsstruktur der Geräte hinter den Gateways bleibt verborgen. Es ist auch möglich, dass ein Endgerät mit einem Gateway im Tunnelmodus kommuniziert. Bei einer IPsecVerbindung eines Rechners (zum Beispiel im Homeoffice) ins Unternehmen wird dieser Modus häufig genutzt. Der IPsec Standard geht davon aus, dass beide Seiten über das erforderliche Schlüsselmaterial zur kryptografisch gesicherten Kommunikation besitzen. Wie das erreicht wird, ist im Standard nicht spezifiziert. Die manuelle Schlüsselverwaltung ist der einfachste Weg. Dabei werden die Schlüssel »irgendwie« ausgetauscht und statisch als Security Association (SA) konfiguriert. Als De-facto-Standard hat sich das Internet Key Exchange Protocol (IKEv1 beziehungsweise IKEv2) etabliert. Hiermit erfolgt eine automatische Schlüsselverwaltung. IKE erfolgt standardmäßig per UDP auf Port 500. Die Authentisierung erfolgt entweder auf Basis eines Preshared Keys oder aus Basis von Zertifikaten.

Wenn ein Unternehmen den VPN-Zugang ins Unternehmen auf IPsec basiert und einen Pre-shared Key zur Authentisierung nutzt, dann haben alle Clients denselben Pre-shared Key. Wird der Pre-shared Key kompromittiert, muss er auf allen Rechnern gewechselt werden. Cisco führte eine proprietäre Erweiterung bei seinem IPsec-Client ein. Die Authentisierung erfolgt auch dort per IKE mit einem Preshared Key. Aber zusätzlich muss sich eine Nutzerin mit Nutzernamen und Passwort anmelden. Diese Erweiterung des IKEv1-Protokolls nutzt XAUTH mit einem Pre-shared Key. Sie wird von vielen IPsec-Implementierungen unterstützt. Die zusätzliche Verwendung eines zweiten Faktors wie den Google Authenticator ist möglich. IKEv1 mit XAUTH gilt als unsicherste Variante der IPsec-Nutzung. Da jede Nutzerin den Pre-shared Key kennt, kann sie ein Fake-VPN-Gateway aufsetzen und die Benutzername-Passwort-Paare abgreifen. Die Nutzung einer ZweiFaktor-Authentisierung wird dringend empfohlen. Es gibt zahlreiche Implementierungen von IPsec von den verschiedensten Herstellern. Die Fritzboxen unterstützen IPsec als Server. Windows 10 unterstützt IPsec direkt. Es gibt hier jedoch ein großes Aber: Die Konfiguration von zwei IPsec-Implementierungen unterschiedlicher Hersteller kann kompliziert sein. Häufig werden die Parameter unterschiedlich bezeichnet. Manchmal kann genau der Parameter, der angepasst werden muss, bei dem einen Gerät gar nicht geändert werden. Am einfachsten ist es, wenn beide Komponenten vom gleichen Hersteller sind. Der IPsec-Standard ist grundlegend in RFC 4301, AH in RFC 4302 und ESP in RFC 4302 beschrieben. Details wie IKE sind über zahlreiche weitere RFCs verteilt.

WireGuard Der neue Star am VPN-Himmel ist zweifelsohne Wireguard. Dieses Protokoll ist einfach gehalten, es gibt nur einen Satz Verschlüsselungsfunktionen. Das vereinfacht die Konfiguration. Zur

Konfiguration der Verschlüsselung müssen Sie nur öffentliche Schlüssel austauschen. Das macht den Austausch weniger sicherheitskritisch. Wireguard nutzt für die Verschlüsselung den Algorithmus ChaCha20 mit der Poly1305 als Authenticator. Für den ECDH-Schlüsselaustausch wird Curve25519 und als Hash-Funktion BLAKE2s verwendet. Ein besonderes Feature ist, dass ein bestehender VPN-Tunnel den Wechsel der IP-Adresse des Rechners (egal ob Client oder Server) überlebt. Alle anderen VPN-Tunnel unterstützen diese Art von Roaming nicht. Aus Sicherheitsgründen können wir ein so junges Protokoll (Wireguard wird seit 2016 entwickelt) noch nicht uneingeschränkt empfehlen. Für Linux gibt es schon länger einen Kernel-Treiber, für Windows erst seit Sommer 2021 eine experimentelle Version eines Kernel-Treibers. Andere Implementierungen nutzen die bei OpenVPN beschriebene Technik mit einem TUN-Treiber. Es bleibt abzuwarten, wie sich Wireguard entwickelt.

Kapitel 24

Monitoring IN DIESEM KAPITEL Wie IT-Sicherheit gemessen wird Angriffserkennungssysteme Vom Umgang mit Schadsoftware

Wie merken wir eigentlich, ob es einen IT-Sicherheitsvorfall im Unternehmen gegeben hat? Die Erfahrung zeigt, dass wir häufig darauf hingewiesen werden: entweder von den eigenen Beschäftigten (das ist gut) oder aber von Dritten (das ist nicht so gut). Natürlich sind wir einem externen Hinweisgeber dankbar, aber eigentlich wollen wir doch selber feststellen, ob etwas passiert ist. Dazu müssen wir uns überlegen, an welchen Parametern wir einem Vorfall erkennen.

Metriken der IT-Sicherheit Das Wort »Metrik« ist ein mathematischer Begriff, damit ist das Messen von Abständen gemeint. Abstände sind Zahlen, die wir der Größe nach ordnen können. Wenn wir die Zahlen der Größe nach geordnet haben, können wir über die Reihenfolge der Zahlen entscheiden, welches gemessene Objekt größer oder kleiner ist.

Die Breite eines Fußball-, Eishockey- oder Handballtores können wir als jeweils den Abstand der linken von der rechten Torlatte messen. Dann haben wir drei Zahlen: 732 cm, 183 cm und 300 cm. Diese drei Zahlen können wir vergleichen. Da 732 größer ist als 300 und 300 größer als 183, wissen wir, dass das Fußballtor breiter ist als das Handballtor und dieses wiederum breiter als das Eishockeytor. Aufgrund der gemessenen Zahlen können wir diese Aussage treffen, obwohl die Tore nicht nebeneinanderstanden. Wenn wir dieses Konzept in der IT-Sicherheit anwenden wollen, müssen wir den Zustand unserer IT-Sicherheit auf aussagekräftige Zahlen abbilden, sogenannte Key Performance Indicators (KPI). Nun ist es in der IT-Sicherheit nicht möglich, die relevanten Parameter mit einem Meterstab zu messen. Eigentlich wissen wir noch nicht einmal, was wir überhaupt messen wollen beziehungsweise was wir messen können. Die Körpergröße des Informationssicherheitsbeauftragten ist sicherlich kein vernünftiges Maß in der Informationssicherheit. Wenn wir uns überlegen, was wir messen, dann suchen wir Metriken der IT-Sicherheit. Was sind interessante Größen und wie messen wir die, das heißt, wie bilden wir die interessanten Größen auf Zahlen ab? Beginnen wir unsere Überlegungen mit einfachen Fragen, die im Grunde mit »ja« oder »nein« beantwortet werden können. Sie müssen aber immer auch mindestens eine dritte Antwort vorsehen: »trifft nicht zu«. Die Frage: »Ist eine Datenschutzbeauftragte bestellt?« kann nicht immer mit »ja« oder »nein« beantwortet werden, da es bei der Bestellpflicht einen Schwellenwert gibt (mindestens 20 Personen verarbeiten personenbezogene Daten). Wenn Sie mit Ihrem Unternehmen unter dem Schwellenwert liegen, dann wäre »nein« nicht korrekt, sondern »trifft nicht zu«. Eine Sammlung von einfachen Ja/Nein-Fragen wäre: Ist ein Informationssicherheitsbeauftragter bestellt? Gibt es eine Leitlinie zur Informationssicherheit?

Gibt es eine Nutzerordnung? Gibt es ein Awareness-Programm für die Beschäftigten? Wurde ein ISMS eingeführt? Gibt es ein Notfallkonzept? Sind die Mitglieder des Krisenstabs nominiert? Diese kurze Liste zeigt beispielhaft, welche Art von Fragen in einer ersten Runde gestellt werden. Alle diese Fragen beschäftigen sich mit den organisatorischen Grundregeln. Wenn Sie die Fragen in Kategorien gruppieren (siehe als Beispiel Abbildung 9.2 zum VdS-Quick-Check), dann können Sie in jeder Kategorie den Prozentsatz der Ja-Antworten bestimmen. Und schon haben Sie quantitative Aussagen zur Umsetzung der IT-Sicherheit im Unternehmen. Derartige quantitative Ergebnisse lassen sich sehr gut in einem Spinnennetzdiagramm darstellen. Abbildung 24.1 zeigt die prozentuale Umsetzung der Maßnahmen in den 14 Abschnitten der ISO/IEC 27002. Die einzelnen Strahlen sind mit den Abschnittsnummern aus der ISO beschriftet. Die beiden Kurven aus den Jahren 2018 und 2020 zeigen intuitiv, wie die Umsetzung sich geändert hat. Nicht alles wurde besser – Sie sehen sofort, wo Sie Ihre Bemühungen noch verstärken müssen. Spinnennetzdiagramme können mit der jeweiligen Tabellenkalkulation der gängigen Officepakete leicht erzeugt werden. Sie finden den Diagrammtyp beim Einfügen eines Diagramms im Microsoft Office Excel unter »Netz« und im LibreOffice Calc unter »Netzdiagramm«.

Abbildung 24.1: Ein Spinnennetzdiagramm erlaubt den quantitativen Vergleich mehrerer Messgrößen. Hier, als Beispiel, die Umsetzung der ISO 27002 in einem Unternehmen in den Jahren 2018 und 2020.

Im nächsten Schritt können Sie natürlich auch Metriken finden, die quantitative Ergebnisse liefern. Antwort sollten in % erhoben werden, da dann die Vergleichbarkeit besser ist. Beispiele für solche Metriken wären:

Wie viele Beschäftige haben eine Informationssicherheitsschulung besucht? Für wie viele Datenkategorien wurde eine Schutzbedarfsanalyse durchgeführt? Für wie viele Verarbeitungsprozesse gibt es eine vollständige Dokumentation? Für wie viele gesellschaftskritische Verfahren gibt es ein ITSicherheitskonzept? Auf wie vielen Geräten ist der Anti-Malware-Schutz umgesetzt? Wie viele IT-Komponenten werden nicht von der IT-Abteilung gemanagt? Für wie viele extern erreichbare IT-Komponenten finden regelmäßige Überprüfungen der IT-Sicherheit statt? Eine Sammlung von 25 Metriken, die gut als Vorlage dienen können, finden Sie im Umsetzungsplan der Leitlinie für die Informationssicherheit in der öffentlichen Verwaltung [ITPR20]. Das Grundsatzpapier der Rechnungshöfe des Bundes und der Länder zum Informationssicherheitsmanagement [RHBL20] enthält ebenso einen umfangreichen Fragenkatalog. Und auch aus Formularen zu Meldepflichten (siehe Kapitel 15) lassen sich Metriken ableiten.

Angriffserkennungssysteme Ein Unternehmen will erkennen, wenn es einen erfolgreichen Angriff gegen das Unternehmen gegeben hat. Im Idealfall wird ein Angriff sogar schon erkannt, noch während er erfolgt. Typischerweise setzt man hierzu Angriffserkennungssysteme (Intrusion Detection Systems, IDS) ein. Wie Sie in Kapitel 6 gesehen haben, wird deren Einsatz in Zukunft in einigen Branchen gesetzlich vorgeschrieben. Ab 1. Mai 2023 müssen Betreiber kritischer Infrastrukturen ein Angriffserkennungssystem einsetzen (§ 8a Abs. 1a BSI-Gesetz). Und schon ab 1. Dezember 2022 sollen (wenn ein erhöhtes Gefährdungspotenzial besteht: müssen) Betreiber öffentlicher

Telekommunikationsnetze und Anbieter öffentlich zugänglicher Telekommunikationsdienste dies umsetzen (§ 165 Abs. 3 TKG). Der Gesetzgeber hat dabei Angriffserkennungssysteme folgendermaßen definiert: »Systeme zur Angriffserkennung im Sinne dieses Gesetzes sind durch technische Werkzeuge und organisatorische Einbindung unterstützte Prozesse zur Erkennung von Angriffen auf informationstechnische Systeme. Die Angriffserkennung erfolgt dabei durch Abgleich der in einem informationstechnischen System verarbeiteten Daten mit Informationen und technischen Mustern, die auf Angriffe hindeuten« (§ 2 Abs. 9b BSI-Gesetz). »Die eingesetzten Systeme zur Angriffserkennung müssen in der Lage sein, durch kontinuierliche und automatische Erfassung und Auswertung Gefahren oder Bedrohungen zu erkennen. Sie sollen zudem in der Lage sein, erkannte Gefahren oder Bedrohungen abzuwenden und für eingetretene Störungen geeignete Beseitigungsmaßnahmen vorsehen« (§ 165 Abs. 3 TKG). Die Abwehr der Angriffe ist dann schon Aufgabe eines »Intrusion Prevention Systems« (IPS). Der Betrieb eines IPS ist nicht unkritisch, da es immer auch Potenzial zu Denial-of-Service-Angriffen bietet. Ein Unternehmen kämpft mit zahlreichen Login-Versuchen durch Unberechtigte auf einem wichtigen Linux-Server. Deshalb wird ein einfaches Intrusion Prevention System (konkret: fail2ban) eingesetzt. Nach mehr als drei Eingaben eines ungültigen Passworts innerhalb von vier Minuten wird die IP-Adresse, von der die Versuche erfolgten, für 24 Stunden gesperrt. Daraufhin häufen sich die Anrufe von Nutzerinnen beim Helpdesk, die sich selbst durch Tippfehler bei der Passworteingabe ausgesperrt haben. Als der Angreifer den Einsatz des IPS erkennt, nutzt er systematisch Fehleingaben von Passwörtern, um den Login von möglichst vielen IP-Adressen zu blockieren. Noch kritischer wäre es, wenn nach drei Fehlversuchen in kurzer Zeit das Nutzerkonto für 24 Stunden gesperrt würde. Dann könnte ein Angreifer systematisch alle Konten sperren!

Bei einem IPS müssen Sie immer auch über die Nebenwirkungen und das Missbrauchspotenzial nachdenken. Angriffserkennungssysteme (Intrusion Detection Systems, IDS) funktionieren nach zwei grundsätzlichen Verfahren: netzwerkbasierte Angriffserkennungssysteme: signaturbasierte Erkennung, anomaliebasierte Erkennung; hostbasierte Angriffserkennungssysteme. Mit beiden Paradigmen werden wir uns in der Folge beschäftigen.

Angriffserkennungssysteme (netzwerkbasiert) Bei der netzwerkbasierten Erkennung lauscht ein Sensor am Netzwerkkabel und untersucht den Netzwerkverkehr auf verdächtige Pakete, die auf einen Angriff hindeuten. Das können Sie sich ähnlich einem klassischen Virenscanner vorstellen, der die Zugriffe auf Dateien im Betriebssystem überwacht und dabei in den Dateien nach Anzeichen (Signaturen) von Viren sucht. Nur wird hier der Netzwerkverkehr beobachtet. Sobald ein Angriffsmuster im Netzwerkverkehr erkannt wird, gibt es einen Alarm. Gleichzeitig müssen die Datenpakete der verdächtigen Verbindung gespeichert werden, um sie weiter analysieren zu können. Ähnlich wie bei einem Virenscanner müssen die Musterdatenbanken ständig aktualisiert werden. Für den Erfolg der Angriffserkennung ist es wesentlich, an welchen Stellen im Netzwerk die Sensoren platziert werden. Einerseits sollten die Sensoren möglichst zentral stehen, anderseits muss das Volumen des Netzwerkverkehrs an der Stelle für den Sensor verarbeitbar sein. Der Sensor filtert den normalen Datenverkehr heraus und reicht nur besonderen Datenverkehr an das Analysesystem weiter. Ist das Netzwerk segmentiert, sollte in jedem Segment ein Sensor stecken. Neben verdächtigen Mustern können Sie bei einem Angriffserkennungssystem auch Regeln definieren. Über solche anpassbaren Regeln und Erkennungsmuster können Sie Ihr System an

Ihre Bedürfnisse anpassen. Wenn Sie aus dem Austausch innerhalb Ihrer Branche Informationen über einen Angriff erhalten, bei dem zum Beispiel Daten von einem bestimmten Server heruntergeladen wurden, können Sie Ihrem System sofort eine neue Regel geben, die nach Kommunikation zu diesem Server sucht. Bei einer anomaliebasierten Erkennung hat das System die Muster des »normalen« Netzwerkverkehrs gelernt und es reagiert auf Abweichungen von diesem Muster. Typische Muster, die dabei ausgewertet werden, sind: ungewöhnliche Datenvolumina zwischen Rechnern, Kommunikation zwischen Geräten, die sonst nicht kommunizieren, Netzwerk-Protokolle, die in der Kommunikation bisher nicht aufgetaucht sind, Datenverkehr zu ungewöhnlichen Zeiten. Es ist ein ständiges Feintuning erforderlich, um die Anomalieerkennung an sich ändernde Anforderungen und geänderten Netzwerkverkehr anzupassen. Dabei spielt es keine Rolle, ob Rechner ein ungewöhnliches Kommunikationsverhalten intern oder nach extern zeigen. Wenn ein Rechner zum Beispiel etwa 10–20 % des Datenverkehrs per UDP macht und den Rest per TCP, dann können Sie das als normal für diesen Rechner definieren. Zeigt dieser Rechner aber plötzlich 35 % UDP und nimmt auch das Datenvolumen entsprechend zu, dann sollten Sie den Grund dafür herausfinden. Wenn ein Desktoprechner, der immer nur zwischen 9:00 Uhr und 17:00 Uhr Datenverkehr gezeigt hat, plötzlich zwischen 1:00 Uhr und 3:00 Uhr aktiv wird, dann ist das auch erst einmal ziemlich verdächtig. Ein Angriffserkennungssystem kann diese Anomalie allerdings nur berichten. Ihre Mitarbeiter müssen dem nachgehen und entscheiden, ob das ein Angriff ist oder war. Suricata und Snort sind bekannte Open-SourceAngriffserkennungssysteme (Sensoren). Die Darstellung und Auswertung der Daten müssen in weiteren Systemen erfolgen. Viele

Hersteller bieten eine Testmöglichkeit für 30 Tage an. Das ist für einen ernstzunehmenden Test eine zu kurze Zeit. Open-Source-Systeme sind meist frei verfügbar und die Erkennungsdatenbanken gibt es in zwei Versionen: eine kostenlose Community- oder Basisversion und eine kostenpflichtige Enterprise-Version. Machen Sie Ihre ersten Gehversuche mit der Community-Version und steigen Sie später auf »Enterprise« um.

Angriffserkennungssysteme (hostbasiert) Hostbasierte Erkennungssysteme sammeln die diversen Protokolldateien auf Ihren Rechnern ein, korrelieren die Ereignisse und werten sie aus. Der Nachteil gegenüber einem netzwerkbasierten Einbruchserkennungssystem ist, dass ein Angriff in den Protokolldateien immer erst dann sichtbar wird, wenn er bereits stattgefunden hat, während ein netzwerkbasiertes IDS den Angriff quasi live verfolgt. Protokolldateien müssen daher auf jeden Fall zeitnah ausgewertet werden. Dies sollte außerdem automatisiert erfolgen. Wenn Sie Protokolldateien manuell auswerten, sehen Sie unter Umständen zufällig Einträge, nach denen Sie überhaupt nicht gesucht haben (Zufallsfunde). Um derartige Zufallsfunde – auch aus Datenschutzgründen – zu vermeiden, darf zum Beispiel das BSI im Regierungsnetz Protokolldateien nur automatisiert auswerten (§ 5 Abs. 1 BSI-Gesetz). Diese Vorgabe für das BSI ist im Sinne einer »Good Practice« auch eine Empfehlung für Unternehmen. Wenn Sie mit Administratoren über potenziell kritische Protokolldateien sprechen, hören Sie oft die Antwort: »Die Protokolldatei ist sowieso harmlos, da schaue ich nie rein«. Protokolldateien, die nicht ausgewertet werden, können abgeschaltet werden. Abbildung 24.2 zeigt die Anzahl von SSH-Anmeldeversuchen der Nutzerin pi auf einem Linux-Server. Dies ist die Default-Nutzerin auf dem Bastelrechner Raspberry Pi. Drei Ereignisse (Peaks) fallen auf, wurden aber nicht zeitnah bemerkt und verfolgt. Ab Juni 2017 sehen Sie ein erhöhtes dauerhaftes Aufkommen von fehlerhaften Anmeldungen für die Nutzerin pi. Das ist das Auftreten eines speziellen Virus auf dem Raspberry-Pi-Rechner. Die Aktivitäten des Virus sind Ende 2021 immer noch feststellbar.

Abbildung 24.2: Die fehlgeschlagenen SSH-Anmeldeversuche mit der Nutzerin pi auf einem Unix-Server über einen Zeitraum von fünf Jahren. [Ger19]

Das gezeigte Beispiel war – zumindest soweit es den Virus betrifft – eher keine Bedrohung für den Linux-Server. In einer Schule, in der eine größere Anzahl von Raspberry Pis im Informatikunterricht eingesetzt werden, wäre die Bedrohungslage hingegen eine andere gewesen. Sie werden mit einem Angriffserkennungssystem in der Anfangszeit immer einige Probleme mit der Optimierung haben. Das Hauptproblem ist die schnelle Erkennung von False Positves, denn Sie wollen ja auch keinen echten Alarm übersehen. Für diese Aufgabe benötigen Sie erfahrene Spezialisten, von denen es leider auf dem Arbeitsmarkt nicht die nötige Anzahl gibt.

Managed Security Wenn Sie den Betrieb eines Angriffserkennungssystems personell nicht stemmen können, denken Sie über einen Managed-Security-Dienstleister nach. Der betreibt Ihre IT-Sicherheitssysteme und unterstützt Sie bei Ihren IT-Sicherheitsaufgaben: Betrieb des Security Operation Centers (SOC),

Betrieb des Angriffserkennungssystems, Überprüfung der Systeme auf Schwachstellen (Schwachstellenscan), Monitoring der IT-Systeme, zum Beispiel Patch-Status, »Feuerwehr« bei IT-Sicherheitsvorfällen (Notfallteam), Wahrnehmung der CERT-Aufgaben, Management von Sicherheits-Hard- und Software (zum Beispiel Firewalls), Beratung und Schulung zu Fragen der IT-Sicherheit. Der große Vorteil eines Managed-Security-Dienstleisters sind die zu erzielenden Synergieeffekte. Wird bei einem Kunden des Dienstleisters ein Angriff erkannt, kann dieses Wissen in kürzester Zeit bei den anderen Kunden zur Abwehr von Angriffen genutzt werden. Dieser wichtige Aspekt, das Information Sharing, darf in der IT-Sicherheit nicht unterschätzt werden. Ein solcher Dienstleister hat auch für alle wichtigen Rollen Stellvertreter, sodass er mit Urlaub und Ausfall seiner Beschäftigen besser umgehen kann. Für ein mittelständiges Unternehmen ist das Auslagern dieser wichtigen Dienste eine echte Alternative. Ein so breit gestreutes Fachwissen können Mittelständler typischerweise nicht vorhalten; schließlich ist die IT und insbesondere die IT-Sicherheit für die meisten dieser Unternehmen nicht das Kerngeschäft.

Schadsoftware Es gibt im Wesentlichen drei Haupteinfallstore für Schadsoftware: per E-Mail, über eine Webseite (Drive-by-Download oder direkter Download) oder über vom Internet erreichbare Systeme mit Sicherheitslücken.

Weitere Einfallstore sind denkbar, stellen aber nicht das Massengeschäft dar. In den vergangenen Jahren war sogenannte Ransomware eine der großen Bedrohungen für IT-Nutzerinnen und Unternehmen. Eine entsprechende Schadsoftware nimmt sensible Daten als Geisel, indem die Daten unbefugt verschlüsselt werden, und erpresst so ein Lösegeld. Es wird versprochen, dass man den Schlüssel zum Entschlüsseln nach erfolgter Zahlung erhält. Wir müssen also auf die Versprechen der Kriminellen vertrauen, wenn wir das Lösegeld bezahlen würden. Sicherheitsbehörden raten von Lösegeldzahlungen ab. Die Schadsoftware ist mittlerweile meist so ausgereift, dass ein Brechen der Verschlüsselung mit vertretbarem Aufwand nicht mehr möglich ist. Deshalb muss mit Abwehrmethoden möglichst versucht werden, eine Infektion mit derartiger Schadsoftware zu vermeiden. Falls es Sie doch erwischt, hilft nur noch eine Schutzmaßnahme: eine funktionierende Datensicherung (siehe Kapitel 20). Wenn Sie die Pressemeldungen über Ransomware-Vorfälle verfolgen, fällt auf, dass zahlreiche Unternehmen und Behörden auch lange nach dem Vorfall noch unter den Auswirkungen leiden. Dies scheint ein Indiz dafür zu sein, dass die Bedeutung einer Datensicherung unterschätzt wird. Wenn Sie eine Datensicherung besitzen, müssen Sie natürlich verifizieren, dass die Datensicherung frei von Schadsoftware ist. Wenn der Infektionszeitpunkt länger zurückliegt als die letzte Datensicherung, dann haben Sie ein Problem. Bei Angriffen mit Schadsoftware müssen wir zwischen dem Massengeschäft und gezielten Angriffen unterscheiden. Eine Ransomware ist ein kriminelles Massengeschäft, wobei sich das »Geschäftsmodell« in letzter Zeit geändert hat. Vor einigen Jahren wurden die Daten verschlüsselt und als Geisel genommen, um ein Lösegeld zu erpressen. Mittlerweile werden die Daten vor der Verschlüsselung kopiert. Wenn das Opfer nicht bereit ist, das Lösegeld zu zahlen, wird mit der Veröffentlichung der entwendeten Daten gedroht. Das ist eine neue Qualität von Bedrohung.

Gezielte Angriffe sind sehr viel schwieriger abzuwehren. Für den Angreifer sind sie in der Konzeption auch deutlich aufwendiger. Er muss sich gezielt mit der Situation des Opfers vertraut machen und seinen Angriff darauf abstellen. Bekannte Angriffe sind zum Beispiel der Angriff gegen die Mail-Server der Demokratischen Partei im Präsidentschaftswahlkampf 2016 in den USA, um mit den erbeuteten Daten die Kandidatin Hillary Clinton zu diskreditieren – oder auch der Angriff gegen das Meldesystem ADAMS der World Anti-Doping Agency (WADA) im Jahr 2016, bei dem vertrauliche Daten der Athleten veröffentlicht wurden. Beide Angriffe werden einer russischen Hackergruppe zugeschrieben, die unter dem Namen APT28 oder Fancy Bear bekannt ist.

Abwehrstrategien Die beiden ersten Einfallstore, E-Mail und Websurfen, können Sie durch heuristische Filtermechanismen überwiegend in den Griff bekommen. EMail kann man auf dem Mail-Server gut filtern und den Web-Download kann man über einen filternden Proxy leiten. Dabei werden ausführbare Dateien blockiert oder per Virenscanner analysiert und nur durchgelassen, wenn sie keine Schadsoftware enthalten. Eine weitere Möglichkeit ist eine Isolierung des Webbrowsers von Ihrem Betriebssystem. Dafür gibt es zwei Möglichkeiten: Remotebrowser: Sie nutzen zum Surfen einen Browser auf einem anderen virtuellen Rechner, der in der Regel abgeschottet unter Linux läuft. Sie haben Zugriff über eine Remotedesktopverbindung (zum Beispiel über VNC). Damit sehen Sie lokal auf Ihrem Rechner nur ein Bild des Browsers. Sie können Dateien herunterladen, diese landen jedoch nicht auf Ihrem Rechner. Jedes Mal, wenn Sie die Verbindung zum Remotebrowser beenden, wird der virtuelle Rechner in den Standardzustand zurückgesetzt. Jedes Mal, wenn Sie mit dem Surfen beginnen, haben Sie also einen frischen Rechner vor sich. Isolierter Browser: Der Browser läuft zwar lokal auf Ihrem Rechner, wird aber durch lokale Virtualisierung vom Betriebssystem isoliert.

Unter Windows gibt es dafür den »Microsoft Defender Application Guard« für den Edge-Browser. Damit können interne und externe Webseiten unterschieden werden. Externe Webseiten werden isoliert, interne nicht. Andere Lösung für Windows wären zum Beispiel Sandboxie oder der »Browser in the Box« von Rhode & Schwarz.

Für einfache Tests enthält Windows 10/11 auch eine einfache Windows Sandbox, die es erlaubt, Software zu testen, ohne gleich das eigentliche Betriebssystem zu gefährden. Die Windows Sandbox ist jedoch nicht dafür gedacht, auf sichere Art Schadsoftware zu untersuchen. Viele Angriffe – gerade über E-Mail – installieren zuerst eine Softwarekomponente (Downloader, Dropper), die erst die eigentliche Schadsoftware nachlädt. Beim Nachladen wird eine Adresse mit einem Domain-Namen verwendet. Dies gibt die Möglichkeit, den Nachladevorgang auf dem eigenen DNS-Server zu blockieren. Dazu benötigten wir »lediglich« eine Liste verbotener Domain-Namen. Da Dienstleister, die derartige Listen zur Verfügung stellen, sehr schnell reagieren, ist dies ein effektiver Weg zur Blockade von Schadsoftware.

Analyse von Schadsoftware Die Analyse von Schadsoftware, um zu verstehen, was die Schadsoftware macht, sollten Experten durchführen, da dafür sehr viel technisches Wissen erforderlich ist. Die IT-Sicherheit im Unternehmen sollte allenfalls, wenn das nötige Fachwissen vorhanden ist, erste Voranalysen machen. Es ist natürlich trotzdem sinnvoll, eine Vorstellung haben, wie dort gearbeitet wird.

Ein Beschäftigter leitet der IT-Sicherheit eine Mail weiter, da ihm die PDF-Datei im Anhang komisch vorkommt. Die erste Möglichkeit wäre es, die Datei beispielsweise nach VirusTotal hochzuladen, um eine Einschätzung zu erhalten. Da Sie zu diesem Zeitpunkt noch nicht wissen, welchen Inhalt die PDF-Datei hat, ist das riskant, denn es könnten personenbezogene Daten enthalten sein. Da eine PDF-Datei ausführbaren Code enthält, wenn eine Schadsoftware enthalten ist, reicht es, mit spezieller Software in die Datei zu schauen, ob ausführbarer Code (in der Regel JavaScript) enthalten ist. Wenn nein, ist die Wahrscheinlichkeit einer Schadfunktion gering. Wenn ausführbarer Code enthalten ist, startet die weitere Analyse durch einen Experten. Kommen Sie nach der ersten Prüfung zu der Erkenntnis, dass die Datei wahrscheinlich harmlos ist, können Sie die Datei mit einem PDF-Anzeige-Programm unter Linux anschauen. Manchmal enthält eine PDF-Datei auch nur einen Link zur einer Schadsoftware, auf den die Beschäftige klicken soll (das ist Phishing). Die erste Entscheidung, also verdächtig oder unverdächtig, kann mit einfachen Mitteln im Unternehmen durch die IT-Sicherheit oder die IT getroffen werden. Alle weiteren Untersuchungen sollten nur durch Experten durchgeführt werden, die sie in KMU meist nicht haben. Wenn Sie eine Datei mit Schadsoftware, zum Beispiel eine WordDatei mit einem Makrovirus, erhalten haben, müssen Sie diese Datei sehr vorsichtig behandeln. Unter Windows kann eine kleine Unachtsamkeit, wie ein versehentlicher Klick auf die Datei, bereits die verhängnisvollen Aktivitäten der Schadsoftware aktivieren. Deshalb hat es sich eingebürgert, verdächtige Dateien in eine passwortgeschützte ZIP-Datei einzupacken. Als Standardpasswort wird »infected« verwendet. Viele Softwarewerkzeuge zur Analyse

von Schadsoftware können dann direkt die ZIP-Datei öffnen, ohne dass sie die Schadsoftware erst auspacken müssen. Da Schadsoftware überwiegend für Windows-Systeme erstellt wird, sollte die Analyse einer Schadsoftware nicht unter Windows erfolgen. Linux-Systeme haben sich da bewährt, da Windows-Viren dort keinen Schaden anrichten können. Für den Einstieg und für einfache Untersuchungen ist schon ein Raspberry Pi völlig ausreichend. Wenn ein Experte sich nicht nur auf sein Bauchgefühl verlassen will, benötigt er einige Tools, um risikolos die »Innereien« einer verdächtigen Datei anzuschauen. Zur Untersuchung von PDF-Dateien sind die PDF-Tools von Didier Stevens [Ste] hervorragend geeignet. Diese Kommandozeilen-Tools können direkt mit passwortgeschützten ZIP-Dateien (Passwort: infected) umgehen. Damit kann ein Experte leicht herausfinden, ob eine PDF ein Autostartprogramm enthält und er kann dann gegebenenfalls auch das Autostartprogramm herauskopieren. Ob das Autostartprogramm harmlos oder gefährlich ist, müsste er entscheiden, wozu er das Programm verstehen müsste, was gute Programmierkenntnisse voraussetzt. Wenn kein Autostartprogramm enthalten ist, ist die PDF-Datei mit sehr hoher Wahrscheinlichkeit harmlos. Das ist ja auch schon eine wichtige erste Erkenntnis. Microsoft-Office-Dateien lassen sich leicht untersuchen, da es sich bei Ihnen eigentlich um einfache zip-Dateien handelt. Sie müssen die Endung der Office-Datei nur in .zip umbenennen. Dann können Sie den Inhalt auspacken und untersuchen. Wenn Sie Programmcode finden, müssen Sie diesen allerdings – wie bei den PDF-Dateien – selber verstehen. Der nächste Schritt in der Analysekette wäre das tatsächliche Ausführen einer verdächtigen Datei in einer kontrollierten Umgebung. Das frei verfügbare Standardprogramm dafür ist die »cuckoo Sandbox« (https://cuckoosandbox.org). Diese wird unter Linux installiert. Die »cuckoo Sandbox« kontrolliert dann zum Beispiel ein Windows, das in

einer virtuellen Maschine läuft, und beobachtet dabei das zu testende Programm. Danach erhält der Analyst einen in der Regel sehr umfangreichen Bericht über alle Feststellungen, den er wieder interpretieren muss. Da die Virenautoren natürlich die »cuckoo Sandbox« auch kennen, versucht ein aktueller Virus häufig zu erkennen, ob er gerade unter der Kontrolle der »cuckoo Sandbox« ausgeführt wird. Wenn ja, verhält er sich unverdächtig. Das ist ein gewisses Katz-undMaus-Spiel. Die Unternehmen, die Antivirensoftware herstellen, nutzen vergleichbare Techniken zur automatisierten Malware-Analyse. Diese nutzen allerdings nicht die cuckoo Sandbox, sondern haben dafür ihre eigenen Programme. Die cuckoo Sandbox ist ein absolutes Profi-Tool. Es ist sehr mächtig, aber auch aufwendig zu betreiben und die Interpretation der Reports verlangt erhebliches Fachwissen. Sehr beliebt für eine schnelle Virenanalyse ist die Webseite https://www.virustotal.com. Dieser Dienst, der von Google betrieben wird, lässt jede hochgeladene Datei von etwa 50 Virenscannern prüfen und zeigt das Ergebnis an. Doch Vorsicht! Virustotal ist eine sogenannte Sharing Community, das heißt jede Datei, die Sie hochladen, wird an die Community verteilt. Hersteller von Antivirensoftware und Sicherheitsbehörden, aber eben auch Virenautoren erhalten Ihre Datei. Wollen Sie, dass ein Ihnen unbekannter Kreis von Teilnehmern Ihre hochgeladene Datei sieht? Enthält die Datei personenbezogene oder andere sensible Daten, darf sie auf keinen Fall hochgeladen werden. Denn wenn Sie bei Virustotal ein entsprechendes kostenpflichtiges Abonnement abschließen, erhalten Sie – zusätzlich zu der hochgeladenen Datei – weitere Informationen, unter anderem die Stadt, aus der die Datei hochgeladen wurde. Eine Möglichkeit ist es hier, nur den Hashwert (MD5, SHA1 oder SHA256) der zu prüfenden Datei hochzuladen. Wenn die Datei schon mal hochgeladen wurde, erhalten Sie das Ergebnis.

Ansonsten gehen Sie natürlich leer aus. Die angezeigten Ergebnisse müssen Sie aber so oder so mit Fachkunde interpretieren. Insofern ist Virustotal durchaus ein hilfreicher Dienst, mit dem Sie aber sehr verantwortungsvoll umgehen müssen.

Kapitel 25

Patch Management IN DIESEM KAPITEL lernen Sie, wie Sie Software aktuell halten … … und warum aktuelle Software wichtig ist

Es gibt keine fehlerfreie Software. Diesen Satz müssen Sie sich als ITVerantwortliche unbedingt zu eigen machen. Die Konsequenz daraus ist, dass Fehler in der Software, sobald Sie gefunden werden, behoben werden müssen. Und das bedeutet für Sie Arbeit, weil Sie die korrigierte Software auf Ihrem System installieren müssen. Das ist eine ständige und regelmäßig wiederkehrende Aufgabe. Zum Glück sind nicht alle Fehler sicherheitsrelevant – aber um die sicherheitsrelevanten Fehler müssen Sie sich ganz sicher kümmern! Wie geht man diese Problematik systematisch an?

In zahlreichen Unternehmen wird die Groupware Zimbra Collaboration Suite eingesetzt. Am 13. März 2019 wurde eine Sicherheitslücke bekannt, mit deren Hilfe über das Netz Software auf dem Server ausgeführt werden konnte (Remote Code Execution, CVE-2019-9670). Am 19. März wurde vom Hersteller ein Update, das die Lücke schloss, zur Verfügung gestellt. Damit war die Sicherheitslücke öffentlich bekannt. Um den 28. März wurden in einem Unternehmen der erste Zimbra-Server gehackt. In den folgenden Tagen wurden noch drei weitere Zimbra-Server des Unternehmens gehackt. Rund zehn oder 15 Tage (je nachdem, ab welchem Datum Sie zählen) benötigten die Angreifer, um einen erfolgreichen Angriff durchzuführen. Dieses Beispiel zeigt eindrucksvoll, was die Aussage »Sicherheitsupdates müssen zeitnah eingespielt werden« wirklich bedeutet. Sie müssen wissen, welche Software in Ihrem Unternehmen eingesetzt wird. Besonders kritisch ist alle Software, die direkten Kontakt zum Internet hat. Dabei ist es egal, ob diese Software aus dem Internet erreichbar ist, zum Beispiel Software auf Servern, oder ob von der Software das Internet erreichbar ist, zum Beispiel Software auf Clients. Durch eine Segmentierung des Netzes (siehe Kapitel 21) oder geeignete Firewallregeln (siehe Kapitel 22) können Sie die Software minimieren, die Kontakt zum Internet hat. Das heißt nicht, dass Sie sich um die übrige Software nicht kümmern müssen, aber die Priorität des Kümmerns wird reduziert. Bei den Servern, die aus dem Internet zu erreichen sind, müssen das Betriebssystem und alle Software, die aus dem Internet erreichbare Dienste anbietet (zum Beispiel Mailservice, DNS, Webservice, Datenbankservice), stets aktuell gehalten werden. Auf den Clients müssen das Betriebssystem, die Antivirensoftware, der Webbrowser, das Mailprogramm und alle Programme, die Dateien verarbeiten, die aus dem Internet kommen, entsprechend permanent

aktuell sein. Zu letzteren gehören zum Beispiel die OfficeProgramme und die PDF-Anzeigeprogramme. Wenn Sie die Liste der Software erstellt haben, die Sie mit höchster Priorität aktuell halten müssen, benötigen Sie Informationen über die aktuellen Sicherheitsupdates (Security Patches). Die meisten Anbieter haben eine Mailingliste oder eine Webseite, über die die Updates angekündigt werden. Wenn Sie mit einem CERT zusammenarbeiten, bietet Ihnen vielleicht auch Ihr CERT eine herstellerübergreifende Mailingliste als Dienstleistung an. Das CERT Bund (https://www.cert-bund.de) bietet einen öffentlichen Warn- und Informationsdienst für Schwachstellen an. Dieser Dienst kann nach einer Registrierung angepasst und genutzt werden. Sie erhalten dann im Abonnement Mails mit an Ihre Anforderungen angepassten Meldungen. Die Nutzung ist kostenlos. Abbildung 25.1 zeigt, wie viele herstellerübergreifende Sicherheitsmeldungen und Updates von Sicherheitsmeldungen ein CERT (hier das DFN-CERT) pro Monat liefert. Die Anzahl wächst stetig und variiert zwischen knapp acht (1. Halbjahr 2015) und knapp 11 (2020/21) neuen Meldungen pro Arbeitstag (20 Arbeitstage pro Monat).

Abbildung 25.1: Die monatliche Zahl der Schwachstellenwarnungen und Updates der Warnungen beim DFN-CERT. (Quelle: DFN-CERT Services GmbH)

Damit Sie beim Umgang mit Sicherheitslücken keine komplizierten verbalen Umschreibungen geben müssen (»die kritische Sicherheitslücke im Windows aus dem letzten Jahr«), erhält jeder Sicherheitslücke eine eindeutige Nummer. Dazu wird die Common Vulnerability Enumeration (CVE) verwendet. Eine Nummer beginnt immer mit CVE-, dann folgen die Jahreszahl und danach eine Nummer. Dies Nummer war von 1999 bis 2014 vierstellig und ist seit 2015 fünfstellig. Die erste in 2022 registrierte Schwachstelle hat also die Nummer CVE-2022-00001. Die Reihenfolge der Nummerierung hat nichts mit der Reihenfolge der Veröffentlichung zu tun, sondern mit der Reihenfolge der Registrierung der Schwachstelle. Damit Sie beurteilen können, wie schwerwiegend eine Schwachstelle ist, gibt es das Common Vulnerability Scoring System (CVSS). Aktuell ist die Version 3.1. Damit kann jeder Schwachstelle ein Wert zwischen null und zehn zugeordnet werden. Die Klassifizierung ist dann: 0,0: keine Schwachstelle,

0,1 - 3,0: niedrig, 4,0 - 6,0: mittel, 7,0 - 8,9: hoch, 9,0 -10,0: kritisch. Der Wert für den CVSS kann aus relativ einfachen Angaben berechnet werden. Dazu ordnet man einfachen Antworten auf Fragen über die Möglichkeiten zur Ausnutzung der Schwachstelle einen numerischen Wert zu. So gibt es die Frage, ob eine Interaktion einer Nutzerin erforderlich ist. Damit ist gemeint, ob die Schadsoftware direkt ausgeführt werden kann, oder ob erst eine Nutzerin aktiv werden, also zum Beispiel einen OK-Button bestätigen muss. Keine Nutzerinteraktion bedeutet den Wert 0,85, eine erforderliche Nutzerinteraktion den Wert 0,62. Wenn die Komplexität des Angriffs niedrig ist, gibt es den Wert 0,77, bei großer Komplexität sind es 0,44. Die Werte werden in eine Formel eingesetzt, um den Score zu berechnen. Um den CVSS zu ermitteln, müssen Sie damit nur einige einfache Antworten geben. Mit der Eingabe von Zahlen haben Sie nicht zu tun. Für einige bekannte Schwachstellen sind die Werte dann SSLv3 POODLE Vulnerability (CVE-2014-3566): 3,1; OpenSSL Heartbleed Vulnerability (CVE-2014-0160): 7,5; GNU Bourne-Again Shell (Bash) »Shellshock« Vulnerability (CVE2014-6271): 9,8; Microsoft Server Remote Code Execution Vulnerability (CVE-202128480 bis -28483): 9,8; Log4j2 Remote Code Execution »Log4Shell« (CVE-2021-44228): 10,0. Der CVSS gibt Ihnen eine Orientierung, wie dringend Sie sich um die Schwachstelle kümmern müssen. Ein wichtiger Punkt beim Einspielen von Sicherheitsupdates ist das Testen. Es kommt immer mal wieder vor, dass ein Sicherheitsupdate mit

Ihrer speziellen Konfiguration nicht funktioniert. Es ist sehr arbeitsintensiv und stressig, wenn Sie das erst nach dem Rollout auf 1000 Desktopsysteme merken. Auch wenn Sie mitbekommen, dass ein Update in einem befreundeten Unternehmen kein Problem gemacht hat, heißt das nicht, das es bei Ihnen auch gut geht. Oder haben Sie eine komplett identische technische Ausstattung in Hard- und Software? Ein spezieller Grafiktreiber, eine ungewöhnliche Umgebung zum Drucken oder ein alternativer Virenscanner – es kann viele Ursachen geben, warum es Probleme bei Ihnen gibt und bei anderen nicht. Das gründliche Testen vor dem Rollout auf der einen Seite und der schnelle Rollout kritischer Sicherheitsupdates für einen möglichst lückenlosen Schutz Ihrer Systeme auf der anderen Seite: das ist die Hohe Schule des Sicherheitsupdates. Viele Unternehmen deaktivieren automatische Updates in einer Software, um die Kontrolle über die Updates zu behalten. Automatische Updates sparen zwar viel Arbeit, verhindern aber jegliches Testen vor dem Update. Einen soliden Kompromiss bietet Microsoft mit dem Betrieb eines eigenen Updateservers (Windows Server Update Services, WSUS). Der Updateserver bekommt alle Updates von Microsoft, Sie können dann selektiv festlegen, welche davon auf Ihre Rechner ausgerollt werden. Sie können auch unterschiedliche Profile für Rechnergruppen erstellen und der IT-Abteilung andere Updates als zum Beispiel der Personalabteilung ausrollen. Unternehmen sollten automatische Updates auf jeden Fall aktiviert haben. Wenn Sie über keine eigene Softwareverteilung verfügen und Software manuell auf den Client-Rechnern installieren, dürfen Sie automatische Updates nicht deaktivieren. Kleine Unternehmen und Privatleute müssen die automatischen Updates aktiviert haben. Eine Software, die Sie immer mit automatischen Updates betreiben müssen, ist Ihre Antivirenlösung. Dort können Sie in keinem Fall auf sofortige Updates verzichten.

Kapitel 26

Zugangssicherung und Authentisierung IN DIESEM KAPITEL Sicherer Umgang mit Passwörtern Was es mit dem zweiten Faktor auf sich hat

Wie schützen wir den Zugang zu unseren digitalen Geräten? Die allgegenwärtige Lösung ist ein Passwortschutz. Und da wir uns viele Passwörter merken müssen, neigen wir dazu, auch einmal ein Passwort zu vergessen. In vielen Unternehmen erfolgt ein erheblicher Teil der Anrufe beim Helpdesk wegen vergessener Passwörter. Je nach Quelle sollen es zwischen 20 und 50 % der Anrufe sein. Besonders häufig rufen Beschäftigte am ersten Tag nach dem Urlaub mit diesem Anliegen an. Sie müssen sich also definitiv mit Passwortsicherheit und Alternativen zu Passwörtern beschäftigen.

Passwörter im Unternehmen Das Wichtigste zum Umgang mit Passwörtern ist eine Passwortrichtlinie im Unternehmen. Darin sollten zumindest die folgenden Punkte geregelt sein: Passwörter müssen geheim gehalten werden und dürfen nicht weitergegeben werden. Wann immer eine Nutzerin das Gefühl hat, jemand anderes kennt ihr Passwort, sollte sie es ändern. Auf eine Vorschrift zum regelmäßigen Ändern des Passworts (zum Beispiel alle 60 Tage) sollten Sie

verzichten. Das empfiehlt mittlerweile auch das BSI. Neue Passwörter sollten mit Listen verbotener Passwörter abgeglichen werden. Die Mindestlänge und die Komplexität (Kleinbuchstaben, Großbuchstaben, Ziffern und Sonderzeichen) müssen vorgegeben werden. Ein Passwort darf auf Datenträgern nur verschlüsselt gespeichert werden. Für jedes System muss ein eigenes Passwort genutzt werden. Dienstliche Passwörter dürfen nicht für private Dienste genutzt werden. Passwörter müssen verschlüsselt gespeichert werden. Die gängigen Betriebssysteme machen das auch. Stand der Technik bei der Speicherung von Passwörtern ist eine Einwegverschlüsselung (zum Beispiel eine Hashfunktion), die es nicht erlaubt, das Passwort zu entschlüsseln. Wenn eine Nutzerin ihr Passwort eingibt, wird das eingegebene Passwort gehasht und der Hashwert mit dem gespeicherten Hashwert verglichen. Sind beide Hashwerte gleich, war das eingegebene Passwort korrekt. Sie sehen: auch wenn der Passworthash nicht entschlüsselt werden kann, kann das Passwort geprüft werden. Wenn Sie ein Passwort einfach nur hashen, sehen Sie sofort, dass zwei Nutzerinnen das gleiche Passwort haben, da für beide der gleiche Hashwert gespeichert ist. Dieses Problem lässt sich lösen, indem eine Kombination aus einem »Salz« (salt, eine Zufallszahl) und dem Passwort gehasht wird. Da bei jeder Nutzerin ein anderes Salz genutzt wird, unterscheiden sich die Passworthashes, obwohl beide Nutzerinnen das gleiche Passwort haben. Das Wort »Salz« in diesem Zusammenhang versteht sich aus dem Englischen – das Wort hash bedeutet im Englischen auch »Hackfleisch«. Da man Hackfleisch salzt, damit es besser schmeckt, entstand der Begriff »salted Hash« für die optimierte Passwortspeicherung. Das Salz wird im Klartext mit dem gehashten Passwort gespeichert.

Außerdem können wir die Hashfunktion nicht nur einmal, sondern auch mehrfach hintereinander anwenden. Das erhöht den Rechenzeitbedarf. Das soll einen Angreifer, der das gespeicherte Passwort knacken will, aufhalten. Ein Angreifer arbeitet mit einer Liste von möglichen Passwörtern (Wörterbuchangriff) oder er probiert alle Möglichkeiten für das Passwort durch (Brute-Force-Angriff). Durch das mehrfache Hashen (Iterationen) braucht er für seinen Angriff mehr Zeit. Üblich sind heute zwischen tausend und zehn Millionen Iterationen (Empfehlung des NIST in SP 800-132). Ob Sie für das Durchprobieren Ihrer Passwortliste eine Stunde oder 100.000 Stunden (bei 100.000 Iterationen) benötigen, macht einen Unterschied. Außer »Salz« gibt es beim Abschmecken von Passwörtern auch noch »Pfeffer«. Dies ist eine längere Zufallszahl, die gemeinsam mit Salz und Nutzerpasswort gehasht wird. Der Pfeffer wird geheim gehalten und ist serverspezifisch. Mit einem hinreichend langen und geheimen Pfeffer ist ein Passworthash mit vernünftigem Aufwand nicht zu knacken. Ein aktuelles Windows 10/11 speichert ein Passwort als ungesalzenen MD4-Hash. Wenn eine Nutzerin das Passwort »Geheim« wählt, wird der Wert FA4942AF3BB92B0C5DDAA88F0C2A95A2 gespeichert. Für alle Nutzerinnen auf der Welt, die das identische Passwort haben, ergibt sich der gleiche Wert. Das ursprüngliche Unix-Verfahren zur verschlüsselten Speicherung von Passwörtern nutzt einen modifizierten DES-Algorithmus mit einem Salz. Das Passwort »Geheim« ergibt mit drei verschiedenen Werten für das Salz die Werte abzBrh1woylC6p, 12eK8FuwL7bvY oder R5EQ0fuIUuyzc. Die beiden ersten Zeichen der drei Werte sind jeweils das Salz im Klartext. Aktuelle Unix-Versionen nutzen einen gesalzenen Hash auf Basis der Hash-Funktion SHA-512. Unser Passwort »Geheim« wäre damit verschlüsselt $6$DPNhIDTN9Rwvhxgi$H9YC4UT029RfbGLGsZoei… Die »6«

zwischen den beiden ersten $-Zeichen gibt das Verfahren an und zwischen dem zweiten und dritten $-Zeichen ist das Salz. Der Rest (hier verkürzt) ist das eigentliche gehashte Passwort. Von 2013 bis 2015 gab es einen Wettbewerb für einen sicheren Passworthash. Dieser wurde nicht vom NIST, sondern von einer Gruppe von Experten durchgeführt. Dort ging »Argon2« als Sieger hervor. Das NIST gibt in SP 800-63b die folgenden Empfehlungen zur Passwortspeicherung: Zum Hashen werden die Funktionen PBKDF2 und Balloon empfohlen. Das Salz soll mindesten 32 Bit umfassen. Es sollen mindesten 10.000 Iterationen gemacht werden. Es soll ein Pfeffer von mindestens 112 Bit Länge verwendet werden. Wie speichern Sie Ihre eigenen Passwörter? In Ihrem Gehirn? Das begrenzt bei vielen Menschen die Zahl der Passwörter erheblich. Viel mehr als zehn längere und komplexe Passwörter kann sich kaum jemand merken. Daraus folgt dann oft: ein Passwort für alles. Die Mehrfachnutzung von Passwörtern ist aber überhaupt keine gute Idee. Und wenn dann auch noch die E-Mail-Adresse das Nutzerkonto ist, kann ein Angreifer sehr leicht herausfinden, wo Sie überall dieses Passwort nutzen. Über die E-Mail-Adresse ergibt sich Ihr E-MailDienstleister; das E-Mail-Passwort ist das übliche Passwort, das Sie immer verwenden. Und schon kontrolliert der Angreifer Ihr E-MailPostfach. Damit kann er sogar Ihre anderen Passwörter ändern, denn viele Unternehmen schicken einen Link zum Passwort-Reset an Ihre EMail-Adresse. Wie merken wir uns unsere Passwörter? Aufschreiben ist offenbar keine gute Idee. Was hilft, ist ein Passwortsafe, also eine Software, die – geschützt durch ein Masterpasswort – Ihre Passwörter speichert. Sie dürfen nur Ihr Masterpasswort nicht vergessen. Das BSI empfiehlt den Einsatz von Passwortsafes in Unternehmen.

Spätestens wenn Sie auf mehreren Endgeräten auf Ihre Passwörter zugreifen wollen, müssen Sie sich Gedanken über eine Synchronisierung Ihres Passwortspeichers machen. Sie fangen an, die Datenbankdatei Ihres Passwortspeichers in der Cloud zu speichern. Wenn die Verschlüsselung Ihres Passwortspeichers gut ist und Sie ein gutes Passwort verwenden, spricht nichts dagegen. Komfortabler ist die Nutzung eines Cloud-basierten Passwortspeichers. Aber Sie müssen sich noch ein paar mehr Gedanken machen. Kann ich den Dienst auch offline nutzen? Dann liegt eine Kopie der Passwortdatenbank auf Ihrem Rechner. Das sichert Ihnen den Zugang, wenn der Anbieter mal ausfällt. Ist das Programm sicher? Diese Frage ist nur sehr schwer zu beantworten, da Sie die Technik nicht selbst prüfen können. Da helfen seriöse Testberichte. Vertrauen Sie dem Anbieter? Gab es bei dem Anbieter schon Sicherheitsvorfälle? Wie ist er damit umgegangen?

Zwei-Faktor-Authentisierung Zwei-Faktor-Authentisierung (2FA) bedeutet, dass man zusätzlich zum Passwort ein weiteres Verfahren zur Anmeldung nutzt. In der Praxis sind das am häufigsten Einmalpasswörter, also eine Hard- oder Software, die ein sich regelmäßig änderndes zweites Passwort erzeugt und anzeigt oder eingibt. Wie diese Passwörter generierenden Geräte funktionieren, haben wir in Kapitel 19 gelernt. Die europäische Zahlungsdiensterichtlinie (2015/2366) aus 2015 schreibt eine »starke Kundenauthentifizierung … unter Heranziehung von mindestens zwei Elementen der Kategorien Wissen (etwas, das nur der Nutzer weiß), Besitz (etwas, das nur der Nutzer besitzt) oder Inhärenz (etwas, das der Nutzer ist)« vor (Art. 4 Nr. 30). Unter »Wissen« wird ein statisches Passwort verstanden, Besitz meint ein Gerät, das ein zusätzliches wechselndes Passwort generiert oder Kryptoverfahren nutzt und Inhärenz meint ein biometrisches Merkmal. Es gibt dabei einige 2FA-Verfahren, die wir heute nicht mehr benutzen sollten. Die gute alte TAN-Liste, die Sie vom Online-Banking kennen,

ist zu anfällig für Phishing. Es gibt Nutzerinnen, die auf »freundliche Nachfrage« alle TANs preisgeben. Das Zusenden einer SMS (smsTAN) ist auch nicht wirklich sicher, da es Angreifern schon gelungen ist, sich eine SIM-Karte mit der identischen Telefonnummer zu beschaffen. Damit erhält der Angreifer eine Kopie von jeder SMS. Üblich sind Verfahren, bei denen die TAN selber oder eine Information zum Erstellen der TAN in ein Gerät der Anwenderin übertragen und dort angezeigt wird. Für die Übertragung gibt es optische Verfahren (FlickerCode, QR-Code, Abtippen einer Zahl) oder Push-Verfahren, die die TAN über das Internet an eine App übertragen. Der Vorteil dieser Verfahren ist, dass die Bank den Empfänger und den Betrag der Zahlung in die Berechnung der TAN einbeziehen kann und damit die beliebige Verwendung der TAN unterbindet. Zur Authentisierung in Unternehmen werden überwiegend zeitbasierte (TOTP) oder ereignisbasierte (HOTP) Einmalpasswort-Generatoren genutzt. Neben den standardkonformen Lösungen gibt es auch proprietäre Lösungen, die im Wesentlichen ähnlich funktionieren. Der Vorteil einer kommerziellen Lösung ist die komplette Integration in Standardlösungen wie Active Directory oder Radius-Infrastrukturen. Die Aussage »Besitz« suggeriert, das die Nutzerin den Token zur Anzeige des Einmalpassworts bei sich haben muss, um das Einmalpasswort abzulesen. Dem ist nicht so. Es reicht, wenn die Nutzerin das Display sieht. Wenn der Token über eine Webcam jederzeit remote abgelesen werden kann, reicht das auch. Damit ist Token-Sharing möglich, was der Grundgedanke des Konzepts »Besitz« eigentlich verhindern soll. Praktisch reicht es sogar, mit jemanden zu telefonieren, der den Token in der Hand hält und das Einmalpasswort vorliest. USBToken, die als »Tastatur« das Einmalpasswort direkt in den Rechner tippen, machen ein solches Token-Sharing deutlich aufwendiger. Im Unternehmen sollten alle kritischen Anwendungen durch eine ZweiFaktor-Authentisierung abgesichert werden. Als kritisch gelten:

Administration der IT, Fernwartung (auch zum Beispiel Gebäudeleittechnik), VPN-Zugang in das Unternehmen. Selbst die Nutzung eines einfachen Authentikators, wie zum Beispiel der Google Authenticator (oder eines der zahlreichen kompatiblen Programme), erhöht die Sicherheit gegenüber statischen Passwörtern. Hier gilt allerdings ein wichtiger Grundsatz: der Authentikator darf nicht auf demselben Gerät laufen wie die Anwendung, in der Sie sich authentisieren müssen. Das heißt, der Authentikator läuft zum Beispiel auf dem Smartphone und der VPN-Client auf dem Notebook. Wen Sie eine Anwendung mit zertifikatbasierter Anmeldung benutzen, zum Beispiel Secure Shell, und zur Freigabe der Verwendung Ihres privaten Schlüssel eine PIN oder ein Passwort eingeben müssen, so ist das keine Zwei-Faktor-Authentisierung. Sie melden sich nur mit der digitalen Unterschrift an. Trotzdem ist die Anmeldung mit einem Zertifikat deutlich sicherer als die Anmeldung mit einem statischen Passwort. Außerdem liegt dann auf dem Server kein Geheimnis (Ihr gehashtes Passwort), sondern nur Ihr öffentlicher Schlüssel, und der ist, wie der Name schon sagt, öffentlich und braucht nicht vertraulich behandelt zu werden. Einige Authentikatoren (zum Beispiel der Microsoft Authenticator) bieten einen Zugriffsschutz (zum Beispiel PIN, Gesichtserkennung oder Fingerabdruck) auf die Einmalpasswörter. Diese Extrasicherheit sollten Sie nutzen.

Biometrie Bei biometrischer Authentisierung des Zugangs zu Arbeitsplatzrechner oder Smartphone und Tablet sind überwiegend Fingerabdruckscanner und Gesichtserkennung im Einsatz. Für Spezialanwendungen wie zum

Beispiel Zutritt zu kritischen Gebäudebereichen werden häufig auch IrisScanner eingesetzt. Die DS-GVO verbietet in Art. 9 Abs. 1 die Verarbeitung von »biometrischen Daten zur eindeutigen Identifizierung einer natürlichen Person«. Ausnahmen von dem Verbot sind in Art. 9 Abs. 2 geregelt. Für den Einsatz biometrischer Authentisierung ist von den Erlaubnistatbeständen nur die Einwilligung möglich. Aber gerade im Arbeitsverhältnis gibt es hohe Anforderungen an die Freiwilligkeit der Einwilligung. Insgesamt macht dies den Einsatz von Fingerabdruckscannern oder Gesichtserkennung zur Anmeldung am Rechner oder Mobilgerät oder auch für Schließsysteme oder Zeiterfassung rechtlich schwierig. Dies dürfte lediglich in Bereichen sehr hoher Sicherheit aufgrund höherwertiger Interessen (zum Beispiel Ausschluss von Gefährdung der Bevölkerung bei biologischen Sicherheitslaboren) möglich sein. Soll ein Rechner nachträglich mit biometrischen Erkennungsgeräten ausgestattet werden (zum Beispiel einer USB-Kamera zur Gesichtserkennung mit Windows Hello), muss darauf geachtet werden, dass es einen Mechanismus gibt, die Echtheit der Kamera festzustellen. Bis zum Herbst 2021 gab es keine Kommunikationsprotokolle mit solchen Geräten, die die Authentizität des USB-Geräts feststellen. Damit kann ein derartiges Gerät leicht gegen ein manipuliertes Gerät ausgetauscht werden. Das Konzept dieses Sicherheitsproblems wurde von Cyberark am Beispiel von Windows-Hello-Kameras berichtet und erhielt die Fehlernummer CVE-2021-34466. Eine Strategie für den Einsatz von biometrischer Authentifizierung sollte die folgenden Punkte berücksichtigen: dezentrale Speicherung der biometrischen Templates; Freiwilligkeit der Nutzung des biometrischen Verfahrens; Nutzung von fest eingebauten Erfassungsgeräten, keine Nachrüstung per USB-Anschluss;

Durchführung einer Datenschutzfolgenabschätzung falls erforderlich.

Single Sign-on Die Last, sich viele Passwörter merken zu müssen, kann Ihnen ein Single-Sign-on-(SSO-)System abnehmen. Sie melden sich nur noch an Ihrem Arbeitsplatzrechner oder einer speziellen Software an und alle anderen Anmeldungen von dort aus – E-Mail-Postfach, Employee Selfservice, Intranet oder Ihre Fachanwendung – übernimmt das System. Jetzt fragen Sie sich vermutlich: »Soll ich dann überall dasselbe Passwort haben? Da habe ich doch gerade gelernt, dass ich das nicht soll!« Die Antwort: Das hängt vom System ab. Es gibt SSO-Systeme, die sorgen dafür, dass Sie überall dasselbe Passwort haben. Das ist keine gute Idee. Die besseren Systeme verwalten für Sie unterschiedliche Passwörter. Für jeden Dienst wird ein eigenes Passwort verwendet. Sie müssen diesen vielen Passwörter aber selbst gar nicht mehr kennen. Sie merken sich nur noch das Passwort Ihres Arbeitsplatzrechners. Noch bessere Systeme nutzen gar keine Passwörter mehr, sondern melden Sie passwortlos bei den Diensten an, zum Beispiel mithilfe von kryptografischen Verfahren. SSO verbessert den Komfort für die Beschäftigten, da sie sich nur noch ein Passwort merken müssen, und erhöht gleichzeitig die Sicherheit. Wenn die Beschäftigten ihr E-Mail-Passwort gar nicht kennen, können Sie sich auch nicht von Ihrem privaten Rechner aus an dem WebmailSystem des Unternehmens anmelden. Wenn Sie Programme benutzen, die nicht jedes Mal nach dem zweiten Faktor fragen können, können diese über spezielle Dienstepasswörter genutzt werden. Sie dürfen allerdings SSO nicht mit einem Identitäts-Provider verwechseln. Dieser bestätigt Ihre Identität und ob Sie Ihr Passwort korrekt eingegeben haben. Google und Facebook, aber auch europäische Organisationen wie netID agieren als solche Identitäts-Provider. Sie melden sich zum Beispiel bei einem Web-Shop (Service Provider) an und nutzen dazu Ihren Benutzernamen und Ihr Passwort vom Identitäts-

Provider zur Authentifikation bei diesem. Sie müssen sich weniger Passwörter merken und der Web-Shop benötigt keine eigene Nutzerverwaltung. Der Preis für den Komfort ist, dass Ihr IdentitätsProvider mitbekommt, bei welchen Service Providern Sie sich so überall anmelden. Ein anderes Problem ist, dass die Service-Provider, die einen IdentitätsProvider nutzen, sich darauf verlassen müssen, dass der IdentitätsProvider die Identitäten seiner Kunden kennt und diese überprüft hat. Das ist sicher nicht immer gewährleistet. Ein föderiertes (das heißt mehrere Identitäts-Povider nutzendes) Identitätsmanagement betreiben die deutschen Hochschulen und Universitäten unter dem DFN-Verein. Dieses System heißt Shibboleth, ist webbasiert und stützt sich auf SAML (Security Assertion Markup Language). Das SAML-Framework erlaubt es, zwischen Service- und Identitäts-Providern Authentisierungsinformationen und Berechtigungen im XMLFormat auszutauschen. Wenn eine Nutzerin bei einem ServiceProvider einen Dienst nutzen will, wird sie zur Authentisierung an ihren Identitäts-Provider (ihre Heimathochschule) umgeleitet. Dort, das heißt bei ihrer Heimateinrichtung, gibt sie ihren Nutzernamen und ihr Passwort ein. Ist dies korrekt, übermittelt der IdentitätsProvider die echte oder eine pseudonyme Identität und die Berechtigungen an den Service-Provider. Bei den Berechtigungen wird auf klassische Rollen an der Universität – Studierende, Fakultätsmitglieder oder Beschäftige – zurückgegriffen. Gleichzeitig gibt es eine gewisse SSO-Funktionalität, da das System sich merkt, dass Sie angemeldet sind.

Kapitel 27

Anwendungssicherheit IN DIESEM KAPITEL Chatten und Mailen Sichere Videokonferenzen Sichere Webanwendungen Blockchain Künstliche Intelligenz

Unterschiedliche Anwendungen stellen unterschiedliche Anforderungen an die Informationssicherheit. Werden Daten ausgetauscht, muss die Kommunikation sicher ablaufen. Werden Daten gespeichert, müssen die Daten auf dem Datenträger geschützt werden. Neue technologische Entwicklungen stellen die Informationssicherheit vor immer wieder neue Herausforderungen. Schauen wir uns im Folgenden einige wichtige Anwendungen hinsichtlich ihrer Sicherheitsanforderungen an.

Chat Wenn ein Chat-Programm »nur« eine Transportverschlüsselung benutzt, liegen alle Inhalte auf dem zentralen Server vor und können dort mitgelesen werden. Und da Chat-Programme eine asynchrone Kommunikation unterstützen, laufen fast alle diese Dienste über zentrale Server. Da die Kommunikation beim Chatten potenziell asynchron erfolgt, ein Diffie-Hellman-(DH-)Protokoll aber synchrone Kommunikation voraussetzt, muss der Server die Schlüsselvereinbarung unterstützen. Erschwerend kommt hinzu, dass eine Nutzerin mehrere Geräte besitzen

kann und einerseits die Nachrichten zwischen den Geräten synchronisiert werden müssen und andererseits eine Kommunikation von jedem der Geräte geführt werden können muss. Bei ChatProgrammen muss außerdem noch zwischen einem Chat zwischen zwei Personen und einem Chat zwischen mehreren Personen unterschieden werden. Ein von zahlreichen Anbietern genutztes Protokoll zur Vereinbarung von Schlüsseln und zur E2E-Verschlüsselung ist Signal. Es wird außer von der namensgebenden App Signal zum Beispiel auch von WhatsApp, Facebook Messenger, Google Messages und Skype genutzt. Alle Nutzerinnen haben ein Schlüsselpaar zum Nachweis ihrer Identität und um Man-in-the-Middle-Angriffe zu verhindern. Dieser Schlüssel muss verifiziert werden, was meist über den persönlichen Austausch von Codes geschieht. Da der Diffie-Hellman-Schlüsselaustausch anfällig für Man-in-the Middle-Angriffe ist, werden die DH-Schlüssel damit signiert. Damit die DH-Schlüsselvereinbarung auch asynchron beginnen kann, legt jede Nutzerin mehrere öffentliche DH-Schlüssel auf dem Chatserver ab. Wenn Alice mit Bob chatten will, holt sie sich einen von Bobs öffentlichen DH-Schlüssel vom Server und berechnet daraus einen symmetrischen Nachrichtenschlüssel, mit dem sie die Nachricht an Bob verschlüsselt. Zusammen mit der Nachricht sendet Alice ihren öffentlichen DH-Schlüssel, sodass Bob auch den Nachrichtenschlüssel berechnen kann. Nach der ersten Schlüsselvereinbarung kann die Kommunikation verschlüsselt werden. Während des Austauschs der Nachrichten werden die Schlüssel ständig fortgeschrieben (das heißt verändert), damit ein kompromittierter Schlüssel nicht alle Nachrichten entschlüsseln kann. Bei Gruppennachrichten gibt es zwei grundlegende Verfahren: Will Alice eine Nachricht an die Gruppe schicken, vereinbart sie mit jedem Gruppenmitglied einen individuellen Nachrichtenschlüssel und schickt entsprechend eine Gruppennachricht als individuelle Nachricht an alle Gruppenmitglieder.

Jedes Gruppenmitglied hat einen symmetrischen Schlüssel, den es zu Beginn eines Gruppenchats an alle Gruppenmitglieder schickt (Sender Key). Jeder Absender muss damit eine Nachricht nur einmal mit seinem symmetrischen Schlüssel verschlüsseln. Jedes Gruppenmitglied hat die Nachrichtenschlüssel aller anderen Gruppenmitglieder und kann damit die Nachrichten entschlüsseln. Da der Aufwand der Verschlüsselung bei Gruppennachrichten groß sein kann, ist die Zahl der Mitglieder einer Gruppe meist beschränkt. Auch die Langlebigkeit der Nachrichtenschlüssel in der Gruppe weicht unter Umständen von der einer individuellen Kommunikation ab. Zusätzlich kompliziert wird die Gruppenverschlüsselung durch die Tatsache, das jederzeit neue Gruppenmitglieder dazu kommen können und andere die Gruppe verlassen (oder rausgeschmissen werden). Es muss sichergestellt sein, dass jemand nach dem Verlassen der Gruppe keinen Zugriff mehr auf zukünftige Gruppennachrichten hat.

E-Mail Wir haben uns im Kapitel 23 bereits mit den kryptografischen Konzepten zur Sicherheit des E-Mail-Verkehrs gesprochen. Im Folgenden wollen wir uns anschauen, wie E-Mail-Sicherheit im Unternehmensalltag umgesetzt werden kann. Dabei ist nicht nur Verschlüsselung wichtig, sondern auch der Schutz vor Schadsoftware, denn E-Mail ist ein wichtiges Einfallstor für bösartige Programme.

Verschlüsselung Die Verschlüsselung von E-Mails wird von zahlreichen E-MailProgrammen als Standardfunktionalität angeboten. Da es zwei wesentliche Standards für die E-Mail-Verschlüsselung gibt, müssen diese getrennt betrachtet werden. Die folgenden E-Mail-Programme unterstützen E-Mail-Verschlüsselung ohne Zusatzsoftware: S/MIME: Apple Mail, Microsoft Outlook, Microsoft Mail, Mozilla Thunderbird, …

OpenPGP: Mozilla Thunderbird, … Ein besonderes Problem stellt das Lesen oder auch Schreiben verschlüsselter E-Mails in einer Webmail-Oberfläche dar. Grundvoraussetzung ist, dass die Oberfläche auf einem vertrauenswürdigen Rechner genutzt wird, denn zum Entschlüsseln oder Signieren wird der eigene private Schlüssel benötigt. Und den wollen Sie nicht auf einem nicht vertrauenswürdigen Rechner handhaben! Das Risiko, dass er dabei entwendet wird, ist zu hoch. Außerdem dürfte es auch den Vorgaben Ihres Unternehmens widersprechen, interne E-Mails auf einem nicht vertrauenswürdigen Rechner zu lesen. Derzeit gibt es für den Edge-Browser eine S/MIME-Erweiterung von Microsoft, die aber nur in Active-Directory-Umgebungen genutzt werden kann. Für den Umgang mit OpenPGP gibt es mit Mailvelope ein Plug-in für Chrome, Edge und Firefox. GMX und web.de setzen dieses Plug-in für verschlüsselte E-Mails ein. Unternehmen können den Umgang mit verschlüsselter E-Mail noch effizienter gestalten. Das Konzept dazu ist ein Verschlüsselungs-Proxy, der sich um die Verschlüsselung, Entschlüsselung und die digitalen Signaturen der E-Mails kümmert. Abbildung 27.1 zeigt die Einbindung des Proxys in die E-Mail-Infrastruktur. Der Proxy wird zwischen MailServer und Internet in die smtp-Verbindungen gehängt. Da der Proxy Zugriff auf die privaten Schlüssel der Beschäftigten hat, kann er für die Beschäftigen E-Mails entschlüsseln oder digital signieren. Die privaten Schlüssel müssen angemessen gesichert werden. Ein Crypto-Proxy unterstützt sowohl OpenPGP als auch S/MIME. Wenn es für beide Verfahren keinen öffentlichen Schlüssel eines Empfängers gibt, haben wir zwei Möglichkeiten: Entweder erhält der Empfänger Zugriff auf eine Webmail-Oberfläche zum Lesen der geschützten E-Mail oder es wird eine nach einem proprietären Verfahren verschlüsselte EMail an den Empfänger geschickt. Häufig ist das dann eine passwortgeschützte PDF-Datei. Das Passwort wird statisch konfiguriert und an den Empfänger einmalig vorab übermittelt oder es wird jedes

Mal zufällig generiert und an den Absender zur Übermittlung an den Empfänger (out of band, zum Beispiel per SMS oder Telefon) geschickt. Mit einem solchen Crypto-Proxy befinden sich nur noch entschlüsselte E-Mails in den Postfächern der Beschäftigten. Das erleichtert die Aufbewahrung (siehe Kapitel 20) des E-Mail-Verkehrs erheblich. Auch eine automatische Weiterleitung der E-Mails an eine Stellvertreterin bei Abwesenheit einer Beschäftigten ist auf diese Weise leicht möglich.

Abbildung 27.1: Ein Verschlüsselungs-Proxy übernimmt die Ver- und Entschlüsselung der E-Mails.

Allgemeine Sicherheit E-Mails sind ein Haupteinfallstor für Schadsoftware. Deshalb sollten Sie im Unternehmen auf einige grundlegende Sicherheitsmaßnahmen achten:

Auf Windows- oder macOS-Rechnern sollte eine aktuelle Antivirensoftware installiert sein. Auf dem Mail-Server des Unternehmens sollte eine Antivirensoftware jede ein- und ausgehende Mail auf Schadsoftware untersuchen. Sie sollten auf dem Mail-Server eine andere Antivirensoftware als auf dem Desktop nutzen. Administratoren berichten, dass der freie Virenscanner »ClamAV« auf einem MailServer gut einsetzbar sei. Dateianhänge, die besonders häufig Schadsoftware enthalten, sollten auf dem E-Mail-Server geblockt werden. Das sind in erster Linie Office-Dateien mit ausführbaren Inhalten (sie können »aktive Inhalte« enthalten): .doc, .xls, .ppt, .docm, .dotm, .xlsm, .xltm, .xlam, .pptm, .potm, .ppam, .ppsm, .sldm. Dazu kommen alle Arten von ausführbaren Programmen. Sollten die Dateien in gängige Formate wie .zip oder Ähnliches gepackt sein, sollten sie auch blockiert werden. Aus Sicherheitsgründen müssten auch PDF-Dateien mit aktiven Inhalten blockiert werden. Sie müssen sorgfältig prüfen, ob in Ihrer Umgebung eine derartige Sperre umsetzbar ist und gegebenenfalls darauf verzichten.

Videokonferenzen Durch die Corona-Pandemie stieg der Bedarf an Videokonferenzlösungen sowohl für Besprechungen als auch für die Lehre an. Von Grundschulen über Universitäten bis zur beruflichen Weiterbildung war Homeschooling und Online-Learning weit verbreitet. Die deutschen Datenschutzaufsichtsbehörden diskutierten intensiv die Frage der datenschutzrechtlichen Zulässigkeit von Videokonferenzlösungen US-amerikanischer Anbieter und forderten zwingend eine E2E-Verschlüsselung. Diese ist jedoch bei Videokonferenzlösungen nicht ohne Einschränkungen umzusetzen. Grundsätzlich gibt es bei Videokonferenzen drei marktübliche Kommunikationsmodelle, die sich in ihren Verschlüsselungsmöglichkeiten unterscheiden (Darstellung nach

[GGHP20]). Dabei ist das Kernproblem nicht die Verschlüsselung des Datenstroms, sondern das Schlüsselmanagement.

Multipoint Control Unit Eine Multipoint Control Unit (MCU) ist ein zentraler Server, zu dem alle Endpunkte, das heißt alle Clients, eine Verbindung aufbauen. Über diese Verbindung laufen Bild und Ton jeweils in beide Richtungen (siehe Abbildung 27.2). Bei einer telefonischen Teilnahme wird die Telefonverbindung ebenfalls an der MCU angenommen.

Abbildung 27.2: Die Kommunikationsflüsse bei einer Videokonferenz über eine zentrale MCU.

Die MCU nimmt die eingehenden Verbindungen an, konvertiert die Formate, baut das Bild auf, mischt den Ton und überträgt schließlich das

Ergebnis an alle Teilnehmer. Für die notwendige Bearbeitung der Audio- und Videodaten müssen diese unverschlüsselt auf der MCU vorliegen. Eine E2E-Verschlüsselung ist nach dem aktuellen Stand der Verschlüsselungstechnik daher nicht möglich. Eine Transportverschlüsselung zwischen Endgerät und MCU ist jedoch üblich.

Selective Forwarding Unit

Abbildung 27.3: Die Kommunikationsflüsse bei einer Videokonferenz über eine zentrale SFU.

Eine Selective Forwarding Unit (SFU) ist ebenfalls ein zentraler Server, zu dem Teilnehmer eine Verbindung aufbauen. Über diese Verbindung werden die Audio- und Videodaten in verschiedenen Auflösungen an die

SFU geschickt (siehe Abbildung 27.3). Die SFU wählt für jeden Teilnehmer die geeignete Auflösung und streamt diese zu dem jeweiligen Teilnehmer. Bei

Teilnehmern empfängt also jeder Teilnehmer im Prinzip Audio- beziehungsweise Videoströme. So werden bei einem Anzeigelayout mit einem größeren Bild des jeweiligen Sprechers und zum Beispiel sechs weiteren Teilnehmerbildern nur diese sieben Datenströme übertragen. Die SFU verarbeitet keine Bild- oder Tondaten, sondern wählt lediglich die Daten aus. Die Anforderungen an die Verbindungsbandbreite einer SFU sind deutlich höher als bei der MCU, die Verarbeitungsleistung skaliert aber deutlich besser mit der Zahl der Teilnehmer. Das Endgerät beim Teilnehmer ist für die Komposition des Bildes aus den Videoströmen zuständig. Grundsätzlich ist das Konzept einer SFU aber mit einer E2EVerschlüsselung kombinierbar.

Peer to Peer Bei einer Peer-to-Peer-(P2P-)Lösung kommunizieren alle Endgeräte direkt miteinander (siehe Abbildung 27.4). Zentrale Infrastruktur wird allenfalls noch zum Verbindungsaufbau benötigt. Die Anforderungen an die Bandbreite der Anbindung der Teilnehmer sind hier deutlich höher. Bei Teilnehmern muss jedes Endgerät den Videostream an andere Teilnehmer senden. Diese Lösung skaliert nur mit wenigen Teilnehmern sinnvoll, da die Bandbreite des Internetanschlusses eines jeden Teilnehmers der begrenzende Faktor ist. Außerdem muss die komplette Bild-und-TonVerarbeitung auf jedem Client erfolgen. P2P bietet konzeptionell die »einfachsten« Voraussetzungen für die Umsetzung einer E2EVerschlüsselung.

Abbildung 27.4: Die Kommunikationsflüsse bei einer Videokonferenz ohne eine zentrale Einheit (P2P).

Das Schlüsselmanagement läuft bei einer Videokonferenz ähnlich wie beim Chatten. Eine Videokonferenz ist zwar eine synchrone Kommunikation, aber auch diese muss mit hinzukommenden und weggehenden Teilnehmern klarkommen. Stand der Technik bei Videokonferenzen ist Ende 2021 der Einsatz von Transportverschlüsselung und E2E-Verschlüsselung bei einer 1:1Kommunikation. Alle E2E-verschlüsselten Videokonferenzen haben eine maximale Teilnehmerzahl. Mit einer E2E-Verschlüsselung gehen Funktionalitätseinschränkungen einher. Eine Telefoneinwahl und zentrale Aufzeichnungen sind dann nicht mehr möglich.

Webanwendungen Es ist Stand der Technik, den Zugriff auf Webseiten zu verschlüsseln. Dabei sollten Sie aktuell mindestens TLS 1.2 oder besser TLS 1.3 einsetzen (siehe Kapitel 23). Diese Verschlüsselung schützt die Daten beim Transport vom Webserver zum dem abrufenden Client. Außerdem können Sie über das TLS-Protokoll gewährleisten, dass der abrufende Client die Identität des Servers überprüfen kann. Was TLS nicht gewährleistet, ist die Korrektheit der übertragenen Daten. Wenn ein Angreifer Ihre Webseite austauscht (Defacement), ist dies mittels TLS nicht feststellbar. Wenn Sie nicht nur statische Webseiten ausliefern, sondern auf Ihrem Webserver auch Anwendungen laufen (zum Beispiel ein ContentManagement-System, ein Bestellsystem oder ein Buchungssystem), dann müssen Sie besondere Sorgfalt auf die eigene Programmierung und die Aktualität der benutzten Software und Bibliotheken verwenden. Schließlich steht die Software 24 Stunden am Tag und sieben Tage in der Woche jedermann im Internet für Eindringversuche zur Verfügung. Eine neu entwickelte Webanwendung muss nach ihrer Fertigstellung gründlich geprüft werden, idealerweise durch einen Penetrationstest. Automatisierte, softwarebasierte Tests gehören auch dazu. Und während der gesamten Einsatzdauer muss sichergestellt werden, dass die Software aktuell gehalten wird. Alle Programmbibliotheken von Drittherstellern müssen bei sicherheitsrelevanten Updates aktualisiert werden. Verzögerungen bei der Aktualisierung von Programmkomponenten von Drittherstellern ist eine gängige Ursache für Sicherheitslücken.

Der ElsterAuthenticator der deutschen Finanzverwaltung, die Open-Source-Software Mediathekview, der Signatursoftware Secsigner von SecCommerce oder die Volksverschlüsselung der Fraunhofer-Gesellschaft kommen alle mit einer eigenen JavaRuntime-Umgebung. Neben der eigenen Software müssen die Hersteller auch noch die Java Runtime und diverse Java Bibliotheken (SQLite Datenbank, HTTP-Tools, Kryptobibliotheken und so weiter) aktuell halten. Auch wenn es sich bei diesen Anwendungen nicht um Webanwendungen handelt, machen sie das Problem deutlich. Eine besondere potenzielle Sicherheitslücke stellen alle Eingabefenster in einer Webanwendung dar. Hier muss durch sorgfältiges Untersuchen des eingegebenen Textes sichergestellt werden, dass dieser nicht zu Fehlern bei der Verarbeitung führt. Dazu gibt es etablierte Verfahren, die müssen aber auch konsequent angewendet werden. Die Auslieferung von Webseiten kann durch Konfiguration des ausliefernden Webservers erheblich verbessert werden. Sie sollten folgende Response Header setzen: Strict-Transport-Security: max-age=31536000;

Der eingesetzte Wert für max-age entspricht einem Jahr. Er gibt die Zeitdauer an, für die ein Browser sich merkt, dass die Seite mit https aufgerufen werden muss. Mit dem Zusatz includeSubDomains gilt diese Anweisung auch für alle Subdomains. Die empfohlene Mindestzeit ist 120 Tage. includeSubDomains;

Mit der Content Security Policy wird festgelegt, von wo Ressourcen für die Webseite (Style-Files, Bilder, Skripte und so weiter) geladen werden dürfen (in diesem Beispiel nur von der Seite selbst). Content-Security-Policy: default-src 'self'

Mit dieser Option steuern Sie, ob die Seite in einem Frame angezeigt werden darf. X-Frame-Options: sameorigin

Dies ist eher eine Datenschutzoption. Hiermit wird verhindert, dass einem Link auf Ihrer Seite beim Anklicken die Information mitgegeben wird, dass der Link auf Ihrer Webseite angeklickt wurde. Referrer-Policy: no-referrer

Das hier sind nur einige wichtige Beispiele. Sie setzen diese Response Header nicht im HTML-Quellcode, sondern in der Konfigurationsdatei des Webservers. Meist können Sie die Response Header auch in der .htaccess-Datei setzen. Wenn Sie wissen wollen, welche Response Header eine Webseite ausliefert, können Sie sich das mit curl -I URL oder wget -S --spider URL ansehen, wobei »URL« durch die Adresse der Webseite ersetzt werden muss. Bei Webanwendungen sollten Sie einen Load-Balancer oder TLSReverse-Proxy vor die eigentliche Webanwendung setzen. Aus dem Internet ist die Webanwendung über den Reverse-Proxy abrufbar, und dieser »holt« sich die eigentliche Information vom Anwendungsserver. Dies erleichtert eine einheitliche TLS-Konfiguration, ohne auf Besonderheiten der Anwendungsserver Rücksicht nehmen zu müssen.

Datenbanken Sie nutzen Datenbanken üblicherweise nicht direkt, sondern indirekt über eine Anwendung. Diese Anwendung speichert dann alle Daten, das heißt auch die zum Betrieb der Anwendung erforderlichen, in der Datenbank. Benötigt die Anwendung eine Nutzerverwaltung, so werden Benutzernamen und Passwort oft ebenfalls in der Datenbank gespeichert. Hier muss darauf geachtet werden, dass die Passwörter nach dem Stand der Technik verschlüsselt werden. Aus Sicht der Datenbank ist eine Anwendung meist nur ein Nutzerkonto. Dieses Nutzerkonto hat umfangreiche Rechte. Sämtliche Zugriffsrechte der Anwendungsnutzerinnen auf die Daten in der Datenbank müssen dann durch die Anwendung verwaltet werden. Das ist ein Overhead, der zusätzlich zur Anwendungslogik programmiert werden muss.

Bei ersten Tests setzt der Programmierer eine Datenbank häufig ohne Nutzerdaten auf. Wenn dann das Testsystem langsam zum Produktionssystem mutiert, vergisst man leicht, den Datenbanknutzer und das zugehörige Passwort anzulegen. Damit steht dann die produktive Datenbank ungeschützt im Netz. Im Wintersemester 2014/15 fanden drei Studenten der Universität des Saarlandes zufällig einige MongoDB-Installationen, die ohne Passwortschutz aus dem Internet erreichbar waren. Eine systematische Untersuchung durch Wissenschaftler des Forschungszentrums CISPA förderte rund 40.000 Datenbanken ohne Passwortschutz zu Tage. Das Problem war, dass in der Anleitung für die Erstinstallation nicht deutlich genug auf die Notwendigkeit des Passwortschutzes für die Datenbank hingewiesen wurde. (https://heise.de/-2545183) Das Beispiel mit der MongoDB zeigt eine weitere Notwendigkeit: eine Datenbank sollte nicht aus dem Internet erreichbar sein. Auch wenn eine aus dem Internet erreichbare Webanwendung eine Datenbank nutzt, bedeutet dies nicht, dass die Datenbank selbst aus dem Internet erreichbar sein muss. Es reicht völlig aus, wenn die Webanwendung die Datenbank erreicht. Auch im Unternehmen gilt, dass Nutzerinnen mit der Anwendung kommunizieren und die Anwendung die Datenbank nutzt. Es gibt keine Notwendigkeit, dass Nutzerinnen direkt mit der Datenbank kommunizieren. Wenn zwischen der Anwendung und der Datenbank unsichere Netze genutzt werden müssen, sollte die Verbindung durch eine Transportverschlüsselung mit TLS oder einer gleichwertigen (herstellerspezifischen) Verschlüsselung geschützt werden. Und damit kommen wir zu einer wichtigen Frage: Können die Daten in einer Datenbank verschlüsselt werden? Grundsätzlich ja, aber Sie müssen sich mit den Vor- und Nachteilen auseinandersetzen. Die Verschlüsselung einer Datenbank ist auf drei Arten möglich:

In der Anwendung: Die Anwendung kümmert sich um die komplette Verschlüsselung. Dies führt zu einem Verarbeitungsoverhead. Wenn Sie eine Datenspalte durchsuchen wollen, müssen Sie diese Spalte für alle Datensätze in die Anwendung laden, entschlüsseln und dann die Suchkriterien testen. Eine Suche mit den Mitteln der Datenbank ist nur eingeschränkt möglich. Sie können nach dem kompletten Eintrag suchen, indem Sie den Suchbegriff (zum Beispiel die PLZ 82256) verschlüsseln und nach dem verschlüsselten Begriff suchen. Sie können aber nicht mit Datenbankmitteln nach allen Postleitzahlen suchen, die mit »8« beginnen. Ein Backup aus dem Datenbankmanagementsystem (DBMS) der Datenbank ist verschlüsselt. In der Datenbank: Viele Datenbanken haben Befehle zum Verschlüsseln. Die Einschränkungen sind nahezu dieselben wie bei der Verschlüsselung in der Anwendung. Die Logik der Verschlüsselung (welche Spalten werden verschlüsselt?) muss in der Anwendung programmiert werden. Lediglich die Verschlüsselungsoperation finden in der Datenbank statt. Ein Backup aus dem DBMS der Datenbank ist verschlüsselt. Bei der Speicherung der Datenbank: Auch eine Datenbank speichert ihre Inhalte auf einem Datenträger. Und bei der Speicherung auf dem Datenträger können die Daten vom Betriebssystem transparent verschlüsselt werden (siehe Kapitel 23). Die Daten werden beim Lesen vom Datenträger in den Speicher entschlüsselt. Ein Backup aus dem DBMS der Datenbank ist unverschlüsselt. In einigen Datenbanken kann diese Verschlüsselung auch in der Datenbank aktiviert werden (zum Beispiel Oracle Transparent Data Encryption). Dann werden die Schlüssel in der Datenbank verwaltet. Bei diesen Datenbanken kann das Backup aus dem DBMS auch verschlüsselt erstellt werden. In der Praxis müssen Sie überlegen, welche Spalten einer Datenbank Sie verschlüsseln wollen, um einen guten Kompromiss zwischen Sicherheit und Performance zu erhalten.

Cloud Wenn Sie Strom benötigen, suchen Sie sich eine Steckdose. Dort können Sie dann zum Beispiel Ihr Notebook oder Ihr Handy laden. Sie machen sich keine Gedanken, wo der Strom herkommt oder ob er mit Ihrem Gerät kompatibel ist. Dies hat die Vision entstehen lassen, Rechenleistung genauso selbstverständlich aus einer Steckdose zu beziehen wie heute den Strom. Im Grunde ist das die Idee der Cloud. Genauso wie Sie nur verbrauchten Strom bezahlen, bezahlen Sie auch nur genutzte Rechenleistung. Der Verbrauch der Rechenleistung ergibt sich aus Ihrem Bedarf. Betrachten wir die Nutzung der Cloud, so gibt es aus Sicht des Unternehmens zwei wesentliche Nutzungsarten: Daten werden in der Cloud gespeichert, aber ausschließlich lokal verarbeitet. Daten werden in der Cloud verarbeitet. Diese beiden Nutzungsarten unterscheiden sich erheblich, insbesondere auch in den Schutzmöglichkeiten.

Speichern in der Cloud Wenn Sie »nur« Daten in der Cloud speichern, lässt sich relativ einfach für die nötige Sicherheit sorgen. Die Daten werden auf dem Rechner im Unternehmen verschlüsselt und dann verschlüsselt in der Cloud gespeichert. Damit ist der Inhalt dem Zugriff des Cloud-Betreibers entzogen. Da er nicht über die nötigen Schlüssel verfügt, kann er Ihre Daten nicht entschlüsseln. Es gibt zahlreiche Lösungen, die eine derartige Verschlüsselung ermöglichen.

Die beiden zum Konzern United Internet gehörenden E-MailMarken »web.de« und »GMX« ermöglichen ihren Kunden mit einer Tresorsoftware, den jeweiligen Cloud-Speicher verschlüsselt zu nutzen. Der Schlüssel befindet sich ausschließlich beim Kunden. Der Tresor basiert auf der aus Deutschland stammenden Verschlüsselungssoftware Cryptomator. Microsoft stellt allen Privatkunden, die ein Microsoft-365Abonnement abgeschlossen haben, mit dem »OneDrive Personal Vault« einen auf der Bitlocker-Technologie basierenden Tresor zur Verfügung. Der »Private Vault« wird zwar über starke Authentisierung abgesichert, über das Schlüsselmanagement ist jedoch nur wenig bekannt. Es ist derzeit nicht klar, ob der Schlüssel für den »Personal Vault« von Microsoft oder von der Nutzerin verwaltet wird. Um einen verlässlichen Zugriffsschutz für die in der Cloud gespeicherten Daten zu gewährleisten, muss der Schlüssel unter Kontrolle der Nutzerin sein. Dieses Feature wird oft auch als »Zero Knowledge« (der Anbieter hat kein Wissen über den Schlüssel) oder als BYOK-(Bring-your-own-Key-)Verschlüsselung bezeichnet. Wenn Sie eine solche Verschlüsselung einsetzen wollen, müssen Sie sich Gedanken machen, wie Sie die Verfügbarkeit der Verschlüsselungsschlüssel sicherstellen. Sie erinnern sich: Vertraulichkeit und Verfügbarkeit sind Konkurrenten.

Verarbeiten in der Cloud Wollen Sie Daten in der Cloud verarbeiten, gibt es drei wesentliche Klassen, in welche sich die Funktionalität einordnen lässt: Infrastructure as a Service (IaaS): Der Cloud-Provider stellt Ihnen virtuelle Rechner und virtuelle Netzwerkkomponenten zur Verfügung. Daraus bauen Sie nach Ihren Vorstellungen ein virtuelles Rechenzentrum in der Cloud. Sie installieren auf der virtuellen Hardware das Betriebssystem Ihrer Wahl und sind für Betrieb, Aktualisierung und Konfiguration selbst verantwortlich.

Platform as a Service (PaaS): Der Cloud-Provider stellt Ihnen eine Laufzeitumgebung, also Betriebssystem und Anwendungssoftware zur Verfügung. Für den Betrieb und die Aktualisierung der Software ist der Anbieter verantwortlich. Sie sind als Kunde für die Konfiguration und Anpassung der Anwendungssoftware zuständig. Software as a Service (SaaS): Der Cloud-Anbieter stellt Ihnen eine betriebsbereite Softwareumgebung (meist über einen Browser) zur Verfügung. Er ist für Betreib, Aktualisierung und Konfiguration verantwortlich. Typischerweise sind das Cloud-Dienste, die Sie ohne Anpassung direkt nutzen, etwa Online-Office-Software, E-MailPostfächer oder Videostreaming. Im Grunde geben Sie nur noch Ihre Daten dazu. Der Rest kommt vom Provider. Allen diesen Cloud-Nutzungen ist gemeinsam, dass sie mit Ihren Daten etwas machen, das heißt, die Daten werden verarbeitet. Damit müssen Ihre Daten in der Cloud im Klartext vorliegen. Verschlüsselung schützt die Daten nur im Ruhezustand, wenn der Rechner ausgeschaltet ist. In dem Moment, in dem der Rechner läuft und der Schlüssel eingegeben ist, sind die Daten zugreifbar. Wenn Sie eine Cloud-Nutzung planen, müssen Sie dies bei Ihren Überlegungen berücksichtigen. Technische Lösungen wie verschlüsselte Daten im RAM, die nur beim Laden in die CPU in der CPU entschlüsselt werden, existieren zwar (zum Beispiel AMD Secure Encrypted Virtualization) sind aber noch nicht Stand der Technik. Ziel der RAM-Verschlüsselung ist die kryptografische Isolierung von virtuellen Maschinen verschiedener Kunden, die auf derselben Hardware laufen. Um im Unternehmen einzelnen Abteilungen den Komfort einer Cloud-Nutzung zu bieten, wie das schnelle Aufsetzen von neuen virtuellen Rechnern, können Sie auch eine eigene interne CloudInfrastruktur aufsetzen. Wichtige und frei verfügbare Programme hierfür sind zum Beispiel Openstack, KVM, QEMU, Linux oder Webserver.

Die großen Cloud-Anbieter bringen immer neue Leistungen. OfficeProgramme in der Cloud (Apple iWork, Google Workspace, Microsoft 365 und viele andere) sind etabliert. Aktuell beginnt die Verlagerung des Desktops in die Cloud. Microsoft hat mit dem Windows-365-Cloud-PC im großen Stil begonnen und im Grunde auch nichts weiter gemacht, als den Terminalserver in die Cloud zu verlagern. Auf dem Schreibtisch steht dann nur noch ein Thin Client für die Ein- und Ausgabe. Durch die komplette Verarbeitung in der Cloud bekommt die Verfügbarkeit des Netzes und des Dienstleisters einen neuen Stellenwert. Sie müssen in diesem Fall Ihre Risikoanalysen nicht nur aktualisieren, sondern grundlegend überdenken.

Blockchain Die Buchhaltung Ihres Unternehmen nutzt vermutlich ein Hauptbuch (General Ledger). Dieses wird von einer zentralen vertrauenswürdigen Instanz geführt und nur besonders Berechtigte dürfen etwas eintragen. Von dem Hauptbuch gibt es ein gültiges Exemplar. Datensicherungen sorgen für Verfügbarkeit und Integrität. Stellen Sie sich nun vor. dass zwei oder mehr Parteien, die sich gegenseitig nicht vertrauen, gemeinsam ein Hauptbuch führen wollen, ohne sich auf eine zentrale und von allen als vertrauenswürdig akzeptierte Instanz zu stützen. Lässt sich das realisieren? Ja, das ist möglich. Das Konzept heißt Blockchain. Es wird gemeinsam ein Hauptbuch geführt, in das jeder etwas eintragen darf. Es gibt viele Kopien (Distributed Ledger) und die Prüfung der Gültigkeit erfolgt über ein Konsensmodell. Das grundlegende Konzept beruht auf mit kryptografischen Verfahren, im Wesentlichen Hashwerten, verketteten Blöcken. Abbildung 27.5 zeigt den systematischen Aufbau. Ein Block besteht aus Transaktionen. Dies können Überweisungen (Bitcoin, Ethereum) oder auch Dokumente, Hashwerte von Dokumenten oder beliebige andere Parameter sein. Die Transaktionen werden häufig vom Ersteller digital signiert. Ist ein Block voll, wird aus dem Hashwert über alle

Transaktionen in dem Block, dem Hashwert des Headers des vorhergehenden Blocks und einer Nonce ein neuer Hashwert berechnet. Der Trick, der die Blockchain sichert, besteht darin, dass dieser Hashwert eine Randbedingung erfüllen muss: er muss mit einer vorgegebenen Anzahl an Nullen beginnen (er muss also kleiner sein als ein vorgegebener Schwellenwert). Um dies zu erreichen, wird die Nonce so lange variiert, bis der Hashwert passt. Im Grunde ist dies ein BruteForce Angriff auf den Hashwert des Headers mit dem Ziel, ein vorgegebenes Kriterium für den Hashwert zu erfüllen. Wer diese Berechnung durchführen darf, unterscheidet sich nach je nach gewähltem Konsensmodell.

Abbildung 27.5: Die verkette Listenstruktur einer Blockchain.

Es gibt die folgenden wesentlichen Konsensmodelle: Proof of Work: Hier darf sich jedermann versuchen. Wer einen passenden Hashwert zuerst findet, hat gewonnen und dessen Block schreibt die Kette fort. Dieses Modell skaliert nicht gut und verbraucht unnötig viel Energie. Es wird aber trotzdem bei Bitcoin genutzt. Proof of Stake: Es wird ausgewürfelt, wer die Kette fortschreiben darf. Die Wahrscheinlichkeit, dass jemand ausgewählt wird, hängt an seinem Interesse, dass das Verfahren sicher funktioniert. Bei einer Währung könnte zum Beispiel das Kriterium die Menge der Währung, die jemand in Besitz hat, sein. Der ausgewählte Teilnehmer berechnet den Hashwert.

Proof of Authority: Nur wenige Berechtige (Moderatoren) dürfen die Blockchain fortschreiben. Dieses Verfahren skaliert gut. Es wird häufig bei privaten, zum Beispiel firmeninternen Blockchains eingesetzt. Es gibt auch noch etliche andere Konsensmodelle. Beim Proof Of Work ist es möglich, dass mehrere Teilnehmer das Problem, den Hashwert des neuen Blockes zu finden, nahezu gleichzeitig lösen. Dann werden die Ketten kurzfristig parallel weitergeführt. Sobald das bemerkt wird, wird die zu dem Zeitpunkt kürzere Kette eingestellt. Alle Transaktionen in der kürzeren Kette, die seit der Spaltung dazugekommen sind, müssen neu ausgeführt werden. Dies trägt nicht zu einer guten Skalierung bei. Die bekannteste Blockchain-Anwendung ist sicherlich Bitcoin, eine Realisierung von digitalem Geld, auch »Kryptowährung« genannt. Bitcoin verwendet, wie gesagt, Proof of Work. Dies führt zu einer erheblichen Kritik aufgrund des extrem hohen Stromverbrauchs für das Erzeugen neuer Blöcke (Mining). Wer einen neuen Block als Erster erzeugt, erhält eine Belohnung in Bitcoins. Nach dem Cambridge Bitcoin Electricity Consumption Index verbrauch das Bitcoin Mining etwa 13 Gigawatt elektrische Leitung. Das sind rund 115 Terawattstunden im Jahr (Stand November 2021) und entspricht in etwa dem jährlichen Stromverbrauch der Niederlande (CIA Factbook). Bei Bitcoins sind derzeit damit nur rund 7 Transaktionen pro Sekunde möglich. Die Kryptowährung Ethereum stellt derzeit von Proof Of Work auf Proof of Stake um. Da in einer Blockchain nichts gelöscht werden kann, wächst der Bedarf an Speicherplatz kontinuierlich an. Datenschutzrechtlich sind Blockchain-Anwendungen mit personenbezogenen Daten nicht zulässig, gerade weil in der Blockchain nicht gelöscht werden kann. Auch eine Einwilligung ist keine Lösung für dieses Problem, da eine Einwilligung jederzeit zu widerrufen sein muss, woraufhin die entsprechenden Daten gelöscht werden müssten. Zusätzlich ist eine Blockchain meist öffentlich. Wir müssen davon

ausgehen, dass im Sinne der DS-GVO die Blockchain-Technologie eher nicht anonym, sondern pseudonym ist. Grundsätzlich sollten Sie immer berücksichtigen: Eine Blockchain löst das Problem, gemeinsam ein Hauptbuch zu führen, wenn sich die beteiligten Parteien nicht vertrauen. In einer von gegenseitigem Vertrauen geprägten Zusammenarbeit macht eine Blockchain keinen Sinn. Insbesondere erscheinen Konzepte, die es nur einer vertrauenswürdigen zentralen Instanz erlauben, die Blockchain fortzuschreiben, wenig sinnvoll.

Künstliche Intelligenz Neben der Blockchain ist »Künstliche Intelligenz« der zweite Modebegriff in der IT, der in jedem Projektantrag vorkommen muss. Wesentliche Meilensteine, sich dem Thema zu nähern, waren: Eliza (Weizmann, 1966): Ein erstes System zur Verarbeitung natürlicher Sprache. Weizmann wollte mit einem System zeigen, dass ein Mensch nicht mehr unterscheiden kann, ob er mit einem anderen Menschen oder einer Maschine redet (Turing-Test). Die Spracheingabe erfolgte per Tastatur. Heute, mehr als 50 Jahre später, verzweifeln wir manchmal an den Chat-Robotern eines Helpdesks, die uns offensichtlich einfach nicht verstehen wollen. Der IBM-Schachcomputer Deep Blue schlägt den langjährigen Schachweltmeister Garri Kasparow im Schach (1997). Das IBM-Programm Watson gewinnt die US-amerikanische Rateshow Jeopardy! gegen einen Menschen (2011). Dabei war das System nicht mit dem Internet verbunden, sondern konnte lediglich auf seine eigene Faktendatenbank zugreifen. Das Programm AlphaGo der Google-Tochter DeepMind schlägt den Go-Europameister Fan Hui (2015). Go ist ein deutlich komplexeres Spiel als Schach.

In den aufgeführten Meilensteinen haben hochspezialisierte Programme, die jeweils genau ein Problem lösen konnten, sich bei der Lösung genau dieses Problems gegenüber Menschen durchgesetzt. Eliza war ein frühes sogenanntes Expertensystem. Es versuchte, durch bestimmte Fragen und die Analyse der Antworten ein Problem zu lösen. Das Expertenwissen wird durch die Programmierer in die Software eingebracht. Es sind allerdings nur solche Expertensysteme möglich, die je nach eingefütterten Daten in den jeweiligen Fachgebieten tätig werden können. Die Systeme lernen nicht dazu. Klassische Spam-Filter fallen auch in diese Kategorie, da sie die Entscheidung »Spam ja oder nein« nach festen Regeln durchführen (siehe Abbildung 27.6a).

Abbildung 27.6: Die Verwendung von Algorithmen und Daten beim Maschinellen Lernen.

Die »lernenden« Bayes-Filter bewerten E-Mails ebenfalls nach bestimmten darin vorkommenden Wörtern. Sie sind in dem Sinne lernend, dass sie auf einer Klassifikation der E-Mails in Spam und NoSpam der Nutzerin beruhen. Aus den Wörtern, die in Spam-Mails und in NoSpam-Mails vorkommen, werden Wahrscheinlichkeiten bestimmt, um neue Mails automatisch nach den dort auftretenden Wörtern zu klassifizieren. Aus der Klassifizierung der Nutzerin wird das »Wissen«

aufgebaut, um dann Mails automatisch zu klassifizieren (siehe Abbildung 27.6b). Das Programm Watson arbeitete in zwei Stufen. Aus eingegebenen Daten (zum Beispiel Wikipedia, Zeitungsartikel) wird automatisch Wissen abgeleitet. Diese aufbereiteten Daten (Wissen) werden dann benutzt, um die Aufgabenstellung zu lösen (siehe Abbildung 27.6c). Wesentliche Probleme sind das Auflösen von widersprüchlichem Wissen (Watson löschte sich widersprechende Fakten), die optimale Speicherung des Wissens und das Verketten von Fakten (durch Verknüpfen der Informationen »Angel Merkel war Bundeskanzlerin.« und »Angela Merkel ist eine Frau.« die Antwort auf die Frage »War schon mal eine Frau Bundeskanzler?« finden). Heute ist »Maschinelles Lernen« ein wesentlicher Teil der Anwendung von »Künstlicher Intelligenz«. Dabei geht es um das Erkennen von Mustern in Eingabedaten, die klassifiziert sind. Sie haben zum Beispiel eine Anzahl von Fotos von Wölfen und Huskys, die klassifiziert sind in »Husky« und »Wolf«. Das System lernt jetzt durch eine komplexe Verarbeitung und Merkmalsabstraktion die Huskys und die Wölfe zu unterscheiden. Durch bewusste Auswahl von Wolf-Bildern mit Schnee und Husky-Bildern ohne Schnee lernte das System die Unterscheidung der beiden Tierarten am Schnee. Das Beispiel zeigt die Probleme des Trainings von Systemen beim Maschinellen Lernen. [RSG16] Aktuelle Systeme bieten auch noch die Möglichkeit der Rückkopplung. Wird ein solches System zum Beispiel in der Medizin eingesetzt, kann der Arzt bestätigen, ob er die Diagnose teilt. Damit lernt das System aus jeder Klassifikation dazu (siehe Abbildung 27.6d). Solche Systeme werden neben der medizinischen Diagnostik auch bei vorausschauender Wartung, bei der Bewertung von Finanztransaktionen oder beim autonomen Fahren eingesetzt. Die Integrität der Datenbank mit den aufbereiteten Daten ist wichtig, da veränderte Daten zu falschen Klassifizierungen führen können. Bei Systemen, die eine Rückkopplung eingebaut haben, ist auch dieser Prozess kritisch, da qualitätsrelevant. Es ist nicht trivial, eine zusätzliche gelernte Information zu entfernen, ohne die alten Daten wieder einzuspielen.

Die Algorithmen, die beim Maschinellen Lernen eingesetzt werden, stützen sich auf Daten, entweder Rohdaten oder aufbereitete Daten. Die Integrität dieser Daten ist wichtig. Bei personenbezogenen Daten muss auch die Vertraulichkeit sichergestellt werden. Insbesondere, wenn der Entscheidungsalgorithmus seine Datenbasis über eine Rückkopplung im laufenden Betrieb ergänzt, um aus der getroffenen Entscheidung weiter zu lernen, sind die Integrität des Lernprozesses und die Manipulationssicherheit wichtig. Andernfalls würde etwas Falsches gelernt. Datenschutz und Sicherheit beim Maschinellen Lernen sind Gegenstand der aktuellen Forschung. Eine informierte Information der Betroffen vor einer Einwilligung ist schwierig, da die Abläufe beim Lernprozess nicht immer nachvollziehbar sind. Eine Unterscheidung der Daten in kritische und unkritische Daten ist zwar in den Rohdaten möglich, in den gelernten aber schwierig, da die aufbereiteten Daten gut durchmischt sind. Werden zusätzliche Daten gelernt, ändern sich alle aufbereiteten Daten.

Teil VI

Der Top-Ten-Teil

Weitere ... für Dummies-Bücher finden Sie unter www.fuer-dummies.de.

IN DIESEM TEIL … In diesem Teil fassen wir noch einmal kurz und knapp die wichtigsten technisch-organisatorischen Maßnahmen zusammen, aufgeteilt in zwei TopTen-Listen: eine zur Technik und eine zur Organisation. Sollten Sie diese beiden Listen abgearbeitet haben, verfügt Ihre IT auf jeden Fall schon mal über einen guten Basisschutz.

Kapitel 28

Zehn Maßnahmen für den technischen Basisschutz IN DIESEM KAPITEL Die zehn wichtigsten technischen Maßnahmen

Um auf unseren IT-Systemen eine Basissicherheit zu garantieren, müssen wir die folgenden zehn minimalen technischen Maßnahmen ergreifen. Die Reihenfolge der Auflistung spiegelt eine gewisse Priorisierung wider – wir können nicht alles gleichzeitig einrichten und müssen deshalb die wirksamsten und wichtigsten Aufgaben zuerst angehen. Die hier aufgelisteten Maßnahmen sind im Privatbereich genauso wichtig wie im Unternehmen.

Backup Die Datensicherung ist die Mutter aller IT-Sicherheitsmaßnahmen und deshalb auf jeden Fall die wichtigste Maßnahme. Nahezu jeder Vorfall lässt sich mit einem funktionierenden Backup in den Griff bekommen. Die Fachzeitschrift c't hat dies mit dem Aufkleber »Kein Backup, kein Mitleid« auf den Punkt gebracht. Solange die Datensicherung nicht funktioniert, brauchen wir uns um um die anderen Maßnahmen gar nicht erst zu kümmern.

Schutz vor Schadsoftware Eine gute Schadsoftware-Erkennung ist der zweite Schritt auf dem Weg zu einem guten Basisschutz. Welche technische Lösung wir einsetzen,

hängt von unserem Betriebssystem ab. Auf einem Linux-System ist eine andere Lösung gefragt als unter Windows.

Netzwerkschutz Unser Netzwerk muss zumindest durch eine Firewall geschützt sein. Bei größeren Netzen sollte das Netzwerk auch intern in Bereiche mit jeweils angepasstem Sicherheitsniveau aufgeteilt sein. Nur so können wir sicherstellen, dass sich Vorfälle lokal eingrenzen lassen.

Firewall Eine Firewall ist ein wichtiger Baustein, um den Netzwerkverkehr ins Unternehmen und aus dem Unternehmen heraus zu filtern. Die Netze eines Unternehmens müssen durch eine Firewall geschützt werden!

Patch-Management Da Software nie fehlerfrei ist, kommen von allen seriösen Softwareherstellern regelmäßige Fehlerkorrekturen (Patches; Sicherheitsupdates). Diese müssen zeitnah installiert werden.

Verschlüsselt speichern Eine wichtige Maßnahme, um die Vertraulichkeit von Daten zu gewährleisten, ist das Verschlüsseln von Daten auf Datenträgern. Insbesondere sollten mobile Datenträger das Unternehmen nur verschlüsselt verlassen dürfen.

Verschlüsselt kommunizieren Um Daten beim Transport zu schützen, muss ihre Übertragung verschlüsselt erfolgen, denken Sie an die Stichworte E-MailVerschlüsselung, VPN und HTTPS.

Passwort-Management »Ein Passwort für alles« ist ganz und gar nicht sicher. Wir müssen für jeden Dienst ein anderes sicheres Passwort verwenden. Dabei muss technisch sichergestellt sein, dass Nutzerinnen keine unsicheren Passwörter wählen, und gleichzeitig müssen wir die Nutzerinnen technisch unterstützen, damit sie bei den vielen unterschiedlichen Passwörtern nicht den Überblick verlieren.

Biometrie und Zwei-FaktorAuthentifikation Die Nutzung biometrischer Authentifizierung am Smartphone oder PC ist eine Komfortfunktion, die sogar die Sicherheit erhöht, wenn deshalb ein längeres und komplexeres Passwort genutzt wird. Eine Zwei-FaktorAuthentifikation schützt kritische Konten zusätzlich. Ein ausgespähtes Passwort genügt dann nicht mehr für einen erfolgreichen Hackerangriff.

Spam-Abwehr Auch wenn von Spam-E-Mails keine unmittelbare Gefahr ausgeht, belasten diese Mails die technischen Ressourcen der IT und die Nerven der Menschen unnötig. Darum sollten sie – natürlich rechtlich einwandfrei – »unterdrückt« werden.

Kapitel 29

Zehn Maßnahmen für den organisatorischen Überbau IN DIESEM KAPITEL Die zehn wichtigsten organisatorischen Maßnahmen

Die besten technischen Maßnahmen nutzen nicht viel, wenn nicht festgelegt wird, wie damit umzugehen ist. Deshalb müssen technische Maßnahmen immer durch den passenden organisatorischen Überbau begleitet werden.

Übernahme der Verantwortung Die Leitung des Unternehmens muss die Verantwortung für die Informationssicherheit im Unternehmen übernehmen. Aus dieser Verantwortung muss sie die Organisation der Informationssicherheit gestalten.

Leitlinie zur Informationssicherheit Das wichtigste Dokument, das die Unternehmensspitze auf den Weg bringen muss, ist die Leitlinie zur Informationssicherheit. In diesem Dokument werden die Ziele der Informationssicherheit im Unternehmen festgelegt. Die Leitlinie wird von der Unternehmensleitung in Kraft gesetzt.

Richtlinien zur Informationssicherheit In den Richtlinien zur Informationssicherheit werden die Ziele der Informationssicherheit konkretisiert.

Definition und Besetzung der Rollen Alle Rollen in der Informationssicherheit im Unternehmen müssen mit ihren Verantwortlichkeiten definiert werden. Da ein Informationssicherheitsbeauftragter gesetzlich nicht vorgeschrieben ist, muss diese Rolle hier eigens definiert werden.

Definition der fundamentalen Prozesse Die fundamentalen Prozesse der Informationssicherheit im Unternehmen müssen festgelegt werden. Dazu gehören alle Aspekte von Krisenplänen über Beschaffungsregeln für IT-Ausstattung bis zu den Meldeprozessen bei Vorfällen.

Risikobetrachtung Es muss eine Risikobeurteilung erfolgen, die zum Beispiel auf den Grundgefährdungen im IT-Grundschutz aufsetzt.

Klassifizierung der Daten und Systeme Alle Systeme, Netzwerke und Daten müssen nach ihrem Schutzbedarf klassifiziert werden. Aus dem Schutzbedarf ergeben sich dann die

erforderlichen Sicherheitsmaßnahmen.

Awareness Alle Beschäftigten müssen mit den Regelungen für die Informationssicherheit im Unternehmen vertraut gemacht werden. Aufgrund der immer neuen Formen von Gefährdungen besteht ein regelmäßiger Bedarf an ergänzenden Schulungen für alle Beschäftigten.

Krisenmanagement Es müssen sowohl ein Krisenstab eingerichtet als auch Krisenpläne erstellt werden. Regelmäßige Übungen und Aktualisierungen gehören dazu. Bildet man den Krisenstab erst nach Eintreten der Katastrophe, ist es definitiv zu spät!

Regelmäßige Überprüfung Mindestens alle zwei Jahre ist eine regelmäßige Überprüfung der Wirksamkeit und Angemessenheit aller technischen und organisatorischen Maßnahmen erforderlich, damit Sie diese an die sich ständig ändernden Rahmenbedingungen anpassen können.

Literaturverzeichnis [Abb99]

Janet Abbate, Inventing the Internet, MIT Press (1999)

[And20]

Ross Anderson, Security Engineering ‐ A Guide to Building Dependable Distributed Systems, John Wiley & Sons, New York, Auflage (2020)

[ATR20]

Daniele Antonioli, Nils Ole Tippenhauer und Kasper Rasmussen, Bias: Bluetooth impersonation attacks, In Proceedings of th IEEE Symposium on Security and Privacy (S&P) (2020)

[BMI16]

Bundesministerium des Innern, für Bau und für Heimat, Cyber‐Sicherheitsstrategie für Deutschland 2016, https://www.bmi.bund.de/cybersicherheitsstrategie/ (2016)

[BMVG]

Bundesministerium der Verteidigung, Cybersicherheit, https://www.bmvg.de/de/themen/cybersicherheit

[Bre76]

Rüdiger Breuer, Direkte und indirekte Rezeption technischer Regeln durch die Rechtsordnung, Archiv des öffentlichen Recht 101 46–88 (1976)

[BSI13]

Bundesamt für Sicherheit in der Informationstechnik, BSI TR‐03126 sicherer RFID‐Einsatz (TR RFID), https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/TechnischeRichtlinien/TR-nach-Thema-sortiert/tr03126/tr-03126_dvl.html (2012‐2013)

Bundesamt für Sicherheit in der Informationstechnik, Kriterien für die Standortwahl von Rechenzentren, [BSI19a]

[BSI19b]

https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nachAngriffszielen/Hochverfuegbarkeit/Standort-Kriterien_HV-RZ/Standort-Kriterien_HV-RZ_node.html (2019)

Bundesamt für Sicherheit in der Informationstechnik, Verfahrensbeschreibung zur Zertifizierung von Auditoren – VB‐Auditore https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Auditoren.html (2019) Bundesamt für Sicherheit in der Informationstechnik, Entwicklungsstand Quantencomputer,

[BSI20a]

[BSI20b]

[BSI21]

https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-undEmpfehlungen/Kryptografie/Quantencomputing/entwicklungsstand-quantencomputer_node.html

(2020)

Bundesamt für Sicherheit in der Informationstechnik, NFC Systeme im Praxiseinsatz, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/DigitaleGesellschaft/NFC_Systeme_im:Praxiseinsatz.pdf

(2020)

Bundesamt für Sicherheit in der Informationstechnik, DDoS‐Angriffe im Cyber‐Raum, https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nachGefaehrdungen/DDoS/ddos_node.html (2021)

[BSIG21]

Bluetooth SIG Core Specification Working Group, Bluetooth Core Specification v5.3, https://www.bluetooth.com/specifications/specs/core-specification/ (2021)

[CBL14]

David Clark, Thomas Berson und Herbert S. Lin (Hrsg.), At the Nexus of Cybersecurity and Public Policy: Some Basic Concepts and Issues, The National Academies Press, Washington, DC (2014)

[CHR]

https://www.chathamhouse.org/about-us/chatham-house-rule

[CISA19]

U.S. CERT Cybersecurity und Infrastructure Security Agency, Alert (TA13‐088A) DNS Amplification Attacks, https://uscert.cisa.gov/ncas/alerts/TA13-088A (2013–2019)

[CIO]

Rolle des CIO, https://www.cio.de/topics/rolle-des-cio,843864

[DM07]

Saar Drimer und Steven J. Murdoch, Relay attacks on card payment: vulnerabilities and defences, https://murdoch.is/talks/ccc07relayattacks.pdf, Vortrag beim 24. Chaos Communication Congress (2007)

[DMS04]

Roger Dingledine, Nick Mathewson und Paul F. Syverson, Tor: The Second‐Generation Onion Router, In Proceedings of the 13th USENIX Security Symposium, August 9‐13, 2004, San Diego, CA, USA, 303–320 (2004)

[ENISA12]

European Union Agency for Cybersecurity, Introduction to Return on Security Investment, https://www.enisa.europa.eu/publications/introduction-to-return-on-security-investment

(2012)

[Fox03]

Dirk Fox, Security Awareness oder: Die Wiederentdeckung des Menschen in der IT‐Sicherheit, Datenschutz und Datensicherheit ‐ DuD, 27 676–680 (2003)

[GCB+21]

Matheus E. Garbelini, Sudipta Chattopadhyay, Vaibhav Bedi, Sumei Sun und Ernest Kurniawan, BRAKTOOTH: Causing Havoc on Bluetooth Link Manager, https://asset-group.github.io/disclosures/braktooth/ 2021

[Ger19]

Rainer W. Gerling, Angriffe auf Raspberry Pis: Anatomie eines Vorfalls, In Albrecht Ude (Hrsg.), Sicherheit in vernetzten Systemen: 26. DFN‐Konferenz, Books on Demand, Norderstedt (2019)

[GGHP20]

Rainer W. Gerling, Sebastian Gerling, Stefan Hessel und Ronald Petrlic, Stand der Technik bei Videokonferenzen ‐ und die Interpretation der Aufsichtsbehörden, Datenschutz und Datensicherheit ‐ DuD, 44 740–747 (2020)

[Han06]

Saul Hansel, em AOL Removes Search Data on Group of Web Users, The New York Times, 8. August (2006)

[Har08]

Dan Harkins, Simultaneous Authentication of Equals: A Secure, Password‐Based Key Exchange for Mesh Networks, In 2nd International Conference on Sensor Technologies and Applications (Sensorcomm 2008), 839–844 (2008)

[Hen20]

Olaf Henniger, Neue Normen für biometrische Datenaustauschformate, Datenschutz und Datensicherheit ‐ DuD, 44 43–47

(2020) [IEEE21]

IEEE, MAC Address Block Large (MA‐L), http://standards-oui.ieee.org/oui/oui.txt (2021)

[ITPR20]

Arbeitsgruppe des IT‐Planungsrats ›Informationssicherheit‹, Leitlinie für die Informationssicherheit in der öffentlichen Verwaltun 2018: Umsetzungsplan, https://www.it-planungsrat.de/fileadmin/beschluesse/2020/Beschluss202005_TOP_09_Umsetzungsplan.pdf (2020)

[ITU94]

ITU, Information technology – Open Systems Interconnection – Basic Reference Model: The basic model, Online unter https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=2820 (1994)

[KMGG07]

Georgios Kambourakis, Tassos Moschos, Dimitris Geneiatakis und Stefanos Gritzalis, Detecting DNS Amplification Attacks, Proceedings of the 2nd International Workshop on Critical Information Infrastructures Security (CRITIS 2007), 185–196 (2007

[Kum07]

Sanjeev Kumar, Smurf‐based Distributed Denial of Service (DDoS) Attack Amplification in Internet, In 2nd International Conference on Internet Monitoring and Protection (ICIMP 2007) (2007)

[LfDN19]

https://lfd.niedersachsen.de/startseite/allgemein/presseinformationen/abschluss-der-querschnittsprufung-182253.html

(2019)

[LLV07]

Ninghui Li, Tiancheng Li und Suresh Venkatasubramanian, t‐Closeness: Privacy Beyond k‐Anonymity and l‐Diversity, Proceedings of the 23rd International Conference on Data Enginering (ICDE'07), 106–115 (2007)

[Maj18]

Marek Majkowski, The cloudflare blog: Memcrashed ‐ Major amplification attacks from UDP port 11211, https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ (2018)

[Mem18]

Memcached, Memcached 1.5.6 Release Notes, https://github.com/memcached/memcached/wiki/ReleaseNotes156 (2018) Damian Menscher, Exponential growth in DDoS attack volumes | Google Cloud Blog,

[Men21]

https://cloud.google.com/blog/products/identity-security/identifying-and-protecting-against-the-largest-ddos-attack

(2020) [MGKV06]

Ashwin Machanavajjhala, Johannes Gehrke, Daniel Kifer und Muthuramakrishnan Venkitasubramaniam, l‐Diversity: Privacy Beyond k‐Anonymity, Proceedings of the 22nd International Conference on Data Engineering (ICDE'06), 24–36 (2006)

[MN09]

Ronald Moen und Clifford Norman, Evolution of the PDCA Cycle, Proceedings of the 7th ANQ Congress (2009)

[NS08]

Arvind Narayanan und Vitaly Shmatikov, Robust De‐anonymization of Large Sparse Datasets, Proceedings of the IEEE Symposium on Security and Privacy, 111–125 (2008)

[PBB+17]

John Padgette, John Bahr, Mayank Batra, Marcel Holtmann, Rhonda Smithbey, Lily Chen und Karen Scarfone, NIST Special Publication 800‐121 Rev. 2: Guide to Bluetooth Security, https://doi.org/10.6028/NIST.SP.800-121r2 (2017)

[PD21]

Ronald Petrlic und Leo Dessani, E‐Mail Sicherheit auf dem Prüfstand, Datenschutz und Datensicherheit ‐ DuD, 45 534–540 (2021)

[Poh03]

Norbert Pohlmann, Firewall‐Systeme, MITP‐Verlag, Bonn (2003)

[PSRC17]

Adrian Perrig, Pawel Szalachowski, Raphael M. Reischuk und Laurent Chuat, SCION: A Secure Internet Architecture, https://scion-architecture.net/pdf/SCION-book.pdf (2017) Rechnungshöfe des Bundes und der Länder, Grundsatzpapier zum Informationssicherheitsmanagement,

[RHBL20]

https://www.bundesrechnungshof.de/de/veroeffentlichungen/produkte/weitere/resolveuid/51c8f7fb355647499896e24d3a8bdc

(2020) [RSG16]

Marco Tulio Ribeiro, Sameer Singh und Carlos Guestrin, ›Why Should I Trust You?‹: Explaining the Predictions of Any Classifier, In Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 1135–1144, Association for Computing Machinery. New York, NY, USA (2016)

[Sch19]

Jürgen Schmidt, Forscher vermelden neuen Rekord beim Knacken von RSA, https://heise.de/-4603700 (2019)

[SDM20]

Das Standard‐Datenschutzmodell, https://www.datenschutzzentrum.de/sdm/ (2020)

[SJTH20]

Rolf Schwartmann, Andreas Jaspers, Gregor Thüsing und Dieter Kugelmann (Hrsg.), DS‐GVO/BDSG – Datenschutz‐ Grundverordnung Bundesdatenschutzgesetz, C.F. Müller GmbH, Heidelberg (2020)

[SMBP]

Sabrina Schönhart, Armin Müller, Laszlo Böszörmenyi und Stefan Podlipnig, DES Challenge, http://cs-exhibitions.uniklu.ac.at/index.php?id=263

[Soc17]

IEEE Computer Society, 802c‐2017 ‐ IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture– Amendment 2: Local Medium Access Control (MAC) Address Usage, IEEE (2017)

[Ste]

Didier Stevens, PDF Tools, https://blog.didierstevens.com/programs/pdf-tools/

[Sti18]

Benno Stieber, Strategien gegen Spione, MaxPlanckForschung, Heft 1, 72–77 (2018)

[StK]

https://www.steb-koeln.de/hochwasser-und-ueberflutungsschutz/wasserstandsvorhersage/wasserstandsvorhersage.jsp

[Swe97]

Latanya Sweeney, Weaving Technology and Policy Together to Maintain Coddentiality, Journal of Law, Medicine & Ethics, 25 98–110 (1997)

[Swe02]

Latanya Sweeney, k‐Anonymity: a Model for protecting Privacy, International Journal of Uncertainty, Puzziness and Knowledge‐Based Systems, 10 557–570 (2002)

[Tor21]

Tor Project, https://www.torproject.org (2021)

[Vas21]

Rechtssache C‐340/21: Vorabentscheidungsersuchen des Varhoven administrativen sad (Bulgarien), eingereicht am 2. Juni 2021, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A62021CN0340&qid=1643814406531 (2021)

[VE06]

Randal Vaughn und Gadi Evron, DNS Amplification Attacks, DEF CON 14 (2006)

[VP17]

Mathy Vanhoef und Frank Piessens, Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, In Proceedings of the 24th ACM Conference on Computer and Communications Security (CCS 2017). ACM (2017)

[VR19]

Mathy Vanhoef und Eyal Ronen, Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP‐pwd, Cryptology ePrin Archive, Report 2019/383, https://ia.cr/2019/383 (2019)

[WFA20]

Wi‐Fi Alliance, WPA3 Specification Version 3.0, https://www.wi-fi.org/download.php? file=/sites/default/files/private/WPA3_Specification_v3.0.pdf (2020)

[WFA21]

Wi‐Fi Alliance, Discover Wi‐Fi Security, https://www.wi-fi.org/discover-wi-fi/security (2021)

[WN05]

Amrit T. Williams und Mark Nicolett, Improve IT Security With Vulnerability Management, https://www.gartner.com/en/documents/480703 (2005)

Abbildungsverzeichnis Abbildung 2.1: Anzahl der aktuellen (2012, 2016 und 2019) und veralteten (2003, 2008) Windows Server Versionen. (Quelle: Rapid7 Blog, Oktober 2020) Abbildung 3.1: Das Risiko wird häufigals das Produkt aus Schadenshöhe und Eintrittswahrscheinlichkeit betrachtet. Abbildung 3.2: Durch die Risikostrategien Vermeiden, Reduzieren und Delegieren kanndas Gesamtrisiko auf ein tragbares Restrisiko vermindert werden. Abbildung 5.1: Die beispielhafte Auswertungder Fragebögen zur Bewertung des Stands der Technik einer bestimmten Technik (nach TeleTrusT, Handreichung zum Stand der Technik). Abbildung 6.1: Die gesetzlichen Vorgaben zur IT-Sicherheit in den unterschiedlichen Sektoren. Die »??« kennzeichnen eine noch nicht existierende Verordnung. »DRA. d. K.« istder Durchführungsrechtsakt 2018/151 der Europäischen Kommission. Abbildung 6.2: Das fünfstufige Reifegradmodell zur OZG-Umsetzung der Verwaltungsverfahren durch deutsche Behörden. (basiert auf Digitalisierungsleitfaden Bund) Abbildung 6.3: Die Priorisierung P1 bis P4 sowie die Zahl der Maßnahmen für kleine, mittlere und große Praxen. (GG = Großgeräte; TI = Telematik-Infrastruktur) Abbildung 6.4: Je nach Grö   ße einer ärztlichen beziehungsweise zahnärztlichen Praxis oder eines Krankenhauses gelten unterschiedliche gesetzliche Vorgaben. Abbildung 7.1: Übersicht über die ISO-Normen der ISO/IEC 27000er Standard-Familie; TR: technische Richtlinie. (Quelle: basiert auf ISO/IEC 27000:2018) Abbildung 9.1: Grobe qualitative Darstellungdes Aufwands und des typisch zu erreichenden Sicherheitsniveaus bei den verschiedenen

Informationssicherheitsstandards. Abbildung 9.2: Tabellarische Übersicht überdas Ergebnis einer Selbsteinschätzung der Informationssicherheit im VdS-Quick-Check. (Quelle: Screenshot VdS-Quick-Check) Abbildung 10.1: Beispiele für Identifikatoren, Teil-Identifikatoren und potenziell kritische Attribute im Umfeld von Beschäftigtendaten. (Darstellung in Anlehnung an S. Ecker, Masterarbeit Hochschule München 2021) Abbildung 10.2: Office-Dokumente können in den Desktopversionen von Microsoft Office mit unterschiedlichen Einschränkungen versehen werden. Abbildung 10.3: Die Konfiguration der Verschlüsselung eines Webservers wird bei SSL Labs mit amerikanischen Schulnoten bewertet. »A+« ist dabei die beste Note. Abbildung 10.4: Der Greenbone-Schwachstellenscanner bewertet die gefundenen Schwachstellen nach dem »Common Vulnerability Scoring System« (CVSS) auf einer Skala von 0 bis 10. Abbildung 11.1: Die Regelungspyramide, die die zeitlichen Änderungsskalen und die unterschiedlichen Detaillierungsgrade trennt. (nach BSI) Abbildung 12.1: Der Deming- oder PDCA-Zyklus als vierstufiger Prozess der ständigen Verbesserung. Abbildung 13.1: Auszug aus der Log-Datei auth.log eines Servers. Hier sind die unberechtigten Anmeldeversuche innerhalbvon drei Stunden zu sehen. Abbildung 15.1: Der Anfang eines TLP:WHITE-Dokuments des BSI mit einer Warnung vor einer Schwachstelle. Alle Warnungen des BSI verwenden diesenAufbau. (Quelle: BSI) Abbildung 17.1: Kommunikationsmodelleines symmetrischen Verschlüsselungssystem. Nachricht, verschlüsselte Nachricht, Schlüssel. (Shannon, 1949)

Abbildung 17.2: Symmetrische Verschlüsselung Abbildung 17.3: Die Verschlüsselung zweier Blöcke im ECB- (links) und CBC-Modus (rechts; = ). Abbildung 17.4: Das Logo der Buchreihe (oberes Bild) wurde mit AES128 mit demselben Schlüssel verschlüsselt, einmal im ECB-Modus (mittleres Bild) und einmal im OFB-Modus (unteres Bild). Abbildung 17.5: Das Verschlüsselungsschema ist beim CFB-, OFB- und CTR-Modus gleich. Lediglich der Wert, der für »Input n« verwendet wird, unterscheidet sich bei den drei Modi ( = ). Abbildung 17.6: Bei einem Man-in-the-Middle-(MITM-)Angriff klinkt sich Mallory aktiv in die Kommunikation von Alice und Bob ein. Abbildung 17.7: Die Verschlüsselung erfolgt mit dem öffentlichen Schlüssel des Empfängers, die Entschlüsselung mit dem privaten Schlüssel des Empfängers. Abbildung 17.8: Zur Erzeugung von Schlüsselpaaren werden im Wesentlichen gute Zufallszahlen benötigt. Abbildung 17.9: Ein Briefkasten ist eine Analogie zur asymmetrischen Verschlüsselung: Jeder kann etwas durch den Schlitz hineinwerfen, aber nur der Besitzer hat den Schlüssel, um etwas herauszunehmen. (Abbildung: BURG-WÄCHTER KG) Abbildung 17.10: Bei der Hybridverschlüsselung wird der Schlüssel mittels asymmetrischer Verschlüsselung ausgetauscht. Der Klartextwird jedoch symmetrisch verschlüsselt. Abbildung 17.11: Bei der Merkle-Damgård-Konstruktion besteht die Hashfunktion aus der wiederholten Anwendung eines elementaren HashModuls. Abbildung 17.12: Wir können uns die Bildung eines Hashwerts wie die Faltung einer Folie mit Text vorstellen. Abbildung 17.13: Beispiele für die verschiedenen Padding-Verfahren. Der Padding-Bereich ist weiß hinterlegt. Die vier Längenbytes sind schwarz hinterlegt.

Abbildung 17.14: Ein Schaukasten im Unternehmen hat eine Funktion, die der digitalen Signatur entspricht. (Foto: R.W. Gerling) Abbildung 17.15: Schematische Darstellung einer digitalen Signatur und ihrer Überprüfung. Abbildung 17.16: Darstellung der Addition zweier Punkt auf einer elliptischen Kurve. Abbildung 17.17: Beim ersten Verbindungsaufbau zu einem SSH-Server muss der Schlüssel (hier per SHA256-Fingerprint) überprüft werden. Meist wird »yes« getippt. Abbildung 17.18: Anforderungen an die Grö   ße von Quantencomputern. Der graue Bereich markiert den Stand der Forschung, die Symbole markieren einzelne Experimente. (Quelle: BSI; Darstellung nach [BSI20a]) Abbildung 18.1: Die Abhängigkeit der False Acceptance Rate (FAR) und der False Rejection Rate (FRR) von einem fiktiven Systemparameter. Abbildung 19.1: Die Chipkartenformate mit Kontaktfeld (von links): ID1, ID-000, Micro-SIM und Nano-SIM. Rechts oben die Kontaktbelegung. Abbildung 19.2: Schematischer Aufbaueiner Speicherchipkarte (a) und einer Prozessorchipkarte (b). Optionale Bausteinesind jeweils gestrichelt dargestellt. Abbildung 19.3: Aus einer Token-abhängigen individuellen Zufallszahl, die bei der Herstellung in den Token geschrieben wird, und einem Zähler wird das Einmalpasswort berechnet. Abbildung 19.4: Aus der Domain des Login-Servers, einer Zufallszahl (Nonce) und dem »Geheimnis« werden das Schlüsselpaar undein MAC in dem U2F-Token berechnet. Abbildung 20.1: Die Darstellung der Datensicherungsarten. a) Vollsicherung; b) Differenzielle Sicherung; c) Inkrementelle Sicherung.

Abbildung 20.2: Schematische Darstellung eines RAID-1- und eines RAID-5-System mit den jeweiligen Datenblöcken ( =A B C, =D E F, =G H I und = XOR). Abbildung 21.1: Der Ablauf der DNS-Auflösung mit normalen DNS (a) und DoT/DoH (b). Abbildung 21.2: Darstellung des Zusammenspiels von Supplicant, Authenticator und Authentication-Server. Abbildung 21.3: Segmentierung eines Netzwerks. Abbildung 21.4: VLAN-Beispiele. Abbildung 22.1: Beispiel für eine Firewall mitvier Sicherheitszonen: Extern, Intern, WLANund Demilitarisierte Zone (DMZ). Abbildung 22.2: Beispielhafte Übersetzungder IP-Adressen mit NAT (zusammengehörende Einträge sind gleich hinterlegt). Abbildung 23.1: Es gibt vier Konzepte, wie Dateien auf einem Datenträger verschlüsselt werden können. Abbildung 23.2: Dialog zum Einrichten der Datenträgerverschlüsselung Bitlocker unter Windows 10. Abbildung 23.3: Schmatische Darstellungder Hardware-Verschlüsselung oder Device Encryption des Flash-Speichers bei iPhone (5s oder neuer) und iPad (Air oder neuer). Abbildung 23.4: Die unterschiedlichen verschlüsselten Datenströme bei einer Ende-zu-Ende-Verschlüsselung (a) undeiner Transportverschlüsselung (b). Abbildung 23.5: Die Verbindung von einem Client zu einem Server (Ziel) über eine SSH-Verbindung. Abbildung 23.6: Der gleichzeitige Aufruf einer Webseite zum Anzeigen der eigenen IP-Adresse mit zwei Browsern auf einem Rechner(hier: Anzeige über Heise Netze/Meine IP-Adresse). Abbildung 23.7: OpenVPN läuft im UserSpace und transportiert Daten zwischeneinem physischen Netzwerk-Interface (Netzwerk-Socket) und

einem TUN Device, das mit einem virtuellen Netzwerkinterface (TUN Socket) verbunden ist. Abbildung 24.1: Ein Spinnennetzdiagramm erlaubt den quantitativen Vergleich mehrerer Messgrö   ßen. Hier, als Beispiel, die Umsetzung der ISO 27002 in einem Unternehmen in den Jahren 2018 und 2020. Abbildung 24.2: Die fehlgeschlagenen SSH-Anmeldeversuche mit der Nutzerin pi auf einem Unix-Server über einen Zeitraum von fünf Jahren. [Ger19] Abbildung 25.1: Die monatliche Zahl der Schwachstellenwarnungen und Updates der Warnungen beim DFN-CERT. (Quelle: DFN-CERT Services GmbH) Abbildung 27.1: Ein Verschlüsselungs-Proxy übernimmt die Ver- und Entschlüsselung der E-Mails. Abbildung 27.2: Die Kommunikationsflüssebei einer Videokonferenz über eine zentrale MCU. Abbildung 27.3: Die Kommunikationsflüssebei einer Videokonferenz über eine zentrale SFU. Abbildung 27.4: Die Kommunikationsflüsse bei einer Videokonferenz ohne eine zentrale Einheit (P2P). Abbildung 27.5: Die verkette Listenstruktur einer Blockchain. Abbildung 27.6: Die Verwendung von Algorithmen und Daten beim Maschinellen Lernen.

Stichwortverzeichnis 3DES 208

A Accountability 42 Address Resolution Protocol 279 AEAD 213, 229 AES 129, 208, 209, 212, 241, 242, 275, 276, 306 Allianz für Cybersicherheit 194 AlphaGo 357 Android 306 Angriffserkennung 55, 61, 84, 189, 322, 323 Angriffserkennungssystem 93, 322–325 Anonymisierung 283, 312 APT28 327 Archivierung 258, 263, 264 Assetmanagement 174 Audit 55 Auftragskontrolle 147 Ausfallsicherheit 146, 265–267 Authenticator 253, 277, 278, 317, 339 Authentifizierung 81, 87, 253, 289, 340 Authentizität 35, 42, 69, 225, 226, 229, 275, 340 Availability siehe Verfügbarkeit Awareness 197, 198

B Backup 41, 52, 136, 143, 147, 173, 257, 307, 308, 352 BDSG 52, 65–67, 73, 131–135, 141, 143, 146–148, 248 Bedienbarkeit 127, 174 Bedrohungsanalyse 169 Belastbarkeit 45, 59, 60, 145 Benutzbarkeit 43 Benutzermanagement 141 Berechtigung 180, 183 Betriebskontinuitäts management,  146 Betriebsrat 142, 222 Bitcoin 356 Bitlocker 50, 305, 306 Bitlocker To Go 308 Blockchain 355, 356 Blockverschlüsselung 209–211 Bluebugging 288 Bluejacking 288 Bluesnarfing 288 Bluetooth 267, 284, 286–288 Braktooth 288 BS7799 95 BSI 27, 36, 44, 51, 52, 54, 55, 194 BSI-Gesetz 36, 38, 47, 49, 52, 54, 55, 81, 82, 85, 90, 92, 94 BSI-ITSiKV 78 BSI-Kritisverordnung 77, 82, 85

Bundesamt für Sicherheit in der Informationstechnik siehe BSI Bundesdatenschutzgesetz siehe BDSG Bundesnetzagentur 52, 54, 55, 93 Bundesverfassungsgericht 68 Bußgeld 52

C Caesar-Chiffre 203 CBC 116, 210, 211, 214, 275, 276 CBC–MAC 222 CCM 213 CDO 156 CERT 158, 159, 194 Chatham House Rule 195 Chatserver 344 Chipkarte 80, 125, 232, 233, 249–252, 304 CIO 156 Ciphertext siehe Geheimtext CISO 156 Cloud-Dienst 298 Cloud-Firewall 299 Common Criteria 95, 251 Common Vulnerability Enumeration 333 Common Vulnerability Scoring System 333 Compliance 44 Computer Emergency Response Team siehe CERT Computerviren 286

Confidentiality siehe Vertraulichkeit Containerverschlüsselung 307, 308 CSIRT 158 Cybersicherheit 35, 38, 39, 76, 77, 81, 84 Cyphersuite 275

D Daktyloskopie 246 Data Encryption Key 304 Data Encryption Standard siehe DES Dateiverschlüsselung 112, 309 Datenkategorien 321 Datenminimierung 114 Datenschutz 44 Datenschutzaufsicht 55 Datenschutzbeauftragte 131, 157, 166, 186, 320 Datenschutzgrundverordnung siehe DS-GVO Datenschutzverletzung 186 Datensicherung 251, 257–264, 326 Datenträgerverschlüsselung 134, 304–306 Datenverschlüsselung 275 Deduplizierung 135, 136 Demilitarisierte Zone siehe DMZ Deming-Kreis 155, 163, 164 Denial of Service siehe DoS

DES 208  66398 145  66399 145 EN 1627 132 DLIES 229 dm-crypt 305, 306 DMZ 294, 298 DoS 288 DS-GVO 47, 50, 52, 54–56, 59, 60, 67, 155, 157, 303 Dual_EC_DRBG 217

E E2E-Verschlüsselung siehe Ende-zu-Ende-Verschlüsselung ECC 117, 227, 229 ECIES 229 eIDAS-Verordnung 43, 79, 80, 232 Eingabekontrolle 141 Einmalpasswort 252, 253, 338 Eintrittswahrscheinlichkeit 49, 49, 59, 60 Einwegverschlüsselung 336 Elliptische-Kurven-Kryptographie siehe ECC Ende-zu-Ende-Verschlüsselung 310, 344, 347, 348 ENISA 38, 77, 198 Erpressung 109 Ethereum 356 Ethernet 270, 279 European Union Agency for Cybersecurity siehe ENISA

Evil-Maid-Angriff 305

F Fachkunde 55, 330 Faktorisierung 240, 241 Fancy Bear siehe APT28 Fernmeldegeheimnis 93 Festplattenverschlüsselung 50, 71 FileVault 2, 305 Fingerabdruck 237, 243, 246, 247 Firewall 132, 175, 191, 276, 291–299, 313 FIRST 194 Forensik 191, 246

G GCM 213 Gefährdungsanalyse 108 Gefährdungspotenzial 55, 89, 93, 322 Geheimschutz 192 Geheimtext 207, 209, 211, 212, 213, 215, 216, 220 Geschäftsgeheimnis 86 Geschäftsgeheimnisgesetz 86 Geschäftsprozess 107 Gesichtserkennung 244, 247, 248, 339, 340 Gewährleistungsziel 74, 114, 141 GnuPG 237, 311

H Hackerangriff 82 Hash 129, 222, 336 Hashfunktion 142, 221, 222, 254, 275, 276, 336 Hashwert 139, 142, 143, 221–223, 225, 230, 251, 330, 336, 355, 356 Hintertür 208 Hybridverschlüsselung 220, 221, 225

I IDEA 208 Identitätsmanagement 157, 180, 184, 341 Implementierungskosten 59, 60, 70, 72 Informationssicherheitsausschuss 159 Informationssicherheitsbeauftragter 155–157, 161, 320 Informationssicherheitsmanagement-System siehe ISMS Informationssicherheitsrichtlinie 128 Initialisierungsvektor 212 Integrity siehe Integrität Integrität 36–38, 41–43, 45, 114, 123, 141, 147, 165–168 Interessenabwägung 264 Intervenierbarkeit 62, 73, 114 Inventarverzeichnis 171, 172 iPad 306 iPhone 306 Iris-Scan 247 ISMS 98, 100–102, 105, 106, 110, 120, 121, 125, 164, 320

ISO 95  900 199  1400 199  2700096–98, 100, 101 IT Infrastructure Library siehe ITIL IT-Grundschutz 101, 115, 119, 125, 175 IT-Sicherheitsbeauftragter 157 IT-Sicherheitsgesetz 75, 81 IT-Sicherheitsgesetz 2.078 IT-Sicherheitskonzept 156 IT-Sicherheitsvorfall 158 ITIL 130, 172 ITSEC 95

K Key Encryption Key 304 Key Performance Indicators 319 Key Wrapping 304 Keylogger 191 Klartext 207, 209, 210, 212, 213, 216, 220–222, 224, 226 Konfigurationsmanagement 178–180 Korrektheit 41, 141, 143, 349 Kreuzreferenztabellen 111 Krisenstab 107 KRITIS 36, 85, 92 Kritische Infrastruktur siehe KRITIS Kryptoanalyse 204

Kryptodebatte 206 Kryptografie 139, 203, 204, 206, 217, 219, 228

L Löschfristen 145 Löschkontrolle 144, 303 Löschprozess 260 Lieferantenbeziehungen 147 Lizenzmanagement 176

M Mallory 215 Malware siehe Schadsoftware Mandantentrennung 135 MD4 222, 223 MD5 222, 223 Meldepflicht 50, 52, 53, 186, 187, 303 Memcached 282 Mindeststandard 86 MISP 195 Missbrauch 71, 108, 109, 112 Missbrauchsrisiko 294

N Nachrichtenschlüssel 344 Nachweispflichten 133

Nameserver 271 National Institute of Standards and Technology siehe NIST Near Field Communication siehe NFC Netzwerkadresse 174 Netzwerkscan 173 Netzwerksicherheit 69 Netzwerkzugang 267, 284 NFC 252, 289 Nichtabstreitbarkeit 43 Nichtverkettbarkeit 73, 135 Nichtverkettung 114 NIS-2-Richtlinie 77, 158 NIS-Richtlinie 38, 47, 53, 60, 75–77, 82 NIST 130, 145, 184, 198, 199, 217, 242, 336, 337 nmap 149 Notfallmanagement 106, 107 Notfallpläne 107 NSA 208

O OATH 253 OFB 211 Once-Only-Prinzip 157 Onlinezugangsgesetz siehe OZG OpenPGP 231, 234–236, 311, 345 Orange Book 95 OZG 87, 88

P Packet Filter 294, 295 Padding 224, 225 Partitionsverschlüsselung 307 Passwort 243, 252, 278, 285, 306–308, 317, 335–340 Passworthash 336 Passwortrichtlinie 335 PDCA-Zyklus 98, 163, 164, 166, 169 Penetrationstest (Pentest) 87, 151, 349 PGP siehe OpenPGP Phishing 199, 328 Post-Quantenkryptografie 242 Prüfsumme 142, 213, 316 Primfaktoren 218, 227 Privatsphäre 272, 276, 284, 287, 289, 296 Protokolldateien 168, 190, 296 Pseudonymisierung 59, 60, 84, 137–139

Q Qualität 44 Quantencomputer 237, 240–242

R RAID 265, 266 Ransomware 40, 186, 258, 261, 326, 327 Rechenschaftspflicht 144

Rechtemanagement 144, 182, 183 Rechtsakt zur Cybersicherheit 77 Redundanz 41, 146, 264 Reifegradmodell 87, 88 Resilienz 44 RFID 249, 289, 290 RIPEMD 222, 223 Risiko 49–52, 59, 60, 67, 72, 78, 89, 97, 101, 189, 233 Risikoanalyse 48, 105, 107, 110 Risikokarte 49 Risikoklasse 49 Risikomanagement 48, 75, 101, 107, 124 Rollenkonzept 114, 180 Rutkowska, Joanna 305

S S/MIME 311, 345 Sabotage 212 Sandbox 328, 329 Schadenshöhe 49, 49, 60 Schadsoftware 40, 41, 128, 186, 292, 293, 296, 326–329, 346 Schlüsselerzeugung 216, 285 Schlüssellänge 208, 209, 227, 241, 275 Schlüsselmanagement 126, 304, 309, 311, 349, 353 Schlüsselpaar 229, 233, 251, 253, 254, 344 Schlüsselstrom 209 Schlüsselvereinbarung 214, 215, 242, 275, 343, 344

Schutzbedarfsanalyse 321 Schutzziele 36, 37, 39, 44, 45, 48, 49, 65, 69, 74, 91, 165–167, 262, 263 Schwachstellenscan 151 Schwachstellenscanner 149 SDG-Verordnung 81 Secure Boot 304 Security Incident and Event Monitoring siehe SIEM SGB V 47, 88 SHA-1 222 SHA-2 222 SHA-3 222, 223 sha1 223 SHA256 222, 223 Sicherheitsüberprüfungsgesetz 192 Sicherheitsarchitektur 277 Sicherheitseinstellungen 44 Sicherheitskonzept 93, 139 Sicherheitsvorfall 52, 77 SIEM 190 Signatur  digitale 43, 79, 142, 143, 225, 234, 243 einfache 79 elektronische 43, 79 fortgeschrittene 79 qualifizierte 80 Signaturerstellungsdaten 79 Signaturerstellungseinheit 80

Single-Sign-on 340 Smartcard 251 Social Engineering 48 Softwareinventarisierung 175 Sozialgesetzbuch V siehe SGB V Speicherchipkarte 251 Spinnennetzdiagramm 320, 321 Spionage 168 Stand der Technik 67 Standard-Datenschutzmodell 113 Stromverschlüsselung 209, 210 Substitutionsverschlüsselung 203

T TCP/IP 268–270 TCSEC 95 Technisch-organisatorische Maßnahmen siehe TOM Telekommunikationsgesetz siehe TKG Telekommunikation-Telemedien-Datenschutzgesetz siehe TTDSG Telematik-Infrastruktur 90 Telemediengesetz siehe TMG TISAX 119, 123 TKG 47, 52, 55, 67, 92–94, 157 TLS 115–117, 129, 140, 149, 213, 272–276, 283, 314, 315 TMG 92–94 TOM 21, 59, 131, 148, 149 TOTP 253

Traffic Light Protocol 193 Transparenz 114 Transport Layer Security siehe TLS Transportverschlüsselung 116, 272, 310, 343, 347, 349, 351 Trennungskontrolle 135 TrueCrypt 305 Trust on First Use 237 TTDSG 67, 92–94

U Umsetzungsplan Bund 82 USV 146

V VeraCrypt 305 Verantwortlichkeit 42, 43, 94 Verbindlichkeit 44 Verfügbarkeit 39–41, 45, 48, 50, 52, 59, 61, 114, 145–147, 166–168 Verfügbarkeitskontrolle 146 Verschlüsselung siehe auch Kryptografie asymmetrische 214 Betriebsarten 210 homomorphe 238 symmetrische 208 Verschlusssache 192 Verschlusssachenanweisung 192 Vertrauensdiensteanbieter 80

Vertraulichkeit 36, 38, 42, 50, 69, 80, 114, 131, 141, 145, 166, 167 Virtual LAN siehe VLAN Virtual Private Network siehe VPN Virus siehe Schadsoftware VLAN 280 VoIP 141 VPN 29, 140, 277, 311, 312, 314 OpenVPN 315 Wireguard 317

W Web of Trust 235 WebSSL 314 Weitergabekontrolle 143 Wireguard 317

Z Zertifizierung 56 Zufallszahlen 139, 212, 217, 220 Zugangskontrolle 133 Zugangssteuerung 133 Zugriffskontrolle 134 Zutrittskontrolle 132 Zuverlässigkeit 44

WILEY END USER LICENSE AGREEMENT Besuchen Sie www.wiley.com/go/eula, um Wiley's E-Book-EULA einzusehen.