Archives des Cybersecurity - Page 2 sur 2

La cybersécurité, un tremplin pour les talents atypiques

La cybersécurité, un tremplin pour les talents atypiques

La cybersécurité est devenue l’un des enjeux majeurs de notre époque. Chaque jour, les entreprises font face à des attaques toujours plus sophistiquées, et les besoins en protection numérique explosent. Pourtant, un paradoxe persiste : malgré la multiplication des formations et des annonces d’emploi, les postes peinent à trouver preneurs. On parle de milliers de places vacantes en Belgique et en Europe. Pourquoi ? Parce que trop souvent, les filtres de recrutement restent figés sur un modèle unique : diplômes académiques, parcours linéaires, expériences validées. Et si cette vision était trop étroite ? Et si la cybersécurité avait justement besoin de talents venus d’ailleurs, de profils autodidactes, atypiques, parfois inattendus ?

Quand la compétence dépasse le diplôme

Dans le monde numérique, ce ne sont pas toujours les diplômes qui font la différence, mais la curiosité, la passion et la capacité à apprendre vite. Combien de jeunes passionnés ont appris à sécuriser des systèmes en explorant par eux-mêmes, en contribuant à des forums spécialisés ou en participant à des compétitions de hacking éthique ? Combien d’autodidactes passent leurs soirées à décortiquer des lignes de code, à tester des scénarios d’attaque et à comprendre, par l’expérience, ce que d’autres mettent des années à théoriser ? Ces profils existent. Ils sont compétents. Mais trop souvent, on les écarte, faute de diplôme estampillé d’une grande école.

Réduire la cybersécurité à une liste de certifications, c’est passer à côté d’une ressource précieuse : la créativité. Un bon professionnel de la cybersécurité, ce n’est pas seulement quelqu’un qui connaît les normes, mais quelqu’un qui anticipe, qui improvise, qui sait se mettre dans la tête d’un attaquant pour mieux protéger. Et ces qualités se développent aussi bien dans un parcours académique que dans l’autodidaxie passionnée.

L’exemple britannique : transformer des trajectoires de vie

Le Royaume-Uni a montré qu’il est possible d’aller encore plus loin. Ces dernières années, plusieurs programmes pilotes ont été lancés dans les prisons pour former des détenus à la cybersécurité. L’idée peut surprendre, mais les résultats parlent d’eux-mêmes. Certains prisonniers, parfois condamnés pour des délits liés à l’informatique, avaient déjà des compétences impressionnantes. D’autres ont découvert dans la cybersécurité une véritable vocation. Encadrés, accompagnés, ces profils se révèlent motivés, rigoureux et extrêmement loyaux envers les entreprises qui leur donnent une chance.

Ce modèle est inspirant : il prouve que même dans les contextes les plus éloignés du marché du travail traditionnel, il est possible de révéler et de valoriser des compétences utiles à la société. Si l’on peut faire confiance à des personnes en réinsertion, pourquoi continuer à fermer la porte à des candidats “hors norme” qui, sans diplôme, ont pourtant les qualités nécessaires pour réussir ?

Une richesse pour les entreprises

Donner leur chance à ces profils atypiques n’est pas une option par défaut face à la pénurie : c’est une véritable opportunité. Ces talents apportent un regard neuf, une capacité d’adaptation et une créativité que l’on retrouve moins chez des profils formatés. Ils savent communiquer, vulgariser, ou gérer des situations inédites, parce qu’ils viennent d’autres horizons : enseignement, artisanat, armée, commerce, ou même parcours autodidacte pur.

Pour les entreprises, c’est un pari qui rapporte. Non seulement elles comblent un besoin critique, mais elles renforcent aussi leur culture interne. Ces collaborateurs, conscients de la chance qui leur est donnée, font souvent preuve d’une loyauté rare. Dans un secteur où la confiance et la résilience sont des valeurs cardinales, c’est un atout immense.

Ouvrir les portes, changer les regards

La pénurie de talents en cybersécurité ne sera pas résolue uniquement par les universités ou les certifications prestigieuses. Elle passera par un changement de mentalité : accepter que la compétence se prouve autrement que par un diplôme, créer des parcours de reconversion accessibles, valoriser l’expérience pratique et la passion. Dans une société plurielle, il est urgent de sortir du réflexe “diplôme à tout prix” et d’ouvrir d’autres chemins vers la réussite professionnelle.

Cela suppose aussi une évolution de l’éducation. Les compétences numériques et la sensibilisation à la cybersécurité devraient être présentes dès l’école primaire, pour donner le goût et les bases à tous les enfants. Mais cela ne doit pas se traduire par l’obligation d’un long parcours universitaire. Cinq ans sur les bancs d’une faculté ne sont pas le seul moyen d’accéder à ces métiers. Des formations plus courtes, plus pratiques et mieux intégrées dans le tissu économique doivent permettre à chacun de trouver sa place, qu’il soit étudiant, en reconversion ou autodidacte.

En ouvrant la cybersécurité à des talents atypiques, nous faisons plus que combler des postes. Nous renforçons la diversité, nous enrichissons la réflexion stratégique et nous offrons à des individus une vraie place dans la société numérique. La cybersécurité est un enjeu collectif : elle mérite que l’on mobilise toutes les énergies, y compris celles qui ne rentrent pas dans les cases traditionnelles.

by Axel Legay

Data centers souverains : un milliard pour l’avenir de la Belgique

La Belgique a récemment annoncé un projet ambitieux : investir un milliard d’euros dans la construction de data centers militaires afin de renforcer sa souveraineté numérique. Selon un article de la RTBF, ce plan, inscrit dans la loi de programmation militaire 2026-2029, représente une avancée stratégique majeure pour notre pays.

Certains y verront une dépense. En réalité, c’est un investissement vital pour l’avenir, non seulement de notre défense, mais aussi de notre autonomie stratégique et de notre sécurité collective.

1. Un outil de souveraineté, pas seulement de défense

Comme le rappelle la RTBF, ces infrastructures de pointe seront conçues pour gérer en temps réel les volumes massifs de données générées par drones, satellites ou systèmes d’armes modernes. Leur valeur ne réside pas uniquement dans la technologie, mais dans ce qu’elle garantit : l’indépendance et le contrôle de nos informations stratégiques.

Aujourd’hui, une grande partie des données publiques et privées transite par des géants étrangers. Cette dépendance comporte un double risque : d’une part, le cyberespionnage ou le sabotage ; d’autre part, le chantage géopolitique. Demain, un litige diplomatique pourrait suffire à couper l’accès à nos données critiques. Avec ses propres data centers militaires, la Belgique dit clairement : nos données, notre souveraineté.

2. L’autonomie stratégique au cœur du projet

Dans mes interventions, je défends régulièrement l’idée que l’Europe et la Belgique doivent assumer une ambition d’autonomie stratégique. L’exemple des data centers illustre parfaitement ce principe : accepter de dépendre d’acteurs étrangers pour nos infrastructures numériques essentielles reviendrait à déléguer une partie de notre sécurité nationale.

À l’heure où la guerre se joue aussi – et parfois surtout – dans le cyberespace, ne pas disposer de nos propres bastions numériques serait une faute historique. Ces data centers permettront à la Défense de réagir rapidement, de coordonner ses forces et de sécuriser ses communications en toute indépendance. Ils incarnent ce que devrait être la politique de sécurité d’un État moderne : protéger ses citoyens en maîtrisant ses infrastructures critiques.

3. Un investissement qui profite à toute la société

Si la Défense est la première bénéficiaire, la RTBF souligne que la mutualisation des ressources pourrait profiter à l’ensemble des services publics. Dans un pays où les hôpitaux, les administrations et les collectivités locales sont régulièrement ciblés par des cyberattaques, la mise en place d’infrastructures souveraines est une assurance-vie pour la continuité des services essentiels.

Cet investissement n’est donc pas réservé aux militaires : il constitue un patrimoine numérique national, garantissant la sécurité des citoyens et la stabilité de nos institutions.

4. Une réponse aux défis de demain

Les data centers militaires ne sont pas une réponse au monde d’hier, mais au monde de demain. Ils soutiendront l’utilisation de l’intelligence artificielle dans le champ de bataille, la coordination logistique en temps réel, la gestion de flottes de drones et satellites, ou encore l’analyse instantanée de données stratégiques.

En d’autres termes, ils donneront à la Belgique la capacité de rester maître de son destin dans un environnement international instable. Comme le souligne Alain De Neve, chercheur à l’Institut Royal de la Défense, ces infrastructures ne sont pas une option, mais un levier indispensable pour moderniser nos armées et renforcer leur efficacité opérationnelle.

Conclusion : assumer notre destin numérique

En investissant dans des data centers militaires souverains, la Belgique prend une décision visionnaire. Ce milliard n’est pas une dépense de confort, c’est une assurance d’indépendance, de sécurité et de résilience.

La souveraineté numérique n’est pas un slogan. C’est la condition pour que nos démocraties restent libres de leurs choix et que nos nations puissent protéger leurs citoyens dans un monde où la guerre de demain – et déjà celle d’aujourd’hui – est avant tout une guerre de l’information et des infrastructures.

La Belgique a raison de faire ce choix courageux. Reste maintenant à assumer pleinement cette ambition, à la défendre et à la porter comme un symbole fort : la souveraineté ne se délègue pas, elle se construit.

by Ragnar

La CNIL vient de publier 13 fiches pratiques pour aider les entreprises, administrations et développeurs à concevoir des systèmes d’IA respectueux des droits fondamentaux.

L’intelligence artificielle avance vite, mais la régulation aussi.
La CNIL vient de publier 13 fiches pratiques pour aider les entreprises, administrations et développeurs à concevoir des systèmes d’IA respectueux des droits fondamentaux.

👉 Ce n’est pas un simple avis d’expert, mais une boîte à outils très opérationnelle, couvrant :

L’intérêt légitime et la base juridique des traitements IA

L’analyse d’impact (AIPD)

Les biais et discriminations

La transparence, l’explicabilité

Les données d'entraînement

La minimisation et conservation des données

Les droits des personnes (accès, opposition, etc.)

Les cas d'usage concrets (RH, cybersécurité, détection de fraude…)

🔍 Objectif : traduire le RGPD dans la pratique IA, sans freiner l’innovation.

Un excellent guide pour préparer son IA Act-compliant et anticiper les audits à venir.

📘 Lien vers les 13 fiches : https://www.itforbusiness.fr/la-cnil-finalise-ses-recommandations-sur-lia-93029

by Axel Legay

Construire un mini pare-feu IA pour le navigateur avec JavaScript et l'API de GPT

Introduction : Pourquoi un pare-feu côté navigateur ?

Dans un monde où les interactions numériques se font majoritairement via des navigateurs web, la sécurité à ce niveau est cruciale. Or, la plupart des dispositifs de protection (pare-feu, antivirus, anti-spam) sont centrés sur le réseau ou le système. Ce que nous proposons ici est un concept simple mais prometteur : un pare-feu comportemental côté navigateur, à l’aide d’une API d’IA.

Notre projet est développé en JavaScript, le langage natif du navigateur. Plutôt que de réinventer la roue avec un moteur d’analyse complexe, nous tirons parti de la puissance d’un modèle d’intelligence artificielle existant (GPT-3.5). Cela permet de simplifier considérablement le développement tout en profitant des capacités avancées d’analyse contextuelle qu’offrent les IA modernes. Là où autrefois il aurait fallu écrire, maintenir et mettre à jour manuellement une série de règles (régulièrement périmées face à l'évolution des attaques), nous confions cette tâche à un moteur déjà entraîné sur des milliards d’exemples.

Objectif du projet

Construire un prototype de "mini pare-feu" IA embarqué dans le navigateur, capable de :

Intercepter les champs de formulaire
Détecter un contenu potentiellement suspect (tentatives de phishing, injections malveillantes, mots-clés dangereux)
Réagir immédiatement (alerte visuelle, blocage, etc.)

Nous utiliserons JavaScript pur et une API GPT (par exemple, OpenAI GPT-3.5) pour l’analyse contextuelle du contenu.

Rappel : qu’est-ce qu’un pare-feu ?

Un pare-feu ("firewall") est un outil qui filtre les communications entrantes et sortantes d’un système informatique. Il agit comme un "vigile" qui bloque ou autorise certaines données selon des règles. Ici, notre pare-feu est adapté au contexte : il ne filtre pas le réseau, mais l’interaction utilisateur-application.

Traditionnellement, un pare-feu repose sur une liste de règles fixes qu’il faut mettre à jour en fonction des nouvelles menaces. L’un des avantages de notre solution basée sur une IA existante est qu’elle remplace ces règles rigides par une interprétation intelligente, adaptable et évolutive.

Prototype simple en JavaScript + API GPT : découpage et explication pédagogique

1. Sélection et écoute des champs de saisie


document.querySelectorAll('input, textarea').forEach(el => {
  el.addEventListener('blur', async () => {
    const flag = await analyseAvecIA(el.value);
    if (flag) {
      el.style.border = '2px solid red';
      alert("⚠️ Contenu potentiellement dangereux détecté.");
    }
  });
});

Explication :
- On sélectionne tous les éléments de type input et textarea.
- Lorsqu’un utilisateur quitte un champ (blur), on déclenche une analyse.
- Si le contenu est jugé dangereux par l’IA, on colore le champ en rouge et on affiche une alerte.

2. Fonction d’analyse avec GPT


async function analyseAvecIA(texte) {
  const response = await fetch("https://api.openai.com/v1/chat/completions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": "Bearer VOTRE_CLE_API"
    },
    body: JSON.stringify({
      model: "gpt-3.5-turbo",
      messages: [
        { role: "system", content: "Ta tâche est de déterminer si un contenu est une tentative de phishing ou contient une injection malveillante." },
        { role: "user", content: texte }
      ]
    })
  });
  const data = await response.json();
  return data.choices[0].message.content.toLowerCase().includes("oui");
}

Explication :
- On appelle l’API GPT d’OpenAI en lui envoyant deux messages :
• Un prompt système qui définit le rôle de l’IA : détecter le phishing ou l’injection.
• Le contenu réel saisi par l’utilisateur.
- On interprète la réponse : si elle contient oui, on considère que le contenu est suspect.

Remarques de sécurité :
- Il faut remplacer VOTRE_CLE_API par votre vraie clé OpenAI.
- Ne jamais exposer une clé sensible en production côté client (voir plus loin les limitations).

Limitations du prototype

Temps de réponse dû à l'appel API (latence perceptible)
Risque de faux positifs ou négatifs selon la formulation du prompt
Le code étant exécuté côté client, il peut être désactivé ou contourné
Exposer une clé API en clair dans le navigateur est dangereux (solution : proxy sécurisé ou back-end intermédiaire)

Pistes d'amélioration

Utiliser un modèle IA local exécuté dans le navigateur (WebLLM, Mistral via WebGPU, etc.)
Créer une extension navigateur pour une meilleure intégration
Ajouter un historique local ou un apprentissage progressif des comportements fréquents

Conclusion

Ce projet montre qu’avec un peu de JavaScript et une API d’IA, il est possible d’implanter une couche supplémentaire de réflexion et d’analyse dans le navigateur lui-même. Ce n’est pas une solution de sécurité totale, mais une preuve de concept qui ouvre la voie à une sécurité plus fine, contextuelle et proactive. Idéal pour l’expérimentation, la pédagogie, ou comme base pour un projet plus ambitieux. Et surtout, il illustre à quel point les IA modernes permettent aujourd’hui de créer en quelques lignes ce qui aurait autrefois nécessité des centaines de règles manuelles, mises à jour et surveillées en permanence.

by Axel Legay

Analyse de faille avec Nikto : exploitation et protection contre Shellshock via CGI

Introduction : pourquoi analyser les failles ?

Dans le monde de la cybersécurité, l’analyse de faille est un processus indispensable. Elle permet d’identifier et corriger les vulnérabilités avant qu’elles ne soient exploitées. Un attaquant n’a besoin que d’un seul point faible : à nous de le détecter avant lui.

Dans cet article, nous allons nous intéresser à une faille emblématique : Shellshock (CVE-2014-6271), qui a touché Bash en 2014. Nous verrons comment utiliser Nikto, un scanner de vulnérabilités web, pour la détecter, comment l’exploiter manuellement, et surtout comment s’en prémunir. Pour cela, il est essentiel de comprendre le rôle joué par CGI (Common Gateway Interface) dans l’exploitation.

🧠 CGI : le chaînon faible de Shellshock

Qu’est-ce que CGI ?

CGI (Common Gateway Interface) est une spécification permettant à un serveur web d’exécuter des programmes externes – appelés scripts CGI – pour générer dynamiquement des réponses HTTP. Ces scripts peuvent être écrits en Bash, Perl, Python, etc., et sont souvent utilisés dans des environnements anciens ou embarqués.

Fonctionnement général

Lorsqu’un utilisateur accède à un script CGI via le web :

Le serveur (ex. Apache) exécute le script comme processus système.
Il lui transmet les en-têtes HTTP sous forme de variables d’environnement (ex : User-Agent, Host, etc.).
Le corps de la requête est envoyé via stdin.
Le résultat du script est retourné au client comme une réponse HTTP.

C’est précisément le passage des variables d’environnement qui rend Shellshock si dangereuse dans ce contexte.

📜 Exemple de script CGI Bash vulnérable

Décryptage du script :

#!/bin/bash : indique que le script sera interprété par Bash.
echo "Content-type: text/plain" : définit le type MIME de la réponse HTTP.
echo : une ligne vide obligatoire après les en-têtes HTTP.
echo "Hello, world!" : le corps de la réponse, affiché dans le navigateur.

Ce script peut être appelé par un navigateur à l’adresse :
http://vulnerable-site.com/cgi-bin/test.sh

🐚 Shellshock (CVE-2014-6271) : la faille

La vulnérabilité Shellshock réside dans le fait que Bash exécute du codecontenu dans les définitions de fonctions transmises via des variables d’environnement. C’est un comportement inattendu et dangereux.

Une requête HTTP malicieuse :

entraînera l’exécution de la commande "echo shellshock exploited" sur le serveur, sans vérification ni contrôle.

🔎 Détection avec Nikto

Nikto est un scanner open source de vulnérabilités web. Il teste des milliers de failles connues sur des serveurs HTTP. L’une de ses forces est sa capacité à détecter automatiquement des scripts CGI vulnérables à Shellshock.

Explication des options principales :

-h : hôte ou URL cible
-Tuning x : active tous les types de tests (CGI, injection, XSS…)
-output fichier.txt : exporte les résultats
-evasion : tente de contourner des filtres ou WAF simples
-Display V : n’affiche que les vulnérabilités confirmées

🧪 Exploitation manuelle de Shellshock

Un simple test curl peut suffire à démontrer une faille :

⚙️ Fonctionnement des variables CGI

Les scripts CGI récupèrent les données HTTP via des variables d’environnement, par exemple :

REQUEST_METHOD (GET, POST…)
HTTP_USER_AGENT, HTTP_COOKIE, etc.
REMOTE_ADDR, SERVER_NAME…

Shellshock tire parti de ce mécanisme pour injecter des fonctions Bash contenant du code dans des en-têtes comme User-Agent.

🔐 Contre-mesures : comment se protéger

✅ 1. Mettre à jour Bash

La mise à jour de Bash corrige le comportement fondamental à l’origine de Shellshock : les versions vulnérables traitaient automatiquement certaines définitions de fonction comme du code à exécuter.

Une version corrigée ignore ou désactive totalement ce comportement.

⚠️ Sans cette mise à jour, aucune autre mesure ne suffit : même avec un WAF ou une surveillance, la faille peut toujours être exploitée.

✅ 2. Désactiver les CGI inutiles

Définition : un script CGI est "inutile" dès lors qu’il ne sert plus à une fonctionnalité en production. Cela inclut :

Des scripts de test (test.sh, env.cgi)
Des scripts hérités de vieilles applications
Des démonstrations installées par défaut (souvent oubliées)

Ces scripts peuvent rester accessibles sans être visibles, et sont très fréquemment ciblés automatiquement par les attaquants.

✅ 3. Filtrage HTTP avec un WAF (Web Application Firewall)

Un WAF agit comme une barrière entre l’utilisateur et le serveur. Il inspecte chaque requête HTTP à la recherche de motifs suspects. Dans le cas de Shellshock, cela signifie bloquer les en-têtes qui contiennent des définitions de fonction suspectes dans des champs comme User-Agent.

Exemple de règle ModSecurity :

Cette règle détecte les chaînes qui ressemblent à une déclaration de fonction Bash suivie d’une commande.
Elle agit avant que le script CGI ne soit exécuté, ce qui est crucial en environnement vulnérable.

💡 Bien que les WAF ne soient pas infaillibles, ils sont efficaces contre des attaques automatiques ou basiques.

✅ 4. Surveillance active avec IDS

Un IDS (Intrusion Detection System) complète la défense en détectant les tentatives suspectes et en générant des alertes.

Exemples d’IDS compatibles :

OSSEC : centralisé, léger, facile à intégrer à des logs Apache.
Snort : puissant, très utilisé, signatures personnalisables.
Suricata : similaire à Snort mais multithreadé.

Exemple de règle Snort (simplifiée) :

Grâce à ces outils, même si une faille est présente, vous saurez en temps réelqu’une attaque a été tentée, et pourrez réagir (blocage d’IP, audit, etc.).

🔧 Déploiement local d’un script CGI pour test

Fichier /usr/lib/cgi-bin/test.sh :

Accès :
http://localhost/cgi-bin/test.sh

Conclusion

Shellshock n’est pas une faille anecdotique. Elle a montré comment un simple en-tête HTTP peut suffire à prendre le contrôle d’un serveur mal configuré. Les scripts CGI, souvent oubliés ou laissés en place par habitude, sont des portes ouvertes.

Ce qu’il faut retenir :

Nikto permet de détecter ces failles rapidement.
La mise à jour de Bash est obligatoire : elle corrige le comportement vulnérable.
Les CGI non utilisés doivent être désactivés.

by Axel Legay