Zero Trust Security Architecture
ESA Program Overview | ESA Foundation | ESA Artifacts | ESA Initiatives | ESA Tools and Templates | ESA Reference Materials | Glossary |
---|
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 |
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 |
|
User Devices | Managed Devices |
|
Resource Protection | Data |
|
Continuous Monitoring | Security Visibility and Real-time Threat Protection |
|
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
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.