feat: Fix review issues and integrate ASTRAL, PULSAR, AURORA product suite
Framework fixes: - antifragile-manifest.md: Correct AI Sovereignty pillar (data residency/audit rights framing); add consultant note - executive-summary.md: Same AI sovereignty correction; add EU Regulatory Context (NIS2, DORA, GDPR) - README.md: Add Brownhat brand explanation; expand Standards Alignment with NIS2/DORA/GDPR - core/about-cqre.md: Prominent TEMPLATE WARNING banner to prevent accidental sharing - index.md: Add CQRE Product Suite; renumber consultant nav 1-26 consistently New: playbooks/cqre-product-suite.md - ASTRAL/PULSAR/AURORA product reference with antifragile pillar alignment, regulatory mapping, deployment prerequisites, and objection handling Updated: sovereign-tool-stack.md - ASTRAL updated to GitHub product spec; AOC replaced with PULSAR; AURORA section added Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
This commit is contained in:
Claude Sonnet 4.6
@@ -0,0 +1,213 @@
|
||||
# CQRE Product Suite: ASTRAL, PULSAR, and AURORA
|
||||
|
||||
> *"Three questions every M365 administrator eventually asks: what does my configuration look like, what happened in my tenant, and what does it mean? The CQRE suite is built to answer all three — each product independently valuable, progressively more powerful in combination."*
|
||||
|
||||
This document describes the three CQRE-built products, how they fit into the antifragile consulting framework, and how to position and deploy them in engagements.
|
||||
|
||||
---
|
||||
|
||||
## Suite Overview
|
||||
|
||||
| Product | Full Name | What It Answers | Model | Repo |
|
||||
|---------|-----------|-----------------|-------|------|
|
||||
| **ASTRAL** | Admin Security: Tenant Review, Automation & Lifecycle | *What does my M365 configuration look like and what has changed?* | Free, open source | [github.com/cqrenet/astral](https://github.com/cqrenet/astral) |
|
||||
| **PULSAR** | Platform for Unified Log Search, Alerting & Review | *What happened in my tenant, when, and by whom?* | Free, open source | [github.com/cqrenet/pulsar](https://github.com/cqrenet/pulsar) |
|
||||
| **AURORA** | Audit, Unified Review, Observability & Remediation for Administrators | *What does it mean and what should I do?* | Paid | [aurora.cqre.net](https://aurora.cqre.net) |
|
||||
|
||||
**The product narrative in one sentence**: PULSAR captures the signal, ASTRAL holds the baseline, AURORA makes sense of both.
|
||||
|
||||
---
|
||||
|
||||
## Framework Alignment
|
||||
|
||||
Each product maps directly to specific antifragile pillars from the [Antifragile Manifest](../core/antifragile-manifest.md).
|
||||
|
||||
### ASTRAL → Pillar 1 (Structural Decoupling) + Pillar 5 (Asymmetric Payoff Design)
|
||||
|
||||
ASTRAL treats M365 configuration as code — Git-tracked snapshots with PR-based review, drift detection, and baseline restore. Every Intune profile, Conditional Access policy, and Entra setting is versioned, auditable, and recoverable.
|
||||
|
||||
**Pillar 1 alignment**: ASTRAL surfaces hidden coupling in M365 configuration. Conditional Access policies with undocumented exclusion groups, Intune profiles silently competing, admin roles accumulating without review — these are the dependencies that produce fragility. ASTRAL makes them visible and governable.
|
||||
|
||||
**Pillar 5 alignment**: The deployment cost is low (one Azure DevOps project, one Entra app registration). The protection payoff is disproportionately large: compliance evidence produced automatically, configuration changes reviewed before they become incidents, rollback available in minutes.
|
||||
|
||||
**Kill chain relevance**: A compromised admin account that modifies Conditional Access policies is a kill-chain event. ASTRAL detects this drift within minutes via the event-driven change probe and surfaces it as a PR requiring review.
|
||||
|
||||
### PULSAR → Pillar 3 (Stress-to-Signal Conversion)
|
||||
|
||||
PULSAR ingests M365 audit events — Entra directory changes, Intune actions, Exchange/SharePoint/Teams operations — into a searchable, retained store with alerting and SIEM forwarding.
|
||||
|
||||
**Pillar 3 alignment**: PULSAR is the instrumentation layer for M365. Without it, admin actions are visible for 90 days in the M365 portal and then gone. With it, every admin action becomes permanent, searchable signal. An incident that would have been un-investigable three months later becomes reconstructible in minutes.
|
||||
|
||||
The antifragile principle is explicit: **every stress event produces a signal**. PULSAR ensures no signal is lost.
|
||||
|
||||
**Kill chain relevance**: When a threat actor enumerates admin accounts, modifies authentication methods, or creates a new enterprise application for persistence, PULSAR captures these events. Combined with alerting rules, PULSAR converts audit noise into actionable detection.
|
||||
|
||||
### AURORA → Pillar 4 (Sovereign Intelligence) + Pillar 2 (Optionality Preservation)
|
||||
|
||||
AURORA connects to PULSAR and ASTRAL via their MCP servers and exposes a unified AI-assisted interface for cross-tool diagnostics, multi-scope orchestration, and enriched SIEM forwarding.
|
||||
|
||||
**Pillar 4 alignment**: AURORA is sovereign intelligence applied to M365 operations. The cross-tool diagnostic tools — correlating audit events with configuration state — produce intelligence that no commercial tool natively generates. This intelligence lives in your infrastructure (self-hosted) or in EU-hosted infrastructure (managed tier), not in a vendor platform you cannot control.
|
||||
|
||||
**Pillar 2 alignment**: AURORA is designed for optionality at every layer. It stores no data itself — data lives in PULSAR's MongoDB and ASTRAL's Git repository, both under your control. The AI layer is pluggable (Azure OpenAI, Ollama, or the managed `llm.cqre.net` endpoint). Switching the underlying model requires one config line.
|
||||
|
||||
---
|
||||
|
||||
## Product Details
|
||||
|
||||
### ASTRAL
|
||||
|
||||
**What it tracks**:
|
||||
|
||||
*Intune*: App Configuration, App Protection, Applications, Compliance Policies, Device Configurations, Enrollment Configurations, Filters, Scope Tags, Scripts, Settings Catalog, and more.
|
||||
|
||||
*Entra*: Named Locations, Authentication Strengths, Conditional Access, App Registrations, Enterprise Applications.
|
||||
|
||||
**How it works**:
|
||||
1. An Azure DevOps pipeline runs daily (and on-demand via an event-driven change probe) to export the full tenant configuration.
|
||||
2. Drift from the committed baseline is committed to a drift branch and surfaced as a rolling PR.
|
||||
3. Reviewers approve or reject individual changes in the PR. Approved changes merge; rejected changes trigger an automated restore.
|
||||
4. The entire history lives in Git — indefinite, auditable, diff-able.
|
||||
|
||||
**AI (optional)**: Bring your own Azure OpenAI endpoint to generate human-readable PR narratives. ASTRAL is complete without it — AI is supplementary, not required.
|
||||
|
||||
**MCP server**: ASTRAL includes an MCP server (Azure Container Apps) that exposes tenant state and drift history to AI assistants via natural-language queries. This is what AURORA connects to.
|
||||
|
||||
**Deployment**: Azure DevOps, one pipeline set per tenant. Full setup guide in [`deploy/onboarding-runbook.md`](https://github.com/cqrenet/astral/blob/main/deploy/onboarding-runbook.md).
|
||||
|
||||
**Engagement module pairings**: Modules 1–5 (all M365 modules), Module 3 (M365 Hardening) as primary drift detection layer. Used in the first-week baseline checklist for every M365 engagement.
|
||||
|
||||
---
|
||||
|
||||
### PULSAR
|
||||
|
||||
**What it ingests**:
|
||||
- Entra ID directory audit logs
|
||||
- Intune audit logs
|
||||
- Exchange Online, SharePoint, and Teams via the Office 365 Management Activity API
|
||||
|
||||
**Core capabilities**:
|
||||
- Watermark-based incremental ingestion with MongoDB persistence
|
||||
- Search and filter UI with REST API
|
||||
- Alerting rules engine with webhook delivery *(see maturity note below)*
|
||||
- SIEM forwarding *(see maturity note below)*
|
||||
- MCP server (stdio and SSE): `search_events`, `get_event`, `get_summary`
|
||||
- Entra OIDC auth and Azure Key Vault integration
|
||||
|
||||
> **Maturity note — alerting and SIEM forwarding**: Both features are functional but proof-of-concept quality. They are suitable for evaluation and non-critical environments. Alerting has no UI for rule management and webhook delivery has no retry logic. SIEM forwarding is basic with no delivery guarantees. Production hardening of both is on the roadmap. Do not recommend these features for production use in critical environments without documenting this caveat to the client.
|
||||
|
||||
**MCP server**: PULSAR's MCP server exposes audit event search to AI assistants. AURORA connects to this endpoint for cross-tool diagnostics.
|
||||
|
||||
**Deployment**: Docker Compose. Full quickstart in the [GitHub README](https://github.com/cqrenet/pulsar). Azure deployment guide in `DEPLOY-AZURE.md`.
|
||||
|
||||
**Engagement module pairings**: Module 12 (Blue/Purple Team Foundation) as the M365 detection layer; Module 10 (AI-Assisted TVM) for audit-trail enrichment; any retained capability engagement where M365 log retention is a client requirement.
|
||||
|
||||
---
|
||||
|
||||
### AURORA
|
||||
|
||||
**What it does**: A unified operations platform that sits in front of PULSAR and ASTRAL. Connects to both via MCP, exposes a single AI interface, and provides cross-tool diagnostics that neither product can answer alone.
|
||||
|
||||
AURORA stores no data. All data lives in PULSAR (MongoDB) and ASTRAL (Git).
|
||||
|
||||
**Cross-tool diagnostic tools**:
|
||||
|
||||
| Tool | What It Answers |
|
||||
|------|----------------|
|
||||
| `diagnose_policy_errors` | "Why is this Intune compliance policy succeeding on most devices but erroring on some?" — pulls ASTRAL policy config and PULSAR audit events for the same policy |
|
||||
| `explain_device_compliance` | "Why did this device suddenly become non-compliant?" — combines ASTRAL assignment data with PULSAR event timeline |
|
||||
| `correlate_drift_with_audit` | "Who in the portal triggered this configuration drift commit?" — matches ASTRAL Git commits with PULSAR audit events by timestamp |
|
||||
| `tenant_security_summary` | "What happened in my tenant this week that I should know about?" — combines open ASTRAL drift PRs with PULSAR event summary, generates executive briefing |
|
||||
| `compare_scopes` | "What's different between my production and development Conditional Access policies?" — cross-scope comparison |
|
||||
|
||||
**Multi-scope orchestration**: AURORA connects to multiple named ASTRAL instances. Production read-only and development read-write in the same interface. Directly useful for clients with strict prod/non-prod separation.
|
||||
|
||||
**Enriched SIEM forwarding**: PULSAR forwards raw audit events. AURORA forwards enriched events — audit events correlated with ASTRAL configuration state at the time of the event. This produces materially higher-quality data for SIEM detection rules.
|
||||
|
||||
**Pricing** (EUR, ex. VAT):
|
||||
|
||||
| Tier | Self-hosted | Hosted (fully managed) |
|
||||
|------|-------------|----------------------|
|
||||
| Single tenant | €259/mo (€2,590/yr) | €389/mo (€3,890/yr) |
|
||||
| Up to 5 scopes | €429/mo (€4,290/yr) | €599/mo (€5,990/yr) |
|
||||
| Enterprise | Custom | Custom |
|
||||
|
||||
Self-hosted customers bring their own Azure OpenAI endpoint (or any OpenAI-compatible API including Ollama for local models). Hosted tier includes managed AI (~500 queries/month fair use).
|
||||
|
||||
---
|
||||
|
||||
## Regulatory Alignment (EU)
|
||||
|
||||
The CQRE suite was designed with EU regulatory requirements as primary constraints, not afterthoughts.
|
||||
|
||||
| Regulation | Requirement | CQRE capability |
|
||||
|------------|-------------|-----------------|
|
||||
| **NIS2** Art. 21 | Configuration management, logging and monitoring, access control | ASTRAL (config), PULSAR (logging), AURORA (cross-tool analysis) |
|
||||
| **DORA** Art. 10 | ICT incident log retention and monitoring | PULSAR (permanent audit log retention, searchable) |
|
||||
| **DORA** Art. 11 | ICT change management records | ASTRAL Git trail (timestamped, reviewed, approved) |
|
||||
| **GDPR** Art. 5(2) | Accountability principle — demonstrate compliance | ASTRAL Git history is directly usable as audit evidence |
|
||||
| **GDPR** Art. 32 | Appropriate technical measures for data protection | Continuous config governance + audit log retention |
|
||||
| **GDPR** Art. 33 | 72-hour breach notification | PULSAR enables rapid incident reconstruction |
|
||||
| **ISO 27001** A.8.9 | Configuration management | ASTRAL |
|
||||
| **ISO 27001** A.8.15–16 | Logging and monitoring | PULSAR |
|
||||
|
||||
**Consultant talking point**: For clients in NIS2-regulated sectors (health, finance, digital infrastructure, public sector), the CQRE suite is not a nice-to-have — it directly maps onto mandatory Article 21 measures. Frame the deployment cost against the supervisory authority's enforcement posture in their country, not against a generic security ROI.
|
||||
|
||||
---
|
||||
|
||||
## Positioning in Engagements
|
||||
|
||||
### Combination A — PULSAR + ASTRAL (free entry, any engagement)
|
||||
|
||||
Deploy the free stack at the start of any M365 engagement. ASTRAL provides the baseline capture that week 1 requires. PULSAR provides the audit trail that retained capability clients need. Both are free — there is no procurement barrier.
|
||||
|
||||
### Combination B — ASTRAL only (compliance-driven clients)
|
||||
|
||||
Clients with ISO 27001 in progress, DORA obligations, or NIS2 scope often need the config change governance story before they need event correlation. ASTRAL alone answers the auditor's question: "show me every M365 change in the last 12 months with evidence it was reviewed and approved."
|
||||
|
||||
### Combination C — PULSAR only (incident-response or log-retention clients)
|
||||
|
||||
Clients who have had a recent incident and discovered their audit logs were gone, or clients facing insurance requirements for log retention, are natural PULSAR deployments. Value is immediate — longer retention, bulk search, alerting.
|
||||
|
||||
### Combination D — Full stack with AURORA (mature clients, retained relationships)
|
||||
|
||||
Clients who have run PULSAR + ASTRAL for at least one module cycle are ready for AURORA. The upsell requires no education — they already know the cross-tool investigation pain that AURORA removes. AURORA self-hosted is the right recommendation for technically capable clients with data sovereignty requirements. AURORA hosted is the right recommendation for SMBs who want zero operational burden.
|
||||
|
||||
### What to avoid
|
||||
|
||||
Do not lead with AURORA in a first engagement. The value of the cross-tool diagnostics is only legible to clients who have experienced the investigation friction of running PULSAR and ASTRAL separately. Clients who have not felt that pain will not pay for the solution.
|
||||
|
||||
---
|
||||
|
||||
## Deployment Prerequisites
|
||||
|
||||
| Product | Prerequisites |
|
||||
|---------|--------------|
|
||||
| ASTRAL | Azure DevOps organisation, Entra app registration (provisioned by bootstrap script), write access to ADO Git repo |
|
||||
| PULSAR | Docker Compose capable host (or Azure Container Apps for cloud deploy), Entra app registration (provisioned by bootstrap script), MongoDB |
|
||||
| AURORA | Running PULSAR + ASTRAL with MCP servers enabled; AURORA licence key; Docker Compose or Azure Container Apps |
|
||||
|
||||
---
|
||||
|
||||
## Objection Handling
|
||||
|
||||
**"We already have Microsoft Purview / Sentinel."**
|
||||
|
||||
Purview and Sentinel are E5 features — €28+/user/month. The CQRE free stack provides comparable log retention and config governance for the entire engineering cost of deploying it. For clients already at E5, AURORA provides the correlation layer that Sentinel and Purview still do not natively deliver.
|
||||
|
||||
**"We don't want to run our own infrastructure."**
|
||||
|
||||
AURORA hosted solves this. CQRE manages the entire stack. Single tenant starts at €389/month — less than one day of external incident response.
|
||||
|
||||
**"We tried open source tools before and found them too complex."**
|
||||
|
||||
The complexity objection is usually a maintenance objection, not a deployment objection. Address it directly: who will own this after we leave? If the client cannot name a person, the sovereign stack requires a retained capability support arrangement. If they can, the deployment is a few hours of consultant time.
|
||||
|
||||
**"Can we see the code?"**
|
||||
|
||||
ASTRAL and PULSAR are fully open source (MIT licensed) on GitHub. AURORA is commercial source — clients can request a code review under NDA as part of enterprise procurement.
|
||||
|
||||
---
|
||||
|
||||
*For the full sovereign tool stack including third-party open source tools, see [Sovereign Tool Stack](sovereign-tool-stack.md).*
|
||||
*For module pairings and engagement sequencing, see [Modular Engagements](../core/modular-engagements.md).*
|
||||
*For retained capability support arrangements, see [Retained Capability](../core/retained-capability.md).*
|
||||
@@ -129,16 +129,29 @@ This document provides the complete capability map for our consulting practice:
|
||||
|
||||
| Attribute | Detail |
|
||||
|-----------|--------|
|
||||
| **What it does** | Intelligent backup, configuration drift detection, and change management for Microsoft Intune, Entra ID, and M365 tenant configurations. Captures baseline state, detects unauthorised or accidental changes, and enables rapid rollback. |
|
||||
| **Why we built it** | No existing tool treats M365 configuration as code. A tenant with 500 conditional access policies, 200 Intune profiles, and 50 compliance policies is unmanageable without version control and drift detection. ASTRAL provides GitOps for M365. |
|
||||
| **Antifragile pillar** | Structural Decoupling, Stress-to-Signal Conversion |
|
||||
| **What it does** | Git-tracked snapshots of Microsoft Intune and Entra ID configuration with Azure DevOps pipeline-driven drift detection, PR-based review and approval workflow, and baseline restore capability. Answers: *"what does my tenant configuration look like, what changed, and can we revert it?"* |
|
||||
| **Why we built it** | No existing tool treats M365 configuration as code. A tenant with 200 CA policies, 500 Intune profiles, and dozens of authentication methods is unmanageable without version control and drift detection. ASTRAL provides GitOps for M365. |
|
||||
| **Antifragile pillar** | Structural Decoupling (surface hidden dependencies), Asymmetric Payoff Design (high protection from low deployment cost) |
|
||||
| **Engagement modules** | Module 1 (Endpoint Management); Module 2 (Identity Security); Module 3 (M365 Security Hardening); retained capability engagements |
|
||||
| **Typical output** | "Configuration drift detected: 3 conditional access policies modified outside change window; 1 Intune profile deleted; all changes attributable to [admin account]; rollback initiated automatically" |
|
||||
| **Integration** | Feeds change logs into AOC for audit intelligence; exports configuration state to CISO Assistant for compliance evidence |
|
||||
| **Typical output** | Rolling PR: "Drift detected: 3 Conditional Access policies modified outside change window; 1 Intune profile deleted; changes attributed to admin@contoso.com via audit log. Reviewer decision: /accept or /reject." |
|
||||
| **Repository** | [github.com/cqrenet/astral](https://github.com/cqrenet/astral) — free, open source (MIT) |
|
||||
| **Integration** | Entra ID and Intune baseline; feeds CISO Assistant for compliance evidence; AURORA connects to ASTRAL's MCP server for cross-tool diagnostics |
|
||||
|
||||
**What it tracks** (current scope):
|
||||
|
||||
*Intune*: App Configuration, App Protection, Applications, Compliance Policies, Device Configurations, Enrollment Configurations, Filters, Scope Tags, Scripts, Settings Catalog.
|
||||
|
||||
*Entra*: Named Locations, Authentication Strengths, Conditional Access, App Registrations, Enterprise Applications. Admin role assignments and auth methods policies in development (Phase 1 roadmap).
|
||||
|
||||
**Key capabilities**:
|
||||
- Event-driven change probe (Azure Function App) triggers backup within minutes of a tenant change — no more hourly polling
|
||||
- Reviewer `/accept` and `/reject` commands in ADO PR threads; auto-queued restore on rejection
|
||||
- MCP server (Azure Container Apps) exposes tenant state and drift history to AI assistants
|
||||
- Optional Azure OpenAI PR narratives — BYOAI, fully optional, ASTRAL is complete without it
|
||||
|
||||
**The conversation**:
|
||||
|
||||
> *"Your M365 tenant has 400 configuration objects and no version control. When an admin accidentally deletes a conditional access policy at 2 AM, you discover it 6 hours later because users are complaining. ASTRAL detects the deletion in 60 seconds, attributes it to the specific admin session, and offers one-click rollback. This is not backup. This is configuration immunity."*
|
||||
> *"Your M365 tenant has 400 configuration objects and no version control. When an admin accidentally deletes a Conditional Access policy at 2 AM, you discover it 6 hours later because users are complaining. ASTRAL detects the deletion within minutes via its event-driven change probe, attributes it to the specific admin session, and offers one-click rollback through the restore pipeline. This is not backup. This is configuration governance."*
|
||||
|
||||
**ASTRAL companion utilities (CQRE)**:
|
||||
|
||||
@@ -152,20 +165,63 @@ This document provides the complete capability map for our consulting practice:
|
||||
|
||||
### M365 Audit Log Intelligence
|
||||
|
||||
#### AOC — Admin Operations Center (Our Platform)
|
||||
#### PULSAR (Our Platform)
|
||||
|
||||
| Attribute | Detail |
|
||||
|-----------|--------|
|
||||
| **What it does** | Correlates Microsoft 365 Unified Audit Log, Entra ID sign-in logs, and Intune operational logs into actionable intelligence. Detects anomalous admin behaviour, privilege escalation, shadow IT creation, and data exfiltration patterns. |
|
||||
| **Why we built it** | The native M365 audit log is a firehose: 10,000+ events per day in a typical tenant, searchable only via slow PowerShell or expensive Sentinel. AOC extracts the 50 events that matter and enriches them with identity context, device state, and business impact. |
|
||||
| **Antifragile pillar** | Sovereign Intelligence, Stress-to-Signal Conversion |
|
||||
| **Engagement modules** | Module 12 (Blue/Purple Team Foundation); retained capability (Detection Engineering); all M365 hardening engagements |
|
||||
| **Typical output** | Daily brief: "3 anomalous events flagged: Global Admin [X] added external user at 03:14; Exchange Admin [Y] exported 12,000 mailboxes; Service Principal [Z] granted Mail.Read to unverified publisher. All require validation within 4 hours." |
|
||||
| **Integration** | Receives alerts from osquery/FleetDM, Wazuh, and Prowler; pushes cases to CISO Assistant for risk register tracking; enriches AI-assisted TVM with insider-threat context; **MCP server** enables Claude and other AI clients to query audit logs in natural language directly from the analyst's desktop |
|
||||
| **What it does** | Ingests Microsoft 365 admin audit events (Entra, Intune, Exchange, SharePoint, Teams) into MongoDB and exposes a UI, REST API, and MCP server for search, filtering, alerting, and SIEM forwarding. Answers: *"what happened in my tenant, when, and by whom?"* |
|
||||
| **Why we built it** | Native M365 audit log retention is capped at 90 days (E3) or 180 days (E5) — searchable only via slow PowerShell or expensive Sentinel. PULSAR provides permanent retention, fast search, and an MCP interface so AI assistants can query audit history directly. |
|
||||
| **Antifragile pillar** | Stress-to-Signal Conversion — every admin action becomes permanent, searchable signal |
|
||||
| **Engagement modules** | Module 12 (Blue/Purple Team Foundation); retained capability (Detection Engineering); any engagement with log retention requirements |
|
||||
| **Typical output** | UI search: "Show me all Conditional Access policy changes by GlobalAdmin@contoso.com in the last 30 days." MCP query: `search_events(actor="globaladmin@contoso.com", operation="Update conditional access policy", days=30)` |
|
||||
| **Repository** | [github.com/cqrenet/pulsar](https://github.com/cqrenet/pulsar) — free, open source (MIT) |
|
||||
| **Integration** | AURORA connects to PULSAR's MCP server for cross-tool diagnostics; alerting rules forward to webhook endpoints; SIEM forwarding to Sentinel/Splunk *(see maturity note)* |
|
||||
|
||||
**Sources ingested**:
|
||||
- Entra ID directory audit logs
|
||||
- Intune audit logs
|
||||
- Exchange Online, SharePoint, and Teams via the Office 365 Management Activity API
|
||||
|
||||
**MCP tools**: `search_events`, `get_event`, `get_summary` — available over stdio (local) or SSE (remote, with API key or Entra OIDC auth).
|
||||
|
||||
> **Maturity note — alerting and SIEM forwarding**: Both features are functional but proof-of-concept quality, suitable for evaluation and non-critical environments. Alerting has no rule management UI and webhook delivery has no retry logic. SIEM forwarding is basic with no delivery guarantees and is not tested at volume. Do not recommend these features for production use in environments where reliability is required — hardening is on the roadmap. AURORA provides production-grade enriched SIEM forwarding for clients who need it now.
|
||||
|
||||
**The conversation**:
|
||||
|
||||
> *"Microsoft gives you the audit log. They do not give you the story. AOC reads 50,000 events per night and tells you the three that need human attention: an admin added an external user at 3 AM, another exported 12,000 mailboxes, and a service principal granted Mail.Read to an unverified app. These are not false positives. These are the events that precede breaches."*
|
||||
> *"Microsoft gives you the audit log. They also take it away after 90 days. PULSAR keeps it forever. When you have an incident six months from now — and you will — and you need to know who added that external user, who modified that CA policy, and what that service principal was doing at 3 AM the week before the breach — PULSAR answers in seconds. Without it, the question is unanswerable."*
|
||||
|
||||
---
|
||||
|
||||
### M365 Governance Intelligence
|
||||
|
||||
#### AURORA (Our Platform — Paid)
|
||||
|
||||
| Attribute | Detail |
|
||||
|-----------|--------|
|
||||
| **What it does** | A unified operations platform connecting PULSAR and ASTRAL via their MCP servers. Provides AI-assisted cross-tool diagnostics, multi-scope orchestration, and enriched SIEM forwarding that neither product can produce alone. Answers: *"what does it mean and what should I do?"* |
|
||||
| **Why we built it** | Running PULSAR and ASTRAL separately leaves an investigation gap: audit events and configuration state live in different places with no correlation layer. AURORA closes that gap. |
|
||||
| **Antifragile pillar** | Sovereign Intelligence (owned observability and reasoning infrastructure), Optionality Preservation (data stays yours; AI layer is pluggable) |
|
||||
| **Engagement modules** | Retained capability engagements; any client running the full PULSAR + ASTRAL stack |
|
||||
| **Pricing** | Self-hosted: €259/mo (single tenant), €429/mo (≤5 scopes). Hosted: €389/mo, €599/mo. Enterprise: custom. |
|
||||
| **Repository** | [aurora.cqre.net](https://aurora.cqre.net) — commercial, self-hosted or CQRE-managed |
|
||||
|
||||
**Cross-tool diagnostic tools**:
|
||||
|
||||
| Tool | What it answers |
|
||||
|------|----------------|
|
||||
| `diagnose_policy_errors` | "Why is this Intune compliance policy erroring on some devices but not others?" — pulls ASTRAL policy config and PULSAR audit events for the same policy |
|
||||
| `explain_device_compliance` | "Why did this device suddenly become non-compliant?" — combines ASTRAL assignment data with PULSAR event timeline |
|
||||
| `correlate_drift_with_audit` | "Who triggered this configuration drift commit?" — matches ASTRAL Git commits with PULSAR audit events by timestamp |
|
||||
| `tenant_security_summary` | "What happened this week that I should know about?" — combines open ASTRAL drift PRs with PULSAR event summary |
|
||||
| `compare_scopes` | "What's different between my production and development CA policies?" |
|
||||
|
||||
**AURORA stores no data.** All data lives in PULSAR (MongoDB) and ASTRAL (Git) under the client's control. AURORA is purely the query, orchestration, and intelligence layer.
|
||||
|
||||
**When to recommend**: After at least one module cycle with PULSAR + ASTRAL deployed. The upsell is natural — clients who have investigated an incident using both tools separately will immediately understand AURORA's value.
|
||||
|
||||
**The conversation**:
|
||||
|
||||
> *"You have ASTRAL showing you what changed and PULSAR showing you who did what. AURORA answers the question neither product answers alone: are those two things related? Did the admin action in PULSAR trigger the drift commit in ASTRAL? Was that a legitimate change or a compromise? That correlation currently takes 20 minutes of manual investigation. AURORA does it in 30 seconds."*
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user