RASK - Framework for IT security requirements

Authors:

  • Caroline Bildsten
  • Daniel Eidenskog
  • Jonas Hermelin
  • Jacob Löfvenberg

Publish date: 2018-11-08

Report number: FOI-R--4641--SE

Pages: 56

Written in: Swedish

Keywords:

  • RASK
  • KSF
  • IT security requirements
  • methodology

Abstract

IT systems are vital to many of the operations in the Swedish Armed Forces. Since the threat level against the Armed Forces is high, the resulting IT security requirements are extensive. Today's regulatory framework for IT security requirements is Krav på IT-säkerhetsförmågor hos IT-system v3.1 (KSF 3.1). As a step towards a more adaptable framework, the Swedish Armed Forces commissioned FOI to produce a suggestion for a new regulatory framework. The goals for the suggested framework were to reduce the risk of overly strict requirements, increase the predictability during requirement fulfillment assessment, increase the understanding of the requirements, and improve the possibility for continuous follow-ups. The work was conducted through an explorative process, where the starting point was the impact goals given by the Armed Forces combined with information collected from previous works showing areas where the current framework can be improved. The result is Ramverk för säkerhetskravställning (RASK), Framework for security requirement selection in English. RASK is a methodology that consists of several metods and a generic model for handling the requirements. The requirements are subdivided into strength levels, based on the level of threats that the solutions are expected to withstand. The strength levels are determined individually for all requirements based on a number of input parameters that describe the system's environment and context. The requirements used in the RASK methodology are clearly phrased and stated as target-oriented to increase the understanding of the requirements and their motives, while avoiding requirements that prescribe specific technical solutions. A demonstrator was developed during the project to show the functionality of the methodology and exemplify how requirements can be written.