In looking for a direct quote from the Report \/ Root Cause Analysis (RCA) it has dawned on me that there is not just one gem that could be used here, but in-fact a whole plethora of them.<\/p>\n\n\n\n
\n“While this scenario with Channel File 291 is now incapable of recurring, it also informs process improvements and mitigation steps that CrowdStrike is deploying to ensure further enhanced resilience.”
– Crowdstrike RCA 2024 pg 2.<\/p>\n<\/blockquote>\n\n\n\nThat quote above is one of the many gems in this RCA in relation to what Crowdstrike is calling the “issue”. Rather this is more the problem as we shall see, they have the problem and the Issue confused.<\/p>\n\n\n\n
The Problem was a number of things not ‘throwing flags’ during testing, which brings me to the next part rather nicely. The only testing this software went through was MOCK Testing … ummm yeaaah… Mock testing is basically where the developers write “scenarios” for it to run through, this while it might be handy for catching some syntax errors should never be the only testing the software undergoes.<\/p>\n\n\n\n
ok ok so it looks like I got ahead of the pace a bit here, so let’s back pedal to page 3 of the RCA report.
I will follow these point by point with commentary of course. denoted with [ square brackets ]<\/p>\n\n\n\nFindings and Mitigations<\/h2>\n\n\n\n
Issue 1:<\/strong> The Number of Fields in the IPC template Type Was NOT Validated at Sensor Compile Time.
Mitigation:<\/strong> Validate the Number of Input Fields in the Template Type at Sensor Compile time.
[ WHY THE HECK NOT? shouldn’t this be done for EVERY sensor compile? of course dingdong didn’t think of it that way ]
Issue 2:<\/strong> A Runtime Array Bounds Check was Missing for Content Interpreter Input Fields on Channel File 291
Mitigation:<\/strong> Add Runtime Input Array Bounds Checks to the Content Interpreter for Rapid Response Content in Channel File 291
[ only one question begs to be answered – WHY? Why was this not a check in previous versions? it seams like it would be trivial to add ]
Mitigation #2:<\/strong> Correct the Number of Inputs provided by the IPC Template Type
[ THIS could be done easily, with an IF statement \/ function that returns the number of inputs and parses that number to the correct Variable ]
Issue 3:<\/strong> Template Type Testing Should Cover a Wider Variety of Matching Criteria
Mitigation: <\/strong>Increase Test Coverage During Template Type Testing
[ WELL DUH! You seriously think this will help now? why wasn’t it implemented back in Ver 0.2 ? ]
Issue 4:<\/strong> The Content Validator Contained a Logic Error
[ Yeah, No Shit Sherlock this is possibly the root cause of the issues ]
Mitigation:<\/strong> Create Additional Checks in the Content Validator
Mitigation 2:<\/strong> Prevent the Creation of Problematic Channel Files
[ OK so the first Mitigation point here is fine, in-fact I can see this being fairly easy to implement, but the second? How does one prevent Humans (my sincere apologies but we are kinda the worst enemy when it comes to computers) from making bad files and adding them to the system? ]
Issue 5:<\/strong> Template Instance Validation SHOULD Expand to Include Testing Within the Content Validator
[ Good point, Now why wasn’t it originally done this way? ]
Mitigation:<\/strong> Update Content Configuration System Test Procedures
[ This should be done periodically anyway, was it never done before and if not why not ]
Issue 6:<\/strong> Template Instances Should Have Staged Deployment
[ ummm Why wasn’t this already a thing? ]
Mitigation:<\/strong> The Content Configuration System has been Updated with Additional Deployment Layers and Acceptance Checks
[ yeah whilst this might help somewhat,it can be more of a hindrance than anything, Also why is this not already part of the “checks” before deployment?]
Mitigation 2:<\/strong> Provide Customer Control Over the Deployment of Rapid Response Content Updates
[ This isn’t part of the problem … I don’t know why it’s here]<\/p>\n\n\n\nWhat I make of this CIRCUS<\/h2>\n\n\n\n
Apart from my first thoughts upon reading the points and mitigations above, CS have got themselves some kinda trouble – possibly legal trouble – in the form of GROSS NEGLIGENCE aka Carelessness. Along side that, though it may be looked at as a bit of a meme the Regular Expression (REGEX) Licensing group website does NOT show a valid license, so if this group were to go after CS for illegally using their product without licensing then CS would be in for a bad time, this might be mitigated however if the Programing Language they are using contains a license for it, I almost am inclined to doubt that though as the mention of C++ in the RCA document indicates that it was a language that is somewhat notorious for not having a lot of native support for things like regex. <\/p>\n\n\n\n
The CS Stocks have taken a Major Crash and are likely to take another one after this report makes its rounds.<\/p>\n\n\n\n
This mess that CS is Obviously looking at as a “few quick patches and It’ll be fine” but that is very much not the case, as a few has pointed out – the RCA (not the highlighted version I have written here) is “hot potato – pass” situation with CS trying to blame MS (Microsoft) for letting them have access to the Kernel. unfortunately for CS that argument is like “I Fucked Up and I Fucked Up because You Let Me Fuck Up” – a total fallacy.<\/p>\n\n\n\n
Al though I am not a programmer in the slightest (PHP, HTML, CSS and SQL being my portfolio) I find this RCA report to be thoroughly embarrassing and my only hope is that CS do too.<\/p>\n\n\n\n
This Report reads like “we are a bunch of clowns” I believe their ToS even includes a line along the lines of “you can’t trust us” or at least that’s what I’ve heard.
All this being said . . . you shouldn’t trust anyone online (especially multi-Billion dollar companies) with your data – far less the data that you can’t imminently see – yes the CS RR Falcon software may need the kernel to carry out it’s anti-malware stuff but also if CS wanted to they could use it to spy on the users and potentially incriminate them, I highly doubt anyone wants the FBI to come knocking for something that CS “saw or Detected” you do.<\/p>\n\n\n\nI hope this will be the last post I make on CS but I have a funny felling I’ll be back writing about them once this Delta Airlines legal action has concluded and we know the outcome along with others that will likely be happening at the same time. Anyone who was affected or is I.T. person for a network that got affected want to make life interesting? It might just be time for some class action baby!
A $10 Uber Eats Gift Card that might not even work is NOT enough!<\/p>\n\n\n\nwell that’s all from me for now – we shall see how this goes and if needed another article will be written.
Cheers, From NZ!
Bryce<\/p>\n\n\n\n\n<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
In looking for a direct quote from the Report \/ Root Cause Analysis (RCA) it has dawned on me that there is not just one gem that could be used here, but in-fact a whole plethora of them. “While this scenario with Channel File 291 is now incapable of recurring, it also informs process improvements and mitigation steps that CrowdStrike is deploying to ensure further enhanced resilience.” – Crowdstrike RCA 2024 pg 2. That quote above is one of the many gems in this RCA in relation to what Crowdstrike is calling the “issue”. Rather this is more the problem as we shall see, they have the problem and the Issue confused. The Problem was a number of things not ‘throwing flags’ during testing, which brings me to the next part rather nicely. The only testing this software went through was MOCK Testing … ummm yeaaah… Mock testing is basically where the developers write “scenarios” for it to run through, this while it might be handy for catching some syntax errors should never be the only testing the software undergoes. ok ok so it looks like I got ahead of the pace a bit here, so let’s back pedal to page 3 of the RCA report.I will follow these point by point with commentary of course. denoted with [ square brackets ] Findings and Mitigations Issue 1: The Number of Fields in the IPC template Type Was NOT Validated at Sensor Compile Time. Mitigation: Validate the Number of Input Fields in the Template Type at Sensor Compile time.[ WHY THE HECK NOT? shouldn’t this be done for EVERY sensor compile? of course dingdong didn’t think of it that way ] Issue 2: A Runtime Array Bounds Check was Missing for Content Interpreter Input Fields on Channel File 291Mitigation: Add Runtime Input Array Bounds Checks to the Content Interpreter for Rapid Response Content in Channel File 291 [ only one question begs to be answered – WHY? Why was this not a check in previous versions? it seams like it would be trivial to add ]Mitigation #2: Correct the Number of Inputs provided by the IPC Template Type[ THIS could be done easily, with an IF statement \/ function that returns the number of inputs and parses that number to the correct Variable ] Issue 3: Template Type Testing Should Cover a Wider Variety of Matching CriteriaMitigation: Increase Test Coverage During Template Type Testing[ WELL DUH! You seriously think this will help now? why wasn’t it implemented back in Ver 0.2 ? ] Issue 4: The Content Validator Contained a Logic Error[ Yeah, No Shit Sherlock this is possibly the root cause of the issues ]Mitigation: Create Additional Checks in the Content ValidatorMitigation 2: Prevent the Creation of Problematic Channel Files[ OK so the first Mitigation point here is fine, in-fact I can see this being fairly easy to implement, but the second? How does one prevent Humans (my sincere apologies but we are kinda the worst enemy when it comes to computers) from making bad files and adding them to the system? ] Issue 5: Template Instance Validation SHOULD Expand to Include Testing Within the Content Validator[ Good point, Now why wasn’t it originally done this way? ]Mitigation: Update Content Configuration System Test Procedures[ This should be done periodically anyway, was it never done before and if not why not ] Issue 6: Template Instances Should Have Staged Deployment[ ummm Why wasn’t this already a thing? ]Mitigation: The Content Configuration System has been Updated with Additional Deployment Layers and Acceptance Checks[ yeah whilst this might help somewhat,it can be more of a hindrance than anything, Also why is this not already part of the “checks” before deployment?]Mitigation 2: Provide Customer Control Over the Deployment of Rapid Response Content Updates[ This isn’t part of the problem … I don’t know why it’s here] What I make of this CIRCUS Apart from my first thoughts upon reading the points and mitigations above, CS have got themselves some kinda trouble – possibly legal trouble – in the form of GROSS NEGLIGENCE aka Carelessness. Along side that, though it may be looked at as a bit of a meme the Regular Expression (REGEX) Licensing group website does NOT show a valid license, so if this group were to go after CS for illegally using their product without licensing then CS would be in for a bad time, this might be mitigated however if the Programing Language they are using contains a license for it, I almost am inclined to doubt that though as the mention of C++ in the RCA document indicates that it was a language that is somewhat notorious for not having a lot of native support for things like regex. The CS Stocks have taken a Major Crash and are likely to take another one after this report makes its rounds. This mess that CS is Obviously looking at as a “few quick patches and It’ll be fine” but that is very much not the case, as a few has pointed out – the RCA (not the highlighted version I have written here) is “hot potato – pass” situation with CS trying to blame MS (Microsoft) for letting them have access to the Kernel. unfortunately for CS that argument is like “I Fucked Up and I Fucked Up because You Let Me Fuck Up” – a total fallacy. Al though I am not a programmer in the slightest (PHP, HTML, CSS and SQL being my portfolio) I find this RCA report to be thoroughly embarrassing and my only hope is that CS do too. This Report reads like “we are a bunch of clowns” I believe their ToS even includes a line along the lines of “you can’t trust us” or at least that’s what I’ve heard.All this being said . . . you shouldn’t trust anyone online (especially multi-Billion dollar companies) with your data – far less the data that you can’t imminently see – yes the CS RR Falcon software may need the kernel to carry out it’s anti-malware stuff but also if CS wanted to they could use it to spy on the users and potentially incriminate them, I highly doubt anyone wants the FBI to come knocking for something that CS “saw or Detected” you do. I hope this will be the last post I make on CS but I have a funny felling I’ll be back writing about them once this Delta Airlines legal action has concluded and we know the outcome along with others that will likely be happening at the same time. Anyone who was affected or is I.T. person for a network that got affected want to make life interesting? It might just be time for some class action baby! A $10 Uber Eats Gift Card that might not even work is NOT enough! well that’s all from me for now – we shall see how this goes and if needed another article will be written.Cheers, From NZ!Bryce<\/p>\n","protected":false},"author":1,"featured_media":95,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,1,25],"tags":[71,30,27,69,70,73,72,68,67],"class_list":["post-94","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-big-tech","category-random","category-technology","tag-8mill","tag-bsod","tag-cs","tag-fail","tag-idiots","tag-its-not-our-fault","tag-pcs","tag-rca","tag-report"],"_links":{"self":[{"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/posts\/94","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/comments?post=94"}],"version-history":[{"count":3,"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/posts\/94\/revisions"}],"predecessor-version":[{"id":197,"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/posts\/94\/revisions\/197"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/media\/95"}],"wp:attachment":[{"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/media?parent=94"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/categories?post=94"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brycefromnz.live\/blog\/wp-json\/wp\/v2\/tags?post=94"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}