Management de la Sécurité des

Systèmes d’Information
(MgmtSSI)
doudou-sensei
Au-delà de l'attaque

(C) doudou-sensei 2
Au-delà de l'attaque

• Les attaques sont perpétrées par des menaces qui infligent des
dommages en exploitant des vulnérabilités qui sont contrôlées par
des contre-mesures.

(C) doudou-sensei 3
Menaces

• Un facteur qui peut causer des dommages aux biens

(C) doudou-sensei 4
Menaces
• Des personnes curieuses, des maladresses
involontaires
• Hackers motivés par les défis techniques
• Employés ou clients mécontents cherchant
à se venger
• Les criminels intéressés par un gain
financier personnel, le vol de services ou
l'espionnage industriel
• Le crime organisé avec l'intention de
cacher quelque chose ou de réaliser un
gain financier
• Les groupes terroristes organisés qui
tentent d'influencer la politique par des
attaques isolées
(C) doudou-sensei
• Les agents d'espionnage étrangers
cherchant à exploiter des informations à
des fins économiques, politiques ou
militaires
• Contre-mesures tactiques destinées à
perturber des armes ou des structures de
commandement spécifiques
• Guerre de l'information tactique à
multiples facettes appliquée de manière
largement orchestrée pour perturber une
mission militaire majeure
• Grands groupes organisés ou États-nations
visant à renverser un gouvernement
5
Dommage

• Conséquence négative pour un actif du système

(C) doudou-sensei 6
Dommage

• Actif ?
• Information (généralement)
• Matériel et logiciels (potentiellement)

• Types d'atteinte (aspects de la triade CIA)

• Atteinte à la confidentialité (p. ex., interception)
• Atteinte à l'intégrité (p. ex., modification, fabrication)
• Atteinte à la disponibilité (p. ex., interruption)

(C) doudou-sensei 7
Vulnérabilités

• Un aspect non intentionnel d'un système (conception, mise en œuvre

ou configuration) qui peut faire en sorte que le système fasse quelque
chose qu'il ne devrait pas faire ou échoue à faire quelque chose qu'il
devrait.

(C) doudou-sensei 8
Vulnérabilités

• Bases de donnees
• National Vulnerability Database (NVD) : https://nvd.nist.gov/
• Common Vulnerabilities and Exposures (CVE) : https://cve.mitre.org/
• GitHub Advisory Database : https://github.com/advisories

• Ignorer les vulnérabilités est risqué

• Le maillon le plus faible, c’est tout ce dont une menace a besoin !

(C) doudou-sensei 9
Confiance et fiabilité

• Un composant de confiance est supposé satisfaire une politique de

sécurité

• Un composant fiable est en outre accompagné d'une preuve qu'il

satisfait à la politique
• Objectif des praticiens de la sécurité : transformer la confiance en fiabilité

(C) doudou-sensei 10
Contre-mesures

• Une défense qui protège contre les attaques en neutralisant la

menace ou la vulnérabilité en question.

(C) doudou-sensei 11
Contre-mesures

• Stratégie :
• Prévenir : bloquer l'attaque ou neutraliser la vulnérabilité
• Dissuader : rendre l'attaque plus difficile mais pas impossible
• Dévier : rendre d'autres cibles plus attrayantes
• Atténuer : rendre le.s dommage.s moins grave.s
• Détecter : en temps réel ou après coup
• Récupérer : réparer les dommages

(C) doudou-sensei 12
Types de contre-mesures

• Physique : quelque chose de tangible (murs, serrures, gardes, etc.)

• Procédural : protocoles pour la façon dont les gens agissent (lois,

règlements, politiques, contrats, etc.)

• Technique : matériel et logiciels (cryptographie, contrôle d'accès,

mots de passe, systèmes de détection d'intrusion, etc.)

(C) doudou-sensei 13
Contre-mesures techniques

• Isolation : restreindre la communication entre les composants

(machines virtuelles, bacs à sable, processus, pare-feu, etc.)

• Surveillance : un programme analyse l'exécution et bloque les

mauvaises choses (moniteur de référence, système de détection
d'intrusion, etc.)

• Récupération : détecter et inverser les effets des dommages

(transactions, sauvegardes, changements de clé, etc.)

(C) doudou-sensei 14
Principes

(C) doudou-sensei 15
Approches de sécurité

• Prévention : concevoir des systèmes totalement exempts de

vulnérabilités

• Gestion des risques : investir judicieusement dans des contre-

mesures

• Dissuasion par la responsabilité : attribuer les attaques aux humains

et engager des poursuites judiciaires.

(C) doudou-sensei 16
Principes de la prévention
• Responsabilité
• Médiation complète
• Le moindre privilège
• Failsafe par défaut
• Séparation des privilèges
• Défense en profondeur
• Économie de mécanisme
• Conception ouverte (Open Design)
• Acceptabilité psychologique

(C) doudou-sensei 17
Responsabilité

• Tenir les utilisateurs responsables de leurs actes

(C) doudou-sensei 18
Responsabilité

• Autorisation : mécanismes qui déterminent si les actions sont

autorisées

• Authentification : mécanismes qui lient les commettants aux actions

• Audit : mécanismes qui enregistrent et examinent les actions

(C) doudou-sensei 19
Médiation complète

• Chaque opération demandée par un commettant doit être

interceptée et jugée acceptable selon la politique de sécurité.

(C) doudou-sensei 20
Médiation complète

• Le moniteur de références est la composante qui effectue

l'interception et la determination

• Liée à la responsabilité

• Limite la mise en cache des informations, y compris les décisions

antérieures

(C) doudou-sensei 21
Moindre privilege
Les utilisateurs doivent bénéficier des privilèges minimums nécessaires
à l'accomplissement de leurs tâches.

• Limite les dommages qui peuvent résulter d'un accident ou d’une

malveillance

(C) doudou-sensei 22
Failsafe par défaut

Fonder les décisions sur la présence d'un privilège et non sur l'absence
d'une interdiction.

• La réponse par défaut est "non"

• Ne dites "oui" que lorsqu'il y a une raison explicite de le faire
• Les utilisateurs qui découvrent qu'ils n'ont pas accès se plaindront
• Les attaquants qui découvrent qu'ils ont accès ne se se plaindront pas
!

(C) doudou-sensei 23
Séparation des privilèges

Des opérations différentes doivent nécessiter des privilèges différents.

• Supporte le principe du moindre privilège

• En tension avec la facilité d'utilisation : trop d'opérations, d'objets et
de principes.

(C) doudou-sensei 24
Défense en profondeur
Préférer un ensemble de mécanismes complémentaires à un seul
mécanisme.

• Complémentaire :
• Indépendants : une attaque qui compromet un mécanisme a peu de chances
de compromettre les autres
• Chevauchement : les attaques doivent compromettre plusieurs mécanismes
pour réussir

(C) doudou-sensei 25
Économie de mécanisme
Préférer des mécanismes plus simples et plus petits.

• Plus facile à comprendre, à construire, à analyser

• Et donc moins susceptibles de présenter des vulnérabilités inconnues

• S'applique à tous les aspects du système, pas seulement à la sécurité

• Base informatique de confiance (TCB) : mécanismes qui mettent en

œuvre la fonctionnalité de sécurité de base
• Limiter la taille de la TCB

(C) doudou-sensei 26
Open Design

La sécurité ne doit pas dépendre du secret de la conception ou de la

mise en œuvre.

• Arguments en faveur de la conception ouverte :

• Les secrets finissent par être dévoilés : la rétro-ingénierie est possible, les
employés peuvent changer de poste
• Rendre les détails publics augmente les chances d'identifier et de réparer les
vulnérabilités

(C) doudou-sensei 27
Open Design

La sécurité ne doit pas dépendre du secret de la conception ou de la

mise en œuvre.

• Arguments contre la conception ouverte :

• Le secret soutient la défense en profondeur en rendant plus difficile la
découverte des vulnérabilités
• Absence de preuves tangibles de la validité de la loi de Linus ("avec
suffisamment de yeux, tous les bogues sont superficiels")
• Après identification, certaines vulnérabilités ne peuvent pas être corrigées
rapidement ou facilement

(C) doudou-sensei 28
Acceptabilité psychologique
Réduire au minimum le fardeau des mécanismes de sécurité sur les humains.

• Ne pas rendre les opérations (beaucoup) plus difficiles à réaliser que si les
mécanismes de sécurité étaient absents

• Ne pas rendre la configuration difficile

• Produire des messages d'erreur compréhensibles

• Il faut toujours trouver un compromis entre sécurité et facilité

d'utilisation
(C) doudou-sensei 29
Méthodologie d'ingénierie

1. Exigences fonctionnelles
2. Analyse de la menace
3. Analyse du préjudice
4. Objectifs de sécurité
5. Analyse de faisabilité
6. Exigences de sécurité

(C) doudou-sensei 30
Exigences fonctionnelles
• Doit être testable – une tierce partie peut déterminer si les exigences
sont satisfaites
• User stories – brève description d'un seul type d'interaction que
l'utilisateur peut avoir avec le système
• En tant qu'utilisateur, je peux agir dans ce but
• Exemples de systèmes de gestion de cours
• En tant que professeur, je peux créer un nouveau devoir en spécifiant son
nom, le nombre de points possibles et la date d'échéance
• En tant qu'étudiant, je peux soumettre un fichier comme solution à un devoir
• Ces récits révèlent les actifs du système

(C) doudou-sensei 31
Analyse des menaces

• Identifier les menaces qui pèsent sur le système

• En particulier les menaces humaines malveillantes
• À quels types d'attaquants le système va-t-il résister ?
• Quelles sont leurs motivations, leurs ressources et leurs capacités ?

• Identifier les non-menaces

• Matériel fiable ?
• Environnement fiable ?
• Salle des machines physiquement sécurisée, dont l'accès est réservé aux
opérateurs de confiance du système.

(C) doudou-sensei 32
Analyse des dommages

• Dommage : l'action affecte négativement la valeur de l'actif

• Atteinte à : Confidentialité, Intégrité, Disponibilité

• "Effectuer une action sur/vers/avec un actif pourrait causer des

dommages"
• "Voler de l'argent pourrait entraîner une perte de revenus"
• "Effacer les soldes des comptes pourrait entraîner la perte de clients"

(C) doudou-sensei 33
Analyse des dommages

• <action, actif, dommage>

• <vols, argent, perte de revenus>
• <effacement, solde de compte, perte de client>

• Méthodologie
• Commencez par l'actif
• Faites un brainstorming : quelles actions pourraient nuire à cet actif ?
• Laissez-vous inspirer par la triade de la CIA

(C) doudou-sensei 34
Objectifs de sécurité
• "Le système doit empêcher/détecter une action sur/vers/avec un
actif."
• Précisez quoi et pas comment
• Exemples
• "Le système doit empêcher le vol d'argent"
• "Le système doit empêcher l'effacement des soldes des comptes"
• Mauvais objectifs
• "Le système doit utiliser le cryptage pour empêcher la lecture des messages"
• "Le système doit utiliser l'authentification pour vérifier les identités des
utilisateurs"
• "Le système doit résister aux attaques"

(C) doudou-sensei 35
Analyse de faisabilité

• Tous les objectifs ne sont pas réalisables

• Assouplir les objectifs
• "Empêcher le vol d'objets dans un coffre-fort"
• Trop difficile !
• "Résister à la pénétration pendant 30 minutes"
• Réalisable et testable
• "Détecter le vol d'objets dans une chambre forte"
• Réalisable et testable

(C) doudou-sensei 36
Objectifs -> Exigences

• Les objectifs : ce qui ne devrait jamais arriver dans n'importe quelle

situation
• Non testable

• Exigences : ce qui doit se produire dans des situations spécifiques

• Testable

(C) doudou-sensei 37
Exigences de sécurité
• Contrainte sur les exigences fonctionnelles, au service des objectifs de
sécurité
• Exemple
• Exigence fonctionnelle : permettre aux clients d'encaisser des chèques
• Objectif de sécurité : éviter les pertes de revenus dues à des chèques sans
provision.
• Exigence de sécurité :
• Le chèque doit être tiré sur la banque où il est encaissé (pour que les fonds puissent être
vérifiés) ou
• Le client doit être titulaire d'un compte dans la banque et y déposer des fonds (pour que
les fonds puissent être contre-passés).

(C) doudou-sensei 38
Exigences de sécurité
• Contrainte sur les exigences fonctionnelles, au service des objectifs de
sécurité
• Exemple
• Exigence fonctionnelle : permettre à deux utilisateurs de chatter en utilisant
la messagerie instantanée
• Objectif de sécurité : empêcher la divulgation du contenu des messages aux
autres utilisateurs
• Exigence de sécurité :
• (Mauvaise) Le contenu du message ne peut être lu par personne d'autre que les deux
utilisateurs
• (Meilleur) Le message est crypté par une clé partagée avec les deux utilisateurs
• Ne soyez pas trop précis dans les détails techniques ici

(C) doudou-sensei 39
Itération Inventer de
nouvelles
exigences
fonctionnelles

Inventer de
nouvelles Introduire un
exigences de nouvel actif
sécurité

Inventer de
nouveaux
objectifs de
sécurité

(C) doudou-sensei 40
THANKS

(C) doudou-sensei 41