Mono culture is always a bad idea and thinks like MS cloud services are the basis for creating a technical pandemic.

Yes, you can hack every company but he have to target them one by one.

Now you only need to take down MS

The expected value rises.

Mostly, if you don't have too high expectations.

My employer has had to invest I don't even want to know how much in an EDR (or whatever it's called nowadays) and a slew of services around this circus just to pretend their Windows systems are secure. Didn't catch a home-grown cryptolocker, though, and happily allowed it to encrypt its own files.

They mostly use web-bases SAAS applications anyway, so could trivially replace windows with an OS with a better security track record.

Plus, AzureAD always seemed kludgy. Until recently, they insisted on having SMS or phone as a second factor for password recovery. Which allowed you to reset the stronger 2nd factor used for auth. They only started supporting Fido tokens like a year or so ago for regular 2fa. Their authenticator is a joke: until recently, you had no idea what you were approving. It still doesn't support group inheritance, so if you base it on your local AD as the source of truth, you have to jump through more hoops and add more ad-hoc groups and maintain them. Good times.

Which is precisely why they went all in on Microsoft Cloud. Using an in-house stack (no matter if it's Jira, Confluence, Exchange, AD, Postfix, Exim, OpenLDAP, Samba, ...) will always lead to people blaming the C level for any outage, hack, whatever. Miss one tiny little patch and insurance won't pay.

Go for Atlassian Cloud/Microsoft/AWS/GCP? You can now deflect any blame onto the cloud provider. No personal liability, nothing. You followed industry best practices, so insurance pays out.

You can’t really avoid them.

Probably because by the time this saying was forged, there wasn't this big push from chickens to integrate as many features as possible and improve their functionality and QoL that's only avaible when you do put all the eggs in the same place

AWS has live customer support you can ring (if you pay for it) and frequently as a client you get an account manager you can call in case of trouble and that person has direct access to support teams. These support peoole can actually fix stuff for you. Back in the day I've handled lots of support cases like this.

Google on their website claims they also offer live support, but I read enough stories with headlines like "Google deleted my business overnight and there's no one to talk to" to question it's usefulness. I haven't had a chance to deal with Google's GCP support yet so I don't know how good or bad it might be, but I had a couple of support cases raised for other products (play store, book publishing etc) and it was obvious people that work there can't really do anything if stuff breaks. They're there just for Google to be able to say "we too have live support" and to tell you how to do stuff in lieu of documentation. When stuff breaks... You get an email "we're escalating it _to_developers_" to never hear from them again (or you get an email every month asking you if the issue is still ongoing)

So I think it is the biggest case of "putting all your eggs in one basket" I saw in a while. If anyone has contrary experience of GCP support I'd love to hear it.

I am yet to see any examples of “Google Cloud” shutting down services on their own whim or not providing a human custom service agents.

https://azure.microsoft.com/en-us/updates/the-managed-iot-ed...

I think there’s a difference between how Google does things on the search side vs their cloud side.

The regularity with which they deprecate services on the search side is unacceptable.

On the cloud side it doesn’t seem to be anywhere close to that

All in all it's been a good experience and it's become my favourite cloud. I find the documentation spot on for the most part, and covering things in both approachable language and diving deep where needed.

The IAM system is easy to use, GKE workload identity works great, PubSub works a dream and Big Query is amazing (though pricey!). SDK's are well documented and generally have nice APIs as well.

We've had very little reason to need support, operating a bunch of GKE clusters, VPNs to various partners plenty of databases, buckets, message queues, etc (non trivial setup)

I do have some minor gripes that come to mind: - Cloud SQL not having a richer API, I'd love to be able to manage postgres permissions by IAM group membership, and grant/revoke postgres roles using the rest API instead of connecting as a postgres user (it'd make secure automation via terraform etc easier if I could lean on IAM) - VPC peering only allowing "one hop", which necessitates proxies even when using private service connect with two GCP products in some instances (eg: cloud SQL to datastream - why can't we just peer the two Google managed VPCs together? That would also avoid the proxy in our VPC) - On datastream, why can't I grant a Google managed service account IAM access to postgres instead of configuring a user/pass based user? - Why can't I configure a longer token expiration for artefact registry? When developing locally I don't want to reauth npm every 30 minutes - Occasionally missing APIs prevent automation using terraform

So like anything it's not perfect but it also has felt like it's continuously improved overtime so I remain a happy developer

Why is it just a handful of keys shared by dozens, hundreds, or likely even thousands of servers? Where is the HSM-backed root key, per-DC intermediate, and per-server transient signing key? Where is the certificate revocation list?

Is it even possible to secure a bearer token from an attack like this? Should we go back to a nonce which we present to the originating service to securely retrieve the payload?

I've seen service provider implementations where the access token is exchanged for a cookie or other similar token, in which case you can't really do anything about it anymore for the lifetime of the cookie.

But if you're always verifying the access token with a reasonably short cached key list, the service provider should be able to refuse the token reasonably quickly once the key is no longer advertised.

When we ran some stress tests, turned out Envoy could happily run with ~300K signing keys in its JWK Set before noticeable service degradation occurred. Even then, by bumping up the memory on the validation servers, there was a small sacrifice of a few ms per extra 100K keys.

This makes me fully agree that, for many applications, there’s probably an opportunity to vastly improve the security surface by bumping up the number of signing keys dramatically.

As long as both Keys and Signing keys define a KID, key verification is prefaced only by a hash table lookup or a tight loop through a keyset to find the appropriate Signing Key, before the slower verification procedure.

More seriously, though, I wonder how AzureAD is implemented and how hard it would be to scope keys per tenant, if not per application. If I'm not mistaken, SAML certificates are per application.

Taking your POC just a bit further and you've got the basis for zero trust networking, right?

That's the Future Perfect Correct Answer™, right?

https://en.wikipedia.org/wiki/Zero_trust_security_model

No incentive, right? If you mess up as a CA, you go out of business because every browser drops you. But if you're an identity provider and you have an incident, maybe 1% of your customers opens an angry support ticket and you give them 5% off their bill next month. So why bother? Are YOU going to move your 100,000 employee organization off of Microsoft because of this? No? Then why would they care at all? They won the sale and you're stuck with what you get.

Here's a list of companies that have gone out of business because they didn't take information security seriously:

<list not found>

Here's a list of billionaires who had to sell their yachts because they didn't prioritize security over other concerns:

<list not found>

Yeah.

Not going out of business is not the only possible incentive though. Security is a pretty key part of the sales pitch of every cloud provider: "We can do this better than your in-house team" they keep saying.

No one is going to move 100,000 employees off Microsoft over this, but what about signing up the next 100,000? Will it impact next quarter's growth figures?

And for the people directly responsible for security at Microsoft breaches like these may be a career risk or at least a huge embarrassment. There will be meetings. People will get blamed. Some will feel they haven't met their own professional standards.

There's no lack of incentives.

There are debates about risks when large companies move to the cloud - in some industries more than in others. Opposing groups within companies as well as competitors' sales people will be looking for weak spots to make their case.

In isolation, incidents like this don't make a difference. If it looks like a pattern that would be bad for business though.

How has this affected sales over the years?

I believe they won the PC wars years ago and there has never been a good replacement system with enough customer incentive that met the same price point. It is this cow they continue to milk.

I would posit that your first list needs a conditional for “too big to fail”.

Anyone even adjacent to business or finance during COVID could very clearly witness the wealth transfer, and the smaller competitors being swallowed.

Which I think is an important point because by volume the majority of businesses in the US are small and mid-sized businesses.

Well, that's an unintentionally loaded question if I've ever seen one.