Understanding Cisco Security Agent Components and Installation
- General CSA Agent Components Overview
- CSA Installation Requirements
- Agent Kits
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter covers the following topics:
- General CSA components overview
- CSA installation requirements
- Agent kits
The Cisco Security Agent (CSA) is a complex architecture that can enforce enterprise security policies by granularly controlling endpoint behavior. Although technical and security expertise is required to configure, control, and monitor the deployment, it takes very little remote user knowledge of such topics to successfully use the product. In most cases, users have very little interaction with the product and typically are completely unaware of the protection the product is providing their system. Occasionally, the local CSA prompts the user for a response regarding an action that might be normal or malicious or even displays temporary balloon messages to the user about actions that are taking place. In general, however, you should keep the interaction between the user and CSA at a minimum, and generally the user will continue unaffected by the dangers lurking on the network.
Other than the installation of the product, which can be scripted through various methods, the user may never need to interact with the product if that is the desired outcome. Through the application of effective tuning mechanisms, discussed in Chapter 12, "Creating and Tuning Policy," you can get the implemented policy to a point where protective mechanisms are enforced and yet users have no interaction with the product at all. Security administrators use the CSA MC to configure all parameter assignments of the agent and its personalized policies. Optionally, as a new feature in version 4.5, the administrator can allow end users to view and use an advanced user interface (UI) that allows the user on the endpoint to control some of the policy enforced on the local workstation, such as personal firewall rules. If that is not desired, you do not need to deploy this interactive capability to all users in the architecture, or any at all.
In this chapter, you continue to gain an understanding of the CSA architecture through an exploration of the agent software components, protocol communication, and installation.
General CSA Agent Components Overview
You have access to several "under-the-hood" components that are built in to CSA. To fully understand how CSA works, it is best to get at least a high-level understanding of a few of the key components and their interaction on the local agent system.
When rules are changed, edited, added, or removed on the CSA MC that pertain to the particular rules and policies running on your agent, you need to update your local policies with the necessary changes. To do this, your local security agent software communicates with the CSA MC via HTTPS (443) to retrieve the new information. If you recall from an earlier discussion in Chapter 2, "Introducing the Cisco Security Agent," the CSA architecture uses a pull model whereby the agent requests information regarding possible policy changes at a set interval, which by default is 10 minutes. CSA version 4.5 includes a signed UDP hint message that can "nudge" the remote agents into polling earlier than the predetermined time so that they will receive the update ahead of schedule. This feature is very convenient, especially in environments where you have changed the default polling interval to a higher time value and you need the ability to push (that is, request a pull) a change quicker than the typical poll cycle.
The agent policy manager is the agent component that receives the policies from the CSA MC server and forwards them to another agent component known as the rule/event correlation engine. This engine reviews the old and new rules and replaces or updates whatever is necessary to form the new local rule set.
Another component in the CSA is known as interceptors. Interceptors proxy actions that are attempted and verify how to proceed against the rules in the rule/event correlation engine. Some of the interceptors are as follows:
- Network Traffic interceptor—Use for SYN flood and port scan protection.
- Network Applications interceptor—Limit or allow individual applications to access the network via specific protocols and networks addressing parameters.
- File interceptor—Limit an application's ability to read and write to specific files and directories.
A final noteworthy component is the local event manager. The local event manager locally stores events that are generated by the rules that have been triggered and set to log. Once stored and cached locally, the events that are to be logged are sent to the CSA MC for administrative review and global event correlation capabilities. If the CSA MC is not available, the agent stores the events and transmits the next time the agent can communicate with the CSA MC server with the appropriate time stamps attached.
All of the previously mentioned agent components also reside in the UNIX agents, although they are implemented through different programming methods available to those operating system architectures.