chrisbst48/itgrundschutzcompendium_2023 huggingface dataset:
APP.4.6.A6 Vollständige Ausführung von Berechtigungsprüfungen
Zusätzlich SOLLTE am Feld der Grund für die Ausnahme dokumentiert werden. Bei einer Berechtigungsprüfung im ABAP-Code (AUTHORITY-CHECK ) SOLLTE sichergestellt sein, dass alle Felder des relevanten Berechtigungsobjekts überprüft werden. Wenn einzelne Felder tatsächlich nicht benötigt werden, SOLLTEN sie als DUMMY gekennzeichnet werden.
APP.4.6.A7 Berechtigungsprüfung während der Eingabeverarbeitung
Wenn ein Bildschirmelement abgeschaltet wurde, dann SOLLTE eine Anwendung NICHT ohne adäquate Berechtigungsprüfungen auf Ereignisse dieses Elements reagieren. Funktionscodes und Bildschirmelemente von ABAP-Dynpro-Anwendungen SOLLTEN konsistent sein. Wenn bestimmte Einträge eines Dynpro-Menüs ausgeblendet oder einzelne Schaltflächen deaktiviert werden, dann SOLLTEN auch die zugehörigen Funktionscodes nicht ausgeführt werden.
APP.4.6.A8 Schutz vor unberechtigten oder manipulierenden Zugriffen auf das Dateisystem
Wenn Zugriffe auf Dateien des SAP-Servers von Eingaben der Benutzenden abhängen, SOLLTEN diese Eingaben vor dem Zugriff validiert werden.
APP.4.6.A9 Berechtigungsprüfung in remote-fähigen Funktionsbausteinen
Es SOLLTE sichergestellt werden, dass alle remote-fähigen Funktionsbausteine im Programmcode explizit prüfen, ob der Aufrufende berechtigt ist, die zugehörige Businesslogik auszuführen.
APP.5.2 Microsoft Exchange und Outlook
Anwendung R2
APP.5.2.A1 Planung des Einsatzes von Exchange und Outlook
• Nutzung von funktionalen Erweiterungen sowie Dabei MUSS sie mindestens folgende Punkte beachten: • Aufbau der E-Mail-Infrastruktur, • die zu verwendenden Protokolle. • einzubindende Clients beziehungsweise Server, Bevor Exchange und Outlook eingesetzt werden, MUSS die Institution deren Einsatz sorgfältig planen.
APP.5.2.A10 Sichere Konfiguration von Outlook
Der IT-Betrieb SOLLTE Outlook so konfigurieren, dass nur notwendige Informationen an andere Benutzende übermittelt werden. Der IT-Betrieb SOLLTE für jeden Benutzenden ein eigenes Outlook-Profil mit benutzendenspezifischen Einstellungen anlegen. Der IT-Betrieb SOLLTE die Benutzenden darüber informieren, welche Informationen automatisiert an andere Benutzende übermittelt werden. Lesebestätigungen und Informationen, die auf die interne Struktur der Institution schließen lassen, SOLLTEN NICHT an Externe übermittelt werden.
APP.5.2.A11 Absicherung der Kommunikation zwischen Exchange-Systemen
• Administrationsschnittstellen, • Public-Key-Infrastruktur, auf der die E-Mail-Verschlüsselung von Outlook basiert. • Server-Server-Kommunikation und • vorhandene Web-based-Distributed-Authoring-and-Versioning-(WebDAV)-Schnittstellen, • Client-Server-Kommunikation, Der IT-Betrieb SOLLTE nachvollziehbar entscheiden, mit welchen Schutzmechanismen die Kommunikation zwischen Exchange-Systemen abgesichert wird. Insbesondere SOLLTE der IT-Betrieb festlegen, wie die Kommunikation zu folgenden Schnittstellen abgesichert wird:
APP.5.2.A12 Einsatz von Outlook Anywhere, MAPI over HTTP und Outlook im Web
Der IT-Betrieb SOLLTE Outlook Anywhere, MAPI over HTTP und Outlook im Web entsprechend den Sicherheitsanforderungen der Institution konfigurieren. Der Zugriff auf Exchange über das Internet SOLLTE auf die notwendigen Benutzenden beschränkt werden.
APP.5.2.A13 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A14 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A15 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A16 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A17 Verschlüsselung von Exchange-Datenbankdateien
• Mechanismen zur Absicherung der Daten in einer PST-Datei. Weitere Aspekte für lokale PST-Dateien, die berücksichtigt werden SOLLTEN, wenn Exchange-Systemdatenbanken verschlüsselt werden, sind: • eigene Verschlüsselungsfunktionen, • Verschlüsselungsgrade sowie Mechanismen wie z. B. Encrypting File System oder Windows BitLocker Laufwerkverschlüsselung SOLLTEN zur Absicherung der PST-Dateien genutzt werden. Der IT-Betrieb SOLLTE ein Konzept für die Verschlüsselung von PST-Dateien und Informationsspeicher-Dateien erstellen. Die Institution SOLLTE die Benutzenden über die Funktionsweise und die Schutzmechanismen bei der Verschlüsselung von PST-Dateien informieren.
APP.5.2.A18 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A19 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A2 Auswahl einer geeigneten Exchange-Infrastruktur
Der IT-Betrieb MUSS auf Basis der Planung des Einsatzes von Exchange entscheiden, mit welchen IT-Systemen und Anwendungskomponenten sowie in welcher hierarchischen Abstufung die Exchange-Infrastruktur realisiert wird. Im Rahmen der Auswahl MUSS auch entschieden werden, ob die Exchange-Systeme als Cloud- oder lokaler Dienst betrieben werden sollen.
APP.5.2.A3 Berechtigungsmanagement und Zugriffsrechte
Zusätzlich zum allgemeinen Berechtigungskonzept MUSS die Institution ein Berichtigungskonzept für die Systeme der Exchange-Infrastruktur erstellen, geeignet dokumentieren und anwenden. Der IT-Betrieb MUSS serverseitige Benutzendenprofile für einen rechnerunabhängigen Zugriff der Benutzenden auf Exchange-Daten verwenden. Er MUSS die Standard-NTFS-Berechtigungen für das Exchange-Verzeichnis so anpassen, dass nur autorisierte Administrierende und Systemkonten auf die Daten in diesem Verzeichnis zugreifen können.
APP.5.2.A4 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A5 Datensicherung von Exchange
Gelöschte Exchange-Objekte SOLLTEN erst nach einiger Zeit aus der Datenbank entfernt werden. Dabei MÜSSEN insbesondere die Exchange-Server-Datenbanken gesichert werden. Exchange-Server MÜSSEN vor Installationen und Konfigurationsänderungen sowie in zyklischen Abständen gesichert werden.
APP.5.2.A6 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A7 Migration von Exchange-Systemen
Der IT-Betrieb SOLLTE alle Migrationsschritte gründlich planen und dokumentieren. Der IT-Betrieb SOLLTE dabei Postfächer, Objekte, Sicherheitsrichtlinien, Active-Directory-Konzepte sowie die Anbindung an andere E-Mail-Systeme berücksichtigen. Außerdem SOLLTE er Funktionsunterschiede zwischen verschiedenen Versionen von Exchange beachten. Das neue Exchange-System SOLLTE, bevor es installiert wird, in einem separaten Testnetz geprüft werden.
APP.5.2.A8 ENTFALLEN
Diese Anforderung ist entfallen.
APP.5.2.A9 Sichere Konfiguration von Exchange-Servern
Bei der Verwendung von funktionalen Erweiterungen SOLLTE sichergestellt sein, dass die definierten Anforderungen an die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit weiterhin erfüllt sind. Für vorhandene benutzendenspezifische Anpassungen SOLLTE ein entsprechendes Konzept erstellt werden. Der IT-Betrieb SOLLTE die Protokollierung des Exchange-Systems aktivieren. Konnektoren SOLLTEN sicher konfiguriert werden. Der IT-Betrieb SOLLTE Exchange-Server entsprechend der Vorgaben aus der Sicherheitsrichtlinie installieren und konfigurieren.
APP.5.3 Allgemeiner E-Mail-Client und -Server
Anwendung R2
APP.5.3.A1 Sichere Konfiguration der E-Mail-Clients
Bevor Dateianhänge aus E-Mails geöffnet werden, MÜSSEN sie auf Schadsoftware überprüft werden. E-Mail-Clients MÜSSEN so konfiguriert werden, dass sie eventuell vorhandenen HTML-Code und andere aktive Inhalte in E-Mails nicht automatisch interpretieren. Vorschaufunktionen für Datei-Anhänge MÜSSEN so konfiguriert werden, dass sie Dateien nicht automatisch interpretieren. E-Mail-Filterregeln sowie die automatische Weiterleitung von E-Mails MÜSSEN auf notwendige Anwendungsfälle beschränkt werden. Ist dies nicht möglich, MUSS die Institution darauf hinweisen, dass die Konfiguration nicht selbstständig geändert werden darf. Die Dateianhänge MÜSSEN auf dem Client oder auf dem E-Mail-Server überprüft werden. Die Institution MUSS eine sichere Konfiguration für die E-Mail-Clients vorgeben. E-Mail-Clients MÜSSEN für die Kommunikation mit E-Mail-Servern über nicht vertrauenswürdige Netze eine sichere Transportverschlüsselung einsetzen. Die E-Mail-Clients MÜSSEN den Benutzenden vorkonfiguriert zur Verfügung gestellt werden. Die Institution SOLLTE sicherstellen, dass sicherheitsrelevante Teile der Konfiguration nicht von Benutzenden geändert werden können.
APP.5.3.A10 Ende-zu-Ende-Verschlüsselung und Signatur(umbenannt von Ende-zu-Ende-Verschlüsselung in Vorjahres-Edition)
Die Institution SOLLTE eine Ende-zu-Ende-Verschlüsselung sowie digitale Signaturen für E-Mails einsetzen. Es SOLLTEN nur Protokolle zur Verschlüsselung und Signatur genutzt werden, die dem aktuellen Stand der Technik entsprechen.
APP.5.3.A11 Einsatz redundanter E-Mail-Server
Die redundanten E-Mail-Server SOLLTEN mit geeigneter Priorität in den MX-Records der betroffenen Domains hinterlegt werden. Die Institution SOLLTE festlegen, wie E-Mails zwischen den E-Mail-Servern synchronisiert werden. Die Institution SOLLTE redundante E-Mail-Server betreiben.
APP.5.3.A12 Überwachung öffentlicher Block-Listen(umbenannt von Überwachung öffentlicher Blacklists in Vorjahres-Edition)
Der IT-Betrieb SOLLTE regelmäßig überprüfen, ob die E-Mail-Server der Institution auf öffentlichen Spam- oder Block-Listen aufgeführt sind.
APP.5.3.A13 TLS-Reporting
Die Institution SOLLTE TLS-Reporting einsetzen. Es SOLLTE festgelegt werden, ob TLS-Reports an andere Institutionen versendet werden.
APP.5.3.A2 Sicherer Betrieb von E-Mail-Servern
Die Institution MUSS alle erlaubten E-Mail-Protokolle und Dienste festlegen. Der IT-Betrieb SOLLTE den E-Mail-Versand durch unsichere Netze über unverschlüsselte Verbindungen deaktivieren. Der IT-Betrieb MUSS den E-Mail-Server so konfigurieren, dass E-Mail-Clients nur über eine sichere Transportverschlüsselung auf Postfächer zugreifen können, wenn dies über nicht vertrauenswürdige Netze passiert. Der IT-Betrieb MUSS Schutzmechanismen gegen Denial-of-Service (DoS)-Attacken ergreifen. Außerdem MUSS der IT-Betrieb den E-Mail-Server so einstellen, dass er nicht als Spam-Relay missbraucht werden kann. Werden Nachrichten auf einem E-Mail-Server gespeichert, MUSS der IT-Betrieb eine geeignete Größenbeschränkung für das serverseitige Postfach einrichten und dokumentieren. Für den E-Mail-Empfang über nicht vertrauenswürdige Netze MÜSSEN E-Mail-Server eine sichere Transportverschlüsselung anbieten. Der Empfang von E-Mails über unverschlüsselte Verbindungen SOLLTE deaktiviert werden. Versenden E-Mail-Server von sich aus E-Mails an andere E-Mail-Server, SOLLTEN sie eine sichere Transportverschlüsselung nutzen.
APP.5.3.A3 Datensicherung und Archivierung von E-Mails
Die Institution SOLLTE ebenfalls bei der Archivierung beachten, dass E-Mails möglicherweise nur lokal auf Clients gespeichert sind. Dafür MUSS die Institution regeln, wie die gesendeten und empfangenen E-Mails der E-Mail-Clients sowie die E-Mails auf den Servern gesichert werden. Der IT-Betrieb MUSS die Daten der E-Mail-Server und -Clients regelmäßig sichern.
APP.5.3.A4 Spam- und Virenschutz auf dem E-Mail-Server
Die Einführung und Nutzung von E-Mail-Filterprogrammen MUSS mit den Datenschutzbeauftragten und der Personalvertretung abgestimmt werden. Der IT-Betrieb MUSS sicherstellen, dass auf E-Mail-Servern eingehende und ausgehende E-Mails, insbesondere deren Anhänge, auf Spam-Merkmale und schädliche Inhalte überprüft werden. Die Institution MUSS festlegen, wie mit verschlüsselten E-Mails zu verfahren ist, wenn diese nicht durch das Virenschutzprogramm entschlüsselt werden können.
APP.5.3.A5 Festlegung von Vertretungsregelungen bei E-Mail-Nutzung
Bei der Weiterleitung von E-Mails MÜSSEN datenschutzrechtliche Aspekte berücksichtigt werden. Die Institution SOLLTE für Autoreply-Funktionen in E-Mail-Programmen Regelungen etablieren, die beschreiben, wie diese Funktionen sicher verwendet werden können. Wenn die Autoreply-Funktion benutzt wird, SOLLTEN keine internen Informationen weitergegeben werden. Die Institution SOLLTE Vertretungsregelungen für die Bearbeitung von E-Mails festlegen. Werden E-Mails weitergeleitet, SOLLTEN die Vertretenen mindestens darüber informiert werden.
APP.5.3.A6 Festlegung einer Sicherheitsrichtlinie für E-Mail
• wie E-Mails auf gefälschte Absendeadressen überprüft werden, Die Institution SOLLTE eine Sicherheitsrichtlinie für die Nutzung von E-Mails erstellen und regelmäßig aktualisieren. • welche offenen E-Mail-Verteiler verwendet werden dürfen, • ob E-Mails privat genutzt werden dürfen, • wie mit E-Mails und Postfächern ausscheidender Personen umgegangen werden soll, • ob und wie Webmail-Dienste genutzt werden dürfen, • wer für Gruppenpostfächer zuständig ist, • wie mit Datei-Anhängen umgegangen werden soll und • ob Benutzende die HTML-Darstellung von E-Mails aktivieren dürfen. Die E-Mail-Sicherheitsrichtlinie SOLLTE ergänzend für die Administrierenden die Einstellungsoptionen der E-Mail-Anwendungen beinhalten, außerdem die Vorgaben für mögliche Zugriffe von anderen Servern auf einen E-Mail-Server. Auch Angaben zu berechtigten Zugriffspunkten, von denen aus auf einen E-Mail-Server zugegriffen werden darf, SOLLTEN in der Richtlinie enthalten sein. Die E-Mail-Sicherheitsrichtlinie SOLLTE den Umgang mit Newsgroups und Mailinglisten regeln. Die Institution SOLLTE alle Benutzenden und Administrierenden über neue oder veränderte Sicherheitsvorgaben für E-Mail-Anwendungen informieren. Die E-Mail-Sicherheitsrichtlinie SOLLTE konform zu den geltenden übergeordneten Sicherheitsrichtlinien der Institution sein. Die Institution SOLLTE prüfen, ob die Sicherheitsrichtlinie korrekt angewendet wird. Die E-Mail-Sicherheitsrichtlinie für Benutzende SOLLTE vorgeben, • welche Zugriffsrechte es gibt, • wie sich übermittelte Informationen absichern lassen, • wie die Integrität von E-Mails überprüft werden soll,
APP.5.3.A7 Schulung zu Sicherheitsmechanismen von E-Mail-Clients für Benutzende(umbenannt von Schulung zu Sicherheitsmechanismen von E-Mail-Clients für Benutzer in Vorjahres-Edition)
Die Schulungen SOLLTEN ebenfalls darauf eingehen, wie E-Mails von gefälschten Absendeadressen erkannt werden können. Die Institution SOLLTE davor warnen, an E-Mail-Kettenbriefen teilzunehmen oder zu viele Mailinglisten zu abonnieren. Die Institution SOLLTE das Personal darüber aufklären, welche Risiken entstehen, wenn E-Mail-Anwendungen benutzt werden und wie sicher mit E-Mails umgegangen werden kann. Dies SOLLTE zusätzlich zur allgemeinen Schulung und Sensibilisierung geschehen. Die Institution SOLLTE zu den Gefahren sensibilisieren, die entstehen können, wenn E-Mail-Anhänge geöffnet werden.
APP.5.3.A8 Umgang mit Spam durch Benutzende(umbenannt von Umgang mit Spam durch Benutzer in Vorjahres-Edition)
Falls die Institution über ein zentrales Spam-Management verfügt, SOLLTEN die Benutzenden Spam-E-Mails an dieses weiterleiten und die E-Mails danach löschen. Sie SOLLTEN Links in diesen E-Mails nicht folgen. Die Benutzenden SOLLTEN auf unerwünschte E-Mails nicht antworten. Grundsätzlich SOLLTEN die Benutzenden alle Spam-E-Mails ignorieren und löschen.
APP.5.3.A9 Erweiterte Sicherheitsmaßnahmen auf dem E-Mail-Server
Die Institution SOLLTE festlegen, ob DMARC-Reporte über empfangene E-Mails an andere Institutionen versendet werden. Die E-Mail-Server einer Institution SOLLTEN eingehende E-Mails mittels des Sender Policy Framework (SPF) und mit Hilfe von DomainKeys Identified Mail (DKIM) überprüfen. Die Institution SOLLTE die E-Mail-Kommunikation über DANE und MTA-STS absichern. Die Institution SOLLTE selbst DKIM und SPF einsetzen, um von ihr versendete E-Mails zu authentisieren. Wird SPF verwendet, SOLLTEN alle sendeberechtigten E-Mail-Server für eine Domain im SPF-Eintrag angegeben werden. Der SPF-Eintrag SOLLTE den -all Parameter enthalten. Der Softfail-Parameter („~“) SOLLTE nur zu Testzwecken verwendet werden. Die Institution SOLLTE Domain-based Message Authentication, Reporting and Conformance (DMARC) nutzen, um festzulegen, wie von ihr versendete E-Mails durch den empfangenden E-Mail-Server überprüft werden sollen. DMARC-Einträge SOLLTEN vorgeben, dass E-Mails im Fehlerfall abgewiesen werden. DMARC-Reporte SOLLTEN regelmäßig ausgewertet werden.
APP.5.4 Unified Communications und Collaboration (UCC)
Anwendung R2
APP.5.4.A1 Planung von UCC (neu seit Vorjahres-Edition)
Es MUSS umfassend und detailliert geplant werden, wie und für welchen Zweck UCC eingesetzt werden soll. • Anforderungen zur Absicherung von UCC • Einsatzzwecke der vorgesehenen UCC-Dienste • Funktionale Anforderungen an UCC als Gesamtheit und an die einzelnen UCC-Dienste • Aufstellen von organisatorischen Regelungen, um die UCC-Dienste zu benutzen Bei der Planung MUSS berücksichtigt werden, wie UCC in die IT-Infrastruktur der Institution integriert wird. • Produkt- und Dienstauswahl ausgehend von den definierten Anforderungen • Analyse der Kommunikation und der Abhängigkeiten von UCC-Diensten untereinander Die Planung MUSS insbesondere die Wechselwirkungen der UCC-Dienste berücksichtigen und mindestens folgende Aspekte beinhalten: • Festlegung zu Informationen und Daten, die über UCC übertragen werden dürfen Hierbei MUSS insbesondere betrachtet werden, ob und wie die Systeme der UCC-Dienste innerhalb des Netzes separiert werden sollen und welche Schnittstellen zu weiteren benutzten Anwendungen notwendig sind.
APP.5.4.A10 Absicherung und Einschränkung von Auswertungen von Inhalten (neu seit Vorjahres-Edition)
Besondere Beachtung SOLLTEN KI-Funktionen und die Übertragung von Daten an Onlinedienste erhalten. Die Art einer (automatischen) Auswertung von Konversationsinhalten SOLLTE schon im Vorfeld sorgfältig geprüft werden und ihr Nutzen gegen den Schutzbedarf abgewogen werden. Es SOLLTE die Möglichkeit bestehen, entsprechende Funktionen entweder vollständig oder pro Konversation zu deaktivieren und eine inhaltliche Auswertung der Kommunikation zu verhindern. Werden Inhalte über den Zweck der Konversation hinausgehend ausgewertet, MUSS dazu auch eine Zustimmung der an der Konversation teilnehmenden Personen eingeholt werden. Werden während der Auswertung von Konversationen persistente Daten erzeugt, SOLLTEN für diese geeignete Schutzmaßnahmen umgesetzt werden.
APP.5.4.A11 Sicherstellung der Verfügbarkeit von Kommunikationsdiensten (neu seit Vorjahres-Edition)
Die Verfügbarkeit von UCC-Diensten SOLLTE insbesondere durch folgende technische Maßnahmen sichergestellt werden: Die Verfügbarkeit SOLLTE durch ein Monitoring der UCC-Dienste überwacht werden. Zudem SOLLTE ein SIP-Provider, der Rufnummern bereitstellt und den Übergang ins öffentliche Telefonnetz bildet, hochverfügbar an das eigene Netz angebunden werden. • möglichst autark funktionierende UCC-Dienste Darüber hinaus SOLLTE bei Cloud-basierten UCC-Diensten der Cloud-Provider sowie der Internet-Provider ausfallsicher an das eigene Netz angebunden werden. • Benutzung von Call Admission Control (CAC) zur Qualitätssicherung von Telefonie und Video-Diensten • redundante Auslegung zentraler Server und Dienste
APP.5.4.A12 Einbindung von UCC in die Notfallplanung (neu seit Vorjahres-Edition)
Zudem SOLLTE ein Notfallplan für die UCC-Dienste erstellt werden, in dem notwendige Konfigurationen sowie Routing-Anpassungen, die über den Telefonie-Provider realisiert werden, behandelt werden. Ausgehend von einer Business Impact Analyse SOLLTE geprüft werden, welche UCC-Dienste in der Notfallplanung berücksichtigt werden sollen. Hierbei SOLLTEN in Notfallsituationen für einzelne UCC-Dienste alternative Anwendungen bereitgestellt werden. Insbesondere SOLLTE für die Benutzenden die Erreichbarkeit von wichtigen Diensten wie der Notruf gewährleistet werden. Ebenso SOLLTE der Wiederanlauf der UCC-Komponenten und -Dienste unter Berücksichtigung der Wechselwirkungen innerhalb der UCC-Dienste festgelegt werden.
APP.5.4.A13 Sichere Administration von SIP-Trunks (neu seit Vorjahres-Edition)
• Änderungen an Routing-Konfigurationen Wenn SIP-Trunks administriert werden, SOLLTE für folgende Tätigkeiten ein 4-Augen-Prinzip angewendet werden: • Änderungen an Parametern, die im Rahmen von Call Admission Control benutzt werden • Änderungen hinsichtlich der Verschlüsselung sowohl in Richtung des eigenen Netzes als auch in Richtung des Provider-Netzes • Änderungen an weiteren sicherheitsrelevanten Konfigurationen wie der lokalen Speicherung von Verbindungsdaten
APP.5.4.A14 Ende-zu-Ende-Verschlüsselung (neu seit Vorjahres-Edition)
Bei Konversationen zwischen UCC-Diensten von verschiedenen Herstellenden SOLLTEN die übertragenen Informationen eingeschränkt werden, sofern eine Ende-zu-Ende-Verschlüsselung nach Stand der Technik nicht möglich ist. Für UCC-Kommunikation SOLLTE eine sichere Ende-zu-Ende-Verschlüsselung benutzt werden. Die Ende-zu-Ende-Verschlüsselung SOLLTE sich sowohl auf die Signalisierung als auch auf die Mediendaten von Audio- und Videokommunikation mit zwei oder mehr Teilnehmenden erstrecken.
APP.5.4.A15 Einschränkung von KI-Funktionen (neu seit Vorjahres-Edition)
Die Benutzung von KI-Funktionen SOLLTE deaktiviert oder auf ein Minimum reduziert werden. Ist eine permanente Deaktivierung nicht möglich oder erwünscht, SOLLTE festgelegt werden, dass Benutzende der UCC-Dienste zu Beginn einer Konversation zielgerichtet KI-Funktionen deaktivieren, falls dies möglich ist.
APP.5.4.A16 Einsatz eines SBC an weiteren Netzübergängen (neu seit Vorjahres-Edition)
Hierbei SOLLTEN insbesondere Netzübergänge zwischen Netzsegmenten mit unterschiedlichem Schutzbedarf berücksichtigt werden. Der SBC SOLLTE sicherstellen, dass die Verschlüsselungsmechanismen an den SBC-gesicherten Netzsegmentübergängen anforderungskonform realisiert werden. Ergänzend zu einem SBC am Netzübergang zum Provider, SOLLTEN weitere SBC an internen Netzübergängen eingesetzt werden.
APP.5.4.A17 Einschränkung der Benutzung von UCC-Diensten (neu seit Vorjahres-Edition)
• Benutzung einer Multi-Faktor-Authentisierung für Benutzende Folgende Aspekte SOLLTEN mindestens berücksichtigt werden, um die UCC-Dienste sowie die übertragenen Daten zusätzlich abzusichern: • Einschränkung der Dienste entsprechend des Schutzbedarfs der übertragenen Informationen • Deaktivierung von Funktionen für externe Benutzende • Deaktivierung der Speicherung von Metadaten • Einschränkung der Sichtbarkeit von kommunikationsbezogenen Daten für Administrierende Darüber hinaus SOLLTEN zusätzliche technische und organisatorische Vorkehrungen getroffen werden, um Konversationen über die Vergabe von PINs bzw. Passwörtern hinaus abzusichern.
APP.5.4.A18 Einbindung von UCC in ein Sicherheitsmonitoring (neu seit Vorjahres-Edition)
Dies SOLLTE mindestens für Komponenten umgesetzt werden, die wie Multipoint Control Units Verschlüsselungsendpunkte realisieren oder die wie SBCs an Vertrauensgrenzen positioniert sind. Die zentralen UCC-Komponenten SOLLTEN durch ein Sicherheitsmonitoring überwacht werden. Wird für die IT der Institution ein System zur zentralen Detektion und automatisierten Echtzeitüberprüfung von Ereignismeldungen eingesetzt, SOLLTEN die zentralen UCC-Komponenten hierin eingebunden werden.
APP.5.4.A2 Berücksichtigung von UCC in der Netzplanung (neu seit Vorjahres-Edition)
• Netzkapazitäten (Bandbreite) für die festgelegte Benutzung der UCC-Dienste wie Videokonferenzen • Verfügbarkeit von WLAN für mobile Endgeräte Falls die UCC-Dienste erweitert werden, SOLLTEN diese Aspekte erneut geprüft werden. Falls die Leistungsparameter nicht erfüllt werden, MUSS festgelegt werden, wie hiermit umgegangen wird. Sollen UCC-Dienste benutzt werden, SOLLTEN im Rahmen der allgemeinen Netzplanung insbesondere folgende Aspekte berücksichtigt werden: • Erfüllung der UCC-spezifischen Leistungsparameter wie Paketverlust, Jitter und Latenz • Berücksichtigung von Power over Ethernet (PoE) für stationäre Endgeräte Bevor UCC-Dienste eingeführt werden, MUSS geprüft werden, ob das Netz die UCC-spezifischen Leistungsparameter erfüllt.
APP.5.4.A3 Initiales und regelmäßiges Testen der UCC-Dienste (neu seit Vorjahres-Edition)
Für die UCC-Dienste MÜSSEN initial Tests durchgeführt werden, die verifizieren, dass die UCC-Komponenten untereinander und mit anderen UCC-Diensten interferenzfrei funktionieren. Ebenfalls MÜSSEN Tests mit ausgewählten Benutzenden durchgeführt werden, um insbesondere Wechselwirkungen mit anderen Anwendungen zu überprüfen. Diese Tests SOLLTEN wiederholt werden, wenn die UCC-Dienste erweitert oder verändert werden. Zusätzlich SOLLTE die Konfiguration der UCC-Dienste in regelmäßigen Abständen auf Plausibilität und Konformität für die festgelegten Einsatzzwecke überprüft werden.