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

Automotive and industrial patterns

Table of contents

1. Automotive reference architecture 2. Common automotive test themes 3. Industrial ICS patterns 4. Supply chain and lifecycle 5. Anti-patterns

Automotive reference architecture

Typical bench targets (names vary by OEM):

Use OEM-provided threat models when available; otherwise derive from interface inventory.

Common automotive test themes

Coordinate with reverse-engineer when analysis requires firmware images or cryptographic review beyond bus behavior.

Industrial ICS patterns

Never test live production assets; use shadow logic, digital twin, or vendor training rigs.

Supply chain and lifecycle

Document hardware and firmware revision matrix in the report appendix.

Anti-patterns

Bus and interface security

Table of contents

1. Interface inventory 2. CAN and CAN-FD 3. LIN 4. Automotive Ethernet 5. Modbus (industrial, high level) 6. Cross-cutting tests

Interface inventory

For each interface on the bench, capture:

CAN and CAN-FD

Security angles (lab only, within ROE):

• ID and DLC abuse — unexpected IDs, length violations, error-frame storms (rate-limited)
• Diagnostic services — UDS session transitions (default/extended/programming), securityAccess sequencing
• Gateway policy — cross-domain frames blocked or forwarded; replay across segments
• Timing — bus-off recovery, priority inversion, flood at bounded rate
• SecOC / MAC (if present) — replay, counter rollback, acceptance of unsigned frames on trusted buses

Capture DBC-aligned interpretations in reports; attach raw .blf/.asc or vendor-native captures.

LIN

• Schedule table violations and unauthorized frame injection on isolated networks
• NAD spoofing and duplicate master scenarios (only with safety-approved benches)
• Correlation with upstream CAN gateway when LIN is a satellite bus

Automotive Ethernet

At high level (delegate deep IT pentest to network-pentester when scope is enterprise-wide):

• Switch ACLs and VLAN separation between domains (infotainment vs powertrain mock)
• DoIP routing and activation types; TLS where specified
• SOME/IP service discovery exposure on bench VLAN
• Time sync (gPTP) manipulation impact on time-sensitive functions
• Mirror/port capture points documented for evidence

Modbus (industrial, high level)

• Unauthorized read/write holding coils from bench segment
• Unit ID scanning on isolated Modbus TCP/RTU
• Engineering workstation paths (logic download) when PLC is target—coordinate with vendor safety
• No guidance on disrupting live production PLCs; bench or shadow logic only

Cross-cutting tests

Map notable behaviors to MITRE Embedded / ATT&CK ICS where helpful for reader context—not as a substitute for reproduction steps.

Evidence and reporting

Table of contents

1. Evidence package 2. Finding format 3. Severity and safety notes 4. Coordination and retest 5. Data handling

Evidence package

For each test case or finding, assemble:

Store hashes (SHA-256) of large binaries in the report index.

Finding format

### [SEVERITY] Title

**Safety note:** (none | caution | hazard — required field)
**Impact:** (confidentiality / integrity / availability / safety-adjacent)
**Preconditions:** bench mode, keys, firmware hash
**Reproduction:** numbered steps on HIL bench
**Evidence:** file refs and offsets / frame IDs
**Root cause hypothesis:** design vs implementation vs configuration
**Remediation:** owner team (firmware, gateway, supplier)
**Retest:** pass criteria on bench

Deliver executive summary (risk themes, safety events) and technical appendix (full test case list).

Severity and safety notes

Always separate safety-adjacent observations from classic CIA impact; escalate safety notes to product safety regardless of CVE-style severity.

Coordination and retest

Retest only when firmware hash or config version is recorded; attach before/after traces.

Data handling

• Minimize PII and geolocation from telematics captures
• Redact VIN, license plates, and facility identifiers in external reports
• Follow ROE for data residency and export controls on automotive/ICS artifacts
• Do not upload raw traces to public issue trackers without scrubbing

Fault injection and stimulus

Table of contents

1. Planning principles 2. Stimulus categories 3. Test case structure 4. Harness and automation 5. Abort and rollback

Planning principles

• Tie every stimulus to a hypothesis (e.g., gateway forwards unsigned diagnostic write)
• Obtain safety approval before actuator-affecting or power-anomaly tests
• Prefer smallest step that falsifies the hypothesis; avoid shotgun fuzzing
• Keep human operator in the loop for first run of a new stimulus class
• Version-control stimulus definitions alongside firmware hash and bench config ID

Stimulus categories

Document prohibited stimuli in the test plan (e.g., airbag bus, steering torque, HV contactors).

Test case structure

Use a consistent template:

ID: HIL-SEC-###
Title:
Hypothesis:
Preconditions: (firmware hash, keys, bench mode, interlocks)
Stimulus: (script ref, frame list, duration, rate cap)
Expected (design intent):
Observed:
Evidence: (trace file, screenshot, log path)
Severity / safety note:
Retest criteria:

Harness and automation

• Separate stimulus generation from monitoring (dual CAN interfaces or logger + injector)
• Synchronize clocks; embed test case ID in log filenames
• Implement rate limits and max duration in scripts
• Run automated suites only after manual proof on the same bench configuration

Abort and rollback

Define abort triggers before execution:

After abort: preserve traces, file safety incident if required, do not resume until review.

HIL security tester scope

Table of contents

1. Role boundary 2. Engagement types 3. Partnership model 4. What good looks like

Role boundary

HIL security tester validates weaknesses on physical targets under controlled conditions; it does not replace IT pentest, SOC operations, or production incident response.

Engagement types

Clarify grey-box vs white-box (schematics, DBC/LDF, firmware images, keys) in the SOW.

Partnership model

What good looks like

1. Written authorization and completed safety review before energizing targets 2. Every finding is reproducible on the bench with versioned stimulus and captured traces 3. Safety interlocks documented; e-stop tested; hazardous motion isolated or mocked 4. Evidence is redacted; no unnecessary exfiltration of customer calibration or PII 5. Baseline restored; test keys and diagnostic sessions cleared before handoff 6. Retest scheduled for critical/high with frozen hardware/firmware identifiers

Test bench and safety

Table of contents

1. Bench topology 2. Safety interlocks 3. Pre-test checklist 4. During test discipline 5. Post-test and handoff

Bench topology

Document a single-line diagram covering:

Prefer isolated lab networks; block paths to corporate or internet unless explicitly in scope.

Safety interlocks

Never bypass OEM safety mechanisms without written approval from product safety.

Pre-test checklist

[ ] ROE and safety sign-off on file
[ ] Bench FMEA updated for this target and stimulus plan
[ ] E-stop tested; interlocks verified closed-loop
[ ] Firmware/calibration baseline captured and checksummed
[ ] Bus termination and ground reference verified
[ ] Emergency contacts posted; fire extinguisher rated for bench
[ ] Rollback plan: reflash, power cycle, config restore documented

During test discipline

• Increase stimulus gradually; log each step with UTC timestamp and operator ID
• Pause on unexpected actuator motion, smoke, over-temperature, or loss of watchdog
• Use named test cases (IDs) tied to version-controlled stimulus files
• Avoid unbounded random fuzz on safety-related frames without rate limits and abort conditions

Post-test and handoff

1. Return target to approved baseline (reflash or config restore) 2. Clear diagnostic sessions, temporary keys, and engineering unlocks 3. Archive traces with test case ID, operator, target hash, and tool versions 4. File incident note if any safety event occurred—even if no security finding 5. Brief firmware/vehicle security with raw evidence paths and reproduction package