CrowdStrike Falcon® Identity Threat Protection Added to GovCloud-1 to Help Meet Government Mandates for Identity Security and Zero Trust

• If users can authenticate against Azure AD, Okta, Ping or on-premises Active Directory, how do our customers secure all of those authentication points?

   

• How do our customers provide the same level of security for on-premises authentication (e.g., Kerberos, NTLM) as they do for cloud authentication that can enforce MFA? This includes service accounts, which are often ignored.
• How do we apply MFA on things, such as remote PowerShell, that leverage non-interactive logon — and why is that such a big deal?

   

• How do our customers ensure that, if they detect suspicious activity in one of those authorization points or see the identity be compromised, all of the other identity providers are made aware and modify how they treat that respective account?

   

• How do our customers segment highly privileged accounts so they can only be exposed to not just specific machines, but to machines that are assessed continuously for device hygiene?

   

Left unaddressed, these scenarios can cause blind spots that can lead to the activity seen in the SUNBURST attack, where the attacker predominantly compromised on-premises credentials, in many cases bypassing MFA to take over entire cloud infrastructures — and leading to devastating consequences. We will explore each of these questions in subsequent blogs and explain how they are addressed by Falcon Identity Threat Protection. But first, let’s view the bigger picture in this blog.

The U.S. Department of Defense’s Seven Pillars of Zero Trust

Following the issuance of the EO, the federal government has been actively developing reference architectures to guide implementation of its mandates. For example, the National Institute of Standards and Technology (NIST) released SP 800-207, which discusses various Zero Trust Architecture (ZTA) policy enforcement and policy decision points and has effectively become the foundation for other reference architectures. In addition, the National Security Agency (NSA) released a Zero Trust Maturity Model to help identify the various maturity levels of implementing Zero Trust.

The U.S. Department of Defense (DoD) released its Zero Trust reference architecture, which differs from the NIST and NSA architectures in that it discusses common Zero Trust use cases across seven “pillars”: User; Device; Network/Environment; Application and Workload; Data; Visibility and Analytics; and Automation and Orchestration (see Figure 1). We will examine how identity protection plays a role in each pillar of this particular architecture.

Figure 1. The DoD’s Seven Pillars of Zero Trust (Click to enlarge)

It is commonly believed that identity affects only one of the pillars described in this architecture, that of the user. In reality, identity applies to all seven pillars as follows:

• User. Each user has an identity, which typically exists in multiple places (e.g., on devices, in Active Directory, in the cloud). It’s important to remember that a user can normally authenticate at multiple places, whether on premises or to cloud services or another identity provider.
• Device. Devices not only have their own identities, but they are exposed to the identities and other credentials of users that access them. As a result, if a device is compromised, the credentials on that device are also exposed as long as the adversary has access to it.
• Network/Environment. Network devices typically are accessible by service accounts having appropriate privileges. If service accounts are ignored in a defense posture — similar to what happened in the SUNBURST attack — blind spots are created that could lead to significant breaches.
• Application and Workload. Applications and workloads depend on users being authenticated to give them respective privileges — and with the continuous integration/continuous development (CI/CD) that modern applications have today to enable DevOps and DevSecOps practices, if an identity token is compromised that has privileges to push code to a CI/CD pipeline, it could be possible for an adversary to make production-level changes.
• Data. To be fully protected, data must be more than cataloged and tagged appropriately. Users must be able to authenticate appropriately for authorized access to such data. Not only that, data protection can also include only enabling certain applications to access that data, and when implemented, should be executed at the process level. And for processes to be trusted, the operating system and device itself must also be trusted to some degree.
• Visibility and Analytics. Visibility and analytics are used to assess identity across all of these pillars, looking for anomalous activity. In addition, users who wish to access this data also must be able to authenticate at some level, thus requiring identity protection for data access at this layer.
• Automation and Orchestration. Automation and orchestration helps defenders use, proactively if possible, the learned visibility and analytics via API webhooks — API webhooks which require authentication tokens, mapped to an identity, giving it the right permissions to execute. A compromise against one of those tokens can have a devastating impact in an environment.

Through the lens of the DoD’s Seven Pillars of Zero Trust, let’s consider two scenarios that include multiple decision and enforcement points and how and where Falcon Identity Threat Protection fits in. The first shows user authentication against an on-premises resource, leveraging “legacy” authentication protocols, while the second focuses on authentication against a cloud resource, or at minimum a resource behind a cloud-based identity provider. (We will dive deeper into some of these concepts in subsequent blogs, showing, for example, how CrowdStrike secures “legacy” authentication protocols.)

Zero Trust for an On-Premises Resource

Figure 2 depicts a user-access flow of a device accessing an on-premises resource, using CrowdStrike technology.

Figure 2. Falcon Identity Threat Protection helps continuously monitor and secure identity, including for legacy authentication protocols such as NTLM and Kerberos, without ever touching the application (Click to enlarge)

In the example shown in Figure 2, the Falcon platform’s endpoint protection helps create a device hygiene score called the “Zero Trust Assessment” score. When a user from a protected device attempts to authenticate or access another system, that authentication continues to occur against on-premises Active Directory as usual. However, Falcon Identity Threat Protection can detect against discrete attacks (e.g., Pass-the-Hash, Overpass-the-Hash, Forged PAC, Golden Ticket) and also measure against the learned baseline of that credential’s normal activity while also assigning a risk score to the credential. That risk score can potentially modify how the credential can successfully authenticate and potentially enforce MFA — all before the user is allowed to authenticate.

Just with the device hygiene score and user-risk score, Falcon Identity Threat Protection solves two of the biggest problems with MFA: It usually has no context of the device itself, and MFA usually isn’t possible for on-premises authentication and certainly is never possible with non-interactive logons (e.g., remote PowerShell, Windows Management Instrumentation).

Zero Trust for the Cloud

Figure 3 depicts a user-access flow example, this time with a device gaining access to a cloud resource.

Figure 3. CrowdStrike Falcon®’s endpoint protection helps secure and measure the device. The device hygiene is shared across vendors, including the SASE vendor and the identity provider — in this case, Okta. If this was targeting an on-premises resource, CrowdStrike Falcon® Identity Threat Protection can also tailor the workflow for on-premises, at authentication time. (Click to enlarge)

Very similar to the authentication flow of on-premises resources, the authentication flow to a cloud resource provides the ability to have context of the device and the user’s risk score throughout multiple parts of the architecture. The SASE vendor can use the Zero Trust Assessment score from CrowdStrike to see if the device is managed and if it has the right level of trust. It can then pass the authentication flow to the identity provider, in this case Okta, which can also leverage the Zero Trust Assessment score for its decision making. However, the identity provider can also integrate with Falcon Identity Threat Protection in cases where risky on-premises users can result in different behavior or policy in the cloud; for example, perhaps you want users who are acting anonymously to be forced to use MFA when they attempt to access a cloud resource. Falcon Identity Threat Protection can do that, integrating with Microsoft Active Directory, Microsoft Active Directory Federation Services (AD FS), Okta, PingFederate and many other identity services. This solves one of the biggest challenges of securing the cloud: The cloud identity provider is traditionally open to the internet. By placing a SASE in front of the identity provider, and by ensuring the SASE vendor is made aware of the source computer’s device hygiene, we can drastically lower the exposure of our identity provider — no more external brute force attacks. Falcon Identity Threat Protection also solves the big issue of identity providers in the cloud possibly having no idea what is happening on premises. Do we have evidence that the user was compromised on premises, and therefore we should disable authentication or force MFA when they next attempt to access a resource? Thanks to Falcon Identity Threat Protection’s integration with cloud identity providers, this is no longer an issue. In addition, user activity can be seen across multiple identity planes, such as Azure Active Directory (Azure AD). This helps secure the account and enables the execution of a timely incident response investigation.

Conclusion

Thanks to Falcon Identity Threat Protection being available in GovCloud-1, this is available to our federal customers and Defense Industrial Base (DIB) customers. Sharing context across multiple parts of the Computer Network Defense (CND) is important to enable many of these use cases. Gone are the days when we assumed we had limited visibility of our own on-premises identity planes. Gone are the days when we didn’t fuse users' activity across multiple identity providers where that user exists. Through Falcon Identity Threat Protection we can detect identity-based attacks, measure their respective risk score, and measure all-up identity hygiene, while being aware of other factors in our decision logic such as source and destination of the device and so forth. In the following weeks, more blogs will drill into a lot of this content, doubling down on why it's important from a risk and threat perspective.

Additional Resources

• Read the press release.
• Learn more about CrowdStrike Falcon® Identity Threat Protection.
• Discover CrowdStrike solutions for the public sector.
• Read about how CrowdStrike secures significant Impact Level 4 (IL-4) authorization to protect critical U.S. Department of Defense assets.
• Find out how CrowdStrike solutions map to the White House Executive Order.
• Get a full-featured free trial of CrowdStrike Falcon® Prevent™ and learn how true next-gen AV performs against today’s most sophisticated threats.