Konzept- und Designphase: Ergebnisse und Übergaben, die ein Audit übersteht

Die teuersten Befunde eines Security-Audits entstehen nicht im Code. Sie entstehen in den ersten Wochen eines Vorhabens — dort, wo Abgrenzung, Annahmen und Schutzziele festgelegt werden, meist mündlich und ohne Ergebnisdokument.

Zwei Jahre später fragt jemand, warum eine bestimmte Schnittstelle als vertrauenswürdig behandelt wurde. Die Antwort existiert, aber sie existiert nur in der Erinnerung von drei Personen, von denen eine das Unternehmen verlassen hat.

Konzeptphase: vier Ergebnisse, nicht vier Folien

Was in der Konzeptphase entsteht, trägt später die gesamte Argumentation. Vier Artefakte sind unverzichtbar — und jedes davon ist ein Ergebnis, kein Absatz in einer Präsentation.

Scope. Was gehört zum Betrachtungsgegenstand und was ausdrücklich nicht? Die Grenze verläuft an Schnittstellen, nicht an Organisationseinheiten. Ein Gateway, das „eigentlich nicht zum Produkt gehört”, aber im selben Gehäuse sitzt, muss eine erklärte Entscheidung sein — keine Auslassung.

Betriebsumgebung. Unter welchen Bedingungen wird das Gerät betrieben? Steht es im verschlossenen Schaltschrank oder am Mast? Hängt es hinter einer Firewall oder direkt am Kundennetz? 62443-4-2 kennt Anforderungen, die sich ausdrücklich auf kompensierende Maßnahmen der Umgebung stützen dürfen — aber nur, wenn die Umgebung beschrieben ist.

Annahmen und Constraints. Der am häufigsten fehlende Punkt. „Der Betreiber vergibt individuelle Zugangsdaten”, „die Wartungsschnittstelle ist physisch geschützt”, „das Gerät wird nie direkt aus dem Internet erreichbar sein” — das sind Annahmen, auf denen ganze Maßnahmenketten ruhen. Ungeschrieben sind sie keine Annahmen, sondern Hoffnungen. Sie gehören außerdem in die Security Guidelines, denn der Betreiber muss wissen, wofür er einsteht.

Schutzziele und Komponenten. Was genau soll geschützt werden — Verfügbarkeit der Steuerfunktion, Integrität der Parametrierung, Vertraulichkeit von Messdaten? Schutzziele entscheiden über Priorisierung. Ohne sie ist jede spätere Risikobewertung eine Geschmacksfrage.

Zwei Ergebnisse kommen dazu, die in der Praxis regelmäßig zu spät entstehen:

Das Bewertungsschema selbst. Welche Skalen für Eintrittsmöglichkeit und Auswirkung gelten, wie beide zu einem Risikowert verknüpft werden und ab welcher Stufe gehandelt wird — das gehört in die Konzeptphase, nicht in die erste Bewertungssitzung. Wer das Schema erst festlegt, wenn die ersten Bedrohungen auf dem Tisch liegen, kalibriert unbewusst am Wunschergebnis.

Die Regel, was bei einem erkannten Risiko passiert. Wer entscheidet über die Behandlung, wer trägt sie, und was löst eine erneute Bewertung aus? Ebenso gehört früh geklärt, wer die Sicherheitsaktivitäten über den gesamten Lebenszyklus verantwortet — in vielen Organisationen eine benannte Rolle mit einem eigenen Cybersecurity-Plan.

Designphase: von der Bedrohung zur Anforderung

In der Designphase kommt die Analyse dazu, und mit ihr die Verbindung, um die es am Ende geht: von der Bedrohung zur Anforderung zum Mechanismus.

• Bedrohungsmodell je Schnittstelle. Nicht je Produkt. Die Schnittstelle ist die Einheit, an der Angriffe ansetzen und an der sich Maßnahmen zuordnen lassen.
• Abgeleitete Sicherheitsanforderungen. Jede Anforderung zeigt zurück auf eine identifizierte Bedrohung und nach vorn auf einen geplanten Mechanismus. Eine Anforderung ohne Rückbezug ist eine Checkliste; eine Bedrohung ohne Anforderung ist ein offener Punkt.
• Architekturentscheidungen mit Begründung. Warum Secure Boot statt signierter Applikationsupdates? Warum TLS auf Transportebene statt Payload-Signatur? Die Antwort ist im Moment der Entscheidung billig und ein Jahr später teuer.
• Designreview mit Protokoll. Das Protokoll ist der Nachweis. Ein Review ohne Aufzeichnung hat aus Auditsicht nicht stattgefunden.
• Verifikation des Sicherheitskonzepts. Das Konzept wird nicht nur spezifiziert, sondern gegen die Anforderungen geprüft — mit einem Ergebnisbericht, der zum freigegebenen Stand gehört.

Die Übergabe ist der kritische Punkt

Zwischen Konzept und Design, zwischen Design und Implementierung geht in der Praxis mehr verloren als innerhalb der Phasen. Drei Regeln halten die Kette zusammen:

Jedes Ergebnis hat einen Stand, nicht nur einen Namen. „Bedrohungsanalyse_final_v3_neu” ist kein Stand. Versionierung mit Datum und Verantwortlichem ist das Minimum.

Der freigegebene Stand bleibt unverändert. Was nach der Freigabe weiterbearbeitet wird, ist eine neue Version — nicht dieselbe Datei mit mehr Inhalt. Ohne diese Trennung lässt sich später nicht zeigen, worauf die Freigabe sich bezog.

Änderungen an der Basis lösen eine Prüfung aus. Ändert sich die Betriebsumgebung oder fällt eine Annahme weg, ist die Analyse betroffen — nicht irgendwann, sondern als ausgelöste Aktivität. Genau das misst der Reifecheck unter Pflege und Aktualität.

Das heißt ausdrücklich nicht, dass die Konzeptphase ein einmaliger Abschluss wäre. Sie ist vor der Produktentwicklung abgeschlossen, aber einzelne Schritte werden in Design, Produktion und Betrieb erneut durchlaufen — wenn eine Schnittstelle dazukommt, wenn ein Test eine Annahme widerlegt, wenn ein neues Angriffsmuster bekannt wird. Iterativ ist der Normalfall; was zählt, ist, dass jede Runde einen eigenen Stand hinterlässt.

Der Prüfstein

Eine einfache Probe für die eigene frühe Phase: Nehmen Sie eine beliebige Sicherheitsanforderung Ihres aktuellen Produkts und versuchen Sie, sie in beide Richtungen aufzulösen — zurück zur Bedrohung, die sie begründet, und nach vorn zur Aktivität, die sie erfüllt. Gelingt das für drei zufällig gewählte Anforderungen, ist die Konzeptarbeit belastbar. Gelingt es für keine, liegt das Problem nicht in der Dokumentation, sondern in der Reihenfolge, in der gearbeitet wurde.

Fachliche Einordnung, kein Rechtsrat und keine Zertifizierungsaussage. Normzitate bitte am Originaldokument prüfen.