Secure Software

Development Lifecycle
Outline
+ Introduction
+ SDLC
+ Requirements
+ Architecture and Design
+ Implementation
+ Testing
+ Release and Maintenance
Software Development Lifecycle (SDLC)
+ Finite and definite period of time
+ Starts: when the SW product is conceived
+ Ends: when the SW is no longer used or available
+ SDLC is composed of phases Requirements

Release and Architecture and

Maintenance Design

Testing Implementation

3
Software Development Lifecycle (SDLC)
Requirements

Release and Architecture and

Maintenance Design

Testing Implementation
 A Ubiquitous Concern
+ You can make a security mistake at every step of the development
lifecycle
+ Requirements that allow for privacy violations
e.g. secretary can view everyone’s patient records
+ Introducing a design flaw, e.g. giving plug-ins total access
+ Introducing a code-level vulnerability, e.g. buffer overflow
+ Missing a vulnerability in code inspections & testing
+ Introducing a vulnerability by regression in maintenance
+ Not facilitating a secure deployment, e.g. installation defaults

5
Software liveliness
+ Software is not a one-shot effort
+ Software development, production, and
maintenance are cost/labor intensive
+ Software life-time can outlive hardware

6
Secure SE versus SE
+ What is the difference between software
engineering and secure software engineering?
+ If we have secure SE, why not also {reliable |
robust | resilient | reproducible | trusted |
verifiable | . . . } SE?

7
What is the Secure Development Lifecycle (SDL)?
+ There is a ready-made solution that provides a
structured approach to application security—the secure
development lifecycle (SDL).
+ It is a set of development practices for strengthening
security and compliance.
+ For maximum benefit, these practices should be
integrated into all stages of software development and
maintenance.
What are the benefits of SDL?
+ The most important reasons to adopt SDL practices are:
+ Higher security. In SDL, continuous monitoring for
vulnerabilities results in better application quality and
mitigation of business risks.
+ Cost reduction. In SDL, early attention to flaws significantly
reduces the effort required to detect and fix them.
+ Regulatory compliance. SDL encourages a conscientious
attitude toward security-related laws and regulations.
Ignoring them may result in fines and penalties, even if no
sensitive data is lost.
What are the benefits of SDL?
+ SDL also provides a variety of side benefits, such as:
+ Development teams get continuous training in secure
coding practices.
+ Security approaches become more consistent across
teams.
+ Customers trust you more, because they see that
special attention is paid to their security.
+ Internal security improves when SDL is applied to in-
house software tools.
What are the best SDL practices?
Requirements
Architecture and Design
Implementation
Testing
Release and Maintenance
What are the best SDL practices?
Requirements

Release and Architecture and

Maintenance Design

Testing Implementation
SDL
+ Most SDLs consist of the same basic building blocks
(application development stages):
+ Requirements
+ Architecture and design
+ Implementation
+ Testing
+ Release and maintenance
Requirements

14
Requirements
+ The purpose of this stage is to define the application concept and evaluate
its viability.
+ This includes developing a project plan, writing project requirements, and
allocating human resources.
+ Define security and compliance objectives for your project.
+ Prepare a list of security requirements for your project. Remember to
include both technical and regulatory requirements.
+ Training sessions provide essential security knowledge ranging from basic
threat awareness to in-depth information on secure development.
+ Adopting these practices improves the success of project planning and
locks in application compliance with security standards.
Security Requirements
+ Requirements are gathered during the initial phase of the software development life cycle.

+ This is an opportunity to not only gather functional requirements, but also security requirements.

+ Several methods exists for gathering security requirements.

+ We will look at misuse cases, which can be seen as a method in itself, but also takes part in more
elaborate methods (such as SQUARE).
+ A Misuse Case highlights something that should not happen (i.e. a Negative Scenario) and the threats
hence identified, help in defining new requirements, which are expressed as new Use Cases. (analyse
user/actor threats to the system. )
+ An Abuse Case is a type of complete interaction between a system and one or more actors, where the
results of the interaction are harmful to the system, one of the actors, or one of the stakeholders in the
system. (analyze vulnerabilities)
Requirements/Specification
+ Regular SE requirement specification plus
+ Security specification
+ Asset identification
+ Assess environment
+ Use cases and abuse cases

17
Architecture and
Design
18
Architecture and design
+ The purpose of this stage is to design a product that meets the requirements.
+ This includes modeling the application structure and its usage scenarios, as well as
choosing third-party components that can speed up development.
+ The result of this stage is a design document.
+ Threat modeling consists of identifying probable attack scenarios and adding relevant
countermeasures to the application design. Modeling uncovers possible threats early,
thus reducing the associated costs.
+ The design document and subsequent updates are validated in light of the security
requirements. Early design reviews assist in identifying features exposed to security
risks before they are implemented.
+ Vulnerabilities in third-party components can weaken the entire system, making it
important to monitor their security and apply patches when necessary.
Architecture and Design
+ Regular SE architecture and design
+ Threat modeling
+ Security design
+ Execution environment and actors
+ Design review
+ Design documentation

20
Implementation

21
Implementation
+ This is the stage at which an application is actually created.
+ This includes writing the application code, debugging it, and producing stable builds
suitable for testing.
+ Secure coding guides and checklists remind programmers of typical mistakes to be
avoided, such as storing unencrypted passwords.
+ Enforcing secure coding principles eliminates many trivial vulnerabilities and frees up
time for other important tasks.
+ Static application scanning tools (SAST) review newly written code and find potential
weaknesses without having to run the application.
+ Manual code reviews are still a must for building secure applications. Timely reviews
help developers to flag and fix potential issues before they shift attention to other
tasks.
Implementation
+ Regular SE implementation
+ Source code repository/version control
+ Coding standards (assertions, documentation)
+ Unit Testing
+ Source code review process
+ Automatic Static Analysis

23
Testing

24
Testing and bug fixing
+ The purpose of this stage is to discover and correct application errors.
+ This includes running automatic and manual tests, identifying issues, and
fixing them.
+ Dynamic application scanner tools (DAST) expose vulnerabilities by
simulating hacker attacks at runtime.
+ Fuzzing or Fuzz testing involves generating random inputs based on custom
patterns and checking whether the application can handle such inputs
properly.
+ Penetration testing is usually done by a third-party team of security
professionals to simulate possible attacks.
Testing
+ Regular SE testing
+ Security test plans
+ Automatic testing
+ Fuzzing
+ Symbolic execution
+ Red team testing
+ Continuous integration testing (Jenkins, Travis, etc)

26
Release and
Maintenance
27
Release and maintenance
+ At this stage an application goes live, with many instances running in a variety of
environments.
+ Eventually new versions and patches become available and some customers choose to
upgrade, while others decide to keep the older versions.
+ Environment management where real attackers exploit environment configuration
errors and vulnerabilities. Security monitoring must cover the entire system, not just
the application.
+ An incident response plan clearly describes the procedures your incident team must
follow to address any security breaches that might occur.
+ Security checks must be repeated on a regular basis because new types of
vulnerabilities are being discovered at a steady rate.
Release and maintenance
+ Dedicated security response team
+ Continuous process: new features, security
issues
+ Regression testing
+ Secure update deployment

29
Security Training
+ Even though training may not seem to fit
directly into any particular SDLC phase, it plays
a very important role in improving the overall
security of developed software.
+ Training should be a prerequisite for anyone
who has a role anywhere in the software
development environment.

30
Security Training
+ All developers and other technical members of the
software design/development/test teams should
undergo security training.
+ The training should explain the responsibilities of
their role, establish the expectations for their part
for security, and provide best practices and
guidance for developing high-quality software.

31
Getting started with secure development
+ Review popular SDL methodologies and choose the one that suits you best.
+ "Mind the gap"—match your current security practices against the list of SDL activities
and identify the gaps.
+ Come up with a list of practices to cover the gaps. Prioritize them and add activities
that improve security to your project's roadmap.
+ Train your team on security and relevant regulations to improve awareness of possible
threats.
+ "Shift left" by implementing each security check as early as possible in the
development lifecycle.
+ Automate everything you can.
+ Do not hesitate to hire outside experts.
Summary
+ Software lives and evolves
+ Security must be first class citizen
+ Secure Requirements/specification
+ Security-aware Design (Threats?)
+ Secure Implementation (Reviews?)
+ Testing (Red team, fuzzing, unit)
+ Release and Maintenance

33
 Questions?
Question in
my mind is Should I
? ask this ?

hmmmmmm Sorry I
mmm? was
sleeping
madam !

34