Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Application Control Rules and Rule Sets within an AC and DC policy

Created: 20 Feb 2013 • Updated: 01 Mar 2013 | 12 comments
This issue has been solved. See solution.

SEP RU2, Applicatin and Device control policy, Application control Rule Sets...........  There are "Rules" and there are "Conditions". For each "condition" under each Rule in a Rule set, there are multiple choices for "Actions" under the Actions tab as follows:

  1. Continue Processing Other Rules
  2. Allow Access
  3. Block Access
  4. Terminate Process

In a way, that's not too difficult to get or understand, HOWEVER, I'm confused as to exactly when or where a couple of them could or should be applied, and what are the consequences.

For example, the last 3 are pretty simple if taken on their own, but number 1 tossed in there leaves me wondering if not understanding full impact is part of our problems here.
Let's say I have 10 rule sets (actually, that's pretty close) - each with a different purpose. In the top rule set, I have a situation where I block process abc from touching any files in folder xyz with xyz\*- but near the bottom tell it to not apply to THESE files and define those. Then in actions - I could choose BLOCK.
Does it STOP with that and not process any other rules in this set, or does it stop and not process any other rules or rule sets at all? And if I choose "continue processing other rules" - uh, what does it do then? I'm not telling it to block, I'm not telling it to allow, I'm not telling it anything at all, just "continue" - so what the heck is the point of "continue processing other rules" since you've got this great condition defined in a rule set - but you don't tell it do to anything at all, just "move along to the next rule please".
What exactly does it do if I choose #1?

And if I choose 2 or 3, does it allow or block and then simply stop since I can not ALSO tell it to continue on?!?!?

I have NEVER used "continue processing other rules" because hey, if I do, then I can't tell it to allow or block! So what's the point?
And if I choose allow or block, does it continue on or not? And if it stops with THAT rule of ALLOW or stops after a BLOCK, then where does it stop - in THAT rule set, or does it finish that rule set and then stop, never seeing the remaining rules?

I don't want IE to automatically install plugins, helpers and so on, but DO want it to allow one in particular -  but with more rule sets and more rules, it's getting complex and things are not working - and worse, although we are sure it's SEP blocking this product, it's never logged

Comments 12 CommentsJump to latest comment

.Brian's picture

I've always seen "Continue processing other rules"  to mean "Ignore" and move on. You can choose to log it if you wish otherwise just ignore it.

if you choose Block or Allow, the action will be applied than move on to the other rules. Sort of like firewall rules with a "top-down" setup

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

ShadowsPapa's picture

That sort of makes sense - but maybe it makes sense to say that I have less than 1 single work day to "get this sorted out" and the product working with SEP.

So, I'd really like to see an example with explanation. Visual leaner - show me a picture, "this does this under these conditions, and it will do that under those conditions". Then it would be solved and the rest up to me.

The documentation in this area, again, like the other, isn't very clear or precise. The online help says "check one of these" basically, but no "if you check here, this will happen". Just like all the other help, they restate what you already know - you have these 4 choices, pick one. Sort of like the Redmond helicoptor tour pilot - has a group of tourists up when a storm with bad fog and poor visibility strikes. His instruments go out and they get lost in the sky. Then he sees a building and flies near it. They hold up a sign "where are we". The response from the building is "in a helicopter". Had to be the Microsoft building - technical factual and correct, but totally unhelpful.

Vikram Kumar-SAV to SEP's picture

Application control rules work similarly to most network-based firewall rules in that both use the first rule match feature. When multiple conditions are true, the first rule is the only one that is applied unless the action that is configured for the rule is to Continue processing other rules.

You can configure any of the following actions to take on an application when it meets the configured condition:

  • Continue processing other rules.

  • Allow the application to access the entity.

  • Block the application from accessing the entity.

  • Terminate the application that tries to access an entity.


Remember that actions always apply to the process that is defined for the rule. They do not apply to a process that you define in a condition.


Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

ShadowsPapa's picture

Yes, I understand the being like a firewall, however, a firewall has 2 choices, allow or deny. It doesn't have "continue on". You allow it, or don't allow it. If the allow is at the top, then a block later, it will allow - first rule found that matches the participants (local/remote etc)

It's the same way in custom IPS rules - I can set up a block rule to prevent IP range or address from sending and/or receiving packets containing a string " This will block any computers matching that IP address from sending or receiving packets with in the data. I can then make another custom IPS rule that says "allow" and put that first - meaning the computers matching that IP would be allowed.
But again - IPS does NOT have a "continue processing other rules" choice. it's block or allow, deny access or let it in/out.

What's the point of "continue processing other rules"? Firewalls and IPS have block or allow, that's pretty much it.

I can allow and log, allow not log, deny and log, deny not log.

But this app control has the added "continue" choice - for what when all needs can be covered with allow or block.

Why, under what condiitons would I want "continue.

FURTHER, it I choose continue - it won't block OR allow because there is no place else in that rule that determines if something is allowed or blocked - if I Choose "continue to process other rules" is it not the same as not having anything there at all? Did we tell it to block? No, we said continue. Did we tell it allow? No, we said continue, so since the default is allow, it would allow, I must assume, it's not been told to block.
IS THIS IT? Allow allows then STOPS, block blocks then STOPS, continue allows and moves on??

If block blocks then stops - where does it stop? With that condition in the rule set, or after that whole rule set is processed? The documents do not define any of this anywhere - not that I've found.

RuleSET 1
Rule 1
  Condition a
  Condition b
Rule 2
  Condition a
  Condition b

Rule SET 2
Rule 1
  Condition a
  condition b

If in rule set 1, rule2, condition a, it matches and is set to BLOCK, does it even look at Rule set 1, rule 1 condition b?
If in rule set 1, rule 1, condition a it finds a match and the instruction is "continue processing other rules", does it move to ruleset 1 rule 2, or does it move on to rule set 2, rule 1? What does continue processing other rules mean - in THAT rule set, or "you are done here, move to the next rule set"
This is not like a firewall - firewalls match, or don't match, and if they match, are told to block or told to allow. Which ever is first wins. This is more complex with an added instruction.

Here's what I would prefer to see - actually need, for an answer-  a flow-chart.
Show me one of those Visio charts showing/demonstrating "if this, then that, go to block B else go to block D".
Comparison to a firewall isn't really good as it's like comparing an all-wheel-drive vehicle with 6 wheels to a standard compact rear wheel drive car with 4. There's more to it. I get the block, and the allow - but when you say continue - continue to which level, and do what? Block or allow? or neither. A firewall doesn't do that......... it blocks OR allows. There's not 4 choices, there's 2. First rule match wins.
With app control we are left guessing and it's one reason I believe I'm one of the very few people who even mess with this part of SEP. I know of no one else in our state who has used this part - for one, they find it too complex. Really?  I've asked at our user group meetings - I get blank stares most of the time, or "you got that figured out did you?"
I know 3 or 4 years ago when I was a volunteer here I posted posts and articles showing how you could really control things, do things that the AV could not - keep things safe and secure even from brand new and unknown threats. At that time, no one else seemed to be doing that at all. Maybe that's changed by now, but I suspect I was the only one gutsy enough to give it a shot with no documentation.............. learn as I went, trial by fire.
I believe I'm finding that no one else here uses it as I've yet to see an "authoritative answer" if you know what I mean. No offense or insult intended, but I really need a hands-on experience and example - time is moving on, deadline is Thursday AM for getting these rules straightened out.

Vikram Kumar-SAV to SEP's picture

I am being pretty lazy here and going only by the official public document available (the help button below the Application control policy)..and I do remember your article from 2009..infact if i remember correctly it was written before Security Response best Practice rules were released.

So here's an example:


You want to prevent all users from moving, copying, and creating files on USB drives.

You have an existing rule with a condition that allows write access to a file named Test.doc.You add a second condition to this existing rule set to block all USB drives.

In this scenario, users are still able to create and modify a Test.doc file on USB drives.

The Allow access to Test.doc condition comes before the Block access to USB drives condition in the rule set. The Block access to USB drives condition does not get processed when the condition that precedes it in the list is true.

Now the File and Folder Access Atempts and Registry Write Attempt gives us more flexibility on what types of action we want to apply that is Different for Read Attempt and Different for Delete,Create and Write attempt.

So coming back to above example say in 1st Rule I for Read Attempt is say continue processing other rules and for Write attempt i say Allow.

and in the 2nd rule I simply block read and write for * to USBSTOR* then I will not be able to read test.doc but I will be able to create test.doc

..I dint go by your example as it got me bit confused..let me know if i was able to answer your question.

and yeah continue Processing other rules wont go to a different Rule is only for the seleted rule.


Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

ShadowsPapa's picture

Thanks for sticking with me on this - and I do believe you understand what I was saying or asking. I think what you are describing to me makes sense. At least enough parts of it I'm finally feeling like I am getting somewhere. Some progress has been made. I'm going to print your post and keep it by my desk, and as a reference in the documentation as so far it's the best explanation I've seen.

I would like to rephrase or restate this in my own words - to help me understand and to see if I REALLY have some of it understood now. (for the most part I've been doing it "ok" but I truly believe it can be much better, faster, leaner and cleaner, less confusing - thus all my questions)

What I think I see in this is that with "continue processing other rules" set for the "read", it is telling SEP's application control "I have this action defined below, move on for further instructions." where for the write, delete, etc. you define it right there, no need to move further.

And finally an answer that I have to say looks pretty solid and sure - you are saying that "continue processing other rules" is ONLY for that specific rule SET. if I have 10 other rule "SETS" below this one they run independently after this rule set is run and finished.

Now I'd like to clarify something - again, just to be sure. Please forgive me, it's honestly a situation I live with where there's a disconnect between what I know and understand internally and the outside world. (all this stuff in my brain is trapped - lines of communication are rough and rocky at best)
Real example - I have a rule set that blocks many risks by blocking BHOs - browser helper objects, and prevents malware from placing DLLs in the user profile area and running from places things should not be running from. This means iexplore.exe (IE) is blocked from doing almost anything other than browsing and such - you aren't likely to get any "drive-by" attacks through the browser with my custom app control rules. That's great, and it's really bad as it means that GOOD things won't work unless or until I define them and allow them.

So there's a rule set that blocks the browser from doing things we don't want it to do. I have certian "do not apply to these files and folders" inside that rule set. But that rule set is rather large now with all the good stuff defined inside it, and it is complex, messy, and some day it is going to explode and I'll have a real mess on my hands.
Can I define a rule set, place it ABOVE the "block bad BHO" rule set, and exclude or allow good processes in that manner?
Let's say I block IE from putting EXE or MSI files in the cache, and I block IE from running certain files or processes from certain locations. Wow, that works GREAT. But I want to allow this bluejeans meeting pluging to run and do anything it needs to do. It is also launched by IE, and triggers the msiexec.exe for initial install of the plugin. Can I make a rule SET, above the block bad bho RULE SET, and in the "allow bluejeans" rule set, define what I need to allow? Or, will it run through the allow bluejeans rule set, then hit the block bad bho rule set and end up killing it anyway?

I guess I'm asking - I know that INSIDE a specific rule set, each "condition" runs in order, first hit wins. What about between different rule sets - is it the same? If the rule set at the top says "allow" and a rule set below says block *, will it hit that lower SET and block?

Thank you very much - you have the best explanation I've seen to date - complete with some very nice examples and explanation. I can certainly see why over the last years your status has changed to what it is.  I appreciate your patience - I have incredible capacity to learn, it is jst that to do so, I have to see it in a specific way, typically picture and example. Reading a book is great, but seeing the movie, that's the best. It's an attention thing - I don't have any.

Vikram Kumar-SAV to SEP's picture


Firstly I would want you to go through
What it says is do not do anything more than 200..That is do not put more than 200 exe's for exception etc..
But this is taking into consideration you are monitoring for every process (*), but I have seen with monitoring just few processes like iexplore.exe in your case going above 200 will also not impact anything.
Even if you increase it exceptionally it will only impact performance if IE and no other process.
Continue processing other rules simply means Ignore this part of action.
In your case you will have to exclude it in all the conditions.
As I am not able to understand why would you create specific condition for allowing the blue jeans rather than excluding it.
If you create condition for allowing the bluejeans then you will have to create each type of condition for it.
Eg for condition terminate process have mentioned no other process should access Iexplore.exe 
here just putting the exe for blue jeans would be easy rather than creating 1 more condition for terminate process attempts above the current condition.
And you will have a create a new condition for allowing bluejeans before every type of conditions you have set.
You cannot create only 1 condition to allow blue jeans from everywhere in that RULE SET.
It would say put exclusion in every condition of every rule set that it monitoring iexplore.exe/Msiexec.exe
As I dont see a need of creating different conditions only to allow.
The conditions are processed top to down.

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

ShadowsPapa's picture

Thanks for the link, that is also helpful. I do see that I'm sure not breaking the bank with my setup - I am not even CLOSE to any limits!  All of that is good stuff to know.

200? More like 20 or 22 and some of those will go away as I clean things up, make them more tidy and better structured.. Inside of each rule set is also pretty small - the largest has 2 rules inside, each with 2 conditions under them. I try to pack a lot of punch in a small package.

Devices 1,000?  LOL - I've got a few, like 3 dozen maybe, and excluded devices is probalby only a dozen. I used wildcards to block devices - usbstor\*  and then allowed the tiny handful we want to allow. Specific definitions for blocking are few as well. The lists of devices is short, not even close to 1,000, probably not even 100.
I fully agree that it needs to be handled with great care. As with the custom intrusion prevention signatures, a simple typing mistake, miss a quote, mistype an IP address and the system can't figure out how to deal with it and you risk total loss of any control or use of any computers it gets to. I watch our system logs VERY closely for any errors from the SEPM servers when I work with SEP. I'm a bit paranoid - we can't work overtime and have to do things on live systems, a live network during production or work time.

Until this past week with that bluejeans plugin, the app control was really pretty simple, and pretty much under control. It just plain worked - and it helped us maintain our 100% malware/virus/risk-free status for 2 years. There is simply no way those fake AV things can get in, no way for malware to hijack and run inside the user profile.
I finally figured out some of the issues with the bluejeans software - they were not telling me everything, and in fact their folder structure was inconsistant, so once I discovered that, closed my door and rewrote the app control policies or sets, I got it to work. Then today's big test failed.......... I was shocked. Come to find out - after the BOSS called them, the link they sent for today's test wasn't with their released stable software but was using a beta plugin in which they changed the folder structure, folder names and file names. OUCH.
I need to tweak a few more things, and based on the fact that my AC rules were mostly put into place 2 or 3 years ago, and a lot has changed including moving FROM XP to W7, and new software, etc. - I need to go through the clean things up a lot. With your information, I can take what I have and make it a whole lot better.
I've actually already done that to some extent - in making things cleaner and easier to get this meeting plugin to work, we noted that that sort of thing in IE runs much faster than ever before. Just like most any code - clean it up, make it leaner, and the process that runs it can run it faster, more logic, more speed.

As for the other - I probably didn't explain it well, and was really only using a "what if" example. Not that I'd do it that way, but I AM trying to understand any interaction between rule sets - not inside a rule set, but between the top rule set and any below it for example. If the top rule set has things that allow xyz.exe to access folder c:\myfolder and rule SETS below that one say block *.exe from accessing c:\myfolder then is it actually allowed because the top rule SET allowed it, or is it blocked because each rule set is an entity until itself? I understand that the conditions inside a rule set apply top down, like a firewall policy, but can something in the top rule SET impact something in a rule set that is 2 or 3 down?
Since I can have a list of 20 rule sets in a single application control policy - do the rule sets interact, or is it all contained within. Rule set 1 in the end says block process A from launching c.exe but rule set 2 just below that one says allow all processes to launch c.exe
I know that inside rule set 1 if a condition says to block, then a condition BELOW that still still in rule set 1 says allow, it would be blocked as the upper condition was the first match made.
I'm not saying things are that way, but could be........... and need to know so I can document it here, and to make sure there's no conflict between rule sets, inTERset as it were, as opposed to inTRAset, which I know how that works.

In any case, I appreciate the help a lot. I will not be at work tomorrow, I have it off, and with a big winter storm heading this direction now as I type, I'm not sure what today will bring as far as further work on this, but it will continue next week, Monday for sure. I'm not sure where you live so when I say Monday, etc. - I realize it could mean the same, or a different day. Every time I work with the web host that hosts my auto forums, I have to rethink my days - he is in the U.K. and I'm working while they sleep.

Vikram Kumar-SAV to SEP's picture

First lets keep no confusion between Rule Sets and Rules/Condition (for any third person reading it)

Rule Set eg : Block Applications from Running, Block writing to USB Drives, Block access to Autorun.inf

Rule/Condition: Within Block application from running when you edit the rule and on the left hand right click you get option to either add additional rule or addtional condition for the existing rule different conditions are FIle and Folder access attempts, Load Dll attempts, Launch Process attempts etc.


Now If you configure a Particular Allow or Continue Processing other rules Action within a rule rule st that is within "Block applications from running"

it will be only for "Block Applications for running" and will not interfere with " Block Software Installers" or "Block File Shares" Rule Set.

The Action condition will only be valid for all the rules and all the conditions within "Block Applications from running"



Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

ShadowsPapa's picture

That is exactly what I was looking for. Each rule set is an entity unto itself - it is stand-alone, like having multiple firewalls, one after the other, it's "first match" inside that firewall, but any allow in the first doesn't have impact on subsequent firewalls if they block later, it's blocked by one down the line even if allowed by the first rule set.

You did pretty well describing it - perhaps if I had used pictures for the first time it might have helped.

In these examples below, I wanted to be sure that something in rule 1, for example, didn't have any impact at all on rule 2, 3 or 4
So (for others watching in) I go to the application and devicer control policy assigned to the group I am managing and wish to change - and choose this one:


Then I go to application control and see these (there are several more, this is a small example) ->


Each of these is a "rule set" - or a set of rules that is self-contained according to the responses I've received here. If I make a change in rule 1, it would have NO impact in rules down the line as each is a rule set and is like a stand-alone firewall - for applications. If I block something in rule 2, however, rule 3 or 4 would never see it. But if I allow it in ruleset 1 or allow it in ruleset 2, ruleset 3 and 4 would see it, and could later block it.

So the only impact something done in the top or upper rule sets would have on later rule sets is if something is blocked up high, the later rule sets would never see it. But if it's allowed, it's still possible for later rule sets to stop or block it.

If I allow abc.exe to run and launch DLLs in rule set 2, I could still block it later in rule set 4. Perhaps the second rule set allows abc.exe to run in folder a, folder b and folder c, but I can later say in rule set 5 I want to prevent abc.exe from launching a process in folder b.  Even though allowed in rule set 2, rule set 5 could block it. But if it's blocked in rule set 2, rule set 5 would never see it to allow it.

That pretty much matches some of the things I've seen where I've made mistakes - and it's a GREAT reason that SEP application and device control users should not only NAME the rule sets so they make sense, but inside of the rule set, assign some sort of numbering system.
Call this a "tip" if you want, but it's saved my skin a number of times when troubleshooting app and device control............... the logs will show exactly what part of a rule set took action, and if you have them numbered besides the names, it's a piece of cake to figure out what happened and what needs to be changed if something was blocked in error!


I think I have gotten the answer I was looking for - and if Vikram believes I have it understood, we'll call this "solved".
|Sometimes the lack of information or the lack of understanding a feature is a problem even if SEP isn't broken, not "getting" how things work in detail can mean the same as broken. I thought I had it understood, and in the end I "sort of did", and things actually worked as far as accomplishing goals, but it was getting too complex and to make this other app work wasn't turning out very well. The biggest problem was lack of information from the other VENDOR, but now that I have pushed and gotten the information I needed from them, combined with an even better understanding of the app control process in SEP (not really all that well documented but that's another thread), we'll be fine now.
I've been using this part of SEP for years - it even allowed us to drop other products. It has blocked or prevented infections other agencies suffered. With more info on this SEP feature, I made it so the app not only worked, but loading it was lightening fast compared to some other browser related stuff. Fine tuning these rules should speed things up. I was using the right tool - but now I can sharpen the tool and make things better..

Vikram Kumar-SAV to SEP's picture

You have got it right..and very well pointed that naming convention is very important and it really comes handy when testing the rules, even the Notifications should be kept different it mkaes it easier to understand  which part of the policy just got trigerred.

I would say for majority of the poeple using Application and Device control the built-in rules are enoguh and in SEP 12 symantec even doubled the number of built in policies.

But the real strengh of ADC policy is understood only when you customize it. It has the power to give you the complete control of your machines.

Very similar to Firewall policy, System Lockdown Policy, Location based policy, HI policy or the most feared custom IDS Policy.

The more you play with them the more you understand the power of SEP.


Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

ShadowsPapa's picture

These features are a big part of my like for SEP. The custom IPS signatures allows me to cover us in event of "unknowns" or risks that IT Enterprise or the ISO warns of something "new coming along". If they have even parts of possible URLs, I can block. And with Akaimi it's nearly impossible to use a firewall to block specific targets these days. I found early on if you wanted to block "ebay" for example (just an example) you ended up also blocking thanks to "IP sharing". The state has an Akaimi (sp) server so just because you see a certain IP address coming through doesn't mean it's who/what you think it is. The custom IPS means if I wanted to block (again, just an example) I could block and not anything else that might end up resolving the same.

I've got a lot of the customer IPS rules in place. We needed to allow facebook for a few, block for all others, it was pretty simple if the few we wanted to allow had a static IP. Two quick custom IPS sigs and we were set. Blocking online radio (a bandwidth killer for some offices) was not too bad....... although it's typically port 80, they still have to get to certain URLs to stream. And in most cases, I can allow them to visit the radio station's web site for job listings for our clients, but block the streaming as that's a bit different url there. Can't catch them all, but got most of them.

You have just given me an idea for one of our upcoming user group meetings - I can give a talk on using the OTHER features of SEP - those seldom used, often feared, or otherwise unknown parts that help to close the gaps traditional methods leave behind....... those parts that allow us to customize SEP to our own individual needs as an agency.

We were able to get rid of another product that handled our hardware control - specifically USB. I can allow USB printing, for example, but block the smart card ports in the printers. I can block use of personal USB devices, but allow use of state-owned USB devices, down to the INDIVIDUAL device!

Need to see what's leaving on USB devices just in case of data loss or theft? A combinatin of app control and device control allows you to control what devices can or can't be used, and monitor certain types of files copied to, or read from usb devices. I can log any Word document put on a usb device.

With all the JAVA threats and bad versions, I was able to allow JAVA to function UNLESS it was a risky version and in those cases, I was alerted. Have users who love to play with fun toolbars that they are told will save time and are absolute musts? You can either block them, or you can block them from sending messages back to home base about user movements and habits. Let part of them work while killing the part that phones home with your usage info.

OK, that's my promotional bit for SEP. Back to business - thanks for the clarification on these things, the links (and I've printed that info and put it in my huge SEP manual) and I consider this not just answered, but well answered.