by Ina Schieferdecker, Axel Rennoch and Jürgen Großmann

Although security and model-based testing are not new areas of research, they are still under development and highly relevant. In particular, their combination is a challenge for academic work and industrial applications. Some examples of systematic and automated security testing include: security functional testing, model-based fuzzing, risk-oriented testing and the usage of security test pattern.

Multiple standardization committees provide significant efforts in the context of security testing. They cover fundamental frameworks but also detailed test specifications for concrete technologies. The range of activities is very large and includes classical concepts from security evaluation using Common Criteria (ISO/IEC 15408) for Information Technology Security Evaluation (CC) and innovative European activities from ETSI like TVRA (Threat Vulnerability Risk Analysis).

The CC is an international standard for the certification of IT-security products. The evaluation process is largely driven by developer documentation and focuses on product development, security testing and vulnerability assessment. In addition to creating trust in the product’s quality, the evaluation results also allow the customer to compare the security functionality of similar products.

The TVRA method developed by ETSI benefits from the CC's work by using a well-established domain-independent generic catalogue of security functional requirements (SFRs), and is characterized by the following concepts and approaches: Threat types like interception, manipulation, denial-of-service, repudiation of messages; security objectives like confidentiality, integrity, availability, authenticity, accountability; UML to model relationships within systems; methods to analyze/evaluate threats, risks, vulnerabilities; calculation of attack potential; and the security requirements taxonomy for SFRs (from CC).

CC and TVRA both require further knowledge about how to derive security tests from the TOE description. The ITEA DIAMONDS project invests in the automatic generation of security tests from system models. The security tests needed in the quality assurance phase and/or evaluation procedures may be derived manually from the system description. Model-based approaches are currently used to contribute towards the generation of security tests. DIAMONDS work includes fuzzing, risk-based testing and security test pattern.

Figure 1: Security testing combined approaches
Figure 1: Security testing combined approaches

The aim of fuzzing is to find deviations of the real System under Test (SUT) to its specification that lead to vulnerabilities because invalid input is processed by the SUT instead of being rejected. Such deviations may lead to undefined states of the SUT which can be exploited by an attacker, for example by allowing a denial-of-service attack because the SUT is crashing or hanging.

Risk-based security testing can generally be introduced with two different goals in mind. On the one hand, risk based testing approaches can help to optimize the overall test process. The results of the risk analysis, ie the results of threat and vulnerability analysis, are used to guide the test identification and may complement requirements engineering results with systematic information concerning threats and vulnerabilities of a system. A comprehensive risk assessment additionally introduces the notion of risk values, that is the estimation of probabilities and consequences for certain threat scenarios.

The "Security Testing chocolate box" presented by DIAMONDS at the ITEA2/ARTEMIS co-summit event 2011 in Helsinki provides a catchy example and a basic model of most security relevant terms (using CORAS) in the context of model-based security testing. It uses a chocolate box as an analogy of a SUT / Target of Evaluation (TOE), different types of chocolate as the assets, and Fredi, an intelligent fox, as the threat that wants chocolate. A security analysis focuses on the box interfaces, vulnerabilities (cover plate and a slot in the cover plate) and threat scenarios (using some tools to get the assets out of the box), in order to avoid “unwanted incidents”, ie the chocolate leaving the box.

Details of fuzzing and risk-based testing can be found in the DIAMONDS deliverables. The project also looks at approaches for capturing security test patterns to create an initial repository thereof, based on the weaknesses and strengths of the systems involved. Like other types of pattern, security test patterns will be both procedural and structural, leading to various sorts of test artefacts, ranging from high-level test activities and methods, via more specific test requirements through to concrete elements of test design, eg test architecture, test behaviour and test data.

rennoch2
Figure 2: Security Models

In the ITEA DIAMONDS project, 22 partners from six European countries are involved in case studies from the following domains: Banking, Smart Cards, Industrial Automation, Radio Protocols, Transport/Automotive, and critical infrastructures. Based on votes cast by participants at the ITEA2/ARTEMIS co-summit 2011 the DIAMONDS project won the prize for the best and most understandable ITEA2 project. We thank our colleagues from the project team at FOKUS and the international project consortium for their support.

Link:
http://www.itea2-diamonds.org

Please contact:
Ina Schieferdecker
Fraunhofer FOKUS, Germany
Tel: +49 30 3463 7241
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.

{jcomments on}
Next issue: October 2024
Special theme:
Software Security
Call for the next issue
Get the latest issue to your desktop
RSS Feed