Unified EPP + EDR Platform

• Single agent
• Behavioral ML
• Windows / macOS / Linux
• Embedded & IoT

EPP and EDR shipped as separate products for a decade. They no longer should. CerbaCore builds and deploys a single-agent platform that does prevention and detection-and-response together, so your analysts stop correlating two consoles by hand.

What the two layers actually do

The distinction still matters technically even when the agent is unified, because the two layers fail in different ways and are tuned against different questions.

Layer	Question it answers	Acts	Failure mode
EPP — Endpoint Protection Platform	Is this known-bad, or close enough to known-bad to stop?	Before execution	Misses novel and living-off-the-land technique
EDR — Endpoint Detection and Response	What did this process actually do, and what did it touch next?	During and after execution	Drowns the SOC in telemetry nobody triages

Run EPP alone and you are blind to anything that gets past the first gate. Run EDR alone and you are investigating incidents you could have prevented. Run them as two products from two vendors and you inherit two agents fighting over the same kernel hooks.

Architecture

How we build it

One agent, one kernel footprint

Prevention and telemetry share a single driver and a single update channel. Two security agents on one host is not defense in depth — it is a support ticket waiting to happen, and on older Windows builds it is a bluescreen.

Behavioral detection, not signature lists

Detection is driven by process lineage, syscall patterns and memory behavior rather than file hashes. That is what catches fileless technique, credential dumping and ransomware staging that has never been seen before.

Coverage that matches your estate

Laptops and servers are the easy part. We extend the same telemetry model to the machines that usually go unmonitored: build servers, jump hosts, ruggedised field devices and IoT endpoints where a full agent will not fit and a lightweight sensor has to do.

Response that reaches past the endpoint

A detection that only quarantines a file is half a response. Ours hands off to the network layer — see zero-trust segmentation — so a compromised host is moved into an isolated VLAN by the router, not just flagged in a console.

Deployment

• Estate survey. Every OS build, kernel version and existing agent, including the machines nobody on the org chart owns.
• Pilot ring. A representative slice — not just IT laptops — with prevention in detect-only mode while we baseline normal behavior.
• Tuning. Suppressing the noise your environment generates legitimately. This is the step most rollouts underfund and it is the one that decides whether the SOC trusts the tool.
• Enforcement. Prevention moved to blocking, ring by ring, with rollback at each gate.
• Handover. Runbooks, detection documentation and analyst training, or ongoing co-management if you would rather we ran it.

Reference architecture

The agent is not a monolith. It is four components with deliberately separated failure domains, so that losing one does not disarm the others.

Component responsibilities

Component	Runs in	Job	If it fails
Kernel driver / eBPF probe	Kernel	Syscall, process and file hooks	Telemetry stops. Fail-open by design — a kernel component that panics is worse than blind.
Memory scanner	User, elevated	Injection, hollowing, unbacked executable pages	Fileless technique becomes invisible; disk-based detection continues.
Ring buffer	Kernel/user shared	Absorbs burst without blocking the hooks	Oldest events drop. Never blocks the kernel path — that would freeze the host.
Local decision engine	User, protected	Evaluates rules and models on-host	Falls back to cloud verdicts; blocking latency rises.

Resource envelope we design to

Target	Memory ceiling	CPU (steady)	CPU (scan)	Telemetry/day
Workstation	250 MB	< 1%	< 15% capped	40–120 MB
Server	400 MB	< 1%	< 10% capped	100–400 MB
Embedded / IoT sensor	32 MB	< 2%	n/a — no scanning	2–8 MB

These are contractual, not aspirational. An agent that exceeds its envelope is a defect, because the first thing an overloaded team does is uninstall the thing making the machine slow.

How a detection is actually decided

Gate ordering is an economic decision as much as a security one. Hash and IOC matching costs microseconds and eliminates the commodity majority. Sequence modelling costs milliseconds. Environment anomaly scoring is the most expensive and runs on the smallest remaining slice.

Worked example — ransomware staging on a finance workstation

A user opens a macro-enabled attachment. Nothing in the chain is known-malicious.

1. t+0ms — Process spawnWINWORD.EXE spawns powershell.exe with an encoded command. Not blocked: legitimate templates do this. Recorded.
2. t+40ms — NetworkPowerShell resolves a domain registered four days ago. Reputation is unknown, not bad. Score rises.
3. t+900ms — InjectionA payload writes into explorer.exe address space from an unbacked page. The memory scanner flags this. Sequence model now has Office → PowerShell → injection, a pattern with high malicious weight.
4. t+1.1s — Shadow copiesvssadmin delete shadows is invoked. This has almost no legitimate use on a finance workstation. The environment model has never seen it on this host.
5. t+1.1s — VerdictCombined score crosses the high-confidence band. The local engine terminates the process tree, quarantines the artifact, and snapshots memory before killing it.
6. t+1.3s — Network containmentThe signal reaches the NAC layer and the host moves to a quarantine VLAN. See zero-trust segmentation.
7. t+4s — AnalystAn alert arrives describing a device that is already contained, with a full process tree and the memory snapshot attached.

No signature existed for any artifact in that chain. Every step of the decision was behavioral.

Deployment

What each gate actually tests

Gate	Pass condition	Typical blocker
0 → 1	Agent stable 7 days, no kernel faults, envelope held	Conflict with an existing agent
1 → 2	False-positive rate < 1 per 100 hosts per week	Developer tooling flagged as injection
2 → 3	One full business cycle clean, including month-end	Month-end batch jobs look like exfiltration
3 → 4	Response runbook exercised on a real detection	Nobody has tested the release path

EDR vs XDR vs MDR — what the acronyms actually mean

These three get used interchangeably in sales conversations and they are not the same kind of thing. Two are products and one is a service.

	EDR	XDR	MDR
What it is	Product	Product	Service
Scope	Endpoints only	Endpoint + network + cloud + identity, correlated	Either of the above, operated for you
Who watches it	Your team	Your team	Someone else's analysts
Needs	Staff to triage	Staff, plus integration work	A contract and defined response authority
Fails when	Nobody reads the console	Sources are connected but never correlated	Tuning is generic across the provider's book

The practical question is not "EDR vs XDR" — it is whether you have anyone to watch it. An organization without a security team buying XDR has bought a more expensive console nobody opens. That is the case for managed detection and response.

EDR for small business

Smaller organizations face the same adversaries with none of the staffing, and the common failure is buying a capable platform, deploying it at vendor defaults and effectively abandoning it within months. Our approach for small estates is the same technical architecture, tuned before handover, with automated containment set conservatively so the routine cases resolve without a human at 2am. See small and mid-sized business.

Failure modes we design against

• Agent conflict. Two products hooking the same kernel paths. We inventory and remove before install, never alongside.
• Update bricking. Content updates are ringed exactly like the rollout, and the agent retains the last known-good content set to roll back to without a network round trip.
• Tamper. Self-protection prevents service stop and file deletion, including by local administrators — with a documented, audited break-glass path for the cases where it is legitimate.
• The silent uninstall. Console coverage is reconciled against your asset inventory weekly. A fleet that reports 98% coverage while 200 hosts silently stopped checking in is the most common real-world failure, and it is an inventory problem, not a product one.