针对国内的情况，我们一直在试图缓解或者处理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从业的技术人员需要潜心研究的问题了。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。