carsecurity.tech

Fast-track analysis of automotive cybersecurity.

  • Automotive-CIS

    1–2 minut
    ,
    Source: Autocrypt Unveils „Automotive-CIS,” a Global Integrated Cybersecurity Infrastructure Standard for Vehicles, at CES 2026

    At CES 2026, Autocrypt unveiled „Automotive-CIS” (Cybersecurity Infrastructure Standard), a framework designed to unify Cybersecurity Management (CSMS), Software Updates (SUMS), and vSOC operations into a single reference model for Software-Defined Vehicles (SDVs).

    While the initiative promises to streamline fragmented security functions across the vehicle lifecycle, its emergence highlights a somehow persistent trend in the industry: the proliferation of proprietary standards.

    Information security has a long history of generating norms, guidebooks, and frameworks. However, we must distinguish between engineering resilience and administrative compliance. The rise of „integrated standards” could raise more questions than it answers:

    • Is this standard a technical breakthrough, or a vendor-driven initiative designed to create ecosystem gravity and PR momentum?
    • A comprehensive infrastructure standard does not inherently improve the security posture of a vehicle. It often simply creates a higher administrative barrier that prioritizes „checkbox” compliance over actual vulnerability mitigation.
    • Every new „integrated standard” requires engineering hours for documentation and alignment—resources that are often diverted away from low-level security tasks.

    This is not to suggest that initiatives like Automotive-CIS are without merit or technically flawed; rather, it is a call for the industry to acknowledge that the proliferation of such standards must be closely monitored (by the community!) to ensure they deliver tangible security outcomes rather than merely increasing administrative complexity.

    In other words, let’s be more cautious and aware because the „standard inflation” where marketing-driven frameworks begin to outpace actual engineering progress is just around the corner.

    Kamil Gapiński

  • Network segmentation in automotive architectures

    1–2 minut
    , , ,
    Source: https://storage.googleapis.com

    The concept of network segmentation in automotive architectures is well-established, traditionally using gateways to separate functional domains such as powertrain, telematics, and comfort. However, in an era of Software Defined Vehicles and hyper-connectivity, partial implementation is no longer sufficient. Segmentation must evolve from a architectural preference into a rigorous, industry-wide standard, from the OEM down through the entire Tier-N supply chain.

    Enforcing standards down the supply Chain

    The most critical security gaps often originate not within the OEM’s high-level design, but at the supplier level. A Tier-1 component that unintentionally bridges two segments—for example, a connectivity module with undocumented access to a safety-critical bus—can undermine the entire vehicle’s security posture. This „lateral movement” is exactly what attackers exploit to move from a non-critical breach (like Infotainment) to a safety-critical system.

    Zero Trust at the hardware level

    Segmentation must be treated as a compliance standard. To move forward, OEMs must demand:

    • Verified Isolation: Formal proof of isolation capabilities from every Tier-1 and Tier-2 supplier.
    • Zero Trust Integration: Ensuring that „Zero Trust” principles—where no communication is trusted by default—are embedded into both hardware and software long before components reach the assembly line.
    • Architectural Rigor: Moving beyond simple physical separation to include logical isolation (VLANs) and strict firewall rules within the vehicle’s backbone.

    We can no longer rely on „security by obscurity” or the assumption that sub-components are intrinsicaly isolated. Resilience requires a top-down approach that leaves no room for unintentional bridging.

    Kamil Gapiński

  • Instrument cluster hijacking via CAN bus

    1–2 minut
    , , , ,
    Source: https://recyclebmws.com/products/bmw-e90-e92-3-series-instrument-cluster-62109166858.html

    In 2017 researchers from the University of Malta — Robert Buttigieg, Mario Farrugia, and Clyde Meli — analyzed the security level and resilience of the CAN protocol using a BMW E90 instrument cluster as a testbed.

    The research demonstrated a practical attack using a malicious device built from low-cost, commercially available components, emphasizing the high risk posed by cheap hardware exploits.

    The Experiment Setup

    1. Test Model: a BMW E90 instrument cluster was used as the primary target.
    2. Simulation Environment: the remainder of the vehicle’s network was simulated using a specialized tool. Both the simulator and the malicious device resided on a single Arduino Mega 2560 microcontroller.
    3. Attack Vector: a prototype external device was physically connected to the CAN bus. The system utilized a remote connection architecture, where a wireless module provided a communication channel for an operator to send commands to the physically connected malicious device.

    Attack Scenarios & Findings

    The external device functioned as a Man-in-the-Middle to intercept and modify CAN frames, proving two key attack vectors:

    1. Data Spoofing (False Order)The MITM device successfully modified the data field in incoming CAN frames. As a result, the instrument cluster received fabricated values (e.g., speed, engine RPMs) and displayed them to the driver, successfully executing a visual spoofing attack.
    2. Denial of Service (Timeout) In a second scenario, the device blocked or dropped expected critical messages (e.g., from ABS or airbag modules). This caused the receiving systems to experience Timeouts and transition into a failure mode, effectively triggering a software-level Denial of Service.

    The researchers concluded that the instrument cluster itself lacked built-in mechanisms for verifying the authenticity of the data it received. The failure relies on the CAN protocol’s legacy assumption of internal trust, highlighting a critical vulnerability in ECU endpoints that prioritize speed over cryptographic verification.

    Kamil Gapiński

  • CAN Bus – a legacy protocol in a connected world

    1–2 minut
    ,

    The CAN protocol was designed for efficiency and reliability in closed, automobile systems, certainly not for security in connected environments. In its classic form, it lacks encryption and authentication. If a malicious actor gains access to the bus (e.g., via a connected ECU), they are implicitly trusted in the network by default.

    Modern security applications (like AUTOSAR SecOC or Secure Gateways) introduce additional defense layers. However, these are not a universal fix that fits perfectly for the car environment. All security implementations add latency and complexity that such legacy architectures cannot handle efficiently.

    The most critical gap pertains to logic, not syntax. An ECU, here understood as a node in a bus, validates a frame’s structure (ID, checksum) perfectly but fails to validate the operational context. So, if the architecture focuses only on the transport layer and ignores contextual validation, the vulnerability remains. This can mean, for example, that the information on your dashboard or IVI screen will be false or suggesting safety issues, while in reality, everything is fine.

    Kamil Gapiński