BSI Meldeprozess nach NIS-2: Mitarbeitende melden im Service Desk, der ISB kanalisiert und meldet

Ein Verdachtsfall landet in vielen Organisationen zuerst im Postfach. Eine Nachricht an „IT“, eine Weiterleitung an „Security“, später ein CC an die Leitung. Dazu ein Screenshot, ein vager Betreff, ein Zeitstempel aus dem Gedächtnis. Unter NIS-2 kann dieses Muster in die falsche Richtung führen. Tempo zählt, aber ebenso zählt Qualität: klare Fakten, saubere Einstufung, nachvollziehbare Schritte. Freie E-Mail-Threads liefern selten beides zugleich. Mal fehlt der betroffene Dienst, mal der genaue Zeitpunkt, mal eine belastbare Einschätzung zur Auswirkung.

Direkte Mails an das BSI durch einzelne Mitarbeitende können das Problem verschärfen. Zwei Risiken rücken nach vorn. Erstens: Unklarheit. Ein Verdacht wirkt dramatisch, obwohl nur ein Fehlalarm vorliegt; ein echtes Signal wirkt harmlos, obwohl ein Angreifer bereits weiterzieht. Zweitens: Kontrollverlust. Wenn jeder Kanal nach außen offensteht, entstehen parallele Meldestränge, doppelte Meldungen oder widersprüchliche Nachlieferungen. Für Organisationen mit BSI-Registrierung zählt ein zentraler, belastbarer Meldeprozess, inklusive interner Prüfung und dokumentierter Freigabe.

Honicon setzt deshalb auf ein klares Prinzip: Jeder meldet intern, eine qualifizierte Stelle steuert die externe Kommunikation. Jira Service Management bildet das Portal und den Workflow ab, Confluence liefert Playbooks und Textbausteine, Assets verknüpft betroffene Systeme, Services und Verantwortlichkeiten. So entsteht Struktur, ohne den internen Einstieg zu erschweren.

Ein Kunde mit BSI-Registrierung und ein klarer Auftrag

Die folgende Ausgangslage stand bei einem Honicon-Kunden im Mittelpunkt. Das Unternehmen ist als NIS 2 betroffen beim BSI registriert und muss den Meldeprozess im Sinne der NIS-2-Umsetzung operationalisieren. Im Alltag zählt dabei ein Spagat: Verdachtsfälle sollen früh sichtbar sein, externe Meldungen dürfen erst nach fachlicher Prüfung rausgehen. Sonst drohen Fehlmeldungen, unnötige Eskalationen und ein unklarer Nachweisstand.

Ein typischer Morgen aus dem Kundenalltag: Eine Kollegin aus dem Fachbereich erhält eine Mail mit angeblichem „Rechnungsupdate“. Der Link führt auf eine Login-Seite, die dem SSO ähnlich wirkt. Statt Verteilerlisten zu bedienen, eröffnet sie im Portal einen Vorgang „Verdacht auf Phishing“. Das Formular fragt nur das Nötigste ab: Absender, Betreff, Link, Zeitpunkt, Screenshot. Nach dem Absenden erscheint sofort ein Status „eingegangen“. Parallel startet eine automatische Zuweisung an die Sicherheitsrolle.

Im Workshop kristallisierte sich ein Ablauf heraus: Meldung erfassen, triagieren, bewerten, entscheiden, erst danach extern kommunizieren. Mitarbeitende melden Verdachtsfälle über ein Service-Portal, nicht per freier Mail. Der Service Desk wirkt als vorgeschaltete Sammelstelle. Ein Ticket ersetzt den Mailverlauf. Der Melder sieht Status und Rückfragen an einer Stelle. Zuständigkeiten sind definiert im Workflow: Erstannahme, technische Klärung, Security-Bewertung, Freigabe.

Confluence liefert den Kontext: Hinweise zur Beweissicherung, Umgang mit Links, Checkliste für Header-Infos. Assets ergänzt den Bezug: betroffene Anwendung, betroffener Account, kritischer Service. So entsteht aus einer Beobachtung eine verwertbare Meldung, ohne Expertenwissen beim Melder vorauszusetzen.

ISB als Filter – Prüfung, Zusammenführung, Entscheidung

Im Zentrum steht eine qualifizierte Instanz: der ISB, je nach Aufbau ergänzt durch CSIRT-Funktionen. Alle Portal-Meldungen laufen zunächst intern auf. Der ISB prüft Plausibilität, priorisiert nach Schweregrad und führt zusammen, was zusammengehört. Drei Meldungen aus verschiedenen Teams ergeben oft ein gemeinsames Bild, das in einzelnen Mails unsichtbar bleibt.

Der ISB steuert die Eskalationslogik entlang belastbarer Kriterien: betroffene Dienste, Reichweite, Dauer, Hinweise auf Datenabfluss, Indikatoren für böswillige Handlung, bereits eingeleitete Maßnahmen. Rückfragen gehen gezielt an die richtige Stelle. Daraus entsteht ein Lageüberblick, der sowohl Technik als auch Leitung trägt.

Im Kundenprojekt führte diese Bündelung zu einem schnellen Treffer. Neben dem Phishing-Ticket traf ein zweites Ticket ein: „ungewöhnliche MFA-Pushes“. Kurz danach folgte ein drittes Ticket aus dem Betrieb: „neuer OAuth-Grant“. Der ISB legte die Vorgänge nebeneinander, zog Logs hinzu, ließ Accounts sperren und Tokens rotieren. Erst danach startete die externe Kommunikation. Der ISB formulierte eine konsolidierte Meldung mit Zeitlinie, betroffenen Diensten und getroffenen Eindämmungsmaßnahmen, holte eine interne Freigabe ein und versendete die Meldung über den vorgesehenen BSI-Kanal. Auch die GF bleibt informiert.

Damit entsteht ein Schutzmechanismus: breite interne Sensorik, zentraler fachlicher Filter, einheitliche Außenkommunikation. Einzelpersonen liefern Signale, der ISB liefert Einordnung und Qualität.

Dynamische Abfrage – nur jene Informationen, die gerade zählen

Ein möglicher Fehler in Sicherheitsformularen liegt in zu vielen Feldern, zu früh, für jeden Fall. Das senkt Datenqualität und Akzeptanz. Honicon setzt im Portal auf dynamische Abfrage. Basisinformationen stehen am Anfang: Beobachtung, Zeitpunkt, betroffene Systeme oder Services, grobe Kategorie des Vorfalls. Danach verzweigt die Erfassung.

Ein Beispiel: Die Frage nach „erheblicher IT-Störung“ erscheint nicht pauschal. Liegt ein Ausfall oder eine erhebliche Beeinträchtigung vor, dann rückt Verfügbarkeit in den Vordergrund: betroffene Nutzergruppen, Dauer, Wiederanlauf, Workarounds. Fehlt ein Ausfall und fehlt eine erhebliche Beeinträchtigung, dann erscheint die gezielte Frage, ob trotz stabiler Verfügbarkeit eine erhebliche Störung im sicherheitsrelevanten Sinn vorliegt, etwa durch unbefugten Zugriff oder aktive Ausnutzung.

Diese Logik passt zu den Erwartungen an Meldungen: klare Beschreibung, belastbare Zeitangaben, betroffene Dienste, Auswirkungen, erste Maßnahmen, Kontaktpunkt, Nachlieferfähigkeit. Der Service Desk sammelt diese Informationen strukturiert. Confluence liefert Definitionen und Textbausteine, die Konsistenz schaffen. Jira bildet den Auditpfad ab: Ticket-Zeitlinie, Entscheidungen, Freigaben, Versandnachweis, Nachlieferungen. Das entlastet Prüfungstermine und schafft Ruhe im Ernstfall.

Am Ende steht ein Prozess, der zwei Ziele gleichzeitig trifft. Frühe interne Meldung durch alle erhöht die Chance auf schnelle Erkennung. Fachliche Prüfung durch den ISB schützt vor Fehlmeldungen und sorgt für konsistente Kommunikation. Der Service Desk übernimmt die Rolle eines Filters: strukturierte Erfassung, gezielte Nachfragen, zentrale Bewertung, dann eine qualifizierte Meldung an das BSI.