L’audit de sécurité
9 février 2024Aujourd’hui, il est pratiquement impossible pour une entreprise de travailler sans systèmes d’informations ni connexions à Internet. Pourtant ces deux éléments essentiels sont potentiellement porteurs de risques importants concernant la disponibilité, l’intégrité et la confidentialité des données et des systèmes.
En effet, les menaces peuvent tout aussi bien être extérieures qu’internes comme nos collègues viennent de vous le montrer. Pour pouvoir se protéger de ces attaques, il est nécessaire de s’assurer de la sécurisation du système d’information.
Pour cela, il est conseillé de recourir à un audit de sécurité qui permet d’éprouver le niveau de sécurité d’un système informatique en mettant en évidence les forces et surtout les vulnérabilités de l’infrastructure, des logiciels ou des moyens humains en se reposant sur l’expression des besoins et l’identification des objectifs de sécurité (méthode EBIOS).
Il est fortement recommandé par l’ANSSI de faire appel à un intervenant extérieur spécialisé pour ne pas risquer de fausser les résultats. En effet une personne connaissant l’infrastructure aura déjà une idée de ses forces et faiblesses et risque de passer à côté de certaines failles de sécurité.
En faisant appel à un prestataire de service un contrat définissant clairement les limites de l’audit doit être conclut. Toute tentative d’intrusion effectuée qui sort de cet accord est illégale est peut être passible de poursuites judiciaires.
Quel sont les types d’audit ?
Il y a trois types d’audit :
White Box: le pentester a accès à la totalité des informations concernant le système. Le testeur travaille dans ce cas en collaboration avec les équipes techniques de l’organisation afin de récupérer un maximum d’informations utiles. Il a accès à tout ce dont il a besoin afin de détecter un maximum de vulnérabilités.
La méthode en White Box est utilisée lorsqu’une entreprise veut arriver à déceler la moindre faille et vulnérabilité de son système d’information.
Les seules limites à l’approche en mode White Box sont les compétences du pentester choisi et la perpétuelle chasse aux nouvelles techniques de hacking qui évoluent chaque jour.
Black Box: le test consiste à réussir à s’introduire dans un système (la boîte) sans avoir la moindre information, tel un hacker découvrant pour la première fois ce système. Le pentester n’a alors aucune connaissance de l’environnement et teste à l’aveugle. Depuis l’extérieur, son objectif est donc de trouver comment s’introduire dans le système cible comme un attaquant extérieur pourrait le faire.
Les tests en black box sont le plus souvent utilisés tout simplement sur des sites vitrines, sans espace membre car aucune information supplémentaire utile ne permettrait au hacker d’aller plus loin dans la démarche de cette attaque.
Le test en black box permet donc de montrer au client quels types d’informations le hacker serait capable d’obtenir et ainsi de mettre en avant les risques encourus dans le cas d’une attaque.
Le test en boite noire aura tendance à être plus long que si le pentester a déjà quelques informations supplémentaires. Il se peut également qu’il n’arrive pas à s’introduire dans le système, ce qui ne prouve pas qu’un hacker n’y arriverait pas et ne puisse pas obtenir les informations que le pentester n’aura pas pu tester au-delà.
Grey Box, Mix des deux : tenter de s’introduire dans le système d’informations en disposant d’un nombre limité d’informations sur l’organisation et son système. Ce cas permet de vérifier les failles d’un système en se positionnant soit en tant que collaborateur de l’entreprise ayant accès en interne à quelques informations, soit en tant que point de départ d’un hacker qui aurait réussi à avoir accès à un compte utilisateur au sein de l’organisation.
En général, lors d’un test en Grey Box, le pentester dispose alors d’identifiants et mots de passe lui permettant d’aller au-delà de l’étape d’authentification. On utilise cette approche dans le cas d’un site marchand ou d’un site non marchand disposant d’un espace membre ou espace clients.
La méthode Grey Box est la plus souvent utilisée dans le cadre de test d’intrusion auprès des entreprises car elle est souvent la plus réaliste. Le hacker dispose en effet dans la majorité des cas de quelques informations, ou si ce n’est pas le cas, il aura trouver comment accéder à ses informations et pourra pousser son attaque au-delà d’une étape d’authentification.
Cependant, le pentester ou hacker éthique ne peut pas garantir que le hacker n’aura pas trouvé une nouvelle technique de piratage et ainsi trouver une nouvelle faille exploitable. Il y a donc toujours une limite de test d’intrusion même si le risque est minimisé.
Qu’elles sont les obligations et les droits des parties impliquées ?
Évidement l’auditeur s’engage à respecter la loi. Il doit aussi signaler tout contenu illicite découvert durant l’audit au commanditaire. Il est par contrat obligé de ne pas divulguer d’informations confidentielles et aussi de ne recourir qu’a des méthodes outils ou techniques validés. Enfin il doit agir avec éthique, loyauté, discrétion et en toute impartialité.
L’audité est en droit de rompre le contrat si l’auditeur n’est pas en mesure de réaliser les tâches définies dans celui-ci. Il défini selon ses attentes et besoins les limites de l’audit et il est en droit de connaitre l’identité et le rôle de chaque auditeurs. Enfin il peut se retourner judiciairement contre l’auditeur si ce dernier enfreint la loi ou outrepasse sans accord les limites fixées dans le contrat.
Comment se prépare un audit ?
Tout d’abord, l’auditeur et l’audité conviennent des attentes et des limites qui seront conclues dans le contrat. L’auditeur doit s’assurer d’être en mesure de réaliser les tâches demandés et l’audité doit être en mesure de fournir les informations ou les accès nécessaire au bon déroulement de l’audit.
Ensemble, ils recensent les missions, valeurs métier et biens support relatifs à l’objet d’étude. Ces éléments peuvent être des entités ou des personnes interne ou externe à l’écosystème visé.
Puis ils identifient les impacts liés aux événements redoutés et l’évaluation de leurs gravités puis la mise en place d’une échelle de gravité. Les impacts peuvent influer sur les missions, le matériel, les personnes, la gouvernance, l’image et les aspects aussi bien financiers que juridiques. L’échelle de gravité doit prendre en compte la totalité des impacts, du plus petit agissant à la marge au plus grand qui peut faire s’écrouler l’ensemble de l’organisation voir au-delà.
Cela fait, on détermine le niveau de menace de chaque partie prenante, client, service interne ou prestataire dans un graphique découpé en zones.
ZONE DE DANGER : zone pour laquelle le niveau de menace est considéré comme très élevé et difficilement acceptable. Par conséquent, aucune partie prenante ne devrait se situer dans cette zone. Les mesures de sécurité prises par la suite devraient faire sortir de cette zone les parties prenantes qui viendraient à s’y trouver.
ZONE DE CONTRÔLE : zone pour laquelle le niveau de menace est considéré comme tolérable sous contrôle. Les parties prenantes qui s’y trouvent doivent faire l’objet d’une vigilance particulière et ont vocation, à moyen terme, à rejoindre une position moins menaçante au travers de mesures de réduction du risque.
ZONE DE VEILLE : zone pour laquelle le niveau de menace est considéré comme faible et acceptable en l’état. Les parties prenantes qui s’y trouvent peuvent faire l’objet d’une veille sans être prises en compte dans l’élaboration des scénarios stratégiques.
HORS PÉRIMÈTRE : les parties prenantes situées à l’extérieur de la zone de veille représentent un niveau de menace jugé négligeable.
Une fois ces vérifications effectuées, le contrat peut être signé. Les deux parties conviennent à ce moment d’une date de déclenchement de l’audit.
Étude des risques (méthode EBIOS)
Étude du contexte : Cette étape essentielle a pour objectif d’identifier globalement le système-cible et de le situer dans son environnement. Elle permet notamment de préciser pour le système les enjeux, le contexte de son utilisation, les missions ou services qu’il doit rendre et les moyens utilisés.
Étude des événements redoutés : Cette étape contribue à l’estimation des risques et à la définition des critères de risques. Elle permet aux utilisateurs du système d’exprimer leurs besoins en matière de sécurité pour les fonctions et informations qu’ils manipulent. Ces besoins de sécurité s’expriment selon différents critères de sécurité tels que la disponibilité, l’intégrité et la confidentialité. L’expression des besoins repose sur l’élaboration et l’utilisation d’une échelle de besoins et la mise en évidence des impacts inacceptables pour l’organisme.
Étude des scénarios de menaces : Cette étape consiste en un recensement des scénarios pouvant porter atteinte aux composants du SI. Une menace peut être caractérisée selon son type (naturel, humain ou environnemental) et/ou selon sa cause (accidentelle ou délibérée). Ces menaces sont formalisées en identifiant leurs composants : les méthodes d’attaque auxquelles l’organisme est exposé, les éléments menaçants qui peuvent les employer, les vulnérabilités exploitables sur les entités du système et leur niveau.
Appréciation des risques : Un élément menaçant peut affecter des éléments essentiels en exploitant les vulnérabilités des entités sur lesquelles ils reposent avec une méthode d’attaque particulière. Les objectifs de sécurité consistent à couvrir les vulnérabilités.
Détermination des exigences de sécurité : L’équipe de mise en œuvre de la démarche doit spécifier les fonctionnalités de sécurité attendues. L’équipe chargée de la mise en œuvre de la démarche doit alors démontrer la parfaite couverture des objectifs de sécurité par les exigences fonctionnelles et les exigences d’assurance.
Comment se conclut un audit ?
L’auditeur doit remettre un rapport qui doit contenir une synthèse compréhensible par des non-experts décrivant les vulnérabilités techniques ou organisationnelles et une appréciation du niveau de sécurité du système d’information.
Il doit aussi contenir un tableau qui fait la synthèse en des termes technique des résultats de l’audit avec les vulnérabilités rencontrées, leur niveau de criticité, les mesures correctives envisagés ainsi que leur faisabilité et leur coût.
Toutes les données fournies à l’auditeur doivent être rendues. Un document stipulant que le système à bien été audité doit être signé par les deux parties.