Your post could've been written in 2004, when Microsoft was pinky swearing it was gonna refocus on security-first development, starting with XP SP2

To be a bit fair, Windows security has gone from a laughing stock in 2004, to having Windows Defender in the 2020s. I ain't no city slickin' infosec guy, but Defender appears to be state of the art end point protection today.

They can figure this stuff out sometimes, right?

How did they get from Windows/AVG/ESET to Windows Defender, and how can they make that happen on Azure?

To me this seems like a different aspect of security. The push with the winxp service packs onwards was to make it secure by default against the network (trying to be vague because I'll probably be wrong on the details), I'm fairly sure it was xp where you could be infected before setup was complete if the network was plugged in, or that acquiring third party AV was something you must do for anything that touches the internet or media from a source you can't 100% trust. Now with defender this is far in the background for most users that they don't need to think about it at all.

The difference with recall is about blast radius of any unauthorized/unintended access, which still happens even if it's less common or via something like clicking a bad link in an email. That's in addition to mistrust of MS or large corporations sucking up data, and how secure they are (what would a Ashley Madison type breach look like with recall data?)

Azure is much more secure than regular Windows.

They did improve their story, with SAL exactly introduced for XP SP2, and having for many years having one of the few C++ standard libraries with bounds checking enabled by default in debug builds.

However that was it, WinDev fought against Longhorn, Office folks redid the .NET ideas in COM for Vista, and so on.

The same way as .NET FOSS, MS <3 Linux and such happened, by having a captain on the bridge that actually cares to make it happen, not sure if that is still Satya though.

If I understand the modern security issues correctly, this is all happening on Azure, correct? Windows is relatively secure, but their cloud has too much legacy compatibility/tech debt?

For example, Kerberos support in Azure AD led to the some of the latest issues?

On the contrary, Azure has a much better security culture than Windows business unit.

Most stuff is built with .NET, Go, Java and Rust, while the hypervisors are based on Windows (Azure Host OS[0]) it isn't the same as regular Windows, and most workloads are Linux based, officially > 60% [1].

Finally, starting this year, Azure has new security guidelines, all new software is to be written in managed languages, if a GC is not an impediment, Rust otherwise.

Writing code in either C or C++, is only allowed for existing products, with the related security guidelines in place[2].

[0] - https://techcommunity.microsoft.com/t5/windows-os-platform-b...

[1] - https://azure.microsoft.com/en-us/products/virtual-machines/...

[2] - https://x.com/dwizzzleMSFT/status/1720134540822520268

Thank you, I really appreciate this response. I need to read all of this. However, the most recent compromises did happen on Azure, and not Windows, correct?

edit: and of course that's where the threat actors put their focus, because that's where the data lived.

The whole issue is with Recall storage, and information gathering on Windows.

Yes, sorry, I had diverged upthread into the part where the CCP read the USA's gov emails.

I can't get over that little tidbit.

Per Microsoft's write-up:

> Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com. All MSA keys active prior to the incident – including the actor-acquired MSA signing key – have been invalidated. Azure AD keys were not impacted. The method by which the actor acquired the key is a matter of ongoing investigation. Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens. This issue has been corrected.

So the attackers found a valid private key for MSA (undetermined how, the theory was that it was scraped from a debug dump that was moved from high privilege prod to someone's low privilege shared drive). They then used that key to sign invalid tokens for AAD and the validating side incorrectly accepted those tokens. In this case, the validating side would be Exchange / OWA. Azure AD seems to not be implicated in the security issues, since it was MSA that leaked the key and OWA that failed to properly validate it.

That's my interpretation of the text anyway. It also aligns with my own understanding from a brief time at MS that Azure is much better at security than the rest of MS and that Exchange is a dumpster fire because of decades of cruft and evolution of systems.

Thank you so much, this really closed the gaps in my understanding of what really happened.

Put DevDiv’s bosses in charge of WinDev.

I fear they would riot. :)