DO NOT apply the prevention policy in Enforce mode.
Globally disable the policy (upper left hand corner, hit the green switch) THEN apply. Then watch the logs as they roll into the manager. Anything that is in BLUE would have been blocked if you had not disabled prevention.
Watch the logs. Investigate the blocks that would have occurred if you had prevention enabled (the events that are in blue). Ask yourself "Are these blocks nefarious?".
As a rule, I would assume all blocks are "Guilty Until Proven Innocent". Use Google, and your knowledge of Windows/Unix. If necessary, create a sterile lab that has NO network access and install everything by hand (in case a gold Image has been corrupted, which I have seen happen) and see if you still see the bad/blocked behavior.
This is the crucial stage of the CSP rollout process called "Policy Tuning". If you do this wrong, you can render the product useless.
Remember: Guilty until proven innocent.
Here are four classic errors that happen with Policy Tuning:
- Allowing behavior that should be blocked. Basically, when this is done, it allows an attack. Often this occurs because the person tuning CSP thought that the policy was too noisy, or it was too hard to research the source and ramifications of the behavior. Don't do this.
- Allowing the blocked behavior for the whole default_ps Process Sets (PSETs). This is not good, because ANYTHING that does not get assigned to a process set gets assigned to the default. This includes viruses. You should not tune the default PSET unless absolutely necessary. Use the custom process set feature to create your own.
- Adding applications to the safepriv_ps or fullpriv_ps. Anything in the Full Priv PSET will be ignored by CSP, as if CSP was not installed This should rarely, if ever, be used.
The SafePriv process sets are given FULL access to the system, except for the CSP files, processes and registry keys. When using SafePriv, CSP is protected but nothing else is.
- Using the event wizard to "quiet" CSP without knowing what the choices offered in the Event Wizard mean. If you don't know, investigate. It is much harder to find and undo exceptions then it is to properly investigate before you allow the behavior.
Remember that you are basically profiling the machines that you install this on. You will learn more about these machines that you install CSP on then you thought possible.
On each block you come across, ask yourself "What is the worst thing that could happen if I allow this behavior?" If you do not know the answer to this question, or are unsure, do not allow the behavior.
There is a chance that you will find a real live genuine infection/intruder when going through this process. Do NOT just brush off the blue (would have been blocked) events, as you just may have found something you do not want in your environment.
Use the custom process sets to pull out applications that are known by you, but are not in the out of the box policy (like homegrown applications, etc). Use the custom PSETS to control these applications.
A lot of people use consultants to intially set up their environment. If you are unsure, I would suggest contacting one. I am sure someone who does this will chime in here soon.
The benefits consultants bring are 1) Experience in the field 2) Experience with deploying CSP 3) The knowledge on what constitutes good and bad behavior, as they have most likely seen it before. Don't be afraid to bring on someone who has done this before.
Note: This is a VERY brief description of the journey you are about to take. Make sure you are ready, or at least practice in a lab before you just throw this into production.