Les mandats réglementaires peuvent-ils sécuriser le développement de logiciels ?

Les éditeurs de logiciels proposent depuis longtemps des produits incomplets et non sécurisés. Cela se produit pour plusieurs raisons. La rapidité de mise sur le marché a toujours été une priorité commerciale, prenant le pas sur la sécurité, d’autant plus que DevOps est devenu la norme dans les méthodologies de développement de logiciels. Et les logiciels, par nature, sont faciles à mettre à jour et à modifier, de sorte que certains défauts ou oublis pourraient être autorisés à se glisser en pensant que nous pouvons toujours le réparer plus tard.

Contrairement aux constructeurs automobiles qui privilégient l’inclusion de fonctionnalités de sécurité dès le départ (ou font face à la lourde main des régulateurs), les fabricants de logiciels ont généralement mis l’accent sur la rapidité de mise sur le marché comme moyen de rester compétitifs.

Mais l’autre chaussure tombe souvent sur cette approche sous la forme de rappels coûteux, de programmes de correctifs étendus, de failles de cybersécurité et d’autres problèmes. La mentalité de réparer plus tard dans les logiciels est devenue de plus en plus difficile ces dernières années avec l’émergence d’appareils connectés/IoT qui sont plus difficiles à maintenir à jour et ont un impact plus important. Les caméras de surveillance en circuit fermé connectées, par exemple, sont fréquemment chassées et exploitées sur Internet pour espionner les gens. Les appareils Internet des objets (IoT) fonctionnant dans des barrages ou des centrales nucléaires peuvent désormais être piratés (comme on l’a vu au barrage de Bowman Avenue à New York, ou trois entreprises de services publics en Ukraine touchées par le malware BlackEnergy). Et, d’un bout à l’autre, le coût des violations de données continue de monter.

Une Maison Blanche eordre exécutif (EO) à partir de 2021 fait également pression sur les fabricants de logiciels, les professionnels DevOps et DevSecOps pour qu’ils améliorent la qualité, avec un mandat pour les agences fédérales américaines d’imposer le développement de logiciels sécurisés par le biais de leurs contrats et acquisitions dans le cadre des efforts visant à sécuriser la chaîne d’approvisionnement en logiciels. La principale différence entre cet effort et les tentatives précédentes telles que FISMA est la visibilité sur le processus de développement logiciel.

L’attention portée au développement de logiciels sécurisés est un pas dans la bonne direction, mais en fin de compte, il appartient toujours à l’industrie plutôt qu’aux organismes de réglementation de changer l’état d’esprit vers la création de logiciels sécurisés à partir de zéro.

La technologie est plus rapide que les mandats

L’OE représente un changement dans le paysage, exigeant non seulement des produits sécurisés, mais des pratiques de développement sécurisées. Bien qu’elle s’applique officiellement aux agences civiles fédérales et à leurs sous-traitants, les réglementations fédérales et autres mandats gouvernementaux deviennent souvent des normes mondiales, comme cela s’est produit avec le Règlement général sur la protection des données (RGPD), la loi européenne sur la confidentialité et la sécurité.

Mais les mandats réglementaires ne suffisent pas. Ils évoluent souvent trop lentement pour constituer une véritable solution, en particulier dans un environnement de développement logiciel qui évolue progressivement vers des environnements plus agiles et rapides où l’intégration continue et la livraison continue (CI/CD) sont la norme. Les échéanciers des nouveaux règlements exigent généralement une fenêtre de mise en œuvre de deux ans; si une entreprise utilise déjà un produit applicable, il peut s’écouler jusqu’à cinq ans avant qu’elle ne soit tenue d’être en pleine conformité, comme dans le secteur des paiements. À ce moment-là, les éléments clés des meilleures pratiques de l’industrie ont déjà changé. En termes simples, la technologie évolue trop rapidement pour que les organismes de réglementation puissent suivre le rythme.

Qui plus est, les réglementations elles-mêmes pourraient finalement échouer si elles sont perçues comme ayant un coût élevé de conformité. Cela est particulièrement vrai si la technologie utilisée dans le cycle de vie du développement logiciel ne peut pas suivre le rythme des besoins de conformité. À l’appui de l’OE, le National Institute of Standards and Technology (NIST) a publié Projet de publication spéciale (SP) 800-218et, comme c’est la routine, accepté ouvert commentaires publics. Les commentaires des consortiums industriels dans ces situations incluent souvent des considérations sur les coûts de mise en œuvre de nouvelles réglementations et peuvent parfois conduire à atténuer certains aspects, arguant, par exemple, que les nouvelles réglementations font peser une charge injuste sur les petites et moyennes entreprises. L’ensemble final de réglementations peut parfois laisser la porte ouverte à des moyens d’aborder la conformité sans aborder les problèmes qui ont conduit à la réglementation en premier lieu.

Par exemple, le Loi californienne sur la confidentialité des consommateurs (CCPA) est largement salué comme l’ensemble de protections de la vie privée le plus strict du pays, mais il a encore ses faiblesses. La faiblesse la plus souvent citée est que la loi rend extrêmement difficile aux consommateurs de profiter de la nouvelle réglementation lorsqu’ils s’estiment lésés.

L’industrie doit y arriver

En fin de compte, il appartient aux fabricants de logiciels et à l’industrie d’améliorer la sécurité de leurs logiciels. Ils devraient adopter les meilleures pratiques pour intégrer des procédures sécurisées dans la conception, le développement, les tests et la validation de nouveaux logiciels, ainsi que leur déploiement et leur utilisation. NIST Cadre de développement logiciel sécurisé est un exemple de conseils tirés des recommandations de groupes tels que BSA, OWASP et SAFECode. Des groupes industriels, comme le Organisation internationale de normalisation (ISO), pourrait adopter des normes de développement et de certification similaires à celles universellement acceptées Normes UL pour les produits électriques.

La demande croissante de développement sécurisé nécessite un changement substantiel d’attitudes vis-à-vis de la manière dont les logiciels sont créés. Beaucoup de ces choses peuvent être mises en œuvre plus facilement si les organisations investissent plus rapidement dans l’adaptation des nouvelles technologies.

Le paysage des menaces est devenu trop sophistiqué et pernicieux pour que le problème des logiciels non sécurisés soit ignoré. Réparer plus tard n’est plus une option valable si les organisations veulent protéger leurs réseaux et, en particulier, leurs données, qui sont devenues la pierre angulaire des opérations dans tous les secteurs. Bien que les mandats réglementaires soient utiles, le travail incombe en fin de compte à l’industrie du logiciel elle-même et à son consortium de personnes partageant les mêmes idées qui comblent le fossé entre les développeurs et les équipes DevOps d’entreprises concurrentes pour finalement offrir ce qu’il y a de mieux pour les consommateurs.