802
edits
Changes
Zero Trust Security Architecture (view source)
Revision as of 08:31, 14 April 2021
, 08:31, 14 April 2021Created 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..."
<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-security-architecture-gc-esa]]<br />[[File:ESAcontactus.png|link=mailto:ZZTBSCYBERS@tbs-sct.gc.ca]]</div> [[File:GOC ESA.jpg|center|link=http://www.gcpedia.gc.ca/wiki/Government_of_Canada_Enterprise_Security_Architecture_(ESA)_Program]] <div class="center">
{| style="border: 2px solid #000000; border-image: none;" width="1000px"
|-
! style="background: #e1caf7; color: black" width="175px" scope="col" " | [[Government of Canada Enterprise Security Architecture (ESA) Program|ESA Program Overview]]
! style="background: #e1caf7; color: black" width="125px" scope="col" " | [[ESA Backgrounder (Strategy)|ESA Foundation]]
! style="background: #e1caf7; color: black" width="125px" scope="col" " | [[ESA Requirements|ESA Artifacts]]
! style="background: #C495F0; color: black" width="125px" scope="col" " | [[ESA Initiatives|ESA Initiatives]]
! style="background: #e1caf7; color: black" width="125px" scope="col" " | [[ ESA Tools and Templates]]
! style="background: #e1caf7; color: black" width="125px" scope="col" " | [[GC ESA Artifact Repository|ESA Reference Materials]]
! style="background: #e1caf7; color: black" width="100px" scope="col" " | [[ESA Glossary| Glossary]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px"
|-
! style="background: #c2c2fa; color: black" width="100px" scope="col" " | [[Cloud Security Initiative]]
! style="background: #c2c2fa; color: black" width="100px" scope="col" " | [[HTTPS Initiative|HTTPS Initiative]]
! style="background: #c2c2fa; color: black" width="110px" scope="col" " | [[Data Loss Prevention Initiative]]
! style="background: #c2c2fa; color: black" width="120px" scope="col" " | [[Enterprise Vulnerability Management System Initiative]]
! style="background: #c2c2fa; color: black" width="100px" scope="col" " | [[DevSecOps Initiative]]
! style="background: #c2c2fa; color: black" width="120px" scope="col" " | [[Integrated Risk Management Initiative]]
! style="background: #c2c2fa; color: black" width="150px" scope="col" " | [[Domain Message Authentication Reporting and Compliance|DMARC Initiative]]
! style="background: #9a9af8; color: black" width="110px" scope="col" " | [[Zero Trust Security|Zero Trust Security Initiative]]
! style="background: #c2c2fa; color: black" width="110px" scope="col" " | [[GC Cyber Security Event Management]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px"
|-
! style="background: #969696; color: black" width="250px" scope="col" " | [[Zero Trust Security Architecture| Zero Trust Architecture]]
|}
</div>{{TOCright}}
=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.
{| class="wikitable"
!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
|}
[[File:ZTS Architecture Pillars.PNG|centre|frameless|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 [https://www.gcpedia.gc.ca/gcwiki/images/8/86/GC_Zero_Trust_Reference_Architecture.pdf Zero Trust Security Reference Architecture] document.
{| class="wikitable"
!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==
{| class="wikitable"
!#
!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|1000x1000px|alt=|thumb|High-level holistic view of ZTS|left]]
[[File:ZTS Application Access.PNG|thumb|1000x1000px|Application access target state|none]]
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|none|thumb|1000x1000px|Inter-service communication]]
==References==
[https://www.gcpedia.gc.ca/gcwiki/images/8/86/GC_Zero_Trust_Reference_Architecture.pdf GC Zero Trust Reference Architecture - DRAFT]
[https://www.gcpedia.gc.ca/gcwiki/images/c/c5/GC_Zero_Trust_Security_Concept.pdf Zero Trust Discussion Paper]
{| style="border: 2px solid #000000; border-image: none;" width="1000px"
|-
! style="background: #e1caf7; color: black" width="175px" scope="col" " | [[Government of Canada Enterprise Security Architecture (ESA) Program|ESA Program Overview]]
! style="background: #e1caf7; color: black" width="125px" scope="col" " | [[ESA Backgrounder (Strategy)|ESA Foundation]]
! style="background: #e1caf7; color: black" width="125px" scope="col" " | [[ESA Requirements|ESA Artifacts]]
! style="background: #C495F0; color: black" width="125px" scope="col" " | [[ESA Initiatives|ESA Initiatives]]
! style="background: #e1caf7; color: black" width="125px" scope="col" " | [[ ESA Tools and Templates]]
! style="background: #e1caf7; color: black" width="125px" scope="col" " | [[GC ESA Artifact Repository|ESA Reference Materials]]
! style="background: #e1caf7; color: black" width="100px" scope="col" " | [[ESA Glossary| Glossary]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px"
|-
! style="background: #c2c2fa; color: black" width="100px" scope="col" " | [[Cloud Security Initiative]]
! style="background: #c2c2fa; color: black" width="100px" scope="col" " | [[HTTPS Initiative|HTTPS Initiative]]
! style="background: #c2c2fa; color: black" width="110px" scope="col" " | [[Data Loss Prevention Initiative]]
! style="background: #c2c2fa; color: black" width="120px" scope="col" " | [[Enterprise Vulnerability Management System Initiative]]
! style="background: #c2c2fa; color: black" width="100px" scope="col" " | [[DevSecOps Initiative]]
! style="background: #c2c2fa; color: black" width="120px" scope="col" " | [[Integrated Risk Management Initiative]]
! style="background: #c2c2fa; color: black" width="150px" scope="col" " | [[Domain Message Authentication Reporting and Compliance|DMARC Initiative]]
! style="background: #9a9af8; color: black" width="110px" scope="col" " | [[Zero Trust Security|Zero Trust Security Initiative]]
! style="background: #c2c2fa; color: black" width="110px" scope="col" " | [[GC Cyber Security Event Management]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px"
|-
! style="background: #969696; color: black" width="250px" scope="col" " | [[Zero Trust Security Architecture| Zero Trust Architecture]]
|}
</div>{{TOCright}}
=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.
{| class="wikitable"
!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
|}
[[File:ZTS Architecture Pillars.PNG|centre|frameless|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 [https://www.gcpedia.gc.ca/gcwiki/images/8/86/GC_Zero_Trust_Reference_Architecture.pdf Zero Trust Security Reference Architecture] document.
{| class="wikitable"
!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==
{| class="wikitable"
!#
!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|1000x1000px|alt=|thumb|High-level holistic view of ZTS|left]]
[[File:ZTS Application Access.PNG|thumb|1000x1000px|Application access target state|none]]
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|none|thumb|1000x1000px|Inter-service communication]]
==References==
[https://www.gcpedia.gc.ca/gcwiki/images/8/86/GC_Zero_Trust_Reference_Architecture.pdf GC Zero Trust Reference Architecture - DRAFT]
[https://www.gcpedia.gc.ca/gcwiki/images/c/c5/GC_Zero_Trust_Security_Concept.pdf Zero Trust Discussion Paper]