Free DownloadEnterprise cybersecurity: A strategic guide for CISOs
Effective enterprise cybersecurity has become even more important as organizations extend their efforts in digital transformation, cloud computing, hybrid work and AI technologies. CISOs and others responsible for safeguarding an organization's systems, networks and data need to manage day-to-day threats while also planning strategically for what's ahead. This comprehensive guide to enterprise cybersecurity explains what's at stake and how CISOs and other security leaders can spend wisely and effectively to meet the many challenges that cybersecurity teams face.
What is cybersecurity mesh? Key applications and benefits
Is it time to consider a different approach to security architecture? Cybersecurity mesh might be an effective way to address complex, distributed environments.
Most security programs are extremely complicated. They're using multiple cloud providers, an array of different cloud services, across IaaS, SaaS and PaaS cloud models.
Environments can be exceedingly complex. Even just one individual application might span multiple cloud service models from multiple providers. As an example, consider a service-based application that does the following:
Fastly handles static delivery and edge logic compute.
API integration with Salesforce.
Connects to a business partner API hosted in Fly.io.
Uses identity services from Okta (Auth0).
This is not an unrealistic scenario. But consider how many different service providers and models are baked into it. There are no less than seven cloud services and/or providers; it encompasses all three standard cloud models, CDN and edge computing, and spans multiple levels of the application stack.
Even so, this example is significantly lesscomplex than many actual applications in the field. Not included are tools such as Rollbar and LogRocket for recording application behavior, engagement tracking tools such as Meta Pixel, tag management tools such as Google Tag Manager, support integrations such as Intercom, Zendesk, and consent management tools such as OneTrust. Plus, there might be dozens -- or in some cases even hundreds -- of CI/CD, staging, test and integration environments.
The point is, technology ecosystems have become fragmented, decentralized and decoupled. At the same time, new developments have come along. The adoption of service mesh in Kubernetes-native architectures, for example, represents a further decoupling of security and routing. Increasingly ephemeral environments and assets sharply increase the number of identities. We've also seen a significant evolution as a result of AI integration into applications themselves and the way they're built.
Securing anything under these conditions strains the security architectures of yesteryear. We need new approaches that can work with the inherent complexity and tie together the various services and platforms. This is where cybersecurity mesh comes into play.
Cybersecurity mesh promises to decentralize control in three key ways:
Decouple policy enforcement from infrastructure.
Enable granular access control across distributed assets.
Modularize security services into a continuous fabric that integrates visibility, identity, assurance and analytics.
What is cybersecurity mesh?
Like the zero trust security model, cybersecurity mesh architecture (CSMA) is best thought of as an architectural approach or design philosophy rather than a specific technology, market segment or capability. In other words, it's not a product -- despite numerous vendors attempting to sell it that way.
The analogy to zero trust is useful. Recall that zero trust is fundamentally about shifting your mindset so that you presuppose that network environments, including corporate networks, data centers, virtual private clouds and so on, are compromised and potentially hostile. This is a simplification, of course, but notice how this single shift in mindset drives a host of architectural and design changes: ubiquitous transmission security, strong user and machine-to-machine authentication, microsegmentation, adaptive access policies and so on. The central premise -- that the network is untrustworthy -- implicitly and logically demands that we adapt the architecture.
CSMA is similar in this respect, but with a starting assumption that environments are fundamentally disparate and heterogeneous, that assets are logically and physically separated, and that implementations of core services such as authentication and audit are disconnected from each other.
It logically follows from this well-justified assumption that security controls need to adapt. You can't assume every environment and system will secure communications the same way, report events in the same format, enforce identity equivalently and so on.
Gartner defines cybersecurity mesh as "a collaborative ecosystem of tools and controls to secure a modern, distributed enterprise. It builds on a strategy of integrating composable, distributed security tools by centralizing the data and control plane to achieve more effective collaboration between tools. Outcomes include enhanced capabilities for detection, more efficient responses, consistent policy, posture and playbook management, and more adaptive and granular access control -- all of which lead to better security."
Key components of cybersecurity mesh
Cybersecurity mesh can be thought of as an orchestration layer tying together several layers of functionality:
Security analytics and telemetry.
Identity (both machine and user identity).
Policy management.
Consolidation of reporting.
To understand the benefits of approaching things this way, consider how you would enforce a single security policy or deploy a uniform control across multiple service provider implementations. You would need to translate the objective from the policy to the different configurations, APIs, administration interfaces, enforcement primitives within each of the services for the assets in scope.
As an example, consider cryptographic key management. Storing a secret in Microsoft's Azure Key Vault is different from doing so in AWS CloudHSM and Google Cloud Key Management; each has its own API, administration interface and security model. But while each service is different at the technical and implementation level, using those services can achieve the same goal of managing cloud keys and secrets.
The value then promised by cybersecurity mesh is to consolidate policy and posture management by translating abstract policy objectives, such as key management, into specific technical configurations to enforce them. In this key management example, teams could decide to log all cryptographic key accesses. They might require keys to have a certain length or expiration period.
This same philosophy extends to reporting. To monitor assets from a security perspective -- be it metrics, measurement, reporting or analysis -- there needs to be a way to collect and consolidate that information and tie it together with information about assets and threats. Since assets report differently based on device type, environment, configuration and other factors, some scaffolding is required to unite them so that telemetry can be analyzed holistically.
Lastly, identity needs to span environments. Would it be acceptable if users or customers had to reauthenticate to an application if different elements of the application live in different PaaS or IaaS environments? Of course not. By its nature, the identity fabric needs to cover multiple environments.
Benefits of cybersecurity mesh for businesses
Security practitioners can purchase any number of products that help accomplish the foundational layers of CSMA. Likewise, organizations have for years been aligning their strategies to decouple policy from enforcement, to eliminate silos in their security stack, and to adapt to an increasingly porous and fragmented perimeter. They've done so because of the risks associated with the work-from-anywhere shift, the proliferation of multi-cloud use, increased application complexity and more modular applications.
When looked at from a long-term perspective, CSMA aids a successful enterprise cybersecurity program in three important ways:
Philosophical shifts. Market influences drive real-life architectures, which further alters product roadmaps to service customer demand. Think about zero trust. It dates back to the mid-1990s, but it didn't become popular until it was espoused by Google (BeyondCorp) in 2009 and Forrester Research in 2010. New companies and technology vendors formed around the concept, driving innovation and new features within existing vendor product portfolios. The same is true here. Those practitioners who find the model compelling can be on the lookout for products that help achieve the vision.
Industry acceptance. Acceptance of CSMA as a viable architectural strategy can potentially simplify architectural discussions around multi-cloud, hybrid cloud, orchestration and containerization security. With a focus on how complex cloud interrelationships are, practitioners can plan accordingly.
Awareness and acceptance of heterogeneity. This accelerates interoperability. As more abstract policies are tied to specific configurations, capabilities converge around generally accepted policy goals. Customers will begin to ask service providers why they lack certain capabilities. The more we synchronize monitoring information from various providers, the more we can integrate them into a central picture. This can also alleviate worries about vendor lock-in.
Real-world applications of cybersecurity mesh
So, what does a cybersecurity mesh approach look like in production? Because the starting point is a change in viewpoint -- i.e., an acceptance of variance, decentralization and heterogeneity -- it really means accounting for those things in your design philosophy and adopting them as foundational premises.
If you follow a formalized architectural methodology such as TOGAF or SABSA, this means including the support for these ideas at the foundational level and throughout most planning phases (i.e., phases A through D of TOGAF ADM; and contextual, conceptual and logical views in SABSA). If you use a more ad hoc process, it means that you plan around and account for these things from project inception, through business requirements definition and ultimately to your technical requirements. They are baked in as fundamental assumptions.
As a way to illustrate this, let's look at a hypothetical situation.
Say you are working in a large, multinational organization with a multi-cloud environment. For policy enforcement, you would want to normalize policy definition and decouple policy definition from enforcement and/or implementation. To support this, you might use multi-cloud tools, which could be a commercial product such as Wiz or an open source option such as Open Policy Agent. You might put time into normalizing access management with, for example, role definitions, identity naming standards and such -- even if the specific enforcement mechanisms differ in each cloud environment. You might integrate real-time telemetry and log information to a central SIEM and SOC workflow, potentially making use of a cloud-based SIEM, such as Microsoft Sentinel or Google Security Operations, formerly Chronicle, to assist with detection and response.
Specific use cases will dictate how you interpret and apply these assumptions.
Considerations and challenges of implementing cybersecurity mesh
What's advantageous about the philosophical and architectural shift to cybersecurity mesh is that there are many ways to put it into practice. And because these options are not tied to any particular technology or implementation, the technical challenges aren't as big a factor as they might be in other projects.
That said, be aware of two potential pitfalls with cybersecurity mesh.
First, be careful with legacy environments and architectures. Just because you're leaning into an assumption of distributed policy enforcement, that doesn't change assumptions made in the past. Legacy assets might depend heavily on environment-supplied services; they might assume the presence of supporting systems and controls such as domain authentication services and on-premises log aggregators. Set realistic expectations about what might be required to bring legacy assets and applications in line with the assumptions you're putting in place.
A second concern is how vendors market cybersecurity mesh. While vendors are updating their product portfolios with CSMA goals in mind – and this can be tremendously helpful -- recall that cybersecurity mesh is not a product category in the same way that SIEM, vulnerability scanners or code-scanning tools are. If a vendor describes a product as cybersecurity mesh-ready, scrutinize this claim. Be sure you understand what that really means. Those explanations will likely be different from one case to the next, so be sure to include this in your vendor selection process.
Cybersecurity mesh vs. zero trust: Do they fit?
Practical questions also arise in the relationship between zero trust and cybersecurity mesh. Are they in opposition, or are they in alignment? Does one eclipse the other? Can both be used at once?
Cybersecurity mesh seeks to decouple policy definition from localized policy enforcement. To do that, a security team needs to place policy enforcement points as close as possible to the asset that the policy governs.
Zero trust and cybersecurity mesh are fundamentally about paradigm shifts in how we view security architecture. The former assumes all environments are untrustworthy; the latter assumes assets are distributed. Not only are these assumptions not in opposition, they're synergistic.
The disparate and non-homogeneous environments where we field assets can absolutely be viewed as fundamentally untrustworthy. This is, in fact, an astute and practical assumption to make when considering a shared-tenancy environment such as a public cloud provider.
Cybersecurity mesh seeks to decouple policy definition from localized policy enforcement. To do that, a security team needs to place policy enforcement points as close as possible to the asset that the policy governs -- either as part of the asset or in its direct orbit. This is a core tenet of zero trust, too, given that environments, and, by extension, some environmental shared services, are less trusted. Again, this helps CSMA and zero trust to reinforce each other's precepts.
A potential complication relates specifically to how vendors use the cybersecurity mesh and zero trust terms. Both concepts have been well received by the marketplace, and they form the backbone of several products. Still, there's always potential for conflicting operations at an individual product level. For example, a zero-trust oriented control, such as a gateway, might block access due to a strict identity check; another product, such as a CSMA-aligned integrated policy engine, might have already assessed the same session as low-risk based on contextual signals. In some situations, this could lead to conflicting decisions unless policies are well-aligned. As always, being clear about requirements is crucial when making any technology purchase.
The future of cybersecurity mesh
So, where do we go from here? Distributed assets are used in various environments with varying security control implementations, and this reality isn't about to change. In fact, this is likely to become more pronounced as organizations continue to embrace container orchestration, implement infrastructure as code and employ ephemeral assets. Therefore, the fundamental assumptions of CSMA are likely to hold.
As these ideas become more generally accepted, they're likely to become less noteworthy. We won't view them as a different or altered conceptual framework. It might take time, but, like zero trust, cybersecurity mesh will become the architectural approach that most organizations embrace as enterprise cybersecurity evolves. In the short term, it reflects a practical and useful way for organizations to plan their security stack.
Ed Moyle is a technical writer with more than 25 years of experience in information security. He is a partner at SecurityCurve, a consulting, research and education company.