Risk assessment

Table of Contents

On this page

 

The controls and activities in the Risk assessment (RA) family deal with the periodic conduct of risk assessments, including PIAs, resulting from the operation of organizational systems and associated handling, storage, or transmission of data and information.

RA-01 Risk assessment policy and procedures

Activity

  1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]
    1. [Selection (1 or more): organization-level; Mission/business process-level; System-level] risk assessment policy that
      1. addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance
      2. is consistent with applicable laws, Orders in Council, directives, regulations, policies, standards, and guidelines
    2. procedures to facilitate the implementation of the risk assessment policy and the associated risk assessment controls
  2. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the risk assessment policy and procedures
  3. Review and update the current risk assessment
    1. policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]
    2. procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]

Discussion

Risk assessment policy and procedures address the controls in the RA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of risk assessment policy and procedures.

Security and privacy program policies and procedures at the organization level are preferable in that they may remove the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or can be represented by multiple policies reflecting the complex nature of organizations.

Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents.

Events that may precipitate an update to risk assessment policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, Orders in Council, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure.

Related controls and activities

PM-09, PS-08, SA-400, SI-02, SI-12.

Enhancements

  • (400) Risk assessment policy and procedures: Privacy impact assessments
    • Develop a PIA process and associated procedures that:
      1. is established by Heads of GC institutions
      2. considers the responsibility within the institution for establishing PIBs
      3. is commensurate with the severity of potential injuries related to the privacy invasiveness of the institution's programs or activities
      4. ensures the PIA is completed by the appropriate privacy senior official or executive holding responsibility within the institution for new or substantially modified programs or activities
    • Discussion: None.
    • GC discussion: Following the establishment of the PIA by the Head of the institution, the appropriate privacy senior officials or executives are responsible for adhering to the process in RA-08 for the completion of the PIA.
    • Related controls and activities: RA-08.

References

Top of page 
 

RA-02 Security categorization

Activity

  1. Categorize the system and information it processes, stores, and transmits
  2. Document the security categorization results, including supporting rationale, in the security plan for the system
  3. Verify that the authorizing official or authorizing official’s designated representative reviews and approves the security categorization decision

Discussion

Security categories describe the potential adverse impacts or negative consequences to organizational operations, organizational assets, and individuals if organizational information and systems are compromised through a loss of confidentiality, integrity, or availability. Security categorization is also a type of asset loss characterization in systems security engineering processes that is carried out throughout the system development lifecycle. Organizations can use privacy risk assessments or PIAs to better understand the potential adverse effects on individuals.

Security categorization processes facilitate the development of inventories of information assets and, along with CM-08, mappings to specific system components where information is handled, stored, or transmitted. The security categorization process is revisited throughout the system development lifecycle to ensure that the security categories remain accurate and relevant. Organizational cyber security and privacy risk management activities (ITSP.10.036) provides guidance on security categorization.

GC discussion

Organizations should conduct the security categorization process as an organization-wide activity with the direct involvement of chief information officers, senior officials in the department’s security governance, appropriate privacy senior officials or executives, system owners, mission and business owners, and information owners or stewards. Organizations should consider the potential adverse impacts to other organizations and injury to the national interest or outside of the national interest.

Related controls and activities

CM-08, MP-04, PL-02, PL-10, PL-11, PM-07, RA-03, RA-05, RA-07, RA-08, SA-08, SA-400, SC-07, SC-38, SI-12.

Enhancements

  • (01) Security categorization: Impact-level prioritization
    • Conduct an impact-level prioritization of organizational systems to obtain additional granularity on system impact levels.
    • Discussion: Organizations should apply the highest determined values to each system categorized in accordance with Organizational cyber security and privacy risk management activities (ITSP.10.036), resulting in systems designated as very low, low, medium, high, or very high impact. Impact-level prioritization of the system allows organizations to focus their investments related to security control selection and the tailoring of control baselines when responding to identified risks.
    • GC discussion: Impact-level prioritization can also be used to determine those systems that may be of heightened interest or value to adversaries or may represent a critical loss to the GC, sometimes described as high-value assets. For such high-value assets, organizations may be more focused on complexity, aggregation, and information exchanges.
    • Related controls and activities: None.

References

Top of page 
 

RA-03 Risk assessment

Activity

  1. Conduct a risk assessment, including
    1. identifying threats to and vulnerabilities in the system
    2. determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it handles, stores, or transmits, and any related information
    3. determining the likelihood and impact of adverse effects on individuals arising from the handling of personal information
  2. Integrate risk assessment results and risk management decisions from the organization and mission or business process perspectives with system-level risk assessments
  3. Document risk assessment results in [Selection (1): security and privacy plans; risk assessment report; [Assignment: organization-defined document]]
  4. Review risk assessment results [Assignment: organization-defined frequency]
  5. Disseminate risk assessment results to [Assignment: organization-defined personnel or roles]
  6. Update the risk assessment [Assignment: organization-defined frequency] or when there are significant changes to the system, its environment of operation, or other conditions that may impact the security or privacy state of the system

Discussion

Risk assessments should consider threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and Canada. Risk assessments should also consider risk from external parties, including contractors who operate systems on behalf of the organization, individuals who access organizational systems, service providers, and outsourcing entities.

Organizations can conduct risk assessments at all 3 levels in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any stage in the system development lifecycle. Risk assessments can also be conducted at various steps in the risk management process, such as Organizational cyber security and privacy risk management activities (ITSP.10.036), including preparation, categorization, control selection and allocation, control implementation, control assessment, authorization, and control monitoring. Risk assessment is an ongoing activity carried out throughout the system development lifecycle.

Risk assessments can also address information related to the system, including system design, the intended use of the system, testing results, and supply chain-related information or artifacts. Risk assessments can play an important role in control selection processes, particularly during the application of tailoring guidance and in the earliest phases of capability determination.

Related controls and activities

CA-03, CA-06, CM-04, CM-13, CP-06, CP-07, IA-08, MA-05, PE-03, PE-08, PE-18, PL-02, PL-10, PL-11, PM-08, PM-09, PM-28, PT-02, PT-07, RA-02, RA-05, RA-07, SA-08, SA-09, SA-400, SC-38, SI-12.

Enhancements

  • (01) Risk assessment: Supply chain risk assessment
      1. Assess supply chain risks associated with [Assignment: organization-defined systems, system components, and system services]
      2. Update the supply chain risk assessment [Assignment: organization-defined frequency], when there are significant changes to the relevant supply chain, or when changes to the system, environments of operation, or other conditions may necessitate a change in the supply chain
    • Discussion: Supply chain-related events include disruption, use of defective components, insertion of counterfeits, theft, malicious development practices, improper delivery practices, and insertion of malicious code. These events can have a significant impact on the confidentiality, integrity, or availability of a system and its information and, therefore, can also adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and Canada. The supply chain-related events may be unintentional or malicious and can occur at any point during the system lifecycle. An analysis of supply chain risk can help an organization identify systems or components for which additional supply chain risk mitigations are required.
    • Related controls and activities: RA-02, RA-09, PM-17, PM-30, SR-02.
  • (02) Risk assessment: Use of all-source intelligence
    • Use all-source intelligence to assist in the analysis of risk.
    • Discussion: Organizations should employ all-source intelligence to inform engineering, acquisition, and risk management decisions.
      All-source intelligence consists of information derived from all available sources, including publicly available or open-source information, or any available corporate intelligence sources. All-source intelligence is used to analyze the risk of vulnerabilities (both intentional and unintentional) from development, manufacturing, and delivery processes, people, and the environment. The risk analysis may be performed on suppliers at multiple tiers in the supply chain sufficient to manage risks. Organizations may develop agreements to share all-source intelligence information or resulting decisions with other organizations, as appropriate.
    • GC discussion: In the GC, all-source intelligence sources include the ones above, with the addition of human intelligence, signals intelligence, and imagery intelligence.
    • Related controls and activities: None.
  • (03) Risk assessment: Dynamic threat awareness
    • Determine the current cyber threat environment on an ongoing basis using [Assignment: organization-defined means].
    • Discussion: The threat awareness information that is gathered feeds into the organization’s information security operations to ensure that procedures are updated in response to the changing threat environment. For example, at higher threat levels, organizations may change the privilege or authentication thresholds required to perform certain operations.
    • Related controls and activities: AT-02.
  • (04) Risk assessment: Predictive cyber analytics
    • Employ the following advanced automation and analytics capabilities to predict and identify risks to [Assignment: organization-defined systems or system components]: [Assignment: organization-defined advanced automation and analytics capabilities].
    • Discussion: A properly resourced SOC or computer incident response team (CIRT) may be overwhelmed by the volume of information generated by the proliferation of security tools and appliances unless it employs advanced automation and analytics to analyze the data. Advanced automation and analytics capabilities are typically supported by artificial intelligence (AI) concepts, including machine learning (ML). Examples include automated threat discovery and response (which includes broad-based collection, context-based analysis, and adaptive response capabilities), automated workflow operations, and machine-assisted decision tools.
      Note, however, that sophisticated adversaries may be able to extract information related to analytic parameters and retrain the ML to classify malicious activity as benign. Accordingly, ML should be augmented by human monitoring to ensure that sophisticated adversaries are not able to conceal their activities.
    • Related controls and activities: None.

References

 

RA-04 Risk assessment update

Withdrawn: Incorporated into RA-03.

Top of page 
 

RA-05 Vulnerability monitoring and scanning

Activity

  1. Monitor and scan for vulnerabilities in the system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system are identified and reported
  2. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for
    1. enumerating platforms, software flaws, and improper configurations
    2. formatting checklists and test procedures
    3. measuring vulnerability impact
  3. Analyze vulnerability scan reports and results from vulnerability monitoring
  4. Remediate legitimate vulnerabilities [Assignment: organization-defined response times] in accordance with an organizational assessment of risk
  5. Share information obtained from the vulnerability monitoring process and control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other systems
  6. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned

Discussion

Security categorization of information and systems guides the frequency and comprehensiveness of vulnerability monitoring (including scans). Organizations should determine the required vulnerability monitoring for system components, ensuring that the potential sources of vulnerabilities — such as infrastructure components (e.g., switches, routers, guards, sensors), and networked printers, scanners, and copiers — are not overlooked.

The capability to readily update vulnerability monitoring tools as new vulnerabilities are discovered and announced and as new scanning methods are developed helps to ensure that new vulnerabilities are not missed by employed vulnerability monitoring tools. The vulnerability monitoring tool update process helps to ensure that potential vulnerabilities in the system are identified and addressed as quickly as possible. Vulnerability monitoring and analyses for custom software may require additional approaches, such as static analysis, dynamic analysis, binary analysis, or a hybrid of the 3 approaches. Organizations can use these analysis approaches in source code reviews and in a variety of tools, including web-based application scanners, static analysis tools, and binary analyzers.

Vulnerability monitoring includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for flow control mechanisms that are improperly configured or operating incorrectly.

Vulnerability monitoring may also include continuous vulnerability monitoring tools that use instrumentation to continuously analyze components. Instrumentation-based tools may improve accuracy and may be run throughout an organization without scanning. Vulnerability monitoring tools that facilitate interoperability include tools that are Security Content Automated Protocol (SCAP)-validated. Thus, organizations should consider using scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that employ the Open Vulnerability Assessment Language (OVAL) to determine the presence of vulnerabilities.

Sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). Control assessments, such as red team exercises, provide additional sources of potential vulnerabilities for which to scan. Organizations should also consider using scanning tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS).

Vulnerability monitoring includes a channel and process for receiving reports from the public about security vulnerabilities. Vulnerability disclosure programs can be as simple as publishing a monitored email address or web form that can receive reports, including notifications that authorize good-faith research and disclosure of security vulnerabilities. Organizations generally expect that such research is happening with or without their authorization and can use public vulnerability disclosure channels to increase the likelihood that discovered vulnerabilities are reported directly to the organization for remediation.

Organizations may also use financial incentives (also known as bug bounties) to further encourage external security researchers to report discovered vulnerabilities. Bug bounty programs can be tailored to the organization’s needs. Bounties can be operated indefinitely or over a defined period and can be offered to the general public or to a curated group. Organizations may run public and private bounties simultaneously and could choose to offer partially credentialed access to certain participants in order to evaluate security vulnerabilities from privileged vantage points.

Related controls and activities

CA-02, CA-07, CA-08, CM-02, CM-04, CM-06, CM-08, RA-02, RA-03, SA-11, SA-15, SC-38, SI-02, SI-03, SI-04, SI-07, SR-11.

Enhancements

  • (01) Vulnerability monitoring and scanning: Update tool capability
    • Withdrawn: Incorporated into RA-05.
  • (02) Vulnerability monitoring and scanning: Update vulnerabilities to be scanned
    • Update the system vulnerabilities to be scanned [Selection (1 or more): [Assignment: organization-defined frequency]; prior to a new scan; when new vulnerabilities are identified and reported].
    • Discussion: Due to the complexity of modern software, systems, and other factors, new vulnerabilities are regularly discovered. It is important that newly discovered vulnerabilities are added to the list of vulnerabilities to be scanned to ensure that the organization can take steps to mitigate those vulnerabilities in a timely manner.
    • Related controls and activities: SI-05.
  • (03) Vulnerability monitoring and scanning: Breadth and depth of coverage
    • Define the breadth and depth of vulnerability scanning coverage.
    • Discussion: The breadth of vulnerability scanning coverage can be expressed as a percentage of components within the system, by the particular types of systems, by the criticality of systems, or by the number of vulnerabilities to be checked. Conversely, the depth of vulnerability scanning coverage can be expressed as the level of the system design that the organization intends to monitor (e.g., component, module, subsystem, element).
      Organizations can determine the sufficiency of vulnerability scanning coverage with regard to its risk tolerance and other factors. Scanning tools and how the tools are configured may affect the depth and coverage. Multiple scanning tools may be needed to achieve the desired depth and coverage.
    • Related controls and activities: None.
  • (04) Vulnerability monitoring and scanning: Discoverable information
    • Determine information about the system that is discoverable and take [Assignment: organization-defined corrective actions].
    • Discussion: Discoverable information includes information that adversaries could obtain without compromising or breaching the system, for example, by collecting information that the system is exposing or by conducting extensive web searches. Corrective actions include notifying appropriate organizational personnel, removing designated information, or changing the system to make the designated information less relevant or attractive to adversaries. This enhancement excludes intentionally discoverable information that may be part of a decoy capability (e.g., honeypots, honeynets, or deception nets) deployed by the organization.
    • Related controls and activities: AU-13, SC-26.
  • (05) Vulnerability monitoring and scanning: Privileged access
    • Implement privileged access authorization to [Assignment: organization-defined system components] for [Assignment: organization-defined vulnerability scanning activities].
    • Discussion: In certain situations, vulnerability scanning may be more intrusive, or the system component that is the subject of the scanning may contain classified or protected information, such as personal information. Privileged access authorization to selected system components facilitates more thorough vulnerability scanning and protects the sensitive nature of such scanning.
    • Related controls and activities: None.
  • (06) Vulnerability monitoring and scanning: Automated trend analyses
    • Compare the results of multiple vulnerability scans using [Assignment: organization-defined automated mechanisms].
    • Discussion: Using automated mechanisms to analyze multiple vulnerability scans over time can help determine trends in system vulnerabilities and identify patterns of attack.
    • Related controls and activities: None.
  • (07) Vulnerability monitoring and scanning: Automated detection and notification of unauthorized components
    • Withdrawn: Incorporated into CM-08.
  • (08) Vulnerability monitoring and scanning: Review historic audit logs
    • Review historic audit logs to determine if a vulnerability identified in a [Assignment: organization-defined system] has been previously exploited within an [Assignment: organization-defined time period].
    • Discussion: Reviewing historic audit logs to determine if a recently detected vulnerability in a system has been previously exploited by an adversary can provide important information for forensic analyses. Such analyses can help identify, for example, the extent of a previous intrusion, the tradecraft employed during the attack, organizational information exfiltrated or modified, mission or business capabilities affected, and the duration of the attack.
    • Related controls and activities: AU-06, AU-11.
  • (09) Vulnerability monitoring and scanning: Penetration testing and analyses
    • Withdrawn: Incorporated into CA-08.
  • (10) Vulnerability monitoring and scanning: Correlate scanning information
    • Correlate the output from vulnerability scanning tools to determine the presence of multi-vulnerability and multi-hop attack vectors.
    • Discussion: An attack vector is a path or means by which an adversary can gain access to a system to deliver malicious code or exfiltrate information. Organizations can use attack trees to show how hostile activities by adversaries interact and combine to produce adverse impacts or negative consequences to systems and organizations. Such information, together with correlated data from vulnerability scanning tools, can provide greater clarity regarding multi-vulnerability and multi-hop attack vectors.
      The correlation of vulnerability scanning information is especially important when organizations are transitioning from older technologies to newer technologies (e.g., transitioning from IPv4 to IPv6 network protocols). During such transitions, some system components may inadvertently be unmanaged and could create opportunities for adversary exploitation.
    • Related controls and activities: None.
  • (11) Vulnerability monitoring and scanning: Public disclosure program
    • Establish a public reporting channel for receiving reports of vulnerabilities in organizational systems and system components.
    • Discussion: The reporting channel should be publicly discoverable and contain clear language authorizing good-faith research and the disclosure of vulnerabilities to the organization. The organization should not condition its authorization on an expectation of indefinite non-disclosure to the public by the reporting entity but may request a specific timeframe to properly remediate the vulnerability.
    • Related controls and activities: None.

References

Top of page 
 

RA-06 Technical surveillance countermeasures survey

Control

Employ a technical surveillance countermeasures survey at [Assignment: organization-defined locations] [Selection (1 or more): [Assignment: organization-defined frequency]; when the following events or indicators occur: [Assignment: organization-defined events or indicators]].

Discussion

A technical surveillance countermeasures survey is a service provided by qualified personnel to detect any presence of technical surveillance devices and hazards and to identify technical security weaknesses that could be used in the conduct of a technical penetration of the surveyed facility. Technical surveillance countermeasures surveys also provide evaluations of the technical security posture of organizations and facilities and include internal and external visual, electronic, and physical examinations of surveyed facilities. The surveys also provide useful input for risk assessments and information regarding organizational exposure to potential adversaries.

Related controls and activities

None.

Enhancements

None.

References

None.

Top of page 
 

RA-07 Risk response

Activity

Respond to findings from security and privacy assessments, monitoring, and audits in accordance with organizational risk tolerance.

Discussion

Organizations have many options for responding to risk, including mitigating risk by implementing new controls or strengthening existing controls, accepting risk with appropriate justification or rationale, sharing or transferring risk, or avoiding risk. The risk tolerance of the organization influences risk response decisions and actions. Risk response addresses the need to determine an appropriate response to risk before generating a plan of action and defining milestones. For example, the response may be to accept risk or reject risk, or it may be possible to mitigate the risk immediately so that a plan of action and milestones are not needed. However, if the risk response is to mitigate the risk, and the mitigation cannot be completed immediately, a plan of action and milestones are generated.

Related controls and activities

CA-05, IR-09, PM-04, PM-28, RA-02, RA-03, SR-02.

Enhancements

None.

References

Top of page 
 

RA-08 Privacy impact assessments

Activity

Conduct PIAs for systems, programs or other activities when:

  1. designing, developing or procuring means of handling personal information
  2. initiating a new collection of personal information
  1. making substantial modifications to existing systems, programs or activities where personal information is handled

Discussion

To manage security risk, an injury assessment is required. Many systems will handle personal information from which injury can arise from privacy violations (as opposed to, for example, financial information, or intellectual property). In addition to the potential harm to the subject individuals, there may also be legal and regulatory repercussions to consider, or business and reputational harm that could occur. Therefore, a privacy-specific assessment of potential injuries is required to determine the security categorization of the intended system.

A PIA is an analysis of how personal information is handled to ensure that handling conforms to applicable privacy requirements and to determine the potential privacy injuries associated with an information system or activity. A PIA is both an analysis and a formal document that details the process and the outcome of the analysis.

Organizations should conduct and develop a PIA with sufficient clarity and specificity to demonstrate that the organization fully considered privacy and has incorporated privacy threats from the earliest stages of the organization’s activity and throughout the information lifecycle.

To conduct a meaningful PIA, the organization’s appropriate privacy senior official or executive may work closely with program managers, information custodians, information management practitioners, IT experts, security architects, counsel, and other relevant organization personnel. A PIA is not a time-restricted activity that is limited to a particular milestone or stage of the information system or personal information lifecycles. Rather, the privacy analysis continues throughout the system and personal information lifecycles. Accordingly, a PIA should be continuously revised and updated whenever there are changes to the IT or to the organization’s practices, or when other factors alter the potential privacy injuries associated with the use of such IT.

After conducting the PIA, organizations may use this information to inform both security and privacy risk assessments. Organizations may also use other related processes that may have different names, including algorithmic impact assessments. A PIA can also inform the public about the organization’s posture with respect to privacy.

GC discussion

For federal departments and agencies, PIAs are triggered under the TBS Directive on Privacy Practices. Federal departments are required to follow the steps detailed within this directive. Departments and agencies should consult their appropriate privacy senior official or executive and legal counsel about this requirement and should be aware of any statutory exceptions and TBS guidance relating to the provision. Prior to conducting privacy analysis, organizations need to complete a privacy checklist, following any existing TBS template, to determine whether a privacy protocol or a PIA is required.

GC organizations are required to conduct PIAs for programs or other activities when personal information is used for or is intended to be used as part of a decision-making process that directly affects the individual and when substantial modifications are made to existing programs or activities where personal information is used or intended to be used for an administrative purpose. However, GC organizations should remain cognizant of potential harm to individuals and consider completing a PIA even if the personal information held by the organization is not being used for decision-making or administrative purposes.

Approval of the PIA must be obtained from the executive or senior official who manages the program or activity and the official responsible for section 10 of the rivacy ActP. Upon approval, the PIA needs to be transmitted to TBS and to the OPC. Organizations are required to create a mitigation plan for compliance gaps or privacy risks identified during the PIA process.

For multi-institutional PIAs, participating organizations should refer to the directive for specific requirements. GC organizations must share copies of the approved PIA and other relevant documentation with partners or other government institutions in a manner that respects security requirements as well as any other confidentiality or legal consideration.

Related controls and activities

CM-04, CM-09, CM-13, PT-02, PT-03, PT-05, RA-01, RA-02, RA-03, RA-07.

Enhancements

None.

References

Top of page 
 

RA-09 Criticality analysis

Activity

Identify critical system components and functions by performing a criticality analysis for [Assignment: organization-defined systems, system components, or system services] at [Assignment: organization-defined decision points in the system development lifecycle].

Discussion

Not all system components, functions, or services necessarily require significant protections. For example, criticality analysis is a key tenet of supply chain risk management and informs the prioritization of protection activities. The identification of critical system components and functions considers applicable laws, Orders in Council, regulations, directives, policies, standards, system functionality requirements, system and component interfaces, and system and component dependencies.

Systems engineers conduct a functional decomposition of a system to identify mission-critical functions and components. The functional decomposition includes the identification of organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and external to the system.

The operational environment of a system or a system component may impact the criticality, including the connections to and dependencies on cyber physical systems, devices, system-of-systems, and outsourced IT services. System components that allow unmediated access to critical system components or functions are considered critical due to the inherent vulnerabilities that such components create. Component and function criticality are assessed in terms of the impact of a component or function failure on the organizational missions that are supported by the system that contains the components and functions.

Criticality analysis is performed when an architecture or design is being developed, modified, or upgraded. If such analysis is performed early in the system development lifecycle, organizations may be able to modify the system design to reduce the critical nature of these components and functions, such as by adding redundancy or alternate paths into the system design.

Criticality analysis can also influence the protection measures required by development contractors. In addition to criticality analysis for systems, system components, and system services, criticality analysis of information is an important consideration. Such analysis is conducted as part of security categorization in RA-02.

Related controls and activities

CP-02, PL-02, PL-08, PL-11, PM-01, PM-11, RA-02, SA-08, SA-15, SA-20, SR-05.

Enhancements

None.

References

Top of page 
 

RA-10 Threat hunting

Control

  1. Establish and maintain a cyber threat hunting capability to
    1. search for indicators of compromise in organizational systems
    2. detect, track, and disrupt threats that evade existing controls
  2. Employ the threat hunting capability [Assignment: organization-defined frequency]

Discussion

Threat hunting is an active means of cyber defence, in contrast to traditional passive protection measures, such as firewalls, intrusion detection and prevention systems, quarantining malicious code in sandboxes, and SIEM technologies and systems.

Cyber threat hunting involves proactively searching organizational systems, networks, and infrastructure for advanced threats. The objective is to track and disrupt cyber adversaries as early as possible in the attack sequence and to measurably improve the speed and accuracy of organizational responses. Indications of compromise include unusual network traffic, unusual file changes, and the presence of malicious code.

Threat hunting teams leverage existing threat intelligence and may create new threat intelligence, which is shared with peer organizations, information sharing and analysis organizations (ISAOs), information sharing and analysis centres (ISACs), and relevant government departments and agencies.

Related controls and activities

CA-02, CA-07, CA-08, RA-03, RA-05, RA-06, SI-04.

Enhancements

None.

References

 
Table of Contents
Date modified: