l’audit et la gestion des incidents · l’audit et la gestion des incidents tiémoko sidibÉ,...

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

Upload: vonhi

Post on 16-Sep-2018

244 views

Category:

Documents


1 download

TRANSCRIPT

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 ?

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/