Organisation
Klassifikation NICHT KLASSIFIZIERT
IT-Grundschutz <Name des Schutzobjektes>
Schutzobjektname Schutzobjektname
Schutzobjektverantwortliche/ r
Name, Vorname, Abteilung/Rolle
Version / Datum V0.1 / XX.XX.XXX
Beschreibung Beschreibung des Informatikschutzobjektes
Änderungsverlauf
Version Datum Autor Beschreibung
Inhaltsverzeichnis
Deckblatt
Allgemeines
Unterschriften
Sicherheitsanforderungen
Abkürzungen
Schutzobjektname NICHT KLASSIFIZIERT
Umsetzung des IT-Grundschutzes
Allgemeines
Nachfolgend sind die minimalen IT- Sicherheitsanforderungen (IT-Grundschutz) in tabellarischer Form angefügt. Damit steht ein Hilfsmittel zur Rapportierung der Art der Umsetzung der Sicherheitsmassnahmen zur Verfügung.
Die IT-Sicherheitsanforderungen entsprechen denjenigen des Vorgabedokuments IT-Grundschutz in der Bundesverwaltung (Si001 Version 5.0). Diese können angepasst oder ergänzt werden.
Inkraftsetzung und kontinuierliche Überarbeitung
Dieses Hilfsmittel (Template) wird durch das BSV bei Bedarf angepasst. Die aktuellste Version findet sich jeweils auf der Homepage des Vollzug Sozialversicherungen (https:// sozialversicherungen.admin.ch).
Tailoring
Das Umsetzungsdokument (z.B. aufgeführte Massnahmen) kann ergänzt werden. Anforderungen können auch als «Nicht in diesem IT-Schutzobjekt gelöst» bezeichnet werden, wenn es sich um Anforderungen handelt, welche nicht in diesem Schutzobjekt gelöst sein müssen oder nicht vorkommen.
Gültigkeit
Dieses Dokument hat eine Gültigkeit von maximal 5 Jahren.
Management Summary
Schutzobjekt
Beschreibung des Schutzobjekts.
Schutzbedarfsanalyse
Zusammenfassung der Angaben (Einstufung) aus der Schutzbedarfsanalyse.
Zusammenfassung allfälliger Ausnahmegenehmigung und entsprechenden Restrisiken
Zusammenfassung und Beurteilung der nicht umgesetzten Massnahmen, die eine Ausnahmebewilligung gemäss Si001 Version 5.0 Kapitel 1.3 benötigen.
Kapitel 1.3 bebenötigen.
Abschliessende Bemerkungen
Abschliessende wichtige Bemerkungen und Fazits zum vorliegenden Schutzobjekt.
Rechtsgrundlagen
Beschreibung der dem Schutzobjekt zugrundeliegenden Rechtsgrundlagen.
Schutzobjektname NICHT KLASSIFIZIERT
Unterschriften
Mit ihren Unterschriften bestätigen die Unterzeichnenden, dass die Anforderungen des IT Grundschutz umgesetzt und eingehalten werden, und dass gemäss ihrer Einschätzung auch alle am Betrieb des Schutzobjektes beteiligten Leistungserbringer (LE) die sie betreffenden Anforderungen erfüllen.
Unterzeichnen müssen in jedem Fall die oder der Schutzobjektverantwortliche, ISBO und Geschäftsprozessverantwortliche. Bei einem Projekt muss auch die Auftraggeberin oder der Auftraggeber mit unterzeichnen.
Bei Unterschreitung des IT-Grundschutzes: Die Leiterin oder der Leiter der zuständigen Verwaltungseinheit entscheidet, ob bekannte Restrisiken in Kauf genommen werden können. Das Dokument kann, je nach amtsinterner Regelung, auch von einem anderen verantwortlichen Mitglied der Geschäftsleitung unterzeichnet werden.
Rolle Datum / Name / Unterschrift
Schutzobjektverantwortliche/r
ISBO
Aufftraggeber/in
Geschäftsprozessverantwortliche/r
Leiter/in Organisation
Weitere Unterschriften können hinzugefügt werden.
è Die Unterschriften können auch in elektronischer Form (in einem PDF) angebracht werden.
Schutzobjektname
Minimale Sicherheitsanforderungen
Anforderung
O Organisation
O1 [ Verantwortlichkeit ] Für das Schutzobjekt muss eine verantwortliche Person (innerhalb der verantwortlichen Organisation) als Schutzobjektverantwortliche/ r definiert sein. Diese Person ist für die Umsetzung dieser Vorgabe zuständig. Sie muss sich ihrer Verantwortung bewusst und fachtechnisch in der Lage sein, die Verantwortung auch wahrzunehmen.
Für eine Anwendung i Verantwortliche Für e analoger Art und Weis (innerhalb der für das Organisation) bestimm
O2.1 [ Dokumentation ] Für das Schutzobjekt muss eine aktuelle und mit den beteiligten LE abgeglichene Dokumentation vorliegen. Dabei muss die Dokumentation die gesamte Lebensdauer («Life Cycle») des Objekts abdecken und insbesondere auch a) die Lieferkette («Supply Chain»), b) die physischen Schutzmassnahmen c) die sicherheitsrelevanten Komponenten, Funktionen und Einstellungen, d) die Schlüsselverwaltung beim Einsatz kryptografischer Verfahren, e) die Modalitäten und Prozesse bei Änderung (im Rahmen des «Change Managements»), Reparatur, Entsorgung und Verlust, f) die vertraglichen Vereinbarungen, sowie g) die Audit-Prozesse und - Aktivitäten zur Kontrolle der Umsetzung und Einhaltung dieser Vorgabe mit einschliessen.
Eine umfassende und Dokumentation der hi Schutzobjekt ist erford Sicherheit gemacht un gezogen werden könn abschliessend, d.h. we Bemerkungen zu ergän wünschenswert. Präzi Aktivitäten müssen vo durchgeführt werden Verfügbarkeit der Sch beeinträchtigt wird (d im Betrieb möglichst k
O2.2 [ Dokumentation ] Wird das Schutzobjekt (IT-System oder Anwendung) nicht in einer Zone der Organisation betrieben (z.B. in einer Public Cloud), muss in der Dokumentation beschrieben sein, a) wie in dieser Umgebung dem Schutzbedarf des Objekts entsprochen werden kann, und b) mit welchen komplementären Sicherheitsmassnahmen sichergestellt wird, dass sich für andere Schutzobjekte der Organisation keine zusätzlichen Bedrohungen und Risiken ergeben.
Gemäss dem Grundsat Leistungserbringung) Schutzobjektes (z.B. in in dieser Umgebung d entsprochen werden k sichergestellt ist und w Sicherheitsmassnahme andere Schutzobjekte Bedrohungen und Risi umfassend dokumenti komplementären Sich organisatorische oder
O3 [ Geschäftskontinuität ] Für das Schutzobjekt muss die Geschäftskontinuität im Rahmen eines IT Service Continuity Management (ITSCM) bzw. eines Business Continuity Management (BCM) Prozesses gemäss ausgewiesenem Bedarf in der Schutzbedarfsanalyse (Schuban) sichergestellt und dokumentiert sein.
Die ITSCM- und BCM- Bedarf entsprechen un Dabei muss insbesond von Cyberangriffen Re
O4 [ Cybervorfälle ] Das Schutzobjekt muss in den Prozess zur Bewältigung von Cybervorfällen eingebunden sein. Bei grösseren Vorfällen werden die Arbeiten vom NCSC koordiniert.
Ein Beispiel eines solc intranet.ncsc.admin.ch partner/20210217- Bewaeltigung_Cybervo Bewaeltigung_Cybervo eines Cybervorfalls mu Prozess eigebunden se betroffenen LE und LB ist dieser Prozess für g beüben.
P Personal
P1.1 [ Sensibilisierung und Schulung ] Alle Benutzerinnen und Benutzer des Schutzobjekts müssen im Bereich der Informatiksicherheit stufen- bzw. funktionsgerecht sensibilisiert und geschult sein.
Die Art und Weise der grundsätzlich nicht fe verantwortlichen Orga Schutzobjektverantwo Rahmen des Schutzobj User, Benutzer, ... ) be Schulungen durchgefü
P1.2 [ Sensibilisierung und Schulung ] Alle Benutzerinnen und Benutzer des Schutzobjekts müssen die für das Schutzobjekt relevanten Einsatzrichtlinien kennen und sind zu deren Einhaltung verpflichtet.
Eine Übersicht über al https://intranet.dti.bk vorgaben/einsatzricht gilt diese Anforderung Systemen und/oder pr Mobilen Arbeiten. Die Schutzobjektverantwo und Benutzer die relev
P2 [ Meldepflicht ] Alle Benutzerinnen und Benutzer des Schutzobjekts müssen sicherheitskritische Ereignisse, wie z.B. anormales und verdächtiges Systemverhalten oder physischer Verlust, möglichst zeitnah der dafür zuständigen Stelle melden (z.B. Servicedesk des LE).
Die Festlegung der sic nicht abschliessend er Verlust), muss dem Sc entsrechen und liegt im verantwortlichen VE b Informatiksicherheitsb
T Technik
T1 [ Betrieb ] Das Schutzobjekt muss dem Stand der Technik entsprechend und unter Berücksichtigung von branchenüblichen Sicherheitsvorgaben und - empfehlungen («Best Practices») betrieben werden.
Der Stand der Technik definiert werden und Informatiksicherheitsb ermittelt werden. Für Technologieabschätzu beigezogen bzw. https de/home/dokumentat empfehlung_technolog werden.
T2.1 [ Konfiguration und Einstellung ] Das Schutzobjekt muss vor der ersten Inbetriebnahme so konfiguriert und eingestellt sein, dass a) es vor unberechtigtem Zugriff geschützt ist, b) es soweit technisch möglich gehärtet ist und in einer zur Aufgabenerfüllung erforderlichen und vom Benutzer nicht veränderbaren Minimalkonfiguration betrieben wird (d.h. nicht genutzte Schnittstellen, Module und Funktionen müssen deaktiviert sein), und c) wichtige sicherheitsrelevante Aktivitäten und Ereignisse (mit Zeitangaben) aufgezeichnet und zeitnah ausgewertet werden.
Letztlich kann diese A verstanden bzw. davo Wichtigkeit wird sie h
T2.2 [ Konfiguration und Einstellung ] Sicherheitskonfigurationen und -einstellungen dürfen nur autorisiert aktiviert, geändert, deaktiviert und deinstalliert werden.
Eine Härtung im Sinne dann Sinn, wenn Siche einstellungen nur auto deaktiviert und deinst
T3 [ Produktive Umgebung ] Die produktive Umgebung des Schutzobjekts muss von allenfalls vorhandenen nicht produktiven Umgebungen (z.B. für Entwicklung und/ oder Test) getrennt sein. Erfolgt die Trennung logisch, müssen die entsprechenden Sicherheitsvorkehrungen und -massnahmen begründet und dokumentiert sein.
Grundsätzlich ist eine Falls das nicht möglic ist, kann eine logische müssen dann die zur l Sicherheitsvorkehrung dokumentiert sein.
T4 [ Schwachstellen und Verwundbarkeiten ] Das Schutzobjekt muss im Hinblick auf Schwachstellen und Verwundbarkeiten vor seiner Inbetriebnahme und in Abhängigkeit seines Schutzbedarfs und Exposition gegenüber dem Internet auch während des laufenden Betriebs regelmässig und vorzugsweise automatisiert überprüft werden (z.B. mit einem Security Scanner). Für kritische Schwachstellen und Verwundbarkeiten ist das NCSC beizuziehen.
Idealerweise ist das Sc vollständiges und auto Verwundbarkeitsmana
T5.1 [ Authentifikation und Autorisation ] Jeder Zugriff auf ein Schutzobjekt muss seinem Schutzbedarf entsprechend authentifiziert und gemäss dem «Least Privilege»- bzw. «Need-to- Know»-Prinzip autorisiert sein.
Grundsätzlich muss di und den erwähnten Pr Authentifikation lokal Netzwerkverbindunge Authentifikation in ihr lokale Authentifikatio Authentifikationen au
T5.2 [ Authentifikation und Autorisation ] Alle Zugriffsrechte auf das Schutzobjekt müssen im Rahmen eines definierten und dokumentierten Prozesses verwaltet und stets aktuell gehalten werden. Insbesondere müssen die Rechte mindestens jährlich in Bezug auf Notwendigkeit und Richtigkeit überprüft und nicht mehr benötigte Rechte (bzw. Konti) entfernt werden.
Im Rahmen des hier a Gewaltentrennung zw Zugriffsrechten wenn und mit dokumentiert veränderte Verhältniss wenn die Anstellung, Nutzungsvereinbarung beendet wird) sollte e definiert sein.
T5.3 [ Authentifikation und Autorisation ] Für das Schutzobjekt dürfen nur Authentifikations- und Identitätsnachweismittel eingesetzt werden, die im Rahmen eines definierten und dokumentierten Prozesses verwaltet werden, der den gesamten Life Cycle des Mittels (inkl. Zugriffsmöglichkeiten für Notfälle, Sperrung, Zurücksetzung, Revozierung und Entsorgung) mit abdeckt.
Diese Anforderung trä Rechnung, dass beim Identitätsnachweismit Verwaltungsprozesse m das eingesetzte Mittel
T6.1 [ Benutzerauthentifikation ] Die Benutzerauthentifikation gegenüber einem APS oder einem Server-System muss auf der Basis eines Authentifikations- und Identitätsnachweismittels mindestens der Sicherheitsstufe «mittel» gemäss Anhang B bzw. einer 2-Faktoren-Authentifikation erfolgen.
Die Notwendigkeit ein ergibt sich aus dem BR Angestellten des Bund der SG-PKI eingesetzt. sich die Benutzerauthe Betriebssystemebene.
T6.2 [ Benutzerauthentifikation ] Die Benutzerauthentifikation gegenüber einem MDM- System muss auf der Basis der vom jeweiligen Betriebssystem unterstützten Verfahren erfolgen, wie z.B. PIN oder biometrische Authentifikation (z.B. Touch ID oder Face ID für iOS- Geräte). Ein PIN muss mindestens 6 Zeichen enthalten und darf nicht trivial sein.
Die konzeptionellen U Passwort und einer PI Technologiebetrachtu Juni 2012 ausgeführt. Benutzer-Nummer, ein Ziffernfolge wie 1111
T6.3 [ Benutzerauthentifikation ] Die Benutzerauthentifikation gegenüber einer Netzwerkkomponente muss auf der Basis eines Authentifikations- und Identitätsnachweismittels mindestens der Sicherheitsstufe «hoch» gemäss Anhang B erfolgen.
Weil das Missbrauchsp Netzwerkkomponente Notwendigkeit eines A Identitätsnachweismit «hoch».
T7.1* [ Passwörter ] Das Passwort a) muss persönlich sein b) muss einmalig sein c) darf nicht weitergegeben werden d) darf nicht aufgeschrieben bzw. muss geschützt abgelegt oder mit einem Passwort- Verschlüsselungsprogramm verwaltet werden e) muss mindestens 10 Zeichen lang sein (bei Benutzern mit erhöhten Rechten 18 Zeichen), wobei die Zeichen aus mindestens drei der vier Kategorien Gross- und Kleinbuchstaben, Zahlen und Sonderzeichen stammen müssen f) darf nicht trivial sein und keinen Bezug zum Benutzer haben, d.h. Attribute wie User-ID, Name, Vorname oder Geburtsdatum dürfen nicht enthalten sein.
Diese Anforderung ist eine Abweichung ist g möglich, wenn sie im zum IKT-Grundschutz und dokumentiert ist. Funktionsaccounts dü vergeben werden (vgl Zugriffe auf Schutzobj Schutzbedarf (Grunds Präzisierung zu b) Insb Passwort für die Auth Systemen und Anwend zu d) Auf APS ist die P (Schale 1) einzusetzen
T7.2* [ Passwörter ] Ein administrativ gesetztes Initialpasswort muss bei seinem Erstgebrauch geändert werden.
Diese Anforderung ist eine Abweichung ist g möglich, wenn sie im zum IKT-Grundschutz und dokumentiert ist.
T7.3* [ Passwörter ] Wenn das Passwort geändert wird, muss sichergestellt sein, dass das neue Passwort keinem der 10 zuletzt verwendeten Passwörtern entspricht.
Diese Anforderung ist eine Abweichung ist g möglich, wenn sie im zum IKT-Grundschutz und dokumentiert ist.
T7.4* [ Passwörter ] Nach maximal
5 Fehleingaben muss das
Passwort gesperrt und darf nur im Rahmen eines definierten Prozesses wieder freigegeben werden.
Diese Anforderung ist eine Abweichung ist g möglich, wenn sie im zum IKT-Grundschutz und dokumentiert ist.
T7.5 [ Passwörter ] Bei Verdacht auf Kenntnisnahme durch Unberechtigte oder Missbrauch muss das Passwort umgehend geändert werden.
Im Zweifelsfall können Informatiksicherheitsb weiterhelfen.
T7.6* [ Passwörter ] Server-seitig muss sichergestellt sein, dass das Passwort nicht im Klartext ausgelesen oder im Rahmen eines anderen Angriffs leicht kompromittiert werden kann.
Passwörter dürfen nic einer Einweg-Funktion abgespeichert werden noch mit einem "Salt"- parametrisiert.
T8.1 [ Administrative Zugriffe und Fernzugriffe ] Administrative Zugriffe auf das Schutzobjekt müssen auf eine dokumentierte und kontrollierte Art und Weise erfolgen. Insbesondere müssen solche Zugriffe kryptografisch abgesichert sein und nachvollziehbar aufgezeichnet und ausgewertet werden.
Die kryptografische A Auswertung erscheint besonders wichtig, da verhindert oder erkan die kryptografische Ab Authentifikation als au Integritätsschutz der D
T8.2 [ Administrative Zugriffe und Fernzugriffe ] Die für administrative Zugriffe verwendeten IT-Systeme müssen für diese Aufgabe ausgelegt sein und vorzugsweise in einer Management Zone betrieben werden. Die Nutzung der entsprechenden (privilegierten) Konti muss einer Person zugeordnet werden können. Zudem dürfen die Konti nur über minimal erforderliche und möglichst kurzlebige Zugriffsrechte verfügen, müssen einer Schicht in einem Schichtenmodell zugeordnet sein und dürfen nur zur Administration in dieser Schicht verwendet werden (zwecks Verhinderung einer «Privilege Escalation»). Insbesondere dürfen die Konti nicht für nicht- administrative Internet- Zugriffe genutzt werden.
Diese Anforderungen «Mitigation Credentia Zugriffsrechte lassen s die im Rahmen einer P (PAM) Lösung verwalt für die Dauer einer be gültig. Ein Schichtenm z.B. im Rahmen der im definiert.
T8.3 [ Administrative Zugriffe und Fernzugriffe ] Ein Fernzugriff durch einen externen Anbieter ist zulässig, wenn a) der Inhaber des Objekts einverstanden ist und bezüglich möglicher Amtsgeheimnisverletzungen gemäss den amts- bzw. departementsspezifischen Prozessen eingewilligt hat (vgl. [Si001-Hi03, Si001- Hi04), b) der Zugriff über ein dediziertes Konto erfolgt und die entsprechende Benutzerauthentifikation auf einem Authentifikations- und Identitätsnachweismittel mindestens der Stufe «mittel» gemäss Anhang B basiert, c) die Nutzung dieses Kontos zeitlich begrenzt ist und überwacht wird, d) wenn technisch möglich der Zugriff über einen Jumphost erfolgt, e) die netzwerktechnische Verbindung für den Zugriff kryptografisch abgesichert ist (z.B. mit Hilfe von SSH) und f) die Auditierbarkeit der externalisierten Prozesse jederzeit sichergestellt ist.
Diese Anforderung ist inhaltlich den Anforde Sicherheitsvorgaben.
I Informationen (Daten)
I1* [ Zulässigkeit von IT- Systemen ] Geschäftsrelevante Informationen dürfen nur auf IT-Systemen gespeichert und verarbeitet werden, deren Inhaber entweder der Organisation angehört oder für die, für welche Einhaltung der sicherheitstechnischen Anforderungen aus dieser Vorgabe vertraglich geregelt ist (z.B. im Rahmen einer Cloud-Lösung).
Mit dieser Anforderun geschäftsrelevante Da und verarbeitet werde oder organisatorisch u Weise kontrollieren ka
I2.1 [ Vertraulichkeit und Integrität ] Die Vertraulichkeit und Integrität von geschäftsrelevanten Informationen müssen jederzeit ihrem Schutzbedarf entsprechend und unter Berücksichtigung der physischen Gegebenheiten mit Hilfe kryptografischer Verfahren geschützt sein (gilt auch für Testdaten und zu Testzwecken eingesetzte produktive Daten). Werden Informationen verschlüsselt, dann müssen die dazu verwendeten Schlüssel so verwaltet werden, dass eine Wiederherstellung und damit eine Entschlüsselung der Informationen jederzeit möglich ist. In der Regel bedingt das eine aufwändige Schlüsselverwaltung (mit einem «Key Recovery»- Mechanismus) sowie ein periodisches Austesten der Wiederherstellbarkeit der Informationen.
Insbesondere müssen Schutzbedarf, die auf speziell geschützten S einer Festplattenversc
I2.2 [ Vertraulichkeit und Integrität ] Die eingesetzten IT-Systeme müssen geeignet sein, den Schutz der Vertraulichkeit und Integrität der Informationen zu gewähren.
So ist z.B. auf MDM-Sy Verarbeitung von als V Informationen nicht b verschlüsselter Sprach
I3.1 [ Verfügbarkeit ] Die Verfügbarkeit von geschäftsrelevanten Informationen muss jederzeit dem Schutzbedarf entsprechend sichergestellt sein.
Grundsätzlich wird di geschäftsrelevanten In postuliert.
I3.2 [ Verfügbarkeit ] Die für Informationen verantwortliche Organisation muss über eine Backup- Strategie verfügen und diese auch umsetzen. Diese Strategie muss ein Mehrgenerationen-Prinzip und eine offline Speicherung wichtiger Datenbestände vorsehen, so dass Daten auch im Falle von datenverschlüsselnder Malware («Ransomware») wiederhergestellt werden können.
Ist die verantwortliche Strategie auch vom LE Strategie dann vom LB spezifische Schutzobje Beübung der Strategie Bedeutung zu, wobei d nach einem Verlust re bestätigt werden muss
I4 [ Datenträger ] Die Datenträger, auf denen geschäftsrelevante Informationen gespeichert sind, müssen jederzeit dem Schutzbedarf der Informationen entsprechend geschützt sein. Namentlich für die Reparatur und Entsorgung von Datenträgern müssen geeignete Prozesse definiert und umgesetzt sein.
Bei der Entsorgung vo darauf zu achten, dass oder die gespeicherten dazu auch die «Empfe elektronischen Datent (https://intranet.ncsc. dokumente/empfehlun Vernichtung_HW_V1-0 Vernichtung_HW_V1-0
S IT-Systeme
S1 [ Zonenzugehörigkeit ] Das IT-System muss einer Zone zugehören und gemäss der entsprechenden Zonenpolicy betrieben werden.
Ein IT-System, das kei werden kann, gehört z keine Zonenpolicy. Zu geben, die weder eine angehören. Diese Kom sein.
S2 [ Updates und Fehlerkorrekturen ] Für das IT-System muss entweder sichergestellt sein, dass der oder die Hersteller während der ganzen Lebensdauer Updates und Fehlerkorrekturen (Patches) bereitstellen, die zeitnah geprüft und eingespielt werden , oder das IT-System in einer dedizierten und möglichst stark abgeschotteten Zone betrieben wird (z.B. Technik Zone) und mit Hilfe welchen komplementären Sicherheitsmassnahmen sichergestellt wird, dass sich für andere Schutzobjekte der Organisation keine zusätzlichen Bedrohungen und Risiken ergeben. Falls ein Ersatz geplant ist, darf das IT-System während maximal zwei Jahren weiter betrieben werden, sofern der Weiterbetrieb in einem ISDS- Konzept beschrieben ist.
Für APS, die nicht per verbunden sind, muss mindestens einmal pro aktualisiert werden. B Zusammenspiel der ve (auf unterschiedlichen werden (z.B. Anwendu Betriebsystem, Virtual Die unteren Schichten werden können. Dies e und ggf. Anpassung de von Dritten muss ein W Anpassungen gemacht Patch Managements e
S3.1 [ Dienstkonti ] Von Systemdiensten benutzte Konti (Dienstkonti) müssen spezifisch und nur mit den für die Diensterbringung minimal erforderlichen Rechten ausgerüstet sein.
Ein Dienstkonto ist sp Dienst verwendet wird
S3.2* [ Dienstkonti ] Die Dienstkonti müssen automatisiert verwalten werden und eine kryptografisch starke Authentifikation erfordern. Im Idealfall basiert diese Authentifikation auf dem Einsatz asymmetrischer Kryptografie, wobei die dazu verwendeten privaten Schlüssel sicher hinterlegt werden müssen. Basiert die Authentifikation auf Passwörtern, müssen diese deutlich stärker (und länger) sein als bei der Benutzerauthentifikation.
Die Anforderungen an Dienstkonti sind höhe bietet sich hier der Ein an. Beim Einsatz von P stärker (und länger) se Benutzerauthentifikat Mindestlänge wird hie von der relativen Wich
S4.1 [ Integritäts- und Malwareschutz ] Die Integrität der auf dem IT- System eingesetzten Softwarekomponenten muss sichergestellt sein (z.B. mit Hilfe von digitalen Signaturen). Insbesondere muss jedes Server-System mit erhöhtem Schutzbedarf regelmässig einer Integritätsprüfung unterzogen werden.
Diese Anforderung erg Dezember 2009. Verg Technologiebetrachtu Systemen» (https://in ncscintra/de/dokumen Technolgiebetrachtun Integritaetspruefung_v d.pdf.download.pdf/T Integritaetspruefung_v
S4.2 [ Integritäts- und Malwareschutz ] Wird ein Integritätsverlust festgestellt, muss das IT-System unmittelbar vom Netzwerk getrennt, gesichert und untersucht werden. Im Falle einer bestätigten Kompromittierung muss das IT-System vollständig gelöscht und neu aufgesetzt werden.
Ein Integritätsverlust d des IT-Systems hin. In IT-System unmittelbar und untersucht wird, u bestätigten Kompromi neu aufgesetzt wird.
S4.3 [ Integritäts- und Malwareschutz ] Das IT- System muss in ein auf [SB003] aufbauendes Malwareschutzkonzept eigebunden sein, das insbesondere auch regelt, wie bei einem Malwarebefall vorzugehen ist und welche Stellen wie informiert werden müssen.
Malwareschutz ist ein System konzeptionell angegangen werden m verwendet werden.
S5.1 [ Bundesclients ] Auf dem Bundesclient müssen interne nicht-flüchtige Datenspeicher (z.B. Festplatten) transparent verschlüsselt sein. Für ein MDM-System muss zudem eine Möglichkeit vorgesehen sein, das System entfernt auf seine Grundeinstellungen zurückzusetzen und sämtliche lokal gespeicherten Informationen zu löschen.
Eine Verschlüsselung Benutzer ohne speziel Die Verschlüsselung v flüchtig) gespeicherten zwingend. Insofern ist (z.B. BitLocker) zu akt Systems muss zudem s Bedarfsfall das System zurückgesetzt und säm Informationen gelösch
S5.2 [ Bundesclients ] Bei fehlender Benutzeraktivität muss der Zugriff auf den Bundesclient automatisch gesperrt werden (auf APS nach maximal 15 Minuten und auf MDM-Systemen nach maximal 3 Minuten). Eine manuelle Aktivierung der Systemzugriffssperre muss ebenfalls möglich sein. Ist eine Sperrung aus technischen Gründen nicht möglich, muss der Zugang zu unbeaufsichtigten aber freigeschalten Bundesclients physisch geschützt sein (z.B. durch Abschliessen des Raumes).
Es muss sichergestellt durchgeführte Benutze missbraucht werden k entweder bei fehlende automatisch gesperrt w physisch geschützt sei auch beide Möglichke
S5.3 [ Bundesclients ] Auf dem Bundesclient darf keine Autorun-Funktion beim Anschluss externer Datenträger (z.B. USB-Sticks) aktiviert sein.
Damit soll verhindert nicht kontrollierbaren ein IT-System eingebr
S5.4 [ Bundesclients ] Die Benutzerinnen und Benutzer des APS dürfen über keine lokalen Administratorenrechte verfügen.
Diese Anforderung sol kompromittierte Benu kann.
S5.5 [ Bundesclients ] Ein administrativer Zugriff zu Supportzwecken auf das APS ist nur mit einer vorgängigen, expliziten Einwilligung der Benutzenden erlaubt.
Diese Anforderung sol adminsitrativer Zugriff Benutzenden erfolgt.
S6.1 [ Peripheriegeräte ] Das Peripheriegerät darf eingesetzt werden, wenn a) es durch eine Beschaffungstelle des Bundes beschafft worden ist und b) seine Integrierbarkeit und grundsätzliche Sicherheit vom LE nachweislich bestätigt worden ist.
Mit dieser Anforderun innerhalb der Organis Peripheriegeräte einge Peripheriegeräte sind thematisiert). Präzisie bedeutet z.B. auch, da ScanToMail an die Mi Organisation angebun
S6.2 [ Peripheriegeräte ] Das Peripheriegerät muss vom LE minimal konfiguriert und vor nicht berechtigten Änderungen (der Konfiguration) geschützt sein.
Die minimale Konfigu Peripheriegeräte.
S6.3 [ Peripheriegeräte ] Wird das Gerät zum Drucken klassifizierter Dokumente benutzt, müssen a) das Gerät lokal betrieben werden oder eine Möglichkeit zur Personenauthentifizierung am Gerät bestehen, und b) interne nicht-flüchtige Datenspeicher (z.B. Festplatten) gemäss einschlägigen Empfehlungen überschrieben werden können, wobei die Überschreibung entweder manuell vom Benutzer oder automatisiert ausgelöst werden kann.
Präzsisierung zu b) "E DoD 5220.22-M oder
S6.4 [ Peripheriegeräte ] Für die Nutzung von privaten Peripheriegeräten beim Mobilen Arbeiten muss die Einsatzrichtlinie [E026] eingehalten werden.
Diese Anforderung reg Peripherieberäten insb
A Anwendungen
A1.1 [ Beschaffung / Entwicklung ] Die Anwendung muss im Rahmen eines methodischen Vorgehens (beispielsweise nach HERMES ) und unter frühzeitiger Berücksichtigung von einschlägigen Sicherheitsvorgaben und - empfehlungen («Best Practices») beschafft bzw. entwickelt werden.
Weitergehende Inform unter https://www.he von Web-Anwendunge Empfehlungen der Op (OWASP) mit zu berüc sichere Verwaltung vo
A1.2 [ Beschaffung / Entwicklung ] Bei der Entwicklung der Anwendungssoftware muss insbesondere sichergestellt sein, dass a) der Quellcode sicher aufbewahrt wird, b) der Zugriff auf die entsprechenden Repositories klar geregelt und nachvollziehbar kontrolliert wird, c) die Build Prozesse überwacht werden und Änderungen an der Build Pipeline nur kontrolliert erfolgen können, d) die Software regelmässig getestet wird und e) die Integrität der Software jederzeit sichergestellt ist (z.B. mit Hilfe von digitalen Signaturen).
Diese Anforderung be Anwendungssoftware Practices». Für die agi des SAFe-Modells solle Definition of Done auf werden. Die Sicherhei Increment aktualisiert Akzeptanzkriterien au
A2 [ Wartung und Pflege ] Für die Anwendung und ihre Komponenten (z.B. Software- Bibliotheken) müssen während der ganzen Lebensdauer eine professionelle Wartung und Pflege sichergestellt sein. Darunter fallen insbesondere auch die Einspielung von regelmässigen und betrieblich oder sicherheitstechnisch notwendigen Updates und Fehlerkorrekturen (Patches).
Wartung und Pflege si (und alle verwendeten Themen. Die Einhaltu und Prozesse ist wicht Software-Bibliotheken Schwachstellen kann z Dependency-Check» ü www-project-depende
Z Zonen
Z1.1 [ Konformität ] Die Zone muss konform zum internen Zonenmodell sein und über einen Inhaber, einen eindeutigen Namen, eine Zonenpolicy und einen Betreiber verfügen (gilt nicht für das Internet bzw. die Zone Internet). Umfasst die Zone IT-Systeme und Anwendungen, die ausserhalb der Organisation (z.B. in einer Public Cloud) betrieben werden, dann muss die netzwerkmässige Erschliessung in der Zonenpolicy beschrieben sein.
Die Eindeutigkeit kann der Inhaber als Suffix SZ-FUB für eine von d Falls ein Inhaber eine müssen die entspreche Der Betreiber ist ein L Inhabers netzwerktech Zone ein LE ist, könne auch identisch sein Fa die Policy ändert, mus Frist für die Umsetzun
Z1.2 [ Konformität ] Der Betreiber muss sicherstellen, dass nur gemäss Zonenpolicy zulässige Kommunikation von und zu der Zone stattfinden kann, und dass mit Hilfe geeigneter komplementärer Sicherheitsmassnahmen (z.B. Isolierung und Segmentierung) von dieser Kommunikation keine zusätzlichen Bedrohungen und Risiken für andere IT- Systeme und Anwendungen in- und ausserhalb der Zone ausgeht.
Die Zonenpolicy stellt aus der Zone dar, und dass die Policy sinnvo mit dem Zoneninhabe auch für kurzfristige A diese betrieblich erfor
Z1.3 [ Konformität ] Die Zone muss in das Verzeichnis integriert sein, das vom zuständigen ISBD geführt und dem NCSC zur Verfügung gestellt wird. Ein ISBD ist zuständig, wenn eine Verwaltungseinheit des Departementes entweder als Inhaber oder Betreiber der Zone auftritt.
Diese Anforderung ist über die in der Organi werden kann. Aufgrun kann eine Zone auch d Sicht des Inhabers und Betreibers).
Z2.1 [ Zugriffe ] Ein eingeschränkter Zugriff in die Zone ist nur für Personen und automatisierte Prozesse zulässig, die mit einem Authentifikations- und Identitätsnachweismittel mindestens der Stufe «mittel» authentifiziert worden sind (für Messgeräte reicht die Stufe «tief»). Die folgenden Ausnahmen sind erlaubt: a) Anonyme und personalisierte Zugriffe im Rahmen von E- Government-Anwendungen, die einer breiten Bevölkerungsschicht in einer SZ zugänglich gemacht werden. Die entsprechenden Webseiten müssen mit TLS (HTTPS) abgesichert und Formulare vor automatisierten Angriffen geschützt werden (z.B. mit Hilfe von CAPTCHAs). b) Zeitlich befristete Zugriffe zum Hochladen von Daten auf ein Server-System. c) Automatisierte und im Einverständnis mit dem Zoneninhaber durchgeführte Zugriffe im Rahmen von Sicherheitsüberprüfungen von Web-Auftritten (Scans). Erfolgt der Zugriff in eine Zone mit erhöhtem Schutzbedarf (z.B. SZ+) muss das Authentifikations- und Identitätsnachweismittel
Ein Zugriff ist eingesc technischer Vorkehrun oder ein paar wenige Anwendungen und au erforderlichen Protoko heisst der Zugriff unei Abgrenzung der entsp gegenüber den andere muss in diesem Fall en zusammen mit allen k Sicherheitsmassnahme der Sicherheitsdokum dokumentiert sein. Se Zoneninhaber mit dem einverstanden sein.
mindestens der Stufe «hoch» gemäss Anhang B sein und die oben aufgeführten Ausnahmen a) und b) sind dann nicht zulässig.
Z2.2 [ Zugriffe ] Ein uneingeschränkter Zugriff in die Zone ist nur für Personen zulässig, die sich über einen Bundesclient verbinden, mit einem Authentifikations- und Identitätsnachweismittel mindestens der Stufe «hoch» gemäss Anhang B authentifiziert sind und die Verbindung kryptografisch abgesichert ist (z.B. mit Hilfe von SSH).
Uneingeschränkte Zon vermeiden bzw. sollen Administration) zugel erhöhte Anforderunge die Kommunikationsss
Z3 [ Zonenübergreifende Kommunikation ] Jede zonenübergreifende Kommunikation muss über eine PEZ erfolgen. Diese hat sicherzustellen, dass die Kommunikation konform zu den betroffenen Zonenpolicies ist. Dazu müssen die erlaubten Kommunikationsmuster und - be-ziehungen in den Policies so präzis wie möglich (idealerweise auf der Anwendungsschicht und in Form einer «Allow List») spezifiziert sein. Ist eine Konformitätsprüfung in einer PEZ nicht möglich (z.B. im Falle End-zu-End verschlüsselter Kommunikation), kann die Prüfung auch durch die IT- Systeme in den Zonen selbst durchgeführt werden (im Sinne eines PEP). Allerdings ist dann der Einsatz von komplementären und risikomildernden Massnahmen vorzusehen und zu dokumentieren.
Obwohl der erste Satz Kommunikation von e liegende Zone gilt, kan Policies der entsprech Fällen darauf verzicht auch erhöhte Anforde Systeme, die Kommun Aufzeichnung der Kom
Z4.1 [ PEZ ] Die in einer PEZ betriebenen PEPs dürfen nur zonenintern virtualisiert betrieben werden, d.h. auf der gemeinsam genutzten Hardware dürfen keine IT- Systeme aus anderen Zonen betrieben werden.
Z4.2 [ PEZ ] Der Inhaber einer PEZ bzw. einer Web-Proxy- Infrastruktur muss regeln, wie der Zugriff auf Ressourcen im Internet erfolgt und welche Zugriffe zulässig sind. Diese Regelung kann entweder in der Zonenpolicy der PEZ oder in einer separaten Vorgabe erfolgen. Das NCSC kann Einträge in den entsprechenden Regelsätzen erlassen. Im Einsatzgebiet des IKT-SD Datenkommunikation (DAKO) erfolgt die Regelung im Rahmen von [Si004].
Für die Regelung der z im Internet ist der Inh PEZ betriebenen Web- muss es möglich sein, aktuell beobachteten A enstprechenden Regel
Z4.3 [ PEZ ] Die Anbindung einer PEZ an das Internet muss hochverfügbar und allenfalls redundant ausgelegt sein. Darüber hinaus muss der Betreiber mit Hilfe geeigneter Massnahmen sicherstellen, dass die durch die PEZ vom Internet getrennten IT-Systeme adäquat vor (D)DoS- Angriffen geschützt sind.
(D)DoS-Angriffe stelle dar. Um sich vor solch muss die Anbindung d hochverfügbar und all
Z5.1 [ Überwachung ] Innerhalb einer Zone muss die Kommunikation dahingehend überwacht werden, dass Angriffe möglichst zuverlässig erkannt werden können (z.B. mit Hilfe von IDS/IPS) und der Betreiber im Bedarfsfall zeitnah und adäquat reagieren kann.
Weil die Überwachung sinnvollerweise autom IDS/IPS postuliert. Da verstehen. Falls es and zeitnah zu erkennen u diese natürlich auch m nicht nur die Speicher natürlich auch deren r Auswertung im Hinbli
Z5.2 [ Überwachung ] Die bei der Überwachung anfallenden Informationen müssen gemäss den rechtlichen Vorgaben (insbesondere Datenschutzgesetzgebung und «Verordnung über die Bearbeitung von Personendaten, die bei der Nutzung der elektronischen Infrastruktur des Bundes anfallen» vom 22. Februar 2012) aufbewahrt und vor nachträglichen Manipulationen geschützt werden. Im Bedarfsfall müssen die Informationen dem NCSC zur Verfügung gestellt werden.
Die hier erwähnten re abschliessend zu betra andere Vorgaben exist Überwachung im Sinn berücksichtigt werden
Schutzobjektname
Referenzen
Abkürzungen
APS Arbeitsplatzsystem
BA Büroautomation
BCM Business Continuity Management
CA Certification Authority
CAPTCHA Completely Automated Public Turing test to tell Computers and Humans Apart
CC Common Criteria
CyRV Verordnung über den Schutz vor Cyberrisiken in der Bundesverwaltung
CZ Client Zone
DAKO Datenkommunikation
DDoS Distributed DoS
DIS Draft International Standard
DNS Domain Name System
DoS Denial of Service
DTI Digitale Transformation und IKT-Lenkung (Bereich der BK)
EAL Evaluation Assurance Level
EFK Eidgenössische Finanzkontrolle
FIDO Fast ID Online
FT Fremdterminal
IAM Identity and Access Management
ID Identifikator
IDS Intrusion Detection System
IEC International Electrotechnical Commission
IKE Internet Key Exchange
IKT Informations- und Kommunikationstechnologie
IoT Internet of Things
IP Internet Protocol
IPS Intrusion Prevention System
IPsec IP security
ISBO Informatiksicherheitsbeauftragter
ISDS Informationssicherheits- und Datenschutz
ISG Informationssicherheitsgesetz
ISO International Organization for Standardization
IT Informationstechnik
ITSCM IT Service Continuity Management
JSON JavaScript Object Notation
JWT JSON Web Token
LB Leistungsbezüger
LE Leistungserbringer
LoA Level of Assurance
MDM Mobile Device Management
NCSC Nationales Zentrum für Cybersicherheit
NW Network Full Access (uneingeschränkter Netzzugriff)
OSI Open Systems Interconnection
OTP One-Time Passwort
OWASP Open Web Application Security Project
PAM Privileged Access Management
PEP Policy Enforcement Point
PEZ Policy Enforcement Zone
PIN Persönliche Identifikationsnummer
PKI Public Key Infrastruktur
RA Restricted Access (eingeschränkter Netzzugriff)
SAML Security Assertion Markup Language
Schuban Schutzbedarfsanalyse
SD Standarddienst
SG-PKI Swiss Government PKI
SMS Short Message Service
SSH Secure Shell
SSO Single Sign-On
SZ Server Zone
SZ+ Server Zone mit erhöhtem Schutzbedarf
TCP Transmission Control Protocol
TLS Transport Layer Security
TPM Trusted Platform Module
VE Verwaltungseinheit
VSK verschlüsselte Sprachkommunikation
Ja
Nein
Teilweise
Nicht relevant
Nicht in diesem Schutzobjekt gelöst