Politique de sécurité informatique : importance, bonnes pratiques et principaux avantages

Les politiques de sécurité écrites n’améliorent pas directement la sécurité du réseau ; certains professionnels de la sécurité raillent donc les exigences relatives aux politiques écrites. Cependant, dans les organisations matures, les professionnels de la sécurité comprennent non seulement l’importance et les avantages des politiques écrites, mais rédigent et promeuvent également les règlements qui établissent formellement ces politiques comme condition de base pour commencer à progresser vers la maturité en matière de sécurité.

Les politiques fournissent un socle de directives, de règlements, de règles et de pratiques qui définissent la manière dont chaque organisation gère, protège et distribue les informations. En outre, les autorités de réglementation citent souvent l’absence de politiques formelles comme une négligence, ainsi que comme un motif justifiant des amendes et des sanctions plus élevées après une violation.

Cet article examine les politiques de sécurité informatique à travers les thèmes suivants :

• Quel est l’objectif ultime d’une politique de sécurité informatique ?
• Importance et objectifs des politiques de sécurité informatique
• 6 principaux avantages des politiques de sécurité informatique
• 3 types de politiques de sécurité
• 5 bonnes pratiques pour rédiger des politiques de sécurité informatique
• Comment créer une politique de sécurité en 4 étapes
• En résumé : créer des politiques pour mieux se concentrer

Quel est l’objectif ultime d’une politique de sécurité informatique ?

L’objectif ultime d’une politique de sécurité informatique est de fournir un ensemble formalisé de règles et de politiques permettant d’évaluer la posture informatique et de cybersécurité d’une organisation. Cette référence peut servir à diverses fins, mais elle sera le plus souvent utilisée pour :

• Démontrer que les risques sont contrôlés et gérés
• Respecter les obligations de conformité
• Mesurer la qualité et les capacités des contrôles et du personnel
• Limiter les responsabilités en cas de violation

Importance et objectifs fondamentaux des politiques de sécurité informatique

Le National Institute of Standards and Technology (NIST) américain a publié Introduction à la sécurité de l’information (NIST SP 800-12), qui affirme :

« La politique de sécurité de l’information est définie comme un ensemble de directives, de règlements, de règles et de pratiques qui prescrivent la manière dont une organisation gère, protège et distribue les informations. »

Pour les organisations qui découvrent les politiques écrites, entreprendre la mise au point de politiques de sécurité peut être intimidant. Pourtant, toutes les organisations déploient des stratégies de sécurité qui constituent des stratégies non écrites et officieuses. Le principal inconvénient de ces stratégies de sécurité non écrites est que, lorsqu’elles ne parviennent pas à protéger les ressources, l’organisation aura du mal à prouver aux autorités de réglementation et aux jurys que les équipes informatiques et de sécurité ont mis en œuvre une stratégie de cybersécurité appropriée et suffisante.

Les politiques écrites, en particulier celles qui exigent des rapports réguliers, produisent naturellement les preuves de conformité. Elles montrent également l’existence d’une stratégie de sécurité formelle approuvée par la direction de l’entreprise.

Plus important encore, les politiques écrites permettent d’atteindre des objectifs clés de sécurité informatique qui auront un impact quotidien sur l’organisation, en formalisant les stratégies, buts et objectifs de sécurité informatique ; en gérant le comportement des utilisateurs ; et en mesurant la réussite de la sécurité informatique.

Formaliser les stratégies, buts et objectifs de sécurité informatique

Les politiques écrites fournissent des instructions écrites qui peuvent servir à présenter la stratégie visée par l’organisation. La plupart des stratégies se concentrent sur les principaux objectifs de la sécurité de l’information :

• Confidentialité : Autoriser l’accès à certaines données uniquement aux utilisateurs qui en ont besoin
• Intégrité : Empêcher toute modification accidentelle ou non autorisée des données stockées ou en transit
• Disponibilité : Fournir aux utilisateurs légitimes un accès continu aux données et aux systèmes

Cependant, les pratiques existantes n’intègrent pas toujours les bonnes pratiques ni ne répondent adéquatement à ces objectifs clés. Le processus d’élaboration d’une politique de sécurité aide l’équipe de sécurité informatique à réfléchir aux pratiques actuelles et à les améliorer, puisqu’elle est obligée de les mettre par écrit et de les comparer aux objectifs et aux exigences de conformité.

Le processus de création des politiques contribue également à aligner les buts et objectifs de sécurité informatique sur ceux de l’entreprise, car la politique est examinée par des dirigeants non techniques concernés par ses dispositions. Au final, l’organisation devrait bénéficier d’une politique qui fournit des stratégies, buts et objectifs formels permettant la croissance de l’entreprise tout en la protégeant grâce à des stratégies de sécurité informatique validées.

Gérer le comportement des utilisateurs

Les politiques définissent les règles d’utilisation et d’accès acceptables, ainsi que les sanctions applicables en cas de non-respect, pour tous les types d’utilisateurs, des utilisateurs invités du réseau Wi-Fi public aux personnes disposant d’un accès administratif aux serveurs du centre de données. Ces politiques écrites orientent ensuite les paramètres des outils de gestion des identités et des accès (IAM) ou de gestion des accès à privilèges (PAM).

Bien sûr, les outils IAM et PAM peuvent être déployés sans politiques écrites, mais celles-ci garantissent l’application de règles cohérentes dans toute l’organisation. Les politiques formelles fournissent également une référence à laquelle les pratiques peuvent être comparées afin de déterminer si elles sont suffisantes et conformes.

Mesurer la réussite de la sécurité informatique

Une politique efficace définit clairement les attentes envers l’équipe de sécurité informatique. Les rapports exigés par les politiques doivent montrer la conformité à la politique et permettre à l’équipe de mesurer sa réussite dans l’atteinte des objectifs de la politique.

Même si les employés s’efforcent toujours de réussir, les insuffisances peuvent également servir à justifier une augmentation des ressources. Par exemple, si les rapports exigés par la politique de gestion des correctifs montrent que l’application des mises à jour critiques prend plus de temps que souhaité, la direction peut envisager d’ajouter des ressources ou d’externaliser certaines fonctions.

6 principaux avantages des politiques de sécurité informatique

Les organisations de toutes tailles ont tendance à éviter les contraintes de la documentation, car la tâche paraît accablante, fastidieuse et contraignante. Pourtant, une politique de sécurité efficace offre six avantages clés : le renforcement de l’environnement informatique, la protection des employés, la tranquillité d’esprit des dirigeants et des membres du conseil d’administration, la protection contre les poursuites, la simplification de la conformité et l’amélioration de l’efficacité et de la résilience opérationnelles.

Renforcement de l’environnement informatique

L’élaboration d’une politique de sécurité efficace permet naturellement de mettre en place un processus de sécurité qui renforce l’environnement informatique contre les attaques. Même si certains considèrent la conformité comme la principale motivation des politiques écrites, le processus de création de la politique oblige les équipes de sécurité à évaluer les systèmes plus rigoureusement et à traiter les problèmes susceptibles d’être négligés au quotidien.

Protection des employés

Malgré tous les efforts de l’équipe informatique, des personnes cliqueront toujours sur des liens d’hameçonnage, de nouvelles vulnérabilités zero-day seront toujours découvertes et les contraintes de ressources de l’entreprise pourront obliger à laisser certaines vulnérabilités exposées. Même si le respect des politiques de sécurité peut réduire les risques, des attaques peuvent encore réussir à causer des dommages à l’organisation.

Dans de nombreux cas, les dirigeants peuvent d’abord chercher un bouc émissaire à blâmer pour un incident, et les équipes informatiques ou de sécurité sont souvent ciblées. Une équipe informatique ou de sécurité capable de démontrer qu’elle respecte une politique de sécurité approuvée par la direction montre également que tous les efforts raisonnables ont été faits pour prévenir d’éventuelles violations. Cette documentation peut protéger les employés contre un traitement injuste après une violation et préserver leur emploi.

Tranquillité d’esprit des dirigeants et des membres du conseil d’administration

Les politiques de sécurité efficaces exigent des rapports pouvant être communiqués aux dirigeants non techniques afin de renforcer leur confiance dans les équipes informatiques et de sécurité. Les politiques condensent les détails techniques en rapports chiffrés et en indicateurs faciles à comprendre, qui rendent l’état des processus de sécurité compréhensible et accessible aux dirigeants non techniques.

Des rapports clairs facilitent la communication avec les dirigeants et le conseil d’administration d’une organisation, contribuant ainsi à renforcer la confiance dans sa posture de sécurité. Ces rapports montrent non seulement que l’organisation accorde une priorité élevée à la sécurité de l’information, mais renforcent aussi une confiance susceptible de se traduire par un soutien accru à l’obtention de ressources supplémentaires.

Protection contre les poursuites

En cas de violation ou d’attaque de cybersécurité réussie, des organismes publics ou des parties prenantes peuvent tenter d’engager des poursuites contre l’organisation. Heureusement, les normes juridiques n’exigent généralement que des « efforts raisonnables », qui peuvent être étayés par la documentation issue d’une politique de sécurité efficace et par les rapports démontrant que les politiques ont été mises en œuvre.

Les organisations dépourvues de processus et de rapports formels devront se démener pour déterminer quelle documentation pourrait être nécessaire afin d’étayer les efforts passés, puis espérer disposer encore des journaux archivés ou d’autres données nécessaires à sa création. Les organisations dotées d’une documentation et de rapports formels disposeront déjà d’une grande partie de leurs éléments de preuve, prêts à être présentés avec un minimum d’efforts ou de perturbations pour l’activité.

Simplification de la conformité

Une politique de sécurité efficace doit être conçue pour refléter les exigences de conformité de l’organisation. Les auditeurs demandent toujours des politiques écrites afin de comprendre facilement les objectifs de l’organisation et le type de preuves qu’ils peuvent s’attendre à recevoir.

Le respect d’une politique écrite déjà conforme à un référentiel de conformité permet à l’organisation de satisfaire facilement aux exigences réglementaires. Les rapports internes réguliers de l’organisation fourniront naturellement des preuves de conformité, sans effort ni étape supplémentaire.

Amélioration de l’efficacité et de la résilience opérationnelles

Un portefeuille efficace de politiques de sécurité peut aider l’organisation à :

• Identifier les matériels et logiciels en fin de vie afin de les remplacer
• Identifier rapidement les infrastructures mises à rude épreuve par une attaque, une défaillance ou la charge de travail
• Vérifier les paramètres et l’intégration entre les systèmes
• Garantir la résilience des systèmes afin de réduire les temps d’arrêt
• Garantir l’intégrité et la disponibilité des données
• Documenter la disponibilité pour les accords internes et les accords de niveau de service client (SLA)

La survie de l’entreprise dépend de la disponibilité et de la protection des actifs. La documentation formalisée des processus de sécurité fournit une liste de contrôle interne destinée à protéger les actifs, à maintenir la disponibilité et à limiter les erreurs.

Les politiques écrites facilitent également les transitions du personnel informatique en fournissant une documentation des attentes et des rapports sur l’activité passée. Ces éléments permettent de gagner du temps, car ils aident les nouveaux employés informatiques à comprendre l’état et les attentes de l’organisation avec moins de formation.

3 types de politiques de sécurité

Lorsqu’elle élabore un ensemble complet de politiques de sécurité, une organisation peut se perdre dans les détails. À lui seul, le SANS Institute fournit des modèles pour plus de 60 politiques différentes ! Ces politiques granulaires sont utiles à une organisation mature, mais une organisation qui débute a besoin de davantage de lignes directrices.

Les trois types de politiques définis par le National Institute of Standards and Technology (NIST) Special Publication 800-12 comprennent les politiques de programme, les politiques propres à un problème et les politiques propres à un système.

Les politiques de programme fournissent des orientations stratégiques de haut niveau pour l’ensemble du programme de sécurité de l’information. Il peut s’agir de programmes uniques, comme cette politique de programme de l’Université de l’Arizona, qui présente une vue d’ensemble des buts et objectifs du programme de sécurité. Ces politiques sont conçues pour rester pérennes et ne pas nécessiter de mises à jour fréquentes ; elles renvoient souvent à d’autres types de politiques dans une annexe, laquelle peut être mise à jour plus fréquemment sans nécessiter de modifier la politique de programme elle-même. Les politiques de programme sont généralement trop vagues pour être mesurées ou vérifiées. Parmi les autres politiques de programme non liées à la sécurité peuvent figurer la continuité d’activité ou la gestion des risques.

Les politiques propres à un problème fournissent des orientations ciblées pour certains composants du programme de sécurité de l’information, mais à un niveau d’abstraction qui décrit les buts, les objectifs et les exigences de reporting, plutôt que de nommer des outils, des techniques et des paramètres précis. Ces politiques doivent être réexaminées périodiquement afin de rester à jour face aux évolutions organisationnelles, technologiques ou réglementaires. Parmi les exemples de politiques de sécurité propres à un problème figurent les politiques de sécurité réseau, de mots de passe, des terminaux et de chiffrement. Certaines politiques propres à un problème peuvent relever de plusieurs politiques de programme, comme celles relatives à la sauvegarde des données (sécurité, continuité d’activité) ou à l’utilisation acceptable par les employés (sécurité, ressources humaines).

Les politiques propres à un système décrivent la manière dont les politiques propres à un problème seront appliquées et contrôlées sur des systèmes précis. Il peut s’agir, par exemple, de la manière dont les politiques de sécurité réseau, d’accès des utilisateurs, de gestion des vulnérabilités et de contrôle des changements seront appliquées à un pare-feu précis ou à une catégorie de serveurs dans un centre de données. Ces politiques détaillées seront appliquées au moyen de paramètres configurés sur les appareils ou d’un logiciel centralisé capable de les gérer.

Politiques courantes propres à un problème

Pour une organisation qui commence à mettre en œuvre des politiques de sécurité, l’accent doit être mis en premier lieu sur les politiques propres à un problème qui sont pertinentes. Les politiques clés précises dépendront de l’organisation. Même si beaucoup commenceront par les politiques d’accès, de réseau, des terminaux et des mots de passe, ces priorités correspondent à un environnement informatique traditionnel. Un petit bureau virtuel de cinq courtiers utilisant Google Workspace pourrait plutôt se concentrer sur des politiques de sécurité des données, de sauvegarde des données et d’accès à distance afin de respecter les exigences de la SEC et de la FINRA.

Voici 10 politiques courantes propres à un problème et politiques connexes :

• Politique d’utilisation acceptable (AUP)
• • Indique à l’organisation comment les utilisateurs finaux sont autorisés à utiliser les systèmes et services informatiques (ordinateurs, réseaux, données, Internet, e-mails)
  • Politiques connexes : politique de formation à la sensibilisation à la sécurité, politique d’accès des dirigeants et des administrateurs
• Politique d’accès
• • Indique à l’organisation comment classifier, appliquer et gérer l’accès, l’authentification et la traçabilité des utilisateurs pour différentes classifications de systèmes et de données
  • Politiques connexes : politique d’accès physique, politique d’accès aux systèmes, politique d’accès à privilèges, politique d’accès à distance (pouvant inclure des politiques de bureau à distance [RDP] ou de réseau privé virtuel [VPN]), politique de mots de passe, politique de gestion des identités et des accès, politique d’authentification multifacteur (MFA), politique de gestion des fournisseurs
• Politique de sécurité des applications
• • Indique à l’organisation comment sécuriser le développement du code et les connexions aux autres ressources de l’entreprise
  • Politiques connexes : politique de sécurité des interfaces de programmation d’applications (API), politique de sécurité des bases de données, politique de développement des applications
• Politique de sécurité du cloud
• • Indique à l’organisation comment sécuriser l’accès, les données, les réseaux et les applications sur des ressources cloud
  • Politiques connexes : politique d’utilisation du cloud, politique de sécurité du logiciel en tant que service (SaaS), politique d’infrastructure en tant que service (IaaS)
• Politique de gestion des données
• • Indique à l’organisation comment assurer la conservation, la gestion et la sécurité de différentes classifications de données
  • Politiques connexes : politique de conservation des données, politique de protection contre les menaces internes, politique de chiffrement et de cryptographie, politique de sécurité de l’information, politique de classification des données et des actifs, politique relative aux données réglementées
• Plan de reprise d’activité
• • Indique à l’organisation comment procéder à la reprise de ses activités dans diverses situations d’urgence
  • Politiques connexes : politique de sauvegarde, politique de redondance, politique de planification de la capacité, politique de tests de résistance 
• Politique de sécurité des terminaux
• • Indique à l’organisation comment sécuriser l’accès, les données et les applications sur les terminaux utilisés par les utilisateurs et connectés au réseau et aux autres ressources de l’organisation
  • Politiques connexes : politique de sécurité des terminaux, politique de sécurité relative à l’utilisation d’appareils personnels (BYOD), politique relative aux appareils mobiles, politique de sécurité des serveurs, politique de sécurité des conteneurs
• Politique de réponse aux incidents et de surveillance
• • Indique à l’organisation comment détecter, identifier, valider, suivre, atténuer, corriger et gérer les incidents de sécurité potentiels
  • Politiques connexes : politique de suivi des journaux et d’audit, politiques propres aux attaques (rançongiciel, DDoS, etc.), politique de réponse aux violations de données
• Politique de sécurité réseau
• • Indique à l’organisation comment sécuriser l’accès et les flux de données, et surveiller les connexions entre les utilisateurs et les données
  • Politiques connexes : politique de sécurité des pare-feu, politique de sécurité réseau, politique de protection et de sécurité des e-mails, politique relative aux réseaux sans fil et à l’accès des invités
• Politique de gestion des vulnérabilités
• • Indique à l’organisation comment localiser, valider, hiérarchiser, atténuer et suivre les vulnérabilités
  • Politiques connexes : politique de gestion des correctifs, politique de gestion des changements, politique d’analyse des vulnérabilités, politique de tests d’intrusion

5 bonnes pratiques pour rédiger des politiques de sécurité informatique

Une organisation peut créer une politique de sécurité efficace en suivant cinq bonnes pratiques essentielles : se concentrer sur ce qu’il faut faire plutôt que sur la manière de le faire, rendre les politiques pratiques, leur donner une longueur adaptée, les maintenir distinctes et les rendre vérifiables.

Se concentrer sur ce qu’il faut faire, pas sur la manière de le faire

La technologie évolue si rapidement qu’une politique ne peut généralement pas suivre les détails techniques, tels que les outils de sécurité et les spécificités de l’architecture informatique. Lors de la rédaction d’une politique informatique, celle-ci doit se concentrer sur les objectifs de haut niveau, les principaux livrables et les exigences de conformité.

L’équipe informatique utilisera ensuite ces exigences avec les contraintes budgétaires et de personnel pour élaborer une solution adaptée. Un excès de détails oblige soit à mettre constamment la politique à jour, soit à imposer à l’équipe informatique des outils, pratiques ou points de vue obsolètes susceptibles, au bout du compte, d’affaiblir la sécurité au lieu de la renforcer. Si nécessaire, des annexes ou des rapports supplémentaires peuvent fournir les détails susceptibles de devoir être modifiés plus fréquemment que la politique elle-même.

Certaines organisations considèrent les politiques propres à un système comme une exception nécessitant des descriptions détaillées des outils, des paramètres et des utilisateurs autorisés. D’autres, toutefois, maintiennent ces politiques à un niveau élevé et conservent des instructions de travail précises qui en détaillent les éléments. Il s’agit d’une question de préférence pour chaque organisation.

Rendre les politiques pratiques

Les politiques de sécurité ne seront pas efficaces si elles ne conviennent pas à l’équipe chargée de leur application, si elles ne sont pas compréhensibles ou si elles ne correspondent pas à l’organisation. Dans certains cas, ces objectifs peuvent entrer en conflit, et l’équipe chargée de rédiger la politique devra travailler avec les parties prenantes pour parvenir à un équilibre efficace.

Des politiques adaptées aux parties prenantes

Les politiques adaptées aux parties prenantes seront plus facilement adoptées par les équipes informatiques et de sécurité chargées de leur mise en œuvre, ou par les utilisateurs concernés. Lorsque les politiques imposent trop de changements, des exigences irréalistes ou dépassent les contraintes de ressources, elles risquent d’être affaiblies, contournées ou ignorées.

Pour élaborer des politiques adaptées aux parties prenantes, évitez de modifier radicalement les pratiques ou d’ajouter des détails et des instructions inutiles. Sauf si la conformité ou les bonnes pratiques l’exigent, appuyez-vous sur les pratiques existantes afin de favoriser une adoption rapide par les utilisateurs concernés comme par les équipes chargées de faire respecter la politique.

Utilisez également des intitulés plutôt que des noms, et des catégories d’outils plutôt que les noms d’outils de sécurité précis. Cela évite de devoir modifier la politique à chaque changement d’outil, de personnel ou de prestataire.

Des politiques compréhensibles

Tous les lecteurs n’ont pas l’anglais comme langue maternelle, en particulier dans les entreprises internationales qui cherchent à standardiser leurs politiques à l’échelle mondiale. Lors de la rédaction des politiques, utilisez un langage simple et clair, destiné aussi bien aux personnes non techniques qu’aux personnes non juristes.

Au cours de la rédaction, le document doit être distribué aux dirigeants, aux conseillers juridiques et aux principaux membres du personnel chargés de mettre la politique en œuvre. Toute confusion, imprécision ou incertitude doit être traitée et éliminée avant l’approbation de la politique.

Répondre aux besoins de l’organisation

Les outils et les processus doivent répondre aux besoins réels de l’organisation et ne doivent pas être suivis aveuglément ou sans réflexion. Même si chaque organisation doit commencer à rédiger ses politiques en se fondant sur ses pratiques et capacités existantes, cela peut conduire à conserver par écrit des processus incomplets. L’organisation doit examiner attentivement son environnement et veiller à ce que la politique réponde à ses besoins réels.

Par exemple, l’équipe informatique d’un hôpital peut utiliser un outil commercial pour analyser les vulnérabilités de son environnement informatique, mais cet outil peut se limiter aux PC, aux équipements réseau et aux serveurs, laissant sans analyse un vaste éventail d’appareils de technologies de santé. Les exigences de sa politique ne doivent pas refléter les seuls appareils actuellement analysés, mais l’ensemble des appareils qui doivent être inclus dans le processus de gestion des vulnérabilités.

Les politiques doivent également prévoir un nombre minimal d’exceptions, qui doivent être documentées. Si les dirigeants du comité de direction insistent pour être exemptés de la politique relative aux mots de passe, ils doivent également être prêts à justifier cette exemption devant un tribunal une fois que l’entreprise aura subi une violation. Comme les employés, les cadres dirigeants doivent comprendre les politiques de sécurité, les approuver et y être soumis.

Adapter la longueur des politiques

Les politiques ne doivent être ni plus longues ni plus courtes que nécessaire. Les équipes informatiques et de sécurité privilégient souvent les politiques courtes, car l’absence d’exigences définies leur offre une flexibilité maximale dans leur mise en œuvre. Toutefois, cette absence d’exigences définies laisse souvent des lacunes ou rend les politiques difficiles à vérifier pour la direction ou les équipes chargées de la conformité.

À l’inverse, les juristes estiment souvent nécessaire de verrouiller autant de détails que possible afin de simplifier la vérification et de clarifier un maximum de points. Malheureusement, cela tend souvent à produire des exigences trop prescriptives qui enferment une équipe informatique dans les exigences du moment et laissent peu de marge pour s’adapter à un environnement informatique dynamique.

Ces forces opposées doivent être équilibrées. Les équipes informatiques, les dirigeants et les juristes doivent collaborer pour produire un document suffisamment détaillé afin que l’équipe informatique puisse démontrer clairement sa conformité à la politique, mais pas au point que celle-ci devienne une entrave au processus de gestion des vulnérabilités.

Maintenir des politiques distinctes

Les équipes chargées de la sécurité et de la conformité chercheront les informations dans les politiques attendues. Par exemple, pour consulter les politiques relatives à la protection des terminaux, la plupart commenceront par rechercher une politique de sécurité générale ou une politique spécifique de protection des terminaux. Enfouir ces informations dans une politique de gestion des vulnérabilités n’est pas intuitif et peut prêter à confusion.

Les équipes chargées de créer les politiques de sécurité doivent également éviter la tentation de copier-coller des éléments d’autres politiques existantes, comme une politique relative aux mots de passe, dans des politiques connexes (accès à distance, protection des terminaux, etc.) par souci d’exhaustivité. À moins que les documents ne soient liés afin de permettre des mises à jour automatiques, les informations copiées deviendront rapidement obsolètes. Au lieu d’insérer des sections d’autres politiques existantes, faites-y référence lorsque cela est nécessaire.

Chaque politique doit être complète en elle-même, avec un chevauchement minimal. Les chevauchements avec d’autres politiques peuvent entraîner des contradictions, des incertitudes et des lacunes en matière de conformité et de sécurité. Si une organisation décide de regrouper des politiques, elle doit produire un index ou un guide afin d’aider les membres des équipes à localiser rapidement les informations.

Rendre les politiques vérifiables

Les politiques vagues, dont les livrables sont flous et indéfinis, ne satisfont que l’exigence de disposer d’une politique, et non celle d’en avoir une qui soit utile. Les politiques efficaces définissent clairement les livrables, afin que l’équipe informatique ou de sécurité puisse satisfaire sans difficulté aux exigences de la politique.

Le processus de sécurité doit être mesurable et testable afin de démontrer la conformité à la politique ainsi qu’aux cadres de conformité pertinents. Les exigences en matière de rapports doivent documenter les indicateurs à mesurer, définir les éléments de preuve nécessaires (fichiers journaux, analyses des vulnérabilités, etc.), préciser la fréquence des rapports et indiquer leurs destinataires.

Comment créer une politique de sécurité en 4 étapes

Les organisations, grandes ou petites, peuvent créer une politique de sécurité fonctionnelle en suivant quatre étapes clés : définir les principes de la politique de sécurité, vérifier la politique de gestion des vulnérabilités, approuver la politique de gestion des vulnérabilités, puis examiner et modifier la politique de gestion des vulnérabilités.

Définir les principes de la politique de sécurité

La personne ou l’équipe chargée de rédiger la politique doit d’abord définir les règles et étapes essentielles de la politique de gestion des vulnérabilités. Voici quelques questions fondamentales auxquelles il convient notamment de répondre :

• Qui est responsable du processus ou de la norme de sécurité ?
• Quelles personnes, quels actifs ou quels systèmes seront couverts par le processus ou la norme de sécurité ?
• Quels sont les processus, normes, composants et priorités de sécurité pour chacun d’eux ?
• Comment le processus ou la norme de sécurité peut-il être validé et vérifié ?
• Quels rapports sont nécessaires pour établir et mesurer la réussite et la conformité du processus ou de la norme de sécurité ?

Vous ne savez pas par où commencer ? Notez la pratique actuelle. La plupart des équipes informatiques disposent d’au moins un processus informel pour presque toutes les pratiques de sécurité, même s’il n’est ni écrit ni surveillé. Cette première version peut simplement prendre la forme de notes. Les paragraphes et la formulation officiels pourront être rédigés ultérieurement, une fois les principes de base définis.

Vérifier la politique de sécurité

Une fois les règles ou principes de base établis, l’équipe chargée de l’élaboration de la politique doit les vérifier au regard des exigences externes et des limites pratiques.

Exigences externes applicables aux politiques de sécurité

Chaque organisation est soumise à des réglementations générales ou spécifiques émanant de gouvernements internationaux, fédéraux, régionaux ou locaux. En outre, elle peut être contrainte de se conformer à des cadres de conformité (NIST, PCI DSS, etc.) et à des normes sectorielles.

Certaines normes de conformité seront générales et vagues, tandis que d’autres seront détaillées ou comporteront des exigences précises. L’équipe chargée de l’élaboration de la politique doit vérifier ces réglementations externes et réviser toute règle qui ne satisfait pas aux exigences de conformité.

Limites pratiques des politiques de sécurité

La plupart des organisations disposent de ressources limitées, et les politiques idéalisées ne tiennent souvent pas compte de ces limites. L’équipe chargée de l’élaboration de la politique de sécurité doit tester les règles proposées avec les équipes informatiques et de sécurité. Si ces équipes ne peuvent pas respecter les normes et exigences avec leurs ressources actuelles, l’organisation devra adapter les règles ou les ressources en conséquence.

Par exemple, lors de l’élaboration d’une politique de gestion des correctifs, l’équipe informatique peut ne pas être en mesure de respecter les exigences du calendrier de gestion des correctifs avec les outils et les ressources humaines actuels. L’organisation devra alors envisager de modifier le calendrier (si les exigences de conformité l’autorisent) ou d’ajouter des ressources (mise à niveau des outils, renforcement des effectifs, externalisation, etc.).

Approuver la politique de sécurité

Après vérification des règles proposées pour la politique de sécurité, celles-ci doivent être officialisées et approuvées par la direction de l’organisation. C’est le moment de transformer les notes préliminaires en paragraphes, tableaux et annexes formels.

Une fois la politique rédigée, transmettez-la à la direction de l’entreprise et aux conseillers juridiques pour examen et approbation. La politique peut être modifiée si nécessaire, puis la version finale doit être signée par les dirigeants de l’organisation afin de ratifier les exigences et d’en prendre acte.

Examiner et modifier la politique de sécurité

Même si la politique de sécurité est approuvée à la troisième étape, l’organisation, les ressources informatiques et la réglementation évolueront au fil du temps. Toutes les politiques doivent être des documents évolutifs, qui changent avec l’organisation, et doivent être régulièrement examinées et mises à jour. En général, les politiques sont examinées selon un calendrier fixe (trimestriel, annuel, semestriel, etc.) ; toutefois, des événements importants, tels que des changements majeurs de l’architecture informatique, l’adoption d’outils de sécurité très différents ou une violation de sécurité, peuvent justifier un examen exceptionnel.

En résumé : créer des politiques pour mieux se concentrer

Les organisations ont tendance à considérer les documents officiels comme une contrainte, mais des politiques efficaces de sécurité informatique leur permettent d’améliorer leur posture de sécurité, de consacrer moins de temps à la conformité et d’éliminer de nombreuses sources d’inquiétude. Grâce à des politiques à jour et efficaces, les entreprises grandes et petites, les organisations à but non lucratif et même les administrations peuvent valider leur posture de sécurité présumée et acquérir la confiance nécessaire pour se concentrer sur les enjeux plus critiques pour leur mission principale. 

Pour en savoir plus sur les sujets connexes, consultez notamment :

• Politique de gestion des vulnérabilités : étapes, avantages et modèle gratuit
• Politique de gestion des correctifs : étapes, avantages et modèle gratuit