日志管理与分析（六）–日志的审核与响应

日志管理与分析（六）–日志的审核与响应
2019-08-27 09:40:35 Author: www.secpulse.com(查看原文) 阅读量:194 收藏

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

健壮的日志分析系统，依赖于所分析日志数据的完整性。该系统必须对修改和删除数据的企图有适应能力，在此基础上，它还必须对日志数据的访问进行细粒度的控制。若日志数据作为法律上的证据，说明日志数据完整性的能力，对于该数据是否被视为可接受的证据，有着很大的影响。https://www.secpulse.com/archives/110454.html。

无论是对日志系统的分析还是为了满足依从性，日志审核都是进入调查过程的起点，而且能够为你进行满足企业自身、监管或者其他强制要求的活动提供保证。日志记录策略、审核、响应、升级规程、用日志管理工具构建一个初始基线以及每天的日志审计。

接以上内容下面对日志审核分析进行介绍。

1. 异常调查与分析

不匹配正常配置的消息被标记为“异常”。需要注意的是，异常不等同于安全事故，但可能是安全事故发生的早期指示。

在这一阶段，有了一条正常运营之外的日志消息。该如何确定他是否严重，如何确定其对安全和PCI依从性状态的影响呢。

1.1 初始调查

图展示了对每个“异常”消息使用的调查过程（“初始调查”）的概要情况。

确切的说，这展示了一个使用日志调查检查列表的过程，下面详细介绍这个列表：

1）查看同一时间的日志消息：这一技术围绕时间范围--涉及所调查日志的消息。大部分日志管理产品能够审核或者搜索特定时间范围内的所有日志。例如：

a）首先，查看“可疑日志”前后1分钟触发的其他日志。

b）其次，查看“可疑日志”前后10分钟触发的其他日志。

c）最后，查看“可疑日志”前后1小时触发的其他日志。

2）查看来自同一用户的其他消息：包含搜索同一用户的活动生成的其他日志消息。常常发生这种情况，用户活动的特定日志事件只能在同一用户其他活动的上下文中解读。大部分日志管理产品允许你搜索特定时间范围内的特定用户。

3）查看其他系统上的同类消息：这种方法包括搜索其他同类日志信息，但是在不同的系统上进行，以确定其影响。例如WAF以及IDS会同时记录该用户告警行为，了解其他系统上何时产生相同的消息，可以得到日志消息的线索。

4）查看来自同一源的消息（如果适用的话）：这种方法需要审核来自网络相关源地址的其他日志消息。

5）查看来自同一应用程序模块的消息（如果适用的话）：这种方法需要审核来自同一个应用程序模块或者组件的所有日志消息。同一时间范围的其他消息可能很重要，但是审核来自相同组件的最近日志一般有助于揭示真实的情况。

在某种情况下，上述检查列表可能没有作用。也就是说，异常日志消息对安全和PCI依从性的影响是未知的。在这种情况下，我们必须从其他系统获得信息，例如文件完整性监控（FIM）、补丁管理（PM）、变更管理（CM）和其他系统。

1.2 外部信息源调查

调查日志规程可以扩展，覆盖企业的其他可用信息源。下图展示了在调查中使用外部信息源所遵守的规程。

这一规程的主要思路是根据异常日志消息的类型来识别并查询信息源，然后识别其影响和必要的行动（如果有的话）。

该规程粗略地确定日志消息的类型，然后查询相关的信息源。在某些情况下，这种日志消息确实是严重问题的征兆，会触发事故响应过程。

但是，有时候初步分析和外部系统查询都不能得到结果，这样的“异常”日志很罕见。在这种情况下，触发协作工作流。

1.3 升级到其他规程

本规程可以利用组织中其他人的知识，这些人可能了解“异常”情况。调查和升级过程如图。

这一规程的主要思路是找出可能了解应用程序中发生的事件的合适人员，并与之面谈，确定事件的影响和必要的行动。

最后的资源是咨询应用程序供应商，这种信息请求通常很费时，甚至很昂贵，所以应该审慎使用。

2. 事故响应和升级

迄今为止介绍的许多工作流依赖事故响应（IR）和升级。但是，什么是事故响应和升级？

在日志管理和IT的一般概念中，升级规程用于确定何时应该升级所发生的情况。

图展示了SANS定义的IR过程。

准备阶段包括事故之前必须完成的任务：从组建团队、训练人员、收集和构建工具，到部署监控和创建过程及事故规程。这也是你开发升级规程/策略的时机。这一策略是关于合适的个人、团体之间的沟通。

识别阶段从事故的征兆被发现开始。这不仅是IDS警报有关（实际上这种情况也不太多）。例如，持续的CPU利用、系统重启和维护窗口之外的配置更改等，都是说明发生了某些值得进一步注意的事件的信号。

控制阶段对于在文档中记录发生的情况、隔离受影响系统（甚至区域）以及进行著名的“拔线”操作（也就是断开或者关闭系统）来说很重要。在这一阶段，我们还试图审核其他系统可能受到的影响和损害，评估破坏范围。

根除阶段中，我们评估可用备份，准备恢复或者重建系统，为回到正常状态做准备。这一阶段还要规划网络的更改。

恢复阶段是一切回到正常的阶段。在此阶段要起用额外的日志记录和监控。

在跟踪阶段，你讨论和记录得到的教训，向管理层报告事故，并规划未来事故处理中的改进。这一阶段也常称为后续阶段。

3. 日志审核的验证

日志审核最后的关键部分是确保有足够的证据，证明这一过程被真正严格地实施。好消息是，可以使用日志记录和日志审核过程管理报告中的相同数据。

首先，常见的错误概念是用实际的日志来提供这种证明。这并不正确：“有日志”和“审核了日志”是完全不同的概念，有时候，需要对安全和依从性进行多年的成熟化，才能分辨这两者。

只需要记住，在PCI DSS依从性验证中，我们需要证明多个主要的部分。下面是需要组合的所有依从性证据的总列表。和其他小节不同，在此我们将包含日志记录的证据，而不只是日志审核的证据，因为后者依赖于前者：

·日志记录的存在和充足性。

·日志审核过程的存在及其实施。

·异常处理过程及其实施。

现在，我们可以围绕这些领域组织证据，然后构建过程来收集这些证据。

3.1 日志记录的证据

第一类证据是日志记录存在和充足性的证据。这一部分是三者中最容易证明的。

下面的项目可以作为日志记录的证据：

1）有文档证明的日志记录策略，包括记录的事件和每个事件记录的细节。

2）实施上述策略的系统/应用程序配置文件。

3）上述应用程序生成的，符合策略的日志。

3.2 日志审核的证据

第二类：日志审核过程及其实施的证明。这一部分比前一部分更难证明。

下面是可以作为日志审核证据的项目：

1)有文档证明的日志记录策略，涵盖日志审核。

2)有文档证明的操作规程，详细说明日志审核的步骤。

3)相关人员执行的日志审核任务记录（有些日志管理产品创建一个审核报告和事件的审计记录；这种审计跟踪应该涵盖），这个项目可以视为“日志审核日志”

4)调查的异常情况记录也间接地证明日志审核的进行。

3.3 异常处理的证据

第三类：异常处理的过程及其实施的证据。这一部分是目前为止最难以证明的。

下面的项目可以作为日志异常处理的证据：

1）有文档证明的日志记录策略，涵盖异常及其处理。

2）有文档证明的操作规程，详细说明日志审核中找到的异常的调查步骤。

3）所有异常调查及所采取的行动的日志（“日志薄”）

上述的特征应该能为组织认真遵循PCI DSS原则提供充足的证据。我们将重点放在这一证据额产生的。

PCI依从性日志记录子域	依从性证据	如何获取证据
日志记录存在和充足的证据	有文档证明的日志记录策略	如果不存在策略，则创建
日志记录存在和充足的证据	系统/应用程序配置文件	部署之后，保存配置文件作为主拷贝
日志记录存在和充足的证据	上述应用程序生成的日志	收集日志样本，保存为依从性的证据
日志审核的证据	有文档证明的日志记录策略	如果不存在策略，则创建
日志审核的证据	有文档证明的操作规程	根据本章的工作流和规程创建
日志审核的证据	执行的日志审核任务记录	使用工具或者创建一个“日志薄”
日志审核的证据	所调查的异常情况的记录	创建一个调查“日志薄”
异常处理的证据	有文档证明的日志记录策略	如果不存在策略，则创建
异常处理的证据	有文档证明的操作规程	根据本章的工作流和规程创建
日志审核的证据	所调查的所有异常情况的记录	创建一个调查“日志薄”或者知识库

上述列表中关键的项目是“日志薄”，它用于记录异常的跟踪和调查，从而创建了PCI DSS需求依从性的有力证据。日志薄甚至可以成长为更加高级的形式--包含过去所有异常分析案例的调查“知识库”。

4. 日志薄--异常调查的证据

日志薄用于记录日常审核期间标记的异常的分析和调查相关的所有情况。虽然事故处理过程中使用相同的日志薄方法，但在这里我们将其当做依从性的证据。

日志薄应该记录所有涉及的系统，所有面谈过的人，采取的所有行动及其理由，得到的结果，使用的工具和命令（及其结果）等。

4.1 日志薄推荐格式

日志薄条目应该包含如下内容：

1）日志薄条目开始的日期/时间/时区。

2）启动日志薄条目的人的姓名和角色。

3）启动该条目的理由：记录异常（从日志聚合工具或者原始日志文件中复制而来）、确保复制整个日志，尤其是时间戳（可能不同于记录时间）和来源系统（什么/何时/何地，等等）。

4）详细说明日志为什么不正常，为什么进行这项分析。

5）产生异常日志记录或者与日志异常相关的系统的相关情况。

a）主机名

b）操作系统

c）应用程序名

d）IP地址

e）位置

f）所有权

g）系统关键性

h）在补丁管理、变更管理、FIM等过程中。

6）产生该日志的活动的用户相关信息。

7）遵循的调查规程、使用的工具、屏幕截图等。

8）采取的调查行动。

9）日志分析过程中接触的人。

10）在分析过程中确定的影响

11）行动和缓解措施的建议

5. PCI依从性证据包

确立PCI DSS日志记录需求的3个关键部分：

·日志记录的存在和充足性

·日志审核

·异常处理

可以在评估之前准备证据包，但是以持续的方式维护它要容易很多。例如，保留如下内容的纸质或者电子拷贝：

1）覆盖所有PCI DSS范围内系统的日志记录策略。

2）日志记录和日志审核规程。

3）日志源列表——来自范围内环境的所有系统及其组件（应用程序）。

4）表明日志记录根据策略配置的配置文件样本（例如Unix的/etc/syslog.conf，Windows审计策略屏幕截图等）。

5）来自范围内的系统，说明日志按照策略生成并满足PCI DSS日志记录需求的日志样本。

6）从日志管理工具导出或者打印、说明日志审核进行的报告。

7）上面定义的最新的日志薄。

这样就能始终确定依从性状态，提供持续的依从性。

6. 管理报告

除了依从性证据之外，可以利用验证活动向高管报告日志管理计划、过程和规程的成功。

PCI依从性证据包的积累作为PCI DSS依从性的数据也可以用于管理报告。具体地说，可以生成如下报告：

·日志记录的存在和充实性：

·这一部分没有实用的管理报告。

·日志审核过程的存在及其实施：

·日志策略和规程变更。

·处于日志审核之中的应用程序。

·审核的日志条目

·异常处理过程及其实施：

·按照分类、分析人员姓名等列出的已处理日志异常。

·升级到事故响应的异常。

·由于及时升级或者事故预防而降低的风险。

·由于及时升级或者事故预防而节约的资源。

·由于日志审核带来的应用程序性能改进。

·其他日志管理计划报告：

·总体依从性准备。

最后，我们来总结组织应该执行的，与日志审核相关的所有运营任务。

7. 定期运营任务

下面包含于日志记录和日志审核相关的运营任务。

7.1 每日任务

下表包含每日任务，负责执行它们的角色，以及它们的执行中创建的记录或者证据。

每日任务

任务	责任方	证据
按照每日日志审核规程的描述，审核前一天生成的各类日志	安全管理员、安全分析人员（经过授权的）应用程序管理员	日志管理工具上运行的报告记录
按照调查规程中的说明，调查异常日志条目	安全管理员、安全分析人员（经过授权的）应用程序管理员	调查事件所记录的日志薄条目
采取必要的行动缓解、补救或者协调调查的结果	安全管理员、安全分析人员（经过授权的）应用程序管理员、其他各方	调查事件和采取的行动所记录的日志薄条目
验证所有范围内的应用程序都进行日志记录	应用程序管理员	创建一个数据表记录这些活动，供以后评估
如果日志记录被禁用或者停止，则启用之	应用程序管理员	创建一个数据表记录这些活动，供以后评估

7.2 每周任务

包含每周任务、负责执行它们的角色，以及它们的执行中创建的记录或者证据。

每周任务

任务	责任方	证据
按照每天日志审核规程的描述，审核前一天非关键应用程序生成的各类日志，按照调查规程中的说明，调查异常日志条目	安全管理员、安全分析人员（经过授权的）应用程序管理员	日志管理工具上运行的报告记录 QSA批准较低频率日志审核的记录，以及批准的理由
按照调查规程中的说明，调查异常日志条目	安全管理员、安全分析人员（经过授权的）应用程序管理员	调查事件所记录的日志薄条目
采取必要的行动缓解、补救或者协调调查的结果	安全管理员、安全分析人员（经过授权的）应用程序管理员、其他各方	调查事件和采取的行动所记录的日志薄条目

7.3 每月任务

包含每月任务、负责执行它们的角色，以及它们的执行中创建的记录或者证据。

每周任务

任务	责任方	证据
准备关于所调查的日志条目的报告	安全分析人员、安全经理	准备好的报告（存档）
有关观察到的消息类型的报告	安全分析人员、安全经理	准备好的报告（存档）
有关观察到的新消息类型的报告	安全分析人员、安全经理	准备好的报告（存档）
按照每天日志审核规程的描述，审核前一天非关键应用程序生成的各类日志，按照调查规程中的说明，调查异常日志条目	安全管理员、安全分析人员（经过授权的）应用程序管理员	日志管理工具上运行的报告记录 QSA批准较低频率日志审核的记录，以及批准的理由
按照调查规程中的说明，调查异常日志条目	安全管理员、安全分析人员（经过授权的）应用程序管理员	调查事件所记录的日志薄条目
采取必要的行动缓解、补救或者协调调查的结果	安全管理员、安全分析人员（经过授权的）应用程序管理员、其他各方	调查事件和采取的行动所记录的日志薄条目

7.4 季度任务

包含了季度任务、负责执行它们的角色，以及它们的执行中创建的记录或者证据。

每周任务

任务	责任方	证据
验证所有PCI范围内的系统都记录日志，且审核了日志	安全分析人员、安全经理
审核每日日志审核规程	安全分析人员、安全经理
审核日志调查规程	安全分析人员、安全经理
审核收集的依从性证据	安全分析人员、安全经理
审核依从性证据收集规程	安全分析人员、安全经理