Action Development Guide


Actions are Sentinel's way of acting on some specific event data and doing something with that data. They can be used to process a set of selected events in a search or Active View, they can be attached to a correlation rule to handle the set of raw events that trigger the rule, or they can be executed off an incident with or without attached events related to that incident. In all cases, Actions have full access to the raw data in the set of input events and can manipulate that data at will. The SDK provides a rich JavaScript API, and Actions can also use Integrators to do the low-level protocol work of communicating outside the Sentinel platform. If no Integrator is available, the entire Java environment is available via Rhino so the options are really limitless.

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.

Actions are sort of like Collectors in that they are JavaScript-based; in a sense, they represent the outbound corollary to the inbound Collector. Collectors get data from Connectors and turn it into Sentinel Events; Actions get Sentinel Events and turn them into data an Integrator can do something with. In fact, most of the same JavaScript classes and methods that are available to Actions are also available to Collectors, although the specific functionality will differ based on the context.

Using Actions

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.

Developing Actions

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.

Action Development Guide

© Micro Focus