Zero Trust Security Principles

The drive to find new resources for innovation and process improvement in life science companies is becoming more and more based on technologies. On this journey, they need an infallible cybersecurity system.

Modern-day enterprises need more than detailed plans, talented people, and capital funding to succeed in the long haul. They need an infallible cyber security system. Businesses don’t operate the same way they used to in the 2000s.

There are remote workers, several internal networks, and cloud services. Moreover, the covid-19 pandemic allowed employees to work from home or even a vacation spot. Although these changes have helped enterprises in many ways, they also pose a threat to their overall security.

And since the perimeter of the enterprises has changed drastically, perimeter-based network security is deemed insufficient. Once an attacker finds a way into the network, there are no hindrances to further lateral movement. So, what’s the best possible cyber security option available currently? It’s Zero Trust (ZT).

Download the Zero Trust security report.

Download the report

Zero Trust Paradigm

There’s a saying, ‘Precaution is better than cure.’ The Zero Trust (ZT) approach works with the same focus. A ZT security model assumes that the enterprise-owned environment is no better than a non-enterprise-owned environment. An attacker can also be present in the enterprise environment; thus, ZT-based security has no implicit trust.

It constantly analyzes and evaluates the risks to the assets and business functions of the enterprise. Then it enacts protective measures to minimize risks, as it’s not possible to eliminate the uncertainties. These measures include minimizing resource access to only those users needing access and continually authenticating and authorizing each access request.

A Zero Trust Architecture (ZTA) is an enterprise cybersecurity architecture based on Zero Trust principles. It prevents data breaches and restricts internal lateral movement only to trustworthy users. ZTA is an end-to-end approach to enterprise resource and data security by granting only the minimum privileges needed to complete a task.

The main objectives are authentication, authorization, reducing implicit trust zones, and creating highly detailed access rules. ZTA must adhere to the following principles:

Everything is a resource. All data sources and computing services are treated as resources to be protected.
Secure all communication. Every communication must meet the same security requirements regardless of network location.
Per-session access. Access to individual enterprise resources is granted on a per-session basis.
Dynamic, enforced policy. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
Trust nothing; monitor everything. The integrity and security posture of all owned and associated assets is continuously measured — no asset is inherently trusted.
Collect to improve. The enterprise collects vast data on asset and network state to continually improve its security posture.

Zero Trust Architecture Components

At the heart of a ZTA sit three logical components that, together, decide and enforce every access request.

Policy Engine (PE)

Decide

The ultimate decision-maker for granting access, using enterprise policy and external input as a trust algorithm. Works alongside the Policy Administrator.

Policy Administrator (PA)

Execute

Executes the PE's decision, establishing or shutting down communication between a subject and a resource. Some implementations merge PA and PE.

Policy Enforcement Point (PEP)

Enforce

Enables, monitors and terminates connections between a subject and a resource. Beyond the PEP lies the trust zone.

Beyond the core components, an enterprise uses several local and external data sources to feed the trust algorithm:

Industry compliance system

Ensures the enterprise complies with all required regulations.

Threat intelligence feed(s)

Provides internal and external information that helps the PE make access decisions.

Network & system activity logs

Aggregates asset logs, network traffic and resource-access actions for real-time posture feedback.

SIEM system

Collects security-centric information for later analysis, used to refine policies and warn of attacks.

Zero Trust deployment

You may understand ZTA deployment through the following examples:

Enterprise with satellite facilities: It is common to find enterprises with a single headquarters and geographically dispersed branches that are not joined by an enterprise-owned physical network connection. Their employees may still need to access enterprise resources using personally-owned or enterprise-owned devices. Thus, enterprises may grant access to some resources but deny or restrict access to more sensitive resources by hosting PE/PAs as cloud services.

Contracted services and/or non-employee access: Many modern businesses employ people on a contractual basis. These temporary employees need to access the enterprise resources for a fixed duration of time and may also need to interact with other employees. Here, the ZTA infrastructure will let them access enterprise resources while safeguarding sensitive resources. The enterprise may host PA/PE/PEPs as a cloud service or on the LAN.

Collaboration across enterprise boundaries: When two enterprises collaborate on a project, they may need to access resources located on each other’s infrastructure. In such a case, the organization with resources on its infrastructure may grant access to only some information while denying access to overall enterprise resources — for example by hosting PE/PAs as a cloud service without establishing a VPN or similar facility.

Zero Trust use cases

The following real-world examples help illustrate the growing need for Zero Trust Architecture:

Microsoft

Its Zero Trust framework follows 'never trust, always verify.' A layered approach secures both corporate and customer data, ensuring productivity, risk mitigation and cloud migration.

IBM

Its Zero Trust strategy increases cyber resiliency while managing the risks of a disconnected business environment, using context to connect the right users to the right data at the right time.

AWS

AWS IoT helps build a Zero Trust Architecture on the seven tenets of Zero Trust, combining IoT, identity and networking services to move incrementally to ZTA.

Migrating to Zero Trust Architecture

Implementing a ZTA from scratch may not be possible as organizations already have an existing network. Thus, enterprises should implement Zero Trust principles subtly. They should opt for a hybrid Zero-Trust/perimeter-based security system while investing in ongoing IT modernization initiatives.

An enterprise needs a baseline of competence before migrating to a Zero Trust Architecture. This baseline encompasses assets, business processes, subjects, traffic flows, and dependency mappings identified and cataloged for the enterprise. Incomplete knowledge regarding these will lead to business-process failure.

Pure Zero Trust Architecture. An organization can build a ZTA from scratch if it has to complete a new task requiring new infrastructure. It may incorporate ZT concepts to some degree. First, it must identify the workflows and components needed, then map how they interact with each other.

Hybrid ZTA and perimeter-based architecture. Since no significant enterprise can shift to ZTA in a single step, an enterprise may operate in a hybrid system, with flexible common elements that can operate in both ZTA and perimeter-based architecture.

Steps to introduce ZTA to a perimeter-based architecture

Identify users. The PE must know enterprise subjects, including human and non-person entities (NPEs). Privileged users such as developers or administrators may have broad access; use logs and audits to identify their behaviour patterns.
Identify assets. ZTA requires the ability to identify and monitor every device that accesses enterprise resources. Since a complete census is impossible, build a ZTA capable of quickly identifying new assets.
Identify key processes and evaluate risks. Rank business processes, data flows and their relations. Start with low-risk business processes for the first transition.
Formulate policies for the ZTA candidate. Choose a candidate service by importance, affected subjects and resource state. Identify all upstream and downstream resources and entities.
Identify candidate solutions. Compose a list of candidate solutions and run a pilot as a 'proving ground' for ZTA before full deployment.
Initial deployment and monitoring. Operate in observation/reporting-only mode at first — grant most requests and compare connection traces against the developed policy.
Expand the ZTA. After gaining confidence and refining the policy set, enter steady operation, gather stakeholder feedback and plan the next stage of deployment.

Summary

In conclusion, the ZTA security system is much better suited for modern enterprises, given the circumstances under which they operate. Enterprises can establish their own policies according to which the PE/PA/PEPs will grant, deny or restrict access to enterprise resources. This ensures the autonomy of enterprises while safeguarding their resources.