Secure

Software
Development
What does Secure Design in Software Development
mean?

"Secure-by-design" is an approach to designing and building systems

with security in mind. It involves implementing continuous security
practices, tools, and controls from the beginning of the software
development lifecycle, ensuring that products are inherently secure.

Secure-by-design is rooted in the DevSecOps philosophy – merging

development, security, and operations. It helps to foster a culture of
security awareness and responsibility across the teams.
Secure Software Development Life Cycle Process
7 Principles of Secure Design in Software Development

Security as Code (SaC) SaC involves writing scripts or

transforms security practices predefined code templates to
from manual processes to enforce security policies,
1. Security as Code automated, scriptable performing vulnerability
components within the assessments, and automating
software development remediation and security
lifecycle. scanning processes.
7 Principles of Secure Design in Software Development

Secure Defaults could manifest

This approach stems from the
Adopting Secure Defaults is a in robust password policies,
understanding that many end-
fundamental principle that multi-factor authentication
users stick to default settings.
2. Secure Defaults mandates systems requirements, and even the
By setting these defaults to be
configurations to be inherently default turning off extra
highly secure, you can
safe. services or features that could
safeguard most users.
serve as attack vectors.
7 Principles of Secure Design in Software Development

The Least Privilege principle is a

crucial best practice for Identity
and Access Management (IAM).
Adopting this approach reduces the
And it doesn’t just apply to users -
potential damage of a breach by
3. Least Privilege every component in your system
reducing the accessible attack
(machine identities such as
surface.
resources and networks) should
also operate with the least privilege
necessary to perform its function.
7 Principles of Secure Design in Software Development

Separation of Duties
(SoD) is about dividing No user should have a
4. Separation of tasks and privileges to level of access that
Duties minimize the risk of allows them to misuse a
malicious activity or system on their own.
errors..
7 Principles of Secure Design in Software Development

The Attack Surface Area Minimizing ASA is about

(ASA) represents all the limiting these entry
5. Minimize Attack points where an points, thereby shrinking
Surface Area unauthorized user can the opportunities for
interact with a system or adversaries to exploit
application. . vulnerabilities.
7 Principles of Secure Design in Software Development

Complete mediation
mandates that every access
request to any system
6. Complete Mediation resource is thoroughly
authenticated and authorized.
This should happen every
time, without exception.
7 Principles of Secure Design in Software Development

The principle of failing When something goes

securely dictates that a wrong, the system should
system should respond to default to a secure state
7. Failing Securely errors or failures in a way rather than exposing
that preserves the overall vulnerabilities or sensitive
security of the application. information.
Code Review
 Code review is a systematic and collaborative
process in software development where one or
more developers examine and evaluate another
developer’s code to identify issues, provide
feedback, and ensure that the code meets quality
standards.
Code
Review The primary goal is to improve the maintainability,
quality, and reliability of the codebase, resulting in
the overall success of a project while also
promoting knowledge sharing and learning among
team members.
 Bug Detection
Collaboration Documentation
and Prevention

Why is Code
Review Improved
Quality of Code
Code
Ownership
Quality
Assurance

important?
Knowledge
Continuous
Consistency Sharing and
Improvement
Learning
Types of Code Review
Types of Code Review

Pull Request (PR) Reviews: In Git-based version control systems like GitHub, etc.,
developers often create pull or merge requests to propose changes to the codebase.
These pull requests are reviewed by the team members before the changes are merged.

Pair Programming: In pair programming, two developers work together on the same
computer, with one writing code while the other reviewing it in real time. This form of code
review is highly interactive.

Over-the-Shoulder Reviews: A developer may ask a team member to review their code by
physically sitting together and going through the code on the computer screen.

Tool-Assisted Reviews: Various tools and platforms are available to facilitate code reviews,
such as GitHub, GitLab, Bitbucket, and code review-specific tools like Crucible and Review
Board.
Types of Code Review

Email-Based Review: In email-based reviews, code changes are sent via email, and the
reviewers provide feedback and comments in response. The discussion occurs over email
threads.

Checklist Review: In a checklist review, a checklist is used to evaluate the code. Reviewers
go through the list and check off items as they are reviewed.

Ad Hoc Review: Ad hoc reviews are informal and spontaneous. Developers may
spontaneously ask team members to take a quick look at their code or discuss changes
without a formal process.

Formal Inspection: Formal inspections are a structured form of code review that follows a
predefined process. They often involve a dedicated inspection team and detailed
documentation.
Code Review Process
Code Review Process

2. Reviewer Selection: One or more

1. Preparation: The developer who has
team members are assigned as
completed a piece of code or feature
reviewers. Reviewers must have the
initiates the code review by creating a
relevant expertise to assess the code
review request or notifying the team.
properly.

3. Code Review Environment or

Tools: Code reviews are often 4. Code Review Checklist: Reviewers
facilitated using specialized tools or may refer to a code review checklist or
integrated development environments coding standards to ensure that the
(IDEs) that allow reviewers to view the code follows established guidelines.
code changes and leave feedback.
Code Review Process

5. Code Inspection: Reviewers examine the

6. Feedbacks and Comments: Reviewers
code thoroughly, looking for issues such as:
provide comments within the code review
syntax errors, logic errors, performance
tool, explaining any issues they find. These
bottlenecks, security vulnerabilities, coding
comments should be clear, constructive, and
standard consistencies, adherence to best
specific, making it easier for the author to
practices along with the code’s overall
understand the feedback.
design, scalability, and maintainability.

7. Discussion: The author and reviewers 9. Revisions: The author makes necessary
engage in a discussion about the code changes based on the feedback received
changes. This dialogue can involve and continues to engage in discussions until
clarifications, explanations, and suggestions all concerns are addressed. This may involve
for improvement. multiple review iterations.
Code Review Process

10. Approval: Once reviewers are 11. Integration: The approved code
satisfied with the code changes and all changes are integrated into the main
concerns have been resolved, they codebase, typically using version
approve the code for integration. control systems.

13. Documentation and Closure: The

12. Follow-Up: After integration, it’s
code review process is documented
crucial to monitor the code in the
for future reference, and the review is
production environment to ensure that
officially closed. This documentation
the changes work as expected and do
may include the review comments,
not introduce new issues.
decisions made, and any action items.
Threat Modelling

Threat modeling is a structured approach to identifying and prioritizing potential

threats to a system. The threat modeling process includes determining the value
that potential mitigations would have in reducing or neutralizing these threats.

Threat modeling works to identify, communicate, and understand threats and

mitigations within the context of protecting something of value.

Threat modeling also provides a clear ‘line of sight’ across a project that can be
used to justify other security efforts.
Purpose of Threat Modeling

Documentation from this process

The purpose of Threat modeling provides system analysts and
is to identify, communicate, and defenders with a complete
understand threats and mitigation analysis of probable attackers’
to the organization’s stakeholders profiles, the most likely attack
as early as possible. vectors, and the assets most
desired by the attacker.
Threat 1. Aim
Modeling
Process The target before approaching Threat Modeling
must be clear within ourselves what we will
achieve from Threat Modeling, that is our
application must follow the CIA Triad.
• Confidentiality: It helps in protecting data from unauthorized
access.
• Integrity: It helps in preventing restricted changes.
• Availability: It helps in performing important tasks under
certain attacks.
 2. Visualization

Threat Here, we will deal with what we are going to build. We must
have a document overview of the application which helps in

Modeling making our process easier. Here we will build diagrams that
will help us in making our process easier.

Process
It can be done in two ways:

• Data Flow Diagram: It helps in showing how the flow of data occurs in the
system.
• Process Flow Diagram: It helps in finding the process of the system that from
where users interact in the system, and how the system works internally.
 3. Threat Identification

Here we are going to deal with how we can identify threats or what
can go wrong in the process.

Threat
Modeling By analyzing the images of the previous section, you have found how
threats can be identified.

Process
4. Mitigation

Here, we are going to deal with what we will do about the Threats.
Here we will review the layers to identify the required vulnerabilities.

Mitigation involves a continuous investigation of each vulnerability so

that the most effective efforts can be designed.
 5. Validation

Threat
Modeling
Process This is the final step in the process of
Threat Modeling, here we are going to
deal with whether we have done a good
job or not.

Have all the threats been mitigated or not?

We will check the changes and as threat
modeling is not a one-time activity, we
have to regularly watch these things.
Threat Modeling Methodology

• Threat modeling methodology refers to a structured approach or

framework used to identify, assess, and prioritize potential security threats
in a system or application.
 Popular Threat Modeling Methodologies:

1. STRIDE:

STRIDE is a threat modeling methodology developed by Microsoft, focusing on the types of

threats and how to categorize them. It’s especially useful for systems with complex
interactions, helping teams think through potential attack vectors.

• Spoofing: Impersonating something or someone.

• Tampering: Modifying data or system resources.
• Repudiation: Denying actions or transactions.
• Information Disclosure: Exposing confidential data to unauthorized parties.
• Denial of Service: Disrupting service or access to resources.
• Elevation of Privilege: Gaining unauthorized access or privileges.
Popular Threat Modeling Methodologies:

2. PASTA (Process for Attack Simulation and Threat Analysis):

PASTA is a risk-centric methodology that aims to simulate potential attacks to assess the risk
posed by different threats. It’s designed to be a high-level approach to understanding the
attacker’s perspective.
PASTA consists of seven stages:
• Define the objectives of the analysis.
• Identify the attack surface.
• Identify threats and vulnerabilities.
• Perform risk analysis.
• Simulate attacks to assess the real-world impact.
• Define mitigation strategies.
• Reevaluate and improve the system.
Popular Threat Modeling Methodologies:

3. OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)

OCTAVE is a strategic threat modeling methodology that emphasizes the organizational risk
management perspective.

Unlike other methodologies that focus primarily on technology, OCTAVE takes into account the people,
processes, and assets involved in the system.

OCTAVE is divided into three phases:

Phase 1: Build Asset-Based Threat Profiles: Identify assets, security requirements, and business
processes.

Phase 2: Identify and Analyze Threats: Identify threats and vulnerabilities to assets, including potential
adversaries and attack scenarios.

Phase 3: Develop Security Strategy: Develop a risk-based security plan and mitigation strategy to
protect critical assets.
Popular Threat Modeling Methodologies:

4. VAST (Visual, Agile, and Simple Threat modeling)

VAST was created to address the need for visual and agile threat modeling, especially
in environments where systems are constantly evolving. It focuses on simplifying the
process and integrating threat modeling into agile development practices.

VAST’s main principles:

• Visual Threat Modeling: Creates visual models to identify potential threats. These diagrams often show data
flows, components, and interactions in easy-to-understand formats.
• Agility: VAST integrates with agile software development practices, allowing for continuous assessment of
risks as the system evolves.
• Simplicity: Aims to avoid overwhelming teams with unnecessary complexity, making threat modeling more
accessible for developers, business stakeholders, and security teams.
Popular Threat Modeling Methodologies:
5. LINDDUN

LINDDUN is a methodology focused on privacy threat modeling, especially useful for

systems handling personal data and meeting privacy regulations.

It is tailored for assessing data privacy threats rather than just security threats.

LINDDUN stands for:

• Linkability: The risk of linking data between different datasets or contexts.

• Identity Disclosure: Exposing someone's identity without consent.
• Non-repudiation: Ensuring that actions or data cannot be denied (such as a user denying that they accessed
specific data).
• Detectability: The ability of an attacker to detect the existence of sensitive information.
• Disclosure of Information: Unauthorized release of private information.
• Unawareness: When individuals are unaware of how their data is being used or processed.
• Non-compliance: Violating data protection laws and regulations (e.g., GDPR).
Popular Threat Modeling Methodologies:

6. Attack Tree Analysis

Attack Tree Analysis is a hierarchical model used to represent attacks on a system as a tree,
with the goal of breaking down the attack into simpler sub-goals. Each node represents an
attack step, and the leaves of the tree are basic attack methods or techniques.

Key components:

• Root Node: Represents the high-level goal or objective of the attack (e.g., gaining unauthorized access to a system).
• Sub-Goals: Nodes representing steps to achieve the root goal (e.g., exploiting a vulnerability, bypassing
authentication).
• Leaf Nodes: Specific attack techniques or actions (e.g., using stolen credentials, exploiting a bug).
The choice of threat modeling methodology largely depends on the context of
your system and objectives:
PASTA is suited for
STRIDE is great for identifying
organizations that want to take
general threats and is widely
a risk-centric approach,
applicable to many kinds of
especially for large, complex
systems.
systems.

OCTAVE is ideal for

VAST is perfect for agile
organizations looking for
development environments and
strategic risk management
systems that need quick,
with an emphasis on assets and
iterative threat analysis.
organizational processes.

LINDDUN is designed Attack Tree Analysis helps in

specifically for systems where visualizing and breaking down
privacy concerns are potential attack scenarios in a
paramount, especially regarding methodical, hierarchical
data protection regulations. manner.