TT安全上的 这篇文章谈及了SIEM实施的负面问题，指出了四个可能存在的主要原因。实际上，这篇文章源自DarkReading在2010年9月27日发表的这篇文章《 Five Reasons SIEM Deployments Fail》，是一个采访多位业内人士的综合报道。原文指出的是五个原因。第五个原因谈及的是“SIEM的伸缩性问题，尤其是事件采集和处理性能的问题”。

其实，文章提及的四个问题，我之前也都有提到，针对国内的情况，我们也一直在试图缓解或者处理这些问题，至少尽可能地规避这些问题。
1）SIEM 很难用，如果是SOC就更难用。没错。因此，这不仅需要技术策略，还需要市场策略，正如我们从2008年开始实践的那样，我们开始一个“Make SIEM Simple！”的行动，简化SIEM，我们倡导日志审计。根据客户需求和市场细分，我们从多个方面简化SIEM的技术复杂度，部署复杂度，维护复杂度。当然，永远没有银弹，简化不等于简单，问题的关键在于如何找到一个细分市场，这个市场的客户能够接受目前程度的简化。我要告诉SIEM从业人员的是，这个细分市场是存在的！所以，需求分析很重要！

2）事件标准化的问题。早期有人从IDS的角度出发提出了IDMEF，不过无人问津，后来，ArcSight也搞出了一个标准化格式 CEF，不过有点可能会成为另一个CheckPoint的OPSEC。目前比较火的是美国MITRE搞的 CEE。MITRE具有军方背景，他们之前搞出了CVE。如果国内有人致力于研究和运用这个，咱们可以交流。

3）关于技术与管理的冲突问题。这个主要是指SIEM为了获得最终的分析效果，需要收集各种门类的信息，但不幸的是这些信息往往隶属于不同的部门，例如网络和主机，还有应用可能就分属于2到3个部门，如何统一收集和分析这些信息，同时确保不会引发大家的或真或假的担忧，以及不介入部门间的利益纠葛，是一个问题。这个问题的规避需要在规划和实施的时候进行很好的预处理。很重要地，在规划的时候十分重要。一个好的Consultant能够减轻很多压力。更多的信息，我会在以后的博文中陆续介绍。实际上，我之前也有提及过。

4）一些甲方的技术和管理人员把SIEM看成安全管理的银弹，也就是期望过高的问题。这个，我之前也多次提及，关键还是要在一开始规划的时候，定位要准确，需求要明确。“Don't Boil the Ocean！”。

5）关于SIEM的性能和伸缩性的问题。这个就是SIEM从业的技术人员需要潜心研究的问题了。