
4 minute read
WHY ZERO TRUST NEEDS SYSTEMS ENGINEERING
by Gina Mihajlovska, Cyber Security Manager at EY
The release of NIST publication 800-207 on Zero Trust Architecture (ZTA) gave the cybersecurity community the preliminary systems engineered processes to deliver ZTA. These processes leverage know-how, developed over decades, on the design, integration and management of complex systems over their lifecycle. At its core, systems engineering uses systems thinking principles to organise this body of knowledge. The outcome of such efforts is an engineered system which combines components that work cooperatively to collectively perform a useful function.
Systems engineering enables organisations to successfully perform the many functions needed for successful system design, implementation and, ultimately, decommissioning: engineering, reliability assessment, logistics, team coordination, testing and evaluation, designing for maintainability, and many others.
Systems engineering also permits the complexities and difficulties associated with the delivery of large and/or complex projects to be managed successfully. Systems engineering uses work process optimisation methods to deal with the, often significant, overlaps between technical and human-centred processes that have been developed to support the management of engineering disciplines. It ensures all likely aspects of a project or system are considered and integrated into a whole.
NIST Special Publication 800-207 defines ZTA as new way of developing a security enterprise architecture. NIST white paper CSWP 20, Planning for a Zero Trust Architecture: A Planning Guide for Federal Administrators, focusses on the implementation of the cybersecurity principles to be applied to services and data flows. In 2020 NIST introduced an approach for the implementation of ZTA to assist organisations with the complexity of moving their technology and operational environment from a security model based on protecting the perimeter to a zero-trust model. Implementation of this model requires systems engineering thinking. It enables organisations to thoughtfully and intelligently undertake the definition, information capture and risk management of the complexities and difficulties encountered as they transform their technology, resources and processes from perimeter protection security to zero-trust security.
However, the successful use of the NIST model is dependent on an organisation’s ability to articulate its zero-trust security architecture strategy and delivery programs. A well-articulated strategy is a prerequisite for the introduction of the security architectures that underpin a zero-trust security organisation. It necessitates an acknowledgment that the objective of a model based on zero-trust is to support a lifecycle that combines existing security processes with any processes developed to establish zero-trust.
There are numerous historical examples showing how systems thinking has been instrumental in creating the focus necessary to enable the change management needed for a business model update in an area critical to an organisation’s business and commercial health.
The diagram below demonstrates the NIST proposed logical flows which emphasise the interactions between policy and operational controls needed to achieve a zero-trust environment. Publication 800207 says a zero-trust deployment in an enterprise is made up of numerous logical components. These components may be delivered through an onpremises service or through a cloud-based service. The conceptual model shows the basic relationship between the components and their interactions. NIST has presented this as an ideal model showing logical components to demonstrate how their interactions are broken down across the policy engine and policy administrator. These logical components use a separate control plane to communicate while application data is communicated on a data plane.

3 Logical Components of Zero Trust Architecture
The interdisciplinary nature of systems engineering is well-suited to organisational change management and to regenerating any lifecycles underpinning the business strategies essential to creating market differentiation and growth. Therefore, how well an organisation protects customer confidential information and responds to exposures and threats is quickly becoming a market differentiator that is reinforced through the introduction of fit-for-purpose architectures for zero-trust.
The model aims to bring together the strategic architectural focus, the organisational thinking and the decision making necessary for transitioning to zero-trust security.
NIST has produced and communicated a set of systems engineered flows that can be used with the ZTA Maturity Model to support the transition to a zero-trust architecture. The Maturity Model has four phases and is reminiscent of waterfall project delivery models that map each phase to a path to assist the
There are numerous logical components that make up a ZTA deployment in an enterprise. These components may be operated as an on-premises service or through a cloud-based service. The conceptual framework model in Figure 2 shows the basic relationship between the components and their interactions. Note that this is an ideal model showing logical components and their interactions. From Figure 1, the policy decision point (PDP) is broken down into two logical components: the policy engine and policy administrator (defined below). The ZTA logical components use a separate control plane to communicate, while application data is communicated on a data plane (see Section 3.4).
The component descriptions:
• Policy engine (PE): This component is responsible for the ultimate decision to grant access to a resource for a given subject. The PE uses enterprise policy as well as input from external sources (e.g., CDM systems, threat intelligence services described below) identification of associated delivery tasks during the transition. Ideally, the model should be used to implement the automated processes and systems, and the architectures and designs that enforce policy decisions and gradually evolve an organisation to a zero-trust security posture.
The model offers significant guidance to practitioners of systems engineering on how to approach an undertaking that continues to baffle and confuse many in the security community. Organisations would struggle to implement zero-trust without this model. The holistic nature of the model guides organisations in the planning needed to achieve a successful deployment of the solutions essential to implementing zero-trust security.
Finally, it is beyond scope of this article to fully explore the depth and importance of the relationship between security and systems engineering. Rather, the article has tried to provide a brief analysis of the important connections and dependencies between ZTA, systems engineering thinking and the need for further discussions on approaches to its implementation.
Systems thinking allows organisations to successfully manage the difficulties and complexities encountered during the transition from perimeter-based to zerotrust security. Systems engineering can also generate organisational knowledge that can be used to inform business thinking in regard to what/where/when/ how to invest in security to ensure customer data continues to be protected in the future.
This is article part 1 of a 6 series on ‘Using the NIST Zero Trust Maturity Model to create the no-trust security organisation.’ www.linkedin.com/in/ginamihajlo
With an affordable annual fee, AWSN members will have access to discounts on programs and industry events, the membership Slack space, post or share job opportunities, and receive our monthly and any special edition newsletters