責任、權限和網路引發的製程安全風險

安全等級是工業網路安全領域最實用的發明之一，它們能化繁為簡，使龐大而雜亂的系統得以分割、加固和改進，而無需掌握全部知識或進行無休止的分析。對於人力、時間和預算有限的組織而言，它們的存在使得網路安全防護成為可能。

安全等級不是問題所在，問題在於，安全等級悄悄變成了它原本不該用來取代判斷風險是否可接受的依據。當安全等級開始取代對網路引發的製程安全風險和剩餘風險可接受性的明確決策時，真正的問題就出現了。這種轉變很微妙，很少出現在文件中。但一旦發生，就意味著遠比技術上的捷徑嚴重得多的事情正在發生。

從設計輸入到無聲決策

IEC 62443將安全等級定義為設計要求，它們規定了一系列控制措施，用於在特定暴露假設下抵禦各類攻擊者的能力，達到安全等級意味著已實施預先定義的安全措施組合。

安全等級無法明確指出剩餘風險，它們沒有描述攻擊成功的可能性有多大，入侵如何透過控制功能傳播，或一旦入侵會造成哪些實際後果。它們反映了風險，但並未以可評估的形式表達出來。

這一點至關重要，因為IEC 62443-3-2標準僅止於此。此標準僅在選擇安全等級所需的範圍內評估風險，一旦確定了安全等級並實施了控制措施，剩餘的風險就被隱性地忽略了。實際上，這會造成強烈的錯覺：如果達到了所需的安全級別，則風險是可以接受的。這個結論從未被明確提出，反而悄悄滲入。

為什麼這不再是技術問題

到那時，工程工作已經完成，但風險問題尚未解決，故事的走向會根據後果而改變。根據定義，殘餘風險始終存在。這種風險是否可以接受，不能只從架構圖或控制目錄中推斷。這需要授權、問責制和明確的風險標準。

在純粹的業務關鍵型環境中，網路攻擊可能導致經濟損失或系統停機，但不會造成人員或環境的實質損害，因此，剩餘風險的接受程度通常仍由內部管理層決定。從技術角度來看，安全等級或許是適當的止步點，即使業務層面的考量可能另有其他討論。在高風險產業，這種奢侈是不存在的。

當網路安全成為製程安全隱患時（網路安全引發的製程安全風險）

在工業控制系統中，並非所有網路安全事件都是製程安全問題。勒索軟體攻擊如果加密工程工作站、歷史記錄系統或部分IT環境，可能會造成破壞性、高昂的成本和混亂，但仍能確保實體過程的可觀察、可控和可操作性。只要嵌入式控制系統、現場儀表和獨立的保護層保持完好，工廠就可以穩定運作或有序停機。在這種情況下，事件的重點在於恢復和業務連續性，而不是立即加劇危險。

但破壞營運完整性的網路事件則有所不同。當控制邏輯被竄改，感測器資料變得不可靠，執行器行為變得不可預測，警報被抑制，或是操作員的決策被操縱時，維持製程安全的裕度就會開始下降。即使沒有立即出現偏差，網路攻擊事件也已在製程安全層面上造成了可信的初始條件。從那一刻起，這項義務不再局限於網路領域，與其他任何起因一樣，也適用同樣的問題：

1. 這種事件會如何傳播？
2. 哪些保障措施會介入？
3. 獨立性假設仍然有效嗎？
4. 剩餘風險是否符合適用標準？

安全等級無法回答這些問題，它們的設計初衷就不是為了回答這些問題。

安全等級的自然極限

安全等級描述了攻破某個功能的難度，他們沒有描述如果這種妥協成功會發生什麼。在煉油、石化生產、油氣和管線運作等產業，網路攻擊很可能對人員、環境或週邊社區造成損害。在這些情況下，安全等級不能作為衡量可接受風險的標準。

風險可接受性已在其他方面得到規範，例如製程安全義務、健康、安全和環境要求以及社會風險標準。基於IEC 62443的方法可以定義基準耐受性，但不能作為風險可接受性的依據，這才是真正重要的界線。

當網路安全威脅可能成為引發事故的原因時，必須進行符合IEC 61511標準的基於情境的因果分析。安全等級為設計提供依據。因果分析則用於論證風險的合理性。

為什麼組織現實不容忽視

這裡有一個令人不安的現實事實，大多數組織沒有能力在所有地方進行完整的因果鏈分析。營運技術安全團隊規模較小，製程安全專家稀缺且工作量已相當繁重，期望對每個系統或區域進行深入的場景分析是不切實際的。這正是安全等級如此吸引人的原因，也是它們作為靜默端點如此危險的原因。

當組織層面難以進行深入分析時，風險接受並不會消失，而是轉化為技術選擇，例如區域定義、安全性等級分配、架構模式和控制選擇。這些決策本身並沒有錯，但當它們成為唯一的決策時，剩餘風險就會在未被明確認識或承擔的情況下被接受。

這種兩步驟結構是為了防止這種故障模式而設定的：

1. 使用安全等級在任何地方建立可擴展、可防禦的基線。
2. 只有在網路攻擊可能導致危險後果的情況下，才選擇性地應用因果分析。

這並非對嚴謹性的妥協，而是嚴謹性經受現實考驗的方式。

誰真正擁有「盡可能低風險」（ALARP）決策權

一旦網路安全能夠引發危險的流程行為，責任就不能再以學科界線劃分了。OT 安全工程師負責定義架構、區域和基線防禦能力，他們的職責是降低系統被攻破的可能性，並明確威脅和風險暴露的假設，他們無權宣布剩餘風險是否可接受。

製程安全專家會分析各種場景、升級路徑、安全措施和獨立性。在網路安全領域，這意味著要明確擴展傳統的製程安全場景，使其涵蓋惡意和蓄意發起的事件，而不僅僅是隨機故障或人為錯誤，他們也不擁有最終的驗收決定權。

最終，承擔剩餘風險的權力歸屬於工廠管理層，他們代表資產所有者行事，並遵循與所有其他製程安全決策相同的治理結構。從問責角度來看，工廠經理是獲授權的負責人，負責批准運作範圍、簽署安全案例，並在發生事故時向監管機構、法院和社會解釋其決策。這並不會因為其根本原因是數位化的而改變，改變的是需要考慮的各種情況。

我們一直迴避的選擇

目前來看，只有兩條可行的道路。網路引發的場景被明確地納入製程安全分析和治理中，剩餘風險與其他任何危害原因一樣，在 ALARP 框架下被接受。或者，風險承擔責任透過安全等級分配悄悄轉移到技術團隊，沒有強制規定，沒有明確標準，也沒有明確的責任。

其中一條路徑符合數十年來來之不易的安全實務經驗，另一路徑則將管理決策隱藏在技術標籤之下。迴避選擇並不能使之成為中立，它只是掩蓋了真正由誰來做決定的事實。

結語

安全等級至關重要，它們使大規模網路安全防護成為可能，但他們沒有承擔風險的權力。一旦網路威脅能夠引發製程安全事件，問題就不再是系統是否受到充分保護，而是誰有權決定剩餘風險是否可接受，以及當這項決定受到質疑時，誰將為此負責。網路技術並不能改變這個問題，這就使得假裝這個問題從未被問過變得不可能了。