November 17, 2022
In this joint webinar with NXP, Natali Tshuva (Sternum CEO) outlines a pragmatic foundation for an embedded security model based on runtime self-protection, and Lian Granot (Sternum CTO) demonstrates how Sternum could be easily installed on NXP LPC55S6x MCU board, and how - once active - it could immediately boost device security and observability.
Below is the recording and the transcript of this talk, and the link to the deck:
Rachel Lockwood: Hello everyone and thank you for joining today’s webinar. I am Rachel Lockwood from NXP. Today we’re joining our partner Sternum to present the topic, Bringing Security and Device Level Insights to IOT Products with NXP’s and Sternum’s Technologies.
Our presenters today will be Stella Or, Security Product Manager from NXP as well as Natali Tshuva and Lian Granot, co-founders of Sternum. Natalie is the CEO. Lian is the VP of R and D and as of last week also the CTO at Sternum. So thank you to each of our presenters for preparing and for joining us today.
We will have a live Q and A session at the end of the presentation. So as we’re going through this material, please enter any questions that you may have in the question box of your GoToWebinar user interface. Once again thanks to everyone for joining the webinar. I will now hand the microphone over to Stella to kick off the material.
Stella Or: Thank you Rachel. Hello everyone. I’m Stella Or, the Security Product Manager of NXP. So today we are going to go through these topics here. First of all, I will go through some key elements that we need in the security solutions and I will highlight some security features of an NXP microcontroller in our software enablement.
NXP provides you with a secure platform for your application development. After that, we will have Natali present Sternum’s runtime security and remote device observability solution. Lastly, Lian will run a demo on an NXP LPC55S69 device to show how Sternum’s technology can catch the exploitation of application software and how it can be fixed right away without deploying patches.
Also, you will see how Sternum provides you the visibility of the device and at the end of the last, like the last 10 minutes of this webinar, we will have a Q and A section.
So how can we build secure solutions with NXP devices? So here are some key elements of a secure platform. First of all, you will need a secure ROM Bootloader. It is an immutable bootloader from a processor. It runs on authorized code from being programmed or executed by the processor.
It also ensures the integrity of the product in it. After that many applications, it requires a second secure bootloader. It can be used for application code verification, integrity check. It is also needed for future updates. For example the over-the-air update and secure key storage. It is the secure area to protect secrets and sensitive information, for example encryption keys.
We also need device authentications, image, crypto, image encryptions and verification. So these are used for IP protection and conflict detection.
Tamper resistance is any method we try to react to a tamper attack. For example we can have a secure package on our device, on our processor. We can also have some kind of measurement on the software, especially on the cryptographic algorithms to prevent some attack happening.
We can – some of our NXP device, have tamper sensors which can provide an active response to the attack. For example to erase any sensitive information or secrets storing in the part immediately.
Lastly we’re also concerned about the – we also have some concern about the industrial standards that we may need to conform. So for example it could be common criteria FIPS, PSA certificate and also the SESIP. So we may also need to think about is the processor designed to conform to these standards.
So security is a big concern in many industries. NXP has been offering many microcontrollers and microprocessors with security-enabled features. Since our demo today is based on an LPC55S69 device, let’s have a look on the security feature of this MCU.
So you can see from the block diagram I highlight some security features in this MCU and let me go through some of these one by one. So the secure bootloader, it is the major component to ensure the root of trust in the product. Secure bootloader is resigned in the ROM of the MCU. It is immutable. When the MCU boots up, the Secure Bootloader performs application code verification and integrity check with RSA or SHA algorithm.
An unauthorized code is not allowed to be loaded and executed in the MCU. With the right design of a second bootloader, secure OTA, secure over-the-air update can be achieved through wireless connection.
TrustZone, it is used for code isolations. It creates a boundary to separate the secure and non-secure world with delicate memory allocation. So application code with user interface such as test screen, LCD, audio output are usually considered as unsecure code. It should be stored and executed in the memory in the unsecured world.
On the other hand, OS, operating system or kernel or some security-related peripherals are considered to be put in the secure world. TrustZone forbids the code from the – from an unsecured world accessing the memory in the secure world.
But the physical and codable functions is a delicate S-Frame used at the dedicated RAM as the silicon fingerprint just like the human fingerprint. Each device is you need fingerprint. We can use the path to generate, store or to reconstruct these.
Crypto blocks, these are the reasons, so – for security device to protect your valuable access. You may want to protect your software IP and your secrets by encryption in digital signature.
The crypto blocks here consist of AES, SHA, CASPER, crypto engine which can be used for a code or secret encryption, verification and integrity check.
TRNG is the random number generator. It provides quality random numbers for key generation. It is important to have a list compiled in TRNG in a secured solution.
PRINCE is used for application code protection. Application code can be encrypt or decrypt on the fly when it is written or from the on chip flash. It supports putting of image from PRINCE encrypted flash region.
Secure debug authentication is a challenge and response protocol to authenticate the identity and credential of the debugger. Access right settings can be preloaded to the MCU before it leaves the factory.
The secure part of the device is non-accessible to the debugger until the debug authentication process is successfully complete.
Lastly the protected flash region. It is a secure region stored as secure boot configurations, root of trust key, trust and configurations, debug process setting and some user configuration.
So the PFR is in irreversible area once the configuration has been set. So here are some major security features that you can find from an LPC55S69 processor.
So we just talked about the MCU and also NXP we provide some software enablement that help you to develop a secure solution. So our platform, the MCU, we also provide the SDK. It has some examples like the MCU example.
It has the TFM examples and for secure software protocols, we provide like the Mbed TLS, Azure RTOS TLS, WolfSSL Embedded SSL and TLS protocol. For the runtime library, we support multiple OS. For example the FreeRTOS and Zephyr.
For the PSA certified products, NXP continue to working on any new products like the MCU products in the market. So right now we have some devices. They already got the PSA certifications, Like PSA level two and level three certified devices. These are a set of device they got the certification approval from PSA.
Since we talked about the secret keys and the IP protection, NXP also provides you a secure provisioning tool. So that when you manufacture your products, you are able to generate some keys, doing some secure provisioning for your device.
OK. So, as we all know, security is a big concern. NXP provides you a secure platform to develop robust products. You can build your application software on top of it to address your market requirements.
However it is almost impossible for software developers to develop an application software withoutvulnerabilities. Hackers look for every single opportunity to hack into your design. Memory-based vulnerabilities are especially concerning because most memory-based attacks target applications.
Most applications security solutions focus on identifying vulnerability in the code, then deploy patches to the device in the field.
Regular patching of your products could lower the rates of your products from being attacked. However, have you ever estimated the time that you use for discovering a vulnerability and the time you used for developing and applying a secure patch to your products?
It is a time-consuming process with a lot of experts, resources and logistic involved. Moreover it is a stressful situation. You and your team need to run against the clock because your products are now at risk.
So enabling runtime security software in your products could help in improving these situations. Today we have Sternum’s Natali to introduce their runtime protection solutions and also the remote device observability solutions. So let me hand over to Natali. Thank you.
Rachel Lockwood: Natali, did you get the popup to share?
Natali Tshuva: Hello everyone. I’m assuming you can see my screen now. I’m very happy to be here. Thank you for joining and thank you very much Stella and NXP. This is a great way to present what we are doing together. I thought with – to start, we just explain a little bit about our partnership and what it means.
So actually when NXP reached out and said, “You know what, security priority devices is really important and what you are doing seems very interesting. We would like to see it in action,” we were amazed by the security knowledge that the CTO office Mark and Martin brought to the discussion and during that period of time, they’ve tested a standard solution in the most comprehensive way.
They crafted attacks. They tried to break our technology. They tested our overhead. As we all know, overhead and performance are super important in the IoT space and what they find out is that we were able to block each and every attack NXP crafted. We were able to prevent it. We were able to alert it with less than three percent overhead.
This is really the story of how Sternum became the only NXP partner that provides security, application security, software security and deep observability into NXP products, into embedded devices and embedded systems.
So this is just a breadcrumb and a little bit about myself really in a nutshell, started with computer science when I was 14 and that led me to becoming a reverse engineer and a cybersecurity researcher in unit 8200, which is the Israeli NSA.
From that point on, I just continued in the path of finding vulnerabilities in Linux kernel, in Android devices, in drivers, in bootloaders. That was really fascinating to me. Also developing the exploits, how to actually exploit a system. Not just find a vulnerability but take it to the next level of taking control over a device.
From that point, it was clear to me that no system is safe. There are always vulnerabilities even in the most secure systems and I asked myself, “What can we do?” because patching those vulnerabilities or finding those vulnerabilities sounds like an impossible task. This is how Sternum got to be and this is why basically I’m talking to you today about a deterministic way of providing the benefits of XDR, of endpoint protection, of application observability into the embedded space.
Sternum is already working with many leaders in the industry. Medtronic, TX group are only a few – some of the leaders we are working with we cannot disclose. We raised $40 million to date. Spark Capital, SquarePeg, top ten VCs in the world and we are really aiming to be the best IoT product.
Even though we won this award, we are continuing the improvement of our platform as we would like to really help developers, device manufacturers to build the best products they can build in a secure way and in an observed way.
A few numbers because we need to put it in some scope. So we have 127 new devices connected to the internet every second. That’s more than laptops. That’s more than mobile devices and you can just imagine the amount of data these devices are generating.
They can see what we are doing, temperature, video screens and so on. They are responsible for so many things and we got so many of them. So imagine just the challenge of understanding these data, gaining insights from these data.
Just in the past six months, we had 1.5 billion IoT breaches and we know that the spending on IoT security is growing and continuing to grow and there is regulation kicking in. There are lots of efforts, lots of attempts to understand what it is to be secure. But still we are seeing that attacks are continuing and when actually we are doing such a good job securing IT devices.
It's not so simple and we will dive in this presentation into why it’s not simple, why it’s not as easy as other things and why it’s important to secure them. But first we have to ask, what will happen if an IoT device will get hacked? What’s at stake?
We see three major elements that contribute to this question. First IoT devices being so widely spread and so diversified became a really attractive entry point to the enterprise network.
So enterprises for your customers, with building devices, the customers that are buying those devices put you liable to the security of those devices because they don’t want the video recorder or the security camera or the printer in the organization to become an entry point to the entire enterprise network.
That’s one thing why we have to remember that even if the asset itself doesn’t seem like the most critical asset, we have to secure it. The second is of course if there is a publication about your vendors’ products being vulnerable, this could lead to ransomware attacks, reputation implications and actually many companies that suffer a security breach do not recover in the five years after the breach. And of course infrastructure - IoT devices are part of our medical devices, our railway systems, our smart cities, our industrial systems. So those assets are extremely important. Even I would say the most important asset that we can think of are actually embedded systems. So we have to make sure that they are secure.
Now we have to ask ourselves about the challenges and why we are falling behind. So first we have to remember the limitations. IoT devices are not like any other server or endpoint or an application. They have limited resources. They can’t really operate an agent or have security solutions.
We have high diversity, different operating systems, different hardware. Even within NXP, there are so many different modules and products that can contribute a lot to the diversity of the application running on the hardware.
We are highly dependent on supply chain, on third party libraries, Bluetooth libraries that will cause you a few bugs in the task. No one ever used the Bluetooth library without having a crash and these actually contribute a lot to the complexity of the security.
We see that vendors are mainly relying on patching and defenses like static analysis and things that are really passive and really the trivial things to do that do not really provide real-time protection and also has a lot of implications that we will review.
Of course there is no on-device XDR or EDR solutions that are popular in that space. You can’t buy Crowdstrike and put it on your embedded system. The implications are really varied but a few to mention, manufacturers are caught in an expensive cat and mouse game with security patches.
With some industries that are single patched can cost like $2 million to produce and to update. Your developers are in a loop of integrating patches, verifying that the patch is working well and then rolling that into the market.
By the time the patch has been rolled, most of the vulnerabilities could already be exploited. Also this does not provide any protection from zero days and some IoT devices cannot really be updated.
So we spend a lot of money. We only protect ourselves from known vulnerabilities and we do it in a – not in a timely manner. Devices have no proactive protection from zero-day threats.
So every other asset you can imagine, cloud, laptops, PCs, email, everything has real-time protection preventing threats, preventing zero days, identifying malware.
We don’t have that in IoT devices. There are only a few companies. Happy to say some of them are market leaders working with Sternum that protects their devices at the endpoint.
Third party software vulnerabilities open the door to supply chain attacks and I don’t need to really elaborate on the past year supply chain attacks that you’ve seen. IoT devices are extremely vulnerable to that.
Lastly, high overhead requirements force engineers to make tradeoffs. I want to release fast. I don’t want this software to hurt the performance of my device and so on.
When there are tradeoffs, developers will always choose performance and I encourage that. First you need to build a device or product that is working well.
The challenge is how can we bring security that make developers not choose between the two. Now I want to give you a glimpse into the hacker’s view. What hackers think when they start attacking a device and I took a real life example.
There is an exploitation video in YouTube. So it’s publicly available. Hacker on the internet. Downloading a publicly available exploitation of a zero day – was a zero day. Now a one-day vulnerability, stack overflow. Downloads the exploitation, finds a Cisco router, business router, connect it to the internet.
Probably miles away from the hacker and exploits the router through these publicly available exploitations. The router obviously did not get the patch yet even though it’s a known vulnerability. Now the hacker has full control over the device. He can disrupt service. He can move into the enterprise. He can perform a ransomware attack on Cisco. Having control on many devices and so on.
Of course he can steal IP. He can leak data. So endless possibilities and that’s a one-day attack that we’ve seen on YouTube from this year. So the vulnerability, this stage is something that we keep seeing. They will not disappear.
But what can we do to actually protect those devices without constantly patching them? Now I want to say a few words about observability. So what you can’t see actually can hurt you and in the IoT space, we have a lot of black box defects. We have some basic device data like where my devices are, some fleet management, some device management.
But we don’t really have device level visibility once the devices are shipped. If you imagine companies like Datadog and Coralogix, they bring you visibility into every aspect of your application. Buttons that are being pushed, quality issues, performance issues, continuous monitoring on customized logs and metrics.
You don’t have this standardized observability or application monitoring solution for embedded systems. Everyone is building their own and have very limited, usually not real-time data with no insights.
The lack of resources including bandwidth also means that we need some more accurate and effective solution, purpose-built for the IoT. The implication is that we have no visibility into performance and security events in the field.
If someone is hacking you, you don’t even know about it. If someone is selling your devices in places you don’t want them to be sold on. If someone is reverse-engineering your IP. If your devices are crashing, it’s very hard to perform remote debugging.
Partial data is causing root cause analysis delay, resulting in a really long time to remediate and even more so without having data from your products, you are lacking some essential insights to produce the next generation of your products and to make business decisions.
The implications of – or let me say the values of observability are pretty obvious in the IT space, in the application space and still we are behind when it comes to the IoT space.
Now these are just general information but now how Sternum can help. So Sternum is a universal on-device platform for embedded systems and we provide three key elements.
First, embedded security. We make devices secure by design by applying real-time protections into the firmware, into the software. It’s embedded inside. It’s a full endpoint protection and it runs on real-time operating systems as well as their metal as well as Linux systems.
It will help you prevent attacks in real time and alert you if something bad happens. We will dive into it in a moment. The second element is real-time observability. You can get granular device level visibility of every element in your software, logs, metrics, events.
We have a C-only lightweight SDK that is portable to every system. You can get started in one hour. So our customers are embedding the SDK and within a few hours, they have full observability platform on their real-time operating system device including third parties within the device.
Lastly, gathering the data and seeing it in a visual way is nice. But the real challenge is to generate insights. Sternum provides an anomaly detection engine that is actually self-learning the data that you chose to collect.
By learning about your data, we alert you on malicious behaviors, abnormal crashes, abnormal CPU values and everything that you can imagine that is out of the original pattern of the device.
This can actually streamline root cause analysis and speed up debugging, understanding what’s wrong and so on.
Now we will take a quick look into the security aspect of our platform. In a nutshell, those of you who know what RASP is, runtime application self-protection, it’s a way to make software self-protected. It is very common in Linux kernel, Windows kernel, providing memory protection, providing elements that makes exploitation harder.
Our security makes sure to put integrity verification checks around and inside your software to provide runtime protection. It is agentless. Therefore it is very low overhead, less than three percent as NXP tested.
It mitigates known and zero-day threats in real time. It protects all of the third parties. If there is an attack attempt that we prevented or detected, you have the live attack information including all elements in the attack, IP addresses, who attacked you, what happened before and after, what areas in the memory are vulnerable. If you have a memory leak, an information leak bug, we will alert you on that as well.
It seamlessly works with both Linux and RTOS and we have a very smooth CI/CD and IDE integration. Don’t worry. If you are asking yourself how they do that, how is this thing even working, we have a really elaborate demo to walk you through exactly how it works.
But just the eye level of how we actually prevent attacks. So Sternum instead of focusing on vulnerabilities, what we invented is the exploitation fingerprint. Basically it’s asking when there is an attack, how the exploitation itself looks like.
So let’s take a memory attack for example. You can see here that memory override is listed here and Stella mentioned many of the vulnerabilities are memory-based vulnerabilities. Heap overflow, use after free, double free. But preventing all of them is almost impossible. But if you ask yourself, “OK, I have a memory vulnerability. How is the attacker going to exploit it?”
Then you realize that in order to exploit in heap overflow, you have to overflow the memory. There is no way that you can exploit a device without overflowing the memory. What Sternum is doing is focusing on profiling the memory in real-time and preventing any overflows from happening, any corruptions from happening.
By doing that, we can alert you on potential issues early in the development life cycle. But also prevent zero days from being exploited or untapped vulnerabilities from being exploited in real time.
That is just one layer of our security. We have an additional layer that keeps the execution flow intact, making sure that no code is running from the memory, no code is running from unallowed sectors and so on and lastly, we have a layer that provides malware detection.
So we detect if your device is suddenly communicating with unknown IP addresses or someone is trying to steal the passwords on your device or there is a brute force attack attempt on your device. These are logical vulnerabilities that we identify using our anomaly detection and visibility platform.
Altogether, it’s really an end-to-end solution that can obviously bring a level of security that’s never seen before in the IP space.
Now let’s take the same example and imagine that Sternum is inside. So what we see here is that we’re using the same vulnerability. Nothing has changed but now this device is protected with Sternum.
No reaction is required. The whole flow is being prevented on device autonomously with no internet connection, with no cloud that needs to be involved. Notification has been sent. Forensics have been shared. You would see this in the demo.
Plus – and this is an important element. We can alert your enterprise customers of the attempted attack attempt. This is a very simple API integration and your customers can get the alert directly to their SIEM, XDR or any other solution.
Now instead of being a potential breach to the enterprise, you are providing a management console that helps them view the cybersecurity health of your products and this is a potential added services for you as a company.
Observability seen inside the black box. I will round really quickly on that to leave enough time to do the demo. But as I mentioned, we have a very simple SDK. You can implement it into every platform. It works for Zephyr, FreeRTOS, Micrium and VxWorks and everything that you can imagine and all the data that you’re collecting and defining is automatically synchronizing with the Sternum cloud.
Anomaly detection is activated directly on this data. The kind of things that you can collect includes user interactions with the device, errors, logs and debug information, battery health, resource consumption, temperature, pressure, loop time for critical functions, which could be really valuable and of course working with Sternum, you will get a full list of recommendations. What you should be collecting and now our anomaly detection is putting an extra set of eyes on those data that you define for your product.
Now we automatically can alert you of lost communications issues, on patterns that are being violated, on high pressure or on any kind of abnormal behaviors that you can imagine.
This of course helps your preemptive detection of emergent quality issues and even deeply understand the root cause analysis of the bug.
Now when it all comes together, I want to give you a use case from our customer, one of them. So during development, they use Sternum and suddenly they uncover a few security flaws and code vulnerabilities. Specifically with a memory leak and a vulnerability in a Bluetooth library. This was only found using our dynamic profile feature during development and design of the product.
Not to mention the rich information they got from our platform about different elements in their software.
Post-market, they had an issue of disconnections between their device and mobile application. Using Sternum and device-level data, they were able to quickly resolve it and access the live device information in the field.
Lastly, they saved around 50 percent of workload reduction due to less patchwork, freeing up developer resources. Imagine the last vulnerabilities we’ve seen Ripple20, BlueBorne all of them was prevented automatically and natively by Sternum.
By the way, I invite you to read our blog post about the recent OpenSSL vulnerability which we have prevented also natively and automatically, putting our customers in a safe place without requiring any patch.
More than six million annual cost saving on fewer CAPAs and support issues that were solved and of course faster time-to-market due to speeding up debugging processes.
To summarize, Sternum helps improve product performance, quality and security in one platform that combines different elements that takes you from building the device, by spotting security gaps, use granular device level insights to resolve the issues and to improve engineering velocity and we will show you some use cases of that in the demo and makes third party libraries safer to use.
When you deploy, we simplify the deployment and management of those devices. Device IDs are being generated automatically. Fleet level management and device management is automatically deployed with your device profile.
We can catch emerging issues using our AI-powered anomaly detection system, issues in your deployment, in software updates, in crashes and reboots and so on and speeding up remote debugging and post-market surveillance.
Lastly, we help you innovate by helping you focus the resources on development instead of patch management. We help you generate insights from the existing devices in the field to help inform future design choices and even business development elements.
We make device security tangible for your customers, for your enterprises. We provide continuous monitoring of the cyber health of the device with real-time alerts on any potential attack attempts that make security not just something that you need to prove that you are doing but something that is tangible, touchable and can be seen on a cloud platform.
Now thank you very much. I will pass quickly to Lian, our CTO, who will present a really cool demo of how Sternum works on NXP product and will show you our platform including the device deep level information and some real attack attempts.
Lian Granot: Thank you Natali. My name is Lian. I’m the cofounder and CTO of Sternum. Today I’m going to demonstrate to you how we integrate Sternum EIV into an existing solution, how we collect traces and send them to ADS and how the Sternum prevention security mechanism works.
So let’s start with integration. To integrate Sternum observability and runtime protection, we will protect your entire firmware including third parties you need to follow three simple steps.
The first step will be to include the Sternum utility in your firmware. You can see it here.
The second step is to include the Sternum out of the box profile in your system and the final step is to actually – it’s select EIV to run and protect your firmware once your build is finished. We are doing this here, the fourth build step. You can see it right away. Once we do it, the project will be protected once you click “Build” and that’s it.
Now let’s integrate those abilities that we have into the device. We start by adding a trace in this area of course where the project is determining that Wi-Fi connection is in progress. We have to create the Sternum ADS API. So this is the API. We just invoke it but now we want to indicate what event is going on.
So we will go into the SDK utility and in this utility, we can create new types of events if we want to report. For example we will create a new event that’s called “Wi-Fi connection in progress”.
OK. Now what the utility did, it designed this event in ADS, in the cloud platform. It also designed it in the project. So now our encoding which allows optimized data to be sent over the internet is getting action. So let’s try to use the event we just created. Wi-Fi connection in progress. OK. Now let’s build it.
OK. We’ll go to the board. Now I’m going to flash the firmware. OK. Now we can go to ADS. We have the device inventory and we can see that our device is communicating with ADS and we have to click on it. We just click “Show Data” and now we have the same devices booted with the task being open on the device.
You see the priority at this left side but you also see the event that we just did. Right after that, you can see the SSID that we connected to the IP address that we got and your information about the device. So this information is very useful. You can use it to debug. You can send errors to generated devices and that would be collected in your entire fleet. You can collect metrics like CPUs usage. You can check what is the battery usage.
You can check how fast it is depleting. You can calculate your average time that the device takes to connect to Wi-Fi network. So you can gain any type of analytic and any type of observability and deep observability into your entire fleet but also Zoom in into a specific device as well.
Now let’s deep dive into ADS now in general. On the device inventory page, you can see our entire fleet of devices of all types. You can manage multiple types of devices.
For example here, you have the LPC55S69 that we also have IP camera – I think that we mentioned. So we have different product lines all automatically managed in ADS. If you want to get a general analytics and you find your own metrics to continuously monitor, you can go into the “Glances” here. Here you can find any glance and you can monitor any method that you would like and you collect from a glance.
For example let’s take a look on the top SSID in use. Here you can see the top SSID in use. We just go into the Wi-Fi connected trace and then go by the SSID. So now we get the most used SSID, a full query for the last year. We will see multiple exercises that they even used. We can understand which ones are the most common.
But that’s only one example. If we’re going to the CPU metric, you can see if you are calculating the maximum CPU usage of a process through ADS. So we can see how we stretch our device. We can also define multiple viewers, multiple dashboards. For example I’m going to the IP camera this time. Here we see completely different information regarding the graphical location of how many request and general activity all the time.
You can see also the top IP addresses that the client connected to and you can continuously monitor more and more metrics and you can add more and more and to improve our observability and on every iteration and everything on the list and also just doing integration, adding more and more traces to this process we’re …
OK. So we covered ADS. I want to show you how Sternum one-time protection works. Let’s get back to the project. So we had a couple of special commands to this project. These commands can be rebuilt remotely. So the device gets the device hosted on AWS.
Let’s go over on this again. In this example, we added a special command that’s given MQTT device, we are going to send a special payload [Phonetic] into that command and we will see how we perform those attacks on this device. We do stop function. Let’s do that now.
First I’m going to flush the unprotected firmware into the device. OK. Let’s reboot. This is out of here. Initializing on the right side, you have the attack console with the payload that will exploit the vulnerability inside the device and …
Here we can send it down. You will see a special activity from the device and you can see them into the device. But now the device is completely stuck and unresponsive.
Now we are going to attack the protected firmware. So let’s flush the protected firmware. Go over the same process. Choosing the protected firmware. OK. Let’s reboot the device. OK. The device is rebooted. Now we’re going to attack the same firmware, the same way and with protection deployed. We’ve done the attack …
OK. So you can see the special activity going on the – now instead of ] being executed, a custom user callback is initiated and this contact is creating the security alert and the user decided to reboot the device. The user and the developer. So the device now boots into a regular state. Now its state, it’s in full functionality. You can see it’s reconnected today. It’s unbroken and completely protected from the attack.
So let’s see the attack here. OK. We are seeing a new alert here and also a new record in the alert list. Let’s investigate. OK. So we see that our runtime protection resulted in preventing the attack. We also get the memory address of the hacker and the originating code address screening that we can show you the function that the attack originated from. So basically we will not detect vulnerabilities.
But when we detect and prevent exploitation, we can guide you to reach vulnerable code that was used in the attack. So you will see that here. So you can have this information attached, zero day vulnerability. Other than that, you get the timeline. So you can actually understand what happened right after the attack. So we see a special MQTT command linked in the field in the device and right after that, we see a stack corruption.
If you go back a little bit in the timeline, you see which entity broker we connected to and which Wi-Fi network we are also connected to. So that’s a lot of information that will allow you to understand. What was the route of the attack? How it happened.
And we also see the special trace that we added in the beginning of the demo, the Wi-Fi connection in progress. OK. So we explore the Sternum observability and explore the Sternum runtime protection. Thank you for your time. Any questions?
Rachel Lockwood: OK. So thank you to our presenters for all the good information. Now I’m going to hand the microphone over to Marty from Sternum to read out a couple of questions although we are short on time. So Marty, I guess pick your best ones and we will follow up with every one offline for the ones that we’re unable to get to.
Marty: Right. Well, thank you so much Rachel. So some great questions. I think a good first one is how do we connect with Sternum to do a POC? So the best way to connect would be through email@example.com.
Those emails will come to us. I’m happy to arrange that. We will send that out in an email as well. Natali, are we on this one? It’s for you. How does Sternum help if you’re already using TPM or SE as an example?
Natali Tshuva: Yeah, that’s a question we get a lot. So TPM or SE are super important to store secrets and have secure elements running. But Sternum protects the overall potential for software vulnerabilities in both the application processor and the TrustZone or TPM. What it means is that the recent API between the TPM or SE and the application processor and APIs can contain software vulnerabilities and this is exactly the way to also steal secrets from TPM or SE.
So one way we help is actually making sure that the secure elements remain secure. That there are no software vulnerabilities that can bypass those protections, those hardware protections.
The second way that Sternum helps is the fact that you’re using TPM doesn’t mean that you don’t have software vulnerabilities in your application.
So basically imagine your Bluetooth library. It can have a heap overflow that can lead to remote code execution and someone taking over your device.
Maybe you won’t be able to steal secrets from the TPM but this is still not a very desired scenario. So Sternum actually helps do that, protect the entire device, the entire software running on the device and the entire libraries running on the device.
So it’s actually complementary to any secure elements that you have and this is also the reason why NXP and Sternum partnered. It’s a layer of hardware security and a layer of software security being on top of it.
Marty: Great, thank you. A question about regulatory requirements. So how can EIV help customers with regulatory requirements for vulnerability mitigation?
Natali Tshuva: Yes. So regular requirements are a bit different for each industry and we help with – to a few industries in multiple ways. So for example in the medical device space, we help to automatically put a checkmark over post-market surveillance over incident response over the requirement to be alerted of potential breaches and on patch management, which is a key element that we help with. It’s the same for industrial regulations and also the new way of the consumer label.
So a few elements requires monitoring, requires applying with certain levels of security and requires incident response and cache management. All of them are covered automatically by our platform.
Marty: Great. Well, I have time maybe for one more question. So is a free demo version available? So I can answer that. We do have an OpenWRT free version for three devices available on the Sternum website, sternumiot.com. We will also send that out with the answers but yes, you can test this on an OpenWRT platform. So I think that’s all we have time for. I will turn it back to you Rachel.
Rachel Lockwood: Wonderful. OK. Well, once again, thank you so much to our presenters for preparing this material and for being here to present and thank you to our attendees who joined us today. We will be following up with you to send you the recording, the information about how to view this on demand and we hope to hear from you if you have any questions. Thanks for joining us today. Bye everyone.
Natali Tshuva: Thank you very much. Bye everyone.
Stella Or: Thank you. Bye-bye.
Better Performance with Autonomous Observability
Gain complete visibility by monitoring and analyzing events in your device or across an entire fleet, from the first line of code and until post-deployment maintenance.
Diagnose software bugs and vulnerabilities by using instrumentation, to pinpoint flaws, gain dynamic profiling and analysis of the software, including third-party code.Learn about Sternum observability >>