8 hours 10 minutes
Hi, I'm Matthew Clark and this is lesson 1.4 I o t. Product Security Part two.
In this lesson, we will continue to look at the i o T product lifecycle. Specifically, we will learn about the people involved with I o. T. Product security
within organizations and will set some based on roles for the purposes of this class.
We will also investigate the product design process and discuss identity and secure operation.
We will introduce the I. O. T security frameworks and finished with the discussion of I. O. T. Security Economics. So let's get started.
So let's talk about the people that are involved.
Every company is different titles and different roles.
What is called a certain role in one company is going to vary to the next company.
So for the purposes of this class, let's just take a moment and identify some common roles, and we will list out their responsibilities that we're assuming that this role would have just again just for the purpose of this class. So, product engineer, When we talk about these, we're assuming that these are the people who developed the product that do the
the work Thean work. Maybe they're in engineering organization,
our new product development organization,
product manager. This is the person that would position the product. Maybe they would approve what features go into it or help set price points.
Product marketing. These are the people that market the product,
Um, does have a management structure along with stakeholders, and these would be shareholders or board of directors.
And, of course, there's customers, regulators and security professionals.
And we're going to talk about how to set up a product security program what resource is a required and how that product security compares to enterprise security all of that in module to.
So this image is generic product development process image. And I wanted to show this to you early in the course so you could kind of see how the course will be laid out in the information that we're gonna bring into it.
And so, basically, Ohms used the design process in order to bring an i o t. Product idea from a proof of concept through engineering, design and manufacturing, prototype
and implementing pilots and eventually move into a mass production. Of course, the design process isn't linear. It's more intuitive, meaning that the result is achieved by repeating the design cycles.
As a probably security leader, you need to understand the fundamental security concepts that are required to secure and i o t device in the ecosystem that it resides in.
So hopefully this course will help you see that it's really, really easy to say all that I o T device should be secure. It's a lot harder to actually think about it and figure out all the different steps um, that you need to do. At least it's harder to do that unless you have a framework and a strategy which we're going to go through.
So it's critical that the OH am ensures that there's a proper plan in place to provide device security from production through operation and eventual decommission.
This means working with product engineers early in the design process.
Provisioning of production could be done by either the O. E. M or a contract manufacturer.
Either way, ah process has to be developed to securely inject identity into the device while keeping secret safe,
secure shipping operation concerns itself with starting the device in a secure manner, operating it in a secure manner and providing patches and other security updates throughout the lifetime of the device
frameworks play a key role in device security
frameworks helped achieve secure by design principles.
And we're gonna identify various frameworks and use them to illustrate how secure by design principles should be integrated into an I. O. T. Device product security program.
And these include the O WASP Top 10 for I O. T. The I O T. Security Foundation framework and various ISO and this standards.
Although we will introduce several frameworks, we will most heavily rely on the I. O T. Security Foundation framework.
Now a framework is important because it gives product security program structure. It gives the hardware and software engineers clear understanding of requirements.
It helps identify and re mediate vulnerabilities in the device design before the devices ever created are sold,
and it helps communicate security in a way that is actionable.
Lastly, security certainly has an impact on cost both the cost to build the product as well as the cost to support it.
It's important to realize that consumers have a unique perspective on I o T. Security. They're just simply not willing to pay extra for it.
They're going to purchase the lowest cost product with the appropriate number of stars and the most positive reviews.
And it's because of this behavior that the industry really hasn't self corrected. At least not in the consumer device industry,
where security is more mandated, such as health care or financial or military industries. Security is being more conscientiously built in. For the most part,
therefore, evidence suggests that regulations and laws or what's driving, changes that we're seeing, and we'll talk more about that amount. Seven.
But regulators, air starting t demand a certain based security be built into products.
And we're seeing this in the new laws, such as the California and Oregon i o T. Laws,
where the term reasonable security is being legislated.
And no, um, they're starting to react to this downward pressure by implementing products security programs.
Well, that's it for this lesson.
this is a graphic of how the last two lessons fit together
in this lesson. We discussed the people involved, including product engineers and managers. We discussed the product design process. We discussed identity and some of the concerns of secure operation.
We introduced a few I ot security frameworks. Specifically,
we noted the I O. T. Security Foundation framework, and lastly, we discussed one of my favorite topics. I ot economics while I'll see you next time.