Skip to content
IRONVEIL

IRONVEIL / RESEARCH & DEVELOPMENT

Two active programs.

We keep a research line running alongside client work. Both programs below are under investigation rather than for sale, and both are described here at the stage they are actually at.

Neither has been through third-party review. Where we have measurements, they come from our own lab under conditions we chose, which is a weaker claim than it sounds and we would rather say so than imply otherwise.

  1. PROGRAM 01

    HOLLOW

    Security operations tooling that rebuilds its own compromised hosts. Working lab build.

  2. PROGRAM 02

    Privacy-preserving communications

    How much metadata leakage a usable messaging system can shed. Simulation only.

PROGRAM 01 · HOLLOW — ACTIVE RESEARCH

A small security operations stack that rebuilds its own compromised hosts.

HOLLOW is an assembly of open-source security tools — detection, threat intelligence, firewalling, and workflow automation — provisioned as code onto a virtualization host and wired so that detection, enrichment, and response happen without someone reading a dashboard first. We name specific components in the design document rather than here, because we replace them as better ones appear.

The name is the design decision: hosts are treated as disposable. A host that trips two independent high-confidence signals is snapshotted for forensics, destroyed, and rebuilt from the same definitions that created it. Nothing gets patched in place and trusted afterward.

It runs as a set of VMs on the same stack as WASP, or on a standalone node if you would rather keep security tooling off the hosts it watches. We recommend the second.

STATUS — READ THIS FIRST

  • Working build, running in our lab on a single node. Under active research: no production deployments and no paying users.
  • Lab node: 16-core CPU, 64 GB DDR4, NVIDIA H200 for local model inference. Everything below was observed on that one machine, under synthetic attack traffic we generated ourselves, not client load.
  • We are not publishing detection rates, response times, or uptime figures. We have numbers from the lab, but one node under traffic of our own making is not evidence about your network, so quoting them would be dishonest.
  • Licensing is undecided. If it ships open, it ships the way WASP did, with the threat model in the repo.

ARCHITECTURE

Nine layers. Each row lists what runs there and what it is responsible for; the stage number marks where it sits in the path from signal to response.

  1. 01

    Infrastructure

    infrastructure-as-code · virtualization · configuration management

    Every VM and network is defined in version control. Rebuilding a host is running the same definition again, which is what makes destroy-and-replace a viable response instead of a last resort.

  2. 02

    Detection

    host agents · network inspection · firewall policy

    Host agents for file integrity and log collection, network inspection at the segment boundary, firewall policy as the enforcement point. Two independent signals per event, so a single noisy rule cannot drive a rebuild on its own.

  3. 03

    Deception

    honeypot services · session logging

    Services that exist only to be touched. Nothing legitimate connects to them, so a connection is a high-confidence signal rather than something to correlate. This is the cheapest true positive in the stack.

  4. 04

    Threat intelligence

    indicator store · public threat feeds

    Indicators from public feeds and from your own incidents, used to add context to an alert. Enrichment tells you whether an address is already known. It does not tell you whether the alert was real.

  5. 05

    Orchestration

    automation tooling · local language model

    Workflows are explicit and readable: this alert, these conditions, that action. A locally hosted model reads the logs and scan findings behind an alert, names the flaw it thinks caused it, and either presents the remediation for approval or applies it directly when that class of fix is on an approved list. Anything outside the list is proposed, not performed.

  6. 06

    Ephemeral tooling

    containers · OSINT collection · memory and disk forensics

    Analysis tools run in containers created for one job and destroyed after. Malware analysis and OSINT collection are the tasks most likely to end badly, so they get the shortest lifetime and the least network access.

  7. 07

    Response

    firewall rules · chat and email notification

    Automatic actions are limited to ones that are cheap to undo: block an address, isolate a segment, page a human. Anything destructive waits for a person. Every action is logged with the alert that caused it.

  8. 08

    Rebuild and recovery

    Snapshots · offsite replication · restore tests

    Snapshot first for evidence, then rebuild from source. Backups replicate offsite and are restored on a schedule into a scratch VM, because an untested backup is a guess. Rebuilding alone would restore the host and leave the flaw, which is why the orchestration layer has to identify and close the cause.

  9. 09

    Validation

    attack tooling · scripted playbooks

    Scripted attacks run against the stack on a schedule to check that detections still fire and workflows still complete after changes. A detection nobody exercises is a detection you do not have.

SIZING

Driven by log volume rather than license tiers. Three configurations we design against; our lab node sits at the bottom of the middle one.

SMALL · UNDER 50 ENDPOINTS

  • 8 cores, 32 GB ECC
  • ~10 GB of logs a month, 7-day retention
  • Three network segments
  • No redundancy. One host, one point of failure.

MID · 50–500 ENDPOINTS

  • 16–24 cores, 64–128 GB
  • ~100 GB a month, 30-day retention
  • Five or more segments, split by role
  • Two-node cluster, firewall failover

LARGE · 500+ ENDPOINTS

  • 32+ cores, 256 GB or more
  • 1 TB+ a month, 90-day retention or longer
  • Ten or more segments, micro-segmented
  • Three-plus nodes, distributed storage

DISCONNECTED ENVIRONMENTS

Air-gapped controls, OT segments, and legacy equipment are where most monitoring stops, because most collectors assume the device can reach them.

We support five routes for getting logs out of a machine that cannot reach the network: a one-way hardware diode, a buffered collector transferred in batches, an isolated bastion host, scanned removable media, and serial console capture. Only the diode is real-time without creating a return path. The rest trade latency or labor for the air gap, and we will tell you which one your environment actually needs rather than selling you the expensive one by default.

THE HONEST VERSION

  • A diode costs roughly $2,000 to $10,000 and complicates the build. It is also the only option that cannot be turned into a route back in.
  • Removable media and serial capture depend on someone keeping a schedule. That is a control with a person in it, so plan for the person.
  • Serial capture is plaintext in transit and does not scale. It is sometimes still the only thing a device supports.
  • A buffered collector needs an agent installed, which some equipment will not accept.

Known gaps: no multi-node testing, no third-party review, and automated rebuild is currently limited to hosts with no local state. Model-driven root-cause remediation is the newest part of the design and the least proven; treat the approved-fix list as short until we can show otherwise.

PROGRAM 02 · PRIVACY-PRESERVING COMMUNICATIONS — ACTIVE RESEARCH

How much metadata can a usable messaging system stop leaking?

Content encryption is settled. Metadata is not. Who talked to whom, when, how often, and from where survives most deployed systems, and it is frequently the more revealing half.

Our program measures how far that leakage can be reduced against stated adversaries — a passive network observer, a hostile server operator, a partial global observer — while the system stays fast enough that people keep using it. Padding, batching, cover traffic, and delay all buy privacy with latency or bandwidth. We are trying to quantify the exchange rate rather than assert one.

This is research. There is no product, no beta, and no date. What exists today is a threat model, a simulation harness, and results we do not yet trust enough to publish.

If your work depends on metadata resistance, we would rather talk about your constraints than sell you something that is not finished.

Status: active investigation. Findings published when they survive review.

Working on something close to this?

We talk to people whose constraints could shape the research. No product to sell yet.

Get in touch →