3 ms·
I work in IT security, so I am probably one of those people who screw other people over by pushing patches to be installed no matter what. Behind the scene, it
by BrandoElFollito 4y ago
I work in IT security, so I am probably one of those people who screw other people over by pushing patches to be installed no matter what.
Behind the scene, it is a never ending war between me who says "if your want your data to be safe, we need to patch", and the business that says "no, those is quarter rend (or stuff like this)'.
So I say" on, sign this paper what you start that you do not want your data to be secure"
And it goes on forever.
This is exhausting for everyone, but IT is zero the very bottom of thefood chain, we cannot claim sales or new products and provide z utility like water or trash collection.
So this is not always that someone is trying to screw you over, out is just that technology works the way it works, with the money that is invested in it.
- hn_version_0023 4y agoYour comment exemplifies the attitude I'm talking about. You've presented a scenario that's false in it's premise: either your data is safe or it isn't. But really, whether a thing is protected isn't quite so zero or one. Whether your production environment is actually at risk for the exploit being patched is a reasonable thing to ask in all scenarios. "What's our exposure here? Can it wait a few days?" would be a reasonable thing to ask. But in my experience that isn't how it goes. It goes how you suggested: ITSecOps presents an easy-to-decide case based on a false premise, and then immediately asks for CYA if the company says no. Over time, this becomes a rubber stamp from management, who are also demoralized by the process. The solution is to not present every security patch as a sky-is-falling event, but rather to be reasonable about the threats one faces and the impact to the business of forcing updates.
- pixl97 4y ago>Whether your production environment is actually at risk for the exploit being patched is a reasonable thing to ask in all scenarios. "What's our exposure here? Can it wait a few days?" would be a reasonable thing to ask. You would think it do be that way, but it don't.... Especially with things like Microsoft's megapatches they distribute these days. You are asking for the potential impact of anywhere from 10 to 100 patches custom tailored to the particular applications you're running on your server. Now you're asking for some large number of manhours of in depth analysis in a department that's already short on time. And as often as there is a patch that breaks the application, there is a patch that was released as a low impact that suddenly is high impact because it can be chained into an exploit, and now IT/SecOps is looking at the servers history to make sure it wasn't exploited at some time in the past. What is helpful here is not delaying patches, but instead having good testing environments that run the same version of the production application so the patch can be tested there first. Of course that costs a lot so you don't see it as often as you should.
- BrandoElFollito 4y ago> You've presented a scenario that's false in it's premise: either your data is safe or it isn't. Do you work in cybersecurity? have you done security assessment - the real, technicals ones before? I did. I coded (a tiny, tiny) part of the Linux kernel. My teams break systems for a living. If you have actually done security assessments than you know, of course, that there is no way to assess whether a vulnerability is low or high before shit hits the fan. When MS says "critical", then I say "critical" as well. I am not going to plat smart ass and then realize that in the shitty cathedral of systems businesses build there is THE configuration that allows for an exploit. Anything lower than critical - I do not care/ This can be done later. Bit is it is critical, it will be applied immediately, breaking systems and important presentations of the C-whatever. If the business has something against me then feel free to escalate to my management and tell them that they do want their data to be insecure. Because this is what they do want. Some tried - their systems are patched as the others. Everyone today is a doctor, football coach an,d recently cybersecurty expert. Yes, maybe your IT team sucks, but others just want to do their fucking dmn, work.
- hn_version_0023 4y agoYou know, I've worked in IT long enough -- 25 years now! -- to watch the rise of "the cybersecurity professional", and their place as a rubber-stamp of acceptability in the food chain of business IT. I'm sorry if you find this comment to be incendiary, and an attack against you in particular. It most certainly is not. I do understand that there's a wide chasm between the state of the industry and the intentions of individual people. If it's any consolation, I've found that my own work is mostly a kind of rubber stamp too, and lately I've begun to question the entire endeavor. What are we actually working to do anymore? Beats me, really. But, I do find some irony in a statement like "it is critical, it will be applied immediately, breaking systems and important presentations of the C-whatever. If the business has something against me then feel free to escalate to my management" when the title of the article we're talking about is Report: 95% of employees say IT issues decrease workplace productivity and morale. If you don't see the connection between "I don't care how this affects you" and "IT causes low productivity and morale", well then I guess all I can do is laugh, and be glad I've left IT desk work for data center technician work.
- jodrellblank 4y agoYour earlier comment is about an IT department "overwhelmed, overworked, under appreciated, and fed up with the BS" who also had no control over the patching installs anyway, and didn't care, and your conclusion is ""What's our exposure here? Can it wait a few days?" would be a reasonable thing to ask." of them? I can't see that adding "now every single patch forever is up for argument" as likely to improve such a situation. Even in a competent and interested IT department, the change from "patch Tuesday, same time every month" to "now every patch is up for negotiation" seems like a non-trivial overhead, given that we assume it's desirable to install them all eventually. Exercising power for power's sake. One off asking "can we eat later today" is reasonable but if dinner is always inconvenient for someone then decide once "dinner is later" or "we eat separate dinners", don't have a dinnertime negotiation every day.
- deleted 4y ago[deleted]
- digitallyfree 4y agoI think compromises could be made in this case - like giving users a reasonable amount of time to apply the patches before the update is performed forcibly. I have seen important meetings stalled because the presenter was only given two hours to reboot his computer after Windows updates were applied, for instance. Same for big Windows feature updates occuring in the middle of the day and stopping work for an hour. But with say twelve hours or so then the user could reboot in the evening or during lunch break without affecting productivity.
- BrandoElFollito 4y agoIt depends on the vulnerability. as I commented elsewhere, below Critical I do not care. Critical needs to be patched NOW, breaking things if needed. Including the important presentation.
- ianai 4y agoIf you want Windows boxes to stay updated then have a way to replace the entire machine and replicate all needed application data (including sql server databases and anything proprietary) within minutes or hours at no notice. The Windows Update Service is a practical nightmare. It will get corrupted. It will require an entire re-image of the machine to fix. It will happen on production servers and client endpoints without regard to core business impact. It might even happen at a rate of a few per hundred of installs updated.