Begrüßung. Der Vortrag dauert rund 80 Minuten, danach Zeit für Fragen.
Er richtet sich an Kolleginnen und Kollegen aus den CISO-Bereichen und den Lageorganisationen der Länder und steht darüber hinaus Nutzerinnen und Nutzern der Plattform zur Verfügung. Er stellt das Konzept in den Vordergrund und zeigt die Entscheidungen, die dahinterstehen, jeweils mit einem Beispiel.
Die Reihenfolge folgt dem Weg der Information: von der Aufgabe über die Systeme zur Aufnahme, Anreicherung und Darstellung, danach die Steuerung der Abläufe, der Zugriff und der Betrieb.
Teil 3 und Teil 7 haben das größte Gewicht, weil sich dort die wesentlichen Entscheidungen zeigen.
Zur Entstehung: Der Foliensatz wurde mit KI erzeugt, mit dem Modell Claude Sonnet 5.5 von Anthropic im Werkzeug Claude Code. Das Modell hat die Folien aus den Dokumenten, der Konfiguration und dem Quelltext des Repositories erstellt; Zahlen werden beim Bau aus dem Repository gelesen. Die Folien sind ein Entwurf und vor einer Verwendung inhaltlich zu prüfen.
Diese Einordnung gehört an den Anfang. Der Demonstrator ist erstellt worden, um Konzepte zu erproben und um Vergaben vorzubereiten. Quelltext und Dokumentation sind aus Effizienzgründen mit KI-Unterstützung entstanden; die Sicherheitsprüfung ist noch nicht abgeschlossen. Mit der KI-Nutzung im Betrieb hat das nichts zu tun, sie ist ein eigenes Thema im Kapitel Berichte. Der Demonstrator ist nicht für den produktiven Betrieb vorgesehen. Offene Punkte und der Stand der Prüfung stehen im Konzept; am Ende des Vortrags fasse ich sie zusammen.
Aussagen in diesem Vortrag beschreiben das Konzept und den Stand des Repositories, nicht einen Betrieb mit echten Teilnehmerdaten.
Teil 1. Kurz halten: Die Einordnung wurde bereits gegeben, hier geht es um Aufgabe, Rollen und die zwei Lagebilder.
Die Aufgabe hat zwei Seiten. Zum einen liegt viel öffentliche Information vor, die sich nur mit Aufwand überblicken lässt: 34 aktive Feeds zählt die Plattform. Zum anderen gibt es vertrauliche Informationen der Teilnehmenden, die nur in definierten Kreisen weitergegeben werden dürfen.
Die Plattform soll beides in einer Umgebung verbinden, ohne die Vertraulichkeitsstufen zu vermischen. Als Nichtziel ist im Konzept festgehalten: keine vollautomatische Lagebewertung ohne menschliche Prüfung.
Die Rollen kommen aus Keycloak und gelten in allen Systemen. Wer sich registriert, sieht das Allgemeine Lagebild IT. Alles darüber hinaus gibt es nur auf Antrag und nach Prüfung; der Antrag läuft als Ticket in Zammad, dazu später mehr.
Das Plattformmanagement hat bewusst keinen Zugriff auf Fachinhalte, sondern verwaltet nur Konten.
Das Allgemeine Lagebild gibt wieder, was öffentlich bekannt ist. Es wird nicht redaktionell geprüft und gibt die Aussagen der Quellen wieder, keine eigene Bewertung.
Das Lagebild Schleswig-Holstein ist der geschützte Raum der Mitglieder. Es baut auf dem ersten auf und ergänzt Bewertungen der Lagezentrale und Meldungen der Teilnehmenden, die so aufbereitet sind, dass die meldende Stelle nicht erkennbar ist.
Teil 2. Zuerst die Architektur auf einer Folie, danach die einzelnen Systeme.
Einleitende Folie zur Architektur. Zu den Weboberflächen führt der Zugang von außen über Traefik, den Reverse Proxy mit TLS; die Mail-Ports gehören zu Mailcow. Dahinter liegen vier Fachsysteme: die Infoseite mit dem Mitgliederbereich, OpenCTI als Wissensgraph, Zammad als Ticketsystem und Keycloak für Anmeldung und Rollen.
Die Systeme sind nicht direkt miteinander gekoppelt, sondern über eine kleine Middleware, die die offiziellen Schnittstellen nutzt (ADR 004). Öffentliche Quellen werden von OpenCTI als Feeds abgerufen und von der Middleware ergänzt (KEV, EUVD, NVD, EPSS, CSAF). Mailcow nimmt Meldungen verschlüsselt entgegen.
Der gesamte Stack ist als Konfiguration im Git-Repository beschrieben und wird von einem Reconciler angewendet. Optional gibt es ein selbst betriebenes Sprachmodell und zusätzliche Connectoren; beide sind in der Grafik nicht dargestellt, weil sie standardmäßig nicht aktiv sind. Mailcow läuft als eigenes Compose-Projekt.
Keycloak ist die zentrale Stelle für Identitäten. Die Rollenlogik wird einmal definiert und per Token in die Fachsysteme übernommen, damit keine Doppelpflege entsteht.
Die Struktur, also welche Rollen und Gruppen es gibt, steht im Repository. Wer welche Rolle hat, wird im Betrieb vergeben, zum Beispiel beim Beitritt.
OpenCTI ist das Fachsystem für das Lagebild. Der entscheidende Punkt ist das Datenmodell: Es ist ein Graph aus Objekten und Beziehungen. Dazu gehe ich in Teil 3 ausführlich ein.
Für die Vertraulichkeit nutzt OpenCTI Markings. Eine Gruppe sieht ein Objekt nur, wenn sie alle seine Markings erlaubt hat. Das haben wir mit Testkonten an der Instanz geprüft (ADR 015).
Zammad wird hier weniger als klassisches Helpdesk genutzt, sondern als Steuerung: Ein Ticket beschreibt einen Vorgang, ein Zustand ist eine Entscheidung, und der Zustandswechsel löst über einen Webhook die Ausführung durch die Middleware aus.
Das hat einen praktischen Grund: Die Entscheidungen werden von Personen mit den passenden Rechten getroffen, bleiben nachvollziehbar und brauchen kein weiteres Werkzeug. Details in Teil 7.
Die Middleware ist keine Option, sondern trägt die Integration. Sie ist bewusst klein gehalten und nutzt nur offizielle Schnittstellen, damit die Systeme austauschbar bleiben (ADR 004).
Der Preis ist eine weitere Komponente im Betrieb; sie ist deshalb in Überwachung und Restore-Test einbezogen.
Die Bausteine sind überwiegend Standardkomponenten. Optional sind das Sprachmodell und die Connectoren; beide sind standardmäßig aus, die Plattform arbeitet ohne sie vollständig (ADR 006).
Die Connectoren sind bewusst offizielle Bausteine und keine Eigenentwicklung (ADR 018). Der Pilot läuft auf einem Server bei einem Cloud-Anbieter, ein Hochverfügbarkeits-Setup gibt es nicht.
Teil 3, der erste Schwerpunkt. Zeit einplanen für die Grafiken und die Screenshots.
Der graphenorientierte Ansatz ist die zentrale Entscheidung bei der Wahl von OpenCTI. Ein Bericht als Dokument beantwortet, was eine Stelle geschrieben hat. Ein Graph hält fest, welche Dinge es gibt und wie sie zusammenhängen: Eine Schwachstelle ist ein Objekt, das von mehreren Berichten genannt wird, zu Produkten gehört und von Stellen beobachtet wird.
Der Vorteil ist, dass Zusammenhänge nicht bei jeder Frage neu aus Texten gelesen werden müssen, sondern abgefragt werden können, und dass jede Aussage ihre Herkunft behält.
Das Modell kommt aus dem Standard STIX 2.1 und ist kein Sondermodell von OpenCTI. Entscheidend ist, dass die Kante ein eigenes Objekt ist: Sie hat eine Kennung, einen Urheber, eine Konfidenz und Zeitangaben. In einem Dokumentenmodell wäre das ein Satz im Text. Hier ist es eine Aussage, die man zählen, filtern und belegen kann.
Der Beziehungstyp related-to ist zwischen allen Objekttypen erlaubt. Andere Typen wie uses oder targets sind nur zwischen bestimmten Typen zulässig. Das ist der Grund, warum die Plattform für Hersteller und Sektoren related-to nutzt.
Zwei Quellen, die dasselbe Produkt unterschiedlich bewerten, stehen als zwei Aussagen nebeneinander. Sie werden nicht zusammengelegt. Die Zahl der bestätigenden Stellen ergibt sich daraus, dass man die Urheber der Aussagen zählt.
Das Sighting ist die passende Form für Beobachtungen: Es gehört nicht zur Schwachstelle, sondern zur Stelle, die sie gesehen hat. Deshalb bleibt die Schwachstelle unverändert, und die Frage, wer die Ausnutzung bestätigt, lässt sich durch Zählen beantworten.
Die Kennung CVE-2026-1001 ist ein Beispiel und keine reale Schwachstelle.
Die Plattform nutzt das Standardmodell von OpenCTI und erfindet keine eigenen Objekttypen. Neu ist die Verwendung: Beobachtungen und Gruppierungen werden gezielt für Fragen eingesetzt, die sonst im Text stecken würden.
So war der Graph zu Beginn aufgebaut, sternförmig um den Bericht. Das ist die übliche Form, wenn Berichte aus Feeds importiert werden. Die Verknüpfung der Berichte mit den Objekten hat bereits geholfen; sie sagt aber nichts darüber, wie die Objekte untereinander zusammenhängen.
Die Weiterentwicklung hat deshalb Beziehungen zwischen den Objekten selbst ergänzt (ADR 026), und zwar in drei Stufen: Beziehungen aufbauen, Aussagen aus Berichten ableiten, den Graphen auswerten.
Das ist das Zielbild für eine einzelne Schwachstelle. Der Bericht nennt sie. Zur Schwachstelle gehören Produkte, deren Hersteller wiederum Sektoren zugeordnet sind; die Zuordnung zu Sektoren ist abgeleitet und deshalb gestrichelt und im Graphen als abgeleitet gekennzeichnet.
Rechts stehen die Stellen, die die Ausnutzung beobachtet haben: jeweils als Beobachtung mit Datum. Unten der Sachverhalt, der Berichte und Schwachstelle zusammenfasst.
Die Darstellung ist ein Beispiel. Die Namen der Stellen sind Platzhalter für reale Beobachter.
Die Konfidenz ist ein Feld, das OpenCTI für jedes Objekt und jede Beziehung vorsieht. Wir nutzen es, um die Verlässlichkeit der Quelle abzubilden. Strukturdaten wie die Produktangaben im NVD haben eine höhere Konfidenz als Zuordnungen, die wir aus einer Liste ableiten.
Abgeleitetes wird nicht versteckt, sondern gekennzeichnet. Das ist eine Entscheidung für Nachvollziehbarkeit: Wer eine Aussage sieht, soll erkennen, ob sie belegt oder angenommen ist.
Ein Label sagt nur, dass etwas gilt. Eine Beobachtung sagt, wer es wann festgestellt hat. Das ist für ein Lagebild die relevantere Information, denn die Zahl unabhängiger Stellen, die die Ausnutzung bestätigen, ist ein Hinweis auf die Verlässlichkeit.
Bei der ENISA nennt die Datenbank kein Datum der Ausnutzung; die Beschreibung der Beobachtung sagt deshalb ausdrücklich, dass das Datum der Tag der ersten Sichtung ist. Erfunden wird nichts.
Zusammengeführt wird nichts: Jeder Bericht ist die Aussage einer Stelle zu einem Zeitpunkt. Der Sachverhalt bündelt sie und macht sichtbar, wie viele unabhängige Stellen berichten. Unabhängig heißt: verschiedene Herausgeber. Nachrichtenseiten geben meist die Meldung einer Behörde wieder und zählen deshalb nicht mit (ADR 023).
Screenshot aus einer Testinstanz mit Beispieldaten: ein Bericht, im Reiter Wissen die verknüpften Schwachstellen, Produkte, Hersteller und Sektoren. Zu zeigen: dass die Verknüpfungen nicht von Hand gepflegt, sondern aus dem Berichtstext und den Produktdaten erzeugt wurden.
Screenshot aus einer Testinstanz, Reiter Wissen einer Schwachstelle: oben die Zahl der Berichte, der Beobachtungen und der Beziehungen, darunter die Verteilung der Berichte nach Quellen und die Verteilung der Sichtungen. Die einzelnen Beobachtungen der Stellen und die betroffenen Produkte zeigt dieses Bild nicht; sie sind über die Programmierschnittstelle abrufbar. Noch nicht an der echten Instanz abgenommen ist, wie die Oberfläche die Beobachtungen im Einzelnen anzeigt.
Der Nutzen zeigt sich bei den Fragen, die sonst Handarbeit wären. Die Berichte nutzen die Beziehungen bereits: Die Abschnitte zu Herstellern und Sektoren im Tages- und Wochenbericht werden aus dem Graphen gezählt.
Die Benachrichtigung nach Referenzprofil ist nicht umgesetzt; die Grundlage dafür, Produkte und ihre Schwachstellen, ist vorhanden.
Nicht jede Idee trägt. Vor dem Bau haben wir an den echten Feeds gemessen. Beziehungen zwischen Akteuren und Schwachstellen ließen sich aus Texten kaum belastbar ableiten, Indikatoren stehen in diesen Feeds selten, und die Kette über CWE und CAPEC zu ATT&CK ist zu unscharf.
Die Beobachtungen aus den Berichten der Behörden dagegen tragen: In der Stichprobe lieferten 22 Prozent der Behördentexte eine Beobachtung, 16 von 18 geprüften Sätzen waren richtig.
Das Vorgehen ist Teil der Methodik: erst messen, dann bauen, und die Messung im ADR festhalten.
Teil 4. Auf die Trennung von Aufnahme und Freigabe hinweisen.
Die Quellen stehen in einer Konfigurationsdatei im Repository, nicht in der Oberfläche. Jede Quelle hat einen Namen, die herausgebende Organisation, optional ein Herkunftsland und Merkmale wie Filter oder die Kennzeichnung als Medium.
Das Quellenverzeichnis ist bewusst eine Liste ohne Bewertung. Die Plattform sagt, woher Informationen stammen und wie viele es sind, nicht, wie gut eine Quelle ist.
Wichtig ist die Trennung von Aufnahme und Freigabe: Was automatisch hereinkommt, ist öffentlich und trägt TLP:CLEAR. Eine Verteilung an Mitglieder löst erst eine Person aus.
Neue Quellen werden vor dem Eintrag geprüft. Dabei zeigt sich auch, dass die Landschaft uneinheitlich ist: nicht jede Behörde bietet einen Feed an, manche Feeds sind fehlerhaft oder nicht abrufbar.
OpenCTI kann beim Feed-Import nicht filtern. Die Middleware liest den Quell-Feed, prüft jeden neuen Eintrag und stellt die Treffer als eigenen Feed bereit, den OpenCTI wie jeden anderen importiert. Dadurch gibt es keinen zweiten Weg in die Plattform.
Ein Filter nach Schlagwörtern im Titel hätte Meldungen verpasst; die CVE-Kennung im Text war in der Messung das zuverlässigere Merkmal.
Das Ausmaß: In einer Messung ergab der Volltext etwa dreimal so viele Schwachstellen und sechsmal so viele Namen wie der Feed-Text allein. Dem steht ein Eingriff in fremde Server gegenüber, deshalb die engen Regeln. Der Abruf ist abschaltbar und je Quelle ausnehmbar.
Die Seite wird täglich aus der Konfiguration und den Zählern erzeugt, nicht von Hand geschrieben. Sie erklärt die Quellen, die Aufbereitung, die Anreicherung und den Einsatz von KI und kann deshalb nicht vom laufenden System abweichen.
Zugriff nur für Mitglieder und Lagezentrale; daneben gibt es dieselben Angaben maschinenlesbar als JSON. Die Zahlen im Bild sind Beispieldaten.
Teil 5. Hier stehen die Messungen vor dem Bau im Mittelpunkt.
Der erste Schritt ist unspektakulär, aber die Grundlage: Aus dem Text wird ein Objekt. Alles Weitere hängt am Objekt Schwachstelle und nicht mehr am Bericht.
Die Bewertungen kommen aus mehreren Quellen; welche gilt, wenn sie sich widersprechen, ist festgelegt. In einem Fall musste ein Fehler korrigiert werden: Vektoren der Version 3.0 wurden von OpenCTI abgelehnt und mussten umgeschrieben werden.
Die Rangfolge folgt der Verlässlichkeit: Die National Vulnerability Database ist am genauesten, die Angaben aus dem KEV-Katalog nur ein Notbehelf. Hersteller-Advisories im CSAF-Format kommen derzeit nur von den Koordinatoren BSI und CISA; Herstellerquellen selbst sind bewusst nicht aufgenommen, dafür wird eine eigene Lösung gesucht.
Die automatische Verknüpfung ist heuristisch. Deshalb steht die Fehlerquote vor dem Bau: Ohne Regeln war ein Drittel der Treffer falsch. Mit den Regeln war es ein Fehlalarm bei zehn Treffern, und dieser wurde in die Stoppliste aufgenommen.
Fehlverknüpfungen lassen sich am Bericht entfernen; die Stoppliste liegt im Repository.
Hier greift das Messprinzip noch einmal: In der Stichprobe war ein gutes Fünftel der Behördentexte betroffen, und 16 von 18 geprüften Sätzen waren richtig. Die beiden Fehler waren Möglichkeits- und Bedingungssätze; sie sind in den Regeln berücksichtigt.
Der Vorsprung gegenüber dem KEV-Katalog ist klein, denn fast alle genannten Schwachstellen standen schon dort. Der Gewinn liegt in den weiteren Beobachtern, also in der Frage, wie viele Stellen es bestätigen.
Das Beispiel ist ein erfundener Eintrag in der Form der Sicherheitshinweise des CERT-Bund. Die Schritte laufen nacheinander und sind unabhängig voneinander wiederholbar; fehlt eine Quelle, bleibt der Bericht ohne diesen Teil und wird später erneut bearbeitet.
Wichtig ist die Rolle jedes Schritts: Er nutzt keine Schätzung des Textes, sondern ordnet Daten aus bekannten Quellen zu. Der Text selbst liefert nur die Kennung der Schwachstelle und, in Schritt 5, einen Satz als Beleg. Schritt 4 findet im Beispiel nichts; das ist der Normalfall und gewollt, weil Treffer aus kurzen Namen häufig falsch wären.
Produkte entstehen asynchron in einer eigenen Schleife. Junge Berichte warten deshalb kurz auf die Produktdaten.
Links steht der Eintrag, wie er aus dem Feed kommt, rechts derselbe Bericht nach der Anreicherung. Der Originaltext wird nicht verändert. Der Block „Schwachstellen im Bericht“ ist als automatisch gekennzeichnet; so ist erkennbar, was von der Quelle stammt und was die Plattform ergänzt hat.
Die Labels sind Suchmerkmale für Dashboards und Berichte: Wer alle kritischen Meldungen der letzten Tage sucht, braucht keinen Text zu lesen.
Hier ist das Ergebnis in der Form, in der es der Graph hält. Der Bericht hängt an der Schwachstelle, und an der Schwachstelle hängen Produkt, Hersteller und die Beobachtung der Stelle, die die Ausnutzung meldet. Jede dieser Verbindungen trägt Urheber und Konfidenz.
Das Beispiel zeigt auch den Nutzen: Kommt eine zweite und dritte Meldung zur selben Schwachstelle, entsteht kein weiterer Knoten, sondern es kommen Berichte und Beobachtungen hinzu. Daraus ergibt sich die Zahl der bestätigenden Stellen ohne weiteren Aufwand.
Teil 6. Kurz, mit dem Beispielbericht.
Das Dossier erweitert die Sammlung um das, was sonst nur beim Lesen aller Berichte sichtbar wird: Was ist die Lücke, was sagen alle übereinstimmend, und was steht nur in einem Bericht. Der dritte Teil ist der Wert für die Lagezentrale, denn ein Hinweis auf Ausnutzung oder eine Umgehungsmaßnahme in nur einem Bericht geht sonst leicht unter.
Das Dossier ist ein eigenes Objekt, eine Notiz. Eine Notiz zählt nicht als Bericht und verfälscht deshalb weder Berichtszahlen noch die Bildung der Sachverhalte. Sie bezieht sich auf dieselben Objekte wie der Sachverhalt und teilt sie dadurch mit ihm und mit den Berichten; so gilt sie in OpenCTI als korrelierter Container. Zusätzlich verbinden Kanten sie mit dem Sachverhalt und der Schwachstelle. Sie lässt sich einzeln finden, kennzeichnen und an Berichten und Schwachstellen unter Notizen sehen. Die Beschreibung des Sachverhalts verweist nur darauf. Ob die Oberfläche sie als korrelierten Container zeigt, ist an der Instanz noch zu prüfen.
Die Berichte bleiben einzeln erhalten; das Dossier ersetzt sie nicht. Kanten und CVSS-Wert entstehen ohne KI aus festen Regeln. Weder ein Grouping noch eine Notiz hat in OpenCTI ein Scorefeld; der Wert steht deshalb im Text und als Label, am Dossier als erste Zeile.
Die Prüfung ist dieselbe Idee wie bei den Periodenberichten, aber anders zugeschnitten: Dort sind Zahlen verboten, hier sind sie erlaubt, wenn sie im Quelltext stehen, weil Versionen für die Leser wichtig sind. Was nicht belegt ist, wird verworfen.
Die Prüfung ist heuristisch: Sie erkennt unbelegte Zahlen, Kennungen und Ausnutzung, nicht jede Falschaussage. Ob etwas von allen Berichten gesagt wird, kann sie nicht prüfen. Deshalb steht der Hinweis „nicht geprüft“ im Dossier und der Verweis auf die Berichte.
Das Bild zeigt den Inhalt der Notiz, den der Code der Plattform erzeugt: Überschrift mit Kennzeichnung, die drei Teile und die Angabe zur Grundlage. Der Text der drei Teile ist ein erfundenes Beispiel in der Form, die die Prüfung durchlässt. Er stammt nicht von einem Modell. Die Qualität mit dem vorgesehenen kleinen Modell ist an der Instanz noch nicht gemessen.
Der Bericht ist für Entscheider und Sicherheitsbeauftragte gedacht, die morgens einen kurzen Überblick brauchen. Er beginnt mit einer Einordnung, die sich allein auf die Sachverhalte stützt, also auf Schwachstellen, über die mehrere unabhängige Stellen berichten. Das Modell bekommt dafür nur diese Sachverhalte mit ihrem Dossier und nicht die Kennzahlen. Die Prüfung lässt in der Einschätzung nur CVE-Kennungen dieser Sachverhalte zu.
Der Überblick zeigt zu jeder relevanten Lücke die Berichte. Weil das Dossier aus den Volltexten entstanden ist, umgeht der Bericht die Grenze der gekürzten Feed-Beschreibungen, ohne bei jedem Bericht Seiten abzurufen. Fehlt das Dossier (Schalter aus oder noch nicht erzeugt), steht nur der Faktenteil.
Alle Zahlen, Tabellen und Listen entstehen weiter ohne KI aus den Daten.
Das Bild zeigt den Beginn eines Berichts: zuerst die kurze, gekennzeichnete Lageeinschätzung, danach der regelbasierte Satz „Auf einen Blick“ mit den Zahlen. Die Struktur kommt aus dem Code der Plattform, die Beispieldaten und der Text der Lageeinschätzung sind erfunden. Der Text stammt nicht von einem Modell.
Der Überblick zeigt eine relevante Lücke: das Dossier mit Umschreibung, übereinstimmend Dargestelltem und den Besonderheiten einzelner Berichte, dazu die Bestätigung der Ausnutzung und die verlinkten Berichte. Aufbau und Daten stammen aus dem Code der Plattform, der Text des Dossiers ist ein erfundenes Beispiel.
KI ist eine Erweiterung mit Human in the Loop. Die Überlegungen waren Halluzination und Datenabfluss: Das Modell läuft deshalb selbst betrieben, es bekommt nur die Fakten, und der Text wird mechanisch geprüft. Wenn das Modell etwas behauptet, was nicht in den Daten steht, wird der Abschnitt verworfen.
Der Betrieb hängt am Speicher des Servers; das kleine Standardmodell liefert allgemeine Texte, ein besseres Modell braucht einen größeren Server.
Dieser Teil erklärt, wofür Zammad in der Plattform vor allem dient: nicht als Helpdesk, sondern als Steuerung. Es folgen die Prinzipien und vier Abläufe: Beitritt, Kontolöschung, Meldungen der Mitglieder und Berichte der Lagezentrale.
Das gemeinsame Muster aller Abläufe. Eine Person entscheidet, indem sie den Zustand setzt. Die Middleware führt aus, aber erst nach eigener Prüfung der Voraussetzungen. Das Ergebnis, auch ein Fehler, steht im Ticket.
Das Ticket ist damit zugleich der Nachweis, wer was wann entschieden hat.
Wer sich registriert, sieht das Allgemeine Lagebild. Für das Lagebild Schleswig-Holstein stellt die Person einen Antrag; das Plattformmanagement prüft Organisation und Sektor. Mit der Genehmigung setzt die Middleware die Rolle und dokumentiert das im Ticket.
Das war zuvor ein Mausklick in der Keycloak-Oberfläche ohne Nachweis; jetzt ist es ein Vorgang mit Beleg.
Die Löschung betraf vier Systeme und war reine Handarbeit. Ein Fehler, also nur in einem System zu löschen, hat Folgen: Der nächste Login legt das Konto neu an.
Jetzt gibt es Vorschau, Vier-Augen-Prinzip und Protokoll. Das Keycloak-Konto bleibt bis zuletzt bestehen, damit ein Abbruch wiederholbar ist.
Die Meldung ist sensibel. Sie geht verschlüsselt ein, die Lagezentrale bekommt einen Hinweis ohne Inhalt, und die Aufbereitung geschieht im Ticket. Die Prüfung ist fail-closed: Im Zweifel wird nicht veröffentlicht.
Die Anonymisierungsprüfung ist heuristisch, sie sucht Name der Stelle und E-Mail-Adressen. Indirekte Identifizierung durch Details des Vorfalls prüft allein die Lagezentrale.
Hier ist der Stand zu benennen. Meldungen und kuratierte Inhalte laufen über Zammad. Die Freigabe von Entwürfen wie dem Lagebericht erfolgt derzeit in OpenCTI mit zwei Handgriffen: TLP setzen und das Gate entfernen. Wird das Gate vergessen, bleibt der Bericht für Mitglieder unsichtbar, also auf der sicheren Seite.
Der Versand per E-Mail an Verteiler ist im Konzept beschrieben und noch nicht vollständig umgesetzt; derzeit wird dafür nur eine interne Notiz angelegt. Ein automatischer Versand der Tages- und Wochenberichte ist zurückgestellt.
Screenshot aus einer Testinstanz mit Beispieldaten: ein Beitrittsantrag mit der Prüfhilfe der Middleware (Organisation, gewünschter Sektor, Verifizierungsstatus, Rollen) und dem Zustand. Zu zeigen: Die Entscheidung ist ein Zustandswechsel, das Protokoll steht im selben Ticket.
Screenshot aus einer Testinstanz mit Beispieldaten: ein Meldungsticket mit der Notiz „Beitrag“, dem TLP-Tag und den Zuständen. Der Text der Originalmeldung darf in der Darstellung nicht sichtbar sein.
Die Abwägung ist nüchtern: Das Ticketsystem ist vorhanden, kennt Rechte und Zustände und dokumentiert. Dafür wird ein Fachsystem Teil der Steuerungskette. Bei sicherheitskritischen Vorgängen wie der Kontolöschung wird ein zweites Augenpaar verlangt, bei der Freigabe von Meldungen im Pilot nicht; das ist vor einer Produktivsetzung neu zu bewerten (ADR 008).
Teil 8.
Die Vertraulichkeit hängt an den Markings der Objekte und den erlaubten Markings der Gruppen. Das Gate-Marking nutzt die OpenCTI-Regel, dass ein Objekt nur sichtbar ist, wenn alle seine Markings erlaubt sind: Was das Gate trägt, bleibt für Mitglieder unsichtbar.
Eine Besonderheit, die an der Instanz aufgefallen ist: Berichte ohne jedes Marking sind für alle Konten sichtbar. Deshalb tragen alle Berichte der Plattform ein Marking.
Der Mitgliederbereich liegt im Bereich der Infoseite, der für alle Registrierten offen ist. Deshalb prüft die Infoseite die Rolle zusätzlich. Auf der Instanz wurde das mit einem Konto mit Rolle, einem Konto ohne Rolle und ohne Anmeldung geprüft.
Der Pilot arbeitet mit öffentlichen Daten und Testkonten. Vor dem Wechsel auf echte Teilnehmerdaten sind die genannten Punkte zu erledigen. Das ist im Konzept als Voraussetzung festgehalten.
Teil 9.
Der Server wird nicht von außen angesteuert, er holt sich seinen Soll-Zustand aus dem Repository. Dadurch ist jeder Zustand nachvollziehbar und die Umgebung neu aufsetzbar. Im Betrieb zeigt sich der Preis: Änderungen brauchen den Umweg über einen Merge Request.
Die Werte sind Ziele des Piloten. Ein Restore-Test gehört zur Abnahme; die Sicherungs- und Backupziele auf dem Server sind noch offene Punkte beim Betreiber.
Tests sichern die Regeln ab, die Messungen sichern die Annahmen. Beides ersetzt keine Abnahme an der Instanz; sie ist je Phase vorgesehen und für Teile noch offen.
Der Stand wird offen benannt, damit der Vortrag nicht mehr verspricht als geprüft ist. Das Änderungsprotokoll im Repository führt bei jeder Änderung auf, was an der Instanz noch zu sehen ist.
Teil 10.
Alle Entscheidungen sind im Repository als ADR festgehalten, mit Kontext, Entscheidung und Folgen. Die Folgen stehen bewusst dabei, damit die Abwägung erkennbar bleibt.
Eine Einordnung ohne Bewertung der Wirkung: Der Ansatz macht Aussagen nachprüfbar, er macht sie nicht richtiger. Wo wir ableiten, kennzeichnen wir es. Der Aufwand verlagert sich in die Pflege von Konfiguration, Listen und Quellen und in den Betrieb mehrerer Systeme.
Die Liste ist keine Zusage, sondern der Stand der offenen Punkte im Repository. Der automatische Versand der Tages- und Wochenberichte ist zurückgestellt, bis mehr Ressourcen für das Sprachmodell vorhanden sind.
Fragen. Hinweise für die Diskussion: Das Konzept, die Entscheidungen und die Betriebsanleitungen liegen im Repository; die Folien werden mit dem Repository fortgeschrieben. Rückfragen zur Plattform an die Support-Adresse der Infoseite.