This chapter excerpt explains two key processes for administrators who need to adjust or change Cisco Security Agent default policies. Learn about the normal tuning process and writing application control policies in Chapter 9: Advanced Custom Policy, of Advance Host Intrusion Prevention with CSA, by Jeff Asher, Paul Mauvais and Chad Sullivan.
Why Write Custom Policies?
There are several reasons for adding to or changing the default policies that ship with the Cisco Security Agent Management Console (CSA MC). The most common and simplest reason for change occurs during the normal tuning process. The second most common reason for change involves writing custom application control policies to better secure your system. The final reason to change policy is to perform forensic data gathering across the deployment.
The Normal Tuning Process
The normal tuning process occurs during every CSA deployment and continues after deployment when software and patches are added to your systems. These custom policies are often called exception rules, which are rules the administrator creates to allow normal system and application interaction to occur. Often, this also includes changing rules that query the user into straight allow rules that require no interaction. This means you not only tune the policy to allow specific use but also streamline and simplify the user interaction with the agent, so it does not become a nuisance. If the product becomes too cumbersome for users, they tend to attempt to circumvent the security measure, which would completely go against your goals.
The following are a few reasons to create exception rules:
- Installers --You likely have a standard process for installing software in your environment, such as using login scripts and software deployment tools. It is important to allow these processes to maintain your systems unimpeded without user interaction and without weakening the security of your endpoint.
- Application memory usage -- Many poorly coded applications (or cleverly coded, depending on your frame of reference) might attempt normal data or stack memory access or even attempt to access memory used by another process. You might need to allow these applications to perform this action for them to function correctly.
- Code injection -- Some applications attempt to insert themselves or DLLs into other processes as part of normal usage.
- Network access -- You often need to tune systems to allow inbound and outbound access to services on workstations and servers. This can include remote control applications and other network services, such as FTP, TFTP, TELNET, SSH, and HTTP.
Custom Application Control Policies
In addition to creating exception rules for your policy, you also need to craft additional policies that control how other applications are used in your network. Many of the policies written in CSA that control applications are a direct result of your written security policies and acceptable use documents that the users acknowledge. CSA allows you to take the verbiage in these documents and place actual enforcement controls on the systems rather than hoping that your users follow the rules.
Examples of reasons you might write custom application control policies include:
- Preventing or controlling certain application usage --Your organization might want to prevent or control specific applications, such as P2P files sharing applications, instant messengers, email applications, and remote control products.
- Limiting system network exposure --You can institute policies that control which services are available remotely when you connect to the corporate network rather than at a remote, untrusted location. Examples of such connections include a user's ISP connection, a wireless hotspot, or a hotel network.
- Administrative policies -- You can create policies that limit which users and systems can access administrative tools and also provide higher levels of access to administrative users (or any other users or groups necessary).
- Application installation policies -- You can create policies that allow CSA to permit mass deployment products to install software unimpeded (examples of mass deployment products include those available from BigFix, Microsoft, and Altiris). Other manual installs can either interactively prompt the user or be denied completely.
Want more from Advance Host Intrusion Prevention with CSA? Download the rest of Chapter 9: Advanced Custom Policy.
This was first published in July 2006
This was first published in July 2006