Post on 14-Jun-2015
description
Gestion d’incidents…
pour développeurs
Par
François Harvey, CISM/CISSP
Professionnel en sécurité de l’information
Gestion medsécure
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
INTRODUCTION
2
À 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
INTRODUCTION :: FRANCOIS HARVEY
3
À 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…
INTRODUCTION :: FRANCOIS HARVEY
4
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
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
INTRODUCTION
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
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é
GESTION D’INCIDENTS
8
POURQUOI LA GESTION D’INCIDENTS? (suite)
• Minimiser
– L’impact : Disponibilité/Intégrité/Confidentialité
– La gravité
• Sur
– Les données
– Les ressources
– L’organisation
GESTION D’INCIDENTS
9
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é
GESTION D’INCIDENTS
10
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é
PUBLICATION DE VULNÉRABILITÉ
11
PROCESSUS DE GESTION D’INCIDENTS
• Préparation
• Identification
• Classification
• Analyse
• Réaction
• Post-mortem
GESTION D’INCIDENTS
12
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)
GESTION D’INCIDENTS :: PRÉPARATION
13
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!
GESTION D’INCIDENTS :: PRÉPARATION
14
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
GESTION D’INCIDENTS :: PRÉPARATION
15
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!
GESTION D’INCIDENTS :: PRÉPARATION
16
« 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
GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
17
« CECI EST UN ÉVÉNEMENT »
GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
18
Date Source
Action
Attaquant
« 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
GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
19
<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
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
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
GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION
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é)
GESTION D’INCIDENTS :: PRÉPARATION
23
IDENTIFICATION DE LA SOURCE
– D’où provient l’incident
– Utilisateur interne, externe ou anonyme
– Catégorie de vulnérabilité
– Niveau de la vulnérabilité
GESTION D’INCIDENTS :: IDENTIFICATION
24
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é
GESTION D’INCIDENTS :: CLASSIFICATION
25
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
GESTION D’INCIDENTS :: CLASSIFICATION
26
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
GESTION D’INCIDENTS :: ANALYSE
27
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
GESTION D’INCIDENTS :: RÉACTION
28
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
GESTION D’INCIDENTS :: AUTOPSIE
29
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
CONCLUSION
30
GARDEZ LE CONTACT!
• Email:
– Contact at francoisharvey dot ca
– Francois.harvey at medsecure dot ca
• Twitter: @FrancoisHarvey
• Web :
– http://francoisharvey.ca
– http://medsecure.ca
CONCLUSION
31
« 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
A PROPOS DE L’ENTREPRISE