合規就代表安全了嗎？那可以不一定
前言
2018年，5G標準、中芯案件，使得技術博弈、話語權博弈持續發酵，深刻改變著數字經濟的利益格局和安全格局。GDPR落地已經半年有餘，我國《網路安全法》也正式實施一年了，全球範圍內圍繞網路安全、數據保護等重要制度立法、執法和司法活動都在積極推動。但是一部分企業在合規過程中往往被一葉障目，以為合規了數據就安全了，真的是這樣嗎？
概述
企業中的開發部門和網路安全部門的責任劃分、目標和動機有著很大的不同，不可避免地會產生諸多衝突。在新應用、新功能的開發過程中，企業一般通過引入代碼掃描工具來確保安全，以便在上線之前發現漏洞並進行修復。但是隨著企業合規需求的不斷上升，對於一些企業而言，網路安全建設的重心轉向了如何滿足法律法規的監管，這就有可能出現本末倒置引發的問題。
這裡舉一個來自於電子支付領域的典型例子。對於存儲了用戶財產信息的支付系統來說，應當以確保所在目標系統和數據的機密性、完整性和可用性為前提。但是合規性需求一來，對於質量安全評估員（QSA）而言獲得支付卡行業數據安全標準（PCI-DSS）認證就變成最高優先順序事件了。
比如2008年Heartland支付系統數據泄露的例子，雖然有點老，但是說明的問題很典型。就是到了現在，它還是有史以來最大的數據泄漏事件之一，當年超過1億人的個人信息和支付卡數據被盜，超過600家公司受到影響，損失總額達數億美元。Heartland符合PCI-DSS，在發現違規行為的兩周前剛剛通過合規審計。造成該事件的原因是攻擊者通過SQL注入漏洞成功滲透到系統內部，並非是零日攻擊或APT。漏洞所在模塊是用於處理支付卡數據，因此不在PCI QSA的審核範圍內。
合規與安全建設
合規計劃與安全建設應當作為兩條軌道同時進行，合規計劃不應管理安全計劃的運作。任何行業標準下的要求應當作為組織的安全底線，而不是終極目標。合規團隊的目標是滿足最低安全標準，這些標準由第三方定義，不會考慮每個企業的獨特業務背景，只是推進某種業務功能而不是強制保證全面安全。
那麼，企業開發流程中的安全建設該如何適應？每個開發生命周期都必須根據業務需求、開發節奏和使用的技術進行自定義設計，以下五點可以作為參考：
一、光掃描是不夠的，還需要持續跟蹤和修正
要提升開發流程安全性，光掃描和報告漏洞是不夠的，必須要有能夠在整個開發周期中進行全面安全管理的一套工具/系統，支持提供以下信息：
有關開放漏洞的最新統計數據；
統計數據的時間窗口；
漏洞的歷史趨勢；
安全缺陷密度統計和趨勢。
該工具應當支持集成基礎架構漏洞管理報告，讓高級管理人員明確了解整體風險，並了解具體針對哪些領域。
二、推進SDLC中的安全流程標準化
標準化保證每個開發階段安全性的必要條件。針對軟體開發生命周期（SDLC）而言，團隊是否遵循每年一次的大規模部署的瀑布流程，或者包含持續集成/持續部署通道，這些因素並不是最重要的。每個人都知道會進行安全測試，比如靜態分析/檢測並修復任何已識別的漏洞。
所以要注意的一點是，SDLC還必須包括安全維護這一環節。一旦推向生產環節，項目往往會凍結，有時候開發人員不會參與下一個版本的工作。在源代碼中發現新漏洞時該怎麼辦？必須有一個持續的版本維護流程來確保安全。
三、使用經過驗證的技術
基於知名和成熟的技術來構建標準化的安全流程可以讓安全團隊更加專註和專業。分析師熟悉語言語法能夠協助開發人員，針對特定語言和版本定製自動化工具。建立第三方庫和框架的索引可以更方便地進行管理，在發生問題時快速急行補救，並可降低使用流氓庫的可能性。
四、上下一心
如果高層管理人員三心二意，那麼就算是世界上最好的安全計劃也無計可施，安全團隊要向管理人員和利益相關方傳達安全開發流程的好處，能夠帶來哪些績效上的提升。
五、開發人員教育
在開發時引入漏洞是源代碼出現問題的根源，相當一部分比例的計算機科學專業畢業生從未接觸過最基本的安全實踐準則或原則。要解決這個問題需要在安全發展計劃中納入繼續教育這一塊的內容而且應當是從全面的安全基礎教育開始，而不是那種蜻蜓點水式的培訓。形式上可以是午餐會、學習小組、現場活動等，當他們深入了解代碼階段引入的各種問題讓安全團隊多麼頭大時，代碼質量就會相應提升。
*
參考來源：
darkreading，Freddy編譯整理，轉載請註明來自 FreeBuf.COM
TAG:FreeBuf |