Let’s talk a little bit about “Policy Layers” and “FireSIGHT Recommendations” in Intrusion Prevention Policy. We mention that in previous blog, and now we will discus these concepts in more details.
Our “WP TEST IPS POLICY” looks like this:
Here we can see that our policy consists of two sets of layers, each containing one or more layers. Perhaps this can be viewed more clearly if we click “Policy Layers” link within our IPS policy:
We can see those two sets of layers:
- Built-in Layers
- User Layers
We can also see that at this moment each set of layers contain one layer. “Built-in Layers” contains “Balanced Security and Connectivity” layer. Remember from the last blog that this was our choice when we created our IPS policy. “User Layers” set contains one layer called “My Changes“. These layers we have when we create our IPS policy, without adding our custom layers or applying “FireSIGHT Recommendations“.
When we first create the IPS policy, “Built-in Layers” set contains signatures that have attributes depending on our choice when we created the policy. On the other hand, “User Layers” set contains rules that we created or modified. We changed CWD ~root rule in our previous blog, so that’s why we have one rule in “My Changes” layer. If we didn’t mess with that rule, we would have a zero here.
At this point we can say something about layers inheritance. The rule is simple: all changes from top layers take precedence over those in lower layers. For example, let’s take a look at the CWD ~root rule at the top layer, in this case “My Changes” layer. We can se that the rule action is set to block intrusion events and that the rule is enabled:
Now if we take a look at this same rule but within “Built-in Security and Connectivity” layer, we can see that the rule is not changed, has default state of disabled and this kinda-red color indicates that this rule is changed “somewhere above”:
Because our previous tests showed that this rule indeed triggers, we know that this inheritance model works as described.
Ok, let’s make it a little bit more interesting by applying “FireSIGHT Recommendations“. When we initially deploy an IPS, it should spend some time learning about our network, hosts, services, applications and so on. After that period we can apply that knowledge to our policy. This is done by clicking the “FireSIGHT Recommendations” link at the top left portion of the IPS Policy Editor. We can see that we can generate recommendations only or generate and apply them:
Let’s generate and use recommendations. After a little processing, we are presented with the summary page:
Now we need to apply generated changes by clicking the “Policy Information” and “Commit Changes“:
After the IPS policy has updated, we need to update all the devices that relies upon this policy.
What is going to happen now is the change of the inheritance. This action will add a new layer called “FireSIGHT Recommendation” above the already existing layer “Balanced Security and Connectivity“. So we have two Built-in layers and one User layer:
Let’s now change the name of our user layer – “My Changes” to “WP IPS LAYER ONE“and add another user layer – “WP IPS LAYER TWO“.
First we click the yellow pencil within the “My Changes” layer and give this layer another name. Then we go back to “Policy Layers” and click “Add Layer“. We give it a name and click OK. Now we have two User layers and two Built-in layers:
What is going on with our CWD ~root rule now? In the “WPS IPS LAYER TWO“:
It is not bold and it’s colored in yellow, which means all settings for this rule is defined “somewhere below”. Let’s go a layer down, to the “WP IPS LAYER ONE“:
It is bold and has no colors, it must mean that this is the layer this rule is changed or created in.
Further below – “FireSIGHT Recommendation“:
No rule state icon, kinda-red color, so this rule is created/changed “somewhere above”. Finally, the “Balanced Security and Connectivity“:
Kinda-greyed-green rule state icon, no bold, so this is where the rule originated.
To sum up, we have the bottom layer which is based upon our choice when we created the policy. Depending on our choice, rules will be enabled or disabled and will have this or that action. We have one layer above, the user layer called “My Changes” which is initially empty and contains all of our changes. Our changes override setting in the layer(s) bellow. When we apply recommendations, additional layer is inserted above the base layer and overrides all setting in that layer, which makes perfect sense. Recommended settings are finally overridden by settings we make in the User layer(s), which again has perfect sense.
We can delete a layer if we want. To be precise, we can delete any user layer we want, by simply clicking the trash can icon and we can remove “FireSIGHT Recommendation” layer from built-in layers by going to “FireSIGHT Recommendations” and clicking “Do Not Use Recommendations“:
And we are left with the only layer we cannot delete – “Balanced Security and Connectivity” base layer:
What happens with our tuned CWD ~root rule? Let’s verify…
So, all of our work is lost, and we can pull this attack off again:
Before we go any further, I just realized that I missed one important thing to mention. Before we even start messing around with IPS policies, we should tune the “Default Set” under the “Objects->Variable Set” or create our own and then make a point to it under our rules settings within the access control policy. We need to specify at least our protected network which is defined as $HOME_NET variable:
If we changed the “Default Set” like described above, then we don’t need to edit our access control policy rules, because this set is implied. Otherwise, we should reference our set in our rules
Next time we will create our own IPS rules.
Thanks for reading!