Software Security Testing:

An introduction
Nouredine TAMANI ([email protected])

09/11/2023
Objectives

01 02 03
Identify Vulnerabilities Identify and apply security Understand and apply the
related to source code, controls in development following concepts:
external code, etc. environments • Security Requirements Testing
• Software Composition Analysis (SCA)
• Static Application Security Testing
(SAST)
• Dynamic Application Security Testing
(DAST)

13/11/2023 2
 Security Objectives: CIA-
DAD Triad
Confidentiality
/ Disclosure

• Security controls are evaluated on how well they address IS Security

these 3 core information security tenets
• Vulnerabilities and risks are also evaluated based on the
threat they pose against one or more of the CIA Triad
principles Integrity / Availability /
Alteration Denial
• Symmetrical concepts: DAD for Disclosure, Alteration,
Destruction
Figure 1. Information security with CIA/DAD triangle
13/11/2023 3
 CIA: Confidentiality – definition

• Confidentiality ensures the protection of the secrecy of data,

objects, or resources
• Only authorized users to access and interact with resources,
• But it also prevents unauthorized users from doing so =>
disclosure

13/11/2023 4
 • Attacks on confidentiality:
• capturing network traffic and stealing password files, social engineering, port
scanning, shoulder surfing, eavesdropping, sniffing, escalation of privileges,

CIA: etc.
• Unauthorized disclosure of sensitive data can be the result of human error,
Confidentiality – oversight, or ineptitude

risks and • Events that lead to confidentiality breaches:

• Failing to properly encrypt and/or authenticate a remote system before
countermeasures transferring data,
• Leaving open otherwise secured access points,
• Accessing malicious code that opens a back door,
• Actions of an end user or a system administrator,
• An oversight in a security policy or a misconfigured security control.

13/11/2023 5
 Sensitivity

Isolation Discretion

CIA:
Confidentiality
– related Seclusion Criticality

concepts Confidentiality

Concealm
Privacy ent

Security
Secrecy through
obscurity
13/11/2023 6
 • Integrity is protecting the reliability and correctness of data
• It prevents unauthorized alterations of data
• Confidentiality and integrity depend on each other:
• Without object integrity confidentiality cannot be maintained
CIA: Integrity – • Integrity can be examined from 3 perspectives:
definition • Preventing unauthorized subjects from making modifications
• Preventing authorized subjects from making unauthorized modifications,
such as mistakes
• Maintaining the internal and external consistency of objects

13/11/2023 7
 • Numerous attacks focus on the violation of integrity:
• Viruses, logic bombs, unauthorized access, errors in coding and
applications, malicious modification, intentional replacement,
and system back doors.
• As with confidentiality, human error, oversight, or ineptitude
CIA: Integrity – • Events that lead to integrity breaches:
risks and • Modifying or deleting files
countermeasures • Entering invalid data
• Altering configurations
• Including errors in commands, codes, and scripts
• Introducing a virus
• Executing malicious code such as a Trojan horse

13/11/2023 8
 Accuracy

Comprehe Truthful-
nsiveness ness

CIA: Integrity –
Comple- Authen-
related teness ticity

concepts Integrity

Responsi-
bility Validity

Accounta- Nonrepu-
bility diation
13/11/2023 9
 • Availability: authorized subjects (user, software, etc.) are
granted timely and uninterrupted access to objects
• Requirements to maintain Availability on a system:
• Controls to ensure authorized access,
CIA: Availability – • An acceptable level of performance,

definition • Quickly handle interruptions,

• Provide for redundancy,
• Maintain reliable backups,
• Prevent data loss or destruction.

13/11/2023 10
 • Events that lead to Availability interruptions:
• Device failure => Destruction,
• Software errors,
• DoS attacks,
CIA: Availability – •
•
Object destruction,
Communication interruptions.
risks and • Events caused by human error, oversight, or ineptitude:
countermeasures • Human intervention,
• Overutilizing a hardware or software component,
• Under-allocating resources and mislabeling or incorrectly classifying
objects
• Etc.

13/11/2023 11
 • Availability depends on both integrity and confidentiality:
• Without integrity and confidentiality, availability cannot be maintained

Usability

CIA: Availability –
related concepts
Availability

Timeliness Accessibility

13/11/2023 12
 • Concept AAA: authentication, authorization, and accounting
• Refers to 5 elements: identification, authentication, authorization,
auditing, and accounting :
• Identification: Claiming to be an identity when attempting to access
a secured area or system
• Authentication: Proving that you are that identity
Other security • Authorization: Defining the permissions (i.e., allow/grant and/or
deny) of a resource and object access for a specific identity
concepts: AAA • Auditing: Recording a log of the events and activities related to the
system and subjects
• Accounting (aka accountability): Reviewing log files to check for
compliance and violations in order to hold subjects accountable for
their actions

13/11/2023 13
 Other security concepts: AAA

• Although AAA is typically referenced in relation to

authentication systems, it is a foundational concept
for security
• Missing any of these five elements can result in an Figure 2. The five elements of AAA services.
incomplete security mechanism

13/11/2023 14
 • Identification is the process by which a subject professes an identity
• A subject must provide an identity to a system to start the AAA process
• Typing in a username
• Swiping a smart card
• Waving a proximity device
• Speaking a phrase
• Positioning your face, hand, or finger for a camera or scanning device
• Without an identity, a system has no way to correlate an authentication
I4A: Identification factor with the subject
• A subject’s identity is typically labeled as public information
• The identity must be proven (authentication) or verified (ensuring
nonrepudiation) before access to controlled resources is allowed
(verifying authorization)

13/11/2023 15
 • Authentication: the process of verifying that the claimed identity is valid
• The most common form of authentication is using a password
à this includes the password variations of personal identification numbers (PINs) and
passphrases.
• Insecure authentication system: If the process of illegitimately obtaining and using
the authentication factor of a target user is relatively easy
• If that process is relatively difficult, then the authentication system is reasonably
secure.
• Identification and authentication are often used together as a single two-step
I4A: Authentication process
• A subject can provide several types of authentication:
• Something you know (e.g., passwords, PINs),
• Something you have (e.g., keys, tokens, smart cards),
• Something you are (e.g., biometrics, such as fingerprints, iris, or voice recognition),…

13/11/2023 16
 • Authorization ensures that the requested activity or access to an object is possible
given the rights and privileges assigned to the authenticated identity
• Once a subject is authenticated, access must be authorized
• In most cases, the system evaluates an access control matrix that compares the
subject, the object, and the intended activity
• If the specific action is allowed, the subject is authorized
• If the specific action is not allowed, the subject is not authorized
• Authorization has a wide range of variations between all or nothing:
• A user may be able to read a file but not delete it,
I4A: Authorization • print a document but not alter the print queue,
• log on to a system but not access any resources.

• Authorization is usually defined using one of the models of access control:

• Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role Based Access
Control (RBAC or role-BAC).

13/11/2023 17
 • Auditing, or monitoring, is the programmatic means by which a subject’s actions
are tracked and recorded
• It is also the process by which unauthorized or abnormal activities are detected on
a system
• System crashes may indicate faulty programs, corrupt drivers, or intrusion attempts
• The event logs leading up to a crash can often be used to discover the reason a
system failed
• Log files provide an audit trail for re-creating the history of an event, intrusion, or
system failure
I4A: Auditing
• Monitoring is a type of watching, while auditing is a recording of the information
into a record or file
• It is possible to monitor without auditing:
• but we can’t audit without some form of monitoring,
• still, these terms are often used interchangeably is some scientific literature

13/11/2023 18
 • Effective accountability relies on the ability to prove a subject’s identity and track
their activities
• Accountability is established by linking a human to activities:
• Online identity through the security services and mechanisms of auditing,
authorization, authentication, and identification

I4A: Accountability • Human accountability ultimately dependents on the strength of the authentication
process

13/11/2023 19
 Security, user-friendliness
and functionality • Security often disabled in order to facilitate the
installation and use of the software
• IT administrator are often responsible for enabling and
configuring security
• Maintaining security is a trade-off between usability and
functionality:
• Example: Windows VISTA Failure
• The more security added, the more admin costs added,
and productivity reduced

13/11/2023 20
 Controls in the development cycle

• Security must be considered at every stage of a system's development

• Programmers should strive to integrate security into every application
they develop
• Higher levels of security to consider for critical applications and for those
that handle sensitive information
• It's much easier to integrate security into a system than to add
security to an existing system
• Programming languages: ANSSI recommendations

13/11/2023 21
 Systems Development
Lifecycle • Security is most effective if it is planned and managed
throughout the software lifecycle
• Software project management is structured using
lifecycle models: the development process
• The use of formalized lifecycle models ensures:
• Good coding practices
• Integrating security at every stage of product
development
• All systems development processes have several so-
called core activities in common

13/11/2023 22
 Conceptual
Definition

Maintenance and
Functional
change
requirements
management

Software Basic activities

Development (can be named
differently) control
Life Cycle (SDLC) System tests specification
design

code review Design review

13/11/2023 23
 Development
cycle security
controls

https://cloudsecurityalliance.org : The-Six-Pillars-of-DevSecOps-Automation-SafeCode.pdf 24
13/11/2023
 SDLC: Code Review • Code implementation comes after stakeholders agree
Guide on software design
• Project managers should schedule multiple code review
meetings at different milestones of the coding process
• These technical meetings:
• Usually involve only developers,
• Require a copy of the code for a specific module,
• Aim to snoop through the code for logical flow issues or
other design/security flaws.
• Role: Check if the code produced works according to
specifications

13/11/2023 25
 Software Testing Types

• Unit Testing • Performance • Regression

• Integration • Endurance • Maintenance
Testing • Load
• +150 types of testing: • Smoke • Volume
• https://www.guru99.com/types-of-software-testing.html • UAT (User • Scalability
Acceptance
• Not all testing types are applicable to all projects but depend Testing) • Usability
on the nature & scope of the project • …
• Localization
• Globalization
• Interoperability
• …

26
13/11/2023 https://www.guru99.com/images/2/061920_1310_Whatissoftwaretesting1.png
 Testing Strategies in Software Engineering
• Unit Testing
• Basic approach followed by the programmer to test the unit of the program
• It helps developers know whether the individual unit of the code is working properly or not

• Integration testing
• It focuses on the construction and design of the software
• Checks if the integrated units are working without errors or not

• System testing
• A software is compiled as a whole and then tested as a whole
• It checks the functionality, security, portability, amongst others

• Program Testing
• Executing an actual software program with the aim at testing program behavior and finding errors
• The software is executed with test case data to analyze the program behavior/response to test data
• A good program testing is one which has high chances of finding bugs

13/11/2023 27
Software
Testing

13/11/2023 https://www.simform.com/blog/functional-testing-types/ 28
 Static tests vs Dynamic tests
• Static tests
• Static tests evaluate the security of the software without running it by analyzing the
source code or compiled application
• Static analysis involves the use of automated tools designed to detect common
software defects, such as buffer overflows
• Dynamic testing
• Evaluates software security in a runtime environment
• The only option for organizations deploying "out-sourced" applications
• Testers often don't have access to the underlying source code

13/11/2023 29
 Static tests vs Dynamic testing

• Example of dynamic software testing is the use of web application analysis tools to detect:
• The presence of cross-site scripts,
• SQL injections,
• Other flaws.

• Dynamic "in-production" tests must always be well coordinated to avoid an unintentional

interruption of service
• Many of the common errors and oversights often found in commercial and in-house software can
be eliminated
• It is important to keep the test plan and results as part of the ongoing system documentation

13/11/2023 30
 Dynamic Testing
• Testing is verification and validation (2Vs):
• Verification is called a Static testing
• Validation is known as Dynamic testing
• Dynamic Testing: to test the dynamic behavior of software code
• Objectives:
• Test software behavior with dynamic variables or variables which are not constant
• Finding weak areas in software runtime environment
• The code must be executed in order to test the dynamic behavior

13/11/2023 31
Types de
dynamic
Testing

13/11/2023 32
 Dynamic Testing: Example
• Testing a Login Page with two fields: “Username” and “Password” and the
Username is restricted to Alphanumeric
• When the user enters Username as “Guru99”, the system accepts the name
• When the user enters as Guru99@123 then the application throws an error message
àThe code is acting dynamically based on the user input
• Dynamic testing means working with the system with the intent of finding errors

13/11/2023 33
 Dynamic Testing: Advantages & Disadvantages
• Advantages
• It can reveal the uncovered defects that are too difficult or complicated to be covered
through static Analysis
• The execution of the software end-to-end ensures error free software which in turn increases
the quality of a product and project
• Disadvantages
• It is time consuming because it executes the application/software or code, which requires
huge amount of resources
• It increases the cost of project/product because it does not start early in the software lifecycle

13/11/2023 34
 Dynamic Testing: 3 software testing methods

White-Box Testing

Black-Box Testing

Gray-Box Testing

13/11/2023 35
 “White-box testing
examines the internal
logical structures of a
program in stages
through line-by-line
code, analyzing the
program for potential
errors”

Dynamic Testing: White-Box testing

13/11/2023 36
 “Black-box testing examines the program from
the user's perspective by providing a wide
variety of input scenarios and inspecting the
output”
• Black box testers do not have access to the
internal code
• Example of black box testing: acceptance
testing that takes place before the system is
delivered

13/11/2023 37
 Gray-Box testing
• The grey box test combines both approaches:
black & white
• Very popular for software validation
• Testers examine the software by putting
themselves in the user's shoes
• They have access to the source code and use it
to design their tests
• However, they do not analyze the inner
workings of the program during their tests

13/11/2023 38
 Software Testing and Security

• Programmers and security professionals should evaluate software security:

• To ensure that it meets the security requirements of the organization
• Vital for web applications that are exposed to the public
• There are two categories of tests used specifically to assess application security:
• Static tests
• Dynamic testing

13/11/2023 39
 Security Testing
• Security Testing is a type of Software Testing:
• Uncovers vulnerabilities, threats, risks in a software application
• Prevents malicious attacks from intruders
• Identifies all possible loopholes and weaknesses, which might cause loss of information,
revenue, etc.
• Goal: identify threats in the system and measure their potential vulnerabilities
• The threats can be encountered
• The system does not stop functioning
• Vulnerabilities cannot be exploited

13/11/2023 40
 • Vulnerability Scanning:
• This is done through automated software to • Security Auditing:
scan a system against known vulnerability
• Internal inspection of
signatures
Applications and Operating

Security Testing: • Security Scanning:

• It can be both Manual and Automated
systems for security flaws
• Can be done via line-by-line
Types • Identifying network and system weaknesses inspection of code
• Provides solutions for reducing these risks • Ethical hacking:
• Penetration testing: • Hacking an Organization
Software systems
• Simulates an attack from a malicious hacker
• Unlike malicious hackers, the
• Involves analysis of a particular system to intent is to expose security
check for potential vulnerabilities to an flaws in the system
external hacking attempt
• Posture Assessment:
• Risk Assessment:
• Combines Security
• Involves analysis of security risks observed in scanning, Ethical Hacking and
the organization Risk Assessments to show an
• Risks are classified as Low, Medium and High overall security posture of an
• Recommends controls and measures to organization
reduce the risk
13/11/2023 41
Security Requirements Testing
An introduction
 Security Test Requirements
• Security requirements: Testing Objectives
• Requirements for security testing can be derived from:
• Applicable standards and regulations
• Positive and negative application requirements
• Testing Objectives:
• Validate that security controls operate as expected
• Via ''security requirements'' that describe the functionality of the security control
• At a high level: proving confidentiality, integrity, and availability of both the data and the service
• Validate that security controls are implemented with few or no vulnerabilities
• Common vulnerabilities (OWASP Top Ten)
• Vulnerabilities identified with security assessments: threat modelling, source code analysis, and
penetration test.

13/11/2023 43
 Security Requirements Documentation
• ’’Business requirements’’: basis of the documentation of security requirements
• Initial high-level information on the expected functionality of the application
• Example:
• Provide financial services to customers or to allow goods to be purchased from an on-line catalog
• A security section should highlight the need:
• To protect the customer data
• To comply with applicable security documentation such as regulations, standards, and policies

13/11/2023 44
 Security Requirements Documentation
• Preliminary security compliance analysis for web applications:
• A checklist of the applicable regulations, standards, and policies.
• Translate compliance guidelines and regulations into specific technical requirements for
security controls
• Example: the case of financial applications
• Compliance with FFIEC guidelines for authentication
• For credit card data à PCI DSS standard is mandatory

13/11/2023 45
 Security Requirements Documentation
• Mapping to a specific section of information security standards:
• "a password complexity of 8 alphanumerical characters must be enforced by the
authentication controls used by the application."
• Role: documenting Risks
• Any violation of information security standards and policies
• Objective: validation and enforcing security compliance requirements

13/11/2023 46
 Security Requirements Validation
• High level:
• Identification of gaps in security controls: lack of basic authentication, authorization, or encryption controls
• In depth:
• Risk analysis: identification of potential weaknesses in security controls that ensure the CIA of the data.
• Example: dealing with personal identifiable information (PII) and sensitive data
• Security requirement: data encryption in transit and in storage
è Encryption algorithms and key lengths need to comply with the organization encryption standards
è Only certain algorithms and key lengths could be used (SHA-256, RSA, AES, etc.)
è Allowed minimum key lengths: +128 bit for symmetric and +1024 for asymmetric encryption

13/11/2023 47
 Security Requirements Validation

• Validation at different SDLC’s phases by using:

• Threat modeling: identifying security flaws during the design,
• Secure code analysis and reviews: identifying security issues in source code during the development,
• Penetration testing: identifying vulnerabilities in the application during testing or validation.
• Test plan: contains identified security issues early in the SDLC to be validated later with security tests
• To derive better security test cases: combining the results of different testing techniques

13/11/2023 48
 Security Requirements Validation

• Example: Security test for a SQL injection vulnerability

• A black box test might first involve a scan of the application to fingerprint the vulnerability
• Generation of an SQL exception: is an evidence of a potential SQL injection vulnerability
• Manually injecting attack vectors to modify the grammar of the SQL query for an information
disclosure exploit
• If the tester has the source code, they might learn how to construct the SQL attack vector that
can exploit the vulnerability

13/11/2023 49
 Threats and Countermeasures Taxonomies
• In the case of web applications:
• OWASP Top 10
• Attacks such as phishing, privacy violations, identify theft, system compromise, data alteration or data
destruction, financial loss, and reputation loss.
• A threat can be categorized by using STRIDE:
• Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation (Escalation) of
privilege.
• The root cause can be categorized as:
• A security flaw in design,
• A security bug in coding,
• An issue due to insecure configuration.
• Threats and vulnerabilities è a battery of tests that simulate such attack scenarios

13/11/2023 50
 Security Testing and Risk Analysis
• Risk mitigation strategy: considering the severity of the vulnerabilities
• Determine the likelihood and exposure of the vulnerability
• Calculate the risk rating of the vulnerability
• Combining the results of source code analysis and penetration testing
• Mitigation strategy : based on vulnerability risk ratings test reports
• Example:
• High and medium risk vulnerabilities can be prioritized for remediation
• Low risk can be fixed in further releases

13/11/2023 51
 Deriving Functional and Non-Functional Test Requirements

• Functional Security Requirements

• Applicable standards, policies and regulations
• Referred to as “positive requirements”
• State the expected functionality that can be validated through security tests
• Examples:
• “the application will lockout the user after six failed log on attempts”
• “passwords need to be a minimum of 8 alphanumerical characters”
• Validation of positive requirements:
• Asserting the expected functionality
• Re-creating the testing conditions
• Running the test according to predefined inputs
• The results are then shown as as a fail or pass condition

13/11/2023 52
 1. Protect user credentials and shared secrets in transit and in storage

Deriving 2. Mask any confidential data in display (e.g., passwords, accounts)

3. Lock the user account after a certain number of failed log in attempts
Functional Test 4. Do not show specific validation errors to the user because of a failed log on
Requirements: 5. Only allow passwords that are alphanumeric, include special characters and 8
characters minimum length, to limit the attack surface
Authentication 6. Allow for password change functionality only to authenticated users by
Example validating the old password, the new password, and the user answer to the
challenge question, to prevent brute forcing of a password via password change
7. The password reset form should validate the user’s username and the user’s
registered email before sending the temporary password to the user via email
8. The temporary password issued should be a one-time password
9. A link to the password reset web page will be sent to the user
10. The password reset web page should validate the user temporary password, the
new password, as well as the user answer to the challenge question

13/11/2023 53
 Risk Driven Security Requirements
• Risk driven Security tests: validate the application for unexpected behavior
• “Negative requirements”: since they specify what the application should not do
• Examples:
• The application should not allow for the data to be altered or destroyed
• The application should not be compromised or misused for unauthorized financial transactions by a
malicious user
• Negative requirements are more difficult to test:
• No expected behavior to look for
• It might require a threat analyst to produce unforeseeable input conditions, causes, and effects
• The key: documenting threat scenarios and the functionality of the countermeasure

13/11/2023 54
 Risk Driven Security Requirements
• Example: security requirements for authentication controls (from the threats and
countermeasure perspective):
• Encrypt authentication data in storage and transit to mitigate risk of information disclosure and
authentication protocol attacks
• Encrypt passwords using non-reversible encryption such as using a digest (e.g., HASH) and a seed to
prevent dictionary attacks
• Lock out accounts after reaching a log on failure threshold and enforce password complexity to mitigate
risk of brute force password attacks
• Display generic error messages upon validation of credentials to mitigate risk of account harvesting or
enumeration
• Mutually authenticate client and server to prevent non-repudiation and Man In the Middle attacks

13/11/2023 55
 Deriving Security Test Requirements:
Use and Misuse Cases
• ''use cases’’: describing the application functionality
• They show the interactions of actors and their relations
• Like use cases, ''misuse and abuse cases'' describe unintended and malicious use scenarios
of the application:
• How an attacker could misuse and abuse the application
• Allow the analysis of the application from the attacker's point of view
• Identifying potential vulnerabilities and the countermeasures that need to be implemented
• The key is to describe all possible or, at least, the most critical use and misuse scenarios

13/11/2023 56
Security Test Requirements: Use and Misuse Cases

• Example: derivation of security requirements for authentication:

• Step 1: Describe the Functional Scenario
• User authenticates by supplying a username and password
• The application grants access to users based upon authentication of user credentials by the application
• It provides specific errors to the user when validation fails
• Step 2: Describe the Negative Scenario:
• Attacker breaks the authentication through a brute force or dictionary attack of passwords and account
harvesting vulnerabilities in the application
• The validation errors provide specific information to an attacker to guess which accounts are valid registered
accounts (usernames)
• Then the attacker will try to brute force the password for such a valid account
• A brute force attack to four minimum length all digit passwords can succeed with a limited number of attempts

13/11/2023 57
Security Test Requirements: Use and Misuse Cases

• Example: derivation of security requirements for authentication:

• Step 3: Describe Functional and Negative Scenarios With Use and Misuse Case
• The functional scenario = user actions (entering a username and password) + the application actions
(authenticating the user and providing an error message if validation fails).
• The misuse case = attacker actions (trying to break authentication by brute forcing the password via a
dictionary attack and by guessing the valid usernames from error messages).
• Step 4: Elicit The Security Requirements
• The following security requirements for authentication are derived:
1) Passwords need to be alphanumeric, lower and upper case and minimum of seven-character length
2) Accounts need to lockout after five unsuccessful log in attempt
3) Log in error messages need to be generic
• These security requirements need to be documented and tested.
13/11/2023 58
Security Test
Requirements:
Use and Misuse Cases

13/11/2023 59
 OWASP: Generic security test suite

• It may include security test cases to validate both positive and negative requirements for security controls:
• Identity, Authentication & Access Control
• Input Validation & Encoding
• Encryption
• User and Session Management
• Error and Exception Handling
• Auditing and Logging

13/11/2023 60
 Test Plan
• Security-related test cases or scenarios
• Test Data related to security testing
• Test Tools required for security testing
• Analysis of various tests outputs from different security tools
• Example Test Scenarios for Security Testing:
• A password should be in encrypted format
• Application or System should not allow invalid users
• Check cookies and session time for application
• For financial sites, the Browser back button should not work

13/11/2023 61
 Test Plan: Security Testing Roles

• Security Testing Roles:

• Hackers – Access computer system or network without authorization
• Crackers – Break into the systems to steal or destroy data
• Ethical Hacker – Performs most of the breaking activities but with permission from the owner
• Script Kiddies or packet monkeys – Inexperienced Hackers with programming language skill

13/11/2023 62
 Security Testing Tools
• Intruder
• Intruder is an enterprise-grade vulnerability scanner that is easy to use
• It runs over 10,000 high-quality security checks across an IT infrastructure:
• configuration weaknesses,
• application weaknesses (such as SQL injection & cross-site scripting) and missing patches.
• Providing intelligently prioritized results and proactive scans for the latest threats

• OWASP (Open Web Application Security Project)

• OWASP is a worldwide non-profit organization focused on improving the security of software
• The project has multiple tools to pen-test various software environments and protocols.
• Flagship tools of the project include:
• Zed Attack Proxy (ZAP – an integrated penetration testing tool)
• OWASP Dependency Check (it scans for project dependencies and checks against know vulnerabilities)
• OWASP Web Testing Environment Project (collection of security tools and documentation)

13/11/2023 63
Security Testing Tools
• Acunetix
• Acunetix (by Invicti) helps small to medium-sized organizations ensure their web applications are secure from
costly data breaches
• It detects a wide range of web security issues and helping security and development professionals act fast to
resolve them
• Features:
• Advanced scanning for 7,000+ web vulnerabilities, including OWASP Top 10 such as SQLi and XSS
• Automated web asset discovery for identifying abandoned or forgotten websites
• Advanced crawler for the most complex web applications, incl. multi-form and password-protected areas
• Combined interactive and dynamic application security testing to discover vulnerabilities other tools miss
• Proof of exploit provided for many types of vulnerabilities
• DevOps automation through integrations with popular issue tracking and CI/CD tools
• Compliance reporting for regulatory standards, such as PCI DSS, NIST, HIPAA, ISO 27001, and more

13/11/2023 64
Security Testing Tools
• WireShark
• A network analysis tool previously known as Ethereal: network packet analyzer
• It captures packet in real time and display them in human readable format
• It is open source and can be used on Linux, Windows, OS X, Solaris, NetBSD, FreeBSD and many other systems
• The information that is retrieved via this tool can be viewed through a GUI or the TTY mode TShark Utility

• W3af
• A web application attack and audit framework
• It has three types of plugins; discovery, audit and attack
• They communicate with each other for any vulnerabilities in site
• Example: a discovery plugin looks for different URLs to test for vulnerabilities and forward it to the audit plugin
which then uses these URLs to search for vulnerabilities

13/11/2023 65
 • A segment of the application security testing (AST) tool market that deals

Software with managing open-source component use

• SCA tools perform automated scans of an application’s code base:
Composition • Identify all open-source components, their license compliance data, and any
Analysis (SCA) security vulnerabilities
• Identify what open-source libraries have known vulnerabilities
• Tell whether the software code calls the affected library
• Suggest a fix when applicable

• Some SCA tools also help:

• Fix open-source vulnerabilities through prioritization and auto remediation
• Identify open-source libraries in the code base that need to be updated or
patched

13/11/2023 66
 Software
Composition
Analysis (SCA)

13/11/2023 67
 • Around 2002, the first open-source manual scanner was released
Software • A high rate of false positives è manual intervention to resolve

Composition • They didn’t meet the needs of agile development environments

• By 2011, the technology is capable of automatically detecting
Analysis (SCA) vulnerabilities and licensing issues in real time
• This enabled software and security teams to shift
left (https://www.whitesourcesoftware.com/resources/blog/shift-left-testing)
their open-source management
• At the same time, SCA solutions were also being integrated with software
development tools:
• Repositories, build tools, package managers, and CI servers
• Despite these advancements, SCA was still heavily focused on detection

13/11/2023 68
 • Static Application Security Testing (SAST) is an AppSec tool, which scans
Static an application’s source, binary, or byte code

Application • It identifies the root cause of vulnerabilities and helps remediate the
underlying security flaws
Security • SAST solutions analyze an application from the “inside out” and do not reed
a running system to perform a scan
Testing (SAST) • It helps educate developers about security while they work:
• Providing them with real-time access to recommendations and line-of-code
navigation
• This enables developers to create more code that is less vulnerable to
compromise
• SAST tools are not capable of identifying vulnerabilities outside the code:
• Vulnerabilities found in a third-party API
• It requires Dynamic Application Security Testing (DAST)

13/11/2023 69
 Static Application Security Testing (SAST)

• Pros of SAST
• Scans source code to find weaknesses that lead to vulnerabilities
• Provides real-time reporting
• Cover languages that developers use:
• ABAP/BSP, ActionScript, Apex, ASP.NET, C# (.NET), C/C++, Classic, ASP
(VBScript), COBOL, ColdFusion CFML, Go, HTML, Java (including Android),
JavaScript/AJAX, JSP, Kotlin, MXML (Flex), Objective C/C++, PHP, PL/SQL,
Python, Ruby, Swift, T-SQL, VB.NET, VBScript, Visual Basic, and XML
• Cons of SAST
• Not capable of identifying vulnerabilities in dynamic environments
• High risk of reporting false positives
• Since the report is static, it becomes outdated quickly

13/11/2023 70
 Dynamic Application Security Testing (DAST)

• Dynamic Application Security Testing (DAST) is the process of analyzing an application through
the front-end to find vulnerabilities through simulated attacks
• It evaluates the application from the “outside in” by attacking an application
• It looks for not expected results set and identifies security vulnerabilities

13/11/2023 71
 Dynamic Application Security Testing (DAST)

• Pros of DAST
• Independent of the application
• Immediately finds vulnerabilities that could be exploited
• Does not require access to the source code
• Cons of DAST
• Does not find the exact location of a vulnerability in the code
• Security knowledge is needed to interpret reports
• Test can be time-consuming

13/11/2023 72
 Non-Functional Security Requirements

• Non-functional security requirements specify a security quality or attribute that the software
must possess
• 3 types of non-functional security requirements:
• Security Property Requirements
• Constraint/Negative Requirements
• Security Assurance Requirements

13/11/2023 73
 Non-Functional Security Requirements:
Security Property Requirements

• Specify the properties that software must exhibit

• Examples:
• The software must remain resilient in the face of attacks
• The behavior of the software must be correct and predictable
• The software must be available and behave reliably even under DOS attacks
• The software must ensure the integrity of the customer account information

13/11/2023 74
 Non-Functional Security Requirements:
Constraint/Negative Requirements
• Constraint/Negative requirements = things to be avoided or prevented
• Things that could lead to software failing in an insecure state or becoming vulnerable to exploitation or
compromise

• They place constraints on software functions to minimize the likelihood of non-secure behaviors
• Examples:
• The server must not return a restricted web page to any browser that it cannot authenticate
• The server must not return a restricted web page to a user who is not authorized to access it
• The software must not accept overlong input data
• The application must not accept invalid URLs

13/11/2023 75
 Non-Functional Security Requirements:
Security Assurance Requirements

• Rules, best practices, and processes by which the software security functions will be built, deployed, and
operated
• They will not be translated into elements of the software’s design
• Translated into standards, guidelines, or procedures
• Examples:
• The software must be built following RESTFULL web service security standards
• The development processes must comply with SSE-CMM capability level 3 or above

13/11/2023 76
Part II
Lab
Lab: Exercise 1 –
Finding Defects

1. Find out defects on the page shown aside.

2. Identify among the defects, those
undermining software security

13/11/2023 78
Lab: Exercise 2 –
Finding Defects

• Providing suggestions to improve quality or user experience is the extension of a Software Testing job.

13/11/2023 79
 Further readings
• https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Testing_Guide_v4.pdf
• https://cyberhoot.com/cybrary/white-box-testing/
• https://www.kiwiqa.com/black-box-testing-techniques-for-security-your-guide/
• https://www.coresentinel.com/black-box-vs-white-box-testing/
• https://www.guru99.com/what-is-security-testing.html
• https://www.microfocus.com/en-us/what-is/dast
• https://www.microfocus.com/en-us/what-is/sast
• https://sites.google.com/site/jimmyxu101/requirements/categories-of-security-requirement

13/11/2023 83