Changes

Jump to navigation Jump to search
no edit summary
Line 28: Line 28:  
! style="background: #969696; color: black" width="250px" scope="col" " | [[Zero Trust Security Architecture| Zero Trust Architecture]]
 
! style="background: #969696; color: black" width="250px" scope="col" " | [[Zero Trust Security Architecture| Zero Trust Architecture]]
 
|}
 
|}
</div>{{TOCright}}
+
</div>{{Delete|reason=Expired Content}}
=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]
 

Navigation menu

GCwiki