安全性是 DevOps 的關鍵部分。 但是，團隊如何知道系統是否安全呢？ 真的有可能提供完全安全的服務嗎？
不幸的是，答案是否。 DevSecOps 是一項持續且持續的工作，需要開發和 IT 營運中每個人的關注。 雖然這項工作從未真正完成，但團隊用於預防和處理違規行為的做法可以幫助建立盡可能安全和有彈性的系統。
基本上，如果某人想進來，他就會進來……接受這一點。 我們告訴客戶的是：首先，無論你是否意識到，你都在戰鬥中。 第二，你幾乎肯定被滲透了。」-- 邁克爾·海登，美國國家安全局和中央情報局前局長
安全對話
我們鼓勵沒有正式 DevSecOps 策略的團隊盡快開始規劃。 起初，團隊成員可能會因為不完全理解存在的威脅而表現出一定的不滿。 其他人可能認為團隊沒有能力面對這個問題，任何特殊投資都會浪費對運輸功能的注意力。 然而，有必要開始對話，以就風險的性質、團隊如何減輕風險以及團隊是否需要他們目前沒有的資源達成共識。
預計懷疑論者會提出一些常見的論點，例如：
- 威脅有多真實？ 團隊通常不了解他們負責保護的服務和數據的潛在價值。
- 我們的團隊很好，對吧？ 安全討論可能被視為對團隊構建安全系統的能力的懷疑。
- 我認為這是不可能的。 這是初級工程師的常見論點。 有經驗的人通常更清楚。
- 我們從未被入侵過。 但你怎麼知道呢？ 你怎麼 知道 ？
- 關於價值的爭論無休止。 DevSecOps 是一項嚴肅的承諾，可能被視為分散對核心功能工作的注意力。 雖然安全投資應該與其他需求相平衡，但也不容忽視。
心態轉變
DevSecOps 文化需要心態的重要轉變。 您不僅需要 防止 違規行為，還需要 假設 違規行為。
安全策略元件
有許多技術可以應用於尋求更安全的系統。
| 防止違規行為 | 假設安全漏洞 |
|---|---|
| 威脅模型 | 戰爭遊戲演習 |
| 程式碼檢閱 | 中央安全監視器 |
| 安全測試 | 即時網站滲透測試 |
| 安全性開發生命週期 （SDL） |
每個團隊都應該至少有一些防止違規行為的做法。 編寫安全代碼已成為默認設置，並且有許多免費和商業工具可以幫助靜態分析和其他安全測試功能。
然而，許多團隊缺乏假設系統漏洞不可避免的策略。 假設您已被入侵可能很難承認，尤其是在與管理層進行艱難對話時，但這種假設可以幫助您在自己的時間回答有關安全的問題。 您不想在真正的安全緊急情況下弄清楚這一切。
需要思考的常見問題包括：
- 您將如何偵測攻擊？
- 如果發生攻擊或滲透，你會如何應對？
- 您將如何從攻擊中恢復，例如當數據洩露或篡改時？
關鍵的 DevSecOps 實務
有幾種常見的 DevSecOps 實踐幾乎適用於任何團隊。
首先，重點關注提高 平均檢測時間 和 平均恢復時間。 這些指標分別表示偵測違規需要多長時間，以及需要多長時間才能復原。 可以透過安全回應計劃的持續即時現場測試來追蹤它們。 在評估潛在政策時，改進這些指標應該是一個重要的考慮因素。
深入練習 防守。 當違規行為發生時，攻擊者可以存取內部網路及其內部的所有內容。 雖然理想的情況是能在攻擊者入侵之前阻止他們，但假設系統遭到入侵的策略會促使團隊最大化地減少已入侵攻擊者帶來的風險。
最後，對您的做法和環境進行定期的違規後評估。 在解決違規行為之後，您的團隊應該評估政策的績效，以及他們自己對政策的遵守情況。 當團隊實際遵循政策時，政策是最有效的。 每一次違規行為，無論是真實的還是實際的，都應被視為改進的機會。
減輕威脅的策略
威脅太多，無法一一列舉。 有些安全漏洞是由於作業系統和程式庫等相依性問題造成的，因此保持這些相依性更新至關重要。 其他則是由於系統程式碼中的錯誤，需要仔細分析才能找到並修復。 秘密管理不善是許多違規行為的原因，社會工程也是如此。 考慮不同類型的安全漏洞及其對系統的意義是一個很好的做法。
攻擊媒介
假設攻擊者已取得開發人員認證的存取權。 他們能做什麼？
| 特權 | 攻擊 |
|---|---|
| 他們可以發送電子郵件嗎？ | 網路釣魚同事 |
| 他們可以存取其他機器嗎？ | 登入，mimikatz，重複 |
| 他們可以修改來源嗎 | 插入程式碼 |
| 他們可以修改建置/發行程式嗎？ | 插入程式碼，執行腳本 |
| 他們可以存取測試環境嗎？ | 如果生產環境依賴測試環境，請利用它 |
| 他們可以存取生產環境嗎？ | 這麼多選擇...... |
您的團隊如何防禦這些攻擊向量？
- 將秘密儲存在受保護的保存庫中
- 移除本機管理員帳戶
- 限制 SAMR
- 憑證防護
- 移除雙宿主伺服器
- 個別訂閱
- 多重驗證
- 特權存取工作站
- 使用 ATP 和適用於雲端的 Microsoft Defender 進行偵測
秘密管理
所有密碼都必須儲存在受保護的保存庫中。 秘密包括：
- 密碼、金鑰和權杖
- 儲存帳戶金鑰
- 證書
- 在共用非生產環境中也使用的認證
您應該使用保管庫的階層來消除機密資訊的重複。 也請考慮存取秘密的方式和時間。 有些是在建置環境組態時在部署時使用，而其他則在執行時期存取。 部署時的秘密通常需要重新部署以載入新設定，而運行時的秘密會在需要時存取，並可隨時更新。
平臺具有安全儲存體功能，可管理 CI/CD 管線和雲端環境中的秘密，例如 Azure 金鑰保存庫 和 GitHub Actions。
有用的工具
- 適用於雲端的 Microsoft Defender 非常適合一般基礎結構警示，例如惡意代碼、可疑進程等。
- 用於靜態應用程式安全測試 （SAST） 的原始程式碼分析工具。
- GitHub 進階安全性 ，用於分析和監視存放庫。
-
mimikatz 從 Windows 的本地安全授權子系統服務記憶體中擷取
lsass.exe密碼、金鑰、PIN 碼、票證等。 它只需要對計算機的管理訪問權限，或啟用了調試權限的帳戶。 - BloodHound 會建置 Active Directory 環境中關聯性的圖表。 紅隊可以用它輕鬆識別難以快速發現的攻擊途徑。
戰爭遊戲演習
Microsoft 的常見做法是進行 戰爭演習。 這些是安全測試活動，其中兩個團隊的任務是測試系統的安全性和策略。
紅隊扮演攻擊者的角色。 他們嘗試對現實世界的攻擊進行建模，以發現安全漏洞。 如果他們可以利用任何漏洞，他們也會展示其違規行為的潛在影響。
藍隊擔任 DevOps 團隊的角色。 他們測試自己偵測和應對紅隊攻擊的能力。 這有助於增強態勢感知並衡量 DevSecOps 策略的準備情況和有效性。
發展戰爭遊戲策略
戰爭遊戲在加強安全方面是有效的，因為它們激勵紅隊發現和利用問題。 這可能會比早期預期的要容易得多。 沒有主動嘗試攻擊自己系統的團隊通常不知道攻擊者可用的安全漏洞的大小和數量。 藍隊一開始可能會士氣低落，因為他們會反覆被碾壓。 幸運的是，系統和做法應該隨著時間的推移而發展，以便藍隊始終獲勝。
為戰爭遊戲做準備
在開始戰爭遊戲之前，團隊應該處理他們可以通過安全通行證發現的任何問題。 這是在嘗試攻擊之前執行的一個很好的練習，因為它將為每個人提供基線體驗，以便在以後發現第一個漏洞後進行比較。 首先透過手動程式碼審查和靜態分析工具識別漏洞。
組織團隊
紅隊和藍隊應按專業組織。 目標是為雙方建立最有能力的團隊，以便盡可能有效地執行。
紅隊應該包括一些具有安全意識的工程師和開發人員，他們非常熟悉程式碼。 如果可能的話，用滲透測試專家來增強團隊也很有幫助。 如果內部沒有專家，許多公司會提供這項服務和指導。
藍隊應該由具有營運意識的工程師組成，他們對可用的系統和日誌記錄有深入的了解。 他們最有可能偵測和解決可疑行為。
運行早期戰爭遊戲
預計紅隊在早期的戰爭遊戲中會發揮作用。 他們應該能夠透過相當簡單的攻擊取得成功，例如透過尋找保護不善的機密、SQL 注入和成功的網路釣魚活動。 在回合之間，花足夠的時間來執行修復並採納政策反饋。 這會因組織而異，但您應該等到每個人都確信已經充分挖掘上一輪的價值後，才開始下一輪。
正在進行的戰爭遊戲
經過幾輪比賽後，紅隊將需要依賴更複雜的技術，例如跨站腳本 （XSS）、反序列化漏洞和工程系統漏洞。 在 Active Directory 等領域引入外部安全專家可能會有助於攻擊更晦澀的漏洞。 到這個時候，藍隊不僅應該有一個強化的防禦平台，而且還將利用全面、集中的日誌記錄進行違規後取證。
捍衛者用清單式思維。 攻擊者在圖表中思考。 只要這件事屬實，攻擊者就會勝利。" -- John Lambert (MSTIC)
隨著時間的推移，紅隊將需要更長的時間才能達到目標。 當他們這樣做時，通常需要發現和鏈接多個漏洞才能產生有限的影響。 透過使用即時監控工具，藍隊將能即時開始捕捉攻擊嘗試。
指導方針
戰爭遊戲不應該是自由搏鬥的。 重要的是要認識到，目標是由更有效的團隊運行的更有效的系統。
行為規範
以下是 Microsoft 使用的行為準則範例：
- 紅隊和藍隊都不會造成傷害。 如果造成損害的可能性很大，則應記錄並解決。
- 紅隊不應在捕獲目標資產時做出過度的讓步。
- 常識性規則適用於物理攻擊。 雖然鼓勵紅隊在非技術攻擊（例如社會工程）方面發揮創意，但他們不應該列印假徽章、騷擾他人等。
- 如果社交工程攻擊成功，請勿透露遭入侵者的姓名。 可以分享課程，而不會疏遠或讓每個人都需要繼續合作的團隊成員感到尷尬。
交戰規則
以下是 Microsoft 使用的參與規則範例：
- 不會影響任何系統的可用性。
- 請勿存取外部客戶資料。
- 請勿大幅削弱任何服務的就地安全性保護。
- 請勿故意對任何資源執行破壞性動作。
- 保護所取得的憑證、漏洞和其他關鍵資訊。
交付項目
任何安全風險或經驗教訓都應記錄在待辦事項的維修項目中。 團隊應定義服務等級協定 （SLA），以確定安全風險的解決速度。 嚴重風險應盡快解決，而小問題可能有兩次衝刺的最後期限。
應向整個組織提交一份報告，其中包含經驗教訓和發現的漏洞。 這對每個人來說都是一個學習機會，所以請充分利用它。
在 Microsoft 學到的經驗教訓
Microsoft 定期進行戰爭遊戲，並在此過程中學到了很多教訓。
- 戰爭遊戲是改變 DevSecOps 文化並將安全放在首位的有效方法。
- 網路釣魚攻擊對於攻擊者來說非常有效，不容小覷。 限制生產存取和要求雙因素身份驗證可以控制影響。
- 對工程系統的控制導致對一切的控制。 請務必嚴格控制建置/發行代理程式、佇列、集區和定義的存取權。
- 實施深度防禦，以提高攻擊者的難度。 他們必須突破的每一個障礙都會減緩他們的行動，並提供抓住他們的另一個機會。
- 永遠不要跨越信任領域。 生產部門永遠不應該信任測試中的任何內容。