• Back


Beware: Redmond’s Risky Assumptions

Let’s imagine for a second that a company sold you a fire-proof safe that you used to store your important personal papers and effects. And let’s imagine that it became clear, over time, that this very popular fire-proof safe was good for organizing stuff, but something of a joke in terms of security. Burglars, you learned, could simply hold a magnet up to the door and spring the lock. Let’s also imagine that - because these safes were really, really common - burglars were bringing magnets with them and springing safes all the time. Houses up and down your street were getting broken into and their safes emptied.

Now let’s imagine that the fire-proof safe company came to you and said ‘Look, these break-ins are a real problem. Your home safe won’t cut it. Fortunately, we have a new, centralized storage facility. We’re telling our customers to move to that!’ Would you take that offer? After all, this is a company whose product you know well and have trusted for a long time. You note also: the safe works pretty well, at least mechanically. It's just not very good at keeping your belongings secure. On the other hand, recent experience tells you that this company may not be as good at safe-making as you were led to believe. What to do?

Deal or No Deal?

I’m putting this question to you because, right now, tens of thousands of enterprise customers of Microsoft are weighing an offer that bears a striking resemblance to this hypothetical. The “fire proof safe” in this case is Microsoft’s Active Directory Services platform. The home owners: organizations that, for two decades, built their enterprise networks and their security assumptions on a foundation of Active Directory and the Kerberos authentication protocol. (Kerberos itself being a massive improvement over NTLM authentication - which is still enabled on far too many networks.)

Of course, AD is more than just a “safe” for user and computer identities. It’s called Directory Services for a reason.  It’s a handy map to both users and IT assets, a security policy enforcement service, a lightweight entitlements repository, a configuration management database and more. In short: it is the beating heart of enterprise environments: the final arbiter of who- and what is allowed to operate within the environment, and what they are able to do.

Inching Away

Now, after more than 20 years, Microsoft has begun telling customers, in a roundabout way, that its core enterprise identity infrastructure may not be up to snuff. It may, if the cloud marketing is to be believed, be un-securable. Salvation, according to Microsoft, can be found in the cloud. Specifically: its Azure cloud and Azure AD platform. In December, Microsoft released updated guidance as part of its "Privileged Access Strategy" series for customers. Ostensibly about methods for securing privileged access to Windows network resources, buried within it was a head-slapper: Microsoft was retiring the Enhanced Security Admin Environment (ESAE) architecture, often referred to as “red forest,” “admin forest,” or “hardened forest.” The problem? Prior to that announcement, red forest was Microsoft’s recommended architecture for securing Active Directory from large-scale attacks, such as those from ransomware actors.

In its place, Microsoft recommended to on-premises AD customers a series of "best practices" including use of multi-factor authentication, creating Privileged Access Workstations (PAWs) to constrain access paths and following “Zero Trust” concepts wherever possible. The company leans heavily on Azure Active Directory as a corrective for ESAE’s failings, recommending customers migrate on premises identities to their cloud and make Azure AD the “master directory” for their organization.

As QOMPLX’s CISO Andy Jaquith noted at the time, the message was clear: “on-premise is declared to be an anti-pattern, replaced by many more belts, a closetful of suspenders, and an embrace of the Microsoft cloud, which requires the costly E5 enterprise license.”  

Indeed, Microsoft still uses the Red Forest architecture construct internally - but thinks you should just hire them since it’s too hard for most companies to execute.  Here is the screen capture from Redmond’s own documentation:

Microsoft statement indicating that the company continues to use Red Forest architecture internally.

Emptore de nubibus cave!

When we get asked about this at QOMPLX, our answer to our customers is a variation on the often-used latin phrase caveat emptor (“let the buyer beware”). Maybe “emptore de nubibus cave” (“let the buyer of clouds beware”)! Here’s why.

The information security community appears to have coalesced on “Zero Trust Networks” as the fix for endemic problems like sophisticated hacks, data theft and crippling ransomware. We have observed that “Zero Trust” is still a concept devoid of a clear definition and open to almost limitless interpretation. That’s bound to be the source of a lot of ongoing confusion for enterprise buyers.

We heartily endorse the move towards identity-centric security, but reject the overly simplistic treatment of the combined people, process, technology and data requirements glossed over by Microsoft and other ravenous prognosticators. What is clear is that entitlements rule everything within modern, hybrid IT environments. The historic “perimeter” defined by firewalls and a DMZ is, today, simply the sum of your users, applications, APIs and their reach both within your environment and out to third parties. That’s why attackers, sophisticated and otherwise, turn their attention to owning privileged accounts almost immediately upon gaining access to a target environment.

To achieve zero trust, organizations first have to shore up that foundation of users and entitlements. The question is: does Microsoft’s very “Redmond-centric” view of Zero Trust offer a way to do that? We are not the only ones to have well founded doubts.

Risky Assumptions

We think that Microsoft’s view of “Zero Trust,” which echoes in the recent CISA guidelines, makes questionable assumptions that organizations should be aware of. First: Microsoft’s vision for a secure, Zero Trust future simply moves risk from on-premises, self-managed Microsoft infrastructure to cloud-based Microsoft (or at least third party) infrastructure.  In our view is that such a move doesn’t reduce risk. Rather, it concentrates it on infrastructure that your organization doesn’t control.  

Outsourcing your identity provider doesn’t mean that you can’t suffer the same kinds of attacks on protocols like NTLM, Kerberos or SAML - it just means that reduced visibility and lack of protocol validation from any of these providers will likely allow attackers to silently evade notice.

That brings us to our second point: while Microsoft’s security is certainly better than average, they didn’t manage to detect any part of Solar Winds even in their own network. True, the company - unlike too many enterprises - is not an easy target. But it is a big target with rich rewards for success. Top notch security talent on staff doesn’t mean that Azure is impregnable. In fact, we already know that Microsoft itself has been the target of both cyber criminal and nation-state adversaries. It was among the victims of the SolarWinds hack, in which attackers reportedly had access to source code for some of the company’s products. Given the growing value of the massive Azure AD infrastructure as organizations and government agencies consolidate on it, we can presume that it will be a top target of sophisticated nation state actors, who have a myriad of tools at their disposal including planting malicious operators within Microsoft itself. The risk there is high - but so is the reward. That’s why it is almost certain to happen, if it hasn’t already.

For organizations wholly dependent on Microsoft and Azure AD, an outage due to a cyber attack, cloud infrastructure failure, natural disaster or other unpredictable event would be catastrophic. There would be no “RESET KRBTGT" available, nor could you ferry an employee off to a far flung office to retrieve an AD backup or offline domain controller. In a best case situation, Azure AD never goes down. In a more realistic scenario, it does experience periodic outages, but Microsoft is able to gracefully recover and interruptions for Azure AD customers are minor. However, the worst case scenario for Azure AD customers really would be bleak - far more so than the worst case scenario in an attack on on-premises AD.  On premises AD instances had to be compromised one org at a time, Azure AD will look more like the 2014 OPM breach (also involving Active Directory) where millions of classified personnel records were pilfered - what a treasure.

Zero Trust But Verify

That’s why QOMPLX backs an approach that we call “Zero Trust, but Verify.” Rather than falling back on the promises of cloud identity providers and outsourcing security (and risk) to them, we advocate an approach to “zero trust” that puts your organization in control of its identity infrastructure, while improving both threat detection and incident response.

QOMPLX’s approach to achieving Zero Trust doesn’t do away with on premises identity infrastructure - most organizations realistically need a hybrid architecture. Instead, we emphasize good security basics like robust patch and configuration management and the use of multi-factor authentication to prevent easy account takeovers. We work with firms to shore up their existing protections, including  endpoint detection and response (EDR) and the application of strategies like user “least privilege,” and network segmentation to frustrate lateral movement and privilege escalation.  Most importantly, we also note that you have to actually look at the entire authentication protocol exchanges that enable authentication.  Remember Azure AD is almost entirely Kerberos-based, just like on premises AD.  Kerberos and SAML protocol validation are foundational parts of having trust in your Zero Trust architecture.

Behind the scenes, QOMPLX’s technology monitors your organization from the inside and the outside: matching knowledge of your security posture with threat intelligence and threat monitoring to focus your detection and prevention efforts. We pay particular attention to your Active Directory and Kerberos infrastructure, monitoring for a variety of Kerberos Ticket and SAML forgeries and other credential forgeries and theft attacks. Our products map trust relationships between databases, file servers, legacy IT infrastructure and extended enterprise/cloud assets as well.

That way, QOMPLX’s technologies minimize the “blast radius” of an intrusion by giving defenders deep visibility into privilege- and authentication events in their network that may indicate an emerging attack or compromise. QOMPLX’s team has secured some of the largest Active Directory implementations in the world and works with both private sector firms and the U.S. government.

If you want to learn more about how QOMPLX can help you address sophisticated cyber threats such as human-directed ransomware and secure both on-premises and cloud-based identity infrastructure, request a meeting with QOMPLX or use the form below to contact us!

More Posts

Card image cap
Attack surface risk signals: DNS records

Published Oct 14, 2021

Card image cap
Identify and Fight the Phish #CyberMonth

Published Oct 12, 2021

Card image cap
Offensive Security Service Data Sheet

Published Sep 28, 2021

Card image cap
Offensive Security Service Tech Spec

Published Sep 28, 2021