Comment une grande entreprise commet-elle des erreurs de recrue qui laissent des failles de sécurité? [fermé]

Sony a récemment été piraté avec une injection SQL et les mots de passe de leurs utilisateurs ont été stockés en texte brut. Ce sont des erreurs de débutant. Dans une si grande entreprise, comment cela passe-t-il l'AQ? Comment n'ont-ils pas de meilleures équipes que de savoir mieux que cela?

La taille même de l'entreprise qui a été piratée rend cela différent. Cela nous affecte tous parce que nous pourrions tous un jour nous retrouver dans une équipe qui est responsable de quelque chose comme ça, puis nous obtenons la hache. Quels sont donc les facteurs qui y ont conduit, et comment les prévenir?

La première chose qui me vient à l'esprit est parce qu'ils sont assez grands pour faire croître quelques couches de bureaucratie. Cela signifie, entre autres, que vous n'avez plus de codeurs vraiment intelligents en charge du processus d'embauche, ce qui signifie qu'ils perdent leur capacité à éliminer les programmeurs potentiels et les personnes d'AQ qui sont incompétents. Ce qui conduit à l'écriture de mauvais code et à sa mise en production, et nous savons tous ce qui se passera ensuite ...

Parce que les programmeurs n'ont pas été invités à tester cela et la culture d'entreprise écrasante ne leur a pas donné suffisamment de latitude pour que leur sens de l'éthique professionnelle se manifeste et exige encore quelques semaines pour tester les failles de sécurité. Ou d'insister pour qu'ils soient en sécurité dès le départ.

Parce que le patron ne voulait pas passer quelques semaines supplémentaires à tester les problèmes de sécurité pour ... quelle que soit la raison. Un bonus supplémentaire à la fin de l'année. Présentant Johnson du département suivant. Droits de vantardise. Devoir envers l'entreprise. Paresse. Méfiance à l'égard des conseils du sous-traitant.

Parce que le grand patron a exigé plus de profits et a promu Johnson par rapport à Bob parce que ses chiffres étaient meilleurs plutôt que d'exiger un meilleur produit. Parce que la qualité et la sécurité sont des valeurs difficiles à afficher sur une feuille de calcul. Parce que les entreprises existent pour gagner de l'argent.

De telles choses sont un problème systématique. Cela se résume à "parce qu'ils sont des imbéciles".

Les programmeurs d' édition peuvent éviter d'être la chèvre sacrificielle en signalant un problème à leur patron. Il fera soit la bonne chose et fera un plan pour le réparer, ou vous dira de l'ignorer. S'il ne le résout pas, officialisez-le, demandez-le par e-mail. Utilisez des mots clés relatifs au problème, comme «vulnérabilité», «injection», «violation de sécurité» dans ce cas. Des trucs qu'une recherche d'email ramasserait.

C'est passer la balle. C'est maintenant la responsabilité de votre patron. Si c'est important, comme si des gens vont mourir quand cette chose échoue, passez la tête et portez le problème à l'attention de son patron. Vous pouvez être licencié pour avoir simplement renvoyé la balle, et vous pouvez toujours être licencié même si vous le transmettez, mais c'est la bonne chose à faire. Pas aussi juste que de régler le problème, mais proche.

Plus l'entreprise est grande, plus les décideurs sont éloignés de toute responsabilité réelle.

Connaissant le fonctionnement des entreprises, la conception du site a probablement été confiée à une société de conseil choisie en fonction du prix le plus bas par développeur. Cette entreprise embaucherait à son tour un groupe de personnes aléatoires sur des critères similaires, une personne moyenne restant sur le projet pendant pas plus de 3 mois avant d'être transférée à autre chose.

Comment fait-on des erreurs? Par paresse, manque de connaissances, manque d'expertise, opportunité, manque de processus, etc. Comment éviter les erreurs? Grâce à la diligence, l'expérience, les garanties, etc. Cette situation n'est pas catégoriquement différente des milliers de petites erreurs commises par chaque programmeur; c'est seulement différent dans l'échelle.

Que pouvons-nous en tirer? Pas tant.

Une explication possible est une liste de priorité asymétrique. De nombreuses entreprises avec lesquelles j'ai travaillé ont accordé plus d'importance à la mise sur le marché d'un produit plutôt qu'à la qualité du produit / code qu'elles produisaient. Cet effet est doublé car non seulement les programmeurs sont précipités à la fin, mais il en est de même du département QA (s'ils en ont même un). J'ai également remarqué que cette attitude coïncide avec le passage au produit suivant avant la fin du précédent, ce qui aggrave encore le problème.

Un dénominateur commun à chacune de ces sociétés est la gestion non technique. Les chefs de projet, les responsables informatiques et les chefs de produit, essentiellement tous ceux qui ont leur mot à dire sur le travail de l'équipe de développement, ne sont pas tous techniques et ne comprennent pas l'importance de produire du code sécurisé de haute qualité. C'est quelque chose que je recherche quand j'interviewe avec des entreprises maintenant. Qui détient les règnes de l'asile, des détenus ou des médecins?

Je ne serais pas surpris si quelque chose de similaire, aggravé par une bureaucratie profonde, contribuait aux facteurs de sécurité de Sony et d'autres sociétés.

Les gens travaillent dans de grandes entreprises, et les gens feront des erreurs, que ce soit par ignorance, paresse, mauvaises procédures, mauvaise documentation, etc. La taille de l'entreprise n'affectera que les erreurs dans la mesure où il peut y avoir plus de sources d'erreurs ou d'erreurs.