安全應急響應的一些經驗總結

在2016年，我儘可能的參與到了事件響應的工作中，並且我還花費了超過300小時的時間去作為今年很多安全事件或者數據泄露事件的顧問。這些工作中包括我目前正在進行的工作，協調事件受害者與事件響應人員的關係。而本文中我所列舉的這些內容，多數都來自與我的工作內容的總結經驗，另外要說明的一點是我主要和科技公司進行合作，所以在這些總結中可能會偏重科技類企業一點。

1、對日誌進行統一集中的管理可能會更好

事實上，我認為我這篇文章最重要的一點就是去教會大家如何去區分什麼是標準的安全事件，什麼是災難性的事件。而根據日誌記錄的好壞，將可能成為其中非常重要，甚至可以說是決定性的部分。

我發現，反覆的對日誌進行審計，能夠使你在應對事件時更好的去提供安全策略並且有效的應對事件。因此，我建議任何安全部門或者相關團隊都應該去推出一個全面的解決方案，並且儘可能的去投資它，因為這可能意味著需要你們將所有的日誌從所有主機、應用程序並且跨團隊的去進行歸納整理，儘可能的去減少日誌的不同類別。我相信通過這一做法將能在未來為你們團隊去進行安全防護提供可靠的信息，並且還可以滿足其他團隊的可用性需求目標。

A gotcha – 注意用戶在您記錄的日誌中的隱私，以及相關信息的長期存儲是否會出現違規。其實縮短保留期以保護用戶隱私是非常常見的做法，當然這還將取決於您構建的產品是否有更大的需求。

結論：在大多數安全項目中，優先考慮進行良好，可訪問，集中和可報警的日誌記錄整理。如果這一條做的好，那麼很有可能在10分鐘內你就會發現一個可能出現的安全警報。

2、當無法找到事件的根本原因時

在這即將過去的一年裡，我不止一次的碰到過事件及時已經被解決了，但是仍然無法找到根本原因的情況。這對於很多應急響應人員來說無疑是一場噩夢，因為這意味著面對領導層或者管理層描述自己的解決方案時只能做到暫時的緩解，卻無法進行一些明確的針對，不得不使這個情況成為一個看起來心有餘而力不足的問題。

事實上，如果能夠找到根本原因，那麼解決方案更像是：

我們擦拭了這台筆記本電腦，更換了這台伺服器，翻閱了這個證書。

而如果無法找到根本原因，解決方案更像是：「我們擦拭了所有的筆記本電腦，更換了所有的伺服器，翻閱了所有的證書。」

發現事件的根本原因就像是一個非常重要的里程碑，它決定了事件將要發生的所有可能環境和情緒，以及它是否會走向不好的方向。如果無法發現根本原因，那麼對於整個團隊來說都可能是有一片烏雲徘徊在頭頂，使所有人都顯得慌張不安，進而感到工作十分困難。因此，不管你的團隊是大還是小 – 重要的是經常進行危機演練。

結論：進行常規情況和紅藍對抗練習。這時你們需要將隨機錯誤提供賞金或漏洞披露視為非常有風險的做法。並且在練習場景中，你不能進行控制，你不是無所不知，正確的日誌不存在，你並不能理解很多問題，從現在開始與你的團隊戰鬥。

3、攻擊者將可能針對家庭進行持續很長時間的攻擊。

「帶自己的設備」通常用於明確描述員工對組織帶來的風險，但這其實並不能很好地描述針對組織內的個人的直接攻擊。

今年涉及APT團體的事件很多都是將攻擊直接集中在員工的個人電子郵件和終端上。這就使得不管他們是在個人帳戶和設備上共享憑據或訪問令牌，還是從家裡訪問公司帳戶，或者他們在辦公室出現他們的個人設備這都顯得無關緊要。

但往往了解從員工家到企業資產的橫向移動是非常困難的，手動的去跟進員工是調查的主要方式。目前一個常見的趨勢是從對個人帳戶和未在公司網路上使用的設備的攻擊獲取共享密碼，但其相關的憑證是進行託管的。

此外（這歸因於「零根本原因」）工程師可能將敏感的憑證存儲在他們自己的個人雲基礎設施中以遠程調試生產基礎設施中，而這很可能是具有高風險性的。

結論：這需要尋找改善員工在家中進行安全防護的方法，對他們進行補貼要求他們使用密碼管理器，MFA硬體或任何其他你可以獲得的。推動他們和你的安全團隊進行多溝通，如果他們有個人安全問題或在下班時看到不良行為，對他們進行教導並使他們能夠保護自己的家人免受威脅。

4、比特幣成為了重要目標，即使你可能並不擁有它

比特幣平台越來越多的受到攻擊，而很多黑客們很可能去訪問或者參與到比特幣公司中去，因此這需要你非常的注意。有關這種趨勢的更多信息，或者SendGrid博客上的公共示例，請參考Blockchain Graveyard。

結論：如果你深深的依賴著合作夥伴的技術，那麼你首先要做的是去管理這種風險。而如果你是一個比特幣公司，那麼你可能需要儘可能的去限制除了您的合作夥伴的訪問。

5、複雜性往往意味著你的「輕視」

今年的許多事件公告都將「複雜的攻擊者」作為他們的問題的敘述。而這樣做往往會導致外界大量的批評，這看起來就像是他們表現出的妥協已經暴露了。

其實大多數漏洞都開始於魚叉式網路釣魚，商品漏洞，泄漏密鑰或其他一些明顯或的可預防的細節。

然而，這些往往都不是大家去認為感到「複雜」的方面。實際上這些一開始看起來令人有些犯「尷尬癌」的攻擊方式，往往在其最終的攻擊出現後盡皆消散。

因此，不要通過他們選擇的最初攻擊向量來判斷對手，他們很可能在最終告訴你真正「複雜」的那一面。

例如，雖然初始向量可能不是顯著的或有趣的，但攻擊者從單獨的平台進行入侵訪問或獲取憑證就可以發現一些讓他們為之心動的內容。

結論：「複雜的」攻擊者往往不會在最初的入侵上努力，展現他們的肌肉，因此不要低估那些初期看起來並不成熟的攻擊，對手總是會盡最大的努力。這個目前正在運行的釣魚攻擊很可能會跟著一個你不知道的新的0Day。

6、管理好你的隱私和密鑰

隱私管理的好壞是公司是否遭受安全事件的一個重要分水嶺。在過去的一年裡我並沒有接觸到任何一家進行了嚴格的隱私管理的公司出現過安全事故，而這可能意味著安全事件在這種情況下發生的並不多，或者說不足以需要我這樣的人來進行諮詢。

事實上，存儲在源代碼中的密鑰、泄露的雲平台記錄、沒有採取任何安全措施的員工端或個人設備，甚至是複製粘貼到gist和pastebin中的對我來說都是意味著一件事，隱私以及密鑰的管理存在著嚴重的疏漏，而這將可能導致攻擊者進一步的擴大破壞程度。

結論：認真的去了解你所使用的雲平台，避免將秘密、隱私放在源代碼中，盡量讓真正的隱私遠離開發人員，並能夠快速而頻繁地去進行更換密鑰。

7、竊取證書仍然是最容易的做法

在正常的進行信息傳遞時，組織內應該要儘可能去避免密碼的重複使用，尤其是高層領導間，但在過去的一年裡，仍然發生了幾起。並且最為重要的是，這種意識的不到位造成的結果就是相關登陸憑證的丟失。

而很多身份管理商正是在這方面進行了拓展，將管理憑據與登錄過程在雲產品上進行了集成，我沒有對任何在企業對身份解決方案中破壞MFA的事件進行回應，當單點登錄集成不是一個選項時，在每個產品中查找MFA選項並執行它們也是一個主要的緩解步驟。 特彆強調一下GitHub是非常必要的，因為很多團隊經常將秘密存儲在源代碼中，這時就可以通過強制的MFA對團隊進行保護，直到更好的秘密存儲選項由團隊同意了進行。

8、內部威脅其實是有一些模式可循的

我在今年的工作遇到的最小的問題是涉及到內部威脅的情況。其實每個內部人員出現問題時都在一個已知的動機範圍內，這一點我已經在好幾年都見過了了，2016年也不例外。

比如那些非常關注矽谷創業文化的人，他們在與媒體接觸然後引起媒體關注到一些創業公司方面的做法其實非常具有典型性。

具體來說，這其實就是使用了一個內部威脅模型：

如果我現在給科技新聞進行曝光，也許他們就會把這個寫成是我的科技創業想法。

雖然這是一個相當具體的模型，但是技術公司的員工真的很喜歡泄漏IP和產品信息來獲得這種結果。

這其實是非常常見的情況，完全可以考慮將其作為一種內部威脅的發展趨勢類型。並且這是很難防禦的，因為這些通常是僱員們不需要太多的信任就可以發生泄漏的現象，很並且難給予廣泛適用的預防建議，所以大多數CEO都會選擇對員工透明，並接受這種風險。

我看到的第二個模式是內部的客戶支持工具。一旦你選擇了一定數量的員工可以訪問管理工具，其中很可能就有一個員工是內鬼，與他人串通。

9、努力去衡量和消除你的債務

我今年協助的所有組織都有一個不正常的情況就是存在技術債務。這使我不得不相信，將「債務」問題作為工程過程的一部分進行考慮的公司通常是擁有嚴格紀律的組織，也就會使得其具有較低的風險。而這也就是為什麼，他們可以積極競爭、冒險甚至是靈活的進行業務轉換。

實際上，從開發到產品成功發布期間，公司之間主要的差異就在於他們如何記錄債務，並對他們的債務水平進行一個「回顧」，然後償還債務。

我很少看到一個團隊能夠完全消除所有的債務，但至少不尊重債務的組織從來沒有走遠的，因為這會使得他們不能再在違約中得到幫助。債務其實有多種形式：規模，開發速度，現場可靠性，客戶流失，自動化之前的手動工作量和安全性。

問題是安全債務沉默。每一種其他形式的債務導致錯誤，客戶投訴，費用和工程師出現狀況。安全債務只會導致違約，幾乎不可能量化，因此它需要手動工作量或技術線索來表現安全債務。

一個完全掌握債務的工程組織如果在一個公司出現是非常罕見的，但這其實是一個很好的狀況，表明這是一個安全性高的組織。

我很少在實踐中看到這一點，但這種水平的工程的出現毫無疑問是一個公司可能成為偉大的跡象。Google就是這樣的一家公司，圍繞其發布實踐構建了「錯誤債務」，並圍繞它制定了政策，這是我發現的使「債務」成為要衡量和解決的客觀問題的最好的例子之一。

實際上大多數工程組織不知道他們的一些基本流程（回顧，驗屍）幫助他們避免大量債務。

本文為嘶吼編輯編譯，如若轉載，請註明來源於嘶吼： 安全應急響應的一些經驗總結

推薦閱讀：