802
edits
Important: The GCConnex decommission will not affect GCCollab or GCWiki. Thank you and happy collaborating!
Changes
Jump to navigation
Jump to search
Line 28:
Line 28: − + − =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]
Zero Trust Security Architecture (view source)
Revision as of 12:38, 20 April 2021
, 12:38, 20 April 2021no edit summary
! 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}}
