La question est aussi vieille que la SSI (Sécurité des Systèmes d’Information) : faut-il favoriser un audit organisationnel à un audit technique ou réciproquement ? D’ailleurs de quoi parle-t-on ? De deux types d'audits qui, finalement, se complètent, plus qu'ils ne s'opposent.

Il existe deux familles d’audit de la sécurité du SI : technique et organisationnel. Pour commencer, présentons le périmètre de ces différents audits.

L’audit organisationnel, porté par les méthodes d’analyse de risques
L’analyse de risques (au travers de méthodes telles que MEHARI® du CLUSIF ou EBIOS® de la DCSSI) permet d’identifier les mesures adaptées à mettre en place pour sécuriser le SI en fonction des enjeux métier. Elle sert de base à l’élaboration de la Politique de sécurité du SI et du Schéma directeur de sécurité. La démarche (Figure 1) permet de positionner l’existant en matière de SSI au regard des enjeux de l’entreprise et des risques qu’elle veut prendre en compte (les risques non retenus sont appelés ‘risques résiduels’ : ils doivent être identifiés en cas d’évolution du SI). C’est sur cette base que sont proposées les recommandations génériques que l’entreprise doit mettre en œuvre.

Figure 1 – Démarche générique d’une méthode d’analyse de risque (source Bull)

Toutefois, à ce stade, l’analyse des risques ne permet pas de définir des priorités pour les recommandations. Pour que l’audit organisationnel soit complet, un classement des recommandations en fonction des enjeux et des moyens de l’entreprise est alors réalisé. Au regard des besoins de l’entreprise, l’audit organisationnel porte sur un périmètre particulier du SI – par exemple une application – ou sur la totalité du SI.

Reste qu’un audit organisationnel est encore souvent perçu comme lourd, compliqué à mettre en œuvre, très chronophage et par conséquent relativement cher. Toutefois, si l’utilisation formelle d’une méthode d’analyse de risque peut rapidement prendre plus de 100 jours, il reste possible, avec une bonne expérience des outils et des organisations, de réaliser des audits organisationnels en moins de 20 jours, en ne sélectionnant qu’un sous-ensemble adapté au métier de l’entreprise, tout en restant pertinent au regard de ses enjeux.

Les audits techniques, différents selon les besoins
L’objectif de ces audits est de s’assurer de la maturité des technologies et des hommes qui les ont mis en œuvre, en analysant leur impact sur la sécurité du SI et en déterminant pour chacune d’entre elles le niveau de disponibilité, d’intégrité et de confidentialité implémenté par rapport à un référentiel d’entreprise.

Différents audits techniques existent, parmi lesquels :

• Les audits d’architecture : l’objectif est d’obtenir un diagnostic de la sécurité d’une plate-forme ou d’une solution : définir les points faibles et forts des maillons composant la chaîne applicative, recenser et qualifier les vulnérabilités, trouver les parades techniques pour y remédier.
• Les tests de vulnérabilité : ils permettent de lister les failles présentes sur un ou plusieurs systèmes (serveur, routeur, etc.). Ils peuvent être effectués en interne ou en externe et être réalisés sur une seule cible jusqu’à plusieurs milliers.
• Les tests d’intrusion : ils visent à qualifier le niveau de sécurité du SI depuis l’extérieur ou l’intérieur de l’entreprise. Ces réalisations s’appuient sur une méthodologie rigoureuse permettant de garantir des prestations de qualité constante, assurant le non débordement, la traçabilité des actions menées, etc.
• Les audits de code : la relecture du code source d’une application sous l’angle de la sécurité permet d’identifier les techniques de programmation n’assurant pas une sécurité suffisante ou la présence de vulnérabilités susceptibles d’entraîner des problèmes de sécurité.
• Les analyses de configuration : elles permettent de détecter les vulnérabilités locales d’une brique élémentaire. Par exemple, un routeur correspond à une brique élémentaire seule, alors qu’un serveur Web est une brique fonctionnelle composée de trois briques élémentaires : le système d’exploitation (par exemple Linux), l’application Web (par exemple Apache) et le développement spécifique réalisé par le client. Les paramètres critiques de la configuration de chaque brique élémentaire sont validés par rapport aux référentiels existants du client et à nos propres guides de sécurisation.

Mise en œuvre : technique versus organisationnel ?
De manière générale, l’audit organisationnel permet de mettre en adéquation les informations critiques de l’entreprise et les risques qu’elle encourt, là où l’audit technique adresse plutôt un client déjà mature en termes de sécurité, en validant une ou plusieurs briques du système d’information.

Ceci positionne naturellement l’audit organisationnel comme une 1ère étape d'un processus complet, qui, classiquement, débouchera sur un ou plusieurs audits techniques. En effet, une fois l’audit organisationnel réalisé, un plan d’action doit être mis en œuvre, constitué de différents ‘chantiers sécurité’, parmi lesquels on pourra retrouver des audits d’architecture, des tests de vulnérabilité, des tests d’intrusion, etc. De fait, l’audit organisationnel ne remplace pas l’audit technique et réciproquement.

D’autre part, le SI des entreprises est en constante évolution et les enjeux évoluent. Les vulnérabilités augmentent (plus de 100 nouveaux bugs sortent chaque semaine¹ ) et les risques évoluent (qui aurait pu croire, avant le 11 septembre 2001, qu’un gratte-ciel entier pourrait disparaître suite au choc d'un avion ?). En sécurité du SI, plus qu’ailleurs, qui n’avance pas, recule !

Ainsi, l’entreprise est confrontée à une course en avant, nécessitant une récurrence des audits de sécurité, afin de prendre en compte ces nouveaux enjeux, vulnérabilités et risques. La récurrence est par définition variable :

• L’audit organisationnel devrait être refait, soit de façon systématique tous les ans afin de mettre à jour la politique de sécurité de l’entreprise, soit lorsque l’entreprise met en œuvre une nouvelle application stratégique, une nouvelle architecture, etc. ; autrement dit, à chaque évolution majeure de son SI.
• L’audit technique, quant à lui, peut être :
  - très souvent récurrent (c’est le cas des tests de vulnérabilité en mode ASP ou via une appliance connectée en permanence sur le SI du client) ;
  - réalisé lors de la mise en production d’une infrastructure ou application nouvelle (par exemple via un test d’intrusion ou des analyses de configuration).

Reste à positionner l’audit de sécurité au sein de l’organisation de l’entreprise

• De plus en plus souvent, le commanditaire est le RSSI, mais cela peut aussi être un DSI, un responsable de l’exploitation, une cellule de contrôle ou d’audit interne, etc. On voit aussi des audits mandatés par des organismes externes (clients, cabinets de certification, assurances, etc.).
• Particulièrement dans le cas de l’audit organisationnel, il est toujours souhaitable que la Direction Générale soit impliquée. En effet, il faudra, pour réaliser l’Analyse des risques, rencontrer (idéalement) toutes les Directions fonctionnelles (« métiers ») de l’entreprise : l’appui de la DG est alors souvent nécessaire.
• Côté audit technique, certains (comme le test d’intrusion) nécessitent la validation d’un mandataire social (ou équivalent) de l’entreprise.

Les résultats de l’audit doivent être présentés aux personnes ‘ayant besoin d’en connaître’ dans l’entreprise. Là encore, ces personnes seront différentes selon le type et le but de l’audit : de l’administrateur système au Directeur Général, en passant par le RSSI. Enfin, ces résultats pourront intégrer un tableau de bord de la sécurité, voire permettre l’évolution, pour les entreprises les plus abouties en SSI, du Système de Management de la Sécurité (SMSI).

Quelques retours d’expérience…
Voici quelques situations typiques rencontrées lors d’audits de sécurité organisationnels et techniques.

• Le RSSI de cette organisation, récemment nommé, voulait sensibiliser sa Direction Générale qui, peu au fait des problématiques de sécurité du SI, n’allouait pas les budgets suffisants. Bull a proposé la réalisation d’un test d’intrusion « sensibilisation ». Dans ce cas, le RSSI attend du test qu’il puisse démontrer la capacité éventuelle d’une structure extérieure à accéder au SI de l’entreprise. L’intrusion « sensibilisation » laisse en principe un champ libre important à l’attaquant (toutes « portes » possibles). Les résultats du test, une fois présentés à la DG, ont permis d’obtenir les budgets nécessaires pour lancer un chantier plus important, basé sur un audit organisationnel et prenant en compte l’ensemble du SI de l’entreprise.
  
  
• Ce client gère un contrat d’infogérance réseau pour une grande banque internationale. Ce contrat prévoit de faire valider le niveau de sécurité du réseau en le comparant aux référentiels SSI internes de la banque, d’en valider les écarts et ce, une fois par an, par un tiers. Bull a proposé la réalisation de :
  - tests externes via Internet, RAS, le LAN d’un fournisseur et au travers du LAN d’un autre client ;
  - tests internes (11 serveurs) ;
  - tests téléphoniques (parcours d’une plage de 500 numéros et tests d’intrusions) ;
  - analyses de configuration (9 serveurs, 15 éléments réseaux et un poste nomade).
  Les résultats des audits ont permis de corriger certaines vulnérabilités, mais aussi de faire évoluer les référentiels internes de la banque.
  
  
• Suite à un problème majeur sur son SI, ce client a eu le plus grand mal à redémarrer, du fait de sauvegardes réalisées aléatoirement. Bull a conduit l’analyse de sécurité d’un ensemble complexe de sauvegardes, selon 3 phases :
  
  1. Phase 1 : étude de l’existant exhaustive
  analyse organisationnelle : fourniture d’un questionnaire spécifique sur la sauvegarde qui reprend les points les plus pertinents de plusieurs méthodes ou « best practices » SSI (Méhari, EBIOS, ISO 17799:2005, etc.) ;
  - analyses fonctionnelle et technique des mécanismes mis en œuvre dans le cadre de la sauvegarde ;
  - interview des différents utilisateurs du système de sauvegarde, organisationnels et techniques.
  
  2. Phase 2 : analyse des besoins (actuels et futurs). Cette phase a permis de mettre en adéquation la réalité du terrain exprimée lors de la phase 1 et les besoins réels en termes de gestion des sauvegardes. Elle comprenait :
  - l’étude de l’analyse des enjeux ;
  - l’analyse des besoins de volumétrie et de la criticité des informations ;
  - l’analyse des besoins de performances ;
  - l’analyse organique.
  
  3. Phase 3 : recommandations
  - bilan organisationnel (équipes, compétences, processus, documentation) ;
  - améliorations possibles de la solution actuelle ;
  - stratégie de sauvegarde à envisager répondant à la problématique du client.
  Ces recommandations ont été priorisées (en fonction des enjeux et des budgets) et fournies sous forme d’un plan d’action mis en œuvre par le client. Les résultats ont conduit à une Politique de sauvegarde / restauration unique pour l’ensemble du SI de l’entreprise.

¹ cf. avis d’expert de Bull Direct n°6 de juillet 2006 intitulé : « Les défis du Patch Management : enjeux de la gestion des correctifs, alternatives et meilleures pratiques ».

Lire aussi

• l’exemple de l’entreprise TOKHEIM, commenté par Patrick Weisse, Responsable Réseau et Sécurité >>
• le livre blanc "La sécurité des systèmes d'information" avec les 10 règles d'or pour renforcer la sécurité et des témognages de DSI et RSSI >>
• le flyer "Audits Techniques de sécurité" >>