Secure Software Development Models/MethodsSome Terms: ProcessProcess ModelsSlide 4AssessmentsSoftware Development Life Cycle (SDLC)SDLCSlide 8System DLCCapability Maturity Models (CMM)CMMWhy CMM?CMMISlide 14Integrated CMMSlide 16Trusted CMMSystems Security Engineering CMMSSE-CMMSlide 20Security Engineering ProcessSecurity Risk ProcessSecurity is part of EngineeringAssuranceSSE-CMM DimensionsSlide 26Process AreaProcess AreasGeneric Process AreasCapability LevelsSlide 31Using SSE-CMMProcess ImprovementCapability EvaluationSSAM OverviewSlide 36Slide 37CMI/iCMM/SSE-CMMSafety/Security additionsGoal 1 related practicesGoal 2 related practicesGoal 3 related practicesGoal 4 related practicesTeam Software Process for Secure SW/DevSlide 45TSP-SecureSlide 47Slide 48Slide 49Slide 50Slide 51Correctness by ConstructionSlide 53Slide 54Slide 55Slide 56Agile MethodsSlide 58Agile ProcessesAdaptive software development (ASP)XP RevisitedCrystalSlide 63Slide 64Rational Unified ProcessSlide 66How TSP RelatesSlide 68Slide 69Slide 70Slide 71Besnosov ComparisonMicrosoft Trustworthy Computing SDLCSDL OverviewSDL at MSDesign PhaseImplementation phaseVerification PhaseResultsSlide 80Secure Software Development Models/MethodsSecure Software Development Models/MethodsJan 23, 2006IS 2935: Developing Secure SystemsLecture 2IS 2935: Developing Secure SystemsLecture 2Some Terms: Process•Process–A sequence of steps performed for a given purpose [IEEE]•Secure Process–Set of activities performed to develop, maintain, and deliver a secure software solution–Activities could be concurrent or iterativeProcess Models•Process model–provides a reference set of best practices that can be used for both •process improvement and •process assessment. –defines the characteristics of processes. –Usually have an architecture or a structure. •Most process models also have a capability or maturity dimension, that can be used for –assessment and –evaluation purposes.Process Models•Process Models–have been produced to create •common measures of organizational processes throughout the software development lifecycle (SDLC). –identify many technical and management practices–primarily address good software engineering practices to manage and build software –Do not, however, guarantee software developed is bug freeAssessments•Assessments, evaluations, appraisals–Imply comparison of a process being practiced to a reference process model or standard. –used to understand process capability in order to improve processes. –help determine if the processes being practiced are •adequately specified, designed, integrated, and implemented sufficiently to support the needsSoftware Development Life Cycle (SDLC)•A survey of existing processes, process models, and standards seems to identify the following four SDLC focus areas for secure software development.–Security Engineering Activities –Security Assurance –Security Organizational and Project Management Activities –Security Risk Identification and Management ActivitiesSDLC•Security Engineering Activities include –those activities needed to engineer a secure solution. –Examples include •security requirements elicitation and definition, secure design based on design principles for security, use of static analysis tools, reviews and inspections, secure testing, etc.. •Security Assurance Activities include –verification, validation, expert review, artifact review, and evaluations.SDLC•Security Organizational and Project Management Activities include –Organizational management•organizational policies, senior management sponsorship and oversight, establishing organizational roles, and other organizational activities that support security. –Project management •project planning and tracking, resource allocation and usage to ensure that the security engineering, security assurance, and risk identification activities are planned, managed, and tracked.•Security Risk Identification and Management Activities –identifying and managing security risks is one of the most important activities in a secure SDLCSystem DLCCapability Maturity Models (CMM)•CMM–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–Defines process characteristicsCMM•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 securityWhy CMM?Source: http://www.secat.com/download/locked_pdf/SSEovrw_lkd.pdfCMMI•CMM Integration (CMMI) provides –the latest best practices for product and service development, maintenance, and acquisition, including mechanisms to help organizations improve their processes and provides criteria for evaluating process capability and process maturity. •As of March 2005, the SEI reports 567 organizations and 2339 projects have reported results from CMMI-based appraisals •its predecessor, the software CMM (SW-CMM)CMMIIntegrated CMM•iCMM is widely used in the Federal Aviation Administration–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 15288.Integrated CMMTrustedCMM•Trusted CMM–In early 1990 as 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 useSystems SecurityEngineering CMM•The SSE-CMM –is a process model that can be used to improve and assess •the security engineering capability of an organization. –provides a comprehensive framework for •evaluating security engineering practices against the generally accepted security engineering principles. –provides a way to measure and improve performance in the application of security engineering principles.SSE-CMM•Purpose for SSE-CMM–although the field of security engineering has several generally accepted principles, it lacks a comprehensive framework for evaluating security engineering practices against the principles. •The