安全规范（Regulations）里通常要求对日志数据进行收集、存储，而且还要求对这样大规模的数据进行审核、并作相应处理。过去，你的系统管理员可能经常通过分析日志文件来追踪一些设备上出现的问题，好让应急响应团队能及时发现可疑破坏或严重事故的关键所在。但是PCI、HIPPA、GLBA、SOX以及其它一些规范戏剧性地改变了这一惯例。现在，不管是财富500强企业，还是小型零售连锁店，还是当地的小医院，日志管理都已经变成一了项巨大的挑战。

　　日志自动管理产品 （以及管理服务）可以稍微帮你缓解一下这个挑战。让我们看看为何日志管理会变得这么困难，这些工具又是如何帮助我们减轻日志管理的负担。
 
　　概览

　　许多规范里面都提出并/或实现了日志管理要求。一个明确的规划，能帮助你全面地达到这些规范要求。概括起来，以下这一些核心的要求是所有规范都需要的.

　　采集和保存。不同的规范对保留的具体年限有不同要求，一般来说，至少要保留一年以上，长的则达到7年。日志的记录范围不仅仅是路由器、交换机、防火墙和入侵检测系统这些网络设备和安全设备， 数据库以及其它一些规范内要求的应用程序也必须有日志记录。
 
　　审计追踪。日志记录必须被设置到适当的级别，这样管理员和安全分析员才可以追踪某人作了哪些操作，来自或者去往哪个系统，当然，还要能答得上审计员的问题。
 
　　监测。你不能只是收集，储存日志，过后就把它扔在一旁。你必须监测日志，一般来说，至少每天都得监测一次，并且要向审计员显示你确实一直在这样做。

　　除了对那些一目了然的网络和安全设备日志进行核查，最重要的是要从中监测用户的行为。确保你能从日志文件里看出来哪个用户获取过哪些资源。
 
　　SystemExperts的副总裁Richard Mackey说：“通常人们考虑的只是用户在某个时刻访问了某一给定信息，但是如果我们要对认证和访问进行管理的话，我们还得知道许多附加信息，这只有通过完善的日志才能获得。”
 
　　补救。所有这些规范的宗旨就是你所要做的是解决安全问题，而不是只记录它们。不管是防火墙配置错误、防病毒升级还是用户的不当操作，都应该要能从你的日志里反映出来。
 
　　这意味着它是达到其它方面要求的基石。
 
　　Matt White是一家大型零售商的信息安全工程师，他们公司所采用的产品是SenSage。他表示：“我们对日志管理系统提出的要求各种各样，非常杂乱。有时候我们需要查看境外用户的访问量、有时候要知道保存有持卡人信息的数据库当前正在执行哪条select语句，有时又需要它提供基于已知认证用户列表实现的异常警告，也就是说有哪些不该访问的人访问了。我们想把一个用户对应的服务帐户和系统帐户区分开来，并分别进行审计。“从而形成集成的/链式的监管体系。你还需要证明这些日志本身以及它们所含的信息没有被改动过，也没有被不正当人员查看或接触过。
 
　　突出的难题

　　日志管理不是一个简单的任务，也不会是一个便宜的工程。它没有捷径可走，需要投入大量人力、财力，还需要有良好的策略、基础设施、实施以及持续的执行力。如果你达不到这些，审计员就该打电话找你麻烦了。在日志管理里存在一些障碍，使得它非常难以实施。再加上吞并或收购这些变化，以及新业务计划、新系统、新程序的加入，这些问题会变得加倍复杂。
 
　　无所不包地记录日志。你面临有两种选择。你可以在各自独立的系统里采集并分析日志，或者你也可以把日志集中到一个地方。很明显，把日志集中到一个地方存储对于开发提供了很大的便利，但是要做到这一点并不容易。你可以设立一台syslog服务器，它可以集中处理大量的日志（但并不是全部）。不断地从不同系统里自动采集日志是一项很有挑战性的任务。
 
　　拖慢系统。把日志调到规范里要求的级别会让你的网络和设备明显变慢。所以先得做好准备，在这些基础设施上投放资金以满足需求。你准备好了为日志记录牺牲防火墙、代理以及生产服务器的性能了吗？
 
　　各种日志格式的混杂。许多记录是以标准的syslog格式存在的。这一点让人高兴。但是Windows事件日志却不是。还有一些非常流行的安全设备、工具、应用程序以及数据库程序也不是标准格式。在你打算自己开发程序前就应该先考虑这一问题。试想一下为每种格式都开发一个解析器，并用正则表达式来分别查询，或者是把它们一股脑全放到关系型数据库里去再用SQL语句来查询你想要的。
 
　　White认为：“有一个很要命的问题是我们的日志来源各种各样，我们的日志来自Windows，Solaris，Linux这些不同的操作系统，还来自入侵检测系统（IDS）、防火墙、远端拨入验证系统(RADIUS)等网络组件，有时候我们还需要对Oracle， SQL Server这些不同的数据库做日志，此外还需要对HP 3000，IIS，Apache，MS ISA这些各种各样的服务器记录代理日志。 而且这些种类还在不断增加，花样越来越繁多。这会让你的开发根本看不到头。”
 
　　以PB为单位计的日志容量。这些系统所产生的日志体积是很吓人的。即使是一个比较小的团体也能产生数个TB的需要长期保存的数据。并且你还需要一些合适的方法来检索它。
 
　　“管理这样庞大的数据是最大的问题，“White说。“对于大型零售商我们配备了一个较小的IT团队，并且还把很多开发任务外包了出去。”
 
　　一切还未结束。就算你已经克服了日志采集和存储的问题，你的业务、网络以及安全人员什么时候会抽点空整理一下日志并从中监测相关事件呢？
 
　　Mackey表示：”我们发现大部分机构都在采集信息这一环上做得很不错，但是由于日志文件分散、复杂而且极其庞大，所以他们根本没有好好去分析日志。“
 
　　理解这一切。你如何才能克服日志的庞大体积、不同格式、不同系统，从里面获得你想要的信息？你手下可能有人能理解某种系统的语言和潜在问题，这种人才能从破译出日志文件里隐藏的问题。但是如果你想要查询整个系统的运行情况的话，那几乎是不可能的。
 
　　报告能力。单个的系统同样有可能无法为内部调查和审计提供强大的报告能力。并且如果不能对它作恰当的分析的话，你就没法获得涵盖整个系统和应用程序的有用报告了。
 
　　这样做安全吗？在这上面有一个很重要的问题。你的确需要加密这些可能包含敏感信息的日志数据。这意味你得考虑加密操作，这就样就又带来了让人头痛的新问题。你必须在传输和其它时候都确保数据的完整性，最后你还得提供对这些数据的适当的访问权限，同时还得做好隔离。这在集中采集日志的系统里是没有什么好方法可以办到的。
 
　　注意：日志可能包含敏感数据，如信用卡号码。这通常应归结于应用程序的安全漏洞，它在你调高日志记录级别前通常并不会显露出来。
 
　　该记录多少信息呢？如何对每个系统和应用程序设定一个恰当的日志记录级别是一个不太简单的问题。如果级别设得太低了，你就没法获得足够的信息。如果太高了 ，又会给你本来就很吃紧的性能和存储增加不必的负担。
 
　　有没有办法协调好这一切？把所有这些因素都协调好真不是件容易的事情，尤其是对于那些庞大、复杂、分散的企业。Mackey说：“最难的问题就是让人们团结一致。确保各个应用程序的负责部门把它们的日志数据分享出来。”
 
　　扫除障碍

　　日志自动管理工具改变了这一情况。
 
　　Mackay说：“如果没有日志自动管理工具，我们几乎不可能达到规范的要求”。
 
　　虽然日志管理产品和服务并不完全是即插即用，但它们能扫清最紧迫的障碍。
 
　　集中化。通过内置的日志采集器，日志管理产品能很好地处理与每个系统、数据库和应用程序之间的关系。集中日志使得存储问题变得容易解决，同时还可以保存日志供报告、审计用。相比为每个单独的系统增加空间，你可以更容易地掌控存储需求，还可以更好地控制在各个部门或业务单位的花费和回充(charge-back)。

　　标准化/相关化。日志管理系统能解析多种日志格式，并能把它们标准化成一种通用格式，那样你就能通过统一的语句查询整个系统里的各种日志了。
 
　　分析。一旦你把日志集中存储起来并有通用的办法在整个系统和应用程序里查询日志之后，定期监测就变得可行了。分析师和管理员可以使用中央控制台审查日志来检查安全性，规范性以及操作上的问题。这些工具通常都内置有能促进分析的组件，并且通常还包含规范兼容包(compliance packages)以实现日志数据与特定标准要求之间的映射。这使得事件响应和取证变得简单多了。当然，人工干预也还是少不了的。
 
　　“按照它的自动化程度，它还没有达到完全不需要人参与的地步，”Mackey表示。”日志管理工具使得那些理解日志以及各个组件的人可以查看并理解日志。但它们并不能自动识别所有突发的事件。”

　　事件管理。虽然它们并不等同于安全信息和事件管理（security information/event management ）工具，但是日志管理产品还是通常提供了一些自动报警功能，它是基于已知的安全问题和用户定义规则作出判断的。有些机构买不起SIEM时就经常把它们当作“轻量级SIEM”来用，它们有时也可以用来与同一生产商或第三方生产的SIEM工具集成使用。
 
　　附加值。日志管理可以为你节省时间和成本，甚至还可以提供高于标准的安全性。很多机构都通过审查日志来解决网络及其它IT问题。如果你可以把解决问题的时间从比如10分钟压缩到2分钟，那就体现出了投资价值。
 
　　赛门铁克的高级产品营销经理Todd Zambrovitz说：“如果你能够做出不同粒度的报告并且确保报告的一致性，那就有一个案例论证(business case justification)等着你。”

　　“如果你能用三分之一的时间完成同样的任务，或是用一半的时间生成信息，那你就成了一桩内部案例(internal business case)的典型”。
 
　　Eric Laszlo是Redcats USA的高级管理信息技术管理人员，他们公司是LogRhythm的客户。他介绍说：“我们会记录一些非PCI导向的信息。”网络段(network segment)和信用卡或订单输入没有什么关系，我们就在交换机或路由器上利用它，并把服务器的那一套架构更多地留来作故障排除 。“
 
　　脚下留神

　　日志管理使得我们的工作变得简单，但并非所有时候都这么简单。想要成功地部署它必须得先仔细进行规划并对你的企业有透彻的了解。还要对今后的业务增长有一个预判。
 
　　步步为赢。先从那些最关键的部分开始，或者，如果有哪个部分厂商已经为你处理得特别好了，就从那个部分开始。SystemExperts的Mackey建议先从周边设备开始。例如为了达到PCI标准，先安装并配置好防火墙，保护持卡人数据。不过，始终记着，这还仅仅是个开始。
 
　　Matt White也是从为他所在的零售公司做一个重要的客户信息数据库开始起步的，通过在一个项目上的数个月的开发，如果他再从头做一遍的话，他肯定可以做得大不一样了。
 
　　“我们最开始的方法是根据应用程序来部署。我本来应该按照操作系统所采用的技术来部署：Windows安全事件记录、Unix 的syslog。这样就可以事半功倍。解决了操作系统之后，下一步就是确定数据库的日志记录等级，并在此基础上提高到你所需要的应用程序级别。”
 
　　协调。“和公司里的所有其它活动一样，你得始终把技术上、组织上、成本上的诸多因素考虑再三，”Mackey说。“小的机构可以快速作出决策，但是大公司就得花上好些时间来协调各种行动，包括日志来源、存取权限、报告路线、分配存储空间以及分配预算。”

　　标准化。选择一个产品作为你们的参照标准，并围绕它开发与之一致的策略。
 
　　获得帮助。你的团队里可能没有这方面的专家，至少在最初部署时是不会有的。大型咨询公司可以帮助你起步。但Mackey警告说，不要迷信这些服务。评估你的真正需求。先按规章里的标准起步，确定你需要采集哪些日志，日志的审核频率需要多高，需要什么样的报告，以及审计员需要哪些信息。为你的系统需求设立一个底线。
 
　　确定哪些系统是相关的，并控制那些系统生成的日志数据以及访问那些系统的网络设备。