雖然連接的系統(tǒng)為更容易的監(jiān)控、升級(jí)和增強(qiáng)帶來(lái)了新的機(jī)會(huì),但它們也帶來(lái)了更容易受到攻擊的攻擊面。不幸的是,沒(méi)有一個(gè)連接系統(tǒng)的單一防御可以保證不可穿透性。幸運(yùn)的是,有多個(gè)安全級(jí)別可以確保如果一個(gè)級(jí)別失敗,其他級(jí)別將保持警惕。
這些縱深防御方法可以包括安全啟動(dòng),以確保正確的映像加載;域分離;多個(gè)獨(dú)立的安全級(jí)別 (MILS) 設(shè)計(jì)原則,例如最小特權(quán);攻擊面減少;以安全為中心的測(cè)試,如靜態(tài)和動(dòng)態(tài)分析,最后但并非最不重要的一點(diǎn)是,安全編碼技術(shù)。
雖然如果底層架構(gòu)不安全,安全的應(yīng)用程序代碼在保護(hù)連接的嵌入式系統(tǒng)方面幾乎無(wú)能為力,但在設(shè)計(jì)時(shí)考慮了安全性的系統(tǒng),它確實(shí)起著關(guān)鍵作用。
縱深防御和 V 型模型
傳統(tǒng)上,安全代碼驗(yàn)證的做法在很大程度上是被動(dòng)的。代碼是通過(guò)遵循一些松散的指南來(lái)開(kāi)發(fā)的,然后進(jìn)行性能,滲透,負(fù)載和功能測(cè)試以查找漏洞,這些漏洞稍后會(huì)修復(fù)。
更好、更主動(dòng)的方法可確保代碼在設(shè)計(jì)上是安全的 — 沿時(shí)間線(xiàn)“向左移動(dòng)”。這意味著一個(gè)系統(tǒng)的開(kāi)發(fā)過(guò)程,其中代碼是根據(jù)安全編碼標(biāo)準(zhǔn)編寫(xiě)的,可追溯到安全要求,并隨著開(kāi)發(fā)的進(jìn)展進(jìn)行測(cè)試以證明符合這些要求。
這種主動(dòng)方法將與安全相關(guān)的最佳實(shí)踐集成到功能安全領(lǐng)域開(kāi)發(fā)人員所熟悉的 V-model 軟件開(kāi)發(fā)生命周期中。由此產(chǎn)生的安全軟件開(kāi)發(fā)生命周期(SSDLC)代表了以安全為中心的應(yīng)用程序開(kāi)發(fā)人員的左轉(zhuǎn),并提供了一種實(shí)用的方法,以確保漏洞被設(shè)計(jì)出來(lái)或及時(shí)徹底地解決。
相同的原則可以應(yīng)用于 DevOps 生命周期,從而產(chǎn)生所謂的 DevSecOps。盡管 DevSecOps 和 SSDLC 之間的上下文不同,但左移對(duì)兩者意味著同樣的事情,即早期和持續(xù)地考慮安全性。
盡早并經(jīng)常測(cè)試
此處介紹的所有與安全相關(guān)的工具、測(cè)試和技術(shù)在每個(gè)生命周期模型中都有一席之地。在 V 模型中,它們?cè)诤艽蟪潭壬项?lèi)似于通常與功能安全應(yīng)用程序開(kāi)發(fā)相關(guān)的過(guò)程(圖 1)。

圖 1:在基于 V 模型的安全軟件開(kāi)發(fā)生命周期 (SSDLC) 中使用安全測(cè)試工具和技術(shù)
在 DevSecOps 模型中,DevOps 生命周期在整個(gè)持續(xù)開(kāi)發(fā)過(guò)程中與安全相關(guān)的活動(dòng)疊加在一起(圖 2)。

圖 2:在 DevSecOps 流程模型中使用安全測(cè)試工具和技術(shù)
對(duì)于 V 模型,需求可追溯性在整個(gè)開(kāi)發(fā)過(guò)程中得到維護(hù),對(duì)于 DevSecOps 模型(在每個(gè)圖中以橙色顯示),每個(gè)開(kāi)發(fā)迭代都會(huì)保持需求可追溯性。
一些SAST(靜態(tài))工具用于確認(rèn)遵守編碼標(biāo)準(zhǔn),確保將復(fù)雜性保持在最低限度,并檢查代碼是否可維護(hù)。其他用于檢查安全漏洞,但僅限于在沒(méi)有執(zhí)行環(huán)境上下文的情況下對(duì)源代碼進(jìn)行此類(lèi)檢查的程度。
白盒 DAST(動(dòng)態(tài))使編譯和執(zhí)行的代碼能夠在開(kāi)發(fā)環(huán)境中進(jìn)行測(cè)試,或者更好的是,在目標(biāo)硬件上進(jìn)行測(cè)試。代碼覆蓋率有助于確認(rèn)代碼是否滿(mǎn)足所有安全性和其他要求,以及所有代碼都滿(mǎn)足一個(gè)或多個(gè)要求。如果系統(tǒng)的關(guān)鍵程度需要,這些檢查甚至可以進(jìn)入目標(biāo)代碼的級(jí)別。
可以在單元測(cè)試環(huán)境中使用健壯性測(cè)試來(lái)幫助證明特定函數(shù)是可復(fù)原的,無(wú)論是在其調(diào)用樹(shù)的上下文中隔離。
傳統(tǒng)上與軟件安全相關(guān)的模糊和滲透黑盒測(cè)試技術(shù)仍然具有相當(dāng)大的價(jià)值,但在這種情況下,它們用于確認(rèn)和證明以安全為基礎(chǔ)設(shè)計(jì)和開(kāi)發(fā)的系統(tǒng)的健壯性。
提供雙向可追溯性
IEEE軟件工程術(shù)語(yǔ)標(biāo)準(zhǔn)詞匯表將可追溯性定義為“在開(kāi)發(fā)過(guò)程中的兩個(gè)或多個(gè)產(chǎn)品之間建立關(guān)系的程度,特別是彼此具有前置 - 繼任者或主從關(guān)系的產(chǎn)品。雙向可追溯性意味著可追溯性路徑既向前保持又向后(圖 3)。
自動(dòng)化使得在不斷變化的項(xiàng)目環(huán)境中保持可追溯性變得更加容易。

圖 3:雙向可追溯性
前向可追溯性表明,所有需求都反映在開(kāi)發(fā)過(guò)程的每個(gè)階段,包括實(shí)現(xiàn)和測(cè)試。可以通過(guò)應(yīng)用影響分析來(lái)評(píng)估對(duì)需求或失敗測(cè)試用例的任何更改的影響,然后可以對(duì)其進(jìn)行處理。然后可以重新測(cè)試由此產(chǎn)生的實(shí)現(xiàn),以提供繼續(xù)遵守雙向可追溯性原則的證據(jù)。
同樣重要的是向后可追溯性,它突出顯示了不滿(mǎn)足任何指定要求的代碼。疏忽、錯(cuò)誤邏輯、功能蠕變以及惡意后門(mén)方法的插入都可能引入安全漏洞或錯(cuò)誤。
必須記住,安全嵌入式工件的生命周期將一直持續(xù)到該領(lǐng)域的最后一個(gè)示例不再使用為止。對(duì)此類(lèi)工件的任何妥協(xié)都需要響應(yīng)、更改或新要求,并且需要立即響應(yīng) — 通常是開(kāi)發(fā)工程師長(zhǎng)時(shí)間未接觸的源代碼。在這種情況下,自動(dòng)可追溯性可以隔離所需的內(nèi)容,并僅對(duì)受影響的功能進(jìn)行自動(dòng)測(cè)試。
在實(shí)踐中向左移動(dòng)
左移原則所采用的概念對(duì)于開(kāi)發(fā)安全關(guān)鍵型應(yīng)用程序的個(gè)人和團(tuán)隊(duì)來(lái)說(shuō)很熟悉。多年來(lái),功能安全標(biāo)準(zhǔn)要求采用類(lèi)似的方法。因此,在功能安全領(lǐng)域經(jīng)過(guò)驗(yàn)證的許多最佳實(shí)踐適用于前面討論的安全關(guān)鍵型應(yīng)用程序,包括在開(kāi)始時(shí)(V模型)或每次迭代(DevSecOps)之前建立功能和安全要求,盡早和經(jīng)常進(jìn)行測(cè)試,以及將雙向跟蹤需求應(yīng)用于開(kāi)發(fā)的所有階段。
審核編輯:郭婷
-
嵌入式
+關(guān)注
關(guān)注
5196文章
20323瀏覽量
332192 -
代碼
+關(guān)注
關(guān)注
30文章
4959瀏覽量
73580
發(fā)布評(píng)論請(qǐng)先 登錄
嵌入式系統(tǒng)安全設(shè)計(jì)原則
什么是嵌入式應(yīng)用開(kāi)發(fā)?
arm嵌入式主板優(yōu)缺點(diǎn)
系統(tǒng)嵌入式的學(xué)習(xí)路線(xiàn)
嵌入式系統(tǒng)的定義和應(yīng)用領(lǐng)域
嵌入式開(kāi)發(fā)的關(guān)鍵點(diǎn)介紹
嵌入式實(shí)時(shí)操作系統(tǒng)的特點(diǎn)
如何采用SAFERTOS和ESM保護(hù)嵌入式系統(tǒng)安全
Linux嵌入式和單片機(jī)嵌入式的區(qū)別?
運(yùn)行在嵌入式系統(tǒng)上的emApps
飛凌嵌入式「2025嵌入式及邊緣AI技術(shù)論壇」議程公布
Python在嵌入式系統(tǒng)中的應(yīng)用場(chǎng)景
嵌入式系統(tǒng)開(kāi)發(fā)圣經(jīng)【干貨】
使用Lattice mVision打造嵌入式視覺(jué)系統(tǒng)解決方案
盤(pán)點(diǎn)無(wú)風(fēng)扇嵌入式主板應(yīng)用優(yōu)勢(shì)
向左移動(dòng)以保護(hù)連接的嵌入式系統(tǒng)
評(píng)論