Que faire lorsque vous trouvez une faille de sécurité sur le site de votre entreprise


13

J'ai trouvé une faille de sécurité majeure dans l'un des sites publics de mon entreprise. Il s'agit de notre premier site accessible au public qui a été converti à partir d'un site intranet. J'ai signalé ce problème à mon patron et ils l'ont essentiellement ignoré, disant qu'il faudrait beaucoup de travail pour ré-architecturer le site pour le rendre sécurisé.

Cela m'a vraiment dérangé et j'ai pensé à exploiter le trou pour montrer les effets que cela pourrait se produire si un pirate informatique y arrivait. Ce n'est probablement pas la meilleure idée car les effets pourraient me coûter mon travail sinon quelque chose de pire.

Que puis-je faire pour montrer l'ampleur de la situation à la direction?


8
Assurez-vous de tout avoir par écrit. Y compris votre mention du trou de sécurité et de son rejet.
FrustratedWithFormsDesigner

Réponses:


13

La responsabilité d'un gestionnaire est de gérer les risques.

Lorsqu'un trou de sécurité entre les scripts a été découvert dans Gmail, cela présentait un risque très critique que l'équipe a rapidement cherché à résoudre. Comme il y a des millions d'utilisateurs de Gmail, si j'écrivais une application Web qui exploitait cette faille, il y aurait de fortes chances que les utilisateurs de mon application Web utilisent Gmail et l'ouvrent dans un autre onglet. Ainsi, en tant que phishing, cela peut valoir la peine de construire une telle application pour accéder aux données des utilisateurs.

La question que votre manager peut se poser est la suivante: quel est le risque de cette faille de sécurité? Quelle est la probabilité qu'une application Web cible ce trou de sécurité particulier sur ce site particulier? Quel est le risque que les employés qui visitent notre site Web utilisent également ce site Web tiers?

D'après mon expérience, si votre site n'obtient pas une tonne de trafic, alors il n'y a pas une tonne de risque.

Votre patron pense peut-être que le coût d'opportunité de ne pas résoudre ce problème de sécurité particulier qui peut ou non être un problème, est qu'il peut plutôt concentrer ses ressources sur des activités qui aideront à développer l'entreprise et à générer des revenus.

Cela dit, il y avait un problème très similaire à celui où Github a été piraté, et il y a une question sur Project Management SE qui couvre ce sujet du point de vue de la gestion de projet. L'utilisateur qui a piraté Github était dans une situation similaire à la vôtre, et ses privilèges Github ont été suspendus pour une période de temps.

Ma question est la suivante: qu'advient-il de votre entreprise si le site tombe en panne? Quelle est la probabilité que vous voyiez même ce trou de sécurité exploité?

Si vous décidez de poursuivre, vous devrez obtenir objectivement des preuves qu'il s'agit d'une menace très réelle et imminente pour la viabilité de l'entreprise.

Voici quelques suggestions pour obtenir des preuves qu'il s'agit d'un vrai problème:

  • Effectuez des recherches Google à la recherche d'articles de presse, de blogs ou d'autres expériences d'entreprises qui ont rencontré des problèmes majeurs en raison d'une faille de sécurité similaire. Démontrez qu'il s'agit bien d'un risque qui mérite d'être traité au lieu d'autres opportunités commerciales.

  • Discutez avec d'autres membres du personnel technique de l'équipe et obtenez leur avis. Si le problème est vraiment grave, vous devriez pouvoir trouver d'autres personnes qui peuvent également vous soutenir. Sinon, soit vos préoccupations ne sont pas justifiées, soit vous avez des problèmes majeurs de sécurité dans la culture de votre entreprise.

  • Discutez d'autres options avec votre service informatique pour colmater le trou qui impliquent des solutions plus rapides qui - bien que non idéales - peuvent atténuer le risque et vous donner une tranquillité d'esprit sans casser la tirelire de l'entreprise. Parfois, une petite quantité de travail peut aider à éliminer une partie du risque, sinon la totalité.

Si les points ci-dessus ne fonctionnent pas, alors je pense à laisser tomber, et je sais que ces problèmes vont juste faire partie intégrante de la gestion des risques de l'entreprise.


2
Je pense que cette réponse ne couvre pas suffisamment le sujet. La nature de la faille de sécurité n'était pas mentionnée dans le PO; pour tout ce que nous savons, cela pourrait permettre aux attaquants de récupérer des informations de carte de crédit dans leur base de données, ce qui peut être désastreux, sans oublier qu'il pourrait avoir des ramifications légales s'il était ignoré.
Daenyth

+1: à la fin de la journée a) il s'agit des coûts par rapport aux avantages et les personnes ayant des droits de décision prendront les décisions et b) la nature de la faille de sécurité n'a pas été mentionnée, mais je parie que la direction en sait bien plus que chacun d'entre nous sur ce forum. Alors oui, OP a soulevé la question et maintenant nous revenons à "la responsabilité du gestionnaire est de gérer les risques"
DXM

@Daenyth - Vous avez absolument raison. Je vous remercie! J'ai ajouté quelques suggestions sous forme de puces pour résoudre le problème, si l'op décidait de poursuivre. Après tout, cela pourrait vraiment être un problème grave et paralysant qui pourrait non seulement affecter la société, mais la sécurité de millions d'utilisateurs.
jmort253

@ jmort253: La mise à jour est bien meilleure - +1 de ma part!
Daenyth

1
Jim, je ne sais pas à quel point vous êtes expérimenté ou combien d'autres emplois de développeur vous avez eus, mais je pense que vous allez rencontrer cela lorsque vous irez ailleurs. Le but de toute entreprise est de réaliser un profit, et je pense que parfois les développeurs qui sont divorcés du côté opérationnel et financier de l'entreprise oublient que le but d'une entreprise est de faire du profit. Pensez également à ceci: votre région n'est pas la seule zone où des risques existent. Peut-être que votre directeur voit un risque encore plus grand de ne pas se concentrer sur la constitution de l'équipe de vente ou de publier un produit ou un plan marketing sensible au facteur temps.
jmort253

10

Si vous avez l'équité, appuyez sur pour planifier une réunion hebdomadaire ou mensuelle pour examiner les problèmes de sécurité et cela peut simplement être un point à l'ordre du jour. Déplacer le focus du problème particulier vers le domaine général est souvent une technique efficace.

Si vous n'avez pas d'équité, passez à autre chose.
Vous avez soulevé la question à la direction et ils ont réussi. Vous pouvez réessayer si c'est important pour vous. Et encore une fois si c'est vraiment important. Si c'est vraiment vraiment très important, trouvez un autre emploi et dites pourquoi aux employeurs potentiels. Ceux qui valorisent le plus l'éthique l'apprécieront probablement.

Gardez également à l'esprit que si vous avez soulevé la question et obtenu un non, vous êtes maintenant confronté à changer d'avis, ce qui est très difficile. Je choisirais de les amener à être d'accord avec vous et à vous donner des oui. Par exemple, "nous voulons tous les deux que l'entreprise réussisse". Oui. "Je sais que nous nous soucions tous les deux de la sécurité". Oui. "Nous savons que nous avons un budget très limité pour traiter de tels articles". Oui. Obtenez-en quelques-uns, puis commencez à vous orienter vers un calendrier pour apporter les correctifs de sécurité.

Une autre approche «plus douce» consiste à convenir que vous n'avez pas le temps / les ressources pour le faire maintenant. Mais pouvez-vous pousser à un accord sur une date à laquelle il sera abordé. Cela peut être dans une semaine, un mois ou 6 mois. Habituellement, le temps passe vite et vous y êtes.


Je ferais en sorte de mettre mon avertissement par écrit et d'en conserver une copie, mais si vous avez fait savoir aux bonnes personnes, vous avez fait ce qu'il fallait. Ce qu'ils choisissent d'en faire, c'est bien leur problème.
Zachary K
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.