作者 | 宗良
編輯 | 濟萌
作者簡介
文思海輝 資訊安全助理副總裁宗良
現任文思海輝資訊技術有限公司全球資訊安全與風險辦公室資訊安全助理副總裁，負責文思海輝全球資訊安全内控，以及對外的內建安全服務。15年以上從業經驗，對軟體開發/測試，服務與項目管理，資訊安全與風險管控，品質與流程體系，教育訓練體系與教育訓練實施等多個方面都有深入了解與實際操作。 序言
随着 DevOps 的實際應用不斷發展，Faster & Faster 的産品釋出推陳出新，一個很嚴峻的問題有待解決：如何確定在快速疊代、快速釋出過程中的産品安全，尤其随着《網絡安全法》等一系列法律法規的完善與釋出，這一問題已經上升到刑事責任而非過往的民事責任的高度。
安全與 DevOps 的整合已經迫在眉睫，本分享将就這一方面，介紹相應的 DevSecOps 的實際實施經驗。
本文的三個部分：
1、Why DevSecOps;
2、What is DevSecOps;
3、How DevSecOps。
一、Why DevSecOps
1.1、傳統的 SDLC 與傳統的應用安全
首先跟大家的分享的是傳統的 SDLC 與傳統的應用安全。在整個傳統的瀑布生命周期裡面，大家可以看到運維是排在最後的，那麼這跟安全存在什麼樣的關系呢？
通過上圖，我們可見在運維過程裡打相關的安全更新檔是運維人員最常遇到的，也是最需要做的日常工作。
但是，實際上運維相關的安全工作并不是隻有一個安全更新檔。在打相關的安全更新檔之前，還存在着許多工作，如：安全需求調研、安全設計工作、安全代碼規範工作和安全測試。
1.2、靈活模型對應的應用安全
下面我們讨論一下安全和靈活是如何有效的結合的。首先是威脅模組化和脆弱性檢測：
- 威脅模組化：這個課題已經存在很久了；但是在國内，就實踐而言我個人來看并不是很完善。
- 脆弱性檢測：從生命周期的角度來看，脆弱性檢測是做什麼用途的呢？如果軟體本身的脆弱性已經做安全測試并覺得沒有問題，但是為什麼還有很多程式在伺服器在生産環境中還是出現了問題？
- 原因很簡單：因為這些漏洞來自于伺服器本身的硬體、作業系統、資料庫等核心中間件的漏洞，并且它們會深層次影響到部署在伺服器上的應用。
故此，就需要用脆弱性檢測這個方法預先找到漏洞。這個就意味着：你在一開發的過程中，需你要合理的考慮未來連接配接通道等等可能帶來的問題。
接下來是兩個測試——靜态應用安全測試和動态應用安全測試。
最後是軟體安全修複和安全代碼教育訓練。
1.3、标準的 DevOps 與應用安全
在 DevOps 整個運作過程中，持續內建和持續釋出變得越來越快了，但足夠安全麼？
下面講述一個真實的案例。我們有一個客戶運用了 DevOps 系統，并且幹的非常棒，從原來的每三周發一個大版本到現在基本上每天出76個版本。
但是，在安全方面系統持續地爆出來各種各樣安全通知；然後，他的上級安全主管部門覺得他的安全管理非常差就給他發了一則安全整改通知并讓其進行專項整頓。
那麼在這個 Faster&Faster 的過程中，他做了測試、開發、檢查；但是，他沒有将安全特性融入進去，其後續的很多版本的 SQL 注入，跨站、中間人劫持這些最基本的安全問題都沒有很好地進行修補。
對于上述的問題，我給大家講幾個概念：
1、SecOps：它的核心理念是自動化，其次是營運，同時把安全作為自動化的方式融進去。但是，EMC 公司本身沒有特别好的産品，是以隻是把這個作為一個服務方式來介紹給他公司的客戶。在這個服務推出來以後，在當時也算業界相對比較領先的安全服務了。
2、SecDevOps：它産生時間是2015年8月17日，是偏向針對主機層的一個安全運維的專家服務。它的核心理念是早期風險模組化，即上述講到的威脅模組化就是 SecDevOp。是以一定要在早期引入，越早期引入越好。
3、DevSecOps：它最主要的提出者是 SANS。SANS 是目前全球最大的安全的公益性、非商業化組織。對于 DevSecOps，SANS 在2016年3月釋出一份白皮書。它的核心理念就是安全和 DevOps 實作共存和共赢，兩者要整合在一起。
将威脅模組化、安全早期的引入和資訊安全融合在一起，這是我們深入地講到的 DevSecOps 這個東西了。
二、What is DevSecOps
2.1、DevSecOps 的概念
在這個 DevSecOps 過程中，核心的思想内容就是用紅色标注出來的部分：一個是自動化，第二個是内嵌整合。那麼在整個過程中，我們會深入地看到幾個東西：
- 威脅模組化。威脅模組化是整個 DevSecOps 裡最重要的以及最核心的一個部分。對于威脅模組化，我們會在後面章節還有詳細的叙述。
- 整合內建。它就是把安全的各種活動作為一個整體內建在一起；同時把安全作為其中的一個基因整合或融入到 DevSecOps 的整個生命周期中。
在這個過程中，圍繞開發的角度和運維的角度來看，會有很多的課題。這些課題有的是從安全的角度解決，有的是從安全的角度隻能給出建議。
但是，不管是建議，還是解決的方式，或者是處置，那麼它所帶來的結果是什麼呢？最常見的一個就是當我們發現問題的時候：
- 首先需要找到問題的識别成本。
- 第二，在發現問題之後需要進行分析成本。
- 第三，就是如何解決和預防成本，并且形成某種程度上的推力。
2.2、DevSecOps 聚焦
從 DevSecOps 聚焦的角度來看，這張圖會很大，但是我們主要就是聚焦：文化、員工、産品、流程和技術，并且将安全融合進去。
2.3、DevSecOps = DevOps + Security Embedded
在本節，我首先給大家三個重要的提示：
- 第一個是自動化測試
- 第二個是持續測試
- 還有一個就是Embedded
這三個重要提示是整個 DevSecOps 裡面最核心的問題。
為什麼說這三者是最核心呢？首先，自動化的測試是在自動化和 DevOps 過程中，将安全基因整合進去。再則，持續測試其實是你要有政策的進行測試達到 TRUST。
TRUST 這個詞在海外非常認可的，整個建設 TRUST 的過程中，最基本的就是威脅模組化，無論何種情況下它會告訴你可能面臨哪些安全隐患、威脅或者風險。
有朋友提到在沒有與網際網路連接配接的情況下，還有安全威脅嗎？一個客戶有A、B、C三個網絡，A類網絡與網際網路沒有實體上的直接連接配接，B類與網際網路之間通過網閘進行邏輯隔離，C類網絡是通過傳統的防火牆進行邏輯隔離。
我們去審查客戶環境的時候，客戶問了一個問題：“我這個A類網絡裡面，你覺得還有必要進行安全防護嗎？”。我回答他這需要從兩個有兩種可能性角度去看。
- 第一種，你現在沒有與網際網路連接配接，但在未來因為業務或者其他特殊需求而改變了現在的部署方式，就要連接配接網際網路了；那麼在這以後，就會發現整個網絡錯漏百出。
- 另外一種，現在不能直接觸碰到你的網絡，但我可以通過其他手段接觸，比如：用無人機作為中繼平台就可以觸及到你的網絡了。故此，在安全領域，有一個安全工具叫無人機反制系統，就是針對這種情況。
上述這個例子就揭示了我們為什麼會需要威脅模組化？威脅模組化不僅要從應用本身來考慮，還要考慮應用所在的主機和中間件等等。因為這是最基本的部分，它帶來的就是安全設計。這意味着一個良好的設計可以減少很多的安全隐患。而安全設計在我們的很多的過程中，并不會被那麼重視，不管在架構中，還是在算法中。
接下來說說安全的測試。它有很多内容：第一個是 SAST，第二是 DAST。在這個過程中，我們把安全作為基因持續內建到開發和測試。這時候會出現一個問題就是在怎麼樣的情況下使用什麼樣的安全政策，比如我們有很多的版本（大版本、小版本、裡程碑版本），以及安全測試的強度不一緻的問題。同時，我們一定要挑出其中跟版本最有關聯的，使其在安全本質上保持一緻。
例如：在全球，我們有一個調查機構叫 Verizon。它每年會出一個叫全球資料洩露調查的報告。在2016年的資料洩露調查報告裡面，此機構做了一個在全球範圍内的統計：“97%的漏洞是來自于我們每年經常看到的 OWASP Top 10” 。
OWASP Top 10這個漏洞會在安全測試的時候成為我們進行安全分級政策的一個重要輸入來源。也就是說，對于小版本而言，我們隻測這10個漏洞有沒有最基礎的呈現就可以了。它就相當于功能測試裡最基礎的冒煙測試。
如果這個都不能過，就不用考慮版本釋出的事宜了。但是對于大版本或是重要的裡程碑而言，我建議不要隻測這10個漏洞了，還需要參看兩個資料（一個是講全球漏洞的 CVE，另一個是講攻擊方式的 CAPEC）。如果你的産品偏向于應用層，我建議你看 CAPEC；如果産品偏向于網絡層，我建議看 CVE。
對于開發過程來說，我們非常建議的是要進行安全狀态的評估。很多的客戶在做開發的時候會有缺失，也就是說他們做了檢測，甚至做的威脅模組化，但是卻沒有做安全狀态的評估。
是以，當生命周期走到釋出的時候，就無法判定能否釋出，因為不知道這個版本有沒有安全隐患以及安全隐患會不會造成影響。其實這個問題産生的根源在兩個部分：
- 第一，前期沒有威脅模組化；
- 第二，沒有規劃好安全測試的分級政策，導緻做安全狀态評估的時候無法記性操作了。
如果我們做好上述這些的話，自然就能得出一個是否是安全的定論。然而，安全測試裡面除了要做 SAST 和 DAST，還有 FUZZ 和法律法規的檢測等等。由于出台國家網絡安全法，是以我們必須要對政策合規性進行合理的考慮（這個合規是合法法律，規是指行政法）。
最後，我要将的就是滲透測試了。滲透測試是模拟黑客進行攻擊的一個測試。從我個人觀點來說，滲透測試還是很有意義的。但是，大家需要注意的是：随着網絡安全法的出台，不管是甲方組織進行滲透測試，還是乙方去做滲透測試，都一定要注意合法合規。簡答來說，合法合規的滲透測試是需要進行報備授權的，也就是說：有報備的叫滲透測試，沒報備的叫黑客攻擊或者被定性為破壞計算機系統罪行。
總結一下，上述我們主要談論到了三個地方。
- 第一個就是剛才談到自動化；
- 第二個是把安全作為基因整個融入到 DevOps 過程中；
- 第三個就是 Embedded。Embedded 意味着什麼呢？用中文是柔性，柔性項目管理，柔性生命周期，柔性就是不是那麼硬，不是強制要求，自發自動主動的去做；否則的話，隻能是前面講的那幾個詞 SecurityDevOps。
DevSecOps 是什麼？是把安全嵌進去了，融入在其他，這才是它真正的核心，這才是它真正的價值所在。
三、How DevSecOps
在整個DevSecOps過程中，存在四個問題：
- 如何設計你的 DevOps 整體的架構，然後把安全融進去；
- 安全怎麼整合；
- 自動化配合 Self-Driven 自驅動；
- V&V 就是品質保證和品質控制。
是以，我們需要更多檢測系統和更多的相關東西，并将這些作為一個整體融在一起，那怎麼融？我個人建議，有三種方式：
- 第一種是以 DevOps 為核心，并把安全內建到釋出過程中，這是一種最常見的融合方式。
- 第二種是把安全作為一道關卡，這也是我推薦的一種方式。比如說冒煙測試就必須通過，如果這個時候不做卻在以後發現問題，那麼安全就不知道要在哪個階段放進去了。
- 對于我門來說，是先做完功能性能的測試，然後再去做安全測試，還是先做安全測試再去做别的呢？這是一個很實際很尖銳的一個問題。那麼，這個就取決于你對實際産品和環境政策的把控了。
- 但是，從安全的角度出發，我建議安全前置，這個是為什麼呢？因為 DevSecOps 有個很重要的隐藏概念叫 Shift Left。它在某種程度上是獨立的以及嵌進去的，意味着在需求早期就要做威脅模組化，而在整體設計前也要做安全設計。
- 安全要走在每一個階段的前面，否則到後面 Faster&Faster 的時候你就沒時間做了。這其實是一個很關鍵的核心，你沒有 Shift Left 以後就沒辦法把安全整合進去就更别談 Embedded。
-
第三種是測試驅動開發，現在是安全驅動整個 DevSecOps，這個概念來自于哪裡？它的來源是：在 Github 有人提供這個東西的原代碼。但是現在它還是原形的東西，是以怎麼做就顯得太激進了。
實話說，我認為安全是要服務于業務，而不能淩駕于業務之上。某種程度上這個方式有點淩駕于業務之上的，是以并不是我推薦的，我推薦的還是第二種。
3.1、安全的自動釋出特性和安全控制特性
上圖是一個很典型的自動化釋出的子產品架構。在這個自動化子產品的架構裡面，安全放在在哪裡？沒有的話，就是會帶來種種的問題。是以，我們需要一個安全的自動化釋出，并考慮把安全性融進去。這就意味着在一起規劃時候，你就要将安全性考慮進去。
3.2、執行個體問題感悟
下面講一個真實的案例。我們有一個客戶上了 DevOps 系統後感覺非常棒。因為，他從原來每三周發一個大版本到現在每天出76個版本。資料顯示上很厲害，但是安全方面持續地爆出來各種各樣安全通知，然後上級主管部門覺得這個客戶安全管理的怎麼這麼差，就給他發了一則整改通知，叫專項整頓。
雖然，他做測試、開發、檢查了，但是他跟安全的特性沒有融進去，然後很多的版本，SQL 注入，跨站、中間人劫持這些最基本的問題，甚至包括前段時間的想哭病毒，他們都有輕微的感染現象。
後來我們幫助客戶上了 DevSecOps 幹，并且我們跟客戶一起去搞。最後的結果，他的76個應用系統、232個釋出單元，全部實作了對應的 DevSecOps。有人問具體工具怎麼做的：首先，商業化工具，其實也就那些大家熟悉的譬如 Fortify、AppScan 之類；此外，用了一些開源的工具；最後，就是也會自研一些東西，自研的東西一定結合客戶場景和應用、實際環境。
3.3、DevSecOps 未來可以整合的元素
對于 DevSecOps 的未來從個人角度說，我認為有六個地方是需要與整個 DevSecOps 進一步深度結合的：
- 第一和第二是人工智能AI和态勢感覺。在現今而言，其實AI和态勢感覺是 DevSecOps 中很重要的一個環節。對于态勢感覺，大家可能從運維的角度或者從安全的角度聽說了很多。但是，在我所見到衆多的态勢感覺系統，其本質上不是态勢感覺系統，而就是一個 SIEM 統一日志平台。
- 可是，在國外并不是這樣的。例如：大概兩年前我跟客戶講 SIEM 不是态勢感覺，而是 SOAPA；那個客戶在前段時間突然間打電話給我說“我終于了解你跟我講的 SOAPA 是什麼事情了”，這個作為小故事這裡分享。
- 那麼我的意思是我們要了解整個趨勢，并且考慮規劃我們的發展，在這個過程中，這六個地方是我看到的能夠與 DevOps 整合的或者與 DevSecOps 整合的最大的六個方面。
- 第三個是智能物聯。現今在很多情況下我們講 DevSecOps 還隻是傳統應用。但是，現今對于 ICS 系統來說某種程度上還是一個空白的區域。
- 第四個是自動模組化。上面我們所談到的威脅模組化是 DevSecOps 一個重要的輸入來源和重要的基礎。但是，自動模組化意味着純粹靠人工模組化會需要極其龐大的工作量。目前，自動模組化都沒有比較成熟的産品。
- 第五和第六是法律法規和證據保全。這兩點就是要告訴你出事兒了怎麼辦以及需要什麼樣的證據來證明做過哪些事情。因為，電子證據在法律法規上是有要求的，而現在我們系統裡很多東西是不能直接作為證據的。尤其，在金融行業裡面，一旦發生重大資訊安全事故或者重大災難的時候，電子證據就成為一個很重要的法律證據。