← 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 most compliance frameworks require that security-relevant events are collected in a centralized, tamper-evident logging 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." With QNSQY's audit system, the answer is "yes, here is the timestamped, tamper-evident record."

How QNSQY Generates Audit Events

Every operation QNSQY performs that touches cryptographic material generates an audit event. This happens automatically; the user does not need to enable it or configure anything. On the Pro and Business tiers, these events are stored in a local audit log that can be viewed, exported, and verified.

The following operations generate audit events:

Event Type	What Triggers It	Details Captured
FILE_ENCRYPTED	Any data encryption operation	Filename, file size, KEM algorithm, AEAD cipher, username, hostname, timestamp, outcome (success/failure)
FILE_DECRYPTED	Any file decryption operation	Filename, username, timestamp, signature verification result, outcome
DECRYPT_FAILED	Wrong password, corrupted file, tampered header	Filename, failure reason (wrong password, integrity check failed, unsupported algorithm), username, timestamp
FILE_SIGNED	Digital signature creation	Filename, DSA algorithm, key identifier, username, timestamp
SIGNATURE_VERIFIED	Signature verification (pass or fail)	Filename, DSA algorithm, verification result, username, timestamp
KEY_GENERATED	Key pair generation (signing or encryption)	Key type (signing/encryption), algorithm, key label, username, timestamp
FILE_SHREDDED	Secure file deletion	Filename, number of overwrite passes, username, timestamp
KEY_ROTATED	Password change via rekey command	Filename, old algorithm, new algorithm, username, timestamp
CONFIG_CHANGED	Any configuration or policy change	Setting name, old value, new value, username, timestamp

The Tamper-Evident Hash Chain

Recording events is only useful if you can prove 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 uses a hash chain, which works like a blockchain in miniature. Each log entry includes a BLAKE3 cryptographic hash of the previous entry. This creates a chain where every entry depends on every entry that came before it. If anyone modifies, deletes, or reorders a single entry, the hash of the next entry will not match, and the chain breaks. The qnsqy audit verify command checks every link in the chain and reports whether the log is intact.

Think of it like a stack of sealed envelopes. Each envelope contains a summary of the previous envelope. If someone opens an envelope in the middle and changes its contents, the summary in the next envelope will not match, and you will know it was tampered with.

# Verify the integrity of your audit log
qnsqy audit verify
Audit log chain verified: 1,247 entries, no tampering detected

If the chain is broken, QNSQY reports exactly which entry is the first inconsistency, so you can investigate what happened.

Export Formats

QNSQY supports three export formats, covering virtually every SIEM product on the market.

CEF (Common Event Format)

CEF is an industry-standard log format developed by ArcSight (now part of Micro Focus/OpenText). It is supported by Splunk, QRadar, Sentinel, and most other enterprise SIEMs out of the box. CEF uses a pipe-delimited header followed by key-value extension pairs:

CEF:0|QNSQY|Encryption|7.0|100|File Encrypted|3|
  src=workstation01 dst=secret.pdf
  outcome=Success cs1=ML-KEM-1024 cs1Label=Algorithm

The severity field (3 in this example) maps to the CEF severity scale: 0-3 for informational events (successful operations), 4-6 for warnings (configuration changes), and 7-10 for high-severity events (decryption failures, potential tampering).

JSON

JSON is the most flexible format and the best choice for custom integrations, Elastic/ELK pipelines, and cloud-native SIEM services. Each event is a self-contained JSON object:

{
  "timestamp": "2026-01-11T10:30:45Z",
  "event": "FILE_ENCRYPTED",
  "source": "workstation01",
  "file": "secret.pdf",
  "algorithm": "ML-KEM-1024",
  "aead": "AES-256-GCM",
  "user": "jsmith",
  "outcome": "SUCCESS",
  "file_size_bytes": 2048576,
  "chain_hash": "b3a1f9c2d4e5..."
}

The chain_hash field in each JSON event is the BLAKE3 hash linking it to the previous entry, preserving the tamper-evident property even after export.

Syslog (RFC 5424)

Syslog is the standard Unix logging protocol, supported by every Linux/macOS system and every SIEM. It is the simplest format and works well with traditional log forwarding tools like rsyslog, syslog-ng, and Filebeat:

<134>Jan 11 10:30:45 workstation01 qnsqy[1234]:
  ENCRYPT success user=jsmith file=secret.pdf algo=ML-KEM-1024

Integration Examples

Splunk (via HTTP Event Collector)

Splunk's HTTP Event Collector (HEC) accepts JSON data over HTTPS. Export your QNSQY audit log to JSON, then forward it to Splunk. You can automate this with a cron job or a systemd timer to run every hour or every day:

# Export audit logs to JSON
qnsqy audit --export audit.json

# Forward to Splunk HEC
curl -X POST https://splunk.company.com:8088/services/collector \
  -H "Authorization: Splunk YOUR_HEC_TOKEN" \
  -d @audit.json

Once the data is in Splunk, you can build dashboards showing encryption operations per day, failed decryption attempts, algorithm usage distribution, and more. Set up alerts for anomalies like "more than 10 failed decryption attempts in 5 minutes from the same user" to catch potential brute-force attacks.

Elastic / ELK Stack (via Filebeat)

The Elastic Stack (Elasticsearch, Logstash, Kibana) can ingest QNSQY logs through Filebeat. Export to JSON and configure Filebeat to watch the export directory:

# Export audit logs to a monitored directory
qnsqy audit --export /var/log/qnsqy/audit.json

# Filebeat configuration (filebeat.yml):
# filebeat.inputs:
#   - type: log
#     paths: ["/var/log/qnsqy/*.json"]
#     json.keys_under_root: true

In Kibana, you can create visualizations showing which algorithms are most commonly used, which users perform the most operations, and trends over time.

Microsoft Sentinel

Sentinel accepts CEF-formatted logs via a Log Analytics agent or Syslog forwarder. Export your logs in CEF format and forward them through your existing Syslog infrastructure. Sentinel's built-in analytics rules can then correlate QNSQY events with Azure AD sign-ins, network traffic, and other data sources.

Simple File Export

If you do not run a SIEM, you can still view and export the audit log locally. This is useful for small teams or for providing records to external auditors:

# View recent audit events in the terminal
qnsqy audit

# Export the full log to a JSON file
qnsqy audit --export /var/log/qnsqy/audit.json

Compliance Framework Mapping

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

Framework	Specific Requirement	How QNSQY Meets 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	Every encrypt/decrypt operation on files containing patient data is logged with user, timestamp, algorithm, and outcome. Hash-chain prevents log tampering.
SOC 2 (Trust Services Criteria)	CC6.1: Logical and physical access controls. CC7.2: System monitoring.	Audit log records all access to encrypted data. Failed decryption attempts are flagged. SIEM export enables centralized monitoring.
PCI-DSS v4.0	Requirement 10.2: Audit trails record all individual user accesses to cardholder data. 10.3: Audit trail entries contain specific information (user ID, type of event, date/time, success/failure, origin).	Every QNSQY audit event contains user, event type, timestamp, outcome, source hostname. SIEM export provides automated trail collection.
GDPR	Article 32: Implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. Article 5(2): Accountability principle.	Encryption of personal data at rest. Tamper-evident log of all processing operations on encrypted files demonstrates accountability.
SOX (Sarbanes-Oxley)	Section 404: Internal controls over financial reporting. Audit trail of access to financial records.	Log of all encryption/decryption operations on financial documents. Chain verification proves records are unaltered.
NIST Cybersecurity Framework	PR.PT-1: Audit/log records are determined, documented, and reviewed. DE.CM-3: Personnel activity is monitored.	Comprehensive audit logging with SIEM export. Hash-chain integrity verification for PR.PT-1. User attribution on all events for DE.CM-3.

What an Auditor Sees

When an external auditor comes to verify your compliance, they typically ask for a sample of your audit logs and check several things: that the logs exist, that they contain the required fields, that they have not been tampered with, and that they cover the relevant time period. Here is what a compliance review looks like with QNSQY:

The auditor requests encryption activity logs for Q1 2026. You export the audit log for that period and hand them the JSON file.
The auditor checks for required fields. Every entry contains timestamp, user, event type, file identifier, algorithm, and outcome. These are the minimum fields required by PCI-DSS 10.3 and HIPAA audit control requirements.
The auditor checks for integrity. They run qnsqy audit verify and see "chain verified, no tampering detected." This satisfies the tamper-evidence requirement.
The auditor checks for anomalies. They search the log for DECRYPT_FAILED events. If there are clusters of failed attempts, they investigate whether it was a legitimate user who forgot their password or a potential unauthorized access attempt.

Building Useful SIEM Dashboards

Raw log data is only valuable if it is organized into actionable views. Here are specific dashboard ideas that security teams can build once QNSQY logs are flowing into their SIEM:

Daily encryption operations. A time-series chart showing total FILE_ENCRYPTED and FILE_DECRYPTED events per day. A sudden spike might indicate a batch migration or a data exfiltration attempt. A sudden drop might indicate that users have stopped encrypting data, which is its own compliance problem.
Failed decryption heatmap. A heatmap showing DECRYPT_FAILED events by user and time. Clusters of failures from a single user are likely a forgotten password. Clusters from many users against a single file suggest that someone is circulating an encrypted file to people who are not authorized to open it.
Algorithm distribution. A pie chart showing which KEM algorithms are in use. If the organization's policy requires ML-KEM-768 minimum and the chart shows 40% of encryptions using ML-KEM-512, there is a compliance gap that needs to be addressed. This is especially useful after deploying a new encryption policy.
Top users by operation count. A ranked table of which users perform the most encryption and decryption operations. Outliers on either end deserve investigation: a user who encrypts thousands of files per day may be running an unauthorized automated process, while a user who never encrypts anything may not be following data protection procedures.
Shred operations tracking. FILE_SHREDDED events confirm that sensitive plaintext files are being securely deleted after encryption. If the ratio of ENCRYPT to SHRED events is low, users may be leaving plaintext copies on disk.

Alerting Rules Worth Configuring

SIEMs are most powerful when they send proactive alerts rather than requiring manual log review. Here are alert rules that map to real security threats:

Brute-force detection: More than 5 DECRYPT_FAILED events from the same source within 10 minutes. This suggests someone is guessing passwords. QNSQY has built-in rate limiting, but the SIEM alert provides a second layer of visibility.
After-hours operations: Any FILE_DECRYPTED event occurring outside business hours (for example, between 11 PM and 6 AM) from a workstation that is not on an approved exception list. Legitimate after-hours decryption happens, but it should be rare and explainable.
Policy violation: Any FILE_ENCRYPTED event where the algorithm field shows an algorithm below the organization's minimum requirement. This catches cases where users might be running an older QNSQY version or have a misconfigured policy file.
Unexpected configuration change: Any CONFIG_CHANGED event from a user who is not in the administrator group. Configuration changes affect all future encryption operations and should be restricted to authorized personnel.
Chain integrity failure: If a scheduled chain verification job (running qnsqy audit verify) reports a broken chain, the SIEM should immediately alert the security team. A broken chain indicates either data corruption or deliberate tampering.

Best Practices for SIEM Integration

Export regularly. Set up a cron job or systemd timer to export logs every hour or every day. Do not wait until an auditor asks for them.
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 log files.
Set up alerts for failed operations. A burst of DECRYPT_FAILED events could indicate a brute-force attack. A CONFIG_CHANGED event from an unexpected user could indicate unauthorized access.
Verify the chain periodically. Run qnsqy audit verify as part of your regular security checks. If the chain ever breaks, investigate immediately.
Retain logs according to your compliance requirements. HIPAA requires 6 years of records. PCI-DSS requires at least 1 year readily available. SOX requires 7 years. Configure your SIEM retention policies accordingly.
Include QNSQY logs in incident response plans. When investigating a security incident, QNSQY's audit trail can answer critical questions: was this file decrypted before or after the breach? Who was the last person to access it? Did anyone attempt to decrypt it without authorization?

Sources

Business-Grade Compliance

SIEM integration and hash-chain audit logs are available in QNSQY Business.

Contact Sales

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