我們的運營基于這樣的假設(shè)，并希望我們實施的控制措施 —— 從 web 應(yīng)用的漏掃到終端上的殺毒軟件 —— 防止惡意的病毒和軟件進入我們的系統(tǒng)，損壞或偷取我們的信息。

不要只測試已有系統(tǒng)，強安全要求更積極主動的策略。

我們當(dāng)中有多少人曾說出過下面這句話：“我希望這能起到作用！”？

毫無疑問，我們中的大多數(shù)人可能都不止一次地說過這句話。這句話不是用來激發(fā)信心的，相反它揭示了我們對自身能力和當(dāng)前正在測試的功能的懷疑。不幸的是，這句話非常好地描述了我們傳統(tǒng)的安全模型。我們的運營基于這樣的假設(shè)，并希望我們實施的控制措施 —— 從 web 應(yīng)用的漏掃到終端上的殺毒軟件 —— 防止惡意的病毒和軟件進入我們的系統(tǒng)，損壞或偷取我們的信息。

滲透測試通過積極地嘗試侵入網(wǎng)絡(luò)、向 web 應(yīng)用注入惡意代碼或者通過發(fā)送釣魚郵件來傳播病毒等等這些步驟來避免我們對假設(shè)的依賴。由于我們在不同的安全層面上來發(fā)現(xiàn)和滲透漏洞，手動測試無法解決漏洞被主動打開的情況。在安全實驗中，我們故意在受控的情形下創(chuàng)造混亂，模擬事故的情形，來客觀地檢測我們檢測、阻止這類問題的能力。

“安全實驗為分布式系統(tǒng)的安全性實驗提供了一種方法，以建立對抗惡意攻擊的能力的信心?！?/p>

在分布式系統(tǒng)的安全性和復(fù)雜性方面，需要反復(fù)地重申混沌工程界的一句名言，“希望不是一種有效的策略”。我們多久會主動測試一次我們設(shè)計或構(gòu)建的系統(tǒng)，來確定我們是否已失去對它的控制？大多數(shù)組織都不會發(fā)現(xiàn)他們的安全控制措施失效了，直到安全事件的發(fā)生。我們相信“安全事件不是偵察措施”，而且“希望不要出事也不是一個有效的策略”應(yīng)該是 IT 專業(yè)人士執(zhí)行有效安全實踐的口號。

行業(yè)在傳統(tǒng)上強調(diào)預(yù)防性的安全措施和縱深防御，但我們的任務(wù)是通過偵探實驗來驅(qū)動對安全工具鏈的新知識和見解。因為過于專注于預(yù)防機制，我們很少嘗試一次以上地或者年度性地手動測試要求的安全措施，來驗證這些控件是否按設(shè)計的那樣執(zhí)行。

隨著現(xiàn)代分布式系統(tǒng)中的無狀態(tài)變量的不斷改變，人們很難充分理解他們的系統(tǒng)的行為，因為會隨時變化。解決這個問題的一種途徑是通過強大的系統(tǒng)性的設(shè)備進行檢測，對于安全性檢測，你可以將這個問題分成兩個主要方面：測試，和我們稱之為實驗的部分。測試是對我們已知部分的驗證和評估，簡單來說，就是我們在開始找之前，要先弄清楚我們在找什么。另一方面，實驗是去尋找獲得我們之前并不清楚的見解和知識。雖然測試對于一個成熟的安全團隊來說是一項重要實踐，但以下示例會有助于進一步地闡述兩者之間的差異，并對實驗的附加價值提供一個更為貼切的描述。

示例場景：精釀啤酒

思考一個用于接收精釀啤酒訂單的 web 服務(wù)或者 web 應(yīng)用。

這是這家精釀啤酒運輸公司的一項重要服務(wù)，這些訂單來自客戶的移動設(shè)備、網(wǎng)頁，和通過為這家公司精釀啤酒提供服務(wù)的餐廳的 API。這項重要服務(wù)運行在 AWS EC2 環(huán)境上，并且公司認(rèn)為它是安全的。這家公司去年成功地通過了 PCI 規(guī)則，并且每年都會請第三方進行滲透測試，所以公司認(rèn)為這個系統(tǒng)是安全的。

這家公司有時一天兩次部署來進行 DevOps 和持續(xù)交付工作，公司為其感到自豪。

在了解了混沌工程和安全實驗方面的東西后，該公司的開發(fā)團隊希望能確定，在一個連續(xù)不斷的基礎(chǔ)上，他們的安全系統(tǒng)對真實世界事件的有效性和快速恢復(fù)性怎么樣。與此同時，確保他們不會把安全控件不能檢測到的新問題引入到系統(tǒng)中。

該團隊希望能小規(guī)模地通過評估端口安全和防火墻設(shè)置來讓他們能夠檢測、阻止和警告他們 EC2 安全組上端口設(shè)置的錯誤配置更改。

• 該團隊首先對他們正常狀態(tài)下的假設(shè)進行總結(jié)。

• 在 EC2 實例里為端口安全進行一個假設(shè)。

• 為未認(rèn)證的端口改變實驗選擇和配置 YAML 文件。

• 該配置會從已選擇的目標(biāo)中隨機指定對象，同時端口的范圍和數(shù)量也會被改變。

• 團隊還會設(shè)置進行實驗的時間并縮小爆破攻擊的范圍，來確保對業(yè)務(wù)的影響最小。

• 對于第一次測試，團隊選擇在他們的測試環(huán)境中運行實驗并運行一個單獨的測試。

• 在真實的游戲日Game Day風(fēng)格里，團隊在預(yù)先計劃好的兩個小時的窗口期內(nèi)，選擇災(zāi)難大師Master of Disaster來運行實驗。在那段窗口期內(nèi)，災(zāi)難大師會在 EC2 實例安全組中的一個實例上執(zhí)行這次實驗。

• 一旦游戲日結(jié)束，團隊就會開始進行一個徹底的、免于指責(zé)的事后練習(xí)。它的重點在于針對穩(wěn)定狀態(tài)和原始假設(shè)的實驗結(jié)果。問題會類似于下面這些：

事后驗證問題

• 防火墻是否檢測到未經(jīng)授權(quán)的端口更改？

• 如果更改被檢測到，更改是否會被阻止？

• 防火墻是否會將有用的日志信息記錄到日志聚合工具中？

• SIEM 是否會對未經(jīng)授權(quán)的更改發(fā)出警告？

• 如果防火墻沒有檢測到未經(jīng)授權(quán)的更改，那么配置的管理工具是否發(fā)現(xiàn)了這次更改？

• 配置管理工具是否向日志聚合工具報告了完善的信息？

• SIEM 最后是否進行了關(guān)聯(lián)報警？

• 如果 SIEM 發(fā)出了警報，安全運營中心是否能收到這個警報？

• 獲得警報的 SOC 分析師是否能對警報采取措施，還是缺少必要的信息？

• 如果 SOC 確定警報是真實的，那么安全事件響應(yīng)是否能簡單地從數(shù)據(jù)中進行分類活動？

我們系統(tǒng)中對失敗的承認(rèn)和預(yù)期已經(jīng)開始揭示我們對系統(tǒng)工作的假設(shè)。我們的使命是利用我們所學(xué)到的，并更加廣泛地應(yīng)用它。以此來真正主動地解決安全問題，來超越當(dāng)前傳統(tǒng)主流的被動處理問題的安全模型。

隨著我們繼續(xù)在這個新領(lǐng)域內(nèi)進行探索，我們一定會發(fā)布我們的研究成果。如果您有興趣想了解更多有關(guān)研究的信息或是想?yún)⑴c進來，請隨時聯(lián)系 Aaron Rinehart 或者 Grayson Brewer。

特別感謝 Samuel Roden 對本文提供的見解和想法。

[超站]友情鏈接：

四季很好，只要有你，文娛排行榜：https://www.yaopaiming.com/
關(guān)注數(shù)據(jù)與安全，洞悉企業(yè)級服務(wù)市場：https://www.ijiandao.com/