Pensez à la dernière fois que vous étiez au travail, peut-être dans une équipe de projet logiciel travaillant dans des délais impossibles à tenir. Et voilà que votre responsable arrive et vous dit qu'il y a une formation obligatoire à faire en matière de sécurité, et qu'il faut la caser dans votre journée de travail en plus de tout le reste.

Ils le savent, et vous le savez. C'est un énorme problème, mais pour des raisons de conformité, vous passerez des vidéos de formation ennuyeuses en arrière-plan pendant que vous continuez à coder, en alternant les deux tâches et en ne consacrant toute votre attention ni à l'une ni à l'autre. Il s'agit d'un scénario courant, très perturbant et qui fait perdre du temps à tout le monde. La plupart des formations à la sécurité sont trop génériques, et il est facile d'ignorer quelque chose qui entre et sort d'une journée de travail sans réelle valeur.

En tant qu'entreprise, notre objectif est de vous apporter un type de formation à la sécurité meilleur et plus efficace, et ceci est né du fait que nous savons exactement ce que c'est que d'être désengagé de ce que l'équipe AppSec vous dit être important, quand chacune de vos priorités est désalignée. Ce qui est intéressant, cependant, c'est que nous avons commencé à réfléchir à ce que nous pourrions faire pour réduire les obstacles à l'obtention d'une formation lorsque vous en avez besoin - même avec notre plateforme complète, il y a quelques étapes qui vous éloignent de votre travail, à des moments où vous avez toujours besoin d'un coup de pouce utile mais où vous ne pouvez pas consacrer un bloc de concentration à une session de formation.

Nous avons cherché à savoir comment le micro-apprentissage pouvait être mis en œuvre dans votre flux de travail, dans l'IDE ou le gestionnaire d'incidents, d'une manière plus transparente. Voici ce que nous avons trouvé :

Cette approche repose sur les principes du "juste à temps" (JiT), selon lesquels vous recevez les bonnes connaissances, au bon moment, pour qu'elles soient immédiatement efficaces et utiles. C'est le contraire de l'approche de l'apprentissage "juste au cas où", qui est souvent un état de surcharge d'informations qui vous prive d'un temps et d'un espace de réflexion précieux pour construire des caractéristiques.

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

Éliminez les obstacles et faites venir la formation à vous.

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é - cela reste le travail d'équipes spécialisées dans l'AppSec. Cependant, 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. C'est un poste très demandé, et vous pouvez construire les fondations au fil du temps avec un micro-apprentissage contextuel.

Maintenant, si vous pensez que la formation intégrée ressemble davantage à Clippy(qu'il repose en paix), il est important de noter que dans le cas des intégrations de Secure Code Warrior, elles sont construites par des développeurs pour des développeurs, de sorte que le facteur d'irritation a été pris en compte et oblitéré.

Voyons ce qu'il en est :

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 problème et le corps du problème afin d'afficher une formation contextuelle juste à temps. Si une référence à une vulnérabilité est trouvée, un commentaire sera posté sur le problème afin d'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 obliger à faire des pieds et des mains pour trouver une solution.

Si vous utilisez Jira, le processus est similaire :

Pour les superstars de la sécurité déjà en place, il est important de se rappeler que ce n'est pas à vous de faire la magie. Vous aurez besoin de soutien, de formation et d'une raison de prendre la sécurité au sérieux et de l'intégrer dans 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.

Depuis quelques années, il semble que les ingénieurs logiciels du monde entier ne se lassent pas de Rust pour la programmation. Ce langage de programmation relativement nouveau, produit par Mozilla, a conquis le cœur de la communauté Stack Overflow - et, en tant que cohorte très peu encline à souffrir les imbéciles, lorsqu'ils votent quelque chose comme le"langage de programmation le plus aimé" cinq années d'affilée, il est temps que nous nous réveillions tous et que nous en prenions note.

Le langage de programmation Rust incorpore des éléments connus et fonctionnels de langages couramment utilisés, en travaillant selon une philosophie différente qui élimine la complexité, tout en introduisant la performance et la sécurité. Il s'agit d'une courbe d'apprentissage, et de nombreux développeurs n'ont pas beaucoup l'occasion de jouer avec lui - seulement 5,1 % des personnes interrogées sur Stack Overflow l'utilisent couramment. Cela mis à part, on ne peut nier qu'il s'agit d'un langage passionnant, dont la puissance de feu en matière de sécurité est bien supérieure à celle de ses prédécesseurs, comme le C et le C++. L'adoption massive de ce langage va nécessiter quelques changements, tant comportementaux que technologiques... mais pour l'instant, il continue de capter l'attention des développeurs à un niveau théorique.  

... mais attendez, nous devons mettre en lumière une autre chose : il est important de noter que Rust est un langage de programmation qui donne la priorité à la sécurité de la mémoire, et à l'éradication des bogues de sécurité qui sont liés à des problèmes courants de gestion de la mémoire. Ces problèmes sont importants (et causent sans aucun doute plus d'une migraine à l'équipe AppSec), mais ce ne sont pas les seuls défis auxquels nous sommes confrontés en matière de codage sécurisé.

Qu'est-ce que Rust empêche exactement ? Et où sommes-nous encore exposés dans le paysage de la sécurité ? Décortiquons la dernière licorne de la programmation :

La nouvelle frontière de la programmation de systèmes modernes à sécurité mémoire

L'équipe de recherche et de développement de Mozilla a travaillé sur des projets incroyables, et l'investissement dans la programmation Rust en tant que pionnier du logiciel libre ne fait pas exception. Leur vidéo d'introduction donne un aperçu de leur philosophie, avec un thème clé très clair : l'approche actuelle de la sécurité des logiciels est défectueuse, et Rust est conçu pour résoudre une grande partie de ce problème.

Cela semble trop simpliste, d'autant plus que nous sommes confrontés tous les deux jours à d'énormes violations de données - comme la récente et horrible bavure rapportée par EasyJet. Des millions d'enregistrements de données sont fréquemment compromis, presque toujours à cause d'une vulnérabilité d'application web, d'une mauvaise configuration de sécurité ou d'une attaque par hameçonnage, et des langages comme le C++ existent depuis des décennies. Cependant, les développeurs n'ont pas eu le temps de les maîtriser au point de mettre en œuvre les meilleures pratiques de codage sécurisé. Pourquoi en serait-il autrement pour Rust ? De nouveaux langages sont apparus auparavant, et ce n'est pas comme s'ils avaient trouvé un moyen d'éradiquer les vulnérabilités courantes, ou de garantir que tout code écrit est magiquement parfait lorsqu'il est compilé.

Aussi simple que soit le concept, ce sont parfois les réponses simples qui permettent de résoudre les questions complexes. Rust est, dans tous les sens du terme, une révolution dans la programmation de systèmes à mémoire sécurisée qui tient ses promesses à bien des égards... et il sauve certainement le lard des développeurs qui sont susceptibles d'introduire des erreurs qui peuvent causer de gros problèmes si elles ne sont pas détectées. Java, C, C++, et même des langages plus récents comme Kotlin et Golang, restent assez impitoyables pour le développeur non sensibilisé à la sécurité. Avec ces langages, il n'y a pas d'avertissements intégrés, pas de signes particuliers indiquant que la fonction géniale qui vient d'être compilée cache un gremlin de sécurité sous le capot.

Approfondissons donc la question :

Qu'est-ce qui rend Rust si sûr ?

En règle générale, un développeur a pour objectif principal de créer des fonctionnalités, de s'assurer qu'elles sont fonctionnelles et conviviales, voire même d'en faire une source de fierté qu'il serait heureux de faire figurer sur son curriculum vitae. Il est tout à fait normal qu'un développeur crée un excellent logiciel, le livre et passe au projet suivant. À ce stade, les équipes de sécurité recherchent des vulnérabilités et, si elles sont détectées, l'application "finie" peut être renvoyée à l'équipe qui l'a créée pour être corrigée. Le problème peut être simple, ou complètement hors de portée d'un développeur pour y remédier.

Le problème est qu'en surface, les bogues de sécurité n'étaient pas du tout apparents, et si l'analyse, les tests et l'examen manuel du code ne les détectent pas, un pirate peut potentiellement utiliser cette petite fenêtre d'opportunité pour exploiter le bogue.

Aujourd'hui, Rust cherche à empêcher de nombreuses vulnérabilités de se retrouver dans le code : il ne compile tout simplement pas s'il y a des erreurs de syntaxe ou d'autres bogues de sécurité de la mémoire qui causent des problèmes de production tout au long du cycle de vie du logiciel (SDLC). Il s'agit d'une programmation sans risque pour la mémoire, qui garantit qu'il n'y a pas d'accès à une mémoire non valide (quelle que soit la manière dont le logiciel est exécuté). Et comme 70 % de tous les bogues de sécurité résultent de problèmes liés à la gestion de la mémoire, il s'agit là d'un véritable exploit.

La rouille sera signalée et empêchée :

• Débordement de mémoire tampon
• Utilisation après la gratuité
• Doublement libre
• Déréférencement d'un pointeur nul
• Utilisation de mémoire non initialisée

Si nous comparons un extrait de code Rust à un code C++, il apparaît clairement que l'un des deux est sûr par défaut. Regardez cet exemple de bug de débordement de mémoire tampon :

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // buffer overflow as len of b is greater than a
std::cout << a << "; " << b << std::endl;
}

Vs.

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust lance un avertissement de sécurité et panique en atteignant la fonction copy_from_slice en cours d'exécution pour éviter un débordement de mémoire tampon, mais pas en cours de compilation.

En ce sens, il s'agit vraiment d'un des langages "à commencer par la gauche". Il mettra en évidence les erreurs et forcera les développeurs à apprendre la bonne façon d'écrire le code afin d'éviter d'introduire des bogues de sécurité liés à la mémoire, de sorte que le respect des délais dépend de l'attention du codeur, de sa capacité à remédier aux problèmes et à rester fidèle à la voie de livraison.

L'approche de ce langage semble simple, mais cela aurait été un exploit incroyable de le faire fonctionner avec une logique aussi puissante, et il le fait. Du point de vue de la sécurité, Rust est un pas de géant... si seulement plus de gens l'utilisaient. Des entreprises comme Dropbox sont les premières à l'utiliser à grande échelle, et cela fait plaisir à voir. Mais il y a d'autres considérations à prendre en compte avant de sauter à la conclusion qu'un problème d'adoption est tout ce qui nous empêche d'avoir un avenir plus sûr.

Le bilan de la rouille.

Il y a quelques petits (ok, grands) problèmes, notamment le fait que la programmation en Rust est plus susceptible d'introduire des bogues qu'il n'y paraît. Elle ne résoudra pas les vulnérabilités du Top 10 de l'OWASP qui continuent à causer des brèches, des retards et une culture générale de techniques de codage peu sûres. Il existe également une dynamique entre l'ange et le diable, ou, comme on l'appelle plus communément : Safe Rust vs. Unsafe Rust.
‍

Comme l'explique la documentation officielle, Safe Rust est la "vraie" forme de Rust, et Unsafe Rust inclut des fonctions qui sont considérées comme "définitivement non sûres", bien qu'elles soient parfois nécessaires - par exemple si l'intégration avec quelque chose dans un autre langage est requise. Cependant, même avec Unsafe Rust, la liste des fonctionnalités supplémentaires reste limitée. En Rust non sécurisé, il est possible d'effectuer les opérations suivantes à l'intérieur de blocs non sécurisés :

• Déréférencer les pointeurs bruts
• Appeler des fonctions non sûres (y compris les fonctions C, les fonctions intrinsèques du compilateur et l'allocateur brut).
• Mettre en œuvre des caractéristiques non sûres
• Mutation de la statique
• Accéder aux champs des syndicats.

Même dans un mode dit "unsafe", l'un des superpouvoirs de la programmation Rust fonctionne toujours : le "borrow checker". Il prévient généralement les problèmes de mémoire, les collisions dans les calculs parallèles et de nombreux autres bogues grâce à l'analyse statique du code, et cette analyse effectuera toujours des vérifications dans un bloc non sécurisé - il faut simplement beaucoup plus de travail pour écrire des constructions non sécurisées sans que le compilateur n'intervienne pour donner des conseils dans certaines situations.

Cela ne semble pas être un problème majeur pour la plupart des développeurs expérimentés - après tout, nous sommes connus pour bricoler afin d'obtenir le meilleur de nos applications et d'ouvrir des fonctions plus cool - mais cela ouvre potentiellement un trou noir qui peut conduire à de graves erreurs de configuration et à des vulnérabilités en matière de sécurité : le comportement non défini. La programmation en Rust (même lorsqu'elle est utilisée de manière non sécurisée) verrouille assez bien les possibilités de vulnérabilités par rapport au C ou au C++, mais l'invocation d'un comportement non défini peut constituer un risque.

Est-ce la fin de la dépendance à l'égard du codage sécurisé par les développeurs ?

Vous vous souvenez que j'ai dit tout à l'heure que Rust avait des composants de langages bien connus ? L'une des principales faiblesses de Rust en matière de sécurité est qu'il contient des composants de langages bien connus, à savoir le C.

Rust est toujours un "langage de programmation sûr", mais là encore, l'introduction d'un utilisateur est le point où les choses peuvent se gâter. Le développeur peut toujours le modifier pour qu'il fonctionne sans signaler les erreurs (une proposition attrayante, car cela permet de débloquer plus de capacités), et essentiellement, même dans un état sûr, les développeurs peuvent toujours être aussi "peu sûrs" qu'ils le souhaitent, car ils disposent d'une couche de conseils et de protection avant que les choses ne tournent vraiment au vinaigre.

Et les deux scénarios ci-dessus deviennent de plus en plus dangereux au fur et à mesure que nous plongeons, car les résultats de Rust sont similaires à ceux des outils d'analyse - tout comme il n'existe pas d'outil SAST/DAST/RAST/IAST de l'armée suisse qui analyse toutes les vulnérabilités, tous les vecteurs d'attaque et tous les problèmes, Rust n'en a pas non plus. Même avec Rust , certaines vulnérabilités peuvent encore être introduites assez facilement.

Le risque de comportement non défini lors de l'utilisation de Unsafe Rust peut entraîner des problèmes de débordement d'entier, alors qu'en général, même les configurations sûres n'empêcheront pas l'erreur humaine dans les mauvaises configurations de sécurité, la logique commerciale ou l'utilisation de composants avec des vulnérabilités connues. Ces problèmes constituent toujours une menace très réelle s'ils ne sont pas corrigés, et dans un environnement "supposé sûr" comme le vrai Rust, cela peut même entraîner un comportement complaisant si un codeur croit que tous les problèmes majeurs seront détectés de toute façon.

J'ai découvert que Rust n'est pas sans rappeler un mentor en programmation - un ingénieur expérimenté qui a pris le temps de s'asseoir avec un codeur moins expérimenté, examinant son travail et lui montrant les bogues potentiels, soulignant les gains d'efficacité et, dans certains cas, s'assurant qu'il n'est pas compilé tant qu'il n'est pas correct. Toutefois, il est de loin préférable que les programmeurs de rouille apprennent la théorie et s'engagent eux-mêmes à respecter les meilleures pratiques, car ce mentor pourrait bien couper les ficelles du tablier, et vous ne voudriez pas être laissé en plan.

Prêt à trouver et à corriger les vulnérabilités courantes de Rust dès maintenant ? Relevez le défi.

Voilà, c'est fini (pour l'instant). Nous sommes arrivés à la fin de notre série Infrastructure as Code. Nous espérons que vous vous êtes amusé à conquérir les problèmes de sécurité dans Docker, Ansible, Kubernetes, Terraform et CloudFormation. Mais avant de terminer, il vous reste une dernière vulnérabilité à maîtriser : les bogues de logique métier.

Vous pensez être prêt à tester vos compétences maintenant ? Essayez le dernier défi ludique :

Si vous avez encore quelques doutes, poursuivez votre lecture :

Les vulnérabilités sur lesquelles nous voulons nous concentrer aujourd'hui sont les failles dans la logique d'entreprise. Celles-ci peuvent survenir lorsque les codeurs ne parviennent pas à mettre en œuvre correctement les règles de logique commerciale, ce qui peut rendre leurs applications vulnérables à différents types d'attaques si un utilisateur malveillant décide de les exploiter. En fonction de l'objectif et de la fonctionnalité mis en œuvre dans chaque application, une faille dans la logique d'entreprise peut permettre une escalade des privilèges, une utilisation inappropriée des ressources ou l'exécution d'un certain nombre de processus d'entreprise non souhaités.

Contrairement à de nombreuses vulnérabilités, la mise en œuvre incorrecte des règles de logique commerciale peut être étonnamment subtile. Elles nécessitent une vigilance particulière pour s'assurer qu'elles ne se faufilent pas dans les applications et le code.

Quels sont les exemples de failles dans la logique d'entreprise ?

Pour illustrer la facilité avec laquelle il est possible d'induire des failles dans la logique métier, prenez l'exemple suivant d'un environnement Docker défini à l'aide d'un fichier Docker Compose. Pour préparer les conteneurs à exécuter des fonctions, un développeur peut utiliser une politique de ressources standard, définie dans le fichier Docker Compose, comme dans l'exemple suivant :

deploy :
resources :
limits :
cpus : "0.5"
reservations :
cpus : "0.5"

Bien que cela semble correct à première vue, cette politique de ressources pour les conteneurs ne limite pas correctement l'utilisation des ressources. Un attaquant pourrait tirer parti de la faille dans la logique commerciale pour mettre en œuvre une attaque par déni de service (DoS).

Pour tenter d'empêcher les utilisateurs d'utiliser trop de ressources, un développeur peut essayer de mieux définir ce que chaque conteneur peut supporter. Le nouveau code pourrait donc inclure une contrainte de placement :

deploy :
resources :
limits :
cpus : "0.5"
reservations :
cpus : "0.5"
placement :
contraintes :
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"

À première vue, cela semble résoudre le problème de logique d'entreprise. Cependant, la nouvelle contrainte de placement n'affecte pas la limite d'utilisation des ressources pour le service de conteneur Docker. Elle n'est utilisée que pour sélectionner un nœud afin de planifier le conteneur. Dans ce cas, une attaque par déni de service reste possible. L'attaquant devra d'abord compromettre un conteneur Docker, mais il pourra ensuite drainer les ressources sans limites.

Comme vous pouvez le constater, il peut être difficile de réfléchir aux failles de la logique d'entreprise et de programmer pour les éliminer.

Éliminer les failles de la logique d'entreprise

En ce qui concerne les failles dans la logique d'entreprise, l'essentiel est de savoir qu'elles existent. Vous devez être vigilant et veiller à ce qu'elles ne soient pas présentes dans votre environnement pendant l'écriture du nouveau code. Les règles de gestion et les meilleures pratiques doivent être clairement définies et vérifiées à toutes les phases du processus de développement de l'application, y compris la conception, la mise en œuvre et les tests.

Par exemple, pour éviter qu'une faille dans la logique métier ne permette une attaque DoS comme dans l'exemple ci-dessus, une bonne pratique consiste à limiter la quantité de ressources que chaque conteneur Docker que vous créez peut utiliser. Plus précisément, la section des limites doit spécifier le nombre de CPU et la quantité de mémoire qu'un conteneur Docker peut utiliser. Voici un exemple :

deploy :
resources :
limits :
cpus : "0.5"
memory : 100M
reservations :
cpus : "0.5"
memory : 50M

L'utilisation d'un code tel que l'exemple ci-dessus en tant que politique permettrait d'éliminer une faille majeure de la logique commerciale de l'environnement et de prévenir les attaques par déni de service. Cela fonctionnerait même si un attaquant compromettait l'un des conteneurs Docker. Dans ce cas, l'attaquant ne serait toujours pas en mesure d'utiliser son point d'appui pour épuiser les ressources.

La modélisation des menaces peut être utile en définissant la manière dont les différentes attaques se produisent et en veillant à ce que les règles de logique d'entreprise soient utilisées pour les prévenir et les limiter. Les tests basés sur les règles de conformité et les cas d'abus connus peuvent également être utiles pour détecter les failles de la logique d'entreprise qui passent à travers les mailles du filet.

Les failles dans la logique d'entreprise font partie des vulnérabilités les plus subtiles qui peuvent se glisser dans les applications, mais elles ne sont pas moins dangereuses que d'autres risques plus médiatisés. En sachant comment elles peuvent se produire et en appliquant les meilleures pratiques, vous pouvez les exclure de votre environnement pendant le développement de l'application et vous assurer qu'elles n'atteindront jamais un environnement de production où elles pourront être exploitées par des attaquants qui savent très bien comment les exploiter.

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 ce défi IaC sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Nous approchons de la fin de notre série Infrastructure as Code, mais nous avons été ravis d'aider des développeurs comme vous sur la voie de la sécurité IaC.

Avez-vous relevé les défis ? Quel est votre score jusqu'à présent ? Avant de commencer, voyons ce que vous savez déjà sur les pièges de l'utilisation de composants provenant de sources non fiables :

Vous avez encore du pain sur la planche ? Lisez la suite :

Le comportement générateur de vulnérabilité sur lequel nous allons nous pencher aujourd'hui est l'utilisation de code provenant de sources non fiables, une pratique apparemment anodine qui pose de gros problèmes. L'utilisation de codes et de ressources open source présente de nombreux avantages. En général, cela permet aux experts d'apporter leurs idées, leur travail et même un code complet à des référentiels tels que GitHub, afin que d'autres personnes s'efforçant de faire fonctionner correctement un programme ou une application puissent s'en servir. L'utilisation d'un code complet pour régir les fonctions d'un programme évite aux développeurs de devoir réinventer la roue à chaque fois qu'ils doivent créer une nouvelle application.

Cependant, l'utilisation d'extraits de code provenant de sources non fiables, non vérifiées ou même potentiellement dangereuses comporte de nombreux risques. En fait, l'utilisation de code provenant de sources non fiables est l'un des moyens les plus courants par lesquels des vulnérabilités de sécurité, majeures ou mineures, se glissent dans des applications par ailleurs sûres. Parfois, ces vulnérabilités sont induites accidentellement par leurs créateurs. Il est également arrivé que des codes malveillants soient écrits par des attaquants potentiels. Ce code est ensuite partagé dans l'espoir de piéger les victimes qui l'intégreront dans leurs applications.

Pourquoi l'utilisation de code provenant de sources non fiables est-elle dangereuse ?

Imaginons qu'un développeur soit pressé et doive configurer une application qu'il est en train de développer. Ce processus peut s'avérer délicat. Alors, au lieu de passer beaucoup de temps à essayer de mettre au point toutes les configurations possibles, il fait une recherche sur Google et trouve quelqu'un qui a déjà créé un fichier de configuration apparemment parfait. Même si le développeur ne sait rien de la personne qui a écrit le code, il est relativement facile de l'ajouter à une nouvelle application. Cela peut se faire dans l'environnement Docker en utilisant deux lignes :

RUN cd /etc/apache2/sites-available/ && \N-
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\N-
9d372cfa8855a6be74bcca86efadfbbf/raw/\N-
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Maintenant, l'image Docker va tirer dynamiquement le fichier de configuration de la tierce partie. Et même si le fichier est testé et jugé correct à ce moment-là, le fait que le pointeur soit désormais intégré dans le code de la nouvelle application signifie qu'une dépendance permanente est en place. Quelques jours, semaines ou mois plus tard, le fichier peut être modifié par l'auteur original ou par un attaquant qui a compromis le dépôt de code. Soudain, le fichier de configuration partagé peut indiquer à l'application de fonctionner très différemment de ce qui était prévu, en donnant éventuellement accès à des utilisateurs non autorisés ou même en volant directement des données et en les exfiltrant.

Une meilleure utilisation des ressources partagées

Si votre organisation autorise l'utilisation de code provenant de sources extérieures, des processus doivent être mis en place pour garantir la sécurité de l'opération. Lorsque vous évaluez un code extérieur en vue d'une utilisation potentielle, veillez à n'acquérir des composants provenant de sources officielles qu'en utilisant des liens sécurisés. Et même dans ce cas, vous ne devez jamais établir de lien avec une source extérieure pour obtenir ce code, car cela vous prive de tout contrôle sur le processus. Au lieu de cela, le code approuvé doit être introduit dans une bibliothèque sécurisée et n'être utilisé qu'à partir de cet emplacement protégé. Ainsi, dans un environnement Docker, le code ressemblerait à ceci :

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

Au lieu de s'appuyer sur des fichiers de configuration tiers distants, il s'agit de s'appuyer sur une copie locale de ces fichiers. Cela empêchera toute modification inattendue ou malveillante.

Outre l'utilisation d'une bibliothèque de code sécurisée, un processus de gestion des correctifs doit être mis en place pour surveiller en permanence les composants tout au long du cycle de vie du logiciel. Tous les composants côté client et côté serveur doivent également faire l'objet d'une vérification des alertes de sécurité à l'aide d'outils tels que NVD ou CVE. Enfin, supprimez toutes les dépendances et fonctionnalités inutilisées ou superflues qui pourraient être intégrées au code externe.

En suivant ces étapes, les développeurs peuvent utiliser des ressources externes en toute sécurité sans introduire accidentellement des vulnérabilités dans leurs applications et leur code.

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 des défis IaC sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Dans son habitat naturel, un développeur est souvent observé dans un état de profonde concentration, en train de coder des fonctionnalités impressionnantes dans des délais serrés. La création de fonctionnalités est souvent notre partie préférée du travail, et en réalité, c'est le résultat fondamental du cycle de vie du développement logiciel (SDLC).

Cependant, comme nous l'avons déjà dit, beaucoup d'entre nous continuent à donner la priorité aux fonctionnalités plutôt qu'aux meilleures pratiques en matière de sécurité. Après tout, dans la plupart des organisations, c'est le travail de quelqu'un d'autre et la formation adéquate en matière de sécurité est limitée. Les tests de pénétration et les outils d'analyse statique (mieux connus sous le nom de SAST) ne sont qu'une partie du processus global de réduction des risques de sécurité, fonctionnant de manière assez indépendante de ce que nous faisons... jusqu'à ce que le code nous revienne pour des correctifs, bien sûr.

C'est à ce moment-là que de nombreux développeurs se disent: "Les pentesters me détestent-ils ?

Ces interactions définissent souvent une équipe, une culture. Le problème, c'est que le manque de communication, de compréhension et de collaboration générale a créé des tensions, du moins du côté du développeur. Pensez-y : Imaginez que vous avez passé quelques centaines d'heures à sculpter une merveilleuse statue, et que quelqu'un arrive avec un marteau et commence à en briser des morceaux après vous avoir dit que ses fondations ne sont pas à la hauteur. C'est la dynamique perçue entre un testeur et un développeur - ce dernier voit ses chouchous logiciels massacrés par une personne extérieure qui n'a pas travaillé avec lui tout au long du processus ; au lieu de cela, il a augmenté la charge de travail et retardé la satisfaction de la livraison du code.

Ayant évolué dans le domaine de la sécurité il y a longtemps, je peux voir les deux côtés de l'histoire. Et non, les pentesters ne détestent pas les développeurs. Le pentester est, selon toute vraisemblance, surchargé de travail et soumis à une forte pression. En tant que tel, un flux constant de bogues de sécurité courants qui pourraient être facilement corrigés au niveau du code prend du temps, des ressources et de l'espace de tête pour les problèmes vraiment sérieux.

J'ai toujours vu les pentesters comme des parents. Ils veulent que vous réussissiez, et quand vous ne réussissez pas... ils ne sont pas fâchés, juste déçus.

Maintenant que j'ai mis cette image (peut-être un peu injuste) dans votre esprit, explorons la question un peu plus en profondeur. Qu'est-ce qui est à l'origine de cette vision du monde chez les développeurs ?

"Bien sûr que je suis sur la défensive, ils me disent comment faire mon travail !

Personne n'aime avoir l'impression d'avoir fait du mauvais travail ou que quelqu'un n'aime pas son travail. Malheureusement pour les développeurs, lorsque les résultats de l'analyse statique et du pentest leur parviennent, ils peuvent avoir l'impression de recevoir un bulletin de notes. Ils ont reçu de mauvaises notes, mais en fin de compte, leurs patrons les évaluent sur les fonctionnalités qu'ils ont développées et le temps qu'ils ont mis pour les livrer, et non sur la présence ou non d'éléments vulnérables dans le logiciel.

Pour le pauvre pentester, c'est un cas de "ne pas tirer sur le messager". Il n'y a rien de personnel - ils sont chargés de trouver des bogues, et ils les ont trouvés. Certes, d'une personne à l'autre, certains pentesters sont peut-être plus grincheux que d'autres, mais ils ne cherchent pas (ou ne devraient pas chercher) à crucifier les équipes de développement. Il serait beaucoup plus facile pour les deux équipes d'être sur la même longueur d'onde en ce qui concerne les meilleures pratiques en matière de sécurité. On n'attend pas des développeurs qu'ils soient parfaits ; de manière réaliste, l'équipe de test est là pour les protéger contre l'envoi de code vulnérable.

"Ils m'ont dit de régler tous ces problèmes mineurs, ne savent-ils pas qu'il y a des priorités plus importantes ? Et pourquoi ne m'aident-ils pas à les résoudre s'ils s'en soucient tant ?"

C'est vrai : la priorité absolue d'un développeur sera toujours de créer des fonctionnalités et, dans ce monde fou de numérisation rapide, il devra le faire à toute vitesse. Si certains codeurs s'intéressent personnellement à la sécurité et au codage sécurisé, le sentiment général est que la sécurité est "le problème de quelqu'un d'autre", ce qui inclut inévitablement les pentesters.

La plupart des vulnérabilités courantes sont en effet des problèmes mineurs à corriger - une fois connus, les correctifs sont simples à exécuter pour des choses comme le cross-site scripting (XSS) et l'injection SQL... le problème est que de nombreux développeurs ne réalisent pas qu'ils les introduisent en premier lieu, et ces problèmes apparemment mineurs sont la petite fenêtre d'opportunité dont un attaquant a besoin pour causer des problèmes dévastateurs pour une entreprise. Selon Akamai, entre novembre 2017 et mars 2019, les vulnérabilités d'injection SQL ont représenté 65 % de tous les vecteurs d'attaque basés sur le web. Pour une vulnérabilité dont la correction est connue depuis plus de vingt ans, c'est une statistique qui donne à réfléchir.

Certaines équipes de pentest aident à remédier aux bogues de sécurité, mais d'autres fourniront un rapport sur les mauvaises nouvelles et attendront des développeurs qu'ils travaillent sur les correctifs, même s'ils sont passés à un autre projet au moment où cela se produit. Dans certains cas, l'équipe de développement peut être confrontée à un rapport contenant des bogues qu'elle ne peut pas (ou ne devrait pas) corriger - cela doit toujours faire partie des conclusions et, encore une fois, ne pas être pris personnellement.

Le "juste milieu" serait que les pentesters, le personnel de sécurité et les responsables du développement jouent davantage un rôle de mentor pour s'assurer que l'équipe dispose de ce dont elle a besoin en termes de formation et d'outils efficaces, donnant ainsi aux codeurs individuels les meilleures chances de réussir et de coder en toute sécurité dès le début du cycle de développement durable. Les deux équipes devraient vraiment se rencontrer à mi-chemin pour s'assurer que la sécurité est prise en compte dès le départ, dans le cadre d'une pratique DevSecOps saine.

"J'ai de bien meilleures connaissances en matière de sécurité qu'on ne le croit ; ces rapports sont pour la plupart des faux positifs ou ne sont pas importants.

L'analyse statique est un élément du processus de sécurité dans le SDLC, et les outils d'analyse statique (SAST) jouent un rôle fondamental. Et oui, les faux positifs sont un problème avec ces outils et d'autres types de scanners (DAST/IAST/RAST). Il s'agit d'une gêne dans un processus déjà lent, qui nécessite un examen manuel du code et met la pression sur les développeurs comme sur les pentesters. Le personnel de pentesting a pris le temps de configurer méticuleusement des règles personnalisées pour éviter les lectures inexactes et a fourni des conseils spécifiques à l'entreprise, mais certaines lectures erronées se glissent et finissent devant un développeur qui se prend la tête.

Ce processus n'est pas parfait, mais l'autre problème est que de nombreux développeurs n'ont pas les connaissances suffisantes pour atténuer de manière cohérente un grand nombre de vulnérabilités courantes. La formation à la sécurité étant rare dans l'enseignement supérieur et la formation sur le tas plus ou moins efficace, il est logique qu'un certain excès de confiance soit également en jeu (et ce n'est pas de leur faute - en tant qu'industrie, nous devons mieux les équiper avec ce dont ils ont besoin).

"Je ne savais pas que cette application allait être testée, mais maintenant je suis coincé avec les tâches de remédiation".

Parfois, les ingénieurs surchargés de travail supposent que les pentesters sont juste dans les coulisses, attendant le moment de frapper en testant une application et en faisant pleuvoir sur la parade de l'équipe de développement. Ils font trop de tests, ils pinaillent, ils créent un surcroît de travail.

Le seul problème, c'est qu'ils sont eux aussi surchargés de travail (plus encore, en fait - la pénurie de compétences en cybersécurité atteint des niveaux catastrophiques et ne fait qu'empirer) et qu'ils n'ont tout simplement pas le temps de tester sans raison. Ils ne sont pas les seuls à décider de la priorité à accorder aux tests ; ceux-ci peuvent avoir été demandés par la direction, un client, dans le cadre d'un audit de sécurité ou même déterminés à la suite d'un programme de récompense des bogues.

Pour un développeur, il est ennuyeux d'être retiré des sprints de création de fonctionnalités pour travailler sur des correctifs de sécurité, surtout si ce n'est pas son travail. La dernière mise à jour a peut-être été effectuée par une équipe précédente ou par un autre fournisseur. Cependant, la sécurité est le problème de tous. Cela ne signifie pas que chaque développeur doive s'approprier les bogues de sécurité comme s'il les avait tous créés lui-même, mais il doit participer à la fête pour que la sécurité soit une responsabilité partagée.

Quelle est la suite des événements ?

Parfois, il suffit de changer d'état d'esprit pour progresser de manière significative dans la résolution d'un problème. Nous avons parlé de la réaction plutôt glaciale d'un développeur face à des résultats de pentest peu favorables, mais que se passerait-il s'il pouvait en faire un défi ? Peut-être pourraient-ils considérer le pentester comme un concurrent amical, quelqu'un qu'ils peuvent battre à leur propre jeu. Après tout, un développeur sensibilisé à la sécurité et capable d'éliminer les bogues courants au fur et à mesure qu'il écrit le code va rendre son travail beaucoup plus difficile. En revanche, un développeur qui ne se préoccupe pas de la sécurité sera largement battu par ses homologues pentesters lorsqu'ils parviendront facilement à casser leur logiciel.

Les pentesters et les développeurs ne sont peut-être pas toujours en harmonie, mais leurs relations peuvent être grandement améliorées lorsqu'une organisation fait de la sécurité une priorité essentielle et donne aux équipes les connaissances et les outils dont elles ont besoin pour réussir, en particulier aux développeurs. La question est de savoir si une culture de la sécurité positive à l'échelle de l'entreprise est une priorité, et si nous voulons mener la bataille (actuellement) perdue d'avance contre les vulnérabilités courantes, elle doit absolument l'être.

Une version de cet article a été publiée dans le TFIR. Il a été mis à jour et syndiqué ici.

On dit que le changement est la seule constante de la vie, mais l'année 2020 a vraiment été une épreuve pour de nombreuses personnes dans le monde entier. La pandémie mondiale de COVID-19 nous a obligés à réfléchir - en profondeur - à la manière dont nous nous connectons. L'isolement, la distanciation sociale sont quelques-unes des adaptations que nous avons faites dans le monde physique et, bien que nous soyons nombreux à passer beaucoup de temps en ligne, c'est un tout autre scénario que de ne pas avoir d'autre choix lorsqu'il s'agit de communiquer et, si possible, de travailler. C'est à la fois une tragédie et une prise de conscience.

Comme pour de nombreuses entreprises technologiques, la flexibilité du travail n'est pas une nouveauté pour nous et le travail à domicile est l'un des avantages du métier. Dès 2009, j'ai travaillé à distance depuis la Belgique pour des entreprises de la Silicon Valley. La technologie était bien moins avancée à l'époque, mais c'était encore possible. Cependant, même pour nous aujourd'hui, le fait que chaque membre de l'équipe travaille à domicile jusqu'à nouvel ordre a été une adaptation. J'ai vu de nombreuses entreprises prendre cette décision, y compris celles qui n'étaient pas aussi bien préparées que d'autres à la gestion d'une main-d'œuvre à distance.

Que la gêne vienne des inconnues d'une nouvelle façon de travailler, d'un peu de méfiance, ou peut-être du fait de ne pas "croire" au travail à distance, je trouve que les entreprises qui y résistent ont tendance à prendre du retard en termes d'attraction des meilleurs talents, de maintien de la portée mondiale et, franchement, d'évolution avec le temps. La crise actuelle n'a laissé à beaucoup d'entre elles d'autre choix que de se doter d'une main-d'œuvre à distance, l'alternative étant un arrêt complet des activités dans un climat économique chaotique.

S'il y a un point positif à retenir de cette tragédie, c'est que les gens auront pris conscience des avantages d'une main-d'œuvre numérique et de la myriade de façons dont une équipe peut se connecter même si elle n'est pas physiquement réunie. Et le secteur de la cybersécurité est l'un de ceux qui peuvent vraiment prospérer grâce à une approche de travail en tout lieu et en tout temps.

Les attaquants ne sont pas restés cloîtrés : ils sont très actifs et profitent de cette crise, tirant parti de la panique et de l'incertitude qui règnent dans le monde entier pour mener des cyberattaques contre des établissements médicaux. Dans une telle situation, il n'est pas exagéré d'observer une recrudescence des cyberattaques, en particulier des ransomwares. Après tout, il s'agit de voler pour survivre dans une période économique précaire. Ce n'est pas pour autant que c'est normal, et le fait est que nous pouvons toujours travailler, nous former et lutter contre les cyberattaques partout où il y a une connexion internet.

L'avenir est flexible, et c'est ainsi que nous - et le secteur de la cybersécurité dans son ensemble - pouvons le faire fonctionner aujourd'hui et à l'avenir :

Les produits accessibles partout sont universels et précieux

Avant toute forme de quarantaine forcée, les équipes internationales devaient encore trouver un moyen de collaborer en cas de besoin. Les conférences téléphoniques abordables ont fait leurs débuts la même année que les Rolling Stones (1964, donc - et il ne fait aucun doute que les premiers utilisateurs avaient les mêmes problèmes que nous rencontrons aujourd'hui : "êtes-vous là ? "Non, allez-y !" que nous rencontrons aujourd'hui, même si nous pouvons nous voir par vidéo).

En 2020, les technologies de communication numérique représentent une part importante de l'industrie des TIC, qui pèse plusieurs milliards de dollars, avec des plateformes mobiles et sociales basées sur l'informatique en nuage qui dominent et remplacent les technologies traditionnelles. Des innovations telles que Slack, Zoom et Discord nous ont permis de rester plus que jamais connectés, en particulier au travail. Et la communication n'est qu'un aspect de l'histoire.

Les services numériques qui sont accessibles partout avec une connexion internet, à la demande, et qui répondent à un besoin de base - qu'il s'agisse d'une connexion, d'un divertissement ou d'une productivité - font partie de notre avenir flexible. En tant que clients, nous recherchons l'hyperpersonnalisation et, en tant qu'entreprise, nous cherchons à offrir une expérience numérique personnelle d'une qualité sans compromis, quel que soit l'endroit d'où l'on y accède.

Dans tous les secteurs, chaque jour, des applications web sont créées pour rationaliser les processus, révolutionner nos modes de vie et de travail et résoudre des problèmes dont nous n'avions peut-être pas conscience. Nous sommes loin de l'apogée des outils et des formations en matière de cybersécurité accessibles à la demande, de manière attrayante et utile pour l'utilisateur, avec des avantages tangibles pour l'entreprise.

Les développeurs apprécient la flexibilité dans leur travail quotidien, et l'accent que nous mettons sur la formation pratique et amusante au codage sécurisé, ainsi que sur l'intégration du flux de travail, est conçu en gardant ces utilisateurs finaux à l'esprit. Les outils doivent être faciles à prendre en main et à utiliser, et la formation ne doit pas être perçue comme une corvée. Le secteur de la cybersécurité étant un champ d'action très vaste, le moment est venu d'innover dans de multiples domaines d'attaque et de défense, où les méthodologies axées sur la sécurité, comme DevSecOps, peuvent encore prospérer même si tout le monde est à la maison. Il s'agit de collaboration et d'une suite d'outils réfléchis permettant à chaque membre de l'équipe de faire son travail efficacement, quel que soit son emplacement physique.

L'entraînement quand vous en avez le plus besoin (ou quand vous voulez changer de journée)

L'un des avantages du travail flexible réside dans le fait que les jours où vous effectuez des tâches à domicile, vous n'avez pas à vous rendre au bureau. Pour certains, cela peut représenter environ deux heures de temps de qualité et de concentration. Dans un monde idéal, tous les membres du personnel auraient du temps à consacrer à l'apprentissage et au développement de leurs compétences pendant leurs heures de travail normales, ce qui peut se faire beaucoup plus facilement dans un environnement à distance approprié. C'est bénéfique pour vos "superstars" à distance, qui peuvent se sentir stimulées et soutenues par la formation continue.

Le paysage de la cybersécurité évoluant à chaque seconde, des formations fréquentes sont indispensables pour se tenir au courant des menaces potentielles qui pèsent sur l'organisation. Une formation complète, mesurable et adaptée aux besoins de l'entreprise est un grand pas dans la bonne direction. Ces facteurs ont été au cœur de la conception de la plateforme Secure Code Warrior ; nous voulions que la formation soit accessible partout, au moment où vous en avez besoin, dans le langage de développement et le cadre de travail choisis par l'utilisateur.

Les développeurs ont une relation difficile avec la sécurité, et à bien des égards, ils n'ont pas été pris en charge d'une manière suffisamment spécifique pour s'engager correctement dans les meilleures pratiques en matière de sécurité. La formation à la demande et la gamification peuvent contribuer à les convaincre, où qu'ils soient ; il est également impératif de veiller à ce que les équipes délocalisées et les fournisseurs soient également sensibilisés à la sécurité, en particulier lorsqu'ils sont impliqués dans toute forme de modification des logiciels d'une organisation.

Maintenir votre cohorte engagée et à niveau avec des formations qui aideront l'organisation (sans parler de leur propre carrière) est une colle très efficace lorsqu'il s'agit de retenir vos meilleurs et plus loyaux talents... une nécessité absolue alors que nous sommes confrontés à une pénurie continue de compétences en cybersécurité.

Les travailleurs à distance peuvent être responsabilisés, productifs et sécurisés

L'idée que pour être productif, il faut être visible dans un bureau de 9 heures à 17 heures est un peu dépassée. Et pourtant, tant d'entreprises (même parmi les nouvelles et passionnantes) fonctionnent encore avec cette idée en tête. Il existe un profond sentiment de méfiance à l'égard de leur propre personnel, comme si la simple suggestion de travailler à domicile les amenait à imaginer leurs équipes en train de jouer en sous-vêtements au lieu de faire leur travail.

Ou bien ils n'ont tout simplement pas franchi le pas du travail à distance viable.

Naturellement, les membres de l'équipe doivent prouver qu'ils peuvent maintenir leur productivité à la maison en montrant leur rendement, mais vous devez donner à votre cohorte les meilleures chances de réussir en dehors du bureau. Posez-vous la question :

• Disposent-ils d'un matériel adéquat ?
• Avez-vous réellement mis en œuvre l'un de ces outils de communication géniaux dont nous avons parlé précédemment ?
• Avez-vous veillé à ce que chaque manager soit présent numériquement avec son équipe, en organisant des réunions régulières ?
• Avez-vous pensé à des outils de productivité pour assurer le suivi des projets et donner à chaque membre de l'équipe une orientation, des objectifs et un sentiment d'accomplissement lorsqu'il accomplit des tâches ?

Dans le climat actuel, de nombreuses entreprises ont été confrontées à la décision d'opter pour des opérations à distance ou de fermer complètement leurs portes. Certaines entreprises qui ont choisi de passer à une main-d'œuvre à distance n'étaient peut-être pas très bien préparées, et il est possible qu'il y ait quelques problèmes à résoudre... mais l'éléphant dans la pièce, c'est que ces entreprises s'exposent probablement aussi à des risques de sécurité.

Éviter les erreurs de sécurité dans les environnements de travail à distance

Il y a plusieurs vecteurs de menace à prendre en compte, étant donné que le personnel se trouve probablement sur son propre réseau et qu'il peut utiliser toute une série d'appareils pour accéder aux comptes de l'entreprise, chacun ayant ses propres besoins en matière de sécurité, qu'ils soient ou non en vigueur.

Dans les situations de travail à distance, tout le monde a tendance à recevoir un nombre croissant de courriels, sans compter qu'il faut gérer divers identifiants, systèmes et configurations. Il n'est que trop facile pour les attaques par ingénierie sociale et les logiciels malveillants de passer à travers les mailles du filet sur un tas d'appareils hors du champ d'application de la sécurité interne. Ce n'est pas une raison pour abandonner le travail à distance, c'est une occasion en or d'apprendre par la pratique et de le rendre aussi robuste que possible pour l'avenir. Et dans les organisations axées sur la sécurité, c'est une bonne occasion d'auditer les processus et de "manger sa propre nourriture" lorsqu'il s'agit des meilleures pratiques en matière de sécurité pour tous.

En parlant de maladresses, il est également important d'évaluer votre espace de travail à distance pour détecter toute menace potentielle... surtout pour votre fierté, comme ce pauvre couple. Morale de l'histoire : assurez-vous que tout le monde porte un pantalon lors d'un appel vidéo.

Les cyberattaques ne s'arrêtent pas parce que nous sommes en crise

Il est profondément bouleversant de voir les effets du COVID-19 dans le monde entier, et le moment est plus que jamais venu de se serrer les coudes et de prendre en compte les autres dans cette crise sanitaire mondiale. Le fait est que les agresseurs profitent activement de cette peur généralisée et de ce pandémonium, peut-être parce qu'ils sont désespérés de devoir mettre de la nourriture sur la table. En tant que société, nous sommes incroyablement vulnérables en ce moment.

Des établissements de santé, dont un centre d'essai de vaccins, ont été victimes d'attaques par ransomware et DDoS, sans parler de ceux qui tentent de profiter de la distraction et de la surcharge de travail des organisations financières et gouvernementales en lançant des campagnes de phishing et de logiciels malveillants à leur encontre. Une autre menace imminente concerne le vaccin lui-même ; il a été rapporté que l'administration Trump avait offert à une entreprise allemande d'importantes sommes d'argent pour développer un vaccin contre le COVID-19 à l'usage exclusif des États-Unis. Les données relatives au vaccin sont peut-être les informations les plus précieuses sur Terre à l'heure actuelle, ce qui constituerait une prime très intéressante pour un pirate informatique.

Il s'agit d'un rappel bien trop opportun que si nous nous isolons de la menace très réelle d'un virus physique, notre rythme cardiaque numérique est également attaqué. La sensibilisation à la sécurité est de la plus haute importance dans chaque organisation, et une formation adéquate doit être dispensée à tous les niveaux - même des mesures telles que l'utilisation d'outils de gestion des mots de passe et l'apprentissage de la manière de repérer un courriel d'hameçonnage sont utiles.

En ce qui concerne les développeurs, ils constituent la première ligne de défense pour sécuriser le code produit activement au sein de l'entreprise, et ils peuvent être un atout précieux avec votre équipe AppSec pour éviter de souffrir davantage d'une cyberattaque en fermant les portes dérobées créées par les vulnérabilités courantes.

Les entreprises qui innovent sur le plan numérique peuvent résister à des tempêtes plus importantes

Le ralentissement économique, qui a forcé de nombreuses personnes à perdre leur emploi dans les secteurs les plus touchés, a été un sous-produit extrêmement malheureux de cette fermeture massive. Tout cela s'est aggravé assez soudainement, et c'est une expérience que beaucoup d'entre nous n'ont probablement pas vécue de leur vivant.

Bien que toutes les entreprises natives du numérique ne soient pas automatiquement en mesure de faire face à la récession (loin de là), par nature, les entreprises qui opèrent dans le numérique sont beaucoup plus agiles, adaptables et durables, même lorsque les circonstances les plus inattendues se présentent.

Notre entreprise peut être gérée de manière efficace et efficiente avec une main-d'œuvre à distance, ce qui constitue un niveau de protection supplémentaire pour notre précieuse équipe et les clients qu'elle soutient également. Nous considérons que la formation à un code sécurisé et viable est un élément essentiel des entreprises modernes, et si nous sommes choisis, nous pouvons livrer et pivoter en fonction des besoins. De nombreuses entreprises, de par la nature des produits ou des services qu'elles vendent, n'ont pas le même luxe, mais ce pourrait être une bonne surprise pour elles d'étudier où les processus peuvent être numérisés, à l'épreuve du temps et aussi à la demande que possible, même dans les espaces les plus traditionnels.

Trouver de nouvelles façons de se connecter est un défi positif, pas un obstacle.

C'est un peu dramatique, mais cela me rappelle la célèbre citation de Jurassic Park où le Dr Ian Malcolm dit que "la vie trouve son chemin". C'est vraiment le cas, et cela s'est manifesté de manière très évidente lors du passage au travail à distance à l'échelle de notre entreprise. Des équipes qui n'interagissaient pas beaucoup auparavant se découvrent des centres d'intérêt communs à l'occasion de discussions au compte-gouttes, de jeux de bureau en ligne et d'une liste de lecture Spotify commune à l'ensemble de l'entreprise. Il y a toujours un moyen de forger une relation significative, et mon conseil est de laisser les équipes l'explorer et la développer de manière organique.

Pour nos clients, il est formidable de constater que leur engagement à améliorer les compétences de codage sécurisé des développeurs a transcendé tout problème lié au travail à distance. Ils ont utilisé notre fonction tournaments , et alors que ces réunions sont généralement organisées en personne avec un peu de fanfare, leurs versions virtuelles ont suscité un engagement sain, une compétition amicale et une excellente distraction (productive) des activités quotidiennes habituellement accomplies de manière solitaire. Tout comme les jeux vidéo sont aujourd'hui un événement beaucoup plus social qu'ils ne l'étaient autrefois, ce type de formation sur le lieu de travail favorise la connexion non seulement avec le matériel de cours, mais aussi entre les participants. Et il est accessible à tous, n'importe où. En tant que geek de la sécurité, je suis certainement partial, mais c'est le moment ou jamais d'aider à promouvoir l'amour du codage sécurisé parmi les développeurs. Ils sont tous des super-héros de la sécurité en devenir, et il est temps de renforcer vos lignes de front de la manière la plus amusante possible.

Une version de cet article a été publiée dans DevOps.com. Elle a été mise à jour pour la syndication ici, et inclut des liens interactifs vers les défis de vulnérabilité.

Je pense que nous nous souvenons tous d'un moment récent où, lors d'une réunion ou d'une conférence, quelqu'un a eu des problèmes avec la technologie de présentation. Cela arrive si souvent que l'on s'attend presque à une expérience maladroite, du moins au début. Il n'est donc pas surprenant que l'application transparente de ClickShare ait été immédiatement populaire auprès des utilisateurs finaux. Pour eux, il n'y a rien de plus facile que d'utiliser une application ClickShare pour transférer une présentation de leur ordinateur portable, tablette ou smartphone vers un grand écran ou un projecteur de salle de conférence. Le fournisseur belge de technologies de projection numérique et d'imagerie Barco a conçu sa plateforme d'automatisation pour qu'elle fonctionne de cette manière, et les grandes entreprises ont adopté le concept. FutureSource Consulting estime que la part de marché de Barco dans le domaine de la technologie de conférence est de 29 %, avec une intégration dans 40 % des entreprises du classement Fortune 1 000.

Lorsque des chercheurs de F-Secure ont révélé en décembre que cette plateforme d'automatisation apparemment inoffensive était truffée de failles de sécurité, cela a provoqué une onde de choc dans le monde des affaires. Les failles de sécurité découvertes sont de nature critique et pourraient potentiellement permettre un certain nombre d'activités malveillantes.

Les chercheurs ont démontré comment les vulnérabilités pouvaient permettre à des utilisateurs distants d'espionner des présentations actives, de créer des portes dérobées dans des réseaux sécurisés ou même de configurer un serveur de distribution de logiciels espions qui infecterait chaque utilisateur se connectant à un appareil Barco. Soudain, les entreprises se sont trouvées confrontées à la perspective d'avoir de sérieux problèmes de sécurité installés directement dans les salles de conférence et les bureaux de toute leur organisation. Et en raison de la nature des vulnérabilités, un seul appareil compromis pouvait être à l'origine d'une violation à l'échelle du réseau.

"Un attaquant qui a réussi à compromettre une unité acquiert la capacité de décrypter et de produire des images cryptées valides pour n'importe quelle unité, que ce soit au sein d'une même famille ou d'une famille à l'autre", écrivent les responsables de F-Secure dans leur rapport. "En outre, un tel attaquant peut accéder à des données sensibles au repos, telles que le PSK Wi-Fi configuré et les certificats.

À sa décharge, Barco s'est montrée extrêmement proactive en publiant des correctifs et en corrigeant les vulnérabilités trouvées dans ses produits. L'éditeur de solutions de sécurité Tenable a récemment publié un rapport faisant état de 15 failles dans huit outils de présentation, dont Barco. Depuis février, seule Barco a déployé des correctifs.

Bien que certaines des vulnérabilités de Barco nécessitent des modifications matérielles (et celles-ci seront un cauchemar à déployer, si une entreprise agit à ce point pour les sécuriser), beaucoup d'entre elles peuvent être corrigées avec des correctifs logiciels. La plupart des entreprises utilisatrices disposent ainsi d'un plan apparemment satisfaisant pour résoudre leurs problèmes immédiats, mais elles ne sont pas au bout de leurs peines. Les problèmes de Barco ne sont que la partie émergée de l'iceberg lorsqu'il s'agit de traiter les vulnérabilités de produits matériels et logiciels bien connus.

La racine du problème

Maintenant que les problèmes immédiats ont été résolus, nous devons nous demander comment des appareils présentant de graves failles de sécurité se sont retrouvés dans des milliers de salles de conférence à travers le monde, ou pourquoi ils ont été si mal conçus et programmés en premier lieu. Ce n'est pas comme si l'équipe de F-Secure avait découvert des vulnérabilités de type "zero-day" ou inconnues jusqu'alors. Dix des failles découvertes dans les produits Barco étaient associées à des vulnérabilités bien connues et courantes, telles que les attaques par injection de code. La plupart d'entre elles étaient déjà identifiées par le système CVE (Common Vulnerabilities and Exposures).

Comment des CVE vieilles de plusieurs dizaines d'années ont-elles pu être codées, voire câblées, dans des outils de présentation modernes ? La seule réponse possible est que les développeurs ne les connaissaient pas ou que la sécurité n'était pas une priorité lors de la conception des appareils Barco. Malheureusement, il s'agit d'une situation courante, qui n'est certainement pas l'apanage des équipes de Barco.

Le meilleur moment pour corriger une vulnérabilité est pendant le développement d'une application, bien avant qu'elle ne soit envoyée aux utilisateurs. Le pire moment (et le plus coûteux) est celui où le produit a été déployé ou exploité par des pirates. Il s'agit là d'une leçon difficile, que Barco ne manquera pas d'apprendre, car sa part de marché, autrefois impénétrable, a été réduite à la suite de ce fiasco de sécurité.

Il n'est pas facile de ramener les correctifs de sécurité vers le processus de développement, mais c'est nécessaire dans le monde d'aujourd'hui où même des dispositifs apparemment simples comme les outils de présentation sont à la fois étonnamment complexes et en réseau avec tout le reste. Dans cet environnement, la sécurité doit devenir une meilleure pratique organisationnelle. Qu'une entreprise programme des applications pour les médias sociaux ou fabrique des grille-pains intelligents, la sécurité doit être prise en compte dans toutes les facettes de l'organisation.

Donner la priorité aux meilleures pratiques en matière de sécurité et en faire une responsabilité partagée est l'objectif du mouvement DevSecOps, dans lequel les équipes de développement, de sécurité et d'exploitation travaillent ensemble pour coder et déployer des logiciels et des produits sécurisés. Cela nécessite autant un changement de culture qu'autre chose. Le nouvel état d'esprit doit être que le déploiement d'un produit fonctionnel présentant des vulnérabilités de sécurité est un échec au même titre que la création d'un produit incapable de remplir sa fonction principale.

Dans un environnement DevSecOps sain, toute personne touchant à un logiciel devrait être sensibilisée à la sécurité, les développeurs recevant des formations pertinentes et fréquentes pour éviter d'introduire des bogues désastreux dans leur travail. Si les équipes travaillant pour Barco avaient considéré la sécurité comme une responsabilité partagée, il est impossible qu'une telle collection de vulnérabilités, y compris des CVE vieux de plusieurs décennies, se soit retrouvée dans leurs outils de présentation.

La voie de la sécurité

Personne ne veut être le prochain Barco à devoir expliquer pourquoi des failles de sécurité bien connues ont été déployées par l'intermédiaire de leurs appareils sur des milliers de réseaux d'entreprise dans le monde entier. Pour éviter ce sort, les entreprises qui développent des logiciels ou du matériel intelligent doivent immédiatement donner la priorité à la sécurité en tant que responsabilité partagée et meilleure pratique organisationnelle. La création d'un programme DevSecOps sain prendra du temps et nécessitera probablement un changement de culture, mais les résultats en vaudront largement la peine. Un programme DevSecOps solide peut éliminer les vulnérabilités bien avant qu'elles ne causent des problèmes.

Les entreprises qui achètent des produits et des logiciels ont tout intérêt à soutenir celles qui ont adopté DevSecOps. Ce faisant, elles s'assureront que les appareils et les logiciels qu'elles achètent ne sont pas des bombes à retardement attendant d'être exploitées par des attaquants de plus en plus habiles.

Consultez les pages du Secure Code Warrior pour en savoir plus sur DevSecOps et sur la manière de protéger votre organisation et vos clients des ravages causés par les failles de sécurité et les vulnérabilités.

Vous souhaitez vous plonger dans les problèmes de sécurité rencontrés par Barco ?

Jouez à ces défis ludiques sur :

• Injection de commandes OS en C
• Injection de code à distance en C
• Débordement de mémoire tampon en C
• Téléchargement de fichiers à distance en C
• Les informations d'identification sont stockées en texte clair dans C.

De nos jours, les menaces qui pèsent sur la cybersécurité sont omniprésentes et incessantes. La situation est devenue si grave qu'il est pratiquement impossible d'essayer de les contrer après le déploiement des programmes. Au lieu de cela, les organisations astucieuses adoptent le concept d'infrastructure en tant que code, selon lequel les développeurs contribuent à l'élaboration d'applications sécurisées alors qu'elles sont encore en cours de création. Cette série a pour but de vous préparer à la sécurité, afin que vous puissiez comprendre les mesures que vous pouvez prendre en tant que développeur pour commencer à déployer une infrastructure sécurisée en tant que code dans votre propre organisation.

Les erreurs de configuration en matière de sécurité, en particulier celles qui concernent les autorisations inappropriées, se produisent le plus souvent lorsqu'un développeur crée un nouvel utilisateur ou accorde une autorisation à une application en tant qu'outil afin d'accomplir une tâche. Il peut s'agir, par exemple, de collecter des informations à partir d'une base de données. Mais si les autorisations pour le nouvel utilisateur sont trop élevées ou ne sont pas configurées par défaut pour la tâche à accomplir, cela peut introduire une vulnérabilité sérieuse dans le code.

Avant d'entrer dans le vif du sujet, pourquoi ne pas tester vos compétences dès maintenant ? Essayez de trouver et de corriger quelques vulnérabilités liées à des autorisations inappropriées :

Quels sont vos résultats ? Approfondissons un peu la question :

Donner toutes les permissions à un utilisateur ou à une application, ou simplement ne pas prendre la peine de définir ce que le nouvel utilisateur devrait pouvoir accomplir et quels comportements sont restreints, est certainement le moyen le plus rapide de mettre en place un nouveau code. Et si tout se passe parfaitement bien, l'application utilisera ces autorisations pour accomplir la tâche qui lui a été assignée. Le danger est qu'un pirate informatique découvre ce processus et compromette l'utilisateur. Même si l'utilisateur a été créé pour accomplir une fonction spécifique pour une application particulière, s'il est compromis, il peut permettre à un attaquant de mettre en danger d'autres applications, des données ou même le réseau.

Comment les failles de sécurité sont-elles exploitées ?

Pour visualiser le danger, examinons comment une tâche courante est parfois codée dans l'environnement cloud Docker. Supposons qu'un développeur utilise le service Prometheus MySQL Exporter pour collecter des informations à partir d'une base de données. Le moyen le plus simple d'y parvenir est d'accorder à l'exportateur la permission d'accéder à la base de données. Le code pourrait donc ressembler à quelque chose comme :

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD ;
GRANT ALL ON *.* TO exporter@% ;
GRANT SELECT ON performance_schema.* TO exporter@% ;

Cela permettrait certainement à l'exportateur d'accomplir sa tâche. Cependant, comme les permissions ne sont pas définies, l'exportateur a en fait la possibilité de faire presque n'importe quoi. Il est évident que l'exportateur lui-même n'agira jamais en dehors des comportements programmés. Mais que se passerait-il si un attaquant parvenait à compromettre le service de l'exportateur ? Dans ce cas, parce qu'il a reçu toutes les permissions, l'attaquant pourrait effectuer toutes sortes de tâches non autorisées avec le service SQL.

Sécuriser et éliminer les autorisations abusives

Là encore, nous nous tournons vers le concept d'infrastructure en tant que code. Si vous intégrez la sécurité dans vos applications au fur et à mesure de leur création, le réseau sera toujours en bien meilleure position en matière de cybersécurité.

Dans l'exemple Docker ci-dessus, si un développeur souhaite que l'exportateur MySQL de Prometheus puisse interroger une base de données, il peut le faire de manière plus sûre en définissant ce qu'il doit être autorisé à accomplir. Voici un bon exemple :

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD ;
GRANT PROCESS, REPLICATION CLIENT ON *.* TO exporter@% ;
GRANT SELECT ON performance_schema.* TO exporter@% ;

Dans ce cas, l'utilisateur MySQL configuré pour le service Prometheus MySQL Exporter ne dispose que d'autorisations restreintes sur le service MySQL. Plus précisément, seuls les privilèges PROCESS et REPLICATION CLIENT sont autorisés. Cela empêche un utilisateur malveillant de tirer parti d'un service Prometheus MySQL Exporter compromis.

La restriction des autorisations au niveau du code peut garantir que les utilisateurs et les applications ne disposent que des autorisations nécessaires à l'accomplissement de leur tâche. Cela peut contribuer grandement à la sécurisation de vos réseaux et à l'adoption du concept d'infrastructure en tant que code.

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 notre plateforme de formation Secure Code Warrior pour maintenir vos compétences en matière de cybersécurité à jour.

Si vous êtes un développeur et que vous souhaitez en savoir plus sur les étapes à suivre pour commencer à déployer une infrastructure sécurisée sous forme de code (IaC) dans votre entreprise, vous êtes au bon endroit. Il s'agit du chapitre suivant de notre série sur l'IaC, conçue pour vous faire progresser dans les meilleures pratiques de sécurité de l'IaC.

Avant de commencer, comment avez-vous relevé le défi du dernier épisode ? Si vous maîtrisez la cryptographie non sécurisée, voyons comment vous vous en sortez avec une protection de la couche transport insuffisante avant d'entrer dans les détails :

Vous voulez en savoir plus et obtenir une note parfaite ? Lisez la suite :

Dans notre dernier article, nous avons parlé de l'importance de disposer d'une cryptographie sécurisée pour protéger toutes les données importantes ou personnelles stockées par des applications et des programmes. Si vous disposez d'un cryptage fort, il agit comme une dernière ligne de défense parfaite. Même si un pirate est en mesure de voler ces données, si elles sont fortement cryptées, les informations enfermées dans ces fichiers sont toujours protégées.

La protection des données au repos n'est toutefois qu'une partie d'une défense complète des données. Lorsque des utilisateurs valides ont besoin d'accéder à des données protégées, celles-ci doivent leur être envoyées. Parfois, les applications partagent également des données avec d'autres programmes dans le cadre d'une charge de travail globale. Si la couche transport n'est pas protégée, elle est vulnérable à la fois à l'espionnage extérieur et à la visualisation interne non autorisée. Ainsi, une protection insuffisante de la couche transport peut entraîner de graves problèmes.

Il s'agit d'un problème courant. L'organisation de sécurité OWASP consacre même une page entière à la protection insuffisante de la couche de transport.

Pourquoi une protection insuffisante de la couche de transport est-elle dangereuse ?

Si vous ne protégez pas suffisamment vos couches de transport, il est relativement facile pour des pirates compétents d'intercepter les informations circulant entre vos utilisateurs et vos applications à l'aide de techniques telles que les attaques de type "man-in-the-middle". L'aspect le plus dangereux de ce type d'espionnage est qu'il est presque totalement invisible pour les plateformes ou les analyses de cybersécurité internes, car il se produit en dehors de votre réseau et de votre contrôle.

Par exemple, dans un environnement Docker qui déploie un service Nginx, les pirates peuvent intercepter les informations qui circulent entre vos utilisateurs et vos applications :

services :
nginx :
image : localhost:5000/scw_nginx
build : ./nginx
secrets :
- nginx_cert
- nginx_key
volumes :
- type : bind
source : ./nginx/nginx.conf
target : /etc/nginx/nginx.conf
read_only : yes
ports :
- 80:8443
networks :
- frontend
deploy :
restart_policy : *default-restart_policy
resources : *politique_default-resources

La configuration du service Nginx ne crypte ni ne protège la connexion, ce qui rend toutes les informations échangées par le biais de la liaison vulnérables à diverses attaques ou à l'espionnage.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Souvent, le premier signe que quelqu'un est en train d'espionner vos couches de transport est l'utilisation d'un grand nombre de mots de passe d'utilisateurs volés lors d'attaques ultérieures. Si d'autres données, telles que des informations sur les clients, des dossiers financiers ou des secrets d'entreprise importants, sont volées via une couche de transport non sécurisée, il se peut que vous ne vous rendiez même pas compte que vous avez été compromis.

Et ce n'est pas seulement la couche de transport entre les utilisateurs et les applications qui doit être protégée. En arrière-plan, de nombreuses applications communiquent entre elles et avec des serveurs situés plus loin dans la chaîne de travail. Bien que ces communications internes ne soient généralement pas vulnérables à l'espionnage extérieur, elles peuvent exposer des données à des utilisateurs qui peuvent être autorisés à accéder au réseau mais qui ne sont pas autorisés à voir certaines informations hautement protégées ou sensibles.

Sécuriser correctement les couches de transport pour une protection totale des données

La meilleure façon de protéger les couches de transport est de le faire pendant la création des applications. Ce processus commence par la mise en place d'une infrastructure dorsale sécurisée. Pour les sites web, tout doit être fait en HTTPS. Ne mélangez jamais les infrastructures HTTP et HTTPS. Vous devriez même configurer vos sites de manière à ce que les requêtes HTTP non sécurisées soient automatiquement acheminées vers l'infrastructure HTTPS.

Dans l'exemple ci-dessus, une méthode appropriée de protection de la couche transport serait la suivante :

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Dans cet exemple, toutes les connexions avec le service Nginx sont fortement cryptées. La section serveur de la configuration de Nginx n'inclut que listen 8443 ssl afin de forcer SSL à protéger les connexions.

Pour protéger vos données contre les menaces internes, les développeurs doivent utiliser un protocole de cryptage de la couche de transport solide comme TLS 1.2. Une fois que vous avez mis en place TLS 1.2 ou son équivalent, les protocoles plus faibles comme SSL v2 doivent être complètement supprimés de votre infrastructure et automatiquement interdits d'utilisation.

N'oubliez jamais que la sécurisation d'une application n'est pas complète tant que les données au repos et les couches de transport ne sont pas suffisamment protégées. De cette façon, vous pouvez garantir une protection complète de bout en bout des données, tant en interne que lorsqu'elles sont transmises à des utilisateurs externes autorisés.
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.