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