Novell is now a part of OpenText

Collector Development Topics

IDENTITIES AND ACCOUNTS

Sentinel Collectors can import referential information into Sentinel SIEM (but not Log Manager, which doesn't support contextual analysis of this kind) about users' Identities and Accounts that are in use within the enterprise, and then leverage that information to provide additional analysis capabilities on top of the standard events. In essence, this allows you to tie activity caused by various user accounts to the actual people that caused that activity.

Importation of Identity and Account Information

There are two methods by which Identity and Account information can be imported into Sentinel:

  • [Sentinel 7 only] REST APIs can be used to load data into Sentinel using an outboard process that converts some native format into Sentinel's REST API format.
  • Collectors can be used to consume data from Identity sources and convert that data into JavaScript classes.

The development of outboard scripts to send data to the REST interfaces is outside the scope of this SDK; see the REST API documentation (available in any Sentinel 7 UI's Help menu) for details.

For Collectors, the general process is to consume some data that describes an Identity, create that Identity, and then attach one or more Account objects to it. Before spending a lot of time writing a Collector for this, you may wish to look for a pre-built Collector on our website for your particular source, or at least one that is similar. You may be able to adapt the code from those Collectors for your needs.

The following API reference information will assist you in creating your own Collector:

When working with these classes, consider the following:

  • The Identity is supposed to map back to a specific actual person, and as a best practice the developer should make efforts to avoid duplicate entries. You can use the Identity.find() method to try to find existing Identities that match one that you are currently processing.
  • The way that Identities are mapped to inbound event data uses matches against the account information included in inbound events, namely fields such as InitiatorUserDomain and InitiatorUserName. Unfortunately, some systems have multiple ways that a single Account is represented in event data — Microsoft for example uses pre-Windows2000 and post-Windows2000 representations in the same event stream — and therefore you may need to construct multiple possible representations of a single Account as separate Account objects to handle these alternate cases.
  • Both Initiator and Target accounts referenced in events will have Identities mapped to them, and multiple related fields filled in by the Mapping Service (see for example the InitiatorUserFullName field). Additional Identity information about accounts referenced in an event can be looked up in the UI interactively

Collector Development Guide

Development Topics

© Copyright Micro Focus or one of its affiliates