SIEM (Security Information and Event Management)

General definition

A SIEM (Security Information and Event Management) system ingests logs and events from across an estate, turns them into a common format, and applies correlation rules and analytics to spot activity that no single log would reveal: a login from a new country followed by a bulk export, an admin role granted and used within minutes, a spike in failed authentications. Analysts investigate from its dashboards, and the retained data answers the auditor’s question of who did what, when. Commercial examples include Splunk, Microsoft Sentinel, Elastic Security, Google Security Operations and IBM QRadar.

• Collection: agents on hosts, syslog, cloud provider log streams, API pulls, and object storage buckets that applications write to
• Normalisation and enrichment: mapping fields to a common schema, adding user, asset and threat-intelligence context
• Correlation and detection: rules, statistical baselines and machine learning that raise alerts
• Retention and search: keeping events for the period a regulation or policy requires and making them searchable for investigations
• Response: case management and, with SOAR tooling, automated playbooks

Regulation is the usual reason a SIEM becomes mandatory rather than nice to have. HIPAA’s Security Rule requires audit controls and review of system activity, PCI DSS requires logging of access to cardholder data with defined retention, and financial supervisors expect a record of communications and administrative actions. The SIEM is where those records are centralised, so any application that holds regulated data is expected to export its audit log in a form the SIEM can ingest, with reliable timestamps, actor identity and event type.

For a messaging platform the relevant events are not only infrastructure logs. Security teams want to know when a user was created or deleted, when a role changed, when a data export ran, when a retention policy was altered, and when moderation caught something. Those application-level events, retained for the required period (see log retention), are what make chat auditable rather than merely encrypted.

In the Ethora ecosystem

Ethora produces the two streams a SIEM wants from a chat platform. The compliance audit trail records administrative and access events, with an immutable log export to S3 so the organisation’s SIEM can ingest from a bucket it controls; the Trust & Safety system reports policy hits (block, censor, quarantine and report, or report only) to your own systems through a message bus, an API or email. Either path lands the events in the security team’s tooling without Ethora needing a connector for each product.

On a dedicated or self-hosted deployment the platform runs inside the customer’s own cloud account, so the infrastructure logs, the ejabberd and API logs, and the Grafana and Prometheus metrics are already inside the perimeter the SIEM watches. That is the model Ethora takes for regulated industries: the server can archive, audit and export rather than hide activity behind client-side encryption, which is what makes the events available to a SIEM in the first place.