L’audit de sécurité informatique permet de mesurer le degré de sécurisation d’un système d’information (SI). Il en repère les failles et délivre des recommandations pour améliorer sa sécurité.
Sommaire
Pourquoi demander un audit de sécurité informatique ?
L’audit de sécurité informatique peut être demandé par une entreprise auprès de prestataires de services informatiques dans plusieurs cas :
- dans l’après-coup d’une attaque (piratage), en vue de remédier aux défauts du SI
- en prévention, pour anticiper les risques
- pour faire l’état des lieux de la sécurité du SI, et élaborer une stratégie de défense
- pour vérifier la sécurité de son SI, après l’ajout d’un nouveau composant. Cela est indispensable, avant de l’utilisation effective. Il s’agit d’un contrôle de qualité, formalisé par Deming (roue de Deming) dans son PDCA (Plan-Do-Check-Act)
Audit de sécurité informatique, pour déceler les failles d’un système
Les informations traitées par les entreprises sont souvent soumis à une GED. Et les systèmes informatiques, susceptibles d’être la proie de différents types d’attaques. L’audit de sécurité informatique intervient pour dresser le bilan d’un SI : ses points forts, et surtout ses points faibles (failles de sécurité, vulnérabilités du système).
Parmi les vices qui peuvent entraîner le succès des attaques, on notera :
- un problème de configuration serveur
- des défauts dans la structure
- un programme mal codé
Audit de sécurité et politique de sécurité
Les auditeurs interviennent dans une entreprise pour évaluer la sécurité de son SI. Ils cherchent bien sûr les failles du système, mais surtout, le résultat de leurs observations doit permettre de déterminer si ces failles sont acceptables ou non.
L’action des auditeurs, en effet, se limite à deux choses :
- vérification de la sécurité du SI et établissement des failles
- conseils pour améliorer la structure en place
Tester la sécurité de votre système d’information
Mais leur verdict n’est jamais absolu. En effet, que des failles soient ou non relevées, c’est l’entreprise elle-même qui décidera si elles sont ou non tolérables pour elle. Les faiblesses d’un SI, en effet, doivent être évaluées en fonction de la politique de sécurité de l’entreprise.
De quoi s’agit-il ? C’est le niveau de sécurité défini par l’entreprise elle-même pour son système. Tout système d’information, de fait, est soumis à des risques, des piratages, contient des failles. La politique de sécurité est le degré de dangerosité acceptable de ces failles.
Les failles détectées sont donc toujours mises en regard de la politique de sécurité. On sort alors du cadre de l’audit, et on entre dans l’analyse de risques.
En quoi consiste un audit de sécurité ?
Plusieurs étapes composent un audit de sécurité informatique.
1. Interviews
Les auditeurs commencent par s’entretenir avec tous les responsables et employés de l’entreprise auditée qui interviennent dans la sécurité du système d’information. Directeur, administrateur, mais aussi utilisateurs du SI sont interrogés par l’intervenant extérieur.
2. Tests d’intrusion
C’est le pivot central de l’audit de sécurité informatique. L’épreuve du feu, on dira.
Il s’agit d’une simulation d’attaque, attaque provenant d’une personne ou d’un logiciel. On cherche par là à détecter les failles à l’avance, avant qu’elles ne soient exploitées par une attaque réelle, et vraiment dangereuse. Les tests d’intrusion sont donc une des étapes primordiales des audits, puisqu’ils testent effectivement la sécurité du site.
Ils permettent dès lors de déceler tous les points faibles, et indiquent clairement où le bât de l’entreprise blesse.
Comme dans toute expérimentation, cependant, les tests peuvent être réalisés sous différentes conditions. On distingue 3 niveaux, qui correspondent au degré de connaissances de celui qui tente d’exploiter les failles du système.
Black box
C’est la boîte noire, ou camera oscura des tests d’intrusion en audit de sécurité.
Test d’intrusion en black box
Celui qui teste le SI ne sait rien de lui. Rien de l’intérieur du moins. Il a seulement à sa disposition le net, sur lequel il part à la recherche de toutes les informations disponibles au grand public : entreprise, employés, partenaires, positionnement et visibilité sur la toile. Mais aussi, écoute et surveillance du réseau.
Ce type d’attaque simulée est la plus extérieure. Le profil choisi pour le test est celui du pirate informatique qui ne connaît pas la boîte, n’en est pas un de ses employés.
Grey box
Grey box désigne le niveau intermédiaire des connaissances pour le test. En fait, le pirate dispose alors d’un compte utilisateur, avec identifiant et mot de passe. Il s’agit donc d’un utilisateur normal, qui se retourne contre son SI et cherche à le percer.
Des sécurités sont alors en place. L’utilisateur n’a pas accès à toutes les données, ne peut pas modifier tout ce qu’il désire dans le système. On établira donc sa marge de manœuvre et le préjudice qu’il peut porter au système, lui qui y est déjà inséré.
White box
L’auditeur dispose des informations précédentes, et d’autres encore, comme un accès au code source. Le testeur connaît déjà le système, et il cherchera directement à exploiter les failles du système.
Ces 3 degrés restent des tests, des simulations : ils ne nuisent pas à l’intégrité du système. Leur seul but est de diagnostiquer les faiblesses de l’architecture. Les testeurs peuvent y ajouter des “exploits”, c’est-à-dire des programmes destinés à montrer à l’entreprise que la faille décelée est vraiment dangereuse, “exploitable”.
3. Relevés de configuration
Il s’agit d’une autre composante de l’audit de sécurité informatique. On analyse l’architecture et les composants du SI. On relève dans le détail leurs caractéristiques, puis on les compare à des systèmes dits sécurisés, ainsi qu’à la liste des failles et faiblesses les plus courantes.
C’est durant cette observation que vont être regardés, par exemple, le degré de sécurité des mots de passe.
4. Audit de code
Les applications développées en interne par l’entreprise doivent faire l’objet d’un traitement détaillé. Elles ne rentrent pas en effet dans les failles communes associées aux applications grand public.
Cet audit de code nécessite donc de lire et comprendre le code, afin d’y déceler les éventuels défauts de programmation et différents bugs. Il représente beaucoup de travail, et peut être assisté par des outils automatisés (comme RATS). Néanmoins, si ces outils ont une valeur certaine, ils ne permettent que de faire le gros du travail. Et ils peuvent passer à côté de problèmes qu’un œil humain verrait sans effort.
Analyse du code dans l’audit de sécurité informatique
Référentiels pour audit de sécurité
Différents types de référentiels existent pour évaluer la sécurité des SI. On en retiendra 3, délivrés par 3 autorités différentes :
- COBIT (Control objectives for Information and Technology) : il s’agit d’un référentiel international pour les SI
- ANSSI (Agence Nationale pour la Sécurité des Systèmes d’Information). L’agence, française, a mis en place un référentiel pour les normes et les recommandations des systèmes d’information
- Norme ISO 27000 : norme internationale des systèmes de sécurité
Laisser un commentaire