工業控制系統的安全性可保護國家基礎設施

從發電廠到工廠再到供水，工業控制系統正在從專有和封閉的網絡轉變為物聯網的一部分。安全的開發過程可以減少這些關鍵基礎設施中的軟件漏洞。

從發電廠到工廠再到供水，工業控制系統正在從專有和封閉的網絡轉變為物聯網的一部分。安全的開發過程可以減少這些關鍵基礎設施中的軟件漏洞。

在一個可能讓大多數軟件開發人員感到震驚的情況下，計算機蠕蟲已經成為電影明星。在新動作驚悚片《零日》中，反派炸毀了化工廠，關閉了核電冷卻系統，破壞了火車，關閉了國家電網等等。這部快速移動的動作片的明星是臭名昭著的Stuxnet蠕蟲，據報道，這是由美國和以色列情報部門開發的，旨在削弱伊朗的核計劃。Stuxnet攻擊了控制核電站內離心機的可編程邏輯控制器（PLC），但蠕蟲及其變體可以針對一系列制造，運輸和公用事業操作中的系統進行定制。

正在看電影的公眾基本上沒有意識到潛伏在我們互聯基礎設施中的危險——這些危險一直困擾著工程師和開發人員。通常，工廠自動化系統使用監控和數據采集（SCADA）系統運行，以實現人機界面和訪問。IEC61508標準及其衍生物的實施是為了確保在廣泛的行業中運行這些系統的軟件的功能安全。但是，這些SCADA系統（通?；赪indows或Linux）又連接到企業管理，企業管理需要訪問庫存控制，營銷，會計和許多其他目的。當然，這些都與外部互聯網相關聯，因此為來自外部的攻擊提供了完美的途徑。因此，雖然早期的封閉系統依靠不幸或惡意的個人來手動安裝蠕蟲，但今天的互聯網連接工業系統提供了新的攻擊面。由于這種高水平的連接性和攻擊風險，如果系統不安全，則不能認為它是安全的。

IEC61508及其衍生產品沒有專門針對安全性。開發人員需要解決從產品開發階段到上市后管理的網絡安全問題。為了遵守各種準則和要求，開發人員必須使用足夠的工具來處理高復雜性。隨著這些系統越來越受到認證要求的約束，編碼的正確性必須與所需的功能一起得到證明和記錄。

開發安全代碼的核心是設計一個策略，該策略可以基于網絡安全指南，例如美國國家標準與技術研究院（NIST）發布的指南，以及組織自己的方法，并將其構建到正在開發的系統的需求文檔中。此外，該項目應采用MISRA C等編碼標準，以防止可疑的方法和粗心大意的錯誤，這些錯誤可能會危及安全性，而不會立即顯現出來，甚至導致功能錯誤。當然，下一個重要步驟是確保這種策略和編碼標準實際上已經有效地執行。由于當今軟件的規模和復雜性，這不再可以手動完成，必須使用一套全面的工具，可以在編譯之前和之后徹底分析代碼。

使用可追溯性和分析來驗證安全性

雖然定義需求是必不可少的第一步，但必須有一個明確定義的方法來跟蹤和驗證是否滿足需求。需求可追溯性和管理可提高代碼質量以及應用程序的整體安全性、安全性和有效性?；谛枨笪臋n的雙向可追溯性可確保每個高級需求都由一個或多個低級需求覆蓋，并且每個低級需求都鏈接到代碼、驗證活動和流程中生成的工件。同樣，這些鏈接必須追溯到從工件和代碼到需求的上游，確保流程中任何階段的任何更改都可以輕松檢測、理解和適當地管理（圖 1）。

圖1 需求可追溯性工具提供了流程透明度，對于確定開發流程所有階段的影響分析至關重要。

需求可追溯性工具允許團隊處理單個活動，并將代碼和驗證工件鏈接回更高級別的目標。在雙向需求可追溯性的監督下，在開發過程的早期和連續階段應用了三個主要功能。這些是靜態分析，功能測試和結構覆蓋分析的動態分析以及單元/集成測試。后者在開發過程的早期應用靜態和動態分析，也適用于后期集成的代碼。

靜態和動態安全分析合作伙伴

在確保安全性時，兩個主要問題是數據和控制。必須考慮的問題包括，誰有權訪問哪些數據？誰能從中讀取，誰可以寫信給它？與哪些實體之間的數據流是什么？以及訪問控制如何影響控制？在這里，“誰”可以指開發人員和操作員以及黑客等人，也可以指應用程序中的軟件組件或居住在網絡架構中的某個地方。為了解決這些問題，靜態和動態分析必須齊頭并進。

在靜態分析方面，這些工具使用未編譯的源代碼來檢查代碼的各種質量指標，例如復雜性，清晰度和可維護性。靜態分析還可用于根據選定的編碼規則檢查代碼，這些規則可以是支持的編碼標準（如MISRA C或CERT C）的任意組合，以及開發人員或公司可能指定的任何自定義規則和要求。這些工具尋找可能危及安全性的軟件構造，并檢查內存保護以確定誰有權訪問哪些內存并跟蹤可能遍歷內存位置的指針。理想情況下，結果應以圖形屏幕顯示，以便于評估結果，以確保代碼干凈、一致且可維護，并符合編碼標準（圖 2）。

此過程可以通過運行分析工具并針對應用程序的源代碼進行編碼標準定義來自動完成。幾乎可以肯定的是，此類代碼需要修改，以符合已添加到 MISRA C 中的最新安全要求（圖 2）。

圖2 編碼標準合規性與文件/功能名稱內聯顯示，以顯示系統的哪些方面不符合標準。編程標準調用圖顯示了系統編碼標準合規性的高級彩色編碼視圖。

另一方面，動態分析測試已編譯的代碼，該代碼使用編譯器生成的符號數據鏈接回源代碼。動態分析，特別是代碼覆蓋率分析，可以提供對測試過程有效性的深刻見解。但是，開發人員通常嘗試手動生成和管理自己的測試用例。從需求文檔開始工作是生成測試用例的典型方法，它們可能會以不同程度的有效性刺激和監視應用程序的各個部分，但考慮到當今代碼的大小和復雜性，這不足以使代碼正確無誤或獲得可能需要的任何認證或批準。

自動生成測試用例可以大大增強測試過程，節省時間和金錢。但是，有效的測試用例生成基于代碼的質量靜態分析。靜態分析提供的信息有助于自動測試用例生成器在動態分析期間為應用程序中的軟件組件創建適當的激勵?？梢允謩觿摻üδ軠y試以擴充自動生成的測試用例，從而提供更好的代碼覆蓋率和更有效和更高效的測試過程。手動創建的測試通常是從需求生成的，即需求驅動的測試。這些應該包括任何功能安全測試，例如模擬嘗試訪問控制設備或向其提供會改變其任務的錯誤數據?；趧摻ǖ臏y試的功能測試應包括魯棒性，例如測試不允許的輸入和異常條件的結果。此外，動態分析不僅提供代碼覆蓋率，還提供數據流/控制分析，反過來可以使用雙向需求可追溯性來檢查其完整性。

除了測試是否符合標準和要求外，還有必要檢查可能是“血統不明的軟件”或SOUP代碼的任何部分。例如，存在與“死”代碼區域相關的危險，這些區域可能被黑客激活或系統中的晦澀事件用于惡意目的。盡管從頭開始實現安全性是理想的，但大多數項目都包含預先存在的代碼，這些代碼可能具有看起來只是所需的功能。開發人員需要抵制自動引入此類代碼（甚至是來自同一組織的代碼），而無需對其進行與他們自己的代碼完全相同的嚴格分析。靜態和動態分析一起使用可以揭示死代碼的區域，這些區域可能是危險源，也可能只是占用空間。有必要正確識別此類代碼并進行處理，通常是通過消除它。當開發團隊（可能在完全不同的位置）開發、測試、修改和重新測試單元時，可以存儲、共享和使用從綜合工具套件生成的測試記錄，同時將單元集成到更大的項目中。

為了使系統可靠和安全，它們還必須是安全的。為此，它們必須被編碼為不僅遵守語言規則，而且還要遵守確保安全和保障的明確定義的策略。將一套全面的測試和分析工具應用于組織的開發過程，可以大大提高安全措施的徹底性和準確性，以保護重要系統。它還使團隊為共同目標而共同努力并對最終產品充滿信心的努力變得順利。由此產生的產品將有更好的機會獲得客戶批準，如果需要，還可以獲得當局的認證 - 并且它不太可能成為下一部大片的明星。