System Testing cont…
Dr. Durga Prasad Mohapatra
Professor, Dept. of CSE,
NIT Rourkela
SECURITY TESTING
Software Problem
# vulnerabilities Reported by CERT/CC
• More than half of the vulnerabilities are due to
buffer overruns.
• Others such as race conditions, design flaws are
equally prevalent.
Software security
It is about
Understanding software-induced security risks and how
to manage them
Leveraging software engineering practice,
Thinking security early in the software lifecycle
Knowing and understanding common problems
Designing for security
Subjecting all software artifacts to thorough objective
risk analyses and testing
It is a knowledge intensive field
Software Security
Renewed interest
“idea of engineering software so that it continues to
function correctly under malicious attack”
Existing software is riddled with design flaws and
implementation bugs
“any program, no matter how innocuous it seems, can
harbor security holes”
Security Testing
• Security is a protection system that is needed to assure
the customers that their data will be protected.
• For example, internet users feel that their personal data/
information is not secure, the system loses its accountability.
• Security may include controlling access to data, encrypting
data in communication, ensuring secrecy of stored data,
auditing security events, etc.
• Security breaches can result in loss of information, privacy
violations, denial of service, etc.
Types of Security Requirements
• While performing security testing, the following
security requirements must be considered:
• Security requirements should be associated with
each functional requirement.
• Each functional requirement, most likely, has a specific set
of related security issues to be addressed in the software
implementation.
• For example, the log on requirement in a client server
system must specify the number of retries allowed, the
action to be taken if the log-on fails, and so on.
Example of Security Concerns
• In addition to the security concerns that are directly
related to particular requirements, a software project has
security issues that are global in nature, and hence
related to the application’s architecture and overall
implementation.
• For example, a web application may have a global requirement
that all private customer data of any kind is stored in encrypted
form in the database.
• In another example, a system wide security requirement is to
use SSL to encrypt the data sent between the client browser
and the web server - the testing team should verify the
correctness of SSL.
Security Concerns cont…
• The problem with security testing is that
security-related bugs are not as obvious as other
types of bugs.
• It may be possible that the security system has
failed and caused the loss of information without
the knowledge of loss.
• Thus, the tester should perform security testing
with the goals to identify the bugs that are very
difficult to identify.
Software Vulnerability
• Vulnerability is an error that an attacker can exploit.
• Security vulnerabilities are of the following types:
• Bugs at the implementation level, such as local
implementation errors or inter-procedural interface
errors.
• Design level mistakes.
• Design level vulnerabilities are the hardest defect
category to handle, but they are also the most
prevalent and critical.
Software Vulnerability cont…
• Unfortunately, ascertaining whether a program has
design level vulnerabilities requires great expertise
• which makes finding not only difficult but particularly hard
to automate.
• Examples: problem in error handling, unprotected data
channels, incorrect or missing access control
mechanisms, and timing errors especially in
multithreaded systems.
How to Perform Security Testing
• Testers must use a risk based approach, grounded in
both the system’s architectural reality and the attacker’s
mindset,
• to gauge software security adequately.
• By identifying risks and potential loss associated with
those risks in the system and creating tests driven by
those risks
• The tester can focus on areas of code in which an attack is
likely to succeed.
• Therefore, risk analysis can help in identifying potential
security problems.
• Once identified and ranked, can help in security testing.
Risk Management
• Risk management and security testing
• Software security practitioners perform many
different tasks to manage software risks, including:
• Creating security abuse/misuse cases
• Listing normative security requirements
• Performing architectural risk analysis
• Building risk based security test plans
• Wielding static analysis tools
• Performing security tests.
Risk Management cont…
• Three tasks, i.e. architectural risk analysis, risk-based
security test planning, and security testing, are closely
linked because a critical aspect of security testing relies on
probing security risks.
• Based on design-level risk analysis and ranking of security
related risks, security test plans are prepared which guide
the security testing.
Risk Management cont…
Thus, security testing must necessarily involve
two diverse approaches:
◦ Testing security mechanisms to ensure that their
functionality is properly implemented.
◦ Performing-risk based security testing motivated by
understanding and simulating the attacker’s approach.
Elements of Security Testing
• Authentication
• To establish the validity of a transmission, message, or originator
• Authorization
• It is the process of determining that a requester is allowed to
receive a service or perform an operation.
• Availability
• It assures that the information and communication services will
be ready for use when expected.
• Non-repudiation
• A measure intended to prevent the later denial that an action
happened, or a communication
17 took place, etc.
Bug
Security problems in software An
implementation
level software
problem
Flaw
A problem at a
deeper level
Bugs + Flaws
leads to Risk
Solution …
Three pillars of security
Pillar I:
Applied Risk Management
Architectural risk analysis
Sometimes called threat modeling or security
design analysis
Is a best practice and is a touchpoint
Risk management framework
Considers risk analysis and mitigation as a full life
cycle activity
Pillar II:
Software Security Touchpoints
“Software security is not security software”
Software security
is system-wide issues (security mechanisms and design security)
Emergent property
Touchpoints in order of effectiveness (based on
experience)
Code review (bugs)
Architectural risk analysis (flaws)
These two can be swapped
Penetration testing
Risk-based security tests
Abuse cases
Security requirements
Security operations
Pillar II: (contd.)
Many organization
Penetration first
Is a reactive approach
Code Review and Architecture Risk Analysis can
be switched however skipping one solves only half
of the problem
Big organizations may adopt these touchpoints
simultaneously
Pillar II: (contd.)
Software security best practices applied to various software artifacts
Pillar II: (contd.)
Microsoft’s move ...
Pillar III:
Knowledge
Involves
Gathering, encapsulating, and sharing security knowledge
Software security knowledge catalogs
Principles
Guidelines Can be put into three categories
Rules Prescriptive knowledge
Vulnerabilities Diagnostic knowledge
Historical knowledge
Exploits
Attack patterns
Historical risks
Pillar III: Knowledge catalogs to s/w
artifacts
Risk management framework:
Five Stages
RMF occurs in parallel with SDLC activities
Measurement and reporting
1 2 Identify 3 4
Understand the Business Define the Risk
Synthesize and
the Business and Technical Mitigation
Rank the Risks
context Risk Strategy
Artifact Analysis
Business
Context
5
Carry out fixes
And validate
Stage 1:
Understand Business Context
Risk management
Occurs in a business context
Affected by business motivation
Key activity of an analyst
Extract and describe business goals – clearly
Increasing revenue; reducing dev cost; meeting SLAs;
generating high return on investment (ROI)
Set priorities
Understand circumstances
Stage 2: Identify the business &
technical risks
Business risks have several impacts
Direct financial loss; loss of reputation; violation of
customer or regulatory requirements; increase in
development cost
Severity of risks
Should be captured in financial or project
management terms
Key is –
tie technical risks to business context
Stage 3: Synthesize and rank the
risks
Prioritize the risks alongside the business goals
Assign risks appropriate weights for resolution
Risk metrics
Risk likelihood
Risk impact
Number of risks mitigated over time
Stage 4: Risk Mitigation Strategy
Develop a coherent strategy
For mitigating risks
In cost effective manner; account for
Cost Implementation time
Completeness Impact
Likelihood of success
A mitigation strategy should
Be developed within the business context
Be based on what the organization can afford, integrate and
understand
Must directly identify validation techniques
Stage 5: Carry out Fixes and
Validate
Execute the chosen mitigation strategy
Rectify the artifacts
Measure completeness
Estimate
Progress, residual risks
Validate that risks have been mitigated
Testing can be used to demonstrate
Develop confidence that unacceptable risk does
not remain
Risk Mitigation Framework - A Multi-loop
Risk management is a continuous process
Five stages may need to be applied many times
Ordering may be interleaved in different ways
Risk can emerge at any time in SDLC
One way – apply in each phase of SDLC
Risk can be found between stages
Level of application
Primary – project level
Each stage must capture complete project
SDLC phase level
Artifact level
It is important to know that Risk Mitigation is
Cumulative
At times arbitrary and difficult to predict
Seven Touchpoints
Cost of fixing defect at each
stage
Architectural risk analysis
Design flaws
about 50% of security problem
Can’t be found by looking at code
A higher level of understanding required
Risk analysis
Track risk over time
Quantify impact
Link system-level concerns to probability and impact
measures
Fits with the RMF
ARA within RMF
2 Measurement and reporting
Identify
the Business Technical
Risk expertise
Artifact Analysis
1 4 5
Understand Business Define the Risk
Synthesize and
the Business Context Mitigation
Rank the Risks
context Strategy
3 Identify
the Technical
Risk
Artifact Analysis
7 6
Validate the
Initiate process Fix the artifacts
artifacts
improvement Validation loop
ARA process
Attack resistance analysis
Steps
Identify general flaws using secure design literature
and checklists
Knowledge base of historical risks useful
Map attack patterns using either the results of abuse
case or a list of attack patterns
Identify risk based on checklist
Understand and demonstrate the viability of these
known attacks
Use exploit graph or attack graph
- Note: particularly good for finding known problems
ARA process
Ambiguity analysis
Discover new risks – creativity requried
A group of analyst and experience helps – use multiple points of view
Unify understanding after independent analysis
Uncover ambiguity and inconsistencies
Weakness analysis
Assess the impact of external software dependencies
Modern software
is built on top of middleware such as .NET and J2EE
Use DLLs or common libraries
Need to consider
COTS
Framework
Network topology
Platform
Physical environment
Build environment
Software penetration testing
Most commonly used today
Currently
Outside->in approach
Better to do after code review and ARA
As part of final preparation acceptance regimen
One major limitation
Almost always a too-little-too-late attempt at the end of a
development cycle
Fixing things at this stage
May be very expensive
Reactive and defensive
Software penetration testing
A better approach
Penetration testing from the beginning and throughout
the life cycle
Penetration test should be driven by perceived risk
Best suited for finding configuration problems and other
environmental factors
Make use of tools
Takes care of majority of grunt work
Tool output lends itself to metrics
Tools for penetration testing
fault injection tools;
attacker’s toolkit: disassemblers and decompilers; coverage
tools monitors
Risk based security testing
Testing must be
Risk-based
grounded in both the system’s architectural
reality and the attacker’s mindset
Better than classical black box testing
Different from penetration testing
Level of approach
Timing of testing
Penetration testing is primarily on completed software
in operating environment; outside->in
Risk based security testing
Security testing
Should start at feature or component/unit level
testing
Must involve two diverse approaches
Functional security testing
Testing security mechanisms to ensure that their
functionality is properly implemented
Adversarial security testing
Performing risk-based security testing motivated by
understanding and simulating the attacker’s approach
Abuse cases
Creating anti-requirements
Important to think about
Things that you don’t want your software to do
Requires: security analysis + requirement analysis
Anti-requirements
Provide insight into how a malicious user, attacker,
thrill seeker, competitor can abuse your system
Considered throughout the lifecyle
indicate what happens when a required security
function is not included
Abuse cases
Creating an attack model
Based on known attacks and attack types
Do the following
Select attack patterns relevant to your system –
build abuse case around the attack patterns
Include anyone who can gain access to the system
because threats must encompass all potential
sources
Also need to model attacker
Security requirements and
operations
Security requirements
Difficult tasks
Should cover both over functional security and
emergent characteristics
Use requirements engineering approach
Security operations
Integrate the security operations
e.g. software security should be integrated with
network security
Research Motivations
Absence of Data-set: So we are in need of an
efficient data-set for analyzing Intrusion Detection
Systems.
Machine-Learning Techniques will improve the
security by around 200%.
Marking threats according to their effect on
vulnerability is needed to draw architecture for
software security.
All Viruses, Trojans and Malwares should be
studied and handled carefully to make our system
strong enough against these, in real- time.
Latent Errors: How Many Errors are Still
Remaining?
Make a few arbitrary changes to the program:
◦ Artificial errors are seeded into the program.
◦ Check how many of the seeded errors are detected during
testing.
Error Seeding
Let:
◦ N be the total number of errors in the system
◦ n of these errors be found by testing.
◦ S be the total number of seeded errors,
◦ s of the seeded errors be found during testing.
Error Seeding
n/N = s/S
N = S n/s
Remaining defects:
N - n = n ((S - s)/ s)
Quiz 2
100 errors were introduced.
90 of these errors were found during testing
50 other errors were also found.
Find errors remaining in code.
Quiz 2: Solution
100 errors were introduced.
90 of these errors were found during testing
50 other errors were also found.
Remaining errors=
50 (100-90)/90 = 6
Challenges in Error Seeding
The kinds of seeded errors should match closely
with existing errors:
◦ However, it is difficult to predict the types of errors that
exist.
Categories of remaining errors:
◦ can be estimated by analyzing historical data from similar
projects.
Quiz 3
Before system testing 100 errors were seeded.
During system testing 90 of these were detected.
150 other errors were also detected
How many unknown errors remain after system
testing?
Summary
Discussed security testing in detail.
Discussed Types of Security Requirements
Explained Software Vulnerability.
Presented the Elements of Security Testing.
Discussed the Security problems in software and the
solution.
Discussed how to know the latent errors.
55
References
1. Rajib Mall, Fundamentals of Software Engineering,
(Chapter – 10), Fifth Edition, PHI Learning Pvt.
Ltd., 2018.
2. Naresh Chauhan, Software Testing: Principles and
Practices, (Chapter – 7), Second Edition, Oxford
University Press, 2016.
THANK YOU
