Protecting On-Premise Audit Trail

Protect On-Premise Challenges for Protecting Audit Trail

Many large organizations prefer to have their audit trail stored within their own infrastructure. Due to their structure and policies they are reluctant to use cloud services.

Using a cloud service has the additional benefit of responsibility segregation – your sysadmins may not have the right to delete logs from the cloud provider infrastructure. Having the audit trail solution on-premise brings additional challenges that we take seriously.

How Does LogSentinel SIEM Protect On-Premise Audit Trail from Tampering?

Our on-premise security guide prescribes limiting the access to the database node only for the ports needed, and from the machines needed (the application nodes). However, someone with access to those nodes can still connect to the database and attempt tampering.

We have to clearly state that even in such cases – a privileged user modifying the data – the attempt will be detected and reported. This is so due to our use of blockchain data structures. But it may not be obvious who was the person that attempted the change. And in some cases this is important. This is why we implemented a Linux PAM that pushes Linux authentication events directly to external services (by instructing LogSentinel to do so). These can include the public Ethereum ledger, a qualified trust service provider, or email.

You can watch a PAM video demonstration of the functionality here:

Privileged Access Management (PAM) Fraud Scenarios And How To Work Around Them

Privileged users can attempt to work around the PAM, by disabling certain network interfaces or attempting a man-in-the-middle attack. Our module detects such attempts and blocks access.

The overall point of a secure audit trail is to not allow data manipulation to be carried out undetected. The most important part is knowing which piece was modified and when, and LogSentinel provides that regardless of whether it’s an on-premise installation or used as a cloud service. But knowing who exactly was the one that did the tampering may also be important, and that’s why we provide that module for our on-premise customers.

Security Use Cases for Detecting That a Security Incident Has Happened and Who Is Responsible

IDFraud ScenarioPrevention mechanisms
1A privileged user logs in via SSH to the LogSentinel database machine to delete dataThe LogSentinel Agent listens to the /var/log/audit/audit.log and /var/log/secure files and sends all events to the audit trail.
LogSentinel supports the option to flag certain log entries as critical and directly push them to external sources as well, which includes: qualified trust service providers, Ethereum, emails of stakeholders. The data pushed is hash(actorId:action), which is meaningless out of context (e.g. hash(254:LOGIN), but can later be used to determine the actual user by attempting to find a hash match for all privileged user IDs.
The uid-to-employee mapping can be stored as an audit trail entry as well as externally.
2Privileged user tries to connect directly to the database via TCP and a Cassandra clientDatabase servers’ firewall is configured to only accept connections from an application server. Both types of servers are protected as per scenario 1 in case the user tries to reconfigure the firewall.
Cassandra logs can also be tracked.
3Privileged user tries to login directly through the Virtual Machine UI (the VMWare admin interface)The same authentication restrictions apply as in SSH access (scenarios 1, 5).
4Privileged user changes the uid-to-employee mappings to make themselves undetectable after the security incidentDistribution of the uid-to-employee mapping can be done in multiple ways, including email, printing, and timestamping externally so that even if it’s modified, the original can be restored.
5Privileged user disables outgoing network connections of the LogSentinel  servers from outside of the servers to prevent them from sending the audit.log details to external sourcesLogSentinel is developing a PAM module that can perform a check if there’s a connection available to a preconfigured list of endpoints (Ethereum, TSA, SMTP server) and proceed to successful authentication only in case of success.
6Privileged user changes the DNS records to point the external services (TSA, Ethereum) to their impostor machine.The PAM module can check the TLS certificates for the endpoints during a TLS handshake and if the other side does not prove to own the certificate, the connection attempt fails, and authentication is rejected.
7The user modifies data in the original data source but doesn’t attempt to modify the audit trailRegular comparisons of the original data against the audit trail can be performed in an automated way to detect discrepancies.
8An attacker steals the credentials of privileged users and tries to SSH into a LogSentinel  machine
The same protections as for the privileged user case apply. Additionally, all LogSentinel  machines have a 2-factor authentication setup.

If you would like to try our SIEM solution today, check out our subscription plans or request a DEMO:

Like this article? Share it with your network!