How to test OSSEC using a linux dataset containing raw system call traces?

[Miroslav S]

Hello everyone.

I have been tasked to test effectiveness of OSSEC HIDS (by effectiveness I mean detection rate it achieves as well as false positives rate) when a dataset of raw system call traces are used.

The dataset itself is the AFDA-LD dataset which can be found here http://www.cybersecurity.unsw.adfa.edu.au/ADFA%20IDS%20Datasets/

This dataset consists of 3 groups of raw system call traces generated with auditd UNIX program:

1. 1. Normal training data
2. 2. Normal validation data
3. 3. Attack data.

The method used to perform this task is irrelevant as long as I manage to use this particular dataset with OSSEC.

So far I have the latest version of OSSEC installed on Ubuntu 14.04. I suppose that in order to perform my task, OSSEC should first be trained using the normal training data of the dataset and then tested for false positives using the normal validation data and for attack detection using the attack data. I am however quite new when it comes to OSSEC and IDS in general so I could very easily be wrong when it comes to that assumption.

So my question is - Can OSSEC be trained and tested with raw system call traces in the first place, and if yes, how? If not, can the data from this particular dataset be used in any other way in order to test effectiveness of OSSEC?

Thank you

Miroslav

[dan (ddp)]

I don't see anything in the data that would be all that useful to OSSEC.

>
> Thank you
>
> Miroslav
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Santiago Bassett]

Miroslav, could you briefly explain what are the contents of the datasets? OSSEC is a log analysis based HIDS based on signatures (rules). It also has a module to detect malware/rookits that looks for hidden processes, suspicious files, registry keys etc.

[Miroslav S]

Well from what I gathered from the dataset documentation, the contents of these datasets are system call traces. They have been generated on a test system during normal activities of the host which ranged from web browsing to latex document preparation, and there's approximately 800 traces used for training data and approximately 4000 used for validation data, and there's the attack traces too representing 6 different methods of attacks 

However, while reading up the documentation of the dataset just now I came across the following:

 "The ADFA-LD12 is designed for anomaly based systems, not signature recognition IDS"

 And since OSSEC is based on signatures, it looks to me that this dataset is in fact useless for my task. Am I correct in that assumption?

[dan (ddp)]

On Thu, Aug 27, 2015 at 4:44 AM, 'Miroslav S' via ossec-list
<ossec...@googlegroups.com> wrote:
> Well from what I gathered from the dataset documentation, the contents of
> these datasets are system call traces. They have been generated on a test
> system during normal activities of the host which ranged from web browsing
> to latex document preparation, and there's approximately 800 traces used for
> training data and approximately 4000 used for validation data, and there's
> the attack traces too representing 6 different methods of attacks
>
> However, while reading up the documentation of the dataset just now I came
> across the following:
>
> "The ADFA-LD12 is designed for anomaly based systems, not signature
> recognition IDS"
>
> And since OSSEC is based on signatures, it looks to me that this dataset is
> in fact useless for my task. Am I correct in that assumption?
>

OSSEC currently has no facilities to interpret that data.

[Santiago Bassett]

Correct, that dataset won't work in this case.

[Miroslav S]

I was afraid of that. Anyway, thank you both Dan & Santiago for your answers. I now know that my task will be impossible to perform as it's currently defined, so I guess it will have to be redefined.