Endpoint Protection

Hi,

The policy I'm using is a simple File and Folder Access Attempts policy with Allow and Logging selected for both Read and Modify/Delete/Create options.  The selected area I am montioring is ' %windir%\system32\* '.

A number of SEP processes are coming up quite regularly so I have put them into the Process Exceptions field in the policy, makeing sure the policy is actually on the machine I'm testing - but I still get the processes being logged.

For example When looking in the Logs (Monitor>Logs>Application & Device control>Application Control) area I can see that a Caller Process named C:/Program Files/Symantec/Symantec Endpoint Protection/Smc.exe is reading a DLL file in my System32.

I export the Log file then cut and paste that exact line into the 'Do not apply this rule to the following processes:' field.  However it still comes up even though I have confirmed that the client has got the new updated policy.

I've got ' * ' (wildcard) in the field above i.e. 'Apply this rule to the following processes:' and I have ticked the 'Sub-processes inherit conditions' box.

It's really annoying - HELP!

https://www-secure.symantec.com/connect/forums/questions-about-shadows-application-control-exceptions

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009022412404548

Yes - that solved it.

How backward is this product!? You don't add the exceptions in the exceptions box in the application control policy, you need to enter it in the Centralised Exception policy - what a crock..

NO - this did not resolve it - I am still getting processes that come up that are in both the application control policy (as an exception) and the centralized exceptions policy (tamper control).

BOO   :-(

Hey Mat, we are still trying to break the code on this. I am beginning to think that there is a bug in this functionality. We have explicity allowed many processes however the application device control policy continues to block stuff. File level exceptions / DLL Exceptions work without any issues. If we could get this working FAKE AV would not stand a chance. Anyone with some ideas on what I may be wrong would be much appreciated.

Hi guys,
 
At the moment I'm also trying out application control.
 
@STF: Do I understand it correct, that the "Process Exceptions for Application Data Folder"-rule should work as a white list for the “Block EXEs and DLLs Located in Users Profile“–rule?

@Mat: Are there probably some other rules in the ruleset that block smc.exe?


My major fault at the beginning was to think, that processes that are allowed in upper rules in the list, cannot be blocked by lower rules. But the order in the list is just an order of what rule SEP will check first and not an hierarchy.

delete plz

Hey Guys, the top component of the policy is designed to catch stuff and allow it to happen before we get to the blocking component. I tried making process exceptions in the blocking component of the policy and that does not work either. This is really frustrating because support could not give me any really good idea as to why it was not working. They tried to tell me that environmental variables are not allowed in the process exception list however I am pretty sure that they are supposed to be. Many different oppionions regarding how this is all supposed to work. I can send more screenshots if anyone is interested. I owe all the credit on the base of this policy to ShadowsPapa. I was hoping he could chime in on this whole thing at some point.

On second thought here are screenshots of the whole policy.

The top rule is not necessary. As I Said the order of the rules is just an order of what SEP will check first.

You need to add the processes in the upper rule into the "Do not apply this rule to the folllowing processes"-field of the blocking rule. Make sure that you haven't mixed rule and condition.

If you want C:\Program Files\Microsoft Office\OFFICE11\winword.exe to be not blocked, you need it to add to "do not apply.."-field in the "Block EXEs and DDLs Located in Users Profile"-rule.
If it is still blocked then there is something definetely not ok.
Can you give me one of the worng loged entries?


One word to environmental variables: Be very careful with these, I just crashed one of my Windows 7 test machines because %userprofile% was at the startup construed as C:\.
The result was, several processes in C:\windows\system32 where blocked at the startup and I get a bluescreen.

Orginally I had all the processes that I wanted to exclude in the (Do not apply this rule to the follow processes) field of the rule and it did not work. I thought by having an explicit rule that allowed the processes that I want I would be able get this working properly. So to clarify you are suggesting that I just can the top rule "Process Exceptions" and try to get it working with exceptions specfied soley in the blocking component of the rule? I can try it again however I still think that there is something not quite right with the process exclusions.

Yes that is the way how it should work.

If it still does not work, plz send me one of the logs. I just need the API Class, caller process, and parameter of the log entry.

OK I will change the rule and let it run for a day. If it does not work I will export the log right out of the SEP Console.