Informations sur le code sécurisé

Une version de cet article a été publiée dans Lecture sombre. Il a été mis à jour et diffusé ici.

Lorsque je parle de sécurité aux développeurs, l'un de mes mantras est que « le seul code de qualité est un code sécurisé ». Cela reste vrai ; nous aurions peut-être échappé à la catastrophe lorsque des logiciels vulnérables sont apparus dans la nature dans les années 90, mais le risque n'en vaut pas la peine aujourd'hui. Beaucoup ont travaillé d'arrache-pied pour inculquer aux développeurs un état d'esprit soucieux de la sécurité au fil des ans et, ce faisant, ils ont, espérons-le, fait de la sécurité un synonyme de qualité lorsqu'il s'agit d'auto-évaluer leur code.

Après réflexion (et après quelques débats entre pairs), cela simplifie peut-être trop le concept. Il est tout à fait possible de créer un code qui soit effectivement sécurisé, mais qui présente des signes de technique de développement novice ou d'autres problèmes qui le rendent loin d'être idéal.

Notre industrie parle longuement de la notion de « glissement vers la gauche ». À mon avis, il s'agit de « repartir » vers la gauche en permettant aux cohortes d'ingénieurs de partager la responsabilité de la sécurité (en tant qu'aspect de la qualité) et en leur donnant le pouvoir d'effacer les vulnérabilités courantes du bout des doigts (littéralement). À la lumière de cette énigme actuelle, il semble toutefois que les limites doivent être repoussées un peu plus loin.

Un code d'un certain niveau de qualité est par définition également sécurisé, mais tout code sécurisé n'est pas nécessairement de bonne qualité. Commencer « à gauche de gauche » est-il la formule pour garantir des normes de codage purement sécurisées ?

À quoi ressemble un code sécurisé « de mauvaise qualité » ?

Passons la loupe à la loupe à cet extrait de code :

Si nous analysons ce code du point de vue de la sécurité, cet extrait est en effet sécurisé et ne constitue pas un point d'entrée permettant à un attaquant d'exploiter une vulnérabilité d'injection SQL.

S'agit-il d'un exemple de code de haute qualité ? Pas vraiment, malheureusement. Une simple modification de l'argument d'un int (entier) à un Corde value permet à l'utilisateur de saisir librement la requête, contrairement à un nombre qui ne le peut pas. Ce changement, ou un copier-coller aléatoire de la chaîne sql depuis un autre endroit, crée immédiatement un environnement dans lequel des vulnérabilités d'injection SQL sont possibles, avec tous les risques qui y sont associés :

Les mesures de sécurité avaient une portée très limitée ici, alors qu'un développeur plus minutieux (ou expérimenté) aurait peut-être adopté une approche différente et envisagé les implications d'une structure d'arguments inefficace. Un code d'expédition comme celui-ci n'est pas seulement une mauvaise pratique, mais aussi un mauvais exemple pour les autres membres de la cohorte de développement.

La « triple menace » logicielle : forme, fonction, forteresse ?

Une « triple menace » dans l'industrie du divertissement est une personne capable de jouer, de danser et de chanter avec un niveau de compétence tout aussi élevé. Ce sont les personnes redoutées et enviées à chaque audition, et ce sont les licornes d'un espace déjà compétitif. Chaque secteur possède sa propre version d'un exemple exceptionnel de ses produits et services, les logiciels ne faisant pas exception.

Si nous pensons à trois éléments clés des applications qui sont difficiles à équilibrer avec une qualité (élevée) égale, ils peuvent être la fonctionnalité et l'élégance, une sécurité irréprochable et la rentabilité compte tenu de la rapidité de livraison requise. Ce dernier attribut est sans aucun doute un facteur déterminant dans la manière dont les deux autres options sont appliquées, et il peut être le catalyseur d'une baisse de la qualité globale au fil du temps.

Cependant, tous les logiciels doivent-ils fonctionner comme Hugh Jackman, ou pouvons-nous nous en tirer avec Nicolas Cage ? En d'autres termes, si vous pouvez intégrer Wolverine dans votre équipe, vous faites de votre mieux.

Martin Fowler a posé la question, La haute qualité en vaut-elle le coût ? dans le développement de logiciels, en concluant que non seulement cela « en valait la peine », mais que cela coûtait en fait moins cher au fil du temps. La plupart des utilisateurs ne vont pas regarder sous le capot pour déterminer si le code est un gâchis ou si la sécurité a été accordée à tout le reste. Cependant, les utilisateurs des outils perdront un temps précieux à refaire du code bâclé pour ajouter de nouvelles fonctionnalités, à parcourir les principales parties du projet pour comprendre ce qui se passe, ou, dans le pire des cas, à corriger une vulnérabilité qui a été rebondie par l'équipe AppSec et a retardé la production. Passer du temps maintenant à rendre le code à la fois sécurisé et de bonne qualité permet d'éviter bien des soucis futurs, sans parler des coûts liés à la résolution de tâches mal exécutées.

Les développeurs expérimentés soucieux de la sécurité écrivent du code qui conserve leur vision créative et leur capacité à résoudre les problèmes lors de la fourniture de fonctionnalités, en veillant à éliminer les pièges de sécurité courants que les ingénieurs peuvent contrôler à leur stade du processus. Le code sécurisé n'est pas très efficace lorsqu'il est isolé, et c'est pourquoi l'idée de commencer « de gauche à gauche » contribuera à promouvoir une culture de la sécurité considérée comme une seconde nature pour les développeurs, intégrée à leur capacité à fournir des fonctionnalités exceptionnelles avec un risque réduit.

Pour une expérience utilisateur sécurisée, il est essentiel de commencer « de gauche à gauche ».

La sécurité est prise en compte dans l'expérience utilisateur des logiciels depuis longtemps, mais elle s'est clairement soldée par un succès mitigé. Erreurs de configuration de sécurité prises en compte 21 % des violations de données basées sur le cloud au cours de l'année écoulée, des erreurs commises par des amateurs, telles que le stockage de mots de passe en texte clair, ont entraîné de graves pertes de productivité, de revenus et de confiance des clients pour les entreprises concernées.

Cela, et les utilisateurs eux-mêmes peuvent être leur pire ennemi lorsqu'il s'agit de protéger leurs propres données. Beaucoup trop de monde utilisent toujours « mot de passe » comme mot de passe, ou utilisent la même combinaison sur plusieurs comptes sensibles.

Je ne connais aucun développeur qui fasse preuve de souplesse lorsqu'on leur demande de travailler sur un écran de connexion, et ce n'est pas étonnant : concevoir un flux de sécurité robuste et fonctionnel dans lequel les utilisateurs pourront naviguer de la manière qui leur convient le mieux, avec le moins de perturbations possible, est un équilibre délicat.

Si vous introduisez trop d'étapes et de restrictions complexes, les utilisateurs risquent de se déconnecter pour ne jamais revenir (ce qui est un désastre pour une nouvelle application), de créer trop de confusion, et vous pourriez finir par donner à l'équipe d'assistance une migraine collective lorsqu'elle répondra aux questions des utilisateurs qui tentent d'accéder à leur compte. Si vous le faites trop facilement, vous échouerez en quelque sorte sur le plan de la sécurité.

Une expérience utilisateur sécurisée réussie doit intégrer une sécurité renforcée dans un flux logique, présenté de manière à ne pas nuire à tout ce qui est convaincant à propos du logiciel. Vous pouvez certainement atteindre l'objectif qui consiste à coder une fonction de connexion sécurisée, en introduisant toutes sortes de mots de passe complexes, un CAPTCHA, des mini-boss et quatre vagues de zombies, mais s'il s'agit d'un désordre total qui repousse les utilisateurs, c'est passer à côté de la cible.

Jeter les bases de l'excellence logicielle.

En tant que développeur, je sais que la grande majorité d'entre nous sont fiers de notre travail et veulent faire le bon choix. Les aléas tels que les contraintes de temps, les changements brusques de l'objectif actuel ou les correctifs urgents peuvent perturber le flux et entraîner des erreurs, mais la dure vérité est que de nombreux ingénieurs logiciels ne sont pas prêts à réussir.

Commencer « de gauche à gauche » est un concept qui donne la priorité aux développeurs et qui oblige les organisations à sérieusement améliorer leur cohorte d'ingénieurs. Les développeurs sensibilisés à la sécurité valent leur pesant d'or, et le soutien sous forme de formation, de fourniture des bons outils et de la possibilité d'être encadré par des développeurs plus expérimentés favorisera un environnement dans lequel le code est conçu avec une approche axée sur la sécurité, avec la précision et l'attention aux détails nécessaires pour faire passer les logiciels au niveau supérieur.

Êtes-vous prêt à allumer le feu du codage sécurisé en vous ? Relevez le défi.

‍

C'est cette période spéciale de l'année (pour nous, en tout cas) où je pense à notre dernier tour du soleil et à ce qui a été fait au cours des trois cent soixante-cinq derniers jours pour nous préparer à une nouvelle année pleine de croissance, de leçons et d'inévitables imprévus.

Bien que personne n'ait pu prévoir les rebondissements de l'année dernière. Après tout, je pense que la plupart d'entre nous ont affronté plus de courbes que les Los Angeles Dodgers, nous sommes toujours là. Le fait de tourner en longueur n'a pas mis fin aux difficultés de cette année qui ne peut pas être nommée, mais tout autour de moi, je constate la résilience inébranlable des individus, des entreprises et de notre secteur d'activité.

Alors, quels progrès avons-nous réalisés dans notre objectif de sécuriser le code à travers la galaxie ?

Nous avons dynamisé notre gamme de produits.

La plateforme de formation Secure Code Warrior sera toujours au cœur de nos offres, mais nous nous efforçons de créer plus de variété et d'utiliser davantage d'outils choisis par les développeurs.

Nous voulons inciter les développeurs à adopter une approche de codage préventif et sécurisée qui permet à chaque équipe de livrer des logiciels de qualité en toute confiance.

Je suis très fière de détailler ce que notre équipe produit a travaillé si dur pour déployer ; elle s'est fixé des objectifs incroyables tout au long de l'année :

• Nous avons acquis Adversary.io et intégré sa technologie, son équipe incroyablement qualifiée et ses clients professionnels en moins de 9 mois.
• Nous avons franchi une étape incroyable en soutenant plus de 50 langages de programmation, y compris l'infrastructure en tant que piliers du code tels que Docker, Ansible, Terraform, Kubernetes, Powershell et CloudFormation, ainsi que de nouveaux acteurs tels que Rust and Go.
• Apporter les connaissances en matière de sécurité au développeur en publiant de toutes nouvelles extensions pour les actions et les problèmes liés à GitHub, en plus d'Atlassian JIRA Cloud & Server, qui propose un apprentissage contextuel là où les développeurs jouent sans avoir à passer d'une tâche à l'autre
• Guidage du code de qualité en temps réel dans l'IDE avec Senseï, désormais disponible dans Place de marché JetBrains pour que chaque développeur détecte les bogues de sécurité, applique les meilleures pratiques, partage des connaissances et évite les problèmes de performances et les dettes techniques
• Permettre aux entreprises d'interagir plus facilement avec les développeurs et de développer le codage sécurisé en publiant Cours, une toute nouvelle fonctionnalité permettant des parcours d'apprentissage sélectionnés pour atteindre les objectifs les plus pertinents pour une organisation et ses objectifs de sécurité. Nous avons également ajouté Missions, une amélioration intéressante de la plateforme phare, qui place les développeurs dans le siège du pilote d'un exploit. Il s'agit de la prochaine étape d'une approche d'apprentissage échafaudée visant à donner aux développeurs une base viable et durable pour réussir.

... et si vous connaissez des débutants en programmation, ils devraient consulter l'application gratuite Secure Code Bootcamp et commencer leur parcours en matière de sécurité.

Nous avons atterri, nous nous sommes développés, nous avons influencé.

Nous aimons aborder le codage sécurisé de manière légèrement différente et, naturellement, nous espérons que cette philosophie se répandra dans l'ensemble du secteur. Il est important que les développeurs reconnaissent leur capacité à lutter efficacement contre les cyberattaquants, et leur donner le goût de l'apprentissage de la sécurité est l'un des principaux objectifs.

Des milliers de développeurs du monde entier ont participé à nos tournois virtuels, dont plus de 80 ont eu lieu rien qu'en 2020. Nous avons été ravis de voir des gens jouer dans le cadre de L'univers GitHub, mondial Cisco événements, et DevSecCon.

Nous avons examiné nos données et avons constaté que des centaines de milliers d'utilisateurs uniques avaient joué sur notre plateforme en 2020, ce qui est époustouflant quand je pense à nos débuts il y a six ans.

J'ai été très heureuse de constater que nous avions considérablement augmenté notre présence auprès des entreprises du Fortune 1000, chacune d'entre elles étant prête à essayer quelque chose de nouveau dans le cadre de ses programmes de sécurité. Nous avons trouvé une synergie avec les entreprises technologiques en particulier, dont beaucoup ont opté pour le télétravail et ont vu l'intérêt des options de formation à distance.

Team Awesome s'est agrandie et s'est renforcée ensemble.

L'une des évolutions les plus importantes que nous avons connues en tant qu'entreprise au cours de l'année écoulée a été l'acquisition de la société de cybersécurité islandaise, Adversary. Nous avions beaucoup en commun : une position similaire sur l'approche de la cybersécurité axée sur les personnes, des valeurs harmonisées et des produits complémentaires. Nous avons accueilli leur équipe au sein de la nôtre, ce qui nous a permis d'acquérir une expertise et un talent inestimables auprès de personnes formidables.

Nous avons également accueilli John Wilson en tant que vice-président des ventes mondiales, bénéficiant de ses 25 années d'expérience en matière de stimulation de la croissance et de transformation des entreprises de technologie cloud et de cybersécurité en leaders du marché. Ses vastes compétences techniques ont été une force d'innovation dans des entreprises telles que Symantec, Qualys, BlackBerry et Verizon, et nous ne pourrions être plus heureux de le voir opérer sa magie avec nous.

Le manque de bureaux physiques ne nous a pas empêchés d'intégrer soixante nouveaux employés dans cinq pays et de leur permettre de démarrer dès le départ grâce à une assistance virtuelle, des présentations et, bien sûr, le très convoité pack cadeau pour les employés livré à leur porte.

Nous avons poursuivi notre croissance dans tous les départements, tous d'une importance égale dans la réalisation de notre mission mondiale qui consiste à permettre un code de qualité rapidement. Et pourtant, j'ai toujours l'impression que nous ne faisons que commencer.

2021, l'année qui a changé la donne.

J'ai le sentiment depuis longtemps que la société ne se soucie tout simplement pas assez de la cybersécurité, et ce n'est que lorsque quelque chose d'incroyablement radical se produit que nous pouvons voir les choses changer en termes d'action et de sensibilisation.

Avec l'énorme brèche de SolarWinds survenue à la fin de l'année dernière, de plus amples détails apparaissent. L'étendue des dégâts n'est toujours pas connue, mais cet incident pourrait être le catalyseur d'un changement généralisé. Les départements du gouvernement américain sont déjà en train de remanier leurs programmes de sécurité, et le cyberespionnage est un sujet très brûlant pour ceux qui ont beaucoup à perdre.

Nous pouvons toujours mettre un peu de fun dans tout ce que nous faisons, mais le moment est venu de retrousser nos manches et de nous mettre au travail pour vraiment changer les choses.

Chaque développeur soucieux de la sécurité rend notre monde un peu plus sûr contre les cyberattaques, et notre objectif sera toujours de leur donner les connaissances nécessaires pour réussir, et peut-être même aimer ça. Nous travaillons d'arrache-pied chaque jour pour créer des outils que les développeurs choisissent d'utiliser pour en savoir plus sur la sécurité et créer un code de la plus haute qualité. Le code sécurisé devrait être la norme, et nous pouvons tous donner un coup de main pour en faire une réalité.

On dirait que la « conformité en matière de cybersécurité » est à la mode depuis des années, avec une infinité d'articles, d'initiatives et de comités discutant de la meilleure façon dont le monde devrait lutter contre l'énorme bête multimenace qu'est la cybercriminalité.

Le problème, c'est que nous ne semblons pas avoir fait cette de nombreux progrès. À l'échelle mondiale, le coût des violations de données n'a cessé d'augmenter, augmentant de 12 % en cinq ans pour s'établir à environ 3,92 millions de dollars américains par violation en 2019. Alors que notre utilisation d'Internet a explosé en quelques décennies à peine, de nombreuses entreprises ont dû se battre sans armes pour se lancer rapidement en ligne, créer leur boutique et faire face aux conséquences de logiciels non sécurisés, de ressources AppSec limitées et, dans certains cas, d'abus de confiance des clients.

De nos jours, nous sommes irréfutablement plus mûrs. Nous comprenons et discutons longuement de l'ampleur de la menace, les entreprises sont bien conscientes de l'impact qu'une cyberattaque peut avoir sur le sentiment des clients, leur réputation et leurs résultats, et de nombreuses entreprises cherchent activement à améliorer la sécurité des logiciels grâce à des formations à la conformité, à des recrutements qualifiés et, de plus en plus, à des initiatives DevSecOps. Malgré ces énormes avancées, nous ne sommes pas en train de gagner le combat, même pas de près. Il y a eu au moins quatre milliards de disques volés en matière de violations de données rien qu'en 2019.

L'un des ingrédients manquants était une répercussion quelque peu lente (au niveau gouvernemental) sur les normes de cybersécurité, les attentes et les conséquences d'une violation. L'avènement de GDPR a connu un certain essor, du moins en Europe, mais de nombreux organismes gouvernementaux sont en train de rattraper leur retard, et la nécessité soudaine de se conformer rapidement à de nouvelles initiatives de conformité pourrait avoir des effets indésirables à l'avenir.

Des imbéciles se précipitent (vers le mauvais entraînement)

Des directives robustes sous la forme de NIST, de nouvelles réglementations pour État de New York et la création du Conseil britannique de cybersécurité ont toutes été des victoires monumentales pour ceux qui mènent le bon combat pour assurer la sécurité de nos données. Ils reconnaissent les problèmes liés au développement logiciel actuel et prennent des mesures pour guider les organisations sur les normes qu'elles doivent désormais respecter pour être considérées comme éthiques et conformes, en termes de meilleures pratiques de sécurité.

Malheureusement, à ce stade, certains des éléments les plus importants sont un peu trop sujets à interprétation. Par exemple, l'un des mandats de la législation du Conseil britannique de cybersécurité est le suivant :

« Créer une liste définie de certifications et un cadre facile à comprendre expliquant comment elles sont toutes liées entre elles et quelles sont les capacités qu'elles véhiculent, en s'appuyant sur les cheminements de carrière déjà entrepris ».

Bien que leurs initiatives s'amélioreront et se développeront sans aucun doute au fil du temps, si les organisations sont déjà en train d'appuyer sur le bouton de panique et de se lancer dans la formation dès maintenant, elles pourraient bien se retrouver mal équipées pour l'avenir.

Les exigences d'une organisation en matière de cybersécurité évoluent rapidement, et il est peu probable que les solutions de formation statiques puissent endiguer le flux de logiciels non sécurisés au rythme requis. Le paysage évolue plus rapidement qu'un cours traditionnel ne peut être mis à jour, ce qui peut entraîner des difficultés à certains endroits dans le piège des exercices de conformité à cocher ; les développeurs, les sous-traitants et les autres professionnels de la sécurité ne reçoivent pas une formation adéquate, et nous sommes redevenus des cibles faciles.

L'entraînement statique et les outils statiques présentent les mêmes problèmes

Les outils d'analyse statique font partie intégrante du SDLC et font leur travail en analysant des outils de pointe pour les spécialistes AppSec rares et surchargés de travail que l'on trouve dans la plupart des grandes entreprises. Ils font un excellent travail, mais il y a un défaut : aucun outil ne peut détecter toutes les vulnérabilités, prenant en charge la vaste gamme de frameworks de programmation disponibles. C'est également un processus lent, et il suffit d'un bogue de sécurité pour passer entre les mailles du filet pour laisser une porte ouverte à un attaquant.

Avec l'entraînement statique, le problème est similaire. Si les développeurs reçoivent une formation à la sécurité sous la forme d'un cours rigide et « personnalisé », il est très peu probable qu'ils aient suivi le rythme des problèmes de sécurité les plus courants au cours de cette période. Il donne un aperçu de l'époque à laquelle il a été écrit, et il est rarement suffisamment revu, présenté dans la langue et le cadre préférés de l'étudiant, et il n'est pas non plus contextuel aux vulnérabilités auxquelles il est susceptible de faire face dans son travail quotidien. Imaginez que vous essayez de vous souvenir d'une information pertinente contenue dans une vidéo que vous avez regardée il y a des mois, tout en essayant de respecter les délais de livraison et de diffuser du code... il est peu probable que cela se produise.

Les méthodes de formation traditionnelles sont en train d'être réévaluées dans de nombreux secteurs, mais lorsqu'il s'agit de former les développeurs à la sécurité, il suffit de prendre en compte le volume considérable de violations de données que nous subissons encore (en particulier celles qui peuvent être attribuées à des vulnérabilités que nous savons comment éviter en matière de codage depuis des décennies) comme une injection SQL) pour réaliser que nous devons essayer une autre méthode.

Nous avons besoin d'une formation qui dépasse les limites d'un cours linéaire unique, capable de s'adapter aux besoins en constante évolution des meilleures pratiques en matière de cybersécurité.

Entraînement dynamique : la référence absolue

En proposant aux développeurs une solution de formation dynamique, qui peut être adaptée rapidement à l'entreprise, au niveau de compétence individuel et aux évolutions générales du secteur, vous leur fournissez les meilleures bases pour coder en toute sécurité, en gardant la sécurité au premier plan et en agissant dans un esprit conscient de la sécurité.

Une formation qui convient à tous, qui ne sera jamais revisitée et qui ne soit pas engageante au départ sera une perte de temps totale. Malheureusement, cela signifie que vous pourriez finir par acheter impulsivement un programme inefficace pour des raisons de conformité. Il peut être obsolète avant même que vous ne le déployez, ou à peine adapté aux besoins de leur travail quotidien.

L'entraînement dynamique est un outil vivant qui est constamment mis à jour, adapté aux besoins quotidiens, qui engage les utilisateurs à faire preuve d'esprit critique et leur permet réellement d'acquérir des compétences et de résoudre les problèmes.

Alors, à quoi ressemble un programme de formation dynamique dans un contexte de sécurité ?

Il s'agira de :

• De la taille d'une bouchée: Les développeurs peuvent acquérir des compétences par étapes faciles à gérer et beaucoup plus faciles à mémoriser (et surtout à appliquer) que de longs modules de formation et des vidéos
• Pertinent : À quoi sert une formation générique à la sécurité dont les exemples sont en C#, par exemple, lorsque le développeur code principalement en Java ? Toute formation doit s'appliquer directement à leur rôle, leur permettant de voir ce qu'ils doivent trouver et corriger (et, idéalement, éviter en premier lieu) pendant qu'ils codent.
• Actuel : Cela semble évident, mais ce n'est pas souvent le cas. Le paysage de la cybersécurité est en constante évolution, et l'augmentation du code entraîne une augmentation des responsabilités. Pour que les développeurs soient votre première ligne de défense, ils ont besoin d'une formation adaptée aux meilleures pratiques de sécurité modernes.
• Engagement : Ce n'est un secret pour personne que la « sécurité » peut être une corvée pour les développeurs, surtout si cela interfère avec leur flux créatif. Une formation adaptée leur montrera le pouvoir dont ils disposent pour résoudre les problèmes de sécurité quotidiens qui peuvent se transformer en risques énormes, en développant une culture de responsabilité et de sensibilisation à la sécurité.
• Amusant : L'entraînement dynamique est rarement ennuyeux ; il est censé être au moins un peu excitant de par sa conception. Pensez à ce que les développeurs adorent : résoudre des problèmes, rivaliser avec leurs pairs et, comme beaucoup d'entre nous sur le marché du travail, être récompensés et reconnus. Tirez parti de leurs points forts et concentrez-vous sur l'obtention des meilleurs résultats.

C'est une période passionnante pour les ingénieurs logiciels ; ils jouent un rôle essentiel dans l'innovation numérique, contribuent à créer des entreprises extraordinaires et prennent même le monde d'assaut avec leurs propres créations. Cependant, les organismes gouvernementaux et les grandes entreprises étant conscients du rôle qu'ils doivent jouer dans l'établissement de normes en matière de sécurité logicielle, il est important de les soutenir en leur proposant des solutions de formation efficaces et dynamiques qui favorisent l'amour pour le codage sécurisé, et non un exercice bureaucratique à cocher des cases.

Selon une étude d'IBM, il est trente fois plus coûteux de corriger les vulnérabilités après leur publication que de les détecter et de les corriger initialement. Dans cette optique, il n'est pas surprenant que les DSI tournés vers l'avenir mettent en œuvre des pratiques de codage sécurisées. Cela implique de former et d'équiper les développeurs pour qu'ils écrivent du code de manière plus sécurisée dès le départ, ce qui en fait la « première ligne de défense » de leur organisation. Pour mesurer les impacts réels de cette tendance, Secure Code Warrior s'est associé à Evans Data Corp* et a commandé une étude récente sur l'attitude des développeurs à l'égard du codage sécurisé, des pratiques de code sécurisées et des opérations de sécurité. Cette étude révèle que la mise en œuvre de pratiques de code sécurisées est transformatrice pour les entreprises sur plusieurs fronts. Téléchargez votre copie du livre blanc ici.

Codage sécurisé avec plus de confiance et de pleine conscience

Il ne fait aucun doute que la mise en œuvre de pratiques de codage sécurisées sensibilise les développeurs à la sécurité d'une manière qui profite à leurs employeurs. Notre étude révèle que 55 % des développeurs affirment qu'une bonne formation leur a permis de renforcer leur confiance dans leurs techniques de codage, et 53 % ont déclaré qu'une bonne formation leur avait permis d'être plus prudents lorsqu'ils déboguaient et testaient leur propre code. De même, 53 % pensent être devenus plus attentifs à la sécurité lorsqu'ils écrivent du code.

Qu'est-ce que cela nous apprend ? Cela nous indique qu'avec un peu de perfectionnement, les développeurs peuvent devenir votre première ligne de défense.

Sélection d'outils plus intelligente + vitesse de lancement accrue

Lorsque nous avons interrogé les responsables sur les impacts de la formation au code sécurisé, leurs points de vue reflétaient leurs responsabilités managériales. 43 % des responsables ont reconnu que la formation au code sécurisé avait aidé leurs organisations à faire preuve de plus de prudence lors du débogage et des tests de leur code. 47 % ont indiqué qu'une formation de qualité leur avait permis d'être plus sélectifs dans les choix d'outils offrant plus de sécurité. Mais ce qui est peut-être le plus important, 44 % ont indiqué que la formation et les techniques de codage sécurisé avaient permis de gagner du temps et d'accélérer la publication des logiciels, un avantage considérable lorsque la rapidité de mise sur le marché est primordiale.

Productivité accrue à tous les niveaux

Lorsque nous avons demandé aux développeurs comment le codage sécurisé avait contribué à améliorer la productivité, plus de la moitié ont estimé qu'il avait contribué à améliorer la qualité du codage et de la conception des applications.

63 % ont déclaré qu'il réduisait les retouches en prévenant les vulnérabilités récurrentes. 70 % ont déclaré qu'il avait aidé à éliminer les erreurs qui entraînaient des retouches ou des correctifs. 56 % affirment qu'il a amélioré la productivité en matière de débogage et de test. Nous pouvons constater la transformation en cours à plusieurs étapes du cycle de vie du développement logiciel.

Dynamique d'équipe et qualité du code

Les pratiques de code sécurisé ont également un impact sur la dynamique des équipes. Bien que les développeurs apprennent individuellement à coder de manière plus sécurisée, leur code n'existe pas dans le vide. Leur code dépend souvent du travail des autres et vice versa. La mise en œuvre de pratiques de codage sécurisées amène les développeurs à partager et à rechercher des connaissances en matière de codage sécurisé, ce qui améliore la communication entre les développeurs, les développeurs et la direction, ainsi qu'entre l'équipe de développement et ses parties prenantes.

• 60 % des développeurs interrogés pensent que l'utilisation de pratiques de code sécurisées a amélioré leur communication avec les autres développeurs
• 45 % affirment que les contacts avec la direction ont augmenté.

Ces sentiments sont partagés par les managers, mais d'un point de vue différent. 62 % des managers interrogés affirment que les pratiques de code sécurisées les obligent à consacrer plus de temps à la gestion des personnes et contribuent à accélérer la publication du code.

Pour les organisations qui mettent en œuvre des pratiques de code sécurisées, l'augmentation de la communication a un impact transformateur sur la dynamique des équipes, avec un impact positif sur la qualité du code et la rapidité de mise sur le marché.

Passer d'une approche réactive à une approche préventive

Enfin, le code sécurisé a un impact sur la manière dont les développeurs et les responsables de développement appliquent les mesures de sécurité et les indicateurs qui les accompagnent.

Aujourd'hui, 81 % des entreprises s'appuient toujours sur des indicateurs réactifs tels que le nombre de défauts et les indicateurs des scanners pour déterminer la qualité de la sécurité.

Mais ces activités réactives sont de plus en plus complétées par des indicateurs proactifs ou préventifs ou cèdent la place à de tels indicateurs. 67 % des organisations évaluent désormais le niveau de sensibilisation des développeurs au Top 10 de l'OWASP en tant que mesure de leur niveau de préparation en matière de sécurité. Parmi les autres indicateurs proactifs dont l'utilisation augmente, citons :

• Mesurer les compétences des développeurs en matière de sécurité des applications
• Utilisation d'un code pré-approuvé
• Conformité aux exigences réglementaires.

90 % des développeurs sont désormais attentifs à ces mesures préventives. Mais alors que la prise de conscience et la mise en œuvre de pratiques de codage sécurisé augmentent, il reste encore du chemin à parcourir pour en exploiter tout le potentiel.

Où aller à partir d'ici ?

En tant que champion du changement en matière de codage sécurisé, Secure Code Warrior adopte une approche dirigée par l'homme pour vous aider à faire de vos développeurs votre première ligne de défense, et à faire passer votre approche globale de la sécurité de réactive à proactive. Notre plateforme d'apprentissage éprouvée propose une formation contextuelle et pratique dans 52 catégories linguistiques spécifiques au framework, avec des défis qui imitent ceux auxquels les développeurs sont confrontés dans le monde réel. Nous savons par expérience que les développeurs préfèrent la méthode de l'apprentissage par la pratique à la difficulté de l'apprentissage statique basé sur la théorie. Si vous souhaitez voir l'impact transformateur que cela peut avoir sur vos équipes et sur leur capacité à envoyer du code de qualité en toute confiance, réservez une démo dès maintenant.

‍

*Passer de la réaction à la prévention : le nouveau visage de la sécurité des applications Secure Code Warrior et Evans Data Corp. 2020
1. IBM Software Group ; minimiser les défauts de code pour améliorer la qualité des logiciels et réduire les coûts de développement - https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

‍

Partager des livres de cuisine au sein d'une équipe

Lorsqu'une personne crée une recette Sensei pour améliorer la qualité de son code ou sa productivité, tous les membres de l'équipe peuvent bénéficier du partage des livres de recettes.

Sensei propose un certain nombre de mécanismes pour partager des livres de cuisine :

• Stockez les livres de recettes dans le projet sous contrôle de version
• Stockage des livres de recettes dans un dossier partagé
• Stockez des livres de recettes sur Github
• Fichiers compressés via HTTP (s)

En partageant les livres de recettes, Sensei aide les équipes à collaborer sur le partage des connaissances. La collaboration permet d'améliorer la communication et d'intégrer les approches convenues en matière de qualité du code.

Par exemple, partager un livre de recettes :

• aide les membres de l'équipe à partager des recettes utiles entre eux.
• aide les chefs d'équipe à codifier les pratiques de codage convenues, pour le personnel subalterne, afin d'identifier les violations courantes et de trouver une solution rapide à la version convenue.
• favorise une coopération accrue entre les équipes, par exemple une équipe AppSec peut créer des recettes pour mettre en évidence un problème dans le code, et l'équipe de développement pourrait écrire la solution rapide.

Les sections suivantes expliquent comment mettre en œuvre chacun des mécanismes de partage.

Stockez les livres de recettes dans le projet sous contrôle de version

Le dossier .sensei du projet est l'option par défaut lors de la création d'un fichier de livre de recettes.

• `projet : //.sensei`

Tous les livres de recettes et recettes seraient stockés dans un dossier .sensei de votre projet.

L'approche la plus simple pour partager est d'ajouter le dossier .sensei du projet au contrôle de version.

Ensuite, le dossier .sensei peut être géré comme n'importe quel autre artefact de code partagé associé au projet. Les livres de recettes sont stockés en tant que configuration YAML, ce qui facilite leur fusion lors de tout processus de validation et de révision.

C'est l'approche adoptée pour le projet public sensei-blog-examples.

• https://github.com/SecureCodeWarrior/sensei-blog-examples

Le dossier .sensei contient le livre de recettes avec toutes les recettes, et elles sont accessibles à tous ceux qui clonent le référentiel.

Rangez les livres de cuisine dans n'importe quel dossier

Les équipes peuvent également utiliser des livres de recettes stockés dans des emplacements centraux.

L'enregistrement du livre de recettes dans n'importe quel dossier doté d'autorisations d'écriture partagées permettra à toute l'équipe de mettre à jour les recettes et de les importer dans n'importe quel projet sur lequel elle travaille.

L'emplacement serait défini sur le chemin du répertoire.

Stockez les recettes sur Github

Sensei peut également accéder à des recettes stockées dans un dépôt Github. Les dépôts privés et publics sont pris en charge.

Github via SSH

L'accès au référentiel SSH est configuré à l'aide de la syntaxe suivante pour l'emplacement

git@github.com : SecureCodeWarrior/ACookbook.git

Pour que cela fonctionne, le référentiel contiendrait le contenu d'un dossier de livres de recettes.

Il est également possible de configurer la branche et le sous-dossier du livre de recettes, par exemple dans la branche principale du sous-dossier du livre de recettes.

p. ex.

• git@github.com : SecureCodeWarrior/sensei-blog-examples.git|master|.sensei

Une clé SSH doit être configurée pour les référentiels privés.

• https://github.com/settings/keys

Et la clé ne doit pas comporter de mot de passe.

Github via HTTPS

Il est également possible d'accéder aux dépôts publics via HTTPS, et la même syntaxe repo.git|branch|folder est utilisée, par ex.

Pour nos exemples de projets de blog :

• https://github.com/SecureCodeWarrior/sensei-blog-examples.git|master|.sensei

Pour notre ensemble d'exemples de protection de base, nous pouvons ignorer la branche et le sous-dossier car nous obtiendrons la branche principale par défaut et le fichier rules.sensei se trouve dans le dossier racine. :

• https://github.com/SecureCodeWarrior/cookbook-basic-protection-set

Zippé via HTTP (s)

Sensei peut également accéder à des livres de recettes compressés, via HTTP ou HTTPS.

par exemple si j'avais un serveur HTTP écoutant localement sur le port 8000

• http://localhost:8000/rules.sensei.zip

Le fichier zip du livre de recettes doit contenir le contenu d'un dossier de livres de recettes, par exemple le fichier rules.sensei.

Résumé du partage

Sensei prend en charge l'utilisation de plusieurs livres de recettes afin que chaque programmeur puisse disposer de recettes qui favorisent son apprentissage et sa productivité.

Plus important encore, nous savons que les équipes travaillent plus efficacement lorsque les connaissances sont partagées. Le fait de disposer de référentiels d'équipe partagés, par exemple pour un projet ou une bibliothèque spécifique, ou pour un ensemble partagé de modèles de migration, peut contribuer à améliorer la productivité de l'équipe et à codifier l'expérience de l'équipe.

Lorsqu'un livre de recettes est partagé, plusieurs équipes peuvent utiliser le même livre de recettes, ce qui peut également améliorer la collaboration entre les équipes issues de différentes disciplines, par exemple la sécurité des applications ou le développement.

Avec quatre principaux mécanismes de partage disponibles, Sensei propose, espérons-le, au moins une approche que vous pouvez utiliser pour améliorer la collaboration en matière de partage des connaissances.

---

Vous pouvez installer Sensei depuis IntelliJ en utilisant « Préférences \ Plugins » (Mac) ou « Paramètres \ Plugins » (Windows), puis recherchez simplement « Sensei Secure Code ».

Tous les articles du blog Sensei, le code et les recettes sont sur Github en :

•  https://github.com/SecureCodeWarrior/sensei-blog-examples

Pensez à la dernière fois que vous étiez au travail, peut-être au sein d'une équipe de projet logiciel dont les délais étaient impossibles à respecter. Ensuite, votre responsable arrive et vous dit qu'il y a une formation obligatoire en matière de sécurité à suivre, et qu'elle doit être intégrée à votre journée de travail en plus de tout le reste.

Ils le savent, et tu le sais. C'est un énorme PITA, mais pour des raisons de conformité, vous allez regarder des vidéos de formation ennuyeuses en arrière-plan pendant que vous continuez à coder, à vous concentrer sur les deux tâches et à ne consacrer toute votre attention à aucune des deux. Il s'agit d'un scénario courant ; il est très perturbateur et fait perdre du temps à tout le monde. La plupart des formations en matière de sécurité sont trop génériques, et il est facile d'ignorer un élément qui se répète au cours d'une journée de travail et qui n'a aucune valeur réelle.

En tant qu'entreprise, notre objectif est de vous proposer un type de formation à la sécurité de meilleure qualité et plus efficace, et cela est dû au fait que nous savons exactement ce que c'est que de ne pas être engagée par rapport à ce que l'équipe AppSec vous considère comme important, alors que chacune de vos priorités n'est pas alignée. Ce qui est intéressant, cependant, c'est que nous avons commencé à réfléchir à ce que nous pouvions faire pour réduire les obstacles qui vous empêchent de suivre une formation au moment où vous en avez besoin. Même avec notre plateforme complète, certaines étapes vous éloignent de votre travail, à des moments où vous avez encore besoin d'un coup de pouce mais que vous ne pouvez pas consacrer un bloc de concentration à une séance d'entraînement.

Nous avons examiné comment le micro-apprentissage pourrait être mis en œuvre de manière plus fluide dans votre flux de travail, dans l'IDE ou dans l'outil de suivi des problèmes. Et voici ce que nous avons trouvé :

Ceci est basé sur les principes du Just-in-Time (JiT), selon lesquels vous recevez les bonnes informations, au bon moment, pour qu'elles soient immédiatement efficaces et utiles. C'est le contraire de l'approche de l'apprentissage au cas par cas, qui consiste souvent en une surcharge d'informations qui fait perdre un temps et une marge de manœuvre précieux à la création de fonctionnalités.

Un code de qualité est un code sécurisé, et si vous avez besoin d'un assistant de sécurité non invasif avec lequel collaborer de temps en temps, cela vaut peut-être la peine de l'essayer.

Éliminez les obstacles et offrez la formation à votre portée.

La cybersécurité peut intéresser certains, mais pas tout le monde. Et personne ne doit s'attendre à ce que les développeurs deviennent des experts en sécurité. C'est toujours le travail des équipes spécialisées dans la sécurité des applications. Cependant, les développeurs soucieux de la sécurité sont reconnus pour leurs compétences et la protection qu'ils peuvent offrir aux entreprises dès la phase de création de code. C'est un poste très demandé, et vous pouvez en construire les bases au fil du temps grâce au micro-apprentissage contextuel.

Maintenant, si vous considérez la formation intégrée comme Clippy (qu'il repose en paix), il est important de noter que dans le cas des intégrations de Secure Code Warrior, elles sont conçues par des développeurs pour des développeurs. Le facteur d'irritation a donc été pris en compte et effacé.

Vérifions-le en action :

Secure Code Warrior pour Github inspecte le code à la recherche de références CWE (Common Weakness Enumeration) ou OWASP dans les étiquettes, le titre du numéro et le corps des numéros afin d'afficher une formation contextuelle juste à temps. La façon dont cela fonctionne est que si une référence de vulnérabilité est trouvée, un commentaire sera publié sur le problème pour aider à la résolution rapide et à la prévention des vulnérabilités récurrentes. Il s'intègre au problème sans perturber votre processus ni vous faire franchir des obstacles pour trouver une solution.

Et si vous utilisez Jira, le processus est similaire :

Maintenant, pour les superstars en place soucieuses de la sécurité, il est important de se rappeler que ce n'est pas à vous de faire opérer la magie. Vous aurez besoin d'assistance, de formation et d'une raison de prendre la sécurité au sérieux et de l'intégrer à votre propre flux de travail. Heureusement, tout cela fait partie d'un processus DevSecOps fonctionnel, et de nombreuses organisations en prennent déjà note. Pourquoi ne pas prendre une longueur d'avance ?

Téléchargez-les dès maintenant, et dites-nous ce que vous en pensez.

Publié à l'origine dans CSO en ligne

En tant que hacker éthique (semi-retraité), professionnel de la sécurité et passionné d'informatique, on peut dire que je tiens beaucoup à la technologie. Je m'intéresse à la façon dont il a été conçu, à ce qu'il fait et à la manière dont il va améliorer ou rendre certains aspects de notre vie plus efficaces. Je regarde tout le temps « sous le capot » des appareils et je trouve certains des meilleurs (et des pires) exemples de code disponibles. Récemment, j'ai étudié comment mon système de climatisation pouvait être contrôlé à distance à l'aide d'une application Android (imaginez ma surprise lorsque j'ai découvert que n'importe qui sur le réseau WiFi pouvait contrôler cet appareil sans aucune authentification).

La sécurité des logiciels est toujours une priorité pour moi, tout comme le danger très réel que représente notre mode de vie de plus en plus numérique et axé sur le partage d'informations personnelles. Après tout, nous nous trouvons dans un territoire largement non réglementé, non supervisé et parfaitement ignoré. Nous sommes dans le Far West.

En tant que société collective, nous ne cherchons pas à dissimuler la technologie que nous utilisons au quotidien. Bien que des séries télévisées populaires et très acclamées comme Mr. Robot contribuent à sensibiliser le public, nous ne sommes pas soucieux de la sécurité... En fait, la plupart d'entre nous ne savent pas à quel point le logiciel est sécurisé parmi la myriade d'applications, de services et d'objets de plus en plus connectés que nous achetons et utilisons. Ce n'est même pas que nous leur faisons fondamentalement confiance, nous n'y pensons tout simplement pas du tout.

Sony PlayStation Network (PSN), Ticketmaster, Yahoo ! , Facebook, Target : chacune de ces entreprises très utilisées a été victime d'une violation de données. Leur vulnérabilités logicielles ont été exploitées et des millions et des millions de dossiers clients ont été exposés. Ces exemples ne représentent qu'une fraction des violations mondiales qui ont eu lieu au cours des dix dernières années. Ils sont la conséquence coûteuse d'une mauvaise sécurité logicielle qui permet aux malfaiteurs de voler nos précieuses informations.

Lorsque la plupart des gens pensent aux violations de données, ils pensent aux failles de sécurité de l'information. Elles sont considérées comme un cauchemar pour l'entreprise concernée et peu pratiques pour les personnes dont les données personnelles ont été touchées, mais sérieusement, quel est le problème ? Si la sécurité continue d'être ignorée, les conséquences sont-elles vraiment si graves ? Rien cette des événements majeurs se sont produits jusqu'à présent : les violations de données ont de graves répercussions sur les entreprises qui en sont responsables, mais c'est leur problème, non ? Ils perdent des clients, ils perdent la confiance des consommateurs ; en fin de compte, c'est à eux de régler le problème et de payer les dégâts.

La sécurité logicielle doit être la priorité de chaque organisation.

La raison pour laquelle la sécurité logicielle n'est pas la principale préoccupation de toutes les entreprises dotées d'une équipe de développement est assez simple : trop peu de personnes ont perdu la vie et les connaissances sur les risques sont insuffisantes.

Morbide ? Peut-être. Mais c'est la vérité. La réglementation, les normes de construction et l'évolution des lois sont prêtées (par exemple, de la part des agences gouvernementales) lorsqu'il y a un véritable coût humain.

Prenons un pont, par exemple. Les ingénieurs civils (un métier vieux de plusieurs centaines d'années) considèrent la sécurité comme un élément essentiel de la construction d'un pont. Leur approche va bien au-delà de l'esthétique et de la fonctionnalité de base. Chaque pont construit est censé respecter des règles de sécurité strictes, les professionnels du génie civil et la société dans son ensemble apprenant au fil du temps à s'attendre à un niveau de sécurité élevé. Aujourd'hui, un pont qui ne répond pas aux exigences de sécurité est considéré comme dangereux et inutilisable. Il s'agit toujours d'une évolution que nous devons réaliser dans le domaine du génie logiciel.

À titre d'exemple plus moderne, examinons l'industrie du jouet. Les années 1950 ont vu forte hausse de la production et des ventes de jouets grâce au baby-boom de l'après-guerre. Il est intéressant de noter que le nombre de visites aux urgences liées à des incidents liés à des jouets aurait également augmenté au cours de cette période. Des flèches en forme de jouet causaient des blessures aux yeux, de petits jouets (et des pièces détachables de jouets plus grands) étaient ingérés, et fours à jouets destinés aux petites filles étaient capables de chauffer à des températures plus élevées que les fours domestiques ordinaires.

C'était un peu un « Far West » là-bas, avec peu de réglementation, à l'exception de quelques interdictions isolées et de rappels de produits dans les circonstances les plus difficiles. Les fabricants de jouets étaient essentiellement libres de produire les jouets de leur choix, tout problème de sécurité étant généralement signalé après que plusieurs incidents aient déjà été signalés. Ce n'est que lorsque des projets de loi comme Loi sur la sécurité des jouets de 1969 de Richard Nixon ont été promulguées pour que les tests et l'interdiction ultérieure des jouets dangereux soient devenus la norme, aux États-Unis et dans le monde entier. Bien que des accidents puissent toujours se produire, aujourd'hui, le processus général de fabrication des jouets adopte une politique de « sécurité d'abord », et nos enfants courent beaucoup moins de danger potentiel.

En matière de sécurité logicielle, nous sommes actuellement dans le Far West. Hormis les lois et réglementations évidentes en matière de confidentialité (en particulier récemment avec le RGPD) et de protection des données des clients, ainsi que la législation obligatoire en matière de signalement des violations dans certains pays, très peu de choses sont dites et faites dans les entreprises ou la communauté traditionnelles sur le niveau de sécurité intégré aux logiciels. Même ces lois concernent davantage la responsabilité de l'entreprise que les logiciels eux-mêmes réglementés ou soumis à une norme de sécurité obligatoire.

Nous y arriverons, mais il faudra peut-être d'abord emprunter la voie de la destruction.

Gartner estime qu'il y aura 8,4 milliards d'appareils connectés à Internet seront utilisés d'ici 2020; un chiffre qui représente une augmentation de 31 % depuis 2016. Cela inclut l'électronique grand public, ainsi que des équipements tels que les dispositifs médicaux et les équipements spécifiques à l'industrie. C'est une sacrée opportunité pour un hacker.

Imaginez que le logiciel qui fait fonctionner le stimulateur cardiaque de quelqu'un n'est pas sécurisé. Un pirate informatique pourrait entrer par effraction et potentiellement arrêter le cœur de sa victime (vous pensez que c'est ridicule ? Médecins a désactivé le WiFi dans le stimulateur cardiaque de Dick Cheney pour empêcher un éventuel assassinat par piratage informatique). Un four à micro-ondes ou une bouilloire connectés pourrait être explosé à distance (ainsi que toutes sortes d'appareils Internet des objets dont nous profitons chez nous), ou les freins d'une voiture électrique connectée pourraient être désactivés. Cela peut sembler être un film d'action hollywoodien tiré par les cheveux, mais si le logiciel de l'une de ces technologies connectées avancées peut être piraté, nous sommes vraiment confrontés à une catastrophe potentielle, tout comme les menaces que nous avons déjà couvertes avec les ramifications explosives des cyberattaques dans l'industrie pétrolière et gazière.

Nous pouvons prévenir les conséquences désastreuses du piratage informatique alors que nos vies deviennent de plus en plus dépendantes du numérique. Tout commence par susciter l'intérêt des développeurs pour le codage sécurisé et prendre au sérieux la nécessité de développer un état d'esprit et une culture solides en matière de sécurité au sein des équipes de développement.

Votre révolution logicielle commence ici. Le secteur bancaire montre la voie à suivre en adoptant la formation gamifiée pour lutter contre les mauvais codes, dans le cadre d'une approche véritablement innovante qui bouleverse la formation traditionnelle (lire : ennuyeuse). En fait, chacune des six plus grandes banques d'Australie engage actuellement ses développeurs de cette manière, ce qui leur permet de renforcer leur état d'esprit en matière de sécurité. Découvrez ce que notre client, IAG Group, a fait avec son tournoi de niveau supérieur.

Alors que je me rends à San Francisco cette semaine pour assister à la RSA, je me prépare à de nombreuses discussions avec les RISO. Cela peut vous surprendre, mais la conversation avec de nombreux RSSI n'est pas heureuse ces derniers temps.

Ils savent que les risques de sécurité augmentent, mais nombre d'entre eux ne voient pas l'opportunité d'améliorer la sécurité. Ils pensent plutôt que leur organisation est plus susceptible que jamais d'être victime d'une violation de données ou d'une attaque de cybersécurité.

L'un des thèmes les plus fréquemment abordés dans mes conversations régulières avec les CISO concerne leurs préoccupations concernant la pénurie problématique de compétences en cybersécurité.

« Notre équipe de sécurité n'est pas assez importante pour la taille de notre équipe d'ingénierie ou de notre entreprise. »

« Notre équipe de sécurité continue d'être recrutée par des entreprises étrangères qui proposent des salaires extraordinaires et la possibilité de travailler et d'explorer d'autres continents. »

« Nos experts en sécurité sont trop occupés à combattre les incendies pour continuer à développer leurs compétences ».

Ce thème est étayé par plusieurs rapports de recherche, notamment une enquête réalisée par le Ponemon Institute en 2017, selon laquelle le « manque de personnel interne compétent » est arrivé en tête de toutes les autres formes de préoccupations des CISO en matière de cybersécurité en 2018.

Ce déficit critique de compétences en matière de sécurité ne devrait pas disparaître de sitôt, en particulier sur des marchés tels que l'Australie, où les meilleurs talents déménagent souvent à l'étranger et où les lois sur l'immigration compliquent de plus en plus le recrutement d'experts en sécurité étrangers dans le pays.

L'un des aspects intéressants de la pénurie de compétences en Australie est que l'incapacité de recruter des experts qualifiés a conduit à une attention positive au renforcement des compétences en matière de sécurité nationale. Comme Benjamin Franklin était censé l'avoir dit : « L'adversité engendre des opportunités ». Les gouvernements, les établissements d'enseignement, les entreprises et les start-up australiens travaillent sur des programmes visant à développer une gamme de compétences en matière de sécurité au niveau local.

L'adversité des compétences en matière de sécurité a certainement créé des opportunités dans le domaine du développement des compétences de codage sécurisé au sein des équipes de développement internes et externalisées. Étant donné que la plupart des principales failles de sécurité dans le monde peuvent être attribuées à des erreurs de codage et qu'une violation coûte en moyenne 3,6 millions de dollars américains, la sécurité des logiciels représente certainement une partie importante du défi de sécurité. L'une des dépenses les plus importantes (et en augmentation) des budgets de sécurité des applications est consacrée à l'identification réactive de la sécurité des applications et à la correction, les mêmes bogues se reproduisant souvent année après année.

Permettre aux développeurs d'écrire du code sécurisé dès le départ est l'occasion pour les RSSI de prendre le contrôle proactif de la situation en matière de sécurité et d'apporter des améliorations rapides, faciles et mesurables », tant pour les équipes de sécurité que pour les équipes de développement.

Il ne s'agit pas de remplacer les experts en sécurité par des développeurs, mais plutôt d'impliquer les développeurs sur les questions de sécurité, d'intégrer la sécurité dans leur état d'esprit quotidien et de leur apprendre à coder en toute sécurité de manière amusante, efficace et efficiente. Il en résultera qu'une expertise limitée en matière de sécurité pourra être mieux utilisée pour trouver et corriger les bogues complexes et réellement difficiles, plutôt que pour traiter les mêmes anciennes vulnérabilités.

Pour certains RSSI, tout cela peut sembler trop beau pour être vrai, ou trop difficile à mettre en œuvre, mais la vérité est que ce n'est ni l'un ni l'autre. Chez Secure Code Warrior, nous avons vu de plus en plus de RSSI saisir cette opportunité et transformer ainsi la vie professionnelle des équipes de sécurité et de développement.

Les banques australiennes sont l'un des groupes de RSSI qui ont joué un rôle de premier plan au niveau mondial en matière de développement d'un état d'esprit et de compétences solides en matière de sécurité chez leurs développeurs de logiciels. Les banques australiennes ont été les premières à adopter cette approche en 2016 et 2017. Les six plus grandes banques du pays encouragent et mobilisent désormais activement leurs équipes de développement pour développer des compétences de codage sécurisées grâce à notre environnement d'apprentissage en ligne, adapté à votre rythme et gamifié. Les banques examinent également régulièrement les indicateurs et les rapports en temps réel afin de vérifier les forces et les faiblesses de leurs développeurs et de leurs équipes.

Des résultats tangibles et positifs découlent de cette approche, notamment une réduction de l'apparition de vulnérabilités courantes, une sensibilisation accrue des développeurs à la sécurité et une amélioration des relations entre les équipes de sécurité et de développement. Les entreprises qui investissent dans la formation de leurs développeurs à coder en toute sécurité réduiront la pression sur leurs talents actuels en matière de sécurité et réduiront leur exposition à la sécurité logicielle.

Si vous êtes un CISO (ou si vous en connaissez un) et que vous vous sentez déprimé par la situation en matière de sécurité au sein de votre organisation, je vous encourage à réfléchir à un moyen simple de marquer des points d'amélioration de la sécurité positifs et tangibles. Donnez à vos développeurs les moyens d'apprendre à coder en toute sécurité de manière pertinente, positive et amusante. Vos équipes de sécurité et de développement vous en seront reconnaissantes et vous réduirez également les coûts et les retards liés à l'innovation et au développement de produits. Je parie que cela ouvrira la voie à de nombreuses conversations positives sur la sécurité _...

Permettre aux développeurs d'écrire du code sécurisé dès le départ est l'occasion pour les RSSI de prendre le contrôle proactif de la situation en matière de sécurité et d'apporter des améliorations rapides, faciles et mesurables », tant pour les équipes de sécurité que pour les équipes de développement.

En matière de sécurité et de protection de vos données, il est essentiel de réagir rapidement aux derniers développements. Après tout, les piratages et les menaces peuvent survenir à tout moment, il est donc important de rester vigilant. Ici à Secure Code Warrior, nous nous efforçons de vous fournir des informations à jour sur les dernières vulnérabilités, les mesures à prendre pour atténuer les risques et la manière de protéger vos utilisateurs. Tout comme pour les récentes annonces pour vous aider les vulnérabilités de la bibliothèque Spring, nous sommes ici pour discuter de deux vulnérabilités récemment découvertes.

Aujourd'hui, nous nous concentrons sur deux nouvelles vulnérabilités : d'abord, le Server Message Block de Microsoft, connu sous le nom de « Windows RPC RCE », et ensuite, NGINX, connu sous le nom de « LDAP Reference Implementation ».

Lisez la suite pour découvrir ce que nous savons de ces vulnérabilités à ce jour et ce que vous pouvez faire pour atténuer les risques.

Microsoft Windows RPC RCE - CVE-26809

Lors du Patch Tuesday d'avril, Microsoft a révélé une vulnérabilité dans leur fonctionnalité Server Message Block (SMB), en particulier dans la gestion des pièces RPC. Cela peut vous sembler familier, car la vulnérabilité est similaire à CVE-2003-0352, une exploitation utilisée par blaster à vers depuis 2003 !

Quels sont le niveau de risque et de probabilité d'exploitation ?

L'avis de Microsoft indique que la « complexité des attaques » est « faible » et a été évaluée risque d'exploitation être « Exploitation plus probable », le niveau le plus élevé en l'absence d'exploitation prouvée dans la nature.

Il n'existe actuellement aucune exploitation connue, mais en raison de la faible complexité des attaques et de l'évaluation de l'exploitation « plus probable », certains craignent que des acteurs malveillants puissent rapidement et facilement tirer parti des attaques Blaster.

Les chercheurs ont identifié un grand nombre d'hôtes sur l'Internet public avec le port 139/445 accessible, ce qui est assez inquiétant si une exploration à grande échelle devait avoir lieu.

Quelles mesures les utilisateurs doivent-ils prendre pour atténuer les risques ?

Heureusement, il est relativement facile d'atténuer le risque d'être exploité par cette vulnérabilité.

1. Assurez-vous de bloquer l'accès aux ports 139 et 445 depuis Internet et, lorsque l'accès est nécessaire, limitez-le à l'accès interne uniquement. Vous pouvez trouver plus de détails dans la documentation de Microsoft ici.
2. Appliquez les correctifs publiés par Microsoft le 12 avril 2022.

NGINX - Implémentation de référence LDAP RCE

NGINX divulgué le 11 avril 2022, une nouvelle vulnérabilité connue sous le nom de « LDAP Reference Implementation RCE » qui permet l'exécution de code à distance (RCE) sur le système.

En quoi consiste cette vulnérabilité ?

Cette vulnérabilité est unique car elle n'affecte pas le code destiné à être utilisé en production ou sur des systèmes généralement sensibles. Comme l'indique le terme « implémentation de référence » dans le nom, le but du code est plutôt de démontrer comment l'intégration LDAP peut fonctionner dans une configuration NGINX.

Qui est à risque et que devez-vous faire pour protéger votre code ?

Heureusement, NGINX n'est pas vulnérable par défaut. Le risque principal est lié à l'installation de l'extension LDAP. Même dans ce cas, de nombreuses autres conditions doivent également être remplies pour que la vulnérabilité soit exploitable. L'une des mesures que nous vous recommandons de prendre est que si vous utilisez l'implémentation de référence, assurez-vous de passer à une implémentation prête pour la production.

Pour plus de détails, consultez le Divulgation de NGINX.

Des vulnérabilités vous donnent le sentiment d'être exposé ? Nous pouvons vous aider.

Qu'il s'agisse de Windows RPC RCE et de NGINX - LDAP Reference Implementation RCE d'aujourd'hui ou des vulnérabilités Spring du mois dernier, il est clair que vulnérabilités logicielles sont toujours présents.

La plupart des entreprises mettent l'accent sur des stratégies de réponse rapide afin d'atténuer les risques pour le code et les clients, mais cette approche repose sur une approche réactive qui, bien qu'importante, peut vous exposer à des risques. Nous pensons qu'une stratégie proactive visant à créer un code sécurisé, à améliorer les compétences de vos développeurs et à créer une culture axée sur la sécurité est le meilleur moyen de vous protéger contre les menaces.

En mettant l'accent sur la sécurité pilotée par les développeurs dès le début du cycle de vie du développement logiciel, vous bénéficierez d'une protection accrue, d'un déploiement de code plus efficace et d'une économie de temps et d'argent.

Secure Code Warrior est là pour vous aider avec notre solution unique plateforme de formation qui va du contenu pédagogique à l'application pratique des nouvelles compétences que votre équipe est en train d'acquérir.

Découvrez comment Plateforme d'apprentissage Secure Code Warrior peut vous aider à former vos développeurs au codage sécurisé.

‍

‍