通過集中日志記錄來減少安全風險
日志記錄和日志分析對于保護基礎設施安全來說至關重要，尤其是當我們考慮到通用漏洞的時候。這篇文章基于我在 FOSDEM'19 上的閃電秀《 Let's use centralized log collection to make incident response teams happy 》，目的是提高大家對日志匱乏這種安全問題的重視，提供一種避免風險的方法，并且倡議更多的安全實踐(利益聲明: 我為 NXLog 工作)。
為什么要收集日志?為什么要集中日志記錄?
確切的說，日志是寫入磁盤的僅追加的記錄序列。在實際生活中，日志可以在你嘗試尋找異常的根源時幫助你調查基礎設施的問題。當你有多個使用自己的標準與格式的日志的異構系統，并且想用一種可靠的方法來接收和處理它們的時候，挑戰就來臨了。這通常以元數據為代價的。集中日志記錄解決方案需要共性，這種共性常常會去除許多開源日志記錄工具所提供的豐富的元數據。
日志記錄與監控匱乏的安全風險
開源 Web 應用程序安全項目(Open Web Application Security Project)( OWASP )是一個為業界貢獻了許多杰出項目(包括許多專注于軟件安全的 工具 )的非營利組織。OWASP 定期為應用開發人員和維護者報告最危險的安全挑戰。在最新一版《 10 項最嚴重的 Web 應用程序安全風險 》中，OWASP 將日志記錄和監控匱乏加入了列表中。OWASP 警告下列情況會導致日志記錄、檢測、監控和主動響應的匱乏：
- 未記錄重要的可審計性事件，如：登錄、登錄失敗和高額交易。
- 告警和錯誤事件未能產生、產生不足或不清晰的日志信息。
- 日志信息僅在本地存儲。
- 對于實時或準實時的主動攻擊，應用程序無法檢測、處理和告警。
可以通過集中日志記錄(例如，不僅將日志本地存儲)和結構化日志數據以進一步分析來緩解上述情形(例如，在告警儀表盤和安全套件中)。
舉例來說, 假設一個 DNS 查詢會導向名為 hacked.badsite.net 的惡意網站。通過 DNS 監控，管理員監控并且主動的分析 DNS 請求與響應。DNS 監控的效果依賴于充足的日志記錄與收集來發現潛在問題，同樣也依賴于結構化 DNS 日志的結果來進一步分析。
- 2019-01-29
- Time (GMT) Source Destination Protocol-Info
- 12:42:42.112898 SOURCE_IP xxx.xx.xx.x DNS Standard query 0x1de7 A hacked.badsite.net
你可以在 NXLog 社區版 中自己嘗試一下這個例子，也可以嘗試其他例子和代碼片段。 (再次聲明：我為 NXLog 工作)
重要的一點：非結構化數據與結構化數據
花費一點時間來考慮下日志數據格式是很重要的。例如，讓我們來考慮以下日志消息：
- debug1: Failed password for invalid user amy from SOURCE_IP port SOURCE_PORT ssh2
這段日志包含了一個預定義的結構，例如冒號前面的元數據關鍵詞(debug1)然而，余下的日志字段是一個未結構化的字符串(Failed password for invalid user amy from SOURCE_IP port SOURCE_PORT ssh2)。因此，即便這個消息是人類可輕松閱讀的格式，但它不是一個計算機容易解析的格式。
非結構化的事件數據存在局限性，包括難以解析、搜索和分析日志。重要的元數據通常以一種自由字符串的形式作為非結構化數據字段，就像上面的例子一樣。日志管理員會在他們嘗試標準化/歸一化日志數據與集中日志源的過程中遇到這個問題。
接下來怎么做
除了集中和結構化日志之外，確保你收集了正確的日志數據——Sysmon、PowerShell、Windows 事件日志、DNS 調試日志、ETW、內核監控、文件完整性監控、數據庫日志、外部云日志等等。同樣也要選用適當的工具和流程來來收集、匯總和幫助理解數據。
希望這對你從不同日志源中集中日志收集提供了一個起點：將日志發送到儀表盤、監控軟件、分析軟件以及像安全性資訊與事件管理(SIEM)套件等外部源。
