Agile Methods

“Build a little, Test a little, Field a little”

Principles:
– Satisfy the customer- Early and continuous delivery of software
– Change requirements, even late in the development process
– Multiple releases
– Meetings are done face to face
– Repeat the “traditional” development cycle – linear development
– The production of working software is the primary measure of succ ess
Implication for Security
– Risk - Security testing will be inadequate
– Security impact of all new/changing requirements
– Schedule is given more importance over security
– No documented evidence
– “Working software” does not mean “software that always functions correctly and securely

Slide 1
 Agile method - Project Management
Mismatches
• Specialization of development team members
– NOT ALLOWED, Like – security experts
• Planning for software security practices and
reviews is not easily accommodated
• Implicit trust in developers – Entire agile team
have access to all software artifacts, including
those not developed by them.
– NO - separation of roles
– NO - separation of duties
– NO - ability to perform secure configuration Slide 2
 Security-Enhanced Development
Methodologies
• Phase-by-phase guidance - promoting
security-enhanced development of software
throughout the life cycle phases
• Modify traditional SDLC activities - insert new
activities with the objective :
– Reducing the number of weaknesses and
vulnerabilities
– Increasing software’s dependency in the face of
threats
Slide 3
 Microsoft Trustworthy Computing
Goals: SDL
1. To reduce the number of security-related design and coding defects in Microsoft software
2. To reduce the severity of the impact of any residual defects
• Microsoft claims up to an 87-percent reduction in security incidents
Disadvantages:
– Not well suited for noncommercial software projects like federal and government project
– Concentration is more on –
• Development
• Distribution,
• Patching
• Maintenance
• Customer support
– And not on activities related to
• Installation
• Deployment
• Operation
• Disposal
– Does not explicitly address business and other nontechnical inputs to the software process

Slide 4
Slide 5
• Conduct evaluations post-production, reporting vulnerabilities
Support and Servicing
• Final security review Release
• Software’s ability to withstand newly reported vulnerabilities
• Enters beta Testing Verification
• Penetration testing
• The product team codes, tests, and integrates the software Implementation/Development
• Developers use security tools, security checklists, and secure coding best practices
• Key participants—architects, developers, and designer Design
• Perform feature design
• How to integrate security Requirements
• Identifies critical objectives
• How security features will affect or be affected by other software
Thinking of deleting this
 Oracle Software Security Assurance
Process
• Oracle has adopted a secure development process in which all
developers are required to
– Follow secure coding standards
– Use standard libraries of security functions (authentication, cryptography)
– Perform extensive security testing
– Validations against security checklists
– Consider third-party (government and industry) security
• Disadvantages:
– The main emphasis of the this process appears to be on security patch
distribution
– Not widely usable or adaptable by other software firms – No resources are
available
– Guidance for developers of applications or systems that incorporate Oracle
databases is not provided

Slide 6
 CLASP
• Designed to insert security methodologies into each life cycle phase
• Released under an open source license
• Set of 30 security-focused activities - integrated into any software development process
• Detailed implementation guide includes:
– Activity Assessment
– Vulnerability Catalog
– CLASP and RUP

TSP-Secure
 Goals - Reduce or eliminate software vulnerabilities that result from software design and
implementation mistakes
 Two core values:
1. Team-oriented environment
2. It guides engineers through the engineering process to
• Reduce the likelihood of skipping steps
• Reduce time to figure out the next move

Slide 7
 Research Models
• Developed by academic researchers
• Have undergone only limited testing
• Not complete and are still working on
modifications, refinements, and further
testing

Slide 8
 Secure Software Development Model
• Unified model - Integrates security
engineering into the software development
process
Security
• Four-phase workflow
Security Training Threat Modeling
Specification
Review of Security

Waterfall-Based Software Security Engineering Process

Model
 Security engineering activities and artifacts are added to functionality-focused
development activities at each phase of their waterfall model
 Disadvantages:
• No testing, verification, or validation of Model

Slide 9