系統日志的安全管理與審計 | FreeBuf甲方群話題討論

當企業遇到安全攻擊事件時，系統設備產生的日志能協助進行安全事件的分析與還原，盡快找到事件發生的時間、原因等，而不同設備間的日志聯動，還能關聯分析監測真正有威脅的攻擊行為，還原出真實的攻擊情況，可見日志對抵御安全威脅起著至關重要的作用，對日志進行安全管理，已成為安全運營中不可或缺的一環。本期話題我們將圍繞企業設備日志的安全管理，就相關問題展開討論。

系統設備產生的日志，如果在攻擊事件中被清掉了，有沒有什么恢復方法？一般日志管理這一塊平時應該怎么做？

A1：要不上日志審計設備，要不統一備份日志到專用服務器。

A2：日志Syslog或者Kafka發到態勢感知平臺，為提升查詢效率，數據量大可考慮冷熱數據分離存儲（冷數據：長周期數據，如1-12個月；熱數據：短周期數據，如1個月內的數據），流量或者行為數據縮短保存周期。

A3：重要日志需要推到集中的日志平臺，有商用的方案，也可以自建ELK那一套，可以加上各種Beat，也是夠用的。

A4：硬件設備Syslog發送存著就好。如果是主機的話，HIDS都會收集這些日志存到服務端的，為的就是避免日志被篡改。日志管理就是SIEM那一套了，ELK或者商業化產品。

A5：日志被刪除了，如果沒被其他數據覆蓋的話可以嘗試數據恢復，但是一般不推薦這樣做，這是靠運氣，靠不住啊。所以才有了SOC，SOC除了安全綜合分析、運營的作用，也可以作為安全日志數據的備份，防止原始日志被刪除。

Q：大家接入SOC的日志，都是哪些設備的日志比較有用？或者是難點？如資產類數據、安全設備日志或其他網絡設備日志？

A1：SOC接入主機防護、防火墻、流量分析、日志審計等安全設備日志。

A2：個人還是傾向于安全設備、網絡設備和主機設備日志比例 6:3:1，難點在于網絡設備日志和主機設備日志有價值的比例過低，占用資源太多。

A3：日志接入屬于SOC告警中心的業務范圍。對于安全監測有益的日志都需要接入，基于業務場景形成單體異常告警。如HIDS、WAF、IDS、防火墻、各類網絡設備變更記錄、桌管日志、堡壘機日志、數據作業平臺日志、內部賬號登錄日志、郵箱日志、AD日志、各類自研應用日志等等。

A4：難點有解密流量、Nginx代理（導致源IP無法溯源）、規則覆蓋不全、流量覆蓋不全等。

A5：網絡跟安全設備的日志比較有用，也比較容易取得，主要接入SOC的也是這兩類數據。

A6：能接盡接，硬盤越來越便宜了不是。難點就是關聯分析起來很困難，各家嘴上都很厲害，實際都很困難。

Q：日志審計做起來是不是比較麻煩？比如網絡中的各種設備的日志都放在一起，進行綜合性的查詢，對于不同格式，以及兼容性、響應速率，有沒有比較好的解決辦法？

A1：是很麻煩，所以寄希望于人工智能分析，但目前還很困難。

A2：有二開能力可以做日志融合工作，這樣可以按照自己想法去優化日志這塊工作。

A3：不太建議在日志格式統一做太多的工作，在日志種類較多的現在，此工作量巨大，占用資源較多，可以將日志格式定粗一點，更多利用規則將日志利用起來。其實日志處理工作，很多安全設備已經幫你去處理了，更多可以關注在IP、攻擊特征等的關聯上，而不是去從底層去做分類、定義，這工作投入與產出完全不成正比，嚴格上說，沒多大實際意義。最后補充一點，要想利用好SOC，最好盡量少地址轉換或者可以備注，無法有效地址溯源發現也沒啥用，因為后續的溯源追蹤會很難搞。

A4：可建立安全數據標準，保障不同來源數據按照相同標準進行解析，不同來源告警按照告警類別做映射，從而保證不同數據源告警可以使用一套分析規則進行分析和統計。

A5：異構日志處理的話，一個是內部從日志合規等角度推進日志規定的起早跟落地實踐，拉研發一起給出標準化的參考案例，但這個部分只對自研的部分起作用，外購的系統還有老舊系統的日志就只有自己去把關鍵信息去解析出來，無法用的部分丟棄掉，然后重組存到集中日志平臺中去。

A6：日志審計，狹隘的可以說是SIEM查日志配置告警，這個其實就基本靠寫正則解析獲取自己的字段，過程很痛苦，結果還是很方便的。ELK我不清楚能不能跨Index，Splunk是可以的。

A7：想要做好日志審計，技術、產品內力缺一不可。不同格式的問題在技術上來說簡單地去切割日志轉換成統一的格式即可。通過單體告警+可疑事件思路快速找到準確的入侵或違規事件。單體告警：商用安全設備自有規則，根據滲透、合規經驗自定義規則。可疑事件：聚合多個告警產生準確事件。籠統地說可分為人員事件（違規、泄密）和入侵事件（同一主機入侵深度、不同主機入侵廣度）。將準確事件拋給預置的SOAR劇本進行快速處置（前期手動，完全訓練成熟后才能考慮逐步自動化）。

話題二：RSA加密的Public key，泄露了會有啥風險么，需要更換么？

A1：Public key本身不就是公開的嗎？結合業務具體場景分析下，Public key不是開放給指定個人的話就沒啥問題。

A2：簡單看了下邏輯，大概是這樣。實際內容是先用一個隨機的AES加密，隨機的AES秘鑰和AES加密后的內容再通過RSA加密傳給服務端。解密服務端返回的時候，應該是直接用隨機生成的AES解密的。這樣Public key泄露了，應該是有問題了？比如我可以直接偽造一個內容，用一個指定的AES秘鑰加密，然后用泄露的Public key 再做RAS加密，服務端應該是會認為是一個正常的業務請求。服務端返回后的內容，就可以直接用指定的AES秘鑰解密，可以這樣理解么？

A3：這有什么意義嗎？你這個只是加密流程，不是業務場景，你要結合業務場景去看。

A4：你的邏輯是對的，但是你忘了還有個第三方的CA。非對稱加密里的CA有RSA的私鑰匙的，可以防止偽造。所以非對稱加密里公鑰就是公開的，要保密的是私鑰。這個場景里，負責數據加密的是AES，RSA做的是AES秘鑰的分發而已。

A5：對，RSA其實就是起到了傳遞AES秘鑰的作用。理論上拿到RSA公鑰，也無法解密出來AES加密的內容。想了下，如果有人拿到了公鑰，想構造出來一個服務端可以正常響應的請求，還得需要知道AES加密前的所有內容，這個有點苛刻了。好像不會有什么風險。

Q：話說這個AES加密有什么作用嗎？

A1：就是把內容加密一下。客戶端AES加密后，還需要把AES秘鑰發給服務端。所以客戶端把AES秘鑰又做了一次RSA加密。這個邏輯似乎比較常見。

A2：因為我看著不是最后都要做一次RSA加密嘛，這個傳輸的時候AES密鑰和內容是一起傳輸的，RSA密鑰泄露后那不就相當于都泄露了嗎？那RSA之前的加密似乎沒什么用了啊。

A3：RSA只做前面的AES密鑰分發，后面傳輸數據都只用AES加密就好了的。非對稱加密適合做身份驗證、秘鑰分發（速度慢）；對稱加密適合做數據加密（速度快）。