Sample Custom Policies
As with most events in life, seeing is believing. You need to be able to use all the CSA MC policy objects effectively. This section illustrates a few examples of how to build custom policies to assist in constructing your basic skills in this art.
State-Based Policies
As discussed earlier, state-based policies can be powerful. Using states can be an effective way to lighten policy enforcement on a single machine temporarily without completely degrading the entire deployments security permanently.
Install Technician Agent Control
Often, you encounter the need to allow a local technician of a system to perform actions that would not normally be allowed to the system user. This could be a technician's manual installation of a software package or hardware driver. To accomplish this, you can either use a state-based set or place the system in a special group or test mode so that the installation can be performed. The problem with the last two options is that the CSA administrator would need to be involved in every daily task. In addition, it's possible that the security is completely removed in test mode rather than just slightly degraded and controlled. In this example, we use the following procedure to start to configure the objects.
- Create a user-based state set named INSTALL-TECH that matches a local group with the same name. This is effective only if you have a group called INSTALL-TECH on your system and have a user in that group perform the installation. This state set is displayed in Figure 9-4.
Figure 9-4 INSTALL-TECH State Set
- Create a policy named Install Allowed Policy and also a rule module named Install Allowed Rule Module. The rule module should be enforced only when the INSTALL-TECH state set matches. The configuration for the rule module can be seen in Figure 9-5. The rule module should be associated with the policy.
Figure 9-5 Install Allowed Rule Module with State Set
- Insert the following rules in the rule module. See these rules in Figure 9-6.
Figure 9-6 Add Necessary Rules to the Rule Module
-
Agent UI control— Allows the agent to become visible to the install technician.
-
Agent service control— Allows the agent service to be stopped by the install technician.
-
Agent UI control— Allows the agent to become visible to the install technician.
- Attach the policy to groups as necessary. At this point, an install technician should be able to log in on any system that carries the policy and install software. They can receive query messages and stop the agent service when necessary.
)
)
)
Remote Registry Access
It is not unusual for certain systems in your environment to attempt registry access to workstations for various purposes. To allow this access, yet not open up remote registry access to all systems, you need to use a user-state set. Follow these steps to create the policy required to accomplish this task.
- Create a user-based state set named MGMT that ties to a group that the user who will attempt the remote access is a member. When a user who is a member of this group authenticates to the remote system, the state set will match and your rules will temporarily apply to the system.
- Create a policy named Remote Registry Access Policy and a rule module named Remote Registry Access Rule Module that you can associate to the policy. This rule module should be enforced only when your state set matches on the system.
- As shown in Figure 9-7, add a Registry Access Control rule to the rule module that allows <Remote Clients> to access all registry keys.
Figure 9-7 Remote Registry Access Rule
- Apply this policy to the correct groups.
)
Remember, if you apply this correctly, you allow access to the registry remotely only after a successful authentication of a specific user or group member. This is much more secure than allowing all access to the registry at all times.
Securing the System When Away from Home
When systems connect to your network, corporate firewalls, intrusion detection systems (IDS), intrusion prevention systems (IPS), and other security devices protect them. When they disconnect and travel to remote networks at coffee shops, hotels, or even their home, they lose all that protection. Therefore, it might be desirable to raise the level of network security enforced on these systems when they travel abroad. In many cases, endpoints run many services that listen on the network, such as mass deployment and system management software, remote control packages, file sharing, and web servers. The following example creates a system state set and a policy to help you lock down your systems when they leave your premises.
- Create a system-based state set named OFF-NET that matches IP addresses that are not part of your address space. Also, be certain that the CSA MC is not reachable as shown in Figure 9-8. When a system does not have an IP address you own and also cannot reach the CSA MC server, you can assume that the system is not local.
Figure 9-8 OFF-NET Systems Set
- Create a policy named OFF-NET Protection Policy and a rule module named OFF-NET Protection Rule Module that you can associate to the policy. Enforce this rule module only when your OFF-NET state set has matched on the system.
- Add the following rules as displayed in Figure 9-9:
- - Add an NAC rule to the rule module that denies all applications from acting as a server on all TCP and UDP ports. This should be enforced only when you are not connected to the corporate network.
- - Add a Network shield rule that prevents all malicious packets and various scanning mechanism but does not log the messages. Your systems are guaranteed to be scanned and see some of the worst the Internet can throw at them when they are off your network. It is therefore advised that you do not log these attempts as you have little recourse when the host is miles away from any protection you can provide. Additionally, you are not likely to receive these messages until the host next connects via remote access or locally, which most likely guarantees you would be too late to react.
Figure 9-9 OFF-NET Rules
- Apply this policy to the correct groups.
)
)
You can add any other rules that would control the system when it is not attached to your network. You might decide that no client connections should be made out of the system except virtual private network (VPN) initiation back to the corporate facility for example.
NAC Policy
If your company decides to implement Cisco NAC, you will find it advantageous to use the CSA to complement the solution. You can use the NAC posture token returned by the Cisco Access Control Server (ACS) Policy Server to match a policy and therefore cause an additional policy to become effective. This example uses the pre-defined Cisco Trust Agent Infected Posture system state set to determine when the NAC server deems your system infected. After you have matched that set, you initiate a rule that does not allow e-mail applications to start other applications, such as viewers.
- Create a policy named NAC Infected Policy and a rule module named NAC Infected Rule Module that you can associate to the policy. This rule module should be enforced only when the Cisco Trust Agent Infected Posture system state set has matched on the system. View the system state in Figure 9-10.
Figure 9-10 Cisco Trust Agent Infected Posture State Set
- Add an application control rule to the rule module that prevents e-mail applications from starting any other application as displayed in Figure 9-11.
Figure 9-11 Application Control Rule
- Apply this policy to the correct groups.
)
)
You can add other protections if desired, such as limited network connectivity. As you can see, this type of configuration can alter the endpoint capabilities if the NAC process deemed that you are infected or quarantined. You would then have limited capabilities until you brought the agent-protected system back into a compliant state by using an endpoint management product, such as the BigFix Agent, at which point the system policy can revert to its original policy.