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.<\/p>\n
However, one bad actor attempted to access Workday from a company-issued endpoint. The attacker harvested the intended victim\u2019s 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.<\/strong><\/p>\n 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.<\/p>\n The catch? Because numerous software vendors widely used Apache Log4j for more than 20 years, many organizations didn\u2019t 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 \u2014 requiring security analysts to remain on the lookout for the Log4Shell bug.<\/p>\n 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.<\/strong><\/p>\n Like identity and endpoint security, adopting a Zero-Trust approach<\/a> to apps requires new thinking. Zero-Trust app protection is a shift from asking, \u201cCan a user access this app?\u201d to asking, \u201cCan a user access this app from this particular location or endpoint?\u201d<\/p>\n 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.<\/strong> The conditional access to the endpoint kept them out.<\/p>\n 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.<\/p>\n Fortunately, while a damage attack like the Log4Shell bug is difficult to repair once it\u2019s 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.<\/p>\n Symantec, Forcepoint, Cisco and Netskope are some common CASBs to look for when comparing offerings. But if you are a Microsoft 365<\/a> (M365) shop with an M365 E5 license, you already have access to Microsoft\u2019s<\/a> most advanced Enterprise Mobility and Security (EMS) tool, EMS E5.<\/p>\nApp Protection in the Grand Scheme of Zero-Trust Architecture<\/h2>\n
How to Protect Your Apps<\/h2>\n
![\"Zero-Trust](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2022\/07\/Blog_EC_ZeroTrust_07_18_22-300x230.png\")
<\/a><\/p>\n