L’audit de code (ou analyse de code) est une étape très fastidieuse et longue (donc très coûteuse pour le client). Souvent imprécise en raison de la complexité de la tâche, elle ne permet généralement pas de dresser une liste exhaustive des vulnérabilités du code, même si des méthodes automatiques existent.

D’où l’intérêt, pour les équipes techniques du client, d’avoir, lors de ses développements applicatifs, tenu compte des principes de Privacy by design et by default (article 25 du RGPD). Vous pouvez également consulter sur le site de la CNIL le guide des bonnes pratiques à l’intention des développeurs :

Il faut analyser en profondeur les composants du système d’information (SI). À la suite de cette analyse, une liste des vulnérabilités est constituée en comparant le relevé réalisé à des configurations conformes à l’état de l’art et réputées sécurisées et à des ensembles de failles connues et identifiées.

Tout peut être inspecté, allant de l’architecture réseau du SI aux systèmes, au matériel et aux applications.

Pour des applications dont le code source n’est pas disponible, il est possible de remplacer l’audit de code par la technique du Fuzzing. Cette technique permet d’analyser le comportement d’une application en lui injectant des données plus ou moins aléatoires, avec des valeurs limites.

Grâce au Fuzzing, il est donc possible de déterminer un profil comportemental de l’application.

Les tests d’intrusion sont une pratique courante dans l’audit technique.

Ceux-ci se déclinent en trois catégories : les tests white box, les tests grey box et les tests dits black box.

Dans les tests black box, l’auditeur / pentester effectue le test de l’extérieur et 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 tests grey box, l’auditeur / pentester dispose de quelques informations sur 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 white box débutent avec de nombreuses informations à 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. Elle permet de déterminer les moyens à mettre en œuvre pour compromettre le système à l’aide des vulnérabilités découvertes.