Time for the continuation of ESET basics and practises with this part 2 post.
If you have not read Part 1 yet, you can find it here.
This second part will go more into basic policies, their way of applying and some basic practises.
These basics will not go into specific settings and/or details, but will mostly discuss the logic behind them.
Specific policy settings will also not be looked at in detail.
As this is both way easier as well as totally different compared to Kaspersky policies for example, I will need to explain the logic behind the policies with ESET Security Management Center.
Let us begin.
First, I will start by explaining how the stacking system works that ESET uses for policies.
The idea behind it is simple.
You have a base policy. This policy includes all basic settings that you want all of a certain device to have (You will have multiple base policies as one is needed for each device type (Server/Desktop/Macbook etc.) and/or other versions of ESET).
You can either run all base policies over all devices or specific OS-types by using the dynamic groups.
Policies are only applied to devices with compatible software, regardless of what policies we set to run over it. There is no disadvantage of running a policy over all devices (Though using the dynamic groups will avoid cluttering of policies in the configuration list on the device)
Within a policy, you can enforce settings by turning on the blue dot in front of the setting. You can do this for multiple settings in one go by using the dot on the right top instead.
Enforced settings can not be overwritten by any policy unless there is a different policy laid on top that also has settings enforced. Settings are always taken from the highest layer (Lowest order) policy that has them enforced. Keep reading for a better understanding on how this works.
It is recommended to have a base policy with everything enforced and lay additional policies over them with only changed settings enforced.
To make the above statement clear, let us look at how layering works.
First, we have a base policy that is laid over all devices it is compatible with. This is as a white sheet of paper on a table.
You might want to make changes to the policy for specific groups/customers/devices etc. so you will have need for a separate policy.
The way this works is that, when the moment this is desired, you will want to make a new policy.
This policy is by default not enforced, so it can be seen as a transparent sheet of paper.
At this point you can make a change to the new policy (For example, turn off the firewall) and enforce that specific setting. This way, this becomes a white line on the transparent sheet.
You can lay this new policy on a group and all it will do is take all the enforced settings of the base policy and only add the enforced settings from the new policy that is on top of it.
This allows you to make changes on group-/customer-level while still making sure that any changes made to the base policy will also be spread to all devices (Unless being overruled by a policy on top of it).
This is a big change from the way Kaspersky and some other anti-virus products which require the use of fully separated policies meaning at those, either you will have to change something for all devices in the entire Security Center or use separate policies which will force you to have to adjust every single policy separately.
By default it lays it down in the order of biggest scale policy -> smallest scale policy (For example, "All"-based policies will be applied before policies targeting smaller group or single devices).
The order can be seen in Applied policies on the device information.
Do realise that the higher a policy in the order, the lower it ends up (basically, the policies at 1 or 2 get placed first and thus higher numbers get laid on top of those)
To give an example, in above picture first a base policy becomes active (order 2) and then a policy with a few changes gets placed on top of that (order 3) meaning the endresult will be a combination of the base policy with added changes (Settings enforced in the policy on #3) from the smaller-scope policy.
You can see the endresult in the "Configuration" tab also visible in above picture.
Hereby a visual example to make it all clear (The orbs indicating (non)enforced settings):
This allows you to make specific differences without having to make changes in 50+ policies every time.
Also an important feature of the ESET policy is the override mode.
The override mode allows someone to temporarily change policy settings through the GUI on the end-device for testing purposes (Ofcourse only if they have the required credentials that you have set).
It will then be possible to for example turn off the Firewall from the GUI on the end-device even when it is enforced to be on. After a set override time (for example 4 hours) , however the policy will revert back to its original state and the Firewall will turn itself back on.
This is perfect for testing out settings when something is not able to connect or being blocked.
This will be all for today.
More information on ESET ESMC will come somewhere in the future.
Categories: ESET, Basics, Informational
Patrick Berger AKA Powershellder.
[ i ] Parallax section below. Click on the section below to upload image. Don't worry if it looks weird in the Weebly editor. It'll look normal on your published site.
To edit or delete your image, press the "toggle" button below. Then, hover over your image until a popup appears with the "edit" and "delete" options. If you don't want a white content section, leave it blank. It will disappear on your live website.