CSA Architecture

The architecture of CSA software is unique in that the host agent resides between the applications and the OS kernel, as shown in Figure 21-2. This provides application visibility with minimal impact to the stability and performance of the underlying operating system.

CSA works at the kernel level by controlling file system and network actions and other operating system components. CSA architecture intercepts all operating system and application-related calls when an access is requested for a certain resource, such as file access, device access, network access, Registry access, and application execution calls. CSA also intercepts dynamic runtime resources requested, such as memory pages, services, shared library modules, and any COM objects.

CSA applies unique intelligence to correlate the behavior of these system calls, based on rules that define unacceptable behavior for a specific application or for all applications. When an application attempts an operation or requests access, CSA checks the operation against the security policy, making a real-time decision to allow or deny the operation.

Security policies are collections of rules that are configurable items within CSA and can be created or modified anytime according to the corporate security policy. These rules drive application and system access to required resources. Because protection is based on blocking malicious behavior, the default policies stop both known and unknown (day-zero) threats without needing updates.

CSA Interceptor and Correlation

At the core of CSA architecture is the interceptor and correlation mechanism, which intercepts application- and system-related functions to enforce policy-based and behavior-based rules. Correlation is the enforcement engine for CSA where relationships between events are established to determine whether the behavior is acceptable and whether the event should be allowed or denied.

CSA correlation maintains the state of all system calls and application activities on the host system. For example, if an application on an endpoint creates a new file on the disk, CSA will monitor and correlate the state by checking the rules engine against a set of behavioral rules to validate the policy and act with necessary action in response (either allow the write function or deny it, depending on the rule policy).

CSA correlation enhances interoperability between applications, such as protecting the usage of a command shell from unauthorized access and ensuring that legitimate applications can invoke this without interruption. CSA achieves this by automatically creating and dynamically maintaining a whitelist of applications that are less vulnerable and allowed to invoke command shells. These applications can invoke a command shell, provided they are not vulnerable. However, if the application becomes vulnerable, the CSA whitelist will automatically update the list and remove this application, thereby denying command shell access. After the application is patched or fixed, the whitelist will dynamically update itself to reallow this application and reinstate the command shell access.

CSA can correlate numerous activities to increase the accuracy of its rules and policies and enhance its capability to make accurate decisions about what is dangerous.

Figure 21-3 illustrates the core architecture of the CSA correlation system and how it intercepts the various system and application-related functions or calls.

Figure 21-3. CSA Interceptor and Correlation Architecture

[View full size image]

CSA Correlation Extended Globally

The CSA correlation discussed previously occurs not only locally on the standalone host agent, but extends globally on the CSA Management Center, resulting in increased accuracy when compared to signature-based host IDS/IPS systems.

The CSA global correlation correlates events received from the network from the many desktop agents deployed throughout the network. By looking at events across the network, intrusions and attacks that went undetected on standalone systems will also be caught.

In an effort to avoid detection, smart hackers send only a few packets to selected hosts on the network, trying to map the entire network by going unnoticed and undetected. These distributed type scans will also be detected by the CSA Management Center because of the global correlation that is in place.

CSA Access Control Process

The following list outlines, in order, the access control process that the CSA agent performs:

Figure 21-4 illustrates the CSA access control process flowchart as previously outlined.

CSA Defense-in-Depth—Zero-Day Protection

A classic evidence of CSA protection was observed during the outbreak of the MyDoom worm in 2004. The MyDoom worm arrived via an e-mail message, installed itself by modifying system binaries, and then infected other systems by forwarding itself to everyone in the address book of the infected system. Host systems running CSA during this time were completely protected from the MyDoom worm because the CSA agent rules stopped the arrival and installation activities of this worm. CSA correlation tracked the worm at each stage of its life cycle and took preventive actions.