l’audit et la gestion des incidents · l’audit et la gestion des incidents tiémoko sidibÉ,...
Post on 16-Sep-2018
242 Views
Preview:
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
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
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
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
Tiemoko.sidibe@1simple1.com
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/
top related