r/sysadmin • u/CurrentFig3376 • 2h ago
General Discussion Interview Question: How often do you update/patch your system?
I was asked this question during an interview and I said "it depends on what exactly you're updating, but I update as often as it's needed."
I don't think this was the answer they were looking for, but how would you answer this question?
•
u/Tymanthius Chief Breaker of Fixed Things 2h ago
Which system?
What kind of patches?
What are the policies in place and what automatic support systems do we have in place to handle this for me?
•
u/bemenaker IT Manager 2h ago
On A monthly schedule. Normally delayed a week after patch Tuesday. Let other people find the broken patches to maintain our reliability. Unless it's a critical active exploit patch, and then as soon as possible in a sane and safe way.
•
u/mesaoptimizer Sr. Sysadmin 1h ago
I feel like this is old advice. There are too many 0 days and attackers have gotten too fast at exploiting stuff to wait a week before you start patching. My current org starts patching Development on Wednesday (this avoids the emergency pulls from completely broken patches) and we complete production patching on Friday the week of patch Tuesday, sometimes expediting internet facing systems as early as Wednesday if we've got known exploitation. I imagine that we're not too far away from occasionally needing to expedite to same day patching if agentic exploitation continues on the path it seems like it is going.
•
u/bemenaker IT Manager 1h ago
Microsoft just recommended patching every 3 days because of the speed of AI threats. Yes it is old advice, but not necessarily bad advice. Not like MS is dropping patches every 3 days. But you should watch for critical patches being released and apply as necessary as I said. MS still releases their standard patch Tuesday once a month unless warranted.
The risk of how long after Tuesday to update is a risk tolerance vs MS crashing your shit tolerance.
If you're tracking the threat announcements, you will know if you need to deviate and patch immediately.
•
u/Cubewood 17m ago
Same here, manage patching for a very large org (400k+ endpoints), and we used to patch just once a month, but thanks to the AI enabled vulnerability research, you just cannot do this anymore. Something like Google Chrome releases multiple patches every week, which remediate hundreds of vulnerabilities, many of them exploitable, so since the start of this year I've setup automatic deployment rules for everything to run three times per week. Patches go out to Ring-0 for three days, if nobody complains it goes to production after that.
•
u/Steve_at_Werk 1h ago
We do QA the weekend after patch Tuesday, DR the next weekend, and the following. It allows us to catch and address any issues the updates may cause.
•
u/mvbighead 2h ago
This x100. Allow the masses to find any issues with the patch, and if possible, you can delay your upcoming patch cycle if there is word that a patch interacts poorly with a product you use. Can't remember specifically what some of the last ones were, but I feel like a fairly prominent security tool played poorly with a patch one cycle and caused some havoc.
•
u/Legionof1 Jack of All Trades 2h ago
the only answer is "The demands of the environment determine the patch cadence, what are your environment's demands?"
•
u/statikuz start wandows ngrmadly 2h ago
Yeah, that's a copout answer. "I do the needful when it is needed."
You probably should have elaborated on your experience in the environments that you have worked in, and addressed update/patch severity.
How have you handled Windows updates? How have you handled updates of other small apps (oh I used PMPC, I used winget, I did it manually when I reviewed updates for the 3 programs we used). Maybe (if its applicable), "we have pilot groups, power users, etc. that we test a critical application update with to validate before we roll out to other groups," etc. We make sure we back up configuration data before doing a big update. If it is a critical security update we do it immediately and this is our process... That sort of thing.
They should be able to balance your answer with your experience on your resume. If you've only worked in small environments you might not be able to talk much about rollout groups/rings, etc. but that might be OK.
•
u/superstaryu 2h ago
There is not necessarily a right answer, but I would be looking for some insight into why you have decided on those times.
Are there compliance reasons for a specific patch cadence? - or what frameworks do you need to abide by?
Are you separating security updates more frequently (such as applying asap).
Are you delaying feature updates? (and why?).
Are you allowing time to test updates (updating a pilot group first) to detect issues.
Are you considering system dependencies?
Some software will follow a known patch cycle of major / minor versions, are you doing every version or just major?
How will patching affect productivity? can you patch out of hours?
Do you have regular maintenance windows?
I would also expect you to be able to recommend an update frequency / schedule around the most common updates, such as windows updates and feature upgrades.
•
u/StuckinSuFu Enterprise Support 2h ago
This is a good question when you are interviewing at places to let you know what you are getting into and the mindset of that IT department.
•
u/TheBigBeardedGeek Drinking rum in meetings, not coffee 2h ago
I patch external facing CVEs as soon as possible. Internal stuff I patch about two weeks after Patch Tuesday for Pilot and a month after for Prod
Everyone else is my pilot group
•
u/AdeptFelix Sysadmin 2h ago
Constantly. I have a scheduled task on every system repeatedly checking for updates as soon as the last check finished so that every vulnerability is squashed the moment an update is out.
\s
Really, I think the interviewer is looking for what thoughts you have when deciding on patch frequency. At least, that's what I'd look for myself, like in this sample below. Expanding on how you reach a decision, rather than the decision itself.
It depends on the release cadence, testing cycles, if updates are security related or not, if there's change management timelines or windows, if production will be impacted, are there compliance needs, and probably a half dozen other dependencies I can't think of at the moment.
•
u/PandemicVirus 2h ago
It's kind of vague and avoidant, especially with the "it depends" and the "as often as needed". I'd assume OS patching and it would have probably been best to mention that specifically with something like "I'd patch Window's clients on a second Tuesday of each month for Critical and Higher and work maintenance windows with appropriate teams for server patching where we need to" or something like that. Say the things you know and what's comfortable.
From a more technical standpoint it doesn't illustrate any of your skill or knowledge. You don't have to check all these boxes but it opens the room to mention testing, deployment, severity, etc. I'd argue that "as often as needed" isn't even the best approach.
•
u/Skylis 1h ago
Because they're asking how long a piece of string is.
The question is poorly phrased for what they actually want, which is how do you think patch management should be approached at (our) scale
•
u/Ssakaa 48m ago
So, for an IT position where, presumably, they might be giving the selected person some amount of freedom to do their job without someone nitpicking every detail continuously... they ask an open ended question to see if the person can answer in even a moderately reasonable level of detail without being spoon fed, demonstrating that they've actually considered the tradeoffs of the reasons for and impact of something like patching?
•
u/Substantial_Tough289 2h ago
Following the IT update policy should have been enough.
Every company applies updates differently, some are quick to apply, some wait a while and some never update so is more company specific than person specific.
•
u/Ssakaa 37m ago
But answering it as "it depends" and not saying anything about what it depends on says nothing about your knowledge and understanding, nor how you view patching. Answering it with some amount of the detail of what your company's policy is, why that was the decision made, and what tradeoffs that comes with... well, that might show that you actually think in your current role. Even if it's "Due to policy, not as quick/often/smoothly/whatever as I'd like, but it's not mine to change there. If I were building the policy from scratch, I'd prefer <rattle off something that probably looks a lot like CISA's BOD 26-04's risk assessment and timeline requirements>."
•
u/pdp10 Daemons worry when the wizard is near. 1h ago
Several others have pointed out that your answer was vague, perhaps even a bit evasive.
A good way to answer is what policy you had in previous roles, followed by how you'd do differently if it were your choice, if at all, and the experiences that formed your opinion.
Our canary population gets patches basically immediately. An advantage of continuous patching is that it spreads out the load across a longer timespan.
•
•
u/ThinkedThought 2h ago
Be more exact than that. Critical are done ASAP. Normal ones are scheduled monthly, and larger, OS defining ones are twice yearly on a schedule to allow testing on a separate machine.
•
u/drewbiez 2h ago
My laptop -- as soon as patches come out becuase why not? Prod server environments, kinda depends.
•
•
u/Darkk_Knight 2h ago
I wait a week before the next round of Windows patches. I rarely ever apply patches on the day of it's release unless it fixes zero day vuls.
•
u/TheKuMan717 2h ago
The answer is monthly or whenever a critical patch releases. Because if it’s VMware, there hasn’t been a patch in a month.
•
u/imSeanGG 2h ago
I don't get these questions..Does sysadmins not schedule updates to run every 7 days via a small shell script or something? With winget + homebrew it should be no headache to maintain. Even OS updates can be automated now via cli.
•
u/Velvet_Samurai 2h ago
I have a monthly routine that includes hitting each of my critical internal servers once. I have a short list of things I check including updates. Just started the process today for September.
•
u/crabshuffle 2h ago
We have an agreed upon patch cadence and work closely with our cyber security team to identify when expedited patching is needed.
•
•
u/SnooMachines9133 2h ago
I would respond with something like... have a system in place so everything gets everything patched at least quarterly, because X; have other things patched on a monthly or weekly schedule in coordination with business group that uses it; and have some out of band emergency process for critical vulns that we can't otherwise mitigate.
•
•
u/6SpeedBlues 1h ago
In short, it completely depends on how urgently an issue needs to be addressed and whether there is a sufficiently tested patch available.
•
u/Ssakaa 28m ago
It's an interview question. Your "In short" is barely more demonstrative of your knowledge and understanding than OP's nebulous "it depends". Don't sell your knowledge short, in this case literally, in an interview. Scope it down by their reaction as needed, but start off showing a bit of both comfort in your own knowledge and enthusiasm.
•
u/6SpeedBlues 23m ago
I don't disagree with ensuring they understand that I understand, so the "in short" is really just a conversation starter with them.
However, I don't provide free consulting services and you have to be a little wary of where some of these questions are really going when you're interviewing. So, I'd be happy to engage in a discussion with them, ask if they have specific example scenarios and similar, but I would instead discuss with them the kinds of avenues I would follow to -make- decisions on when to apply certain patches but I would stop short of providing anything too "concrete" for general use (if that makes sense).
•
u/Ssakaa 9m ago
I'm of the attitude that... if they're fishing for free consulting, fine, interview practice is interview practice. You can generally sus out the pure consulting fishing pretty easily, and fire back some organizational questions that'll make them uneasy, and call it yourself with a polite thank you.
If they're asking open ended questions, they want to see how you engage with it. Almost everything we do in IT starts with someone throwing around an open ended question. If you close off, freeze up, or otherwise won't engage in a discussion that blatantly exists to provide you a platform to sell your skills on... someone else will.
•
u/dreniarb 1h ago
like you said it does depend on what you're updating. but my typical approach:
wait a week after the update(s) are out (assuming it's not a high risk vulnerability)
push updates to a test group of devices
if another week goes by without any issues push to the remaining devices
with windows, that's once a month. other things, could be every few months.
•
u/GreyBeardEng 1h ago
"Quarterly or monthly schedule, with priority and timeframe manipulated by CVE vulnerability."
•
u/Mailstorm 1h ago
"The goal is to match the patch release cycle of the thing being patched. However, for more sensitive and critical systems the business may determine that the cycle is to frequent and opt for longer patching cycles in which case its whatever the business wants regular patching to be for those systems."
•
u/DarthJarJar242 IT Manager 1h ago
"prod push schedule is 7 days after patch Tuesday, every month.
Also any time The SOC tells me a CSV is high enough priority to skip the prod push schedule (sometimes I have to suggest they raise the priority).
So basically every day in the last year or so!"
•
u/thecravenone Infosec 56m ago
At work: Whatever the policy says.
At home: The first night that I remember after the new version runs out.
•
u/Technical_Union_3249 55m ago
For normal patches (aka no hair on fire holes being fixed) the last Friday of the month. (This is the policy where I work). For hair on fire patches it can be within hours of it being released to us.
Personally my answer would be something like "the cadence and policy at places I've worked over the years has varied, I patch when the written SOP says I patch".
•
u/Ssakaa 15m ago
Personally my answer would be something like "the cadence and policy at places I've worked over the years has varied, I patch when the written SOP says I patch".
That's a great start, but your answer here before that said a LOT more about your understanding and knowledge. IT requires thinking. "I just folow the list" doesn't demonstrate that well. It's necessary too in a lot of scenarios, but even showing understanding of why rigid adherence to the SOP is necessary would help.
They probably don't care what OP's policy specifically is in their current/previous role, they probably care what OP understands about it, i.e. if they know why the policy is what it is, and what weaknesses (because there are always tradeoffs) OP's aware of in it, and maybe even their ideal policy if it was all up to them, with a much more important "and why".
•
u/Hale-at-Sea 45m ago
As dictated by policy (and that may come from audit requirements, insurance, support recommendation, etc)
I realize this is mostly about security patches, but updating the system can mean feature or breaking changes as well. Ask interviewers what their test environments look like, and what/how long they test before rolling into production
Updating an ERP system from v5 to v6 is a whole different world away from just applying mini patch v5.0.1.1, so there's not a single answer
•
•
u/sandfleazzz 29m ago
We have weekly maintenance windows of one hour per server. We schedule VMware snapshots prior to them and keep them for 3 days. Out of band or zero day stuff gets done as needed.
•
u/burdalane 20m ago
I think your answer was too vague. How do you define "as needed"? Are there policies, and what's the reasoning behind them? How do you handle testing and urgent security patches?
I suppose I would have trouble answering this question myself. When I do patch, I do it on non-primary systems first and then on the other systems when they become non-primary because this is the way my systems work -- some are operationally primary some of the time. Others require scheduling beforehand to handle reboots. I don't have a patch schedule or maintenance window.
•
u/GX_EN 8m ago
That's a long answer, imo.
Window servers? Where I worked we patched everything automatically once a month starting the week after patch Tuesday with test/dev/non-prod, etc.. first, then prod the following week.
For physical systems like hypervisor hosts and associated stuff.. depends.
When I was at my last MSP we patched the Nutanix stuff N-1 as our policy unless there was a critical vulnerability.
When I was with a VMWare shop, basically the same as above including the storage arrays.
•
u/GhostandVodka 6m ago
PCs get patched monthly. Servers Monthly, Firewalls get patch within 2 days of a critical vulnerability. If its being exploited in the wild sometimes we do it day of announcement. Switches' management is airgapped so rotate those building quarterly/bi quaterly. APs we do as needed as my work doesn't consider wireless essential services.
•
u/NoTime4YourBullshit Sr. Sysadmin 2h ago
The “correct” answer is that you patch everything whenever there is an update available, unless there is a specific reason not to.
I put “correct” in quotation marks because everyone understands that’s not always how it goes. But it is the goal to be strived for.
•
u/ThatBCHGuy 2h ago
Monthly, or when there is a high severity vulnerability.