# Projet 3A

## Jalon 1 : Dossier d'étude de risque avec planning

### Présentation du sujet

Le nombre de cyberattaques ne cesse d'augmenter, ciblant les gouvernements ainsi que les secteurs publics et privés. La plupart de ces attaques utilisent des programmes malveillants appelés **[malwares](#glossaire)** pour infecter les victimes.

Pour répondre à ces problèmes, le commerce antiviral n'a cessé de se développer depuis plusieurs années. Cependant, un antivirus ne peut détecter que ce qu'il connaît et la détection antivirale étant un problème sans solution, les antivirus ne sont qu'une barrière ralentissant les attaquants. La question à laquelle les antivirus doivent répondre est la suivante : *comment distinguer un malware d'un programme légitime* ?

En effet, un malware par définition est un programme informatique créé à des fins malveillantes. Cependant, il semble tout à fait possible d'atteindre un objectif malveillant en ayant uniquement recours à des **[briques légitimes](#glossaire)**.

Ce type de d'application va notamment chercher à utiliser les autres programmes qui eux sont légitimes, pour dissimuler ou effectuer des actions que ces derniers ont le droit de réaliser. Finalement, ces malwares détourneront des règles de sécurité contre l'OS.

Ainsi, nous avons défini avec notre client Eric Filiol le sujet suivant :

> Evaluation des risques liés à un malware mutualisant des ressources légitimes d'un système.

Les objectifs de cette évaluation sont présentés dans la section suivante.

### Objectifs

1) Développer au moins un programme informatique malveillant, reposant sur des couches applicatives légitimes;
2) Identifier une méthode (voire développer un outil) de détection de l'attaque précédente.

### Planning prévisionnel

* Etat de l'art : définition de briques légitimes pouvant être exploitées à des fin malveillantes;
* Mise en place de l'environnement d'analyse de malware;
* Développement des malwares;
* Identification des potentiels moyens de détection desdits malwares;
* Implémentation d'outils de détection.

gantt
dateFormat DD-MM-YYYY
axisFormat %d-%m
title Jalon 1
%% commentaire


section  
Livrables (diaporama, étude de risques): s1t1, 10-09-2021, 16d
Etat de l'art (jalon 2) : s1t2, 10-09-2021, 16d
Mise en place de l'environnement d'analyse de malwares : s1t3, 10-09-2021, 15d
Proposition d'une date de présentation au client : crit, s1t4, 20-09-2021, 5d
Prendre RDV avec Vincent Corleau : crit, s1t5, 20-09-2021, 5d
Envoyer un mail à Y. Prioux (gitlab): crit, s1t6, 20-09-2021, 5d
Présentation client 1 : s1t7, after s1t1, 1d

gantt
dateFormat DD-MM-YYYY
axisFormat %d-%m
title Jalon 2
%% commentaire


section  
Diaporama : s1t1, 04-11-2021, 26d
Ebauche de publication : s1t2, 04-11-2021, 26d
Démonstrateur : s1t3, 04-11-2021, 26d
Guide de déploiement : s1t4, 04-11-2021, 26d

### Organisation de l'équipe

Notre équipe est composée de quatre membres :

* Amaury Bonnaud ;
* Jean Jestin-Scanvion ;
* Timothé Pouyet ;
* Maxime Buridant.

Pour mener à bien notre projet, nous allons utiliser un framework **[[1]](#bibliographie) Scrum**, qui met en œuvre les principes de la méthode Agile sous la forme d'un ensemble concret d'**artefacts**, de pratiques et de rôles.

Le diagramme ci-dessous détaille le cycle de vie itératif de [Scrum](#glossaire). L'ensemble du cycle de vie est réalisé dans des périodes de temps fixes appelées **sprints**. Un sprint dure généralement de deux à quatre semaines :


Dans le cadre de notre projet, nous allons adapter le framework scrum pour gagner en flexibilité. Concrètement, les rôles seront répartis comme suit :

| Rôle | Responsable(s) |
|--------------------------------------------------------------------------------------------------------------------|-------------|
| **Product owner** : responsable du produit et de la mise à jour du Backlog (tâches et priorités) | Eric Filiol |
| **Scrum master** : à la fois coach et membre de l'équipe, il vérifie que les règles de Scrum sont bien appliquées | Jean |
| **Scrum team** : équipe responsable du développement du produit et de sa qualité | Jean, Amaury, Timothé et Maxime |

Table: Rôles et organisation de l'équipe

En ce qui concerne l'organisation et les livrables, nous allons procéder comme suit :

| Pratiques & Artefacts | Description |
|-------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| **Product Backlog** : liste priorisée des actions à réaliser pour obtenir le produit final | Définition du besoin, des attentes et des objectifs à atteindre (le document présent) |
| **Sprint Planning / Backlog** : liste des actions sélectionnées pour le sprint à venir | Durée d'un sprint définie : 1 semaine |
| **Sprint Review / Retrospective** : retour d'expérience sur le sprint, les points positifs, négatifs et bloquants | En fin de semaine pour l'équipe et toutes les deux semaines avec le client/Product Owner |
| **Shippable Increment** : livrable opérationnel en fin de sprint | Livrable toutes les deux semaines avec le client/Product Owner |

Table: Méthode de travail et livrables

### Axes de développement et de recherche

Nous avons identifié plusieurs axes de développement et de recherche concernant notre projet :

1. Amélioration du malware **[[2]](#bibliographie) Bitlocker**. Le code source fourni correspond à un cryptolocker utilisant *[bitlocker](#glossaire)* pour chiffrer tous les disques montés sur le système. Dans cette première partie, nous nous proposons d'étudier et d'analyser ce code. L'objectif est d'identifier les faiblesses du système et les mécanismes utilisables par les malwares de ce type pour dans la partie suivante remédier à ces failles.
2. **Détection du malware bitlocker**. Après avoir découvert les points critiques permettant au cryptolocker d'être plus efficace, nous tenterons de mettre en place des moyens de détection et de prévention qui pourraient être utilisés par les antivirus pour se prémunir de ce type de malware.
3. **Création de nouveaux malwares basés sur des briques légitimes du système d'exploitation Windows** (autres que BitLocker). Après avoir amélioré et détecté le malware basé sur bitlocker, nous avons pour objectif d'en développer de nouveaux qui seront basés sur des briques légitimes du système Windows (UEFI, GPO, etc.).
4. **Détection des différents malwares précédemment créés**. Après avoir développé de nouveaux malwares basés sur des briques légitimes du système d'exploitation Windows, nous essayerons de mettre en place des moyens de détection et de prévention que les antivirus pourraient utiliser.

### Liste des moyens nécessaires

Dans cette partie, nous listons les différentes ressources dont nous aurons besoin pour mener à bien la réalisation de notre projet :

* Nous avons besoin d'un git pour développer de façon collaborative. De plus, par souci de confidentialité, il serait préférable de posséder une solution privée qui pourrait être hébergée à l'ENSIBS par exemple. Une solution pourrait être un **Gitlab** privé, éventuellement accessible depuis internet afin de pouvoir travailler aussi en dehors de l'UBS. Pour ce point, il existe une forge UBS Gitlab sur laquelle il est possible d'héberger notre projet Git. Toutefois il reste à vérifier la possibilité de créer un dépôt **privé**.
* Une ou plusieurs **machine(s) virtuelle(s)** possédant des ressources suffisantes pour nous permettre d'installer et d'utiliser les outils nécessaires à l'analyse de malware (Flare, désassembleurs, débugeurs, antivirus...). Il sera aussi intéressant de pouvoir restaurer facilement des sauvegardes (snapshot) de la machine virtuelle afin de pouvoir tester nos charges.

### Etude des risques du projet

A présent, nous présentons tous les risques qui pourraient compromettre le bon déroulé et l'avancement du projet :

* Fuite du code source ou de binaires (exemple : emploi de virus-total résultant d'une détection antivirale);
* Impact non maîtrisé du malware (exemple : exécution non désirée sur nos ordinateurs personnels);
* Manque de ressources;
* Complexité du sujet.

Les principaux risques étant identifiés, voici une liste d'action à mettre en place pour prévenir la réalisation de ces risques et/ou y faire face :

* Utilisation de machines virtuelles strictement isolées (hors-ligne et aucune interaction entre machine hôte et machine virtuelle)
* Identification d'experts dans le domaine pour pouvoir les contacter au besoin.
* Travail de veille et d'état de l'art pour constituer un solid ensemble de ressources utiles.

### Bibliographie

[1] mijacobs, « What is Scrum? - Azure DevOps ». https://docs.microsoft.com/en-us/devops/plan/what-is-scrum (consulté le sept. 17, 2021).
[2] Dansimp, « BitLocker (Windows 10) - Microsoft 365 Security ». https://docs.microsoft.com/fr-fr/windows/security/information-protection/bitlocker/bitlocker-overview (consulté le sept. 16, 2021).

### Glossaire

*Bitlocker* : Le chiffrement de lecteur BitLocker est une fonctionnalité de protection des données intégrées au système d’exploitation Windows. Il permet de prévenir le vol ou l’exposition de données provenant des ordinateurs perdus, volés ou mis hors service de façon inappropriée.

*Brique légitime* : Ce terme désigne un composant du système ayant une fonction reconnue non malveillante.

*Malware* : Ce terme générique désigne tous les types de logiciels informatiques ayant des intentions malveillantes.