- Title Page
- Introduction & Preface
- Logging into the FireSIGHT System
- Using Objects and Security Zones
- Managing Devices
- Setting Up an IPS Device
- Setting Up Virtual Switches
- Setting Up Virtual Routers
- Setting Up Aggregate Interfaces
- Setting Up Hybrid Interfaces
- Using Gateway VPNs
- Using NAT Policies
- Getting Started with Access Control Policies
- Blacklisting Using Security Intelligence IP Address Reputation
- Tuning Traffic Flow Using Access Control Rules
- Controlling Traffic with Network-Based Rules
- Controlling Traffic with Reputation-Based Rules
- Controlling Traffic Based on Users
- Controlling Traffic Using Intrusion and File Policies
- Understanding Traffic Decryption
- Getting Started with SSL Policies
- Getting Started with SSL Rules
- Tuning Traffic Decryption Using SSL Rules
- Understanding Intrusion and Network Analysis Policies
- Using Layers in Intrusion and Network Analysis Policies
- Customizing Traffic Preprocessing
- Getting Started with Network Analysis Policies
- Using Application Layer Preprocessors
- Configuring SCADA Preprocessing
- Configuring Transport & Network Layer Preprocessing
- Tuning Preprocessing in Passive Deployments
- Getting Started with Intrusion Policies
- Tuning Intrusion Rules
- Tailoring Intrusion Protection to Your Network Assets
- Detecting Specific Threats
- Limiting Intrusion Event Logging
- Understanding and Writing Intrusion Rules
- Blocking Malware and Prohibited Files
- Logging Connections in Network Traffic
- Working with Connection & Security Intelligence Data
- Analyzing Malware and File Activity
- Working with Intrusion Events
- Handling Incidents
- Configuring External Alerting
- Configuring External Alerting for Intrusion Rules
- Introduction to Network Discovery
- Enhancing Network Discovery
- Configuring Active Scanning
- Using the Network Map
- Using Host Profiles
- Working with Discovery Events
- Configuring Correlation Policies and Rules
- Using the FireSIGHT System as a Compliance Tool
- Creating Traffic Profiles
- Configuring Remediations
- Using Dashboards
- Using the Context Explorer
- Working with Reports
- Understanding and Using Workflows
- Using Custom Tables
- Searching for Events
- Managing Users
- Scheduling Tasks
- Managing System Policies
- Configuring Appliance Settings
- Licensing the FireSIGHT System
- Updating System Software
- Monitoring the System
- Using Health Monitoring
- Auditing the System
- Using Backup and Restore
- Specifying User Preferences
- Importing and Exporting Configurations
- Purging Discovery Data from the Database
- Viewing the Status of Long-Running Tasks
- Command Line Reference
- Security, Internet Access, and Communication Ports
- Third-Party Products
- glossary
Configuring SCADA Preprocessing
You configure Supervisory Control and Data Acquisition (SCADA) preprocessors in a network analysis policy, which prepares traffic for inspection using the rules enabled in an intrusion policy. See Understanding Network Analysis and Intrusion Policies for more information.
SCADA protocols monitor, control, and acquire data from industrial, infrastructure, and facility processes such as manufacturing, production, water treatment, electric power distribution, airport and shipping systems, and so on. The FireSIGHT System provides preprocessors for the Modbus and DNP3 SCADA protocols that you can configure as part of your network analysis policy.
Caution Some users with custom user roles cannot access the network analysis policy via the standard menu path (Policies > Access Control > Network Analysis Policy). These users can access the network analysis policy through the intrusion policy: Policies > Intrusion > Intrusion Policy > Network Analysis Policy. For more information on custom user roles, see Managing Custom User Roles.
If you enable a rule containing Modbus or DNP3 keywords in the corresponding intrusion policy, the system automatically uses the Modbus or DNP3 processor, respectively, with its current settings, although the preprocessor remains disabled in the network analysis policy web interface. For more information, see Modbus Keywords and DNP3 Keywords.
Configuring the Modbus Preprocessor
The Modbus protocol, which was first published in 1979 by Modicon, is a widely used SCADA protocol. The Modbus preprocessor detects anomalies in Modbus traffic and decodes the Modbus protocol for processing by the rules engine, which uses Modbus keywords to access certain protocol fields. See Modbus Keywords for more information.
A single configuration option allows you to modify the default setting for the port that the preprocessor inspects for Modbus traffic.
You must enable the Modbus preprocessor rules in the following table if you want these rules to generate events. See Setting Rule States for information on enabling rules.
Note regarding the use of the Modbus preprocessor that if your network does not contain any Modbus-enabled devices, you should not enable this preprocessor in a network analysis policy that you apply to traffic.
You can use the following procedure to modify the ports the Modbus preprocessor monitors.
To configure the Modbus preprocessor:
Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy .
The Network Analysis Policy page appears.
Step 2 Click the edit icon (
) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.
The Policy Information page appears.
Step 3 Click Settings in the navigation panel on the left.
Step 4 You have two choices, depending on whether Modbus Configuration under SCADA Preprocessors is enabled:
The Modbus Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.
Step 5 Optionally, modify the Ports that the preprocessor inspects for Modbus traffic. You can specify an integer from 0 to 65535. Use commas to separate multiple ports.
Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.
Configuring the DNP3 Preprocessor
The Distributed Network Protocol (DNP3) is a SCADA protocol that was originally developed to provide consistent communication between electrical stations. DNP3 has also become widely used in the water, waste, transportation, and many other industries.
The DNP3 preprocessor detects anomalies in DNP3 traffic and decodes the DNP3 protocol for processing by the rules engine, which uses DNP3 keywords to access certain protocol fields. See DNP3 Keywords for more information.
You must enable the DNP3 preprocessor rules in the following table if you want these rules to generate events. See Setting Rule States for information on enabling rules.
Note regarding the use of the DNP3 preprocessor that, if your network does not contain any DNP3-enabled devices, you should not enable this preprocessor in a network analysis policy that you apply to traffic. See Configuring TCP Stream Preprocessing for more information.
The following list describes the DNP3 preprocessor options you can configure.
Enables inspection of DNP3 traffic on each specified port. You can specify a single port or a comma-separated list of ports. You can specify a value from 0 to 65535 for each port.
When enabled, validates the checksums contained in DNP3 link layer frames. Frames with invalid checksums are ignored.
You can enable rule 145:1 to generate events when invalid checksums are detected.
To configure the DNP3 preprocessor:
Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy .
The Network Analysis Policy page appears.
Step 2 Click the edit icon (
) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.
The Policy Information page appears.
Step 3 Click Settings in the navigation panel on the left.
Step 4 You have two choices, depending on whether DNP3 Configuration under SCADA Preprocessors is enabled:
The DNP3 Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.
Step 5 Optionally, modify the Ports that the preprocessor inspects for DNP3 traffic. You can specify an integer from 0 to 65535. Use commas to separate multiple ports.
Step 6 Optionally, select or clear the Log bad CRCs check box to specify whether to validate the checksums contained in DNP3 link layer frames and ignore frames with invalid checksums.
Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See the Network Analysis Policy Editing Actions table for more information.
Configuring the CIP Preprocessor
The Common Industrial Protocol (CIP) is a widely used application protocol that supports industrial automation applications. EtherNet/IP is an implementation of CIP that is used on Ethernet-based networks.
The CIP preprocessor detects CIP and ENIP traffic running on TCP or UDP and sends it to the intrusion rules engine. You can use CIP and ENIP keywords in custom intrusion rules to detect attacks in CIP and ENIP traffic. See CIP and ENIP Keywords. Additionally, you can control traffic by specifying CIP and ENIP application conditions in access control rules. See Controlling Application Traffic.
- To detect CIP and ENIP applications and use them in access control rules, intrusion rules and so on, you must manually enable the CIP preprocessor in the corresponding network analysis policy. See Setting the Default Network Analysis Policy for Access Control and Specifying Traffic to Preprocess Using Network Analysis Rules.
- To drop traffic that triggers CIP preprocessor rules and CIP intrusion rules, ensure that the corresponding intrusion policy Drop when Inline option is enabled. See Setting Drop Behavior in an Inline Deployment.
- To block CIP or ENIP application traffic using access control rules, ensure that the inline normalization preprocessor and its Inline Mode option are enabled in the corresponding network analysis policy. See Normalizing Inline Traffic and Allowing Preprocessors to Affect Traffic in Inline Deployments.
- Add the default CIP detection port 44818 and any other ports you list to the TCP stream Perform Stream Reassembly on Both Ports list. See Selecting Stream Reassembly Options.
- Event viewers give special handling to CIP applications. See Understanding CIP Events.
You must enable the CIP preprocessor rules listed in the following table if you want them to generate events. See Setting Rule States for information on enabling rules.
The following list describes CIP preprocessor options you can modify.
Specifies the ports to inspect for CIP and ENIP traffic. You can specify an integer from 0 to 65535. Separate multiple port numbers with commas.
Note You must add the default CIP detection port 44818 and any other ports you list to the TCP stream Perform Stream Reassembly on Both Ports list. See Selecting Stream Reassembly Options.
Default Unconnected Timeout (seconds)
When a CIP request message does not contain a protocol-specific timeout value and Maximum number of concurrent unconnected requests per TCP connection is reached, the system times the message for the number of seconds specified by this option. When the timer expires, the message is removed to make room for future requests. You can specify an integer from 0 to 360. When you specify 0, all traffic that does not have a protocol-specific timeout times out first.
Maximum number of concurrent unconnected requests per TCP connection
The number of concurrent requests that can go unanswered before the system closes the connection. You can specify an integer from 1 to 10000.
Maximum number of CIP connections per TCP connection
The maximum number of simultaneous CIP connections allowed by the system per TCP connection. You can specify an integer from 1 to 10000.
To configure the CIP preprocessor:
Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy .
The Network Analysis Policy page appears.
Step 2 Click the edit icon (
) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.
The Policy Information page appears.
Step 3 Click Settings in the navigation panel on the left.
Step 4 You have two choices, depending on whether CIP Configuration under SCADA Preprocessors is enabled:
The CIP Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.
Step 5 You can modify any of the options described in this section.
Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.
Understanding CIP Events
By design, application detectors detect and event viewers display the same application one time per session. A CIP session can include multiple applications in different packets, and a single CIP packet can contain multiple applications. The CIP preprocessor handles all CIP and ENIP traffic according to the corresponding rule and controls the display of CIP events as follows:
- Application Protocol: CIP or ENIP
- Client: CIP Client or ENIP Client
- Web Application: the specific application detected, which is:
– For rules that allow or monitor traffic: the last application protocol detected in the session.
Note that access control rules that you configure to log connections might not generate events for specified CIP applications, and access control rules that you do not configure to log connections might generate events for CIP applications.
– For rules that block traffic: the application protocol that triggered the block.
When an access control rule blocks a list of CIP applications, event viewers display the first application that is detected.
- Cisco recommends that you use an access control policy default action of Intrusion Prevention .
- The CIP preprocessor does not support an access control policy default action of Access Control: Trust All Traffic which may produce undesirable behavior, including not dropping traffic triggered by CIP applications specified in intrusion rules and access control rules.
- The CIP preprocessor does not support an access control policy default action of Access Control: Block All Traffic which may produce undesirable behavior, including blocking CIP applications that you do not expect to be blocked.
- The CIP preprocessor does not support application visibility for CIP applications, including network discovery.
See Understanding Connection and Security Intelligence Data Fields for more information.
Feedback