La version 3 renforce ce positionnement, et apporte une expérience utilisateur plus riche. Parmi de nombreuses corrections, la version 3 permet de mieux modéliser l’organisation autour du SI, apporte la gestion de SNMPv3 pour plus de sécurité, et une meilleure ergonomie des cartographies en particulier pour les applications. Cette version dévoile le futur d’EyesOfNetwork Exploitation. Cette brique de la suite propose d’ores et déjà un premier niveau de « Service Desk » et de « Gestion des configurations » grâce, entre autres, à l’ajout d’une version stable de l’excellent GLPI.

Le « bundle » EyesOfNetwork est composé d’un système d’exploitation minimaliste incluant un ensemble intégré d’applications répondant aux différents besoins de supervision :

• GED (Generic Event Dispatcher) : gestion multi sites et sécurisée des évènements,
• NAGIOS : gestion des incidents et des problèmes,
• NAGIOSBP : gestion de la criticité des applications,
• NAGVIS : cartographie personnalisée de la disponibilité,
• CACTI : gestion des performances,
• WEATHERMAP : cartographie de la bande passante,
• BACKUP MANAGER : Outil de sauvegarde de la solution,
• EONWEB : Interface Web unifiée de la solution,
• EZGRAPH : Librairie d’affichage des graphiques,
• SNMPTT : Traduction des traps snmp,
• GLPI: Gestion de parc.

EyesOfNetwork est accessible via une interface Web unique dont l’objectif est de réunir les différents acteurs d’un système d’informations (DSI, Administrateurs, Techniciens, Opérateurs, …). Chacun des ces acteurs dispose d’une vue correspondant à son métier. Toutes les informations sont consolidées en Base de Données MYSQL ou BERKELEY.
EyesOfNetwork est un produit sous licence GPL2 sponsorisé et proposé par APX dans le cadre de prestations de services (Intégration, Télé-service, Support téléphonique et Tierce Maintenance Applicative).

Téléchargement : ici

En principe, CE veut dire Conformité Européenne, ce qui veut dire que le produit estampillé de la sorte est conforme aux normes et directives imposées par la norme européenne.
Mais il existe encore un autre CE, qui cette fois veut dire tout autre chose, en l’occurrence China Export.

La différence entre ces deux CE ?

Pour faire la différence, il faut voir l’espace entre le C et le E ainsi que la longueur de la barre du E qui est qui est en retrait dans le cas du logo UE.

Vous pouvez le voir sur l’image ci-dessous : le marquage officiel CE de Conformité Européenne fait que les deux lettres se chevauchent au niveau de l’épaisseur des lettres sur l’esquisse de chacune de ses dernières et forment un huit à l’horizontale, alors que le CE de China Export fait que ces deux lettres sont trop rapprochées pour obtenir la même forme du huit couché !

Attention donc à ce fameux sigle, l’un vous certifie la conformité du produit acheté aux normes de la communauté européenne, l’autre qu’il a été fabriqué en chine et exporté, mais quant à savoir s’il est comme le premier conforme CE, c’est une autre histoire…

Pour terminer, voici une vidéo provenant du site YouTube, qui explique en détails la différence entre ces deux sigles !

Le logo officiel Conformité européenne

Le logo China Export

CobiT concerne différents types d’utilisateurs :

• les directions générales : pour que l’investissement informatique produise de la valeur et pour trouver le bon équilibre entre risques et investissements en contrôles dans un environnement informatique souvent imprévisible,
• les directions métiers : pour obtenir des assurances sur la gestion et le contrôle des services informatiques fournis en interne ou par des tiers,
• les directions informatiques : pour fournir les services informatiques dont les métiers ont besoin pour répondre à la stratégie de l’entreprise, et pour contrôler et bien gérer ces services,
• les auditeurs et consultants : pour justifier leurs opinions et/ou donner des conseils au management sur les contrôles internes et la gouvernance des SI.

Le cadre de référence de contrôle de CobiT facilite la mise en place d’une gouvernance des SI en :

• établissant un lien avec les exigences métier de l’entreprise,

• structurant les activités informatiques selon un modèle de processus largement reconnu,

• identifiant les principales ressources informatiques à mobiliser,

• définissant les objectifs de contrôle à prendre en compte.

L’orientation métier de CobiT consiste à lier les objectifs métier aux objectifs informatiques, à fournir les métriques (définir ce qui doit être mesuré et comment) et les modèles de maturité pour faire apparaître leur degré de réussite, et à identifier les responsabilités communes aux responsables de processus métier et de processus informatiques.

L’orientation processus de CobiT est illustrée par un modèle de processus qui subdivise l’informatique en 34 processus répartis entre les quatre domaines de responsabilités que sont planifier, mettre en place, faire fonctionner et surveiller, donnant ainsi une vision complète de l’activité informatique. Les concepts d’architecture d’entreprise aident à identifier les ressources essentielles au bon déroulement des processus comme les applications, l’information, les infrastructures et les personnes. Pour fournir les informations dont l’entreprise a besoin pour réaliser ses objectifs, les ressources informatiques doivent être gérées par un ensemble de processus regroupés selon une certaine logique.

Les dirigeants ont besoin d’objectifs de contrôle pour fournir l’assurance raisonnable que les objectifs de l’entreprise seront atteints et que des dispositifs sont en place pour prévenir ou détecter et corriger des événements indésirables. Les entreprises ont besoin de pouvoir mesurer objectivement où elles en sont et où elles doivent apporter des améliorations, et elles ont besoin d’implémenter des outils de gestion pour surveiller ces améliorations. La réponse à ce besoin de déterminer et de surveiller les niveaux de contrôle et de performance de l’informatique appropriés est apportée par CobiT sous forme de :

• Tests comparatifs de la capacité des processus informatiques présentés sous la forme de modèles de maturité inspirés du Capability Maturity Model du Software Engineering Institute,
• Objectifs et métriques des processus informatiques pour définir et mesurer leurs résultats et leurs performances (capacité à atteindre les objectifs métiers et informatiques) selon les principes du tableau de bord équilibré de Robert Kaplan et David Norton,
• Objectifs des activités pour mettre ces processus sous contrôle en se basant sur des objectifs de contrôle détaillés.

L’évaluation de la capacité des processus au moyen des modèles de maturité de CobiT est un élément clé de la mise en place d’une gouvernance des SI. Lorsqu’on a identifié les processus et les contrôles informatiques essentiels, le modèle de maturité permet de mettre en évidence les défauts de capacité et d’en faire la démonstration au management. On peut alors concevoir des plans d’action pour amener ces processus au niveau de capacité désiré.

CobiT concourt à la gouvernance des SI en aidant à s’assurer que les :

• les SI sont alignés sur le métier de l’entreprise,
• les SI apportent un plus au métier, et maximisent ses résultats,
• les ressources des SI sont utilisées de façon responsable,
• les risques liés aux SI sont gérés comme il convient.

La mesure de la performance est essentielle à la gouvernance des SI. Elle est un élément de CobiT et consiste entre autres à fixer et à surveiller des objectifs mesurables pour ce que les processus informatiques sont censés fournir (résultat du processus) et pour la façon dont ils le fournissent (capacité et performance du processus).

Pour que cette gouvernance soit efficace, les dirigeants doivent obtenir des directions opérationnelles qu’elles mettent en place des contrôles dans un cadre de référence défini pour tous les processus informatiques.

En conclusion, parmi les avantages à adopter CobiT comme cadre de gouvernance des SI on peut citer :

• un meilleur alignement de l’informatique sur l’activité de l’entreprise du fait de son orientation métier,
• une vision compréhensible par le management de ce que fait l’informatique,
• une attribution claire de la propriété et des responsabilités, du fait de l’approche par processus,
• un préjugé favorable de la part des tiers et des organismes de contrôle,
• une bonne compréhension de toutes les parties prenantes grâce à un langage commun,
• le respect des exigences du COSO pour le contrôle de l’environnement informatique.

CobiT : le modèle de référence

CobiT retient 34 processus regroupés en 4 domaines qui correspondent au cycle de vie des SI et à leur maîtrise : Planifier et Organiser (10 processus), Acquérir et Implémenter (7 processus), Délivrer et Supporter (13 processus), Surveiller et Evaluer (4 processus).

Chaque processus met en œuvre des ressources informatiques (applications, informations, infrastructures et personnes au sens compétences), fournit une information destinée à satisfaire les besoins métiers exprimés sous formes de critères (efficacité, efficience, confidentialité, intégrité, disponibilité, conformité, fiabilité) et concerne un ou plusieurs des domaines de la gouvernance des SI (alignement stratégique, apport de valeur, gestion des risques, gestion des ressources, mesure de la performance).

CobiT V4.1

CobiT 4.1 est une version incrémentale de CobiT 4.0 comprenant :

• Une amélioration de la partie Synthèse.

• Une présentation des objectifs et des métriques dans la partie Cadre de Référence.

• De meilleures définitions des concepts essentiels. Il est important de mentionner que la définition de l’objectif de contrôle a évoluée pour devenir davantage l’exposé d’une pratique de management.

• Une amélioration des objectifs de contrôle résultant d’une mise à jour des pratiques de contrôle et de la prise en compte de Val IT. Certains objectifs de contrôle ont été regroupés et/ou réécrits pour éviter les redondances et rendre la liste des objectifs de contrôle plus cohérente. Il en a résulté une renumérotation des objectifs de contrôle restants. Quelques objectifs de contrôle ont été réécrits afin de les rendre plus cohérents et davantage tournés vers l’action. Plus précisément :

- AI5.5 et AI5.6 ont été regroupés avec AI5.4

- AI 7.9, AI7.10 et AI7.11 ont été regroupés avec AI7.8

- SE3 intègre désormais la conformité aux obligations contractuelles en plus des obligations légales et réglementaires.

• Les contrôles applicatifs ont été retravaillés afin de les rendre plus efficaces, pour aider à évaluer et rendre compte de l’efficacité des contrôles. Il en résulte une liste de six contrôles applicatifs au lieu des 18 de CobiT 4.0 avec des détails additionnels provenant des Pratiques de Contrôle CobiT, 2^ème version.

• La liste des objectifs métiers et informatiques de l’Annexe I a été améliorée sur la base d’un nouveau regard résultant des travaux de recherche menés par l’Ecole de Management de Université d’Anvers (Belgique).

• Le hors texte a été enrichi. Il intègre une liste de référence rapide des processus CobiT et le diagramme de synthèse de description des domaines a été revu afin d’intégrer une référence aux  contrôles de processus et aux contrôles applicatifs du Cadre de Référence CobiT.

• Les améliorations proposées par les utilisateurs de CobiT (CobiT 4.0 et CobiT Online) ont été revues et intégrées quand cela était opportun.

CobiT : la famille des produits

Vous trouverez également sur ce site des présentations de synthèse de CobiT V4.1, ainsi que des présentations de certains processus à la rubrique Téléchargements.

Améliorer la sécurité de son système d’information suppose de suivre la norme ISO 27001 :2005 et donc d’impliquer en tout premier lieu la Direction Générale de l’entreprise. Dans la pratique, la démarche vient du management de haut niveau pour s’appliquer sur tous les niveaux de la pyramide, la perception globale des enjeux et des risques pour
l’exploitation de l’entreprise permet d’adapter les démarches de sécurisation du SI, ni trop, ni trop peu.

La norme ISO27002 :2005 est généralement suivie par les directions informatiques ou par des équipes techniques autonomes lorsque l’engagement de la direction générale n’est pas au rendez-vous. Dans la pratique, le périmètre couvert est inadapté dans la mesure où il est vu du point de vue la DSI et non en fonction des biens identifiés et nécessaires à l’exploitation de l’entreprise.

Autrement dit la norme propose, à partir du contexte de l’entreprise, une appréciation des risques (identification, estimation) et une évaluation avec quatre traitements possibles de ces risques :

• Refuser le risque
• Réduire le risque
• Transférer le risque
• Conserver le risque.

Cette norme peut être un sous-ensemble de la norme ISO 27001, spécifique à la gestion des risques mais est applicable de manière concrète et autonome.
De nombreuses méthodes permettent d’effectuer cette démarche d’appréciation des risques : eBios, Méhari,…

ISO/IEC 27002 version 2005 est le volet qui traite des techniques de Sécurité de l’information. C’est un guide de pratique pour la gestion de la Sécurité de l’information. En complément d’IS/IEC 27001 il permet d’accompagner le processus de mise en œuvre d’un SMSI.

La norme  ISO/IEC 27002 fournit des recommandations de gestion de la Sécurité de l’information au lecteur responsable d’initier, implémenter et maintenir la sécurité.

2. Évaluation et traitement des risques. [section 4 de la norme]

La présente section de la norme ISO/IEC 27002 couvre les aspects de gestion des risques. En revanche la norme de donne aucune indication quant à la méthode de gestion des risques. Afin d’aller plus loin dans la gestion des risques nous vous invitons à lire ISO/IEC 27005 ou à vous intéresser aux méthodes telles que EBIOS ou MÉHARI.

3. Politique de Sécurité [section 5 de la norme]

La Direction ou le management doit formaliser une politique de sécurité. Cette politique est une déclaration d’intention quant à la direction prise par l’organisme, à sa volonté de soutenir la sécurité de l’information.

La politique est un manuel décrivant les normes appliquées et applicables, les procédures et processus mises en œuvre et l’ensemble des directives de sécurité de l’entreprise.

4. Organisation de la sécurité de l’information [section 6 de la norme]

ISO/IEC 27002 nécessite qu’une structure appropriée de gestion de la sécurité de l’information doit être désignée et mise en œuvre.

4.1 Organisation interne

L’organisme doit définir un cadre de gestion de la sécurité de l’information. La direction doit donner la direction du projet et assurer son engagement en validant formellement la politique de sécurité par exemple.

Les rôles et responsabilités doivent être définis dans la gestion de la sécurité de l’information.  Les revues du SMSI doivent être réalisées par des équipes indépendantes.

4.2 Tierces parties

La mise en service de produits et services provenant de tierce partie (fournisseurs, mainteneurs, etc.) ne doivent en aucun cas compromettre la sécurité de l’information.

Les risques  concernant les tierces parties doivent être évalués et réduits autant que possible lorsque l’organisme contractualise soit avec des clients soit avec des fournisseurs externes.

Les risques identifiés et les mesures de réduction des risques doivent être enregistrés pour apporter la preuve de cette activité.

5. Gestion des actifs  [section 7 de la norme]

L’organisme doit être en mesure de connaitre l’ensemble des actifs (Serveurs, Routeurs, Logiciels, Applications, etc.) qu’il possède afin de gérer efficacement leur sécurité.

5.1 Responsabilité des actifs (assets)

Tous les actifs inventoriés doit être affectés à un possesseur. L’inventaire des actifs doit être maintenu et mis à jour et doit contenir le possesseur et la localisation des actifs.

5.2 Classification de l’information

Les informations doivent être classifiée en fonction de leur besoin respectif de protection.

Les actifs doivent être identifiés et étiquetés. Notez que selon leur classification et leur importance les actifs doivent être groupés et que des contrôles appropriés doivent être mis en œuvre afin de s’assurer de l’efficacité des dispositions sécuritaires.

6. Sécurité des ressources humaines [section 8 de la norme]

L’organisation qui initie un projet ISO/IEC 27 002 doit mettre en œuvre et maintenir un système de gestion des accès., notamment concernant le personnel entrant ou quittant l’entreprise.

L’organisme doit par ailleurs s’assurer que des actions de sensibilisation aux enjeux de sécurité sont entreprises, et des actions de formations sont mises en œuvre conformément aux besoins identifiés.

6.1 En amont de l’embauche

Lors d’un recrutement l’entreprise doit prendre en compte les futurs prérogatives sécurité du salarié. Cela concerne aussi les prestataires externes et intérimaires.

Les responsabilités, en termes de sécurité, doivent faire l’objet d’une formalisation dans le contrat de travail. Il s’agit par exemple du respect de la charte informatique, des rôles et responsabilité de tout un chacun dans l’entreprise.

6.2 Durant l’emploi

L’entreprise doit en outre définir les responsabilité en termes de gestion de la Sécurité. A ce titre les employés et tierces parties doivent être sensibilisés, formés et informés quant aux procédures sécurité et à leur responsabilité dans le respect et la mise en oeuvre de ces directives.

En outre il est nécessaire de formaliser les sanctions disciplinaires encourues pour traiter le cas des infractions à la sécurité.

6.3 Rupture du contrat ou changement d’employeur

L’organisme doit mettre en œuvre les dispositions permettant de s’assurer que le personnel sortant est géré et spécifiquement concernant les habilitations et droits d’accès.

7. Sécurité physique et environnementale [section 9 de la norme]

Les actifs et particulièrement ceux qui revêtent une importance supérieure pour l’entreprise doivent être protégé physiquement contre les malveillances, le dommage, la perte accidentelle, etc.

7.1 Zones de sécurité

L’organisme doit s’assurer qu’un dispositif de contrôle physique est mis en œuvre afin de protéger les équipements sensibles contre les accès non autorisés.

7.2 Équipement de sécurité

Les composants IT, les câbles, les équipements électriques, les onduleurs, etc. doivent être protégés contre les dommages physiques, les incendies, les inondations, le vol. Ces dispositions doivent intégrer à la fois les équipements sur site et hors des locaux de l’entreprise.

Les équipements d’alimentation électriques ainsi que les câblages doivent être assurés par l’entreprise.

Enfin tous les équipements doivent être entretenus et faire l’objet de procédure de recyclage intégrant des dispositions sécuritaires, telle que l’effacement des données sur les disques durs.

8. Gestion des communications et des opérations [section 10 de la norme]

Cette section de la norme ISO/IEC 27 002 décrit les dispositions spécifiques aux contrôles de sécurité des systèmes ainsi qu’a la gestion de la sécurité des réseaux.

8.1 Responsabilités et procédures opérationnelles

L’organisme s’engage à formaliser les responsabilités opérationnelles et à documenter les procédures. A ce titre toutes les modifications apportées sur des équipements informatiques ou des systèmes doivent être contrôlés.

Les habilitations sur les système doivent être alignés sur les prérogatives des collaborateurs et permettre ainsi de cloisonner par exemple une administrateur système d’un utilisateur simple sur un système de fichier.

8.2 Livraison de service par des tierces parties

Les exigences de sécurité doivent être prises en compte lors du recours à des tierces parties telles que des fournisseurs externes, des constructeurs, des mainteneurs. Les exigences concernant les changements et la maintenance par des tiers doivent être formalisées contractuellement.

8.3 Planification et acceptation des Systèmes

Cette sous-section d’ISO/IEC 27 002 couvre les dispositions spécifiques à la planification de la capacité de production et les processus d’acceptation.

8.4 Protection contre le code mobile et malicieux

L’organisme doit mettre en œuvre un dispositif de lutte et de contrôle contre le code mobile, et disposer de logiciels permettant de lutter efficacement contre les logiciels malveillants tels que les « spyware ».

8.5 Sauvegarde

Cette section couvre tous les aspects concernant la sauvegarde des données, mais aussi et surtout des tests de restauration.

8.6 Gestion de la sécurité des réseaux

L’organisme doit mettre en œuvre une gestion sécurisé des réseaux, ainsi que les moyens nécessaires à la surveillance de la sécurité des réseaux. Ces dispositions incluent les réseaux internes, externes (liaisons avec des partenaires) et réseaux externalisés et/ou infogérés.

8.7 Gestion des supports

L’organisme doit mettre en place des procédures opérationnelles pour protéger :

• les documents,
• les supports informatiques,
• les données,
• le système d’information,

L’organisme doit s’assurer que les données sont éliminées conformément a leur cycle de vie.

Enfin, des procédures doivent être définies pour la sécurité des opérations de manutention, de transport et de stockage d’une part des  supports de sauvegarde et d’autre part des documentation sur le système.

8.8 Échange des informations

L’organisme doit s’assurer que tous les échanges d’information avec des organisations externes sont contrôlés. Non seulement les échanges doivent être conformes aux procédures et politiques applicables, mais aussi conformément à la législation en vigueur.

Des dispositions sécuritaires doivent être mise en place afin de s’assurer de la protection des informations et documents transitant hors et à l’intérieur de l’entreprise, tels que les emails, les échanges de données EDI, les données échangées entre les systèmes d’information, etc.

8.9 Services de commerce électronique

Pour le cas ou l’organisme a recours ou met en oeuvre des services de commerces electronique, les enjeux potentiels en termes de sécurité doivent être évalués et faire l’objet de contrôles appropriés.

L’intégrité et la disponibilité des informations publiées, notamment sur des sites Internet, doivent être assurées.

8.10 Monitoring

La surveillance et le monitoring couvre :

• la détection d’événements de sécurité
• les alertes de surveillance,
• les détections d’utilisation non autorisées,
• les tentatives d’exploit,
• les failles du systèmes,
• etc.

9. Contrôles d’accès [section 11 de la norme]

Les accès « logiques » aux systèmes informatiques, aux réseaux et aux données doivent être contrôlés afin de prévenir toute utilisation non autorisée.

9.1 Exigences business sur les contrôles d’accès

Une politique de contrôle d’accès doit être formalisée. Elle doit inclure à minima l’accès aux actifs, aux informations.

En fonction des profiles et des rôles du personnel la politique de contrôle doit spécifier qui peut avoir accès à quoi.

9.2 Gestion des accès utilisateurs

Des procédures administratives doivent être mises en œuvre afin de s’assurer que les droits d’accès affectés aux utilisateurs sont correctement enregistré et suivi.

9.3 Responsabilités des utilisateurs

Les utilisateurs doivent avoir conscience de leur implication et de leur responsabilité quant au maintien de l’efficacité des contrôles d’accès. Cela se traduit par la sensibilisation a l’utilisation de mots de passe complexes et confidentiels.

Enfin l’accès aux poste de travail doit être sécurisé lorsque le collaborateur quitte son bureau.

9.4 Contrôles d’accès au réseau

L’accès à tous les services réseau doit être contrôlé, tant en interne que lors des relations avec l’extérieur.

La politique concernant les contrôles d’accès doit être formalisée et les utilisateurs distants doivent être dûment authentifiés.

9.5 Contrôles d’accès au système d’exploitation

Des dispositions concernant la gestion des postes de travail doivent être déployées. Il s’agit notamment de l’authentification systématique de l’utilisateur, de l’utilisation de compte individuels, d’enregistrement des privilèges accordés à l’utilisateur, etc.

L’accès aux outils d’administration systèmes doivent être contrôlés.

9.6 Contrôles d’accès aux applications et à l’information

L’accès aux applications doivent être contrôlés conformément à une politique de contrôle d’accès prédéfinies.   Les applications particulièrement sensibles peuvent nécessité la mise en œuvre de plates-formes dédiées ou de contrôles supplémentaires.

9.7 Télétravail et informatique mobile

L’organisme doit formaliser une politique portant sur la sécurité de l’utilisation des PC portables, PDA, téléphones portables etc. Elle doit par ailleurs garantir la sécurité dans le cadre du télétravail, via par exemple un tunnel IPSEC.

10. Acquisition, développement et maintenance des systèmes d’information [section 12 de la norme]

La sécurité de l’information doit être prise en compte et intégrée lors de la spécification, la conception, l’acquisition, les tests, la mise en œuvre et le maintien des technologies de l’information.

10.1 Exigences de sécurité des systèmes d’information

Les contrôles automatique et/ou manuel de sécurité doivent être identifiés et analysés lors de la phase de développement de systèmes ou lors du processus d’acquisition.

Les logiciels acquis par l’entreprise doivent être officiellement testés d’un point de vue sécurité. Et les risques encourus doivent être évalués.

10.2 Contrôle des traitements dans les applications

La saisie, le traitement et la validation des données ainsi que les contrôles d’authentification doivent être assurés afin de s’assurer de l’intégrité des données.

10.3 Contrôles cryptographiques

Une politique en matière de cryptographie doit être définie. Elle porte sur les rôles et les responsabilités, les signatures numériques, la non-répudiation, la gestion des clés et certificats numériques, etc.

10.4 Sécurité des file systèmes

L’organisme doit s’assurer que l’accès au système de fichiers, ainsi qu’aux exécutables et au code source , sont contrôlés.

10.5 Sécurisation du développement et processus de soutien

L’organisme doit charger les gestionnaires d’applications de contrôler l’accès aux environnement de projet et de support.

Les processus de contrôle des changements doivent être formalisés et mis en œuvre. Ils doivent inclure des revues techniques exhaustives.

Enfin, l’organisme doit veiller a mettre en œuvre des surveillances et des contrôles de surveillance pour les développement externalisés.

10.6 Gestion des vulnérabilités techniques

Les vulnérabilités techniques concernant les systèmes et les applications doivent être contrôlées par la mise en place d’un suivi des annonces des failles de sécurité. L’évaluation des risques sur l’application et/ou le système d’un correctif de sécurité doit être réalisé avant son déploiement.

11. Gestion des incidents de sécurité de l’information [section 13 de la norme]

Les événements de sécurité, les incidents et les failles ou points faibles doivent être signalés rapidement et gérées promptement.

11.1 Rapports sur les événements et faille de sécurité

Chaque incident doit faire l’objet d’un compte rendu. Une procédure d’alerte doit exister et etre utilisée. Des procédures de réponse et de l’escalade doivent être associés aux alertes et aux incidents.

Un SPOC (point de contact unique) doit être informés des rapports d’incident qui les concernes, c’est à dire relatifs à la sécurité de l’information.

11.2 Gestion et amélioration des incidents de sécurité

Des responsabilités et des procédures sont requises pour

• gérer les incidents de manière cohérente et efficace,
• mettre en œuvre l’amélioration continue,
• recueillir des preuves concernant le suivi des incidents de sécurité et leur traitement.

12. Gestion de la continuité Business [section 14 de la norme]

Cette section décrit la relation entre le plan de continuité IT, la continuité Business, et la planification d’urgence. Elle couvre l’analyse, la documentation et les plans de test.   Tous les contrôles sont conçus pour minimiser l’impact des incidents de sécurité pouvant survenir malgré les contrôles préventifs mis en œuvre par l’organisme. Il s’agit notamment des sinistres ou incidents majeurs.

13. Conformité [section 15 de la norme]

13.1 Conformité avec les exigences légales

L’organisation doit se conformer à la législation en vigueur, tel que le droit d’auteur, la protection des données ( y compris les données financières), etc.

13.2 Conformité technique, conformité avec les politiques de sécurité et les normes

La Direction et les propriétaires des systèmes doivent veiller au respect des politiques de sécurité et des normes. A cet effet des revues de sécurité doivent être réalisée afin de statuer sur l’efficacité du dispositif. Il peu s’agir en outre de revoir les résultats de tests d’intrusion, etc.

15.3 Considérations sur l’audit des SI

Les audits devraient être soigneusement planifié afin de minimiser les perturbations sur les systèmes opérationnels.

• Système de management de la sécurité de l’information (SMSI) : Partie du système de management global, basée sur une approche du risque lié à l’activité, visant à établir, mettre en œuvre, exploiter, surveiller, réexaminer, tenir à jour et améliorer la sécurité de l’information.

• Actif : tout élément représentant de la valeur pour l’organisme.

• Disponibilité : propriété d’être accessible et utilisable à la demande par une entité autorisée.

• Confidentialité : propriété selon laquelle l’information n’est pas rendue accessible ou divulguée à des personnes, entités ou processus non autorisés.

• Sécurité de l’information : protection de la confidentialité, de l’intégrité et de la disponibilité de l’information; en outre, d’autres propriétés, telles que l’authenticité, l’imputabilité, la non-répudiation et la fiabilité, peuvent également être concernées.

• Événement lié à la sécurité de l’information : Occurrence identifiée d’un état d’un système, d’un service ou d’un réseau indiquant une faille possible dans la politique de sécurité de l’information ou un échec des moyens de protection, ou encore une situation inconnue jusqu’alors et pouvant relever de la sécurité.

• Incident lié à la sécurité de l’information : Un ou plusieurs événements intéressant la sécurité de l’information indésirable(s) ou inattendu(s) présentant une probabilité forte de compromettre les opérations liées à l’activité de l’organisme et de menacer la sécurité de l’information.

• Intégrité : Propriété de protection de l’exactitude et de l’exhaustivité des actifs.

• Risque résiduel : risque subsistant après le traitement du risque.

• Acceptation du risque : Décision d’accepter un risque.

• Analyse du risque : Utilisation systématique d’informations pour identifier les sources et pour estimer le risque.

• Appréciation du risque : Ensemble du processus d’analyse du risque et d’évaluation du risque.

• Évaluation du risque : Processus de comparaison du risque estimé avec des critères de risque donnés pour en déterminer l’importance.

• Management du risque : Activités coordonnées visant à diriger et piloter un organisme vis-à-vis du risque.

• Traitement du risque : Processus de sélection et de mise en œuvre des mesures visant à diminuer le risque.

• Déclaration d’applicabilité (DdA) : Déclaration documentée décrivant les objectifs de sécurité, ainsi que les mesures appropriées et applicables au SMSI d’un organisme. Un exemple de DdA est téléchargeable dans la zone de « téléchargement«