開發(fā)團隊不斷面臨挑戰(zhàn)，以確保其物聯(lián)網(wǎng)產(chǎn)品的機密性、完整性和可用性。眾所周知的漏洞不斷暴露在連接的產(chǎn)品中。開發(fā)人員通常缺乏識別和關閉新漏洞所需的專業(yè)知識和時間。需要能夠幫助開發(fā)人員和安全工程師實現(xiàn)其安全物聯(lián)網(wǎng)產(chǎn)品目標的工具。

在軟件開發(fā)的早期，人工分析代碼的質(zhì)量缺陷和漏洞。這種類型的代碼檢查仍在敏捷同行評審過程中使用，并可能用于應用程序中的高價值代碼，但無法擴展以滿足現(xiàn)代技術(shù)的需求。例如，麥肯錫公司的一份報告指出，現(xiàn)代汽車中有超過 1.5 億條軟件代碼行 (SLoC)。試圖手動審查此代碼并仍然按時將產(chǎn)品推向市場是不可能的。

確定安全要求

為了定義自動化安全測試，團隊必須首先了解產(chǎn)品威脅。威脅模型應該是任何團隊開展的第一項活動。威脅模型通常是很少閱讀的靜態(tài)文檔，但是，如今有一些工具可以將威脅模型數(shù)據(jù)與用戶故事聯(lián)系起來，并支持創(chuàng)建可在整個開發(fā)過程中運行的自動化測試。

一個有用的例子是WE45的機器人腳本庫。質(zhì)量保證團隊使用機器人框架來創(chuàng)建行為驅(qū)動開發(fā) (BDD) 測試。WE45 開發(fā)了腳本，允許工程師在威脅模型中定義附加到用戶故事的誤用案例，然后將這些誤用案例直接鏈接到自動化測試。這是基于附加工具的使用，例如 YAML 腳本、OWASP ZAP 和其他 SAST/DAST 工具。

無論是使用這樣的框架還是從頭開始，團隊都必須能夠建立安全需求積壓。安全要求可以來自許多來源。產(chǎn)品團隊根據(jù)監(jiān)管要求、最佳實踐指南、安全技術(shù)實施指南 (STIG) 以及威脅模型來定制需求。這些需求被捕獲為產(chǎn)品積壓中的功能用戶故事或驗收測試。

這有效地創(chuàng)建了一個安全需求可追溯性矩陣 (SRTM)，可用于支持自動化安全測試的創(chuàng)建和執(zhí)行。安全用戶故事可以標記為待辦事項中的安全故事。此外，這些故事應包括允許鏈接回安全需求源的元數(shù)據(jù)（例如 IA 控制編號或 STIG 標識符），還應包括與源自需求的自動化測試相關的元數(shù)據(jù)（例如，自動化測試） ID）。這允許自動化框架或其他工具對原始需求具有完全的可追溯性。

當需要測試物聯(lián)網(wǎng)啟用的新型功能時，基礎設施或?qū)Φ葢贸绦?a href="http://www.brongaenegriffin.com/analog/" target="_blank">模擬器也可以證明是有用的。一個例子——之前開發(fā)的一個仿真器用于測試支持車對車 (V2V) 通信的復雜汽車加密證書管理系統(tǒng)。測試團隊在項目開始時定義了錯誤用例，并設計了一個模擬器來自動運行這些錯誤用例。這通過在應用層識別系統(tǒng)的功能安全要求，然后將負面測試用例構(gòu)建到模擬器中來測試整個功能線程。例如，

將安全性集成到產(chǎn)品設計中

一旦記錄了安全要求，產(chǎn)品設計階段就可以從基于模型的安全測試 (MBST) 等方法中受益。MBST 可用于驗證產(chǎn)品設計中是否滿足安全要求。MBST 基于需求的正式建模。今天的產(chǎn)品團隊采用敏捷開發(fā)方法，這意味著設計過程在一系列開發(fā)沖刺中迭代。這使設計人員能夠根據(jù)在沖刺期間開發(fā)的代碼上執(zhí)行的安全工具的反饋，不斷地重新評估其設計的網(wǎng)絡安全態(tài)勢。

例如，對物聯(lián)網(wǎng)產(chǎn)品的掃描可能會發(fā)現(xiàn)對敏感配置文件的讀取訪問權(quán)限未在設備內(nèi)得到適當限制。結(jié)果通知開發(fā)人員需要在文件系統(tǒng)中實施更多限制性特權(quán)。可以設置工具以自動在 JIRA 中打開問題，以根據(jù)適用的行業(yè)最佳實踐建議重新審視產(chǎn)品訪問控制模型的設計，例如“實施基于角色的訪問控制”和“需要提升的訪問權(quán)限”敏感數(shù)據(jù)”，允許設計團隊更新安全架構(gòu)。

在每個沖刺期間執(zhí)行這些掃描的安全工具可以配置為自動運行。開源自動化框架（如Guantlt）直接為 git 提供插件，以支持預提交檢查，自動提醒開發(fā)人員在其桌面上已引入基本錯誤。這允許開發(fā)人員在提交之前糾正錯誤。

可以設置持續(xù)集成工具，例如 Jenkins、Bamboo、Travis、Buildbot、Thoughtworks 等，以集成在每個構(gòu)建上自動運行的安全測試工具。例如，Jenkins 結(jié)合了警告下一代插件，該插件收集和可視化各種安全分析工具收集的問題。這包括代碼分析和運行時應用程序安全工具。還有一些工具（例如 CodeBurner）可以有效地管理多個靜態(tài)分析測試工具的執(zhí)行和報告。

可以自動化不同的安全工具來識別已知漏洞。例如，靜態(tài)代碼分析可以識別和報告代碼中的已知簽名。這些對于識別配置問題、硬編碼憑據(jù)、第三方庫中的漏洞以及映射到CVE的漏洞等問題非常有用。

物聯(lián)網(wǎng)設備固件分析的二進制分析也可用于有效識別已知漏洞，目前有可用的工具，例如 VDOO 的Vision，可以分析基于 Linux、Android 和 Widows 平臺的物聯(lián)網(wǎng)產(chǎn)品。通常用于識別代碼質(zhì)量問題的工具也可以在 CI 中自動運行，并且可以支持快速識別基本問題。其中包括 findbugs、sonarqube 和復制/粘貼檢測器 (CPD) 等工具作為示例。

更深入的測試可以被納入 CI 以開始識別潛在的零日漏洞。這些漏洞尚不為人所知，但可能由專門的安全研究人員或不良行為者發(fā)現(xiàn)?；诜枅?zhí)行的工具可以有效地發(fā)現(xiàn)未知漏洞，但即使是小型二進制文件也可能需要數(shù)小時才能運行。符號測試分析程序以確定導致程序執(zhí)行的輸入。一些工具，如 VDOO 的 Vision 可以集成到 CI 環(huán)境中，為開發(fā)人員提供快速固件分析和更深入的分析能力，旨在識別未知和已知漏洞。

了解基礎知識

雖然安全自動化是一個強大的工具，但它并不是物聯(lián)網(wǎng)產(chǎn)品安全開發(fā)的靈丹妙藥。開發(fā)團隊仍然需要一些最低水平的網(wǎng)絡安全知識和專業(yè)知識來識別獨特的產(chǎn)品威脅和解釋測試工具輸出，以及確保物聯(lián)網(wǎng)硬件和軟件組件的集成。所有開發(fā)人員都有責任至少對與其產(chǎn)品相關的安全問題有基本的了解，并且每個產(chǎn)品團隊都應該擁有了解如何運行和解釋自動化安全工具輸出的安全工程支持。
?