敏捷項(xiàng)目中的安全需求管理
在軟件開(kāi)發(fā)初期處理安全需求是防止安全問(wèn)題最經(jīng)濟(jì)的方式。大多數(shù)安全需求都屬于非功能性需求(Non-Functional Requirements ,NFRs)。很多從業(yè)者發(fā)現(xiàn),在敏捷項(xiàng)目中處理安全和其他NFR非常具有挑戰(zhàn)性。原因有二:
匹配N(xiāo)FR和特性驅(qū)動(dòng)的用戶故事需要付出很大努力;
安全控制常因缺少可見(jiàn)度而被忽視。敏捷過(guò)程容易讓團(tuán)隊(duì)不自覺(jué)地側(cè)重于那些可以直觀改善客戶體驗(yàn) 的新功能開(kāi)發(fā)或缺陷修復(fù)。
在本文中,我們會(huì)探討以上兩個(gè)問(wèn)題。
在用戶故事中處理NFR
敏捷專(zhuān)家們提出過(guò)一些方法,用以定義用戶故事驅(qū)動(dòng)的開(kāi)發(fā)過(guò)程中的NFR。Mike Cohn在他的文章中討論了評(píng)論者們提出的一些有趣的建議。Scott Ambler就該主題寫(xiě)了一系列文章,旨在證明并非所有的NFR都可以獨(dú)立存在于用戶故事中。而Dean Leffingwell可以說(shuō)在這方面做了最深入的研究,他在自己的著作《敏捷軟件需求》中花了整整一章探討該主題。這些專(zhuān)家中大部分人都認(rèn)為,NFR大致可以分成兩類(lèi):
非功能性用戶故事:以用戶故事的形式展現(xiàn)的可測(cè)試功能塊。這些用戶故事中的參與者(Actor)可能是內(nèi)部IT人員。例如:“作為安全分析師,我希望系統(tǒng)能抑制不成功的身份認(rèn)證嘗試,這樣應(yīng)用程序在面對(duì)暴力破解時(shí)不至于太過(guò)脆弱”。
約束:這是個(gè)跨領(lǐng)域的問(wèn)題,常常涉及多個(gè)用戶故事。我們可以將它看作是對(duì)所有相關(guān)開(kāi)發(fā)工作收取“課稅”。例如:開(kāi)發(fā)Web應(yīng)用時(shí),要求所有開(kāi)發(fā)者對(duì)Http表單中的字段進(jìn)行數(shù)據(jù)校驗(yàn)即為一種約束。
處理第一類(lèi)NFR很簡(jiǎn)單:創(chuàng)建一系列的NFR用戶故事,將它們加入某種工作序列,例如Product Backlog。
NFR約束的挑戰(zhàn):
然而處理第二類(lèi)NFR則困難很多。敏捷專(zhuān)家們對(duì)此提出過(guò)一些解決辦法,包括:
在特定的用戶故事中添加恰當(dāng)?shù)募s束作為驗(yàn)收標(biāo)準(zhǔn)
在某個(gè)中央知識(shí)庫(kù)——例如,貼在墻上或者發(fā)表在wiki上的一份文件——中維護(hù)包含所有約束的列表。
但無(wú)論哪個(gè)方法都無(wú)法解決的問(wèn)題是,如何針對(duì)特定的用戶故事選擇適用的約束。而且,使用SD Elements進(jìn)行安全需求匹配的經(jīng)驗(yàn)表明,要將這些技術(shù)限定在一定范圍之內(nèi)很困難。下面這個(gè)列表是標(biāo)準(zhǔn)Web應(yīng)用需要面對(duì)的安全約束中的一部分,我們以此為例:
在SQL語(yǔ)句中以變量綁定的方式阻止SQL注入
對(duì)來(lái)自客戶端的只讀數(shù)據(jù)進(jìn)行完整性驗(yàn)證,以防止參數(shù)篡改
避開(kāi)存在于HTML、HTML屬性、CSS以及JavaScript中的不可信數(shù)據(jù),從而防止跨站點(diǎn)腳本攻擊)(XSS)
避免客戶端JavaScript中基于DOM的XSS
使用安全的算法以避免整型溢出
不接受外部重定向以防止自由重定向攻擊
授權(quán)給受保護(hù)的頁(yè)面,以防止權(quán)限提升攻擊)
使用防止跨站請(qǐng)求偽造(CSRF)的令牌
驗(yàn)證輸入
盡量使用正則表達(dá)式,因?yàn)樗鼘?duì)于拒絕服務(wù)攻擊有較強(qiáng)的抵抗力。
為高價(jià)值的事務(wù)實(shí)現(xiàn)事務(wù)身份認(rèn)證
不要硬編碼密碼
該列表列舉的可能只是程序員在實(shí)現(xiàn)用戶故事時(shí)需要考慮的安全約束中的一小部分。若將需要遵循的法規(guī)標(biāo)準(zhǔn)——諸如支付卡行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn)(PCI DSS)之類(lèi)——考慮在內(nèi),約束還要增加不少。如果你開(kāi)始添加其他NFR約束,例如可訪問(wèn)性,約束列表會(huì)快速增長(zhǎng),轉(zhuǎn)眼間就會(huì)超過(guò)程序員的承受范圍。一旦列表變得臃腫,我們的經(jīng)驗(yàn)是,程序員往往會(huì)將它全部忽略,僅根據(jù)自己的記憶來(lái)應(yīng)用NFR約束。而在很多不斷專(zhuān)業(yè)化的領(lǐng)域——例如應(yīng)用安全——NFR的數(shù)量不斷增長(zhǎng),這給程序員的記憶力造成了沉重的認(rèn)知負(fù)擔(dān)。因此,如何使用靜態(tài)分析技術(shù)偵測(cè)代碼中違背NFR約束之處就成了關(guān)注重點(diǎn)。研究表明,靜態(tài)分析可以偵測(cè)出的可預(yù)防缺陷最多不超過(guò)總數(shù)的40%,也就是說(shuō)仍有大量的約束漏網(wǎng),包括特定領(lǐng)域的安全控制,更別說(shuō)在缺乏定制的情況下辨別靜態(tài)分析產(chǎn)生的“假陽(yáng)性”結(jié)果也不是那么簡(jiǎn)單。
應(yīng)對(duì)NFR約束的挑戰(zhàn)
為了解決NFR約束過(guò)多的問(wèn)題,我們需要做到以下四點(diǎn):
按優(yōu)先級(jí)排序:與用戶故事和缺陷一樣,NFR約束也應(yīng)擁有不同的優(yōu)先級(jí),例如:相較于避開(kāi)HTML中的不可信數(shù)據(jù)以防止持續(xù)的跨站腳本攻擊,對(duì)HTTP響應(yīng)頭中的不可信數(shù)據(jù)進(jìn)行編碼或校驗(yàn)以防止HTTP響應(yīng)拆分攻擊就不那么重要。因此我們假定程序員通常沒(méi)有足夠的時(shí)間處理所有約束,然后我們提供一種機(jī)制為如何定義約束的相對(duì)優(yōu)先級(jí)提供建議。之所以說(shuō)“建議”,是因?yàn)閮?yōu)先級(jí)有可能隨著具體情況的變化而變化,程序員需要自己作出判斷——對(duì)于他們的特定代碼,哪種相對(duì)優(yōu)先級(jí)是適用的。你可以選用簡(jiǎn)單的優(yōu)先級(jí)設(shè)置,如“高、中、低”,也可以使用數(shù)字范圍,如1-10。
過(guò)濾:使用簡(jiǎn)單的標(biāo)準(zhǔn)常常就可以為特定的用戶故事移除大量的NFR約束。舉例來(lái)說(shuō),假如你正在實(shí)現(xiàn)的用戶故事與表現(xiàn)層無(wú)關(guān),那么就可以安全地忽略大量表現(xiàn)層相關(guān)的約束。使用標(biāo)簽系統(tǒng)或者簡(jiǎn)單的Excel過(guò)濾器,就可以為特定的用戶故事削減約束數(shù)量。以下是一些Web應(yīng)用相關(guān)的安全性約束過(guò)濾器的范例:
用戶故事是否涉及用戶輸入;
用戶故事是否涉及保密數(shù)據(jù),如密碼、信用卡信息以及非公開(kāi)的財(cái)務(wù)數(shù)據(jù);
用戶故事是否返回一個(gè)全新或修正過(guò)的用戶輸出,例如一個(gè)網(wǎng)頁(yè);
用戶故事是否與數(shù)據(jù)庫(kù)進(jìn)行交互;
用戶故事是否會(huì)暴露或使用來(lái)自RESTful 或SOAP API調(diào)用的數(shù)據(jù);
用戶故事是否會(huì)訪問(wèn)受保護(hù)的數(shù)據(jù)(例如,不是所有用戶都能查看或修改的數(shù)據(jù))。
情境(Context):程序員在寫(xiě)代碼或定義任務(wù)單(tickets)/ 用戶故事的時(shí)候更容易記起并應(yīng)用約束。理想情況下,如果把約束列表內(nèi)嵌入IDE或任務(wù)單系統(tǒng),那么程序員就可以在編碼時(shí)獲取相關(guān)的約束。既然現(xiàn)在很多IDE都支持內(nèi)嵌的Web瀏覽器,那么使用輕量級(jí)的網(wǎng)站或者SharePoint站點(diǎn)就可以實(shí)現(xiàn)這個(gè)目標(biāo)。
框架:框架可以大幅減少約束產(chǎn)生的“稅收”。例如,像 Django這樣的框架自帶了CSRF防護(hù),這意味著程序員可以安全地忽略該約束,除非他們主動(dòng)繞過(guò)這個(gè)內(nèi)建的功能。根據(jù)我們的經(jīng)驗(yàn),多數(shù)大型的應(yīng)用軟件都會(huì)采用某種形式的定制框架,這些框架可以無(wú)縫處理最高優(yōu)先級(jí)的約束。雖然這樣的框架定制可能需要較高的先期投入,但如果你將約束看成一種基于用戶故事的“稅收”,那么減少約束數(shù)量就相當(dāng)于永久性的降低了“稅率”。
驗(yàn)證
雖然主動(dòng)處理NFR很重要,但仍有必要進(jìn)行驗(yàn)證。如果你有手動(dòng)代碼審查(Code Review)的經(jīng)驗(yàn),就可以檢查用戶故事中作為驗(yàn)收標(biāo)準(zhǔn)出現(xiàn)的NFR。然而,如果僅使用手動(dòng)代碼審查,很多約束的驗(yàn)證將是非常棘手或者繁重的。靜態(tài)分析工具則可以自動(dòng)檢查編碼標(biāo)準(zhǔn)的遵守情況,其中一些產(chǎn)品特別關(guān)注安全方面。將你的靜態(tài)分析工具與持續(xù)集成過(guò)程整合在一起,可以幫助你始終遵守編碼標(biāo)準(zhǔn)。但也務(wù)必注意,不要一味依賴(lài)于代碼審查。防范特定領(lǐng)域缺陷——如HTTP參數(shù)篡改——的NFR要求對(duì)背后的業(yè)務(wù)領(lǐng)域有深刻的理解。將手動(dòng)驗(yàn)證與針對(duì)特定攻擊的自動(dòng)測(cè)試結(jié)合起來(lái),可以幫助我們建立一套對(duì)于特定領(lǐng)域缺陷擁有更強(qiáng)抵抗力的系統(tǒng)。
可見(jiàn)度
難以將安全需求集成進(jìn)敏捷項(xiàng)目的另一方面原因是安全需求通常缺乏可見(jiàn)度。面向客戶的會(huì)議,如Scrum的Sprint評(píng)審會(huì)議),容易使開(kāi)發(fā)人員產(chǎn)生一種固有的傾向,即實(shí)現(xiàn)用戶故事或修復(fù)缺陷時(shí)傾向于那些能直接改善用戶體驗(yàn)的故事或缺陷。一部分非功能屬性,例如易用性和性能,對(duì)于系統(tǒng)的使用體驗(yàn)有具體的影響,因此也比較容易向客戶展示。而另外一些——如安全性——卻很難在Sprint評(píng)審會(huì)議上給客戶留下很好的印象。實(shí)際上,某些安全特性,如賬號(hào)封鎖(Account Lockout),可能給客戶體驗(yàn)帶來(lái)相當(dāng)負(fù)面的影響。大多數(shù)安全特性對(duì)系統(tǒng)的影響,普通用戶很難察覺(jué)。因此,安全性NFR是不可見(jiàn)的,它們必須和可見(jiàn)度更好的特性競(jìng)爭(zhēng),以?shī)Z得寶貴的開(kāi)發(fā)周期。在軟件開(kāi)發(fā)初期,準(zhǔn)確的說(shuō)在程序員應(yīng)該構(gòu)建安全特性的時(shí)候,處理這些“隱形”需求的機(jī)會(huì)成本會(huì)特別高。
讓安全特性可見(jiàn)
對(duì)于敏捷團(tuán)隊(duì)來(lái)說(shuō),沒(méi)有“銀彈”能讓安全需求在開(kāi)發(fā)伊始就擁有最高優(yōu)先級(jí)。但有一些方法可以讓安全NFR對(duì)客戶和/或PO可見(jiàn)。
圖形化安全用戶故事:如果你在應(yīng)用程序安全方面足夠?qū)I(yè),就可以針對(duì)已知的安全弱點(diǎn)創(chuàng)建一套全面的安全控制。然后將它們與NFR用戶故事匹配起來(lái),并繪制簡(jiǎn)單的圖形,用以說(shuō)明系統(tǒng)中已實(shí)現(xiàn)的和未實(shí)現(xiàn)的安全用戶故事數(shù)量。這個(gè)圖可以放在大型可視圖表中。
圖1:安全用戶故事圖
當(dāng)然,這個(gè)圖沒(méi)必要局限于安全用戶故事,你可以將其他重要的NFR囊括進(jìn)來(lái)。實(shí)際上,你可以使用故事點(diǎn)(Story Point)取代用戶故事數(shù)量,從而更準(zhǔn)確的反映工作量。另外,你有可能希望圖中只記錄那些針對(duì)高風(fēng)險(xiǎn)安全問(wèn)題的、擁有最高優(yōu)先級(jí)的用戶故事或控制。每完成一個(gè)故事,“已完成”數(shù)量都會(huì)增加,客戶也會(huì)籍由此圖直觀地了解項(xiàng)目的進(jìn)度。
展示可利用性(exploitability):沒(méi)有什么比可利用性展示更能讓人們理解一個(gè)安全漏洞的各個(gè)方面了。這是安全性滲透測(cè)試和漏洞評(píng)估的主要區(qū)別。你可以展示在上一版本的應(yīng)用中如何成功地利用了漏洞,而在新的版本中卻沒(méi)辦法這么做了。然后你可以從對(duì)業(yè)務(wù)和/或客戶影響的角度解釋漏洞的方方面面。這非常有利于解釋為什么在安全控制上花的時(shí)間是合理的。
結(jié)論
主動(dòng)處理NFR,特別是安全特性,在敏捷環(huán)境中非常重要。不少專(zhuān)家對(duì)于如何處理此類(lèi)需求——特別是當(dāng)它們與創(chuàng)建用戶故事相關(guān)時(shí)——給出了建議。全面地處理約束是個(gè)相當(dāng)大的挑戰(zhàn)。記住本文討論的提議,你可以極大地增加維護(hù)一系列約束的價(jià)值。即使不能完全做到以上所提的四點(diǎn)內(nèi)容以改善對(duì)約束的管理,但從長(zhǎng)遠(yuǎn)來(lái)看,任何一點(diǎn)改進(jìn)都能帶來(lái)很高的回報(bào)。進(jìn)行驗(yàn)證能保證團(tuán)隊(duì)始終遵守NFR。最后,提高安全特性的可見(jiàn)度,可以讓你證明用在NFR上的時(shí)間是合理的,就算它們對(duì)系統(tǒng)的改善不能反映到用戶體驗(yàn)上。
posted on 2014-08-14 09:28 順其自然EVO 閱讀(216) 評(píng)論(0) 編輯 收藏 所屬分類(lèi): 測(cè)試學(xué)習(xí)專(zhuān)欄