Native SIEM/SOC integration for IBM ELM / DOORS Next (syslog + structured security/audit events)

Summary

• Add a built-in, supported way to stream security-relevant audit/events from IBM ELM (incl. DOORS Next) directly to external SIEM/SOC platforms (e.g., Nokia SIEM/SOC) using standard protocols and formats, without customers building custom integrations.

Background / why this matters

• Our corporate security governance requires centralized ingestion of application security logs/events into our Company SIEM/SOC for detection, correlation, and incident response.

Current product situation (what exists today)

• ELM provides file-based logs (e.g., jts.log, rm.log) whose locations are controlled by log4j2.xml (default under logs/).

ELM provides an Audit Service that can be enabled per application and writes audit logs into a separately managed audit directory.

Audit Service can help track configuration changes and can include user and IP information.

ELM also has REST API Access Logging, but IBM documents that it is not intended for security logging, and it can significantly affect performance.

Gap / problem

• There is no simple native “send to SIEM/SOC” capability for ELM security/audit events.

• Customers must implement and maintain:

  • log shipping agents / collectors

  • parsing/mapping to SIEM schemas (CEF/LEEF/JSON)

  • buffering/retry/health monitoring

• This increases compliance risk (missed events, format drift, operational failures) and ongoing operational effort, especially in cloud-hosted self-managed deployments.

Requested enhancement (what IBM should build)

1) Native forwarding (“SIEM output”) in ELM

• Configurable targets (1..N) for SIEM collectors

• Syslog forwarding (RFC3164/5424) with TLS support

• Built-in buffering + retry, backpressure handling, and delivery health metrics

2) Standardized security/audit event model

• Consistent schema across:

  • Jazz Team Server + DOORS Next + other ELM apps (EWM/ETM/GC, etc.)

• Export formats:

  • JSON (preferred)

  • Optional: CEF and/or LEEF

3) Minimum event coverage (security-relevant)

• Authentication events (success/failure; SSO outcomes)

• Authorization failures / access denied

• Permission/role changes, project/admin configuration changes

• User/account lifecycle events (create/disable/reactivate)

• Administrative/security settings changes

4) Controls and operations

• Filtering (by app, event type, severity, project area)

• PII (Personally Identifiable Information) controls/masking options (enterprise compliance)

• Clear guidance on performance impact and sizing

Acceptance criteria

• An ELM admin can enable “SIEM forwarding” in the product UI, configure a company SIEM/SOC collector endpoint, and reliably receive structured events for:

  • authentication failures

  • authorization failures

  • permission/config changes
    …with no custom code and no dependency on third-party log shipping agents.