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.