Zero Trust Security Architecture

ESA Program Overview	ESA Foundation	ESA Artifacts	ESA Initiatives	ESA Tools and Templates	ESA Reference Materials	Glossary

Cloud Security Initiative	HTTPS Initiative	Data Loss Prevention Initiative	Enterprise Vulnerability Management System Initiative	DevSecOps Initiative	Integrated Risk Management Initiative	DMARC Initiative	Zero Trust Security Initiative	GC Cyber Security Event Management

Zero Trust Architecture

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

1000x1000px

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