接《日志管理與分析(三)--對日志系統的攻擊》，如果你的企業沒有認真地對待日志，那么就可以說明你的企業對IT可審核性并不重視，這也就是日志記錄成為一種完善的依從性技術，許多法規和法律以及最佳實踐框架都對此作出強制性要求的原因。日志管理與分析(四)重點在于根據PCI DSS以及ISO27001標準的日志的管理規程。

01日志管理規程

日志記錄和管理的目標本質上是為你提供環境中的態勢感知(SA)，這樣你就可以在網絡中發生某些情況時進行評估、響應，并在必要時升級。SA部分通過啟用日志數據收集、分析和保存來實現。

企業很可能因為如下的某些原因而實施日志記錄：

你想要保護公司的資產(知識產權和財務數據等)。

你所處行業(銀行、醫療、信用卡處理等)要求監管依從性，確保你能夠對抗外部和內部威脅、數據丟失等。

你就是希望記錄所有日志。

就第二種原因，許多法規不僅從過程和規程的角度規定你必須做的事，還要求你能夠證明自己真的遵循和維護你的策略和規程。這可能意味著從提供最新的網絡系統訪問權限文檔，到制作備份文檔的報告的一切事情。

下面以支付卡行業(PCI)數據安全標準(DSS)舉個例子。

PCI DSS是一組技術和運營需求，意在保護信用卡持卡人數據免遭違規使用。商戶、處理設備、發卡行和服務提供商在PCI中都有利害關系。該標準的終極目標是在全球采用這些需求。

1.1假設、需求和預防措施

關鍵項目對于日志記錄、日志管理和日志審核的成功必不可少。在日志審核、響應和升級規程投入使用之前，假定如下需求已經得到滿足。

1.1.1需求

必須有一組需求，運營規程才能有效地使用：1)創建日志記錄策略，以編集PCI DSS日志相關需求，以及其他監管和運營日志需求。2)在范圍內的系統上啟用日志記錄。3)日志記錄的中端和終止本身必須記入日志、接受監控。4)記錄PCI DSS文檔規定的事件。5)生成滿足PCI DSS日志記錄需求的日志。6)范圍內的系統時間和可靠的時間服務器(NTP等)同步。7)所有日志記錄系統的時區已知并作記錄，可以和日志一起審核。

1.1.2預防措施

需要采取如下的預防措施，使日志可以用于PCI DSS依從性、其他法規和安全、取證及運營需求：

關鍵預防措施：在特定系統上記錄其操作的個人不能作為負責該系統日志審核的唯一當事人。

關鍵預防措施：PCI DSS強制實施日志安全措施，對日志的所有訪問應該記錄和監控，識別終止或者影響日志存在和質量的企圖。

這些預防措施的主要思路是確保系統完整性。本質上，沒有一個人應該擁有能夠掩蓋自己或者其他人蹤跡的控制權。

1.2常見角色和職責

常見角色和職責總結

角色	職責	涉及工作示例
應用系統管理員	管理應用程序	配置應用程序日志記錄設置，可能進行日常日志審核
系統或者網絡管理員	管理底層操作系統或者網絡	配置應用程序日志記錄設置，可能進行日常日志審核
應用程序業務負責人	負責應用程序的業務經理	批準日志記錄和日志審核所需的應用程序配置更改
安全管理員	管理一個或者多個系統/應用程序的安全控制	配置安全和日志記錄設置，進行日常日志審核
安全分析人員	處理運營安全性過程	訪問安全系統并分析日志和其他數據
安全主管或者經理	監督安全策略、過程和運營	負責日志審核規程、更新規程
事故響應人員	參與安全事故響應	處理安全事故，在響應過程中審核日志

上面指出的角色，你的企業可能沒有定義這些角色，大多企業都是一人兼顧多責。

1.3PCI和日志數據

PCI DSS對于日志記錄和監控的強制關鍵領域是需求10和需求11的各個部分。為了達到依從性，你必須實現需求；它是必要的條件。在PCI DSS文檔中，需求10陳述“跟蹤和監控對網絡資源和持卡人數據的所有訪問”。需求11陳述“定期測試安全系統和過程”。需求12陳述“維護一個處理所有個人信息安全的策略”。

1.3.1關鍵需求

10.1需求10.1涵蓋的是“建立一個過程，將對系統組件的所有訪問(特別是使用根用戶等管理權限完成的訪問)與每個單獨用戶聯系起來。”這確實是一個而有趣的需求；它不僅強制日志的存在或者建立日志記錄過程，還提到日志必須與個人綁定(不是計算機或者生成日志的“設備”)。這個需求常常給PCI實施者造成問題，因為許多人認為日志是“人的操作記錄”，而現實中他們只擁有“計算機的操作記錄”。將后者映射到實際用戶往往帶來額外的挑戰。順便說一句，PCI DSS需求8.1強制企業“在允許用戶訪問系統組件或者持卡人數據之前，要為他們分配唯一的ID”，這一條目使日志在此更加有用。10.210.2定義了需要記錄的系統事件的最小列表，這些需求的動機是為了評估和監控用戶操作，以及可能影響信用卡數據的其他事件。下面是PCI DSS需求中的列表：

• 10.2.1 訪問持卡人數據的所有單獨用戶。

• 10.2.2 具有根或者管理權限的任何個人進行的所有操作。

• 10.2.3 對所有審計跟蹤的訪問。

• 10.2.4 無效的邏輯訪問企圖。

• 10.2.5 標識和身份認證機制的使用。

• 10.2.6 審計日志初始化。

• 10.2.7 系統級對象的創建和刪除。

可以看出，上述列表覆蓋了數據訪問、特權用戶操作、日志訪問和初始化、失敗和無效的訪問請求、身份認證和授權決策和系統對象更改。重要的是，這樣的列表來源于IT治理“最佳實踐”，這些最佳實踐指出，要監控訪問、身份認證、授權變更管理、系統可用性和可疑活動。10.3而且，PCI DSS需求10更加深入，包括了每個事件中需要記錄的具體數據字段或者數值。它們提供了健康狀況的最低需求，各種IT平臺上的日志記錄機制一般都能超過這個要求。

• 10.3.1 用戶標識。

• 10.3.2 事件類型。

• 10.3.3 日期和時間。

• 10.3.4 成功或者失敗的指示。

• 10.3.5 事件來源

• 10.3.6 受影響的數據、系統組件或者資源的標識或者名稱。

可以看到，上述最小列表包含了事故分析所需的基本屬性，能夠回答如下問題：何時、誰、何地、發生何事、來自何處。10.4需求10.4，處理常常被忽略但是很關鍵的一個需求：所有日志具備準確而一致時間的需求。時間和安全事件監控的緊密結合似乎相當簡單。在家庭或者小型辦公室網絡中，系統時間往往是隨機的。不管你的服務器時間設成什么，為了設計有一定可靠性的網絡，你的系統應該配置為從可靠來源(如網絡時間協議(NTP)服務器)獲得時間同步。10.5人們必須解決日志的機密性、完整性和可用性(CIA)。

• 10.5.1：PCI DSS的10.5.1介紹了機密性：“將對審計跟蹤的查看限制在與工作相關的需求上”。這意味著，只有必須查看日志才能完成工作的人才能夠查看日志，原因之一是和身份認證相關的日志總是包含用戶名。雖然不是真正的秘密，但是用戶名稱信息提供了密碼猜測所需的50%信息。而且，因為用戶錯誤輸入證書，而在日志中顯示密碼的情況并不少見。編寫質量低劣的web應用程序可能造成密碼和web統一資源定位符(URL)一起記錄在web服務器日志中。

• 10.5.2：接下來是“完整性”，根據PCI DSS的10.5.2，必須“保護審計跟蹤文件免遭未授權修改”。這是顯而易見的，因為如果日志被未授權方修改，它們就不再是系統和用戶活動的客觀評估個弄臟。

但是人們不僅必須保留來自惡意用戶的日志，還應該保留系統故障和系統配置錯誤結果的日志。這涉及日志數據的“可用性”和“完整性”。PCI DSS 10.5.3明確指出，必須“立即將審計跟蹤文件備份到集中日志服務器或者難以修改的媒介”。確實，將日志集中到一個或者一組用于日志分析的服務器，對于日志保護和增加日志實用性都是不可或缺的，將日志備份到CD或者DVD(或者磁帶)是這一需求的另一種結果。人們應該始終記住，磁帶上的日志不容易訪問，在出現事故時也無法搜索。

許多網絡基礎設施(如路由器和交換機)被設計為將日志放到外部服務器，在設備自身上只保留極少量(或者沒有)日志。因此，對于這些系統來說，集中化的日志最為重要。PCIDSS的需求10.5.4說明了這種需求，“將無線網絡的日志復制到內部LAN上的日志服務器中”。

為了進一步降低日志修改的風險，并證明這樣的修改沒有發生，需求10.5.5要求“在日志上使用文件完整性監控和變更檢測軟件，確保現存日志數據不能在沒有警告的情況下更改”。與此同時，在日志文件中添加新的日志數據不應該生成警報，因為日志文件不斷增長，不會自己壓縮。文件完整性監控系統使用加密哈希算法，將文件和一個已知的正確副本比較。問題是，日志文件因為新紀錄的添加而不斷增長，從而導致完整性檢查的削弱。為了解決這一矛盾，應該注意完整性監控只能保證沒有被日志記錄組件不斷寫入的日志的完整性。

10.6

許多PCI DSS實施者忘記了，PCI需求10不僅要求“有日志”，還要求“有日志，并且查看它們”，10.6明確指出PCI組織應該按照PCI DSS，“至少每天一次審核所有系統組件的日志。日志審核必須至少包含執行IDS和AAA服務器等安全功能的服務器”。

因此，PCI DSS需求還覆蓋了需要“每天審核”的日志源范圍，而不僅是需要配置日志、保留或者集中化日志。考慮到大型IT環境每天可能生成以GB計算的日志，人工閱讀所有日志是不可能的。因此，PCI DSS在這個需求上有個注釋：“可以使用日志收集、解析和警報工具實現需求10.6的依從性”

10.7最后一個需求(10.7)處理另一個非常重要的日志記錄問題--日志保存，它規定：“保存審計跟蹤歷史至少一年，保持在線可用性至少三個月”。和其他無數需求不同，這一需求直接處理復雜的日志保存問題。因此，如果你無法查看1年前的日志，就違反了規定。而且，PCI DSS在更新后的版本1.1中還明確地增加了一年的需求規定。總結一下目前為止學習的PCI 日志記錄需求：

• PCI需求10規定以預先定義的細節水平記錄來自范圍內所有系統的特定事件。

• PCI要求日志中所有操作與實際用戶掛鉤。

• 范圍內的系統上的時鐘和時間應該同步。

• 應該保護所有收集日志的CIA(機密性、完整性、可用性)。

• 日志應該定期審核：特定的日志應該至少一天審核一次。

• 范圍內的所有日志應該留存至少一年。

下面更深入的研究日志和監控，這些日志和監控不僅在需求10中規定，還出現在所有其他PCI需求中。許多人可能認為PCI中的日志都在需求中說明，但實際情況更為復雜：日志出現和隱藏在所有其他的小節中。

1.3.2與日志記錄相關的其他需求

幾乎所有滿足PCI DSS需求的規定(如數據加密或者防病毒更新)，都可能使用日志文件來證明。

例如，需求1“安裝和維護防火墻配置，以保護持卡人數據”中提到，企業必須有“批準和測試所有外部網絡連接以及防火墻配置變更的正式過程”。但是，在建立這種過程之后，人們必須驗證防火墻配置變更確實得到授權，并且按照書面的變更管理規程進行。這時日志記錄變得極其方便，因為它說明了實際發生的情況，而不是“應該發生”的情況。

需求1.3包含防火墻配置的指導原則，有關于入站和出站連接性的具體陳述。必須使用防火墻日志來驗證這些配置，僅僅審核配置還不夠，因為只有日志才能說明“實際發生了什么”而不是“如何配置”。

類似地，需求2討論密碼管理“最佳實踐”和一般的安全加固，例如不運行沒有必要的服務。日志可以說明何時啟動了之前禁用的服務，這可能是不知情的系統管理員或者攻擊者的操作造成的。

需求3更進一步，處理數據加密，這和日志記錄有著直接而明確的聯系。例如，3.6小節隱含了一個要求：擁有驗證這些活動是否真正進行的日志。確切的說，大部分加密系統記錄秘鑰生成、分發和廢止的日志，這些日志對于滿足上述需求是至關重要的。

需求4處理的也是加密，由于同樣的原因，和日志記錄也有隱含的聯系。

需求5針對病毒防御。當然，為了滿足5.2小節的需求--“確保所有防病毒機制更新、活躍地運行，并且能夠生成審計日志”必修查看所提到的這些日志。

所以，即使是“使用和定期更新防病毒軟件”也可以在評估期間需要請求日志數據，因為這些信息由防病毒評估日志提供。著名的“防病毒更新失敗”問題也在日志中反映，它說明公司正處于惡意軟件的威脅之下，因為沒有更新最新特征碼的防病毒軟件只能造成虛假的安全感，損害依從性工作。

需求6頁處于同一范疇：它要求組織“開發和維護安全的系統和應用程序”，沒有強大的評估日志記錄功能和應用程序安全監控，這是無法想象的。

需求7規定“根據業務按需了解的原則限制對持卡人數據的訪問”，需要日志來驗證誰能夠訪問文中所指的數據。如果不應該看到數據的用戶出現在訪問數據的日志文件中，就需要采取糾正措施。

為每個訪問系統的用戶分配一個唯一的ID符合其他安全“最佳實踐”。在PCI中，這不僅是一個“最佳實踐”，還是一個需求。顯然，人們必須“控制用戶ID、證書和其他標識符對象的添加、刪除和修改”。大部分系統記錄這些活動的日志。

除此之外，8.5.9小節“每90天至少更改用戶密碼一次”也可以通過審核服務器日志來驗證，以便確保所有賬戶在90 天內至少修改一次密碼。

需求9介紹了安全的一個新領域--物理訪問控制，甚至連包含來訪者日志維護的9.4小節也和日志管理有關，對于這類日志有單獨的數據保存需求：“使用訪問者日志維護訪問者活動的物理評估跟蹤，保存這些日志至少3個月，除非法律有其他限制”

需求11說明掃描范圍內系統漏洞的必要性。但是，在11.4小節中要求使用IDS或者IPS：“使用網絡入侵檢測系統、基于主機的入侵檢測系統和入侵防御系統，監控所有網絡流量，并向有關人員發出可疑入侵的警報。保持所有入侵檢測和預防引擎最新”。入侵檢測只在審核日志和警報時才有用。

需求12涵蓋了更高級的問題--安全策略、安全標準和日常運營規程(例如，需求10中強制的每日日志審核規程應該在這里反映)。但是，它也和日志記錄相關，因為評估日志記錄應該是每個安全策略的一部分。除此之外，事故響應需求也和日志記錄相關：“建立、記錄和發布安全事故響應和升級規程，確保及時和有效地處理所有情況”，如果沒有高效的日志數據收集和及時審核，上述要求難以想象。

因此PCI DSS中的事件日志記錄和安全監控遠不止需求10。只有通過精心的數據收集和分析，才能滿足PCI的廣泛需求。

1.4日志記錄策略

根據PCI DSS需求，源于PCI的日志記錄策略至少必須包含如下內容：

• 足夠的日志記錄，包括日志事件類型(登錄/注銷、資源訪問、防火墻接受/拒絕、IPS/IDS警報等)和細節。

• 日志聚合和留存(1年)。

• 日志保護(確保日志不被篡改)。

• 日志審核

日志記錄策略定義應該捕獲日志數據的哪些屬性供以后審核、升級和響應。同樣，本章中使用PCI DSS的概念，但是這個策略是通用的，可以應用于非PCI活動、應用程序等場合。

現在，我們將重點放在日志審核上。PCI DSS指出：“至少每天一次審核所有系統組件的日志。日志審核必須包含執行入侵檢測系統(IDS)和身份認證、授權等安全功能的服務器，以及計費協議服務器”然后，它又增加了這一條：“可以使用日志收集、解析和報警工具滿足需求10.6的依從性”。PCI日志審核測試和驗證規程強制，合格安全評審員(QSA)應該“獲得和檢查安全策略及規程，驗證他們包含每天至少一次審核安全日志的規程，并且要求對異常情況進行后續調查”。QSA還必須確定“通過觀察和面談，驗證所有系統組件都進行了定期日志審核”。

最后，在下一個小節，我們討論日志審核規程的應用和工作流程，包括：

日志審核方法、模式和任務。

異常調查和分析。

規程和管理報告的驗證。

這些規程可以使用自動化的日志管理工具，當這些工具不可用或者不兼容應用程序生成的日志格式時，也可以人工進行。

1.5審核、響應、升級規程

日志管理的定期審核規程，這種審核由應用管理員或者安全管理員進行，可以使用自動化工具，如果這些自動化工具不可用或者不支持PCI應用程序中的日志類型，則人工進行。

PCI DSS定期日志審核的基本原則是實現如下目標：

• 確定持卡人數據沒有遭到攻擊者的入侵。

• 盡早檢測出持卡人數據的可能風險。

• 滿足PCI DSS日志審核的明確需求。

PCI DSS是每天日志審核的動機，但是它還能實現其他的目標：

• 確保處理持卡人數據的系統安全有效地運行。

• 協調日志中觀察到的與其他系統和活動之間所有可能被的異常情況(例如應用程序代碼變化或者補丁部署)。

根據上述目標，每天日志審核圍繞“基線”或者常規日志消息集的學習和文檔記錄構建。

1.5.1用日志管理工具構建一個初始基線

執行如下步驟，用日志管理工具構建一個基線：

1)確保日志管理工具收集PCI應用程序中的相關日志。2)確定工具能夠“理解”消息，并標識每個日志的“事件ID”或者消息類型。3)為初始基線選擇一個事件周期：“90天”，或者在日志收集不到90天時“全時”。4)運行一個報告，顯示每個消息類型的計數。這個報告指出系統運營90天內遇到的所有日志類型。5)如果沒有發現任何卡數據泄露，我們可以接受如上報告，作為“例行運營”基線。6)創建基線的同時應該執行一個附加步驟：即使我們斷定卡數據沒有遭到入侵，在90天內記錄的某些日志消息也可能觸發某種行動或者補救措施。這樣的消息成為“已知錯誤”，應該標記出來。

1.5.2人工構建初始基線

在日志不兼容可用工具或者可用工具不能很好地理解日志數據時，必須在不使用日志管理工具的情況下人工構建基線。為此，執行如下步驟：

1)確保來自PCI應用程序的相關日志保存在某個位置。2)為初始基線選擇一個時間周期：“90天”或者在日志收集不到90天時“全時”；檢查最早的日志時間戳確定這一點。3)從最舊的日志條目開始審核，直到最新的條目，嘗試識別它們的類型。4)人工創建所有觀測類型的摘要；如果現實的話，收集每條消息出現的次數。5)如果沒有發現任何卡數據泄露，我們可以接受如上報告，作為“例行運營”基線。

6)創建基線的同時應該執行一個附加步驟：即使我們斷定卡數據沒有遭到入侵，在90天內記錄的某些日志消息也可能觸發某種行動或者補救措施。這樣的消息被稱為“已知錯誤”，應該標記出來。

確定“已知錯誤”消息的原則：1)在不尋常的時間發生的登錄和其他“授權訪問”日志消息。2)發生在更改窗口之外的證書和權限修改日志消息。3)到期的用戶賬戶生成的任何日志消息。4)維護窗口之外的重啟消息。5)在備份窗口之外進行的數據備份/導出。6)日志數據刪除。7)系統或者應用程序日志記錄終止。8)系統或者應用程序記錄配置的任何變更。9)在過去觸發了任何行動(系統配置、調查等等)的日志消息。10)與安全策略違規明顯相關的其他日志。

構建初始基線之后，我們就開始每天審核日志。

1.5.3主要工作流程：每天日志審計

這是日志審核中非常核心的部分--將最后一天產生的日志與積累的基線想比較。

定期日志審核的頻率

PCI DSS需求10.6明確規定，“每天至少一次審核所有系統組件的日志”，假定日志審核規程每天進行。下面是日志審核執行頻率低于每天一次的理由：

• 應用程序或者系統沒有每天生成日志。如果日志記錄沒有每天添加，就沒有必要每天進行日志審核。

• 日志審核使用以批模式收集日志的日志管理系統，日志批次到達頻率低于每天一次。

• 應用程序沒有處理或者存儲信用卡數據；只因為直接連接而被列入范圍。

每天日志審核的比較方法總結如下：基本方法：

• 前所未見的日志類型(新日志消息類型)。

高級方法：

• 前所未見的日志類型(新日志消息類型)。

• 比基線中出現頻率更高的日志類型。

• 比基線中出現頻率更低的日志類型。

• 前所未見的日志類型(對于特定用戶)。

• 前所未見的日志類型(對于特殊應用程序模塊)。

• 前所未見的日志類型(在周末)。

• 前所未見的日志類型(在工作日內)。

遵循高級方法的同時，日志管理工具也可以使用其他比較算法。

在消息被標記為異常之后，我們轉入日常工作流的不同階段--從每天審核轉向調查分析。

02日志的依存性

日志記錄和通過日志管理軟件或者其他工具跟蹤此類活動，是實現IT可審核性的主要手段，因為大部分用戶和系統操作可能記錄在日志中。實現組織中的可審核性可能需要許多其他手段，但是日志是遍及各個IT領域的一個機制，甚至延伸到技術的范圍之外。如果你的IT運營不可審核，也就意味著你的業務無法審核。

如果你的企業沒有認真地對待日志，那么就可以說明你對IT可審核性并不重視，這也就是日志記錄成為一種完善的依從性技術，許多法規和法律以及最佳實踐框架都對此作出強制性要求的原因。

總體來說，法規在日志數據上有如下的某些或者全部要求，

• 有充足的日志記錄，各種法規在“充足”的含義上有顯著的不同。有些法規只規定企業有審計日志記錄。

• 集中收集日志，有些法規要求收集日志并集中存儲和分析。

• 審核日志數據，許多法規中最困難的部分是強制日志審核。例如，PCI DSS要求每天審核來自范圍內系統的日志。很明顯，這并不意味著每個單獨的日志條目都必須人工閱讀。

• 留存日志一段時間。法規要求各種不同的日志保存期--從幾個月到幾年。有些法規只要求企業必須有日志保存策略，而沒有規定具體的數字。

• 監控安全性。有些法規規定了網絡和WEB警報的審核，在必要時可以部署一個事故響應過程。其他任務包括日志數據保護、時間同步等。

“法規只強制要求擁有日志數據”是常見的錯誤概念。

下面是幾種流行的法規，看看他們與日志記錄、日志分析和日志管理的相關性。

2.1 PCI DSS

在2.日志管理規程中提到了PCI DSS與日志，這里不再做羅列。

總體上，日志記錄和監控不只限于需求10，而是遍及PCI DSS的全部12個需求；在PCI DSS中強制日志記錄和監控的關鍵領域是需求10，和需求11及需求12的一些部分。

2.2 ISO 2700X系列

ISO 27001屬于ISO 27000標準家族。它是由國際標準化組織(ISO)發布的一個信息安全管理系統(ISMS)標準，全名為ISO/IEC 27001:2500“信息技術--安全技術--信息安全管理系統--需求”。該規范可以在http://www.27000.org和其他位置找到。

重點放在與日志記錄和監控相關的ISO控制上。集中在“A.10.10監控”小節，其目標是：“檢測未經授權的信息處理活動。”這與ISO 27001框架的安全任務保持一致，強調安全問題的檢測，而非調查。

ISO A.10.10.1小節“審計日志記錄”有如下陳述：“應該生成記錄用戶活動、異常和信息安全事件的審計日志，并保存一定的周期，以輔助未來的調查和訪問控制監控。”這規定要擁有日志，而且在一個預算定義的時間周期(在你的日志保存策略中定義)內保存。它還簡短地強調了日志中需要記錄的事件類型，遵循本章引言中提到的傳統依從性相關日志類別。

擴展上述定義，并接入A.10.10.4小節“管理員和操作員日志”(“系統管理員和系統操作員活動應該記入日志”)和A.10.10.5“故障日志”(“故障應該記錄、分析并采取相應的行動”)中的附加需求，我們可以總結ISO環境中所有系統需求記錄的事件類型。

所有這些事件可以提供對安全事故(如數據竊取)有用的初始證據。

在windows上，這些事件包括了從登陸到策略更改，再到應用程序更新及用戶對數據的操縱等廣泛的事件。在網絡設備上，將包含安全性和可用性問題。

對于特權用戶的監控(如“系統管理員和系統操作員活動”)應該加以特別注意。這種日志記錄實際上是在ISO計劃指導下創建的最重要的日志，因為它們可以作為全能IT管理員的關鍵可審核性手段。但是，為了用于這樣的目的，日志必須通過日志管理解決方案，脫離這些管理員的控制。

上述幾個小節還包含了日志保存和調查的其他需求。和PCI DSS不同，ISO沒有明確規定1年的日志保存期，只是提到日志保存，要求有單獨的策略定義日志保存期。實際上，保護安全相關日志1年是常見的行業慣例。建議所有企業在整個環境中對物理和虛擬組件都實施這樣的日志保存。

還要注意10.10.5小節中的“采取行動”需求。這提示我們不僅要收集日志，還要定義監控、調查和異常跟蹤的策略及規程。

ISO 27002提供實踐中實施ISO系列標準的其他有用細節。例如，10.10.1“審計日志記錄”附件的原則規定，“特權的使用”和“系統工具及應用程序的使用”必須記入日志。

下一小節A.10.10.2“監控系統使用”中明確強制規定“應該建立監控信息處理設施使用情況的規程，活動監控的結果定期進行審核。”這要求一個日志記錄策略和監控的操作規程。ISO還暗示著這些策略和規程的持續審核，例如，對于ISO項目范圍內的系統和應用程序，操作規程必須包含定期或者實時日志審核工作流。這種審核由應用程序管理員或者安全管理員用自動化工具或者人工進行(但是由于收集和保存的日志體積，后者在較大的環境中不可能進行)。

ISO 27002建議“單獨設施的監控級別應該通過風險評估確定”，這為安全監控活動提供了合理的基礎，不會缺乏或者過度控制。“I/O設備連接/斷開”明確地成為監控目標。

總體來說，這些關鍵控制要求創建一個日志記錄策略，定義日志記錄、日志收集和保存以及審核和分析--還可能有實時警報。

ISO 27001包含了加固日志，使之免遭未授權修改和查看的主題。A.10.10.3小節“日志信息保護”中規定“日志記錄設施和日志信息應該得到保護，免遭篡改和未授權訪問。”注意日志保護的兩個重點：訪問控制(保持日志機密性)和完整性保護(保持日志完整性)。大部分現代日志管理和SIEM系統提供嚴格的基于角色訪問控制，按照“按需了解”的原則，將法定操作權限在授權人員上。在此基礎上，系統還采用加密機制進行完整性檢查，檢測任何可能的日志更改。作為最后手段，日志可以寫入“一次性寫入”媒介(如DVD)或者網絡備份存檔。雖然沒有明確提及，但是這種控制暗示，惡意的內部人員不應該能夠使用日志，進一步實現其邪惡的目的--日志安全措施應該對外部攻擊者和惡意(以及不謹慎的)內部人員都有效。

除此之外，企業必須監控“日志文件媒體的存儲容量超限，造成記錄事件的失敗或者覆蓋過去的日志記錄”。這種日志數據的意外丟失是不能容忍的。

最后，ISO A.10.10.6小節“時鐘同步”規定“組織或者安全域內所有相關信息處理系統始終應該與公認的準確時間源同步。”

和PCI DSS一樣，日志定時對于安全監控、取證和故障排除都很重要。確保所有收集和分析的日志有正確的時間戳，且保持相關的時區信息，是行業的最佳實踐。為日志使用NTP或者其他可靠定時機制，以便保持事件的正確時序以及絕對時間。

2.3 HIPAA

有兩個主要的法律來規范醫療行業的數據安全：HIPAA(健康保險流通責任法)和HITECH(健康信息技術對經濟和臨床健康)。后者是在2009年撰寫的，并作為HIPAA的補充。它增加了對違規行為的罰款和處罰。一般來說，如果一個APP符合HIPAA，它也將符合HITECH法規。

1996年的HIPAA概述了健康信息的相關安全和隱私標準，包括電子和物理信息。該法案的主要使命是“改進健康保險覆蓋團體和個人市場的便利性和持續性，和健康保險和保健服務中的浪費、欺詐和違規使用做斗爭”

特別是，該法的第2條“避免保健欺詐和違規；管理簡化；醫療責任改革”包含安全規則(2.3節)和隱私規則(2.1節)

和PCI DSS不同,HIPAA本身沒有涉及安全控制級別和所采用的技術，這要求HIPAA所影響的組織，也稱為“涵蓋實體”，遵循法規的精神和非其文字。還要注意的一點是，接受支付卡的保險公司和許多醫院要同時遵守HIPAA和PCI DSS。可以理解，不同組織中，實用性的范圍可能不同，因為支付處理系統不應該保存患者的健康信息，反之亦然。然而，考慮符合兩種法規的技術和管理控制是謹慎的做法，在短期和長期來說都能夠節約金錢。

HIPAA需求廣泛適用于日志記錄、日志審核和安全監控：

164.308小節“登錄監控”要求監控記錄患者信息的系統的登錄和訪問。這一需求適用于失敗和成功的“登錄企圖”。

164.312小節“審計控制”廣泛涵蓋了審計日志記錄和處理敏感健康信息的系統上的其他審計跟蹤。這條需求隱含了這些審計日志的審核。

164.308小節“信息系統活動審核”規定了各種IT活動記錄的審核，如日志、系統利用率報告、事故報告和其他安全相關活動的指示。

上面需求說明，和PCI DSS相比，HIPAA中的日志記錄和監控要求本身不能真正地幫助公司回答部署和運營日志記錄和日志管理時所需回答的關鍵問題--從技術和策略/規程的角度看都是如此。

特別是對于下面的問題都沒有明確的回答：

• “審計控制”應該記錄哪些信息？哪些活動和事件？每個活動或者事件的哪些細節？

• 日志記錄是否應該集中收集

• 日志應該保存多久

• 應該審核哪些特殊“活動”？審核的頻率如何？

• 應該如何執行安全監控和“登錄監控”？

• 如何保護審計記錄？

模糊的原則不能幫助企業積極的進行日志記錄和日志審核。除了上述問題之外，還有一個問題不清晰：這些控制適用于處理敏感健康數據的實際應用，還是適用于底層平臺？

幸運的是，NIST SP800-66中介紹了HIPSS安全規則實施的附加細節。NIST SP800-66提供了加固受保護的電子健康信息的詳細日志管理需求的指南。

NIST SP800-66的4.1小節描述了信息系統活動定期審核的需求，例如審計日志、信息和系統訪問報告以及安全事故跟蹤報告。這一小節提出問題而不是提供答案。

4.15小節試圖提供“審計控制”的附加指導。雖然力求提供方法和實施者需要詢問的問題，如“監控哪些活動？”和“審計日志應該包含哪些內容？”但是這一文檔并沒有真正解決關鍵的實施問題，換言之，它沒有告訴涵蓋實體必須怎么做才能實現依從性。

而且，4.22小節指出，操作和活動文檔必須留存至少6年，并將安全活動記錄(如日志)是否被視作“文檔”的討論留給實施者。

推薦的策略建議，公司從信息安全活動審核策略和過程入手，使用NIST SP800-66中提出的問題，人們可以規劃這些策略的范圍：需求實用性、記錄的活動和記錄細節、審核規程、異常監控過程等。下面的內容引自NIST SP800-66：

• 誰負責總體過程和結果？

• 審核進行的頻率多高？

• 審核結果分析的頻率多高？

• 組織對員工違規有何約束政策？

• 審核信息保存在哪里(例如單獨的服務器)？

• 接下來，企業必須真正地為日志記錄和日志審核實施上述過程。這些細節可以借鑒對應的PCI DSS原則。

日志記錄和監管依從性聯系緊密，在未來仍然是如此。盡管日志有很多挑戰，但是日志記錄仍然是IT可審核性的主要手段，因為大部分用戶和系統操作可能在日志中記錄。這也就是日志記錄成為完善的依從性技術，被許多法規和法律所強制的原因。

往期精彩文章：

【資訊】程序猿的憤怒？有史以來 GitHub Star 數上漲最快的一個項目誕生

【干貨】日志管理與分析(一)——日志收集及來源

【贈書】滲透實戰指南——《sqlmap從入門到精通》

GitHub回應突然斷供：身在美國不由己，無權提前通知預警

2019年上半年Web應用安全報告

網絡安全學習方法論之體系的重要性

【熱點】安全群炸了！！！《親愛的，熱愛的》竟用三行代碼搞定服務器攻擊

別不信，垃圾分類，正在曝光你的隱私

關注脈搏，有更多安全資訊及技術性文章在等你！

總結

以上是生活随笔為你收集整理的tp5记录用户的操作日志_【干货】日志管理与分析（四）日志管理规程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。