Grundschutz und sichere Entwicklung: ein Change-Fall durch Architektur, Änderungen und Tests

Im Anwenderkatalog vom 29.10.2026 enthält die Praktik ARCH 63 Anforderungen, TEST 36 und DEV 34, jeweils rekursiv über alle Ebenen gezählt. Für das Anforderungspaket ist wichtiger, welchen Zielobjektkategorien sie zugeordnet sind. Anforderungen ohne Zielobjektkategorie gehören nach 300-1 Kap. 3.4.1 ohne Zuordnung zu Assets in das Anforderungspaket. Bei TEST betrifft das 35 der 36 Anforderungen; nur TEST.2.2 (Folgenabschätzung) richtet sich an die Kategorie Administrierende. Von den 35 stehen 26 auf normal-SdT (5 MUSS, 21 SOLLTE); 9 sind KANN-Anforderungen auf „erhöht“ und nach Kap. 3.4.2 optional. Das Änderungsverfahren gehört damit in jedes Anforderungspaket, unabhängig davon, welche Assets ein Informationsverbund hat.

Bei DEV sind 9 Anforderungen ohne Zielobjektkategorie, darunter das Verfahren, Security by Design, die Einschränkung des schreibenden Zugriffs auf Quellcode, die Freigabe und die Bereitstellung. 25 Anforderungen richten sich an die Kategorie Anwendungen und kommen hinzu, sobald Assets dieser Kategorie zugeordnet sind. Bei ARCH haben 7 Anforderungen keine Zielobjektkategorie, die übrigen hängen vor allem an Netzen und externen Netzanschlüssen. Ob DEV entfällt, wenn eine Institution nichts selbst entwickelt, regelt 300-1 nicht ausdrücklich. Die Erläuterung zu DEV.1.1 im Katalog sagt dazu: „Entwickelt die Institution im Informationsverbund keine IT-Produkte, so sind diese und alle anderen Anforderungen der Praktik entbehrlich.“ Im Anforderungspaket wird das je Anforderung mit dem Status „nicht anwendbar“ und einer Begründung festgehalten (300-1 Kap. 4.1.1); der Grund ist dann, dass die zugrunde liegende Komponente im Informationsverbund nicht existiert.

Der Zusammenhang steht im Katalog selbst. DEV.4.11 verlangt, Änderungen am Quellcode „im Einklang mit den Verfahren und Regelungen für Änderungen und Tests“ zu testen, DEV.6.1 und DEV.7.1 binden Freigabe und Bereitstellung ebenso an diese Verfahren. ARCH.2.2.8 (Segmentierung von Test und Betrieb) und ARCH.7.3 (Entwicklungs- und Testumgebungen) verweisen auf TEST.3.1.5, die dedizierte Testumgebung. Wer den Change-Prozess sauber aufsetzt, schafft damit die Grundlage für die DEV-Anforderungen, die auf dieses Verfahren verweisen, und für einige Architekturfragen.

Das Versorgungswerk Musterland (VWM) ist erfunden. Es betreibt ein selbst entwickeltes Mitgliederportal auf eigenen Virtualisierungshosts im eigenen Serverraum. Ein kleines Entwicklungsteam pflegt den Code, die Administration betreibt Hosts, Netz und Datenbank. Der Geschäftsprozess Beitragsfestsetzung hat im Schutzbedarf Vertraulichkeit die Kategorie hoch, weil Einkommensnachweise der Mitglieder verarbeitet werden.

Der Change CHG-031 soll Mitgliedern erlauben, Einkommensnachweise als PDF hochzuladen, statt sie per Post zu schicken. Dafür entstehen ein neuer Upload-Dienst, eine Ablage für die Dateien und eine Schnittstelle zum Fachverfahren. Weil der Geschäftsprozess hohen Schutzbedarf hat, ist nach 300-1 Kap. 2.11 ohnehin eine explizite Risikobetrachtung nötig; wie sie abläuft, zeigt die Seite Risikoanalyse. Hier geht es um den Weg der Änderung selbst.

Vor dem ersten Change hat das VWM die Gestaltungsentscheidungen getroffen, die TEST offenlässt. TEST.1.1 verlangt Verfahren und Regelungen zum Management von Neueinführungen, Änderungen oder der Entfernung von Komponenten und lässt per Parameter offen, ob sie für den Informationsverbund, pro Geschäftsprozess oder pro IT-System gelten. Das VWM hat sich für ein Verfahren für den ganzen Informationsverbund entschieden. Den Parameter „regelmäßig“ in TEST.1.2 hat es auf jährlich festgelegt. Parameter werden nach 300-1 Kap. 3.5 bei oder nach der Erstellung des Anforderungspakets konkretisiert.

TEST.2.2 verlangt, Administrierende zu einer strukturierten Folgenabschätzung vor wesentlichen Änderungen anzuweisen. Für CHG-031 erstellen sie diese Abschätzung und ordnen den Change einer Kategorie zu (TEST.2.2.1). Die Erläuterungen zu TEST.2.2 und TEST.2.2.1 schlagen Klassen wie geringe, mittlere und hohe Auswirkungen vor und empfehlen, die Prüftiefe nach dieser Einstufung auszurichten. Das VWM stuft CHG-031 als hoch ein: neuer, aus dem Internet erreichbarer Dienst, Daten eines Geschäftsprozesses mit hohem Schutzbedarf, neue Schnittstelle. Die geplanten Änderungen und die betroffenen Abhängigkeiten werden dokumentiert (TEST.2.2.2, TEST.2.2.3), darunter Datenbank, Fachverfahren, Zertifikat der Portaldomain und Datensicherung.

Die Architekturentscheidung fällt im selben Schritt. Der Upload-Dienst läuft auf einem eigenen virtuellen Host (ARCH.7.1 verlangt Serverdienste auf dedizierten virtuellen oder physischen Hostsystemen) in der demilitarisierten Zone (ARCH.2.2.6); die Ablage liegt im internen Segment, erreichbar nur über die neue Schnittstelle. Netzinventar und Netzplan werden vor der Umsetzung angepasst (ARCH.2.4, ARCH.2.5), damit Test und Freigabe gegen den geplanten Stand prüfen können.

DEV.2.1 verlangt, die Architektur nach dem Prinzip „Security by Design“ zu verankern, DEV.2.2 die Architektur der Anwendung zu dokumentieren. Für CHG-031 heißt das: Das Team beschreibt, welche Komponente welche Daten sieht, dass der Upload-Dienst ohne Schreibrecht auf das Fachverfahren läuft (DEV.2.3, Ausführung mit den geringstmöglichen Berechtigungen) und wo Eingaben geprüft werden (DEV.2.6.1, Eingabevalidierung). Fehlermeldungen des Upload-Dienstes geben keine Pfade oder Dateinamen anderer Mitglieder aus (DEV.3.3).

Der Upload nutzt zwei externe Bibliotheken zur PDF-Verarbeitung. DEV.4.2 untersagt die Einbindung externer Softwareartefakte aus unzuverlässigen oder unbekannten Quellen, DEV.4.3 verlangt eine Software Bill of Materials (SBOM) vor dem Release, DEV.4.4 einen Integritätstest externer Artefakte und DEV.4.5 einen Test auf Sicherheitsupdates vor dem Release. Beim Abgleich der SBOM fällt auf, dass eine der Bibliotheken in einer Version eingebunden ist, für die ein Sicherheitsupdate vorliegt. Das Release wird angehalten, die Bibliothek aktualisiert, SBOM und Tests werden neu erzeugt. Dieser negative Befund gehört in die Change-Akte: Er zeigt, dass die Prüfung tatsächlich stattgefunden hat.

Jede Codeänderung wird mit Zeitpunkt, Inhalt, ändernder Person und Begründung protokolliert (DEV.4.10) und nach dem Änderungsverfahren getestet (DEV.4.11). Im VWM übernimmt das die Versionsverwaltung: Jeder Merge referenziert CHG-031.

TEST.3.1 verlangt, vor wesentlichen Änderungen die Einhaltung der Sicherheitsanforderungen zu testen. Die Erläuterung zählt dazu technische Anforderungen und prozessuale, etwa zur Überwachung von Ereignissen oder zur Sensibilisierung des Personals. Getestet wird in einer dedizierten Testumgebung (TEST.3.1.5), die auf eigenen Hosts außerhalb der produktiven Virtualisierung läuft (ARCH.7.3) und gegen den Betrieb eingeschränkt ist (ARCH.2.2.8). Als Testdaten dienen erzeugte PDF-Dateien ohne echte Einkommensdaten (TEST.3.1.4). Prüfschritte, Ergebnisse und Korrekturen werden dokumentiert (TEST.3.1.1). Einen Penetrationstest bei kritischen Änderungen sieht TEST.3.1.11 als KANN-Anforderung vor; das VWM beauftragt ihn für CHG-031, weil der Dienst aus dem Internet erreichbar ist.

Kritische Änderungen sind nach TEST.4.1 anhand von Kriterien einschließlich der Sicherheitsanforderungen zu autorisieren. Das VWM hat dafür eine Freigabeliste: alle Testfälle bestanden, kein offener Befund der Schwere hoch aus dem Penetrationstest, SBOM aktuell, Rückfalllösung beschrieben. Zusätzlich autorisiert die Leitung IT-Betrieb als Person, die nicht an der Umsetzung beteiligt war (TEST.4.1.1, KANN). Die Freigabe wird mit Zeitpunkt, Vorhaben, Kriterien und freigebenden Personen dokumentiert (TEST.4.1.3). Die Rückfalllösung (TEST.4.3) besteht aus dem Abschalten des Upload-Dienstes per Konfiguration und dem Zurückspielen des vorherigen Release-Stands.

Eine Lücke bleibt: TEST.4.1.2 verlangt, freizugebende Änderungen in einer Staging-Umgebung zu testen, deren Komponenten so weit wie möglich der Produktivumgebung entsprechen. Die Testumgebung des VWM hat eine andere Datenbankversion. Die Staging-Umgebung ist im Umsetzungsplan vorgesehen, aber noch nicht gebaut. Das ist eine temporäre Nichterfüllung einer SOLLTE-Anforderung, die mit Begründung dokumentiert wird (300-1 Kap. 4.1.2). Was daraus folgt, lässt 300-1 offen: Kap. 4.1.2 sagt, eine temporäre Nichterfüllung löse keine Risikobetrachtung aus, Kap. 2.11 verlangt für SOLLTE-Anforderungen, die in der Umsetzungsplanung enthalten, aber noch nicht erfüllt sind, eine Restrisikobetrachtung mit Freigabe durch die Institutionsleitung, und Kap. 4.1.1 verlangt, das noch nicht mitigierte Risiko zu identifizieren und der Leitung mitzuteilen. Das ist eine offene Auslegungsfrage. Das VWM legt der Leitung das Restrisiko vor und vermerkt in der Change-Akte, dass es so verfährt und warum.

Vor der Bereitstellung informiert das VWM die betroffenen Kreise (TEST.5.1): Mitgliederservice, Sachbearbeitung Beitragsfestsetzung, Informationssicherheitsbeauftragte. Die Bereitstellung selbst erfolgt verschlüsselt (TEST.5.2) und nach dem Änderungsverfahren (DEV.7.1). Nach der Inbetriebnahme prüft die Administration die Persistenz (TEST.5.4): Die Erläuterung im Katalog meint damit, dass eine wesentliche Änderung auch nach Neustart, Update oder dem Rückspielen von Konfigurationssicherungen wirksam bleibt. Im VWM wird der Upload-Host einmal neu gestartet und die Firewallregel für die neue Schnittstelle nach dem Neustart erneut geprüft.

Den Parameter „regelmäßig“ in TEST.5.5 hat das VWM so konkretisiert: Rückblick sechs Wochen nach jeder Bereitstellung der Kategorie hoch, für alle übrigen Änderungen gesammelt einmal im Quartal. Für CHG-031 folgt der Rückblick also nach sechs Wochen: Wurden die Bereitstellungsziele erreicht, gab es unbeabsichtigte Auswirkungen auf Sicherheit, Stabilität oder Verfügbarkeit? Ergebnis im Fall: Ziele erreicht, eine offene Feststellung aus dem Penetrationstest der Schwere mittel ist mit Termin im Umsetzungsplan. Die Einhaltung der Netzarchitektur prüft das VWM ohnehin regelmäßig (ARCH.2.6); der nächste Lauf erfasst die neue Zone.

Wäre nach dem Go-live eine aktiv ausgenutzte Schwachstelle in einer der PDF-Bibliotheken bekannt geworden, hätte das Verfahren für Notfalländerungen gegriffen (TEST.4.4). Es legt Vorgehensweise, Zuständigkeiten, erforderliche Ressourcen und minimale Prüfschritte fest. Die Erläuterung nennt als Beispiele ein Eskalationsverfahren, beschleunigte Sicherheitsprüfungen mit Vier-Augen-Prinzip und eine Nachbereitung. Eine Notfalländerung verkürzt den Weg; Dokumentation und Nachbereitung bleiben.

Die Tabelle zeigt die Change-Akte so, wie sie im Fall aussieht. Spalte zwei nennt Kennung und Modalverb der Anforderung, Spalte vier den Nachweis, den eine Prüferin oder ein Prüfer sehen will. 300-1 Kap. 4.3 verlangt, Nachweise der jeweiligen Maßnahme eindeutig zuzuordnen; die Akte erfüllt das, indem jede Zeile auf ein Dokument oder einen Eintrag verweist. Alle Angaben sind erfunden.

Die Fragen leiten sich aus dem Fall ab. Sie ersetzen nicht die Bewertung jeder einzelnen Anforderung Ihres Anforderungspakets, zeigen aber, wo Change-Prozesse aus der Zeit vor Grundschutz++ nachgeschärft werden müssen.