Secure Software Development Models/Methods. Associate Professor

Transcription

1 IS 2620: Developing Secure Systems Secure Software Development Models/Methods Lecture 1 Aug 27, 2014 James Joshi, Associate Professor

2 Objective Understand/Familiarize with various process models for secure software development and assurance Capability Maturity Models CMMI, icmm, SSE-CMM, TSP Security Assurance Maturity Model Secure software development life cycle models

3 Software/Systems t Security Renewed ---- interest & importance idea of engineering software so that it continues to function correctly under malicious attack Existing software is riddled with design flaws and implementation bugs ~70% related to design flaws* any program, no matter how innocuous it seems, can harbor security holes * com/archive/library/atstake tech0502 pdf

4 Software Problem # vulnerabilities Reported by CERT/CC More than half of the vulnerabilities are due to buffer overruns More than half of the vulnerabilities are due to buffer overruns Others such as race conditions, design flaws are equally prevalent

5 Software security It is about Understanding software-induced security risks and how to manage them Leveraging software engineering practice, thinking security early in the software lifecyle Knowing and understanding common problems Designing for security Subjecting all software artifacts t to thorough h objective risk analyses and testing It is a knowledge intensive field

6 Ti Trinity it of ftrouble Three trends Connectivity Inter networked Include SCADA (supervisory control and data acquisition systems) Automated attacks, botnets Extensibility Mobile code functionality evolves incrementally Web/Os Extensibility Complexity XP is at least 40 M lines of code Add to that t use of unsafe languages (C/C++) Bigger problem today.. And growing

7 It boils down to more code, more bugs, more security problems

8 Security problems in software Defect implementation and design vulnerabilities Can remain dormant Bug An implementation level software problem Flaw A problem at a deeper level Bugs + Flaws leads to Risk Bug Buffer overflow: stack smashing Buffer overflow: one-stage attacks Buffer overflow: string format attacks Race conditions: TOCTOU Unsafe environment variables Unsafe system calls (fork(), exec(), system()) Incorrect input validation (black list vs. white list Flaw Method over-riding riding problems (subclass issues) Compartmentalization problems in design Privileged block protection failure (DoPrivilege()) Error-handling problems (fails open) Type safety confusion error Insecure audit log design Broken or illogical access control (role-based access control [RBAC] over tiers) Signing too much code

9

10 Process Models Secure Process Set of activities performed to develop, maintain, and deliver a secure software solution Activities could be concurrent or iterative Process model provides a reference set of best practices process improvement and process assessment. defines the characteristics of processes usually has an architecture or a structure

11 Process Models Process Models Help identify technical and management practices good software engineering practices to manage and build software Establishes common measures of organizational processes throughout the software development lifecycle (SDLC). But no guarantees product is bug free

12 Process Models Typically also have a capability or maturity dimension used for Purposes: assessment and evaluation. Assessments, evaluations, appraisals includes: comparison of a process being practiced to a reference process model or standard understanding process capability in order to improve processes determining if the processes being practiced are adequately specified, designed, and implemented

13 Software Development Life Cycle (SDLC) Four key SDLC focus areas for secure software development Security Engineering g Activities Security Assurance Security Organizational and Project Management Activities Security Risk Identification and Management Activities iti Based on a survey of existing processes, process y g p, p models, and standards seems to identify the following

14 SDLC Security Engineering Activities activities needed to engineer a secure solution. security requirements elicitation and definition, secure design based on design principles for security, use of static analysis tools, Waterfall Model reviews and inspections, security testing, etc.. Security Assurance Activities verification, validation, expert review, artifact review, and evaluations.

15 SDLC Security Focused Activities Organizational management focused organizational policies, senior management sponsorship and oversight, establishing organizational roles,. Project management focused project planning and tracking, resource allocation and usage Security Risk Identification and Management Activities Cost-based Risk analysis Risk mitigation..

16 System DLC

17 Capability Maturity Models (CMM) CMM focuses on process characteristics Provides reference model of mature practices Helps identify the potential areas of improvement Provides goal-level definition for and key attributes for specific processes No operational guidance!! Focuses on/defines process characteristics

18 CMM Three CMMs Capability Maturity Model Integration (CMMI ), The integrated Capability Maturity Model (icmm), and the Systems Security Engineering Capability Maturity Model (SSE-CMM) Specifically to develop secure systems

19 Why CMM? Source:

20 CMMI CMM Integration (CMMI) provides the latest best practices related to development, maintenance, and acquisition, Includes Mechanisms to improve processes and Criteria for evaluating process capability and process maturity. As of Dec 2005, the SEI reports 1106 organizations and 4771 projects have reported results from CMMIbased appraisals its predecessor the software CMM (SW-CMM) its predecessor, the software CMM (SW CMM) Since 80s Dec, Organizations + 16,540 projects

21 CMMI

22 CMMI

23 Integrated CMM icmm is widely used in the Federal Aviation Administration (FAA-iCMM) Provides a single model for enterprise-wide improvement integrates the following standards and models: ISO 9001:2000, EIA/IS 731, Malcolm Baldrige National Quality Award and President's Quality Award criteria, CMMI-SE/SW/IPPD and CMMI-A, ISO/IEC TR 15504, ISO/IEC 12207, and ISO/IEC CD

24 Integrated CMM

25 Trusted CMM Trusted CMM Early Trusted Software Methodology (TSM) TSM defines trust levels Low emphasizes resistance to unintentional vulnerabilities High adding processes to counter malicious developers TSM was later harmonized with CMM Not much in use

26 Systems Security Engineering i CMM The SSE-CMM To improve and assess the security engineering capability of an organization provides a comprehensive framework for evaluating security engineering g practices against the generally accepted security engineering principles. provides a way to d i f i h li i f measure and improve performance in the application of security engineering principles.

27 SSE-CMM: ISO/IEC Purpose for SSE-CMM To fill the lack of a comprehensive framework for evaluating security engineering practices against the principles Helps Identify Security Goals Assess Security Posture Support Security Life Cycle The SSE-CMM also describes the essential characteristics of an organization s describes the essential characteristics of an organization s security engineering processes. The SSE-CMM is now ISO/IEC standard

28 SSE-CMM

29 Security Engineering i Process

30 Security Risk Process

31 Security is part of Engineering i

32 Assurance

33 SSE-CMM Dimensionsi Practices (generic) that indicate Process Management & Institutionalization Capability All the base practices

34 SSE-CMM 129 base practices organized into 22 process areas Security engineering : 61 of these - organized in 11 process areas Project and Organization domains : remaining Base practice Applies across the life cycle of the enterprise Does not overlap with other base practices Represents a best practice of the security community Does not simply reflect a state t of the art technique Is applicable using multiple methods in multiple business context Does not specify a particular method or tool

35 Process Area Assembles related activities in one area for ease of use Relates to valuable security engineering services Applies across the life cycle of the enterprise Can be implemented in multiple organization and product contexts Can be improved as a distinct process Can be improved by a group with similar interests in the process Includes all base practices that are required to meet the goals of the process area

36 Process Areas

37 Generic Process Areas Activities that apply to all processes They are used during Measurement and institutionalization i i i Capability levelsl Organize common features Ordered according to maturity

38 Capability Levels 0 Not Performed 1 Performed Informally 2 Planned & Tracked 3 Well Defined 4 Quantitatively Controlled 5 Continuously improving Base Practices Performed Committing to perform Planning performance Disciplined performance Tracking performance Verifying performance Defining a standard process Tailoring standard process Using data Perform a defined process Establishing measurable quality goals Determining process capability to achieve goals Objectively managing performance Establishing quantitative process goals Improving process effectiveness

39 Summary Chart.

40 Using SSE-CMM Can be used in one of the three ways Process improvement Facilitates understanding of the level of security engineering process capability Capability evaluation Allows a consumer organization to understand the security engineering process capability of a provider Assurance Increases the confidence that product/system/service is trustworthy

41 Process Improvement

42 Capability Evaluation No need to use any particular appraisal method SSE-CMM Appraisal (SSAM) method has been developed if needed SSAM purpose Obtain the baseline or benchmark of actual practice related to security engineering within the organization or project Create or support momentum for improvement within multiple levels of the organizational structure

43 SSAM Overview Planning phase Establish appraisal framework Preparation phase Prepare team for onsite phase through information gathering (questionnaire) Preliminary data analysis indicate what to look for / ask for Onsite phase Data gathering and validation with the practitionerinterviews Post-appraisal Present final data analysis to the sponsor

44 Capability Evaluation

45 Assurance A mature organization more likely to create a product or system with appropriate p assurance Process evidence to support claims for the product trustworthiness It is conceivable that An immature organization could produce high assurance product.

46 CMI/iCMM/SSE-CMMCMM CMMI / icmm used by more organizations than the SSE-CMM Because of the integration of process disciplines and coverage of enterprise issues, One weakness CMMI and icmm have gaps in their coverage of safety and security. Joint effort sponsored by FAA and the DoD to identify best safety and security practices for use in combination with the icmm and the CMMI.

47 Safety/Security additions The proposed Safety and Security additions include the following four goals: Goal 1 An infrastructure for safety and security is established and maintained. Goal 2 Safety and security risks are identified and managed. Goal 3 Safety and security requirements are satisfied. Goal 4 Activities and products are managed to achieve safety and security requirements and objectives.

48 Goal 1 related practices 1. Ensure safety and security awareness, guidance, and competency. 2. Establish and maintain a qualified work environment that meets safety and security needs. 3. Ensure integrity of information by providing for its storage and protection, and controlling access and distribution of information. 4. Monitor, report and analyze safety and security incidents and identify potential corrective actions. 5. Plan and provide for continuity of activities with contingencies for threats and hazards to operations and the infrastructure Goal 1 An infrastructure for safety and security is established and maintained. i

49 Goal 2 related practices 1. Identify risks and sources of risks attributable to vulnerabilities, security threats, and safety hazards. 2. For each risk associated with safety or security, determine the causal factors, estimate the consequence and likelihood of an occurrence, and determine relative priority. 3. For each risk associated with safety or security, determine, implement and monitor the risk mitigation plan to achieve an acceptable level of risk. Goal 2 Safety and security risks are identified and managed.

50 Goal 3 related practices 1. Identify and document applicable regulatory requirements, laws, standards, policies, and acceptable levels of safety and security. 2. Establish and maintain safety and security requirements, including integrity levels, and design the product or service to meet them. 3. Objectively verify and validate work products and delivered products and services to assure safety and security requirements have been achieved and fulfill intended use. 4. Establish and maintain safety and security assurance arguments and supporting evidence throughout h t the lifecycle. l Goal 3 Safety and security requirements are satisfied.

51 Goal 4 related practices 1. Establish and maintain independent reporting of safety and security status and issues. 2. Establish and maintain a plan to achieve safety and security requirements and objectives. 3. Select and manage products and suppliers using safety and security criteria. 4. Measure, monitor and review safety and security activities against plans, control products, take corrective action, and improve processes. Goal 4 Activities and products are managed to achieve safety and security requirements and objectives.

52 Team Software Process for Secure SW/Dev TSP provides a framework, a set of processes, and disciplined methods for applying software engineering principles at the team and individual level TSP for Secure Software Development (TSP- Secure) focus more directly on the security of software applications.

53 Team Software Process for Secure SW/Dev TSP-Secure Secure addresses secure software development (three ways). 1. Secure software is not built by accident Plan: TSP-Secure addresses planning for security. Self-direct: Since schedule pressures and people issues get in the way of implementing best practices, TSP-Secure helps to build self-directed development teams, and then put these teams in charge of their own work.

54 TSP-SecureS 1. Since security and quality are closely related, TSP-Secure helps manage quality throughout the product development life cycle. 2. Since people building secure software must have an awareness of software security issues, TSP-Secure includes security awareness training for developers.

55 TSP-SecureS Teams Develop their own plans Make their own commitments Track and manage their own work Take corrective action when needed

56 TSP-SecureS Initial planning Project Launch (3-4 days) Tasks include identifying security risks, eliciting and defining security requirement, secure design, and code reviews, use of static analysis tools, unit tests, and Fuzz testing. Next, the team executes its plan, and ensures all security related activities are taking place. Security status is presented and discussed during every management status briefing.

57 TSP-SecureS Basis Defective software is seldom secure Defective software is not inevitable Consider cost of reducing defects Manage defects throughout the lifecycle Defects are leading cause of vulnerabilities Use multiple defect removal points in the SD: Defect filters

58 TSP-SecureS Key questions in managing defects What type of defects lead to security vulnerabilities? Where in the software development life cycle should defects be measured? What work products should be examined for defects? What tools and methods should be used to measure the defects? How many defects can be removed at each step? How many estimated defects remain after each removal step? TSP S i l d t i i f d l TSP-Secure includes training for developers, managers, and other team members.

59

60 Correctness by Construction ti CbC Methodology from Praxis Critical Systems Process for developing high integrity software Has been successfully used to develop safetycritical systems Removes defects at the earliest stages uses formal methods to specify behavioral uses formal methods to specify behavioral, security and safety properties of the software.

61 Correctness by Construction ti The seven key principles of Correctness-by- Construction are: Expect requirements to change Know why you're testing (debug + verification) Eliminate errors before testing Write software that is easy to verify Develop incrementally Some aspects of software development are just plain hard Software is not useful by itself

62 Correctness by Construction ti Correctness-by-Construction Construction is one of the few secure SDLC processes that incorporate formal methods into many development activities. Requirements are specified using Z, and verified. Code (in Spark) is checked by verification software.

63

64 Correctness by Construction Defect detection/correction ti ti

65 Effort and Defect Rate

66 Agile Methods Agile manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

67 Agile manifesto principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing g requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people p and developers work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity the art of maximizing the amount of work not done is essential. The best architectures, requirements and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

68 Agile Processes Among many variations Adaptive software development (ASP) Extreme programming (XP) Crystal Rational Unified Process (RUP)

69 TSP Revisited - How TSP Relates to Agile.. Individuals and interactions over processes and tools TSP holds that the individual is key to product quality and effective member interactions are necessary to the team's success. Project launches strive to create gelled teams. Weekly meetings and communication are essential to sustain them. Teams define their own processes in the launch.

70 How TSP Relates Working software over comprehensive documentation TSP teams can choose evolutionary or iterative lifecycle models to deliver early functionality the focus is on high h quality from the start. t TSP does not require heavy documentation. Documentation should merely be sufficient to facilitate Documentation should merely be sufficient to facilitate effective reviews and information sharing.

71 How TSP Relates Customer collaboration over contract negotiation Learning what the customer wants is a key focus of the launch. Sustaining customer contact t is one reason for having a customer interface manager on the team. Focus on negotiation of a contract is more a factor of the organization than of whether TSP is used.

72 How TSP Relates Responding to change over following a plan TSP teams expect and plan for change by: Adjusting the team's process through process improvement proposals and weekly meetings. Periodically re-launching and re-planning whenever the plan is no longer a useful guide. Adding new tasks as they are discovered; removing tasks that are no longer needed. Dynamically rebalancing the team workload as required to finish faster. Actively identifying and managing risks.

73

74 Besnosov Comparison 50% of traditional security assurance activities are not compatible with Agile methods (12 out of 26), less than 10% are natural fits (2 out of 26), about 30% are independent of development method, and slightly more than 10% (4 out of 26) could be semiautomated and thus integrated more easily into the Agile methods.

75 Microsoft Trustworthy Computing SDLC Generally accepted SDL process at MS (actually spiral not waterfall as it indicates)

76 SDL Overview MS s SD 3 + C paradigm Secure by Design Secure by Default Secure by Deployment Communications software developers should be prepared for the discovery of product vulnerabilities and should communicate openly and responsibly The SDL is updated as shown next

77 SDL at MS Add the SD 3 + C praradigm

78 Design Phase Define Security architecture and design guidelines Identify tcb; use layering etc. Document the elements of the software attack surface Find out default security Conduct threat modeling Define supplemental ship criteria

79 Implementation ti phase Apply coding and testing standards Apply security testing tools including fuzzing tools Apply static analysis code scanning tools Conduct code reviews

80 Verification Phase Security push for Windows server 2003 Includes code review beyond those in implementation phase and Focused testing Two reasons for security push Products had reached the verification phase Opportunity to review both code that was developed or updated during the implementation phase and legacy code that was not modified

81 Results

82 Results

83 Topic to be continued