SL1 easily integrates with existing security hardware, software, and policies and adds additional security features and automation. The following sections will describe the added security that SL1 can add to your network.
Use the following menu options to navigate the SL1 user interface:
- To view a pop-out list of menu options, click the menu icon (
). - To view a page containing all of the menu options, click the Advanced menu icon (
).
Monitoring IDS, Firewalls, and Security Hardware
As a Manager of Managers, SL1 can monitor security hardware, including intrusion detection systems and firewalls. SL1 can generate alarms (called events) about the security hardware. SL1 can also create alarms about network information that the security hardware collects.
For example, SL1 can generate an alarm when a Cisco IPS Sensor indicates a change in security status.
Security Events
Using policies, Dynamic Applications, and retrieved log messages, SL1 can monitor security on each managed device and generate alerts about security breaches.
For example, SL1 can generate an alert when a user opens a chassis on a Dell server.
SL1 ships with many pre-defined security events. You can also easily customize your system to monitor the security events and generate alerts that are most useful to your operations.
You can define customized events specifically for your operations.
You can define escalation policies based on events.
Monitoring Changes to Device Configuration
SL1 can automatically create an asset record for each discovered device. SL1 uses information gathered from the device during initial discovery, nightly auto-discovery, and from Dynamic Applications to populate each asset record.
Asset records can contain the following information:
- The name, make, and model of the device
- The serial number of the device
- The function and status of the device
- Networking information, like host ID, IP address, and DNS server for the device
- Hardware information like amount of memory, CPU, and BIOS or EPROM version
- The physical location of the device
- Vendor information for the device, including PO or check number, warranty policy, and service policy
- A description of the network interface
- A description of each hardware component (if applicable)
- A description of installed software (if applicable)
In SL1, you can define a policy for one or more asset fields that you want to monitor. If the value of a monitored asset field changes, the platform will alert you to the change.
Monitoring for Illicit Behavior
SL1 can monitor devices for misuse and illicit behavior. SL1 can alert users when:
- illicit DNS domains or DNS records are discovered on a Domain Name server
- illicit processes are found on one or more devices
- processes are running as "root" or "su" on one or more devices
- illicit Windows services are found on one or more devices
- illicit ports are found open on one or more devices
Blueprinting Windows Services
You can define policies that monitor the Windows services on each Windows server. You can create a "blueprint" of the services and settings that should run on each Windows server. If SL1 detects a change to those services and settings, SL1 can automatically restore the server to its blueprint of services and settings.
Blueprinting System Processes
You can define policies that monitor the system process on a server. You can create a "blueprint" of the processes and process settings on each server. If SL1 detects a change to those processes or their settings, SL1 can generate an alert, specifying the exact changes to the blueprint.
Blueprinting DNS
You can define policies that monitor DNS servers. You can create a "blueprint" of the records that should exist on the server. If SL1 detects a change to those records, the platform can generate an alert, specifying the exact change to each changed record.
Monitoring Open Ports
SL1 helps you limit open ports on each managed device and reduce your vulnerability to attacks.
During initial discovery, SL1 scans each device to discover all the open ports on the device. SL1 also scans each device every night and looks for any newly opened ports.
- If SL1 discovers an illicit port, SL1 can alert users. System administrators can define which ports to consider "illicit".
- If SL1 discovers a newly opened port, SL1 can alert users of the new port.
Monitoring Bandwidth Usage
SL1 discovers each network interface on each managed device. SL1 can then monitor bandwidth usage and performance for each network interface.
You can define thresholds for bandwidth usage and performance. These thresholds will alert you of unusual or illicit bandwidth usage.
You can define global thresholds for the following bandwidth statistics. If any network interface on any device exceeds these thresholds, the platform will alert users.
You can also define each of these thresholds per interface. The interface will use the custom thresholds instead of the global thresholds. If the interface exceeds these thresholds, the platform will alert users.
- Inbound Bandwidth. Rate at which a device is using network bandwidth for inbound traffic, in Mb per second. If a device uses bandwidth for inbound traffic at a greater rate than the specified rate, SL1 generates an event.
- Outbound Bandwidth. Rate at which a device is using network bandwidth for outbound traffic, in Mb per second. If a device uses bandwidth for outbound traffic at a greater rate than the specified rate, SL1 generates an event.
- Inbound Percent. Percentage of network bandwidth being used by each device for inbound traffic. If a device uses more than the specified percentage of network bandwidth for inbound traffic, SL1 generates an event.
- Outbound Percent. Percentage of network bandwidth being used by each device for outbound traffic. If a device uses more than the specified percentage of network bandwidth for outbound traffic, SL1 generates an event.
- Inbound Errors. Threshold for number of inbound packet-errors per polling interval per interface. Errors occur when packets are lost due to hardware problems such as breaks in the network or faulty adapter hardware. If the number of inbound packet-errors on an interface exceeds the threshold specified in this field, SL1 will generate an event for that interface.
- Outbound Errors. Threshold for number of outbound packet-errors per polling interval per interface. If the number of outbound packet-errors on an interface exceeds the threshold specified in this field, SL1 will generate an event for that interface.
- Inbound Error Percent. Threshold for percentage of inbound packet-errors per polling interval per interface. If the percentage of inbound packet-errors on an interface exceeds the threshold specified in this field, SL1 will generate an event for that interface. The percentage is calculated as inbound errors/total inbound packets.
- Outbound Error Percent. Threshold for percentage of outbound packet-errors per polling interval per interface. If the percentage of outbound packet-errors on an interface exceeds the threshold specified in this field, SL1 will generate an event for that interface. The percentage is calculated as outbound errors/total outbound packets.
- Inbound Discards. Threshold for number of inbound packet-discards per polling interval per interface. Discards occur when an interface receives more traffic than it can handle (either very large message or many messages simultaneously). Discards can also occur when an interface has been specifically configured to discard. For example, a user might configure a router's interface to discard packets from a non-authorized IP. If the number of inbound packet-discards on an interface exceeds the threshold specified in this field, SL1 will generate an event for that interface.
- Outbound Discards. Threshold for number of outbound packet-discards per polling interval per interface. If the number of outbound packet-discards on an interface exceeds the threshold specified in this field, SL1 will generate an event for that interface.
- Inbound Discard Percent. Threshold for percentage of inbound packet-discards per polling interval per interface. If the percentage of inbound packet-discards on an interface exceeds the threshold specified in this field, SL1 will generate an event for that interface. The percentage is calculated as inbound discards/total inbound packets.
- Outbound Discard Percent. Threshold for percentage of outbound packet-discards per polling interval per interface. If the percentage of outbound packet-discards on an interface exceeds the threshold specified in this field, SL1 will generate an event for that interface. The percentage is calculated as outbound discards/total outbound packets.
Monitoring Hardware Performance
SL1 allows you to monitor hardware performance, to detect intrusions or illicit use of hardware resources.
SL1 can monitor each device to determine if:
- network connections to the device are unusually slow
- the operating system or CPU on a device is being over-taxed
- one or more file systems on a device are filling up unexpectedly
- one or more CPUs on a device are being over-taxed
- memory or virtual memory on a device is being over-taxed
You can accept the default values or customize these values.
You can define global thresholds for the following hardware statistics. If any device exceeds these thresholds, the platform will alert users.
You can also define each of these thresholds per device. The device will use the custom thresholds instead of the global thresholds. If the device exceeds these thresholds, the platform will alert users.
- System Latency. During polling, SL1 initially pings monitored devices. The value in this field is the maximum number of milliseconds for the device to respond to the platform's ping (round-trip time/2). When the latency threshold is exceeded, SL1 generates an event for that device.
- System Availability. During polling, SL1 monitors devices for availability. Availability means the device's ability to accept connections and data from the network. The value in this field is the percent availability required of each device. When a device falls below this level of availability, SL1 generates an event for that device.
- File System Warning . Threshold that will trigger a "low disk space" event. The default threshold is 85%. When a device has used more disk space than the specified percentage, SL1 will generate an alert with a status of "major".
- File System Critical. Threshold that will trigger a "low disk space" event. The default threshold is 95%. When a device has used more disk space than the specified percentage, SL1 will generate an alert with a status of "critical".
In addition, SL1 includes Dynamic Applications to monitor CPU performance and memory performance. SL1 includes such Dynamic Applications for each major operating system and for generic SNMP.
- For each device that uses a CPU Dynamic Application:
- When a device exceeds the "CPU Utilization High" threshold, SL1 will alert users.
- For each device that uses a memory Dynamic Application:
- When a device exceeds the "Physical Memory Utilization High" threshold, SL1 will alert users.
- When a device exceeds the "Swap Memory Utilization High" threshold, SL1 will alert users.
Managing Patches and Hot Fixes
During initial discovery and during the nightly update, SL1 searches each device and determines the software installed on each device.
From the list of all discovered software, you can generate Software Exclusion Reports. These reports can help administrators manage patches and software versions. Among other information, a Software Exclusions Report displays the following:
- Name of the software title and the date the report was generated
- List of all devices in SL1 that have the software installed
- List of all devices in SL1 that don't have the software installed. SL1 includes only appropriate devices in this report. For example, Linux servers would not appear in a report for a Windows patch.
Using Standard Deviation To Calculate "Normal" Conditions and Abnormal Conditions
SL1 allows you to examine a value retrieved from a device and compare that value it to "normal" values for the hour of day on that day of week. SL1 will trigger an alert if the current retrieved value falls outside the range of "normal" values for the hour of day on that day of week.
Standard deviation allows you to monitor security based on the real-life parameters of your environment. For example, if your organization operates Monday–Friday, from 8:00 AM until 5:00 PM, "normal" values during work hours will differ from "normal" values during the weekend or late at night.
Some possible uses for the deviation function are:
- Determining if an application is functioning properly. For example, if a log file for an application begins to grow at a rate outside the "normal" range for Sunday at 03:00, you can trigger an alert to determine if there is a problem with the application.
- Monitoring security. For example, if bandwidth usage on a Saturday at 23:00 exceeds the normal activity, you can trigger an alert that indicates that your network might have been compromised.
Using Run Book Automation to Automate Responses to Security Events
SL1 includes automation features that allow you to specify actions you want the platform to execute automatically when specific security conditions are met.
Automation in SL1 includes two pieces: an automation policy and an action policy. An automation policy defines the conditions that can trigger an automatic action. When the criteria in an automation policy are met, one or more actions are executed. These actions are defined in an action policy.
For example, an automation policy might specify: if the event "illicit process" occurs on device "mailserver01", and the event is not cleared within five minutes, execute the action policy "email NOC". The action policy "email NOC" could notify all NOC staff about the "illicit process" event.
Automation policies can evaluate one or more of the following criteria:
- whether SL1 has triggered one or more of the specified events (sometimes called "alerts" or "alarms" in other products)
- whether one or more events has occurred on one or more of the specified devices
- whether one or more of the events has the specified severity (critical, major, minor, notice, or healthy)
- whether one or more of the events has the specified status (event is not cleared, event is not acknowledged, ticket is not created for event)
- whether the specified text appeared in the event message
When the criteria in an automation policy are met, an action policy can perform one or more of the following actions:
- Send an Email message to a pre-defined list of users.
- Send an SNMP trap to an external device.
- Create a new ticket.
- Perform an SNMP SET on an external device.
- Execute a custom program written in Python.
- Query a database.
Reports
In addition to security policies and their related alerts, the platform generates multiple reports that trend and categorize hardware performance and policy performance, for all devices in SL1 and per device. You can use these reports to quickly find unusual spikes or lulls in usage.