← Back to Blog Product

SIEM Integration: Compliance Made Easy

13 min read

What Is a SIEM, and Why Should You Care?

Imagine you own a building with 500 rooms, each with its own security camera, door lock, and alarm sensor. Every time someone enters a room, swipes a badge, or triggers an alarm, an event is recorded. Now imagine trying to monitor all 500 rooms by watching 500 separate screens. You would miss things constantly.

A SIEM (Security Information and Event Management) system is like a single control room that collects feeds from every camera, lock, and sensor in your building and displays them on one screen. It correlates events across systems, flags suspicious patterns, and gives you a searchable history of everything that happened. In a computer network, the "cameras" and "locks" are firewalls, authentication systems, databases, servers, and applications. Each one produces log data. A SIEM collects all of it, normalizes it into a common format, and lets security analysts search, alert, and report across the entire organization.

Popular SIEM products include Splunk, Elastic Security (the ELK Stack), Microsoft Sentinel, IBM QRadar, and Sumo Logic. Most large organizations run one of these. And many compliance frameworks expect security-relevant events to be logged, protected from tampering and reviewed, often in a central system. That is where QNSQY's SIEM integration comes in.

The Encryption Blind Spot

Most organizations already feed their firewall logs, authentication events, and endpoint detection data into their SIEM. But encryption tools have historically been a blind spot. When someone uses GPG to encrypt a file, there is no log entry anywhere. When someone decrypts a file with Age, no event is recorded. The SIEM has no visibility into what is arguably the most security-critical operation: who is accessing protected data, when, and with what tools.

This creates a serious gap in incident response. If a security breach occurs and investigators need to determine whether a specific file was accessed before or after the intrusion, they have no records to check. If an employee is suspected of data exfiltration, there is no log showing which encrypted files they decrypted. The cryptography tool has effectively created a black hole in the organization's security monitoring.

Why Encryption Audit Logs Matter

Encryption tools traditionally operate in silence. You encrypt a file, you decrypt a file, and nothing is recorded. For personal use, this is fine. For an organization subject to compliance requirements, it is a serious gap.

Consider the questions that auditors routinely ask:

Who encrypted this patient record, and when?
Has anyone attempted to decrypt this file without authorization? How many times?
Was this file encrypted with an approved algorithm, or did someone use a weaker setting?
Is there an unbroken chain of custody from the moment the file was created to now?
When the encryption key was rotated, who authorized it?
Can you prove that these logs have not been modified after the fact?

Without audit logging, the answer to every one of these questions is "we do not know." QNSQY's audit log answers who did what, and when, with a tamper-evident record. It does not record which algorithm was used; on Business, an organization policy controls that instead.

How QNSQY Generates Audit Events

QNSQY writes an audit event for each operation automatically; there is nothing to enable or configure. The log is written on every plan. Viewing it, exporting it and verifying it need Pro or Business.

The events, by the name they carry in exports:

Event	Recorded when
EncryptStart, EncryptComplete, EncryptFailed	Encrypting data
DecryptStart, DecryptComplete, DecryptFailed	Decrypting data
WrongPassword, RateLimited	A wrong password, and repeated wrong passwords being slowed down
Sign, Verify, VerifyFailed	Creating and checking signatures
KeyGen, KeyImport, KeyExport	Generating, importing and exporting keys
Shred	Secure deletion
Rekey	Changing a file's password
BatchEncrypt, BatchDecrypt	Batch runs (the details show how many files succeeded, for example 3/3)
SecretSplit, SecretCombine	Splitting a secret into M-of-N shares and recombining it
CryptoScan, CryptoMigrate	Scanning for classical cryptography and migrating files
VaultCreated, VaultAccess, VaultModify, VaultRekey	Password vault activity
EscrowKeygen, EscrowRecover, EmergencyDecrypt	Organization key escrow and break-glass decryption
Remote push, pull, sync and test events	Remote backup activity, including failures
AppStart, AppShutdown, LogRotation	Program start and stop, and log rotation markers

Every entry holds a sequence number, the date and time, the event, the operating-system user name (or numeric user ID) and, for operations on a file, a BLAKE3 hash of the file's path. Some events add short details, such as 3/3 for a batch. The log never records file names, file contents, passwords, keys or the algorithm used. That keeps sensitive file names out of the log, but it also means that to tie an entry to a file, you compare the path hash with the hash of the path you are asking about.

The Tamper-Evident Hash Chain

Recording events is only useful if you can show the records have not been altered. If an attacker can decrypt a file and then delete the log entry, the audit trail is worthless.

QNSQY's audit log is hash-chained, like a blockchain in miniature: each entry carries a BLAKE3 hash of the entry before it. If anyone changes, deletes or reorders an entry inside the log, the next entry's hash no longer matches and the chain breaks. The entries are also encrypted with a key derived from the machine. qnsqy audit --verify checks the chain:

qnsqy audit --verify
Verifying audit log integrity...
Audit log integrity verified.

If the chain is broken, QNSQY names the sequence number of the first entry that does not match. Two honest limits: someone with full control of the machine can still delete the whole log, and timestamps come from the system clock. That is why exports should also go to a separate system, such as your SIEM. On Business, the audit chain also carries ML-DSA signatures.

Export Formats

QNSQY exports its audit log in four formats: CEF, JSON and Syslog for SIEM products, and CSV. Choose the format with --format; the default is CSV, whatever the file name:

qnsqy audit --export audit.cef --format cef
qnsqy audit --export audit.json --format json
qnsqy audit --export audit.log --format syslog
qnsqy audit --export audit.csv

--security-only limits an export to security events (wrong passwords, rate limiting, failed signature checks, escrow recovery, break-glass decryption, log rotation and failed remote-backup operations), and --after limits it to a date range.

CEF (Common Event Format)

CEF is a log format created by ArcSight and accepted by Splunk, QRadar, Microsoft Sentinel and most other enterprise SIEMs. One QNSQY line looks like this:

CEF:0|QNSQY|qnsqy|7.0|EncryptComplete|Encryption completed|3|seq=3570 ts=1792124457 user=jsmith fileHash=<64 hex characters> cs1Label=Details cs1=

The severity field is 7 for failed decryptions, wrong passwords and rate limiting, 5 for failed encryptions and failed remote-backup operations, and 3 for everything else. ts is a Unix timestamp.

JSON

JSON suits custom integrations and Elastic pipelines. The export is one JSON array with one entry per line:

[
  {"sequence":3570,"timestamp":"2026-10-16T04:20:57+00:00","action":"EncryptComplete","user_id":"jsmith","details":null},
  {"sequence":3571,"timestamp":"2026-10-16T04:20:57+00:00","action":"AppShutdown","user_id":"jsmith","details":null}
]

The JSON export carries neither the file hash nor the chain hashes. Use CEF or CSV when you need the file hash, and keep the original log so that qnsqy audit --verify can prove its integrity.

Syslog (RFC 5424)

Syslog is the standard Unix logging format and works with rsyslog, syslog-ng and Filebeat. QNSQY writes RFC 5424 lines with the details in structured data:

<134>1 2026-10-16T04:20:57+00:00 qnsqy - - [qnsqy@0 action="EncryptComplete" seq="3570" user="jsmith"]

Integration Examples

QNSQY writes export files; it does not send events over the network itself. You move the files with the tools you already use, on a schedule such as a cron job or a systemd timer.

Splunk

Export to JSON (or CEF) and ingest the file the way you ingest other files, for example with a Universal Forwarder watching the export folder:

# Export audit logs to a folder the forwarder watches
qnsqy audit --export /var/log/qnsqy/audit.json --format json

Once the data is in Splunk, you can chart operations per day, failed decryptions and wrong passwords, and set alerts, for example for more than 10 wrong passwords in 5 minutes from the same user.

Elastic / ELK Stack (via Filebeat)

Filebeat reads one JSON object per line, so turn the exported array into that form first (here with jq), then point a filestream input at the folder:

# Export, then write one JSON object per line
qnsqy audit --export /tmp/qnsqy-audit.json --format json
jq -c '.[]' /tmp/qnsqy-audit.json > /var/log/qnsqy/audit.ndjson

# filebeat.yml
# filebeat.inputs:
#   - type: filestream
#     id: qnsqy-audit
#     paths: ["/var/log/qnsqy/*.ndjson"]
#     parsers:
#       - ndjson:
#           target: ""

In Kibana you can then chart operations by user, event type and time.

Microsoft Sentinel

Sentinel ingests CEF through a Linux log forwarder that runs the Azure Monitor Agent (the "Common Event Format via AMA" connector). Export in CEF and pass the lines to the forwarder through your syslog setup, for example rsyslog. Sentinel can then correlate QNSQY events with Microsoft Entra ID sign-ins and other sources.

Simple File Export

Without a SIEM, you can still view and export the log locally, for example for an external auditor:

# View audit events in the terminal
qnsqy audit

# Export the full log as JSON
qnsqy audit --export /var/log/qnsqy/audit.json --format json

Compliance Framework Mapping

Different compliance frameworks have specific requirements around logging and audit trails. Here is how QNSQY's audit log relates to the major ones:

Framework	Requirement	How QNSQY supports it
HIPAA	45 CFR 164.312(b): implement hardware, software and/or procedural mechanisms that record and examine activity in systems that contain or use ePHI.	Each encrypt and decrypt is logged with the user, time, event and a hash of the file path; failures are separate events. The hash chain makes changes to the log detectable.
SOC 2 (Trust Services Criteria)	CC6.1: logical and physical access controls. CC7.2: system monitoring.	The log records every encryption-related access by QNSQY. Failed decryptions and wrong passwords are recorded as their own events, and the exports feed central monitoring.
PCI DSS v4.0	Requirement 10.2: audit logs capture user activity; 10.2.2 lists the details for each event (user, type of event, date and time, success or failure, origin, affected data or resource).	Each QNSQY event carries the user, event type, date and time, and success or failure (as separate events). It records no host name, so add the host when you forward events, and keep a mapping from path hashes to files if you must name the affected data.
GDPR	Article 32: appropriate technical and organizational measures to ensure security appropriate to the risk. Article 5(2): accountability principle.	Encryption of personal data at rest, and a tamper-evident record of operations on encrypted files, support accountability.
SOX (Sarbanes-Oxley)	Section 404: internal controls over financial reporting, including an audit trail of access to financial records.	A log of encryption and decryption operations on financial documents; chain verification shows the log was not altered.
NIST Cybersecurity Framework 2.0	PR.PS-04: log records are generated and made available for continuous monitoring. DE.CM-03: personnel activity and technology usage are monitored.	Audit logging with exports for continuous monitoring, hash-chain verification, and the user on every event.

To be explicit about scope: QNSQY's audit logging is a technical control that supports your compliance program. QNSQY itself is not HIPAA-audited, SOC 2-certified, PCI-DSS-assessed, FedRAMP-authorized, or FIPS 140-validated, and using it does not by itself make your organization compliant with any of these frameworks.

What an Auditor Sees

An external auditor typically asks for a sample of your audit logs and checks that the logs exist, that they contain the required fields, that they have not been tampered with, and that they cover the relevant period. With QNSQY:

The auditor requests encryption activity logs for a quarter. You export that period (for example with --after) and hand over the file.
The auditor checks the fields. Every entry has the date and time, the user and the event, and file operations carry a hash of the file path; success and failure are separate events. QNSQY does not record a host name or the file name, so add the host when you forward events and keep a mapping from path hashes to files if the auditor needs names.
The auditor checks integrity. You run qnsqy audit --verify and it reports "Audit log integrity verified.", which shows the log has not been altered since it was written.
The auditor looks for anomalies, such as DecryptFailed and WrongPassword events. A cluster of them is either a user who forgot a password or someone trying to get in, and is worth a question.

Building Useful SIEM Dashboards

Once QNSQY events are in your SIEM, these views are useful:

Daily operations. EncryptComplete and DecryptComplete events per day. A sudden spike can mean a batch migration or data being pulled out; a sudden drop can mean people have stopped encrypting.
Failures by user and time. DecryptFailed, WrongPassword and RateLimited events. A cluster from one user is usually a forgotten password; failures from many users can mean a file is circulating to people who should not open it.
Top users by operation count. Outliers deserve a look: thousands of operations a day may be an unapproved script, and none at all may mean data protection steps are being skipped.
Shred tracking. Compare Shred events with EncryptComplete events. A low ratio can mean plaintext copies are being left on disk.

The audit log does not record which algorithm was used. To control algorithms, use an organization policy on Business, which can require a key-exchange algorithm or restrict the allowed ones.

Alerting Rules Worth Configuring

Password guessing: more than 5 WrongPassword events from the same user within 10 minutes, or any RateLimited event. QNSQY slows down repeated wrong passwords itself; the alert gives you visibility.
After-hours decryption: DecryptComplete events outside business hours (for example 11 PM to 6 AM) from users or hosts that are not on an approved list.
Failed signature checks: any VerifyFailed event, which can mean a file was altered or signed with the wrong key.
Break-glass and escrow use: any EmergencyDecrypt or EscrowRecover event, which should always have a ticket behind it.
Chain integrity failure: if a scheduled qnsqy audit --verify reports a broken chain, alert the security team at once: the log was damaged or tampered with.

Best Practices for SIEM Integration

Export regularly. Use a cron job or systemd timer to export every hour or every day. Do not wait until an auditor asks.
Store exports on a separate system. If the machine running QNSQY is compromised, the attacker should not be able to reach the SIEM or the exported files.
Alert on failures. Bursts of WrongPassword or DecryptFailed events can mean someone is guessing passwords.
Verify the chain periodically. Run qnsqy audit --verify as part of your regular checks, and investigate any break at once.
Retain logs as your rules require. For example, PCI DSS 4.0 asks for at least 12 months of audit logs with the last three months immediately available, and HIPAA requires its security documentation to be kept for 6 years. Set your SIEM retention accordingly.
Include QNSQY logs in incident response. The audit trail can show whether a file was decrypted before or after a breach, by which user, and whether anyone tried and failed.

Sources

Business-Grade Compliance

The hash-chained audit log is written on every plan; viewing it, exporting it and the SIEM formats need a paid plan.

Contact Sales

Originally published at quantumsequrity.com/blog/siem-integration.