SSDLC AWARENESS SESSION

Secure Software Development

Lifecycle
Muzammil Khan
Senior Offensive Security Team

PNPT
Muzammil Khan started his career as a Information Security
Engineer with expertise in Desktop, Web, Mobile, Networks
and ATM machines as well. Also, he has done some hands-on
in RedTeam Assessments, Malware Analysis and Exploit
Development. He is an active participant of International
and national CTF competitions like HTB Apocalypse, RedTeam
Village 29 Defcon, and got 1st Position in OS Exploitation
in Cyber Hackathon by Ignite.
OBJECTIVES
▪ Understand what SSDLC is and why it's important.

▪ Learn about the processes of SSDLC.

▪ Understand the Secure-SDLC with respect to OWASP.

SECURE SOFTWARE DEVELOPMENT LIFECYCLE (SSDLC)

▪ During SDLC, security testing was introduced very late in the lifecycle.

▪ Bugs, flaws, and other vulnerabilities were identified late, making them far
more expensive and time-consuming to fix.

▪ In most cases, security testing was not considered during the testing phase,
so end-users reported bugs after deployment.

▪ Secure-SDLC models aim to introduce security at every stage of the SDLC.

WHY IS SECURE-SDLC IMPORTANT?
A study conducted by the Systems and Sciences institute at IBM discovered that it
costs six times more to fix a bug found during implementation than one identified
as early as during the design phase. It also reported that it costs 15 times more
if flaws are identified during testing and up to 100 times more costly if
identified during the maintenance and operation phases. (Shift Left Approach)
WHY IS SECURE-SDLC IMPORTANT?
Apart from faster development and reduction of costs, integrating security across
the SDLC helps discover and reduce vulnerabilities early, reducing business risk
massively.

Examples of introducing security at all stages are architecture analysis during

design, code review and scanners during the development stage and conducting
security assessments (e.g. penetration tests) before deployment.

ARCHITECTURE REVIEW

PENTEST
MYSITE.COM
DESIGN DEPLOYEMENT
PHASE
PHASE
CODE
DB SERVER REVIEW

DEV
PHASE
WHY IS SECURE-SDLC IMPORTANT?
For example, in waterfall models, this sort of testing was carried out at the end
of the lifecycle, right before production; in more agile processes, we can
implement a "Security by Design" approach.

If the pentests result in errors like an SQL injection in a waterfall scenario,

mitigating the bugs would entail doing another cycle to fix the bug.

It would require redesigning, applying the changes and retesting to check it has
been remediated.

In a more agile approach, discussions on whether to prevent flaws like this, such
as deciding on parameterization during the planning phase, can avoid having to
roll back changes, and it only costs a planning discussion.
WHAT WE HAVE LEARNED SO FAR?

▪ Security is a constant concern, improving software quality and security

constantly.

▪ Boosting security education and awareness: all stakeholders know each phase's
security recommendations and requirements.

▪ Flaws are detected early before deployment, reducing the risk of getting hacked
or disrupted.

▪ Costs are reduced, and speed increases, thanks to the early detection and
resolution of vulnerabilities. Business risk, brand reputation damage, and fines
that could lead to economic disaster for a company are prevented.
SSDLC PROCESSES

4.DEVELOPMENT
1.PLANNING [Code Review]
[Risk Assessment]

5.TESTING
[Code Review]
3.DESIGN/
PROTOTYPE
[Threat Modeling]
2.ANALYSIS
[Risk Assessment]
6.DEPLOYMENT
[Secure Configuration]

[Security Assessment]
7.MAINTENANCE
RISK ASSESSMENT
▪ During the early stages of SDLC, it is essential to identify security
considerations that promote a security by design approach when functional
requirements are gathered in the planning and requirements stages.

▪ Risk refers to the likelihood of a threat being exploited, negatively

impacting a resource or the target it affects.

▪ For example, vulnerabilities being exploited after a new version of the

software is published, design flaws, and poorly reviewed code can increase the
risk of these scenarios.

▪ Risk management is an important pillar to integrate into the SDLC to mitigate

risk in a product or service.

▪ Risk assessment is used to determine the level of the potential threat. Risk
identified in the risk assessment process can be reduced or eliminated by
applying appropriate controls during the risk mitigation process.
PERFORMING RISK ASSESSMENT
▪ The first step in the risk assessment process is to assume the software will be attacked
and consider the factors that motivate the threat actor. List out the factors such as the
data value of the program, the security level of companies who provide resources that the
code depends on, the clients purchasing the software, and how big is the software
distributed (single, small workgroup or released worldwide).

▪ The next step is risk evaluation. Include factors like the worst-case scenario if the
attacker has successfully attacked the software. You can demonstrate the worst-case
scenario to executives and senior engineers by simulating a ransomware attack. Determine
the value of data to be stolen, valuable data such as the user's identity, credentials to
gain control of the endpoints on the network, and data or assets that pose a lower risk.

▪ Some attacks only affect one or two users, but the Denial of Service attack will affect
thousands of users when a server is attacked. Moreover, thousands of computers may be
infected by the spread of worms. The last factor is the accessibility of the target.
Determine whether the target accepts requests across a network or only local access,
whether authentication is needed for establishing a connection, or if anyone can send
requests.
TYPES OF RISK ASSESSMENT

QUALITATIVE RISK QUANTITATIVE RISK

ASSESSMENT ASSESSMENT

i.e. LOW [3.6]

THREAT MODELING
It is the process of identifying potential threats when there is a lack of
appropriate safeguards.

Threat modelling is best integrated into the design phase of an SDLC before any
code is written. Threat modelling is a structured process of identifying
potential security threats and prioritizing techniques to mitigate attacks so
that data or assets that have been classified as valuable or of higher risk
during risk assessment, such as confidential data, are protected.

Not all the methods have the same purpose; some focus on risk or privacy
concerns, while some are more customer-focused. It is essential to analyze which
way aligns more with the project or business.

STRIDE

DREAD

PASTA
THREAT MODELING - STRIDE
STRIDE is built upon the CIA triad principle (Confidentiality, Integrity &
Availability). Security professionals that perform STRIDE are looking to answer
"What could go wrong with this system".

SSDLC
Elevation of
Spoofing Privilege
Identity

Tampering Denial of
with Data Service

Repudiation Information
Disclosure
THREAT MODELING - DREAD
DREAD model also can be used in assessing, analyzing and finding the risk
probability by threat rating.

SSDLC
Discoverability

Damage

Affected Users

Reproducibility

Exploitability
THREAT MODELING - PASTA
PASTA involves the threat modelling process from analyzing threats to finding
ways to mitigate them, but on a more strategic level and from an attacker's
perspective.
QUESTIONS*

Q1. What threat modelling methodology assigns a rating system based on

risk probability?
DREAD

Q2. What threat modelling methodology is built upon the CIA triad?

STRIDE

Q3. What threat modelling methodology helps align technical requirements

with business objectives?
PASTA
CODE REVIEW
Code reviews can be either manual or automated.

Code Scanning or automated code reviews can leverage Static and Dynamic
Security testing technologies.

These are crucial in the Development stages as code is being written.

CODE REVIEW
Static analysis detects bugs at the implementation level, and dynamic
analysis detects errors during program runtime.

[Static Application Security Testing]

[Interactive Application Security Testing]

SAST
DAST IAST RASP
SCA

[Software Composition Analysis]

[Runtime Application Self Protection]
[Dynamic Application Security Testing]
CODE REVIEW
SAST uses a testing methodology of analyzing a source code to detect any
traces of vulnerabilities that could provide a backdoor for an attacker.
SAST usually analyses and scans an application before the code is
compiled.

SCA is used to scan dependencies for security vulnerabilities, helping

development teams track and analyze any open-source component brought into
a project. SCA is now an essential pillar in security testing as modern
applications are increasingly composed of open-source code.

DAST works by simulating automated attacks on an application, mimicking a

malicious attacker. The goal is to find unexpected outcomes or results
that attackers could use to compromise an application.

IAST testing occurs in real-time, just like DAST, while the application
runs in the staging environment. IAST can identify the line of code
causing security issues and quickly inform the developer for immediate
remediation. IAST checks the source code similar to SAST, but at the post-
build stage, unlike SAST, which occurs during development.
CODE REVIEW
RASP is deployed to a web or application server next to the main
application while running to monitor and analyze the inward and outward
traffic behavior. Immediately once an issue is found, RASP will send
alerts to the security team and immediately block access to the individual
making a request. When you deploy RASP, it will secure the whole
application against different attacks.
APPLICATION SECURITY TESTING TIMELINE

DEVELOPMENT INTEGRATION ACCEPTANCE PRE PRODUCTION PRODUCTION

• SAST • SCA • SAST • SAST • RASP
• SCA • DAST • DAST
• IAST
QUESTIONS*

Q1. Is it recommended to use SAST analysis at the beginning of the

SDLC?
YES

Q2. Which type of code analysis uses the black-box method?

DAST

Q3. Which type of code analysis uses the White-box method?

SAST
SECURITY ASSESSMENT
Like Penetration Testing & Vulnerability Assessments are a form of
automated testing that can identify critical paths of an application that
may lead to exploitation of a vulnerability.

However, these are hypothetical as the assessment doesn't carry

simulations of those attacks.

Pentesting, on the other hand, identifies these flaws and attempts to

exploit them to demonstrate validity.

Pentests and Vulnerability Assessments are carried out during the

Operations & Maintenance phase of the SDLC after a prototype of the
application.
SECURITY TESTING

SECURITY ASSESSMENT
Security testing
assesses a system, VULNERABILITY ASSESSMENT
software or web
application for Vulnerability
Assessments focus on PENETRATION TESTING
vulnerabilities and
other attack Finding Vulnerabilities,
but do not validate them It is extended by
vectors. testing/validating of
or simulate the findings
to prove they are vulnerabilities,
exploitable in reality. quantifying risks and
attempting to penetrate
systems.
OWASP
SSDLC
PHASE – 01 [BEFORE DEVELOPMENT]
1.1: Review Policies and Standards
Ensure that there are appropriate policies, standards, and documentation
in place. Documentation is extremely important as it gives development
teams guidelines and policies that they can follow.

1.2: Develop Measurement and Metrics Criteria and Ensure Traceability

Before development begins, plan the measurement program. By defining
criteria that need to be measured, it provides visibility into defects in
both the process and product. It is essential to define the metrics
before development begins, as there may be a need to modify the process
in order to capture the data.
PHASE – 02 [DEFINITION & DESIGN]
2.1: Review Security Requirements
Security requirements define how an application works from a security
perspective. It is essential that the security requirements are tested.
Testing in this case means testing the assumptions that are made in the
requirements and testing to see if there are gaps in the requirements
definitions.
When looking for requirements gaps, consider looking at security mechanisms
such as:

▪ User Management
▪ Authentication
▪ Authorization
▪ Data Confidentiality
▪ Integrity
▪ Accountability
▪ Session Management
▪ Transport Security
▪ Tiered System Segregation
▪ Legislative and standards compliance (including Privacy, Government and Industry
standards)
PHASE – 02 [DEFINITION & DESIGN]
2.2: Review Design and Architecture
Applications should have a documented design and architecture. This
documentation can include models, textual documents, and other similar
artifacts. Identifying security flaws in the design phase is not only one
of the most cost-efficient places to identify flaws, but can be one of
the most effective places to make changes.

2.3: Create and Review UML Models

Once the design and architecture is complete, build Unified Modeling
Language (UML) models that describe how the application works. If
weaknesses are discovered, they should be given to the system architect
for alternative approaches.
PHASE – 02 [DEFINITION & DESIGN]
2.4: Create and Review Threat Models
Having design and architecture reviews and the UML models explaining
exactly how the system works, undertake a threat modeling exercise.

Develop realistic threat scenarios, Analyze the design and architecture

to ensure that these threats have been mitigated.

When identified threats have no mitigation strategies, revisit the design

and architecture with the systems architect to modify the design.
PHASE – 03 [DURING DEVELOPMENT]
3.1: Code Walk Through
Security team should perform a code walk through with the developers, and
in some cases, the system architects. A code walk through is a high-level
walk through of the code where the developers can explain the logic and
flow of the implemented code. The purpose is not to perform a code
review, but to understand at a high level the flow, the layout, and the
structure of the code that makes up the application.

3.2: Code Reviews

Having a good understanding of how the code is structured and why certain
things were coded the way they were, the tester can now examine the
actual code for security defects.
PHASE – 03 [DURING DEVELOPMENT]
3.2: Code Reviews - Continue

Static code reviews validate the code against a set of checklists,

including:

▪ Business requirements for availability, confidentiality, and integrity.

▪ OWASP Guide or Top 10 Checklists for technical exposures (depending on the

depth of the review).

▪ Specific issues relating to the language or framework in use, such as the

Scarlet paper for PHP or Microsoft Secure Coding checklists for ASP.NET.
PHASE – 04 [DURING DEPLOYMENT]
4.1: Application Penetration Testing

Having tested the requirements, analyzed the design, and performed code
review, it might be assumed that all issues have been caught. Hopefully
this is the case, but penetration testing the application after it has
been deployed provides a last check to ensure that nothing has been
missed.

4.2: Configuration Management Testing

The application penetration test should include the checking of how the
infrastructure was deployed and secured. While the application may be
secure, a small aspect of the configuration could still be at a default
install stage and vulnerable to exploitation.
PHASE – 05 [MAINTENANCE & OPERATIONS]
5.1: Conduct Operational Management Reviews

There needs to be a process in place which details how the operational

side of both the application and infrastructure is managed.

5.2: Conduct Periodic Health Checks

Monthly or quarterly health checks should be performed on both the

application and infrastructure to ensure no new security risks have been
introduced and that the level of security is still intact.

5.3: Ensure Change Verification

After every change has been approved and tested in the QA environment and
deployed into the production environment, it is vital that the change is
checked to ensure that the level of security has not been affected by the
change. This should be integrated into the change management process.
DISCUSSION
THANK YOU!