Zero trust architecture represents a fundamental shift in how enterprises secure their technology resources. Arguably, it’s a bigger change even than migrating to the cloud. IT teams face the challenge of undoing 30 years of infrastructure development while encouraging their IT employees to say goodbye to the banks of knowledge they’ve accrued over the course of their entire educational and professional careers.
The coordination, cooperation, and support for this sea-change of a project cannot be underestimated. Though a single group may initially bear zero trust transformation, it cannot be implemented in silos.
Let's review the different personas and the roles they will play in a successful zero trust transformation. As each organization is different, there may be slight differences in personas, but the overall message roles and responsibilities should be similar.
The business and the CIO
The business must ultimately own the zero trust initiative, while the CIO, in hand with the CISO, justifies the initiative in terms of the benefits to the business, risk tolerance, etc. The business must support the initiative with the required resources given the agreed-upon scope, timeline, and deliverables. Any zero trust architecture (ZTA) initiative is a long-term commitment, and the CIO must report on the status for continued support.
- Evangelizing the project both outward to the wider business and inward to the IT organization. For some, implementing zero trust architecture is a significant change, so empathy is required.
- Resourcing the IT organization, allowing time for existing operations along with the new project work. Staff must be properly educated and supported through upskilling and reskilling periods.
Enterprise architects (EAs) are the personnel who metaphorically fit all the pieces together. Though they may traditionally have focused more on systems integration, they must now consider ZTA and identity in a much broader scope than before.
- Designing the core, high-level zero trust enablement architecture.
- Coordinating the different IT groups (perhaps with a PMO) and technologies aligning them toward a common goal.
- Working closely with the CIO, ensuring milestones are met, and progress reported.
The identity team
This is arguably one of the most critical groups within a ZTA project. While a modern, automated IAM ecosystem is not required on day one for ZTA, it is pivotal to the long-term success of the project and ideally should be realized in parallel. The identity team will work closely with the business on entitlement aspects of the project, with this support being crucial for success.
- Implementing authentication mechanisms that are simple, frictionless, and secure for users and non-user systems alike, in accordance with zero trust principles.
- Coordinating with other groups and technologies to standardize authorization for access to enterprise resources.
- Working with the business on an automatic access entitling strategy, such as role-based access control (RBAC), for example.
- Assisting with the creation of entitlement workflows, automation of access provisioning and attestation, and working with different business functions to formally identify who needs access to what, instead of relying on help desk tickets.
- Accommodating secure resource access for third-party users and systems to facilitate moving away from network-based access controls.
Networking staff are among the most significantly affected by ZTA initiatives. They must be fully supportive of the change and open to reskilling. Previously, the network team was responsible for user-to-application connectivity, while with ZTA the scope, complexity, and (from a security perspective) overall importance of the network is reduced. With ZTA, network teams focus on creating a performant canvas for the zero trust traffic; connecting users and workloads to the zero trust broker.
- Assisting in transforming underlying network connectivity from a wide, flat network to something resembling small pockets of private networks.
- Helping identify and transition from network-based access to resource-based access, especially as it pertains to third-party and non-user based resources.
- Aiding in the design and network implementation of new datacenter, office, storefront, factory, and other relevant locations.
Like network teams, information security teams and their operations can be heavily affected by a ZTA, which might make some uncomfortable. The CISO must lead the security aspects of the effort and ensure all are on board, educated, and properly skilled.
One of the main goals of security teams is ensuring the new ZTA creates a default high-bar secure environment for applications to reduce friction and increase innovation.
- Assisting EAs with ZTA design
- Updating policies, procedures, governance, and compliance documentation.
- Working with the business on data sensitivity and classification strategy, as well as associated data protection strategies.
These personas manage the infrastructure that supports enterprise applications and resources. They’re worthy of a great deal of consideration regarding ZTA, especially in the presence of legacy technologies.
ZTA is a design philosophy, so many modifications to policies and architecture will change as the enterprise moves away from network perimeter security models. ZTA also involves deploying infrastructure and applications, thereby requiring wholesale shifts in DevOps practices, relying on infrastructure as code (IAC), for instance, which may be new to some staff.
- Defining DevOps deployment frameworks.
- Implementing ZTA principles to support infrastructure, e.g., domain controllers.
- Migrating infrastructure management services in support of the removal of network-perimeter security models.
- Assisting with the migration or replacement of legacy systems.
Application owners, developers, and their teams face similar challenges as network and security teams regarding ZTA, especially for homegrown applications. These teams must now focus more on underlying infrastructure and how their applications match architectural principles afforded by ZTA.
- Building their knowledge of ZTA and integrating those principles into application design.
- Working with business and IAM teams to define app entitlements, and then linking those to roles, entitlement workflow automation, and attestation requirements.
- Documenting and communicating data sensitivity and protection requirements.
Support teams, testers, and consumers
These are the people at the coal face of the initiative and crucial to its success. Helpdesk and desktop teams interface with the users, supporting the new environment while providing feedback to the ZTA project teams. IT-friendly employees help pilot the new environment and new changes before being introduced to the wider population.
- Users being actively aware of the initiative and supportive of the change, even through interruptions.
- Reporting bugs rather than silently inventing workarounds.
- Testing and enthusiastically exploring and breaking things. Formal pilot programs can offer “carrots” to entice further participation, like faster access to the newest OS, app versions, or even hardware as part of the project.
Zero trust is a team sport. It takes alignment among various departments to pull off on both the business and IT sides of the aisle. But, when done successfully, all benefit.
What to read next
Exploring the history of enterprise app connectivity to prepare for what’s next
Basic principles in designing an education and upskilling strategy