-
Using Management Center for Cisco Security Agents 4.5.1
-
Title
-
Preface
-
Product Overview
-
Management Center for Cisco Security Agents Administration
-
Configuring Groups and Managing Hosts
-
Building Policies
-
Using System Correlation Rules
-
Using Application Classes
-
Configuring Variables
-
Event Logging and Alerts
-
Generating Reports
-
Using Management Center for Cisco Security Agents Utilities
-
Using Cisco Security Agent Analysis
-
Policy Definition Guidelines
-
Third Party Product Integration
-
Cisco Security Agent Overview
-
System Components
-
Open Source License Acknowledgements
-
Table Of Contents
Using System Correlation Rules
Event Correlation and Heuristics
Email Worm Protection Rule Module
Installation Applications Policy
Manage Dynamically Quarantined Files and IP Addresses
Using System Correlation Rules
Overview
Management Center for Cisco Security Agents provides rule modules and individual rules you can add to your policies that allow CSA MC to categorize processes and correlate events across multiple systems. When these rules are triggered by one or more system actions across a network, the MC registers this occurrence and automatically builds application classes and sends out new process categories to Cisco Security Agents. In some cases, the MC can prevent actions from executing on any additional systems. The Cisco Security Agent also uses heuristics to detect and terminate suspicious activities on systems, such as buffer overflows and password stealing attempts. These rule types differ from other action control rules in that multiple internal system events must trigger before these rules fire.
Use the rules and rule modules described in this chapter to protect systems just as you would other rules. For details on adding rules modules to policies and attaching policies to groups, refer back to Chapter 4, "Building Policies".
This section contains the following topics.
•
Event Correlation and Heuristics
•
•
Event Correlation and Heuristics
The Network shield rule which controls SYN flood protection and port scan detection and the System API control rule are some examples of preconfigured rules you can add to your modules in the same way you add other rules. These are basic system hardening, event correlation, and heuristic features that should be applied in most cases. Some are used in the General Applications Permissions module shown in Figure 5-1.
Figure 5-1 General Applications Permissions Module
System API Control Rule
The System API control rule detects several forms of malicious programming code that is installed on a system by an unsuspecting user either thinking that he or she is running some other type of program, or as a result of some other activity such as reading an attachment to an email message. Once installed, these malicious programs (for example, Trojans) may allow others to access and virtually take over a system across the network. Other errant programs may be set up to automatically send mail messages or other types of network traffic (including system passwords) while the system owner is unaware of what is occurring.
Note
It could be useful, especially in the case of server systems, to use a service restart rule in conjunction with a System API control rule. This way, if you are forced to press the Terminate button if queried by a triggered rule and you subsequently terminate the application in question, a service restart rule will cause the application to automatically restart.
Use the System API control rule in a policy to detect and prevent errant programs from performing malicious acts on individual systems and networks. The included System API control rule lets you enable several different types of system detection. See Figure 5-2.
System Information Checks
•
Detect applications that attempt to read system registry settings.
•
Detect applications that attempt to steal local system passwords.
System Monitoring Checks
•
Detect applications that attempt to capture system keystrokes.
•
This checkbox lets you control which applications can monitor media devices on the system. Media device "inputs" can be exploited by Trojans which can, for example, turn on the microphone on a system and covertly listen to a conversation.
Patterns to be included: Use the Wizard from the Event log message in question to include particular devices in a System API "allow" rule. You must specify media devices as "device\port". For example,
plantronics\microphone.
Note
System Modification Checks
•
Detect applications that attempt to directly access physical memory while bypassing virtual memory restrictions.
•
Detect applications that download ActiveX controls and immediately attempt to execute them.
This functionality limits applications from downloading ActiveX controls (signed and unsigned). This type of behavior is generally typical of a web browser and sites that require the downloading of ActiveX can trigger this rule. Note that this rule may be unnecessary if system web browser settings are configured with a "High" security level that would restrict the downloading of ActiveX controls.•
Detect applications that are attempting to write code to space owned by other applications. e.g. injecting a malicious .dll into a privileged process.
•
Detect applications that attempt to interfere with the memory space of other applications or detect Trojans attempting to hide in another executable to escape detection and gain permissions to access other resources.
Atypical System Behavior Checks
•
Although this behavior is sometimes exhibited by downloaded/executable content (e.g. license checking software), this may be symptomatic of a buffer overflow attack.
–
•
Detect processes running exception handling routines. This typically occurs due to bugs in the application software. But this may be a sign of an attack if this occurs with an application that does not generally exhibit this behavior.
•
Use this checkbox to detect processes invoking system calls that are rarely used. In normal system operation, many system calls are either never used or may only be used infrequently by a specific system application performing a service. Attempting to exploit undetected flaws in these unusual system calls is common attack vector for malware.
–
You also have the ability to select specific application classes to exclude from the various System API control rules you designate. For example, in some cases, debuggers may perform actions that can be misconstrued as malicious behavior. Therefore, you would want to create an application class, and select it as an exclusion to one or more System API control rule features.
Figure 5-2 System API Control Rule
Replicate Feature
When you make rule changes and click the Save button for rule types that contain multiple checkboxes, such as System API control rule (Network shield and Buffer overflow rules also provide this feature) a "replicate" link appears beside the "Saved changes" message at the top of the rule page. Click on replicate to access a pop-up box. From this box, you select other policies that contain System API control rules and choose to propagate the same change(s) you made on the current page to System API control rule pages in other policies. If the change you make to one System API control rule page is a change you need to make to all System API control rules in all your policies, this is a quick way to propagate those changes on a wide or even global scale.
Network Shield Rule
The Network shield rule provides network protocol stack hardening capabilities. The features available here require that the network shim be enabled on an agent system. If the network shim is not enabled, these rules have no effect when applied. See Network Shim Optional, page A-7.
Note
Step 1
•
•
Step 2
Note
Step 3
•
•
Step 4
Caution
IP Security checks
•
Enabling this feature causes the Cisco Security Agent to perform an integrity check on the IP packet header. This includes performing a consistency check on the IP header, on the length of the IP header, and on the number of bytes in the packet. If you configure this as a Deny rule, the following occurs: if any of these checks fail, the packet is dropped, if an IP checksum fails, the packet is dropped, IP options and IP fragments are validated as well and dropped if they are found to be invalid. (This defeats attacks such as Teardrop, Boink, and Ping of Death.)
•
IP addresses are determined to be invalid for several reasons: if the source address is a multicast address, if the TCP connection is to a broadcast address. You can select this checkbox as part of a Deny rule to protect against these types of attacks.
•
This detects IP options which control explicit routing instructions for packets. With IP source routing (an IP header option) the originator of a packet can try to partially or completely control the path through the network to the destination.
•
This detects the mapping of network topology via trace route.
Transport Security checks
•
This check ensures that transport headers are the proper length and that they are consistent (have enough data in the packet for them to fit). This includes verifying that certain fields have valid values and that certain combinations of TCP flags are legal. This defeats attacks such as a Christmas Tree scan.
•
SYN flooding is a type of denial of service attack. It occurs when a TCP/IP connection request is received from a return address that is not in use (i.e. a non-existent host for a spoofed address) resulting in a half open connection. An abundance of half open states on a server can prevent legitimate connections from being established. Detecting and preventing SYN floods stops this attack from succeeding.
(This rule type is not available for UNIX policies as the UNIX OS already provides this protection.)
Servers that are external to your network and not protected by a firewall should be protected against SYN floods. Firewalls generally provide this protection.
Note
•
If you configure this as a Deny rule, this check causes agents to make TCP sequence numbers unpredictable.
A server accepting connections using predictable TCP sequence numbers may be tricked into accepting a connection from a malicious source that is spoofing a trusted host. This prevents that vulnerability.
(This rule type is not available for UNIX policies as the UNIX OS already provides this protection.)
Note
•
Port scanning is a common method for finding weaknesses at a site by determining what network services are being run. An attacker attempts to connect to port after port on a target system, mapping ports to identify network services and machine type vulnerabilities. Configure this rule to log an event when an attempt is made to scan the system for an open port. Information is also gathered on the number of different source IP addresses perpetrating the scan and it reveals the source. In most cases, you should apply port scan detection to servers and end-user systems in your enterprise.
Configure this rule as a Deny rule to prevent unauthorized port scans, effectively cloaking a system on the network. Denying port scans causes a system to not respond to connectivity tests and to not respond to service requests with connectivity error messages.
A system generally sends out error messages when a remote machine sends a request for a service which is not running on the system. Often, this is how remote machines locate other systems and obtain network information about the system in an attempt to target it for an attack. By not responding, this prevents both UDP and TCP-based port scans of the system and basically hides it on the network.
If you are running an allowed service on a system and you are denying port scans, connection requests to this service are honored and your machine is viewable for the service you're offering.
Note
•
This check works similar to the TCP/UDP port scan feature, but for ping scans. See the port scan description for information.
•
If you configure this rule as a Deny, this feature restricts messages which can change the configuration of a machine. For example, a redirect can be used to cause routing tables to be updated.
•
Some ICMP messages may be used to gather information about a machine in an attempt to attack it. This data, when obtained, can be used to gather system information which can be used to exploit the system. If you configure this rule as a Deny, this feature restricts messages which report back on system or network configuration.
•
Configuring this rule as a Deny, causes agents to drop unsolicited echo responses.
The Cisco Security Agent validates that the echo response data matches the echo request data. This way, ping cannot be used as a transport for communications.
•
Configuring this rule as a Deny causes agents to block packets which are technically legal but are known exploits against protocol stacks (e.g. UDP packet storm or RF poison).
System Startup Security checks
•
Configuring this feature as a Deny, prevents non-essential network connections during system startup. This check is automatically disabled when the agent service starts and policies (including those which govern allowed network connections) are enforced. This protects the system from network-based attacks at boot-time before the agent service has started.
(This rule type is not available for UNIX policies.)
Note
Note
Step 5
Optionally, you can enter specific addresses here for those checkbox features in this rule that support addressing parameters.
Step 6
By default, this field indicates all local addresses on the agent system. You would want to use this to identify specific network interfaces, if necessary.
Step 7
Figure 5-3 Network Shield Rule
Note
Buffer Overflow Rule
A buffer overflow is what happens when two conditions are met: Firstly, an application is coded in a manner such that it trusts that all users of that application will provide the application with reasonable and expected data. Secondly, the application is provided larger quantities of data than it is capable of correctly handling. When these events come together, an application can behave in unexpected and unintentional ways.
For applications with special privileges, this can result in external users gaining access to machine resources and privileges which they normally would not be able to acquire. In other words, a hostile, network-based attack on a privileged, trusted application via buffer overflows can result in undesirable parties gaining access to your system.
In the case of UNIX operating systems, there are three distinct types of
buffer overruns which can occur, based upon the type of memory space involved: stack, data, and heap.•
•
•
Note
Configure the Buffer overflow rule as follows.
Step 1
Step 2
Step 3
•
•
Step 4
Step 5
•
•
Step 6
Applications in any of the following selected classes
Select one or more preconfigured application classes here.
Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes. For application class configuration details, see Chapter 6, "Using Application Classes".But not in the following class—Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default.
Step 7
•
Enable this checkbox to detect buffer overflow conditions which occur in UNIX executables. This feature provides protection from stack buffer overflows to a number of commonly used libc routines. As a large number of attacks on UNIX systems are based upon buffer overflow attacks, it is recommended that you enable this feature. Processes terminated by operating system due to executing code in stack space.
•
Use this checkbox to prevent certain system calls (e.g. those which grant extra privileges or start new processes) from occurring if they are invoked in an unsafe manner, or if they appear to have come from a corrupted or invalid context.
•
This checkbox enables the "noexec_user_stack" system variable for all processes or for processes added to the <*Processes requiring OS Stack Execution Protection>. See Built-in Configurable Application Classes, page 6-7 for details. This checkbox monitors the execution of instructions from stack memory. This only provides logging.
•
Processes can be killed on a system by either another process or by an internal error occurring on the system. This checkbox causes the agent to monitor when this occurs. The only action type available when this checkbox is enabled is Monitor.
•
Use this checkbox to prevent the usage of the '%n' *printf() format qualifier. Numerous attacks utilize the '%n' format on *printf() routines to gain access to program control flow information.
You also have the ability to select specific application classes to exclude from the various Buffer overflow types you designate. If you select an application in the available list beside a checkbox rule, that rule does not apply to the selected application class. If you have multiple, similar Buffer overflow rules, the application class exceptions are combined.
Note
Figure 5-4 Buffer Overflow Rule
Email Worm Protection Rule Module
Email worms are some of the most commonly spread and costly attacks affecting corporate networks today. Some well-known worms of the past include Mydoom, Anna Kournikova, and variations thereof. These worms easily infected systems, passing undetected through most security software until virus scanner vendors provided updates to detect these virus signatures. Even with this detection capability, if the worm is modified in any way, it is again undetectable by virus scanners.
When a worm of this type is received through email and executed by unsuspecting users, it generally attempts to send copies of itself to all entries in the email address book of the user. In doing this, the worm modifies registry keys, writes its own script files, and modifies existing files. This makes file recovery difficult and it can cause users to invoke the virus again when they attempt to open these infected files.
The Cisco Security Agent ships with a preconfigured email worm protection rule module. You must have this module deployed to take advantage of email worm network event correlation and quarantine capabilities.
The email worm protection module works through a combination of steps including dynamically building an application class through the detection of a suspicious action occurring on a system. If this suspicious action detection is seen by the MC as occurring on more than one system, a quarantine of the detected malicious process will also occur.
More specifically, it is through two sets of rule types that the detection and tagging of a virus or email worm occurs. In fact, these rules can be used more widely to identify and stop any type of virus, not only email. Although, this does require some different parameters to be set in the first group of rules.
The email worm protection rule module works this way:
•
•
The methodology used in the email protection module can be applied to any virus type you're protecting against. By altering the parameters of the first rule set (in this example, downloaded contented accessing the COM component for the email application address book) you can configure parameters to categorize any process as suspicious and subsequently stop any type of errant action.
Email Worm Event Correlation
If you select one of the options to add dynamically quarantined files to the list in the Global Event Correlation page (see Correlation), when a worm is detected, other agents will be notified to prevent the spread of this virus. Under these circumstances, the agent(s) report the file name the worm was written into. If at least two agents report worms writing to the same file name within an hour, the file is added to a dynamic list (@dynamic) of quarantined files. If you have a rule configured to stop dynamically quarantined files in a deployed policy, no further agents can open the contaminated file during the quarantine time frame. See also, page 4-64 for information on using @dynamic in File access control rules.
Installation Applications Policy
There is a preconfigured policy that you can apply to systems to detect when a software installation occurs and to add the install process or processes to a dynamically built application class. If dynamic tagging occurs, another set of rules would apply to the install processes added to this dynamic class. You may need to use this installation detection rule module in order to enforce a less strict set of rules to the system while an approved software installation is occurring. Under normal conditions, other rules on the system may prevent the install from occurring.
The built-in dynamic application class in question is called "Installation Applications." The rule module may build this application class under the following circumstances: A set of rules determines that setup.exe is detected on a system and it is added to the dynamic built-in Installation Applications class. As a result, a System State installation condition is triggered (see System State Sets, page 4-25) and a new policy is applied to the system. The system should automatically return to its original policy when the install exits. If this does not occur, the user can manually indicate when the installation is complete (a Resume button, see Figure 5-5, is made available if the end user has an agent UI) and return the system to the initial stricter policy. The installation state may also time out and the system then automatically returns to its initial policy.
Figure 5-5 Agent UI Resume Button
Global Events
The Management Center for Cisco Security Agents lets you enable correlation functions for particular types of events. In each case, you must have a corresponding rule enabled in a policy for the global event correlation to take place. If you do not enable global event correlation, individual events are logged by system agents but similar events across multiple agents are not correlated by the central CSA MC.
Correlation
The Event Correlation page, accessible from the menu bar as follows Configuration>Global Event Correlation (see Figure 5-6), provides the following capabilities:
•
With this checkbox enabled, correlated port scans and ping scans across multiple agent systems are logged separately as a correlated event in addition to the individual port scan and ping scan events that continue to be logged.
Note that you must have a Network shield rule with Port scan detection and Ping scan enabled in a policy deployed to the agent(s) in question for these event types to be detected and logged.
The threshold and time frame for correlating network scans are values you can configure.
•
•
With this checkbox enabled, events from multiple systems are correlated based on the NT event code, NT event severity, NT event source, and NT event log type. If 2 systems log the same NT event type within 30 minutes, a correlated summary event is logged.
Note that you must have an NT event log rule in a policy deployed to the agent(s) in question for these events to be uploaded to the CSA MC log.
If you do not enable this checkbox, NT event correlation does not take place, but individual NT events are logged in accordance with the NT event log rule you have configured.
Note
•
With this checkbox enabled, when processes are added to the dynamic <Suspected Virus Applications> application class (see Built-in Configurable Application Classes, page 6-7) and this event is logged across multiple agent systems, these events are correlated and the contaminated file that triggered the event is added to a dynamic list of quarantined files that CSA MC maintains. If you have a rule configured to stop dynamically quarantined files in a deployed policy, no further agents can access the contaminated file. See page 4-64 for information on using @dynamic in File access control rules.
If you do not enable this checkbox, suspected virus correlation does not take place, but individual virus events are logged.
Note that you must have a a corresponding policy deployed to the agent(s) in question for these event types to be detected and logged.
•
With this checkbox enabled, events logged by virus scanners running on agent systems are received and correlated by CSA MC. Contaminated files detected by virus scanners are added to the list of quarantined files. If you have a rule configured to stop access to dynamically quarantined files in a deployed policy, no further agents can receive the contaminated file. See page 4-64 for information on using @dynamic in File access control rules.
Note
The threshold and time frame for correlating events received from virus scanners are values you can configure.
Note
•
With this checkbox enabled, when processes are added to the dynamic <Processes communicating with Untrusted Hosts> application class (see Built-in Configurable Application Classes, page 6-7) and this event is logged across multiple agent systems, these events are correlated and the untrusted peer address that triggered the event is added to a dynamic list of quarantined IP addresses that CSA MC maintains. If you have a rule configured to stop dynamically quarantined IP addresses in a deployed policy, no further agents can communicate with this peer address. See page 4-69 for information on using @dynamic in Network access control rules.
If you do not enable this checkbox, untrusted host correlation does not take place, but individual untrusted host events are logged.
Note
Note
Manage Dynamically Quarantined Files and IP Addresses
You can use the @dynamic token in the File set text field and in the Network address set text field to control access to files and addresses that have been quarantined by CSA MC. Files are quarantined as a result of suspected virus application events, correlated virus scanner log messages, or files that were added manually. This list updates automatically (dynamically) as logged quarantined files are received. Addresses are quarantined as a result of communication with a suspected untrusted host (this updates dynamically) or by being added manually.
To view the files that are added to the dynamically quarantined files list and to manually add files to be quarantined, click the Manage dynamically quarantined files link on the Global Event Correlation page. See Figure 5-7. Add and Remove files from this list using the provided buttons on the bottom of the window that appears.To view the addresses that are added to the dynamically quarantined IP addresses list and to manually add addresses to be quarantined, click the Manage dynamically quarantined IP addresses link on the Global Event Correlation page. Add and Remove IP addresses from this list using the provided buttons on the bottom of the window that appears. See Figure 5-8. The "Source" column in this window describes how the address was added to the list (manually by the administrator or through a correlation event).
Changes made to the quarantined file and IP address lists are not received by agents until they next poll in to the management center. You can send a hint message to hosts to poll in sooner than the set interval. See Configuring Groups, page 3-3 for poll hint details.
Figure 5-6 Global Event Correlation Page
Figure 5-7 Quarantine Files Window
Figure 5-8 Quarantine IP Addresses Window
