Evaluation des besoins

Votre système est-il important pour remplir vos missions ?
Non, le système est accessoire à l'accomplissement des missions.
Oui, les missions seraient fortement perturbées par un dysfonctionnement du SI.
Oui, les missions dépendent totalement du SI.
Je ne sais pas.

Si un sinistre atteint votre SI, causant un dysfonctionnement ou une perte de données, les conséquences en interne (pour vos services), seraient-elles graves ?
Exemple : une panne électrique ne permet pas d'utiliser le système, le contenu d'une base de données a été supprimé ...
Non, les conséquences internes d'un sinistre seraient négligeables.
Oui, les conséquences internes d'un sinistre seraient significatives.
Oui, les conséquences internes d'un sinistre seraient graves, voir fatales.
Je ne sais pas.

Si un sinistre touche la sécurité de votre système (il ne fonctionne plus ou pas bien, vol d'informations...), les conséquences pour l'extérieur (pour vos usagers, administrés...) seraient-elles graves ?
Non, les conséquences d'un sinistre pour l'extérieur seraient négligeables.
Oui, les conséquences d'un sinistre pour l'extérieur seraient significatives.
Oui, les conséquences d'un sinistre pour l'extérieur seraient graves, voir fatales.
Je ne sais pas.

Le fait que les données de votre système soient inaccessibles est-il grave ?
Exemple : vous ne pouvez pas accéder aux données en raison d'une panne matérielle.
Non, le fait qu'il ne soit pas accessible ne gêne quasiment pas l'activité.
Oui, le fait qu'il ne soit pas accessible perturbera l'activité de manière significative.
Oui, le fait qu'il ne soit pas accessible peut être fatal pour l'activité.
Je ne sais pas.

Le fait que les données de votre système soient altérées est-il grave ?
Exemple : un virus a modifié des valeurs dans une base de données, les remettant toutes à 0.
Non, le fait que les données soient altérées ne gêne quasiment pas l'activité.
Oui, le fait que les données soient altérées perturbera l'activité de manière significative.
Oui, le fait que les données soient altérées peut être fatal pour l'activité.
Je ne sais pas.

Le fait que les données de votre système ne soient pas ou plus confidentielles est-il grave ?
Exemple : la liste des bénéficiaires du service social est dévoilée.
Non, le défaut de confidentialité ne gêne quasiment pas l'activité.
Oui, le défaut de confidentialité perturbera l'activité de manière significative.
Oui, le défaut de confidentialité peut être fatal pour l'activité.
Je ne sais pas.

Quel est le niveau de compétence maximal présumé de l'attaquant ou du groupe d'attaquants susceptibles de porter atteinte au système ?
Individu isolé de niveau de compétence élémentaire.
Individu isolé de niveau de compétence avancé.
Groupe d'individus organisés, de niveaux individuels de compétence faibles à moyens, avec des ressources financières et matérielles limitées, ou individu isolé aux compétences expertes et moyens restreints.
Groupe d'individus experts, organisés, aux moyens quasi-illimités.

Quelle est la précision des attaques potentielles envers le SI ?
Attaques "au hasard" sur le cyberespace.
Attaques orientées vers le continent européen ou la France.
Attaques ciblant un groupe de victimes présentant des caractéristiques communes.
Attaques visant précisément le système.

Quel est le niveau de sophistication des attaques potentielles contre le SI ?
Outils d'attaque triviaux (logiciel de scan de ports, virus connus, etc...).
Outils élaborés génériques prêts à l'emploi (réseaux de botnet loué, faille connue, etc...).
Outils sophistiqués, adaptés pour le SI (zéro-day, etc...).
Boîte à outils très hautement sophistiquées.

Quelle est la visibilité des attaques potentielles contre le SI ?
Attaque annoncée (revendications "d'hacktivistes", rançon, etc...).
Attaque constatée immédiatement par ses efffets sur le SI.
Attaque discrète, qui laisse des traces dans les journaux d'événements mais ne perturbe pas le fonctionnement du SI.
Attaque invisible, réalisée en laissant le minimum de traces.

Quelles sont la fréquence et la persistance des attaques potentielles contre le SI ?
Unique : l'attaque ne se produit sur la cible d'une seule fois.
Ponctuelle : l'attaque servient plusieurs fois sans régularité dans la fréquence.
Récurrente : attaque par vagues successives importantes.
Permanente.

Quel est le niveau d'hétérogénéité du système ?
Exemple : plusieurs logiciels, matériels ou réseaux différents pour un même système.
Le système est jugé comme homogène.
Le système est jugé comme faiblement hétérogène.
Le système est jugé comme fortement hétérogène.
Je ne sais pas.

Quel est le dégré d'ouverture/interconnexion du système ?
Exemple : Internet, un autre système interne ou externe (celui d'un prestataire, d'une autre autorité admninistrative...).
Le SI n'est pas ouvert.
Le SI n'est ouvert qu'à des systèmes internes maîtrisés.
Le système est ouvert à des systèmes internes non maîtrisés ou externes.
Je ne sais pas.

Le contexte dans lequel se trouve le SI et ses composants (matériels, logiciels, réseaux) évolue-t-il régulièrement ?
Le SI et son contexte sont jugés stables.
Le SI et son contexte changent souvent.
Le SI et son contexte évoluent en permanence.
Je ne sais pas.

Les composants du SI sont-ils mis régulièrement à jour ?
Les composants du SI sont tous tenus à jour en permanence.
Une partie des composants du SI est régulièrement mise à jour.
Les mises à jour son effectuées de manière irrégulière.
Je ne sais pas.

Evaluation de la maturité SSI

Des règles relatives à la politique SSI garantissent l'existence d'une politique validée et promue par la hiérarchie, largement diffusée, tenue à jour et déclinable de manière cohérente.
Il n'existe aucun élément de politique SSI.
Les risques SSI sont parfois appréciés, mais de manière informelle, et la mise en oeuvre de mesures de sécurité destinées à traiter ces risques n'est pas forcément cohérente avec ce qui a été planifié.
Les pratiques d'appréciation des risques SSI sont relativement homogènes, bien qu'informelles ; leur utilisation est peu régulière ; la mise en oeuvre des mesures de sécurité correspond au traitement planifié.
Le processus (dont les rôles et responsabilités associés) de gestion des risques SSI (appréciation, traitement, acceptation et communication) est formalisé de manière rationnelle, une(des) démarche(s) méthodologique(s) est(sont) définie(s) pour gérer les risques SSI, ainsi que ses(leurs) conditions d'application et son(leur) utilisation est régulière.
La gestion des risques SSI est devenue une pratique standard partiellement automatisée, avec des bases de connaissances partagées ; les études sont raffinées et tenues à jour ; des objectifs mesurables sont définis et la gestion des risques SSI est suivie (ex. : tableaux de bord SSI, audits...).
La gestion des risques SSI est un processus continu (itératif), généralisé, bien automatisé, utilisé par tous les autres processus SSI, intégré aux processus métiers, bien accepté et d'uilité reconnue dans les prises de décisions.

Les règles relatives à l'organisation de la SSi définissent les rôles et responsabilités internes et externes, ainsi que les mesures de sécurité générales à mettre en oeuvre.
L'organisation SSI est inexistante.
Il existe une organisation SSI, mais informelle, occasionnellement utilisée et peu adéquate.
L'organisation de la SSI est coordonnée (planification, vérification, actions correctives), relativement homogène, mais encore informelle.
Les responsabilités et les procédures SSI sont formalisées en fonction d'une étude d'organisation, et utilisées régulièrement.
Des objectifs mesurables sont définis et la mise en oeuvre de l'organisation SSI est suivie ; le processus de gestion de l'organisation de la SSI est standard et tenu à jour.
Le processus de gestion de l'organisation de la SSI est généralisé, bien accepté et s'améliore continuellement ; il s'applique à tous les autres processus SSI et est intégré aux processus métiers.

La gestion de la continuité des activités doit être alimentée par la SSI et les plans de continuité doivent être élaborés en suivant un même modèle, testés et mis à jour.
La continuité des activités n'est pas traitée.
Des mesures de sécurité relatives à la disponibilité du système d'information (ex. : sauvegardes, redondance, transfert de compétences...) sont mises en oeuvre occasionnellement, de manière informelle et peu cohérente avec ce qui est planifié.
Les pratiques liées à la gestion de la continuité des activités (planification, vérification, actions correctives) sont coordonnées, de manière relativement homogène, mais informelle ; la mise en oeuvre correspond à la planification.
Le processus (dont les rôles et responsabilités associés) de gestion de la continuité des activités intègre la SSI de manière formalisée ; il se base sur le processus de gfestion des risques ; il existe un ou des plans de continuité élaboré(s) selon un cadre défini, et si possible sur la base de démarches méthodologiques globales.
Le processus de gestion de la continuité des activités intègre la SSI de manière systématique, standardisée, suivie et partiellement automatisée ; des objectifs mesurables sont définis ; des tests sont régulièrement réalisés.
La SSI fait partie intégrante du processus de gestion de la continuité des activités ; celui-ci est généralisé, bien automatisé, intégré aux processus métiers, appliqué à tous les autres processus SSI, bien accepté et s'améliore continuellement.

Afin d'assurer la conformité aux différentes références applicables (réglementaires, contractuelles, normatives, internes...), des règles précisent qu'un recensement doit être tenu à jour et que des vérifications de conformité doivent être régulièrment réalisées.
Le processus de vérification de la conformité est inexistant.
Le processus de vérification de la conformité existge mais n'est qu'occasionnellement utilisé, informel et peu cohérent ; il repose sur des meilleures pratiques ou des expériences individuelles.
Le processus de vérification de la conformité est coordonné, relativement homogène, mais encore informel.
Le processus de vérification de la conformité est formalisé (dont les rôles et responsabilités), utilisé régulièrement, et reposant éventuellement sur les démarches méthodologiques.
Le processus de vérification de la conformité est standard, avec des objectifs mesurables, suivi et tenu à jour, et partiellement automatisé.
Le processus de vérification de la conformité est généralisé, bien automatisé, intégré aux processus métiers, appliqué à tous les atres processus SSI, bien accepté et s'améliorant continuellement.

La gestion des biens fait l'objet de règles visant à les identifier, leur associer un propriétaire et à les gérer de manière cohérente avec leur classification.
La sécurité des biens n'est pas considérée.
La sécurité des biens est réalisée de manière occasionnelle, informelle et peu cohérente ; elle repose sur de l'expertise individuelle ou de meilleures pratiques.
La sécurité des biens est coordonnée, relativement homogène, sur la base de meilleures pratiques partagées, mais encore informelle.
La sécurité des biens repose sur un processus formalisé (dont les rôles et responsabilités), utilisé régulièrement, et sur des démarches méthodologiques.
La sécurité des biens repose sur un processus standard, avec des objectifs mesurables, suivi et tenu à jour, partiellement automatisé.
La sécurité des biens repose sur un processus généralisé, bien automatisé, en interaction avec les processus métiers, conformément aux processus de pilotage SSI et s'appuyant sur les processus de support SSI ; le processus s'amélire continuellement (exploitation des retours d'expérience...).

La sécurité liée au personnel définit les responsabilités, les vérifications et engagements, l'incitation au respect des règles, la sensibilisation, les sanctions, le retour des biens et le retrait des droits.
Les aspects humains ne sont pas spécifiquement pris en compte dans la SSI ; il n'existe aucune sensibilisation ou formation en matière de SSI.
Les aspects SSI liés aux personnels (avant, pendant et après un emploi) sont traités occasionnellement et de manière informelle : habilitation, auto-formation... ; la mise en oeuvre ne correspond pas forcément à ce qui a été planifié.
La SSI est intégrée dans la gestion des aspects humains (planification, vérification, actions correctives), de manière relativement homogène, sur la base de meilleures pratiques partagées, mais informelle ; les actions réalisées correspondent à ce qui a été planifié.
Un processus (dont les rôles et responsabilités associés) de gestion des aspects humains intégrant la SSI est défini (avant, pendant et après un emploi) et relativement utilisé ; il existe un plan de formation adapté aux profils des personnels et des labellisations d'individus peuvent être utilisées (formations reconnues, diplômantes...).
Des objectifs mesurables sont déterminés et le personnel fait l'objet d'un suivi intégrant des évaluations suite aux sensibilisations et formations ; le processus de gestion des aspects humains intégrant la SSI est systématisé.
Le processus de gestion des aspects humains intégrant la SSI est généralisé, accepté, en interaction avec les processus métiers, conformément aux processus métiers, conformément aux processus de pilotage SSI et s'appuyant sur les processus de support SSI, et s'améliore continuellement ; les ressources personnelles sont optimisées, le plan de formation est continuellement amélioré en fonctions des retours d'expérience.

Les règles relatives à la sécurité physique et environnementale visent à contrôler les accès physiques des zones de sécurité et à protéger les équipements jusqu'à leur recyclage contre le bol d'information, les accès non autorisés, les pertes d'énergie, l'altération, l'interception et les pertes de disponibilité.
La sécurité physique et environnementale n'est pas considérée.
La sécurité physique et environnementale est réalisée de manière occasionnelle, informelle et peu cohérente ; elle repose sur de l'expertise individuelle ou de meilleures pratiques.
La sécurité physique et environnementale coordonnée, relativement homogène, sur la base de meilleures pratiques partagées, mais encore informelle.
La sécurité physique et environnementale repose surun processus formalisé (dont les rôles et responsabilités), utilisé régulièrement, et sur des démarches méthodologiques.
La sécurité physique et environnementale repose sur un processus standard, avec des objectifs mesurables, suivi et tenu à jour, partiellement automatisé.
La sécurité physique et environnementale repose sur un processus généralisé, bien automatisé, en interaction avec les processus métiers, conformément aux processus de pilotage SSI et s'appuyant sur les processus de support SSI ; le processus s'améliore continuellement (exploitation de la veille et des retours d'expérience...).

Les règles d'exploitation et communications traient des procédures et responsabilités pour gérer les sous-traitants, la recette des systèmes, les codes malveillants et mobiles, les sauvegardes, la sécurité des réseaux, les supports, les échanges d'informations, le commerce électronique et la surveillance.
La sécurité de l'exploitation et des communications n'est pas considérée.
La sécurité de l'exploitation et des communications est réalisée de manière occasionnelle, informelle et peu cohérente ; elle repose sur de l'expertise individuelle ou de meilleures pratiques.
La sécurité de l'exploitation et des communications est coordonnée, relativement homogène, sur la base de meilleures pratiques partagées, mais encore informelle.
La sécurité de l'exploitation et des communications repose sur un processus formalisé (dont les rôles et les responsabilités), utilisé régulièrement, et sur des démarches méthodologiques.
La sécurité de l'exploitation et des communications repose sur un processus standard, avec des objectifs mesurables, sui et tenu à jour, partiellement automatisé.
La sécurité de l'exploitation et des communications repose sur un processus généralisé, bien automatisé, en interaction avec les processus métiers, conformément aux processus de pilotage SSI et s'appuyant sur les processus de support SSI ; le processus s'améliore continuellement (exploitation de la veille et des retours d'expérience...).

Le contrôle d'accès logique aux réseaux, systèmes d'exploitation, applications, informations et via des postes nomades fait natamment l'objet de mesures restrictives, de cloisonnement et de traçabilité.
La sécurité des accès logiques n'est pas considérée.
La sécurité des accès logiques est réalisée de manière occasionnelle, informelle et peu cohérente ; elle repose sur de l'expertise individuelle ou de meilleures pratiques.
La sécurité des accès logiques est coordonnée, relativement homogène, sur la base de meilleures pratiques partagées, mais encore informelle.
La sécurité des accès logiques repose sur un processus formalisé (dont les rôles et responsabilités), utilisé régulièrement, et sur des démarches méthodologiques.
La sécurité des accès logiques repose sur un processus standard, avec des objectifs mesurables, suivi et tenu à jour, partiellement automatisé.
La sécurité des accès logiques repose sur un processus généralisé, bien automatisé, en interaction avec les processus métiers, conformément aux processus de pilotage SSI et s'appuyant sur les processus de support SSI ; le processus s'améliore continuellement (exploitation de la veille et des retours d'expérience...).

Les règles relatives à la gestion des incidents SSI doivent permettre une remontée et un traitement des incidents et des failles détectées de manière organisée, formalisée, rapide et donc efficace.
Les incidents SSI ne sont pas traités.
Les incidents SSI font l'objet de remontées occasionnelles et informelles, et sont traités de manière occasionnelle et informelle ; ce qui est fait ne correspond pas forcément à ce qui a été planifié.
Les incidents SSI font l'objet de remontées, bien que peu régulières, et ils sont gérés systématiques (planification, vérification, actions correctives), mais de manière informelle ; la mise en oeuvre correspond à ce qui a été planifié.
Le processus (dont les rôles et responsabilités associés) de gestion des incidents SSI est formalisé (ex. : changements d'états, réseau de détection et d'alerte, procédure d'escalade, procédure de traitement...) et régulièrement utilisé ; les données des CSIRTs (Computer Security Indicent Response Teams) sont exploitées ; les remontées sont régulières.
Des objectifs mesurables sont définis et le processus de gestion des incidents SSI est globalement suivi, devenu standard et davantage automatisé (ex. : helpdesk...) ; des bases de données d'incidents SSI et de leur traitement sont alimentées de manière interactive.
Les processus de gestion des incidents SSI est en constante amélioration, généralisé, bien automatisé, en interaction avec les processus métiers, conformément aux processus de pilotage SSI et s'appuyant sur les processus de support SSI, et bien accepté.

Concernant la gestion des risques SSI, les règles y afférant la décrivent comme un processus continu comprenant l'appréciation, le traitement, l'acceptation et la communication.
Il n'existe aucun gestion des risques SSI.
Les risques SSI sont aprfois appréciés, mais de manière informelle, et la mise en oeuvre de mesures de sécurité destinées à traiter ces risques n'est pas forcément cohérente avec ce qui a été planifié.
Les pratiques d'appréciation des risques SSI sont relativement homogènes, bien qu'informelles ; leur utilisation est peu regulière ; la mise en oeuvre des mesures de sécurité correspond au traitement planifié.
Le processus (dont les rôles et les responsabilités associés) de gestion des risques SSI (appréciaiton, traitement, acceptation et communication) est formalisé de manière rationnelle, une(des) démarche(s) méthodologique(s) est(sont) définie(s) pour gérer les risques SSI, ainsi que ses(leurs) conditions d'application et son(leur) utilisation est régulière.
La gestion des risques SSI est devenue une pratique standard partiellement automatisé, avec des bases de connaissances partagées ; les études sont raffinées et tenues à jour ; des objectifs mesurables sont définis et la gestion des risques SSI est suivie (ex. : tableaux de bord SSI, audits...).
La gestion des risques SSI est un processus continu (itératif), généralisé, bien automatisé, utilisé par tous les autres processus SSI, intégré aux processus métiers, bien accepté et d'utilité reconnue dans les prises de décisions.

S'agissant d'acquisition, développement et maintenance de SI, il convient d'intégrer la SSI dans les projets et l'exploitation, de tester suffisamment les applications, d'employer les moyens cryptographiques, de protéger les fichiers systèmes et de traiter les vulnérabilités connues.
La SSI n'est pas pris en compte dans le cycle de vie des systèmes.
Des meilleurs pratiques SSI sont occasionnellement et informellement utilisées dans le cycle de vie des systèmes ; la mise en oeuvre ne correspond pas forcément à ce qui a été planifié.
Les meilleurs pratiques SSI sont intégrées dans le cycle de vie des systèmes (planification, vérification, actions correctives) de manière peu régulière, mais homogène ; les actions correspondent à ce qui a été planifié.
Le processus (dont les rôles et responsabilités associés) d'intégration de la SII dans le cycle de vie des systèmes est formalisé, éventuellement sur la base d'une démarche méthodologique, depuis les phases amont d'un projet jusqu'à sa fin de vie ; il est régulièrment utilisé ; les systèmes font l'objet d'une homologation de sécurité formelle sur la base d'un dossier de sécurité défini.
Des objectifs mesurables d'intégration de la SSI dans les projets sont définis et suivis (ex. : tableaux de bord projets intégrant la SSI, audits...) ; le processus est devenu standard et davantage automatisé.
Le processus d'intégration de la SSI dans le cycle de vie des système est généralisé, bien automatisé, utilisé par tous les autres processus SSI, intégré aux processus métiers, bien accepté et s'améliore continuellement.