工業企業在OT漏洞管理的成熟度方面，明顯與 IT 漏洞管理的成熟度存在差距，滯后的原因與其說是OT系統先天存在缺陷或弱點，不如說是在 OT環境中發現和修復漏洞存在特別挑戰。當然，在許多OT系統中處理的技術和漏洞類型與 IT 系統相同。也存在明顯的交叉，工業控制系統 （ICS） 等許多OT資產依賴于與其對應IT 系統類似的操作系統、網絡連接和架構。
然而，ICS/OT工作環境與IT迥異，潛在的網絡風險及其影響也是如此。最重要的是OT獨有的附加協議，用戶與供應商之間復雜的售后支持協議會影響系統修補方式和時間，以及通常對業務可持續性至關重要的嚴格監管和運營要求。因此，建立OT漏洞管理過程是一個緩慢的、系統性的過程，需要人財物各方面的資源，當然還需要一定的時間。從當前的實踐探索來看，工業組織中沒有一成不變的漏洞管理流程或道路可以遵循，不同行業都有不同的套路。但有些問題和挑戰是共同的，比如優先級排序，資產與漏洞的映射，手工與自動化的協調，設備供應商的協同，專職的人員，修復決策等等。工業網絡安全公司Dragos日前發布的《了解OT漏洞管理的挑戰和如何解決它們》的白皮書，總結了OT漏洞管理的10個關注點，期望為OT漏洞管理的成功提供一些有價值的方法指導。
1.稍安勿躁，讓漏洞飛一會
工業組織在第一次處理OT漏洞管理時最常犯的錯誤之一是陷入恐慌，焦躁不安。往往安全事件的威脅或監管要求的加碼，會造成突然的、強烈的壓力。
解決特定ICS漏洞或一組漏洞，從高層下達命令，實施人員在匆忙中修復缺陷，安全團隊或許破壞系統，由于不正確的或不充分的測試，或沒有真正理解OT系統是如何運行的。
正確地進行OT漏洞管理需要安全人員和運營人員穩步推進，考慮漏洞的風險影響，以便他們能夠幫助領導者做出解決漏洞的正確決策或命令，并創建一個可復現的系統，真正降低業務的整體風險。
2.資產清單，全面的可見性
每一個重大的OT漏洞管理方案，其根本的基礎都是一個全面的OT資產清單。為了正確地實施，組織需要經歷一個不限于可以挖掘的資產發現過程。
在所有這些資產上，還要根據一系列屬性對它們進行分類，映射它們的連接，并跟蹤它們的配置狀態。理想情況下，組織不應該只是計劃在某個時間點對資產進行調查，而是努力構建自動化機制，以獲得對資產清單狀態的持續可見性。這種持續的監測將確保一個成功的漏洞管理程序的可持續性。
IT資產的許多可見性工具和戰術無法直接運用或很好地轉換到OT環境。例如，你不能把代理放在可編程邏輯控制器（PLC）上。這意味著組織可能需要采取特定于OT環境的不同方法，以實現對資產、漏洞和風險的可見性水平，這與他們的安全團隊可能習慣于看到的跨IT資產組合相對應。確保制定計劃，通過像Dragos收集管理框架這樣的結構化方法確定數據收集需求。一個好的計劃將為一個成功的結果奠定基礎，這個成功的結果將創建一個可持續的、可擴展的、有效的資產可見性計劃，持續更新清單。
3.考慮效率，不要擔心自動化
通常而言，OT漏洞管理幾乎肯定是一個完全手工的過程。的確，你不會像在IT系統中那樣，用自動補丁和更新來覆蓋OT系統。然而，盡管許多關鍵ICS系統的補救和緩解必須保持手動，但許多方面可以實現自動化。
許多自動化發生在過程的前端，在漏洞管理周期的前三個階段，但最終OT在報告任務和理解環境的自動化中是非常安全的。如前所述，資產發現是很容易實現的目標。類似地，漏洞評估和跟蹤配置基線和配置轉移實例的過程為大量自動化提供了機會。資產的優先級還可以通過發現和評估提供的數據實現自動化。
解析的執行在許多方面可能有風險，但是像備份系統和測試備份這樣的任務是可以立即自動化的。另外，不要低估自動為非關鍵OT系統打補丁所節省的時間。
4.定期巡查，讓手動工作更有效
有時，開始使用自動發現可能會很困難，因為組織不知道它對其基礎設施不了解的內容。這就是為什么用手動發現啟動計劃是很有價值的。首先通過映射高級架構和執行全面的設施巡視，開始用物理方法識別需要解釋的隱藏資產。
這種早期的手工工作將使優先級更容易確定，并決定在哪里建立遠程的發現，首先嘗試連續的、自動的發現。
在整個漏洞管理過程中，巡查也是至關重要的，以驗證自動化資產發現生成的結果，并填補環境中可能沒有必要由監測和遙測技術覆蓋的空白。考慮定期巡查，去查看環境，并將結果與之前記錄的結果進行比較。理想情況下，組織應該在其文檔或映射機制中有一個簡單的路徑來添加定期手工發現的結果。
5.過程記錄，文檔至關重要
出于許多原因，文檔記錄是OT漏洞管理的關鍵。首先，因為很多過程仍然是手工的，所以過程的文檔需要遵守紀律，以確保它們不是在特定的基礎上完成的。最終的目標，是讓組織嘗試將文檔轉化為兼容的工作流程，以確保一切都是標準化的、可重復的和可證明的。
確保部分文檔包含關于工作流中的角色和職責的信息是至關重要的。
考慮到系統更新的時間框架很長，要確保職責不是指定給個人，而是指定給特定的角色或崗位。這確保了即使你的隊友六年后不在身邊，當某個設備的維護窗口打開時，它仍然會被修補。
最后，如前所述，文檔記載了實際做了什么動作。發現漏洞是漏洞管理與評估的區別所在。對于OT漏洞，由于操作上的考慮，對于那些必須接受風險的OT漏洞，漏洞處理的文檔尤為重要。
最終，所有這些文檔工作可以成為滿足監管審計人員的一個重要因素，并有助于降低關注OT漏洞帶來的風險。
6.優先排序，OT漏洞優先級是不同的
OT漏洞優先級與IT中非常不同，在IT中，重點主要是漏洞的嚴重程度評分（CVSS），理想情況下是資產的業務關鍵性。運行風險和物理世界影響的額外維度改變了計算的方式。工業空間也超過了一個關鍵閾值。2020年，在日歷年的每個工作日都披露了工業產品的一個以上嚴重漏洞。
確定關鍵的“皇冠寶石”系統對做出這些優先級決策至關重要，但請記住，這不是簡單地說“這是皇冠寶石資產的一個漏洞，我們必須立即修補它。”如果這些資產受到治理活動的干擾，它們的運營風險通常也最高。它們也是OT環境中最可能被最安全控制緩沖的關鍵設備。所以，這個決定比這要微妙得多。
自動化標準和法規合規性機制，如IEC （International Electrotechnical Commission） 62443，傾向于關注普渡模型中更低層次的資產，但組織在為優先級建立風險評分時也應該考慮其他因素。例如，資產所有者應該在他們的OT網絡中為連接最多的系統提供高權重——如連接到第三方、不同的供應商和外部世界，特別是在這些資產上存在通往互聯網的路徑時。這些系統通常面臨著最容易出現OT漏洞利用的風險。此外，應該優先考慮具有單點故障或作為集中式系統存在的資產。這包括活動目錄、管理控制臺，甚至Windows Server Update Services （WSUS）補丁。SolarWinds供應鏈攻擊事件提供了一個很好的例子，一個盒子可以將它的手指伸進整個OT環境。
其他考慮因素可能包括，是否存在會使組織無法進行補救的運行風險的緩解因素。例如，如果系統相對容易脫機，那么內置冗余的系統可能會在優先級列表中上升。
7.忽略漏洞，掌握補償控制技巧
許多OT系統中，由于更改這些資產存在操作風險，因此無法進行修補。事實上，2020年DRAGOS的統計數據發現，2020年披露的OT漏洞中，超過五分之一的供應商在宣布時甚至沒有可用的補丁。
此外，關鍵OT資產通常在設計上是不安全的，因此即使應用了補丁，它們仍然容易由于濫用正常功能而失去視圖或失去控制。在這些情況下，資產所有者必須捫心自問，如果一個系統仍然容易受到設計問題的影響，他們為什么還要承擔修補漏洞的風險。
這意味著有效的OT漏洞管理程序必須掌握補償控制的藝術，不僅降低漏洞的風險，而且降低必須在某些資產中持續存在的潛在設計缺陷的風險。目標應該是通過加強資產配置、關閉不需要的功能、限制資產的占用空間和連接，以及更新與脆弱系統相關的可修補系統，盡可能減少攻擊面。
對于SMB v2，根據系統的運行情況，正確的做法可能是關閉協議。與風險接受一樣，像這樣的緩解應該在徹底的漏洞配置跟蹤中仔細地記錄下來，以便更改不會意外逆轉。
對于“皇冠”資產，其思想是它們應該使用盡可能少的功能，并與網絡中盡可能少的部分進行通信，這對于流程來說是必要的。網絡和應用程序防火墻在這方面是無價的，應用程序白清單也是如此。同樣，組織應該重新評估網絡分段。
8.協調行動，積極管理供應商
在OT領域，大多數主要供應商提供網絡解決方案和服務，通常包括補丁、端點保護和配置管理。但是組織不應該把這些作為內部漏洞管理程序的替代品。這些服務并沒有提供真正的漏洞管理的“設置即可忘記”保證，也沒有提供必要的文檔以提供組織范圍內的風險可見性。
組織需要積極地管理他們的供應商關系，不僅要確認服務正在按照商定的方式升級或緩解系統，而且還要記錄所有供應商和整個現用資產的漏洞狀態。
在組織正在為自己的系統打補丁的情況下，它還需要注意與供應商合作，以確保更改不會使支持協議或保證無效。通常，在對關鍵ICS系統進行更改之前需要供應商預先的批準或許可。
9.變更管理，需要建立嚴格的流程
對于許多關鍵ICS資產，由于需要符合安全管理的要求，變更管理治理非常嚴格。例如，像PLC這樣的資產，總是要根據不同行業的要求，經過過程安全管理強制要求的正式變更管理過程。如果資產涉及工業過程，則要求可能會嚴格得多。
然而，OT中也存在一些灰色區域，其中某些資產對流程沒有影響，但更改和配置狀態仍可能影響操作風險。以歷史數據庫為例，即使它崩潰了，也不會對過程產生影響，但在整個OT生態系統中仍然至關重要。一個成熟的OT漏洞管理程序應該注意創建一個變更管理流程，該流程捕獲可能在監測系統下運行的資產，在進行補救和緩解時管理和跟蹤變更。
10.專人專崗，專業人員做專業的事
一個有效的OT漏洞管理程序需要持續關注，需要專門的資源來維護。雖然發現和評估過程中的許多職責可以自動化，但與資產所有者協調、更新系統、采用補償控制、驗證和跟蹤進度仍有大量必要的工作。期望一個人甚至幾個人既做修復工作、項目工作、工程任務，同時還做所有他們自己的漏洞管理工作，這是不切實際的，也是不合理的期望。
