合适的日志管理工具能够大幅减轻管理企业系统日志数据的负担。但是，除非组织为这个工具投入必要的时间和精力，否则再好的工具也会很快变成一个差劲的工具。Diana Kelley为大家提供了6个确保成功的日志管理最佳实践。

　　门外汉用上了工具依然是门外汉

　　如果你不准备投入时间和精力在恰当地安装、管理日志管理工具上，那么就不要把钱浪费在日志管理系统上面。日志管理系统必须进行合理的配置，以正确解析您网络中的事件和日志，这样出来的报表才具有商业和技术价值。另一个“愚蠢”的错误是不去浏览和审查告警控制台，因而错过了关键的安全事件。因此，不要犯只重视日志管理技术而不重视系统使用的错误。

　　通过预定义需求来精简RFP（请求提案）

　　创建RFP（请求提案，需求方案说明书）是一个费时的过程。而一些需求一旦被定义出来，就能在随后的RFP中复用。这在制定日志管理的需求时很常见，因为日志管理的基本需求（例如日志文件的格式，写入日志文件的数据，等等）都是一样的，可以预先定义出来。使用预定义需求的另一个好处是这确保了在精简 RFP周期的同时保持需求的一致性。

　　确定你有所需的信息

　　为了能够写出有效的关联规则，日志管理系统必须有足够的上下文数据进行分析。例如，为了确定某个特定的流量或者行为来自哪里，就需要知道源IP地址信息，这意味着日志管理系统必须先记录下IP地址信息，这样引擎才能够将其解析出来。又例如，如果要写一条日志分析规则对目标设备或者应用发生了某种行为进行告警，相关的日志数据必须先记录下那些行为才行。

　　不要局限于静态分析

　　大部分组织需要做的最后一件事是将那些没有整体分析模型的数据填写到另一张大表中，然后利用这张大表来进行事件分析。根据预期或者可接受行为的基线设定的告警不仅要通过分析大表中单条记录的特征来产生，还要通过分析一组记录集的特征来产生。不妨设想一下关键数据库的登录记录。一般会将两次登录失败的行为设定为触发告警的基线，但是如果那个数据库系统的密码策略从使用简单的字典单词变为使用8位以上非字典单词字符串，那么登录失败次数的基线可能要增大，因为用户要适应新的策略。具有智能感知能力的日志管理系统应该可以进行调节，以监测发展趋势，并为管理员提供反馈。管理员可以决定使用该趋势信息临时地改变告警阀值。

　　使用日志数据描述正在或者已经发生的事情

　　“日志是检查故障的极佳信息源”。因为大部分情况下用户判断导致故障原因的所有所需信息都能够从日志文件中找到。在危机期间，管理人员经常不得不进入被动模式，往往只能通过直觉、猜测、将不可再分的无关信息拼凑到一起等方式来判断正在或者已经发生的事情。而日志是真实发生事件的记录，日志管理系统允许管理人员针对故障信息实时地撰写和产生报表，从而真实地告诉响应小组网络中发生了什么。

　　使用范畴可以超越安全本身　　

　　日志管理系统是一个绝佳的安全设备信息收集和分析工具，不仅可以用这些信息实现安全感知，而且可以利用这些信息实现其他目标。例如，可以将这些信息用于分析（你的）十大业务关系的客户体验。许多WEB应用分析系统无法提供展示真实客户体验的细粒度视图。而设计良好的应用系统日志可以记录这些客户体验，日志管理系统可以通过这些日志来分析客户体验，从而将日志管理系统的运用领域扩展到安全分析之外。

【后记】本文已经发表在TT安全上。这里，我想在原文基础上谈谈我对这六个最佳实践的一些理解，希望有助于读者理解原文的含义。

1）日志管理是工具，不是代替人做出决策的系统。因此，再好的工具也需要人去用，工具只是提高人的效率，不取代人。日志管理（LM）或者说日志审计产品如此，安全管理产品亦是如此。

2）日志管理的很多基本需求都是相对固定的，这是日志管理（日志审计）系统的工作原理决定的。我之前已经分析了很多遍原理了（包括这里，还有这里，以及这里），不再赘述。我们事先可以定义一下自己的网络对日志管理的EPS性能要求，存储要求（时间和空间），要分析的日志种类，对查询性能和可用性的要求，等等。

3）“巧妇难为无米之炊”。日志审计的根本是日志，再好的产品，如果缺少日志，那么之前设定的分析效果就无法达到。

4）审计规则应该是动态的，根据实际环境的变化而变化。这也就意味着，大多数情况下分析规则无法写死，内置在系统中，而是根据实际情况量身定制的。可以有模板，但是很多参数要具体而定。

5）日志确实很有用，有人将它比作安全分析人员的金矿，但是要从金矿中提炼出真金（真正的安全问题），还需要日志管理工具的帮助，否则就真是大海捞针，无从下手了。

6）日志管理不仅对安全审计人员有用，还对系统性能和故障分析人员有用，甚至对业务部门的人有用。不过，那个时候的日志管理就不是一个单纯日志安全审计系统了，原理类似，但是分析目标有不同。