En discutant avec des prospects, vous en apprendrez davantage qu’en lisant des études de marché. Des interactions récentes (malheureusement encore virtuelles) avec des clients ont clairement montré que les entreprises avaient besoin d’une sécurité efficace.
1. Définition d’une sécurité efficace
Inutile de réinventer la roue à chaque fois. Le développement d’applications modernes, les architectures de fourniture et les cadres opérationnels offrent une flexibilité maximale aux équipes de R&D. En outre, des services, modules et fonctions prêts à l’emploi sont disponibles et faciles à intégrer. Il y a cependant un problème qui complique tout : il faut garantir la disponibilité de l’application, ainsi que l’intégrité et la confidentialité de ses données.
Rien n’est plus facile que d’acheter une solution de sécurité : il suffit de choisir la technologie adaptée aux menaces. C’est la gestion de cette solution qui est plus compliquée. En premier lieu, les avantages d’une telle solution rétablissent l’équilibre entre sécurité et productivité pour les équipes de développement. En conséquence, les entreprises bénéficient de cycles de lancement plus rapides et de nouvelles capacités de commercialisation à coût réduit, ce qui permet aux équipes de développement et de fourniture d’applications (AD&D) d’exercer une plus grande influence sur les décisions relatives à la sécurité. Une sécurité efficace doit figurer dans votre cahier des charges. Autrement dit, ne cassez rien et ne provoquez aucune perturbation ni aucun ralentissement.
[Sur le même thème : Pourquoi les DevSecOps doivent s’efforcer de mettre en place des mesures de coercition efficaces]
2. Une sécurité efficace doit détecter
Différentes approches permettent d’intégrer les technologies de protection des applications dans le pipeline CI/CD. Chacune d’entre elles tente de répondre au besoin de rapidité et de minimiser l’impact sur l’environnement, qu’il s’agisse de la latence, de l’empreinte en termes de ressources ou des coûts liés à la charge de travail. Dans la plupart des cas, les approches « conviviales pour les développeurs » présentent au moins une ou deux lacunes :
1. La solution ne couvre pas entièrement la surface d’attaque
2. La solution n’applique pas de manière active des mesures contraignantes de sécurité
1. Les menaces qui pèsent aujourd’hui sur les applications ne se limitent pas à l’exploitation de failles de code et de logique (qui constituent déjà un problème plus que suffisant en termes d’analyse et de gestion). Le suivi des vulnérabilités connues, des protocoles d’authentification et d’autorisation les plus récents et des différentes façons de les pirater représente déjà une tâche énorme.
Les applications actuelles – surtout dans les environnements de développement modernes – recourent largement aux API pour partager et utiliser des données sensibles, qui sont elles aussi vulnérables et nécessitent une technologie dédiée de précision pour s’assurer qu’il n’y a pas d’utilisation abusive ou excessive de jetons, ni de vol de données par injection.
Hormis la sécurité des API, de nombreux services reposent sur l’intégration ou la gestion de bots, et doivent pouvoir distinguer clairement les bons bots des bots malveillants. Pour être accepté par le service de développement et de fourniture d’applications, le système d’autoprotection des applications au moment de l’exécution (RASP) devient vulnérable à certaines attaques, comme le déni de service.
2. Du point de vue du DevOps, l’application de mesures de sécurité contraignantes est risquée. Cela peut affecter l’expérience utilisateur ou même interrompre le flux, entraînant des erreurs d’exécution. Le cycle de vie du développement logiciel (SDLC) présente de nombreuses failles en matière de sécurité, surtout dans l’architecture hybride et multi-cloud actuelle. Pour cette raison précise, de nombreuses technologies génèrent des alertes, ce qui est appréciable.
[Sur le même thème : Pourquoi les DevSecOps doivent s’efforcer de mettre à exécution des mesures de sécurité efficaces]
3. Une sécurité efficace doit protéger
On constate une certaine lassitude à l’égard des outils qui ne fournissent que de la visibilité. Les tests de sécurité automatisés, les scanners de vulnérabilités des serveurs Web, les systèmes d’exploitation et même les images de conteneurs ne parviennent pas à faire respecter les règles de sécurité, ce qui oblige le développeur à prendre un peu de recul et à appliquer des correctifs. Lorsque de telles alertes affluent, il est beaucoup plus difficile de les classer par ordre de priorité et de les traiter toutes.
Une version déjà lancée est de l’histoire ancienne pour les équipes de développement, jusqu’au moment où un membre de l’équipe de sécurité vient demander de corriger une vulnérabilité. Si vous pouvez détecter une menace, bloquez-la. Veillez simplement à détecter tout le spectre des menaces. Personne ne désire un trop grand nombre de solutions ponctuelles, car cela n’équivaut pas nécessairement à une posture de sécurité robuste.
4. Une sécurité efficace doit rester efficace
La nature dynamique d’un SDLC agile, assorti de modifications et de mises à jour fréquentes de l’application, peut rendre les politiques de sécurité moins pertinentes au fil des jours. Ce processus n’est pas extensible et nécessite un équivalent temps plein pour mettre à jour les règles, établir une liste blanche et traiter les exceptions.