Identifier les risques

Identifier les risques
d’un projet informatique
Module de formation
Avril 2013

Présentons-nous
Avril 2013www.cleodit.fr
2

Carine Pascal, CleodIT
Audit & Evaluation
• Evaluation qualité
• Evaluation technique :
processus / produit
• Accompagnement à la
certification /
accréditation
Expertise
• Sûreté / Sécurité : analyse
de risque, dossier de
sûreté…
• Système / Logiciel :
système critique, système
à forte composante
logicielle, système
embarqué
Formation
• Qualité : approche
processus, audit,
indicateurs, tableau de
bord…
• Sûreté de fonctionnement
: méthodes et outils,
FMEA, HAZOP, SEEA…
R&D
• Recherche
• Développement
expérimental (pilote,
prototype)
• Technologies de
l’information
3

Avant-propos
• Le discours associé à ce support sera axé sur la démarche
pédagogique imaginée pour la formation
• Le contenu proposé ci-après est un exemple (partiel) de
support de formation
• La méthodologie proposée dans ce contenu est générique et
reproductible
• Applicable aux fonctions de gestion de projet
• Applicable aux fonctions techniques du projet
4

PLAN DE FORMATION
On ne fait pas de projet sans risque
Le plus grand risque est de ne pas faire de projet
5

Plan de formation (1/6)
6
Projet informatique
Vocabulaire

7
Risque
Vocabulaire

8
PLAN DO
CHECKACT
Processus
d’identification du risque

9
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6
PLAN DO
CHECKACT
Identifier le risque d’un projet informatique tout au long de son cycle de vie

10
Cas d’étude

11
Bilan de formation

GÉNÉRALITÉS ET VOCABULAIRE
Exigences
Présentation d’un projet informatique : découpage en phases, découpage en biens, découpage en fonctions
Evénement redouté, défaillance
Notion de risque
12

Exigence
Une exigence est un énoncé :
• qui peut être rédigé dans un langage naturel ou dans un
langage mathématique
• qui traduit des besoins et/ou des contraintes (comme des
contraintes techniques, des contraintes de coûts, des
contraintes de délais, ou d’autres types de contrainte)
• qui caractérise un élément du système [le projet, NDLR] à
réaliser à l’aide d’un identifiant unique
Référence : Association Française d’Ingénierie Système
Exemple : une norme, un cahier des charges
13

Exigence
Une exigence est un énoncé :
• qui peut être rédigé dans un langage naturel ou dans un
langage mathématique
• qui traduit des besoins et/ou des contraintes (comme des
contraintes techniques, des contraintes de coûts, des
contraintes de délais, ou d’autres types de contrainte)
• qui caractérise un élément du système [le projet, NDLR] à
réaliser à l’aide d’un identifiant unique
14
Besoin ≠ Moyen
Explicite ou Implicite

Attributs
QUALITE
COÛT
DELAI
Sécurité
Disponibilité
15

Caractérisation
Attribut Exigence Indicateur Valeur
Coût Le projet doit respecter
l’objectif global de
productivité de l’organisme
TJM > 500 €
Délai Le projet ne doit pas
donner lieu à des pénalités
de retard
Retard maximum sur une
livraison
5 jours
Qualité
(Compétences)
Les membres du projet
doivent avoir les
compétences requises
Efficacité des formations > 2
Qualité
(Satisfaction client)
Le projet doit permettre de
fidéliser un nouveau client
Satisfaction client mesurée
lors du bilan de fin de
projet
80 %
Nombre de réclamations 0
Processus de management
du risque
Le projet doit appliquer le
processus
Nombre de non-conformité
moyen par audit
< 2
Le projet doit contribuer à
améliorer le processus
Nombre de fiches
d’amélioration émises
> 0
…
16

Projet informatique
Projet (informatique) : ensemble de biens interagissant
entre eux pour satisfaire des fonctions requises. Ces
fonctions ont pour finalité de répondre à des exigences.
17
MOA MOE
Sous-
traitant

Fonction
18
Fonction(deservice)
Actiond’unprojetexpriméeen
termedefinalité
Fonction principale (fonction d’interaction)
Fonction qui traduit la raison d’être du projet
dans son environnement, pour répondre au
besoin
Fonction de contrainte (fonction d’adaptation)
Fonction qui doit être satisfaite par le projet,
sans traduire sa raison d’être

Exemple de
fonction principale
• Développer un logiciel informatique
• Développer l’algorithme de calcul
• Développer l’IHM
• Fournir le support technique
• Assurer la maintenance
• …
19

Exemple de
fonction de contrainte
• Respecter la norme ISO 9001
• Préserver l’image / la réputation de l’organisme
• Concurrencer les applications similaires existantes
• …
20

Interfaces
21
Attention aux
interfaces
(externes / internes)

Bien
(actif)
• Bien : entité représentant de la valeur pour le projet ou pour
l’organisme
• Bien primordial : fonction de service, donnée
• Bien en support : matériel, logiciel, réseau, personnel, locaux,
sous-traitant, information (document papier, document
numérique, connaissances), moyen d’accès (compte utilisateur,
clé de chiffrement)…
22
Traduction du besoin
« Matérialisation » des
biens primordiaux

Phases du cycle de vie
23
Lancement Réalisation
Bilan de
réalisation
Garantie
Bilan de
garantie
Clôture
- Lancement de projet externe
- Lancement de projet interne
- Elaboration du PQP
- Elaboration du plan de management des risques
- Développement
- Recette
- Bilan de fin de projet externe
- Bilan de fin de projet interne
- Bilan de fin de garantie externe
- Bilan de fin de garantie interne
Affaire
- Qualification de l’affaire
- Elaboration de la proposition commerciale
- Revue de la commande

Phases – Redécoupage (Cycle en V)
24
Lancement Réalisation
Bilan de
réalisation
Garantie
Bilan de
garantie
Clôture
- Lancement de projet externe
- Lancement de projet interne
- Elaboration du PQP
- Elaboration du plan de management des risques
- Bilan de fin de projet externe
- Bilan de fin de projet interne
- Bilan de fin de garantie externe
- Bilan de fin de garantie interne
Affaire
- Qualification de l’affaire
- Elaboration de la proposition commerciale
- Revue de la commande
- Développement
- Recette

Evénement redouté
(événement indésirable)
• Evénement redouté : événement dont la survenue n’est
pas souhaitée en regard des exigences
• Accident, si la gravité est importante
• Incident, si la gravité est peu importante
25

Défaillance
• Défaillance : cessation de l’aptitude d’un bien à satisfaire
une fonction requise
26

Types de défaillance
• Défaillance aléatoire : défaillance d’une entité dont la cause est
aléatoire
• Défaillance systématique : défaillance liée de manière
déterministe à une cause
• Défaillance primaire : défaillance d'une entité dont la cause
n'est pas une défaillance d'une autre entité
• Défaillance secondaire : défaillance d'une entité dont la cause
est une défaillance d'une autre entité et pour laquelle cette
entité n’est pas dimensionnée
• Défaillance de commande : défaillance d'une entité dont la
cause est une défaillance d'une autre entité et pour laquelle
cette entité est dimensionnée
27
matérielle

Risque
• Risque : Possibilité qu’une défaillance d’un bien
conduise à un événement redouté
28

Barrière de sûreté
• Action en réduction du risque : action de traitement du
risque
• Barrière de sûreté : fonction réalisant l’action en
réduction du risque
29

IDENTIFICATION DU RISQUE
L’étape d’identification dans le processus de management du risque
Identification des sources de risque, des événements redoutés, de leurs causes et de leurs conséquences
Méthodes et outils : APR, AMDE(C), HAZOP
30

31
Etablissement du contexte
Evaluation du risque
Traitement du risque
Communicationdurisque
Surveillanceetréexamendurisque
Identification du risque
Estimation du risque
Analyse du risque
Appréciation du risque
Processus de
management du risque

• Objectifs
• Quelles sont les exigences applicables au projet ?
• Quels attributs doivent être suivis en regard de
ces exigences ?
• Quel est le niveau d’analyse souhaité ?
• Périmètre
• Quelles phases du cycle de vie du projet doivent
être analysées ?
• Organisation
• Plan de management du risque : rôles et
responsabilités, échanges, méthodes et outils,
enregistrements…
32

• Objectifs
• Quelles sont les exigences applicables au projet ?
• Quels attributs doivent être suivis en regard de
ces exigences ?
• Quel est le niveau d’analyse souhaité ?
• Périmètre
• Quelles phases du cycle de vie du projet doivent
être analysées ?
• Organisation
• Plan de management du risque : rôles et
responsabilités, échanges, méthodes et outils,
enregistrements…
33
Processus itératif

• Identification du risque : processus de recherche, de
reconnaissance et de description du risque
34
Identification des sources d’information
Identification des biens dans le périmètre
Identification des événements redoutés
Identification des barrières de sûreté existantes
Identification des causes des événements redoutés
Identification des conséquences des événements redoutés

Identification
des sources d’information
• Personnes à rencontrer
• Responsable du bien (administrateur système…)
• Utilisateur du bien
• Autre : responsable d’activité,
expert, sous-traitant…
• Documentation à étudier
• Registre d’accidents/incidents
• Plan de traitement des risques
• REX
• Spécification technique
35

Identification des biens
36
Attention à la
granularité choisie

Analyse fonctionnelle
• Analyse fonctionnelle externe
• Exemple : Méthode MISME
• Analyse fonctionnelle interne
• Exemple : Méthode SADT
37

Exemple d’AF externe
38
Utilisateur
Applications
mobiles
existantes
Application
mobile
Mobile
Projet
dans une
phase
donnée
MOA
Normes SMQ
Plus globalement,
les éléments
entrants
Plus globalement,
les éléments
à produire

Tableau
d’analyse fonctionnelle
• Synoptique des analyses fonctionnelles externe et interne
• Lien entre les fonctions issues de l’AF externe et les
fonctions techniques les réalisant issues de l’AF interne
• Lien entre les fonctions issues de l’AF externe et les
biens supportant leur réalisation issus de l’AF interne
39
B1 B2 B3 B4
F1 F11 X
F12 X
F13 F131 X
F132 X
…

Exemple de tableau d’AF
40
B1 : mobile
Iphone
E2 : Ordinateur
MacOS X
E3 : ordinateur
Windows
E4 : Suite
bureautique
F0 : Développer
l’application
mobile
F1 : Développer le
cœur applicatif X
F2 : Développer
l’IHM X
F3 : Tester
l’application
F31 : Tester
l’application
sur hôte
X
F32 : Tester
l’application
sur cible
X X
…

Identification
des événements redoutés
• Liste générique sectorielle
• Liste basée sur le REX
• Exemple : catalogue de menaces EBIOS
• Exemple : l’organisme peut estimer ne pas être exposé à
une menace humaine interne malveillante
41
A adapter
(préciser / ajouter /
supprimer)

Nature de l’ER
• Naturelle (incendie, inondation)
• Délibérée (vol…)
• Accidentelle (effacement de données…)
42

Identification
des barrières existantes
43
Bien (support) auquel
est associée la fonction
Bien (support)
supportant sa réalisation
F0 : Activer une alarme
anti-intrusion durant les
heures de fermeture
Locaux de la
société
Alarme
F1 : Permettre le
contrôle d’accès par mot
de passe sous MacOS X
MacOS X
F2 : Permettre le
contrôle d’accès par mot
de passe sous Windows
XP
Windows XP
A identifier
parmi les
biens ?

Identification
des modes de défaillance
• Mode de défaillance : état observable d’un bien défaillant
pour une fonction requise
• La liste des modes de défaillance doit être établie de
manière exhaustive
• Les modes de défaillance doivent être indépendants
44

Exemples de défaillances
ER = « Pas d’accès internet »
• Défaillance systématique : serveur inopérant dont la cause
est un bug logiciel sur le serveur
• Défaillance aléatoire : serveur inopérant dont la cause est
une panne matérielle du serveur
• Défaillance primaire : idem
• Défaillance secondaire : serveur inopérant dont la cause
est une panne d’électricité
• Défaillance de commande : fournisseur d’accès internet
inopérant, erreur de câblage
45

HAZOP
• HAZard and OPerability Studies : étude de danger et
d’exploitabilité
• Etudie l’influence des déviations de divers paramètres
régissant un bien par rapport à leurs valeurs nominales de
fonctionnement
46
Non Plus Moins
Aussi bien
que
Une partie
de
Inverse Autre que Tôt/avant Tard/après

Détermination HAZOP
des modes de défaillance
47
Non Plus Moins Aussi
bien
que
Une
partie
de
Inverse Autre
que
Tôt /
Avan
t
Tard /
Après
Entrant
du
projet
Accès
Pas
d’accès
N/A N/A N/A N/A N/A Accès
non
autorisé
N/A Pas
d’accès
Entrant
du
projet
Contenu
Insuffi-
sant
Supplé-
mentaire
Insuffi-
sant
N/A Corrom-
pu
N/A Authen-
ticité
Insta-
ble
Périmé
…

Modes de défaillance
d’une fonction
• Fonctionnement prématuré ou intempestif
• Non fonctionnement ou fonctionnement retardé
• Fonctionnement interrompu ou intermittent
• Fonctionnement continu
• Fonctionnement dégradé
48
Légende :
Fonctionnement attendu
Fonctionnement observé

Identification
des conséquences
• Impact : dommage exprimé en terme d’atteinte à l’un des
attributs de sûreté
• Exemple : Allongement du délai de réalisation du projet
• Conséquence : dommage exprimé en terme d’atteinte au
projet ou à l’organisme
• Exemple : Perte de clientèle
49

Construction des scenarios
50
• La norme ISO 31010 (cf. annexe) propose une liste de
méthodes et outils applicables
• Les approches méthodologiques sont à privilégier
• APR
• AMDEC

APR
• Analyse Préliminaire des Risques
• Méthode déductive : on part des événements redoutés
pour en déterminer les causes (bien concerné, phase du
cycle de vie, événement initiateur…)
• Les événements considérés sont indépendants
51

Tableau d’APR/APD
• 1) Identification unique du scenario
• 2) Evénement redouté
• 3) Situation préalable à l’accident potentiel
• 4) Evénement redouté initiateur ou cause rendant effective la situation dangereuse
• 5) Bien auquel on peut associer une défaillance et qui est à l’origine de l’événement
initiateur
• 6) Evénement complémentaire transformant la situation dangereuse en accident potentiel
(indépendant de l’événement initiateur et dont un autre bien est à l’origine)
• 7) Phase d’utilisation
• 8) Conséquences du scenario
• 9) Criticité du risque
• 10) Actions en réduction de risque
• 11) Remarques ou commentaires éventuels concernant le scenario ou la méthodologie
52
N°
Accident
potentiel
Situation
dangereuse
Evénement
causant une
situation
dangereuse
Entité
dangereuse
Evénement
causant un
accident
potentiel
Phase Effets Criticité
Traitement
du risque
Remarques /
Commentaires
1 2 3 4 5 6 7 8 9 10 11

Exemple d’APR
53
N°
Accident
potentiel
Situation
dangereuse
Evénement
causant une
situation
dangereuse
Entité
dangereuse
Evénement
causant un
accident
potentiel
Phase Effets Gravité
Traitement
du risque
Remarques /
Commentaires
1 2 3 4 5 6 7 8 9 10 11
1
Perte, vol ou
déterioration
d'un bien
Dommage
naturel
Défaillance du coffre-
fort
Coffre-fort Incendie des locaux Toutes
Coût
Délai
Qualité
Coffre-fort
ignifugé
2
Perte, vol ou
déterioration
d'un bien
Dommage
délibéré
Alarme non enclenchée Personnel
Intrusion d'un voleur
dans les locaux
Toutes
Coût
Délai
Qualité
Confidentialité
Sensibilisation
du personnel
3
Perte, vol ou
déterioration
d'un bien
Dommage
accidentel
Défaillance de
l'utilisateur
(chute du bien)
Utilisateur Toutes
Coût
Délai
Qualité
Assurance
Sauvegarde des
informations
4
Perte, vol ou
déterioration
d'un bien
Dommage
accidentel
Défaillance de
l'utilisateur
(effacement de donnée)
Utilisateur Toutes
Délai
Qualité
Sauvegarde des
informations
5
Perte, vol ou
déterioration
d'un bien
Dommage
accidentel
Défaillance du support
(panne)
Disque dur Toutes
Délai
Qualité
Sauvegarde des
informations
Maintenance
périodique

AMDE(C)
• Analyse des Modes de Défaillance, de leurs Effets (et de
leur Criticité)
• Méthode inductive
• Analyse des défaillances simples uniquement
• Les combinaisons de défaillances font l’objet d’analyses
séparées
54

Tableau d’AMDE(C)
• 1) Identifiant unique du scenario
• 2) Bien analysé
• 3) Mode de défaillance
• 4) Cause du mode de défaillance
• 5) Conséquence au niveau analysé du projet
• 6) Conséquence au niveau « suivant » du projet ou sur l’organisation
(ex. événement redouté)
• 7) Gravité / Vraisemblance / Criticité
• 8) Barrières de sûreté existantes
• 9) Conséquence en tenant compte des barrières
• 10) Gravité / Vraisemblance / Criticité en tenant compte des barrières
• 11) Exigences pour la réduction du risque
• 12) Remarques ou commentaires éventuels concernant le scenario ou la méthodologie
55
N°
Entité /
Fonction
Mode de
défaillance
Cause de la
défaillance
Effet local Effet global G V C
Traitement
du risque
Effet résiduel G' V' C'
Exigences de
sûreté
Remarques /
Commentaires
1 2 3 4 5 6 7 7 7 8 9 10 10 10 11 12

Exemple d’AMDEC
56
N° Entité / Fonction Phase
Mode de
défaillance
Cause de la
défaillance
Effet local Effet global G
Traitement
du risque
Effet résiduel G' Exigences de sûreté
Remarques /
Commentaires
1 2 3 4 5 6 7 8 9 10 11 12
1
F31 Tester
l'application sur
hôte (à partir de
sa spécification)
Validation
Spécification
non accessible
Retard de fin de
phase de
spécification
Retard de
démarrage
de phase de
validation
Délai
Réunions
périodiques
client
2
F31 Tester
l'application sur
hôte (à partir de
sa spécification)
Validation
Accès non
autorisé à la
spécification
Accès au
répertoire
projet non
protégé
Confidentia
lité
Gestion des
accès
3
F31 Tester
l'application sur
hôte (à partir de
sa spécification)
Validation
Accès non
autorisé à la
spécification
Divulgation
Confidentia
lité
Rappel des
exigences de
confidentialité
lors de la revue
de lancement de
projet interne
4
F31 Tester
l'application sur
hôte (à partir de
sa spécification)
Validation
Authenticité de
la spécification
Entrant
incorrectement
identifié
Erreur
fonctionnelle
dans la
réalisation
des tests
Coût
Délai
Qualité
Procédure de
gestion
documentaire
(identifiant
unique, version)
Identification
des entrants en
revue de
lancement de
phase
5
F31 Tester
l'application sur
hôte (à partir de
sa spécification)
Validation
Spécification
insuffisante
Externe
(client)
Difficultés de
réalisation
des tests
Délai
Qualité
Condition
d'acceptation
des entrants à
préciser en
revue de
lancement
projet
7
F31 Tester
l'application sur
hôte (à partir de
sa spécification)
Validation
Spécification
corrompue
Effacement de
donnée
(erreur
humaine)
Erreur
fonctionnelle
dans la
réalisation
des tests
Coût
Délai
Qualité
Intégrité
Protection de
l'intégrité des
entrants
8
F31 Tester
l'application sur
hôte (à partir de
sa spécification)
Validation
Spécification
instable
Externe
(client)
Evolution du
périmètre
des activités
Coût
Délai
Qualité
Procédure de
gestion des
évolutions
Entrant non figé au
démarrage de la
phase

57
Analyse du risque
Communication du risque

58
Analyse du risque
Surveillance/Réexamen du risque
Eninterne
≠
Enexterne
Etreréactifetsouple
(ex.:Nepasattendre
itérationsuivante)

ANNEXES
59

Bibliographie
• Lupfer, Anne – Gestion des risques en sécurité de
l’information – Mise en œuvre de la norme ISO 27005 –
Eyrolles – 2010
• Méthode EBIOS (Expression des Besoins et
Identification des Objectifs de Sécurité) – ANSSI
• Méthodologie
• Base de connaissances
• Etude de cas
60

Normes
• ISO Guide 73 – Management du risque – Vocabulaire –
2009
• ISO 31000 – Management du risque – Principes et lignes
directrices – 2009
• ISO 31010 – Management du risque – Techniques
d’évaluation des risques – 2009
• ISO/IEC 60812 – Techniques d’analyses de la fiabilité du
système – Procédure d’analyse des modes de défaillance
et de leurs effets (AMDE) – 2006
• ISO/IEC 61882 – Etudes de danger et d’exploitabilité
(HAZOP) – 2001
61

CONDITIONS DE LICENCE ET
DROITS D’UTILISATION
Licence
Crédits images
62

Licence
• Cette œuvre de CleodIT est mise à disposition selon les
termes de la licenceCreative Commons Attribution – Pas
d’Utilisation Commerciale – Partage dans les Mêmes
Conditions 3.0 France
63

Crédit images
• Les images contenues en page 3 de cette présentation sont
la propriété de Christian F. Burprich
• Ces images sont proposées sous licence Creative
Commons CC BY-NC-SA 3.0
• Les images originales ont été colorisées
64

Crédit images Clip Art
• Les images Clip Art contenues dans cette présentation sont la propriété de
Microsoft Corporation
• Vous pouvez copier et utiliser ces éléments multimédias dans vos projets et
documents
• Vous n’êtes pas autorisé à
• vendre, concéder sous licence ou distribuer des copies des éléments multimédias en tant
que tels ou en tant que produit si la valeur principale du produit est constituée par les
éléments multimédias
• concéder à vos clients des droits les autorisant à concéder sous licence ou distribuer les
éléments multimédias
• concéder sous licence ou distribuer à des fins commerciales des éléments multimédias
incluant des représentations d’individus, de gouvernements, de logos, de marques
commerciales ou d’emblèmes, ou utiliser ces types d’images d’une façon impliquant la
promotion ou l’association à votre produit, entité ou activité
• Ou créer des oeuvres obscènes ou diffamatoires à l’aide des éléments multimédias
• Pour plus d’informations, visitez le site www.microsoft.com/permission (en
anglais)
65

Identifier les risques

Contenu connexe

Tendances

En vedette

Similaire à Identifier les risques

Identifier les risques