Chapter 21. Host Intrusion Prevention

Security enforcement evolves mainly at the network level through common techniques such as authentication, integrity mechanisms, firewalls, and encryption technologies. These techniques are adopted to provide the desired security at the network level, where data is transitional. An important area that is largely overlooked in enforcing security is the host level—the endpoint, where data resides and the potential for damage is the greatest.

The Cisco Host Intrusion Prevention solution provides self-defending solutions by deploying intelligent agents on desktops and servers that defend against the proliferation of attacks across networks.

This chapter provides details on the Cisco Host-based Intrusion Prevention solution that uses Cisco Security Agent (CSA). The chapter takes a closer look at core concepts such as CSA architecture, CSA components, CSA Policies, Rules, CSA Rule Modules, and details on managing and deploying CSA using CSA Management Center (CSA MC).

Securing Endpoints Using a Signatureless Mechanism

Today in many ways, networks are overgrown and distributed in nature. With open network policies, enforcing security at the network perimeter is insufficient. Data needs to be secured where it resides—at the endpoints.

Traditionally, endpoint security has always taken a reactive approach by implementing antivirus, scanners, personal firewalls, and other system audit programs. These products usually rely on signature-based mechanisms to detect only the known vulnerabilities and intrusions. Signatures and virus definition files are core elements of these solutions.

With endpoint security, multiple products are required to combat different aspects of the issue. For example, a desktop host may require antivirus software and a personal firewall, along with a system audit program, to cover different aspects of the intrusion. This is not a scalable solution and creates manageability issues and an administrative burden.

Figure 21-1 illustrates the five phases of the host-based attack landscape and the life cycle of activities that take place when a host intrusion occurs.

Figure 21-1. Host-Based Attack Life Cycle

Viruses and worms take advantage of numerous vulnerabilities at the operating system and application level. New viruses and worms proliferate in no time and spread rapidly, infecting the host system. A signature-based approach cannot prevent this rapid activity of intrusions. However, taking the different approach of using a proactive, behavioral-based system can identify and dynamically prevent malicious code from interacting with a host system and therefore can prevent known and unknown (day-zero) attacks.

The most effective way to provide endpoint security is to use a signatureless approach that does not require updates or patches and yet provides a proactive mechanism to protect the host against both known and unknown (day-zero) vulnerabilities, intrusions, and attacks.

Cisco Security Agent (CSA)

Cisco Security Agent (CSA) is a unique proposition that provides proactive host-based intrusion detection and prevention solutions for endpoint systems (desktop PCs, laptops, servers, and point of service [POS] terminals) for known and unknown (day-zero) threats. CSA goes beyond conventional security and does not rely on signature-based architecture. CSA provides endpoint security using a flexible policy-based and behavior-based architecture, thus offering defense against targeted attacks, virus, worm, spyware, adware, rootkit, and day-zero attacks that have not been discovered and new exploits and variants by taking advantage of known and unknown vulnerabilities.

CSA also provides policy compliance controls offering protection to sensitive information on the system. Examples include granular controls such as the restriction of the following: removable media storage (USB key), copy-paste sensitive information between applications, and peer-to-peer applications such as instant messaging (IM). CSA provides unique intelligence to correlate the behaviors of system functions, based on rules that define unacceptable behavior for a specific application, and it defines the necessary action to be taken. CSA is capable of implementing a wide range of granular policy-based compliance controls.

In addition, CSA provides numerous benefits:

• Endpoint system protection (desktop, server, and point of service [POS] terminals)

• Host-based intrusion prevention

• Policy-based and behavior-based architecture

• Personal firewall protection

• Day-zero attack protection

• Regulatory policy compliance enforcement

• Acceptable corporate use policy compliance

• Preventive protection against targeted attacks

• Stability and protection of the underlying operating system

• File and directory protection

• Host application visibility

• Application control

• Correlation of system calls and application functions

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.

Figure 21-2. CSA Sits Between Application and OS Kernel

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

---

---

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:

Step 1. Identify the resource being accessed (for example, network resource, memory function calls, application execution, file access, device access, system configuration, system API control, Registry access, connection rate limit, or any other OS kernel system calls).

Step 2. Gather data about the operation (for example, if a file access operation is requested, identify and gather the process name, file path, filename, and file operation, such as Read, Write, or Erase).

Step 3. Determine the state of the system (for example, currently assigned IP address, MAC address, DNS suffix, VPN client status, NAC posture, or virus/worm detection).

Step 4. Consult the security policy by analyzing the rules and consulting the local policies (for example, anomaly based, atomic rules, pattern-based, behavioral-based, or access control matrix).

Step 5. Take action as per policy defined in the rules (for example, Allow, Deny, Query, Change Internal State, or Monitor).

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

Figure 21-4. CSA Access Control Process Flowchart

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.

CSA Capabilities and Security Functional Roles

CSA has unique capabilities and plays many roles within the network, mainly because of its strategic positioning on the host system. With the in-depth knowledge of real-time events occurring on the system, CSA can monitor and control a wide variety of security functions and roles. CSA can control how the endpoint interacts with other surrounding systems and how users interact with the local system.

From the very beginning when CSA is first installed and launched, it begins monitoring the local system by maintaining a state table of each event and enforces security policy accordingly. As mentioned earlier, CSA monitors all system- and application-related calls, whether invoked by a user or by auto-executed malicious code that is attempting to gain unauthorized access. If the access is classified as inappropriate behavior, CSA will take real-time dynamic action and send an alert to both the local system and the CSA Management Center for global correlation.

CSA in a single agent software plays security functional roles on the host system beyond just preventing known and unknown (day-zero) attacks. Table 21-1 lists various CSA capabilities and their functional role descriptions.

Table 21-1. CSA Capabilities and Security Roles

CSA Components

As shown in Figure 21-5, CSA has three basic components:

• CSA endpoints: Endpoints are computing desktops, servers, laptops, and point of service (POS) terminals. The CSA agent is responsible for enforcing security policies received from the management server, sending events, and interacting with the user.

• CSA management server: The server is the core component in the CSA deployment, a repository of configuration database. The server is responsible for deploying the security policies to the endpoints; it receives and stores all events, sends alerts to the administrator, and can deploy software to the endpoints.

• CSA management console (CSA MC): The management console is an administrative web-based user interface and policy configuration tool that provides event views.

---

---

Figure 21-5. CSA Components

Configuring and Managing CSA Deployment by Using CSA MC

All security policies and configurations are accomplished using the CSA MC. These policies are associated with specific hosts and groups of hosts. All configurations are stored on the management server and deployed to the agents via the management server.

All communications between the CSA MC and the server are secured using Secure Sockets Layer (SSL) protocol. Similarly, communications between the CSA agent and the server database are secured using SSL.

The web-based user interface is accessed securely using SSL from any machine on the network that can connect to the management server. The web-based interface is used to deploy policies from CSA MC to all the agents across the network.

SSL protocol is also needed for the agents to periodically update the policy; therefore the network must not restrict SSL traffic on port 443. This is especially important if CSA agents are located on remote network segments that are isolated via firewalls.

The CSA MC binds with the server database which holds all the policies. All CSA endpoint agents must register with CSA MC to receive the policy. The CSA MC validates the host and deploys the respective policy pertaining to that host or group of hosts.

After the CSA agent on the local system receives the policy, it starts monitoring the system proactively and takes dynamic actions as necessary.

At regular intervals (configurable), the CSA agent polls the CSA MC for policy updates. It also sends triggered event alerts to the CSA MC global event manager.

No configuration is required on the CSA agent. All configurations are completed on the server via the CSA MC and deployed to the CSA agent. CSA agent will have only basic viewing capabilities.

Managing CSA Hosts

In the CSA architecture, hosts are the endpoint systems that require protection. A host is any system that has installed the CSA agent kit from the CSA MC and has registered with CSA MC. The host can be a desktop computer, a laptop, or even a server. These endpoints are referred to as hosts within the CSA MC configuration. As mentioned earlier, every host on the network has to register with CSA MC to receive policy updates. The status of the host can be monitored by CSA MC.

Figures 21-6 through 21-8 show a few sample screenshots for managing a host that is using the CSA MC.

Figure 21-6. CSA MC—Displaying List of Hosts

Figure 21-7. CSA MC—Searching a Host

---

---

There is no specific configuration required to configure the host settings within the CSA MC. As mentioned earlier, hosts register dynamically with the CSA MC and inherit group membership and policy settings transparently upon successful registration. Default policies are available for implementation out of the box.

To view the details of a particular host that has registered with the CSA MC, choose Systems, Hosts. Figure 21-8 shows a sample screenshot of the host detail page for a host named biohazard with complete host details. Several types of information can be viewed from the Host Detail Page, for example:

• Host Name and Description: Displays the system name of the CSA endpoint and a brief description of the host.

• Host Identification: Displays the CSA product version, the host IP address, a numeric ID associated to this host within the CSA MC database, registration details, host operating system details, and whether the Cisco Trust Agent (CTA) is installed and the associated posture state currently assigned to this agent. (This feature is part of the Network Admission Control [NAC] of the Cisco Self-Defending Network solution.)

• Host Status: Displays events triggered by the host, software and policy version, the time since the policy was last updated, and a detailed status and diagnostics link.

• Host Settings: Displays various items such as the polling interval, test mode, learn mode, logging mode, deny actions, filtering user information, and whether application deployment investigation is enabled.

• Group Membership and Policy Inheritance Table: Displays group membership, details of which groups the host is a member of, the policies assigned to the groups, and the modules within the policies.

• Combined Policy Rules Table: Displays a complete list of all the rules running on the host as combined from all associated groups, policies, and modules.

Managing CSA Agent Kits

Every endpoint system (host) requires a CSA agent to be installed on the system. This is done via the agent kit, which is an executable installation file generated by the CSA MC for the endpoint host system. By definition, an agent kit is the CSA agent installation executable file that is installed on the endpoint system.

Agent kits can be downloaded from the CSA MC directly via the SSL-protected web page. Alternatively, the file can be transported via other media (such as a USB key or copying it across the network) and executed manually from the local system. Another alternative is to develop scripted and automated installation procedures using software installation systems.

After the agent kit is installed on the system, the host registers to the CSA MC and pulls the appropriate policies and group settings accordingly. Agent kits are associated to groups, which have appropriate policies attached to them. When a host downloads the agent kit, it dynamically associates the host to the corresponding group with the preconfigured knowledge and enforces the associated policies of that group.

Figure 21-8. CSA MC—Host Detail Page

CSA MC has several built-in preconfigured agent kits available. Several default kits exist, such as kits for generic desktops, generic servers, and application servers.

Additionally, a custom agent kit can also be created by using the CSA MC. This gives you greater flexibility to define customized options to deploy to the host. Before creating a custom agent kit, other related parameters must be configured, such as initial modules, policies, and rules that the agent must use.

Figure 21-9 shows a sample screenshot from the CSA MC that was used to create an agent kit for IIS web servers.

Figure 21-9. CSA MC—Creating Agent Kit for IIS Web Servers

When the Make Kit button at the bottom of the page is submitted on the page shown in Figure 21-9, the kit is created, and the CSA MC produces a distribution kit for the host. The CSA MC will display a unique URL for each corresponding kit. This URL needs to be distributed to all the endpoint hosts for which the kit was created. This URL information can be sent to users via e-mail. When users receive this URL, they access the URL by using a web browser to download and install the kit. This is the most effective and recommended method for agent kit distribution.

Figure 21-10 shows a sample screenshot from the CSA MC of an agent kit URL page for IIS web servers created earlier. This URL can be distributed to all the IIS servers to be downloaded and installed on any IIS web server that needs CSA protection.

Figure 21-10. CSA MC—Agent Kit Page for IIS Web Servers

Alternatively, the default system URL for the CSA MC server can be distributed to the users. This URL lists all the available kits on the server, and users can choose the corresponding kit for their host or server and download and install it accordingly. This gives the users empowerment to make their own decisions as to which kit to download. The URL for the CSA MC is https://<system name>/csamc52/kits.

---

---

Managing CSA Groups

Groups are logical collections of hosts. The concept is similar to Windows Active Directory Groups or any other user database system.

Grouping host systems provides the following advantages:

• Policy consistency through applying the same set of policies on multiple hosts across the network

• The capability to apply alternative mechanisms and event set parameters based on group configurations

• A test mode feature to validate policies on groups of hosts before they are actively enforced on production systems

Hosts can be grouped on logical similarities and can be bound together on any common criteria that meet the security policy requirements; for example:

• Hosts, such as web servers, can be grouped according to system function. Specific policies can be created corresponding to the web server requirements.

• Hosts can be grouped according to business units, such as sales, finance, operations, and marketing. Specific policies can be created and crafted to meet the requirements of business functions and each business unit’s individual needs.

• Hosts can be grouped according to geographical or topological location.

• Hosts can be grouped according to their importance within an organization. For example, you can group mission-critical systems into a common group so that you can apply critical alert-level configurations to the group.

CSA Group simplifies configuration management by associating policy controls and other parameters into group settings. When a user is associated with the group, the host will inherit all the parameters configured within the group. The group also ensures consistency across the entire CSA deployment. All hosts have uniform settings when associated to the same group.

This scalable approach of grouping hosts allows large-scale CSA deployments to be deployed with great ease and reduced complexity.

Hosts can be members of one or more groups and will inherit all the settings merged into the host-specific policy setting from each group.

Another important advantage of having groups is that it makes creating the agent kits easier. The group parameter is the only element required to build agent kits.

CSA MC has several built-in predefined groups (in addition to the mandatory groups) that can be used according to the requirement.

Additionally, custom groups can be created using the CSA MC. This gives flexibility to define user-defined customized group options. Before creating a custom group, several parameters must be gathered, such as operating system, application information, and system user requirements to be configured for the group.

Figure 21-11 shows a sample screenshot from the CSA MC for the group setting page for the IIS web servers.

Figure 21-11. CSA MC—Group Settings Page for IIS Web Servers

Typically, groups in CSA MC can be divided into three categories:

• Mandatory groups

• Predefined groups

• Custom groups

By default, CSA MC provides three auto-enrollment mandatory groups:

• All Windows

• All Solaris

• All Linux

One of these three mandatory groups will be associated to each endpoint host according to its OS architecture upon registration. For example, when Windows-based hosts are registered to the CSA MC, they are automatically enrolled in the “All Windows” group in addition to any other groups that are mapped to this host. Hosts cannot be removed from the mandatory groups.

Mandatory groups enforce some of the compulsory security policies to prevent critical service from being inadvertently disturbed. For example, a mandatory policy can dictate that a user cannot disable DNS or DHCP service.

---

---

CSA Agent User Interface

After the agent kit is installed on the endpoint system, the CSA is ready to monitor the system. As mentioned earlier, to run the CSA agent software, no configuration is required on the endpoint. Optionally, as the administrator, you can provide end users with an advanced user interface that allows them to control the security settings and to use other added features.

To open the CSA agent user interface (UI), double-click the CSA agent icon in the system tray. (Locate a Red Flag icon in the system tray that denotes the CSA agent.) The options available in the agent UI depend upon the options selected in the Agent UI control page that governs the agent control rules in this context, as shown in Figure 21-12.

Figure 21-12 shows a sample screenshot from the CSA MC for the Agent User Interface control setting page.

Figure 21-12. CSA MC—Agent User Interface Control Page

Figure 21-13 shows a sample screenshot from an endpoint host system showing the CSA Agent user interface.

Figure 21-13. CSA Agent Host Endpoint—User Interface

As shown in Figure 21-13, the Agent User Interface displays various status information of the endpoint host, for example:

• The hostname of the machine on which this agent is installed.

• The name of the CSA MC with which this agent is registered.

• The date and time the agent registered with CSA MC.

• The date and time the agent last polled in to CSA MC.

• The date and time the agent last downloaded data from CSA MC.

• Update information informing the user whether a software version update is available for his agent.

• Display of the NAC posture result for the agent, if the Cisco Trust Agent (CTA) is installed. For example, the display can state the status as Healthy, Quarantine, or Infected.

• When the user clicks the Poll button, it forces the agent to poll the CSA MC immediately, rather than waiting for the configured time interval to trigger a poll. This way, the agent receives any rule changes right away.

Optionally, the CSA MC for the Agent User Interface control setting page can be configured to enable the Local Firewall and File Protection feature. The local firewall settings on the endpoint allow users to manually control which applications have access permissions on their systems and define what those permissions are.

Note that these firewall settings and permissions that indicate whether the application can access the network are assigned locally by the agent by a dynamic query method via a pop-up dialog box. These permissions can also be assigned during a learning mode period.

Figure 21-14 shows a sample screenshot from an endpoint host system that shows the Local Firewall setting in the CSA Agent user interface.

---

---

Figure 21-14. CSA Agent Host Endpoint—Local Firewall Setting

CSA Policies, Rule Modules, and Rules

As discussed in previous sections, each group is associated with a security policy that drives specific actions.

Policy is a collection of rule modules, and a rule module is a collection of multiple rules. The rule module acts as the container for rules, whereas the policy serves as the unit of attachment to groups. Rules provide control access to system resources. These resources can either be a system resource or a network resource.

Multiple rule modules can be attached to a single policy, and multiple policies can be attached to a single group. The rules enforce policy control actions to allow or deny specific actions. Different types of rules in a rule module can coexist, and consequently different types of rules within one policy can also exist.

CSA MC allows the creation of several types of policies in addition to the default built-in policies. An example of the three mandatory policies (Windows, Solaris, and Linux) is presented earlier in this chapter.

In principle, policies must reflect a well-planned security framework and be driven by the fundamental guidelines of the corporate security policy. Appropriate time and effort should be expended before charting these policies, because they provide network and application access to the systems.

Policies, rule modules, and rules are the enforcement tools in the CSA architecture.

---

---

Several other parameters are required to be configured when you are using CSA MC to complete the CSA deployment. For example, configure global correlation parameters, application classes, variables, logging and alerts, and other parameters.

Refer to the following Cisco documentation for further details to implement CSA in greater depth and additional configuration parameters: http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_book09186a008080732b.html.

Summary

Endpoint systems (such as desktops, laptops, and servers) are no longer secure because the threats from viruses, worms, adware, and spyware are on the rise. Vulnerabilities in the operating systems and application codes are also on the rise, and exploits can compromise endpoints in no time.

These dynamically evolving threats cannot be mitigated through traditional signature-based tools such as antivirus software on the host systems. Endpoints need to be equipped with the sophisticated intelligence to detect and prevent known and unknown threats in real-time without the need of signature updates.

The trend in host intrusion prevention has shifted and evolved into a more proactive approach that uses policy-based and behavior-based mechanisms to stop malicious activities and unknown (day-zero) attacks.

The Cisco Host Intrusion Prevention solution using the Cisco Secure Agent (CSA) endpoint software provides self-defending solutions by deploying intelligent agents to protect endpoint systems (desktops, laptops, and servers) against the proliferation of known and unknown threats and targeted attacks across networks.

The chapter began with a basic overview of the host intrusion prevention systems followed by a comprehensive overview of the Cisco host-based IPS solution that uses the Cisco Security Agent (CSA) solution.

The chapter provided in-depth details of the CSA architecture and described the workings of the CSA interceptor and correlation techniques that are equipped with the access control process.

The chapter provided a detailed list of CSA capabilities and the security functional roles that CSA can offer.

The chapter described details of CSA components, CSA hosts and groups, CSA policies, rule modules, and rules.

The chapter also provided and illustrated implementation guidelines and supporting references for configuring and managing the CSA deployment using the CSA Management Center (CSA MC).

References

http://www.cisco.com/go/csa

http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_book09186a008080732b.html

http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_chapter09186a00808074f6.html

http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_data_sheet0900aecd805baf46.html

http://www.cisco.com/en/US/products/sw/secursw/ps5057/tsd_products_support_design_technotes_list.html

http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_white_paper0900aecd8020f448.shtml

http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_white_paper0900aecd8020f438.shtml

http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_quick_installation_guide_chapter09186a00808073e5.html

http://www.ciscopress.com/title/1587052059

http://www.ciscopress.com/title/1587052520