Collector Development Guide
COMMON CODE AND RESOURCES
Even with the diversity of event sources in the world, and the relative lack of standards in the area of audit event formats, nevertheless as you work on Collectors you will find that there are many commonalities across source types. A lot of sources use syslog, for example, which although it does not impose any standardization on the event record content, does provide a reasonably consistent header. The point is, over the years we have developed a library of re-usable resources — including code snippets, map files, and similar — that developers can optionally choose to include in their Collectors if they happen to be working on integration with a source uses the same semantics.
Including these common resources is very simple — simply list the file in the files.include
file that is part of every Collector
as part of the template. You can review the set of files that are available in the //current/sdk/common/Collector/src
directory; open
each file to see what it does. Any files you wish you use you just list on a single line, comma-separated, in files.include
.
Using Common Maps
To use common map files, you will need to add a line to your Collector to load the map (the common map file is copied into the plug-in just like any
other file). For example, the Check Point Collectors all use the same mappings for severity, and hence they include the map file cp-severity.map.
.
To load that map file, you must specify something like this in Collector.prototype.initialize()
:
this.MAPS.SevMap = new KeyMap(this.CONFIG.collDir + "cp-severity.map");
Then to use the map of course you would use a line like instance.MAPS.SevMap.lookup(key)
.
Using Common Code
For JavaScript files included from the common area, you don't need to do anything special to get the code loaded - the infrastructure will handle that. But to actually use the code, you will likely have to review what the structure and function of the provided methods are. In general, the common code includes the following types of methods:
- Initialization routines
- You may need to add a line or two to your
Collector.prototype.initialize()
method to set things up correctly. - Full parsing replacement methods
- In some cases, such as Novell Audit's
parseAudit()
method or the RadwareparseRadware()
method, the intent is to almost completely take over the parsing logic for the Collector. Essentially you would have your Collector'sparse()
method just make a call to this replacement method, and leave it at that. - Modular parsing
- Some codesets, such as
unix-common.js
, are built around the assumption that there's usually an "event key" of some kind that can be used to partition the set of possible input events into manageable chunks. Usually the regular Collector code will do a little work to extract that key (forunix-commons.js
, the key is simply the AppID from syslog), and then will call a method that knows how to handle events with that particular key (i.e. that particular application) which will be provided either by the local Collector code or this common code.
If you run into issues using the common code you may need to go through a debugging session to work out how the code is supposed to be used. Feel free to post to the Forum if you have questions, or would like to suggest other useful source libraries.
- Forward to Parameters
- Back up to Develop to Sentinel
Collector Development Guide
- Overview
- Getting Started
- Initial Build
- Plug-in Contents
- Data Parsing
- Build Process
- Event Construction
- Taxonomy
- Connector Interaction
- Common Code
- Parameters
- Additional Information