Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Pourquoi les vulnérabilités d'Appsec sont rejetées comme étant «théoriques» ou «fausses»

Par Parasoft

28 janvier 2016

6  min lire

Ce contenu a été initialement publié sur Le blog Code Curmudgeon.

By Arthur Hicken, Chef évangéliste chez Parasoft

Dans un post précédent sur les vulnérabilités théoriques d'Appsec, j'ai expliqué comment «c'est théorique» est utilisé à mauvais escient par ceux qui essaient d'éviter de corriger une vulnérabilité de sécurité ou d'en prendre la responsabilité - par exemple, le Violation de Lenovo SuperfishHeartbleed et attaques wifi des compagnies aériennes.

L'idée qu'une vulnérabilité est purement théorique est non seulement ignorante mais dangereuse. Les exploits logiciels se produisent parce que les mauvais acteurs opèrent en trouvant des failles inattendues dans un système logiciel. Pensez-y de cette façon - si vous avez laissé votre porte déverrouillée, est-ce un problème de sécurité? Ou peut-être «Si une porte déverrouillée n'est jamais entrée, est-elle vraiment déverrouillée» si vous êtes philosophe. On pourrait soutenir que le risque est théorique, mais la plupart d’entre nous diraient qu’une telle affirmation est ridicule. (Accessoires pour ceux qui vivent dans une zone où la sécurité des portes n'est pas requise.)

Les vulnérabilités logicielles sont exactement comme les portes déverrouillées. Ils ne sont pas théoriques, ce sont des éléments réels ou des ouvertures dans votre logiciel qui peuvent et seront probablement exploitées. Si nous voulons avoir des applications sécurisées, nous devons grandir et cesser de prétendre que les vulnérabilités auxquelles nous sommes confrontés ne sont pas réelles. Nous devons adopter une approche proactive basée sur l'ingénierie préventive qui traite les vulnérabilités comme des risques réels, ce n'est qu'alors que nous pouvons être en sécurité.

Néanmoins, les gens continuent de justifier d'ignorer les résultats de leurs scanners de sécurité. Comment rationalisent-ils cela? Dans aucun ordre particulier…

Bruit

Bruit, bruit, bruit! Comment vous l'appelez, qu'il s'agisse de faux positifs, de fausses alarmes, de problèmes théoriques, de trop de messages ou de toute autre chose, le bruit est une grande douleur. Jeff dit que la précision est importante et qu'elle l'est effectivement. Mais d'après mon expérience, les développeurs sont extrêmement rapides pour appuyer sur la gâchette «bruit». Ce serait amusant de faire un sondage / quiz avec quelques exemples de code réel et de voir ce que les développeurs en pensent. le quiz de base sur la sécurité des applications au Blog Notes d'AppSec mais n'expose pas les problèmes de connaissance liés à la reconnaissance de véritables vulnérabilités de sécurité dans le code réel. En d'autres termes, reconnaîtriez-vous pourquoi un morceau de code est dangereux si vous le voyiez? J'aimerais voir le quiz qui contient à la fois un bon code et un mauvais exemple de code et la question «problème de sécurité ou ok». C'est plus compliqué qu'il n'y paraît au début, car vous ne pouvez pas simplement avoir un mauvais code et un code fixe, vous avez besoin d'un mauvais code, puis d'un code suspect qui déclencherait probablement une fausse alerte. Maintenant, il y a un vrai test. Si quelqu'un connaît une telle bête ou veut en construire une, assurez-vous de me le faire savoir.

Le bruit peut être encore pire si vous avez de faux objectifs et de faux paramètres. Par exemple, si vous basez le succès sur le «nombre de problèmes trouvés», vous trouverez probablement le plus grand nombre de problèmes sans importance. Il y a de meilleures définitions du succès discutées dans la présentation Théorie de la fenêtre cassée AppSec cela vaut la peine d'être lu. Un exemple rapide est de suivre le succès par le nombre de «failles non trouvées» dans les nouvelles applications.

Un autre point sur le bruit, en particulier dans le domaine de ce que les gens aiment appeler les faux positifs. J'ai la «loi de Curmudgeon sur l'utilité de l'outil d'analyse statique». Plus un outil d'analyse statique est intelligent, plus sa sortie sera perçue comme un faux positif. C'est parce qu'il est facile d'accepter un résultat que vous comprenez, mais si un outil essaie de vous dire quelque chose que vous ne savez pas (c'est-à-dire le résultat le plus utile), vous êtes le moins susceptible de l'accepter. C'est pourquoi je continue à insister sur a) une meilleure présentation des résultats pour expliquer POURQUOI c'est important et b) une meilleure formation.

Mauvais flux de travail ou processus

Ceci est étroitement lié au problème du bruit. Si vous avez un flux de travail, un processus ou une configuration défectueux, votre analyse de sécurité sera pénible. Parfois, cette douleur est du bruit, parfois c'est un effort supplémentaire, un travail lent ou d'autres symptômes. Par exemple, j'avais vu des gens analyser une analyse statique sur du code hérité où la politique d'entreprise était «aucun changement sauf s'il y a un bogue signalé sur le terrain». L'analyse du code que vous n'avez pas l'intention de réparer ou la recherche d'éléments que vous n'avez pas l'intention de réparer contribue certainement au bruit, aux efforts requis et aux coûts.

Le point à retenir est de vous assurer que vos outils sont configurés de manière optimale et que la façon dont ils s'intègrent à votre processus ne cause pas de maux de tête. Je pourrais continuer longtemps sur ce sujet seul, mais nous garderons cela pour un autre jour. Comment savoir si cela cause des maux de tête? Demandez à ceux qui utilisent les outils et à ceux qui doivent aborder la sortie des outils.

Une autre bonne lecture sur ce sujet est Le progrès provient-il des produits ou processus de sécurité où Gunnar Peterson dit "L'ingénierie des procédés est profondément peu sexy. C'est à peu près aussi éloigné du monde glamour des défilés de mode des conférences sur la sécurité que vous pouvez l'imaginer, mais c'est là que les changements réels se produisent. »

Priorisation

Encore une fois, c'est une catégorie étroitement liée au bruit. Le bruit est un symptôme d'un manque de priorité dans les résultats de vos applications. Idéalement, vous stockez toutes les sorties de tous les outils de sécurité de votre arsenal dans un système intelligent basé sur les données qui vous aidera à déterminer les éléments les plus importants. Personne ne veut passer des semaines à réparer quelque chose qui est peu probable et même si cela se produit, les conséquences sont minimes.

La hiérarchisation AppSec doit prendre en compte les risques. Cela arrivera-t-il? Cela se produit-il aujourd'hui? Est-ce difficile à exploiter? Est-ce difficile de prévenir? Plus toutes les autres questions habituelles sur la gestion des risques. Vous savez quoi faire, si vous avez trop de bruit de vos outils, vous devez mettre un peu d'intelligence derrière cela pour arriver à ce qui compte.

Notez que quand je parle de priorisation, je ne veux pas nécessairement dire triage. Le triage implique un processus humain (voir goulot d'étranglement) qui fait des compromis douloureux dans un court laps de temps plutôt qu'un processus réfléchi et ordonné. Dans le Windows cassé présentation que j'ai mentionnée plus tôt Erik Peterson dit «Triage! = Programme de sécurité des applications» et je suis tout à fait d'accord.

C'est pourquoi je suis fan de la tentative de développer des cadres d'application de risque complets. Certains d'entre eux sont les Système commun de notation des faiblesses (CWSS) qui est géré à Mitre. CWSS propose un moyen d'évaluer correctement les résultats de sécurité dans le contexte de votre application, ce qui devrait permettre une meilleure hiérarchisation automatisée. Cela va de pair avec le Cadre commun d'analyse des risques de faiblesse (CWRAF).

Je sais qu'ils sont loin d'être parfaits et qu'ils sont souvent trop compliqués et douloureux à utiliser. La recherche dans ce domaine garantira une amélioration continue et je m'attends à ce qu'elle devienne à terme le moteur essentiel de l'espace d'analyse des applications.

Tester la sécurité dans

Nous avons tous entendu l'adage selon lequel «vous ne pouvez pas tester la qualité dans une application». Ceci est basé sur le troisième principe de Deming «cesser de dépendre de l'inspection pour atteindre la qualité». Au début, beaucoup n'étaient pas d'accord avec Deming, mais aujourd'hui, c'est une vérité acceptée que l'inspection seule ne résoudra pas vos problèmes. Pourtant, dans AppSec, beaucoup pensent que nous pouvons «tester la sécurité dans une application». Cette attitude est facile à reconnaître car elle aboutit à des processus de sécurité complètement orthogonaux au développement et mis en évidence par le fait que toutes les activités de sécurité sont des activités de type AQ ​​post-développement. Cette méthode ne fonctionnait pas pour la qualité et ne fonctionnait pas pour la sécurité.

Afin de devancer les problèmes de sécurité des logiciels, nous devons commencer par créer des logiciels sécurisés. Il y a un excellent site sponsorisé par le gouvernement américain appelé Construire la sécurité dans et il contient de nombreuses informations intéressantes pour vous aider à démarrer. Jetez également un œil à la Construire un modèle de sécurité à maturité. Je me rends compte que c'est plus facile à dire «Intégrer» ce qu'il est de faire réellement et que le construire apporte ses propres défis. Mais comme la fabrication et la qualité, c'est le seul moyen d'obtenir une amélioration durable à long terme.

Entrainement

Les Institut SANS a fait un enquête sur les programmes et pratiques de sécurité des applications et a trouvé

«Bien que les fournisseurs continuent d'améliorer la vitesse et la précision des outils SAST et de les rendre plus faciles à utiliser, les développeurs ont besoin d'une formation en sécurité ou de l'aide d'un expert pour comprendre ce que les outils leur disent, quelles vulnérabilités sont importantes, pourquoi elles doivent être corrigées et comment répare les."

Le rapport note que seulement 26% des organisations avaient une formation sur le codage sécurisé qui fonctionnait bien ou qui était obligatoire. En outre, il lit

«Un manque de connaissances et de compétences freine les programmes Appsec aujourd'hui et empêche les organisations de faire de réels progrès dans Appsec à l'avenir. Le principal obstacle au succès signalé dans l'enquête de cette année est la pénurie de personnel qualifié, qui fait partie d'un problème plus important auquel est confronté le secteur de la sécurité informatique en général, comme le montrent des études récentes de Forrester Research13 et (ISC) 214.

Une formation et une formation sont nécessaires pour remédier à cette pénurie de compétences, non seulement pour former davantage de spécialistes d'Infosec et d'Appsec, mais également pour former des développeurs et des gestionnaires. Moins d'un quart des répondants ont des programmes de formation qui sont en cours et qui fonctionnent bien, et la formation au codage sécurisé se classe en bas de la liste des pratiques dont les organisations dépendent dans leurs programmes Appsec aujourd'hui. Cela doit changer. "

OWASP parle de la importance de la formation

«Du point de vue de la sécurité des informations, l'approche holistique de la sécurité des applications devrait inclure, par exemple, une formation à la sécurité pour les développeurs de logiciels ainsi que pour les responsables et responsables de la sécurité…

enquête en 2010 a montré que la formation à la sécurité n'était pas dispensée et je soupçonne que peu de choses ont changé aujourd'hui.

«Près de 80% du personnel des agences gouvernementales et des sous-traitants ont déclaré que leur organisation ne fournissait pas une formation et des conseils suffisants pour le développement et la livraison d'applications de sécurité logicielle, selon une nouvelle enquête.»

Résumé

Les outils seuls et la précision des outils ne répondront pas pleinement aux problèmes d'AppSec. Encore une fois, à partir de l'enquête Sans

«Il n'y a pas d'outils de nouvelle génération ou d'autres balles d'argent à l'horizon qui résoudront le problème des logiciels sécurisés. L'écriture de logiciels sécurisés repose sur des principes fondamentaux: une conception réfléchie, un codage minutieux, des tests disciplinés et une gestion informée et responsable. Plus tôt les organisations comprendront et commenceront à le faire, plus tôt elles résoudront leurs problèmes de sécurité. "

Les fausses alarmes et la précision sont un énorme problème. Il en va de même pour le manque de formation. Je ne voudrais pas dire que l'un est plus important que l'autre, car je pourrais facilement me retrouver à discuter des deux côtés. Les deux sont importants. Jusqu'à ce que nous ayons un outil de sécurité parfait, ce qui signifie pas de fausses alarmes et tout aussi important, pas de faux négatifs, la formation jouera un rôle essentiel dans la sécurité des applications (appsec) et la sécurité des logiciels (swsec).

Par Parasoft

Les outils de test de logiciels automatisés de pointe de Parasoft prennent en charge l'ensemble du processus de développement logiciel, depuis le moment où le développeur écrit la première ligne de code jusqu'aux tests unitaires et fonctionnels, jusqu'aux tests de performance et de sécurité, en exploitant des environnements de test simulés en cours de route.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.