How do you prove a deployable kit's sensors see traffic?

Check that capture interfaces are in promiscuous mode, detection rules are loaded and events are arriving in the analytics platform, and measure capture and detection loss per sensor. Rhombus validation runs these checks on the kit for the sensors it carries.

What does self-heal do?

On Rhombus, a failed critical check with a known fix re-runs the install for that service, then the check is re-probed. The loop is bounded, warnings never trigger it, and anything left failing is reported to the operator.

Does validation need a network connection?

No. Rhombus validation and remediation run on the kit with no internet connection.

Field guide

Kit Acceptance Testing: Proving a Deployable Kit's Sensors Work

Q: What should a kit acceptance test report include?

Kit identity, a summary scorecard, every check with its description, expected outcome and result, and a sign-off block. Rhombus exports this as the Kit Validation and Acceptance Report.

A kit acceptance test proves a deployable cyber kit works, not just that it powers on. It checks every critical service, confirms each sensor is capturing traffic and its events reach the analytics platform, and records each check with its result in a report the receiving party signs. Rerun it after every update, rebuild or reset.

Why "powered on" is not "working"

A sensor can look healthy from every service check and still see almost nothing. A capture interface can drop out of promiscuous mode, an intrusion detection engine can run with no rules loaded, and an exporter can report success while every event it sends is rejected. None of these show up as a red light on the hardware.

When acceptance is a manual walk-through, these failures ship. The team finds out in the field, usually when they need the data most.

What a real acceptance test covers

Start with the foundation: identity, name resolution, time and the package mirror, checked on every machine the kit is supposed to have. Then check the services analysts use, and that each one answers and accepts a login.

Sensors need functional checks, not port checks. The test should confirm capture interfaces are in promiscuous mode, detection rules are loaded, every sensor node is connected, events are arriving in the analytics platform without failures, and packet, protocol-log and intrusion-detection loss are measured per node. On a quiet tap, the test should still tell a silent sensor from a broken one.

Finally, the results need to become a record: every check, what it expected, what it found, and who accepted the kit on what date.

How Rhombus validates a kit

Rhombus runs one check registry from three places: at the end of a kit build, from the command line and from the console. Checks are generated for each kit from the machines it declares, covering name resolution, reachability, time source and whether each machine takes its packages from the kit's own mirror, plus service health and sensor checks such as capture interface state, detection rules loaded and events arriving downstream. The console's validation suite adds sensor grid health, event flow and per-node capture, protocol-log and detection loss.

Validate and Self-Heal closes the loop. Failed critical checks that have a known fix re-run their install, the failed checks are re-probed, and a final full validation decides the result, within a bounded number of rounds. Warnings never trigger remediation, and what cannot be fixed is named for the operator.

The console exports a Kit Validation and Acceptance Report: kit identity, a summary scorecard, a per-section checklist, every check with its description, expected outcome and result, and a sign-off block that records how many executed checks passed.