Zero Trust Security Architecture

Revision as of 08:31, 14 April 2021 by Greggory.elton (talk | contribs) (Created page with "<div style="float: right; z-index: 10; position: absolute; right: 0; top: 1;">File:JoinusonGCconnex.png|link=http://gcconnex.gc.ca/groups/profile/2785549/gc-enterprise-secur...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
JoinusonGCconnex.png
ESAcontactus.png
GOC ESA.jpg

Zero Trust Reference Archicture

In order to achieve the target zero trust reference architecture, industry best practices, security controls and related whitepapers in alignment with zero trust principles have beentaken into consideration.

In an idealistic scenario, zero trust architecture can be split into three categories.

Define critical business goals

  • Identify the in scope applications and datatype
  • Determine the protect surface (data,applications, devices, services, etc.)
  • Identify the communication flows withinthe network including network flowsbetween applications, users and devices
  • Define the business scope and requirements for the zero trust architecturewhile taking into consideration the threatlandscape
  • Map the business scope and requirementsto zero trust goals

Bring building blocks together

  • Identify and prioritize the zero trust building blocks based on the business scopeand requirements
  • Define use cases based on the zero trustprinciple.
  • Map the defined use cases to theprioritized zero trust building blocks toensure comprehensive coverage
  • Identify key security and technologycontrols required to achieve the zero trustarchitecture in alignment with the buildingblocks and business goals

Controls and boundaries

  • Leverage the building blocks and applicablesecurity/technology controls to architectthe architecture
  • Segment the network based on datasensitivity and criticality
  • Define micro perimeters around sensitivedata and resources
  • Enforce micro perimeters with identifiedsecurity controls
  • Limit and enforce access to microperimeters
  • Validate the designed controls andboundaries against the business scope andrequirements

Zero Trust Pillars

The following Zero Trust strategic pillars help in defining the key security capabilities to be considered for a Zero Trust Security model. These pillars have been used to derive the critical building blocks required to implement the ideal zero trust scenario.

Pillar Examples
Users Identification and authentication, leas tprivilege access, two-factor authentication
User Devices User device identification and verification, user device management
Networks Isolation and protection of network devices and infrastructure
Resource Protection Protection of assets including data, applications and services
Continuous Monitoring Ongoing automated security event management and user behaviour analysis; real-time correlation, threat assessment and response

The pillars defined focus on Zero Trust not the Zero Trust Network Architecture as the Zero Trust Architecture includes ZTNA as a piece. Zero Trust Network Architecture (ZTNA) refers to a model of securing an organization’s systems and resources based on the Zero Trust principle of “Never Trust, Always verify”. The ZTNA approach includes a user/application model which required the verification of anything and everything trying to connect to systems before granting access as opposed to the old “protect the perimeter” approach.  

Key Security Considerations

The following are a subset of the key considerations for a Zero Trust Security policy. For the full list see page 9 of the Zero Trust Security Reference Architecture document.

Pillar Category Considerations
Users Access Control
  • Implement fine-grained, least privilege access control
  • Base access control decisions on multiple inputs (user authentication assurance level, user role/privileges, device authentication, device health/status, source environment, target resource, usage/behavioral patterns, etc.) – essentially Risk Adaptive Access Control
  • Implement effective user account management procedures - add/update/remove user accounts when and as required
User Devices Managed Devices
  • Maintain an up-to-date inventory of all user devices
  • Assign each device with a verifiable unique identifier (e.g., device certificate)
  • Keep the configuration/health of all managed user devices up-to-date using Mobile Device Management (MDM) solution 
  • Secure boot considerations 
Resource Protection Data
  • Identify and catalogue all data resources
  • Label data to distinguish sensitive from non-sensitive data
  • Encrypt sensitive data at rest
  • Encrypt all end-to-end communication, regardless of source and destination locations (both internal and external) 
  • Data Loss Prevention (DLP)
Continuous Monitoring Security Visibility and Real-time Threat Protection
  • Security Information and Event Management (SIEM)
  • User Entity Behavior Analytics
  • Traffic flow inspection and analysis
  • Real-time correlation, assessment and response based on inputs from multiple sources (including data from automated monitoring tools) 

Use Cases

# Use case Description
1 Authorized user access

An authorized user needs secure access to a corporate application/resource from anywhere (i.e.

outside the enterprise or within the enterprise) via a company managed device. The corporate 

application can either be on premise or in the cloud.

2 Administrator access through managed devices An administrator requires access to an enterprise resource to perform administrative tasks such as

application configuration, patching, infrastructure configuration changes, etc., via a managed 

device.

3 Authorized user access through unmanaged

devices

The authorized user requires secure access to a corporate application/resource via an unmanaged device.
4 Application to application communication Application to application access or inter server communication within the enterprise
5 Inter-service communication (microservices) Service is initiating multiple calls to another services to perform activities such as read data, store user

information.

6 Application Delivery Pipeline Security DevOps teams building cloud applications and interacting APIs.
7 API Management The user/device/third party application API calls made to the Government of Canada applications
8 On premise application to cloud

application/database or vice versa

An on premise application requires access to a database hosted within the cloud environment
9 Layer 7 Attacks Protection and Lateral Movement

Protection

Prevent attacks and unauthorized lateral movement within the enterprise should a host asset or user be

compromised

Next Steps

  • Development of an implementation roadmap to achieve a Zero Trust architecture
  • Conduct workshop with all applicable stakeholders (e.g. CRA, ESDC, NRC, etc.) to validate building blocks and ensure alignment of the Zero Trust Reference Architecture with existing GC projects and initiatives 
  • Identification of technology and controls required to achieve the Zero Trust Reference Architecture use cases  i.e. existing technology and controls at GC vs acquisition of new technology 
  • Prioritization of implementation activities based on factors such as risk, cost and feasibility 
  • Identify potential pathfinder departments to pilot Zero Trust

Architecture Diagrams

File:ZTS HighLevel Holistic View.PNG
High-level holistic view of ZTS
File:ZTS Application Access.PNG
Application access target state

The above image is a view of an eventual target state in which security is enhanced, the user experience is greatly improved and costs and complexity are reduced.

File:ZTS Communication Diagram.PNG
Inter-service communication

References

GC Zero Trust Reference Architecture - DRAFT

Zero Trust Discussion Paper