CSA Components Overview

< Day Day Up >

CSA Components Overview

CSA uses a distributed architecture consisting of two major components:

Management Console (MC)— The MC performs many important tasks such as agent configuration, policy configuration, and centralized reporting.
Agents — Agents, which enforce local security policies, reside on hosts throughout the network.

The next sections provide an overview of both components.

Management Console

The CSA MC runs on top of the Microsoft Windows 2000 Server operating system using either a Microsoft Database Engine (MSDE) by default, which is included in the product installation, or Microsoft SQL 2000 when you need to scale beyond 500 agents. The CSA MC is where all management functions are performed. As part of the CiscoWorks VPN Management Solutions (VMS) network management family of products, the CSA MC has the same look and feel as the other management tools from Cisco, and its configuration interface is accessible via a web browser over a secure encrypted Secure Sockets Layer (SSL) connection. Figure 2-1 provides a typical CSA MC screen you will see upon successfully logging in to the CSA MC application with your web browser.

Figure 2-1. Cisco Security Agent Management Console

The CSA MC application is where you perform all configuration tasks and tuning of necessary modules, rules, and policies to secure agents. You can also modify host group assignments and attach necessary security policies to groups from this interface. Another major function provided by the MC is the Event Viewer and Reporting tool by which necessary data is presented to the security group such that necessary action can be taken based on event notification.

Agent

CSA is a software application that installs on end systems. The following are host operating systems supported by the Cisco Security Agent:

Microsoft Windows NT
Microsoft Windows 2000
Microsoft Windows 2003
Microsoft Windows XP
Solaris 8
Linux RedHat Enterprise v3.0

The agent monitors the local system for policy violations and protects local resources and data from being compromised. Whenever an attempted policy violation is detected , a message is sent to the MC for centralized reporting purposes. At predetermined time intervals (polling time), the agents report back to the MC server to see whether any policy changes have been made to what is currently running on the local agent. Figure 2-2 shows a view of the CSA user interface that you can access from any agent-protected system in your environment.

Figure 2-2. CSA Local User Interface

< Day Day Up >

CSA Communication

Security agents are deployed on workstations and servers throughout your infrastructure, and your MC is located on a secured segment of your management network. Because these systems reside in different parts of your network, you should understand what communication needs to take place between the agents and MC. The next sections look at what communication takes place and the secure methods used.

Necessary Protocols and Ports

There are two communication streams to look at within the security agent architecture:

The management connection from the security administrator s PC to the MC
The communication path between the MC and the agents

The management connection from the security administrator s PC to the MC uses a web browser as the remote application to build an encrypted SSL tunnel on TCP ports 1741 and 1742. The typical installation of CiscoWorks VMS (where the CSA MC resides) uses a locally generated server-side certificate for the SSL connection; however, you can import a certificate for use on the server if you require an authenticated certificate using your current Public Key Infrastructure (PKI).

The communication path between the MC and the agents also uses SSL as the communication protocol on its standard TCP port 443 as well as TCP/5401. The MC also transmits larger transactions using HTTP (TCP/80). These large transactions include agent install kits and policy updates. Transmitting this information over HTTP allows organizations to benefit from distributed caching technologies that may have been deployed to allow for lower bandwidth utilization on slower WAN links. These files and communication are signed with the CSA MC certificate to prove its authenticity such that no one can intercept the communication and alter the contents without the endpoint knowing the transaction had been tampered with. Communication streams between the CSA MC and remote agents are used for a few purposes such as policy updates, agent polling, and alert message communication.

Pull Model

The major communication model CSA uses when checking for updates is that of a pull model. This at first seems contrary to what is expected. Many people have initially commented that they believe the communication should be a push rather than a pull because a configuration change on the MC requires an agent to initiate the conversation at the normal poll interval. This could mean that an agent would not get the necessary update in a timely fashion. This belief is a common misconception and is related to what many people have used for many years to protect their networks: signature-based technologies.

Remember, signature-based technologies are only as good as their signature level; therefore, signature-based products must have the ability to be updated as fast as possible when a new signature file is released. Behavior-based technologies do not have this limitation. Because CSA uses behavior-based rules to prevent day-zero attacks, you almost never need to force an update to the remote policy. Policy updates typically only need to take place in conjunction with rolling out a new application to an agent-protected system or as part of dynamic updates resulting from globally correlated network activities.

NOTE

The polling interval defaults to 10 minutes, but you can set it between 10 and 86,400 seconds (24 hours).

Push/Hint Capability

Even though the pull model has proven to be successful during previous versions of the CSA, with version 4.5 you can now send a hint message to remote agents suggesting they check in early because an update is waiting. The previous section identified some reasons the agent might need to receive an update. In most cases, the agent poll time is sufficient because the updates can be planned in advance as part of the project planning involving the additional new application to be installed on the end system.

Remote policy updates also may be required when a dynamic variable is updated as the result of correlated events such as the @DYNAMIC list of globally quarantined files or IP addresses. When this list is updated, it is beneficial to let the agents know they should poll early ( especially if you have set the poll interval to a very long timeframe). The method used to make this happen in version 4.5 is signed UDP hint messages. Signed UDP hint messages are UDP packets that carry the CSA MC certificate as the signature to prove authenticity. This message operationally instructs the remote agent to poll earlier than the next poll time to retrieve the necessary update. Although only functionally a hint to the remote client, you can consider this feature to be as timely as a push model.

NOTE

Because the hint message is UDP based, it is nonreliable and you will not know whether the message reached the endpoint.

< Day Day Up >