接《日志管理与分析（三）--对日志系统的攻击》，如果你的企业没有认真地对待日志，那么就可以说明你的企业对IT可审核性并不重视，这也就是日志记录成为一种完善的依从性技术，许多法规和法律以及最佳实践框架都对此作出强制性要求的原因。日志管理与分析（四）重点在于根据PCI DSS以及ISO27001标准的日志的管理规程。

01

日志管理规程

日志记录和管理的目标本质上是为你提供环境中的态势感知（SA），这样你就可以在网络中发生某些情况时进行评估、响应，并在必要时升级。SA部分通过启用日志数据收集、分析和保存来实现。

企业很可能因为如下的某些原因而实施日志记录：

1. 你想要保护公司的资产（知识产权和财务数据等）。

2. 你所处行业（银行、医疗、信用卡处理等）要求监管依从性，确保你能够对抗外部和内部威胁、数据丢失等。

3. 你就是希望记录所有日志。

就第二种原因，许多法规不仅从过程和规程的角度规定你必须做的事，还要求你能够证明自己真的遵循和维护你的策略和规程。这可能意味着从提供最新的网络系统访问权限文档，到制作备份文档的报告的一切事情。

下面以支付卡行业（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.2

10.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. 日志审核方法、模式和任务。

2. 异常调查和分析。

3. 规程和管理报告的验证。

这些规程可以使用自动化的日志管理工具，当这些工具不可用或者不兼容应用程序生成的日志格式时，也可以人工进行。

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可审核性的主要手段，因为大部分用户和系统操作可能在日志中记录。这也就是日志记录成为完善的依从性技术，被许多法规和法律所强制的原因。