The Zero Trust Model

By Ashwin Venugopal -

 





Zero Trust Concept

As the name suggests zero trust always assumes breach and verifies every request as though it originates from an open network, instead of assuming that everything behind the corporate firewall is completely safe. Zero trust always teaches us to "never trust, always verify". while every access request is fully authenticated, authorized, and encrypted before granting access, the rich intelligence and analytics are used to detect as well as respond to the anomalies on real time.

Zero Trust Principles

  • Verify explicitly- You must always authenticate as well as authorize according to the available data points, along with the user identity, location, device health, service or workload, data classification, and anomalies.

  • Use least privileged access- User access must be limited with the help of Just-in-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data protection to protect both the data as well as productivity.

  • Assume breach- The blast radius must be minimized for breaches and lateral movement should be prevented by segmenting access by network, user, devices, and app awareness with the help of analytics to get visibility, drive threat detection, and improve defenses.

Zero Trust Components

The six primary components are:

  1. Identities- Each identity must be verified and secured with strong authentication across your entire digital environment.

  1. Devices- Gain visibility into the devices accessing the network after ensuring their health status and compliance before granting access.

  1. Applications- Discover shadow IT, ensure appropriate in-app permissions, gate access based on real-time analytics while also monitoring and control user actions.

  1. Data- Prefer data-driven protection instead of perimeter-based data protection, use intelligence to classify and label data, encrypt and restrict access based organizational policies.

  1. Infrastructure- You can readily use telemetry to detect attacks as well as anomalies, automatically block as well as flag risky behavior, and employ least privilege access principles.

  1. Network- You should not blindly trust the devices and users simply because they are on an internal network. You must encrypt all internal communications, limit access by policy, employ microsegmentation, and real-time threat detection. 

Plan for a Zero Trust Model

A successful zero trust strategy contains seamless as well as flexible access to systems, applications, and data while also ensuring the security of both the users and the resources required to complete their jobs. The steps to securing your identity infrastructure includes:

  • Strengthen your credentials- If users in your identity system uses weak passwords without strengthening them with MFA, you will be compromised more often.

  • Reduce your attack surface area- You must avoid using older, less secure protocols, limit access entry points, and exercise more significant control of administrative access to resources to make it harder for the hackers to even think of an attack.

  • Automate threat response- You can easily reduce costs and risks by simply reducing the time criminals have to embed themselves into your environment.   

  • Increase your awareness- The regular auditing as well as logging of security-related events and alerts, will help you to identify the pattern that may indicate an internal attack or attempted or successful external penetration of your network.

  • Enable user self-help- You can reduce friction by simply empowering your users to stay productive, even as you remain vigilant.

Zero Trust using Azure AD Conditional Access

Azure AD offers the much needed strong, adaptive, standard-based identity verification required in zero trust framework. It provides intrinsically strong authentication (including automatic adaptive protection against many attacks) along with the permission for admins to express their access requirements in simple terms. A framework of controls like additional authentication factors, terms of use, limited access, and the other session semantics are available to guarantee that "we are secure at access" in our zero trust approach.

Zero Trust Networking

All the organizations contains their particular network security characterized by the following:
  • Few network security perimeters and open, flat networks.
  • Minimal threat protection and static traffic filtering.
  • Unencrypted internal traffic. 

If you want to implement an end-to-end zero trust framework for securing networks, you should firstly focus on the following initial deployment objectives:

I. Networking segmentation- Many ingress/egress cloud micro-perimeters with some micro-segmentation.
II. Threat protection- Cloud native filtering and protection for known threats.
III. Encryption- User-to-app internal traffic is encrypted. 

After successfully completing all these steps, you can also focus on the following additional deployment objectives:

IV. Network segmentation- Fully distributed ingress/egress cloud micro-perimeters and deeper micro-perimeters and deeper micro-segmentation.
V. Threat protection- Machine learning-based threat protection and filtering with context-based signals.
VI. Encryption- All traffic is encrypted.














Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more