Pourquoi est-il important d'appliquer les meilleures pratiques de sécurité lorsque le risque contre lequel elles protègent est très faible?
Parfois, les meilleures pratiques de sécurité vous protègent contre les attaques très improbables. Dans ces scénarios, comment défendez-vous la mise en œuvre de telles mesures de sécurité?
Par exemple, l'accès protégé par mot de passe au BIOS d'un client léger. Un BIOS sans mot de passe est un risque car un attaquant disposant d'un accès physique peut modifier la configuration du BIOS afin de démarrer depuis USB et accéder aux données du système sans authentification. Dans ce cas, l'attaquant a besoin d'un accès physique, le thinclient ne stocke pas trop d'informations importantes, etc. Le risque est très faible.
D'autres exemples peuvent être liés à certaines mesures lorsque vous durcissez des systèmes.
Dans ce cas, vaut-il mieux ne pas appliquer cette mesure de sécurité pour être raisonnable avec le reste de l'entreprise ou vous ouvrez de petits trous qui vous frapperont au visage à l'avenir?
L'impact potentiel de cela n'est pas faible, quelle que soit la quantité d'informations stockées par le client léger.
Plus précisément, le risque est qu'un attaquant installe quelque chose comme un rootkit ou un enregistreur de frappe logiciel dans le système d'exploitation du client léger, que vous ne pourrez probablement pas découvrir par inspection. (Ceci est une variante de l'attaque Evil Maid).
Si un administrateur utilise ce client à l'avenir, ce sera la partie terminée pour le réseau. Le client léger peut également être utilisé comme tête de pont pour lancer de nouvelles attaques contre le réseau ou pour effectuer une reconnaissance.
La protection du BIOS empêche cela de se produire, en protégeant l'intégrité du système d'exploitation client léger.
La leçon plus large ici: Les meilleures pratiques vous permettent d'économiser les dépenses et la difficulté d'évaluer chaque risque, ce qui, comme le montre cette question, est difficile à faire.
Les coûts sont la base pour évaluer les risques et leurs atténuations. Si les coûts (coûts monétaires, coûts opérationnels, coûts de facilité d'utilisation, etc.) pour mettre en œuvre une défense (meilleures pratiques, etc.) dépassent les dommages causés par le risque réalisé, alors vous avez le droit de choisir d'accepter le risque .
C'est un concept assez basique dans la gestion des risques.
Les meilleures pratiques ne sont pas des lois mais des recommandations. Ils viennent généralement avec une explication pourquoi ils sont recommandés. Si vous pensez que l'explication ne s'applique pas dans votre cas, vous êtes libre d'ignorer la recommandation. Vous pourriez même avoir raison avec ce sentiment et ainsi vous pouvez économiser des coûts.
Mais sachez qu'en fonction de votre environnement de travail, vous ne pouvez pas simplement ignorer la recommandation, mais vous devez documenter pourquoi vous pensez qu'elle peut être ignorée. Il se peut également que vous soyez responsable en personne si quelque chose de grave se produit parce que les meilleures pratiques ont été ignorées. Ainsi, il est souvent plus facile et moins risqué de suivre les recommandations que de les ignorer.
Il y a un certain nombre de facteurs à considérer ici:
Quel est le coût de mise en œuvre de la mesure? La protection de tous les BIOS peut être pénible, mais n'est pas une dépense importante en argent ou en effort.
quel est le risque qu'une mauvaise chose se produise? Les chances sont assez faibles, mais l'impact est modéré (les enregistreurs de frappe sont mentionnés, il y a un certain nombre d'autres problèmes avec quelqu'un qui exécute son propre code sur votre système, à savoir que ce n'est plus votre système). Le risque réel est faible à moyen.
Quel est l'impact de la mise en œuvre? Existe-t-il des raisons légitimes pour que l'utilisateur moyen accède au BIOS de son client léger? Pas vraiment.
Nous avons donc quelque chose où l'atténuation ne coûte pas cher, n'a pas d'impact majeur et protège contre un risque faible à moyen. Je dirais que c'est un bon argument pour l'appliquer, personnellement.
Dans de nombreux cas, cela se résume à une question sur ce que signifie très faible risque . Si vous avez une connaissance exacte du niveau de risque, vous pouvez effectuer des calculs sur le coût attendu de la non-atténuation du risque.
En réalité, vous connaissez rarement le risque exact. Souvent, les problèmes de sécurité potentiels sont considérés comme un risque très faible sans aucune tentative d’évaluation réelle du risque.
Dans de nombreux cas, il faut moins d'efforts pour résoudre le problème de sécurité que pour évaluer le risque avec une précision suffisante pour prendre une décision éclairée sur la manière de traiter la vulnérabilité de sécurité. Pour moi, c'est le principal argument pour remédier aux vulnérabilités de sécurité, même à très faible risque, car cela signifie que vous économisez la plupart des coûts associés à l'évaluation du risque.
Qui peut toujours faire la différence entre un problème de sécurité connu pour être à faible risque et un problème supposé faible?
Parfois, il est plus productif d'évaluer les problèmes de sécurité les uns par rapport aux autres plutôt que d'évaluer chaque problème de sécurité individuel par rapport à un seuil de risque faible.
Dans votre exemple spécifique, vous pouvez comparer le risque de modification malveillante des paramètres du BIOS au risque de connexion réseau sur le périphérique en cours de bug avec un périphérique MITM.
La posture que vous adoptez est basée sur l'environnement dans lequel vous opérez. À tout le moins, les politiques de sécurité que vous créez sont proportionnelles au budget dont vous disposez et aux modèles de menace que vous avez en tête. Sans une évaluation de la valeur en dollars que vous protégez, vous passerez un temps exorbitant à déterminer où se trouvent les trous. D'un autre côté, les éléments criminels utilisent des éléments protégés faibles ou inexistants pour rechercher des cibles de valeur supérieure.
Gardez également à l'esprit que les fournisseurs censés aider à atténuer les risques ne viennent pas avec la solution miracle pour résoudre chaque problème. En fin de compte, vous et l'entreprise êtes les seuls responsables de la sécurité. D'un point de vue commercial, vous pourriez répercuter les coûts des erreurs/failles de sécurité, mais cela pourrait ne pas aider à long terme. C'est un monde assez sombre en ce moment.
Parfois, les meilleures pratiques de sécurité vous protègent contre des risques très improbables. Dans ces scénarios, comment défendez-vous la mise en œuvre de ces mesures de sécurité?
Vous ne devriez rien avoir à défendre; laissez les chiffres parler d'eux-mêmes:
- Probabilité d'attaque X se produisant = P.
- Coût total de X s'il se produit = TC. (Cela doit inclure le diagnostic et la réparation de la violation, la perte de revenus, la réputation, les poursuites, la gestion de crise, etc.)
- Coût de prendre des mesures de sécurité pour empêcher X en premier lieu = C.
L'équation est simplement:
C <P * TC
Lorsque l'équation est vraie, la mesure de sécurité doit être mise en œuvre. Bien sûr, la partie difficile consiste à calculer P et TC pour commencer, mais vous pouvez trouver que vous pouvez être trop conservateur sur TC et trop optimiste sur P et ce sera toujours un investissement utile. De plus, vous obtenez également l'avantage supplémentaire de faire connaître les mesures de sécurité aux investisseurs et/ou aux clients.
Il s'agit évidemment d'une simplification excessive de tous les facteurs à considérer, mais d'un point de vue ROI, la logique devrait tenir le coup.
C'est donc une sorte d'extension de réponse de schroeder .
Je pense qu'il y a un léger mélange ici dans ce que nous entendons par "risque". Vous regardez le risque du point de vue du système informatique (mot de passe du BIOS, installez AV, utilisez un pare-feu, etc.). La perspective dont Schroeder parle est du point de vue de l'entreprise: une fois que la machine a été compromise, quel est le coût associé?
Lorsqu'une entreprise a un "risque", il y a quelques choses qu'elle peut faire :
Acceptez le risque - supposez que rien de mauvais ne se produira, et s'il le fait, ce ne sera pas un énorme problème à gérer.
Évitement des risques - Évitez toute exposition au risque.
Limitation des risques (atténuation) - Réduisez la probabilité que le risque se produise.
Transfert de risque (CYA) - Assurez-vous que quelqu'un d'autre est responsable du risque.
Pour être clair, les deux types de risques qui sont discutés dans le fil:
Le risque d'une entreprise si un système particulier est compromis. Cela peut inclure des informations financières sur les clients (numéros de carte de crédit, etc.), ainsi que des informations exclusives, des secrets commerciaux, des informations classifiées, etc.
Le risque que propose l'OP: le risque qu'un ordinateur soit compromis de manière spécifique.
Voici la nuance à laquelle je veux en venir: # 1 est le risque de l'entreprise. La stratégie pour gérer ce risque passe généralement par la limitation des risques (atténuation) . C'est là qu'intervient # 2. # 2 atténue la probabilité que # 1 se produise. Nous considérons de nombreuses méthodes différentes dans lesquelles un ordinateur peut être compromis dans # 2, et mettons en œuvre des mesures préventives afin d'atténuer autant que possible # 1. Étant donné que de nombreuses `` meilleures pratiques '' sont bon marché ou simples (c'est-à-dire que leur coût est facilement justifié), il est logique de les suivre même si sur une base individuelle, leur vecteur d'attaque est hautement improbable.
En ce qui concerne votre exemple:
Tout accès à un système/réseau/forêt/chose qui contient des données sécurisées doit être sécurisé de bout en bout, quelle que soit la taille de la fin.
En ce qui concerne la sécurité en général :
Tous les accès à un système/réseau/forêt/objet contenant des données sécurisées doivent être sécurisés.
Pourquoi?
Il y a une raison à cela. Un point d'accès unique à un réseau contenant des données sécurisées a lui-même besoin de sécurité. Les informations sur ce qui s'est passé sur le système dans son ensemble doivent être sécurisées pour garder les données sécurisées dans leur plus petite partie. Si un seul maillon de la chaîne se casse, la chaîne est rompue.
Mais comment briser cette chaîne s'il n'y a pas d'informations de sécurité sur le client? Simple, en observant le réseau. Si je peux voir ce qui se passe sur le réseau, je peux savoir quelles clés me permettront de franchir quels verrous, comment et de quelles manières. Ensuite, j'ai un moyen facile d'accéder à votre réseau et d'obtenir vos données. C'est pourquoi, de bout en bout, TOUTES les activités doivent être sécurisées.
Passons à l'exemple de vous frapper au visage:
- Vous pensez que votre maison est sécurisée.
- Vous avez des scanners biométriques d'empreintes digitales (comme sur la télévision) qui signifient que seuls vos doigts vous permettent d'entrer
- Vous touchez un bouton de porte sur une devanture de magasin à 70 millions de kilomètres, il y a six ans
- Je soulève cette impression
- J'identifie votre impression (à travers un long processus)
- J'utilise cette impression pour ouvrir votre maison pendant que vous dormez
- Je te frappe au visage
Même si c'était à des kilomètres de là, et que cette estampe avait de nombreuses autres estampes, et ainsi de suite, je pourrais éventuellement trouver votre empreinte là-dedans et l'utiliser pour ouvrir votre maison. C'est très improbable, mais si je le veux vraiment, je peux toujours vous frapper au visage avec du temps, des efforts et de la patience.
Même si cela ne fait que présenter un exemple. Disons plutôt la vérité de la sécurité:
Le système le plus sécurisé au monde dans des souterrains enfouis, dans un endroit inconnu, incendié et détruit.
Bien sûr, c'est un peu ironique, mais cela fait passer l'idée. Alors oui, cette meilleure pratique de sécurité doit toujours être utilisée. Après tout, votre système n'est pas le système le plus sécurisé au monde, vous devriez donc essayer de vous rapprocher.
Comme cela a déjà été dit, la sécurité est principalement une approche risque/coût.
Mais à mon humble avis, il y a un autre point à considérer: comme dans la sécurité des bâtiments, une porte renforcée est peu utile si la fenêtre est laissée ouverte. Pour évaluer correctement un risque, vous devez savoir contre quoi vous protéger. Donc, protéger le BIOS avec un mot de passe parce que cela pourrait être un vecteur pour un attaquant qui pourrait avoir un accès physique. À mon humble avis, si un attaquant peut accéder physiquement à un ordinateur, cet ordinateur est compromis car tout pourrait arriver: un enregistreur de frappe physique dans le clavier lui-même, un analyseur de réseau entre le connecteur interne et la fiche externe, un périphérique USB malveillant à l'intérieur de la boîte , etc.
Mais le mot de passe du BIOS est toujours une bonne pratique car il peut empêcher une nouvelle infection si une attaque atteint le poste, et principalement parce qu'il empêche un utilisateur imprudent ou maladroit de casser ou de compromettre son propre terminal.