来源：https://github.com/defenxor/dsiem/blob/master/docs/faq.md
以下是关于这个项目经常被问到的问题(技术或其他方面)的答案。
一、为什么不直接使用OSSIM呢?
我们做到了，而且持续了很多年。但是随着我们对Elastic stack的使用不断增加，将日志解析并摄取到两个不同的系统中的必要性成为操作团队的一个更大的问题。
除此之外，我们也对OSSIM的未来发展感到担忧，因为Alienvault AT&T公司的网络安全正日益将他们的重点转向基于云的产品。
二、但是…为什么OSSIM ?
Dsiem使用“ossimstyle”事件规范化方案、相关规则和风险计算方法，因为这是我们的分析师最熟悉的，也是我们开发的大多数自定义规则所使用的。
这意味着Dsiem继承了一些OSSIM设计上的限制，比如需要在规范化事件上使用IPv4地址，或者限制定制数据字段的数量。至少现在，我们接受这些折衷方案，以便在团队中更容易地过渡和更快地采用。
三、但它不像OSSIM!
这就是为什么我们不称之为“OSSIM-clone😉”。
提到的两个重要区别是Dsiem和OSSIM如何处理漏洞信息，以及它们如何构造相关规则。这里有更详细的解释。
四、为什么不支持[此处插入特性]?
无论您认为Dsiem中应该包含哪些附加功能，最好在it之外实现它们。Dsiem仅仅是为了取代OSSIM相关引擎，而不是整个OSSIM包，OSSIM包还包括一个票务系统、知识库系统、集成的安全工具(Suricata、Ossec、OpenVAS等)，以及基于php的web界面。
为了进一步说明这一点，之所以为Dsiem提供web UI，是因为Kibana没有一个小部件来完成我们需要做的两件事:更新文档的字段(alarm的状态和标记)，以及显示一个多对多关系(siem_alarm和siem_events索引之间的关系，通过siem_alarm事件)。
五、Elastic 已经有自己的SIEM，为什么我要使用Dsiem?
Dsiem、OSSIM和其他类似的系统基于预定义的关联规则生成警报，在某些方面比Elastic SIEM等系统更灵活、更特别的方法有自己的优势。
例如，关联规则产生的警报数量总是比进入系统的事件数量少几个数量级。基于警报的系统允许安全监控团队有一个可测量的基准性能目标，如“所有警报应在30分钟内进行调查”。当团队必须直接处理进入系统的所有原始事件时，这种覆盖承诺将更难制定。
也就是说，如果您有足够的资源，没有理由不使用这两种方法。在Defenxor，我们使用相关规则来处理已知的和重复的威胁，以及Kibana和Elastic SIEM提供的更灵活的方法来寻找可能用作新规则的模式。
六、为什么报警必须从Dsiem→Filebeat→Logstash→Elasticsearch?你不能直接发送ES吗?
使用Filebeat使Dsiem不必处理与网络相关的错误或Logstash管道中的拥塞。使用Logstash，因此我们可以使用其过滤器配置尽可能多地转换数据，而不必在Dsiem中对数据进行编码。Elasticsearch API和客户端库经常变化，因此直接向Elasticsearch发送警报可能需要我们为每个版本的Elasticsearch维护一个特定的Dsiem版本。
该设计还将Dsiem代码从Elastic stack 特定的库中解耦出来，有效地允许Dsiem在需要时用作非ELK堆栈的ossims样式的相关引擎。
七、那么如何在没有Elastic stack的情况下使用Dsiem呢?
首先，使用Logstash以外的其他东西来根据Dsiem规范化事件规范对日志进行规范化。例如，您可以使用Fluentd来实现这个目的。
接下来，通过HTTP将这些规范化事件发送到Dsiem。同样，应该可以使用类似Fluentd HTTP输出的东西。
最后，用其他内容替换Filebeat以读取Dsiem输出(siem_alarm .json)，并将其发送到最终的存储或通知目的地。在Fluentd中，这可能涉及尾输入和json解析器插件将结果发送到某个Fluentd数据输出插件。
八、这个在生产中使用过吗?稳定版本在哪里?
我们在生产中使用Dsiem来交付托管的安全监视服务。具体来说，我们在一个自托管的Kubernetes集群内的所有部署上使用最新的docker映像，并使用Keel策略自动更新它们。这给我们的团队增加了额外的压力，以确保主分支是可部署的，并且没有已知的错误。
同样值得注意的是，Dsiem不必将自己插入到主要ELK日志摄取管道的中间。它只需要进入管道(如这里所示)，因此使用管道到管道或多个Logstash实例的适当Logstash配置将能够屏蔽主日志摄取流，以防Dsiem中出现任何中断。
网友评论