Security-Baseline

Einordnung

Dieses Dokument definiert die Security-Baseline für die Einsatzsoftware und die dazugehörige Betriebsumgebung.

Ziel ist ein Sicherheitsniveau, das Abhören, Manipulation und Störung durch hochfähige Angreifer (einschließlich böswilliger Staaten) möglichst erschwert.

Die Software muss nicht für VS-NfD zugelassen sein. Die Architektur SOLL jedoch so gestaltet werden, dass eine spätere Hochstufung der Schutzmaßnahmen (bis hin zu VS-NfD) konzeptionell möglich bleibt.

Normative Grundlage

Die Security-Baseline wird vollständig auf Basis des BSI IT-Grundschutzes umgesetzt. Maßgeblich sind insbesondere:

BSI-Standard 200-1 (ISMS / Sicherheitsmanagement)
BSI-Standard 200-2 (IT-Grundschutz-Methodik)
BSI-Standard 200-3 (Risikoanalyse auf Basis IT-Grundschutz)
IT-Grundschutz-Kompendium (jeweils aktuelle Edition, inkl. Errata)

Das IT-Grundschutz-Kompendium wird vom BSI jährlich aktualisiert und bildet zusammen mit den BSI-Standards die Basis der Methodik. Siehe BSI-Übersicht und Downloadbereiche.

Verbindlichkeit der Anforderungswörter

Die Semantik der Anforderungswörter MUSS exakt so angewendet werden, wie sie der IT-Grundschutz vorsieht.

Insbesondere gilt:

MUSS / DARF NICHT: verbindlich umzusetzen
SOLLTE / SOLLTE NICHT: i. d. R. umzusetzen; Abweichungen NUR mit nachvollziehbarer Begründung und dokumentierter Abwägung
KANN: optional; keine Pflicht zur Umsetzung

Projektintern werden Anforderungswörter NICHT umgedeutet. “KANN bleibt KANN, MUSS bleibt MUSS, SOLL bleibt SOLL.”

Geltungsbereich

Die Baseline gilt für:

Client-Systeme (Windows, iOS, Android, Kiosk-/Anzeige-Systeme)
Server-Systeme (Debian, optional containerisiert)
Kommunikationswege (Netz, lokale Netze, Offline-Transport)
Entwicklungs- und Updateprozesse (Supply-Chain, Artefakte, Rollout)
organisatorische Sicherheitsprozesse (ISMS, Rollen, Incident-Handling)

Die zugrunde liegende Plattformlandschaft ist in Betriebsumgebung beschrieben.

Umsetzungsvorgehen nach IT-Grundschutz

Die Umsetzung MUSS nach der IT-Grundschutz-Methodik erfolgen.

1. ISMS etablieren

Ein Informationssicherheitsmanagementsystem MUSS eingerichtet werden, inkl. Rollen, Verantwortlichkeiten, Richtlinien und Prozessabläufen.

2. Scope und Strukturanalyse

Der Geltungsbereich (Informationsverbund) MUSS definiert werden. Assets, Systeme, Netze, Anwendungen und Prozesse MÜSSEN strukturiert erfasst werden.

3. Schutzbedarfsfeststellung

Der Schutzbedarf MUSS je Objekt ermittelt werden. Für Objekte mit erhöhtem Schutzbedarf ist eine vertiefte Betrachtung einzuplanen.

4. Modellierung mit Bausteinen

Für den Informationsverbund MÜSSEN die relevanten Bausteine aus dem Kompendium modelliert werden. Das umfasst typischerweise u. a.:

Windows-Clients, Laptops, mobile Geräte (iOS, Android)
Server unter Linux
Containerisierung (falls genutzt)
Netze und Kommunikation (VPN, Firewalls, WLAN etc.)
Anwendungen und Individualsoftware-Entwicklung
Wechseldatenträger

5. Umsetzung von Anforderungen

Alle MUSS- und DARF-NICHT-Anforderungen MÜSSEN umgesetzt werden.

SOLLTE-Anforderungen SOLLTEN umgesetzt werden. Falls nicht, MUSS die Abweichung begründet, freigegeben und dokumentiert werden.

KANN-Anforderungen sind optional.

6. Risikoanalyse bei erhöhtem Schutzbedarf

Wenn Schutzbedarf oder Bedrohungslage dies erfordern, MUSS eine Risikoanalyse nach BSI-Standard 200-3 durchgeführt werden.

Dies ist insbesondere relevant, wenn fraglich ist, ob Basis- und Standard-Anforderungen für ausreichende Sicherheit genügen.

Bedrohungsmodell (Baseline)

Die Baseline geht davon aus, dass Angreifer grundsätzlich:

Kommunikation abhören (Passivangriffe)
Kommunikation manipulieren oder stören (Aktivangriffe)
Endgeräte kompromittieren (Malware, Exploits, Supply-Chain)
Benutzerkonten missbrauchen (Phishing, Credential Stuffing)
physische Angriffe versuchen (Diebstahl, Zugriff auf Geräte)

Die Architektur MUSS daher Vertraulichkeit, Integrität und Verfügbarkeit systematisch adressieren.

Baseline-Anforderungen für die Architektur

Die folgenden Punkte sind als Baseline-Ziele zu verstehen. Die konkrete Umsetzung MUSS durch die IT-Grundschutz-Bausteine und -Anforderungen konkretisiert werden.

Vertraulichkeit

Datenübertragung MUSS gegen Abhören geschützt werden.
Datenhaltung auf Endgeräten und Servern MUSS gegen unbefugten Zugriff geschützt werden.
Schlüsselmaterial MUSS angemessen geschützt werden.

Integrität

Manipulation von Daten MUSS erkennbar und möglichst verhinderbar sein.
Änderungen an Daten MÜSSEN nachvollziehbar sein (Protokollierung, Auditierbarkeit).
Software-Artefakte (Installer, Container, Updates) MÜSSEN vor Manipulation geschützt werden.

Verfügbarkeit und Resilienz

Das System MUSS bei Netzausfall arbeitsfähig bleiben, soweit in Netzausfall gefordert.
Störangriffe (z. B. Überlastung) SOLLTEN durch geeignete Maßnahmen begrenzt werden.
Wiederanlauf und Recovery MÜSSEN planbar und dokumentiert sein.

Zugriffskontrolle und Identitäten

Identitäts- und Berechtigungsmanagement MUSS etabliert werden.
Minimale Rechte (Least Privilege) MÜSSEN umgesetzt werden.
Administrativer Zugriff MUSS besonders geschützt werden (z. B. getrennte Konten, starke Authentisierung, Protokollierung).

Protokollierung und Incident Response

Sicherheitsrelevante Ereignisse MÜSSEN protokolliert werden.
Protokolle MÜSSEN gegen Manipulation geschützt werden.
Reaktion auf Sicherheitsvorfälle MUSS organisatorisch und technisch möglich sein (Meldewege, Zuständigkeiten, Maßnahmen).

Supply-Chain und Updatefähigkeit

Abhängigkeiten SOLLTEN beherrschbar und prüfbar sein.
Artefakte SOLLTEN signiert und nachvollziehbar versioniert sein.
Offline-Installation und Offline-Updates MÜSSEN möglich sein (siehe Betriebsumgebung).

Gedankliche Vorbereitung für VS-NfD

Auch wenn keine VS-NfD-Zulassung gefordert ist, SOLLTE die Architektur so gestaltet werden, dass eine spätere Hochstufung nicht grundsätzlich verhindert wird.

Der IT-Grundschutz berücksichtigt Geheimschutz/VS-NfD explizit als Baustein (CON.11.1) in Edition 2023. Das unterstreicht, dass eine Konzeption für höhere Schutzanforderungen im Rahmen des Grundschutzes grundsätzlich vorgesehen ist.

Konkrete Maßnahmen für VS-NfD sind NICHT Teil dieser Baseline. Die Baseline fordert lediglich, spätere Aufrüstung nicht zu verbauen (z. B. durch starre Kryptofestlegungen oder untrennbare Datenräume).

ESW Dev