NZISM: Sicherheitsbetrieb, Vorfälle und Meldung an das NCSC, Produktauswahl, Patching und Lieferkette, und was ein deutscher Lieferant oder Dienstleister daraus erwarten muss

Problem in der Praxis

Die erste Fehlannahme betrifft die Meldefrist. Wer aus anderen Regelwerken feste Stundenfristen kennt, sucht sie im NZISM und findet keine; es spricht von "as soon as possible", bei Critical und Serious von sofortigem Handeln. Umgekehrt ist das Fehlen einer Zahl kein Freibrief: Der Kunde muss vom Dienstleister verlangen, informiert und konsultiert zu werden, und muss selbst so bald wie möglich an das NCSC melden. Ob der Vertrag eine konkrete Frist enthält, ist zu prüfen; fehlt sie, lässt sie sich vereinbaren. Ob neuseeländisches Recht, etwa der Privacy Act 2020, eigene Fristen setzt, beschreibt das NZISM nicht, und der Korpus führt diese Gesetze nicht.

Die zweite Fehlannahme ist eine Lesart ohne Einstufung. Wer eine Ausschreibung liest, die "die NZISM-Patchvorgaben" verlangt, unterstellt oft die strengste Form. Ob die Zwei-Tage-Vorgabe für kritische Patches als MUST gilt, hängt aber an der Einstufung des Systems; für alle Einstufungen ist sie eine SHOULD-Vorgabe mit "vorzugsweise binnen zwei Tagen". Beide Lesarten führen zu Fehlern: Wer zu viel zusagt, kann es nicht halten; wer zu wenig anbietet, fällt bei einem höher eingestuften System durch.

Die dritte Fehlannahme betrifft Service und Rückläufer. Deutsche Hersteller schicken defekte Geräte oft in ein zentrales Reparaturzentrum und setzen eigene Techniker ohne neuseeländische Sicherheitsermächtigung ein. Nach dem NZISM muss die Stelle einen nicht ermächtigten Techniker durch ermächtigtes, eingewiesenes und weisungsbefugtes Personal begleiten lassen, und Transport, Bearbeitung und Lagerung außer Haus müssen der Einstufung des Geräts entsprechen; zusätzlich soll die Wartung die höchste Einstufung des Bereichs berücksichtigen, in den das Gerät zurückkehrt. Geräte, die NZEO-Informationen verarbeitet oder gespeichert haben und nicht bereinigt werden können, müssen zur Bereinigung oder Vernichtung nach Neuseeland zurück. Ein Austauschprozess über Deutschland passt dazu nicht ohne Weiteres.

CISO-Einordnung

Rechtsnatur und Einstufung. Die Controls dieser Kapitel adressieren die Stelle. Was davon für das deutsche Unternehmen gilt, ergibt sich aus dem Vertrag; Einzelheiten zur Betroffenheit in nzism-002. Jede Control trägt einen Einstufungsbereich. "All Classifications" umfasst nach 1.1.26 alle Stufen von Official Information und UNCLASSIFIED bis TOP SECRET einschließlich Zusatzvermerken. Wo eine Vorgabe als MUST nur für CONFIDENTIAL, SECRET und TOP SECRET und daneben als SHOULD für alle Einstufungen steht, ist sie für niedriger eingestufte Systeme Empfehlung, für höher eingestufte Pflicht.

Sicherheitsreviews (Abschnitt 6.1). Die Stelle soll ihre Systeme mindestens jährlich überprüfen und das dokumentieren, und zwar durch vom Prüfgegenstand unabhängiges Personal oder einen unabhängigen Dritten. Zu den Gegenständen zählt das NZISM unter anderem die Sicherheitsdokumentation einschließlich Prüfberichten Dritter, Dispensationen vor ihrem Ablauf, Verfahren nach einem Vorfall oder einer Übung und Änderungen am NZISM selbst (6.1.9). Anpassungen aus einer Schwachstellenanalyse sollen mit der Vulnerability Disclosure Policy vereinbar sein.

Schwachstellenanalyse (Abschnitt 6.2). Die Stelle soll eine Strategie zur Schwachstellenanalyse umsetzen, die unter anderem die Beobachtung öffentlicher Schwachstelleninformationen, die Erwägung, automatisierte Werkzeuge für kontrollierte Schwachstellenbewertungen einzusetzen, und manuelle Konfigurationsprüfungen umfasst. Sie soll Schwachstellenbewertungen als Ausgangsbasis durchführen, etwa vor dem ersten Einsatz eines Systems, nach wesentlichen Vorfällen oder Änderungen und wenn ITSM oder System Owner es verlangen, und soll alle dabei gefundenen Schwachstellen analysieren und behandeln. Notwendige Änderungen laufen über das normale Änderungsmanagement (6.2.3). Alle Controls dieses Abschnitts sind SHOULD.

Änderungsmanagement (Abschnitt 6.3). Als Anlässe für Änderungen nennt das NZISM ausdrücklich Mitteilungen von Anbietern über Upgrades und über das Ende der Lebensdauer von Software oder Geräten (6.3.3). Für Routine- und Notfalländerungen soll die Stelle den dokumentierten Änderungsprozess einhalten, die Änderung von der zuständigen Stelle genehmigen lassen, sicherheits- oder akkreditierungsrelevante Änderungen der Accreditation Authority zur Genehmigung vorlegen und die Sicherheitsdokumentation nachziehen; für TOP SECRET ist dasselbe MUST (6.3.6). Ebenso soll der Prozess festlegen, was vor und nach Notfalländerungen geschieht, für TOP SECRET muss er es (6.3.7). Als MUST für alle Einstufungen gilt: Beeinflusst eine Konfigurationsänderung die Sicherheit und wird das Gesamtrisiko dadurch als verändert bewertet, muss die Stelle das System erneut akkreditieren (6.3.8). Für einen Dienstleister heißt das: Eine Änderung, die er für Routine hält, kann beim Kunden eine erneute Akkreditierung auslösen (zum Verfahren nzism-003).

Kontinuität und Wiederherstellung (Abschnitt 6.4). Die Stelle muss Verfügbarkeits- und Wiederherstellungsanforderungen für ihre Systeme bestimmen und dazu passende Maßnahmen im Einklang mit dem Security Risk Management Plan umsetzen (6.4.5). Sie soll unentbehrliche Unterlagen (vital records) bestimmen und sichern, Kopien mit dokumentierten Wiederherstellungsverfahren außer Haus und der höchsten Einstufung entsprechend aufbewahren, Sicherung und Wiederherstellung regelmäßig testen und einen Business-Continuity-Plan und einen Disaster-Recovery-Plan erstellen. Vorgaben zu Wiederherstellungszeiten nennt das NZISM nicht; sie bestimmt jede Stelle nach ihrem Bedarf.

Erkennen von Vorfällen (Abschnitt 7.1). Für Systeme der Stufen CONFIDENTIAL, SECRET und TOP SECRET muss die Stelle Werkzeuge und Verfahren zur Erkennung möglicher Vorfälle entwickeln, umsetzen und pflegen, die unter anderem Schulung, Abwehr von Schadcode, Angriffserkennung, Überwachung abfließender Daten, Zugriffsanomalien und Schwachstellenbewertungen abdecken; für alle Einstufungen soll sie das, dort ergänzt um dynamische Netzabwehr wie Protective DNS oder Next-Generation-Firewalls (7.1.7). Die genannten Werkzeugtypen, etwa EDR, SIEM und Data Loss Prevention, führt das NZISM als Beispiele, die Stellen in Betracht ziehen können.

Begriffe und Kategorien (Abschnitt 7.2). Ein Cyber-Sicherheitsvorfall ist nach 7.2.10 jedes Ereignis, das Vertraulichkeit, Integrität oder Verfügbarkeit eines Informationssystems oder seiner Informationen gefährdet oder gefährden kann, einschließlich Verstößen gegen Sicherheitsrichtlinien, Nutzungsregeln oder einschlägige Vorschriften. Das NZISM schlägt eine dreistufige Einteilung vor: Critical, Serious und Low (7.2.14). Vorfälle, deren Umfang oder Ursache noch nicht feststeht, sollen als Serious oder Critical eingestuft und so behandelt werden (7.2.15). Schwellen, ab denen ein Ereignis eine Reaktion auslöst, soll die Stelle selbst festlegen (7.2.13).

Interne Meldung. Die Stelle muss ihr Personal anweisen, Vorfälle nach ihren Verfahren so bald wie möglich nach Entdeckung an einen ITSM zu melden (7.2.18), und der ITSM muss den CISO vollständig informiert halten (7.2.19). Critical und Serious verlangen nach dem erläuternden Text sofortiges Handeln; Low lässt sich meist über periodische, etwa wöchentliche oder monatliche Berichte abdecken.

Meldung an das NCSC. Der ITSM der Stelle muss Vorfälle der Kategorien Critical und Serious sowie Vorfälle an behördenübergreifenden oder staatlichen Systemen so bald wie möglich an das NCSC melden; dafür nennt das NZISM ein Meldeformular auf der Website des NCSC (7.2.20). Vorfälle der Kategorie Low soll die Stelle melden, und Berichte über die Nachbetrachtung (post-incident review) soll sie förmlich mit dem NCSC teilen. Eine Stunden- oder Tagesfrist nennt das NZISM für keine dieser Meldungen (Volltextsuche siehe Quellenmatrix).

Auslagerung und Vorfälle. Die Meldepflicht der Stelle gilt unabhängig davon, ob sie das Vorfallsmanagement selbst betreibt oder IT-Funktionen ganz oder teilweise ausgelagert hat (7.2.5). Bei Auslagerung bleibt die Stelle für die Meldung aller Vorfälle verantwortlich, ausdrücklich auch bei ausgelagerten Cloud-Diensten, und muss sicherstellen, dass der Dienstleister sie bei einem Vorfall informiert und konsultiert (7.2.21). Zudem sollen Stellen bedenken, dass ihre Verträge und Vereinbarungen mit Anbietern das Teilen von Vorfallsinformationen mit dem NCSC ermöglichen (7.2.8). Eine eigene Meldepflicht des Dienstleisters direkt gegenüber dem NCSC formuliert das NZISM in den gefundenen Stellen nicht; es legt die Meldung bei der Stelle und den Informationsfluss vom Dienstleister zu ihr. In den Abschnitten zu Session Border Controllern (19.5.28) und zu Cloud-Diensten (20.1.25) verlangt es außerdem, Leistungen zur Vorfallsbehandlung in die Verträge mit dem Anbieter aufzunehmen (Einzelheiten zu Cloud in nzism-005).

Kryptografisches Schlüsselmaterial. Die Stelle muss alle Nutzer über einen vermuteten oder bestätigten Verlust oder eine Kompromittierung von Schlüsselmaterial informieren, kompromittierte Schlüssel dringend ersetzen und den Ersatz in der Vorfallsmeldung festhalten; einen vermuteten Verlust oder eine Kompromittierung von Schlüsselmaterial für HACE (hochsichere Kryptogeräte) muss sie dem GCSB dringend melden (7.2.22 bis 7.2.24).

Behandlung von Vorfällen (Abschnitt 7.3). Die Stelle muss Zuständigkeiten und Verfahren für Vorfälle je System in der Sicherheitsdokumentation festlegen (7.3.5) und soll alle Vorfälle in einem Register führen, das sie für spätere Risikobewertungen nutzt (7.3.6). Für Datenabflüsse (data spill oder data breach) muss sie Erkennungsverfahren einrichten, die Behandlung im Incident Response Plan festlegen, jeden Abfluss als Vorfall behandeln und annehmen, dass Daten der höchsten Einstufung auf dem System kompromittiert sind (7.3.7). Die Einzelheiten muss sie nach Maßgabe des Privacy Act 2020 an den Privacy Commissioner und den Informationseigentümer melden; was dieses Gesetz im Einzelnen verlangt, beschreibt das NZISM nicht. Gelangen eingestufte Informationen auf ein dafür nicht akkreditiertes System, muss sofort ein ITSM hinzugezogen und das System oder der Abfluss abgetrennt oder isoliert werden; die höher eingestuften Informationen dürfen ohne ausdrückliche Genehmigung des ITSM nicht gelöscht und überhaupt nicht kopiert, angesehen, gedruckt oder per E-Mail versandt werden (7.3.8). Gelingt die Trennung nicht, soll die Stelle sofort das NCSC um Rat fragen.

Bei Schadcode beschreibt das NZISM eine Schrittfolge als SHOULD, die unter anderem Isolation, die Entscheidung über eine Unterstützung durch das NCSC und, wenn diese vereinbart ist, das Abwarten weiterer Schritte bis zu dessen Anweisung, die Prüfung angebundener Systeme und Sicherungen sowie den Wechsel von Zugangsdaten und Schlüsselmaterial umfasst (7.3.9). Will eine Stelle einen Angreifer unter kontrollierten Bedingungen weiter agieren lassen, um Informationen oder Beweise zu gewinnen, muss sie Rechtsrat einholen (7.3.10); nach dem erläuternden Text soll sie mit Geschäftsverantwortlichen und Rechtsberatern klären, ob damit Service Level Agreements oder vertragliche Pflichten verletzt würden. Beweise soll sie sichern, etwa durch Kopien der Protokolle und Aufzeichnungen aller Untersuchungsschritte, und Unterstützung des NCSC so früh wie möglich anfordern, ohne vorher etwas zu tun, was die Beweisintegrität beeinträchtigen könnte (7.3.11, 7.3.12).

Produktauswahl (Abschnitt 12.1). Der Abschnitt gilt für Produkte, die Sicherheitsfunktionen zum Schutz von Informationen bereitstellen; für Produkte ohne Sicherheitsfunktion, oder deren Sicherheitsfunktionen nicht genutzt werden, darf die Stelle ihren eigenen Beschaffungsregeln folgen (12.1.2, 12.1.3). Für Produkte mit Sicherheitsfunktion gilt eine Rangfolge: zuerst gegen ein Protection Profile evaluierte Produkte, dann Produkte mit abgeschlossener Evaluierung im australischen Programm AISEP oder Anerkennung nach dem Common Criteria Recognition Arrangement (CCRA), dann Produkte in laufender AISEP-Evaluierung, dann Produkte in laufender Evaluierung in einem Schema, dessen Ergebnis der GCSB nach Abschluss anerkennen wird. Für CONFIDENTIAL, SECRET und TOP SECRET ist diese Rangfolge MUST, verbunden mit dem Hinweis, sich andernfalls an den GCSB zu wenden, und die Begründung für die Wahl eines Produkts in laufender Evaluierung muss dokumentiert und das Risiko akzeptiert werden; für alle Einstufungen ist sie SHOULD, und fällt ein Produkt in keine Kategorie, gelten die üblichen Auswahlkriterien (12.1.30). Gibt es für ein Produkt einen Consumer Guide (Einsatzhinweise aus der Evaluierung), muss die Stelle ihn prüfen und einhalten (12.1.32). Vor dem Kauf von High-Assurance-Produkten und HACE muss sie den GCSB kontaktieren und etwaige produktspezifische Anforderungen einhalten.

Für einen deutschen Hersteller mit Common-Criteria-Zertifikat aus einem ausländischen Schema ist wichtig: Nach 12.1.23 erkennt der GCSB Evaluierungen in Common-Criteria-Schemata anderer Staaten im Rahmen des AISEP weiter an; als eine der Anerkennungsvereinbarungen des AISEP nennt 12.1.17 das CCRA bis zur Stufe EAL2 mit der Erweiterung um Fehlerbehebung im Lebenszyklus. Zugleich ermutigt das NZISM Stellen, vor der Wahl eines nicht im AISEP evaluierten Produkts beim GCSB nachzufragen, ob es für Neuseeland anerkannt wird (12.1.16). Die Stelle soll prüfen, ob die gewünschte Sicherheitsfunktion im Evaluierungsumfang liegt und zur eigenen Umgebung passt (12.1.31), und Produkte von Entwicklern wählen, die sich zur fortlaufenden Pflege der Zusicherung verpflichtet haben (12.1.37). Für nicht evaluierte Software, etwa aus dem Internet, soll sie verifizierbare Quellen und vom Anbieter bereitgestellte Prüfsummen nutzen und das Zusammenspiel vorab in einer Testumgebung prüfen (12.1.33). Bei der Lieferung soll sie auf die Lieferverfahren aus der Evaluierung achten oder, bei nicht evaluierten Produkten, auf Kennzeichnungsänderungen, Schäden und Manipulationsspuren prüfen (12.1.34, 12.1.35). Für High-Assurance-Produkte und HACE gilt bei der Beschaffung eine MUST-Sonderregel: Die Stelle muss den GCSB kontaktieren und etwaige produktspezifische Lieferverfahren einhalten (12.1.34).

Installation und Konfiguration (Abschnitt 12.2). Will die Stelle ein evaluiertes Produkt außerhalb seiner evaluierten Konfiguration nutzen, muss sie eine Sicherheitsrisikobewertung durchführen, die Notwendigkeit, Tests und Einsatzumgebung umfasst (12.2.6). High-Assurance-Produkte und HACE dürfen nicht in nicht evaluierten Konfigurationen betrieben werden.

Patching (Abschnitt 12.4). Für alle Einstufungen muss die Stelle eine Patch-Management-Strategie einschließlich eines Bewertungs- oder Testverfahrens umsetzen (12.4.4). Für CONFIDENTIAL, SECRET und TOP SECRET muss sie kritische Sicherheitspatches so bald wie möglich und binnen zwei Tagen nach Veröffentlichung des Patches oder Updates einspielen; für alle Einstufungen soll sie das so bald wie möglich und vorzugsweise binnen zwei Tagen tun. Nicht kritische Sicherheitspatches soll sie so bald wie möglich einspielen, und zwar über den vom Anbieter empfohlenen Weg. High-Assurance-Produkte und HACE darf sie ohne Freigabe des GCSB nicht patchen. Firmware-Updates müssen so erfolgen, dass Integrität und Echtheit der Quelle und des Updatevorgangs geprüft werden (12.4.6). Lassen sich bekannte Schwachstellen nicht patchen oder sind keine Sicherheitspatches verfügbar, soll die Stelle ausweichende Maßnahmen ergreifen; dazu zählt das NZISM ausdrücklich, den Anbieter nach einem anderen Weg zu fragen oder auf ein Produkt eines reaktionsschnelleren Anbieters zu wechseln (12.4.5). Wird ein Datum für das Ende des Supports angekündigt oder wird das Produkt vom Entwickler nicht mehr unterstützt, soll sie das Risiko der Weiternutzung bewerten (12.4.7). Die Stelle soll zudem einschlägige Quellen zu neuen Schwachstellen und Patches beobachten (12.4.3).

Wartung und Reparatur (Abschnitt 12.5). Reparaturen an High-Assurance-Produkten und HACE brauchen vorher die Zustimmung des GCSB (MUST). Wartung von Geräten mit Datenträgern soll vor Ort durch angemessen ermächtigte Techniker erfolgen. Setzt die Stelle einen nicht ermächtigten Techniker ein, muss ihn eine Person begleiten, die angemessen ermächtigt und eingewiesen ist, die Preisgabe eingestufter Informationen verhindert, die Integrität des Geräts schützt und dem Techniker Weisungen erteilen darf (12.5.4); Gerät und Datenträger soll die Stelle vorher bereinigen und neu einstufen oder ihre Einstufung aufheben. Bei Wartung außer Haus muss sie sicherstellen, dass Transport, Bearbeitung und Lagerung jederzeit der Einstufung des Geräts entsprechen (12.5.5). Zusätzlich soll die Wartung außer Haus jedes Gerät nach den Anforderungen der höchsten Einstufung behandeln, die in dem Bereich verarbeitet, gespeichert oder übertragen wird, in den das Gerät zurückkehrt, und nach der Rückkehr in einen gesicherten Bereich soll die Stelle das Gerät technisch prüfen lassen (12.5.6).

Bereinigung und Entsorgung (Abschnitt 12.6). Geräte mit Datenträgern muss die Stelle vor der Entsorgung bereinigen oder vernichten und dann ihre Einstufung aufheben (declassify, 12.6.4); eine bloß niedrigere Einstufung genügt dafür nicht, und sie muss ein dokumentiertes Entsorgungsverfahren haben. Geräte und Datenträger, die NZEO-Informationen verarbeitet oder gespeichert haben und nicht bereinigt werden können, müssen zur Bereinigung oder Vernichtung, Aufhebung der Einstufung und Entsorgung nach Neuseeland zurückgebracht werden. Für einen Hersteller mit zentralem Austauschprozess ist das eine Vorgabe, die er vor Vertragsschluss kennen sollte.

Lieferkette (Abschnitt 12.7). Das NZISM nennt fünf Aspekte des Lieferkettenrisikos: Schutz sensibler Informationen und Systeme, Lieferfähigkeit, Produktzusicherung, Sicherheitsvalidierung und die nationale Beschaffungspolitik (12.7.7). Die Stelle soll Lieferkettenrisiken in ihre organisationsweite Risikobewertung aufnehmen, laufend überwachen und die Government Rules of Procurement befolgen (12.7.14). Sie soll von Bietern und Auftragnehmern Angaben verlangen, welche Beschränkungen der Offenlegung, Weitergabe oder Nutzung von Technologie aus Exportkontrollen oder Sicherheitsvereinbarungen folgen, und Nachweise, dass ihre Lieferketten die vertraglichen Anforderungen an die Versorgungssicherheit erfüllen; von Auftragnehmern und Unterauftragnehmern soll sie Informationen zu ihrer Fähigkeit verlangen, Informationen zu schützen (12.7.15). Für CONFIDENTIAL, SECRET und TOP SECRET muss sie allen Auftragnehmern und Unterauftragnehmern vertragliche Pflichten zum Schutz der Informationen während des gesamten Ausschreibungs- und Vergabeverfahrens auferlegen; für alle Einstufungen soll sie vertragliche Pflichten zum Schutz der Informationen während des Ausschreibungs- und Vergabeverfahrens vorsehen; Auftragnehmer und Unterauftragnehmer, denen die nötige Zuverlässigkeit fehlt, um Risiken für die nationale Sicherheit auszuschließen, oder die in einem früheren Vertrag Pflichten zum Informationsschutz in einer Weise verletzt haben, die einem schweren Fehlverhalten gleichkommt, soll sie ablehnen (12.7.16). Sie soll sicherstellen, dass Änderungen in der Lieferkette während der Vertragslaufzeit die Lieferfähigkeit nicht beeinträchtigen (12.7.17). Den Herkunftsnachweis, also eine Aufzeichnung von Ursprung, Geschichte, Spezifikationsänderungen und Lieferweg, muss sie für CONFIDENTIAL, SECRET und TOP SECRET von Lieferanten und Auftragnehmern verlangen, für alle Einstufungen soll sie es (12.7.18). Vor dem Einsatz soll sie Geräte bei Eingang auf Manipulation, Umetikettierung und Schäden prüfen, testen und Software, Firmware oder sonstigen Programmcode, der für Initialisierung, Betrieb, Service oder Wartung des Geräts erforderlich ist, vor der Installation im operativen System auf Schadcode prüfen; für CONFIDENTIAL, SECRET und TOP SECRET muss sie den GCSB zu Vorinstallations-, Sicherheitsverifikations- und zugehörigen Tests konsultieren, bevor das Gerät in einem operativen System eingesetzt wird (12.7.20). Für Geräte mit langer Einsatzdauer in kritischen Systemen soll sie für den Fall, dass der Lieferant nicht mehr liefern kann, Lizenzen, Informationen zur Ersatzteilfertigung, Testgeräte und Vereinbarungen über technische Unterstützung sichern (12.7.21).

Umsetzungsperspektive

1. Einstufung des Kundensystems erfragen. Sie entscheidet, ob Vorgaben zu Erkennung, Produktauswahl, Patching, Herkunftsnachweis und vertraglichem Informationsschutz MUST oder SHOULD sind. Die verbindliche Einstufung trifft der Kunde.
2. Vorfallsweg zum Kunden bauen. Kontaktstelle, Kriterien für Critical, Serious und Low im Abgleich mit dem Kunden, Meldeweg "so bald wie möglich" und die Bereitschaft, den Kunden zu konsultieren. Die konkrete Frist vertraglich vereinbaren.
3. Beweissicherung vor Bereinigung festlegen. Beim Vorfall in Kundensystemen erst sichern und abstimmen, dann bereinigen; das NZISM legt Wert darauf, vor einer Unterstützung durch das NCSC nichts zu tun, was die Beweise beeinträchtigt.
4. Änderungen klassifizieren. Mit dem Kunden vereinbaren, welche Änderungen er vorab sehen muss, weil sie die Akkreditierung berühren können, und Ende-der-Lebensdauer-Mitteilungen früh liefern.
5. Patchversprechen an die Einstufung binden. Für höher eingestufte Systeme die Zwei-Tage-Vorgabe für kritische Patches als Kundenpflicht einplanen, Patches auf dem empfohlenen Weg mit prüfbarer Integrität bereitstellen und Ausweichmaßnahmen für ungepatchte Schwachstellen beschreiben.
6. Service- und Rücklaufprozess prüfen. Begleitung nicht ermächtigter Techniker, Anforderungen an Transport und Lagerung, Bereinigung vor Versand und Rückführung nicht bereinigbarer NZEO-Geräte nach Neuseeland einplanen.
7. Lieferkettenpaket vorbereiten. Herkunftsnachweis, Angaben zu Exportkontrollbeschränkungen, Unterauftragnehmer, Lieferfähigkeit, Prüfsummen und Lieferverfahren, Evaluierungsstatus und Consumer Guides der Produkte.

Typische Fehler

1. Eine Stundenfrist wird ins NZISM hineingelesen, oder umgekehrt wird aus dem Fehlen einer Zahl geschlossen, der Dienstleister könne sich Zeit lassen. Das NZISM verlangt "so bald wie möglich"; ob der Vertrag eine konkrete Frist enthält, ist zu prüfen.
2. Vorgaben werden ohne Einstufungsbereich gelesen, sodass eine SHOULD-Vorgabe als Pflicht oder eine MUST-Vorgabe für höher eingestufte Systeme als bloße Empfehlung behandelt wird.
3. Der Dienstleister meldet nur, was er selbst für schwerwiegend hält, obwohl Vorfälle mit ungeklärtem Umfang oder ungeklärter Ursache nach dem NZISM als Serious oder Critical zu behandeln sind und der Kunde informiert und konsultiert werden muss.
4. Ein kompromittiertes System wird sofort neu aufgesetzt oder abgeschaltet, bevor Beweise gesichert und der Kunde einbezogen ist.
5. Konfigurationsänderungen werden als Routine ausgerollt, obwohl eine risikoverändernde Änderung beim Kunden eine erneute Akkreditierung auslöst.
6. Defekte Geräte gehen ungeprüft in ein ausländisches Reparaturzentrum, obwohl Transport und Lagerung der Einstufung entsprechen müssen und nicht bereinigbare NZEO-Geräte nach Neuseeland zurück müssen.
7. Ein Common-Criteria-Zertifikat wird als für Neuseeland anerkannt behauptet, ohne die vom NZISM genannte Anerkennungsvereinbarung, den Evaluierungsumfang und die empfohlene Rückfrage beim GCSB zu berücksichtigen.
8. Herkunftsnachweis und Angaben zu Exportkontrollbeschränkungen werden erst auf Nachfrage erhoben, obwohl der Kunde sie nach dem NZISM schon im Vergabeverfahren verlangen soll oder, bei höherer Einstufung, beim Herkunftsnachweis muss.

Risiken und Trade-offs

Der Grundkonflikt liegt zwischen schneller Behebung und Beweissicherung. Ein Dienstleister, der einen kompromittierten Server sofort neu aufsetzt, verkürzt den Ausfall, vernichtet aber unter Umständen Spuren, die der Kunde und das NCSC brauchen. Wer erst sichert und abstimmt, verlängert den Ausfall, hält aber die Linie des NZISM. Diese Abwägung gehört vorab in den Vertrag und in das Betriebshandbuch, nicht in die erste Stunde eines Vorfalls.

Beim Patching steht Geschwindigkeit gegen Stabilität. Die Zwei-Tage-Vorgabe für kritische Patches lässt wenig Raum für Tests, während das NZISM zugleich eine Patch-Strategie mit Bewertungs- oder Testverfahren verlangt. Ein Hersteller, der vorab getestete Patches mit prüfbarer Integrität liefert, nimmt dem Kunden diesen Konflikt teilweise ab und erhöht seine Chancen in der Lieferkettenbewertung.

Bei Service und Lieferkette steht Effizienz gegen Kontrolle. Zentrale Reparaturzentren, gemeinsame Ersatzteilpools und globale Unterauftragnehmer senken Kosten; das NZISM verlangt dagegen Transparenz über Herkunft, Unterauftragnehmer und Exportbeschränkungen sowie in bestimmten Fällen Begleitung vor Ort und Rückführung nach Neuseeland. Ein Sonderprozess für neuseeländische Regierungskunden ist teuer, aber oft die Voraussetzung, überhaupt in Betracht zu kommen.

Entscheidungspunkte

• Für welche Einstufungen wollen wir neuseeländische Regierungskunden beliefern oder betreuen, und tragen wir die damit verbundenen MUST-Vorgaben?
• Welche Meldefrist und welche Kriterien für Critical, Serious und Low sagen wir vertraglich zu, und reicht unsere Organisation dafür?
• Sagen wir für kritische Sicherheitspatches eine Bereitstellung zu, die dem Kunden die Zwei-Tage-Vorgabe ermöglicht?
• Können wir Wartung vor Ort mit ermächtigtem Personal anbieten, oder akzeptieren wir die Begleitung durch Kundenpersonal und einen eigenen Rücklaufprozess?
• Wie liefern wir Herkunftsnachweise und Angaben zu Exportkontrollbeschränkungen, und welche Unterauftragnehmer legen wir offen?
• Welche Änderungen legen wir dem Kunden vor, weil sie seine Akkreditierung berühren können?

Praktische Empfehlungen

• Einen neuseelandspezifischen Vorfallsanhang zum Vertrag vorbereiten: Kontaktstelle, Kategorien, Meldeweg, Konsultation, Beweissicherung, Zusammenarbeit mit einer Unterstützung durch das NCSC.
• Patches mit Prüfsummen oder Signaturen und auf einem dokumentierten Weg bereitstellen; Ende des Supports früh und schriftlich ankündigen.
• Für jedes Produkt mit Sicherheitsfunktion Evaluierungsstatus, Schema, Umfang und Consumer Guide griffbereit halten und die Anerkennung für Neuseeland nicht selbst behaupten.
• Den Rücklauf- und Reparaturprozess für Kundensysteme einstufungsgerecht beschreiben, einschließlich Bereinigung vor Versand und Sonderweg für NZEO-Geräte.
• Ein Lieferkettenpaket mit Herkunftsnachweis, Unterauftragnehmern, Lieferfähigkeit und Exportbeschränkungen pflegen.
• Fragen zum Privacy Act 2020, zum Exportkontrollrecht oder zu Anforderungen des GCSB nicht selbst beantworten, sondern beim Kunden, beim GCSB oder bei neuseeländischer Rechtsberatung klären.

Relevante Normreferenzen

• NZISM 3.9 (November 2025), Abschnitt 1.1.26 ("All Classifications") und 1.2.6 (Rechtsnatur).
• Kapitel 6 "Information security monitoring": 6.1 Information Security Reviews, 6.2 Vulnerability Analysis, 6.3 Change Management, 6.4 Business Continuity and Disaster Recovery.
• Kapitel 7 "Information Security Incidents": 7.1 Detecting, 7.2 Reporting (Kategorien 7.2.14 bis 7.2.16, Meldung an das NCSC 7.2.20, Auslagerung 7.2.21, Schlüsselmaterial 7.2.22 bis 7.2.24), 7.3 Managing (Datenabfluss, Schadcode, fortgesetzte Angriffe, Beweise).
• Kapitel 12 "Product Security": 12.1 Selection and Acquisition, 12.2 Installation and Configuration, 12.3 Classifying and Labelling, 12.4 Patching and Updating, 12.5 Maintenance and Repairs, 12.6 Sanitisation and Disposal, 12.7 Supply Chain; dazu 19.5.28 und 20.1.25 (Vorfallsbehandlung in Verträgen mit Anbietern von Session-Border-Controller- und Cloud-Diensten) als Verweis.
• Abgrenzung: Vorfälle, Lieferkette und Auslagerung nach dem australischen ISM stehen im ism-australien-Track; Incident Response und Lieferkettenrisikomanagement nach NIST im nist-Track; Notfallmanagement und Patch- und Änderungsmanagement nach IT-Grundschutz im it-grundschutz-Track; Incident Response und Schwachstellenmanagement nach den CIS Controls im cis-Track. Hier steht nur, was das NZISM selbst sagt; Rollen und Certification and Accreditation in nzism-003, Cloud und Auslagerung in nzism-005, Betroffenheit des deutschen Unternehmens in nzism-002.