Security requirements analysis based on security and domain ontologies

HAL Id: hal-00864311

https://hal-paris1.archives-ouvertes.fr/hal-00864311

Submitted on 20 Sep 2013

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Security requirements analysis based on security and

domain ontologies

Amina Souag, Camille Salinesi, Isabelle Wattiau

To cite this version:

Amina Souag, Camille Salinesi, Isabelle Wattiau. Security requirements analysis based on security

and domain ontologies. REFSQ, Apr 2013, Essen, Germany. pp.1-3. �hal-00864311�

Security requirements analysis based on security and

domain ontologies

Amina Souag1, Camille Salinesi1, Isabelle Wattiau2

1

CRI, Paris 1 Sorbonne University {Amina.Souag, camille.salinesi}@malix.univ-paris1.fr

2

CEDRIC-CNAM & ESSEC Business School, France [email protected]

Security is the discipline concerned with protecting systems from a wide range of threats (malice, error or mischief) that break the system by exploiting a vulnerability, i.e. a property of the system or its environment that, when faced with particular threats, can lead to failure[5] . Security is a multi-faceted problem; it is as much about understanding the domain in which systems operate as it is about the systems themselves. While developing security facilities such as encryption, identity control, or specific architectures is important, our attention should be drawn at looking into the sociotechnical context in which target systems will operate and threats that may arise and their potential harm, so as to uncover security requirements. Recent research has argued about the importance of considering security at the early stages of the information systems development process, and especially the need to consider security during RE.

An ontology, in the field of knowledge representation, is most often defined as “a representation of a conceptualization”[1]. It should represent a shared conceptualization in order to have any useful purpose [2]. Ontologies are useful for representing and interrelating many types of knowledge. Several security ontologies have been proposed [3]. Domain ontologies are formal descriptions of classes of concepts and relationships between these concepts that describe a given domain. Our previous experience with RITA [4] a requirements elicitation method that exploits a just one threat ontology, was that “being generic, the threats in the RITA ontology are not specific to the target [bank] industry” (the case study was in the banking sector). Experts involved in the evaluation complained about “the lack of specificity of the types of threats to the industry sector and the problem domain at hand”. The problem that remains open is therefore that we need to exploit both security knowledge and domain knowledge to guide the elicitation of domain-specific security requirements. Our research question is "how to combine the use of security ontologies and domain ontologies to guide requirements elicitation efficiently?" This paper presents an ongoing research project that aims to develop a method that explores the use of security and domain ontologies for SRE. The approach is generic in the sense that different security ontologies and different domain ontologies can be used with it. However it is domain specific when it is applied in the sense that during its application only one domain ontology is used.

Our method guides the discovery of security requirements for a specific domain. This process handled by a series of heuristic production rules that, starting from high level security requirements, produce a security requirements specification. Figure 1 shows an overview of our method. There are two sub-sets of rules. The first set of rules handles domain-specific analysis. The second set of rules performs a security specific analysis. Each set of rules exploits different ontologies: respectively domain ontologies and security ontologies. In order to be able to handle different security and domain ontologies, the rules were specified with so-called “upper ontologies”, that handle concepts that are (a) common to most ontologies, (b) sufficiently high level to abstract many other concepts in the specific ontologies, and (c) more importantly that represent an important subject of interest for the method.

The requirements definition process starts with the elicitation step, where stakeholders express their needs about security in non-formal sentences. Then an analysis stage is carried out to discover more requirements and express these needs in a semi-formal requirement.

During the elicitation step, an initial I* requirements model is first constructed from the stakeholders' needs and concerns expressed about security at the beginning of the project. At this stage, the analyst defines initial actors, resources, and especially security goals (integrity, confidentiality, traceability...) During the security requirements analysis stage, the production rules will exploit the security-specific ontology to discover threats, vulnerabilities, countermeasures, and resources, and thus enrich the requirements model by adding new elements (malicious tasks, vulnerability points...). During the domain specific security requirements analysis stage, another set of rules explores the domain ontology to improve the requirements model with resources, actors and other concepts that are more specific to the domain at hand; for instance: thieves in the banking domain, hijackers in the aeronautic domain, pirates in the maritime domain, etc.

The originality of the method lies: (a) in the fact that the combination of security and domain ontologies is not achieved a priori, but at runtime, while the method is applied, and (b) in the genericity of the method, in the sense that it is designed to be used with any pair of security and domain ontologies, as long as they embed some expected knowledge.

Our preliminary evaluation conducted through a small, but real, case study and through critical analysis by three experts (domain, security, requirements engineering, respectively). The evaluation shows that the method provides a good balance between the genericity with respect to the ontologies (which do not need to be selected in advance), and the specificity of the elicited requirements with respect to the domain at hand.

References

1234 564 764 89ABC9D4 E45F94 9C4 F94 C4 C4 F4 FFFC4 AC4 F94 FCC4 94D4 64 !64 "A#6$%F#A64 &A6D4 'F64 ()D4 F_{4 * +D4 64} ,-. ,/0D4F'642,,*64

1/34 864 1FBF4 C4 264 &3C9D4 7C'4 4FF3$5C4 7C6A9C#C4 7CC94 4 C4 C4 F4 C4 &C#4 8CB64 94 1CCBC4 7C6A9C#C47CC94F4%F#AC9C4&3C#44:2264/--+64 1)34 &64 ;C<4 C4 =64 7C9D4 E4;F9#<4 F9#F4 CA934 FCC4D4

4 29FCC4 F4 C4 (4 C9F4 &3#FA#4 F4 F9#FD4 %F#AC9D44%F##AF4&CA93D4:C4>F9D4:>D4?&=D4/--,D464 20)@2,(64

1(34 %64&CD4764 'D4C4864=FCD4E4?4C47 5=459C44FF34 F4 8AC4 7C6A9C#C4 7F94 4 7#94 7AC9#C4 4 C4 54 &CF94D4 4 B4 7C6A9C#C4 CFCCD4 /--064 B=7C44 D-064;94 C9F48F9F4FD4/--0D464224 2*64

1*34 764 !64 =C9FD4 &CA934 7CC994 =4 8AC4 F4 5A4 1CCBC4 19BAC4&3C#64!F48C34E4&FD4/-2-64