EBIOS

---

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:

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.

Close

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.

Close

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:
Close