資安混沌工程

Security Chaos Engineering

在"快速"與"大規模變動"的IT世界中，增加資安與IT系統韌性的信心。

在你的資安發生狀況之前，主動的探索問題

資安混沌工程案例

資安混沌工程的定義 :
通過主動試驗並識別我們的IT環境中各項"安全控制項"的故障(失效/不作用)，以建立對系統防禦我們IT環境中各項惡意(不利 )條件能力的信心。

資訊安全遭到破壞。給我們(資安從業人員)飯吃的內部用戶或外部客戶將越來越多的系統託付給我們，而我們卻無法保持這種信任。年復一年，相同類型的資安攻擊都是成功的，並且每一次這些攻擊的影響範圍變得越來越大。同時，資安產業一直在研發炫砲的新技術，並可能在此過程中逐步進行改進。

理論和實作都必須進行根本性的轉變。資訊安全必須包含可能發生失敗的現實納入考量。使用者可能會點擊錯誤(惡意)的內容。簡單的程式修改對安全性的影響尚不清楚。資安替代方案可能會突然被禁用。事情有天會炸鍋。

通過接受這種現實，資訊安全可以從"嘗試構建完美的安全系統(因為人是不完美的，不完美的東西不可能造出完美的事物)"轉變為不斷問題像是 "我怎麼知道這個控制方式是不是持續有效的?"，"如果資安替代方案突然不能用怎麼辦，我能先預見到嗎?"，或是"我的團隊（包括高階管理人員在內）是否已準備好應對明天發生的此類事件的重要決策？"

希望(拿乖乖放機器上)不是一種策略。同樣的，完美的系統也不該是我們的應該去做的(因為做不到)。我們負責的系統由於它運行方式的正常功能而發生故障，無論我們是否喜歡它，無論我們是否看到它。資安渾沌工程旨在增強對於我們的安全控制項(方案)在我們設計它們的條件下可以有效執行的信心。通過持續性的安全試驗，我們能為組織做好了充分的準備，並減少了因資安問題導致維運中斷而措手不及的可能性。這些做法可以更好地使我們（作為專業人員）的團隊以及我們所代表的組織在面對未知的安全性時更有效率和韌性。

我們如何構建軟體的先進做法已經達到了這樣一種狀態，即我們所構建的系統已經成為我們的大腦無法進行整體思維模型化的狀態。現在，我們的系統分佈廣泛並且在運行上是短暫的。諸如雲端計算，微服務和持續交付（CD）之類的轉型技術變革都帶來了業務價值方面的新里程，但反過來又帶來了一系列新挑戰。這些挑戰中最主要的是我們無法理解自己系統中的所有內容。

我們應該做的不是永無止盡的一直往我們的環境加資安解決方案。我們應該重新評估組織防禦的基本原則，並從其根本中剔除失敗的假設(也就是去除不合時宜的安全控制)。取而代之的是，我們應該像是種下新抗藥性的種子，這種抗藥性有利於與組織業務需求保持一致，並尋求主動的，適應性的學習，而不是反應性的資安修補。

失敗 — 最偉大的導師

Pass on what you have learned. Strength, mastery, hmm…but weakness, folly, failure also. Yes: failure, most of all. The greatest teacher, failure is.
Luke, we are what they grow beyond. That is the true burden of all masters.
— — — 尤達大師, 最後的絕地武士

傳統的防禦性安全觀念是以避免失敗為基礎-防止不可避免的資料洩露或其他資安問題。失敗被視為資安人員的恥辱。我們認為失敗是我們在防禦安全方面最出色的老師；它教會了我們寶貴的經驗教訓，這些經驗教訓告訴我們如何為資安事件做更好的準備。如果我們對系統的運作行為/原理了解不多，那麼我們如何在這些系統中提高安全性呢？答案是通過有計劃的且能得到相關資安經驗的實驗。我們將渾沌工程應用於資安領域。我們稱此為資安混沌工程security chaos engineering （SCE）。SCE是資安的前進之路，它將促進防禦性安全的適應，以滿足現代資安作戰的需求。

SCE是發展學習文化的基礎，這個文化圍繞組織如何建置，操作，檢測和保護其系統而進行的。這些實驗的目的是將實踐中的安全性從"主觀評估"轉變為"客觀評估"。混沌實驗使資安團隊可以減少“unknown unknows”，轉變為“known unknowns”來改善資安的態勢。

通過有意義的導入資安的故障模式或其他資安事件，資安團隊可以發現他們透過良好的檢測，就可以看到整個系統針對資安的可視性和可測量性。團隊可以驗證關鍵的資安假設(例如這個firewall or WAF 其中一條rule會發生甚麼事)，評估系統的能力和弱點，然後採取行動增強整體的資安並減少我們的資安弱點。

SCE建議理解資安的"不確定性"的唯一方法是通過引入可被控制的資安試驗來客觀地應對它。通過將諸如安全故障之類的受控事件注入系統，就可以衡量你的團隊對資安事件做出回應的能力。此外，我們可以主動了解技術的有效性，運行手冊或安全事件流程的協調程度等等。作為一種實踐，這可以通過追蹤和衡量不同時間段的實驗結果來幫助團隊更好地了解攻擊準備情境。

我們會在這篇文章分享SCE的指導原則，因此你可以開始利用資安實驗和失敗作為增強資安能力的工具 — 這樣你就可以將資安從"阻礙業務發展的守門員"轉變為能夠為組織的其他部門提供支持的"有價值的顧問"。

嘗試失敗

混沌工程是一種不斷實驗的實踐，目的是驗證我們的系統是否按照我們認為的方式運行。這些實驗有助於發現我們了解中的系統性的弱點或不足之處，從而改進與幫助系統的設計與流程改進，使組織對他們的運行系統的行為更有信心。故障的發生(Shit always happen)是我們系統正常運行情況的一部分。混沌工程為工程師提供了一種實用的技術，可以在系統中出現未知的故障之前主動發現系統中的未知的故障。

韌性(Resilience)的基礎

那麼，韌性是什麼意思呢？據古田和夫(韌性工程專家)說，“韌性是系統在更改或有干擾的之前，之中或之後調整其功能的固有能力，以便它可以在預期和意外情況下維持所需的操作。”

韌性不僅代表著從資安威脅和壓力中恢復過來的能力，而且還具有在各種狀況下按所需要執行並適當應對的能力。然而，我們通常會在資安的對話中看到韌性的意圖會變成是資安系統的強壯度。對資安的強狀性的關注會導致一種“防禦性”(傳統上的)姿態，而不是一種"適應性系統"，韌性應該像風中的蘆葦草那樣的彎曲那樣被設計為有著以下真實狀況：將發生會對系統產生負面影響的事件或狀況。因此，資訊安全的現狀是旨在完美預防，通過從一開始就阻止事件發生來違背現實，這是不切實際的。

強壯性還導致我們優先考慮將受威脅的系統還原到上一個運作版本，儘管它容易受到促成危害的條件的影響(可能還是有問題的，只是還沒發作)，這種妄想驅使我們拼命的想用技術控制而不是系統性的緩解方案，這會產生錯誤的安全感，從而促進資安風險積累在仍然固有且易受攻擊的系統中。例如，如果在住宅區增加了河川水堤，那麼那裡可能會出現更多的房屋開發-如果水堤失敗，將導致更大的災難性後果。在資安中，由於認為防火牆或入侵檢測系統（IDS）會阻止攻擊者訪問和利用它，因此在脆弱的內部(LAN) Application中會發現有著這種錯誤安全感例子，而該內部Application因不安全的設計而陷入了困境。

事情總是會失敗的

儘早發現安全控制中的故障可能意味著未被駭客利用的安全漏洞與必須向客戶或使用者宣告資料外洩之間的區別。韌性和混亂的工程設計包含以下事實：我們的整體的資安模型是不完整，安全控制將會失敗，緩解措施將無法使用 — 換句話說，事情將會失敗。如果我們在設計系統時預期會故障本來就會出現，通過實驗主動挑戰我們的假設，並將我們所學到的feedback納入我們的資安策略，那麼我們可以了解有關系統實際工作方式以及如何改進它們的更多資訊。

故障是指系統（包括所涉及的任何人員和業務流程）未按預期運行。例如，微服務無法與其相關的服務進行連結將被視為故障。同樣，SCE內的失敗是安全控制未達到安全目標時。安全失敗的示例包括：接受已經撤銷的API密鑰，防火牆無法強制執行拒絕規則，漏洞掃描程序缺少SQLi或入侵檢測未告警發現到的安全漏洞。

混亂工程的目標不是阻止安全事件永遠不會發生，而是設法優雅地處理資安事件，儘早發現故障可以最大程度地減少事故的影響範圍(事件在公司內部的爆炸半徑)，並降低事故發生後的清理成本。工程師們了解到，儘早發現服務故障（例如支付API上的等待時間過長）可以降低修復成本，而安全事故也不例外。

因此，我們會有SCE的兩個核心指導原則。首先，期望安全控制會失敗並進行相應的準備。其次，不要試圖完全避免資安事件發生，而應具有快速有效地回應資安事件的能力。

在第一個原則下，必須在以下假設下設計系統架構：安全控制將失敗，使用者將不會立刻知道（或在乎）其操作的安全隱患。根據生態經濟學學者彼得·蒂默曼（Peter Timmerman）描述的第二個原則，可以將韌性視為將“緩衝能力”建置到系統中，以便在將來不斷增強其回應能力。因此，必須確保系統能夠妥善處理事件。安全必須從防禦姿態轉變為具韌性的姿態，並放棄完美預防的不可能的標準。

SCE的效益

SCE的實踐和利用”實驗性的失敗”會帶來許多效益。其中包括降低救火的成本，降低終端用戶的服務中斷時間，降低事件發生時的救火的壓力，以及提高對Production系統的信心，對系統風險的理解和feedback loops。

SCE通過不斷重複的練習從資安事件中回復到正常的做法，通過更好地讓團隊為處理事件做好準備，從而降低了救火成本。資安團隊可能在其知識庫中的某個地方放著資安回應計劃，但是實踐(練習)該回應過程是使人們對從事件中有效恢復的能力有所放心的更可靠的做法。可以將團隊發展muscle memory的過程。

SCE還可以減少對終端用戶的干擾。每個測試場景都會產生feedback，這些feedback可以為系統設計改進提供資訊，包括有助於最大程度地減少對用戶影響的系統變更。例如，模擬會導致ecommerce application的DDoS攻擊可能會導致我們採用CDN，這將大大減少終端用戶對事件的破壞。

SCE的另一個好處是減輕了on call和回應事件的壓力。從故障中恢復的反複練習將事件發生時的恐懼和不確定性降到最低，將其轉變為已知的解決問題的方法。muscle memory使團隊更有信心，他們可以解決問題，並根據他們的專業知識來確保系統恢復。

很少有組織對其系統的安全性充滿信心，這在很大程度上是由於無法持續追蹤和客觀地衡量成功指標。SCE可以通過受控且可重複的實驗來提高您追蹤和評估安全性的能力。SCE的試驗/練習成果還可以讓你的公司對資安事件的準備能力提高來增強公司高層的信心。

決策樹 — 讓攻擊者的算計為你所用

在software交付生命週期的所有階段中，把自己當作攻擊者然後模擬在操作過程中如何做出選擇對於接下來的資安策略至關重要。了解攻擊者的決策過程可以讓我們免去過多的技術工程工作，以阻止基本的威脅，而將精力集中於在攻擊者將首先試圖成功的攻陷系統。

正如Phil Venables所說，“攻擊者也有他的老闆和預算。”就像任何其他項目一樣，攻擊活動預計將產生很大的ROI。通俗地說，這種攻擊者的ROI被稱為“攻擊者的算計”。了解與你的個別系統和服務有關的攻擊者算計，對於幫助你確定要實施的安全控制向的優先順序至關重要。在SCE的整體內容中，攻擊者的算計還為你應該執行的game-day(練習日)場景類型提供了一個藍圖。通過考慮攻擊者的最高ROI選項，你將發現他們最有可能採取哪些行動，從而闡明應將哪些類型的故障應該注入系統以測試其韌性。

資安威脅模型的決策樹

威脅模型列舉了可能被攻擊者濫用的系統，產品或功能的特徵，並在系統設計階段實施時建立了安全成功的系統。這個模型涵蓋了系統中所有相關的問題，甚至包括已經緩解的問題，因為整體系統會隨著時間而變化。從戰術層面上來看，威脅模型詳細描述了詳細的系統結構，用於保護該體系結構的現行的processes以及任何安全性漏洞。威脅模型應包括資產清單和敏感資料清單，以及有關與系統上游和下游要串接的服務的連接資訊。威脅模型理想上可以連結到存放code的地方/工具/執行的測試，因此任何人都可以更好地理解它並追蹤進度。

決策樹是一種包含攻擊者投資回報率(ROI)的威脅模型。決策樹是攻擊者在攻擊行動中的每個階段可以採取的不同動作的直觀呈現。當想要破壞特定IT資產時，攻擊者可以使用多種途徑和方法。建立決策樹可以幫助您確定這些攻擊者的選擇，並可視化攻擊者最可能採用的路徑或他們最可能採用的方法。記住，我們的目的是為了進行主動實驗而使用對抗性思維來模擬潛在的攻擊者的行動，並且我們的模型和攻擊者做出的現實決策中可能存在差距。

在探討建立決策樹的過程以及它們可以增加價值的其他方式之前，讓我們先看一下決策樹的具體範例，以幫助構成本篇文章的其餘部分。在此範例中，我們將深入研究如何為AWS 雲端服務 S3 bucket創建決策樹，以代表攻擊者的最終目標 — 獲得“敏感的客戶資料”。

決策樹演練: AWS S3 bucket與客戶資料

我們確定了一項業務優先事項：包含客戶交易記錄的S3 bucket，這符合攻擊者“敏感的客戶資料”的一般目標。我們的下一個任務是集思廣益(brainstorming)，攻擊者將如何最輕鬆地達到access和擷取此資料的目標。儘管我們可以天馬行空的想像攻擊者會用Mossad fluctuates你的DataCenter的電源來一點一點偷資料的場景，但確定攻擊者可以採用的最低成本路徑是進行測試的最明智之地。

如果S3 bucket是設定成public而不是private，則攻擊者可以輕易地破壞包含敏感資料的S3 bucket，從而使攻擊者無需任何授權即可直接access它。儘管它看起來像是人為的，但該案例類似於過去十年中最常見的“cloud breaches”，影響了Booz Allen Hamilton，Accenture和Twilio等組織。這個呈現了缺乏任何適當的安全控制，即一開始就沒有使用安全控制，而其中一位作者曾將其稱為“ yolosec”。從“ yolosec”的假設開始，以及攻擊者將如何利用它，是在決策樹中構建成本最低的路徑的明智方法。在我們的案例中，對於攻擊者而言，真正最簡單的路徑是訪問public bucket的cache，如下圖示。

一旦有了決策樹的第一個分支（攻擊者最容易的路徑），就添加一棵新樹，其中具有最基本的防禦性假設。在我們的情況下，確保S3 bucket使用預設的private訪問權限和訪問控制列表（ACL）似乎是最簡單的緩解措施。但是，第一個必要的緩解措施實際上是禁止在site map上進行爬蟲工程（在下圖中以深藍色顯示），以避免cache到public S3 bucket中的任何資料。

接下來，我們將開始考慮如果將S3 bucket改為private（現在AWS是預設值）並使用基本ACL的話，攻擊者將採取何種措施。網絡釣魚中最簡單的分支是偷取有權限的客戶端的用戶憑據，然後查看是否存在允許使用客戶端操作更改S3 bucket的設定。採取適當的緩解措施（下圖中的深藍色顯示），攻擊者將被發送回phishing，以尋求其他網絡釣魚方法。

資安團隊應繼續此過程，以考慮攻擊者要實現目標的最簡單策略，可以採取哪些措施緩解這種攻擊，以及攻擊者他會如何調整他的攻擊策略以繞過你的緩解措施。在練習結束時，最困難的路徑應該是利用一系列zero day的漏洞，因為這幾乎普遍反映了攻擊者面臨的最艱鉅和最昂貴的挑戰。zero day漏洞利用的防禦很少，因為大家都不知道才叫zero day。但是，對於大多數組織而言，將防禦措施提高到攻擊者被迫使用zero day的攻擊水準，這時我們就可以攻擊者的範圍限制在只有辦法動員"國家級的資源和經驗"的攻擊。我們利用攻擊者的算計手段來確保針對攻擊帶來的投資回報率很低。

在我們存儲在S3 bucket中的客戶資料範例中，下圖顯示如何通過以深藍色方塊實施緩解措施來消除攻擊者垂手可得的成果（攻擊者的便捷之路），最終迫使攻擊者走上“ zero day之路”。甚至國家級的攻擊者也會發現後門supply chain的前景令人沮喪和艱鉅-因此，除非最終成果極其巨大（這對您的組織是一個勝利！），否則他們不會這樣做。

超越攻擊者

如我們在這個例中看到的那樣，決策樹的一個重要好處是，它可以幫助你在攻擊者的決策之前進行思考。決策樹鼓勵我們執行second-order thinking，或者更有效地執行second-order thinking。 First-order thinking通常是人腦的預設的運作方式，它考慮了行動的明顯含義。相比之下，N-order thinking則考慮了cascading implications。就像下棋一樣，如果攻擊者比你多想了後面三步哪你就要比他多想十步。

n-order thinking是belief prompting的本質。belief prompting是一種策略，可以通過鼓勵人們在競爭環境中表明自己對對手可能會採取的行動的信念來培養戰略思維。實驗證據顯示，通過思考對手將如何回應你將要做出的任何行動，你將做出更明智的選擇。即使看到潛在行動順序的視覺展示（稱為“擴展形式”競爭情景中的博弈論術語中的“博弈樹”被證明可以鼓勵更多理性的選擇，即可以最大化獲勝機會的選擇。

建立決策樹的練習不僅讓我們表現出對攻擊者可能做出的回應的信念，而且結果圖還可以作為持續性的視覺化參考，以幫助制定更具戰略意義的決策。當應用於資訊安全時，belief prompting會涉及防禦者(就是你)反複的詢問自己，攻擊者將對防禦行動做出回應。例如，如果防禦者防止機密資料透過網路外流，則攻擊者可能使用SSL隱藏其內容。無論我們執行belief prompting還是建立決策樹，這些都是要問的一些關鍵問題：

• 攻擊者想要我們哪些組織的數位資產？誘使攻擊發生的資產可能包括用使用者資料，電腦的計算能力，知識產權，金錢等
• 攻擊者如何決定他們的傳送方式，以及他們如何制定他們的攻擊活動？
• 攻擊者預期在我們的環境中遇到什麼安全控制措施？
• 攻擊者如何繞過他們在我們環境路徑上遇到的每個安全控制措施？
• 攻擊者將如何回應我們的安全控制？ 他們會改變路線並採取不同的行動嗎？
• 攻擊者在攻擊活動中採取特定攻擊需要什麼樣的資源？
• 攻擊者在其攻擊活動中採取特定攻擊的可能性有多大？ 基於大家都知道資安知識與組織內部知識的關係將如何變化？

開始建立你的決策樹

要製作自己的決策樹，請從有風險的business priority開始。這種business priority（通常是資源，服務，資產等）將代表攻擊者的最終目標。當然，攻擊者可能在組織的整個technology footprint中都有各種各樣的目標，但是你應該關注組織面臨的最大實質風險 — 需要向客戶，董事會或股東披露的資訊類型要道甚麼樣的程度或細節。

下圖所示，一個簡單的優先順序矩陣圖可以通過簡化優先級別排序問題，為建立決策樹提供有價值的參考。通過考慮資產對組織和攻擊者的價值，你可以挑選出最適合決策樹的攻擊者目標。

重要的是，上圖中的矩陣表考慮了攻擊的最終目標，而不是可以用作立足點的資產。例如，員工清單與組織的收入並不直接相關。員工清單在用於顯示誰是網路釣魚活動的目標時變得很有價值，但其本身並不那麼有價值。相比之下，金錢作為資產始終對攻擊與防守的兩方都至關重要，最終，大多數組織資產受到損害的影響是由於它如何影響組織的金錢。組織的名譽受損會轉化為收入損失。用組織的電腦資源偷挖礦為組織帶來了更高的電腦計算成本。因此，考慮此矩陣的一種簡單方法是這一個資產“如何直接幫公司賺錢的？”和“對於攻擊者而言，這有多少獲利？”

在弄清楚從決策樹開始的位置時，請關注矩陣圖中的“右上角的”框框。這些資產中的每一個都代表應制定的不同決策樹。試圖一次捆綁多個最終目標的決策樹將遭受過多的複雜性和視覺干擾。瞄準一個最終結果的特定範例。例如，“敏感的客戶資料”是一個優先目標，但是列舉到組織中資料所存在的每個位置的所有攻擊路徑將遭受複雜性超過負荷的干擾。相反，請選擇類似我們之前的範例“將客戶的資料放在S3 bucket”之類的範例，該範例具有特定的位置和特徵，可以更輕鬆地對應攻擊路徑。完成特定決策樹後，你可以推斷緩解方案以應用於與該目標類型匹配的其他資源。

在使用了決策樹處裡完“priority”框的所有資產之後，可以繼續進行到“nice to have”。這些資源和資產更直接地貢獻了收入，但不容易被攻擊者利用，例如business intelligence metrics或公司業務流程的文件。在為這些制定了決策樹之後，你可以選擇移動到“Depriority”框框，其中充滿了對攻擊者有價值的項目，但僅是抽象或間接地為組織的營收做出了貢獻。這些不優先使用的資源和資產可以包括收費系統，或研發資料。

我們在每個框框中包含的範例資源和資產僅用於說明目的。雖然攻擊者的價值在各個行業中保持合理的恆定，但是由你決定哪些資源對您的組織最有價值！與業務部門或財務部門的同事合作，了解推動組織收入和運營的因素。每個矩陣對於每個公司而言都是唯一的，因此每個公司確定priority的決策樹可能會有所不同（儘管某些包含金錢或敏感客戶資料的資產可能會在許多行業中持續存在）。

事件回顧

雖然決策樹是在功能或系統的初始設計階段，讓安全改善有用的威脅建模工具，它能不斷持續完善戰略工具。尤其在考慮對系統或功能的修改時，可以查閱決策樹，以了解即將發生的修改將如何改變相關的攻擊者算計。在資安事件回顧期間，請提取相關的決策樹，看看你的假設是對還是錯。作為資安團隊，你應該問的一些以下的問題包括：

• 攻擊者是否碰到了決策樹上的任何分枝？在我們的範例中，也許來自API回溯的log data顯示了在短時間內對同一IP地址的重複訪問嘗試-攻擊者首先嘗試最簡單的路徑。
• 緩解方案是否像預期的那樣改變了攻擊者的攻擊路徑？在我們的範例中，也許使用2FA可能降將攻擊者嘗試利用2FA的漏洞。
• 你的假設缺少哪些攻擊者有的選擇？也許您的應用程序監控資料顯示，攻擊者試圖利用個別Application程序中的漏洞，試圖潛進在你的AWS infrastructure。
• 攻擊者是否遇到了你沒有認知到的其他緩解阻礙？在我們的範例中，也許你在AWS中使用了不可變動的container，這使它變得困難了。攻擊者可以通過SSH找到立足點並橫向(東西向網路)移動。

除了事件回顧之外，決策樹對於測試和實驗也很有用。在舊方式(紅藍隊的資安攻防)中，你可以為紅隊（滲透測試人員）提供決策樹，以突出顯示應針對的功能。在SCE中，你的決策樹會讓你知道要測試的故障方案。在最簡單的分支中的每個功能點上開始測試，使您能夠不斷驗證是否完全消除了攻擊者的垂手可得的成果-正確cover“基本知識(大家都知道的資安知識)”。一旦你對系統對更明顯的安全故障的恢復能力充滿信心，就可以轉到攻擊者需要花費大量精力的分支。只有在經過大量的資安混沌實驗並根據生成的feedback loops對策略進行細致化之後，你才可以繼續處理“ zero day 分支”。儘管對最難的威脅進行渾沌測試可能會令人興奮，但如果不對更容易的攻擊路徑進行測試，它對你的組織也無濟於事。所以不要做技術狂，除非你是靠技術研發混飯吃的。

SCE與資安劇本 — 讓劇本脫離資安

沒有人會爭辯說我們的資料和系統的安全性很重要。那麼為什麼安全性目標常常被置於次要目標之上呢？傳統的安全程序通常會給使用者單位造成的工作增加衝突，資安團隊要求使用者跳到與他們業務毫無相關的流程或方式來實現資安目標。因此，資安充當了門口的保全 — 是否需要使用者與資安工具進行互動以進行帳戶訪問，或者當橡皮圖章對於批准軟體版本可以上版至關重要。當然，企業需要賺錢，因此，可以理解的是，阻礙軟體小改版或無法提供服務給客戶的任何事物(包含資安)都被是視為次要的。

這個解決方案看起來很簡單-只需確保資安方案能夠推動業務發展，而不是拖慢速度！但是，就像人生和IT技術運作中的許多事情一樣，說起來容易做起來難。如果組織希望避免罰款和聲譽受損，則某些法規遵從要求（例如PCI和HIPAA規定的訪問控制）就是沒得談的。也可能存在道德上的無法調和的判斷，例如保留的用戶資料的隱私權然後出售這一類的資料。但是，傳統資安方案認為有價值的約束(資安方案或政策)通常是強制性的：這是現狀偏見的產物（“資安人員說: 這是公司一貫的做法，所以它一定是正確的”）及一種要嘛全都要有或全部都沒有的心態。

SCE的原則為security program奠定基礎，這個security program從本質上在資安的東西盡可能的容易理解與使用最重要的跟公司的業務層面保持一致性。通過擁抱資安失效，你不僅可以考慮哪種類型的失效對公司業務的影響最大，而且還可以更深入地了解導致失敗的系統性因素。因此，不要堅持“must(這個觀念)”成為你的security program中的一部分，相反的應該要專注於在實踐中可以減少安全失敗的措施。

接下來，我們將探討資安劇本和SCE方法之間的差異，包括資安批准模式，這些模式可以在確保軟體安全的同時交付軟體

資安劇本

不幸的是，作為資安守門人的無效安全現狀的一個主要信念是“資安劇本”，即所執行的工作產生了對改善組織資安的感知能力，而不是產生切實有效的資安成果。在使用劇本上演時，毫無疑問，你正在為戲劇進行優化！你將重點放在“壞蘋果”案例上，這些流程會影響到組織中的每個人，而只是為了抓住少數可能做出愚蠢或惡意行為的人。這些劇本的理論基礎是“可能有人無法信任。這種策略似乎是對每個人進行預防性的控制，而不是對那幾個人進行損害控制。但是，資安劇本變成了公司的資安團隊作為資安政策或命令的來源依據，並在資安團隊與企業的其他部門之間建立了對抗性關係。

在討論資安劇本時，我們將利用Jez Humble在“風險管理劇本”。正如Humble所指出的那樣，無論是資訊安全，風險管理還是實體的安全，這種劇本都是一種“自上而下實施的常見控制手段，這使無辜者的生活痛苦，但可以避免是有罪的。”自上而下的控制（我們可以稱為組織門口的保全）可能會產生安全感，但與使用基於實驗和feedback loops的系統性的方法相比，它的效果不佳。

這個資安劇本在practice中看起來如何，以便你可以發現自己組織中的危險信號？沒有戲劇性的方法如何形成對比？下面圖表概述了這篇文章中討論的SCE方法與傳統的資安劇本方法之間的核心區別，傳統的資安劇本方法在企業中創建了作為資安保全的安全管理員。這種比較與Jez Humble的適應性風險管理與劇本式的風險管理的比較之間存在重疊，這在對IT領域的防禦能力的Application中有望實現（尤其是在文化方面）。

如我們從上表中所見，SCE完全是關於outcomes而不是output，它更傾向於選擇心理安全性而不是是集權統治，並且針對現實世界策略性的反覆試驗來優化我們的資安而不是資安是唯一優先的理想世界。從資安團隊本身到產品和開發團隊，實現實質性結果而不是付出把所有於資安有關部門與人員全部攪和進來的巨大付出(更不用說公司領導力的改進了，這可以開始看到資安預算帶來的改善結果)。

SCE方法還與產品和開發團隊的思維方式保持一致。失敗測試與希望測試可能導致性能問題的bug的團隊進行了相當大的交叉。你的許多團隊可能已經主動發現錯誤或其他問題，並想想如果當前狀態未產生結果，則如何改善其流程或tech stack。因此，SCE方法所需的思維轉變幾乎是最小的：只是假設故障是屬於整個系統的緊急性，而不是假設資安團隊已對所有內容進行了完美檢查。看起來我們對資安策略和流程特別苛刻，而且它們本質上都是不好的。當然不是這樣！正如我們將在本篇文章稍後討論的那樣，經過精心設計的流程可以促進變更，同時又可以降低風險。問題在於，不應過分依賴政策和程序來防止發生所有可能的弊端。政策不應代表懲罰手段，而應鼓勵持續學習，試驗和適應。資安程序不應作為“陷阱”，如果不遵循這些程序，則可被用作在發生資安事件後將某人開除的佐證。具有諷刺意味的是，任何忽視人類行為或資安政策/程序所適用的員工的工作流程的東西注定都會失敗。

這正是資安劇本如何創建自我實現的預言。如果每個人都被認為是可以指責的潛在錯誤源，那麼掩蓋錯誤的可能性就更大，大家對看到的資安疑慮保持沉默，從而減少feedback loops。而且，如果沒有反饋循環，就很難持續改進您的資安策略，從而使所有人望而卻步。

向Feedback loop邁進還反映了向量測邁進，這對於許多資安團隊來說無疑是艱鉅的，他們通常根據output而不是outcomes進行評估。如果您想破壞資安廠商正在吃早餐的早上，問他們如何量化這個security program預算上對公司的金錢效益有多少。計算安全性的投資回報率是一項惡名昭彰的事情，這在很大程度上被認為是pipe dream。實際上，資安或任何特定領域的戰場的標誌是，收益不能直接與成本掛鉤，也就是說，投資回報率是模糊的。實際上，資安領域或任何特定領域的標誌是，收益不能直接與成本掛鉤，也就是說，投資回報率是不確定的。

如果你為購買的每種產品建立有效作用的標準，並隨著時間的推移在幾個不同的維度上繼續衡量其功效，那麼任何無用之舉都應該顯而易見。從一個已經花大錢後穩定的系統狀態過渡到一個你要為每個項目或戰略任務負責的狀態，這無疑是令人不安的。在一定程度上，公司的資安團隊有著確保維持一定的安全性：由於安全性的投資回報率表示幾乎無法計算，因此公司的資安團隊從不想要對其進行計算。但是，這種宿命論在資安促進組織業務發展的世界中是行不通的。資安團隊必須證明可以避免金錢損失或促進獲得更多金錢（例如，如果強大的資安成為競爭優勢並有助於銷售成功）。

Security program的投資回報不僅涉及花費的金錢與所獲得的資安益處之間的直接關聯。你的security program的負面性的對外影響（你所進行的會對你以外的其他人產生負面影響的任何活動）也都具有相關性。就像機場安全劇本式的方式造成了道路死亡人數增加的意外外部性一樣，我們必須考慮資安劇本式帶來的負面外部性。由於資安劇本造成的摩擦，損失了多少業務活動？資安團隊很少量化資安活動的不便帶來的業務成本，也不會將其用作決策的依據。與其排他性的查看安全性指標，不如同時查看其他團隊的指標以發現可能的負面外部性。例如，如果你的security review code覆蓋率在增加，請檢查工程團隊的前置時間或部署頻率指標是否受到影響。雖然參加過統計學課程的任何人都將記住“關聯不等於因果關係”，但工程方面的惡化指標與資安方面的改進指標同時是研究的起點。也許工程團隊認為玩新發行的video game比推送代碼更有趣！通過與這些團隊交談並進行調查，你可以驗證問題主要是由video game驅動的，而不是由security program驅動的。如果security program對軟體交付效率造成負面外部影響，則你的調查可以幫助您確定改進措施，以減少摩擦。

好消息是安全團隊不必僅從資安劇本實現這一過渡。不幸的是，傳統的企業資安團隊很大程度上是孤島運作。如上表(SCE與資安劇本的比較)所示，操作孤島是資安劇本的組成部分，使我們無法獲得整個企業的態勢感知，包括實際構建所交付軟體的團隊在內。減少守門的部分目的是確保專業知識不僅僅存在於一個地方。這種專業知識也不應僅限於在軟體交付流程上僅在某一點上使用（就像在發布到正式環境前一樣）。為了實現這一目標，安全性應該嵌入產品團隊中，而不是孤立無援，應成為“推動者”而不是“行動者”。為了探索這種模型如何改變安全性審核流程，請瀏覽SCE的審核模式。

資安的核准模式

我們可以清楚地看到，資安劇本實現了許多劇本場景和繁重的工作，卻沒有很多results。相比之下，SCE提出了一種更健康的操作模式，可以消除當門口警衛的工作。但是，隨著組織將門口警衛的方式作為一種安全策略而丟棄時，他們通常會陷於應該如何進行資安核准的運作方式。如果您不想成為阻礙者，是否會完全放棄核准？但這不是導致混亂的原因嗎？仔細研究這些問題，我們可以發現，傳統資安需要的穩定性與SCE所培養的快速，實驗性和協作性文化之間存在著明顯的緊張關係。

儘管一些組織認為，更嚴格的變更管理流程（包括安全核准流程）可以帶來更高的穩定性，但Forsgren博士的Accelerate調查數據表明事實恰恰相反。部署頻率最快，變更準備時間最短的組織，變更失敗率也最低，恢復服務的時間也最短。實際上，你可能認為最穩定的組織（在部署代碼或進行更改之前具有更多限制和要求的組織）遇到的更改失敗率最高。最保守的組織（理論上說是“謹慎的”組織）部署的變更中，有46％至60％會導致服務質量下降，並最終需要補救。

現在從安全性角度考慮這一個發現。假設你需要為遠程執行代碼漏洞部署補丁。繁瑣的變更管理過程將阻止補丁的部署，這將直接使安全性和穩定性受到威脅。相反，靈活的過程使你可以更快地進行必要的更改，從而更加持續地提高系統穩定性。它甚至使rollbacks更加容易，因此，如果補丁出現錯誤，則與繁瑣的變更管理範例相比，它可以更快地撤消。確保你的系統更易於更改，改進測試並建立強大的監控功能，所有這些都降低了變更管理的成本，並最終帶來了比分層的官僚機構和核准機構所創建的資訊安全更高的安全性。

進行大量安全檢查的另一個危險（等同於CAB-變更批准委員會）是，它們為問責制提供了一個很好的隱藏點。與其在設計階段就預先平穩地實施有著high impact的變更方面進行思考，不如將這些考量留給外部批准者（例如資全團隊或CAB委員會）。畢竟，如果外部核准者需要幾天到幾週的時間來批准這些修改，從而延長發佈時間，為什麼還要花時間集思廣益如何實施更改呢？

透明度是實際變更流程的另一個核心要素。明確的變更過程顯示出對軟體交付性能有正面影響，而一次性的大幅度變更過程則對軟體交付效能有負面影響。以類似方式對待資安檢查過程。你的資安審核過程是否清晰，還是繁瑣？資安團隊是否共享要通過的資安需求，還是根據主觀判斷在每個項目的基礎上決定需求？是否有關於資安審核過程中步驟的文件？在安全性如何通過審核進行考量方面是否透明，或者從產品團隊的角度來看，資安團隊似乎是在不允許組織中其他部門的同事進入的高牆堡壘中進行審核的？

最終，需要任何外部批准來更改或發布都會造成瓶頸，而瓶頸會固有的增加部門間的摩擦，降低效率並削弱責任感。瓶頸還刺激了批量性的工作。工程師們在預見到瓶頸的情況下，將工作推向將小的事情堆疊成一堆事，因為較小的批次將導致瓶頸中的排隊時間更長。不幸的是，這些大批量產品涉及更多變量，並增加了存在缺陷和其他不必要的可變性的可能性。瓶頸還加劇了人們對變更的恐懼，這阻礙了學習並阻礙了變更流程的改進。這正是SCE與外部批准流程不兼容的原因-因為建立假設，進行實驗以及從結果中學習對SCE至關重要。

相反，必須存在一種夥伴關係，其中最終目標（要解決的問題）是相關stakeholders判斷質量的基礎。在這種夥伴關係中，資安團隊應充當諮詢小組的角色，而不是決策單位。重要的是，將負責工作的團隊包括在任何變更過程中，以便他們也可以處於持續改進的循環中。這意味著資安團隊應授權其他團隊幫助建立和參與新的變更流程。現行的資安管理方式是規定條件並向進行更改的團隊指導，這不會增強責任感。通過共同努力尋找解決方案，您可以加強責任制，從而最終激勵更高質量的變更。

為確保過程透明，應記錄security review並使其可追溯。優化安全測試或評估“足夠的程度”，以確保你對正式環境的系統的安全性有足夠的信心，而“足夠”在很大程度上取決於組織的安全性和合規性要求。這也將鼓勵你建立基於指標和可識別的標準而不是你的個人意見或感覺的security review過程。例如，你的團隊使用頻繁的自動化測試來取代大幅度的變更流程。實際上，通過採用SCE，你可以認為從大幅度的變更管理流程到較小的測試和復審的這種演進是遷移到一系列實驗的過程。這有助於減少security review的排隊的大小，根據利特爾法則，這將有助於最大程度地縮短交付週期，這是衡量運營績效的關鍵指標。

資安民主化

想像一下，如果你公司中的每個軟體工程師都曾經是駭客。他們可以查看他們團隊的功能或產品，並迅速集思廣益，從公司的損害中受益的方式以及最容易做到的步驟。在想像了一下攻擊者的想法之後，他們可以回到現實並提出設計改進方案，這將使攻擊者更難以採取他們想像的步驟。儘管每個工程團隊都有這樣的feedback loop，這看起來像是自己的想像，但它比您想像的更容易實現。

分散式的，民主化的security program可以實現這些目標。使資安防禦“民主化”是什麼意思？它代表著一項security program，這個program得到廣泛的自願參與支持，每個人都能獲益。這意味著資安工作既不是孤立也不是排他的。像民主國家一樣，它必須為所有利益相關者服務，並讓這些利益相關者參與。具體來說，組織的防禦團隊不僅要由資安人員組成，還必須包括正在建構防禦者必須挑戰其安全性的系統的產品和工程團隊的成員。

接下來，我們將探討防禦者的關鍵功能-替代分析-以及民主化的security program（例如Security Champions計劃）如何適合SCE。

甚麼是替代分析(Alternative Analysis)

在我們深入探討SCE如何實現資安民主化之前，我們應該回答“什麼是替代分析？”這個問題。在現代資訊安全中，替代分析功能通常由紅隊執行，為此我們可以藉鑑軍事領域的定義：“紅隊是一項功能，可為指揮官提供獨立的能力，以全面探索計劃，行動中的替代方案，環境，operational environment以及從合作夥伴，對手和其他人的角度來看的概念，組織和能力。”

當然，企業中沒有“指揮官”（就像某些CISO，CIO和CTO所希望的那樣！），而是將其替換為“團隊領導者”跟把“operational environment”換成“ 組織環境。最終目標（民主化的security program的）包括：通過擴大對環境的了解來改善組織的決策；規劃過程中的挑戰性假設； 提供其他觀點； 識別架構，設計，工具，流程和策略中的潛在弱點； 並預期潛在的下一步可能帶來的影響，尤其是攻擊者將如何應對。

從根本上說，應該使用紅隊來挑戰組織防禦者（通常稱為“藍隊”）所持的假設，這種做法被稱為替代分析。這個想法已有一世紀的歷史，基本上圍繞著預測可能出問題的地方，從其他角度分析情況以支持我們的決策，以及從心理強化我們自己對問題可能出錯的地方。將替代分析應用於當今的數位世界，仔細考慮如何分解事物可以幫助你更安全的建構事物。具有挑戰性的假設是防禦策略的基礎，它揭示了可能導致防禦失敗的缺陷和弱點。而且，對失敗如何從當前系統狀態中體現出來進行反思，也使您在心理上也更加適應失敗。

更重要的是，替代分析不是關於防禦者採用能夠充分體現實際攻擊者角色的方法。一個紅隊與其他人分開坐在一起而專門專注於攻擊或滲透系統，這對紅隊成員發現企業security program中的故障很好玩，但這無濟於事。但是，如此狹窄的關注點會形成一個膚淺的feedback loop。如果紅隊無法幫助提升共享知識，那麼他們就不是進行真正的替代分析，其實際上就是在進行狩獵行動。

替代分析是SCE武器庫中的強大工具，但應如何實施？民主化的security program提供了務實的協作解決方案，以實現改進的組織決策的效益。

分散式的替代分析

就像你所認知的，請紅隊的費用很貴。需要具備必要的攻擊專業知識和批判性思維技能的專業人員。幸運的是，SCE可以提供一種自動化的紅隊型式，因為它不斷挑戰你對系統的假設。通過使這些系統發生故障，它可以幫助你從其他角度觀察系統。

但是，組建一支分散的團隊專門從攻擊者的角度（或更廣泛地說，從其他角度來看）來解決問題，這是對SCE附加的方法，並且可以進一步增強組織的防禦性決策。這樣的團隊可以幫助您完善SCE實驗並確定哪種自動測試是合適的。但是，如何在預算有限的情況下完成這類的任務？

紅隊輪替計劃可以教會工程師透過根據據攻擊者思維的有趣的做法來破壞真實系統，並最終在產品團隊中教會大家替代分析功能。可以將其想像為在整個工程團隊中傳播“攻擊者算計”知識的種子。你可以教導這種新穎的資安見解給工程團隊，以改善決策制定能力。通過與這些工程師的互動，資安團隊將獲得可以改善security program為組織服務的新視角。

輪替紅隊的組成是甚麼？紅隊應該由具有攻擊經驗的領導者（最好是對組織和發展優先事項也有真正的了解）來定調。至關重要的是，它們應與提供替代分析以改善組織決策的首要目標保持一致。每個領導者都應該能夠對團隊成員進行有關替代分析和攻擊方法的培訓。團隊本身應該主要由每個產品團隊的工程師組成，他們可以學習並實踐攻擊者的想法。

如果你的公司有很多不同的產品或團隊，我們建議從對參與該計劃最感興趣的一組團隊中的工程師開始。正如Forsgren博士的“ State of DevOps”研究表明，最能促進變革的兩種方法是真的動手做的一群人和組織的基層。動手做的一群人涉及團體，這些團體具有共同的利益，並在組織內部和彼此之間有著共享的知識，這與整個紅隊輪替計劃的存在理由非常一致。組織的基層做法涉及小型團隊緊密合作，以聚集資源並在整個組織中分享他們的成功，從而獲得支持。在紅隊輪替的情況下，這可以從資安團隊和一個或兩個渴望建立的產品團隊開始設計上的安全性。

教育的目的是使工程師在full time 的加入產品團隊後立即能提供使用替代分析的價值。當然，你不希望您的security program長期拖延開發速度，因此，你應該仔細考慮什麼組成了工程師時間中專門且持續學習在"攻擊者算計"思維上。進行優化以提高工程師執行替代分析的能力，同時確保只要他們必須重新學習整體系統的內容，他們就不會脫離產品的週期循環。

正如我們在決策樹章節所講的那樣，決策樹是支持民主化替代分析的有利工具。參與輪替計劃的工程師必須將攻擊算計應用於建構或運行的實際系統中，從而提高跟攻擊者一樣的算計技能。本質上，培訓涉及工程師在進行攻擊以實現特定目標時，在決策樹中創建自己的分支。理想情況下，他們將以樹狀格式記錄他們所採取的行動，以便與產品團隊在輪替後分享。其結果會是，參與者可以返回到有著新專業知識的產品團隊，了解應該在決策樹中包括哪些攻擊分支。對於現有的決策樹，參與者可以打破現有假設並提出分支修改建議。憑藉這些經驗，他們可以利用攻擊者的思維方式來考慮攻擊者將如何回應提議的安全控制或緩解措施，從而幫助二階（甚至更高）思考，以改善團隊的決策能力。

民主化資安模型最有希望的實現是通過“資安擁護”計劃。接下來，我們將對該程序在實踐中的樣貌以及它為組織帶來的益處進行High-level overview。

資安擁護計畫

資安擁護計劃是一連串的過程，涉及一個或多個工程團隊的現有成員，在資安領域承擔額外責任。資安擁護的目標是在其工程團隊和資安團隊之間建立更準確，一致的溝通管道。其結果是，組織通過新產品開發和功能設計大大提高了對他們對其風險的了解。如果正確的執行，則資安工程師的許多任務可以在產品團隊內部進行交接和處理，而資安工程團隊只需通過複雜的決策指導並領導這個計畫即可。資安擁護計劃促進有關每種產品和系統互連性的資訊的持續交換。它還將與資安實踐有關的知識傳播給產品團隊，資安擁護計畫確保可以理解和遵循這些知識。

資安擁護計劃允許以更快的速度將安全功能整合到產品或服務中。在回報和解決錯誤以及其他資安方面問題，資安擁護計畫變成是一個聯絡窗口。緩解功效以及引入緩解的速度也得到了改善。較少的bugs才會達到SLA的限制，絕大多數的問題是在規定的時間範圍內得到解決，從而可以更好地控制風險。

在SCE中建立安全性

SCE可幫助你為系統中的安全性故障做好準備，但是軟體交付的生命週期的不同階段涉及不同類型的故障。我們將在本節中討論“建構安全性”，指的是從設計階段開始的軟體交付的安全性，並包括導致在運作中系統上實際部署代碼的開發工作。我們將討論如何考慮建構階段的安全性，並探討build piple以及微服務的設計和配置中的故障示例。

當我們考慮安全性失敗時，我們傾向於考慮在程式build之後發生的情況，例如資料外洩。但是安全性故障始於軟體和服務的設計與開發階段。故障是相互關聯的components以意外的方式表現的結果，這種方式可以並且幾乎總是如此！我們要盡量回到系統在設計，開發過程和其他策略的初期階段考慮安全性問題，而在產品或服務的最前期這些資訊可以告訴我們系統的最終樣貌和操作方式。

Build階段的失敗

本著SCE的真正精神，我們必須進行實驗以發現潛在的失敗。這就引出了一個問題：你應該進行哪些實驗才能發現系統如何處理build時安全性故障？如果你的漏洞掃描程序或其他build時安全工具出現故障，會發生什麼情況？它會停止PR合併嗎？ release是否會凍結？例如，如果service使用錯誤的API token ，我們就嘗試在其中一種資安工具中強制中斷它。

安全測試工具及其操作人員將永遠無法完美執行。因此，必須在假設這種故障的情況下設計你的系統。不允許單個工具成為單個故障來源。例如，僅依靠漏洞掃描程序但沒有對可能無法檢測和修復漏洞的補償性控制是不明智的。而且，關注於檢查服務或產品的漏洞清單意味著較少的注意力集中在可以從本質上提高安全性的設計選擇上。

重要的是，對於cloud native環境，misconfigurations是導致安全失敗的巨大原因，但不是漏洞，也不會收到CVE identifier。允許匿名訪問的容器，在服務器上打開不必要的端口，公開暴露orchestration management consoles，在處理錯誤時顯示stack trace或啟用了遠程管理功能都是所有可能導致安全故障的misconfigurations範例。儘管很容易看出這些錯誤如何直接導致安全性失敗（如果被發現是造成危害的原因，將構成巨大的“麻煩”！），但其他misconfigurations可能會更加奧妙。過時的證書是很明顯的misconfigurations，但是authentication的錯誤可能更難發現，同時仍然可能導致相同的最終失敗。

擁抱故障可以幫助我們發現應用程序中潛在的故障根源，而不僅僅是對照OWASP Top 10。本節其餘部分概述的渾沌測試的類型旨在實現驗證安全控制，測試回應能力以及發現系統內部任何負面外部影響的目標。有了這些資訊，你就可以建立一個feedback loop，以通知系統設計的改良，例如，建立一個自動腳本來關閉保護在網路層不允許開啟清單中的port number。

現在，我們將探討跨不同環境類型的Application中的安全性失敗，以便你切實了解如何將SCE引入軟體交付生命週期的build階段。

容器和Image Repositories中的應用程序安全性失敗

讓我們學習下表中列舉的容器中的一些常見安全性故障，並著眼於如何將這種故障注入到你的SCE系統中。您的組織可能沒有在系統中安裝所有這些組件或配置，因此請將其視為說明性的起始點，以集思廣益進行自己的測試。

Build Pipelines的安全性失敗

Build pipelines（通常為continuous integration / continuous delivery (CI/CD) pipelines）包括幾個不同的組件：build和自動化服務器，代碼和image repositories以及第三方工具（通常是open source的）。我們已經介紹了容器和image repositories，因此現在讓我們集中討論build和自動化服務器以及支源CI / CD的工具。

微服務環境中典型的CI / CD pipelines按以下步驟操作：開發人員將代碼提交到代碼存儲庫，該代碼存儲庫通過CI integrate到image repositories中，image repositories通過CD傳遞到cluster。在某些pipeline中，開發人員將具有對image repositories和cluster的直接write access-這顯然可能導致安全性失敗。此外，由於擁有image repositories和cluster之間的read-write access權限，自動化服務器通常會呈現出多個維度的攻擊面。

實際上，可以通過多種方式專門將安全故障顯示在build pipelines中。在下表中，讓我們探討將安全性失敗注入這些pipeline的一些方法。

SCE中的Production security

如前所述，當我們說“Production security”時，我們指的是從部署階段開始的軟體交付的安全性，包括軟體和Service的持續運行。你可能還會聽到稱為“runtime security”或“operation security”的“production security”。在本節中，我們將介紹基礎架構中的一些核心特徵，這些特徵通過Design來建立安全性，Production系統中的故障範例，以及故障如何能有更好的基礎架構設計以及強大的檢測和回應應程序。

Production中軟體的部署和操作對於支持各個產業的組織營收已變得至關重要。當故障意味著直接面對客戶的Service中斷且變成為收入損失時，這種感覺尤其令人恐懼。但是，像往常一樣，故障仍然是我們武器庫中的寶貴的工具，可確保運行中的實際活生生的系統能夠優雅地處理事件並順利恢復。

主動了解production system如何對某些故障情況做出回應的唯一方法之一是在Production system中進行渾沌工程測試。你的團隊或組織很可能不願意在Production system中啟動SCE計劃，而寧願先對Development 或stageing環境進行測試。但是，這應將此視為初始過渡期，並計劃將其渾沌測試遷移到Production環境中。否則，你將永遠無法真正了解Production系統將如何應對故障，這意味著當不可避免的情況發生時，你將無法做好準備。

接下來我們將介紹Production security，即如何通過擁抱DIE鐵三角在設計上使基礎架構更安全。

DIE鐵三角

DIE鐵三角是考慮安全性未來需求的另一種方式。它倡導了三個新的典範來說明我們如何保護系統。舊的典範著重於confidentiality, integrity, and availability，或者我們稱為CIA鐵三角。新的典範著重於build要distributed, immutable, and ephemeral的系統，DIE鐵三角。

build要distributed, immutable, and ephemeral的屬性賦予安全性好處，解決了我們在安全性方面遇到的一些主要挑戰，但是更有趣的是，這些屬性實際上可以解決對CIA鐵三角的需求。如果某些東西是分散式的，那麼為什麼我需要這種資產是available的呢？如果某些東西是immutable，那為什麼還要擔心它的integrity呢？如果某些東西是高度的ephemeral，那麼為什麼我需要擔心它的confidentiality？

在cloud native世界中使用這種比喻時 — “寵物”和“牛群”時，可以更清楚地理解這種二分法。寵物是我們以愛心命名和用心對待的東西，例如我們機房內的Server或是我們養的貓或狗。另一方面，牛群被貼上模糊的概念，沒有發名字沒有我們用心的對待，當牛群中的一隻牛生病時（例如，有脆弱性並且需要修補），牛被從牛群中剔除，而我們繼續前進。牛就像容器和serverless功能以及信用卡號交易序號，每次交易都會更改。

這具有多重含義。想一下公司內資安方面的勞動力短缺：由於我們的資安專家太少或寵物太多了，這種短缺加劇了嗎？因此，從長遠來看，我們需要通過限制新寵物的產生，使其更容易飼養牛群並進行控制以防止牛群成為寵物。

生產系統故障

人們傾向於將更多的注意力放在資安光譜的預防面 — 試圖確保在將軟體部署到生產環境中之前消除漏洞。那很重要！但是，假設所有漏洞都將得到修復是不現實的，尤其是在你無法控制的軟體components中，例如container runtime, orchestrator,或kernel本身。

如前面所獎，決策樹可以幫助你確定攻擊者可能採取最可能破壞你的production infrastructure的路徑。例如，具有公開權限的aws S3 bucket將是access production infrastructure的最簡單途徑之一。利用zero day 的Linux kernel 漏洞從container 跳到host 中可能是損害production infrastructure的較困難的途徑之一。

Production security困難的部分原因是production infrastructure本身的廣度。Production infrastructure.可以放在on-premises或私有/公共雲中。公司的Application(不管是給客戶用或是內部用的)可能會放在physical servers/virtual private servers/virtual machines/containers/Serverless等等的環境中。

複雜性的另一層是，有數不清的活動類型會危害Production的安全性。攻擊者可以產生一個interactive shell， disable SELinux，並利用memory mismanagement的漏洞來獲得root用戶訪問權限，然後load kernel module以確保其訪問權限是永久的。或者，攻擊者可以使用return-oriented programming （ROP）通過漏洞利用來提升特權，從而使他們能夠container中跳到host並獲得對host的控制權。攻擊者和內部開發人員都可以將debugger附加到Production system，從而促進訊息公開或特權升級。

識別production components之間的關係有助於減少攻擊傳染的可能性。執行資安混沌實驗可以加快此過程，因為模擬一個資源的危害可以顯示與之連接的資源中哪些也受到了影響。例如，如果將一個挖礦程式注入到一個隨機選擇的server中，資源利用率的峰值是否僅限於該server？

這使我們進入了特定的資安渾沌實驗，以幫助將故障注入production system。

Production 中的系統故障

讓我們看一下故障如何在production system中展現出來，包括servers, containers, orchestrators（實際上是任何正在運行的服務）。大多數Production infrastructure都在Linux上運行，在Linux系統上，所有東西都是file。從這個角度來看，安全性失敗可以看作是因為任何file 的creation, deletion, or modification。如下表所示，大量針對production環境的實驗包括注入與file相關的行為，這些行為可能會危害安全性或性能。

進入SCE旅程

通過單純地“回應”“事件”(You are just reacting, not handling)，資安產業忽略了進一步了解和培養這些事件的寶貴機會，並將其作為主動增強系統回復力的機會。相反，如果我們明確並主動地發起資安事件以了解其影響並設計優雅的自動回應，該怎麼辦？

驗證我們已知的假設

如果大多數惡意代碼旨在入侵那些毫無戒心，準備不足或不為人知的人，又名“垂手可得的成果”，那麼提出以下問題是有道理的：如果沒有這些，那麼會有多少次攻擊仍將是成功的？這麼大的攻擊面積從一開始？難道這種“垂手可得的成果”是主動了解我們的系統運作以及建構和操作它們的這些人的主要行為嗎？

如果我們總是預期人類和系統，會以意想不到的方式運作，或許我們會採取有關於系統行為的更多有用的不同觀點：假設失敗，並設計了系統預期失敗和適當地處理它們。

我們應該專注於從系統中發生的故障中學習。通過這種思想上的轉變，我們可以開始理解並建構更具韌性的系統所需要的內容。通過實驗測試的基礎上建構韌性系統，我們可以使駭客變得不老練，攻擊者會更加努力地為自己的利益而努力。

制定資安渾沌實驗

SCE通過嚴格的實驗介紹了可視性，以說明系統的安全性。可視性對於產生feedback loop至關重要。測試是對先前已知結果進行確認。在找尋之前，我們先知道要尋找的是什麼。透過實驗試圖獲得以前未知的新見解和資訊，這些新見解完善了feedback 並持續學習。

透過向我們的系統中注入資安事件可以幫助團隊了解他們的系統如何運作與回應，並增加提高韌性的機會。維運，開發團隊和資安團隊都應實施資安措施。他們都應該定義其服務，以承受潛在的故障，並在必要時適當將服務降級而不影響公司業務。通過持續進行資安實驗，我們可以評估和增強對未知漏洞的了解，以免它們成為危機。

試驗的設計過程

文件是設計，建構和進行混沌實驗的重要組成部分。仔細記錄實驗是建立有價值的混沌實驗過程中最被忽視和低估的其中之一。

文件定義下的正常狀態

進行SCE實驗的第一步是定義目標系統及其預期結果的穩定運行特徵（也稱為正常運行狀態）模型。確保記錄描述系統正常運行的可觀察特徵。

設計我們的假說

在記錄了穩定的正常運行行為之後，我們將使用這個資訊定義一個假說，作為在測試過程中可能會發生和應該發生的事情的起點。假設通常以“如果出現以下X條件，我們相信我們的系統將以Y回應”的形式出現。重要的是要記住，我們永遠不會進行我們已經知道會失敗的渾沌實驗。如果我們知道它將會失敗，則應該修復已知問題。

定義假設的考量點如下:

• 我們期望在實驗中發生什麼？
• 支持該假設的具體標準和特徵是什麼？
• 這個假設的範圍是什麼？
• 有哪些變數？
• 我們的假設是什麼?

控制爆炸半徑

另一個至關重要的設計元素是仔細考慮實驗可能產生的潛在不利的影響，並嘗試將爆炸範圍最小化。最小化爆炸半徑的範例可能包括在對外客戶的服務上不注入故障，或在用戶數量較少的server上進行實驗。許多open source的渾沌工程工具通常都包含一個opt-in/ opt-out模型，以定出實驗的範圍。我們會在後面介紹其中一種工具:ChaoSlingr

從小地方開始，並在有一定的成熟度時驗證我們的預期。例如，如果要試驗WAF的特定類型的故障模式，則可以選擇首先在非重要的業務服務或非正式環境中上執行此操作，以確保該工具不會造成影響客戶的問題。

Plan B

在準備執行實驗的過程中，花時間檢查和記錄plan B方案和過程可能很有價值。這樣做的話，如果實驗假說不正確，相關的stakeholders將對他們的回應能力更有信心。此外，更進一步特徵實驗的預期結果可能是一項增值的練習。

通告組織

開始在你的組織中進行渾沌實驗時，一定要告知組織的其他成員你打算做什麼，為什麼這麼做以及何時計劃這樣做。

計畫你的Game days跟執行試驗

將實驗與Game days練習聯結起來。詳細的安安排Game days將會提供幫助。你應該枚舉Game days場景中可能發生的情況。這也將有助於降低令人厭惡的且對公司業務有影響的意外會發生的機會。Game days應在啟動之前將各種stakeholders包括資安，軟體工程師，使用者代表以及其他IT成員納入其中。後面，我們將更詳細地討論SCE game days。

衡量每次故障的影響

You cannot manage what you cannot measure.通過衡量，你可以放心地縮小或放大實驗，以為實驗增加範圍或寬度。

在探索定義的fault spaces（攻擊面積）時，應在資安屬性的context中構築資安假說，因為必須正確地對結果（發現）進行分類。使用結果分類法對實驗結果進行分類可能是衡量隨時間變化而進行實驗結果的好方法。

安全性實驗最常見的結果是以下幾種：

預防性的:
這個動作是可以被預防的

已修復的:
如果沒有預防，則將其修復（已分類）

偵測到的:
如果沒有進行修復，則會偵測到（logs, alerts）

驗證你的資安和具能見度工具所期望的feedback

檢查您的假設是否成立。確認系統和流程（自動或手動）是否按預期運行。假說正確嗎？ 發生了你沒有想到的任何事情嗎？

使用具持續性驗證的自動化工具

在最大程度上，讓我們的實驗自動化。自動化使我們能夠以精確，可控的方式重複進行實驗。此外，它確保考慮相同的環境變數，從而可以對其進行操作。自動化還可以使你隨著時間的推移提高實驗的嚴格性和包含的範圍。

Note : 資安混沌工程無法做到下列事項

• 驗證configuration;你需要用其他的解決方案
• 檢查authentication privileges
• trust network settings;傳送的是真實的流量
• check application policy

Game days

開始使用SCE的一種好方法是Game days。通過在實彈射擊(真的讓系統著火)練習中注入故障，Game days可立即產生有價值的結果。目的是開展跟安全性components相關的一系列假說，計劃實驗並執行實驗以驗證或駁斥這些假說。

資安混沌的Game days是引入受控的，安全的和可觀察到的實驗的一種方法，該實驗使工程師能夠觀察其安全性對現實條件的回應程度。在這些練習中，團隊經常執行recovery procedures and security control，並完善其解決方案協議，例如系統維運手冊。

Game day是一種意圖評估如何應對現實世界可能有的亂七八糟狀況的實踐。他們對系統的復原能力建立了信心。這些練習涉及在Production中強制執行某些故障狀況，以驗證我們有關容錯的假設是否與實際相符。

目標是回答以“how”開頭的問題，答案應該是緩解系統故障的策略，方法或一系列操作。正確執行Game days程序可以幫助提高韌性。

Game days的練習包括一個對話，工程師們可以在該對話中一起工作並集體討論各種失敗情況。他們會建立一個計劃文件，該文件描述了要測試的系統，建議會發的故障場景（包括將要模擬故障的步驟），圍繞系統應如何回應故障的期望反應以及對用戶的預期影響。這個團隊研究每個場景，記錄觀察結果並確定預期與現實之間的差異。利用這些結果，團隊可以獲取真實的資訊，從而可以在系統中建立越來越大的韌性。

實施資安混沌的Game days包括在Game days之前進行計劃，在Game days期間執行並在事後進行分析。Russ Miles的《Learning Chaos Engineering》中的每個步驟都有完整的描述，因此以下指南提到了專門針對資安Game days的修改。

在計劃期間

• 這個練習應具有跨功能性；謹慎的計畫誰應該參與其中。例如維運團隊, security incident responders, product owners, software engineers等等。
• 提出與系統中現實世界資安問題相關的建議假說。這些問題的主題是：“如果……會發生什麼？” 或“如果…失敗了怎麼辦？ 會發生什麼？ 我們知道嗎 如何做嗎？”

進行練習

• 通過注入預先定義好的故障條件，計劃並執行建議的假說

Game day 之後

• 完成後，參與者將進行post-mortem，以了解預期的效果或不正常的效果。
• 制定補救措施。
• 修復後，安排時間重新進行實驗，以驗證修復措施是否成功並且假說是最新的。

Use Case: 資安架構

理論上的資安架構將不再足以保護現代化的工程組織，使這個資安架構轉變成公司的業務和產品以在當今需求量很大的數位世界中競爭。從歷史上看，資安架構的任務是儘早在工程生命週期中的設計階段整合安全性。目的是避免在專案投入運作之前時解決資安問題。架構師定期參加設計討論，並協助工程師將資安要求轉換為工程可交付成果，作為專案實施的一部分。

資安架構功能的有效性是根據流程的結果衡量的，這些結果在設計階段無法被影響。無論其創新性或技術性如何，其結果都取決於工程師正確遵守其提供的策略，標準，設計和實施要求。大多數專案很少嚴格按照規範執行。不幸的是，不可預見的技術限制，有限的專案時間，功能修改和錯誤很容易破壞資安架構並難以建立的資安基準。即使團隊在專案上線時滿足了所有要求，在系統生命週期中進行的修改也會削弱安全性。

但是，如果我們能夠進入一個產品團隊和工程師進行他們自己的資安性實驗，並且受到激勵且愉悅的學習其成果並採取措施提高安全性和韌性……全憑自己主動的世界，該怎麼辦？

SCE是在設計過程中引入feedback機制的極有價值的工具，可幫助工程師和架構師了解該feedback機制是否正確實施以及在運作上是否有效。我們要解決的主要需求是建立一種方法，以在系統部署後直接向系統要求有關其運作安全性狀態的基本問題。

Use case: 資安監控

資安團隊依靠高質量的logs和準確的alerts來實現絕大多數的安全功能。為了偵測事件並防止發生負面影響，團隊需要對可疑事件發生的時間和地點有可觀察的洞察力。由logs引發的可疑事件警報是此洞察力的最重要來源。如果logs pipeline 發生問題，哪麼alert也不會有作用。

此外，要求資安團隊盡快回應並控制資安事件。 Incident response teams依靠準確，完整，高質量的logs，這不僅可以幫助他們找到任何事件的更多背景資訊，而且還可以幫助確定適當的對策，並在升級資安事件與需要上法庭時提供證據。

故障有以下兩個主要方面，它們可能對組織的資安狀況產生不利影響：

• 組織一開始就沒有準確的log data
• 組織在偵測infrastructure方面遇到小問題，而這種小問題會阻礙他們獲得對事件的洞察力。“小問題”可能出現在偵測infrastructure以下三個部分中的任何一個中：
  — logging
  — alerting
  — response

如果上面其中任何一項失敗，就可能造成攻擊是成功的並會造成重大損失。

通過SCE獲得新見解

就像其他挑戰一樣，有許多方法可以解決logging and alerting這類infrastructure中的這種潛在故障。解決該問題的基本方法之一是驗證是否集中收集了所有logs，並且對它們進行了持續的異常訪問和/或活動監控。除了log trends的monitoring and alerting外，還可以使團隊的偵測和回應基礎價構的可靠性大大提高。這樣，團隊就可以觀察到從SIEM中接收log的每條pileline上 log flow中的異常值和峰值。

為了主動檢查並確定log pipeline 和alert infrastructure中的損壞，安排定期的安全混亂實驗很重要，以檢查所有logs和alerts是否已按預期及時收集並收集到security logs和alert toolsets中(例如SIEM)。根據我們的經驗，log pipeline一開始做完後後很少進行測試。結果，資安團隊經常是在偶然狀況下或是發生了資安事件和/或資安事件發生期間發現到log是不完全的。在這種情況下，資安團隊就算要嘗試找詢特定的logs或alerts，也找不到。定期進行渾沌實驗可以幫助驗證這些關鍵功能的運行狀況。

再次回到有破損的log pipeline的範例，資安團隊在假設logging and alerting infrastructure正常運行的前提下進行維運。當這樣的假設錯誤時，它們可能導致公司每小時損失數百萬美元。2018年7月的Amazon Prime Day中斷，這讓亞馬遜每小時產生高達3300萬美元的成本，而工程師們爭先恐後的診斷和分類問題。可以使用韌性技術（例如混沌工程）來主動識別出這三個小時的停機時間。

總之，隨著對自動化的偵測和回應日益重視，自動化所涉及的infrastructure和工具正在迅速變得更加複雜。有鑑於此，我們必須尋求新的方法，例如混沌工程，以更好的理解這些複雜系統的工作原理，對其進行改良，並預測其不可預測結果的非線性結果。

Use Case: Security Incident Response

Security incident response是一種被動而混亂的災難。如果你可以將這種情況拋在腦後，該怎麼做呢？混沌工程通過逆轉資安事件後與準備階段來採取推進Security incident response框架的方法。這是通過建立可以衡量和管理的實際演習來完成的。它通過挑戰回應者(資安團隊與其相關人員)在其舒適圈外做出反應來發展整個incident response團隊。

發現安全故障的最常見方法是觸發資安事件。資安事件本身並不是有效的偵測信號，因為已經發生了且為時已晚。災難已經發生。如果我們希望主動偵測安全故障，就必須找到更好的偵測手段和可觀察性。導入SCE。如果我們可以利用從資安事件中汲取的教訓而不會造成附帶損失，該怎麼做呢？

更好的為資安失敗做好準備的無形方面是資安事件回應者的專注焦點。在錯誤的文化中（通常是經常發生資安事件的組織），資安事件回應被視為使公司不受新聞影響的最後一道防線。這是一種錯誤的方法，通常會被濫用，因為事後評估通常會產生正面的結果。那麼，我們如何資安事件無罪的環境中汲取的事故教訓並從中受益呢？導入SCE。

實際故障的現實是，即使有組織所有的人員，計劃和可用資源，你也無法為實際資安事件的不可預測性做好計劃和準備。在這種狀況下我們已經讓我們團隊甚麼都做不了，只能對資安事件做出反應。這種機器式的反應正在浪費我們的時間和人才。最重要的是，我們缺少可以學習的東西。我們唯一可以改進的方法是更好的了解我們的環境以及它們在資安威脅和攻擊下的反應。

現在，如果我們可以在安全可控的環境中利用從模擬的資安事件中學到的教訓，該怎麼做呢？SCE使我們能夠在沒有附帶影響的情況下進行實彈射擊，以提高我們有效應對的能力，並確保資安工具，技術和流程在應對現實情況的混亂之前是有效的。

資安事件渾沌工程例子

• Simulate DoS on a performance or staging environment
• Credential stuffing of a controlled login page
• Disable syslog alerting on a single firewall
• Misconfigure port 445 server message block (SMB) to be left open

SCE工具:ChaoSlingr

如下圖所示，ChaoSlingr是一個資安實驗和回報框架，最初由Aaron Rinehart領導的UnitedHealth Group團隊建立。它是第一個證明將混沌工程應用到資安中具有價值的開源軟體工具。它是作為open source來設計，引入和發布的，目的是展示用於編寫資安混段實驗的簡化框架。

一個實驗涉及錯誤配置端口。此實驗的假設是防火牆應偵測到錯誤配置的端口並block該端口，並且應將事件適當的記錄給資安團隊。一半的時間就是這樣。另一半時間，防火牆無法偵測到並block它。但是商用化configuration management工具(例如 CHEF解決方案)始終可以捕獲並修正它。不幸的是，某些工具方案沒有以資安團隊可以輕鬆識別事件發生地點的方式對其進行記錄(CHEF解決方案可以解決此類問題)。

想像一下你在那個團隊中。這一發現將動搖您對自己的安全態勢基本了解。ChaoSlingr的強大功能在於，實驗可以證明你的假設是否正確。你無需對安全性工具進行猜測或假設。

這個框架包含的四個主要功能:

Generatr
Generatr的工作是通過過濾已識別的“opt-in/opt-out” 以AWS來當範例以security group的tag來確定目標環境以執行資安混沌實驗。它選擇一個被指定opt-in tag的一個隨機security group，並選擇一個隨機端口範圍打開以通過TCP或UDP流量。

Slingr
一旦確定了目標並驗證了opt-in tag，Slingr就會通過打開或關閉尚未打開或關閉的端口在目標上執行錯誤配置的端口修改。

Trackr
執行更改後，Slingr會通過Slack將相關資訊收集到Tracker，以進行回報和告警。

Experiment description
這提供了有關實驗的文件以及AWS Lambda函數的適用輸入和輸出參數。

ChaoSlingr最初被設計在AWS中運作。它通過一系列實驗來主動介紹已知的安全失敗條件，以確定如何有效地實施安全性。這項工作背後的high-level business driver是提高公司快速提供高質量產品和服務的能力，同時保持最高水準的安全性。

ChaoSlingr的開發目的是發現，溝通並主動解決重大缺陷，以防它們影響Production中的客戶。此後，大多數使用ChaoSlingr的組織分支了這個project，並以該project提供的框架為指導，構建了自己的一系列資安混沌實驗。

SCE工具:CloudStrike

CloudStrike的開發是將安全性故障注入的演算法以量測雲端服務的安全性（confidentiality, integrity, and availability）。混沌工程的出發點是圍繞常態性異常的選擇性假說，這個假說具有可測量的屬性。因此，我們制定了預期狀態的概念：時間t 這個時間點的資源的安全狀態。本質上，cloud resource orchestration engine會知道此狀態。例如，Access control policy可以在正常時間時(例如上班時間)為使用者（例如，John）指定對特定cloud resource的access。orchestration system知道這個access policy，並定義了一個可測量的屬性。例如，如果Alice在權限被移除後針對AWS nucket發出access request，則會生成HTTP 401狀態訊息（未經授權）。此範例中，在安全故障注入操作期間Policy已經被修改了。

為了模擬現實世界的事件，實施了可能多樣態的攻擊。CloudStrike orchestrates針對目標cloud platfoerm的隨機操作（例如，使用cloud API進行刪除，建立和修改）。支持三種混沌模式：低，中和高，分別對應於30％，60％和90％的幅度。下表是使用的AttackPoints的範例：每個AttackPoint都定義了要執行的特定操作，並且有兩個或更多個攻擊點的組合構成了攻擊情景。另外下圖是說明AP1和AP4的組合以建立攻擊者在雲端帳戶中建立隨機account，建立用於訪問bucket的privileged policy並將該policy附加到惡意account的方案流程圖。

Case Studies

Case Study: Cyber Chaos Engineering — Capital One

由Capital One David Lavezzo 描述

好複雜。預測一個看似很小的修改的所有結果非常困難。結合on-premise和multicloud環境顯示出來的挑戰在進入Production運作之前可能並不明顯。怎麼知道什麼是行不通的？如何衡量進度？

量測很難。Production system需要始終是abailable的。傳統指標會尋找已經安裝好並證明它正在運行。Audit會尋找有效的證據，因此你要執行一個快照，以表明工具有偵測到某物或停止了某物。但是，這真正告訴我們什麼呢？我們知道它已經安裝，且可用，並且在特定時間點已經偵測到/提止了某些東西。我們的系統隨著不斷的發展和管理，測量其實是一個一直在移動的目標。

在大多數情況下，“系統上線”是你真正了解系統的唯一時間。你已記錄了configuration和policy，並驗證了一切是否按預期進行。很快，業務運營的現實就出現了。 Platform updates, patching, tuning, competing priorities — 這些都找到了將變數引入系統運作方式的方法。一個新的update在增加薪功能中可能會帶來 downstream影響，例如效率下降或導致大規模問題的錯誤。

導入SCE

測量和測試工具的有效性是一個相對較新的實踐。以前，外部和內部資安專家都在走自己的路。我們的挑戰不是技術而是建立共識。當時的假設是“每個人都知道我們在端點(例如PC/laptop)的可見性方面面臨挑戰”，這使我懷疑共識是否正確。輸入混亂的工程，但要保證安全。與其專注於對抗服務中斷的韌性，不如著眼於確定真實的當前狀態並確定什麼是“正常”運作。

在Capital one公司，我們首先測量了十大關鍵端點告警，以尋找我們的假設是否得到支持。我有兩個目標：告警驗證和偵測。使用真實的威脅和事件，我能夠確認我們在端點可見性方面所做的工作取得了巨大成功，這直接導致了偵測和告警能力的增強。它為我們提供了一種方法來解決我們遵循的五個階段過程的測量和開發問題：

1. 了解你的穩定狀態。 所有測量開始的baseline。 沒有好，沒有壞，只有旅程的開始。
2. 實驗，觀察和分析。 看看將新事物引入baseline時會發生什麼。
3. 找出與預期結果的gaps和deviations。 一切都按你認為的方式運作嗎？
4. 在分析的基礎上改善系統。利用現有的合作夥伴關係來幫助每個人變得更好，從而使整個計劃變得更好。
5. 在Production中不斷重複。 需要對真實的系統進行測試以獲得真實結果。 請注意。

讓老闆買單

通過為防禦環境設定baseline，我們可以顯示出可衡量的改進，證明工具能夠按預期工作，並且除衡量安全正常運行時間外還可以做更多的事情。

這是一個強大的變化，從“We don’t know…”變為“Here’s what we know and how we know it”。通過在baseline之後使用自動化，我們可以確定什麼時候偏離穩定狀態，並幫助推動改進並為正面修改的意外影響帶來可見性。我們確定哪些有效，哪些需要改進。我們可以向你展示我們團隊所做的出色工作，這是傳統上未認知到的，並且對企業產生了正面的影響。

結論

在這個不斷發展的軟體和系統的時代，每天不斷的資安事件新聞史我們感到數位世界是如此易受傷害的（甚至是脆弱的），將渾沌工程的技術應用於資安不僅感到很貼切，而且勢在必行。當在應用在資安時，渾沌工程技術有可能揭示有關系統安全性的有價值跟客觀的資訊，從而使組織能夠更可以驗與證確保其所依賴的系統的穩定性和可靠性。

SCE甚至是渾沌工程本身，仍然是一項新興且先進的實踐，技術和工具集。的確，對於少數組織而言，固有的資安思維的轉變最初將是艱難的，尤其是對於那些堅持傳統資安思想的組織。但是，如果我們開始挑戰我們的假設，培養協同作作能力而不是孤島式作業(自己做自己的)，並通過實驗學習，我們肯定會對迫切需要它的產業產生深遠的影響。