Sicherheit, Schutz und Protektion in ArchRL überarbeiten

betrifft Vorgaben:

Bezug zu:

Aufgaben:

  • Titel überarbeiten
  • Begründung überarbeiten
  • Abhängigkeiten überarbeiten
  • Implikationen überarbeiten
  • Kommentarsektionen überarbeiten
  • Self-Assessment überarbeiten
  • Security by Default
  • geschäftskritische IT/ Kritikalität
  • Post-Quanten-Kryptografie
  • Zero Trust
  • Cyber Resilience Act
  • Code Security
  • Verlagerung Datenschutz
  • wehrhafte Demokratie
  • Resilienz, resiliente Wertschöpfungsketten
  • Krisenmanagement
  • Digitale Identitäten, Identitätsinformationen
  • Schutzzonen, Zonen
  • Georedundanz

Hinweise:

  • keine doppelten Namen in Vorgaben "Schutz"
  • Klarstellung/ Benennung Security by Default
  • FV-08 Vorgabenformulierung nicht gut nachvollziehbar (Schutz durch Schutz)
  • Trennung von geschäftskritischer IT von der fachlichen und querschnittlichen IT (Hintergrund: Absicherung der Geschäftsgrundlage und der Untersetzung unterschiedlicher Rahmenbedingungen (mehr Sicherheit bei Kritikalität, mehr Freiheit bei regulärer IT))
  • Standards für Post-Quanten-Kryptografie der NIST (National Institute of Standards and Technology) (TV-08 zu Kryptografie)
    • ML-KEM => verschlüsselte Kommunikation mit Webseiten oder Servern
    • MS-DSA, SLH-DSA => Erstellung und Überprüfung digitaler Signaturen
  • Aus dem Entwurf zu Zero Trust Sicherheitsarchitektur:
    • Kommunikationsströme werden netzwerkunabhängig abgesichert („Assume Breach“, Zugangsanfragen von innerhalb wie von außerhalb)
    • Sichere Authentifizierung für alle Zugriffe
    • Zugang zu Daten, Geräten und Anwendungen nur mit minimalen Rechten gewährt
    • Identitäten, Endgeräte, Netzwerke, Anwendungen und Datenverkehr werden kontinuierlich überwacht (Echtzeitüberwachung)
    • Nutzer sind geschult und leben Zero Trust basierte Prozesse
  • Wird der Cyber Resiliance Act (CRA) berücksichtigt? Welche Rolle spielt Open Source in der Bewertung des CRA? Wie wird die nicht-/kommerzielle Nutzung von Code bewertet/ reguliert?
    • Umstände der Entwicklung
    • Finanzierung der Entwicklung
  • Informationssicherheit, Geheimschutz und Datenschutz werden in einer einzigen AV behandelt
    • nicht zielführend
    • befördert die Meinung "ist doch alles eine Sache - Sicherheit eben"
    • unterschiedliche Motivation, insbesondere bei Datenschutz
    • Zweck und Mittel ggf. ähnlich
    • betroffene Organisationen auch getrennt (u.a. BfDI, BSI)
    • Sicherheit als Ganzes betrachten, Fokus auf Verlässlichkeit, ggf. Titel darauf abändern
    • Abgrenzung zu AV-04 Datenzentriertes Handeln, Nachvollziehbarkeit sicherstellen
    • Abgrenzung zu Qualitätsmanagement und Entwicklung
    • Bsp: Hürden Autonome Systeme (e.g. Fraunhofer) "Verlässlichkeit umfasst dabei viele Qualitätseigenschaften wie Sicherheit, Verfügbarkeit, und Zuverlässigkeit."
  • wehrhafte Demokratie, z.B. Fakes vermeiden, innere Verfasstheit stärken, berücksichtigt wird. Bedarfsweise Abgleich mit der AV-06 Kollaboration oder zu AV-07 Offenheit.
  • Zu klären ist wie Resilienz abgedeckt ist
  • Desinformation
  • Welche Standards gibt es? Wie passt das in FV-08 Schutz und TV-08 Protektion?
  • Wie wird abgedeckt das die Vorgaben im Bereich Sicherheit anwendungsorientiert bleiben
  • betrifft primär Identitätsinformationen und deren Umgang, also funktionale Fragestellungen (FV-08 Schutz ?)
  • Definition/ Festlegung von Schutzzonen, Zonen
    • Nutzende, die die Anforderungen an NdB nicht einhalten können, sollen über das NdB-Extranet / Grundschutzzone Zugriff auf ggf. „separierte“ NdB-Dienste erhalten“
    • Der derzeitige Entwicklungsstand des Zonenkonzepts und der möglichen Übergänge zwischen den Zonen, erlaubt noch keine konkrete Beschreibung in der Architekturrichtlinie
    • aktuell nicht alle IT-Lösungen über den GS/Ex-Anschluss zugänglich sind (insbes. PVSplus und SIB Dachportal). Dazu gibt es auch neue IT-Lösungen, wo der Zugang noch geklärt werden muss (u.a. TMS, ITR4Web, Controlling Bund).
    • bei der Bereitstellung von zentralen IT-Lösungen sollte geprüft werden, ob ein Zugang über den GS/Ex-Anschluss für die jeweilige IT-Lösung erforderlich ist. Falls Behörden mit GS/Ex-Anschluss einen Zugang benötigen, so sollte sichergestellt werden, dass der Zugang über den GS/Ex-Anschluss durch die jeweilige IT-Lösung ermöglicht wird.
    • Abstimmung zu BMDV-WAN
  • Regel 4 und 5 von AV-08 ggf. in eine andere Ebene verschieben
  • Abgleich mit Vorgabe zu Design (Schutz von Bildern durch Wasserzeichen & Co.)
Edited by Heiko Hartenstein