TNS
VOXPOP
Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
0%
At work, but not for production apps
0%
I don’t use WebAssembly but expect to when the technology matures
0%
I have no plans to use WebAssembly
0%
No plans and I get mad whenever I see the buzzword
0%
Security

How Developers Can Help Secure the Digital Fortress

Aligning with CISA's seven pillars of zero trust helps the digital estate stand strong in an era of ever-evolving cybersecurity challenges.
Dec 22nd, 2023 8:00am by
Featued image for: How Developers Can Help Secure the Digital Fortress
Featured image by Bernardo Lorena Ponte on Unsplash.

In the days before the internet, background checks were the only things needed to adequately protect an enterprise’s most critical digital assets. Mainframes and their databases resided in dark rooms, and their backup tapes were locked in vaults. The only way data could go missing was if a person walked out with a rather large nine-track tape.

Once the descendants of those machines were connected to each other across the world, enterprises needed to add strong network perimeter defenses to keep the threat actors away from the data. But even then, those on the inside got a pass by being able to access resources and datasets that those on the outside could not. Virtual private networks (VPNs) eroded that distinction by giving outsiders a tunnel to the inside. Insecure third-party open source modules created the need for software composition analysis (SCA) and improved coding practices. In all these transitions, trust was removed from locations, devices and individuals.

Now enter the era of apps everywhere. Enterprises all over the world are shipping software to public app stores that intentionally allow untrusted users to access corporate backend systems. And even though the people using those apps are untrusted, many enterprises trust their apps to make those connections on their behalf. Those apps also contain the required code and protocol implementations needed to access those systems.

One more step completes the puzzle: Threat actors can easily and legitimately download apps published by a given enterprise. They can run those apps in clean environments to observe normal behavior. They can perform static analysis to discover interesting parts of the code. They can also do dynamic analysis to gain an understanding of call chains, parameters, return values, API arguments and differences in network traffic between several identical transactions. And once the threat actors collect enough intelligence, they can begin changing those trusted apps to create derivatives that almost do what the developers intended. This is where zero trust and application security meet.

Enterprises should not blithely trust their own apps because, without sufficient protection, they can easily be weaponized to operate outside the bounds of their initial mandate.

What Is Zero Trust Architecture?

As we navigate the cybersecurity landscape of 2024, zero trust architecture stands as a formidable shield against evolving threats. And the security world has taken notice. There is no shortage of tools or cybersecurity vendors ready to help CISOs make their networks or network architecture “zero trust.” To help make sense of the concept, the Cybersecurity and Infrastructure Security Agency (CISA) has proposed seven pillars of zero trust network access.

While in prior years, developers were not considered the vanguards of secure application design, they can and should contribute to secure applications and, by extension, secure networks. Application hardening, also known as application shielding, will show the way. Developers can strategically employ application hardening, which encompasses code obfuscation, anti-tampering measures, monitoring and runtime application self-protection (RASP), to align with the following seven pillars of zero trust architecture outlined in CISA’s guidance.

Pillar 1: Identity (User ID and Trusted Access)

Who’s at the castle gate?

CISA’s first pillar of zero trust is user identification and trusted access. In the realm of application hardening, code obfuscation is a safeguard for authentication mechanisms. Code can be obfuscated at many different levels, and fortunately, the commercial obfuscation tool market is maturing. Today, developers can apply post-build and pre-test protections, and obfuscations can range from simple string renaming to control flow obfuscation to even more tricky techniques that are proprietary to obfuscation software providers. By obscuring critical parts of the codebase, developers shield the authentication process from prying eyes. Furthermore, the application of white-box cryptography enables the secure transit of credentials — even when the keys are literally in the threat actor’s hands — thus fortifying the user’s entry point into the trusted digital realm.

Pillar 2: Device (Anti-Tampering Techniques, Enabling Device Integrity)

Are they trying to jimmy the lock?

Device integrity is paramount in the zero trust model, and anti-tampering techniques become the bedrock for establishing the trustworthiness of devices requesting access. By employing anti-tampering measures, developers can help ensure that their application runs only on vetted and trusted devices. Commercial tools exist to help developers add anti-tampering measures to their code post-build and pre-test. Look for tools that detect the presence of jailbreaks and roots, as well as emulators and dynamic instrumentation toolkits such as Frida.

Pillar 3: Network and Environment (Granular Control and Trustworthy Communication)

Who knows the secret door knock?

There are two ways application hardening applies in the context of zero trust’s network and environment pillar: First, white-box cryptography provides an extra layer of security beyond SSL to protect data in transit. Second, code obfuscation makes JavaScript and Java in web applications more resistant to reverse engineering, and by extension, code modification.

Pillar 4: Applications and Workload (Shielding the Backend)

Is this castle safe for everyone?

Application hardening is useful for protecting backend systems because applications, by definition, contain blueprints showing how to access servers. Applications that run on the client side, such as in browsers, on mobile devices or on desktops, are thus at risk of being used as threat vectors by reverse engineers. If the code isn’t obfuscated and outfitted with anti-tampering measures, the blueprint can fall right into the eager hands of threat actors.

Pillar 5: Data (Comprehensive Protection through White Box Cryptography)

We’ll let you know the secret door knock when you get there.

Encrypting data at rest and in transit is required. But even that is not good enough if the keys exist in the application. There are several tools that can be used to scan memory for crypto keys. (To frustrate those tools, keys must never be stored as plaintext for extraction and offline use.)

White box cryptography protects keys by changing them into code that can be used for cryptographic operations while never allowing them to appear in memory in their canonical form. Adding obfuscation further frustrates threat actors by obscuring or even damaging and repairing code to make the reverse-engineering process harder by minimizing the time the repaired code exists in memory. Adding anti-tampering techniques also helps by recognizing when applications are running in an unsafe environment or under a dynamic framework where data in use could be collected.

Pillar 6: Visibility and Analytics (Informed Response Through Threat Analytics)

Don’t worry, we’ve got security cameras.

Visibility and analytics form the eyes and ears of zero trust. For developers, this translates into implementing application-based robust threat monitoring solutions. Through application monitoring and RASP reactions, developers provide the means for security operations centers (SOCs) to see and react to threats to applications used outside the security perimeter.

Pillar 7: Automation and Orchestration (RASP and Threat Analytics Integration)

Did someone approve the infantry before it went out?

All the mitigations for supporting the previous pillars come to naught if an organization unknowingly ships an unprotected version of an application because a build engineer disabled protection to debug an issue and forgot to reenable it before release. Adding application protection gates to release-orchestration processes can help ensure that all released applications are protected. Including obfuscation, anti-tampering mechanisms, RASP techniques and monitoring connections to security information and event management (SIEM) tools in the SOC is the best way to make fielded applications as safe as possible and to frustrate, detect and block threat actors.

Conclusion

2024 could be a peak year for zero trust network architecture. And with good reason — enterprise networks have undergone enormous changes, and security architecture must evolve to keep up. In that context, the marriage of zero trust architecture and application hardening is a necessity. Developers, armed with knowledge of code obfuscation, anti-tampering techniques, monitoring and RASP, can become architects of resilience, fortifying backend systems against myriad potential breaches. By aligning with CISA’s seven pillars of zero trust, developers not only enhance security but also contribute to establishing a digital fortress that stands strong in an era of ever-evolving cybersecurity challenges.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.