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

Preliminary Post Incident Review

crowdstrike.com

Post reply on HN
Print view View original

221–227 of 227 posts

Re: Preliminary Post Incident Review

#221

Post by throwaway2037 »

lesuorac wrote: post #209
throwaway2037 wrote: post #186

Earlier quoted context omitted.

I felt exactly the same when I read about the outage. What kind of CTO would allow 3rd party "security" software to automatically update? That's just crazy. Of course, your own security team would do some careful (canary-like) upgrades locally... run for a bit... run some tests, then sign-off. Then upgrade in a staged manner.

Pretty sure many people see the point of having Falcon as a reason to not have an internal security team. Outsource everything.

This is a great point that I never considered. Many companies subscribing to CrowdStrike services probably thought they took a shortcut to completely outsource they cyber-security needs. Oops, that was a mistake.

Re: Preliminary Post Incident Review

#222

Post by throwaway2037 »

aenis wrote: post #210
throwaway2037 wrote: post #184

Earlier quoted context omitted.

As I understand, it is incredibly difficult to prove "gross negligence". It is better to pressure them to settle in a giant class action lawsuit. I am curious what the total amount of settlements / fines will be in the end. I guess ~2B USD.

Same here. Our losses were quite significant - between lost productivity, inability to provide services, inability of our clients to actually use contracted services, and having to fix their mess - its very easily in the millions. And then there will be the costs of litigation. It was crazy in the IT department over the weekend, but not much less crazy in our legal teams, who were being bombarded with pitches from la…

To be clear: I do not expect the settlement to bankrupt them, but I do expect it to be painful. And, when you say "easily in the millions" -- good luck to demonstrate that in a class action lawsuit, and have the judge believe you. It is much harder than people think. You will be lucky to recoup 10% of those expenses after a settlement. Also, your company may also have cyber-security insurance. (Yes, the insurance companies will join the class action lawsuit, but you cannot get blood from a stone. There will be limits about the settlement size.)

Re: Preliminary Post Incident Review

#223

Post by hello_moto »

skydhash wrote: post #169
hello_moto wrote: post #140

Earlier quoted context omitted.

I'm referring to the landscape how current Cybersecurity vendors deliver "detection definition" (for lack of better phrase) to their customers. If you don't send them fast to your customer and your customer gets compromised, your reputation gets hit. If you send them fast, this BSOD happened. It's more like damn if you do, damn if you don't.

> If you don't send them fast to your customer and your customer gets compromised, your reputation gets hit. > If you send them fast, this BSOD happened. > It's more like damn if you do, damn if you don't. What about notifications? If someone has an update policy that disable auto-updates to a critical piece of infrastructure, you can still let him know that there's a critical update is available. Now, he can do foll…

What if they're sleeping and won't read the notification until they wake up?

Wouldn't they get compromised?

Re: Preliminary Post Incident Review

#224

Post by hello_moto »

XlA5vEKsMISoIln wrote: post #216
hello_moto wrote: post #140

Earlier quoted context omitted.

I'm referring to the landscape how current Cybersecurity vendors deliver "detection definition" (for lack of better phrase) to their customers. If you don't send them fast to your customer and your customer gets compromised, your reputation gets hit. If you send them fast, this BSOD happened. It's more like damn if you do, damn if you don't.

Okay, but who has more domain knowledge when to deploy? A "security expert" that created the "security product" that operates with root privileges and full telemetry, or IT staff member that looked at said "security expert" value proposition and didn't have issue with it. Honestly, this reads as a suggestion that even more blame ought to be shifted to the customer.

The AV definition delivery is part of UX of the product.

Re: Preliminary Post Incident Review

#226

Post by samcat116 »

skydhash wrote: post #169
hello_moto wrote: post #140

Earlier quoted context omitted.

I'm referring to the landscape how current Cybersecurity vendors deliver "detection definition" (for lack of better phrase) to their customers. If you don't send them fast to your customer and your customer gets compromised, your reputation gets hit. If you send them fast, this BSOD happened. It's more like damn if you do, damn if you don't.

> If you don't send them fast to your customer and your customer gets compromised, your reputation gets hit. > If you send them fast, this BSOD happened. > It's more like damn if you do, damn if you don't. What about notifications? If someone has an update policy that disable auto-updates to a critical piece of infrastructure, you can still let him know that there's a critical update is available. Now, he can do foll…

most people will defer updates indefinitely if they are able to.

Re: Preliminary Post Incident Review

#227

Post by Cyphase »

yuliyp wrote: post #156
throwanem wrote: post #67

Earlier quoted context omitted.

If the rules are Turing-complete, then sure. I don't see enough in the report to tell one way or another; the way rules are made to sound as if filling templates about equally suggests either (if templates may reference other templates) and there is not a lot more detail. Halting seems relatively easy to manage with something like a watchdog timer, though, compared to a sound, crash- and memory-safe* parser for a who…

No matter what sort of static validation they attempt, they're still risking other unanticipated effects. They could stumble upon a bug in the OS or some driver, they could cause false positives, they could trigger logspew or other excessive resource usage. Failure can happen in strange ways. When in a position as sensitive as deploying software to far-flung machines in arbitrary environments, they need to be paranoi…

It's not paranoia if you can crash the kernel.
Post reply on HN