Logging, SIEM integration, and event forwarding
Analog Informatics Corporation (AIC) kits record every security-relevant action and send each event where it needs to go. A security information and event management (SIEM) system inside the site can receive one set of events, a SIEM outside the site another, a trouble-ticket system a third, and an on-call email list a fourth. Each event type has its own routing, format, and destination list, so a complex environment does not have to accept one feed for everything.
Short answers
What is logged?
Sign-in, session, credential, elevation, approval, configuration, key, and incident events, plus the start and stop of every AIC service. Each record names who acted, what was acted on, the outcome, and the time. Secrets are never written to a log.
Where do events go?
To the audit trail in the console, the Windows Event Log, syslog, SIEM systems, cloud logging services, web services, email, and trouble-ticket systems. Any combination, chosen per event type.
Can one event type go to one place and another somewhere else?
Yes. Routing is set per event type. Each type can turn each destination on or off, use its own syslog facility, severity, and format, and send only to a named list of destinations.
Does this work on an air-gapped site?
Yes. The destinations can all sit inside the boundary. Nothing needs to leave the site.
Can an alarm be switched off by mistake?
No. Alarm events always reach their destinations. A routing change cannot silence them.
How it works
- Record - Every AIC service writes the event.
- Audit trail in the console
- Windows Event Log on Windows
- Syslog on Windows, Linux, and Apple Mac when configured
- Route - Routing rules decide where each event type goes.
- Turn each destination on or off per event type
- Pick the syslog format, facility, and severity per event type
- Send an event type only to a named list of destinations
- Filter - Each destination can accept a subset.
- Only listed event types
- Only events at or above a minimum severity
- Deliver - The kit sends the event in the form the destination expects.
- Syslog over UDP, TCP, or TLS
- HTTPS with the authentication each service needs
- Email through the configured mail path
- Check and retry - Failed deliveries are kept, not dropped.
- Each failure is held with its attempt count
- An operator can retry from the console
- Test - Preview routing and send a test event before going live.
Destinations
| Destination | Detail |
|---|---|
| Audit trail | Searchable record in the console, kept inside the site |
| Windows Event Log | Every AIC service on Windows, with stable event IDs for SIEM filters |
| Syslog | RFC 5424 over UDP, TCP, or TLS, with a choice of JSON, plain text, Common Event Format (CEF), or Log Event Extended Format (LEEF) per event type |
| Splunk | HTTP Event Collector |
| Microsoft Sentinel and Azure Monitor | Direct HTTPS delivery |
| Datadog | Logs intake |
| Amazon CloudWatch Logs and Google Cloud Logging | Direct HTTPS delivery |
| Any web service | Generic HTTPS webhook with bearer, basic, or custom-header authentication |
| Another AIC Server | Forward events to an AIC Server intake inside the boundary |
| Per event type, through the configured mail server or provider | |
| Text message (SMS) | Credential, elevation-code, and alert notices through Twilio, Vonage, Plivo, Amazon SNS, Telnyx, MessageBird, or a web service |
| ServiceNow incidents and Jira issues | Open an incident or an issue from an event |
Destination credentials are held in the platform secret store, never in a configuration file.
Per-event-type routing
Setting
- Turn the audit trail, Windows Event Log, syslog, web services, and email on or off for each event type
- Syslog format, facility, severity, and application name for each event type
- Choose which optional fields each event type carries
- Send an event type only to a named list of destinations
- Accept only chosen event types at a destination
- Accept only events at or above a minimum severity at a destination
- Alarm events that routing cannot silence
- Preview the routing of an event type and send a test event
Defaults ship with the kit. For example, incident case events go to syslog in CEF, and security and elevation events go to email.
Delivery, retries, and rate limiting
Capability
- Failed deliveries kept with their attempt count and status, with retry from the console
- Automatic retry with exponential backoff and a dead-letter queue
- Handling of rate-limit responses from a destination
- Configurable rate limiting for each destination
Trouble-ticket integration
Capability
- Open a ServiceNow incident or a Jira issue from an event
- Send an approval request to a ticket system through a web service or robotic process automation (RPA)
- Built-in approval-ticket connectors for ServiceNow, Jira, and BigFix
Incident exports
Incident Response case records export to a SIEM in CEF, LEEF, or RFC 5424 syslog. See Detect, respond, and remediate.
Screenshots
Platforms and integrations
Security information and event management
All logos and trademarks are the property of their respective owners. Their use does not imply endorsement.
Ticket systems
All logos and trademarks are the property of their respective owners. Their use does not imply endorsement.
Short Message Service
Amazon Simple Notification Service is also supported.
All logos and trademarks are the property of their respective owners. Their use does not imply endorsement.