Avec le manque de ressources et la limitation des taux, la vulnérabilité de l'API agit presque exactement comme elle est décrite dans le titre. Chaque API dispose de ressources et d'une puissance de calcul limitées en fonction de son environnement. La plupart d'entre elles doivent également répondre à des requêtes d'utilisateurs ou d'autres programmes qui leur demandent d'exécuter la fonction souhaitée. Cette vulnérabilité survient lorsque trop de demandes arrivent en même temps et que l'API ne dispose pas de suffisamment de ressources informatiques pour traiter ces demandes. L'API peut alors devenir indisponible ou ne plus répondre aux nouvelles demandes.

Les API sont vulnérables à ce problème si leurs limites de taux ou de ressources ne sont pas définies correctement, ou si les limites ne sont pas définies dans le code. Une API peut alors être surchargée si, par exemple, une entreprise connaît une période particulièrement chargée. Mais il s'agit également d'une vulnérabilité en matière de sécurité, car des acteurs menaçants peuvent délibérément surcharger les API non protégées de requêtes afin de mener des attaques par déni de service (DDoS).  

Au fait, comment vous débrouillez-vous jusqu'à présent avec les défis gamifiés de l'API ? Si vous souhaitez tester vos compétences en matière de gestion d'une vulnérabilité limitant le débit, entrez dans l'arène :

Allons maintenant un peu plus loin.

Quels sont les exemples de manque de ressources et de taux qui limitent la vulnérabilité de l'API ?

Cette vulnérabilité peut se glisser dans une API de deux manières. La première est qu'un codeur ne définit tout simplement pas les taux d'étranglement d'une API. Il peut y avoir un paramètre par défaut pour les taux d'étranglement quelque part dans l'infrastructure, mais s'y fier n'est pas une bonne politique. Au contraire, les taux de chaque API doivent être définis individuellement. Cela est d'autant plus vrai que les API peuvent avoir des fonctions et des ressources disponibles très différentes.

Par exemple, une API interne conçue pour servir quelques utilisateurs seulement peut avoir un taux d'étranglement très bas et fonctionner parfaitement. En revanche, une API publique faisant partie d'un site de commerce électronique en direct nécessiterait très probablement un taux exceptionnellement élevé pour compenser l'éventualité d'une augmentation soudaine du nombre d'utilisateurs simultanés. Dans les deux cas, les taux d'étranglement doivent être définis en fonction des besoins prévus, du nombre d'utilisateurs potentiels et de la puissance de calcul disponible.

Il peut être tentant, en particulier avec les API qui seront très probablement très occupées, de définir les taux comme illimités afin d'essayer de maximiser les performances. Cela peut être réalisé avec un simple bout de code (à titre d'exemple, nous utiliserons le framework REST Python Django) :

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

Dans cet exemple, les utilisateurs anonymes et ceux qui sont connus du système peuvent contacter l'API un nombre illimité de fois, sans tenir compte du nombre de demandes au fil du temps. C'est une mauvaise idée car, quelle que soit la quantité de ressources informatiques dont dispose une API, les attaquants peuvent déployer des éléments tels que des réseaux de zombies pour ralentir l'API, voire la mettre hors ligne. Dans ce cas, les utilisateurs valides se verront refuser l'accès et l'attaque sera couronnée de succès.

Élimination des problèmes de manque de ressources et de limitation du débit

Chaque API déployée par une organisation devrait avoir ses taux d'étranglement définis dans son code. Il peut s'agir de délais d'exécution, de la mémoire maximale autorisée, du nombre d'enregistrements par page pouvant être renvoyés à un utilisateur ou du nombre de processus autorisés dans un délai donné.

Dans l'exemple ci-dessus, au lieu de laisser les taux d'étranglement ouverts, ils pourraient être définis de manière stricte, avec des taux différents pour les utilisateurs anonymes et les utilisateurs connus.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

Dans le nouvel exemple, l'API limiterait les utilisateurs anonymes à 200 demandes par heure. Les utilisateurs connus qui ont déjà été contrôlés par le système bénéficient d'une plus grande marge de manœuvre, avec 5 000 requêtes par heure. Mais même eux sont limités pour éviter une surcharge accidentelle aux heures de pointe ou pour compenser la compromission d'un compte d'utilisateur et son utilisation pour une attaque par déni de service.

Une dernière bonne pratique à prendre en compte est d'afficher une notification aux utilisateurs lorsqu'ils ont atteint les limites d'étranglement et d'expliquer quand ces limites seront réinitialisées. Ainsi, les utilisateurs valides sauront pourquoi une application rejette leurs demandes. Cela peut également s'avérer utile si des utilisateurs valides effectuant des tâches approuvées se voient refuser l'accès à une API, car cela peut signaler au personnel d'exploitation qu'il est nécessaire d'augmenter la limitation.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

La vulnérabilité relative à l'exposition excessive de données se distingue des autres problèmes d'API figurant sur la liste de l'OWASP, car elle concerne un type de données très spécifique. Les mécanismes de cette vulnérabilité sont similaires aux autres, mais l'exposition excessive de données, dans ce cas, est définie comme impliquant des données légalement protégées ou hautement sensibles. Il peut s'agir d'informations personnelles identifiables, souvent appelées IPI. Il peut également s'agir d'informations relatives à l'industrie des cartes de paiement (PCI). Enfin, l'exposition excessive aux données peut inclure toute information soumise aux lois sur la protection de la vie privée, telles que le règlement général sur la protection des données (RGPD) en Europe ou le Health Insurance Portability and Accountability Act (HIPAA) aux États-Unis.

Comme vous pouvez l'imaginer, il s'agit d'une source de préoccupation majeure et il est impératif que les développeurs avisés apprennent à éliminer ces bogues dans la mesure du possible. Si vous êtes déjà prêt à affronter un dragon de l'exposition des données, rendez-vous à notre défi ludique :

Quel est votre score ? Poursuivez votre lecture pour en savoir plus :

Quels sont les exemples d'exposition excessive aux données ?

L'une des principales raisons pour lesquelles une exposition excessive des données se produit est que les développeurs et les codeurs n'ont pas suffisamment d'informations sur le type de données que leurs applications utiliseront. Pour cette raison, les développeurs ont tendance à utiliser des processus génériques dans lesquels toutes les propriétés des objets sont exposées aux utilisateurs finaux.

Les développeurs supposent parfois que les composants frontaux filtrent les données avant d'afficher les informations aux utilisateurs. Pour la plupart des données génériques, cela pose rarement un problème. Mais l'exposition de données légalement protégées ou sensibles aux utilisateurs dans le cadre d'un identifiant de session, par exemple, peut entraîner de gros problèmes, tant du point de vue de la sécurité que du point de vue juridique.

Pour illustrer la facilité avec laquelle des données sensibles peuvent être accidentellement partagées, le rapport de l'OWASP envisage un scénario dans lequel un agent de sécurité a accès à des caméras IOT spécifiques dans un établissement. Ces caméras surveillent peut-être des zones scellées et sécurisées, tandis que d'autres caméras montrant des personnes sont censées être réservées aux gardes ou aux superviseurs disposant d'autorisations plus élevées.

Pour permettre au gardien d'accéder aux caméras autorisées, les développeurs peuvent utiliser un appel API comme le suivant.

/api/sites/111/caméras

En réponse, l'application enverra des détails sur les caméras que le gardien est en mesure de voir dans le format suivant :

{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}

À première vue, cela semble fonctionner parfaitement. Le gardien, qui utilise l'interface utilisateur graphique de l'application, ne verrait que les flux de caméras qu'il est autorisé à voir. Le problème est qu'en raison du code générique utilisé, la réponse API réelle contiendrait une liste complète de toutes les caméras de l'établissement. Toute personne reniflant le réseau et capturant ces données, ou compromettant le compte du gardien, serait en mesure de découvrir l'emplacement et la nomenclature de chaque caméra sur le réseau. Il pourrait alors accéder à ces données sans restriction.

Éliminer l'exposition excessive aux données

La clé de la prévention d'une exposition excessive des données est la compréhension des données et des protections qui les entourent. Créer des API génériques et laisser au client le soin de trier les données avant de les afficher aux utilisateurs est un choix dangereux qui conduit à de nombreuses failles de sécurité évitables.

Outre la compréhension des protections des données pertinentes, il est également important d'arrêter le processus consistant à tout envoyer à un utilisateur à l'aide d'API génériques. Par exemple, les codes tels que to_json() et to_string() doivent être évités. Au lieu de cela, le code doit sélectionner spécifiquement les propriétés qui doivent être renvoyées aux utilisateurs autorisés et envoyer exclusivement ces informations.

Pour s'assurer qu'aucune donnée protégée n'est accidentellement partagée, les entreprises devraient envisager de mettre en œuvre un mécanisme de validation des réponses basé sur un schéma, en tant que couche de sécurité supplémentaire. Ce mécanisme doit définir et appliquer les données renvoyées par toutes les méthodes de l'API, y compris les règles de signalement des erreurs.

Enfin, toutes les données classées comme contenant des PII ou PCI, ou des informations protégées par des réglementations telles que GDPR ou HIPAA, doivent être protégées à l'aide d'un chiffrement fort. Ainsi, même si l'emplacement de ces données est divulgué dans le cadre d'une vulnérabilité d'exposition excessive des données, il existe une bonne ligne de défense secondaire qui devrait protéger les données même si elles tombent entre les mains d'un utilisateur malveillant ou d'un acteur de la menace.

Consultez les pages du blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre entreprise contre les risques de fraude. Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Il n'est pas étonnant que l'authentification brisée figure sur la liste des problèmes d'API de l'OWASP - les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. De plus, les attaquants ont un petit avantage car, de par leur nature même, la plupart des défis d'authentification doivent être exposés aux utilisateurs, ce qui leur donne l'occasion de les étudier et de rechercher des modèles ou des vulnérabilités qu'ils peuvent exploiter.

Enfin, comme l'authentification sert souvent de passerelle vers une application et potentiellement vers le reste d'un réseau, elle constitue une cible tentante pour les attaquants. Si un processus d'authentification est défaillant ou vulnérable, il y a de fortes chances que des attaquants découvrent cette faiblesse et l'exploitent.

Dans ce chapitre, nous allons donc apprendre à faire taire les méchants lorsqu'il s'agit de problèmes d'authentification. Si vous souhaitez d'abord tester vos compétences, rendez-vous sur notre site et jouez à notre défi ludique :

Vous voulez améliorer votre score ? Restez avec moi pour en savoir plus.

Quels sont les exemples d'une authentification défaillante ou mal configurée ?

Un exemple où le problème peut ne pas être aussi évident est celui d'une méthode d'authentification vulnérable au "credential stuffing", c'est-à-dire à l'utilisation de listes de noms d'utilisateur et de mots de passe connus pour enfreindre la sécurité. Même une méthode d'autorisation normalement très sûre, comme l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, étranglées ou contrôlées d'une autre manière.

Par exemple, un attaquant pourrait déclencher une demande de récupération de mot de passe en envoyant une requête POST à /api/system/verification-codes et en fournissant un nom d'utilisateur dans le corps de la requête. Si une application utilise un défi par message texte SMS où un code à six chiffres est envoyé au téléphone de l'utilisateur, mais que le champ de saisie n'est pas limité, l'application peut être piratée en quelques minutes seulement. Un pirate n'a qu'à envoyer toutes les combinaisons possibles de six chiffres dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, il semble que l'authentification à deux facteurs permette d'assurer la sécurité de l'application. Mais comme l'entrée de l'utilisateur n'est pas limitée par le taux, l'authentification est défaillante et vulnérable.

Dans un autre exemple, une application peut utiliser des objets utilisateur codés comme cookies d'authentification. Mais si un attaquant disposant d'un accès utilisateur de bas niveau décode ce cookie à l'aide de Base64, il peut découvrir comment le cookie définit les sessions et les utilisateurs de l'application. Par exemple, il pourrait voir le JSON suivant une fois décodé :

{
"username" : "ShadyGuy",
"role" : "user"
{

À ce stade, l'utilisateur malveillant peut modifier son nom d'utilisateur, son rôle ou les deux. Il peut devenir un autre utilisateur avec un niveau de privilège plus élevé en changeant quelques valeurs :

{
"username" : "GoodGuy",
"role" : "admin"
{

À ce stade, si l'attaquant recode les informations et les définit comme valeur du cookie, il devient essentiellement le nouvel utilisateur avec un niveau d'autorisation plus élevé. À moins que des méthodes soient en place pour empêcher un tel changement, il y a de fortes chances que l'application accepte la transformation.

Élimination des authentifications erronées ou mal configurées

Si l'authentification échoue, il y a de fortes chances que la sécurité de l'ensemble du système soit compromise. Le respect de quelques règles importantes lors du codage des applications peut toutefois contribuer à garantir la sécurité de l'ensemble.

Tout d'abord, veillez à inclure des contrôles d'authentification partout où les utilisateurs peuvent accéder aux fonctionnalités du programme. Si le contrôle d'authentification n'existe pas du tout, la bataille est perdue d'avance.

En termes de bonnes pratiques, une bonne chose à garder à l'esprit est d'éviter d'exposer les identifiants de session dans l'URL accessible aux utilisateurs. Dans le deuxième exemple ci-dessus concernant l'authentification brisée, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il n'y est jamais exposé.

C'est également une bonne idée de mettre en place une authentification multifactorielle. Celle-ci peut être réalisée en toute sécurité à l'aide de jetons matériels qui génèrent algorithmiquement des mots de passe selon un calendrier serré. Si vous n'êtes pas en mesure de fournir à vos utilisateurs des dispositifs de ce type, les SMS peuvent également faire l'affaire. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre tentatives par période de 30 secondes, et que les codes expirent tous au bout de quelques minutes seulement. L'utilisation d'un code alphanumérique peut également améliorer la sécurité en ajoutant des lettres et des chiffres aux mots de passe potentiels.

Enfin, dans la mesure du possible, évitez d'utiliser des noms d'utilisateur ou des valeurs séquentielles prévisibles comme identifiants de session. Utilisez plutôt un gestionnaire de session sécurisé côté serveur qui génère à chaque fois un identifiant de session aléatoire.

La mise en œuvre de méthodes d'authentification sécurisées est un peu plus délicate que la lutte contre la vulnérabilité moyenne. Mais comme l'autorisation est si importante pour chaque application, programme et API, il vaut la peine de prendre le temps de s'assurer que vous y parvenez.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

L'un des aspects les plus intéressants du travail dans une startup technologique réside dans les personnes intéressantes et intelligentes que vous rencontrez et avec lesquelles vous collaborez tout au long de votre parcours. Faire passer une entreprise d'une idée géniale à un concurrent sérieux sur le marché nécessite la constitution de votre propre équipe d'Avengers (ou de la Ligue des Justiciers, selon votre allégeance).

Dans cette optique, nous aimerions mettre en lumière l'un de nos experts, Oscar Quintas. Il fait partie de notre équipe Product Content et travaille en tant que chercheur principal en sécurité. Il est également notre sorcier attitré pour tout ce qui concerne l'Infrastructure as Code (IaC). Il est à l'origine de nos 178 (et plus !) défis de la plateforme IaC, et notre interlocuteur pour toutes les questions brûlantes que nous nous posons sur ce sujet frais et brûlant.

Nous pensons qu'il est assez spécial, alors nous aimerions que vous le connaissiez un peu mieux. Il partagera ici ses idées sur le sujet brûlant de la sécurité de l'Infrastructure as Code, sur son rôle et sur ce que les organisations peuvent faire pour mieux préparer leur infrastructure et leurs ingénieurs en nuage :

Q:Parlez-nous de votre rôle à l'adresse Secure Code Warrior. À quoi ressemble une journée typique pour vous ?

R : Je fais partie de l'équipe Product Content et je travaille en tant que chercheur principal en sécurité. Une journée typique consiste à examiner le code des défis dans différents langages (Python, Java, Golang, et bien d'autres !) pour s'assurer que les normes de qualité du code sont respectées et que les meilleures pratiques en matière de sécurité sont mises en œuvre. Je développe également de nouveaux contenus pour l'IaC.

Q : Vous avez été le génie derrière tous les défis de notre plateforme Infrastructure as Code. Comment procédez-vous ?

R : Je dirais qu'il s'agit d'une combinaison de recherche et de travail acharné pour fournir un contenu qui offre une grande pertinence et un engagement à plusieurs niveaux de compétence. Je commence généralement par étudier les problèmes les plus courants auxquels les utilisateurs sont confrontés lors du déploiement de l'infrastructure et, à partir de ces informations, je développe des défis utiles pour montrer les meilleures pratiques en matière de sécurité pour chaque cas.

J'essaie toujours d'offrir une bonne expérience d'apprentissage à nos guerriers et de m'assurer qu'il s'agit d'un exercice utile et pertinent pour l'emploi, avec un bénéfice continu.

Q : La sécurité de l'IaC est un sujet très populaire en ce moment. Quels sont les principaux problèmes auxquels les entreprises sont confrontées en ce qui concerne leurs pratiques en matière de sécurité informatique ?
R : L'infrastructure en tant que code consiste à gérer vos ressources d'infrastructure à l'aide d'un code. Avec seulement quelques lignes de ce code, vous pouvez déployer des centaines de ressources en nuage (réseau, règles de pare-feu, machines virtuelles, conteneurs, etc. ) qui peuvent contenir des bogues de sécurité s'ils ne sont pas correctement configurés. Ainsi, les mêmes principes appliqués pour le déploiement d'applications sécurisées peuvent s'appliquer à l'IaC, et ces risques - et leurs corrections - doivent être compris par toutes les équipes impliquées dans le SDLC.

Cette prise de conscience et cette action commencent par une formation adéquate à la sécurité de l'IaC et par la priorité donnée aux compétences de codage sécurisé de vos ingénieurs en informatique dématérialisée. Ils peuvent constituer une puissante couche de défense, et c'est particulièrement important lorsqu'ils construisent l'infrastructure qui héberge les applications.

Q : L'industrie s'intéresse beaucoup à Kubernetes, qui semble être largement utilisé. Cependant, les données de notre plateforme montrent que Terraform est un langage extrêmement populaire, avec un engagement élevé. Avez-vous des idées à partager sur les raisons de cette popularité ?
R : Terraform est le langage de facto pour IaC car il nous permet de déployer des ressources d'infrastructure dans des environnements multi-cloud (par exemple, AWS, GCP, Azure) à l'aide d'une syntaxe simple. Il vous permet de définir votre infrastructure à l'aide de code et il interagit de manière transparente avec les API du nuage pour gérer le déploiement des ressources.

Ce langage est incroyablement polyvalent et, comme il peut être ajouté aux référentiels de contrôle des sources, les principes DevOps / DevSecOps peuvent également être appliqués au déploiement de l'infrastructure. Cependant, cela introduit également de nouvelles menaces auxquelles il faut faire face, c'est pourquoi une formation complète sur le codage sécurisé avec Terraform est indispensable.

Q : Vous êtes un expert en sécurité de l'IaC. Quelle est la meilleure partie de votre travail ?
R : L'IaC n'en est qu'à ses débuts et de nombreuses nouveautés sont régulièrement mises sur le marché. C'est un peu difficile de se tenir au courant de ces nouvelles technologies, mais c'est en même temps gratifiant. J'aime beaucoup apprendre de nouvelles choses et tester les meilleures pratiques de sécurité pour les nouveaux services.

Faites passer votre sécurité IaC au niveau supérieur.

Si vous souhaitez que vos développeurs cloud perfectionnent leurs compétences en matière de sécurité autour de l'Infrastructure as Code, lancez-vous un défi avec notre IaC Top 8! Lisez chaque chapitre pour obtenir une description complète de huit bogues de sécurité IaC courants, y compris des défis interactifs pour tester leurs nouvelles connaissances.

Faites-nous part de votre score et rendez Oscar fier !

De nos jours, les menaces qui pèsent sur la cybersécurité sont omniprésentes et incessantes. Elles sont devenues si graves qu'il est pratiquement impossible de les contrer après le déploiement des programmes. Cependant, à l'ère du DevSecOps, de la livraison en continu et de la multiplication des données, les entreprises astucieuses aident leurs développeurs à se perfectionner pour devenir des superstars de la sécurité qui contribuent à éliminer les vulnérabilités courantes avant même qu'elles n'atteignent le stade de la production. Nous avons abordé les vulnérabilités du web, ainsi que notre propre Top 8 des bogues de l'Infrastructure as Code, et il est maintenant temps de se familiariser avec le prochain grand défi de la sécurité des logiciels. Êtes-vous prêt ?

La prochaine série de blogs se concentrera sur certains des pires bogues de sécurité liés aux interfaces de programmation d'applications (API). Ces bogues sont si graves qu'ils figurent sur la liste des principales vulnérabilités des API établie par l'Open Web Application Security Project(OWASP). Compte tenu de l'importance des API dans les infrastructures informatiques modernes, il s'agit de problèmes critiques que vous devez à tout prix éviter dans vos applications et vos programmes.

Un exemple parfait de la raison pour laquelle il est essentiel d'utiliser du code pour renforcer la sécurité peut être trouvé dans l'examen de la vulnérabilité de l'autorisation au niveau de l'objet brisé. Cela se produit lorsque les programmeurs ne définissent pas explicitement quels utilisateurs sont en mesure de visualiser les objets et les données, ou ne fournissent aucune forme de vérification pour visualiser, modifier ou faire d'autres demandes de manipulation ou d'accès aux objets, ce qui leur permet de modifier et d'accéder aux objets et aux données par l'intermédiaire des points de terminaison de l'API. Un point de terminaison API est un point de contact, souvent une URL, qui est utilisé pour la communication entre l'API elle-même et un autre système. La capacité de connectivité entre les applications a permis d'élever certains des logiciels les plus appréciés au monde, mais elle comporte le risque d'exposer de multiples points d'extrémité s'ils ne sont pas hermétiques.

Cela peut également se produire lorsque les codeurs oublient ou héritent des propriétés des classes parentes, sans se rendre compte que ce faisant, ils omettent également un processus de vérification critique dans leur code. En général, des contrôles d'autorisation au niveau de l'objet devraient être inclus pour chaque fonction qui accède à une source de données en utilisant une entrée de l'utilisateur.

Vous pensez que vous les connaissez déjà et que vous pouvez trouver, corriger et éliminer un bogue de contrôle d'accès dès maintenant ? Participez au défi ludique :

Comment vous en êtes-vous sorti ? Si vous voulez améliorer votre score, continuez à lire !

Quels sont les exemples de vulnérabilités au niveau de l'autorisation de l'objet qui ne sont pas respectées ?

Les vulnérabilités du contrôle d'accès au niveau de l'objet permettent aux attaquants d'effectuer des actions qu'ils ne devraient pas être autorisés à faire. Il peut s'agir d'une action qui devrait être réservée aux administrateurs, comme l'accès ou la consultation de données sensibles, ou la destruction d'enregistrements. Dans un environnement hautement sécurisé, il peut même s'agir d'empêcher quiconque de consulter des enregistrements à moins d'y être spécifiquement autorisé.
Vous devez garder à l'esprit toutes les actions possibles lorsque vous définissez l'autorisation au niveau de l'objet. Par exemple, dans l'API Java Spring, un point de terminaison présentant un problème potentiel pourrait ressembler à ceci :

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

Le point de terminaison de l'API supprime les commandes par ID, mais ne vérifie pas si cette commande a été effectuée par l'utilisateur actuellement connecté. Cela permet à un pirate d'exploiter cette faille et de supprimer les commandes d'autres utilisateurs.

Pour que les restrictions d'accès soient correctement mises en œuvre, le code devrait ressembler à ce qui suit :

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

Élimination des vulnérabilités liées à l'autorisation au niveau de l'objet brisé

Le code de contrôle d'accès ne doit pas être excessivement compliqué. Dans le cas de notre exemple d'environnement Java Spring API, il peut être corrigé en définissant de manière stricte qui peut accéder aux objets.

Tout d'abord, un processus de vérification doit être mis en œuvre afin d'identifier l'auteur de la demande :

User user = userService.getUserByContext() ;

Ensuite, nous devons nous assurer que l'identifiant de l'objet existe et qu'il appartient à l'utilisateur qui fait la demande :

boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id)) ;

Enfin, nous procédons à la suppression de l'objet :

orderRepository.deleteById(id) ;

Gardez à l'esprit que vous devez vous assurer que la méthode d'autorisation de votre code est conforme aux politiques d'utilisation et aux contrôles d'accès aux données de votre organisation. Pour vous assurer que votre code est entièrement sécurisé, vous devez vérifier que les utilisateurs disposant de différents niveaux d'autorisation ont accès aux données dont ils ont besoin pour effectuer leur travail, mais qu'ils ne peuvent pas visualiser ou modifier des éléments qui devraient leur être réservés. Ce faisant, vous pourriez découvrir des vulnérabilités de contrôle d'objets manquants qui ont été accidentellement négligées.

Les principales leçons à tirer de ces exemples sont qu'il faut d'abord définir toutes les actions qu'un utilisateur peut effectuer avec un objet, puis ajouter des contrôles d'accès stricts directement dans le code. Enfin, ne faites jamais confiance aux propriétés parentales héritées pour faire ce travail ou pour déléguer cette autorité ailleurs. Au lieu de cela, définissez explicitement les autorisations et les actions des utilisateurs dans le code pour chaque type d'objet que vous devez protéger.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Dans l'onomatopée japonaise, l'expression "doki-doki" ("""") représente le son d'un cœur qui bat fort... ce qui est exactement ce que les membres de l'équipe de sécurité peuvent ressentir si leur serveur Docker est infecté par Doki, une nouvelle vulnérabilité qui fournit une porte dérobée pour l'injection de code malveillant, et bien plus encore. Un nom tout à fait approprié, c'est le moins que l'on puisse dire.

À l'heure où nous dépendons de plus en plus de l'infrastructure en nuage, il est essentiel que les meilleures pratiques en matière de sécurité soient précises et évolutives, et qu'elles aillent bien au-delà du strict minimum pour le déploiement d'applications sécurisées, avec des mesures personnalisées pour la sécurité des conteneurs qui soient connues et déployées tout au long du cycle de vie du logiciel.

Les cyberattaques sont de plus en plus fréquentes, et les menaces affectant les infrastructures basées sur Linux sont de plus en plus courantes, l'objectif final étant d'ouvrir un coffre à butin de données sensibles stockées dans le nuage. C'est précisément ce que vise Doki, qui utilise de multiples technologies pour rester indétecté, puissant et efficace, ce qui est sans précédent dans le domaine des problèmes de sécurité liés à Docker.

Qu'est-ce que Doki et comment fonctionne-t-il ?

Comme c'est le cas pour de nombreuses applications compromises, les erreurs de configuration de la sécurité jouent un rôle inacceptable dans la manière dont les logiciels ont été violés. Dans le cas de Docker en particulier, la mauvaise configuration de l'API du moteur Docker s'est avérée fructueuse pour les attaquants. Le bot de cryptomining Ngrok Botnet recherche depuis 2018 des serveurs Docker non sécurisés, crée ses propres conteneurs et exécute des logiciels malveillants sur l'infrastructure de la victime.

Doki est une version plus rusée et malveillante de ce logiciel malveillant, qui a réussi grâce au même réseau de zombies, exposant le même vecteur d'attaque : une mauvaise configuration de l'API, qui aurait dû être corrigée bien avant le déploiement du code ou la visibilité publique du serveur. Doki utilise la blockchain de la crypto-monnaie satirique préférée de tous, Dogecoin, pour servir de porte dérobée pratiquement indétectable. En l'état actuel des choses, il s'est faufilé sans laisser de traces depuis le mois de janvier.

Le logiciel malveillant abuse essentiellement d'un portefeuille blockchain afin de générer des noms de domaine de commande et de contrôle (C2), ce qui n'est pas nouveau en soi, mais Doki fournit une capacité continue d'exécution de code à distance sur un serveur infecté, ouvrant la voie à une gamme d'attaques dommageables basées sur des logiciels malveillants, comme les ransomwares et les DDoS. Il est implacable, comme un "Doge avec un os", si vous voulez. Les bonnes gens d'Intezer ont rédigé un article complet sur l'ensemble de la menace et sa charge utile tentaculaire.

Repérer un chemin de Doki dans le code.

Le fait que Doki soit une porte dérobée fonctionnant sur un réseau blockchain décentralisé, employant des techniques d'évasion de conteneurs insaisissables et rapides pour brouiller les pistes, accéder à d'autres zones de l'hôte et continuer à propager l'infection, en fait un véritable cauchemar pour les développeurs et les équipes de sécurité.

Néanmoins, Doki ne peut pas infecter un serveur Docker doté de ports API sécurisés. Une mauvaise configuration de ces ports pendant la production est une erreur lourde de conséquences, mais une formation efficace sur la sensibilisation à la sécurité et les compétences pratiques en matière de codage sécurisé pour les développeurs en nuage est une solution quelque peu "simple" face à un logiciel malveillant aussi complexe et percutant.

Examinons cet exemple d'API Docker non sécurisée, dans laquelle Doki pourrait s'introduire et commencer à se propager :

dockerd -H tcp://0.0.0.0:2375

Pouvez-vous repérer les erreurs de configuration ? La version sécurisée ressemble à ceci :

dockerd -H tcp://0.0.0.0:2376 --tlsverify --tlscacert=/etc/ssl/certs/ca.pem --tlscert=/etc/ssl/certs/server-cert.pem --tlskey=/etc/ssl/private/server-key.pem

Dans l'exemple non sécurisé, l'API du moteur Docker écoute sur le port TCP 2375 et accepte toute demande de connexion, de sorte qu'elle est accessible à quiconque accède au serveur Docker.

Dans l'exemple sécurisé, l'API Docker Engine a été configurée pour utiliser la validation de certificats TLS et n'acceptera que les connexions de clients fournissant un certificat approuvé par votre autorité de certification.

Nous avons créé une toute nouvelle série de défis ludiques pour aider les développeurs à identifier et à corriger la cause première d'une infection Doki, et vous pouvez en jouer un ici:

La sécurisation de l'infrastructure en nuage est un sport d'équipe.

Les erreurs de configuration du cloud ont coûté aux organisations la somme hallucinante de 5 000 milliards de dollars en 2018 et 2019, ce qui représente des milliards d'enregistrements exposés et des dommages irréversibles à la réputation. Pour un vecteur d'attaque largement évitable, il s'agit d'une statistique plutôt alarmante. Et quand on pense que des mesures telles que la surveillance et la correction des ports exposés (idéalement avant le déploiement), la vérification de tout conteneur inconnu et la surveillance de toute charge de serveur excessive pourraient arrêter les dégâts à effet boule de neige d'une attaque comme Doki, on se dit que la tranquillité d'esprit n'est pas si chère à payer.

La sensibilisation à la sécurité à l'échelle de l'entreprise est essentielle, et pour chaque personne impliquée dans le SDLC, l'application des meilleures pratiques en matière de sécurité n'est pas négociable. Les meilleures organisations s'engagent dans un processus DevSecOps solide, où la responsabilité de la sécurité est partagée, et où les développeurs et les professionnels de l'AppSec ont les connaissances et les outils nécessaires pour empêcher les vulnérabilités courantes de se frayer un chemin dans les logiciels et dans l'infrastructure vitale.
Vous voulez commencer à travailler en tant qu'ingénieur en nuage sensibilisé à la sécurité et suralimenté ? Testez vos compétences dès maintenant.

Nous sommes à peine à la moitié de l'année 2020, et pourtant nous sommes déjà en passe d'établir un sinistre record en matière de violation de données, avec une augmentation de 273 % des données volées par rapport au premier semestre 2019. De nos jours, il est plus juste de se demander combien de données n 'ont pas encore été volées. Avec des événements mondiaux comme la pandémie de COVID-19, ces attaques n'ont fait qu'augmenter en fréquence et en puissance, avec des cibles de plus en plus vulnérables.

Nous le savons tous depuis un certain temps : la sécurité n'est plus facultative et nous devons nous concentrer sur une attaque préventive. Pour que cela soit efficace, tous les acteurs du cycle de développement logiciel doivent être sensibilisés à la sécurité, en particulier les développeurs. C'est la partie "DevSec" de DevSecOps, une méthodologie de développement logiciel idéale pour le climat, mais de nombreuses organisations ne sont pas entièrement préparées pour l'exécuter efficacement.

En gardant votre organisation à l'esprit, réfléchissez à ces questions dans le contexte de votre rôle. Comment se comporterait-il lorsqu'il est soumis au test DevSec ?

DevSec Self-Assessment: Votre jardin SDLC est-il prêt à accueillir des ingénieurs sensibilisés à la sécurité ?

1. La sécurité est-elle au cœur du processus de développement interne ?
   Une série de facteurs de risque de cybersécurité peut empêcher le RSSI moyen de dormir, mais la réalité préoccupante est que, bien que de nombreuses entreprises fassent de la sécurité une priorité, leur approche interne n'est peut-être pas assez solide pour atténuer un désastre potentiel (ou, du moins, des maux de tête massifs pour l'équipe AppSec et des retards dans la livraison des logiciels).
   DevSecOps est peut-être l'état actuel du nirvana de la sécurité, mais peu d'entreprises travaillent avec cette méthodologie. Si vous êtes encore en mode Agile - ou même en mode Waterfall - la sécurité est souvent considérée comme le domaine de spécialistes éloignés du processus et activés tardivement dans le SDLC, surgissant pour gâcher la journée d'un développeur avec des correctifs pour son code. Dans un tel environnement, il sera difficile d'instaurer une culture DevSec : les développeurs aiment et donnent la priorité à la création de fonctionnalités, et n'auront tout simplement pas eu assez d'expérience pratique de la sécurité pour la considérer comme une voie de perfectionnement souhaitable. En fait, leurs contacts avec la sécurité peuvent être empreints de frustration et de négativité. Il faut y remédier rapidement afin d'instiller une approche de premier plan pour toutes les personnes impliquées dans le processus de développement de logiciels.
   ‍
2. Votre organisation est-elle encore en train de rattraper son retard en matière de modélisation des menaces ?
   Les statistiques sont inquiétantes : 60 % des PME cessent leurs activités dans les six mois qui suivent une cyberattaque réussie et, comme pour d'autres catastrophes, l'impact est bien plus important sans une planification adéquate.
   La modélisation des menaces est un élément crucial des meilleures pratiques de sécurité, qui permet aux professionnels de l'AppSec d'évaluer toute l'étendue de la surface d'attaque et de structurer les défenses, les contre-mesures et la planification appropriées. Dans les entreprises qui ont pleinement adopté DevSecOps, la sécurité est activée dès le début du pipeline CI/CD, de manière à ne pas ralentir la production autant que par le passé. La sécurité, le codage sécurisé et la livraison continue font tous partie du processus, et les équipes de développement reçoivent les ressources et l'exposition nécessaires pour être des composants majeurs du moteur qui crache un code étanche.
   ‍
3. Les responsables du développement accordent-ils la priorité aux meilleures pratiques en matière de sécurité ?
   Qu'ils le veuillent ou non, les responsables du développement sont des modèles pour leur équipe. Et ce n'est pas seulement une question de culture et d'ambiance, comme le fait de porter des tongs au bureau ou la façon dont ils "gèrent vers le haut". Leurs priorités de travail seront inévitablement absorbées par les membres de leur équipe, et si la sécurité ne fait pas partie des objectifs clés, ou n'est pas planifiée en termes de formation et de soutien, alors les ingénieurs en dessous d'eux manqueront à l'appel, et l'entreprise sera plus en danger qu'elle ne devrait l'être.
   ‍
4. Les développeurs ont-ils une raison de se préoccuper de la sécurité ?
   D'après mon expérience, le moyen le plus rapide de mettre quelqu'un hors-jeu est de lui dire qu'il doit faire quelque chose qui n'a rien à voir avec son approche actuelle, sans lui dire pourquoi.
   
   Le fait de devoir "changer" implique que l'approche précédente était erronée, alors que dans de nombreux cas, il s'agit simplement d'une amélioration qui, espérons-le, rendra les choses plus faciles et plus efficaces par la suite. Pour adopter véritablement le mouvement DevSec, il faut donner aux développeurs une raison de se préoccuper de la sécurité en premier lieu - après tout, dans la plupart des organisations, c'est encore le "problème de quelqu'un d'autre" (c'est-à-dire les magiciens de l'AppSec enfermés dans une autre pièce, loin, très loin, très loin).
   
   DevSecOps ne fonctionne tout simplement pas si la sécurité n'est pas une responsabilité partagée. Les développeurs ont besoin des bons outils, du support et de la formation pour faire leur part... et cela demande du temps pour être déployé et perfectionné dans le cadre d'un programme de sécurité global. La pire approche est celle qui submerge et aliène, ce qui peut être le cas lorsque les développeurs ont trop de priorités concurrentes et aucune aide pour les gérer sans se rendre fous. Il s'agit d'un changement culturel qui ne se fera pas du jour au lendemain.
   ‍
5. Comptez-vous sur une poignée de licornes magiques de la sécurité pour prendre en charge la tâche d'un grand nombre de personnes ?
   Les professionnels de la sécurité sont très rares, et nous en avons besoin de beaucoup plus que ce qui est actuellement disponible. C'est une évidence, mais un nombre croissant de développeurs s'orientent vers des fonctions plus axées sur la sécurité. En règle générale, ils portent des titres tels que "ingénieur en sécurité" ou "ingénieur DevOps" (avec un peu de chance, nous verrons ce titre se transformer en ingénieur DevSecOps). Un ingénieur DevOps est capable de développer des fonctionnalités pour pratiquement n'importe quelle application, tout en la déployant à l'aide d'un véritable pipeline CI/CD. Il s'occupe de tout de bout en bout et est généralement doté d'une bonne dose de sensibilisation à la sécurité. En ce sens, ils sont un peu magiques, et donc rares.
   
   Cependant, certaines entreprises font l'erreur d'embaucher ces ingénieurs spécialisés, de les intégrer dans une équipe et de s'attendre à ce qu'ils s'occupent de tous les problèmes de sécurité, à chaque étape du processus de développement, et qu'ils soient la panacée. Surchargez vos magiciens DevSecOps et vous vous retrouverez au même point qu'au début : vous livrerez un code non sécurisé sans les contrôles, les équilibres et la précision de sécurité pour lesquels ils ont été embauchés. Il est de la plus haute importance que l'équipe de développement en général soit perfectionnée et nourrie dans un environnement de sécurité positif afin qu'elle soit équipée pour partager la charge de manière significative.

Trouvez le changement que vous souhaitez voir s'opérer dans votre organisation.

Si vous mettez en place une formation solide dans le cadre de votre programme de sécurité, vous découvrirez quelques joyaux cachés dans votre cohorte de développement. Il s'agit des personnes qui, malgré les expériences négatives qu'elles ont pu avoir dans leur travail quotidien, ont une certaine passion pour le codage sécurisé et les meilleures pratiques en matière de sécurité. Ces personnes sont des candidats de choix pour devenir des champions de la sécurité au sein de l'équipe ; un point de contact entre la sécurité et l'ingénierie qui montre l'exemple aux autres, maintient la sensibilisation à un niveau élevé et contribue aux initiatives d'engagement. Leurs compétences interpersonnelles sont également très importantes pour diffuser largement la joie de la sécurité et défendre les besoins des développeurs auprès de la direction et de l'équipe de sécurité.

La conversation "qu'est-ce que j'y gagne ?" est un pas en avant positif.

Même les êtres humains les plus nobles ont besoin d'une "carotte" pour s'aventurer en terrain inconnu ou dans une activité dont la courbe d'apprentissage n'est pas des plus agréables.
Faire le saut de "dev" à "DevSec" est un formidable coup de pouce pour la carrière d'un développeur. Les développeurs sensibilisés à la sécurité ont travaillé dur pour comprendre la sécurité, en assumer la responsabilité dans les domaines qu'ils peuvent contrôler et travailler en sachant que le seul code de qualité est un code sécurisé. En général, les développeurs veulent s'améliorer, s'attaquer à de nouveaux problèmes et créer des fonctionnalités enviables qui les aident à se démarquer de leurs pairs. Donnez-leur la possibilité d'atteindre un niveau plus élevé de développement logiciel, et vous obtiendrez une situation gagnant-gagnant.

Il n'est jamais trop tard pour constituer votre équipe de rêve DevSec.

Si vous gérez des développeurs, si vous dirigez une équipe de sensibilisation à l'AppSec ou si vous êtes l'un des nombreux cerveaux qui travaillent à l'élaboration de stratégies de programmes de sécurité, le moment est venu de faire mieux que de "passer" à gauche. Avec la formation, les outils et l'environnement adéquats, vous pouvez créer un incubateur de sécurité pour les développeurs qui rapportera beaucoup à toutes les parties. Si cette liste de contrôle a mis en évidence certains points à améliorer, vous avez une excellente occasion de préparer votre organisation à un service d'ingénierie dirigé par DevSec et capable de réduire les risques dès le début du cycle de développement durable (SDLC).

Il existe une vérité qui dérange, une vérité qui tend à être ignorée par les gouvernements, les grandes entreprises et même certains leaders du secteur : en tant que société, nous sommes engagés dans une bataille constante contre les cybermenaces, et nous sommes actuellement du côté des perdants. Comment le savons-nous ? Ces statistiques racontent une histoire qui donne à réfléchir :

• Le coût global de la cybercriminalité est estimé à 6 000 milliards de dollars d'ici 2021.
• Une cyberattaque se produit toutes les 39 secondes
• 24% des violations de données sont dues à une erreur humaine
• Il est alarmant de constater que 77 % des organisations ne disposent pas d'un plan de réponse aux incidents de cybersécurité qui s'étende à l'ensemble de l'entreprise et qui soit appliqué de manière cohérente entre les différents services.

En ce qui concerne les spécialistes de la cybersécurité, nous manquons cruellement de personnel ; le déficit de compétences a peu de chances d'être comblé, et aucune armée secrète d'AppSec ne viendra nous tirer d'affaire. Nous le savons depuis des années et nous devons changer d'approche. Dans notre cas, la meilleure attaque est une grande défense, et nous pouvons frapper les premiers avec un bon plan.

Tout cela semble un peu déprimant, mais la situation n'est pas aussi grave que certains voudraient nous le faire croire. Nous avons un atout dans notre manche, et le climat de cybersécurité nous offre une opportunité en or. Vous n'avez qu'à chercher dans vos équipes de développement internes le personnel qui viendra à la rescousse de l'organisation, mais votre programme de sécurité doit les aider à devenir des ingénieurs sensibilisés à la sécurité et prêts à partager la responsabilité de coder en toute sécurité.

N'importe quelle formation ne suffira pas - nous l'avons certainement dit assez souvent - mais même la bonne formation qui engage, construit des connaissances contextuelles et aide les développeurs à aimer la sécurité pourrait être beaucoup plus efficace, si seulement elle était mieux adaptée aux besoins de l'entreprise, aux menaces auxquelles elle est confrontée, et aux exigences de conformité qui aident les entreprises à assurer la sécurité de toutes nos données.

C'est là qu'intervient notre nouvelle fonctionnalité, Coursesentre en jeu. D'ailleurs, si vous avez compris la référence du titre, vous êtes officiellement vieux (ou vous appréciez simplement un classique).

Apprentissage spécifique à l'organisation : construire une défense, renforcer les compétences des développeurs

Nous avons toutes sortes d'opinions sur les raisons pour lesquelles certains types de formation pour développeurs sont meilleurs que d'autres (par exemple, ne les ennuyez pas à mort avec des heures de sermons vidéo génériques et arides, et attendez qu'une passion pour le codage sécurisé s'épanouisse). Mais même avec une formation compétitive conçue pour attirer les développeurs, le contenu peut toujours être un peu plus large que ce qui est nécessaire pour répondre aux besoins particuliers d'une organisation.

Un cours adapté contenant les modules exacts dans lesquels vos développeurs devraient faire preuve de compétence aura un impact puissant et leur permettra d'être opérationnels lorsqu'il s'agira de mettre en œuvre les meilleures pratiques de sécurité dans leur travail quotidien. Adaptez les programmes aux équipes frontales, aux ingénieurs cloud et autres, avec la possibilité d'approfondir les vulnérabilités les plus importantes, dans les langages et les frameworks qui les concernent. Les développeurs développeront leurs compétences grâce à un contexte, des points de contact et une expérience continus, tandis que l'entreprise bénéficiera d'une sensibilisation précise aux problèmes qui posent le plus de risques.

Personnaliser un cours pour assurer la conformité

Des réglementations plus strictes en matière de cybersécurité sont imposées partout dans le monde, et la conformité de la sécurité des logiciels est une excellente base pour construire une culture de la sécurité positive et efficace. Cela ne devrait pas être ennuyeux, et un bon programme de sécurité suscite chez les développeurs un sentiment de fierté et de responsabilité, plutôt qu'un grognement et un sourire en coin.

Pour commencer, c'est une très bonne idée de mettre tout le monde au courant du Top 10 de l'OWASP, mais pour atteindre de nouveaux sommets en matière de conformité industrielle, vous pouvez concevoir un cours personnalisé autour des exigences de réglementations spécifiques. Par exemple, une organisation financière pourrait adapter un cours aux exigences de conformité de son logiciel, conformément aux directives PCI-DSS qui régissent les applications de paiement et de traitement des cartes. Les enjeux sont élevés lorsque vous êtes en charge du traitement et du stockage d'informations sensibles telles que les numéros de cartes de crédit, et le fait d'être ultra-spécifique en matière de formation des développeurs permet de s'affranchir du bruit, de dispenser la bonne formation au bon moment et de contrôler plus facilement les aptitudes de l'équipe.  

Voici comment General Electric (GE) utilise Courses au sein de ses équipes :

"Courses est une excellente solution pour nos ingénieurs. Grâce à la nouvelle fonctionnalité - qui regroupe le parcours d'apprentissage, les vidéos et les points de contrôle dans un module personnalisable - nous avons la possibilité de façonner le contenu en fonction de ce dont nous avons besoin à tout moment. Les capacités de mise en conformité et la flexibilité offrent une meilleure occasion de garantir un processus plus rationalisé et plus souple. Cette capacité a aidé General Electric à adapter une formation pertinente à chaque ingénieur plus rapidement et plus facilement que jamais.

Et n'oubliez pas qu'il peut s'agir d'une formation à la conformité, mais qu'elle est toujours dispensée sous la forme d'une expérience d'apprentissage contextuelle et engageante, qui est bien plus attrayante pour les développeurs.

Une culture positive de la sécurité fondée sur le respect et la pertinence

L'éducation est un processus qui dure toute la vie, mais dans le monde effréné de DevSecOps, il y a beaucoup d'assiettes à faire tourner. Le temps consacré à la formation doit être utilisé à bon escient, avec un parcours d'apprentissage viable qui continue de susciter l'intérêt et d'apporter de la valeur ajoutée.

En créant un cours personnalisé qui est hyper pertinent, vous respectez le temps et le flux de travail du développeur, tout en travaillant à une réduction mesurable des vulnérabilités et des risques de cybersécurité pour l'entreprise.

La relation entre les spécialistes de l'AppSec et les ingénieurs est traditionnellement marquée par des malentendus et des tensions, mais un apprentissage structuré avec Courses peut permettre aux deux parties d'être sur la même longueur d'onde en ce qui concerne les meilleures pratiques en matière de sécurité. Les développeurs apprécieront certainement que l'équipe AppSec les aide à trouver des solutions, ce qui réduira leur charge de travail et les aidera à élaborer un code de meilleure qualité.

Gommez les faiblesses, renforcez l'hygiène de sécurité au niveau de l'entreprise

Nous sommes tous humains et, malheureusement, nous commettons des erreurs. Ces erreurs peuvent être extrêmement coûteuses dans le monde numérique, et pourtant elles sont étonnamment courantes. Le rapport 2019 de Symantec sur les menaces de sécurité Internet a confirmé que plus de 70 millions d'enregistrements ont été volés à la suite de buckets S3 mal configurés. Les erreurs de configuration de la sécurité sont l'une des principales causes des violations de données, l'erreur humaine étant à l'origine d'environ un quart d'entre elles.

Ces problèmes sont dus à un certain nombre de raisons, mais le manque de sensibilisation et de formation à la sécurité est un facteur déterminant pour les petites fenêtres d'opportunité laissées ouvertes aux attaquants. Pour une hygiène de sécurité évolutive qui ait un impact, vous devez faire en sorte qu'elle compte grâce à un cours conçu sur mesure pour votre entreprise. N'ayez aucune pitié pour vos ennemis et éliminez toutes les possibilités qu'ils ont de vous causer le plus grand mal de tête que vous puissiez rencontrer.

Nous constatons déjà un impact considérable auprès de nos clients, y compris ce fournisseur SaaS de comptabilité en nuage de premier plan :

Courses"Le parcours d'apprentissage sur mesure a changé la donne. La spécificité des langages de programmation et des vulnérabilités offre plus de contrôle et de flexibilité pour créer l'expérience d'apprentissage adéquate pour chaque développeur en fonction des besoins de l'individu et de l'entreprise. L'utilisation de Courses en conjonction avec la plateforme de codage sécurisé plus large de Secure Code Warrior a transformé l'engagement de nos développeurs, en ce sens qu'ils sont maintenant plus intéressés par l'amélioration de leurs compétences en codage sécurisé afin d'écrire un code meilleur et plus sûr".

Préparez-vous à DevSec. Découvrez la toute nouvelle fonctionnalité de Secure Code Warriors Courses ici.

Le cycle de développement des logiciels (SDLC) semble assez inoffensif ; c'est un processus, et nous, les informaticiens, nous nous réunissons pour que la magie opère et pour expédier tous ces biens numériques dont la société ne peut se passer.

Sauf que... si vous avez déjà participé à un projet de développement de logiciel, vous savez qu'il s'agit généralement d'un gant, avec de nombreuses quêtes à conquérir et des dragons à tuer. C'est amusant pendant un certain temps, mais l'épuisement professionnel est réel, et la demande de logiciels nous fait tous travailler à la vitesse de la lumière dans le meilleur des cas, en particulier l'équipe de développement.

Imaginez maintenant qu'on leur confie une autre tâche incontournable : la responsabilité de la sécurité des éléments du projet qu'ils touchent. Dans le pire des cas, le château de cartes peut s'écrouler pour certains individus, mais le scénario le plus réaliste est que la sécurité n'est tout simplement pas considérée comme une priorité et que les problèmes jugés plus urgents à résoudre prennent le dessus. Et lorsque la plupart des développeurs ne sont pas formés pour coder en toute sécurité (surtout si leurs responsables n'accordent pas non plus la priorité à la sécurité), il n'est pas étonnant que nous assistions à de fréquentes violations de données, à la sortie d'applications défectueuses et à une sérieuse désaffection des professionnels de la sécurité qui atteignent le point de rupture sous l'avalanche de codes bogués.

Les développeurs ont besoin d'un défenseur de l'AppSec.

Si l'on considère le scénario ci-dessus, on peut comprendre pourquoi la sécurité est mise dans le panier "trop difficile" au cours du processus de codage, et laissée à l'équipe de sécurité pour s'en occuper. Trop d'échéances concurrentes, pas assez de formation et aucune raison réelle de se préoccuper de la sécurité avec tout ce qui se passe ailleurs. Cependant, la demande de code est tout simplement trop importante pour que ce statu quo perdure. C'est là que les développeurs de haut niveau peuvent se démarquer de leurs pairs, acquérir de nouvelles compétences et, surtout, créer un code plus sûr.

Cependant, il est important de se rappeler que la gestion de la sécurité des logiciels ne repose pas uniquement sur les épaules des développeurs - c'est toujours le domaine de l'équipe AppSec (qui, lorsqu'elle travaille avec des développeurs sensibilisés à la sécurité, dispose d'une plus grande marge de manœuvre au lieu de réparer les bogues courants de façon répétée). Pour que le processus DevSecOps fonctionne, il faut que chaque membre de l'équipe dispose du soutien et des outils dont il a besoin pour partager la responsabilité de la sécurité, et le bon type de formation est primordial. L'équilibre entre la bonne série d'outils et la bonne formation nécessite la perspicacité de professionnels de l'AppSec prêts à travailler en étroite collaboration avec les développeurs afin de les inspirer et de conduire un changement positif.

Les formations perturbatrices sont plus ennuyeuses qu'efficaces, et tout ce qui est répulsif pour les développeurs ne fonctionnera pas. Une solution intégrée à un IDE ou à un outil de suivi des problèmes, axée sur des connaissances fragmentaires, est une alternative qui permet de mettre les bonnes informations à la disposition des développeurs, au moment même où ils en ont besoin.

Voici comment cela fonctionne :

Juste à temps, et non pas "juste au cas où".

L'apprentissage contextuel et pratique est de loin la manière la plus efficace de former, avec des morceaux de taille réduite livrés au moment le plus opportun. C'est ce que l'on appelle parfois la formation "juste à temps" (JiT), qui est très efficace pour les développeurs qui apprennent à coder de manière sécurisée.

Inspirée des principes de production allégée de Toyota, la formation JiT est conçue pour être activée sur la base du besoin de savoir, dans le contexte, au moment où cela compte le plus. Un développeur vient-il d'écrire quelque chose qui semble avoir des autorisations inappropriées ? Et si une petite porte dérobée avait été ouverte, permettant à un attaquant d'exécuter du code à distance ? Il sera beaucoup plus mémorable que les développeurs puissent accéder aux connaissances dès qu'ils en ont besoin, plutôt que de parcourir la documentation dans Confluence ou de chercher sur Google quelque chose qui a été abordé lors de la formation.

Le juste-à-temps est l'antithèse de l'apprentissage "juste au cas où" ; bien que ce dernier soit le moyen le plus courant de transmettre des connaissances, il n'est tout simplement pas efficace. Nous devons faire en sorte qu'il soit plus facile pour les développeurs de s'engager dans les meilleures pratiques de codage sécurisé et de voir l'avantage d'améliorer leurs compétences pour leur carrière tout en se concentrant sur les objectifs clés sur lesquels ils travaillent en ce moment.

Arrêtez de faire courir les développeurs après la formation.

Nous savons déjà qu'il y a trop de choses à faire dans une journée de travail, alors pourquoi les développeurs devraient-ils se rendre dans une salle de classe ou changer de contexte pour passer par cinq étapes afin d'accéder à une formation théorique statique ?

Le consensus général est que ce que font la plupart des organisations n'est pas terriblement efficace si l'on en croit le nombre de vulnérabilités à l'origine de violations de données. Le rapport 2020 Data Breach Investigations Report de Verizon précise que 43 % des violations de données peuvent être attribuées à des vulnérabilités web. Les développeurs ne reçoivent pas de formation efficace, ni dans l'enseignement supérieur, ni dans le cadre de mesures de perfectionnement sur le lieu de travail. Si c'était le cas, les vulnérabilités courantes telles que l'injection SQL et la traversée de chemin à l'ancienne ne seraient pas exploitées pour obtenir des données importantes, et la pénurie de compétences en cybersécurité ne serait pas incontrôlable.

Alors, sachant qu'il s'agit du climat actuel dans lequel les développeurs reçoivent une formation et se familiarisent avec la sécurité, pourquoi sommes-nous surpris de ce mauvais résultat ? Cela pourrait avoir un effet - positif - pour le développeur et l'organisation d'assurer une expérience de formation plus fluide, plus intégrée et moins dérangeante, où elle est accessible dans les espaces dans lesquels ils travaillent réellement, comme Jira, GitHub, et dans l'IDE. L'industrie doit simplement aller de l'avant et rendre la sensibilisation à la sécurité beaucoup plus facile, dans un environnement où elle n'est plus un luxe.

Prêt à sécuriser le processus de développement ?

Les développeurs sensibilisés à la sécurité sont vénérés pour leurs compétences et la protection qu'ils peuvent offrir aux organisations dès la phase de construction du code. La sécurité n'est plus optionnelle, surtout avec les amendes GDPR, les réglementations de conformité PCI-DSS, la gouvernance NIST... et la possibilité d'être poursuivi en justice dans le cadre d'une action collective de plusieurs millions de dollars, à la manière d'Equifax.

Une approche intégrée pourrait être le catalyseur pour commencer à gagner les développeurs avec un apprentissage moins perturbant, et créer des voies pour un apprentissage plus approfondi courses, former des champions de la sécurité, et généralement inspirer cette responsabilité partagée dont nous avons besoin pour garder les données du monde sûres et solides.

Téléchargez les outils d'intégration pour Jira et GitHub maintenant, et faites-nous savoir ce que vous en pensez.