Note to readers

This publication does not currently meet the Government of Canada's Web Standards. The information remains valid.

Annex 4A - Profile 1 - (PROTECTED B / Medium integrity / Medium availability) (ITSG-33)

From: Canadian Centre for Cyber Security

 

Alternate format: Annex 4A - Profile 1 - (PROTECTED B / Medium integrity / Medium availability) (ITSG-33) (PDF, 1.73 MB)

Suggested organizational security control profile for departments and agencies requiring protection of business activities of security category - Protected B / Medium integrity / Medium availability

January 2015

 

Table of Contents

List of Tables

List of Abbreviations and Acronyms

CC
Common Criteria
CMVP
Cryptographic Module Validation Program
COTS
Commercial off the Shelf
CSE
Communications Security Establishment
DSO
Departmental Security Officer
GC
Government of Canada
ISSIP
Information System Security Implementation Process
IT
Information Technology
ITSG
Information Technology Security Guidance
PDARR
Prevention Detection Analysis Response Recovery
SAL
Security Assurance Level
TBS
Treasury Board of Canada Secretariat

Foreword

Annex 4A – Profile 1 (Protected B / Medium Integrity / Medium Availability) to IT Security Risk Management: A Lifecycle Approach (ITSG-33) is an unclassified publication issued under the authority of the Chief, Communications Security Establishment (CSE).

Suggestions for amendments should be forwarded through departmental communications security channels to your Information Technology (IT) Security Client Services Representative at CSE.

Requests for additional copies or changes in distribution should be directed to your IT Security Client Services Representative at CSE.

For further information, please contact CSEC’s IT Security Client Services area by e-mail at itsclientservices@cse-cst.gc.ca, or call 613-991-7654.

Effective Date

This publication takes effect on 20 January 2015.

Originally signed by

Toni Moffa

Deputy Chief, IT Security

Summary

This Annex is part of a series of documents published by the Communications Security Establishment (CSE) under Information Technology Security Guidance Publication 33 (ITSG-33), IT Security Risk Management: A Lifecycle Approach.

This Annex suggests a selection of security controls and control enhancements, together referred to as a security control profile. Departmental security authorities can use this profile as a reference to create departmental-specific security control profiles suitable for protecting the confidentiality, integrity, and availability of departmental information technology (IT) assets against threats that could cause injury to business activities of category PROTECTED B / Medium Integrity / Medium Availability. This security control profile has been developed using ITSG-33 Annex 3A, Security Control Catalogue [Reference 1].

The suggested security controls in this profile constitute a starting point and need to be tailored to the business, technical, and threat and risk context of each department’s business activities and supporting information systems. The selection of security controls was based on industry and governmental security best practices, and under certain threat assumptions, derived from CSE’s analysis of the threat environment faced by information systems in the documented business context.

This profile has been created as a tool to assist security practitioners in their efforts to protect information systems in compliance with applicable Government of Canada (GC) legislation and Treasury Board of Canada Secretariat (TBS) policies, directives, and standards.

It is the responsibility of departmental security authorities, when developing their departmental security control profiles, to ensure compliance to all security requirements of GC regulations and TBS policy instruments applicable to their business activities as well as any other contractual obligations.

1 Introduction

1.1 Purpose

This Annex is part of a series of documents published by the Communications Security Establishment (CSE) under Information Technology Security Guidance Publication 33 (ITSG-33), IT Security Risk Management: A Lifecycle Approach.

This Annex suggests a selection of security controls and control enhancements, together referred to as a security control profile. Departmental security authorities can use this profile as a reference to create departmental-specific security control profiles suitable for protecting the confidentiality, integrity, and availability of departmental information technology (IT) assets against threats that could cause injury to business activities of category PROTECTED B / Medium Integrity / Medium Availability. This security control profile has been developed using ITSG-33 Annex 3A, Security Control Catalogue [Reference 1].

Departmental security control profiles help ensure that the IT security function of a departmental security program can:

  1. perform appropriate IT security risk management activities; and
  2. provide adequate support to IT projects.

1.2 Scope and Applicability

The suggested security controls in this profile constitute a starting point and need to be tailored to the business context, technical context, and threat and risk context of each department’sFootnote 1 business activities and supporting information systems (as described in Section 2). The selection of security controls was based on industry and governmental security best practices, and under certain threat assumptions, derived from CSE’s analysis of the threat environment faced by information systems in the documented business context.

This profile does not provide details about the implementation or utilization of these security controls in a department or its information systems. ITSG-33 Annex 1 – Departmental IT Security Risk Management Activities [Reference 2] and Annex 2 – Information System Security Risk Management Activities [Reference 3] provide more detail guidance on these topics. Refer to CSE’s website for a current list of additional guidance publications.

1.3 Audience

This Annex is intended for:

  • Departmental security officers (DSOs), IT security coordinators, and security practitioners supporting departmental IT security risk management activities; and
  • Participants in the definition, design, development, installation, and operations of information systems, more specifically authorizers, project managers, security architects, security practitioners, security assessors, and members of IT operations groups.

1.4 Publication Taxonomy

This Annex is part of a suite of documents on IT security risk management in the GC. The other documents in the series are as follows:

  • ITSG-33, Overview – IT Security Risk Management: A Lifecycle Approach
  • ITSG-33, Annex 1 – Departmental IT Security Risk Management Activities
  • ITSG-33, Annex 2 – Information System Security Risk Management Activities
  • ITSG-33, Annex 3A – Security Control Catalogue
  • ITSG-33, Annex 4A – Profile 3 – SECRET / Medium Integrity / Medium Availability; and
  • ITSG-33, Annex 5 – Glossary

1.5 Definitions

should
This word indicates a goal or preferred alternative. There may exist valid reasons in particular circumstances to ignore a particular item or statement, but the full implications must be understood and carefully weighed before choosing a different course.
must
This word indicates a requirement that must be fulfilled to claim conformance to the control.

For other definitions of key terms used in this publication, refer to Annex 5 of ITSG-33 [Reference 4].

2 Context and Assumptions

This section characterizes the business context, the technical and threat context, and the security approaches for which this security control profile is suitable. When selecting this profile as a starting point, departmental security authorities (supported by security practitioners) will need to tailor it in order to create departmental-specific security control profiles that will be appropriate for their department and business activities.

2.1 Business Context

This security control profile is suitable for departments using information systems to support a wide range of GC business activities of medium sensitivity and criticality involving particularly sensitive, PROTECTED B information. Examples of such business activities include, but are not limited to, the delivery of social services, taxation, Receiver General functions, departmental finance and administration, human resources, public service pay and benefits, and providing common and shared IT services to a broad client base.

Departments that are candidates for using this security control profile will perform business activities with a maximum security category marking of (PROTECTED B / Medium Integrity / Medium Availability), as defined in ITSG-33, Annex 1, Section 6 [Reference 2]. Business activities with such a marking have the following general characteristics:

  • Confidentiality – A compromise of the confidentiality of this PROTECTED B information is reasonably expected to cause a medium level of injury to non-national interests;
  • Integrity – A compromise of the integrity of supporting IT assetsFootnote 2 is reasonably expected to cause a medium level of injury to non-national interests;
  • Availability – A compromise of the availability of supporting IT assets is reasonably expected to cause a medium level of injury to non-national interests; and
  • Acceptable residual risksFootnote 3 – The business activities require the support of an information system operating with residual risks at a maximum level of low for the security objectives of confidentiality, integrity and availability.

Table 1 characterizes, in greater detail, suitable business contexts using confidentiality, integrity, and availability objectives; it also includes examples of consequences of compromise, business processes, and related information.

2.1.1 Compliance with GC Legislation and TBS Policy Instruments

This profile has been created as a tool to assist security practitioners in their efforts to protect information systems in compliance with applicable GC legislation and Treasury Board of Canada Secretariat (TBS) policies, directives, and standards.

It is the responsibility of departmental security authorities, when developing their departmental security control profiles, to ensure compliance to all security requirements of GC regulations and TBS policy instruments applicable to their business activities as well as any other contractual obligations.

Table 1: Characterization of Applicable Business Contexts

Characteristics Descriptions and Examples
Confidentiality Objective The business activities involve the processing, transmission, and storage of PROTECTED B information that needs to be adequately protected from unintentional disclosure.
Integrity and Availability Objective The expected injury from compromise of the integrity and availability of IT assets is assessed as medium. IT assets therefore need to be adequately protected from integrity and availability compromise.
Acceptable Residual Risks The business activities require the support of an information system operating with residual risks at a maximum level of low for the security objectives of confidentiality, integrity and availability.
Examples of Injuries
  • Serious civil disorder or unrest
  • Physical pain, injury, trauma, hardship, or illness to individuals
  • Psychological distress or trauma to individuals
  • Financial loss to individuals that affects their quality of life
  • Financial loss to Canadian companies that reduces their competitiveness
  • Inability to conduct criminal investigations or other impediments to effective law enforcement
  • Disruption of government business activities that would seriously inconvenience Canadians
Examples of Business Processes
  • Payments of benefits, to Canadians, whose disruption or delay could cause psychological harm to people
  • Police services whose disruption could cause physical harm to people or lead to civil disorder or unrest
  • Financial and reporting processes whose disruption could lead to serious financial losses to people or Canadian companies
  • Processing of large financial transactions and payments
  • Processes involving health care records
Examples of Information Assets
  • Personal medical and financial information
  • Personal income tax information
  • Large financial transactions and payments
  • Information that could be used for criminal purposes (e.g., false identity or impersonation)
  • Information compiled as part of a criminal investigation
  • Information about an individual’s eligibility for social benefits

2.2 Technical Context

This security control profile is suitable for departments operating in a wide range of IT environments. In general terms, departmental information systems targeted by this profile can be categorized based on their objective as follows:

  • Information systems providing online services (e.g., internet-based) to departmental program or service recipients;
  • Information systems providing operational support services to departmental employees and contractors (e.g., corporate network); and
  • Information systems providing shared or common services within and outside of the department.

It is assumed that these information systems will be connected to other departments and the Internet.

2.3 Threat Context

This security control profile has been developed to protect departmental business activities from IT-related threats that are relevant to both the business context and the technical context.

In addition to the objective of protecting business activities, this profile aims to protect the information systems. This approach is necessary as threats may be directed towards GC IT assets for no other reasons than to compromise technical components and benefit from their resources, irrespective of the type of business activities being supported by these IT assets.

For example, many attackers are not interested in GC information or in disrupting GC business activities; rather, they are interested in compromising GC information systems in order to perform illegal acts, such as storing illegal data (e.g., images, or movies) and covertly sharing that data with other criminals, performing denial of service attacks on commercial websites, extorting money, sending spam, or infecting GC information systems with malware.

Threat information has been analyzed from multiple sources, including TBS and departmental threat and incident reports, in addition to CSE’s own analysis. As a result, this security control profile, when properly implemented (see Section 4), mitigates the risks from exposure to deliberate threat agents of categories from Td1 to Td4, and accidental threats and natural hazards of categories Ta1 to Ta3, as defined in Table 2 and Table 3. As threat agent capabilities evolve over time, this security control profile will be updated to ensure that the selection of security controls is appropriately adjusted to mitigate new capabilities.

Before selecting and tailoring this profile, departments must ensure that the threat context is applicable to their environment. Depending on the threat context, substantial tailoring may be necessary, or if the threat context is very different, a different security control profile should be selected, if available. If a suitable security control profile is not available, departments will need to create their own profile by considering the suite of security controls documented in ITSG-33 Annex 3A, Security Control Catalogue [Reference 1]. Refer to ITSG-33 Annex 1 [Reference 2] for more details on the creation of security control profiles and departmental threat assessments.

Table 2: Applicable Deliberate Threat Categories

Threat Category Threat Agent Description Examples of Increasing Threat Agent Capabilities
Td1 Non-malicious adversary (e.g., non-malicious unauthorized browsing, modification, or destruction of information due to the lack of training, concern, or attentiveness).
  • Basic end user capabilities to access information systems and contents
Td2 Passive, casual adversary with minimal resources who is willing to take little risk (e.g., listening, script kiddie).
  • Execution of a publicly available vulnerability scanner
  • Execution of scripts to attack servers
  • Attempts to randomly delete system files
  • Modification of configuration files settings
Td3 Adversary with minimal resources who is willing to take significant risk (e.g., unsophisticated hackers).
  • Use of publicly available hacker tools to run various exploits
  • Insiders installing trojans and key loggers on unprotected systems
  • Use of simple phishing attacks to compromise targets with malware
  • Execution of programs to crash computers and applications
Td4 Sophisticated adversary with moderate resources who is willing to take little risk (e.g., organized crime, sophisticated hackers, international corporations).
  • Sophisticated use of publicly available hacker tools, including 0-day exploits
  • Ability to create own attack tools in software
  • Basic social engineering attacks
  • Ability to assemble hardware using commercial off the shelf (COTS) components to facilitate attacks
  • Phishing attacks to gain access to credit card or personal data

Table 3: Applicable Accidental Threats and Natural Hazard Categories

Threat Category Magnitude of Events
Ta1
  • Minor accidental events (e.g., trip over a power cord, enter wrong information)
Ta2
  • Moderate accidental events (e.g., render a server inoperable, database corruption, release information to wrong individual or organization)
  • Minor hardware or software failures (e.g., hard disk failure)
  • Minor mechanical failures (e.g., power failure within a section of a facility)
  • Minor natural hazards (e.g., localized flooding, earthquake compromising part of a facility)
Ta3
  • Serious inadvertent or accidental events (e.g., cut facility telecommunications or power cables, fire in the facility, large scale compromise of information)
  • Moderate mechanical failures (e.g., long term facility power failure)
  • Moderate natural hazards (e.g., localized flooding or earthquake compromising a facility)

2.4 Security Approaches

In addition to the business, technical, and threat contexts documented in previous sections, the selection of security controls documented in Section 4 was also influenced by the choice of security engineering best-practices applied to the implementation of dependable information systems. This profile is meant to address the IT security needs of a broad range of business activities, from day-to-day office work to citizen-facing service delivery applications to common and shared service infrastructure support. The protection of business activities call for security approaches where, at a minimum, the following main security engineering best-practices are applied:

  • Defence–in-Depth: technical, operational (including personnel and physical), and management security controls are used in a mutually supportive manner to mitigate risks (e.g., technical access controls used to protect sensitive databases, and additional physical security prevents unauthorized personnel to physically access the database servers);
  • Least-Privilege: users are provided only the minimum access necessary to perform their duties (e.g., day-to-day tasks are performed using limited user accounts only, not administrative accounts);
  • Prevent-Detect-Analyze-Respond-Recover (PDARR): ensures that successful attacks can be detected and contained, IT assets can be restored to a secure and authentic state, and lessons learned are documented and used to improve the security posture of information systems; and
  • Layered Defence: ensures the various layers of an information system, such as applications, databases, platforms, middleware, and communications are adequately protected. This approach reduces the risk that a weakness in one part of the information system could be exploited to circumvent safeguards in other parts (e.g., SQL injection application-layer attacks bypassing network-layer boundary protection).

The broad range of applicability of this profile does not lend itself easily to the use of a set of security approaches where strict boundary protection and strong physical and personnel security are used as the main protection measures (this approach could potentially afford the use of weaker internal security controls). In contrast, this profile suggests a balanced set of security controls to reduce the risks of compromised internal elements of an information system being used to easily compromise additional elements. This profile also suggests security controls to detect, respond, and recover gracefully from security incidents. Many of these controls are operational controls that a mature IT operations group should have in place, not only for security reasons, but also for the efficient and cost-effective day-to-day management of information systems.

Note: While selecting security controls is somewhat subjective, considerable effort was made to include security controls that mitigate real threats, and that can be implemented using readily available COTS products. Security controls that specify a specialized or advanced capability not required for all information systems were excluded from this suggested security profile. Furthermore, every effort was made to achieve the appropriate balance between usability and security.

2.4.1 Relationship of Security Controls to Confidentiality, Integrity, and Availability Objectives

The selection of security controls in this profile aims to ensure the appropriate mitigation of threats that could compromise the confidentiality, integrity, or availability of IT assets supporting departmental business activities. This profile does not document the exact mapping between a security control and the specific objectives it aims to fulfil. While some security controls map more clearly to a specific objective (e.g., CP-7 Alternate Processing Site maps to an availability objective), most security controls support more than one security objective. For example, most controls in the Access Control family support, either directly or indirectly, all three objectives of confidentiality, integrity, and availability of IT assets. An adequate implementation of Access Control will mitigate a compromise where a threat agent:

  • Exfiltrates sensitive documents (confidentiality objective);
  • Modifies documents or database records (integrity and usually availability objectives);
  • Tampers with the proper behaviour of a business application (integrity and possibly availability objective);
  • Deletes database records (availability objective); and
  • Corrupts a business application to make it inoperable (availability objective).

The tailoring of this security control profile to satisfy departmental or business needs must take into account the complex and subtle relationships between afforded security control protection and the three security objectives a security control usually aims to fulfill.

3 Adequate Implementation Guidance

3.1 Security Assurance

Security controls need to be implemented in a manner commensurate with the potential for threat and injury. This profile was developed under certain assumptions as described in Section 2. Consequently, the security controls should be implemented with a medium level of effort and due diligence, as described in this section, in order to ensure that the information system supporting the business activities operates with residual risks at a maximum level of low. However, if the threat and injury applicable to some security controls are determined to be greater (e.g., access control to sensitive databases), then the manner in which these security controls are implemented will need to be adjusted accordingly.

In order to meet the security control requirements documented in this profile, departments need to define the level of effort that will be invested in developing, documenting, and assessing the implementation of the security controls.

Annex 1 of ITSG-33 [Reference 2] describes activities suggested to put in place, or to update, security controls in this profile that relate to the management of IT security risks and those that are not deployed as part of information systems. ITSG-33 does not provide guidance on the level of effort expected for the implementation of those common security controls (e.g., incident management, risk assessments, personnel screening program, physical security program). TBS provides guidance on the establishment of mature management practices and produces assessment tools to measure the current maturity level of those practices.

Annex 2 of ITSG-33 [Reference 3] describes a suggested information system security implementation process useful to cost-effectively design, develop, test, install, and operate dependable information systems that satisfy business needs for security. Annex 2 of ITSG-33 [Reference 3] provides guidance to IT project managers, security practitioners, security assessors, and authorizers on the expected level of effort for the security engineering and security assessment tasks to ensure that the IT security implemented in information systems meets the objectives of this profile.

In the case of security controls implemented in information systems, the appropriate level of effort for security engineering and security assessment tasks are defined as security assurance requirements. These requirements are directed at the tasks that security control designers, developers, and implementers need to perform to increase confidence that the security engineering work and documentation produced is adequate, and that security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security objectives defined for the information systems. A Security Assurance Level of 2 (SAL2) as defined in ITSG-33, Annex 2, Section 8 [Reference 3], is suggested for use by IT projects for the implementation of the majority of the security controls in this profile.

For critical security controls, in particular those on the boundary of an information system, and those facing greater threat agent capabilities, an adequate implementation will ensure that a greater level of effort has been applied to the design, development, testing, installation, and operation of these security controls. A Security Assurance Level of 3 (SAL3) as defined in ITSG-33, Annex 2, Section 8 [Reference 3], is suggested for use by IT projects for the implementation of the critical security controls in this profile. The criticality of a security control is dependent on the specific design of information systems it is applied to and needs to be determined by IT projects’ security practitioners.

Additionally, as described in ITSG-33, Annex 2, Section 7.3.2.1 [Reference 3], for assurance levels SAL1 to SAL3, any supplier involved in the design, development, or operation of an information system should hold, as a minimum, a designated organization screening.

Note that the level of assurance required to adequately implement this profile is not intended to ensure adequate protection of an information system against the highest level of threat agent capabilities (i.e., Td5, Td6, and Td7 threat agents that are highly skilled, highly motivated, and well-resourced).

ITSG-33 Annex 2 [Reference 3] provides more detailed guidance to IT projects on security assurance requirements and the development, documentation, and assessment tasks required to satisfy those requirements.

In addition, it is recommended that selected commercial IT products, that perform security functionality, need to be evaluated in order to ensure they perform functionally as required and are sufficiently resilient to identified threats. To facilitate this assurance process and ensure that IT products are evaluated against appropriate security requirements, CSE makes available for departments to use at their discretion, a pool of commercially available products that have been evaluated by CSE in partnership with certain commercial laboratoriesFootnote 4. If Departments choose to leverage this pool of CSE assured IT products, then procurement vehicles should specify that the selected IT security products be verified by the Common Criteria (CC) program against an appropriate security target or CC protection profileFootnote 5 (either defined organizationally in security standards, or determined by the IT project’s security practitioners to satisfy the requirements of Sections 2 and 3). If the IT product contains a cryptographic module then it should also be verified by the Cryptographic Module Validation ProgramFootnote 6 (CMVP) against FIPS 140-2.

3.2 Implementation priority guidance

Not all organizations have the necessary budget to simultaneously implement all of the security controls and enhancements that are required. In reality, organizations may be required to implement security controls and enhancements as time and budget permit. In order to aid organizations in deciding which security controls and enhancements to implement initially, CSE has categorized security controls and enhancements into three priority levels, as documented in Table 4. It should be noted, this effort is targeted at new information systems such that that the emphasis is on prevention rather than detection or response. Priorities would be different for existing systems. This implementation priority ensures mitigation of the most common threats while planning for the implementation of the remaining security controls. In order to appropriately secure an information system and achieve low residual risks, all of the security controls and enhancements specified in the security control profile must be implemented.

3.3 Format

Table 4 provides the suggested set of security controls and control enhancements for this profile. For each security control, a control ID is provided along with:

  • The name of the security control;
  • A listing of suggested enhancements;
  • Suggested groups responsible (R) to implement or to support (S) the implementation of the security control requirements (IT Security Function, IT Operations Group, IT Projects, Physical Security Group, Personnel Security Group and Learning Center);
  • General tailoring and implementation guidance notes;
  • Suggested implementation priority;
  • Values for the placeholder parameters documented as part of each security control in the profile; and
  • Additional notes regarding the security controls and control enhancements in the context of this profile.

The complete description of the security control, enhancements, and placeholder parameters is available in Annex 3A of ITSG-33 (Security Control Catalogue) [Reference 1].

Note: To make it convenient for security practitioners to create their own departmental security control profile, a spreadsheet document that contains the selection of controls provided in Section Section 4 is available. Contact IT Security Client Service for a copy of the spreadsheet.

4 Suggested Security Controls and Control Enhancements

Table 4: Suggested Security Controls and Control Enhancements:

5 References

[Reference 1]
Communications Security Establishment. IT Security Risk Management: A Lifecycle Approach – Security Control Catalogue. Information Technology Security Guidance Publication 33 (ITSG-33), Annex 3A. 30 December 2014.
[Reference 2]
Communications Security Establishment. IT Security Risk Management: A Lifecycle Approach – Departmental IT Security Risk Management Activities. Information Technology Security Guidance Publication 33 (ITSG-33), Annex 1. 1 November 2012.
[Reference 3]
Communications Security Establishment. IT Security Risk Management: A Lifecycle Approach – Information System Security Risk Management Activities. Information Technology Security Guidance Publication 33 (ITSG-33), Annex 2. 1 November 2012
[Reference 4]
Communications Security Establishment. IT Security Risk Management: A Lifecycle Approach – Glossary. Information Technology Security Guidance Publication 33 (ITSG-33), Annex 5. 1 November 2012.

Notes

Date modified: