Building the Box: Hardware Decisions for a Hardened SOC Appliance

Once we had the concept — a pre-configured sensor, shipped to the client, connected to SOC365 — the next question was the obvious one: what does the box actually contain? This is where the engineering work began in earnest, and where we made several decisions that turned out to be more consequential than we expected.

Form Factor: 1U Rack or Desktop

The first decision was physical form. Our target clients — law firms, GP surgeries, small councils, engineering consultancies — have wildly different infrastructure environments. Some have proper server rooms with 19-inch racks. Many don't. A GP surgery typically has a small networking cabinet, if that. A parish council's "server room" is often a cupboard.

We designed the physical appliance to work in both. The same unit can be rack-mounted in a standard 1U bay or deployed as a desktop unit sitting next to a switch. It ships with both a rack kit and rubber feet in the box. No additional hardware required.

The unit is a hardened x86 appliance — fanless where the deployment size allows, with active cooling for larger configurations. Made in the UK. The chassis is designed to be physically unremarkable: nothing about it advertises that it's a security device. In environments where physical security matters, an attacker walking through the office shouldn't immediately identify the most important piece of hardware in the room.

Connectivity: Network Interfaces

Network visibility is everything in a SOC sensor. An appliance that can only see traffic on a single subnet isn't worth shipping. We settled on six internal Ethernet interfaces plus two external, giving the sensor the flexibility to handle segmented networks — separate VLANs for staff, guests, IoT devices, and management — without requiring additional hardware.

In inline deployment mode, the appliance operates as a transparent network bridge, inspecting traffic without introducing a detectable bottleneck. In passive mode, it taps a SPAN port on the client's switch. Both configurations are pre-configured before the unit ships. The client doesn't need to know which mode is appropriate for their setup — that's determined during the scoping call and configured in our workshop.

Storage and Encryption

The sensor stores up to 31 days of telemetry locally — a deliberate design choice that provides a local forensic buffer while keeping cloud egress to a minimum. All data at rest is encrypted with AES-256. All data in transit to SOC365 uses TLS 1.3 with certificate pinning, meaning an attacker who compromises the network between the appliance and the SOC platform cannot intercept or tamper with the telemetry stream.

We spent a significant amount of time on the key management architecture. Hardware Security Module (HSM) integration ensures that encryption keys are never stored in software. This matters particularly for clients in regulated sectors — healthcare, legal, financial services — where the security of the monitoring infrastructure itself has to meet the same standards as the data it's protecting.

The Virtual Appliance

From the outset, we designed SOC in a Box to be deployable as both a physical appliance and a virtual machine. Not as an afterthought — as a first-class deployment option that delivers identical capability.

The virtual appliance is an OVA/VMDK image supporting VMware, Hyper-V, Proxmox, and KVM. Minimum specification is 4 vCPU, 16 GB RAM, and 500 GB storage — well within the capacity of most modern hypervisors. It's available for download within one hour of the scoping call being completed.

The decision to support four hypervisor platforms rather than picking one was driven by what we actually saw in client environments. Enterprise-focused MSSPs typically standardise on VMware. Our clients use whatever they use — and that means a Cambridgeshire law firm on Hyper-V needs to be served as well as an engineering consultancy that's recently migrated to Proxmox.

Pre-Configuration in Our Workshop

This is the part of the hardware process that makes the five-day deployment target achievable. Every appliance — physical or virtual — is fully configured before it leaves our hands. The scoping call on Day 1 isn't just a sales conversation; it's a technical intake. We learn the client's asset count, network topology, device types, cloud services, and sector-specific requirements. That information drives the appliance build on Days 1–2.

By the time the box arrives at the client's premises, it knows what it's looking for. The detection rules are already tuned to the sector. The DLP policies already reflect the data types present in the environment. The deception sensors are pre-positioned for the network topology described in the scoping call. Plug in, call us, and we verify the connection. That's it.

"We've seen vendors turn up on-site for a week to deploy a SOC sensor. Our target was that the client should be able to do it themselves, in under an hour, without reading a manual."

Next week, we'll go deeper into the software side — specifically how we integrated the SOC365 detection engine with the sensor architecture, and what that means for the quality of detections a SOC in a Box client actually receives.