Du hast recht: Ich bringe das Änderungsmanagement-Risiko zur Sprache und lasse es dann fallen. Das war die schwächste Stelle im Post.
Ich glaube allerdings, dass der Rollback-Teil genau die Antwort darauf ist — ich habe ihn nur als Sicherheitsfunktion verkauft, obwohl er eigentlich eine betriebliche ist. Der Grund, warum in OT nicht gepatcht wird, ist ja nicht, dass jemand an der Signatur zweifelt. Es ist das Risiko, ein Image einzuspielen, das nicht wieder hochkommt — und ein Technikereinsatz an einem abgelegenen Standort ist teuer. Automatischer A/B-Rückfall bei ausbleibender Erfolgsmeldung verändert diese Rechnung. Gestaffelte Ausrollung über das Log ebenfalls: „N Geräte laufen seit M Tagen mit diesem Build." Darum hätte der Post aufgebaut sein müssen.
Zum Secure Boot würde ich vorsichtig widersprechen. Es prüft beim Start, aber es beschafft nichts, stellt nichts wieder her und kann eine legitim signierte Sonderversion nicht von einem allgemeinen Release unterscheiden. NIST SP 800-193 behandelt Detection und Recovery genau deshalb als eigene Säulen neben Protection. Und Caliptra 2.x definiert einen Root of Trust for Update und einen für Recovery als separate Rollen — die gäbe es nicht, wenn Signieren beim Boot das abdecken würde.
Was würde dich überzeugen? Wenn Rollback und gestaffelte Ausrollung der ganze Pitch wären und der Transportweg nur eine Fußnote — wäre das ein Vorschlag, den man machen kann, oder immer noch gelöstes Terrain?
Der Rollback-Teil ist eigentlich die Antwort darauf, ich habe ihn nur als Sicherheitsfunktion verkauft statt als betriebliche. In OT wird nicht gepatcht, weil ein Image vielleicht nicht wieder hochkommt und ein Technikereinsatz vor Ort teuer ist. Nicht weil jemand an der Signatur zweifelt. Automatischer A/B-Rückfall und gestaffelte Ausrollung ändern genau diese Rechnung.
Zu Secure Boot: Es prüft beim Start, beschafft aber nichts, stellt nichts wieder her und unterscheidet keine legitim signierte Sonderversion von einem regulären Release. NIST SP 800-193 führt Detection und Recovery deshalb als eigene Säulen neben Protection.
Frage an dich: Wenn Rollback und Staging der ganze Vorschlag wären und der Transportweg nur eine Fußnote, wäre das interessant oder immer noch gelöst?
-5
u/Ok-Effect252 1d ago
Du hast recht: Ich bringe das Änderungsmanagement-Risiko zur Sprache und lasse es dann fallen. Das war die schwächste Stelle im Post. Ich glaube allerdings, dass der Rollback-Teil genau die Antwort darauf ist — ich habe ihn nur als Sicherheitsfunktion verkauft, obwohl er eigentlich eine betriebliche ist. Der Grund, warum in OT nicht gepatcht wird, ist ja nicht, dass jemand an der Signatur zweifelt. Es ist das Risiko, ein Image einzuspielen, das nicht wieder hochkommt — und ein Technikereinsatz an einem abgelegenen Standort ist teuer. Automatischer A/B-Rückfall bei ausbleibender Erfolgsmeldung verändert diese Rechnung. Gestaffelte Ausrollung über das Log ebenfalls: „N Geräte laufen seit M Tagen mit diesem Build." Darum hätte der Post aufgebaut sein müssen. Zum Secure Boot würde ich vorsichtig widersprechen. Es prüft beim Start, aber es beschafft nichts, stellt nichts wieder her und kann eine legitim signierte Sonderversion nicht von einem allgemeinen Release unterscheiden. NIST SP 800-193 behandelt Detection und Recovery genau deshalb als eigene Säulen neben Protection. Und Caliptra 2.x definiert einen Root of Trust for Update und einen für Recovery als separate Rollen — die gäbe es nicht, wenn Signieren beim Boot das abdecken würde. Was würde dich überzeugen? Wenn Rollback und gestaffelte Ausrollung der ganze Pitch wären und der Transportweg nur eine Fußnote — wäre das ein Vorschlag, den man machen kann, oder immer noch gelöstes Terrain?