Data theft and shadow IT present an international threat. In addition to locking down online identities and endpoints, you must also secure your apps to build a true Zero-Trust architecture.
In previous posts in this series, I described how tools like multi-factor authorization (MFA) secure data by safeguarding online identities and endpoints. In this post, I will look a little deeper into how these tools can also function at the app level. In other words, even if bad actors steal an identity or breach a device, they can’t access sensitive data if you’ve protected the apps.
For example, we recently set up Microsoft Defender for Cloud Apps (MDCA, formerly MCAS) for a client. MDCA conditional application logic allowed users to access Workday from company-issued endpoints to download their paycheck stubs.
However, one bad actor attempted to access Workday from a company-issued endpoint. The attacker harvested the intended victim’s device sign-on and password from the dark web, giving them access to the device. Fortunately, our client had also enabled MDCA. When the hacker tried to access Workday, MDCA recognized the request was coming from an unusual geographic location and put up an additional MFA requirement that denied them access to Workday.
But app attacks can be much more complicated and harder to defend against. Most IT professionals are now familiar with the Log4Shell bug, which began wreaking havoc throughout the public and private sectors toward the end of 2021. The bug attacked Apache Log4j, a common Java-based utility many vendors use within their applications to log system activity.
The catch? Because numerous software vendors widely used Apache Log4j for more than 20 years, many organizations didn’t know they were vulnerable to its attack. The result? Bad actors broke in and executed remote code that reached into organizations worldwide. While companies have since deployed tools to identify exposed Apache Log4j systems, hackers continue to look for other places where vulnerabilities exist — requiring security analysts to remain on the lookout for the Log4Shell bug.
As we helped our client do successfully with the attempted Workday attack, vendors could have protected Apache Log4j from the Log4Shell bug with conditional access requirements based simply on where the attack originated. An additional layer of protection would have kept attackers out.
App Protection in the Grand Scheme of Zero-Trust Architecture
Like identity and endpoint security, adopting a Zero-Trust approach to apps requires new thinking. Zero-Trust app protection is a shift from asking, “Can a user access this app?” to asking, “Can a user access this app from this particular location or endpoint?”
Thinking more about our MDCA experience, recall how the bad actor found a user’s endpoint credentials on the dark web. If not for MFA, they would have been able to get into Workday and retrieve data or execute malicious code. The conditional access to the endpoint kept them out.
Similarly, MFA or a different conditional access tool would have intervened as soon as bad actors launched their attack on Apache Log4j. That simple tool would have prevented the chain of events that allowed them to insert Java Naming and Directory Interface (JNDI) code into the vulnerable server housing Apache Log4j.
How to Protect Your Apps
Fortunately, while a damage attack like the Log4Shell bug is difficult to repair once it’s done, numerous tools are available to help with app protection. Known collectively as cloud access security brokers (CASBs), they stand between apps in the cloud and app users to enforce your policies regarding everything from credential mapping to tokenization, encryption, device profiling and more.
Symantec, Forcepoint, Cisco and Netskope are some common CASBs to look for when comparing offerings. But if you are a Microsoft 365 (M365) shop with an M365 E5 license, you already have access to Microsoft’s most advanced Enterprise Mobility and Security (EMS) tool, EMS E5.
Otherwise, Microsoft customers can add EMS E5 to their existing license. Below I have listed various Microsoft subscriptions and the necessary add-on to request, depending on your M365 license type.
Conclusion
Online identity, endpoint and application security work together to deliver a comprehensive approach to Zero-Trust architecture. They protect against attacks that use individual credentials, vulnerable devices — remote or not — and the apps that live on those devices.
The next evolution of Zero-Trust thinking requires going beyond the resources people very personally interact with every day to the bigger digital assets and systems that usually hum along quietly in the background — your company’s data, infrastructure and network. Those will be the topics of my next three blogs. Until then, stay alert and stay safe!