Article Preview
Top1. Introduction
Traditional security engineering requires a big up-front design (BUFD) which includes the following engineering tasks: threat analysis, security requirements elicitation, security design and (security) architecture. Reviews ensure the consistency of these artifacts. In highly secure systems, the consistency of the security requirements and the security architecture is formally verified. Altogether, this constitutes a huge effort, before the implementation is even started upon. After the security design, the system is implemented according to requirements and design. Thereafter, evidence of security has to be provided in the form of documentation. This documentation is then delivered to the evaluation body. The evaluation may take several months. If the feedback from the evaluator is negative, the system has to be re-designed. If this is the case, then a large amount of time and effort would be required. Moreover, the pressure to deliver the product to market is high. Summarizing, the challenges involved in security engineering are: early validation and time-to-market. The software industry came up with the trend of agile development practices (Cockburn, 2006), such as XP, Scrum, and Test-driven development. Agile methods focus on customer interaction and incremental software development. Feedback loops, such as customer on-site, pair programming and refactoring tend to minimize errors. Generally, agile processes react flexibly to changing customer requirements. In contrast, traditional processes tend to fulfill contractually specified requirements and are inflexible, by nature. Agile processes have demonstrated a high success rate in several software projects (Cohn, 2010). Unfortunately, agile methods have not been well studied for high-level security engineering and evaluation. Case studies and success stories are lacking, especially for the Common Criteria standard (Common Criteria, 2012). Despite the fact that traditional security engineering seems to counter agile practices (Beznosov, 2004), we think that a synthesis of both is not contradictory, if well considered.
In the background section we provide material, we think helps to understand the following sections. As we do not claim a contribution in this section, we want to keep this section as simple as possible.
Our contribution is the analysis of two evaluation approaches, which are possibly suitable for an agile security evaluation. Both evaluation approaches are compared and one of them is then proposed for an agile security evaluation. In an agile security evaluation, all security properties of the system are kept in a model, which is capable of creating documentation for an evaluation round. In the agile evaluation approach only the increment of the model has to be reviewed. This has several benefits: the entire system does not have to be reviewed in each iteration. The evaluator starts with a small system and gains experience as the system matures. Early feedback enables an early, and thus more inexpensive, correction of the system. With elaborated algorithms we are able to create a difference model for all changes during an increment. Additionally, we demonstrate the feasibility of automation by customizing existing open source software.
The presented agile security evaluation approach is applicable under certain constraints. We discuss those constraints, which are fulfilled in a large portion of today’s industrial software projects. However, the existing certification scheme could be enhanced in order to better support agile development processes. As a contribution, we propose to view security assurance under two perspectives: structural product assurance and behavioral process assurance. Both of the mentioned assurance paradigms are well established in other domains, such as automotive safety engineering (Habli, 2006; Habli, 2007; Hawkins, 2010). These paradigms span a two dimensional assurance space. The concept of such an assurance space could provide a more flexible certification scheme that could support traditional and agile development processes.