Technische NZISM-Leitlinien auf Managementebene: Standardumgebung, Zugang und Mehrfaktor, Kryptografie und Post-Quanten-Vorbereitung, Netze, Gateways, Datentransfers

Problem in der Praxis

Das erste Muster ist die übernommene Kontrollmenge ohne Zuschnitt. Ein Dienstleister erhält vom neuseeländischen Kunden die Vorgabe "NZISM" und behandelt alle Controls als gleich verbindlich, oder er übernimmt umgekehrt nur die MUST-Controls und übersieht, dass für hoch eingestufte Systeme zusätzliche MUST-Controls gelten. Beides lässt sich vermeiden, wenn am Anfang feststeht, welche Einstufung das System trägt und welche Technologien es nutzt.

Das zweite ist die Mehrfaktor-Lücke. Mehrfaktor-Authentisierung ist eingeführt, aber mit SMS- oder E-Mail-Codes, und ein Notfallkonto ist mangels Konzept entweder ungeschützt oder hängt an einer Person. Das NZISM beschreibt SMS-, E-Mail- und App-basierte Einmalpasswörter als nachweislich anfällig für Phishing und Angriffe durch einen Mittelsmann, und es behandelt Notfallkonten eigens.

Das dritte ist die Kryptografie ohne Inventar. Niemand weiß, welche Systeme auf Public-Key-Verfahren beruhen und welche Datenbestände lange vertraulich bleiben müssen. Genau diese beiden Inventare empfiehlt das NZISM als Vorbereitung auf die Post-Quanten-Kryptografie.

Das vierte ist die Konzern-IT als blinder Fleck. Eine deutsche Zentrale administriert neuseeländische Systeme mit, und niemand hat geprüft, ob dort NZEO-Informationen oder eingestufte Informationen liegen, für die das NZISM Staatsangehörigkeits- und Kontrollanforderungen stellt.

CISO-Einordnung

Wie die Verbindlichkeit technisch gelesen wird. Das NZISM fasst Informationen der Stufen UNCLASSIFIED, IN-CONFIDENCE, SENSITIVE und RESTRICTED unter einen einheitlichen Satz von baseline controls; für CONFIDENTIAL, SECRET und TOP SECRET kommen weitere Controls hinzu (NZISM 1.1.4, 1.1.5). Die Angabe "All Classifications" an einer Control umfasst alle Stufen einschließlich Weitergabevermerken (1.1.6). In den hier behandelten Abschnitten (2.4, Kapitel 14 bis 19, 20.2, 20.3 und Kapitel 21) stehen nach Zählung am Snapshot 584 Controls; 503 davon gelten für alle Einstufungen, nämlich 213 MUST oder MUST NOT und 290 SHOULD oder SHOULD NOT (einschließlich einer Control mit der Angabe "All Classifications, Restricted/Sensitive"). 74 MUST- oder MUST-NOT-Controls gelten nur für CONFIDENTIAL und höher, und in 47 dieser Fälle steht im selben Absatz auch eine SHOULD-Control mit Geltung für alle Einstufungen. Das belegt nur die gemeinsame Platzierung, nicht dieselbe Maßnahme: So verlangt Absatz 16.6.6 für TOP SECRET, Systemprotokolle über die gesamte Lebensdauer des Systems aufzubewahren (MUST), für alle Einstufungen dagegen nur, eine Aufbewahrungsrichtlinie festzulegen (SHOULD). Wer ein System unterhalb von CONFIDENTIAL betreibt, muss deshalb je Absatz lesen, was für seine Einstufung gilt. Wird eine MUST-Control nicht umgesetzt, ist die Begründung der Accreditation Authority (der für die Akkreditierung des Systems zuständigen Stelle oder Person) vor Genehmigung der Ausnahme darzulegen (1.1.46); auch der Verzicht auf eine SHOULD-Control braucht eine dokumentierte Abwägung, deren Restrisiko die Accreditation Authority mitträgt (1.1.47 bis 1.1.49). Das Abweichungsverfahren selbst behandelt nzism-002, Rollen und Akkreditierung nzism-003.

Standardumgebung und Allow Listing (Abschnitte 14.1, 14.2). Für alle Server und Arbeitsplätze verlangt eine MUST-Control eine abgestimmte technische Spezifikation je Plattform, eine Standardkonfiguration je Betriebssystemtyp und Version, keine Installation oder Deaktivierung von Software durch Nutzer ohne Genehmigung und aktuelle Patches. Eine gehärtete Standardumgebung (standard operating environment, SOE) ist als SHOULD empfohlen, ebenso die Prüfung, ob Software ungeplante Verbindungen nach außen aufbaut, mit einer bewussten Geschäftsentscheidung darüber. Application allow listing, also das Zulassen nur genehmigter Programme, ist als SHOULD Teil der Standardumgebung; wo es eingesetzt wird, darf ein Nutzer den Mechanismus nach einer MUST-Control nicht abschalten können, und Administratoren sollen nicht automatisch ausgenommen sein.

Anwendungsentwicklung und Web (Abschnitte 14.3 bis 14.5). Die Controls zur Softwareentwicklung sind durchweg SHOULD: getrennte Umgebungen für Entwicklung, Test und Produktion, sichere Programmierpraxis, Prüfung auf Schwachstellen vor dem Produktiveinsatz und Prüfung auch durch eine unabhängige Stelle neben dem Entwickler; für Webanwendungen verweist das NZISM auf die Leitfäden des Open Web Application Security Project. Eine Richtlinie zur Webnutzung ist MUST; ein Web-Proxy, TLS-Inspektion oder ersatzweise eine Liste erlaubter Adressen sind SHOULD, und zur Inspektion verschlüsselten Verkehrs empfiehlt das NZISM, rechtlichen Rat einzuholen.

E-Mail (Kapitel 15). Eine E-Mail-Nutzungsrichtlinie ist MUST, ebenso Schutzvermerke (protective markings) auf allen eingestuften und nicht eingestuften E-Mails; persönliche E-Mails ohne Regierungsinformationen sollen dagegen keinen Schutzvermerk tragen (SHOULD NOT). Für die Infrastruktur verlangen MUST-Controls unter anderem DMARC mit einer Ablehnungsrichtlinie, SPF und DKIM, opportunistisches TLS bei Verbindungen über öffentliche Infrastruktur und abgeschaltetes offenes Relaying. Öffentliche Web-Maildienste sollen für dienstliche Zwecke nicht genutzt werden (SHOULD NOT). Für einen deutschen Betreiber eines Mailsystems im Auftrag einer Regierungsstelle sind das konkrete Leistungsmerkmale.

Identität, privilegierter Zugang, Mehrfaktor, Protokollierung (Kapitel 16). Alle Nutzer müssen eindeutig identifizierbar und bei jedem Zugang authentisiert und autorisiert sein (MUST). Gemeinsame Anmeldedaten für Administrator- und privilegierte Konten sind MUST NOT, ausgenommen nach dem ausdrücklichen Vermerk an dieser Control Notfallkonten (break glass accounts); für sonstige Konten sind gemeinsame Anmeldedaten SHOULD NOT (bei CONFIDENTIAL und höher MUST NOT). Administratoren müssen für Administrationsaufgaben ein persönliches Konto nutzen, privilegierte Konten sind auf das Minimum und auf Administrationsarbeit zu beschränken. Abschnitt 16.4 verlangt als MUST eine Richtlinie für Privileged Access Management mit geringsten Rechten, förmlicher Genehmigung vor Ausgabe privilegierter Zugangsdaten, Inventar der privilegierten Konten, laufender Überwachung, Untersuchung jedes Hinweises auf Kompromittierung oder Missbrauch und Schulung. Für Passwörter nennen MUST-Controls etwa eine Mindestlänge von 16 Zeichen und einen mindestens jährlichen Wechsel auf Systemen ohne Mehrfaktor- oder passwortlose Authentisierung.

Mehrfaktor-Authentisierung ist nach Lage gestuft. MUST: für alle Nutzerkonten, wenn die Stelle extern erreichbare Systeme oder Cloud-Dienste hat oder sich an Diensten Dritter anmeldet, jeweils mit einem sicheren mehrfaktorgestützten Verfahren zum Zurücksetzen; für alle Konten mit Fernzugriff; für den Zugang zu privilegierten Konten; vor Entwurf und Einführung eine Risikoanalyse und eine Nutzerschulung. SHOULD: Mehrfaktor für alle Konten mit Zugang zu Ressourcen der Organisation und phishingresistente Verfahren, als Beispiele nennt der erläuternde Text FIDO2/WebAuthn, Smartcards und PKI-basierte Authentisierung. Notfallkonten (break glass accounts) sollen nach dem erläuternden Text nur im Notfall genutzt, keiner Person zugeordnet und zentral protokolliert werden; ihre Mehrfaktor-Absicherung soll außerhalb der allgemeinen Richtlinie geregelt werden.

Für die Protokollierung sind MUST: dokumentierte Protokollierungsanforderungen, Schutz der Protokolle vor Veränderung, unbefugtem Zugriff und Verlust innerhalb der Aufbewahrungsfrist, Archivierung für einen von der Stelle bestimmten Zeitraum und dokumentierte Anforderungen an die Protokollauswertung. Eine Aufbewahrung von DNS-, Proxy- und Ereignisprotokollen von mindestens zwölf Monaten und eine Überwachung, die Vorfälle zeitnah erkennt, sind SHOULD.

Kryptografie (Kapitel 17). Produkte, deren Kryptofunktionen Vertraulichkeit, Authentisierung, Nichtabstreitbarkeit oder Integrität schützen, müssen eine vom GCSB anerkannte kryptografische Evaluierung abgeschlossen haben (MUST); ausgenommen sind nach dem erläuternden Text Produkte, die mit zugelassenen Algorithmen oder Protokollen nicht eingestufte Daten schützen (17.1.31). Setzt ein nicht evaluiertes Produkt zugelassene und nicht zugelassene Algorithmen um, muss sichergestellt sein, dass nur die zugelassenen genutzt werden können; ein Produkt mit zugelassenem Protokoll darf nur zugelassene Protokolle zulassen (jeweils MUST). Für die Übertragung über unsichere Netze wie das Internet gilt: Informationen der Stufen RESTRICTED und SENSITIVE müssen mit zugelassenem Algorithmus und Protokoll verschlüsselt werden, ebenso aggregierte Daten, deren Kompromittierung erhebliche Folgen hätte; ab CONFIDENTIAL ist dafür Hochsicherheitskryptotechnik MUST (siehe unten); NZEO-Informationen müssen gespeichert und, zusätzlich zu einer etwa vorhandenen Verschlüsselung des Übertragungswegs, bei der Übertragung mit zugelassenen Verfahren geschützt werden (jeweils MUST). Nur für die übrigen Daten der Stelle ist die Verschlüsselung über unsichere Netze SHOULD. Wird Verschlüsselung eingesetzt, um Anforderungen an Speicherung oder physische Handhabung zu senken, muss ein zugelassener Algorithmus in einem Produkt mit mindestens EAL2 eingesetzt werden (MUST). Verschlüsselung senkt nach dem NZISM die Einstufung nicht. Für Schlüssel betont der erläuternde Text, dass Verschlüsselung die Kontrolle über Schlüssel und Schlüsselverwaltung voraussetzt, und unterscheidet bei Auslagerung Eigentum, Kontrolle und Besitz der Schlüssel; Kryptoperioden für alle Schlüssel festzulegen ist SHOULD, ein Schlüsselmanagementplan ist bei kommerzieller Kryptotechnik SHOULD, und seine Detailtiefe muss Kritikalität und Einstufung der geschützten Informationen entsprechen (MUST). Für TLS soll die aktuelle Version 1.3 genutzt werden (SHOULD), SSL in keiner Version (SHOULD NOT). Hochsicherheitskryptotechnik (High Assurance Cryptographic Equipment) ist für CONFIDENTIAL und höher über unsichere Netze MUST; für diesen Bereich verweist das NZISM auf Vorgaben, die nicht ausgewertet sind.

Post-Quanten-Vorbereitung (Abschnitt 2.4). Das NZISM stellt fest, dass derzeit kein Post-Quanten-Verfahren für die Nutzung nach dem NZISM zugelassen ist (2.4.8). Sobald Standards vorliegen, kann das GCSB klassische Verfahren abkündigen; die Stellen sollen sich darauf einstellen, möglicherweise in den nächsten zwei bis drei Jahren umzustellen (2.4.10). Ab welchem Datum diese Spanne läuft, sagt der Text nicht, und ein Zieljahr nennt das NZISM nicht. Bis dahin sollen die Algorithmen, Protokolle und Schlüssellängen aus Kapitel 17 gehalten oder gestärkt werden (2.4.11); eine Umstellung von RSA auf elliptische Kurven empfiehlt der erläuternde Text nicht mehr eigens, wo sie nicht schon erfolgt ist (17.1.23). Die sieben Controls in 2.4 sind sämtlich SHOULD: Entwicklung verfolgen, Datenbestände inventarisieren, die lange geschützt bleiben müssen, Systeme mit Kryptografie inventarisieren, Public-Key-abhängige Systeme in Risikobewertungen als quantenverwundbar führen, eine Reihenfolge festlegen (nach Wert, Schutzbedarf, Abhängigkeiten und Schutzdauer) und einen Übergangsplan für die Veröffentlichung des neuen Standards entwickeln.

Netze (Kapitel 18). Für jedes verwaltete Netz sind Netzdiagramme MUST. Bevor Netzdokumentation an Dritte wie Dienstleister geht, ist eine Risikobewertung MUST, und sie darf nur enthalten, was der Dritte für seine vertragliche Leistung braucht; detaillierte Konfigurationen gehören nach einer MUST-NOT-Control nicht in Ausschreibungsunterlagen. Ein deutscher Bieter erhält also bewusst wenig und sollte das nicht als Mangel der Ausschreibung lesen. Nicht genutztes IPv6 muss auf Dual-Stack-Geräten abgeschaltet sein, sofern es nicht benötigt wird; vor Einführung sind eine Risikobewertung und eine erneute Akkreditierung MUST. Vor dem Einsatz von inverse split tunnelling in VPN-Zugängen ist eine Bedrohungs- und Risikobewertung MUST. Für Funknetze stehen detaillierte Vorgaben; als Beispiel ist WPA ausgeschlossen (MUST NOT), WPA2 nicht empfohlen (SHOULD NOT) und WPA3 empfohlen (SHOULD). Eine Strategie zur Angriffserkennung ist für CONFIDENTIAL und höher MUST, sonst SHOULD.

Gateways (Kapitel 19). Alle Netze der Stelle müssen gegen Netze anderer Sicherheitsdomänen durch Gateways geschützt sein (MUST). Gateways müssen der einzige Kommunikationsweg sein, standardmäßig alles verweigern, nur ausdrücklich autorisierte Verbindungen zulassen, über einen isolierten Pfad verwaltet werden, protokollieren und in Echtzeit alarmieren, und nach jeder Konfigurationsänderung sind alle Controls auf Wirksamkeit zu testen. Ein Gateway übernimmt die höchste Einstufung der verbundenen Domänen. Vor der Inbetriebnahme ist eine Risikobewertung MUST, und alle über das Gateway verbundenen Domänen- und Systemverantwortlichen müssen das Restrisiko verstehen und akzeptieren. Unangekündigte Tests der Sicherheitsmaßnahmen in zufälligen Abständen von höchstens sechs Monaten und eine jährliche Überprüfung der Architektur sind SHOULD. Wo die Tabelle der Zusicherungsstufen beiden Seiten eine Firewall abverlangt, muss jede Seite diese Anforderung getrennt und unabhängig erfüllen, gemeinsam genutzte Geräte genügen nicht (MUST). Welche Seite was braucht, hängt von Richtung und beteiligten Netzen ab: Bei einer bidirektionalen Verbindung werden nach dem erläuternden Text beide Gateways eingerichtet, bei einer unidirektionalen genügt eines, und für die Gegenseite eines UNCLASSIFIED-Netzes wie des Internets weist die Tabelle keine Anforderung aus. Ob auf Auftragnehmerseite eine eigene Firewall verlangt ist, ergibt sich deshalb aus Verbindungsrichtung und Einstufung beider Netze nach dieser Tabelle. Cross Domain Solutions sind MUST, wenn ein Netz der Stufe CONFIDENTIAL, SECRET oder TOP SECRET mit einem anderen Netz verbunden wird. Für Sprach- und Kollaborationsdienste (Session Border Controller, Abschnitt 19.5) verlangt das NZISM als MUST unter anderem Vertragsklauseln zu Service Level, Verfügbarkeit und Wiederherstellung nach den förmlich festgelegten Geschäftsanforderungen, zu Übernahme oder Insolvenz des Anbieters und zur Vorfallbehandlung, was einen Anbieter solcher Dienste direkt betrifft.

Virtualisierung und VLAN (Abschnitte 20.2, 20.3). Virtualisierung darf nicht zur funktionalen Trennung von Servern unterschiedlicher Einstufung dienen (MUST NOT). VLANs zwischen eingestuften und nicht eingestuften Netzen und VLAN-Trunking über Sicherheitsdomänen hinweg sind MUST NOT; Administration nur aus dem vertrauenswürdigsten Netz ist MUST. Innerhalb eines einzelnen Netzes, das nach einem einzigen Sicherheitsplan betrieben wird, dürfen VLANs nach dem erläuternden Text der funktionalen Trennung dienen. Die Trennung von Produktion und Test in virtuellen Umgebungen ist SHOULD.

Datentransfers (Kapitel 21). MUST sind eine Richtlinie mit Schulung und den nötigen Freigaben, die Verantwortlichkeit der Nutzer für ihre Transfers, die Prüfung importierter Daten auf Schadcode und aktive Inhalte, Schutzvermerkprüfungen zur Beschränkung von Exporten und der Umgang mit Daten, die ein Datenfilter als verdächtig erkennt: Sie sind zu sperren, in Quarantäne zu nehmen oder zu verwerfen, bis eine vertrauenswürdige Stelle, die nicht der Urheber ist, sie geprüft und zur Übertragung freigegeben hat. Für blockierte oder in Quarantäne genommene Daten mit berechtigtem Übertragungsbedarf soll es einen Ausnahmeprozess geben (SHOULD). Verschlüsselte Inhalte sollen zur Prüfung entschlüsselt werden (SHOULD). Für CONFIDENTIAL und höher kommen unter anderem mindestens monatliche Prüfungen der Transferprotokolle und Freigaben durch vertrauenswürdige Stellen bei Transfers in Systeme niedrigerer Einstufung hinzu, für NZEO-Daten Stichwortsuche, Quarantäne und Verfahren gegen den Export.

Die Konzernfrage für deutsche Unternehmen. Ausländischer Staatsangehöriger ist nach dem Glossar jede Person ohne neuseeländische Staatsbürgerschaft. Für Systeme mit NZEO-Informationen ist privilegierter Zugang ausländischer Staatsangehöriger MUST NOT, Zugriff auf NZEO-Informationen von Systemen und Einrichtungen, die nicht allein unter der Kontrolle der neuseeländischen Regierung und neuseeländischer Staatsbürger stehen, ebenfalls MUST NOT, und Gateway-Administratoren müssen die Staatsangehörigkeitsanforderungen erfüllen. Für Systeme mit eingestuften Informationen gilt der Ausschluss privilegierten Zugangs ausländischer Staatsangehöriger als SHOULD NOT, und Zugriff von solchen Systemen soll ohne multilaterales oder bilaterales Sicherheitsabkommen unterbleiben (SHOULD NOT). Ob ein solches Abkommen mit Deutschland besteht, sagt das NZISM nicht. Wo E-Mails NZEO-Informationen tragen, dürfen sie nur an benannte Empfänger gehen.

Nur zur Einordnung: Kapitel 8 bis 11 und 13. Physische Sicherheit (Kapitel 8) behandelt Einrichtungen, Server- und Netzräume, Netzinfrastruktur, IT-Geräte und Siegel; personelle Sicherheit (Kapitel 9) Schulung, Berechtigungen und Sicherheitsüberprüfungen, Internetnutzung und Begleitung nicht überprüfter Personen; Kapitel 10 Verkabelung, Abstrahlschutz und Netzadressierung; Kapitel 11 Kommunikationsgeräte wie Bluetooth, Telefonie, Mobilfunk, tragbare Geräte, RFID und Multifunktionsgeräte; Kapitel 13 Medienhandhabung, Löschung, Vernichtung, Außerbetriebnahme und Entsorgung. Dieser Artikel wertet diese Kapitel nicht im Einzelnen aus.

Ein Hinweis zur Quelle. Querverweise im Text folgen teils einer anderen Nummerierung als die Abschnittsüberschriften derselben Fassung, etwa bei Datentransfers und Virtualisierung. Zitiert wird hier nach der Nummer der Abschnittsüberschrift.

Umsetzungsperspektive

1. Einstufung und Umfang klären. Mit dem Kunden schriftlich festhalten, welche Einstufung und welche Weitergabevermerke das System trägt und welche Technologien es nutzt; daraus folgt, welche Controls gelten und welche als MUST statt als SHOULD auftreten.
2. Abweichungen formalisieren. Jede nicht umgesetzte MUST-Control mit Begründung für die Accreditation Authority, jede nicht umgesetzte SHOULD-Control mit dokumentierter Abwägung führen (nzism-002).
3. Standardumgebung festlegen. Je Plattform Spezifikation und Standardkonfiguration bestimmen, Installationsrechte der Nutzer sperren, Patchstand nachweisbar halten und über Allow Listing entscheiden.
4. Zugang ordnen. Persönliche Administrationskonten, Richtlinie für privilegierten Zugang mit Inventar und Überwachung, Mehrfaktor nach den MUST-Lagen, phishingresistente Verfahren planen, Notfallkonten eigens regeln.
5. Protokollierung definieren. Anforderungen, Schutz, Aufbewahrungsdauer und Auswertung festlegen und die Aufbewahrungsdauer mit dem Kunden abstimmen.
6. Kryptografie inventarisieren. Eingesetzte Produkte, Verfahren und Schlüssellängen erfassen, die Evaluierungsfrage je Produkt klären, Schlüsselkontrolle bei Auslagerung regeln und die beiden Post-Quanten-Inventare anlegen.
7. Netz- und Domänengrenzen kartieren. Netzdiagramme pflegen, Gateways an jeder Domänengrenze vorsehen, je Verbindung klären, welche Seite welche Firewall-Anforderung trägt, unangekündigte Tests in zufälligen Abständen und das jährliche Architekturreview einplanen.
8. Transferwege festlegen. Für jeden Weg hinein und hinaus Prüfung, Behandlung verdächtiger Daten (Sperren, Quarantäne oder Verwerfen), Freigabe und Protokollierung bestimmen.
9. Konzernzugriffe prüfen. Für jedes System klären, ob NZEO-Informationen oder eingestufte Informationen vorkommen, und die Zugriffsfrage für nicht neuseeländische Mitarbeitende mit dem Kunden vor Vertragsschluss beantworten.

Typische Fehler

1. Alle Controls werden als gleich verbindlich behandelt, oder nur die MUST-Controls werden gelesen, ohne den Einstufungsbereich zu prüfen.
2. Controls für nicht genutzte Technologien werden mitgeschleppt, oder umgekehrt fehlen Controls, weil eine Technologie wie IPv6 still aktiv ist.
3. Mehrfaktor per SMS- oder E-Mail-Code gilt als ausreichend; Notfallkonten sind nicht geregelt.
4. Administratoren arbeiten mit gemeinsamen oder dauerhaft privilegierten Konten.
5. Kryptoprodukte werden ohne Klärung der Evaluierungsfrage beschafft, und die Schlüsselkontrolle liegt bei Auslagerung faktisch beim Anbieter.
6. Die Post-Quanten-Vorbereitung wird verschoben, weil das NZISM noch kein Verfahren zulässt, obwohl die empfohlenen Inventare davon unabhängig sind.
7. Die Firewall-Anforderungen an der Verbindung zum Kundennetz werden nicht nach Verbindungsrichtung und Einstufung beider Netze bestimmt: Verlangt die Tabelle der Zusicherungsstufen auch auf Auftragnehmerseite eine Firewall, fehlt sie dort, oder beide Seiten teilen sich ein Gerät, obwohl jede Seite ihre Anforderung unabhängig erfüllen muss.
8. Die deutsche Konzern-IT administriert Systeme mit NZEO- oder eingestuften Informationen, ohne dass die Staatsangehörigkeitsfrage geklärt ist.

Risiken und Trade-offs

Dass viele Pflichten nur ab CONFIDENTIAL gelten und für alle Einstufungen oft nur eine SHOULD-Control im selben Absatz steht, eröffnet Spielraum unterhalb von CONFIDENTIAL. Wer ihn nutzt, braucht eine dokumentierte Abwägung, die der Kunde mitträgt; wer ihn nicht nutzt, zahlt mit Betriebsaufwand. Vertraglich kann der Kunde jede SHOULD-Control zur Pflicht machen, und dann hilft der Verweis auf die Empfehlungsform nicht.

Phishingresistente Mehrfaktor-Authentisierung kann nach dem NZISM zusätzliche Infrastruktur verlangen und Zeit und Geld kosten; dafür schützt sie gegen die Angriffsart, die das NZISM als häufigsten Weg zum Diebstahl von Zugangsdaten beschreibt.

Bei der Post-Quanten-Vorbereitung steht frühe Inventur gegen spätere Hektik. Weil das NZISM weder ein Verfahren zulässt noch ein Zieljahr nennt, ist eine vorzeitige Festlegung auf ein Verfahren riskant; die Inventare dagegen behalten ihren Wert unabhängig davon, welches Verfahren später zugelassen wird.

Bei der Konzern-IT steht Effizienz gegen Zugriffsbeschränkung. Zentrale Administration aus Deutschland ist billiger; wo NZEO-Informationen oder eingestufte Informationen vorkommen, kann eine Administration durch neuseeländische Staatsbürger aus neuseeländisch kontrollierten Systemen nötig werden.

Entscheidungspunkte

• Welche Einstufung trägt das System, und welche Controls gelten danach als MUST?
• Welche SHOULD-Controls setzen wir nicht um, und trägt der Kunde die dokumentierte Abwägung mit?
• Bis wann stellen wir Fernzugriff, privilegierte Konten und Cloud-Zugänge auf Mehrfaktor um, und ab wann phishingresistent?
• Wer verantwortet die Post-Quanten-Inventare und den Übergangsplan?
• Wo verlaufen unsere Domänengrenzen zum Kundennetz, und wer betreibt welche Firewall?
• Dürfen nicht neuseeländische Mitarbeitende das System administrieren, und welche Antwort hat der Kunde dazu gegeben?

Praktische Empfehlungen

• Eine Geltungstabelle je System führen: Einstufung, genutzte Technologien, geltende Abschnitte und Abweichungen mit Begründung, ohne Control-Texte abzuschreiben.
• Den Zugangsplan mit Mehrfaktor, privilegiertem Zugang und Notfallkonten als ein Dokument führen, weil das NZISM diese Themen aufeinander verweisen lässt.
• Die Kryptografie-Inventur mit der Beschaffung verbinden und je Produkt die Evaluierungsfrage, die Schlüsselkontrolle und die Post-Quanten-Fähigkeit erfragen.
• Netzdokumentation für den Kunden nach dem Bedarf-zu-wissen-Prinzip strukturieren, weil die Regierungsstelle Dritten nur das Nötige geben darf.
• Gateway-Tests unangekündigt und in zufälligen Abständen von höchstens sechs Monaten durchführen, wie es das NZISM empfiehlt, und nur das jährliche Architekturreview fest in den Revisionskalender aufnehmen.
• Die Staatsangehörigkeits- und Kontrollfrage vor Vertragsschluss klären und für Einzelheiten neuseeländische Beratung und den Kunden einbeziehen.
• Für Konfigurationsdetails, Tabellen zu Zusicherungsstufen und zugelassene Verfahren die jeweils aktuelle Fassung des NZISM heranziehen; das NZISM verlangt selbst, dass Systementwürfe für eigene und ausgelagerte Projekte nach der neuesten Fassung erfolgen (1.2.15).

Relevante Normreferenzen

• NZISM 3.9 (November 2025), Abschnitt 2.4 (Preparation for Post-Quantum Cryptography).
• Ebenda, Kapitel 14 Software security (14.1 Standard Operating Environments, 14.2 Application Allow listing, 14.3 Web Applications, 14.4 Software Application Development, 14.5 Web Application Development).
• Ebenda, Kapitel 15 Email security (15.1, 15.2).
• Ebenda, Kapitel 16 Authentication and Access Controls (16.1 bis 16.7, insbesondere 16.4 Privileged Access Management, 16.6 Event Monitoring, Logging and Auditing, 16.7 Multi-Factor Authentication).
• Ebenda, Kapitel 17 Cryptography (17.1 Cryptographic Fundamentals, 17.2 und 17.3 zugelassene Algorithmen und Protokolle, 17.4 Transport Layer Security, 17.9 Key Management).
• Ebenda, Kapitel 18 Network security, Kapitel 19 Gateway security, Abschnitte 20.2 Virtualisation und 20.3 Virtual Local Area Networks, Kapitel 21 Data management (21.1 bis 21.4).
• Ebenda, 1.1.4 bis 1.1.6 und 1.1.41 bis 1.1.49 (Einstufungsbereich, Umfang, Verbindlichkeit), 2.2.5 (Auftragnehmer), Glossar in Kapitel 24; Kapitel 8 bis 11 und 13 nur zur Einordnung.
• Abgrenzung: Das australische Gegenstück, ISM und Essential Eight des ASD, steht im Track ism-australien, hier ohne Vergleich der Controls; NIST-Kontrollkataloge und Rahmenwerke stehen im nist-Track, hier keine Zuordnung; IT-Grundschutz steht im it-grundschutz-Track, hier keine Gegenüberstellung von Bausteinen; die CIS Controls stehen im cis-Track, hier keine Safeguard-Zuordnung. Innerhalb dieses Tracks: Überblick in nzism-001, Betroffenheit und Abweichungsverfahren in nzism-002, Rollen und Akkreditierung in nzism-003, Betrieb und Vorfälle in nzism-004, Cloud und Auslagerung in nzism-005.