2 hours 35 minutes
All right. Welcome to less than 3.2. We're gonna be talking about software and hardware requirements when it comes to vulnerability management.
So in this video, we're gonna talk about determining what your software needs are in your organization. It's really important to vulnerability management. Um, how you're gonna consolidate and eliminate hardware? Uh, how end of life software can affect your organization. We discussed some of these elements and last less. We're gonna dive a little deeper here.
Um, and we're gonna talk about what executive leadership needs to know
about tech refreshes hardware, software, all that good stuff to help make really good decisions. When it comes to vulnerability management,
so suffer needs.
You know, it might seem like a no brainer. Every piece of software requires updates, but it's true. Um, you know, I've seen in some instances where
add Mons will install different versions of wire shark everywhere. They just have different versions of wire shark all over the environment. It's like, wait where we only using the same version where we all using the same updated version. Why aren't we pushing that out to everybody?
Eso um any of those, uh, require updates patches and that increases your threat or risk profile. So you need to be aware of those things keeping your architecture and design teams in the loop have them involved in vulnerability management. That's really gonna help you. Um,
when they're looking a different software to implement, integrate to help improve their I T. Or infrastructure,
uh, having them be part of that vulnerability management group.
We'll always help to understand what the software needs are for the group
on then your vulnerability Management s Emmys. They can help to determine more secure software. So it's possible. You know, maybe someone from I t Architecture comes over and says, Hey, I really want to try this product. You know, I think it's gonna really improve process or functionality will your vulnerability management SME, your security engineer could come in and say,
You know what? This isn't This is good software, but I think we have a more secure option here. This is has the same functionality,
but we know it's patched off in. We know who built the software. We know how it's built, and this could be a more secure solution.
Um, and then again, that consolidation software needs How are you? How is your organization? Even using software. What do you have? Why do you have it? Um, And then and then you can use those threat modelling techniques to help to address those software concerns. So figuring out what's offer we have and then saying,
you know what? Let's take a look at this across the environment, figure out what we have. Let's use these threat modelling techniques or frameworks to address any of those software concerns
hardware considerations. So if you're still using on Prem, uh, you probably you probably at least have some hardware on site. Even if you are using maybe some cloud resources, you may still have some desktops, zero clients, something that you're using. Eso figuring out what you still have on site
can really help you figure out,
uh, kind of what's going on in the environment
and considering those diar sites as well. Because even if those sites, let's say
you have a cold backup or warm back up, you're not even a hot site where everything's up and running all the time. Even if you have a warm site, those systems should still be patched. They should still be part of your patch management process and all those vulnerabilities associated should be part of your risk profile. So making sure we know what what hardware we have,
every different type of switch firewall, router storage. They're all gonna require software or firmware updates. So being aware of all of that different hardware and knowing what's gonna come out because that effects your patch management and vulnerability management as well, you know, it's not just Windows OS. It's also hate what routers, air reusing
are using 15 different types. Why do we have 15? Why don't we just try to use one
that'll help cut down on upgrade times?
Can anything be decommissioned? I know I've seen in lots of different, uh, server rooms. There's lots of equipment hanging out, some of its being used. Maybe some of its not Maybe, some people aren't using old applications anymore that are on these older servers. Maybe we can d come them and just get rid of him that we don't even have to worry about it.
A Z being needing being patched or
needing that to add to our risk index.
Um and then, of course, we're gonna identify what's most critical to our infrastructure. You know, off those 12 routers, do we really need all 12? What are we using them for? Um, so? So that'll help Teoh identify those critical assets in your infrastructure
and a voice software. I'm definitely gonna bring this up again as we go through this, because it's ah, it's so critical to make sure. Um, we understand what our end of life software is.
I know I've seen this as one of the big challenges where even if you know, depending on your maturity, let's say you have you gotten to the point where you have your product list your approved product last year approved software list and you say I know everything I have in the environment.
Well, do you have all the versions of everything that you have in the environment? You know? Do you have Adobe Flash 24 25 26. What do you have in the environment? And are they end of life? What's going on with them? Are we still using Java? Six. I hope not. But if you are, uh,
we need to know When did it go? Eea. Well, when is it going to go end of life, you know, having that foresight saying, Hey, you know what? I know this Windows 10 versions go go End of life in June. We need to plan to upgrade way before June. So by March April, we need to have this upgraded.
It can have major implications on vulnerability management on. And as I mentioned in some of the previous lessons, there are other ways that you can secure end of life software. But if there's any way that you can get away from it, it's good to have a plan in place called Poems. The Plan of Action and Mitigation
s. So that way we can actually mitigate, um,
that end of life software and those threats associated with them,
uh, upgrading software that should be part of any five year business plan. So when we're talking about it from an executive level, knowing what end of life software you have, what needs to be upgraded if it can be upgraded or if you need a new product entirely, you have to get rid of this one. That should be part of the business plan, because we can allocate funds for that
on and make sure that we're lowering our risk index
identifying system owners You have seen some really great system owners. They know exactly what products they have in the environment. They keep track of what's going on. So that way they know how to mitigate and when. But that way they can keep track of end of life software, you know. But then I've also seen in cases where
there's no way to upgrade the software because of certain customer requirements or certain business requirements.
So what can we do to secure those systems at that point?
Uh, licensing costs? Those were usually affected with innovative software. You know, it's possible that we couldn't upgrade because we couldn't buy the license for the latest version. You know, I saw that challenge a couple of times when it came to upgrading from Adobe 11. Teoh Adobe, D. C.
You know, Lou, new licensing had to be purchased, and it was done in a new way, so it was difficult. Teoh allocate the funding for that figure out what we need. How do we download the new license? We have to build a new package. So it's all those considerations that come to identifying those costs. And if we can identify them earlier knowing when things are gonna go end of life,
that'll help reduce costs in overhead.
Uh, so that way technical staff can be working on those upgrades. If we know it's gonna go end of life in six months, that's great. We've got a head start. We know we've got six months upgrade. We can start working on that and fitting that into our schedule.
A ticket will refresh.
So there's a lot of great tech refresh ideas, projects, things going on out there that can really help to improve vulnerability management. So a lot of these I mentioned from a vulnerability management standpoint,
desktop virtualization. I'm a big fan of virtualization. I think it can really reduce administrative overhead. Uh, instead of having 500 desktops to manage, you've got one image to manage, and you can push that image out to all their virtual desktops.
And if you have an issue with a virtual desktop, you just delete it.
Create a new one from the same image. Everything's Patchett's. It's much easier to, um, from it from a system administrator perspective than trying to patch desktops. It's because some of the desktops. You're gonna have to go out and physically touch a few virtual desktops. Virtual desktops I have to do is log in.
Check that desktop deleted if you don't need it and create a new one
application virtualization in the same way that desktop virtualization can be done to virtualized your OS level, you can also virtualized applications.
One of the ones out there makes off happy. You can go ahead and, um,
uh, virtualized your applications to the desktop. That way, you don't have the burden on the actual desktop. You're hosting it on servers on the back end. It's much easier to manage and patch those applications. If they're not actually installed on the desktop, you can just do it on the server on the backhands. Easy done. No problem.
Cloud storage. I'm a big fan of cloud for a lot of things, but you do have to be aware that you are probably still gonna have to patch your servers. But when it comes to server management and image management,
it can definitely help to reduce costs and improve it from an administrative perspective. You know, you have one image managing a bunch of servers much easier to manage. Then you know, just having a template in creating a new server. New server, new, sir. It could just It can be a little bit easier. You just spend up servers and take him down as you need,
uh, image management. So that's part of that. Even if you're using a tool like S E C M. You know you can really update and create a lot of, uh, take away a lot of the Ministry of Overhead when you're managing one image, and you are installing the patches on that image as they come out. You can patch your systems,
but patch your image, and that way you're constantly updated. If you need to re image something,
you're always have the latest version
application way listing.
This really helps limit the amount of applications that are allowed to be installed or run.
It can create its own unique challenges with
Maybe somebody needs a new application. Maybe they need to run a zoo meeting instead of a go to meeting something like that, and they can't download the installer, so those could be those kind of issues that can kind of be hammered out as you're developing your application white listing instance. But it can definitely limit the amount of applications installed. And from an executive leadership standpoint,
I think it's really important. You can say, Hey,
these the only applications were allowed to run
and and that's it so that from that perspective can really cut down on overhead as well. Ah, segmentation.
Keep your development and admin environment separate. Different V lands different. Whatever you need to do to separate them, to, say network, segment them. Keep them separate that way. If, let's say 11 network was compromised, let's see your workstation network was compromised.
They may not be able to get to your admin environment because you have that segmentation and that can. That can
make all the difference when we're talking about vulnerability, management and remediation.
So into these video, we talked about how software requirements could really affect vulnerability management,
how teams can identify and consolidate hardware.
How to address end of life software reduced that threat profile risk profile on Ben How you can conduct a *** successful technical. Refresh all the different components in different types of tech refreshes that you can use to help your vulnerability management process,
and that's it for this lesson. I will see you in the next one