Custom Alerting

Alert messages can be distributed via e-mail, SNMP, syslog, or user-written Java™ classes. The last option is referred to as custom alerting.

When an alert is triggered, a custom alerting class can take any action appropriate for the situation; for example, it might update a Web page or send a text message to a telephone number.

To create a custom alerting class, first contact Technical Support to obtain the necessary interface file. The following topic describes how to implement the interface. See Use the Custom Alerting Interface, and also the following topic which contains an example: Sample Custom Alerting Class.

Once the class has been compiled, it must be uploaded to the Guardium® appliance. See Manage Custom Classes.

For guidelines on testing a custom alerting class, see the Test a Custom Alerting Class section later in this topic.

Note: Do not take or run custom code from untrusted data sources to order to reduce the risk of security vulnerabilities.

Note: Do not take or run custom code from untrusted sources.

Note: Do not write a custom class that gets data from an untrusted source.

Use the Custom Alerting Interface

The custom alerting class must be in the com.guardium.custom package and must implement the com.guardium.custom.alerts.CustomerDefinedAlertingIfc interface:

package com.guardium.custom
public class YourClassNameHere implements CustomerDefinedAlertingIfc {
       }

The interface contains the five methods described.

Table 1. processAlert Method
Method 1
Description	Process a single alert message.
Syntax	public void processAlert (String message, Date timeStamp)
Parameters	A String containing the message generated by the alert. A java.util.Date for the time the alert message was created.

Table 2. getMessage Method
Method 2
Description	Return the alert message
Syntax	public String getMessage ()
Parameters	A String containing the alert message.

Table 3. getTimeStamp Method
Method 3
Description	Return the timestamp associated with the alert message.
Syntax	public Date getTimeStamp ()
Parameters	A java.util.Date for the time the alert message was created.

Table 4. setMessage Method
Method 4
Description	Set the alert message.
Syntax	public void setMessage (String inMessage)
Parameters	A String containing the alert message.

Table 5. setTimeStamp Method
Method 5
Description	Set the timestamp associated with the alert message.
Syntax	public void setTimeStamp (Date inDate)
Parameters	A java.util.Date for the time the alert message was created.

Sample Custom Alerting Class

The following sample program implements the five methods described in the previous section. For the processAlert method, this program simply writes the alert message and timestamp to the system console.

/*
 * Sample Custom Alerting Class
 *
 */
package com.guardium.custom;
import java.text.DateFormat;
import java.util.Date;
public class HandleAlerts implements CustomerDefinedAlertingIfc {
private String message = "";
private Date timeStamp = null;
public void processAlert(String message, Date timeStamp){
setMessage(message);
setTimeStamp(timeStamp);
System.out.println(getMessage() + " on " +
  DateFormat.getDateInstance(). format(getTimeStamp()));
}
    public void setMessage(String inMessage){
        message = inMessage;
    }
    public String getMessage(){
        return message;
    }
    public void setTimeStamp(Date inDate){
        timeStamp = inDate;
    }
    public Date getTimeStamp(){
        return timeStamp;
    }
}

Test a Custom Alerting Class

After compiling a custom alerting class, follow the procedure to test it.

Upload the custom class to the appliance. This is an administration function that is performed from the Administrator Console. See Manage Custom Classes.
Define a correlation or real-time alert to use the custom alerting class. Regardless of which alert type generates the alert, testing is easier if you assign a second notification type (email, for example) against which you can compare the custom alerting results.
Check the environment by doing one of the following:
- For a correlation alert:
  - Check that the Anomaly Detection polling interval is suitable for testing purposes and that Anomaly Detection has been started. If the polling interval is too long (it may be 30 minutes or more), you may have a long wait before the query runs.
  - Check that the Alerter polling interval is suitable for testing purposes and that the Alerter has been started.
  - Check that the alert to be tested has been marked Active.
- For a real-time alert:
  - Check that policy containing the rule with the custom alert action is the installed policy.
  - Verify that the inspection engine was restarted after the updated policy was installed.
  - Check that the Alerter polling interval is suitable for testing purposes and that it has been started.
Take whatever action is necessary to trigger the alert (generate a number of login failures, for example).