CaseFile: On the road 27001

To no longer be lost on the road 66 of ISO 27001, I am pleased to present Case File the latest Maltego Teeth. The latter is integrated into the Kali-Linux distribution.

The Maltego Case File application is available in Java with support for Windows / Mac / Linux systems and the official version is available on the Paterva website.

CaseFile !

CaseFile is a light emanation of Maltego Teeth. This is essentially the same graphical application with bridle functions (online investigation). CaseFile allows you to quickly add, bind, and analyze data across nodes.

The application has the possibility to view data stored in files in CSV, XLSX format and to export the representations in graphic format.

A complementary asset is the generation of a PDF report containing all the elements with the interactions.

The application focuses on a need for « offline » analysis, the sources of which are acquired « on the ground », gathering information from others on the team and drawing up an information card of their investigation.

The application responds to a formalization to represent attacks, threat scenarios, or a risk to a process. It is one of the indispensable tools of digital investigation.


The use case ISO 27001

Our use case was to be able to model the list of controls present in the appendix to ISO / IEC 27001: 2013 and thus to be able to attach actions or to follow the evolutions of this standard.

First step

To be able to model this standard, it was necessary to create three objects to take into account domains, objectives and security controls. The creation of entities (Manage Entity) is done fairly quickly with a naming of the object, a description, a unique name and a logo.

Second step

The modeling is done with the sliding of the objects on the sheet, then for each object, its attribute is assigned to it, namely in our case of use the domains, objectives and controls in the appendix of ISO 27001: 2013.

After this operation, we must establish the relations between the objects with the following relation:

One domain integrates one or more security objectives;
A goal incorporates one or more security controls.

Navigation in the cybergalaxy

The modeling of the controls  of ISO / IEC 27001, allows you to navigate the 14 domains listed below:

– A5  Security Policies
– A6 Organization of information security
– A7 Human Resource Security
– A8 Asset Management
– A9 Access control
– A10 Cryptography
– A11 Physical and environmental security
– A12 Operations security
– A13 Communications Security
– A14 Acquisition, development and maintenance
– A15 Supplier relationships
– A16 Information security incident management
– A17 Information security aspects of business continuity management
– A18 Compliance

and to identify the 35 objectives and 114 security controls of the standard. The documentation of the generated model is given in this report ISO27001_2013-EN

Stay on the course.

This modeling can meet both the mapping needs of the implementation of the ISO 27001 security controls, the management of its improvement axes or the audit of a system.

The mtgx modeling file is available on request via a linkedin message.

Publicités

CaseFile : La ROOT 27001

Pour ne plus être perdu sur la Route 66 de l’ISO 27001, Il me fait plaisir de vous présenter Case File le petit dernier de Maltego Teeth. Ce dernier est intégré dans la distribution Kali-Linux .

L’application Maltego Case File est disponible sous  Java avec le support des systèmes Windows / Mac / Linux et la version officielle est disponible sur le site de Paterva .

Quésaco

CaseFile est une émanation allégée de Maltego Teeth. Il s’agit essentiellement de la même application graphique avec des bridages de fonctions (investigation en ligne). CaseFile vous permet d’ajouter rapidement, de lier et d’analyser les données au travers de nœud.

L’application a la possibilité de visualiser des données stockées dans des fichiers aux formats CSV, XLSX ainsi que d’exporter les représentations au format graphique.

Un atout complémentaire est la génération d’un rapport PDF reprenant l’ensemble des éléments avec les interactions.

L’application vise un besoin d’analyse «hors ligne» dont les sources d’information sont acquises  «sur le terrain», en recueillant des renseignements auprès d’autres personnes dans l’équipe et en dressant une carte d’information de leur investigation.

L’application répond à une formalisation  pour représenter des attaques, des scénarios de menaces ou un risque sur un processus. Il est un des outils indispensable de l’investigation numérique.

Le cas d’usage ISO 27001

Notre cas d’usage était de pouvoir modéliser la liste des mesures présentes en annexe de la norme ISO/IEC 27001:2013 et ainsi de pouvoir y attacher des actions ou de suivre les évolutions de cette norme.

Le premier pas

Pour pouvoir modéliser cette norme, il a fallu créer trois objets pour prendre en compte les domaines,  les objectifs et les mesures de sécurité. La création d’entités (Manage Entity) se fait assez rapidement avec une attribution d’un nom à l’objet, d’une description, d’un nom unique et d’un logo.

Le second pas

La modélisation se fait avec le glissement des objets sur la feuille, ensuite pour chaque objet, on lui affecte son attribut  à savoir dans notre cas d’usage les domaines,  les objectifs et les mesures cités en annexe de la norme ISO 27001:2013.

Après cette opération, il faut établir les relations entre les objets avec la relation suivante :

Un domaine intègre un ou plusieurs objectifs de sécurité ;
Un objectif intègre une ou plusieurs mesures de sécurité.

 

La navigation dans la galaxie

La modélisation des mesures de la norme ISO/IEC 27001, vous permet de naviguer sur les 14 domaines repris ci-dessous :

– A5 – Politiques de sécurité
– A6 – Organisation de la sécurité de l’information
– A7 – Sécurité des ressources humaines
– A8 – Gestion des actifs
– A9 – Contrôle d’accès
– A10 – Cryptographie
– A11 – Sécurité physique et environnementale
– A12 – Sécurité liée à l’exploitation
– A13 – Sécurité des communications
– A14 – Acquisition, développement et maintenance des systèmes d’information
– A15 – Relations avec les fournisseurs
– A16 – Gestion des incidents liés à la sécurité de l’information
– A17 – Aspects de la sécurité de l’information dans la gestion de la continuité de l’activité
– A18 – Conformité

et d’identifier les 35 objectifs et 114 mesures de sécurités de la norme . La documentation du modèle généré est reprise dans ce rapport ISO27001

Garder le cap avec l’ISO 27001.

Cette modélisation peut répondre tant à des besoins de cartographie de l’implémentation des mesures de sécurité de l’ISO  27001,  que pour la gestion de ses axes d’améliorations ou pour un audit d’un système.

 

Le fichier de modélisation  mtgx est disponible sur demande via un message linkedin.

Enregistrer

Gestion de la sécurité de l’information

La sécurité de l’information doit s’inscrire dans une démarche d’un système de management afin d’éviter un empilement de mesures de sécurité techniques. En effet, une telle approche reviendrait à mettre en place un système d’information sur un château de cartes qui risquerait de s’effondrer à la première menace.

La construction de la sécurité de l’information doit tenir compte des facteurs clefs que sont le périmètre à couvrir, la formation du personnel et la mise en œuvre des processus en appliquant le principe de Deming reposant sur le  ‘Plan Do Check Act’.

En effet, la formalisation de la sécurité est un chemin qui peut être une longue traversée du désert. Pour éviter le découragement il faut commencer par les services vitaux de l’entreprise afin d’apporter de la valeur au processus et accroître la confiance dans la démarche tant pour l’entreprise que pour les clients.

Ensuite les processus prendront en compte les services annexes mais sans tomber dans l’excès de vouloir couvrir l’ensemble des activités.

Il existe de nombreux référentiels permettant d’appréhender la construction de la sécurité avec des visions différentes que nous aborderons dans la suite du billet.

 

ITILv3Security

Les référentiels et normes existantes sur la gouvernance IT

ISO 27001: La norme ISO 27001 est une norme dédiée à la gestion de la sécurité des systèmes d’information, Système de Management de la Sécurité de l’Information (SMSI). Cette norme est disponible auprès de l’ISO.

ISO 20000: La norme ISO 20000 est une norme dédiée à la fourniture de services. L’ISO 20000 reprend la même logique que le référentiel ITIL®. La version 2011 oriente la norme vers un système de management des services (SMS). Normes disponible auprès de l’ISO.

COBIT:    Le référentiel CobiT, Control objectives for information and technology proposé par l’ISACA, est un cadre de référence orienté processus de l’audit et de la maîtrise du système d’information. Le référentiel COBIT propose des bonnes pratiques pour gérer efficacement l’alignement des technologies dans une logique de maîtrise des risques et des investissements. Le référentiel est disponible auprès de l’ISACA avec une version en français (http://www.isaca.org/COBIT/Pages/COBIT-5-french.aspx ).

ITIL®: Information Technology Infrastructure Library est le fruit d’un travail conduit par l’Office Public du Commerce Britannique. Il s’agit d’une sélection de bonnes pratiques orientées clients afin d’assurer une gestion efficace, risques et qualité, des services informatiques. Les processus ITIL sont intégrés dans 4 typologies (stratégie, conception, transition et opération). Le référentiel est disponible sur le site www.axelos.com

CMMI: Capability Maturity Model Integration est un modèle d’évaluation orienté processus de la capacité à atteindre les objectifs en matière de réalisation informatique. Fondé sur un référentiel de bonnes pratiques de la profession, il s’inscrit dans une logique d’amélioration continue des processus.

Le référentiel ITIL v3 et la sécurité de l’information

Les processus de sécurité au niveau de l’ITIL v3 ont pour objectif de couvrir les fonctions vitales de l’information à savoir la confidentialité, l’intégrité et la disponibilité. Ces processus sont inscrits avec la version 3 dans la conception des services afin d’intégrer en amont la sécurité de l’information avant la mise en production des services. Au niveau des processus opérationnels, nous aborderons le processus de gestion des habilitations et celui des incidents.

La sécurité dans la conception des services

Le premier processus que nous évoquons est celui de l’Information Security Management qui intègre 4 sous-processus

  • La conception des mesures de sécurité : concevoir des mesures techniques et organisationnelles appropriées afin d’assurer la confidentialité, l’intégrité, la sécurité et la disponibilité des actifs, des informations, des données et des services d’une organisation (DO).
  • L’évaluation de la sécurité : faire en sorte que tous les mécanismes de sécurité soient soumis à des tests réguliers (CHECK).
  • La gestion des incidents de sécurité : détecter et combattre les attaques et les intrusions afin minimiser les impacts sur les actifs et réduire les conséquences pour l’entreprise (DO).
  • Les revues de sécurité : Examiner si les mesures et procédures de sécurité sont toujours en ligne avec la perception des risques du côté des entreprises, et vérifier si ces mesures et procédures sont régulièrement entretenues et testées (PLAN / ACT).

 

Exemples d’indicateur (Kpi) du processus :

  1. Nombre de mesures de sécurité préventives qui ont été mises en œuvre en réponse aux menaces de sécurité identifiées;
  2. Nombre de tests et de formations sécurité effectués;
  3. Nombre de vulnérabilités dans les mécanismes de sécurité qui ont été identifiés au cours des essais;

Le processus Risk Management / Gestion des risques

Un second processus doit être implémenté dans la gestion de la sécurité de l’information, en effet la gestion des risques devient de plus en plus prégnant dans la gouvernance de l’entreprise. Il faut rappeler que ce processus permet de réduire la potentialité d’une menace sur les actifs de l’entreprise.

L’objectif de la gestion des risques est d’identifier, d’évaluer et de contrôler les risques. Cela couvre l’analyse de la valeur des actifs, l’identification des menaces, l’évaluation de la vulnérabilité de chaque actif et l’estimation des conséquences sur l’entreprise.

Nous conseillons d’instruire ce processus en se conformant et en se référant à la norme ISO/CEI-27005 v2011.

Le processus intègre 4 sous processus qui sont :

  • L’analyse des risques: définit un cadre pour la gestion des risques. Ce processus spécifie comment le risque est quantifié, quels risques l’organisation est prête à accepter, et qui est en charge des différentes fonctions de gestion des risques.
  • L’appréciation des risques: quantifie l’impact de la perte de service ou d’actif sur l’activité et détermine la probabilité d’une menace ou d’une vulnérabilité. Le résultat de sous processus est un registre des risques. Cette liste hiérarchise les risques devant être traités.
  • Évaluation des mesures d’atténuation des risques : Déterminer où les mesures d’atténuation des risques sont nécessaires, et identifier les propriétaires de risques qui seront responsables de leur mise en œuvre et de la maintenance.
  • Surveillance et réexamen des risques: suivre les progrès de la mise en œuvre de contre-mesures, et prendre des mesures correctives si nécessaire.

Exemples d’indicateur (Kpi) de ce processus :

  1. Pourcentage du personnel formé aux techniques critiques de gestion des risques (par exemple, les techniques d’analyse de risque standard, la gestion des crises, la gestion de projet,..);
  2. Délais entre la découverte d’une déficience d’un contrôle et la décision de traitement : Temps de découverte d’une déficience d’un contrôle (par exemple, un événement de vulnérabilité) et le temps d’une décision de traitement des risques;
  3. % des services critiques de l’entreprise qui ne sont pas couverts par l’analyse des risques;

Le processus IT Service Continuity Management / Gestion de la continuité d’activité

Ce processus a vocation de réduire les risques qui pourraient avoir un impact sérieux sur les services primordiaux de l’organisme. Il garantit la fourniture de service minimum pendant un sinistre et  instruit la planification de la reprise des services. Ce processus est conçu pour soutenir la continuité des activités de gestion.

Le processus de gestion de la continuité d’activité est décomposé en 4 sous – processus :

  • Communication : Faire en sorte que tous les membres du personnel IT ayant des responsabilités pour la lutte contre les catastrophes soient conscients de leurs fonctions exactes, et faire en sorte que toutes les informations pertinentes soient facilement disponibles en cas de catastrophe.
  • Conception du plan de continuité : Concevoir des mécanismes et procédures de continuité à un coût permettant d’atteindre les objectifs de la continuité d’activités. Cela comprend la conception de mesures de réduction des risques et les plans de reprise.
  • Formation et Tests : Faire en sorte que toutes les mesures préventives et les mécanismes de récupération pour le cas d’événements catastrophiques soient soumis à des tests réguliers.
  • Revue : Examiner si les mesures de prévention sont toujours en ligne avec la perception des risques et  vérifier si les mesures et procédures de continuité sont régulièrement entretenues et testées.

Rôles et responsabilités : L’ensemble de ces sous-processus est sous l’autorité du Resp. de la continuité de l’activité ( IT Service Continuity Manager). Il intervient principalement comme réalisateur sur cette chaîne en synergie avec les services métiers et infrastructures de la DSI.

Exemples d’indicateur (Kpi) de ce processus :

  1. Pourcentage des processus d’affaires qui sont couverts explicitement par des objectifs de continuité de service;
  2. Délai entre l’implémentation d’une mesure de continuité d’activité et un risque identifié;
  3. Nombre de tests de continuité d’activité effectivement réalisés;

La sécurité dans les services opérationnels

Le processus Access Management /  Gestion des accès

Ce processus  vise à accorder aux utilisateurs autorisés le droit d’utiliser un service, tout en empêchant l’accès aux utilisateurs non autorisés. Les processus de gestion d’accès  exécutent essentiellement des politiques définies dans la gestion de la sécurité de l’information.

Le processus gestion des accès  est parfois aussi appelé  Gestion des droits ou Gestion des identités (IAM).

Les sous-processus ITIL de gestion d’accès couvrent :

  • Maintien du référentiel des habilitations: Faire en sorte que le référentiel des rôles des utilisateurs et leurs profils d’accès soit toujours approprié pour les services offerts aux clients et prévenir l’accumulation indésirable de droits d’accès.
  • Traitement des demandes d’habilitation: Traiter les demandes pour ajouter, modifier ou révoquer les droits d’accès, et faire en sorte que seuls les utilisateurs autorisés aient le droit d’utiliser un service.

Exemples d’indicateur (Kpi) de ce processus :

  1. Pourcentage des processus d’affaires qui sont couverts par une grille d’habilitation;
  2. Nombre de revues des comptes effectivement réalisées;
  3. Délai entre la demande d’une grille d’habilitation pour un nouveau service et sa mise en œuvre effective;

Le processus Incident Management /  Gestion des Incidents;

Le processus de gestion des incidents selon ITIL V3 établit une distinction entre les incidents qui ont un impact sur la Disponibilité des services (Interruptions de service) et les demandes de services (demandes des utilisateurs standards, par exemple réinitialisations de mot de passe). Les demandes utilisateurs ne sont pas comptabilisées  dans la gestion des incidents. Afin de répondre à ces sollicitations, un nouveau processus est mis œuvre appelé « demande de service ».

En complément, ITIL V3 complète la liste de ces processus pour faire face aux situations d’urgence, il est nommé  («Gestion des incidents majeurs»).

Il faut souligner que ITILv3 ne considère pas l’atteinte à la confidentialité, à l’intégrité ou à la non répudiation comme des incidents. Dans ce contexte, il advient d’enrichir ce processus de ces critères afin de couvrir l’ensemble des caractéristiques de la sécurité de l’information. La norme ISO 27035 « Information security incident management » permet d’apporter un éclairage à ce processus.

La gestion des incidents englobe 7 sous-processus suivants :

  • Support au traitement des incidents: Vise à fournir et à maintenir les outils, les processus, les compétences et les règles pour une gestion efficace et efficiente des incidents.
  • Enregistrement des Incidents : L’objectif est d’enregistrer et de hiérarchiser l’incident avec la diligence appropriée afin de faciliter une résolution rapide et efficace.
  • Traitement des incidents de 1er niveau: A pour but de résoudre les incidents (interruption de service) dans un délai défini. L’objectif est le rétablissement rapide du service informatique, le cas échéant avec une solution de contournement. Dès qu’il devient clair que le support de 1er niveau  n’est pas en mesure de résoudre l’incident lui-même ou lorsque le délai est expiré, l’incident est transféré au support de 2e niveau.
  • Traitement des incidents de 2e niveau: A pour but de résoudre les incidents (interruption de service) dans un délai défini. L’objectif est le rétablissement rapide du service, le cas échéant au moyen d’une solution de contournement. Si nécessaire, des groupes de soutien spécialisés ou des fournisseurs tiers (3e niveau) sont impliqués. Si la correction de la cause racine n’est pas possible, un enregistrement problème est créé et la correction d’erreur transférée à la gestion des problèmes.
  • Traitement des incidents majeurs : L’objectif est de résoudre un incident majeur. Les principaux incidents provoquent des interruptions graves des activités commerciales et doivent être résolus avec une plus grande urgence. L’objectif est le rétablissement rapide du service, le cas échéant au moyen d’une solution de contournement. Si nécessaire, des groupes de soutien spécialisés ou des fournisseurs tiers (3e niveau) sont impliqués. Si la correction de la cause racine n’est pas possible, un enregistrement du problème est créé et la correction d’erreur transférée à la gestion des problèmes.
  • Suivi et escalade des Incidents : Surveille en permanence l’état de traitement des incidents en cours, de sorte que des contre-mesures peuvent être introduites dès que possible afin que les niveaux de service soient conformes aux objectifs fixés.
  • Évaluation et clôture des incidents: Présente le dossier d’incident à un contrôle de qualité final avant qu’il ne soit fermé. L’objectif est de faire en sorte que l’incident soit effectivement résolu et que toutes les informations nécessaires pour décrire le cycle de vie de l’incident soit fourni de manière suffisamment détaillée. En plus, les résultats de la résolution de l’incident doivent être enregistrés pour une utilisation future.
  • Communication Pro-Active : Le but est d’informer les utilisateurs des défaillances du service dès que ceux-ci sont connus pour le Service Desk, de sorte que les utilisateurs soient en mesure de s’adapter aux interruptions. Les communications pro-actives auprès d’utilisateurs visent également à réduire le nombre de demandes par les utilisateurs. Ce processus est également responsable de la diffusion d’autres informations aux utilisateurs, par exemple les alertes de sécurité.
  • Le rapport d’incident : Vise à fournir des informations liées aux incidents aux autres processus de gestion des services et de veiller à établir un plan d’amélioration au regard des incidents passés.

Exemples d’indicateur (Kpi) de ce processus :

  1.  Nombre d’incidents répétés, se référant à la base de connaissance des incidents;
  2. Nombre d’incidents résolus à distance par le Service support sans intervention physique sur le poste;
  3. Nombre d’incidents escaladés non résolus dans le délai de résolution;

La mise en œuvre des différents processus est un effort non négligeable pour l’entreprise qui sera valorisée sur le long ou moyen terme.

L’approche doit être mûrement posée au sein de l’entreprise afin d’établir une feuille de route acceptable et valorisée. L’implication des parties prenantes contribuant au projet est un facteur de succès du projet.

Enfin, la Direction doit communiquer et présenter son intention sur la démarche adoptée