Building Resilient Systems: The Secure Software Development Lifecycle

Transcription

1 Building Resilient Systems: The Secure Software Development Lifecycle Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213, PhD Technical Director, CERT 22-Jul Carnegie Mellon University

2 Copyright 2015 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. References herein to any specific commercial product, process, or service by trade name, trade mark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN AS-IS BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This material has been approved for public release and unlimited distribution. This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at [email protected]. Carnegie Mellon is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. DM

3 Software is advancing function and replacing hardware Evolution of avionics size and function from F-4A (1960) to F-35 (2000) 1.0E E E E E E+02 Avionics SLOC 1, ,000,000 Sources: Final Report, NASA Study on Flight Software Complexity March 2009; Mel Conway, Tower of Babel and the Fighter Plane, Oct 9, % 80% 60% 40% 20% 0% % Airplane Function in Software 8% % 3

4 Software vulnerabilities are ubiquitous 4

5 Automotive electronics following the same path and with vulnerabilities 2014 Jeep Cherokee 2010 Jeep Cherokee Common assertion that modern high end cars have over 100M lines of code Source: Miller and Valasek, A Survey of Remote Automotive Attack Surfaces, 5

6 Catching software faults early saves money Faults accounts for 30 50% percent of total software project costs Sources: Critical Code; NIST, NASA, INCOSE, and Aircraft Industry Studies 6

7 An ounce of prevention. We wouldn't have to spend so much time, money, and effort on network security if we didn't have such bad software security. Source: Washington Post, March 19, 2014, Bruce Schneier in Viega and McGraw, Building Secure Software,

8 Security is a lifecycle issue Focus on the need to develop the theory, processes, practices and technology to support the agile construction and maintenance of secure software 8

9 Room for improvement 19% fail to carry out security requirement definition 27% do not practice secure design 72% do not use code or binary analysis 47% do not perform acceptance tests for thirdparty code Mission thread (Business process) More than 81% do not coordinate their security practices in various stages of the development life cycle. Sources: Forrester Consulting, State of Application Security, January 2011; Wendy Nather, Research Director, 451 Research, Dynamic testing: Why Tools Alone Aren't Enough, March 25,

10 Requirements 10

11 Getting the right requirements: desire for backdoors conflicts with secure operations Helpful capability Backdoor vulnerability 11

12 Need for multisystem risk analysis Expert Knowledge System Requirements Compliance Exploit 1 Vulnerability 1 Exploit 2 Vulnerability 2... Exploit N Vendor Solutions Single system scope Vulnerability N Risk analysis is focused on a single system Standalone (i.e., single system) models have been developed Risk analysis considers the exploit of an individual vulnerability within a single system Security risk identification techniques do not consider: Compositions of multiple vulnerabilities Cross-system security events/risks Impacts beyond the exploit of a single system (to the intended service and organization) Need for systematic, multiple system evaluations Notation for expressing a security events and risks Take into account all context: operational and physical, data, workflow, stakeholder, network views 12

13 System level cyber attacks on physical systems Steelworks compromise causes massive damage to furnace. One of the most concerning was a targeted APT attack on a German steelworks which ended in the attackers gaining access to the business systems and through them to the production network (including SCADA). The effect was that the attackers gained control of a steel furnace and this caused massive damages to the plant. Dragonfly attacks a dozen companies The Dragonfly hacker group attacked a number of companies SCADA systems and installed the malware Havex. This was used to gather information about the systems. No damage was done, because the compromise was detected and removed before the hackers had completed the observation and intelligence gathering phase. Sources: blob=publicationfile; 13

14 Security Engineering Risk Analysis 1. Establish operational context. Process Thread Worksheet Risk Identification Worksheet 2. Identify risk. Risk Evaluation Criteria Risk Analysis Worksheet 3. Analyze risk. Control Approach Worksheet Control Plan Worksheet 4. Develop control plan. 14

15 Engineering and Development 15

16 Integrating security into Agile development Code hygiene Secure DevOps 1. Code hygiene introduce secure coding 2. Secure DevOps include security tools 3. Threat modeling represent a new role 4. Risk analysis prioritize in backlog Risk analysis Threat modeling (See also: Bellomo and Woody, DoD Information Assurance and Agile: Challenges and Recommendations Gathered Through Interviews with Agile Program Managers and DoD Accreditation Reviewers ( i?article=1674&context=sei) Persona nongrata 16

17 Coding rules Collected wisdom of programmers and tools vendors Fed by community wiki started in Spring ,576 registered contributors Basis for ISO Standard 17

18 Adoption of secure coding rules Training Integrated development environments Batch analyzers Automated transformation and remediation 18

19 Embedded Systems (ES) represent new classes of vulnerabilities Characteristics of Embedded Systems ES cyber defenses differ from PC/IT network cyber defenses ECU designed for a specific purpose architecture could be unique for each ES Size, Weight, Power and Latency concerns Watchdog and filtering processes may not fit in operational envelop Designing ES and code is a special field Subject matter expertise of unique system Autonomous systems have physical resources, navigation needs and Safety-Critical Real-time OS Intermittent communications and multiple command-and-control masters Embedded firmware, unique internal busses & controllers Can require specific skills at the bit and clock cycle level Network-centric cyber defenses have limited applicability to embedded systems Virus definitions and operating guidelines don t always apply Centralized account control not possible Network tools and assessment techniques have limited relevance to embedded systems architecture and interfaces Threat Mitigation for ES and PC/IT are quite different Larger number and more diverse attack surfaces Back doors (maintenance), hardcoded credentials, insecure protocols, unplanned connectivity and upgrades 19

20 Programming for security is not the same as programming for safety Safety strategy Rely on physical models in fault trees Redundancy mitigates single failures Security view Attackers do not obey the laws of physics Attackers are not independent events Shared, global state improves behavior Shared service containers to meet space, power and weight constraints Microcontrollers and air gaps implement boundaries Attackers use leaked information beyond intended purposes Coupled services enable denial of service attacks Side channels open vulnerabilities 20

21 Vulnerabilities emerge in existing code New operating environments are a major cause of vulnerabilities Software supply chain delivers components of unknown provenance 21

22 Need security in depth to mitigate risk Perform checks at interfaces Compartmentalization helps contain damage 22

23 Future (CHERI) architectures improve compartmentalization Source: Watson, et al, CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization, IEEE Symposium on Security and Privacy, May 2015 Designed from ground up for security and safety Fine grained containers Breach of one container is isolated Backward compatibility Existing modules can be containers Prototypes constructed Transition activities on-going 23

24 Need to get the right skills to write secure code Moral: Need embedded, security mindset, processes, technology and support Source: 24

25 Software Assurance Framework (SAF) What Defines software assurance practices for acquiring and developing assured software products Why Improve software assurance practices in acquisition programs Enhance software assurance services provided by third parties Benefits Establish confidence in a program s ability to acquire software-reliant systems across the life cycle and supply chain Reduce cybersecurity risk of deployed software-reliant systems 25

26 SAF: Nine Practice Areas Focus 1. Governance Infrastructure Practices Governance Infrastructure 2. Materiel Solution Analysis (MSA) Practices 3. Technology Development (TD) Practices 4. Engineering and Manufacturing Development (EMD) Practices 5. Production and Deployment (PD) Practices 6. Operations and Support (O&S) Practices Acquisition Lifecycle Assurance 7. Secure Software Development Practices 8. Secure Software Operation Practices Software Security 9. Software Security Infrastructure Practices Software Security Infrastructure 26

27 Security is a lifecycle issue 27

28 Contact Information (412) Web Resources (CERT/SEI)

29 29