Comment les RSSI et les DSI créatifs peuvent-ils innover et transformer leur programme de sécurité ?

Une version de cet article a été publiée sur DevOps.com; il a été renommé et mis à jour pour inclure de nouvelles informations.

Si les RSSI et les DSI ont la position peu enviable d'assumer la plus grande part de responsabilité en matière de sécurité des logiciels, notamment en cas de violation embarrassante des données de l'entreprise, ils bénéficient également d'une opportunité unique de plus en plus pertinente : ils sont les nouveaux innovateurs et peuvent avoir une grande influence en adoptant la bonne approche. Toutes les organisations de la planète, qu'elles soient publiques ou commerciales, se battent pour conserver (et gagner) leur place sur le marché dans un monde qui se numérise rapidement. Les clients s'attendent à une expérience en ligne transparente pour les produits passés et futurs, et une approche commerciale "numérique d'abord" devient obligatoire. Après tout, si ces attentes ne sont pas satisfaites, il y a presque certainement un concurrent prêt à saisir l'occasion.

Qu'est-ce que cela signifie pour le RSSI ou le DSI moderne ? Naturellement, cela signifie qu'ils emploient des équipes de développeurs, chacun créant ligne après ligne le code qui forme leur produit ou service numérique. La cybersécurité, qui est une préoccupation majeure depuis de nombreuses années, est un facteur de risque croissant, car de plus en plus d'activités commerciales sont menées en ligne et se trouvent dans la ligne de mire des attaquants. Les conséquences d'une violation sont énormes, mais il n'est pas possible de se soustraire à la numérisation.

Les RSSI et les DSI créatifs sont dans une position privilégiée pour continuer à tracer la voie de notre avenir numérique, en collaboration avec leurs équipes d'AppSec et de développement. Ils façonneront sans aucun doute l'innovation à long terme des entreprises, des administrations et des services publics en ligne, mais ils ont la lourde responsabilité de trouver un équilibre entre les objectifs de rapidité de mise sur le marché, la qualité élevée des logiciels et l' atténuation des risques de sécurité.

Jusqu'à présent, cet équilibre a été extrêmement difficile à trouver. Il a conduit à des équipes de développement souvent fragmentées, dont l'objectif principal est de fournir des caractéristiques et des fonctions, sans tenir compte des vulnérabilités qu'elles pourraient créer dans le code qu'elles produisent si rapidement. Les spécialistes de l'AppSec corrigent constamment les mêmes erreurs, alors que la menace d'une violation due à une porte dérobée relativement simple laissée ouverte se profile à l'horizon.

Pour que nos données restent en sécurité, les RSSI et les DSI doivent faire preuve de créativité dans la manière dont leurs équipes travaillent ensemble, et forger une culture de sécurité positive et de responsabilité partagée du haut en bas de l'échelle. Il suffit de regarder les conséquences catastrophiques auxquelles Marriott a dû faire face à la suite de la violation de 2018 : Une amende GDPR de plus de 123 millions de dollars, plus de 500 millions d'enregistrements volés et une réputation de sécurité en lambeaux. Ce désastre est en grande partie le résultat direct de pratiques de codage non sécurisées, avec des vulnérabilités d'injection SQL découvertes dès 2014 sur les serveurs de Starwoods, une société acquise par Marriott en 2016. L'utilisation ultérieure du logiciel n'a manifestement pas été contrôlée du point de vue de la sécurité des applications. Les attaquants malveillants ont ainsi eu plusieurs années pour accéder aux données et les acquérir, tandis que d'autres vulnérabilités, comme la faiblesse des mots de passe, ont laissé davantage de failles à exploiter au fil du temps.

Les DSI et les RSSI doivent examiner très attentivement l'état de leur propre climat de sécurité logicielle. Dans quelle mesure le développeur moyen est-il sensibilisé à la sécurité ? Les équipes de développement et d'AppSec travaillent-elles bien ensemble ? Il n'existe pas de solution miracle, mais la culture, la formation et le soutien peuvent être travaillés et améliorés. Les équipes de développement peuvent passer de la première ligne de risque de violation de données dans l'organisation aux super-héros de la sécurité qui arrêtent le mauvais code avant même qu'il n'entre en production.

Bilan de santé du codage sécurisé : Le vôtre est-il sous assistance respiratoire ?

Quelle est la place de votre équipe de développement ? J'ai créé cette liste de contrôle pour aider les DSI et les RSSI à déterminer si leurs équipes de développement sont vraiment équipées pour être des champions du codage sécurisé, contribuant à l'innovation avec un code plus rapide, meilleur et plus sûr (ou, en fait, si vous avez besoin d'une refonte de votre programme de sécurité) :

1. Quel est le degré de soutien du reste de votre équipe de direction ? Comprennent-ils que la sécurité traditionnelle des réseaux ne suffit plus ?

Dans l'avenir des logiciels, sécuriser la couche réseau à l'aide de mesures de sécurité dépassées n'est tout simplement pas suffisant (et, soyons honnêtes, ne réussit que rarement de toute façon), même contre des pirates semi-professionnels. Parmi de nombreux rapports concordants, le "2017 Data Breach Investigations Report" de Verizon indique qu'un pourcentage stupéfiant de 35 % des violations de données sont aujourd'hui causées par des vulnérabilités d'applications web.

La sécurité des applications web est tout aussi importante que la sécurité des réseaux ; si vous ne tenez pas compte de ce fait et si vous ne prévoyez pas de budget pour la couche de protection fondamentale des mesures AppSec et ne l'instaurez pas, vous risquez d'être victime d'une violation.

2. Vous déplacez-vous suffisamment vers la gauche et le faites-vous assez tôt ?

L'approche actuelle de la sécurité des applications est plutôt axée sur les outils et se concentre sur le passage de la droite à la gauche du cycle de vie du développement logiciel (SDLC). Par définition et par conception, cette approche reconnaît que le processus est défectueux et soutient un résultat de détection et de réaction. Les équipes de sécurité recherchent et détectent les vulnérabilités dans le code déjà écrit, réagissant pour corriger le code engagé au lieu de s'assurer qu'il est exempt de bogues au moment de sa création. Selon le National Institute of Standards and Technology(NIST), il est 30 fois plus coûteux de détecter et de corriger les vulnérabilités dans le code validé que de les prévenir au moment où elles sont écrites dans l'IDE. Cela ne prend même pas en compte les retards de production, la double manipulation et le temps passé à remédier aux mêmes problèmes de sécurité bien connus, encore et encore.

Une culture de la sécurité vraiment solide insiste sur le fait qu'il faut commencer par la base, en inspirant des champions de la sécurité au sein de la cohorte des développeurs, tout en donnant à l'équipe de développement les bons outils et la bonne formation pour se développer et agir avec un état d'esprit de codage sécurisé. L'accent est mis sur l'auto-développement continu et sur l'utilisation des muscles de résolution de problèmes afin qu'ils puissent être la première ligne de défense de leur organisation, en empêchant les vulnérabilités courantes de se produire en premier lieu.

3. Faites-vous l'effort de développer des compétences pratiques en matière de sécurité ou vous contentez-vous de transmettre des connaissances à sens unique ?

La grande majorité des solutions de formation à la sécurité (en ligne et CBT) se concentrent sur l'acquisition de connaissances plutôt que de compétences pratiques directement liées à leur travail. Pour que les développeurs s'épanouissent et s'engagent dans l'écriture de codes sécurisés, ils ont besoin d'un accès régulier à un apprentissage contextuel et pratique qui les encourage activement à continuer à se former et à développer leurs compétences dans un environnement réel. Ils doivent se familiariser avec les vulnérabilités récemment identifiées, à l'aide d'exemples de code réels, et être en mesure de travailler dans leurs langages et cadres préférés. Cette expérience d'apprentissage les aide à comprendre comment localiser, identifier et corriger les vulnérabilités connues dans le code sur lequel ils travaillent activement dans le cadre de leur travail.

Bien qu'il existe de nombreux enseignants compétents et de nombreuses informations sur la correction des failles de sécurité, le fait de feuilleter des manuels ou de regarder des heures de vidéo ne parvient pas à mobiliser l'esprit de nombreux développeurs créatifs et capables de résoudre des problèmes et, si l'on en croit le flux constant de violations de données, reste largement inefficace pour empêcher les failles d'entrer dans le code.

4. Mesurez-vous vos compétences en matière de codage sécurisé à l'aide d'indicateurs en temps réel ?

Pour s'assurer qu'une équipe de développement adopte un état d'esprit axé sur la sécurité, il est essentiel de recueillir et d'examiner des preuves. Il ne doit pas s'agir d'une hypothèse ou d'un jeu de devinettes : soit les développeurs sont soucieux de la sécurité, soit ils ne le sont pas.

Les mesures visent à prouver au développeur et à son organisation que son travail acharné porte ses fruits et que ses compétences individuelles en matière de codage sécurisé s'améliorent. Vous ne pouvez pas améliorer ce que vous ne pouvez pas mesurer. Il doit y avoir des évaluations pertinentes, et celles-ci doivent permettre d'identifier les progrès de vos équipes de développement en temps réel ainsi que de comparer leurs forces et faiblesses en matière de codage sécurisé en vue d'une amélioration continue.

Trop souvent, la formation à la sécurité devient un exercice "à cocher" pour les organisations, sans que l'accent soit mis sur l'efficacité, l'engagement ou même la rétention de cette formation.

5. Vos fournisseurs externalisés utilisent-ils des techniques de codage sécurisées et robustes ?

De nombreuses organisations décident de confier des travaux de développement à des agences tierces. Qu'elles existent à l'étranger ou à l'étranger, leurs capacités et leurs pratiques générales en matière de codage sécurisé sont un mystère pour leur client. Dans le meilleur des cas, la seule forme d'assurance qu'une organisation recevra en matière de sécurité sera une déclaration dans le contrat exigeant que le produit à livrer soit "sécurisé". Très peu d'entreprises prennent des mesures pour vérifier en amont les compétences de ces sociétés de développement, courant ainsi le risque de se voir livrer un logiciel qui fonctionne comme prévu, mais qui a été construit sans respecter de bonnes pratiques de codage sécurisé. Pire encore, si l'entreprise acheteuse n'est pas consciente des failles de sécurité inhérentes à l'application, elle risque d'envoyer un logiciel vulnérable dans la nature.

Le scénario le plus courant est que les vulnérabilités sont détectées par des spécialistes de la sécurité (des personnes difficiles à recruter et dont le coût est élevé) et que vous êtes confronté à un retard de la date de mise en service et à d'éventuelles discussions contractuelles sur la question de savoir qui doit payer pour corriger ces faiblesses en matière de sécurité. Toutefois, si vous faites preuve d'intelligence dès le départ et que vous évaluez les compétences en matière de sécurité des applications des développeurs qui vont créer votre prochaine application, vous économiserez beaucoup de retards potentiels, de frustration et d'argent.

6. Vos développeurs connaissent-ils les faiblesses de sécurité les plus couramment exploitées ?

Plus de 85 % des vulnérabilités exploitées dans les applications web sont attribuées à seulement 10 vulnérabilités connues, le Top 10 de l 'OWASP. Votre formation à la sécurité des applications doit au minimum couvrir ces vulnérabilités, ainsi que de nombreux autres types de vulnérabilités. Les défis de formation auxquels vos développeurs sont confrontés doivent être révisés et mis à jour régulièrement, avec de nouveaux défis pour de nouveaux cadres de codage ou de nouveaux types de vulnérabilités.

Une formation précise utilisant des scénarios de codage sécurisés du monde réel devrait être la norme ; de vagues connaissances générales ne sont tout simplement pas efficaces. (Vous vous demandez à quoi pourraient ressembler ces scénarios de codage sécurisé ? Consultez notre série de blogs Coders Conquer Security; chaque article contient un défi à relever).

7. Disposez-vous de champions de la sécurité en interne ?

Toute organisation à forte intensité de développement devrait investir dans un champion de la sécurité - une personne qui va prendre la responsabilité de maintenir une norme de sécurité élevée au sein de l'équipe de développement. Son objectif est de servir de point de contact pour toute personne ayant des questions sur la sécurité et de devenir le principal défenseur du respect des meilleures pratiques en matière de sécurité.

Ils sont une pièce essentielle du puzzle de la culture de la sécurité ; un grand champion de la sécurité peut maintenir l'élan après une formation intensive, s'assurer que tous les membres de l'équipe disposent de ce dont ils ont besoin et continuer à plaider en faveur d'un soutien.

8. Avez-vous investi dans des outils pour vos développeurs afin de faciliter le codage sécurisé ?

Si votre organisation pratique le développement agile, ou si vous êtes confronté à des mises à jour fréquentes des applications développées par l'entreprise, l'automatisation de certaines parties de votre sécurité est l'un des seuls moyens de suivre le rythme effréné et le volume de travail.

Il existe des outils disponibles à chaque étape du cycle de développement durable qui serviront de conseillers, de gardiens de la qualité ou d'outils de détection. En outre, certains outils exécutent des tests automatisés sur le code, simulant des tentatives de piratage une fois que le logiciel est en production. Tous ces outils présentent leurs propres avantages et défis, et aucun ne peut garantir à 100 % qu'aucune menace de sécurité n'existe au sein de l'application. La principale mesure préventive que vous pouvez employer est que plus tôt vous pouvez détecter la faiblesse, plus il est rapide et moins coûteux d'y remédier avec le moins d'impact possible sur votre entreprise.

La prochaine étape pour les RSSI tournés vers l'avenir

Comment votre organisation s'est-elle comportée par rapport à la liste de contrôle ci-dessus ?

Alors que les RSSI et les DSI sont essentiellement contraints de développer agressivement les capacités DevOps et DecSecOps de leur entreprise, cela ne signifie pas qu'il n'y a pas de temps pour envisager et mettre en œuvre les bons outils et la bonne formation au sein des équipes. Les compétences en matière de codage sécurisé seront une arme, et non un obstacle à l'innovation, et le fait d'y renoncer pourrait signifier la destruction absolue de la réputation et des données de l'entreprise. Ces compétences représentent des capacités essentielles et une solution à long terme beaucoup moins coûteuse pour réduire les vulnérabilités et atténuer les risques.

Un RSSI brillant et innovant a le pouvoir d'orchestrer une culture de la sécurité saine depuis le sommet jusqu'à la base ; assurez-vous que votre personnel dispose de ce dont il a besoin pour mettre en œuvre efficacement les meilleures pratiques en matière de sécurité.

Pieter Danhieux est un expert en sécurité et le cofondateur de. Secure Code Warrior.