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
@@ -47,7 +47,8 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
|
||||
│ ├── ad-endpoint-hardening.md # On-prem AD, Windows endpoint, hybrid identity
|
||||
│ ├── zero-budget-hardening.md # Maximize existing tool investment
|
||||
│ ├── implementation-playbook.md # Step-by-step operational guide
|
||||
│ ├── sovereign-tool-stack.md # Open-source arsenal and capability map
|
||||
│ ├── cqre-product-suite.md # ASTRAL, PULSAR, AURORA: details, alignment, deployment
|
||||
│ ├── sovereign-tool-stack.md # Full arsenal: CQRE products, open-source, and commercial tools
|
||||
│ ├── privileged-access-architecture.md # PAM: Teleport, Tailscale/Headscale, JIT access (Module 13)
|
||||
│ ├── sovereign-communications.md # Delta Chat chatmail, Matrix/Element, crisis channels (Module 14)
|
||||
│ └── business-case-template.md # Financial justification and ROI framework
|
||||
@@ -68,6 +69,12 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
|
||||
└── assets/ # Diagrams, visuals, and presentation materials
|
||||
```
|
||||
|
||||
## What Is Brownhat?
|
||||
|
||||
Brownhat is the delivery brand for CQRE consulting engagements. The name is a deliberate rejection of the traditional hat colour taxonomy in security (black hat / white hat / grey hat) — our work is not about adversarial simulation or compliance theatre. It is about the unglamorous, practical work of making real environments more resilient: brownfield by design, working with what exists, fixing what matters most.
|
||||
|
||||
The **Brownhat methodology** is the operational posture behind every engagement: move fast, extract value from existing investments, and close existential gaps before they become incidents. The **Brownhat Diagnostic** is the specific entry engagement — a structured NIST CSF 2.0 baseline assessment that every new client completes before any module recommendation is made.
|
||||
|
||||
## Our Posture: Move Fast and Fix Things
|
||||
|
||||
This practice is built on a simple, actionable stance: **move fast and fix things**. We do not wait for perfect plans. We identify the kill chain, extract value from existing investments, and close existential gaps before they become incidents.
|
||||
@@ -92,6 +99,9 @@ Our approach is not an alternative to established frameworks. It is the fastest
|
||||
|
||||
- **[CIS Controls v8](reference/cis-controls-mapping.md)** — IG1 as a non-negotiable 90-day floor, achieved primarily through existing tool configuration
|
||||
- **[NIST CSF 2.0](reference/nist-csf-mapping.md)** — All six functions addressed with emphasis on GOVERN as the missing keystone
|
||||
- **NIS2 (EU 2022/2555)** — Every engagement produces direct evidence for the Article 21 measures: configuration management (ASTRAL), logging and monitoring (PULSAR), access control, and incident detection. Essential and important entities under NIS2 will find the Brownhat module set directly maps to their supervisory obligations.
|
||||
- **DORA (EU 2022/2554)** — ICT change management records (ASTRAL Git trail), incident log retention (PULSAR), and ICT third-party risk governance map onto DORA Articles 10 and 11. Designed for financial entities who need demonstrable controls, not documentation exercises.
|
||||
- **GDPR Article 32** — Continuous configuration governance and audit log retention constitute "appropriate technical measures" under the accountability principle. Evidence produced by ASTRAL and PULSAR is directly usable in DPA and auditor reviews.
|
||||
|
||||
## Quick Start for Executives and Board Members
|
||||
|
||||
|
||||
@@ -1,5 +1,11 @@
|
||||
# About CQRE · Brownhat
|
||||
|
||||
> ⚠️ **TEMPLATE — NOT READY TO SHARE** ⚠️
|
||||
>
|
||||
> This document contains unfilled `[PLACEHOLDER]` sections. **Do not share this file with clients or external contacts until every placeholder has been replaced with real content and all INTERNAL NOTE sections have been removed.**
|
||||
>
|
||||
> To check: `grep -r "\[PLACEHOLDER\]" about-cqre.md` should return no results before this file leaves the repository.
|
||||
>
|
||||
> *This document introduces CQRE and the Brownhat methodology to new clients and new team members. Fill every `[PLACEHOLDER]` section with specific, honest information. Avoid generic consulting language — clients can tell. The sections marked **INTERNAL NOTE** contain guidance for completing the template; remove them before sharing externally.*
|
||||
>
|
||||
> *A Czech-language version of this document is maintained at [about-cqre-cs.md](about-cqre-cs.md).*
|
||||
|
||||
@@ -118,9 +118,11 @@ An organization that outsources its cognition outsources its future. Sovereign i
|
||||
|
||||
### The Argument
|
||||
|
||||
The current AI paradigm is extractive. Every prompt sent to a cloud AI is a contribution to a competitor's training set. Every workflow built on a third-party model is a dependency on an intelligence you do not control, cannot audit, and cannot guarantee will serve your interests tomorrow. This is not a privacy concern. It is a **survival concern**.
|
||||
The current AI paradigm introduces three underappreciated risks. First, **vendor dependency**: every workflow built on a third-party model is a dependency on an intelligence you do not control, cannot fully audit, and cannot guarantee will serve your interests when the vendor's incentives shift. Second, **data residency and audit rights**: even where enterprise agreements prohibit training on your data, you typically cannot verify this independently — and audit rights over model inference are absent from most SLAs. Third, **operational continuity**: cloud AI services can change pricing, degrade quality, or enforce new acceptable-use restrictions at will. Your workflows break on their schedule, not yours.
|
||||
|
||||
Sovereign intelligence is the antifragile response: local models, proprietary data loops, and owned reasoning infrastructure that improves with use rather than leaking value to external platforms.
|
||||
Sovereign intelligence is the antifragile response: owned or auditable models, proprietary data loops, and reasoning infrastructure that improves with use rather than creating dependency. This does not require rejecting all cloud AI. It means treating AI infrastructure with the same dependency analysis you would apply to any critical vendor: map it, stress-test the exit, and ensure you retain options.
|
||||
|
||||
> **Consultant note**: The strongest client argument is not "your prompts are training competitors" — most enterprise agreements explicitly prohibit this, and technically literate clients will push back. The more durable arguments are data residency requirements (NIS2, DORA, GDPR Article 32), audit rights over inference decisions, and operational continuity risk when a critical workflow depends on an endpoint you cannot control. Start there.
|
||||
|
||||
### Antifragile Moves
|
||||
|
||||
|
||||
@@ -34,16 +34,24 @@ An antifragile organization does not merely survive shocks. It **grows stronger
|
||||
|
||||
## The Strategic Mandate: AI Sovereignty
|
||||
|
||||
The current AI paradigm is **extractive**. Every prompt sent to a cloud AI teaches that system how to replace you. By running artificial intelligence on infrastructure you control, you:
|
||||
Cloud AI introduces three risks that most organisations have not priced. **Vendor dependency**: your critical workflows run on an endpoint you cannot audit, cannot predict, and cannot replace overnight. **Data residency and audit rights**: even where enterprise agreements prohibit training on your data, you typically cannot verify this, and regulators increasingly want proof — not assurances. **Operational continuity**: cloud AI services change pricing, restrict acceptable use, and degrade quality on the vendor's timeline, not yours.
|
||||
|
||||
- **Protect your intellectual property** from becoming public training data
|
||||
By running intelligence on infrastructure you control, you:
|
||||
|
||||
- **Retain audit rights** over every inference decision — increasingly required by GDPR, NIS2, and DORA auditors
|
||||
- **Ensure operational continuity** regardless of vendor decisions, geopolitics, or API changes
|
||||
- **Eliminate data residency risk** — EU customers in particular face regulatory requirements that cloud AI processing often cannot satisfy
|
||||
- **Reduce long-term costs** from unpredictable per-token pricing to fixed infrastructure
|
||||
- **Demonstrate regulatory maturity** to auditors who increasingly scrutinize data residency and third-party risk
|
||||
|
||||
> *"If our company's intelligence were a physical pile of cash, would we store it in a public bank that takes a 'training fee' off every dollar and reserves the right to change the currency? Or would we keep it in our own vault?"*
|
||||
|
||||
Local AI is the vault.
|
||||
Local AI — or auditable AI with clear data residency — is the vault.
|
||||
|
||||
## The Regulatory Context
|
||||
|
||||
For organisations operating in the EU, the compliance case is now as compelling as the security case. **NIS2** (in force October 2024) requires essential and important entities to demonstrate configuration management, logging, and incident detection. **DORA** (applying to financial entities from January 2025) mandates ICT change management records and audit log retention. **GDPR Article 32** requires appropriate technical measures that are increasingly interpreted as continuous, evidenced controls — not annual point-in-time reviews.
|
||||
|
||||
Every engagement we deliver produces evidence that maps directly to these requirements. This is not coincidence — it is by design.
|
||||
|
||||
## The 180-Day Commitment
|
||||
|
||||
|
||||
@@ -59,7 +59,8 @@ Operational and persuasion documents used in engagements. **Start every new clie
|
||||
| [AD and Endpoint Hardening](playbooks/ad-endpoint-hardening.md) | On-prem AD, Windows endpoints, hybrid identity | Infrastructure Consultants, Security Engineers |
|
||||
| [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) | Maximize existing tools, minimize new purchases | Consultants, CISOs, IT Managers |
|
||||
| [Implementation Playbook](playbooks/implementation-playbook.md) | Tactical step-by-step delivery guide | Technical Leads, Security Engineers |
|
||||
| [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) | Open-source arsenal: Prowler, BloodHound, CISO Assistant, ASTRAL, AOC, Wazuh, Shuffle | Consultants, CTOs, CISOs |
|
||||
| [CQRE Product Suite](playbooks/cqre-product-suite.md) | ASTRAL, PULSAR, and AURORA: product details, framework alignment, deployment, and positioning | Consultants, Account Managers |
|
||||
| [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) | Full arsenal: Prowler, BloodHound, CISO Assistant, ASTRAL, PULSAR, AURORA, Wazuh, Shuffle | Consultants, CTOs, CISOs |
|
||||
| [Privileged Access Architecture](playbooks/privileged-access-architecture.md) | PAM design: Teleport, Tailscale/Headscale, JIT access, vendor access governance | Security Architects, Infrastructure Consultants, OT Leads |
|
||||
| [Sovereign Communications](playbooks/sovereign-communications.md) | Delta Chat chatmail relay, Matrix/Element, crisis out-of-band channels | CISOs, Operations Leads, Incident Response |
|
||||
| [Business Case Template](playbooks/business-case-template.md) | Financial justification, ROI, risk quantification | CFOs, Boards, Consultants |
|
||||
@@ -125,25 +126,26 @@ Operational and persuasion documents used in engagements. **Start every new clie
|
||||
|
||||
8. [NIST CSF 2.0 Baseline Assessment](assessment-templates/nist-csf-baseline.md) — run this first with every new client (the Brownhat Diagnostic)
|
||||
9. [Modular Engagements](core/modular-engagements.md) — the full module menu (Modules 1–14) and platform adaptation guide
|
||||
10. [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) — the full arsenal: CQRE tools, open-source stack, commercial partnerships, and when to use each
|
||||
11. [M365 E3 Hardening](playbooks/m365-e3-hardening.md) — primary client environment for MS clients (most are E3)
|
||||
12. [AD and Endpoint Hardening](playbooks/ad-endpoint-hardening.md) — on-premises identity and endpoint depth
|
||||
13. [Privileged Access Architecture](playbooks/privileged-access-architecture.md) — Module 13: Teleport, Tailscale/Headscale, JIT access, vendor remote access governance
|
||||
14. [Sovereign Communications](playbooks/sovereign-communications.md) — Module 14: Delta Chat chatmail relay, Matrix/Element, crisis out-of-band channels
|
||||
10. [CQRE Product Suite](playbooks/cqre-product-suite.md) — ASTRAL, PULSAR, and AURORA: what they do, how they fit the framework, and how to deploy them
|
||||
11. [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) — the full arsenal: CQRE tools, open-source stack, commercial partnerships, and when to use each
|
||||
12. [M365 E3 Hardening](playbooks/m365-e3-hardening.md) — primary client environment for MS clients (most are E3)
|
||||
13. [AD and Endpoint Hardening](playbooks/ad-endpoint-hardening.md) — on-premises identity and endpoint depth
|
||||
14. [Privileged Access Architecture](playbooks/privileged-access-architecture.md) — Module 13: Teleport, Tailscale/Headscale, JIT access, vendor remote access governance
|
||||
15. [Sovereign Communications](playbooks/sovereign-communications.md) — Module 14: Delta Chat chatmail relay, Matrix/Element, crisis out-of-band channels
|
||||
|
||||
**Reference when needed:**
|
||||
|
||||
15. [AI Sovereignty Framework](core/ai-sovereignty-framework.md) — persuasive arguments and objection handling
|
||||
16. [AI Operations Inevitability](core/ai-operations-inevitability.md) — why defensive AI is not optional
|
||||
17. [Organizational Resilience](core/organizational-resilience.md) — shift left and Dev/Sec/Ops merger talking points
|
||||
18. [Retained Capability](core/retained-capability.md) — what to keep in-house when outsourcing SOC, pentest, compliance
|
||||
19. [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) — extract value from existing tools in 30 days
|
||||
20. [Zero-Budget Vulnerability Discovery](playbooks/zero-budget-vulnerability-discovery.md) — script-based and osquery-based discovery before scanner procurement
|
||||
21. [Osquery: The Sovereign Discovery Platform](playbooks/osquery-custom-platform.md) — build owned vulnerability and asset inventory capability
|
||||
22. [Rapid Modernisation Plan](playbooks/rapid-modernisation-plan.md) — structured engagement roadmap
|
||||
23. [Implementation Playbook](playbooks/implementation-playbook.md) — tactical delivery guidance
|
||||
24. [Vertical: Power and Utilities](reference/vertical-power-utilities.md), [Vertical: Telco](reference/vertical-telco.md), or [Vertical: Banking](reference/vertical-banking.md) — sector-specific adaptations
|
||||
25. [CIS Controls Mapping](reference/cis-controls-mapping.md) and [NIST CSF Mapping](reference/nist-csf-mapping.md) — standards alignment for auditors and regulators
|
||||
16. [AI Sovereignty Framework](core/ai-sovereignty-framework.md) — persuasive arguments and objection handling
|
||||
17. [AI Operations Inevitability](core/ai-operations-inevitability.md) — why defensive AI is not optional
|
||||
18. [Organizational Resilience](core/organizational-resilience.md) — shift left and Dev/Sec/Ops merger talking points
|
||||
19. [Retained Capability](core/retained-capability.md) — what to keep in-house when outsourcing SOC, pentest, compliance
|
||||
20. [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) — extract value from existing tools in 30 days
|
||||
21. [Zero-Budget Vulnerability Discovery](playbooks/zero-budget-vulnerability-discovery.md) — script-based and osquery-based discovery before scanner procurement
|
||||
22. [Osquery: The Sovereign Discovery Platform](playbooks/osquery-custom-platform.md) — build owned vulnerability and asset inventory capability
|
||||
23. [Rapid Modernisation Plan](playbooks/rapid-modernisation-plan.md) — structured engagement roadmap
|
||||
24. [Implementation Playbook](playbooks/implementation-playbook.md) — tactical delivery guidance
|
||||
25. [Vertical: Power and Utilities](reference/vertical-power-utilities.md), [Vertical: Telco](reference/vertical-telco.md), or [Vertical: Banking](reference/vertical-banking.md) — sector-specific adaptations
|
||||
26. [CIS Controls Mapping](reference/cis-controls-mapping.md) and [NIST CSF Mapping](reference/nist-csf-mapping.md) — standards alignment for auditors and regulators
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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