安全信息管理(SIM)是用于从日志文件和其他来源收集安全信息以检测和响应安全事件的技术，SIM的应用正变得越来越广泛。现在的服务器、网络设备和应用产生海量日志数据和各种类型的信息，这些海量数据可以被分析、关联和过滤，从而推动与安全、合规和应用性能相关的各种决策。虽然有很多可能的用途，但SIM解决方案必须专注，否则会被信息过载、性能问题“淹没”，变得一无是处。
为SIM设定有限目标
SIM的功能是在大量安全事件中寻找特定安全事件的“蛛丝马迹”。简单地说，SIM是在针堆里找针。这是一项艰巨的任务，然而，很多公司试图使用SIM做太多工作，使“针堆”越来越大，“找针”的工作也越来越困难。
部署SIM第一项也是最重要的部分是专注于一个目标或者一组有限的目标。SIM是用来检测入侵?用来寻找违规行为?还是专注于内部或外部攻击?对于这么多可能的用途，企业很容易失去焦点，并试图完成上述所有任务。你试图通过SIM解决的问题越多，SIM解决这些问题中的任何一个问题的效率就越低。
你应该收集哪些日志?如果你为SIM设定了特定的目标，你就可以很容易确定需要收集的数据。例如，如果你决定关注支付卡行业数据安全标准(PCI-DSS)的合规性，那么，防火墙日志将是你必须收集和分析的首要数据。PCI是为数不多的规范性法规之一，因此，有很多关于日志收集的具体指导。但其他法规并没有那么容易：例如，HIPAA要求你保护个人健康信息(PHI)，但对此你应该收集什么日志呢?
日志收集的常见错误是，安全专家在这个过程中过早地使用过滤。例如，在医疗机构，SIM被配置为仅收集失败登录尝试的日志信息。其理由是，这种日志信息可能表明有人试图入侵系统。然而，当发生数据泄露事故时，该公司发现攻击者已经成功盗用了用户密码。攻击者并没有产生失败登录日志信息，他们使用合法用户账户成功登录了系统。但这些成功登录信息并没有被收集，负责分析该泄露事故的安全专家将无法看到攻击者做了什么。
这是一个艰难的权衡：如果你不收集一些具体的细节数据，当你在数据泄漏事故后需要查看历史数据时，你将无法看到这些数据。但如果你收集所有数据，你将会面临性能和存储增长问题。看似不重要的小细节可能是事故后需要的关键数据。
在数据泄露事故后，SIM不仅可用于对历史数据进行取证分析。很多企业还将SIM解决方案作为安全运营中心(SOC)实时事件响应的基础。实时事件响应和事件后历史分析的区别很关键，因为这两者的目标往往不一致--如果说不是直接矛盾的话。针对实时分析的SIM解决方案被调整为高性能相关性和过滤，尽量减少收集的信息。然而，为了提高SIM用于事故后历史分析的可操作性，你必须以完全相反的方式对它进行调整，以最大化收集和存储的信息。
可操作的结果是指可用于业务流程的结果。如果你的目标是合规性，那么，流程应该产生年度审计报告。如果你的目标是数据泄露检测，那么，这种结果应该能够允许分析师通过事件响应流程对安全警报进行调查。如果你试图提高安全操作，那么，SIM结果应该支持变更和配置管理流程。如果没有明确的目标以及你想实现的流程，SIM无法产生可操作的结果。#p#
让SIM成为安全监管计划的一部分
当你让SIM专注于单个目标，并成功地将它整合到你的标准安全操作中，那么，你就可以开始逐渐转移注意力去解决其他业务挑战。这并不意味着收集更多数据，因为这只会让SIM速度变慢和失去焦点。相反地，这意味着寻找新方法来重新使用SIM结果作为你的整体安全监管计划的一部分。
很多公司正在逐渐将其注意力从合规转移到风险管理。风险管理意味着查看企业面临的风险，并根据对企业的风险优先安排安全控制和事件响应来管理风险。对于SIM解决方案，这意味着关联安全事件信息和风险信息，例如：
用户身份/角色：涉及或影响哪些用户/角色
系统风险：受影响系统是否是关键业务系统
应用风险：受影响应用是否是业务关键应用
为了将风险管理添加到SIM产品中，你不一定要收集更多日志。在大多数情况下，你可以向现有日志数据补充关于应用、系统、用户和角色的风险/关键程度的信息。例如，很多SIM产品让安全分析师可以根据关键程度将服务器分为不同级别，可使用数字分数(例如1至5分，其中1为最关键，5为最不关键)或标签(例如高级、中级或低级)。这些额外的属性给你的结果添加了另一个视角，让安全专业人员可以优先业务关键安全事件，而推后非关键事件。这里关键的区别在于，关键程度是业务属性，而不是安全属性。
同样地，为了让SIM适应法规合规性，你不一定需要更多日志。在很多情况下，你必须关联现有SIM结果到特定审计报告要求或规则。大多数法规代表着行业需要部署的最小安全控制。如果你的SIM被设计为支持强大的安全程序，你可能已经收集了合规所需的所有日志。
一些企业可能想要部署实时响应到安全事件。毫无疑问，这是所有公司的宏伟目标。实时响应要求近乎完美的技术、流程和人员，这方面很少有公司是成功的。如果你试图实现这个雄心勃勃的目标，请确保这是完善的成功的SIM部署的最终目标，而不是第一个目标。为了让SIM适用于实时关联和分析，你必须选出日志数据的一个子集来进行关联。对太多日志数据进行实时分析会降低性能，而收集太少日志则会让事故后分析无法实现，因为记录中会有很多空白。成功的部署会将日志数据划分到长期归档中，这能保证尽可能全面的日志数据，以及更少的日志数据用于关联和警报。
成功的关键是渐进化：从有限的专注的目标开始，然后逐渐增加功能，同时确保SIM系统不会被数据淹没。如果你将SIM解决方案作为广泛的操作过程的一部分，你会发现最薄弱的环节并不是技术，而是操作者。如果你为SIM设定了过于宏伟的目标，你会看到，这个系统被日志数据覆盖，并且，你的工作人员也会被日志结果淹没。面对产生太多结果和警报的SIM的操作人员，他们只有两个选择：停止产生结果，这可能错过安全事件;或者忽略警报。很多SIM部署项目会出现其中一种情况或两种情况，在一段时间后，SIM最终不得不被废弃或取消。#p#
安全kaizen：SIM用于持续质量改进
看待SIM的一个有趣方式是将它作为安全计划的反馈环节。所有政策、配置和安全设备最终会以安全事件的形式来表达自己。SIM是风险管理程序的很好的良性循环机制，还可以用它来确定政策是否在合理运作。
为了将SIM变为强大的反馈机制，安全运营经理必须将其作为持续改进计划的一部分。SIM生成的每个事件都预示着企业安全的成功或失败。当安全专业人员查看安全事件时，他们有可能越过这个事件，并发现政策、流程或控制存在的根本问题。在日本制造业，持续质量改进的过程被称为“kaizen”，对改善安全程序产生巨大影响的概念。
在检查的第一级，安全事件可能突显出日志收集过程中的遗漏或错误。在审查事件时，安全分析师会发现日志信息的关键部分没有被收集。在很多情况下，企业对这种发现并没有马上采取行动，没有带来任何变化。而在持续改进过程中，安全分析师将能够提交变更申请表以添加日志到收集中。
在审查安全事件的过程中，安全分析师会发现一个较早期的重要事件但没有生成警报。这里，企业能够通过添加警报模式到SIM来改进过程。例如，分析师会收到关于不恰当数据库访问模式的警报，如不寻常的SQL查询。在调查该事件时，分析师发现不仅这个具体查询不寻常，而且它是来自不同IP地址和数据库用户，而不是既定的地址和用户。但SIM只针对这个奇怪查询发出警报，而实际上，它可以针对奇怪的连接来源和登录凭证发出警报。通过添加这个模式，分析师能够确保在未来SIM会对这种事件发出警报，让安全团队更快响应。
大多数企业在业务流程和配套基础设施方面持续进行着变革。我们都知道，变化是安全的头号敌人，因为变化会带来错误，而错误带来安全风险。SIM通常是配置错误首先出现的位置，它们可能触发安全警报或者只是不相关的看似虚假的日志信息。因此，安全人员应该密切关注SIM中与变更相关的事件，不仅因为变更可能带来潜在的安全泄露，而且因为变更可能已经破坏了SIM的关联和过滤模式。例如，应用中的常规升级可能将日志信息从“登录失败：未知用户”改为“失败登录：无此用户”。对于我们来说，这两个消息没什么区别，但对于SIM的字符串模式匹配引擎来说，这两者完全不同。如果你在升级前收到警报，你将不会再收到警报。
然而，在最基本的层面，SIM让你能够改善政策和流程，而不只是技术。如果你收集不同的日志、更改模式或者引入新模式，你将会改进SIM。但如果你使用SIM来发现损坏或无效的过程，或误用的安全政策，你会提高企业的整体安全性，而不只是SIM。
想要修复政策和流程，安全分析师需要的不仅仅是变更申请单。为了不断改进，你必须执行事件后审查，并对流程改进有着明确目标。你需要查看安全事件，包括从员工无意的简单政策违规行为到灾难性破坏，以此审查你现有的政策和流程以寻求改进。
安全信息管理工具是安全企业武器库的重要组成部分。这些工具具有很多功能，以至于很多公司都过于延伸，试图快速做太多事情。其结果是，很多SIM部署失败--因为性能问题、操作员过度劳累或者花费太多成本而没有成效。为了避免这种结果，企业应该从小事做起，专注于单个目标，并逐步扩大范围，直到成功。
