来源：https://github.com/defenxor/dsiem/blob/master/docs/directive_and_alarm.md
与OSSIM类似，Dsiem指令包含一组用于评估传入规范化事件的规则。指令在满足足够的规则条件时触发警报。
一、关于指令规则
在Dsiem中有两种类型的指令规则，即PluginRule和TaxonomyRule。正如规范化事件表中所建议的，PluginRule根据PluginID和Plugin_SID字段区分事件，而TaxonomyRule使用Product、Category和可选的Subcategory字段。
如果您想要基于特定品牌设备产生的特定事件进行关联，那么应该使用PluginRule。另一方面，TaxonomyRule允许基于一组具有相似特征的事件进行关联。
例如，假设您的网络中有以下安全设备:Suricata IDS、SomebrandNG IDS、Pfsense防火墙、SomeRouterNG防火墙。PluginRule允许你定义一个指令，该指令说:“如果Suricata IDS检测到SQL注入或者XSS攻击没有被SomeRouterNG防火墙阻止，就发出警报”。相反，TaxonomyRule允许定义更一般的指令，即“如果IDS检测到web应用程序攻击未被防火墙阻止，则发出警报”。
尽管TaxonomyRule具有明显的灵活性，但是它确实需要您维护一个定制的分类/分类法方案，而这并不是PluginRule所需要的。在上面的例子中，使用TaxonomyRule意味着您必须知道并分类来自Suricata或SomebrandNG的哪些事件是“web应用程序攻击”，而PfSense和SomeRouterNG中的哪些事件是“不阻塞”。
作为一个通用指南，当有类似类型的产品(如IDS和上面的防火墙)要覆盖时，TaxonomyRule应该是首选，因为它将防止大量冗余指令。但如果不是这样，PluginRule可能会提供一个更容易维护插件/解析器配置的插件。
二、指令和规则处理
下面是具有多个PluginRule的dsiem指令的示例。
注意，上面的SRC_IP中的指令Ping泛滥有3条规则，每条规则都有一个从1到3的阶段，并且可靠性和超时键的值各不相同。
当传入的事件与指令的第一阶段规则条件相匹配时，dsiem将创建与该指令相关联的backlog对象，以跟踪潜在警报的进度。
然后，Dsiem将等待与下一个规则(即阶段2)规则条件相匹配的传入事件，直到其中一个条件发生:
匹配事件的计数达到阶段发生值，此时求值将继续到下一个规则(即第三阶段);或
超时持续时间(以秒为单位)从第一个匹配的事件开始，在这种情况下，backlog将被丢弃。
重复上述操作，直到最后一个规则的求值完成——在此之后，backlog对象将最终被删除。
三、触发报警
Dsiem在当前阶段的规则条件与传入事件匹配时，为backlog计算一个风险值。当backlog风险值≥1时，将触发报警。风险价值计算公式如下:
Risk=(reliability*priority*assetvalue)/25
地点:
可靠性(1到10):活动规则可靠性值。更高的可靠性意味着对(潜在的)警报为真实阳性的可能性有更高的信心。
优先级(1到5):指令的优先级值。这反映了指令的重要性。那些有更严重影响的应该给予更高的优先考虑。
资产值(1到5):来自assets_*.json配置文件上的资产值集。这反映了目标/受影响资产的重要性。更高的价值应该分配给更重要的资产。
根据上面的情况，我们可以计算出任何backlog的风险值，从所有参数都处于最小值时的0.4到所有参数都处于最大值时的10。因为报警只会在该值≥1时才会被创建，所以我们也可以推断出任何报警的风险范围是1到10。
通过使用Dsiem启动参数，您可以根据该范围配置警报何时应该标记为低风险、中等风险或高风险。默认阈值为:
低风险⟶风险值小于3大于1
中等风险⟶风险价值3到 6
高风险⟶风险价值超过6到10
启动参数medRiskMin和medRiskMax控制数分别为3和6。
四、例子指令⟶报警处理
让我们假设Dsiem配置了来自SRC_IP指令的上述Ping流，以及一个assets_*.json，它为10.0.0.0/8网络定义了一个资产值4。
当Dsiem收到以下一系列事件时:
plugin_id: 1001, plugin_sid: 2100384，协议:ICMP, src_ip: 10.0.0.1, dst_ip: 10.0.0.2
plugin_id: 1001, plugin_sid: 2100384，协议:ICMP, src_ip: 10.0.0.1, dst_ip: 10.0.0.3
plugin_id: 1001, plugin_sid: 2100384，协议:ICMP, src_ip: 10.0.0.2, dst_ip: 10.0.0.1
plugin_id: 1001, plugin_sid: 2100384，协议:ICMP, src_ip: 10.0.0.1, dst_ip: 10.0.0.4
plugin_id: 1001, plugin_sid: 2100384，协议:ICMP, src_ip: 10.0.0.1, dst_ip: 10.0.0.5(重复13x)
1、第一个事件
（1）事件匹配指令1规则条件，因为:
它们对于plugin_id、plugin_sid和协议具有相同的值。
事件src_ip(10.0.0.1)匹配来自HOME_NET条件的指令。这是因为HOME_NET引用了assets_*-json文件中定义的任何地址。
事件dst_ip(10.0.0.2)将指令匹配为ANY的条件。这是因为ANY将匹配所有可能的值。
（2）创建backlog #1是为了跟踪这个潜在的警报。
（3）backlog #1已经满足了它的所有条件，包括它需要的出现次数(1个事件)。这就开始了risk = (reliability * priority * asset value)/25 =(1 * 3 * 4)/25 = 0.48的风险计算，所以还没有报警。
（3）backlog #1现在转到第二个相关阶段，并开始监视可能触发第二个阶段规则条件的传入事件。
2、第二个事件
这个事件匹配backlog #1的第二个规则条件，因为这个事件src_ip与值:1的指令匹配。1表示对第一个规则中匹配的from值的引用，在本例中是10.0.0.1。
3、第三个事件
由于from条件和事件的src_ip不匹配，所以该事件不匹配backlog #1第二个规则条件。
因为这个事件确实符合指令1的规则，一个新的backlog #2将会被创建来单独跟踪backlog #1。
4、第四个事件
事件符合backlog #1第二规则条件。这将使第二阶段的事件数从1增加到2。
事件不符合第2条规则条件。
5、第5到17个事件
第5到第7个事件匹配backlog #1第二个规则条件，并使其事件计数达到发生限制(5个事件)，因此这将重新计算风险值为risk =(5 * 3 * 2)/25 = 2.4。这将生成一个低风险警报，并将backlog #1移动到第三个相关阶段。
接下来的10个事件(8-17)匹配backlog #1第三条规则条件，并将再次重新计算风险值为risk =(10 * 3 * 4)/25 = 4.8。这将导致相关警报的风险标签从低到中更新。
Backlog #1现在没有更多的规则需要处理，并且会立即从内存中删除。对于backlog #2，它将持续等待与它的第二条规则匹配的事件10分钟(600秒)，之后它将过期并被删除。
Backlog #1现在没有更多的规则需要处理，并且会立即从内存中删除。对于backlog #2，它将持续等待与它的第二条规则匹配的事件10分钟(600秒)，之后它将过期并被删除。
五、创建Dsiem指令
基本的Dsiem指令可以通过解析dpluger工具在Dsiem插件创建过程中生成的TSV文件自动创建。这些指令是基本的，因为它们只寻找具有相同的PluginID和PluginSID组合，以及相同的源和目标IP地址对的事件。
例如，给定一个包含以下内容的sangfor_plugin-sid.tsv文件:
我们可以使用以下dpluger命令:
./dpluger directive -i 3001 -f sangfor_plugin-sids.tsv
来自动生成这个directives_dsiem.json文件:
以上生成的指令具有以下特点:
（1）指令id按顺序从-i参数提供的数字开始分配给dpluger。此参数用于防止id与其他文件中已定义的指令冲突。
（2）每个指令有3个相关规则阶段:
第1阶段:匹配具有类似于TSV文件的每一行所指定的PluginID和PluginSID组合的单个事件。
阶段2:与阶段1具有类似的条件，增加了事件也匹配阶段1源和目标IP地址的要求。此阶段将在3600秒(1小时)内匹配最多10个事件。
阶段3:与阶段2具有类似的条件，但设置为在6小时内匹配10,000个事件。
（3）设置指令优先级值(1)和相关规则可靠性值(每个连续阶段:1,5,10)，使指令在第二阶段收到最后一个匹配事件时触发低风险报警。如果事件源或目标IP地址包含值至少为2的资产(默认资产值)，则为真，因为这将导致第二阶段的最后一个事件产生风险值1.2。
网友评论