Standard IT-Sicherheit R009 Serversysteme Roger Solioz Anthony Kalbermatten 2025-01-01 2030-12-31 Dieser Standard dient als Umsetzungsanforderung für Richtlinien IT-Sicherheit zu Serversystemen im BIT. Betroffen sind von diesem Standard grundsätzlich alle Serversysteme . Einzelne, explizite Ausschlüsse werden in den Anforderungen spezifiziert Dieser Standard unterliegt den Definitionen vom Zentraldokument für Standard IT-Sicherheit. Ziel & Zweck, Änderungswesen etc. sind da definiert und werden hier nicht ein zweites Mal aufgeführt. Information Security Management BIT 1 R0009.2.1 CMDB-Erfassung Organisation Die Konfigurationsmanagement-Datenbank stellt die integrierte Informationsgrundlage für das Service-Management BIT sicher und ist das IT-Repository fürs IT-Sicherheitsmanagement. Jedes Asset (Server, Gateway, Router, Switch usw.), dass sich im BIT-Netz befindet, muss in einer möglichst standardisierten Form dokumentiert sein. Ist die Betriebsverantwortung bei einem anderen Leistungserbringer, ist dies entsprechend zu dokumentieren und einzufordern. O2 Dokumentation 2025-09-02 Assets BIT-Netz 1 Dienste und Protokolle Technik Nicht benötigte Dienste und Protokolle deaktivieren Nach einer Standardinstallation von Systemen und Softwareprodukten sind typischerweise lokale oder aus dem Netz erreichbare Dienste und Protokolle aktiv, die für den Betreib und die Funktionalität des Systems nicht notwendig sind. Hierzu gehören auch Dienste und Protokolle, die aufgrund ihrer bekannten Sicherheits-Schwachstellen, die gegebenen falls für die Verletzung von Schutzzielen wie Vertraulichkeit, Integrität und Verfügbarkeit genutzt werden können. Solche Dienste (wie z.B. SSL anstatt TLS) und Protokolle müssen auf einem System vollständig deaktiviert sein (System-Härtung). Dabei ist es wichtig zu beachten, dass die Deaktivierung auch nach einem Neustart des Systems bestehen bleibt. Als Referenz für System-Härtung sollen die spezifischen Hersteller Sicherheits-Konfigurationen und weitere Referenzen wie CIS-Workbench angewendet werden. CIS-Benchmarks Security-by-Default-Prinzip Security-by-Design-Prinzip Zero-Trust-Prinzip T2.1 2025-09-02 Dienste Härtung Installation Protokolle 2 Einschränkungen Tools auf Serversystemen Technik Es dürfen keine Entwicklungstools, wie Compiler und Debugger, sowie Source Code Repositories auf einem produktiven Server vorhanden sein. Es dürfen keine Entwicklungstools, wie Compiler und Debugger, sowie Source Code Repositories auf einem produktiven Server vorhanden sein. Falls diese temporär benötigt werden (z.B. in einer krisenbedingten Restore-Situation) dürfen sie nur punktuell und so lange wie nötig auf den Systemen installiert werden. T2.1 2025-09-02 Entwicklungstools Repositories 3 Erreichbarkeit von Diensten Technik Dienste können nur eingeschränkt erreichbar sein und die Konfiguration darf nur autorisiert erfolgen. In der Regel sind aktivierte Dienste in der Grundkonfiguration über alle verfügbaren Schnittstellen eines Systems erreichbar und können von anderen Systemen in den angeschlossenen Netzen erreicht werden. Diese Erreichbarkeit ist funktional weder notwendig noch sinnvoll. Daher dürfen auf einem System die Dienste nur auf Schnittstellen aktiviert werden, auf denen deren Nutzung erforderlich ist. Auf den Schnittstellen, auf denen einen Dienst aktiv ist, muss dessen Erreichbarkeit auf legitime Kommunikationspartner eingeschränkt werden. Diese Einschränkung muss lokal, also ohne zusätzliche netzseitige Massnahmen, wie z. B. eine Firewall, erfolgen Dies kann zum Beispiel durch gegenseitige Authentisierung der Serversysteme mittels Zertifikats oder Key-Austausch erreicht werden. Least-Privilege-Prinzip T2.2 2025-09-02 Dienste Grundkonfiguration Schnittstellen 4 Lokale Firewalls anwenden Technik Vorgeschaltete Firewwalls bieten keinen umfassenden Schutz. Zonen Übergreifende Firewall oder Netz-Segmentierung sind keine Garantie für eine effiziente Einschränkung an nur berechtigte Zugriffe. Ein lokaler Paketfilter (Firewall) stellt sicher, dass Dienste, insbesondere Management-Dienste, nur an den erforderlichen Schnittstellen erreichbar sind. Ist auch Teil der Grund-Konfiguration durch System-Härtung (R0009.T.1). Least-Privilege-Prinzip Zero-Trust-Prinzip 2025-09-02 Dienste Firewall Netzwerkkommunikation 1 BIT-Externer Betrieb Informationen Die Verschlüsselung der Datenträger soll wo immer möglich verwendet werden. Es ist ein MUSS wo keine angepasste physische Zugriff Sicherheit gesichert werden kann. Falls sich das System nicht in einem BIT betriebenen RZ oder in einem abgesicherten Raum mit mindestens «Sehr hohem Schutzbedarf» befindet, müssen verwendete Datenträger vollständig verschlüsselt sein. Der Schutzbedarf oder auch die Schutzklassen (SK) sind in der (Richtlinie Informationssicherheit)[https://community.bit.admin.ch/team/eabit/Private/iktvorgaben/IKTVorgaben%20genehmigt/R0135_V5.2.pdf] BIT definiert. I4: Datenträger 2025-09-02 Datenträger Rechenzentrum 2 Vermeiden von Überlastsituationen Informationen Das System muss sich gegen Überlastsituationen schützen Ein System muss über Schutzmechanismen verfügen, die Überlastsituationen soweit wie möglich verhindern. Insbesondere ist eine partielle oder komplette Beeinträchtigung der Verfügbarkeit des Systems zu vermeiden. Beispiele für mögliche Schutzmassnahmen sind: Begrenzung auf Netzwerkzonen Begrenzung des pro Anwendung verfügbaren Arbeitsspeichers Begrenzung der maximalen Sessions einer Web-Anwendung Festlegen der maximalen Grösse eines Datensatzes Begrenzung von CPU-Ressourcen pro Prozess Priorisieren von Prozessen Begrenzung der Anzahl oder der Grösse von Transaktionen eines Benutzers oder von einer IP-Adresse in einem bestimmten Zeitraum. I3: Verfügbarkeit 2025-09-02 3 Reaktion auf Überlastsituationen Informationen Falls eine Überlastsituation nicht verhindert werden kann muss sich das System berechenbar verhalten. Ein System muss so konzipiert sein, dass es mit Überlastsituationen in kontrollierter Weise umgeht. Trotzdem kann es zu Situationen kommen, bei denen die Schutzmassnahmen gegen Überlastungen nicht mehr ausreichend sind. In einem solchen Fall muss sichergestellt sein, dass das System nicht in einen undefinierten und möglicherweise unsicheren Zustand gerät. Dies kann im Extremfall bedeuten, dass ein kontrolliertes Herunterfahren des Systems eher hinnehmbar ist als ein unkontrolliertes Versagen der Sicherheitsfunktionen und somit ein Verlust des Systemschutzes. I3: Verfügbarkeit 2025-09-02 4 Dynamische Inhalte Informationen Zunehmende (dynamische) Inhalte dürfen Systemfunktionen nicht beeinträchtigen. Zunehmende Logdaten oder Uploads dürfen die Funktionalität des Systems nicht beeinträchtigen. I3: Verfügbarkeit 2025-09-02 5 IP-Schnittstellen Informationen Das System darf keine IP-Pakete verarbeiten, deren Absenderadresse nicht über die Schnittstelle erreicht wird, an der das Paket eingegangen ist. Es muss darauf geachtet werden, dass Systeme nicht über unnötige Default-Routen verfügen, was z. B. der Fall ist, wenn Systeme nur intern verwendet werden. In einer solchen Konstellation handelt es sich i. d. R. um Pakete mit gefälschten Absenderadressen oder einen Fehler im Routing. Das eintreffende Paket muss als nicht vertrauenswürdig verworfen werden, Ein Umsetzungsbeispiel: Die Verwendung der Funktion «Reverse Path Filter» (RPF), die dafür sorgt, dass genau solche Pakete verworfen werden. I3: Verfügbarkeit 2025-09-02 6 Disaster Recovery Plan Informationen Ein Wiederanlaufplan / Disaster Revovery Plan muss beschrieben und sichergestellt sein. Wiederaufsetz- und Neustart Prozeduren im Fehlerfall, sowie Notfallpläne müssen dokumentiert sein. Die Vorbereitung und das Testen von Routine-Betriebsabläufen müssen nach festgelegten Standards erfolgen. Definierte Sicherheitsmassnahmen müssen nachweislich wirksam implementiert sein. Verfahren zur Sicherstellung des Geschäftsbetriebs müssen definiert und geregelt sein. I3: Verfügbarkeit 2025-09-02 7 Partitionierung Informationen Partitionen müssen, wenn möglich, getrennt werden. Daten-, Applikations- und Systempartitionen müssen, wenn möglich, getrennt werden. Eine Trennung der Daten liefert einen zusätzlichen Sicherheitslayer, sollte es zu Systemausfällen oder Malware-Befall kommen. Abhängig vom Schutzbedarf sollte auch entsprechend sichergestellt werden, dass die einzelnen Partitionen mit einer RAID-Funktionalität geschützt werden. I3.1 2025-09-02 1 Softwareinstallation Systeme Nicht benötigte (autorisierte[^2]) Software darf nicht installiert oder muss deinstalliert werden [^2]: (P035 – IKT-Anforderungs- und Vorgabemanagement Bund)[https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/prozesse-methoden/p035-ikt-anforderungs-und_vorgabenmanagement_bund.html] Bei der Installation eines Systems werden oftmals Software-Komponenten installiert oder auch einzelne Teile einer Software aktiviert, die für den Betrieb und die Funktion des Systems nicht notwendig sind. Hierzu zählen auch Teile einer Software, die als Anwendungsbeispiele (z. B. Default-Web-Seiten, Beispieldatenbanken, Testdaten) installiert werden, aber typischerweise nicht verwendet werden. Solche Komponenten dürfen entweder bei der Installation nicht mit installiert werden oder müssen im Anschluss an die Installation gelöscht werden. Des Weiteren ist es nicht erlaubt Software auf einem System zu installieren, die nicht für den Betrieb, die Wartung oder Funktion des Systems notwendig ist Least-Privilege-Prinzip T2.1 2025-09-02 2 Softwarefunktionen Systeme Nicht benötigte Funktionen der eingesetzten Software und Hardware müssen deaktiviert werden Bei der Installation von Software und Hardware werden oftmals Funktionen aktiviert, die nicht für den Betrieb und die Funktionalität des Systems notwendig sind. Funktionen der Software sind meistens ein fester Bestandteil, der nicht einzeln gelöscht oder deinstalliert werden kann. Solche Funktionen müssen über die Konfiguration oder Einstellungen dauerhaft deaktiviert werden Neben Funktionen der Software sind nach der Systeminstallation oftmals Hardware-Funktionen aktiviert, die nicht für den Einsatz des Systems benötigt werden. Solche Funktionen, wie beispielsweise nicht benötigte Schnittstellen, müssen dauerhaft deaktiviert werden, so dass sie auch nach einem Neustart deaktiviert bleiben. Least-Privilege-Prinzip T2.1 2025-09-02 3 Netzwerkprotokolle Systeme Die IPv4-/IPv6-Adressen aller Schnittstellen eines Servers müssen fest konfiguriert werden IP-Adressen, auf denen Dienste angeboten werden, dürfen nicht durch äussere Einflüsse verändert werden können, auch nicht bei einem erzwungenen Reboot. Eine automatische Zuweisung von IP-Adressen, z. B. mittels DHCPv4/v6 oder IPv6-Autokonfiguration, ist nur dann zulässig, wenn sie nach initialer Vergabe der Adresse(n) abgeschaltet oder anderweitig abgesichert wird. IPv6 Router Advertisements müssen ignoriert werden. Es wird empfohlen den Host-Anteil der IPv6-Adressen zufällig zu bilden, da auf Grund des sehr grossen Adressbereiches von IPv6 ein Auffinden von Systemen für einen Angreifer durch Scans sehr aufwändig ist. Nicht benutzte Protokolle (z.B. IPv6) können komplett abgeschaltet werden. Least-Privilege-Prinzip T2.1 2025-09-02 4 Netzwerkfunktionen Systeme Netzfunktionen im Betriebssystemkern, die für den Betrieb als Server nicht benötigt werden, müssen abgeschaltet werden (Kernel Parameter). Ein Server braucht nicht zu routen, daher muss die Routing-Funktion abgeschaltet sein. Ebenso muss das Antworten auf Broadcast-ICMP-Pakete abgeschaltet sein. Diese und weitere Netzfunktionen sind normalerweise bereits im Auslieferungszustand korrekt gesetzt. Least-Privilege-Prinzip T2.1 2025-09-02 5 Autorun-Funktionen Systeme Das automatische Starten von Anwendungen auf Wechseldatenträgern muss abgeschaltet werden. Wechseldatenträger – etwa CD-, DVD-, USB-Sticks oder USB-Laufwerke – dürfen darauf enthaltene Anwendungen nicht automatisch starten. Least-Privilege-Prinzip S5.3 2025-09-02 6 Verarbeitung von transferierten Daten Systeme Die Verarbeitung von ICMPv4-/ICMPv6-Paketen, die für den Betrieb nicht benötigt werden, muss deaktiviert werden. Es gibt verschiedene Typen von ICMPv4 und ICMPv6, die in den meisten Netzen nicht verwendet werden, aber ein potentielles Risiko darstellen. Diese Typen müssen deaktiviert oder gefiltert werden. Folgende ICMP-Typen sind erlaubt und dürfen genutzt werden: Echo Request [Type 8 (v4), Type 128 (v6)] Echo Reply [Type 0 (v4), Type 129 (v6) ] Destination Unreachable [Type 3 (v4), Type 1 (v6)] Time Exceeded [Type 11 (v4), Type 3 (v6)] Parameter Problem [Type 12 (v4), Type 4 (v6)] Packet Too Big [Type 2 (nur v6)] Neighbor Solicitation [Type 135 (nur v6)] Neighbor Advertisement [Type 136 (nur v6)] Es besteht die Möglichkeit, dass weitere Typen notwendig sind. Dies ist im Einzelfall zu prüfen. In *keinem Fall* dürfen beantwortet oder verarbeitet werden: Timestamp Reply [Type 14 (v4)] Netmask Reply [Type 18 (v4)] Information Reply [Type 16 (v4)] Redirect [Type 5 (v4), Type 137 (v6)] Router Solicitation [Type 133 (v6)] Router Advertisement [Type 134 (v6)] Least-Privilege-Prinzip T2.1 2025-09-02 Die ICMP-Typen Timestamp Reply, Netmask Reply, Information Reply, Redirect, Router Solicitation und Router Adversisement sind blockiert und werden nicht beantwortet. 7 IP-Headers Systeme IP-Pakete mit nicht benötigten Optionen oder Erweiterungs-Headern dürfen nicht bearbeitet werden. IP Optionen und Erweiterungs-Header (z. B. Source Routing) werden nur in seltenen Ausnahmefällen benötigt. Somit sind alle Pakete mit gesetzten IP-Optionen und Erweiterungs-Headern auf Standard-Servern zu filtern. Least-Privilege-Prinzip T2.1 2025-09-02 8 Default-Konten Systeme Vordefinierte Konten müssen gelöscht oder deaktiviert werden. Auf vielen Systemen existieren vordefinierte Konten (z. B. Gast, Admin) die teilweise ohne oder mit bekannten Passwörtern vorkonfiguriert sind. Diese Standardbenutzer müssen gelöscht oder deaktiviert werden. Sollten diese Massnahmen nicht umsetzbar sein, so sind solche Konten für einen Fernzugriff zu sperren. In jedem Fall müssen gesperrte und deaktivierte Konten mit einem möglichst komplexen Passwort (12 Zeichen und mehr, Nutzung von Gross-/ Kleinbuchstaben, Zahlen und Sonderzeichen) versehen werden, so dass auch im Falle eine Fehlkonfiguration die unberechtigte Nutzung eines solchen Kontos verhindert wird. Ausgenommen von der Anforderung, Konten zu löschen oder zu deaktivieren, sind Konten, die ausschliesslich der internen Nutzung auf dem entsprechenden System dienen und die für die Funktionalität einer oder mehrerer Anwendungen des Systems notwendig sind. Auch für ein solches Konto muss sichergestellt werden, dass ein Fernzugriff oder eine lokale Anmeldung nicht möglich ist und dass ein Benutzer des Systems ein solches Konto nicht missbräuchlich nutzen kann. S3 2025-09-02 1 Wartung und Pflege Anwendungen Software- und Hardware-Komponenten, für die es keine Wartung oder Pflege durch den Lieferanten, Hersteller oder Entwickler gibt, dürfen nicht verwendet werden Es dürfen auf einem System nur Betriebssystem-, Middleware- und Anwendungs-Software sowie Hardware- Komponenten eingesetzt werden, für die ein Support durch Lieferanten, Hersteller, Entwickler oder anderen Vertragspartner besteht. Komponenten die End-of-Life oder End-of-Support sind dürfen nicht eingesetzt werden. Ausgenommen hiervon sind Komponenten für die ein spezieller Support-Vertrag abgeschlossen wurde, durch den auch über den Lebendzyklus des Produkts hinaus die Behebung von Sicherheitsschwachstellen gewährleistet ist und von SI-SUR so genehmigt wurdeWeiterführende Informationen A2: Wartung und Pflege 2025-09-02 2 Schwachstellen Anwendungen Bekannt gewordene Schwachstellen in der Software oder Hardware des Systems müssen behoben oder abgesichert werden Vor der Installation einer Software- oder auch Hardware-Komponente muss überprüft werden, ob bereits Schwachstellen in der einzusetzenden Version gefunden und veröffentlicht wurden. Sollte die entsprechende Komponente von einer Schwachstelle betroffen sein, darf sie nicht installiert oder verwendet werden. Eine Ausnahme hiervon sind Komponenten, für die bereits eine Massnahme zum Beheben der Schwachstelle wie z. B. ein Patch, ein Update oder ein Workaround vom Hersteller zur Verfügung gestellt wurde. In diesem Fall muss die zusätzliche Massnahme auf dem System umgesetzt werden. Zudem ist dies ein fortlaufender Prozess während des kompletten Life-Cycles des Systems, um auftretende Schwachstellen zeitnah zu beheben. Zeitvorgaben für das beheben von entsprechenden Schwachstellen werden vom SI-SUR-CSIRT vorgegeben A2: Wartung und Pflege S2: Updates und Fehlerkorrekturen 2025-09-02 1 Abgesicherte Räume Zonen Falls sich das System nicht in einem BIT-betriebenen abgesicherten Raum (RZ) befindet, muss der Schutzbedarf «sehr hoher Schutzbedarf (SN3)» gewährleistet werden. Das BIOS muss vor nicht autorisierten Veränderungen geschützt werden. Server, die öffentlich oder in Räumlichkeiten von Kunden installiert sind, müssen besonders vor unautorisiertem Zugriff und Veränderungen geschützt werden: Es müssen die Einstellungen des BIOS gegen Auslesen und Manipulation geschützt werden. Bei Verwendung eines Passworts muss dieses exklusiv für den einzelnen Server sein und darf keine Rückschlüsse auf ein Unterscheidungsmerkmal des Servers ermöglichen. Das BIOS muss so konfiguriert sein, dass sich darüber ausschliesslich das vorgesehene Betriebssystem von der dafür vorgesehenen Partition starten lässt Z2: Zugriffe 2025-09-02