Art Manion

[Robert Graham @robertgraham]

We know what probably happened.

From what we see publicly, NightmareEclipse doesn't communicate well, is emotionally immature, and appears to want to extort Microsoft.

Almost certainly, this played a part in the conflict between them and Microsoft -- it's probably as much NightmareEclipse's fault as Microsoft's.

With that said, everything Florian says is correct. It doesn't excuse Microsoft's failures. They are supposed to be the responsible one,

When there is miscommunication or dispute, it's always allowable to drop 0day, regardless whose fault it is. It's Microsoft's job to avoid that, even when they really aren't at fault for the miscommunication.

But Microsoft has convinced themselves of the opposite, that "responsible" disclosure means only the responsibilities of the vuln finder.

Vuln finders have no responsibility. Dropping 0day is responsible. Responsible companies don't have so many bugs.

We let industry subvert the disclosure process. Instead of working to secure their code, vendors have tricked people into believing in the myth of "responsible disclosure", that vendors should be given time to fix and patch their bugs so they are never to blame for the bugs to begin with.

That's why you have customers still buying Fortinet appliances even though their bugs continue to be major sources of customers getting hacked. Customers shrug their shoulders: as long as Fortinet has a vulnerability disclosure program and releases patches, they aren't responsible for when hackers keep breaking into their boxes.

This is garbage. Vendors are still responsible for preventing bugs in the first place, a responsibility that doesn't go away just because they patch.

Regardless of what happened, Microsoft's threats are a gross violation of ethics in the industry.

[Art Manion @zmanion]

Only weeks away, if you can sort out travel or are maybe relatively near Utrecht, a boutique, high-quality vulnerability measurement and prediction festival:
https://t.co/bUtSS5Xm0C

[Art Manion @zmanion]

@robertgraham Chaos A.D.

[Art Manion @zmanion]

@daveaitel @arekfurt would perl be better? ;)

[Art Manion @zmanion]

@arekfurt But also, some minimum bar for well-known security issues, like running web apps on the internet as root (VPNs...), see also https://t.co/FVmi3xe0SA

[Art Manion @zmanion]

@arekfurt IMO measuring *product* liability is difficult, because measuring *product* security is difficult, so an option is to measure vendor/supplier/producer behaviors: transparency about vulnerability reports, fixes (delivered securely), EOL, SBOM/dependencies

[Art Manion @zmanion]

@pyotam2 @sonatype Fundamentally I really don't like using a *vulnerability* ID for malware. Seems like CVE will continue to allow assignments for trojans/backdoors (surprising and unwanted software behavior + security impact) but not for "straight up" malware (which can be a relative label)

[Art Manion @zmanion]

@pyotam2 I ran into this recently, I think it uses MAL- and https://t.co/hQSOW3gey5: https://t.co/WvnePG7sx3

[Art Manion @zmanion]

@proustmalone @TGreg72 The medium is the message

[Art Manion @zmanion]

@armengar @Andrew___Morris @GreyNoiseIO Yeah working a mapping table again for like the Nth time

[Art Manion @zmanion]

@robertgraham "We use this" and "the way we use it is vulnerable" can be independent, and we might not know or tell if it's vulnerable, but with SBOM at least you can ask, investigate on your own, or maybe augment your purchasing decisions.

[Art Manion @zmanion]

@threehalfs @daveaitel This is my understanding but I don't have one in hand.

[Art Manion @zmanion]

Anyone who operates a physical Ivanti ICS device: How do you boot it from known-good media? E.g., an external USB drive, a reasonably secure boot loader, minimal ROM image?

[Art Manion @zmanion]

@fortraofficial as a CNA, you have the first opportunity to assign and publish a CVE ID. If you chose not to, another CNA can act. Also, silent patches rarely are.

[Joel Land @joel_land]

@fortraofficial @Horizon3ai @stephenfewer Looking into the fix for CVE-2024-0204 and it's clear that the root issue is the path traversal "/..;/" -- this was not fixed in GoAnywhere MFT 7.4.1. However, it does appear to be fixed in 7.4.2, though another silent fix. Any CVE yet?

[Art Manion @zmanion]

@truekonrads @allanfriedman @daveaitel I also suspect that sort of secrecy may be reduced over time, after all, it's mostly a secret from customers, not from adversaries.

[Art Manion @zmanion]

@truekonrads @allanfriedman @daveaitel Another option is to tell only customers, under whatever sort of support login terms of service. Or keep the SBOM secret, but you really better actually have SBOM when it matters. In some sense sharing SBOM with customers could be a degree of risk transfer.

[Art Manion @zmanion]

@WeldPond @A_P_Delchi suppliers are the least cost avoider, also I bet suppliers would prefer to manage the notification vs. have a regulator/legally-mandated third-party come calling

[Art Manion @zmanion]

@wdormann I'd rather have a CVE ID for "something under investigation that sure seems like one or more new vulnerabilities" than no CVE ID or the ID is delayed until fixes are released.

[Art Manion @zmanion]

@joshcorman and Audra reminding us that SBOM is a roadmap for the defender. With minesweeper. #SBOMaRama