Gestion d'incidents pour développeurs

2 420 vues

Publié le

Présentation sur la gestion d'incidents présentée à confoo 2010.

Publié dans : Technologie, Business
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 420
Sur SlideShare
0
Issues des intégrations
0
Intégrations
17
Actions
Partages
0
Téléchargements
44
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Gestion d'incidents pour développeurs

  1. 1. Gestion d’incidents… pour développeurs Par François Harvey, CISM/CISSP Professionnel en sécurité de l’information Gestion medsécure
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. GESTION D’INCIDENTS PROCESSUS DE GESTION D’INCIDENTS • Préparation • Identification • Classification • Analyse • Réaction • Post-mortem 12
  13. 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. 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. 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. 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. 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. 18. GESTION D’INCIDENTS :: PRÉPARATION :: JOURNALISATION « CECI EST UN ÉVÉNEMENT » Date Source Action Attaquant 18
  19. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×