Bienvenue sur notre blog.
![Automatiser la gestion des vulnérabilités techniques [SOC 2]](https://cdn.prod.website-files.com/642adcaf364024654c71df23/67643587d60e739a2713e706_1887747146-2_e9a02ce5d4c4c0b738e209b16c20f222_2000.png)
Automatiser la gestion des vulnérabilités techniques [SOC 2]
Comment devenir conforme sans imposer une lourde charge de travail à votre équipe de développement ?
La mise en conformité avec les normes ISO 27001 et SOC 2 peut être une tâche ardue, en particulier lorsqu'il s'agit de la gestion des vulnérabilités techniques. Cependant, avec les bons outils et le bon soutien, ce n'est pas une fatalité. Dans ce billet de blog, nous verrons comment Aikido et Vanta peuvent vous aider à aborder les aspects techniques de la conformité SOC 2.

Couvrir les exigences techniques en matière de gestion des vulnérabilités pour SOC 2
Pour se conformer à la norme SOC 2, les entreprises doivent mettre en œuvre des mesures techniques de gestion des vulnérabilités. Il s'agit d'identifier, de hiérarchiser et de traiter les vulnérabilités de votre base de code et de votre infrastructure. Pour répondre à ces exigences et garantir la sécurité de vos systèmes, vous devez suivre une série d'étapes et mettre en œuvre un processus :
- Effectuer une évaluation des risques
La première étape consiste à effectuer une évaluation des risques de votre base de code et de votre infrastructure afin d'identifier les vulnérabilités potentielles. Il s'agit d'analyser vos systèmes et d'identifier les faiblesses potentielles qui pourraient être exploitées par des attaquants. - Classer les vulnérabilités par ordre de priorité
Une fois que vous avez identifié les vulnérabilités potentielles, vous devez les classer par ordre de priorité en fonction de leur gravité et de leur impact potentiel sur vos systèmes. Cela vous aidera à concentrer vos efforts sur les vulnérabilités les plus critiques. - Traiter les vulnérabilités
L'étape suivante consiste à traiter les vulnérabilités identifiées. Il peut s'agir de mettre en œuvre des correctifs, de mettre à jour des logiciels ou de modifier la configuration de vos systèmes. - Test d'efficacité
Après avoir remédié aux vulnérabilités, il est essentiel de tester l'efficacité des correctifs que vous avez mis en œuvre. Cela implique de mener des tests de pénétration et d'autres tests de sécurité pour s'assurer que vos systèmes sont sécurisés. Les tests de pénétration ne sont toutefois pas une condition sine qua non pour obtenir la certification SOC 2. - Surveillance continue
Enfin, il est essentiel de surveiller en permanence vos systèmes pour détecter les vulnérabilités et les menaces potentielles. Cela implique la mise en œuvre d'un programme de gestion des vulnérabilités qui analyse régulièrement votre base de code et votre infrastructure pour détecter les vulnérabilités et les risques potentiels.
En suivant ces étapes, les entreprises peuvent s'assurer qu'elles répondent aux exigences de gestion des vulnérabilités techniques pour la conformité SOC 2 et qu'elles disposent de systèmes sécurisés pour protéger leurs données et leur infrastructure.
Automatiser le processus avec Aikido
Pour vous mettre en conformité, vous pouvez mettre en œuvre le processus manuellement ou utiliser une plateforme de gestion des vulnérabilités, telle qu'Aikido. Nous allons vous présenter le processus et la manière de l'automatiser.
1. Effectuer une évaluation des risques
En se connectant à votre code et à votre infrastructure cloud, Aikido procède automatiquement à une évaluation des risques. Il analyse en profondeur vos systèmes, identifiant les vulnérabilités potentielles qui pourraient être exploitées par des attaquants. Comme Aikido est sans agent, vous pouvez obtenir une vue d'ensemble en 30 secondes. Plus besoin de perdre des heures à installer des logiciels coûteux ou à configurer et maintenir des outils gratuits.
2. Classer les vulnérabilités par ordre de priorité
Une fois l'évaluation des risques terminée, Aikido classe les vulnérabilités par ordre de priorité. Au lieu de vous submerger avec une longue liste de toutes les vulnérabilités présentes dans votre système, les vulnérabilités sont dédupliquées et triées automatiquement. Les vulnérabilités sont dédupliquées et triées automatiquement, vous ne verrez que celles qui sont vraiment importantes et exploitables. Vous pouvez ainsi concentrer vos efforts sur les vulnérabilités les plus critiques.

3. Traiter les vulnérabilités
La correction des vulnérabilités peut être une tâche manuelle, mais Aikido la rend facile. Des fonctionnalités telles que l'autofixation vous permettent d'effectuer une RP en un seul clic. De plus, Aikido s'intègre parfaitement aux outils que vous utilisez déjà. Qu'il s'agisse d'implémenter des correctifs, de mettre à jour des logiciels ou d'effectuer des changements de configuration.

4. Test d'efficacité
Pour s'assurer de l'efficacité des correctifs mis en œuvre, nous conseillons de réaliser un pentest. Vous pourrez ainsi valider l'efficacité des mesures de sécurité et vous assurer que vos systèmes sont robustes face aux attaques potentielles. Cependant, pour SOC 2, cela n'est pas nécessaire. Aikido travaille généralement avec Shift Left Security, mais vous êtes libre de choisir le consultant de votre choix.
5. Contrôle continu
De plus, Aikido vous aide à assurer une surveillance continue, un aspect crucial du maintien de systèmes sécurisés. Aikido scanne votre environnement toutes les 24 heures pour détecter les nouvelles vulnérabilités et les nouveaux risques. En surveillant continuellement vos systèmes, vous pouvez rester proactif dans l'identification et la résolution des vulnérabilités et menaces émergentes.
Avec Aikido, vous pouvez automatiser l'ensemble du processus de gestion des vulnérabilités, de l'évaluation des risques à la hiérarchisation des vulnérabilités, en passant par le traitement des vulnérabilités, les tests d'efficacité et la surveillance continue. En s'appuyant sur les fonctionnalités d'Aikido, les entreprises peuvent répondre aux exigences techniques de gestion des vulnérabilités pour la conformité SOC 2 et mettre en place un environnement sécurisé pour protéger leurs données et leur infrastructure.
Pourquoi l'intégration de l'Aïkido et de Vanta vous fera gagner du temps et de l'argent
Plus de processus manuels à suivre
Aikido met la gestion des vulnérabilités techniques en pilote automatique. La plateforme surveille en permanence votre posture de sécurité en arrière-plan. Vous n'êtes averti que lorsque c'est vraiment important. De plus, elle automatise 16 tests Vanta et aide à passer 5 contrôles Vanta.

Plus de temps perdu à trier les faux positifs
La majorité des plateformes de sécurité envoient sans distinction toutes les vulnérabilités identifiées à Vanta. Il en résulte une perte de temps considérable, car il faut passer au crible de nombreux faux positifs. Par exemple, lorsque vous utilisez d'autres outils de sécurité, toutes les vulnérabilités trouvées sont envoyées à Vanta, ce qui signifie que vous devez passer beaucoup de temps à les trier. En revanche, Aikido a construit un moteur de tri automatique qui agit comme un filtre utile, vous faisant gagner un temps précieux.
Fini le gaspillage d'argent avec des licences coûteuses
Le secteur de la sécurité est en proie à des modèles de tarification prédateurs trop complexes. Certaines entreprises adoptent une tarification basée sur l'utilisateur, ce qui encourage les développeurs à partager leurs comptes, compromettant ainsi la sécurité. D'autres optent pour des modèles de tarification basés sur la ligne de code, qui deviennent très vite onéreux. Nous rejetons ces approches et proposons à la place une tarification fixe et simple par organisation. Avec Aikido, vous pouvez commencer à partir de 249 € par mois. En choisissant notre modèle, vous pouvez espérer économiser environ 50% par rapport à vos concurrents.
Vanta, une pièce essentielle du puzzle
Pour mettre en œuvre la norme SOC 2, il ne suffit pas de gérer les vulnérabilités techniques. Vous aurez besoin d'une solution logicielle générale de conformité à la sécurité. Une plateforme telle que Vanta automatise 90% du processus complexe et chronophage de SOC 2. De plus, elle s'intègre parfaitement à Aikido. Tous les aspects de la gestion des vulnérabilités techniques deviennent ainsi d'une simplicité déconcertante.

Pourquoi attendre ? Essayez Aikido gratuitement dès aujourd'hui (l'inscription prend 30 secondes) et accélérez votre mise en conformité SOC 2.

Prévenir la pollution des prototypes dans votre référentiel
Si vous êtes arrivé sur cette page directement à partir d'une Pull Request d'Aikido Autofix et que vous voulez juste apprendre à terminer la PR, passez directement à 'How to implement'.
L'écosystème JavaScript a un problème qui s'appelle la pollution par les prototypes. Pour une entreprise SaaS qui utilise JavaScript/npm, 20 à 30 % de toutes les vulnérabilités connues (CVE) détectées dans les dépendances sont causées par la pollution des prototypes. Elles ne sont généralement pas faciles à exploiter, mais dans les cas les plus graves, elles peuvent conduire à des failles d'exécution de code à distance. Il est donc difficile de les ignorer complètement.
Deux façons de prévenir la pollution des prototypes
Il existe un support expérimental dans Node.js pour geler le prototype par défaut sous un drapeau appelé --frozen-intrinsics. L'activation de ce drapeau met en échec toutes les attaques par pollution du prototype. Cependant, nous ne pouvons pas encore le recommander parce qu'il est expérimental et qu'il ne fonctionnera pas sur les bases de code frontales. Cela vous empêcherait de construire la même protection pour votre frontend et votre backend.
Une alternative est nopp (No Prototype Pollution), une bibliothèque de 14 lignes qui gèle le prototype (et certains autres points d'entrée).
Comment mettre en œuvre
1. Importer la bibliothèque
Après avoir installé nopp, tout ce que vous avez à faire est d'aller dans le script qui démarre votre application. Là, il vous suffit d'exiger la bibliothèque, après avoir exigé toutes vos autres bibliothèques. Exemple de livraison ci-dessous :

2. Vérification de la sécurité des bibliothèques à l'échelle de l'application en fonction de la manipulation du prototype
La raison pour laquelle nous gelons le prototype après avoir inclus d'autres bibliothèques est que certaines de vos autres bibliothèques peuvent dépendre de la modification du prototype pour fonctionner ! Même en s'assurant de geler le prototype APRES avoir inclus d'autres bibliothèques, il est toujours possible que vous ayez besoin d'un remaniement avant que votre application ne fonctionne à nouveau !
Par exemple, le kit aws-sdk d'Amazon pour Node.js modifie le prototype lors de la construction d'objets tels que "new AWS.S3(...)". Dans de tels cas, vous devrez peut-être procéder à un remaniement comme indiqué ci-dessous, en vous assurant que l'objet est créé lorsque votre processus Node.js est démarré et non lors d'une phase ultérieure.

S'assurer que votre application fonctionne toujours après ce changement peut représenter un investissement en temps plus important pour les grands dépôts qui ont une faible couverture de test. Pour les référentiels plus petits, cela vaut la peine de ne plus jamais avoir à s'occuper de la pollution des prototypes. Pour les référentiels plus importants, cela peut s'avérer plus complexe, mais l'investissement en ingénierie aura probablement un retour sur investissement positif à long terme.

Comment le directeur technique d'une startup SaaS peut-il concilier vitesse de développement et sécurité ?
Enseignements tirés de l'expérience des entreprises SaaS
Dans une startup SaaS typique, l'équipe de développement est soumise à une forte pression pour fournir de nouvelles fonctionnalités. Vous avez généralement des concurrents qui peuvent être mieux financés, vous avez l'équipe de vente qui demande une dernière fonctionnalité pour conclure l'affaire, l'équipe d'assistance à la clientèle qui demande une correction de bug. Il peut être difficile de donner la priorité à la sécurité, à moins qu'une grande entreprise cliente ne l'exige ou que votre conseil d'administration ne l'impose d'en haut.
Dans la plupart des startups, vous ne disposez pas d'une gamme complète de profils techniques : vous n'avez peut-être pas encore de chef de produit à plein temps, ni de responsable de la sécurité à plein temps au sein de votre équipe de développement. Une équipe de développement sous pression sera obligée de prendre des raccourcis, même en matière de sécurité.
J'ai été le directeur technique de trois start-ups SaaS en phase de démarrage (Teamleader, Officient et Futureproofed). (Teamleader, Officient & Futureproofed) J'ai décrit ci-dessous les enseignements que j'ai tirés de ces expériences passées dans le domaine des SaaS.

Éviter de réinventer la roue
Un bon exemple : ne construisez pas un système de connexion avec des mots de passe. Certes, vous pouvez le construire en quelques jours, mais le coût de sa maintenance et de l'ajout de fonctions de protection avancées à l'avenir sera très élevé. Envisagez d'utiliser un login via Single-sign on tel que Gmail ou utilisez un service tel que Auth0.com. Non seulement vous bénéficierez d'une expérience de connexion plus fluide et plus riche en fonctionnalités, mais vous n'aurez pas non plus à vous préoccuper de toute une série d'aspects de sécurité liés à la connexion (forçage brutal, fuite d'informations d'identification de l'utilisateur dans des services tiers, prévention et détection des attaques par prise de contrôle du compte, validation des adresses de courrier électronique, journalisation...).
En fin de compte, si vous choisissez le bon fournisseur, vous ne réduisez pas seulement votre surface d'attaque, vous gagnez aussi du temps qui peut être consacré à des fonctions plus utiles.
Voici d'autres exemples qui pourraient vous faire gagner des semaines, voire des mois :
- Ne stockez pas de cartes de crédit, utilisez quelque chose comme Stripe, Mollie ou Chargebee.
- N'exécutez pas vous-même des logiciels complexes tels que MySQL, PostgreSQL ou ElasticSearch. Utilisez des services en nuage gérés tels que RDS.
- Ne créez pas vos propres systèmes de journalisation. Utilisez des systèmes tels que Sentry ou Papertrail (et n'y enregistrez aucune donnée sensible).
- Ne gérez pas vos propres serveurs de messagerie (SMTP), utilisez un service géré comme Sendgrid ou Mailgun.
- Ne construisez pas de serveurs websocket, utilisez des services gérés tels que Pusher.com
- Ne créez pas votre propre système de marquage des caractéristiques, utilisez un service tel que Launchdarkly.
- Ne créez pas votre propre intégration de calendrier, utilisez un outil comme cronofy.com
- Lorsque vous créez des intégrations en général, recherchez des API unifiées dans ce domaine, comme Apideck.
Investir du temps dans un dispositif de communication de crise
Veillez à mettre en place des outils tels qu'une application de chat pour parler à vos clients ou, mieux encore, une page d'état gérée ou un compte Twitter où vous pouvez communiquer les problèmes. En cas de problème, c'est une bonne pratique de permettre au reste de votre entreprise de communiquer avec vos clients pendant que vous vous concentrez sur la résolution du problème en cas de crise.
Ajouter des garde-fous globaux
Vous êtes probablement en train de passer en revue les Pull Requests de vos développeurs, super ! C'est une tâche considérable que de les examiner du point de vue de la maintenabilité, des performances et des fonctionnalités. Avez-vous le temps de les examiner également du point de vue de la sécurité ? Il est certain que vous serez en mesure de couvrir certains risques, mais il est agréable de pouvoir écarter certains risques en ajoutant des garde-fous et une configuration globale.
Parfois, vous avez de la chance et il existe des solutions globales pour des problèmes spécifiques.
- Si vous utilisez nodeJS et que vous n'aimez pas penser à la pollution des prototypes, vous devriez geler le prototype pour désactiver cette classe d'attaques à l'échelle de l'application. Aikido peut automatiquement construire une Pull Request qui fait cela pour vous.
- Si vous utilisez SQL et craignez les attaques par injection SQL (vous devriez), vous pouvez utiliser un WAF (comme AWS WAF) ou un RASP (comme Datadog's app security) pour une protection à l'échelle de l'application.
- Si vous découvrez un grand nombre d'attaques XSS, vous pouvez probablement en éliminer une grande partie en introduisant une politique CSP très stricte dans le navigateur.
- Si vous effectuez beaucoup de requêtes sortantes basées sur les données des clients, vous pourriez être vulnérable aux attaques SSRF. Bien qu'il soit difficile de bloquer complètement ces attaques, vous pouvez atténuer les dommages en vous assurant qu'elles ne peuvent pas conduire à quelque chose de pire (comme une attaque IMDSv1 sur les informations d'identification IAM dans AWS). Aikido surveille cela dans votre nuage AWS par défaut.
- Lorsqu'il s'agit de stockage d'objets, éviter des types de fonctions spécifiques comme Pickle, XML, (un)serialize en Java et PHP,... et à la place opter pour des options de stockage simples comme JSON peut éviter beaucoup d'exploits typiques liés à la non-sérialisation non sécurisée. Aikido surveille ces types de fonctions dans votre base de code par défaut.
- Si vous utilisez un CDN ou des mécanismes de mise en cache, utilisez des domaines distincts pour vos actifs statiques avec des configurations CDN distinctes afin d'éviter toutes sortes d'attaques par empoisonnement du cache (ChatGPT est tombé dans ce piège récemment).
Sensibilisez vos développeurs à l'aide de cette simple astuce
Il existe un moyen simple (jeu de mots) de mettre en œuvre vos processus. Une question rapide à poser à l'équipe de développement pendant la planification du sprint :
Comment la fonctionnalité que nous construisons peut-elle être piratée (et comment l'empêcher) ?
Bien que l'équipe de développement ne puisse pas anticiper tous les scénarios d'abus potentiels, cette méthodologie est très simple à mettre en œuvre. Il s'agit d'une petite étape supplémentaire qui encourage les développeurs à vérifier les considérations de sécurité avant d'entreprendre tout travail de développement.

Attribuer des priorités aux différentes parties de votre base de code
Tout ne sera pas une cible aussi importante pour les pirates. Les éléments clés qu'ils aiment cibler sont :
- Systèmes de paiement, portefeuilles, systèmes de crédit
- Fonctionnalité qui se connecte à des API coûteuses telles que SMS, voip (pensez à Twilio)
- Réinitialisation du mot de passe, systèmes de connexion, invitations d'utilisateurs
- Les fonctions d'exportation telles que PDF, Excel,... les exportations qui peuvent effectuer des opérations risquées.
- Tout ce qui concerne le téléchargement de fichiers et d'images
- Fonctionnalités qui effectuent des requêtes sortantes par conception, telles que les webhooks
- Toute fonction permettant d'envoyer des courriers électroniques, en particulier avec un contenu personnalisé
PS : Aikido peut vous aider à vous concentrer sur les meilleurs dépôts dans l'univers de votre startup en assignant des niveaux de risque à chaque base de code.
N'oubliez pas l'aspect humain
En tant que directeur technique d'une petite entreprise en démarrage, vous êtes généralement responsable de la sécurité opérationnelle. Donnez à votre équipe les moyens de sécuriser leurs comptes. Assurez-vous qu'ils utilisent des Yubikeys matériels ou des applications logicielles pour le 2FA et, si possible, imposez-le. Des outils comme Gmail permettent de le faire. C'est une excellente première ligne de défense contre les attaques de phishing.
Il est difficile de se tenir au courant des pratiques de sécurité
Il est difficile de s'informer sur les nouveaux types d'attaques contre les logiciels. Il est déjà assez difficile de suivre les mises à jour des langages que vous utilisez (Python, Node, Go,..) ou les correctifs des systèmes d'exploitation ou les exploits populaires dans les paquets open-source. Certaines attaques deviennent de plus en plus populaires au fil du temps et il est donc utile de suivre les tendances. Par exemple, après avoir remarqué une augmentation des attaques par prise de contrôle de sous-domaines l'année dernière, Aikido a introduit un outil de surveillance de prise de contrôle de sous-domaines afin de prévenir ce risque et d'automatiser la pratique de la surveillance de ces enregistrements DNS.
Automatiser
Dans mes entreprises précédentes, nous essayions d'atteindre un niveau de sécurité supérieur en demandant à une personne chargée de la sécurité d'établir un calendrier avec des tâches de sécurité récurrentes. Effectuer un examen de l'accès à toutes les applications chaque trimestre. Effectuer une analyse des fuites de secrets sur le code toutes les deux semaines, nettoyer les CVE des paquets open source tous les vendredis, effectuer une analyse SAST de temps en temps, vérifier les enregistrements DNS pour les prises de contrôle de sous-domaines tous les mois,... Les résultats de ces tâches étaient difficiles à trier et à rendre exploitables pour les développeurs. Pire encore, lorsque cette personne quittait l'entreprise, il était difficile pour quiconque de reprendre ces tâches car elles nécessitaient de nombreuses connaissances spécifiques.
C'est là que l'idée d'Aikido a commencé à germer. Nous avions besoin d'une solution pour automatiser tout ce qui précède, filtrer le bruit et présenter les tâches à vos développeurs dans Slack ou Jira.
Commencez à scanner votre code et votre nuage avec Aikido dès aujourd'hui. Inscrivez-vous ici et commencez à scanner gratuitement.

Comment le cloud d'une startup a été pris en charge par un simple formulaire d'envoi de courriels
Prévenir la prise de contrôle totale du nuage par des attaques SSRF
Voici l'histoire d'un attaquant qui a eu accès aux buckets Amazon S3 d'une startup, à des variables d'environnement et à divers secrets d'API internes, le tout par le biais d'un simple formulaire qui envoie un courrier électronique. Bien qu'il s'agisse d'une histoire vraie, je garde le nom de la startup secret.

Comment ils sont entrés
Tout commence par une application PHP qui envoie un courrier électronique. Pour charger certaines images fantaisistes en pièces jointes, l'application doit les télécharger. En PHP, c'est facile. Vous utilisez la fonction file_get_contents et c'est là que tout commence.
Bien entendu, certaines des données saisies par les utilisateurs pour ce courrier électronique n'ont pas été entièrement vérifiées ou codées en HTML, et un utilisateur a donc pu inclure une image telle que <img src=’evil.com’/>
. En théorie, ce n'est pas si mal, mais malheureusement, cette fonction PHP est très puissante et peut faire bien plus que charger des images sur l'internet. Elle peut également lire des fichiers locaux et, plus important encore, des fichiers sur le réseau local au lieu d'Internet.
Au lieu de evil.com, l'attaquant a saisi une URL locale spéciale. Vous pouvez utiliser cette URL pour obtenir les informations d'identification IAM liées au rôle du serveur AWS EC2 que vous exécutez à l'aide d'une simple requête GET.
<img src=’http://169.254.169.254/latest/meta-data/'>
Le résultat est que l'attaquant a reçu un courriel contenant les identifiants IAM du serveur EC2 dans une pièce jointe de la boîte aux lettres. Ces clés permettent à l'attaquant d'usurper l'identité de ce serveur lorsqu'il communique avec divers services AWS. À partir de là, tout s'écroule...
Pourquoi cela est-il possible ?
Le système qui charge ces clés IAM est appelé IMDSv1 et Amazon a publié une nouvelle version en 2019 appelée IMDSv2. Avec IMDSv2, vous devez envoyer une requête PUT avec un en-tête spécial pour obtenir vos informations d'identification IAM. Cela signifie qu'une simple fonction de chargement d'URL basée sur GET comme file_get_contents ne peut plus causer autant de dégâts.
On ne sait pas exactement quel sera le taux d'adoption d'IMDSv2 en 2023, mais il est clair qu'Amazon prend toujours des mesures pour augmenter son adoption et que nous voyons IMDSv1 encore utilisé dans la nature.
La compromission des clés IAM entraîne d'autres compromissions : Les buckets S3 ont pu être listés et leur contenu lu. Pour aggraver les choses, l'un des buckets S3 contenait un modèle de formation de nuages, qui contenait des variables d'environnement sensibles (par exemple les clés API de Sendgrid).
Comment défendre mon infrastructure en nuage contre ce phénomène ?
Que peut-on faire pour éviter cette perte totale de données ? Vos développeurs pourraient être très prudents et veiller à utiliser une liste d'autorisations pour les URL qu'ils transmettent à file_get_contents. Ils pourraient même vérifier que le contenu qu'ils reçoivent est une image s'ils s'attendent à une image. En réalité, il est difficile d'éviter ce genre d'erreurs en tant que développeur.
Il serait préférable de s'assurer que votre infrastructure dispose de défenses supplémentaires contre ces attaques. Notre nouvelle intégration avec AWS au sein d'Aikido Security vous alertera si votre cloud ne prend pas activement l'une des mesures suivantes. Chacune de ces mesures aurait permis d'arrêter cette attaque, mais nous recommandons de toutes les mettre en œuvre. Utilisez notre compte d'essai gratuit pour voir si votre cloud est déjà défendu contre ces menaces. Découvrez comment Aikdido protège votre application contre les vulnérabilités ici.
Mesures à prendre :
- Migrer vos nœuds EC2 IMDSv1 existants pour utiliser IMDSv2
- Ne stockez aucun secret dans l'environnement de vos serveurs web ou dans les modèles de formation de nuages. Utilisez un outil tel que AWS Secrets Manager pour charger les secrets au moment de l'exécution.
- Lorsque vous attribuez des rôles IAM à vos serveurs EC2, veillez à ce qu'ils soient assortis de conditions supplémentaires, telles que la restriction de leur utilisation à l'intérieur de votre réseau AWS local (votre VPC). L'exemple ci-dessous permet à votre serveur de lire dans S3, mais uniquement si le serveur EC2 communique via un point d'extrémité VPC spécifique. Cela n'est possible qu'à partir de votre réseau, de sorte que l'attaquant n'aurait pas été en mesure d'accéder aux fichiers S3 depuis son ordinateur local.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
}
}
}
]
}
À propos de "The Kill Chain" (La chaîne de la mort)
The Kill Chain est une série d'histoires réelles d'attaquants atteignant les joyaux de la couronne d'entreprises de logiciels en enchaînant de multiples vulnérabilités. Rédigée par Willem Delbare, elle s'appuie sur ses dix années d'expérience dans la création et le soutien de startups SaaS en tant que directeur technique. Les récits proviennent directement du réseau de Willem et se sont réellement produits.

Aikido Security lève 2 millions d'euros pour créer une plateforme de sécurité logicielle destinée aux développeurs.
La startup belge SaaS Aikido Security a levé 2 millions d'euros en financement de pré-amorçage auprès d'investisseurs providentiels renommés qui soutiennent sa mission de simplifier la sécurité des logiciels pour les développeurs.
Ces dernières années, l'industrie du logiciel s'est orientée vers le développement "shift left", ce qui a eu pour effet d'accroître la responsabilité des développeurs en matière de sécurité. Malheureusement, les plateformes actuelles de sécurité logicielle sont difficiles à utiliser pour les développeurs, ce qui leur fait perdre beaucoup de temps. Aikido Security a été fondé pour relever ce défi.
Le tour de pré-amorçage a la chance de pouvoir compter sur le soutien d'un éventail d'investisseurs (anges) qualifiés. Syndicate One, Pieterjan Bouten (Showpad), Louis Jonckheere (Showpad), Christophe Morbee (Besox), Mathias Geeroms (OTA Insight) ont tous décidé de participer. Aikido Security a la chance de pouvoir compter sur leur soutien et leur expertise.
"Les outils de sécurité des logiciels ont rendu ma vie de directeur technique plus difficile".
explique Willem Delbare, fondateur et directeur technique d'Aikido Security. "J'en ai testé un grand nombre et ils souffrent tous des mêmes problèmes. Ils vous surchargent de faux positifs, vous inondent de notifications et rendent le triage difficile. J'ai trouvé cela très épuisant. Nous avons décidé d'y remédier.
L'équipe est composée d'entrepreneurs expérimentés qui ont construit des produits à succès dans diverses industries avant de se réunir au sein d'Aikido Security. L'équipe fondatrice est composée de Willem Delbare (Teamleader, Officient), Roeland Delrue (Showpad, Officient), Amber Rucker (Veriff, Cloudbees) & Felix Garriau (nexxworks, AREA42).
Aikido a récemment achevé la version alpha de son produit, qu'elle teste activement auprès des premiers utilisateurs. Le financement permet à la société d'agrandir son équipe et de compléter les fonctionnalités du produit, tout en développant sa base de clients.

A propos d'Aikido Security
Aikido Security est une plateforme de sécurité logicielle qui s'adresse d'abord aux développeurs. Nous analysons votre code source et votre cloud pour vous montrer quelles vulnérabilités sont réellement importantes à résoudre. Le triage est accéléré en réduisant massivement les faux positifs et en rendant les CVE lisibles par l'homme. Aikido simplifie la sécurisation de vos produits et vous redonne du temps pour faire ce que vous faites le mieux : écrire du code.