什么是SIEM？如何发挥出SIEM的价值？
<p>SIEM一般被认为是一个日志聚合的设备。然而，SIEM的主要能力是提供威胁检测，最好还能够实现事件调查、加速事件响应时间，同时还能有统一、整体的基础设施视角。SIEM只是保护和监控网络和系统的拼图之一;而从Michael Oberlaender看来，这块拼图由十层堆栈组成(OSI七层，加上用户、管理和金钱)，在刚开始的时候，会看上去很吓人。</p>
<p>
<img title="什么是SIEM？如何发挥出SIEM的价值？" alt="什么是SIEM？如何发挥出SIEM的价值？" border="0" src="https://zhuji.jb51.net/uploads/img/202305/c85feb10aa44bcd694ced1c1b6685fcb.jpg"></p>
<p>
在一个略微更加深入的层面，一个SIEM一般会提供以下能力：</p>
<ul>
<li>
事件与日志收集：从网络中各个来源聚合事件和日志数据，从而更方便监控。</li>
<li>
面板：频繁地从收集到的数据处做出表格，从而更容易地识别环境模式以及非正常活动。</li>
<li>
关联：基于常见属性将事件连接到一起，从而将数据转化为能够关联的有价值组合。</li>
<li>
告警：自动化分析关联事件，提供可持续的验证、趋势与审计。• 取证分析：能够基于特定的标准，在不同的阶段和时间段上搜索全日志。</li>
<li>
合规：：自动化收集应用中的合规数据，基于现有的安全、治理以及审计流程生成相对应的报告。</li>
<li>
留存：长时间存储历史数据，使长时间的数据关联更为容易;同时满足应用合规。</li>
<li>
映射：将计算机化的术语转化为可读的数据，更便于展示，并且能够映射到用户以及厂商定义的分类和方法中。</li>
</ul>
<p>
SIEM不应该是一个购入以后就被遗忘的设备。如果企业做的仅仅是购买了SIEM，连上网，然后认为SIEM将所有的安全需求都达成了——那就会陷入许多哦麻烦中。SIEM只是一个为事件响应团队与数字取证团队标准化安全工作流的工具而已——这些团队的成员会使用SIEM来确保网络的安全。</p>
<p>
这只是使用SIEM的原因之一，其他部署SIEM的原因还包括：</p>
<ul>
<li>
满足HIPAA、SOX、PII、NERC、COBIT 5、PCI、FISMA等合规要求。</li>
<li>
ISO 27000、ISO 27001、ISO 27002和ISO 27003等认证。</li>
<li>
日志管理与留存。</li>
<li>
事件响应与持续监控。</li>
<li>
事例管理以及工单系统。</li>
<li>
策略实施验证以及监测策略违反情况。</li>
</ul>
<p>
许多企业过去部署SIEM的主要原因是为了合规。SIEM的功能不仅仅能保护敏感信息，还提供一种能够满足合规要求的手段。企业可以通过SIEM避免审计失败，因为SIEM的存留和报告功能能够验证自身的合规情况是否和法律法规的要求一致。</p>
<p>
然而，就像之前提到的那样，一个企业不能单纯地部署了SIEM，让员工去监测SIEM的情况，然后就再也不关心系统了。要让一个SIEM有用哪个，尤其是对于事件响应和威胁检测系统有用，其告警以及事件和日志收集流程必须进行调整。如果告警太多，相关团队会错过关键数据，迷失在噪音之中;如果告警太少，那严重的安全事故可能永远也无法被检测到。这一条调整的过程需要在人工侧发生，需要依赖那些十分熟悉网络环境，并且盯着SIEM以及其监测的系统，然后基于业务和网络需求进行更新。这一周期，可以参考Gartner的预测、预防、检测和响应的四阶段模型。</p>
<p>
简而言之，SIEM遵从GIGO原则(garbage in, garbage out;输入的如果是垃圾，输出的也是垃圾)。SIEM会反应出用户以及用户安全团队对其的输入内容——缺乏对SIEM必要的审阅、观察、调整，SIEM就会停滞，并最终成为一个负担。SIEM解决方案应该由业务驱动，以流程为核心——像ITIL框架这样的就可以协助决定哪些流程或者进程可以被合并、修改、或者完全舍弃。</p>
<p>
那么从哪里开始?试着用一个服务目录，如果自己没有，就用一些基础的用例，从那里开始，没有必要从零开始。</p>
<p>
就像SIEM的使用需要持续的适应，这些方式也一样，以下这些内容也会不断改变：</p>
<ul>
<li>
合规要求</li>
<li>
流程</li>
<li>
进程</li>
<li>
威胁</li>
<li>
脆弱点和CVE</li>
<li>
人员</li>
<li>
客户/用户期望</li>
<li>
SLA</li>
</ul>
<p>
每个企业应用SIEM的方式不一定会相同，甚至自身的竞争对手或者同类企业的使用方式都会大相径庭——最终还是需要看哪些适合自己的环境和业务。创建一个路线图作为向导可能会有所帮助——从“为什么”或者使用SIEM的目的开始，会更容易识别相关资产以及优先级。</p>
<p>
在确定了资产和优先级以后，下一步就是定义范围。这事确保SIEM解决方案能适合的关键。SIEM的能力范围在除了支持和保护业务之外，还需要能够助力业务。</p>
<p>
高效的技术、网络运营以及安全运营团队在某种进程和流程之下协作来识别：</p>
<ul>
<li>
数据分类</li>
<li>
关键资产</li>
<li>
进出点(包括网络和物理层面)</li>
<li>
必须的合规要求</li>
<li>
内部IP机制</li>
</ul>
<p>
一旦有了这些，还必须有一些流程，包含责任和追责制度。另外，还需要有固定的来源，对一些问题进行回答，或者能够获得答复：可以是人、团队，甚至可以是一个内部的页面。</p>
<p>
为了确保实践一致性，可以将SOC或者SIEM围绕ITIL实践展开;并且鉴于ITIL专注于管理，可以将其作为一个向导或者路线图。</p>
<h3>
战略管理</h3>
<p>
定义自己对SIEM的愿景，或者SIEM解决方案可以整体提供的服务。这个定义可以是简单的，也可以是复杂的，但最好从一些简单的东西开始，定义一些对象的“常识”。十个常见用例可以在早期联系起来，作为一个好的开始。</p>
<h3>
服务设计</h3>
<p>
一旦分析了业务需求，就可以开始将SIEM/SOC的期望以及部署的初心和业务关联。这里的目标是创建一个“SIEM服务目录”，用一系列的指标作为SIEM在业务中的核心功能。</p>
<h3>
服务与技术管理实践</h3>
<p>
SOC或者SIEM运维人员需要注意环境中的变化。这看似是一个很显而易见的事，但需要真正落地。SOC或者SIEM的运维人员如果不知道一个新的PC加入了网络，或者某个数据中心暂时下线了，会导致误报、审计失败、无效的报告等。</p>
<p>
这一步骤也需要实践在“服务设计”阶段中描述的功能，包括定义责任、沟通、SLA，甚至OLA等。这一步尤其需要标注趋势、修复行为、每日活动，以及配置和存货改变。</p>
<h3>
持续改进</h3>
<p>
这一步对企业而言经常是最困难的一步，但也是最必要的一步。在这一阶段，数据会被审阅，并且用于之前建立的指标来重新定义或者改善服务、流程和进程。这一阶段是确认和验证人工或者GRC收集的数据的大好机会。使用持续改进记录也能提供一定帮助。</p>
<p>
到这里，应该能够了解为什么需要SIEM，以及理解它能够给业务带来的许多价值中的一部分。但是要记得，优先级、方式和方案都会基于环境而改变——从简单的 开始，随着对SIEM的理解逐渐开始增加复杂性。使用已经被证明有效的框架和已经被证明有价值的资源作为辅助工具，可以帮助在一些最初的需求上做需求。</p>
<h3>
点评</h3>
<p>
SIEM的价值在于通过对于各类事件的整合，进行安全分析，从而实现对威胁的发现、对安全问题的响应、对已发生攻击的溯源取证等等。而另一反面来看，SIEM也是一个“难对付”的产品：需要通过一系列的流程和制度，才能有效地使用其各种功能;需要根据业务不断地调整相关的配置，才能将其功能的价值发挥到最大。</p>
<p>
原文地址：https://mp.weixin.qq.com/s?__biz=MzkxNzA3MTgyNg==&mid=2247490903&idx=1&sn=e9c659c339a3bf39ac719b7c5edf7436&chksm=c1476feaf630e6fcaff82ab0c1134df79dcf8c3b21dd28ea0226039dff11dddd47873947e135&mpshare=1&s</p>
頁:
[1]