IoT Bill of Materials Part 2

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

Video Transcription
Hi, I'm Matthew Clark. This is less than 5.7 I ot build materials. Part two
in this lesson will discuss product design, the BSP and the SDK.
It will continue our discussion of supply chain.
We'll also take a look at a case study for urgent 11 and briefly review some security controls. Let's start a discussion with the term out of box experience. This term tends to illustrate how difficult a product is to use when you first pull it out of packaging.
Well, hardware typically comes with both board support packages or be SPS and software development. Cancer SDK s. And it's really not an either or proposition, because either both are included or you can download one or the other from the Internet.
And both of these air used to communicate with the board or chip that's used on the I. O. T. Device in an effort to make it a little bit easier.
So if I were to make this a simplest possible, I'd say that these work like this their pre programmed code snippets with tangible results like they If you use this specific code, it'll make our led blink, um, this way or that way, and that's probably too simple of an explanation. But it should get us started.
There are a lot of similarities between sdk S and B S P s. Both contain the basic same basic components. Their code snippets. They have drivers, support libraries, utilities. The main difference is that the BSP sports hardware
the VSP, provides a standard interface between hardware and the operating system via device driver.
And the BSP does not access the hardware directly, but it contains a boot loader of boot manager, the kernel image and the root file system and usually supports bare metal applications.
Ps, ps oftentimes have hooks in the hardware accelerators for encryption support, whereas the SDK probably has more of a library support SCK smite reference An algorithm that's not directly tied to hardware sdk support hardware and software and they generally have tool change such as GCC s
plus ah number of potentially large libraries that are built for that target architectures.
So sdk s could be quite large in size.
Sdk zehr, usually built off standard interfaces such as bios on day eased the creation of applications generally by having a compiler and debugging er and sometimes a software framework included and embedded together.
Another way to look at the difference between the two is SD case. Hide the hardware because they use abstraction, whereas ps ps expose it
when version 2.1 of a software dependency module has a vulnerability. Theo AM is not gonna upgrade that software to the latest version such a 6.4, because that might break existing code and introduce bugs into the OT product.
More likely, the OM will upgrade that software if they do anything at all to the same version with the patch, such as 2.1 point one. And this is the same as it is for firmware as it is for any other type of software.
In their previous lesson, we introduced the concept of a backcourt, and this is basically what the OM would be doing.
Let's take the B S, P S and the SdK s as a quick example, and we could just as easily be talking about other outdated components in the operating system or software package or just about anything.
Hardware manufacturers often build products using reference designs found in B. S, P S and S T case the issue is that these boards of war packages come as is, and they haven't always been updated when vulnerabilities were found in the code or the utilities are the drivers that they're used as part of that.
So when the OM product engineers designed to build a product, if they use the materials that come with the board or downloaded from the board manufacturer's website or get hub repository somewhere, it means that if they're not corrected, there may be vulnerabilities baked into the product from the very beginning. Furthermore,
the board support package may not ever be updated
even when a new operating system comes out or a security pact is deployed for an existing operating system.
And let's say that the OM device manufacturer does decide to update the device with a new or past operating system,
then the kernel changes in that new operating system could cause existing drivers and board support packages to no longer work, which means that the product engineers may be required to then also update existing drivers as well as code taken from those B S, P S and S D case,
as well as any other custom software that they may have previously written,
and this may be required for each new revision of the operating system.
That is, if the OM where to keep up with the new revisions for their I O T devices, which many coyote devices don't manufacturers don't really do right now.
Remember, the consumer Iot devices might last only a few years, but industrial Iot devices are expected to last 10 to 20 years, and that's plenty of time for significant vulnerabilities to be found.
The Sooner Type
report that we reference in our previous lesson
found that the older of the component, the more likely it would be toe have a vulnerability. And components less than three years old have a 65% fewer known vulnerabilities.
So this means that the longer the code is out there, the more likely will be toe have a vulnerability.
You can probably see where a product managers might be getting concerned about the future product support cost and have any of these things been budgeted.
It's also important to note that usable code and drivers and utilities are not always available for every third party sensor or component driver that's used by the O. E M so many times. The device, oh am will need to custom code those from scratch, in other words, making back ports for that existing code.
And this doesn't account for any of the licensing restrictions, since third party components are usually license for a pre built function, and the license may only allow for that. Devices use with a certain version of an operating system or colonel. And this is a lot of work
similar to releasing a new product version. And it doesn't always necessarily bring any new revenue to the OM,
and we haven't even added the first new feature to the product. Another issue that is that device, so EMS have with updating components is that it may not even be feasible toe update a specific, vulnerable component because of an interdependency between another component.
Some components may require the older, more vulnerable component in orderto work. Properly and again, licensing may restrict or used to that vulnerable component,
So this is not an easy process. And remember, we haven't added any new features or capabilities to the product yet. All we've done is the very bare minimum to keep it secure.
This is a great time to bring in URGENT 11 is a case study.
Inter Peak Network created a custom TCP poppy stack called the Pipe Net,
and they license that stack out to multiple vendors of embedded operating systems.
And this became the main not networking stack in the Wind River V X Works, which is an embedded operating system used in billions of devices.
It was also used by many other companies across multiple industries, from NASA to Rockwell Automation.
Well, when River acquired Inter Peak in 2006 and stop supporting I p. Net
when rivers end of support did not stop all these other manufacturers from continuing to use i p. Net.
In October 28 19, the FDA made an announcement about 11 critical vulnerabilities that were found in I. P. Net. The vulnerability made it so that a threat actor could basically send a couple of custom packets and end up getting root access to the device, which, of course,
concerned the FDA that that vulnerability could allow anyone
to remotely take control of a medical device and change its function or cause it to act in a way that it wasn't designed to.
Security. Researchers found that the urgent 11 vulnerabilities were in many products made by companies such as Vieques Works by Wind River, a BB Avaya, Honeywell G E Healthcare, Netapp, Rockwell Automation, Seaman's Opto 22 Phillips,
Xerox printers,
Sonic Wall Firewalls and Trend Micro. Just to name a few,
which affected all kinds of products, from scattered devices to industrial controllers and patient monitors in rhyme machines. Voice over I P phones and printers and even more
so it's a member of The Simpsons team. What are some of the controls and activities that you would recommend that would mitigate some of these concerns from urgent 11? Well, if the first thought was build materials, then ding ding u n Well, what else could we do?
Well, security awareness is a is a good option for product engineers and application developers. Relative to be SPS and sdk s. A swell is probably helping product managers understand potential cost for fixes,
as well as code reviews and vulnerability testing and penetration testing as well.
And one quick note about code reviews you need to connect ongoing security reviews of products you know, toe. Look at the risk, however, software developers need to have the ability to see security issues while still inside their integrated development environments.
It's best if they don't have to leave that environment in order to perform security functions. We can't make security hard for them and then expect them to follow through. Security has to be seamless and their many products out there that integrate well with their development products and help them to be able to see security issues as their writing code.
Well, that's it for this lesson. So what do we do? Well, we took a brief trip into the mysterious world of software building materials. We reviewed the product design, including B S, P S and S D. K s, and we discuss the impact on the supply chain and investigated urgent 11 and some appropriate things we could do to help with that.
I'll see you next time
Up Next
Manufacturing and Provisioning
Vulnerability Management and Patching Part 1
Vulnerability Management and Patching Part 2
Vulnerability Disclosure Program Part 1
Vulnerability Disclosure Program Part 2