Security Categorization Tool

Revision as of 08:35, 14 April 2021 by Greggory.elton (talk | contribs) (Created page with "<div class="center"><div style="float: right; z-index: 10; position: absolute; right: 0; top: 1;">File:JoinusonGCconnex.png|link=http://gcconnex.gc.ca/groups/profile/2785549...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Overview

Security categorization is fundamental to effective security risk management. From a policy perspective, greater emphasis is needed on assessing business impacts resulting from compromises in terms of the overall value of the business activity, rather than simply the cost of the assets that support it. When the GC makes information and services available to the public and businesses, this also comes with an inherent responsibility to ensure that the integrity of the data is not compromised, and that the information and services remain available. Security categorization allows a department to identify and prioritize what measures are reasonable for each business activity.

From a broader perspective, security categorization also helps with cost-effective security management, effective business continuity planning, and the Security Assessment and Authorization (SA&A) process. It is also a key enabler for open data and open information initiatives.

As part of Annex 1 of ITSG-33 - IT Security Risk Management: A Lifecycle Approach, the ESA Program has developed a tool to conduct security categorization. The tool identifies the Confidentiality, Integrity, and Availability (CIA) needs of business activities, and qualitatively or quantitatively categorizes the impact associated with the disruption or compromise of one of these elements. Moreover, it adds valuable intelligence on how to manage the security risks related to business activities and their related system, information, and asset inventories. The tool is an Excel spreadsheet with embedded functions and macros used to help organize business processes and information for the purposes of injury assessment. It contains two main sections:

  • A business activity identification section for programs, business activities, processes, and information, and
  • A business activity categorization section for injury assessment with respect to confidentiality (in pink), integrity (in green), and availability (in yellow).

The categorization tool is an instrument meant to be used by security practitioners. It should help the practitioner develop a business injury view of the department for the purposes of designing secure systems. However, to use it successfully, the security practitioner will need to seek input from business analysts and other relevant individuals. If a department has an existing repository of information that can be converted into a business injury view, using the tool may not be necessary.

For more information about the Security Categorization Tool, how it works, and how to use it effectively, please read the User Manual included in the Security Categorization Tool package.


Security Categorization: Three Steps

Security Categorization consists of three steps which you can read about in more detail by expanding each section below:

Step 1: Inventory Business Activities and Information Assets
Step 2: Assess Injury
Step 3: Identify Business Domains


For more information about the Security Categorization process, please read the User Manual included in the Security Categorization Tool package.


Approaches for Enterprise Applications and Service Provision

Enterprise architecture may identify applications to be used by multiple departments (e.g. email, HR, supply). Service providers may also target multiple departments or domains for their offerings (e.g. SaaS, PaaS). There are two approaches that providers can take with respect to categorization:

  • Pull Approach: The provider seeks out categorization information from each potential client and develops a profile to address the highest level of expected injury.
  • Push Approach: The provider sets the categorization of the application or service and develops a profile to address the highest level of expected injury.

The Pull Approach - Asking "What Do You Need?"

Collecting categorization information from multiple departments requires time and careful planning.This effort should be carried out as part of project initiation in order to determine:

  • Feasibility
  • Scope
  • Schedule and funding envelopes

Considerations:

  • Ensure that all departments use the same categorization template
  • A formal or informal briefing may be required to ensure consistency in injury assessment across departments
  • The overall categorization may not be achievable given the allocated budget/schedule. Significant changes in proposed scope may be required (e.g. off-boarding departments, securing additional funding).

The Push Approach - Declaring "What You're Getting"

The application or service is categorized as a business decision.

For non-obligatory applciations or services, departments can compare their needs against the offering and on-board as appropriate.

For obligatory applications or services (e.g. SSC- or TBS-driven initiatives), departments must compare their needs against the service offering and address areas of risk.

Considerations:

  • Providers must supply all SA&A artifacts or client departments cannot determine areas of residual risk
  • For obligatory applications or services, it is important that the categorization be established based on a comprehensive understanding of the business domains (this may be achieved by exercising a Pull approach).

Departments Must Still Apply ITSG-33, Annex 1

Departments and Agencies must continue to use ITSG-33, Annex 1 in order to:

  • Examine the injury that might occur when the Enterprise applications and services that they depend on fail
  • Decide on the level of risk that they will tolerate with respect to such failures
  • Select a set of controls that, whe implemented appropriately, will reduce their risk to the chosen level

Instead of implementing the chosen controls, departments use their profiles to:

  • Compare their departmental requirements against the Enterprise application or service being provided
  • In a non-obligatory case, decide to use the application or service (and accept any residual risk) or move on to another provider
  • In an obligatory case, flag any differences that result in additional risk and mitigate, accept, or challenge the use of the service.

Security Categorization Tool