7.1. Security-by-Design Name: Security-by-Design Statement: Enable and protect activities and assets of both people and enterprises are built-in to any business practice and corresponding IT solution Rationale: • ESDC’s IM/IT assets are protected against theft, loss, damage, or unauthorized modification, destruction or disclosure to assure public confidence in the Department. • When security protection for confidentiality, availability and integrity are considered up front., it is more cost effective and results are more robust and resilient. Implications: • Controls for the protection of confidentiality, integrity and availability must be designed into all aspects of solutions from initiation, not as an afterthought. • Security must be designed in the business processes within which an IT system will be used. • ESDC’s business solutions must be compliant with the Privacy Act; MITS; ATIP policies; FAA, etc. • Security requirements must be determined with all stakeholders. • Business driven security requirements based on legislation, policies, and business needs must be supported. • A consistent, trusted and effective security model must be developed for use across all applications, data, systems, and infrastructure. • Security Assessment and Audit (SA&A) , and Statement of Sensitivity (SoS) processes shall be used to identify threats and risks and select cost effective controls which meet control objectives. • A Vulnerability Assessment (VA) process shall be used to identifying and quantifying vulnerabilities in a system. • Program managers need to have business impact analysis and business continuity planning processes developed and implemented. • Program managers need to be part of the process to conduct the business impact analysis and to select contingency and business continuity plans. • Business impact analysis should be coordinated with value/risk analysis to identify potential countermeasures to exposures to the ESDC during the design of new business processes. • A controlled variance process must be adhered to. • Accountable parties are responsible for establishing or aligning to authorised purposes for their assets • Risk tolerances, breach mitigation and breach outcomes must be clearly defined beforehand. • Ethically and legally, ESDC is obligated to protect Information / Data under its care to retain the right to manage and use it. • Information / Data are sheltered from unauthorised access, modification, use, disclosure or destruction. • Intellectual property and confidentiality is safeguarded. • Sharing must be balanced against classification, proprietariness or sensitivity of Information / Data. • Aggregation of Information / Data, such as for residual data must also be reviewed for sensitivity. • Security must be applied at the appropriate level, i.e., data level versus application level. • Systems and Information / Data must be safeguarded from malevolent intentions and disaster. • Emerging technologies such as cloud and data lakes, must be accounted for in modernised policies, standards and practices, and user awareness and training. • Anonymization or masking techniques may be necessary and utilised before permitting certain access. • Security controls must not hinder appropriate and timely access and sharing of assets s (e.g. Information / data). GC Security Architecture • Information categorization – As the originator of a record, each department is responsible for a plan, the implementation of information categorization systems and the review of data and information prior to release on the Open Government Portal (the “Portal”) • Should it be third-party information (government to government, government to industry, other), additional release mechanisms are up to department review • Training and awareness on the requirements of the Portal is needed (to reduce additional work for other departmental stakeholders such as ATIP officer or Privacy analysts) • Departments are also responsible to review the metadata and telemetry of datasets, to reduce the risk that combining smaller pieces of the data can enable a malicious user to action one of the risk scenarios • Legal and policy framework – Departments must continue to observe all domestic and international laws as they relate to handling resources, and should be respectful when considering which resources are being shared and released on the Portal • Respect for privacy and persons – Departments must protect personal information by not releasing it on the Portal • Departments must ensure that all data and information released on the Portal contains no personal information or is properly de-identified/anonymized • Departments should be transparent about how data and information will be collected, used and shared on the Portal • Within an “Open by Default” environment, departments must identify situations and datasets which cannot be released or be made open by design • Forward planning – Departments should consider privacy and security when releasing records on the Portal. Considerations should include: • Consulting internally with business line and data / information owners / stewards to identify risks associated to the public, the organizations and the government as a whole • Assessing privacy and security on an ongoing basis, as due diligence does not end with uploading a record but rather an ongoing responsibility to maintain the accuracy and completeness of all records • Making plans prior to the release of records for their maintenance and periodic reviews of the privacy and security implications of the universe of relevant records available on the Portal • Assigning clear accountabilities within departments and agencies for considering privacy and security implications of open government records • Security and Privacy Incidents and Remediation – Departments and agencies will take steps to ensure their ability to respond effectively in the case of a privacy or security incident • In the event of any real or suspected security incidents, departments and agencies will respond in accordance with the Directive on Departmental Security Management (DDSM), departmental and agency processes and procedures, and when applicable the Cyber Security Event Management Plan (GC CSEMP) • In the event of any real or suspected privacy breach, departments and agencies will respond in accordance with the Directive on Privacy Practices. Departments and agencies should apprise themselves of TBS Guidelines for Privacy Breaches and the Privacy Breach Management Toolkit. These privacy instruments identify causes of privacy breaches, provide guidance on how to respond, contain and manage privacy breaches, delineate roles and responsibilities, and include links to relevant supporting documentation • Considerations for maximizing release – When considering de-identifying information and data, the following should be noted: • De-identification needs to be done by trained officials • Software for de-identification is not always available and may need to be developed • Effective de-identification may reduce the granularity of records and, as a result, data and information quality may decrease • De-identification can be costly and require significant investments of resources, time, and data processing • Extrapolation or aggregation risks may persist in spite of de-identification efforts References: • Canada Border Services Agency (CBSA) defined Architecture Principles • CDO • See decomposition in Open Web Application Security Project (OWASP) • GC Security and Privacy Guidelines- https://gcconnex.gc.ca/file/download/29788569