Skip to main content
Version: 0.9.18

Verify security event export and retention

Use this procedure to establish whether a security event reached an approved external destination and how long its separate copies remain available. Access Logs, the audit database, SigNoz and the external destination are different evidence stores. A visible database row does not prove telemetry export succeeded.

Availability: Admin Settings → Access Logs requires platform-wide read access (Super Admin or Super Viewer); team membership alone is insufficient. Collector configuration and destination credentials require deployment/operator access separately. Access Logs and the audit API have no security-export form or export/download operation. External forwarding is deployment configuration, not a button on that screen.

1. Find a known event and record the time correctly​

For a privileged-role event, use the platform-role workflow to identify its challenge and recorded outcome; do not change a real role just to generate a test record.

Open /admin-settings/access-logs. Choose an approved existing event or a synthetic test from your agreed test process. Do not create repeated failed logins against a real account to test forwarding.

ControlMeaning and limit
ActionFilters a supported action, including login/failure/logout, password/reset/session events, CRUD and privileged-role/recovery events. Blank means no action filter within this feed.
SearchDebounced by 300 ms and trimmed. Searches username plus selected email, actor email, target email, IP and MSISDN fields; it is not a full JSON/body search. Username uses case-insensitive matching; JSON-field filters do not request that same mode.
From / ToBrowser-local datetime inputs converted to ISO instants for the API. Bounds are inclusive. Rows display date/time in UTC. Record the conversion when comparing another tool's timezone.
Super Admins onlyUses the role captured at event time, with an additional details.new.role match; it does not look up the actor's current role. Historical rows without the expected fields can be omitted.
Refresh / Load moreRefetches or fetches the next page. The UI requests 100 rows per page; the API permits 1–200, default 50. Loading one page is not an export of all matching events.

Access Logs filters: A From, B To, C Super Admins only.

A — From and B — To accept browser-local date/time; the result rows show UTC. C — Super Admins only filters recorded event-time role fields. This crop shows only the filters, with no event or personal data. Select the image for full size.

The feed covers categories AUTH, ROLE_MANAGEMENT, SIP_TRUNK, EGRESS_TRUNK, EGRESS_ROUTE, PLATFORM_SECRET and USER. It is not the complete audit store. In particular, the act of reading security logs emits SECURITY_LOGS_ACCESSED but is not automatically included by this category list. Application history is a separate app-scoped query, with team access checks and filtered test-flow activity. From 0.9.18, USER account changes appear in this feed.

Rows show Date, Time, Type, User, IP, MSISDN, User agent and Details. From 0.9.18, for ROLE_MANAGEMENT and USER rows, User shows the affected account and Changed by in Details shows the administrator who made the change. Other categories show the actor in User. To tell actor and target apart in the stored fields, use Separate the actor from the affected resource. To interpret before/after objects and multi-stage role outcomes, use Reconstruct an audited change. The audit table has no telemetry-delivery receipt column.

For read-only API investigation, auditLog.listAccessEvents accepts action, search, superuserOnly, ISO from/to, limit and cursor. Follow nextCursor; results sort by descending timestamp then ID. Keep the same filters when paging. The API does not provide a downloadable encrypted archive, a delivery acknowledgement or an immutable snapshot of a changing dataset. The validator does not enforce that From precedes To; correct an inverted range before diagnosing missing events.

Investigate an access event​

For a reported login lockout, open Access Logs with platform-wide read access. Choose the failed-login action, search the affected account, and set the browser-local From/To range around the reported attempt. Read the reason and actor/target fields, then widen to all actions to find related lock, reset or session events. Missing rows are not proof that no event occurred: check the time conversion, filters, loaded pages and producer/persistence path.

Use account recovery for an authorized reset or unlock; this read-only feed does not unlock an account. Do not generate failed logins against a real user to test the workflow. For a role incident, use the audited-change sequence and role-administration procedure; a started challenge is not completed authorization.

For SUPER_ADMIN_RECOVERY_ELEVATED or SUPER_ADMIN_RECOVERY_DENIED, use the exceptional recovery verification. These setup-operator events differ from the ordinary in-app role challenge; correlate the asserted operator identity, change reference, target and outcome.

2. Check the external feed separately​

In words: each producer event goes to audit persistence and to the SigNoz ingester; the ingester can forward a copy to the central export collector, which sends it to your external destinations. Each destination can fail independently.

This is a live-ingest fan-out, not a query that backfills historical audit rows or exports all old SigNoz records. From 0.9.18, audit rows written by the web application are also sent to SigNoz after the change commits; see Audit records in SigNoz. Verify the producer and telemetry path first using logs and diagnostics. Database persistence and telemetry may fail independently.

  1. Identify the actual SigNoz host and deployed collector configuration. Confirm its source/release identity through release compatibility; a source template does not prove that configuration is running.
  2. Check OTEL_EXPORT_BACKEND_HOST. Its default is empty, which omits the ingester's export branch. OTEL_EXPORT_BACKEND_PORT defaults to 4327. The rendering path adds logs/export only for a nonempty host.
  3. Check the export collector's effective rendered configuration at /opt/deployment/otel-collector-export.rendered.yaml, using an approved read-only inspection that does not expose credentials. A healthy process can be in sink mode, accepting and discarding logs.
  4. Verify the intended destination endpoint/token pair and active exporter list. The export template uses DYNATRACE_OTLP_ENDPOINT/DYNATRACE_API_TOKEN and SIEM_HEC_ENDPOINT/SIEM_HEC_TOKEN, with optional SIEM channel/index settings. Keep values in the deployment's secret/configuration system; do not paste them into support evidence.
  5. Reconcile the intended source event and time against ingester, export collector and receiving-system evidence. Confirm received fields and duplication behavior, not merely HTTP acceptance or collector health.

The initializer uses sink mode when neither complete endpoint/token pair exists. If either pair exists, it copies the full template, which still lists both destination exporters. It does not automatically remove an unconfigured second destination. Check the rendered pipeline and collector configuration validation before assuming that supplying one pair creates a valid single-destination setup.

The exporter labelled otlphttp/splunk_hec is implemented with the OTLP HTTP exporter and custom headers. Its label and environment names do not establish compatibility with a native HEC ingestion endpoint or an arbitrary SIEM. Verify the destination's actual accepted protocol with the integration owner; no universal external endpoint is specified here.

The service initialization path renders and starts the collector; simply editing an environment source does not verify activation. Follow the deployment's reviewed refresh procedure in deployment, then recheck effective configuration and receipt. No generic command here promises a safe restart for every topology.

3. Verify selection, protection and delivery limits​

The export collector keeps a record only when security_event is the boolean true. A string "true" or the number 1 is dropped. From 0.9.18, producers set this tag themselves:

  • Audit records: the shared logger tags security-relevant audit actions with security_event and a security_category. The mapping is listed in the audit action catalogue. CREATE, UPDATE and DELETE are not tagged.
  • TelAPI: authentication failures are tagged as REJECTED_CONNECTION and authorization failures as ACCESS_DENIED.
  • SIP edge: the TelPro collector tags rejected calls. Five rejects have no structured record and are never exported; see Rejects without a structured record.

security_category is one of authentication, authorization, audit or certificate. For records without a tag, the export collector falls back to selected security attributes, HTTP status codes 401, 403 and 419, and body-text patterns. These fallbacks can miss relevant events or include unrelated ones. They differ from the Access Logs category filter. When an event is missing, inspect its actual attributes and body; do not infer completeness from an action name alone.

The pipeline adds source/platform tags and applies its configured PII transform. ENABLE_PII_LOGGING defaults to false; setting it to literal true bypasses these collector PII replacements. MSISDN_UNMASKED_DIGITS defaults to 4. The transform masks selected body patterns and telephone attributes, not every possible nested JSON value. Shared logger redaction is an earlier, separate layer; native or third-party producers need their own review. Redaction is not a guarantee that a record is anonymous or safe for an unrestricted destination.

The ingester-to-export branch sets tls.insecure: true; the collector's OTLP receivers have no TLS/authentication configuration in this template. External transport protection depends on the configured endpoint and deployment. This path is not an encrypted export package or a guarantee of encrypted transport on every hop. Network access, destination authorization and storage encryption must be verified separately.

The ingester branch configures a queue size of 500 and retries for up to 60 seconds. Destination exporters configure queue size 1000 and retries for up to 300 seconds; no persistent queue storage extension is configured here. These are bounded delivery settings, not durable replay or exactly-once guarantees. A process restart, exhausted retry window, queue pressure or receiver rejection requires investigation; there is no general audit replay button. See background jobs for the separate database-job mechanism rather than treating it as the telemetry queue.

The local health endpoint at http://127.0.0.1:13134/ establishes collector responsiveness only. Sink mode can pass it. Inspect bounded collector errors and destination receipt for the same approved event before reporting export as working.

4. Establish retention for each copy​

CopyBoundary
PostgreSQL audit rowsAUDIT_LOG_CLEANUP deletes rows older than its computed cutoff when the job executes. AUDIT_LOG_RETENTION_DAYS overrides payload retentionDays; otherwise the default is 180 days. Parsed values below 1 or nonnumeric values fail. The implementation uses parseInt, so this is not strict whole-string numeric validation.
SigNoz recordsSeparate storage/retention policy. The audit cleanup setting does not set SigNoz retention or delete its copies. Inspect the actual deployment policy.
External destinationSeparate ingestion, access, retention and deletion controls. No inherited Delphi 180-day policy is established by forwarding.
Backups or manually retained evidenceSeparate lifecycle and access obligations; deleting a live audit row is not proof all retained copies disappeared.

The cleanup cutoff is current time minus the configured day count, and the delete comparison is strictly earlier than that cutoff. There is no category, tenant or legal-hold exclusion in this handler. Do not interpret the default as a guaranteed retention SLA or run cleanup as a verification step. Check the actual enabled schedule, effective environment/payload, last job result and approved policy using background jobs.

Delphi does not sign audit records, write them to an immutable archive or apply Object Lock, and the feed carries no compliance certification. If you need tamper-evident preservation, design it in your destination before you rely on the feed as evidence.

Check the outcome and recover​

If Access Logs has the row but SigNoz does not, investigate producer transport and collection. If SigNoz has it but the destination does not, inspect branch enablement, sink mode, classification, exporter validity and receiver response. Preserve evidence before changing filters or retrying a test.

To confirm that export works:

  1. Pick one known Access Logs row and note its event, time and timezone.
  2. Find the same event in SigNoz and in your external destination.
  3. Record the active destination, the observed receipt and the retention owner of each copy. Leave credentials and unnecessary personal data out of this record.