A Tool-based Semantic Framework for Security Requirements Specification

Attaining high quality in security requirements specification requires first-rate professional expertise, which is scarce. In fact, most organisations do not include core security experts in their software team. This scenario motivates the need for adequate tool support for security requirements specification so that the human requirements analyst can be assisted to specify security requirements of acceptable quality with minimum effort. This paper presents a tool-based semantic framework that uses ontology and requirements boilerplates to facilitate the formulation and specification of security requirements. A two-phased evaluation of the semantic framework suggests that it is usable, leads to reduction of effort, aids the quick discovery of hidden security threats, and improves the quality of security requirements

AMAN-DA : Une approche basée sur la réutilisation de la connaissance pour l'ingénierie des exigences de sécurité

In recent years, security in Information Systems (IS) has become an important issue that needs to be taken into account in all stages of IS development, including the early phase of Requirement Engineering (RE). Considering security during early stages of IS development allows IS developers to envisage threats, their consequences and countermeasures before a system is in place. Security requirements are known to be “the most difficult of requirements types”, and potentially the ones causing the greatest risk if they are not correct. Moreover, requirements engineers are not primarily interested in, or knowledgeable about, security. Their tacit knowledge about security and their primitive knowledge about the domain for which they elicit security requirements make the resulting security requirements poor and too generic.This thesis explores the approach of eliciting requirements based on the reuse of explicit knowledge. First, the thesis proposes an extensive systematic mapping study of the literature on the reuse of knowledge in security requirements engineering identifying the diferent knowledge forms. This is followed by a review and classification of security ontologies as the main reuse form.In the second part, AMAN-DA is presented. AMAN-DA is the method developed in this thesis. It allows the elicitation of domain-specific security requirements of an information system by reusing knowledge encapsulated in domain and security ontologies. Besides that, the thesis presents the different elements of AMANDA: (i) a core security ontology, (ii) a multi-level domain ontology, (iii) security goals and requirements’s syntactic models, (iv) a set of rules and mechanisms necessary to explore and reuse the encapsulated knowledge of the ontologies and produce security requirements specifications.The last part reports the evaluation of the method. AMAN-DA was implemented in a prototype tool. Its feasibility was evaluated and applied in case studies of three different domains (maritime, web applications, and sales). The ease of use and the usability of the method and its tool were also evaluated in a controlled experiment. The experiment revealed that the method is beneficial for the elicitation of domain specific security requirements, and that the tool is friendly and easy to use.Au cours de ces dernières années, la sécurité des Systèmes d'Information (SI) est devenue une préoccupation importante, qui doit être prise en compte dans toutes les phases du développement du SI, y compris dans la phase initiale de l'ingénierie des exigences (IE). Prendre en considération la sécurité durant les premieres phases du dévelopment des SI permet aux développeurs d'envisager les menaces, leurs conséquences et les contre-mesures avant qu'un système soit mis en place. Les exigences de sécurité sont connues pour être "les plus difficiles des types d’exigences", et potentiellement celles qui causent le plus de risque si elles ne sont pas correctes. De plus, les ingénieurs en exigences ne sont pas principalement intéressés à, ou formés sur la sécurité. Leur connaissance tacite de la sécurité et leur connaissance primitive sur le domaine pour lequel ils élucident des exigences de sécurité rendent les exigences de sécurité résultantes pauvres et trop génériques.Cette thèse explore l'approche de l’élucidation des exigences fondée sur la réutilisation de connaissances explicites. Tout d'abord, la thèse propose une étude cartographique systématique et exhaustive de la littérature sur la réutilisation des connaissances dans l'ingénierie des exigences de sécurité identifiant les diférentes formes de connaissances. Suivi par un examen et une classification des ontologies de sécurité comme étant la principale forme de réutilisation.Dans la deuxième partie, AMAN-DA est présentée. AMAN-DA est la méthode développée dans cette thèse. Elle permet l’élucidation des exigences de sécurité d'un système d'information spécifique à un domaine particulier en réutilisant des connaissances encapsulées dans des ontologies de domaine et de sécurité. En outre, la thèse présente les différents éléments d'AMAN-DA : (i) une ontologie de sécurité noyau, (ii) une ontologie de domaine multi-niveau, (iii) des modèles syntaxique de buts et d’exigences de sécurité, (iv) un ensemble de règles et de mécanismes nécessaires d'explorer et de réutiliser la connaissance encapsulée dans les ontologies et de produire des spécifications d’exigences de sécurité.La dernière partie rapporte l'évaluation de la méthode. AMAN-DA a été implémenté dans un prototype d'outil. Sa faisabilité a été évaluée et appliquée dans les études de cas de trois domaines différents (maritimes, applications web, et de vente). La facilité d'utilisation et l’utilisabilité de la méthode et de son outil ont également été évaluées dans une expérience contrôlée. L'expérience a révélé que la méthode est bénéfique pour l’élucidation des exigences de sécurité spécifiques aux domaines, et l'outil convivial et facile à utiliser

HCAPP-SEC : selection and analysis of security assessment items based on heuristics and criteria

Orientador: Mario JinoTese (doutorado) - Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de ComputaçãoResumo: Nos dias atuais, o software tem papel importante na maioria das indústrias e áreas de atividade. Os aspectos relacionados à segurança da informação são críticos, com forte impacto na qualidade dos sistemas. Como saber se uma determinada avaliação de segurança foi boa ou suficiente? Por meio de critérios e heurísticas é possível determinar a suficiência da avaliação de segurança e, consequentemente, analisar sua qualidade. Fontes de conhecimento (normas, padrões, conjuntos de casos de teste) e seus itens de avaliação são instrumentos essenciais para avaliar a segurança dos sistemas. Para criar projetos de avaliação de segurança mais efetivos é necessário saber as propriedades de segurança e as dimensões de avaliação abordadas em cada item de uma fonte de conhecimento de segurança. Nesta tese, uma abordagem para selecionar e analisar itens de avaliação de segurança (HCApp-Sec) é proposta; suas bases provêm de critérios e heurísticas de avaliação e visam a aumentar a cobertura das dimensões de avaliação e propriedades de segurança dos projetos de avaliação. A abordagem centra-se em selecionar itens de avaliação de forma sistemática. Sistematiza-se o processo de avaliação de segurança por meio da formalização conceitual da área de avaliação de segurança; uma ontologia (SecAOnto) é usada para explicitar os conceitos principais. HCApp-Sec pode ser aplicada a qualquer fonte de conhecimento de segurança para selecionar ou analisar itens de avaliação em relação a 11 propriedades de segurança e 6 dimensões de avaliação. A abordagem é flexível e permite que outras dimensões e propriedades sejam incorporadas. Nossa proposta visa a apoiar: (i) a geração de projetos de avaliação de segurança de alta cobertura que incluam itens mais abrangentes e com cobertura assegurada das principais características de segurança e (ii) a avaliação de fontes de conhecimento de segurança em relação à cobertura de aspectos de segurança. Em um estudo de caso, um mapeamento de fontes de conhecimento de segurança é apresentado. Então, aplica-se a proposta a uma fonte de conhecimento de segurança bem conhecida (ISO/IEC 27001); seus itens são analisadosAbstract: Nowadays, software plays an important role in most industries and application domains. The aspects related to information security are critical, with a strong impact on systems quality. How to know whether a particular security assessment was good or sufficient? By means of criteria and heuristics it is possible to determine the sufficiency of the security assessment and consequently to analyze its quality. Knowledge sources (standards, patterns, sets of test cases) and their assessment items are essential instruments for evaluation of systems security. To create security assessment designs with suitable assessment items we need to know which security properties and assessment dimensions are covered by each knowledge source. We propose an approach for selecting and analyzing security assessment items (HCApp-Sec); its foundations come from assessment criteria and heuristics and it aims to increase the coverage of assessment dimensions and security properties in assessment designs. Our proposal focuses on the selection of better assessment items in a systematic manner. We systematize the security assessment process by means of a conceptual formalization of the security assessment area; an ontology of security assessment makes explicit the main concepts. HCApp-Sec can be applied to any security knowledge source to select or analyze assessment items with respect to 11 security properties and 6 assessment dimensions. The approach is flexible and allows other dimensions and properties to be incorporated. Our proposal is meant to support: (i) the generation of high-coverage assessment designs which includes security assessment items with assured coverage of the main security characteristics and (ii) evaluation of security standards with respect to coverage of security aspects. We have applied our proposal to a well known security knowledge source (ISO/IEC 27001); their assessment items were analyzedDoutoradoEngenharia de ComputaçãoDoutor em Engenharia Elétric

A Tool-based Semantic Framework for Security Requirements Specification

Abstract: Attaining high quality in security requirements specification requires first-rate professional expertise, which is scarce. In fact, most organisations do not include core security experts in their software team. This scenario motivates the need for adequate tool support for security requirements specification so that the human requirements analyst can be assisted to specify security requirements of acceptable quality with minimum effort. This paper presents a tool-based semantic framework that uses ontology and requirements boilerplates to facilitate the formulation and specification of security requirements. A two-phased evaluation of the semantic framework suggests that it is usable, leads to reduction of effort, aids the quick discovery of hidden security threats, and improves the quality of security requirements. Keywords: security requirements, ontology, requirements boilerplates, information extraction, security threat, misuse cases. Categories: D.2.1, M.4, M.8 Introduction The advent of the Internet and virtual environments that afford systems integration and collaboration among remotely based systems has increased the importance of security considerations when developing software systems. Security requirements specification entails the formal documentation of identified security needs of a system in order to ensure the development of secure information systems. However, attaining good quality in security requirements specification requires first-rate professional expertise, which is scarce. There is a lack of security experts or security requirements engineers in many organizations. This is because most requirements engineers have had no training in identifying, analysing, specifying, and managing security requirements (SR) [Firesmith 04; Salini 11]. Hence, when security requirements are Science, vol. 19, no. 13 (2013Science, vol. 19, no. 13 ( ), 1940Science, vol. 19, no. 13 ( -1962 1/7/13 © J.UCS defined, they are often either too vague or overly specific in constraining designers to use particular mechanisms [Firesmith 04]. This scenario motivates the provision of tool-based support for security requirements specification. The tool-based support will: 1) assist the requirements analyst (subsequently referred to as analyst) to identify security threats, which is usually a manual procedure in which the quality of SR depends on the expertise of the human personnel; 2) stimulate the adoption of appropriate defence strategies to deal with the identified security threats; 3) enable the formulation of SR in a consistent way, minimizing ambiguity, and enhancing correctness of SR; and 4) reduce the effort needed for security requirements specification by allowing the reuse of previously specified SR in subsequent instances. The overriding aim is to complement the capabilities of the analyst in the task of security requirements specification so that the quality of SR is improved and the amount of human effort reduced. In order to realize this aim, we have adopted a semantic-based approach that uses an integration of ontologies and requirements boilerplates to complement the activities of the analyst during security requirements specification. A requirement boilerplate is a predefined textual template that can guide the way requirements are written so that a consistent pattern can be maintained when writing structurally similar requirements [Hull 04]. The use of ontologies provides the necessary background knowledge, and domain knowledge that is required to identify security threats, and recommend appropriate countermeasures, while the requirements boilerplates provide a reusable template for writing SR in a consistent way in order to minimize ambiguity. Relative to previous approaches, the main contribution of this work is the provision of an elaborate semantic-based procedure that enables the toolassisted formulation of SR in a way that enhances quality, and reduces effort needed to formulate SR. This is because our approach: 1) enables identification of security threats from security threat description scenarios; 2) provides recommendation of defence actions as countermeasure to identified security threats; and 3) enables pattern-based reuse of requirements boilerplates when writing SR. Journal of Universal Computer The rest of this paper is as follows. Section 2 gives an overview of contextual background and related work, while Section 3 presents our approach. Section 4 discusses the evaluation, results and threats to validity. The paper is concluded in Section 5 with a discussion of further work. Background and Related Work In this section, we provide background information on security requirements engineering (SRE), application of ontologies to SRE, and the use of boilerplates for security requirements specification. Additionally, we discuss related work. Security Requirements Engineering (SRE) A requirement is "a condition or capability that must be met by the system to solve a problem or achieve an objective" [IEEE Std. 98 It is a nine-step process consisting of the following activities: 1) agree on definitions; 2) identify vulnerable and/or critical assets; 3) identify security objectives and dependencies; 4) identify threats and develop artifacts; 5) risk assessment; 6) elicit security requirements; 7) categorize and prioritize requirements; 8) requirements inspection; and 9) repository improvement. . CORAS is a seven steps process that provides a customized language for threat and risk modeling and has a detailed guide on how the language should be used to capture and model relevant information during the security analysis. CORAS methods provides a computational tool designed to support documenting, maintaining and reporting analysis results through risk modeling, table-based documentation, consistency checking and more. The seven steps of CORAS are: 1) Introduction; 2) high level analysis; 3) approval of target description; 4) risk identification; 5) risk estimation; 6) risk evaluation, and 7) risk treatment. Application of Ontologies to SRE Ontology is a shared formal conceptualization of a domain that allows definition of semantic relationships between entities, and inference of knowledge through reasoning at run-time Generally, a good ontology will facilitate more effective reporting of incidents, sharing of information, and interoperable security collaborations among different organizations. Our proposed framework uses ontology to ensure the standardization of vocabulary in security requirements specification, threat identification, and the recommendation of appropriate countermeasure to identified threats. Boilerplates for Security Requirements The notion of requirements boilerplates (RB) which stems originally from the work of [Hull 04], and subsequently applied in [Daramola 11] enables the writing of requirements in a consistent manner. A requirement boilerplate is a pre-defined structural template for writing requirement statements. It imposes a uniform structure on the way requirements are written, by affording a level of expressivity akin to using natural language, yet minimising ambiguity in requirement statements. The fixed parts of requirement boilerplate are reused when writing requirements, while the analyst can fill in the parameter parts manually. An example of a boilerplate taken from the webpage 1 is: "BP2: The <system> shall be able to <action> <entity>" Here, BP2 is the label of this particular boilerplate. The terms in < > brackets are parameters where something must be filled in when the boilerplate is instantiated to a concrete requirement. The words that are outside brackets are the fixed syntax elements (FSE) that will be kept as-is when the boilerplate is instantiated. An example of an instantiation of this particular boilerplate, would be "The Internet banking system shall be able to authenticate all its users". In this case <action> has been replaced by "authenticate" and <entity> by "all its users". In some cases, several boilerplates may be combined to make precise and testable requirements, e.g. combining BP2 with BP37 ...at least <percentage> of the time will yield the requirement "The Internet banking system shall be able to authenticate all users at least 99.99% of the time". Thus, the use of boilerplate will ensure that a unified structure and style of writing is used for requirements that pertain to specific classes of system function, capability, goals, or constraints. The FSE in each boilerplate will remain the same for all requirements that used a certain boilerplate. For instance, all who used BP2 + BP37 to specify that the system should be able to do something with some specific frequency, will now use phrases "shall be able to", "at least", "times per", rather than various other phrases that could have more or less the same meaning, e.g., "have the ability to", "be capable of", "a minimum of", "more than", "shots per", etc. Therefore, using boilerplates will: i) facilitate the reuse of parts of the requirements text (viz. the FSE), as well as hints what should be filled in for parameters; (ii) help to attain better quality of requirements, e.g., BP35 reminding analysts that one should be precise about the required frequency of some action, thus encouraging more quantification of requirements, which is vital for testability (viz. using boilerplates as preliminary basis for requirements checking); and (iii) lead to completeness of the specification, e.g., looking at the boilerplates available, the analyst or domain expert might be reminded of requirements that they would otherwise have forgotten to specify (viz. using the boilerplates catalogue as a checklist). Boilerplates could also be applied to security requirements (SR), and it is possible to integrate the formulated boilerplates with a security-related ontology for specifying SR. In [Firesmith 05], Firesmith provided a foundation for the mapping of specific security requirements to the types of defence actions to address them. He identified four different types of defence against security threats, which can be used to assign specific security threats to the types of defence actions to counter them. These are: (i) Prevention of malicious harm, security incident, security threats and security risks. (ii) Detection of malicious attack, security incidents, security threats, and security risks. (iii) Reaction to detected malicious attack. (iv) Adaptation of system to avoid or minimize the negative consequences of the malicious harm, security incidents, security threats and security risks. This could also be in terms of recovery of system from attacks. For each of the defence types, Firesmith also gave specific examples. The The use of boilerplates for security requirements specification in practical terms will involve formulating requirement boilerplates for the different aspects of security such as authentication, authorization, integrity, intrusion detection, non-repudiation, confidentiality, and auditing. Therefore, more boilerplates could be formulated, both as core parts and as attachments, but since boilerplates for security will vary for different domains, we cannot go into more detail here. However, experienced personnel must create the boilerplates prior to security requirements specification as an upfront investment, while it should be updated periodically as new types of requirements emerge. By so doing, the boilerplate repository becomes an organisational asset for security requirements specification that can be useful when there is paucity of experienced security requirements analyst personnel. Extending Boilerplates with Ontologies It is possible to use boilerplates without any ontology, and the originators of boilerplates did not propose any ontology extension. Without ontologies, the boilerplates will still be useful in providing reuse of at least the FSE, and probably some quality increase by writing requirements in a fixed style, where one is reminded of the need to quantify requirements where possible. Extending the boilerplates with ontologies gives some extra advantages, such as allowing the validation of terms and relationships that are contained in requirements to ensure they are used correctly and acceptably in the domain concerned [Daramola 12]. For example, pertaining to the parameterized parts in italics in the boilerplate examples above (SecBP1), where the analysts themselves have to fill in numbers, single words or phrases in the boilerplate requirements, an ontology could be developed based on standards documents for that domain. The domain ontology will ensure that whenever the analyst fills in a word or phrase denoting some recognized concept from the ontology, say "ACC" (Automatic Cruise Controller) in the case of developing automotive software, the support tool could search for the concept ACC in the domain ontology, and -if finding it -know (i) whether there are any other terms which might be synonyms for this, and thus discover relationships between requirements that would not easily have been discovered otherwise, because of different terminology used; (ii) what other components are closely related to the ACC; and (iii) what various security levels is typically required of ACC, etc. Similarly, for other domains, e.g., aviation, one would have definitions of relevant concepts there, like flight, plane, pilot, runway, tower, etc. stored in a domain ontology. Hence, to put it simply, if just using boilerplates without ontologies, the analysts mainly get help with reusing the FSE (bold phrases) of examples like those above, but are left on their own with the parameters (italics) to fill the brackets. With ontologies there is help also with ensuring consistent use of language, discovering requirements that are related to each other because they address the same or closely related concepts or procedures in the system, etc. Hence, a tool platform that enables the leveraging of domain knowledge via an ontology, and use of boilerplates will be potentially useful to a requirements analyst in the process of security requirements specification. Related Work We shall approach our review of related work from two perspectives. First we shall consider the recent approaches of ontology-based frameworks for security and second, the aspect of tool support for security requirements engineering (SRE). Recent approaches of ontology-based frameworks for security include [Lasheras et al., 2009], where an ontology framework for reusing security requirements during requirements specification was presented. The work involved the creation of a risk analysis ontology and requirement ontology which are combined to represent reusable security requirements, and improve the detection of incomplete and inconsistent requirements, and also semantic processing in requirements analysis. It was an extensible framework that provided basis for a lightweight method to elicit, and specify security requirements, based on security standards. The framework is typically a combination of ontologies that will be useful to ontology experts who are not experienced in security issues. However, the work was not focussed on detecting 1946 Daramola O., Sindre G., Moser T.: A Tool-based Semantic Framework ... security threats from textual sources as done in our own approach, neither was it a tool-based framework. [Chikh et al., 2011] proposed a framework for information security requirements (ISRs) using ontologies. The framework enables ISRs traceability and reuse based on three kinds of generic ontologies -software requirement ontology, application domain ontology, and information security ontology. The work proposed the design of an ontology-based information security requirements engineering framework, which supports analysts in building and managing their ISRs by leveraging the three ontologies. The authors anticipated that the proposal will help requirements engineers to create and understand the ISRs. The work was strictly a proposal that did not include any implementation or evaluation. [Massacci et al., 2011] presented an amalgamated and extended ontology for modelling security requirements. The extended ontology integrates the existing concepts from the Problem Frames and Secure i* methodologies in order to realize a more complete basis for modelling security requirements due to missing constructs in the individual approaches. The expressiveness of the proposed extended ontology was tested by modelling the security requirements of a case study from the Air Traffic Management domain. Similarly, [Blanco et al., 2011] after conducting a systematic review of existing proposals, proposed a basis for an integrated and united security ontology since existing security ontologies seem to focus on specific domains. They identified three key requirements that an integrated security ontology should consider, which are static knowledge -which will allow the concepts collected in the ontology to be properly identified; dynamic knowledge -which will ensure that the knowledge collected in the ontology can be used to infer other knowledge; and reusabilitywhich will ensure the fact that the ontology is developed by taking into consideration aspects that permit its reuse and shareability. The tool-based orientation of our approach is a deviation from existing ontology-based frameworks for security, in that it targets real-time support for the requirements analyst during security requirements specification. It leverages ontology and a template-based approach -boilerplates -for both the elicitation and formulation of security requirements from textual sources in order to reduce effort and enhance quality. In terms of tool support for SRE, we shall classify tool for SRE into two broad categories -front-end tools and back-end tools. Front-end tools and approaches are those that facilitate the elicitation, modelling, and analysis of security threats in order to derive SR, while the back-end tools are those that help with the specification and validation of SR, and their integration with other requirements. Currently, there are more front-end tools than back-end tools for SRE. The SQUARE tool [Mead 05] is a back-end managerial tool that is designed to increase the quality of SRE process for the adopters of the SQUARE methodology. It supports core SRE aspects such as definitions, searching, and addition of new terms, identification of security goals, assets and privacy goals, performing risk assessment, identifying threats, prioritizing requirements, traceability, and exporting of requirements to other requirements management tool. Similarly, the prototype toolReqSec tool -that we have developed is an eclipse-based back-end tool that supports security requirements specification, and enables the integration of SR with other types of requirements. The unique feature of the ReqSec tool compared to other SRE backend tools stems from its capability to facilitate automatic analysis of natural language requirements in order to assist the analyst during security requirements specification. It represents a first attempt to use semantic-based procedures for supporting both security threat identification and security requirements specification. In the wider requirements engineering context, approaches such as [Gleich 10] -ambiguity detection-, [Wilson 97; Fabrini 01] -requirement quality assessment-, are also based on natural language (NL) text analysis but did not use ontologies. The DODT [Farfeleder 11] tool does not have a focus for SRE, but it bears similarity with our approach, because it combines the use of ontologies and boilerplates to enable semiautomatic transformation of NL requirements into boilerplate requirements. However, it can only ensure the correctness of requirements based on the underlying domain ontology, and the writing of boilerplate requirements. Our approach does more, in that it entails the discovery of latent security threats contained in NL descriptions, and the recommendation of probable defence actions that aids the formulation of semi-formal boilerplate SR. Hence, the novelty of our approach is the provision of a backend tool for SRE that will minimize effort needed for security requirements specification, and offer a credible starting point for security requirements specification, particularly in cases where there is paucity of experienced personnel. 3 Overview of the Semantic Approach A high-level schematic overview of our semantic approach is presented in Figure 1: Activity Workflow of the tool-assisted SR Specification Process Database Tampering -Example In order to demonstrate how our tool-based framework can be applied, we hereby consider the example of a security threat description of database tampering scenario. The detail of the scenario is presented in Name of System Web Query System Summary A crook manipulates the web query, submitted from a search form, to update or delete information, or to reveal confidential information; Basic Path The crook provides some values on a product search form and submits. The system displays the product(s) matching the query. The crook alters the submitted URL, introducing a query error, and resubmits. The query fails and the system displays the database error message to the crook, revealing more about the database structure. The crook alters the query further, for instance adding a nested query to reveal secret data or update or delete data, and submits. The system executes the altered query, changing the database or revealing content that should have been secret. Alternative Path