Zero Trust - Application Security

This will be Part 3 of my series of articles on Zero Trust. Applications perhaps receive the least amount of attention when it comes to implementing Zero Trust. The level of trust given to applications is often surprising considering the rate at which vulnerabilities are being discovered (yes, title quote is from The Matrix). The tendency is to protect the device, network and the data and assume applications will automatically be protected within this sandwich of security. However, as some high profile cyberattacks and vulnerabilities (SUNBURST, LOG4SHELL , coa NPM package to name a few ) have demonstrated, defense-in-depth needs to apply to the Application perimeter as well. This may be obvious for tech and software development companies, but holds true for other industries as well. Especially as non-software development organizations start adopting “citizen development” and “DevOps” in-house to solve business problems.

Applications are often trusted from the source. They may be from a known vendor or an open-source community like Apache. History has demonstrated the fallacy of trust. Let’s take a look at one of the most high-profile cyber attacks in the recent times.

Solar Winds — Bring Your Own Vulnerability

When the news of Solar Wind compromise broke, it shook the world of cybersecurity. Dubbed SUNBURST backdoor hack highly motivated and targeted attack was the harbinger of doom for supply chain security. The details of the compromise can be found in several blogs and articles, though probably none as in-depth as the blog from Crowdstrike. A few other deeply technical reads that are worth diving into are from Qualys, Mandiant and Microsoft.

While a lot of the analysis deals with the post-mortem and detection and remediation of breach, the real concern may be a little earlier in the kill-chain of the attack. The threat actors injected a vulnerability into the Orion platform. This was not just some bad coding practices or lack of “secure-by-design” that the attackers exploited in the Orion software. It was the implicit “trust” in the software build pipeline itself that they exploited and leveraged to deliver malware to customers of Solar Winds. They brought their own vulnerability to the party.

The vulnerability was not evident in the Orion Platform products’ source code but appears to have been inserted during the Orion software build process. — Solar Winds blog post

This demonstrates that attackers can (and have) breached trusted code repositories, and can inject themselves into the code build pipelines to introduce vulnerabilities that can be deployed at scale. Undetected malware and proprietary protocols that are provided as part of a trusted vendors software end up whitelisted in customers’ environments. From there, the threat attackers can branch out their supply chain attack ( Unauthorized use of Fireye’s Red Team Tools ) or breach the target customer’s network.

It turns the concepts of secure code, code-signing certificates and other such measures on its head. SUNBURST impacted the largest IT service providers, led to a cascade of breaches , the impact of which will take years to come out or just remain unknown. It is telling that Solar Winds did not detect the compromise until FireEye notified them. And while details are scarce of how FireEye detected their own breach, it appears to have been an indirect detection if not accidental. To assume that Solar Winds is the only vendor targeted and compromised by such a sophisticated attack is foolhardy.

The key learnings from Solar Winds for Zero Trust in Applications development can be summarized as

• Secure your code and software build environments
• Explicitly verify software builds at each stage of the pipeline (Eg: Solar Winds now decompiles each build to compare the decompiled code to the original source code)
• Have a rapid patch testing and deployment plan in place

Stop trusting Application runtimes

Securing the application development and build cycle is one aspect. What about the final product. Is it now safe to execute in a trusted context? Probably not. Defense-in-depth tells us to add an effective layer of defense during runtime as well.

Developments in the security space for applications has enabled the ability to put in controls at the Application runtime. Modern browsers can now sandbox processes so as to only expose CPU and Memory.

Windows now feature ASR (Attack Surface Reduction) that has rules that can block spawning of child processes that are high risk or indicative of malware. And *nix OS always had security built in to ensure processes run within a non-privileged context (a common security feature that is sadly bypassed often to move projects along). In the Infrastructure space, cloud providers are providing controls such as Azure’s Adaptive Application Control to prevent unauthorized processes from executing on a server workload.

Wrapping it up

To wrap it up, Applications need to be treated with the same Zero Trust approach that’s applied to networks or devices. Application security controls can be applied at

• Code compile and software build
• Application execution

During application development, code integrity needs to be checked at every step of the software build pipeline. During application execution, the process needs to be given access to only those resources it needs and within a protected context. And for Host OS, it is necessary to know which applications are allowed execution and within which context, especially when it applies to a server workload. In each control, we must ask the standard ZT questions:

• Can the process be verified explicitly?
• Is the application running with the least privilege?
• If we assume breach of the application, what’s the detonation radius?