DevSecOps — 實踐
在我們實行任何變革之前，我們需要評估我們目前所處的位置，並從現在所處的位置開始。哪我們如何開始尋找我們的流程呢?以下方法可以協助我們:
- 問卷與評估
- 指標 — 重複、具背景脈絡的資料
- 有意義且認知的對話
- 識別問題
知道我們所處的位置之後，接下來就需要知道我們要去到哪個位置。通常這需要有組織層級的願景與目標來決定。另外我們也需使用價值流圖技術使流程與流水線保持一致。
然而為了讓整個組織順利運作，我們需要整合的不只是流程還有技術，同時還要整合人員與治理。什麼符合組織的價值觀？這通常需要跨領域的感知。
以開發人員為中心的安全研究
- 認識到安全基礎很難正確
- 承認開發人員不一定是安全專家
- 幫助從早期階段激發有關網路安全的對話
- 促進網路安全專家和開發人員之間的協作
- 獎勵和激勵開發人員 — 無論是內在的還是透過工作環境
- 選擇開發人員認為可用的工具和技術
- 提倡無責備文化，鼓勵開發人員報告事件（以便團隊能夠從錯誤中學習並不斷改進）
在 DevSecOps 中，我們使用精實和價值流思維來確保安全性不會造成周期時間的浪費或延遲 — 它不是一種限制，也不會中斷流程。安全是在企業的所有作業空間流程中。每一個不同的企業領域中，可能有一個工具是對該領域很重要的。持續安全是解決持續交付流水線中的安全問題和測試。
利害關係人的心態
開發(Dev): 辨識Repo與日常流程
安全(Sec):合規、標準、治理、持續安全
維運(Ops): 尋求與SREs的相關實踐，告警與日誌
DevOps與SoD(Separation of Duties)的三個迷思
迷思一: DevOps + CI/CD = 直接把東西丟到生產環境。事實是:
- 代碼永遠都需要在CI/CD流水線中進行檢查與測試，所以不會有哪種直接把東西丟到生產環境哪種事。
- 在大多數的組織中，開發與維運仍然是兩個團隊
迷思二: SoD 可有效阻止詐欺和錯誤。事實是:
- 無論如何錯誤一定會發生，重點是我們如何快速的偵測與回復
- DevOps的三步工作法的第二步: 快速失敗，快速回復、快速學習
- DevOps意味著更多測試大於阻止詐欺和錯誤
迷思三: SoD與DevOps不兼容。事實是:
- 請(或幫忙)稽核定義"控制目標"是甚麼，而不是為控制而控制
- SoD的目標是減少詐欺和錯誤
- 不要接受“不行” / 不要簡單地說“不行”，而是需要解釋Why
把安全編排在作業流程中(如下範例)。最低的要求甚麼?
實踐與產出 — 三步工作法
流程:
- 安全驅動開發，包含正負面場景。
- 產品/功能團隊與安全團隊的協作
- 安全驗收標準
- 設定政策，如舊有的代碼使用新的方式來實作
- 強化協作
回饋:
1.將安全左移:
- 縮短反饋循環
- 縮短待命作業
- 進行資料科學活動
- 共享威脅情資
2.確定所需的安全回饋
- 目前的掃瞄狀態
- 流水線驗收
- 已修復/未修復的CVE
持續學習:
1.持續學習
- 被攻陷的指標
- SIEM
- 關注指標
2.重複實踐
3. 安全是可擴充的
4. 持續合規的驗證
安全左移的成果
測試是整合在DevSecOps的實踐中。實踐有:
實踐一: 自動化測試
- 單元測試
- 功能測試
- 回歸測試
- 整合測試
- 系統測試
- 與其他非功能性測試
實踐二: 測試、驗證、自動化
- 盡早進行內部稽核
- 訂出自動化的政策與合規
- 即時的報告
實踐三: 紀錄
- 中央式儲存庫
- 告警 — 誰通誰?
- 可能可以自動化的區域
保護我們的CI/CD流水線
原則一: 實行"剛剛好"的安全
- 真實曝險與感知(自己認為)曝險之間的平衡
- 基於風險的對策設立
- 用於持續合規的工件(Artifacts)
原則二: 分階段安全保障
- 成功的代碼掃描
- 綜合脆弱性量測
- 評估整合度
- 保護生產環境資料
聚焦產出 — 如果我們在意就追蹤它
- 對指標進編號
- 遙測(Telemetry)
-Uptime/downtime
-CVE狀態
-弱點評估
-風險標準
-帳號的存取狀態 - 債務 — 臨時方法而不是根本解決
-技術債
-流程債
-人員債 - 個人-員工需要甚麼?
-快樂度
-工作滿意度
-個人成長
基於資料的決策制定
定性(Qualitative)與定量(Quantitative)或對兩項的綜合。
資料標準:
- 設立由代碼驅動、peer-reviewed的標準，如極限開發、pair programming、Peer Review
- 代碼標準品質
- Repos
- 品質保證
資料驗證:
- Bug / 漏洞攻擊
- 流程攻擊
- War games
- Tabletop exercises
- Bug bounties
- 紅Red/藍Blue/紫Purple team
Red/Blue/Purple團隊
紅隊:
- 永遠都會贏 — 因為總是會有漏洞，所以紅隊有高度動機
- 從外部攻擊來驗證安全性
藍隊:
- 永遠都會輸 — 因為總是會有漏洞，所以藍隊有低動機
- 從內部來探索與關閉漏洞
紫隊:
- 結合紅藍隊的功能來設立合規的解決方案
- 允許“藍隊”測試直至完成而不會失敗
辨識目標狀態
我們仍然要從價值流程圖開始。能夠直觀地協作以確定當前發生安全活動的位置，並確認哪裡有限制。協作性地設計目標狀態圖以儘早滿足安全要求，另外也要辨識"溝通和自動化"改進的可能。
PS:關於價值流程圖，可以參考Karen.Martin與Mike Osterling所寫的Value Stream Mapping一書。
流程的最佳實踐
工件管理(Artifact management)
- 價值鍵(Value Key)配對與組織中的任何其他任務一樣重要 — 將正確的資源對應到正確的所有者
- 透過 CI/CD 流水線自動維護 CMDB
- 定義工件加入或退出流程
- 資料可以是最大的資產：在複製生產環境資料進行測試時，保持在生產安全的環境中
風險管理
- 理解對組織與系統、平台、服務等的威脅樣貌是甚麼
- 進行威脅建模
- 自動化TaaC(Threat Modeling as a Code)
- 紀錄威脅模型的流程
- 從相關的利害關係人中取得風險接受度
- 安全適應性(Security fitness)量測可讓我們量化風險
- 用KPI來視覺化風險
IAM(Identify and Access Management)
- 定期的稽核政策
- 辨識高風險的使用者
- 稽核特權帳號，給予所有使用者最小權限
- 啟用MFA
- 追蹤程式之間的credentials
- 在secrets managements自動化安全檢查
- 在Vault中儲存、管理 secrets/tokens/control access，而不是在檔案中
- 特權存取管理工具限制自動化、編排和配置工具的生產環境存取
Secret management
- 不會有人知道secret的內容
- 被授權的人會有key
- Secret是動態的;它們永遠都在變動
- 將Secret設定為pull式工件的變數（避免secret蔓延）
- Secret的輪替是有節奏的
- 對secret store的存取都是最小權限的
- 不要hard code
- secret的生命週期是可被稽核的
- 確保所有的secret都有加密
加密
- 目標是甚麼 — 交互點
- 確保加密標準都是最新的 — 我們的IT Infra需要支援它，所以我們需要注意技術債
- 使用資料分類來定義要加密的數位資產的知識產權或資料
- 了解風險並相應地應用
- 資料加密 in Transit / at rest還有使用數位簽章
- 用於加密的工件應被安全存儲
GRC(Governance, Risk and Compliance)
- 配置變更和政策規則的實施
- 自動執行合規性以運行 CaC(Compliance as code)
- 版控對於維護代碼很重要
- 設定流水線中Build(構建)失敗時的流程
- 建立反饋循環以理解風險
監控與紀錄
“使用率的峰值可能是攻擊的一個指標”。
- 加入關鍵日誌來源（應用程式、伺服器、網路設備等）
- 啟用所需日誌（例如應用程式日誌、平台日誌、安全性日誌等）
- 建立use case來擷取關鍵活動
- 用利用已知/未知漏洞來持續監控生產環境
- 制定處理事故的回應計劃
— 準備好尋求外部協助
— 了解我們的極限並制定應急計劃
— 利用自動化機會
— 調整我們的技能，包括雲端
— 基於日誌資料和威脅情資的觸發器
緊急應變
- 處理重大事故的書面計劃
- 正式書面的R.A.C.I(Responsible, Accountable, Consulted and Informed)矩陣
- 辨識正確的利害關係人
- 正式書面的事故升級矩陣
- 對於高嚴重性事故要使用Call tree這一類詳細資訊
- 對於DR plan有知悉
- 對於重要資產、系統或服務要建立HA
威脅情資方案
- 辨識能定義與解釋不斷進化的威脅樣貌的來源
- 正式書面＂情資來源＂如何被運用
- 對於情資的收集、評估與資訊告知要分配R&R(Role & Responibility)
學習的最佳實踐
有價值的最佳實踐
