Pour nombre de ces, il n’existe aucune solution technique pour éliminer ce risque. Et ils ont raison : la solution ne peut être uniquement technique. Elle est également d’ordre méthodologique et humain.

APT : trois lettres qui donnent des sueurs froides à nombre de RSSI. APT, pour Advanced Persistent Threath, qualifie ces menaces, particulièrement furtives, qui s’immiscent sur les réseaux d’entreprises pour exfiltrer informations confidentielles et autres données de valeur. Les RSSI ont pris la mesure du danger face aux attaques dont ils sont victimes, des attaques parfois médiatisées. Pour nombre de ces RSSI, il n’existe aucune solution technique pour éliminer ce risque. Et ils ont raison : la solution ne peut être UNIQUEMENT technique. Elle est également d’ordre méthodologique et humain.

Sur quels vecteurs peut-on agir pour minimiser le risque lié aux APT ?

Les APT exploitent souvent (trop souvent ?) des vulnérabilités connues. Des patchs permettent, certes, de pallier ces vulnérabilités, mais force est de constater qu’ils ne sont pas toujours déployés. Les cyber-délinquants le savent et continuent à mener leurs attaques en exploitant ces vieilles vulnérabilités.

Parallèlement, au cœur des infrastructures actuelles, il y a un cruel déficit de visibilité sur les événements de sécurité. Pourtant, cette visibilité est impérative pour circonscrire ces menaces de nouvelle génération et mener des actions de remédiation en amont, alors que les impacts des APT sont encore mineurs. Par exemple, est-il normal qu’une pièce jointe qui a été transmise par email à un utilisateur tente d’ouvrir une connexion réseau avec un serveur externe à l’entreprise ? Les administrateurs sont-ils alertés lorsqu’un utilisateur clique sur cette pièce jointe suspecte ?

Les organisations peuvent agir en améliorant le déploiement des patchs de sécurité et en gagnant en visibilité sur des événements de sécurité qui affectent le système d’information. Mais sur le terrain, ces bonnes intentions ne sont pas toujours simples à mettre en œuvre.

Pourquoi les patchs ne sont-ils pas appliqués ?

Le rôle principal d’un administrateur système est d’assurer la continuité des environnements de production. Or, les patchs de sécurité ont parfois des conséquences disruptives sur les systèmes, ce qui est en porte à faux avec l’objectif initial de continuité. Le patching exige de réaliser des tests en amont du déploiement en production. La réalisation de ces tests est souvent fastidieuse et coûteuse, ce qui constitue un frein supplémentaire à leur mise en œuvre. 

Notons également que c’est principalement cette peur du changement qui incite les administrateurs à garder le plus longtemps possible en l’état leurs systèmes, jusqu’à risquer l’obsolescence et la fin de maintenance des produits par leurs éditeurs/constructeurs respectifs.

Quelles solutions pour réduire le risque des APT ?

En novembre 2011, l’OWASP, la communauté mondiale œuvrant à la sécurité des applications et des services Web, détaillait les «  best practices » en matière de Virtual Patching. Cette fonctionnalité mérite qu’on s’y attarde, d’autant qu’elle est proposée par quelques acteurs de la sécurité. Le principe est simplissime : lorsqu’une nouvelle vulnérabilité est identifiée, les équipes des éditeurs travaillent sur la réalisation d’un patch, déployé de manière transparente et qui acte une protection immédiate. Les administrateurs systèmes disposent ainsi de cette denrée rare pour planifier l’application du patch issu par l’éditeur : du temps ! C’est tout l’intérêt du Virtual Patching. Les patchs fournis par les éditeurs sont alors testés de manière sereine, tandis que les systèmes ou applicatifs sont protégés, même s’ils ne sont plus sous maintenance. Au final, cette fenêtre de risque entre l’identification d’une vulnérabilité et le déploiement du patch est jugulée, ce qui minimise le risque d’attaques de type Zero-Day, souvent utilisées par les APT. 

En ce qui concerne la visibilité sur les événements de sécurité, des solutions techniques existent. Elles analysent le comportement des fichiers qui transitent sur le réseau. Ces fichiers sont exécutés au sein d’une sandbox, pour identifier un comportement suspect (ouverture de connexion, TCP, modification de certains fichiers ou de clés de registre…). Le cas échéant, une alerte est émise. C’est la principale valeur ajoutée de ces solutions, qui alertent au plus tôt, pour ne pas dire en temps réel, les administrateurs.

Mais revenons à la question qui fâche et qui fait écho à l’introduction de cet article: si les solutions techniques existent, pourquoi les attaques APT perdurent-elles ? Il s’agit, dans un premier temps, d’un problème de méthodologie. Combien d’entreprises disposent d’une méthodologie formalisée qui définit, par écrit, les différentes étapes de la prise en charge des vulnérabilités ?! Car, avec les APT, il n’est plus possible de se contenter de réaliser des audits et tests de pénétration qui sont rarement suivis de mesures concrètes pour remédier aux vulnérabilités détectées. Corollaire de ce premier point, quelle est la réactivité des administrateurs lorsqu’ils sont notifiés d’un risque de sécurité ?

Ces deux interrogations illustrent le dilemme qui affecte notre métier de la sécurité. Oui, les technologies existent, mais nous, en tant qu’éditeur de solution de sécurité, ne pouvons réussir que si nos clients apportent les briques méthodologiques et humaines qui sont essentielles pour maîtriser les APT, et, au-delà, les risques de sécurité.

La question reste ouverte. Mais sur le terrain, je reste positif : je rencontre de plus en plus d’entreprises qui gagnent en maturité et réussissent ce grand écart entre technique, méthodologie et humain.