Language selection

Government of Canada / Gouvernement du Canada

Search

CDS Platform Security 

Last updated: 12-07-2023

Provides an overview of CDS security practices  and compliance for our internal assets and products. 

Executive Summary

Security is important to us at the Canadian Digital Service. CDS is housed within Employment and Social Development Canada (ESDC). All our operations, including our Platform Products, meet the Government of Canada policies, directives, and guidance on security, as well as industry best practices. We work at the intersection of  traditional government IT development and new methods and practices, delivering high quality, secure products that other government departments and agencies, and the public, can trust. We include humans at the heart of security and not just technology.

This document provides an overview of CDS security practices, including: 

  • Compliance with federal policies, directives, and guidelines 
  • How we handle our hardware and software assets at CDS
  • Our infrastructure on AWS 
  • Compliance with ITSG-33 and and our Authority to Operate (ATO) process
  • Commitment to penetration testing
  • Incident management process
  • Industry best practices we follow beyond compliance
  • How we foster an organizational security culture

More information on product specific security and privacy practices is available in individual product documentation. Security-specific questions can be directed to CDS.SECURITY-SECURITE.SNC@servicecanada.gc.ca.

Policy Compliance

CDS Platform meets all federal policies, directives, and guidelines for security. This includes:

Asset Management: How we manage our assets and data 

Our ESDC-provided hardware (tablets and phones) are managed by ESDC. We commit to using asset management for our hardware and software that isn’t managed by ESDC in order to meet security requirements. In addition to our ESDC devices, we also use a variety of Apple Macbook models for development and business work. We use the following tools to manage these assets:

  • Jamf Pro integration: allows for  the automatic import/sync of all hardware (Apple MacBook devices) assets into AssetSonar which we also use to track other peripherals (monitors, docks, etc.). Jamf Pro and mobile device management captures all software installed locally on devices and uploads to AssetSonar database. 
  • AssetSonar: is both a hardware and software asset discovery tool. While it does not integrate with Sentinel, it does so with Jamf Pro and Google Workspace.
  • Security Information and Event Management (SIEM): a security management system that collects and analyzes log data from various sources, such as network devices, servers, and applications. It’s a way to centralize information to identify threats, provide alerts and reports, and provide automations to quickly respond to incidents.
    • Sentinel: collects data at cloud scale across all users, devices, applications, and infrastructure, in multiple clouds.
  • Google Workspace: Our use of Google Workspace includes capturing all cloud SaaS products logged into with an @cds-snc.ca
  • Password manager: CDS employees use an encrypted password manager to securely store user login details, enabling the use of strong and unique passwords for each account. The password manager is also secured physically with a Yubikey for 2FA. 
  • Two-factor authentication (2FA): We use an extra layer of protection beyond a username and password to secure and authenticate CDS user accounts (e.g. Google, AWS, etc). 
  • Yubikey: Every CDS employee has a physical Yubikey (usb-c) for hardware authentication. 
  • Helpdesk tools: We use HappyFox for our ticket management system to handle staff inquiries about assets so that corporate knowledge does not get lost.
  • Centralized code management: We use Github to manage versioning and to retain centralized copies of our code. This is backed up into AWS in case of outages. 
  • Supply chain management: We manage our Software-as-a-service (SAAS) using an asset management process. We are working on a bespoke application to improve the current process.

Infrastructure on AWS

CDS uses Amazon Web Services (AWS) infrastructure. Under the Directive on Service and Digital federal data (up to Protected B) can be stored outside of Canada as long as Canadian options were evaluated first. At CDS data residency (data at rest) for our products remains in Canada. 

These products have Shared Services Canada (SSC) guardrails designed to create a Protected B medium availability, medium integrity (PBMM) environment.

Some AWS services that we use are global (e.g. user ID and access management), meaning that their servers are outside of Canada. However, this only affects CDS staff members and not government clients or members of the public using our products. We follow the principle of least privilege and restrict access to our infrastructure on AWS. 

Compliance

Each of our CDS products follow the government of Canada’s Authority to Operate (ATO) process: an official management decision given by a senior organizational person to authorize operation of a system and to explicitly accept the risks of doing so based on the implementation of an agreed-upon set of security controls. We also conduct an interim authority to operate process (iATO) when products are in MVP or development.  The ATO process does not end after management approval — it is a continuous process that we consistently monitor.

Security compliance frameworks are used to help government departments ensure security is considered right from the start, helping the process to obtain and maintain an ATO. Following the Canadian Centre for Cyber Security’s ITSG-33 guidance, we select the relevant controls that apply to each product we build. CDS products are all based in the cloud: this means that we have less physical hardware considerations because we are not tied to one facility or cloud service. As a result, a Protected B, Medium Integrity, Medium Availability (PBMM) profile is reduced to around 90 controls. We are working towards a more streamlined process to choose controls sorted by type (e.g. organization-wide vs product-specific), and define how to satisfy them (see ITSG-33 Yaml Explorer, ESDC for an example of how other departments have achieved this).

In addition to this, all federal cloud-based products participate in the Canadian Centre for Cyber Security (CCCS)’s Cloud-Based Sensor program as a second line of defence. We send our firewall and access logs to be part of a network that watches all cloud operations across multiple vendors, helping to catch distributed attacks and prevent similar attacks in the Government of Canada.

Penetration Testing

CDS is committed to a cadence of internal and external penetration testing. “Pentesting” is a security exercise where cybersecurity experts attempt to find and exploit vulnerabilities. Pentesting in the Government of Canada fulfills certain security controls in ITSG-33, as well as the Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN). CDS has a Security Notice and Vulnerability Reporting Tool for CDS products. At CDS, there is a dedicated cyber security team that assesses and triages all reported vulnerabilities, as well as security-conscious people across the organization that support this indirectly.

Incident Management

When something goes wrong, whether it’s a security breach, an outage or a broken feature, team members need to respond immediately and restore service. This process is called incident management. CDS has an organization-wide incident response culture and process that is practiced regularly to encourage openness. This is facilitated through the use of the blameless post-mortem process. We improve services by holding teams accountable, not by apportioning blame. It is a keystone of openness and ensuring psychological safety.

Our incident management process at CDS is based on the Government of Canada Cyber Security Event Management Plan (GC CSEMP). We base our Incident Management Handbook on it which outlines the stakeholders and actions required to ensure that incidents are addressed in a consistent, coordinated, and timely fashion CDS-wide. The handbook is tested and reviewed frequently, and modified as required. Our incident response is not just limited to security and technology incidents, we encourage every incident at CDS to run this way, such as identifying missed steps in non-technical procedures. 

When there is a significant security or privacy incident on our products, we notify our clients about incidents in a timely manner. The Incident Commander works together with the Incident Outreach and Policy leads to develop plain-language summaries and communications to users and stakeholders. In addition to this, we follow TBS established guidance and tools in the event of a privacy breach to assess and contain, notify clients and relevant partners, and to mitigate and prevent future incidents.

Industry Best Practice

We apply industry best practice at CDS using standard tools and processes. These include developer security training, patch management, code analysis, testing, among others.  

Some processes at CDS include:

  • Patch management guideline for CDS products: This is the first step in the GC CSEMP. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Applying patches (security updates, etc.) at the earliest possibility limits exposure to software vulnerabilities. 
  • Developer security training: we use a hands-on real-world platform to train developers on recognizing common security exploits in code and how to mitigate them.

Some tools that we use at CDS include:

  • Automatic website scanning: a CDS-built tool that scans websites for security vulnerabilities and accessibility issues. Issues are automatically exported to Azure Sentinel for visualization and triage.
  • Static analysis: A way of examining the code without executing the program like proofreading
    • Linting: Automatic review for common programmatic or stylistic errors.
  • Code review: A manual process that has one human reviewer (at minimum) that reviews the code and can make suggestions before it’s accepted. 
  • Testing: We encourage teams to write meaningful tests against their code and integrate them into their release pipeline.

Culture

We practice continuous security at CDS for our products and greater organization. We embed security and policy specialists on our team and treat security priorities and requirements as design constraints. We use automation and metrics to facilitate security operations. As part of this, we organize and offer regular training to our security team, developers, and other staff to learn or brush up on relevant skills. 

Date modified: