Les organisations avisées adoptent le concept d'infrastructure en tant que code, et ce sont des développeurs comme vous qui peuvent contribuer de manière significative à l'élaboration d'un code sécurisé, même en dehors de la construction d'une application. Le chemin à parcourir peut sembler long au début, mais il en vaut la peine si vous voulez vous démarquer de vos pairs.

Avant de commencer ce nouveau chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à jouer à un défi gamifié de la vulnérabilité du stockage des données sensibles ; jouez maintenant et choisissez entre Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment cela s'est-il passé ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, la protection des données critiques telles que les mots de passe, les informations personnelles et les dossiers financiers est la pierre angulaire de toute défense en matière de cybersécurité. À bien des égards, il s'agit à la fois d'une dernière ligne de défense et de l'un des meilleurs types de protection. En effet, même si un attaquant parvient à franchir d'autres défenses et à obtenir des fichiers critiques, cela ne lui servira pas à grand-chose tant qu'ils sont correctement hachés et stockés.

Il s'agit également d'une solide protection secondaire contre les initiés malveillants, car les fichiers cryptés peuvent avoir des clés ou des mots de passe distincts de ceux du reste du réseau. Dans ce cas, un administrateur système ou un pirate informatique ayant compromis les informations d'identification d'un administrateur peut être en mesure de naviguer dans un répertoire protégé, mais pas de déverrouiller les fichiers cryptés qu'il y trouve si la clé de cryptage est détenue ailleurs.

Bien entendu, toutes les méthodes de protection par cryptage reposent sur des normes de cryptage solides qui ne peuvent pas être transgressées par les ordinateurs les plus puissants.

Pourquoi la cryptographie non sécurisée est-elle dangereuse ?

En matière de technologie informatique, la capacité à créer des algorithmes de cryptage puissants et la capacité à les casser sont en concurrence depuis longtemps. En 1977, le gouvernement fédéral des États-Unis a mis au point la norme de cryptage des données (DES), un algorithme de 56 bits qui était considéré comme sûr à l'époque compte tenu de la puissance relative des ordinateurs.

Mais les ordinateurs ont évolué et les gens ont trouvé des moyens de les mettre en réseau de manière collaborative afin d'accroître encore leur puissance. En 1999, l'Electronic Frontier Foundation et Distributed.net ont collaboré pour casser publiquement le cryptage d'un document protégé par DES en seulement 22 heures. Soudain, tout document protégé par le cryptage DES n'était plus sûr.

Croyez-le ou non, certaines organisations protègent encore leurs fichiers critiques à l'aide de l'algorithme DES ou d'une protection de chiffrement aussi faible. Et alors qu'il fallait un réseau distribué pour casser le cryptage 56 bits en 1999, aujourd'hui, presque n'importe quel ordinateur autonome suffisamment puissant peut le faire avec un peu de temps. Les pirates ont également créé des machines dédiées au craquage, construites à partir de banques de processeurs graphiques (GPU). Ces GPU sont exceptionnellement performants pour cette tâche, sont relativement peu coûteux à obtenir et à mettre en réseau localement.

Si vous choisissez aujourd'hui de protéger vos fichiers critiques à l'aide d'un algorithme cryptographique peu sûr ou faible, il ne faudra pas longtemps pour que la plupart des pirates informatiques puissent décrypter ces fichiers et les rendre lisibles. Si vous êtes victime d'une violation de données, vous devez partir du principe que les fichiers seront finalement compromis s'ils n'ont pas été suffisamment protégés.

Par exemple, l'extrait de code Kubernetes suivant utilise un algorithme de chiffrement faible pour protéger les informations au niveau du contrôleur d'entrée NGINX :

apiVersion : v1
kind : ConfigMap
metadata :
name : nginx-load-balancer-conf
namespace : kube-system
data :
ssl-ciphers : DES-CBC3-SHA
ssl-protocols : "TLSv1.2"

Dans cet exemple, la suite de chiffrement DES a été utilisée pour protéger les informations. Toutefois, un pirate pourrait facilement la déchiffrer et accéder à des informations sensibles.

Il est recommandé d'utiliser des algorithmes de chiffrement puissants. Dans l'exemple Kubernetes suivant, des suites de chiffrement fortes ont été utilisées pour protéger les informations au niveau du contrôleur d'entrée NGINX :

apiVersion : v1
kind : ConfigMap
metadata :
name : nginx-load-balancer-conf
namespace : kube-system
data :
ssl-ciphers : |
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 :
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 :
ECDHE-ECDSA-AES128-GCM-SHA256 :ECDHE-RSA-AES128-GCM-SHA256 :
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 :
ECDHE-RSA-AES128-SHA256
ssl-protocols : "TLSv1.2"

Dans cet exemple, une série de chiffrements puissants a été utilisée afin d'éviter que des attaquants n'aient un accès potentiel à des informations sensibles.

Protéger les informations critiques grâce à un cryptage fort

Il existe aujourd'hui un système de cryptage fort qui est pratiquement inviolable. En 2001, le National Institute of Standards and Technology (NIST) a créé une nouvelle technologie de cryptage pour remplacer le DES. Appelée Advanced Encryption Standard (AES), elle utilise trois longueurs de clé différentes, soit 128, 192 ou 256 bits. Le cryptage AES 256 bits est le plus sûr, bien que les trois soient considérés comme presque totalement incassables compte tenu de la technologie actuelle. Des tests effectués avec des superordinateurs ont montré qu'il faudrait des milliers d'années de travail constant pour déchiffrer la plupart des documents protégés par AES.

Pour protéger correctement les fichiers critiques, les développeurs doivent d'abord les identifier. Il n'est pas nécessaire de tout crypter sur un réseau, car cela pourrait ralentir les opérations en raison du processus constant de cryptage et de décryptage. En revanche, les fichiers critiques tels que les dossiers du personnel, les données des clients et les informations financières doivent être protégés de manière adéquate. En fait, il s'agit de trouver un équilibre entre la sécurité et l'efficacité du système.

Ces données doivent être cryptées selon l'une des normes AES, voire 256 bits pour les informations réellement critiques qui ne doivent jamais tomber entre de mauvaises mains.

Un autre élément à prendre en compte est le fait que l'ajout du cryptage revient à ajouter des mots de passe à un site. Cela signifie que les utilisateurs autorisés devront assurer le suivi des clés de chiffrement. Pour éviter que cela ne devienne un goulot d'étranglement dans le flux de travail, envisagez de mettre en œuvre une plateforme de gestion des clés pour assurer le suivi de ces clés et les garder en sécurité. Et même si vous n'utilisez pas la gestion centralisée des clés, veillez à ce que toutes les clés et tous les mots de passe soient protégés afin que les utilisateurs non autorisés ne puissent pas accéder à vos coffres-forts les plus sécurisé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 d'un défi IaC sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Lorsqu'il s'agit de déployer une infrastructure sécurisée sous forme de code dans votre propre organisation, où en êtes-vous ? Il peut s'agir d'une courbe d'apprentissage, mais le fait d'apprendre les ficelles du métier vous permettra d'améliorer vos compétences, de vous démarquer de vos pairs et d' assurer la sécurité des données des utilisateurs finaux.

Avant de commencer ce nouveau chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à jouer à un défi gamifié de la vulnérabilité du stockage des données sensibles ; jouez maintenant et choisissez entre Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment cela s'est-il passé ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe sont la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, comme l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité basée sur les mots de passe comme un élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement les mots de passe que nous avons même des règles sur la manière de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes continuent d'utiliser des mots de passe faibles, comme le montre un rapport récent de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi qu'un tas d'autres mots devinables comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours des personnes qui ne se soucient pas d'utiliser des mots de passe forts, mais la plupart des organisations professionnelles obligent les utilisateurs à rédiger leurs mots ou phrases d'accès d'une certaine manière. Nous connaissons tous les règles : les mots de passe doivent comporter au moins huit caractères et être composés de lettres majuscules et minuscules, avec au moins un chiffre et un caractère spécial.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des mots de passe les plus forts, cela ne sert à rien si tous les mots de passe sont stockés en clair. Le mot de passe 12345 est tout aussi mauvais que Nuts53!SpiKe&Dog12 si un pirate informatique est en mesure de lire l'intégralité du fichier de mots de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en clair est une mauvaise chose car il met en danger à la fois le système et les utilisateurs. Il est évident qu'un pirate informatique capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait un désastre. Il lui suffirait de trouver un utilisateur disposant d'identifiants d'administrateur pour compromettre l'ensemble du système ou du site. Et comme il utiliserait des noms d'utilisateur et des mots de passe appropriés, la sécurité interne pourrait ne pas détecter l'intrusion ou la détecter longtemps après que les dégâts ont été causés.

Faciliter le vol des mots de passe stockés en clair par les attaquants nuit également aux utilisateurs, car de nombreuses personnes réutilisent leurs mots de passe. Parce que nous avons rendu les mots de passe si difficiles à créer, beaucoup de gens réutilisent ceux dont ils se souviennent sur plusieurs sites. Si un pirate compromet un fichier de mots de passe, il essaiera presque certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de délits secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte clair ou de ne pas se rendre compte que cela pourrait causer des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode courante utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de la base de données MySQL dans AWS est stocké en clair. Cela signifie que toute personne ayant accès au dépôt de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du cadre, mais il existe des méthodes de protection pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en clair dans les fichiers du modèle.

Protéger les mots de passe en évitant le stockage en clair

Les mots de passe sont les clés de votre royaume et ne devraient jamais être stockés en clair. Même les personnes internes à une organisation ne devraient pas avoir accès à un grand dépôt non protégé de mots de passe, et cela ne devrait pas être un protocole d'entreprise accepté (il existe de nos jours de nombreux gestionnaires de mots de passe qui permettent le partage crypté des informations d'identification - pas d'excuses !) Il y a également le risque que des personnes internes malveillantes fouillent dans les fichiers et accèdent à des endroits où elles ne le devraient pas.

Et dans le cas d'une attaque extérieure, imaginez le double effet possible si une porte dérobée vers votre base de données est trouvée grâce à quelque chose d'aussi simple qu'une vulnérabilité d'injection SQL, et qu'ils accèdent également au répertoire où les mots de passe sont stockés. Vous pensez qu'il s'agit là d'un trop grand nombre d'étapes truffées d'erreurs pour que cela porte ses fruits ? Malheureusement, c'est exactement ce scénario qui s'est produit lors de la faille de Sony en 2011. Plus d'un million de mots de passe de clients étaient stockés en clair, et le groupe de pirates Lulzsec a accédé à ces mots de passe et à bien d'autres encore par le biais d'une banale attaque par injection SQL.

Tous les mots de passe doivent être protégés par les défenses disponibles dans le cadre d'appui. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, en fonction du fournisseur d'infrastructure.

Obliger les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part du travail en arrière-plan. Le fait de ne pas stocker les mots de passe en clair contribuera grandement à la protection de vos utilisateurs et de vos systèmes. Le principal danger du stockage des mots de passe en clair est la faiblesse du contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement, davantage de personnes ont accès à des informations sensibles) que les mots de passe soient hachés de manière adéquate et que seules les personnes qui ont absolument besoin d'y accéder puissent le faire.

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 contre les ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayer un défi IaC de démonstration sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en matière de cybersécurité à jour.

Toute personne ayant travaillé dans la production de logiciels est probablement consciente des tensions qui peuvent survenir lorsqu'il s'agit de prendre en compte la sécurité, principalement entre les développeurs et les spécialistes de la sécurité qui examinent leur code.

Autrefois, il n'était pas rare que l'équipe de développement livre le code le plus tard possible, en réduisant délibérément la fenêtre pendant laquelle les gourous de la sécurité pouvaient vérifier les vulnérabilités - après tout, cela retardait la publication si quelque chose ne fonctionnait pas, et il y avait déjà le désir d'aller de l'avant et de commencer à construire la prochaine fonctionnalité géniale. Toutefois, cela a fini par avoir un impact négatif, car lorsque le code était finalement vérifié - parfois après qu'une brèche externe se soit déjà produite - le code revenait toujours aux développeurs, leurs bébés logiciels étaient toujours traités de laids par l'équipe de sécurité, et ils devaient tout laisser tomber pour corriger le code qu'ils avaient touché pour la dernière fois il y a des mois.

Ce dysfonctionnement se poursuit aujourd'hui, mais il y a un énorme problème : il y a beaucoup plus de code qui est développé, et la société est exposée à un risque beaucoup plus grand en cas de violation de données. Nous n'avons plus le temps de mener cette vieille bataille, et en 2020, il est temps que nous soyons tous du même côté contre les méchants.

Nous devons arriver à un stade où la sécurité est considérée comme une responsabilité partagée par l'ensemble de l'organisation et tout au long du cycle de développement durable. Cela est certainement possible lorsque vous vous engagez dans un environnement DevSecOps à part entière et très favorable. De plus, lorsque vous allumez le feu de la sécurité dans votre équipe de développement avec la bonne formation et les bons outils, ils sont une force puissante non seulement pour écraser les bogues, mais aussi pour soulager les spécialistes de la sécurité qui ont été trop dispersés, pendant trop longtemps.

J'aimerais que vous assistiez à l'un de mes derniers webinaires, Comment mettre le "Sec" dans DevOps:

Cet article, qui s'inscrit dans le cadre du sommet de 24 heures AllTheTalks, jette un regard approfondi sur la question :

• Pourquoi les anciennes méthodologies de développement ont-elles rendu les meilleures pratiques en matière de sécurité beaucoup plus difficiles ?
• Pourquoi DevSecOps est le dernier changement en date dans la lutte contre les failles de sécurité les plus courantes ?
• Ce à quoi ressemble la sécurité en tant que responsabilité partagée dans une organisation
• Comment vous pouvez permettre aux développeurs de produire du code sécurisé en toute confiance, sans sacrifier ce qu'ils aiment (indice : il s'agit de créer des fonctionnalités géniales).

Au plaisir de vous y voir !

De nos jours, les menaces qui pèsent sur la cybersécurité sont omniprésentes et incessantes. Plus les facettes de notre vie sont numérisées, plus les enjeux pour les cybercriminels sont élevés - il y a trop de code à sécuriser, et les données privées sont trop précieuses. En outre, il est devenu pratiquement impossible de suivre et de défendre chaque aspect de la surface d'attaque après le déploiement des programmes.

Il existe des approches qui peuvent atténuer certains de ces symptômes, et l'une d'entre elles est apparente lorsque des organisations astucieuses adoptent le concept d'infrastructure en tant que code (IaC). Bien sûr, comme pour tout développement, il y a des pièges à éviter en matière de sécurité. Et comme les développeurs travaillent sur le code qui génère l'infrastructure vitale pour héberger les applications, la sensibilisation à la sécurité est essentielle à chaque étape du processus.

Alors, comment un développeur débutant dans un environnement de serveurs en nuage peut-il se perfectionner, apprendre les ficelles du métier et aborder la construction avec une conscience accrue de la sécurité ? Nous avons créé la prochaine série Coders Conquer Security pour aborder les vulnérabilités IaC courantes, et ces prochains blogs se concentreront sur les étapes que vous, en tant que développeur, pouvez suivre pour commencer à déployer une infrastructure sécurisée en tant que code dans votre propre organisation.

Commençons.

Une fable de l'Ouest américain raconte l'histoire d'un homme paranoïaque qui craignait que des bandits n'attaquent et ne dévalisent sa propriété. Pour compenser, il a investi dans toutes sortes de mesures de sécurité, comme l'installation d'une porte d'entrée très solide, la pose de planches sur toutes les fenêtres et la conservation d'un grand nombre d'armes à portée de main. Il a tout de même été cambriolé une nuit pendant son sommeil parce qu'il avait oublié de verrouiller la porte latérale. Les bandits ont simplement constaté que la sécurité était défaillante et ont rapidement exploité la situation.

Le fait de désactiver des fonctions de sécurité dans votre infrastructure s'apparente à cela. Même si votre réseau dispose d'une infrastructure de sécurité solide, elle ne sert pas à grand-chose si des éléments ont été désactivés.

Permettez-moi de vous lancer un défi avant d'entrer dans le vif du sujet :

Cliquez sur le lien ci-dessus et vous serez transporté vers notre plateforme de formation ludique, où vous pourrez tenter d'éliminer dès maintenant une vulnérabilité de la fonction de sécurité désactivée. (Attention : Il s'ouvrira dans Kubernetes, mais utilisez le menu déroulant et vous pourrez choisir entre Docker, CloudFormation, Terraform et Ansible).

Quels sont vos résultats ? Si vous avez encore du travail à faire, lisez la suite :

Les fonctions de sécurité peuvent être désactivées pour diverses raisons. Avec certaines applications et certains frameworks, elles peuvent être désactivées par défaut et doivent d'abord être activées pour commencer à fonctionner. Il est également possible que les administrateurs aient désactivé des fonctions de sécurité spécifiques afin de pouvoir effectuer plus facilement certaines tâches sans être constamment contestés ou bloqués (par exemple, rendre public un seau AWS S3). Une fois leur travail terminé, ils peuvent oublier de réactiver ces fonctions désactivées. Ils peuvent également préférer les laisser désactivées pour se faciliter la tâche à l'avenir.

Pourquoi les dispositifs de sécurité désactivés sont-ils si dangereux ?

Le fait d'avoir une ou plusieurs fonctions de sécurité désactivées est néfaste pour plusieurs raisons. Tout d'abord, la fonction de sécurité a été intégrée aux ressources de l'infrastructure pour les protéger contre un exploit, une menace ou une vulnérabilité connus. S'il est désactivé, il ne pourra pas protéger vos ressources.

Les attaquants essaieront toujours de trouver en premier les failles facilement exploitables et peuvent même utiliser un script pour passer en revue les faiblesses les plus courantes. C'est un peu comme si un voleur vérifiait toutes les voitures d'une rue pour voir si une porte est déverrouillée, ce qui est beaucoup plus facile que de briser une fenêtre. Les pirates peuvent être surpris de constater qu'un dispositif de sécurité courant est inactif. Mais lorsque cela se produit, il ne leur faut pas longtemps pour l'exploiter.

Deuxièmement, le fait de mettre en place une bonne sécurité puis de la désactiver crée un faux sentiment de sécurité. Les administrateurs peuvent penser qu'ils sont protégés contre les menaces courantes s'ils ne savent pas que quelqu'un a désactivé ces défenses.

Pour illustrer la manière dont un pirate peut tirer parti d'une fonction de sécurité désactivée, prenons l'exemple de la fonction de sécurité AWS S3 qui consiste à bloquer l'accès public. Avec le blocage de l'accès public à Amazon S3, les administrateurs de comptes et les propriétaires de seaux peuvent facilement mettre en place des contrôles centralisés pour limiter l'accès public à leurs ressources Amazon S3. Cependant, certains administrateurs rencontrant des problèmes lors de l'accès à un bac S3 décident de le rendre public afin d'effectuer la tâche le plus rapidement possible. S'ils oublient d'activer cette fonction de sécurité, un pirate aura un accès complet aux informations stockées dans ce seau S3, ce qui entraînera non seulement la divulgation d'informations, mais aussi des coûts supplémentaires dus aux frais de transfert de données.

Comparons un peu de code réel ; regardez ces extraits de CloudFormation :

Vulnérable :

CorporateBucket :
Type : AWS::S3::Bucket
Propriétés :
PublicAccessBlockConfiguration :
BlockPublicAcls : false
BlockPublicPolicy : false
IgnorePublicAcls : false
RestrictPublicBuckets : false
VersioningConfiguration :
Status : Enabled
BucketEncryption :
ServerSideEncryptionConfiguration :
- ServerSideEncryptionByDefault :
SSEAlgorithm : "AES256"

Sécurisé :

CorporateBucket :
Type : AWS::S3::Bucket
Propriétés :
PublicAccessBlockConfiguration :
BlockPublicAcls : true
BlockPublicPolicy : true
IgnorePublicAcls : true
RestrictPublicBuckets : true
VersioningConfiguration :
Status : Enabled
BucketEncryption :
ServerSideEncryptionConfiguration :
- ServerSideEncryptionByDefault :
SSEAlgorithm : "AES256"

Empêcher la désactivation des dispositifs de sécurité

Empêcher les fonctions de sécurité désactivées de nuire à votre organisation est autant une question de politique que de pratique. Il convient de mettre en place une politique ferme stipulant que les fonctions de sécurité ne doivent être désactivées que dans des circonstances très spécifiques. Les incidents au cours desquels des fonctions doivent être temporairement désactivées pour résoudre un problème ou mettre à jour des applications doivent être consignés. Une fois les travaux terminés, il convient de vérifier que les dispositifs ont été pleinement réactivés.

Si une fonction de sécurité doit être désactivée de manière permanente afin de rationaliser les opérations, d'autres protections doivent être fournies aux données concernées afin de garantir que les pirates ne pourront pas y accéder en l'absence de la protection par défaut. Si une fonction de protection nécessaire a été désactivée, ce n'est qu'une question de temps avant qu'un pirate ne trouve cette porte déverrouillée et n'exploite la situation.

Apprenez-en plus, lancez-vous des défis :

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 contre les ravages causés par d'autres failles de sécurité et vulnérabilités.

Prêt à trouver et à corriger cette vulnérabilité maintenant que vous avez lu l'article ? Il est temps d'essayer un défi de sécurité gamifié de l'IaC sur la plateforme Secure Code Warrior pour garder toutes vos compétences en cybersécurité aiguisées et à jour.

Il s'agit d'une série hebdomadaire couvrant les huit principales vulnérabilités de l'infrastructure en tant que code ; revenez la semaine prochaine pour en savoir plus !

Il est temps de lire le prochain épisode de notre série Infrastructure as Code, les blogs qui amèneront les développeurs comme vous à un tout nouveau niveau de sensibilisation à la sécurité lors du déploiement d'une infrastructure sécurisée au sein de votre propre organisation.

Au fait, comment avez-vous relevé le défi de la mauvaise configuration de la sécurité dans le blog précédent ? Si vous souhaitez vous attaquer dès maintenant à une vulnérabilité de contrôle d'accès fonctionnel manquante, rendez-vous sur la plateforme :

(Le lien ci-dessus vous mènera au défi Kubernetes, mais une fois sur la plateforme, utilisez le menu déroulant pour choisir entre Ansible, CloudFormation, Terraform ou Docker. À vous de choisir).

Presque toutes les applications déployées aujourd'hui disposent d'un mécanisme de contrôle d'accès qui vérifie si l'utilisateur a le droit d'exécuter les fonctions demandées. C'est la pierre angulaire d'une bonne sécurité et d'une bonne fonctionnalité lors de la création d'une application. En fait, toutes les applications web ont besoin de contrôles d'accès afin de permettre à des utilisateurs ayant des privilèges différents d'utiliser le programme.

Des problèmes peuvent toutefois survenir lorsque ces mêmes fonctions de vérification du contrôle d'accès ne sont pas exécutées au niveau de l'infrastructure ou sont mal configurées. Si le contrôle d'accès au niveau de l'infrastructure n'est pas parfaitement en ordre, toute l'entreprise est ouverte aux pirates informatiques, qui peuvent utiliser cette vulnérabilité comme porte d'entrée pour un espionnage non autorisé ou une attaque complète.

En fait, il est extrêmement facile d'exploiter les vulnérabilités du contrôle d'accès aux fonctions manquantes ou mal configurées. Les attaquants n'ont même pas besoin d'être très habiles. Il leur suffit de savoir quelles commandes exécutent les fonctions dans le cadre de l'application, quel qu'il soit. S'ils le font, c'est juste une question d'essais et d'erreurs. Ils peuvent continuellement soumettre des requêtes qui ne devraient pas être autorisées, et dès que l'une d'entre elles réussit, le site web, l'application, le serveur ou même l'ensemble du réseau ciblé peut être exposé.

Comment fonctionnent les exploits de contrôle d'accès aux fonctions manquantes ?

Les contrôles d'accès au niveau des fonctions peuvent s'infiltrer dans une organisation de plusieurs manières. Par exemple, l'accès au niveau de la fonction peut être laissé à une application et ne pas être vérifié par l'infrastructure sous-jacente. Le contrôle d'accès au niveau de l'infrastructure peut également être mal configuré. Dans certains cas, les administrateurs supposent que les utilisateurs non autorisés ne sauront pas comment accéder aux ressources de l'infrastructure que seuls les utilisateurs de niveau supérieur devraient pouvoir voir et utilisent un modèle de "sécurité par l'obscurité" qui fonctionne rarement.

Pour un exemple de sécurité par l'obscurité, l'URL suivante est probablement vulnérable à une attaque :

http://companywebsite.com/app/NormalUserHomepage

Si un utilisateur authentifié utilise une technique appelée "Forced URL Browsing", il peut essayer d'atteindre une page qui n'est affichée qu'aux administrateurs. Voici un exemple :

http://companywebsite.com/app/AdminPages

S'il n'existe pas de vérification côté serveur, l'attaquant se verra simplement présenter la page d'administration (si son nom correspond à la demande) et aura alors accès à toutes les fonctions supplémentaires que les administrateurs exécutent à partir de la nouvelle page. Si le serveur renvoie une erreur "page non trouvée" à l'attaquant, celui-ci peut simplement continuer à essayer jusqu'à ce qu'il trouve le nom de la page d'administration.

Pour les attaquants, l'exploitation des contrôles d'accès manquants au niveau des fonctions est un processus similaire. Au lieu d'essayer de parcourir des pages non autorisées, ils envoient des demandes de fonctions. Par exemple, ils peuvent essayer de créer un nouvel utilisateur avec des droits d'administrateur. Leur demande ressemblerait donc à quelque chose comme ceci, selon le cadre de travail :

POST/action/createuser name=hacker&pw=password&role=admin

S'il n'existe pas de contrôle d'accès au niveau de la fonction, l'exemple ci-dessus aboutirait et un nouveau compte d'administrateur serait créé. Une fois que l'attaquant s'est reconnecté en tant que nouvel administrateur, il dispose des mêmes accès et autorisations que n'importe quel autre administrateur sur ce réseau ou ce serveur.

La solution aux contrôles d'accès manquants au niveau des fonctions

Parce qu'il est si facile pour les attaquants d'exploiter les vulnérabilités du contrôle d'accès au niveau des fonctions manquantes, il est essentiel qu'elles soient trouvées, corrigées et évitées. Heureusement, cela n'est pas trop difficile avec un peu de savoir-faire et une formation de base à la sécurité de l'Infrastructure as Code.

La principale protection viendra de la mise en œuvre d'une autorisation basée sur les rôles au niveau de l'infrastructure. Ne confiez jamais cette fonction aux applications. Même si elles le font, une autorisation au niveau de l'infrastructure permettra de s'assurer que rien n'a été oublié. Idéalement, l'autorisation devrait provenir d'un emplacement centralisé (par exemple, AWS IAM, Azure IAM, etc.) qui est intégré dans la routine de votre organisation et appliqué à chaque nouvelle application. Ces processus d'autorisation peuvent provenir du framework lui-même ou d'un certain nombre de modules externes faciles à utiliser.

Enfin, votre organisation devrait adopter le concept du moindre privilège. Toutes les actions et fonctions doivent être refusées par défaut, le processus d'autorisation étant utilisé pour donner aux utilisateurs valides la permission de faire ce dont ils ont besoin. Ils ne doivent recevoir que les autorisations nécessaires à l'exécution de la fonction requise, et uniquement pour la durée nécessaire.

L'absence de contrôles d'accès au niveau de la fonction peut être dévastatrice. Heureusement, en intégrant de bonnes pratiques d'autorisation au niveau de l'infrastructure dans votre organisation, vous pouvez facilement empêcher ce problème de se produire.

Vous pensez être prêt à repérer un bogue de contrôle d'accès dans la nature ? Comparez ces extraits de code Docker, l'un vulnérable, l'autre sécurisé :

Vulnérable :

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Sécurisé :

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Apprenez-en plus, lancez-vous des défis

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 contre les ravages causés par d'autres failles de sécurité et vulnérabilités.

Et si vous l'avez manqué plus tôt, vous pouvez essayer un défi de sécurité gamifié de l'IaC sur la plateforme Secure Code Warrior pour garder toutes vos compétences en cybersécurité aiguisées et à jour.

Restez à l'écoute pour le prochain chapitre !

Voici la deuxième partie d'une mini-série sur la conformité PCI-DSS au sein d'une organisation. Dans ce dernier chapitre, nous expliquons en détail comment les directeurs techniques et les responsables de la sécurité des systèmes d'information peuvent prendre l'initiative de réduire les cyber-risques et de rendre le processus transparent, réussi... et peut-être même un peu amusant pour les développeurs. (Vous avez manqué la première partie ? Consultez-la ici et découvrez comment les spécialistes AppSec peuvent saisir cette opportunité pour obtenir de meilleurs résultats en matière de sécurité).

Les meilleures pratiques PCI-DSS sont sans aucun doute une responsabilité partagée, mais les RSSI et les directeurs techniques peuvent exploiter leur influence considérable pour créer un programme de sécurité prospère et positif depuis le sommet. Ils sont la figure de proue de la confiance en la cybersécurité et du sentiment qui en découle chez les utilisateurs finaux, et l'accent mis sur la sensibilisation dès le début a un puissant effet d'entraînement, aidant les développeurs et les professionnels de l'AppSec à obtenir les connaissances, les outils et le soutien dont ils ont besoin pour contribuer à une posture de sécurité solide au sein de l'entreprise.

Il est important de rester en conformité, mais lorsque tout le monde est d'accord avec le "pourquoi", voit des résultats et est soutenu de la bonne manière, un programme peut transcender la législation et devenir une seconde nature.

Les directeurs techniques et les RSSI ont un rôle à jouer dans l'instauration d'une confiance mutuelle

Avez-vous récemment visité un site et réfléchi à deux fois avant de donner les détails de votre carte de crédit ? À moins qu'il ne s'agisse de l'application web à l'aspect douteux qui gère la commande en ligne de votre pizzeria locale, ce n'est probablement pas quelque chose que vous rencontrez très souvent, en particulier avec les grandes entreprises et les grands noms de la vente en ligne.

À moins qu'ils ne divulguent une violation de données, bien sûr.

Le géant mondial de l'hébergement, Marriott, vient de révéler sa deuxième faille en l'espace de trois ans, celle-ci ayant entraîné le vol de 5,2 millions d'enregistrements de clients. Cette fois-ci, il ne semble pas que les informations de paiement aient fait partie du vol, bien que la faille catastrophique de 2018 s'en soit chargée ; 383 millions de clients ont été compromis, 5 millions de numéros de passeport non cryptés ont été volés, ainsi que 8 millions de numéros de cartes de crédit.

Si la confiance des clients dans la marque Marriott n'était pas déjà au plus bas, je dirais qu'elle va bientôt toucher le fond. C'est le genre de choses qui empêchent les RSSI de dormir, car ils ont l'impression d'être des cibles faciles dans la guerre contre les cybermenaces. Il suffit de penser à Equifax, Yahoo, Sony, Target - ce ne sont là que quelques grands noms qui ont subi des violations à grande échelle, représentant des milliards d'enregistrements de données volées, des centaines de milliards de dollars de dommages, et des trous en forme de clients percés en plein cœur de leur économie. C'est un désastre pour l'entreprise (Target a enregistré une chute de 440 millions de dollars de ses bénéfices au cours du trimestre qui a suivi la violation de 2014), et bien que les individus ne soient généralement pas tenus pour responsables - après tout, la sécurité des logiciels devrait être une responsabilité partagée - c'est quelque chose que vous ne voulez pas voir figurer sur un CV par ailleurs élogieux si vous avez travaillé pour ces organisations à l'époque.

Renoncer à un programme de sécurité solide pour assurer la conformité d'une organisation qui traite des paiements, des données sensibles et de l'or intangible que représente le sentiment positif des clients, est un indicateur d'une entreprise qui n'est pas seulement à risque, mais qui est sérieusement à la traîne en matière d'innovation.

Tout le monde devrait se préoccuper des questions de confiance dans la relation client/organisation.

Outre le stress et les désastres auxquels sont confrontés les services informatiques, de développement et de sécurité après une violation, le facteur de confiance est un élément majeur du succès à long terme d'une nouvelle entreprise ou de la croissance continue d'une entreprise bien établie. La chose évidente que vous risquez de perdre est votre emploi, si l'entreprise est confrontée à une récession économique à la suite d'une perte de confiance.

Les réglementations PCI-DSS responsabilisent les entreprises - et comme nous l'avons vu plus haut, ignorer ces plans bien conçus a d'énormes conséquences - mais elles ne valent que ce que valent le programme de sécurité mis en place et les personnes qui y travaillent. Si vous les prenez au sérieux, si vous restez informé et si vous montrez l'exemple aux autres, vous vous distinguerez de manière très positive.

La prise de conscience est essentielle.

Un programme de sensibilisation à la sécurité défaillant rendra la plupart des tentatives de mise en conformité avec la norme PCI presque inutiles. La sensibilisation à la sécurité à l'échelle de l'organisation constitue la partie la plus critique des lignes directrices sur les meilleures pratiques ; elles proposent même leurs propres modules de formation sur la manière dont cette sensibilisation peut être mise en œuvre dans les rôles interfonctionnels, et sur ce à quoi cela ressemble dans les entreprises qui le font correctement.

Alors que nous nous dirigeons vers DevSecOps en tant qu'étalon-or actuel du développement de logiciels sécurisés - dans lequel la sécurité en tant que responsabilité partagée est fondamentale - les entreprises doivent consacrer du temps, de l'argent et des efforts pour s'assurer que tout le monde, y compris les fournisseurs et les sous-traitants, est sensibilisé à la sécurité et suit les meilleures pratiques.

Un développeur sensibilisé à la sécurité est un développeur respectueux des règles (et il n'est pas nécessaire de s'ennuyer pour y parvenir).

Lorsqu'il s'agit de devenir un développeur "certifié" conforme à la norme PCI-DSS, il n'y a pas beaucoup d'options évidentes. Pourquoi ? Probablement parce qu'il ne s'agit pas d'un exercice "one and done".

L'organisation OWASP est l'une des meilleures de la planète lorsqu'il s'agit d'apprendre à déjouer les vulnérabilités courantes, et son Top 10 figure officiellement dans les lignes directrices PCI-DSS pour les développeurs. Cependant, garder la sécurité à l'esprit et perfectionner ses compétences demande du temps et des efforts continus. Et personne ne souhaite que ces efforts ne soient pas inspirants et qu'ils soient gaspillés.

Une culture positive de la sécurité n'est pas une "bonne chose" dans une organisation ; si elle prend la sécurité au sérieux, elle doit faire partie du fonctionnement quotidien de l'entreprise.

Les développeurs sont en première ligne lorsqu'il s'agit d'éliminer les vulnérabilités. Bénéficient-ils du soutien, des outils et de la formation nécessaires pour remplir leur part du contrat de sécurité dans le cadre de la conformité à la norme PCI-DSS ?

En réalité, la bonne formation est plus transparente ; elle ne doit pas ressembler à un cours magistral et doit être très pertinente par rapport au travail effectué chaque jour. Ce type de formation pratique est une opportunité de perfectionnement - une évolution de carrière qui n'a que des avantages pour les développeurs qui veulent vraiment éliminer les vulnérabilités et travailler avec le reste de l'équipe pour produire un code de meilleure qualité.

Vous voulez tester vos compétences en matière de codage sécurisé dès maintenant ? Choisissez votre mission.

Voici la première partie d'une série de deux articles sur la conformité PCI-DSS au sein d'une organisation. Dans ce chapitre, nous détaillons comment les spécialistes AppSec peuvent travailler en étroite collaboration avec les responsables du développement pour responsabiliser les développeurs, renforcer le SSDLC et obtenir des résultats spécifiques à partir de la législation générale.

Le mot "conformité" n'est pas très excitant. Il est formel, sec, directif... et même un peu restrictif dans son ton. S'il avait une couleur, ce serait le beige. Enfin, il semble en contradiction avec toute forme d'environnement créatif ou d'innovation.

En tant que développeur, mon expérience de la "conformité" consistait généralement à lire (verticalement) quelques lignes directrices ou à regarder une présentation, avant de retourner au codage des fonctionnalités et de me concentrer sur la création d'un logiciel que les clients utiliseront et aimeront. Chacun retient ce qu'il peut dans l'instant (et essaie de faire ce qu'il faut à tout moment), mais les directives de conformité - en particulier celles qui concernent les meilleures pratiques en matière de sécurité - ne sont généralement pas rédigées à l'intention des développeurs, et les actions requises peuvent manquer de clarté. Dans ce scénario, il est trop facile de se contenter de poursuivre les objectifs en cours.

Le fait est que le développement de logiciels sécurisés n'est plus un "avantage" pour une entreprise ; il est (ou devrait être) au centre des préoccupations de chaque organisation... et si elle détient de grandes quantités d'informations sensibles sur ses clients, elle est mûre pour les cyber-attaques. Les développeurs sont les premiers à manipuler le code et, à ce titre, ils devraient être tout aussi impliqués que le reste de l'équipe dans les mesures de conformité en matière de sécurité.

Mais, attendez... écoutez-moi. Cela ne signifie pas que tout le monde doit devenir l'esclave d'un développement et de résultats logiciels rigides et dépourvus de créativité. Cela signifie que l'entreprise a la possibilité et le pouvoir de créer ensemble une norme de code plus élevée. Lentement, le monde se rend compte que, jusqu'à présent, les développeurs n'ont pas vraiment eu les bons outils à leur disposition pour faire de la sécurité une priorité (et les spécialistes de la sécurité, cloisonnés, ne peuvent pas assumer seuls cette responsabilité). Cependant, alors que l'industrie évolue vers un avenir DevSecOps où la sécurité est une responsabilité partagée, ils peuvent contribuer à endiguer le flux de vulnérabilités récurrentes lorsqu'ils sont mis en place pour réussir.

Les lignes directrices PCI-DSS couvrent la conformité de la sécurité en ligne pour les passerelles de paiement par carte - un service que la plupart d'entre nous utilisent régulièrement. Ces lignes directrices sont applicables à l'échelle mondiale et décrivent en détail ce que les développeurs doivent faire pour maintenir des normes conformes à leurs mandats, ainsi que plusieurs documents de conformité concernant des aspects de l'activité de commerce électronique.

Les violations de données sont des risques effrayants et destructeurs de réputation que les entreprises ne peuvent pas se permettre, et avec Cyber Security Ventures qui prévoit que les violations de type "zero-day" atteindront une par jour en 2021, c'est quelque chose que tout le monde dans le processus de livraison de logiciels peut aider à combattre.

Décortiquons les recommandations PCI-DSS et voyons comment elles peuvent s'appliquer à l'ensemble de l'équipe :

Hé, équipes AppSec et Compliance : Toutes les formations pour développeurs ne sont pas égales

Les développeurs des grandes (ou même des petites) entreprises ont rarement leur mot à dire sur la formation qu'ils reçoivent en cours d'emploi. Afin de conserver leurs employés vedettes, certaines entreprises proposent des programmes complets, mais ceux-ci sont encore moins répandus qu'ils ne devraient l'être. Un besoin de formation en matière de sécurité représente une excellente occasion non seulement de lancer la conformité organisationnelle sans ennuyer tout le monde, mais aussi de commencer à réchauffer les relations glaciales avec l'équipe de développement.

En ce qui concerne la conformité PCI, vous pouvez constater que les lignes directrices sont spécifiques quant aux résultats qu'elles attendent de tout logiciel exécutant des passerelles de paiement ; entre autres objectifs, elles veulent que les applications soient renforcées (ce qui est vital pour contrecarrer l'injection de code malveillant ou la falsification), qu'il y ait des contrôles du moindre privilège et une sensibilisation à grande échelle aux vulnérabilités courantes... au minimum. Tout le personnel travaillant avec des données de titulaires de cartes doit être formé de manière adéquate, et pour les développeurs, cette formation peut faire la différence entre leur succès et l'écriture d'un code sécurisé dès le début de leur processus.

Le document officiel " Best Practices for Maintaining PCI-DSS Compliance" détaille certains concepts directs concernant la sensibilisation à la sécurité, les besoins des développeurs et la formation appropriée, par exemple :

Copyright © 2006 - 2020 Conseil des normes de sécurité PCILLC. Tous droits réservés.

Cela donne une idée de la formation spécifique et approfondie requise pour doter les développeurs des compétences nécessaires, mais n'indique toujours pas de type particulier de solutions éducatives plus efficaces que d'autres. Le guide PCI-DSS pour les développeurs est un peu plus direct, identifiant le Top 10 de l'OWASP comme une référence pour apprendre à trouver et à corriger les vulnérabilités les plus courantes, ainsi que certains programmes de certification.

Mais... c'est là que le bât blesse. Comme vous l'avez sans doute constaté à l'occasion de diverses initiatives de formation et de mise en conformité sur le lieu de travail, leur qualité et leur succès futur peuvent varier considérablement. En ce qui concerne les développeurs, de nombreux programmes de formation au codage sécurisé ne semblent pas répondre à nos besoins, à nos méthodes de travail ou même à nos tâches quotidiennes de manière significative. Dans ce scénario, toutes les formations ne se valent pas, et toutes les formations ne déboucheront pas sur des logiciels plus sûrs. C'est, bien sûr, exactement le contraire de ce que vous souhaitez et cela ne réduira pas le stress de votre propre travail de manière significative. Si vous voulez réduire le fardeau et empêcher les vulnérabilités courantes de provoquer des catastrophes potentielles, vous devrez construire un pont.

Combler le fossé des compétences en matière de sécurité avec l'aide des responsables de l'ingénierie

Travailler directement avec les responsables de l'ingénierie pour trouver une solution adaptée, tout en étant adoptée par les personnes qui doivent réellement s'en charger, est un moyen rapide d'obtenir des résultats positifs en matière de sécurité. Ils auront une vision plus immédiate de leur propre équipe et pourront parler de tous les obstacles qui ont rendu la formation à la conformité difficile (à part le fait qu'elle n'est pas une bonne expérience, la plupart du temps).

Les formations en salle de classe, les vidéos à la demande et les exercices ponctuels rendent très difficile le fait de rester à jour ; il s'agit de solutions statiques qui ne peuvent pas suivre le rythme de l'évolution constante du secteur de la cybersécurité. En fin de compte, le responsable de l'ingénierie voudra voir la valeur de l'engagement en temps, et il est important de travailler avec lui et de lui fournir des options viables qui permettent d'atteindre l'objectif commun de tous : un code plus sûr et plus conforme.

À quoi ressemble donc une bonne formation ? Il ne sert pas à grand-chose d'apprendre à coder en toute sécurité par le biais de grandes quantités d'informations ponctuelles. Un processus d'apprentissage graduel et par petites bouchées facilite grandement la mémorisation et l'application en contexte, et il doit absolument se faire dans les langages et les cadres utilisés au quotidien. Personnellement, je veux être stimulé et je veux que mes efforts soient récompensés - nous sommes déjà tous assez occupés, n'est-ce pas ?

Pour se conformer aux meilleures pratiques PCI-DSS décrites ci-dessus, en fonction de la solution choisie, les responsables peuvent se retrouver à devoir assembler un patchwork de différents sites courses pour couvrir tous les langages et cadres utilisés dans l'entreprise, et c'est là que les choses deviennent très compliquées, sans parler de la difficulté pour les équipes AppSec et de conformité d'évaluer l'impact sur la sécurité et la réduction des vulnérabilités dans les logiciels. Travaillez ensemble pour trouver la bonne solution, au lieu de vous précipiter sur la mauvaise option pour obtenir un résultat rapide. Sinon, vous risquez de vous retrouver avec une solution de formation Frankenstein... et cela fait très peur.

Merci d'avoir lu la première partie de cette mini-série sur la norme PCI-DSS. Dans le dernier chapitre, nous verrons comment les RSSI et les directeurs techniques peuvent contribuer à cette transformation culturelle, habiliter les équipes et comment les premières lignes de sécurité (votre cohorte de développeurs) peuvent utiliser la sensibilisation et la conformité à la norme PCI-DSS à leur avantage.

Tout comme la technologie elle-même, les outils, les techniques et les processus optimaux de développement de code évoluent rapidement. Nous, les humains, avons un besoin insatiable de plus de logiciels, de plus de caractéristiques, de plus de fonctionnalités... et nous les voulons plus rapides que jamais, plus qualitatifs et, en plus, sécurisés. Il y a quelques années à peine, le développement agile était la grande nouveauté utilisée pour diviser de gros volumes de travail en plus petits morceaux et pour pouvoir s'adapter rapidement aux cycles de retour d'information rapides provenant du client. Auparavant, c'était la méthode Waterfall qui régnait en maître.

Alors que de nombreuses personnes et organisations passent de l'approche Waterfall à l'approche Agile - et tout le monde n'y est pas encore, soyons réalistes - elles se heurtent déjà à un nouveau problème : les équipes de développement et leurs homologues opérationnels travaillent toujours en silos. Dans cet environnement, comment de petites équipes travaillant de manière agile peuvent-elles tenir la promesse d'un déploiement et d'une livraison plus rapides ?

DevOps, un nom qui est une combinaison de développement et d'opérations, a été créé pour fusionner les fonctions des développeurs et des équipes opérationnelles lors de la création de nouveaux logiciels. Il s'agissait essentiellement d'aider les développeurs à s'approprier la mise en production, au lieu de la confier à l'équipe chargée des opérations et d'en faire sa responsabilité.

Ils peuvent certainement livrer plus rapidement - même plusieurs fois par jour - ce qui semble aller dans le sens de l'Agile. Cependant, DevOps crée toujours une grande équipe mixte d'ingénieurs et de personnel d'exploitation, qui n'est peut-être pas aussi alignée sur Agile dans la réalité. En fin de compte, il est préférable de considérer DevOps comme une évolution d'Agile, car les méthodologies sont similaires à bien des égards et complémentaires dans leurs différences. DevOps promeut un pipeline d'intégration et de déploiement automatisé et continu, ce qui est essentiel pour permettre des mises à jour fréquentes, mais pas aussi suffisant au niveau de l'équipe - et c'est là que l'Agile entre en jeu. L'Agile permet aux équipes, en particulier aux petites équipes, de suivre le rythme de ces versions rapides et de ces exigences changeantes, tout en restant concentrées sur les tâches à accomplir et en collaborant. Cela semble certainement idéal - et le processus peut maintenir les équipes sur la voie de l'objectif final - mais cela n'est pas sans poser de problèmes.

Les logiciels créés à l'aide des meilleures pratiques DevOps ont toujours le potentiel de trébucher lors du premier combat contre le patron : l'équipe de sécurité. Lorsque le code est examiné par les spécialistes AppSec traditionnels/Waterfall, que ce soit avec des outils ou un examen manuel complexe, ils trouvent souvent des risques et des vulnérabilités inacceptables qui doivent alors être corrigés après coup. Le processus d'intégration de correctifs de sécurité dans des applications terminées n'est ni rapide ni facile... et il est beaucoup plus coûteux pour l'organisation.

Alors, si le monde évolue après Waterfall, Agile et maintenant DevOps, quelle est la solution ? Et en tant que développeur, quel est votre rôle pour suivre le rythme de ces changements d'approche ?

Les techniques de développement sont en constante évolution, mais heureusement, celle-ci n'est pas un changement si important. Les organisations ont juste besoin de mettre le "Sec" dans "DevOps"... et c'est ainsi que DevSecOps est né. L'un des principaux objectifs de DevSecOps est de faire tomber les barrières et d'ouvrir la collaboration entre les équipes de développement, d'exploitation et, enfin et surtout, de sécurité. DevSecOps est devenu à la fois une tactique d'ingénierie logicielle et une culture qui prône l'automatisation et la surveillance de la sécurité tout au long du cycle de vie du développement logiciel.

Cela peut sembler être un autre processus au niveau de l'organisation, peut-être un processus avec "trop de cuisiniers" lorsqu'il s'agit d'un développeur avec une longue liste de fonctionnalités à construire. Cependant, la méthodologie DevSecOps offre aux développeurs sensibilisés à la sécurité la possibilité de briller.

L'avenir radieux de DevSecOps

Alors, pourquoi un codeur voudrait-il devenir un ingénieur DevSecOps ? Vous avez peut-être une certaine expérience de DevOps (ou même d'Agile), mais vous souhaitez passer à l'étape suivante pour devenir compétent en DevSecOps. Tout d'abord, il est bon de savoir qu'il s'agit d'une démarche très intelligente, et pas seulement dans le but de mettre le monde à l'abri de cyberattaques coûteuses. Les experts affirment que la demande de personnel talentueux dans le domaine de la cybersécurité monte en flèche et qu'il n'y a pas de fin en vue. Ceux qui maîtrisent DevSecOps peuvent s'attendre à une carrière longue et rentable.

La sécurité de l'emploi pour les ingénieurs DevSecOps est encore plus assurée, car contrairement aux tactiques traditionnelles de cybersécurité telles que l'analyse des vulnérabilités à l'aide d'une gamme d'outils logiciels, DevSecOps nécessite des personnes qui savent comment mettre en œuvre la sécurité au fur et à mesure qu'elles codent. Comme le notent les analystes de Booz, Allen et Hamilton dans leur blog intitulé 5 Myths of Adopting DevSecOps, les entreprises veulent et ont même besoin de DevSecOps, mais ne peuvent tout simplement pas l'acheter. DevSecOps est une méthodologie qui permet aux équipes interfonctionnelles d'intégrer des technologies et de collaborer tout au long du cycle de vie du développement logiciel, et qui nécessite des personnes qualifiées, une gestion du changement et un engagement permanent de la part de multiples parties prenantes.

Selon Booz, Allen et Hamilton, les entreprises peuvent acheter des applications et des outils pour faciliter certains aspects de DevSecOps, comme un logiciel de gestion des versions, "mais ce sont vraiment vos équipes de livraison qui en sont responsables". Ce sont elles qui sont à l'origine de l'amélioration continue offerte par DevSecOps et de son changement de culture et de paradigme.

Les organisations ne peuvent pas "acheter" un programme DevSecOps viable ; il doit être construit et maintenu, en utilisant une gamme d'outils, des connaissances internes et des conseils qui améliorent la culture de la sécurité, tout en ayant un sens commercial. Ce n'est pas facile, mais c'est loin d'être impossible.

Comment vous pouvez vous démarquer dans le mouvement DevSecOps

L'une des premières étapes pour devenir un ingénieur DevSecOps est de réaliser qu'il s'agit autant d'une culture que d'un ensemble de techniques. Il faut avoir la volonté de mettre en œuvre la sécurité dans chaque morceau de code que vous créez, et le désir de protéger votre organisation de manière proactive en recherchant activement les failles de sécurité et les vulnérabilités au fur et à mesure que vous codez, et en les corrigeant bien avant qu'elles n'atteignent la phase de production. La plupart des ingénieurs DevSecOps prennent leur profession et leurs compétences très au sérieux. L'organisation professionnelle DevSecOps dispose même d'un manifeste énonçant ses convictions.

Le manifeste est un peu lourd, car les manifestes sont rarement légers à lire. Mais au cœur de ce manifeste se trouvent quelques vérités que tous les grands ingénieurs DevSecOps devraient apprendre à embrasser, comme :

• Réalisez que l'équipe chargée de la sécurité des applications est votre alliée. Dans la plupart des entreprises, les spécialistes de la sécurité des applications sont en désaccord avec les développeurs, car ils renvoient toujours le code terminé pour qu'il soit retravaillé. Les équipes AppSec n'aiment pas non plus beaucoup les développeurs, car ils peuvent retarder la mise en production du code terminé en introduisant des bogues de sécurité courants. Cependant, un ingénieur DevSecOps intelligent comprendra que les objectifs des équipes de sécurité sont en fin de compte les mêmes que ceux des développeurs et des codeurs. Vous n'avez pas besoin d'être les meilleurs amis du monde, mais l'établissement d'une relation de travail sereine et collaborative est essentiel à la réussite.
• Pratiquez et affinez vos techniques de codage sécurisé. Si vous parvenez à détecter les vulnérabilités des applications alors qu'elles sont encore en cours d'élaboration, vous pourrez alors combler ces lacunes et arrêter les futurs pirates dans leur élan. Bien entendu, il faut pour cela comprendre les vulnérabilités et disposer des outils nécessaires pour y remédier. Les pages du blogSecure Code Warrior peuvent vous donner un aperçu des vulnérabilités les plus courantes et les plus dangereuses que vous rencontrerez, ainsi que des conseils pratiques et des défis pour tester vos connaissances. L'aspect le plus important est de garder la sécurité à l'esprit et de prendre le temps de suivre des formations de courte durée qui vous aideront à développer vos connaissances existantes. Il est courant que les interactions d'un développeur avec la sécurité soient plutôt banales, voire négatives, mais le renforcement des compétences en matière de sécurité est un excellent moyen d'évoluer dans sa carrière, et cela ne doit pas être une corvée.
• Rappelez-vous : Les superstars du DevSecOps contribuent à une culture de sécurité positive au sein de leur organisation. Au lieu de se concentrer sur les objectifs du passé, comme la livraison rapide d'applications sans tenir compte des problèmes inhérents, il est important de faire de la recherche et de la correction des vulnérabilités dans le code de développement une priorité absolue. La sécurité doit être considérée comme le travail de chacun, et tout le monde devrait partager l'adulation et les récompenses qui découlent du déploiement d'applications efficaces et hautement sécurisées à chaque fois.

Vous pouvez contribuer à cultiver une incroyable culture de la sécurité au sein de votre organisation en défendant le codage sécurisé et les meilleures pratiques de sécurité dès le départ, en recommandant des solutions de formation et en veillant à ce qu'aucun codeur ne soit laissé pour compte dans le monde en constante évolution de DevSecOps. Le seul bon code est un code sécurisé, et les développeurs compétents et sensibilisés à la sécurité sont des pièces essentielles du puzzle. Les récompenses personnelles et professionnelles en valent certainement la peine, et avec des milliards d'enregistrements de données personnelles compromis chaque année (et de plus en plus), nous avons besoin de vous. Prenez place en première ligne et aidez-nous à nous défendre contre les méchants dans notre monde numérique.

Matias Madou, docteur en sciences, est directeur technique et cofondateur de Secure Code Warrior. C'est un expert en sécurité, un développeur de longue date et un accro de Fortnite.

Il existe une théorie bien connue selon laquelle les cafards peuvent survivre à n'importe quoi, même à une explosion nucléaire. Bien que cette théorie ne soit vraie que jusqu'à un certain point, leur simple composition corporelle les rend extrêmement résistantes pour leur taille et difficiles à éradiquer dans la plupart des conditions.

J'ai réfléchi... si les cafards avaient un équivalent dans le monde numérique, il s'agirait des vulnérabilités de code par injection SQL (SQLi). Il s'agit d'une vulnérabilité connue depuis plus de vingt ans, et pourtant les organisations en sont victimes à maintes reprises. L'attaque généralisée et coûteuse contre Target était le résultat d'une injection SQL, de même qu'un piratage électoral dans l'Illinois au cours duquel 200 000 dossiers d'électeurs ont été exposés, ce qui a incité le FBI à recommander à tous les administrateurs informatiques de travailler rapidement au renforcement de leurs pratiques en matière de sécurité.

Le rapport Hacker Intelligence Initiative d'Imperva a révélé qu'entre 2005 et 2011, les attaques SQLi ont été utilisées dans 83 % de toutes les violations de données signalées. Aujourd'hui, les vulnérabilités par injection restent la première menace du Top 10 de l'OWASP. Elles sont relativement simples, mais elles ne veulent pas mourir.

Il semble ridicule que cette même vulnérabilité apparaisse encore dans un nombre important d'analyses de sécurité d'applications. Nous savons comment elle fonctionne et nous savons comment l'arrêter. Comment cela est-il possible ? La vérité, c'est que la sécurité de nos logiciels peut encore être largement améliorée.

Le rapport State of Software Security Report de Veracode - basé sur 400 000 scans d'applications en 2017 " a révélé une statistique alarmante : seulement 30 % des applications ont passé la politique Top 10 de l'OWASP. Il s'agit d'un thème constant au cours des cinq dernières années, les injections SQL apparaissant dans près d'une application nouvellement analysée sur trois. C'est la preuve d'un problème endémique ; nous n'apprenons pas de nos erreurs, et les RSSI semblent être confrontés à une bataille difficile pour se procurer suffisamment de talents en matière de sécurité. En règle générale, le rapport entre les spécialistes de la sécurité applicative et les développeurs est insuffisant (1:100).

Pourquoi la sécurité des logiciels est-elle sous assistance respiratoire ?

Ce n'est un secret pour personne que les spécialistes de la sécurité sont rares, mais nous devons également prêter attention au fait que les développeurs ne corrigent pas les problèmes au fur et à mesure qu'ils surviennent, et qu'ils sont manifestement mal équipés pour ne pas introduire de vulnérabilités en premier lieu. Le même rapport de Veracode révèle qu'il n'existe des mesures d'atténuation documentées que pour 14,4 % de toutes les vulnérabilités liées au développement. En d'autres termes, la plupart des vulnérabilités ont été soumises sans mesures d'atténuation. Moins d'un tiers des vulnérabilités ont été résolues dans les 90 premiers jours, et 42 % des vulnérabilités n'ont jamais été résolues au cours de la période de développement.

Je m'entretiens en permanence avec des professionnels de la sécurité, des RSSI et des PDG et, de manière anecdotique, je me suis rendu compte que de nombreuses entreprises sont tellement frustrées par le nombre de vulnérabilités trouvées qui ne peuvent pas être atténuées (en plus du fléau connu sous le nom de faux positifs), qu'elles cessent complètement de les rechercher, croisent les doigts et espèrent que tout ira pour le mieux.

Pourquoi les professionnels de l'AppSec laissent-ils faire ?

Ne vous y trompez pas : Les personnes chargées de l'AppSec sont douloureusement conscientes des problèmes dans le code. Après tout, c'est l'une de leurs principales compétences qui fait d'eux une ressource si précieuse pour l'équipe. Cependant, ils sont souvent paralysés par plusieurs facteurs.

Par exemple, un responsable AppSec trouvera un problème et demandera au développeur : "Pouvez-vous corriger le code ?". La réponse à cette question importante diffère d'une organisation à l'autre, mais en général, le développeur est tellement sollicité pour respecter des sprints stricts de livraison de fonctionnalités qu'il n'a tout simplement pas le temps de résoudre ces problèmes, ni d'outils décents pour l'aider. Les professionnels de l'AppSec eux-mêmes peuvent être en mesure d'identifier les vulnérabilités, mais ils n'ont souvent pas les compétences et/ou l'accès nécessaires pour y remédier sur-le-champ.

Nous devons également nous rendre compte que pour chaque problème, il faut trouver une solution, la mettre en œuvre et la tester. Pour le moindre problème découvert dans le code, le temps nécessaire à la correction, sans parler des ressources requises, est immense. Il existe plus de 700 vulnérabilités qui peuvent être introduites dans les logiciels, et il est tout simplement impossible pour une seule personne d'être en mesure de se défendre contre toutes ces vulnérabilités. C'est pour cette raison que la plupart des entreprises se contentent de suivre le Top 10 de l'OWASP. Pendant ce temps, les développeurs continuent à créer des fonctionnalités et, à leur tour, à introduire des vulnérabilités dans le code qu'ils écrivent.

Quelle est la solution ?

Le fait est que nous ne donnons pas à nos développeurs les outils et la formation nécessaires pour qu'ils réussissent à coder en toute sécurité. Aucune réglementation n'oblige les organisations à s'assurer que les développeurs possèdent des compétences adéquates en matière de sécurité, et il est triste de constater que la plupart des universités et des stages ne préparent pas non plus les jeunes développeurs à coder de manière sécurisée.

Lorsque quelqu'un souhaite piloter un avion, il est soumis à un processus très rigoureux qui prévoit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant qu'il ne soit en mesure de voler. Personne n'oserait imaginer qu'on le laisse voler dans le ciel sans une telle préparation et une telle validation de ses compétences.  

Nous devons prendre le temps de former les développeurs à l'écriture de codes sécurisés. Cependant, dans le monde d'aujourd'hui, où le développement de logiciels se fait à un rythme rapide et où les bons développeurs et les professionnels de la sécurité sont rares, cela ne semble jamais être une priorité. Il est temps de changer la donne.

Le Forum économique mondial a récemment titré : "Il ne peut y avoir d'économie numérique sans sécurité" : "Il ne peut y avoir d'économie numérique sans sécurité", et le contenu qui l'accompagne fait valoir la nécessité d'intégrer la sécurité au cœur de toute stratégie de transformation numérique. "La sécurité est ce qui protège les entreprises, leur permettant d'innover et de créer de nouveaux produits et services. Au-delà d'un rôle défensif, la sécurité offre aux entreprises un avantage stratégique en termes de croissance".

L'amélioration des compétences et des résultats en matière de codage sécurisé ajoutera une puissante couche de cyberprotection pour les organisations, en les aidant à créer un code meilleur et plus rapide. Les développeurs n'ont pas besoin de devenir des experts en sécurité, mais ils doivent être responsabilisés de manière positive et pratique pour être la première ligne de défense contre les cyberattaques. Les développeurs peuvent être les prochains héros de la sécurité et de l'innovation. Ce sont des personnes très intelligentes, qui savent résoudre les problèmes de manière créative et qui sont généralement désireuses d'améliorer leurs compétences. Misez sur leurs atouts en leur offrant la formation spécialisée qu'ils méritent et engagez-vous à appliquer des normes plus strictes en matière de sécurité des logiciels. Lisez notre livre blanc pour en savoir plus.

Lorsque quelqu'un souhaite piloter un avion, il est soumis à un processus très rigoureux qui prévoit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant qu'il ne soit en mesure de voler. Personne n'oserait imaginer qu'on le laisse voler dans le ciel sans une telle préparation et une telle validation de ses compétences.