Windows Event Collector to centralize and filter Windows logs before pickup by OSSEC agent.

[InfoSec]

Has anyone tried to integrate OSSEC with Windows Event Collector (WEC)?

Any insight about potential issues?

[alberto....@wazuh.com]

Hello

  Actually we haven't tried to integrated, but could be a great idea. Could you please describe us how do you think that WEC can help OSSEC?

Very appreciate your feedback, thanks a lot. 

[Jahchan, Georges]

Hello Alberto,

OSSEC Agent blindly sends all the events in the log files it is configured to collect to the OSSEC server where serve configuration determines how events are treated.

Windows is *very* noisy, and lacks granularity when it comes to audit configuration. In my experience, no more than one event in 10 has security value, and is therefore worthy of forwarding and processing, and that number could be as low as one in a thousand. This means that the OSSEC infrastructure has to bear a weight 10 to 1000 times heavier than it should.

WEC can be configured to filter events prior to forwarding using XPath filters. While XPath is not as capable as regular expressions, it nevertheless would allow filtering most of the noise *before* the OSSEC agent picks it up. So the signal to noise ratio of events reaching the OSSEC server becomes 90-95%. With so much less to do, it does it more efficiently. The result is vastly improved scalability.

In my experience, if OSSEC is given too much to do, it crumbles under the load (this is true for any solution). WEC may be the best add-on option in Windows environments to relieve OSSEC from most of the burden of Windows noise. It is from Microsoft, it integrates with AD, and does not require separate licensing (no capital cost). The real cost are the brains and manpower to configure it, deploy it, and maintain it thereafter. The payoff of that effort is a *substantial* boost in OSSEC performance.

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/E8xJJak_KNA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+unsubscribe@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/87d11b5f-bc45-4b47-8153-47c2786b6524%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jesus Linares]

Hi,

you are right, Windows can be very noisy. According to your comments, the great advantage to use WEC is the XPath filters, but right now OSSEC is able to perform that kind of filters:

<localfile>
  <location>System</location>
  <log_format>eventchannel</log_format>
  <query>Event/System[EventID=7040]</query> <!--It is possible to specify an XPATH query following the event schema-->
</localfile>

Maybe we need to improve the query feature if it is not able to perform the same filters that WEC.

Thanks.

Regards.

[Jahchan, Georges]

This is a lifesaver functionality. Is the full syntax well documented anywhere?

The filters to be implemented consist of elaborate sequences of <suppress> commands for specific event IDs. I know which XPath filters I want to implement, and I have tested them in Event Viewer and in NxLog, I was just unable to translate them in OSSEC due to the absence of reference documentation.

I can share examples off-list.

Regards,

George

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/ddccf903-df56-4258-b67c-ac7c3591930a%40googlegroups.com.

[Jesus Linares]

Hi,

there is no documentation. In the code:

result = EvtSubscribe(NULL,
                          NULL,
                          wchannel,
                          wquery,
                          bookmark,
                          channel,
                          (EVT_SUBSCRIBE_CALLBACK)event_channel_callback,
                          flags);

wquery is read from the tag <query>. According to the EvtSubscribe function documentation:

Query [in]
A query that specifies the types of events that you want the subscription service to return. You can specify an XPath 1.0 query or structured XML query. If your XPath contains more than 20 expressions, use a structured XML query. To receive all events, set this parameter to NULL or "*".

Please, test if OSSEC is able to process your filters. If it is not possible, we will study how to do it.

Feel free to share it with us.

Thanks.

Regards.

[MartijnG]

This is a bit of digging up an old post, but i was thinking of this now also and the reason it would be nice if wazuh can accept the WEF logs like NXLog can, then yo wouldnt need an agent on the windows machine to get the logs but you can configure an GPO to forward all logs towasrs the wazuh machine.

Op donderdag 6 april 2017 12:36:13 UTC+2 schreef Alberto Rodriguez:

[Jesus Linares]

Hi MartijnG,

As you said, Windows Event Forwarding (WEF) is an interesting option to forward events from Windows servers to the Wazuh manager. I think this could be an "input" in the Wazuh manager (like rsyslog). Feel free to open a feature request in our repository: https://github.com/wazuh/wazuh.

On the other hand, keep in mind that WEF only works with the Windows Eventlog. It cannot forward events that are not stored in the Windows Eventlog. In that situation, the Wazuh agent is the best approach. Also, don't forget that the agent does more things: file integrity monitoring, detect vulnerabilities, SCA, etc.

Regards.