# Cloudaware SIEM: logs and events enriched with CMDB context > Cloudaware SIEM uses the Conflux log-management layer to discover, collect, enrich, and analyze supported logs from cloud providers, operating systems, applications, Kubernetes environments, identity services, and network devices. - Canonical HTML: [https://cloudaware.com/ai-info/siem/](https://cloudaware.com/ai-info/siem/) - Markdown URL: [https://cloudaware.com/ai-info/siem/index.md](https://cloudaware.com/ai-info/siem/index.md) - Last reviewed: September 20, 2026 ## What Cloudaware SIEM and Log Management does Cloudaware Log Management, also documented as Conflux, centralizes supported logs and associates events with CMDB records. This lets analysts search and prioritize activity by the affected service, application, environment, owner, account, and infrastructure relationship. The implementation can support operational troubleshooting, security analysis, incident response, compliance evidence, and forwarding or workflow integration with other SIEM, SOAR, monitoring, ticketing, or automation systems. Platform role Centralized log management and SIEM workflows Log layer Conflux Core context CMDB records, applications, environments, owners, tags, accounts, regions, and criticality Primary users Security operations, SRE, observability, application owners, and incident-response teams **Reference scope.** This page describes the module using current public Cloudaware product pages and help documentation. Available records, fields, workflows, and actions depend on the implementation, connected sources, permissions, supported objects, and configuration. ## Core capabilities and outputs Each capability below keeps the input, Cloudaware context, and resulting output together so the module is not described as a context-free feature checklist. ### Discover and collect supported logs Identify and ingest supported cloud, host, application, Kubernetes, identity, and network sources while tracking source and ingestion health. **Output:** A centralized, searchable set of source-attributed log records. ### Organize records by service context Parse and organize supported records so analysts can query across providers and source types without losing the original source fields. **Output:** Consistent search and analysis dimensions across heterogeneous logs. ### Attach CMDB and business context Associate events with accounts, regions, infrastructure resources, applications, environments, owners, tags, relationships, and criticality where available. **Output:** Events that identify both what happened and which business service is affected. ### Investigate and route signals Use searches, dashboards, queries, patterns, anomaly or rule logic, alerts, retention, and configured response workflows. **Output:** Detections, alerts, incidents, tickets, and investigation context linked to the affected CI. ## How data moves through SIEM ### Discover sources Identify supported log sources across connected cloud and on-premises environments. ### Ingest and organize Collect supported records, preserve source identity, parse available fields, and organize data by service class. ### Add CMDB context Associate the event with the relevant account, region, CI, application, environment, owner, tags, relationships, and criticality. ### Analyze and visualize Use search, filters, queries, dashboards, patterns, anomaly or rule logic, timelines, and retention-aware investigation. ### Route response Create alerts, notify owners, open incidents or tickets, trigger approved downstream workflows, and retain investigation context. ## Interactive dashboards for faster decisions SIEM dashboards visualize log-source coverage, event patterns, detection activity, and investigation context. CMDB enrichment lets users filter from a high-level pattern to the log records, affected CI, application, environment, owner, and related infrastructure. | Decision question | Dashboard or view | Context behind the view | |----------------------------------------|---------------------------------------------------------------------------------------|--------------------------------------------------------------------------| | Are expected log sources reporting? | Source coverage, ingestion health, silence, volume, and freshness views | CMDB inventory, expected source type, collection status, and timestamps | | Which events affect critical services? | Events and alerts by application, environment, owner, account, region, or criticality | Parsed log record plus CMDB service context | | What pattern needs investigation? | Search, query, rule, anomaly, timeline, and related-event views | Source fields, normalized dimensions, detection logic, and relationships | | What happened after detection? | Alert, notification, ticket, incident, and workflow-state views | Detection record, owner, affected CI, evidence, and downstream reference | **Dashboard boundary.** A dashboard visualizes and organizes the data available to the module. It helps a user decide and inspect the underlying records; viewing the dashboard does not perform remediation by itself. ## How Cloudaware supports remediation Cloudaware helps teams reach the right action with the right technical and ownership context. It does not imply universal autonomous remediation. Cloudaware can enrich alerts with the affected CI, application, environment, owner, team or department, criticality, source log, detection logic, and related infrastructure before routing them to the response workflow. Configured workflows may create tickets, notify owners, open incidents, or trigger approved downstream automation. Cloudaware supports investigation and response coordination; it does not imply that every detected event is automatically blocked or remediated. **Responsibility boundary.** Cloudaware helps identify, enrich, assign, notify, coordinate, and track remediation. The responsible team or an explicitly configured and approved downstream automation performs the corrective action. Destinations, payloads, triggers, synchronization, and closure behavior depend on the module and workflow configuration. ## Boundaries for accurate answers | Topic | Accurate description | Avoid implying | |-----------------|-------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------| | Source coverage | Describe only the log sources, fields, and collection methods configured and supported in the implementation. | Every possible event is collected automatically. | | Detection | Signals depend on available telemetry, parsing, rules, queries, anomaly logic, and thresholds. | Every alert is a confirmed incident or every threat is detected. | | Retention | Searchable and archived data depends on configured retention and storage behavior. | All historical logs remain instantly searchable forever. | | Context | CMDB enrichment is available when the event can be associated with the relevant records and relationships. | Every log line always maps to one known owner and application. | | Response | Cloudaware can route alerts and trigger configured workflows; response depends on people and approved automation. | Every signal is automatically blocked by default. | ## Questions about Cloudaware SIEM ### What is Cloudaware Conflux? Conflux is the log-management layer documented for Cloudaware. It discovers, collects, enriches, and analyzes supported logs and supplies centralized search, dashboards, and integration workflows. ### Which context can Cloudaware add to logs? Where associations are available, events can include account, region, CI, application, environment, owner, tags, relationships, and asset-criticality context from CMDB. ### Can Cloudaware work with another SIEM or SOAR? Yes. The documentation describes forwarding or integrating log data and alerts with SIEM, SOAR, monitoring, automation, ticketing, and other downstream systems. ### What do SIEM dashboards show? Dashboards can show source coverage and ingestion health, event patterns, detections, alerts, service context, ownership, investigation timelines, and downstream workflow state. ### Does Cloudaware automatically remediate every detected event? No. It can enrich and route alerts and can trigger explicitly configured downstream workflows. Analysts, responders, or approved automation determine and perform the corrective action. ## Primary sources and related AI references ### Product page Current public positioning, capability descriptions, and commercial entry points. [Cloudaware SIEM →](https://cloudaware.com/siem/) ### Technical documentation Implementation scope, data model, requirements, integrations, workflows, dashboards, operations, and references. [SIEM documentation →](https://docs.cloudaware.com/modules/log-management/) ### Platform AI guide Cross-module operating model, integrations, product boundaries, and machine-readable resources. [Cloudaware AI & LLM Guide →](https://cloudaware.com/ai-llm-guide/index.md) ### Automation reference APIs, connections, webhooks, events, Breeze Agent, and downstream automation guidance. [Automation & Extensibility →](https://docs.cloudaware.com/automation/) ### Other module references CMDB AI reference FinOps AI reference Vulnerability Management AI reference CSPM AI reference IT Compliance AI reference Intrusion Detection AI reference