一種新的安全檢測的方法

2018-12-14 12:37:00

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

我們當中有多少人曾說出過下面這句話:“我希望這能起到作用!”?

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

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

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

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

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

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

範例場景:精釀啤酒

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

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

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

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

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

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

事後驗證問題

  • 防火牆是否檢測到未經授權的埠更改?
  • 如果更改被檢測到,更改是否會被阻止?
  • 防火牆是否會將有用的紀錄檔資訊記錄到紀錄檔聚合工具中?
  • SIEM 是否會對未經授權的更改發出警告?
  • 如果防火牆沒有檢測到未經授權的更改,那麼設定的管理工具是否發現了這次更改?
  • 設定管理工具是否向紀錄檔聚合工具報告了完善的資訊?
  • SIEM 最後是否進行了關聯報警?
  • 如果 SIEM 發出了警報,安全運營中心是否能收到這個警報?
  • 獲得警報的 SOC 分析師是否能對警報採取措施,還是缺少必要的資訊?
  • 如果 SOC 確定警報是真實的,那麼安全事件響應是否能簡單地從資料中進行分類活動?

我們系統中對失敗的承認和預期已經開始揭示我們對系統工作的假設。我們的使命是利用我們所學到的,並更加廣泛地應用它。以此來真正主動地解決安全問題,來超越當前傳統主流的被動處理問題的安全模型。

隨著我們繼續在這個新領域內進行探索,我們一定會發布我們的研究成果。如果您有興趣想了解更多有關研究的資訊或是想參與進來,請隨時聯絡 Aaron Rinehart 或者 Grayson Brewer。

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