Audit ou test d'intrusion ? 

L'audit de sécurité ne doit pas être confondu avec les tests d'intrusion. Un audit se fait à livres ouverts, ou en boîte blanche. Les auditeurs peuvent poser toutes les questions qu'ils souhaitent, et ont accès à toutes les informations qu'ils jugent nécessaires à la réalisation de leur mission (sous réserve de ne pas déborder du périmètre de l'audit).

Le contenu d'un audit de sécurité est très variable :

• audit de l'organisation de la sécurité,
• audit global d'un réseau ou d'un système informatique,
• audit d'un système,
• audit d'une architecture réseau,
• audit d'une application ou architecture applicative,
• audit des configurations de systèmes ou éléments de communication,
• etc.

Lorsqu'il existe un référentiel de sécurité, ou des contraintes de sécurité s'appliquant au système analysé (quel qu'il soit), l'audit permet de vérifier si les contraintes sont respectées et de mesurer l'écart entre l'existant et ce qui devrait être. L'audit permet aussi de relever les éventuelles faiblesses ou vulnérabilités dans le système analysé.

Il s'agit d'un état des lieux, qui peut être réalisé sur un système en production mais qu'il est préférable d'exécuter

• en phase de recette,
• en préalable à la mise en production, ou
• à des étapes clé du développement/déploiement d'un système.

Les collaborateurs de B&A Consultants réalisent tout au long de l'année de nombreux audits de sécurité. Nous apportons à nos clients plusieurs dizaines d'années cumulées d'expérience en ce domaine.

Audit d'applications

Un audit applicatif est nécessaire dès lors qu'une application (qui peut être arbitrairement complexe) va être connectée à un réseau non sécurisé (typiquement à Internet), qu'elle va être utilisée par des personnes qui ne sont pas maîtrisées ou maîtrisables par l'entreprise (clients, fournisseurs, stagiaires, partenaires, etc.), qu'elle gère des données sensibles ou critiques, etc. Toute application un tant soit peu étoffée devrait être auditée, y compris s'il s'agit d'une application purement interne à une entreprise : c'est la criticité de l'application et des données qu'elle manipule qui doit servir de critère, et non pas l'accès depuis Internet ou l'utilisation par des centaines de personnes différentes.

L'audit d'une application revient à essayer, par divers moyens, de perturber son fonctionnement. Les auditeurs se servent de l'application et visent à en définir le niveau de sécurité. Une telle activité n'a que peu de points communs avec les tests réalisés durant le développement, qui sont généralement des tests fonctionnels, parfois des tests aux limites. Quelques axes de travail examinés durant un tel audit applicatif :

• contournement des mécanismes d'identification et d'authentification des utilisateurs,
• usurpation d'identité,
• modification de fichiers ou de programmes,
• escalade de droits d'accès,
• vol d'identifiants,
• injection de commandes vers l'application, les outils sous-jacents (base de données) ou le système d'exploitation,
• etc.

Les applications de type Web sont tout particulièrement sensibles à ce genre d'attaques, et doivent être auditées avec soin.

Les conclusions de l'audit

Un audit se termine par la remise d'un ou plusieurs rapports contenant

• les faiblesses et vulnérabilités relevées sur le périmètre audité et
• les risques associés à ces vulnérabilités.

Les informations contenues dans ce document étant d'une nature très technique, un résumé non-technique est rédigé en parallèle afin de permettre aux responsables de l'entreprise d'appréhender complètement les résultats de l'audit.

Les résultats de l'audit sont présentés lors de la réunion de clôture, afin de permettre une discussion globale sur le niveau de sécurité de l'entreprise, les améliorations à apporter, les risques et les contraintes qu'il va falloir prendre en considération, etc.