Did you know that it takes IT companies up to 6 months to detect a data breach? This lack of visibility means that the damage may have already been done by the time an organization realizes there’s malware in their networks.
But in the automotive domain, OEMs don’t have the luxury to wait days, nor hours, for cyberattacks to be discovered given the risk to human lives.
In order to navigate through this complex landscape, CISOs are extending their current security operations to incorporate an Automotive SOC (security operation center) — either in-house or through a Managed Security Service Provider (MSSP).
But how does an ‘Automotive SOC’ differ from the traditional enterprise SOC we’ve all heard of? And why can’t automotive CISOs rely on existing infrastructure to monitor vehicles? In this article, we’ll examine the rise of Automotive SOCs, what they are, and their key characteristics.
What is an Automotive SOC?
An Automotive SOC (‘ASOC’ or Automotive Security Operation Center) is an in-house or outsourced function involving people, processes, and technology that continuously monitors, investigates, and improves the security posture of fleets.
Currently, OEMs adopt one of two approaches to establishing an ASOC — either by building it as an extension of their existing IT SOC or by outsourcing a Managed Security Service Provider (MSSP).
In the next section, I will explain the 3 core elements required in an automotive SOC: technology, people, and processes.
1. Automotive SOC People
The people and their knowledge are the cornerstones of an effective Automotive SOC. Their purpose is to provide the OEM with sophisticated cyber security identification, analysis, and investigation capabilities across the fleet. The ideal structure of an ASOC team comprises five key functions:
L1 Alert Analyst
The primary functions of the alert analyst are to continuously monitor the alerts queue, understand security alerts specific to the automotive domain, monitor fleet health, and collect data to enable the mitigation by Level 2 incident responder(s).
L2 Incident Responder
Incident responders perform deep-dive analysis by correlating data from various sources, determining whether a critical in-vehicle system has been breached, and classifying incidents by types. Incident responders also advise OEMs on which remediation procedures to initiate and provide support for new analytic methods for detecting threats.
Automotive Content Engineer / Use Case Analyst
This individual works hand in hand with the MSSP or the OEM to continuously improve the Automotive SOC process by identifying new use cases and implementing them.
L3 Automotive Cybersecurity Expert & Incident Responder
For escalated security events, ASOC teams can rely on automotive cybersecurity experts who usually come from product engineering teams. They possess in-depth knowledge of in-vehicle networks, threat intelligence, and forensics as well as functions of specific ECUs or underlying infrastructure. Based on this knowledge, they perform risk analysis and provide suggestions to the ASOC team.
L4 External Research Response Team / Threat Hunters
In some cases, in-house resources and expertise are not sufficient to comprehensively solve an issue. As such, external research response teams or threat hunters–who possess unique skills–can be employed in a Level 4 (L4) escalation.
External research response teams or threat hunters may be responsible for finding unknown threats that have gone undetected. Such a role involves developing, tuning, and implementing advanced automotive threat detection analytics based on experience, pen-testing, and other measures and experience.
2. Automotive SOC Process
An automotive SOC requires well-defined and documented processes to ensure timely and effective management of all automotive alerts and events, involving various SOC employees. The flowchart below illustrates the entire process of how a security alert is handled from start to finish.
More specifically, it takes four pillars to build a mature Automotive SOC process:
Defining an effective ASOC process requires a deep understanding of SOC and OEM functions and operations. The Automotive SOC team must be experienced in these areas to facilitate proper cyber security responses when incidents occur.
For an ASOC process to run efficiently, there needs to be a constant improvement and expansion of the automotive use case library. This involves adding new data feeds, creating new detection rules, and training employees.
Argus provides its customers with automotive playbooks, which are based on well-documented automotive use cases across the threat landscape. These playbooks guide analysts throughout the entire investigative process by providing actionable steps from the moment the threat is detected and up until its mitigation. For any given incident, analysts can determine, with certainty, whether it’s a false-positive or if it requires further attention, resulting in a faster, collaborative, and standardized ASOC process.
An advanced ASOC team is most successful with the mutual support of the vehicle development team (usually the electric and electronics team). Despite their vastly different responsibilities, both departments should cooperate to Investigate and mitigate vehicle-related cyber security incidents and support industry-wide IT processes such as the Incident Response Plan by the Automotive Information Sharing and Analysis Center (Auto-ISAC).
3. Automotive SOC Technology
Traditional IT SOC tools are not designed to manage millions of endpoints with such large volumes of data. Given this, Automotive SOC technology should support the following capabilities:
Solve unique technological challenges such as scale, geolocation, connectivity, protocols, and backdating processing.
Detect automotive attacks: Detection engines used by the Automotive SOC must take into account existing and emerging threats in the automotive world, not IT.
Understand the cyber state of the fleet: Insights into emerging attacks as well as full visibility into existing attacks, vulnerabilities, and various security trends of a fleet post-production.
Minimal incident detection time: Full visibility is required across the fleet on a simple display that aggregates findings to expose potential incidents, not just isolated events. Unlike traditional IT SOCs, a domain-specific methodology is required to shorten detection times since automotive data usually contains unique protocols (e.g. CAN), unique data types (e.g. Telematics), and specific data flows (e.g. OTA process), which do not exist in regular IT infrastructure.
Distributed detection: Achieving comprehensive threat detection across the fleet requires the analysis of relevant in-vehicle data as well as data from other sources (such as mobile apps, telematics data, diagnostic data, backend systems etc). Any suspicious activity detected by technologies inside the vehicle should be sent to the Automotive SOC team for immediate response and analyzing such data requires extensive automotive knowledge.
Focus on critical indicators: Powerful investigation and forensics capabilities enable you to analyze the incident in progress and identify what type of attack it is, when and where it originated, and how to make sure it never happens again. Such critical indicators can be identified by performing cause analysis with data provided by suppliers or vendors (e.g. what is the module version of an attacked ECU).
Operational efficiency: False positives should be removed with minimal user interference, and the UI should focus on a unified investigation system. Having a close integration with the detection system as well as a deep understanding of automotive technology boosts efficiency in handling events.
Continuous adaptations: Mechanisms for ongoing refinement should be built-in, including advanced algorithms that support two things: 1) A growing understanding of automotive cybersecurity threats and 2) continuous improvements of vehicle-related security concepts.
Comply with emerging regulations: Support for heightened security measures to comply with vehicle regulations like UNECE WP29 Automotive Cybersecurity Regulation and data privacy laws like GDPR. Under GDPR, any personal information that’s used to identify a driver (such as their plate number, vehicle usage, geolocation, or driving behaviors) can only be collected, stored, and processed upon explicit consent of the individual.
Integrate with existing IT infrastructure: Connect new Automotive SOC platforms with existing applications to ensure consistency across platforms and reduce unnecessary costs. Support both on-premise and in-cloud deployment as well as centralized and distributed architectures.
Gain Full Visibility Across your Fleet with an Automotive SOC
It’s no surprise that today’s highly-connected vehicles can be vulnerable to cyber-attacks. By establishing a dedicated Automotive SOC with the skilled personnel, technologies, and defined processes designed for the automotive landscape, CISOs will be able to detect vehicle attacks in real-time, understand the full attack story, and help mitigate the damage as quickly as possible.
To learn more about how you can build a complete Automotive SOC strategy using Argus Fleet Protection, get your copy of our latest eBook.
Author: Sapir Segal, Product Marketing Manager
at Argus Cyber Security