Protecting On-Premise 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.

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 stated 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 SentinelTrails 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 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 SentinelTrails 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.

 

Sentinel Trails: Security use cases for detecting both that a security incident has happened and who is responsible

ID Fraud Scenario Prevention mechanisms
1 Privileged user logs in via SSH to the Sentinel Trails database machine to delete data The LogSentinel Agent listens to the /var/log/audit/audit.log and /var/log/secure files and sends all events to the audit trail.

Sentinel Trails supports the option to flag certain log entries as critical and directly push them to external sources as well, which includes: qualified trust service provider, 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.

2 Privileged user tries to connect directly to the database via TCP and a Cassandra client Database 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.

3 Privileged user tries to login directly through the Virtual Machine UI (the VMWare admin interface) Same authentication restrictions apply as in SSH access (scenarios 1, 5).
4 Privileged user changes the uid-to-employee mappings to make themselves undetectable after the security incident Distribution 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.
5 Privileged user disables outgoing network connections of the Sentinel Trails servers from outside of the servers to prevent them from sending the audit.log details to external sources LogSentinel 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.
6 Privileged 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.
7 User modifies data in the original data source, but doesn’t attempt to modify the audit trail Regular comparisons of the original data against the audit trail can be performed in an automated way to detect discrepancies.
8 An attacker steals the credentials of a privileged users and tries to SSH into a Sentinel Trails machine The same protections as for the privileged user case apply. Additionally, all Sentinel Trails machines have 2-factor authentication setup.

 


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

SentinelTrals-audit-trail-PAM
All your logs, documents and data – protected by blockchain technology.
Subscription Plans » | See DEMO »