Important: The GCConnex decommission will not affect GCCollab or GCWiki. Thank you and happy collaborating!
ESA Architecture Description Document (ESADD)
Overview of GC ESA Description Document (ESADD)
The GC Enterprise Security Architecture Description Document - Main Body (ESADD) defines and introduces a number of key concepts intended to ensure that security practitioners across the Government of Canada can have a shared vision of an integrated, secure and robust GC Enterprise IT infrastructure.
The ESADD and its associated annexes are intended to be a framework in support of consistent and systematic security definition, design, compliance and risk assessment for the GC IT/IS enterprise. The ESADD provides GC individuals involved in the ESA program, departmental security officials and practitioners, and IT/IS practitioners involved in system planning, development, and compliance assessment a general guideline of the security analysis, implementation and compliance management approach as part of the overall ESA framework. The document's purpose is:
- To develop a process for identifying and managing IT security requirements and ensuring alignment with business and IT,
- To identify security requirements aligned with GC security policy and enterprise objectives, and establish a minimum baseline security control profile for the GC,
- To develop enterprise-level security requirements that are decomposed into high-level sub-systems or enterprise security focus areas,
- To develop security architecture artifacts identifying key security capabilities, information flows, use cases, enterprise components, and resulting patterns,
- To provide artifact traceability to ensure that security requirements have been satisfied, that the selected controls are robust, and to identify any gaps and dependencies that need to be addressed, and
- To provide reusable security architecture artifacts for common solutions that depicts the allocation of security controls against enterprise capabilities and components.
Enterprise Security Architecture Overview
The enterprise security architecture considers security relevant aspects of the GC organization, operations, and the functionality, components, and relationships required to provide a secure GC enterprise. The views and narrative were developed without constraining the solution to fit within the bounds of currently deployed systems and solutions in the GC enterprise.
This approach provides a target architecture for the GC enterprise to shape the evolution of currently deployed IT systems and the associated personnel and processes towards a common, interoperable, consistent approach towards a secure enterprise based on best practices and application of appropriate security controls.
The goal of the ESA is to provide a framework to guide the future deployment of secure GC IT solutions with enough flexibility to allow the insertion of new technology as it becomes available. The ESA is expected to withstand the evolution of technical mechanisms without changes to the ESA framework. The ESADD Annexes discuss several technologies, some commonplace, some still very early in the development cycle. The internet of including these technologies is to show the different ways security could be implemented within the common ESA framework.
Mature information assurance concepts are included in the ESA from the beginning to avoid the temptation to deploy first and "bolt on" security later. The ESA supports the notion of defence-in-depth layered security and other best practices, such as separation of duties, least privilege, roots of trust, strong authentication, etc.
Several views and descriptions are included to provide different perspectives and methods for understanding the Enterprise Security Architecture in the context of the GC Enterprise. These views are intended to be used in concert to provide the greatest level of understanding to the implementers of secure GC IT solutions.
Relationship of the Architecture to Initiatives
The goal of the GC Enterprise Security Architecture (ESA) is to provide an architectural underpinning for the development of initiatives that result in the implementation of IT/IS capabilities. The relationship between architecture and initiatives is depicted in the image on the right. As shown, each initiative is defined by an Operational Concept (OpsCon) and, optionally, a High-Level Design (HLD) and Implementation Strategy. The architecture described in the ESADD and its annexes is used to inform the development of multiple initiatives. The architecture itself is driven by a set of Architectural Needs that identify strategic architectural objectives. As the architecture is not a system that needs to meet a set of system requirements, the Architectural Needs are written in an informal style (as opposed to formal "shall" statements) that are intended to inform, but not constrain development of the architecture.
Architecture needs are applicable GC-wide and are not specific to any initiative. They identify essential characteristics of the target GC Enterprise IT/IS Infrastructure as it undergoes transformation from its current state:
- Overarching concepts that are defined at a high enough level to be applicable GC-wide. Technical concepts include support for GC-wide consolidation, interoperability (internal and external), and hierarchical situational awareness. Non-technical concepts include risk management, supply chain integrity, and security awareness training.
- Guiding principles, in the form of laws, regulations, policy instruments, and government publications (such as Blueprint 2020), that define the desired approach to securing the GC Enterprise IT/IS Infrastructure. These artifacts may also identify constraints, particularly in the area of protecting the privacy of GC workers and other Canadian citizens.
The architecture is organized into a number of Enterprise Security Focus Areas (ESFAs), each of which is documented in an annex to the ESADD. The architectural needs have been developed independently of the ESFAs, but have been allocated to ESFAs. The architectural needs allocated to an ESFA are documented in the ESFA annex. Each Architectural Need may be allocated to more than one ESFA depending on its scope and applicability.
The Architectural Needs and their allocation to ESFAs are captured in the GC ESA Requirements Database. The database is described in the GC ESA Requirements Database Overview. A table listing the architectural needs identified for the ESA can be found in the ESADD.
Components of the GC Enterprise Security Architecture
When defining the state of the GC Enterprise Architecture from a security perspective, several aspects come into play. These aspects are collected into three major categories, as shown in the image on the right.
- Policy: The guiding principle and governance associated with the enterprise in general, and security in particular, are required to drive the GC Enterprise towards inherently secure people, processes, and technical solutions. Good Security policy is the foundation for security woven throughout the GC enterprise.
- People and Process: The people behind the business of the GC, including end users, contractors, suppliers, system administrators, security personnel, etc., are an important aspect of securing the GC enterprise. Staffing security-related roles with qualified personnel and training the enterprise GC population in security basics are a foundational necessity to rid the GC Enterprise of human-caused security incidents. The processes used by personnel are opportunities to weave security best practices into everyday operations to enable repeatable, secure behaviours, and workflows.
- Technology: For the professionals that design, implement, and maintain the vast GC IT/IS enterprise, this is the first security category that comes to mind and the initial focus of the ESADD. The hardware and software that constitute the GC IT/IS Enterprise is constantly changing due to the deployment of new capabilities, obsolescence of old ones, and the continuous pursuit for lower lifecycle costs. Integrated and standalone security mechanisms are part of this continuing renewal. The technology of the GC's IT/IS infrastructure is a great place to embed security in the enterprise to automate the protection of GC information. However, it is only fully effective if designed in an enterprise, end-to-end fashion and supported by the policies, people, and process of the other security categories.
All three aspects must be considered holistically to fully define the state of the ESA. The emphasis to date in the ESADD has been a subset of the technology aspect of the enterprise.
GC Enterprise Security Architecture End State and Transitions
The ESA has many facets that define a full architectural view of the GC Enterprise. The current state of GC enterprise security architecture, as well as the desired end state, must be defined in the context of all three aspects, as shown in the image on the left. Without the unique perspective offered by each of the three security considerations, a complete understanding and definition of the security architecture is not possible.
The effort to date has defined a subset of the technical aspects of the ESA. Therefore, as a placeholder, this section draws from the architectural views developed as part of the ESA annex work for the Endpoint Security (END), Network and Communications Security (NCS), Data Security (DAT), Security Operations (OPS), and Application Security (APP) Enterprise Security Focus Areas (ESFAs). As the remainder of the technical ESFAs are defined and the coverage of the ESADD is expanded into the non-technical ESFAs representing the people and process and policy aspects, a full enterprise architectural view will emerge.
The GC ESA Roadmap (GCER) discusses that the path ahead for the GC Enterprise can be described as the transition through three notional stages. The image on the right is aligned with the GCER and defines a notional progression of security maturity from the current state of GC Enterprise Security to the desired target state. The GCER and GC ESA Initiative Strategy look at progression in terms of implementable initiatives while the ESADD is focused on the progression of the overarching architectural concepts that drive the solutions generated by the initiatives.
Foundational State
The first state in the ESFA is the current focus of the IT Security Tripartite and the GC. Establishing a foundational security state is primarily driven by the adoption of security best practices for IT/IS design, deployment, and operations as captured in references, such as CSE Top 10 Security Actions and SANS Top 20 Critical Controls. Policy and governance establishes the roles and responsibilities for security personnel in the GC and drives the implementation of best practices. The best practices are augmented by the definition of enterprise security services required for trusted infrastructure and security mechanisms, such as global identity, authentication, access control, key management for encryption, and gateways to disruptive technologies, such as cloud computing. The technical aspects of the transition are discussed in each ESFA annex to the ESADD.
Improve and Extend State
Rigour, repeatability, enterprise focus, and the introduction of security metrics are the hallmarks of this interim state of security aspects. Policies drive the organization to capture the processes and procedures related to security and measure the results over time. The local control of security gives way to a hierarchical paradigm with control points at each level of the hierarchy. The flow of security information and events is consolidated to a common point to provide an enterprise view of the state of security in the GC and enhance the awareness and decision process for changes to the system operationally and strategically over time. Enterprise security services deploy in this state, providing services required to establish trust in transactions and the handling of sensitive GC information. The dynamic threat environment is continuously assessed and threat intelligence is used to drive security capabilities in the operational environment.
Comprehensive and Agile State
This final ESA state is driven by the automation of security processes, transparency of security mechanisms to the end users, and the collapse of infrastructure driven by anticipated changes in information protection. The loop from threat detection to vulnerability mitigation is compressed to near real time, allowing for the automated and nearly instant protection of the enterprise from the ever-changing threat environment. Sensitive GC information is protected at the data layer and processed on high trust devices, obviating the need for enclaves and internal boundary protections while ensuring protection of the information outside the direct control of the GC. Security metrics collection is pervasive and used to maintain security of deployed systems and drive the investment process for augmented and new capabilities. Security processes and procedures are fully documented, measured, and continuously optimized for efficiency and effectiveness. Security specialists are fully trained and qualified for security roles in the GC. The risk management process assesses, tracks, and reduces risks to the GC security state, including accepting risks associated with deploying new systems and continuing to operate existing systems.
Transitions
The transitions between ESA security states are driven by process in the three security aspects of policy, people and process, and technology. These three aspects will mature at different rates and are driven by the immediate needs and funding priorities of the GC and the priorities driven by the IT Security Tripartite and executives of the constituent departments. The technology-driven architectural transitions are captured at the ESFA level in the annexes to this document. These transitions typically show a handful of states and discuss the transitions between them. The technology maturity is driven by progress in the architectural transitions, as well as the technical initiatives defined in the GC Enterprise Roadmap.
The transitions in the policy and people and process aspects are captured in related artifacts from the IT Security Tripartite and departments and agencies of the GC. Progress in these areas is also driven by GCER initiatives and the associated implementation strategies.
The states presented here are not discrete. There is significant gray area in the transition from one state to the next. A more appropriate term may be "age" or "era". The transition from one state to the next is detectable only with a cross-cutting look at all aspects of security in the GC, the collection of security metrics and effectiveness data, and progress in each aspect area.
Enterprise Security Architecture Focus Areas
The focus areas that support the notion of the GC Enterprise Security Architecture are shown in the image below. Each circle represents a requisite part of the secure enterprise. The circles and their interdependencies provide the basis for the enterprise security architecture and represent collections of architectural components required for a secure enterprise. Definitions of the outer circles, or the technically-based Enterprise Security Focus Areas (ESFAs), are shown in a table below. Note the three-letter identifier trigraph associated with each ESFA, as these are used throughout the architectural views and narrative.
Definitions of the non-technical policy- and process-associated areas shown in the outer gray circle are considered non-technical Enterprise Security Focus Areas (ESFAs) and typify the management and operational aspects of security. These non-technical ESFAs are defined in a table in the ESADD.
The ESADD focuses on seven distinct technical ESFAs. Each technical ESFA has an associated annex which describes in further detail the security architecture considerations associated with that particular technical ESFA. The general description of each technical ESFA is provided in the table below. Where an annex has been completed for the technical ESFA, its relevant GCpedia page has been linked in the table (click on the name of the technical ESFA to be taken to the appropriate annex page). Please note that not all annexes may be complete as the ESADD is a living document undergoing constant development.
| Enterprise Security Focus Area (ESFA) | Trigraph | Description |
| Identity, Credential, and Access Management | ICA | Represents the functional elements supporting credentialing of users and non-person entities (NPEs), identification, authentication, and authorization (IA&A) of users and NPEs, key generation and distribution, as well as Attribute Based Access Control (ABAC) to GC Enterprise resources.
Represents the infrastructure components required for ICAM including Public Key Infrastructure, Key Management Systems, Identity Attribute Broker, Authentication Broker, and ABAC Policy Engine. |
| Security Operations | OPS | Represents the security policy-driven capabilities required for the day-to-day operations and maintenance of the GC Enterprise, encompassing operations typically performed in a Security Operations Centre (SOC) and/or Network Operations Centre (NOC). The objective of OPS is to ensure the secure state of the GC Enterprise by identifying exploitable weaknesses, detecting intrusions, responding to attacks, and recovering and evolving in order to prevent future attacks. |
| Endpoint Security | END | Represents the security capabilities of any computer attached to an IP network. Within the ESA, the scope of an endpoint is limited to the hardware platform and associated operating environment (operating system, virtual machine monitor, etc.). Endpoints are used to host functional capabilities defined by other ESFAs. |
| Network and Communications Security | NCS | Represents network-specific security capabilities including switching, routing, VPN, firewall, and intrusion detection/prevention functions. NCS supports multiple security domains, includes proxy functionality for external access to GC Resources, terminates secure sessions with client and server endpoints, and arbitrates access to network resources. |
| Applications Security | APP | Represents secure application architectures including secure communications between application services, secure service discovery, application support for centralized authentication and authorization, and business process automation. |
| Data Security | DAT | Represents the complement of security services required to secure data throughout the GC Enterprise including enforcement of secure access to storage and database infrastructure, trusted labeling and tagging in support of data provenance,access control, and data handling requirements of the information owner/steward, encryption for confidentiality and integrity protection of data and strong binding of metadata to data objects, and enforcement of Information Rights associated with licensed or otherwise restricted data. |
| Computer and Storage Services Security | CSS | Represents services within the data centre supporting reliable and available execution of application services. Includes dynamic service provisioning and scheduling, load balancing, resiliency, and supporting back-end data access services. Provides the cloud computing characteristics of on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. |
Each ESFA further decomposes into architectural components that represent collections of security and enterprise IT functionality. The image below shows the mapping of architectural components to Enterprise Security Focus Areas.
This mapping will be used throughout the architectural description. The components shown in the mapping view are described throughout the subsections beginning with the Endpoint Security Architecture focus area. It is important to note that these architectural components do not necessarily align with physical and virtual IT components and appliances, but instead reflect collections of related functionality or capabilities. The functionality represented by each component is elaborated in the ESADD and in the annexes devoted to each ESFA.
Enterprise Security Architecture Technical Components
Below are descriptions of the technical components for each ESFA. Click 'Expand' for more information on the technical components of each ESFA.
Endpoint Security (END) ESFA
Endpoint Security (END) ESFA
The Endpoint Security (END) Enterprise Security Focus Area (ESFA) represents IP-enabled physical and virtual computing platforms that consist of hardware and its associated operating environments. The operating environment includes operating systems, virtual machine managers (hypervisor, microvisor), and utility software. Utility software include web browsers that essentially act as containers for downloadable mission-specific functionality. Mission-specific capabilities hosted by the endpoint defined in other ESFAs. In particular, the NCS, OPS, and ICA ESFAs define a number of mission-specific functions hosted by endpoints.
General-purpose platforms that host functions not specific identified by this architecture (for example, the APP ESFA) are characterized as client endpoints (directly accessed by the end user) and server endpoints (usually resident in a GC data centre or cloud provider). Endpoint can be further characterized as follows:
- Client Endpoint (workstation, desktop, tablet, smartphone, etc.)
- Server Endpoint (application server, database server, file server, etc.)
- Network Endpoint (switch, router, network security appliance, etc.)
- Network-Attached Peripheral Endpoint (printer, scanner, etc.)
- Hybrid Endpoint that relays network traffic, but also provides application functionality (application proxy, email relay/server, etc.)
The image on the right shows the components used to define the END EFSA. The components are intended to represent the superset of functionality required by a wider range of endpoint form factors and characteristics.
Descriptions of each of these components, including key interfaces with elements of the GC Enterprise are shown in a table in the ESADD. The list of example technologies for each component contains examples of the types of technical solutions that embody the functions of the component.
Identity, Credential, and Access Management Security (ICA) ESFA
Identity, Credential, and Access Management Security (ICA) ESFA
The Identity, Credential, and Access Management (ICA) ESFA includes the infrastructure services required to create and manage GC Enterprise credentials and associated tokens, identify, and authenticate users and non-person entities (NPEs), authorize, control access to GC protected resources, and create and manage keys for use in credential and encryption services. The image on the left shows the components used to define the ICA ESFA.
Descriptions of each of these components, including key interfaces with elements of the GC Enterprise are shown in a table in the ESADD. The list of example technologies for each component contains examples of the types of technical solutions that embody the functions of the component.
Network and Communications Security (NCS) ESFA
Network and Communications Security (NCS) ESFA
The Network and Communications Security (NCS) ESFA contains components for providing GC Enterprise network services, terminating and proxying remote connections, protecting network and application flows, protecting inter-domain communications, and network attached peripheral devices. The image on the right shows the components used to define the NCA ESFA.
Descriptions of each of these components, including key interfaces with elements of the GC Enterprise are shown in a table in the ESADD. The list of example technologies for each component contains examples of the types of technical solutions that embody the functions of the component.
Compute and Storage Services Security (CSS) ESFA
Compute and Storage Services Security (CSS) ESFA
The Compute & Storage Services Security (CSS) ESFA contains components for providing information system infrastructure to support the computing needs of the GC Enterprise. The image on the left depicts the components used to define the CSS ESFA.
Descriptions of each of these components, including key interfaces with elements of the GC Enterprise are shown in a table in the ESADD. The list of example technologies for each component contains examples of the types of technical solutions that embody the functions of the component.
Data Security (DAT) ESFA
Data Security (DAT) ESFA
The Data Security (DAT) ESFA provides supplemental security services to the Compute & Storage Services Security (CSS) ESFA and the Application Security (APP) ESFA. It includes data labelling and marking, provenance, information handling and rights controls, and encryption for the information systems within the GC Enterprise. The image on the right depicts the components used to define the SAD ESFA.
Descriptions of each of these components, including key interfaces with elements of the GC Enterprise are shown in a table in the ESADD. The list of example technologies for each component contains examples of the types of technical solutions that embody the functions of that component.
Application Security (APP) ESFA
Application Security (APP) ESFA
The Application Security (APP) ESFA represents the application environment in the GC Enterprise. The APP ESFA provides applications services to the GC Enterprise and manages the applications lifecycle in the production environment. The APP ESFA is supported by non-technical Security in Acquisition (ACQ) ESFA non-technical components. The image on the left depicts the APP ESFA technical components and the non-technical acquisition components that support the technical components.
Descriptions of each of these technical components, including key interfaces with elements of the GC Enterprise are shown in a table in the ESADD. The list of example technologies for each component contains examples of the types of technical solutions that embody the functions of that component.
Security Operations (OPS) ESFA
Security Operations (OPS) ESFA
The Security Operations (OPS) ESFA represents the functions required for the day-to-day operations and maintenance of the GC Enterprise. The OPS ESFA encompasses operations typically performed in a network operations centre (NOC) and security operations centre (SOC). The OPS ESFA provides the management of devices, managed elements, hardware and software components in the following areas (commonly abbreviated to "FCAPS"):
- Fault Management: Detect, isolate, correct, and log faults
- Configuration Management: Maintain authoritative source of software and configuration data for the enterprise, maps to assets, pushes software, OS, firmware, and configuration changes to elements of the enterprise, and validates element configurations
- Accounting Management: Collect usage statistics by resource
- Performance Management: Measure the efficiency of the enterprise, track system health, and trend key metrics
- Security Management: Event collection and security configuration in response to threats and detected incidents
From a GC Enterprise standpoint, OPS provides threat detection, policy deployment and violation detection, monitoring/diagnostics of security events, anomaly analytics identifying indicators of compromise, as well as asset, configuration, and audit management capabilities. The image on the right depicts the components used to define the OPS ESFA. Descriptions of each of these components, including key interfaces with elements of the GC Enterprise are shown in a table in the ESADD. The list of example technologies for each component contains examples of the types of technical solutions that embody the functions of that component.
Non-Technical Components
The following non-technical ESFAs were create to support the technical ESFAs. These non-technical components will be addressed as required to support the technical ESFAs.
- Personnel Security (PER)
- Business Continuity (BCP)
- Security in Acquisition (ACQ)
- Physical Security (PHY)
- Awareness and Training (AAT)
- Risk Management (RMT)
Enterprise Security Capability Mapping
CSEThis section outlines the relationships between SANS Top 20 Critical Controls and the GC Enterprise Security Focus Areas, providing GC Security Architects and Professionals with a mapping of the associated ITSG-33 controls that should be considered in support of securing GC’s IT/IS Consolidated Enterprise.
The SANS’ NIST control mapping is based upon what SANS considers to be most important. When compared with GC prioritization for a Protected B environment (PB/Medium/Medium, ITSG-33 Annex 4-Profile 1), several of the controls listed by SANS are not selected. Also several applicable controls that are selected in the Protected B profile are not part of the SANS mapping.
To address the differences between the SANS’ NIST and GC’s Protected B controls prioritization, it was determined that the SANS mapping be retained and additional GC Protected B priority controls be included. The result is a superset of priority controls inclusive of both the SANS’ NIST baseline and GC’s ITSG-33 PB/Medium/Medium (PBMM) controls.
Click 'Show/Montre' on the table below to see the mapping of the SANS Top 20 Critical Controls area and associated ITSG-33 security controls to the various Enterprise Security Focus Areas. The mapping table column definitions are as follows:
- SANS – one of the Top 20 SANS Critical Controls area.
- Description – SANS’ description for the given 20 Critical Controls area.
- NIST Controls – SANS’ mappings of the NIST SP 800-53 Rev. 3 controls for the given Critical Controls area.
- ITSG-33 Controls (PBMM) – recommended additional GC ITSG-33 controls from PBMM profile for a Protected B environment that are not included in the SANS Critical Controls mapping.
- Additional ITSG-33 Controls – additional ITSG-33 controls that are considered relevant in the context of the GC Enterprise. Controls that were not included in the SANS or the ITSG-33 PBMM profile.
- Consolidated List – combined list inclusive of SANS’ NIST SP 800-53 Rev. 3 and GC’s ITSG-33 priority controls for the given SANS Critical Controls area.
- ESFA – the Enterprise Security Focus Areas mapped to the given SANS Critical Controls area.
| Enterprise Security Capability Mapping | ||||||
|---|---|---|---|---|---|---|
| SANS | Description | NIST controls | ITSG-33 Controls (PBMM) | Additional ITSG-33 Controls | CSE Top 10 | ESFA |
| 1 | Inventory of Authorized and Unauthorized Devices | CA-7, CM-8, IA-3, SA-4, SC-17, SI-4, PM-5 | CA-7, CM-8, IA-3, SA-4, SI-4 | PM-5 | #7: Manage devices at enterprise level | EUD, NCS, CSS, OPS |
| 2 | Inventory of Authorized and Unauthorized Software | CA-7, CM-2, CM-8, CM-10, CM-11, SA-4, SC-18, SC-34, SI-4, PM-5 | CA-7, CM-2, CM-8, CM-10, CM-11, SA-4, SC-18, SI-4 | SC-34, PM-5 | #10: Implement application whitelisting | APP, OPS |
| 3 | Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers | CA-7, CM-2, CM-3, CM-5, CM-6, CM-7, CM-8, CM-9, CM-11, MA-4, RA-5, SA-4, SC-15, SC-34, SI-2, SI-4 | CA-7, CM-2, CM-3, CM-5, CM-6, CM-7, CM-8, CM-9, CM-11, MA-4, RA-5, SA-4, SC-15, SI-2, SI-4 | SC-34 | EUD, NCS, APP, CSS, PCM, ICA, OPS | |
| 4 | Continuous Vulnerability Assessment and Remediation | CA-2, CA-7, RA-5, SC-34, SI-4, SI-7 | CA-2, CA-7, RA-5, SI-4, SI-7 | SC-34 | PCM | |
| 5 | Controlled Use of Administrative Privileges | AC-2, AC-6, AC-17, AC-19, CA-7, IA-4, IA-5, SI-4 | AC-2, AC-6, AC-17, AC-19, CA-7, IA-4, IA-5, SI-4 | #3: Enforce Management of Administrative Privileges | EUD, NCS, APP, ICA | |
| 6 | Maintenance, Monitoring, and Analysis of Audit Logs | AC-23, AU-2, AU-3, AU-4, AU-5, AU-6, AU-7, AU-8, AU-9, AU-10, AU-11, AU-12, AU-13, AU-14, CA-7, IA-10, SI-4 | AU-2, AU-3, AU-4, AU-5, AU-6, AU-7, AU-8, AU-9, AU-11, AU-12, CA-7, SI-4 | AC-23, AU-10, AU-13, AU-14, IA-10 | DAT, CSS, OPS | |
| 7 | Email and Web Browser Protections | CA-7, CM-2, CM-3, CM-5, CM-6, CM-7, CM-8, CM-9, CM-11, MA-4, RA-5, SA-4, SC-15, SC-34, SI-2, SI-4 | CA-7, CM-2, CM-3, CM-5, CM-6, CM-7, CM-8, CM-9, CM-11, MA-4, RA-5, SA-4, SC-15, SI-2, SI-4 | SC-34 | #9: Isolate web-facing applications
#5: Segment and separate information |
|
| 8 | Malware Defences | CA-7, SC-39, SC-44, SI-3, SI-4, SI-8 | CA-7, SI-3, SI-4, SI-8 | SC-39, SC-44 | #1: Use Shared Services Canada (SSC) Internet gateways
#4: Harden Operating Systems (OSs) #8: Apply protection at the host level #9: Isolate web-facing applications |
PCM, CSS, NCS, OPS, EUD |
| 9 | Limitation and Control of Network Ports, Protocols, and Services | AT-1, AT-2, AT-3, AT-4, SA-11, SA-16, PM-13, PM-14, PM-16 | AT-1, AT-2, AT-3, AT-4, SA-11, SA-16 | PM-13, PM-14, PM-16 | #4: Harden Operating Systems (OSs)
#8: Apply protection at host level #9: Isolate web-facing applications |
NCS, CSS, EUD, OPS |
| 10 | Data Recovery Capability | CP-9, CP-10, MP-4 | CP-9, CP-10, MP-4 | DAT, CSS, EUD, OPS | ||
| 11 | Secure Configurations for Network Devices such as Firewalls, Routers, and Switches | AC-4, CA-3, CA-7, CA-9, CM-2, CM-3, CM-5, CM-6, CM-8, MA-4, SC-24, SI-4 | AC-4, CA-3, CA-7, CA-9, CM-2, CM-3, CM-5, CM-6, CM-8, MA-4, SC-24, SI-4 | #4: Harden Operating Systems (OSs)
#8: Apply protection at host level |
NCS, OPS, PCM | |
| 12 | Boundary Defence | AC-4, AC-17, AC-20, CA-3, CA-7, CA-9, CM-2, SA-9, SC-7, SC-8, SI-4 | AC-4, AC-17, AC-20, CA-3, CA-7, CA-9, CM-2, SA-9, SC-7, SC-8, SI-4 | #1: Use Shared Services Canada (SSC) Internet gateways
#4: Harden Operating Systems (OSs) #5: Segment and separate information #8: Apply protection at host level |
NCS, PCM, OPS | |
| 13 | Data Protection | AC-3, AC-4, AC-23, CA-7, CA-9, IR-9, MP-5, SA-18, SC-8, SC-28, SC-31, SC-41, SI-4 | AC-3, AC-4, CA-7, CA-9, IR-9, MP-5, SA-18, SC-18, SC-28, SI-4 | AC-23, SC-31, SC-41 | #5: Segment and separate information | DAT, NCS |
| 14 | Controlled Access Based on the Need to Know | AC-1, AC-2, AC-3, AC-6, AC-24, CA-7, MP-3, RA-2, SC-16, SI-4 | AC-1, AC-2, AC-3, AC-6, CA-7, MP-3, RA-2, SI-4 | AC-24, SC-16 | #3: Enforce management of administrative privileges
#5: Segment and separate information #10: Implement application whitelisting |
DAT, NCS, ICA, APP |
| 15 | Wireless Access Control | AC-18, AC-19, CA-3, CA-7, CM-2, IA-3, SC-8, SC-17, SC-40, SI-4 | AC-18, AC-19, CA-3, CA-7, CM-2, IA-3, SC-17, SI-4 | SC-40 | #1: Use Shared Services Canada (SSC) Internet gateways
#10: Implement application whitelisting |
NCS, OPS, EUD, ICA, DAT |
| 16 | Account Monitoring and Control | AC-2, AC-3, AC-7, AC-11, AC-12, CA-7, IA-5, IA-10, SC-17, SC-23, SI-4 | AC-2, AC-3, AC-7, AC-11, CA-7, IA-5, SC-17, SC-23, SI-4 | AC-12, IA-10 | #3: Enforce management of administrative privileges | ICA |
| 17 | Security Skills Assessment and Appropriate Training to Fill Gaps
(Data Loss Prevention) |
AT-1, AT-2, AT-3, AT-4, SA-11, SA-16, PM-13, PM-14, PM-16 | AT-1, AT-2, AT-3, AT-4, SA-11, SA-16 | PM-13, PM-14, PM-16 | #6: Provide tailored awareness and training | OPS
(DAT, NCS, PCM) |
| 18 | Application Software Security | SA-13, SA-15, SA-16, SA-17, SA-20, SA-21, SC-39, SI-10, SI-11, SI-15, SI-16 | SA-15, SA-16, SA-17, SI-10, SI-11, SI-16 | SA-13, SA-20, SA-21, SC-39, SI-15 | #2: Patch operating systems (OSs) and applications
#9: Isolate web-facing applications #10: Implement application whitelisting |
APP, PCM, OPS |
| 19 | Incident Response and Management | IR-1, IR-2, IR-3, IR-4, IR-5, IR-6, IR-7, IR-8, IR-10 | IR-1, IR-2, IR-3, IR-4, IR-5, IR-6, IR-7, IR-8, IR-10 | OPS | ||
| 20 | Penetration Tests and Red Team Exercises | CA-2, CA-5, CA-6, CA-8, RA-6, SI-6, PM-6, PM-14 | CA-2, CA-5, CA-6, CA-8 | RA-6, SI-6, PM-6, PM-14 | OPS | |
SANS Top 20 Capability Area to ESFA Mapping Rationale
To understand the rationale behind the selected GC IT/IS Enterprise Security Focus Areas for the given SANS Top 20 Critical Controls, please read the SANS Top 20 Critical Controls Overview and SANS Top 20 Critical Controls Document. For more controls mapping with the SANS Top 20 Controls, please see the SANS CIS Critical Security Controls Poster.
_ESFA_Components.PNG){kind=link}