Gestion d'incidents pour développeurs

Gestion d’incidents…

pour développeurs

Par

François Harvey, CISM/CISSP

Professionnel en sécurité de l’information

Gestion medsécure

http://medsecure.ca/

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é


8

POURQUOI LA GESTION D’INCIDENTS? (suite)

• Minimiser

– L’impact : Disponibilité/Intégrité/Confidentialité

– La gravité

• Sur

– Les données

– Les ressources

– L’organisation


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é


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


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!


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


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!


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 »


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


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


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


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


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

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

http://francoisharvey.ca/


« 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


Gestion d'incidents pour développeurs

Technology

Transcript of Gestion d'incidents pour développeurs