802
edits
Changes
Jump to navigation
Jump to search
Created page with "==Glossary== The table below is made up of information from various sources credited in the far right column of the table. The terms defined in the table are used in many of..."
==Glossary==
The table below is made up of information from various sources credited in the far right column of the table. The terms defined in the table are used in many of the ESA Program documents available through this portal. Please use the authoritative source when referencing terms in this glossary.
'''Note:''' The terms in this glossary apply primarily to the ESA program, the framework, initiative and its artifacts. While some of the terms can be applied to Security outside fo the ESA and Information Technology scope, the definitions here are intended to provide a better understanding of the terms used in ESA related artifacts and documents.
{| class="wikitable"
|+ Glossary of Terms
|-
!Term
!Definition
!Source
|-
|'''''Accidental Threat'''''
|An unplanned ''threat'' caused by a human being.
|HTRA, Reference 1
|-
|'''''Architecture'''''
|A set of design ''artifacts'', that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change). The design ''artifacts'' describe the structure of ''components'', their inter-relationships, and the principles and guidelines governing their design and evolution over time.
|OSA, Reference 20
|-
|'''''Architecture Description'''''
|An architecture description is a formal description of an ''information system'', organized in a way that supports reasoning about the structural properties of the system. It defines the ''components'' or building blocks that make up the overall ''information system'', and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system.
A document that provides a detailed description of the architectural approach that will realize a particular solution in support of the Business (IT) Services. It is the ''architecture'' ''blueprint'' of the solution and will include descriptions of various ''views'' of the solution such as systems engineering, enterprise security, communications, ''data'' flow, enterprise manageability. It enables further gap analysis to be performed with the identification of the detailed ''Baseline (or Current) Architecture'' and detailed ''Target Architecture''. It also includes high-level implementation recommendations to transition from current state to target state.
|TOGAF
|-
|'''''Access Management'''''
|The management and control of the ways in which entities are granted or denied access to the protected resources of an organization and are authorized to perform a specific action(s) within a given resource.
|[[ICAM|GC ICAM]]
|-
|'''''Account (User Account)'''''
|In the context of GC ICAM, a user account is a mechanism used to establish and control user access to IT systems such as networks, servers and workstations. Users may be individual or NPEs.
|[[ICAM|GC ICAM]]
|-
|'''''Architecture Framework'''''
|A conceptual structure used to develop, implement, and sustain an architecture.
|TOGAF
|-
|'''''Architecture Requirement Specifications'''''
|Provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture.
|ESA Framework
|-
|'''''Architecture Roadmap'''''
|An Architecture Roadmap lists individual ''work packages'' that will realize the ''Target Architecture'' and lays them out on a timeline to show progression from the ''Baseline Architecture'' to the ''Target Architecture''.
|ESA Framework
|-
|'''''Architecture View'''''
|A perspective from which an architecture may be viewed in order to ensure that a specific topic is considered in a coherent manner.
|ESA Framework
|-
|'''''Artifacts'''''
|An architectural work product that describes an aspect of the architecture. Architectural artifacts are created in order to describe a system, solution, or state of the enterprise.
|TOGAF
|-
|'''''Assurance'''''
|A measure of certainty that a statement or fact is true.
|Standard on Identity and Credential Assurance
|-
|'''''Assurance Level'''''
|A level of confidence that may be relied on by others. (Also see ''Security Assurance Level'')
|Standard on Identity and Credential Assurance
|-
|'''''Attribute Based Access Control (ABAC)'''''
|An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.
|[[ICAM|GC ICAM]]
|-
|'''''Audit (Information System)'''''
|The activity of ''monitoring'' the operation of a product from within the product. It includes ''monitoring'' of a product for a set of pre-determined events. Each audit event may indicate rogue behavior, or a condition that is detrimental to security, or provide necessary forensics to identify the source of rogue behaviour.
|ESA Framework
|-
|'''''Audit Log'''''
|A chronological record of the ''audit'' events that have been deemed critical to security. The ''audit'' log can be used to identify potentially malicious activity that may further identity the source of an attack, as well as potential vulnerabilities where additional countermeasures or corrective action are required.
|ESA Framework
|-
|'''''Authentication'''''
|The process of establishing truth or genuineness to generate a measure of certainty that a statement or fact is true.
|[http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26262§ion=text Guideline on Defining Authentication Requirements]; Pan Canadian Assurance Model
|-
|'''''Authentication Assurance Level'''''
|The degree of confidence in the ''authentication'' process expressed in terms of one of four Levels of Assurance (LOA) as defined below. A number of factors contribute to the determination of the LOA including (but not limited to) ''identity'' proofing and ''credential''/''token'' issuance and use.
|[[ICAM|GC ICAM]]
|-
|'''''Authoritative Source'''''
|A collection or registry of records maintained by an authority that meets established criteria (e.g., federation criteria).
|[http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26262§ion=text Guideline on Defining Authentication Requirements]
|-
|'''''Authorization (ICAM)'''''
|The processes of granting or denying specific requests for obtaining and using information processing services or ''data'' and to enter specific physical facilities. It ensures individuals can only use those resources they are entitled to use and then only for approved purposes, enforcing security policies that govern access throughout the enterprise.
|FICAM Glossary (Authentication and Access)
|-
|'''''Authorization (Information Security)'''''
|The ongoing process of obtaining and maintaining official management decision by a senior organizational official to authorize operation of an ''information system'' and to explicitly accept the ''risk'' of relying on the ''information system'' to support a set of business activities based on the implementation of an agreed-upon set of ''security controls'', and the results of continuous ''security assessment''.
|NIST SP800-39, Reference 7, adapted
|-
|'''''Availability'''''
|The state of being accessible and usable in a timely and reliable manner.
Note: (a) Availability is generally applied to ''information assets'', application software, and hardware (infrastructure and its ''components''). Availability can also be applied to ''business processes'', and personnel; (b) It is implicit in the definition that the ''integrity'' of objects being accessed has not been ''compromised'' (e.g., corrupted ''data'')
|PGS, Reference 2, adapted
|-
|'''''Availability Security Objective'''''
|To ensure the ''availability'' of a ''business activity'' or ''IT asset'' against a specified set of ''threats'' in order to prevent ''injury'' to ''national interests'' or
''non-national interests''.
|ITSG-33 Annex 5
|-
|'''''Baseline Architecture'''''
|Describes the current state for an ''enterprise architecture''.
|ESA Framework
|-
|'''''Baseline Security Controls'''''
|Mandatory ''security controls'' of Treasury Board of Canada Secretariat (TBS) policy instruments for implementation by ''departments'' in departmental ''IT security functions'' and ''information systems''.
|MITS,Reference 3
|-
|'''''Blueprint'''''
|Includes ''artifacts'' that compose various architectural ''views''.
|ESA Framework
|-
|'''''Business Activity'''''
|Any activity performed by a department in the course of its operations to deliver or support the delivery of its programs or services. A business activity is composed of one or several ''business processes'' and related ''information assets''.
Note: A business activity can be a GC program (e.g., Employment Insurance), a specific ''business process'' and related ''information assets'' (e.g., accounting), or a set of ''business processes'' and related ''information assets'' with common organizational objectives (e.g., human resources management). Business activities can also include broader concerns such as mission, image, and reputation.
|ITSG-33 Annex 5
|-
|'''''Business Context'''''
|A component of a departmental or domain ''security control profile''. A ''business context'' defines the business activities that are within the scope of a profile in terms of their ''business processes'', related ''information assets'', business needs for security, and their security categories.
|ITSG-33 Annex 5
|-
|'''''Business Domain'''''
|An operational environment where a department performs business activities supporting common organizational objectives.
|ITSG-33 Annex 5
|-
|'''''Business Domain Security Control Profile (Domain Security Control Profile)'''''
|A ''departmental security control profile'' for a specific ''business domain'' as opposed to a department as a whole.
|ITSG-33 Annex 5
|-
|'''''Business Need for Security'''''
|Any protection or compliance requirement associated with a ''business activity'' that can be satisfied by ''security controls''. Business needs for security are derived from laws (e.g., Employment Insurance Act, Financial Administration Act), policies (e.g., Policy on Financial Management, Information and Reporting), and any other regulatory instruments such as directives and standards governing GC business activities. Business needs for security can also be derived from departmental missions, objectives, priorities, the need to preserve the organization’s image and reputation, and various obligations that may have been contracted.
|ITSG-33 Annex 5
|-
|'''''Business Process'''''
|A business process refers to the work required to transform inputs into outputs.
|BTEP, Reference 4, adapted from service process
|-
|'''''Context Specific Architecture View'''''
|''Artifacts'' developed at this layer provide supplementary details; their scope is on common, shared or departmental services and they have a business impact.
Example ''Artifacts'':
*''Strategy'' & Plans
*''Generic Threat Assessment''
*''Baseline Security Controls''
*''Requirements Matrix''
*''Security Patterns''
*''Target Architectures''
*''Transition Strategies & Roadmaps''
|ESA Framework
|-
|'''''Certificate / Certification Authority (CA)'''''
|An authority trusted by one or more users to create and assign certificates.
|ESA Framework
|-
|'''''Certificate Policy (CP)'''''
|A named set of rules that indicate the applicability of a certificate to a particular community and/or class of application with common ''security requirements''. For example, a particular CP might indicate applicability of a type of certificate to the ''authentication'' of parties engaging in business-to-business transactions for the trading of goods or services within a given price range.
|ESA Framework
|-
|'''''Classified IT Asset'''''
|An ''IT asset'' that contains, stores, processes, or transmits ''data'' representing information that may qualify for an exemption or exclusion under the Access to Information Act or the Privacy Act, because its disclosure would reasonably be expected to cause ''injury'' to ''national interests''.
|ITSG-33 Annex 5
|-
|'''''Components'''''
|Components are allocated to one or more patterns. Components represent the lowest level of implementable elements in the ESADD and act as the central meeting point for understanding the system-level relationships among requirements, ''threats'', controls, patterns, and ''use cases''.
|ESA Framework
|-
|'''''Compromise'''''
|The unauthorized access to, disclosure, destruction, removal, modification, use, or interruption of ''IT assets'', causing a loss of ''confidentiality'', ''integrity'' and/or availability. [PGS, Reference 2, adapted] verb. The act of causing a compromise by exploiting vulnerabilities. Note: This loss may lead to the failure of a ''business activity'' and its related requirements. This failure may lead to injuries to ''national interests'' or ''nonnational interests''.
|ITSG-33 Annex 5
|-
|'''''Confidentiality'''''
|The state of being disclosed only to authorized ''principals''.
Note: Confidentiality is typically applied to ''information assets''. Confidentiality can also be applied, usually at a classified level, to some business activities, such as military missions and intelligence collection activities, where the fact the mission or activity exists is classified, and the particulars of its execution is also classified. Operations Security (OPSEC), typically supported by ''IT security'', is one technique used to protect the confidentiality of business activities. In addition, confidentiality can also be applied to other types of ''IT assets'' such as Type-1 COMSEC and SIGINT equipment or weapons systems. Confidentiality in these cases means that the equipment must be provided to, handled by, and disposed of by cleared and authorized personnel. An adversary getting hold of classified equipment may be able to reverse engineer it to deduce
classified information about the design, configuration, and weaknesses.
|PGS, Reference 2, adapted
|-
|'''''Confidentiality Security Objective'''''
|To ensure the ''confidentiality'' of business activities and ''IT assets'' against a specified set of ''threats'' in order to prevent ''injury'' to ''national interests'' or ''non-national interests''.
|ITSG-33 Annex 5
|-
|'''''Concept of Operations'''''
|A document that provides a high-level view of the operating model of an ''information system''. It generally evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or target state. Verbal and graphic statement, in broad outline, of an organization's assumptions or intent in regard to an operation or series of operations
|ISO/IEEE 29148
|-
|'''''Confirm'''''
|Declare that something has been reviewed in detail with an independent determination of sufficiency.
|CC, Reference 5
|-
|'''''Contextual Architecture'''''
|A description of the ''business context'' in which your secure system must be designed, built and operated.
|SABSA
|-
|'''''Control Objectives'''''
|A statements of desired results or purposes to be achieved by implementing y controls
|ESA Framework, adapted from COBIT
|-
|'''''Credential'''''
|In the context of GC ICAM, an object or ''data'' structure that authoritatively binds an individual or NPE to a ''token'' possessed and controlled by that individual or NPE. While common usage often assumes that the credential is maintained by the individual or NPE, this term also refers to electronic records maintained elsewhere (e.g., a protected userid/password database maintained by an application or a public key certificate stored in a repository).
|[[ICAM|GC ICAM]]
|-
|'''''Credential Assurance Level'''''
|In the context of GC ICAM, the degree of confidence that an individual or NPE has maintained possession and control over the ''token'' issued to them and the ''token'' and associated ''credentials'' have not been tampered with or ''compromised''. The degree of confidence is expressed in terms of one of four Levels of Assurance (LOA) as defined below.
|[[ICAM|GC ICAM]]
|-
|'''''Credential Authentication (Credential Validation)'''''
|The process of establishing confidence that the client has control over their rightful credential (i.e. not stolen), and that the credential (or information contained within) has not been compromised (i.e. not tampered with or modified).
|Pan-Canadian Assurance Model
|-
|'''''Credential Management'''''
|In the context of GC ICAM, the policies, principles, practices, processes, procedures and technology that collectively enable the reliable and secure life cycle management of ''credentials'' and the associated ''tokens''.
|GC ICAM (aligns with the definition for Identity Management)
|-
|'''''Critical IT Asset'''''
|An ''IT asset'' that supports a ''business activity'' having some degree of ''criticality''.
|ITSG-33 Annex 5
|-
|'''''Criticality'''''
|The relative importance of a ''business activity'' in promoting or maintaining the health, safety, security, or economic well-being of Canadians, or to the effective functioning of the GC.
|PGS, Reference 2, adapted from critical service
|-
|'''''Cyber Security'''''
|Cyber security is the body of technologies, processes, practices and response and mitigation measures designed to protect electronic information and information infrastructure from mischief, unauthorized use, or disruption. Cyber security involves securing systems and information that may be vulnerable online (e.g. perimeter security, need to know access, vulnerability management, patch management, and related processes).
|[https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=32603 Policy on Service and Digital]
|-
|'''''Data'''''
|Electronic representation of information. The quantities, characters, or symbols on which operations are performed by a computer, being stored and transmitted in the form of electrical signals and recorded on magnetic, optical, or mechanical recording media.
|Oxford, Reference 9, adapted
|-
|'''''Deliberate Threat'''''
|A planned or premeditated ''threat'' caused by a human being.
|HTRA, Reference 1
|-
|'''''Demonstrate'''''
|Provide a conclusion gained by an analysis that is more rigorous than a ''trace'' but less rigorous than a proof. To demonstrate a mapping, a rigorous analysis and an informal proof of the more detailed correspondence between elements of successive specifications is required.
|CC, Reference 5
|-
|'''''Departmental Security Control Profile'''''
|A set of ''security controls'' that a department establishes as the minimum mandatory requirements for their departmental ''IT security function'' and their ''information systems''. A profile must satisfy TBS ''baseline security controls'' and departmental business needs for security with due consideration for the departmental ''threat context'' and ''technical context''.
|ITSG-33 Annex 5
|-
|'''''Departmental Security Program'''''
|The group of security-related resource inputs and activities that departmental security officers (DSOs) manage to address the security needs of their department while achieving the results set forth in security related TBS policy instruments.
|ITSG-33
|-
|'''''Departmental Security Requirement'''''
|Any ''security requirement'' prescribed by senior officials of a department that applies generally to ''information systems'' of that department. Departmental ''security requirements'' may relate to ''business processes'', ''information assets'', IT-related ''threats'', ''robustness levels'', ''security control profiles'', ''security assurance'' requirements, business needs for security, ''security architecture'', security design, common ''security controls'', and specific ''security solutions''.
|ITSG-33 Annex 5
|-
|'''''Departments (GC Departments)'''''
|GC departments, agencies, and other organizations subject to the Policy on Government Security.
|ITSG-33 Annex 5
|-
|'''''Describe'''''
|Provide specific details.
|CC, Reference 5
|-
|'''''Determine'''''
|Affirm a particular conclusion based on independent analysis with the objective of reaching a particular conclusion.
|CC, Reference 5
|-
|'''''Development Environment'''''
|Environment in which the ''information system'' is developed.
|CC, Reference 5, adapted
|-
|'''''End User Device (EUD)'''''
|Any device that is used to access GC Enterprise resources and services for the purpose of conducting the business of the GC''. This includes static solutions such as workstations and desktops as well as mobile solutions such as tablets, smart phones, and laptops. ''
|ESADD Annex A
|-
|'''''Enterprise Architecture'''''
|A description of the structure of an enterprise, which comprises enterprise ''components'' (business entities), the externally visible properties of those ''components'', and the relationships (e.g. the behaviour) between them. Enterprise architecture describes the terminology, the composition of enterprise ''components'', and their relationships with the external environment, and the guiding principles for the requirement, design, and evolution of an enterprise. This description is comprehensive, including enterprise goals, ''business processes'', roles, organizational structures, organizational behaviours, business information, software applications, and ''information systems''.
|ITSG-33 Annex 5
|-
|'''''Enterprise IT Security Architecture'''''
|The translation of government-wide ''IT security'' vision and ''strategy'' into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future ''IT security'' state and enable its evolution.
|ESA Framework
|-
|'''''GC Unique Identifier'''''
|In the context of GC ICAM, a unique reference (e.g., a number) associated with a specific individual or NPE used to unambiguously distinguish one individual or NPE from another. In the context of GC ICAM, the GC unique identifier is permanently associated with the individual or NPE.
|[[ICAM|GC ICAM]]
|-
|'''''GC Worker (GC ICAM)'''''
|In the context of GC ICAM, GC employees, contractors, Canadian Forces military personnel, regular members of the RCMP (i.e., police officers), trusted guests, or any other authorized users operating internal to the GC.
|GC ICAM
|-
|'''''High-Level Architecture View'''''
|''Artifacts'' developed at this layer are high level documents that are GC/Enterprise in scope and have a strategic impact.
|ESA Framework
|-
|'''''Identification'''''
|The “I” in IA&A, identification is the act of asserting an ''identity''. Usually, the entity asserting an ''identity'' is required to prove the assertion by authenticating.
|ESA Framework
|-
|'''''Identity'''''
|In the context of GC ICAM, a reference, designation or set of attributes used to distinguish a unique and particular individual or NPE within a given context.
|[[ICAM|GC ICAM]]
|-
|'''''Identity Authentication'''''
|Identity Authentication is the act of proving an asserted ''identity''. For example, a password can be used to authenticate a presented ''identity'' or a digital signature can be used to authenticate an ''identity'' asserted in a public key certificate; The process of verifying that a claimed individual or NPE is genuine and based on valid ''credentials''.
|ESA Framework; [[ICAM|GC ICAM]]
|-
|'''''Identity Assurance Level'''''
|In the context of GC ICAM, the degree of confidence that an individual or NPE is who or what it claims to be expressed in terms of one of four Levels of Assurance (LOA) as defined below.
|[[ICAM|GC ICAM]]
|-
|'''''Identity Attribute'''''
|In the context of GC ICAM, a ''data'' element that represents a property, quality or characteristic associated with the identity of an individual or NPE.
|[[ICAM|GC ICAM]]
|-
|'''''Identity Management'''''
|In the context of GC ICAM, the policies, principles, practices, processes, procedures and technology that collectively enable the reliable and secure life cycle management of identities and ''identity attributes''.
|[[ICAM|GC ICAM]]
|-
|'''''Identity Proofing'''''
|The process used to collect, validate and verify identity information associated with an individual or NPE. (Note: Guidance associated with this process is provided in the Guideline on Identity Assurance.)
|[[ICAM|GC ICAM]]
|-
|'''''Implementation (Implement, Implementing)'''''
|A term used to designate the phases of the system lifecycle that are responsible for the delivery of an ''information system''. It includes the initiation, development/acquisition, and integration and installation phases of the system lifecycle, but excludes the operations and maintenance phase and the disposal phase.
|ITSG-33 Annex 5
|-
|'''''Implementation Representation'''''
|The least abstract representation of an ''information system''. It consists of source code, hardware and software products, physical network diagrams, configuration documentation such as build books, and so on. Collectively, these elements allow for the construction of the ''information system'' without having to make any further design or implementation decisions.
|ITSG-33 Annex 5
|-
|'''''Information (Information Asset)'''''
|Any pattern of symbols or sounds to which meaning may be assigned.
|HTRA, Reference 1
|-
|'''''Information System'''''
|An information system is generally composed of ''data'', computing platforms, communications networks, business applications, people, and processes, organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
|NIST SP800-39, Reference 7, adapted
|-
|'''''Information System Security Implementation Process (ISSIP)'''''
|The process of identifying security needs and then building ''information systems'' capable of satisfying these needs in a real-world operational environment. ISSIP incorporates process areas of ''information system'' security engineering, ''security assessment'', and authorization to form a comprehensive process for the implementation of dependable information
systems.
|ITSG-33 Annex 5
|-
|'''''Injury'''''
|The damage to the ''national interests'' and ''non-national interests'' that business activities serve resulting from the ''compromise'' of ''IT assets''.
|[HTRA, Reference 1, adapted]
|-
|'''''Injury Level'''''
|The severity of an ''injury''. Five levels are defined: very low, low, medium, high, very high.
|ITSG-33 Annex 5
|-
|'''''Integrity'''''
|The state of being accurate, complete, authentic, and intact.
Note: Integrity is generally applied to ''information assets''. Integrity can also be applied to ''business processes'', software application logic, hardware and personnel.
|DDSM, Reference 6
|-
|'''''Integrity Security Objective'''''
|To ensure the ''integrity'' of a ''business activity'' or ''IT asset'' against a specified set of ''threats'' in order to prevent ''injury'' to ''national interests'' or ''nonnational interests''.
|ITSG-33 Annex 5
|-
|'''''Intermediate Architecture'''''
|Provides detailed and context-specific information required to implement one of the transition states described in a ''transition strategy and roadmap''.
|ESA Framework
|-
|'''''IT Asset'''''
|A generic term used to represent business applications, electronic representations of information (''data''), and the hardware, software, and system ''data'' that ''information systems'' are composed of.
|ITSG-33 Annex 5
|-
|'''''IT Security'''''
|The discipline of applying ''security controls'', ''security solutions'', tools, and techniques to protect ''IT assets'' against ''threats'' from ''compromises'' throughout their lifecycle, based on the ''security category'' of supported business activities, and in accordance with departmental and GC policies, directives, standards, and guidelines. These securirty controls are intended to preserve the ''confidentiality'', ''integrity'', availability, intended use and value of electronically stored, processed or transmitted information.
Note: Protecting ''IT assets'' helps protect departmental business activities and therefore departmental mission and objectives.
|ITSG-33 Annex 5
|-
|'''''IT Security Function'''''
|The elements of a ''departmental security program'' that are dedicated to the protection of departmental ''IT assets''.
|ITSG-33 Annex 5
|-
|'''''IT Security Incident'''''
|Any unexpected or unwanted event that might cause a ''compromise'' of ''IT assets''.
|MITS, Reference 3, adapted
|-
|'''''IT Security Risk'''''
|The potential that a given ''threat'' will ''compromise'' ''IT assets'' and cause ''injury''.
|HTRA, Reference 1, adapted
|-
|'''''IT Security Risk Management'''''
|The process by which organizations manage ''IT security risks''. ''IT security risk'' management is achieved through ''IT security'' and other ''risk management'' processes.
|ITSG-33 Annex 5
|-
|'''''IT Threat'''''
|Any potential event or act, deliberate, accidental or ''natural hazard'', that could ''compromise'' ''IT assets''.
|HTRA, Reference 1, adapted
|-
|'''''Justify (Justification)'''''
|Provide a conclusion gained by an analysis that is more rigorous than a demonstration but less rigorous than a proof. It requires significant rigour in terms of very carefully and thoroughly explaining every step of a logical argument.
|CC, Reference 5, adapted from justification
|-
|'''''Logical Access Control Systems (LACS)'''''
|An electronic system that controls an individual’s ability to access one or more computer system resources such as a workstation, network, application, or database.
|[[ICAM|GC ICAM]]
|-
|'''''Management Security Control'''''
|A ''security control'' that focuses on the management of ''IT security'' and ''IT security risks''.
|NIST FIPS 200, Reference 11, adapted
|-
|'''''Monitor (Monitoring)'''''
|The continuous process of observing the operations of ''information systems'' with the objective of detecting deviations from planned or expected behaviour.
|ITSG-33 Annex 5
|-
|'''''Must'''''
|This word means that the statement is a mandatory requirement.
|RFC 2119, Reference 8, adapted
|-
|'''''Natural Hazard'''''
|A ''threat'' attributable to forces of nature.
|HTRA, Reference 1
|-
|'''''National Interests'''''
|The security and the social, political, and economic stability of Canada.
|PGS, Reference 2
|-
|'''''Non-National Interests'''''
|The safety, health, and well being of individuals, and the financial position and reputation of individuals and Canadian companies.
|PGS, Reference 2, SOAS, Reference 10, adapted
|-
|'''''Non-Person Entity (NPE)'''''
|Any type of non-human device (e.g., routers, servers, firewalls, mobile devices such as smart phones), application or software object.
|[[ICAM|GC ICAM]]
|-
|'''''Operational Concept (OpsCon)'''''
|verbal and graphic statement of an organization's assumptions or intent in regard to an operation or series of operations of a system or a related set of systems
|ISO/IEEE 29148
|-
|'''''Operational Security Control'''''
|A ''security control'' that is primarily implemented and executed by people and is typically supported by the use of technology, such as supporting software.
|NIST FIPS 200, Reference 11, adapted
|-
|'''''Orphaned Account'''''
|An ''account'' belonging to a user that has left the organization or no longer requires access to the resource. Orphaned accounts are most often the result of ineffective de-provisioning processes wherein user access privileges are not removed immediately upon a user leaving the organization. These accounts create security vulnerabilities, which may be exploited by individuals seeking to do harm.
|FICAM Glossary
|-
|'''''Physical Access Control Systems (PACS)'''''
|Systems controlling access to physical areas or assets (e.g., buildings, restricted zones).
|GC ICAM
|-
|'''''Principal'''''
|Participating entity in an ''information system'' (physical person, legal person, role, equipment, channel, automated process).
|ITSG-33 Annex 5
|-
|'''''Privilege Management'''''
|A set of processes for establishing and maintaining the entitlement or privilege attributes that comprise an individual’s access profile. These attributes are features of an individual that can be used as the basis for determining access decisions to both physical and logical resources.
|FICAM Glossary
|-
|'''''Protected IT Asset'''''
|An ''IT asset'' that contains, stores, processes, or transmits ''data'' representing information that may qualify for an exemption or exclusion under the Access to Information Act or the Privacy Act because its disclosure would reasonably be expected to cause ''injury'' to ''non-national interests''.
|ITSG-33 Annex 5
|-
|'''''Protection Profile'''''
|A document used as part of the certification process according to the Common Criteria. As the generic form of a security target, it is typically created by a user or user community and provides an implementation independent specification of information assurance ''security requirements''.
|ESA Framework
|-
|'''''Public Key Infrastructure (PKI)'''''
|A cryptographic key and certificate delivery system that makes possible secure electronic transactions and exchanges of sensitive information using a system of trusted third parties called “certificate authorities.”.
|PWGSC - Information Management Fascicle 2: Information Security Glossary
|-
|'''''Recommended'''''
|Refer to the definition of should.
|ITSG-33 Annex 5
|-
|'''''Reference Design'''''
|A predefined pattern, or set of patterns, possibly partially or completely instantiated, designed, and proven for use in particular business and ''technical contexts'', together with supporting ''artifacts'' to enable their use.
|Rational Unified Process
|-
|'''''Residual Risk'''''
|A ''risk'' that remains after ''security controls'' have been selected, approved and implemented.
Note: Business owners should generally require the support of an ''information system'' with a ''security posture'' that aligns with their tolerance to ''risk''. For example, they should require the support of an ''information system'' with a ''strong security posture'' where their tolerance to ''risk'' is low. However, this may not always be the case. For example, it may be acceptable for troops to deploy in theatre to save lives with the support of ''IT assets'' having a weaker ''security posture'' than would normally be required if the consequences of not performing the mission (i.e., loss of many civilian lives) are worse (relatively) than the consequences of relying on these ''IT assets'' of weaker ''security posture'' to perform the mission (i.e., loss of some military assets).
|HTRA, Reference 1, adapted
|-
|'''''Residual Risk Level (IT Security Residual Risk Level)'''''
|The degree of ''residual risk''.
|ITSG-33 Annex 5
|-
|'''''Residual Risk Assessment'''''
|The assessment performed at the conclusion of the ''system development lifecycle'' to adjust the conclusions of the detailed ''threat and risk assessment'' to account for unresolved security deficiencies identified during the design, development, testing, and installation phases.
|ITSG-33 Annex 5
|-
|'''''Risk'''''
|refers to the effect of uncertainty on objectives. It is the expression of the likelihood and impact of an event with the potential to affect the achievement of an organization's objectives.
|TBS Framework for the Management of Risk
|-
|'''''Risk Level'''''
|The degree of ''risk''
|ITSG-33 Annex 5
|-
|'''''Risk management'''''
|A systematic approach to setting the best course of action under uncertainty by identifying, assessing, understanding, acting on and communicating ''risk'' issues
|TBS Integrated Risk Management Framework
|-
|'''''Robustness'''''
|A characterization of the ''security strength'' and security ''assurance'' of an implemented ''security control''.
|ITSG-33 Annex 5
|-
|'''''Robustness Level'''''
|A robustness level is composed of a ''security strength'' component and a ''security implementation assurance'' component. Together, these two components define the requirements that must be met in the implementation and operation of a ''security control'' to satisfy defined security ''control objectives''. Note: A ''security control'' of a higher robustness level aims to counter ''threat agents'' with more sophisticated capabilities, or ''accidental threats'' and ''natural hazard''s of higher magnitude.
|ITSG-33 Annex 5
|-
|'''''Roots of Trust'''''
|Security primitives composed of hardware, firmware and/or software that provide a set of trusted, security-critical functions. They must always behave in an expected manner because their misbehaviour cannot be detected. As such, Roots of Trust need to be secured by their design. Hardware Roots of Trust are preferred over software Roots of Trust due to their immutability, smaller attack surface, and more reliable behaviour.
|NIST SP 800-164
|-
|'''''Scenario'''''
|A scenario is a refinement of a ''use case'' (see ''Use Case'') that shows a sequence of interactions between the system and the user (actor) and/or external systems. It may also show interactions between ''components'' internal to the system. A single ''use case'' is often associated with multiple scenarios that show alternative interactions, including those that deal with error conditions.
|ESA Framework
|-
|'''''Security Architecture'''''
|The design ''artifacts'' that describe how the ''security controls'' are positioned, and how they relate to the overall IT Architecture. These controls serve the purpose to maintain the system’s quality attributes, among them ''confidentiality'', ''integrity'', availability, accountability and ''assurance''.
|OSA
|-
|'''''Security Assessment (Information System)'''''
|The ongoing process of evaluating the performance of ''IT security controls'' throughout the lifecycle of ''information systems'' to establish the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the departmental business needs for security. Security assessment supports authorization by providing the grounds for confidence in ''information system'' security.
|NIST SP800-39, Reference 7, adapted from ''security control'' assessment
|-
|'''''Security Assurance Level'''''
|Predefined measure of ''Robustness''
|ITSG-33 Annex 5, Adapted
|-
|'''''Security Implementation Assurance'''''
|Confidence-building tasks that aim to ensure that a ''security control'' is designed and implemented correctly, and is operating as intended, with the resiliency required to meet an ''assurance level'' expected by the business owner. This is also called “Security Assurance” in ITSG-33. Note: Security Implementation Assurance and the ''Security Strength'' (of mechanism) both characterize the ''Robustness'' level.
|Adapted from “Security Assurance” ITSG-33 Annex 5
|-
|'''''Security Implementation Assurance Level'''''
|The level of assurance achieved by completing a predefined set of ''security implemntation assurance'' tasks.
|ITSG-33 Annex 5
|-
|'''''Security Implementation Assurance Task'''''
|An action performed by a security practitioner or an assessor to establish ''assurance'' (confidence) in a specific security aspect of an ''information system''. There are two types of ''security implementation assurance'' tasks: engineering task and assessment task. Engineering tasks include the production of documentation and may need to satisfy documentation content requirements.
|ITSG-33 Annex 5
|-
|'''''Security Categorization'''''
|The process of determining the ''security category'' of business activities, ''information systems'', and ''IT assets''.
Notes:
a) Security categorization is established by assessing ''injury'' to national and ''non-national interests'' as a result of failures of business activities to meet their ''security objectives'' of ''confidentiality'', ''integrity'', and availability. ''Information systems'' and ''IT assets'' generally inherit the ''security category'' of the business activities that relate to them.
b) At the departmental level, security categorization is a continuous activity for categorizing the security of business activities to support the development of ''security control'' profiles. At the ''information system'' level, security categorization is an activity of the ISSIP for categorizing the security of the ''information system'' and its ''IT assets''. For the ''information system'', it is done early in the ''system development lifecycle''. For ''IT assets'', it is done later during the design phases when ''IT assets'' have been defined.
|ESA Framework
|-
|'''''Security Category'''''
|A security category characterizes a ''business activity'' by the severity of expected injuries (''injury level'') from ''compromise'' with respect to the ''security objectives'' of ''confidentiality'', ''integrity'', and availability.
|ITSG-33 Annex 5
|-
|'''''Security Control'''''
|An administrative, operational, technical, physical or legal measure for managing ''security risk'' (avoid, counteract or minimize ''security risks'').
|CSEC ITSG-33
|-
|'''''Security Control (IT Security Control)'''''
|A management, operational, or technical high-level ''security requirement'' prescribed for an ''information system'' to protect the ''confidentiality'', ''integrity'', and availability of its ''IT assets''. ''Security controls'' are implemented using various types of ''security solutions'' that include security products, security policies, security practices, and security procedures.
|NIST SP800-39, Reference 7, adapted
|-
|'''''Security Control Enhancement'''''
|A statement of security capability to: (i) build in additional, but related, functionality to a basic control; and/or (ii) increase the ''security strength'' of a basic ''security control''.
|NIST SP800-39, Reference 7
|-
|'''''Security Controls Mapping Matrix'''''
|A tool used to for compliance and support for SA&A analysts. It provides a complete mapping of ''security controls'' to ''components'' and ''threats'', and indirectly to patterns and ''use cases''.
|ESA Framework
|-
|'''''Security Control Objective'''''
|A statement, stated in a standardize language, that formalizes what is to be achieved by a ''security control'' to satisfy business needs for security. Note: A security control objective should be written in a way that is specific, measurable, attainable, results-oriented, and time-based. A security control objective must be measurable using performance metrics, continuous ''monitoring'', and ''security assessment''. The implementation of ''security controls'' aims to fulfill the security control objectives, in order to satisfy the business needs for security. For example, the issuance of an accurate benefits amount to an authorized recipient (citizen) is a business need for security. The security control objectives for this business need for security may be defined as a function of the positive ''authentication'' of the recipient with a defined error rate; the positive authorization of the recipient in receiving the benefits payment with a defined error rate; and the preservation of the ''integrity'' of the payment transaction event (log of the ''business process'' events) and payment record (log of the approved payment and all related information) with high confidence. The exact metrics (e.g., error rate and confidence) associated with the security control objectives need to be defined based on the injuries that could be incurred by the recipient where the business need for security is not satisfied. The metrics may be loose when the injuries are minor (an inaccurate payment amount leads to some inconvenience), or strict when the injuries are serious (an inaccurate amount leads to serious stress and financial loss).
|ITSG-33 Annex 5
|-
|'''''Security Domain'''''
|Within the context of this document, a security domain represents a collection of ''data'', ''components'', systems, devices, networks, etc. that operate under the same security policy. Before moving ''data'' between security domains, an assessment should be made to determine whether the security policy of the target domain is sufficient to protect the ''data''. If not, the transfer should be blocked or the ''data'' sanitized prior to transfer.
|ESA Framework
|-
|'''''Security Measure'''''
|Refer to the definition of ''security solution''.
|ITSG-33 Annex 5
|-
|'''''Security Mechanism'''''
|A class of ''security solutions'' rated in terms of ''security strength'' of protection and ''security implementation assurance'' to address specific ''threats''. Note: examples of classes of ''security solutions'' are: biometrics, digital signature, hot standby, anti-tampering, discretionary access control, packet filtering. Each of these classes can be implemented by various ''security solutions'' (e.g., products). For example, biometrics can be implemented using fingerprint, iris or retina scanners.
|ITSG-33 Annex 5
|-
|'''''Security Objective'''''
|Refer to the definitions of ''confidentiality security objective'', ''integrity' security objective'', and ''availability security objective''.
|ESA Framework
|-
|'''''Security Pattern'''''
|A general reusable solution to a commonly occurring problem in creating and maintaining secure ''information systems''. A technique for putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.
|OSA, TOGAF
|-
|'''''Security Posture'''''
|A characteristic of an ''information system'' that represents its resilience to a specific set of deliberate attacks and accidental and ''natural hazards'' (i.e., ''selected threats'') Note: Resilience relates not only to the capability of the ''information system'' to prevent ''threats'' but also to detect, respond, and recover from their ''compromise''s. A security posture is assessed without regard for ''unselected threats''.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Very Weak)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system’s'' ''IT assets'' is assessed as severe. This rating indicates that the ''information system'' has not been adequately built to prevent, detect, respond, or recover from ''compromises''. The department does not have in place the mechanisms to manage ''IT security incidents'' and ''compromises'', or to implement required improvements.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Weak)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system''’s ''IT assets'' is assessed as considerable. Issues characterizing an ''information system'' having a weak security posture typically include many of the following:
#The business needs for security are not fully understood and are not well documented;
#The ''security controls'' and requirements are not fully defined and are not well documented;
#The ''threats'' are not fully understood and are not well documented;
#The implemented ''security solutions'' fulfill only partially the ''security controls'' and requirements, without adequate assurance;
#The ''information system'' is not operated in a manner to maintain the security posture;
#The departmental ''IT security function'' does not perform adequate ''monitoring'' and ''security assessment'';
#The department does not have mechanisms in place to learn fromthe ''IT security incidents'' and ''compromises'' and to implement required improvements.
These elements increase the potential of ''threats'' compromising ''IT assets'' due an increase in the number or significance of exploitable vulnerabilities. In the event of a ''compromise'', the ''information system'', IT operations group, and the departmental ''IT security function'' cannot effectively detect, respond to, and recover from the ''compromise''.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Average)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system''’s ''IT assets'' is assessed as significant. Issues characterizing an ''information system'' having an average security posture may include some of the following:
#The business needs for security are not fully understood or are not well documented;
#The ''security controls'' and requirements are not fully defined or are not well documented;
#The ''threats'' are not fully understood or are not well documented;
#The implemented ''security solutions'' fulfill only partially the ''security controls'' and requirements, without adequate assurance;
#The ''information systems'' is not operated efficiently in a manner to maintain the security posture;
#The departmental ''IT security function'' does not perform efficient ''monitoring'' and ''security assessment'';
#The department does not have in place mature mechanisms to learn from ''IT security incidents'' and ''compromise''s and to implement required improvements.
These elements increase the potential of ''threats'' compromising ''IT assets'' due an increase in the number or significance of exploitable vulnerabilities. In the event of a ''compromise'', the ''information system'', IT operations group, and the departmental ''IT security function'' cannot gracefully detect, respond to, and recover from the ''compromise''.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Strong)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system''’s ''IT assets'' is assessed as minor. The key characteristics of an ''information system'' having a strong security posture include most or all of the following:
#The business needs for security are well understood and documented;
#The ''security controls'' and requirements are well defined and documented;
#The ''threats'' are well understood and documented;
#The implemented ''security solutions'' fulfill the ''security controls'' and requirements, with adequate assurance;
#The ''information system'' is operated in a manner to maintain the security posture over time;
#The departmental ''IT security function'' performs adequate ''monitoring'' and ''security assessments'' of implemented ''security controls'';
#In the event of a ''compromise'', the ''information system'', IT operations group, and the departmental ''IT security function'' can detect, respond to, and recover gracefully from the ''compromise'',thus minimizing the possibility of incurring injuries, or the severity of injuries;
#The department learns from incidents and implements any required improvements.
This rating indicates that the ''information system'' has been adequately built to prevent, detect, respond, and recover gracefully from ''compromise''.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Very Strong)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system''’s ''IT assets'' is assessed as very small. The ''information system'' fully satisfies business needs for security, has been adequately built to prevent, detect, respond, and recover gracefully from ''compromise'', and is fully documented. The department has in place mature mechanisms to manage incidents and ''compromise'', learns from the experience, and implements required improvements promptly.
|ITSG-33 Annex 5
|-
|'''''Security Requirement'''''
|Any need, stated in a standardized language, that an ''information system'' must satisfy through ''IT security'' that contributes to achieving a business need for security.
|CC, Reference 5, adapted
|-
|'''''Security Requirements Traceability Matrix'''''
|A tool used to trace the correspondence between high-level business and ''security requirements'' through successively more detailed designs. The SRTM provides a cross-reference of system ''security requirements'' to ''components'', and indirectly to patterns and ''use cases''.
|ESA Framework
|-
|'''''Security Risk'''''
|An expression of the likelihood and impact of events with the potential to cause ''injury'' to information, assets, individuals or services
|ESA Framework
|-
|'''''Security Safeguard'''''
|Refer to the definition of ''security solution''.
|ITSG-33 Annex 5
|-
|'''''Security Solution'''''
|Any security function, product, practice, or procedure that is implemented
in an ''information system'' to realize a ''security control''.
|ITSG-33 Annex 5
|-
|'''''Security Strength'''''
|The characterization of an implemented ''security control’s'' potential to protect ''IT assets'' against ''compromise''s from ''threats''. Note: As the ''security strength'' increases, the effort (cost) or magnitude required by the ''threat agent'' to defeat the implemented ''security control'' also increases. The protective potential of an implemented ''security control'' can be fulfilled only when it is implemented with adequate ''security implementation assurance''.
|ITSG-33 Annex 5
|-
|'''''Security Testing'''''
|Testing conducted during the development phase and the integration and testing phase of the ''system development lifecycle'' (SDLC) and that contributes to the establishment of ''security implementation assurance''. Note: During the development phase, security testing includes functional testing of custom ''security solutions'' (e.g., functional unit testing) and may
also include other forms of testing such a negative functional testing of non-security functions (e.g., fuzz testing of URL against a web application) and the testing of operational procedures to determine usability and maintainability. During the integration and testing phase, security testing includes functional security testing and may also include ''vulnerability assessments'' and penetration testing, depending on the ''security implementation assurance'' requirements.
|ITSG-33 Annex 5
|-
|'''''Selected Threat (Selected IT Threat)'''''
|Any IT-related ''threat'' that has been deemed, through a ''threat assessment'', as relevant to a ''business activity'' or an ''information system'' and against which a department intends to protect its ''IT assets''. Note: Factors influencing the selection of ''threats'' include, for example, the resources and skill set available or not available to the organization to effectively counter a ''threat''; the limited budget allocated to ''IT security''; the assessment that some ''threat'' ''compromises'' may not lead to injuries; etc. Refer to the definition of ''threat assessment'' for more information.
|ITSG-33 Annex 5
|-
|'''''Shall'''''
|Refer to the definition of must.
|ITSG-33 Annex 5
|-
|'''''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.
|RFC 2119, Reference 8, adapted
|-
|'''''Solution Architecture'''''
|A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.
|TOGAF
|-
|'''''Solution Architecture View'''''
|''Artifacts'' developed at this layer include significant detail, are system in scope and have an operational impact.
|ESA Framework
|-
|'''''Statement of Assessment'''''
|Any recognition or acknowledgement that the assessment process has been completed with acceptable results. It can be as simple as a record of decision appearing in the minutes of an engineering or project meeting or as formal as an assessment certificate signed by a security assessor.
|ITSG-33 Annex 5
|-
|'''''Statement of Sensitivity (SOS)'''''
|Identification and categorization of relevant assets according to their ''confidentiality'', ''integrity'' and availability values based upon the injuries that may reasonably be expected in the event of a ''compromise''
|HTRA
|-
|'''''Strategy'''''
|The pattern or plan that integrates an organization’s major goals, policies, and action sequences into a cohesive whole.
|EABOK Starter Glossary
|-
|'''''System Development Lifecycle'''''
|The successive stages through which ''information systems'' are implemented (i.e., brought into service or delivered).
Note: The reference SDLC used in ITSG-33 publications consists of the following phases: 1) stakeholder engagement, 2) concept, 3) planning, 4)requirements analysis, 5) high-level design, 6) detailed design, 7)development, 8) integration and testing, and 9) installation.
|ITSG-33 Annex 5
|-
|'''''System Lifecycle'''''
|The successive stages that ''information systems'' pass through from their inception to their end of life.
Note: The reference SLC used in ITSG-33 publications consists of the following phases: 1) Initiation, 2) development/acquisition, 3) integration
and installation, 4) operations and maintenance, and 5) disposal.
|ITSG-33 Annex 5
|-
|'''''Target Architecture'''''
|The description of a future state of the architecture being developed for an organization. There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.
|TOGAF
|-
|'''''Token'''''
|In the context of GC ICAM, something that an individual or NPE possesses and controls that is used to authenticate that individual or NPE. A token can be thought of as a secure container for a secret (i.e., Token Secret) that is used to generate a Token Authenticator. Additional information regarding these concepts can be found in NIST SP 800-63-2, Section 6.
|[[ICAM|GC ICAM]]
|-
|'''''Transition Architecture'''''
|A formal description of one state of the architecture at an architecturally significant point in time. One or more Transition Architectures may be used to describe the progression in time from the Baseline to the ''Target Architecture''.
|TOGAF
|-
|'''''Transition Strategy and Roadmap'''''
|Outlines an incremental approach to evolve from current state to the ''target architecture''. Each transition state described in a roadmap provides a clear milestone with measurable business value.
|ESA Framework
|-
|'''''Technical Context'''''
|A component of a departmental or domain ''security control'' profile. A technical context defines in general terms the technical environment that might influence the selection of the profile’s ''security controls''.
|ITSG-33 Annex 5
|-
|'''''Technical Security Control'''''
|A ''security control'' implemented and executed by ''information systems'' primarily through ''security mechanisms'' contained in hardware, software, and firmware components.
Note: A technical security control is dependent on the proper functioning of the ''information system'' for effectiveness. Also, some operational aspects may be included in the implementation of the control (e.g., manual assessment of log ''monitoring'' results).
|NIST FIPS 200, Reference 11, adapted
|-
|'''''Threat'''''
|An event or act, deliberate or accidental, that could cause ''injury'' to information, assets or individuals.
|ITSG-33
|-
|'''''Threat Actor'''''
|A threat actor is an individual or organization that conducts or may conduct an attack against an ''information system''.
|ITSG-33
|-
|'''''Threat Agent'''''
|A threat agent is an autonomous entity that acts on behalf of a threat actor. A threat agent can be a human, electronic, or mechanical device that can communicate with a threat actor and act on instructions. The degree of autonomous behaviour varies with the complexity of the threat agent.
|ITSG-33
|-
|'''''Threat Assessment'''''
|The process of identifying and qualifying ''threats'' faced by an organization’s business activities and ''information systems'' supporting them. Note: A threat assessment will identify all ''threats'' faced by an organization. The ''selected threats'' are the ones that the organization chooses to address and are documented explicitly. Threats that an organization may face, but that are not addressed for various reasons, such as cost constraints, technical constraints, or operational constraints, are also documented explicitly (i.e., unselected threats).
|ITSG-33 Annex 5
|-
|'''''Threat and Risk Assessment (IT-Related TRA)'''''
|The process of identifying and qualifying ''threats'' and ''risks'' to ''IT assets'' and of implementing or recommending additional ''security controls'' to mitigate ''risks'' that are deemed unacceptable.
|ITSG-33 Annex 5
|-
|'''''Threat Context'''''
|A characteristic of a departmental or domain ''security control profile''. A threat context defines the ''selected threats'' of relevance to the domain’s business activities.
|ITSG-33 Annex 5
|-
|'''''Threat Event'''''
|The occurrence of an actual incident in which a ''threat agent'' exploits a ''vulnerability'' on an ''information system'' (which may or may not be successful at achieving the ''threat actor’s'' objectives) with potentially adverse effects on an ''IT asset'' of value.
|ITSG-33
|-
|'''''Trace/Tracing(IT)'''''
|Perform an informal correspondence analysis between two entities with only a minimal level of rigour. Tracing involves documenting a basic correspondence between the elements of successive specifications.
|ITSG-33 Annex 5
|-
|'''''Use Case'''''
|A function offered by the system that results from, or results in, interaction between the system and a user (actor) and/or external systems. A ''use case'' identifies the purpose and nature of the function, but contains no details of how it is implemented (see ''Scenario'').
|ESA Framework
|-
|'''''View'''''
|The representation of a related set of concerns. A view is what is seen from a viewpoint. An ''architecture view'' may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature.
|TOGAF
|-
|'''''Viewpoint'''''
|A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from - the vantage point or perspective that determines what you see.
|TOGAF
|-
|'''''Vulnerability'''''
|An inadequacy related to security that could increase susceptibility to ''compromise'' or ''injury''.
|ESA Framework
|-
|'''''Vulnerability Assessment'''''
|A determination of the existence of ''information system'' vulnerabilities.
|MITS, Reference 3
|-
|'''''Work Package'''''
|A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program.
|TOGAF
|}
==References==
[Reference 1] Communications Security Establishment Canada and the Royal Canadian Mounted Policy. Harmonized Threat and Risk Assessment (TRA) Methodology. 23 October 2007.
[Reference 2] Treasury Board of Canada Secretariat. Policy on Government Security.1 July 2009.
[Reference 3] Treasury Board of Canada Secretariat. Operational Security Standard: Management of Information Technology Security. 31 May 2004.
[Reference 4] Treasury Board of Canada Secretariat. Business Transformation Enablement Program (BTEP). Glossary. April 2006.
[Reference 5] Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements. CCMB-2009-07-001, Version 3.1, Revision 3. July 2009.
[Reference 6] Treasury Board of Canada Secretariat. Directive on Departmental Security Management. 1 July 2009.
[Reference 7] National Institute of Standards and Technology. Information Security. Managing Information Security Risk: Organization, Mission, and Information System View. NIST Special Publication 800-39, March 2011.
[Reference 8] Internet Engineering Task Force. RFC2119 Key words for use in RFCs to Indicate Requirement Levels. March 1997.
[Reference 9] Oxford Dictionaries Online (ODO). http://oxforddictionaries.com
[Reference 10] Treasury Board of Canada Secretariat. Security Organization and Administration Standard. 1 June 1995.
[Reference 11] National Institute of Standards and Technology. Minimum Security Requirements for Federal Information and Information Systems FIPS PUB 200. March 2006.
[Reference 12] FICAM Glossary - US Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, Version 2.0, Appendix B, December 2, 2011
[Reference 13] NIST SP 800-63-2 - National Institute of Standards and Technology Electronic Authorization Guideline, August 2013
[Reference 14] OMB M-04-04: Executive Office of the President Office of Management and Budget Memorandum on E-Authentication Guidance for (US) Federal Agencies, December 16, 2003
[Reference 15] ICAM Lexicon: Identity, Credential and Access Management Lexicon, National Security Systems Identity, Credentialing and Access Management Focus Group, Version 1.0, 30 May 2013
[Reference 16] Directive on Identity Management – Directive on Identity Management, Government of Canada, July 1, 2009
[Reference 17] Standard on Identity and Credential Assurance – Standard on Identity and Credential Assurance, Government of Canada, February 1, 2013
[Reference 18] Guideline on Defining Authentication Requirements – Guideline on Defining Authentication Requirements, Government of Canada
[Reference 19] Draft Guideline on Identity Assurance – draft Guideline on Identity Assurance, Government of Canada, January 21, 2014
[Reference 20] Open Security Architecture Glossary (http://www.opensecurityarchitecture.org/cms/definitions/glossary), Accessed July 24th 2014
The table below is made up of information from various sources credited in the far right column of the table. The terms defined in the table are used in many of the ESA Program documents available through this portal. Please use the authoritative source when referencing terms in this glossary.
'''Note:''' The terms in this glossary apply primarily to the ESA program, the framework, initiative and its artifacts. While some of the terms can be applied to Security outside fo the ESA and Information Technology scope, the definitions here are intended to provide a better understanding of the terms used in ESA related artifacts and documents.
{| class="wikitable"
|+ Glossary of Terms
|-
!Term
!Definition
!Source
|-
|'''''Accidental Threat'''''
|An unplanned ''threat'' caused by a human being.
|HTRA, Reference 1
|-
|'''''Architecture'''''
|A set of design ''artifacts'', that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change). The design ''artifacts'' describe the structure of ''components'', their inter-relationships, and the principles and guidelines governing their design and evolution over time.
|OSA, Reference 20
|-
|'''''Architecture Description'''''
|An architecture description is a formal description of an ''information system'', organized in a way that supports reasoning about the structural properties of the system. It defines the ''components'' or building blocks that make up the overall ''information system'', and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system.
A document that provides a detailed description of the architectural approach that will realize a particular solution in support of the Business (IT) Services. It is the ''architecture'' ''blueprint'' of the solution and will include descriptions of various ''views'' of the solution such as systems engineering, enterprise security, communications, ''data'' flow, enterprise manageability. It enables further gap analysis to be performed with the identification of the detailed ''Baseline (or Current) Architecture'' and detailed ''Target Architecture''. It also includes high-level implementation recommendations to transition from current state to target state.
|TOGAF
|-
|'''''Access Management'''''
|The management and control of the ways in which entities are granted or denied access to the protected resources of an organization and are authorized to perform a specific action(s) within a given resource.
|[[ICAM|GC ICAM]]
|-
|'''''Account (User Account)'''''
|In the context of GC ICAM, a user account is a mechanism used to establish and control user access to IT systems such as networks, servers and workstations. Users may be individual or NPEs.
|[[ICAM|GC ICAM]]
|-
|'''''Architecture Framework'''''
|A conceptual structure used to develop, implement, and sustain an architecture.
|TOGAF
|-
|'''''Architecture Requirement Specifications'''''
|Provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture.
|ESA Framework
|-
|'''''Architecture Roadmap'''''
|An Architecture Roadmap lists individual ''work packages'' that will realize the ''Target Architecture'' and lays them out on a timeline to show progression from the ''Baseline Architecture'' to the ''Target Architecture''.
|ESA Framework
|-
|'''''Architecture View'''''
|A perspective from which an architecture may be viewed in order to ensure that a specific topic is considered in a coherent manner.
|ESA Framework
|-
|'''''Artifacts'''''
|An architectural work product that describes an aspect of the architecture. Architectural artifacts are created in order to describe a system, solution, or state of the enterprise.
|TOGAF
|-
|'''''Assurance'''''
|A measure of certainty that a statement or fact is true.
|Standard on Identity and Credential Assurance
|-
|'''''Assurance Level'''''
|A level of confidence that may be relied on by others. (Also see ''Security Assurance Level'')
|Standard on Identity and Credential Assurance
|-
|'''''Attribute Based Access Control (ABAC)'''''
|An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.
|[[ICAM|GC ICAM]]
|-
|'''''Audit (Information System)'''''
|The activity of ''monitoring'' the operation of a product from within the product. It includes ''monitoring'' of a product for a set of pre-determined events. Each audit event may indicate rogue behavior, or a condition that is detrimental to security, or provide necessary forensics to identify the source of rogue behaviour.
|ESA Framework
|-
|'''''Audit Log'''''
|A chronological record of the ''audit'' events that have been deemed critical to security. The ''audit'' log can be used to identify potentially malicious activity that may further identity the source of an attack, as well as potential vulnerabilities where additional countermeasures or corrective action are required.
|ESA Framework
|-
|'''''Authentication'''''
|The process of establishing truth or genuineness to generate a measure of certainty that a statement or fact is true.
|[http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26262§ion=text Guideline on Defining Authentication Requirements]; Pan Canadian Assurance Model
|-
|'''''Authentication Assurance Level'''''
|The degree of confidence in the ''authentication'' process expressed in terms of one of four Levels of Assurance (LOA) as defined below. A number of factors contribute to the determination of the LOA including (but not limited to) ''identity'' proofing and ''credential''/''token'' issuance and use.
|[[ICAM|GC ICAM]]
|-
|'''''Authoritative Source'''''
|A collection or registry of records maintained by an authority that meets established criteria (e.g., federation criteria).
|[http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26262§ion=text Guideline on Defining Authentication Requirements]
|-
|'''''Authorization (ICAM)'''''
|The processes of granting or denying specific requests for obtaining and using information processing services or ''data'' and to enter specific physical facilities. It ensures individuals can only use those resources they are entitled to use and then only for approved purposes, enforcing security policies that govern access throughout the enterprise.
|FICAM Glossary (Authentication and Access)
|-
|'''''Authorization (Information Security)'''''
|The ongoing process of obtaining and maintaining official management decision by a senior organizational official to authorize operation of an ''information system'' and to explicitly accept the ''risk'' of relying on the ''information system'' to support a set of business activities based on the implementation of an agreed-upon set of ''security controls'', and the results of continuous ''security assessment''.
|NIST SP800-39, Reference 7, adapted
|-
|'''''Availability'''''
|The state of being accessible and usable in a timely and reliable manner.
Note: (a) Availability is generally applied to ''information assets'', application software, and hardware (infrastructure and its ''components''). Availability can also be applied to ''business processes'', and personnel; (b) It is implicit in the definition that the ''integrity'' of objects being accessed has not been ''compromised'' (e.g., corrupted ''data'')
|PGS, Reference 2, adapted
|-
|'''''Availability Security Objective'''''
|To ensure the ''availability'' of a ''business activity'' or ''IT asset'' against a specified set of ''threats'' in order to prevent ''injury'' to ''national interests'' or
''non-national interests''.
|ITSG-33 Annex 5
|-
|'''''Baseline Architecture'''''
|Describes the current state for an ''enterprise architecture''.
|ESA Framework
|-
|'''''Baseline Security Controls'''''
|Mandatory ''security controls'' of Treasury Board of Canada Secretariat (TBS) policy instruments for implementation by ''departments'' in departmental ''IT security functions'' and ''information systems''.
|MITS,Reference 3
|-
|'''''Blueprint'''''
|Includes ''artifacts'' that compose various architectural ''views''.
|ESA Framework
|-
|'''''Business Activity'''''
|Any activity performed by a department in the course of its operations to deliver or support the delivery of its programs or services. A business activity is composed of one or several ''business processes'' and related ''information assets''.
Note: A business activity can be a GC program (e.g., Employment Insurance), a specific ''business process'' and related ''information assets'' (e.g., accounting), or a set of ''business processes'' and related ''information assets'' with common organizational objectives (e.g., human resources management). Business activities can also include broader concerns such as mission, image, and reputation.
|ITSG-33 Annex 5
|-
|'''''Business Context'''''
|A component of a departmental or domain ''security control profile''. A ''business context'' defines the business activities that are within the scope of a profile in terms of their ''business processes'', related ''information assets'', business needs for security, and their security categories.
|ITSG-33 Annex 5
|-
|'''''Business Domain'''''
|An operational environment where a department performs business activities supporting common organizational objectives.
|ITSG-33 Annex 5
|-
|'''''Business Domain Security Control Profile (Domain Security Control Profile)'''''
|A ''departmental security control profile'' for a specific ''business domain'' as opposed to a department as a whole.
|ITSG-33 Annex 5
|-
|'''''Business Need for Security'''''
|Any protection or compliance requirement associated with a ''business activity'' that can be satisfied by ''security controls''. Business needs for security are derived from laws (e.g., Employment Insurance Act, Financial Administration Act), policies (e.g., Policy on Financial Management, Information and Reporting), and any other regulatory instruments such as directives and standards governing GC business activities. Business needs for security can also be derived from departmental missions, objectives, priorities, the need to preserve the organization’s image and reputation, and various obligations that may have been contracted.
|ITSG-33 Annex 5
|-
|'''''Business Process'''''
|A business process refers to the work required to transform inputs into outputs.
|BTEP, Reference 4, adapted from service process
|-
|'''''Context Specific Architecture View'''''
|''Artifacts'' developed at this layer provide supplementary details; their scope is on common, shared or departmental services and they have a business impact.
Example ''Artifacts'':
*''Strategy'' & Plans
*''Generic Threat Assessment''
*''Baseline Security Controls''
*''Requirements Matrix''
*''Security Patterns''
*''Target Architectures''
*''Transition Strategies & Roadmaps''
|ESA Framework
|-
|'''''Certificate / Certification Authority (CA)'''''
|An authority trusted by one or more users to create and assign certificates.
|ESA Framework
|-
|'''''Certificate Policy (CP)'''''
|A named set of rules that indicate the applicability of a certificate to a particular community and/or class of application with common ''security requirements''. For example, a particular CP might indicate applicability of a type of certificate to the ''authentication'' of parties engaging in business-to-business transactions for the trading of goods or services within a given price range.
|ESA Framework
|-
|'''''Classified IT Asset'''''
|An ''IT asset'' that contains, stores, processes, or transmits ''data'' representing information that may qualify for an exemption or exclusion under the Access to Information Act or the Privacy Act, because its disclosure would reasonably be expected to cause ''injury'' to ''national interests''.
|ITSG-33 Annex 5
|-
|'''''Components'''''
|Components are allocated to one or more patterns. Components represent the lowest level of implementable elements in the ESADD and act as the central meeting point for understanding the system-level relationships among requirements, ''threats'', controls, patterns, and ''use cases''.
|ESA Framework
|-
|'''''Compromise'''''
|The unauthorized access to, disclosure, destruction, removal, modification, use, or interruption of ''IT assets'', causing a loss of ''confidentiality'', ''integrity'' and/or availability. [PGS, Reference 2, adapted] verb. The act of causing a compromise by exploiting vulnerabilities. Note: This loss may lead to the failure of a ''business activity'' and its related requirements. This failure may lead to injuries to ''national interests'' or ''nonnational interests''.
|ITSG-33 Annex 5
|-
|'''''Confidentiality'''''
|The state of being disclosed only to authorized ''principals''.
Note: Confidentiality is typically applied to ''information assets''. Confidentiality can also be applied, usually at a classified level, to some business activities, such as military missions and intelligence collection activities, where the fact the mission or activity exists is classified, and the particulars of its execution is also classified. Operations Security (OPSEC), typically supported by ''IT security'', is one technique used to protect the confidentiality of business activities. In addition, confidentiality can also be applied to other types of ''IT assets'' such as Type-1 COMSEC and SIGINT equipment or weapons systems. Confidentiality in these cases means that the equipment must be provided to, handled by, and disposed of by cleared and authorized personnel. An adversary getting hold of classified equipment may be able to reverse engineer it to deduce
classified information about the design, configuration, and weaknesses.
|PGS, Reference 2, adapted
|-
|'''''Confidentiality Security Objective'''''
|To ensure the ''confidentiality'' of business activities and ''IT assets'' against a specified set of ''threats'' in order to prevent ''injury'' to ''national interests'' or ''non-national interests''.
|ITSG-33 Annex 5
|-
|'''''Concept of Operations'''''
|A document that provides a high-level view of the operating model of an ''information system''. It generally evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or target state. Verbal and graphic statement, in broad outline, of an organization's assumptions or intent in regard to an operation or series of operations
|ISO/IEEE 29148
|-
|'''''Confirm'''''
|Declare that something has been reviewed in detail with an independent determination of sufficiency.
|CC, Reference 5
|-
|'''''Contextual Architecture'''''
|A description of the ''business context'' in which your secure system must be designed, built and operated.
|SABSA
|-
|'''''Control Objectives'''''
|A statements of desired results or purposes to be achieved by implementing y controls
|ESA Framework, adapted from COBIT
|-
|'''''Credential'''''
|In the context of GC ICAM, an object or ''data'' structure that authoritatively binds an individual or NPE to a ''token'' possessed and controlled by that individual or NPE. While common usage often assumes that the credential is maintained by the individual or NPE, this term also refers to electronic records maintained elsewhere (e.g., a protected userid/password database maintained by an application or a public key certificate stored in a repository).
|[[ICAM|GC ICAM]]
|-
|'''''Credential Assurance Level'''''
|In the context of GC ICAM, the degree of confidence that an individual or NPE has maintained possession and control over the ''token'' issued to them and the ''token'' and associated ''credentials'' have not been tampered with or ''compromised''. The degree of confidence is expressed in terms of one of four Levels of Assurance (LOA) as defined below.
|[[ICAM|GC ICAM]]
|-
|'''''Credential Authentication (Credential Validation)'''''
|The process of establishing confidence that the client has control over their rightful credential (i.e. not stolen), and that the credential (or information contained within) has not been compromised (i.e. not tampered with or modified).
|Pan-Canadian Assurance Model
|-
|'''''Credential Management'''''
|In the context of GC ICAM, the policies, principles, practices, processes, procedures and technology that collectively enable the reliable and secure life cycle management of ''credentials'' and the associated ''tokens''.
|GC ICAM (aligns with the definition for Identity Management)
|-
|'''''Critical IT Asset'''''
|An ''IT asset'' that supports a ''business activity'' having some degree of ''criticality''.
|ITSG-33 Annex 5
|-
|'''''Criticality'''''
|The relative importance of a ''business activity'' in promoting or maintaining the health, safety, security, or economic well-being of Canadians, or to the effective functioning of the GC.
|PGS, Reference 2, adapted from critical service
|-
|'''''Cyber Security'''''
|Cyber security is the body of technologies, processes, practices and response and mitigation measures designed to protect electronic information and information infrastructure from mischief, unauthorized use, or disruption. Cyber security involves securing systems and information that may be vulnerable online (e.g. perimeter security, need to know access, vulnerability management, patch management, and related processes).
|[https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=32603 Policy on Service and Digital]
|-
|'''''Data'''''
|Electronic representation of information. The quantities, characters, or symbols on which operations are performed by a computer, being stored and transmitted in the form of electrical signals and recorded on magnetic, optical, or mechanical recording media.
|Oxford, Reference 9, adapted
|-
|'''''Deliberate Threat'''''
|A planned or premeditated ''threat'' caused by a human being.
|HTRA, Reference 1
|-
|'''''Demonstrate'''''
|Provide a conclusion gained by an analysis that is more rigorous than a ''trace'' but less rigorous than a proof. To demonstrate a mapping, a rigorous analysis and an informal proof of the more detailed correspondence between elements of successive specifications is required.
|CC, Reference 5
|-
|'''''Departmental Security Control Profile'''''
|A set of ''security controls'' that a department establishes as the minimum mandatory requirements for their departmental ''IT security function'' and their ''information systems''. A profile must satisfy TBS ''baseline security controls'' and departmental business needs for security with due consideration for the departmental ''threat context'' and ''technical context''.
|ITSG-33 Annex 5
|-
|'''''Departmental Security Program'''''
|The group of security-related resource inputs and activities that departmental security officers (DSOs) manage to address the security needs of their department while achieving the results set forth in security related TBS policy instruments.
|ITSG-33
|-
|'''''Departmental Security Requirement'''''
|Any ''security requirement'' prescribed by senior officials of a department that applies generally to ''information systems'' of that department. Departmental ''security requirements'' may relate to ''business processes'', ''information assets'', IT-related ''threats'', ''robustness levels'', ''security control profiles'', ''security assurance'' requirements, business needs for security, ''security architecture'', security design, common ''security controls'', and specific ''security solutions''.
|ITSG-33 Annex 5
|-
|'''''Departments (GC Departments)'''''
|GC departments, agencies, and other organizations subject to the Policy on Government Security.
|ITSG-33 Annex 5
|-
|'''''Describe'''''
|Provide specific details.
|CC, Reference 5
|-
|'''''Determine'''''
|Affirm a particular conclusion based on independent analysis with the objective of reaching a particular conclusion.
|CC, Reference 5
|-
|'''''Development Environment'''''
|Environment in which the ''information system'' is developed.
|CC, Reference 5, adapted
|-
|'''''End User Device (EUD)'''''
|Any device that is used to access GC Enterprise resources and services for the purpose of conducting the business of the GC''. This includes static solutions such as workstations and desktops as well as mobile solutions such as tablets, smart phones, and laptops. ''
|ESADD Annex A
|-
|'''''Enterprise Architecture'''''
|A description of the structure of an enterprise, which comprises enterprise ''components'' (business entities), the externally visible properties of those ''components'', and the relationships (e.g. the behaviour) between them. Enterprise architecture describes the terminology, the composition of enterprise ''components'', and their relationships with the external environment, and the guiding principles for the requirement, design, and evolution of an enterprise. This description is comprehensive, including enterprise goals, ''business processes'', roles, organizational structures, organizational behaviours, business information, software applications, and ''information systems''.
|ITSG-33 Annex 5
|-
|'''''Enterprise IT Security Architecture'''''
|The translation of government-wide ''IT security'' vision and ''strategy'' into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future ''IT security'' state and enable its evolution.
|ESA Framework
|-
|'''''GC Unique Identifier'''''
|In the context of GC ICAM, a unique reference (e.g., a number) associated with a specific individual or NPE used to unambiguously distinguish one individual or NPE from another. In the context of GC ICAM, the GC unique identifier is permanently associated with the individual or NPE.
|[[ICAM|GC ICAM]]
|-
|'''''GC Worker (GC ICAM)'''''
|In the context of GC ICAM, GC employees, contractors, Canadian Forces military personnel, regular members of the RCMP (i.e., police officers), trusted guests, or any other authorized users operating internal to the GC.
|GC ICAM
|-
|'''''High-Level Architecture View'''''
|''Artifacts'' developed at this layer are high level documents that are GC/Enterprise in scope and have a strategic impact.
|ESA Framework
|-
|'''''Identification'''''
|The “I” in IA&A, identification is the act of asserting an ''identity''. Usually, the entity asserting an ''identity'' is required to prove the assertion by authenticating.
|ESA Framework
|-
|'''''Identity'''''
|In the context of GC ICAM, a reference, designation or set of attributes used to distinguish a unique and particular individual or NPE within a given context.
|[[ICAM|GC ICAM]]
|-
|'''''Identity Authentication'''''
|Identity Authentication is the act of proving an asserted ''identity''. For example, a password can be used to authenticate a presented ''identity'' or a digital signature can be used to authenticate an ''identity'' asserted in a public key certificate; The process of verifying that a claimed individual or NPE is genuine and based on valid ''credentials''.
|ESA Framework; [[ICAM|GC ICAM]]
|-
|'''''Identity Assurance Level'''''
|In the context of GC ICAM, the degree of confidence that an individual or NPE is who or what it claims to be expressed in terms of one of four Levels of Assurance (LOA) as defined below.
|[[ICAM|GC ICAM]]
|-
|'''''Identity Attribute'''''
|In the context of GC ICAM, a ''data'' element that represents a property, quality or characteristic associated with the identity of an individual or NPE.
|[[ICAM|GC ICAM]]
|-
|'''''Identity Management'''''
|In the context of GC ICAM, the policies, principles, practices, processes, procedures and technology that collectively enable the reliable and secure life cycle management of identities and ''identity attributes''.
|[[ICAM|GC ICAM]]
|-
|'''''Identity Proofing'''''
|The process used to collect, validate and verify identity information associated with an individual or NPE. (Note: Guidance associated with this process is provided in the Guideline on Identity Assurance.)
|[[ICAM|GC ICAM]]
|-
|'''''Implementation (Implement, Implementing)'''''
|A term used to designate the phases of the system lifecycle that are responsible for the delivery of an ''information system''. It includes the initiation, development/acquisition, and integration and installation phases of the system lifecycle, but excludes the operations and maintenance phase and the disposal phase.
|ITSG-33 Annex 5
|-
|'''''Implementation Representation'''''
|The least abstract representation of an ''information system''. It consists of source code, hardware and software products, physical network diagrams, configuration documentation such as build books, and so on. Collectively, these elements allow for the construction of the ''information system'' without having to make any further design or implementation decisions.
|ITSG-33 Annex 5
|-
|'''''Information (Information Asset)'''''
|Any pattern of symbols or sounds to which meaning may be assigned.
|HTRA, Reference 1
|-
|'''''Information System'''''
|An information system is generally composed of ''data'', computing platforms, communications networks, business applications, people, and processes, organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
|NIST SP800-39, Reference 7, adapted
|-
|'''''Information System Security Implementation Process (ISSIP)'''''
|The process of identifying security needs and then building ''information systems'' capable of satisfying these needs in a real-world operational environment. ISSIP incorporates process areas of ''information system'' security engineering, ''security assessment'', and authorization to form a comprehensive process for the implementation of dependable information
systems.
|ITSG-33 Annex 5
|-
|'''''Injury'''''
|The damage to the ''national interests'' and ''non-national interests'' that business activities serve resulting from the ''compromise'' of ''IT assets''.
|[HTRA, Reference 1, adapted]
|-
|'''''Injury Level'''''
|The severity of an ''injury''. Five levels are defined: very low, low, medium, high, very high.
|ITSG-33 Annex 5
|-
|'''''Integrity'''''
|The state of being accurate, complete, authentic, and intact.
Note: Integrity is generally applied to ''information assets''. Integrity can also be applied to ''business processes'', software application logic, hardware and personnel.
|DDSM, Reference 6
|-
|'''''Integrity Security Objective'''''
|To ensure the ''integrity'' of a ''business activity'' or ''IT asset'' against a specified set of ''threats'' in order to prevent ''injury'' to ''national interests'' or ''nonnational interests''.
|ITSG-33 Annex 5
|-
|'''''Intermediate Architecture'''''
|Provides detailed and context-specific information required to implement one of the transition states described in a ''transition strategy and roadmap''.
|ESA Framework
|-
|'''''IT Asset'''''
|A generic term used to represent business applications, electronic representations of information (''data''), and the hardware, software, and system ''data'' that ''information systems'' are composed of.
|ITSG-33 Annex 5
|-
|'''''IT Security'''''
|The discipline of applying ''security controls'', ''security solutions'', tools, and techniques to protect ''IT assets'' against ''threats'' from ''compromises'' throughout their lifecycle, based on the ''security category'' of supported business activities, and in accordance with departmental and GC policies, directives, standards, and guidelines. These securirty controls are intended to preserve the ''confidentiality'', ''integrity'', availability, intended use and value of electronically stored, processed or transmitted information.
Note: Protecting ''IT assets'' helps protect departmental business activities and therefore departmental mission and objectives.
|ITSG-33 Annex 5
|-
|'''''IT Security Function'''''
|The elements of a ''departmental security program'' that are dedicated to the protection of departmental ''IT assets''.
|ITSG-33 Annex 5
|-
|'''''IT Security Incident'''''
|Any unexpected or unwanted event that might cause a ''compromise'' of ''IT assets''.
|MITS, Reference 3, adapted
|-
|'''''IT Security Risk'''''
|The potential that a given ''threat'' will ''compromise'' ''IT assets'' and cause ''injury''.
|HTRA, Reference 1, adapted
|-
|'''''IT Security Risk Management'''''
|The process by which organizations manage ''IT security risks''. ''IT security risk'' management is achieved through ''IT security'' and other ''risk management'' processes.
|ITSG-33 Annex 5
|-
|'''''IT Threat'''''
|Any potential event or act, deliberate, accidental or ''natural hazard'', that could ''compromise'' ''IT assets''.
|HTRA, Reference 1, adapted
|-
|'''''Justify (Justification)'''''
|Provide a conclusion gained by an analysis that is more rigorous than a demonstration but less rigorous than a proof. It requires significant rigour in terms of very carefully and thoroughly explaining every step of a logical argument.
|CC, Reference 5, adapted from justification
|-
|'''''Logical Access Control Systems (LACS)'''''
|An electronic system that controls an individual’s ability to access one or more computer system resources such as a workstation, network, application, or database.
|[[ICAM|GC ICAM]]
|-
|'''''Management Security Control'''''
|A ''security control'' that focuses on the management of ''IT security'' and ''IT security risks''.
|NIST FIPS 200, Reference 11, adapted
|-
|'''''Monitor (Monitoring)'''''
|The continuous process of observing the operations of ''information systems'' with the objective of detecting deviations from planned or expected behaviour.
|ITSG-33 Annex 5
|-
|'''''Must'''''
|This word means that the statement is a mandatory requirement.
|RFC 2119, Reference 8, adapted
|-
|'''''Natural Hazard'''''
|A ''threat'' attributable to forces of nature.
|HTRA, Reference 1
|-
|'''''National Interests'''''
|The security and the social, political, and economic stability of Canada.
|PGS, Reference 2
|-
|'''''Non-National Interests'''''
|The safety, health, and well being of individuals, and the financial position and reputation of individuals and Canadian companies.
|PGS, Reference 2, SOAS, Reference 10, adapted
|-
|'''''Non-Person Entity (NPE)'''''
|Any type of non-human device (e.g., routers, servers, firewalls, mobile devices such as smart phones), application or software object.
|[[ICAM|GC ICAM]]
|-
|'''''Operational Concept (OpsCon)'''''
|verbal and graphic statement of an organization's assumptions or intent in regard to an operation or series of operations of a system or a related set of systems
|ISO/IEEE 29148
|-
|'''''Operational Security Control'''''
|A ''security control'' that is primarily implemented and executed by people and is typically supported by the use of technology, such as supporting software.
|NIST FIPS 200, Reference 11, adapted
|-
|'''''Orphaned Account'''''
|An ''account'' belonging to a user that has left the organization or no longer requires access to the resource. Orphaned accounts are most often the result of ineffective de-provisioning processes wherein user access privileges are not removed immediately upon a user leaving the organization. These accounts create security vulnerabilities, which may be exploited by individuals seeking to do harm.
|FICAM Glossary
|-
|'''''Physical Access Control Systems (PACS)'''''
|Systems controlling access to physical areas or assets (e.g., buildings, restricted zones).
|GC ICAM
|-
|'''''Principal'''''
|Participating entity in an ''information system'' (physical person, legal person, role, equipment, channel, automated process).
|ITSG-33 Annex 5
|-
|'''''Privilege Management'''''
|A set of processes for establishing and maintaining the entitlement or privilege attributes that comprise an individual’s access profile. These attributes are features of an individual that can be used as the basis for determining access decisions to both physical and logical resources.
|FICAM Glossary
|-
|'''''Protected IT Asset'''''
|An ''IT asset'' that contains, stores, processes, or transmits ''data'' representing information that may qualify for an exemption or exclusion under the Access to Information Act or the Privacy Act because its disclosure would reasonably be expected to cause ''injury'' to ''non-national interests''.
|ITSG-33 Annex 5
|-
|'''''Protection Profile'''''
|A document used as part of the certification process according to the Common Criteria. As the generic form of a security target, it is typically created by a user or user community and provides an implementation independent specification of information assurance ''security requirements''.
|ESA Framework
|-
|'''''Public Key Infrastructure (PKI)'''''
|A cryptographic key and certificate delivery system that makes possible secure electronic transactions and exchanges of sensitive information using a system of trusted third parties called “certificate authorities.”.
|PWGSC - Information Management Fascicle 2: Information Security Glossary
|-
|'''''Recommended'''''
|Refer to the definition of should.
|ITSG-33 Annex 5
|-
|'''''Reference Design'''''
|A predefined pattern, or set of patterns, possibly partially or completely instantiated, designed, and proven for use in particular business and ''technical contexts'', together with supporting ''artifacts'' to enable their use.
|Rational Unified Process
|-
|'''''Residual Risk'''''
|A ''risk'' that remains after ''security controls'' have been selected, approved and implemented.
Note: Business owners should generally require the support of an ''information system'' with a ''security posture'' that aligns with their tolerance to ''risk''. For example, they should require the support of an ''information system'' with a ''strong security posture'' where their tolerance to ''risk'' is low. However, this may not always be the case. For example, it may be acceptable for troops to deploy in theatre to save lives with the support of ''IT assets'' having a weaker ''security posture'' than would normally be required if the consequences of not performing the mission (i.e., loss of many civilian lives) are worse (relatively) than the consequences of relying on these ''IT assets'' of weaker ''security posture'' to perform the mission (i.e., loss of some military assets).
|HTRA, Reference 1, adapted
|-
|'''''Residual Risk Level (IT Security Residual Risk Level)'''''
|The degree of ''residual risk''.
|ITSG-33 Annex 5
|-
|'''''Residual Risk Assessment'''''
|The assessment performed at the conclusion of the ''system development lifecycle'' to adjust the conclusions of the detailed ''threat and risk assessment'' to account for unresolved security deficiencies identified during the design, development, testing, and installation phases.
|ITSG-33 Annex 5
|-
|'''''Risk'''''
|refers to the effect of uncertainty on objectives. It is the expression of the likelihood and impact of an event with the potential to affect the achievement of an organization's objectives.
|TBS Framework for the Management of Risk
|-
|'''''Risk Level'''''
|The degree of ''risk''
|ITSG-33 Annex 5
|-
|'''''Risk management'''''
|A systematic approach to setting the best course of action under uncertainty by identifying, assessing, understanding, acting on and communicating ''risk'' issues
|TBS Integrated Risk Management Framework
|-
|'''''Robustness'''''
|A characterization of the ''security strength'' and security ''assurance'' of an implemented ''security control''.
|ITSG-33 Annex 5
|-
|'''''Robustness Level'''''
|A robustness level is composed of a ''security strength'' component and a ''security implementation assurance'' component. Together, these two components define the requirements that must be met in the implementation and operation of a ''security control'' to satisfy defined security ''control objectives''. Note: A ''security control'' of a higher robustness level aims to counter ''threat agents'' with more sophisticated capabilities, or ''accidental threats'' and ''natural hazard''s of higher magnitude.
|ITSG-33 Annex 5
|-
|'''''Roots of Trust'''''
|Security primitives composed of hardware, firmware and/or software that provide a set of trusted, security-critical functions. They must always behave in an expected manner because their misbehaviour cannot be detected. As such, Roots of Trust need to be secured by their design. Hardware Roots of Trust are preferred over software Roots of Trust due to their immutability, smaller attack surface, and more reliable behaviour.
|NIST SP 800-164
|-
|'''''Scenario'''''
|A scenario is a refinement of a ''use case'' (see ''Use Case'') that shows a sequence of interactions between the system and the user (actor) and/or external systems. It may also show interactions between ''components'' internal to the system. A single ''use case'' is often associated with multiple scenarios that show alternative interactions, including those that deal with error conditions.
|ESA Framework
|-
|'''''Security Architecture'''''
|The design ''artifacts'' that describe how the ''security controls'' are positioned, and how they relate to the overall IT Architecture. These controls serve the purpose to maintain the system’s quality attributes, among them ''confidentiality'', ''integrity'', availability, accountability and ''assurance''.
|OSA
|-
|'''''Security Assessment (Information System)'''''
|The ongoing process of evaluating the performance of ''IT security controls'' throughout the lifecycle of ''information systems'' to establish the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the departmental business needs for security. Security assessment supports authorization by providing the grounds for confidence in ''information system'' security.
|NIST SP800-39, Reference 7, adapted from ''security control'' assessment
|-
|'''''Security Assurance Level'''''
|Predefined measure of ''Robustness''
|ITSG-33 Annex 5, Adapted
|-
|'''''Security Implementation Assurance'''''
|Confidence-building tasks that aim to ensure that a ''security control'' is designed and implemented correctly, and is operating as intended, with the resiliency required to meet an ''assurance level'' expected by the business owner. This is also called “Security Assurance” in ITSG-33. Note: Security Implementation Assurance and the ''Security Strength'' (of mechanism) both characterize the ''Robustness'' level.
|Adapted from “Security Assurance” ITSG-33 Annex 5
|-
|'''''Security Implementation Assurance Level'''''
|The level of assurance achieved by completing a predefined set of ''security implemntation assurance'' tasks.
|ITSG-33 Annex 5
|-
|'''''Security Implementation Assurance Task'''''
|An action performed by a security practitioner or an assessor to establish ''assurance'' (confidence) in a specific security aspect of an ''information system''. There are two types of ''security implementation assurance'' tasks: engineering task and assessment task. Engineering tasks include the production of documentation and may need to satisfy documentation content requirements.
|ITSG-33 Annex 5
|-
|'''''Security Categorization'''''
|The process of determining the ''security category'' of business activities, ''information systems'', and ''IT assets''.
Notes:
a) Security categorization is established by assessing ''injury'' to national and ''non-national interests'' as a result of failures of business activities to meet their ''security objectives'' of ''confidentiality'', ''integrity'', and availability. ''Information systems'' and ''IT assets'' generally inherit the ''security category'' of the business activities that relate to them.
b) At the departmental level, security categorization is a continuous activity for categorizing the security of business activities to support the development of ''security control'' profiles. At the ''information system'' level, security categorization is an activity of the ISSIP for categorizing the security of the ''information system'' and its ''IT assets''. For the ''information system'', it is done early in the ''system development lifecycle''. For ''IT assets'', it is done later during the design phases when ''IT assets'' have been defined.
|ESA Framework
|-
|'''''Security Category'''''
|A security category characterizes a ''business activity'' by the severity of expected injuries (''injury level'') from ''compromise'' with respect to the ''security objectives'' of ''confidentiality'', ''integrity'', and availability.
|ITSG-33 Annex 5
|-
|'''''Security Control'''''
|An administrative, operational, technical, physical or legal measure for managing ''security risk'' (avoid, counteract or minimize ''security risks'').
|CSEC ITSG-33
|-
|'''''Security Control (IT Security Control)'''''
|A management, operational, or technical high-level ''security requirement'' prescribed for an ''information system'' to protect the ''confidentiality'', ''integrity'', and availability of its ''IT assets''. ''Security controls'' are implemented using various types of ''security solutions'' that include security products, security policies, security practices, and security procedures.
|NIST SP800-39, Reference 7, adapted
|-
|'''''Security Control Enhancement'''''
|A statement of security capability to: (i) build in additional, but related, functionality to a basic control; and/or (ii) increase the ''security strength'' of a basic ''security control''.
|NIST SP800-39, Reference 7
|-
|'''''Security Controls Mapping Matrix'''''
|A tool used to for compliance and support for SA&A analysts. It provides a complete mapping of ''security controls'' to ''components'' and ''threats'', and indirectly to patterns and ''use cases''.
|ESA Framework
|-
|'''''Security Control Objective'''''
|A statement, stated in a standardize language, that formalizes what is to be achieved by a ''security control'' to satisfy business needs for security. Note: A security control objective should be written in a way that is specific, measurable, attainable, results-oriented, and time-based. A security control objective must be measurable using performance metrics, continuous ''monitoring'', and ''security assessment''. The implementation of ''security controls'' aims to fulfill the security control objectives, in order to satisfy the business needs for security. For example, the issuance of an accurate benefits amount to an authorized recipient (citizen) is a business need for security. The security control objectives for this business need for security may be defined as a function of the positive ''authentication'' of the recipient with a defined error rate; the positive authorization of the recipient in receiving the benefits payment with a defined error rate; and the preservation of the ''integrity'' of the payment transaction event (log of the ''business process'' events) and payment record (log of the approved payment and all related information) with high confidence. The exact metrics (e.g., error rate and confidence) associated with the security control objectives need to be defined based on the injuries that could be incurred by the recipient where the business need for security is not satisfied. The metrics may be loose when the injuries are minor (an inaccurate payment amount leads to some inconvenience), or strict when the injuries are serious (an inaccurate amount leads to serious stress and financial loss).
|ITSG-33 Annex 5
|-
|'''''Security Domain'''''
|Within the context of this document, a security domain represents a collection of ''data'', ''components'', systems, devices, networks, etc. that operate under the same security policy. Before moving ''data'' between security domains, an assessment should be made to determine whether the security policy of the target domain is sufficient to protect the ''data''. If not, the transfer should be blocked or the ''data'' sanitized prior to transfer.
|ESA Framework
|-
|'''''Security Measure'''''
|Refer to the definition of ''security solution''.
|ITSG-33 Annex 5
|-
|'''''Security Mechanism'''''
|A class of ''security solutions'' rated in terms of ''security strength'' of protection and ''security implementation assurance'' to address specific ''threats''. Note: examples of classes of ''security solutions'' are: biometrics, digital signature, hot standby, anti-tampering, discretionary access control, packet filtering. Each of these classes can be implemented by various ''security solutions'' (e.g., products). For example, biometrics can be implemented using fingerprint, iris or retina scanners.
|ITSG-33 Annex 5
|-
|'''''Security Objective'''''
|Refer to the definitions of ''confidentiality security objective'', ''integrity' security objective'', and ''availability security objective''.
|ESA Framework
|-
|'''''Security Pattern'''''
|A general reusable solution to a commonly occurring problem in creating and maintaining secure ''information systems''. A technique for putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.
|OSA, TOGAF
|-
|'''''Security Posture'''''
|A characteristic of an ''information system'' that represents its resilience to a specific set of deliberate attacks and accidental and ''natural hazards'' (i.e., ''selected threats'') Note: Resilience relates not only to the capability of the ''information system'' to prevent ''threats'' but also to detect, respond, and recover from their ''compromise''s. A security posture is assessed without regard for ''unselected threats''.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Very Weak)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system’s'' ''IT assets'' is assessed as severe. This rating indicates that the ''information system'' has not been adequately built to prevent, detect, respond, or recover from ''compromises''. The department does not have in place the mechanisms to manage ''IT security incidents'' and ''compromises'', or to implement required improvements.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Weak)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system''’s ''IT assets'' is assessed as considerable. Issues characterizing an ''information system'' having a weak security posture typically include many of the following:
#The business needs for security are not fully understood and are not well documented;
#The ''security controls'' and requirements are not fully defined and are not well documented;
#The ''threats'' are not fully understood and are not well documented;
#The implemented ''security solutions'' fulfill only partially the ''security controls'' and requirements, without adequate assurance;
#The ''information system'' is not operated in a manner to maintain the security posture;
#The departmental ''IT security function'' does not perform adequate ''monitoring'' and ''security assessment'';
#The department does not have mechanisms in place to learn fromthe ''IT security incidents'' and ''compromises'' and to implement required improvements.
These elements increase the potential of ''threats'' compromising ''IT assets'' due an increase in the number or significance of exploitable vulnerabilities. In the event of a ''compromise'', the ''information system'', IT operations group, and the departmental ''IT security function'' cannot effectively detect, respond to, and recover from the ''compromise''.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Average)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system''’s ''IT assets'' is assessed as significant. Issues characterizing an ''information system'' having an average security posture may include some of the following:
#The business needs for security are not fully understood or are not well documented;
#The ''security controls'' and requirements are not fully defined or are not well documented;
#The ''threats'' are not fully understood or are not well documented;
#The implemented ''security solutions'' fulfill only partially the ''security controls'' and requirements, without adequate assurance;
#The ''information systems'' is not operated efficiently in a manner to maintain the security posture;
#The departmental ''IT security function'' does not perform efficient ''monitoring'' and ''security assessment'';
#The department does not have in place mature mechanisms to learn from ''IT security incidents'' and ''compromise''s and to implement required improvements.
These elements increase the potential of ''threats'' compromising ''IT assets'' due an increase in the number or significance of exploitable vulnerabilities. In the event of a ''compromise'', the ''information system'', IT operations group, and the departmental ''IT security function'' cannot gracefully detect, respond to, and recover from the ''compromise''.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Strong)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system''’s ''IT assets'' is assessed as minor. The key characteristics of an ''information system'' having a strong security posture include most or all of the following:
#The business needs for security are well understood and documented;
#The ''security controls'' and requirements are well defined and documented;
#The ''threats'' are well understood and documented;
#The implemented ''security solutions'' fulfill the ''security controls'' and requirements, with adequate assurance;
#The ''information system'' is operated in a manner to maintain the security posture over time;
#The departmental ''IT security function'' performs adequate ''monitoring'' and ''security assessments'' of implemented ''security controls'';
#In the event of a ''compromise'', the ''information system'', IT operations group, and the departmental ''IT security function'' can detect, respond to, and recover gracefully from the ''compromise'',thus minimizing the possibility of incurring injuries, or the severity of injuries;
#The department learns from incidents and implements any required improvements.
This rating indicates that the ''information system'' has been adequately built to prevent, detect, respond, and recover gracefully from ''compromise''.
|ITSG-33 Annex 5
|-
|'''''Security Posture (Very Strong)'''''
|This rating means that the potential for ''selected threats'' compromising an ''information system''’s ''IT assets'' is assessed as very small. The ''information system'' fully satisfies business needs for security, has been adequately built to prevent, detect, respond, and recover gracefully from ''compromise'', and is fully documented. The department has in place mature mechanisms to manage incidents and ''compromise'', learns from the experience, and implements required improvements promptly.
|ITSG-33 Annex 5
|-
|'''''Security Requirement'''''
|Any need, stated in a standardized language, that an ''information system'' must satisfy through ''IT security'' that contributes to achieving a business need for security.
|CC, Reference 5, adapted
|-
|'''''Security Requirements Traceability Matrix'''''
|A tool used to trace the correspondence between high-level business and ''security requirements'' through successively more detailed designs. The SRTM provides a cross-reference of system ''security requirements'' to ''components'', and indirectly to patterns and ''use cases''.
|ESA Framework
|-
|'''''Security Risk'''''
|An expression of the likelihood and impact of events with the potential to cause ''injury'' to information, assets, individuals or services
|ESA Framework
|-
|'''''Security Safeguard'''''
|Refer to the definition of ''security solution''.
|ITSG-33 Annex 5
|-
|'''''Security Solution'''''
|Any security function, product, practice, or procedure that is implemented
in an ''information system'' to realize a ''security control''.
|ITSG-33 Annex 5
|-
|'''''Security Strength'''''
|The characterization of an implemented ''security control’s'' potential to protect ''IT assets'' against ''compromise''s from ''threats''. Note: As the ''security strength'' increases, the effort (cost) or magnitude required by the ''threat agent'' to defeat the implemented ''security control'' also increases. The protective potential of an implemented ''security control'' can be fulfilled only when it is implemented with adequate ''security implementation assurance''.
|ITSG-33 Annex 5
|-
|'''''Security Testing'''''
|Testing conducted during the development phase and the integration and testing phase of the ''system development lifecycle'' (SDLC) and that contributes to the establishment of ''security implementation assurance''. Note: During the development phase, security testing includes functional testing of custom ''security solutions'' (e.g., functional unit testing) and may
also include other forms of testing such a negative functional testing of non-security functions (e.g., fuzz testing of URL against a web application) and the testing of operational procedures to determine usability and maintainability. During the integration and testing phase, security testing includes functional security testing and may also include ''vulnerability assessments'' and penetration testing, depending on the ''security implementation assurance'' requirements.
|ITSG-33 Annex 5
|-
|'''''Selected Threat (Selected IT Threat)'''''
|Any IT-related ''threat'' that has been deemed, through a ''threat assessment'', as relevant to a ''business activity'' or an ''information system'' and against which a department intends to protect its ''IT assets''. Note: Factors influencing the selection of ''threats'' include, for example, the resources and skill set available or not available to the organization to effectively counter a ''threat''; the limited budget allocated to ''IT security''; the assessment that some ''threat'' ''compromises'' may not lead to injuries; etc. Refer to the definition of ''threat assessment'' for more information.
|ITSG-33 Annex 5
|-
|'''''Shall'''''
|Refer to the definition of must.
|ITSG-33 Annex 5
|-
|'''''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.
|RFC 2119, Reference 8, adapted
|-
|'''''Solution Architecture'''''
|A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.
|TOGAF
|-
|'''''Solution Architecture View'''''
|''Artifacts'' developed at this layer include significant detail, are system in scope and have an operational impact.
|ESA Framework
|-
|'''''Statement of Assessment'''''
|Any recognition or acknowledgement that the assessment process has been completed with acceptable results. It can be as simple as a record of decision appearing in the minutes of an engineering or project meeting or as formal as an assessment certificate signed by a security assessor.
|ITSG-33 Annex 5
|-
|'''''Statement of Sensitivity (SOS)'''''
|Identification and categorization of relevant assets according to their ''confidentiality'', ''integrity'' and availability values based upon the injuries that may reasonably be expected in the event of a ''compromise''
|HTRA
|-
|'''''Strategy'''''
|The pattern or plan that integrates an organization’s major goals, policies, and action sequences into a cohesive whole.
|EABOK Starter Glossary
|-
|'''''System Development Lifecycle'''''
|The successive stages through which ''information systems'' are implemented (i.e., brought into service or delivered).
Note: The reference SDLC used in ITSG-33 publications consists of the following phases: 1) stakeholder engagement, 2) concept, 3) planning, 4)requirements analysis, 5) high-level design, 6) detailed design, 7)development, 8) integration and testing, and 9) installation.
|ITSG-33 Annex 5
|-
|'''''System Lifecycle'''''
|The successive stages that ''information systems'' pass through from their inception to their end of life.
Note: The reference SLC used in ITSG-33 publications consists of the following phases: 1) Initiation, 2) development/acquisition, 3) integration
and installation, 4) operations and maintenance, and 5) disposal.
|ITSG-33 Annex 5
|-
|'''''Target Architecture'''''
|The description of a future state of the architecture being developed for an organization. There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.
|TOGAF
|-
|'''''Token'''''
|In the context of GC ICAM, something that an individual or NPE possesses and controls that is used to authenticate that individual or NPE. A token can be thought of as a secure container for a secret (i.e., Token Secret) that is used to generate a Token Authenticator. Additional information regarding these concepts can be found in NIST SP 800-63-2, Section 6.
|[[ICAM|GC ICAM]]
|-
|'''''Transition Architecture'''''
|A formal description of one state of the architecture at an architecturally significant point in time. One or more Transition Architectures may be used to describe the progression in time from the Baseline to the ''Target Architecture''.
|TOGAF
|-
|'''''Transition Strategy and Roadmap'''''
|Outlines an incremental approach to evolve from current state to the ''target architecture''. Each transition state described in a roadmap provides a clear milestone with measurable business value.
|ESA Framework
|-
|'''''Technical Context'''''
|A component of a departmental or domain ''security control'' profile. A technical context defines in general terms the technical environment that might influence the selection of the profile’s ''security controls''.
|ITSG-33 Annex 5
|-
|'''''Technical Security Control'''''
|A ''security control'' implemented and executed by ''information systems'' primarily through ''security mechanisms'' contained in hardware, software, and firmware components.
Note: A technical security control is dependent on the proper functioning of the ''information system'' for effectiveness. Also, some operational aspects may be included in the implementation of the control (e.g., manual assessment of log ''monitoring'' results).
|NIST FIPS 200, Reference 11, adapted
|-
|'''''Threat'''''
|An event or act, deliberate or accidental, that could cause ''injury'' to information, assets or individuals.
|ITSG-33
|-
|'''''Threat Actor'''''
|A threat actor is an individual or organization that conducts or may conduct an attack against an ''information system''.
|ITSG-33
|-
|'''''Threat Agent'''''
|A threat agent is an autonomous entity that acts on behalf of a threat actor. A threat agent can be a human, electronic, or mechanical device that can communicate with a threat actor and act on instructions. The degree of autonomous behaviour varies with the complexity of the threat agent.
|ITSG-33
|-
|'''''Threat Assessment'''''
|The process of identifying and qualifying ''threats'' faced by an organization’s business activities and ''information systems'' supporting them. Note: A threat assessment will identify all ''threats'' faced by an organization. The ''selected threats'' are the ones that the organization chooses to address and are documented explicitly. Threats that an organization may face, but that are not addressed for various reasons, such as cost constraints, technical constraints, or operational constraints, are also documented explicitly (i.e., unselected threats).
|ITSG-33 Annex 5
|-
|'''''Threat and Risk Assessment (IT-Related TRA)'''''
|The process of identifying and qualifying ''threats'' and ''risks'' to ''IT assets'' and of implementing or recommending additional ''security controls'' to mitigate ''risks'' that are deemed unacceptable.
|ITSG-33 Annex 5
|-
|'''''Threat Context'''''
|A characteristic of a departmental or domain ''security control profile''. A threat context defines the ''selected threats'' of relevance to the domain’s business activities.
|ITSG-33 Annex 5
|-
|'''''Threat Event'''''
|The occurrence of an actual incident in which a ''threat agent'' exploits a ''vulnerability'' on an ''information system'' (which may or may not be successful at achieving the ''threat actor’s'' objectives) with potentially adverse effects on an ''IT asset'' of value.
|ITSG-33
|-
|'''''Trace/Tracing(IT)'''''
|Perform an informal correspondence analysis between two entities with only a minimal level of rigour. Tracing involves documenting a basic correspondence between the elements of successive specifications.
|ITSG-33 Annex 5
|-
|'''''Use Case'''''
|A function offered by the system that results from, or results in, interaction between the system and a user (actor) and/or external systems. A ''use case'' identifies the purpose and nature of the function, but contains no details of how it is implemented (see ''Scenario'').
|ESA Framework
|-
|'''''View'''''
|The representation of a related set of concerns. A view is what is seen from a viewpoint. An ''architecture view'' may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature.
|TOGAF
|-
|'''''Viewpoint'''''
|A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from - the vantage point or perspective that determines what you see.
|TOGAF
|-
|'''''Vulnerability'''''
|An inadequacy related to security that could increase susceptibility to ''compromise'' or ''injury''.
|ESA Framework
|-
|'''''Vulnerability Assessment'''''
|A determination of the existence of ''information system'' vulnerabilities.
|MITS, Reference 3
|-
|'''''Work Package'''''
|A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program.
|TOGAF
|}
==References==
[Reference 1] Communications Security Establishment Canada and the Royal Canadian Mounted Policy. Harmonized Threat and Risk Assessment (TRA) Methodology. 23 October 2007.
[Reference 2] Treasury Board of Canada Secretariat. Policy on Government Security.1 July 2009.
[Reference 3] Treasury Board of Canada Secretariat. Operational Security Standard: Management of Information Technology Security. 31 May 2004.
[Reference 4] Treasury Board of Canada Secretariat. Business Transformation Enablement Program (BTEP). Glossary. April 2006.
[Reference 5] Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements. CCMB-2009-07-001, Version 3.1, Revision 3. July 2009.
[Reference 6] Treasury Board of Canada Secretariat. Directive on Departmental Security Management. 1 July 2009.
[Reference 7] National Institute of Standards and Technology. Information Security. Managing Information Security Risk: Organization, Mission, and Information System View. NIST Special Publication 800-39, March 2011.
[Reference 8] Internet Engineering Task Force. RFC2119 Key words for use in RFCs to Indicate Requirement Levels. March 1997.
[Reference 9] Oxford Dictionaries Online (ODO). http://oxforddictionaries.com
[Reference 10] Treasury Board of Canada Secretariat. Security Organization and Administration Standard. 1 June 1995.
[Reference 11] National Institute of Standards and Technology. Minimum Security Requirements for Federal Information and Information Systems FIPS PUB 200. March 2006.
[Reference 12] FICAM Glossary - US Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, Version 2.0, Appendix B, December 2, 2011
[Reference 13] NIST SP 800-63-2 - National Institute of Standards and Technology Electronic Authorization Guideline, August 2013
[Reference 14] OMB M-04-04: Executive Office of the President Office of Management and Budget Memorandum on E-Authentication Guidance for (US) Federal Agencies, December 16, 2003
[Reference 15] ICAM Lexicon: Identity, Credential and Access Management Lexicon, National Security Systems Identity, Credentialing and Access Management Focus Group, Version 1.0, 30 May 2013
[Reference 16] Directive on Identity Management – Directive on Identity Management, Government of Canada, July 1, 2009
[Reference 17] Standard on Identity and Credential Assurance – Standard on Identity and Credential Assurance, Government of Canada, February 1, 2013
[Reference 18] Guideline on Defining Authentication Requirements – Guideline on Defining Authentication Requirements, Government of Canada
[Reference 19] Draft Guideline on Identity Assurance – draft Guideline on Identity Assurance, Government of Canada, January 21, 2014
[Reference 20] Open Security Architecture Glossary (http://www.opensecurityarchitecture.org/cms/definitions/glossary), Accessed July 24th 2014
