Carbon Black’s Solo Venture, Cybersecurity in Space, Rethinking Human Error, & More! – ESW #342

Adrian: "I guess you could think of this as a divestiture within an acquisition? Not sure if this is a positive thing or not. I've heard a lot about Carbon Black falling behind the rest of the market under VMware ownership, and last week we heard about layoffs following the completion of the VMware acquisition, so maybe this is good news, maybe not. Time will tell."

Cyberz in Spaaaaaaaace!

Adrian: "Someone posted this in response to a LinkedIn post on not blaming employees when their mistakes result in cybersecurity issues. I've added it here for two reasons: 1) because I think it's important to remember that some of the issues we security folks run into have often already been solved in other, older disciplines, and 2) many security folks still seem to have a hard time with understanding that the direct cause of a cascading failure (like a breach) isn't necessarily responsible for it.

For example - when a bridge fails, we wouldn't blame the people driving on it at the moment it failed, right? Damn that Doug White and that extra cheeseburger he had at Five Guys today! He made the bridge fall!

Of course not! Instead, we aim to understand more about how the bridge was constructed, maintained, monitored, and inspected to understand the (more than likely) groups of factors that played a part in the failure.

An organization's computer systems, applications, networks, and other components are also a complex system, and when failures occur, it is also typically groups of factors that all contribute."

Adrian: "We're seeing a lot of shifting from traditional models and assumptions now that failures (mostly ransomware) is hitting companies hard, and often. We've long had the data telling us that using patching as a defensive measure requires extremely quick response. Quicker than most organizations can muster.

If vulns are going to be exploited, they'll generally happen in hours or days. At that scale, there are only a few options:

1. fully automate software updates and skip QA/safety testing altogether
2. put mitigations in place very quickly (e.g. virtual patching, vuln/exploit-specific mitigations)
3. design systems/networks to be more resilient to attacker actions in general (e.g. isolation, zerotrust, principle of least privilege, etc)

We saw the latter two in action following Okta's latest breach, as BeyondTrust, Cloudflare, and 1Password seemed to detect the attacks very quickly, and (according to them, at least) were able to isolate and eradicate the attackers.

In another example, the folks that fared best during the Log4Shell debacle were those that denied outbound comms by default for servers or any other systems that didn't really need it. Turns out that malicious code can't do much damage if it can't communicate back out!

In conclusion, I hate to say that traditional vuln management seems like a waste of time, but... I don't think getting OT vendors to switch to rust, as CISA suggests, is the solution either."

Adrian: "I'm sorry, did you say XP-CMDSHELL???

What Year is It.GIF"

News Article detailing some of the latest fails and shutdowns.