L’AUDIT ET LA GESTION DES INCIDENTS - 1SIMPLE1 · L’audit de la gestion des inidents selon PAM...

64
L’AUDIT ET LA GESTION DES INCIDENTS Tiémoko SIDIBÉ, MBA, CISA, ITIL Expert 21 avril 2015 http://www.isaca-quebec.ca

Transcript of L’AUDIT ET LA GESTION DES INCIDENTS - 1SIMPLE1 · L’audit de la gestion des inidents selon PAM...

  • L’AUDIT ET LA GESTION DES INCIDENTS

    Tiémoko SIDIBÉ, MBA, CISA, ITIL Expert 21 avril 2015

    http://www.isaca-quebec.ca

  • Pourquoi les incidents arrivent-ils encore?

    2

    - Nouvelles technologies pas assez maîtrisées

    - Implantation à la va-vite

    - Erreurs humaines (volontaire ou involontaire)

    - Défaillances technologiques

    - Etc.

    Coût moyen des incidents

    (Ex. : Target, Sony, etc.)

    Délai moyen de résolution

    d’un incident

  • Quels sont selon vous les (4) éléments essentiels à la réussite de la gestion des incidents?

    3

    Processus (process)

    Personnes (People)

    Technologies (Product)

    - Rôles et responsabilités

    - Structure de gouvernance

    - Imputabilités

    - Activités clés

    - Métriques (Facteurs critiques de succès/

    indicateurs de performances)

    - Ressources (internes et externes)

    - Formation

    - Accompagnement

    - Travail d’équipe

    - Etc.

    - Différents outils (Cloud, SAAS, local, etc.)

    Audit (Performance)

    Les 4P

  • OBJECTIFS

    Objectifs de la présentation Comprendre la relation entre CobIT 5 et les processus de

    gestion

    Comprendre le processus de gestion des incidents

    Comprendre l’audit du processus de gestion des incidents

    Avoir une vision 365o de la gestion des incidents à la fin de la présentation

    4

  • AGENDA

    Agenda Introduction - Présentateur

    CobIT 5 et la gestion par processus

    Le processus de gestion des incidents Volet conceptuel

    Volet opérationnel

    L’audit de la gestion des incidents selon PAM (process assessment model)

    Volet conceptuel

    Volet opérationnel

    5

  • INTRODUCTION

    6

    Présentateur – Tiémoko SIDIBÉ

    13 années d’expérience

    MBA en TI (Université Laval), CISA, CobIT, ITIL Expert v3, ISO 27002

    Formateur agréé

    Entreprise – 1SIMPLE1

    Qui sommes-nous?

    Services-conseils en gestion des TI avec expertise CobIT/ ITIL / ISO20000, etc.

    Quelques clients

    SQI (société québécoise des infrastructures)

    VDQ - Ville de Québec

    CARRA (commission administrative des régimes de retraites et d’assurances)

    Quelques partenaires

    CEGEP de Sainte-Foy

    PeopleCert

  • INTRODUCTION

    7

    Entreprise – 1SIMPLE1 Nos passions/ notre expertise

    Gestion de la sécurité et de la continuité

    Gestion des services TI (ITIL, CobIT et autres bonnes pratiques)

    Formations (ITIL, BPMN et sur mesure)

    Guide 1SIMPLE1 (processus pré-documentés – adaptables & à valeurs ajoutées à 80% (inspirés CobIT,

    ITIL, BPMN, ISO 20000, ISO 27000s, PMI, etc. )) – Différents processus clés

    Stratégie(STR)

    Conception(CON)

    Transition(TRA)

    Exploitation(EXP)

    Amélioration continue(AMC)

    Diriger

    Évaluer

    Surveiller

    GOUVERNANCE

    GESTION DES TI

    Rétroaction de la gestion

    Besoins d’affaires

    Pro

    cessu

    s d

    eg

    esti

    on

    des T

    IP

    ro

    cessu

    s d

    eg

    ou

    vern

    an

    ce d

    es T

    I

    Org

    an

    isati

    on

    d

    es T

    I

    Org

    an

    isati

    on

    d

    es T

    I

    Base du Guide de documentation 1SIMPLE1

    Planifier(APO)

    Créer(BAI)

    Exécuter (LSS)

    Surveiller(SEM)

    Notre modèle

  • CobIT 5 et la gestion par processus

    CobIT 5 vue

    d’ensemble

    Cascade d’objectifs, dont les facilitants (enablers)

    8

  • 9

    Annexe D

    CobIT 5 et la gestion par processus (suite)

  • 10

    Figure 5

    CobIT 5 et la gestion par processus (suite)

    Les quatre (4) dimensions du

    tableau de bord équilibré ou

    propectif

    (Balanced Scorecard ou BSC)

    - But : mesurer la performance des

    activités d’une entreprise

    Les trois (3) paramètres

    essentiels à la création de la

    valeur pour les parties prenantes

  • 11

    Annexe B

    CobIT 5 et la gestion par processus (suite)

  • 12

    Figure 6

    CobIT 5 et la gestion par processus (suite)

  • 13

    Annexe C

    CobIT 5 et la gestion par processus (suite)

    Gestion des incidents

  • CobIT 5 et la gestion par processus (suite)

    Les facilitateurs

    Sept (7) facilitateurs, dont les processus

    14 Sept (7) facilitateurs d’entreprise

  • CobIT 5 et la gestion par processus (suite)

    15

    Combien de

    processus

    supportent

    CobIT 5 ?

    Notre focus sera juste sur la gestion des incidents dans LSS02 Fonction – Gestion

    Domaine - LSS

    Trente sept (37)

    processus, dont

    la gestion des incidents et des

    demandes de

    services (LSS02)

  • CobIT 5 et la gestion par processus (suite)

    16

    Un processus est

    un ensemble

    d'activités

    logiquement

    interreliées qui

    produisent un

    résultat déterminé.

    1

    2

    3

    Qu’est-ce qu’un

    processus?

  • Gérer les incidents – volet conceptuel

    Quelques concepts de base

    Incident - Un incident est une interruption non planifiée ou une baisse de

    qualité d'un service. Cette interruption vient surtout de la défaillance ou de

    la dégradation du fonctionnement d’un actif.

    Ex.: un serveur de fichiers est tombé

    Demande de service - Demande formelle d'un utilisateur pour quelque

    chose devant être fournie.

    Ex. : Demande d’un nouveau serveur.

    17 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Quelques concepts de base

    Incident de sécurité - un incident lié à la sécurité de l’information est indiqué

    par un ou plusieurs événement(s) de 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. Il est relié au D-I-C (Disponibilité,

    Intégrité et Confidentialité)

    Ex: Les données du serveur de fichiers tombé ont été exposées sur le Web par

    un groupe.

    Incident majeur - Un incident majeur provoque une interruption significative

    d’un service de mission. Aussi appelé Incident de priorité 1 (P1). Ex.: un

    système de gestion de recrutement dans une organisation de RH; un système

    de PES pour une organisation offrant les services en ligne (comme Amazon)

    18 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Quelques concepts de base Solution de contournement (workaround) - Une solution visant à réduire ou

    éliminer l’impact d’un incident pour lequel une résolution complète n’est pas

    encore disponible.

    Escalade fonctionnelle - L’escalade fonctionnelle consiste à transférer un

    incident à une ressource plus spécialisée ou un groupe de support

    possédant un plus haut degré d’expertise.

    Escalade hiérarchique - L’escalade hiérarchique consiste à informer ou à

    impliquer les niveaux plus seniors de gestion (chef d’équipe ou gestionnaire,

    RSIN/COGI) afin d’aider dans les activités de résolution.

    Ex.: Chaîne décisionnelle ou de commandement (chef d’équipe au président/

    membres du CA)

    19 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Description et buts

    Fournir une réponse rapide/ efficace et une résolution à tous les types

    d'incidents (applicatifs, technologiques ou de sécurité).

    Restaurer le service dans les conditions normales (selon les ententes de

    niveaux de service – SLA. Ex: Temps de transaction 50/Seconde);

    Valeurs ajoutées

    Accroître la productivité et minimiser les perturbations par la résolution

    rapide des incidents.

    Justifier une augmentation des dépenses (Incident = dimunition de valeur;

    Demande de service = création de valeur)

    20 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités génériques de la gestion des incidents selon CobIT 5 Activité 1 - Définir les schémas de classification des incidents

    Activité 2 - Enregistrer, classer et prioriser les incidents

    Activité 3 - Rechercher, diagnostiquer et assigner les incidents

    Activité 4 - Résoudre les incidents et revenir aux opérations normales

    Activité 5 - Fermer les incidents

    Activité 6 - Suivre l'état et produire des rapports

    21 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités Activité 1 - Définir les schémas de classification des incidents

    Définir les critères de classification (types et catégories)

    Définir les critères de priorisation des incidents (Impacts vs Urgence)

    Définir les règles d’escalade fonctionnelle

    Définir les règles d’escalade hiérarchique

    Définir des procédures spécifiques pour les traitements des incidents majeurs

    Définir les procédures spécifiques pour le traitement des incidents de sécurité

    Définir l’architecture de la base de connaissances

    22 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités (suite) Activité 1 - Définir les schémas de classification des incidents

    Définir les critères de classification (types et catégories)

    Exemples de type : applicatifs, technologiques, sécurité

    Exemple de catégorie - 1 : Localisation/ Service/ Système/ Application

    Exemple de catégorie - 2: Application/ Base de données/ Serveurs/ disques

    Exemple classification avec la méthode OBASHI (Ownership, Business Process, Application, System, Hardware, Infrastructure)

    23

    Propriétaire

    Services

    Applications

    Matériels

    Équipements réseau

    Roulent sur

    Systèmes d’exploitation

    Sont offerts grâce aux

    Demeurent imputable des

    Reposent sur

    Sont reliés entre elles par

    Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités Activité 1

    24

    Exemple de modèle OBASHI

    Note - La classification est propre à chaque organisation,

    mais il faut s’appuyer sur les bonnes façons de faire. Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités Activité 2 - Enregistrer, classer et prioriser les incidents

    Journaliser les incidents

    Classifier les incidents (types et catégories)

    Prioriser les incidents selon la grille de priorisation (P1 à P5 en général : Impact Vs Urgence)

    25

    Priorité Impact

    Élevé Moyen Faible

    Urgence Élevée 1 2 3

    Moyenne 2 3 4

    Faible 3 4 5

    Code de priorité Description Ex. Temps de résolution (niveaux de service - SLO)

    P1 Critique (incident majeur) 1h

    P2 Important 8h

    P3 Moyen 24h

    P4 Faible 48h

    P5 Planification (en vue de) Planifié

    Tableau 1

    Tableau 2

    Ex. Voir – un exemple de grille plus élaborée Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités Activité 3 - Rechercher, diagnostiquer et assigner les incidents

    Préalable – Établir les niveaux de service (SLO – Service Level Objective)

    Baliser les symptômes de l’incident

    Diagnostiquer et rechercher une solution de contournement à l’incident

    Assigner l’incident à des groupes de support appropriés selon les paramètres du schéma de classification (N1/ N2/ N3 ou expert/fournisseur).

    Prendre en considération les niveaux de service opérationnels entre N1 à N3. Ex : le délai de traitement entre N1 et N2

    26 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités Activité 4 - Résoudre les incidents et revenir aux opérations

    normales Trouver la solution et appliquer cette dernière afin de restaurer le

    service

    Effectuer les actions de récupération, au besoin

    Documenter les solutions de contournement ou la solution permanente

    Alimenter la base de connaissances

    27 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités Activité 5 - Fermer les incidents

    Vérifier la satisfaction de l’utilisateur

    Donner un délai à l’utilisateur pour réagir

    Fermer l’incident de façon définitive (clôture)

    28 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Activités Activité 6 - Suivre l'état et produire des rapports

    Étape préalable – Définir les métriques (éléments de contrôles)

    Exemple de métrique :

    Nombre d’incidents de sécurité pour une période donnée sur le total des incidents

    Délai moyen dans la résolution d’un incident de sécurité Temps moyens de traitement par niveau (N1, N2, N3) Incidents avec un délai de traitement dépassé Etc.

    Surveiller les métriques dans le cadre de l’escalade fonctionnelle ou hiérarchique

    Faire un suivi périodique

    Produire et distribuer les rapports sur une base périodique

    29 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Rôles (exemple) Propriétaire du processus

    Gestionnaire du processus (au niveau opération)

    Responsable de la sécurité de l’information

    Responsable de la protection de la vie privée

    Responsable niveau 1 et 2

    Etc.

    Note : Il est important d’avoir un gardien du processus (gestionnaire du processus)

    Parallèle avec les rôles au Gouvernements du Québec COGI – Conseiller organisationnel en gestion des incidents ROSI – Responsable opérationnel de la sécurité de l’information COSI – Conseiller organisationnel de la sécurité de l’information

    30 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Matrice RACI (matrice de rôles et responsabilités) R (Responsable/ responsible) : le ou les intervenants qui doivent

    exécuter l'activité ou une partie de celle-ci

    A (Imputable/ accountable) : le seul intervenant qui est imputable de la performance et de la qualité de la réalisation de l'activité

    C (Consulté/ consulted) : le ou les intervenants qui sont consultés et qui donnent leur avis dans la réalisation de l'activité.

    I (Informé/ informed) : le ou les intervenants qui sont informés de la réalisation de l'activité.

    31

    Il existe aussi d’autres formes de RACI plus élaborées : RACI-VS, RASCI, etc.

    Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Matrice RACI de la gestion des incidents selon CobIT 5 Tableau

    32 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Liens avec les autres processus CobIT 5 en terme d’intrants et d’extrants Les processus du domaine APO – Aligner, Planifier et Organiser

    APO08 – Gérer les relations

    APO09 – Gérer les accords de services (SLA)

    APO11 – Gérer la qualité

    APO12 – Gérer le risque

    APO13 – Gérer la sécurité

    Les processus du domaine BAI – Bâtir, acquérir et implanter

    BAI04 – Gérer la disponibilité et la capacité

    BAI06 – Gérer les changements

    BAI07 – Gérer l’acceptation du changement et de la transition

    BAI10 – Gérer les configurations

    33 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Liens avec les autres processus CobIT 5 en terme d’intrants et d’extrants Les processus du domaine LSS – Livrer, Servir et Soutenir

    LSS01 – Gérer les opérations TI

    LSS03 – Gérer les problèmes

    LSS04 – Gérer la continuité

    LSS05 – Gérer les services de sécurité

    Les processus du domaine SEM – Surveiller, évaluer et mesurer

    SEM01 – Surveiller, évaluer et mesurer la performance et la conformité

    34 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Diagramme BPMN (Business process modeling notation)

    35

    Exemple de

    processus de

    gestion des

    incidents

    simplifié

    Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Indicateurs de performance clés (métriques) Quelques exemples d’IPC

    Nombre et pourcentage d’incidents dus à l’arrêt des processus d’affaires critiques de l’organisation

    Temps moyen entre l’enregistrement de l’incident et la remise en état du service concerné

    Pourcentage d’incidents résolus à l’intérieur des délais connus et acceptés

    Nombre et pourcentage d’incidents majeurs

    Nombre et pourcentage d’incidents de sécurité

    36

    Il ne suffit pas seulement de définir les métriques, les métriques doivent être

    SMART (spécifique, mesurable, accessible, réaliste, temporel)

    (Specific, Measurable, Attainable, Relevant, Time-bound)

    Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Autre procédure spécifique à développer dans la mise en place de la

    gestion des incidents

    Gestion des incidents majeurs

    Cellule de crise

    Composition – Membres permanents s ou temporaires

    Plan de communication

    Chaînes de coordonnées,

    Moyens (écrans, téléphones, etc.)

    37 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet conceptuel

    Autre procédure spécifique à développer dans la mise en place de la

    gestion des incidents

    Gestion des incidents majeurs

    Cellule de crise

    Composition – Membres permanents s ou temporaires

    Plan de communication

    Chaînes de coordonnées,

    Moyens (écrans, téléphones, etc.)

    38 Processus

    Personnes

    Technologies

    Audit

  • Pause !

    39

  • Gérer les incidents – volet conceptuel

    Outil (technologies) – Quelques critères de sélection Bon positionnement GARTNER (MAGIC Quadrant) (souhaitable)

    Supporte le processus de gestion des incidents

    Supporte vos autres processus déjà en place (intégration)

    Supportera vos processus à mettre en place en à court/ moyen terme

    Supporte le processus de gestion des actifs (BAI09) et la gestion des configurations (BAI10)

    Supporte les ententes de service (SLA/ SLO)

    Supporte la procédure de gestion des incidents de sécurité

    Permet la mise en place d’une base de connaissances

    Etc.

    40 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet opérationnel

    41

    Conceptuel

    (haut niveau)

    Opérationnel

    Transition

    Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet opérationnel

    Gestion du changement (dimension humaine dans la mise en place du processus)

    Enjeux de la mise en place du processus de gestion des incidents

    Perception d’ajouter de la lourdeur Nouvelles tâches

    Nouveaux rôles

    Centralisation des points d’entrée (aussi vrai pour les incidents de sécurité)

    Communication du processus de gestion des incidents

    Adoption du processus de gestion des incidents

    42 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet opérationnel

    Pièges à éviter Penser que le processus va fonctionnement tout seul

    Pas besoin d’avoir l’implication des gestionnaires (approche Top-down/ Buy-in)

    Développer votre processus en fonction de l’outil

    Pas besoin de faire un suivi du processus

    Pas besoin de documenter le processus

    Etc.

    43 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet opérationnel

    Bonnes pratiques à adopter

    Impliquer des gestionnaires (directeurs) – Essentiel

    Effectuer la gestion du changement

    Établir un sentiment d’urgence

    8 Étapes de John P. Kotter (livre à lire – Establishing sense of urgency)

    Former et sensibiliser sur le processus

    Rôles et responsabilités

    44 Processus

    Personnes

    Technologies

    Audit

  • Gérer les incidents – volet opérationnel

    Bonnes pratiques à adopter

    Effectuer le support de début de vie (ELS – Early life support)

    Réorganisation des équipes de support

    Arrimer le processus avec votre outil en place

    Maintenir un tableau de bord

    suivi des indicateurs de performance

    Définir les politiques qui encadrent le processus

    Documenter le processus

    45 Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    46

    Pourquoi doit-on utiliser un modèle d’évaluation de processus?

    Quand utiliser un modèle d’évaluation de processus?

    Processus

    Personnes

    Technologies

    Audit

    Évaluer vos processus en place

    S’assurer de la santé de vos processus

    Utiliser les méthodes connues et éprouvées

    Etc.

    À la veille d’un nouveau projet

    À la suite de l’implantation d’un ensemble de processus

    S’assurer de la conformité avec une réglementation ou une exigence gouvernementale (ex.: niveau «Établi» pour la gestion des incidents au gouvernement du Québec)

    Etc.

  • Audit des incidents – volet conceptuel

    47

    PAM – Process Assessment Model Historique

    Modèle de maturité (CobIT 4.1) vs Modèle de capabilité (PAM – CobIT 5)

    Différence entre un modèle de maturité et le modèle de capabilité

    Modèle de maturité répond à la question

    Est-ce que le processus est mature à haut niveau? Mais, il ne permet pas de mesurer si le processus a atteint ses objectifs visés (outcomes)

    Modèle de capabilité répond à la question

    Est-ce que le processus sert ses buts?

    Est-ce que le processus livre ses objectifs visés ? il permet de mesurer si le processus atteint ses objectifs visés (outcomes)

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    48

    PAM – Process Assessment Model

    Basé sur le modèle de référence des processus de COBIT 5.

    Basé sur la norme ISO15504 (Software Process Improvement and Capability determination).

    Permet l’évaluation du cycle de développement informatique

    Permet l’évaluation des processus

    (CobIT 5) (ISO15504)

    (PAM)

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    49

    Modèle de référence de processus (process reference model)

    Ensemble des processus CobIT décrit en terme de buts (purpose) et

    d’extrants tangible (outcomes) avec une architecture détaillée

    décrivant les relations entre les processus

    Attribut de processus (Process attribute)

    Ensemble de caractéristiques mesurables qui permettent d’attester

    de la capabilité d’un processus. Il se fie sur l’existence de bonnes

    pratiques et des produits de travail.

    Bonnes pratiques (base practice)

    Activité qui lorsqu’elle est réalisée, contribue à la réalisation d’un but

    spécifique du processus.

    Ex. : Définir un schéma de classification des incidents

    Quelques concepts de base

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    50

    Produit de travail (WP – Work product)

    Extrant tangible relié à l’exécution du processus.

    Ex.: Ententes de services (SLA)

    Niveau de capabilité (Capability level)

    Niveau 0 – Processus Incomplet

    Niveau 1 – Processus exécuté

    Niveau 2 – Processus géré

    Niveau 3 – Processus établi

    Niveau 4 – Processus prévisible

    Niveau 5 – Processus en optimisation

    Quelques concepts de base

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    51

    PAM – Process assessment model Buts

    Apporter de la valeur aux organisations en augmentant l’efficacité et

    l’efficience

    Identifier les forces, les faiblesses et les risques reliés au processus

    S’assurer que le processus adresse les besoins d’affaires (à travers

    cascade d’objectifs – Goals cascade)

    Valeurs ajoutées

    Reproductible – Comparer les résultats et mesurer les progrès

    Logique – Critère objectifs

    Facile à comprendre – facilement explicable aux parties prenantes

    Fiable et robuste – Reflète l’état actuel du processus

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    52

    Niveau 0 - Processus incomplet Attribut de processus (PA) - Aucun

    Interprétation

    Processus non mis en œuvre

    Processus ne parvient pas à réaliser la fonction désirée

    Aucune preuve que les objectifs du processus seront atteints

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    53

    Niveau 1 – Processus exécuté Attribut de processus (PA) - Un (1)

    PA 1.1 – Performance du processus

    Interprétation

    Processus mis en œuvre réalise la fonction désirée

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    54

    Niveau 2 - Processus géré Attribut de processus (AP) – Deux (2)

    AP 2.1 – Gestion de la performance

    AP 2.2 – Gestion des résultats de l’activité

    Interprétation

    Niveau 1 atteint (pleinement)

    Processus mis en œuvre et bien géré (planifié, surveillé et ajusté)

    Processus avec des résultats adéquatement établis, contrôlés et maintenus

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    55

    Niveau 3 – Processus établi Attribut de processus (PA) – Deux (2)

    PA 3.1 – Définition du processus

    PA 3.2 – Déploiement du processus

    Interprétation

    Niveau 2 atteint (pleinement)

    Processus mis en œuvre selon une procédure définie qui permet l’atteinte des résultats souhaités

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    56

    Niveau 4 - Processus prévisible Attribut de processus (PA) - Deux (2)

    PA 4.1 – Gestion du processus

    PA 4.2 – Contrôle du processus

    Interprétation

    Niveau 3 atteint (pleinement)

    Processus fonctionnement selon des limites définies qui assurent l’atteinte des résultats souhaités

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    57

    Niveau 5 - Processus en optimisation Attribut de processus (PA) – Deux (2)

    PA 5.1 – Innovation du processus

    PA 5.2 – Optimisation du processus

    Interprétation

    Niveau 4 atteint (pleinement)

    Processus est amélioré continuellement afin d’atteindre les objectifs d’affaires pertinents actuels et projetés

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet conceptuel

    58

    Score de l’audit - Notation des attributs de processus (PA)

    N : 0-15%. Non réalisé (N – not achieved)

    P : 15 à 50%. Partiellement réalisé (P – Partially achieved)

    L : 50% à 85%. Largement réalisé (L – Largely achieved)

    F : 85 à 100%. Pleinement réalisé (F – Fully achieved)

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet opérationnel

    59

    Exemple d’application de PAM avec la gestion des incidents Voir la fiche Excel

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet opérationnel

    60

    Les limites de PAM Ce n’est qu’un outil

    Prendre en considération les autres dimensions du processus (3 autres P)

    Processus

    Personnes

    Technologies

    Audit

  • Audit des incidents – volet opérationnel

    61

    Programme d’audit de processus Initiation et préparation

    • Découverte du contexte

    • Planification et organisation de l’audit

    • Lancement

    Évaluation

    • Collecte d’informations

    • Consolidation des résultats

    Analyse

    • Analyse des résultats

    • Identification des forces, faiblesses et risques

    • Recommandations et rapports détaillés

    Plan d’amélioration et rapport

    • Présentation du rapport à la gestion

    • Établir un calendrier de réalisation selon les priorités

    PAM

    Processus

    Personnes

    Technologies

    Audit

  • CONCLUSION

    62

    L’implication des gestionnaires est essentielle au succès

    du processus de gestion des incidents Agir à titre de «champions» Agir à titre d’«agents de changement»

    Il est important de prendre en considération les 4P dans la mise en place d’un processus de gestion des incidents

    La mise en place d’un processus de gestion des incidents implique un travail d’équipe

  • Merci!

    63

    Tiemoko Sidibé, MBA, CISA, ITIL Expert V3

    [email protected]

    www.1simple1.com

    1-418-261-5954

    Questions ?

    mailto:[email protected]://www.1simple1.com/

  • Références

    64

    Nouveau cadre de gouvernance de la sécurité de l'information –

    Présentation de Mohamed Darabid/ CT à l’ISACA-Québec, le 14 octobre 2015

    ISACA – CobIT 5 – Les processus facilitants

    ISACA – CobIT 5 – PAM (Process Assessment Model)

    ITIL – Information Technology Infrastructure Library

    ISO15504 - Software Process Improvement and Capability Determination

    ISO27000 series – Information Security

    OBASHI - http://www.obashi.co.uk/methodology/methodology.asp

    Tripwire - http://www.tripwire.com/state-of-security/latest-security-news/

    average-cyber-crime-incident-costs-companies-12-7-million/

    Huit (8) étapes de John P. Kotter - http://www.kotterinternational.com/

    the-8-step-process-for-leading-change/