Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patching is hard; so what?

blog.cryptographyengineering.com

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Patching is hard; so what?

#21

Post by sillysaurus3 »

mirashii wrote: post #18
sillysaurus3 wrote: post #16

Earlier quoted context omitted.

The fact that Equifax reported the breach at all represents a good faith understanding: they tell the world, and in return the world does not make them cease to exist. If you kill companies over security incidents, then magically you will no longer hear about security incidents.

It's not a good faith gesture, it's required by law almost everywhere they operate that they notify of a security breach of PII. http://www.ncsl.org/research/telecommunications-and-informat...

And yet, as if by magic, you will no longer hear about security incidents if you kill companies.

Re: Patching is hard; so what?

#22

Post by Sevii »

sillysaurus3 wrote: post #21
mirashii wrote: post #18

Earlier quoted context omitted.

It's not a good faith gesture, it's required by law almost everywhere they operate that they notify of a security breach of PII. http://www.ncsl.org/research/telecommunications-and-informat...

And yet, as if by magic, you will no longer hear about security incidents if you kill companies.

If there is no penalty that hurts shareholders and executives breaches aren't going to stop.

Re: Patching is hard; so what?

#23

Post by KGIII »

Sevii wrote: post #22
sillysaurus3 wrote: post #21

Earlier quoted context omitted.

And yet, as if by magic, you will no longer hear about security incidents if you kill companies.

If there is no penalty that hurts shareholders and executives breaches aren't going to stop.

There exists some space between no penalty and a penalty that effectively kills the company.

Re: Patching is hard; so what?

#24

Post by CiPHPerCoder »

topkeker wrote: post #15
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…

I've worked in enterprise security teams for the last decade. This is spot on. It's retarded and will never change because there is no accountability. Corporate IT don't give no fucks.

Then let's hope Equifax shakes the foundation of their egos and they start to give fucks about this sort of thing.

Re: Patching is hard; so what?

#25

Post by ktRolster »

chasb wrote: post #3

For teams that use a DevOps model, fast, predictable deploys that can be safely rolled back are important for security, for this reason. If deploys are like playing Jenga on a sailboat, you're not going to be able to patch fast or safely. That said, even becoming aware a CVE exists in the first place is still a problem for many teams. There are plenty of good options, it's just underinvested in early on.

Back in the 90s people used to have their pager connected to CERT to make sure they knew if anything happened. Of course no one uses pagers anymore, but there are places you should definitely pay attention to if you're looking at the software.

Re: Patching is hard; so what?

#26

Post by pizza »

Sevii wrote: post #22
sillysaurus3 wrote: post #21

Earlier quoted context omitted.

And yet, as if by magic, you will no longer hear about security incidents if you kill companies.

If there is no penalty that hurts shareholders and executives breaches aren't going to stop.

Penalizing shareholders and executives to the extent that reporting breaches becomes enterprise suicide is only going to make breaches unannounced and prevent the collective from learning from individual mistakes, so therefore more common.

The way to reduce breaches is to encourage open admission of security failures, so that preventative knowledge spreads quickly. It is worth some positive amount of respect to follow through in one's obligation to warn one's dependents, and moreso if one tries to warn society as a whole.

Re: Patching is hard; so what?

#27

Post by microcolonel »

ktRolster wrote: post #25
chasb wrote: post #3

For teams that use a DevOps model, fast, predictable deploys that can be safely rolled back are important for security, for this reason. If deploys are like playing Jenga on a sailboat, you're not going to be able to patch fast or safely. That said, even becoming aware a CVE exists in the first place is still a problem for many teams. There are plenty of good options, it's just underinvested in early on.

Back in the 90s people used to have their pager connected to CERT to make sure they knew if anything happened. Of course no one uses pagers anymore, but there are places you should definitely pay attention to if you're looking at the software.

I get SMS for CERT.

Re: Patching is hard; so what?

#28

Post by viraptor »

pizza wrote: post #26
Sevii wrote: post #22

Earlier quoted context omitted.

If there is no penalty that hurts shareholders and executives breaches aren't going to stop.

Penalizing shareholders and executives to the extent that reporting breaches becomes enterprise suicide is only going to make breaches unannounced and prevent the collective from learning from individual mistakes, so therefore more common. The way to reduce breaches is to encourage open admission of security failures, so that preventative knowledge spreads quickly. It is worth some positive amount of respect to follo…

> so that preventative knowledge spreads quickly

It doesn't need to spread. It's not original research. People do this every day in other places. This shouldn't be talked about as some black magic skills.

Re: Patching is hard; so what?

#29

Post by sillysaurus3 »

viraptor wrote: post #28
pizza wrote: post #26

Earlier quoted context omitted.

Penalizing shareholders and executives to the extent that reporting breaches becomes enterprise suicide is only going to make breaches unannounced and prevent the collective from learning from individual mistakes, so therefore more common. The way to reduce breaches is to encourage open admission of security failures, so that preventative knowledge spreads quickly. It is worth some positive amount of respect to follo…

> so that preventative knowledge spreads quickly It doesn't need to spread. It's not original research. People do this every day in other places. This shouldn't be talked about as some black magic skills.

It may be tempting to believe this, but evidence would contradict you.

Re: Patching is hard; so what?

#30

Post by pizza »

viraptor wrote: post #28
pizza wrote: post #26

Earlier quoted context omitted.

Penalizing shareholders and executives to the extent that reporting breaches becomes enterprise suicide is only going to make breaches unannounced and prevent the collective from learning from individual mistakes, so therefore more common. The way to reduce breaches is to encourage open admission of security failures, so that preventative knowledge spreads quickly. It is worth some positive amount of respect to follo…

> so that preventative knowledge spreads quickly It doesn't need to spread. It's not original research. People do this every day in other places. This shouldn't be talked about as some black magic skills.

If security best practices weren't made irrelevant by ignorance in the first place then people wouldn't cause these preventable mishaps in the first place.

It's not rigorous enough to say "I am certain some people can RTFM and understand without resorting to glorified mimicry, therefore the benefit to the group of encouraging people to share mistakes is marginal".

There is just too much at stake in the outcomes of security breaches. It is far far better to be have a high variance of variance of protective + relayed benefit gained from analyzing someone else's failure, than it is to overestimate your certainty of understanding while at the same time underestimating the lessons of someone else's failures.

Security is too important to put the focus on people learning in rigorous and logical ways over the protection of users. That said, due to the informational nature of security, to protect users necessarily contains as a sub-goal wholly understanding what your security is. But it's disingenuous at best to say that incident disclosure isn't actually empirically sound but instead gives security the appearance of black magic.

Post reply on HN