Si les outils AppSec sont la solution miracle, pourquoi tant d'entreprises ne les utilisent-elles pas ?

Une version de cet article a été publiée dans Revue SC. Il a été mis à jour et diffusé ici.

‍

L'une des nombreuses énigmes auxquelles sont confrontés les spécialistes de la sécurité d'aujourd'hui est de trouver l'équilibre entre les solutions qu'ils utiliseront pour gérer les cyberrisques auxquels ils sont confrontés. Comment répartir le budget entre les outils et les personnes ? Quelle suite d'outils conviendra le mieux à la technologie existante ? Avec autant d'options, il n'y a pas de réponse facile, et choisir les mauvaises options coûtera du temps et de l'argent plus tard.

Un rapport récent a révélé que le marché des outils de sécurité des applications est en pleine évolution une croissance « explosive » d'ici 2025, une indication claire de leur rôle incontesté dans le succès des pratiques DevSecOps et de leur pertinence croissante pour le secteur face à des volumes croissants de code présentant des failles de sécurité potentielles.

Il y a cependant un problème un peu curieux. Près de la moitié des organisations envoient sciemment du code vulnérable, malgré à l'aide d'une gamme d'outils AppSec conçus pour y mettre fin. Pour les produits dont la demande du marché est indéniable et qui gagnent rapidement du terrain, cela n'a aucun sens. Pourquoi tant de personnes achèteraient-elles des outils de sécurité sophistiqués, pour ignorer leurs découvertes ou ne pas les utiliser du tout ? C'est un peu comme acheter une maison en bord de mer pour dormir dans une tente dans les bois.

Les outils AppSec ne sont pas utilisés comme on aurait pu s'y attendre pour plusieurs raisons. Il s'agit moins des outils et de leurs fonctionnalités que de la manière dont ils s'intègrent à un programme de sécurité dans son ensemble.

Plus d'outils ne signifie pas moins de problèmes.

Au fur et à mesure que les entreprises font évoluer leurs processus de développement logiciel, passant d'Agile à DevOps, en passant par le nirvana sacré qu'est DevSecOps (bon, pour l'instant, c'est le meilleur que nous ayons), il est inévitable que plusieurs scanners, écrans, pare-feux et toutes sortes d'outils AppSec soient achetés en cours de route. Bien que cela puisse sembler être une question de « plus en plus, mieux c'est », cela conduit très souvent à une technologie qui ressemble au monstre de Frankenstein, avec toute l'imprévisibilité que cela implique.

Les budgets et les ressources d'experts étant de plus en plus limités par rapport à l'étendue des travaux requis, essayer de résoudre le problème et de trouver la meilleure solution d'outillage est une tâche ardue, et le code à scanner et à corriger ne cesse d'arriver. Il n'est pas étonnant que de nombreuses organisations aient dû conserver le code d'expédition, même si cela est plutôt alarmant, et cela représente toujours un risque immense pour nos données et notre confidentialité.

Les outils de numérisation sont lents, ce qui a un impact sur l'agilité des versions.

La mise en place d'une sécurité rapide est un véritable casse-tête en matière de développement logiciel, et à vrai dire, nous essayons toujours de faire les choses correctement alors même que nous incitons les organisations à adopter une approche axée sur DevSecOps. Une révision manuelle méticuleuse du code aurait pu constituer la solution de sécurité dans les années 90, mais à une époque où nous produisons des centaines de milliards de lignes de code, c'est un plan à peu près aussi efficace que la préparation d'un terrain de football avec une paire de ciseaux à ongles.

Les outils de numérisation automatisent le processus de détection des problèmes potentiels, en effectuant pour nous cette partie méticuleuse de la révision du code. Le problème est qu'ils sont encore lents dans le contexte d'un pipeline CI/CD fonctionnant à plein régime, et aucun outil ne détecte toutes les vulnérabilités. Les résultats transmis à l'équipe de sécurité à la suite d'un scan présentent également quelques problèmes flagrants :

1. Il existe un lot de faux positifs (et négatifs)
2. Un mauvais expert en sécurité doit encore rester là et faire une révision manuelle pour trier les vrais bogues des bogues fantômes
3. Bien souvent, trop de vulnérabilités courantes sont révélées et auraient dû être détectées avant le déploiement du code. Voulez-vous vraiment que vos experts en sécurité, très onéreux, ne se préoccupent pas des gros problèmes de sécurité liés aux petites choses ?
4. Les scanners trouvent, ils ne réparent pas.

Même dans une organisation qui fait de son mieux pour appliquer les meilleures pratiques en matière de cybersécurité et qui évolue avec le temps pour inclure la sécurité à chaque étape du processus, le processus ci-dessus reste un obstacle si les scanners constituent la principale mesure de protection et si trop de bogues courants obligent l'équipe à déployer un code sécurisé. Il va de soi que l'on peut faire des économies dans ce domaine, et cela se traduit généralement par le recours au strict minimum d'outils qui ne peuvent pas couvrir tous les risques potentiels, même si une suite de solutions a été achetée.

Une certaine automatisation technologique peut entraîner une diminution de la qualité du code

L'analyse et les tests supportent la charge des processus automatisés des outils AppSec, ainsi que des éléments essentiels tels que les pare-feux et la surveillance, mais d'autres outils courants peuvent par inadvertance éroder les bases pratiques de sécurité au fil du temps.

Par exemple, la technologie RASP (Runtime Application Self-Protection) est souvent utilisée pour renforcer la posture de sécurité sans sacrifier la vitesse de codage. Il fonctionne dans l'environnement d'exécution d'une application, protégeant contre la saisie de code malveillant, les attaques en temps réel et signalant tout comportement d'exécution étrange.

Il s'agit certainement d'une couche de protection supplémentaire, mais si elle est considérée comme une protection intégrée contre les éventuelles faiblesses de la base de code, les développeurs peuvent faire preuve de complaisance, en particulier lorsqu'ils sont confrontés à des délais de mise sur le marché de plus en plus impossibles à atteindre pour proposer de nouvelles fonctionnalités. Les pratiques de codage sécurisé peuvent ne pas être suivies, en partant du principe que l'autoprotection lors de l'exécution détectera les erreurs. Les développeurs ne font pas tout leur possible pour créer des modèles de codage non sécurisés, mais la sécurité est souvent reléguée au second plan au profit de la fourniture de fonctionnalités, en particulier dans l'hypothèse d'une sauvegarde automatisée.

Les outils peuvent échouer (et dans le cas de RASP, ils sont souvent exécutés en mode surveillance pour éviter les faux positifs, ce qui ne fait que fournir de la visibilité, et non une protection, contre une attaque), et lorsque cela se produit, il s'agit d'un code sécurisé de haute qualité sur lequel on peut se fier à chaque fois. La sensibilisation à la sécurité dans tous les rôles qui concernent le code est fondamentale pour DevSecOps, et les développeurs ne pas suivre de formation ou ne pas produire de code sécurisé sont une erreur. Le code sécurisé et le code non sécurisé demandent le même effort d'écriture ; c'est l'acquisition des connaissances nécessaires pour coder en toute sécurité qui demande de l'énergie. Le temps passé à implémenter et à optimiser RASP peut être bien mieux utilisé pour améliorer les compétences des développeurs afin qu'ils ne commettent pas d'erreur au départ.

Trouver l'équilibre entre les outils et les personnes : ce n'est pas une solution miracle, mais c'est ce que nous avons de plus proche (pour l'instant).

La philosophie principale de DevSecOps est de faire de la sécurité une responsabilité partagée, et pour les organisations qui créent les logiciels qui alimentent nos vies, qu'il s'agisse du réseau électrique ou de nos sonnettes, elles doivent impliquer tout le monde dans le processus afin de garantir un niveau de sécurité plus élevé.

Les outils ne suffiront pas à tout, et ce n'est même pas le moyen le moins cher. Les meilleurs résultats sont de loin obtenus en donnant la priorité à une formation à la sécurité pertinente pour tous ceux qui ont accès au code, en travaillant activement pour que la sécurité soit au cœur des préoccupations de l'équipe de développement et en développant une culture de sécurité positive dirigée par l'homme, avec une suite d'outils qui joue un rôle de soutien.

Malgré les contraintes de temps, les contraintes de coûts et d'autres facteurs qui empêchent les experts en sécurité de dormir la nuit, si les développeurs n'introduisent pas de failles de sécurité courantes dès le départ, ces outils (qu'ils soient utilisés ou non) représentent un facteur de risque bien moindre.

‍