3 Approaches to Building a Vehicle Security Operations Center

With the rise in the number and sophistication of cyber-attacks targeting connected vehicles, it isn’t surprising that large vehicle OEMs either operate a Security Operations Center (SOC) or are in the process of building one. A SOC will be used by these OEMs to monitor, alert and respond to cyber-attacks with immediacy, therefore, protecting the connected vehicles, services and fleets that they manufacture and manage.

The Challenge with Automotive Cybersecurity

“Vehicle SOC” or “VSOC” is a term we’ve coined here at Upstream Security. Others refer to it as: ”Car SOC”, ”Mobility SOC” or “Automotive SOC”, but we prefer this term as it describes a holistic SOC that handles all the various aspects of mobility; from connected vehicles, to fleet management, mobility services and user applications.

But, why would OEM cyber security need a dedicated Vehicle SOC anyway?

Enterprise SOCs have been in existence for over a decade now, and they function well for the purpose for which they were built – i.e. providing security monitoring for the IT systems in standard enterprise architectures: perimeter, network, servers and endpoints.

Given its current tools (SIEM, SOAR, log management, ticketing, etc.) and methodologies, the “traditional” enterprise SOC is inadequate to handle the new challenges of mobility:

1. Risk potential

The potential impact of a cyber-attack against mobility is greater than the risk posed by hackers to IT systems. The reason is obvious – connected vehicles transport real people around, and any malfunction could have dramatic consequences – from a disturbance to traffic, to crashing a vehicle.

IT SOCs are tasked with securing data, and the primary damage resulting from a cyber-attack could be IT system downtime, data loss, financial loss or information theft – connected vehicle platforms inherit all these risks while introducing new human safety risks outlined above.

2. Scale

Although multinational enterprises may seem huge, sometimes employing hundreds of thousands of employees, the actual number of IT “assets” that they utilize is not. Not every employee has a computer and even when adding up the number of servers – a large enterprise can have up to 500,000 “assets”- a big number. However, when compared to a large OEM that manufactures millions of vehicles annually and with each vehicle expected to be on the roads for an average of ten years, the number pales in comparison.

3. Complexity

Enterprise IT infrastructure is structured in a fairly simple configuration; it is composed of endpoints (desktops), network, servers, gateway and perimeter devices. Mobility requires a more sophisticated infrastructure, including proprietary command and control (C+C) telematics servers, moving cars, cloud layer(s), machines, sensors, mobile applications and other components, making it more complicated to manage and monitor.

4. Ownership

An Enterprise IT team owns and manages its IT assets. Every piece of IT equipment must be registered and validated, and needs to be accessed by the IT staff. IT staff can “take control” and perform any desired action at any given time.

When it comes to mobility, things are quite different. The OEM usually is not the owner of the car, they cannot force the consumer to install components that it doesn’t wish to, nor can they quarantine the vehicle when they identify a threat. In short, there is no clear “ownership” of the asset after that asset has been sold and deployed.

5.  Liability

The “Right to Repair” act of 2012 allows car owners to modify their vehicle hardware and software configurations (up to a certain point when the warranty is voided).

This means that if something happens it isn’t clear as to who is responsible – The OEM or car owner? For instance, an owner can decide to ignore software updates that patch critical vulnerabilities, leaving the vehicle exposed to hacking (in an IT environment, users are not granted this level of freedom, all software updates are pushed automatically by IT). This is further exemplified in the use of OBD2.

(On-board diagnostics – a standard that specifies the type of diagnostic connector and its pinout, the electrical signaling protocols available, and the messaging format) that, being open for all, allows owners to develop or use customized plug-in devices that can compromise the car’s security.

What are the requirements of a successful Vehicle Security Operations Center?

As we’ve seen, the Vehicle SOC is a new creature that is facing novel challenges that are radically different than the traditional enterprise SOC. Therefore, it requires a set of capabilities to allow it to handle these new tasks:

1. Ingest various feeds 

Mobility requires the use of multiple data feeds from different stakeholders using different protocols:

• Telematics (Data sent from vehicles to telematics servers and commands being sent the other way), proprietary protocols, different versions per car model
• OTA software updates
• Consumer mobile app – connected to the car remotely
• Vehicle APIs (as in vehicle delivery)
• Mobility services and applications (like car sharing)
• In-vehicle sensors and security

The Vehicle SOC must be able to ingest all these feed types, process them and analyze them.

2. Correlation between various feeds

Any SIEM platform (Security Information Event Management, the main tool used at SOCs) can correlate between data feeds, but no SIEM platform was designed to see correlations across multiple geographies, time zones, vehicle types, driver types, and various ownership models (private, rented, shared). In short, specific rules must be applied in order to allow for a correlation between various mobility-related objects and groups. Which leads us to the next requirement.

3. Mobility-specific analytics

Vehicle SOCs must utilize specific analytics in order to allow it to detect and alert regarding anomalies (which could also indicate a cyber-attack). This stems from the need to interpret the data and understand the context, and this is only possible using very deep domain expertise.

For instance, some OEM vehicles send updates to the cloud in real-time, while others send these in batches. Understanding who does what is key in order to discern if such activity is ordinary (as it correlates to standard update patterns) or anomalous (indicating a malfunction or cyber attack that is preventing the vehicle from sending updates).

4.  Real-Time detection

Vehicle SOCs must detect incidents in near real-time and mitigate the risk to avoid further risk to the entire fleet. The security analytics need to have its algorithms run in real-time and able to analyze millions of messages per second, and identify the attacks before they affect the whole fleet of cars.

5. Mobility playbook

The playbooks are designed to block an attack targeted connected vehicle or mitigate potential risk. Mobility playbooks are completely different from enterprise playbooks where it usually involves assets like desktop, firewalls, etc. The mobility playbooks activate playbooks in the connected car’s environment and include unique workflows such as putting a vehicle or group of vehicles on quarantine, updating the drivers/passengers, controlling the OTA servers, etc.

6. Around the clock (not just follow the sun)

An operational angle, but one that requires further exploration, is that the enterprise SOC works in either day/night mode (for local organizations) or in a “follow the sun” pattern (for global companies). Vehicle SOC would have to operate 24/7 in full capacity- somewhere in the world there will be a connected vehicle on the road that requires protection. Hence, the mobility SOC will have to be more robust, with less tolerance for downtime and false positive alerts.

3 approaches for a new VSOC to secure your connected cars

Given the need to handle these new challenges and technical requirements, OEMs wishing to build Vehicle SOCs can choose from 3 main courses of actions:

• Expand the existing enterprise SOC to encompass mobility – this has obvious appeal to organizations with an existing SOC, but it would require the addition of mobility – specific platforms and change of operating procedures.
• Create a new and dedicated Vehicle SOC- this would fit organizations that are just starting their SOC journeys. Like other aspects of mobility, this is another avenue for business innovation and disruption- this new Vehicle SOC could potentially offer services to other OEMs and constitute an independent business unit.
• Outsource the Vehicle SOC to a managed security services provider (MSSP), that has (in addition to IT security capabilities) also mobility-related security capabilities.

Whatever the route the OEMs will take, it is imperative they will use the best tools and technologies to assist them in this transformation. Upstream’ proven SOC platform for cyber technology mobility supports all these approaches.

 

To learn more about Upstream’s SOC solution that is available today, click here.