STM Task Flow Overview
Available Languages
Table Of Contents
Checklist for Provisioning Phase
Checklist for Monitoring Phase
Strategies for Monitoring, Notification, Mitigation, Remediation, and Audit
Appliance-side Tuning Guidelines
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.
•
•
•
Your monitoring policy should:
•
•
•
•
•
Your mitigation policy should:
•
•
•
•
•
•
•
Your remediation policy should:
•
•
•
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.
2.
3.
4.
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:
•
•
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.
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.
•
•
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:
•
•
•
2.
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.
TipTo 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:
•
•
•
•
•
3.
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:
•
•
•
•
•
•
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.
TipFor more information, see:
•
•
•
4.
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:
•
•
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:
•
•
•
•
•
•
5.
After you add the devices, you can enable the rich data collection features of MARS, which include:
•
•
•
•
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:
•
•
•
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:
•
•
•
•
•
•
•
6.
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:
•
7.
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:
•
•
Note
Note
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.
TipResult: The events being processed by the MARS Appliance are restricted to those that provide value to the STM system.
For more information, see:
•
•
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.
Note
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.
1.
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:
•
2.
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:
•
•
•
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). You must also identify the devices that need to be notified or that need to take some action (see Device Inventory Worksheet).
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:
•
•
•
•
3.
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:
•
•
•
•
4.
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:
•
•
5.
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:
•
•
•
•
6.
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.
TipMARS 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:
•
•
•
•
•
•
7.
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.
•
Note
•
•
•
•
•
•
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:
•
•
•
Strategies for Monitoring, Notification, Mitigation, Remediation, and Audit
STM requires the close coordination of multiple strategies in support of your corporate security policies:
•
•
•
•
•
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:
•
•
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:
•
Note
•
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:
•
•
•
•
•
•
•
•
•
•
User Role Worksheet
The user role worksheet will help you collect required information about administrators of your network. It includes the following information:
•
•
•
•
•
•
•
Table 1-2 User Role Worksheet
Feedback