Si nous sommes derrière un pare-feu, devons-nous toujours corriger / corriger les vulnérabilités?
J'ai récemment rejoint une communauté axée sur la sécurité dans mon organisation. Beaucoup de nos produits sont déployés dans l'intranet (sur site), rien dans le cloud public. Ainsi, les portails internes ne sont accessibles qu'au sein du réseau de l'organisation.
Récemment, une vulnérabilité de sécurité d'une bibliothèque tierce Apache (apparemment, une exécution de code à distance) a été publiée. Notre responsable de la sécurité nous avait demandé de mettre à niveau la bibliothèque vers la dernière version fixe immédiatement.
J'avais demandé: "Puisque le portail n'est accessible que sur l'intranet derrière un pare-feu, avons-nous encore besoin de mettre à jour la bibliothèque?". Le responsable n'a pas pu fournir d'explication détaillée en raison du manque de temps et a confirmé que la mise à niveau devait se produire malgré tout.
Alors, quel est le problème avec la déclaration (hypothèse?), "Car nous sommes derrière un pare-feu et de telles vulnérabilités ne nous affectent pas".
Votre déclaration fait deux hypothèses erronées:
Votre ou vos pare-feu sont entièrement configurés correctement et ne présentent aucune vulnérabilité qui permettrait à un attaquant de le compromettre et cet état parfait continuera.
Tout le monde dans votre organisation est digne de confiance et ne présente aucun risque.
Vous devez toujours opérer selon une approche de défense en profondeur et sécuriser chaque couche partout où vous le pouvez. Si un attaquant pénètre dans un périmètre ou si vous avez un acteur voyou, cette vulnérabilité Apache pourrait être exploitée si elle n'était pas corrigée.
C'est une question séculaire et a toujours la même réponse.
Vous ne pouvez pas vous attendre à ce que vos attaquants ne puissent pas accéder à votre réseau. Tout ce qu'il faut, c'est un seul employé qui clique sur un e-mail de phishing et l'attaquant a un pied sur votre réseau. Si vous laissez tout sans correctif, ils auront une journée sur le terrain.
Les rapports sur les menaces constatent régulièrement que vous êtes beaucoup plus à risque de la part de vos propres collègues que de l'extérieur. De ce rapport 2015 , par exemple, nous avons les chiffres suivants:
74% des infractions proviennent de l'entreprise étendue - soit parmi les employés (40%), les tiers (22%) ou les anciens employés (12%) - avec 26% provenant de l'extérieur de l'organisation
...
Les deux tiers (67%) des atteintes à la sécurité interne proviennent d'une erreur involontaire - une sur trois (33%) est due à une intention malveillante
Ainsi, 33% de 74% nous donne environ un quart de toutes les infractions causées par l'un de vos propres collègues décidant qu'ils ne vous aiment pas.
Cette vulnérabilité spécifique devrait être exploitée par une menace d'initié malveillante et techniquement capable. D'une part, le qualificatif "techniquement capable" réduit ici de manière significative votre probabilité d'attaque. D'un autre côté, "cette vulnérabilité ne nous rend vulnérables qu'aux initiés" est une raison tout à fait inadéquate de ne pas corriger.
Oui, vous devez patcher les systèmes internes.
Supposons que ce qui suit est vrai (ce qui n'est probablement pas le cas):
- votre système interne est 100% impénétrable du monde extérieur (ou vous êtes bien avec chaque système interne étant repris en cas de violation).
- vous faites confiance à 100% à tout le monde dans votre organisation (ou plus précisément à toute personne ayant accès à l'intranet, qui peut également inclure des visiteurs, des employés temporaires, etc.).
Il existe encore des vulnérabilités basées sur le Web qui ne nécessitent aucun accès à l'intranet, notamment XSS et CSRF.
Si vous adoptez la même approche de non-mise à jour avec les applications Web que vous adoptez avec les serveurs Web, il est juste de supposer que certaines applications seront vulnérables. Désormais, un attaquant qui connaît ou devine les logiciels que vous utilisez pourrait obtenir l'exécution de code via XSS ou CSRF si un membre de votre organisation ne fait pas attention en cliquant sur des liens ou en visitant des sites Web.
Pour expliquer métaphoriquement:
Un pare-feu, au sens habituel d'un filtre de paquets directionnel/passerelle de masquage NAT, empêchera le reste du monde de nourrir de force votre poison "humain".
Cela les empêchera également de causer trop de dommages au reste du monde s'ils deviennent fous et violents au cas où quelqu'un les empoisonnerait encore.
À moins que vous ne les mainteniez à un régime très strict, cela n'empêche pas votre peuple de chercher et de manger des aliments que quelqu'un a empoisonnés, soit dans le but exprès de les empoisonner, soit simplement par pur sadisme non ciblé, pour provoquer la terreur ...
Un pare-feu plus avancé (inspection approfondie des paquets, liste noire/liste blanche, etc.) contrôlera la nourriture, mais ne sera pas fiable. Cela peut également créer des problèmes quand il pense que l'assouplissant est de la gatorade, ou que le fromage malodorant est une tentative de gazage pour tout le monde, ou que le sel étant mis au vert signifie qu'une bouteille de saumure saturée sera sûre à consommer.
Les services et applications intranet uniquement non sécurisés sont souvent la cible finale des violations. Malheureusement, le plus souvent, les administrateurs système/réseau trop confiants (et j'ose dire naïfs) négligent de les sécuriser.
Que faire si la machine d'un utilisateur normalement de confiance intranet contracte un virus, un cheval de Troie ou un malware de botnet, ou ce que vous avez qui scanne votre intranet de l'intérieur et envoie ces informations à une partie non fiable? Désormais, la partie non fiable a non seulement un vecteur dans votre intranet, mais elle connaît la mise en page et comment accéder à ses services non sécurisés.
Pour contrer les nombreuses vulnérabilités imprévues, il faut avoir plusieurs niveaux de sécurité, pas un seul.
Les vulnérabilités logicielles sont un problème difficile à atténuer avec une mesure spécifique à moins qu'il ne soit entièrement testé. Aucun fournisseur ne peut donc répondre à une telle question à moins qu'il ne soit très sûr de la méthode d'atténuation à l'aide du pare-feu.
En fait, vous devez vous demander si le correctif interrompra votre application et votre processus actuels, s'il peut être annulé.
Maintenir à jour un pare-feu et maintenir à jour les logiciels sont 2 lignes de défense indépendantes
Bref, la réponse à votre question ne peut pas être oui ou non, les deux sont faux.
Et voici quelques explications:
Un pare-feu "parfait" (ce modèle n'existe pas) et même un intranet complètement isolé (c'est-à-dire sans connexion à Internet) ne protège pas vos systèmes contre la connexion au sein de cet intranet hautement protégé d'un ordinateur contaminé ou d'attaque. (Ceci est une rétroaction de la vie réelle: ~ une telle attaque de l'intérieur/année). Voir aussi Stuxnet (2010, analysé par Kaspersky Lab.) .
En bref, même un pare-feu "parfait" ne peut pas vous protéger contre les risques majeurs de l'intérieur.
À l'autre extrémité du spectre des événements pervers, une mise à niveau d'un système d'exploitation ou d'un logiciel n'est pas la garantie d'une amélioration de la sécurité. La plupart des mises à niveau logicielles sont des augmentations du nombre de lignes de codes et la loi des probabilités nous dit que le nombre de bogues augmente proportionnellement. Une mise à niveau du système d'exploitation peut ouvrir une vulnérabilité sur le port
80/tcp(http) dans Apache qui n'était pas présent dans la version précédente. Et comme c'est le cas sur de nombreuses configurations de pare-feu, ce protocole peut être légitimement autorisé à entrer dans votre réseau. Ensuite, la mise à niveau de votre système d'exploitation peut entraîner une grave vulnérabilité au sein de l'ensemble de votre réseau. Voir aussi vulnérabilité d'accès root à distance en passant à MacOS High Sierra (2017, analysé par Lemi Orhan Ergin) .En bref, même une pratique "parfaite" de "toujours mettre à jour" ne peut pas vous protéger contre le risque majeur de bugs des éditeurs devant un port ouvert de votre pare-feu.
Il existe de nombreux autres scénarios pour démontrer qu'aucune de ces 2 approches n'est suffisante: le pare-feu "parfait", la pratique de mise à niveau "parfaite".
Donc qu'est ce que je devrais faire?
Mon conseil personnel est de maintenir les pare-feu et les logiciels à jour de manière indépendante après avoir vérifié au minimum qu'aucun d'entre eux n'introduit une vulnérabilité contre laquelle l'autre n'est pas prêt à se défendre.