Risk Analysis Support Tool


OSAR is a student project launched in 2017/2018 in collaboration with a security risk expert from Orange Cyberdefense. Risk analysis experts' role is to audit customers' companies and to analyse their IS (information system). They take notes of board expectations about the assets whose security and safety they want to ensure and study in detail the supports through which theses assets may transit.

The project goal is to implement a software tool allowing to input information system architecture which he studies as well as the vulnerabilities which the different equipments could face. The OSAR software outputs the most sensible attack paths and thus helps the client to identify the system's components where appropriate coutermeasures should be put in place.




The three analysis methods result from decades of scientific investigations and practical, industrial experience. EBIOS allows us to analyze and locate the most sensitive points of a system. It gives also a way to link the assets with their supports. We depict these links using an attack tree which permits us to provide a graphical representation of the attack scenarios and helps us to quantify them. Thanks to the Common Criteria, we can valuate this tree and determine the system's vulnerabilities according to the desired security criteria.


The OSAR team in 2017/2018 is composed of eight students of INSA Rennes. At the first semester, the team studied the context and wrote some documents including functional specifications and a planification report. At the second semester, the team realized the software tool and presented it to its client.

Raphaël GILLET
Mathieu THÉ


Expression of Needs and Identification of Security Objectives (EBIOS) is a method of risk analysis. It means that EBIOS must be performed before a project or service creation and allows to identify and rank the underlying vulnerabilities in order to propose suitable countermeasures.

EBIOS consists of five modules. The main steps of this methodology are:

  1. study of functional and technical context;
  2. expression of security needs;
  3. study of threats (functional and technical ones) to the audited perimeter;
  4. expression of security objectives;
  5. determination of security requirements.

The first module, context, consists in defining the working context with the client. The latter delimits a perimeter for the risks analysis. The first module is the core strength of EBIOS method because it allows the approach to adapt to the company's context and to be ajusted to its tools.

The second module, feared events, focuses only on assets (information, data, service, etc.) which we seek to protect. This security need is expressed through the standard security criteria: confidentiality, integrity and availability (CID). It is necessary to identify the assets, estimate their values, highlight threat sources (dangerousness and likelihood) and show the impacts (economic, legal, etc.) on the enterprise if the security needs are not fulfilled.

The third module, threat scenarios, of the EBIOS methodology focuses on supporting goods. These are the "real/physical" components that carry the assets. Supporting goods are analysed concreately through their architecture, their flow... and the corresponding threats and their sources are identified.

The fourth module, risks, aims to enumerate the feared events.

The last module aim, security measures, is to provide countermeasures to risks identified before in order to reduce the likelihood of the risks and their impacts.


Common criteria

Common criteria are born from the need of uniformization in the risks analysis world. In the 80s and 90s, several countries began to develop risks analysis methodologies. The issue was that a certified system that respect security norms defined by a method, was not necessarily admitted in countries using a different norm. Moreover it was hard to compare softwares to certify between them because the certification norm used was often different. From this uniformization wish, has resulted the ISO-15408 norm, also known as Common Criteria, admitted by 17 signatory countries, which can certify systems.

Common criteria are described according to three documents. The first one is the introduction, it introduces the two others documents and how Common criteria works. It explains the method but does not clarify explicitly how to implement it. The second document introduces the functional requirements, and the third the criteria in terms of security insurance.

For this project we use one specific part of common criteria: the attack potential. The attack potential belongs to the vulnerabilities evaluation done by the common criteria for the requirement of security insurance. This evaluation takes place in 3 steps:

  • identification of concerned areas: the evaluater seek in system areas that he considers needed to check the vulnerability and he will make researches on conception, architecture of thoses areas to gather information;
  • vulnerabilities search: this part consists in searching in concerned areas possible vulnerabilities by resting on common knowledge and on gathered information analysis;
  • hypothesis check: we check in the vulnerabilities list if they can be applied to the system environment, if they can be used to attack.

Finally a list of vulnerabilities is established. From this list, attack scenarios are established for each vulnerability to then calculate attack potential. The latter corresponds to a numeric value computed from a scenario that exploits a flaw. The scenarios are decomposed in two parts: identification and utilization. To allow to valuate these two steps we sum up the values attributed to the five following factors:

  • time spent: time needed to do this step;
  • knowledge required: level of knowledge required to do this step;
  • target system knowledge required: knowledge that the attacker must have on the system to do this step;
  • opportunity window: window required before being countered or discovered for the attack to be successful;
  • equipment needed: correpond to software or equipment needed.

Thus, for the two steps that are part of a scenario, we sum up the values attributed to each factor. To end we do the sum between the two steps to obtain the attack potential of a given scenario.


Attack Trees and ADTool

The attack trees provide a representation of attack scenarios. The root represents the final goal of the attack, the different nodes are intermediate goals and leaves are elementary actions to be performed. These actions will be valuated by the attack potential, given by the common criteria.
Attack trees make use of three types of nodes:

  • disjonctive node OR: the logical OR, i.e. in order to achieve the node, at least one of its children must have been achieved;
  • conjonctive node AND: the logical AND. For its achievement, all its children have to be achieved;
  • sequential conjonctive node SAND: for its achievement, all its children has to be achieved in a sequential order, i.e. children are achieved one after another in the given order.

Depending of those nodes, leaves values will climb up to obtain the attack potential of the root.

To ADTool

ADTool is a software that enables the creation, edition and display of attack trees. It allows to valuate leaves and propagate the values in the bottom-up way up to the root of the tree. In our project, ADTool is used to display the attack trees generated by OSAR.

Example of a generic tree created by OSAR and displayed by ADTool: