Creating Custom Policies for the Cisco Security Agent
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Cisco Security Agent (CSA) is an extremely flexible product that has granular policy enforcement capabilities. Included as part of the product installation on the management server is a suite of preconfigured policies that can be deployed to provide immediate protection and control. These policies are a great start and in many cases provide the security required by organizations. In addition, some minor tweaking might be required to allow for approved system use. If you are familiar with the flexibility and applications of the CSA product, you can extend the base capabilities to solve many host security issues in your deployment. In this chapter, you learn about:
- The importance and basics of tuning CSA
- Rule capabilities
- Importance and usage of state sets
- Using dynamic application classes
- Basic forensics
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 controling certain application usage— Your organization might want to prevent or control specific applications, such as P2P files sharing applications, instant messengers, e-mail 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.
Forensic Data Gathering
Because CSA continually monitors system interaction on endpoints in your environment, you might want to leverage this product to report certain interactions you find interesting. By creating a specific set of rules that monitor interaction, you can create a "Honey Pot" policy that when deployed reports interaction of specific processes for you to acknowledge. Monitoring system interaction or at least specific interaction can provide an early warning system that can alert you to suspicious activity before it becomes a real security issue.