Model-Based Security Testing

Security testing aims at validating software system requirements related to security properties like confidentiality, integrity, authentication, authorization, availability, and non-repudiation. Although security testing techniques are available for many years, there has been little approaches that allow for specification of test cases at a higher level of abstraction, for enabling guidance on test identification and specification as well as for automated test generation. Model-based security testing (MBST) is a relatively new field and especially dedicated to the systematic and efficient specification and documentation of security test objectives, security test cases and test suites, as well as to their automated or semi-automated generation. In particular, the combination of security modelling and test generation approaches is still a challenge in research and of high interest for industrial applications. MBST includes e.g. security functional testing, model-based fuzzing, risk- and threat-oriented testing, and the usage of security test patterns. This paper provides a survey on MBST techniques and the related models as well as samples of new methods and tools that are under development in the European ITEA2-project DIAMONDS.Comment: In Proceedings MBT 2012, arXiv:1202.582

Analyzing Android Browser Apps for file:// Vulnerabilities

Securing browsers in mobile devices is very challenging, because these browser apps usually provide browsing services to other apps in the same device. A malicious app installed in a device can potentially obtain sensitive information through a browser app. In this paper, we identify four types of attacks in Android, collectively known as FileCross, that exploits the vulnerable file:// to obtain users' private files, such as cookies, bookmarks, and browsing histories. We design an automated system to dynamically test 115 browser apps collected from Google Play and find that 64 of them are vulnerable to the attacks. Among them are the popular Firefox, Baidu and Maxthon browsers, and the more application-specific ones, including UC Browser HD for tablet users, Wikipedia Browser, and Kids Safe Browser. A detailed analysis of these browsers further shows that 26 browsers (23%) expose their browsing interfaces unintentionally. In response to our reports, the developers concerned promptly patched their browsers by forbidding file:// access to private file zones, disabling JavaScript execution in file:// URLs, or even blocking external file:// URLs. We employ the same system to validate the ten patches received from the developers and find one still failing to block the vulnerability.Comment: The paper has been accepted by ISC'14 as a regular paper (see https://daoyuan14.github.io/). This is a Technical Report version for referenc

What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE

Modeling input validation in UML

Security is an integral part of most software systems but it is not considered as an explicit part in the development process yet. Input validation is the most critical part ofsoftware security that is not covered in the design phase of software development life-cycle resulting in many security vulnerabilities. Our objective is to extend UML to new integrated jramework for model driven security engineering leading to ideal way to design more secure software. Input validation in UML has not been addressed previously, hence we incorporate input validation into UML diagrams such as use case, class, sequence and activity. This approach has some advantages such as preventing jrom common input tampering attacks, having both security and convenience in software at high level of abstraction and ability of solving the problem ofweak security backgroundfor developers

Automated Reusable Tests for Mitigating Secure Pattern Interpretation Errors

The importance of software security has increased along with the number and severity of incidents in recent years. Security is a multidisciplinary aspect of the software development lifecycle, operation, and user utilization. Being a complex and specialized area of software engineering, it is often sidestepped in software development methodologies and processes. We address software security at the design level by adopting design patterns that encapsulate reusable solutions for recurring security problems. Design patterns can help development teams implement the best-proven solutions for a specialized problem domain. However, from the analysis of three secure pattern implementations by 70 junior programmers, we detected several structural errors resulting from their interpretation. We propose reusable unit testing test cases based on annotations to avoid secure pattern interpretation errors and provide an example for one popular secure pattern. Providing these test cases to the same group of programmers, they implemented the pattern without errors. The reason is annotations build a framework that disciplines programmers to incorporate secure patterns in their applications and ensure automatic testing.info:eu-repo/semantics/publishedVersio

Assessing and augmenting SCADA cyber security: a survey of techniques

SCADA systems monitor and control critical infrastructures of national importance such as power generation and distribution, water supply, transportation networks, and manufacturing facilities. The pervasiveness, miniaturisations and declining costs of internet connectivity have transformed these systems from strictly isolated to highly interconnected networks. The connectivity provides immense benefits such as reliability, scalability and remote connectivity, but at the same time exposes an otherwise isolated and secure system, to global cyber security threats. This inevitable transformation to highly connected systems thus necessitates effective security safeguards to be in place as any compromise or downtime of SCADA systems can have severe economic, safety and security ramifications. One way to ensure vital asset protection is to adopt a viewpoint similar to an attacker to determine weaknesses and loopholes in defences. Such mind sets help to identify and fix potential breaches before their exploitation. This paper surveys tools and techniques to uncover SCADA system vulnerabilities. A comprehensive review of the selected approaches is provided along with their applicability