Is Microsoft Repeating Mistakes with Azure Security?

An image of an executive learning the old adage that the definition of insanity is repeating the same mistake over and over
Insanity defined: making the same mistake over and over once you know better

I’m a Microsoft fanboy.

For the last decade, my consulting practice has centered on helping large enterprises and governments migrate to Azure. I own the stock. I am a true believer.

But as the adage says, insanity is making the same mistake over and over once you know better. Unfortunately, Microsoft appears to keep slipping on banana peels as the push to compete with AWS and Google Cloud Platform grows more intense.

I get it: Microsoft has obligations to its shareholders, employees and, frankly, customers to be as profitable as it can be. But it also has an increasingly heavy responsibility to secure customers’ infrastructure in the cloud.

Let’s rewind to the summer of 2023 when Microsoft revealed that Microsoft 365 had been penetrated by the threat actor Storm-0558 which, shockingly, used consumer Microsoft Accounts to forge access keys that could be used in what was then called Azure Active Directory (today, Entra ID) to obtain access to mailboxes hosted by Exchange Online. Unlike competitors, Microsoft 365 and Azure are tightly coupled to the identity system in Entra ID. You can’t use either Microsoft 365 or Azure without Entra ID; the former are completely dependent on Entra ID for access control. That’s both a blessing and a curse.

If you are a CISO, CTO, security analyst, infrastructure architect, work in the SOC or are an enterprise security professional, you owe it to your career to read the Cyber Safety Review Board’s post-mortem of the Storm-558 intrustion. It reads like a murder mystery.

There are some truly shocking revelations in the report. First, Microsoft really doesn’t know and to this day cannot explain how Storm-0558 got the consumer signing key that precipitated the disaster. More to the point: it was only through logging that the State Department discovered anomalies that eventually revealed the intrusion.

The report states:

[The] State Department was the first entity to detect the intrusion when on June 16, 2023, a State SOC analyst observed multiple alerts…Detecting an intrusion like this is difficult; State Department found Storm-0558 because it had purchased enhanced logging through the G5 licenses…

So, at that time only government departments that were paying extra were potentially able to discover the intrusion. To dispel the unfortunate optics, Microsoft expanded logging in Microsoft Purview to all government users.

As Steve Gibson is fond of pointing out, enterprise IT must develop a “culture of logging” to have a hope of securing its infrastructure. He and I agree that literally everything should be logged. Thus, logging isn’t an option or a profit center. It’s a fundamental part of a cloud service or resource. Reading logs is not only a fantastic way to learn what’s going on with a cloud resource, it’s the only way to do any forensics.

That’s because in Azure and other public cloud systems, all you have are logs. You don’t get to touch any hardware. Your entire infrastructure exists solely as definitions in the cloud provider. Your only peek into that cloud provider is via logging. (An aside: think of the scope of logging in cloud-scale log systems. These, along with the billing systems that charge for every API call and microsecond, are my nominees for the biggest applications ever developed. They’re run at mind-blowing scale.)

So, that brings us to a recent disappointment of mine: Microsoft continues to bury important logging features in extra-cost products when they should be included. And I suspect they are doing it to increase revenue at the cost of security and, ultimately, customer trust.

Case in point: Entra ID Conditional Access and Workload Identities.

Conditional Access is the logic capability applied to access control in Azure and Microsoft 365: it’s the feature that allows enterprises to make a decision about the location or quality of an attempted login.

But you can only use the decision-making capabilities of Conditional Access if you pay for it via Entra ID P1. This means you could have a Microsoft 365 or Azure infrastructure (which come with Entra ID “Free”) in which, anytime a user presents valid credentials, they’re in. Worse, you won’t get the logs that are associated with failures — denials — of the Conditional Access policy restrictions because you can’t make conditional decisions at login time.

Here’s an example of a simple Conditional Access policy at work and the output log entry. This shows that a user was denied login from a specific IP address. Conditional Access policies can be customized to address a large number of conditions. But what’s most important is that the result of the policy is logged and can be examined.

A log entry from Entra ID Conditional Access
A log entry from Entra ID Conditional Access

It’s terrible that Conditional Access isn’t included in every Microsoft 365 and/or Azure tenant. Without Conditional Access, there are no Conditional Access logs and therefore no real way to determine which end user logins would have violated your policy. But that’s not all…

If you want to apply logic to your applications — as opposed to users — in Azure and log those access attempts, you have to buy yet another feature on top of Entra ID P1: Workload Identity. Here’s the description from Microsoft:

A workload identity is an identity you assign to a software workload (such as an application, service, script, or container) to authenticate and access other services and resources.

IOW, anything but an interactive user login costs more to log using Conditional Access. When you consider the potential security risk inherent in compromise of your internal applications — the resources closest to your data, your enterprise’s crown jewels — the price gauging by Microsoft is breathtaking. Practically speaking, you have to license Entra ID P1 per seat, then add workload identities on to that cost. And it ain’t cheap. Each Workload ID is $3/month. I’ve worked for banking clients with thousands of applications, each of which would require a separate ID.

As recently as this month, Pro Publica has excoriated Microsoft for hooking the government on security features and then charging them for them. IMHO, some of the accusations Pro Publica makes sound like sour grapes from former salespeople — who may or may not be technically competent to comment on the actual capabilities the government was using. And some of what Pro Public alleges is, let’s face it, standard sales practice. Still, I’d rather the federal government procures technology from a US-based company rather than a company which might cost less but whose business culture is less responsive to the US government.

The bottom line is that it’s quite clear that Microsoft, despite the Storm-0558 maelstrom and the fallout from that experience, hasn’t changed its ways. Microsoft people like to talk about “learnings” — an idiom unique to that company. The need to understand two important “learnings”: every things needs to be logged. And customers shouldn’t have to pay to obtain those logs. (Charging to store logs is, of course, fine. Nobody expects storage for free.)

The question is, will Microsoft accept the learning that profiting from logging is not worth the risk to its users and ultimately reputational damage to Microsoft itself?


Posted

in

by

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *