This is the presentation slides on the paper "Safe & Sec Case Patterns" at ASSURE 2015. This research investigate how to integrate safety and security from process patterns and show an integrated assurance case for both.

1. Kenji Taguchi＠AIST
3rd International Workshop on Assurance Cases for Software-intensive Systems
(ASSURE) 2015
Safe & Sec Case Patterns
2015 September 22
National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute
Software Analytics Research Group
Kenji Taguchi, Daisuke Souma, Hideaki Nishihara

2. Kenji Taguchi＠AIST
General Background
• Many industrial sectors, which manufacture safety intensive systems
e.g., automotive, railway, etc., now face technical challenges how to
integrate and harmonize issues on safety in addition to security for
their systems.
• After the stuxnet incident, any safety critical systems, even not linked
to any network are under the imminent threats for security
vulnerabilities.
• Can we treat safety and security separately? Are there any interactions
between safety and security? The answer is YES and we need to
tackle issues how to integrate them.
• From safety point of view, security is of great importance. Since some
(safety-related) hazardous events (such as car crash, derailing, etc,.)
could be caused by hardware/software failures and/or malicious
attacks, thereby we need to identify and analyze potential
hazards/threats, their combinations and their associated risks in a
systematic way, and build a new assurance framework for safety and
security.

3. Kenji Taguchi＠AIST
Background: Security in Automotive Industry
• The automotive industry has been experiencing sudden changes of
security demands.
– Markey report 2014
– Class action against Ford, GM and Toyota 2015
– Recall of Chrysler Jeep Cherokee 2015
– Spy Car Act bill 2015
Markey report Spy Car Act Bill
Class action Recall

4. Kenji Taguchi＠AIST
• Many industrial sectors are standardizing safety and security standards.
• There are several critical issues in those standardizations:
• In most cases, harmonization of the both standards are neither well considered nor well
understood.
• Major stakeholders are becoming to aware that there are many critical issues involved in
how to harmonize both standards.
ARP 4754A
Safety
DO-326A
Security
ISO 26262
Safety
?
Security
IEC 62278
RAMS
IEC 62280
Security
Background: Security and Safety Standards

5. Kenji Taguchi＠AIST
Background: Integrating standards for Automotive Case
ISO 26262
Safety
?
Security
IEC 62443 ISO/IEC 15408
J3061
Cybersecurity
Guidebook (SAE)
VDA (German Association
of the Automotive industry)
• Harmonized style is required
• Dual certification would be a challenge
Or
ISO 26262
Safety
Incorporate
Security features
• Interference analysis could not be sufficient.
• Certification cost would be more than doubled.
There are several possibilities at
what level this integration could be
achieved.
Otherwise

6. Kenji Taguchi＠AIST
Background: SafSec Methodology and Automotive case
Def-Stan 00-56
Safety
ISO/IEC 15408
Security
Assurance Framework based on Dependability Case
ISO 26262
Safety Security
J3061
Cybersecurity
Guidebook (SAE)
Safety Case Cybersecurity Case
Possible Future
SafSec Standard/Guideline
Need a new assurance framework
based on Safety and Security
Cases?
+

7. Kenji Taguchi＠AIST
Aims of Our Research
• Provide process patterns for the guidance on the design of the system development
process, which integrates safety and security engineering processes.
– There is no well-accepted development process which includes both safety and security
engineering so we presented some current practice/proposals in patterns.
– Process patterns are derived from an extensive survey on existing safety/security
standards/guidelines and research, and our experience with industrial partners in railway (and
automotive) industry.
– Limitations:
• Only dealt with at the early stage of the system development lifecycle.
• No evaluation has not been done yet.
• Provide case patterns derived from the process patterns, which provide the insight on
how a safety case and a security case could be constructed/integrated.
– Some assumption:
• In near future, many security standards would demand the submission of security cases.
– E.g., J-3061 “Cybersecurity guidebook for Cyber-physical automotive systems” by
SAE mentions on a cyber-security case.
• There would be a critical issue on how to integrate a safety case mandated by a safety
standard and a security case mandated by a security standard.

8. Kenji Taguchi＠AIST
Assumption: Process level
• Only a part of safety concept phase is dealt with in this paper.
– E.g., Part 3 of ISO 26262, the safety concept phase.
Safety
concept
phase
ISO 26262

9. Kenji Taguchi＠AIST
Basic Process Pattern
• Basic process is a very generic process commonly found in functional safety standards.
• No interactions between the security and safety processes.
• Assumption:
– Security process may have a identical process (functional security view).

10. Kenji Taguchi＠AIST
Subordinate Process Pattern
• Some of activities related to security are subordinate to its counterparts in safety.
– Requirements:
• Need methodological supports, e.g, safety analysis method which also can analyze security threats.
• This view appears to be predominant in the safety critical systems community.
The above tree represents a methodological
support for the subordinate approach, which
integrates Fault Tree (FT) analysis with
Attack Tree (AT) analysis.
Steiner, M., Liggesmeyer, P.: Combination of Safety and Security Analysis - Find-
ing Security Problems That Threaten The Safety of a System.

11. Kenji Taguchi＠AIST
Uni-Directional Reference Process Pattern
• Security and safety processes are separated but the security part will refer to some results of the safety part.
• This process pattern can be witnessed in the airworthiness security standard DO-326A.
• This process pattern is also safety pre-dominant, since information flows from safety to security.
– Remark:
• Bi-directional Reference Process Pattern could be possible, but it would be the most complex and the worst cost-effective process.

12. Kenji Taguchi＠AIST
Interrelated (Independent) Process Pattern
• Security and safety processes run independently, but the trade-off analysis on risk reduction measures
(safety requirements) and mitigation methods (security requirements) should be carried out.
– It is witnessed in FP7 SESAMO Project.
• The aim of the analysis is to identify potential feature interaction between functional safety requirements
and security requirements.
– For instance, timing constraints on a functional safety requirement may be interfered by time-consuming encryption
mechanism of security requirement.

13. Kenji Taguchi＠AIST
SafSec Process Pattern
• This process pattern is derived from the SafSec standard/guidelines by UK MOD and Praxis.
• The aim of this standard/guideline is to certify military equipment under the Def-Stan 00-56 (software
safety) and Common Criteria (security).
• It converges hazards and threats as losses, which is carried out at the Loss Op meeting, where security
experts and safety experts get together to merge hazards and threats.

14. Kenji Taguchi＠AIST
Process Patterns (Remaining Issues)
• Evaluations on each process pattern is on-going work.
– This classification shows there would be several options how to integrate safety and
security engineering processes.
– Some evaluation criteria should be established.
• There are some other issues which do not explicitly appear in these
patterns.
– Integration of safety analysis and security analysis
– Integration of safety and security assessments.
• How can we uniformly assess safety risks and security risks even they are based on
different matrixes (integrity levels)?
– Analysis on feature interaction between safety and security
• For instance, could we effectively perform the trade-off analysis at this early stage?
• Since at this stage, safety and security requirements are still abstract and feature
interactions between them might not be clearly identified yet.

15. Kenji Taguchi＠AIST
Safe & Sec Case Patterns
• *-cases are required for more than one system attribute.
– Existing *-cases
• Safety case
• Reliability and maintainability case
• Dependability case
• (Cyber) security case
• If more then one case is required, how to integrate them is of
great importance to practitioners.
• We will show how cases called Safe & Sec Case Patterns
could be provided which reflect process patterns presented on
the previous slides.
– These patterns are represented at the abstract level.
• The Safe & Sec Case Patterns are represented in GSN (Goal
Structuring Notation).

16. Kenji Taguchi＠AIST
GSN (Goal Structuring Notation)
• A graphical notation for representing an argument （T. Kelly）
– GSN Community Standard Ver. 1.0
• Defines the full-specification of GSN
• Goal
•Goal which the systems should ensure
•Goal is further decomposed to sub-goals
•Context
•Any material (e.g., documents) under which
the argument holds
•Strategy
•Indicates how a goal is decomposed
•Solution
•Evidence which support the argument
Solution
Strategy
Goal Context

17. Kenji Taguchi＠AIST
Subordinate Case Pattern
• This pattern is derived from the subordinate process pattern.
Safety analysis
Includes threat
analysis
All threat which
may cause hazards
are identified.

18. Kenji Taguchi＠AIST
Interrelated (Independent) Case Pattern
Trade-off analysis is
Carried out here

19. Kenji Taguchi＠AIST
Related work
• Many works on safety cases
– No need to mention.
• A few work security cases
– Alexander, R., Hawkins, R., Kelly, T.: Security assurance cases:
Motivation and the state of the art
– Goodenough, J., Lipson, H.F.,Weinstock, C.B.: Arguing security -
creating security assurance cases.
• Interactions between safety case and security case
– Bloomfield, R.E., Netkachova, K., Stroud, R.J.: Security-informed
safety: If it‘s not secure, it's not safe.
• Build a safety case first and analyze the impact on that safety case from
security.
Our approach does not provide any means to analyze feature interactions between safety
and security, and only provides possible combinations in process and case patterns.

20. Kenji Taguchi＠AIST
Conclusion
 Our contributions are twofold:
 Process patterns are provided which show how safety and security
processes could be integrated based on survey on existing standards
and research.
 Case patterns are then derived from those process patterns.
 These patterns would help practitioners working on safety critical
systems how to develop their own safety/security engineering
processes and what critical issues they should address.
 Future work
 In railway standards, it is not yet certain how a safety case (EN
50126/IEC 62278) could include security features. Our case patterns
show some baseline to fill this gap.
 Currently we are planning to incorporate security features into CAA (The
Civil Aviation Authority)‘s safety case in a subordinate approach
 IN-2014/184: Small Unmanned Aircraft: Congested Areas Case (CAOSC).
Operating Safety