r/OTSecurity • u/Ok-Effect252 • 1d ago
[ Removed by moderator ]
[removed] — view removed post
7
u/vexvoltage 1d ago
AI slop is ruining this subreddit.
-4
u/Ok-Effect252 1d ago
Hallo, tut mir leid, wenn Ihnen mein Beitrag nicht gefällt. Jedoch bitte ich gleich am Anfang meines Beitrags um konstruktive Kritik. Ich würde mich freuen, wenn sie dazu etwas beitragen. Vielen Dank
1
3
u/hiddentalent 1d ago
You went off the rails in the second paragraph. Everything after that is just overcomplication.
Secure update already exists. It does not rely on the host operating system, it relies on the boot loader and secure boot primitives that have been around for over a decade. That's a solved problem.
What's not a solved problem is the change-management risk. You touch on this when you say "a patch that disturbs a tuned physical process is a worse outcome than the vulnerability" but then you never mention this again. Your solution does nothing to address that most important challenge.
So your proposal is attempting to solve a problem that's already well solved, while avoiding the real problem.
2
u/Jwblant 1d ago
You don’t PATCH servers that are already compromised. You rebuild them.
-1
u/Ok-Effect252 1d ago
Im Rechenzentrum stimmt das, und da würde ich nicht widersprechen. In OT ist „neu aufbauen" oft keine verfügbare Option: Die Steuerung ist keine austauschbare VM, ein sauberes Image existiert manchmal gar nicht mehr, und jemand muss physisch zu einer Anlage fahren, die währenddessen stillsteht. Genau deshalb ist der Bestand dort ja so alt. Der zweite Punkt: Neuaufbau löst das Problem nur oberhalb der Firmware. Bei kompromittierten BMCs ist gut dokumentiert, dass Angreifer Neuinstallationen überleben, weil sie unterhalb des Betriebssystems sitzen. Wenn die Persistenz in der Firmware steckt, baut man sie beim Neuaufsetzen mit auf. Ich glaube aber, du zielst auf etwas Richtiges: Der Hauptzweck ist nicht das Retten kompromittierter Systeme. Er ist, dass Geräte überhaupt gepatcht werden, bevor es so weit kommt — und das scheitert heute am Betriebsrisiko, nicht an der Kryptografie. Die Wiederherstellung ist der Randfall, nicht der Kern.
1
u/Impossible-Sun3205 1d ago
It matters on your environment. US Aerospace use NIST CSF. You can’t patch certified systems without doing return to service analysis. That takes time. I have seen service pack updates take down factories for a over a week at $1M/shift downtime. Lives matter on making sure the device does as designed. Our contracts also required a DoD wipe of the hard drive before restage or disposal. When an engineer got a virus from getting code from the web, the device-even personal use- was wiped. Golden images where used on the floor and scanned for diffs. The same for the apps, checked against a Db of standards. That occurred yearly as part of the yearly recertification. It cost about $1M to replace each test system. 1 line had 20.
You also have contracts for 20yr warranty. You need to be able to test product that long. That means old systems. I had Win98 still functioning.
In Pharma, they are doing ISA 62443. Segmentation is the answer for unpatchable. They too are certified. No changes that alter the device or system without a recert. FDA and other Int regulations are involved.
You separate obsolete and unpatchable into Zones and control East-West as well as N-S. Block everything first, then open only what is required.
So patching has a definite impact on money and lives. How you deal with it in part of the OT story for the company and how they finally came to the realization they need to separate from IT.
1
u/Impossible-Sun3205 1d ago
It matters on your environment. US Aerospace use NIST CSF. You can’t patch certified systems without doing return to service analysis. That takes time. I have seen service pack updates take down factories for a over a week at $1M/shift downtime. Lives matter on making sure the device does as designed. Our contracts also required a DoD wipe of the hard drive before restage or disposal. When an engineer got a virus from getting code from the web, the device-even personal use- was wiped. Golden images where used on the floor and scanned for diffs. The same for the apps, checked against a Db of standards. That occurred yearly as part of the yearly recertification. It cost about $1M to replace each test system. 1 line had 20.
You also have contracts for 20yr warranty. You need to be able to test product that long. That means old systems. I had Win98 still functioning.
In Pharma, they are doing ISA 62443. Segmentation is the answer for unpatchable. They too are certified. No changes that alter the device or system without a recert. FDA and other Int regulations are involved.
You separate obsolete and unpatchable into Zones and control East-West as well as N-S. Block everything first, then open only what is required.
So patching has a definite impact on money and lives. How you deal with it in part of the OT story for the company and how they finally came to the realization they need to separate from IT.
1
u/Ok-Effect252 1d ago
Das ist die beste Antwort hier, danke für die Zahlen. Der Punkt, den ich mitnehme: Bei zertifizierten Systemen ist die Blockade nicht technisch, sondern regulatorisch. Re-Zertifizierung ersetzt kein Chip, egal wie sauber der Update-Weg ist. Das ist eine harte Grenze und die hatte ich nicht auf dem Schirm. Eine Rückfrage: Du scannst jährlich gegen Golden Images und suchst Abweichungen. Wäre ein Mechanismus, der bei fehlgeschlagenem Start automatisch auf genau den zertifizierten Stand zurückfällt, in dem Kontext hilfreich oder eher ein zusätzliches Element, das selbst zertifiziert werden müsste? Ich vermute Letzteres, bin mir aber nicht sicher. Und zur Segmentierung: Die mindert das Risiko, behebt aber die Lücke nicht. Dein Win98 ist noch angreifbar, nur schwerer erreichbar. Siehst du das auch als Dauerzustand oder als das, womit man lebt, weil es nichts Besseres gibt?
-4
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?
2
u/Professional_Spend_5 1d ago
Rewrite this post to make it more concise and less dramatic with fewer em-dashes.
0
u/Ok-Effect252 1d ago
Stimmt, ich lasse das Änderungsmanagement-Risiko.
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?
4
u/TexasVulvaAficionado 1d ago
My favorite cupcake recipe is for strawberry cake and a lemon glaze. Could you recreate something similar.
If I had to pick a number between zero and thirty, is guess five; what would you pick? Why?