CSA 4.5 User State policy

[rvaguilera]

What is the best way to create a policy in which all local admins or service accounts can NOT have security policies applied?

In other words, a host has CSA 4.5 installed. If a "regular" user logs into the machine, protection mode is enabled and security policies are enforced.

But if a local or domain admin logs into the same machine security policies are not enforced. Or if a process needs to execute under a particular service account security policies are not enforced.

4.5 has the ability to create user-state policies, what's the best way to go about doing this?

[smalkeric]

The following links talks about the creation of CSA policies.

http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/csa/45/45usr/

http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/csa/45/45usr/chap4.htm

[rvaguilera]

any other suggestions?

[alanholmes]

Try this link

http://www.cisco.com/en/US/partner/products/sw/secursw/ps5057/products_configuration_guide_chapter09186a008042482b.html#wp1067757

[rvaguilera]

alan,

that link is unreachable.

[tsteger1]

Try this one...

http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_book09186a0080422f08.html

Tom S

Remember, please rate all (even old) helpful posts so others can benefit.

Thanks

[rvaguilera]

Yes, I've read that chapter in the documentation first, but it doesn't show any good examples.

I know how to create a user state and I know how to create rules that will only be applied if that user state is met, but let's say I'm using the default desktop group/kit. It has some good default policies and rules. I then create an exception policy with the appropriate rule modules/rules for my particular organization and add it to the default desktop group.

Great, now I create a new rule module (since the User State check only applies to rule modules), let's call it "Allow All for admins" and add it to my exception policy. But since rules are "additive" in CSA what do I do?

Do I have to replicate every rule that is attached to the default group/kit and do a like a "high priority allow"?

I basically just want to negate or disable all the "block" rules when an admin is logged into the machine, or when a service account needs to run a process, etc.

I'm sure many organizations have desktop personnel that are constantly installing/uninstaling software and troubleshooting. But with CSA being VERY "secure" it can become a crutch. Right now I have my exception to allow the UI to be displayed when an admin is logged on, and hidden when a regular user is logged on. This helps but the admin still needs to open the UI and turn off security. It would be nice to streamline this even more and just say, Admins can do whatever. I was hoping this new User State feature in 4.5 would help, but it is not as straight forward as it seems.

[alanholmes]

try this one

http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_chapter09186a008042482b.html#wp1067757

basically it is in "Using Management Center for Cisco Security Agents 4.5" the chapter called Building Policies and the section User State Sets

[rvaguilera]

Yes, I've read that chapter in the documentation first, but it doesn't show any good examples.

I know how to create a user state and I know how to create rules that will only be applied if that user state is met, but let's say I'm using the default desktop group/kit. It has some good default policies and rules. I then create an exception policy with the appropriate rule modules/rules for my particular organization and add it to the default desktop group.

Great, now I create a new rule module (since the User State check only applies to rule modules), let's call it "Allow All for admins" and add it to my exception policy. But since rules are "additive" in CSA what do I do?

Do I have to replicate every rule that is attached to the default group/kit and do a like a "high priority allow"?

I basically just want to negate or disable all the "block" rules when an admin is logged into the machine, or when a service account needs to run a process, etc.

I'm sure many organizations have desktop personnel that are constantly installing/uninstaling software and troubleshooting. But with CSA being VERY "secure" it can become a crutch. Right now I have my exception to allow the UI to be displayed when an admin is logged on, and hidden when a regular user is logged on. This helps but the admin still needs to open the UI and turn off security. It would be nice to streamline this even more and just say, Admins can do whatever. I was hoping this new User State feature in 4.5 would help, but it is not as straight forward as it seems.

[rvaguilera]

bump

[mwong]

Since some of these features are new, I suspect most people are still trying to find the best way to do things. Having said that, this is what I think.

1) you don't have to replicate every deny rule and change it to allow. If you create a few allow rules and allow "All Applications" to r/w all, invoke all, modify all registry, etc., that should allow most installs/uninstalls.

2) you may also be able to use the "Software installation in progress" system state to make it easier for your admins to install/uninstall stuff. You'd still want one initial prompt when an admin is logged in and performs software installation. But when a machine has both admin user state and software installion, then you can be permissive. Let me know if this works as I haven't implemented it myself.

[jeffasher]

See if this procedure will do what you want:

1. Make copies of all of the rule modules in use by the desktop and append or prepend ADMIN or something similar to the cloned modules and place all of these modules in test mode.

2. Modify the original modules to use a new user state called "Not Admin" or similar. This new system state should have "Administrators" in the Groups Matching: but not: field.

4. Modify cloned ADMIN modules to use the "Administrators" System State.

This way, the normal users will have no change in poplicy enforcement, but the normal policies will not be applied when an administrator logs in because of the "Not Admin" user set. When an administrator does log in, only the test mode modules should be applied. I can't think of any easier way to do this.