¶ Patch- und Schwachstellennachweise
Beispieldokument: Diese Seite beschreibt eine Nachweisstruktur für die fiktive „Muster GmbH“. Die Musterwerte bestätigen weder einen vollständigen Assetbestand noch eine funktionierende Schwachstellenerkennung, fristgerechte Patchverteilung, geschlossene Sicherheitslücken oder wirksame kompensierende Maßnahmen.
Nachweisgrundsatz: Ein geschlossenes Ticket, ein gemeldeter Patchstand oder ein erfolgreich beendeter Verteilauftrag belegt noch keine wirksame Behebung. Betroffenheit, vollständiger Rollout, installierte Version, Konfiguration und verbleibende Exposition müssen technisch verifiziert werden.
Schutzregel: Schwachstellenberichte, Exploitdetails, Scannerergebnisse, Systemlisten, Konfigurationen, Zugangspfade und Ausnahmen sind regelmäßig vertraulich oder streng vertraulich. Diese Seite führt Metadaten und kontrollierte Referenzen; technische Originale verbleiben in einer geschützten Ablage.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-NW-07-06 |
| Dokumentenart | Nachweisverfahren für Patch- und Schwachstellenmanagement |
| Wiki.js-Pfad | /ISMS/07-Nachweise/Patch-und-Schwachstellennachweise |
| Verantwortlich | IT-Leitung und Informationssicherheit |
| Fachlich geprüft durch | System-/Service Owner, OT-/Produktionsverantwortung, Entwicklung, Cloud-/Lieferantenmanagement, Datenschutz, ISMS und Audit/QM |
| Freigabe durch | Geschäftsführung beziehungsweise festgelegte befugte Risiko- und Betriebsverantwortung |
| Status | Entwurf – keine realen Befunde, Patchstände oder Wirksamkeitsnachweise referenziert |
| Version | 0.1 |
| Stand | 08.08.2026 |
| Gültig ab | Nach fachlicher Prüfung und Freigabe |
| Nächste Prüfung | Nach freigegebenem Prüfzyklus sowie anlassbezogen bei kritischen Befunden, Zero-Day-Lagen, wesentlichen Änderungen oder Vorfällen |
| Schutzklasse | Vertraulich; technische Detailnachweise regelmäßig streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Kapitel 6, 7.5, 8.1, 9 und 10 sowie Annex A 5.7, 5.9, 8.8, 8.9, 8.19 und 8.32 |
| TISAX-Bezug | Maßgebliche ISA-Fassung und zugeordnete Kontrollfragen zu Assetbestand, Schwachstellen, Patchmanagement, Betrieb, Änderungen und Nachweisen |
| Weitere Bezüge | NIS2-Umsetzung, Datenschutz, Verträge, Kundenanforderungen, sichere Entwicklung und Lieferkette, soweit anwendbar |
Nachweiskette von Bestand und Befund über Behandlung und Umsetzung bis zur technischen Verifikation und Nachverfolgung. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Dieses Verfahren legt fest, wie objektive Nachweise zu technischen Schwachstellen und Patches identifiziert, geschützt, miteinander verknüpft, geprüft und bewertet werden. Es soll sicherstellen, dass:
- die betroffene Grundgesamtheit aus Assets, Produkten, Versionen und Services bekannt ist,
- Funde aus unterschiedlichen Quellen eindeutig normalisiert und nachvollziehbar bewertet werden,
- Priorität und Frist nicht allein aus einem CVSS-Wert abgeleitet werden,
- Behandlung, Test, Freigabe, Rollout und Rückfallverfahren belegt sind,
- nicht erreichte, fehlgeschlagene und ausgeschlossene Assets sichtbar bleiben,
- Behebung, Mitigation, Nichtbetroffenheit und False Positive unterschiedlich nachgewiesen werden,
- Ausnahmen befristet, risikobasiert und mit kompensierenden Maßnahmen geführt werden,
- ein technischer Retest oder ein gleichwertiger Kontrollnachweis den Abschluss stützt.
Die Seite ersetzt weder Scanner, Patchwerkzeug, Asset-Inventar, Change-Management, Risikoregister noch die geschützten Originalnachweise.
¶ 2. Geltungsbereich
Der reale Nachweis-Scope kann umfassen:
- Server, Clients, mobile Geräte, Netzwerk- und Sicherheitskomponenten,
- Betriebssysteme, Firmware, Appliances und eingebettete Systeme,
- OT-, Produktions-, Labor-, Gebäude- und Legacy-Systeme,
- Anwendungen, Bibliotheken, Container, Images, Repositories und CI/CD-Werkzeuge,
- Cloud-IaaS, PaaS, SaaS, Hosting und Managed Services,
- Internetpräsenzen, APIs, externe Schnittstellen und Fernzugänge,
- Identitäts-, Verzeichnis-, Kryptografie-, Logging- und Monitoringdienste,
- Lieferantenprodukte, kundenseitig betriebene Komponenten und gemeinsam verantwortete Dienste.
Ausgeschlossene oder technisch nicht prüfbare Bestandteile werden mit Grund, Risiko, Owner, Frist und Ersatzkontrolle dokumentiert.
¶ 3. Aussageebenen trennen
| Aussage | Mindestnachweis | Was noch nicht belegt ist |
|---|---|---|
| Produkt oder Asset inventarisiert | eindeutige Asset-/Produkt-ID, Owner, Version und Scope | aktuelle Scanabdeckung |
| Schwachstelle gemeldet | Quelle, Kennung, Zeitpunkt und Rohbefund | reale Betroffenheit |
| Betroffenheit bestätigt | Version, Konfiguration, Komponente und nachvollziehbare Prüfung | erfolgreiche Behandlung |
| Patch verfügbar | vertrauenswürdige Quelle, Version, Integrität und Freigabeinformationen | Eignung für den eigenen Betrieb |
| Patch getestet | definierter Scope, Kriterien, Ergebnis und Abweichungen | vollständiger produktiver Rollout |
| Patch verteilt | Zielgruppe, Verteilauftrag und Laufstatus | Installation auf allen Assets |
| Installation bestätigt | Ist-Version oder gleichwertiger technischer Beleg je Asset | Beseitigung jeder Exposition |
| Behebung verifiziert | Kontrollscan, Retest oder gleichwertige reproduzierbare Prüfung | dauerhafte Wirksamkeit außerhalb des Prüfzeitraums |
| Mitigation wirksam | implementierte Ersatzkontrolle und Test gegen definiertes Szenario | vollständige Beseitigung der Schwachstelle |
| Ausnahme akzeptiert | befristete, befugte Risikoentscheidung und Kontrollen | Wegfall der Behandlungspflicht nach Ablauf |
¶ 4. Nachweiskette und eindeutige Referenzen
Jeder Befund wird über kontrollierte IDs verbunden:
Asset-/Produkt-ID → Befund-ID → externe Kennung → Risiko-/Prioritätsentscheidung → Change-/Patch-ID → Rollout → Verifikation → Abschluss oder Ausnahme
| Referenz | Zweck |
|---|---|
| Asset-/Produkt-ID | betroffene Grundgesamtheit, Owner und Kritikalität |
| Befund-ID | interne, dauerhaft eindeutige Nachverfolgung |
| externe Kennung | zum Beispiel CVE, Herstellerkennung, CERT-Hinweis oder Scanner-Plugin |
| Risiko-/Maßnahmen-ID | Bewertung, Behandlung, Restrisiko und Ressourcenentscheidung |
| Change-/Release-ID | Test, Freigabe, Zeitfenster, Rollback und Umsetzung |
| Ausnahme-ID | Befugnis, Begründung, Ersatzkontrolle, Ablauf und Review |
| Nachweis-ID | kontrollierte Referenz im Nachweisregister |
Mehrere Scannerfunde dürfen zu einem Befund zusammengeführt werden, wenn Herkunft, betroffene Assets und Originalreferenzen erhalten bleiben. Ein Befund darf nicht durch Dublettenbereinigung verschwinden.
¶ 5. Quellen und Eingangsnachweise
| Quelle | Erwarteter Nachweis | Qualitätsprüfung |
|---|---|---|
| Hersteller-/Providerhinweis | Originalmeldung, Version, Datum und Produktbezug | Authentizität, Aktualität und betroffene Versionen |
| CVE/NVD/CERT | Kennung, Beschreibung, Schweregrad und Referenzen | nicht mit interner Risikobewertung gleichsetzen |
| CISA KEV | Katalogstand und Nachweis aktiver Ausnutzung | als Priorisierungseingang verwenden; fremde Fristen nicht ungeprüft übernehmen |
| Schwachstellenscanner | Scan-ID, Zeitpunkt, Profil, Scope, Credentials und Fehler | Abdeckung, Aktualität, Ausschlüsse und False Positives |
| Penetrationstest/Audit | Auftrag, Scope, Methodik, Befund und Vertraulichkeit | Aussagegrenzen und Nachtest klären |
| Bedrohungsinformationen | Quelle, Relevanz, Zeitpunkt und Vertrauensniveau | Bezug zu eigenen Assets und Angriffswegen |
| Entwicklung/Lieferkette | SCA-, SBOM-, Container- oder Codebefund | Build, Version, Abhängigkeit und Erreichbarkeit |
| Vorfall/Monitoring | Indikator, Zeitlinie und betroffene Systeme | Incident Response und Beweissicherung berücksichtigen |
Der CISA-KEV-Katalog ist ein wichtiger Eingang zur Priorisierung aktiv ausgenutzter Schwachstellen. Für US-Bundesbehörden geltende Behebungsfristen werden nicht als allgemeine ISO-, TISAX- oder Unternehmensfrist dargestellt.
¶ 6. Grundgesamtheit und Scanabdeckung
Vor einer Abdeckungs- oder Fristaussage werden mindestens bestätigt:
- vollständige Asset- und Produktliste mit eindeutigen IDs,
- installierte Versionen, Komponenten und Abhängigkeiten,
- externe Erreichbarkeit, Netzzone, Privilegien und Geschäftsbezug,
- Kritikalität, Schutzbedarf und zuständiger Owner,
- vorgesehene Scan- oder Prüfart je Assetklasse,
- tatsächlich erreichte, authentisierte und vollständig geprüfte Assets,
- nicht erreichbare, ausgeschlossene, ausgeschaltete oder neu hinzugekommene Assets,
- Scannerprofil, Signaturstand, Prüfzeitpunkt und technische Fehler.
Die Scanquote verwendet eine bestätigte Grundgesamtheit. „Keine Funde“ ist bei unbekannter oder unvollständiger Abdeckung keine positive Sicherheitsaussage.
¶ 7. Befundaufnahme und Normalisierung
| Feld | Mindestinhalt |
|---|---|
| Befund-ID | dauerhaft eindeutige interne Referenz |
| Quelle und Eingang | System, Meldung, Import, Datum und verantwortliche Rolle |
| externe Kennungen | CVE, Herstellerhinweis, Scanner-Plugin oder andere Referenz |
| Asset-/Produktbezug | IDs, Version, Standort, Service und Owner |
| technische Beschreibung | betroffene Komponente, Bedingung und mögliche Auswirkung |
| Rohbewertung | CVSS-Version und Vektor, Herstellerbewertung und Exploitinformationen |
| interner Kontext | Exposition, Privilegien, Angriffsweg, Kritikalität und Kontrollen |
| Status und Zeitlinie | Eingang, Triage, Entscheidung, Umsetzung, Retest und Abschluss |
| Originalreferenzen | kontrollierte Fund-, Log-, Scan- und Ticketnachweise |
Änderungen an Schweregrad, Betroffenheit oder Status werden mit Datum, Rolle und Begründung historisiert.
¶ 8. Betroffenheit bestätigen
Die Betroffenheitsprüfung dokumentiert reproduzierbar:
- installierte Produkt-, Komponenten-, Build- und Firmwareversion,
- relevante Konfiguration, Funktion oder aktiviertes Modul,
- Erreichbarkeit und erforderliche Berechtigungen,
- vorhandene Sicherheits- und Segmentierungskontrollen,
- Herstellerlogik, Erkennungsmethode oder manuellen Prüfschritt,
- Ergebnis je Asset beziehungsweise klar definierter Assetgruppe,
- Unsicherheiten, fehlende Informationen und weitere Prüfbedarfe.
„Nicht betroffen“ benötigt denselben Qualitätsanspruch wie „betroffen“. Eine bloße Aussage des System-Owners ohne technischen oder herstellerbezogenen Beleg genügt nicht.
¶ 9. Risikobasierte Priorisierung
Die interne Priorität berücksichtigt mindestens:
- bestätigte oder plausible aktive Ausnutzung,
- KEV-, Exploit- und Bedrohungsinformationen,
- externe und interne Exposition sowie erreichbare Angriffswege,
- benötigte Privilegien und Benutzerinteraktion,
- Kritikalität des Services und Schutzbedarf der Information,
- mögliche Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit,
- Umfang betroffener Assets und gemeinsame Abhängigkeiten,
- vorhandene, getestete kompensierende Kontrollen,
- Herstellerunterstützung, Patchverfügbarkeit und Betriebsrisiko,
- rechtliche, vertragliche, Kunden- und Assessmentanforderungen.
CVSS unterstützt die technische Einordnung, ersetzt aber weder Betroffenheitsprüfung noch interne Risiko- und Behandlungsentscheidung. Organisationsspezifische Prioritäten und Fristen werden freigegeben und nicht als pauschale Normvorgabe ausgegeben.
¶ 10. Behandlungsentscheidung
| Option | Erforderlicher Nachweis |
|---|---|
| Patch/Update | Quelle, Integrität, Version, Test, Freigabe, Rollout und Verifikation |
| Konfigurationsänderung | Sollzustand, Change, Test, Rollout und Konfigurationsprüfung |
| Deaktivierung/Entfernung | betroffene Funktion, technische Umsetzung und Funktions-/Restprüfung |
| Segmentierung/Zugriffsbeschränkung | Regel, Scope, Freigabe und technischer Wirksamkeitstest |
| Überwachung/Detection | konkrete Logquelle, Erkennungsregel, Testalarm und Reaktionsweg |
| Produktersatz | Migrationsplan, Übergangsrisiko, Außerbetriebnahme und Verifikation |
| Risikoakzeptanz | befristete befugte Entscheidung, Begründung, Kontrollen und Review |
Die Entscheidung nennt Owner, Zieltermin, erwarteten Nachweis, Eskalation und Verifikationskriterium.
¶ 11. Patchquelle, Integrität und Freigabe
Vor der Verwendung werden dokumentiert:
- vertrauenswürdige Bezugsquelle und Hersteller-/Providerreferenz,
- Produkt, Zielversion, Build und unterstützte Ausgangsversionen,
- Signatur, Hash oder anderes geeignetes Integritätsmerkmal,
- Abhängigkeiten, Voraussetzungen und bekannte Nebenwirkungen,
- ersetzte, kumulative oder superseded Updates,
- Lizenz-, Support- und Kompatibilitätsinformationen,
- verantwortliche Freigabe und vorgesehener Rolloutkanal.
Nicht verifizierbare oder aus inoffiziellen Quellen bezogene Pakete werden nicht ungeprüft eingesetzt.
¶ 12. Test- und Change-Nachweis
| Feld | Mindestinhalt |
|---|---|
| Change-/Patch-ID | eindeutige Verbindung zum Befund und Zielsystem |
| Test-Scope | repräsentative Systeme, Versionen, Abhängigkeiten und ausgeschlossene Varianten |
| Ausgangszustand | Version, Konfiguration, Datenstand und Sicherheitszustand |
| Testkriterien | Installation, Funktion, Schnittstellen, Performance, Logging und Sicherheit |
| Ergebnis | Soll-Ist-Vergleich, Protokolle, Fehler und Einschränkungen |
| Freigabe | befugte Rolle, Zeitpunkt, Bedingungen und Risikobeurteilung |
| Rollback | Auslösekriterien, Verfahren, benötigte Sicherung und Verantwortlichkeit |
| Zeitfenster | Beginn, Überwachung, Abbruch und Eskalation |
Ein Test auf nur einer Plattform wird nicht ohne Begründung auf abweichende Betriebssysteme, Firmwarestände, Mandanten oder OT-Varianten übertragen.
¶ 13. Notfallpatching und Zero-Day-Lagen
Beschleunigte Verfahren erhalten weiterhin nachvollziehbare Nachweise. Festgehalten werden:
- Lagebild und Anlass der Dringlichkeit,
- betroffener Scope und Sofortpriorität,
- verkürzte, aber definierte Test- und Freigabeschritte,
- Schutzmaßnahmen bis zur vollständigen Behandlung,
- Rolloutreihenfolge, Monitoring und Rückfalloption,
- nicht erreichte Assets und Eskalationen,
- nachgelagerte vollständige Dokumentation und Verifikation.
Dringlichkeit rechtfertigt eine risikobasierte Verfahrensanpassung, nicht das Weglassen von Verantwortlichkeit und Nachkontrolle.
¶ 14. Rollout-Nachweis
Der Rolloutnachweis enthält mindestens:
- freigegebene Zielmenge und tatsächliche Zielmenge,
- Start, Ende, Werkzeug, Paket und Version,
- erfolgreich verarbeitete, fehlgeschlagene, ausstehende und nicht erreichbare Assets,
- Geräte außerhalb des Netzes, ausgeschaltete Systeme und Ausnahmen,
- Neustart-, Wartungs- oder Produktionsanforderungen,
- automatisierte und manuelle Nacharbeiten,
- Störungen, Rollbacks und Serviceauswirkungen,
- verantwortliche Überwachung und Eskalation.
Die Erfolgsanzeige des Verteilwerkzeugs wird durch eine unabhängige Ist-Prüfung ergänzt, soweit dies technisch und risikobasiert erforderlich ist.
¶ 15. Technische Verifikation
Eine Behebung wird erst nach geeigneter Prüfung als verifiziert geführt. Abhängig vom Befund umfasst sie:
- tatsächlich installierte Produkt-, Build- oder Firmwareversion,
- erwartete Konfiguration oder deaktivierte verwundbare Funktion,
- erneuten authentisierten Scan beziehungsweise gezielten Retest,
- Kontrolle, dass die ursprüngliche Angriffsvoraussetzung nicht mehr besteht,
- Funktions- und Schnittstellenprüfung,
- Prüfung von Logging, Monitoring und Schutzwerkzeugen,
- Bewertung weiterhin offener, nicht erreichter oder neu hinzugekommener Assets,
- dokumentierte Prüfmethode, Zeitpunkt, Rolle und Ergebnis.
Ein Scanner kann veraltete Signaturen, Credential-Probleme oder False Positives besitzen. Ein Kontrollscan wird deshalb zusammen mit Scope, Profil, Signaturstand und Fehlern bewertet.
¶ 16. False Positive, Nichtbetroffenheit und Risikominderung
| Status | Zulässige Begründung | Prüfnachweis |
|---|---|---|
| False Positive | Erkennung trifft technisch nicht zu | reproduzierbare Prüfung, Scanner-/Herstellerbezug und Reviewer |
| Nicht betroffen | Version, Komponente oder Konfiguration liegt nicht vor | Inventar-, Versions- und Konfigurationsnachweis |
| Nicht erreichbar | Asset konnte nicht geprüft werden | Fehlernachweis, Owner, Nachholtermin und Eskalation |
| Mitigiert | Schwachstelle besteht, Angriffsweg wird kontrolliert begrenzt | implementierte Kontrolle und Wirksamkeitstest |
| Behoben | Schwachstelle wurde beseitigt | Ist-Zustand und technischer Retest |
False-Positive- und Nichtbetroffenheitsentscheidungen erhalten Reviewtermin, falls Quelle, Produktstand oder Prüfmethodik sich ändern können.
¶ 17. Ausnahmen und Risikoakzeptanzen
Ausnahmen werden mit der Seite Ausnahmen und Risikoakzeptanzen verbunden und enthalten:
- Befund-, Asset-, Risiko- und Ausnahme-ID,
- technische und betriebliche Begründung,
- bestätigte Exposition und mögliche Auswirkungen,
- kompensierende Maßnahmen und deren Test,
- befugte entscheidende Rolle,
- Start, Enddatum und Reviewtermin,
- Ersatz-, Migrations- oder Behandlungsplan,
- Überwachung, Eskalation und automatischen Wiederöffnungspunkt.
Eine abgelaufene Ausnahme setzt den Befund nicht automatisch auf geschlossen.
¶ 18. OT, Legacy und End-of-Life
Für nicht oder nur eingeschränkt patchbare Systeme werden zusätzlich dokumentiert:
- Herstellerstatus, Supportende und verfügbare sichere Zielversion,
- Produktions-, Sicherheits- und Verfügbarkeitsrisiken eines Eingriffs,
- Wartungsfenster und erforderliche Anlagenfreigaben,
- Segmentierung, Whitelisting, Zugriffsbegrenzung und Monitoring,
- Ersatzteil-, Backup-, Restore- und Wiederanlaufvorsorge,
- Migrations- oder Ablöseplan mit Owner und Termin,
- regelmäßige Neubewertung der Bedrohungs- und Expositionslage.
„Nicht patchbar“ ist keine dauerhafte Abschlusskategorie, sondern ein dokumentierter Risikozustand.
¶ 19. Cloud, SaaS und Lieferanten
Bei extern betriebenen Diensten werden mindestens referenziert:
- vertragliche Rollen und Patch-/Schwachstellenpflichten,
- betroffene Services, Mandanten, Regionen und Versionen,
- Providerhinweis, Statusseite, Ticket oder Attest,
- eigene Konfigurations-, Identitäts- und Schnittstellenverantwortung,
- Kundeninformation, Eskalation und vertragliche Fristen,
- unabhängige Plausibilisierung oder technische Eigenprüfung, soweit möglich,
- Restrisiko, Exit- oder Ersatzentscheidung bei unzureichender Behandlung.
Eine allgemeine Zertifizierung des Providers ersetzt keinen konkreten Befund- und Servicebezug.
¶ 20. Sichere Entwicklung und Abhängigkeiten
Für Anwendungen und Softwarelieferketten können ergänzend erforderlich sein:
- Repository, Branch, Build, Release und deployte Version,
- betroffene direkte oder transitive Abhängigkeit,
- SCA-, SBOM-, Container- und Code-Scanreferenzen,
- Erreichbarkeit beziehungsweise tatsächliche Nutzung der verwundbaren Funktion,
- Fix-Version, Rebuild, Signierung und Freigabe,
- Deployment in alle betroffenen Umgebungen,
- Regressionstest und erneuter Scan der ausgelieferten Komponente.
Ein korrigierter Quellcode belegt noch nicht, dass die sichere Version gebaut, ausgeliefert und produktiv eingesetzt wurde.
¶ 21. Statusmodell
| Status | Eintrittskriterium | Folge |
|---|---|---|
| Neu | Befund übernommen, noch nicht triagiert | zeitnahe Zuordnung und Prüfung |
| In Prüfung | Assetbezug und Betroffenheit werden validiert | Unsicherheit sichtbar halten |
| Bestätigt | Betroffenheit und interner Kontext nachvollziehbar | Behandlung priorisieren |
| In Behandlung | freigegebene Maßnahme mit Owner und Termin | Fortschritt und Fehler überwachen |
| Umgesetzt | vorgesehene technische Änderung ausgeführt | noch keine Abschlussaussage |
| Verifiziert behoben | Ist-Zustand und Retest bestätigen Beseitigung | kontrollierter Abschluss möglich |
| Wirksam mitigiert | Ersatzkontrolle implementiert und getestet | Schwachstelle bleibt sichtbar; Review erforderlich |
| Ausnahme aktiv | befristete Risikoentscheidung gültig | Ablauf und Kontrollen überwachen |
| Überfällig | freigegebene Frist überschritten | Eskalation und Neubewertung |
| Wieder geöffnet | Retest, neue Exposition oder abgelaufene Ausnahme | erneute Behandlung |
„Geschlossen“ wird nur als administrativer Sammelstatus verwendet, wenn der fachliche Abschlussgrund weiterhin eindeutig erkennbar bleibt.
¶ 22. Nachweispaket
| Nachweis | Mindestinhalt | Schutz |
|---|---|---|
| Bestands-/Abdeckungsnachweis | Grundgesamtheit, Versionen, Scope, erreichte und fehlende Assets | Streng vertraulich |
| Befundoriginal | Quelle, Kennung, Rohbefund, Zeitstempel und Integrität | Streng vertraulich |
| Betroffenheitsprüfung | Version, Konfiguration, Ergebnis, Methode und Reviewer | Streng vertraulich |
| Prioritätsentscheidung | Bedrohung, Exposition, Auswirkung, Kontrolle, Owner und Frist | Vertraulich |
| Test- und Freigabenachweis | Testscope, Kriterien, Ergebnis, Change, Rollback und Freigabe | Vertraulich |
| Rolloutnachweis | Zielmenge, Ergebnisse, Fehler, Restbestand und Eskalation | Streng vertraulich |
| Verifikationsnachweis | Ist-Version, Konfiguration, Kontrollscan/Retest und Ergebnis | Streng vertraulich |
| Ausnahme-/Mitigationsnachweis | Entscheidung, Kontrollen, Test, Ablauf und Review | Vertraulich |
| Abschlussdatensatz | Zeitlinie, Abschlussgrund, Scope-Grenze und Nachweisreferenzen | Vertraulich |
Kontrollierte Metadaten werden im Nachweisregister geführt. Exploitdetails, Zugangsdaten und technische Originale werden dort nicht eingebettet.
¶ 23. Musterregister ohne positive Nachweisbehauptung
| Befund-ID | Asset-/Produktklasse | Quelle | Priorität | Behandlung | Verifikation | Ausnahme | Status |
|---|---|---|---|---|---|---|---|
| VUL-2026-001 | extern erreichbarer Dienst | Nicht referenziert | Nicht bewertet | Nicht entschieden | Nicht vorhanden | Keine | Benötigt |
| VUL-2026-002 | Arbeitsplatzsysteme | Nicht referenziert | Nicht bewertet | Nicht entschieden | Nicht vorhanden | Keine | Benötigt |
| VUL-2026-003 | Netzwerkkomponente | Nicht referenziert | Nicht bewertet | Nicht entschieden | Nicht vorhanden | Keine | Benötigt |
| VUL-2026-004 | OT-/Legacy-System | Nicht referenziert | Nicht bewertet | Nicht entschieden | Nicht vorhanden | Nicht bewertet | Benötigt |
| VUL-2026-005 | Anwendungsabhängigkeit | Nicht referenziert | Nicht bewertet | Nicht entschieden | Nicht vorhanden | Keine | Benötigt |
Die Einträge sind offene Musterbedarfe und keine realen Schwachstellenfunde.
¶ 24. Kennzahlen und Aussagegrenzen
| Kennzahl | Berechnung | Aussagegrenze |
|---|---|---|
| Scanabdeckung | geeignet geprüfte / vorgesehene Assets | Grundgesamtheit, Scanart und Credential-Qualität angeben |
| bestätigte Befunde | bestätigte / bewertbare Funde | Dubletten und Assetanzahl getrennt betrachten |
| fristgerecht verifiziert | innerhalb freigegebener Frist verifiziert / fällige Befunde | Umsetzung ohne Retest nicht mitzählen |
| mittlere Behandlungszeit | Zeit von bestätigtem Eingang bis Verifikation | Priorität und Ausreißer ausweisen |
| Restbestand | offene betroffene Assets je Befund | nicht erreichbare Assets einschließen |
| aktive Ausnahmen | gültige Ausnahmen nach Priorität und Alter | Ablauf und getestete Kontrollen sichtbar machen |
| wieder geöffnete Befunde | Reopenings / abgeschlossene Befunde | Ursache und Prüfqualität analysieren |
| EOL-Anteil | nicht unterstützte / relevante Assets | nur mit bestätigtem Produktbestand belastbar |
Eine hohe Ticketabschlussquote ist keine Behebungs- oder Wirksamkeitsquote.
¶ 25. Rollen und Funktionstrennung
| Rolle | Aufgabe |
|---|---|
| IT-Leitung | Verfahren, Ressourcen, Prioritäten und Eskalationen verantworten |
| Informationssicherheit | Quellen, Triage, Risiko- und Bedrohungskontext koordinieren |
| Asset-/Service Owner | Betroffenheit, Betriebswirkung, Behandlung und fachliche Abnahme verantworten |
| Patch-/Systemadministration | Paketprüfung, Test, Rollout und technische Nachweise erstellen |
| Entwicklung/DevSecOps | Abhängigkeiten, Build, Release, Deployment und Regressionstest steuern |
| OT-/Produktionsverantwortung | Anlagenrisiko, Wartungsfenster, Ersatzkontrollen und Freigaben koordinieren |
| Lieferantenmanagement | Provider- und Herstellerpflichten, Tickets, Nachweise und Eskalation steuern |
| Risiko-Owner | Restrisiko und befristete Ausnahme im eigenen Befugnisrahmen entscheiden |
| ISMS/Audit | Vollständigkeit, Aussagegrenzen, Stichproben und Wirksamkeit unabhängig prüfen |
Bei kritischen Befunden werden Durchführung, Freigabe und unabhängige Verifikation angemessen getrennt.
¶ 26. Audit- und Assessmentprüfung
Vor Bereitstellung wird geprüft:
- Ist die Grundgesamtheit vollständig und passt sie zum ISMS-/Assessment-Scope?
- Sind Scanabdeckung, Credentials, Signaturstand und technische Fehler offengelegt?
- Ist die Betroffenheitsprüfung reproduzierbar und je Asset oder Gruppe nachvollziehbar?
- Ergänzt die interne Priorität CVSS um Bedrohung, Exposition und Geschäftsfolgen?
- Sind Behandlung, Test, Freigabe, Rollout und Rückfall miteinander verbunden?
- Bleiben fehlgeschlagene, nicht erreichbare und ausgeschlossene Assets sichtbar?
- Belegt ein technischer Retest die Behebung oder Wirksamkeit der Mitigation?
- Sind Ausnahmen befristet, befugt entschieden und praktisch überwacht?
- Sind Cloud, OT, Entwicklung und Lieferanten entsprechend dem Scope einbezogen?
- Sind Originalnachweise geschützt und kontrolliert referenziert?
Ein Export aus Scanner oder Patchwerkzeug ohne Scope-, Entscheidungs- und Verifikationsbezug ist kein vollständiges Nachweispaket.
¶ 27. Aktueller Entwurfsstatus
| Prüffrage | Status |
|---|---|
| Sind relevante Assets, Produkte und Versionen vollständig bestätigt? | Nein |
| Ist die tatsächliche Scanabdeckung messbar? | Nein |
| Sind reale Befunde und Originalquellen kontrolliert referenziert? | Nein |
| Sind organisationsbezogene Prioritäten und Fristen freigegeben? | Nein |
| Sind Patchquelle, Test, Freigabe und Rollout stichprobenfest belegt? | Nein |
| Wurden Behebungen technisch verifiziert? | Nein |
| Sind aktive Ausnahmen und EOL-Systeme vollständig erfasst? | Nein |
| Wurde die Nachweisstruktur intern auditiert? | Nein |
Der Musterbestand erlaubt keine positive Aussage über Schwachstellenabdeckung, Patchstand oder Wirksamkeit.
¶ 28. Mitgeltende Seiten
| Thema | Führende Seite |
|---|---|
| operatives Schwachstellen- und Patchverfahren | Schwachstellen- und Patchmanagement |
| Assets, Produkte und Owner | Asset-Inventar |
| Bedrohungslage und Quellen | Bedrohungsinformationen |
| Änderungen, Tests und Rollback | IT-Betrieb und Änderungen |
| Entwicklung und Abhängigkeiten | Sichere Entwicklung |
| Cloud und externe Verantwortung | Mobile Arbeit und Cloud und Lieferanten und Dienstleister |
| Ausnahmen und Restrisiken | Ausnahmen und Risikoakzeptanzen |
| führendes Nachweisregister | Nachweisregister |
| Maßnahmensteuerung | Maßnahmen- und Umsetzungsregister |
| Vorfallbehandlung | Incident Response |
| unabhängige Prüfung | Interne Audits |
¶ 29. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei ISO 27001, TISAX, Risikomanagement, technischen Sicherheitsprozessen und belastbarer Nachweisführung
- ISO-27001-Beratung und Auditvorbereitung
- SMCT MANAGEMENT – Managementberatung mit System
- Erstgespräch unter info@smct-management.de vereinbaren
¶ 30. Offene Punkte vor Freigabe
- realen Asset-, Produkt-, Versions- und Servicebestand bestätigen,
- Quellen, Scanner, Scanprofile, Credentials und Abdeckung freigeben,
- Prioritätsmodell, Fristen, Eskalationen und Befugnisse festlegen,
- Patchquelle, Integritätsprüfung, Test, Change und Rollback operationalisieren,
- Rollout- und Ist-Versionsnachweise je Assetklasse festlegen,
- Retestverfahren und Abschlusskriterien freigeben,
- Ausnahme-, OT-, EOL-, Cloud- und Lieferantenprozesse verbinden,
- geschützte Originalablage und Registerreferenzen einrichten,
- Pilotstichprobe vom Befund bis zur Verifikation durchführen,
- fachliche Prüfung und formale Freigabe dokumentieren.
¶ 31. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 08.08.2026 | Erste Fassung für Asset-Scope, Befund, Priorisierung, Patchentscheidung, Test, Rollout, technische Verifikation, Ausnahmen und Kennzahlen | IT-Leitung / Informationssicherheit | Ausstehend | – |
¶ 32. Quellen und fachliche Grundlagen
- CVE Program – offizielle Schwachstellenkennungen
- CISA – Known Exploited Vulnerabilities Catalog
- FIRST – Common Vulnerability Scoring System
- BSI – Schwachstellen verantwortungsvoll koordinieren und offenlegen
- BSI – Umsetzungshinweise zu Prozessleit- und Automatisierungstechnik
- ISO – ISO/IEC 27001 Information security management systems
- ENX – TISAX Downloads und ISA
- SMCT MANAGEMENT – ISO-27001-Beratung
Vor der betrieblichen Nutzung sind die tatsächlich anwendbaren Norm-, ISA-, Rechts-, Vertrags-, Hersteller-, Kunden- und Betriebsanforderungen sowie Scope, Prioritäten und Befugnisse zu bestätigen. Lizenzierte Norm- und ISA-Texte bleiben die führenden Quellen und werden nicht in dieser Wiki-Seite reproduziert.