Technical
What Vanguard is actually built on
How the platform is engineered and operated: the detection pipeline, tenant isolation, and the discipline around change. Written for the technical evaluator who has to recommend it.
Position
Engineered as one operated system
Security capability is usually acquired one product at a time, and the integration cost is discovered afterwards. Vanguard is engineered as a single operated system, which is why its parts agree with each other and why a critical alert means the same thing in every surface you look at.
The value is not in any individual component. It is in the integration, the detection content written for your environment, the tuning, the tenant isolation, the operational discipline around change, and the analysts who use it. A collection of security tools is not a security operations platform, in the same way that a pile of bricks is not a building.
We do not publish the specific detection tooling the centre runs on. Naming it tells an attacker which detections to expect and which evasions are worth attempting. Customers and their technical evaluators receive that detail under agreement during procurement.
Engineering principles
Verify before changing production
Findings are established by multiple independent methods with a control case. A check that returns the same answer for a positive and a negative case proves nothing and is treated as broken.
Nothing exposed that need not be
Component interfaces are bound to loopback or private networks and reached through an authenticated reverse proxy or VPN. Only what must be public is public.
Change is recorded
Detection and configuration changes go into an append-only changelog with the verification method used and the residual risk accepted.
Never silence a failing check
If a check fails, the cause is established before anything is edited to make it pass. The check is usually telling the truth.
Detection pipeline
How an event travels through the platform
Each stage is separately verifiable, which is what makes it possible to prove the platform is working rather than assume it.
Collection
Endpoint agents, syslog collection, cloud connectors
Agents on servers and workstations, plus syslog and API collection from network devices, firewalls and cloud workloads.
Normalisation
Custom decoders, version-controlled and reviewed
Decoders parse each source into a consistent schema so events from different systems can be compared and correlated.
Detection
Correlation engine, environment-specific ruleset, MITRE ATT&CK mapping
A maintained ruleset plus environment-specific rules, each mapped to MITRE ATT&CK at authoring time.
Network analysis
Signature inspection, protocol metadata extraction
Signature-based intrusion detection alongside protocol metadata, feeding the same central pipeline.
Enrichment
Indicator matching, reputation lookups, workflow automation
Reputation, indicator matching and asset context attached automatically before an analyst sees the event.
Case management
Case management system of record
Qualifying alerts become tracked cases with a documented outcome, which is also what monthly reporting is generated from.
Investigation
Remote artefact collection, fleet-wide query
Remote forensic collection and fleet-wide querying, so an alert becomes an answer about scope.
Assurance
Self-monitoring heartbeat, verification harness
A heartbeat verifying every component is both alive and ingesting, plus infrastructure and certificate monitoring.
Components are introduced one at a time, each with its own tuning window. Enabling several detection sources in the same week produces an unreadable alert stream, and a stream nobody reads is worse than no stream at all.
Multi-tenancy
Isolation designed in, then proven by test
Every organisation is a separate tenant from the moment it is onboarded. Each has its own agent group, its own data separation, and access rules restricting its users to its own data.
Isolation is verified rather than assumed. The test is to authenticate as a tenant user, attempt to read another tenant’s data, and assert that it fails. Reading the configuration and concluding that it looks correct is not a test, and configurations that look correct while being wrong are common.
A dedicated detection fires if any query or request crosses a tenant boundary, so an isolation failure would surface as an alert rather than as a discovery during an audit.
Access model
- Customer users reach only their own organisation.
- Analysts reach only the organisations they are assigned to.
- Administrative access is separate, audited and restricted to private networks.
- Vendor interfaces are never exposed directly to customers.
- Every access decision is logged and retained.
Customers reach Vanguard through our own interface, not through the underlying vendor consoles. Vendor interfaces leak cross-tenant structure and cannot be safely restyled per organisation.
Deployment
Sized for the estate, split for capacity
The platform runs consolidated for smaller deployments and separates into distinct tiers as volume requires. We split for measured capacity limits, never for architectural elegance.
A consolidated deployment with every component bound to loopback behind a single reverse proxy presents a materially smaller attack surface than four hosts communicating across a network that then has to be secured. Distribution is added when a real bottleneck appears - typically indexer memory - rather than in anticipation of one.
Separate tiers for the SIEM, network security monitoring, forensics, threat intelligence and automation are used where scale, trust boundaries or failure domains justify them.
Get started
Technical questions we have not answered here?
We are happy to go deeper with your technical team - detection coverage, data handling, deployment topology or integration with what you already run.