In this presentation, we’re going to explore the connected car, its threat landscape and the means of establishing a Security Operations Center, SOC, for safely and securely running a connected car service. We are going to start with talking about the rise of connected cars, then how to build a connected car SOC and how to operate the SOC and finish the presentation with talking about to protect the connected car ecosystem from cyber threats.
The automotive industry is in the midst of a massive transformation – rapidly evolving into a service economy with eyes set on Transportation as a Service or Mobility as a Service. At the base of this transformation is CONNECTIVITY – enabling vehicles to be connected to an automotive cloud for operational, customer experience and massive data benefits. Today, according to Gartner, there are already over 100M connected vehicles – both OEM as well as after market fleets. That figure is going to expand dramatically and within a few years, the vast majority of new vehicles shipped will be connected according to Accenture.
Vehicle connectivity inherently creates new attack vectors for hackers to expose –
The combination of connectivity and the inherent cybersecurity risks are bringing OEMs across the board to establish Automotive SOCs as a key element in addressing these cyber threats.
In the next slides we are going to drill down into the right approach into building a Connected Car SOC:
What you see here is a diagram depicting a connected car service involving multiple application servers in the automotive cloud.
Vehicles that have mobile connectivity to the automotive cloud and a OEM mobile application allowing for performing of remote actions on the vehicles, such as: unlock door, start engine, drive out of driveway. All these servers are generating mountains of data that need to be analyzed by an Automotive Cloud Big Data solution and then are also integrated with solutions inside the SOC like SIEM and WORKFLOW. The primary goal of the SOC is to provide the security analysts with a global end-to-end view of the entire connected car service in order to get to root cause analysis and remediation as fast as possible.
The data sources for the connected car service may also extend past the specific OEM service into value added applications and integration with 3rd party sources like Smart City that also need to be taken into account. Here you can see the many types of data sources that the security solution will need to ingest and analyze. And the various security solutions that can also contribute to the big picture – some of them will come from the IT side of the business. e.g. think of a disgruntled employee trying to misuse the telematics server and impact vehicles.
The conclusion is that there needs to be a solution for aggregating and understanding all these data sources and create a Single Source of Truth – we call that Centralized Connected Car Security. Not every SOC will be the same but here are some of the main elements that we believe most Automotive SOCs need to have.
Now that we’ve seen the various elements in the SOC – let’s see how to operate the SOC.
In the SOC there will be similar people to the ones manning an IT SOC– but in addition OEMs need new types of people with automotive expertise – Telematics as well as In-Vehicle understanding. This is a brand new discipline that does not exist in the enterprise side.
One of the first things that the SOC will need to do is develop playbooks that are geared towards automotive events.
Here we see an example for a playbook for bad or anomalous telemetry after FOTA Update, a firmware over the air update. The Playbook is aimed to start at the symptom which is a data health violation, and do a gradual and systematic process to reach the rot cause and discover the problem.
In this example we see that the violations are following a FOTA update. The analysis problem aims to collect the cars that are affected by the issue, and then to pass the problem for the correct owner in the SOC, or product teams – in this case it is the FOTA owner in case of a buggy or bad FOTA, and the In-Vehicle owner in case of installing an unauthorized FOTA locally.
Here is a typical cyber scenario involving takeover of elements in the automotive cloud and involving both the IT and OT sides of the business. In this example the Telematics server attacks the fleet by sending START_ENGINE command to 300 vehicles at the same time. Then, the Automotive Cloud Security sends an alert to SIEM. The SIEM correlates the detected anomaly to administrator A login to the telematics server. And finally Administrator A is blocked.
As we’ve seen one of the key elements towards creating an effective SOC for automotive is a Single Source of Truth solution that can analyze all the various automotive data feeds and detect cybersecurity and business policy incidents in real time. Upstream Security built the first solution in the world to address this complex problem.
Upstream C4 provides an Agent Less, no software or hardware in vehicle, that can ingest and correlate multiple data feeds in the automotive cloud and distill them into actionable detection. The solution integrates seamlessly with your anonymized data feeds and capable of protecting vehicles already on the road today.
To learn more about how Upstream’s C4 can integrate into your SOC and become your Single Source of Truth solution for detecting cybersecurity and business policy incidents please contact us. Thank you for watching.