Sichere Kommunikationsprotokolle in der Gebäudeautomation – im Fokus: BACnet Secure Connect

BACnet ist ein herstellerneutraler Kommunikationsstandard für die Gebäudeautomation.

Die erste Version von BACnet wurde bereits im Jahr 1995 veröffentlicht. BACnet Secure Connect (SC) ergänzt als neuer Protokoll-Layer den bisherigen BACnet-Standard. BACnet/SC wurde im Jahr 2019 von der ASHRAE im Addendum bj der Version 125-2016 veröffentlicht [2]. Normativ wird der BACnet-Standard in der DIN EN ISO 16484-6 definiert [3].

Die Ergänzung um BACnet/SC wurde im Jahr 2020 in dem Annex AB veröffentlicht. BACnet eignet sich als interoperabler Kommunikationsstandard in der Gebäudeautomation, um die gewerkeübergreifende Integration von HKLS-Anlagen (Heizungs-, Klima-, Lüftungs- und Sanitäranlagen), Lichtsteuerung, Verschattung, Sicherheit und Brandmeldetechnik zu realisieren. Eine zentrale Rolle spielen hierbei die intelligenten Automationsstationen, die ein einheitliches Gesamtsystem durch Vernetzung untereinander, mit Geräten aus der Feldebene und mit übergeordneten Management-Bedieneinrichtungen aufbauen. In Abbildung 1 ist ein schematischer Aufbau einer Gebäudeautomation unter Verwendung von BACnet als führendes Kommunikationsprotokoll visualisiert. In der Managementebene kann sich eine BACnet-Workstation oder eine Gebäudemanagementplattform befinden. In der Automationsebene werden die klassischen TGA-Anlagen über die Automationsstationen angebunden. In der Feldebene befinden sich die Raumautomationsstationen. An die Raumautomation können verschiedenste Aktoren und Sensoren mit unterschiedlichen Kommunikationsprotokollen angebunden werden.

Das BACnet-Kommunikationsprotokoll fungiert unabhängig von einer konkreten Anwendung und kann somit herstellerunabhängig für Komponenten der Gebäudeautomation genutzt werden. BACnet zeichnet sich weiterhin dadurch aus, dass es zu einer Vielzahl von Kommunikationsprotokollen kompatibel ist. Hierfür wurde der Standard stets so fortgeschrieben, dass die Kompatibilität zu älteren Protokollversionen gewahrt wurde. Das BACnet-Protokoll wurde in Anlehnung an das ISO/OSI-Schichtenmodell entwickelt. Der Aufbau wird auch in der Norm ISO 16484-5:2022 in Anlehnung an das ISO/OSI-Schichtenmodell definiert, siehe Abbildung 2. Gemäß dieser Abbildung bleiben der BACnet Application Layer und der BACnet Network Layer immer bestehen, und für unterschiedliche Protokollvarianten können die darunterliegenden Schichten beliebig ausgetauscht werden.

Die bisher wohl am häufigsten verwendeten BACnet-Varianten sind BACnet MS-TP und BACnet-IP. MS/TP (Master Slace / Token Passing) nutzt zur Datenübertragung die serielle Schnittstelle RS-485. IP-Kommunikation via BACnet wurde durch den Annex J des BACnet-Standards eingeführt. Bei BACnet/IP handelt es sich um ein verbindungsloses Protokoll, welches das User Datagram Protocol (UDP) als Transportschicht nutzt. Als Port wird in BACnet-Netzwerken in der Regel der UDP-Port 47808 verwendet. Ein BACnet/IP-Netzwerk unterscheidet sich in der Topologie sowie in vielen weiteren Aspekten von BACnet-MS/TP-Netzwerken.

Der */IP-Standard basiert auf unverschlüsselter UDP-Broadcast-Kommunikation. Bei der UDP-Broadcast-Kommunikation müssen alle Netzwerkteilnehmer jede Nachricht verarbeiten. Um den Netzwerkverkehr zu regulieren, können BACnet/IP Broadcast Management Devices (BBMD) eingesetzt werden. Für mehr Informationen zu BACnet/IP-Netzwerken wird an dieser Stelle auf den Netzwerk Insider 06/2022 verwiesen [5]. Der BACnet/SC-Standard wurde unter anderem aufgrund der Tatsache entwickelt, dass der BACnet/IP-Netzwerkverkehr unverschlüsselt über UDP/IP stattfindet, die Broadcast-Kommunikation das Netzwerk belastet und die Verwendung von statischen IP-Adressen eine flexible Netzwerktopologie verhindert. Im Nachfolgenden wird zunächst auf die Grundlagen von BACnet/SC eingegangen.

BACnet/SC-Grundlagen

Im Wesentlichen wurde mit BACnet/SC der in Anlehnung an Abbildung 2 definierte Data Link Layer ersetzt. Eine detaillierte Gegenüberstellung des ISO/OSI-Schichtenmodells, des BACnet-Schichtenmodells, des äquivalenten BACnet/IP-Aufbaus sowie des äquivalenten BACnet/SC-Aufbaus ist der Abbildung 3 zu entnehmen.

Bei Secure Connect werden standardisierte und bewährte IT-Technologien wie das WebSocket-Protokoll HTTPS verwendet, welches durch TLS v.1.3 und X.509-Zertifikate gesichert ist. Das Verschlüsselungsprotokoll Transport Layer Security 1.3 (TLS 1.3) entspricht dem aktuellen Stand der Technik. Dieser bietet eine 256-Bit-Verschlüsselung und nutzt eine Public-Key-Infrastruktur. Unter der Voraussetzung einer richtigen Verwendung können auch TLS-1.2-Verbindungen als sicher eingestuft werden. Alle früheren Protokollversionen werden vom IEEE als unsicher eingestuft. Es wird stets empfohlen, die aktuelle Version des Verschlüsselungsprotokolls zu nutzen. Die zuvor beschriebenen Protokollstandards werden in der IT bereits seit Langem verwendet. Die neue Absicherung der Kommunikation wird schematisch in Abbildung 4 visualisiert.

Im Vergleich zu BACnet/IP wird demnach keine unverschlüsselte UDP/IP-Kommunikation mehr genutzt, sondern verschlüsselte und gerichtete TCP/IP-Kommunikation. Eine aufwändige BBMD-Konfiguration ist somit nicht mehr notwendig. Zudem ist nun eine Adressierung der Netzwerk-Teilnehmer über dynamische IP-Adressen möglich. Da ausschließlich der Data Link Layer erneuert wurde, ist BACnet/SC abwärtskompatibel. Aus diesem Grund ist eine Kommunikation mit bestehenden BACnet/IP- und BACnet-MS/TP-Netzwerken problemlos möglich. Mithilfe des WebSocket-Protokolls können bidirektionale Verbindungen zwischen den BACnet/SC-Teilnehmern auf Basis des TCP-Protokolls hergestellt werden. Der genaue Kommunikationsaufbau wird nachfolgend beschrieben.

Netzwerk-Architektur

Durch die Neuerung ändert sich die Architektur des BACnet-Netzwerks. Bisher wurden in der Regel flache Layer-2-Netzwerkarchitekturen genutzt [5]. Bei */SC wird eine Hub-and-Spoke-Architektur, auch als Sterntopologie bekannt, eingeführt.

Der Primary-Hub ist der zentrale Punkt der Architektur, zu dem sich die einzelnen Konten (Nodes) des Netzwerks verbinden, siehe Abbildung 5 (a). Die Kommunikation findet grundsätzlich vom Node ausgehend zum Hub statt. Es ist zudem möglich, direkte Verbindungen zwischen */SC-Nodes aufzubauen. Diese direct connections sind in den Abbildungen durch gestrichelte Pfeile gekennzeichnet. Um keinen Single Point of Failure im Netzwerk zu haben, sollte ein BACnet/SC-Device als Failover-Hub definiert werden. Im Falle eines Systemausfalls des Primary-Hubs übernimmt der Failover-Hub automatisiert dessen Rolle, siehe Abbildung 5 (b).

Ein BACnet/SC-Hub muss nicht zwingend durch eine Automationsstation dargestellt werden. Es ist auch möglich, eine dafür ausgelegte Gebäudemanagementplattform als Hub zu definieren, siehe Abbildung 6. Diese Netzwerkarchitektur ist insbesondere dann interessant, wenn mehrere Gebäude, oder Standorte, einen gemeinsamen Hub nutzen sollen. In diesem Szenario ist es auch möglich, den Primary-Hub in einer privaten Cloud zu betreiben. Eine solche Architektur kann den Managementaufwand eines */SC-Netzwerks deutlich reduzieren.

Da */SC auch abwärtskompatibel ist, können Bestandsnetzwerke um ein */SC-Netzwerk erweitert werden. Somit können bestehende BACnet/IP- und MS-TP-Netzwerke beibehalten und trotzdem ein sicherer Netzwerkverkehr innerhalb des GA-Netzwerks sichergestellt werden. Eine entsprechende Netzwerkarchitektur ist in Abbildung 7 schematisch dargestellt. Bei einer solchen Netzwerkarchitektur ist darauf zu achten, dass möglicherweise bisher in sich geschlossene Subnetzwerke ohne Kommunikation zu anderen Subnetzwerken miteinander verbunden werden. Es sollte sichergestellt werden, dass kein Teilnehmer der Subnetzwerke kompromittiert ist, da sonst die Möglichkeit bestünde, Schaden am gesamten Netzwerk und nicht nur in dem geschlossenen Subnetzwerk anzurichten.

Nachdem die allgemeine Architektur nun soweit bekannt ist, bleibt die Frage zu klären, wie die gemäß TLS 1.3 verschlüsselte Kommunikation aufgebaut wird und wie die X.509-Zertifikate auf die */SC-Geräte kommen.

Zertifikatsmanagement

In der Gebäudeautomationsbranche wird das Management der Zertifikate als größte Herausforderung bei der Umstellung auf BACnet/SC angesehen. Das Zertifikatsmanagement ist zwar in der IT ein bekanntes Aufgabenfeld, für die Gebäudeautomation ist es allerdings Neuland. Auch wenn im Betrieb eine größere Synergie zwischen IT- und GA-Abteilung sicherlich wünschenswert wäre und in Zukunft auch immer wichtiger wird, bleibt es anfangs wohl dabei, dass sich der GA-Betrieb selber um das Zertifikatsmanagement kümmert. Das Management wird nicht zuletzt als Herausforderung für den Betrieb angesehen, weil die Betriebszertifikate aller */SC-Geräte regelmäßig erneuert werden, um eine sichere Datenübertragung garantieren und aufrechterhalten zu können.

Das Management der Zertifikate, die in allen BACnet/SC-fähigen Geräten enthalten sind und regelmäßig erneuert werden müssen, um eine sichere Datenübertragung zu gewährleisten und aufrechtzuerhalten, wird sich als eine Herausforderung für die

Gebäudeautomationsbranche darstellen.

Die TSL-Kommunikation basiert auf einer Private-Public-Key-Infrastruktur. Die Kommunikation besteht dabei aus einem Client und einem Server. Der Kommunikationsaufbau wird nachfolgend zusammengefasst und analog in der Abbildung 8 visualisiert. Bei einer gemäß TLS verschlüsselten Kommunikation besitzt jeder Teilnehmer ein individuelles Betriebszertifikat (Operational Certificate, OC) sowie den dazugehören privaten Schlüssel, den sogenannten private key.

Zusätzlich verfügt jeder Teilnehmer über das gleiche Stammzertifikat (Root Certificate, RC), welches von einer Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wird. Wenn der Client mit dem Server eine gemäß TLS 1.3 verschlüsselte Verbindung aufbauen möchte, sendet er eine Anfrage an den Server. Darauf antwortet der Server mit einem öffentlichen Schlüssel, welcher sich in seinem Betriebszertifikat befindet. Wenn das Betriebszertifikat von der richtigen CA ausgestellt wurde, verschlüsselt der Client einen neu erstellten Sitzungsschlüssel mit seinem Betriebszertifikat und sendet dieses zurück an den Server. Den Sitzungsschlüssel kann der Server mit seinem privaten Schlüssel entschlüsseln. Beide Teilnehmer verfügen dann über den gleichen, sicheren Sitzungsschlüssel. Da es sich bei BACnet/SC-Verbindungen um eine gegenseitige Geräteauthentifizierung handelt, überprüft der Hub nach dem gleichen Verfahren auch noch die Daten des Nodes. Erst danach kann die Kommunikation sicher verschlüsselt beginnen.

Für das */SC-Netzwerkmanagement ist allerdings entscheidend, wie die Zertifikate auf das entsprechende Device kommen. Grundsätzlich wird eine CA benötigt, welche die Zertifikate erstellt und signiert. Es ist durchaus möglich, eine manuelle Zertifikatsverwaltung mit öffentlichen Software-Lösungen wie dem X – Certficate and Key Management durchzuführen. Zertifikate können so manuell installiert, aktualisiert und gelöscht werden.

Dies ist jedoch zeitaufwändig, fehleranfällig und nicht wirklich praktikabel, insbesondere in großen Netzwerken. Unabhängig von BACnet/SC gibt es bereits eine Vielzahl von Public-Key-Infrastruktur-Unternehmen, die ein Zertifikatsmanagement anbieten. Falls verfügbar, besteht auch die Möglichkeit, die Public-Key-Infrastruktur der eigenen IT zu nutzen. In diesem Fall könnte ein RADIUS-Server der IT eingesetzt werden, um eine Authentifizierung der */SC-Teilnehmer gemäß IEEE 802.1x zu gewährleisten. Für mehr Informationen zu diesem Thema wird auf den Netzwerk Insider von Mai 2022 verwiesen [6]. Wird eine Entscheidung gefällt, dass extra für die Gebäudeautomation ausgelegte Systeme verwendet werden, können herstellerunabhängige Gebäudemanagementplattformen genutzt werden, oder die Managementplattform des verwendeten BACnet-Device-Anbieters.

In Abbildung 10 ist ein Workflow für das Erstellen von Betriebszertifikaten dargestellt. Der erste Schritt in einem neuen Projekt ist die Erstellung des Stammzertifikats. Da das Stammzertifikat und damit die gesamte Zertifikatshierarchie nur solange vertrauenswürdig bleiben bis dessen privater Schlüssel (der auf der Root-CA gespeichert ist) ausschließlich der ausstellenden Partei bekannt ist, kommt dem Schutz der Root-CA höchste Bedeutung zu. Das Stammzertifikat muss unabhängig vom Gerätehersteller für alle Geräte in der Umgebung identisch sein. Die Zertifikatsmanagementsoftware muss somit herstellerunabhängige Stammzertifikate erstellen können. In einem nächsten Schritt wird von der Zertifikatsmanagementsoftware (ZMS) für jeden Node ein Betriebszertifikat mit einer definierten Gültigkeitsdauer erstellt. In dem BACnet-Standard gibt es keine Vorgabe für die Gültigkeitsdauer. Es wird allerdings empfohlen, diese nicht länger als 18 Monate einzustellen. Eine solche Gültigkeitsdauer ermöglicht den Austausch der Zertifikate im Rahmen einer jährlichen GA-Wartung, ohne dass die Zertifikate vorher ablaufen. Wenn Zertifikate ablaufen, sollte die ZMS rechtzeitig eine Warnung ausgeben, damit ein entsprechender Prozess zur Erneuerung der Zertifikate eingeleitet werden kann. Das Erneuern der Zertifikate erfolgt ebenfalls durch die ZMS. Je nachdem, welche Software genutzt wird, ist der Aufwand für diesen Prozess unterschiedlich groß. Es wird empfohlen, ein System zu wählen, bei dem der Prozess möglichst automatisiert ist.

Wenn neue Teilnehmer in das Netz eingebunden werden sollen oder neue Zertifikate benötigt werden, können die Netzwerkteilnehmer ein Certificate Signing Request (CSR) an die ZMS senden, siehe Abbildung 11. Die CSR-Funktionalität ist mittlerweile auch im Addendum cc des BACnet-Standards festgeschrieben [7]. In diesem Addendum werden Verfahren zu der Zertifikatsverwaltung und der Zertifikatserneuerung ausführlich beschrieben. Der CSR-Prozess kann genutzt werden, um BACnet/SC-Geräte von Drittanbietern einzubinden. Neben der Zertifikatsverwaltung ist es noch wichtig, die richtigen Einstellungen auf den */SC-Geräten zu nutzen, um wirklich die volle Schutzfunktion zu aktivieren.

Die richtigen Einstellungen wählen

Beim Einrichten des BACnet/SC-Netzwerks ist es entscheidend, die korrekten Einstellungen auszuwählen. Grundsätzlich gilt, dass man die Gültigkeitsdauer der Zertifikate selber definiert. Werden Geräte mit vorinstallierten Zertifikaten erworben, sollte die Gültigkeitsdauer überprüft werden. Es ist nicht zielführend, wenn vorinstallierte Betriebszertifikate mit einer Gültigkeitsdauer von zehn Jahren genutzt werden. An dieser Stelle wird darauf hingewiesen, dass die Gültigkeitsdauer des Root-Zertifikats deutlich länger sein darf und an die Lebensdauer der Umgebung angepasst werden sollte. Um einen Überblick über mögliche Einstellungsmöglichkeiten zu erhalten, hat sich die ComConsult BACnet/SC-Geräte von unterschiedlichen Herstellern angeschaut. Auf die wesentlichen Erkenntnisse dieser Marktstudie zu Einstellungsmöglichkeiten, die aus Sicht der IT-Sicherheit kaum zu vertreten sind, wird im Folgenden eingegangen. Hier muss angemerkt werden, dass je nach Hersteller verschiedene Einstellungsmöglichkeiten angeboten werden und die nachfolgende Auflistung eine Zusammenstellung von gefundenen Optionen ist:

• Akzeptiere ungültige Zertifikate
• Akzeptiere abgelaufene Zertifikate
• Akzeptiere jedes Zertifikat
• Akzeptiere TLS-1.0- oder -1.1-Verbindungen

Durch solche Einstellungen können die Sicherheitsfeatures von BACnet/SC ad absurdum geführt werden. Durch das Akzeptieren von ungültigen oder allen Zertifikaten können

Fremdgeräte am */SC-Netzwerk teilnehmen und dieses kompromittieren. Auch das Erlauben von TLS 1.0 führt zu einem Sicherheitsrisiko, da somit der Netzwerkverkehr wieder wie bei einem BACnet/IP-Netzwerk im Klartext mitgelesen werden kann.

Die Möglichkeit, abgelaufene Zertifikate zu erlauben, sollte ebenfalls im Betrieb exkludiert werden, da diese Einstellung dem Betreiber eine einfache Option bietet, die Zertifikatserneuerung durchzuführen. Dieses Szenario wurde von der ComConsult getestet. Dazu wurde der Netzwerkverkehr in einem BACnet/SC mit Wireshark mitgeschnitten. Während des Versuchs wurde das Betriebszertifikat eines Nodes so eingestellt, dass die Gültigkeit des Zertifikats abläuft.
Abbildung 12 zeigt den Netzwerkverkehr eines BACnet/SC-Netzwerks. Initial war der Verbindungsaufbau erfolgreich und gemäß TLS 1.3 verschlüsselt. Während des Betriebs ist allerdings das Betriebszertifikat eines Nodes abgelaufen. Daraufhin folgt ein sofortiger Verbindungsabbruch. Wireshark gibt die nachfolgende Meldung aus: „Alert (Level: Fatal, Description: Certificate Expired)“. In der Praxis sollte dieses Szenario nicht auftreten, da entweder die ZMS oder die Gebäudemanagementplattform bereits frühzeitig auf die auslaufenden Zertifikate hingewiesen haben sollte. Für den Fall, dass es doch passiert, ist das Zertifikat schnellstmöglich zu erneuern, um den Verkehr wiederherzustellen.

Noch einfacher wäre es für die zuständige Stelle, in den Einstellungen die Option „akzeptiere abgelaufene Zertifikate“ zu aktivieren. Abbildung 13 zeigt den Wireshark-Mitschnitt, nachdem auch abgelaufene Zertifikate akzeptiert wurden. Im Anschluss wird somit wieder eine gemäß TLS v1.3 verschlüsselte Kommunikation mitgeschnitten, und das abgelaufene Zertifikat wird im Betrieb sehr wahrscheinlich vergessen und nie wieder erneuert. Von ungültigen Zertifikaten und unendlich gültigen Zertifikaten wird dringend abgeraten.

Der Umgang mit den BACnet/SC-Zertifikaten und den erlaubten Einstellungsmöglichkeiten sollte in einem Betriebskonzept festgelegt werden. Eine Möglichkeit für eine regulative Steuerung des Zertifikatsmanagements ist es, dieses im Kontext des GA-Wartungsintervalls durchzuführen. In dem VDMA-Einheitsblatt 24186-4:2024-01 werden für die Wartung notwendige Tätigkeiten und Leistungen für MSR-Einrichtungen und Gebäudeautomationssysteme definiert. In der Neuauflage von 2024 wird auch die periodische „Prüfung der Gültigkeitsdauer der Zertifikate der Kommunikation“ als Tätigkeit aufgeführt. Mit richtig eingerichteten Zertifikaten und einem abgestimmten Betriebskonzept ist die Kommunikation im GA-Netzwerk garantiert sicherer als zuvor.

BSI-IT-Grundschutz INF.14 Gebäudeautomation

Mit der Verwendung von BACnet/SC können, bei richtiger Verwendung, mehrere Anforderungen aus dem Baustein INF.14 Gebäudeautomation des BSI-IT-Grundschutzkompendiums erfüllt werden [8]. Die Verwendung des */SC-Protokolls hilft bei der Erfüllung der Basis-Anforderung INF.14.A3 Sichere Anbindung von TGA-Anlagen und GA-Systemen, indem die Informationsflüsse reglementiert werden können. Da alle BACnet-Netzwerkteilnehmer in dem Zertifikatsmanagementsystem hinterlegt sein müssen, wird eine gute Grundlage für die Basis-Anforderung INF.14.A.4 Dokumentation der GA geschaffen.

Hier wird gefordert, alle verfügbaren und genutzten Sicherheitseigenschaften der verwendeten Protokolle zu dokumentieren. Insbesondere wird die Standard-Anforderung INF.14.A12 Nutzung sicherer Übertragungsprotokolle für die GA erfüllt. Für die Konfiguration, Wartung und Steuerung von GA-relevanten Komponenten, die auf Ethernet und IP basieren, sollen sichere Protokolle verwendet werden. Zudem wird gefordert, dass die Kommunikation über Ethernet und IP zwischen GA-Systemen verschlüsselt erfolgen soll und die entsprechenden aktuellen Verschlüsselungsmechanismen genutzt werden. Dies wird zum aktuellen Stand der Technik mit einem korrekt implementierten BACnet/SC-Netzwerk gewährleistet. Des Weiteren kann die Standard-Anforderung INF.14.A20 Vermeidung von Broadcast-Kommunikation in GA-Netzen erfüllt werden, da bei einem vollständigen */SC-Netzwerk keine BACnet/IP-Broadcast-Kommunikation mehr benötigt wird.

Zusammenfassung

Um eine Kommunikation zwischen allen Systemen der Gebäudeautomatisierung und -steuerung zu ermöglichen, bedarf es herstellerunabhängiger Kommunikationsprotokolle. Da die Netzwerke der Gebäudetechnik für moderne Gebäude keine geschlossenen Systeme mehr sind, wird die IT-Sicherheit in der Gebäudeautomation stetig sicherer. Mehrere TGA-Kommunikationsprotokolle haben in den letzten Jahren neue Protokollversionen für eine sicherere Netzwerkkommunikation veröffentlicht.

BACnet/SC bietet die Möglichkeit, gemäß TLS 1.3 verschlüsselten Netzwerkverkehr zu nutzen, und eröffnet den Planern zusätzlich die Chance auf eine flexiblere Netzwerkplanung. Mittlerweile gibt es eine Vielzahl von Anbietern für BACnet/SC-fähige Controller. Wenn die ersten großen Projekte mit BACnet/SC umgesetzt wurden, wird es spannend zu sehen, wie die Praxiserfahrung mit BACnet/SC-Netzen im Betrieb ausfallen wird.

Literatur / Verweise

[1] Bundesgesetzblatt Teil 1 – Nr.280 – Gesetz zur Änderung des Gebäudeenergiegesetzes – §71
[2] ANSI/ASHRAE Addendum bj to ANSI/ASHRAE Standard 135-2016
[3] DIN EN ISO 16484-6 Systeme der Gebäudeautomation – Teil 6: Datenübertragungsprotokolle
[4] VDI 3814-1 Gebäudeautomation Grundlagen
[5] Netzwerk Insider 06/2022 – Anforderungen aus der Gebäudetechnik – TGA-Protokolle in strukturierten Netzen als Herausforderungen.
[6] Netzwerk Insider 05/2022 – RADIUS aus der Cloud – Marketing oder Mehrwert.
[7] ANSI/ASHRAE Addendum cc to ANSI/ASHRAE Standard 135-2020
[8] BSI-IT-Grundschutz Kompendium (Edition 2023)