Hi, I'm Matthew Clark, and this is less than 6.3. Vulnerability management and patching Part two
in this lesson will discover different update types will discuss over the air updates and identify three methods of it.
And they will conclude by talking why I can't drive 55.
There are many different types of updates, including automatic over the air updates in which no user intervention is required. Thes air generally cryptographic Lee signed so that you can Onley load the images from the O. E M. Maybe the device or reboot. Or maybe it want. You may or may not know about it.
The next type is over the air. There manually initiated cryptographic Lee signed updates. Um, different types of vices do this. It requires a device users to stop what they're doing. And to kick that off. Some of the security cameras that I use around the home provide that They tell me that there's an update and wait and wait for me to initiate it.
Of course, there's the over the air manually initiated unsigned updates. Uh, there's no signing at all, so you could load third party images, even malicious ones,
and then we have the manually updated binaries. Most likely this will acquire an out of band patch mechanism with some sort, and I don't think anybody really does these much. They might require a USB stick to transport that binary from whatever device downloads it from the Internet to that device itself.
And then, of course, there's my favorite yours, the no updates at all. Uh, this might apply with products with shorter life cycles or cheap products. The second or third market me to type products, Uh, maybe a product as seen on television.
Or maybe it's just a ni o t device maker that hasn't hired a sip. So yet
one thing about updates is that you have to get it right. You could break a $10 indoor camera, and that might be one thing. But if you break a $3000 smart fridge, well, that might be a little bit more painful. You're probably gonna have to send out a certified repairman,
Um, when you develop updates, regardless of the delivery method over the air, USB, whatever this ipso will need to work with the engineering team and product managers to determine the life cycle and limitations of that device. Some devices of sensor actuator maybe so simple that it doesn't require an update during its prescribed lifetime,
and others may need to be updated but will have varying degrees of risk tolerance. So let's run through some real quick definitions. Mostly should be a review. The two of them towards the end might not be
firmware. It's protected, immutable code right that enables the i O. T. Device function. It contains a boot loner, a curdle and a false system.
Boot loader should also be review protected, immutable code. Part of that route. Trust. It's generally injected during manufacturing and if up, datable three architecture should require some type of authentication, maybe a mutual authentication responsible. It's responsible for starting the device and a known good state and allocating resources.
Ah, Colonel also should be review. It's the core of a device Is operating system. It's really the intermediate layer between the device hardware and software
device tree. The Wikipedia definition. It's a data structure describing the hardware components of a particular computer so that they're operating systems. Colonel can use and manage those components,
including the CPU or soup use and the memory. The bus peripherals,
and the last one is a root file system. And of course, this is where all the files are stored. So let's walk through kind of a generic boot process on Day one jump and updating these
So the generic boot processor. The boot letter initiates the necessary hardware boot letter starts the colonel the device tree the kernel then starts all the required processes and services. The boot letter will stop. The colonel will mount the root file system, and the colonel starts applications that air in the roof. All system.
There's a great article by Drew Mosley called the Considerations for updating the boot loader over the air. It's published in a bed computing dot com, and I provided a link of the resource Is courage to read. It's great. Read
also, if you wanna learn Mawr and ready for a really deep technical dive on this topic, read the article by Benjamin Brown. I've also included in The Resource Is.
So for the next two slides, we're gonna drop Andrew's article, and we'll bring in what we've learned from previous lessons and kind of layer. That with what Drew has, um, secure updates, is a topic we've spoken a lot about. This is like a perfect time to try to bring it all together.
So in a basic over the air process, the devices boot loader will be responsible for interacting with the O. T. A client, which is an app in the root file system.
As pointed out in other lessons of class, we protect the boot loader, right? It's part of established, establishing a root of trust. If we mess up this process, we could energies vulnerabilities into the root of trust. We could weaken the overall root of trust, or we could just break the system.
So redundancy is a classic control that we employ in security. And I think we might need toe when, if we might need to update the firmware. Adding redundancy is generally a good idea.
This slide shows how designing redundancy into the I. O T. Device can help. So if something goes wrong during the firmware update process such as empowers lost her, the network connection is lost or there's just a bug in the process.
In this case, the boot loader has a secondary are permanent, fail over a colonel, the device tree of the root file system
by providing redundancy in the i. O T. Architecture, designed to provide a mechanism for rolling the device back to a known good state
and the boot loader. That really small piece of protected immutable code that we've talked about needs to be able to switch from a failed boot to a known good boot configuration in your mind. If you're you're probably thinking about how to integrate the TPM chip with its measure boot process, and and that would be a good use of the knowledge and trying to apply up.
There's other options that you can design is well, so let's see about those in the next slide.
So there's several different design options that you can consider for over the air. First is no redundancy, right? Option one. There's just no updates, period Option to. You don't need to update the firmware so you know and only offer application updates. Option three. You just roll the dice and on firmware updates, and so see if you need it or not.
Redundancy. Um, option one you can use a single boot loader has similar to the previous slide. Our option two. You can use a multistage boat boot loader, and we've discussed those and other lessons. The first stage boot letter with immutable code does change than the second stage changes. Obviously,
alternate boot loaders you can have an optional USB load. Boot loader. I think it's a terrible, terrible idea. Uh, just into introduces a new tech vector. Google, just full of stories about people abusing us peace. I just don't think about that
optional onboard storage. You could store second copy on a source that's immutable. That could be relied on to recover a failed due process
and the other sources up datable. Obviously, for example, with the root file system
to switch between the two boot options may still work. Our physical intervention may be changing a jumper or switch on this really ah, high difficult rating for users. Maybe hold down the reset button. That's a lot less difficulty. Most end users air used to doing that. So always ask yourself with how difficult is this gonna be for the end user
to do this? Another option optional onboard storage will be having a recovery partition with just enough logic to call home, like maybe doing over the air update server to report the update failure, maybe to receive a new update.
Uh, Julia burgeoning. Did a great job kind of outlining three over the air architectures for I O T devices. And she published a paper in Tech Target, which I've included a reference to it in the reference sections. Take a look at it. We're going to review these really quickly. The very first one that she came up with was edged a cloud over the air
and in this 13 i ot device would receive an update from the Ed Tape server itself.
It requires that the I o T. Device be connected to the Internet, generally through a native connection
where the outie device receives that update directly and requires It also requires the attitude vice be hardy enough to process the firmware in the software updates. And this is a great option for consumer based Iot devices like Amazon Alexa.
So when this next one, this is a gateway to cloud over the air, where I o. T devices and sensors and actuators are connected to a gateway.
So the gateway manages those devices and the gateway connects devices to systems that don't match the device requirements.
So in this one, the gateway would receive updates from the update. Remote update server gateways, firmware and application are updated, and there's no change to the I O T devices they don't get updated on. This is a great option for devices with really restricted hardware, such like low power devices,
devices that don't natively connect to the Internet,
such as industrial hyoty devices where communications really have to route through the gateway or devices communicating with, say, Bluetooth low energy.
This is also a great option for heavily regulated industries like healthcare finance or for devices that just don't need updating themselves like they're super simple actuator sensor.
And this drawing obviously demonstrates a single point of failure, which is would be the gateway.
So in this next architectural er, um, this is edge to gateway to cloud over the air updates. This is where the I O. T. Devices connect to a gateway that connects to the over the air server via the Internet,
and this looks a lot like the previous slide. But there is one major difference.
An edge to gateway to cloud. The I O. T devices receive the updates to firmware and applications, and the gateway does not receive any updates.
This is great for hardwired access to the Internet or for instances where the gateway is limited.
At the beginning, I said that we would discuss why I can't drive 55. So here it is a $70,000 over the air car. Example.
The new 2020 Corvette sports over the air software updates, and there is a problem with the trunk.
Owners were accidentally hitting their key fobbed opened the trunk and the trunk was located in the front of the car. And because the car smart, it knew that if the trunk was opened that it needed toe limit the maximum speed 82 MPH while the trunk was unlocked.
Um, because 83 miles and hours obviously too, too fast to go for a car
with the trunk being unlocked,
especially if you're just casually cruising through the shopping center parking lot. So, evidently, some Corvette owners didn't like that speed limitation of 82 miles an hour, or the fact that the front hood might violently open while driving down the road. So GM designed to fix
or nearly a car owner would have to drive to the dealership to get that software reprogrammed. However, the over the air fix changed the sequence required from the key fob to activate the front trunk.
Eso the the owner had to press it more than once, so to speak.
So if you asked me for a $70,000 smart car, I would have expected the car to be smart enough to close the hood, right? If the notice that was open, um, eso I would be safe while obviously cruising around the parking lot at 82 miles an hour. But that's probably just May.
Have you ever Googled new Corvette? Go fund me before? If not, it's highly recommended. I'm sure it's for a good calls. Just look for the one that last name Clark. Well, that's all for this lesson
in this lesson, we concluded our trip into the mysterious world of vulnerability management patching. We talked about different types of over the air updates over including over the air basics, redundancy and design. We talked about three methods of over the air updates, and we wondered, How do I get a go fund me page just asking for a friend who likes Corvettes