How do Threat Prevention Layers work?

[Vladimir]

Tomer,

Can you expand on the use of Threat Prevention layers?

I am having difficulty envisioning how those relate to the overall policy and its layers.

I.e. Adding layer to Threat Prevention seem to create additional policy:

That is not tied to the layers in the main policy.

Would those TP policies be then processed sequentially?

What is the point of those layers if the only differentiation in each is the Scope and Profile?

How is the TP layers differ from multiple rules in the same TP policy?

Thank you,

Vladimir

[Tomer_Sole]

Hi,

Threat Prevention Layers enforcement is calculated by the following:

- Each layer has a first-match logic. Once a match is found, processing is done at the other layers.

- Unlike Access Control, there is no requirement for clean-up rule. So if there is no match on a layer, assumption is that no threat prevention inspection is needed.

- In case there are multiple threat prevention layers, and a match was found in several layers, the strictest option matters. So if you chose to prevent a protection for a subnet in the first layer but detect that protection in another layer, it will be in prevent.

The motivation was to add extra layers of protection, if needed. Separation can happen per blade (like the IPS Shared Layer which appears post-upgrade and is the way things worked in previous versions) or per network (for the sake of policy clarity and in later versions, role segregation).

At Check Point we believe that Access Control and Threat Prevention are separate things. Access Control is typically a more massive operation, with sometimes hundreds of rules and more, while generally for Threat Prevention you probably don't define that many rules, and entire scopes go with a profile. Adding a new Access Control Rule does not violate a threat prevention profile. Installing policy changes is done separately for Access Control and Threat Prevention because we believe those are different types of owners in the organization and they don't have to affect one another.

[Vladimir]

Tomer,

I'm still a bit baffled by it, should you have an opportunity to showcase few sample policies with layers, it will go a long way clarifying the issue.

As far as I can tell, there is no ability to limit individual admin's rights over single or select Threat Prevention layers:

Further more, when multiple Threat Prevention layers are used, I am seeing a warning about possible conflict in IPS:

I'll read the SK later to see what is it all about.

As to the sequential processing with segregated controls, multiple rules in the same policy seem to be able to address it:

But I really do not see much merit in separating blades in rules if they cover same scope, as shown in rules 2 and 3. 

[Tomer_Sole]

Hi,

As far as I can tell, there is no ability to limit individual admin's rights over single or select Threat Prevention layers:

This is actually coming in the next release of Security Management Server, not this one.

Further more, when multiple Threat Prevention layers are used, I am seeing a warning about possible conflict in IPS:

I'll read the SK later to see what is it all about.

Personally I think we may have used the wrong UI indication to tell our users that the policy works as they designed it. It means that the stricter option matters. It's not really a warning, it's more like a reminder of how the policy will behave.

So we can talk about 2 examples:

1. Each layer controls a software blade. This pattern already happens for users who upgraded their Management but not their gateways - the IPS Shared Layer is separated from the rest of the Threat Prevention products, which are in a second layer. So the upgraded policy scenario is a private case of this pattern. Users can go further and separate the signature-based decisions and profiles with the dynamic-based decisions and profiles by placing them in multiple layers. 

2. Each layer controls a different network, and has multiple profiles for different portions of a network (so multiple rules per layer). 

Why split to layers and not just have one big rule-base? It's up to each administrator to decide, generally:

1. Smaller building blocks help understand the policy better

2. Features that are coming in the next release: Sharing the same layer across multiple policies, and assigning different permission profiles to edit different layers - similar to the way Access Control layers are defined.

[Vladimir]

Thank you!

This does makes more sense when new features are implemented in the : "coming in the next release: Sharing the same layer across multiple policies, and assigning different permission profiles to edit different layers - similar to the way Access Control layers are defined." 

Will the layers applied to the same policy be visible in one contiguous view, same as inline layers?

[Tomer_Sole]

I think that the need for "one contiguous view" is not due to threat prevention execution similar to inline access layers or not (it's not similar to inline layers...) but rather because it makes sense to see all the rules in one contiguous view (and then it also makes sense to do that for ordered layers at Access Control). At the moment we don't have concrete plans for this but we will take your feedback into consideration.

[Vladimir]

Yep, that's exactly it: "rather because it makes sense to see all the rules in one contiguous view".

It is just had to made very clear that this is the presentation only, not the actual sequence of execution.

[Johannes_Schoen]

@Tomer_Sole: Could you maybe clarify again the behavior, if I got multiple rules on one layer, with same scope and different threat profiles, like in the screenshot provided by @Vladimir :

Will Threat-Emulation in Rule 3 be enforced, or is rule 2 shadowing rule 3, so that only AV and AB is enforced for internal-zone?

So in one layer - is it a first-match and out or first-match per protection?

Thanks
Johannes

[Tomer_Sole]

The combination of all the enabled engines will apply.

[Johannes_Schoen]

Okay, so for clarification:
(Same Scope)
Rule 1: av-only
Rule 2: ab-only
Rule 3: TE-only
Rule 4: av, ab and TE

With this setup is garanteed, that up to and including Rule 3, Blades AB, AV and TE are enforced, but Rule 4 is shadowed by Rule 1-3 and will never match, right?

[Tomer_Sole]

No.

If these rules belong to the same layer, the first matched rule, #1, will apply, and that's it.

However if you split each rule to its own layer, AV, AB and TE will apply with the strictest prevention set.

[Chen_Fenghua]

Hi Tomer:

In case there are multiple threat prevention layers, and a match was found in several layers. Aside these layers both prevent one protection.

How about the matching in this situation?

[TP_Master]

Hi Chen,

Not sure I understood the question accurately, but the answer to your question is that both layers will be matched, and the protection will be prevented. Is that what you asked?