Dans cette série de tableaux de bord de sécurité pour RSSI, je présente des « templates »pouvant être utilisés directement par les RSSI ou avec des adaptations. Le Tableau de bord de sécurité « Suivi des incidents de sécurité » répond à deux objectifs: – un suvi journalier des incidents avec des jauges, pouvant passer du vert, au jaune et au rouge. Cela permet au RSSI d'avoir un suivi temps réel des incidents de sécurité selon la gravité et le nombre. – un suivi mensuel des incidents de sécurité avec une comparaison avec l'année précédante, pour évaluer l'évolution de la sécurité. Tableau de bord: Suivi des incidents de sécurité N. B: il est possible de filtrer les informations selon les périmètres, les vendeurs (OS, etc), et les types d'incidents et les services de sécurité concernés.
Pour ne pas décourager les destinataires de ses tableaux de bord, le RSSI se doit donc de ruser, en adaptant sa présentation aux attentes. Concrètement, un tableau de bord agréable à consulter pour un non-sachant est avant tout synthétique. Un tableau de bord SSI stratégique doit ainsi permettre aux décideurs de comprendre très rapidement où se trouvent les problèmes potentiels, et quel niveau d'investissement consentir pour couvrir le risque. Pour rappel, l'ANSSI (alors nommée DCSSI à l'époque) recommandait déjà en 2004 de se limiter à 6 indicateurs dans les tableaux de bord stratégiques, pour répondre aux besoins des directions de ne disposer que d'informations concises et génériques. Bien évidemment, la forme compte également: un bon tableau de bord doit aussi être clair, lisible et même « parlant ». Les RSSI, pour améliorer leur présentation peuvent ainsi avoir recours à deux bonnes pratiques: Les représentations visuelles: il est possible de représenter le risque de bien des façons, que ce soit avec un simple schéma en deux dimensions (impact du risque/fréquence par exemple) ou sous forme de radar.
Dans nos prochains billets, nous nous intéresserons au cœur du sujet, à savoir au choix d'indicateurs de sécurité pertinents et aux écueils à éviter lors de la mise en place d'un tableau de bord. Le prochain billet traitera de l'élaboration des tableaux de bord.
Dans un premier temps, l'objectif suivi à court terme est de permettre aux entreprises de disposer d'une boite à outils d'indicateurs afin de communiquer en interne et de se comparer en interne entre filiales. Dans un second temps, les entreprises pourront éventuellement se comparer entre elles, si elles le souhaitent, soit de gré à gré, soit en se réunissant au CIGREF et en définissant une méthode commune de calcul des indicateurs. Les quatre axes stratégiques d'un tableau de bord sécurité Télécharger: Tableau de bord Sécurité: indicateurs clés de la sécurité système d'information
Les procédures de sécurité IT sont-elles correctement appliquées par la DSI et les métiers, notamment en matière de protection et de traçabilité des données? Sur cette question, le Cigref recommande d'appliquer trois indicateurs annuels: L e taux de contrôle (nombre d'audits de sécurité effectué sur le nombre d'audits cible); Le taux de conformité (nombre d'audits effectués avec succès sur le nombre d'audits effectués); Le taux de correction (nombre d'audits corrigés sur le nombre d'audits défectueux). Plusieurs éléments permettent de prendre la mesure du niveau de structuration de l'organisation et de la gouvernance de la sécurité du système d'information. Les comités de sécurité stratégique - en général au moins une fois par an - ont-ils bien lieu? Qu'en est-il des comités de sécurité opérationnels - dont la tenue doit être en principe trimestrielle? Enfin, le nombre de correspondants SSI responsables de la bonne application des règles de sécurité informatiques est-il suffisant? Quel est leur nombre au regard du nombre de filiales du groupe?
- Optimisation de nombreuses parties du code (chargement ciblé des bibliothèques, classe groupe_moyens, menu opérationnel,... ). - Technique d'imbrication du code HTML et PHP dans les pages de vue modifiée: pour une meilleure visibilité, le code HTML ne fait plus du tout parti de chaines de caractères PHP, le code PHP est uniquement imbriqué dans le HTML. - Rajout de nombreux controles d'erreur dans les modules WEB et Collecte, contenu des messages d'erreur plus précis dans les logs du module collecte(erreurs SQL et commandes shell). Importantes modifications de l'API: - Encapsulation de chaque plugin au sein d'une fonction afin d'éviter des problèmes de collision de noms de variables. - Création de classes supplémentaires dans l'API, les éléments de plugins et champs d'éléments de plugins. Ces classes fournissent un cadre de développement strict, autonome et controlé qui permet de simplifier l'architecture et la compréhension d'un plugin. Ces nouvelles classes assurent également une fonction de validation afin de faciliter la gestion des erreurs et le débugage.