Upstream’s Cybersecurity Engines

[Transcript]

At the core of our Upstream C4 platform we have four cybersecurity engines that work together to protect your connected car service. These four engines are all data driven and leverage machine learning at their foundation.

When data first enters the system, it goes into our protocol cybersecurity engine. The protocol engine is stateless, which means that it inspects every message individually as it comes into the system. The protocol engine verifies that every message should be according to spec and that there should not be any rogue messages that are beyond the normal operation of the connected car service. Additionally, it does deep packet inspection on the actual contents of individual messages, verifying that all the message fields, variables and payload are according to standard. The protocol engine is real time and it can actually create real time incidents for data that flows into the C4 platform.

From the protocol engine, we move on to our stateful engines that actually look at data using streaming analytics over longer periods of time. The first stateful engine is our transaction cybersecurity engine. In Upstream C4 platform, a transaction is basically a combination of several messages that combine together to perform a certain action. A transaction can stem either from a single data source, such as the telematics application, or a correlation of multiple data sources, for example, flow from a mobile application all the way to the telematics service. As an example, we can look at a transaction such as an unlock, or remote unlock door command, starting from a mobile application where the user would unlock their doors using their mobile app. This would create a message that would flow to the mobile server, from there to a telematics server, and from there to the car, and then roll all the way back to the mobile application with an ACK.

For that specific example, that can spawn actually like eight or ten different messages flowing from the user all the way to the car and back. The transaction engine would basically identify that sequence as a single transaction that we would name “unlock door” and verify going forward that that specific transaction always is carried in the same way. So, for example, if a hacker would try to overtake that transaction, what we might see with the engine is only a single message sending the unlock door command from the telematics server instead of the transaction starting and originating from the mobile application. The engine can then flag that incident and then send that over to a workflow solution or a SIEM solution.

The next engine that’s in play is our contextual engine. Within normal operation of the connected car service, a vehicle undergoes multiple context or multiple states. The very basic state is either the vehicle is either in rest or in motion driving on the road somewhere. The contextual engine can learn dynamically what state or what context the vehicle is currently undergoing, and then identify what are the valid messages, valid commands that are allowed during this specific state. So for example, if a vehicle is currently driving 50 miles per hour, it should probably not get a “shut down engine” command as it’s doing that.

The last stateful engine is our behavioral engine. The behavioral engine takes a look at the overall connected car service and analyzes the behavior of multiple modules that compose that connected car service. We use profiling techniques to classify the telematics application and how it behaves, the specific vehicles, and finally the drivers, and then compose that into an overall behavioral picture of that connected car service.

For the telematics application, we analyze multiple parameters such as the frequency of messages and the types of messages over time of day. For vehicles, we’re able to group specific make models of vehicles and identify the unique behavior each one of them contain. So, for example, we take an SUV compared to a compact car and compare the various behaviors in terms of messages and overall ECU and TCU behavior and then be able to classify the various types.

And the last behavioral component, we look at the drivers and the fleet and search for anomalous behavior of both fleet-wide policy, as well as individual driver behavior, looking for remote cyber-attack detection and using that as another signal to identify that. Each of the engines use a different technique. They all work together and complement each other to create a complete protection and basically create incidents both in real time and non-real time.

The final component in our core is something that we call auto threat intelligence. Since multiple OEMs and multiple fleets use the same components, and they’re all exposed to similar attacks, we thought it would be great to be able to share metadata between customers. Auto threat intelligence is the first vendor-driven effort to group together multiple customers, multiple OEMs and basically be able to share metadata of security incidents and security violations. The result is an ever-learning security framework that is able to ingest third party sources and create a comprehensive security framework that is always learning and always improving.