Suivi des actions
Nous avons vu plus haut que tous les processus de sécurité opérationnelle nécessitent de
suivre les actions. La norme ISO 27001 insiste sur cet aspect, qui se traduit concrètement
par la mise en place des trois éléments suivants.
Comité de suivi : il convient de suivre les actions dans une ou plusieurs instances
appropriées. Ce peut être dans un comité de suivi spécialement créé pour l’occasion,
mais rien n’empêche de suivre les actions dans des comités existants : comité de
pilotage d’exploitation, comité de sécurité, comité DSI, etc. Naturellement, les
comptes-rendus de ces comités doivent être rédigés, validés et consignés.
Tableaux de suivi : cela peut paraître trivial, mais la grande majorité des auditeurs
s’attendent à des tableaux de suivi. Chaque action donne lieu à une ligne comportant
plusieurs colonnes, telles que : désignation de l’action, description de l’action, actions
réalisées, actions restant à accomplir, pourcentage d’avancement, date prévue de
réalisation. On peut aussi suivre les actions par les comptes-rendus de réunion de suivi
rédigés, mais force est de constater que les auditeurs préfèrent les états d’avancement
sous forme de tableau synthétique.
Preuves : élaborer des tableaux de suivi indiquant le pourcentage d’avancement des
actions est somme toute assez simple à réaliser, mais encore faut-il en apporter la
preuve. Aussi est-il important de consigner ces preuves. Concrètement, il suffit de
désigner les documents ou les traces pertinentes. Par exemple, si dans le domaine de
la gestion des journaux, une action consistait à modifier une application afin qu’elle
trace les dates de connexion et les actions réalisées par les utilisateurs, les preuves de
la réalisation peuvent être la note officielle de mise en production de cette
fonctionnalité, ou bien les journaux générés suite à cette modification.
Contrôle interne
Comme le chapitre consacré aux audits le précise, les parties prenantes font de plus en
plus pression pour contrôler le niveau de sécurité du SI. Aussi n’est-il pas rare d’avoir à
subir dans la même année un audit de commissariat aux comptes, un audit interne, un
audit commandité par un client important, sans compter d’éventuels audits de
certification si un SMSI a été implémenté. Ces audits sont une charge très importante
pour le RSSI et les équipes d’exploitation. Aussi, quitte à dépenser beaucoup d’argent et
de temps pour préparer ces audits et satisfaire les auditeurs, autant faire en sorte que tous
ces efforts profitent à la sécurité opérationnelle.
Concrètement, il suffit de mettre en place un dispositif de contrôle interne de la sécurité.
Cela consiste à identifier un certain nombre de processus clés intéressant tous les
auditeurs (auditeurs internes, clients, certificateurs, commissaires aux comptes…).
Généralement, les points incontournables sont la gestion des identités pour les
applications les plus sensibles, la gestion des sauvegardes et des restaurations, les tests de
continuité/reprise d’activité, les dispositifs organisationnels et techniques de séparation
des tâches, le contrôle de la qualité des mots de passe, les processus de mise en
production, etc. En fait, ce dispositif de contrôle est directement inspiré des plans de
contrôle IT imposés par les sociétés d’audit de comptes, portant sur les applications
financières. L’idée est d’élargir le périmètre de ce plan de contrôle à tous les aspects
Nous avons vu plus haut que tous les processus de sécurité opérationnelle nécessitent de
suivre les actions. La norme ISO 27001 insiste sur cet aspect, qui se traduit concrètement
par la mise en place des trois éléments suivants.
Comité de suivi : il convient de suivre les actions dans une ou plusieurs instances
appropriées. Ce peut être dans un comité de suivi spécialement créé pour l’occasion,
mais rien n’empêche de suivre les actions dans des comités existants : comité de
pilotage d’exploitation, comité de sécurité, comité DSI, etc. Naturellement, les
comptes-rendus de ces comités doivent être rédigés, validés et consignés.
Tableaux de suivi : cela peut paraître trivial, mais la grande majorité des auditeurs
s’attendent à des tableaux de suivi. Chaque action donne lieu à une ligne comportant
plusieurs colonnes, telles que : désignation de l’action, description de l’action, actions
réalisées, actions restant à accomplir, pourcentage d’avancement, date prévue de
réalisation. On peut aussi suivre les actions par les comptes-rendus de réunion de suivi
rédigés, mais force est de constater que les auditeurs préfèrent les états d’avancement
sous forme de tableau synthétique.
Preuves : élaborer des tableaux de suivi indiquant le pourcentage d’avancement des
actions est somme toute assez simple à réaliser, mais encore faut-il en apporter la
preuve. Aussi est-il important de consigner ces preuves. Concrètement, il suffit de
désigner les documents ou les traces pertinentes. Par exemple, si dans le domaine de
la gestion des journaux, une action consistait à modifier une application afin qu’elle
trace les dates de connexion et les actions réalisées par les utilisateurs, les preuves de
la réalisation peuvent être la note officielle de mise en production de cette
fonctionnalité, ou bien les journaux générés suite à cette modification.
Contrôle interne
Comme le chapitre consacré aux audits le précise, les parties prenantes font de plus en
plus pression pour contrôler le niveau de sécurité du SI. Aussi n’est-il pas rare d’avoir à
subir dans la même année un audit de commissariat aux comptes, un audit interne, un
audit commandité par un client important, sans compter d’éventuels audits de
certification si un SMSI a été implémenté. Ces audits sont une charge très importante
pour le RSSI et les équipes d’exploitation. Aussi, quitte à dépenser beaucoup d’argent et
de temps pour préparer ces audits et satisfaire les auditeurs, autant faire en sorte que tous
ces efforts profitent à la sécurité opérationnelle.
Concrètement, il suffit de mettre en place un dispositif de contrôle interne de la sécurité.
Cela consiste à identifier un certain nombre de processus clés intéressant tous les
auditeurs (auditeurs internes, clients, certificateurs, commissaires aux comptes…).
Généralement, les points incontournables sont la gestion des identités pour les
applications les plus sensibles, la gestion des sauvegardes et des restaurations, les tests de
continuité/reprise d’activité, les dispositifs organisationnels et techniques de séparation
des tâches, le contrôle de la qualité des mots de passe, les processus de mise en
production, etc. En fait, ce dispositif de contrôle est directement inspiré des plans de
contrôle IT imposés par les sociétés d’audit de comptes, portant sur les applications
financières. L’idée est d’élargir le périmètre de ce plan de contrôle à tous les aspects