Reach Us via WhatsApp
KSA: +966 115204950
Bahrain: +973 13304959
Zero Trust Architecture

Planning a Zero Trust Architecture

Zero trust (ZT) is a set of principles on which the construction of information technology is planned, implemented, and implemented. ZT uses a holistic approach that considers all potential risks to a particular job or business process and how they are minimized. Thus, there is no specific infrastructure implementation or construction, but it depends on the work flow (i.e., part of the business objective) being analyzed and the resources used to create that work flow. Zero trust thinking strategy can be used to plan and deploy a business IT infrastructure, which can be referred to as zero-trust architecture (ZTA).

Business managers and program operators need to be involved in planning and deploying for the ZTA to be effective. ZTA planning requires input and analysis from system owners and workflow and professional security designers. Zero trust will not be placed from the top of the existing application but needs to be integrated into all aspects of the business. This research paper introduces some concepts to the NIST Risk Management Framework (RMF) for managers and operators. The RMF sets out a set of processes and activities that are integrated into business risk analysis, planning, development, and implementation. Managers who may not normally do the tasks specified in the RMF may find that they will need to get acquainted with them as they move on to ZTA.

NIST Special Publication 800-207 provides a conceptual framework for dishonesty. Although not perfect for all information technology it can be used as a tool to understand and develop a business ZTA. NIST SP 800-207 also provides logical structures that can be used to map solutions and spaces. Invisible architecture is provided in the image below:

The parts are listed as their logical function, so they do not represent a single operating system. It is possible that many components may perform one logical function in a distributed way, or a single solution may perform multiple logical roles. The roles are described below:

  • Policy Engine (PE): The “brain” of ZTA implementation and the components that ultimately analyse service access requests. PE relies on information from a variety of data sources (access logs, threatening intelligence, device health and network ID verification tests, etc.)
  • Policy Manager (PA): The function of the PE provider. The role of PA is to establish, maintain and terminate times in the data area. PA, PE and PEP interact with a separate set of logic (or physical) called a control plane. The control plane is used to set up and configure the channels used to send app traffic (i.e., data plane).
  • Policy Enforcement Point (PEP): Part of those applications, resources, etc. which they will work with to provide access to the resource. PEP is responsible for collecting PE information and following the instructions issued by PA to establish and terminate communication times. All data flight communications (i.e. all workflow app traffic) between business resources must be via PEP.
  • Information Feed: This is a set of device policies, ownership and attributes, environmental features and historical data used by PE to make decisions about access to resources.

Tenets of Zero Trust

Zero trust can be summarized as a set of principles (or principles) used to plan and implement an IT architecture. The principles below were originally described in NIST SP 800-207 but are repeated here and collected as doctrines relating to network ownership, device life, or data flow. Some ethical discussions have been included, as well as other considerations that editors should keep in mind when developing zero-trust architecture.

Tenets that Deal with Network Identity Governance

All service verification and authorization are subject to change and strict enforcement before access is granted. A typical business has a wide collection of network identities: end users, service accounts, etc. Some end users may have multiple network ownerships, and some identities may only be used for hardware / software components. An entity needs to have an administrative and structural policy in place to perform only authorized functions, and only if you have properly verified yourself. An entity needs to consider whether their patent governance policies are sufficiently mature and where and how verification and authorization is performed.

Tenets that Deal with End Devices

All data sources and computer services are considered applications. An entity relies on a variety of resources to carry out its mission: mobile devices, data stores, accounting services (including visual), remote sensors / actuators, etc. All these components need to be considered in the ZTA. Some elements (e.g. IoT sensors) may not be able to support other solutions such as activation agents, application sandboxing, etc. therefore alternatives that use network infrastructure may be required. If a device lacks some security capabilities, the company may need to add a portion of PEP to provide that functionality.

An entity monitors and evaluates the integrity and security of all assets held and its assets. This tutorial deals with the components of online hygiene: configuration, modification, app loading, etc. Utility status should be monitored and appropriate action taken when new information such as new vulnerabilities or attacks is reported or detected. The confidentiality and integrity of the data used must be protected. This requires that business executives know how resources are prepared, stored and maintained.

Tenets that Apply to Data Flows

All communications are secure regardless of network location. With zero trust, the network is always considered an opponent. There should be an assumption that the attacker is on the network and can see / correct the connection. Appropriate protections should be in place to protect the confidentiality and integrity of transportation data. If resources are unable to provide this functionality naturally, a separate PEP component may be required.

Access to the resources of each business is provided per session. In the ideal zero trust architecture, all unique functions will be verified and validated before they can be performed. For example, the removal function that follows the application of the readings on the website should launch a validation and authorization test. This may not always be the case and other mitigation measures such as logging, and backups may be required to recover and restore unauthorized operations. Business managers will need to learn how to apply the best grain access policies for each service. If the current set of tools does not allow for this, other solutions such as login, translation tools, or backups may help reduce the risk.

Access to services is determined by flexible policy — including the client’s personal identity, request / service, and requesting assets — and may include other ethical and environmental factors. At zero trust, the default behaviour of all resources is to deny all communications with the approval list. Members of this permit list must prove themselves and prove that they are complying with the business policy to be granted time. These may include meeting requirements such as client software versions, modification level, accommodation, historical application patterns, etc. Note that it may not be possible to check everything immediately before the access request, but some may be done soon (e.g., daily. Software conversion checks).

An entity collects as much information as possible about the current state of assets, network and communication infrastructure and uses it to improve its security standing. Zero trust adds a missing (or non-existent) variable response feature to structures based on a previous cycle. System logs and threatening intelligence are used to refine or change policy in response to new information. For example, new vulnerabilities in the software component used in a business are announced. The zero-trust business will move swiftly to disassociate the affected resources until they can be rented out or repaired to minimize the newly discovered risks. Business managers will need to set up and maintain a comprehensive business monitoring and amendment system and should consider how automated tools can help respond to newly received threats.

The Process

The Risk Management Framework methodology and its seven steps:

  • Organizational and program adjustments (PREPARE step)
  • System split (CATEGORIZE step)
  • Manage selection (SELECT action)
  • Manage usage (IMPLEMENT step)
  • Manage testing (ASSESS step)
  • System authorization (authorize action)
  • Manage monitoring (MONITOR step)

While the steps are described in sequence, after the initial implementation, they may be performed or updated in any sequence. Each of the seven steps can be done and updated as needed, and possibly in conjunction with the other steps / activities. Switching between steps can be liquid. This is especially true when the ZTA is being developed and implemented, as the volatile zero trust environment may require duplication or rapid changes in RMF measures in response to new information or technological changes.

At Kanoo Elite, we have developed our data privacy policies using trust principles. Our vault allows you to create granular access policies that are continuously tested and monitored. We also provide control over your data and details of how users and services access it and in what form. We combine this polymorphic encryption with vault technology to keep all your sensitive data in one place. Our technology allows you to use data without having direct access to it, without having to rely on another level. If you would like to know more about how Kanoo Elite deals with zero trust, contact us and schedule a demo.

Speak to an Expert

    All Copyright Reserved © 2021 Kanoo Elite