What you actually cannot afford is have email clients that are easily hacked via email. Like Outlook.

You can't really beat the fundamental economics of software development: expensive to do right but cheap to copy means that you really, really, want to share a problem with as many other people as possible(unless your whole business is being uniquely good at solving whatever the problem is; but that typically isn't the case for this sort of software). Applies to both proprietary and FOSS: relatively mass-market software is often pretty cheap for what you get; really oddball niche stuff is frequently both pricey and terrible; while your life is going to get steadily more miserable if you are personally responsible for handling backports and fixes for some internal fork of a long-EOL version of an OSS package.

The big difference, at least potentially, is that, while it tends not to be economic to DIY, licenses that give you the right to DIY also give you the right to pay someone else to do it for you; or to form a coalition of people with similar problems and have everyone pitch in to pay someone to do it for you. You still need to either eat the cost of maintaining an internal fork or putting together some sort of coalition of people with similar problems to be the openJDK 8 forever pals and share the cost of maintenance; but the vendor can't just stop selling you licenses if they want you to move to their cloud offering or whatnot.

They primarily manage company-internal CAs for big businesses, which they seem to do well. AFAICT, they noticed that their security infrastructure was compliant for managing a global CA, and thought they might as well also have that as a product. However, there are some operational differences between an enterprise CA and a public one, including that companies want to issue client certs to employees but nobody really does global client certs. That means that they had an intermediate CA for global client certs that they never used, but it was in the standard trust store, and nobody tested that it was handled right until Wayne just went through the standard trust store making sure a new certificate weakness detector didn't give false positives.

So eMudhra correctly handled all the certs they issued, and all the certs they used to sign them, but they got some extra CA certs trusted that they didn't really need, because it would make their side business more similar to their main business, and this caused a major problem.

Chances are that they actually got a real random number out of a HSM for the bad CA certs, but accidentally made the certs with the index of the random number instead of the actual number. (That is, they got the 4th random number and made a cert for 4 instead of the number.) I wouldn't be surprised if they stored the correct private key, which would have made leaf certs that didn't validate because the intermediate was wrong, but they never used it to find this problem.

Random intermediate CA. They got a couple of commonly used root CAs to sign for them; and everything just works from there.

That's the problem. It's relatively easy to fire a certificate issuer; but it can get surprisingly fiddly surprisingly fast to ensure that all your stuff actually distrusts one(unless you are responsible for basically nothing but a a handful of in-support major browsers and are OK with the choices their vendors make, in which case it will be handled for you relatively quickly; and was in this case). Basically any network connected widget is going to have at least one trusted root store embedded in it somewhere, possibly not updated anymore; and a number of software packages either bring their own or only partially track the OS-provided one.

You also have very little control over what other people do; both what CAs they chose to get certs from and what...questionable...partnership decisions the root CAs you do chose to trust. It's not technically secret; but unless you are practically a full-time PKI nerd you probably didn't know until after the fact that Comodo, now Sectigo, had quietly trusted eMudhra for you.

I fully admit that this might be a 'me' problem, not a them problem; but I just don't understand why this agent monitoring setup was so vulnerable and is being treated as so novel.

Sure, the monitoring of whatever goes on inside the LLM is comparatively new and exotic; but when you set it loose on the internet it's going out through one or more of your WAN links, presumably with your router and firewall and so on in the way, and is mostly doing HTTP(s) stuff. Keeping an eye on what an internal host is doing when you can insert whatever trusted roots you want for TLS MiTM and you 100% own the pipe that it is using to communicate is not necessarily a desperately enjoyable task; but it would have been a relatively banal requirement a quarter century ago.

I'd also think that, when you are spending $$$$$ on the exercise in Nvidia compute gear, and it's a test of a 'frontier model' whose behavior and capabilities you are trying to better characterize and refine, allocating the handful of terabytes necessary to just store a full packet capture of the session in case it is relevant would be a no-brainer item.

Is there something I'm missing that makes this case more complex? I'm not talking about the 'grubbing around in the LLM's vectors and such' side; just the "a host is doing HTTP stuff through a WAN link we control, can we observe what it is doing?" aspect.

The email wasn't even too good to be true. The nasty phishing emails are the ones where the recipient is supposed to get a real email on the topic, but it's because of a publicly known event and outsiders could easily make up the content, so they just need to find a bunch of likely recipients.

I think the "you've been assigned the mandatory phishing training" emails should come from an external sender and contain a link to get into the extended training, and you should only get the short refresher by finding it through verified sources. Not only would this be a good placement test, it would test that official communications are actually hard to fake and possible to verify using the process in the training.

"In response to the embarrassing data breach that hit the news recently, we've assigned every employee at the company an online training session about phishing at this link. By sure to take it immediately, because it's a legal requirement for our settlement and delays could affect your employment." --Russian Hackers

Exactly. This is a technology problem, not a user problem. Trying to fix it on user side accomplishes nothing.

User awareness is impossible to create. Yes, for the rather primitive phishing campaigns of 10 or even 5 years ago it was possible to a very limited degree. With the attackers now using LLMs, that time is past. Get actually secure email systems and clients or get hacked. Those are your only choices.

Employees cannot be trained to recognize suspicious emails. I do not know which blithering idiot came up with the idea, but regular people cannot be qualified to do what takes an IT security expert and even that expert will occasionally fail.

Yes. These tests are worse than useless. They insult those with a clue and waste the time of everybody. They make everybody angry and that means less mental power to recognize scams and problems. They are a meaningless ritual that accomplishes less than nothing.

The thing that would need to be done is use of better technology. And that is the only thing that can fix this problem. The user is not the problem.

That is because you give your users technology that sucks and cannot be secured. Terrorizing your users will do nothing. Using better technology will. Yes, that means dumping the steaming pile Microsoft sells on the trash-heap of history where it belongs, and quite a few other offerings as well. Yes, that means telling the C-levels they have to get used to a different desktop. But nothing else will do it.

If your IT security is so abysmally bad that clicking on a link can blow up your set-up, "educating" employees will do nothing. And if that is the best your go-to vendor can deliver, get a different one.

That said, information about complex phishing attacks, like the "chef email" scam and the like, is different. But these target human interaction, not intricate technology that is very much outside of the areas of expertise of almost everybody.

Agreed.

Only that Putin has done a long string of wars like that before. The difference is that Ukraine has been able to fight back quite efficiently. I guess Putin got used to winning and lost contact to reality along the way.

So, no, this claim that Russia was provoked or had no choice is Russian propaganda. It cannot hold water on closer inspection. They just want some of that victim bonus, so they twist reality beyond all recognition to convince some useful idiots.