DevOps 中的安全性 （DevSecOps）

  • 發行項

安全性是DevOps的重要部分。 但是小組如何知道系統是否安全？ 是否真的能夠提供完全安全的服務？

不幸的是，答案是 否。 DevSecOps 是持續且持續的努力，需要開發與 IT 作業中每個人的注意。 雖然作業從未真正完成，但小組用來預防和處理缺口的做法有助於產生盡可能安全且具有復原性的系統。

“從根本上說，如果有人想進去，他們就會進去...接受這一點。 我們告訴客戶的是：頭號，你正在戰鬥，無論你認為你是否在。 第二，你幾乎肯定被滲透了。“--邁克爾海登，前國家安全局和中情局局長

安全性交談

鼓勵沒有正式 DevSecOps 策略的小組儘快開始規劃。 起初可能有小組成員的抵抗，他們並不完全瞭解存在的威脅。 其他人可能覺得小組無法解決問題，而且任何特殊投資對推出功能來說都是浪費的干擾。 不過，必須開始對話，以就風險的性質、小組如何減輕風險，以及小組是否需要目前沒有的資源達成共識。

有疑慮的人預期會有一些常見的爭論，例如：

  • 威脅有多真實？ 小組通常不了解他們有責任要保護的服務與資料的潛在價值。
  • 我們的小組很棒，是吧？ 對於小組建置安全系統的能力，安全性討論可能會被視為懷疑。
  • 我不認為那有可能。 這是資歷較淺工程師的常見爭論。 有經驗的人員通常比較清楚。
  • 我們從未遭到入侵。 但您如何知道？ 您如何「預知」？
  • 關於價值無止境的爭論。 DevSecOps 是一項嚴謹的承諾，可能會被視為對核心功能工作的干擾。 雖然安全性投資應該與其他需求平衡，但不能被忽略。

思維轉變

DevSecOps 文化需要思維的重要轉變。 您不僅需要 防止 外洩，也 假設 它們。

安全性策略元件

有許多技術可以在尋求更安全的系統時套用。

防止外洩 假設發生外洩
威脅模型 戰爭遊戲練習
程式碼檢閱 中央安全性監視器
安全性測試 即時網站滲透測試
安全性開發生命週期 (SDL)

每個小組都應該至少有一些防止違規的做法。 撰寫安全程式碼不僅僅是基本要求，而且有許多免費與商業工具可協助您進行靜態分析與其他安全性測試功能。

不過，許多小組缺乏假設系統外洩是不可避免的策略。 假設您遭到入侵可能很難承認，尤其是在與管理進行困難的交談時，但該假設可協助您自行回答有關安全性的問題。 你不想在真正的安全緊急情況下弄清楚這一切。

要思考的常見問題包括：

  • 您如何偵測攻擊？
  • 如果有攻擊或滲透，您該如何回應？
  • 如何從攻擊中復原，例如數據洩漏或竄改時？

重要的DevSecOps做法

有數個適用於幾乎任何小組的常見DevSecOps做法。

首先，專注於改善 平均偵測 時間，以及 平均復原時間。 這些計量會指出偵測缺口所需的時間，以及個別復原所需的時間。 您可以透過安全性回應計畫的持續即時網站測試來追蹤它們。 評估潛在原則時，改善這些計量應該是重要的考慮。

深入練習防禦。 發生缺口時，攻擊者可以存取內部網路及其內的所有專案。 雖然在到達這一點之前停止攻擊者是理想的做法，但假設缺口的原則會驅動小組，以將已經進入的攻擊者的風險降到最低。

最後，對做法和環境執行定期缺口后評估。 解決缺口之後，您的小組應該評估原則的效能，以及自行遵守這些原則。 當小組實際遵循原則時，原則最有效。 無論是實際還是實踐，每個缺口都應該被視為改善的機會。

緩和威脅的策略

列舉威脅太多，無法全部列舉。 某些安全性漏洞是因為作業系統與程式庫等相依性發生問題，因此保持最新狀態非常重要。 其他則是因為系統程式碼中需要仔細分析才能尋找並修正的錯誤 (Bug)。 不良的祕密管理是許多外洩的原因，就像社交工程一樣。 最好考慮不同類型的安全性漏洞，以及它們對系統的意義。

攻擊向量

請考慮攻擊者取得開發人員認證存取權的案例。 他們可以做什麼？

Privilege 攻擊
他們可以傳送電子郵件嗎？ 網路釣魚同事
他們可以存取其他電腦嗎？ 登入，mimikatz，重複
他們可以修改來源嗎 插入程序代碼
他們可以修改組建/發行程式嗎？ 插入程式代碼，執行文稿
他們可以存取測試環境嗎？ 如果生產環境相依於測試環境，請利用它
他們可以存取生產環境嗎？ 這麼多選項...

您的小組如何防禦這些向量？

  • 將秘密儲存在受保護的保存庫中
  • 拿掉本機系統管理員帳戶
  • 限制 SAMR
  • Credential Guard
  • 拿掉雙主伺服器
  • 個別訂用帳戶
  • 多重要素驗證
  • 特殊權限存取工作站
  • 使用 ATP 和 適用於雲端的 Microsoft Defender 偵測

秘密管理

所有秘密都必須儲存在受保護的保存庫中。 秘密包括：

  • 密碼、金鑰和令牌
  • 儲存體帳戶金鑰
  • 憑證
  • 共用非生產環境中所使用的認證也

您應該使用保存庫階層來消除重複的秘密。 也請考慮如何及何時存取秘密。 有些是在部署時間建置環境組態時使用，而其他則是在運行時間存取。 部署時間秘密通常需要新的部署，才能取得新的設定，而運行時間秘密則視需要存取，而且可以隨時更新。

平臺具有安全儲存功能，可用來管理 CI/CD 管線和雲端環境中的秘密，例如 Azure 金鑰保存庫 和 GitHub Actions。

實用工具

  • 適用於雲端的 Microsoft Defender 非常適合一般基礎結構警示，例如惡意代碼、可疑進程等。
  • 靜態應用程式安全性測試的原始程式碼分析工具 （SAST）。
  • GitHub 進階安全性 ，用於分析和監視存放庫。
  • mimikatz 會從 Windows 上的本機安全性授權單位子系統服務記憶體 lsass.exe中擷取密碼、金鑰、釘選碼、票證等等。 它只需要計算機的系統管理存取權，或已啟用偵錯許可權的帳戶。
  • BloodHound 會建置 Active Directory 環境中關聯性的圖表。 您可以使用紅色小組輕鬆地識別難以快速識別的攻擊向量。

戰爭遊戲練習

Microsoft 的常見做法是參與 戰爭遊戲練習。 這些是安全性測試事件，其中兩個小組負責測試系統的安全性和原則。

紅色小組會扮演攻擊者的角色。 他們嘗試建立真實世界攻擊的模型，以找出安全性缺口。 如果他們可以利用任何項目，他們也會示範其缺口的潛在影響。

藍色小組會擔任DevOps小組的角色。 他們測試他們偵測和回應紅隊攻擊的能力。 這有助於增強情境意識，並測量 DevSecOps 策略的整備程度和有效性。

發展戰爭遊戲策略

戰爭遊戲在強化安全性上有效，因為它們促使紅隊尋找和利用問題。 它可能比預想的要容易得多。 尚未主動嘗試攻擊自己系統的小組通常不知道攻擊者可用的安全性漏洞大小和數量。 藍隊一開始可能會低迷，因為他們會反覆跑過來。 幸運的是，系統與做法應該隨著時間發展，讓藍隊一直獲勝。

準備戰爭遊戲

開始戰爭遊戲之前，球隊應該負責他們可以通過安全通行證找到的任何問題。 這是在嘗試攻擊之前執行的絕佳練習，因為它將為每個人提供基準體驗，以供稍後找到第一次惡意探索之後進行比較。 首先，透過手動程式代碼檢閱和靜態分析工具來識別弱點。

組織小組

紅色和藍色團隊應該由專業組織。 目標是要為每個球隊建置最有能力的團隊，以便盡可能有效地執行。

紅色小組應該包含一些安全考慮的工程師和開發人員，他們非常熟悉程序代碼。 如果可能的話，使用滲透測試專家來增強小組也很有説明。 如果沒有內部專家，許多公司會提供這項服務以及指導。

藍色團隊應該由對系統及記錄有深入瞭解的作業型工程師所組成。 他們有偵測和解決可疑行為的最佳機會。

執行早期戰爭遊戲

期待紅隊在早期戰爭比賽中有效。 他們應該能夠透過相當簡單的攻擊成功，例如尋找受到保護不佳的秘密、SQL 插入和成功的網路釣魚活動。 花很多時間在四輪之間套用修正和原則的意見反應。 這會因組織而異，但直到每個人都相信前一輪已經為它的價值進行挖掘，否則您不想在下一輪開始。

正在進行的戰爭遊戲

幾輪之後，紅隊必須依賴更複雜的技術，例如跨網站腳本（XSS）、還原串行化惡意探索，以及工程系統弱點。 在 Active Directory 這類領域引進外部安全性專家可能會很有説明，以攻擊更多模糊的惡意探索。 到這個時候，藍隊不僅應該有一個強化的平臺來辯護，而且將利用全面、集中的記錄進行入侵後鑑識。

“Defender 在列表中思考。 攻擊者會在圖表中思考。 只要這是真的，攻擊者就贏了。「約翰·蘭伯特（MSTIC）

經過一段時間，紅隊需要更長的時間才能達到目標。 當他們這樣做時，通常需要探索和鏈結多個弱點，以產生有限的影響。 透過使用即時監視工具，藍色小組應該開始實時攔截嘗試。

指導方針

戰爭遊戲不應該是一個自由自在的。 請務必認識到目標是產生更有效率的系統，由一個更有效率的團隊執行。

管理辦法

以下是 Microsoft 所使用的范例行為規範：

  1. 紅藍兩隊都不會造成任何傷害。 如果可能造成損害的可能性很大，則應記錄並加以解決。
  2. 紅色小組不應超過擷取目標資產所需的入侵。
  3. 常識規則適用於實體攻擊。 雖然紅隊受到非技術攻擊的創意，如社會工程，他們不應該列印假徽章，騷擾人等。
  4. 如果社會工程攻擊成功，請勿透露被入侵者的姓名。 課程可以分享，而不疏遠或尷尬的團隊成員每個人都需要繼續合作。

參與規則

以下是 Microsoft 使用的參與範例規則：

  1. 不會影響任何系統的可用性。
  2. 請勿存取外部客戶數據。
  3. 請勿大幅削弱任何服務的就地安全性保護。
  4. 請勿刻意針對任何資源執行破壞性動作。
  5. 保管庫 guard 認證、弱點和其他取得重要資訊。

交付項目

任何所學到的安全性風險或教訓都應該記錄在修復專案的待處理專案中。 Teams 應定義服務等級協定（SLA），以瞭解安全性風險的解決速度。 應儘快解決嚴重風險，而次要問題可能有兩個短期衝刺期限。

應該向整個組織呈現報告，其中包含所學到的經驗和弱點。 這是每個人的學習機會，所以充分利用它。

Microsoft 學到的課程

Microsoft 經常練習戰爭遊戲，並一路上學到了很多教訓。

  • 戰爭遊戲是改變 DevSecOps 文化並牢記安全性的有效方式。
  • 網路釣魚攻擊對攻擊者非常有效，不應低估。 影響可以藉由限制生產存取和要求雙因素驗證來包含。
  • 工程系統的控制會導致控制所有專案。 請務必嚴格控制組建/發行代理程式、佇列、集區和定義的存取權。
  • 深入練習防禦，讓攻擊者更加困難。 他們必須破壞的每個界限都會減緩它們的速度，並提供了另一個抓住他們的機會。
  • 不要跨越信任領域。 生產環境絕不應該信任任何測試專案。

下一步

深入瞭解 Azure 上的安全性開發生命週期和 DevSecOps。