一種新的安全檢測的方法
不要只測試已有系統(tǒng),強(qiáng)安全要求更積極主動(dòng)的策略。
我們當(dāng)中有多少人曾說出過下面這句話:“我希望這能起到作用!”?
毫無疑問,我們中的大多數(shù)人可能都不止一次地說過這句話。這句話不是用來激發(fā)信心的,相反它揭示了我們對(duì)自身能力和當(dāng)前正在測試的功能的懷疑。不幸的是,這句話非常好地描述了我們傳統(tǒng)的安全模型。我們的運(yùn)營基于這樣的假設(shè),并希望我們實(shí)施的控制措施 —— 從 web 應(yīng)用的漏掃到終端上的殺毒軟件 —— 防止惡意的病毒和軟件進(jìn)入我們的系統(tǒng),損壞或偷取我們的信息。
滲透測試通過積極地嘗試侵入網(wǎng)絡(luò)、向 web 應(yīng)用注入惡意代碼或者通過發(fā)送釣魚郵件來傳播病毒等等這些步驟來避免我們對(duì)假設(shè)的依賴。由于我們在不同的安全層面上來發(fā)現(xiàn)和滲透漏洞,手動(dòng)測試無法解決漏洞被主動(dòng)打開的情況。在安全實(shí)驗(yàn)中,我們故意在受控的情形下創(chuàng)造混亂,模擬事故的情形,來客觀地檢測我們檢測、阻止這類問題的能力。
“安全實(shí)驗(yàn)為分布式系統(tǒng)的安全性實(shí)驗(yàn)提供了一種方法,以建立對(duì)抗惡意攻擊的能力的信心。”
在分布式系統(tǒng)的安全性和復(fù)雜性方面,需要反復(fù)地重申混沌工程界的一句名言,“希望不是一種有效的策略”。我們多久會(huì)主動(dòng)測試一次我們設(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)測試要求的安全措施,來驗(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)行檢測,對(duì)于安全性檢測,你可以將這個(gè)問題分成兩個(gè)主要方面:測試,和我們稱之為實(shí)驗(yàn)的部分。測試是對(duì)我們已知部分的驗(yàn)證和評(píng)估,簡單來說,就是我們在開始找之前,要先弄清楚我們在找什么。另一方面,實(shí)驗(yàn)是去尋找獲得我們之前并不清楚的見解和知識(shí)。雖然測試對(duì)于一個(gè)成熟的安全團(tuán)隊(duì)來說是一項(xiàng)重要實(shí)踐,但以下示例會(huì)有助于進(jìn)一步地闡述兩者之間的差異,并對(duì)實(shí)驗(yàn)的附加價(jià)值提供一個(gè)更為貼切的描述。
示例場景:精釀啤酒
思考一個(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)行滲透測試,所以公司認(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ì)把安全控件不能檢測到的新問題引入到系統(tǒng)中。
該團(tuán)隊(duì)希望能小規(guī)模地通過評(píng)估端口安全和防火墻設(shè)置來讓他們能夠檢測、阻止和警告他們 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ì)于第一次測試,團(tuán)隊(duì)選擇在他們的測試環(huán)境中運(yùn)行實(shí)驗(yàn)并運(yùn)行一個(gè)單獨(dú)的測試。
- 在真實(shí)的游戲日風(fēng)格里,團(tuán)隊(duì)在預(yù)先計(jì)劃好的兩個(gè)小時(shí)的窗口期內(nèi),選擇災(zāi)難大師來運(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)證問題
- 防火墻是否檢測到未經(jīng)授權(quán)的端口更改?
- 如果更改被檢測到,更改是否會(huì)被阻止?
- 防火墻是否會(huì)將有用的日志信息記錄到日志聚合工具中?
- SIEM 是否會(huì)對(duì)未經(jīng)授權(quán)的更改發(fā)出警告?
- 如果防火墻沒有檢測到未經(jīng)授權(quán)的更改,那么配置的管理工具是否發(fā)現(xiàn)了這次更改?
- 配置管理工具是否向日志聚合工具報(bào)告了完善的信息?
- SIEM 最后是否進(jìn)行了關(guān)聯(lián)報(bào)警?
- 如果 SIEM 發(fā)出了警報(bào),安全運(yùn)營中心是否能收到這個(gè)警報(bào)?
- 獲得警報(bào)的 SOC 分析師是否能對(duì)警報(bào)采取措施,還是缺少必要的信息?
- 如果 SOC 確定警報(bào)是真實(shí)的,那么安全事件響應(yīng)是否能簡單地從數(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ì)本文提供的見解和想法。