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

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

確定安全要求

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

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

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

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

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

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

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

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

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

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

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

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

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

了解基礎(chǔ)知識

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