Our platform
Our own single-agent endpoint security software. Prevention and detection in one runtime, one kernel footprint, one console — deployable in the cloud, on-premises or fully air-gapped.
Our own security software for computers, servers and phones. One program on the machine does everything: it blocks dangerous programs from running, watches what every program actually does, and can shut a machine off from the network the moment something goes wrong. It works the same whether it is managed over the internet, kept entirely inside your building, or running somewhere with no network connection at all.
This is a product, not a project. Where our engineering services build you something bespoke, the Endpoint Defense Platform is the system we already own, maintain and deploy — and the one our managed service runs on.
CerbaCore publishes two platforms and one relevant service, and they are easy to confuse. The distinction is worth thirty seconds:
| Offering | What it is | Choose it when |
|---|---|---|
| Endpoint Defense Platform (this page) | Our productized EPP + EDR agent and console | You want proven endpoint security software you can deploy now |
| Adaptive AI engine | The behavioral model ensemble that produces this platform's verdicts | You want to understand how detection decisions are actually made |
| Custom EPP/EDR engineering | A bespoke build for constraints no product satisfies | Air-gapped, embedded, unsupported OS, or you need to own the source |
The engine is not sold separately and the platform is not sold without it. They are one system described from two angles, because buyers ask two different questions about it.
Prevention and detection share a single driver, a single update channel and a single configuration. Two security agents on one host is not defense in depth — it is contention over the same kernel hooks, and on older Windows builds it is a bugcheck. Everything below is delivered by that one runtime.
Prevention is layered and ordered by cost. Each gate only evaluates what the previous one could not decide, which is what keeps behavioral analysis affordable across a large fleet.
| # | Gate | What it stops | Where it is weak |
|---|---|---|---|
| 1 | Device and media control | Unapproved USB storage, Bluetooth transfer, unsigned mounts | Nothing, if policy is set to audit rather than block |
| 2 | Application control | Anything not on the allow-list — by publisher, path or hash | Environments where users legitimately run unknown binaries |
| 3 | Reputation and signature | Known-bad hashes, revoked certificates, indicator feeds | Anything never seen before — by definition |
| 4 | Static machine learning | Novel files whose structure resembles malicious families | Living-off-the-land, where the binary is genuinely legitimate |
| 5 | Exploit mitigation | Return-oriented programming, heap spray, stack pivot, unbacked execution | Logic flaws that need no memory corruption |
| 6 | Script and interpreter inspection | Malicious PowerShell, macros, JScript — content inspected after de-obfuscation | Interpreters without a scan interface on that OS |
| 7 | Behavioral runtime | Sequences that are malicious regardless of which binary performs them | Activity that closely resembles your legitimate normal |
Gates 1 and 2 are the two most organizations never enable, and they are the two that stop the most with the least cleverness. We turn them on in audit mode during the pilot precisely so the argument about enabling them is settled with your own data.
Eight classes of event are collected and bound into a process tree at the point of capture, not reassembled later by a query. The tree is the product. A flat event log can tell you a process ran; only a lineage can answer what it did next, which is the question every investigation actually asks.
| Signal | Why it is collected |
|---|---|
| Process create, exit, command line | The spine of every investigation |
| Image and module load | Catches search-order hijacking and unsigned modules in signed processes |
| File create, write, rename, delete | Ransomware staging, tooling drop, log destruction |
| Registry, launchd, cron, systemd unit writes | Persistence, across all three OS families |
| Network connect, DNS, listening sockets | Command-and-control, lateral movement, exfiltration |
| Authentication and token use | Credential theft and misuse, which rarely involves malware at all |
| Memory region protection change | Injection, hollowing, execution from unbacked pages |
| Script block content, post-de-obfuscation | The actual script, not the encoded wrapper |
Hot storage of 30 days is queried instantly. Warm storage to one year is queried with latency. Cold retention is set by your policy, and in regulated estates by your regulator. What you can answer during an incident was decided months earlier by this setting — which is why we treat it as an architecture question at design time, not a storage-cost question at renewal.
Automation is authorized per rung and per asset class, never globally. A workstation may be isolated automatically at high confidence; a domain controller or an infusion pump never is. That granularity is the difference between automation that survives its first false positive and automation that gets switched off in week two.
Host isolation keeps the agent connected while cutting everything else, so an analyst can still investigate and release the machine remotely. Isolation that also cuts your own access forces a desk visit and gets used far less than it should be.
| Capability | Windows | macOS | Linux | Embedded / IoT |
|---|---|---|---|---|
| Prevention gates 1–7 | All seven | 1–5, 7 | 2–5, 7 | 3, 7 only |
| Kernel-level telemetry | Driver | System extension | eBPF | Userspace sensor |
| Script inspection | Full (AMSI) | Partial | Shell only | Not available |
| Memory scanning | Full | Restricted by the OS | Full | Not available |
| Host isolation | Yes | Yes | Yes | Network-side only |
| Typical footprint | 250 MB | 250 MB | 180 MB | 32 MB |
macOS restricts what any vendor may do in memory, and no product should imply otherwise — parity claims across operating systems are a reliable sign a datasheet was written by marketing. On embedded targets we run a sensor rather than an agent, and pair it with network-side enforcement.
The agent decides locally in every topology. Losing the console degrades reporting and content updates; it never degrades protection. A platform that needs a cloud round trip to reach a verdict fails exactly when an adversary cuts the link — which is the first thing a competent one does.
| Target | Memory | CPU steady | CPU scan | Telemetry per day |
|---|---|---|---|---|
| Workstation | 250 MB | < 1% | < 15%, capped | 40–120 MB |
| Server | 400 MB | < 1% | < 10%, capped | 100–400 MB |
| Embedded sensor | 32 MB | < 2% | no scanning | 2–8 MB |
These are contractual, not aspirational. An agent over its envelope is a defect, because the first thing an overloaded team does is uninstall whatever is making machines slow.
| Layer | What it does |
|---|---|
| SIEM / data lake | Normalized event export, so your correlation rules keep working |
| Network access control and routers | Drives VLAN quarantine — see segmentation |
| Identity provider | Session revocation and account disablement as response actions |
| Ticketing | Detection to ticket with the process tree attached, not a bare alert ID |
| Vulnerability pipeline | Installed-software inventory feeds reachability scoring |
Bring us the estate you actually have — mixed OS fleets, ageing routers, unmanaged IoT — and we will tell you what can be unified under one agent and what needs custom work.