基于數據挖掘的工業控制系統防危機制研究

徐新國,朱廷劭,康 衛,孫保輝,房志奇,王 焱

(1.中國電子信息產業集團有限公司第六研究所，北京 100083；2.中國科學院研究生院 信息科學與工程學院，北京 100190)

工業控制系統包括數據采集與監控系統(SCADA)、分布式控制系統(DCS)、可編程邏輯控制器(PLC)、遠程終端(RTU)、智能電子設備(IED)等，以及確保各組件通信的接口技術[1]。目前廣泛應用于電力、水利、污水處理、石油化工、交通運輸、制藥以及大型制造行業，是國民經濟的重要組成部分。

據權威工業安全事件信息庫RISI(Repository of Security Incidents)統計[2]，截止 2011年 10月，全球已發 生200余起工業控制系統的嚴重安全事件。工業控制系統信息安全事關工業生產運行、國家經濟安全和人民生命財產安全，一旦出現工業事故，將對正常生產運行和國家經濟安全造成重大損害。

1984年 12月3日凌晨，在印度的 Bhopal，45噸甲烷異氰酸脂重毒氣從聯合炭化蟲劑制造廠泄漏并擴散到附近居民區，造成至少2 500人死亡，25萬人的健康受到影響。1986年4月，前蘇聯切爾諾貝利核電發生爆炸，導致世界上最嚴重的核事故。

分析以上事故原因發現，每起事故都涉及到控制系統的防危問題。印度毒氣泄露事件調查報告顯示[3]，610號儲槽的壓力在15 min內由2 psig上升到10 psig。由于換班原因，新操作員并未察覺到壓力突變異常，正常壓力大約在2～25 psig之間。而當壓力突升而未察覺時，則會導致毒氣泄漏。1986年切爾諾貝利核電站爆炸事故調查報告顯示[4]，由于核電站人員多次違規操作，導致反應堆能量增加，發生爆炸。

隨著高新技術的廣泛應用，工業控制系統越來越復雜，錯誤越難檢測和避免，由此帶來的安全隱患也越多，對系統的防危要求越來越迫切。工控系統對防危性的要求包含以下幾個方面[5]：

(1)整體性：工控系統中對關鍵設備的不同操作之間存在相互依賴關系，要將其視為一個整體考慮。

(2)通用性：為達到資源共享以及實現不同工控系統間的移植，需把系統功能實現與防危機制分離開，提高防危機制的通用性。

(3)自適應性：系統內部環境發生改變時，應采用某種自適應手段，適應新的環境來滿足用戶的需求。

(4)隔離性：監控對關鍵設備的操作，拒絕可能導致重大人身和財產損失的操作命令，實現應用軟件與系統設備的隔離，保證工控系統的防危性。

面對越來越復雜的工控系統和愈來愈重要的防危性要求，開展針對現有工控系統的防危機制研究具有巨大的科學意義和應用價值。

1 相關研究介紹

近年來很多重大事故的發生都可以歸結為工控系統在防危性方面的疏忽或缺失，事故主要來源于系統的設計缺陷及操作人員的誤操作，也使工控系統失去了可信性。

1985年，Laprie提出了 dependability(為與可靠性 reliability相區別，譯為可信性)概念，以此度量計算機系統的服務質量[6]。如圖1所示，可信性是一個復雜的綜合性概念，具有豐富的內涵，它所包含的特征有：可用性(Availability)、可 靠 性(Reliability)、防 危 性(Safety)、安 全 性(Security)和可維護性(Maintainability)5個特征量。1995年Laprie把 Security分解為Confidentiality和Integrity[7]。

防危性與可用性、可靠性、可維護性、安全性的區別[8]如表1所示。防危強調的是防止危險發生，即防止系統給生命財產及生態環境造成災難性破壞。防危技術主要是對系統內部錯誤的偵測、異常處理以及誤操作的避免，不同于可信性的其他特性。

目前實現防危的主要技術手段有防危核與防危殼兩種。

防危核(Safety Kernel)最早由安全學家 Leveson[9]提出，其原理是根據實際系統的工作特點定制的一套防危策略，驗證所有對關鍵設備的操作請求，只有通過驗證的操作請求才可到達硬件進行操作，拒絕所有未經過驗證的操作。防危核成功隔離了應用請求與關鍵設備，避免用戶誤操作引起的系統錯誤,達到對系統的防危保護。

防危殼(Safety Shell)是由 Katwijk和 Zalewski[10]提出的防危技術，其技術原理與防危核類似，是防危核技術的一種功能更為強大的擴展。防危殼的防危原理是在系統控制器與關鍵設備之間安插一個隔離層，所有操作請求都必須經過防危殼的驗證。防危殼主要由狀態監視器、時間監視器、異常處理子模塊組成。狀態監視器是保證系統防危性最重要的關鍵子模塊，其作用是負責與底層I/O接口交互，驗證所有操作請求，并負責實時監測設備的工作狀態，一旦發現異常，則發送相應的操作命令來調整系統狀態，同時報告錯誤。時間監視器用于檢驗設備命令是否在規定的時間內完成，保證了設備操作的實時性。異常處理器監視對設備的操作命令，拒絕錯誤的操作命令，并調用相應的錯誤處理程序。

防危核和防危殼是防危系統里最常用的兩種技術手段，將防危核與防危殼技術進行比較，可以發現兩種方式的基本原理都是相同的，即提供了設備操作與關鍵設備的隔離。不同點在于，防危核只提出了操作驗證的基本功能，而防危殼將防危策略細分為三個子模塊，子模塊擁有了單獨檢查設備狀態和保證命令時間限制等功能，降低了驗證整個防危策略的開銷。某種程度上，防危殼可以看作是防危核技術的一種擴展變型和另一種實現方式。

2 防危分析

無論防危核還是防危殼，都只是把關鍵設備進行隔離防危，而實際的工控系統是一個復雜的網絡，各設備之間存在著相互依賴關系，對一個設備的操作勢必會對其他設備造成影響，針對獨立設備的防危往往達不到整體防危的要求。因此，針對整體性防危的要求，本文提出利用防危保護態以及有窮狀態機實現防危，如圖2實線所示。系統從正常工作狀態發展為事故，一般經過多個狀態，從警告、臨界到危險，直至事故。為了實現防危，借鑒容錯理論，引入防危保護狀態(E)，也就是在系統遇到危險或在臨界情況下，通過防危機制進入保護模式，在保護模式下系統可以通過自我調節回歸到正常模式。

表1 可信特征的區別

工控防危系統的有窮狀態機 M=(K,Σ,f,S,Z)。

狀態集 K：{A,B,C,D,E,F}

輸入集 Σ：{a,b,c,d}

轉化函數

初始狀態 S：A

終態集Z：{A,F}

用狀態轉化圖表示如圖2所示。圖中，A：正常狀態；B：警告狀態；C：臨界狀態；D：危險狀態；F：事故狀態；E：防危保護態。

危險包括針對工業現場的和工控系統自身的，為了從危險狀態(D)轉化到防危保護狀態(E)，針對不同類型的危險，需要通過專家規則實時判斷工業現場的危險狀況，或者通過降級服務對工控系統實施保護。為了從防危保護態(E)轉化為正常態(A)，需要通過工控系統的合理調度，實現自身狀態的回歸，或者利用專家知識庫推薦工業現場的補救方案。

為了從臨界狀態(C)轉化為防危保護態(E)，一方面需要對關鍵設備的情況進行主動預測和危險預報；另一方面，通過分析設備之間的相互影響關系，預測系統整體的風險。

針對出現報警(B)的情況，利用專家規則判斷危險狀況，并根據專家規則中的處理辦法進行相應的操作，使得系統轉化為正常狀態(A)。

系統在正常運行(A)期間，通過對關鍵設備的情況進行預測，防患于未然，使系統維持在正常狀態。

通過對狀態之間的操作進行分析整理，可以得出下面一些主要的操作：

(1)通過分析設備之間的相互關系，預測系統整體風險，即全局防危(a)；

(2)通過對關鍵設備的情況進行預測，防患于未然，即主動防危(b)；

(3)利用專家規則進行實時判斷和推薦，即實時防危(c)；

(4)對工控系統實施保護并且實現狀態回歸，即自主防危(d)。

通過提供上面這些防危措施，就可以實現工控系統的防危，將工控系統從非正常狀態轉移到正常狀態。同時結合防危技術，實現防危認證。

3 基于數據挖掘的工控防危機制

針對現有的工業控制系統，為加強其防危能力，本文提出以建立工控系統的全局防危機制為主線，通過數據預測技術實現對單點的主動防危；通過建立工控系統復雜網絡模型，研究單點異常對其他節點的影響，實現對整個工控系統的全局防危；提供防危認證，從而實現工控系統的防危。防危的體系結構如圖3所示。

3.1 全局防危

工業控制系統是一個復雜網絡，系統內各設備之間相互依賴和影響。根據工控系統現場環境、歷史數據和經驗，建立工控系統復雜網絡模型，網絡中的節點表示系統中的設備或者關鍵采集點，邊表示設備之間的關聯關系或風險傳遞關系。通過風險傳遞算法，此網絡可以很快收斂，達到穩定狀態，從而可以預測出某一個（或多個）設備出現風險后系統中所有相關設備受影響的情況。通過此網絡模型可以做到對工控系統的整體風險預測和防危。

3.2 主動防危

為了提高系統的安全性，應該開展針對工控系統的趨勢預測。針對工業控制系統中設備的差異性，實現數據預測的通用性，構造適合大部分實際應用環境輸入向量的方法，使用迭代法最大限度地保留實時數據中的歷史信息，并結合系統的閉環反饋實現精確的多步預測，實現滿足工控系統的高效率、高準確率的預測算法。

3.3 實時防危

工業控制系統對實時性要求很高，通過預設的規則和經驗的學習建立專家規則庫。由于專家規則的推理算法時間復雜度較高，為滿足工控系統的實時性要求，可以采用GPU并行處理技術。使用GPU并行處理技術有兩大好處：(1)降低計算時間，滿足工控系統的實時性要求；(2)解放CPU，使實時防危子系統基本不占用 CPU資源。通過專家規則可以及時發現系統的異常節點，通過預設的規則可以給出后續的補救方案，避免更大的損失，做到對系統的實時防危。

3.4 自主防危

在系統處于超負荷情況下，采取合理的措施，在確保系統穩定的前提下，通過優化配置，實現系統的優化運行，確保系統自身的穩定安全。自主防危從大的方面分為兩部分內容：(1)系統監控，監視系統的運行狀態以及各關鍵模塊的狀態，包括進程的狀態、優先級、對于CPU和內存的使用情況（包括數據采集模塊中的數據，各個模塊的內存，以及GPU的信息）；(2)系統的自我管控，當系統發現監控的某些狀態達到峰值，采取措施進行降級處理,避免系統在高負荷下運行發生故障或崩潰。

3.5 防危驗證

防危驗證不僅要考慮失效的頻率，還要兼顧失效的代價，把重要性采樣理論應用于防危驗證，提出基于加速險剖面的防危驗證測試方案。通過分析開發軟件的運行剖面，得到軟件運行的相對發生頻率。然后，對可能導致災難性事故的危險進行分析識別，得到危險剖面。再利用故障樹分析得到安全關鍵運行。最后，生成軟件的安全運行剖面。

測試過程中，如果系統進入危險狀態，就認為軟件存在風險，沒有通過防危驗證，測試不達標。如果所有的測試用例都沒有進入危險狀態，則證明通過了軟件防危驗證，測試達標。

在符合工程實踐的條件下，本文以加強現有工業控制系統的防危能力為目標，針對傳統工控系統防危技術的不足，提出了基于數據挖掘的工控防危機制。設計和綜合出一套能夠進行風險主動預測、故障實時檢測、系統自適應調節的工控系統防危機制及其實現算法，并通過仿真實驗和理論分析的手段，評估防危機制與算法的性能，最終實現對現有工業控制系統的防危保護。

[1]STOUFFER K,FALCO J,SCARFONE K.Guide to industrial control systems(ICS)security[M].National Institute of Standards and Technology,2011:55-62.

[2]Client Company.Quarterly report on cyber security incidents and trends affecting industrial control systems[J].Security Incidents Organization,2009:35-77.

[3]Horng Jaojia,Lin Yishu,Shu Chimin.Using consequence analysis on some chlorine operation hazards and their possible effects on neighborhoods in central taiwan[C].International Conference on the 20th Anniversary of Bhopal Gas Tragedy,The Indian Institute of Technology,2004:3-12.

[4]KONSTANTIN I M,夏光.切爾諾貝利事故:問題的實質[J].科學對社會的影響,1992(03):2-6.

[5]FALCO J,STOUFFER K,WAVERING A,et al.IT security for industrial control systems[M].National Institute of Standards and Technology,2001:201-235.

[6]LAPRIE J C.On the dependability evaluation of high safety systems[C].Proceeding of the 15th International Sym posium on Fault Tolerant Computing,1985:5-16.

[7]LAPRIE J C.Dependable computing:concepts,limits,challenges[J].In Special Issue FTCS-25.Pasadera.CA.1995:42-54.

[8]LAPRIE J C.Dependability of computer systems:concepts,limits,improvements[C].Proceedings 6th International Symposium on Fault Tolerant Computing,1995:12-32.

[9]LEVESON N G.Murphy:expecting the worst and preparing for it[M].The small computer evolution,Arlington,VA,1984:294-300.

[10]ZALEWSKI J,SAGLIETTIC F,et al.Safety of computer control systems:challenges and results in software development,Annual Reviews in control，2003，27(1):23-37.