IS.AR.215 Information security incidents — detection, response and recovery

Without prejudice to the definition of ‘information security event’ in Article 3 of Regulation (EU) 2023/203, those events that indicate the potential materialisation of unacceptable risks include both occurrences (i.e. anything that causes harm or has the potential to cause harm) and discovery of vulnerabilities. In fact, information security risks are associated with the potential that threats will exploit vulnerabilities, therefore the discovery of an exploitable vulnerability is an information security event. In light of this, in the context of this Regulation: detection activities required under IS.AR.215(a) include vulnerability discovery; response activities required under IS.AR.215(b) include vulnerability management.

DETECTION When complying with the requirement in IS.AR.215(a), the competent authority should define and implement a strategy to detect information security incidents which may have a potential impact on safety. This should be done in a way to ensure that at least the detection strategy is able to cover all known information security threats to their assets that may materialise in a safety hazard having an unacceptable consequence.

DETECTION STRATEGY In order to determine the scope of the event detection, the competent authority should:

(a)identify a list of threat scenarios from the risks identified under IS.AR.205;

(b)identify, as a minimum, those assets that, if compromised, contribute to the scenario(s) that may materialise in an unsafe condition. For this identification of the assets, the measures introduced under IS.AR.210 should also be considered. Note: The contribution of an asset to the threat scenario and the materialisation of an unsafe condition should be assessed also by considering the whole functional chain. In some cases, the asset may be at the end of a functional chain and if it is compromised, the effect on safety is direct and may be immediate; conversely, if the asset is far from the end of a functional chain and it is compromised, the effect should propagate and may be delayed.

DETECTION STRATEGY When developing the detection strategy, for those items within the scope of event detection, the competent authority should define the conditions that trigger a process that, for example, would require personnel intervention and further analysis. These conditions on the items may be defined using elements from the:

(a)expected functional baseline: engage in the identification of deviations from the expected functional operation of the system (excluding information security functions/controls);

(b)expected information security baseline: engage in the identification of deviations from the expected information security operation of information security controls. These conditions should consider both abnormal behaviour and substantial deviations from the baselines and relevant correlation of multiple independent events. Further guidance on the objectives for the establishment of a detection strategy can be found in EUROCAE ED-206, Chapter 4.

(a)INCIDENTS The competent authority should take into account the following aspects when establishing compliance with the objectives contained in point IS.AR.215(b) relative to incidents:

(1)Preparation of procedures and delineation of roles and responsibilities to respond in a timely, effective and orderly manner to any relevant information security incidents.

(2)The response procedure should:

(i)consider the warnings, unitary or combined, from IS.AR.215(a)(2), and assess their potential impacts on aviationsafety;

(ii)establish, in accordance with IS.AR.215(b)(2), a containment strategy for each asset category considering the potential worst-case effect and the mission constraints, and provide criteria indicating when the incident is contained;

(iii)define, in accordance with IS.AR.215(b)(3), the acceptable impact on safety and information security of each asset in scope when they fail due to the materialisation of a threat scenario.

(3)The response time should be commensurate with the impact level assessed in (2)(iii).

(4)The response measures implemented under IS.AR.215(b) should be based on the response procedure referred to in the above point (a)(2) and they should, in particular, consider the following:

(i)the maximum acceptable safety level degradation of the assets within the scope of the incident;

(ii)the actions, such as resistance, containment, deception and control of the possible ways systems can fail, which will contribute to achieving the acceptable safety level degradation identified in point (i) while minimising impact on operations;

(iii)the resources required to implement the actions specified in point (ii).

(5)The response time and the measures should take into account the potential immediate negative impact on safety if the measure is taken before it has been fully verified that it would not cause additional immediate safety impacts.

(b)VULNERABILITIES The competent authority should take into account the following aspects when establishing compliance with the objectives contained in point IS.AR.215(b) relative to vulnerabilities:

(1)Establishment of a vulnerability management strategy defining procedures, roles and responsibilities to respond in a timely, effective and orderly manner to any detected relevant vulnerabilities.

(2)The response measures implemented under point IS.AR.215(b) should be based on the maximum acceptable risk of the items within the scope of the vulnerability, considering the worst-case scenario of the vulnerability being exploited.

(3)The response time should be commensurate with the pre-triage done on the warnings and with the assessment of the potential impact of the vulnerability, if it is exploited.

An attack is considered contained (i.e. it is not spreading any further) when the boundaries of the incident have been identified and the threat does not propagate beyond these boundaries. Further guidance can be found in EUROCAE ED-206 – Chapter 5. The term ‘warning’ as used in IS.AR.215 should be understood as an alert that would require timely awareness and response from the information security events management team. In the context of information security response, ‘deception’ refers to a range of techniques that aim to mislead potential attackers or malicious users, thereby protecting the system and its data. Deception techniques, such as honeypots or breadcrumb trails, are designed to confuse, slow down, or divert attackers, increasing their cost and risk while providing defenders with valuable time and intelligence. Guidance regarding the vulnerability management strategy can be found in EUROCAE ED-206, Chapter 3.4 — Vulnerability management considerations. This is not the only source where guidance can be found, and the organisation may refer to different guidance more appropriate for their application.

When complying with the requirement in IS.AR.215(c), the competent authority should develop an incident recovery procedure including at least the following:

(a)a list of those assets that enable safe operations, as well as the dependencies among them, constituting the scope of the recovery;

(b)a description of the process with the necessary priority actions to be executed for a return to a safe and secure state for the assets within the scope of the recovery;

(c)the resources required to execute the actions defined in point (b) to ensure that these resources are readily available after an incident has occurred;

(d)the objectives for recovery time that should be set in relation to the safety criticality of the assets within the scope of the recovery.

RECOVERY OBJECTIVES AND TIMING Point IS.AR.215(b) addresses event conditions which may develop or have developed into information security incidents, that may have a potential impact on aviation safety, and require response and recovery measures to be in place to ensure that operational safety remains above a minimum acceptable level. The level of operations and safety may be interrelated, so in some cases when the level of operations is compromised by an information security incident and drops, the level of safety does the same. This is, for instance, the case of air traffic control; if air traffic services are reduced or became unreliable, the safety of flights is reduced too. However, in other cases the relation between the level of operations and safety may be the inverse, or they may be decoupled, so when an incident occurs and the level of operations drops, the level of safety is preserved. One example is the compromise of the software loading process on board the aircraft. In this case, a detected incident followed by the decision to interrupt the software loading operations would preserve the existing level of safety. The following Figure 1 depicts a conceptual framework that may be considered for the definition of the response and recovery objectives, including the recovery time. It represents, in the worst-case scenario, how the expected level of operational safety (safety level) for a process or an activity may vary over time when an information security incident occurs. In this scenario, the safety level is first reduced by the incident and then it degrades as long as the time passes. The figure also shows the expected effect that mitigating measures and controls should have, respectively: in containing the operational safety drop as soon as an incident occurs, and in improving the recovery, i.e. the return to the expected safety level. [Figure or form omitted from this preview — available in the Avioverse workspace library.] Figure 1: Conceptual framework for the definition of the response and recovery objectives

As mentioned, there might be different relations between the level of operations and safety that would lead to a different representation of the above figure. In certain cases, an incident may have a delayed effect on the safety level (e.g. a compromised development environment) as depicted in Figure 2, or it may have no impact if properly controlled, as in the case of the compromised software loading process mentioned before, which is depicted in Figure 3. [Figure or form omitted from this preview — available in the Avioverse workspace library.]

Moreover, it should be noticed that there might be different ways the same incident can be dealt with since there are several factors that may affect safety. In practical terms, the objectives for recovery time under AMC1 IS.AR.215(c) may be expressed as a list of resources and services to be restored by order of priority, within the scope of the recovery. Guidance about objectives for recovery time can be found in EUROCAE ED-206, Chapter 7.3.5.

A recovery procedure or recovery plan should describe incident recovery actions and the internal or external resources that are involved (e.g. staff, IT, buildings, providers). Guidance about incident recovery plan can be found in ED 206, Chapter 7 – Recover. The resources required to apply the recovery measures should be available in order to implement the recovery actions in a timely manner after an incident has occurred. Those resources may be internally available or provided by contracted organisations as provided for in IS.AR.220. The contracting of recovery activities should be established before an incident occurs (proactive) and the contract should include provisions for the contracted party to react in a timely manner. The return to a safe and secure state may initially require emergency measures, which are actions that are initiated based on the best information available at the time, before complete understanding of the situation is achieved and these measures can potentially degrade the level of service or functionalities. The return to a safe and secure state should be evaluated against the initial risk assessment and may only temporarily differ from the normal operational conditions. However, any increase of residual risk and the duration of this risk increase, i.e. due to the implementation of emergency measures, should be documented and accepted at the right level of accountability. The recovery activities mentioned here may also be the outcome of the response to incidents for which the authority has received information that requires the implementation of adequate measures in order to react to information security incidents or vulnerabilities with a potential impact on aviation safety. In such context the authority may not have a process or a recovery plan covering the specific occurrence. Therefore, the definition from the authority of a specific recovery plan is usually required.