Skip to main content
Skyhigh Security

Configuring Incident Notifications and Alerts

Introduction

This article will explain how to use and implement "Incident Notification" ruleset. Using the ruleset along with the Alerts you find in the dashboard you can begin to receive proactive notifications which include actionable next steps (Support Recommendations).

Understanding Incidents/Alerts

An Incident (good or bad) is an action or event that was triggered by the Web Gateway process. An Alert is a record of this Incident. A good example of this is when the Web Gateway tries to update the URL Filter engine, push a log file, or connect to the domain. The Incident would be the action taken, and the Alert would be the outcome of that action. Everything that shows up in the Dashboard Alerts can be referenced by an Incident ID. Throughout this article, we will be referencing Incident IDs in order to generate notifications.

Locating Incident IDs

Starting in Web Gateway 7.4.0 Incident IDs can be found dashboard alert messages themselves. This helps in identifying Incident IDs you might be interested in to quickly add to your notification rules. For a full Incident ID listing you still have the option of searching the help file in the UI.

Simplified View

This ruleset uses the Simplified View. You will see less of the inner workings of the ruleset, if you have any reason to unlock it, please post your use case here, and we can try and address it. If you unlock it, and quickly regret it, please reimport the ruleset and refer to existing objects on import.

Incident Notification Ruleset

The Web Gateway support team has come up with a ruleset that is intended to simplify incident notifications. We have incorporated a feature that allows for actionable information to be included IN the notification. This actionable information is called Support Recommendations.

Concept

The concept of this ruleset is simple, identify an alert you want to know about, add it to a list to receive a notification in whatever form you want (email/snmp/syslog/incident.log).

Example

clipboard_e117e89adb3fe47b670caba06d27b5d43.png

Install

Download the "Incident Notifications v2.0.zip" To install the ruleset, navigate to Policy > Rule Sets > Error Handler, select the Default Error Handler, then import from the library, choosing the "Import from File" option. Refer to existing objects if there are any conflicts.

clipboard_ecdd29600b7ced800f59f0a484ecccc43.png

clipboard_e5a2ff1e95e10d68b393eef42eac42caf.png

Configuration

Incident Specific Settings

clipboard_e3bac0d0ffdc0af8f47b4be905f65c67e.png

With each incident you can configure incident specific settings. The incident specific settings involve three things:

  1. Notification "switches" (1's and 0's)
  2. User defined message (optional)
  3. Incident specific email recipient (optional)
  • Example 1 - Send an email to the default recipient and write to a the incident.log 1001;
  • Example 2 - Send an email to john_doe@company.com, write to syslog, and write to the incident.log. 1011;john_doe@company.com
  • Example 3 - Send an email with the custom message "Custom message: Call the data center." to john_doe@company.com and jane_doe@company.com, also send an SNMP trap.

1100;Custom message: Call the data center.;john_doe@company.com;jane_doe@company.com

clipboard_e9f15345119193d3470b58a16b3c8b648.png

Global override options

If you wish to always send an SNMP trap, send to syslog, or write to the incident.log, incident specific settings can be overridden.

clipboard_efd2fa0d93e8ec1a8362d98f38d63eda6.png

Support Recommendations

Support recommendations are included in the notifications sent by Web Gateway. Recommendations are updated by the Web Gateway support team using the subscribed lists feature. LEAVE THIS ON.

The list of Support Recommendations can be found here:

clipboard_e7f9fb6edfea272b373b4bbb501efc44c.png

Mail Settings

In order for Web Gateway to send email notifications, you must define default recipients (for which emails will be sent to), and also your mail servers. If you have appliances in different regions or subsidiary's, you can specify alternate mail server settings.

clipboard_e26effef1f890fa2747570d443b185e00.png

Snooze Feature (Optional)

Much like an alarm clock's "snooze" feature, there may be notifications you want to "snooze" as well. If you have a failing harddrive and the new drive is on its way, you can acknowledge the notification, and snooze notifications for a configurable amount of time.

The snooze feature is off by default.

Installation

To install the Snooze feature, you must first import the blockpages, then install the ruleset.

Install Block Pages

Download "Incident Snooze Blockpages v2.0.zip" and install the block pages in the Template Editor by navigating to Policy > Settings, select a Blockpage template, and click edit.
clipboard_ed241099ee5906a7ad0e706e501d825a0.png

Install the Snooze Policy Ruleset

To install the Policy ruleset, navigate to Policy > Rule Sets, and stay on the "Rule sets" section. Click "Add" and select "Import Ruleset from Library", on the next screen "Choose from file..." and browse for the "Incident Snooze v2.0.xml" file.

In the Snooze Policy Ruleset, you can restrict access, disallow resets of Snoozed alerts, and configure the Snooze Time.

clipboard_e8fc4e6cf355a3ac65b488b0a2bdc5bb6.png

Configure the Snooze options in the Error Handler

In the Error Handler options are configurable for what the Snooze URL should be (external --swginternal.com, internal -- the appliance hostname, or off). You can also define what items will be snoozed.

clipboard_e02782ebfebc84525b690283b94ddc6f9.png

clipboard_e0286ae363d8dc5719fecb9c070025526.png

Delivery Methods

Email

To be able to receive notifications via Email, it is required to first configure the Email notification settings under Policy > Settings > Email Notification. If you have multiple appliances in Central management, this only needs to be applied once, as it is part of the policy and shared between appliances.

The required settings include:

  • SMTP server. Enter the active/functioning SMTP server name
  • SMTP port. Enter the port that is used for SMTP
  • HELO name. Enter the HELO name of the SMTP server
  • Sender name. Enter the value configured to be the sender name

clipboard_e88438098ae20e8c3d3647fd3f7599a7e.png

SNMP Traps

To be able to receive notifications via SNMP Traps, it is required to first configure the SNMP Trap Sink under Configuration > SNMP. The SNMP settings are unique per appliance and need to be configured for each member of a central management cluster.

These required settings include:

  • SNMP Trap Sinks. these settings specify the management systems that will receive traps from the agent
  • Host name or IP address. Enter the host name or IP of the server that is to be used as the Trap Receiver
  • Port. The listener port that is configured to listen for SNMP messages
  • Community string. Enter the string message that is expected by the Trap Receiver

clipboard_e081cf8d66349a2d5ec068ac82a95d4e0.png

Syslog

To be able to receive notifications via syslog, it is required to first configure the rsyslog.conf file under Configuration > File Editor > rsyslog.conf. The syslog settings are unique per appliance and need to be configured for each member of a central management cluster.

clipboard_e13529c004577a6b75641c050dda58a18.png

Incident.log (a local log)

It is highly recommended to use a local file in addition to any of the delivery methods above. This log file will give you a record of all the notifications that have been triggered and helps to troubleshoot in case other delivery methods are not working correctly.

To be able to write notifications into a local log file, it is required to first configure a new log file under Policy > Settings > File System Logging . If you have multiple appliances in Central management, this only needs to be applied once, as it is part of the policy and shared between appliances.

The required settings include:

  • Name of the log. Enter the name of the log file that will be used in the event the Incident criteria is matched
  • Settings for Rotation, Pushing, and Deletion. These settings are required

clipboard_eb9c57c292c371be7825f4ff16c6dd4f1.png

Changelog

If any changes are made to the ruleset, the version number of the ruleset will be incremented and documented here. To update, simply delete the old ruleset and import the new ruleset in place of the old one. Your lists and settings should all be preserved on the Web Gateway.

  • Version 2.0 - Rewrite of Incident Notifications, incorporation of Support Recommendations
  • Was this article helpful?