Cliquez sur la couverture pour découvrir le sommaire et des extraits du magazine !
En savoir plus9,00 € TTC
APTe ou in-APT, face aux A.P.T. ? À vous de voir !
La mode des APT est bien implantée depuis maintenant quelques années et l’actualité sécu est rythmée par la publication des rapports de sociétés soucieuses de surfer sur le buzz des noms les plus improbables (vivement le rapport « tardigrade irradié » !).
Le nombre de ces rapports montre que, heureusement, les victimes commencent à découvrir ces attaques et parfois même à les rechercher. En France, la médiatisation de l’attaque de Bercy en mars 2011 a sûrement contribué à réveiller les esprits les plus endormis.
La réponse aux incidents est donc hype, utilisée commercialement pour se proclamer expert, capable de détecter, corriger et prévenir les attaques à grand renfort de « spectrométries sur équipements » ou autre « cyber intelligence » ! Mais au final, combien d’équipes sont déjà réellement intervenues sur des attaques de grande ampleur et donc aptes à fournir le service promis ? Car le forensics à l’ancienne a vécu et personne ne peut plus traiter l’incident seul à coups de dd et de grep. Aujourd’hui, l’APT ne peut être considérée que comme une crise où, nécessairement, la dimension humaine est cruciale. De plus, l’ensemble des domaines techniques de la SSI est concerné ; au-delà des OS traditionnels, tous les composants du SI : smartphones, IPBX, cœur de réseau, équipements industriels, etc. font partie du périmètre à analyser.
Bref, la situation est dramatique dans un monde qui se divise en deux catégories : ceux qui connaissent leur compromission et ceux qui doivent encore la découvrir. Or, celle-ci est encore vue comme l’étaient les poux : une maladie honteuse. Pourtant, seule la collaboration permettra de combattre l’épidémie et de réduire l’asymétrie entre attaquant et défenseur. Pour lutter efficacement, il est nécessaire de mettre en place un partage entre tous les acteurs sur les outils, les techniques d’attaques, les marqueurs, etc. Reste à voir d’où viendra le salut. Peut-être l’ANSSI donnera-t-elle (enfin !) l’impulsion du partage généralisé ? Ou faudra-t-il attendre un acteur privé de référence en Europe continentale, à l’instar de FireEye/Mandiant ou BAE/Detica ?
En attendant cette révolution, il faut jouer les pompiers et j’espère que ce numéro vous donnera non seulement un aperçu des difficultés auxquelles il faut faire face, mais également quelques idées à mettre en œuvre.
Raphaël Rigo
p. 04 Qu'est-ce qu'un incident de sécurité ?
p. 11 Aspects juridiques et légaux du traitement d'incident
p. 18 Analyse de malware à la rescousse du CSIRT : de la rétro-conception aux IOC
p. 25 Méthodologie d'analyse de vulnérabilités et production de signatures de détection
p. 33 Recherche d'indices de compromission sur iOS
p. 45 Quelle méthodologie pour une réponse à incident sur Android ?
p. 54 La citadelle est tombée ! Cybercrise, comment s'organiser ?
p. 61 Débusquer l'APT dans votre parc
p. 68 Introduction au traitement des logs et des flux réseau dans une réponse sur incident
p. 75 Contrôler la sécurité des objets de l’Active Directory avec BTA
Face à la transformation digitale de notre société et l’augmentation des cybermenaces, la cybersécurité doit être aujourd’hui une priorité pour bon nombre d’organisations. Après plus de 20 années de publications et de retours d’expérience, MISC apporte un vivier d’informations techniques incontournable pour mieux appréhender ce domaine. Précurseur sur ce terrain, MISC a été fondé dès 2002 et s’est peu à peu imposé dans la presse française comme la publication de référence technique en matière de sécurité informatique. Tous les deux mois, ses articles rédigés par des experts du milieu vous permettront de mieux cerner la complexité des systèmes d’information et les problèmes de sécurité qui l’accompagne.

Bienvenue dans ce numéro spécial dédié à la mise en place d’un intranet à l’aide de Red Hat Enterprise Linux (RHEL) ! Comme vous allez vite le voir, l’utilisation de la distribution au chapeau rouge ne change que peu de choses et tout ce que nous allons aborder dans ce dossier (ou presque) pourra être utilisé ou reproduit sur des distributions similaires, telles que CentOS ou encore simplement Fedora.
Nous allons ici documenter l’installation et la configuration de notre serveur RHEL à l’aide du fichier de configuration Ansible (que l’on nomme « playbook »). Afin de nous assurer que le lecteur dispose de tous les éléments nécessaires à la bonne compréhension du contenu de ce numéro spécial, nous allons donc commencer par un rapide tour d’horizon de cet outil.
Le précédent chapitre a présenté, de manière sommaire et limitée aux besoins de ce dossier, les fonctionnalités d’Ansible. Nous allons donc maintenant revenir au cas d’étude en tant que tel et continuer la configuration de notre serveur RHEL, en utilisant désormais un playbook Ansible.