Comment les RSSI et DSI créatifs peuvent 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.

Bien que les CISO et les CIO occupent la position peu enviable de devoir assumer la majeure partie de la responsabilité en matière de sécurité logicielle, surtout en cas de violation de données embarrassante pour l'entreprise, ils bénéficient également d'une opportunité unique de gagner en pertinence : ils sont les nouveaux innovateurs et peuvent être très influents avec la bonne approche. Chaque organisation sur la planète, qu'elle soit publique ou commerciale, se bat pour conserver (et gagner) des parts de marché dans un monde qui se numérise rapidement. Les clients attendent une expérience en ligne fluide de la part des produits passés et futurs, et une approche commerciale « axée sur le numérique » devient obligatoire. Après tout, si ces attentes ne sont pas satisfaites, il y a presque certainement un concurrent prêt à saisir l'occasion.

Alors, qu'est-ce que cela signifie pour le CISO ou le CIO 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é, bien qu'étant une considération majeure depuis de nombreuses années, est un facteur de risque croissant à mesure que de plus en plus d'opérations commerciales sont menées en ligne et sous le regard des attaquants. Les implications d'une violation sont énormes, mais renoncer à la numérisation n'est pas une option.

Les CISO et CIO créatifs sont idéalement placés pour continuer à tracer la voie de nos futurs numériques, en collaboration avec leurs équipes AppSec et de développement. Ils façonneront sans aucun doute l'innovation à long terme des entreprises, du gouvernement et des services publics en ligne, mais ils portent la lourde responsabilité de trouver un équilibre entre les objectifs de mise sur le marché rapide, la haute qualité logicielle et l'atténuation des risques de sécurité.

Cet équilibre a été, jusqu'à présent, extrêmement difficile à atteindre. Cela a conduit à des équipes de développement souvent fragmentées, avec un objectif principal général axé sur la livraison de fonctionnalités, sans considération pour les 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, tandis que la menace d'une violation due à une porte dérobée relativement simple laissée ouverte plane au-dessus de tous.

Si nous voulons que nos données restent en sécurité, les CISO et les CIO 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 sommet à la base. Il suffit de regarder les conséquences catastrophiques subies par Marriott à la suite de leur violation de 2018 : une amende RGPD de plus de 123 millions de dollars US, plus de 500 millions d'enregistrements volés et une réputation en matière de sécurité en lambeaux. Ce désastre est survenu en grande partie en raison 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 Starwood, une société acquise par Marriott en 2016. Leur utilisation ultérieure du logiciel n'a clairement pas été contrôlée du point de vue de la sécurité des applications. Cela a donné aux attaquants malveillants plusieurs années pour accéder aux données et les acquérir, tandis que d'autres vulnérabilités, comme des mots de passe faibles, ont laissé davantage de failles à exploiter au fil du temps.

Les CIO et les CISO doivent examiner très attentivement l'état de leur propre climat de sécurité logicielle. Quel est le niveau de sensibilisation à la sécurité du développeur moyen ? Dans quelle mesure les équipes AppSec et de développement travaillent-elles bien ensemble ? Il n'y a pas de solution « baguette magique », mais la culture, la formation et le soutien peuvent être travaillés et améliorés. Les équipes de développement peuvent passer du statut de première ligne de risque de violation de données dans l'organisation à celui de super-héros de la sécurité qui arrêtent le mauvais code avant même qu'il n'atteigne la production.

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

Où se situe votre propre équipe de développement ? J'ai créé cette liste de contrôle de codage sécurisé pour aider les CIO et les CISO à déterminer si leurs équipes de développement sont réellement équipées pour être des champions du codage sécurisé, contribuant à innover 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 niveau de soutien de votre direction générale ? Comprennent-ils que la sécurité réseau traditionnelle ne suffit plus ?

Dans l'avenir du logiciel, sécuriser la couche réseau à l'aide de mesures de sécurité obsolètes ne suffit tout simplement pas (et, soyons honnêtes, est rarement efficace de toute façon), même contre des pirates semi-professionnels. Parmi de nombreux rapports cohérents, le « Data Breach Investigations Report 2017 » de Verizon cite que 35 % des violations de données aujourd'hui sont causées par des vulnérabilités des applications Web.

La sécurité des applications Web est tout aussi importante que la sécurité réseau ; ignorer cela et ne pas prévoir de budget pour instaurer la couche de protection fondamentale et de base des mesures AppSec pourrait vous laisser véritablement vulnérable à une violation.

2. Allez-vous assez loin vers la gauche, et le faites-vous assez tôt ?

L'approche actuelle de la sécurité des applications est très axée sur les outils, se concentrant sur le passage de la droite vers la gauche dans le cycle de vie du développement logiciel (SDLC). Cela, par définition et par conception, reconnaît que le processus est défectueux et favorise un résultat de détection et de réaction. Les équipes de sécurité recherchent et détectent les vulnérabilités dans un code déjà écrit, réagissant pour corriger le code validé au lieu de s'assurer qu'il est exempt de bogues dès 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, le double traitement et le temps passé à remédier aux mêmes problèmes de sécurité bien connus encore et encore.

Une culture de sécurité vraiment robuste insiste sur le fait de commencer par la gauche, en inspirant des champions de la sécurité au sein du groupe des développeurs, tout en donnant à l'équipe de développement les bons outils et la formation nécessaire 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'exercice de leurs capacités de résolution de problèmes afin qu'ils puissent être la première ligne de défense de leur organisation, empêchant ainsi l'apparition de vulnérabilités courantes.

3. Faites-vous l'effort de développer des compétences pratiques en 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 sur des compétences pratiques directement liées à leur travail. Pour que les développeurs puissent s'épanouir et s'engager dans l'écriture de code sécurisé, 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 en apprendre davantage sur les vulnérabilités récemment identifiées, avec des exemples de code réels, et être capables de travailler dans leurs langages et frameworks préférés. Cette expérience d'apprentissage est efficace pour les aider à 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 beaucoup d'informations sur la correction des vulnérabilités de sécurité, feuilleter des manuels ou regarder des heures de vidéo ne parvient pas à engager l'esprit de nombreux développeurs créatifs et résolveurs de problèmes, et si le flux constant de violations de données est une indication, cela reste largement inefficace pour empêcher les vulnérabilités de pénétrer dans le code.

4. Mesurez-vous vos compétences en codage sécurisé avec des métriques en temps réel ?

Une étape essentielle pour garantir l'instauration d'une culture axée sur la sécurité au sein d'une équipe de développement consiste à collecter et examiner des preuves. Il ne doit s'agir ni de suppositions ni de conjectures : les développeurs ont une mentalité orientée sécurité, ou ils ne l'ont pas.

Les indicateurs visent à prouver aux développeurs et à leur organisation que leurs efforts portent leurs fruits et que leurs compétences individuelles en matière de codage sécurisé progressent. On ne peut améliorer ce que l'on ne peut mesurer. Il est nécessaire de mettre en place des évaluations pertinentes qui permettent de suivre en temps réel la progression de vos équipes de développement, tout en identifiant leurs forces et leurs faiblesses en matière de codage sécurisé pour une amélioration continue.

Trop souvent, la formation à la sécurité devient un exercice purement formel pour les organisations, sans aucune garantie que cette formation ait été efficace, suivie ou même retenue.

5. Vos prestataires externes utilisent-ils des techniques de codage sécurisé robustes ?

De nombreuses organisations choisissent de sous-traiter leurs activités de développement à des agences tierces. Qu'elles soient locales ou délocalisées, leurs capacités et pratiques générales en matière de codage sécurisé restent souvent un mystère pour le client. Dans le meilleur des cas, la seule assurance reçue par l'organisation est une clause contractuelle exigeant que le livrable soit « sécurisé ». Très peu d'entreprises prennent des mesures pour vérifier les compétences de ces prestataires en amont, courant ainsi le risque de recevoir un logiciel fonctionnel selon le cahier des charges, mais développé sans respecter les bonnes pratiques de codage sécurisé. Pire encore, si l'entreprise cliente ignore les failles de sécurité inhérentes à l'application, elle risque de mettre en circulation un logiciel vulnérable.

Le scénario le plus courant est que les vulnérabilités soient détectées par des spécialistes de la sécurité (des profils rares et coûteux), ce qui entraîne un retard de mise en production et d'éventuelles discussions contractuelles sur la prise en charge des coûts de correction. Cependant, si vous anticipez en évaluant les compétences en sécurité applicative des développeurs chargés de créer votre prochaine application, vous vous épargnez de nombreux retards potentiels, frustrations et dépenses inutiles.

6. Vos développeurs connaissent-ils les failles 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 failles connues, le Top 10 de l'OWASP. Votre formation en sécurité applicative doit au minimum couvrir ces vulnérabilités, ainsi que bien d'autres types de failles. Les défis de formation proposés à vos développeurs doivent être révisés et mis à jour régulièrement, avec de nouveaux exercices adaptés aux nouveaux langages de programmation ou aux nouveaux types de vulnérabilités.

La formation de précision basée sur des scénarios réels de codage sécurisé devrait être la norme ; les connaissances générales vagues sont tout simplement inefficaces. (Vous vous demandez à quoi pourraient ressembler ces scénarios ? Consultez notre série de blogs Coders Conquer Security ; chaque article propose un défi interactif).

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

Chaque organisation comptant de nombreux développeurs devrait investir dans un « champion de la sécurité », une personne responsable du maintien d'un haut niveau de sécurité au sein de l'équipe de développement. Son rôle est d'être un point de contact privilégié pour toute question liée à la sécurité et de devenir le principal promoteur des meilleures pratiques en la matière.

Ces champions sont un élément vital de la culture de sécurité ; un bon champion peut maintenir la dynamique née d'une formation intensive, s'assurer que tous les membres de l'équipe disposent des ressources nécessaires et continuer à plaider pour un soutien accru.

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

Si votre organisation pratique le développement agile ou si vous êtes confronté à des mises à jour fréquentes de vos applications internes, l'automatisation d'une partie 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 à chaque étape du cycle de vie du développement logiciel (SDLC) qui servent de conseillers, de gardiens de la qualité ou d'outils de détection. De plus, certains outils effectuent des tests automatisés sur le code, simulant des tentatives de piratage une fois le logiciel en production. Tous présentent leurs propres avantages et défis, et aucun ne peut garantir à 100 % l'absence totale de menaces de sécurité dans l'application. La mesure préventive numéro un est la suivante : plus une faille est détectée tôt, plus sa correction est rapide, économique et moins impactante pour votre activité.

La prochaine étape pour les RSSI visionnaires

Alors, comment votre organisation s'en est-elle sortie face à cette liste de contrôle ?

Bien que les RSSI et les DSI soient contraints de développer agressivement leurs capacités DevOps et DevSecOps, cela ne signifie pas qu'il n'y a pas de temps pour envisager et mettre en œuvre les outils et la formation adéquats au sein des équipes. Les compétences en codage sécurisé seront un atout pour l'innovation, et non un frein ; les négliger pourrait entraîner la destruction pure et simple de la réputation et des données de l'entreprise. Ces compétences représentent des capacités critiques et une solution à long terme bien plus économique 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 sécurité saine du sommet à la base ; assurez-vous que votre personnel dispose de ce dont il a besoin pour appliquer efficacement les meilleures pratiques de sécurité.

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