The Snare Central can process a reasonably wide range of source data types. The Snare Central data acquisition software is generally tuned for particular versions of operating system or device logs, so if you encounter problems importing particular types of data, please contact your Snare Central support team, and be prepared to supply (sanitised if required) log samples.

...

Organisations that use the Snort network intrusion detection system can send data to the Snare Central via the syslog protocol. Snare will be able to collect, interpret, and report on the events. The following information provides an overview of the steps required to configure the Snort sensor to send eventlog data back to the Snare Central. Note that there is no configuration required on the Snare Central.

...

• Look in /var/log/messages for errors.
• Run manually:
  • /usr/sbin/snort -D -i "ppp0" -c /etc/snort/snort.conf
• ..then look in /var/log/messages for errors

Collecting ACF2 Data

The Snare Central is able to collect ACF2 processed reports, via FTP transfer. The processed reports need to be transferred to a particular directory on the Snare Central, which will then be uploaded by Snare Central processes, on a daily basis.

The ACF2 processed reports are based on specific utilities, provided with the ACF2. The utilities produce formatted reports on the following activity on a mainframe, which can then be collected by the Snare Central, and used for reporting:

...

The end of this chapter contains a listing of an example JCL which could be used to run, extract and send the ACF2 processed reports to the Snare Central. This sample job has been set up for the Logonid Modification Log report, but could easily be configured for all the reports listed above. Each step in the sample job below performs the following steps. Note that a fixed transfer library name is used because a reference to this library is stored in an FTP parm library which cannot be changed with each run. Some of the programs used in this job are defined below.

• Deletes previous day's FTP transfer library.
• Runs ACF2 report, placing output in a GDG (7 generations kept).
• Allocate new FTP transfer library and copy report from GDG created in previous step.
• FTP the transfer library to Snare Central. The 'snarexfer' FTP user must be used. This user defaults to the "/data/SnareCollect" directory on the Snare Central. The ACF2 processed reports must be placed in the "ACF2Log" sub-directory. So the full path becomes: "/data/SnareCollect/ACF2Log". Member level security is used to protect the FTP lid password.

The IEBGENER program used in the sample job is an IBM-supplied utility program designed to generate copies of data sets when disk storage or tape is involved. The IKJEFT01 program is the TSO/E program, and is used to perform a TSO function within a batch job.

********************************** Top of Data **********************************
//CSCSNR01 JOB (P,SCF81),ACT.SECURITY,CLASS=C,MSGCLASS=J
/*JOBPARM SYSAFF=PROD
//-----------------------------------------------------------------
//*
//* JOB TO PRODUCE ACF2 LIDMOD REPORT FOR XFER TO SNARE SERVER
//*
//*---------- DELETE TEMP XFER LIB ---------------------------------
//*
//STEP1 EXEC PGM=IKJEFT01,REGION=8192K
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD *
DELETE 'CSC.SNARE01.LIDMODS.XFER'
//*
//*---------- ACF2 LID DB MODIFICATION LOG REPORT ------------------
//*
//STEP2 EXEC PGM=ACFRPTLL
//SYSPRINT DD DSN=CSC.SNARE01.LIDMODS.REPORT(+1),
//
DISP=(,CATLG),
//
VOL=SER=BTCH52,
//
UNIT=SYSDA,
//
SPACE=(TRK,(60,5),RLSE),
//
DCB=(GDGMODEL,RECFM=FB,LRECL=142,BLKSIZE=27974)
//SYSUDUMP DD SYSOUT=*
//REC01 DD DSN=CTF.SMFJR,DISP=SHR
//SYSIN DD *
MASK(********)
DETAIL
NOUPDATE
SYSID(****)
//*
//*---------- COPY REPORT FROM GDG TO XFER LIB ---------------------
//*
//COPY
EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1
DD DSN=CSC.SNARE01.LIDMODS.REPORT(+1),
DISP=SHR
//SYSUT2
DD DSN=CSC.SNARE01.LIDMODS.XFER,
//
DISP=(NEW,CATLG,DELETE),
//
VOL=SER=BTCH52,
//
UNIT=SYSDA,
//
SPACE=(TRK,(60,5),RLSE),
//
DCB=*.SYSUT1
//*
DCB=(RECFM=FB,LRECL=142,BLKSIZE=27974)
//SYSIN
DD DUMMY
//*
//*---------- FTP XFER FILE TO SNARE SERVER ------------------------
//*
//STEP4 EXEC FTP,
//
SERVER='CSCSNARE',
//
FTPUSER='SNAREXFER',
//
FTPCMDS='CSCSNR01',
//
ENV='PROD',
//
SOUT='*'
//*
//*---------- Notify Security Monitoring Team if job fails ---------
//*
//*JOBFAIL IF ((RC > 4) | (ABEND)) THEN
//*
//SENDMEMO EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
HELO NCC
MAIL FROM:<PSC0SCHD@AGENCY.COM>
RCPT TO:<ITSECMON@AGENCY.COM>
DATA
TO:ITSECMON<ITSECMON@AGENCY.COM>
SUBJECT:SNARE REPORT FTP JOB FAILURE: JOB CSCSNR01
PLEASE CHECK SDSF OUTPUT FOR THIS JOB ASAP AND DETERMINE WHY.
>> THIS E-MAIL IS GENERATED BY A BATCH JOB RUNNING ON THE
>> AGENCY'S MAINFRAME ENVIRONMENT.
.
QUIT
/*
//SYSUT2 DD SYSOUT=(B,SMTP)
//SYSIN DD DUMMY
//*
//JOBFAIL ENDIF
//*===================================================================

...

RACF resource violation logs can be batch-imported to the Snare Central. In particular, ACCESS, DELRES, and JOBINIT logs are supported directly, .

...

...

Sidewinder firewall logs can be exported to CSV, and transferred to the Snare Central for processing.

The Snare Central, will utilise the following fields:

...

IIS logs should retain the header information, that includes the 'Fields' definition line.

The Snare Central requires the following fields to be included:

...

In situations where systems are air-gapped, or have sporadic internet connectivity, directly transferring the archived log data to the Snare Central via FTP is possible.

...

• String order may not match the order found in normal Snare agent logs.
  • Some existing Snare Central objectives may require strings to be in a particular order, to pull out information of particular interest, from the 'Strings' section of events, such as as user name.
• String names may not match those found in normal Snare agent logs.
  • The string "SubjectUserSid" in the EVTX file, is actually translated to "Subject: Security ID:" in many events.
  • The string "SubjectUserName" in the EVTX file may be "User Name" in some circumstances, or "Account Name" in others. There is no obvious consistency , and there does not seem to be a generally available lookup-table to hint at what translations are appropriate.
  • The Snare Central will attempt to convert the 'CamelCase' string headers to space-included versions, which are more likely to match those displayed by the Windows event viewer (and therefore transmitted by Snare), however, case may be incorrect in some circumstances:
    • SubjectUserId may be translated as "Subject User Id", whereas the Windows event view will display it as "Subject User ID".
    • There are a few 'special cases' defined in the EVTX converter, that may fix the more obvious examples.
• The contents of the 'Data' field is not currently supported for conversion.
• Content that is usually interpreted at display-time in the Windows event viewer, or at transmission time in the Snare agents, will not be interpreted.
  • At event display-time, the Windows event viewer interrogates the registry, and sometimes native or third party DLL's, to try and resolve event template components to human readable text. The Snare for Windows agent does the same, when it converts the events to text-format prior to transmission.
  • These DLL's/registry entries are not guaranteed to be installed on all windows machines - for example, Internet Information Server template conversion DLL's will not be installed on a server that is not running IIS.
  • As such, information that is available to a Snare Agent on the source system, is NOT available to the Snare Central when it attempts to convert the binary EVTX log data to text format.
  • Human-readable event descriptions that are often included within the strings section, will not be available.
• Date/Time values within the EVTX files are in UTC format, and the EVTX files do not contain UTC offset information for the source server.
• In general, the conversion tool may require assistance in determining the source of the source EVTX file (eg: Security, Application, System, etc).
  • The two points above, can be addressed with the assistance of file path hints.
  • Logs should be included in one of the following file paths, depending on the log type/source:
    • /data/SnareCollect/MSWinEVTX/Security
    • /data/SnareCollect/MSWinEVTX/Application
    • /data/SnareCollect/MSWinEVTX/System
  • Under these directories, if time zone conversion is required (highly recommended), a directory should be created with the textual representation of the time-zone (but with the forward-slash character switched out for a COLON)
    • For example:
      
      • /data/SnareCollect/MSWinEVTX/Security/America:New_York
      • /data/SnareCollect/MSWinEVTX/Security/Australia:Adelaide

...