[[252507]]

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

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

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

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

“安全實(shí)驗(yàn)為分布式系統(tǒng)的安全性實(shí)驗(yàn)提供了一種方法，以建立對(duì)抗惡意攻擊的能力的信心。”

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

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

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

示例場(chǎng)景：精釀啤酒

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

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

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

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

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

• 該團(tuán)隊(duì)首先對(duì)他們正常狀態(tài)下的假設(shè)進(jìn)行總結(jié)。
• 在 EC2 實(shí)例里為端口安全進(jìn)行一個(gè)假設(shè)。
• 為未認(rèn)證的端口改變實(shí)驗(yàn)選擇和配置 YAML 文件。
• 該配置會(huì)從已選擇的目標(biāo)中隨機(jī)指定對(duì)象，同時(shí)端口的范圍和數(shù)量也會(huì)被改變。
• 團(tuán)隊(duì)還會(huì)設(shè)置進(jìn)行實(shí)驗(yàn)的時(shí)間并縮小爆破攻擊的范圍，來確保對(duì)業(yè)務(wù)的影響最小。
• 對(duì)于第一次測(cè)試，團(tuán)隊(duì)選擇在他們的測(cè)試環(huán)境中運(yùn)行實(shí)驗(yàn)并運(yùn)行一個(gè)單獨(dú)的測(cè)試。
• 在真實(shí)的游戲日Game Day風(fēng)格里，團(tuán)隊(duì)在預(yù)先計(jì)劃好的兩個(gè)小時(shí)的窗口期內(nèi)，選擇災(zāi)難大師Master of Disaster來運(yùn)行實(shí)驗(yàn)。在那段窗口期內(nèi)，災(zāi)難大師會(huì)在 EC2 實(shí)例安全組中的一個(gè)實(shí)例上執(zhí)行這次實(shí)驗(yàn)。
• 一旦游戲日結(jié)束，團(tuán)隊(duì)就會(huì)開始進(jìn)行一個(gè)徹底的、免于指責(zé)的事后練習(xí)。它的重點(diǎn)在于針對(duì)穩(wěn)定狀態(tài)和原始假設(shè)的實(shí)驗(yàn)結(jié)果。問題會(huì)類似于下面這些：

事后驗(yàn)證問題

• 防火墻是否檢測(cè)到未經(jīng)授權(quán)的端口更改？
• 如果更改被檢測(cè)到，更改是否會(huì)被阻止？
• 防火墻是否會(huì)將有用的日志信息記錄到日志聚合工具中？
• SIEM 是否會(huì)對(duì)未經(jīng)授權(quán)的更改發(fā)出警告？
• 如果防火墻沒有檢測(cè)到未經(jīng)授權(quán)的更改，那么配置的管理工具是否發(fā)現(xiàn)了這次更改？
• 配置管理工具是否向日志聚合工具報(bào)告了完善的信息？
• SIEM 最后是否進(jìn)行了關(guān)聯(lián)報(bào)警？
• 如果 SIEM 發(fā)出了警報(bào)，安全運(yùn)營(yíng)中心是否能收到這個(gè)警報(bào)？
• 獲得警報(bào)的 SOC 分析師是否能對(duì)警報(bào)采取措施，還是缺少必要的信息？
• 如果 SOC 確定警報(bào)是真實(shí)的，那么安全事件響應(yīng)是否能簡(jiǎn)單地從數(shù)據(jù)中進(jìn)行分類活動(dòng)？

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

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

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