Addressing information security aspects in functional safety

Security aspects in safety engineering
HEAVENS Project
3rd Scandinavian Conference on SYSTEM & SOFTWARE SAFETY
Rickard Svenningsson <rickard.svenningsson@sp.se>
HEAVENS
HEAling Vulnerabilities to ENhance Software Security and Safety
“We will identify security vulnerabilities in software-intensive automotive systems and
define methodologies along with tools for performing software security testing.
A common way of assessing security will improve the industry’s ability to deliver safe and
secure vehicles.”
HEAVENS Participation
HEAVENS Project Goals
 Identify state-of-the-art, and needs and requirements
 Construct security models
 Define methods and identify tool support for security testing and evaluation
 Establish interplay of safety and security in the E/E architecture
 Demonstrate proof of concepts, automotive use cases
Accomplished
On-going activities
HEAVENS
Apr 2013
WP1
Startup
Mar 2016
WP2
Security
models
WP1.1
Needs and
requirements
WP3
Security testing
and evaluation
WP4
Safety, security and
E/E architecture
WP5
Demonstrator
WP3.1 Methods
WP3.2 Tools
WP1.2
State of the art
study
Accomplished
WP3.3 Integration
On-going activities
WP10
Project
management
WP11
Exploitation and
Dissemination
HEAVENS Security Model
What is a security model ?
Provide threat analysis and risk assessment to facilitate deriving
security requirements for a particular asset and/or a target of
evaluation (TOE) by applying the HEAVENS methodology and
tools.
HEAVENS Security Model
Automotive cybersecurity - HEAVENS
HEAVENS Security Model
Principles and Workflow
HEAVENS Security Model
Structured keyword-based method
Threat analysis
STRIDE
Explanation
Security attribute
Spoofing
attackers pretend to be someone or something else
Authenticity, Freshness
Tampering
attackers change data in transit or in a data store
Integrity
Repudiation
attackers perform actions that cannot be traced
back to them
Non-repudiation,
Freshness
Information disclosure
attackers get access to data in transit or in a data
store
Confidentiality, Privacy
Denial of service
attackers interrupt a system’s legitimate operation
Availability
Elevation of privilege
attackers perform actions they are not authorized to
Authorization
perform
HEAVENS Security Model
Risk Assessment – Security Levels
 Threat Level (TL)
The probability of occurence of harm
 Impact Level (IL)
The severity of that harm
 Security Level (SL)
Measure of the needed strength of security
mechanisms for a security relevant asset
HEAVENS Security Model
Threat Level (TL) Parameters
TL parameters are primarily
“attack/attacker” oriented and
relatively “dynamic” in nature
– may change drastically over
time.
HEAVENS Security Model
Impact Level (IL) Parameters
SAFTEY: ISO 26262 Road Vehicles – Functional Safety, 2011.
FINANCIAL: BSI-Standard 100-4, Version 1.0, 2009, Federal Office for Information Security (BSI), Germany.
OPERATIONAL: Automotive Industry Action Group (AIAG), “Potential Failure Mode and Effects Analysis (FMEA)”, 2008.
PRIVACY: Privacy Impact Assessment Guideline, 2011, Federal Office for Information Security (BSI), Germany.
HEAVENS Security Model
Impact Level (IL) Parameters cont’d
SAFTEY: ISO 26262 Road Vehicles – Functional Safety, 2011.
HEAVENS Security Model
Impact Level (IL) Parameters cont’d
FINANCIAL: BSI-Standard 100-4, Version 1.0, 2009, Federal Office for Information Security (BSI), Germany.
HEAVENS Security Model
Impact Level (IL) Parameters cont’d
OPERATIONAL: Automotive Industry Action Group (AIAG), “Potential Failure Mode and Effects Analysis (FMEA)”, 2008.
HEAVENS Security Model
Impact Level (IL) Parameters cont’d
PRIVACY: Privacy Impact Assessment Guideline, 2011, Federal Office for Information Security (BSI), Germany.
WP4 – Safety, security and E/E architecture
One deliverable: ”D4 Interplay of safety and security in E/E architecture”
Estimated for release in April 2015 and final release in April 2016.
“The relationship between safety and security, and the impacts of safety
and security mechanisms on each other will be addressed. Approaches of
integrating safety and security mechanisms in the E/E architecture to
improve the overall dependability.”
Interplay of safety and security in embedded systems
 Similarities and differences between the two domains
 Requirement engineering – Threat and risk analysis
 Design
 Implementation
 V&V Activities
 An integrated lifecycle (V-model?) för safety and security
Similarities between the two domains
 Risk oriented approach
 What can go wrong? How likely is it? What will the consequences be? (note: differences in probability estimations)
 Development process
 Safe and secure software is achieved by using a systematic development approach rather than reactive patching
 Quality of the development process and procedures is fundamental for the confidence in the final product
 Testing
 Comprehensive testing is essential for confidence in the final product
 Additivity and composability
 Double instances of safety/security mechnisms does not necessarily lead to double safety/security (cmp. two 8-character passwords instead of one 16-character
or two CRC-8 instead of one CRC-16)
 Ultimate objective
 Achieving a sufficiently safe/secure product
 Culture and values
 Knowledgable, motivated and committed management and employees is a success factor for achieving safe and secure products
Differences between the two domains
 Classification of consequences
 In safety typically divided into several levels (e.g. SIL/ASIL/DAL)
 In security quite binary, system is either compromised or not
 Threat- and riskanalysis
 In safety we have pretty wellknown, static fault models and fault assumptions
 In security threats changes regarding motivation, knowledge and attack vectors
 Non-experts understanding of threats
 In safety the consequences are easily understandable
 In security the threat models are often met with sceptisism and might be jugded as paranoid
 Exchange of experience
 In the safety domain there is a culture of discussion and sharing of experience
 In security, business actors tend to keep their experiences to themselves, thus efficiently slowing down the collective expertise
Source of inspiration: L. Piétre-Cambacédès et. al: Reliability engineering and system safety, 2013
Thank you for your attention!