[flagged]
It's called Twitter.
Preliminary Post Incident Review
21–30 of 227 posts
Re: Preliminary Post Incident Review
#22Why do they insist on using what sounds like military pseudo jargon throughout the document? ex. sensors? I mean how about hosts, machines, clients?
It’s endemic in the tech security industry - they’ve been mentally colonised by ex-mil and ex-law enforcement (wannabe mil) folks for a long time.
I try to use social work terms and principles in professional settings, which blows these people’s minds.
Advocacy, capacity evaluation, community engagement, cultural competencies, duty of care, ethics, evidence-based intervention, incentives, macro-, mezzo- and micro-practice, minimisation of harm, respect, self concept, self control etc etc
It means that my teams aren’t focussed on “nuking the bad guys from orbit” or whatever, but building defence in depth and indeed our own communities of practice (hah!), and using psychological and social lenses as well as tech and adversarial ones to predict, prevent and address disruptive and dangerous actors.
YMMV though.
Re: Preliminary Post Incident Review
#23[flagged]
How can these companies be certified and compliant, etc., and then in practice have horrible SDLC?
What was the impact of diverse teams (offshoring)? Often companies don’t have necessary checks to ensure disparateness of teams does not impact quality. Maybe it was zero or maybe it was more.
Re: Preliminary Post Incident Review
#24[flagged]
The thread is still wrong, since it was a OOB memory read, not a missing null pointer check as claimed. 0x9c is likely the value that just happened to be in the OOB read.
Re: Preliminary Post Incident Review
#25They bypassed the tests and staged deployment, because their previous update looked good. Ha. What if they implemented a release process, and follow it? Like everyone else does. Hackers at the workplace, sigh.
They know better obviously, transcending process and bureaucracy.
Re: Preliminary Post Incident Review
#26Such a disingenuous review; waffle and distraction to hide the important bits (or rather bit: bug in content validator) behind a wall of text that few people are going to finish. If this is how they are going to publish what happened, I don't have any hope that they've actually learned anything from this event. > Throughout this PIR, we have used generalized terminology to describe the Falcon platform for improved re…
> "behind a wall of text that few people are going to finish."
heh? it's not that long and very readable.
Re: Preliminary Post Incident Review
#27Why do they insist on using what sounds like military pseudo jargon throughout the document? ex. sensors? I mean how about hosts, machines, clients?
because those things are different? i didn't see a single "military" jargon. there is absolutely nothing unusual about their wording. It's like someone saying "why do these people use such nerdy words" regarding HN content.
Re: Preliminary Post Incident Review
#28A summary, to my understanding:
* Their software reads config files to determine which behavior to monitor/block
* A "problematic" config file made it through automatic validation checks "due to a bug in the Content Validator"
* Further testing of the file was skipped because of "trust in the checks performed in the Content Validator" and successful tests of previous versions
* The config file causes their software to perform an out-of-bounds memory read, which it does not handle gracefully
Re: Preliminary Post Incident Review
#29Re: Preliminary Post Incident Review
#30Such a disingenuous review; waffle and distraction to hide the important bits (or rather bit: bug in content validator) behind a wall of text that few people are going to finish. If this is how they are going to publish what happened, I don't have any hope that they've actually learned anything from this event. > Throughout this PIR, we have used generalized terminology to describe the Falcon platform for improved re…
> "behind a wall of text that few people are going to finish." heh? it's not that long and very readable.
I disagree; it's much longer than it needs to be, is filled with pseudo-technoese to hide that there's little of consequence in there, and the tiny bit of real information in there is couched with distractions and unnecessary detail.
As I understand it, they're telling us that the outage was caused by an unspecified bug in the "Content Validator", and that the file that was shipped was done so without testing because it worked fine last time.
I think they wrote what they did because they couldn't publish the above directly without being rightly excoriated for it, and at least this way a lot of the people reading it won't understand what they're saying but it sounds very technical.