Audit de sécurité

Les interviews sont généralement essentiels à tout audit. Dans le cas où l'organisation du SI est analysée, ils sont même indispensables. Toutes les personnes ayant un rôle à jouer dans la sécurité du SI sont à interroger :

• Le directeur des systèmes d'information (DSI)
• Le ou les responsable(s) de la sécurité des systèmes d'information (RSSI)
• Les administrateurs
• Les utilisateurs du système d'information, qu'ils aient un rôle dans la production de l'entreprise, dans la gestion, ou la simple utilisation des moyens informatiques
• Tout autre rôle ayant un lien avec la sécurité

Il est important de formuler les questions avec tact. En effet, interroger des personnes à propos de leur travail peut faire qu'elles se sentent jugées et les résultats peuvent être faussés. La diplomatie est donc une compétence essentielle pour la pratique des audits.

Les tests d'intrusion sont une pratique d'audit technique. On peut diviser les tests d'intrusion en trois catégories principales : les tests boîte blanche, les tests boîte grise et les tests dits boîte noire.

Un test boîte noire signifie que la personne effectuant le test se situe dans des conditions réelles d'une intrusion : le test est effectué de l'extérieur, et l'auditeur dispose d'un minimum d'informations sur le système d'information. Ce genre de tests débute donc par l'identification de la cible :

• Collecte d'informations publiques : pages web, informations sur les employés, entreprise ayant un lien de confiance avec la cible ;
• Identification des points de présence sur internet ;
• Écoute du réseau.

Lors de la réalisation de tests boîte grise, l'auditeur dispose de quelques informations concernant le système audité. En général, on lui fournit un compte utilisateur. Ceci lui permet de se placer dans la peau d'un « utilisateur normal ».

Les tests boîte blanche débutent avec toutes ces informations (et beaucoup plus) à disposition. Ensuite commence la recherche des vulnérabilités, à l'aide de différents tests techniques, comme la recherche des ports ouverts, la version des applications, etc.

La dernière phase est l'exploitation des vulnérabilités. Des effets indésirables pouvant survenir (déni de service par exemple), le côté pratique de cette phase n'est pas systématique. Elle consiste à déterminer les moyens à mettre en œuvre pour compromettre le système à l'aide des vulnérabilités découvertes. Selon les moyens à mettre en œuvre, le client pourra décider que le risque associé à la vulnérabilité décelée est négligeable (probabilité d'exploitation faible) ou au contraire à prendre en compte. Pour prouver la faisabilité de l'exploitation, les auditeurs créent des programmes qui exploitent la vulnérabilité, appelés exploits.

Des tests d'intrusion « Red Team » peuvent également être mis en place. Il s'agit de faire une simulation grandeur nature d'une attaque qui pourrait être menée par un groupe ou des individus malveillants. Le périmètre d'attaque n'est pas défini, et plusieurs techniques aussi bien informatiques que d’ingénierie sociale, voir d'intrusion physique peuvent être utilisées dans ce type de test.

Il s'agit ici d'analyser, profondément, les composants du système d'information. Les configurations sont inspectées dans les moindres détails. À la suite de cette observation, la liste des vulnérabilités est dégagée en comparant le relevé à des configurations réputées sécurisées[1]^,[2], et à des ensembles de failles connues[3]^,[4].

Tout peut être inspecté, allant de l'architecture réseau du SI aux systèmes et aux applications. Par exemple sur un serveur, les points suivants sont analysés :

• le chargeur de démarrage ;
• les mécanismes d'authentification (robustesse des mots de passe, utilisation d'authentification forte, etc.) ;
• le système de fichiers (permissions, utilisation de chiffrement etc.) ;
• les services ;
• la journalisation ;
• la configuration réseau ;
• les comptes présents ;
• etc.

Il existe des bases de vulnérabilités très fiables pour les applications répandues. Néanmoins, pour des applications moins utilisées, ou codées par l'entreprise elle-même, il peut être nécessaire d'analyser leur sécurité. Si les sources de l'application sont disponibles, il faut lire et comprendre le code source, pour déceler les problèmes qui peuvent exister. Notamment, les dépassements de tampon (buffer overflow), les bugs de format, ou pour une application web, les vulnérabilités menant à des injections SQL...

L'audit de code est une pratique très fastidieuse et longue. De plus, elle ne permet généralement pas, en raison de la complexité, de dresser une liste exhaustive des vulnérabilités du code. Des méthodes automatiques existent, et permettent de dégrossir le travail, avec des outils comme RATS[5]. Mais se reposer uniquement sur ce genre de méthodes peut faire passer à côté de problèmes flagrants pour un humain.

Pour les applications boite noire, où le code n'est pas disponible, il existe un pendant à l'analyse de code, qui est le fuzzing. Cette technique consiste à analyser le comportement d'une application en injectant en entrée des données plus ou moins aléatoires, avec des valeurs limites. Contrairement à l'audit de code qui est une analyse structurelle, le fuzzing est une analyse comportementale d'une application.

• L'Agence nationale de la sécurité des systèmes d'information (ANSSI) est la référence française en matière de SSI, et a produit notamment un référentiel général de sécurité (normes et recommandations).
• Norme ISO 27000 : est une norme internationale dédiée à la sécurité informatique. Elle représente une famille complète de normes en cours d'élaboration.
• COBIT (Control objectives for information and technology ISACA) : propose un référentiel pour les systèmes d'information,

• Sécurité des systèmes d'information (SSI)
• CobiT