Pourquoi l’agilité est la clé pour sécuriser les logiciels

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 corriger. Plus il y a de logiciels qui sont publiés sans être assurés, plus les chances sont grandes 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 se produisent. 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’un voleur de banque fait 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 scripts inter-sites (cross-site scripting) les attaques ne peuvent pas se produire? Tout ce qui n’a pas été mis en œuvre, c’est une dette de garantie.

Que se passe-t-il si la banque ajoute une nouvelle aile pour soutenir les clients? Que se passe-t-il si le logiciel ajoute de nouvelles fonctionnalités prises en charge par de nouveaux microservices ? La dette de garantie augmente potentiellement chaque fois qu’il y a un changement au produit ou à son infrastructure.

Les récentes cyberattaques majeures ont mis en évidence la nécessité pour les entreprises d’adopter un zero-trust 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 intégrant des procédures d’identification et d’authentification fortes pour accéder à des zones sécurisées telles que le coffre-fort – 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 atteintes à la protection des données, la conformité réglementaire et le risque de réputation ont créé la nouvelle normalité. Les entreprises doivent prendre au sérieux les menaces à la sécurité ou perdre la confiance des consommateurs, des entreprises et des organismes de réglementation.

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 nécessite des audits de conformité pour les réseaux de cartes de paiement par le biais d’analyses de vulnérabilité effectuées par un fournisseur d’analyse approuvé.

Avec l’adoption accrue de modèles de livraison de logiciels agiles soutenir les changements progressifs, les entreprises vont-elles demander tests de pénétration pour les libérations qui pourraient survenir toutes les deux à quatre semaines? Les tests de stylo traditionnels offrent une couverture de test de sécurité approfondie aux côtés de méthodes automatisées de test de sécurité des applications statiques et test de sécurité des applications dynamiques, mais une sécurité continue est requise pour des cycles de libération plus courts.

Restez en sécurité pour rester pertinent

Les responsables de la livraison de logiciels et des produits 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 assurances de conformité dans leur pipeline de livraison existant.

Sans prendre ces mesures pendant le cycle de libération, le risque d’accumulation constante de la dette de sécurité reste réel, et pour quoi – juste pour rester pertinent?

Une fois qu’une cyberattaque se produit, en particulier une attaque qui aurait été facilement évitable, les développeurs informatiques peuvent-ils dis-le valait la peine de ne pas aborder le risque? S’ils aplatent la courbe de risque de sécurité en sécurisant leurs cycles de libération, ils n’auront jamais à demander.