Les codeurs conquièrent la série sur l'infrastructure de sécurité en tant que code : Protection insuffisante de la couche transport
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.
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 consultation interne non autorisée.
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationMatias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
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.
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.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationMatias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
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.
Table des matières
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
Plongée en profondeur : Naviguer dans la vulnérabilité critique de CUPS dans les systèmes GNU-Linux
Découvrez les derniers défis de sécurité auxquels sont confrontés les utilisateurs de Linux en explorant les récentes vulnérabilités de haute sévérité dans le système d'impression commun d'UNIX (CUPS). Apprenez comment ces problèmes peuvent conduire à une potentielle exécution de code à distance (RCE) et ce que vous pouvez faire pour protéger vos systèmes.