Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
User Guide for Cisco Security MARS
Local Controller
Release 4.2.x
December 2006
Customer Order Number:
Text Part Number: 78-17020-01
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant
to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial
environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause
harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required
to correct the interference at their own expense.
The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not
installed in accordance with Cisco’s installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to
comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable
protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation.
Modifying the equipment without Cisco’s written authorization may result in the equipment no longer complying with FCC requirements for Class A or Class B digital
devices. In that event, your right to use the equipment may be limited by FCC regulations, and you may be required to correct any interference to radio or television
communications at your own expense.
You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the Cisco equipment or one of its
peripheral devices. If the equipment causes interference to radio or television reception, try to correct the interference by using one or more of the following measures:
• Turn the television or radio antenna until the interference stops.
• Move the equipment to one side or the other of the television or radio.
• Move the equipment farther away from the television or radio.
• Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television or radio are on circuits
controlled by different circuit breakers or fuses.)
Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate your authority to operate the product.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
User Guide for Cisco Security MARS Local Controller
Copyright © 2006 Cisco Systems, Inc. All rights reserved.
CCVP, the Cisco logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a
service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco
Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networking Academy,
Network Registrar, Pack e t , PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath are
registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (0705R)
iii
User Guide for Cisco Security MARS Local Controller
78-17020-01
CONTENTS
Preface xix
Introduction xix
The MARS Appliance xix
The MARS Web Interface xix
About This Manual xx
Obtaining Documentation xxi
Cisco.com xxi
Product Documentation DVD xxi
Ordering Documentation xxii
Documentation Feedback xxii
Cisco Product Security Overview xxii
Reporting Security Problems in Cisco Products xxii
Product Alerts and Field Notices xxiii
Obtaining Technical Assistance xxiii
Cisco Support Website xxiii
Submitting a Service Request xxiv
Definitions of Service Request Severity xxv
Obtaining Additional Publications and Information xxv
CHAPTER
1 STM Task Flow Overview 1-1
Checklist for Provisioning Phase 1-2
Checklist for Monitoring Phase 1-9
Strategies for Monitoring, Notification, Mitigation, Remediation, and Audit 1-16
Appliance-side Tuning Guidelines 1-17
Device Inventory Worksheet 1-18
User Role Worksheet 1-20
CHAPTER
2 Reporting and Mitigation Devices Overview 2-1
Levels of Operation 2-1
Selecting the Devices to Monitor 2-2
Understanding Access IP, Reporting IP, and Interface Settings 2-8
Access IP 2-9
Contents
iv
User Guide for Cisco Security MARS Local Controller
78-17020-01
Reporting IP 2-9
Interface Settings 2-10
Selecting the Access Type 2-10
Configure SNMP Access for Devices in MARS 2-11
Configure Telnet Access for Devices in MARS 2-11
Configure SSH Access for Devices in MARS 2-12
Configure FTP Access for Devices in MARS 2-12
Bootstrap Summary Table 2-12
Adding Reporting and Mitigation Devices 2-16
Add Reporting and Mitigation Devices Individually 2-17
Edit a Device 2-18
Upgrade the Device Type to a Newer Version 2-18
Delete a Device 2-19
Delete All Displayed Reporting Devices 2-20
Add Multiple Reporting and Mitigation Devices Using a Seed File 2-20
Devices that Require Custom Seed Files 2-21
Devices that Require Updates After the Seed File Import 2-21
Seed File Header Columns 2-21
Load Devices From the Seed File 2-24
Adding Reporting and Mitigation Devices Using Automatic Topology Discovery 2-25
Verify Connectivity with the Reporting and Mitigation Devices 2-26
Discover and Testing Connectivity Options 2-26
Run a Reporting Device Query 2-27
Activate the Reporting and Mitigation Devices 2-27
Data Enabling Features 2-28
Layer 2 Discovery and Mitigation 2-29
Networks for Dynamic Vulnerability Scanning 2-29
Select a Network for Scanning 2-30
Create a Network IP Address for Scanning 2-30
Create a Network IP Range for Scanning 2-30
Understanding NetFlow Anomaly Detection 2-30
How MARS Uses NetFlow Data 2-31
Guidelines for Configuring NetFlow on Your Network 2-32
Enable Cisco IOS Routers and Switches to Send NetFlow to MARS 2-32
Configuring Cisco CatIOS Switch 2-34
Enable NetFlow Processing in MARS 2-34
Host and Device Identification and Detail Strategies 2-36
Configuring Layer 3 Topology Discovery 2-37
Add a Community String for a Network 2-37
Contents
v
User Guide for Cisco Security MARS Local Controller
78-17020-01
Add a Community String for an IP Range 2-37
Add Valid Networks to Discovery List 2-38
Remove Networks from Discovery List 2-38
Discover Layer 3 Data On Demand 2-38
Scheduling Topology Updates 2-39
Schedule a Network Discovery 2-40
To edit a scheduled topology discovery 2-40
To delete a scheduled topology discovery 2-41
To run a topology discovery on demand 2-41
Configuring Resource Usage Data 2-41
Enabling the Required SNMP OIDs for Resource Monitoring 2-42
Configuring Network Admission Control Features 2-52
Integrating MARS with 3rd-Party Applications 2-54
Forwarding Alert Data to 3rd-Party Syslog and SNMP Servers 2-54
MARS MIB Format 2-54
Relaying Syslog Messages from 3rd-Party Syslog Servers 2-56
Configure Syslog-ng Server to Forward Events to MARS 2-56
Configure Kiwi Syslog Server to Forward Events to MARS 2-57
Add Syslog Relay Server to MARS 2-57
Add Devices Monitored by Syslog Relay Server 2-58
CHAPTER
3 Configuring Router and Switch Devices 3-1
Cisco Router Devices 3-1
Enable Administrative Access to Devices Running Cisco IOS 12.2 3-1
Enable SNMP Administrative Access 3-2
Enable Telnet Administrative Access 3-2
Enable SSH Administrative Access 3-2
Enable FTP-based Administrative Access 3-2
Configure the Device Running Cisco IOS 12.2 to Generate Required Data 3-3
Enable Syslog Messages 3-3
Enable SNMP RO Strings 3-3
Enable NAC-specific Messages 3-4
Enable SDEE for IOS IPS Software 3-6
Add and Configure a Cisco Router in MARS 3-6
Cisco Switch Devices 3-9
Enable Communications Between Devices Running CatOS and MARS 3-9
Enable SNMP Administrative Access 3-10
Enable Telnet Administrative Access 3-10
Enable SSH Administrative Access 3-10
Contents
vi
User Guide for Cisco Security MARS Local Controller
78-17020-01
Enable FTP-based Administrative Access 3-10
Configure the Device Running CatOS to Generate Required Data 3-11
Enable SNMP RO Strings on CatOS 3-11
Enable Syslog Messages on CatOS 3-11
Enable L2 Discovery Messages 3-12
Add and Configure a Cisco Switch in MARS 3-13
Adding Modules to a Cisco Switch 3-14
Add Available Modules 3-14
Add Cisco IOS 12.2 Modules Manually 3-15
Extreme ExtremeWare 6.x 3-17
Configure ExtremeWare to Generate the Required Data 3-17
Add and Configure an ExtremeWare Switch in MARS 3-18
Generic Router Device 3-18
Add and Configure a Generic Router in MARS 3-19
CHAPTER
4 Configuring Firewall Devices 4-1
Cisco Firewall Devices (PIX, ASA, and FWSM) 4-1
Bootstrap the Cisco Firewall Device 4-2
Enable Telnet Access on a Cisco Firewall Device 4-4
Enable SSH Access on a Cisco Firewall Device 4-4
Send Syslog Files From Cisco Firewall Device to MARS 4-4
Device-Side Tuning for Cisco Firewall Device Syslogs 4-6
Logging Message Command 4-6
List of Cisco Firewall Message Events Processed by MARS 4-7
Add and Configure a Cisco Firewall Device in MARS 4-8
Add Security Contexts Manually 4-11
Add Discovered Contexts 4-12
Edit Discovered Security Contexts 4-13
NetScreen ScreenOS Devices 4-14
Bootstrap the NetScreen Device 4-15
Add the NetScreen Device to MARS 4-20
Check Point Devices 4-22
Determine Devices to Monitor and Restrictions 4-24
Bootstrap the Check Point Devices 4-25
Add the MARS Appliance as a Host in Check Point 4-26
Define an OPSEC Application that Represents MARS 4-27
Obtain the Server Entity SIC Name 4-30
Select the Access Type for LEA and CPMI Traffic 4-32
Create and Install Policies 4-34
Contents
vii
User Guide for Cisco Security MARS Local Controller
78-17020-01
Verify Communication Path Between MARS Appliance and Check Point Devices 4-36
Reset the OPSEC Application Certificate of the MARS Appliance 4-36
Add and Configure Check Point Devices in MARS 4-39
Add a Check Point Primary Management Station to MARS 4-40
Manually Add a Child Enforcement Module or Log Server to a Check Point Primary Management
Station
4-44
Add a Check Point Certificate Server 4-47
Edit Discovered Log Servers on a Check Point Primary Management Station 4-48
Edit Discovered Firewall on a Check Point Primary Management Station 4-50
Define Route Information for Check Point Firewall Modules 4-50
Specify Log Info Settings for a Child Enforcement Module or Log Server 4-52
Verify Connectivity Between MARS and Check Point Devices 4-55
Remove a Firewall or Log Server from a Check Point Primary Management Station 4-55
Troubleshooting MARS and Check Point 4-56
CHAPTER
5 Configuring VPN Devices 5-1
Cisco VPN 3000 Concentrator 5-1
Bootstrap the VPN 3000 Concentrator 5-1
Add the VPN 3000 Concentrator to MARS 5-2
CHAPTER
6 Configuring Network-based IDS and IPS Devices 6-1
Cisco IDS 3.1 Sensors 6-1
Configure Sensors Running IDS 3.1 6-1
Add and Configure a Cisco IDS 3.1 Device in MARS 6-4
Cisco IDS 4.0 and IPS 5.x Sensors 6-5
Bootstrap the Sensor 6-5
Enable the Access Protocol on the Sensor 6-6
Enable the Correct Signatures and Actions 6-6
Add and Configure a Cisco IDS or IPS Device in MARS 6-6
Specify the Monitored Networks for Cisco IPS or IDS Device Imported from a Seed File 6-8
View Detailed Event Data for Cisco IPS Devices 6-9
Verify that MARS Pulls Events from a Cisco IPS Device 6-10
Cisco IPS Modules 6-10
Enable DTM Support 6-10
Enable SDEE on the Cisco IOS Device with an IPS Module 6-11
Add an IPS Module to a Cisco Switch or Cisco ASA 6-11
ISS Site Protector 6-13
ISS RealSecure 6.5 and 7.0 6-17
Configure ISS RealSecure to Send SNMP Traps to MARS 6-18
Contents
viii
User Guide for Cisco Security MARS Local Controller
78-17020-01
Add an ISS RealSecure Device as a NIDS 6-19
Add an ISS RealSecure Device as a HIDS 6-20
IntruVert IntruShield 6-22
Extracting Intruvert Sensor Information from the IntruShield Manager 6-22
Configure IntruShield Version 1.5 to Send SNMP traps to MARS 6-23
Configure IntruShield Version 1.8 to Send SNMP Traps to MARS 6-23
Add and Configure an IntruShield Manager and its Sensors in MARS 6-25
Add the IntruShield Manager Host to MARS 6-26
Add IntruShield Sensors Manually 6-26
Add IntruShield Sensors Using a Seed File 6-27
Snort 2.0 6-28
MARS Expectations of the Snort Syslog Format 6-28
Configure Snort to Send Syslogs to MARS 6-28
Add the Snort Device to MARS 6-28
Symantec ManHunt 6-29
Symantec ManHunt Side Configuration 6-29
MARS Side Configuration 6-31
Add Configuration Information for Symantec ManHunt 3.x 6-31
NetScreen IDP 2.1 6-31
IDP-side Configuration 6-31
MARS-side Configuration 6-32
Add Configuration Information for the IDP 6-32
Add NetScreen IDP 2.1 Sensors Manually 6-32
Enterasys Dragon 6.x 6-33
DPM/EFP Configuration 6-33
Configure the DPM or EFP 6-33
Host-side Configuration 6-34
Configure the syslog on the UNIX host 6-34
MARS-side Configuration 6-34
Add Configuration Information for the Enterasys Dragon 6-34
Add a Dragon NIDS Device 6-35
Contents
ix
User Guide for Cisco Security MARS Local Controller
78-17020-01
CHAPTER
7 Configuring Host-Based IDS and IPS Devices 7-1
Entercept Entercept 2.5 and 4.0 7-1
Extracting Entercept Agent Information into a CSV file (for Entercept Version 2.5) 7-1
Create a CSV file for Entercept Agents in Version 2.5 7-2
Define the MARS Appliance as an SNMP Trap Target 7-2
Specific the Events to Generate SNMP Traps for MARS 7-2
Add and Configure an Entercept Console and its Agents in MARS 7-3
Add the Entercept Console Host to MARS 7-3
Add Entercept Agents Manually 7-4
Add Entercept Agents Using a Seed File 7-4
Cisco Security Agent 4.x Device 7-5
Configure CSA Management Center to Generate Required Data 7-5
Configure CSA MC to Forward SNMP Notifications to MARS 7-6
Export CSA Agent Information to File 7-6
Add and Configure a CSA MC Device in MARS 7-7
Add a CSA Agent Manually 7-8
Add CSA Agents From File 7-9
Troubleshooting CSA Agent Installs 7-10
CHAPTER
8 Configuring Antivirus Devices 8-1
Symantec AntiVirus Configuration 8-1
Configure the AV Server to Publish Events to MARS Appliance 8-1
Export the AntiVirus Agent List 8-7
Add the Device to MARS 8-7
Add Agent Manually 8-7
Add Agents from a CSV File 8-8
McAfee ePolicy Orchestrator Devices 8-8
Configure ePolicy Orchestrator to Generate Required Data 8-8
Add and Configure ePolicy Orchestrator Server in MARS 8-12
Cisco Incident Control Server 8-13
Configure Cisco ICS to Send Syslogs to MARS 8-14
Add the Cisco ICS Device to MARS 8-15
Define Rules and Reports for Cisco ICS Events 8-15
Contents
x
User Guide for Cisco Security MARS Local Controller
78-17020-01
CHAPTER
9 Configuring Vulnerability Assessment Devices 9-1
Foundstone FoundScan 3.0 9-1
Configure FoundScan to Generate Required Data 9-2
Add and Configure a FoundScan Device in MARS 9-2
eEye REM 1.0 9-3
Configure eEye REM to Generate Required Data 9-4
Add and Configure the eEye REM Device in MARS 9-4
Qualys QualysGuard Devices 9-5
Configure QualysGuard to Scan the Network 9-6
Add and Configure a QualysGuard Device in MARS 9-6
Schedule the Interval at Which Data is Pulled 9-8
Troubleshooting QualysGuard Integration 9-9
CHAPTER
10 Configuring Generic, Solaris, Linux, and Windows Application Hosts 10-1
Adding Generic Devices 10-1
Sun Solaris and Linux Hosts 10-2
Configure the Solaris or Linux Host to Generate Events 10-2
Configure Syslogd to Publish to the MARS Appliance 10-2
Configure MARS to Receive the Solaris or Linux Host Logs 10-3
Microsoft Windows Hosts 10-4
Push Method: Configure Generic Microsoft Windows Hosts 10-5
Install the SNARE Agent on the Microsoft Windows Host 10-5
Enable SNARE on the Microsoft Windows Host 10-6
Pull Method: Configure the Microsoft Windows Host 10-6
Enable Windows Pulling Using a Domain User 10-7
Enable Windows Pulling from Windows NT 10-7
Enable Windows Pulling from a Windows 2000 Server 10-7
Windows Pulling from a Windows Server 2003 or Windows XP Host 10-8
Configure the MARS to Pull or Receive Windows Host Logs 10-9
Windows Event Log Pulling Time Interval 10-11
Define Vulnerability Assessment Information 10-12
Identify Network Services Running on the Host 10-14
Contents
xi
User Guide for Cisco Security MARS Local Controller
78-17020-01
CHAPTER
11 Configuring Database Applications 11-1
Oracle Database Server Generic 11-1
Configure the Oracle Database Server to Generate Audit Logs 11-1
Add the Oracle Database Server to MARS 11-2
Configure Interval for Pulling Oracle Event Logs 11-3
CHAPTER
12 Configuring Web Server Devices 12-1
Microsoft Internet Information Sever 12-1
Install and Configure the Snare Agent for IIS 12-1
To configure IIS for web logging 12-2
MARS-side Configuration 12-5
To add configuration information for the host 12-5
Apache Web Server on Solaris or RedHat Linux 12-7
Sun Java System Web Server on Solaris 12-7
Generic Web Server Generic 12-7
Solaris or Linux-side Configuration 12-7
Install and Configure the Web Agent on UNIX or Linux 12-7
Web Server Configuration 12-8
To configure the Apache web server for the agent 12-8
To configure the iPlanet web server for the agent 12-8
MARS-side Configuration 12-9
To add configuration information for the host 12-9
CHAPTER
13 Configuring Web Proxy Devices 13-1
Network Appliance NetCache Generic 13-1
Configure NetCache to Send Syslog to MARS 13-1
Add and Configure NetCache in MARS 13-2
CHAPTER
14 Configuring AAA Devices 14-1
Supporting Cisco Secure ACS Server 14-2
Supporting Cisco Secure ACS Solution Engine 14-2
Bootstrap Cisco Secure ACS 14-3
Configure Cisco Secure ACS to Generate Logs 14-3
Define AAA Clients 14-5
Configure TACACS+ Command Authorization for Cisco Routers and Switches 14-7
Install and Configure the PN Log Agent 14-7
Upgrade PN Log Agent to a Newer Version 14-10
Application Log Messages for the PN Log Agent 14-10
Contents
xii
User Guide for Cisco Security MARS Local Controller
78-17020-01
Add and Configure the Cisco ACS Device in MARS 14-12
CHAPTER
15 Configuring Custom Devices 15-1
Adding User Defined Log Parser Templates 15-1
Define a Custom Device/Application Type 15-2
Add Parser Log Templates for the Custom Device/Application 15-3
Add Custom Device or Application as Reporting Device 15-13
CHAPTER
16 Policy Table Lookup on Cisco Security Manager 16-1
Overview of Cisco Security Manager Policy Table Lookup 16-1
More About Cisco Security Manager Device Lookup 16-3
More About Cisco Security Manager Policy Table Lookup 16-4
Prerequisites for Policy Table Lookup 16-4
Restrictions for Policy Table Lookup 16-5
Checklist for Security Manager-to-MARS Integration 16-6
Bootstrapping Cisco Security Manager Server to Communicate with MARS 16-12
Add a Cisco Security Manager Server to MARS 16-13
Procedure for Invoking Cisco Security Manager Policy Table Lookup from Cisco Security MARS 16-14
CHAPTER
17 Network Summary 17-1
Navigation within the MARS Appliance 17-1
Logging In 17-1
Basic Navigation 17-2
Help Page 17-4
Your Suggestions Welcomed 17-4
Summary Page 17-6
Dashboard 17-6
Recent Incidents 17-8
Sessions and Events 17-8
Data Reduction 17-9
Page Refresh 17-9
Diagrams 17-9
Manipulating the Diagrams 17-11
Display Devices in Topology 17-12
Network Status 17-12
Reading Charts 17-13
My Reports 17-15
To set up reports for viewing 17-15
Contents
xiii
User Guide for Cisco Security MARS Local Controller
78-17020-01
CHAPTER
18 Case Management 18-1
Case Management Overview 18-1
Case Management Considerations for the Global Controller 18-3
Hide and Display the Case Bar 18-3
Create a New Case 18-4
Edit and Change the Current Case 18-5
Add Data to a Case 18-6
Generate and Email a Case Report 18-7
CHAPTER
19 Incident Investigation and Mitigation 19-1
Incidents Overview 19-1
The Incidents Page 19-2
Time ranges for Incidents 19-4
Incident Details Page 19-4
To Search for a Session ID or Incident ID 19-4
Incident Details Table 19-5
False Positive Confirmation 19-6
The False Positive Page 19-8
To Tune a False Positive 19-9
To Tune an Unconfirmed False Positive to False Positive 19-9
To Tune an Unconfirmed False Positive to True Positive 19-9
To Activate False Positive Drop Rules 19-10
Mitigation 19-10
802.1X Mitigation Example 19-11
Prerequisites for Mitigation with 802.1X Network Mapping 19-11
Procedure for Mitigation with 802.1X Network Mapping 19-11
Display Dynamic Device Information 19-15
Virtual Private Network Considerations 19-17
Layer 2 Path and Mitigation Configuration Example 19-17
Prerequisites for Layer 2 Path and Mitigation 19-17
Components Used 19-17
Network Diagram 19-18
Procedures for Layer 2 Path and Mitigation 19-19
Add the Cisco Catalyst 5000 with SNMP as the Access Type. 19-19
Add the Cisco Catalyst 6500 with SNMP as Access Type (Layer 2 only). 19-20
Add the Cisco 7500 Router with TELNET as the Access Type 19-21
Verify the Connectivity Paths for Layer 3 and Layer 2 19-22
Perform Mitigation 19-26
Contents
xiv
User Guide for Cisco Security MARS Local Controller
78-17020-01
CHAPTER
20 Queries and Reports 20-1
Queries 20-1
To Run a Quick Query 20-2
To Run a Free-form Query 20-2
To Run a Batch Query 20-3
To Stop a Batch Query 20-4
To Resubmit a Batch Query 20-4
To Delete a Batch Query 20-5
Selecting the Query Type 20-5
Result Format 20-5
Order/Rank By 20-7
Filter By Time 20-8
Use Only Firing Events 20-8
Maximum Number of Rows Returned 20-8
Selecting Query Criteria 20-9
To Select a Criterion 20-9
Query Criteria 20-10
Source IP 20-10
Destination IP 20-11
Service 20-11
Event Types 20-11
Device 20-11
Severity/Zone 20-12
Operation 20-12
Rule 20-12
Action 20-12
Saving the Query 20-13
Viewing Events in Real-time 20-13
Restrictions for Real-time Event Viewer 20-13
Procedure for Invoking the Real-Time Event Viewer 20-14
Perform a Long-Duration Query Using a Report 20-17
View a Query Result in the Report Tab 20-19
Perform a Batch Query 20-20
Reports 20-23
Report Type Views: Total vs. Peak vs. Recent 20-24
Creating a Report 20-25
Working With Existing Reports 20-25
Contents
xv
User Guide for Cisco Security MARS Local Controller
78-17020-01
CHAPTER
21 Rules 21-1
Rules Overview 21-1
Prioritizing and Identifying 21-2
Think Like a Black Hat 21-2
Planning an Attack 21-2
Back to Being the Admin 21-3
Types of Rules 21-4
Inspection Rules 21-4
Global User Inspection Rules 21-4
Drop Rules 21-4
Constructing a Rule 21-5
Working Examples 21-16
Example A: Excessive Denies to a Particular Port on the Same Host 21-16
Example B: Same Source Causing Excessive Denies on a Particular Port 21-16
Example C: Same Host, Same Destination, Same Port Denied 21-16
Working with System and User Inspection Rules 21-17
Change Rule Status—Active and Inactive 21-17
Duplicate a Rule 21-17
Edit a Rule 21-18
Add an Inspection Rule 21-19
Working with Drop Rules 21-21
Change Drop Rule Status— Active and Inactive 21-21
Duplicate a Drop Rule 21-21
Edit a Drop Rule 21-22
Add a Drop Rule 21-22
Setting Alerts 21-23
Configure an Alert for an Existing Rule 21-24
Rule and Report Groups 21-24
Rule and Report Group Overview 21-25
Global Controller and Local Controller Restrictions for Rule and Report Groups 21-26
Add, Modify, and Delete a Rule Group 21-27
Add, Modify, and Delete a Report Group 21-30
Display Incidents Related to a Rule Group 21-32
Create Query Criteria with Report Groups 21-33
Using Rule Groups in Query Criteria 21-34
Contents
xvi
User Guide for Cisco Security MARS Local Controller
78-17020-01
CHAPTER
22 Sending Alerts and Incident Notifications 22-1
Configure the E-mail Server Settings 22-4
Configure a Rule to Send an Alert Action 22-5
Create a New User—Role, Identity, Password, and Notification Information 22-10
Create a Custom User Group 22-12
Add a User to a Custom User Group 22-13
CHAPTER
23 Management Tab Overview 23-1
Activating 23-1
To activate a set of management additions or changes 23-1
Event Management 23-1
Search for an Event Description or CVE Names 23-2
To view a list of all currently supported CVEs 23-2
Event Groups 23-2
To filter by event groups or severity 23-2
Edit a Group of Events 23-2
Add a Group 23-3
IP Management 23-3
Search for an Address, Network, Variable, or Host 23-3
Filter by Groups 23-3
Edit a Group 23-4
Add a Group 23-4
Add a Network, IP Range, or Variable 23-4
Add a Host 23-5
Edit Host Information 23-6
Service Management 23-7
Search for a Service 23-7
Add a Group of Services 23-7
Edit a Group of Services 23-7
Add a Service 23-8
Edit a Service 23-8
Delete a Service 23-8
User Management 23-8
Add a New User 23-9
Add a Service Provider (Cell phone/Pager) 23-11
Search for a User 23-11
Edit or Remove a User 23-12
Create a User Group 23-12
Contents
xvii
User Guide for Cisco Security MARS Local Controller
78-17020-01
Add or Remove a User from a User Group 23-12
Filter by Groups 23-13
CHAPTER
24 System Maintenance 24-1
Setting Runtime Logging Levels 24-1
Viewing the MARS Backend Log Files 24-2
View the Backend Log 24-2
Viewing the Audit Trail 24-3
View an Audit Trail 24-3
Retrieving Raw Messages 24-3
Retrieve Raw Messages From Archive Server 24-4
Retrieve Raw Messages From a Local Controller 24-5
Change the Default Password of the Administrator Account 24-7
Understanding Certificate and Fingerprint Validation and Management 24-7
Setting the Global Certificate and Fingerprint Response 24-9
Upgrading from an Expired Certificate or Fingerprint 24-9
Upgrade a Certificate or Fingerprint Interactively 24-10
Upgrade a Certificate Manually 24-10
Upgrade a Fingerprint Manually 24-10
Monitoring Certificate Status and Changes 24-10
Hardware Maintenance Tasks—MARS 100, 100E, 200, GCM,
and GC
24-11
Replacing the Lithium Cell CMOS Battery 24-11
Hard Drive Troubleshooting and Replacement 24-12
Status Lights 24-12
Partition Checking 24-12
Hotswapping Hard Drives 24-12
Overview of MARS RAID 10 Subsystem 24-12
RAID Procedures for MARS Appliances 100, 100E, 200, GCM, and GC 24-13
Correlating Hard Drive Slots to RAIDSTATUS Command Physical Port Numbers 24-16
Hotswap Procedure To Remove and Add a Hard Drive 24-18
Hotswap CLI Example 24-19
Procedures for the MARS RAID Utility 24-20
24-25
Contents
xviii
User Guide for Cisco Security MARS Local Controller
78-17020-01
APPENDIX
A Cisco Security MARS XML API Reference A-1
XML Schema Overview A-1
XML Incident Notification Data File and Schema A-1
XML Incident Notification Data File Sample Output A-2
XML Incident Notification Schema A-6
Usage Guidelines and Conventions for XML Incident Notification A-6
APPENDIX
B Regular Expression Reference B-1
PCRE Regular Expression Details B-1
Backslash B-2
Non-printing Characters B-3
Generic Character Types B-4
Unicode Character Properties B-5
Simple Assertions B-6
Circumflex and Dollar B-7
Full Stop (Period, Dot) B-8
Matching a Single Byte B-8
Square Brackets and Character Classes B-8
Posix Character Classes B-9
Vertical Bar B-10
Internal Option Setting B-10
Subpatterns B-11
Named Subpatterns B-12
Repetition B-12
Atomic Grouping and Possessive Quantifiers B-14
Back References B-15
Assertions B-16
Lookahead Assertions B-17
Lookbehind Assertions B-17
Using Multiple Assertions B-18
Conditional Subpatterns B-19
Comments B-20
Recursive Patterns B-20
Subpatterns as Subroutines B-21
Callouts B-22
Contents
xix
User Guide for Cisco Security MARS Local Controller
78-17020-01
APPENDIX
C Date/Time Format Specfication C-1
APPENDIX
D System Rules and Reports D-1
List of System Rules D-1
List of System Reports D-13
G
LOSSARY
I
NDEX
Contents
xx
User Guide for Cisco Security MARS Local Controller
78-17020-01
xxi
User Guide for Cisco Security MARS Local Controller
78-17020-01
Preface
Introduction
Thank you for purchasing the Cisco Security Monitoring, Analysis, and Response System (MARS)
Local Controller. appliance. This guide will help you get the most value from your MARS Appliance.
Note The information in this document referring to a “MARS appliance” also applies to MARS use as Local
Controller in a Global Controller architecture.
The MARS Appliance
The Cisco Security Monitoring, Analysis, and Response System Appliance (MARS Appliance)– the
MARS 20, MARS 50, MARS 100, and MARS 200 – is a Security Threat Mitigation (STM) appliance.
It delivers a range of information about your networks’ health as seen through the “eyes” and “ears” of
the reporting devices in your networks. It takes in all of the raw events from your reporting devices,
sessionizes them across different devices, fires default rules for incidents, determines false positives, and
delivers consolidated information through diagrams, charts, queries, reports, and rules.
The MARS operates at distinct and separate levels based on how much information is provided about
your networks’ devices. At its most basic level, MARS functions as a syslog server. As you add
information about reporting devices, it starts sessionizing, and when fully enabled, it presents a
bird’s-eye view of your networks with the ability to quickly drill-down to a specific MAC address.
The MARS Web Interface
The MARS user interface uses a tabbed, hyperlinked, browser-based interface. If you have used the Web,
you have used similar Web pages.
Note When using the MARS user interface, avoid using the Back and Forward arrows in the browser. Using
these arrows can lead to unpredictable behavior.
xxii
User Guide for Cisco Security MARS Local Controller
78-17020-01
Preface
About This Manual
About This Manual
This manual describes the features and functionality of the Local Controller. The layout of this manual
is as follows:
• Chapter 1, “STM Task Flow Overview,” recommends a taskflow for planning and implementing
your security threat mitigation system. It ties back to your corporate security policies and presents
a structure deployment and configuration strategy based on two phases: provisioning and
monitoring.
Part 1: Provisioning Phase. This part details provisioning your network devices to communicate with
MARS. It involves performing device inventories, bootstrapping and configuring the reporting devices
and mitigation devices to communicate with the MARS Appliance, and performing device-side tuning.
• Chapter 2, “Reporting and Mitigation Devices Overview,”discusses concepts important to a
successful deployment of MARS. These concepts include selecting among the devices on your
network, understanding the levels of operation, and performing those tasks that affect many devices,
such as defining data pulling schedules.
• Chapter 3, “Configuring Router and Switch Devices.”
• Chapter 4, “Configuring Firewall Devices.”
• Chapter 5, “Configuring VPN Devices.”
• Chapter 6, “Configuring Network-based IDS and IPS Devices.”
• Chapter 7, “Configuring Host-Based IDS and IPS Devices.”
• Chapter 8, “Configuring Antivirus Devices.”
• Chapter 9, “Configuring Vulnerability Assessment Devices.”
• Chapter 10, “Configuring Generic, Solaris, Linux, and Windows Application Hosts.”
• Chapter 11, “Configuring Database Applications.”
• Chapter 12, “Configuring Web Server Devices.”
• Chapter 13, “Configuring Web Proxy Devices.”
• Chapter 14, “Configuring AAA Devices.”
• Chapter 15, “Configuring Custom Devices.”
Part II: Monitoring Phase. This part concepts important to successfully using MARS to monitor your
network. These concepts include defining inspection rules and investigating incidents.
• Chapter 16, “Policy Table Lookup on Cisco Security Manager” explains how to integrate with
Cisco Security Manager and use the policy lookup features in MARS.
• Chapter 17, “Network Summary” covers the Summary pages which includes the Dashboard, the
Network Status, and the My Reports pages.
• Chapter 18, “Case Management” covers using cases to provide accountability and improve
workflow.
• Chapter 19, “Incident Investigation and Mitigation” covers incidents and false positives and
provides a starting point for configuring a Layer 2 path and mitigation to work with a MARS.
• Chapter 20, “Queries and Reports” covers working with scheduled and on-demand reports and
queries. It also discussing using the real-time event viewer.
• Chapter 21, “Rules” covers defining and use inspection rules.
xxiii
User Guide for Cisco Security MARS Local Controller
78-17020-01
Preface
Obtaining Documentation
• Chapter 22, “Sending Alerts and Incident Notifications” explains how to configure the MARS to
send an alert based on an inspection rule.
• Chapter 23, “Management Tab Overview” covers managing events, networks, variables, hosts,
services, and MARS users.
• Chapter 24, “System Maintenance” covers some of the maintenance chores for the MARS.
Additionally, the following appendices are provided:
• Appendix A, “Cisco Security MARS XML API Reference” presents the XML schema used by
MARS for XML-based notifications.
• Appendix B, “Regular Expression Reference” The syntax and semantics of the regular expressions
supported by PCRE are described in this appendix.
• Appendix C, “Date/Time Format Specfication” The date/time field parsing is supported using the
Unix strptime() standard C library function.
• Glossary — A glossary of terms as they relate to MARS.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. This section explains the
product documentation resources that Cisco offers.
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/techsupport
You can access the Cisco website at this URL:
http://www.cisco.com
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Product Documentation DVD
The Product Documentation DVD is a library of technical product documentation on a portable medium.
The DVD enables you to access installation, configuration, and command guides for Cisco hardware and
software products. With the DVD, you have access to the HTML documentation and some of the
PDF files found on the Cisco website at this URL:
http://www.cisco.com/univercd/home/home.htm
The Product Documentation DVD is created and released regularly. DVDs are available singly or by
subscription. Registered Cisco.com users can order a Product Documentation DVD (product number
DOC-DOCDVD= or DOC-DOCDVD=SUB) from Cisco Marketplace at the Product Documentation
Store at this URL:
http://www.cisco.com/go/marketplace/docstore
xxiv
User Guide for Cisco Security MARS Local Controller
78-17020-01
Preface
Documentation Feedback
Ordering Documentation
You must be a registered Cisco.com user to access Cisco Marketplace. Registered users may order Cisco
documentation at the Product Documentation Store at this URL:
http://www.cisco.com/go/marketplace/docstore
If you do not have a user ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do
Documentation Feedback
You can provide feedback about Cisco technical documentation on the Cisco Support site area by
entering your comments in the feedback form available in every online document.
Cisco Product Security Overview
Cisco provides a free online Security Vulnerability Policy portal at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
From this site, you will find information about how to do the following:
• Report security vulnerabilities in Cisco products
• Obtain assistance with security incidents that involve Cisco products
• Register to receive security information from Cisco
A current list of security advisories, security notices, and security responses for Cisco products is
available at this URL:
http://www.cisco.com/go/psirt
To see security advisories, security notices, and security responses as they are updated in real time, you
can subscribe to the Product Security Incident Response Team Really Simple Syndication (PSIRT RSS)
feed. Information about how to subscribe to the PSIRT RSS feed is found at this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
Reporting Security Problems in Cisco Products
Cisco is committed to delivering secure products. We test our products internally before we release them,
and we strive to correct all vulnerabilities quickly. If you think that you have identified a vulnerability
in a Cisco product, contact PSIRT:
• For emergencies only—security-alert@cisco.com
An emergency is either a condition in which a system is under active attack or a condition for which
a severe and urgent security vulnerability should be reported. All other conditions are considered
nonemergencies.
• For nonemergencies— psirt@cisco.com
In an emergency, you can also reach PSIRT by telephone:
• 1 877 228-7302
xxv
User Guide for Cisco Security MARS Local Controller
78-17020-01
Preface
Product Alerts and Field Notices
• 1 408 525-6532
Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product (for example, GnuPG) to
encrypt any sensitive information that you send to Cisco. PSIRT can work with information that has been
encrypted with PGP versions 2.x through 9.x.
Never use a revoked encryption key or an expired encryption key. The correct public key to use in your
correspondence with PSIRT is the one linked in the Contact Summary section of the Security
Vulnerability Policy page at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
The link on this page has the current PGP key ID in use.
If you do not have or use PGP, contact PSIRT to find other means of encrypting the data before sending
any sensitive material.
Product Alerts and Field Notices
Modifications to or updates about Cisco products are announced in Cisco Product Alerts and Cisco Field
Notices. You can receive these announcements by using the Product Alert Tool on Cisco.com. This tool
enables you to create a profile and choose those products for which you want to receive information.
To access the Product Alert Tool, you must be a registered Cisco.com user. Registered users can access
the tool at this URL:
http://tools.cisco.com/Support/PAT/do/ViewMyProfiles.do?local=en
To register as a Cisco.com user, go to this URL:
http://tools.cisco.com/RPF/register/register.do
Obtaining Technical Assistance
Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The
Cisco Support website on Cisco.com features extensive online support resources. In addition, if you
have a valid Cisco service contract, Cisco Technical Assistance Center (TAC) engineers provide
telephone support. If you do not have a valid Cisco service contract, contact your reseller.
Cisco Support Website
The Cisco Support website provides online documents and tools for troubleshooting and resolving
technical issues with Cisco products and technologies. The website is available 24 hours a day at
this URL:
http://www.cisco.com/en/US/support/index.html
Access to all tools on the Cisco Support website requires a Cisco.com user ID and password. If you have
a valid service contract but do not have a user ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do
xxvi
User Guide for Cisco Security MARS Local Controller
78-17020-01
Preface
Obtaining Technical Assistance
Note Before you submit a request for service online or by phone, use the Cisco Product Identification Tool
to locate your product serial number. You can access this tool from the Cisco Support website
by clicking the Get Tools & Resources link, clicking the All Tools (A-Z) tab, and then choosing
Cisco Product Identification Tool from the alphabetical list. This tool offers three search options:
by product ID or model name; by tree view; or, for certain products, by copying and pasting show
command output. Search results show an illustration of your product with the serial number label
location highlighted. Locate the serial number label on your product and record the information
before placing a service call.
Tip Displaying and Searching on Cisco.com
If you suspect that the browser is not refreshing a web page, force the browser to update the web page
by holding down the Ctrl key while pressing F5.
To find technical information, narrow your search to look in technical documentation, not the
entire Cisco.com website. After using the Search box on the Cisco.com home page, click the
Advanced Search link next to the Search box on the resulting page and then click the
Technical Support & Documentation radio button.
To provide feedback about the Cisco.com website or a particular technical document, click
Contacts & Feedback at the top of any Cisco.com web page.
Submitting a Service Request
Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and
S4 service requests are those in which your network is minimally impaired or for which you require
product information.) After you describe your situation, the TAC Service Request Tool provides
recommended solutions. If your issue is not resolved using the recommended resources, your service
request is assigned to a Cisco engineer. The TAC Service Request Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests, or if you do not have Internet access, contact the Cisco TAC by telephone.
(S1 or S2 service requests are those in which your production network is down or severely degraded.)
Cisco engineers are assigned immediately to S1 and S2 service requests to help keep your business
operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411
Australia: 1 800 805 227
EMEA: +32 2 704 55 55
USA: 1 800 553 2447
For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/techsupport/contacts
xxvii
User Guide for Cisco Security MARS Local Controller
78-17020-01
Preface
Obtaining Additional Publications and Information
Definitions of Service Request Severity
To ensure that all service requests are reported in a standard format, Cisco has established severity
definitions.
Severity 1 (S1)—An existing network is “down” or there is a critical impact to your business operations.
You and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your
business operations are negatively affected by inadequate performance of Cisco products. You and Cisco
will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of the network is impaired while most business operations
remain functional. You and Cisco will commit resources during normal business hours to restore service
to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or
configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online
and printed sources.
• The Cisco Online Subscription Center is the website where you can sign up for a variety of Cisco
e-mail newsletters and other communications. Create a profile and then select the subscriptions that
you would like to receive. To visit the Cisco Online Subscription Center, go to this URL:
http://www.cisco.com/offer/subscribe
• The Cisco Product Quick Reference Guide is a handy, compact reference tool that includes brief
product overviews, key features, sample part numbers, and abbreviated technical specifications for
many Cisco products that are sold through channel partners. It is updated twice a year and includes
the latest Cisco channel product offerings. To order and find out more about the Cisco Product Quick
Reference Guide, go to this URL:
http://www.cisco.com/go/guide
• Cisco Marketplace provides a variety of Cisco books, reference guides, documentation, and logo
merchandise. Visit Cisco Marketplace, the company store, at this URL:
http://www.cisco.com/go/marketplace/
• Cisco Press publishes a wide range of general networking, training, and certification titles. Both new
and experienced users will benefit from these publications. For current Cisco Press titles and other
information, go to Cisco Press at this URL:
http://www.ciscopress.com
• Internet Protocol Journal is s a quarterly journal published by Cisco for engineering professionals
involved in designing, developing, and operating public and private internets and intranets. You can
access the Internet Protocol Journal at this URL:
http://www.cisco.com/ipj
• Networking products offered by Cisco, as well as customer support services, can be obtained at
this URL:
http://www.cisco.com/en/US/products/index.html
xxviii
User Guide for Cisco Security MARS Local Controller
78-17020-01
Preface
Obtaining Additional Publications and Information
• Networking Professionals Connection is an interactive website where networking professionals
share questions, suggestions, and information about networking products and technologies with
Cisco experts and other networking professionals. Join a discussion at this URL:
http://www.cisco.com/discuss/networking
• “What’s New in Cisco Documentation” is an online publication that provides information about the
latest documentation releases for Cisco products. Updated monthly, this online publication is
organized by product category to direct you quickly to the documentation for your products. You
can view the latest release of “What’s New in Cisco Documentation” at this URL:
http://www.cisco.com/univercd/cc/td/doc/abtunicd/136957.htm
• World-class networking training is available from Cisco. You can view current offerings at
this URL:
http://www.cisco.com/en/US/learning/index.html
CHA P T ER
1-1
User Guide for Cisco Security MARS Local Controller
78-17020-01
1
STM Task Flow Overview
This chapter describes the project phases and task flows that you should follow when you deploy MARS
as a security threat mitigation (STM) system in your network. First, however, you must develop a set of
policies that enables the application of security measures.
Your security policy should:
• Identify security objectives for your organization.
• Document the resources to protect.
• Identify the network infrastructure with current maps and inventories.
• Identify the critical resources (such as research and development, finance, and human resources)
that require extra protection.
Your monitoring policy should:
• Identify the expected administrative traffic flows across your network, including user, source,
destination, services, and hours of operation.
• Identify expected network traffic for security probing and vulnerability testing, including user,
source, destination, services, and hours of operation.
• Identify the network infrastructure able to provide audit data in “network proximity” to the critical
resources.
• Identify the various event logging levels available from the devices and hosts in the network
infrastructure.
• Identify the devices and techniques used to investigate
Your mitigation policy should:
• Identify the choke points on your network relative to the critical resources.
• Define your process for documenting mitigated attacks on layer 2 and layer 3 devices.
• Define your process for documenting mitigated attacks at the host and application layer.
• Resolve corporate ownership issues among network operations, security operations, host owners
and application owners on shared hosts.
• Identify your policy for notifying security response teams and remediation teams.
• Identify vendor detection tool prioritization process, such as IOS IPS Dynamic Attack Mitigation
(DAM).
• Identify how you want to block detected attacks: block them temporarily or permanently, block
them using MARS-generated rules, using custom rules defined by security operations team, etc.
Your remediation policy should:
1-2
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Provisioning Phase
• Identify the responses to detected but unmitigated attacks for each type of node in your network.
• Identify tool vendor update policies to ensure proper remediation of hosts and applications.
• Identify the policies and procedures for isolating infected legacy hosts where remediation options
are unavailable. These procedures may include restoring from backups or network isolation.
After you develop your policies, they become the hub of the Cisco Security Wheel, (Figure 1-1).
Figure 1-1 Cisco Security Wheel
The spokes of the Cisco Security Wheel represent network security as a continual process consisting of
four steps:
1. Secure your system.
2. Monitor the network for violations and attacks against your security policy and respond to them.
3. Test the effectiveness of the security safeguards in place.
4. Manage and improve corporate security.
You should perform all four steps continually, and you should consider each of them when you create
and update your corporate security policy.
The remainder of this section details recommended task flows according to the following project phases:
• Provisioning (see Checklist for Provisioning Phase, page 1-2).
• Monitoring (see Checklist for Monitoring Phase, page 1-9).
Check out http://www.cisco.com/web/about/security/intelligence/articles.html for more planning ideas.
Look closely at the SAFE information.
Checklist for Provisioning Phase
Provisioning deals with planning, setting up and configuring the hardware, software, and networks that
actually provide access to the data and network resources for the MARS Appliance. This phase takes
place after you successfully complete the installation, which was detailed in the Install and Setup Guide
for Cisco Security Monitoring, Analysis, and Response System.
The following checklist describes the tasks required to understand the decision-making process and the
basic flow required to provision MARS in the most productive manner. Each step might contain several
substeps; the steps and substeps should be performed in order. The checklist contains references to the
specific procedures used to perform each task.
1-3
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Provisioning Phase
Task
1. Inventory and review possible reporting devices, mitigation devices, and supporting devices.
Reporting devices provide logs about user and network activities and device status and configuration. Mitigation
devices can be used to respond to detected attacks. They also act as reporting devices. Supporting devices provide
network services to reporting devices, mitigation devices, or a MARS Appliance.
Identifying which devices on your network to monitor depends on multiple factors, including their placement,
the reporting they can provide relative to other devices on the same network segment, and the level of operation
that you want to achieve from your MARS Appliance.
When considering which devices to declare as reporting devices and mitigation devices, be sure you know what
data is provided to MARS by those devices. Simply adding all possible devices does not guarantee the best
monitoring and mitigation strategy. Deliberate selection of the devices can reduce the MARS workload, resulting
in improved detection and mitigation times, as well as improved false positive detection.
Because MARS only considers monitored devices, you should take care in identifying which devices to monitor.
The following are only a couple examples of considerations you should make when identifying devices.
• Consider of the types of logs and data available from reporting devices on specific network segments, and
select those logs that provide the most complete picture of the activity on your network.
• Identify mitigation devices at natural chokepoints across each segment in your network. You are more likely
to stop an attack if these mitigation devices are identified to MARS. When MARS identifies an attack, it
studies the topology of your network to identify the best chokepoint; however, it only considers those devices
that are monitored.
Supporting devices can play an important role in the operation of your STM system. Therefore, you should
inventory and review the supporting devices on your network, which include e-mail, AAA, DNS, and syslog
servers, that will play a role in the envisioned STM system.
Result: The list of devices that you want to monitor is complete. The details of each device include device name,
reporting IP address, management IP address, management protocol, administrative account information, and the
logging features, levels, and protocols to enable.
For more information, see:
• Selecting the Devices to Monitor, page 2-2
• Levels of Operation, page 2-1
• Deployment Planning Guidelines, page 2-1 in Install and Setup Guide for Cisco Security Monitoring,
Analysis, and Response System
• Device Inventory Worksheet, page 1-18
1-4
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Provisioning Phase
2. Identify and enable all required traffic flows.
After you identify the devices, you must verify that the network services they use for management, reporting, and
notification are permitted along the required traffic flows. Using the detailed Device Inventory Worksheet
identified in Step 1., ensure that the management, logging, and notification traffic between the MARS Appliance
and each supporting device, reporting device, and mitigation device is allowed by intermediate gateways.
In addition, network services of supporting devices, such as DNS, e-mail, AAA, and NTP servers, must also be
permitted to flow among the MARS Appliance, the supporting devices, and the reporting devices and mitigation
devices on your network.
MARS applies the device time to received events only. For all events pulled from devices such as IDS/IPS devices
or Windows, MARS uses the reported time as long as that reported time falls within 3600 seconds of the time on
the MARS Appliance.
Tip It is a recommended security practice to have all devices, including MARS Appliances, synchronized to the
same time. Also, since the MARS Appliance is an HTTPS server, it uses certificates which require the time,
date, and time zone to be set properly. Otherwise, sessions and incidents are stamped incorrectly and you may
experience “time out” errors when accessing the web interface.
To limit troubleshooting, you should test each traffic flow from the source network segment to the destination
segment. If possible, you should test all device-to- device flows for each protocol to ensure that best match versus
first match semantics of various gateway ACLs do not hinder required traffic flows. As with any security devices
on your network, enabled traffic flows should be restricted to the required protocols, ports, and source/destination
pairs.
Result: You have verified that all intermediate gateways permit the log, management, and notification traffic
between the devices and the MARS Appliance.
For more information, see:
• Event Timestamps and Processing in Top Issues for the Cisco Security Monitoring, Analysis, and Response
System
• Deployment Planning Guidelines, page 2-1, in Install and Setup Guide for Cisco Security Monitoring,
Analysis, and Response System
• Supporting Devices, page 2-1, in Install and Setup Guide for Cisco Security Monitoring, Analysis, and
Response System
• Required Traffic Flows, page 2-2, in Install and Setup Guide for Cisco Security Monitoring, Analysis, and
Response System
• Specify the Time Settings, page 5-10, in Install and Setup Guide for Cisco Security Monitoring, Analysis,
and Response System
• Device Inventory Worksheet, page 1-18
Task
1-5
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Provisioning Phase
3. Bootstrap the reporting devices, mitigation devices, and supporting devices.
For each device identified in the Device Inventory Worksheet, you must prepare, or bootstrap, that device to
ensure that the desired communications with MARS occur. Bootstrapping a device involves configuring the
settings for that device, as determined by its role within the STM system. Perform the following bootstrap tasks
as applicable to a device type and its role:
• Enable management of the device by the MARS Appliance for mitigation and access.
• Install an agent that collects the correct logs for MARS Appliance.
• Turn on the correct logging level and logging services.
• Direct the logs to the MARS Appliance or identify the appliance to receive or pull those logs as needed.
• Enable discovery of the device settings.
• Enable the device to receive notifications from the MARS Appliance.
Each device has a different required configuration to ensure that it assumes the role you have envisioned for it in
the STM system. As you consider the devices, their expected role in your STM system will correlate directly with
the configuration of the tasks listed above. In addition, you identify any restrictions imposed by MARS. For
example, MARS may restrict the supported protocols for discovery of a specific device type.
Result: The correct logging levels are enabled on the reporting devices and mitigation devices. The MARS
Appliance can receive or pull any necessary logs from those devices, and it can retrieve configuration settings
and push ACLS to the supported mitigation devices. Any devices that require notification of detected attacks are
configured to receive such notifications from the MARS Appliance. While the MARS Appliance picks up and
stores the events it receives, it does not inspect them until the reporting devices and mitigation devices are defined
and activated in web interface.
Tip Any events published by a device to MARS prior to adding and activating the device in the web interface can
be queried using the reporting IP address of the device as a match criterion. This technique can be useful for
verifying that the device is properly bootstrapped.
For more information, see:
• Device Inventory Worksheet, page 1-18
• Supported Reporting and Mitigation Devices, page 3
• Bootstrap Summary Table, page 2-12
• The log settings sections of the user guides for your reporting devices and mitigation devices
Task
1-6
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Provisioning Phase
4. Define the devices in MARS.
After you identify and bootstrap the reporting devices and mitigation devices and enable the required traffic
flows, you must represent those devices in MARS, which uses this information to communicate with the devices.
You can do this by adding individual devices in the web interface or by importing a comma separated vector
(CSV) file, which can define the required settings for basic device types and give you a headstart on defining the
more complicated devices. In addition, you can use topology discovery to automatically discover reporting
devices and mitigation devices and later go back to provide additional detail.
For most device types, you must determine what access protocol to use for device discovery. The selection of
this protocol determines what type of data you can discover and whether you can perform mitigation.
Understanding the options helps you develop a consistent approach in compliance with your corporate policies.
How you choose to add the devices depends on the number of devices on your network and whether there are
CSV device keywords for the devices that you want to add. In addition, device types that use agents, modules,
or sensors are defined in multiple steps, where you first define the base host or device, and then add the modules,
sensors, and agents to the base device. For example, if you want to add an IPS module to a Cisco ASA device,
you must first define the Cisco ASA device and then define the IPS module as a component of that device. In
addition, many applications that are not dedicated appliances require that you first define the host (generic,
Windows, Unix, or Linux) on which that application runs before you can associate the application with that host.
After you add the devices, you must activate them by clicking Activate on any page in the web interface.
To display all devices that are either added incorrectly or not activated in MARS, you can define one of two
queries:
• Select “Unknown Reporting Device” in the Devices field. This query returns the events only for those
devices that are reporting events that do not matching the one of the reporting IPs defined in MARS. When
MARS receives events, it first determines if the IP from which the events are received matches one of
reporting IPs identified in the Reporting and Monitor Devices page. Only if MARS finds a match does it
attempt to parse the events. Therefore, if the Reporting IP is defined incorrectly for a reporting device, the
events from that device are not parsed. This query essentially identifies events that are not parsed.
• Select the “Unknown Device Event Type” in the Events field. This query returns events from known devices
that for some reason the event is not parsed by MARS (for example, if the MARS signature list is not current
with the device event lists), and it returns events reported by unknown devices.
These queries are a recommended good practice after adding the devices, especially when using a CSV seedfile
or SNMP discovery. For both queries, if you are looking for a specific reporting IP address, enter that address in
the Keyword field to filter the results down to those that include that IP address.
Result: All reporting devices and mitigation devices are defined and activated in MARS. When the devices are
bootstrapped and defined in MARS, MARS begins to inspect the logs received from the devices. Until the devices
are added in MARS, MARS picks up and stores the events it receives without inspecting them.
For more information, see:
• Device Inventory Worksheet, page 1-18
• Selecting the Access Type, page 2-10
• Add Reporting and Mitigation Devices Individually, page 2-17
• Add Multiple Reporting and Mitigation Devices Using a Seed File, page 2-20
• Adding Reporting and Mitigation Devices Using Automatic Topology Discovery, page 2-25
• Supported Reporting and Mitigation Devices, page 3 (CSV Keyword column)
• Verify Connectivity with the Reporting and Mitigation Devices, page 2-26
• Activate the Reporting and Mitigation Devices, page 2-27
Task
1-7
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Provisioning Phase
5. Configure global data collection settings and schedules in MARS.
After you add the devices, you can enable the rich data collection features of MARS, which include:
• Dynamic vulnerability scanning. When MARS detects an attack, it can probe the network to determine the
likely success and severity of the attack. To allow this data collection in response to detected attacks, you
must enable the feature and identify which networks to analyze.
• NetFlow data collection. NetFlow data enables MARS to identify anomalies by profiling typical data flows
across your network, allowing MARS to detect day-zero attacks, including worm outbreaks. Statistical
profiling takes between four days and two weeks for a MARS Appliance to complete. When the profiles are
developed, MARS begins detecting anomalous traffic flows and creates incidents in response to them. To
configure NetFlow data collection, you must configure those devices that can generate NetFlow traffic, and
you must configure MARS to listen on a shared community string.
• Layer 3 topology discovery. A process-intensive operation that discovers the layer 3 network devices (that
is, those devices operating at the IP layer). This layer 3 data is used to determine the attack path vector and
to populate the Topology graphs. You can define the schedule for updating this information.
• Layer 2 device discovery. This feature allows MARS to determine the attack path vector and to identify
attacking hosts and targets by MAC address, which eliminates confusion caused by attacks that spoof IP
addresses. This feature is typically configured when adding a switch and enabling mitigation.
There are also several device types from which MARS periodically pulls data. For such devices, you can define
the intervals at which the event logs are retrieved and processed. These update features are as follows:
• Distributed Threat Mitigation (DTM) device updates. The DTM services poll Cisco IPS and Cisco IDS
devices to determine the top firing signatures across the reporting devices. Based on this information, MARS
generates the list of top signatures that are firing on the network so that Cisco IOS Routers running the DTM
feature set can query MARS for the list of signatures they should be running.
• Windows event logs. You can set the frequency by which MARS pulls audit trail records from Windows
hosts and servers. This setting is global for all such hosts and has a default value of five minutes.
• Oracle event logs. You can set the frequency by which MARS pulls audit trail records from Oracle database
servers. This setting is global for all such servers and has a default value of five minutes.
• Monitored device update scheduler. You can set the frequency by which MARS pulls data from specific
reporting devices, such as Qualys QualysGuard, Foundstone Foundscan, and eEye REM. Schedules are set
on a per IP address basis.
After you define the settings, you must activate them by clicking Activate on any page in the web interface.
Result: The schedules for updating cached data pulled from reporting, mitigation, and supporting devices are
defined and activated in MARS. After these settings are defined, MARS can probe the network or pull updates
from reporting, mitigation, and supporting devices.
For more information, see:
• Data Enabling Features, page 2-28
• Windows Event Log Pulling Time Interval, page 10-11
• Layer 2 Discovery and Mitigation, page 2-29
• Configure Interval for Pulling Oracle Event Logs, page 11-3
• Networks for Dynamic Vulnerability Scanning, page 2-29
• Understanding NetFlow Anomaly Detection, page 2-30
• Configuring Layer 3 Topology Discovery, page 2-37
• Technology Preview: Configuring Distributed Threat Mitigation with Intrusion Prevention System in
Cisco Security MARS, page 1
• Scheduling Topology Updates, page 2-39
Task
1-8
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Provisioning Phase
6. Populate vulnerability assessment information for supporting devices and network assets.
Vulnerability assessment information describes specific hosts on your network. You can detail this information
for any host, whether it is a host representing a reporting device, a mitigation device, or an important asset on
your network.
This information identifies the operating system, patch levels, and the network services that run on the host.
After you define the hosts, you must activate them by clicking Activate on any page in the web interface.
Result: MARS understands more about the hosts on your network and the services that they run.
For more information, see:
• Host and Device Identification and Detail Strategies, page 2-36
• Device Inventory Worksheet, page 1-18
• IP Management, page 23-3
• Service Management, page 23-7
Task
1-9
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Monitoring Phase
Checklist for Monitoring Phase
After you complete the provisioning phase, you must configure MARS to help you realize your broader
security goals and requirements. During the monitoring phase, your primary goal is to effectively realize
your monitoring, mitigation, and remediation policies. This phase involves defining the strategies, rules,
reports, and other settings required to achieve this goal.
7. Monitor and tune event generation and processing.
As with all monitoring applications, tuning log generation and event processing is key to technical accuracy and
performance. You can use two methods to tune which events are processed by MARS:
• Device-side tuning. This method involves restricting event generation at the device level. MARS never
receives events that are not relevant to security or device status. It also involves eliminating superfluous,
duplicate data reported by multiple devices on the network, as well as eliminating those events that can be
reproduced by reports or queries in MARS, such as traffic summary syslogs.
• Appliance-side tuning. This method involves identifying events received by the MARS Appliance that
represent normal or planned network activity. Drop rules are defined to prevent MARS from processing such
events as part of potential security incidents. When defining such drop rules, you should be as precise in the
definition as possible, for example, identify the source of expected ping sweeps by an IP address within an
expected time period, which is much more difficult to spoof as it requires explicit knowledge of your network
and administrative practices. You can further qualify the rules using a combination of seven conditions:
source, destination, service type, event type, time range, reporting device, and event severity. You must
choose whether to drop the event entirely or to drop it and log it to the database, where it can be used by
queries and reports.
Note Drop rules do not prevent MARS from storing the event data; they simply prevent the appliance from
processing the events. Events affected by drop rules can still appear a query as they are being stored on the
appliance.You are still storing them; just not processing them for inspection rules.Therefore, if appliance
storage considerations are an issue, we recommend using device-side tuning.
Note For releases 4.2.3 and earlier of MARS, you cannot define drop rules for a NetFlow-based event. For these
releases, tuning of NetFlow events must be performed on the reporting device.
Tuning is an ongoing task to improve the identification of attacks, report quality surrounding truly suspicious
activities, and the overall performance and accuracy of your STM solution. It involves a detailed study of traffic,
which can be conducted and refined by evaluating the events that are coming into the appliance on a
device-by-device basis.
Tip In a lab network environment, use a MARS Appliance to study generated events and tuning options on an
individual device type basis. By documenting your requirements in a controlled environment, you can
eliminate much of the production network tuning by establishing valuable device-side tuning standards for
each monitoring device type.
Result: The events being processed by the MARS Appliance are restricted to those that provide value to the STM
system.
For more information, see:
• Appliance-side Tuning Guidelines, page 1-17
• Configuring Logging Policies on Firewall Devices in User Guide for Cisco Security Manager 3.0
Task
1-10
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Monitoring Phase
Note You must prepare MARS to closely adhere to your corporate security policy before you begin monitoring
traffic flows, as you must be prepared to react to detected attacks.
The following checklist describes the tasks required to understand the decision-making process and the
basic flow required to operate MARS in the most productive manner. Each step might contain several
substeps; the steps and substeps should be performed in order. The checklist contains references to the
specific procedures used to perform each task.
Task
1. Develop monitoring, notification, mitigation, remediation, and audit strategies.
These strategies are concerned less with desired traffic flows and generated events and focus more on what to do
after MARS Appliance processes that data. These strategies are at the heart of how you will use MARS to protect
your network, taking into account the short- and long-term requirements of monitoring and forensic analysis, as
well as how to stop ongoing attacks and clean infected hosts. These strategies encompass not only your expected
interaction with MARS, but the expectations of your reporting devices as well. Essentially, they identify the roles,
tasks, and data requirements that you anticipate so that you can map events, rules, queries, and reports to those
roles that provide the data required by the identified tasks.
As with any security system, we recommend that users be assigned the lowest-level privilege required to perform
their job. Admin-level privileges should be reserved for administrators of the MARS Appliance.
Result: You have identified the users and roles required to effectively respond to detected attacks and device
issues. You have defined clear guidance for responding to notifications and understand the information
requirements of those such notifications and the expected format and delivery methods to be used.
For more information, see:
• Strategies for Monitoring, Notification, Mitigation, Remediation, and Audit, page 1-16
• Case Management, page 18-1s
• User Management, page 23-8
• , page 23-13
• User Role Worksheet, page 1-20
1-11
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Monitoring Phase
2. Define the notification services.
This task prepares the notification services of MARS to notify your mitigation and remediation personnel and
take other required actions. In MARS, notification services have three building blocks:
• User accounts. Represent users who will receive reports or notifications or who will access the web interface
for the purpose of monitoring or mitigation. Users can receive notifications in the form of e-mail, pager
messages, or Short Message Service (SMS) messages. Users are assigned to one of four roles, admin,
security analyst, operator, notification only, which determines their access privileges in the web interface.
• Devices. Represent those devices that will receive notifications in the form of an SNMP message, a syslog
message, or in the case of an IOS IPS device, a DAM message (equivalent to a shun). For more on defining
devices, refer to Checklist for Provisioning Phase, page 1-2.
• Actions. Actions are defined within inspection rules, and they represent the notifying action. Depending on
the target of the notification, a user or a device, your action can provide guidance to your staff or instruct
your devices to log or block an attack.
Within MARS, any person or device that is expected to receive a notification must be identified in the system.
Therefore, the first step is to define user accounts that map to the users or groups who must be notified based on
specific event settings (see User Role Worksheet, page 1-20). You must also identify the devices that need to be
notified or that need to take some action (see Device Inventory Worksheet, page 1-18).
The next step is to define the notification service settings (actions), which can be one or more of e-mail, page,
SMS, SNMP, Syslog, or Dynamic Attack Mitigation. Each of these settings includes the contact information and
a message that you can define for each type of notification.
There is not a separate interface for defining these settings. To define the notification service settings, you must
edit an existing inspection rule and add new Action definitions. After you define these settings, they are available
to all inspection rules.
Result: All required personnel have been identified in MARS so that rules and reports can be customized to notify
the correct personnel.
For more information, see:
• User Management, page 23-8
• Add or Remove a User from a User Group, page 23-12
• IP Management, page 23-3
• Adding Reporting and Mitigation Devices, page 2-16
• Forwarding Alert Data to 3
rd
-Party Syslog and SNMP Servers, page 2-54
• MARS MIB Format, page 2-54
• Inspection Rules, page 21-4
• Working with System and User Inspection Rules, page 21-17
• Setting Alerts, page 21-23
• Sending Alerts and Incident Notifications, page 22-1
Task
1-12
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Monitoring Phase
3. Define custom inspection rules and refine system inspection rules.
Inspection rules correlate events from disparate devices into meaningful sessions that reflect the end-to-end
activities of an attack or other network session. By identifying the end-to-end view of attacks, MARS is better
able to identify mitigation points in your network. However, you can define inspection rules to accomplish
different goals: identification of an attack is just one possible goal. Other example goals include identifying use
of priority assets, network health, and refining your network configuration based on usage analysis.
MARS ships with over 100 system inspection rules; however, you may find that you cannot identify those
sessions that are important to your corporate policies. For example, if you want to monitor the use of a custom
or unsupported application, you can either define a new inspection rule that monitors traffic between a selected
source and destination using a known protocol and port pair, or define a custom log parser that uniquely processes
the events generated by that application to expose the data within the event that you want to track. Monitoring a
known protocol port pair can provide summary data, such as number of sessions, where a custom log parser can
enable detailed inspection of aspects of the traffic, such as resource utilization or failed logging attempts. To
define a custom parser, you must know the message format used by that appliance and it must be published to
MARS in clear text.
Organizing the rules that you create into meaningful groups can help clarify your purpose and improves the
learnability of the system. As you consider your specific goals, you should define a rule group (and a
corresponding report group) to help you refine the strategies you identified in Step 1. Because rules can be
members of multiple groups, you do not have to worry about creating multiple rules to address the same issue.
The groups are merely available to help your organize your work and allow you to focus on one strategy at a time.
Result: Any custom inspection rules are developed and existing inspection rules are configured to provide proper
notification in compliance with your corporate policies. Any custom log parser and inspection rules are defined
that enable the audit of the traffic flows of home-grown or unsupported applications or protocols.
For more information, see:
• Rule and Report Groups, page 21-24
• Event Management, page 23-1
• IP Management, page 23-3
• Service Management, page 23-7
• User Management, page 23-8
• Adding User Defined Log Parser Templates, page 15-1
• Inspection Rules, page 21-4
• Working with System and User Inspection Rules, page 21-17
• Setting Alerts, page 21-23
• Sending Alerts and Incident Notifications, page 22-1
Task
1-13
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Monitoring Phase
4. Define custom queries and reports.
Queries and reports are forensic analysis tools. They help you analyze historical data and enable you to identify
trends over longer periods of time than the real-time monitoring features of MARS. The relationship between
queries and reports is essentially that queries are on-demand, refined inspections of data as defined by a report
template. Reports are scheduled to run periodically, enabling you to define the periods and frequencies that you
want to inspect on an ongoing basis. Queries allow you to narrow or broaden your search based on a report
template by filtering the search criteria. WhileMARS provides many predefined report templates, you can define
new report templates that focus on the incidents and events important to fulfilling your policies. This feature can
be especially useful for adhering to compliance reporting requirements, as you can define a report, schedule it to
be generated, and store the results as part of your audit records.
As with overall access, you can restrict the ability to run or view reports and queries based on user role. Such
safeguards can reduce accidental tampering with schedule reports by other users of the system.In addition, you
can configure your report templates so that users are notified of the report. Typically, e-mail is the primary
method used for report notification, but all notification methods are supported.
Result: The report templates required to realize your forensic analysis and audit goals are defined and assigned
to user roles according to your least privilege policies. Any report groups that facilitate access or division of
reports and queries among your staff are defined.
For more information, see:
• Queries and Reports, page 20-1
• Queries, page 20-1
• Perform a Batch Query, page 20-20
• Reports, page 20-23
• Creating a Report, page 20-25
Task
1-14
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Monitoring Phase
5. Monitor network and security activity.
This task encompasses monitoring your network for attacks or issues and responding to them. How users interact
with MARS depends on their role and your operational guidelines. For users who are expected to use the web
interface to monitor traffic in near real-time, this task requires an in-depth understanding of the data that is
correlated and displayed, as well as when and how to respond to suspicious or anomalous behavior.
MARS provides two interfaces to network and security activity: the Summary tab and the Query/Reports tab.
Each interface provides different views and tools to help you understand what is happening on your network.
The Summary tab focuses on near real-time events, whereas the Query/Reports tab focuses on historical, forensic
analysis as described in Step 4. The Summary tab organizes priority views of your network activity, displaying
hot spot diagrams, recent events, charts of incidents, and a topology diagram, identifying recent activities.
When you identify an incident that requires further investigation or mitigation, you can investigate the incident
to determine whether it is a false positive or block attack using MARS. If you have choke points operating at layer
2, primarily switches, MARS will identify the appropriate device, provide recommended CLI changes, and allow
you to push these changes to the device. If the choke point is a layer 3 device, MARS recommends CLI changes
that you can copy and paste into an administrative session with the identified choke point.
In this manner, you can monitor your network for suspicious behavior and respond to any detections.
Result: Users understand the views and tools required to monitor, verify, and mitigate attacks on the network.
For more information, see:
• Network Summary, page 17-1
• Incident Investigation and Mitigation, page 19-1
• False Positive Confirmation, page 19-6
• Rule and Report Groups, page 21-24
• Event Groups, page 23-2
• Case Management, page 18-1
• The False Positive Page, page 19-8
• Retrieving Raw Messages, page 24-3
Task
1-15
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Checklist for Monitoring Phase
6. Monitor system and network health.
The STM system is more than your MARS Appliance; it includes all reporting devices and mitigation devices
and any MARS Appliances. When assessing the health of the system, you should monitor the health of each of
these devices. You can monitor your system health by using inspection rules that generate notifications for
anomalous behavior, by generating system health queries and reports, and by manually reviewing the system logs
of MARS.
MARS provides reports about use of common resources, including CPU, bandwidth, and memory. To simplify
the monitoring of system health, you can define a report group that organizes these reports into a meaningful
collection. You can also restrict the presentation of those reports and queries to specific user roles.
Because reports can be scheduled, you can notify the appropriate users each time the report is updated.
Tip If you cannot view the resource usage of a reporting device, verify that you have enabled the Monitor
Resource Usage option as part of that device definition in Admin > System Configuration > Security and
Monitored Devices. For the list of devices that can be configured to provide this data, see Configuring
Resource Usage Data, page 2-41.
MARS also includes detailed logs about the status of the appliance itself, as well as several command-line
utilities that present status on the health of the appliance.
Result: The users responsible for monitoring the system and network health understand the tools and reports
provided by MARS to perform these functions.
For more information, see:
• Rule and Report Groups, page 21-24
• Rule and Report Group Overview, page 21-25
• Configuring Resource Usage Data, page 2-41
• pnstatus, page A-39
• pnlog, page A-30
• Setting Runtime Logging Levels, page 24-1
• Viewing the MARS Backend Log Files, page 24-2
• Viewing the Audit Trail, page 24-3
• Retrieving Raw Messages, page 24-3
Task
1-16
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Strategies for Monitoring, Notification, Mitigation, Remediation, and Audit
Strategies for Monitoring, Notification, Mitigation, Remediation,
and Audit
STM requires the close coordination of multiple strategies in support of your corporate security policies:
• Monitoring involves the study of network activities and device status to identify anomalous
activities or behavior.
• Notification involves alerting those parties responsible for responding to detected anomalies with
the information necessary to respond.
• Mitigation involves responding to suspicious activity to prevent the spread of anomalies across your
network.
• Remediation involves responding to successful exploits to clean infected hosts on your network.
7. Tune MARS processing.
Tuning, which is an ongoing activity for any monitoring application, involves refining the sensitivity and
accuracy of how events are processed. In MARS, you can do any of the following to effect such changes.
• Use drop rules to enable or disable the processing of events by MARS.
Note For releases 4.2.3 and earlier of MARS, you cannot define drop rules for a NetFlow-based event. For these
releases, tuning of NetFlow events must be performed on the reporting device.
• Turn on or off event generation at the device.
• Identify selected incidents as false positives.
• Tune inspection rules to include or exclude specific networks, hosts, services, reporting devices, or traffic
flows.
• Tune the inspection of traffic by device type, such as IPS and IDS, refining the rule set they use to generate
events.
• Add or remove reporting devices to alter the reported event set or to provide supporting data that can be used
to improve the self-tuning features of MARS, such as false positives, OS fingerprinting, and vulnerability
assessment.
• Describe the expected behavior on your network by describing the assets, services, and vulnerability
assessment information. The more details MARS knows about your network, the better it can assess the
incoming events.
Result: The events being processed by the MARS Appliance are restricted or expanded to encompass those that
provide the most value to the STM system.
For more information, see:
• Appliance-side Tuning Guidelines, page 1-17
• Working with Drop Rules, page 21-21
• False Positive Confirmation, page 19-6
• Selecting the Devices to Monitor, page 2-2
Task
1-17
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Appliance-side Tuning Guidelines
• Audit involves logging and reporting activities that have taken place during other tasks. The goal of
audit is to provide an account the activities and responses to support compliance audits and trend
analysis.
The first decision you must make is who will be responsible for mitigation at the selected choke points.
Often, organizations separate specialized security devices from the core network infrastructure devices
along organizational divisions. As an example, two separate teams, security operations and network
operations, may be responsible for different network components or different policies on shared devices.
Before you roll MARS out on your network, ownership of a strategies for mitigation must be clearly
defined in according with your corporate policies.
When it comes to a mitigation strategy, two options exist:
• You can rely on MARS to identify the choke point and accept the recommended CLI changes to
block the detected attack.
• You can issue notifications and incident details to a responsible party who can evaluate the MARS
recommendations, but ultimately that party will make the final decision about where and how to stop
the detected attack.
Regardless of the option you choose, you should develop guidelines on how long an attack should be
blocked, how to investigate an internal attack so that you can clean them, who is responsible for updating
the policies after the required quarantine period, and how records of such events should be maintained
for audit compliance (for example, is the case management feature of MARS tied to your ticket
integration system?).
Next, you should make a distinction in the type of monitoring that you should perform: system
monitoring versus security monitoring. System monitoring involves monitoring not only the status of the
MARS Appliance but also the health and status of the reporting devices and mitigation devices that
MARS manages. Security monitoring focuses on network and security activity.
For both types of monitoring, you must decide what predefined and custom queries and reports are
required, the processes for evaluating and responding to the data they reveal, and guidelines on using
the case management features of MARS to manage the responses and track changes.
The last phase involves determining who should be notified when specific incidents are detected. For
example, who is notified of device status incidents versus security-related incidents. You must identify
your mitigation and remediation personnel, identify those responsible for monitoring (across
organizations if necessary), and determine how notifications are to be generated and what they should
look like. This involves selecting among methods, including SMS, pager alert, and e-mail, as well as
whether the notifications are based on incidents, queries, or reports.
Appliance-side Tuning Guidelines
Tuning on the MARS Appliance focuses on not inspecting traffic that is received from the reporting
devices. Two primary techniques exist for appliance-side tuning:
• Drop rules. This technique involves dropping all events that match specific criteria received from
a reporting device. This technique is the fastest and the least refined. As part of defining a drop rule,
you can also specify whether to retain the event log in or simply discard it. The advantage of drop
rules is that they events are not processed by any inspection rules, which speeds up the processing
of the appliance by reducing the potential workload.
Note For releases 4.2.3 and earlier of MARS, you cannot define drop rules for a NetFlow-based event.
For these releases, tuning of NetFlow events must be performed on the reporting device.
1-18
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Device Inventory Worksheet
• Removing devices from inspection. This technique involves removing a device from inspection
rules. This technique is specific to the events that trigger a specific type of alarm. The advantage of
this technique is that is does not drop all events that match specific criteria received from a reporting
device. In other words, your focus is on reducing a specific false positive rather than all incidents
that are fired based on the events. In addition, the events are retained so that you can review them
using queries and reports.
When using either of these techniques, remember that when you add or modify a rule, you must click
Activate before the changes take effect.
Device Inventory Worksheet
The device inventory worksheet will help you collect the required information about the devices on your
network. It includes the following information:
• Device name. Identifies the well-known name of the device. Typically, this name is the DNS name
of the device. MARS uses this name in the topology graph, reports, and events.
• Reporting IP address. Identifies the IP address assigned to the network interface from which
MARS will be receiving events. This address is used by MARS to map back to the device name and
to uniquely identify messages and events originating from the device.
• Management IP address. Identifies the IP address assigned to the network interface to which
MARS connects to discover the configuration settings for the device.
• Username/password. Identifies the account that has the correct authorization to connect to the
management IP address and read or write information based on the role in the network. For reporting
devices, this account must have privileges sufficient for MARS to read the existing configuration.
For mitigation devices, specifically layer 2 switches, this account can enable MARS to publish
actual CLI changes to the device to block detected attacks.
• Role in system/segment. Identifies whether this device is a reporting device or a mitigation device.
It can also identify supporting devices, such as DNS and e-mail servers. In addition, the role should
take into account this device’s expected importance relative to the network segment, specifically
relative to the other devices on the same segment. You can qualify this segment-level role using
terms that fit your overall monitoring strategy, such as primary source, second opinion, attack
identification, false positive assessment, session data, and endpoint/MAC address identification.
Understanding the role that a device can or should play at a network segment level helps prioritize
the required and tunable log settings.
• Required protocols. Identifies the protocols that this device uses to operate. The primary focus is
on the management protocols, notification protocols, and protocols used to publish audit events.
• Log settings/SNMP RO community string. Identifies the specific settings with respect to event
and log generation that are required for this device to satisfy the role that it will play in the MARS
system. It also identifies the SNMP RO community string for this device.
• Tunable. Identifies whether you can perform device-side tuning of the log generation.
• Notify. Identifies whether this device can receive notifications from MARS.
• Notification format. Identifies the format for any notifications that are sent to this device.
1-19
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
Device Inventory Worksheet
Table 1-1 Device Inventory Worksheet
Device Name
Reporting IP
Address
Management
IP Address/
Account
Username/
Password
Role in
System/
Segment
Required
Protocols
Log Settings/
SNMP RO Community
Tunable
(y/n)
Notify
(y/n)
Notification
Format
1-20
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
User Role Worksheet
User Role Worksheet
The user role worksheet will help you collect required information about administrators of your network.
It includes the following information:
• User Name. Identifies the user by name.
• User Role. Identifies the role this user has with respect to your corporate security policies.
• MARS Account. Identifies the MARS user account and role—admin, security analyst, operator, or
notification only—which determines access privileges in the web interface. For accountability and
security, each user typically has a unique account. However, you can define group-based accounts.
• Notification Settings. Identifies the information required to contact this user when incident rules
are fired. For users, notification settings include e-mail, pager messages, or SMS messages. For
response teams, you may use group aliases. Users should be notified when inspection rules fire and
scheduled reports are generated.
• Device Ownership. Identifies the reporting devices and mitigation devices on your network for
which the user is responsible. This list is especially important when the user is a member of your
mitigation or remediation team.
• Inspection Rules. Identifies any inspection rules required to meet the needs of this user role. These
rules must to be defined or configured to notify the user when they fire.
• Reports/Queries. Identifies any reports and queries required to meet the needs of this user role. You
must ensure that the user can access these reports and queries. Optionally, you may want to notify
the user when scheduled reports are generated.
1-21
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
User Role Worksheet
Table 1-2 User Role Worksheet
User Name User Role
MARS
Account/Role
Notification
Settings
Device
Ownership Inspection Rules Reports/Queries
1-22
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 1 STM Task Flow Overview
User Role Worksheet
CHA P T ER
2-1
User Guide for Cisco Security MARS Local Controller
78-17020-01
2
Reporting and Mitigation Devices Overview
Revised: June 20, 2007, 78-17020-01
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, page 1-1.
This chapters assumes that you have made corporate-level policy decisions and that you are executing
against the Checklist for Provisioning Phase, page 1-2. This chapter provides the following:
• Guidance on selecting and configuring reporting devices and mitigation devices
• Discussion of the levels of operation that MARS supports
• Guidance on selecting a method for adding devices to Local Controller
• Discussion of those features that enable rich data collection
It contains the following sections:
• Levels of Operation, page 2-1
• Selecting the Devices to Monitor, page 2-2
• Understanding Access IP, Reporting IP, and Interface Settings, page 2-8
• Selecting the Access Type, page 2-10
• Bootstrap Summary Table, page 2-12
• Adding Reporting and Mitigation Devices, page 2-16
• Data Enabling Features, page 2-28
• Integrating MARS with 3
rd
-Party Applications, page 2-54
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.
2-2
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Selecting the Devices to Monitor
• 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, page 2-16.
• 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, page 23-3 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, page 2-39.
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
2-3
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Selecting the Devices to Monitor
Consider distinct goals:
• Attack detection
• Attack detection and mitigation
• Regulatory compliance
• Full NAC awareness
• 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.
2-4
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Selecting the Devices to Monitor
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
2-5
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Selecting the Devices to Monitor
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
Table 2-2 Device Types and Data Available (continued)
Device Type Data Available Recommended Configurations
2-6
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Selecting the Devices to Monitor
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.
Table 2-2 Device Types and Data Available (continued)
Device Type Data Available Recommended Configurations
2-7
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Selecting the Devices to Monitor
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.
Table 2-2 Device Types and Data Available (continued)
Device Type Data Available Recommended Configurations
2-8
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Understanding Access IP, Reporting IP, and Interface Settings
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, page 2-9
• Reporting IP, page 2-9
• Interface Settings, page 2-10
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, page 14-2
Supporting Cisco Secure ACS Solution Engine,
page 14-2
Generic Syslog Same as host, provides support for additional
customer devices.
Generic SNMP Same as host, provides support for additional
customer devices.
Cisco Security Mana
ger
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.
Table 2-2 Device Types and Data Available (continued)
Device Type Data Available Recommended Configurations
2-9
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Understanding Access IP, Reporting IP, and Interface 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, page 2-10.
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.
2-10
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Selecting the Access Type
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.2.x and 5.2.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.
Note TFTP is not supported. You must use an FTP server.
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.
2-11
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Selecting the Access Type
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, page 2-11
• Configure Telnet Access for Devices in MARS, page 2-11
• Configure SSH Access for Devices in MARS, page 2-12
• Configure FTP Access for Devices in MARS, page 2-12
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.
If you selected SNMP as the access type, follow these steps:
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.
If you selected TELNET as the access type, follow these steps:
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.
2-12
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Bootstrap Summary Table
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.
If you selected SSH as the access type, follow these steps:
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.
If you selected FTP as the access type, follow these steps:
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.
Note If you select FTP, you cannot enter an enable password.
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.
2-13
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Bootstrap Summary Table
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, page 3-1
Cisco Switch (IOS) Cisco Switch Devices, page 3-9
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, page 3-17
Generic Router Generic Router Device, page 3-18
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, page 4-2
Cisco Adaptive Security
Appliance (ASA)
Cisco Firewall Services
Module (FWSM)
Cisco IOS Firewall
Feature Set
Juniper Netscreen NetScreen ScreenOS Devices, page 4-14
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, page 4-25
Nokia Firewall (running
Checkpoint)
VPN Devices
Cisco VPN
Concentrator
Cisco VPN 3000 Concentrator, page 5-1
2-14
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Bootstrap Summary Table
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, page 6-1
Cisco IDS 4.0 and IPS 5.x Sensors, page 6-5
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 and IPS 5.x Sensors, page 6-5
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, page 6-10
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, page 6-10
McAfee Intrushield IntruVert IntruShield, page 6-22
Juniper Netscreen IDP NetScreen IDP 2.1, page 6-31
Symantec Manhunt Symantec ManHunt, page 6-29
ISS RealSecure ISS RealSecure 6.5 and 7.0, page 6-17
Snort Snort 2.0, page 6-28
Enterasys Dragon Enterasys Dragon 6.x, page 6-33
Table 2-3 Reporting and Mitigation Device Bootstrap Summary (continued)
Device Type/Name Bootstrap Summary Reference Information
2-15
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Bootstrap Summary Table
Host IDS
Cisco Security Agent Cisco Security Agent 4.x Device, page 7-5
McAfee Entercept Entercept Entercept 2.5 and 4.0, page 7-1
ISS RealSecure Host
Sensor
ISS RealSecure 6.5 and 7.0, page 6-17
Anti-virus
Symantec AntiVirus Symantec AntiVirus Configuration, page 8-1
Cisco Incident Control
System (Cisco ICS),
Trend Micro Outbreak
Prevention Service
(OPS)
Cisco Incident Control Server, page 8-13
McAfee ePolicy
Orchestrator
McAfee ePolicy Orchestrator Devices, page
8-8
Network Associates
VirusScan
McAfee ePolicy Orchestrator Devices, page
8-8
Vulnerability Assessment
eEye REM eEye REM 1.0, page 9-3
Qualys QualysGuard Qualys QualysGuard Devices, page 9-5
Foundstone Foundscan Foundstone FoundScan 3.0, page 9-1
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, page 10-5
Pull Method: Configure the Microsoft
Windows Host, page 10-6
Solaris — Syslog (from Device)
Sun Solaris and Linux Hosts, page 10-2
Redhat Linux — Syslog (from Device)
Sun Solaris and Linux Hosts, page 10-2
Web Server
Microsoft Internet
Information Server
— Syslog (from SNARE agent)
Install and Configure the Snare Agent for IIS,
page 12-1
Sun iPlanet — HTTP (from MARS Agent)
Install and Configure the Web Agent on
UNIX or Linux, page 12-7
Table 2-3 Reporting and Mitigation Device Bootstrap Summary (continued)
Device Type/Name Bootstrap Summary Reference Information
2-16
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
Adding Reporting and Mitigation Devices
Three methods exist for adding reporting devices and mitigation devices to MARS:
• Manually add the devices one at a time.
• Add multiple devices using a seed file.
• Discover devices automatically using SNMP RO community strings.
Apache — HTTP (from MARS Agent)
Install and Configure the Web Agent on
UNIX or Linux, page 12-7
Web Proxy
NetApp NetCache — HTTP
Network Appliance NetCache Generic, page
13-1
Database Server
Oracle TCP SQLnet (from Host)
Oracle Database Server Generic, page 11-1
AAA Server
Cisco Secure Access
Control Sever (ACS)
— Syslog (from MARS Agent)
Install and Configure the PN Log Agent, page
14-7 (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, page 14-2
Install and Configure the PN Log Agent, page
14-7 (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, page 10-1
Generic SNMP Server Enable SNMP access by MARS Appliance. Adding Generic Devices, page 10-1
Other
Cisco Security Manager Enable HTTPS access by MARS Appliance Checklist for Security Manager-to-MARS
Integration, page 16-6
Bootstrapping Cisco Security Manager
Server to Communicate with MARS, page
16-12
Add a Cisco Security Manager Server to
MARS, page 16-13
Table 2-3 Reporting and Mitigation Device Bootstrap Summary (continued)
Device Type/Name Bootstrap Summary Reference Information
2-17
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
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.
The device support is categorized into three categories:
• 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, page 2-39).
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 20-2.)
For more information on adding devices, see:
• Add Reporting and Mitigation Devices Individually, page 2-17
• Add Multiple Reporting and Mitigation Devices Using a Seed File, page 2-20
• Adding Reporting and Mitigation Devices Using Automatic Topology Discovery, page 2-25
Regardless of the method that you have used to add the devices, you should also perform the following
tasks:
• Verify Connectivity with the Reporting and Mitigation Devices, page 2-26
• Activate the Reporting and Mitigation Devices, page 2-27
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, page 2-23 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.
2-18
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
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.
To add a device manually, follow these steps
Step 1 Click Admin > System Setup > Security and Monitor Devices > Add.
Step 2 Select the device from the list.
Step 3 Enter the information needed to communicate with the device.
Step 4 Click Submit.
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, page 2-27.
Edit a Device
Step 1 Check the box next to the device.
Step 2 Edit the device’s settings.
Step 3 Click Submit.
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:
• Cisco IDS
• Cisco PIX
• Cisco VPN Concentrator
• NetScreen ScreenOS
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.
To change the version of a device, follow these steps:
2-19
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
Step 1 Click Admin > System Setup > Security and Monitor Devices.
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 3 Select the new version in the New Device Type Version list.
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, page 2-27.
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.
To delete a device, follow these steps:
Step 1 Select one of the following pages:
• Admin > Security and Monitoring Devices
• Management > IP Management
Step 2 Check the box next to each device you want to delete.
2-20
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
Step 3 Click Delete.
Step 4 On the confirmation page, click Submit.
The device is deleted from the selected page.
Delete All Displayed Reporting Devices
You can perform this procedure from the Admin > Security and Monitoring Devices page.
To delete all devices displayed on a page, follow these steps:
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.
All displayed devices are selected.
Step 2 Click Delete.
A page appears prompting you to confirm that you want to delete the list of devices.
Step 3 Click Submit to delete all the selected 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:
10.1.1.1,,,,PIX,TELNET,,,cisco,,,,,,,,,,,
192.168.229.241,,,,IOS,TELNET,,,csRv$12*,EcsRv$12$,,,,,,,,,,
10.1.1.83,,,,PIX,SSH,pix,Vpnspn12,,vPfw1ne,,,,,,,,,,
192.168.151.169,,,,PIX,SSH,pix,lpt$12,,pot$1*d1,,,,,,,,,,
10.4.2.4,,,,NETSCREEN,SSH,netscreen,nt*$scn25,,,,,,,,,,,,
10.4.2.3,,,,NETSCREEN,SSH,netscreen,nt*$scn10,,,,,,,,,,,,
10.1.1.241,,,,IOS,TELNET,,,cisco,cisco,,,,,,,,,,
10.4.2.1,,,,IOS,TELNET,,,Qa$1*5ft,gt$*j15,,,,,,,,,,
10.4.2.2,,,,IOS,TELNET,,,Qa$1*5ft,gt$*j15,,,,,,,,,,
wanRouter,public,,,IOS,SNMP,,,,,,,,,,,,,,,
myPix63,,,,PIX,SSH,pix,test1,,test1234,,,,,,,,,,,10.2.3.1
MyPc,,,,WINDOWS,RPC,myname,mypass,,,,,,,,,,,,,
myPix70,,,,PIX7X,SSH,,,,,,,,,,,,,,,
myids40,,,,CiscoIDS4x,SSL,,,,,,,,,,,,,,,
myids50,,,,CiscoIPS5x,SSL,,,,,,,,,,,,,,,
myASA70,,,,ASA,SSH,,,,,,,,,,,,,,,
myWindowsNT,,,,WindowsNT,RPC,,,,,,,,,,,,,,,
myFWSM23,,,,FWSM,SSH,,,,,,,,,,,,,,,
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, page 2-27).
2-21
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding 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 hostor 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:
• Entercept. For more information, see Extracting Entercept Agent Information into a CSV file (for
Entercept Version 2.5), page 7-1.
• IntruVert IntruShield. For more information, see Extracting Intruvert Sensor Information from the
IntruShield Manager, page 6-22.
• 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, page 7-6.
• 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, page 8-7.
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:
• Cisco IDS 4.x Devices. These sensors are defined by importing a MARS-specific seed file as
defined in Load Devices From the Seed File, page 2-24. However, once you import a sensor, you
must identify the monitored networks that it monitors. For more information, see Specify the
Monitored Networks for Cisco IPS or IDS Device Imported from a Seed File, page 6-8.
• Cisco IPS 5.x Devices. These sensors are defined by importing a MARS-specific seed file as defined
in Load Devices From the Seed File, page 2-24. However, once you import a sensor, you must
identify the monitored networks that it monitors. For more information, see Specify the Monitored
Networks for Cisco IPS or IDS Device Imported from a Seed File, page 6-8.
• 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, page 6-27.
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.
2-22
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
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.
2-23
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
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
• FWSM3: 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.
Table 2-4 Seed File Column Description (continued)
Column Type Entry
2-24
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
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.
To load the file into the MARS, follow these steps:
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.
Step 3 Click Submit.
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, page 2-27.
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, page 2-8
Table 2-4 Seed File Column Description (continued)
Column Type Entry
2-25
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding 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, page 2-21).
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:
• Community String and Networks. Allows you to define SNMP RO community strings on a per
network or IP range basis. Networks and SNMP RO stings can overlap. At least one SNMP string
must be defined before discovery is attempted.
• Valid Networks. Identifies the set of networks and IP ranges that you want to discover. You should
also define one or more SNMP targets. If no SNMP targets are defined, MARS uses it’s own gateway
as the SNMP target. SNMP targets should be layer 3 gateway devices, such as a router or firewall
with SNMP RO community strings defined and discovery permitted; they should also be defined on
a per network or per range basis if you wish to separate the discovery using schedule rules. At least
one valid network must be defined before discovery is attempted.
• Topology/Monitored Device Update Scheduler. While not required for discovery, it does allow
you to increase the frequency of topology discovery and further refine the potential depth of a
discovery based on a particular schedule rule. The default schedule rule is once a month for all valid
networks. However, if no valid networks are defined, the process wakes up, sees no valid networks
are defined, and quits. Each schedule rule allows you to select which networks, as defined within
the list of valid networks and ranges, that should be discovered according to frequency also specified
in the rule. As connected networks often exist, you can refine which networks are discovered by
ensuring that separate schedule rule exists for each network that you do not want to be automatically
discovered as part of a connected network.
Based on the networks defined within the schedule rules, MARS starts with the first SNMP target
associated with those networks or ranges as defined under Valid Networks and attempts to discover that
device using SNMP discovery. The discovery process continues as long as the target device provides
additional routes and the addresses of such routes are part of the networks in another schedule rule. The
process also iterates through each SNMP target that is defined. The entire discovery process is limited
based on the schedule rule’s bounding networks, the SNMP targets, the valid network and IP ranges, and
the SNMP RO community strings, which are defined on a per network basis. Networks and SNMP RO
community stings can overlap, in which case MARS tries each string against the gateway addresses
discovered within that network. The discovery process only discovers Layer 3 gateway devices, such as
routers and firewalls. It does not discover hosts, unless those hosts are defined as the explicit target
within a schedule rule (see Scheduling Topology Updates, page 2-39).
As the discovery process identifies supported reporting and mitigation devices, it adds those devices to
the Monitoring and Security Devices list (Admin > Monitoring and Reporting Devices), identifying
them by the Reporting IP. You can later edit these discovered devices to provide Access IP information
and perform more thorough device-level discovery. Once a device is listed under Monitoring and
Reporting Devices, it may be rediscovered, but it will not be added again unless it has been properly
deleted (see Delete a Device, page 2-19).
2-26
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
For more information on these settings, see:
• Configuring Layer 3 Topology Discovery, page 2-37
• Scheduling Topology Updates, page 2-39
Note Once the discovery process is complete, you must click Activate for MARS to correctly process events
received from that device. For more information, see Activate the Reporting and Mitigation Devices,
page 2-27.
Verify Connectivity with the Reporting and Mitigation Devices
After loading the seed file or manually adding devices, you can verify that the devices were loaded by
clicking Admin > System Setup > Security and Monitor Devices. You should see the devices that you
have added populating this page.
You can test the devices by checking the box next to the name of the device and clicking Edit. On the
device’s page, click Discover or Test Connectivity. The UI displays a “holding pattern” screen while
it connects to the device. When complete, it shows you the device’s discovery screen.
Note Some devices cannot be checked for connectivity nor can be discovered. The next section, Discover and
Testing Connectivity Options, page 2-26, contains a list of devices that can be checked or discovered.
Discover and Testing Connectivity Options
When you add a device, you should check its connectivity or perform the discovery. Checking a device’s
connectivity or discovery analyzes the device’s configuration, checks that MARS can process its events,
and that MARS can understand its NAT information.
You can test these devices for connectivity or perform discovery:
• Cisco IOS
• Cisco PIX
• Cisco ASA
• Cisco Switch CatOS
• Cisco Switch IOS
• Cisco IDS
• Cisco IDSM
• Cisco FWSM
• Cisco Security Manager server
• Cisco VPN Concentrator 4.x
• Check Point
• Extreme ExtremeWare 6.x
• NetScreen
2-27
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Adding Reporting and Mitigation Devices
Run a Reporting Device Query
Another method to see the added devices, is to run a query with the display format: Reporting Device
Ranking.
Note You might not see all of the devices that you loaded using the seed file right away because of lag,
network size and traffic. If you do not see a device after waiting, it could be due to input error.
To run a reporting device ranking query, follow these steps:
Step 1 Click the Queries / Reports tab.
Step 2 On the Queries page, in the Query Event Data table, click Event Type in the Display Format column.
Step 3 Select Reporting Device Ranking.
Step 4 Click Apply.
Step 5 Click Submit to run the query.
Activate the Reporting and Mitigation Devices
After you have added reporting devices and mitigation devices to MARS, you must activate those
devices before MARS begins to fully process the data provided by those devices. This processing is
different from those devices discovered on the network, where the logs sent to the appliance are stored,
but your ability to interact with that data is limited to queries and reports. Typically, MARS runs
inspection rules and generates notifications only against the data retrieved from activated devices.
Once a device is known to the MARS Appliance, all data provided by that particular device can be
normalized and sessionized, which enables that device’s data to be used to fire an incident
Note Default installations of MARS do not fire incidents based on data received from unknown devices.
However, you can still enable this by creating one or more rules that use keyword search. A device must
be defined for the MARS to be able to parse and sessionize the event data. The act of parsing the event
data correctly is what ensures rules fire more accurately.
Tip You must click Activate whenever you add or modify rules, drop rules, reports, or add or modify any
options or settings under in the Admin tab other than those on the User Management subtab. Otherwise,
the changes that you make will not take effect.
To activate added devices, follow these steps:
Step 1 For each device that you want to add, provide the device details and click Submit to add the device.
The Submit action stores the device details in the database. Once you click Submit, your work is saved,
even if you drop the administrative connection before clicking Activate.
Step 2 Once you have all of the devices desired for this administrative session, click Activate.
2-28
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
The Activate action differs from Submit in that MARS begins to inspect and generate notifications about
the data provided by the devices.
Tip If you are adding or editing several devices, it is better for the system to click Activate for
several changes rather than for each individual change.
Data Enabling Features
Adding a the reporting devices and mitigation devices is the primary method of providing MARS with
the data required to study the activities on your network. However, other features, both within the web
interface and as part of configuring the devices, can provide MARS with additional data, which is used
to refine the views it provides and to assist in the improving the overall effectiveness of the system. We
think of these features as data enabling features.
This section contains the following topics:
• Layer 2 Discovery and Mitigation, page 2-29
Enable SNMP community strings to support the discovery the network topology. Allows for
mapping to the port level for switches. Combined with 802.1x support required by NAC, this setting
can resolve MAC address level settings for attached and wireless nodes on the network.
• Networks for Dynamic Vulnerability Scanning, page 2-29
Enables a Nessus-based scan of the targeted hosts. Nessus also uses nmap for OS fingerprinting and
port scanning during a vulnerability assessment scan. These scans are conducted in response to
suspicious activity to determine whether the attempted attack is successful or likely to succeed based
on information such as target operating system type, patch level, and open ports on the host.
• Understanding NetFlow Anomaly Detection, page 2-30
By enabling NetFlow, MARS can detect anomalies in traffic and network usage by comparing new
events with summary data. When anomalies are detected, MARS begins to store full NetFlow data.
By default, full NetFlow data is not stored by MARS unless an incident is identified.
• Host and Device Identification and Detail Strategies, page 2-36
Details about reporting devices and the hosts that are on your network aids in the elimination of false
positives, as well as improves the performance of MARS in assessing events.
• Configuring Layer 3 Topology Discovery, page 2-37
Layer 3 topology discovery aids in attack path analysis, as well as the population of the topology
graph in the web interface.
• Scheduling Topology Updates, page 2-39
Topology update schedules are a critical part of many of the data enabling features, including
discovery of Layer 2 and Layer 3 devices, as well as pulling information from specific reporting
devices.
• Configuring Resource Usage Data, page 2-41
MARS can collect additional data from a select set of reporting devices, which is used to provide
reports about CPU utilization, memory utilization, and device saturation. This data can be helpful
in detecting anomalies as well in network capacity planning.
2-29
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
• Configuring Network Admission Control Features, page 2-52
Describes how to accomplish full NAC awareness, what it provides, and what products are required.
• Configuring Distributed Threat Mitigation
http://www.cisco.com/en/US/products/ps6241/products_configuration_example09186a008067a2b
0.shtml
Describes how to accomplish full DTM awareness, the features it provides, and what products are
required.
• MARS MIB Format, page 2-54
Describes the format of the MARS MIB, which helps integrate with other SNMP-based management
applications on your network.
Layer 2 Discovery and Mitigation
Make sure that all the L2 devices have the SNMP RO community strings specified in the web interface
for L2 mitigation, even if the access type is not SNMP. (See False Positive Confirmation, page 19-6 for
more information on mitigating an attack.)
The SNMP RO community string is always required on Layer 2 devices for L2 mitigation. L2 devices
must be added manually—there is no automatic discovery for these device.
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).
MARS does not discover L2 devices automatically as it does with L3 devices.
Note L2 devices must be added manually; there is no automatic discovery for these devices. Make sure all the
L2 devices (switches) have the SNMP RO community strings specified in the web interface, even if the
access type is not SNMP. The SNMP RO community string is always required on L2 devices for L2
mitigation.
You can specify which L3 devices to discover by specifying networks and SNMP RO community values,
as defined in Configuring Layer 3 Topology Discovery, page 2-37.
The reason is MARS does not scan the network for devices. Therefore, you must manually add L2
devices using the web interface or a CSV file. Assuming that device discovery permission has been
provided, L3 devices are discovered automatically using the route information provided by monitored
gateways. Once devices are loaded/added in the web interface, user can use the topology scheduler
feature to update the configuration of both L2 and L3.
For L2 devices SNMP access type is sufficient with RO community. But for mitigation, MARS requires
SNMP RW community access. If SNMP RW community is not possible, select TELNET/SSH access
type with SNMP RO Community.
Networks for Dynamic Vulnerability Scanning
With dynamic vulnerability scanning, the MARS probes the networks that you have specified for
weaknesses. These automatic scans commence after a rule has fired that indicates an attack is in
progress. Once an attack is underway, these scans accomplish the following:
2-30
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
• return information that determines if the attack failed
• return information that determines if the attack likely succeeded
• return false positive information
• assign severity to firing events and incidents
Select a Network for Scanning
To select a network for scanning, follow these steps:
Step 1 Click the Select radio button.
Step 2 Click a network to scan.
Step 3 Click Add.
Step 4 Repeat Step 1 through Step 3.
Step 5 Click Submit when ready.
Create a Network IP Address for Scanning
To create a network address that you can use to define the scan settings, follow these steps:
Step 1 Click the Network IP radio button.
Step 2 Enter the Network IP address and Mask.
Step 3 Click Add.
Create a Network IP Range for Scanning
To create a range of network addresses that you can use to define the scan settings, follow these steps:
Step 1 Click the IP Range radio button.
Step 2 Enter the range of IP addresses.
Step 3 Click Add.
Understanding NetFlow Anomaly Detection
NetFlow is a Cisco technology that supports monitoring network traffic and is supported on all basic IOS
images. NetFlow uses an UDP-based protocol to periodically report on flows seen by the Cisco IOS
device. A flow is a Layer 7 concept that consists of a session set up, data transfer, and session teardown.
For every flow, a NetFlow-enabled device record several flow parameters including
• Flow identifiers, specifically source and destination addresses, ports, and protocol
2-31
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
• Ingress and egress interfaces
• Packets exchanged
• Number of bytes transferred
Periodically, a collection of flows and its associated parameters are packaged in an UDP packet
according to the NetFlow protocol and sent to any identified collection points. Because data about
multiple flows is recorded in a single UDP packet, NetFlow is an efficient method of monitoring high
volumes of traffic compared to traditional methods, including SYSLOG and SNMP.
The data provided by NetFlow packets is similar to that provided by SYSLOG, SNMP, or Checkpoint
LEA as reported by enterprise-level firewalls, such as Cisco PIX, NetScreen ScreenOS, and Checkpoint
Firewall-1. The difference being that NetFlow much more efficient. To receive comparable syslog data
from a firewall device, the syslog logging level on the firewall must be set to DEBUG, which degrades
firewall throughput at moderate to high traffic loads.
If NetFlow-enabled reporting devices are positioned correctly within your network, you can use NetFlow
to improve the performance of the MARS Appliance and your network devices, without sacrificing
MARS’s ability to detect attacks and anomalies. In fact, NetFlow data and firewall traffic logs are treated
uniformly as they both represent traffic in the network.
This section contains the following topics:
• How MARS Uses NetFlow Data, page 2-31
• Guidelines for Configuring NetFlow on Your Network, page 2-32
• Enable Cisco IOS Routers and Switches to Send NetFlow to MARS, page 2-32
• Configuring Cisco CatIOS Switch, page 2-34
• Enable NetFlow Processing in MARS, page 2-34
How MARS Uses NetFlow Data
When MARS is configured to work with NetFlow, you can take advantage of NetFlow’s anomaly
detection using statistical profiling, which can pinpoint day zero attacks like worm outbreaks. MARS
uses NetFlow data to accomplish the following:
• Profile the network usage to determine a usage baseline
• Detect statistically significant anomalous behavior in comparison to the baseline
• Correlate anomalous behavior to attacks and other events reported by network IDS/IPS systems
After being inserted into a network, MARS studies the network usage for a full week, including the
weekend, to determine the usage baseline. Once the baseline is determined, MARS switches to detection
mode where it looks for statistically significant behavior, such as the current value exceeds the mean by
2 to 3 times the standard deviation.
By default, MARS does not store the NetFlow records in its database because of the high data volume.
However, when anomalous behavior is detected, MARS does store the full NetFlow records for the
anomalous entity (host or port). These records ensure that the full context of the security incident, such
as the infected source and destination port, is available to the administrator. This approach to data
collection provides the intelligence required by an administrator without affecting the performance of
the MARS Appliance. Storing all NetFlow records consumes unnecessary CPU and disk resources.
Note MARS only supports NetFlow version 5 and version 7.
2-32
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Guidelines for Configuring NetFlow on Your Network
Ideally NetFlow should be collected from the core and distribution switches in your network. These
switches, together with the NetFlow from Internet-facing routers or SYSLOG from firewalls, typically
represent the entire network. With this in mind, review the following guidelines before deploying
NetFlow in your network:
• MARS normalizes NetFlow and SYSLOG events to prevent duplicate event reporting from the same
reporting device.
• Review VLANS in switches and pick several VLANs for which the traffic volume is low. This
approach allows you to slowly integrate NetFlow and become comfortable with using it in your
environment.
• Be aware of existing CPU utilization on NetFlow capable devices. For more information on
understanding how NetFlow affects the performance of routers and network throughput, see the
following link:
http://www.cisco.com/en/US/tech/tk812/technologies_white_paper0900aecd802a0eb9.shtml
• Consider using a sampling of NetFlow data 10:1 100:1 ratio’s in highly utilized VLANS.
• Be selective in using NetFlow, you to not need to enable it on all NetFlow-capable devices. In fact,
such usage can create duplicate reporting of events, further burdening the MARS Appliance.
• MARS uses NetFlow versions 5 and 7. Ensure that the version of Cisco IOS software or Cisco
CatOS running on your reporting devices supports at least one of these NetFlow versions.
Note For releases 4.2.3 and earlier of MARS, you cannot define drop rules for a NetFlow-based event.
For these releases, tuning of NetFlow events must be performed on the reporting device.
The taskflow for configuring NetFlow to work with MARS is as follows:
1. Identify the reporting devices on which to enable NetFlow.
2. Enable NetFlow on each identified reporting device and direct the NetFlow data to the MARS
Appliance responsible for that network segment.
3. Verify that all reporting devices are defined in the MARS web interface.
4. Enable NetFlow processing in the MARS web interface.
5. Allow MARS to study traffic for a week to develop a usage baseline before it beings to generate
incidents based on detected anomalies.
The following tasks provide guidance on the required device configuration:
• Enable Cisco IOS Routers and Switches to Send NetFlow to MARS, page 2-32
• Enable NetFlow Processing in MARS, page 2-34
Enable Cisco IOS Routers and Switches to Send NetFlow to MARS
For more information on NetFlow and configuring the settings in Cisco IOS, refer to:
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_book09186a00805b
88ed.html
Before you configure NetFlow from MARS, you must first configure it on the router or switch.
To enable NetFlow on a Cisco IOS router or switch and to push those events to the MARS Appliance,
follow these steps:
2-33
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Step 1 Log in to the Cisco IOS router or switch with administrator’s privileges.
Step 2 Enter the following commands:
Step 3 For each interface in the device, enter the following commands:
Step 4 To verify that NetFlow is enabled correctly, enter the following commands:
show ip flow export
show ip cache flow
Command Purpose
enable
Turn on enable mode.
configure terminal
Enter global configuration mode.
Note Commands in this mode are written to the running
configuration file as soon as you enter them (using the Enter
key/Carriage Return).
ip flow-export destination
<MARS_IP_address>
<UDP_port>
Enables the data export to the MARS Appliance on UDP port 2055
(assuming the default port is used). MARS_IP_address is the IP
address of the MARS Appliance that is responsible for processing
the NetFlow events for this reporting device. UDP_port is the
default UDP port to send NetFlow (the default port is 2055).
ip flow-export source
<
syslog_interface_name>
• Set the source IP for the interface to send the NetFlow. The
syslog_interface_name value should be the interface attached
to the network through which the MARS Appliance is
reachable, and it must equal the syslog source interface name.
ip flow-export version
<version_number>
Identifies which version of NetFlow, 5 or 7, to use when generating
events. Cisco recommends using version 5 if supported.
version_number is either 5 or 7. MARS only supports NetFlow
versions 5 and 7.
ip flow-cache timeout active
5
Configures the flow timeout. This timeout value breaks up
long-lived flows into 5-minute segments. You can choose any
number of minutes between 1 and 60; however, selecting the default
of 30 minutes will result in spikes appearing in utilization reports.
ip flow-cache timeout
inactive 15
Ensures that those flows that have finished are exported in a timely
manner.
Command Purpose
interface <interface_name> Specifies the interface for which you want to enable NetFlow and it
enters the interface configuration mode. interface_name is the name
of the interface to which the MARS is connected. This command
varies based on the device type. For example,
interface type slot/port-adapter/port (Cisco 7500 series
routers)
interface type slot/port (Cisco 7200 series routers)
ip route-cache flow
Enables NetFlow for the selected interface.
2-34
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Step 5 To exit enable mode, enter the following command:
exit
Configuring Cisco CatIOS Switch
Some Cisco Catalyst switches support a different implementation of NetFlow that is performed on the
supervisor. With the cache-based forwarding model, which is implemented in the Catalyst 55xx running
the Route Switch Module (RSM) and NetFlow Feature Card (NFFC), the RSM processes the first flow
and the remaining packets in the flow are forwarded by the Supervisor. This support is also implemented
in the early versions of the 65xx with MSFC. The deterministic forwarding model used in the 65xx with
MSFC2 do not use NetFlow to determine the forwarding path, the flow cache is only used for statistics
as in the current IOS implementations. In all of these configurations, flow exports arrive from both the
RSM/MSFC and the Supervisor engines as distinct streams.
The router-side running IOS is configured as specified in Enable Cisco IOS Routers and Switches to
Send NetFlow to MARS, page 2-32. However, to configure the he CatIOS NetFlow Data Export, use the
following commands:
set mls flow full
set mls nde version 5
set mls nde <MARS_IP_address> 2055
set mls nde enable
From a user’s perspective, the switch is only running IOS when the 65xx is running in Native mode.
Enable NetFlow Processing in MARS
Once you have enabled NetFlow on your routers or switches and you have directed those devices to
publish NetFlow data to the MARS Appliance, you must configure the appliance to process that data.
This configuration involves determining how to store data, as well as identifying which networks you
want to process for anomalous behavior. Both of these options can affect the rate at which MARS can
process events: storing the full event data rather than summary data burdens the system with writing
large volumes of data rather than processing new incoming events. Also, by not specifying a select set
of networks, MARS studies all networks.
Step 1 Click Admin > System Setup > NetFlow Config Info.
2-35
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Step 2 Under NetFlow Configuration, enter the NetFlow Global NetFlow UDP Port. This is the default port
for MARS to listen for NetFlow; the default value is 2055.
Note This value must match the value you entered in the “ip flow-export destination” command when
configuring the router (see Enable Cisco IOS Routers and Switches to Send NetFlow to MARS, page
2-32. Also, verify you have enabled this traffic to flow between the router or switch and the MARS
Appliance on any intermediate gateways, such as routers and firewalls.
Step 3 Choose whether to Enable NetFlow Processing.
• Ye s tells MARS to process the NetFlow logs.
• No disables the processing of NetFlow data into the MARS.
Step 4 Choose whether to Always Store NetFlow Records.
• Ye s tells MARS to store all of the NetFlow events in the database. Selecting this option can slow
down the system by greatly decreasing the number of events per second that MARS is able to
process.
• No tells MARS to store only anomalies. The MARS detects anomalies by using two dynamically
generated watermarks comparing the previous data against current data. When the data breaches the
first watermark, MARS starts to save that data. When the data rises above the second watermark,
MARS creates an incident.
Step 5 Under NetFlow Valid Network Addresses, you can enter one or more for networks you want to monitor
and use the << Add button to add them.
2-36
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
• Specifying one or more networks causes MARS to generate NetFlow-based anomalies that occur
only on the specified networks. If empty, then entire network is examined for anomalies. If the
Local Controller is monitoring a specific zone (as defined by theGlobal Controller-Local Controller
relationship), then this field should include only those networks for which this Local Controller is
responsible.
Note To reduce the memory usage and increase performance of the appliance, you can configure
MARS to profile hosts belonging to a set of valid networks.
• Leaving this value blank (not specifying any networks) causes MARS to examine all networks for
anomalous behavior based on the NetFlow events.
Step 6 Click Submit to save your changes.
Step 7 To enable NetFlow processing by the MARS Appliance, click Activate.
Before MARScan start detecting anomalies based on NetFlow data, it must first develop a baseline for
network behavior. It takes a full week, including the weekend, for MARS to develop such a baseline.
After this period has elapsed, MARS can start generating incidents based on NetFlow’s anomaly
detection.
Host and Device Identification and Detail Strategies
MARS studies many events at the network layer, relying on firewalls, routers, and IPS devices to identify
anomalies and suspected incidents at a layer above the endpoint hosts that are the source or destination
of network sessions. If operating exclusively at this network layer, MARS can generate a number of false
positive incidents that must be manually investigated. However, several features exist that allow you to
provide host-level details to MARS:
• Enable event reporting from the hosts on your network. MARS can receive, and in some cases, pull
event data directly from the hosts on your network. This additional data allows MARS to verify the
success of some attacks, as well as to report issues with the operation of the host, such as including
them in “device down” reports if they are inaccessible. For more information on configuring the
hosts and MARS to pull or receive data from those hosts, see the following topics:
–
Adding Generic Devices, page 10-1
–
Sun Solaris and Linux Hosts, page 10-2
–
Microsoft Windows Hosts, page 10-4
• Manually identify the operating system type and network services running on discovered hosts. For
more information, see Define Vulnerability Assessment Information, page 10-12 and Identify
Network Services Running on the Host, page 10-14
• Manually identify common hosts and nodes in your network by adding other devices via
Management > IP Management. This additional data allows you to identify those hosts that are
likely to be involved in network sessions without having to configure the hosts to provide event data
directly to MARS. This open allows you to provide vulnerability assessment information to assist
in the reduction of false positives. For more information on adding hosts manually, see Add a Host,
page 23-5.
2-37
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Configuring Layer 3 Topology Discovery
For the MARS to reach full operability, you must specify its community strings and select the networks
that you want to discover. Once the appliance discovers these networks, you get a more accurate view of
MAC addresses, end-point lookup (attack paths), and network topology. Topology discovery enables
operation level three, see Levels of Operation, page 2-1 for more information.
See Figure 17-13 on page 17-7 for a view of the topologies.
Note Remember to activate additions and changes to your community strings and valid networks by clicking
Activate.
Add a Community String for a Network
To add a community string for a network IP, follow these steps:
Step 1 To open the Community Strings and Networks page, click Admin > Community Strings and
Networks.
Step 2 Click the Network IP radio button.
Step 3 Enter the Community String, Network IP address, and Mask.
Step 4 Click Add.
Step 5 Repeat Step 2 through Step 4 for all the community strings that you want to add.
Step 6 Click Submit to commit these additions.
Add a Community String for an IP Range
To add a community string for an IP range, follow these steps:
Step 1 To open the Community Strings and Networks page, click Admin > Community Strings and
Networks.
Step 2 Click the IP Range radio button.
2-38
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Step 3 Enter the Community String and its IP Range.
Step 4 Click Add.
Step 5 Repeat Step 2 through Step 4 for all the community strings that you want to add.
Step 6 Click Submit to commit these additions.
You can add multiple community strings for the same network by adding similar entries.
Add Valid Networks to Discovery List
Adding valid networks confines the MARS to discover the networks that you want. MARS uses this
information to create topologies, find MAC addresses, and for end-point lookup (attack paths).
Note You can only specify networks for the zone where the MARS Appliance operates.
To add valid networks, follow these steps:
Step 1 Click Admin > Valid Networks to open the Valid Networks page.
Step 2 Enter the SNMP Target’s IP address.
The SNMP target is the entry-point where the MARS starts discovering devices on a network. It typically
identifies an address on a default gateway of the network.
Step 3 Click either Network IP or Network Range to define the scope of the scan.
Step 4 Enter the appropriate information.
Step 5 Click Submit.
Remove Networks from Discovery List
To remove a network, follow these steps:
Step 1 Click Admin > Valid Networks to open the Valid Networks page.
Step 2 Click the network that you want to remove.
Step 3 Click Remove.
Discover Layer 3 Data On Demand
You can schedule topology discovery, as defined in Scheduling Topology Updates, page 2-39. However,
you can also initiate an on-demand discovery.
To perform an on-demand discovery, follow these steps:
Step 1 Click Admin > Valid Networks to open the Valid Networks page.
2-39
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Step 2 Verify that the list of Valid Network Addresses contains the networks that you want to discover.
Step 3 Click Discover Now.
Scheduling Topology Updates
You can configure MARS to run automatic topology updates on devices, networks, and groups of
networks. Scheduling topology updates is a critical part of keeping the MARS Appliance abreast of
changes in the network and of changes to the configuration settings of the reporting devices and
mitigation devices. This operation is similar to clicking Discover when defining a reporting device.
Configuration discovery depends on the device type, proper authorization, an access type, such as Telnet
or SSH, and an access IP address. When device discovery is performed, MARS contacts the device and
conducts a topology and configuration discovery. This discovery collects all of the route, NAT, and
ACL-related information for the device or admin context. In addition, the name of the device may
change to
hostname.domain format if it was not already entered as such. If discovering a device that
supports them, MARS also discovers information about modules, admin contexts, and security contexts.
Another effect of scheduled updates is that MARS keeps the network diagram and attack paths current
in the Dashboard.
This feature also allows you to pull data from those devices that require interval-based polling. The list
to devices that require such polling are:
• Qualys QualysGuard
• eEye REM
• FoundStone FoundScan
• Check Point log servers
Figure 2-1 Example Scheduled Update for eEye REM
2-40
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Schedule a Network Discovery
To add a network for scheduled discovery, follow these steps:
Step 1 Click Admin > Topology/Monitored Device Update Scheduler.
The Topology/Monitored Device Update Scheduler page displays.
Step 2 Click Add.
Step 3 Enter a name for the network (or group of networks).
Step 4 Select or enter your networks:
• Click the Select radio button, and select a network from the list.
• Click the Network IP radio button, and enter the IP address and Mask.
• Click the IP Range radio button, and enter the IP ranges.
Step 5 Click Add to move the network into the selected field.
• To remove an item in the selected field, click it to highlight it, and click Remove.
Step 6 In the schedule table, select the appropriate radio button and its time criteria:
• Run On Demand Only
• Daily and the Time of Day
• Wee k l y, the Time of Day, and the Days
• Monthly, the Time of the Day, and the Dates
Step 7 Click Submit.
To edit a scheduled topology discovery
Step 1 Check the box next to the Topology Group.
Step 2 Click Edit.
Step 3 Click Add to move the network into the selected field.
• To remove an item in the selected field, click it to highlight it, and click Remove.
Step 4 In the schedule table, select the appropriate radio button and its time criteria:
• Run On Demand Only
• Daily and the Time of Day
• Wee k l y, the Time of Day, and the Days
• Monthly, the Time of the Day, and the Dates
Step 5 Click Submit.
2-41
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
To delete a scheduled topology discovery
Step 1 Check the box next to the Topology Group.
Step 2 Click Delete.
To run a topology discovery on demand
Note You can run any scheduled or on-demand topology discoveries at any time.
Step 1 Check the box next to the Topology Group.
Step 2 Click Run Now.
Configuring Resource Usage Data
While the Monitor Resource Usage box appears on every host and reporting device, only three device
types actually provide resource usage data to MARS:
• Cisco IOS routers running 12.2
• Cisco IOS switches running 12.2
• Cisco PIX 6.0, 6.1, 6.2, 6.3, 7.0
• Cisco ASA 7.x
• Cisco FWSM 2.x and 3.x
• Check Point devices (Opsec NG FP3)
For these six devices, MARS can provide data about CPU utilization, memory utilization, and device
saturation. For FWSM, MARS monitors system context level resources (CPU, memory, connections) via
the CLI and per-context resources (CPU, memory, connections, interface utilization, and errors) via
SNMP. Therefore, you can monitor three views of the FWSM module: base platform (IOS switch
hosting the module), module level (system context), and security context level.
To enable the collection of resource usage data, you must ensure that the resource usage-specific events
are logged by the reporting devices, that the SNMP RO community string is set, that those devices
forward the events to MARS, and that the device is defined in the web interface as a reporting device or
mitigation device. In addition, you must select Yes in the Monitor Resource Usage box of the General
tab for each supported reporting device.
Once configured, MARS uses SNMP to poll the device every 5 minutes for the following SNMP OIDs:
• Bytes in/out of every interface on the device (Cisco IOS, Cisco PIX)
• Number of current connections (Cisco PIX, Check Point)
• CPU of last second and last 60 seconds (Cisco IOS, Cisco PIX)
• Memory free/used (Cisco IOS, Cisco PIX)
2-42
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
It also detects anomalous resource utilization if the consumption is significantly higher than the hourly
average.
The following resource usage data reports are available:
• Resource Utilization: Bandwidth: Inbound - Top Interfaces
• Resource Utilization: Bandwidth: Outbound - Top Interfaces
• Resource Utilization: CPU - Top Devices
• Resource Utilization: Concurrent Connections - Top Devices
• Resource Utilization: Errors: Inbound - Top Interfaces
• Resource Utilization: Errors: Outbound - Top Interfaces
• Resource Utilization: Memory - Top Devices
You can define custom rules, reports, and queries about resource usage based on the following events:
• CPU Utilization Higher Than 50%
• CPU Utilization Higher Than 75%
• CPU Utilization Higher Than 90%
• CPU Utilization Abnormally High
• Memory Utilization Higher Than 50%
• Memory Utilization Higher Than 75%
• Memory Utilization Higher Than 90%
• Memory Utilization Abnormally High
There is also is pre-defined resource utilization inspection rule:
• System Rule: DoS: Network Device - Success Likely
• System Rule: DoS: Network - Success Likely
• System Rule: Resource Issue: Network Device
Enabling the Required SNMP OIDs for Resource Monitoring
Table 2 - 5 lists the OIDs to enable, on a per device basis, for the supported model and versions.
2-43
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Table 2-5 SNMP OIDs Required for Resource Monitoring
Vendor, Model,
and Version OID Descriptor OID
Cisco IOS 12.2 DEVICE_RES_OID_CPU .1.3.6.1.4.1.9.2.1.56.0
DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
2-44
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Cisco Switch-IOS
12.2
DEVICE_RES_OID_CPU .1.3.6.1.4.1.9.2.1.56.0
DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
Cisco PIX 6.0 DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_CONNECTION .1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
Table 2-5 SNMP OIDs Required for Resource Monitoring (continued)
Vendor, Model,
and Version OID Descriptor OID
2-45
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Cisco PIX 6.1 DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_CONNECTION .1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
Table 2-5 SNMP OIDs Required for Resource Monitoring (continued)
Vendor, Model,
and Version OID Descriptor OID
2-46
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Cisco PIX 6.2 DEVICE_RES_OID_CPU .1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_CONNECTION .1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
Table 2-5 SNMP OIDs Required for Resource Monitoring (continued)
Vendor, Model,
and Version OID Descriptor OID
2-47
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Cisco PIX 6.3 DEVICE_RES_OID_CPU .1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_CONNECTION .1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
Table 2-5 SNMP OIDs Required for Resource Monitoring (continued)
Vendor, Model,
and Version OID Descriptor OID
2-48
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Cisco PIX 7.0 DEVICE_RES_OID_CPU .1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_CONNECTION .1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
Table 2-5 SNMP OIDs Required for Resource Monitoring (continued)
Vendor, Model,
and Version OID Descriptor OID
2-49
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Cisco FWSM 2.2 DEVICE_RES_OID_CPU .1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_CONNECTION .1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
Table 2-5 SNMP OIDs Required for Resource Monitoring (continued)
Vendor, Model,
and Version OID Descriptor OID
2-50
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 2 Reporting and Mitigation Devices Overview
Data Enabling Features
Cisco FWSM 2.3 DEVICE_RES_OID_CPU .1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
DEVICE_RES_OID_MEMORY_FREE .1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED .1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_CONNECTION .1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_INTERFACE_NUMBER .1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES .1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES .1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH .1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR .1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR .1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET .1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET .1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET .1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR .1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS .1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS .1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS .1.3.6.1.2.1.2.2.1.19.i
Table 2-5 SNMP OIDs Required for Resource Monitoring (continued)
Vendor, Model,
and Version OID Descriptor OID
Loading...