Installing Threat Prevention Policy Doesn't Resolve All Changes From Session?

[eranlif]

Hi All,

This may be a silly question but here goes...

After a session of editing the Threat Prevention policy (namely, switching one IPS protection from Disabled to Prevent), I went to the Install Policy window, selected the Threat Prevention box ONLY, and installed the policy. This ended successfully.

When I cleared the Threat Prevention box and selected the Access Control one instead, SmartConsole showed that there was, still, one change from this session that has not been installed yet. This surprised me, since I have only touched one IPS protection...

I verified that the change on the Threat Prevention policy has been made, and found that the IPS protection now blocks traffic as it should. So, now I wonder - Do I have to install the Access Control policy too? Did I unknowingly change the Access Control policy?

I will be grateful for any insights, 

Thanks!

[the_rock]

Its not silly question at all...I cant speak for reason in your case, unless I saw it for myself, but you can verify via audit logs what it shows. Usually, for threat prevention changes, you would just need to install that policy for settings to take an effect. Sounds like there may had been something you changed that wold fall into access control policy category, for the lack of better term.

Andy

[Amir_Senn]

For IPS, you should install Access Control as well for good practice.

The reason is that a few of the IPS protections are actually Access Control based as seen in the attached picture:

[the_rock]

I usually do that, agree its best practice!

Andy

[eranlif]

Thanks for your reply!

Installing both Access Policy and Threat Prevention Policy is indeed good practice. However, I am curious to know whether it's mandatory and what might happen if we omit to do a double-installation. (The complementing question is - Why doesn't the button responsible for installing TP Policy perform a double-installation automatically?...)

As far as I remember, Core protections are an important, but also an exotic type of protections. The specific protection I activated was not a Core protection. This raises the question - how can I know whether a specific protection is Access Control based or not?

I have looked for clues in the UI but found none. I will surely follow the_rock's advice to check the audit logs. However, I have doubts whether this is really something related to the specific Protection changed.

[the_rock]

@eranlif I just tested in the lab, but as per attached, installed on TP policy only.

I do have quesiton for @Amir_Senn however. I also do find it odd that when I tried pushing policy again and selected access control, showed 1 change, though I ONLY changed TP profile to be used...is that normal?

Andy

[Amir_Senn]

Try to repeat with TP profile without IPS. This might be the same thing discussed here.

[the_rock]

I will, though Im pretty sure that will be indeed same bahvior.

Andy

[Amir_Senn]

I marked them in the picture. You can see there are 39 core protections that this applies to AFAIK and they have an icon that has a small firewall in the corner.

[eranlif]

Thanks, Amir and Andy,

Indeed, my question stems from the fact that it seems like we can't anticipate whether a change in Threat Prevention policy will cause SmartConsole to prompt the user to install Access Policy.

Amir's explanation may cover some cases, but I think both Andy's test and mine show, that this phenomenon occurs in situations not related to Core protections, too. (Alternatively - our tests show that it's hard to anticipate when a change to Threat Prevention policy will result in a change to Core protections configuration...)

I think this is worth looking into, but black-boxing this does not seem like a good idea. 

[Amir_Senn]

I also tried something on my lab:

Created a profile without IPS:

Installed the new profile, changed definitions on the new profile and re-installed:

It doesn't look like this is made changes related to Access Control.

Lets wait for Andy's results or maybe point me in more specific direction and I will try to investigate further but I think IPS was responsible for now.

[the_rock]

Yep, I got the same.

Andy

[eranlif]

Thanks, again!

So, the verdict is "If the profile includes IPS then every policy installation HAS to include both Access Policy and Threat Prevention Policy"?

This make things somewhat more predictable (although the exact relation between a change to one IPS protection and updating the entire Access Policy is still a bit of a mystery for me)...

[PhoneBoy · Accepted solution]

There are only three instances where an Access Policy installation is required when making Threat Prevention configuration changes:

• Very first policy installation on gateway (Threat Prevention requires an Access Policy to be installed)
• When Inspection Settings are edited
• When a "Core Protection" is edited 

The reason this is necessary is because Core Protections and Inspection Settings are actually implemented in the firewall code.
Changes to that configuration require an Access Policy installation.

When you edit a Core Protection, SmartConsole explicitly warns you of this:

Same with editing Inspection Settings:

If you've identified something outside of the above circumstances, I suggest involving TAC.

[eranlif]

Thanks, PhoneBoy, Amir and Andy!

Based on PhoneBoy's explanation, it looks like what I'm seeing is, indeed, unexpected behavior by the system. (BTW, I would be very interested in a link to any docs you based this explanation on, if possible...🙂)

Based on Andy's original test and on testing the same flow on an R81 machine, it seems like this phenomenon is more widespread than a specific instance or version. I will contact TAC.

Again, thanks all!

[PhoneBoy]

SmartConsole explicitly tells you that an Access Policy installation is needed in all three of these cases.
If there are other cases (e.g. specific IPS protections that aren't "Core Protections" require this), I would expect a similar warning message to appear to ones I've shown.
However, there may be other IPS protections that are implemented in the firewall code (and thus need an Access Policy push).
Or it might be something else.

If you look through a Changes Report, I believe you'll be able to see which IPS signatures were modified as part of a session.
Each of these protections can be reviewed in SmartConsole to see if they have a similar banner to what I've shown.
If none of them have this banner, then TAC will need to investigate to understand why this is happening.

[eranlif]

Thanks.
Just to wrap things up - the images below tell the story:

I performed a single change in the Threat Prevention policy (Setting the action to Detect, for a single protection on a single profile), I then installed the Threat Prevention policy, only, on the gateway. The results were (1) No more changes to Threat Prevention need to be installed, but (2) SmartConsole "detects" one change on the Access Control policy.

There are more strange things here - The Revisions window shows changes that were made on 5/14/2025 - that is before the last installation (whether it is 5/16/2025 or 5/19/2025). In addition, a screenshot taken before installing the new policy shows the changes detected, and I can't really correlate between this info and the actual change I made (although this may be some internal DB elaboration of "Disabled->Detect"):

Performing the same flow on other SmartConsole (R81,R82) gives very similar results: A single change in an IPS protection causes SmartConsole to detect changes both in Access Control and Threat Prevention policies. The bottom line is that this behavior seems consistent and, at least for me - unexpected.

[PhoneBoy]

You said "a single change in an IPS protection" is made without really describing the IPS protection this was done on.
Is it the 7zip one shown in these screenshots?
Did you try this with different IPS protections also?

It looks like the change that was done (based on the screenshots) was to set the action for the IPS protection to "Detect" for the relevant protection.
Have you opened a TAC case on this yet?

[eranlif]

Yes. I repeated the test twice, on two different SCs, with the same 7-Zip protection shown on the screenshot, and then on a third SC with another 7-Zip protection. Previous tests were made on other protections. The tests were similar but not identical: Changing the protection action for a specific, randomly-selected, Protection-Profile combination.

I wait for a colleague to open the case, so I have some time for debugging... 🙂

[PhoneBoy]

TAC would have to elaborate if this is expected behavior, though I have not seen any documentation to suggest it is.