This article is intended for technical readers.
What’s described here is not a roadmap, nor a demo. It’s what we deliver today.
The Hoxey architecture consists of 6 “not-so-micro” services, each handling specific tasks in isolation and with finetuned interactions.
For further information about the security model, you can read this article
Orchestrator
The Orchestrator is the heart of the service; it’s the ultimate decision-maker and source of truth.
The goal of the Orchestrator is to set up Device→Honeypot pairings.
To do so, the Orchestrator:
- Waits for a pairing request from a Device
- Validates the request against a set of parameters
- Gathers the correct configuration and Honeypot Template from the database
- Generates two pairs of encryption keys for the virtual tunnel
- Chooses the most appropriate Hypervisor to provision on
- Provisions the desired VM from the template, injecting the configuration
- Once ready, answers the initial Device’s pairing request with the configuration to use for the tunnel
The Orchestrator is also responsible for managing and keeping track of Devices’ and Hypervisors’ health.
Dashboard
The Dashboard is the multi-tenant administrative panel for Hoxey staff and customers.
The goal of the Dashboard is to manage anything customer-related. It acts as an interface between the humans and the Orchestrator.
More specifically, the Dashboard is responsible for:
- Receiving and filtering security Alerts from Honeypots
- Handling additional push notification channels, like Teams, Slack, Telegram and more
- Managing Honeypots, from selecting templates, integrations and customization to status and health
- Managing billing and payments
- Adding and managing additional accounts.
Customers and staff cannot connect directly to the Orchestrator, their requests have to be first validated from the Dashboard and ultimately forwarded to the Orchestrator with a secret API Key.
Hypervisors
Hypervisors are the workhorses; they host Honeypot VMs.
Given their job - hosting potentially intruder-infested honeypots - they are treated as untrustworthy.
They hold no secrets and cannot communicate with any other element of the infrastructure. They can only execute orders from the Orchestrator.
Hypervisors are not clustered, as the compromise of one could cascade to the others in a domino effect. Yet they still provide High Availability not by migrating VMs, but by letting the Orchestrator re-provision the VM on another peer.
Device
The Device’s role is to make the remote, cloud-hosted Honeypot VM appear to be inside your Local Network, while in reality it’s securely isolated and quarantined on a Hypervisor.
This is done thanks to the encrypted, one-way L3 virtual tunnel. This solution is the core of our security model and uses proprietary and patent pending algorithms. It’s what initially started Hoxey!
The Device is a special component, as it takes orders from none, not even the Orchestrator.
While the Orchestrator can deny a request from a Device, it cannot force it to do anything.
The Device is proactively contacting the Orchestrator making requests or notifying it of events, but it NEVER, EVER gets requests on its own. The Device only receives answers.
This means the Device is fully isolated, it does not suffer supply-chain like attacks. We don’t even hold the keys to the device, and if we did, we’d have no way of using them because the device denies any connection.
The whole Hoxey Infrastructure is built with the Orchestrator at the core, but the sole purpose is to serve the Devices’ requests - Yes, the small appliance we ship to you!
Virtual Machines
The VMs are the actual Honeypots. They run inside the Hypervisor and they are provisioned from pre-made templates.
Honeypots are ephemeral, they are temporary copies of real systems and leave no traces. They are disposable by design.
They are also fully customizable through the initialization script, this allows third party agents and syslog collectors to forward events to virtually any other security system.
Another advantage is centralized management: we can update the whole fleet in minutes and optimize resource consumption.
The Honeypot VM appears to be inside your network, and it's fully interactive and exploitable.
They are designed to keep intruders busy and waste their time.
Detection Engine
The Detection Engine is a custom-built security software designed to detect attacks to the Honeypots.
Unlike standard security systems, like SIEM agent collectors, Hoxey’s Detection Engine is specifically built to operate inside a Honeypot and reduce the noise and false positives to nearly zero. It’s small, but powerful.
Most competitors use two components, honeypots directly running on bare-metal and a dashboard for alerts.
Our patent pending architecture is designed from the ground up with a Zero-Trust philosophy to protect the customers from pivoting, while providing flexibility and plenty of features either not available or behind costly upsells from competitors.
Our mission is serving the SMB market with a largely affordable solution that doesn't sacrifice security and detection/deception capabilities.