Technische ISM-Leitlinien auf Managementebene: Härtung, Zugang und Mehrfaktor, Kryptografie, Netze und Gateways, Datentransfers

Problem in der Praxis

Das erste Muster ist die Delegation ohne Entscheidung. Die technischen Leitlinien werden an den Betrieb gegeben, und niemand entscheidet, welche Abweichungen akzeptiert sind. Im Bewertungsgespräch zeigt sich dann eine Sammlung stillschweigender Ausnahmen, für die es weder einen Ausgleich noch eine Risikoakzeptanz gibt. Das ISM ordnet die Genehmigung der Kontrollauswahl dem authorising officer zu (ism-australien-003); ohne dokumentierte Entscheidung gibt es nichts zu genehmigen.

Das zweite ist die Mehrfaktor-Illusion. Ein Unternehmen hat Mehrfaktor-Authentisierung eingeführt und hält das Zugangsthema für erledigt. Das ISM unterscheidet aber zwischen Faktoren: Codes per SMS, Sprachanruf oder E-Mail und Biometrie bezeichnet es als anfälliger, E-Mail schließt eine Kontrolle für Out-of-band-Authentisierung ganz aus, für eingesetzte Mehrfaktor-Authentisierung menschlicher Nutzer von Online-Diensten, Systemen und Datenablagen sehen die Kontrollen ausdrücklich phishingresistente Verfahren vor, und es weist darauf hin, dass Angreifer nach der Anmeldung die entstandenen Authentisierungsartefakte wie Sitzungs- und Aktualisierungstoken stehlen und wiederverwenden, um auch Mehrfaktor-Authentisierung zu umgehen.

Das dritte ist der Kryptografie-Bestandsschutz. Beschaffungen mit langer Laufzeit werden nach heutigem Zulassungsstand bewertet. Das ISM kündigt aber an, dass klassische asymmetrische Verfahren wie RSA und die Diffie-Hellman-Varianten wegen erwarteter Fortschritte im Quantencomputing über 2030 hinaus nicht zugelassen werden, und dass auch einzelne heute zugelassene Parametergrößen symmetrischer und Hash-Verfahren aus Gründen der Interoperabilität und Wartbarkeit über 2030 hinaus entfallen.

Das vierte ist die Konzern-IT als blinder Fleck. Eine deutsche Zentrale administriert die australischen Systeme mit, und niemand hat geprüft, ob für die betroffenen Systeme Staatsangehörigkeits- oder Überprüfungsanforderungen bestehen.

CISO-Einordnung

Härtung: Grundlinie wählen, Abweichungen verantworten. Die "Guidelines for system hardening" behandeln Betriebssysteme, Nutzeranwendungen, Serveranwendungen und Virtualisierung. Die Leitgedanken auf Managementebene: Bei der Auswahl Anbieter bevorzugen, die sich nachweislich zu Secure by Design und Secure by Default bekennen, einschließlich speichersicherer Programmiersprachen oder, weniger bevorzugt, speichersicherer Programmierpraktiken. Ältere und vor allem nicht mehr unterstützte Versionen setzen nach dem ISM Schwachstellen aus, die längst behoben sind. Arbeitsplätze und Server sollen aus einer zentral verwalteten Standardumgebung (standard operating environment) kommen; wird sie von Dritten bezogen, soll sie von vertrauenswürdigen Dritten stammen und auf Schadcode und schädliche Konfigurationen geprüft werden. Härtungsvorgaben veröffentlichen ASD und Hersteller; widersprechen sie sich, soll nach dem ISM die restriktivste umgesetzt werden. Dazu kommen Anwendungskontrolle (nur genehmigte Programme laufen), verhaltensbasierte Erkennung auf Arbeitsplätzen, kritischen und hochwertigen Servern, die besondere Absicherung von Verzeichnisdiensten wie Microsoft Active Directory, die das ISM wegen ihrer Schlüsselrolle für Identitäten hervorhebt, und bei Virtualisierung zusätzliche Kontrollen, weil eine Schwachstelle im Isolationsmechanismus andere Umgebungen auf derselben Hardware gefährden kann. Für den CISO heißt das: Er legt fest, welche Härtungsvorgabe je Plattform gilt, wer Abweichungen genehmigt und wie sie ausgeglichen werden.

Zugang: Identität, Privileg, Mehrfaktor. Die "Guidelines for system access" verlangen eindeutige Identifizierbarkeit, damit Handlungen zugeordnet werden können, und wenden die Kontrollen für Identifizierung, Authentisierung, Autorisierung und Überwachung ausdrücklich auch auf nicht menschliche Nutzer an, etwa Dienste, Anwendungen, Workloads und KI-Agenten. Für KI-Agenten sieht das ISM eine eigene Identität je Agent und ein Register der Agenten vor. Zugang soll auf das für die Aufgabe Erforderliche begrenzt sein. Privilegierte Konten, also solche, die Sicherheitskontrollen ändern oder umgehen können, sollen keinen Zugang zu Internet, E-Mail und Webdiensten haben; sind sie ausdrücklich dafür autorisiert, ist dieser Zugang strikt auf das Erforderliche zu begrenzen. Notfallkonten (break glass accounts) sollen nur für bestimmte autorisierte Tätigkeiten genutzt, besonders geschützt und überwacht werden. Mehrfaktor-Authentisierung hält das ISM im erläuternden Text für Nutzer von Online-Diensten, privilegierte Nutzer und Nutzer mit Zugang zu Datenablagen für besonders wichtig, und bewertet SMS-, Sprach- und E-Mail-Codes sowie Biometrie als anfälliger. Die Kontrollen unterscheiden nach Anwendungsfall: Mehrfaktor-Authentisierung sehen sie für menschliche Nutzer vor, und zwar bei eigenen und fremden Online-Diensten, die sensible Daten der Organisation verarbeiten (bei fremden Online-Diensten mit nicht sensiblen Daten nur, soweit verfügbar), bei eigenen und fremden Online-Kundendiensten mit sensiblen Kundendaten, als privilegierte und unprivilegierte menschliche Nutzer von Systemen und als menschliche Nutzer von Datenablagen; gesondert sehen sie Mehrfaktor-Authentisierung für Kunden von Online-Kundendiensten mit sensiblen Kundendaten vor; können Systeme keine Mehrfaktor-Authentisierung, ist ersatzweise Ein-Faktor-Authentisierung mit Passwörtern vorgesehen. Davon getrennt die Anforderungen an eingesetzte Mehrfaktor-Authentisierung: Für menschliche Nutzer von Online-Diensten, Systemen und Datenablagen soll sie phishingresistent sein, für Kunden von Online-Kundendiensten unterscheiden die Kontrollen nach Essential-Eight-Reifegrad: eine phishingresistente Option bei der mit ML2 markierten Kontrolle, phishingresistente Mehrfaktor-Authentisierung selbst bei der mit ML3 markierten, und E-Mail ist für Out-of-band-Authentisierung ausgeschlossen. Mehrere dieser Kontrollen sind an bestimmte Essential-Eight-Reifegrade gebunden. Zugriffsentscheidungen sollen sich nicht allein auf die Vorlage von Anmeldedaten stützen, sondern Kontextsignale wie Gerätezustand, Authentisierungsstärke, Privilegstufe und Nutzerverhalten einbeziehen; der Anmeldeort ist nach dem ISM für sich allein ein schwaches Signal. Ergänzend gehören nach den "Guidelines for system management" getrennte privilegierte Arbeitsumgebungen und eine von der übrigen Umgebung getrennte Administrationsinfrastruktur zum sicheren Administrieren. Welche Zugangs- und Mehrfaktor-Kontrollen zu welchem Reifegrad gehören, behandelt ism-australien-004. Viele Mehrfaktor-Kontrollen tragen in dieser Ausgabe den Aktualisierungsvermerk September 2026; wer gegen eine ältere Fassung umgesetzt hat, sollte sie abgleichen.

Kryptografie: zugelassene Verfahren und ein Plan für 2030. Die "Guidelines for cryptography" verlangen ASD-zugelassene Algorithmen (ASD-Approved Cryptographic Algorithms) und Protokolle (ASD-Approved Cryptographic Protocols) für ruhende und übertragene Daten und bevorzugen es, nicht zugelassene Verfahren technisch abzuschalten, statt ihren Gebrauch nur per Richtlinie zu untersagen. Das ISM betont, dass Verschlüsselung die Schutzbedürftigkeit oder Einstufung von Daten nicht senkt, sondern nur die unmittelbaren Folgen eines Zugriffs mindert. Für das Schlüsselmanagement verlangt es entwickelte, umgesetzte und gepflegte Prozesse und Verfahren. Für die Implementierungsgüte nennt es eine Rangfolge von Evaluierungswegen, an deren Spitze eine Common-Criteria-Evaluierung gegen ein von ASD anerkanntes Schutzprofil steht; für bestimmte Verschlüsselungszwecke bei OFFICIAL: Sensitive und PROTECTED sieht es Produkte mit einer solchen Evaluierung vor, für SECRET und TOP SECRET Hochsicherheitskryptogeräte (High Assurance Cryptographic Equipment). Gibt es kein geeignetes Common-Criteria-evaluiertes Produkt, darf nach dem erläuternden Text ein anderes Produkt eingesetzt werden, das die ASD-zugelassenen Algorithmen und Protokolle sicher umsetzt, wobei Lieferkettenrisiken weiter zu berücksichtigen sind und das ISM dafür Auswahlmerkmale des Lieferanten nennt; wie sich dieser Ausweichweg zu den Kontrollen für OFFICIAL: Sensitive und PROTECTED verhält, sagt der Text nicht ausdrücklich. Für Transport Layer Security soll nach dem ISM nur die neueste Version eingesetzt werden, derzeit TLS 1.3. Für die Planung entscheidend ist der Übergang zur Post-Quanten-Kryptografie: Neue Geräte, Anwendungen und Bibliotheken, die über 2030 hinaus genutzt werden sollen, sollen mit dem Ziel entwickelt oder beschafft werden, bis 2030 ASD-zugelassene Post-Quanten-Verfahren zu unterstützen. Maßgeblich sind dabei die über 2030 hinaus zugelassenen Varianten: Auch bei den heute zugelassenen Post-Quanten-Verfahren entfällt nach 2030 jeweils die schwächere zugelassene Parameterstufe, und für neue Komponenten mit Nutzung über 2030 nennt das ISM bei Hash- und symmetrischen Verfahren SHA-384, SHA-512 und AES-256. Hybride Verfahren aus klassischem und Post-Quanten-Algorithmus empfiehlt das ISM nicht, verbietet sie aber nicht; werden sie eingesetzt, soll mindestens einer der beiden Algorithmen ASD-zugelassen sein. Wird Kryptotechnik oder Schlüsselmaterial kompromittiert oder besteht der Verdacht, soll das so bald wie möglich dem CISO oder einem Delegierten gemeldet und das Schlüsselmaterial gewechselt werden. Die Grundprinzipien (Abschnitt "Cyber security principles") verlangen zudem kryptografische Agilität, also Systeme, die geordnete Wechsel der Kryptografie einschließlich Post-Quanten-Verfahren erlauben.

Netze: Segmentierung und Dokumentation. Die "Guidelines for networking" bezeichnen Netzsegmentierung und Netztrennung als eine der wirksamsten Kontrollen gegen die Ausbreitung von Angreifern nach dem Erstzugang; die Administrationsinfrastruktur soll vom übrigen Netz getrennt sein. Verwaltungsschnittstellen sollen nicht direkt aus dem Internet erreichbar sein; wo das nicht geht, sind alternative Schutzmaßnahmen nötig. Alle Daten, die über Netzinfrastruktur laufen, sollen nach dem ISM geeignet verschlüsselt sein, auch innerhalb sicherer Bereiche. Netzdokumentation soll genau und hinreichend detailliert sein und ihrerseits geschützt werden, weil sie Angreifern hilft. Dazu kommen Integrität und Härtung von Netzgeräten, protective DNS (Sperrung bekannter Schaddomänen) und bei IPv6 eine dem IPv4-Schutz gleichwertige Abdeckung.

Gateways: jede Domänengrenze ist eine Kontrollstelle. Die "Guidelines for gateways" sehen Gateways nicht nur zwischen eigenen Netzen und öffentlicher Infrastruktur vor, sondern auch zwischen eigenen Netzen unterschiedlicher Sicherheitsdomänen und zu Netzen anderer Organisationen, die auf anderem Weg verbunden sind. Ein Gateway übernimmt die höchste Schutzstufe der angeschlossenen Domänen. Erlaubt sein sollen nur ausdrücklich autorisierte Datenflüsse; Dienste für Externe gehören in eine demilitarisierte Zone. Administriert wird über einen von allen angeschlossenen Netzen isolierten Pfad, nach geringsten Rechten und Funktionstrennung, und die Administratoren sollen je nach Schutzstufe Staatsangehörigkeitsanforderungen erfüllen, eine Personalüberprüfung durchlaufen und gegebenenfalls eine Sicherheitsüberprüfung haben. Für die Nachweisführung wichtig: Gateways sollen nach Konfigurationsänderungen und in Abständen von höchstens sechs Monaten getestet werden, und für Gateways der Stufen NC, OS, P und S sieht das ISM eine IRAP-Bewertung mindestens alle 24 Monate vor (für TS eine Bewertung durch ASD). Bei Verbindungen zwischen den Netzen zweier Organisationen sollen beide eigene Firewalls betreiben, außer die gemeinsame Infrastruktur dient nur als Transportweg und der gesamte Verkehr ist verschlüsselt. Für Webverkehr sieht das ISM TLS-Inspektion vor, lässt aber zu, einzelnen Verkehr wie Online-Banking zum Schutz der Privatsphäre auszunehmen, und hält eine Liste erlaubter Domänen für sicherer als eine Sperrliste. Inhaltsfilter sollen verschlüsselte Dateien zur Prüfung entschlüsseln. Cross Domain Solutions sind für Verbindungen zwischen SECRET- oder TOP-SECRET-Netzen und anderen Netzen anderer Sicherheitsdomänen vorgesehen, also sobald mindestens eine beteiligte Domäne SECRET oder TOP SECRET ist, auch wenn die andere niedriger eingestuft ist; für typische Unternehmenslagen ohne solche Netze sind sie nicht einschlägig.

Datentransfers: Verantwortung und Spur. Die "Guidelines for data transfers" verlangen Prozesse und Verfahren für Datentransfers, machen Nutzer für ihre Transfers verantwortlich und sehen vor, manuell eingeführte Daten auf Schadcode und aktive Inhalte zu prüfen, manuell ausgeführte Daten auf ungeeignete Schutzvermerke zu prüfen, bei fehlgeschlagener Prüfung in beiden Richtungen die Daten in Quarantäne zu nehmen und alle Transfers zu protokollieren, gleich ob über Wechseldatenträger, Gateways oder Cross Domain Solutions, idealerweise mit wer freigegeben hat, was, woher und wohin, wann, warum und wie übertragen wurde. Protokollieren allein genügt nicht: Die Transferprotokolle sollen mindestens monatlich teilweise überprüft werden, bei SECRET- und TOP-SECRET-Systemen mindestens monatlich vollständig. Für Exporte aus SECRET- und TOP-SECRET-Systemen kommen hinzu: vorherige Prüfung und Freigabe durch eine vertrauenswürdige Stelle, etwa den CISO oder einen Delegierten, wobei als vertrauenswürdige Stellen nur Personen und Systeme gelten, die der CISO als solche geprüft und autorisiert hat; digitale Signatur der freigegebenen Daten durch diese Stelle; und bei manuellen Exporten die Prüfung der Signaturen sowie eine Stichwortprüfung aller Textdaten. Für AUSTEO-, AGAO- und REL-Daten sollen zusätzliche Prozesse verhindern, dass sie in ungeeignete ausländische Systeme gelangen; die zugehörige Kontrolle trägt ebenfalls nur S und TS.

Die Konzernfrage für deutsche Unternehmen. Das ISM verlangt für Systeme mit AUSTEO- und AGAO-Daten, dass ihre Steuerung bei australischen Staatsangehörigen liegt, die für oder im Auftrag der australischen Regierung arbeiten, und dass AUSTEO- und AGAO-Daten nur von Systemen zugänglich sind, die allein unter der Kontrolle der australischen Regierung stehen und sich in von ihr autorisierten Einrichtungen befinden; australische Staatsangehörigkeit oder eine Administration in Australien genügt dafür also nicht. Zudem empfiehlt es nachdrücklich, ausländischen Staatsangehörigen keinen privilegierten Zugang zu Systemen mit AUSTEO-, AGAO- oder REL-Daten zu geben; die zugehörigen Kontrollen tragen nur die Markierungen S und TS. Unabhängig davon sollen Gateway-Administratoren je nach Schutzstufe des Gateways etwaige Staatsangehörigkeitsanforderungen erfüllen, eine Personalüberprüfung durchlaufen und, wo nötig, eine Sicherheitsüberprüfung haben. Wo das ISM von Sicherheitsüberprüfungen spricht, schließt es in den Zugangsleitlinien auch Überprüfungen ausländischer Regierungen ein, die Australien förmlich anerkennt; ob und für welche Stufen das für deutsche Überprüfungen gilt, steht nicht im Snapshot. Für Zugang zu Regierungsressourcen und erforderliche Überprüfungen verweist das ISM auf das Protective Security Policy Framework, das hier nicht ausgewertet ist.

Umsetzungsperspektive

1. Grundlinien festlegen. Je Plattform bestimmen, welche Härtungsvorgabe gilt, und die Regel des ISM übernehmen, bei Widerspruch zwischen ASD und Hersteller die restriktivere umzusetzen.
2. Abweichungen formalisieren. Jede Abweichung mit Begründung, Ausgleichsmaßnahme, Risikoakzeptanz und Ablaufdatum führen und in den Annex des Systemsicherheitsplans übernehmen (ism-australien-003).
3. Identitäten vollständig erfassen. Menschliche, technische und KI-Identitäten mit Eigentümer, Zweck und Rechten registrieren; privilegierte Konten von Internet, E-Mail und Web trennen oder die ausdrückliche Autorisierung dokumentieren.
4. Mehrfaktor nach Stärke staffeln. Für menschliche Nutzer von Online-Diensten, Systemen und Datenablagen phishingresistente Verfahren planen, wie es die Kontrollen für eingesetzte Mehrfaktor-Authentisierung vorsehen, Systeme ohne Mehrfaktor-Unterstützung mit ihrer Passwort-Ersatzlösung erfassen und den Schutz der Sitzungstoken mitdenken.
5. Kryptografie inventarisieren. Eingesetzte Algorithmen, Protokolle und Schlüssellängen erfassen, nicht zugelassene Verfahren abschalten und einen Übergangsplan zur Post-Quanten-Kryptografie mit dem Zielpunkt 2030 aufstellen; Beschaffungen mit Laufzeit über 2030 daran messen.
6. Domänengrenzen kartieren. Alle Übergänge zwischen Sicherheitsdomänen und zu fremden Netzen erfassen, dort Gateways mit ausdrücklich erlaubten Datenflüssen vorsehen und Test- und Bewertungstermine einplanen.
7. Transferwege festlegen. Für jeden Weg, über den Daten in Systeme für australische Kunden hinein oder heraus gelangen, Prozess, Prüfung, Quarantäne und Protokollierung bestimmen.
8. Konzernzugriffe prüfen. Für jedes System mit australischem Kundenbezug klären, ob Weitergabevermerke oder Schutzstufen gelten, die Staatsangehörigkeits- oder Überprüfungsanforderungen auslösen, und die Antwort mit dem Kunden abstimmen.

Typische Fehler

1. Die technischen Leitlinien werden an den Betrieb delegiert, ohne dass jemand Abweichungen genehmigt oder ausgleicht.
2. Hersteller-Härtungsvorgaben werden übernommen, obwohl die Vorgabe des ASD restriktiver ist.
3. Nicht menschliche Identitäten, insbesondere KI-Agenten und Dienstkonten, fehlen in der Identitätsverwaltung.
4. Privilegierte Konten werden auch für E-Mail und Web genutzt, ohne ausdrückliche und begrenzte Autorisierung.
5. Mehrfaktor-Authentisierung per SMS oder E-Mail gilt als ausreichend, und gestohlene Sitzungstoken werden nicht betrachtet.
6. Beschaffungen mit langer Laufzeit berücksichtigen nicht, dass das ISM mehrere klassische Verfahren über 2030 hinaus nicht mehr zulässt.
7. Gateways existieren nur zum Internet, nicht zwischen internen Netzen unterschiedlicher Sicherheitsdomänen (auch bei gleicher Einstufung) oder zu Partnernetzen.
8. Gateway-Tests und Bewertungen sind nicht terminiert, sodass der Nachweis im Bewertungsgespräch fehlt.
9. Die deutsche Konzern-IT administriert australische Systeme, ohne dass Staatsangehörigkeits- und Überprüfungsfragen geklärt sind.

Risiken und Trade-offs

Strenge Härtung und Anwendungskontrolle senken das Risiko deutlich, kosten aber Betriebsaufwand und Ausnahmeverwaltung. Wer die restriktivere Vorgabe umsetzt, muss mit Inkompatibilitäten rechnen; wer sie nicht umsetzt, braucht mindestens eine dokumentierte, vom authorising officer getragene Entscheidung. Ob eine Abweichung zulässig ist, entscheidet aber nicht die Dokumentation: Schreibt ein Vertrag, eine verbindliche Anordnung oder eine gesetzliche Pflicht die Kontrolle vor, macht eine dokumentierte Abweichung die Nichtbefolgung nicht zulässig. Unzulässig ist in jedem Fall das Schweigen.

Phishingresistente Mehrfaktor-Authentisierung und gebundene Sitzungstoken verlangen Hardware oder moderne Plattformen und Nutzerschulung. Der Gewinn ist der Schutz gegen genau die Angriffsart, die das ISM als Umgehungsweg herausstellt.

Der Übergang zur Post-Quanten-Kryptografie ist ein Beschaffungs- und Architekturthema mit langem Vorlauf. Frühe Umstellung bindet Mittel bei noch reifenden Implementierungen; späte Umstellung riskiert, dass Systeme nach 2030 mit nicht mehr zugelassenen Verfahren laufen. Hybride Verfahren erscheinen als Kompromiss; das ISM empfiehlt sie nicht, verlangt bei ihrem Einsatz mindestens einen ASD-zugelassenen Algorithmus, nennt als Nachteile höhere Komplexität und Mehraufwand und weist darauf hin, dass ihre Sicherheit bei Existenz eines kryptografisch relevanten Quantencomputers auf die des Post-Quanten-Verfahrens zurückfällt.

Bei der Konzern-IT steht Effizienz gegen Zugriffsbeschränkung. Eine zentrale Administration aus Deutschland ist billiger; wo Weitergabevermerke oder Schutzstufen Staatsangehörigkeitsanforderungen auslösen, kann eine lokale Administration in Australien nötig werden.

Entscheidungspunkte

• Welche Härtungsvorgabe gilt je Plattform, und wer genehmigt Abweichungen mit welchem Ausgleich?
• Erfassen wir nicht menschliche Identitäten einschließlich KI-Agenten vollständig, und wer verantwortet das Register?
• Bis wann stellen wir Online-Dienste, Systemzugänge und Datenablagen auf phishingresistente Mehrfaktor-Authentisierung um?
• Welcher Übergangsplan zur Post-Quanten-Kryptografie gilt, und wie fließt er in laufende Beschaffungen ein?
• Wo verlaufen unsere Sicherheitsdomänengrenzen, und sind Gateway-Tests und Bewertungen terminiert und budgetiert?
• Darf die deutsche Konzern-IT die Systeme für australische Kunden administrieren, und welche Antwort hat der Kunde dazu gegeben?

Praktische Empfehlungen

• Ein Abweichungsregister je System führen, das Kontrolle, Begründung, Ausgleich, Akzeptanz durch den authorising officer und Ablaufdatum enthält, ohne Kontrolltexte abzuschreiben.
• Für Verzeichnisdienste und Identitätsplattformen einen eigenen Schutzplan führen, weil das ISM sie als besonders kritisch heraushebt.
• Die Kryptografie-Inventur mit der Beschaffung verbinden: Jede neue Komponente mit Laufzeit über 2030 nach ihrer Fähigkeit zu ASD-zugelassenen Post-Quanten-Verfahren fragen.
• Gateway-Tests nach jeder Konfigurationsänderung und im Halbjahresrhythmus sowie die Bewertung im Zweijahresrhythmus in den Revisionskalender aufnehmen.
• Datentransfers so protokollieren, dass wer, was, woher, wohin, wann, warum und wie nachvollziehbar sind, und die Protokolle mindestens monatlich überprüfen, bei SECRET- und TOP-SECRET-Systemen vollständig.
• Die Staatsangehörigkeits- und Überprüfungsfrage für Konzernzugriffe vor Vertragsschluss mit dem Kunden klären und für Einzelheiten australische Beratung einbeziehen.
• Für Konfigurationsdetails die aktuelle Ausgabe des ISM und die dort genannten ASD-Härtungspublikationen heranziehen; dieser Artikel ersetzt sie nicht.

Relevante Normreferenzen

• ASD, Information Security Manual, Ausgabe September 2026: "Guidelines for system hardening" (Operating system hardening, User application hardening, Server application hardening, Virtualisation hardening).
• Ebenda, "Guidelines for system access" (Identity and access management, Credential management) und "Guidelines for system management", Abschnitt System administration.
• Ebenda, "Guidelines for cryptography" (Cryptographic fundamentals, Cryptographic algorithms mit dem Übergang zur Post-Quanten-Kryptografie, Cryptographic protocols, Transport Layer Security).
• Ebenda, "Guidelines for networking", Abschnitt Network design and configuration, und "Guidelines for gateways" (Gateways, Cross domain solutions, Firewalls, Web content filters, Content filtering).
• Ebenda, "Guidelines for data transfers".
• Ebenda, "Cyber security principles" (kryptografische Agilität, Segmentierung, Identitäts- und Zugriffsmanagement auf Prinzipienebene) und "Using the cyber security framework" (Anwendbarkeitsmarkierungen).
• Abgrenzung: NIST-Kontrollkataloge und das Risk Management Framework stehen im nist-Track, hier keine Zuordnung von ISM-Kontrollen zu NIST; ISO/IEC 27001 steht im Track core-iso27001, und dieser Artikel behauptet keine Gleichwertigkeit; 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: Risikomanagement, Systemsicherheitsplan und Freigabe in ism-australien-003, Essential Eight und Reifegrade in ism-australien-004, Vorfälle, Beschaffung, Cloud und Lieferkette in ism-australien-005.