Regardons comment sont traités les problèmes de sécurité dans un système d’information. Regardons d’abord, la version traditionnelle du traitement de la cybersécurité. L’image que tout le monde a, c’est qu’il existe un système d’information, et puis tout autour il y a un réseau, qui constitue sa périphérie, dans lequel on va placer un certain nombre de systèmes que l'on désigne par sécurité périphérique).

Par exemple l’IDS²⁾ qui veut désigne un système qui va regarder, analyser les flux pour essayer de dire « Là, peut-être qu’il y a eu une attaque ».

Un autre système, un peu plus intelligent, est l’IPS ³⁾ qui va essayer de détecter, avant même que l’attaque n’ait lieu, un début de construction d’attaque.

Tout un système qui lui regroupe pratiquement les deux premiers et qui fait un travail plus intelligent, est le SIEM⁴⁾. Ce dernier va analyser tous les événements pour essayer de les comparer avec des évènements déjà passés ou anticipés. C’est dans ce type de système où parfois on intègre des systèmes intelligents qui construisent, par exemple, des profils d’attaquants pour essayer de détecter le plus tôt possible des attaques.

Après, il y a tout ce qui est Firewall qui consiste à réguler les accès à notre système ou les WAF qui sont l’équivalent de Firewall mais pour la communication entre applications internet.

C’est donc tout ce qui constitue la sécurité périphérique. C’est vrai que la sécurité périphérique est importante. Elle est importante pour les systèmes qui existent déjà, qui ont leurs vulnérabilités et qu’on ne peut pas modifier.

Ainsi, cela correspond à une approche de la sécurité qui est, plutôt, réactive que préventive. Mais réagir veut souvent dire trop tard, parce que l’attaque a déjà eu lieu. On peut parfois avoir une réaction assez rapide pour éviter qu’il y ait des dégâts. Mais souvent on se rend compte de l’attaque un peu trop tard et les dégâts sont déjà là.

L’objectif de l'approche préventive est de sécuriser le logiciel lui-même. Cela implique d’être capable de comprendre ce que sont les vulnérabilités, de les identifier et d’estimer les risques encourus pour chacune d’elles. Ce dernier point est important, car parfois certaines vulnérabilités peuvent n’induire aucune conséquence. Dans ce cas, la vulnérabilité ne représente qu’un risque potentiel avec une faible probabilité qu’elles puissent être exploitée par les attaquants. D’où l’intérêt de l’estimation du risque au regard du coût induit par la correction de la vulnérabilité.

La meilleure manière d’éviter de laisser des vulnérabilités dans le code logiciel, est d’avoir des bonnes pratiques de développement et être capable de vérifier leur bonne application. L’objectif de tout cela est d’arriver à permettre le fonctionnement de logiciels dans des environnements dits hostiles. Sachant que des environnements non hostiles il n’en reste pas beaucoup.

Tout cela pour dire, que dans la vision préventive, contrairement à la vision réactive - qui consiste à ajouter des fonctionnalités -, la sécurité est considérée comme étant une propriété non fonctionnelle du logiciel. Ainsi, la sécurité d’un système ne dépend pas de l’ajout de fonctionnalités, mais c’est une propriété qui lui est inhérente. Le système doit être sécurisé, comme il doit être maintenable. Avant on parlait de maintenabilité pour diminuer les coûts d’un système, on parle de système agile pour qu’il puisse s’adapter à différentes situations, il doit être sécurisé pour inspirer une confiance.

C’est aussi ce qu’on appelle informatique de confiance.

Regardons l’ensemble des bonnes pratiques qui vont nous permettre d’atteindre cette sécurité préventive :

• Connaître les vulnérabilités pour les éviter : tout le monde parle, bien sûr, du top 10 OWASP, mais dans ce top 10, on va trouver les vulnérabilités qui ont été les plus exploitées, mais liées à des domaines applicatifs très différents. Donc, pour un concepteur qui construit son système, il ne sera pas concerné par l’ensemble des vulnérabilités qui sont dans le top 10. De plus, il peut être concerné par d’autres vulnérabilités qui se trouvent loin dans le classement. Parfois même, la vulnérabilité qui est la plus risquée pour son propre système, parce que c’est celle qui engendre le plus de dégâts, se trouve très loin dans le classement.
• Spécifier le besoin de sécurité : on a déjà parlé des propriétés de sécurité et qu’il faut trouver un équilibre entre elles. Il faut donc être capable de savoir quels sont les éléments qui nécessitent la sécurité et avec quelles propriétés et quel est le bon équilibre pour bien spécifier ce besoin de sécurité. Puis, évaluer les risques résiduels. C’est à dire qu’on peut considérer que, par certains aspects, le système n’est pas forcément très bien sécurisé et on ne peut pas faire autrement. Dans ce cas, il faut être capable d’anticiper la chose et d’évaluer les risques et de présenter l’évaluation de ces risques aux décideurs pour qu’ils prennent leurs responsabilités.
• Établir un plan de tests de sécurité : ce plan doit être réalisé avant même d’avoir construit le système. Les tests sont à réaliser tout au long du cycle de vie de développement du logiciel. En effet, à chaque étape il y a des traitements spécifiques qui nécessitent des tests spécifiques. De plus, cela aide à construire un jeu de tests le plus complet possible.
• Faire une relecture croisée du code : c’est une relecture de code croisée, dans le sens où chaque équipe de développement relie le code de l’autre. Pourquoi croise-t-on la relecture ? Regardez, par exemple, quand vous envoyez un mail, vous avez beau le relire, le récepteur a plus de chances que vous d’y trouver des erreurs d’orthographe. Cela ne veut pas dire que vous êtes moins bon que le récepteur en orthographe ! Cela est dû au fait que quand vous écrivez votre mail, votre principale préoccupation est de transformer votre image mentale en représentation textuelle. Par contre, le récepteur il doit construire une image mentale à partir du texte. Il va donc analyser plus précisément le texte, pour se construire cette image mentale, et c’est ce qui lui permet de voir les erreurs auxquelles vous n’avez pas fait attention. C’est le même cas pour le développement, qui en plus est concentré sur comment résoudre le problème. Celui qui relis le code n’a pas à construire la solution : elle est là. Il va chercher à la comprendre et c’est ce qui va lui permettre de trouver les erreurs laissées par le programmeur.
• Jouer le plan de test : construire un plan test c’est une chose, être capable de le jouer est un atout. Pour pouvoir jouer les tests, il faudra prévoir des moyens, de la planification, de l’organiser et montrer à quel point votre façon de jouer le test couvre les objectifs prévus.
• Réaliser les tests d’intrusions : quand vous avez fini de construire votre système, vous allez le déployer avec tout une architecture de déploiement. Cette architecture de déploiement va ajouter des possibilités aux attaquants et qui risque de mettre en évidence des vulnérabilités qui étaient minimes au départ et qui sont exposées de manière excessive à travers l’architecture. C’est le cas des vulnérabilités qui ne sont détectables qu’à l’exécution. De plus, l’architecture de déploiement, elle-même, peut avoir des vulnérabilités. Avec les tests d’intrusions, on va se mettre à la place de l’attaquant et attaquer son propre système pour essayer d’identifier ses vulnérabilités dans son environnement d’exécution.
• Enfin, ne pas oublier une activité, qui est pas mal utilisée dans le monde de la qualité logicielle, qui consiste prendre des métriques sur le logiciel. Les métriques doivent être prises à tous les niveaux et à chaque étape du développement logiciel. Ce sont des informations très précises sur notre logiciel, qui peuvent nous renseigner sur sa qualité, mais aussi sur les potentiels vulnérabilités qu’il peut contenir.

◁ Précédent | ⌂ Sommaire | Suivant ▷