STOP.LI / MOTION SYSTEM
FRAMEWORKS WERDEN ENTSCHEIDBAR

Der Navigator ordnet Standards nach Zweck, Entscheidungslage und benötigtem Arbeitsobjekt.

01 SIGNAL 02 PROCESS 03 DECISION
STOP.LI · Werkzeuge für Entscheidungen

Wann nutze ich was?

Kein Framework deckt alle Aufgaben der Informationssicherheit ab. Der Navigator ordnet zehn etablierte Ansätze danach, welche konkrete Frage sie beantworten und welche Aufgaben sie nicht abdecken.

Beginnen Sie mit der Entscheidung, die ansteht – nicht mit der Suche nach dem vermeintlich besten Framework.

Zuerst sauber trennen

Mehr Frameworks machen noch keine bessere Security.

Mappings, Reifegradwerte und Massnahmenlisten helfen nur, wenn Zweck und Verantwortung geklärt sind. Führungsrahmen, Normen, Kontrollsätze, Angreifermodelle und regulatorische Pflichten erfüllen unterschiedliche Aufgaben und dürfen nicht gleichgesetzt werden.

01

Führungsrahmen

Ordnet Ziele, Risiko und Verantwortung.

02

Managementsystem

Verankert Verantwortung, Risikobehandlung, Prüfung und Verbesserung.

03

Kontrollsatz

Priorisiert konkrete Sicherheitsmassnahmen.

04

Angreifermodell

Strukturiert Angreiferverhalten, Telemetrie und Detection.

05

Umsetzungstiefe

Beschreibt Kontrollen und Architektur detailliert.

06

Verpflichtung

Bestimmt Geltung, Frist, Empfänger und Nachweis.

Schnellwahl

Welche Frage hält Sie gerade auf?

Wählen Sie die Frage, die Sie als Nächstes entscheiden müssen. Die Route führt zum passenden Framework und nennt nur dort eine Ergänzung, wo für Umsetzung oder Nachweis etwas fehlt.

Zehn Werkzeuge · unterschiedliche Aufgaben

Das richtige Werkzeug für die nächste Entscheidung.

Wählen Sie ein Werkzeug nur für die Aufgabe, die es tatsächlich abdeckt. Offene Anforderungen müssen mit einem passenden Standard oder einer konkreten Kontrolle ergänzt werden.

01 · Führungsrahmen

NIST Cybersecurity Framework 2.0

Wann?
Wenn Management, Security und IT ein gemeinsames Zielbild und eine verständliche Sprache für Cyberrisiken brauchen.
Stark für
Governance, Zielprofile, Verantwortung und die Verbindung von Govern, Identify, Protect, Detect, Respond und Recover.
Nicht genug für
Konkrete technische Konfigurationen, vollständige Kontrolltiefe oder den Nachweis echter Wirksamkeit.
Danach
CIS Controls für Priorisierung, ISO/IEC 27001 für ein formales ISMS oder NIST SP 800-53 für Kontrolltiefe.
Praxis-Hinweis
Das Framework schafft ein gemeinsames Führungsbild. Konkrete Kontrollen oder Produkte müssen danach gesondert ausgewählt werden.
02 · Managementsystem

ISO/IEC 27001:2022

Wann?
Wenn Informationssicherheit dauerhaft geführt, intern überprüft und bei Bedarf zertifiziert werden soll.
Stark für
Verantwortlichkeiten, Risikobehandlung, Management Review, interne Audits und kontinuierliche Verbesserung.
Nicht genug für
Die Annahme, dass jede technische Kontrolle wirksam ist oder regulatorische Compliance automatisch entsteht.
Danach
CIS Controls oder BSI IT-Grundschutz für Umsetzung; MITRE ATT&CK für die Prüfung relevanter Angriffshandlungen.
Praxis-Hinweis
Das Managementsystem muss Entscheidungen, interne Prüfungen und Verbesserungen auslösen. Dokumente allein belegen keine wirksame Informationssicherheit.
03 · Priorität

CIS Controls v8.1

Wann?
Wenn Lücken bekannt sind, aber eine belastbare Reihenfolge fehlt.
Stark für
Pragmatischen Start, Implementation Groups und eine verständliche Diskussion über das Nächste.
Nicht genug für
Architekturentscheidungen, klare Eigentümerschaft oder einen Wirksamkeitsnachweis im Alltag.
Danach
NIST CSF oder ISO/IEC 27001 für Führung; technische Baselines für die konkrete Konfiguration.
Praxis-Hinweis
Die Implementation Groups geben eine erste Reihenfolge vor. Risiko, Systemlandschaft und verfügbare Fähigkeiten bestimmen, welche Controls tatsächlich zuerst umgesetzt werden.
04 · Angreiferverhalten

MITRE ATT&CK®

Wann?
Wenn die Frage lautet, welche Handlungen eines Angreifers verhindert, gesehen oder sicher beantwortet werden müssen.
Stark für
Threat-informed Defence, Detection Engineering, Purple-Team-Szenarien und strukturierte Analyse.
Nicht genug für
Ein vollständiges Sicherheitsprogramm. Eine Coverage-Matrix beweist weder gute Telemetrie noch funktionierende Alarme.
Danach
Ausgewählte Techniken mit Datenquellen, Detection-Tests und Incident-Abläufen verbinden.
Praxis-Hinweis
Wählen Sie die für Ihre Organisation plausiblen Angriffswege aus. Prüfen Sie vorhandene Telemetrie und Reaktionsabläufe mit realistischen Tests.
05 · Angriffsverlauf

Cyber Kill Chain®

Wann?
Wenn ein komplexer Angriff für Management und Technik als verständliche Abfolge diskutiert werden soll.
Stark für
Eine gemeinsame Sicht auf den Angriffsweg und die Frage, wo er früh unterbrochen werden kann.
Nicht genug für
Die Tiefe heutiger Angreifertechniken oder alle nichtlinearen Angriffsverläufe.
Danach
MITRE ATT&CK für Verhaltens- und Detection-Tiefe; eigene Kontrollen und Nachweise anschliessen.
Praxis-Hinweis
Die vereinfachte Abfolge unterstützt die gemeinsame Analyse eines Angriffswegs. Für einzelne Angreiferhandlungen ist MITRE ATT&CK genauer.
06 · Kontrolltiefe

NIST SP 800-53 Rev. 5

Wann?
Wenn Architektur, Control Owner oder Assurance-Funktionen Kontrollen detailliert ausarbeiten und auswählen müssen.
Stark für
Breiten Kontrollkatalog, Tailoring und strukturierte Assessments.
Nicht genug für
Proportionalität, Priorität und gelebte Verantwortlichkeit. Der Katalog kann sehr schnell zu gross werden.
Danach
Über Risiko, Zielbild, Owner, Architektur und erwartete Evidenz tailoren.
Praxis-Hinweis
Kontrollen müssen anhand von Risiko, Architektur und Nachweisbedarf ausgewählt werden. Eine vollständige Übernahme des Katalogs schafft noch keine Priorität.
07 · DACH-Umsetzung

BSI IT-Grundschutz

Wann?
Wenn eine Organisation im DACH-Raum eine strukturierte Methode mit Nähe zur konkreten Umsetzung sucht.
Stark für
Modellierung, systematische Analyse, Bausteine und eine etablierte Sprache für Sicherheitsanforderungen.
Nicht genug für
Einen schnellen Start ohne Scope und Priorität. Nicht jeder Baustein ist überall gleich wichtig.
Danach
Relevante Bausteine modellieren, Verantwortliche verbinden und Umsetzung anhand geeigneter Evidenz prüfen.
Praxis-Hinweis
Begrenzen Sie zuerst den Anwendungsbereich und priorisieren Sie die relevanten Bausteine. Umfangreiche Dokumentation ersetzt keinen Nachweis der Umsetzung.
08 · Schweiz · Verbesserungsweg

NCSC Cybersecurity and Resilience Method

Wann?
Wenn eine Schweizer Organisation einen pragmatischen Weg für Cybersecurity und Resilienz benötigt.
Stark für
Die Verbindung wichtiger Geschäfts- und Produktionsprozesse mit IT-Schutzobjekten, Schutzbedarf und Massnahmen.
Nicht genug für
Zertifizierung oder die Aussage, alle regulatorischen Pflichten seien erfüllt.
Danach
IKT-Minimalstandard für eine Baseline; NIST CSF oder ISO/IEC 27001 für zusätzliche Führungstiefe.
Praxis-Hinweis
Kleinere Organisationen können damit Schutzbedarf und Massnahmen schrittweise ausarbeiten. Zusätzliche regulatorische oder zertifizierbare Anforderungen müssen separat geprüft werden.
09 · Schweiz · Baseline

Schweizer IKT-Minimalstandard 2023

Wann?
Wenn eine Schweizer Organisation oder Branche eine verständliche Baseline und erste Selbstbeurteilung braucht.
Stark für
Orientierung, Mindestniveau, Reifegraddiskussion und Verbindung zum NIST CSF.
Nicht genug für
Den Nachweis der Wirksamkeit. Eine Selbstbeurteilung ist kein Kontrolltest.
Danach
Wenige wesentliche Lücken auswählen, Owner und Termin festlegen und die erwartete Evidenz definieren.
Praxis-Hinweis
Eine begrenzte und nachvollziehbare Selbstbeurteilung ist belastbarer als ein umfassender Fragebogen ohne geprüfte Nachweise.
10 · OT und Produktion

ISA/IEC 62443

Wann?
Wenn Produktion, industrielle Steuerungen, OT-Komponenten oder entsprechende Produkte und Dienstleistungen im Scope sind.
Stark für
Rollen im IACS-Lebenszyklus, Zonen und Conduits, System Security und sichere Produktentwicklung.
Nicht genug für
Die gesamte Enterprise Governance. Die richtigen Teile der Standardreihe müssen zur jeweiligen Rolle passen.
Danach
OT-Risiko, Safety, Verfügbarkeit, Architektur und Verantwortlichkeit mit ISMS und Unternehmensrisiko verbinden.
Praxis-Hinweis
Berücksichtigen Sie bei OT Wartungsfenster, lange Lebenszyklen, Safety und mögliche Betriebsunterbrechungen ausdrücklich. Anforderungen aus der Office-IT lassen sich nicht unverändert übertragen.
Drei typische Situationen

Nicht zuerst ein Framework wählen. Die anstehende Entscheidung fällen.

Die Beispiele zeigen typische Ausgangslagen. Sie beziehen sich nicht auf konkrete Kundenmandate.

Situation 01

Zertifiziert,
aber blind

Das ISMS ist vorhanden. Doch bei missbrauchten privilegierten Konten oder seitlicher Bewegung bleibt offen, ob die Organisation etwas erkennen würde.

Start: Wenige plausible ATT&CK-Verhaltensweisen auswählen, Telemetrie und Reaktion testen. Ein PAM-Video beweist allein noch keine wirksame Kontrolle.

Situation 02

Viele Mappings,
keine Priorität

ISO, NIST, CIS und regulatorische Anforderungen liegen im Spreadsheet. Trotzdem entscheidet niemand, was das nächste Quartal wirklich verändert.

Start: Mit einem NIST-CSF-Zielprofil die fehlenden Ergebnisse bestimmen. CIS Implementation Groups helfen anschliessend bei der Reihenfolge.

Situation 03

Schweizer KMU,
realistischer Start

Risiken aus Cloud, Abhängigkeiten und Lieferanten sind sichtbar. Für ein grosses Framework-Programm fehlen jedoch Zeit und spezialisierte Ressourcen.

Start: NCSC CSRM für Prozesse, Schutzobjekte und Schutzbedarf einsetzen. Dann wenige Lücken mit hoher Wirkung, Owner und Evidenz auswählen.

Schweiz und Regulierung

Frameworks helfen. Verpflichtungen müssen separat geführt werden.

NCSC-Methoden und der IKT-Minimalstandard unterstützen Entscheidungen. FINMA-Rundschreiben, ISG und Cyberverordnung sowie anwendbares EU-Recht bestimmen dagegen Geltung, Frist, Empfänger und Nachweis. Ein gutes Control Mapping hilft dabei, ersetzt aber kein Verpflichtungsregister.

01

Entscheid

Welche Frage ist blockiert?

02

Werkzeug

Welche Methode gibt genug Struktur?

03

Kontrolle

Wie wird die Frage konkret gelöst?

04

Evidenz

Woran ist Wirkung im Betrieb erkennbar?

05

Verpflichtung

Geltung, Trigger, Frist, Empfänger und Owner separat prüfen.

Praktischer Einstieg

Vorgehen für den Einstieg.

Das Ergebnis ist eine nachvollziehbare Verbindung von der anstehenden Entscheidung über die Umsetzung bis zum erforderlichen Nachweis.

  1. 01Eine blockierte Entscheidung benennen.
  2. 02So wenig Framework wie möglich, so viel Struktur wie notwendig wählen.
  3. 03Die Frage in Architektur, Prozess, Owner und Betrieb übersetzen.
  4. 04Evidenz vor der Umsetzung definieren.
  5. 05Geltung und regulatorische Trigger separat prüfen – danach die Entscheidung überprüfen und bei Bedarf neu fällen.
Quellen und Grenzen

Originalquellen vor Zusammenfassungen.

Massgeblich sind die jeweils aktuellen Primärquellen. Die Nennung eines Werkzeugs bedeutet keine Empfehlung oder Unterstützung von STOP.LI durch die genannten Organisationen.

Stand: August 2026 · Diese Seite ist eine Orientierung, keine Rechtsberatung, Zertifizierungsaussage oder vollständige Implementierungsanleitung. Versionen, Geltungsbereiche und regulatorische Pflichten müssen vor einer konkreten Anwendung geprüft werden.