La plupart des entreprises s’appuient sur des équipes internes de développement de logiciels pour traduire leurs besoins en un produit fiable et sûr qui pourrait leur apporter un avantage concurrentiel. Cependant, les rapports les plus récents sur la cybersécurité suggèrent toujours que les logiciels sont pour la plupart non sécurisés, plus de 80 % d’entre eux présentant des vulnérabilités élevées et critiques, malgré une prise de conscience croissante des risques.
Comment cela se fait-il ? Parce que la sécurité des applications est souvent boulonnée plutôt qu’intégrée. Examinons de plus près les interactions typiques entre un chef de produit, une équipe de développeurs et un RSSI au cours d’un projet et voyons à quel point cela peut être frustrant…
Le propriétaire du produit
En tant que responsable de produit, vous comptez sur les développeurs pour apporter un avantage concurrentiel à votre entreprise. Vous écrivez des histoires et attendez des développeurs qu’ils écrivent du code et des algorithmes, qu’ils connectent des systèmes et qu’ils produisent de la valeur pour vos clients. Dans cette phase, tous vos efforts visent à décrire ce que fera votre produit. Malheureusement, certains malfaiteurs attendent déjà la sortie de votre solution innovante. Ils espèrent que certaines vulnérabilités leur permettront de voler des données qui seront vendues sur le marché noir.
Les développeurs
Sur la base de toutes les informations fournies par le propriétaire du produit, les développeurs ont commencé à écrire du code. Ils ont résolu des problèmes complexes et proposé une solution innovante. Ce fut un travail d’équipe difficile, et ils sont fiers du résultat final. Leur produit a une belle interface et fonctionne à merveille. Il est tout à fait prêt pour la production. Il ne manque plus qu’un agrément de sécurité.
Le RSSI
C’est généralement à ce moment-là que vous, en tant que RSSI, apprenez l’existence de ce nouveau projet passionnant. Il vous incombe désormais de protéger l ‘entreprise contre les risques inhérents à l’innovation. Votre meilleure option est de demander un test de pénétration, qui finira par trouver des vulnérabilités importantes et critiques, comme c’est habituellement le cas dans de telles circonstances. Le logiciel doit être remédié : c’est un « No Go » pour la sécurité.
Conséquences
Du point de vue du Product Owner, c’est beaucoup trop cher. Les budgets étant limités, la remédiation est rarement complète. Il s’agit en fin de compte d’un compromis entre les risques et les coûts. Cela explique peut-être pourquoi plus de 80 % de tous les logiciels sont encore à risque.
À ce stade, pour le RSSI, la seule façon de réduire le risque pour l’entreprise est d’ajouter de plus en plus de contrôles compensatoires.
Une approche différente de la sécurité des applications
Mais voici la bonne nouvelle : les entreprises ne sont pas condamnées à produire des logiciels risqués. En introduisant des tests automatisés de sécurité des applications dans leur SDLC (cycle de vie du développement logiciel), elles peuvent produire des logiciels plus sûrs à moindre coût , car les mesures correctives sont moins coûteuses lorsqu’elles sont prises au cours de la phase de développement.
Non seulement elle réconciliera les visions uniques des entreprises, de la sécurité et du développement, mais elle amorcera une révolution positive où la sécurité sera l’affaire de tous, car elle sera obtenue par la collaboration plutôt que par l’imposition.
Si vous souhaitez en savoir plus sur la façon dont nous pouvons relever vos défis avec notre méthode Secure SDLC, nous vous invitons à participer à notre conférence lors d’Infosecurity Belgium 2020 « Developers : your first line of defense against cyber threats ».
A propos de l’auteur :
Développeur de formation, Eric Lefèbvre a passé plus de 20 ans à travailler avec des équipes de développement web. Avant de rejoindre Approach en tant que Consultant principal en matière de sécurité, il a dirigé avec succès le programme international des champions de la sécurité chez Thomas Cook.
