Les incidents coûtent de plus en plus chers à traiter. Les organisations répondent souvent à cela par une augmentation des solutions technologiques (Cloud, Big Data, externalisation, outil de balayage, etc.) sans forcement mettre l’emphase sur le volet processus et le volet humain. Le résultat, on le connaît : beaucoup de technologies avec peu de résultat en cas d’incident, délai de traitement des incidents défoncés (SLA), etc. Le but cette présentation est de comprendre le processus de gestion des incidents selon COBIT5 de l’ISACA. La présentation consistera à regarder la gestion des incidents de long en large (vision 365º) – volet conceptuel et volet opérationnel.

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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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
Processusde
gestiondesTI
Processusde
gouvernancedesTI
Organisation
desTI
Organisation
desTI
Base du Guide de documentation 1SIMPLE1
Planifier
(APO)
Créer
(BAI)
Exécuter
(LSS)
Surveiller
(SEM)
Notre modèle

8. CobIT 5 et la gestion par processus
CobIT 5 vue
d’ensemble
 Cascade
d’objectifs, dont
les facilitants
(enablers)
8

9. 9
Annexe D
CobIT 5 et la gestion par processus (suite)

10. 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. 11
Annexe B
CobIT 5 et la gestion par processus (suite)

12. 12
Figure 6
CobIT 5 et la gestion par processus (suite)

13. 13
Annexe C
CobIT 5 et la gestion par processus (suite)
Gestion des incidents

14. CobIT 5 et la gestion par processus (suite)
Les facilitateurs
 Sept (7)
facilitateurs,
dont les
processus
14Sept (7) facilitateurs d’entreprise

15. 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)

16. 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?

17. 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.
17Processus
Personnes
Technologies
Audit

18. 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)
18Processus
Personnes
Technologies
Audit

19. 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)
19Processus
Personnes
Technologies
Audit

20. 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)
20Processus
Personnes
Technologies
Audit

21. 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
21Processus
Personnes
Technologies
Audit

22. 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
22Processus
Personnes
Technologies
Audit

23. 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

24. 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

25. 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éeProcessus
Personnes
Technologies
Audit

26. 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
26Processus
Personnes
Technologies
Audit

27. 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
27Processus
Personnes
Technologies
Audit

28. 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)
28Processus
Personnes
Technologies
Audit

29. 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
29Processus
Personnes
Technologies
Audit

30. 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
30Processus
Personnes
Technologies
Audit

31. 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

32. Gérer les incidents – volet conceptuel
Matrice RACI de la gestion des incidents selon CobIT 5
 Tableau
32Processus
Personnes
Technologies
Audit

33. 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
33Processus
Personnes
Technologies
Audit

34. 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é
34Processus
Personnes
Technologies
Audit

35. 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

36. 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

37. 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.)
37Processus
Personnes
Technologies
Audit

38. 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.)
38Processus
Personnes
Technologies
Audit

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.
39Processus
Personnes
Technologies
Audit

40. Gérer les incidents – volet opérationnel
40
Conceptuel
(haut niveau)
Opérationnel
Transition
Processus
Personnes
Technologies
Audit

41. 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
41Processus
Personnes
Technologies
Audit

42. 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.
42Processus
Personnes
Technologies
Audit

43. 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
43Processus
Personnes
Technologies
Audit

44. 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
44Processus
Personnes
Technologies
Audit

45. Audit des incidents – volet conceptuel
45
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.

46. Audit des incidents – volet conceptuel
46
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

47. Audit des incidents – volet conceptuel
47
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

48. Audit des incidents – volet conceptuel
48
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

49. Audit des incidents – volet conceptuel
49
 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

50. Audit des incidents – volet conceptuel
50
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

51. Audit des incidents – volet conceptuel
51
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

52. Audit des incidents – volet conceptuel
52
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

53. Audit des incidents – volet conceptuel
53
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

54. Audit des incidents – volet conceptuel
54
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

55. Audit des incidents – volet conceptuel
55
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

56. Audit des incidents – volet conceptuel
56
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

57. Audit des incidents – volet conceptuel
57
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

58. Audit des incidents – volet opérationnel
58
Exemple d’application de PAM avec la gestion des
incidents
 Voir la fiche Excel
Processus
Personnes
Technologies
Audit

59. Audit des incidents – volet opérationnel
59
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

60. Audit des incidents – volet opérationnel
60
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

61. CONCLUSION
61
 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

62. Merci!
62
Tiemoko Sidibé, MBA, CISA, ITIL Expert V3
Tiemoko.sidibe@1simple1.com
www.1simple1.com
1-418-261-5954
Questions ?

63. Références
63
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/