Fermer

septembre 17, 2024

Besoin d’une feuille de route en matière de sécurité ? Abandonnez la mesure ad hoc

Besoin d’une feuille de route en matière de sécurité ? Abandonnez la mesure ad hoc


Les RSSI ne peuvent connaître les performances et la maturité de leur programme de sécurité qu’en les mesurant activement eux-mêmes ; après tout, mesurer, c’est savoir. Grâce à des mesures proactives, les RSSI confirmeront les performances de leur programme de sécurité, comprendront mieux son état de préparation contre les menaces pertinentes et mettront en évidence les lacunes qui nécessitent des améliorations.

Cependant, les RSSI ne mesurent généralement pas leur programme de sécurité de manière proactive ou méthodique pour comprendre leur programme de sécurité actuel. Ils comptent plutôt sur pour ça des intrants tels que des audits informatiques, des résultats de pentest, des évaluations de sécurité ponctuelles, une analyse du registre des risques et une compréhension générale de leur programme.

Pourquoi les RSSI ont besoin d’informations mieux mesurées

Les RSSI subissent une pression accrue non seulement pour sécuriser l’organisation, mais aussi pour le faire de manière démontrée. Cette pression accrue provient des clients finaux exigeant des produits et services sécurisés, ainsi que de l’entreprise, du conseil d’administration et des régulateurs.

Parmi les nouvelles réglementations comportant des exigences de sécurité plus élevées et une charge accrue de démontrer la sécurité figurent les suivantes :

  • La disposition révisée de la SEC des États-Unis sur la divulgation des incidents de cybersécurité, qui exige que les incidents ou violations de cybersécurité importants soient divulgués à la SEC dans les quatre jours ouvrables après qu’une organisation a déterminé que l’incident est important.
  • La loi sur la résilience opérationnelle numérique (DORA) de l’Union européenne, qui exige de renforcer la sécurité des entités financières dans l’UE
  • La directive NIS2 de l’UE, qui introduit des exigences plus strictes en matière de cybersécurité pour les organisations qui fournissent des services essentiels aux secteurs de l’énergie, des transports, de la banque, de la santé et des infrastructures numériques de l’UE.

Cette pression accrue signifie que les RSSI doivent être plus conscients de leur état de sécurité actuel et qu’une évaluation de l’état de sécurité actuel doit être basée sur des mesures, des mesures et des faits.

Définir et décrire le programme de sécurité

Avant de pouvoir mesurer un programme de sécurité, il doit être défini et décrit. La plupart des programmes de sécurité sont basés sur un cadre standard tel que le NIST Cybersecurity Framework (CSF) ou ISO27001 du ministère américain du Commerce, et personnalisés pour s’aligner sur l’entreprise, le paysage technique et informatique et les spécificités organisationnelles liées à l’organisation.

IDC, 2024

Les niveaux de maturité doivent être appliqués aux processus individuels du programme de sécurité. Cela consiste généralement à définir quatre ou cinq niveaux. Il est important de définir et de décrire clairement chaque niveau de maturité pour garantir une signification claire et cohérente des différents niveaux de maturité dans l’ensemble du programme de sécurité.

Il n’existe pas de programme de sécurité unique. Elle doit s’adapter à l’organisation et à sa taille, aux pertes potentielles, aux niveaux de risque acceptables, aux exigences réglementaires, à la nature de l’activité, au paysage informatique spécifique, au niveau de développement interne par rapport aux solutions disponibles dans le commerce, et bien plus encore.

Définir et décrire l’appétit pour le risque de sécurité

Un programme de sécurité ne doit pas nécessairement garantir une sécurité parfaite. En fait, il est impossible d’atteindre une sécurité parfaite. Un programme de sécurité doit plutôt viser à atteindre une sécurité suffisante et à réduire les risques à des niveaux acceptables pour atteindre les objectifs commerciaux globaux de l’organisation.

Pour ce faire, l’organisation et le programme de sécurité doivent définir son appétit pour le risque de sécurité. Cela se produit généralement dans le cadre d’un programme de gestion des risques où l’appétit pour le risque d’autres disciplines est également pris en compte. Si ce n’est pas le cas, cela peut se produire au sein du programme de sécurité.

Une déclaration d’appétit pour le risque fournit une description générale du risque acceptable. Il doit être rédigé de manière à ce que les collègues techniques et non techniques puissent le comprendre. Certaines organisations ont un appétit pour le risque ambitieux (elles sont très averses au risque), tandis que d’autres organisations ont un appétit pour le risque plus tolérant.

Le défi est que l’appétit pour le risque doit être compris et traduit en termes de programme de sécurité, de menaces et de risques techniques, de processus de sécurité et en termes de niveaux de maturité.

Méthodes pour mesurer les performances et comprendre l’état actuel de la sécurité

L’objectif est de pouvoir attribuer un niveau de maturité à chaque processus du programme de sécurité. Cela doit être fait aussi précisément que possible en utilisant des mesures quantitatives et qualitatives. Ceci peut être réalisé en utilisant les méthodes décrites ci-dessous.

  • Répondre à des questions standardisées avec une notation pondérée : Les questions standardisées peuvent couvrir tous les sujets requis dans un processus de sécurité (c’est-à-dire les personnes, les processus et la technologie). Plus il y a de réponses positives, plus le score est élevé, contribuant ainsi à une note de maturité globale plus élevée.
  • Des métriques clairement définies avec des seuils cibles : L’utilisation de mesures de performances permet une lecture impartiale des performances d’un processus de programme de sécurité. Les mesures doivent être basées sur les objectifs clés d’un processus de sécurité. Idéalement, ces mesures de performances existent déjà pour les processus de sécurité. Toutefois, s’ils n’existent pas, ils peuvent être introduits.
  • Interviews des contributeurs du programme de sécurité : Les entretiens apportent une meilleure compréhension des aspects qualité du processus d’un programme de sécurité. Les responsables du processus de sécurité peuvent informer l’intervieweur (généralement un professionnel de la sécurité et du risque) de la situation générale d’un processus de sécurité, expliquer les défis rencontrés (qui peuvent se traduire par des lacunes) et les activités en cours pour améliorer le processus. Les entretiens fournissent un contexte que les questions standardisées et les mesures de performance peuvent ne pas identifier.
    • Démarche d’entretien :
      • Au cours de l’entretien, parcourez le processus de sécurité de bout en bout avec le propriétaire du processus.
      • Discutez des questions standardisées et des mesures de performance pour obtenir plus de contexte et une meilleure compréhension des réponses données.
      • Demandez au propriétaire quelles sont ses lacunes et comment des améliorations peuvent être apportées.
  • Utilisation d’informations existantes provenant d’autres activités liées à la sécurité : Cela peut inclure des activités telles que des tests d’intrusion, des audits informatiques réalisés par des auditeurs internes et externes, pour ça évaluations de sécurité et divulgations responsables. L’organisation de sécurité effectue probablement déjà de nombreuses activités qui peuvent être utilisées comme points de données pour mesurer les performances de sécurité. Il est sage de réutiliser autant d’activités et de résultats que possible et de quantifier les résultats lorsque cela est possible.
  • Les résultats des tableaux de bord de sécurité opérationnels au sein du programme de sécurité : En règle générale, les programmes de sécurité disposent de tableaux de bord avec diverses mesures opérationnelles. La collection de tableaux de bord de sécurité peut être utilisée comme entrée globale pour mesurer les performances du programme de sécurité. De plus, le manque de tableaux de bord opérationnels sera également un indicateur.
  • Comparaisons avec des organisations homologues : Les comparaisons actives avec les pairs ne sont généralement pas effectuées et ne sont certainement pas basées sur des données et des mesures de performances. Cependant, la communauté de la sécurité est suffisamment petite pour que les professionnels de la sécurité soient souvent conscients des pratiques utilisées par leurs pairs. Par conséquent, ces connaissances peuvent être utilisées pour identifier les processus de sécurité en retard par rapport à leurs pairs.

Élaborer une feuille de route en matière de sécurité

Une fois l’état actuel établi en utilisant les niveaux de maturité des processus de sécurité, vous pouvez développer une feuille de route de sécurité.

  • Le point de « départ » de la feuille de route doit être bien compris (étant donné la compréhension de l’état actuel). La feuille de route doit indiquer comment les équipes peuvent construire à partir du point de départ et atteindre leur maturité cible (cela ne signifie pas nécessairement atteindre un état de perfection).
  • Les questions standardisées et les mesures de performance qui échouent doivent être abordées dans la feuille de route.
  • La priorité doit être accordée aux activités de la feuille de route qui ont le plus grand impact sur la réduction globale des risques pour l’organisation, tel que quantifié par des questions standardisées et des mesures de performance. Généralement, cela équivaut aux processus de sécurité présentant la maturité la plus faible et les lacunes les plus importantes. Cependant, certains processus de sécurité auront un impact global plus important que d’autres sur la réduction des risques (par exemple, l’amélioration de la gestion des vulnérabilités peut avoir plus d’impact que l’amélioration des politiques de sécurité et de la gouvernance).
  • L’équipe centrale de planification et de feuille de route ainsi que les responsables individuels des processus de sécurité devraient être impliqués dans l’élaboration d’une feuille de route. L’équipe de planification centrale aura une bonne connaissance de la situation dans son ensemble et les responsables individuels des processus de sécurité auront la meilleure compréhension de leur processus.
  • La feuille de route doit être élaborée en coopération avec les principales parties prenantes et les équipes de livraison à l’intérieur et à l’extérieur du service de sécurité. De nombreuses activités de la feuille de route dépendront fortement de ces parties prenantes et équipes de mise en œuvre. Le CIO et le département informatique, par exemple, auront un rôle majeur à jouer dans les activités de la feuille de route.

En savoir plus sur Recherche d’IDC pour les leaders technologiques.

International Data Corporation (IDC) est le premier fournisseur mondial d’informations commerciales, de services de conseil et d’événements pour les marchés technologiques. IDC est une filiale en propriété exclusive d’International Data Group (IDG Inc.), le leader mondial des services de médias technologiques, de données et de marketing. Récemment élu cabinet d’analystes de l’année pour la troisième fois consécutive, les solutions technologiques leaders d’IDC vous fournissent des conseils d’experts soutenus par nos services de recherche et de conseil de pointe, de solides programmes de leadership et de développement et les meilleures données d’analyse comparative et d’approvisionnement. auprès des conseillers les plus expérimentés de l’industrie. Contactez-nous dès aujourd’hui pour en savoir plus.

Nick Kirtley est conseiller de recherche adjoint auprès des programmes pour cadres informatiques (IEP) d’IDC. Il est un professionnel de la sécurité expérimenté avec une vaste expérience acquise dans de nombreuses missions de conseil et en interne au sein de divers départements de sécurité (RSSI). Nick possède des connaissances approfondies dans des sujets tels que la gestion des programmes de sécurité (et la mesure de la maturité de la sécurité), la sécurité du cloud, la sécurité DevOps, la gestion des vulnérabilités et la modélisation des menaces.




Source link