一種新的安全檢測的方法

知識 12-15

一種新的安全檢測的方法

編譯自： https://opensource.com/article/18/4/new-approach-security-instrumentation
作者： Aaron Rinehart

譯者： hopefully2333

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

我們當中有多少人曾說出過下面這句話：「我希望這能起到作用！」？

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

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

「安全實驗為分散式系統的安全性實驗提供了一種方法，以建立對抗惡意攻擊的能力的信心。」

在分散式系統的安全性和複雜性方面，需要反覆地重申混沌工程界的一句名言，「希望不是一種有效的策略」。我們多久會主動測試一次我們設計或構建的系統，來確定我們是否已失去對它的控制？大多數組織都不會發現他們的安全控制措施失效了，直到安全事件的發生。我們相信「安全事件不是偵察措施」，而且「希望不要出事也不是一個有效的策略」應該是 IT 專業人士執行有效安全實踐的口號。

行業在傳統上強調預防性的安全措施和縱深防禦，但我們的任務是通過偵探實驗來驅動對安全工具鏈的新知識和見解。因為過於專註於預防機制，我們很少嘗試一次以上地或者年度性地手動測試要求的安全措施，來驗證這些控制項是否按設計的那樣執行。

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

示例場景：精釀啤酒

思考一個用於接收精釀啤酒訂單的 web 服務或者 web 應用。

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

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

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

該團隊希望能小規模地通過評估埠安全和防火牆設置來讓他們能夠檢測、阻止和警告他們 EC2 安全組上埠設置的錯誤配置更改。

該團隊首先對他們正常狀態下的假設進行總結。
在 EC2 實例里為埠安全進行一個假設。
為未認證的埠改變實驗選擇和配置 YAML 文件。
該配置會從已選擇的目標中隨機指定對象，同時埠的範圍和數量也會被改變。
團隊還會設置進行實驗的時間並縮小爆破攻擊的範圍，來確保對業務的影響最小。
對於第一次測試，團隊選擇在他們的測試環境中運行實驗並運行一個單獨的測試。
在真實的遊戲日(Game Day)風格里，團隊在預先計劃好的兩個小時的窗口期內，選擇災難大師(Master of Disaster)來運行實驗。在那段窗口期內，災難大師會在 EC2 實例安全組中的一個實例上執行這次實驗。
一旦遊戲日結束，團隊就會開始進行一個徹底的、免於指責的事後練習。它的重點在於針對穩定狀態和原始假設的實驗結果。問題會類似於下面這些：