La conférence de François Harvey porte sur la gestion d'incidents informatiques, soulignant l'importance de la journalisation dans le processus. Il aborde les étapes de préparation, identification, classification, analyse et réaction face aux incidents, ainsi que la nécessité d'une publication responsable des vulnérabilités. Il conclut en insistant sur l'importance d'implanter une journalisation solide et d'améliorer les processus de gestion d'incidents.

1. Gestion d’incidents…
pour développeurs
Par
François Harvey, CISM/CISSP
Professionnel en sécurité de l’information
Gestion medsécure

2. INTRODUCTION
OBJECTIF DE LA CONFÉRENCE
• Vous initier à la gestion d’incidents
• Définir le rôle et le fonctionnement de
la journalisation dans le processus
2

3. INTRODUCTION :: FRANCOIS HARVEY
À PROPOS
• Professionnel en sécurité chez Gestion
medsécure
– Domaine de la santé
– Audit de sécurité applicative
– Architectures de sécurité de logiciels
– Gestion d’incidents
3

4. INTRODUCTION :: FRANCOIS HARVEY
À PROPOS (suite)
• J’ai contourné la sécurité de plus de logiciels
que vous allez en programmer toute votre
vie…
• Ce n’est que mathématique… développer
un logiciel peut nécessiter plusieurs années…
• Et quelques minutes pour qu’il se fasse
attaquer…
4

5. INTRODUCTION
POURQUOI CETTE CONFÉRENCE
• Il devient de plus en plus difficile pour les
professionnels en sécurité de suivre les
développements de logiciels
• Les développeurs vont de plus en plus vers
l’intégration où les aspects journalisation et
incidents ne sont pas traités
5

6. INTRODUCTION
<TRANCHE DE VIE >
Commentaire d’un programmeur lors de la
présentation d’un rapport d’audit..
– « Oui…. Mais vous avez triché pour
entrer dans l’application, ça ne
respecte pas les « use cases » de l’accès
utilisateur »
6

7. GESTION D’INCIDENTS
DÉFINITION D’INCIDENTS
« Tout événement qui ne fait pas partie du
fonctionnement standard d’un service et qui
cause, ou peut causer, une interruption ou une
diminution de la qualité de ce service » (ITIL)
« Événement lié à la sécurité informatique, qui
implique une violation de la politique de
sécurité du système d’information » (RFC 2828)
7

8. GESTION D’INCIDENTS
POURQUOI LA GESTION D’INCIDENTS?
• Vos logiciels seront attaqués
– Audit de sécurité volontaire (Interne ou
Externe)
– Découverte par une tierce partie
• Publication responsable
• Full-disclosure (publique)
– Attaque contre votre logiciel
– Client qui utilise votre logiciel et qui a été
• Audité (Interne ou Externe)
• Attaqué
8

9. GESTION D’INCIDENTS
POURQUOI LA GESTION D’INCIDENTS? (suite)
• Minimiser
– L’impact :
Disponibilité/Intégrité/Confidentialité
– La gravité
• Sur
– Les données
– Les ressources
– L’organisation
9

10. GESTION D’INCIDENTS
POURQUOI LA GESTION D’INCIDENTS? (suite)
• En développement, un incident est très
souvent relié à une vulnérabilité technique ou
logique
• Un incident peut être perçu comme une
exploitation pratique ou théorique d’une
vulnérabilité
10

11. PUBLICATION DE VULNÉRABILITÉ
PUBLICATION RESPONSABLE VS FULL-DISCLOSURE
• Publication responsable
– Le fournisseur est avisé de façon privée
et le chercheur ne publie rien avant le
correctif
• Full-Disclosure
– La vulnérabilité (et la preuve de
concept associée) est publiée sur
Internet sans que le fournisseur soit avisé
11

12. GESTION D’INCIDENTS
PROCESSUS DE GESTION D’INCIDENTS
• Préparation
• Identification
• Classification
• Analyse
• Réaction
• Post-mortem
12

13. GESTION D’INCIDENTS :: PRÉPARATION
AVOIR UN PLAN
– Gestion de crise
– Avoir une équipe désignée (~CERT)
– Support exécutif
– Processus d’analyse
– Mesure de mitigation
– Remise en service
– Escalade (hiérarchique ou fonctionnelle)
13

14. GESTION D’INCIDENTS :: PRÉPARATION
AVOIR UN POINT DE CONTACT UNIQUE
– Page explicative des procédures de
contact
– Courriel (securite@)
– Tenir une liste des vulnérabilités passées et
des correctifs requis
– SI VOUS CONTACTER EST TROP COMPLIQUÉ
ALORS LA VULNÉRABILITÉ OU INCIDENT NE
VOUS SERONT PAS COMMUNIQUÉS!
14

15. GESTION D’INCIDENTS :: PRÉPARATION
GESTION DE CODES SOURCE
– Les changements doivent être répertoriés
– Tenir une liste des versions de codes source
tiers (librairie) et appliquer une veille sur leurs
mises à jour
– Intégrer la sécurité dans les processus de
packaging
– Développer des processus clairs de
publication de correctifs
15

16. GESTION D’INCIDENTS :: PRÉPARATION
INTÉGRER UNE JOURNALISATION COHÉRENTE
– Votre infrastructure de journalisation doit
considérer votre application comme étant
hostile*!
– Ajout mais pas de suppression/modification
– Consultation en lecture seule
– Toujours bien penser à encoder
correctement les caractères (rien de pire
qu’un XSS dans un visualiseur de log)
* Vraiment très hostile!
16

17. GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
« UN ÉVÉNEMENT DOIT »
– Être intègre
– Être horodaté… incluant le fuseau horaire!
– Permettre d’identifier la source
• Adresse IP
• Nom d’utilisateur
– Permettre d’identifier l’action (ou l’attaque)
– Permettre de relier l’attaque à la source
17

18. GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
« CECI EST UN ÉVÉNEMENT »
Date Source
Action
Attaquant
18

19. GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
« LA COUCHE INFÉRIEURE JOURNALISE… »
– Les applications ont de plus en plus de
couches :
Gestion de charge  Présentation Application
 Base de données  Infrastructure
– Le serveur Web
•N’enregistre pas les cookies ni les paramètres
POST
– La détection d’intrusion réseau
•Ne journalise que ce qu’elle détecte
•Ne détecte pas les attaques sous SSL ou les
vulnérabilités logiques
19

20. GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
<tranche de vie> QUOI NE PAS FAIRE
Listes des tables d’une application
– Security_Groups
– Security_Logs
– Security_Users
L’application en question était
exploitable via le SQL injection…
20

21. GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
FORMAT DE JOURNAUX
• Pour les traces réseaux
– Privilégier le format PCAP
• Pour les traces de sécurité
– Fichiers plats balisés (compatibles syslog)
– Format IDMEF (Prelude – IDS)
• Pour toutes les autres fonctions
– Fichiers plats balisés (compatibles syslog)
21

22. GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
AVANTAGE DES FICHIERS PLATS
– Utilisation d’outils de manipulation de texte
(grep, awk, cut, sort, emacs (ou même vi))
– Signature ou hash (GPG ou MD5/SHA)
– Compressible (gzip)
– Facilité d’import/export (nc, syslog)
– Intégration des droits du FS (Append Only,
RO/RW, etc.)
– Rotation facile en fonction des
grosseurs/dates
22

23. GESTION D’INCIDENTS :: PRÉPARATION
AUDITER SOUVENT ET TESTER VOS PROCÉDURES
– Auditer à l’interne
– Auditer à l’externe
– Pour les vulnérabilités identifiées : Appliquer
les processus requis (Publier un avis public et
le correctif associé)
23

24. GESTION D’INCIDENTS :: IDENTIFICATION
IDENTIFICATION DE LA SOURCE
– D’où provient l’incident
– Utilisateur interne, externe ou anonyme
– Catégorie de vulnérabilité
– Niveau de la vulnérabilité
24

25. GESTION D’INCIDENTS :: CLASSIFICATION
DÉTERMINER LA CIBLE ET LA PORTÉE
• Déterminer la portée de l’attaque et
ses impacts sur votre entreprise et sur
les données
– Confidentialité
– Intégrité
– Disponibilité
25

26. GESTION D’INCIDENTS :: CLASSIFICATION
CALCUL DU RISQUE
Risque = f(Impact, Vulnérabilité et Menace)
– Impact : Gravité de la vulnérabilité
– Vulnérabilité : Niveau de faiblesse du système et
facilité d’exploitation
– Menace : Possibilité pour les attaquants
d’exploiter la vulnérabilité
• Il existe des méthodes de calcul du risque plus avancées,
par exemple « CVSS *»
*http://www.first.org/cvss/cvss-guide.html
26

27. GESTION D’INCIDENTS :: ANALYSE
ANALYSER
La vulnérabilité a été identifiée et son impact est
connu…
–Corriger la vulnérabilité
–Trouver des mesures de mitigation possibles
–Auditer et corriger les vulnérabilité similaires
–Documenter les traces journalisées par
l’exploitation
27

28. GESTION D’INCIDENTS :: RÉACTION
RÉACTION
• Escalader et avertir :
– L’utilisateur
– Le groupe d’utilisateurs
– Le CERT
• Publication du correctif
• Incrémenter la version du produit
• Assister vos utilisateurs en cas d’attaques
28

29. GESTION D’INCIDENTS :: AUTOPSIE
AUTOPSIE (POST-MORTEM)
• La méthode « 5 Pourquoi »
• Déterminer les lacunes ayant conduit à cet incident et corriger la
source.
– Intégrer cet incident ou vulnérabilité dans les futurs « use
cases » des développeurs pour y inclure des validations
ou des tests
29

30. CONCLUSION
CONCLUSION
• Si vous ne devez que vous rappeler de
trois choses :
– Implanter une journalisation solide
– Être transparent et communiquer
– Définir et rehausser vos processus de
gestion d’incidents
30

31. CONCLUSION
GARDEZ LE CONTACT!
• Email:
– Contact at francoisharvey dot ca
– Francois.harvey at medsecure dot ca
• Twitter: @FrancoisHarvey
• Web :
– http://francoisharvey.ca
– http://medsecure.ca
31

32. A PROPOS DE L’ENTREPRISE
« Gestion medsécure se spécialise
dans la sécurité, le développement
et l’architecture des systèmes
d’informations relié aux domaines
cliniques et hospitaliés. »
http://medsecure.ca