EventSentry employes a variety of built-in techniques to ensure to protect the EventSentry database from tampering and deletion, however these mechanisms do not protect against malicious by Administrators, especially the EventSentry and database administrators.
To protect against log tampering even from Administrators, additional data protection is available by cryptographically signing event logs exported to text files.
Network Security
The built-in database only needs to be reachable by the local host, as long as the key components (network services, web reports, ...) are installed on the same host and the collector service is utilized by the remote agents. As such, the database does not need to be reachable from any remote host.
Account Security
The built-in database only requires 3 user accounts: The built-in admin accounts ("postgres" or "sa") along with the eventsentry_svc and eventsentry_web users. Neither of the EventSentry users have access to delete or modify data, so data integrity is maintained even any of those accounts get compromised.
Backups
It's possible to backup data and then either encrypt or run a checksum on the actual database. If the database is large, then you could also configure periodic jobs in the web reports that write log (e.g . Syslog) data to a CSV or PDF file, and automatically create checksums using EventSentry's FIM feature.
Encryption
If the EventSentry database runs on Windows (default), then enabling BitLocker on the volume were the actual database is stored can protect the database at rest and provide additional security.
Log Signing
To ensure that event logs or Syslogs have not been tampered with, Windows event logs and Syslog data can be exported to text files (preferably to a remote host) which can then subsequently be signed and timestamped by OpenSSL. Timestamping the signed log files ensures that not even those who are in possession of the private key can re-sign modified logs.
Signing logs works as follows:
1.A "File" action saves all matching event log records (determined by filter in step 3) to text files (multiple formats are supported). Using variables, multiple files can be created based on date and time and other properties. For example, files can be organized in folders and a new file can be saved every minute or hour.
2.This action can store files on a local or a remote volume for additional security or fault tolerance. For highest security, the remote volume should not allow modify/delete access to anyone - especially individuals with access to the private key used for signing the files. WORM-type volumes provide additional security.
3.A new event log filter is created that routes all (or specific) events to this new action.
Once the file(s) are created, a verification script - which utilizes the public key - can verify the following:
•The log file matches the signature
•Verifies and informs when the signature was created
For example, if the log file was created 2 months ago but the associated time stamp is from yesterday, then it essentially means that file has been tampered with.
The diagram below shows the Log Signing components and flow:
