SDL只是方法論，忌爲SDL而SDL

一、sdl是什麼 

我的看法:“sdl是安全研發生命週期 ,一個方法論, 理念是安全左移, 通過各種方法、工具、流程,設計和交付更安全的軟件,以期望降低安全成本,最終還是爲了保護企業和用戶的資產”

一圖勝千言,簡化版sdl (偷個懶,太多了,概念性的東西不多說了,我就默認看的都是做過至少了解過sdl的;)

簡化版sdl

二、爲什麼要sdl

成本,應急成本、修復成本、法律成本……

越來越多的安全事件、漏洞、法規要求, 這些成本也愈加明顯,安全左移的需求也愈發迫切;

從傳統應用安全(注重線上漏洞應急、安全測試)到SDL(全鏈路)其實也代表社會及軟件行業對安全的需求和了解越發深入,從一個“必須解決的問題之一”發展到“應滿足的最低要求之一”,

在歐美這個歷程大概花了10-12年,在我國,可能還需要3-5年左右時間,(也許更快,從這個角度看(應用)安全應該還是在黃金時代初期);

這裏放一張sdl的發展歷程,from 微軟官網 https://www.microsoft.com/en-us/securityengineering/sdl/about 這張圖裏的信息量還是比較大的,感興趣的可以去了解下,包括TwC(microsoft-trustworthy-computing)、微軟、思科和Adobe在sdl方面的共同協作倡導等;

SDL TimeLine

無論怎麼看,SDL的最終目的還是“設計和交付更安全的軟件,以期望降低安全成本,最終還是爲了保護企業和用戶的資產“,爲了解決應用安全的問題,這一點不能忘記,也就是說,如果你在做SDL的時候,做的事情不能爲這個目的服務,那是沒有意義的  

三、實際建設中sdl的誤區及痛

這裏說一下SDL建設中常見的幾種誤解、誤區,以及帶來的痛;

1、領導對sdl的“誤解”,如:

“靈丹妙藥”:覺得sdl一上,應用安全能一下子緩解,不再是老大難

投入少:覺得sdl很容易就能實現,招一兩個安全工程師就能落地,最多再搞搞自動化(一個人的sdl,甚至一個人的安全部)

實現快:從哪裏聽到看到SDL的這一套流程、工具和效果,就想照搬過來,直接複用,快速實現

……

總的來說就是“期望過高+資源很少”

2、其它部門對SDL的感受或“誤解”,比如

找事的,因爲需要相關同學給到配合,信息同步、做出相應action,舉幾個例子:

需求對應產品,要同步需求信息、評審會議信息、填寫checlist或問答表、根據安全建議修改需求業務邏輯(或流程圖)、上線要滿足安全要求才能上線

開發對應研發:要同步代碼提交信息給代碼審計、要按照安全標準進行開發、要更新升級存在漏洞的三方包、要修復安全測試出的漏洞

集成發佈對應研發及應用運維:要添加三方包檢測(Nday及版權)、對接白盒掃描、對接自動化測試(IAST、DAST、SAST)

測試對應QA:同步測試進度、同步測試用例評審會信息、測試數據環境賬號等等

pmo:每個環節都要管,都要參與,你們是不是pmo啊

……

3、安全人員對sdl的實施誤區

SDL 過程圖示

完全照搬:比如上面的sdl過程圖示,各種規範、自動化上來就整一堆,推給各部門團隊

心急:沒摸清公司安全狀況,沒理清背景、需求就上馬

拿來主義,生搬硬套,而不是因地制宜:舉個例子,在上家公司經過兩年摸索、建設,結合devops做成了一些安全自動化的東西,到新公司想在半年內就把原來的這套搭建起來,但這家公司沒有相應的devops、IT能力支持,業務場景、產品類型也不同,結果費了大力做出來卻效果不理想;更甚者,直接網上找來一些就去推廣,自然被產品、研發懟的鼻青臉腫,後續工作也不好開展;

沒有自己的節奏:尤其是遇到上面描述的領導時,容易被牽着走,結果也很不好

軟性能力不足,受環境影響過大:在好的環境下有好的同事配合可以幹好,而遇到自己不喜歡的環境、同事,就幹不好

這些感受或“誤解”、“誤區”,加上工作或環境中的問題, 會帶來SDL推行、落地時的各種困難,比如:

領導的要求不現實

被領導牽着鼻子走,亂了步子

同步信息不及時、忘了甚至不願同步

問卷填寫隨意填,不一定真實正確

漏洞沒修復就要上線,帶傷上陣

修復時間一拖再拖,要跟在後面催

只要安全沒卡點,就可以不用care

一段時間後沒成果,領導或他人甚至自己都覺得沒價值

……

這樣下來,搞得自己和大家都很累,也沒成果,最終黯然離場或混喫等死…

四、應該怎麼做

SDL只是方法論，忌爲SDL而SDL

爲什麼會有上面那些誤解、誤區,

投入與預期   “既要馬兒跑得快,還不給馬兒喫草”

理解偏差,且太強調SDL,一定成度上將其“神話”了不同的人知識儲備、能力、“屁股”都不相同,有理解偏差很正常,但要避免“神話”、“過分超出預期”;

工作開展方式問題,這個不能說是誰的問題,只能說結果不好,我們要去改進;

另外還有就是我們的軟能力(如溝通、協調協作、管理、價值觀等等)不足,需要加強,安全從業者多數是技術出身,這個問題也是技術同學的通病,但企業安全建設,尤其是sdl需要跨部門、溝通協作的地方格外多,那麼出問題時不足也凸顯了;

應該怎麼做

 1、也是前提,定好安全的戰略目標(長期目標):要做成什麼樣的安全,實現什麼樣的效果,可以不用那麼明確,大致期望即可,也是要跟領導傳達安全需要時間,需要資源,是個長期投入、長期建設的事情;
 2、同樣也是前提,定出中短期的安全工作,根據風險評估(安全現狀)來制定,同時最好能估算出之前、現在的安全成本,這樣在SDL一段時間後,可以對比體現價值;
 3、摸索出適合這家企業的打法節奏,要根據業務、團隊、IT能力、同事等等因素來定,需要有個摸索過程,不同階段、相應的項目or工具或平臺;摸索的過程靠自己,共通之處可以借鑑(後面有機會展開~)
 4、應用安全的合理性,開展的背景要明確(問boss、問leader、問自己),有答案了再做後面的事情,且要通曬同步對齊;
 5、有些彎路是必須要走的:摸索的過程,找出合適的方法,同時也是給相關部門、團隊、人一個瞭解接受的時間,這個過程繞不過去也有必要;
 6、跟直屬領導常溝通、常同步,方式很多:開會、主動討論、週報(如週報 描述重點項目、解決什麼問題、遇到什麼問題和困難,需要什麼協助;不用太細)
 7、定期安全情況報告,可以分環節分對象來,比如漏洞管理情況、比如某業務的迭代需求及測試用例評審、安全測試結果;體現價值,涮存在感,獲得認同;
 8、提升軟能力,建議根據冰山模型+學習提升管理能力

另外在公司安全建設戰略甚至戰術層面,不要過分強調“要做SDL”,個人認爲沿用“應用安全”這個詞會好很多,包括減少不必的溝通成本和超預期的情況,尤其是在資源不足,“一個人SDL”、甚至“一個人安全部”的情況下,好好把基礎的東西做起來, 用能爭取到資源,解決主要的風險,就一個字“穩”;

徐徐圖之, 其他的留給時間(拿多少錢辦多少事,話糙理不糙);如果時間不能解決,那….該幹嘛幹嘛吧  (基操勿6)

各方面也都是再向成熟趨勢走的,包括技術、整體IT能力、公司管理,對安全的投入等等, 安全治理 工作是要基於這些因素來開展的;

理清楚做SDL的目的,找到背景,順理成章開展;不忘來路,始知歸處;

五、總結&後續:

SDL只是一個方法論,只是一種手段，而不是目的，安全左移理念,目的是設計與交付更安全的軟件,來保護公司及用戶資產,同時降低安全的成本;

如果盲目爲了SDL而SDL,完全follow SDL ,結果必然是悲慘的,就算你能完全實現,那最直接的就是沒業務了,公司就搞安全了… 因地制宜,適合自己的纔是最好的,我們做SDL其實真正花時間去思考解決的就是找到合適的方法將SDL方法論落地來達到目標,這個順序我們要明確,通俗一點說:有些彎路是必須要走的;

方法論是一種以解決問題爲目標的理論體系或系統，通常涉及對問題階段、任務、工具、方法技巧的論述。方法論會對一系列具體的方法進行分析研究、系統總結並最終提出較爲一般性的原則。

當然有許多工具、經驗是就在那裏,也值得我們去借鑑的,涉及對問題階段、任務、工具、方法技巧,都能夠提煉到一些共通的東西,這些後面具體展開,這裏先說一下大致的思路;

sdl建設思路

首先確定我們的產品是有安全問題的，以前有過(比如外部白帽測試)，現在也有，以後也會有，這個跟bug是一個道理.

那麼怎麼就能更安全，目前就是在做測試,我們在測試SDL這個方法是否可行，類似我們要採購某個產品工具，我們要先測，測功能，測性能，測效果;分步驟在進行.

試點，是一個很常用的手段,(在流程、工具、效果、不同業務線適用度都需要做試點),在一家企業要做sdl時,第一個試點就是測試sdl流程能否在這家企業跑通，能否工作運轉起來；同時也會測效果，能否提升安全，但這塊後續還會有試點項目來進行驗證；第一個試點建議找比較穩定的項目，來測流程是比較合適的。試點過程中會發現很多問題,不僅是流程或安全知識技能、工具,還有公司環境、人等方面的,這些不同企業所特有的問題是更需要思考去解決的; 總結出問題、嘗試解決方法、(比如溝通成本高,能否有方便溝通雙方的方法,工具?比如覆蓋率低,比如不配合等等,詳見上面的困難)

那如果測試結果發現SDL不管用，不能跑通，或者不能使我們更安全，(當然不太可能，畢竟這個是業界比認可的，但不同場景公司是有自己的特殊性，就不適用通用別人公司的方法)，或者遇到各種問題, 效果沒我們想象中的好，那我們就換一種方法，或者參考/添加一些方法、元素，比如SAMM，比如以前的測試修復模式，比如BSIMM,比如事件驅動，比如威脅建模等等，或者取這些方法的優點，來做一個適合自己的東西出來，當然 我們也可以繼續把這個東西叫做SDL，只要結果是對的就好，是能提升我們產品安全性即可。

當然 這些話沒必要對老闆去講，老闆只要結果。

我們在過程中去做去改進即可去拿到結果。實在要說，就一句話：我們在不斷改進，得到更適合我們自己的方法來進行。

那麼目前看來，闊以提取到的通用元素的是什麼(設計交付更安全的軟件的要素),比如：

流程(闊以借鑑PMP，項目管理方面知識)

工具化自動化

人員及能力

威脅建模(安全分析設計能力)

……

接下來就是如何將這些元素在自己的公司裏/場景下實現、串聯、運轉到落地應用;

這些元素在不同企業裏落地時的共通點,以及涉及的軟能力提升,凸顯價值等等

後續一個一個展開,先挖坑,待填(但願不會太監)

SDL-建設的兩種模式

 SDL–與devsecops   
 SDL–人員及能力之冰山模型與SDL建設
 ……

*本文作者：若水行，轉載請註明來自FreeBuf.COM