Hi, I'm Matthew Clark. And this is module to I o T products security programs.
Well, congratulations. We've completed module one.
This slide shows our progress towards our certificate of completion.
So let's begin our new module with less than 2.1 foundations for success.
You know, I really like bubbles. I still like bubbles. I liked him when I was younger, and I like him when I'm an adult. I think that they're pretty cool.
And the thing about bubbles is when you first look at them, they all look the same.
But when you look closer at them, you realize that they really are. Each one is unique. They have different sizes. Some are larger, some are smaller. Cem connect together and make really cool shapes.
Um others, you know, float really high in the air and some of them afloat, really down low to the ground.
And when you look at the think about the world of I, O. T. And the different devices that are out there, those devices really are unique, is well in the way that they interact in each one of these industries is also very unique.
and it's something to think about and keep in mind that a Z go through this course. And as you go through your career and your considering different piece of security, it's always important to use what you've learned in your past. But always keep yourself open to think about new new ways to do things, um, new risk. That may be out there
as conditions change.
So there's different characteristics of success that I want to go through. And a lot of this kind of centers on the PPT people, the process and technology and all three of those really work well together. Toe Dr Security.
So, for example, let's start with people. You're gonna need someone, Um, of course, an executive side. You're gonna need that leadership support in the I. O. T. Security Foundation really outlined some of these key roles that you need from the people side to be very successful.
You're also gonna need a role designated to lead the program. You just can't do it by committee. You can't just hire people and say, Okay, this group of people while you build a program, I also build a product. I also want you toe considered insecurity and welcome. Here's another hat to wear
Andi. That's the thing about people. The more hats we give them, um,
the more their attention is kind of divided between those different pieces of responsibilities, which is important, why we need to map roles and responsibilities together.
Racy charts are great for this right responsible, accountable, consulted and informed. Being able to map out who should be doing each one of those four rolls and making sure that you don't need that you have the right people in the right roles in order for what you're asking people to do to be successful.
Something else to think about, too, is process right, and there's lots of different processes that are out there
and on. The good thing is that on the enterprise security side, a lot of these processes have already been created. Of course, the bad news is that you just can't lift and shift. You can't take what its existing in the enterprise side and just apply it equally without changing it, um, to the i o. T products security, peace.
Is it just for example, um,
the process. You're gonna need a process to conduct risk assessments. And I put the example fair out there because, you know, I tend to think about risk assessments. Is something that there's a lot of different frameworks out there that say that you need to do it, but very few ways that actually say how you should do it and go about it. And I'm not a big fan of heat maps,
but fair is something fun toe learn about,
try to apply it. And, uh, it's a way to be able to make sure that you're you're really, you know, challenging yourself. A zit relates to risk assessments, and I think it works out well on the coyote products side as well.
You're gonna need a process to handle security incidents again. You have this already in place on the enterprise side, but it's different when a security researcher contacts your frontline support people to say, Hey, your I O t product, Um, I hooked a sniffer up to it, and boy, I can read everything right. That's that's a completely different
type of security incident
that you're gonna need to build a framework for. Another process could be just issue security advisories, right? Once you know that there's an incident to fix. How are you gonna advise individuals, customers in the market
on how to handle that? And I could tell you that if your weight to the very end to be able to think this thing through, there's going to be enough other things happening
that's gonna make that very difficult. It's always easier to think about these processes and put them in place prior to the emerged when the emergency happens and you actually need it. And another one is the process. Third party suppliers and third party suppliers air so important that in the I o. T security
world, because they're everywhere and I love this quote here,
I'm a terrible cook on DSO. This quote is always giving me, you know, hope on this is from Laurie Colwyn. She's a cookbook writer. She said that no one who cooks cooks alone, even at her most solitary ah, cook in the kitchen is surrounded by generations of cooks past the advice and venues of cooks present
and the wisdom of cookbook writers.
So and this is very to me, this is this applies to coyote security very well, because in the i o. T. world. When you think about your third party suppliers, there are an awful lot of cooks in that quote unquote kitchen. Right. When you go to develop something, you pull software code in there.
There could be lots of different hooks and that software
with lots of different people, different libraries on different things that are out there that you may or may not be considering the security of.
So another thing to think about is the technology side, and technology is a big piece. Of course, the biotech, because we're building a physical products, says everything from hardware. Roots of trust, different types of communication software, tools to software development kits, right, different languages,
cloud automation. Whether you're using dealing with Google or Amazon or
Microsoft Azure, you've also got the security and the auditing and the Anna legs and encryption. It just goes on and on and all because of the technology side.
And of course, when we think about this and this is a really common thing that people the process and the technology right, it all fits together. Um, when the process and the technology worked well together, then you can automate, and when the technology and the people work together, Then you can innovate.
And when people in process work together, then you have scale, right? And then those magic magic moments
when you get the perfect PPT and it all works together, then that's like, you know, success. Nirvana, right? It's it's great.
But all these things, just like in the in the enterprise security world, these things, things work together in the allergy products security world.
Something else to think about to his policy. And I know that in light of the PPT, this is really part of the process side of the world. But for each one of those processes that you create, it needs to have an underlying policy behind it. And as policies air really important because they help the Enterprise work together.
So, for example, you're gonna need a program charter, right? Ah, wayto something that says, Hey, we're gonna be doing i o T products security
And the enterprise is behind this, and senior management is forward, and they've given us the authority to act.
You're gonna need an established security framework
on the enterprise security side. You're gonna have a framework like NIST CSF or maybe even the critical security controls.
You're gonna use a different framework for the i o T. Products security. But those two frameworks need to work together under the same umbrella. And the good news is that there's lots of mapping things that are out there already. That you can use
risk management is another good one to think about, right? There's probably processes for doing that On the enterprise side. You you have risk management and probably enterprise security rolls up under other types of risk management for the enterprise as well. On DSO, you're gonna want to make sure that your I o t. Product security
risks that you have identified,
um, also roll up a swell
vulnerability disclosures, right? How to handle that? You're gonna need a policy for it. And this is for how toe how a security researcher would communicate a vulnerability once they find one. And then how are you gonna handle that disclosure once you receive it, right, Who's gonna look at it
twice? Updates That's another good one, right? I mean, the policy's just go on and on things to think about
and again. Programs is another area to think about. So
in the world you're gonna need. GRC is a good way to think about these programs. You're gonna need a governance program to make sure that you're doing the things that, uh, doing the correct things right. And they're doing being done in the correct ways. Um, risk management side everything. The risk understanding, risk, appetite
to conducting risk assessments and threat management
responsible disclosure, right. All these different pieces that you have within the risk world
developing these these individual programs on. Of course, you're gonna need a compliance program, right? And that that's basically just doing the things that you say that you're gonna be,
um and so all these things work together.
So in this video, in summary, we identified the characteristics of success of what do successful product security programs have all in common. We took a look into the people process and technology, the classic PPT triad and how that applies to the i. O. T. Product security world.
And lastly, we talked about policy and governance and risk management and compliance
on basically, you know, doing the things that we say that we're doing and making sure that they map back to the enterprise.
Well, that's it for this lesson.