Reporting and Mitigation Devices Overview

After you complete the initial configuration of Local Controller as described in Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System, you must determine a monitoring strategy to use for your network. You must also determine a mitigation strategy, if you chose to take advantage of the MARS mitigation features. For guidance on how to determine the monitoring and mitigation strategies, see STM Task Flow Overview.

This chapters assumes that you have made corporate-level policy decisions and that you are executing against the Checklist for Provisioning Phase. This chapter provides the following:

•

Guidance on selecting and configuring reporting devices and mitigation devices

Before configuring the MARS Appliance to recognize reporting devices, you should understand the three levels of operation that MARS can achieve.

Levels of Operation

MARS operates at three discernible levels based on the type of data collected from reporting devices and the features such data enables for the system.These levels focus on the ability to identify attacks from end-to-end, and they are separate from the features enabled by specific types of reporting devices.

•

Basic. At this level, MARS behaves like a smart syslog server. It collects reporting device logs and support basic queries and reports. To enable basic operation, you must complete the initial configuration of the MARS Appliance as described in Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System. In addition, you must specify the device name and reporting IP addresses of the reporting devices as described in Adding Reporting and Mitigation Devices.

•

Intermediate. At this level, MARS processes events and performs session-based correlation, including resolving NAT and PAT translations at the IP address layer. To enable intermediate operation, you must provide more details about the devices you want to monitor, including access IP addresses, management access passwords, OS platforms and versions, and running services and applications, see IP Management for more information.

•

Advanced. This level is a fully enabled MARS Appliance. When advanced operation is enabled, MARS Appliance discovers and displays the full topology, draws attack paths, and enables MAC address lookups of the hosts involved in an attack. To enable advanced operation, you must provide the SNMP community string information for your network. You must also enable topology discovery, as defined in Scheduling Topology Updates.

Table 2-1 summarizes the levels, their configuration requirements, and the features enabled at that level.

Selecting the Devices to Monitor

All monitoring strategies involve selecting the types of devices to monitor and how much data to provide the MARS Appliance. All devices on your network, be they hosts, gateways, security devices, or servers, provide some level of data that MARS can use to improve the accuracy of security incident identification. However, careful consideration of what data to provide can improve the attack identification response time by ensuring that MARS does not perform necessary or redundant event correlation and analysis. Unnecessary logging and reporting by reporting devices can also reduce the effectiveness of your network.

We recommend analyzing each network segment to identify the most data rich combination that you can achieve, while identifying and refining your configurations to reduce redundant data.

When determining a monitoring strategy, you must also determine the goals behind the monitoring. Is it just for attack detection? Attack detection and mitigation? Regulatory compliance? Your goals affect which devices you must monitor and what features you must configure on those devices.

Table 2-1 Levels of Operation
Level Of Operation	Configuration Requirements	Functionality Enabled
Level 1	MARS configured Reporting device names and reporting IP addresses added NetFlow enabled	Basic syslog functionality Event correlation Query, reports, and chart support NetFlow anomaly detection
Level 2	Access IP addresses and information added	Starts performing event and session-based correlation NAT and PAT resolution IP address lookup of attackers and targets
Level 3	Community strings and networks added	MAC address lookup of attackers and targets Topologies enabled

•

Identify the devices/feature pairs that overlap on the same network segment, where a choice between device can reduce duplicity or prioritize device performance

Last, you must consider an event tuning method for your monitoring strategy. How you tune your MARS affects your overall operational costs proportionally to the number of device of a give type that are monitored. Essentially, if you have the bandwidth available, we recommend that you tune the events at the MARS Appliance, which reduces your operational costs by tuning at a single point in the network. However, if bandwidth is a precious commodity, you may chose to tune the event propagation at the reporting device level, preventing the events from going onto the network.

Table 2-2 identifies the device types, describes what information they can provide, and recommends how to configure these devices within your network.

Table 2-2 Device Types and Data Available
Device Type	Data Available	Recommended Configurations
Router	The device discovery protocol is the one used for administrative access/mitigation. For example, if SSH is used to discover the device, then SSH is the protocol that used to pushed the mitigation command. The following data is pulled from routers: •hostname •static routes •ACL rules •static NAT rules •traffic flows •SNMP RO Community strings •NetFlow data •device status and resource utilization, such as memory, CPU, and interface/port statistics. •ARP cache table. Used to map IP address to MAC address.	Enable the following: •SNMP RO community strings •Syslog traffic •Device discovery via SSH or Telnet access
Switch	During investigation and mitigation, the ARP cache tables are reviewed to resolve the MAC addresses involved in the incident. This data is cached for 6 hours. SNMP RO Community strings Forwarding tables, used to map IP address to MAC address. Device status and resource utilization, such as memory, CPU, and interface/port statistics. NetFlow data 802.1x logs generated during NAC sessions	Enable the following: •SNMP RO community strings •Syslog traffic •Device discovery via SSH or Telnet access •Enable NetFlow data •Administrative access for mitigation push
Firewall	Interface configurations. Used to populate topology view and determine expected routes, which helps refine correlation of traffic traversing the firewall. NAT and PAT mappings. Used to identify the point of origin attackers and targets and trace attacks as they spread. Firewall policies. When discovering ASA, PIX, and FWSM, MARS parses ACLs and conduits (PIX only). For Check Point firewalls, it collects the firewall policy from policy table. MARS using this information only for path computation and mitigation recommendations. It is not used by any other components, such as rules, reports, and sessionization. Firewall logs. Accepted and denied sessions logs are used to identify false positives and determine if potential attacks were blocked before reaching their targets. Audit logs. Associates users with authentication sessions and assists in identifying exploited accounts and administrative sessions. ARP cache tables. Used to map IP address to MAC address. Device status and resource utilization information. Used to identify anomalous network activities based on memory, CPU, and interface and port statistics.	Enable the following: •SNMP RO community strings •Syslog messages •Device discovery
VPN	Remote user information. Provides username to IP address mapping. VPN client helps determine the person who logged in and performed specific actions. Clarifies the true point of origin by identifying the host, not the VPN concentrator. Login/logout records. Helps identifies worms by tracing outbreaks back to a specific user and provides network access periods. Device status information. Identifies whether the device is operational, which allows prediction of possible spread of potential attacks and worms. •SNMP RO Community strings
Network IDS/IPS	Fired signature alerts. Identifies attacks and threats, which helps determine mitigation response, identify potential false positive information, and target vulnerability assessment probes conducted by MARS. Trigger packet information. Provides the payload of the packet that caused the signature to fire. Determine whether an attack was blocked at a specific device. Device status information
Host IDSes	Provides host-level validation of exploits and blocked attacks, which improves the accuracy of false positive identification, which in turn improves the ability of the administrator to accurately prioritize the work required to contain attacks.
Anti-Virus	Central anti-virus management servers provide information on which hosts are infected, which hosts have reported attempted infections, etc. The servers also provide the dat or signature file information for managed hosts, which improves the ability to determine whether an attack was likely to have succeeded.
Vulnerability Assessment	Host OS and Patch Level. When a signature fires on an IDS and it is reported to MARS, MARS can either launch a targeted scan using Nessus, or query a vulnerability assessment system that helps determine whether the target was vulnerable.	Enable any vulnerability assessment solutions supported by MARS.
Host OSes	Microsoft Windows Hosts Events found in the security event log as well application event and system event log.	Install and configure SNARE, which pushes events to MARS in near real time, and scales more efficiently than pulling events from hosts.
	Solaris and Linux Hosts Incoming network session logs, via inted, and FTP transfer logs, via xferlog. In addition, any events that are written to the system log by applications and services running on host.	•Enable logging for the xferlog and inetd applications. •Enable syslog daemon. •Identify the MARS Appliance as syslog target.
	Generic Hosts (All OSes) Includes system-level information, such as privilege escalation and buffer overflow. Helps determine what attacks make it to the host layer. If MARS learns of activity at the host level, then it understands that the attack or exploit has successfully traversed the network. MARS correlates this data with the network level data to discover the whole incident and analyze the exploit method so the administrator can build a better defense. In some cases, MARS recommends actions for mitigating the attack. We recommend that you maintain these recommended blocks as long as similar attacks are expected. Typical blocking techniques, such as IPS shunning, often fail to identify the best chokepoint for containment. As part of the recommended action, MARS does identify the optimal chokepoint where the recommended action should be effected.
Web Server	Same as hosts (SNARE and Perl script agents) need this when the hosts cannot send us the logs via syslog. agent is basically a transport.
Web Proxy	Mapping from user to site, translations for the IP address mapping, tells us the real address of the host who is likely infected. URLs and also filtering...regulatory compliance.
Database	Login/logout to determine the actual user (query report tab on the data). Privilege escalation, brute force crack type stuff, or maybe we want to do regulatory compliance.
AAA Server	Login/logout and NAC functionality (deny a person due to privileges, it triggers NAC message) •passed authentication log •failed attempts log •RADIUS accounting log, including those events specific to NAC.	Supporting Cisco Secure ACS Server Supporting Cisco Secure ACS Solution Engine
Generic Syslog	Same as host, provides support for additional customer devices.
Generic SNMP	Same as host, provides support for additional customer devices.
Cisco Security Manager	Mapping to any committed policy rules defined in Security Manager that match any ACL rules that could cause the generation of a specific syslog event by a reporting device. This policy lookup feature allows you to debug network issues and understand the cause/effect relationships between event messages and the device policies and traffic that resulted in the generation of the event.	Enable HTTPS on the Security Manager server. Define an administrative level account on the Security Manager server that CS-MARS can use for policy lookups.

Understanding Access IP, Reporting IP, and Interface Settings

When defining a reporting or mitigation device in the web interface, MARS allows (and at times, requires) you to specify several IP addresses. Understanding the purpose of the different addresses is important to effectively defining the devices that you want to monitor and manage. It is also important to understand their relationship to other settings that you can identify.

If a device has a single interface and a single IP address associated with that interface, the access and reporting IP addresses are the same as the address assigned to the interface. MARS collects this information separately to support those devices that have multiple interfaces, multiple IP addresses associated with a single interface, or both.

Note Not all reporting devices support both an access and reporting IP address. Some devices use only access IP addresses to query the device for the required information (e.g., QualysGuard security service), while others have no settings that MARS can discover and only generate event messages for MARS to process (e.g., NetCache appliances). In addition, not all devices require the definition of interfaces.

This section discusses the following three addresses and their relationship to other settings:

Access IP

MARS uses the access IP address to either connect to the device for network-based administrative sessions or connect to a remote server on which a file containing the device's configuration is stored. The expected value is determined by the access type you select. Most devices also require that you explicitly identify the IP addresses of hosts allowed to administer them. The MARS Appliance must be listed among such hosts as part of the device preparation.

The protocol that MARS uses to connect to the device is defined by the access type value, which is a dependency for enabling administrative access. Once MARS has administrative access, it can perform device discovery, which includes settings such as ARP tables, NAT, routes, and active ACLs, all of which helps MARS understand the topology, perform attack path analysis, and identify false positive incidents. Discovery can be performed to varying degrees using any of the access types. For more information on access types, see Selecting the Access Type.

MARS also uses SNMP RO and SNMPwalk to discover the device settings and topology information. However, the two methods of discovery are distinct and have distinct requirements. SNMPwalk requires the access IP address and the SNMP access type. SNMP RO discovery does not requires the SNMP access type, but it does require the access IP address.

Note MARS does not support the following characters in the SNMP RO community string: ' (single quote), " (double quote), < (less than symbol), and > (greater than symbol).

In addition, both SNMPwalk and SNMP RO are unrelated to SNMP notifications or SNMP traps. SNMPwalk and SNMP RO both require that MARS initiate the information request, where as SNMP notifications are event notifications published by the reporting device, much the same as syslog messages are. As with syslog messages, SNMP notifications are published over the reporting IP address.

Reporting IP

The reporting IP is the source IP address of event messages, logs, notifications, or traps that originate from the device. MARS uses this address to associate received messages with the correct device. For single-homed devices, the reporting IP address is the same as the access IP; for dual- or multi-homed devices, this address must be explicitly associated with the syslog, NetFlow, and SNMP services running on the reporting device. Most devices also require, for each message type, that you explicitly identify the IP addresses of hosts to which messages should be published. These hosts are commonly referred to as target log servers. The MARS Appliance must be listed among such hosts as part of the device preparation.

The role in MARS of the reporting IP address differs from that of the access IP address in that the reporting IP address is treated passively from the MARS perspective. MARS does not query the device using this address. Such operations are performed using the access IP address and the access type.

MARS accepts only one reporting IP address per device. For devices supporting two message formats, such as NetFlow and syslog, you must ensure that both message formats are bound to the same source IP address (the reporting IP). In Cisco IOS devices, this common association is not the default so you must change either the syslog or the NetFlow reporting IP address to match the other. If the message types do not originate from a common IP address, one of them is seen as originating from an unreported device and MARS does not parse those events correctly.

The supported format of event data varies among reporting devices. Just because the device is able to generate syslog, NetFlow, and SNMP notifications does not mean that MARS processes all three formats. The document, Supported Devices and Software Versions for Cisco Security MARS Local Controller 4.3.x and 5.3.x, identifies the event retrieval protocol supported by each device type.

Interface Settings

Interface settings are exclusive to hosts and software applications running on hosts. While MARS can discover the settings of a reporting device that is a software application running on a host, it cannot discover settings about the host itself. The role of interface settings in MARS is different from that the access IP address and reporting IP address. Interface settings represent static information, not discovered or learned, about the host.

When correlating events specific to a host or reporting devices running on that host, MARS needs to understand the number of interfaces installed in the host, their names, and the IP addresses and networks associated with them. MARS uses the interface settings to guide discovery operations, to determine attack path vectors, and to perform Nessus vulnerability assessments.

Selecting the Access Type

The access type refers to the administrative protocol that MARS uses to access a reporting device or mitigation device. For most devices monitored by MARS, you can choose from among four administrative access protocols:

•

SNMP. SNMP access provides administrative access to the device using a secured connection. It allows for the discovery of the settings using SNMPwalk, such as routes, connected networks, ARP tables, and address translations. If granted read-write access, SNMP also allows for mitigation on any L2 devices that support MIB2.

•

Telnet. Telnet provides full administrative access to the device using an unsecured connection. It allows for the discovery of the settings, such as routes, connected networks, ARP tables, and address translations. It also allows for mitigation on L2 devices.

•

SSH. SSH provides full administrative access to the device using a secured connection. It allows for the discovery of the settings, such as routes, connected networks, ARP tables, and address translations. It also allows for mitigation on L2 devices. This access method is recommended for DTM support; however, Telnet access can achieve the same results.

•

FTP. FTP passive discovery of settings by providing MARS access to a file copy of the configuration running on the router. FTP does not support mitigation, DTM, or discovery of dynamic settings, such as NAT and ARP tables. In addition, if you select the FTP access type for device types, such as Cisco ASA and FWSM, you can only discover settings for the admin context. This access method is the least preferred and most limited access method. To enable configuration discovery using FTP access, you must place a copy the device's configuration file on an FTP server to which the MARS Appliance has access. This FTP server must have users authentication enabled.

You can use any access scheme in conjunction with an SNMP RO community string. The division between Access IP and Reporting IP is clearly illustrated by an FTP access type example. Assume that you have SNMP RO access to a router, but your configuration discovery (access type) is restricted to a file stored on an FTP server.

When you define a device in MARS, the Access IP is the IP address of the FTP server (not the router), and the authentication information is used to access the FTP server. The Access Method is set to FTP. The Reporting IP is the IP address of the interface over which SNMP traps are published by the router.

The following topics describe how to configure each access type, identifying the fields that should be completed when a specific access type is selected. For efficiencies sake, these procedures are referenced throughout the specific device configuration topics, as they related to a specific device type.

Configure SNMP Access for Devices in MARS

This procedure assumes you are defining a reporting device or mitigation device and that you were referred to this procedure after selecting SNMP in the Access Type list. To select SNMP as the access type, you must provide MARS with SNMP read-write access.

Note The SNMP access type is not required to enable the SMPO RO strings. In fact, no access type is required to support SNMP RO. SNMP RO uses a shared, read-only community string; it does not require a read-write community string as does the SNMP access type.

Step 1

In the Login field, enter the username of the administrative account to use when accessing the reporting device.

Step 2

In the Password field, enter the password associated with the username specified in the Login field.

Step 3

If this device supports an enable mode, enter that password in the Enable Password field.

Configure Telnet Access for Devices in MARS

This procedure assumes you are defining a reporting device or mitigation device and that you were referred to this procedure after selecting TELNET in the Access Type list.

Step 1

In the Login field, enter the username of the administrative account to use when accessing the reporting device.

Step 2

In the Password field, enter the password associated with the username specified in the Login field.

Step 3

If this device supports an enable mode, enter that password in the Enable Password field.

Configure SSH Access for Devices in MARS

This procedure assumes you are defining a reporting device or mitigation device and that you were referred to this procedure after selecting SSH in the Access Type list.

Step 1

From the list box to the right of the Access Type list, select 3DES, DES, or BlowFish as the encryption cipher for SSH sessions between the MARS Appliance and the reporting device.

Step 2

In the Login field, enter the username of the administrative account to use when accessing the reporting device.

Step 3

In the Password field, enter the password associated with the username specified in the Login field.

Step 4

If this device supports an enable mode, enter that password in the Enable Password field.

Configure FTP Access for Devices in MARS

This procedure assumes you are defining a reporting device or mitigation device and that you were referred to this procedure after selecting FTP in the Access Type list.

Step 1

In the Login field, enter the username of the FTP server account to use when accessing the configuration file of the reporting device.

Step 2

In the Password field, enter the password associated with the username specified in the Login field.

Step 3

In the Config Path field, enter the path to the reporting device's configuration file residing on the FTP server.

This path begins at the root of the FTP server's published folder, not at the root directory of server.

Step 4

In the File Name field, enter the name of the reporting device's configuration file residing on the FTP server.

Bootstrap Summary Table

Table 2-3 summaries the settings that you must configure for reporting devices and mitigation devices. It also provides links to any required agent downloads and to detailed configuration information.

Table 2-3 Reporting and Mitigation Device Bootstrap Summary
Device Type/Name	Bootstrap Summary	Reference Information
Router/Switch
Cisco Router	1. Access to IP address/interface by MARS. 2. FTP, SNMP, Telnet or SSH access by MARS. 3. Define SNMP RO community string. 4. Turn on syslog, define log level, and define MARS as target of syslog messages. 5. Enable NAC features.	Cisco Router Devices
Cisco Switch (IOS)		Cisco Switch Devices
Cisco Switch (CatOS)
Extreme ExtremeWare	1. Access to IP address/interface by MARS. 2. (ExtremeWare only) Turn on syslog, define log level, and define MARS as target of syslog messages. 3. SNMP access by MARS. 4. Define SNMP RO community string.	Extreme ExtremeWare 6.x
Generic Router		Generic Router Device
Firewall Devices
Cisco PIX	1. Access to access and reporting IP address/interface by MARS. 2. FTP, Telnet, or SSH access by MARS. 3. Define SNMP RO community string. Note SNMP settings should be defined for the admin context on ASA and FWSM. You do not need to define these settings for each security context. 4. Turn on syslog, define log level, and define MARS as target of syslog messages.	Bootstrap the Cisco Firewall Device
Cisco Adaptive Security Appliance (ASA)
Cisco Firewall Services Module (FWSM)
Cisco IOS Firewall Feature Set
Juniper Netscreen		NetScreen ScreenOS Devices
Checkpoint Opsec NG and Firewall-1	1. Add the MARS Appliance as a host. 2. Create and install an OPSEC Application object for the defined host. 3. Define policies to permit SIC traffic between the MARS Appliance, the Check Point management server, and any remote servers. 4. Define the log settings to push the correct events to the defined host. 5. Install the policies.	Bootstrap the Check Point Devices
Nokia Firewall (running Checkpoint)		Bootstrap the Check Point Devices
VPN Devices
Cisco VPN Concentrator		Cisco VPN 3000 Concentrator
Network IDS
Cisco Network IDS Cisco IDSM	1. Enable RDEP for IDS modules. 2. Configure the following signature actions: •Alert •(Optional) To view trigger packets, enable the "produce-verbose-alert". •(Optional) To view IP logs, enable the alert or "produce-verbose-alert" and "log-pair-packets".	Cisco IDS 3.1 Sensors Cisco IDS 4.0, IPS 5.x, and IPS 6.x Sensors
Cisco Intrusion Prevention System (IPS), Network IPS	1. Enable SDEE for IPS modules. 2. Configure the following signature actions: •Alert •(Optional) To view trigger packets, enable the "produce-verbose-alert". •(Optional) To view IP logs, enable the alert or "produce-verbose-alert" and "log-pair-packets".	Cisco IDS 4.0, IPS 5.x, and IPS 6.x Sensors
Cisco IPS ASA module	1. Enable SDEE for IPS modules. 2. Configure the following signature actions: •Alert •(Optional) To view trigger packets, enable the "produce-verbose-alert". •(Optional) To view IP logs, enable the alert or "produce-verbose-alert" and "log-pair-packets".	Cisco IPS Modules
Cisco IOS IPS module	1. Enable SDEE for IPS modules. 2. Configure the following signature actions: •Alert •(Optional) To view trigger packets, enable the "produce-verbose-alert". •(Optional) To view IP logs, enable the alert or "produce-verbose-alert" and "log-pair-packets".	Cisco IPS Modules
McAfee Intrushield		IntruVert IntruShield
Juniper Netscreen IDP		NetScreen IDP 2.1
Symantec Manhunt		Symantec ManHunt
ISS RealSecure		ISS RealSecure 6.5 and 7.0
Snort		Snort 2.0
Enterasys Dragon		Enterasys Dragon 6.x
Host IDS
Cisco Security Agent		Cisco Security Agent 4.x and 5.x Device
McAfee Entercept		Entercept Entercept 2.5 and 4.0
ISS RealSecure Host Sensor		ISS RealSecure 6.5 and 7.0
Anti-virus
Symantec AntiVirus		Symantec AntiVirus Configuration
Cisco Incident Control System (Cisco ICS), Trend Micro Outbreak Prevention Service (OPS)		Cisco Incident Control Server
McAfee ePolicy Orchestrator		McAfee ePolicy Orchestrator Devices
Network Associates VirusScan		McAfee ePolicy Orchestrator Devices
Vulnerability Assessment
eEye REM		eEye REM 1.0
Qualys QualysGuard		Qualys QualysGuard Devices
Foundstone Foundscan		Foundstone FoundScan 3.0
Host Operating Systems
Windows	Do one of the following: •Install and configure the SNARE agent •Create or edit an administrative account to ensure that it has permissions to pull the event data	Syslog (pushed by SNARE agent) or event data pull using MS-RPC Push Method: Configure Generic Microsoft Windows Hosts Pull Method: Configure the Microsoft Windows Host
Solaris	—	Syslog (from Device) Sun Solaris and Linux Hosts
Redhat Linux	—	Syslog (from Device) Sun Solaris and Linux Hosts
Web Server
Microsoft Internet Information Server	—	Syslog (from SNARE agent) Install and Configure the Snare Agent for IIS
Sun iPlanet	—	HTTP (from MARS Agent) Install and Configure the Web Agent on UNIX or Linux
Apache	—	HTTP (from MARS Agent) Install and Configure the Web Agent on UNIX or Linux
Web Proxy
NetApp NetCache	—	HTTP Network Appliance NetCache Generic
Database Server
Oracle	TCP	SQLnet (from Host) Oracle Database Server Generic, page 12-1
AAA Server
Cisco Secure Access Control Sever (ACS)	—	Syslog (from MARS Agent) Install and Configure the PN Log Agent (Cisco Secure ACS)
Cisco Secure ACS Appliance	Install and configure remote log agent.	Syslog (from MARS Agent) on secondary host Supporting Cisco Secure ACS Solution Engine Install and Configure the PN Log Agent (Cisco Secure ACS)
SNMP and Syslog Servers
Generic Syslog Server	Publish syslog messages to MARS Appliance. Enable SNMP access by MARS Appliance.	Adding Generic Devices
Generic SNMP Server	Enable SNMP access by MARS Appliance.	Adding Generic Devices
Other
Cisco Security Manager	Enable HTTPS access by MARS Appliance	Checklist for Security Manager-to-MARS Integration Bootstrapping Cisco Security Manager Server to Communicate with MARS Add a Cisco Security Manager Server to MARS

Adding Reporting and Mitigation Devices

Three methods exist for adding reporting devices and mitigation devices to MARS:

From the Security and Monitor Devices page, you can add or edit the reporting devices and mitigation devices that MARS monitors. To access this page, click Admin > System Setup > Security and Monitor Devices. You can search for, add, edit, delete, change display status, and load devices from the seed file.

•

HW-Based Security Devices. Hardware-based devices represent routers, switches, and other dedicated security appliances. You can add such reporting devices by selecting the appropriate device.

•

SW-Based Security Devices. Software-based devices represent applications that reside on a host, rather than a dedicated appliance. You can add reporting device on a new host by selecting Add SW security apps on new host or on an existing host by selecting Add SW security apps on existing host.

•

On-Demand Security Services. Security services represent subscription-based services provided by vendors using a central security operations center (SOC) with remote monitoring nodes. These services, such as Qualys QualysGuard, represent systems from which MARS periodically pulls data. You can add such reporting devices by selecting the appropriate service. These devices also require you to define a schedule for pulling data (see Scheduling Topology Updates).

The complete list of supported devices is presented in the Supported Devices and Software Versions for Cisco Security MARS Local Controller 4.2.x and 5.2.x document. Devices are added to this list on an ongoing basis via software upgrade packages. See Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System for details on how to upgrade your MARS Appliance.

MARS can also support any syslog or SNMP devices, even if they do not appear on the list of devices supported by the MARS. You can enter any syslog or SNMP device into the network topology, configure it to report data to the MARS, and query it using a free-form query. (See To Run a Free-form Query, page 21-2.)

Regardless of the method that you have used to add the devices, you should also perform the following tasks:

Add Reporting and Mitigation Devices Individually

In general, you have two choices for adding devices that you want to monitor into your MARS. You can create a seed file or you can add each device manually. Seed file support is limited to a few device types, see Column E for the devices supported.

When manually configuring devices, select the devices that are most interesting to you. Once added, you can come back and edit them as necessary. Manual configuration is also useful when you add or change a single security device on your network.

Note Remember that you do not have to add all of the devices configuration information at once. You can start by adding the device's name and its access IP address. You can always return later, when the MARS starts to report to you, and provide more details.

Step 1

Click Admin > System Setup > Security and Monitor Devices > Add.

Step 5

Once add a device, you must click Activate for MARS to correctly process events received from that device. For more information, see Activate the Reporting and Mitigation Devices.

Edit a Device

Upgrade the Device Type to a Newer Version

You can change the Device Type version setting of a hardware-based security device. You cannot upgrade the version for software applications running on a host. To upgrade the software appliance version, you must remove the application from the host and add the newer one.

This version change feature applies only to device types with the same vendor and model but different versions. Specifically, you can change the version for the following device types:

For example, you could change the settings for the device type Cisco PIX 6.1 to Cisco PIX 7.0 without having to delete the device and add it again. The benefit of matching the version setting to the deployed device is that it allows MARS to correlate any event types introduced in the more recent version. It also allows you to incrementally upgrade your reporting devices without having to worry about when to add that reporting device to MARS. The events that are correlated under one device type will be associated with the newer device type version when you make the change in MARS.

Step 2

Select the checkbox to the left of the device for which you want to change the version, and click Change Version.

The Change the Device Type Version page appears, displaying the device name, vendor, model, and old version type information.

Step 4

To change the version of the device to the new version, click Submit.

If any additional changes are available due to the version change, the Edit page appears.

Step 5

If the Edit page appears, make any desired changes and click Submit.

Step 6

Once you change the version setting for a device, you must click Activate for MARS to correctly process events received from that device. For more information, see Activate the Reporting and Mitigation Devices.

Delete a Device

When you define a reporting device in MARS, this device is added in two separate pages of the web interface. It appears where you have defined it, on the Admin > Security and Monitoring Devices page, as well as under the general device identification page under Management > IP Management. This duplication of content is based on the different functions that each of these pages serves.

The Security and Monitoring Devices page configures the contact and device type information, whereas the IP Management page is used by the parser module to correlate known devices versus unknown devices. Typically when you delete a device from the Security and Monitoring Device page, you still want to retain the knowledge of that device in MARS so that historical incidents and events and cases can resolve to a known device; therefore, the device is not deleted from the IP Management page.

Note Deleting a device does disassociate any historical incidents and events from the IP address. In other words, once you delete the device, you will not be able to find historical events for that device even if you re-add the device at a later date.

However, if you need to delete and re-add a device to MARS, you must delete the device from both pages before you attempt to re-add the device.

In addition, as devices are discovered on your network, they are added to the list of devices in the IP Management page. If you want to add a reporting device and find that you cannot, review the list of devices in the IP Management page to ensure that the device has not been auto-populated. If it has, you must first delete that device, then you can add it as a reporting device on the Security and Monitoring Devices page.

Delete All Displayed Reporting Devices

You can perform this procedure from the Admin > Security and Monitoring Devices page.

Step 1

On the Admin > Security and Monitoring Devices, select the checkbox to the left of the Device Name column heading at the top left of the table.

A page appears prompting you to confirm that you want to delete the list of devices.

Add Multiple Reporting and Mitigation Devices Using a Seed File

The seed file is a comma-delimited file with the file extension .csv (comma-separated value). Most spreadsheet programs let you import and export files as CSV files.

The following is a sample seed file as exported from a popular spreadsheet program:

With the CSV file, you can enter the values, passwords, and information for each device that you want the MARS Appliance to monitor in its appropriate row and column. While the seed file is useful for getting the MARS Appliance started processing event data for most devices, you may need to use the Admin > System Setup > Security and Monitoring Devices page to fine-tune the device manually. In addition, you must Activate the devices that you add using a seed file (see Activate the Reporting and Mitigation Devices).

Devices that Require Custom Seed Files

Some reporting devices represent the management consoles for the actual host- or node-based reporting devices. These consoles often represent centralized log servers for the devices they manage. However, for MARS to correctly correlate the logs for these centralized log servers, you must identify those host- or node-based reporting device. In some cases, MARS is able to dynamically learn of the hosts or nodes by parsing the logs. In other cases, you must use a seed file generated by management console to identify each of the managed reporting devices.

Once you generate the seed file, you must import that seed file under the host that represents the management console in the MARS web interface to load the sensor module information from the CSV or seed file. The device types that use a custom seed file are as follows:

•

Cisco Security Agent. While MARS can learn of the CSA agents dynamically, you can also import the initial list of agents using a custom seed file. For more information, see Export CSA Agent Information to File.

•

Symantec AntiVirus. While MARS can learn of the Symantec AntiVirus agents dynamically, you can also import the initial list of agents using a custom seed file. For more information, see Export the AntiVirus Agent List.

Devices that Require Updates After the Seed File Import

When you add specific reporting devices using a seed file, you must edit them to complete the definition of the device before you can monitor them. Typically, these devices are IDS/IPS devices that monitor specific networks. The device types that you must update are as follows:

•

IntruShield Senors. These sensors are defined by importing a custom seedfile; however, once you import the sensors, which appear as children of the IntruShield Manager host, you must identify the monitored networks for each sensor. For more information, see Add IntruShield Sensors Using a Seed File.

Seed File Header Columns

Table 2-4 describes the columns in the seed files and identifies valid values. If you do not enter a value for a given column, you must enter a comma to delineate that column.

Note Remember that you do not have to add all of the devices' configuration information at once. You can start by adding the device's name and its access IP address. You can always return later, when the MARS starts to report to you, and provide more details.

Table 2-4 Seed File Column Description
Column	Type	Entry
Column A	NAME OR IP	The device's name or IP address. (Mandatory) If the device name is provided and Column U is empty, MARS performs a DNS lookup to identify the address which will be used to populate the Access and Reporting IP fields Note If an IP address appears in Column U, that address overrides any address or derived address specified in Column A. However, the name value specified in Column A is used.
Column B	SNMP RO/RW Community	The device's SNMP RO community name here. Note MARS does not support the following characters in the SNMP RO community string: ' (single quote), " (double quote), < (less than symbol), and > (greater than symbol).
Column C	EMPTY	Empty placeholder column.
Column D	EMPTY	Empty placeholder column.
Column E	DEVICE TYPE	The device type designator. (case insensative) Note Some of the devices supported in the GUI cannot be entered via a CSV file. Use the following strings represent the desired device type: •`ASA`: for Cisco ASA devices •`CiscoIDS4x`: for applaince running Cisco IPS 4.x (not modules) •`CiscoIPS5x`: for appliance running Cisco IPS 5.x (not modules) •`FWSM`: for Cisco FWSM 2.3 •`FWSM`3: for Cisco FWSM 3.1 •`PIX`: for Cisco PIX 6.0, 6.1, 6.2, and 6.3 devices •`PIX7X`: for Cisco PIX 7.0 devices •`IOS`: for Cisco IOS 12.2 (default) •`SWITCH-CATOS`: for Cisco Switch in Hybrid Mode •`SWITCH-IOS`: for Cisco Switch in Native Mode •`EXTREME`: for Extreme ExtremeWare 6.x •`NETSCREEN`: for ScreenOS 4.0 and 5.0 •`WINDOWS`: for Window host •`Windows2000`: for Windows 2000 host •`Windows2003`: for Windows 2003 host •`WindowsNT`: for Windows NT 4.x host. •`SOLARIS`: for Solaris host •`LINUX`: for Linux host Note In the case of host files, Linux, Solaris, and Windows, MARS is configured by default to receive events from the hosts specified in a seed file. However, for a Windows host where the RPC settings are also specified in the seed file, MARS will both pull and receive logs from the host by default.
Column F	ACCESS TYPE	The Access Type for this device. Your choices are: •TELNET •FTP •SSH •SNMP (default) •RPC (Windows only) In the RPC case, the username field ( Column G) should be non-empty. The password can be provided in Column H. If RPC access type and username are given, the PULL flag is set by the backend in addition to the default RECEIVE flag.
Column G	USER NAME	The TELNET, SSH, FTP, or RPC user name. This column is only valid if you have used TELNET, SSH, or FTP in Column F.
Column H	SSH/FTP/RPC PASSWORD	The SSH or FTP Password for the device. This column is only valid if you have used SSH or FTP in Column F.
Column I	TELNET PASSWORD	The Telnet password for the device.
Column J	ENABLE PASSWORD	The enable password (applicable only with FWSM, PIX, or IOS devices).
Columns K	EMPTY	Emplty placeholder column.
Column L	EMPTY	Emplty placeholder column.
Column M	EMPTY	Emplty placeholder column.
Column N	EMPTY	Emplty placeholder column.
Column O	EMPTY	Emplty placeholder column.
Column P	EMPTY	Emplty placeholder column.
Column Q	EMPTY	Emplty placeholder column.
Column R	EMPTY	Emplty placeholder column.
Column S	EMPTY	Emplty placeholder column.
Column T	FTP LOCATION [if Access Type =FTP]	The location for the FTP file. This location starts from the FTP root, not the sysroot. If, for example, the file is at `<ftproot>/configdata/router1.txt`, using ./`configdata/router1.txt` is correct.
Column U	Access/Reporting IP [optional]	The Access IP and Reporting IP address to use when populating this device. The MARS Appliance uses this address to communicate with the device. See Understanding Access IP, Reporting IP, and Interface Settings

Load Devices From the Seed File

Once you have completed the seed file, you must the CSV file on to the FTP server where you want to upload it.

Step 1

Click Admin > System Setup > Security and Monitor Devices > Load From Seed File.

Step 2

Enter the FTP Server's IP address, the user name and password for the FTP server, the path, and the file name for the seed file.

The FTP path starts from the FTP root, not from the sysroot for the configuration path.

Once you have loaded devices from the seed file, return to each device. Continue to configure the devices and to add information such as reporting IP addresses, and SNMP information.

Step 4

Once add a device, you must click Activate for MARS to correctly process events received from that device. For more information, see Activate the Reporting and Mitigation Devices.

Note Using a seed file to define the reporting devices replaces the manual definition of the device; however, the topology information will not be available. After adding the reporting devices via a seed file, you must either manually discover each device by selecting the device, clicking Edit, and then clicking the Discover button or by scheduling a topology discovery. In addition, some device types required that you define additional settings (see Devices that Require Updates After the Seed File Import).

Adding Reporting and Mitigation Devices Using Automatic Topology Discovery

On the Admin page, under the Topology Discovery Information section, three links exist, allowing you to define the settings required to discover reporting and mitigation devices automatically. These links are:

Table Of Contents