Comment puis-je argumenter contre: "Le système est impossible à pirater, alors pourquoi corriger les vulnérabilités?"
Un système d'exploitation a atteint la fin du support (EoS), donc plus aucun correctif de sécurité n'est à venir pour le système d'exploitation. Un périphérique intégré exécutant ce système d'exploitation doit être mis à jour vers une version plus récente. Cependant, les ingénieurs qui ont conçu le produit d'origine estiment que la machine n'est pas piratable et n'a donc pas besoin d'être corrigée. L'appareil dispose de ports WiFi, Ethernet, USB et d'un système d'exploitation qui a atteint EoS.
Les questions qui me sont posées quotidiennement:
- Nous avons la liste blanche des applications, alors pourquoi devons-nous corriger les vulnérabilités?
- Nous avons un pare-feu, alors pourquoi devons-nous corriger les vulnérabilités?
Et les commentaires que j'obtiens:
Notre plan est de durcir encore plus le système. Si nous le faisons, nous ne devrions pas avoir à mettre à jour le système d'exploitation et à continuer de le patcher. Personne ne pourra atteindre les vulnérabilités. Nous corrigerons également les vulnérabilités dans les parties du système d'exploitation orientées vers l'extérieur (même si elles n'ont pas la possibilité de corriger les vulnérabilités elles-mêmes), puis nous pourrons laisser les vulnérabilités non extérieures confrontées sans correction.
J'ai expliqué en détail les analyses avec accréditation Nessus. Je ne sais pas comment transmettre mon point de vue à ces ingénieurs. Avez-vous des réflexions sur la façon dont je peux expliquer cela?
PDATE: Le système est en cours de correction. Merci pour les réponses et l'aide de tous.
Le problème avec la situation (comme vous le signalez) est qu'il y a beaucoup d'hypothèses faites avec beaucoup d'opinions. Vous avez vos opinions et vous voulez qu'ils partagent vos opinions, mais ils ont leurs propres opinions.
Si vous voulez que tout le monde soit d'accord sur quelque chose, vous devez trouver un terrain d'entente. Vous devez contester et confirmer chaque hypothèse et trouver des données fiables pour étayer votre opinion ou la leur. Une fois que vous avez un terrain d'entente, vous pouvez tous avancer ensemble.
- Vous avez une liste blanche: super, qu'est-ce que cela signifie? Y a-t-il des moyens de contourner cela? Une application en liste blanche peut-elle être corrompue?
- Que fait le pare-feu? Comment est-il configuré? Les pare-feu signifient des ports bloqués, mais ils signifient également des ports autorisés. Peut-on abuser de ces ports autorisés?
- Personne n'y a accès? Qui a accès à l'appareil? Faites-vous confiance à un initié ou à l'ignorance d'un utilisateur pour le sécuriser?
- Que se passe-t-il si quelqu'un obtient un accès local à l'appareil? Quelle est la probabilité?
En tant que professionnel de la sécurité de l'information, votre travail n'est pas de battre les gens au-dessus de la tête avec les "meilleures pratiques", mais d'effectuer des analyses de risques et de concevoir une voie à suivre qui limite les risques sous le seuil de risque de manière rentable. Vous devez justifier pas en utilisant les meilleures pratiques, mais si la justification est valide, alors elle est valide.
Si quelqu'un me dit que sa machine n'est pas piratable et que je dois le croire, je conclus immédiatement que
- La machine est gardée dans des conditions de détention à Fort Knox/haute sécurité, avec des gardiens 24/7 et des caméras de sécurité,
et également l'un des suivants:
La machine n'a aucun échange d'informations d'aucune sorte (pas d'usb, ethernet, firewire, série, parallèle, etc. de toute nature)
La machine est éteinte en permanence.
Parce que vous voulez une stratégie de sécurité multicouche avec une défense en profondeur. Vous avez un pare-feu, mais qu'en est-il s'il y a une vulnérabilité de sécurité dans votre pare-feu? Que se passe-t-il si un exploit d'application donne un accès au système d'exploitation au niveau utilisateur, puis qu'une vulnérabilité de système d'exploitation non corrigée permet que cela soit escaladé pour un accès root? Pour une sécurité adéquate, vous devez corriger toutes les vulnérabilités connues, pas seulement celles qui, selon vous, peuvent être exploitées sur votre système, car une combinaison d'une vulnérabilité inconnue et d'une vulnérabilité connue qui, selon vous, ne peut pas être exploité peut permettre des compromis là où ce n'est pas le cas, et vous ne pouvez pas corriger les vulnérabilités inconnues.
La raison est simple, la sécurité est appliquée par couches. Par exemple, pour se connecter à une base de données importante, il faut d'abord accéder au réseau de la base de données (passer le pare-feu), ajouter sa propre adresse IP à la liste des clients autorisés à se connecter, puis initier la connexion avec nom d'utilisateur et mot de passe. L'une des couches rend les deux autres redondants. Le problème est "et si". Pensons à la connexion par défaut scott/tiger de l'ancien Oracle ou d'un employé qui transfère par inadvertance un port à Internet public. Le pare-feu peut bloquer uniquement TCP, tandis que le serveur écoute également sur UDP, ou IPv6 est mal configuré, et la sécurité ne s'applique qu'à IP4. C'est pourquoi une bonne sécurité se décline en plusieurs couches, les tentatives sont surveillées et les experts en sécurité tirent des leçons des attaques (qui, espérons-le, ont échoué), ou inspectent l'activité sur les pots de miel. De plus, les exploits zero day (ceux qui s'appliquent même au dernier correctif) sont moins susceptibles de réussir dans un environnement en couches, car l'attaquant aura besoin d'un exploit pour chaque couche.
Aucun appareil n'est piratable, il n'a jamais été piraté auparavant. Soit il y a peu d'intérêts sur votre appareil et/ou le gain est très faible. Des exploits Zero Day peuvent encore exister.
De plus, certains appareils Android Android ne peuvent tout simplement pas être mis à niveau au-delà d'une version spécifique. Savoir qu'un adversaire possède un tel appareil est une invitation ouverte au piratage, car le nom/la marque de l'appareil contient la recette exacte de la façon dont pour le pirater.
La maintenance d'un appareil sans assistance active est également dangereuse du point de vue fonctionnel.
La sécurité n'est pas nécessaire pour protéger des étrangers (pare-feu) mais aussi des initiés. Je ne connais pas le contexte de fonctionnement de votre appareil, mais compte tenu de ce que vous écrivez, il peut être vulnérable à quelqu'un déjà à l'intérieur du pare-feu.
Il n'y a pas de système inébranlable. Pour ceux qui mentionnent l'entrefer, il existe de nombreux exemples de hacks réels ou de hacks potentiels sur les systèmes à air. Stuxnet est probablement l'exemple le plus célèbre (et le plus extrême). Certains autres incluent le phreaking de van Eck, l'analyse acoustique ou d'autres attaques de canal latéral.
Il existe des moyens d'atténuer les vulnérabilités qui n'impliquent pas l'application de correctifs. Par exemple, si le système est vulnérable à KRACK, est-il possible de désactiver simplement le WiFi? Si le WiFi est définitivement désactivé, il ne devrait pas être nécessaire d'appliquer une mise à jour impliquant le WiFi. De même, s'il existe des applications spécifiques sur le système qui posent une vulnérabilité (comme Java, .NET, Flash, navigateurs, etc.), vous pouvez simplement désinstaller ces applications. Il n'est pas nécessaire de mettre à jour Java s'il n'est même pas installé.
Avec les mises à niveau du système d'exploitation, cela est certes plus difficile. Vous devez être conscient des vulnérabilités potentielles, puis vous devez les atténuer. L'avantage d'utiliser un système d'exploitation pris en charge est que quelqu'un d'autre fait (vraisemblablement) déjà la première partie et la moitié de la deuxième partie pour vous.
Un système entièrement mis à jour/mis à niveau n'est pas un système sécurisé ou non piratable. Mais cela tend à minimiser le risque de vulnérabilités CONNUES. Pour faire écho à Schroeder, l'analyse des risques est plus importante que le "durcissement/verrouillage" ou la "mise à niveau" aveugle et en espérant que cela vous rendra plus sûr.
Aucun système n'est vraiment "inébranlable". Cependant, une fois que nous avons décidé qu'un système est suffisamment "inébranlable", nous n'avons plus à maintenir de canal pour les correctifs de sécurité.
Pour un exemple concret, notre système "inébranlable" contrôle une caméra de sécurité. Le travail de la caméra consiste à regarder un emplacement fixe. Chaque paramètre est constant ou le système est suffisamment intelligent pour s'ajuster par lui-même. Le système diffuse des données vidéo et ne nécessite aucune entrée de l'utilisateur.
Nous pourrions avoir le système exécuté ssh afin que nous puissions nous connecter périodiquement et appliquer des correctifs de sécurité, mais cela ouvre en fait un (très petit) trou de sécurité. Un attaquant pourrait utiliser ssh pour pirater la caméra. (Bonne chance hacking ssh).
C'est donc un compromis. Si vous pensez honnêtement que vous n'aurez jamais besoin d'appliquer un correctif de sécurité, vous pourriez décider que laisser ce canal ouvert n'en vaut pas la peine.
J'ai eu cette idée lors d'une présentation à laquelle j'ai assisté, où quelqu'un a décrit les systèmes qu'ils construisaient pour le gouvernement. Les composants du système étaient des machines virtuelles de courte durée (généralement moins d'une journée). Chaque machine virtuelle était immuable et jetable. Le plan était que s'ils devaient appliquer un correctif de sécurité, ils se contenteraient d'éliminer les machines de manière ordonnée et d'en créer de nouvelles. Les machines virtuelles n'avaient pas de ssh.
L'auditeur de sécurité du gouvernement a fait sauter un joint et leur a fait installer ssh afin qu'ils puissent appliquer des correctifs de sécurité. Le serveur ssh n'a fourni aucune valeur de sécurité et était en fait un trou.
Cependant, en y réfléchissant, cet exemple (et mon appareil photo) ne sont que des mises à jour de sécurité via un canal non traditionnel.
Qu'en est-il de
- une caméra déployée sur Mars ... tout le monde connaît la caméra et tout le monde peut voir les données de la caméra
- une caméra qui existe secrètement derrière les lignes ennemies (si l'ennemi connaissait la caméra, il pourrait facilement la prendre ... voulons-nous maintenir un canal pour les mises à jour de sécurité).
Le fait qu'ils ne peuvent pas penser (en ce moment) à un moyen de le pirater ne signifie pas qu'il est "inébranlable". C'est pourquoi, en principe, nous appliquons tous les correctifs de sécurité, même si c'est sur un composant qui ne devrait pas être accessible (par exemple, pourquoi corriger une vulnérabilité d'escalade de privilèges si un attaquant n'avait même pas accès aux utilisateurs?).
Maintenant, ils peuvent avoir raison, et ne pas corriger cela pourrait en fait être la bonne décision dans votre cas. Mais il y a peu de gens pour qui j'accepterais carrément cela. Et ces ingénieurs ne sont probablement pas spécialement compétents en exécution audits de sécurité.
Comme argument pour les convaincre, je leur demanderais de donner accès à l'un de ces appareils à toute personne intéressée par une prime juteuse (par exemple, ils misent leur maison?).
S'ils ne sont pas à l'aise de le faire, eh bien, ils ne pensent pas que c'est inébranlable. Et s'ils pensent que cela révélerait des informations importantes, cela signifie qu'ils comptent sur la sécurité par l'obscurité. Un véritable système non piratable serait toujours piratable si l'attaquant savait tout de son fonctionnement.
PS: Même s'ils ne finissent pas parier leurs maisons, vous bénéficierez vraiment de la mise en œuvre d'un programme de bug bounty.
"Le système est impossible à pirater, alors pourquoi corriger les vulnérabilités?" Dans votre question, vous essayez d'argumenter contre un sophisme et un argument non démontrable ("Comment savez-vous qu'il est" inamovible "? Ou vous pensez juste que puisque vous ne pouvez pas le pirater, personne d'autre ne le peut? "). En fin de compte cependant, je pense que cela va se résumer à une discussion sur l'acceptabilité du risque et qui est prêt à accepter ce risque. Essayez de leur expliquer de cette façon
"Nous avons des listes blanches d'applications, alors pourquoi devons-nous corriger les vulnérabilités?"
La liste blanche des applications est aussi bonne que la liste blanche elle-même, les outils pour bloquer les applications ne figurant pas sur cette liste blanche, et suppose qu'il n'y a pas de défauts ou de vulnérabilités dans l'outil de liste blanche des applications lui-même. Il protège également uniquement contre les applications inconnues/non fiables. Et si l'attaquant décide de "vivre de la terre" et d'utiliser les outils du système contre lui-même? Que faire si l'une des applications que vous avez ajoutées à la liste blanche dans le cadre du système d'exploitation présente une vulnérabilité
"Nous avons un pare-feu, alors pourquoi devons-nous corriger les vulnérabilités?" Il s'agit, en fait, du même argument que le précédent. Êtes-vous certain, absolument, positivement, à 100%, sans aucun doute certain qu'il n'y a aucune vulnérabilité dans la pile réseau et/ou le pare-feu lui-même ni aucune des applications ou des services qui peuvent être écoutés ou accessibles via cette pile réseau?
Si leurs réponses à ce qui précède sont qu'ils sont 100% positifs sur leurs choix et décisions, je rédigerais un document détaillant leur acceptation de ce risque et le ferais approuver par leur équipe de direction jusqu'au DSI. En fin de compte, c'est leur (le niveau CxO) qui est à la merci du problème si et quand le système est violé et ce sont eux qui pourraient être appelés devant le Congrès (ou tout autre organisme gouvernemental de surveillance dont ils sont soumis) ala les dirigeants à Equifax étaient. Lorsqu'il est expliqué aux dirigeants qu'ils ne font pas tout ce qui est en leur pouvoir pour maintenir un système à jour et corrigé (comme l'exigent de nombreux groupes/lois de certification et de surveillance) et qu'ils (le CxO) pourraient être tenus responsables, les attitudes vont souvent changer.
les ingénieurs qui ont conçu le produit d'origine estiment que la machine n'est pas piratable
Les ingénieurs qui ont conçu le Titanic ont estimé qu'il était insubmersible.
Le problème dans l'informatique est que les gens ne voient pas la nécessité de mettre à jour un système, pourquoi changer un système qui fonctionne? Ces entreprises font alors la une des journaux: "4 usines ont été fermées en raison de la flambée x" ou "La société x a été violée, les données personnelles de y millions de clients étant exposées".
Imaginez, le cloud d'IBM a récemment déplacé tous les clients avec force vers TLS 1.1 (OUI, la version déjà obsolète) et certains clients se sont plaints ... CES CLIENTS DEVRAIENT SE PRÉPARER POUR TLS 1.3, je ne sais pas ce qu'ils font et je m'en fiche quelles sont leurs excuses, ils devraient exécuter TLS 1.2 PARTOUT! IBM dos colporté, INACCEPTABLE!
Maintenant, vous pouvez me dire que la licorne noire dans l'écurie vous empêche de tout déplacer vers TLS 1.2, que ce soit, en disposer et ne pas faire affaire avec l'entreprise qui vend la licorne noire ... En tant qu'industrie, nous ne le faisons pas et les violations font les gros titres, les violations continueront à faire les gros titres jusqu'à ce que nous apprenions la leçon.
sentir que la machine n'est pas piratable
Les sentiments n'ont pas d'importance. Les faits le font.
Revenez à votre modèle d'évaluation des risques et/ou de menace. Vérifiez si l'application de correctifs ou la mise à jour du logiciel faisait partie de votre plan de traitement des risques. Vérifiez si des logiciels obsolètes faisaient partie de votre analyse des risques ou de votre modèle de menace.
Retournez voir les ingénieurs avec ces faits et discutez avec eux de la façon dont le risque change ou des menaces qui ne sont plus traitées en raison du fait que le logiciel n'est plus obsolète. Considérez également que ce risque particulier augmentera au fil du temps à mesure que les chances de découvrir un défaut exploitable augmenteront. Alors, regardez en avant jusqu'à la fin de vie raisonnable de votre produit.
Notez que leurs mesures d'atténuation pourraient bien rendre le risque acceptable. Mais cela doit être discuté et le plan de risque mis à jour. Il se peut aussi que cela rend le risque acceptable aujourd'hui, mais dans quelques années plus. Et alors? Au lieu de chercher des arguments contre les ingénieurs, mettez-vous sur la même longueur d'onde avec eux. Le vôtre réalise au moins que des mesures d'atténuation pourraient être nécessaires.
Ce n'est peut-être pas du tout une décision technique. L'utilisation de tout composant de source externe signifie généralement que vous devez utiliser ce composant strictement conformément aux directives de son fabricant, sinon vous risquez de vous retrouver avec tous les conséquences et les responsabilités résultant de toute défaillance dans laquelle il pourrait être impliqué.
Donc, si l'appareil se comporte mal et que quelqu'un est blessé (ou qu'une autre responsabilité est engagée), le fabricant du système d'exploitation d'origine dira "logiciel non pris en charge - pas notre problème". Et l'assureur de votre entreprise dira "utiliser un logiciel obsolète hors support - c'est de la négligence, et donc pas notre problème".
Donc, de votre point de vue personnel, assurez-vous que ceux qui prennent la décision affirmative de continuer à utiliser des composants obsolètes et non pris en charge:
- il a été démontré qu'ils le font (et vous l'avez par écrit)
- ont affirmé que la mise à niveau est inutile (et ils l'ont fait par écrit)
Il y a un grand écart entre les gens qui disent "nous n'avons pas besoin de faire cette mise à jour" et "j'accepte personnellement la responsabilité de ne pas faire cette mise à jour".
Dans la pratique, il y a souvent des mises à niveau des composants qui ont été mandatés par eux comme étant en fin de vie, même s'il n'y a aucun besoin technique réel de le faire. C'est une partie nécessaire de l'ingénierie d'un produit complexe.
Si votre appareil dispose d'une connexion Wi-Fi, il peut être attaqué via le réseau. Cette attaque réussira-t-elle? C'est une question d'avantages d'attaquer l'appareil, par rapport au niveau d'effort requis. Le baser sur un système d'exploitation obsolète et non pris en charge simplifie certainement la méthode d'attaque.
La liste blanche des applications n'est pas une protection, juste un barrage mineur. Vous pensez qu'un pirate ne peut pas développer une application qui se fait passer pour une sur la liste blanche des applications? Bien sûr, ils peuvent ... quelque chose qu'ils pourraient examiner si leur première tentative ne fonctionne pas.
Equifax avait tout à fait un pare-feu en place. Cela n'a pas empêché les pirates d'exploiter le trou Struts que les responsables informatiques d'Equifax n'ont pas réussi à corriger, via un port qui a été laissé ouvert par nécessité. Un pare-feu arrête simplement certaines des attaques les plus anciennes et évidentes.
Repensez au piratage de Target - le PDG et le CIO ont perdu leur emploi sur celui-ci, et il a été perpétré par un initié, aidé par l'utilisation par Target d'une ancienne version de Windows, qui n'est plus mise à jour, ainsi que des méthodes de connectivité plus anciennes et non sécurisées sur leur dispositifs de point de vente. Sans aucun doute, le CIO a conclu que la mise à jour de la version Win sur leurs appareils POS était trop coûteuse, un jugement qui s'est avéré très erroné.
Vous pensez que le firmware intégré est à l'abri du piratage? Considérez le piratage de l'imprimante HP. HP a eu la bonne idée de mettre à jour le micrologiciel de son imprimante via un travail d'impression - facile à lancer. Jusqu'à ce que ... quelqu'un propose une version du micrologiciel qui a transformé l'imprimante en relayer le spam et l'a livrée via un travail d'impression de logiciels malveillants.
Comment faites-vous les mises à jour du firmware? Grâce au wi-fi? Oui, un pirate peut reproduire cela ... s'il a une raison suffisante.
Un appareil en réseau peut être piraté pour faire partie d'un botnet ... un moyen courant de lancer une attaque DOS. Un pirate pourrait trouver la vulnérabilité, et sachant que cela nuirait à la réputation de l'entreprise, lancer l'attaque en même temps qu'il court-circuite les actions de votre entreprise. C'est arrivé ... Voler des informations PII et CC n'est pas le seul moyen de profiter d'un hack.
Maintenant, demandez-vous - quel est le risque pour vous personnellement? Si votre système devait être piraté, pouvez-vous démontrer aux dirigeants de votre entreprise que vous avez fait preuve de diligence raisonnable pour identifier et atténuer les menaces potentielles, d'autant plus que vous basez le système sur un système d'exploitation qui n'est plus mis à jour? Astuce: prendre la Parole des ingénieurs qui disent que le système est "inébranlable" ne constitue probablement pas une diligence raisonnable.
D'ailleurs, si vos ingénieurs disent que ce n'est pas piratable, ils ne recherchent probablement même pas des vulnérabilités potentielles, sans parler de les atténuer.
Quiconque dit qu'un système est impossible à pirater n'est tout simplement pas réaliste. Pas de nos jours.
Cela me semble simple. Revenons à la question de savoir comment faire valoir un argument contre le fait de ne pas patcher un système considéré comme impossible à pirater. Quel est le pire scénario qui puisse se produire si ce système est brisé? Supposons que toutes les protections en place échouent ou sont également violées. Ne biaisez pas cet exercice en dévoilant les conséquences parce que vous ne pensez pas qu'il peut ou sera violé.
Maintenant, mettez ce pire scénario en termes d'impact sur les affaires sous la forme de pertes de revenus, d'amendes légales/réglementaires ou de dommages à l'image de l'entreprise dans l'industrie.
Si cet impact est grave, alors regardez vos ingénieurs dans les yeux et dites "êtes-vous prêt à mettre votre travail - et peut-être toute votre carrière - sur la ligne que cela ne se produira jamais? Parce que si c'est le cas, au lendemain de expliquant comment cela s'est produit, la décision consciente de continuer à utiliser le système d'exploitation EOL et à juger les correctifs inutiles sera proche, sinon en haut, de la liste. "
D'un autre côté, si l'impact sur l'entreprise n'est pas si impactant, il pourrait être judicieux de continuer à utiliser un système d'exploitation EOL. Mais la meilleure façon de le faire de manière bien gérée est un autre sujet entier.
Selon les ressources dont vous disposez, le moyen "à toute épreuve" (avec tout le respect dû à vos collègues) serait de prouver pour eux que le système est piratable. Embauchez quelqu'un qui le peut et laissez-le démontrer les faiblesses du système. Je suppose qu'avec le WLAN, cela ne devrait pas être très difficile. WLAN et pare-feu? C'est un contradictio in adjecto.
Après coup: il est peut-être possible de s'entendre sur le paiement en cas de succès (mon dictionnaire appelle cela des "frais de contingence"); de cette façon, le service (piratage) en valait toujours la peine.