5.3: SEC.3 Cybersecurity Verification

Process Overview: SEC.3 establishes procedures to verify that cybersecurity controls effectively mitigate identified threats. Unlike SEC.1 (threat analysis) and SEC.2 (security implementation), SEC.3 focuses on validation - proving controls work as designed.

Process Definition (ASPICE 4.0, Clause 5.3.3)

Purpose

To verify that security controls implemented in SEC.2 effectively mitigate identified threats and achieve required security objectives.

Outcomes

Base Practices

Security Verification Strategy (BP1)

Components of a Security Verification Strategy

1. Threat-Based Testing

For each threat identified in SEC.1 threat analysis:

THREAT: [THR-001] Brake command injection attack
├─ Attack Vector: CAN bus message spoofing
├─ Severity: CRITICAL (loss of brake function → crash)
├─ Control: [CTL-001] CAN message authentication (MAC)
│
├─ VERIFICATION STRATEGY:
│  ├─ Unit Test: MAC calculation correctness
│  ├─ Integration Test: Message validation in brake controller
│  └─ Penetration Test: Inject invalid MAC, verify rejection

2. OWASP Testing Categories

Cover all major attack classes:

3. Multi-Level Verification

LEVEL 1: Static Analysis (Code Review)
  └─ Does code implement intended controls?
  └─ Tools: SonarQube, Checkmarx (SAST)
  └─ Example: "Verify AES-256 is used, not AES-128"

LEVEL 2: Dynamic Testing (Unit/Integration)
  └─ Do controls work in isolation?
  └─ Example: "Mock CAN bus, send invalid MAC, verify rejection"

LEVEL 3: Penetration Testing (System-Level)
  └─ Can attacker bypass controls in integrated system?
  └─ Example: "Connect to real vehicle, attempt brake injection, verify blocked"

LEVEL 4: Red Team Exercise (Operational)
  └─ Can authorized personnel find new attacks?
  └─ Example: "Give security team 2 days to break brake system"

Security Verification Test Cases (BP2)

Test Case Template

[SEC-TEST-XXX] Threat Name - Verification Test

THREAT ADDRESSED:
  [THR-NNN] (from SEC.1 threat analysis)

ATTACK SCENARIO:
  Attacker position: <network, physical, etc.>
  Attack method: <injection, fuzzing, physical probe, etc.>
  Expected defense: <encryption, authentication, timeout, etc.>

TEST SETUP:
  1. Configure test environment (lab with vehicle ECUs)
  2. Instrument security controls (add logging)
  3. Deploy monitoring (packet capture, system logs)

TEST STEPS:
  1. Send valid message (baseline) → Verify accepted
  2. Send invalid message variant → Verify rejected
  3. Send attack payload → Verify safely rejected

PASS CRITERIA:
  [PASS] Valid messages: 100% accepted (no false negatives)
  [PASS] Invalid messages: 100% rejected (no false positives)
  [PASS] Attack payloads: 0 successful (zero vulnerability)
  [PASS] System remains responsive (no DoS side-effect)

EVIDENCE ARTIFACTS:
  - Test log (timestamp, message, response)
  - Packet capture (wireshark, candump)
  - ECU system log
  - Pass/fail summary

Example: CAN Message Authentication Verification

[SEC-TEST-001] CAN Message Authentication - MAC Validation

THREAT ADDRESSED:
  [THR-001] Brake command injection via CAN spoofing

TEST SETUP:
  ├─ Brake ECU (target)
  ├─ CAN sniffer (Kvaser, Vector)
  ├─ CAN injection tool (CANoe, Python-CAN)
  └─ Real brake system (or HIL simulator)

TEST STEPS:

Step 1: Baseline - Valid Message (Transmit Real Brake Command)
  Action: Send authentic brake command from OEM tool
  Message: ID=0x123, Data=[0x00, 0x50, ...], MAC=[0xAB, 0xCD]
  Result: [PASS] Brake applies, system responds correctly

Step 2: Injection Attack - Invalid MAC
  Action: Spoof brake command with modified MAC
  Message: ID=0x123, Data=[0x00, 0x50, ...], MAC=[0xFF, 0xFF]  ← INVALID
  Result: [PASS] Brake rejects command, logs security event [THR-001 BLOCKED]

Step 3: Brute Force - Try 100 MAC Variants
  Action: Send brake command with different MACs (fuzzing)
  Results:
    - Valid MAC (1 variant): [PASS] Accepted
    - Invalid MACs (99 variants): [PASS] All rejected
    - No system crash, no lockup

Step 4: DoS Attack - Rapid Invalid Messages
  Action: Send 1000 invalid messages/second
  Results:
    [PASS] System remains responsive
    [PASS] Valid commands still accepted
    [PASS] No buffer overflow, no CPU saturation

PASS CRITERIA:
  [PASS] All invalid messages rejected
  [PASS] Valid messages still processed
  [PASS] System stable under attack
  [PASS] Security events logged for diagnostics

EVIDENCE:
  - CAN log (1000 messages, 999 blocked, 1 accepted)
  - ECU system event log (timestamps, blocked message count)
  - Brake response (applied when valid, not applied when spoofed)

Security Verification Execution (BP3)

Three Verification Approaches

1. Static Analysis (Code-Level)

Tools: SonarQube, Checkmarx, Fortify

Example: Verify AES-256 encryption is used

// COMPLIANT: Uses AES-256
mbedtls_aes_context ctx;
mbedtls_aes_setkey_enc(&ctx, key_256bit, 256);  // [PASS] 256-bit key
mbedtls_aes_crypt_ecb(&ctx, MBEDTLS_AES_ENCRYPT, plaintext, ciphertext);

// NON-COMPLIANT: Uses weak AES-128
mbedtls_aes_context ctx;
mbedtls_aes_setkey_enc(&ctx, key_128bit, 128);  // [FAIL] 128-bit key (weak)

Static Analysis Detection:

• Tool scans code → Finds AES-128 usage
• Reports: "Use of weak encryption (128-bit) detected in CAN_encode()"
• Severity: HIGH
• Recommendation: Upgrade to AES-256

2. Dynamic Testing (System-Level)

Approach: Execute test cases against running system

Setup:

┌─────────────────────┐
│  Test Framework     │
│  (Robot, pytest)    │
├─────────────────────┤
│ Test Case Executor  │
│ Sends: CAN frames   │
│ Checks: Response    │
├─────────────────────┤
│ CAN Interface       │
├─────────────────────┤
│ ECU Under Test      │
│ (Brake Controller)  │
└─────────────────────┘

Test Execution:

Verify MAC Authentication
    [Documentation]  Test SEC-TEST-001

    # Step 1: Valid message
    Send CAN Message    ID=0x123  Data=[0x00,0x50]  MAC=VALID
    ECU Should Accept   (verify in system log)

    # Step 2: Invalid MAC
    Send CAN Message    ID=0x123  Data=[0x00,0x50]  MAC=INVALID
    ECU Should Reject   (verify event [THR-001 BLOCKED])

    # Step 3: Brute Force
    FOR    ${i}    IN RANGE    100
        Send CAN Message    ID=0x123  Data=[0x00,0x50]  MAC=${RANDOM_MAC}
    END
    ECU Should Reject All    (verify 0 accepted of 100)

    # Step 4: DoS Test
    Flood CAN Bus    Messages=1000  MACs=INVALID
    ECU Should Remain Responsive
    Valid Messages Should Still Work

Result: [PASS] All test cases pass

3. Penetration Testing (Red Team)

Scope: Realistic attacks by security expert

Engagement:

Week 1: Reconnaissance
  ├─ Reverse engineer CAN protocol
  ├─ Analyze key exchange mechanism
  └─ Identify attack surface

Week 2-3: Attack Development
  ├─ Design injection payloads
  ├─ Build CAN spoofing tool (Python-CAN)
  └─ Attempt bypass techniques

Week 4: Exploitation & Documentation
  ├─ Try attacks on real vehicle
  ├─ Document successful attacks (if any)
  └─ Recommend mitigations

Expected Result: [PASS] All attacks blocked OR [FAIL] Vulnerabilities found → Fix → Re-test

Security Verification Tools & Integration

Static Analysis (SAST)

Tool: SonarQube with C/C++ plugins

# sonarqube-properties.yml
sonarqube:
  security_rules:
    - hardcoded_passwords: FAIL
    - weak_encryption: FAIL  # Detects AES-128, RC4, MD5
    - sql_injection: FAIL
    - buffer_overflow: FAIL  # CWE-120, etc.

  quality_gates:
    - Security Rating: A minimum
    - Vulnerabilities: 0
    - Critical Issues: 0

Integration:

• Pre-commit hook: SonarQube scan before code merge
• CI/CD pipeline: Fails build if security issues found
• Dashboard: Real-time vulnerability tracking

Dynamic Testing (DAST)

Tool: CANoe with test automation

CANoe Test Automation:
├─ CAN trace capture
├─ Message injection
├─ Response verification
├─ Automated fuzzing
└─ Report generation

Configuration:

// CANoe CAPL code - Send spoofed brake command
on message brakeCommand {
    // Intercept valid command
    message mockBrakeCmd;
    mockBrakeCmd.ID = 0x123;
    mockBrakeCmd.DLC = 8;

    // Modify MAC (make it invalid)
    mockBrakeCmd.byte[6] = 0xFF;  // Inject invalid MAC
    mockBrakeCmd.byte[7] = 0xFF;

    // Send spoofed message
    output(mockBrakeCmd);

    // Verify ECU rejects it
    setEventMask(0);  // Monitor ECU response
}

Penetration Testing

Tools & Approach:

Example Attack Script:

import can
import itertools

# CAN interface
bus = can.interface.Bus(channel='can0', bustype='socketcan')

# Target message ID
brake_id = 0x123

# Known plaintext (brake command)
known_data = bytes([0x00, 0x50, 0x00, 0x00, 0x00, 0x00])

# Brute force MAC (last 2 bytes)
for mac_bytes in itertools.product(range(256), repeat=2):
    mac = bytes(mac_bytes)

    # Construct spoofed message
    payload = known_data + mac
    message = can.Message(arbitration_id=brake_id, data=payload)

    # Send attack
    bus.send(message)

    # Check if accepted (wait for confirmation)
    # If ECU accepts any message → Vulnerability!
    if check_acceptance():
        print(f"[VULNERABILITY] Accepted with MAC: {mac.hex()}")
        break

    if (iterations % 100) == 0:
        print(f"Tested {iterations} MACs...")

Analysis & Findings Management (BP4-BP5)

Vulnerability Classification

After verification, classify findings:

Severity Levels (CVSS 3.1):

Example Finding

[VUL-001] Brake MAC Authentication Weakness

Severity: CRITICAL (CVSS 8.7)

Description:
  Brake commands in CAN bus protected by 8-bit MAC (checksum).
  Attacker can brute-force valid MAC in <1 second with commodity hardware.

Affected Code:
  - can_security.c:145 MAC_CALC_8BIT()

Proof of Concept:
  Send 256 CAN messages with varying MACs → 1 will be accepted

Impact:
  Attacker can inject arbitrary brake commands → Loss of braking → Crash

Remediation:
  Upgrade to AES-256 authenticated encryption (CMAC-AES)

Timeline:
  ├─ Discovery: 2025-12-15
  ├─ Fix: 2025-12-28
  └─ Re-verification: 2026-01-04 (PASSED)

Status: [PASS] RESOLVED

SEC.3 Verification in Multi-Standard Context

Mapping to Other Standards

ISO 26262 Automotive Safety:

• SEC.3 = Part of ISO 26262 verification (but ISO 26262 focuses on functional safety, not cybersecurity)
• Complementary: ISO 26262 + ISO/SAE 21434 (cybersecurity standard)

ISO/SAE 21434 Cybersecurity:

• SEC.3 aligns with ISO/SAE 21434 Clause 13 (Cybersecurity Testing)
• Verification approach matches both standards

IEC 62304 Medical Device Security:

• SEC.3 verification can be applied to medical devices
• Example: Insulin pump wireless command injection testing

SEC.3 Verification Checklist

• [PASS] Threat model from SEC.1 reviewed
• [PASS] Security controls from SEC.2 identified
• [PASS] Verification strategy documented (BP1)
• [PASS] Test cases designed for each threat (BP2)
• [PASS] Static analysis executed (SAST tool)
• [PASS] Dynamic testing completed (integration tests)
• [PASS] Penetration testing performed (red team)
• [PASS] All critical vulnerabilities remediated
• [PASS] Evidence compiled (test logs, reports)
• [PASS] Sign-off obtained (security team approval)

Summary

SEC.3 Cybersecurity Verification:

• Purpose: Prove security controls effectively mitigate threats
• Approach: Multi-level verification (static → dynamic → penetration testing)
• Tools: SonarQube (SAST), CANoe (DAST), Python/Ghidra (red team)
• Evidence: Test cases, logs, vulnerability reports
• Integration: Multi-standard (ISO 26262 + ISO/SAE 21434 + ASPICE)

Next: Document security improvements and deploy SEC.3 verification into CI/CD pipeline.