SDL-開篇明義
SDL只是方法論，忌為SDL而SDL
1、sdl是什麼
sdl是安全研發生命周期 ,一個方法論, 理念是安全左移, 通過各種方法、工具、流程設計和交付更安全的軟體,以期望降低安全成本,最終還是為了保護企業和用戶的資產
一圖勝千言,簡化版sdl (偷個懶,太多了,概念性的東西不多說了,我就默認看的都是做過至少了解過sdl的;)
2、為什麼要sdl
成本:應急成本、修復成本、法律成本……
越來越多的安全事件、漏洞、法規要求, 這些成本也愈加明顯,安全左移的需求也愈發迫切
一言以蔽之,設計和交付更安全的軟體,將安全左移動,儘早的發現安全可能的風險以處理、緩解;
從傳統應用安全(注重線上漏洞應急、安全測試)到SDL(全鏈路)其實也代表軟體行業對安全的需求和了解越發深入,從一個「必須解決的問題之一」發展到「應滿足的最低要求之一」,
在歐美這個歷程大概花了10-12年,在中國,可能還需要3-5年左右時間,(也許更快,從這個角度看(應用)安全應該還是在黃金時代初期);
這裡放一張sdl的發展歷程,from 微軟官網//www.microsoft.com/en-us/securityengineering/sdl/about
這張圖裡的資訊量還是比較大的,感興趣的可以去了解下,包括TwC(microsoft-trustworthy-computing)、微軟、思科和adobe在sdl方面的協作共同領導等等;
無論怎麼看,SDL的最終目的還是為了解決應用安全的問題,這一點不能忘記,
也就是說,如果你在做SDL的時候,做的事情不能為這個目的服務,那是沒有意義的
3、實際建設中sdl的誤區及痛
SDL 過程圖示
這裡說一下SDL建設中常見的幾種誤解、誤區,以及帶來的痛;
1、領導對sdl的「誤解」,如:
- 「靈丹妙藥」:覺得sdl一上,應用安全能一下子緩解,不再是老大難
- 投入少:覺得sdl很容易就能實現,招一兩個安全工程師就能落地,最多再搞搞自動化(一個人的sdl,甚至一個人的安全部)
- 實現快:從哪裡聽到看到SDL的這一套流程、工具和效果,就想照搬過來,直接復用,快速實現
- ……
總的來說就是「期望過高+資源很少」
2、其它部門對SDL的感受或「誤解」,比如
- 找事的,因為需要相關同學給到配合,資訊同步、做出相應action,舉幾個例子:
- 需求對應產品,要同步需求資訊、評審會議資訊、填寫checlist或問答表、根據安全建議修改需求業務邏輯(或流程圖)、上線要滿足安全要求才能上線
- 開發對應研發:要同步程式碼提交資訊給程式碼審計、要按照安全標準進行開發、要更新升級存在漏洞的三方包、要修復安全測試出的漏洞
- 集成發布對應研發及應用運維:要添加三方包檢測(Nday及版權)、對接白盒掃描、對接自動化測試(IAST、DAST、SAST)
- 測試對應QA:同步測試進度、同步測試用例評審會資訊、測試數據環境帳號等等
- pmo:每個環節都要管,都要參與,你們是不是pmo啊
- ……
3、安全人員對sdl的實施誤區
- 完全照搬:比如上面的sdl過程圖示,各種規範、自動化上來就整一堆,推給各部門團隊
- 心急:沒摸清公司安全狀況,沒理清背景、需求就上馬
- 拿來主義,生搬硬套,而不是因地制宜:舉個例子,在上家公司經過兩年摸索、建設,結合devops做成了一些安全自動化的東西,到新公司想在半年內就把原來的這套搭建起來,但這家公司沒有相應的devops、IT能力支援,業務場景、產品類型也不同,結果費了大力做出來卻效果不理想;更甚者,直接網上找來一些就去推廣,自然被產品、研發懟的鼻青臉腫,後續工作也不好開展;
- 沒有自己的節奏,尤其是遇到上面描述的情形和領導時,容易被牽著走,結果也很不好
- 軟性能力不足,受環境影響過大:在好的環境下有好的同事配合可以干好,而遇到自己不喜歡的環境、同事,就干不好
這些感受或「誤解」、「誤區」,加上工作或環境中的問題, 會帶來SDL推行、落地時的各種困難,比如:
- 領導的要求不現實
- 被領導牽著鼻子走,亂了步子
- 同步資訊不及時、忘了甚至不願同步
- 問卷填寫隨意填,不一定真實正確
- 漏洞沒修復就要上線,帶傷上陣
- 修復時間一拖再拖,要跟在後面催
- 只要安全沒卡點,就可以不用care
- ……
這樣下來,搞得自己和大家都很累,也沒成果,最終黯然離場或混吃等死…
4、應該怎麼做
SDL只是方法論，忌為SDL而SDL
為什麼會有上面那些誤解、誤區,
- 投入與預期 「既要馬兒跑得快,還不給馬兒吃草」
- 首先理解偏差,且太強調SDL,一定成度上將其「神話」了不同的人知識儲備、能力、「屁股」都不相同,有理解偏差很正常,但要避免「神話」、「過分超出預期」;
- 其次,工作開展方式問題,這個不能說是誰的問題,只能說結果不好,我們要去改進;
- 另外還有就是我們的軟能力(如溝通、協調協作、管理、價值觀等等)不足,需要加強,安全從業者多數是技術出身,這個問題也是技術同學的通病,但企業安全建設,尤其是sdl需要跨部門、溝通協作的地方格外多,那麼出問題時不足也凸顯了;
應該怎麼做
- 也是前提,定好安全的戰略目標(長期目標):要做成什麼樣的安全,實現什麼樣的效果,可以不用那麼明確,大致期望即可,也是要跟領導傳達安全需要時間,需要資源,是個長期投入、長期建設的事情;
- 同樣也是前提,定出中短期的安全工作,根據風險評估(安全現狀)來制定
- 摸索出適合這家企業的打法節奏,要根據業務、團隊、IT能力、同事等等因素來定,需要有個摸索過程,不同階段、相應的項目or工具或平台;摸索的過程靠自己,共通之處可以借鑒(後面有機會展開~)
- 應用安全的合理性,開展的背景要明確(問boss、問leader、問自己),有答案了再做後面的事情,且要通曬同步對齊;
- 有些彎路是必須要走的:摸索的過程,找出合適的方法,同時也是給相關部門、團隊、人一個了解接受的時間,這個過程繞不過去也有必要;
- 跟直屬領導常溝通、常同步,方式很多:開會、主動討論、周報(如周報 描述重點項目、解決什麼問題、遇到什麼問題和困難,需要什麼協助;不用太細)
- 定期安全情況報告,可以分環節分對象來,比如漏洞管理情況、比如某業務的迭代需求及測試用例評審、安全測試結果;體現價值,涮存在感,獲得認同;
- 提升軟能力,建議根據冰山模型+學習提升管理能力
另外在公司安全建設戰略甚至戰術層面,不要過分強調「要做SDL」,個人認為沿用「應用安全」這個詞會好很多,包括減少不必的溝通成本和超預期的情況,尤其是在資源不足,「一個人SDL」、甚至「一個人安全部」的情況下,好好把基礎的東西做起來, 用能爭取到資源,解決主要的風險,就一個字「穩」;
徐徐圖之, 其他的留給時間(拿多少錢辦多少事,話糙理不糙);如果時間不能解決,那….該幹嘛幹嘛吧 (基操勿6)
各方面也都是再向成熟趨勢走的,包括技術、整體IT能力、公司管理,對安全的投入等等, 安全治理 工作是要基於這些因素來開展的;
理清楚做SDL的目的,找到背景,順理成章開展;不忘來路,始知歸處;
總結&後續:
SDL只是一個方法論,只是一種手段，而不是目的，目的是讓我們的產品更安全:設計與交付更安全的軟體,來保護公司及用戶資產;
如果盲目為了SDL而SDL,完全follow SDL ,結果必然是悲慘的,就算你能完全實現,那最直接的就是沒業務了,公司就搞安全了… 因地制宜,適合自己的才是最好的,我們做SDL其實真正花時間去思考解決的就是找到合適的方法將SDL方法論落地來達到目標,這個順序我們要明確,通俗一點說:有些彎路是必須要走的;
方法論是一種以解決問題為目標的理論體系或系統，通常涉及對問題階段、任務、工具、方法技巧的論述。方法論會對一系列具體的方法進行分析研究、系統總結並最終提出較為一般性的原則。
當然有許多工具、經驗是就在那裡,也值得我們去借鑒的,涉及對問題階段、任務、工具、方法技巧,都能夠提煉到一些共通的東西,這些後面具體展開,這裡先說一下大致的思路;
首先確定我們的產品是有安全問題的，以前有過(比如外部白帽測試)，現在也有，以後也會有，這個跟bug是一個道理.
那麼怎麼就能更安全，目前就是在做測試,我們在測試SDL這個方法是否可行，類似我們要採購某個產品工具，我們要先測，測功能，測性能，測效果;分步驟在進行.
試點，是一個很常用的手段,(在流程、工具、效果、不同業務線適用度都需要做試點),在一家企業要做sdl時,第一個試點就是測試sdl流程能否在這家企業跑通，能否工作運轉起來；同時也會測效果，能否提升安全，但這塊後續還會有試點項目來進行驗證；第一個試點建議找比較穩定的項目，來測流程是比較合適的。試點過程中會發現很多問題,不僅是流程或安全知識技能、工具,還有公司環境、人等方面的,這些不同企業所特有的問題是更需要思考去解決的; 總結出問題、嘗試解決方法、(比如溝通成本高,能否有方便溝通雙方的方法,工具?比如覆蓋率低,比如不配合等等,詳見上面的困難)
那如果測試結果發現SDL不管用，不能跑通，或者不能使我們更安全，(當然不太可能，畢竟這個是業界比認可的，但不同場景公司是有自己的特殊性，就不適用通用別人公司的方法)，或者遇到各種問題, 效果沒我們想像中的好，那我們就換一種方法，或者參考/添加一些方法、元素，比如SAMM，比如以前的測試修復模式，比如BSIMM,比如事件驅動，比如威脅建模等等，或者取這些方法的優點，來做一個適合自己的東西出來，當然 我們也可以繼續把這個東西叫做SDL，只要結果是對的就好，是能提升我們產品安全性即可。
當然 這些話沒必要對老闆去講，老闆只要結果。
我們在過程中去做去改進即可去拿到結果。實在要說，就一句話：我們在不斷改進，得到更適合我們自己的方法來進行。
那麼目前看來，闊以提取到的通用元素的是什麼(設計交付更安全的軟體的要素),比如：
- 流程(闊以借鑒PMP，項目管理方面知識)
- 工具化自動化
- 人員及能力
- 威脅建模(安全分析設計能力)
- ……
接下來就是如何將這些元素在自己的公司里/場景下實現、串聯、運轉到落地應用
這些元素在不同企業里落地時的共通點,以及涉及的軟能力提升
後續一個一個展開,先挖坑,待填(但願不會太監)
- SDL-建設的兩種模式
- SDL–與devsecops
- SDL–人員及能力之冰山模型與SDL建設
已發表於freebuf原創 //www.freebuf.com/articles/es/232252.html,格式跟這裡略有不同
