Overall Design

1) Generation & Collection of Logs

Every environment is a made up of a complex assortment of services and there are many tools, processes, and policies to manage those services. With this level of complexity, a one-size-fits-all design would have been a non-starter. Accordingly, the overriding design goal was to allow as much flexibility as possible in the Generation and Collection of the Autoruns’ logs. This allows the use of whatever tools are used in the environment (SCCM for instance), or just a quick PsExec loop throughout a subnet.

There are only three requirements for the generation and collection process:

1. Logs are generated with the Autoruns’ tab-delimited CSV option
   Eg. autorunsc -ct

2. Logs are generated with the Autoruns option to verify signatures
   Eg. autorunsc -s

3. The generated file is named with the hostname or IP Address of the source system
   Eg. “DD-HR” is the name of the log for the system DD-HR

After generation, the logs need to be copied or moved to the system that is designated as the Collector.

2) Normalization for Security Onion

In order for the data to have any use within Security Onion, it needs to be normalized. Specifically, the following is required:

-Removal of autoruns’ header rows (Unneeded information)
-Addition of unique identifier to each message (For use in OSSEC & ELSA parsers)
-Addition of source hostname to each message (Ties message to source system)
-Addition of runtime to each message (Gives context to when logs were generated)
-Conversion to ASCII (Required for OSSEC)
-Replacement of TAB delimiter with a Pipe delimiter (Required for ELSA Parser, TAB is not supported)

A Powershell script has been written to implement the needed normalization.

3) Importation into Security Onion

Once the data has been normalized, the OSSEC agent on the Collector system will be able to read the data and send it to the OSSEC server of the connected Security Onion Sensor, parsing it and firing applicable rules. From there, Security Onion’s internal processing (Syslog-ng, etc), will make the data accessible and queryable through ELSA.