Endpoint security
The CyberOptix CTEM Platform does not ship its own endpoint agent. It connects to the EDR you already run and brings its devices, alerts and findings into the same place as everything else.
That is the value: endpoint data stops being a separate console. A device here carries the same business unit, tags and findings model as every other asset, so "Critical findings in Payments" includes laptops.
Connected vendors
| Vendor | Brings |
|---|---|
| CrowdStrike | Devices and alerts |
| SentinelOne | Agents and threats |
| Carbon Black | Devices, alerts, vulnerabilities, watchlists |
| Microsoft Defender | Devices, per-device vulnerabilities, software inventory, security recommendations |
Connect one under Integrations.
The device list is vendor-agnostic
The main device view is a single list across every connected vendor. If you run more than one EDR - common after an acquisition, or mid-migration - this is where the estate is actually visible as one thing.
SCREENSHOT: the vendor-agnostic device list.
Each vendor's own views remain available underneath, because they carry detail the common shape does not:
- Defender contributes software inventory and security recommendations, which is closer to vulnerability management than to detection.
- Carbon Black contributes watchlists and its own vulnerability data.
- SentinelOne models threats per agent.
- CrowdStrike contributes devices and alerts.
What to do with it
Find the gap. The most useful first query is which assets have no EDR agent. Compare the device list against your broader asset inventory - hosts discovered by scanning or by a cloud integration that never appear here are either unmanaged or running an agent that is not reporting. Both are worth knowing, and neither is visible from inside the EDR console, which only knows about machines it already manages.
Use Defender's vulnerability data if you run it. Per-device vulnerabilities and software inventory give you patch-level exposure on endpoints, which network scanning generally cannot see.
Pivot from an alert. An endpoint alert names a device; the device names its other findings, its owner, and where it sits.
Response
Endpoint response actions are driven from Monitor and respond, where isolation, blocking, account disabling and quarantine are recorded as incident sub-statuses. What is actually available depends on the vendor and on the permissions the integration was granted.
If a guardrail cannot be evaluated, the action proceeds with its safety check skipped rather than being blocked. An alert is raised for exactly that case and is the only signal the constraint did not apply. See Monitor and respond.
API
The endpoints behind this section are in the API reference.
Next
- Monitor and respond - alerts and response
- Integrations - connecting an EDR vendor
- Assets - how devices relate to other asset views