The DORATHEA Methodology for ATM Security Risk...

© GMV, 2014 Property of GMV

All rights reserved

The DORATHEA Methodology for ATM Security Risk Assessment

ICRAT 2014

Istambul

29.05.2014

José Neves

GMV Skysoft

Portugal

© GMV, 2014

1. What’s DORATHEA?

2. The DORATHEA background

3. The methodology

4. Wrap-up

AGENDA

2014/05/29 The DORATHEA Methodology for ATM Security Risk Assessment

© GMV, 2014

PROJECT GENESIS


DORATHEA was an R&D project co-financed by the European Commission, in the scope of the CIPS 2010 Programme…

SESM Scarl, a private research institute from Italy, was the project leader…

… and GMV Skysoft from Portugal, part of the GMV multinational group, was the project partner

Development Of a Risk Assessment meTHodology to Enhance security Awareness in ATM

© GMV, 2014

SESM SCARL


Founded in 1990

Owned by SELEX ES and SIRIO PANEL S.P.A.

Based in Naples (HQ) and Rome

120 employees, most of them research engineers

Main domain of activities:

Middleware and Open-Source for mission-critical systems

Interoperability for ATM and Crisis Management

Security and Dependability for Embedded Systems certification and Critical Infrastructure protection

Radar Tracking and Data Fusion for surveillance systems

Integrated logistic support for complex systems maintenance

Involved in SESAR WP16

© GMV, 2014

GMV SKYSOFT


Multinational conglomerate founded in 1984

Offices in Spain, USA, Malaysia, Poland, Germany, Romania, Portugal, India and France

Aeronautics

Onboard Equipment, Avionics Software and Test Benches

Integrated Modular Avionics – IMA

Safety Critical Software Development and Certification

Ground Support Equipment and Test Benches

Flight Physics & Control Techniques implementation

Development and Integration of GNSS satellite navigation infrastructure (SBAS, GBAS, support equipment)

Support systems for ATM and flight security

Aeronautical Communications

Reference Clients include Aena, Airbus Military, BAE Systems, EADS, Embraer, ESA, Eurocontrol, Eurocopter, Honeywell, Thales, …

110M€ (total revenue) Around 1.100 employees worldwide

€

© GMV, 2014

PROJECT GOALS


Development Of a Risk

Assessment meTHodology

Enhance security Awareness in

ATM

to ATM System

Manufacturers National Supervisory

Authorities

Air Navigation Service Providers

3 international workshops

~25 key players per workshop

New security risk assessment methodology tailored for ATM-CI

feed

back

© GMV, 2014

THE DORATHEA MOTIVATION


Überlingen mid-air collision, 2002

Air China Flight 129 crash, 2002

2005 Logan Airport runway incursion

ATM has a crucial role!

© GMV, 2014



ATM is already being targeted!

ATM has vulnerabilities!

© GMV, 2014



ATM is already being targeted!

Überlingen mid-air collision, 2002

Air China Flight 129 crash, 2002

2005 Logan Airport runway incursion

ATM has a crucial role!

ATM has vulnerabilities!

© GMV, 2014

RISK ASSESSMENT IN ATM


SAM – Safety Assessment Methodology

Eurocontrol

Safety risk assessment and mitigation in ATM

ESARR 4 - Eurocontrol Safety Regulatory Requirement

What about security?

SecRAM - SESAR ATM Security Risk Assessment Method

DORATHEA


All rights reserved

The DORATHEA methodology

© GMV, 2014

METHODOLOGY OVERVIEW

Based on the strength points of SAM

Follows a similar workflow

Clearly preserves the distinction of roles and responsibilities


Strives to incorporate key aspects of SecRAM

Primary / Supporting Assets

Impact Areas

…

© GMV, 2014

ISO/IEC 27005:2008

Primary Assets vs Supporting Assets



All rights reserved

SecFHA Security Functional Hazard Assessment

© GMV, 2014 2014/05/29 The DORATHEA Methodology for ATM Security Risk Assessment

SECURITY ASSESSMENT PROCESS

SYSTEM DEFINITION

SECURITY FUNCTIONAL

HAZARD ASSESSMENT

SecFHA

How secure does

the system need to be to

achieve a tolerable risk?

SYSTEM DESIGN

PRELIMINARY SYSTEM

SECURITY ASSESSMENT

PSSecA

Is the proposed architecture

expected to achieve a

tolerable risk?

SYSTEM SECURITY

ASSESSMENT

SSecA

SYSTEM

IMPLEMENTATION &

INTEGRATION

OPERATIONS

Does the system as

implemented achieve a

tolerable risk?


SECFHA OVERVIEW

ANSPs are responsible for this phase

Identify system’s Security Hazards

• Identify all system functionalities

• Classify system functionalities

• Select highest priority functionalities

• Identify potential Security Hazards

• Derive Impact of Security Hazards’ effects

Derive system’s Security Objectives

© GMV, 2014

IDENTIFICATION OF SYSTEM FUNCTIONALITIES

System Functionalities Table (SFT)


© GMV, 2014

CATEGORIZATION OF SYSTEM FUNCTIONALITIES

System functionalities to be protected are selected according to:

The Impact that the loss of either Confidentiality, Integrity or Availability of the functionality will bring about;

The Appeal of causing the loss of either Confidentiality, Integrity or Availability from an attacker’s point of view.


© GMV, 2014

CATEGORIZATION OF SYSTEM FUNCTIONALITIES


© GMV, 2014

IDENTIFICATION OF POTENTIAL SECURITY HAZARDS

Security Hazards Table (SHT)


A Security Hazard is defined as any condition, event, or circumstance which could lead to the loss or corruption of critical system functionalities

© GMV, 2014

DEFINITION OF SECURITY OBJECTIVES


Each Security Objective specifies for each identified Security Hazard the maximum tolerable Likelihood of its Occurrence, given its assessed Impact

The Security Risk shall be at least Tolerable (i.e. yellow)

The Impact is inherited from the previous analysis

The maximum Tolerable Likelihood of Occurrence is obtained from the Risk Scheme

© GMV, 2014

DEFINITION OF SECURITY OBJECTIVES

Security Objectives Table (SOT)


Each Security Objective specifies for each identified Security Hazard the maximum tolerable Likelihood of its Occurrence, given its assessed Impact

The Security Risk shall be at least Tolerable (i.e. yellow)

The Impact is inherited from the previous analysis

The maximum Tolerable Likelihood of Occurrence is obtained from the Risk Scheme


All rights reserved

PSSecA Preliminary System Security Assessment



SYSTEM DEFINITION

SECURITY FUNCTIONAL

HAZARD ASSESSMENT

SecFHA

How secure does



SYSTEM DESIGN

PRELIMINARY SYSTEM

SECURITY ASSESSMENT

PSSecA



tolerable risk?

SYSTEM SECURITY

ASSESSMENT

SSecA

SYSTEM

IMPLEMENTATION &

INTEGRATION

OPERATIONS

Does the system as


tolerable risk?


PSSECA OVERVIEW

ATM System Providers are responsible for this phase

Derive Security Requirements to satisfy the Security Objectives of the system

Attack Tree Analysis (ATA)

Identification of Vulnerability and Effects Analysis (IVEA)


PSSECA IN MORE DETAIL

Attack Tree Analysis (ATA)

• Aims at identifying the logical combination of Security Incidents leading to the non-fulfilment of the Security Objectives

• The focus is on the system’s primary assets

Identification of Vulnerability and Effects Analysis (IVEA)

• Aims at evaluating if the supporting assets linked to the Security Objectives are vulnerable to the identified threats

• The focus is on the system’s supporting assets

SecFHA

Technical

Input IVEA

ATA

SECURITY OBJECTIVES

FUNCTIONAL BREAKDOWN

DESIGN INFORMATION

INCIDENT CRITICALITY

SECURITY REQUIREMENTS

Security Control

Definition

Technical

Specifications


ATA - ATTACK TREE ANALYSIS SECURITY INCIDENTS

1. The Security Objective to be analysed is the top event of the tree;

2. All the Security Incidents that contribute to the non-fulfilment of this top event are identified;

3. The Security Incidents identified in point 2 are correlated between themselves through logic gates (AND / OR gates) until the top event is reached;

4. For each Security Incident identified in point 2 that seems to be not enough detailed, the Security Incidents that lead to it have to be identified and correlated through logic gates;

5. From the Security Objective defined as the top event of the tree, the Incident Criticality for each identified Security Incident is derived.

Security Incidents are one or more unwanted or unexpected security events that could very likely compromise the security of the organization and weaken or impair business operations


ATA - ATTACK TREE ANALYSIS INCIDENT CRITICALITY


Attack tree for SO_IN_I07


Attack tree for SO_HMI_C07

© GMV, 2014

Security Incidents Table (SIT)


ATA - ATTACK TREE ANALYSIS THE TABLE OF SECURITY INCIDENTS


IVEA TABLE

1. The list of supporting assets is considered;

2. The vulnerabilities of each supporting asset are identified;

3. The list of threats is considered. Each threat will be traced to a determined supporting asset if the latter is vulnerable to the former;

4. The Security Incidents that are caused by the threats related to the supporting asset under scope will be linked. This task implies the assessment of the threats’ consequences in terms of Impact, and thus entails relating the supporting assets to their underlying primary assets. These Security Incidents were identified during the ATA analysis, and can be referred by their IDs. Only Security Incidents at the bottom of the attack trees will be considered;

5. The maximum Incident Criticality of all the pinpointed Security Incidents will be set;

6. The most appropriate Security Controls to mitigate or prevent the threat’s effects will be selected;

7. The system Security Requirements will be derived.

1 2 3

4 5 6 7


THREATS AND VULNERABILITIES


IVEA TABLE 1. The list of supporting assets is considered;

2. The vulnerabilities of each supporting asset are identified;

3. The list of threats is considered. Each threat will be traced to a determined supporting asset if the latter is vulnerable to the former;

4. The Security Incidents that are caused by the threats related to the supporting asset under scope will be linked. This task implies the assessment of the threats’ consequences in terms of Impact, and thus entails relating the supporting assets to their underlying primary assets. These Security Incidents were identified during the ATA analysis, and can be referred by their IDs. Only Security Incidents at the bottom of the attack trees will be considered;

5. The maximum Incident Criticality of all the pinpointed Security Incidents will be set;

6. The most appropriate Security Controls to mitigate or prevent the threat’s effects will be selected;

7. The system Security Requirements will be derived.

© GMV, 2014

SECURITY CONTROLS

Security Controls are means of managing Security Risks, including policies, procedures, guidelines, practices or organizational structures


© GMV, 2014

SECURITY REQUIREMENTS

It is up to the Security Requirements to make sure that the Security Incidents are not attainable, and consequently that the Security Objectives are satisfied.


Security Requirements Table (SRT)

The Security Requirements must be linked to the system’s Security Objectives, and consist of documented physical and functional needs that the system must be able to deliver. As such, each Security Requirement will be a statement that identifies a necessary attribute, capability, characteristic or quality of the system for it to be protected from a security point of view against intentional attackers.



SYSTEM DEFINITION

SECURITY FUNCTIONAL

HAZARD ASSESSMENT

SecFHA

How secure does



SYSTEM DESIGN

PRELIMINARY SYSTEM

SECURITY ASSESSMENT

PSSecA



tolerable risk?

SYSTEM SECURITY

ASSESSMENT

SSecA

SYSTEM

IMPLEMENTATION &

INTEGRATION

OPERATIONS

Does the system as


tolerable risk?


SSECA OVERVIEW

ATM System Providers are responsible for this phase

The process produces assurance that the Security Objectives are satisfied and that system elements meet their Security Requirements

Verification and validation activities

Security metrics, a measure of the Security Risk


VERIFICATION ACTIVITIES

1. Verify if the Security Requirements are testable, i.e. deterministic, unambiguous, correct, complete, non-redundant, lend themselves to change control, traceable, readable by all project team members, written in a consistent style, processing rules reflect consistent standards, explicit, logically consistent, lend themselves to re-usability, terse, annotated for criticality, feasible, non-conflicting

2. Design a necessary and sufficient (from a black box perspective) set of test cases from those requirements to ensure that the design and code fully meet those requirements


VALIDATION ACTIVITIES

A validation plan is required in order to identify the content of validation exercises

Validation objectives:

Effectiveness

Robustness

Functional feasibility

Updatability

Security certification

Security function operability

Integration

Operability

Performance

Aeronautical constraints

Customization

Safety


SECURITY METRICS

Measurements

Single-point-in-time views of specific, discrete factors

Generated by counting

Objective raw data

Metrics

Comparison of two or more measurements taken over time to a predetermined baseline

Generated from analysis

Objective or subjective human interpretations of raw data

smart: Specific, Measurable, Attainable, Repeatable, and Time-dependent

© GMV, 2014

CONCLUSIONS

Positive aspects of the methodology

Very systematic approach

Raise awareness

Foster the discussion between experts

Shortcomings of the methodology

Immature

Subjective decision-making

Over-engineering at some points


© GMV, 2014

NEXT STEPS

Improvement points

Systematize the identification and categorization of system functionalities to protect

Assignment of the attack appeal postponed until system implementation details are known

Database of known attacks would be useful to build the attack trees

Threats’ propagation and vulnerabilities resulting from the integration of legacy and new systems would be useful additions to the framework

The impact of proposed Security Controls (e.g. their cost) should be taken into account when selecting them

New research topic

Framework to assure the harmonization of safety and security in ATM


The DORATHEA Methodology for ATM Security Risk...

Documents

Transcript of The DORATHEA Methodology for ATM Security Risk...