我是怎么把研發安全做“沒”了的

2019-06-19 367874人圍觀 ,發現 19 個不明物體 系統安全

我叫王大錘,萬萬沒想到,我成了馬欄山不省心集團的研發安全工程師……這一定是對我的終極考驗,相信用不了多久我就會升職加薪,當上總經理,出任CEO,迎娶白富美,走向人生巔峰。想想,還有點小激動。

言歸正傳,老板說,我的職責是在研發同事的日常研發過程中不同環節介入不同安全能力,從而實現對項目進行上線前安全質量管控。

再詳細點說就是在下面圖里的開發編碼和測試階段,介入安全廠商不同商用工具進行安全檢測和修復,并且以制度形式完善落地效果。

圖片1.png

想想我王大錘是什么人,這點小事在我手里簡直信手拈來,一想到自己接下來的無限前景,簡直….嘿嘿嘿。

圖片2.png

說干就干,首先,是研發環節,簡單說就是程序員寫代碼的環節,這個環節我們馬欄山不省心集團介入的是標準的SAST(靜態應用安全測試)。

把項目源碼導入,它就會自動化利用已有規則進行安全檢查,嘿你別說,這工具還挺靈光,一個項目就能掃出3000+漏洞!再來我把漏洞報告提交給研發人員修復,我的工作就萬事大吉啦!

然而我還是Too Young,研發同事沒一會就拎著平底鍋過來找我說,他們拿著報告測試了前500個漏洞,居然有450個是誤報,于是他們當場炸毛,要求我給他們驗證這3000+個漏洞哪些需要他們修復,否則他們不處理該報告。

圖片3.png

OMG,光一個項目就3000+個漏洞等著讓我去一一驗證,我哪還有時間去完成我的工作進度,一想到老板還在等我的部門產出,我仿佛看到了各色獎金在離我而去。

沒辦法,為了大局考慮,我決定放松在研發階段的安全檢查,畢竟,我們還有后面測試環節的安全介入不是~

測試環節我們馬欄山不省心集團介入的是標準的DAST(動態應用安全測試),也就是俗稱的漏掃,方式是在測試環節將項目地址提供給某商用工具,該工具會自動構造請求與項目交互,隨著測試時間越長,工具構造的請求能夠進入的項目功能邏輯分支就越多,檢測深度就越完善,效果就越好,而且由于是動態測試,誤報率的情況比SAST簡直不知道好到哪里去!

然而事實告訴了我,我不僅Too Young,而且還Naive。

圖片4.png

我忽略了一個嚴重的問題,集團研發項目進度普遍較快,各環節里程碑時間都較為緊湊,研發人員工作量、交付壓力普遍較大,故在有限時間下,習慣性將主要精力聚焦在功能問題,主觀意識上未將研發安全歸為己任,加上DAST工具和規章的介入會在一定程度上打亂他們工作安排和進度,所以實際使用過程中DAST的介入掃描時間、深度往往不盡如人意。

很多研發、測試人員故意就只拿它測了個大概,拿我們安全工具“走過場”,漏洞依然遺留,導致上線后的項目安全能力“千瘡百孔”。

圖片5.png

看著手拿白帽子漏洞報告的老板逐漸垮下來的嘴角,我不禁感到絲絲涼意……于是決定拿出我最后的倔強。

既然項目已經上線,不敢貿然做業務切割的排查,于是我購買了最為一流的WAF,把規則控制得天衣無縫,什么?你說我有SQL注入?有XSS?有本事利用給我看吶!

然而,萬萬沒想到,運維同事說我的WAF攔截干擾了他們的正常業務,要求我交出WAF的規則控制權,由他們進行攔截規則管控,于是所有規則被他們限制到最寬松,“為正常業務讓路”,一同被讓進來的,還有一眾數不清的攻擊利用手段,于是,我最后的倔強,分崩離析。

圖片6.png

我是王大錘,我成了馬欄山不省心集團的研發安全工程師,萬萬沒想到,最終一通操作之后,我從研發到測試甚至上線后的安全建設全部名存實亡,成功把研發安全做“沒”了。。。

看著這攤狼藉,一想到已經沒法升職加薪,當上總經理,出任CEO,迎娶白富美,走向人生巔峰,我最終決定抄起《企業安全從入門到跑路》,開辟另一番天地。

微信圖片_20190613141247.gif

王大錘的從業經歷,相信大家都會有所感觸。那不妨我們今天就來分析一些問題出在哪里,以及應該如何進行應對。

簡單歸納起來,上述問題的核心無非是SAST誤報高無法落地、DAST過度依賴構造請求的準確率,導致的不定量漏報;以及上述兩個環節對研發過程的侵入性,而導致的落地推進阻力,最終使得安全不得不以被動防御的姿態運用在項目上線之后。

那反過來說,如果我們能夠解決DAST的漏報問題,通過新型技術進一步精化其檢測能力,并以該環節為安全保證基礎反推研發環節SAST的規則構建,實現規則告警“少而精”,解決SAST的高誤報問題,同時在這兩個環節做到柔和無感知,不更改相關人員原有工作方式,降低落地阻力,上述的各種問題,是不是就能解決了呢?

這正是默安科技正在專注的主要方向之一——研發安全技術革新,通過完整自研“服務+工具+平臺”SDL全流程方案,基于微軟經典SDL(安全開發生命周期)模型,將賦能服務貫穿需求分析、架構設計、研發、測試回歸以及發布迭代全流程。

8.png

微軟SDL(安全開發生命周期)模型

通過賦能將專業安全能力賦予研發各環節人員,并在各環節提供不同工具(STAC、SAST、IAST、常態化安全運營),使賦能知識真實應用落地,最終以統一平臺展示、分析、回歸、閉環安全問題,并向安全部提供SIEM(安全信息和事件管理),根據各流程頻現的漏洞類型、研發人員知識盲區等再次提供針對性培訓和制定規章制度,實現制度精準逆推落地。

測試環節以交互式安全測試(IAST)替換原有DAST,交互式應用程序安全測試通過無感知的方式獲取功能測試人員測試交互流量,并以此取代動態應用安全測試的自行構造模式,同時基于模糊測試(fuzz)思想對流量進行攻擊代碼隨機插入和攻擊流量構建,自動化對被測程序進行安全測試,并在測試過程中借助插樁監控平臺對被測程序的運行軌跡進行實時跟蹤和介入,一旦攻擊流量觸發安全問題,插樁平臺不僅可以第一時間捕獲安全問題,精確定位到漏洞所在的代碼文件、行數、函數及參數。

通過這種方式,交互式應用安全測試既能保證檢出漏洞的有效性,有效降低誤報漏報率,還能夠精準定位漏洞,幫助研發人員更好地進行漏洞修復和回歸,有效提升測試過程安全檢測能力。

同時,IAST的新型測試模式還可以覆蓋更多傳統DAST無法觸及的安全范疇,包括邏輯類漏洞檢測自動化、雙向加密數據獲取等,實現更為良好的安全檢測能力。

微信圖片_20190613141446.jpg

測試環節有了IAST這樣強力的安全支持后,SAST將不再是割裂的一環,我們就可以在SAST部分進行規則精簡,確保只檢出與其核心規則匹配的安全問題,所有與其規則匹配度較低,存在“模棱兩可”情況的潛在安全隱患,SAST均可以通過反饋機制交由下一環節的IAST部分進行實際運行攻擊測試。

換言之,通過階梯式檢測方案,在研發不同階段介入最為適合的檢測方式和最優檢測規則,確保在每個流程上都只檢出真實漏洞。而所有需要確認的漏洞,交由IAST過程使用真實漏洞攻擊代碼進行檢測,確保更為有效的真實漏洞檢出概率并降低誤報導致的人工分析成本。

同時SAST通過與git、svn等代碼倉庫聯動,自動化拉取全量或增量代碼進行代碼安全檢查,以波谷時間檢測方式在上班時間前根據提交歷史以郵件形式同時相關責任人,降低對相關人員工作方式更改和落地阻力。

通過上述測試和研發環節的安全建設,大量漏洞得已在項目上線前被解決,故上線后的安全能力將不再必須以被動防御的姿態進行。

9.png

同時,上線迭代的項目安全風險來源已不僅僅只有其本身,該項目使用的服務器、服務器提供的中間件以及項目本身這三個維度均可能是風險來源,故默安科技建議用戶使用常態化安全運營方案,對項目上線后所在的服務器資產、中間件以及項目本身進行7*24小時周期性安全檢查,相當于有一個安全團隊或滲透測試工程師全天候管理線上資產、站點以及中間依賴的安全問題,有效確保安全健壯性。

在上述環節完成后,我們則可以進行最后一輪安全前置,即項目需求分析、架構設計環節基于業務場景的威脅建模(STAC),以威脅建模賦能和提供針對性checklist方式教會需求分析和架構審計人員對項目內場景潛在風險進行識別和剝離,通過威脅建模針對性提出安全方案,用于后續研發等環節的解決或規避,完成SDL的最后一環,真正實現從需求分析、架構設計、研發、測試以及上線運營五個環節的安全能力全方位介入。

回到文章開頭的故事,主人公王大錘如果能夠擁有這樣的系統化專業方案,相信他想把研發安全做“沒”都難~

*本文作者:劉雋良@默安科技,轉載請注明來自FreeBuf.COM

這些評論亮了

  • xxx 回復
    默安叼得很,基本都是安全大佬一心研發產品,工作時間找官網客服都找不到,本甲方只能默默退避.
    )47( 亮了
  • 默安科技 (3級) 杭州默安科技有限公司 回復
    @ xxx “很多安全大佬”我也就認了,但工作時間找不到客服這個必須澄清:周一至周五 9:30-18:00,0571-57890068,默安客服一直在線!隨時恭候甲方爸爸的來電咨詢!
    )18( 亮了
  • 補丁君 (4級) Love&Peace 回復
    前面的情節看得挺爽的 :mrgreen:
    )11( 亮了
  • 確實是很現實的問題,企業著重點不一,安全變成錦上添花的投標的項,而非必要項,整個生命周期竟沒有安全的一席之地,這是很多企業同樣面臨的問題
    )10( 亮了
  • linda琳達0?? 回復
    護網用幻陣,SDL用靂鑒
    )8( 亮了
發表評論

已有 19 條評論

取消
Loading...

特別推薦

推薦關注

填寫個人信息

姓名
電話
郵箱
公司
行業
職位
css.php 重庆百变王牌走势图