日志管理迎接法规遵从时代
来源:用户上传
作者: 杨宗良
日志管理正在成为一项“必须做的工作”。来看看美国是如何用法规规范日志管理的。
每发生一次重大的数据泄密事件(譬如英国零售商TK Maxx和美国农业部的泄密事件)或者每出台一部新的法规,安全重点似乎都要从“阻挡坏人”的传统办法转向全面的安全机制,以进一步分析IT活动。
现在,不同类型的日志正在从不同来源以惊人的速度生成,这就可以详细记录下来IT活动。如果某位满腹牢骚的员工企图窃取数据,访问了含有机密信息的数据库,日志就有可能记录下他的一举一动,那样别人只要检查日志,就能确定是谁在什么时候从事了什么活动。日志提供了线索,企业利用这些线索就能追查所有用户(不管是否不怀好意)的行踪。
由此可见,对日志进行管理会给组织带来许多好处。它们让组织意识到面临的情况,并帮助组织开展行之有效的调查,例行的日志检查及深入分析保存日志不但可以立即识别出现不久的安全事件、违反政策情况、欺诈活动以及运作问题,还有助于提供有用的信息,从而解决问题。
考虑到日志管理本身所具有的功效,收集日志数据及进行分析,通常被认为是安全行业的一条最佳实践。不过,美国的许多法规还明确要求搜集、保存、维护及检查日志,日志管理随之从“应当做的一项工作”成为“必须做的一项工作”。
尤其是FISMA、HIPAA和PCI-DSS这三项法规同时影响着事件响应流程和日志管理,因为它们既要求检查日志,还具备日志功能。
《联邦信息安全管理法案》(FISMA)
虽然许多人在抨击FISMA完全注重文档资料、而不是注重具体措施,但该法重点强调了美国每个联邦机构都要制订、记录及实施在整个组织范围的计划,以保护信息系统。
NIST SP 800-53《联邦信息系统推荐安全控制》描述了日志管理控制,包括审计记录的创建、检查、保护及保留,另外还描述了万一审计失败,应当采取的措施。
NIST 800-92《计算机安全日志管理指南》同样旨在简化遵从FISMA,它完全偏重于日志管理方面。它描述了联邦机构需要日志管理,还描述了建立及维护成功、有效的日志管理基础设施的方法,包括日志创建、分析、保存及监控。
NIST 800-92讨论了对来自不同地方,不同类别的日志进行分析的重要性,并且讨论了为参与日志管理的团队及个人明确定义具体的角色及职责的重要性。
《健康保险可携性及责任性法案》(HIPAA)
1996年出台的美国《健康保险可携性及责任性法案》概述了健康信息方面相关的安全标准。
NIST SP 800-66《实施健康保险可携性及责任性法案安全规定的介绍性资源指南》详细描述了受保护健康信息的日志管理要求。NIST 800-66的第4.1条要求定期检查信息系统的活动,譬如审计日志、访问报告及安全事件跟踪报告。
另外,第4.22条还规定了记载行动和活动的文档内容至少保留六年。
虽然要不要把日志当成文档来对待的争论还没有结束,但一些组织的确选择了日志的保存时间与其他工作文档一样长。另外,该文档的附录A鼓励组织提出与日志有关的各种问题,包括系统性能监控是不是用来实时分析系统性能日志,以便发现主动攻击之类的可用性问题。
《支付卡行业数据安全标准》(PCI-DSS)
PCI-DSS适用于处理信用卡交易的组织,它规定了要把特定的详细信息记入日志,还规定了日志检查程序,以防止保存、处理或传送信用卡数据的公司出现信用卡欺诈、黑客活动及其他相关问题。
PCI-DSS的第10项要求侧重于日志功能和日志管理方面。根据这项要求,系统所有部件的日志都必须每天检查一次; 这些日志检查对象必须包括执行安全功能的服务器,譬如入侵检测系统以及使用验证、授权和记账协议的服务器。
另外,PCI-DSS还规定: 组织必须针对日志实施文件完整性监控及变更检测软件,确保现有的日志数据在变更后会生成警报,从而确保日志的完整性。它还规定,来自监控范围内系统的日志至少要保存一年。
其他法规
另外美国还有诸多法规要求日志管理功能,但不如上述三项法规规定得明确。
譬如说,California Bill 1386(CB 1386)及即将出台的类似联邦法案规定: 一旦数据安全遭到了任何破坏,拥有或者许可他人使用计算机数据(包括个人信息)的联邦机构、个人或者公司就要把此事透露给加州居民,只要后者未经加密的个人信息被未经授权的人获得。
日志本身可以让人们跟踪IT基础设施的活动,它是评估数据泄密事件是否发生、如何发生、何时发生、在何处发生的最佳方法。因而,管理这些日志是评估哪些数据已被人访问或者被人窃取、因而评估需要通知谁的最佳方法。
法规遵从时代对日志管理带来的重大影响就是,使日志管理成为一项要求,而不是只是一项建议,而这种变化肯定有利于受这些法规约束的任何组织。
不难看出,为什么搜集及管理日志很重要,FISMA、HIPAA和PCI-DSS等重要法规明确加入了监控日志管理活动的内容,这恰恰表明了日志管理对满足更广泛的风险管理需求以及企业安全到底有多重要。(沈建苗编译)
.Net环境下三种方法管理日志
.Net提供了几个方法来更好地管理日志。
1. 添加一个新的LogSource。
什么是LogSource?其实简单地说,它就是日志的一个分类标记,例如你可以用程序一次取出所有LogSource为指定内容的日志。这样一来,只要你记得这个Source名,你就可以读取和分类管理日志了。
默认情况下,用户在直接用EventLog的静态函数写日志的时候,要指定一个LogSource,如果LogSource不存在,那么它就自动在Application下建立一个,因此,创建LogSource就这么简单了。
2. 添加一个新的Log。
什么是Log?这里的Log是指系统事件日志里的大日志分类。一般情况下,系统有Application,System和Sercuity三个日志,每个下面有不同的Soucce,这样就构成了日志系统。
用户不能独立地创建一个Log,因为.NET里没有提供任何方法来创建一个Log,只能通过函数CreateEventSource(string,string)来创建一个Sourcce,此时如果这样做:CreateEventSource("MySource","MyLog"); 就会在日志管理器里看到多了一个MyLog类,然后再这样写日志:
EventLog.WriteEntry("MySource","This is a test log.");
就可以写一条记录到MyLog分类下,这样就可以很好地管理自己的日志了。
需要说明的是如果Source已经存在,那么创建会失败。注意:不管Source的哪个Log下,只要Source的名字已经存在,那么创建都会失败。
3. 最后就是用日志实例对象来写日志。用户可以指定一个Log名和一个Source名来写日志,但要注意,必须是Log与Source匹配,否则也会出现错误。这比直接用静态方法来写日志要复杂一点点,但有更多的自由空间。
系统事件日志不好的地方就是日志只保存三个月,而且不好管理。如果可以直接管理服务器,或者就在本机上运行应该会好一些,否则就不得不自己写些代码来管理日志了。当然,如果是一些重要的日志,可以导出到其他文件中。
这样做的好处有很多:
●不必与数据库链接,效率会高一些,也不会有数据库访问失败的问题。
●不会有进程冲突问题,它是系统的日志,不管是什么应用程序都可以写日志。
●全局可用,不管在哪里都可以直接写日志,而且可读。因此可以把它当成一个消息通信平台。(杨宗良)
转载注明来源:https://www.xzbu.com/8/view-1077489.htm