 My name is Gil Mizzouz. I'm VP of Engineering at Upstream, where I lead the software development, data engineering, data science, and DevOps. Before Upstream, I was nine years at NSO, where I founded the real-time data analytics and intelligence domain. So today, we're gonna talk about cybersecurity and data management for connected vehicles. Let's see. We're gonna start with the challenges that brings us connected vehicle data, and there are many. We're gonna see how Upstream data management and cybersecurity platform solve these challenges and aim to solve it. We're gonna show how we utilized cloud agnostic architecture with OpenShift in order to deploy our platform easily. And of course, questions at the end if there are any. So, let's begin. So today, almost every new vehicle is connected, whether it's connected by telematics controller unit or any other form. So the automotive industry is accelerating toward a technology-centric future with connectivity at its heart. Data and connectivity are the foundation of connected vehicles, and the automotive industry and its transformation comes in many ways. There are so many data sources, whether it's a key fob, whether it's a mobile application that controls the vehicle or to the server telemetry and so forth. There are so many data sources. The need for improved driving and better customer experience pushes OEMs to create new technologically advanced innovations that are enabled by this connectivity. Unfortunately, the other side of connectivity is that it widens the attack surface for hackers to find new attack vectors and exploit every flaw, leaving vehicles, networks, and backend servers vulnerable. So we can see here, there are so many vectors and exploits that could be in this domain. You have the backend server. So imagine yourself, someone a hacker attacks the telematic server of a specific OEM. It can control the entire fleet. You might send commands that control the entire fleet. Say it's closed the doors and no one can enter or even something worth. You have mobile applications. Hacker can also hack to a specific vehicle or to an application server that receives mobile application commands that are moving from this attack vector with all of this data. So this technology comes with a risk. That's where upstream comes to the rescue. So upstream, one of our passwords is unlocking the value of mobility data. And that's what we do. Upstream aims to unlock the value in connected vehicles data to help stakeholders secure their assets. First of all, security to make sure that the answers are not compromised. Comply with regulations, improve vehicle data quality and then data find new business opportunities. Upstream introduced a fundamental innovative shift in the approach to connected vehicle security, predictive maintenance, automotive insurance and business intelligence. It is fueled and powered and unlocked by a cloud-based data management platform purpose-built for connected vehicles. Upstream security provides a cloud-based data management platform purpose-built for connected vehicles delivering unparalleled automotive cybersecurity detection and response vehicle detection and response and data-driven applications. The upstream platform allocates the value of vehicle data empowering customers to build connected vehicle applications by transforming highly distributed vehicle data into centralized structured contextualized data lakes. And I'm gonna show that in a few slides more thoroughly. And of course, upstream customers include some of the worlds leading automotive OEM suppliers and others protecting millions of vehicles. So let's talk about Red Hat OpenShift and the upstream cloud agnostic architecture. So first of all, let's see how the platform is built, how the flow, how the data flow go through the platform. So data comes from many sources as we've mentioned before. Data comes from telematic servers, from the vehicles themselves, from applications. All of this data requires a serious data engineering and data ingestion flow in order to make it, to make good use of it in order to protect it, in order to have services upon it and other application. So the first phase is this data is going through is data normalization and cleansing. So we are cleaning the data, making sure that unsorted data even in real time can be sorted to a specific extent and make sure that the data is unified in order for us to make sense of it. After that, we deduce a digital twin from this data. Now, digital twin, imagine yourself in the actual vehicle state is like it's a virtual representation of the vehicle. Now that has its own challenges because for instance, if the velocity of a vehicle was 80 miles per hour before five minutes, is it still 80 miles per hour? If that's the last signal we receive. So you need to manage and maintain all of this state and to make sure that it's still relevant and it's still up to date. And after that, based upon all those signals and the digital twin, we have an AI artificial intelligence power detection where we detect anomalies and cyber attacks and other forms of models that utilize the data. Up top of this platform, we're building applications. So we have cybersecurity application that first of all, most guards and protects the vehicles and the servers. We also have advanced analytics and other uses and other applications for the data, such as insurance, predictive maintenance, business intelligence, data quality validation. There are so many corrupted data that are getting that the OEMs are getting and our customers are getting. And also the ability to create third-party applications upon this data. So let's drill down a little bit more into the architecture. Now, one of the first biggest challenges that we have is that we are being deployed in the customer's virtual private cloud usually or virtual private cloud or on-prem. We cannot say, okay, we rely on the cloud because we sometimes can be deployed on AWS. We can't deploy the GCP, we can't deploy on Azure. And we even can be deployed on-prem. So how do you handle this kind of a challenge? So let's go over a little bit into our components and see how OpenShift helped us in this challenge. So we use Kafka, obviously Kafka and not something like dedicated stream platforms, but Kafka because we can deploy it everywhere. So we use Kafka for the ingestion and message brokery. So we have messages that are coming or all messages that are coming from all of our sources. It goes through a macro server, a macro service that's doing the parsing and normalization and all of that. By the way, macro service is a term that Uber mentioned because when you have too many microservices it's hard to maintain. So sometimes it's good to unify them and have a clear interface with a clear domain over each macro service. That's what we did. After this normalization and ingestion there are clean signals and unified signals that are going to a new topic. And of course, after that there's the processing, detection, enforcement and so forth. We are using Redis for state store, POSPUS SQL for entity, business entity storage, makes sense because hierarchical entities are built like that and it's much easier to query than with SQL. We use of course logs uploader, machine learning models in our data lake and we use Presto or to be more accurate Trino in order to query this data and also for our machine learning and machine learning operations. So that's a drill down into our architecture. This architecture we utilized with OpenShift in order to have it as much as cloud agnostic as we can. So upstream was designed to run over cloudage for structure agnostic as I've mentioned, AWS Azure GCP using HELL to deploy and install upstream platform and supporting third party app components. Upstream utilize cloud services such as POSPUS SQL DB, Redis, object storage and here we found the OpenShift operators equivalence out of the box. What happened is that it actually replaced for us the managed services that we used to have from the cloud. So if we wanted a managed service instead of that we could have used an OpenShift operator and to know that it doesn't matter where we deploy it we know that it will act the same and it will remain the same and that's super easy to maintain when you have this trait. The OpenShift advantages that we've seen are many. So the first advantage that we had is ease of use. Deployment of operators shortened upstream time to deliver end to end full blown solution because now you have a marketplace you can deploy operator and that gives you a functionality that a managed service used to do without rely on a specific cloud provider. We have an operator marketplace which is a very large place where you can find most if not all of official releases for cloud native services and applications and it's one click deployment. It's one click deployment and you have this operator service which is again, super convenient. Deployment, we use help. OpenShift is based upon Kubernetes obviously so help works here out of the box. Support deployment for best practices of cloud native Kubernetes application. Maintenance, we have also built in metrics in OpenShift console that provided us better visibility and overall view of the running workloads. It was really easy for us to see what's happening in our cluster because of the OpenShift console. Security, I think this is one of the biggest ones. So we all know how big advantage OpenShift gives to security. So the fact that we were able to run in separate projects easy to segregate and the segregation which is easy to segregate between two projects easy to assign user roles and control access was great for us and was great for the customer that were hosting us because they could sleep well at night because they knew that we don't have a domain permissions. We have a segregated project and we knew that we can't herd their cluster in any ways and it gave us peace of mind. Also wild card, the ability to work and get the SSL for free without managing the certificate not work with the Astrid.cluster.openShift with on all the routes within the cluster again very simple, very straightforward. And multi-tenancy which it can be deployed in a multi-vendor cluster with no cluster level admin permissions which we can run multi-project on the same cluster with different permissions of user which I mentioned before we have a specific customer that that was a must requirement for him and OpenShift allowed us to do so. And again, to allow them to sleep well and for us as well with the full segregation and not hurting other vendors that are deployed there. Furthermore, eventually, I could tell you without of course mentioning the customer that we had a very big OEM, very big customer that we moved our platform due to its specific needs more than once we moved it from Azure to on-prem to GCP. And all of this was really straightforward due to the fact we had OpenShift we had platform as a service built in for us for deployment and with our cloud agnostic architecture all of it fit really well because our architecture I think almost all of it without maybe the outliers is fully agnostic it's fully cloud agnostic and we needed good replacements and OpenShift provided this to us. So to deploy and to have a single code base when you have an entire R&D department that maintain single code base and still be able to deploy yourself in so many different forms that's a great trait and OpenShift helped us utilize that very well. So that's basically OpenShift and cybersecurity and data management platform that we did. There is of course some time for questions and answers from the audience. Thank you Gil, great presentation. I'm just looking at any questions. Meanwhile, I had a question for you regarding what are the kind of challenges you found while running upstream platform using OpenShift? So this actually was a challenge that eventually became an advantage. It's a great question. So the fact that in one of our customers we were running as a guest we didn't have any root permissions had some of our components such as machine learning operates for instance being a little bit more complicated because we didn't have all the permissions we need. But what it allowed us is to do the configurations and changing in order for all of the platform including this MLOps to run without root permissions. So we actually evolutionize the platform to be able to run as guests completely. And that takes us to the next level because that actually helped us being even more agnostic not just agnostic with the cloud but even very lightweight with the permissions required to run the platform which is very convenient and it's very important when you deploy yourself in different customers that again security is very important for them. So that was a challenge that we eventually made an advantage. And also I think you touched upon an important point to you had to change the cloud multiple times sometimes from GCP to Azure and all the... So how important is the cloud agnostic? Was that a one-off case or is that how we have architected your system in terms of being cloud agnostic? So to be honest, at the beginning, obviously, I mean, I think everyone that comes to develop data platform data engineering platform some kind of way especially in our days wants to rely on a specific cloud at first because you get a lot of things for free you get a lot of managed services you get a lot of good stuff for free and you can rely upon that. But very soon we saw that this is not feasible due to the nature of our customers due to the sensitivity of the data due to the fact that we need to be extremely flexible. So I would say almost from the beginning when we started designing the platform we thought about we need to be cloud agnostic to some extent. We didn't believe how bigger was the extent that we eventually did because eventually almost each component, we've said, okay, listen, we have to find a replacement for this managed service and eventually we've made it. That's what exactly what we did. And OpenShift, as I mentioned, helped us with that because wherever outlier we had which was, okay, listen, we need that we could have replaced with an operator in order to have this piece of mind. So eventually component after component a piece after piece, we almost did the entire platform to be cloud agnostic and that was super important. It was crucial for our business. It has many advantages. It's the flexibility of the platform is amazing. And that's one of our biggest advantages. So yeah, it was very important. And I think we knew that we need to have that. Again, the other option was to maintain multiple R and D departments and code bases. And I don't think it's fun for anyone to do that. I didn't want to do this. So I think we've chosen the right alternative. Yeah, great. I mean, to say the cloud technologies are evolving so fast on a day-to-day basis and also maintaining your platform to be agile. I think that's one of the USBs of any platform providers. Thanks a lot, Gil. That's it from my side. Just checking if there are any other questions. So there is one question that came from JC. Can you give us an example of what kind of vulnerability can be reduced or detected by data normalization and cleansing in this architecture? Oh, of course. Unfortunately, there are many. But let's just say, for instance, injection, okay? You can have a SQL injection into the car. You can have even that or SQL injection to the telematic server, for instance, or some kind of a tag chain. All of those things in order for you to analyze and to understand an anomaly, or for instance, let's just say brute force attack, okay? In order for a detection platform to understand if it was an attack or just big amount of messages that came right now, you need to analyze the pattern. The machine needs to analyze the pattern to understand the anomaly. In order to do so, all the data that you have from all the vehicles and specifically from a specific vehicle and from the servers and from the applications needs to talk in the same language, needs to be unified. If it's not unified, you cannot start doing machine learning models upon that. It's very hard to identify patterns upon it. But once you clean the data, you unified, you put it in a unified schema, you can work upon that and you can start doing advanced things. One of them is anomaly detection and attack chain detection, for instance. Hope that answered your question. Thanks a lot, Gil. Great presentation. Thanks for clarifying the questions. And have a nice day.