J'ai lu deux papiers dernièrement qui traitent un thème commun. Le premier est l'édito de MISC septembre-octobre dans lequel un paragraphe a retenu mon attention: "Un peu de réflexion et de bon sens permettrait déjà de régler nombre de problèmes. Par exemple, au lieu de déployer des anti-virus, IDS/IPS, WAF et autres outils de filtrage qui n'arrêtent que le bruit ambiant d'Internet, peut-être qu'analyser et comprendre les 20-30 failles critiques qui sortent par an suffirait à déployer une défense ciblée, adaptée à ces risques ? Encore faut-il être capable d'identifier ces 20-30 failles ...". Le second est un article de blog de Carnal Ownage qui donne une piste de réflexion "We should stop trying so hard to stop the 80% of low sophistication attackers and focus on the 20% of attackers we really care about and who can really hurt us".
Le blog de Carnal0wnage est un peu plus disert que l'edito de MISC et donne des détails sur le contenu de ces pourcentages. Les 80% ont pour but des vols de numéros de sécu ou CB, de l'envoi de mail, de l'ajout de bandeaux publicitaires ou de defacer du site web. Leurs techniques sont des techniques massives, du scan au malware en utilisant des failles anciennes (appelées 1day). Le but des 20% est de voler de la propriété intellectuelle, d'obtenir des informations confidentielles afin de bénéficier d'une avance (législative, négociation, paris, etc..), pouvoir endommager des architectures physiques dans une optique de perte financière, décrédibiliser une entreprise et même de voler des codes sources afin de trouver des 0day ou de les modifier. Leurs techniques sont plus pointues et regroupent des 0day, du spear phishing, des APT, des AET (combo buzzword!), utilisent des certificats volées, implantent du malware dès la chaîne de construction et réussissent à exploiter les relations de confiance.
On observe effectivement une bonne dichotomie entre d'un côté des attaques de "masse" et de l'autre des attaques "ciblées". Apparemment, une bonne expérience[1] de la sécurité informatique permet d'éviter les scans massives et les 1days (finalement le trio infernal firewall/antivirus/IDS fonctionne un peu :) ) Attaques de masse => réponse standardisée. Pour ces 80%, normalement, pas de soucis, l'ANSSI vient même de créer un checkup à réaliser (ou pas).
Bien évidemment le problème est posé par les attaques ciblées. On sait très bien qu'un firewall ne bloque ni n'analyse un flux https sortant ou qu'un antivirus est aveugle devant un exploit préparé pour, qu'un social engineering efficace contourne beaucoup de protections. Alors, quelles solutions avons nous pour ces 20%? MISC conseille l'étude de ces failles pour en déduire une défense ciblée. Certes, mais laquelle, et en regard de quelle faille? CarnalOwnage propose une option offensive (?) ou une option d'augmentation des coûts pour l'attaquant (par des méthodes de SIEM semble t'il). Je reste dubitatif vis à vis de ces lignes de défense. L'offensif pourquoi pas, le mot cyberguerre commence à être employé de plus en plus souvent, mais contre quel ennemi? A l'opposé du champ de bataille ou l'ennemi est connu puisqu'en en face, qui attaquer lorsque l'ennemi est invisible? Tabler sur la peur? Je n'y crois pas. Les SIEM (ou assimilé) pour faire augmenter le coût de la réussite de l'attaque? Est-ce possible d'estimer le coût qu'espère tirer l'attaquant de son action?
L'informatique et le réseau permet de relier des systèmes et des personnes afin qu'ils communiquent entre eux. Les attaquants tirent partie de ces personnes et communications. La sécurité veut empêcher tout ou partie de ces communications. Equation impossible?
[1] ou hygiène? :)
Salut Kevin, très bonnes questions que tu poses là.
RépondreSupprimerLes 80/20 décrits sont une évidence pour celui qui travaille en sécurité mais pas pour les "décideurs". Cela dit, il faudrait aussi avoir un chiffre sur les pertes représentées ? Est-ce 80/20, 98/2, 50/50 ?
Pour ce qui est de la protection contre le 20% d'attaques les plus ciblées, quelques propositions.
- Virus ciblés : analyses heuristiques + "bacs à sables" pour l'exécution des programmes qui ne sont pas en liste blanche.
- HTTPS : déchiffrement et inspection à la volée par une autorité de confiance.
- Social engineering : ségrégation des droits d'administrateurs + double validation nécessaire pour les accès critiques.
De manière générale, je pense que les concepts de liste noire, liste blanche et liste grise devront être étendus à des concepts plus vastes en sécurité (pas seulement spam et surf web). Exemple: signature des exécutables, signature des paquets réseau...
Sur le https, vu les alertes certificats dès qu'on n'utilise pas l'OS et le navigateur corporate... Je pense que c'est assez fréquent.
SupprimerMaintenant, il faut aussi être préparé au possible tsunami résultant d'une compromission exposant les logs du proxy trop curieux, exposant (au mieux, pour l'entreprise au moins!) beaucoup de données bancaires en clair de tous ces employés faisant leurs achats en ligne pendant leurs pauses...
@Christophe: Comment estimer les pertes? C'est une bonne question. La première étant de savoir si l'on fait partie de ces gens visés par ces attaques sophistiquées...
RépondreSupprimerPour les virus vraiment ciblés, je pense que les concepteurs font ce qu'il faut pour ne pas être détectés par les bacs à sable et autre.
Le https est censé assurer un chiffrement de bout en bout. Si on le casse, est-ce encore du https? Ensuite, on sait très bien que sortir d'un réseau protégé est toujours possible. Je proposais de couper la route par défaut http://exploitability.blogspot.fr/2010/05/route-del-default-gw-ou-et-si-on.html
Contre le social Engineering, mettre une double valid, pourquoi pas, mais à part pour des opérations critiques, cela impacte beaucoup trop la productivité générale... La sécurité n'est acceptée que lorsqu'elle est pragmatique et invisible. Son ressenti est toujours négatif et elle finit toujours par être bypassée.
@Kevin : Merci pour la réponse. En fait, le terme de bac à sable est impropre, je pensais à une zone d'exécution pour laquelle les fichiers réels ne seraient pas accessibles à l'exécutable, sauf décision exceptionnelle de l'utilisateur. Un genre de chroot à la volée sur un espace tampon.
RépondreSupprimerOkay pour la suppression de la route par défaut. A partir d'une certaine taille de réseau, l'utilisation de règles explicites aidera autant les admins réseau que les gens de la sécurité, d'ailleurs.
Autre proposition concernant le social engineering (qui nécessite développement) : l'ajout de méta-données qui doivent être affichées par les programmes et qui permettent de connaître les règles de (non-)divulgation. Façon DLP mais orienté sensibilisation.