Définissez le périmètre et le type d’audit ou de contrôle à réaliser
Imaginons maintenant que vous ayez réalisé votre audit ou contrôle ponctuel. Votre nouvel objectif en tant que RSSI de PayeTonPote est alors le suivant :
Vérifier que chaque sprint de développement n’apportera pas de nouvelles vulnérabilités dans le code.
Avant de vous lancer dans la réalisation, il est nécessaire de définir en détail le périmètre et le type d’analyse que vous allez réaliser sur ce périmètre.
Cela revient à répondre aux questions “Quoi ?” et “Comment ?”
Quoi ?
Nous avons déjà traité cette question au chapitre précédent pour un audit ou contrôle ponctuel. Vous devrez avoir les mêmes réflexions pour un audit ou contrôle continu.
Cependant, dans le cas d’un audit ou contrôle continu, le résultat va souvent alimenter un tableau de bord cybersécurité.
En complément des questions vues précédemment, il faut donc aussi vous interroger : lequel de vos indicateurs souhaitez-vous alimenter avec cet audit ou ce contrôle ?
Par exemple, dans le cas de PayeTonPote, vous souhaitez vous assurer que chaque sprint de développement n’apporte pas de nouvelle faille dans le code. Quel serait alors le périmètre de l’audit ? Quels événements redoutés ou scénarios d’attaque veut-on évaluer ?
Comment ?
La question du “Comment” consiste là aussi à identifier le type d’audit ou de contrôle que vous allez réaliser, et les modalités de réalisation.
Pour le choix du type d’audit ou de contrôle à réaliser, vous pouvez vous référer à la partie 1.
Ici, la question des prérequis est également clé : de quoi aurez-vous besoin pour réaliser cet audit ou contrôle ? Pourrez-vous l’obtenir ?
Il est important alors de bien identifier vos possibilités, et en particulier :
le budget que vous avez à disposition, pour savoir si vous pourrez ou non acquérir un outil, et lequel ;
la manière dont vous pourrez interfacer cet outil avec votre SI ;
les données sources que vous serez en capacité de récupérer, et si elles sont suffisantes pour répondre à votre objectif.
Pour traiter les deux derniers points, il faudra bien sûr vous rapprocher des personnes chargées du périmètre que vous souhaitez contrôler.
Il est aussi possible que certains outils soient déjà mis en place chez certaines équipes (par exemple un outil de cartographie du SI). Il est important de bien vous renseigner sur l’existant, car cela pourrait vous faire gagner du temps (et de l’argent !) dans la mise en place de votre audit ou contrôle.
Par exemple dans le cas de PayeTonPote : quel serait le type d’audit à réaliser et les prérequis nécessaires ? Un outil est-il nécessaire, si oui de quel type ?
Donc pour une approche continue, je suis obligé d’automatiser mon audit ou mon contrôle ?
Pour des questions d’efficacité, c’est souvent le choix qui est privilégié par les entreprises. Vous pouvez par contre avoir dans un premier temps une approche plus manuelle pour tester votre audit ou contrôle, puis l’automatiser lorsque cela vous convient.
Il est aussi possible de garder une approche plus manuelle dans les conditions suivantes :
la récupération du résultat est “simple” (par exemple, lorsqu’il suffit de cliquer sur un bouton ou de lancer une ligne de commande) ;
vous ne souhaitez pas une fréquence très élevée (du genre quotidienne) ou en temps réel pour cet audit ou contrôle ;
votre SI n’est pas très étendu ni très complexe (par exemple, vous avez peu d’applications, et un réseau peu cloisonné).
Définissez le planning et les ressources à mobiliser
Nous retrouvons une nouvelle fois ici les mêmes questions que pour un audit ou contrôle ponctuel : “Qui ?” et “Quand ?”.
Qui ?
1. Qui va mettre en place l’audit ou le contrôle ? Et qui va le déclencher ?
Ici, il faut bien distinguer la question de la mise en place initiale de l’audit ou du contrôle (phase projet), et le déclenchement récurrent de l’audit ou du contrôle qui a été mis en place (phase de run).
Pour répondre au premier point, il faut bien identifier les compétences qui vont être nécessaires, car elles peuvent être assez avancées dans certains cas. Par exemple, est-ce que la mise en place de cet audit ou contrôle nécessite des compétences en analyse de données ? Faut-il une maîtrise d’un outil spécifique du marché ?
Pour les audits ou contrôles “simples”, comme les cartographies du SI ou les scans de vulnérabilités, vous pourrez généralement vous appuyer sur des compétences internes si vous êtes en capacité de les mobiliser. Pour d’autres types d’audits ou de contrôles plus complexes, comme les scans de conformité ou le Bug Bounty, il est en revanche très possible que vous deviez vous faire accompagner par une société spécialisée.
La réponse au second point (“Qui va le déclencher ?”) est normalement plus simple si l’audit ou le contrôle est suffisamment outillé. Il s’agit plutôt d’une question de périmètre de responsabilité. Généralement, les audits et contrôles continus sont déclenchés à l’initiative de l’équipe Cybersécurité ou du contrôle interne (ou équivalent).
Quel budget dois-je prévoir dans ce cas ?
Le budget va principalement être nécessaire pour la mise en place initiale de l’audit ou du contrôle. Il va là aussi dépendre de la complexité de l’audit ou du contrôle que vous souhaitez mettre en place, des outils dont vous allez avoir besoin, et de votre besoin ou non de faire appel à une société externe.
2. Qui va être mobilisé pendant la mise en place de l’audit ou du contrôle ? Et lorsqu’il sera déclenché ?
On retrouve encore ici la distinction entre la phase de projet et la phase de run de l’audit ou du contrôle.
Pour la mise en place, il sera probablement nécessaire d’impliquer les personnes qui connaissent le périmètre, et qui pourront fournir les informations nécessaires. Par exemple : l’architecture du SI, les plages d’adresses IP, les composants à interfacer avec votre outil, etc. Il faudra prévoir quelques ateliers avec eux afin de collecter toutes ces informations.
Ils pourront aussi être impliqués lorsque vous allez tester le déclenchement de votre audit ou contrôle, en cas d’anomalie, notamment.
Là aussi, pensez bien à estimer la charge de travail qui leur sera nécessaire, afin d’éviter toute mauvaise surprise.
Une fois que l’audit ou le contrôle est mis en place et fonctionne, il est possible que vous n’ayez plus du tout besoin de mobiliser des personnes en interne. C’est en revanche moins vrai pour les audits et contrôles organisationnels (autocontrôles SSI, par exemple), qui nécessiteront de collecter à intervalles réguliers des informations de la part des audités.
3. Qui sera mobilisé, une fois les résultats obtenus, pour réaliser la remédiation de manière continue ?
Dans le cas d’un audit ou contrôle continu, il faut aussi clarifier au plus tôt qui sera chargé de remédier aux problèmes identifiés.
En effet, si la remédiation n’est pas efficace, cela se verra encore plus qu’avec un audit ou contrôle ponctuel, puisqu’à chaque itération, les résultats seront identiques ou moins bons que la fois précédente.
Par exemple dans le cas de PayeTonPote : qui met en place l’audit ou le contrôle ? Qui le déclenche ? Quelles sont les personnes à solliciter pour la mise en place et lors du déclenchement de l’audit ou du contrôle, et à quelle hauteur seront-ils mobilisés ? Qui va traiter la rémédiation ?
Quand ?
La dernière question à se poser est celle du planning.
On retrouve les mêmes sous-questions que pour les audits ou contrôles ponctuels, mais vous n’allez pas les traiter exactement de la même manière.
1. Quel serait le planning idéal du point de vue cybersécurité pour mettre en place cet audit ou ce contrôle ? À quelle fréquence serait-il déclenché, idéalement ?
De la même manière que pour les audits et contrôles ponctuels, il faut prendre en compte la notion de risque pour définir le planning de mise en place. Par exemple, si une vulnérabilité très critique a été rendue publique récemment et que vous avez mis en place des moyens pour mettre à jour votre SI, vous pourriez vouloir suivre l’avancement de ce chantier en réalisant des scans de vulnérabilités très régulièrement.
2. Quelles sont les contraintes de planning et de fréquence sur le périmètre à auditer ?
Pour collecter ces éléments, il sera nécessaire de vous rapprocher des personnes chargées du périmètre. Les questions suivantes peuvent guider vos discussions :
Y a-t-il des contraintes d’agenda à prendre en compte pour la mise en place de l’audit ou du contrôle ? et pour son déclenchement ?
Là aussi, tout va dépendre du niveau de mobilisation que vous demandez pour la mise en place du contrôle ; il est donc important de bien l’avoir identifié avant de poser cette question.
Y a-t-il des évolutions structurantes en cours ou à venir sur le périmètre audité ?
Ici aussi, une évolution structurante pourrait remettre en question la manière dont vous avez implémenté votre audit ou contrôle. En particulier si un changement d’architecture important est prévu et que vous souhaitez automatiser un audit ou contrôle technique, auquel cas il vaut mieux attendre qu’il soit réalisé pour éviter de changer son implémentation. Vous vous assurerez ainsi que l’effort de mise en place de votre audit ou contrôle sera rentable dans la durée.
Dans quels délais les équipes concernées sont-elles capables de traiter les problèmes identifiés ?
N’oubliez pas que dans le cas d’un audit ou contrôle continu, une remédiation inefficace sera d’autant plus visible. Il est donc important d’adapter la fréquence de vos audits et contrôles aux capacités de remédiation des équipes. Comme nous l’avons vu en partie 1, une remédiation inefficace peut être un critère discriminant pour certains types d’audits ou de contrôles, comme le Bug Bounty.
Par exemple dans le cas de PayeTonPote : quel serait le planning idéal pour mettre en place cet audit ou ce contrôle ? Avec quelle fréquence ? Quelles sont les contraintes à prendre en compte ?
Préparez le lancement
Une fois que tous ces éléments sont définis, vous pouvez préparer le lancement de l’audit ou du contrôle.
Vous pouvez aussi organiser une réunion de lancement de la phase projet (mise en place de l’audit ou du contrôle) à l’aide d’un document qui précisera :
le périmètre de l’audit ou du contrôle, le scénario redouté à qualifier et l’indicateur attendu ;
le type d’audit choisi et les prérequis (dont l’outillage choisi) ;
les acteurs : ceux qui sont chargés de la mise en place puis du déclenchement de l’audit ou du contrôle, ceux qui seront sollicités pendant la mise en place et pendant le déclenchement, et ceux qui effectueront la remédiation ;
le planning de mise en place et la fréquence.
À vous de jouer !
Vous allez cadrer l’audit ou le contrôle continu à réaliser pour répondre à votre objectif :
Vérifier que chaque sprint de développement n’apporte pas de nouvelles vulnérabilités dans le code.
Pour cela, vous pouvez de nouveau vous appuyer sur le compte-rendu de la réunion réalisée avec le responsable des développements. Remplissez la colonne de droite de ce tableau, et comparez vos réponses à celles de la correction !
En résumé
Dans le cas d’un audit ou contrôle continu, les questions à se poser sont globalement les mêmes que pour une approche ponctuelle.
Il faut cependant bien distinguer la mise en place de l’audit ou du contrôle (qui sera faite une seule fois) et son déclenchement (qui sera fait plusieurs fois, par définition, sauf s’il est totalement automatisé).
La question de la fréquence est également clé, elle doit se traiter à la fois en fonction des capacités d’automatisation de l’audit ou du contrôle, mais aussi en fonction des capacités de remédiation de vos équipes.
Maintenant que nous avons vu comment cadrer des audits et contrôles unitaires, nous allons nous attaquer à la définition de la stratégie d’audit à proprement parler !
