Que font les programmeurs des entreprises de sécurité?


10

J'ai entendu parler de sociétés de sécurité qui consultent sur la sécurité des systèmes d'un client. Toutes les personnes que je connais dans ce domaine sont des ingénieurs réseau, mais je sais que les programmeurs sont également impliqués dans la sécurité. Que font réellement les programmeurs de sécurité qui effectuent des audits / conseils? Parcourent-ils littéralement la base de code à la recherche de toutes les vulnérabilités des systèmes existants des gens? J'ai toujours supposé que c'était ce qu'ils avaient fait, mais il semble que cela ne serait pas très fiable et ne ferait pas beaucoup plus que fournir un faux sentiment de sécurité. Remarque: je ne parle pas des programmeurs qui écrivent des algorithmes de chiffrement ou quelque chose comme ça, seulement ceux concernés par les audits / conseils en sécurité logicielle.


1
N'hésitez pas à parcourir security.stackexchange.com pour un public de beaucoup plus de gens de sécurité!
Rory Alsop

1
^ ce qu'il a dit, nous sommes tous les deux des modérateurs pro tem là-bas.

Réponses:


12

Franchement, nous essayons de ne pas parcourir votre base de code, nous essayons d'écrire des outils pour le faire pour nous.

Tout d'abord, la théorie. La sécurité est une exigence d'un système logiciel, donc comme d'autres exigences (fonctionnalité, utilisabilité, accessibilité, performances, etc.), elle doit être prise en compte à chaque étape du flux de travail d'ingénierie logicielle, de la collecte des exigences au déploiement et à la maintenance. En effet, cela est possible et des conseils existent pour aider les équipes de projet logiciel à le faire. Même si je travaille principalement avec des développeurs iOS, ma description préférée du «cycle de vie de développement sécurisé» provient de Microsoft Press .

Dans ce modèle, la sécurité des applications commence lorsque nous essayons d'obtenir des exigences de nos utilisateurs. Nous devons découvrir leurs préoccupations en matière de sécurité et de confidentialité, ce qui n'est pas facile car nous sommes les experts, pas les utilisateurs, et lorsqu'ils comprennent leurs exigences en matière de sécurité, il peut être difficile de les exprimer. Nous devons également découvrir à quels risques le logiciel sera exposé lors du déploiement et quel niveau de risque est acceptable.

Nous concevons notre application en répondant à ces exigences. Nous écrivons le code dans le but de répondre à ces exigences et d'éviter les risques supplémentaires associés aux erreurs de sécurité au niveau du code. Nous testons le logiciel pour nous assurer que notre modèle de sécurité est cohérent avec ce que nous avons vraiment construit, puis nous déployons le logiciel d'une manière qui correspond aux hypothèses que nous avons faites sur l'environnement lorsque nous avons conçu la chose. Enfin, nous fournissons un support et une maintenance qui aident l'utilisateur à utiliser le logiciel d'une manière cohérente avec ses exigences de sécurité, et qui lui permet (ainsi qu'à nous) de réagir à de nouveaux changements dans les risques présentés.

Ok, tant pis pour la théorie. En pratique , pour des raisons qui sont très bien expliquées (quoique de manière non technique) en géekonomie et qui sont principalement dues à la façon dont les éditeurs de logiciels sont motivés, la plupart des choses ci-dessus ne se produisent pas. Au lieu de cela, nous obtenons cela. Les développeurs:

  • embaucher un gars ou une fille de sécurité pour être présent quand ils soumissionnent pour un contrat, pour montrer qu'ils "obtiennent" la sécurité.
  • écrire des logiciels.
  • embaucher un responsable de la sécurité ou une fille pour valider le logiciel avant sa sortie, corrigeant de nombreux problèmes survenus à l'étape 2.
  • patchez tout le reste après le déploiement.

Alors que la plupart des gens de la sécurité de l' application sont vraiment en train de faire est, comme vous le dites, trouver des bogues. C'est vraiment une revue de code glorifiée, mais c'est une revue de code très ciblée effectuée par des personnes qui sont des experts dans les types de bogues que cette revue recherche, il est donc toujours utile d'obtenir de l'aide extérieure pour le faire. C'est une règle générale de teting, bien sûr: demandez toujours à quelqu'un d'autre de tester qui n'a pas participé à la fabrication de la chose.

Si nous acceptons ce qui précède comme vrai, il s'ensuit que les personnes qui prennent des décisions d'achat assimilent probablement «un gars de la sécurité capable» à «trouve beaucoup de bugs». Ceux qui obtiennent des ordinateurs pour faire le travail pour eux trouveront plus de bogues que ceux qui ne le font pas, alors bien sûr, ils s'appuient fortement sur des outils d'analyse statique et viseront à consacrer plus de temps à étendre les outils qu'à coder pour des problèmes spécifiques pour des clients spécifiques. Nous concluons ensuite que les personnes chargées de la sécurité des applications sont plus susceptibles d'écrire des outils pour lire du code que pour lire du code.

** Attention: ce qui reste, c'est l'opinion personnelle et la spéculation **

La réalité est brisée. Vous remarquerez que la théorie de la sécurité des logiciels consistait à identifier et à répondre au risque de s'appuyer sur un système logiciel, alors que la pratique consistait à trouver autant de bogues que possible. Bien sûr, cela réduira toujours le risque, mais seulement comme effet secondaire. Le but du jeu est devenu moins important que de "gagner" le jeu, donc les règles sont modifiées pour faciliter la victoire.

Que pouvez-vous faire en tant que développeur de logiciels à ce sujet? Jouez le jeu selon ses règles d'origine. Trouvez quelqu'un dans votre équipe (de préférence en fait dans votre équipe, plutôt qu'un entrepreneur, afin qu'ils soient motivés à fournir des résultats à long terme plutôt qu'une victoire rapide) qui comprend l'importance de la sécurité et en forme le bejeezus. Donnez à cette personne la responsabilité de diriger l'équipe en assurant la sécurité de bout en bout décrite au début de ma réponse.

Donnez également à cette personne le pouvoir de poursuivre . Si une conception n'exprime pas les exigences de sécurité, elle doit être révisée. Si l'implémentation ne répond pas aux exigences de sécurité, elle ne doit pas être publiée . Votre responsable de la sécurité peut rendre le jugement, mais doit être autorisé à donner suite à ce jugement. Je me rends compte que cela pourrait ressembler au gars de la sécurité qui dit "la sécurité OMFG est la chose la plus importante", mais ce n'est pas ce que je veux dire. Si votre produit ne répond pas non plus aux exigences de fonctionnalité, de convivialité ou de performances, vous ne devriez pas non plus publier cette chose.

Pourquoi voudriez-vous faire ça? Cela devrait être moins cher: nous avons tous vu (et probablement cité pour un représentant +10 pas cher) le tableau Code Complete où les défauts deviennent plus chers plus tard vous les corrigez, non? Les défauts de sécurité sont également des défauts. I les règles du jeu du monde réel, la plupart d'entre eux sont des problèmes dans les exigences qui sont fixées dans la maintenance. C'est bon marché?

Ok, maintenant, que puis- je faire en tant que pistolet de sécurité à louer? Il se trouve que je peux aussi refuser de jouer selon les règles modifiées. Je peux dire aux développeurs qu'il s'agit de réduire les risques, que cela peut être fait à chaque étape, puis je peux les aider à le faire.


Pour une personne dans votre position, je suis surpris que vous ne puissiez pas en offrir plus à la discussion. Je serais très intéressé à entendre ce que vous avez à dire.
Steven Evers

Tu as raison, j'étais fatiguée (décalage horaire) quand j'ai écrit la réponse. Je vais essayer de le compléter un peu.

@snorfus Je dois m'excuser de ne pas avoir donné une bonne réponse. Je suis sincèrement désolé.

@Graham Lee: Je soupçonnais que vous aviez une excellente réponse cachée :) Vos modifications l'ont prouvé; Merci!
Steven Evers

@snorfus Je devrais vraiment réfléchir avant de poster. Et si je ne suis pas en état de réfléchir, je ne devrais pas poster ...

5

Après 15 ans passés à exécuter des programmes d'assurance de la sécurité contre des applications, des environnements, des systèmes de petite et très grande taille, je dirais qu'il y a un peu de tout. Dans mes équipes, j'en ai toujours eu quelques-uns qui sont des codeurs hardcore.

Au niveau détaillé, certains se résument à un examen très approfondi du code - à titre d'exemple, je travaille actuellement sur une base de code de plusieurs millions de lignes, en utilisant des outils pour réduire les problèmes possibles, puis en examinant chacun pour classer par catégories.

(Certes, je passe le relais aux développeurs pour corriger ou m'expliquer pourquoi le problème ne pose pas de risque)

Mais il s'agit d'un engagement spécifique pour lequel le profil de risque a du sens pour effectuer ce type de travail gourmand en ressources.

Beaucoup plus standard et beaucoup plus rentable essaie de comprendre le profil de risque de l'organisation et de se concentrer sur les risques de haut en bas, par exemple:

  • Appétit pour le risque - impact sur l'entreprise, modélisation des menaces
  • Gouvernance - conformité réglementaire, rapports, etc.
  • Politiques - définitions pour assurer l'efficacité du cadre de gouvernance
  • Processus - techniques et humains
  • Normes - définitions pour chaque contrôle de sécurité
  • Mise en œuvre - comment faire

Le côté programmation ne vient vraiment que dans les deux derniers, avec une révision du code et des tests de pénétration personnalisés. Pour certaines organisations, il est de très faible importance, par exemple si vous avez des contrôles de sécurité en couches qui ont déjà été largement examinés par des pairs (divers types de cryptage, par exemple), alors que vous pouvez vérifier votre implémentation, vous ne revérifiez généralement pas tous les code comme cela a été fait auparavant.


2
I + 1d, mais attention "ou pour m'expliquer pourquoi le problème ne pose pas de risque". Les développeurs trouveront souvent des raisons d'éviter de changer la chose qu'ils ont faite (en parlant en tant que développeur), et en outre peuvent ne pas comprendre les risques des clients. Après tout, ce sont les développeurs qui ont écrit Windows 98 ;-)

@Graham - vous avez dit ce qui ne devait pas être nommé :-) Et j'aime bien votre nouvelle version plus longue! +1
Rory Alsop

oh, c'est vrai. J'ai délibérément dit cela parce que je ne voulais pas nommer Windows 98 mais trois ans plus tôt.

1

Je n'en ai jamais rencontré qui va beaucoup plus loin que de discuter de l'architecture / des meilleures pratiques de manière vague lors de la conception et / ou d'exécuter des suites de tests d'attaque / fritzing / exception contre des projets finis.

Dans presque tous les cas, je peux même dire quels outils ils utilisent par les vecteurs d'attaque qu'ils essaient et la manière dont l'attaque est effectuée après que l'un des audits ait transmis un système existant.

J'imagine qu'il y en a quelques-uns qui prennent réellement le temps d'examiner le code et de faire des tests de critique / boîte blanche, mais je ne les ai pas encore rencontrés dans la vraie vie.


on dirait que l'entreprise pour laquelle vous travaillez est toujours moins chère et prend les hacks, qui parlent un bon jeu mais ne comprennent pas vraiment le point. Outre moi-même et les autres répondeurs ici, j'ai travaillé avec et formé beaucoup de personnes qui le font correctement. Certes, j'en ai probablement rencontré plus du genre que vous avez eu aussi ...
AviD

@avid Je ne voulais pas dire négatif. Je suis certain que si vous avez payé le meilleur prix, vous pourriez trouver suffisamment d'entreprises concurrentes, mais même lorsque vous le faites, vous avez tendance à obtenir beaucoup plus de suggestions pour acheter quelque chose que vous ne le faites pour améliorer / mettre en œuvre quelque chose. CE N'EST PAS UNE MAUVAISE CHOSE en utilisant un produit connu avec un bon dossier de sécurité, c'est mieux quand c'est un bon ajustement pour l'espace problématique. L'OP a spécifiquement mentionné AUDIT, et dans la fourchette que vous payez pour votre audit annuel tiers, vous obtenez les 2e, 3e et 1/2 des 4e points de Rory.
Bill
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.