diff --git a/_posts/2019-09-12-Decaying-Of-Indicators.md b/_posts/2019-09-12-Decaying-Of-Indicators.md index 5e44e39..7c6f6a1 100644 --- a/_posts/2019-09-12-Decaying-Of-Indicators.md +++ b/_posts/2019-09-12-Decaying-Of-Indicators.md @@ -1,11 +1,13 @@ --- title: Decaying of Indicators - MISP improved model to expire indicators based on custom models layout: post -featured: /assets/images/misp/blog/community-view.png +featured: /assets/images/misp/blog/decay.png --- # An improved and flexible model to expire indicators +This blog post introduces the new functionality of MISP 2.4.116 which allows users and organisations to easily expire information depending on their objectives and targets. + MISP being a distributed system, various users and organisations are sharing data, sometimes without even knowing each others. While having access to a lot of information is extremely beneficial for all parties, it, however, also induces challenges to deal with. In this blog post, we will mainly discuss about information **quality** and **freshness**, other issues like **trust**, **use-cases**, **interests**, etc. are partially taken into account but will not be presented. Nevertheless, these concepts are examined in this [paper](https://arxiv.org/abs/1902.03914) along with a detailed explanation of the solution we have chosen to tackle these issues. @@ -32,11 +34,11 @@ Where ``P`` is composed of ``parameters``: We still have to see how the ``base_score`` is actually computed. In the built-in version of the *Decaying Model* in MISP, the ``base_score`` is computed from the *Taxonomies* and some weight. Weights are a mean to prioritize extracted ``numerical_values`` from *Taxonomies* over others. -To give the intuition of how the ``base_score`` computation works, let's look at two examples. In these examples, the two *Taxonomies* used are +To give the intuition of how the ``base_score`` computation works, let's look at two examples. In these examples, the two *Taxonomies* used are [*phishing*](https://github.com/MISP/misp-taxonomies/blob/master/phishing/machinetag.json) and [*admiralty-scale*](https://github.com/MISP/misp-taxonomies/blob/master/admiralty-scale/machinetag.json). Both of them contain *Tags* that have a ``numerical_value`` associated to them: -- admiraly-scale:source-reliability = Completely reliable, ``numerical_value = 100`` -- admiraly-scale:source-reliability = Not usually reliable, ``numerical_value = 25`` -- phishing:psychological-acceptability = high, ``numerical_value = 75`` +- admiraly-scale:source-reliability = Completely reliable, ``numerical_value = 100`` +- admiraly-scale:source-reliability = Not usually reliable, ``numerical_value = 25`` +- phishing:psychological-acceptability = high, ``numerical_value = 75`` So, if an *Attribute* only have one *Tag* attached, let's say ``admiralty-scale:source-reliability="Completely reliable"``, the ``base_score`` would be: ``` @@ -51,9 +53,9 @@ phishing = 50 --------------------- sum 100 ``` -If an *Attribute* has the *Tags* admiraly-scale:source-reliability = Completely reliable and phishing:psychological-acceptability = high attached, the computation steps would look like this: +If an *Attribute* has the *Tags* admiraly-scale:source-reliability = Completely reliable and phishing:psychological-acceptability = high attached, the computation steps would look like this: -base_score comnputation steps +![base_score computation steps](/assets/images/misp/blog/decaying/bs-computation-steps.png) Thus, the ``base_score`` of this *Attribute* will be ``87.50``. @@ -68,7 +70,7 @@ Now that we've seen the basic concepts, let's have a look at how MISP implements At the *Event* level, a new filtering button has been added to attach the real-time computed ``score`` of any *Attributes* that has been mapped to a *Model*. -Decaying Model index +Decaying Model index ### Endpoint: ``attribute/restSearch`` @@ -107,19 +109,19 @@ When creating a new *Decaying Model*, setting a parameters and viewing its impac ### Customizing lifetime and decay speed parameters -