Joe Comyns - Patch Management...It Ain't Brain Surgery

good morning it's about time to start so thanks for tuning in to patch management cornerstone and cyber security my name is joe cummins i want to start off by admitting this is a selfish presentation it's a collection of things i have learned over the last 20 years that make my job easier most of the content is based off basic computer practices if you've been working in it for a few years much of the content will sound familiar it really is about managing basics but the spin i want to put on it is how to manage is how managing these things can help reduce the time and energy it takes to run a monthly patch process turns out those things

also help reduce time and effort for some security processes as well most of the presentation is black and white except for a few color color slides see if you notice them i was also intrigued with slide transitions so warning someone might be a little goofy the first group of slides about me where i worked what i learned next group of slides is about those things that relate to patching the last group is about the process and how those things can affect it so you may ask yourself because i ask myself this all the time same job for 20 years how did you do that well fortunately i landed a few great companies along the way

and the tools and techniques used to secure workstation have changed enough in that time to keep it interesting i've also been consulting on the side for decades the evolution of securing a business is constantly changing you must be ready i spent hours researching new technologies investing investigating patch issues researching vulnerabilities and keeping up with the latest cyber security news at this point i'd like to find out who i was talking to but i don't think i'll be able to do that so i'm going to assume that we are all interested in patching and that you have a process in place you might want to prove it or you're starting a process i do want to emphasize this is a

workstation patching uh process non-server but you know those processes are similar enough um this the concept should apply to anything that needs to be patched and i do use asset machine pc computer and workstation interchangeably it should make sense though so who am i um i've been involved in the i.t world since 1982 about 38 years experience i was educated northern southern ohio kirkland ohio about 20 miles east of cleveland and ohio university down in athens ohio my first job after graduating from lakeland with a mis degree was helping a dad's friend code he was about to retire he didn't want to learn a new language and i just happened to know or was learning that

language so we helped each other moved to columbus in the early 90s since moving to columbus i've worked for three multi-billion dollar companies and healthcare fast food and a utility most of my security was learned from an infrastructure group in a large utility like i said the group was responsible for everything related to workstation and mobility products i've never worked in a cyber security security group but i've worked on many cyber security projects i like to think i know what they do from a high level i participated in most security projects involved involving workstation security over the last 30 years patching antivirus hips pam mac ips ids disk encryption certificate authority data classification event viewer logging

secure ftp to policy configurations firewalls uh proxy servers i probably missed a few i i i i don't know all the gory details of all those processes but i learned enough about them to understand what they do for the most part my next slide has a corneal line on top um i've been doing patch management for it was a two-word term i started doing patch management probably late 90s but early 80s i said earlier as a programmer didn't like it too hard so i didn't work at it too much mid 80s i went to ohio university i worked in their labs at a pc lab and mac lab i went down there to get into the business school but my

grade point wasn't high enough and there was an alternate degree called the uh there's a bachelor of science in communication systems management csmt there's basically a business degree or a telecom degree emphasizing business so i learned some networking to go along with my mis degree from lakeland mid late 90s i in columbus i started off in computer rooms working the 8pm eight a.m shift last uh computer i worked in there was a pc in the corner it had tivoli af operator on it i started playing all that and automating a lot of stuff and sending emails and messages and next you know i was working in the pc world it was at its infancy at that time

so it was pretty good timing companies just started adopt computers uh all the good and bad that came along with it um during that time i upgraded some regional offices for a restaurant chain from windows 3 1 which was non-networking to windows 95 which required a network so we it was a project inventory the systems uh got the new uh pcs and the network equipment installed it and did that over the whole year late 90s up until now um like i said i'm a utility company an engineering group and we are responsible for hardware software asset management we evaluate recommend test and maintain it do os provisioning we create the image it goes on the pcs in our

enterprise i do patch management uh other people are grouped to privilege access pam privilege access management basically removing admin rights group policy software delivery packaging there's a group for mobility and all the vdi equivalents of all that stuff let's see so that timing see i just absorbed a lot of uh cyber security activities uh next slide um this was at the bottom of the last slide that other side was getting a little busy uh it shows the the life cycles i've been involved with you can see windows 3.0 to 3-1 you know patching was ad-hoc it was you know we put all the patches the image pardon me and then patched it once in a

while not too much when it was mt4 to 2000 i had developed a process a 30-day process but most of it was manual did a lot of scripting and um database work with recording all the data and then around uh you know 2000 to windows 10 it was a lot more automated you can tell i'm a windows guy microsoft has kept me employed for a very long time um all right so let's move on ninth okay this is why i started patching 1999 8000 pcs across 11 states in three locations when i first started patching there was no structure patches released when the vendor was ready firewalls antivirus and patching and some kind of email scanner passed as security back in

the late 90s most bad people hadn't figured out what to do with their skills and once they did figure out they could make some money with it that's when things started to get rough so i had to make some sense of the whole mess i had to create some structure i created a monthly process that started on the first of every month for example the patches released from january 1 to january 31 were used to create a set of patches that would be deployed after testing and i called that the patch badge so january patches were february's patch match short story is like i said i wrote vbscript to interrogate the machines see if the patches were needed

that were from the patch batch if so install them recorded that in the backend database so it could be rendered in the web page they downloaded from vendor the the downloads were from a vendor site to a dfs share that was had 12 servers geographically distributed across enterprise for faster downloads the data like i said was recorded to back in sql database and had a web front end so we can deliver some reports we had a monthly change control that documented all our work with different tasks from uh the different people that were involved there was a large contingent of field operations staff that did a lot of testing they weren't really application testers but they found a lot

of errors actually when they were doing it they found most here um and they found it because they were the ones that are responsible for fixing them if there was there so application management wasn't uh it was terrible there was no software development life cycle they never retired apps and there was plenty of different versions of the same app everywhere our group oversaw the assets the tools then were new we weren't really that good at it to be honest and you know we did what we could main thing was i was not allowed to force reboots for some reason that was just a part of the culture that reboots were frowned upon i guess i

don't know but let's change so let's move on flash forward to today um 19 000 there's probably 20 000 pcs i haven't updated for a while 11 states the locations have increased somewhat i am using a patching compliance module from a configuration management tool i use the one from avanti they're all the same it's a tool do the evaluations find one that has all the features you want to use and uh use it look for the automation features a lot of them do have automation features that can speed things up privilege access management was implemented in that time we removed admin rights that was big inventory was a lot better we got better using the tools and we

the machines we were in charge of getting client we put the clients on the machine so we were pretty diligent at that there was uh we still use change management to communicate and document the process uh you can see there's plenty of difference out there i'm sure your company has one but it is automated now so every i think it's on the eighth of every month it's automatically created with a number of different tax tasks with a number of different groups involved that's nice because it's all consolidated in one place the there are security groups now that are have a major influence in patching vulnerability management group is the one i work with a lot the closest with

and uh the sdlc the software development life cycle is it's a little better it's always been worked on it's one of the hardest things to get going but it is one of the things that is worth improving we'll get into that later so i went over these last set of slides things change and what i've learned over time is i like that little transition the solid patch management process makes cyber security easier i'm not sure if science out was right word so i should have said any so i learned to automate or what do you call it uh animate so i get any any patch management helps the gold patch management is to reduce the attack surface caused by hardware

and software vulnerabilities your attack surface is increased with every vulnerability that exists in your environment i found the easiest and most effective way to reduce the attack surface is to fix the vulnerability that's what patching does the driving force behind patch patching is a risk management decision based on your company's tolerance to leaving machines unpatched and vulnerable to attack if you have a low risk tolerance you probably want a fast turnaround in patching if your risk tolerance is infinite you'll never pass i don't recommend that just means that you're you're higher higher silence you're not going to pass patch as fast you got to decide what solid means like i said it's subjective so you want

it should your cycle be 15 days 20 days 30 days should you measure the timing patch can you get 90 saturation in a week two weeks three weeks those are things you have to decide and uh weigh toward what a solid is so how do you make patch management easier and cyber security easier there are three things that i'm going to focus on today remember that things and your quotes and that is software hardware and user managing these three things goes a long way to reducing your company's attack surface most of some of the information may not be new what i want to do is have you look at it from the patching guys perspective

so patching now to move forward we have to agree on what patching is and i like this definition i don't know i made it up i guess patching applying fixes enter updates to technology at set intervals to maintain and secure optimal operation uh notice that i did say technology i know it is my job was patching workstations but a lot of this can be applied to just generalized technology that needs to be updated and the intervals is what makes it a process

so i found this up patching becomes easier as a variance of things you patch decrease look at all the things you got you got to patch the windows os mac os and apps linux mobility apps hardware software apps all the apps for that third-party software network stuff database stuff storage stuff here's my another animation oh my it does get complicated and uh and a modern business large and small with remote locations and a web presence you know all this stuff is is there you need to patch it so this slide this uh one of the color slides it's pretty obvious it's a little abstract um does anybody know what this stuff has in common type it into the chat window there i

should be online uh these are the related activities processes and additional things that can affect the monthly patch process i don't think the list is all encompassing i i've been adding it and thinking over the years but i just added ai recently there was a scanner that had some new uh artificial intelligence functionality like a slider and they turned it up a little too far and it stops on my patch downloads i added cloud recently i did see some cool stuff on analytics where they can analyze your company and come up with a representative set of test machines that hits most or all of the applications in the environment uh the animals one i thought was

interesting we have a fiber network that goes down every once in a while because of gunshots and hunting season if a bird's sitting on a wire sometimes people shoot at it all right

whether whether is another frequent interrupter or at work utility if there's a storm the restoration uh efforts um they asked me to carefully monitor the patching during that time i can keep the west and east and south and north separate so it is a little bit uh easy to do that way i dns has been on there for a while but that's been in there for the news last week i guess we had there was an emergency patch that uh had to go out and it went out

that is the end of the first section now let's talk about the things these are the things that can have an impact on patching it's not a complete list just the ones i have time to talk about remember they can have a negative or positive effect depending on the size of your organization these activities could be a few people's responsibilities or many different groups responsibilities many of these points are based off processes that you may have up and running some camping some can be considered computer hygiene or maintenance asset management whatever you want to call it a lot of times this stuff gets overlooked or hasn't been looked at for a while later on i'll get into more detail

explanation how improvements here benefit the patching process all these points are relevant but the top three four have the greatest ability to influence patching those are three i'm gonna spend the most time on the last four i'm just gonna mention app management at some point in the future it's it will be the most critical thing to manage the virtualization of applications will allow apps to be run anywhere on any platform user management there's a couple things three things there admin rights permissions and auditing hardware management configuration hardware management some of the important things are configuration management and risk classification network uh condition network condition matters and you get pretty expensive to try to keep up with uh user demand

security products creative products can cause patching to stop think about it patching acts like what security products look for it hits a machine downloads a package exe or msi executes the downloads reports back to command and control if those products aren't configured correctly security software stops patching to some degree enterprise culture and c-level buy-in are a little more uh abstract but well worth the effort since uh culture directly deals with the end user all right so this is it managing applications standardized standardized standardized it's all about the apps get to know application support and development people apps are what business businesses run on it's all about the apps as virtualization takes over app management is going to be even more important

at some point in the future we'll all be supporting apps in one way or another the hardware layer won't be a consideration as much as it is today people get to work on whatever device they're comfortable with and virtualization plays a hard key role in that so with applications a software having a software development life cycle is a must application lifecycle called what you want is about manager applications and keeping production versions consistent and retiring old applications if i could work at a place that used one app think about it the attack surface is reduced you don't have three different versions of a pdf reader uh testing takes less time all the different configurations that

you should test it on but time permitting you do the best you can number patches is smaller so burden on the network is reduced having a formal support and testing structure in place for every piece of software is critical know who supports what hours of time can be wasted looking for who supports the broken app the disk data and risk classification apply a risk score to software products it's nice to know what applications are critical for operating the business that can help prioritize what to patch or maybe uh creating a special group for those critical apps could be a process you undertake to isolate them and make sure they get patched in more time and manner

assigning risk we talked about that who accessed what app and when that's identity and access management i'm using it as a general term it's powerful tools used to control and unlock access i firm believe you're in least privileged principle only give them access to what they need especially for process ids all this information that im gathers is help for doing treble resolution and to keep an eye on what users are doing especially if they have admin rights or you have to do some for forensics on a machine that's been compromised configuration management database that stuff's important let's you know uh software usage if they're not using it uh take it away sometimes license software can get pretty expensive and

people use it you can manage it through that those methods so managing software helps with testing deployment and network usage the user the two main points here admin rights and iam again understand the difference between admiration permissions think of it like this you can be an admin on a machine but you still need permission to access applications and depending on who you ask removing admin rights stops up about 95 percent of malware i think that's a little bit high but uh it's just a figure admin rights allow the user or the hacker to do anything they want in the system make it easy to give in remove admin rights you don't want someone who has just fired your admin

rights for a very long time especially if they're disgruntled evidence of what hackers and malware are after when malware is run with admin rights inherited from a logged in user or elevated through a vulnerability the malware hacker can do anything to that machine and depending on the network access of the uh right cigarette it may make it much easier to move laterally through your network if possible only supply admin rights when needed the principal at least privilege again and you could even take it further to the zero trust framework where nothing is trusted that's a pretty simple simplified explanation of it but the privilege of lease principle and zero trust frameworks uh take additional effort but they're

they're they might go outside of patch management they're well worth the effort mobility remember mobility that's a whole nother aspect of patching all the different mobility products out there and the access the user has and what rights they have some regulatory requirements require a business unit in a regular area have they cannot talk to each other we there's one in our area where we have an unregulated sign that can't talk to a regulated side so regulatory requirements are in consideration when it comes to users the hardware again standardized standardized standardized you need to understand what you're up against by having an accurate inventory of unique models and systems on the network each model usually has its own driver

set bios updates chipsets buses network adapters uh wired wi-fi you get the point remember the variance of things principle the more models running on the network the more effort required to do that to test and patch and track all the different vulnerabilities so standardization helps reduce the workloads standardized that's one thing i tell you about hardware don't have three different vendors minimize the choices it helps reduce the attack surface why have microsoft or ibm and lenovo and there all that different choices require a lot more testing a lot more patching just like a life cycle is crucial for software have a hardware life cycle it's just as important helps keep old and sometimes unsupported hardware off the network how

many years you should wait between the refresh is a risk management decision once you decide that should you forklift do it all at once do have a rolling life cycle do 25 percent of your machines every every every year uh that's something you need to decide um audit audit activities on the asset usually through event logs or you can use third-party software to do that a big one here is assigning a risk score based on data for data classification risk scores are determined by the apps running on the server or what kind of data is on the database helps you decide which ones to monitor more closely and helps determining your patching schedule usually putting the critical ones first

vendor relations has been in the news lately as a possible attack vendor many vendors attack vector many vendors want access to their linux security appliances or non-linux security appliances verify um who they are and and look at their security posture before you let them on your network uh again some some regulations require systems being locked cages uh we have a regular retirement from nerc which is a regulator electrical industry where these critical assets have to be in a physically locked cage so there's a lot of considerations in that area too for hardware we'll touch upon the network these uh we hit on the first three spin a little detail on those these last one i'm going to touch upon

network condition matters no condition can have a major impact on success or failure and is usually out of your control it's usually related to patchy downloads or port closures get to know the people who run the network have a good friend at your 24 7 knock or sock whatever you want to call it make sure you can have someone to call when when you come across some network issues have a formalized process in place for issue reporting escalation and resolution if needed uh have a police anatom analogy you could call a swat and get all the interested people together to come to some trouble resolution you should know all your ingress and egos points and how data flows through

them the vpn connection has been in the spotlight with all of us working from home lately it also has hampered my ability to query for accurate patch groups because there's not a lot of whole information on iron that comes through that can distinguish the vpn user and where they are make sure the network can handle the traffic i think every network has slow links know where they are when you're patching if you have a big patch batch that could hamper network performance or getting the patches and machines you can have 24 hour baselines determined to see where bandwidth is available or how it's used and then monitor those deviations from baselines to know where you can patch

understand when network bandwidth is available and not available remote locations can have low bandwidth that do cause some patching issues um i didn't know where to put this slide i talked about regulations and frameworks for a while these are some of the regulatory standards and industrial frameworks that are out there regular regulatory standards or requirements you must meet your work in certain industries and frameworks are standards you choose to implement for example this has a good patch management framework that you can follow any company you follow whereas hipaa has regulatory requirements if you're in the medical industry that you have to abide by i tell you truth i don't know what all those mean uh

but my point here is that if you're in industry know what the regular requirements are because they can be very time consuming to meet security products know their processes and understand their protocols the key is to have process and people in place for quick and easy collaboration escalation and a resolution all this security stuff can affect patching when i say protocols i mean the actual practices and procedures and who leads them and it's also nice to know what what protocols different software uses and what different security products use and knowing the ports just helps in general and if you're going to be a patch person the key is to knowing what these products do and what kind of effects

they can have in patching and most importantly make sure you have a contact point for every security product in your environment the next slide might tie live stream together software hardware user security and how it's all interrelated i might be getting a little outside patch management here but all this stuff but i put all this on one slide to show there is some overlapping hardware and software and some of the processes and to show that it all runs on the network and being aware of this being aware of all this helps me to patch get to know the software hardware users and networks used to access and protect data as a patch person you're exposed to all

groups in the company you reach out and touch every pc every month i've learned that patching is the first thing everyone looks at when there is an issue i'm assuming many now i'm assigned many non-patching trouble tickets so understand the basics of all this help you perform the job it also helps you to know who you can reassign tickets to when one is erroneously routed to you get to know the computing environment get to know how it works especially security products and processes eventually at some point uh if you're patching you'll run into some issues with them okay these um i'm just going to touch upon these last three i feel like a short change them

uh they're a little more abstract than the first three three and a half with half of the networking i include that the higher on the org chart the message comes from the greater probability of success people seem to listen to c-level executives the higher on the merge chart the message comes from the more likely employees will listen i have two males about an upcoming security event one from us from the admin that is performing the work the other from the ceo which one is read more i'll put my money on the cdl note um cyber security is discussed at many board meetings now it used to be pretty hard to get time for security at the at that level

that's changing uh cost thanks to the cost of rising breaches people are still the weakest link make sure patching is talked about encouraged and rewarded this is about culture train your people they are usually the weakest link and will probably always be the weakest link teach them about security even a basic online course can help and making it mandatory might help them understand the importance of patching or some or even some companies are making cyber security a criteria in their bonus structure it is very serious uh let them know what you're doing and and when you're doing it make patching a habit tell people why it's so important and and telling them why it's so

important can make them care having a monthly calendar available for end users to check uh patching and security events is a step toward that end uh make it easy to report issues the easier it is to report issues the faster you can resolve them done with the second section let's talk about the process i like that transition i started patching i thought 30-day cycle would be plenty of time to download tests and deploy patches to the environment it still is a 30-day cycle but it's instead of starting on the first of the month today the starting date for each month is patch tuesday microsoft started labeling the second tuesday of each month patch tuesday this is the date that they released most

of their patches many other software vendors also post their patches on that date as well i'm not going to go over all the details of the process i'll hit a few important ones along the way i will have a bunch of bullets in my notes when i post this presentation you can look at those um throughout the process communication is important we talked about it here and there but good communication about what is going on cannot be neglected with that in mind these are the things i do to inform and document what happens every month we may touch on these a little earlier but this little more detail change management one monthly master change with

assignable tasks to detail all the activities from all the groups involved that can be automated it is automatically working it is worth automating uh the workflows a lot of the new uh service now and uh a couple i don't remember the other ones names but they all have workflow automation you can use the monthly email released on the first day of patch psycho with links to patching details and resources on patrick tuesday or shortly after an email was sent to itunes managers app support managers app people help desk security groups and business unit contacts that email provides details on testing timeline patches to be deployed the schedule who to call with issues formalized communication between uh

from formalized communication channels between all groups involved engineering help desk app support network and security over the years i found it beneficial to know the other players that the patching process can cause work for for example if there is an issue the help desk gets inundated with uh calls the patching website we've been over a little bit it has the deployment schedule and links to the change control and uh schedule with issues um announce testing in patching schedule and cab meeting cab meeting is a change advisory board meeting a lot of companies have a daily one that if you have a change coming up for that day or the next few days you announce it we do that regularly

with a patching workstation server and whatever any other group that does do patching during this testing period robust test environment is important i generally provide about eight working days for patch testing but let me say if it's a if there is an emergency emergency deployment declared because of active code exploiting a zero-day vulnerability the testing window could be reduced to zero usually about three days is what we test on with it zero day testing is critical the purpose of testing is to find and fix issues in the small test groups prior to deploying them to the enterprise the time it takes to test has a direct correlation to the variety of things in things to test so remember that less

variety less time as variety goes up so does testing time as the models of hardware and versions of software running in your environment increase so does the complexity and time to test ideally you should test all versions of all software on all hardware models but that is not practical you make your best effort to test the most prevalent configurations in your environment and be ready for uh unexpected remediations for instance you could have a task in the change management that you can enter all the issues into and if like the one we use i can follow it anytime anybody adds anything to the to that task i get an email you can never have enough uh application

and patch testers make it easy to join and leave the patch testing groups i have a query for an 80 group that is for patch testers and if you're in that group you're a tester it makes it really easy to keep track of the page testers it's critical to test all the functionality of an application after patching it's not that hard you'll launch the app sign in if necessary use the app and report the issues and that can all be automated if some groups don't have a testing environment you can provide a testing environment is there is some cost to it and time and money to set up a virtual workstation a certain workstations that testers can

use with the different flavors and operating systems and stuff so uh it might be worth setting it up for some critical apps that don't have that kind of testing environment again now we're going to deployment remember it's important to tell the people what you're doing and hey people i'm about to bake your pc um if there's a patching problem you can hear about it like i said it's pretty obvious it comes in big groups if there's an issue that didn't get caught in testing it the help desk gets inundated and i get called the deployment is a stage deployment with small batch of assets that i add to and get bigger and bigger it starts on the last day

and the testing day ends on the next month's deployment start date i start by turning the tasks i use for testing into the production test and try to try to keep those number of groups down to a minimum if you have too many groups the queries get hard to manage you get tend to get a few machines in a lot of different groups so it's like you say one thing keep your groups to a minimum it's much easier to patch one group than managing all the like let's say 10 groups you got to manage that scheduling queries some remember keep those views to a minimum monitor your console and help desk calls i found that once the word is out about

patching a lot of the issues that are out there become patching issues so if you get a ticket you can spot check that machine and see if it got patched you can cross-reference the the machines that were patched that day to the issues coming in and if you if you see something like that that could help um have a remediation plan to handle handle the issues that you find um that would help in the long run to get all the groups involved and who to call and stuff uh one of the important things i found out you need is rebooting and sometimes that bothers people make sure you control and configure the reboots having the ability to set parameters is

important most of the patching tools do have the ability to set configuration like time to time it can reboot when it can't reboot if you don't make people reboot a certain percentage won't and they will complain when you force them if you use as admin right they can stop patching completely so remember it's important to remove admin rights some patches are not installed until the system is rebooted attack surface is not reduced when a system sits in a pending agreement state and the machine is left sitting in an unstable state appointment they should uh what's the next one there should be a way to mark machines as do not reboot so in this case if you have a machine

you can't reboot make sure they fill out risk exception i don't know we talked about that yet um but it should be filled out by the party that is requesting the stoppage no matter how hard you try someone's always going to have an asset that can't be rebooted have them fill out a form the risk exemption form info should include the name contact the asset name how long will the stoppage be are there mitigating circumstances in place of the patch all that stuff is pretty important to know make sure your people know the difference between reboot and log off sometimes you can set a job up you want to set a job up to work when no one's logged in

and people don't know the difference between logging off and rebooting or signing out you can run into some issues um again i'll go to the bottom one clearing out memory intent files reboots help with that it keeps the machine running better let's move on after the deployment post deployment by this time you're also doing some pre-work for the next cycle so compare your stats with the security groups um installs failed installs machines missing patches etc i usually work with the security group to see if our sets match verify patches did indeed install this is where you can spot check bigger groups of machine just to validate the installs check your geographic footprint just to make sure

investigate and remediate fail investigate and remediate failed installs investigating or meeting failed installs is very time consuming you could get lucky and find a trend where you know you you know you patch location x and you see all those office versions are broke in that office um that would be pretty obvious but a lot of times they're one-off machines and it does take a lot of time to remediate them complete and uh close your change control uh closing monthly change control and verifying all support documents are attached is important a lot of times that information can be used for audit purposes or is used for auto purposes so this last slide let's tie it all together

let's slide this little dizzy in there so wrap it up imagining the big three will go a long way in reducing the attack surface patching becomes easier as your attack surface decreases the application standardized application life cycle process help set only the latest versions of all apps should be in production eliminate duplicate apps like some office is a prime example don't have office 16 19 and 10 classified for criticality helps you determine uh what to patch first only give access to people who use the app but if they don't use it take it away hardware is standardized keep model choices to a minimum and audit usage lifecycle is is critical for keeping unsupported hardware off your network users

remove admin rights control or at least monitor usage for critical apps and hardware for future forensic investigations or audits getting these basics in order makes patching easier mainly by reducing attack surface network usage and the time it takes to patch

and i oh i did include uh some visual another color slide this is just a swimlane chart you can go through these that you want it basically says all of what i said in a visual form to some extent uh this is i like that is my one of my favorite transitions this is another timeline thing where it shows where everything overlaps and um i think we have time for some questions so that was the end and thanks for listening