Action Development Guide
Actions can be used to do things like the following:
- Forward selected event data in some format (JSON, CSV, HTML, etc) to a file, to syslog, to SNMP, and so forth.
- Process incident information into a nicely-formatted e-mail.
- React to detected rogue activity by disabling the user's account and notifying their manager.
- Reflect Sentinel correlation output/anomalies/incidents into external ticketing systems.
- Execute arbitrary remote commands to process event data.
- Turn on/off data collection nodes within Sentinel if an error condition is detected.
Since Actions are so flexible, before developing an Action you have to think carefully about how it will be used. An Action can consume three different kinds of input:
- Regular Events
- Correlated Events
- Incident Data
Depending on what task you wish your Action to perform, you should choose which inputs to process. And based on that choice, Sentinel will decide where to present the Action in the user interface. For example, if you write an Action that takes an Incident, formats it nicely, and sends it to the incident response team manager, that Action can't be used to process a selected set of events in a Search — there's no incident data. Sentinel will therefore restrict the Action (or actually any configured instance of that Action) anywhere except where it can get data from an Incident.
Similarly, you will need to decide whether your Action will use one or more Integrators, or if it doesn't need one. If the Action is intended to control Sentinel-domain objects like data collection nodes, it may not need an Integrator; if it needs to connect to a remote SOAP service, it probably does. In some cases an Action might be able to use more than one Integrator, like our Event Forwarder which can format event data into JSON, HTML, or CSV format and then send that format to file, syslog, or SNMP.
Your Action may have other configurable parameters, options that the person configuring the Action plug-in as an Action instance can configure to modify the Action's behavior. The specific output format of the aforementioned Event Forwarder Action is an example here, as is the ability to select a specific provider for sending SMS messages in the Send SMS Action.
After all these decisions are made for the Action plug-in, they will dictate the set of options available to the user when they are configuring the Action as an instance within Sentinel and then attaching that Action to various user interfaces. They will have to choose settings for the configuration parameters (Action Manager), select which Integrator to use, and then they may have to configure the Action to appear in the set of Actions that can be triggered off search data (Event Action Configuration), or attach the Action to a correlation rule. Note however that if the Action is delivered as part of a Solution Pack, it can be delivered with these options pre-configured, which is a convenient way to deliver Actions in some cases.
There are so many possibilities when it comes to what you can do with Actions that it can sometimes be tough to know where to start. Take a look at the existing Actions that we ship with our product, and the corresponding list of Integrators that can be used with those Actions (available on the Sentinel Plug-ins site). Use those as a jumping-off point, but don't let them limit you; the Action framework is almost infinitely flexible.