Best Practices Process & Technology. Sachin Dhiman, Senior Technical Consultant, LDRA

Size: px

Start display at page:

Download "Best Practices Process & Technology. Sachin Dhiman, Senior Technical Consultant, LDRA"

Carol Phelps
5 years ago
Views:

1 Best Practices Process & Technology Sachin Dhiman, Senior Technical Consultant, LDRA

2 Best Quality Software Product Requirements Design Coding Testing 2

3 Product Requirement Feature Requirement Security Requirement Safety Requirement 3

4 Product Design Hardware Architecture Software Architecture 4

5 Coding is Critical Safety and Security Design Coding Code is good but design may have problems! Design is good but code may have Coding Defects! 5

6 Testing Requirement driven testing Testing of complete software by running in actual environment Testing of correctness of function 6

7 Leading Process Standard Avionics DO-178B (First Published 1992) DO-178C (2012) Industrial IEC (First Published 1998, Update 2010) Railway CENELEC EN (First published 2001) Nuclear IEC (First published 2001) Automotive ISO (Published 2011) Medical IEC (First published 2006) Process IEC (First published 2003) 7

8 Cybersecurity Standard Industrial & Control IEC/ISA NIST CSF Special Publication 800 Series 8

9 Requirements & Requirement Based Testing

10 Requirements Product Features What product will do? Safety Objectives What is at risk in case of software failure? Security Targets What we want to protect? 10

11 Three Level of Requirements Decomposition of Requirements System Level Requirements High Level or Functional Requirements Low Level or Detail Requirements 11

Linking Requirements, Code and Tests System

b) Software Low-level Requirements (5.2.1.

12 Linking Requirements, Code and Tests System Requirements H/S Integration Tests (6.4.3.a) Software High-level Requirements (5.1.1.a) Software Integration tests (6.4.3.b) Software Low-level Requirements (5.2.1.a) Software Unit Tests (6.4.3.c) Source Code (5.3.1.a) Object Code ( b) 12

direction, i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through

13 What is Requirements Traceability? The requirements traceability is the ability to describe and follow the life of a requirement, in both a forward and backward direction, i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases. Requirements Requirements Evolving Versions Users/Clients Design Testing Code Requirements Pre-Requirement Traceability Post-Requirement Traceability 13

14 Types of Traceability Forward Traceability we can check that requirements are covered in which test cases? Whether is the requirements are coved in the test cases or not? Backward Traceability This will help us in identifying if there are test cases that do not trace to any coverage item Helps to identify that a particular test case is covering how many requirements Bi-Directional Traceability Bi-Directional Traceability contains both Forward & Backward Traceability 14

15 Backward and Forward Traceability Video link 15

16 Traceability Issue All the functions map to Low Level Requirements, but there are some High Level Requirements that are not mapped to any Low Level Requirements 16

17 Requirement based testing Recommendations NIST Special Publication IEC/ISA Standard Chapter 2, Section 1 - Defines system security requirements and associated verification methods derived requirements mapped to system requirements to subsystems and components DO178 C Table A - Requirements are traceable up to source code ISO Section 9 Table 10 - Requirements based test IEC Verify software requirements EN Section Software requirements 17

18 Design Software Architecture

19 Design is foundation Security and Safety comes from Design Design Choosing Hardware Choosing right software architecture 19

20 Software Architecture Separation of Critical Code from Standard code Encrypting sensitive data Using security feature of Microprocessor/Microcontroller Securing Communication Security Policies 20

21 Software Architecture Monolith Microkernel Client Server Event Driven MILS Layered Architecture 21

22 Security Partition 1 Security Partition 2 Security Partition 3 Example MILS Architecture Multiple Independent Levels of Security (MILS) Architecture Multiple Software Components must be Segregated Minimize Security Vulnerabilities Software is developed as per Common Criteria Guidelines Middleware Middleware Middleware Microkernel Microprocessor 22

23 Design Recommendations NIST Special Publication IEC/ISA Standard Design Principles for Security Security Risk Assessment and System Design DO178 C A-4 - Verification of Outputs of Software Design Process ISO Part 4 - System Design IEC Section 7 - Software Design IEC Software Architectural Design EN Clause 10 - Software Design and Implementation 23

24 Coding Best Coding Practices

25 Coding Most vulnerabilities are due to Coding Errors Software defect can be very expensive Safety Security Top Software vulnerabilities Integer overflow Buffer overflow uncontrolled format string missing authentication incorrect authorization Reliance on untrusted inputs (aka tainted inputs) Best coding Practice 25

26 Software has to be bug free! Write bug free code Review Code to find Programming Errors Formal Review is required, to avoid human errors Programming Standards MISRA CERT CWE etc 26

27 Why Programming Standards? 27

28 Why Programming Standards?

29 MISRA C :2012 MISRA C:2012 Enhanced Guidelines 236 pages in MISRA C: pages in MISRA C:2004 C90 / C99 support Total of 159 Guidelines 143 Rules 16 Directives Each guideline classed as Mandatory, Required, or Advisory Rules classed as Undecidable or Decidable LDRA is represented on the MISRA C working group - three committee members. The compliance to the standard is published on the LDRA website. 29

30 MISRA C :2012 AMD 2 Establishes 14 new C coding rules to extend the coverage of security concerns highlighted by the ISO C Secure Guidelines Addresses specific issues pertaining to the use of untrustworthy data a well-known security vulnerability Is supported by MISRA C:2012 Addendum 2, which maps the coverage by MISRA C:2012 of ISO/IEC 17961:2013 Is an enhancement to and fully compatible with all existing editions of the MISRA language guidelines 30

Other C Coding Standards There are numerous other C coding standards, ex: CERT C Secure Coding Standard Reference standard for Security Supported by some compilers HIS (Hersteller Initiative

31 Other C Coding Standards There are numerous other C coding standards, ex: CERT C Secure Coding Standard Reference standard for Security Supported by some compilers HIS (Hersteller Initiative Software) German Automotive standard Netrino Coding Standard Embedded standard also containing naming conventions and style guidelines Company Specific Standard Very popular is a company specific standard, based on MISRA 31

C++ Coding Standards - I JSF++ AV (F-35 Lightning II) project from Lockheed Martin Incorporates appropriate MISRA C rules Incorporates style rules 221 rules Validated by Bjarne Stroustrup (language

32 C++ Coding Standards - I JSF++ AV (F-35 Lightning II) project from Lockheed Martin Incorporates appropriate MISRA C rules Incorporates style rules 221 rules Validated by Bjarne Stroustrup (language inventor) LM Train Control Program (LMTCP) This coding standard has been devised by Lockheed Martin Maritime Systems & Sensors and is based mainly upon the JSF++ AV and HIC++ Standards together with a number of MISRA C:2004 and Reinhardt rules 408 rules 32

33 C++ Coding Standards - II MISRA C++:2008 This standard was released on 5 June 2008 and is an integration of JSF++ AV, HIC++ and other standards donated to the project by major international companies 228 rules High Integrity C++ (HIC++) Version 4 (October 2013) 155 rules (Reduced from 202) Covers C++11 LDRA is represented on the MISRA C++ working group chairman and committee members. 33

34 Advantage of Compliance with Coding Standard Program will behave in predictable manner Minimum or no software bug Portable Code 34

35 Code Review Recommendations DO178 C IEC ISO IEC EN Table A Source code conforms to standards Table B.1 1- Use of coding standard to reduce likelihood of errors Part 6 Table 1b - Use of language subsets software development standards Table A Coding Standard 35

36 Coding Guidelines for Cybersecurity Coding Guidelines CERT Secure Coding Standard Java, C/C++, Perl, Android MISRA Coding Standard with AMD 1 Open Web Application Security Project (OWASP) OWASP Code Review 36

37 Testing Validation & Verification

38 Testing Requirement based testing Testing to achieve 100 % Code Coverage Functional Testing 38

39 Requirement based testing Define Requirement Develop Code for Requirement Write Test Case to validate requirement Verify requirement by running Test case 39

40 Code Coverage Test complete code Run every statement/branch of the code in the lab Observe the behaviour of code Objective should be achieving100 Code Coverage 40

41 Advantage of 100 % Code Coverage Complete Testing Testing of complete portion of code Finding run time errors 41

42 Functional Testing Testing smallest software unit Correctness Robustness Error Guessing Fault Injection Test Analysis of Boundary Value 42

and Black Box Achieve structural coverage objectives, verify

43 Low-level Testing Requirement Based Low level testing Verify Low Level Requirements Testing on Actual Hardware White Box and Black Box Achieve structural coverage objectives, verify low level requirements and greatly reduce verification costs 43

44 Advantage of Unit/Integration Testing Developed functions will be correct Functions will be tested against valid and invalid values Interface Testing find issue in Integration 44

45 Code Coverage and Unit Testing Recommendations NIST Special Publication Chapter 3 - Perform Security focused verification, Penetration Testing, misuse and abuse case testing, temper resistance testing DO178 C Table A 7 - Test coverage of Software Structure ( Statement, Decision, MCDC etc.) ISO Section 9 Table 12 Software unit Testing ( Coverage metrics Statement, Branch, MCDC) IEC Table B Structural Test coverage ( Statement, Decision, MCDC etc.) IEC Software integration and Unit testing EN Table A.21 - Test Coverage for Code ( Statement, Decision, Path etc.) 45

46 Any Questions Q & A 46

47 Contact Us Need more information?.com 47

Don t Be the Developer Whose Rocket Crashes on Lift off LDRA Ltd

Don t Be the Developer Whose Rocket Crashes on Lift off 2015 LDRA Ltd Cost of Software Defects Consider the European Space Agency s Ariane 5 flight 501 on Tuesday, June 4 1996 Due to an error in the software