Hardware In The Loop Security Tester

Hardware-in-the-Loop (HIL) Security Tester

When to Use

• Plan or execute authorized security assessments on real hardware with a HIL rig (ECU, ECM, PLC, gateway, domain controller)
• Design test bench topology, bus taps, power/reset control, and safety interlocks before active testing
• Map attack surfaces on cyber-physical targets (diagnostics, flashing, debug ports, wireless, OTA paths) under lab conditions
• Develop fault injection and stimulus campaigns (bus frames, timing, signal, power) with reproducible test cases
• Monitor buses and interfaces during tests; correlate observations with firmware/vehicle security teams
• Capture evidence (logs, traces, captures, configuration snapshots) suitable for remediation and retest
• Coordinate retest after firmware patches, key rotation, or configuration hardening on the same bench

When NOT to Use

• Web application or API-only assessments (OWASP, proxy methodology) → web-pentester
• Network/AD/infra pentest without embedded targets on the bench → network-pentester
• General penetration test without HIL hardware, buses, or plant simulation → penetration-tester
• Disassembly, decompilation, patch diff, or malware RE as primary work → reverse-engineer
• SIEM alert triage, SOC playbooks, or shift operations → soc-analyst
• Live incident command, war room, or production containment → incident-responder
• LLM jailbreak, prompt injection, or agent tool abuse → ai-redteam
• Classified ISSO / accreditation paperwork without hands-on HIL testing → information-systems-security-officer-classified-specialist
• CI build validation or release gates without hardware under test → build-validator
• Enterprise security strategy, GRC roadmap, or policy without lab execution → cybersecurity
• Control testing and audit evidence mapping only (no active HIL tests) → compliance-engineer

Related skills

Core Workflows

1. Authorization, scope, and bench readiness

Do not energize targets or inject faults without written authorization and completed safety review.

1. Confirm signed SOW/ROE: targets, buses, methods, time windows, stop conditions
2. Complete bench FMEA / hazard review with lab owner; document interlocks and e-stop
3. Inventory target firmware versions, keys, calibration, and baseline configuration
4. Define out-of-scope (moving machinery, public roads, production fleets, third-party networks)
5. Establish emergency stop, power-down procedure, and escalation contacts

See references/hil_security_tester_scope.md and references/test_bench_and_safety.md.

2. Attack surface mapping and test design

baseline capture → interface inventory → trust boundaries → threat hypotheses → test cases → peer review

Prioritize interfaces exposed on the bench: OBD/diagnostics, flashing, debug (JTAG/SWD), wireless, USB/Ethernet, service modes, and cross-domain gateways.

See references/bus_and_interface_security.md and references/automotive_and_industrial_patterns.md.

3. Execute fault injection and stimulus (in scope)

• Run reproducible scripts or harness-defined sequences; version control stimulus definitions
• Record bus traces, power events, and target responses with synchronized timestamps (UTC)
• Stop at agreed impact; avoid unbounded fuzzing on safety-critical actuators without explicit approval
• Restore baseline configuration and clear test keys/sessions before handoff

See references/fault_injection_and_stimulus.md.

4. Evidence, reporting, and coordination

Per finding: title, severity, safety note, impact, preconditions, reproduction on bench, evidence refs, remediation owner, retest criteria. Coordinate with firmware/vehicle security on exploitability vs design intent.

See references/evidence_and_reporting.md.

When to load references