Alert types and functions


BMC Defender Servers alerting functions complement the Thread functions discussed previously and can be considered a type of correlation. Specifically, whereas the threads group together messages that match a common criteria, alerts correlate the counts of these messages with respect to time, and generate new alerts when the number of messages during a time window exceeds.

All alerting functions exist in the Alerts tab of the system. All alerting functions open tickets on the system, and further feed syslog messages back to the main event log. All alerting functions include a Suggest option (to suggest an alert message to be sent, that is also the same text used in tickets).

Given the preceding common features, the types of alerting is somewhat diverse, and is used for different alerting applications as follows:

  • Counter Alerts—The Alerts > Counters screen provides general utility in keeping track of the number of incoming messages associated with a particular thread counter. These are the most commonly used types of alerts; they work with all types of threads and messages, and they furnish a great overview of anomalous activity, building on the organization of correlation threads. Counter alerts work with the auto-learn function of the system. Counter alerts permit GT (Greater Than), or LT (Less Than) compare functions.
  • Device Alerts—The Alerts > Devices screen furnishes a more specialized type of alerting, where a single match pattern is applied across a range of devices. For instance, if you want to be alerted if, any device receives more than X number of errors in Z seconds, this is the type of alert to use. 

    Warning

    Note

    This is quite different than Counter Alerts since device alerts are maintained for each active device instance, and these instances refer to an alert condition specific to a particular device.

  • User Alerts—The Alerts > Users screen it behaves like the Device Alerts, but is specific and maintained for each active user instance. For instance, this is the type of alert to employ if the operator wants to be alerted when any user receives more than X number of errors in Z seconds.
  • Pattern Alerts—The Alerts > Patterns screen supports a highly specialized type of alerting that works with Trigger elements of the system. The alert condition exists when a certain combination of correlation triggers get detected during an overlapping time window. For instance, if the administrator has configured a trigger which is active for 200 seconds when a printer is active and has configured another trigger that is active for 300 seconds when a file is accessed, then the Pattern Alert detects the condition of both of these triggers being set (indicating that a file might have been printed out.) Patterns are configured for All Messages, or in a context of Same Device or Same User. This gives the operator considerable control in detecting anomalous system, hardware, or user activity.
  • Custom Alerts—The Alerts > Custom screen furnishes a highly specialized type of extensible alert, based on the execution of batch files (whose output is scanned for match patterns) and based on the execution of a parse function across a range of thread messages. This type of alert offers a wide integration area to cover any esoteric type of alerting. Custom Alerts are documented are detailed within subsequent sections of this section.

Each of the preceding types of alerts, while somewhat different, behave similarly:The count of some value gets compared to a threshold during a specified time interval. If the threshold gets violated, then a syslog message is sent back to the main event log (possibly for further correlation), and a ticket is opened in the Tickets tab. The ticket can trigger notifications, such as e-mail. The ticket documents the alert condition, including the messages that caused the alert to be triggered.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC AMI Command Center for Security 5.9