Skip to content

Structured audit trail and SIEM integration #881

Description

@Manuthor

updated by @HatemMn

Summary

Every key operation should emit a structured JSON audit event so that security teams can feed events into their SIEM, detect anomalies, and produce compliance evidence.

Impact

  • Without structured audit events, regulated customers cannot satisfy PCI-DSS, HIPAA, or SOC 2 audit requirements
  • Absence of SIEM integration is a blocker for security-conscious enterprise accounts
  • OpenTelemetry traces exist but do not provide a per-operation, user-attributed audit record

Implementation plan

  1. New middleware crate/server/src/middlewares/audit.rs emitting structured JSON per request:
    { timestamp, operation, user, object_uid, algorithm, client_ip, result, duration_ms }
  2. Export targets:
    • OpenTelemetry log export (already wired infrastructure)
    • Syslog CEF format (ArcSight / QRadar)
    • HTTP Event Collector endpoint (Splunk HEC)
  3. New config block [audit] with per-target enable flags and endpoint configuration
  4. CLI: ckms audit export --since <date> --format json|cef

Effort: Medium (3-4 weeks) | No prerequisites


Preliminary phase: Definition

Working on this project needs understanding of some concepts that were not within the KMS - Here is a summarized documentation :

SIEMs

A SIEM (Security Information and Event Management) is a system that collects logs and security events from many sources (servers, apps, firewalls, etc.), correlates them, and lets security teams detect attacks, investigate incidents, and build compliance reports in one place.

Note : A security operations center (SOC) is the team responsible for monitoring, analyzing, and investigating security events. A SIEM is the technology utilized by a SOC.

SIEM tools can be implemented as software, hardware, or managed services. Exp: Wazuh SIEM - open source. Some examples worth knwoing are ArcSight, QRadar, Splunk

We need to know some stuff about the latters ...

Splunk

it's a commercial product by Splunk Inc. We will talk about its HEC* specifically because Splunk is so dominant in enterprise security that its HTTP Event Collector has become a de facto integration target.

*(HTTP Event Collector) is Splunk’s HTTP API for sending events/logs directly to Splunk over HTTPS as JSON, authenticated with a token;

ArcSight and IBM QRadar

Same story: neither is open source or an official norm. They are market leaders that drove adoption of CEF (Common Event Format), the actual open source portable format that we will implement. It's a spec.


Other definitions :

OTel

Shorthand for OpenTelemetry. KMS already does this. It's an open‑source standard for collecting telemetry data (logs, metrics, traces) from applications and sending it to backends like Prometheus, Datadog,...

OTLP (OpenTelemetry Protocol) is the wire protocol OpenTelemetry uses to send telemetry data between different actors.

On this KMS : https://docs.cosmian.com/key_management_system/configuration/logging/

syslog

Syslog is a standard protocol and message format for sending logs from systems and applications to a central log server or SIEM; it’s defined in RFC 5424 and is widely used on Unix/Linux.

⚠️ CEF (Common Event Format) in particular is a log format that runs over channels like syslog and standardizes how security events are represented so SIEMs (ArcSight, QRadar, Splunk, etc.) can parse fields like user, source IP, outcome, and severity. ⚠️

PCI‑DSS

PCI‑DSS (Payment Card Industry Data Security Standard) is the security standard you must follow if you store, process, or transmit payment card data (Visa, Mastercard, etc.).

Relation to this PR : It has explicit logging requirements (Requirement 10): you must log user access to cardholder data, admin actions, failed logins, etc., and retain logs for at least one year with three months immediately available.
https://www.pcicompliance.com/pci-requirement-10/

HIPAA

HIPAA (Health Insurance Portability and Accountability Act) is a US law that sets security and privacy requirements for protected health information (PHI).
Like PCI-DSS, it has logging requirements this project should account for : https://www.accountablehq.com/post/hipaa-compliance-for-audit-logs-requirements-and-best-practices

SOC 2 evidence

SOC 2 is an auditing standard (“Service Organization Control 2”) used to evaluate security, availability, confidentiality, etc., of service providers like SaaS platforms; SOC here is not “system on chip”.
To read more : https://security-docs.com/blog/soc2-logging-monitoring
Compliance checklist : https://soc2auditors.org/insights/soc-2-compliance-checklist

WORM

“Write Once, Read Many”: storage where data can be written once and then cannot be modified; this is used to make logs/audit trails tamper‑resistant for compliance. This is so that once an audit log record is written, it cannot be altered or deleted until the retention period expires. It is likely we will need to imprement a sofware storage layer to get this.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions