Le problème avec la situation (telle que vous la rapportez) 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 accepte quelque chose, vous devez trouver un terrain d'entente. Vous devez contester et confirmer chaque hypothèse et trouver des données concrètes pour soutenir votre opinion ou la leur. Une fois que vous avez un terrain d'entente, vous pouvez tous avancer ensemble.

1. 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?
2. Que fait le pare-feu? Comment est-il configuré? Les pare-feu signifient les ports bloqués, mais ils signifient également les ports autorisés . Ces ports autorisés peuvent-ils être abusés?
3. Personne n'y a accès? Qui a accès à l'appareil? Faites-vous confiance à un initié ou à l'ignorance d'un utilisateur pour assurer sa sécurité?
4. Que se passe-t-il si quelqu'un obtient un accès local à l'appareil? Quelle est la probabilité que cela?

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 ne pas utiliser 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 sous les conditions de Fort Knox / High security prison, avec 24 / 7 gardes et caméras de sécurité,

et aussi l'un des suivants:

• La machine n'a aucun échange d'informations d'aucune sorte (non usb, ethernet, firewire, série, parallèle, etc. de tout type)

• La machine est éteinte en permanence.

Parce que vous voulez une stratégie de sécurité à plusieurs niveaux avec une défense en profondeur. Vous avez un pare-feu, mais que se passe-t-il s'il y a une faille 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 de l'utilisateur, puis qu'une vulnérabilité de système d'exploitation non corrigée permet de l'escalader en 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 que vous pensez ne peut pas être exploité peut permettre des compromis là où l'un ou l'autre ne le ferait pas, 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 entrer dans le 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 le nom d'utilisateur et le mot de passe. N'importe laquelle des couches rend les deux autres redondantes. Le problème est "et si". Pensons à la connexion par défaut scott / tiger de l'ancien Oracle ou un employé transfère par inadvertance un port vers l'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é s'applique uniquement à 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é apprennent des tentatives d'attaques (avec un peu de chance), ou ils inspectent l'activité sur les pots de miel. De plus, les exploits zero day (ceux qui s'appliquent même au dernier patch) ont moins de chances de réussir dans un environnement en couches, car l'attaquant aura besoin d'un exploit pour chaque couche.

Aucun appareil n'est pas piratable, juste il n'a pas été piraté auparavant. Soit il y a peu d'intérêts sur votre appareil et / ou le gain est très faible. Les exploits Zero Day peuvent toujours exister.

De plus, certains appareils 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 de le pirater.

Maintenir un appareil sans support actif est dangereux également du point de vue fonctionnel perspective.

La sécurité n'est pas nécessaire conçue pour protéger des étrangers (pare-feu) mais aussi des initiés. Je ne connais pas le contexte de votre appareil, mais étant donné ce que vous écrivez, il peut être vulnérable à quelqu'un qui se trouve déjà à l'intérieur du pare-feu.

Il n'y a pas de systèmes non piratables. Pour ceux qui mentionnent l'espacement aérien, il existe de nombreux exemples de hacks réels ou de hacks potentiels sur des systèmes espacés. Stuxnet est probablement l'exemple le plus célèbre (et le plus extrême). D'autres incluent le phreaking de van Eck, l'analyse acoustique ou d'autres attaques de canaux secondaires.

Il existe des moyens d'atténuer les vulnérabilités qui n'impliquent pas de correctifs. Par exemple, si le système est vulnérable à KRACK, est-il possible de simplement désactiver le WiFi? Si le WiFi est désactivé en permanence, il ne devrait pas être nécessaire d'appliquer une mise à jour impliquant le WiFi. De même, s'il y a des applications spécifiques sur le système qui présentent une vulnérabilité (comme Java, .NET, Flash, les 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 à jour du système d'exploitation, c'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 a tendance à minimiser le risque de vulnérabilités CONNUES. Pour faire écho à Schroeder, l'analyse des risques est plus importante que le «renforcement / verrouillage» ou la «mise à niveau» aveugle et en espérant que l'un ou l'autre vous rendra plus sûr.

Aucun système n'est véritablement "inattaquable". Cependant, une fois que nous avons décidé qu'un système est suffisamment "non piratable", nous n'avons plus besoin de maintenir un canal pour les correctifs de sécurité.

Pour un exemple concret, notre système "non piratable" contrôle une caméra de sécurité. Le travail de la caméra est de regarder un endroit fixe. Chaque paramètre est soit constant, soit le système est suffisamment intelligent pour s'ajuster par lui-même. Le système diffuse les données vidéo et n'a besoin d'aucune entrée de la part de l'utilisateur.

Nous pourrions demander au système d'exécuter ssh afin de pouvoir nous connecter périodiquement et d'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 pour le piratage de 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 ne vaut pas la peine.

J'ai eu cette idée d'une présentation à laquelle j'ai assisté où quelqu'un a décrit les systèmes sur lesquels il construisaient pour le gouvernement. Les composants du système étaient des machines virtuelles de courte durée (généralement moins d'un jour). Chaque machine virtuelle était immuable et jetable. Le plan était que s'ils avaient besoin d'appliquer un correctif de sécurité, ils se débarrasseraient simplement des machines de manière ordonnée et en créeraient 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 ne fournissait aucune valeur de sécurité et était en fait un trou.

Cependant, en y réfléchissant, cet exemple (et ma caméra) ne sont que des mises à jour de sécurité via un canal non traditionnel.

Qu'en est-il

1. d'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
2. 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 (pour le moment) à un moyen de le pirater ne signifie pas qu'il est "inhackable". C'est pourquoi, en principe, nous appliquons tous les correctifs de sécurité, même s'il s'agit d'un composant qui ne devrait pas être accessible (par exemple, pourquoi corriger une vulnérabilité d'escalade de privilèges si un attaquant n'a même pas accès aux utilisateurs?).

Maintenant, ils peuvent avoir raison, et ne pas le corriger pourrait en fait être la bonne décision dans votre cas. Mais il y a peu de gens pour lesquels j'accepterais tout à fait cela. Et ces ingénieurs ne sont probablement pas spécialement compétents pour effectuer des audits de sécurité.

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 ont parié leur maison?).

S'ils ne sont pas à l'aise de faire ça, eh bien, alors ils ne pensent pas que ce soit impossible à pirater. Et s'ils pensent que cela révélerait des informations importantes, cela signifie qu'ils s'appuient sur la sécurité par l'obscurité. Un vrai système non piratable serait toujours piratable si l'attaquant savait tout sur son fonctionnement.

PS: Même s'ils ne finissent pas par parier leurs maisons, vous auriez vraiment intérêt à implémenter un programme de bug bounty.

les ingénieurs qui ont conçu le produit original 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 en informatique est que les gens ne voient pas la nécessité de mettre à jour un système, pourquoi changer un système opérationnel? Ces entreprises font ensuite la une des journaux: "4 usines ont été fermées en raison de l'épidémie x" ou "L'entreprise x a été violée, les détails personnels de y millions de clients exposés".

Imaginez, le cloud d'IBM a récemment tout déplacé les clients avec force à 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 peu m'importe quelles sont leurs excuses, ils devraient exécuter TLS 1.2 PARTOUT! IBM est de retour 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, peu importe, éliminez-le et ne faites pas affaire avec la société qui vend le licorne noire ... En tant qu'industrie, nous ne faisons pas cela et les violations font la une des journaux, les violations continueront de faire les gros titres jusqu'à ce que nous apprenions la leçon.

pense que la machine n'est pas piratable

Les sentiments n'ont pas d'importance. Les faits le font.

Revenez à votre évaluation des risques et / ou à votre modèle 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 un logiciel obsolète faisait 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 l'évolution du risque ou des menaces qui ne sont plus traitées. basé sur le fait que le logiciel n'est plus obsolète. Considérez également que ce risque particulier va augmenter avec le temps au fur et à mesure que le risque de découverte d'un défaut exploitable augmentera. Alors attendez 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 des risques mis à jour. Il se peut aussi que cela rende le risque acceptable aujourd'hui, mais plus dans quelques années. Au lieu de chercher des arguments contre les ingénieurs, mettez-vous sur la même longueur d'onde avec eux. Vous savez au moins que des mesures d'atténuation pourraient être nécessaires.

"Le système ne peut pas être piraté, alors pourquoi corriger les vulnérabilités?" Dans votre question, vous essayez d'argumenter contre une erreur et un argument indémontrable ("Comment savez-vous savoir que c'est" inhackable "? Ou pensez-vous simplement que puisque vous ne pouvez pas le pirater, personne d'autre ne peut? "). En fin de compte, cependant, je pense que cela se résumera à une discussion sur l'acceptabilité du risque et sur qui est prêt à accepter ce risque. Essayez de leur expliquer de cette façon

"Nous avons une liste blanche des applications, alors pourquoi avons-nous besoin de corriger les vulnérabilités?"

La liste blanche des applications est uniquement bon comme 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écidait de «vivre de la terre» et d'utiliser les outils propres 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 a une vulnérabilité

"Nous avons un pare-feu, alors pourquoi avons-nous besoin de corriger les vulnérabilités?" C'est, effectivement, le même argument que le précédent. Êtes-vous certain, absolument, positivement, à 100%, au-delà de tout doute, certain qu'il n'y a pas de vulnérabilités dans la pile réseau et / ou le pare-feu lui-même, ni dans aucune des applications ou services qui peuvent être à l'écoute ou accessibles via cette pile réseau?

Si leurs réponses à ce qui précède sont qu'ils sont à 100% positifs quant à leurs choix et décisions, alors je rédigerais un document détaillant leur acceptation de ce risque et le ferais valider par leur équipe de direction jusqu'à le CIO. En fin de compte, ce sont leurs (le niveau CxO) qui sont confrontés au problème si et quand le système est violé et ce sont eux qui pourraient être convoqués devant le Congrès (ou tout autre organe de surveillance gouvernemental auquel ils sont soumis) tous les cadres. à Equifax étaient. Lorsqu'on explique 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 d'accréditation et de surveillance) et qu'ils (le CxO) pourraient être tenus responsables, attitudes va souvent changer.

Cela me semble simple. Revenons à la question de savoir comment faire passer un argument contre le fait de ne pas patcher un système considéré comme inattaquable. Quel est le pire scénario qui puisse se produire si ce système est violé? Supposons que toutes les protections en place échouent ou sont également violées. Ne biaisez pas cet exercice en révélant les conséquences parce que vous ne pensez pas qu'il peut ou sera violé.

Maintenant, traduisez ce pire scénario en termes de coût en termes d'impact commercial sous forme de perte 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 il le fait, après avoir expliqué comment cela s'est produit, la décision consciente de continuer à utiliser le système d'exploitation EOL et de juger les correctifs inutiles sera proche, sinon en haut, de la liste. "

D'un autre côté, si l'impact commercial n'est pas aussi important, il peut être judicieux de continuer à utiliser un système d'exploitation EOL. Mais comment faire au mieux cela d'une manière bien gérée des risques est un autre sujet.

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 en stricte conformité avec les directives de son fabricant, sinon vous risquez d'être bloqué avec toutes les conséquences et responsabilités découlant de toute défaillance dans laquelle il pourrait être impliqué.

Donc, si le périphérique 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 désuet sans 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 positive de continuer utiliser des composants obsolètes et non pris en charge:

• il a été démontré qu'ils le faisaient (et vous l'avez par écrit)
• ont affirmé que la mise à niveau était 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 avoir fait cette mise à niveau" .

Dans la pratique, il y a souvent des mises à niveau des composants qui sont mandatés par eux étant devenus EOL, 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 des 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 définitivement la méthode d'attaque.

La liste blanche des applications n'est pas une protection, juste un barrage routier mineur. Vous pensez qu'un hacker ne peut pas développer une application qui se fait passer pour une application sur la liste blanche des applications? Bien sûr, ils peuvent ... quelque chose qu'ils pourraient examiner si leur première tentative échoue.

Equifax avait tout un pare-feu en place. 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 laissé ouvert par nécessité. Un pare-feu arrête simplement certaines des attaques les plus anciennes et évidentes.

Pensez au piratage de Target - le PDG et le CIO ont perdu leur emploi à cause de 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, plus ancienne , méthodes de connectivité non sécurisées sur leurs appareils de point de vente. Sans aucun doute, le DSI a conclu que la mise à jour de la version Win sur leurs appareils de point de vente était trop coûteuse, un jugement qui s'est avéré très erroné.

Vous pensez que le micrologiciel intégré est immunisé contre le piratage? Considérez le piratage de l'imprimante HP. HP a eu l'idée intelligente 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 transforme l'imprimante en relais de spam et la délivre via un travail d'impression malveillant.

Comment effectuez-vous les mises à jour du firmware? Grâce au wi-fi? Oui, un hacker peut reproduire cela ... s'il a une raison suffisante.

Un appareil en réseau peut être piraté pour faire partie d'un botnet ... une manière courante de lancer une attaque DOS. Un pirate informatique 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 les actions de votre entreprise. C'est arrivé ... Voler des informations PII et CC n'est pas le seul moyen de profiter d'un piratage.

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 exercé une 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 «inhackable» ne peut probablement pas être considéré comme une diligence raisonnable.

D'ailleurs, si vos ingénieurs disent que c'est impossible à pirater, ils ne recherchent probablement même pas les vulnérabilités potentielles, et encore moins les atténuer.

Quiconque dit qu'un système ne peut pas être piraté n'est tout simplement pas réaliste. Pas de nos jours.

En fonction des ressources dont vous disposez, la méthode «infaillible» (avec tout le respect que je dois à vos collègues) serait de leur prouver 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 terriblement difficile. WLAN et pare-feu? C'est une contradictio in adjecto .

Après coup: Peut-être est-il possible de s'entendre sur le paiement en cas de succès (mon dictionnaire appelle cela des "honoraires conditionnels"); de cette façon, le service (de piratage) en vaudrait toujours la peine.

Chaque jour, nous faisons la une des journaux disant qu'un système est piraté. Ce n'est pas parce qu'ils ne sont ni à jour ni protégés par des mitrailleuses, mais parce que quelqu'un investit du temps pour les pirater.

Plus important encore, ceux qui sont bien joués ne sont pas faits par IQ power mais par une simple ingénierie sociale. On nous dit donc de garder le système à jour car si nous tombons d'une manière ou d'une autre dans ce trou, nous leur donnons les informations qui ne les aident pas.