There are few buzz phrases in IT risk and security today with as much clout as “Zero Trust” and “Digital Twins”. Both represent significant departures from legacy practices that comprise much of the planning, design, and activity of current IT risk and security programs for many organizations, large and small alike. In a past posting about the US Governments’ efforts to ramp cyber security, implementing a zero trust approach was a noted priority. Many articles and comments by interviewees online and in the media have mentioned it too. So, what’s a zero trust approach look like? Can you purchase it? Implement it easily, without risking bankruptcy? And what about digital twins? Are they involved? What are they? Where do they fit into this buzz-laden recipe? Let’s unpack some of this, demystify the names, and see where we can find some value.
Finding Zero Trust
When most of us designed and build our “enterprise” networks, regardless of their size and complexity, most shared a common philosophy—secure the boundaries and access through them, and all that’s inside can then communicate freely. This is often referred to as a “castle and moat” approach. It made sense in a world of emerging technical scope and sophistication. It presumed that only people with a want or business “need to know” would seek entrance, and if they did and it were granted, they’d make use of the resources needed to conduct their business and be done. It also meant that security was relatively easy to administer, limited only to access from without. For people who worked within the boundaries, all that was necessary was authentication to the network, except for a few designated resources whose management required additional authorization. Changes to the “innards” didn’t otherwise require adjustments to anyone’s internal security; adding devices or resources, such as a printer, a server, or a data store, didn’t require additional authentication or entitlement. We all lived largely that way for some time. But times changed. The internet happened. Remote working happened. Extended boundaries created by logistics, international commerce, third party partnerships and providers happened. Electronic payments, banking, and transactions happened. And grew in volume, ease of execution, and value. And then, of course, the malicious actors followed. We needed something better. The “moat” was too big, too thin, and too oddly shaped—it constantly changed. And the castle wasn’t one asset, but many; each offering an entryway to others of equal value. The secure wall became porous.
Zero trust is a completely different approach. In it each asset requires its own permissions and authentication, it “trusts no one” simply because it’s asked, or because you’re present. Perimeter boundaries are still in place, but within them each and every asset, service, or resource requires proof you have been granted rights to be there. So now security needs to be layered, specific, and discrete. Role based approaches are an administrative method to simplifying administration to such an environment. But there’s more. There needs to be the means to enable all devices to challenge access and reject the unauthorized. Further, access to devices itself may be layered to enable access but not to change data, to print but not to alter configuration of a printer, and so on. You can see where this is going. And, in a zero trust environment, every device, every asset must require such authentication and permission vetting. And of course, there needs to be the tools to effectively manage such an environment. The intent is to slow down and minimize the damage a malicious actor might create through gaining entrance through the perimeter boundary. It’s not perfect, but it’s a step forward. But it’s not easy to migrate from one approach to the other.
Migration To Explicit Vs Implicit Trust
Some pundits offer that the only path forward is wholesale teardowns and reconstruction of the enterprise. Sorry, I reject that approach as unrealistic for almost any size business. Zero trust requires users prove they require access. For example, this could mean logging into a corporate account with a hardware security key or some other authentication method in addition to a username and password combination to make it harder for attackers to impersonate users. And even if someone passes the perimeter, access from there is on a need-to-know or need-to-access basis. So, if you don’t invoice clients or customers as part of your job, your enterprise account shouldn’t allow your access to the billing systems. In some firms such access is already restricted with respect to sensitive assets such as client data, billing, etc. In a zero trust scenario, your needs-to-access-permissions must specifically incorporate everything.
Zero trust is an approach to security. It’s a way of doing things, not a product, nor an end result. Despite what some vendors may state, there are no specific “zero trust” boxed products for you to purchase that deliver zero trust upon opening and installing. You still must implement things like device and software inventories, segmented networks, and role based access controls. You still need to replace default credentials that ship with hardware. Access must still be managed and change management practices need to be followed with rigor. You evolve your infrastructure and operation to an increasingly zero trust environment as you make changes, as you grow, as your business matures. Like the human body, you don’t wipe out the circulatory system or replace your muscular structure at once. You alter eating and exercise habits and improve them over time, building one advance upon another, based upon following an approach to health. You need to function while you change. You cannot take a break from existence and service to completely recast how you do business all at once. It’s neither practical, reasonable, nor likely affordable.
Now, a word about complexity. If your “enterprise” is composed of many different companies, each operating with relative independence, but connected through some kind of spoke and hub consolidation to a corporate entity, you may have some additional complexity and opportunity. The complexity comes from the need for creating some standard approach to doing like things common throughout each enterprise entity. This is often a human, behavioral and emotional rather than a technological problem to solve. There are no pat easy resolutions, but value in each success. The path for one will suggest a means for the next. Further, you can experiment with changes in entity discreet before extending them to others. This supports a phased introduction of zero trust, through stages of “lesser trust” to “almost no trust”.
Zero Building Blocks
Great, more buzz phrases! This one’s mine (sorry). When you add something new to your operation, a process, asset, or method, try to embrace a zero trust means from the outset. This allows you to create building blocks of zero trust compliance incrementally, ones that are reusable and can be integrated easily to existing systems, yet also to other such “zero trust building block” or “zero blocks” for short. It’s a way of avoiding rework as you progress towards a fully zero trust operating environment. Migrating some aspect of your operation to a cloud service? Great opportunity to build it out as an encapsulated zero block, or assembly of zero blocks. And, as you extend or expand it, create additional discreet zero blocks, creating a set of zero trust components you can reapply as you need them going forward.
Thought: Considering a new GRC tool? Make its implementation a zero trust instance. It can then become a zero trust building block you can apply as you extend its scope or expand the platform’s feature/module set wherever used in your enterprise.
And Then There Were Digital Twins
Digital Twins is a catchy new name on a concept somewhat older. A digital twin is a virtual replication of a real world asset or resource, such as a machine, or a process, like a supply chain, or a facility, like a factory, even like a complex device such as a car. Virtualization of hardware has been an established practice for a while. Today’s cloud technologies offer the ability to virtualize whole processes, assets, and data stores. This gives you a test environment to model threats, attacks, and the effectiveness of responses. You can even model in the current state of your environment, leveraging recent risk assessment, remediation, and vulnerability data from your GRC. This can be particularly valid if your risk data is integrated with those from audits, incidents, and regulatory findings—yet one more item to list in the reasons to invest in a GRC platform if you do not already have one. Creating digital twins of key resources and assets in your enterprise would enable your cyber risk and security staff to mimic the behavior of malicious actors and determine the risks and associated vulnerabilities of business processes. Simulations will enhance your understanding of your cyber readiness, letting you modify the complexity of the cyberattack surface based upon your own threat modeling or experience in your industry. They are usually designed to function from use cases. If you have third party suppliers or service partners critical to executing your business model, you could create digital twins for each and explore the impact of attacks or even disaster losses of service. This is a further extension of third party risk management (TPRM), one that would work best if based upon comprehensive data from a robust TPRM process and supporting software, integrated into your GRC, if present.
Many, if not most environments are far from homogenous, and the diversity of platforms and processes, particularly in complex extended environments, can be a problem for digital twin developers. The Object Management Group’s Digital Twin Consortium is working with standards groups including ISO and IEC to help create consistent vocabularies, architectures and security for digital twin development. They describe themselves as “…a global ecosystem comprising industry, government, and academia. It was founded to accelerate the development, adoption, interoperability, and security of digital twins and enabling technologies.”
Integrating Zero Trust and Digital Twins With Your GRC’s Help
Migrating your philosophy of security from a “moat and castle” to a “trust nothing” approach requires a process, and patience. It does not happen overnight. And the processes will leave you with a timeline of transition or transformation. Since many enterprises are heterogeneous in nature, built up from layers of technology accumulated over time some systems will be easier to adapt than others. Understanding the shifting vulnerability points to your business throughout is an important risk management obligation. Digital twins may offer additional data for your risk analysis to help determine where to begin with zero trust changes. And as you establish zero trust components, you could use digital twins to revisit, test, and prioritize your critical areas for attention along the way.
Don’t forget to consider the data in your GRC platform, from risk assessments, audit findings, incidents, regulator’s reviews and comments, internal control and performance metrics, and any other indicators you may have vetted and monitor regularly. Also keep in mind that changes you make may impact those third party services and partners tied most closely to your infrastructure. Pay particular attention to ones with access to internal assets, regardless of the current controls and provisions in place. Note that as part of TPRM seemingly subtle and unrelated changes to your processes and methods may create temporary vulnerabilities in unforeseen ways. Finding these is one of the great benefits of digital twins, allowing you to identify and address such anomalies before they create a significant risk.
Between the guidance offered by data from your GRC, and leveraging it to inform configurations of digital twins, you will have a clear advantage in your efforts to strengthen security and reduce risk while increasing the extent of zero trust presence across your enterprise. Such an approach will help you achieve migration in process and control, while managing and minimizing the associated risks of an environment in transition. It’s a worthy effort to explore and pursue.
About the Author:
Simon Goldstein is an accomplished senior executive blending both technology and business expertise to formulate, impact, and achieve corporate strategies. A retired senior manager of Accenture’s IT Security and Risk Management practice, he has achieved results through the creation of customer value, business growth, and collaboration. An experienced change agent with primary experience in financial, technology, and retail industries, he’s led efforts to achieve ISO2700x certification and HIPAA compliance, as well as held credentials of CRISC, CISM, CISA.
