This document is the fifth in the six-part Technical Manager’s Guide to Zero Trust series, which articulates critical links between zero trust (ZT) and security strategy within each of the six ZT pillars: identity, devices, network, infrastructure, applications, and data.
Zero trust (ZT) is an approach to cybersecurity that aligns organization-wide capabilities around the defense of key assets. ZT is organized around six “pillars” – identity, devices, network, infrastructure, applications, and data. Each pillar’s security team needs to both establish ZT capabilities within their area and work effectively with other pillars to support enterprise-wide ZT strategic objectives.
For managers responsible for delivering applications security within an organization committed to ZT (“ZT applications”), addressing both application-specific and business-wide ZT objectives is a complex endeavor. CISOs will look to ensure that ZT applications approaches fully support organizational objectives, while ZT applications managers will look to use the ZT capability framework to organize and prioritize their investments and activities. The significant challenges faced by ZT applications managers, listed here, complicate the path to addressing these objectives:
These challenges may seem overwhelming, but applications security managers can add significant value to the business by taking an incremental approach to increasing maturity across key areas in support of the ZT strategy. Stratascale SMEs who contributed to this document identified the following key priorities for the applications security manager to add value to the zero trust program:
Addressing the extensive set of key priorities listed above is daunting. How can ZT applications managers obtain support for such a wide-ranging agenda, from the multiple stakeholder constituencies – business executives, DevOps, IT colleagues, peers in other parts of the cybersecurity team, procurement – whose support is critical for success?
In ZT applications discussions, Stratascale SMEs identified a potential avenue for helping to align these diverse stakeholders and objectives: establishing a “living list” of evaluation criteria that identify ZT applications “must haves.” Realistically, this list is applied first and most completely to mission-critical applications and then extended as widely through the corporate portfolio as feasible.
Contributors to this report urged using the “must haves” list to establish an enterprise-wide understanding of both what is needed and why it is important. This requires the ZT applications manager to develop a format accessible and transparent to:
By highlighting the need to address key ZT attributes, ZT applications managers can articulate the ways that zero trust both delivers consistent protection for business-essential software and supports overall organizational security objectives.
In an organization committed to ZT, applications security managers have several ways to create a foundation for action and build momentum for change. ZT applications managers can tie to solutions built in other pillars or collaborate with those teams to create capabilities – such as central identity repositories, continuous authentication and authorization, segmented resource pools, and data classification and protection – that support ZT goals within the applications pillar and across the business.
ZT managers can also use the organization-wide security awareness and visibility that ZT provides to build support for sophisticated application security practices that are beyond the reach of most enterprises today. By aligning ZT applications with continuous protection of applications, their users, and their data, ZT applications managers demonstrate their contribution to business agility and competitiveness.
Each ZT pillar is unique. But even against this backdrop, ZT application security requires special attention. Applications interact with the other pillars in critical ways:
ZT applications managers need to deliver reasonable and consistent answers to these questions, so that needed capabilities are well-understood by security teams focused on other areas.
To further complicate application security, development often occurs within its own silo, using DevOps-specific tooling and processes. Often, developer objectives do not align with fundamental security priorities. Developers focus on rapid delivery of features their business stakeholders need, while security is expected to deliver risk reduction and compliance support.
ZT applications managers are to some extent caught between these “gates wide open!” and “gates locked shut!” approaches. They need to find a way to work effectively with DevOps to achieve both throughput and protection. As one Stratascale SME observed, if security is inserted “into the software development lifecycle, which is what the applications [development] folks use, it becomes a natural part of the development process…if you integrate it into where application development lives, it’s comprehensive and gives you deeper defense.”
Shifting security left provides more rapid and targeted identification of potential vulnerabilities than is possible in a process that relies on handoffs between the AppDev and security groups.
Takeaway: In the words of one contributor to this report, the ZT applications function is focused on “ensuring that the applications are available and secured and that you have visibility into what they're doing.” Because applications are the primary deliverable of the IT function, ZT applications managers need to achieve these objectives using tools and methods that are easily consumed by other security teams, IT staff responsible for delivery of needed components and capabilities, the business staff, and, in many cases, customers.
Interest and investment drivers for ZT applications function at two levels: Security leaders are looking to ensure that the ZT strategy is instantiated within the application pillar, while application security staff are looking to tie into the ZT framework. Because objectives, considerations, and constraints in each area affect the other, organizations need to balance their actions and attention to address both top-down and AppSec-out issues to create a holistic ZT applications approach.
The Stratascale SME discussion of interest and investment drivers zig-zagged across these perspectives, framing a ZT applications approach aligned with each set of requirements.
Highlights from this discussion included:
“AppSec has had a really hard time getting enough traction – enough resources.”
“How do I weave this app into a zero trust story?”
In a ZT framework, applications security teams need to both safeguard software and integrate seamlessly with other pillars to support corporate ZT objectives. CISOs, for example, want an approach in which applications reach through API gateways to other resources, rather than an environment where each app is responsible for its own connections – but they also want to ensure the use of procedures and technologies established within the identity pillar to consistently control access to data secured elsewhere in the ZT framework.
“Security has done a very poor job of enabling developers.”
“Analysis, design, and construct processes often have discrete risk and compliance…”
“Compliance doesn’t really come up in SDLC discussions, but DevSecOps processes do address end-to-end governance.”
“Zero trust has the constructs to break down silos, perimeters, archaic security models…”
During the course of this conversation, ZT applications SMEs raised three issues that do not tie directly to interest and investment drivers, but which may help professionals engaged in ZT applications to articulate additional context to their peers and managers:
Data loss and data manipulation are the key factors that lead to major incidents. Applications will increasingly be seen as a critical threat vector.
Organizations using COTS need to be sure that these applications either fit into the ZT model – embedding either directly or through internal connections features like contextual access – or that they can be retrofitted to comply with ZT applications principles. One example of a retrofit solution mentioned in this discussion was the approach of routing traffic to a COTS application through an API gateway that mitigates risk. Regardless of how the objectives are realized, there is a clear need to establish a unified ZT applications standard across COTS and internally developed software – first with respect to identity, and then expanding to connect with best practices in other ZT pillars.
Takeaway: Interest and investment in ZT applications reflect the AppSec manager’s complex environment. Real-world rollout of zero trust applications security practices requires managers to balance top-down and developer-out considerations, to plot a course that applies meaningfully to both in-house and COTS software, and which recognizes the impact of potential wild card factors like 14028 and cyber insurance. Zero trust isn’t – or shouldn’t be – a complicating factor in forging this approach; rather, it provides principles and support from other areas (such as identity) that help the ZT applications manager improve defenses within the applications pillar and collaborate effectively with peers in other security areas.
The complex mix of ZT applications demands makes it difficult for ZT applications managers to define a priority list that is both meaningfully aligned with all key requirements and manageable in scope. These demands include the need to connect effectively with security practices deployed within other pillars, to implement security measures consistently across internally developed “homegrown” applications and COTS, and to balance application-specific and organization-wide ZT objectives.
Asked for guidance to help ZT applications managers focus on issues that respond to the broad swath of ZT applications considerations and which will result in tangible progress over time, SMEs contributing to this report identified five priorities. Together, these priorities define a practical path managers can use to both organize activity and demonstrate success in addressing these needs.
Start with the low-hanging fruit, then build on the foundation. Improving authentication by establishing a central identity repository and implementing MFA provides “the best bang for your buck” (or the fastest return on effort). ZT applications managers who focus here can “stop building [individual] user stores and identity silos using databases,” moving instead to consolidate identity and authentication into a central control plane.
After having centralized identity and authentication, ZT applications managers can turn their attention to building stronger identity and authentication protection controls.
Build visibility and observability into the ZT applications strategy, and work to continuously enhance capabilities in this area. “The biggest gap in ZT applications today,” one SME stated, “is observability of the posture of different systems on an ongoing basis – infrastructure and network, user and device, and/or the application itself. That visibility and observability is likely missing from the vast majority of organizations.”
Although the terms are linked, the group contributing to this report drew a distinction between visibility and observability. Visibility describes the ability “to see into what's happening: to see into transactions, into data flows, into the data… logging outputs, visualizing through use of dashboards.” This establishes a basis for action. Observability adds to this the ability “to touch something and observe how it changes.” Visibility “is read only – observability means I can change something and see the collateral downstream effects.” One SME couched the distinction in these terms: “You don't understand simply by watching. You have to have a hypothesis, make a change, and see a result...test, learn, understand.”
These capabilities follow one another: You need visibility before moving to observability. This allows the ZT applications manager to define a priority sequence, build the ability to see into applications status and behavior, and then add the ability to test current-state reactions to changing conditions.
Visibility and observability define capabilities fundamental to extending ZT applications across internally developed, SaaS, and legacy systems. Obtaining actionable insight into application status and whether new inputs trigger desired and predictable responses enables the ZT applications manager to manage the entire software portfolio holistically, avoiding inconsistencies that might arise if separate approaches are applied to different application categories.
By capturing a consistent level of relevant intelligence and feedback across the entire application set, ZT applications managers can deliver analysis and recommendations that attach cleanly to ZT objectives, avoiding approaches that miss or overemphasize issues tied to sources or delivery methods.
APM – and the other APM. From a technology perspective, prioritizing visibility and observability as ZT applications objectives will likely require the use of application performance monitoring (APM) tools. These technologies automate the discovery and mapping of application and related dependencies, provide performance monitoring that can flag potential security issues, and support deeper analysis of application behavior.
In the SME discussion on this topic, one expert noted that “the other APM – application portfolio management – will also provide tremendous value” to ZT applications managers. This APM identifies those applications that are most important to the business, enabling ZT applications managers to focus on highest-value systems, and potentially, to take action to reduce exposure tied to redundant or unused applications. Or, per the succinct guidance of one Stratascale SME, to “keep usage data current and get rid of the stuff you don’t need any more via applications rationalization.”
Keep usage data current and get rid of the stuff you don’t need any more via applications rationalization.
Do right by DevOps. Contributors to this report recognized that DevOps poses a unique challenge to ZT applications. Even a relatively advanced developer may struggle to fully support application security processes and requirements (see “roadblocks and challenges,” below). In addition to working with DevOps to integrate ZT applications capabilities into software development practices, ZT applications managers can support developers in several important ways:
Invest in the creation of a “living checklist” that articulates ZT applications priorities to key stakeholders. As noted in this document’s Executive Summary, SMEs believe that a “living list” of clearly articulated must-have ZT application attributes can help diverse stakeholders come to a common understanding of requirements and objectives. ZT applications managers can and should specify requirements that:
The “must-have” list should be applied first and most stringently to mission-critical applications. It should extend as broadly through the application portfolio as is feasible and evolve over time, reflecting changes in both new options enabled by current security capabilities and in corporate goals. ZT applications managers can use this framework to demonstrate progress and to ensure that their strategy aligns with overall security and business objectives.
Takeaway: Most organizations have limited ZT applications capabilities – both within the application security function and in terms of supporting corporate targets across internally developed and COTS systems. Focusing on a limited number of key priorities will help the ZT applications manager to consistently improve the application security posture and stay current with requirements as they evolve.
Each document in the Technical Manager’s Guide to Zero Trust series incorporates a roadmap providing practical guidance to readers looking to implement ZT within their respective areas.
Reflecting the complexity of ZT applications, the advice offered by contributors to this document functions at multiple levels. At a rollout level, the guidance covers four steps defining a sequence that builds overall ZT applications capabilities. At the top of the graphic is a note reminding readers that all controls need to extend into the DevOps environment. At the bottom, a sub-loop illustrates a repeating process aligned with the rollout sequence which should be applied continuously in support of ZT applications objectives.
The business won’t secure anything it doesn’t know it has to secure.
Discussion around this point included observations about how “not everybody is a good steward of change management” and the importance of “finding out where the bodies are buried.” Visibility and observability protect against having applications become attack vectors and provide insight needed in other pillars to secure the enterprise as a whole.
ZT applications managers need to cultivate a deep and effective relationship with DevOps. As one contributor to this report noted, “Getting stuff to work is hard. Is ‘getting it to work securely’ even part of the developer’s mindset?”
This topic is (in the words of another SME) “a real balancing act – and it’s broader than just the IT conversation.” The business needs new capabilities, and developers are evaluated on their ability to meet that need. It’s important to not view security as an impediment to timely rollouts – which means that ZT applications managers must “enable the developers to do their job, not restrict them from doing their jobs… there needs to be alignment across the business on what will help developers to be more effective.”
ZT applications managers need to work with their DevOps counterparts to ensure that controls “shift left” alongside application production and that there is reasonable alignment of expectations, measurement, and incentives across AppDev and security teams.
The process diagram above shows three objectives as part of a continuous loop: automating inventory changes, restricting trust to inputs proven to be safe, and developing context to understand resource requests. The guidance here: ZT applications managers should automate these functions to ensure they are consistent and timely and should improve the functions programmatically over time. Key points in this discussion included:
ZT applications security offers compelling benefits, and the graphic above defines a workable path for technical managers responsible for its execution. However, no strategy is immune to real-world challenges. Where are these most likely to arise on the path to establishing ZT in applications security? Stratascale SMEs contributing to this document identified two impediments that ZT applications managers may need to overcome:
Poor-fit tools create the need for ad hoc, “swivel chair” connections to bridge function and need, which will result in additional work and may create additional vulnerabilities.
Outside of security and IT, a key awareness and culture issue is the acute business management desire to “make the magic happen behind the scenes.” Our SME contributors were sympathetic to this point of view. They understand that business unit managers and staff don’t care nearly as much about security as they do about new release timing and functionality. To participate seamlessly in enabling digital business, ZT applications managers are urged to “make sure that the user experience isn’t a barrier to adoption. Make sure the magic happens on the back end.”
As part of its zero trust research program, the Stratascale team has developed the Stratascale Zero Trust Metrics in Context and Action (Stratascale ZT-MICA) tool, which embeds a robust set of metrics that combine to provide:
Metrics contained within Stratascale ZT-MICA for ZT infrastructure security management include:
Collectively, these measurements help infrastructure security managers to assess readiness and progress over time and to identify and respond to areas of need before they are exploited.
Readers looking for a downloadable version of Stratascale ZT-MICA can follow this link to register for notification of release (form at bottom of the page, available at no cost).
At the end of the research discussion, contributing SMEs were asked to propose recommendations that will help Stratascale client managers succeed in establishing zero trust applications security. These recommendations included:
One characteristic of a unicorn is their ability to both accept and provide perspective in DevSecOps discussions: “Sharing our concerns and our focuses and how can we best leverage all of our collective insight and resources to make the business go” safely and steadily towards ZT.
One participant in this discussion added that, if you look at the need to apply people, process, and technology to IT solutions, “the application is the technology. The other two-thirds of the equation ties to program.” Companies will invest in great technology platforms but install them in an environment that lacks adequate programs, with the result that “they end up just automating a train wreck.”
As part of its Executive Guide to Zero Trust research series, Stratascale published the report, Key Zero Trust Technologies and Management Imperatives. The ZT Applications section of this report highlights the following as technologies that managers should understand as they plot their ZT applications strategies:
The group also discussed user experience as a key factor in ZT applications success, but not as a discrete technology area.
In its “Zero Trust Vendors to Watch, Know, Understand: ZT Applications” series, Stratascale experts reviewed 154 vendors of potential importance to ZT application strategies in the six product-defined areas highlighted above.
Caveats to consider in reviewing the lists below:
Results of these analyses are available in individual reports (linked via the section headers below). Vendors discussed in these reports include:
As with devices and infrastructure, step one in a ZT applications strategy is discovering and classifying the software already within your internal and extended (external) environments. This is a challenging objective, but “there are tools that will fingerprint your network and inventory the apps that are running.”
This inventory provides a basis for implementing ZT applications within a corporate environment, “because if I put new apps up and I don’t know what’s out there and the application is serving data up, how am I going to apply policies and controls to it? How am I going to decide what network zone to put it into? How am I going to know what version it is, or what open source software it has within it, that needs to be patched?”
This is an extension of a concept raised in the identity pillar, but it applies to ZT applications as well. By their nature, software systems access data in ways that are opaque to users – and to many security professionals. Using technology and policies to establish a principle of least privilege (PoLP) for application data access can avert lateral intrusions that start with a compromised application and burrow into sensitive data sources.
Workload monitoring is “where you are going to catch a lot of anomalies. Wait a minute! Suddenly, this application is downloading two terabytes of data and making 3,000 calls.” An unexpected spike in access or connections can be a critical, real-time flag highlighting a compromised application.
The issue of mapping data flows, or the broader constellation of application dependencies, arises in many ZT-focused conversations. If ZT is intended to allow only applications that require specific data to gain access to it, and to allow data access only to authorized applications, the security team needs to have a clear idea of the interdependencies between applications and the data they input or output.
Application data flows and dependency mapping in a major corporation are complex. Large enterprises cannot tackle data flow and dependency mapping manually. They need tools to automate this process, to understand (on a current, continuous basis) and inventory which connections must be permitted, and to enable automated blocking of non-permitted connections.
The basis of trusted connections between applications is “secrets” – credentials that allow applications to connect securely. Seamless connections between applications are critical to supporting business processes that span multiple software systems or functions – which means that an effective, programmatic approach to secrets management is critical to supporting a digital business environment across both COTS and internally developed software.
API traffic represents an enormous subset of total traffic – and an enormous potential vulnerability for businesses that use APIs to connect applications. It is essential to manage API traffic effectively and consistently. As one contributor to this document noted, “You shouldn't be running APIs out of every single application. You should have an API gateway implemented where you're making calls and every app is using the same API call” – and not coding APIs for common applications like Salesforce into every application that feeds into or takes data from the CRM system. An API gateway provides a single point to control API calls across both COTS and internally developed software.
This is the fifth of six documents included in Stratascale’s “Technical Manager’s Guide to Zero Trust” research series. We have also published an eight-part companion series (“The Executive Guide to Zero Trust”) which is available on the Stratascale website.
Readers interested in specific manager-level perspectives on zero trust may wish to explore the other deliverables in this series:
 For more detailed insight into this topic, please see the Stratascale report, “System Observability: Understanding Critical Business Systems to Improve Digital Agility.”
Michael is a world-leading IT industry analyst. He has led North American and global initiatives focused on developing insights and strategies that connect technology solutions with business needs, combining data, knowledge, analysis and advanced content delivery to define options for IT and buy-side businesses.