OSSEC FIM Registry - wrong CEF output

[mkvocka]

Hi,

OSSEC v2.9.0 syscheck-registry monitoring, when using CEF as syslog output, uses the field "cs2" for multiple values. In my case:
cs2=(hostname) IP->syscheck-registry
and later in the same log:
cs2='new hash'

[ddpbsd]

What fields should those items be in? (I don't use CEF)

[mkvocka]

CEF is a format developed by ArcSight for their SIEM. Each SIEM system has a schema (fields) for events, but no schema can fit all possible fields from logs. For this reason CEF format has a mechanism called custom fields. They always come in pairs, one for value and one for label (meaning).

In this case, cs stands for custom string. So when cs2="123" cs2Label="Hash" is parsed, a new field "Hash" with value "123" is created.

The main bug is that the field indexes (numbers) should be distinct, otherwise the cs2 field gets overwritten.

---

Example

For events 550 (file integrity), the following cs fields are present:

cs2=(hostname) IP->syscheck cs2Label=Location classification

No other cs fields are used. There is a slight bug - indexes should start from 1 (cs1), not cs2.

For events 594 (registry integrity), the following cs fields are present:

cs2=(hostname) IP->syscheck-registry cs2Label=Location classification
cs1Label=OldMD5 cs1='old hash'
cs2Label=NewMDG cs2='new hash' (yes there is a typo in 2.9.0, G->5)

Any CEF parser will loose the hostname, because it will overwrite cs2 with the latest occurence (new hash).

---

The CEF format should be consistent between log types, f.e.:

• cs1 for hostname (address and process information should not be here, there are other fields for that)
• dst/dsthost or src/srchost for agent IP/hostname
• cs2 for old hash
• cs3 for new hash
  and so on.

Is this clear?

[ddpbsd]

Thank you so much for the detailed explanation! It looks like the fix is simple (for some value of simple):

cs1 = location
cs2 = old md5
cs3 = new md5
cs4 = src city
cs5 = dst city

This may interfere with some already running systems, but seems like the best solution going forward. Pull request #1143 has the fix. I will backport this to the 2.9.1 branch as well.

[atomicturtle]

Is this sorted out now in 2.9.1?