Organiser sa LID, lutte informatique défensive, reste un exercice complexe tant en termes techniques qu'en termes d'organisation.
Quels sont les outils de la défense contre les agressions informatiques ? On peut penser, par exemple, et sans prétention d'exhaustivité à : Firewall, antivirus, sondes de prévention d'intrusion, filtrages divers et variés, corrélation des logs....
Cependant, pour la pertinence du propos, je retiendrai une différence, contestable évidemment entre Sécurité des SI et "défense informatique" ou LID. Pour moi, la SSI est un phénomène continuel d'amélioration de la sécurité des SI, sécurité que l'on comprend au travers du trigramme DIC pour Disponibilité, Intégrité et Confidentialité.
En revanche, la Lutte Informatique Défensive relèvera ici des actions, réactions, outils et processus permettant de gérer les évènements de sécurité informatique et plus particulièrement les crises, les problèmes, les attaques....
Pourquoi cette distinction ?
Tout d'abord, il est vrai que je lui trouve une certaine pertinence et ce, de façon tout à fait personnelle. Plus simplement, elle est aussi contenue dans le titre d'un récent RFC, le RFC 6045 intitulé Real-time Inter-network Defense. Ce post est ainsi basé sur une analyse par un spécialiste des RFC qui nous en donne les grandes lignes.
Un RFC, pour "Request For Comments" est un standard publié par l'IETF, principale organisme de standardisation de la Gouvernance Internet. On lui doit de nombreuses normalisations de protocoles et solutions au sein desquels la sécurité est souvent bien prise en compte.
Une des problématiques au cœur de la sécurité, et de la défense informatique, repose notamment sur les capacités d'interaction entre les acteurs concernés. Par exemple, en cas d'attaques par déni de service, il faut pouvoir réagir rapidement auprès de son hébergeur ou son opérateur pour mettre en place des mesures permettant d'atténuer l'effet du déni de service (par exemple, diriger le trafic vers "nul part").
Coordonner ses réactions demande donc un échange d'informations le plus efficace et structuré possible. C'est alors ici que l'on se place sur un terrain de réaction et donc, pour moi, de LID et c'est là que ce RFC intervient.
Ce RFC créé ainsi un nouveau format de message et de requêtes adressés automatiquement aux différents acteurs impliqués dans une attaque informatique. Une série d'échanges RID sera donc capable d'alerter les acteurs, de demander des interventions et de suivre, en temps réel, les actions réalisées pour mettre fin à l'attaque. Destiné à faciliter les échanges, le protocole présent donc à la fois un fort taux de standardisation (format XML) mais également de larges capacités de transmission de l'information (on peut transmettre un paquet litigieux dans son ensemble).
Destiné à être relativement automatisé, RID peut réagir visiblement à la fois à une détection humais comme automatique. Le RFC le positionne ainsi au sein des organes (techniques) de gestion des réseaux et des solutions de gestions des incidents. On dénombre ainsi 6 requêtes RID distinctes :
- Requête de recherche d'une source de l'incident auprès d'un opérateur : on émet ainsi plusieurs fois cette requête pour arriver à la source
- Requête d'investigation si la source est identifiée
- Un envoi d'informations sans requête associée
- Une requête sur les détails d'une attaque connue mais pas forcément subie (pour tenter de la prévenir au cas où on serait victime une vulnérabilité identique)
- Deux requêtes permettant de transmettre les résultats intermédiaires ou finaux.
Bien évidemment, la sensibilité de tels échanges supposent des solutions de communications sécurisées (authentification mutuelle, chiffrement...).
L'intérêt de RID porte sur plusieurs points :
=> C’est un RFC donc un standard qui a été partagé par les acteurs du Net. Par exemple, celui-ci a été porté par un collaborateur de la société EMC, bien connu dans le monde de l'hébergement informatique. S'il est adopté largement comme c'est le cas de nombreux protocoles et sa "cible" finale, il fournira un cadre générique d'échange d'informations et de pratique de sécurité partagée. Il suppose cependant que les sociétés et organisations mettent la main à la pâte et l'acceptent et il peut donc également "tomber à l'eau".
=> C’est un protocole relativement technique adapté à la LID en tant que telle, ce qui reste tout de même assez rare et donc très intéressant.
=> c'est un protocole qui semble savoir dépasser la technique pour prendre en compte des pratiques de gestion de crise et d'attaque informatique, ce qui en fait quelque chose de grande valeur.
Librement inspiré de l'article produit par www.bortzmeyer.org, j'ai essayé de mettre en exergue les qualités et le contexte d'application d'une telle solution. Nul doute que de telles approches apportent beaucoup à la "cyberdéfense" et qu'elles pourront apporter beaucoup à ceux qui se préoccupent de lutte informatique.
Source :
http://www.bortzmeyer.org/6045.html
mardi 9 novembre 2010
Inscription à :
Publier les commentaires (Atom)
Aucun commentaire:
Enregistrer un commentaire