Hi, I'm Matthew Clark. This is less than 6.2 vulnerability management and patching part one.
In this video, we will gain a perspective of vulnerabilities and patching by discussing vulnerability. Management will also review CVS and the Patch Process and conclude by reviewing Samayoa. TSF recommended controls. So let's get started. So let's start with the perspective of vulnerabilities. How did we get here?
Well, let's take a look at the law supply and demand.
Brian Krebs has a very interesting article, published on October 15th of 2018, entitled Supply Chain Security is the whole enchilada. But who's going to pay for?
In this article, he discusses how important supply chain security is.
But if security is done correctly, the product would be more expensive,
he said. The following consumers would almost certainly balk at buying these way more expensive devices.
Years of experience has shown that consumers aren't interested in paying a huge premium for security when a comparable product with the features that they want is available much more cheaply.
Why would I o t devices be interesting to Attackers? And why should consumers care? Staying with Krebs on security, Let's dive into the economics of a botnet attack
and 2016 Krebs on security was a target of Adidas attack from the Rory but Net, which used over 24,000 coyote devices such as routers and security cameras and video recorders.
The attack lasted 77 hours, with up to 620 gigabytes of data per second being thrown at the website,
so no lives were lost. An immediate impact was that people couldn't read Kreps latest tantalizing security article. However, there was another, more subtle cost. Ah, University of California. Berkeley's report found that the attack against Krebs on security cost coyote device owners
in power consumption and bandwidth. That's $13.50 per device,
according to a 2018 Kaspersky lab research. DDOS attacks can cost S and B s over $120,000 and larger enterprises over $2 million per attack.
Those amounts have had to increase since that last report,
so Adidas is certainly one reason why I o. T devices would be interesting to it. Attackers and consumers. Putting the bill of the attack should care as well.
But what about consumer expectations?
we discussed marketings effort at creating a low friction environment when developing a product
consumers have come to expect and demand low friction controls. In the article cited earlier, the University of California, Berkeley report pointed out that lax security controls from I o T. Manufacturers and Low Consumer Expectations a tribute to the security problems found in I o T devices.
on the manufacturer side. Many devices run lightweight Linux based operating systems that have opened doors for hackers.
Consumers actions to contribute to the insecurity of I O T devices.
Consumers who expect I ot devices toe act like user friendly plug and play conveniences may have sufficient intuition to use the device, but insufficient technical knowledge to protect or to update it.
Finally, we've covered this topic before, but it's worth mentioning again.
I O T devices in general tend to stay around. And let's use the example of a smart refrigerator in your home or office.
The National Association of Realtors estimates that the lifespan of the average refrigerator, for instance, is between 14 and 17 years.
So right now you're smart refrigerator, maybe receiving updates and security patches. But for how long can you reliably say that will be maintained 10 or 15 years from now.
And even if the refrigerator doesn't have a vulnerability discovered in the next few years, security posture changes over time. For example, what happens if an office worker plugs in an Ethernet cable into the refrigerator or configures the wireless
six months after it was delivered and set up in an office environment
that would defeat the It's not connected argument, and we've spoken about vulnerability management before that. It's not the easiest thing to handle, even for the enterprise. Vulnerability Management is just part of the basics, but no one ever said the basics were easy,
and it's typically easier to find a vulnerability than it is to respond to it.
And the i o T realm. True, management requires action across the entire ecosystem, not just a single device, which would include firmware and device and Web and mobile applications, the A. P I and so forth.
And it's a it's either a never ending task or it's a task that never starts
and install the latest patches, a refrain that you hear most often when it comes the latest malware, or ransomware, attacks
and is that we demonstrated in our previous lessons. It's not easy to bolt on security afterwards, especially if that security hasn't been designed in from the start
and building a patch is a process. It's not an event that could be scheduled on the calendar like an invitation to lunch. I could just imagine that conversation with one of the developers. Sorry, I can't make that appointment from 1 30 to 2 15. I'm scheduled to locate a vulnerability backcourt someone else's code.
Review the licenses to make sure we're OK.
Running through change management testing and approvals, commit the code, update the documentation and upload the final code to 75,000 deployed devices. But you know, I'm free at 2 30.
Okay, I admit that last one was probably a little facetious, But here's another example. Thio Consider.
I know I am develops an I O T. Device and lots of people of it. The big box store orders thousands of them and put them in all their stores and airport kiosk. Everything is great. The CEO is happy, the shareholders air happy. It's raises for everyone.
However, the next day your software developers find a vulnerability in the a p I that's used for your trust on first use process. You know that process that's used by the device toe on board,
and they determine that fixing it will break the authentication for that process,
and patching it afterwards doesn't really do you any good for all the products that have already been shipped.
So what's the classic enterprise security approach? We'll fix it right? The risk is too high. We have to fix it.
But what about all those devices at the big box store?
You know they need that broken a p I to complete the on boarding process and fixing it breaks that process.
And therefore there is a risk to making the products that that big box store turning a bunch of useless paperweights. So what's the business going to Dio?
I won't answer that last one immediately. I'll give you an opportunity to think about it some,
but let's say that the organization decides to go after CVS. Well, there's a couple different options that they've got for handling that, and this charge listed out I've given credit for it because I didn't come up with this myself below the chart.
They can ignore them. They can handle it through a manual process. They can try to use an open source vulnerability, tool or purchase the tool that gives them automation.
But whatever choice that they saseidx for handling CVS is gonna be something that that organization, the Simpsons Organization, is really gonna have to think out. They're not gonna be able to go out and just spend money to buy their way out of this problem.
And once you have identified two CV and you decided to fix it and issue a patch, then you need to have an internal process. But what if that vulnerability was not found by your internal developers, but by an outside person? But what are you going to do? How are you going to receive that notification and how are you going to process it?
And finally, let's say this so called security researcher gives you an arbitrary date to get all your mess cleaned up and he chooses 90 days. What are you going to do and how are you going to communicate with him?
If it sounds like I'm throwing lots of problems out there without solving them, well, it's because I am because These are the types of things that the sip so is gonna have to deal with working with other members of risk management,
because patching is never easy. Good security just doesn't age gracefully. And there's lots of issues like and I've only listed to hear component dependencies and license restrictions. But there's even Mawr, which we've discussed,
and thankfully, this is where framework comes in. For example, here's some of the things that the I. O. T. S f recommends that you do, and there's even mawr to address the problems that we've identified.
This is something that the sip. So we'll have to sit down and work without with the business, develop a strategy to address how to handle vulnerabilities and how to handle security researchers. And we're going to get into the vulnerability disclosure here in a couple of lessons and point out some of the ways that you can address this
Well, that's it for this lesson. So what do we cover? Well, we took a brief trip into the mysterious world of vulnerability management patching. We talked about vulnerability management and details. We also discuss patching of I O T devices and covered CVS and we reviewed the I o T s f controls. I'll see you next time