| 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]
| |