Guardium can distribute alert messages 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 Guardium 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 from the Administration Console. See Manage Custom Classes.
For guidelines on testing a custom alerting class, see .
The custom alerting class must be in the com.guardium.custom package and must implement the com.guardium.custom.CustomerDefinedAlertingIfc interface:
package com.guardium.custom
public class YourClassNameHere implements CustomerDefinedAlertingIfc {
}
The interface contains the five methods described below.
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. |
Description |
Return the alert message. |
Syntax |
public String getMessage () |
Returns |
A String containing the alert message. |
Description |
Return the timestamp associated with the alert message. |
Syntax |
public Date getTimeStamp () |
Returns |
A java.util.Date for the time the alert message was created. |
Description |
Set the alert message. |
Syntax |
public void setMessage (String inMessage) |
Parameter |
A String containing the alert message. |
Description |
Set the timestamp associated with the alert message. |
Syntax |
public void setTimeStamp (Date inDate) |
Parameter |
A java.util.Date for the time the alert message was created. |
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;
}
}
After compiling a custom alerting class, follow the procedure outlined below to test it.
Upload the custom class to the Guardium 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 Guardium 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).