Politique de sécurité informatique

La sécurité informatique consiste en un ensemble de stratégies mises en place pour gérer
les processus, les outils et les politiques nécessaires afin de prévenir, détecter, documenter
et contrer les menaces aux informations numériques et non numériques des utilisateurs des
systèmes informatiques (Rouse, 2016).
De nos jours, la sécurité informatique est devenue une question primordiale qui préoccupe
beaucoup de gens. L’adoption accrue de celle-ci dans des secteurs à sensibilités élevées tels
que les gouvernements, et les banques a fait en sorte que son marché a gagné rapidement du
terrain au fil des années.
En effet, pendant les 13 dernières années, le marché de la sécurité informatique a été multiplié
environ 35 fois. En 2004, il valait 3,5 milliards de dollars, tandis qu’en 2017 ce nombre s’est
accru à plus de 120 milliards de dollars (Morgan, 2017).
Malgré l’ampleur de ce marché et les avancées atteintes dues aux travaux réalisés depuis au
moins 40 ans dans ce domaine, la sécurité de centaines de millions de systèmes informatiques
déployés reste faible. En effet, à ce jour n’importe quel attaquant motivé et compétent peut
détruire ou voler des informations de presque tout système informatique connecté à un réseau
(Lampson, 2004). Pire encore, l’attaquant pourrait faire cela à des millions de systèmes à la
fois.
Au cours des dernières décennies, l’amélioration des technologies de communication numérique
a rendu l’application de la sécurité informatique encore plus difficile qu’elle ne l’était
déjà. Auparavant, un système informatique avait au plus quelques douzaines d’utilisateurs,
tous membres de la même organisation. Les utilisateurs exécutaient des programmes écrits
en interne ou produits par quelques fournisseurs. Aujourd’hui, avec la décentralisation du
processus de développement des logiciels, et la pratique du téléchargement des programmes
informatiques depuis des sources inconnues (dans le but de les utiliser et les exécuter localement
sur des machines personnelles), des logiciels malveillants ou « malware » sont apparus
sur la toile. Ce type de logiciel circulant sur Internet menace la sécurité des utilisateurs du
réseau.
Dans ce contexte, un logiciel malveillant désigne tout programme ou fichier nuisible pour l’utilisateur
d’un ordinateur. Les logiciels malveillants comprennent les virus, les vers, les chevaux
de Troie, ainsi que les logiciels espions (des programmes qui recueillent des informations sur
un utilisateur sans y être autorisés) (Rouse, 2017).
Selon McAfeeLabs, plus de 150 millions de nouveaux codes malveillants ont été créés en
2017 (McAfeeLabs, 2017), ce qui représente une augmentation de 25% par rapport à 2016.
Compte tenu de ces chiffres, la détection des codes malveillants est clairement devenue un
Problème important. Ceci implique la nécessité de trouver des moyens afin de se protéger des
dommages que peuvent causer ces derniers et garantir l’intégrité des systèmes informatiques.
Le paradigme du code mobile malveillant ou « malicious mobile code » (MMC) englobe les programmes qui peuvent être exécutés sur un ou plusieurs hôtes autres que celui dont ils
proviennent. La mobilité de tels programmes implique une capacité intégrée permettant à
chaque morceau de code de circuler facilement d’un hôte à l’autre. Un code mobile est associé
à au moins deux parties, son producteur et son consommateur, le consommateur étant l’hôte
qui exécute le code.
Pour la prévention des attaques des codes malveillants la pratique du codage sécuritaire a vu
le jour. Cette technique consiste à développer des logiciels informatiques sûrs de manière
à prévenir l’introduction accidentelle de vulnérabilités de sécurité. En effet, les défauts, les
bogues et les failles logiques sont systématiquement la cause principale des vulnérabilités
logicielles couramment exploitées (Viega et McGraw, 2001).
Lors de la conception de systèmes informatiques, les développeurs essayent de prévoir toutes
les possibilités d’attaques potentielles. Le système doit répondre à des spécifications qui
permettent de le protéger contre les menaces ; ces spécifications sont appelées propriétés de
sécurité. Couvrir toutes les failles possibles est quasiment irréalisable du fait que des nouvelles
techniques d’attaques et des nouvelles failles de sécurité apparaissent en continu, ce qui met en
échec ce principe (Evans et Twyman, 1999). Comme exemple de propriété de sécurité, dans la
programmation Java, la méthode java.lang.Object.equals() est incapable de comparer
des objets composites tels que les clés cryptographiques. Les classes de clés ne fournissent pas
une implémentation de la méthode equals() qui surcharge Object.eqauls(). Dans un tel
cas, les composants de l’objet composite doivent être comparés individuellement pour assurer
l’exactitude du résultat de la comparaison (Long et al., 2013).
Il y a eu une quantité importante de travaux sur des techniques et des outils pour la détection
des codes malveillants et des défauts logiciels. Les solutions existantes pour analyser et détecter
les codes malveillants dans un programme se divisent en deux catégories : des analyseurs statiques et des analyseurs dynamiques. Les analyseurs statiques sont capables de détecter
les défauts dans le code source sans l’exécuter. En revanche, les analyseurs dynamiques
doivent exécuter le code pour détecter les défauts. Aucune de ces méthodes ne peut arrêter
efficacement les codes malveillants ou les logiciels malveillants. Étant donné que les outils
antivirus existants sont basés sur la signature, il existe toujours un intervalle de temps entre le
moment où un code malveillant apparaît pour la première fois et le moment où la signature
correspondante qui permet de le détecter est dérivée et distribuée aux utilisateurs. Pour les
logiciels malveillants tels que le ver SQL Slammer (Moore et al., 2003), tout écart de plus de
quelques heures est inacceptable, car un ver bien conçu peut neutraliser Internet en quelques
heures. De ce fait, l’importance de la détection précoce des failles, ainsi que de permettre
aux développeurs d’ajouter de nouvelles propriétés et signatures sans présenter des efforts
considérables pendant la phase des tests de sécurité dans le processus de développement des
logiciels, est un fait bien établi (Lam et al., 2006). En conséquence, des outils d’analyse de
code source, également appelés outils SAST (« Static Application Security Testing ») sont
conçus pour aider les développeurs à analyser leurs codes source et / ou les versions compilées
du code afin de détecter les failles de sécurité.
La vérification des propriétés spécifiées par rapport à l’exécution de systèmes ou de programmes
est un sujet ancien, dont les racines précises sont difficiles à identifier. En 2001
premier un atelier visant à traiter les problèmes à la limite entre la vérification formelle et
les tests a introduit officiellement la terminologie du « runtime verification » aussi appelée «
runtime monitoring ».
Le « runtime monitoring » (la surveillance au moment de l’exécution) permet l’analyse de
l’exécution d’un système informatique en se basant sur l’extraction des détails sur son exécution,
et les utilise pour détecter et réagir à un comportement satisfaisant ou violant une certaine
propriété au moment de l’exécution (Leucker et Schallhart, 2009). Cependant le « runtime monitoring » utilise les ressources partagées du système sur lequel le moniteur est exécuté, ce
qui pourrait causer une diminution des performances de celui-ci.
Chaque événement extrait de l’exécution est analysé avant qu’il soit exécuté, ce qui peut
affecter la vitesse et ralentir le fonctionnement du programme. Le monitoring ne devrait pas
causer la surconsommation des ressources.
Plusieurs outils adoptant cette technique ont été développés. Parmi eux, un moniteur extensible
et léger appelé BeepBeep a été développé par Hallé en 2015. BeepBeep permet la vérification
d’une spécification donnée par un programme informatique au fur et à mesure de son exécution.
par exemple, les messages envoyés ou reçus par l’application peuvent être vérifiés par cet outil
en se basant sur une spécification donnée en tant que propriété de sécurité (prédéfinis sous
forme de contraintes) (Hallé, 2015). Ce moniteur a la spécificité de se présenter comme un outil
facile à manipuler : il permet d’ajouter, modifier, ou supprimer facilement des spécifications
au système surveillé.
La sécurité d’un programme informatique a traditionnellement été modélisées comme un
prédicat spécifiant si le programme sous analyse est sécurisé ou non-sécurisé. Un programme
est sécurisé seulement s’il respecte toutes les propriétés de sécurité prises en compte par le
système de sécurité. Dans le cas contraire, il est considéré comme étant non sécurisé. En 2015,
Ray et Ligatti généralisent le modèle qualitatif de la sécurité à un modèle quantitatif. Au lieu
de spécifier si les systèmes sont sécurisés, les politiques grises précisent comment sont les
systèmes sécurisés (Ray et Ligatti, 2015). Autrement dit, on aborde la question d’offrir plus
de flexibilité à l’utilisateur d’un système informatique en lui rendant possible la spécification
de ces besoins en termes de sécurité. De même lors de la phase des tests dans le processus
de développement des logiciels informatiques, les développeurs chargés des tests doivent
avoir la possibilité de choisir les propriétés de sécurité à appliquer pendant l’analyse du
programme selon leurs besoins, par exemple dans le cas ou un développeur désire analyser si
un programme se connecte au réseau, il n’a pas à analyser toutes les propriétés existantes dans
le moniteur. Cela impliquera des coûts en argent et en temps d’exécution superflus.
Dans notre travail de recherche, nous nous proposons de répondre à la question de suivante :
est-il possible de développer un modèle flexible et extensible permettant de détecter les
violations aux propriétés de sécurité dans un programme informatique Java en utilisant l’outil
de « runtime monitoring » BeepBeep?
Dans le but d’implémenter un système d’analyse des violations des propriétés de sécurité
des programmes Java au moment de l’exécution, nous commençons par concevoir un modèle
comportant des mécanismes appropriés qui permettent l’instrumentation du programme et la
détection des violations des propriétés de sécurité.
Pour l’instrumentation, AspectJ, une extension dédiée à la programmation orientée aspect a
été utilisée pour insérer du code aux points que nous définissons dans un programme Java et
qui se présente comme un outil très utile pour le «runtime monitoring».
Dans une seconde étape, nous définissons un ensemble de propriétés de sécurité susceptibles
de menacer un système informatique. Nous implémentons ces spécifications avec l’outil de
« runtime monitoring » BeepBeep, de façon à permettre la détection des violations de ces
propriétés au moment de l’exécution. En 1999, Evans et Twyman ont proposés une approche
pour la sécurité du code. Ils ont présenté une architecture système appelé Naccio qui offre
une large classe de propriétés (restrictions) de sécurité. Ces propriétés constituent la base du
travail. Nous ajoutons ensuite des propriétés plus complexes, non prises en compte par Naccio, cette base afin de démontrer la fléxibilité de notre approche.
Pour la validation, nous implémentons Stethoscope, un nouveau moniteur d’exécution qui
adopte le modèle porposé et qui permet de détecter les violations des propriétés de sécurité
choisies par l’utilisateur dans les programmes et applets Java. Il permet aussi d’ajouter,
modifier, et supprimer les signatures associées à ces contraintes.
Comme dernière étape, nous étudions l’impact du fonctionnement du moniteur sur la performance
du système surveillé et sur l’utilisateur du moniteur. Ce dernier ne doit pas nuire
à l’exécution du programme sous surveillance et ne doit pas présenter des difficultés a être
manipulé.
Par le modèle proposé dans notre approche, on sépare les spécifications de la façon dont
les systèmes sécurisés sont de la façon dont les utilisateurs sécurisés exigent que leurs systèmes
soient. Cette séparation permet aux utilisateurs de spécifier des exigences de sécurité
différentes.
On peut conclire que la facilité de manipulation et l’extensibilité qu’offre BeepBeep donne aux
u tilisateurs du moniteur la capacité d’étendre la plage de propriétés de sécurité sans difficulté.
Par le « runtime monitoring » on automatisera l’analyse des programmes au moment de
l’exécution. Il n’y aura besoin de l’interaction de l’utilisateur que pour spécifier les contraintes
de sécurité souhaitées, notre application sélectionnera automatiquement l’événement et l’analysera.
Ce mémoire est organisé en cinq chapitres :
Nous commençons par définir les notions requises à la bonne compréhension de notre travail
de recherche dans le premier chapitre, qui donne une introduction au monde de la sécurité du code, ainsi qu’au domaine du « runtime monitoring ».
Le deuxième chapitre dresse un état de l’art dans le domaine de l’analyse des codes malveillants
dans la sécurité du code qui permettent d’apprécier le niveau d’avancement et la contribution
de notre technique.
Dans le troisième chapitre, nous abordons plus en profondeur le principe et l’architecture de
notre approche. Nous décrivons son fonctionnement, les différentes étapes d’implémentation
pour son intégration au code, ainsi que la façon de l’appliquer et l’utiliser pour écrire des
spécifications. À partir de ces informations, il sera possible d’intégrer cette solution à notre
champ d’intérêt. Ici le fonctionnement du moniteur BeepBeep est formulé ainsi que la méthode
d’instrumentation de ce dernier via AspectJ.
Dans le quatrième chapitre, nous décrirons les propriétés de sécurité sélectionnées dans notre
base de propriétés de sécurité. Ensuite nous expliquons la conception et l’implémentation de
celle-ci. Nous commençons par des propriétés simples, puis, pour montrer la puissance de
notre approche, nous abordons des propriétés plus complexes.
Dans le cinquième chapitre, afin d’expérimenter notre approche, nous proposons Stethoscope,
un nouvel outil de détection des violations des propriétés de sécurité dans les programmes
Java construit autour de l’outil de traitement d’événement de flux BeepBeep. Par la suite, nous
testons notre moniteur sur des programmes téléchargés sur Internet et analysons les résultats
obtenus en vue de prouver l’efficacité de notre approche.
La conclusion résume notre contribution au domaine de la sécurité du code et de la vérification
des programmes donne nos perspectives et nos pistes de recherche futures.
La majorité des travaux entrepris dans ce mémoire ont été publiés dans l’article suivant dont
je suis le premier auteur :

Leave a Reply

Your email address will not be published. Required fields are marked *