The Same Engine: Integrating SOC365 With a Compact Sensor

The claim we make on the SOC in a Box product page — "identical to full SOC365" — is the kind of statement that needs to be earned, not just written. This week, we want to explain exactly what it means technically, because understanding it is the difference between choosing SOC in a Box with confidence and taking our word for something you can't verify.

What SOC365 Is

SOC365 is the detection and response platform built and operated by Cyber Defence. It's not a white-labelled third-party product with our branding on it. It's ours — developed over several years of running a CREST-accredited SOC for enterprise clients across defence, financial services, critical national infrastructure, and professional services.

At its core, SOC365 is a correlation engine. It ingests telemetry from multiple sources — network traffic, endpoint agents, cloud audit logs, authentication events, DNS queries, threat intelligence feeds — and runs it through a continuously updated rule set to identify patterns that indicate malicious or anomalous behaviour. The rule set is maintained by our threat research team and is informed by our active participation in threat intelligence sharing communities.

Above the correlation engine sits EmilyAI — our triage augmentation layer. We'll cover EmilyAI in detail next week. Below it sits a case management and analyst workflow system designed around how our analysts actually work, not around how a product manager thought they might work.

The Integration Challenge

When we started the SOC in a Box project, our SOC365 deployments assumed high-bandwidth, low-latency connections to client environments, often via dedicated circuits or site-to-site VPN. Enterprise clients have the network infrastructure to support that. A 20-person law firm typically does not.

The sensor had to work reliably over standard business broadband — potentially over a connection shared with normal office traffic, without a dedicated link to our SOC platform. This drove several important design decisions.

Local Processing First

Raw network packet data is voluminous. Sending it across a shared broadband connection would saturate the link and make the sensor immediately visible and disruptive to the client's normal operations. Instead, the sensor performs significant processing locally before transmission: flow analysis, protocol decoding, alert pre-enrichment, and log normalisation all happen on the appliance. What's transmitted to SOC365 is structured telemetry, not raw packets.

This has a secondary benefit: local telemetry is available for forensic analysis even if the SOC365 connection is temporarily interrupted. The 31-day local buffer means a connectivity outage doesn't create a gap in the audit trail.

Selective Telemetry Transmission

Not all telemetry is equally valuable. High-volume, low-signal data — routine DNS queries to known-good resolvers, established connections to cloud services in use by the organisation — can be summarised rather than transmitted in full. High-signal events — authentication anomalies, lateral movement indicators, unusual outbound connections, deception sensor interactions — are transmitted immediately and in full.

The sensor's prioritisation logic is updated alongside the SOC365 rule set. As new threat techniques emerge, the prioritisation logic adjusts to ensure that the telemetry relevant to detecting them is always transmitted without delay.

Detection Rule Parity

When we say SOC in a Box clients get the same detection engine, we mean the same detection rules. Not a subset. Not a lite version. The same SIGMA-based detection logic, updated by the same threat research team, running against the same categories of telemetry.

There is one meaningful difference, and we're transparent about it: the telemetry sources available from a compact sensor on a small network are necessarily a subset of the sources available in a large enterprise deployment with hundreds of endpoints, dedicated security infrastructure, and purpose-built log pipelines. A SOC in a Box deployment doesn't produce Active Directory domain controller logs if the client doesn't have a domain controller. It doesn't produce cloud CASB logs if the client doesn't have a CASB.

What it does produce — network flow data, endpoint telemetry from agents on covered assets, authentication events, DNS queries, syslog from network devices, and Azure/Microsoft 365 audit logs for clients using those services — is the set of sources from which the majority of SMB-relevant detections are derived. We tuned the detection coverage specifically for the data sources available in small and medium environments.

The Azure and Microsoft 365 Integration

A significant proportion of our SOC in a Box clients use Microsoft 365 as their primary collaboration and email platform. Azure Active Directory sign-in logs, Teams activity, SharePoint access, Exchange Online message traces — this telemetry is rich with detection opportunities that many SMBs aren't currently monitoring at all.

SOC365 ingests Microsoft 365 audit logs directly via the Management Activity API. For SOC in a Box deployments, this integration is set up during the scoping call. It means that a business email compromise attempt — a criminal logging in to a staff member's email account from an unusual location — is visible to the SOC analyst within minutes of it occurring, regardless of whether the activity touches the physical network at the client's premises.

Next week, we're going to talk about EmilyAI — the triage augmentation layer that sits between raw alerts and analyst attention. It's possibly the part of the system that makes the most practical difference to the quality of service that SOC in a Box clients receive.