Best Practice: Incident Notifications and Dashboard Alerts

Version 7


    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).




    A TechTalk was held to demo this ruleset and explain it's purpose. The video for the TechTalk can be found here, the Incident Notifications ruleset was the first topic, and is about 15 minutes long.


    Click here to view the TechTalk Demo



    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.


    Incident IDs - Origin.png


    For a full Incident ID listing you still have the option of searching the help file in the UI, or reviewing the McAfee Web Gateway 7.4.2 Product Guide on page 567.



    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.



    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).





    Download the "Incident Notifications" 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.





    Incident Specific Settings



    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
    # Example 2 - Send an email to, write to syslog, and write to the incident.log.
    # Example 3 - Send an email with the custom message "Custom message: Call the data center." to and, also send an SNMP trap.
    1100;Custom message: Call the data center.;;




    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.



    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: Incident Response: Support Recommendations


    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.



    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.



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


    Install Block Pages

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




    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.



    Configure the Snooze options in the Error Handler

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




    Delivery Methods


    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



    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




    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.



    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


    To find out more about custom logs, please see the following article:


    Older than 7.4.2

    The updated revision of this guide was written for 7.4.2 or newer in order to take advantage of newer features. See previous version of this guide:



    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