Sending audit events from an application to a SIEM should be a pretty standard practice nowadays. However, in practice – it seems – still not clear how to actually do this properly.The first obstacle, how the app itself supports this. The majority of applications not even have audit feature, so we (as the SOC Team) are focusing on the remaining few :)
Even from those few, most of them are just dumping their audit events to a simple file on the local filesystem, and pushing the responsibility – to do something with them – to the server admins. This is a solid indication that the app developers are not really care about security in general :( We can still handle those ‘abandoned’ files, but that’s another story…
HashiCorp Vault is one of the very few applications that actually designed for security. So it is not just create audit logs, but a successfully generated audit event is a mandatory step in their security model:
Access to data or controls without accountability. If audit logging is enabled, requests and responses must be logged before the client receives any secret material.
And we can configure multiple audit devices, including syslog – yee-haw!
However:
It currently does not support a configurable syslog destination, and always sends to the local agent.
And – obviously – this feature is available only on Unix/Linux based servers. But, who on earth would put all their secrets to a windows server, right?! ;)
So the first step is to enable the syslog audit device, by:
# vault audit enable syslog tag="vault" facility="AUTH"
Where the tag and the facility are very important, as we will use those later as a syslog filter.
Keep in mind, that in a modern Linix distribution, this will direct these events to the system journal – at least this is a default behaviour on a Centos/RedHat 9 (and above)
What will happen to those events, is competely depends on your syslog agent configuration from this point . As most of the modern distributions are shipping rsyslog as a syslog agent by default, here is two example config file what you might want to place under /etc/rsyslog.d folder to be utilised by rsyslogd
/etc/rsyslog.d/Vault.conf:
ruleset( name="filter_Vault" )
{
if ( $programname == 'vault' and $syslogfacility-text == 'auth')
then
{
call QRadar
}
}
call filter_Vault
This will create the filter based on the parameters you provided to the Vault server before.
As you might notice, this will call the function named: QRadar, which is defined in the next file:
/etc/rsyslog.d/QRadar.conf:
ruleset( name="QRadar" )
{
action( type="omfwd"
target = "qradar.security.lab"
port = "6514"
protocol= "tcp"
KeepAlive= "on"
Template="RSYSLOG_SyslogProtocol23Format"
# and queue to disk if needs be
queue.spoolDirectory="/var/lib/rsyslog"
queue.filename="tls_fwd"
queue.type="LinkedList"
queue.saveonshutdown="on"
queue.maxdiskspace="1g"
action.resumeretrycount="-1"
action.reportsuspension="on"
StreamDriver="ossl"
StreamDriverMode="1"
StreamDriverAuthMode="anon"
)
}
Where the later can be familiar from my previous articles…
This example using the OpenSSL backend, and initiating an anonymous TLS connection to the target SIEM – You might need to adjust those, depending on your SIEM settings.
I used QRadar as a SIEM in this example, however nothing is really QRadar specific, you can use any other SIEM that capable of receiving events via syslog.
As I’m currently working for IBM, please read my disclaimer.