Pourquoi l’agilité est la clé pour sécuriser les logiciels
4 min read
Les fournisseurs de logiciels doivent configurer et maintenir la sécurité dès le départ plutôt que d’attendre qu’il y ait une violation pour la réparer. Plus il y a de logiciels publiés sans être assurés, plus il y a de chances que les risques de sécurité se transforment en violations à part entière. Ces risques invisibles sont des dettes de sécurité qui doivent être découvertes et traitées avant chaque libération.
La sécurité « Shift left » favorise la mise en œuvre de la sécurité dès le début du cycle de vie du développement logiciel. À partir du moment où la valeur du produit est clairement définie, les chefs de produit doivent tenir compte de la sécurité bien avant que les tests logiciels ne soient effectués. La modélisation des menaces est un excellent moyen de le faire au stade de l’architecture logicielle.
La modélisation des menaces est comme le travail de reconnaissance qu’effectue un braqueur de banque avant d’essayer de pénétrer dans un coffre-fort, de voler l’argent et de s’enfuir sans se faire prendre. Chaque fois que vous concevez des solutions logicielles, il est important d’évaluer des points d’entrée similaires dans le logiciel.
« Quels matériaux ont été utilisés pour sécuriser les fenêtres de la banque ? devient « quelles exigences non fonctionnelles sont implémentées dans l’architecture de sécurité de l’application Web afin que script intersites les attaques ne peuvent pas avoir lieu ? » Ce qui n’a pas été mis en œuvre, c’est la dette de sécurité.
Et si la banque ajoutait une nouvelle aile pour accompagner les clients ? Et si le logiciel ajoutait de nouvelles fonctionnalités prises en charge par de nouveaux microservices ? La dette de sécurité augmente potentiellement à chaque fois qu’il y a une modification du produit ou de son infrastructure.
Les récentes cyberattaques majeures ont mis en évidence la nécessité pour les entreprises d’adopter une zéro confiance modèle de sécurité avec leurs produits et services. Si la banque ne doit pas faire confiance à ses visiteurs ou même à son personnel par défaut – en incorporant des procédures d’identification et d’authentification solides pour accéder à des zones sécurisées telles que le coffre-fort – alors le logiciel ne doit pas faire aveuglément confiance à son propre flux de données interne.
Validation continue de la sécurité
Les professionnels de l’informatique s’attendent à ce que les applications Web et mobiles soient tenues à jour avec les meilleures fonctionnalités. Ils attendent également des résultats sans sacrifier la sécurité. Les violations de données, la conformité réglementaire et le risque de réputation ont créé la nouvelle norme. Les entreprises doivent prendre les menaces de sécurité au sérieux ou perdre la confiance des consommateurs, des entreprises et des régulateurs.
Dans certains contextes, les normes de conformité ne laissent pas la confiance au choix – le Norme de sécurité des données de l’industrie des cartes de paiement exige des audits de conformité pour les réseaux de cartes de paiement via des analyses de vulnérabilité menées par un fournisseur d’analyse approuvé.
Avec l’adoption accrue de modèles de livraison de logiciels agiles soutenir le changement progressif, les entreprises vont-elles demander tests de pénétration pour les sorties qui pourraient se produire toutes les deux à quatre semaines ? Les tests d’intrusion traditionnels offrent une couverture approfondie des tests de sécurité ainsi que des méthodes automatisées de test de sécurité des applications statiques et test dynamique de sécurité des applications, mais une sécurité continue est requise pour des cycles de publication plus courts.
Restez en sécurité pour rester pertinent
La livraison de logiciels et les chefs de produit responsables de la fourniture de logiciels informatiques peuvent maintenir à la fois la pertinence et la sécurité des produits en intégrant la modélisation des menaces, les tests de sécurité des applications et d’autres garanties de conformité dans leur pipeline de livraison existant.
Sans prendre ces mesures pendant le cycle de publication, le risque d’une dette de sécurité toujours croissante reste réel, et pour quoi – juste pour rester pertinent ?
Une fois qu’une cyberattaque se produit, en particulier si elle aurait été facilement évitable, les développeurs informatiques peuvent-ils dire que cela valait la peine de ne pas gérer le risque ? S’ils aplatissent la courbe des risques de sécurité en sécurisant leurs cycles de publication, ils n’auront jamais à demander.
