Patching is hard; so what? • Hacker News Board

Re: Patching is hard; so what?

#61

Post by user5994461 » Sat, Sep 16, 2017, 10:41 PM UTC

watwut wrote: post #46

ams6110 wrote: post #12

Earlier quoted context omitted.

That's not the mindset of enterprise IT though. The mindset of enterprise IT is "if it works, don't touch it." This mindset developed because of decades of dealing with arcane, complicated software that was at the same time critical to business operations. I'm aware of a major university that still has a three-week "change freeze" at the start of every semester because of this attiude and I'm sure they are not the on…

Three weeks freeze twice a year during the most critical time does not sound that horrible to me. Software developers tend to break system with changes. That is not some kind of mythical rare issue - that happens often (with some vendors very often).

Agreed. A company that doesn't have change freezes at the most critical times has very poor practices.

Re: Patching is hard; so what?

#62

Post by Spooky23 » Sun, Sep 17, 2017, 2:53 AM UTC

sverhagen wrote: post #14

yeukhon wrote: post #13

Earlier quoted context omitted.

It isn't necessary DevOps or system admin not capable. You've vendor software not up-to-date that is beyond your control, and often users do not know until vendor sends a notification or a hack headline comes online then "oh fuck" moment. Just to be fair too: I have seen a number of enterprises run their "legacy" infrastructure (mostly refereing to on-premise servers and old applications) doing a good job keeping up…

Your first paragraph, do you find any of that a valid excuse for a company like Equifax, who handle so much sensitive data? _I_ consider them responsible for the entire chain. I understand it's hard, makes no difference with those stakes.

Companies like Equifax are fundamentally timebombs. The problem there isn't an IT problem.

Re: Patching is hard; so what?

#63

Post by genmud » Mon, Sep 18, 2017, 2:31 AM UTC

hn_throwaway_99 wrote: post #50

rythie wrote: post #37

Is it so hard though? Do Facebook, Google etc. have this problem too? I doubt it. Systems need to be designed to be patched regularly from the outset. Yes, defense in depth can help, but it's not defense in depth if you one of the layers is pretty much always broken. If they are relying on legacy systems that can't be proactively and regularly be patched, they shouldn't be holding that data. I think part of the probl…

> Is it so hard though? Do Facebook, Google etc. have this problem too? I doubt it. Companies with monopolistic pricing power like Facebook and Google are a poor comparison for almost any other company. Many problems become very easy when you have a near infinite supply of money. Other businesses need to work with much more difficult constraints.

Average IT spend runs between 2 and 5% of revenue for fortune 500s. For reference... GM makes 166 billion/year in revenue, and on the low end their IT spend is probably more than 2 billion/year. In 2004 they were making the news because they went from 4B/year in 1998 to 3B/year. In 2006 they were making 190B/year, so I doubt their IT budget has changed significantly and is on the low end compared to other companies in the fortune 500 list.

Facebook and other technology companies might spend a lot more on IT, but that's part of them doing business.

Don't confuse the fact that technology companies do technology better with the fact that any company in the fortune 500 list have HUGE IT budgets. At a large company that I used to work for we had an IT budget of more than 1 billion USD and they didn't patch very well either. Our budget was actually smaller than many of our peers.

If you have a IT infrastructure/application budget of 1B or more and you can't patch, your doing it wrong and there is no excuse. For a full baked/managed solution, you can find folks to do an entire program for less than 12m/year for a 200k node network.

Re: Patching is hard; so what?

#64

Post by BrandoElFollito » Mon, Sep 18, 2017, 4:27 AM UTC

The whole problem boils down to a choice :security or availability.

If you prefer to have systems 100% up (no downtime for patches and fixing potential issues after the patch) then it is fine. The actual risk (described beyond "having security") has to be accepted by the owner of the data / service and the problem is over. I have yet to see a CFO who will accept in written that his systems are prone to hacking, theft, manipulation.

Until the CISO does not force the company to sign off such risks, he or she will be the one who fucked up.