近幾年,伴隨云計算、容器技術以及 DevOps 的普及,DevSecOps 作為糅合了開發(fā)、安全及運營理念的全新方法,其關注熱度持續(xù)上升,并在全球范圍內(nèi)得到廣泛應用。目前 IAST 被部分業(yè)內(nèi)人士看作一種“更適合 DevSecOps 流程構建”的應用程序安全檢測技術,受到行業(yè)的更多關注。那么 IAST 是否真的更適合 DevSecOps 流程構建?它能夠提供哪些核心能力和關鍵技術,以及有哪些局限性,未來前景如何?對此,安全牛特別邀請到火線安全洞態(tài) IAST 產(chǎn)品負責人董志勇先生,就 IAST 和 DevSecOps 的相關話題展開探討。
安全牛:
在您看來,目前DevSecOps的痛點和難點是什么?
董志勇:
要了解 DevSecOps 的痛點和難點,首先要弄明白 DevSecOps 到底是什么。根據(jù) Gartner 定義,DevSecOps(即 Development、Security 和 Operations)是指在不減少敏捷度和開發(fā)者效率,或在不要求開發(fā)者離開現(xiàn)有工具鏈的情況下,將安全盡可能無縫、無感知地集成進 IT 和 DevOps 開發(fā)中。
DevSecOps 有三個核心點:一是便于集成,安全工具可以很方便的與現(xiàn)有的 IT 或 DevOps 流程對接和打通,這也是實現(xiàn) DevSecOps 的前提條件;二是無感知,要求安全工具對已有的 DevOps 流程不能產(chǎn)生任何的影響和干擾;三是在研發(fā)階段解決安全問題,而不是像傳統(tǒng)開發(fā)流程一樣,在軟件上線后由安全人員檢測問題,再反饋給研發(fā)人員來解決問題。問題越早的檢測和修復,企業(yè)的整體修復成本就越低,這也是 DevSecOps 的核心目的之一。目前來看,DevSecOps 在落地時遇到的主要痛點和難點也體現(xiàn)在這三個點上。
在 IAST 技術出現(xiàn)之前,我們熟知的安全技術是動態(tài)應用程序安全測試技術(DAST)和靜態(tài)應用程序安全測試技術(SAST),這兩種技術在 DevSecOps 流程構建中有其獨特優(yōu)勢,但也有各自的不足。
DAST 的優(yōu)點是檢測結(jié)果準確,因為它拿的是真實 Payload(有效載荷),在運行的應用程序上直接做漏洞驗證。DAST 發(fā)現(xiàn)問題后,沒有代碼層的相關信息,這可能會給研發(fā)人員解決問題帶來一定的成本,同時其檢測時間較長、會產(chǎn)生臟數(shù)據(jù)等,不能滿足 DevSecOps 對無感的要求;SAST 的檢測結(jié)果對于開發(fā)人員來說比較友好,但由于工具無法直接理解代碼,尤其是開發(fā)人員在寫代碼時,引用的各種設計模式和新奇的技術,這些原因都會導致 SAST 漏洞檢測的誤報率存在挑戰(zhàn),給到研發(fā)人員時,不能保證報告的準確性,影響使用。
安全牛:
IAST 可以幫助 DevSecOps 進行哪些應對呢?
董志勇:
IAST 是交互式應用程序安全測試(Interactive Application Security Testing),是一種新的應用程序安全測試方案,通過在服務端部署 Agent ,收集、監(jiān)控應用程序運行時的函數(shù)執(zhí)行、數(shù)據(jù)傳輸?shù)刃畔?然后根據(jù)污點跟蹤算法、值傳遞算法等一系列算法進行漏洞的識別。
IAST 是一種應用程序運行時的漏洞檢測技術,所以它具備了 DAST 中檢測結(jié)果準確的特征;此外,IAST 采集到數(shù)據(jù)在方法內(nèi)部的流動后,通過污點跟蹤算法來進行漏洞檢測,用算法來進行漏洞檢測,所以檢測結(jié)果也具備了 SAST 中全面性的特征。
同時因為 IAST 安裝在應用程序內(nèi)部,安全人員可以拿到類似于源碼級漏洞報告,這種漏洞結(jié)果對于開發(fā)人員很友好,可以方便開發(fā)人員進行漏洞修復。綜合來看,IAST 具有高檢出率、低誤報率、檢測報告詳細便于排查等一系列優(yōu)勢,可以很好地在 DevSecOps 流程中解決痛點和難點。
安全牛:
基于 IAST 來構建 DevSecOps 流程,所依靠的關鍵性技術有哪些?
董志勇:
對于這個問題,我的理解是如何用 IAST 來構建 DevSecOps ,或者說是構建 DevSecOps 流程時,IAST 必須具備哪些功能才能支撐這個流程的構建。我個人認為大概有三點。第一點,IAST 必須柔和地嵌入 DevOps 流程,即十分便利地與 CI/CD 流程對接,包括與 Jenkins 、Gitlab 等工具打通等;第二點,當 IAST 和 DevOps 流程對接時,需要做版本的控制,支持在 Agent 端直接指定項目名稱和版本,進行后續(xù)的版本跟蹤,以及版本的漏洞對比等;第三點,IAST 可通過漏洞復測與回歸測試,驗證此前發(fā)現(xiàn)的漏洞是否依舊存在。
安全牛:
相比較其他應用程序安全測試模式,您認為 IAST 的核心能力有哪些?其在具體的場景應用中又會存在哪些局限性?
董志勇:
IAST 本質(zhì)是做漏洞檢測,其核心能力主要包括四點:一是實時的漏洞檢測,保證不影響 DevOps 的原有效率;二是第三方組件的梳理和漏洞檢測,保證應用避免供應鏈的攻擊;三是靈活的漏洞檢測邏輯,讓用戶在使用內(nèi)置檢測邏輯的同時,很方便地配置出具有業(yè)務屬性的特定檢測邏輯,來做業(yè)務層面的漏洞檢測;四是極低的運營成本,IAST 在企業(yè)內(nèi)部使用時,一定是需要持續(xù)運營的,當出現(xiàn)了 IAST 沒有覆蓋到的漏洞情況時,可以用最低的成本來完善檢測策略和檢測邏輯,保證漏洞的檢出。
IAST 的局限性主要體現(xiàn)在 IAST 的內(nèi)置漏洞策略有限、且無業(yè)務屬性,無法保證檢測所有的安全風險;推薦在上線前通過白盒、灰盒、黑盒、人工滲透測試一起來檢測漏洞,然后將 IAST 沒有覆蓋到的漏洞策略補充進來;上線后可通過外部的眾測、SRC 運營等手段,更全面地發(fā)現(xiàn)安全風險,同時將漏洞策略補充到 IAST 中,做后續(xù)的自動化測試。
安全牛:
目前國內(nèi) IAST 產(chǎn)品的代表類型有哪些?從應用的角度看其主要差異是什么?
董志勇:
根據(jù) Gatner 定義,IAST 特指被動插樁的這種模式,但由于開發(fā)難度等一系列原因,在國內(nèi)出現(xiàn)了一些臨時性的解決方案,如:將黑盒改造成 IAST ,另外也有將 RASP 與掃描器結(jié)合形成主動插樁的方案。
主動插樁的原理是在應用程序上安裝 Agent,Agent 采集應用程序從外部獲取數(shù)據(jù)的入口,以及最終觸發(fā)漏洞的關鍵位置信息,然后聯(lián)動外部掃描器,把流量數(shù)據(jù)發(fā)到掃描器上,掃描器根據(jù)漏洞庫,或者根據(jù)主動式對應的 POC 庫,來做一些流量的重組、重放,實現(xiàn)對漏洞的檢測。它在檢測漏洞的時候,是看外部掃描器端重組的 POC 有沒有到達上次出現(xiàn)危險的位置。
主動式有很大的局限性:一,從整個行業(yè)來看,應用的安全性越來越高,比如驗證碼、數(shù)據(jù)包加密、防重放等一些安全措施越來越完善。在這樣的背景下,主動式 IAST 依賴流量重放進行漏洞檢測,比如:滑動驗證碼場景下,IAST 無法重放流量,此時,便無法檢測對應位置的漏洞;二,主動式 IAST 需要進行流量重放,會產(chǎn)生大量的臟數(shù)據(jù),影響功能測試結(jié)果;三,應用程序的技術架構整體趨勢是向微服務、分布式等方向發(fā)展,在微服務中,服務間可能不用傳統(tǒng)的 Http 請求進行通信,比如使用基于 TCP 協(xié)議的 RPC 請求。此時,主動式 IAST 無法發(fā)起 RPC 請求,也就無法進行漏洞檢測。
被動式 IAST 的檢測原理,是在應用程序上安裝 Agent ,安全人員進行正常的功能測試時,外部會有一定的流量進入。在這種模式下,所有進來的流量數(shù)據(jù)都會被標記為不可信,并分析不可信數(shù)據(jù)在內(nèi)部應用程序中如何變化,如何流轉(zhuǎn),類似于生物學上的基因傳遞流程。它只需要分析不可信數(shù)據(jù)在應用程序內(nèi)部的變化情況,重點分析數(shù)據(jù)的流向和傳播,然后用“算法 + 數(shù)據(jù)流”進行漏洞檢測,根據(jù)不可信數(shù)據(jù)未經(jīng)任何有效處理直接到達危險函數(shù)的方法,來判定漏洞是否存在,無需做流量重放。前文所提到的驗證碼、數(shù)據(jù)包加密或者防重放場景,以及分布式、微服務的技術架構下都可以使用被動式 IAST 進行漏洞檢測。
從整個行業(yè)趨勢上來說,應用本身的安全性越來越高,只有被動式 IAST 才能兼容所有的場景,在實現(xiàn)漏洞檢測的同時,滿足 DevOps 流程下高效、準確等要求,所以最佳選擇一定是被動式 IAST 。
安全牛:
用戶在選擇 IAST 產(chǎn)品時,應從哪些維度進行評估?
董志勇:
第一點是使用成本,它體現(xiàn)在幾部分,其一是產(chǎn)品在 Server 端的部署成本,其二是在 Server 端的升級成本,其三是當把 Server 端部署和升級之后,Agent 在業(yè)務線上的推廣成本,或者 Agent 在使用過程中的升級成本等。所以整體來看,需要綜合考慮:Server 端的部署成本, Server 端的升級成本,Agent 端的部署升級成本以及 Agent 端的推廣成本。
第二點是漏洞檢測能力,建議直接把 IAST 部署到企業(yè)內(nèi)部真實業(yè)務線上試運行兩到三個月。根據(jù)“是否檢測到漏洞,及漏洞檢測的準確率”,對比哪款產(chǎn)品檢測效果更佳,這是最實際的評估方法。第三點是 IAST 的整體擴展性,在企業(yè)落地 IAST 時,需評估其是否能夠便利地與已有業(yè)務系統(tǒng)較好結(jié)合。可通過查看其 API 接口是否完善、需要的數(shù)據(jù)是否都能獲取。火線安全洞態(tài) IAST 直接開放源代碼,方便用戶做二次開發(fā),因此可擴展性更強。
第四點是前文提到的運營成本,當出現(xiàn)未檢測到的漏洞時,如何將缺失的策略或檢測規(guī)則加入到產(chǎn)品中,也會產(chǎn)生比較高的后期使用成本,不能忽視。
安全牛:
火線安全選擇了開源 IAST 產(chǎn)品模式,其原因是什么?開源 IAST 產(chǎn)品的能力表現(xiàn)如何?我們未來的產(chǎn)品規(guī)劃又是怎樣的?
董志勇:
IAST 是個非常不錯的工具,可以高效地幫助企業(yè)在 DevOps 階段解決相當多的漏洞。火線安全的理念是幫助整個行業(yè)提升安全能力,我們想讓更多的企業(yè)使用 IAST 來防范安全風險。此外,IAST 本身是一個安全產(chǎn)品,其開發(fā)門檻比較高,倘若因為市場上沒有開源的 IAST 產(chǎn)品,導致很多企業(yè)重復造輪子,就會影響行業(yè)進步,因此我們選擇了開源。其實開源和非開源只是產(chǎn)品的外在形式不同,同樣的領域也都存在偉大的閉源產(chǎn)品和開源產(chǎn)品。洞態(tài) IAST 是這一領域的后起之秀,產(chǎn)品進展很快,也得到了很多用戶的支持和認可。我們也會繼續(xù)努力打磨產(chǎn)品,為用戶帶來更大的價值。
對 IAST 的未來規(guī)劃:洞態(tài) IAST 整體架構是利用 Agent 采集數(shù)據(jù),在 Server 端進行漏洞檢測。在這種架構下,在一定程度上將安全與開發(fā)進行分割,安全人員可專注于安全,開發(fā)人員可專注于開發(fā)。火線安全希望洞態(tài) IAST 真正成為一款鏈接 Dev、Ops 和 Sec 團隊的工具,讓安全賦能開發(fā)和運維,并結(jié)合場景來滿足更多 DevSecOps 流程下的安全需求。
安全牛評:
在代碼安全與敏捷交付同樣重要的時代,只有開發(fā)者主動接受安全測試,才能從“根”上解決代碼安全問題。在提高開發(fā)人員安全意識的同時,將安全測試無感知地融入開發(fā)流程等等都是在想盡辦法讓開發(fā)者愛上測試。“以 IAST 為起點構建 DevSecOps 流程”的初衷是用開發(fā)思維拉近代碼安全測試與代碼開發(fā)者的距離。
而開源的代碼安全工具,進一步推動開發(fā)者樂于進行安全測試,有利于應用開發(fā)行業(yè)代碼安全整體水平的提高,也將成為推動代碼安全市場良性循環(huán)的“加速劑”。火線安全開創(chuàng)了開源代碼安全工具的元年——代碼安全從代碼開源做起。
