Building Security into the Software Life Cycle

Transcription

1 Building Security into the Software Life Cycle A Business Case Marco M. Morana Senior Consultant Foundstone Professional Services, a Division of McAfee

2 Outline» Glossary» What is at risk, what we do about it and when» Is software complexity the root cause?» Vulnerability management challenges» Application security vs. software security» A change of perspective: the Software Security Life Cycle (SDLC)» Security-enhancing lifecycle process models» CLASP, activities, phases and roles» Secure-SDLC requirements, how we get there?» Secure software best practices and activities» Guidelines for building secure software» The Secure-SDLC touch-point Model» Secure software best practices and software development models» In summary: take away lessons» Resources 2

3 Glossary» Risk: the probability that a particular threat-source will exercise a particular information system vulnerability and the resulting impact if this should occur» Threat: any circumstance or event with the potential to harm an information system through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.» Vulnerability: a weakness in system security requirements, design, implementation, or operation, that could be accidentally triggered or intentionally exploited» Security Defects: implementation vulnerabilities and design vulnerabilities» Security Bugs: implementation-level security software problem» Security Flaw: design-level security software problem 3

4 What is at risk? 4

5 What we do about it 1) Security defects discovered BEFORE the product release gets into production: - Found during functional tests - Dealt with as bugs - Fixed with changes into the product - Deployed with product release 2) Vulnerabilities discovered AFTER the product release gets into production: - Found during operation & maintenance - Dealt with as security defects - Fixed with new security patches - Deployed in all products already released 5

6 When we do something about it?» Today most people test after software is built! 6

7 Is software complexity the root cause?» Software is getting bigger and more complex: Windows complexity ~ 2 million lines of code in Windows 3.1 (1990) ~ 20 million lines of code in Windows 95 (1997) ~ 40 million lines of code in Windows XP (2001)» More lines of code means more security bugs: - Average Security Bugs in Code: 6 every one Thousand Line Of Code (KLOC) - Millions of LOC => Thousands of Security Bugs» Network centric approach means a penetrate and patch mentality: - 47% of security defects that are exploitable are preventable (@stake)» Lack of focus on secure software development best practices: - Best designed applications have 80% fewer defects than the worst designed (@stake) 7

8 Application Security vs. Software Security» Penetrate and patch» Look at the issue» Just in time solution: fix one application in one single time» Network Security Centric Perspective» Information Security Knowledge» Short term tactical solutions (e.g. penetration tests)» Security as an afterthought, consider risks only when you are exposed» High risk low ROI activities» Manage software security risks» Looks at the root cause» Lifecycle solution: from start (e,g, inception) to end (e.g. decommissioning)» Software Security Engineering Perspective» Software Security Knowledge» Long term strategic solution (e.g. software security best practices)» Security thought early on, consider risks from software inception» Low risk High ROI activities 8

9 Change of perspective: software security life cycle 9

10 Security-enhancing Lifecycle Process Models» Repetitive and measurable processes» Provide guidance on secure software activities» Apply development best practices to various software artifacts» Integrate with foundational software security activities» Include tactical resources» Provision the use of automation tools» Provide a framework for mapping security activities into SDLC such as: SDLC phases, tasks and checkpoints (e.g. M. Howard SDL) Roles, process phases and interactions (e.g. J. Viega CLASP) Risk management, knowledge and touchpoints (e.g. Gary Mc Graw) 10

11 Comprehensive Lightweight Application Security Process (CLASP) 11

12 Mapping Security Activities, Phases and Roles with CLASP 1. Institute a security awareness program Planning Project Manager 2. Monitor security metrics On going Project Manager 3. Specify operational environment Analysis & Design Requirement Specifier 4. Identify global security policy Planning Requirement Specifier 5. Identify resources and trust boundaries Requirements Architect 6. Identify user roles and resource capability Analysis & Design Requirement Specifier 7. Document security-relevant requirements Requirements Requirement Specifier 8. Detail misuse cases Inception & Elaboration Requirement Specifier 9. Identify attack surface Evaluation Designer 10. Apply security principles to design Analysis & Design Designer 11. Research and assess security posture of tech. solutions Ongoing Architect 12. Annotate class designs with security properties Analysis & Design Designer 13. Specify database security configuration Implementation Designer 14. Threat Modeling Analysis & Design Security Auditor 15. Integrate security analysis into source management proc. Implementation Integrator 16. Implement interface contracts Implementation Implementor 17. Implement and elaborate resource policies and tech. Implementation Implementor 18. Address reported security issues Test Designer 19. Perform source level security review Evaluation Security Auditor 20. Identify, implement, and perform security tests Test Designer 21. Verify security attributes of resources Evaluation Integrator/Tester 22. Perform code signing Transition Integrator 23. Build operational security guide Deploy & Maintain Integrator/Tester 24. Manage security issue disclosure Deploy & Maintain Project Manager 12

13 HACME Secure-SDLC requirements 1. Be complaint with HACME security policies and guidelines (e.g. regulatory compliance, information security policy, information risk management guideline) 2. Define security activities that are both strategic (e.g. long term objectives) and tactical (e.g. short term goals) 3. Provide guidance on each security activity with clear objectives artifacts to be produced and dependencies 4. Show how you map security activities into different software development methodologies (e.g waterfall, AGILE, XP, RUP) 13

14 How we get there?» Adopt an activity driven approach» Define and document security activities derived by best practices: Preliminary Software Risk Analysis Secure Requirements Engineering Security Risk Driven Design Secure Code Implementation Security Tests Secure Configuration & Deployment Metrics & Measurements Training & Awareness» Define dependencies and prerequisites (e.g. activities and artifacts)» Define entry scenarios for the activities (e.g. events and reasons)» Position the activities w.r.t. SDLC methodologies and roadmaps (e.g. new development vs. legacy) 14

15 Secure Software Best Practices and Activities» Preliminary Software Risk Analysis - Define use and misuse cases requires: Business Requirements, Security Requirements depends on: none produces: Misuse Cases Diagrams and descriptions» Security Requirements Engineering - Define Security Requirements requires: Business requirements, Functional requirements, Industry Regulations, Organizational Policies, Technical Standards depends on: Misuse cases produces: Security Requirement Document 15

16 Secure Software Best Practices and Activities» Security Risk Driven Design - Secure Architecture & Design Patterns requires: Requirements, Architecture Documentation depends on: Security Requirements produces: Secure Architecture Documents - Threat Modeling requires: Architecture Documents, Data Classification, Requirements depends on: Misuse cases produces: Threat Profile 16

17 Secure Software Best Practices and Activities» Security Risk Driven Design - Secure Architecture Review requires: Functional Requirements, Architecture Diagrams, Network Diagrams, Data Flow Diagrams depends on: Security Architecture & Design Patterns, Threat Model produces: Security Architecture Review Findings - Security Test Planning requires: Requirements, Architecture & Network diagrams, Data Flow Diagrams, Test Tools & Frameworks depends on: Security Requirements, Misuse cases, Threat Model produces: Security Test Plan 17

18 Secure Software Best Practices and Activities» Secure Code Implementation - Peer Code Review requires: Source code, Coding standards, Architecture documents, depends on: Threat Model produces: Code Review Findings - Automated static & dynamic code review requires: Source code, Components and Libraries, Build depends on: Threat Model produces: Automated Code Review Findings - Security Unit Tests requires: Source code, Unit Test Frameworks depends on: Security Requirements, Test Cases produces: Unit Test Results 18

19 Secure Software Best Practices and Activities» Security Tests - Functional - Risk Driven - System - Component - White Box - Black Box all require: Source code, Architecture documents, Data flow Diagrams, Test Environment all depend on: Security Test Planning, Threat Model, Security Requirements all produce: Test reports 19

20 Secure Software Best Practices and Activities» Secure Configuration & Deployment - Secure Configuration requires: depends on: none produces: Operational data and services, source code, build environment, account and password policies, configuration files Secure Configuration Guide/Checklist - Secure Deployment requires: depends on: none produces: Application files and directories, auditing and logging services, registry entries, authentication services, service components, network configuration, service accounts Secure Deployment Guide/Checklist 20

21 Secure Software Best Practices and On Going Activities» Security Training & Awareness - Security Awareness Training - Secure Architecture Design - Secure Coding - Operational Security - Security QA - Ethical hacking» Metrics & Measurements - Number of bugs vs. flaws - Time to fix bugs vs. flaws - Number of vulnerabilities - Time to respond to incident - Support statistical data» Information Risk Management - Investigate Preliminary Risks - Business Analysis - Asset Classification - Threat & Vulnerability Analysis - Business Impact Analysis - Risk Determination - Risk Strategy Selection» Vulnerability management - Policy Compliance - Vulnerability Assessment - Security Configuration - IT Security Risk Management 21

22 Guidelines for Building Secure Software 1.Threat Modeling The purpose of this exercise is to ensure that all known threats to the application are adequately addressed. During design, you will gather information such as requirements and design artifacts to analyze your application from the prospective of the impacts of potential threats. The main outcome at this activity is a threat profile that identifies and categorizes you application threats, recommends countermeasures and identifies application vulnerabilities. Further information on how this activity should be conducted is covered in the Guideline For Conducting Threat Modeling 22

23 Secure-SDLC Touchpoint Model 23

24 Secure Software Best Practices and the Waterfall Model 24

25 Secure Software Best Practices and the Spiral Model 25

26 Secure Software Best Practices and the RUP Model 26

27 In Summary: Take Away Lessons» Software and organizations are not homogenous (e.g. X divisions, Y software applications running on Z platforms implement N software technologies)» Building security into the SDLC is a formal process: - Top Down (organization driven from CIO) - Bottom up (gap analysis from managers and auditors)» S-SDLC and Information Risk Management are integrated processes: - S-SDLC Manage Software Security Risks - Technical Risk Management Information Risk Management» There is no silver bullet for software security: - Strategic and tactical plans - Roadmaps: short term, near term and long term (e.g. maturity levels)» Clients that care about software security know that: - Application Security!= Software Security - Security = Commitment x (Best Practices^2 + Tools) 27

28 Resources» Foundstone Resources, Whitepapers, Articles Comprehensive, Lightweight Application Security (CLASP) Process DHS Build Security In Most recent books on software security: - Gary McGraw Software Security, January 2006 Addison Wesley - M. Howard and S. Lipner: The Security Development Lifecycle, May 2006 Microsoft Press 28

29 Thanks You For Listening! 29