Test Prioritization in
Security Risk Testing
36. GI-TAV
26. – 27. June, Leipzig - Deutschland Michael Berger,
IT security risk definition
The Potential that a
threat
will exploit a
vulnerability
of an
asset or group of assets
and thereby cause harm to the organization
(Source ISO 27000)Risk assessement (ISO 31000 / 2009)
Risk identification:
identifying sources of risk, areas of impacts, events, their causes and their potential consequences
Risk analysis: comprehend the nature of risk and to determine the level of risk
Risk evaluation: comparing the results of risk estimation with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable
Risk treatment: modify risk by avoidance or mitigations
Dynamic test process (DRAFT ISO 29119-2)
Test planning: determine test strategy, resource planning
Test design : deriving the test cases and test procedures.
Test implementation:
realizing the executable test scripts.
Test execution: running the test procedure resulting from the test design and
implementation phases.
Test reporting: managing the test incidents and the test results.
Optimizing security testing activities
Security testing
Test planning
Test design
Test implementation
Test execution
Test reporting
Security risk
assessment
• Risk-based
security test
identification
• Risk-based
security test
selection
& prioritisation
Optimizing security risk assessment
Security risk assessment
Establishing context
Risk identification
Risk analysis
Risk evaluation
Risk treatment
Security testing
• Test-based risk
identification
(identifying new
risk factors)
• Test-based
reassessment of
risk values (e.g.
probabilities)
Risk-based security testing goals
Providing arguments by experiments
Risk assessment
Test planning & test design
Test execution Test reporting
Provide arguments for the
absence of potential vulnerabilities.
Provide arguments for the
functional correctness of treatment
scenarios
and
countermeasures.
Discover
unknown
risk factors
(i.e. vulnerabilities)
Model-based security risk assessment
The CORAS approach
Source: http://coras.sourceforge.net/
• Developed by
Scandinavian
research organisation
SINTEF
• CORAS consists of
• Method for risk
analysis
• Language for risk
modeling
• Tool for editing
diagrams
Model-based security risk assessment
The CORAS approach
Threat (agent) Threat scenario Treatment scenario Vulnerability Unwanted incident Consequence
Risk evaluation
Risk = rv (Likelihood, Consequence)
Model-based security risk assessment
CORAS example (HBGary hack)
Risk-based security testing
Qualitative approach:
Risk-based test identification
What should be tested?
Starting point:
Vulnerabilities
Threat scenarios
Treatment scenarios
Quantitative approach
:
Risk-based test selection & prioritisation
How much/intensive should be tested?
Starting point:
Test objective specification Test scenario specification
Risk-based security test identification
Security Test Pattern
Security test pattern
consists of:
Mandatory attributes, i.e. id
and name
parameters for test
assessment
Descriptions and procedures
for manually testing
Parameters for automatically
testing (stimulation and
observation)
Risk-based security test identification
Decomposing the overall scenario
TP: Detection of vulnerability to data structure attacks Observation: Stimulus: Do different kind of SQL injections
TP: Detection of vulnerability to data structure attacks TP: Cryptographic strength tests TP: Software configuration and update checks
Security test prioritization
Calculating overall risk contribution of items
high
Security test prioritization
Calculating overall risk contribution of items
The potential that a threat will exploit a vulnerability of an asset or group of assets and thereby cause harm to the organization (Source ISO 27000)
Testing to find an argument for the absence of potential vulnerabilities.
Calculate and rate the risks (probability of unwanted incidents * consequence).
Identify the vulnerabilities with the highest impact to the most critical risks. Additional issues to be considered:
Impact of the vulnerability to the probability success probability of the threat scenario
Efforts needed to sufficiently test for a vulnerability
Quality of tests and test coverage
0.5
0.9
TP: Detection of vulnerability to data structure attacksFraunhofer Institute for
Open Communication Systems
FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin, Germany
Tel.
+49 (30) 34 63 -7000
Fax
+49 (30) 34 63 -8000
www.fokus.fraunhofer.de
Contact
Innovation Center for
Cost-Effective Systems Quality
http://s.fhg.de/sqc
Prof. Dr.-Ing.
Ina Schieferdecker
Tel. +49 (30) 3463-7241
[email protected]
Jürgen Großmann
Tel. +49 (30) 3463-7390
