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.

Executive Summary

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:

• Application sprawl.
• Lack of standards for applications.
• The often-byzantine maze of technology layers that have fermented over time (e.g., different development languages, lost source code, lack of documentation, unsupported operating systems).
• Present-day DevOps teams focused on feature delivery and code releases, often using open-source building blocks which may embed vulnerabilities.
• Out of support commercial off-the-shelf (COTS) applications running on their own infrastructure.
• SaaS applications that morph rapidly and often unpredictably.
• Multi-cloud environments with continually shifting components.

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:

• Implement automated and continuous discovery of applications.
• Continuously rationalize applications to reduce the attack surface.
• Establish ZT standards for applications (e.g., multifactor authentication, support for a central identity repository).
• Automate and shorten feedback loops to “shift left” security in the software development lifecycle (SDLC).
• Provide platform-like shared services to enable applications teams to easily consume services needed to support ZT application standards.
• Build telemetry into continuous assessment and authentication for application identities.

Aligning diverse constituencies through focus on organizational “must haves”

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:

• Business leaders.
• DevOps managers and developers.
• Procurement professionals responsible for sourcing COTS and SaaS applications.
• IT and security staff responsible for the functions that affect/are affected by application security requirements and outcomes.

 

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.

Defining the connections between zero trust and application security

Zero trust in applications is intertwined with all other ZT pillars

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:

• Application access is gated by identity. How does the security strategy align ZT identity with application identity requirements?
• Applications are called via devices. To what degree is security complementary – redundant – or misaligned between ZT devices and ZT applications? What is the best approach to optimizing protection while minimizing user frustration?
• Many organizations consider core applications to be critical intellectual property. How do ZT network and ZT infrastructure principles protect these assets, while also providing the backbone technology that enables the applications to run and be available to users?
• Applications both require and create data. How do ZT applications approaches align with the organizational ZT data strategy – for example, with the need to maintain privacy controls or establish consistent audit trails?

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.

Security at the speed of DevOps

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.

Drivers of ZT interest and investment in DevOps security

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.”

• “You've got a whole bunch of developers that may or may not have had a lot of security training…this is an ideal time to capitalize on growing industry awareness of the importance of pushing security into the SDLC, closer to when we’re developing new applications.”

 

• • The SME noted, though, that major organizations are confused about how to achieve this: “What do we do about this? Where’s the easy button for zero trust?”

“How do I weave this app into a zero trust story?”

• Looking at this topic from the top-down perspective, another SME stated that “there are two sides to this issue: the AppDev side and the applications themselves. Do the applications support a central identity repository? Do they support MFA? Do they support just-in-time provisioning?”

 

• • These questions illustrate how quickly the links between ZT applications and other pillars – especially identity and data – become critical. Security leaders wonder, “How are we granting access to this application, how are we authorizing it, how are we taking signals and telemetry in to make the decision? Does that come from the identity platform, or is the app consuming signals and telemetry from those other pillars, asking ‘What’s your posture? What’s your status? What’s your IP address? What’s your geolocation?’”

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.”

• Several SMEs contributing to this report discussed the difficulties in assigning security responsibility to developers. One said that overall, industry practices are “getting better – we’re still not teaching developers how to code securely, but we’re putting tools in place to help them out.”
  • The SME went on to draw a top-down perspective into the conversation: “We also need to look at what happens when an application is deployed, because whether you’re developing internally or buying off-the-shelf software, you need the ability to understand what’s happening with the user, the application, and the data.” Tools enhance individual developers’ security capabilities, but simply deploying these tools doesn’t fully meet zero trust objectives; ZT applications teams need to deliver (per the previous point) an ability to “weave applications into the ZT story.”

“Analysis, design, and construct processes often have discrete risk and compliance…”

• One SME with management experience in a highly regulated industry spoke about discrete guidelines and objectives within the AppDev team: “Analysis, design, and construct – each one of those processes had its own risk and compliance approaches and requirements. It’s not just ‘get out there and code’ – many criteria have to be met to produce an application.” This creates tension between the tooling that helps accelerate development and the processes that govern its outputs. “You’ve got to consider what the developers want to make their jobs easier, but also, what the managers need to meet risk and compliance criteria.”
  • This SME believes that zero trust plays an important role in building cohesion across the application teams: “ZT gives the rest of the group context to establish ‘Why is security important? Why do we follow these processes? Why do we have to do code reviews and requirement reviews?’ ZT establishes where you fit in the process,” providing common understandings that connect developer and management objectives.

“Compliance doesn’t really come up in SDLC discussions, but DevSecOps processes do address end-to-end governance.”

• In addition to the potential misalignment between developer and management goals and perspectives, it’s important for ZT applications managers to acknowledge that different parts of the organization emphasize different control objectives. The bolded observation above was pulled from a debate about how DevSecOps supports compliance mandates. The quoted SME noted that compliance considerations generally arise as “a function of how the app is classified.” If an application is intended for use in healthcare, to process PCI transactions, or to manage customer data privacy, it will tie into the relevant compliance guidelines, “but compliance isn’t itself a standard topic” in software development lifecycle (SDLC) discussions.
  • The SME went on to note, however, that end-to-end governance is a living issue in SDLC. This expert estimated that a very large proportion of software used in application creation (perhaps as much as 75%) is open source, and as a result, governance is an ongoing point of emphasis. DevOps managers need to ask questions like “How do we understand risk? How do we protect the developers? How do we get a handle on the entire chain from developer desktop to deployment?” in order to provide the capabilities needed to identify and/or remediate vulnerabilities embedded in new code.

“Zero trust has the constructs to break down silos, perimeters, archaic security models…”

• The final point in the Stratascale SME discussion of ZT applications interest and investment drivers illustrated why zero trust is seen as a means of connecting different groups within the AppDev organization and across the IT and security functions. The expert stated that, in their view, “Zero trust is the new security paradigm. We no longer focus on defense in depth – ZT is what organizations are looking to align with.”
  • This SME added that organizations “haven’t fully figured out” how to leverage cross-functional buy-in to zero trust as a means of breaking down silos and moving beyond outdated security models. But, they believed, the change is needed: When corporate information assets, users, and infrastructure are “exposed to the Internet through an ID rather than a hard-coded firewall filter, the security model has to change dramatically.” Zero trust is compelling because it responds to the pervasive threats faced in a de-perimiterized digital world.

Bonus points: Three important factors

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:

• Impact of Executive Order 14028. Executive Order 14028, the “Executive Order on Improving the Nation’s Cybersecurity” issued by President Biden on May 12, 2021, was raised as a possible factor driving application security. The order sets stringent guidelines for suppliers to the US Federal Government, a community that includes virtually every major software and services firm operating in the country. SMEs contributing to this report believe that the order will create a ripple effect resulting in generally more secure software.

• Impact of cyber insurers. The expanding focus of cyber insurers was a second issue raised in the context of this discussion. The general sense here was that while cyber insurers have been focused on infrastructure and data, data loss and data manipulation are the key factors that lead to major incidents, and that applications will increasingly be seen as a critical threat vector.

Data loss and data manipulation are the key factors that lead to major incidents. Applications will increasingly be seen as a critical threat vector.

• Do ZT applications apply to both commercial off-the-shelf software (COTS) and internal development? In a word, yes, though it plays out differently in each area. As noted in the SDLC/DevSecOps observations above, internal developers need to manage the software supply chain and ensure that the applications they build include features like contextual access, device posture, and support for a central identity repository.

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.

Key ZT applications security priorities

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.

• Authorization follows authentication both in a process map and in this priority queue. Once a user has been validated as being a legitimate system user, the next question is, user of what? What resources should the user have access to? Often, authorization is role-based: Users in management, or in a particular department (or non-human users such as an application or device) have access to a class of resources. Controls tied to identity gate the ways that different types of users or resources can access applications or access data through applications.
• Continuous authentication represents the next level of control. In many environments, a user or device is authenticated on entry. But zero trust has a higher validation standard. Users/devices should be continuously monitored using telemetry to identify changes in posture or anomalous activity, and challenged as necessary, to prevent applications from being hijacked in service of malicious objectives.
• Fine-grained authentication, or discretionary access control, represents a step beyond role-based authentication, tying specific permissions to individual user needs and expected posture attributes (rather than assigning resource access to a class of users), and raising alerts if users or devices try to access resources that are outside defined parameters.
• Integration with SOAR (security orchestration, automation, and response) platforms enables ZT applications managers to “ensure sharing of information and appropriate escalation across the ZT framework,” automatically making other pillars aware of emerging threats and receiving inputs that help strengthen application defenses.

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.”[1]

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:

• As a support function, ZT applications staff can streamline identity and access and infrastructure security functions.
  • One important zero trust objective is managing or eliminating “privileged access” – accounts that have extraordinary permissions to data and other resources. Developers often belong to the privileged user class, which means that if, for example, their systems are compromised, the damage can quickly spread across internal applications. Working with DevOps to reduce this “blast radius” by replacing privileged accounts with easier-to-protect access methods is one way ZT applications managers can deliver value to the AppDev team.
  • Similarly, the DevOps team needs to regularly build or access internal systems. If the ZT applications team can provide a secure and consistent path for provisioning new resources, tracking and reporting on their status (still in use/needed?), and incorporating them into a CMDB, developers can spend more time writing software and less managing security administration around needed resources.
• At a process level, ZT components are “pushed into” DevOps by security teams and leadership. At a cultural level, though, the dynamic can and should work the other way. ZT applications managers should work to see that the ZT applications framework is “pulled in” by DevOps, cleanly connecting developers to “the centralized identity solo, MFA, monitoring and reporting, key management systems – the whole process flow.”

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:

• Provide guidance to DevOps teams with respect to needed capabilities.
• Help procurement to establish security criteria for new software acquisitions.
• Demonstrate to security teams how applications connect with actions and priorities in other pillars.
• Enable senior executives to connect specific ZT applications requirements with broader corporate objectives.

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.

Defining the path to ZT applications

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.

Rolling out ZT applications

1. Understand the inventory. Most companies use several different types of applications: those that are documented within a CMDB and support key security functions like SSO; those that are known but do not support core security functions; and those that are used but not documented within the CMDB. The second group will often include legacy applications and possibly new apps either developed without needed capabilities or purchased without supporting those capabilities. In these cases, it’s important for the ZT applications team to identify and address the application’s shortcomings. The “not documented” group is problematic – as one contributor said, “The business won’t secure anything it doesn’t know it has to secure.” It’s important to automate continuous discovery of applications across all environments, particularly SaaS applications, which can move in and out of use rapidly.
2. Define and build a central identity repository. In most parts of IT, “silo” is a bad word, describing situations where assets are kept separate from corporate oversight and management. To counter the danger of rogue identity silos, ZT applications managers need to establish a central identity repository – a single, managed source of identity used universally for authentication. All applications should authenticate through this central resource. This guidance applies to “all identities, human and non-human, employees, customers, third parties, devices, and applications.”
3. Focus on authentication and authorization. At a basic level, zero trust is concerned with protecting key intellectual property assets – including applications and data – and in gating access to them. From this perspective, ZT applications managers have two objectives: to protect applications and to defend against applications being used as a vector to exfiltrate or compromise data, or to enact other attacks. As described earlier in this document, it’s essential that the ZT applications manager establish and then enhance application “user” (again, human and non-human) authentication and authorization by moving to continuous and more granular approaches.
4. Establish visibility and observability. Although we discussed this topic above, it’s worth emphasizing these goals as part of the maturity roadmap for ZT applications. To enable visibility and observability, ZT applications managers need to develop people (by building or hiring needed skills), processes, and technology—they require a combination of the three to achieve success within the application pillar and at an organizational level.

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.[2]

 

Extend all controls into the DevOps environment

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.

Automating continuous controls

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:

• Automate inventory: The goal is to “have the pipeline do the work, not the humans” for all changes, ranging from new COTS to VMs and containers.
• Don’t trust inputs until proven safe: This is an authentication and authorization issue. Who (or what) is making this request, and are they authorized to do so?
• Build context to assess requests: This point builds on the last, drilling down into potential anomalies. An application may be empowered to request resources needed to scale up – but what, specifically, is prompting this request? Is this a real workload? As the graphic implies, success in automating context analysis and flagging potential issues requires the ZT manager to have implemented tools and processes supporting visibility and observability.

ZT applications roadblocks and challenges

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:

• A lack of guidance and support for developers. DevSecOps describes a state in which security and development are tightly coupled through the process of delivering new functionality. In the real world, though, developers may lack needed knowledge. One Stratascale SME with a background in this area observed, “I don't think our computer science courses in academia do a very good job of teaching students to think critically about security, to ask questions like ‘Hey, you’ve got to think of your applications as being compromised. How do you even know that your application is toast?’” In modern organizations, security and DevOps teams operate within their own spheres. The ZT applications professionals need to invest in building a “better together” culture that helps both groups establish and effectively pursue common goals.

• The need to build awareness and culture. Much of the discussion about ZT applications constraints focused on the lack of ZT understanding inside and outside the security function. Within security, this can manifest as a focus on what one Stratascale SME described as “best-of-breed, rather than best-of-integration.” Instead of comparing features across different offerings, ZT applications managers need to ask, “Does this new application fit into my framework for zero trust? Does it connect with the tools I use for visibility and observability? Does it have the capability to integrate into a central identity store? Does it expose APIs so I can do automation and orchestration?”

 

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.”

ZT applications metrics

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:

• Strategic insights to executives.
• Operational perspectives to IT and security management.
• Tactical data to managers responsible for ZT within each of the six pillars.

 

Metrics contained within Stratascale ZT-MICA for ZT infrastructure security management include:

• Number of automated deployments.
• Number of manual deployments.
• Number of vulnerabilities captured via CI/CD automation.
• Number of vulnerabilities discovered outside CI/CD automation.
• Number of open source vulnerabilities.
• Percentage of applications in use that are registered in the corporate CMDB for authorized applications.
• Number of applications integrated into the zero trust program.
• Number of applications not integrated into the zero trust program.
• Percentage of applications leveraging secrets management.
• Percentage of applications utilizing certificates.
• Number of developers using MFA.
• Percentage of applications requiring MFA.

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).

ZT applications recommendations

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:

• Establish, socialize, and regularly refresh the “must haves” checklist. SMEs believe that investing in the development of a living list of ZT applications priorities and ensuring that it provides role-relevant insight to senior executives, IT and security management, DevOps teams, and procurement helps build organization-wide support for the ZT applications agenda.

 

• Highlight the requirement to make progress on “perpetual” issues. One contributor urged ZT applications managers to ask relevant stakeholders, “How many of our top 25 vulnerabilities are the same ones we’ve been fighting for years?” This question, the expert believed, helps underscore the need to embrace ZT applications as a means of moving from a reactive approach that “fights yesterday’s battles, again” to one that establishes a basis for progress on longstanding issues and opens the door to more proactive investments.

 

• Build your unicorn ranks. One group member with a background in DevOps called on ZT applications managers to identify, hire, and retain “that unicorn – the application architect who has the mindset and knowledge to produce secure code – who can bridge security, risk, and DevOps.”

 

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.

 

• Emphasize program over product. “Everyone wants that silver bullet that ‘zero trusts’ their organizations.” And suppliers are continuously looking for ways to position offerings as this type of holistic ZT solution. But ZT “is not a product. It’s not a bunch of products. It’s a program, and a culture.”

 

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.”

 

• Measure and demonstrate success. This guidance isn’t specific to ZT applications, but it does reinforce the “must haves” checklist that leads off these recommendations. Senior executives, internal IT and security leaders, DevOps teams, and procurement will be more receptive to the messages around the checklist if the ZT applications manager can link them to tangible improvements in the organization’s ability to rapidly deliver secure code, extend defenses to COTS applications, and defend against threats to data confidentiality and system integrity.

Important ZT applications technologies and suppliers

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:

• Application inventory.
• Least privilege access to data.
• Application workload monitoring.
• Application data flow/dependency mapping.
• Secrets management.
• API gateways.

 

The group also discussed user experience as a key factor in ZT applications success, but not as a discrete technology area.

Vendors active in the ZT applications space

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:

• In each area, we only included vendors if they were both familiar to our team of experts from our work with clients and considered relevant to the category and to zero trust applications strategy.
• Reviewers also drew a distinction between vendors who are broadly applicable in the enterprise environments that Stratascale addresses (generally, Fortune 1000 businesses) and those which are relevant in specific niches, but not across all potential enterprise use cases.
• As a default in this document and others in the Technical Manager’s Guide to Zero Trust series, we listed firms which have been acquired under their original names, with notes in the profiles included in the linked documents indicating the acquiring company. This gives readers a chance to see the aggregation of specific capabilities via acquisition.

Results of these analyses are available in individual reports (linked via the section headers below). Vendors discussed in these reports include:

Application inventory

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?”

Vendors that should be considered by buyers looking to build or enhance enterprise ZT application inventory capabilities, listed in alphabetical order:

• Cisco.
• Palo Alto Networks.
• ServiceNow.

Vendors that address specific ZT application inventory requirements and may fit specific needs, but which don't apply to a full spectrum of enterprise ZT application inventory use cases:

• Adaptive Shield.
• AppOmni.
• Bitglass.
• Grip Security.
• Skybox Security.
• Trellix.
• Zscaler.

 

Click here to access the Zero Trust Vendors to Watch, Know, Understand: ZT Applications – Application Inventory report.

Least privilege access to data

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.

Vendors that should be considered by buyers looking to build or enhance enterprise ZT least privilege access to data capabilities, listed in alphabetical order:

• Amazon Web Services (AWS).
• CyberArk.
• FileFlex Enterprise.
• Forcepoint.
• IBM.
• Immuta.
• Imperva.
• Microsoft.
• Mimecast.
• Netskope.
• Netwrix.
• Ping Identity.
• SailPoint.
• Saviynt.
• STEALTHbits Technologies.
• Varonis.

Vendors that address specific ZT applications least privilege access to data requirements and may fit specific needs, but which don't apply to a full spectrum of enterprise ZT least privilege access to data use cases:

• Styra.
• Zscaler.

 

Click here to access the Zero Trust Vendors to Watch, Know, Understand: ZT Applications – Least Privilege Access to Data report.

Application workload monitoring

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.

Vendors that should be considered by buyers looking to build or enhance enterprise ZT application workload monitoring, listed in alphabetical order:

• Aqua Security.
• Sysdig.

Vendors that address specific ZT application workload monitoring requirements and may fit specific needs, but which don't apply to a full spectrum of enterprise ZT application workload monitoring use cases:

• Data Theorem.
• Oak9.
• Rafay Systems.

 

Click here to access the Zero Trust Vendors to Watch, Know, Understand: ZT Applications – Application Workload Monitoring report.

Application data flow mapping and dependency mapping

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.

Vendors that should be considered by buyers looking to build or enhance enterprise ZT application data flow and dependency mapping, listed in alphabetical order:

• Amazon Web Services (AWS).
• Microsoft.
• Sysdig.
• Virsec.

Vendors that address specific ZT application workload monitoring requirements and may fit specific needs, but which don’t address a full spectrum of enterprise ZT application data flow and dependency mapping use cases:

• GuardiCore.
• Illumio.
• TrueFort.

 

Click here to access the Zero Trust Vendors to Watch, Know, Understand: ZT Applications – Application Data Flow Mapping and Dependency Mapping report.

Secrets management

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.

Vendors that should be considered by buyers looking to build or enhance enterprise ZT secrets management, listed in alphabetical order:

• Akeyless.
• Amazon Web Services (AWS).
• CyberArk.
• Google.
• HashiCorp.
• Knox.
• Microsoft.
• SecretHub.

Vendors that address specific ZT secrets management requirements and may fit specific needs, but which don't address a full spectrum of enterprise secrets management use cases:

• Doppler.

 

Click here to access the Zero Trust Vendors to Watch, Know, Understand: ZT Applications – Secrets Management report.

API gateway

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.

Vendors that should be considered by buyers looking to build or enhance enterprise ZT API gateway capabilities, listed in alphabetical order:

• 42Crunch.
• Cequence Security.
• Salt Security.
• StackHawk.
• Traceable Inc.

 

Click here to access the Zero Trust Vendors to Watch, Know, Understand: ZT Applications – API Gateway report.

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:

• The Technical Manager’s Guide to Zero Trust: Identity.
• The Technical Manager’s Guide to Zero Trust: Devices.
• The Technical Manager’s Guide to Zero Trust: Network.
• The Technical Manager’s Guide to Zero Trust: Infrastructure.
• The Technical Manager’s Guide to Zero Trust: Applications.
• The Technical Manager’s Guide to Zero Trust: Data.
• The Technical Manager’s Guide to Zero Trust: Understanding ZT Pillars (ebook consolidating all reports).
• Stratascale Zero Trust Metrics in Context and Action tool (Stratascale ZT-MICA) (downloadable tool – no cost, registration required).

 

 

---

[1] For more detailed insight into this topic, please see the Stratascale report, “System Observability: Understanding Critical Business Systems to Improve Digital Agility.”

[2] For more insight into this issue, please refer to Clear the Fog with Application Dependency Mapping.