IS.I.OR.205 Information security risk assessment

Part-IS does not require the use of any specific information security framework, such as ISO, NIST or others to develop the risk assessment or in general to implement risk management. Each framework offers different benefits and none of these frameworks is perfect for an individual organisation, and should be customised and tailored to meet the overall needs of an organisation as well as the specific need to consider aviation safety aspects. Organisations whose information security frameworks have achieved industry certifications can provide this information as supporting artefacts; however, these organisations should show the applicability of the industry certification to the scope of this Regulation (see GM1 IS.I.OR.200). General guidance on risk management, including risk assessment, can be found in ISO/IEC 27005 and ISO/IEC 31000 as well as NIST SP 800-30. Aviation organisations may also wish to consider aviation-specific guidance as defined in the risk management chapter of the latest version of EUROCAE ED-201A and, as appropriate to the specific operating environment, in the chapters of EUROCAE ED-204A, EUROCAE ED-205A and EUROCAE ED-206 covering risk management.

When conducting an information security risk assessment, the organisation should ensure that all relevant aviation safety elements are identified and included in the ISMS scope as per IS.I.OR.200 and related AMC. A means to comply with the requirement in point IS.I.OR.205(a) is to perform a preliminary high-level risk assessment or impact assessment, carried out in accordance with a documented methodology and following precise criteria for the inclusion in and exclusion from the ISMS scope of the elements listed in IS.I.OR.205(a).

SCOPE AND BOUNDARIES IDENTIFICATION The organisation should develop clear and comprehensive understanding of its aviation activities and services, the related processes and associated information systems, and the relevant data flows and information exchanges that define the scope of the ISMS and the boundaries for risk assessment. Therefore, the organisation should develop corresponding documentation on resources and dependencies related to computing, networking and contracted services which have the potential to affect the information security and safety of the functions, services or capabilities within the scope of the risk assessment. The following non-exhaustive list provides examples of items that may be considered for the identification of the aforementioned scope and boundaries. The level of detail of the analysis can be an iterative process, with the effort commensurate with the expected level of risk. As stated above, the purpose is to establish understanding of all relevant assets, resources and dependencies that are directly a part of the functions, services and capabilities through the following activities:

(a)Identification of operational inputs and outputs relevant to the functions, services and capabilities of the organisation; these can be related to: internal or external sources; internal or external leased or managed services, or other dependencies;

(b)Identification of all relevant assets (i.e. hardware, software, network and computing resources) used to create, process, transmit, store or receive the aforementioned operational inputs and outputs;

(c)Identification of the operating environments (e.g. office, public access area, access-controlled room, etc.) and locations for all relevant assets;

(d)For each asset included in the scope, identification of the specific methods, processes and resources that will be used to manage, operate and maintain each asset throughout its life cycle, including: internal or contracted resources; contracted companies remotely managing the assets (i.e. provider of managed services).

The organisation should, as part of the information security risk assessment, identify the interfaces it has with other parties such as service providers, supply chains and other third parties, based on the exchange of data and information and the assets used for that exchange, which could lead to a situation where information security risks, as a result of mutual exposure, may either: increase aviation safety risks faced by other parties; and/or increase aviation safety risks faced by the organisation.

RISK INFORMATION SHARING Interfacing organisations should share information with each other about the potential exposure to information security risks by following, for instance, the approach detailed in EUROCAE ED-201A, Appendix B — B.1, B.2 and B.3. The purpose of this exchange of information is to enable organisations to establish a matching mapping for the services identified under IS.I.OR.205(a), including all information and data flows, in order to:

(a)illustrate (e.g. through a functional diagram) the relationships of logical and physical paths connecting the different parts involved;

(b)clearly identify all assets (i.e. hardware, software, network and computing resources) that will be used in the exchange;

(c)identify all functions, activities and processes, including their respective information and data, which will be created, transmitted, processed, received and stored, and associate those with the responsible party which provides or performs those functions, activities and processes;

(d)determine for these paths, constituting the so-called functional chains, the role of the interfacing party as a producer, processor, dispatcher or consumer of the information or data involved;

(e)determine whether one interfacing party acts as an originator or receiver of a flow across such path.

TWO CATEGORIES OF INTERFACING ORGANISATIONS There are two categories of interfacing organisations: those that are subject to Regulation (EU) 2023/203 or Regulation (EU) 2022/1645, and those that are not. Where the organisation has interfaces with an organisation that is subject to Regulation (EU) 2023/203 or Regulation (EU) 2022/1645, each entity: is responsible for the identification of the interfaces that its own organisation has with other organisations, and which could result in the mutual exposure to information security risks. The entity may benefit from the sharing of risk information as this exchange allows for a more accurate assessment of those risks; remains accountable for the proper management of the information security risks within the scope of its own ISMS. In all other cases, the organisation is accountable for the proper management of the information security risks that may arise from its exposure to the interfacing entity. Where these risks need to be treated, the organisation always has the option of implementing mitigating measures and controls within its own boundaries. In the specific case where the interfacing entity is a supplier, the organisation may decide to manage the risks through contractual arrangements and require the supplier to implement mitigating measures and controls within its own organisation.

EXAMPLES OF AVIATION SERVICES Examples of aviation services that may be considered when determining the ISMS scope and interfaces are provided in Appendix III.

The organisation should use a risk management framework that includes a methodology for assigning risks with a risk level and establishing criteria for determining risk acceptance or further treatment. The organisation should provide documented evidence of assessment of risks which have a potential impact on aviation safety including the level of risks. The organisation should associate each risk with the relevant elements and interfaces identified under IS.I.OR.205 (a) and (b), and document whether the risk is acceptable or requires further treatment. The organisation should provide the assurance that the risk assessment process is carried out with the necessary rigour and discipline by documenting the process and its robustness. By doing so, the organisation should consider:

(a)reproducibility of the assessment’s results for similar inputs;

(b)repeatability of the assessment over time in a way that the results of the different prior assessments can be compared to determine the changes;

(c)the gathering of inputs that are relevant and valid, in particular:

(1)the information that allows the determination of the safety consequences;

(2)the information that allows the determination of the potential of occurrence of the threat scenario;

(d)iterative refinement over time allowing for more fine-grained threat scenarios as inputs to become available, with the aim of reducing uncertainty regarding threats, vulnerabilities, effectiveness of existing controls, and dependencies on external entities, in particular by:

(1)refining initial high-level threat scenarios with greater detail and specificity as more data is gathered;

(2)refining data on known vulnerabilities by continuously updating information about their exploitability and the associated consequences;

(3)reviewing the effectiveness of existing controls, and consider newly available controls;

(4)refining the understanding of the dependencies on external entities and their implications for the organisation’s risk profile.

RISK ASSESSMENT The risk classification levels for the potential of occurrence of the threat scenario and severity of the safety consequences listed below may be applied; however, this does not prevent the organisation from developing additional intermediate categories if it deems this necessary for risk assessments. The organisation should specify and document the applied, organisation-specific classification levels with an accurate qualitative or quantitative definition in terms of a range or interval of numerical values in order to enable a sufficiently calibrated, consistent estimation, evaluation and communication within the organisation or with the interfacing entities. The potential of occurrence of the threat scenario may be expressed as an interval of likelihoods including the duration of the observation. Supporting documentation and methods can be found in EUROCAE ED-203A, Chapter 3.6 which references the evaluation of the potential of occurrence of the threat scenario in the Security Risk Assessment of EUROCAE ED-202A. Note 1: The phrase ‘duration of the observation’ refers to the time period during which a threat scenario is observed or monitored. It is essential in determining the likelihood of the threat scenario occurring, since the probability of occurrence may vary depending on the length of the observation period. Note 2: EUROCAE ED-202A and EUROCAE ED-203A were originally developed for aircraft information security risk assessment, but the generic principles developed in those documents can be adapted to other frameworks when deemed useful by the organisation. In order to facilitate the mutual comparability of risk assessment methodologies between interfacing organisations, the organisation may associate the assessment of the potential of occurrence of the threat scenario with one of the following categories: High potential of occurrence: the threat scenario is likely to occur. The attack related to the threat scenario is feasible and similar threat scenarios have occurred many times in the past. Medium potential of occurrence: the threat scenario is unlikely to occur. The attack related to the threat scenario is possible and a similar threat scenario may have occurred in the past. Low potential of occurrence: the threat scenario is very unlikely to occur. The materialisation of the threat scenario is theoretically possible; however, it is not known to have occurred. The evaluation of the potential of occurrence of the threat scenario may be based on the following aspects: Protection (as defined in EUROCAE ED-203A) Security measures and architecture that deny access to assets: the degree to which an asset is open to access from compromised systems Access to security measures: the degree to which a security measure prevents access/attack to itself from compromised systems Failure of mechanism: the degree to which the known implementation of a security measure will fail to prevent an attack Detection methods or procedures to recognise the attack and appropriately respond to reduce the potential of occurrence of the threat scenario Exposure reduction (as defined in EUROCAE ED-203A) Conditions under which an external access connection can be used by a user or attacker Limits on the functionality of an external access connection Organisational policies that control the time-to-feasibility for developing attack tools specific to the product Vulnerability management including intelligence, scanning, treatment and retesting aimed to discover, detect and treat reported or detected vulnerabilities in a fast, risk-prioritised manner with high assurance in order to reduce the attack surface Reduction of the severity of a successful attack (i.e. through a redundant system that can maintain the continuity of service in case of a denial of service of a system critical for aviation safety) Attack attempt (as defined in EUROCAE ED-203A) The capability of the attackers which is determined by the resources and expertise required for their attack The capability of the attackers can be assessed through several ways, for instance: information from computer emergency response teams (CERTs) / computer security incident response teams (CSIRTs), information sharing and analysis centres (ISACs); analyses of past activities, techniques and procedures (TTPs) and success rate of attacks. For the same reason the organisation may associate the outcome of the evaluation of the severity of the safety consequences with one of the following categories: High severity: those immediate or delayed scenarios that can cause or contribute to an unsafe condition where an unsafe condition means an occurrence associated with the operation of an aircraft in which: a person is fatally or seriously injured; the aircraft sustains damage or structural failure; the aircraft is either missing or completely inaccessible; Moderate severity: those immediate or delayed scenarios that can cause or contribute to safety incidents where an incident means any occurrence other than an accident, associated with the operation of an aircraft, which affects or could affect the safety of operations; Low severity: those immediate or delayed scenarios that can cause or contribute to negligible safety consequences. Examples for high, moderate, and low severity can be found in EUROCAE ED-201A, Appendix B for products, ATM systems and airspace. If the organisation cannot determine the safety effect, the assessment should identify assumptions from the risk-sharing information at interfaces with other organisations along the functional chain, leading up to the safety effect. Some of those assumptions can be granted with the certification of products: where assets are subject to product certification from other aviation regulations addressing product information security, the organisation performing the risk assessment may consider the perimeter of the product certification as already covered. This should be acceptable under the condition that this certification is valid and that the instructions provided by the OEM to maintain the certification validity are implemented by the organisation. Additional information can also be found in Regulation (EU) 2015/1018 on mandatory reporting of occurrences in civil aviation. Further examples of impact severity classifications for aviation domains can be found in EUROCAE ED-201A, Appendix B — Tables B-5, B-6 and B-7. Risk acceptance criteria Risk acceptance criteria are critical and should be developed, specified and documented. The criteria may define multiple thresholds, with a desired target risk level, but allowing also for the accountable manager or delegated person(s) to accept risks above this level under defined circumstances and conditions. In order to facilitate the mutual comparability of risk assessments between interfacing entities, the organisation should classify the risks in the following categories: unacceptable risk; conditionally acceptable risk; acceptable risk. For what concerns the conditional acceptance of risks, the criteria for acceptance should take into account how long a risk is expected to exist (temporary or short-term activity or exposure), or may include requirements for the commitment of future treatments to reduce the risk at an acceptable level within a defined time duration and show how the risk will be managed over time through the organisation’s risk governance processes. Moreover, risks should be conditionally accepted only under the condition that the organisation demonstrates the presence of a comprehensive risk management structure that includes risk assessment, risk treatment and risk monitoring processes for operations. The risk management should consider the variability and consistency of threat likelihood, vulnerability, existing controls, external dependencies and safety impact. This is typically achieved when the organisation reaches a higher level of maturity that is representative of functionality and repeatability of information security risk management — see GM1 IS.I.OR.260(a). The following Figure 1 depicts a risk acceptance matrix based on the aforementioned categories that can be used by interfacing organisations for mutual comparability.

Figure 1: Example of a risk acceptance matrix for comparison purposes * The potential of occurrence of the threat scenario is reassessed in a timely manner (refer to IS.I.OR.205(d)) and monitored to ensure that it remains low and that if the risk materialises, it is early detected and dealt with.

A comprehensive risk management structure typically entails the following aspects and processes: a repeatable and reproduceable risk assessment. If the risk factors are considered fairly uncertain and within some wide value range or not sufficiently precise, further iterations of the risk assessment are performed involving additionally gathered or detailed information and a more in-depth assessment in order to reduce uncertainty and increase precision; a thorough review of those risks proposed to be conditionally acceptable that is performed by the accountable manager or delegated person(s) who may impose additional conditions for the risk retention, including risk treatment measure and the timeline for its implementation; strict monitoring of the key risk indicators that includes a defined, reliable detection of the potentially evolving risk materialisation; an incident response scheme is in place with reactive measures that are triggered by detection mechanisms in order to immediately contain the consequences, in particular, for risk scenarios involving a high severity level. Note: As detailed in NIST SP-800 Rev.1, repeatability refers to the ability to repeat the assessment in the future, in a manner that is consistent with and hence comparable to prior assessments — enabling the organisation to identify trends. Therefore, a risk assessment process can be classified as ‘repeatable’ when under similar conditions an entity or a person delivers consistent results. As detailed in NIST SP-800 Rev.1, reproducibility refers to the ability of different experts to produce the same results from the same data. Therefore, a risk assessment process can be classified as ‘reproducible’ when another entity or person, given the same inputs, assumptions, information security context and threat environment can replicate the same steps and reach the same conclusions. Threat scenario identification A threat scenario is one of the possible ways a threat could materialise. Typically, a threat scenario describes a potential attack targeting one or more vulnerabilities of assets, as well as processes. The purpose of the threat scenario identification under this Regulation is to develop a list of scenarios that may lead to an information security threat having an impact on aviation safety. A threat scenario, in general, is characterised by the following: a threat source of the information security attack; an attack vector and a path through the organisation up to the asset; the information security controls that would mitigate the attack; the consequence of the attack including the affected safety aspects. Threat scenario identification guidance can be found in EUROCAE ED-202A, Chapter 3.4. This is not the only source where guidance can be found, and the organisation may refer to different guidance more appropriate for their application. Additional methods to identify relevant threat scenarios When conducting this analysis, both information security and safety aspects should be coordinated throughout the process to ensure mutual understanding of the threat preventive measures and mitigating measures being applied. In the following Figure 2 the interactions between information security and aviation safety are depicted through a ‘bow-tie’ diagram that highlights the links between risk controls and the underlying management system. [Figure or form omitted from this preview — available in the Avioverse workspace library.] Figure 2: Interactions between information security and aviation safety risk management areas

Note: A preventive barrier or measure is a proactive action or control implemented to reduce the likelihood of a risk, hazard, or threat materialising, while a mitigating measure is an action or control designed to reduce the severity or impact of an undesired event, would it occur. Examples of threat scenarios Threat catalogues may provide guidance and elements for the elaboration of threat scenarios that are relevant for the organisation. References can be found in ARINC 811 – Att. 3 – Tables 3-7 and 3-8 for the threat catalogues examples and other threat catalogue examples as they are provided by EU institutions — for example, the ENISA threat taxonomy. However, this is not an exhaustive list of examples, and the identification of threat scenarios should therefore not be limited to those examples only. In addition, other relevant resources containing information on information security threats and the information security threat landscape should be consulted to support the risk assessment process with relevant inputs. A set of examples of threat scenarios can be found in Appendix I.

The organisation should take into account the following criteria when establishing compliance with the objectives contained in point IS.I.OR.205(d):

(a)The risk assessment performed under points IS.I.OR.205 (a), (b) and (c) should be reviewed at regular intervals to identify and account for relevant changes. The periodicity at which potential changes have to be evaluated should be determined by the organisation performing the assessment considering the criticality of the assets within the scope of the risk assessment, levels of residual risk of the assets within the scope of the risk assessment and any contractual or regulatory requirements. A higher criticality or level of risk will require more frequent review.

(b)The periodicity of risk assessment reviews should be documented by the organisation and include the justification, date of approval and information about the risk owner.

The criteria to consider for the frequency of the risk assessment review may be the risk level as well as the criticality and complexity of the assets concerned. The objective of a risk assessment review is to trigger the revaluation of risks, their likelihood and impact in case of relevant changes. One possible way is to have a tiered approach to risk assessment, with a higher-level risk assessment being used for the identification of changes. The higher-level risk assessment could allow the identification of the detailed risks that should be reviewed in a next step. Risk assessments should be subject to regular reviews to:

(a)allow for continuous improvement of the quality of risk assessment;

(b)ensure efficiency and effectiveness of risk controls and mitigating measures in both their design and operation;

(c)review plans and actions for risk treatment;

(d)identify any organisational change which may require a review of the priorities as well as of the treatment of risks;

(e)maintain an overview of the complete risk picture; and

(f)identify any emerging risks. Risk assessment reviews should involve the risk owners, project teams and other stakeholders as applicable. Evidence of risk assessment review should be documented and should include: evidence of approval of the review by the designated risk owner; and the rationale behind or basis for the risk owner’s approval of the review. Such evidence may comprise, but is not limited to: reports which constitute a form of documentation to track information security risks potentially impacting an organisation; the documentation of the information security risk assessment; exerts from a business or security risk register. The periodicity of risk assessment reviews should also be documented by the organisation in information security manuals, processes or procedures and should align with wider change management activities and management reviews of information security. Further guidance on criteria and frequency of risk assessment review can be found in EUROCAE ED-201A, Chapter 4, as well as in EUROCAE ED-205A, Chapter 3.2 (for ATMS/ANS).

The following are examples of changes that should be identified during the risk assessment review as they may trigger an update of the risk assessments:

(a)there is a change in the elements subject to information security risks as identified in IS.I.OR.205(a); a change in the elements will include: additions to, or removals from, the scope of the risk assessment of individual elements; changes to design or configuration of elements within the scope of the risk assessment that have the potential to alter the risk assessment outcomes; or changes to values, which would potentially trigger changes to impact levels, of elements within the scope of the risk assessment;

(b)there is a change in the interfaces between the organisation and other organisations with which the organisation shares information security risks or relies upon to mitigate information security risks (e.g. supply chains, service providers, cloud providers and customers), as identified in IS.I.OR.205(b), or between the system within the scope of the risk assessment and any other interconnected systems, or in the risks notified to the organisation by other organisations, as identified in IS.I.OR.205(b), or owners or managers of the other systems including: establishment of new interfaces; removal of existing interfaces; changes to existing interfaces that would have the potential to alter the risk assessment outcomes. Note: Some organisational or system interconnections may be with organisations that are not within the scope of this Regulation as defined in Article 2 and therefore are not subject to the requirements of Part-IS. Where this is the case, these organisations should be informed of their responsibility to report such changes as listed above through contractual arrangements and reporting requirements between the affected organisations on a case-by-case basis and where applicable;

(c)there is a change in the information or knowledge used for the identification, analysis and classification of risks including: changes to threats and their values or addition of new threats that have not previously been assessed; changes to vulnerabilities or addition of new vulnerabilities that have not previously been assessed; changes in impacts or consequences of assessed threats or vulnerabilities; changes in aggregation of risks that may result in unacceptable levels of risks; changes or improvements in the risk management process, risk assessment approach and related activities; changes or improvements in the treatments of risks; changes in the criteria used to determine acceptance and treatments of risks;

(d)there are lessons learned from the analysis of information security incidents including: understanding why and how incidents have occurred; and reviewing all types of incidents including those due to external factors, technical reasons, human errors (inadvertent behaviour). For human intentional acts, a distinction can be made between malign and benign actions.

SAFETY SUPPORT ASSESSMENT Non-ATS providers should conduct a safety support assessment as it is described in Regulation

(EU)2017/373 to assess the information security risk on their assets in regard to the service specification, e.g. integrity and availability, and to identify the residual risk. The non-ATS provider should share with the ATS provider, in an appropriate form, information on the residual risk and the impact on the services it provides to that ATS provider. The residual risk should be used to assess the potential impact on services and products that a non-ATS provider offers to an ATS provider. The ATS provider can use this as an input for its security risk assessment and, more importantly, to evaluate the potential impacts of these residual risks on safety.

SAFETY SUPPORT ASSESSMENT Table 1 below shows the non-ATS providers which shall comply with Subpart C of Annex III to Regulation (EU) 2017/373. These are the organisations having to conduct the safety support assessment in order to provide the required information to ATS providers. The information on the impact on products and services could be shared between non-ATS providers and ATS providers through agreed means, e.g. service level agreement, external agreement (in line with EUROCAE ED-201A), etc. Shared information should enable ATS providers to perform an accurate assessment of the residual risk for their services. For instance, if the non-ATS providers identified a risk which could affect the availability of data provided to an ATS provider, the impact on the availability should be described in a way that allows the ATS provider to assess whether the resulting latency or delay in data transmissions could have a safety impact. This is relevant because only the ATS provider through its assessment can either accept or decline a residual risk.

Table 1: Non-ATS providers which shall comply with Subpart C of Annex III to Regulation (EU) 2017/373 [Figure or form omitted from this preview — available in the Avioverse workspace library.]