Zero Trust Full

As a recap, Zero Trust is a security model, a set of principles for designing a system, and a coordinated strategy for cybersecurity and system management based on recognizing that threats exist both within and outside the traditional boundaries of the network.

Zero Trust repeatedly questions the premise that users, devices, and network components should by default be trusted based on their network location.

Many definitions and discussions about Zero Trust (ZT) underline the concept of eliminating perimeter defenses of wide-area (e.g., firewall) with a definition in relation to existing perimeters (micro-segmentation, micro perimeter), as part of the functional capabilities of ZTA (Zero trust Architecture).

Zero Trust incorporates comprehensive security monitoring, granular, dynamic, and risk-based access controls, system security automation in a coordinated manner and in all aspects of the infrastructure to focus specifically on protecting critical assets (data) in real-time in a dynamic threat environment.

This data-centric security model allows the least privileged access concept to be applied to every access decision, where answers about who, what, when, where, and how are essential to properly allow or prohibit access to resources.

From here, the most important principles, the basic ones, of the ZTA are much easier to understand and are represented by:

  1. All data sources and computing services are considered as resources (including personally owned devices, as long as such classification is decided). The entire private network is not considered a default trust area and the assets should always act as if an attacker is present on the network.
  2. All communications are secured regardless of the location of the network (the location of the network itself is considered untrusted, the communication is necessary to be carried out in the safest way available).
  3. Access to individual resources is granted on a session-by-session basis, with trust assessed before access is granted, with the smallest privileges possible. Keep in mind that devices on the network may not be owned or configurable. Similarly, it is possible that visitors and/or contracted services may include external assets that need access to the network, including BYOD devices. No resources shall be deemed to be reliable, with each asset having its security position assessed by means of a PEP before a request is granted to a resource, the evaluation being continuous for as long as the session lasts. Devices may have artifacts that allow authentication and provide a higher level of trust than similar requests.
  4. Access to resources is determined by the dynamic policy – including the observable state of the client's identity, application/service and the requested asset (it may also include other behavioral and environmental effects; based on the definition of available resources, who the members are, etc.). The asset status request can include device features such as software versions, location, temporary elements of the request, previous behavior, installed credentials, etc. Behavioral attributes include, but are not limited to, automatic analysis of subjects, device analysis, and measured deviations from observed usage patterns, etc. Environmental attributes can include factors such as the requestor, network location, time elements, etc., even the reported active attacks. Then, not all the resources are located on the accessible infrastructure. The resources include remote topics as well as cloud services.
  5. Monitoring and measuring the integrity and security position of all assets owned and associated. No asset is reliable, with the asset security posture assessment being carried out when evaluating a resource request. It is also necessary to have a continuous diagnostic and attenuation system (CDM – Continuous Diagnostics and Mitigation) who have a similar system for monitoring the status of devices and applications facilitating the application of patches/fixes as needed. Assets that are discovered to be undermined, have known vulnerabilities, and/or are not managed directly may be treated differently (including denial of all connections) while maintaining the state considered the safest. It may also apply to associated devices (e.g., personally owned devices) that may be allowed limited access to resources. In addition, remote subjects and assets cannot have full trust in their connection to the local network.
  6. All resource authentications and authorizations are dynamic and strictly enforced before allowing access. There is talk of a constant cycle of gaining access, scanning, and assessing threats, adapting, and continuously reassessing trust in continuous communication (ICAM – Identity, Credential, and Access Management). This also includes multifactor authentications (MFAs) for access in accordance with communication requirements (restricted or to all available resources).
  7. It collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve the security position. Assets should assume that all traffic is monitored and potentially altered, with all connection requests required to be authenticated and authorized, and all communications to be made in the safest way possible (e.g., provide confidentiality, integrity protection and source authentication).

Finally, moving assets and workflows should have a consistent security policy and a consequent security posture.

Assets and workflows should retain their security position when they move, including both the networks themselves and the remote connection, in cloud workflows or instances.

And now, there are described enough elements that seem to have a theoretical character and it would be appropriate to move on to discussions of completion/clarification.

Dealing with a purely theoretical architecture, without clear, precise elements, still under debate, we find ourselves forced to try to create our own Zero Trust structure, adapted by each reader to their own needs or the needs of their job or work involvement, advisory effort, etc.

And that requires more experience than you can imagine...

Bibliography:

Publication "NIST Special Publication 800-207" – Zero Trust Architecture.

Embracing a Zero Trust Security Model.

Dorin M, January 5, 2022

Logo Dorin M Wolf

Thank you for your visit!

Whenever you consider that it "worth", I expect you with feedback, comments, or donations in
the account RO95BRDE090SV31723640900 opened at "BRD-Groupe Société Générale" S.A. Romania or
Paypal donation (using the button below)

or on Patreon (using the button below).

Become a Patron!
  • About the Author: Dorin M - Merticaru Dorin Nicolae

No thoughts on “Zero Trust Principles”