ISO 27001 – Annexe A.12 : Sécurité des opérations

Quel est l’objectif de l’annexe A.12.1 ?

L'annexe A.12.1 concerne les procédures opérationnelles et les responsabilités. L'objectif de cette zone de l'annexe A est de garantir un fonctionnement correct et sécurisé des installations de traitement de l'information. Il s'agit d'un élément important du système de gestion de la sécurité de l'information (ISMS), surtout si vous souhaitez obtenir la certification ISO 27001. Comprenons maintenant ces exigences et ce qu’elles signifient de manière un peu plus approfondie.

A.12.1.1 Procédures opérationnelles documentées

Les procédures opérationnelles doivent être documentées puis mises à la disposition de tous les utilisateurs qui en ont besoin. Les procédures opérationnelles documentées contribuent à garantir un fonctionnement cohérent et efficace des systèmes pour le nouveau personnel ou les ressources changeantes, et peuvent souvent être essentielles pour la reprise après sinistre, la continuité des activités et lorsque la disponibilité du personnel est compromise. Lorsque les systèmes d'information sont « basés sur le cloud », les activités opérationnelles traditionnelles telles que le démarrage, l'arrêt, la sauvegarde, etc. du système deviennent moins pertinentes et peuvent souvent être externalisées vers un fournisseur de cloud. Dans les environnements et architectures informatiques plus traditionnels, des procédures d'exploitation sont beaucoup plus susceptibles d'être requises.

Il est important que les documents soient conservés dans un état correct et à jour et soient donc soumis à des procédures formelles de gestion du changement et d'examen périodique – c'est essentiel, car l'auditeur veillera spécifiquement à s'en assurer.

On nous demande souvent quel niveau de détails est nécessaire et quels domaines de l'entreprise doivent disposer de procédures documentées. Adoptez une approche de bon sens. Par exemple, si vous disposez d’une réelle stabilité du personnel, que les procédures implicites sont très bien comprises et que la résilience est en place dans l’ensemble de ce pool de ressources, de simples puces peuvent suffire pour former une procédure documentée de type liste de contrôle.

De même, si les procédures évoluent ou changent régulièrement, par exemple en raison d'une croissance rapide, vous souhaitez également disposer de procédures qui peuvent être mises à jour facilement et rapidement. Encore une fois, si de nombreuses nouvelles ressources sont ajoutées et que la zone présente des risques et de la complexité, alors des procédures plus approfondies peuvent être nécessaires afin qu'il soit sans ambiguïté sur quoi, quand, comment, qui, etc.

Les domaines de l'activité qui doivent être pris en compte pour les procédures documentées doivent être ceux dans lesquels vos actifs informationnels sont menacés en raison d'un fonctionnement incorrect, ce qui sera bien entendu identifié dans le cadre de l'évaluation des risques conformément au point 6.1. Cela peut inclure le développement de logiciels, la gestion informatique, jusqu'à la comptabilité financière, la gestion des clients, les travaux de conseil ou de fabrication, etc., selon la nature de l'entreprise.

A.12.1.2 Gestion du changement

L'organisation, les procédures commerciales, les installations de traitement de l'information et les systèmes qui affectent la sécurité de l'information doivent être contrôlés. Une gestion des changements correctement contrôlée est essentielle dans la plupart des environnements pour garantir que les changements sont appropriés, efficaces, correctement autorisés et effectués de manière à minimiser les risques de compromission malveillante ou accidentelle. La gestion du changement s'applique à l'ensemble de l'organisation, de ses processus, de ses installations de traitement de l'information, de ses réseaux, de ses systèmes et de ses applications.

Les journaux d'audit sont requis pour fournir la preuve de l'utilisation correcte des procédures de changement. L'auditeur voudra souligner que les procédures de changement ne doivent pas nécessairement être trop compliquées, mais doivent être adaptées à la nature du changement envisagé. Vous pouvez simplement capturer des preuves des modifications et des changements de contrôle de version au fur et à mesure, ou opérer une gestion des changements beaucoup plus complexe et plus approfondie et inclure le recyclage et les communications, ainsi que disposer d'investissements et de processus d'approbation plus importants.

A.12.1.3 Gestion de la capacité

L'utilisation des ressources doit être surveillée, ajustée et des projections faites des besoins futurs en capacité pour garantir les performances du système requises pour atteindre les objectifs commerciaux. La gestion de la capacité porte généralement sur trois types principaux : Capacité de stockage des données – (par exemple dans les systèmes de bases de données, les zones de stockage de fichiers, etc.) ; Capacité de puissance de traitement – ​​(par exemple, puissance de calcul adéquate pour garantir des opérations de traitement en temps opportun.) ; et Capacité de communication – (souvent appelée « bande passante » pour garantir que les communications sont effectuées en temps opportun).

La gestion des capacités doit également être : Proactif – par exemple, en utilisant des considérations de capacité dans le cadre de la gestion du changement ; Réactif – par exemple, des déclencheurs et des alertes lorsque l'utilisation de la capacité atteint un point critique afin que des augmentations opportunes, temporaires ou permanentes, puissent être effectuées.

A.12.1.4 Séparation des environnements de développement, de test et d'exploitation

De bonnes politiques pour les environnements de développement, de test et opérationnels confirmeraient qu'ils doivent être séparés pour réduire les risques d'accès non autorisé ou de modifications de l'environnement opérationnel. Séparer les environnements informatiques de développement, de test et opérationnels est une bonne pratique, car cela facilite la séparation des tâches et l'accès non autorisé à l'environnement et aux données en direct. Les modifications et les nouveaux développements doivent être minutieusement testés dans une zone distincte avant d'être déployés dans l'environnement d'exploitation réel.

Idéalement, le personnel de développement ne devrait pas avoir accès à l'environnement réel, mais cela peut ne pas être possible, en particulier dans les petites organisations. Une fois séparés, il est important de vérifier que les testeurs n’utilisent pas accidentellement (ou délibérément) les environnements de test en direct. L'auditeur vérifiera que les environnements de développement, de test et en direct sont séparés et qu'il existe des procédures formelles comprenant des niveaux d'autorisation appropriés pour déplacer les modifications et les développements d'un environnement à un autre.

Quel est l’objectif de l’annexe A.12.2 ?

L'annexe A.12.2 concerne la protection contre les logiciels malveillants. L’objectif ici est de garantir que les informations et les installations de traitement de l’information soient protégées contre les logiciels malveillants.

A.12.2.1 Contrôles contre les logiciels malveillants

Des contrôles de détection, de prévention et de récupération pour se protéger contre les logiciels malveillants doivent être mis en œuvre, combinés à une sensibilisation appropriée des utilisateurs. Il s’agit d’une section dont la plupart des organisations ont un certain niveau de connaissance, de compréhension et de mise en œuvre. Cependant, la protection contre les logiciels malveillants peut prendre différentes formes en dehors du « logiciel antivirus » évident.

D'autres contrôles, tels que les restrictions concernant l'utilisation de supports amovibles ou les restrictions sur l'installation de logiciels par les utilisateurs – contribuant à empêcher l'utilisation de logiciels non autorisés – sont également utiles. Il est également essentiel de corriger rapidement les vulnérabilités connues du système et des logiciels. Les virus sont souvent conçus pour rechercher des systèmes et des logiciels non corrigés dans lesquels peuvent résider des vulnérabilités connues. Il est important que toute protection contre les logiciels malveillants soit maintenue à jour, à la fois en termes de « fichiers de signature » pertinents et de logiciel lui-même.

Quel est l’objectif de l’annexe A.12.3 ?

L'annexe A.12.3 concerne la sauvegarde. L’objectif est de se protéger contre la perte de données.

A.12.3.1 Sauvegarde des informations

Pour protéger les informations précieuses contre la perte, un bon contrôle décrit comment des copies de sauvegarde des informations, des logiciels et des images système doivent être prises et testées régulièrement conformément à une politique de sauvegarde convenue.

Les régimes de sauvegarde doivent être conçus en fonction des exigences commerciales et des niveaux de risque liés à l'indisponibilité des informations. Il est donc important de s'assurer que ces régimes répondent aux besoins réels plutôt que de simplement se contenter de « nous effectuons des sauvegardes ». Lorsque des sauvegardes sont effectuées, les informations doivent être protégées au minimum au même niveau que les données en direct et doivent être stockées à l'écart de l'environnement en direct afin de minimiser le risque d'une seule compromission détruisant à la fois l'environnement en direct et les sauvegardes.

Des tests réguliers des sauvegardes sont essentiels pour garantir que les restaurations seront réussies et réalisées en temps opportun. La surveillance et l'enregistrement des sauvegardes doivent être mis en œuvre pour garantir qu'elles se déroulent conformément à la politique de sauvegarde. Les auditeurs intelligents voudront voir des rapports sur les sauvegardes échouées et les tests effectués pour s'assurer qu'ils fonctionnent comme prévu. Les politiques de sauvegarde doivent être envisagées autour de quoi, d'où et où, qui, quand – en tenant compte du bureau et des travailleurs à domicile, des appareils mobiles, etc. où il existe des considérations concernant les sauvegardes de stockage mobiles et de suppression qui présentent des risques accrus en cas de perte qui pourrait être traitées par cryptage ou d’autres contrôles.

Quel est l’objectif de l’annexe A.12.4 ?

L'annexe A.12.4 concerne l'enregistrement et la surveillance. L’objectif de cette zone de l’annexe A est d’enregistrer les événements et de générer des preuves.

A.12.4.1 Journalisation des événements

Les journaux d'événements enregistrant les activités des utilisateurs, les exceptions, les pannes et les événements liés à la sécurité des informations doivent être produits, conservés et examinés régulièrement. Les mécanismes de journalisation et de surveillance constituent un élément important d’une stratégie de « défense en profondeur » pour la gestion de la sécurité en fournissant à la fois des capacités de détection et d’enquête. Des journaux d'événements de tous types, par exemple des journaux système, des journaux de contrôle d'accès, etc., peuvent être requis, notamment en ce qui concerne la gestion des incidents et l'audit. Les journaux devront souvent stocker des quantités potentiellement énormes d'informations, il est donc important de prendre en compte la capacité.

A.12.4.2 Protection des informations du journal

Les installations de journalisation et les informations des journaux doivent être protégées contre la falsification et l’accès non autorisé. Il est également essentiel de garantir que les journaux sont stockés de manière sécurisée et inviolable afin que toute preuve qui en dérive puisse être prouvée de manière prouvable. Ceci est particulièrement important dans toute forme de procédure judiciaire relative aux preuves du journal. Étant donné que les journaux contiennent potentiellement de grandes quantités de données sensibles, il est important qu'ils soient protégés et sécurisés de manière adéquate. Il est également important de considérer que si les journaux contiennent des informations personnellement identifiables, ce qui sera presque certainement le cas, telles que l'identifiant de l'utilisateur et les actions effectuées par cet UID, ils sont susceptibles de relever des exigences de la législation sur la protection des données et la vie privée, y compris la conservation des données. .

A.12.4.3 Journaux de l'administrateur et de l'opérateur

Un bon contrôle décrit comment les activités de l'administrateur système et de l'opérateur système doivent être enregistrées et les journaux protégés et régulièrement examinés. Une attention particulière doit être accordée à des niveaux plus élevés de journalisation pour les comptes privilégiés tels que les administrateurs système et les opérateurs.

A.12.4.4 Synchronisation de l'horloge

Les horloges de tous les systèmes de traitement de l'information pertinents au sein d'une organisation ou d'un domaine de sécurité doivent être synchronisées avec une seule source de temps de référence. La synchronisation de l'horloge du système est importante, en particulier lors de la preuve d'événements dans le cadre d'une enquête ou d'une procédure judiciaire, car il est souvent impossible, voire très difficile, de prouver la « cause et l'effet » si les horloges ne sont pas correctement synchronisées. L'auditeur accordera une attention particulière pour s'assurer que cela a été fait.

Quel est l’objectif de l’annexe A.12.5 ?

L'Annexe A.12.5 concerne le contrôle des logiciels opérationnels. L’objectif de ce domaine de l’annexe A est d’assurer l’intégrité des systèmes opérationnels.

A.12.5.1 Installation de logiciels sur les systèmes opérationnels

Des procédures doivent être mises en œuvre pour contrôler l’installation de logiciels sur les systèmes opérationnels. Comme pour tout contrôle lié à la sécurité, il est important que l’installation de logiciels sur les systèmes opérationnels soit formellement contrôlée. Même si cela n’est pas toujours possible, notamment dans les petites organisations, le principe reste vrai. Les problèmes liés à l'installation ou à la modification inappropriée de logiciels sur les systèmes opérationnels peuvent inclure : Logiciel infecté par un logiciel malveillant en cours d'installation ; Problèmes de capacité ; ou un logiciel pouvant permettre l'installation d'activités internes malveillantes (par exemple, des outils de piratage). Au-delà de restreindre et de limiter l'installation de logiciels sur les systèmes opérationnels, il est également important de contrôler formellement l'installation légitime.

C'est une bonne pratique de garantir, dans la mesure du possible, que, par exemple : Une gestion formelle du changement a eu lieu, y compris des niveaux d'autorisation appropriés ; Des procédures de retour en arrière sont en place ; et Les versions précédentes du logiciel et les historiques de modifications sont conservés en toute sécurité. Chaque changement doit prendre en compte à la fois les exigences commerciales et les exigences et risques de sécurité, conformément aux procédures formelles de gestion des changements. L'auditeur s'attendra à voir les enregistrements des modifications logicielles et des installations qui ont été conservées, qu'il voudra inspecter/échantillonner.

Quel est l’objectif de l’annexe A.12.6 ?

L'annexe A.12.6 concerne la gestion des vulnérabilités techniques. L’objectif de ce domaine de l’annexe A est d’empêcher l’exploitation des vulnérabilités techniques.

A.12.6.1 Gestion des vulnérabilités techniques

Les informations sur les vulnérabilités techniques des systèmes d'information utilisés doivent être obtenues en temps opportun, les organisations exposées à ces vulnérabilités évaluées et des mesures appropriées prises pour faire face au risque associé. Toute vulnérabilité constitue une faiblesse dans la protection de la sécurité et doit être traitée de manière efficace et efficiente lorsque les niveaux de risque sont inacceptables. Les vulnérabilités techniques ont été au cœur de nombreuses failles de sécurité importantes signalées dans les médias (et de celles qui ne le sont pas !) et il est donc essentiel que des processus de gestion formels soient en place à un niveau adéquat et proportionné.

Il doit y avoir un équilibre entre l'impératif de sécurité consistant à mettre en œuvre les correctifs de vulnérabilité le plus rapidement possible et l'impératif de sécurité consistant à tester les correctifs suffisamment pour garantir la disponibilité et l'intégrité continues des systèmes et la minimisation des incompatibilités. La sensibilisation peut également jouer un rôle important et il est donc judicieux de disposer d'une stratégie de communication visant à informer les utilisateurs lorsqu'il existe des vulnérabilités qui peuvent être gérées dans une certaine mesure par le comportement des utilisateurs. L'auditeur s'attendra à ce que des processus d'identification et de détection des vulnérabilités soient en place, notamment sur les systèmes critiques ou ceux traitant ou stockant des informations sensibles ou classifiées.

A.12.6.2 Restrictions sur l'installation du logiciel

Des règles régissant l'installation de logiciels par les utilisateurs doivent être établies et mises en œuvre. Ce contrôle consiste à restreindre la capacité des utilisateurs à installer des logiciels, notamment sur les appareils locaux (postes de travail, ordinateurs portables, etc.). L'installation de logiciels par les utilisateurs soulève un certain nombre de menaces et de vulnérabilités, notamment la menace d'introduction de logiciels malveillants et la violation potentielle des lois sur les licences logicielles/DPI. Idéalement, les utilisateurs ne seraient pas en mesure d'installer de logiciel sur les équipements de l'organisation. Toutefois, des raisons commerciales ou pratiques peuvent expliquer pourquoi cela n'est pas possible.

Lorsqu’une restriction totale n’est pas possible, il est recommandé de mettre sur « liste blanche » les logiciels pouvant être installés. L'auditeur vérifiera quelles restrictions ont été imposées à l'installation de logiciels par les utilisateurs. Ensuite, là où aucune restriction totale n’est mise en œuvre, ils voudront avoir la preuve que les risques ont été pleinement évalués et que, lorsque cela est possible, des contrôles complémentaires tels que des audits logiciels réguliers ont été mis en œuvre et sont régulièrement utilisés.

Quel est l’objectif de l’annexe A.12.7 ?

L’annexe A.12.7 concerne les systèmes d’information et les considérations d’audit. L’objectif de ce domaine de l’annexe A est de minimiser l’impact des activités d’audit sur les systèmes opérationnels.

A.12.7.1 Contrôles d'audit des systèmes d'information

Les exigences d’audit et les activités impliquant la vérification des systèmes opérationnels doivent être soigneusement planifiées et convenues afin de minimiser les perturbations des processus métier. Chaque fois que vous effectuez des tests et des activités d'audit (par exemple, analyses de vulnérabilité, tests d'intrusion, etc.) sur les systèmes opérationnels, il convient de veiller à ce que les opérations ne soient pas affectées négativement. De plus, la portée et la profondeur des tests doivent être définies. Un tel audit ou test des systèmes opérationnels doit être effectué dans le cadre d'un processus formel et dûment autorisé. L'auditeur recherchera des preuves que la planification des tests et le niveau des tests sont convenus et autorisés par le biais d'un processus formel.