+Anwendungen
---+APP.1.1 Office-Produkte
------+APP.1.1.G1 Fehlende Anpassung der Office-Produkte an den Bedarf der Institution
------+APP.1.1.G2 Schädliche Inhalte in Office-Dokumenten
------+APP.1.1.G3 Integritätsverlust von Office-Dokumenten
------+APP.1.1.A2 Einschränken von Aktiven Inhalten (B)
------+APP.1.1.A3 Sicheres Öffnen von Dokumenten aus externen Quellen (B) [Benutzende]
------+APP.1.1.A17 Sensibilisierung zu spezifischen Office-Eigenschaften (B)
------+APP.1.1.A6 Testen neuer Versionen von Office-Produkten (S)
------+APP.1.1.A10 Regelung der Software-Entwicklung durch Endbenutzende (S)
------+APP.1.1.A11 Geregelter Einsatz von Erweiterungen für Office-Produkte (S)
------+APP.1.1.A12 Verzicht auf Cloud-Speicherung (S) [Benutzende]
------+APP.1.1.A13 Verwendung von Viewer-Funktionen (S) [Benutzende]
------+APP.1.1.A14 Schutz gegen nachträgliche Veränderungen von Dokumenten (S) [Benutzende]
------+APP.1.1.A15 Einsatz von Verschlüsselung und Digitalen Signaturen (H)
------+APP.1.1.A16 Integritätsprüfung von Dokumenten (H)
---+APP.1.2 Webbrowser
------+APP.1.2.G1 Ausführung von Schadcode durch Webbrowser
------+APP.1.2.G2 Exploit Kits
------+APP.1.2.G3 Mitlesen der Internetkommunikation
------+APP.1.2.G4 Integritätsverlust in Webbrowsern
------+APP.1.2.G5 Verlust der Privatsphäre
------+APP.1.2.A1 Verwendung von grundlegenden Sicherheitsmechanismen (B)
------+APP.1.2.A2 Unterstützung sicherer Verschlüsselung der Kommunikation (B)
------+APP.1.2.A3 Verwendung von vertrauenswürdigen Zertifikaten (B)
------+APP.1.2.A6 Kennwortmanagement im Webbrowser (B)
------+APP.1.2.A13 Nutzung von DNS-over-HTTPS (B)
------+APP.1.2.A7 Datensparsamkeit in Webbrowsern (S) [Benutzende]
------+APP.1.2.A9 Einsatz einer isolierten Webbrowser-Umgebung (H)
------+APP.1.2.A10 Verwendung des privaten Modus (H) [Benutzende]
------+APP.1.2.A11 Überprüfung auf schädliche Inhalte (H)
------+APP.1.2.A12 Zwei-Browser-Strategie (H)
---+APP.1.4 Mobile Anwendungen (Apps)
------+APP.1.4.G1 Ungeeignete Auswahl von Apps
------+APP.1.4.G2 Zu weitreichende Berechtigungen
------+APP.1.4.G3 Ungewollte Funktionen in Apps
------+APP.1.4.G4 Software-Schwachstellen und Fehler in Apps
------+APP.1.4.G5 Unsichere Speicherung lokaler Anwendungsdaten
------+APP.1.4.G6 Ableitung vertraulicher Informationen aus Metadaten
------+APP.1.4.G7 Abfluss von vertraulichen Daten
------+APP.1.4.G8 Unsichere Kommunikation mit Backend-Systemen
------+APP.1.4.G9 Kommunikationswege außerhalb der Infrastruktur der Institution
------+APP.1.4.A1 Anforderungsanalyse für die Nutzung von Apps (B) [Fachverantwortliche]
------+APP.1.4.A5 Minimierung und Kontrolle von App-Berechtigungen (B) [Fachverantwortliche]
------+APP.1.4.A7 Sichere Speicherung lokaler App-Daten (B)
------+APP.1.4.A8 Verhinderung von Datenabfluss (B)
------+APP.1.4.A3 Verteilung schutzbedürftiger Apps (S)
------+APP.1.4.A12 Sichere Deinstallation von Apps (S)
------+APP.1.4.A14 Unterstützung zusätzlicher Authentisierungsmerkmale bei Apps (H)
------+APP.1.4.A15 Durchführung von Penetrationstests für Apps (H)
------+APP.1.4.A16 Mobile Application Management (H)
---+APP.2.1 Allgemeiner Verzeichnisdienst
------+APP.2.1.G1 Fehlende oder unzureichende Planung des Einsatzes von Verzeichnisdiensten
------+APP.2.1.G2 Fehlerhafte oder unzureichende Planung der Partitionierung und Replizierung im Verzeichnisdienst
------+APP.2.1.G3 Fehlerhafte Administration von Zugangs- und Zugriffsrechten
------+APP.2.1.G4 Fehlerhafte Konfiguration des Zugriffs auf Verzeichnisdienste
------+APP.2.1.G5 Ausfall von Verzeichnisdiensten
------+APP.2.1.G6 Kompromittierung von Verzeichnisdiensten durch unbefugten Zugriff
------+APP.2.1.G7 Fehlerhafte Konfiguration von Verzeichnisdiensten
------+APP.2.1.A1 Erstellung einer Sicherheitsrichtlinie für Verzeichnisdienste (B)
------+APP.2.1.A2 Planung des Einsatzes von Verzeichnisdiensten (B) [Datenschutzbeauftragte, Fachverantwortliche]
------+APP.2.1.A3 Einrichtung von Zugriffsberechtigungen auf Verzeichnisdienste (B) [Fachverantwortliche]
------+APP.2.1.A5 Sichere Konfiguration und Konfigurationsänderungen von Verzeichnisdiensten (B)
------+APP.2.1.A6 Sicherer Betrieb von Verzeichnisdiensten (B)
------+APP.2.1.A17 Absicherung von schutzbedürftigen Anmeldeinformationen (B)
------+APP.2.1.A8 Planung einer Partitionierung im Verzeichnisdienst (S)
------+APP.2.1.A9 Geeignete Auswahl von Komponenten für Verzeichnisdienste (S) [Fachverantwortliche]
------+APP.2.1.A11 Einrichtung des Zugriffs auf Verzeichnisdienste (S)
------+APP.2.1.A12 Überwachung von Verzeichnisdiensten (S)
------+APP.2.1.A13 Absicherung der Kommunikation mit Verzeichnisdiensten (S)
------+APP.2.1.A14 Geregelte Außerbetriebnahme eines Verzeichnisdienstes (S) [Fachverantwortliche]
------+APP.2.1.A15 Migration von Verzeichnisdiensten (S)
------+APP.2.1.A18 Planung einer Replikation im Verzeichnisdienst (S)
------+APP.2.1.A19 Umgang mit anonymen Zugriffen auf Verzeichnisdienste (S)
------+APP.2.1.A16 Erstellung eines Notfallplans für den Ausfall eines Verzeichnisdienstes (H)
------+APP.2.1.A20 Absicherung der Replikation (H)
------+APP.2.1.A21 Hochverfügbarkeit des Verzeichnisdienstes (H)
---+APP.2.2 Active Directory Domain Services
------+APP.2.2.G1 Unzureichende Planung der Sicherheitsgrenzen
------+APP.2.2.G2 Zu viele oder nachlässige Vertrauensbeziehungen
------+APP.2.2.G3 Fehlende Sicherheitsfunktionen durch ältere Betriebssysteme und Domänen- und Gesamtstruktur-Funktionsebenen
------+APP.2.2.G4 Betrieb weiterer Rollen und Dienste auf Domänencontrollern
------+APP.2.2.G5 Unzureichende Überwachung und Dokumentation von delegierten Rechten
------+APP.2.2.G6 Unsichere Authentisierung
------+APP.2.2.G7 Zu mächtige oder schwach gesicherte Konten
------+APP.2.2.G8 Nutzung desselben lokalen Administrierendenpassworts auf mehreren IT-Systemen
------+APP.2.2.G9 Unsichere Speicherung von Passwörtern
------+APP.2.2.G10 Unzureichende Absicherung von Domänencontrollern
------+APP.2.2.G11 Hinterlassen von hochprivilegierten Anmeldeinformationen auf Domänenmitgliedsservern und -clients
------+APP.2.2.G12 Hinzufügen nicht vertrauenswürdiger IT-Systemen zur Windows-Domäne
------+APP.2.2.G13 Vermaschung von administrativen Privilegien durch Integration von weiteren Anwendungen
------+APP.2.2.A1 Planung von Active Directory Domain Services (B) [Fachverantwortliche]
------+APP.2.2.A3 Planung der Gruppenrichtlinien unter Windows (B)
------+APP.2.2.A5 Absicherung des Domänencontrollers (B)
------+APP.2.2.A6 Sichere Konfiguration von Vertrauensbeziehungen (B)
------+APP.2.2.A7 Umsetzung sicherer Verwaltungsmethoden für Active Directory (B) [Fachverantwortliche]
------+APP.2.2.A16 Härtung der AD-DS-Konten (B)
------+APP.2.2.A17 Anmelderestriktionen für hochprivilegierte Konten der Gesamtstruktur auf Clients und Servern (B)
------+APP.2.2.A18 Einschränken des Hinzufügens neuer Computer-Objekte zur Domäne (B)
------+APP.2.2.A8 Absicherung des „Sicheren Kanals“ (S)
------+APP.2.2.A9 Schutz der Authentisierung beim Einsatz von AD DS (S)
------+APP.2.2.A12 Datensicherung für Domänencontroller (S)
------+APP.2.2.A15 Auslagerung der Administration in eine eigene Gesamtstruktur (H)
------+APP.2.2.A19 Betrieb von virtualisierten Domänencontrollern (H)
------+APP.2.2.A20 Trennung von Organisationseinheiten (H)
------+APP.2.2.A21 Konfiguration eines Schichtenmodells (H)
------+APP.2.2.A22 Zeitlich befristete Berechtigungen für die Administration (H)
------+APP.2.2.A23 Regelmäßige Analyse von Berechtigungen und resultierenden Angriffspfaden (H)
---+APP.2.3 OpenLDAP
------+APP.2.3.G1 Fehlende oder unzureichende Planung von OpenLDAP
------+APP.2.3.G2 Unzureichende Trennung von Offline- und Online-Zugriffen auf OpenLDAP
------+APP.2.3.A1 Planung und Auswahl von Backends und Overlays für OpenLDAP (B)
------+APP.2.3.A3 Sichere Konfiguration von OpenLDAP (B)
------+APP.2.3.A4 Konfiguration der durch OpenLDAP verwendeten Datenbank (B)
------+APP.2.3.A5 Sichere Vergabe von Zugriffsrechten auf dem OpenLDAP (B)
------+APP.2.3.A6 Sichere Authentisierung gegenüber OpenLDAP (B)
------+APP.2.3.A8 Einschränkungen von Attributen bei OpenLDAP (S)
------+APP.2.3.A9 Partitionierung und Replikation bei OpenLDAP (S)
------+APP.2.3.A10 Sichere Aktualisierung von OpenLDAP (S)
------+APP.2.3.A11 Einschränkung der OpenLDAP-Laufzeitumgebung (S)
---+APP.3.1 Webanwendungen und Webservices
------+APP.3.1.G1 Unzureichende Protokollierung von sicherheitsrelevanten Ereignissen
------+APP.3.1.G2 Offenlegung sicherheitsrelevanter Informationen bei Webanwendungen und Webservices
------+APP.3.1.G3 Missbrauch einer Webanwendung durch automatisierte Nutzung
------+APP.3.1.G4 Unzureichende Authentisierung
------+APP.3.1.A1 Authentisierung (B)
------+APP.3.1.A4 Kontrolliertes Einbinden von Dateien und Inhalten (B)
------+APP.3.1.A7 Schutz vor unerlaubter automatisierter Nutzung (B)
------+APP.3.1.A14 Schutz vertraulicher Daten (B)
------+APP.3.1.A8 Systemarchitektur (S) [Beschaffungsstelle]
------+APP.3.1.A9 Beschaffung von Webanwendungen und Webservices (S)
------+APP.3.1.A11 Sichere Anbindung von Hintergrundsystemen (S)
------+APP.3.1.A12 Sichere Konfiguration (S)
------+APP.3.1.A21 Sichere HTTP-Konfiguration bei Webanwendungen (S)
------+APP.3.1.A22 Penetrationstest und Revision (S)
------+APP.3.1.A20 Einsatz von Web Application Firewalls (H)
---+APP.3.2 Webserver
------+APP.3.2.G1 Reputationsverlust
------+APP.3.2.G2 Manipulation des Webservers
------+APP.3.2.G3 Denial of Service (DoS)
------+APP.3.2.G4 Verlust vertraulicher Daten
------+APP.3.2.G5 Verstoß gegen Gesetze oder Regelungen
------+APP.3.2.G6 Fehlende oder mangelhafte Fehlerbehebung
------+APP.3.2.A1 Sichere Konfiguration eines Webservers (B)
------+APP.3.2.A2 Schutz der Webserver-Dateien (B)
------+APP.3.2.A3 Absicherung von Datei-Uploads und -Downloads (B)
------+APP.3.2.A4 Protokollierung von Ereignissen (B)
------+APP.3.2.A5 Authentisierung (B)
------+APP.3.2.A7 Rechtliche Rahmenbedingungen für Webangebote (B) [Fachverantwortliche, Zentrale Verwaltung, Compliance-Beauftragte]
------+APP.3.2.A11 Verschlüsselung über TLS (B)
------+APP.3.2.A8 Planung des Einsatzes eines Webservers (S)
------+APP.3.2.A9 Festlegung einer Sicherheitsrichtlinie für den Webserver (S)
------+APP.3.2.A10 Auswahl eines geeigneten Webhosters (S)
------+APP.3.2.A12 Geeigneter Umgang mit Fehlern und Fehlermeldungen (S)
------+APP.3.2.A13 Zugriffskontrolle für Webcrawler (S)
------+APP.3.2.A14 Integritätsprüfungen und Schutz vor Schadsoftware (S)
------+APP.3.2.A16 Penetrationstest und Revision (S)
------+APP.3.2.A20 Benennung von Anzusprechenden (S) [Zentrale Verwaltung]
------+APP.3.2.A15 Redundanz (H)
------+APP.3.2.A18 Schutz vor Denial-of-Service-Angriffen (H)
---+APP.3.3 Fileserver
------+APP.3.3.G1 Ausfall eines Fileservers
------+APP.3.3.G2 Unzureichende Dimensionierung des Fileservers
------+APP.3.3.G3 Unzureichende Überprüfung von abgelegten Dateien
------+APP.3.3.G4 Fehlendes oder unzureichendes Zugriffsberechtigungskonzept
------+APP.3.3.G5 Unstrukturierte Datenhaltung
------+APP.3.3.G6 Verlust von auf Fileservern abgespeicherten Daten
------+APP.3.3.G7 Ransomware
------+APP.3.3.A2 Einsatz von RAID-Systemen (B)
------+APP.3.3.A3 Einsatz von Viren-Schutzprogrammen (B)
------+APP.3.3.A15 Planung von Fileservern (B)
------+APP.3.3.A6 Beschaffung eines Fileservers und Auswahl eines Dienstes (S)
------+APP.3.3.A7 Auswahl eines Dateisystems (S)
------+APP.3.3.A8 Strukturierte Datenhaltung (S) [Benutzende]
------+APP.3.3.A9 Sicheres Speichermanagement (S)
------+APP.3.3.A11 Einsatz von Speicherbeschränkungen (S)
------+APP.3.3.A14 Einsatz von Error-Correction-Codes (S)
------+APP.3.3.A12 Verschlüsselung des Datenbestandes (H)
------+APP.3.3.A13 Replikation zwischen Standorten (H)
---+APP.3.4 Samba
------+APP.3.4.G1 Abhören ungeschützter Kommunikationsverbindungen von Samba
------+APP.3.4.G2 Unsichere Standardeinstellungen auf Samba-Servern
------+APP.3.4.G3 Unberechtigte Nutzung oder Administration von Samba
------+APP.3.4.G4 Fehlerhafte Administration von Samba
------+APP.3.4.G5 Datenverlust bei Samba
------+APP.3.4.G6 Integritätsverlust schützenswerter Informationen bei Samba
------+APP.3.4.A1 Planung des Einsatzes eines Samba-Servers (B)
------+APP.3.4.A2 Sichere Grundkonfiguration eines Samba-Servers (B)
------+APP.3.4.A3 Sichere Konfiguration eines Samba-Servers (S)
------+APP.3.4.A4 Vermeidung der NTFS-Eigenschaften auf einem Samba-Server (S)
------+APP.3.4.A5 Sichere Konfiguration der Zugriffssteuerung bei einem Samba-Server (S)
------+APP.3.4.A6 Sichere Konfiguration von Winbind unter Samba (S)
------+APP.3.4.A7 Sichere Konfiguration von DNS unter Samba (S)
------+APP.3.4.A8 Sichere Konfiguration von LDAP unter Samba (S)
------+APP.3.4.A9 Sichere Konfiguration von Kerberos unter Samba (S)
------+APP.3.4.A10 Sicherer Einsatz externer Programme auf einem Samba-Server (S)
------+APP.3.4.A12 Schulung der Administrierenden eines Samba-Servers (S)
------+APP.3.4.A13 Regelmäßige Sicherung wichtiger Systemkomponenten eines Samba-Servers (S)
------+APP.3.4.A15 Verschlüsselung der Datenpakete unter Samba (H)
---+APP.3.6 DNS-Server
------+APP.3.6.G1 Ausfall des DNS-Servers
------+APP.3.6.G2 Unzureichende Leitungskapazitäten
------+APP.3.6.G3 Fehlende oder unzureichende Planung des DNS-Einsatzes
------+APP.3.6.G4 Fehlerhafte Domain-Informationen
------+APP.3.6.G5 Fehlerhafte Konfiguration eines DNS-Servers
------+APP.3.6.G6 DNS-Manipulation
------+APP.3.6.G7 DNS-Hijacking
------+APP.3.6.G8 DNS-DoS
------+APP.3.6.G9 DNS-Reflection
------+APP.3.6.A1 Planung des DNS-Einsatzes (B)
------+APP.3.6.A2 Einsatz redundanter DNS-Server (B)
------+APP.3.6.A3 Verwendung von separaten DNS-Servern für interne und externe Anfragen (B)
------+APP.3.6.A4 Sichere Grundkonfiguration eines DNS-Servers (B)
------+APP.3.6.A6 Absicherung von dynamischen DNS-Updates (B)
------+APP.3.6.A7 Überwachung von DNS-Servern (B)
------+APP.3.6.A8 Verwaltung von Domainnamen (B) [Zentrale Verwaltung]
------+APP.3.6.A9 Erstellen eines Notfallplans für DNS-Server (B)
------+APP.3.6.A10 Auswahl eines geeigneten DNS-Server-Produktes (S)
------+APP.3.6.A11 Ausreichende Dimensionierung der DNS-Server (S)
------+APP.3.6.A13 Einschränkung der Sichtbarkeit von Domain-Informationen (S)
------+APP.3.6.A14 Platzierung der Nameserver (S)
------+APP.3.6.A15 Auswertung der Logdaten (S)
------+APP.3.6.A16 Integration eines DNS-Servers in eine "P-A-P"-Struktur (S)
------+APP.3.6.A17 Einsatz von DNSSEC (S)
------+APP.3.6.A18 Erweiterte Absicherung von Zonentransfers (S)
------+APP.3.6.A19 Aussonderung von DNS-Servern (S)
------+APP.3.6.A20 Prüfung des Notfallplans auf Durchführbarkeit (H)
------+APP.3.6.A21 Hidden Master (H)
------+APP.3.6.A22 Anbindung der DNS-Server über unterschiedliche Provider (H)
---+APP.4.2 SAP-ERP-System
------+APP.4.2.G1 Fehlende Berücksichtigung der Sicherheitsempfehlungen von SAP
------+APP.4.2.G2 Fehlendes oder nicht zeitnahes Einspielen von Patches und SAP-Sicherheitshinweisen
------+APP.4.2.G3 Mangelnde Planung, Umsetzung und Dokumentation eines SAP-Berechtigungskonzeptes
------+APP.4.2.G4 Fehlende SAP-Dokumentation und fehlende Notfallkonzepte
------+APP.4.2.A1 Sichere Konfiguration des SAP-ABAP-Stacks (B)
------+APP.4.2.A2 Sichere Konfiguration des SAP-JAVA-Stacks (B)
------+APP.4.2.A3 Netzsicherheit (B)
------+APP.4.2.A4 Absicherung der ausgelieferten SAP-Standard-Konten (B)
------+APP.4.2.A5 Konfiguration und Absicherung der SAP-Konten-Verwaltung (B)
------+APP.4.2.A6 Erstellung und Umsetzung eines Konten- und Berechtigungskonzeptes (B) [Fachabteilung, Entwickelnde]
------+APP.4.2.A7 Absicherung der SAP-Datenbanken (B)
------+APP.4.2.A8 Absicherung der SAP-RFC-Schnittstelle (B)
------+APP.4.2.A9 Absicherung und Überwachung des Message-Servers (B)
------+APP.4.2.A11 Sichere Installation eines SAP-ERP-Systems (S)
------+APP.4.2.A12 SAP-Berechtigungsentwicklung (S) [Fachabteilung, Entwickelnde]
------+APP.4.2.A13 SAP-Passwortsicherheit (S)
------+APP.4.2.A14 Identifizierung kritischer SAP-Berechtigungen (S) [Fachabteilung]
------+APP.4.2.A15 Sichere Konfiguration des SAP-Routers (S)
------+APP.4.2.A16 Umsetzung von Sicherheitsanforderungen für das Betriebssystem Windows (S)
------+APP.4.2.A17 Umsetzung von Sicherheitsanforderungen für das Betriebssystem Unix (S)
------+APP.4.2.A18 Abschaltung von unsicherer Kommunikation (S)
------+APP.4.2.A19 Definition der Sicherheitsrichtlinien für Konten (S)
------+APP.4.2.A20 Sichere SAP-GUI-Einstellungen (S)
------+APP.4.2.A22 Schutz des Spools im SAP-ERP-System (S) [Entwickelnde]
------+APP.4.2.A23 Schutz der SAP-Hintergrundverarbeitung (S) [Entwickelnde]
------+APP.4.2.A24 Aktivierung und Absicherung des Internet Communication Frameworks (S)
------+APP.4.2.A25 Sichere Konfiguration des SAP Web Dispatchers (S)
------+APP.4.2.A26 Schutz von selbstentwickeltem Code im SAP-ERP-System (S)
------+APP.4.2.A27 Audit des SAP-ERP-Systems (S) [Fachabteilung]
------+APP.4.2.A28 Erstellung eines Notfallkonzeptes (S) [Notfallbeauftragte]
------+APP.4.2.A29 Einrichten von Notfall-Konten (S)
------+APP.4.2.A30 Implementierung eines kontinuierlichen Monitorings der Sicherheitseinstellungen (S)
------+APP.4.2.A31 Konfiguration von SAP Single-Sign-On (S)
------+APP.4.2.A32 Echtzeiterfassung und Alarmierung von irregulären Vorgängen (H)
---+APP.4.3 Relationale Datenbanken
------+APP.4.3.G1 Unzureichende Dimensionierung der Systemressourcen
------+APP.4.3.G2 Aktivierte Standard-Konten
------+APP.4.3.G3 Unverschlüsselte Datenbankanbindung
------+APP.4.3.G4 Datenverlust in der Datenbank
------+APP.4.3.G5 Integritätsverlust der gespeicherten Daten
------+APP.4.3.G6 SQL-Injections
------+APP.4.3.G7 Unsichere Konfiguration des Datenbankmanagementsystems
------+APP.4.3.G8 Malware und unsichere Datenbank-Skripte
------+APP.4.3.A1 Erstellung einer Sicherheitsrichtlinie für Datenbanksysteme (B)
------+APP.4.3.A3 Basishärtung des Datenbankmanagementsystems (B)
------+APP.4.3.A4 Geregeltes Anlegen neuer Datenbanken (B)
------+APP.4.3.A9 Datensicherung eines Datenbanksystems (B)
------+APP.4.3.A11 Ausreichende Dimensionierung der Hardware (S) [Fachverantwortliche]
------+APP.4.3.A12 Einheitlicher Konfigurationsstandard von Datenbankmanagementsystemen (S)
------+APP.4.3.A13 Restriktive Handhabung von Datenbank-Links (S)
------+APP.4.3.A16 Verschlüsselung der Datenbankanbindung (S)
------+APP.4.3.A17 Datenübernahme oder Migration (S) [Fachverantwortliche]
------+APP.4.3.A18 Überwachung des Datenbankmanagementsystems (S)
------+APP.4.3.A19 Schutz vor schädlichen Datenbank-Skripten (S) [Entwickelnde]
------+APP.4.3.A20 Regelmäßige Audits (S)
------+APP.4.3.A21 Einsatz von Datenbank Security Tools (H)
------+APP.4.3.A22 Notfallvorsorge (H)
------+APP.4.3.A23 Archivierung (H)
------+APP.4.3.A24 Datenverschlüsselung in der Datenbank (H)
------+APP.4.3.A25 Sicherheitsprüfungen von Datenbanksystemen (H)
---+APP.4.4 Kubernetes
------+APP.4.4.G1 Mangelhafte Authentisierung und Autorisierung in der Control Plane
------+APP.4.4.G2 Vertraulichkeitsverlust von Zugangsdaten
------+APP.4.4.G3 Ressourcenkonflikte auf Nodes
------+APP.4.4.G4 Unautorisierte Änderungen an Clustern
------+APP.4.4.G5 Unberechtigte Kommunikation
------+APP.4.4.A1 Planung der Separierung der Anwendungen (B)
------+APP.4.4.A2 Planung der Automatisierung mit CI/CD (B)
------+APP.4.4.A3 Identitäts- und Berechtigungsmanagement bei Kubernetes (B)
------+APP.4.4.A4 Separierung von Pods (B)
------+APP.4.4.A5 Datensicherung im Cluster (B)
------+APP.4.4.A6 Initialisierung von Pods (S)
------+APP.4.4.A7 Separierung der Netze bei Kubernetes (S)
------+APP.4.4.A8 Absicherung von Konfigurationsdateien bei Kubernetes (S)
------+APP.4.4.A9 Nutzung von Kubernetes Service-Accounts (S)
------+APP.4.4.A10 Absicherung von Prozessen der Automatisierung (S)
------+APP.4.4.A11 Überwachung der Container (S)
------+APP.4.4.A12 Absicherung der Infrastruktur-Anwendungen (S)
------+APP.4.4.A13 Automatisierte Auditierung der Konfiguration (H)
------+APP.4.4.A14 Verwendung dedizierter Nodes (H)
------+APP.4.4.A15 Trennung von Anwendungen auf Node- und Cluster-Ebene (H)
------+APP.4.4.A16 Verwendung von Operatoren (H)
------+APP.4.4.A17 Attestierung von Nodes (H)
------+APP.4.4.A18 Verwendung von Mikro-Segmentierung (H)
------+APP.4.4.A19 Hochverfügbarkeit von Kubernetes (H)
------+APP.4.4.A20 Verschlüsselte Datenhaltung bei Pods (H)
------+APP.4.4.A21 Regelmäßiger Restart von Pods (H)
---+APP.4.6 SAP ABAP-Programmierung
------+APP.4.6.G1 Fehlende Berechtigungsprüfungen
------+APP.4.6.G2 Verlust von Vertraulichkeit oder Integrität von kritischen Daten
------+APP.4.6.G3 Injection-Schwachstellen
------+APP.4.6.G4 Umgehung von vorhandenen SAP-Sicherheitsmechanismen
------+APP.4.6.A1 Absicherung von Reports mit Berechtigungsprüfungen (B)
------+APP.4.6.A2 Formal korrekte Auswertung von Berechtigungsprüfungen (B)
------+APP.4.6.A3 Berechtigungsprüfung vor dem Start einer Transaktion (B)
------+APP.4.6.A4 Verzicht auf proprietäre Berechtigungsprüfungen (B)
------+APP.4.6.A5 Erstellung einer Richtlinie für die ABAP-Entwicklung (S)
------+APP.4.6.A6 Vollständige Ausführung von Berechtigungsprüfungen (S)
------+APP.4.6.A7 Berechtigungsprüfung während der Eingabeverarbeitung (S)
------+APP.4.6.A8 Schutz vor unberechtigten oder manipulierenden Zugriffen auf das Dateisystem (S)
------+APP.4.6.A9 Berechtigungsprüfung in remote-fähigen Funktionsbausteinen (S)
------+APP.4.6.A10 Verhinderung der Ausführung von Betriebssystemkommandos (S)
------+APP.4.6.A11 Vermeidung von eingeschleustem Schadcode (S)
------+APP.4.6.A12 Vermeidung von generischer Modulausführung (S)
------+APP.4.6.A13 Vermeidung von generischem Zugriff auf Tabelleninhalte (S)
------+APP.4.6.A14 Vermeidung von nativen SQL-Anweisungen (S)
------+APP.4.6.A15 Vermeidung von Datenlecks (S)
------+APP.4.6.A16 Verzicht auf systemabhängige Funktionsausführung (S)
------+APP.4.6.A17 Verzicht auf mandantenabhängige Funktionsausführung (S)
------+APP.4.6.A18 Vermeidung von Open-SQL-Injection-Schwachstellen (S)
------+APP.4.6.A19 Schutz vor Cross-Site-Scripting (S)
------+APP.4.6.A20 Keine Zugriffe auf Daten eines anderen Mandanten (S)
------+APP.4.6.A21 Verbot von verstecktem ABAP-Quelltext (S)
------+APP.4.6.A22 Einsatz von ABAP-Codeanalyse Werkzeugen (H)
---+APP.5.2 Microsoft Exchange und Outlook
------+APP.5.2.G1 Fehlende oder unzureichende Regelungen für Exchange und Outlook
------+APP.5.2.G2 Fehlerhafte Migration von Exchange
------+APP.5.2.G3 Unzulässiger Browserzugriff auf Exchange
------+APP.5.2.G4 Unerlaubte Anbindung anderer Systeme an Exchange
------+APP.5.2.G5 Fehlerhafte Administration von Zugangs- und Zugriffsrechten unter Exchange und Outlook
------+APP.5.2.G6 Fehlerhafte Konfiguration von Exchange
------+APP.5.2.G7 Fehlerhafte Konfiguration von Outlook
------+APP.5.2.G8 Fehlfunktionen und Missbrauch selbst entwickelter Makros sowie Programmierschnittstellen unter Outlook
------+APP.5.2.A1 Planung des Einsatzes von Exchange und Outlook (B)
------+APP.5.2.A2 Auswahl einer geeigneten Exchange-Infrastruktur (B)
------+APP.5.2.A3 Berechtigungsmanagement und Zugriffsrechte (B)
------+APP.5.2.A5 Datensicherung von Exchange (B)
------+APP.5.2.A7 Migration von Exchange-Systemen (S)
------+APP.5.2.A9 Sichere Konfiguration von Exchange-Servern (S)
------+APP.5.2.A10 Sichere Konfiguration von Outlook (S)
------+APP.5.2.A11 Absicherung der Kommunikation zwischen Exchange-Systemen (S)
------+APP.5.2.A12 Einsatz von Outlook Anywhere, MAPI over HTTP und Outlook im Web (S)
------+APP.5.2.A17 Verschlüsselung von Exchange-Datenbankdateien (H)
---+APP.5.3 Allgemeiner E-Mail-Client und -Server
------+APP.5.3.G1 Unzureichende Planung der E-Mail-Nutzung
------+APP.5.3.G2 Fehlerhafte Einstellung von E-Mail-Clients und -Servern
------+APP.5.3.G3 Unzuverlässigkeit von E-Mail
------+APP.5.3.G4 Schadsoftware in E-Mails
------+APP.5.3.G5 Social Engineering
------+APP.5.3.G6 Mitlesen und Manipulieren von E-Mails
------+APP.5.3.A1 Sichere Konfiguration der E-Mail-Clients (B)
------+APP.5.3.A2 Sicherer Betrieb von E-Mail-Servern (B)
------+APP.5.3.A3 Datensicherung und Archivierung von E-Mails (B)
------+APP.5.3.A4 Spam- und Virenschutz auf dem E-Mail-Server (B)
------+APP.5.3.A5 Festlegung von Vertretungsregelungen bei E-Mail-Nutzung (S) [Vorgesetzte]
------+APP.5.3.A6 Festlegung einer Sicherheitsrichtlinie für E-Mail (S)
------+APP.5.3.A7 Schulung zu Sicherheitsmechanismen von E-Mail-Clients für Benutzende (S)
------+APP.5.3.A8 Umgang mit Spam durch Benutzende (S) [Benutzende]
------+APP.5.3.A9 Erweiterte Sicherheitsmaßnahmen auf dem E-Mail-Server (S)
------+APP.5.3.A10 Ende-zu-Ende-Verschlüsselung und Signatur (H)
------+APP.5.3.A11 Einsatz redundanter E-Mail-Server (H)
------+APP.5.3.A12 Überwachung öffentlicher Block-Listen (H)
------+APP.5.3.A13 TLS-Reporting (H)
---+APP.5.4 Unified Communications und Collaboration (UCC)
------+APP.5.4.G1 Eingeschränkte Verfügbarkeit von UCC-Diensten
------+APP.5.4.G2 Unzureichende Planung von UCC
------+APP.5.4.G3 Fehlerhafte Konfiguration von UCC
------+APP.5.4.G4 Unbefugte oder missbräuchliche Benutzung der Administrationsrechte eines UCC-Dienstes
------+APP.5.4.G5 Preisgabe von schützenswerten Informationen
------+APP.5.4.G6 Preisgabe von personenbezogenen Informationen
------+APP.5.4.G7 Wechselwirkungen bei UCC-Diensten
------+APP.5.4.G8 Zugriff auf Applikationen oder Ressourcen durch Freigabe der Steuerung
------+APP.5.4.G9 Vorspiegelung falscher Identitäten
------+APP.5.4.A1 Planung von UCC (B)
------+APP.5.4.A2 Berücksichtigung von UCC in der Netzplanung (B)
------+APP.5.4.A3 Initiales und regelmäßiges Testen der UCC-Dienste (B)
------+APP.5.4.A4 Deaktivierung nicht benötigter Funktionen und Dienste (B)
------+APP.5.4.A5 Rollen- und Berechtigungskonzept für UCC (B)
------+APP.5.4.A6 Verschlüsselung von UCC-Daten (B)
------+APP.5.4.A7 Regelungen für eine sichere Benutzung der UCC-Dienste (B)
------+APP.5.4.A8 Einsatz eines Session Border Controller am Provider-Übergang (S)
------+APP.5.4.A9 Sichere Konfiguration von UCC (S)
------+APP.5.4.A10 Absicherung und Einschränkung von Auswertungen von Inhalten (S)
------+APP.5.4.A11 Sicherstellung der Verfügbarkeit von Kommunikationsdiensten (H)
------+APP.5.4.A12 Einbindung von UCC in die Notfallplanung (H)
------+APP.5.4.A13 Sichere Administration von SIP-Trunks (H)
------+APP.5.4.A14 Ende-zu-Ende-Verschlüsselung (H)
------+APP.5.4.A15 Einschränkung von KI-Funktionen (H)
------+APP.5.4.A16 Einsatz eines SBC an weiteren Netzübergängen (H)
------+APP.5.4.A17 Einschränkung der Benutzung von UCC-Diensten (H)
------+APP.5.4.A18 Einbindung von UCC in ein Sicherheitsmonitoring (H)
---+APP.6 Allgemeine Software
------+APP.6.G1 Ungeeignete Auswahl von Software
------+APP.6.G2 Offenlegung schützenswerter Informationen durch fehlerhafte Konfiguration
------+APP.6.G3 Bezug von Software aus unzuverlässiger Quelle
------+APP.6.G4 Sicherheitslücken durch mangelhafte Wartung
------+APP.6.G5 Datenverlust durch fehlerhafte Nutzung von Software
------+APP.6.G6 Mangelhafte Ressourcen für die Ausführung von Software
------+APP.6.G7 Nichtbeachtung von Anforderungen der Benutzenden
------+APP.6.A1 Planung des Software-Einsatzes (B) [Fachverantwortliche]
------+APP.6.A2 Erstellung eines Anforderungskatalogs für Software (B) [Fachverantwortliche]
------+APP.6.A3 Sichere Beschaffung von Software (B) [Beschaffungsstelle]
------+APP.6.A4 Regelung für die Installation und Konfiguration von Software (B) [Fachverantwortliche]
------+APP.6.A5 Sichere Installation von Software (B)
------+APP.6.A6 Berücksichtigung empfohlener Sicherheitsanforderungen (S)
------+APP.6.A7 Auswahl und Bewertung potentieller Software (S) [Fachverantwortliche, Beschaffungsstelle]
------+APP.6.A8 Regelung zur Verfügbarkeit der Installationsdateien (S)
------+APP.6.A9 Inventarisierung von Software (S)
------+APP.6.A10 Erstellung einer Sicherheitsrichtlinie für den Einsatz der Software (S)
------+APP.6.A11 Verwendung von Plug-ins und Erweiterungen (S)
------+APP.6.A12 Geregelte Außerbetriebnahme von Software (S) [Fachverantwortliche]
------+APP.6.A13 Deinstallation von Software (S)
------+APP.6.A14 Nutzung zertifizierter Software (H)
---+APP.7 Entwicklung von Individualsoftware
------+APP.7.G1 Unzulängliche vertragliche Regelungen mit externen Dienstleistenden
------+APP.7.G2 Software-Konzeptionsfehler
------+APP.7.G3 Undokumentierte Funktionen
------+APP.7.G4 Fehlende oder unzureichende Sicherheitsmaßnahmen in Anwendungen
------+APP.7.G5 Mangelhafte Steuerung der Software-Entwicklung
------+APP.7.G6 Beauftragung ungeeigneter Software-Entwickelnder
------+APP.7.A1 Erweiterung der Planung des Software-Einsatzes um Aspekte von Individualsoftware (B)
------+APP.7.A2 Festlegung von Sicherheitsanforderungen an den Prozess der Software-Entwicklung (B)
------+APP.7.A3 Festlegung der Sicherheitsfunktionen zur Systemintegration (B) [IT-Betrieb]
------+APP.7.A4 Anforderungsgerechte Beauftragung (B) [Beschaffungsstelle]
------+APP.7.A5 Geeignete Steuerung der Anwendungsentwicklung (S)
------+APP.7.A6 Dokumentation der Anforderungen an die Individualsoftware (S)
------+APP.7.A7 Sichere Beschaffung von Individualsoftware (S)
------+APP.7.A8 Frühzeitige Beteiligung der Fachverantwortlichen bei entwicklungsbegleitenden Software-Tests (S)
------+APP.7.A9 Treuhänderische Hinterlegung (H)
------+APP.7.A10 Beauftragung zertifizierter Software-Entwicklungsunternehmen (H)

Anwendungen

Die Schicht APP beschäftigt sich mit der Absicherung von Anwendungen und Diensten, unter anderem in den Bereichen Kommunikation, Verzeichnisdienste, netzbasierte Dienste sowie Business- und Client-Anwendungen. Typische Bausteine der Schicht APP sind Allgemeiner E-Mail-Client und -Server, Office-Produkte, Webserver und Relationale Datenbanken.

1. Oversigt

APP.1.1 Office-Produkte

Einleitung

Die Gruppe der Office-Produkte umfasst in erster Linie Anwendungen, die dazu dienen, Dokumente zu erstellen, zu bearbeiten oder zu betrachten. Dazu zählen unter anderem die freie Anwendung LibreOffice und die proprietäre Anwendung Microsoft Office, die in vielen Institutionen genutzt werden. Office-Produkte gehören für die meisten Institutionen zur notwendigen IT-Grundausstattung. Sie umfassen unter anderem Programme zur Textverarbeitung, Tabellenkalkulation und Erstellung von Präsentationen sowie Zeichenprogramme und einfache Datenbanksysteme.

Zielsetzung

Ziel des vorliegenden Bausteins ist der Schutz der Informationen, die durch Office-Produkte verarbeitet und genutzt werden. Dazu werden spezielle Anforderungen an die Funktionsweise der Komponenten von Office-Produkten gestellt. Der Baustein zeigt Anforderungen auf, die zur Absicherung von Office-Produkten vor spezifischen Gefährdungen erfüllt werden sollten.

Abgrenzung und Modellierung

Der Baustein APP.1.1 Office-Produkte ist auf jedes Office-Produkt anzuwenden, das lokal installiert ist und mit dem Dokumente betrachtet, bearbeitet oder erstellt werden, außer E-Mail-Anwendungen.

Dieser Baustein betrachtet den Einsatz von Office-Produkten aus Sicht des IT-Betriebs und gibt Hinweise für Benutzende, wie Office-Produkte eingesetzt werden sollten. Ergänzend zu den Anforderungen dieses Bausteins müssen die Anforderungen des übergeordneten Bausteins APP.6 Allgemeine Software umgesetzt werden. E-Mail-Anwendungen werden in diesem Baustein nicht berücksichtigt, die entsprechenden Anforderungen sind im Baustein APP.5.3 Allgemeiner E-Mail-Client und -Server zu finden. Bei der Verwendung von integrierten Datenbanksystemen wie Base in LibreOffice oder Access in Microsoft Office muss der Baustein APP.4.3 Relationale Datenbanken berücksichtigt werden. Ebenfalls im vorliegenden Baustein ausgenommen sind reine Cloud-Office-Anwendungen wie Google Workspace mit den Anwendungen Docs oder Sheets. Anforderungen an Cloud-Anwendungen sind in dem Baustein OPS.2.2 Cloud-Nutzung festgelegt.

Wissenswertes

Das BSI hat in den „BSI-Veröffentlichungen zur Cyber-Sicherheit“ folgende Dokumente zur sicheren Konfiguration von Office Produkten veröffentlicht:

  • BSI-CS 135: Sichere Konfiguration von Microsoft Office 2013/2016/2019
  • BSI-CS 136: Sichere Konfiguration von Microsoft Excel 2013/2016/2019
  • BSI-CS 137: Sichere Konfiguration von Microsoft PowerPoint 2013/2016/2019
  • BSI-CS 138: Sichere Konfiguration von Microsoft Word 2013/2016/2019
  • BSI-CS 139: Sichere Konfiguration von Microsoft Outlook 2013/2016/2019
  • BSI-CS 140: Sichere Konfiguration von Microsoft Access 2013/2016/2019
  • BSI-CS 141: Sichere Konfiguration von Microsoft Visio 2013/2016/2019
  • BSI-CS 146: Sichere Konfiguration von Libre Office - Empfehlungen für Unternehmen mit einer verwalteten Umgebung
  • BSI-CS 147: Sichere Konfiguration von Libre Office - Empfehlungen für Privatanwender und Privatanwenderinnen, kleine Unternehmen

Die International Organization for Standardization (ISO) gibt in der Norm ISO/IEC 27001:2013 im Annex A, A.9.4 System and application access control & A.12.5 Control of operational Software Vorgaben, die auf den Betrieb von Office-Produkten zutreffen.
APP.1.2 Webbrowser

Einleitung

Webbrowser sind Anwendungsprogramme, die (Hypertext-) Dokumente, Bilder, Video-, Audio- und andere Datenformate aus dem Internet abrufen, verarbeiten, darstellen, ausgeben und auf lokalen IT-Systemen speichern können. Ebenso können Webbrowser auch Daten ins Internet übertragen.

Stationäre und mobile Clients sind heute ohne Webbrowser nicht vorstellbar, weil sehr viele private und geschäftliche Anwendungen entsprechende Inhalte nutzen. Gleichzeitig werden diese Inhalte im Internet immer vielfältiger. Die meisten Webseiten nutzen eingebettete Videos, animierte Elemente und andere aktive Inhalte. Moderne Webbrowser decken zudem eine große Bandbreite an Zusatzfunktionen ab, indem sie Plug-ins und externe Bibliotheken einbinden. Hinzu kommen Erweiterungen für bestimmte Funktionen, Datenformate und Inhalte. Die Komplexität moderner Webbrowser bietet ein hohes Potenzial für gravierende konzeptionelle Fehler und programmtechnische Schwachstellen. Sie erhöht nicht nur die möglichen Gefahren für Angriffe aus dem Internet, sondern birgt zusätzliche Risiken durch Programmier- und Bedienungsfehler.

Die Risiken für die Vertraulichkeit und Integrität von Daten sind erheblich. Ebenso ist die Verfügbarkeit des gesamten IT-Systems durch solche Schwachstellen bedroht. Internetinhalte müssen demzufolge aus Sicht des Webbrowsers grundsätzlich als nicht vertrauenswürdig angesehen werden.

Zielsetzung

Ziel dieses Bausteins ist es, Sicherheitsanforderungen für Webbrowser, die auf Clients, also auf stationären und mobilen IT-Systemen sowie auch auf Tablets und Smartphones, eingesetzt werden, zu beschreiben.

Abgrenzung und Modellierung

Der Baustein APP.1.2 Webbrowser ist auf jeden Webbrowser einmal anzuwenden.

Er enthält grundsätzliche Sicherheitsanforderungen, die bei der Installation und dem Betrieb von Webbrowsern für den Zugriff auf Daten aus dem Internet zu beachten und zu erfüllen sind.

Webbrowser sind eine der am häufigsten genutzten Anwendungen. Sie greifen auf ungeprüfte, potentiell schädliche Daten im Internet zu und stellen damit ein Einfallstor für Angriffe dar, oft mit dem Ziel, sich weiter auf das Betriebssystem auszubreiten. Um die Betriebssysteme abzusichern, sollten daher die Anforderungen der Bausteine der Schichten SYS.2 Desktop-Systeme und SYS.3.2 Tablet und Smartphone erfüllt werden.

Mit Browsern genutzte Webanwendungen sowie zuständige Server werden in den Bausteinen APP.3.1 Webanwendungen und Webservices und APP.3.2 Webserver behandelt.

Allgemeine Anforderungen an den sicheren Einsatz von Software sind in diesem Baustein nicht enthalten. Sie sind im Baustein APP.6 Allgemeine Software zu finden, der zusätzlich zu diesem Baustein anzuwenden ist.

Wissenswertes

  • BSI-Veröffentlichung zur Cyber-Sicherheit BSI-CS 047: „Absicherungsmöglichkeiten beim Einsatz von Webbrowsern“
  • Mindeststandard des BSI für den Einsatz des SSL/ TLS-Protokoll durch Bundesbehörden nach § 8 Abs. 1 Satz 1 BSIG
  • Mindeststandard des BSI für Webbrowser nach § 8 Absatz 1 Satz 1 BSIG
  • Common Criteria Protection Profile for Remote-Controlled Browsers Systems (ReCoBS): BSI-PP-0040

Die Mindeststandards sind von den in § 8 Abs. 1 Satz 1 BSIG genannten Stellen der Bundesverwaltung umzusetzen.
APP.1.4 Mobile Anwendungen (Apps)

Einleitung

Smartphones, Tablets und ähnliche mobile Geräte sind heute auch in Behörden und Unternehmen weit verbreitet. Mitarbeitende können so unabhängig von Ort und Zeit auf Daten der Institution, auf Informationen und Anwendungen zugreifen.

Mobile Anwendungen (Applikationen, kurz Apps) sind Anwendungen, die auf mobil genutzten Betriebssystemen wie iOS oder Android auf entsprechenden Endgeräten installiert und ausgeführt werden. Apps werden üblicherweise aus sogenannten App Stores bezogen. Diese werden oft von den herstellenden Institutionen der mobil genutzten Betriebssysteme und Endgeräte betrieben und gepflegt. Im professionellen Umfeld ist es aber auch üblich, Apps selbst zu entwickeln und z. B. über Mobile-Device-Management-Lösungen (MDM) auf den Endgeräten zu installieren und zu verwalten. Im Vergleich zu Anwendungen auf Desktop-Betriebssystemen unterliegen Apps unter iOS oder Android besonderen Rahmenbedingungen, wie etwa einem durch das Betriebssystem sichergestellten Berechtigungsmanagement.

Für die unterschiedlichen mobilen Betriebssysteme gibt es mittlerweile eine große Auswahl an verfügbaren Apps. Auch gibt es standardisierte Bibliotheken und Entwicklungsumgebungen, mit deren Hilfe sich Apps im Vergleich zu klassischen Anwendungen schnell selbst entwickeln lassen.

Zielsetzung

Ziel dieses Bausteins ist es, Informationen zu schützen, die auf mobilen Endgeräten mit Apps verarbeitet werden. Auch die Einbindung von Apps in eine bestehende IT-Infrastruktur wird dabei betrachtet. Der Baustein definiert zudem Anforderungen, um Apps richtig auszuwählen und sicher betreiben zu können. Dabei werden die Apps unabhängig von ihrer Quelle (App Store oder eigene Installation) betrachtet.

Abgrenzung und Modellierung

Der Baustein APP.1.4 Mobile Anwendungen (Apps) ist auf alle Anwendungen anzuwenden, die auf mobilen Endgeräten eingesetzt werden.

Der Baustein betrachtet Apps unter mobilen Betriebssystemen wie iOS und Android. Anforderungen, welche die zugrundeliegenden Betriebssysteme betreffen, werden hier nicht berücksichtigt. Diese Anforderungen finden sich beispielsweise in den Bausteinen SYS.3.2.3 iOS (for Enterprise) sowie SYS.3.2.4 Android. Oft werden Apps zentral über ein Mobile Device Management verwaltet. Anforderungen hierzu können dem Baustein SYS.3.2.2 Mobile Device Management (MDM) entnommen werden.

Ebenso sind anwendungsspezifische Aspekte von Apps nicht Gegenstand des Bausteins zu mobilen Anwendungen. Diese werden in den entsprechenden Bausteinen der Schicht APP Anwendungen, wie z. B. APP.1.2 Webbrowser behandelt.

Apps greifen häufig auf Backend-Systeme oder Server bzw. Anwendungsdienste zurück. Werden die Backend-Systeme oder Server selber betrieben, werden Sicherheitsempfehlungen dazu nicht an dieser Stelle gegeben, sondern in den entsprechenden Bausteinen des IT-Grundschutz-Kompendiums. Dazu gehören beispielsweise APP.3.1 Webanwendungen und Webservices oder APP.4.3 Relationale Datenbanken. Zusätzlich sollten die Bausteine berücksichtigt werden, die sich mit allgemeinen Aspekten von Anwendungen befassen, etwa OPS.1.1.6 Software-Tests und -Freigaben oder APP.6 Allgemeine Software, da diese Aspekte nicht im vorliegenden Baustein berücksichtigt werden. Bei der Entwicklung eigener Apps sollten die Anforderungen des Bausteins CON.8 Software-Entwicklung berücksichtigt werden.

Wissenswertes

Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. (Bitkom) stellt mit dem Leitfaden „Apps & Mobile Services - Tipps für Unternehmen“ (2. Auflage, 2014) eine Entscheidungshilfe zum Thema Apps und Mobile Services in Unternehmen bereit.

Das Information Security Forum (ISF) bietet eine Broschüre mit dem Titel „Securing Mobile Apps - Embracing mobile, balancing control“ (2018) an.

Auch die „NIST Special Publication 800-163: Vetting the Security of Mobile Applications“ (2015) bietet weiterführende Informationen zum Thema Apps.
APP.2.1 Allgemeiner Verzeichnisdienst

Einleitung

Ein Verzeichnisdienst stellt in einem Datennetz Informationen über beliebige Objekte in einer definierten Art zur Verfügung. In einem Objekt können zugehörige Attribute gespeichert werden, zum Beispiel können zu einer Kennung der Name und Vorname des oder der Benutzenden, die Personalnummer und der Name des IT-Systems abgelegt werden. Diese Daten können dann gleichermaßen von verschiedenen Applikationen verwendet werden. Der Verzeichnisdienst und seine Daten werden in der Regel von zentraler Stelle aus verwaltet.

Einige typische Anwendungsgebiete von Verzeichnisdiensten sind:

  • Verwaltung von Adressbüchern, z. B. für Telefonnummern, E-Mail-Adressen und Zertifikate für elektronische Signaturen
  • Benutzendenverwaltung, z. B. zur Verwaltung von Konten und Berechtigungen
  • Bereitstellung eines Backend-Dienstes für Authentifizierungsfunktionen, z. B. zur Anmeldung an Betriebssystemen oder Anwendungen

Verzeichnisdienste sind auf Lesezugriffe hin optimiert, da Daten aus dem Verzeichnisdienst typischerweise vorwiegend abgerufen werden. Schreibzugriffe, bei denen Einträge erstellt, geändert oder gelöscht werden, sind seltener notwendig.

Wenn ein Verzeichnisdienst eingesetzt wird, können manche Verwaltungsaufgaben innerhalb des Netzes, wie z. B. Kontenerstellung, Passwortänderungen und Zuweisungen von Rollen und Gruppen, an zentraler Stelle durchgeführt werden.

Zielsetzung

Ziel dieses Bausteins ist es, allgemeine Verzeichnisdienste sicher zu betreiben sowie die damit verarbeiteten Informationen angemessen zu schützen.

Abgrenzung und Modellierung

Der Baustein APP.2.1 Allgemeiner Verzeichnisdienst ist für alle verwendeten Verzeichnisdienste anzuwenden.

Dieser Baustein betrachtet allgemeine Sicherheitsaspekte von Verzeichnisdiensten unabhängig vom eingesetzten Produkt. Für produktspezifische Sicherheitsaspekte gibt es im IT-Grundschutz-Kompendium weitere Bausteine, die zusätzlich auf den jeweiligen Verzeichnisdienst anzuwenden sind. Bausteine zu Server-Betriebssystemen, auf denen Verzeichnisdienste üblicherweise betrieben werden, sind in der Schicht SYS.1 Server des IT-Grundschutz-Kompendiums aufgeführt. Grundlegende Anforderungen an Software-Produkte finden sich in APP.6 Allgemeine Software und sind ebenfalls zu beachten.

Verzeichnisdienste sollten grundsätzlich im Rahmen der Bausteine ORP.4 Identitäts- und Berechtigungsmanagement, OPS.1.1.3 Patch- und Änderungsmanagement, CON.3 Datensicherungskonzept, OPS.1.2.2 Archivierung, OPS.1.1.5 Protokollierung, OPS.1.2.5 Fernwartung sowie OPS.1.1.2 Ordnungsgemäße IT-Administration mitberücksichtigt werden.

Wissenswertes

Für den Baustein APP.2.1 Allgemeiner Verzeichnisdienst sind keine weiterführenden Informationen vorhanden.
APP.2.2 Active Directory Domain Services

Einleitung

Active Directory (AD) ist ein Sammelbegriff für verschiedene von Microsoft für Windows Server entwickelte Serverrollen. Die Serverrolle Active Directory Domain Services (AD DS) aggregiert sowohl Funktionalitäten eines Verzeichnis-, als auch Authentifizierungs- und Autorisierungsdienstes sowie einer zentralen Konfigurationsverwaltung für Windows-Infrastrukturen.

Active Directory Domain Services wird hauptsächlich in Netzen eingesetzt, die vorrangig von Microsoft-basierten Betriebssystemen geprägt sind. Ein AD DS speichert und verwaltet Informationen zu Netzressourcen (z. B. Benutzende, Computer und Geräte). Bei Bedarf können diese Informationen, wie in LDAP-Verzeichnisdiensten üblich, auch um anwendungsspezifische Daten erweitert werden. Es dient Anwendenden und Administrierenden dazu, diese Informationen in einer hierarchischen Struktur zu organisieren, bereitzustellen und zu nutzen. Dabei strukturiert AD DS die Objekte in Namensräumen, die als Gesamtstrukturen, Domänen und Organisationseinheiten bezeichnet werden. Eine Gesamtstruktur bildet eine hierarchische Sammlung von Domänen, die jeweils mehrere Organisationseinheiten enthalten können. Die erste und damit in der Hierarchie oben angeordnete Domäne, die in einer Gesamtstruktur angelegt wird, übernimmt systembedingt die Rolle der „Gesamtstruktur Stammdomäne“ (englisch „forest root domain“) und beinhaltet die administrativen Gruppen, die für gesamtstrukturweite Verwaltungsaufgaben wie beispielsweise das Hinzufügen weiterer Domänen oder Schemaänderungen zuständig sind. Alle Domänen innerhalb einer Gesamtstruktur sind implizit durch bidirektionale, transitive Vertrauensstellungen miteinander verknüpft, so dass die Gesamtstruktur eine logische Sicherheitsgrenze darstellt.

Als Authentisierungsprotokoll nutzt AD DS im Standard Kerberos v5 (in einer durch Microsoft erweiterten Implementierung). Zusätzlich steht weiterhin auch noch das Protokoll NTLM (New Technology LAN Manager) zur Verfügung. NTLM kann dabei einfacher von Angreifenden ausgenutzt werden. Windows Server mit der Serverrolle AD DS werden als Domänencontroller bezeichnet. Aus Verfügbarkeitsgründen werden häufig mehrere Domänencontroller verteilt eingesetzt. Das AD DS bietet außerdem die Möglichkeit eines „Read-Only-Betriebs“ eines Domänencontrollers, der für Standorte mit erhöhtem Risiko für die physische Sicherheit vorgesehen ist.

Zielsetzung

Das Ziel dieses Bausteins ist es, Active Directory Domain Services im Regelbetrieb einer Institution abzusichern, die AD DS zur Verwaltung von Windows-Systemen (Client und Server) sowie zur zentralen Authentifizierung und Autorisierung einsetzt.

Abgrenzung und Modellierung

Der Baustein APP.2.2 Active Directory Domain Services ist für alle verwendeten Verzeichnisdienste anzuwenden, die auf Microsoft Active Directory Domain Services basieren. Er kann zusätzlich für die Modellierung von Active Directory Lightweight Directory Services (AD LDS), die einen reduzierten Funktionsumfang von AD DS bieten, in Teilen verwendet werden.

In diesem Baustein werden die für Active Directory Domain Services spezifischen Gefährdungen und Anforderungen betrachtet. Allgemeine Sicherheitsempfehlungen zu Verzeichnisdiensten finden sich im Baustein APP.2.1 Allgemeiner Verzeichnisdienst. Die dort beschriebenen allgemeinen Anforderungen werden im vorliegenden Baustein konkretisiert und ergänzt. Dieser Baustein wiederholt nicht die Anforderungen zur Absicherung der Betriebssysteme der Server und Clients, die für den Betrieb und die Verwaltung des AD DS genutzt werden, wie z. B. SYS.1.2.3 Windows Server oder SYS.2.2.3 Clients unter Windows. Dieser Baustein geht auch nicht erneut auf die Anforderungen der zugrundeliegenden Netzinfrastruktur ein.

Active Directory Domain Services sollte nicht losgelöst von den Bausteinen ORP.4 Identitäts- und Berechtigungsmanagement, OPS.1.1.3 Patch- und Änderungsmanagement, CON.3 Datensicherungskonzept, OPS.1.2.2 Archivierung, OPS.1.1.5 Protokollierung, sowie OPS.1.1.2 Ordnungsgemäße IT-Administration, OPS.1.2.5 Fernwartung, DER.1 Detektion von sicherheitsrelevanten Ereignissen, DER.2 Security Incident Management, DER.4 Notfallmanagement und APP.3.6 DNS-Server modelliert werden. Es ist davon auszugehen, dass sich die Anforderungen dieser Bausteine wechselseitig beeinflussen.

Wissenswertes

Die Website „Active Directory Security“ (https://adsecurity.org) enthält viele weiterführende Informationen zu AD-Sicherheit.

Der Hersteller Microsoft bietet weitergehende Informationen zu Active Directory und dessen Sicherheitsaspekten:
APP.2.3 OpenLDAP

Einleitung

OpenLDAP ist ein frei verfügbarer Verzeichnisdienst, der in einem Datennetz Informationen über beliebige Objekte, beispielsweise Konten, IT-Systeme oder Konfigurationen, in einer standardisierten und definierten Art zur Verfügung stellt. Die Informationen können einfache Attribute wie die Namen oder Nummern von Objekten oder auch komplexe Formate wie Fotos oder Zertifikate für elektronische Signaturen umfassen. Typische Einsatzgebiete sind zum Beispiel Adressbücher oder Kontenverwaltungen, aber auch Konfigurationen.

OpenLDAP stellt eine Referenz-Implementierung für einen Server-Dienst im Rahmen des Lightweight Directory Access Protocols (LDAP) dar. Als Open-Source-Software kann OpenLDAP auf einer Vielzahl von Betriebssystemen installiert werden und gilt als einer der am meisten verbreiteten Verzeichnisdienste. Zur Besonderheit von OpenLDAP gehören die Overlays. Overlays erweitern den Funktionsumfang von OpenLDAP um zahlreiche Funktionen und werden auch für grundlegende Funktionen wie Protokollierung, Replikation und die Wahrung der Integrität verwendet.

Zielsetzung

Ziel dieses Bausteins ist es, auf OpenLDAP basierende Verzeichnisdienste sicher zu betreiben sowie die damit verarbeiteten Informationen geeignet zu schützen.

Abgrenzung und Modellierung

Der Baustein APP.2.3 OpenLDAP ist auf jedes OpenLDAP-Verzeichnis anzuwenden.

In diesem Baustein werden die für OpenLDAP spezifischen Gefährdungen und Anforderungen betrachtet. Dabei wird die Version 2.4 von OpenLDAP zugrunde gelegt. Allgemeine Sicherheitsempfehlungen zu Verzeichnisdiensten gibt es im Baustein APP.2.1 Allgemeiner Verzeichnisdienst. Diese müssen zusätzlich berücksichtigt werden. Die dort beschriebenen Anforderungen werden im vorliegenden Baustein konkretisiert und ergänzt.

OpenLDAP sollte grundsätzlich im Rahmen der Bausteine ORP.4 Identitäts- und Berechtigungsmanagement, OPS.1.1.3 Patch- und Änderungsmanagement, CON.3 Datensicherungskonzept, OPS.1.2.2 Archivierung, OPS.1.1.5 Protokollierung sowie OPS.1.1.2 Ordnungsgemäße IT-Administration mitberücksichtigt werden.

Wissenswertes

Für den Baustein APP.2.3 OpenLDAP sind keine weiterführenden Informationen vorhanden.
APP.3.1 Webanwendungen und Webservices

Einleitung

Webanwendungen bieten bestimmte Funktionen und dynamische (sich verändernde) Inhalte. Dazu nutzen Webanwendungen die Internetprotokolle HTTP (Hypertext Transfer Protocol) oder HTTPS. Bei HTTPS wird die Verbindung durch das Protokoll TLS (Transport Layer Security) kryptografisch abgesichert. Webanwendungen stellen auf einem Server Dokumente und Bedienoberflächen, z. B. in Form von Eingabemasken, bereit und liefern diese auf Anfrage an entsprechende Programme auf den Clients aus, wie z. B. an Webbrowser.

Webservices sind Anwendungen, die das HTTP(S)-Protokoll verwenden, um Daten für andere Anwendungen bereitzustellen. In der Regel werden sie nicht unmittelbar durch Benutzende angesteuert.

Um eine Webanwendung oder einen Webservice zu betreiben, sind in der Regel mehrere Komponenten notwendig. Üblich sind Webserver, um Daten auszuliefern und Applikationsserver, um die eigentliche Anwendung oder den Webservice zu betreiben. Außerdem werden zusätzliche Hintergrundsysteme benötigt, die oft als Datenquellen über unterschiedliche Schnittstellen angebunden sind, z. B. Datenbanken oder Verzeichnisdienste.

Webanwendungen und Webservices werden sowohl in öffentlichen Datennetzen als auch in lokalen Netzen einer Institution (Intranet) eingesetzt, um Daten und Anwendungen bereitzustellen. In der Regel müssen sich Clients authentisieren, um auf eine Webanwendung oder einen Webservice zugreifen zu können.

Zielsetzung

Ziel dieses Bausteins ist es, Webanwendungen und Webservices sicher einzusetzen sowie Informationen zu schützen, die durch sie verarbeitet werden.

Abgrenzung und Modellierung

Der Baustein ist auf jede Webanwendung und jeden Webservice anzuwenden, die im Informationsverbund eingesetzt werden.

Anforderungen an Webserver und an die redaktionelle Planung eines Webauftritts werden in diesem Baustein nicht behandelt. Sie sind im Baustein APP.3.2 Webserver zu finden. Die Entwicklung von Webanwendungen wird im Baustein CON.10 Entwicklung von Webanwendungen behandelt.

Webservice-Schnittstellen werden oft via Representational State Transfer (REST) und Simple Object Access Protocol (SOAP) realisiert. In diesem Baustein werden nur REST-basierte Webservices betrachten. Der Fokus liegt dabei auf der Lebenszyklusphase „Betrieb“. Sicherheitsanforderungen, die sich beispielsweise aus der Planung und Konzeption sowie Aussonderung und Notfallvorsorge ergeben, werden in diesem Baustein nicht betrachtet, sondern müssen gesondert im Rahmen einer Risikoanalyse ermittelt werden.

Allgemeine Anforderungen an die Auswahl von Software werden im Baustein APP.6 Allgemeine Software betrachtet.

Wissenswertes

Das Open Web Application Security Projekt (OWASP) stellt auf seiner Webseite Hinweise zur Absicherung von Webanwendungen und Webservices zur Verfügung.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt im Dokument „Kryptographische Verfahren: Empfehlungen und Schlüssellängen: BSI TR-02102“ Hinweise zur Anwendung kryptografischer Verfahren zur Verfügung.
APP.3.2 Webserver

Einleitung

Ein Webserver ist die Kernkomponente jedes Webangebotes, er nimmt Anfragen der Clients entgegen und liefert die entsprechenden Inhalte zurück. Die Daten werden in der Regel über das Hypertext Transfer Protocol (HTTP) oder dessen mit Transport Layer Security (TLS) verschlüsselte Variante HTTP Secure (HTTPS) transportiert. Da Webserver eine einfache Schnittstelle zwischen Serveranwendungen und Clients bieten, werden sie auch häufig für interne Informationen und Anwendungen in Institutionsnetzen, wie dem Intranet, eingesetzt.

Webserver sind in der Regel direkt im Internet verfügbar und bieten somit eine exponierte Angriffsfläche. Deswegen müssen sie durch geeignete Schutzmaßnahmen abgesichert werden.

Zielsetzung

Ziel dieses Bausteins ist der Schutz des Webservers und der Informationen, die durch den Webserver bereitgestellt oder damit verarbeitet werden.

Abgrenzung und Modellierung

Der Baustein muss auf alle Webserver des Informationsverbunds angewendet werden.

Die Bezeichnung Webserver wird sowohl für die Software verwendet, welche die HTTP-Anfragen beantwortet, als auch für die IT-Systeme, auf denen diese Software ausgeführt wird. In diesem Baustein wird vorrangig die Webserver-Software betrachtet. Sicherheitsaspekte des IT-Systems, auf dem die Webserver-Software installiert ist, werden im Baustein SYS.1.1 Allgemeiner Server sowie den jeweiligen betriebssystemspezifischen Bausteinen betrachtet.

Empfehlungen, wie Webserver in die Netzarchitektur zu integrieren und mit Firewalls abzusichern sind, finden sich in den Bausteinen NET.1.1 Netzarchitektur und -design bzw. NET.3.2 Firewall.

Der Baustein behandelt grundsätzliche Aspekte, die für die Bereitstellung von Webinhalten wichtig sind. Dynamische Inhalte, die durch Webanwendungen bereitgestellt werden, sind nicht Gegenstand des vorliegenden Bausteins. Diese werden im Baustein APP.3.1 Webanwendungen und Webservices behandelt. Ebenso werden hier keine Webservices betrachtet.

Webbrowser werden in diesem Baustein nicht betrachtet. Anforderungen dazu sind im Baustein APP.1.2 Webbrowser zu finden.

In der Regel werden die Verbindungen zu Webservern verschlüsselt. Der Baustein CON.1 Kryptokonzept beschreibt, wie die dazu notwendigen kryptografischen Schlüssel sicher verwaltet werden können.

Werden Webserver nicht selbst betrieben, sondern über einen Hosting-Anbieter bereitgestellt, ist der Baustein OPS.2.3 Nutzung von Outsourcing zu beachten.

Oft werden Authentisierungsmechanismen für Webserver verwendet. Ergänzende Anforderungen dazu finden sich im Baustein ORP.4 Identitäts- und Berechtigungsmanagement.

Wissenswertes

Das Bundesamt für Sicherheit in der Informationstechnik hat folgende weiterführende Dokumente veröffentlicht, die für den Betrieb von Webservern relevant sein können:

  • Migration auf TLS 1.2 - Handlungsleitfaden
  • Sicheres Webhosting: Handlungsempfehlung für Webhoster
  • Sicheres Bereitstellen von Webangeboten (ISi-Webserver)

Das National Institute of Standards and Technology (NIST) stellt in seinem Dokument „Guideline on Securing Public Web Servers“ Hinweise zur Absicherung von Webservern zur Verfügung.
APP.3.3 Fileserver

Einleitung

Ein Fileserver (oder auch Dateiserver) ist ein Server in einem Netz, der Dateien von (internen) Festplatten oder Netzfestplatten für alle zugriffsberechtigten Personen sowie Clients zentral bereitstellt. Die Datenbestände können von den Zugriffsberechtigten genutzt werden, ohne sie z. B. auf Wechseldatenträgern zu transportieren oder per E-Mail zu verteilen. Dadurch, dass die Daten zentral vorgehalten werden, können sie strukturiert und in verschiedenen Verzeichnissen und Dateien bereitgestellt werden. Bei Fileservern können Zugriffsrechte auf die Dateien zentral vergeben werden. Auch die Datensicherung kann vereinfacht werden, wenn sich alle Informationen an einer zentralen Stelle befinden.

Ein Fileserver verwaltet meistens Massenspeicher, die mit ihm über Schnittstellen wie SCSI (Small Computer System Interface) oder SAS (Serial Attached SCSI) verbunden sind. Die Speicher befinden sich entweder direkt im Gehäuse des Fileservers oder sind extern angeschlossen. Letzteres wird oft als Directly Attached Storage (DAS) bezeichnet. Ein Fileserver kann auf herkömmlicher Server-Hardware oder einer dedizierten Appliance betrieben werden. Oft können bei großen Datenmengen auch zentrale Storage-Area-Network (SAN)-Speicher über Host-Bus-Adapter (HBA) im Server und an SAN-Switches angebunden werden.

Zielsetzung

In diesem Baustein werden wesentliche, für einen Fileserver spezifischen Gefährdungen und die sich daraus ergebenden Anforderungen für einen sicheren Einsatz beschrieben.

Abgrenzung und Modellierung

Der Baustein APP.3.3.Fileserver ist auf jeden Fileserver im Informationsverbund einmal anzuwenden.

Der vorliegende Baustein enthält grundsätzliche Anforderungen, die beim Einsatz von Fileservern zu beachten und zu erfüllen sind. Allgemeine und betriebssystemspezifische Aspekte eines Servers sind nicht Gegenstand des vorliegenden Bausteins, sondern werden im Baustein SYS1.1 Allgemeiner Server bzw. in den entsprechenden betriebssystemspezifischen Bausteinen der Schicht SYS IT-Systeme behandelt, z. B. in SYS.1.3 Server unter Linux und Unix oder SYS.1.2.3 Windows Server. Es werden keine Anforderungen an netzbasierte Speichersysteme bzw. Speichernetze beschrieben. Diese sind im Baustein SYS.1.8 Speicherlösungen zu finden. Auch wird nicht auf dedizierte Dienste eingegangen, mit denen ein Fileserver betrieben werden kann, wie z. B. Samba. Der Dienst Samba wird im Baustein APP.3.4 Samba behandelt.

Ein wichtiger Schwerpunkt bei der Absicherung eines Fileservers ist es, Zugriffsrechte auf Dateien nur restriktiv zu vergeben. Weitergehende Anforderungen hierzu sind in dem Baustein ORP.4 Identitäts- und Berechtigungsmanagement zu finden. Auch die Sicherung der auf einem Fileserver abgelegten Informationen wird in diesem Baustein nicht behandelt. Hierzu sind die Anforderungen des Bausteins CON.3 Datensicherungskonzept zu erfüllen.

Wissenswertes

Für den Baustein APP.3.3 Fileserver sind keine weiterführenden Informationen vorhanden.
APP.3.4 Samba

Einleitung

Samba ist ein frei verfügbarer und vollwertiger Active Directory Domain Controller (ADDC), der Authentisierungs-, Datei- und Druckdienste bereitstellen kann und dadurch die Interoperabilität zwischen der Windows- und der Unix-Welt ermöglicht. Samba führt viele unterschiedliche Protokolle und Techniken zusammen. Dazu gehört beispielsweise das Server-Message-Block (SMB)-Protokoll. Als Samba-Server werden Server bezeichnet, auf denen Samba betrieben wird. In der Regel sind das Unix-Server.

Wurde der Einsatz von Samba korrekt konzipiert und geeignet konfiguriert, interagiert Samba mit einem Windows-Client oder -Server, als ob es selbst ein Windows-System wäre.

Zielsetzung

Ziel des Bausteins ist es darzustellen, wie Samba in Institutionen sicher eingesetzt werden kann und wie sich die durch Samba bereitgestellten Informationen schützen lassen.

Abgrenzung und Modellierung

Der Baustein APP.3.4.Samba ist auf jeden Samba-Server des betrachteten Informationsverbunds anzuwenden.

Dieser Baustein betrachtet Samba als Authentisierungs-, Datei- und Druckdienst. Da Samba in der Regel auf Unix-Servern eingesetzt wird und dort aus der Windows-Server-Welt bekannte Dienste bereitstellt, sind die Sicherheitsaspekte der Bausteine SYS.1.1 Allgemeiner Server und SYS.1.3 Server unter Linux und Unix zu berücksichtigen.

Ein wichtiger Schwerpunkt bei der Absicherung eines Samba-Servers ist es, Zugriffsrechte auf Dateien nur restriktiv zu vergeben. Vertiefende Informationen zum Identitäts- und Berechtigungsmanagement sind nicht in diesem Baustein, sondern in ORP.4 Identitäts- und Berechtigungsmanagement zu finden.

Generelle Sicherheitsanforderungen für Drucker, Fileserver oder Verzeichnisdienste sind nicht Bestandteil dieses Bausteins. Diese werden in den Bausteinen SYS.4.1 Drucker, Kopierer und Multifunktionsgeräte, APP.3.3 Fileserver und APP.2.1 Allgemeiner Verzeichnisdienst sowie APP.2.3 OpenLDAP beschrieben.

Wissenswertes

Für den Baustein APP.3.4 Samba sind keine weiterführenden Informationen vorhanden.
APP.3.6 DNS-Server

Einleitung

Domain Name System (DNS) ist ein Netzdienst, der dazu eingesetzt wird, Hostnamen von IT-Systemen in IP-Adressen umzuwandeln. DNS kann mit einem Telefonbuch verglichen werden, das Namen nicht in Telefonnummern, sondern in IP-Adressen auflöst. Üblicherweise wird über DNS zu einem Hostnamen die entsprechende IP-Adresse gesucht (Vorwärtsauflösung). Ist hingegen die IP-Adresse bekannt und der Hostname wird gesucht, wird dies als Rückwärtsauflösung bezeichnet.

Welche Hostnamen zu welchen IP-Adressen gehören, wird im Domain-Namensraum verwaltet. Dieser ist hierarchisch aufgebaut und wird von DNS-Servern zur Verfügung gestellt. Die Bezeichnung DNS-Server steht im eigentlichen Sinne für die verwendete Software, wird jedoch meist auch als Synonym für das IT-System benutzt, auf dem diese Software betrieben wird.

DNS-Server verwalten den Domain-Namensraum im Internet, werden aber auch häufig im internen Netz einer Institution eingesetzt. Auf den IT-Systemen der Benutzenden sind standardmäßig sogenannte Resolver installiert. Über den Resolver werden die Anfragen an DNS-Server gestellt. Als Antwort liefern die DNS-Server Informationen über den Domain-Namensraum zurück.

DNS-Server können nach ihren Aufgaben unterschieden werden. Dabei gibt es grundsätzlich zwei verschiedenen Typen: Advertising DNS-Server und Resolving DNS-Server. Advertising DNS-Server sind üblicherweise dafür zuständig, Anfragen aus dem Internet zu verarbeiten. Resolving DNS-Server hingegen verarbeiten Anfragen aus dem internen Netz einer Institution.

Der Ausfall eines DNS-Servers kann sich gravierend auf den Betrieb einer IT-Infrastruktur auswirken. Dabei ist nicht das ausgefallene DNS-System an sich problematisch, sondern die DNS-basierten Dienste, die daraus eingeschränkt werden. Unter Umständen sind Webserver oder E-Mail-Server nicht mehr erreichbar oder die Fernwartung funktioniert nicht mehr. Da DNS von sehr vielen Netzanwendungen benötigt wird, müssen laut Spezifikation (RFC 1034) mindestens zwei autoritative DNS-Server (Advertising DNS-Server) für jede Zone betrieben werden.

Zielsetzung

In diesem Baustein werden die für einen DNS-Server spezifischen Gefährdungen und die sich daraus ergebenden Anforderungen für einen sicheren Einsatz beschrieben.

Abgrenzung und Modellierung

Der Baustein APP.3.6 DNS-Server ist auf jeden im Informationsverbund eingesetzten DNS-Server anzuwenden.

Der vorliegende Baustein enthält grundsätzliche Anforderungen, die zu beachten und zu erfüllen sind, wenn eine Institution DNS-Server einsetzt. Der Fokus liegt dabei auf der Verfügbarkeit von DNS-Servern und der Integrität der übertragenen Informationen. Außerdem werden Probleme behandelt, die auftreten können, wenn DNS-Server eingesetzt werden.

Allgemeine und betriebssystemspezifische Aspekte eines Servers sind nicht Gegenstand dieses Bausteins. Diese werden im Baustein SYS1.1 Allgemeiner Server und in den entsprechenden betriebssystemspezifischen Bausteinen der Schicht SYS IT-Systeme behandelt, z. B. SYS.1.3 Server unter Linux und Unix oder SYS.1.2.3 Windows Server.

Wissenswertes

Das BSI hat folgende weiterführende Dokumente zum Themenfeld DNS veröffentlicht:

  • BSI-Veröffentlichung zur Cyber-Sicherheit BSI-CS 055: „Sichere Bereitstellung von DNS-Diensten: Handlungsempfehlungen für Internet-Service-Provider (ISP) und große Unternehmen“
  • BSI-Veröffentlichung zur Cyber-Sicherheit BSI-CS 121: „Umsetzung von DNSSEC: Handlungsempfehlungen zur Einrichtung und zum Betrieb der Domain Name Security Extensions“
  • Sichere Anbindung von lokalen Netzen an das Internet (ISi-LANA)

Das National Institute of Standards and Technology (NIST) gibt in der NIST Special Publication 800-81-2 „Secure Domain Name System (DNS) - Deployment Guide“ Empfehlungen zum Einsatz von DNS.

Im Request for Comments (RFC) bietet der RFC 1034 „Domain Names - Concepts and Facilities“ weiterführende Informationen zu DNS.
APP.4.2 SAP-ERP-System

Einleitung

Enterprise-Resource-Planning-Systeme von SAP (kurz SAP-ERP-Systeme) werden eingesetzt, um interne und externe Geschäftsabläufe zu automatisieren und technisch zu unterstützen. SAP-ERP-Systeme verarbeiten daher typischerweise vertrauliche Informationen, sodass alle Komponenten und Daten geeignet geschützt werden müssen.

SAP-ERP-Systeme sind aktuell unter den Produktbezeichnungen SAP Business Suite und SAP S/4HANA auf dem Markt. Ein SAP-ERP-System setzt sich aus verschiedenen Modulen zusammen, mit denen die Organisationsstruktur einer Institution abgebildet werden kann. Zu den Modulen eines SAP-ERP-Systems zählen unter anderem Rechnungswesen, Personalwirtschaft und Logistik. Die Kernkomponenten des SAP-ERP-Systems sind SAP NetWeaver (Applikationsserver-Middleware) und SAP HANA (Applikationsserver und Datenbank). SAP NetWeaver ermöglicht es, SAP-ABAP- und SAP-JAVA-Anwendungen anzubinden und Prozesse systemweit zu steuern. SAP HANA kann in Echtzeit große Datenmengen für alle Geschäftsbereiche analysieren.

Zielsetzung

Der Baustein beschreibt, welche Gefährdungen für SAP-ERP-Systeme zu beachten sind und wie diese Systeme sicher installiert, konfiguriert und betrieben werden können. Er richtet sich an Informationssicherheitsbeauftragte und Administrierende, die dafür zuständig sind, SAP-ERP-Systeme zu planen und umzusetzen.

Abgrenzung und Modellierung

Der Baustein APP.4.2 SAP-ERP-System ist auf jedes SAP-ERP-System anzuwenden.

Der Baustein beschränkt sich auf die Kerninstallation eines SAP-ERP-Systems und fokussiert die spezifischen Merkmale des darunterliegenden SAP-NetWeaver-Applikationsservers. Auch werden in diesem Baustein nicht alle verfügbaren SAP-Produkte detailliert beschrieben. Die folgenden Darstellungen beschränken sich auf die Konfiguration der SAP-Basis und gehen nicht auf Module oder Applikationen ein.

Anforderungen an die Entwicklung von ABAP-Programmen finden sich im Baustein APP.4.6 SAP ABAP-Programmierung. Darüber hinaus werden keine angrenzenden IT-Systeme, Betriebssysteme oder Datenbanken näher betrachtet. Dazu sind die spezifischen Bausteine wie SYS1.2.2 Windows Server 2012, SYS.1.3 Server unter Linux und Unix oder APP.4.3 Relationale Datenbanken anzuwenden. Ebenso geht der vorliegende Baustein nicht auf SAP HANA ein. Auf aktuelle Bezeichnungen der Produkte wird bewusst verzichtet, da sich diese häufig ändern.

Wissenswertes

Das SAP Help Portal (https://www.help.sap.com/viewer/index) ist der zentrale Einstieg in die SAP Hilfe. Sie bietet zu vielfältigen Themen umfangreiche Informationen und Anleitungen. Im Folgenden wird eine Auswahl an Themen, die im Kontext SAP-ERP-Systeme interessant sind, aufgelistet:

Detaillierte Best-Practice-Empfehlungen für die Prüfungen von SAP-ERP-Systemen, bietet der Prüfleitfaden SAP ERP 6.0: Best Practice - Empfehlungen der Deutschsprachigen SAP Anwendergruppe e. V. (DSAG).
APP.4.3 Relationale Datenbanken

Einleitung

Datenbanksysteme (DBS) sind ein oft genutztes Hilfsmittel, um IT-gestützt große Datensammlungen zu organisieren, zu erzeugen, zu verändern und zu verwalten. Ein DBS besteht aus dem so genannten Datenbankmanagementsystem (DBMS) und einer oder mehreren Datenbanken. Eine Datenbank ist eine Zusammenstellung von Daten samt ihrer Beschreibung (Metadaten), die dauerhaft im Datenbanksystem abgelegt werden. Da Datenbanksysteme oft eine zentrale Bedeutung in einer IT-Infrastruktur einnehmen, ergeben sich an sie wesentliche Sicherheitsanforderungen. Meist sind Kernprozesse einer Institution von den Informationen aus den Datenbanken abhängig. Dadurch ergeben sich entsprechende Verfügbarkeitsanforderungen. Zusätzlich bestehen oft hohe Anforderungen an die Vertraulichkeit und Integrität der in den Datenbanken gespeicherten Informationen.

Zielsetzung

Ziel dieses Bausteins ist es, relationale Datenbanksysteme sicher betreiben zu können sowie die Informationen, die in Datenbanken verarbeitet und gespeichert werden, angemessen zu schützen. Dazu werden Anforderungen beschrieben, mit denen sich Datenbanksysteme sicher planen, umsetzen und betreiben lassen und durch die Gefährdungen reduziert werden können.

Abgrenzung und Modellierung

Der Baustein APP.4.3 Relationale Datenbanken ist auf jedes relationale Datenbanksystem einmal anzuwenden.

In diesem Baustein werden Anforderungen an relationale Datenbanksysteme beschrieben. Sicherheitsanforderungen an nicht-relationale Datenbanksysteme sind nicht Gegenstand des vorliegenden Bausteins.

Um die Informationen in den Datenbanken durchgängig zu schützen, sollten bereits in der Anwendungsentwicklung Sicherheitsanforderungen an den Aufbau der Datenbanktabellen und den Zugriff auf die Datenbank beachtet werden. Anforderungen zu diesen Themen werden jedoch nicht in diesem Baustein aufgeführt.

Ebenso geht der Baustein nicht auf Gefährdungen und Anforderungen ein, die das Betriebssystem und die Hardware betreffen, auf denen das Datenbanksystem installiert ist. Aspekte dazu finden sich in den entsprechenden betriebssystemspezifischen Bausteinen der Schicht SYS IT-Systeme, z. B. SYS.1.3 Server unter Linux und Unix oder SYS.1.2.3 Windows Server.

Relationale Datenbanksysteme sollten grundsätzlich im Rahmen der Bausteine OPR.4 Identitäts- und Berechtigungsmanagement, OPS.1.1.3 Patch- und Änderungsmanagement, CON.3 Datensicherungskonzept, OPS.1.2.2 Archivierung, OPS.1.1.5 Protokollierung sowie OPS.1.1.2 Ordnungsgemäße IT-Administration mit berücksichtigt werden.

Wissenswertes

Das BSI hat im Rahmen der Allianz für Cybersicherheit zum Themenfeld Datenbanksicherheit folgende Partnerbeiträge veröffentlicht:

  • Oracle: Datenbank-Sicherheit - Grundüberlegungen
  • McAfee: Datenbanksicherheit in Virtualisierungs- und Cloud-Computing-Umgebungen

Die Deutsche Telekom Gruppe hat im Rahmen ihres Privacy and Security Assessment Verfahrens (PSA-Verfahren) das Dokument „Sicherheitsanforderung Datenbanksysteme“zum Themenfeld Datenbanken veröffentlicht.

Das Information Security Forum (ISF) macht in seinem Standard „The Standard of Good Practice for Information Security“ im Kapitel BA2.3 Protection of Databases Vorgaben für die Absicherung von relationalen Datenbanksystemen.
APP.4.4 Kubernetes

Einleitung

Kubernetes hat sich als De-Facto-Standard für die Orchestrierung von Containern in der Public und Private Cloud etabliert. Auch für IoT und andere Anwendungsfälle ist Kubernetes im Einsatz, mit K3S gibt es beispielsweise eine Edition, die für sehr kleine Server wie Einplatinencomputer gedacht ist. Auch der sogenannte Cloud Native Stack, der aus vielen verschiedenen Komponenten besteht, baut auf dem von Kubernetes etablierten Standard auf.

Der Begriff Container bezeichnet eine Technik, bei der ein Host-System Anwendungen parallel in separierten Umgebungen ausführt (Operating System Level Virtualization). In den meisten Fällen erfolgt die Überwachung, das Starten und Beenden und die weitere Verwaltung der Container durch eine Verwaltungssoftware, die somit die sogenannte Orchestrierung übernimmt. Kubernetes fasst dabei einen oder mehrere zusammengehörige Container in einem Pod zusammen. Da der Fokus des Bausteins auf Kubernetes liegt, wird im Weiteren nur von Pods und nicht von einzelnen Containern gesprochen. Die Orchestrierung erfolgt dabei zumeist in Gruppen von gemeinsam verwalteten Kubernetes-Nodes in einem oder mehreren sogenannten Clustern.

Um die Orchestrierung von Pods zu betreiben und diese zu verwalten, haben sich mehrere Produkte etabliert, die es erlauben, auch sehr große Umgebungen zu bedienen. In ihrem Kern setzen allerdings alle auf Kubernetes auf. Bei der Betrachtung ist zwischen der Runtime, die die Prozesse auf den Kubernetes-Nodes betreibt, und der Orchestrierung, die die Runtimes auf mehreren Kubernetes-Nodes steuert, zu unterscheiden.

Zusätzlich zu diesen beiden zentralen Komponenten besteht der Betrieb von Kubernetes in den meisten Fällen noch aus einer spezialisierten Infrastruktur, zu der z. B. Registries, Code-Versionierung und -Speicherung, Automatisierungswerkzeuge, Verwaltungsserver, Speichersysteme oder virtuelle Netze gehören.

Die folgenden Begriffe werden im Baustein in dieser Bedeutung verwendet:

  • Anwendung bezeichnet eine Zusammenstellung mehrerer Programme, die gemeinsam eine Aufgabe erfüllen
  • Cluster sind Betriebsumgebungen für Container mit mehreren Nodes
  • Container sind aus einem Image gestartete Prozesse, die innerhalb von Betriebssystem-Namespaces laufen
  • Container Network Interface (CNI) bezeichnet die Schnittstelle zur Verwaltung der virtuellen Netze im Cluster
  • Container Storage Interface (CSI) bezeichnet die Schnittstelle zu den zumeist externen Speichersystemen, die Kubernetes den Pods bereitstellen kann
  • Control Plane bezeichnet alle für die Verwaltung, also Orchestrierung der Nodes, Runtimes und Cluster eingesetzten Anwendungen
  • Images sind alle der Open Container Initiative (OCI) entsprechenden Software-Pakete, diese umfassen sowohl Basis-Images für eigene Images als auch solche Images, die unverändert im Einsatz sind
  • Node bezeichnet einen Server, der für den Betrieb der Runtime installiert und optimiert ist
  • Pod bezeichnet eine Sammlung mehrerer Container, die innerhalb der gleichen Betriebssystem-Namespaces laufen
  • Registry ist der Oberbegriff für die Code-Verwaltung und die Speicherung der Images
  • Runtime bezeichnet die Software, die die Software im Image als Container startet

Zielsetzung

Ziel dieses Bausteins ist der Schutz von Informationen, die in Kubernetes-Clustern verarbeitet, angeboten oder darüber übertragen werden.

Abgrenzung und Modellierung

Der Baustein APP.4.4 Kubernetes ist immer zusammen mit dem Baustein SYS.1.6 Containerisierung anzuwenden. Dabei ist es bezogen auf den Fokus des vorliegenden Bausteins nicht relevant, welche Container-Runtime im Einsatz ist oder welche zusätzlichen Anwendungen Teil der Control Plane sind.

Der Baustein enthält grundsätzliche Anforderungen zur Einrichtung, zum Betrieb und zur Orchestrierung mit Kubernetes sowie zur spezialisierten Infrastruktur, die zum Betrieb notwendig ist. Letzteres beinhaltet Registries, CSI/CNI, Nodes und Automatisierungssoftware, soweit sie direkt mit dem Cluster interagieren. Die Anforderungen für diese Anwendungen beziehen sich zumeist auf die Schnittstellen, enthalten aber auch Anforderungen, die den Betrieb dieser Anwendungen betreffen, sofern sie direkt die Sicherheit des Clusters berühren. Weitere im Kubernetes-Umfeld übliche Dienste, wie z. B. Automatisierung für CI/CD-Pipelines und Codeverwaltung in z. B. Git, behandelt der Baustein nicht in der Tiefe.

Der Baustein modelliert umfassend einen Cluster. Die Anwendungen der Control Plane, Dienste zur Automatisierung und die Nodes, sind hier als eine Gruppe zu sehen und zu behandeln.

Sicherheitsanforderungen für die in Kubernetes-Clustern betriebenen Dienste, wie z. B. Webserver (APP.3.2 Webserver) oder E-Mail-Server (siehe APP.5.3 Allgemeiner E-Mail-Client und -Server), sind Gegenstand eigener Bausteine.

Wissenswertes

Weiterführende Informationen zu Gefährdungen und Sicherheitsmaßnahmen im Bereich Container finden sich unter anderem in folgenden Veröffentlichungen:
APP.4.6 SAP ABAP-Programmierung

Einleitung

Häufig werden in SAP-Systemen Eigenentwicklungen programmiert. Die Gründe dafür sind vielfältig, so können Geschäftsprozesse oder Anforderungen an das Reporting mit Hilfe von Eigenentwicklungen individuell an die Institution angepasst werden. Außerdem ist es möglich, spezielle Funktionen zu erstellen, die in der Standard-Auslieferung nicht vorhanden sind.

Eigenentwicklungen werden von Entwickelnden der Institution oder von beauftragten Entwickelnden programmiert. Im SAP-Umfeld wird dazu häufig ABAP (Advanced Business Application Programming) verwendet.

ABAP ist eine proprietäre, plattformunabhängige Programmiersprache des Unternehmens SAP. Sie wurde für die Programmierung kommerzieller Anwendungen im SAP-Umfeld entwickelt und ähnelt in ihrer Grundstruktur entfernt der Sprache COBOL. Wichtige Merkmale sind:

  • Integration eines Authentisierungs-, Rollen- und Berechtigungskonzepts,
  • Verwendung eines proprietären, datenbankunabhängigen SQL-Derivats (Open SQL),
  • Unterstützung der Kommunikation zwischen verschiedenen SAP-Systemen sowie
  • Integration von Audit-Optionen.

Zielsetzung

Der Baustein zeigt ABAP-Entwickelnden und Sicherheitstestenden relevante technische Risiken auf, die sich durch ABAP-Eigenentwicklungen ergeben können. Außerdem werden Anforderungen definiert, die aufzeigen, wie ABAP-Programme sicher entwickelt und eingesetzt werden können.

Der Baustein setzt grundlegende Kenntnisse in ABAP und im Umgang mit ABAP-Entwicklungswerkzeugen voraus.

Abgrenzung und Modellierung

Der Baustein APP.4.6 SAP ABAP-Programmierung ist auf jedes SAP-System einmal anzuwenden, wenn Eigenentwicklungen in der Programmiersprache ABAP erstellt werden.

Mit diesem Baustein werden die Bausteine CON.8 Software-Entwicklung, APP.6 Allgemeine Software und APP.7 Entwicklung von Individualsoftware um konkrete Aspekte zur Entwicklung von ABAP-Programmen erweitert.

Der Baustein stellt keine vollständige Anleitung dar, um ABAP-Programme zu entwickeln, sondern beschreibt die generellen Risiken der Programmiersprache ABAP. Im Baustein werden Anforderungen definiert, die bei der Entwicklung von ABAP-Programmen aus Sicherheitssicht erfüllt werden sollten.

Da Webanwendungen nur einen sehr geringen Anteil aller ABAP-Anwendungen in SAP-Implementierungen ausmachen, stehen Web-Schwachstellen nicht im Fokus dieses Dokuments.

Wissenswertes

Im „Best Practice Guide: Leitfaden Development ABAP 2.0“ der Deutschsprachigen SAP Anwendergruppe e.V. (DSAG) finden sich vertiefende Informationen zur ABAP-Programmierung.

Weitere Informationen und Best Practices zur sicheren ABAP-Programmierung finden sich im Buch „Sichere ABAP-Programmierung“ von Wiegenstein, Schuhmacher, Schinzel, Weidemann aus dem SAP Press Verlag.
APP.5.2 Microsoft Exchange und Outlook

Einleitung

Microsoft Exchange Server (im Folgenden „Exchange“) ist eine Groupware-Lösung für mittlere bis große Institutionen. Mit ihr können elektronisch Nachrichten übermittelt werden und sie verfügt über weitere Dienste, um Workflows zu unterstützen. Nachrichten, wie E-Mails, können mit Exchange zentral verwaltet, zugestellt, gefiltert und versendet werden. Ebenso können typische Groupware-Anwendungen, wie Notizen, Kontaktlisten, Kalender und Aufgabenlisten angeboten und verwaltet werden. Um die Funktionen von Exchange nutzen zu können, ist neben dem Server-Dienst eine zusätzliche Client-Software oder ein Webbrowser nötig.

Microsoft Outlook (im Folgenden „Outlook“) ist ein Client für Exchange, der durch die Installation des Office-Pakets von Microsoft oder durch Integration in die Betriebssysteme von mobilen Geräten direkt zur Verfügung gestellt wird. Darüber hinaus ermöglicht die Webanwendung „Outlook im Web“ (ehemals „Outlook Web App“) über den Browser z. B. auf E-Mails, Kontakte und den Kalender zuzugreifen. Diese Funktion ist in Exchange bereits enthalten.

Die Kombination aus Exchange-Servern und Outlook-Clients wird in diesem Baustein als Exchange-System bezeichnet.

Zielsetzung

Das Ziel dieses Bausteins ist es, über typische Gefährdungen für Exchange und Outlook zu informieren sowie aufzuzeigen, wie Exchange und Outlook sicher in Institutionen eingesetzt werden.

Abgrenzung und Modellierung

Der Bausteine ist auf alle Exchange-Systeme im Informationsverbund anzuwenden.

Allgemeine Anforderungen an die Sicherheit von E-Mail-Systemen sind im Baustein APP.5.3 Allgemeiner E-Mail-Client und -Server zu finden. Er ist zusätzlich auf jedes E-Mail-System anzuwenden, das auf Exchange bzw. Outlook basiert.

Der Baustein enthält spezifische Gefährdungen und Anforderungen für Exchange-Systeme. Spezifische Anforderungen an Serverplattformen und Betriebssysteme sind nicht Bestandteil des Bausteins. Diese sind in den Bausteinen SYS.1.1 Allgemeiner Server sowie SYS.2.1 Allgemeiner Client und in den jeweiligen betriebssystemspezifischen Bausteinen zu finden.

Wissenswertes

Microsoft stellt auf seiner Webseite „Microsoft Technet" (https://technet.microsoft.com/de-de) umfangreiche Informationen zur Administration von Microsoft Exchange zur Verfügung.
APP.5.3 Allgemeiner E-Mail-Client und -Server

Einleitung

E-Mail ist eine der am häufigsten genutzten und ältesten Internetanwendungen. E-Mails werden dazu verwendet, Texte und angehängte Dateien zu versenden. Dazu wird eine E-Mail-Adresse benötigt.

Um E-Mail nutzen zu können, werden E-Mail-Server benötigt, die elektronische Nachrichten empfangen und versenden. In der Regel rufen E-Mail-Clients, mit denen auf E-Mail-Dienste zugegriffen wird, Nachrichten, die für sie bestimmt sind, mittels der Protokolle POP3 oder IMAP vom E-Mail-Server ab und senden mit dem Protokoll SMTP selbst Nachrichten an den E-Mail-Server, der diese bei Bedarf an einen anderen E-Mail-Server weiterleitet.

Da E-Mail insbesondere in Unternehmen und Behörden weit verbreitet ist, sind E-Mail-Server häufig das Ziel von Angriffen.

Auch E-Mail-Clients stehen im Fokus von Angriffen. Sie werden angegriffen, indem beispielsweise Schadsoftware per E-Mail versendet wird. Zusätzlich werden E-Mails auch oft als Werkzeug für Social-Engineering-Angriffe eingesetzt.

Aus diesen Gründen kommt dem sicheren Betrieb und der sicheren Nutzung von E-Mail-Anwendungen eine besondere Bedeutung zu.

Zielsetzung

Ziel dieses Bausteins ist es, die Informationen zu schützen, die mit E-Mail-Clients bzw. auf E-Mail-Servern verarbeitet werden.

Abgrenzung und Modellierung

Der Baustein APP.5.3 Allgemeiner E-Mail-Client und -Server ist auf jeden E-Mail-Client und -Server im Informationsverbund anzuwenden.

Der Baustein enthält Anforderungen für allgemeine E-Mail-Clients und -Server. Anforderungen für Serverplattformen, Betriebssysteme und Clients sind nicht Bestandteil des Bausteins. Diese sind in den Bausteinen SYS.1.1 Allgemeiner Server sowie SYS.2.1 Allgemeiner Client und in den jeweiligen betriebssystemspezifischen Bausteinen zu finden.

Der Baustein APP.5.3 Allgemeiner E-Mail-Client und -Server wird in einem Informationsverbund meist in Verbindung mit einem weiteren spezifischen Baustein der Schicht APP.5 E-Mail/Groupware/Kommunikation genutzt. Diese müssen ebenfalls separat umgesetzt werden. Zu diesen Bausteinen zählt unter anderem APP.5.2 Microsoft Exchange und Outlook.

Anforderungen für die Protokollierung und Datensicherung finden sich in den Bausteinen OPS.1.1.5 Protokollierung und CON.3 Datensicherungskonzept.

Nicht in diesem Baustein behandelt werden Groupware-Funktionen, die neben E-Mail auch noch weitere Funktionen wie die Verwaltung von Kontaktdaten und Kalendern bieten. Ebenso werden keine reinen Cloud-Lösungen behandelt, wie sie etwa als Teil von Microsoft 365 oder Google G Suite zu finden sind. Allgemeine Anforderungen dazu sind im Baustein OPS.2.2 Cloud-Nutzung zu finden. Ebenfalls nicht betrachtet werden Webbrowser, mit denen über Webseiten auf Webmail-Dienste zugegriffen wird. Anforderungen an Webbrowser sind im Baustein APP.1.2 Webbrowser zu finden.

Wissenswertes

Die International Organization for Standardization (ISO) macht in der Norm ISO/IEC 27001:2013 im Kapitel 13.2.3 Vorgaben für den Betrieb von E-Mail-Diensten.

Das Information Security Forum (ISF) macht in seinem Standard "The Standard of Good Practice for Information Security" im Kapitel CF2.3.3 Vorgaben für den Betrieb von E-Mail-Diensten.

Das National Institute of Standards and Technology (NIST) beschreibt in seinen "Guidelines on Electronic Mail Security" wie E-Mail-Anwendungen sicher betrieben werden können.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt im Dokument "BSI TR-03108 Sicherer E-Mail-Transport" Informationen darüber zur Verfügung, wie E-Mails sicher versendet werden können.
APP.5.4 Unified Communications und Collaboration (UCC)

Einleitung

Unified Communications bezeichnet einen Dienst, der verschiedene Kommunikationsdienste in einer Anwendung und in der Regel auch einem Softclient vereint. Damit wird der Anteil der traditionellen Telefonie in der persönlichen digitalen Kommunikation reduziert. Die möglichen Kommunikationswege werden um zusätzliche Dienste wie Video, diverse Formen von Chats und Erreichbarkeitsanzeigen erweitert.

Eine Kommunikationsbeziehung zwischen zwei oder mehr Teilnehmenden wird unabhängig vom benutzten Dienst als Konversation bezeichnet.

Die häufig bei Unified Communications und Collaboration (UCC) genannte Zusammenarbeit (Collaboration) geht noch einen Schritt weiter. Während damit in der Vergangenheit häufig nur Dienste wie Screen Sharing und (digitales) Whiteboarding bezeichnet wurden, stellen UCC-Dienste viele weitere Funktionen zur Verfügung. Insbesondere beim Zusammenarbeiten von Teams hat sich eine Anzahl von Anwendungen etabliert, die häufig als Cloud-Dienst benutzt werden und neben Telefonie, Erreichbarkeitsanzeige, klassischen Chats, Video-Anrufen und Konferenzen auch Team-Chatbereiche sowie gemeinsame Dateiablagen beinhalten. Hinzukommen (offene) Schnittstellen, wodurch zusätzliche Anwendungen integriert werden können, so dass der Gesamtdienst funktional gegebenenfalls sehr umfangreich wird.

Zielsetzung

Ziel dieses Bausteins ist es, die Informationssicherheit als integralen Bestandteil beim erweiterten Kommunikationsspektrum von UCC-Diensten zu etablieren, ein Bewusstsein für die potenzielle Gefährdungslage dieser Anwendungen zu schaffen und Ansätze zur Vermeidung von Gefährdungen anzubieten.

Abgrenzung und Modellierung

Der Baustein APP.5.4 Unified Communications und Collaboration (UCC) ist auf alle IT-Systeme und Kommunikationsnetze sowie Anwendungen anzuwenden, mit denen UCC-Dienste betrieben werden. Da UCC über Datennetze betrieben wird, sind zusätzlich zu diesem Baustein die Anforderungen der Bausteine NET.1.1 Netzarchitektur- und Design und NET.3.2 Firewall zu berücksichtigen.

Da sich der Geltungsbereich von Kommunikationsdiensten durch UCC zunehmend erweitert, gibt es eine besonders große Zahl von Überschneidungen mit anderen Bausteinen.

Dieser Baustein behandelt die folgenden Inhalte:

  • die UCC-Dienste sowie Interaktion und Wechselwirkungen unterschiedlicher Dienste
  • die (Soft-) Clients, die bereitgestellt werden, um diese Dienste zu benutzen und deren Funktionsumfang
  • die zugehörigen Infrastrukturkomponenten, sofern diese nicht bereits durch andere Bausteine abgedeckt sind
  • Themen, die sich aus dem (aus Sicht der Benutzenden) fließenden Übergang zwischen der UCC-Umgebung und weiteren Anwendungen ergeben

Folgende Inhalte sind ebenfalls von Bedeutung und werden an anderer Stelle behandelt:

  • Falls über eine dedizierte TK-Anlage telefoniert wird, muss der Baustein NET.4.1 TK-Anlagen angewendet werden.
  • Für Voice over IP (VoIP) als ein elementarer Dienst bei UCC-Diensten muss der Baustein NET.4.2 VoIP angewendet werden.
  • Für die zentralen Server sowie diverse Endgeräte und Clients müssen die Bausteine SYS.1.1 Allgemeiner Server und SYS.2.1 Allgemeiner Client sowie gegebenenfalls spezifische Bausteine angewendet werden.
  • Für die zugrundeliegenden Netze muss der Baustein NET.1.1 Netzarchitektur und -design angewendet werden.
  • Falls UCC-Dienste aus der Cloud bereitgestellt werden, ist der Baustein OPS.2.2 Cloud-Nutzung anzuwenden.
  • Um Dateiablagen abzusichern, die im Rahmen der UCC-Dienste bereitgestellt werden, sind insbesondere die Bausteine APP.3.3 Fileserver und SYS.1.8 Speicherlösungen anzuwenden.

Dieser Baustein behandelt nicht die folgenden Inhalte:

  • Der E-Mail-Dienst ist in der Regel nicht Teil der UCC-Dienste. Hier ist der Baustein APP.5.3 Allgemeiner E-Mail-Client und -Server anzuwenden.

Wissenswertes

Für die Auswahl von Verschlüsselungsverfahren und Schlüssellängen sollte die technische Richtlinie „BSI-TR-02102: Kryptographische Verfahren: Empfehlungen und Schlüssellängen“ des BSI beachtet werden.
APP.6 Allgemeine Software

Einleitung

Dieser Baustein fasst jegliche Software unter dem Begriff Allgemeine Software zusammen, unabhängig davon, ob es sich um eine Textverarbeitung, ein Betriebssystem, eine mobile Kommunikations-App, eine individuell entwickelte Software oder ein verteiltes Content-Management-System handelt.

Dabei durchläuft in der Regel jegliche Software einen Lebenszyklus, der die Planung, Anforderungserhebung, Beschaffung, Software-Tests inklusive Freigabe, Installation in Produktivumgebung, Schulung, Betrieb, Updates und Änderungsmanagement sowie Außerbetriebnahme mitsamt Deinstallation umfasst. Dieser Lebenszyklus kann je nach Anwendungskontext variieren, sodass bei einzelnen Anwendungen noch weitere individuelle Zwischenschritte dazu kommen können und auch der Umfang der einzelnen Schritte schwankt.

Allerdings treten bei den aufgeführten Zwischenschritten immer wiederkehrende Aspekte der Informationssicherheit auf, die auf jegliche Art von Software angewendet werden können.

Zielsetzung

Der Baustein zeigt auf, welche Sicherheitsanforderungen zu erfüllen sind, damit allgemeine Software über den gesamten Lebenszyklus hinweg sicher eingesetzt werden kann. Übergeordnetes Ziel ist dabei, die Software und die hiermit verarbeiteten Informationen zu schützen.

Abgrenzung und Modellierung

Der Baustein APP.6 Allgemeine Software ist grundsätzlich für jede Software, die im Informationsverbund eingesetzt wird, anzuwenden. Ausgenommen hiervon sind Betriebssysteme, die auf geschlossenen Systemen wie IoT-Geräten, Routern, Druckern oder eingebetteten Systemen ausgeführt werden. Häufig wird Software gebündelt ausgeliefert (z. B. Office Suites oder Betriebssysteme mit umfangreich integrierten Boardwerkzeugen) oder um Plug-ins, Add-ons oder vergleichbare erweitert. In solchen Fällen kann der Baustein auf das gesamte Softwarebündel einmal angewendet werden.

Dieser Baustein befasst sich nur mit standardisierten und generischen Verfahrensweisen im Lebenszyklus von Software. Es werden keine konkreten Empfehlungen beschrieben, wie Software im Einzelnen konfiguriert und wie sie durch individuelle Schutzmechanismen auf den eingesetzten IT-Systemen abgesichert werden soll. Hierzu sind die spezifischen Bausteine der APP-Schicht anzuwenden.

Die Zwischenschritte Freigabe (inklusive Software-Tests) sowie Patch- und Änderungsmanagement werden nicht in diesem Baustein behandelt, sondern in den Bausteinen OPS.1.1.6 Software-Tests und -Freigaben sowie OPS.1.1.3 Patch- und Änderungsmanagement.

Können Anforderungen an Software nicht von einem fertigen Softwareprodukt erfüllt werden, indem z. B. die Konfiguration angepasst wird, sondern es wird ein individuell entwickeltes Produkt benötigt, dann muss der Baustein APP.7 Entwicklung von Individualsoftware ergänzend modelliert werden.

Software und die damit verbundenen Daten müssen häufig auch in Notfällen verfügbar sein. Erste Überlegungen hierzu zeigt der Baustein DER.4 Notfallmanagement auf.

Wissenswertes

Die International Organization for Standardization (ISO) gibt in der Norm ISO/IEC 27001:2013 im Annex A.14 „Security requirements of information systems“ Anforderungen an die Informationssicherheit von IT-Systemen, die auch bei der Auswahl und dem Einsatz von Software berücksichtigt werden sollten.

Die Common Criteria for Information Technology Security Evaluation (CC) stellen die Basis für international anerkannte Produktzertifizierungen dar. Eine CC-Zertifizierung kann somit als Nachweis für die Informationssicherheit eines Softwareproduktes herangezogen werden.

Das National Institute of Standardisation and Technology formuliert in der NIST Special Publication 800-53 im Appendix F „Family System and Service Acquisition“ unter anderem Anforderungen an die Anschaffung von IT-Produkten, hierunter auch Software.

Das Information Security Forum (ISF) stellt in seinem Standard „The Standard of Good Practice for Information Security“ in dem Kapitel „Business Application Management“ unter anderem Best Practices zur Absicherung von Software vor.
APP.7 Entwicklung von Individualsoftware

Einleitung

Viele Institutionen stehen vor Herausforderungen, die sie nicht mehr hinreichend mit unangepasster Software lösen können. Die mit diesen Herausforderungen verbundenen Aufgabenstellungen bedürfen häufig Softwarelösungen, die auf die individuellen Bedürfnisse der Institutionen zugeschnitten sind. Im Folgenden werden diese Softwarelösungen als Individualsoftware bezeichnet. Hierzu können einerseits Basislösungen, die aus einer Grundmenge an typischen Funktionen bestehen, eingesetzt und individualisiert werden. Die Grundfunktionen werden hierbei für den individuellen Einsatzzweck der Institution angepasst und um individuell benötigte Funktionen erweitert. Gängige Beispiele hierfür sind IT-Anwendungen wie ERP- (Enterprise Resource Planning), CMS- (Content Management Systeme) oder IDM-Systeme (Identity Management). Individualsoftware kann auch vollständig neu von der Institution selbst oder von Dritten entwickelt werden. Hierzu gehören Anwendungen zur Geschäftsprozesssteuerung oder individuell angepasste Fachanwendungen, wie Personalverwaltungssoftware, Verfahren zur Verwaltung von Sozialdaten oder Meldedaten.

Von essentieller Bedeutung ist es hierbei, dass bereits bei der Planung und Konzeptionierung der Individualsoftware auch die benötigten Sicherheitsfunktionen bedacht werden und die Informationssicherheit in dem gesamten Lebenszyklus der Individualsoftware berücksichtigt wird. Fehler in der Planung oder fehlende Sicherheitsfunktionen können im laufenden Betrieb nicht oder nur mit hohem zusätzlichem Aufwand ausgeglichen werden.

Individualsoftware wird dabei in der Regel im Rahmen eines Projektes entwickelt. Hierzu haben sich die unterschiedlichsten Vorgehens- bzw. Projektmanagementmodelle etabliert. Während klassische, lineare Vorgehensmodelle, wie der Wasserfallprozess, sehr gut zu Projekten mit zu Beginn feststehenden Anforderungen passen, ermöglichen agile Vorgehensmodelle, wie Scrum, Individualsoftware iterativ und inkrementell zu entwickeln. Agile Vorgehensmodell können sich somit besser an verändernde Gegebenheiten anpassen, insbesondere wenn zu Beginn noch nicht alle Anforderungen feststehen. Allerdings bieten sie nicht dieselbe Kalkulationssicherheit wie lineare Vorgehensmodelle und passen auch in einigen Fällen nicht zu den klassischen Strukturen der Beschaffungsprozesse, die auf ein lineares Vorgehen ausgerichtet sind.

Zielsetzung

Ziel dieses Bausteins ist es aufzuzeigen, welche grundlegenden Sicherheitsanforderungen bei der Planung und Entwicklung von Individualsoftware zu berücksichtigen sind.

Abgrenzung und Modellierung

Der Baustein APP.7 Entwicklung von Individualsoftware ist für jede Entwicklung einer Individualsoftware einmal anzuwenden.

Aspekte zur Planung, Konzeption und Einsatz von Individualsoftware, wie benötigte Sicherheitsfunktionen festzulegen oder Individualsoftware außer Betrieb zu nehmen, werden im Baustein APP.6 Allgemeine Software behandelt. Er ist daher immer zusammen mit diesem Baustein anzuwenden.

Wenn Software entwickelt wird, liegt sehr häufig ein auftragnehmendes und auftraggebendes Verhältnis vor. Im IT-Grundschutz spiegelt sich dieser Sachverhalt wider, indem der Baustein APP.7 Entwicklung von Individualsoftware die auftragsgebende Seite und der Baustein CON.8 Software-Entwicklung die auftragnehmende Seite behandeln.

Die Freigabe und Tests von Individualsoftware wird im Baustein OPS.1.1.6 Software-Tests und -Freigaben behandelt.

Wissenswertes

Die International Organization for Standardization (ISO) gibt

  • in der Norm ISO/IEC 12207:2008, „System and software engineering - Software life cycle process“ einen Überblick über alle Bestandteile des Lebenszyklus einer Software,
  • in der Norm ISO/IEC 15408-2:2008, „Information technology - Security techniques - Evaluation criteria for IT security - Part 2: Security functional components“ einen Überblick über die Möglichkeiten der Systemabsicherung und
  • in der Norm ISO/IEC 27001:2013, „Information technology - Security technigues - Information security management systems - Requirements“ im Annex A, A.14 System acquisition, development and maintenance“ Anforderungen an die System-Entwicklung und den -betrieb.

Das Information Security Forum (ISF) macht in seinem Standard „The Standard of Good Practice for Information Security“ in der „Area BA Business Application Management“ Anforderungen an das Management von Business-Anwendungen.

Das National Institute of Standards and Technology stellt in der „NIST Special Publication 800-53“ im Apendix F-SA „Family: System and Services acquisition, Family: System and communications protection and Family: System and information integrity“ weitergehende Anforderungen an den Umgang mit Individualsoftware.

1.1 Referencer

1.2 Identificerede krav

1.3 Relaterede reguleringer

2. Identificerede krav

Krav

3. Relaterede reguleringer

Reguleringer