Importance of Securing Software with a Zero Trust Mindset

By Shinesa Cambric, Microsoft

This article is part of a series showcasing learnings from the Secure Software Summit.

Photo by Morgane Perraud on Unsplash

With the increase of supply chain attacks on everything from logging software like Log4J to takeovers of important JavaScript packages to compromises of network utility tools like SolarWinds, more and more organizations are recognizing the need to adopt a Zero Trust mindset. Zero Trust can improve security, reduce risks, and give organizations greater confidence in the integrity of their IT infrastructure and applications. To correctly set up a Zero Trust architecture, you need to understand what it actually takes to make systems Zero Trust.

Zero Trust Definition and Guiding Principles

Due to the rise of interest in Zero Trust, many misconceptions have built up that bear correcting.

• Zero Trust is not a product or tool. In fact, there is no single tool you can apply to an environment to configure a full-stack Zero Trust implementation. Rather, Zero Trust is more about creating and refining an architecture and applying a consistent mindset.
• Zero Trust is a never-ending journey. It is not a destination. You are never done and finished setting up Zero Trust, because software applications and IT environments continuously evolve. As your environment evolves, part of applying Zero Trust is going back and reassessing everything you are doing on a regular basis to ensure it complies with the principles of Zero Trust and covers all your software and technology assets.
• Zero Trust does not mean your environment cannot be hacked or breached. On the contrary, under Zero Trust you constantly assume your environment has been breached. Zero Trust emphasizes building defensive layers that reduce the potential impact of any hack or breach and protect your assets and data.

So then what is Zero Trust?

Zero Trust is a framework and approach to security that assumes an organization’s IT assets — software, networks, data — are constantly at risk and must be secured through continuous verification of the identity, and the application of “least privilege” principles against any identity — human or machine — operating inside the IT environment. The core of Zero Trust is the lack of inherent trust for any identity as a managing approach to building more resilient applications and segmented risk.

Zero Trust has several key guiding principles:

1. Verify all identities all the time using a strong form of authentication  — not just username and password. Specifically, use strong forms of authentication, such as multi-factor authentication. This principle applies not only to human users but also to all devices, bots, services, APIs, and partner systems accessing your environments. They must be verified every time they seek access and continuously while they are active inside your environment.
2. Always assume your environment has been breached. From this starting point, design your systems to reduce the blast radius and protect your assets as if an attacker is continuously present and moving within your environment to perform malicious acts — data exfiltration, system takeover, or other forms of abuse.
3. Always enforce least privilege for everyone and everything operating in your environment. Least privilege means limiting access only to systems, applications, data and services required for each task or interaction. To properly apply least privilege requires an understanding of expected behavior for applications and services, what they should and should not be doing, and also creating a sense of context. Applying least privilege with context is also dependent on assessing the security posture of any device, service, application, API or identity seeking access. Your Zero Trust policy enforcement engines should always interrogate inbound and ongoing connections to understand where an identity is coming from, what it is trying to connect to, and what is the current security posture of that identity. The answers to these questions should inform and shape least privilege permissions and provide additional insight into the risk of providing access.
4. Segment your environment to limit horizontal traversals or pass-through attacks. This is closely related to least privilege. The bottom line is, do not award any identities carte blanche access to your network, applications data, or infrastructure. Only allow identities access to the portions they truly need to perform their task, and only while they are performing that task.

How to Use Zero Trust to Secure Your Software and Software Supply Chain

The conceptual language of Zero Trust makes it sounds like an identity architecture and network security approach, floating above developers. For building and deploying secure applications, developers and DevOps teams must also adopt a Zero Trust mindset. In fact, there are clear synergies between Zero Trust and application security — and particularly with regard to Open Source Software (OSS). OSS developers may not spend sufficient time and energy on securing their code, because it is not what they like about writing software. For this reason, if you are including OSS code (and nested OSS libraries) in your applications and environments, then you have even more reason to apply Zero Trust frameworks.

A useful framing is to think about Zero Trust as applicable from the inside out, from the outside in, and to everything in between linking internal and external, applications and APIs, code and integration/deployment pipelines, and partner environments. Properly executed, Zero Trust allows your developers to go faster but also be safer. Additionally, it is useful to view Zero Trust through the CIA (Confidentiality, Integrity, Availability) lens. You should design your Zero Trust architecture to deliver these elements in priority that map to your business needs and there are a few ways to implement Zero Trust principles to the software supply chain.

Assume Your Code Has Been Breached And Is Insecure

Conduct a software asset inventory, looking at and categorizing all code running in your environment. This makes it easier for you to identify unauthorized changes and build more resilient applications. Set up mechanisms to detect unauthorized changes or anomalous software behaviors. You may want to apply these guidelines to close partners and their software and supply chain, as well. Remember that attacks may be from you, through you, or at you.

Manage Identities Carefully

Analyze and categorize user entitlements to set a baseline for “least privilege”. Conduct an inventory of all identities active in your environment to identify known identities (and quickly recognize unknown identities). Set up mechanisms to analyze behavior of identities to spot anomalies and create a baseline for context and behavioral privilege and access policy decisions. Include partner identities in this inventory: your greatest risk may come from unsecure partners that attackers use to gain access to your environment. The inventory should also include service and admin accounts. The inclination is to set their privileges and forget about them, often awarding broad access so as not to slow them down, and also potentially providing an unmonitored backdoor to attackers.

Inventory + Lock Down Integrations

Inventory your external and internal supply chain. This includes all dependencies in the code, services called, APIs exposed or accessed, and tooling for developing, hosting, integrating and building applications. For example, you may want to analyze your CI/CD pipeline and deployment environments through the lens of segmentation and least privilege to limit access depending on the pipeline stage. Put in place measures to segment the software environment and prevent lateral movement, like application sandboxing (but make sure to also tightly secure your sandboxes).

Code Assessment

Developers need to apply threat models to their code and adopt the mindset of considering what an attacker might access and what they might do should they compromise an application or the surrounding supply chain. Obviously, for all code — and especially OSS code — developers will need to continuously look for vulnerabilities and scan code using tools like Static Code Analysis and Dynamic Application Security Testing. Zero Trust means continuous verification of your own code, not just the entities using the code.

Zero Trust Takeaways

As we continue towards a future of more complex and integrated application environments and more usage of OSS code for core application functionality, the Zero Trust future becomes Zero Trust forever. It will simply become a way of life in application development. That said, we should keep in mind four key guiding principles.

Know Your Current State  — Be aware of where your environment stands and your security posture, and direct and indirect impacts of security vulnerabilities.

Assume Breach  — Be able to identify anomalous behavior and continuously consider what could be done by an attacker if your app was used maliciously?

Assess  — Continuously assess the status and changes in the environment. Ask questions like: Who has what, when and where? Where do your integrated partners and vendors stand in terms of security?

Continuous Improvement  — Periodically assess and compare your Zero Trust efforts against desired security posture and make improvements that align with objectives around confidentiality, integrity, and availability. Constantly guard against risk.

These four principles map over to five key takeaways that any developer, application security team, DevSecOps team or platform team can apply today and forever.

• Review your environment with a Zero Trust lens
• Recertify all identities continuously
• Establish baseline app and identity behavior
• Focus on detection and prevention of attacks
• Design applications for resilience

Following these guiding principles and basic framings will ensure your Zero Trust journey creates strong defenses that help protect your development supply chain from the outside in, inside out, and with integrated partners.

To view this and other recorded sessions from the Secure Software Summit, visit: https://www.techstrongevents.com/Secure-Software-Summit.

To get a demo of static analysis of custom code, open-source dependencies, and secrets, visit shiftleft.io/request-demo/.

---