The document discusses software development security and the software development life cycle (SDLC). It covers integrating security into each phase of the SDLC, including initiation, development, implementation, operation, and disposal. Different SDLC methodologies are described, such as waterfall, agile, DevOps, and DevSecOps. Maturity models for software security and the role of integrated product teams are also summarized.

1. Software Development
Security
(Understanding, Applying, and Enforcing Software Security)

2. • 8.1 Understand and integrate security in the Software
Development Life Cycle (SDLC)
• 8.2 Identify and apply security controls in software
development ecosystems
• 8.3 Assess the effectiveness of software security
• 8.4 Assess security impact of acquired software
• 8.5 Define and apply secure coding guidelines and
standards
Domain 8: SW Development Security 2
Test Objectives at a Glance

3. 8.1 Understand and integrate security in the Software
Development Life Cycle (SDLC)
• Development methodologies (e.a. Agile, Waterfall, DevOps,
DevSecOps)
• Maturity models (e.g. Capability Maturity Model (CMM), Software
Assurance Maturity Model (SAMM))
• Operation and maintenance
• Change management
• Integrated product team (IPT)
Domain Objectives 8.1
Domain 8: SW Development Security 3

4. • Focuses on security at every level
• Used to plan, execute, and control a software development
project
• Security plan is the first step of any SDLC model
• Multiple models of the SDLC
• Most models contain 5 basic phases:
• Initiation
• Development/acquisition
• Implementation
• Operation
• Disposal
Systems Development Life Cycle (SDLC)
Domain 8: SW Development Security 4

5. Systems Development Life Cycle (ISC)2
System Development Lifecycle
Phases
• Project Initiation and planning
• Functional Requirements Definition
• System Design Specifications
• Development and Implementation
• Documentation and Common
Program Controls
• Testing and
EvaluationControl(Certification/Acc
reditation)
• Transition to Production
System Lifecycle has
two additional Phases
• Operations and
Maintenance
Support
• Decommissioning/Di
sposal and System
Replacement
Domain 8: SW Development Security 5

6. • Determine security requirements
• Conduct risk analysis
• Define security strategy
Domain 8: SW Development Security 6
Project Initiation and Planning Security
Activities

7. • Identify Security Areas
• Establish security requirements
• Security tests
• Define strategy
• Develop functional baseline
Domain 8: SW Development Security 7
Functional Requirements Specifications
Security Activities

8. • Establish security specifications
• Update security test plans
• Document security baseline
Domain 8: SW Development Security 8
Detailed Design Specifications Security
Activities

9. • Develop security code
• Evaluation of security code
• Document security code
Domain 8: SW Development Security 9
Development and Documentation Security
Activities

10. • Test security components
• Validate security in integrated systems
• Implement security code
• Document security controls
• Certify secure operations
• Accept secure system
Domain 8: SW Development Security 10
Testing, Acceptance, and Transition into
Production Security Activities

11. Waterfall Lifecycle Method
Measure Twice,
Cut Once
Software Development Methods
• Finish one stage prior to
starting the next
• Requires formal reviews before
moving into the next phase
• Heavy overhead in planning and
administration
• No changes once the project is
started
• Paradigm for non-iterative models
• Non-iterative are more secure
Domain 8: SW Development Security 11
Requirements
Analysis
Design
Development
Testing
Maintenance

12. • Non-iterative
• Estimated costs and schedules are revised at the end of
each risk assessment
• Decision to proceed/cancel project is revisited after
each risk assessment
• Nested waterfall phases
• Each phase has 4 sub phases
• Phases based on Deming PDCA
• Plan, do, check, act
Spiral Model
Domain 8: SW Development Security 12

13. • Simplest and least disciplined method
• Useful for small development projects where quality is not
essential.
• Not a recommended software development practice.
1. Developer creates the first version of the program with
limited specification and design
2. Software developer may sketch out a functional or
technical design based on customer needs
3. From the initial project, the software is repeatedly
modified until the customer is satisfied.
Domain 8: SW Development Security 13
Build and Fix

14. • A repetitive mini waterfall
• A series of small, incremental development projects
• Without a complete understanding of ultimate end product,
success may be hard to achieve
1. Determine system requirements
2. Evaluate and prioritize
3. Develop based on priority
Domain 8: SW Development Security 14
Incremental Method

15. • Non-iterative
• Write good code the first time
• Controls defects in software
• Quality achieved through design versus testing and
remediation
• Focus is on defect prevention rather than defect
removal
Clean Room Model
Domain 8: SW Development Security 15

16. • Prototyping
• Iterative
• Developed to combat the weaknesses of the waterfall model
• Refine prototype until acceptable
• 4 Step Process:
• Initial Concept
• Design and Implement Initial Prototype
• Refine Prototype
• Complete and Release
Prototyping Model
Domain 8: SW Development Security 16

17. • Modified Prototype Model (MPM)
• Iterative
• Ideal for web application development
• Allows for basic functionality to be deployed in a quick time frame
• Maintenance phase begins after the deployment
• Application evolves as the environment changes (not frozen in
time)
Modified Prototype Model (MPM)
Domain 8: SW Development Security 17

18. • Rapid Application Development (RAD)
• Iterative
• Rapid prototyping within strict time limits
• Can be a disadvantage if decisions are made too quickly
• Joint Application Development (JAD)
• Iterative
• Management process that allows developers to work directly with
users. Can help with RAD
• Key players communicate at key phases of development
Rapid Application Development (RAD) /
Joint Application Development (JAD)
Domain 8: SW Development Security 18

19. • Requirements built on what is available
• Built on assumptions as to how the system might work
• Consists of planning and trying different designs before development
• Not cost-effective
• Results in less-than-optimal systems
• Iterative
Exploratory Model
Domain 8: SW Development Security 19

20. • Component Based Development
• Involves using standardized building blocks to assemble, rather
than develop, an application
• May be a security advantage as the components have previously
been tested for security
• Similar to Object Oriented Programming (OOP)
Component Based Model
Domain 8: SW Development Security 20

21. • Reuse Model
• Built from existing components
• Best suited for projects using
object oriented development
… because objects can be
exported, reused, and
modified
• Libraries of software modules
are maintained to be copied
for use in any system
Reuse Model
Domain 8: SW Development Security 21

22. • Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• More flexible
• Fast turnaround
• Strong communications
• Customer involvement
• Methods include scrum and extreme programming
Agile Model
Domain 8: SW Development Security 22

23. Waterfall Model versus Agile Model
Domain 8: SW Development Security 23

24. • Extreme Programming (XP)
• Based on simplicity, communications, and feedback
• Relies on subprojects of limited and defined scope with
programmers working in pairs
• Code quality improves to compensate for second
programmer cost.
• Relies on continuous integration and test-driven
development to produce working software.
Extreme Programming (XP) Model
Domain 8: SW Development Security 24

25. • Small teams of developers called
scrum teams
• Scrum master supports the
scrum team
• Product owner makes major
decisions
• The teams take the project from
start to finish, handing off similar
to rugby
Scrum Development Model
Domain 8: SW Development Security 25

26. • An approach based on lean and agile principles in which
business owners and the development, operations, and
quality assurance departments collaborate and work
together to deliver software in a continuous manner that
enables the business to more quickly react to market
opportunities and reduce the time to include customer
feedback into products.
• A set of practices that combines software development and
IT operations.
• It trys to shorten the systems development life cycle and provide
continuous delivery with high software quality.
Domain 8: SW Development Security 26
DevOps

27. • it is short for development, security and operations.
• Make everyone accountable for security with the objective
of implementing security decisions and actions at the same
scale and speed as development and operations decisions
and actions
• DevSecOps tools ensures security is built into applications
instead of added later.
• When security is present during every stage of the software
delivery lifecycle, the cost of compliance is reduced and
software is delivered and released faster
Domain 8: SW Development Security 27
DevSecOps

28. • A tool for process improvement (capability maturity model)
• Used to evaluate areas of capability or performance and to
point out specific areas of improvement
• May be used as a standard to evaluate a process
• Can be used as a bench mark or score card to evaluate
performance or identify improvement areas.
Domain 8: SW Development Security 28
Maturity Models

29. Levels
• Initial
• Managed
• Defined
• Qualitatively managed
• optimizing
Domain 8: SW Development Security 29
Maturity Models: Capability Maturity Model
(CMM)

30. Process level improvement program created to integrate an
assessment and process improvement guidelines for separate
organizational functions.
Levels
• Incomplete
• performed
• Managed
• Defined
• Qualitatively managed
• optimizing
Domain 8: SW Development Security 30
Maturity Models: Capability Maturity Model
Integration (CMMI)

31. BSIMM: Descriptive software security focused maturity
model based on actual software security initiatives. Available
under the creative commons license. An evidence based
model as it reflects real world industry activities.
SAMM: framework to help organizations formulate and
implement a security software strategy that is tailored to the
specific risks facing an organization (prescriptive framework).
Maintained by OWASP. Based on: governance, construction,
verification, and operations
Domain 8: SW Development Security 31
Maturity Models: Building Security in Maturity
Model (BSIMM) & Software Assurance Maturity
Model (SAMM)

32. • An Integrated Product Team (IPT) is a multidisciplinary
group of people who are collectively responsible for
delivering a defined product or process.
• IPTs are used in complex development programs/projects
for review and decision making.
• The emphasis of the IPT is on involvement of all
stakeholders (users, customers, management, developers,
contractors) in a collaborative forum
Domain 8: SW Development Security 32
Integrated Product Team

33. • Combine product design and process design to better
understand product requirements
• Facilitates meeting cost and performance objectives
• Facilitates multi-skilled team members working together
through the concept of integrated product teams
• Allows for team decisions to made from input from the
entire team.
Domain 8: SW Development Security 33
Integrated Product and Process
Development (IPPD)

34. Questions?
Domain 8: SW Development Security 34