Assumptions are frequently made during requirements analysis of a system about the trustworthiness of its various components (including human components). These trust assumptions, whether implicit or explicit, affect the scope of the analysis, derivation of security requirements, and in some cases how functionality is realized. This paper presents trust assumptions in the context of analysis of security requirements. A running example shows how trust assumptions can be used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process. The paper concludes with a case study examining the impact of trust assumptions on software that uses the secure electronic transaction specification.

Abstract. As software systems and networks continue to evolve, so do threats to their security. Unfortunately, most security issues come to light only after completion of the system because security is often managed in an ad hoc fashion late in the software lifecycle. There are many advantages to incorporating security specification into the requirements phase and a number of approaches have been proposed. In this paper, we present a comparative evaluation of three such approaches: The Common Criteria, Misuse Cases, and Attack Trees. We applied each of these approaches to a common problem, a wireless hotspot, and evaluated them for learnability, usability, solution inclusiveness, clarity of output, and analyzability. We found that each approach has strengths and weaknesses, and that they can be complimentary when combined. The Common Criteria are difficult to learn and use, but are easy to analyze. Misuse Cases are easy to learn and use, but produces output that is hard to read. In contrast, Attack Trees produce clear output, but are difficult to analyze.

Deviational analyses for validating regulations