3. Carine Pascal, CleodIT
Avril 2013www.cleodit.fr
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
4. 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
Avril 2013www.cleodit.fr
4
5. PLAN DE FORMATION
On ne fait pas de projet sans risque
Le plus grand risque est de ne pas faire de projet
Avril 2013www.cleodit.fr
5
6. Plan de formation (1/6)
Avril 2013www.cleodit.fr
6
Projet informatique
Vocabulaire
7. Plan de formation (2/6)
Avril 2013www.cleodit.fr
7
Risque
Vocabulaire
8. Plan de formation (3/6)
Avril 2013www.cleodit.fr
8
PLAN DO
CHECKACT
Processus
d’identification du risque
9. Avril 2013www.cleodit.fr
9
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6
PLAN DO
CHECKACT
Plan de formation (4/6)
Identifier le risque d’un projet informatique tout au long de son cycle de vie
11. Plan de formation (6/6)
Avril 2013www.cleodit.fr
11
Bilan de formation
12. 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
Avril 2013www.cleodit.fr
12
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
Référence : Association Française d’Ingénierie Système
Exemple : une norme, un cahier des charges
Avril 2013www.cleodit.fr
13
14. 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
Avril 2013www.cleodit.fr
14
Besoin ≠ Moyen
Explicite ou Implicite
16. Caractérisation
Avril 2013www.cleodit.fr
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
17. 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.
Avril 2013www.cleodit.fr
17
MOA MOE
Sous-
traitant
19. 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
• …
Avril 2013www.cleodit.fr
19
20. 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
• …
Avril 2013www.cleodit.fr
20
22. 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)…
Avril 2013www.cleodit.fr
22
Traduction du besoin
« Matérialisation » des
biens primordiaux
23. Phases du cycle de vie
Avril 2013www.cleodit.fr
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
24. Phases – Redécoupage (Cycle en V)
Avril 2013www.cleodit.fr
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
25. 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
Avril 2013www.cleodit.fr
25
26. Défaillance
• Défaillance : cessation de l’aptitude d’un bien à satisfaire
une fonction requise
Avril 2013www.cleodit.fr
26
27. 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
Avril 2013www.cleodit.fr
27
matérielle
28. Risque
• Risque : Possibilité qu’une défaillance d’un bien
conduise à un événement redouté
Avril 2013www.cleodit.fr
28
29. 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
Avril 2013www.cleodit.fr
29
30. 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
Avril 2013www.cleodit.fr
30
31. Avril 2013www.cleodit.fr
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
32. Etablissement du contexte
• 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…
Avril 2013www.cleodit.fr
32
33. Etablissement du contexte
• 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…
Avril 2013www.cleodit.fr
33
Processus itératif
34. Identification du risque
• Identification du risque : processus de recherche, de
reconnaissance et de description du risque
Avril 2013www.cleodit.fr
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
35. 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
Avril 2013www.cleodit.fr
35
37. Analyse fonctionnelle
• Analyse fonctionnelle externe
• Exemple : Méthode MISME
• Analyse fonctionnelle interne
• Exemple : Méthode SADT
Avril 2013www.cleodit.fr
37
38. Exemple d’AF externe
Avril 2013www.cleodit.fr
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
39. 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
Avril 2013www.cleodit.fr
39
B1 B2 B3 B4
F1 F11 X
F12 X
F13 F131 X
F132 X
…
40. Exemple de tableau d’AF
Avril 2013www.cleodit.fr
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
…
41. 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
Avril 2013www.cleodit.fr
41
A adapter
(préciser / ajouter /
supprimer)
42. Nature de l’ER
• Naturelle (incendie, inondation)
• Délibérée (vol…)
• Accidentelle (effacement de données…)
Avril 2013www.cleodit.fr
42
43. Identification
des barrières existantes
Avril 2013www.cleodit.fr
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 ?
44. 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
Avril 2013www.cleodit.fr
44
45. 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
Avril 2013www.cleodit.fr
45
46. 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
Avril 2013www.cleodit.fr
46
Non Plus Moins
Aussi bien
que
Une partie
de
Inverse Autre que Tôt/avant Tard/après
47. Détermination HAZOP
des modes de défaillance
Avril 2013www.cleodit.fr
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é
…
48. 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é
Avril 2013www.cleodit.fr
48
Légende :
Fonctionnement attendu
Fonctionnement observé
49. 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
Avril 2013www.cleodit.fr
49
50. Construction des scenarios
Avril 2013www.cleodit.fr
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
51. 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
Avril 2013www.cleodit.fr
51
52. 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
Avril 2013www.cleodit.fr
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
53. Exemple d’APR
Avril 2013www.cleodit.fr
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
54. 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
Avril 2013www.cleodit.fr
54
55. 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
Avril 2013www.cleodit.fr
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
56. Exemple d’AMDEC
Avril 2013www.cleodit.fr
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. Avril 2013www.cleodit.fr
57
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
Communication du risque
58. Avril 2013www.cleodit.fr
58
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
Surveillance/Réexamen du risque
Eninterne
≠
Enexterne
Etreréactifetsouple
(ex.:Nepasattendre
itérationsuivante)
60. 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
Avril 2013www.cleodit.fr
60
61. 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
Avril 2013www.cleodit.fr
61
62. CONDITIONS DE LICENCE ET
DROITS D’UTILISATION
Licence
Crédits images
Avril 2013www.cleodit.fr
62
63. 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
Avril 2013www.cleodit.fr
63
64. 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
Avril 2013www.cleodit.fr
64
65. 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)
Avril 2013www.cleodit.fr
65