Security Chaos Engineering
在"快速"與"大規模變動"的IT世界中，增加資安與IT系統韌性的信心。
在你的資安發生狀況之前，主動的探索問題
資安混沌工程案例
資安混沌工程的定義 :
通過主動試驗並識別我們的IT環境中各項"安全控制項"的故障(失效/不作用)，以建立對系統防禦我們IT環境中各項惡意(不利 )條件能力的信心。
資訊安全遭到破壞。給資安從業人員飯吃的內部用戶或外部客戶將越來越多的系統託付給資安從業人員，而資安從業人員卻無法保持這種信任。年復一年，相同類型的資安攻擊都是成功的，並且每一次這些攻擊的影響範圍變得越來越大。同時，資安產業一直在研發新技術，並可能在此過程中逐步進行改進。
理論和實作都必須進行根本性的轉變。資訊安全必須包含可能發生失敗的現實納入考量。使用者可能會點擊錯誤(惡意)的內容。簡單的程式修改對安全性的影響尚不清楚。資安替代方案可能會突然被禁用。事情有天會炸鍋。
通過接受這種現實，資訊安全可以從"嘗試構建完美的安全系統(因為人是不完美的，不完美的東西不可能造出完美的事物)"轉變為不間斷的問題像是 "我怎麼知道這個控制方式是不是持續有效的?"，"如果資安替代方案突然不能用怎麼辦，我能先預見到嗎?"，或是"我的團隊（包括高階管理人員在內）是否已準備好應對明天發生的此類事件的重要決策？"
希望(拿乖乖放機器上)不是一種策略。同樣的，完美的系統也不該是我們的應該去做的(因為做不到)。我們負責的系統由於它運行方式的正常功能而發生故障，無論我們是否喜歡它，無論我們是否看到它。
資安渾沌工程旨在增強對於我們的安全控制項(方案)在我們設計它們的條件下可以有效執行的信心。通過持續性的安全試驗，我們能為組織做好了充分的準備，並減少了因資安問題導致維運中斷而措手不及的可能性。這些做法可以更好地使資安團隊以及我們所代表的組織在面對未知的安全性時更有效率和韌性。
我們如何構建軟體的先進做法已經達到了這樣一種狀態，即我們所構建的系統已經成為我們的大腦無法進行整體思維模型化的狀態。現在，我們的系統分佈廣泛並且在運行上是短暫的; 諸如雲端計算，微服務和持續交付（CD）之類的轉型技術變革都帶來了業務價值方面的新里程，但反過來又帶來了一系列新挑戰。這些挑戰中最主要的是我們無法理解自己系統中的所有內容。
我們應該做的不是永無止盡的一直往我們的環境加資安解決方案。我們應該重新評估組織防禦的基本原則，並從其根本中剔除失敗的假設(也就是去除不合時宜的安全控制)。取而代之的是，我們應該像是種下新抗藥性的種子，這種抗藥性有利於與組織業務需求保持一致，並尋求主動的，適應性的學習，而不是反應性的資安修補。
失敗 — 最偉大的導師
傳遞你所學到的知識。力量、精通，嗯……但也有弱點、愚蠢、失敗。是的，最重要的是失敗。失敗是最偉大的老師。 路克，我們就是他們成長過程中超越的對象。這才是所有大師真正的負擔。
— — — 尤達大師, 最後的絕地武士
傳統的防禦性安全觀念是以避免失敗為基礎-防止不可避免的資料洩露或其他資安問題。失敗被視為資安人員的恥辱。但其實失敗是我們在防禦安全方面最出色的老師；它教會了我們寶貴的經驗教訓，這些經驗教訓告訴我們如何為資安事件做更好的準備。
如果我們對系統的運作行為/原理了解不多，那麼我們如何在這些系統中提高安全性呢？答案是通過有計劃的且能得到相關資安經驗的實驗。我們將渾沌工程應用於資安領域。我們稱此為資安混沌工程security chaos engineering （SCE）。SCE是資安的前進之路，它將促進防禦性安全的適應，以滿足現代資安作戰的需求。
SCE是發展學習文化的基礎，這個文化圍繞組織如何建置，操作，檢測和保護其系統而進行的。這些實驗的目的是將實踐中的安全性從"主觀評估"轉變為"客觀評估"。混沌實驗使資安團隊可以減少“unknown unknows”，轉變為“known unknowns”來改善資安的態勢。
通過有意義的導入資安的故障模式或其他資安事件，資安團隊可以發現他們透過良好的偵測，就可以看到整個系統針對資安的可視性和可測量性。團隊可以驗證關鍵的資安假設(例如這個firewall or WAF 其中一條rule停用的話會發生甚麼事)，評估系統的能力和弱點，然後採取行動增強整體的資安並減少我們的資安弱點。
SCE建議理解資安的"不確定性"的唯一方法是通過引入可被控制的資安試驗來客觀地應對它。通過將諸如安全故障之類的受控事件注入系統，就可以衡量團隊對資安事件做出回應的能力。此外，我們可以主動了解技術的有效性，運行手冊或安全事件流程的協調程度等等。作為一種實踐，這可以通過追蹤和衡量不同時間段的實驗結果來幫助團隊更好地了解攻擊準備情境。
我們會在這篇文章分享SCE的指導原則，因此我們可以開始利用資安實驗和失敗作為增強資安能力的工具 — 這樣就可以將資安從"阻礙業務發展的守門員"轉變為能夠為組織的其他部門提供支持的"有價值的顧問"。
嘗試失敗
混沌工程是一種不斷實驗的實踐，目的是驗證我們的系統是否按照我們認為的方式運行。這些實驗有助於發現我們了解系統性中的弱點或不足之處，從而改進與幫助系統的設計與流程改進，使組織對他們的運行系統的行為更有信心。故障的發生(Shit always happen)是我們系統正常運行情況的一部分。混沌工程為工程師提供了一種實用的技術，可以在系統中出現未知的故障之前主動發現系統中的未知的故障。
韌性(Resilience)的基礎
那麼，韌性是什麼意思呢？據古田和夫(韌性工程專家)說，“韌性是系統在更改或有干擾的之前、之中或之後調整其功能的固有能力，以便它可以在預期和意外情況下維持所需的操作。”
韌性不僅代表著從資安威脅和壓力中恢復過來的能力，而且還具有在各種狀況下按所需要執行並適當應對的能力。然而，我們通常會在資安的對話中看到韌性的意圖會變成是資安系統的強壯度。
對資安的強狀性的關注會導致一種“防禦性”(傳統上的)姿態，而不是一種"適應性系統"，韌性應該像風中的蘆葦草那樣的彎曲那樣被設計為有著以下真實狀況：將發生會對系統產生負面影響的事件或狀況。因此，資訊安全的現狀是旨在完美預防，通過從一開始就阻止事件發生來違背現實，這是不切實際的。
強壯性還導致我們優先考慮將受威脅的系統還原到上一個運作版本，儘管它容易受到促成危害的條件的影響(可能還是有問題的，只是還沒發作)，這種妄想驅使我們拼命的想用技術控制而不是系統性的緩解方案，這會產生錯誤的安全感，從而促進資安風險積累在仍然固有且易受攻擊的系統中。
例如，如果在住宅區增加了河川水堤，那麼那裡可能會出現更多的房屋開發-如果水堤失敗，將導致更大的災難性後果。在資安中，由於認為防火牆或入侵檢測系統（IDS）會阻止攻擊者存取和利用它，因此在脆弱的內部(LAN) 系統中會發現有著這種錯誤安全感例子，而該內部系統因不安全的設計而陷入了困境。
事情總是會失敗的
儘早發現安全控制中的故障可能意味著未被駭客利用的安全漏洞與必須向客戶或使用者宣告資料外洩之間的區別。韌性和混沌的工程設計包含以下事實：我們的整體的資安模型是不完整，安全控制將會失敗，緩解措施將無法使用 — 換句話說，事情將會失敗。如果我們在設計系統時預期會故障本來就會出現，通過實驗主動挑戰我們的假設，並將我們所學到的經驗納入我們的資安策略，那麼我們可以了解有關系統實際運作方式以及如何改進它們的更多資訊。
故障是指系統（包括所涉及的任何人員和業務流程）未按預期運行。例如，微服務無法與其相關的服務進行連結將被視為故障。同樣，SCE內的失敗是安全控制未達到安全目標時。安全失敗的範例包括：接受已經撤銷的API key，防火牆無法強制執行拒絕規則，漏洞掃描程序缺少SQL injection或入侵檢測未告警發現到的安全漏洞。
混沌工程的目標不是阻止安全事件永遠不會發生，而是設法優雅地處理資安事故(incident)，儘早發現故障可以最大程度地減少事故的影響範圍(事故在公司內部的爆炸半徑)，並降低事故發生後的清理成本。工程師們了解到，儘早發現服務故障（例如支付API上的等待時間過長）可以降低修復成本，而安全事故也不例外。
因此，我們會有SCE的兩個核心指導原則。
jas8411
1. 期望安全控制會失敗並進行相應的準備
2. 不要試圖完全避免資安事件發生，而應具有快速有效地回應資安事件的能力
在第一個原則下，必須在以下假設下設計系統架構：安全控制將失敗，使用者將不會立刻知道（或在乎）其操作的安全隱患。根據生態經濟學學者彼得·蒂默曼（Peter Timmerman）描述的第二個原則，可以將韌性視為將“緩衝能力”建置到系統中，以便在將來不斷增強其回應能力。因此，必須確保系統能夠妥善處理事件。安全必須從防禦姿態轉變為具韌性的姿態，並放棄完美預防的不可能的標準。
SCE的效益
SCE的實踐和利用”實驗性的失敗”會帶來許多效益。其中包括降低救火的成本，降低終端用戶的服務中斷時間，降低事件發生時的救火的壓力，以及提高對生產系統的信心，對系統風險的理解和回饋圈(feedback loops)。
SCE通過不斷重複的練習從資安事件中回復到正常的做法，通過更好地讓資安團隊為處理事故做好準備，從而降低了救火成本。資安團隊可能在其知識庫中的某個地方放著資安回應計劃，但是實踐(練習)該回應過程是使人們對從事件中有效恢復的能力有所放心的更可靠的做法。可以將團隊發展肌肉記憶的過程。
SCE還可以減少對終端用戶的干擾。每個測試場景都會產生回饋，這些回饋可以為系統設計改進提供資訊，包括有助於最大程度地減少對用戶影響的系統變更。例如，DDoS模擬攻擊會導致電子商務應用程式可能會導致我們採用CDN，這將大大減少終端用戶對事件的破壞。
SCE的另一個好處是減輕了on call和回應事件的壓力。從故障中恢復的反覆練習將事件發生時的恐懼和不確定性降到最低，將其轉變為已知的解決問題的方法。肌肉記憶使團隊更有信心，他們可以解決問題，並根據他們的專業知識來確保系統恢復。
很少有組織對其系統的安全性充滿信心，這在很大程度上是由於無法持續追蹤和客觀地衡量成功指標。SCE可以通過受控且可重複的實驗來提高組織追蹤和評估安全性的能力。SCE的試驗/練習成果還可以讓公司對資安事件的準備能力提高來增強公司高層的信心。
決策樹 — 讓攻擊者的算計為你所用
在軟體交付生命週期的所有階段中，把自己當作攻擊者然後模擬在操作過程中如何做出選擇對於接下來的資安策略至關重要。了解攻擊者的決策過程可以讓我們免去過多的技術工程工作，以阻止基本的威脅，而將精力集中於在攻擊者將首先試圖成功的攻陷系統。
正如Phil Venables所說，“攻擊者也有他的老闆和預算。”就像任何其他專案一樣，攻擊活動預計將產生很大的ROI。通俗地說，這種攻擊者的ROI被稱為“攻擊者的算計”。了解與個別系統和服務有關的攻擊者算計，對於幫助我們確定要實施的安全控制項的優先順序至關重要。
在SCE的整體內容中，攻擊者的算計還為我們應該執行的練習日(Game-Day)場景類型提供了一個藍圖。通過考量攻擊者的最高ROI選項，我們將發現他們最有可能採取哪些行動，從而闡明應將哪些類型的故障應該注入系統以測試其韌性。
資安威脅模型的決策樹
威脅模型列舉了可能被攻擊者濫用的系統，產品或功能的特徵，並在系統設計階段實施時建立了安全成功的系統。這個模型涵蓋了系統中所有相關的問題，甚至包括已經緩解的問題，因為整體系統會隨著時間而變化。
從戰術層面上來看，威脅模型詳細描述了詳細的系統結構，用於保護該系統結構的現行的流程以及任何安全性漏洞。威脅模型應包括資產清單和敏感資料清單，以及有關與系統上游和下游要串接的服務的連接資訊。威脅模型理想上可以連結到存放代碼庫的地點/工具/執行的測試，因此任何人都可以更好地理解它並追蹤進度。
決策樹是一種包含攻擊者ROI的威脅模型。決策樹是攻擊者在攻擊行動中的每個階段可以採取的不同動作的直觀呈現。當想要破壞特定IT資產時，攻擊者可以使用多種途徑和方法。建立決策樹可以幫助我們確定這些攻擊者的選擇，並可視化攻擊者最可能採用的路徑或他們最可能採用的方法。記住，我們的目的是為了進行主動實驗而使用對抗性思維來模擬潛在的攻擊者的行動，並且我們的模型和攻擊者做出的現實決策中可能存在差距。
在探討建立決策樹的過程以及它們可以增加價值的其他方式之前，讓我們先看一下決策樹的具體範例，以幫助構成本篇文章的其餘部分。在此範例中，我們將深入研究如何為AWS 雲端服務 S3 bucket創建決策樹，以代表攻擊者的最終目標 — 獲得“敏感的客戶資料”。
決策樹演練: AWS S3 bucket與客戶資料
我們確定了一項業務優先事項：包含客戶交易記錄的S3 bucket，這符合攻擊者“敏感的客戶資料”的一般目標。我們的下一個任務是集思廣益(brainstorming)，攻擊者將如何最輕鬆地達到存取此資料的目標。儘管我們可以天馬行空的想像攻擊者會用摩薩德波動(Mossad fluctuates)我們的資料中心的電源來一點一點偷資料的場景，但確定攻擊者可以採用的最低成本路徑是進行測試的最明智之地。
如果S3 bucket是設定成public而不是private，則攻擊者可以輕易地破壞包含敏感資料的S3 bucket，從而使攻擊者無需任何授權即可直接存取它。儘管它看起來像是人為的，但該案例類似於過去十年中最常見的“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)，或者更有效地執行二階思維。 一階思維(First-order thinking)通常是人腦的預設的運作方式，它考量了行動的明顯含義。相比之下，N階思維(N-order thinking)則考量了連鎖效應(cascading implications)。就像下棋一樣，如果攻擊者比你多想了後面三步哪你就要比他多想十步。
N階思維是想法提示(belief prompting)的本質。想法提示是一種策略，可以通過鼓勵人們在競爭環境中表明自己對對手可能會採取的行動的信念來培養戰略思維。實驗證據顯示，通過思考對手將如何回應你將要做出的任何行動，你將做出更明智的選擇。即使看到潛在行動順序的視覺展示（稱為“擴展形式”競爭情景中的博弈論術語中的“博弈樹”被證明可以鼓勵更多理性的選擇，即可以最大化獲勝機會的選擇。(有興趣的讀者可以找有關賽局理論的書來看)
建立決策樹的練習不僅讓我們表現出對攻擊者可能做出回應的信念，而且結果圖還可以作為持續性的視覺化參考，以幫助制定更具戰略意義的決策。當應用於資訊安全時，想法提示會涉及防禦者(就是你)反複的詢問自己，攻擊者將對防禦行動做出回應。例如，如果防禦者防止機密資料透過網路外流，則攻擊者可能使用SSL隱藏其內容。無論我們執行想法提示還是建立決策樹，這些都是要問的一些關鍵問題：
開始建立你的決策樹
要製作自己的決策樹，請從有風險的業務資產開始。這種業務資產（通常是資源，服務，資產等）將代表攻擊者的最終目標。當然，攻擊者可能在組織的整個technology footprint中都有各種各樣的目標，但是你應該關注組織面臨的最大實質風險 — 需要向客戶，董事會或股東披露的資訊類型要道甚麼樣的程度或細節。
如下圖所示，一個簡單的優先順序矩陣圖可以通過簡化優先等級排序問題，為建立決策樹提供有價值的參考。通過考量資產對組織和攻擊者的價值，我們可以挑選出最適合決策樹的攻擊者目標。
重要的是，上圖中的矩陣表考慮了攻擊的最終目標，而不是可以用作立足點的資產。例如，員工清單與組織的收入並不直接相關。員工清單在用於顯示誰是網路釣魚活動的目標時變得很有價值，但其本身並不那麼有價值。
相比之下，金錢作為資產始終對攻擊與防守的兩方都至關重要，最終，大多數組織資產受到損害的影響是由於它如何影響組織的金錢。組織的名譽受損會轉化為收入損失。用組織的電腦資源偷挖礦為組織帶來了更高的電腦計算成本。因此，考慮此矩陣的一種簡單方法是這一個資產“如何直接幫公司賺錢的？”和“對於攻擊者而言，這有多少獲利？”
在弄清楚從決策樹開始的位置時，請關注矩陣圖中的“右上角的”框框。這些資產中的每一個都代表應制定的不同決策樹。試圖一次捆綁多個最終目標的決策樹將遭受過多的複雜性和視覺干擾。瞄準一個最終結果的特定範例。
例如，“敏感的客戶資料”是一個優先目標，但是列舉到組織中資料所存在的每個位置的所有攻擊路徑將遭受複雜性超過負荷的干擾。相反，請選擇類似我們之前的範例“將客戶的資料放在S3 bucket”之類的範例，該範例具有特定的位置和特徵，可以更輕鬆地對應攻擊路徑。完成特定決策樹後，我們可以推斷緩解方案以應用於與該目標類型匹配的其他資源。
在使用了決策樹處裡完“priority”框的所有資產之後，可以繼續進行到“nice to have”。這些資源和資產更直接地貢獻了收入，但不容易被攻擊者利用，例如business intelligence metrics或公司業務流程的文件。在為這些制定了決策樹之後，你可以選擇移動到“Depriority”框框，其中充滿了對攻擊者有價值的項目，但僅是抽象或間接地為組織的營收做出了貢獻。這些不優先使用的資源和資產可以包括收費系統，或研發資料。
我們在每個框框中包含的範例資源和資產僅用於說明目的。雖然攻擊者的價值在各個行業中保持合理的恆定，但是由你決定哪些資源對您的組織最有價值！與業務部門或財務部門的同事合作，了解推動組織收入和運營的因素。每個矩陣對於每個公司而言都是唯一的，因此每個公司確定priority的決策樹可能會有所不同（儘管某些包含金錢或敏感客戶資料的資產可能會在許多行業中持續存在）。
事件回顧
雖然決策樹是在功能或系統的初始設計階段，讓安全改善有用的威脅建模工具，它能不斷持續完善戰略工具。尤其在考慮對系統或功能的修改時，可以查閱決策樹，以了解即將發生的修改將如何改變相關的攻擊者算計。在資安事件回顧期間，請提取相關的決策樹，看看我們的假設是對還是錯。作為資安專家，我們應該問的一些以下的問題包括：
除了事件回顧之外，決策樹對於測試和實驗也很有用。在舊方式(紅藍隊的資安攻防)中，我們可以為紅隊（滲透測試人員）提供決策樹，以突出顯示應針對的功能。在SCE中，決策樹會讓我們知道要測試的故障方案。在最簡單的分支中的每個功能點上開始測試，使我們能夠不斷驗證是否完全消除了攻擊者的垂手可得的成果-正確cover“基本知識(大家都知道的資安知識)”。
一旦我們對系統對更明顯的安全故障的恢復能力充滿信心，就可以轉到攻擊者需要花費大量精力的決策樹分支。只有在經過大量的資安混沌實驗並根據生成的回饋圈對策略進行細致化之後，我們才可以繼續處理“ zero day 分支”。儘管對最難的威脅進行渾沌測試可能會令人興奮，但如果不對更容易的攻擊路徑進行測試，它對組織也無濟於事。所以不要做技術狂，除非你是靠技術研發混飯吃的。
SCE與資安劇本 — 讓劇本脫離資安
沒有人會爭辯說我們的資料和系統的安全性很重要。那麼為什麼安全性目標常常被置於次要目標之上呢？傳統的安全程序通常會給使用者單位造成的工作量進而增加衝突，資安團隊要求使用者跳進到與他們業務毫無相關的流程或方式來實現資安目標。
因此，資安充當了門口的保全 — 是否需要使用者與資安工具進行互動以進行資料存取，或者當橡皮圖章對於批准軟體版本可以上版至關重要。當然，企業需要賺錢，因此，可以理解的是，阻礙軟體小改版或無法提供服務給客戶的任何事物(包含資安)都被是視為次要的。
這個解決方案看起來很簡單-只需確保資安方案能夠推動業務發展，而不是拖慢速度！但是，就像人生和IT技術運作中的許多事情一樣，說起來容易做起來難。如果組織希望避免罰款和聲譽受損，則某些法規遵從要求（例如PCI DSS和HIPAA規定的存取控制）就是沒得談的。
也可能存在道德上的無法調和的判斷，例如歸檔的使用者資料的隱私權然後出售這一類的資料。但是，傳統資安方案認為有價值的約束(資安方案或政策)通常是強制性的：這是現狀偏見的產物（“資安人員說: 這是公司一貫的做法，所以它一定是正確的”）及一種要嘛全都要有或全部都沒有的心態。
SCE的原則為安全方案奠定基礎，這個安全方案從本質上在資安事物盡可能的容易理解與使用最重要事物與公司的業務層面保持一致性。通過擁抱資安失效，我們不僅可以考量哪種類型的資安失效對公司業務的影響最大，而且還可以更深入地了解導致失效的系統性因素。因此，不要堅持“must(這個觀念)”成為我們的安全方案中的一部分，相反的應該要專注於在實踐中可以減少安全失效的措施。
接下來，我們將探討資安劇本和SCE方法之間的差異，包括資安批准模式，這些模式可以在確保軟體安全的同時交付軟體
資安劇本
不幸的是，作為資安守門人的無效安全現狀的一個主要信念是“資安劇本”，即所執行的工作產生了對改善組織資安的感知能力，而不是產生切實有效的資安成果。在使用劇本上演時，毫無疑問，我們正在為戲劇進行優化！我們將重點放在“壞蘋果”案例上，這些流程會影響到組織中的每個人，而只是為了抓住少數可能做出愚蠢或惡意行為的人。
這些劇本的理論基礎是“可能有人無法信任。這種策略似乎是對每個人進行預防性的控制，而不是對那幾個人進行損害控制。但是，資安劇本變成了公司的資安團隊作為資安政策或命令的來源依據，並在資安團隊與企業的其他部門之間建立了對抗性關係。
在討論資安劇本時，我們將利用Jez Humble在“風險管理劇本”。正如Humble所指出的那樣，無論是資訊安全，風險管理還是實體的安全，這種劇本都是一種“自上而下實施的常見控制手段，這使無辜者的生活痛苦，但可以避免是有罪的。”自上而下的控制（我們可以稱為組織門口的保全）可能會產生安全感，但與使用基於實驗和回饋圈的系統性的方法相比，它的效果不佳。
這個資安劇本在實踐中怎麼運作的，以便我們可以發現自己組織中的危險信號？沒有戲劇性的方法如何形成對比？下面圖表概述了這篇文章中討論的SCE方法與傳統的資安劇本方法之間的核心區別，傳統的資安劇本方法在企業中創建了作為資安保全的安全管理員。
這種比較與Jez Humble的適應性風險管理與劇本式的風險管理的比較之間存在重疊，這在對IT領域中有防禦能力的應用程式中有望實現（尤其是在文化方面）。
如我們從上表中所見，SCE完全是關於成果(outcomes)而不是輸出(output)，SCE更傾向於選擇心理安全性而不是是集權統治，並且針對現實世界策略性的反覆試驗來優化我們的資安而不是資安是唯一優先的理想世界。從資安團隊本身到產品和開發團隊，實現實質性結果而不是付出把所有關於資安的有關部門與人員全部攪和進來的巨大付出(更不用說公司領導力的改進了，這可以開始看到資安預算帶來的改善結果)。
SCE方法還與產品和開發團隊的思維方式保持一致。失敗測試與希望測試可能導致效能問題的bug的團隊進行了相當大的交叉。我們的許多團隊可能已經主動發現錯誤或其他問題，並想如果當前狀態未產生結果，則如何改善其流程或技術堆棧。因此，SCE方法所需的思維轉變幾乎是最小的：只是假設故障是屬於整個系統的緊急性，而不是假設資安團隊已對所有內容進行了完美檢查。
看起來我們對資安策略和流程特別苛刻，而且它們本質上都是不好的。當然不是這樣！正如我們將在本篇文章稍後討論的那樣，經過精心設計的流程可以促進變更，同時又可以降低風險。問題在於，不應過分依賴政策和程序來防止發生所有可能的弊端。政策不應代表懲罰手段，而應鼓勵持續學習，試驗和適應。資安程序不應作為“陷阱”，如果不遵循這些程序，則可被用作在發生資安事件後將某人開除的佐證。具有諷刺意味的是，任何忽視人類行為或資安政策/程序所適用的員工的工作流程的東西注定都會失敗。
這正是資安劇本如何創建自我實現的預言。如果每個人都被認為是可以指責的潛在錯誤源，那麼掩蓋錯誤的可能性就更大，大家對看到的資安疑慮保持沉默，從而減少回饋。而且，如果沒有回饋圈，就很難持續改進資安策略，從而使所有人望而卻步。
向回饋圈邁進還反映了向量測邁進，這對於許多資安團隊來說無疑是艱鉅的，他們通常根據輸出而不是成果進行評估。如果我們想破壞資安廠商正在吃早餐的早上，問他們如何量化這個資安方案預算對公司的金錢效益有多少。
計算安全性的投資回報率是一項惡名昭彰的事情，這在很大程度上被認為是白日夢(pipe dream)。實際上，資安或任何特定領域的戰場標誌是，收益不能直接與成本掛鉤，也就是說，投資回報率是模糊的。實際上，資安領域或任何特定領域的標誌是，收益不能直接與成本掛鉤，也就是說，投資回報率是不確定的。
如果我們為購買的每種產品建立有效作用的標準，並隨著時間的推移在幾個不同的維度上繼續衡量其功效，那麼任何無用之舉都應該顯而易見。從一個已經花大錢後穩定的系統狀態過渡到一個我們要為每個專案或戰略任務負責的狀態，這無疑是令人不安的。
在一定程度上，公司的資安團隊有著確保維持一定的安全性：由於安全性的投資回報率表示幾乎無法計算，因此公司的資安團隊從不想要對其進行計算。但是，這種宿命論在資安促進組織業務發展的世界中是行不通的。資安團隊必須證明可以避免金錢損失或促進獲得更多金錢（例如，如果強大的資安成為競爭優勢並有助於銷售成功）。
資安方案的投資回報不僅涉及花費的金錢與所獲得的資安效益之間的直接關聯。資安方案的負面性的對外影響（我們所進行的會對我們以外的其他人產生負面影響的任何活動）也都具有相關性。就像機場安全劇本式的方式造成了道路死亡人數增加的意外外部性一樣，我們必須考量資安劇本式帶來的負面外部性。
由於資安劇本造成的摩擦，損失了多少業務活動？資安團隊很少量化資安活動的不便帶來的業務成本，也不會將其用作決策的依據。與其排他性的查看安全性指標，不如同時查看其他團隊的指標以發現可能的負面外部性。例如，如果security review code覆蓋率在增加，請檢查工程團隊的前置時間或部署頻率指標是否受到影響。
雖然參加過統計學課程的任何人都將記住“關聯不等於因果關係”，但工程方面的惡化指標與資安方面的改進指標同時是研究的起點。也許工程團隊認為玩新發行的video game比推送代碼更有趣。通過與這些團隊交談並進行調查，我們可以驗證問題主要是由video game驅動的，而不是由資安方案驅動的。如果資安方案對軟體交付效率造成負面外部影響，則調查可以幫助我們確定改進措施，以減少摩擦。
好消息是資安團隊不必僅從資安劇本實現這一過渡。不幸的是，傳統的企業資安團隊很大程度上是穀倉式運作。如上表(SCE與資安劇本的比較)所示，穀倉式運作是資安劇本的組成部分，使我們無法獲得整個企業的態勢感知，包括實際構建所交付軟體的團隊在內。減少守門的部分目的是確保專業知識不僅僅存在於一個地方。這種專業知識也不應僅限於在軟體交付流程上僅在某一點上使用（就像在發布到正式環境前一樣）。為了實現這一目標，安全性應該嵌入產品團隊中，而不是孤立無援，應成為“推動者”而不是“反應者”。為了探索這種模型如何改變安全性審核流程，請瀏覽SCE的審核模式。
資安的核准模式
我們可以清楚地看到，資安劇本實現了許多劇本場景和繁重的工作，卻沒有很多結果。相比之下，SCE提出了一種更健康的運作模式，可以消除當門口警衛的工作。但是，隨著組織將門口警衛的方式作為一種安全策略而丟棄時，他們通常會陷於應該如何進行資安核准的運作方式。如果我們不想成為阻礙者，是否會完全放棄核准？但這不是導致混亂的原因嗎？仔細研究這些問題，我們可以發現，傳統資安需要的穩定性與SCE所培養的快速，實驗性和協作性文化之間存在著明顯的緊張關係。
儘管一些組織認為，更嚴格的變更管理流程（包括安全核准流程）可以帶來更高的穩定性，但Forsgren博士的Accelerate調查數據表明事實恰恰相反。部署頻率最快，變更準備時間最短的組織，變更失敗率也最低，恢復服務的時間也最短。實際上，我們可能認為最穩定的組織（在部署代碼或進行更改之前具有更多限制和要求的組織）遇到的更改失敗率最高。最保守的組織（理論上說是“謹慎的”組織）部署的變更中，有46％至60％會導致服務質量下降，並最終需要補救。
現在從安全性角度考慮這一個發現。假設你需要為遠程執行代碼漏洞部署補丁。繁瑣的變更管理過程將阻止補丁的部署，這將直接使安全性和穩定性受到威脅。相反，靈活的過程使我們可以更快地進行必要的更改，從而更加持續地提高系統穩定性。它甚至使rollbacks更加容易，因此，如果補丁出現錯誤，則與繁瑣的變更管理範例相比，它可以更快地撤銷。確保系統更易於更改，改進測試並建立強大的監控功能，所有這些都降低了變更管理的成本，並最終帶來了比分層的官僚機構和核准機構所創建的資訊安全更高的安全性。
進行大量安全檢查的另一個危險（等同於CAB-變更批准委員會）是它們為問責制提供了一個很好的隱藏點。與其在設計階段就預先平穩地實施有著高度影響的變更方面進行思考，不如將這些考量留給外部批准者（例如資全團隊或CAB委員會）。畢竟，如果外部核准者需要幾天到幾週的時間來批准這些修改，從而延長發佈時間，為什麼還要花時間集思廣益如何實施更改呢？
透明度是實際變更流程的另一個核心要素。明確的變更過程顯示出對軟體交付性能有正面影響，而一次性的大幅度變更過程則對軟體交付效能有負面影響。以類似方式對待資安檢查過程。你的資安審核過程是否清晰，還是繁瑣？資安團隊是否共享要通過的資安需求，還是根據主觀判斷在每個項目的基礎上決定需求？是否有關於資安審核過程中步驟的文件？在安全性如何通過審核進行考量方面是否透明，或者從產品團隊的角度來看，資安團隊似乎是在不允許組織中其他部門的同事進入的高牆堡壘中進行審核的？
最終，需要任何外部批准來更改或發布都會造成瓶頸，而瓶頸會固有的增加部門間的摩擦，降低效率並削弱責任感。瓶頸還刺激了批量性作業。工程師們在預見到瓶頸的情況下，將工作推向將小事堆疊成一堆事，因為較小的批次將導致瓶頸中的排隊時間更長。不幸的是，這些大批量產品涉及更多變量，並增加了存在缺陷和其他不必要的可變性的可能性。瓶頸還加劇了人們對變更的恐懼，這阻礙了學習並阻礙了變更流程的改進。這正是SCE與外部批准流程不兼容的原因-因為建立假設，進行實驗以及從結果中學習對SCE至關重要。
相反，必須存在一種夥伴關係，其中最終目標（要解決的問題）是相關利害關係人判斷品質的基礎。在這種夥伴關係中，資安團隊應充當諮詢小組的角色，而不是決策單位。重要的是，將負責工作的團隊也包含在任何變更過程中，以便他們也可以處於持續改進的循環中。這意味著資安團隊應授權其他團隊幫助建立和參與新的變更流程。現行的資安管理方式是規定條件並向進行變更的團隊進行指導，這不會增強責任感。通過共同努力尋找解決方案，我們可以加強責任制，從而最終激勵更高品質的變更。
為確保過程透明，應記錄security review並使其可追溯。優化安全測試或評估“足夠的程度”，以確保對正式環境的系統的安全性有足夠的信心，而“足夠”在很大程度上取決於組織的安全性和合規性要求。這也將鼓勵我們建立基於指標和可識別的標準而不是個人意見或感覺的security review過程。
例如，團隊使用頻繁的自動化測試來取代大幅度的變更流程。實際上，通過採用SCE，我們可以認為從大幅度的變更管理流程到較小的測試和復審的這種演進是遷移到一系列實驗的過程。這有助於減少security review的排隊的大小，根據利特爾法則，這將有助於最大程度地縮短交付週期，這是衡量運營績效的關鍵指標。
資安民主化
想像一下，如果公司中的每個軟體工程師都曾經是駭客。他們可以檢視他們團隊的功能或產品，並迅速集思廣益，從公司的損害中受益的方式以及最容易做到的步驟。在想像了一下攻擊者的想法之後，他們可以回到現實並提出設計改進方案，這將使攻擊者更難以採取他們想像的步驟。儘管每個工程團隊都有這樣的回饋圈，這看起來像是自己的想像，但它比我們想像的更容易實現。
分散式的，民主化的資安方案可以實現這些目標。使資安防禦“民主化”是什麼意思？它代表著一項資安方案，這個方案得到廣泛的自願參與支持，每個人都能獲益。這意味著資安工作既不是孤立也不是排他的。像民主國家一樣，它必須為所有利害關係人服務，並讓這些利害關係人參與。具體來說，組織的防禦團隊不僅要由資安人員組成，還必須包括正在建構防禦者必須挑戰其安全性的系統的產品和工程團隊的成員。
接下來，我們將探討防禦者的關鍵功能-替代分析-以及民主化的利害關係人（例如Security Champions計劃）如何適合SCE。
甚麼是替代分析(Alternative Analysis)
在我們深入探討SCE如何實現資安民主化之前，我們應該回答“什麼是替代分析？”這個問題。在現代資訊安全中，替代分析功能通常由紅隊執行，為此我們可以藉鑑軍事領域的定義：“紅隊是一項功能，可為指揮官提供獨立的能力，以全面探索計劃，行動中的替代方案，環境，運作環境以及從合作夥伴，對手和其他人的角度來看的概念，組織和能力。”
當然，企業中沒有“指揮官”（就像某些CISO，CIO和CTO所希望的那樣！），而是將其替換為“團隊領導者”跟把“運作環境”換成“ 組織環境。最終目標（民主化的資安方案的）包括：通過擴大對環境的了解來改善組織的決策；規劃過程中的挑戰性假設； 提供其他觀點； 識別架構，設計，工具，流程和策略中的潛在弱點； 並預期潛在的下一步可能帶來的影響，尤其是攻擊者將如何應對。
從根本上說，應該使用紅隊來挑戰組織防禦者（通常稱為“藍隊”）所持的假設，這種做法被稱為替代分析。這個想法已有一世紀的歷史，基本上圍繞著預測可能出問題的地方，從其他角度分析情況以支持我們的決策，以及從心理強化我們自己對問題可能出錯的地方。將替代分析應用於當今的數位世界，仔細考慮如何分解事物可以幫助我們更安全的建構事物。具有挑戰性的假設是防禦策略的基礎，它揭示了可能導致防禦失敗的缺陷和弱點。而且，對失敗如何從當前系統狀態中體現出來進行反思，也使我們在心理上也更加適應失敗。
更重要的是，替代分析不是關於防禦者採用能夠充分體現實際攻擊者角色的方法。一個紅隊與其他人分開坐在一起而專門專注於攻擊或滲透系統，這對紅隊成員發現企業資安方案中的故障很好玩，但這無濟於事。但是，如此狹窄的關注點會形成一個膚淺的回饋圈。如果紅隊無法幫助提升共享知識，那麼他們就不是進行真正的替代分析，其實際上就是在進行狩獵行動。
替代分析是SCE武器庫中的強大工具，但應如何實施？民主化的資安方案提供了務實的協作解決方案，以實現改進的組織決策的效益。
分散式的替代分析
就像我們所認知的，請紅隊的費用很貴。需要具備必要的攻擊專業知識和批判性思維技能的專業人員。幸運的是，SCE可以提供一種自動化的紅隊型式，因為它不斷挑戰我們對系統的假設。通過使這些系統發生故障，它可以幫助我們從其他角度觀察系統。
但是，組建一支分散的團隊專門從攻擊者的角度（或更廣泛地說，從其他角度來看）來解決問題，這是對SCE附加的方法，並且可以進一步增強組織的防禦性決策。這樣的團隊可以幫助我們完善SCE實驗並確定哪種自動測試是合適的。但是，如何在預算有限的情況下完成這類的任務？
紅隊輪替計劃可以教會工程師透過根據據攻擊者思維的有趣的做法來破壞真實系統，並最終在產品團隊中教會大家替代分析功能。可以將其想像為在整個工程團隊中傳播“攻擊者算計”知識的種子。我們可以教導這種新穎的資安見解給工程團隊，以改善決策制定能力。通過與這些工程師的互動，資安團隊將獲得可以改善資安方案為組織服務的新視角。
輪替紅隊的組成是甚麼？紅隊應該由具有攻擊經驗的領導者（最好是對組織和發展優先事項也有真正的了解）來定調。至關重要的是，他們應與提供替代分析以改善組織決策的首要目標保持一致。每個領導者都應該能夠對團隊成員進行有關替代分析和攻擊方法的培訓。團隊本身應該主要由每個產品團隊的工程師組成，他們可以學習並實踐攻擊者的想法。
如果公司有很多不同的產品或團隊，我們建議從對參與該計劃最感興趣的一組團隊中的工程師開始。正如Forsgren博士的“ State of DevOps”研究表明，最能促進變革的兩種方法是真的動手做的一群人和組織的基層。動手做的一群人涉及團體，這些團體具有共同的利益，並在組織內部和彼此之間有著共享的知識，這與整個紅隊輪替計劃的存在理由非常一致。組織的基層做法涉及小型團隊緊密合作，以聚集資源並在整個組織中分享他們的成功，從而獲得支持。在紅隊輪替的情況下，這可以從資安團隊和一個或兩個渴望建立的產品團隊開始設計上的安全性。
教育的目的是使工程師在全職地加入產品團隊後立即能提供使用替代分析的價值。當然，我們不希望資安方案長期拖延開發速度，因此，我們應該仔細考量什麼組成了工程師時間中專門且持續學習在"攻擊者算計"思維上。進行優化以提高工程師執行替代分析的能力，同時確保只要他們必須重新學習整體系統的內容，他們就不會脫離產品的週期循環。
正如我們在決策樹章節所講的那樣，決策樹是支持民主化替代分析的有利工具。參與輪替計劃的工程師必須將攻擊算計應用於建構或運行的實際系統中，從而提高跟攻擊者一樣的算計技能。本質上，培訓涉及工程師在進行攻擊以實現特定目標時，在決策樹中創建自己的分支。理想情況下，他們將以樹狀格式記錄他們所採取的行動，以便與產品團隊在輪替後分享。其結果會是，參與者可以返回到有著新專業知識的產品團隊，了解應該在決策樹中包括哪些攻擊分支。對於現有的決策樹，參與者可以打破現有假設並提出分支修改建議。憑藉這些經驗，他們可以利用攻擊者的思維方式來考慮攻擊者將如何回應提議的安全控制或緩解措施，從而幫助二階（甚至更高）思考，以改善團隊的決策能力。
民主化資安模型最有希望的實現是通過“資安擁護”計劃。接下來，我們將對該程序在實踐中的樣貌以及它為組織帶來的益處進行高階概述。
資安擁護計畫
資安擁護計劃是一連串的過程，涉及一個或多個工程團隊的現有成員，在資安領域承擔額外責任。資安擁護的目標是在其工程團隊和資安團隊之間建立更準確，一致的溝通管道。其結果是，組織通過新產品開發和功能設計大大提高了對他們對其風險的了解。
如果正確的執行，則資安工程師的許多任務可以在產品團隊內部進行交接和處理，而資安工程團隊只需通過複雜的決策指導並領導這個計畫即可。資安擁護計劃促進有關每種產品和系統互連性的資訊的持續交換。它還將與資安實踐有關的知識傳播給產品團隊，資安擁護計畫確保可以理解和遵循這些知識。
資安擁護計劃允許以更快的速度將安全功能整合到產品或服務中。在回報和解決錯誤以及其他資安方面問題，資安擁護計畫變成是一個聯絡窗口。緩解功效以及引入緩解的速度也得到了改善。較少的bugs才會達到SLA的限制，絕大多數的問題是在規定的時間範圍內得到解決，從而可以更好地控制風險。
在SCE中建立安全性
SCE可幫助我們為系統中的安全性故障做好準備，但是軟體交付的生命週期的不同階段涉及不同類型的故障。我們將在本節中討論“建構安全性”，指的是從設計階段開始的軟體交付的安全性，並包括導致在運作中系統上實際部署代碼的開發工作。我們將討論如何考慮建構階段的安全性，並探討建置流水線以及微服務的設計和配置中的故障示例。
當我們考慮安全性失敗時，我們傾向於考慮在代碼build之後發生的情況，例如資料外洩。但是安全性故障始於軟體和服務的設計與開發階段。故障是相互關聯的組件以意外的方式表現的結果，這種方式可以並且幾乎總是如此！我們要盡量回到系統在設計，開發過程和其他策略的初期階段考量安全性問題，而在產品或服務的最前期這些資訊可以告訴我們系統的最終樣貌和操作方式。
Build階段的失敗
本著SCE的真正精神，我們必須進行實驗以發現潛在的失敗。這就引出了一個問題：我們應該進行哪些實驗才能發現系統如何處理build時安全性故障？如果漏洞掃描程序或其他build時安全工具出現故障，會發生什麼情況？它會停止PR合併嗎？ release是否會凍結？例如，如果service使用錯誤的API token ，我們就嘗試在其中一種資安工具中強制中斷它。
安全測試工具及其維運人員將永遠無法完美執行。因此，必須在假設這種故障的情況下設計系統。不允許單個工具成為單個故障來源。例如，僅依靠漏洞掃描程序但沒有對可能無法檢測和修復漏洞的補償性控制是不明智的。而且，關注於檢查服務或產品的漏洞清單意味著較少的注意力集中在可以從本質上提高安全性的設計選擇上。
重要的是，對於雲原生環境，錯誤配置(misconfigurations)是導致安全失敗的巨大原因，但不是漏洞，也不會收到CVE identifier。允許匿名訪問的容器，在服務器上打開不必要的端口，公開暴露orchestration management consoles，在處理錯誤時顯示stack trace或啟用了遠程管理功能都是所有可能導致安全故障的錯誤配置範例。儘管很容易看出這些錯誤如何直接導致安全性失敗（如果被發現是造成危害的原因，將構成巨大的“麻煩”！），但其他錯誤配置可能會更加奧妙。過時的SSL憑證是很明顯的錯誤配置，但是驗證(authentication)的錯誤可能更難發現，同時仍然可能導致相同的最終失敗。
擁抱故障可以幫助我們發現應用程序中潛在的故障根源，而不僅僅是對照OWASP Top 10。本節其餘部分概述的渾沌測試的類型旨在實現驗證安全控制，測試回應能力以及發現系統內部任何負面外部影響的目標。有了這些資訊，就可以建立一個回饋圈，以通知系統設計的改良，例如，建立一個自動腳本來關閉保護在網路層不允許開啟清單中的port number。
現在，我們將探討跨不同環境類型的應用程式中的安全性失敗，以便你切實了解如何將SCE引入軟體交付生命週期的build階段。
容器和Image Repositories中的應用程序安全性失敗
讓我們學習下表中列舉的容器中的一些常見安全性故障，並著眼於如何將這種故障注入到我們的SCE系統中。組織可能沒有在系統中安裝所有這些組件或配置，因此請將其視為說明性的起始點，以集思廣益進行自己的測試。
看影片追技術