Vue d'ensemble

NeonFlare Community Edition est un dashboard de sécurité self-hosted et gratuit qui réunit trois besoins habituellement éclatés entre plusieurs outils : la surveillance de ton réseau, une référence d'outils pentest avec terminaux embarqués, et un suivi GRC (Gouvernance, Risques & Conformité). C'est un site statique -- aucune base de données, aucun backend applicatif. Toute ta configuration (nœuds réseau, outils, checklist GRC, préférences) vit dans le localStorage de ton navigateur.

Premiers pas

Au tout premier lancement, un assistant guidé se déclenche automatiquement et pointe directement les sections réelles du Dashboard (Réseau, Outils, GRC), puis la page Settings où tout se configure. Chaque étape est passable, et l'assistant reste accessible à tout moment depuis Settings → Assistant de configuration → Relancer l'assistant de configuration.

La configuration démarre volontairement avec des exemples/valeurs par défaut (une checklist GRC ISO 27001 / NIST CSF déjà remplie, par exemple) plutôt qu'un dashboard totalement vide -- tu supprimes ou remplaces ce qui ne te correspond pas depuis Settings.

Le Dashboard

La page centrale est composée de panneaux indépendants, redimensionnables et déplaçables (glisser l'en-tête d'un panneau, ou sa poignée en bas à droite) :

• Réseau -- les nœuds de ton infrastructure (au départ : NeonFlare.ca, le GitHub GothamBlood et GothamTech.ca) ; la jauge « NODES ONLINE » de l’en-tête ne s’affiche que sur les dashboards qui montrent ce panneau
• Explorateur -- gestionnaire de fichiers piloté depuis un shell (bash/zsh/PowerShell), presets SUID/SGID/capabilities/cron/sudo -l -- masqué par défaut
• Outils -- référence de commandes pentest par catégorie
• DevSecOps -- même principe qu'Outils, mais pour les CLI cloud/infra (Docker, Kubernetes, Terraform, AWS, Azure)
• Website -- tes liens/services web par catégorie
• Couverture GRC -- résumé de ta progression sur les 64 pages de checklist, section par section
• System log -- journal d'activité
• Shells -- terminaux embarqués ouverts à la demande
• Prochaines revues -- dates de revue tirées des registres Actifs/Risques, en retard signalé

Chaque panneau peut être replié (bouton – dans son en-tête) ou masqué entièrement -- soit depuis Paramètres, soit directement dans le Dashboard via le bouton ☰ Panneaux de la barre du haut (mêmes cases à cocher, appliquées tout de suite, sans changer de page). La disposition (position/taille, glisser l'en-tête ou la poignée en bas à droite d'un panneau) est mémorisée par dashboard.

Réseau

Le panneau Réseau affiche les nœuds que tu as déclarés : titre, sous-titre, catégorie, icône, lien direct. Au départ il contient quelques nœuds d’exemple (NeonFlare.ca, le GitHub GothamBlood, GothamTech.ca) -- remplace-les par les tiens depuis Settings → Config Network (ajout, édition, suppression, import/export JSON, réinitialisation aux valeurs par défaut).

Outils & Terminaux

Fini les cheatsheets planqués dans un fichier .txt.

Le panneau Outils regroupe des catégories de commandes (recon, exploitation, post-exploitation, etc.). Cliquer une commande la copie directement dans un terminal embarqué (bash, zsh ou PowerShell selon ce que tu ouvres) -- pas de copier/coller manuel entre fenêtres. Avec le bouton 🔗 Link de la barre du Dashboard, une commande choisie ici peut même atterrir dans le terminal d'un autre onglet du navigateur (utile avec deux dashboards ouverts côte à côte).

Terminaux embarqués

Ouverts via le bouton "+ Shell" du Dashboard, ils restent actifs même en changeant de page dans la sidebar (ils ne sont pas détruits à chaque navigation). Les fenêtres de terminal sont à 75 % d'opacité par défaut (le fond transparaît derrière) ; cela se règle depuis Settings → Shells.

Explorateur de fichiers

Le panneau Explorateur (masqué par défaut, à activer depuis ☰ Panneaux ou Paramètres) est un gestionnaire de fichiers visuel piloté à travers un terminal déjà ouvert dans le panneau Shells -- local ou reverse shell attrapé pendant un engagement, le module ne fait pas la différence. Il ne se connecte à rien de nouveau : il attache une connexion WebSocket courte à la même session tmux que le terminal affiché, envoie les commandes, et relit le résultat. Tant que son panneau n'est pas visible (masqué sur le tableau courant, ou replié), il reste inactif : aucune sonde, rien n'est tapé dans les shells -- il démarre dès qu'on l'affiche.

Navigation

• Sélecteur de pane (bash / zsh / PowerShell) et détection automatique de l'OS de la cible
• Listing avec fil d'Ariane, permissions, taille, propriétaire, date -- fichiers cachés affichables d'un clic
• Aperçu de fichier texte par palier de taille, sans jamais rapatrier un gros fichier en un coup
• Favoris persistants par navigateur, et un Journal des commandes non-masquable -- chaque commande exécutée reste visible avec sa sortie

Presets post-exploitation

Une liste de scans classiques en un clic : binaires SUID/SGID, capabilities, dossiers world-writable, cron, sudo -l, id/groupes, recherche de flags -- chacun tourne en arrière-plan sur la cible et remonte ses résultats dans le panneau.

Reverse shells & énumération en un clic

NeonFlare gère la boucle complète d'un reverse shell sans quitter le tableau. Dans un terminal embarqué tu lances ton écouteur (par ex. nc -lnvp 4444), dans un autre tu déclenches le payload (dépôt web, curl, ou une commande collée depuis les Outils), et le shell retombe directement dans un pane tmux -- persistant et réattachable, côte à côte avec tes notes et tes Findings. Pas de va-et-vient entre plusieurs fenêtres : déclenchement, capture et suite de l'exploitation se font au même endroit.

Côté post-exploitation, l'Explorateur offre une barre de presets d'énumération en un clic qui tournent sur la cible et remontent leurs résultats classés dans le panneau : binaires SUID / SGID, capabilities, dossiers world-writable, cron, sudo -l, id/groupes et recherche de flags (user/root/flag.txt). De quoi repérer un vecteur d'élévation de privilèges en quelques secondes, sans retaper les commandes.

GRC (Gouvernance, Risques & Conformité)

Des pages de checklist organisées en 6 sections : les 15 domaines de gestion ISO 27001 en GRC générale (contexte organisationnel, gouvernance, gestion des actifs, analyse des risques, traitement des risques, contrôles de sécurité, politiques et directives, procédures opérationnelles, gestion des incidents, continuité des activités — un registre unique de plans où chaque plan porte un type (taxonomie de 14 types : PUI, PCA, PGC, PCO, PSI, PCC, PRH, PRL, PLOG, PDEP, PRII, PRI, DRP, PRA), avec fiche et checklist de référence par type dans le registre, la page étant une seule rangée d'onglets dans l'ordre de la démarche : BIA (un registre par processus), analyse de risques PCA, ressources critiques, stratégies, Faire un plan, Tests & exercices, formation, amélioration continue, synthèse des plans —, gestion documentaire, gestion de la conformité, gestion des fournisseurs, protection des renseignements personnels, performance et indicateurs GRC), puis la sécurité réseau, API, WebApp, base de données et la Sécurité opérationnelle (7 domaines de mesures : architecture, vulnérabilités, IAM, ressources humaines et sensibilisation, sécurité physique, cloud, DevSecOps). Chaque page a sa propre checklist, pré-remplie avec un référentiel ISO 27001 / ISO 22301 / NIST CSF / CIS par défaut.

Organisation des sections et migration

Le hub GRC suit la liste des 15 domaines de gestion ISO 27001 ; la Gestion de la conformité et la Protection des renseignements personnels (Loi 25) y ont chacune leur page. Les domaines de mesures -- architecture de sécurité, vulnérabilités, IAM, ressources humaines et sensibilisation, sécurité physique, cloud et DevSecOps -- sont dans la section Sécurité opérationnelle. Chaque item de checklist porte un identifiant stable : ajouter ou réordonner des items ne décale plus les cases cochées, et l'état déjà coché des pages déplacées ou fusionnées -- comme celui des sauvegardes JSON antérieures -- est migré automatiquement, sans perte. Les anciennes adresses redirigent vers les nouvelles pages.

Export & suivi

• Export JSON du hub = sauvegarde GRC complète (checklist + tous les registres : actifs, risques, incidents, fournisseurs, contrôles, conformité, continuité, indicateurs, documents, vie privée, plans de traitement, revues d'accès, pentest, fiches, DDA) ; Word / PDF restent des rapports -- sur un domaine ou sur l'ensemble
• Import JSON pour restaurer une sauvegarde complète (checklist + registres) ; les anciens fichiers checklist-seule restent lisibles
• Barres de progression et badges de couverture par domaine (activables/désactivables depuis Settings)
• Réinitialisation complète si besoin de repartir de zéro

Registres opérationnels

Trois des domaines GRC vont au-delà de la checklist d'auto-évaluation et offrent un vrai registre CRUD, en plus de la checklist :

• Documentation de l'organisation (les 15 pages du hub GRC) -- un onglet par élément de la page (un seul affiché à la fois, compteur d'entrées, Précédent / Suivant), chacun avec une explication et un exemple pour guider un débutant. Quatre types d'onglets : un formulaire à saisie multiple aux champs prédéfinis (énoncés de mission et vision, parties prenantes, comités, appétit au risque, articles de politique, étapes de procédure, playbooks d'incident, SLA…) ; le registre existant de la page rangé dans son onglet (actifs, risques, plans de traitement, contrôles, incidents et espace IR, PCA/PRA, documents, conformité, vie privée, fournisseurs, indicateurs -- données et exports inchangés) ; une vue en lecture seule d'un registre (propriétaires, matrice P × I et cartographie, plans par stratégie, risque résiduel et ROSI, DDA avec justification, contrôles par référentiel et par type, matrice risques ↔ contrôles, obligations par norme, audits, écarts, consentements, EFVP, conservation, clauses et dépendances fournisseurs, KPI / KRI / tableau RAG) ; ou un renvoi vers l'endroit où l'élément est documenté. Les champs peuvent pointer vers d'autres registres (contrôles, fournisseurs, incidents, processus, objectifs du SGSI) ; chaque champ de lien porte un bouton « + Ajouter » qui, si la cible n'existe pas encore, ouvre la page concernée dans un nouvel onglet avec son formulaire d'ajout déjà ouvert -- l'élément créé devient sélectionnable au retour, sans quitter le formulaire en cours. Environ 110 champs texte proposent des listes de suggestions (autocomplétion : fréquences, délais, durées de conservation, canaux, classification, publics, rôles standard et rôles saisis en Gouvernance, actifs, fournisseurs…) tout en acceptant le texte libre -- une liste déroulante intégrée (▾, même rendu dans tous les navigateurs) montre toute la liste au clic, même quand le champ est déjà rempli, filtre à la frappe et se pilote au clavier ; les champs obligatoires sont marqués d'un * et un champ vide montre un exemple en gris italique (« ex. … ») ; chaque date (GRC et Paramètres) a un calendrier aux couleurs du thème (FR/EN, utilisable au clavier), la saisie reste possible (AAAA-MM-JJ ou JJ/MM/AAAA, normalisée) et une date invalide est refusée avec un message ; un terme standard est enregistré sous forme de code et affiché dans la langue du site (FR/EN). Export Word/PDF du document de la page, export/import JSON ; chiffré par le coffre (un seul écran de déverrouillage par page) et inclus dans la sauvegarde complète. La checklist de chaque page reste à part et ne sert qu'au suivi d'avancement
• Chaîne GRC -- les sections dépendent les unes des autres : les formulaires des registres proposent des sélecteurs de liens (actif ↔ processus / fournisseurs / portée, risque ↔ actifs / enjeux / menaces / sources / scénario, plan ↔ contrôles et risques traités, contrôle ↔ risques / obligations / Annexe A, incident, obligation, document, indicateur, plan de continuité ↔ processus couvert et BIA lié, BIA ↔ processus analysé / dépendances / ressources) et chaque entrée affiche « dépend de / utilisé par ». Supprimer un élément utilisé ailleurs avertit d'abord, un import signale les liens orphelins, et modifier une entrée marque tout ce qui en dépend « à revoir ». Le panneau Chaîne du hub liste 23 règles de rupture (enjeu prioritaire sans risque, risque à traiter sans plan, contrôle applicable de l'Annexe A sans mise en œuvre, processus vital sans plan de continuité ou sans BIA…) avec réparation en un clic (formulaire cible pré-rempli et relié).
• Déclaration d'applicabilité (DDA) (page Contrôles) -- les 93 contrôles de l'Annexe A d'ISO/IEC 27001:2022 (libellés reformulés + référence, jamais le texte de la norme) : applicable ou exclu (exclusion justifiée obligatoire), raison, état de mise en œuvre, contrôles du registre qui le mettent en œuvre, rapprochement automatique depuis les références ISO existantes ; onglet Attributs (ISO/IEC 27002, indicatifs) avec filtres ; export Word / PDF / CSV.
• Parcours débutant -- une page Démarrer ici (les 15 étapes dans l'ordre de la chaîne avec prérequis, participants et durée indicative ; un diagnostic de départ dont les réponses sont proposées dans le Contexte ; les documents exigés par ISO 27001 et ISO 22301 avec un état calculé et l'endroit où les documenter ; une organisation exemple fictive FSociety, sans rupture, retirable ; des modèles de départ par profil), deux nouveaux domaines dans Sécurité opérationnelle (Ressources humaines et sensibilisation, ISO 27001 A.6, et Sécurité physique, A.7), des onglets « essentiels » d'abord avec « Afficher tout », « Partir de l'exemple » sur chaque formulaire, un statut du document par page (brouillon → en revue → approuvé, repasse « en révision » à toute modification), la checklist reliée à ses onglets, « Étape suivante » d'une page à l'autre, des actions croisées (ex. enjeu → créer un risque), un panneau À faire (hub et tableau de bord) et une recherche globale.
• Compléments ISO 27001 / 27005 / 22301 -- modifications du système (27001 6.3), ressources du SGSI, un registre unique d'amélioration et d'actions correctives (les autres pages en affichent des vues filtrées ; les actions de Continuité existantes y sont reprises sans perte), une revue de direction structurée avec « Préparer automatiquement », un programme d'audit interne, sources de risque, scénarios, opportunités, échelles de cotation, concertation et veille sur les menaces, un BIA dans le temps (impacts par horizon, ressources, DMIA suggérée), une documentation par plan dans le registre (onglet Fiche par type : politique et objectifs, arbre d'appel, main courante, messages types, ordre de rétablissement…), les capacités de continuité des fournisseurs, la sécurité dans les projets, et une documentation légère reliée sur les 38 pages des hubs techniques.
• Limites -- les approbations sont déclaratives (aucune signature vérifiée), l'application est locale et sans serveur, et les bilans (documents exigés, avancement) sont indicatifs : ils aident à préparer un audit, ils ne le remplacent pas.
• Registre d'actifs (page Actifs) -- type, classification CIA (confidentialité/intégrité/disponibilité), rôle primaire/support, dépendances entre actifs, criticité calculée automatiquement, valeur monétaire (AV) avec devise, reprise par le volet quantitatif des risques
• Registre de risques (page Analyse des risques) -- menace/vulnérabilité, actifs concernés, matrice probabilité × impact (ISO 27005), plan de traitement, date de prochaine revue ; volet quantitatif optionnel : SLE = AV × EF, ARO (avec la périodicité « 1 fois tous les N ans ») et ALE = SLE × ARO calculés, AV reprise automatiquement des actifs liés, ALE total en synthèse et colonnes SLE / ARO / ALE dans le rapport
• Journal d'incidents (page Incidents) -- sévérité, timeline détection → réponse → résolution, durée calculée, post-mortem ; chaque incident s'ouvre en espace de réponse à incident (timeline interactive, notes / hypothèses / IOC d'investigation, kanban de tâches, export du dossier en JSON + Word/PDF + liste d'IOC)
• Page Continuité en une seule rangée d'onglets, dans l'ordre de la démarche -- BIA · analyse de risques PCA · ressources critiques · stratégies · Faire un plan · Tests & exercices · formation · amélioration continue · synthèse des plans (liens et ancres ouvrent le bon onglet). L'onglet Tests & exercices se saisit : programme d'exercices (planifiés, reliés au plan testé) et rapports d'exercice (type : TTX, simulation de crise, restauration, bascule, évacuation, complet ; scénario, participants, RTO observé, résultat, écarts, actions ouvertes dans le registre d'amélioration). C'est la source unique des exercices : l'onglet Tests d'un plan affiche ses rapports (les anciens tests par plan y ont été recopiés) et « Consigner un exercice » ouvre le formulaire pré-rempli. S'y ajoutent les Sauvegardes (3-2-1) (complète / différentielle / incrémentale / réplication, copies, supports, hors site, copie immuable, dernier test de restauration, RPO atteint), les stratégies de site de relève chaud / tiède / froid, actif-actif / actif-passif et réplication synchrone / asynchrone, les niveaux d'alerte de la fiche PGC (pré-alerte, mineur, majeur, crise, avec ce qui se déclenche) et une matrice RACI en Gouvernance (un seul A par décision, rôles reliés). La page Continuité compte aussi : Disponibilité (MTBF / MTTR) par chaîne de service (série = produit des disponibilités, parallèle = 1 − produit des indisponibilités, indisponibilité par an, alerte sous la cible), Dépendances techniques (agent déployé partout, service externe critique, fournisseur ou compétence unique, cascade, téléphonie, multifonction, BYOD, avec la question de continuité et le mode dégradé) et Outils de crise (cartelette, annuaire de crise, trousse papier / hors ligne / matériel, emplacement hors salle serveurs, vérification) ; les stratégies notent construire ou acheter, le coût complet (acquisition, exploitation, compétence, tests, sortie) et le RTO garanti ; l'onglet Faire un plan propose « Choisir le bon plan en quatre questions » ; Analyse de risques ajoute le nœud papillon (dessin causes → prévention → événement → limitation → conséquences) et Directives une politique BYOD. Les scénarios de l'analyse de risques PCA suivent les types de menaces (dommage physique, catastrophe naturelle, perte de services essentiels, compromission d'informations, défaillance technique, actions non autorisées) et les fiches citent ISO 22313, 22316, 22320, 22398, 27031 et 31000. Registre unique de plans : chaque plan porte un type (taxonomie de 14 types groupés par niveau et catégorie : PUI, PCA, PGC, PCO, PSI, PCC, PRH, PRL, PLOG, PDEP, PRII, PRI, DRP, PRA ; le registre est regroupé et trié par catégorie), avec bilan d'impact (DMIA, MAO, RTO, RPO et MBCO, règles de cohérence RTO ≤ MAO ≤ DMIA et RPO ≤ RTO), dépendances avec marquage SPOF, SPOC et cellule de crise décisionnelle (CCD) par plan, redondance, procédure de reprise ordonnée, journal de tests (dont les exercices sur table TTX), export du dossier complet et fiche de reprise 1 page. À l'ouverture d'un plan, deux onglets Fiche et Checklist affichent la documentation et la checklist de référence partagées par type. Registre BIA par processus, indépendant des plans : chaque entrée est un processus de la cartographie avec sa criticité, DMIA / MAO / RTO / RPO / MBCO et alertes de cohérence, impacts dans le temps (1 à 5 par nature — financier, opérationnel, réputation, réglementaire, humain — et par horizon, DMIA suggérée appliquée sur demande), justification des chiffres, ressources nécessaires dans le temps et dépendances métier (actif, application, données, service, fournisseur, site, personne-clé) avec leur raison et marquage SPOF ; registre groupé par criticité, synthèse (SPOF, objectifs incohérents, pires écarts RTO–DMIA), couverture des processus vitaux / critiques et exports Word / PDF / JSON. Un plan se relie au BIA de son processus (champ BIA lié, présélectionné d'après le processus) : il en affiche les objectifs, signale un RTO / RPO du plan plus long et peut les reprendre en un clic. Les checklists par type, le BIA et les Tests & exercices sont comptés dans la couverture du domaine (les anciennes sous-pages de plans redirigent vers le registre).
• Registre des fournisseurs (page Fournisseurs) -- évaluation du risque tiers (score probabilité × impact), clauses contractuelles avec alerte de fin de contrat, suivi des certifications (ISO 27001 / SOC 2 / …) avec badges d'expiration, checklist d'onboarding/offboarding et revue périodique, liens vers les incidents, exports rapport / fiche 1 page / CSV du registre
• Suivi des vulnérabilités (Sécurité opérationnelle › Vulnérabilités) -- cycle de vie de bout en bout, sévérité et échéance SLA déduites du score CVSS, alerte SLA dépassé, timeline des changements d'état, liens actifs / incident / risque, bloc d'acceptation du risque avec alerte d'expiration, rapport Word/PDF trié par sévérité et export CSV du registre
• Registre vie privée (page Protection des renseignements personnels, Loi 25) -- un registre des traitements (ROPA) : base légale, catégories de données structurées (sensibilité/volume/source), transferts hors province/pays avec alerte de garantie manquante, durée de conservation (+ méthode de destruction et date de suppression prévue) avec alerte d'échéance, un registre de consentements (type, obtention/expiration/retrait, preuve), des liens destinataires vers le registre des fournisseurs, un score DPIA (sensibilité × volume × exposition) avec workflow d'approbation formelle (brouillon/en cours/approuvée) et alerte, revue périodique -- un journal des demandes des personnes avec échéance légale automatique (30 j) et alerte de retard -- et un registre des bris de confidentialité (personnes touchées, gravité, notification CAI et personnes avisées avec alerte, mesures correctives, liens traitements/incident). Le registre des actifs peut signaler qu'un actif contient des RP et le lier à ses traitements ; les Paramètres portent une fiche RPRP (nom, coordonnées, délégué, date de nomination). Exports ROPA Word/CSV, journal DSR CSV, registre des bris Word/CSV et accusé + réponse en une page
• Registre de conformité (page Gestion de la conformité) -- des obligations (loi / norme / contrat) avec indicateur d'applicabilité (DDA), un statut de conformité et une évaluation périodique avec alerte de retard, plus des audits qui portent leurs constats -- chacun une non-conformité avec gravité, action corrective (alerte de retard) et statut de vérification ; taux de conformité en synthèse, exports DDA Word/CSV, rapport de conformité et rapport par audit
• Recertification des accès (Sécurité opérationnelle › IAM) -- des campagnes de revue avec une décision garder / révoquer / réduire par ligne, un ajout en masse par coller-parser, une barre de progression, une alerte d'échéance dépassée et un sign-off qui exige que toutes les lignes soient décidées puis les verrouille (ré-ouverture historisée), plus un journal des mouvements (arrivée / mobilité / départ) avec alerte « départ non déprovisionné depuis plus de 7 jours » ; exports rapport de campagne et lignes CSV
• Registre d'indicateurs (page Indicateurs) -- des KPI / KRI avec cible, seuils ambre / rouge et sens (« plus haut = mieux » ou l'inverse), une série de mesures tracée en sparkline SVG maison (ligne de cible + bandes de seuils), un statut RAG (vert / ambre / rouge), une tendance vs la mesure précédente et une alerte « mesure en retard » ; la synthèse est un mini tableau de bord RAG, plus exports rapport périodique, CSV définitions, CSV séries et JSON
• Plan de traitement des risques (page Traitement des risques) -- registre autonome et partageable de plans de traitement (grc-treatment-plans.js) : une stratégie (éviter / atténuer / transférer / accepter) avec justification, un plan d'action ordonné avec responsables et échéances (alerte de retard), et des contrôles liés. Relation many-to-many avec le registre de risques (page Analyse des risques) : un même plan peut couvrir plusieurs risques à la fois (ex. un déploiement MFA), et un risque peut cumuler plusieurs plans (ex. MFA + segmentation réseau) -- créer un plan à la volée ou en lier un existant depuis la fiche du risque, autant de fois que nécessaire. Le score résiduel (probabilité × impact, réduction inhérent → résiduel) et le bloc d'acceptation (exigé si la stratégie liée est « accepter » ou si le résiduel est non nul, avec alerte de revue à échéance) restent propres à chaque risque même si le plan est partagé. Les risques avec un ancien plan embarqué sont migrés automatiquement vers le registre partagé au premier chargement, sans perte ; une synthèse de traitement au-dessus du registre des risques et un export CSV du registre de plans. Côté quantitatif, l'EF et l'ARO après contrôles et le coût annuel des contrôles donnent l'ALE résiduel, la réduction d'ALE (risque résiduel = risque initial − réduction apportée par les mesures) et le ROSI, avec une alerte si l'ALE résiduel dépasse l'ALE initial
• Registre documentaire (partagé par les pages Procédures / Directives / Gestion documentaire / Gouvernance -- un seul registre, chaque page filtrée par type de document) -- cycle de vie éditorial (brouillon → en revue → approuvé → publié → en révision → retiré), une version libre avec un bouton « nouvelle version » qui l'incrémente et ajoute une entrée au journal de versions, un approbateur (qui alimente le registre d'autorité), une revue périodique avec alerte de retard, une alerte « brouillon jamais approuvé depuis plus de 90 jours », les contrôles couverts et les liens entre documents ; la page Gouvernance affiche en plus une table d'autorité en lecture seule (document → approbateur), plus exports sommaire Word/CSV, registre d'autorité CSV et JSON
• Ressources externes (catégorie More du panneau Website du dashboard « GRC & Website » ; elles ne sont plus dans le menu GRC) -- une sélection de références tierces pour appuyer vos politiques et vos contrats fournisseurs (modèles SANS, clauses fournisseurs Aspen Tech Policy Hub / Law Insider, exemples de contrats de rétention pour la réponse aux incidents Mandiant / Trustwave), plus des sources officielles pour la Loi 25 du Québec (texte de loi sur Légis Québec, guides de la CAI, formulaire de déclaration d'un incident de confidentialité) et les portails officiels des principaux référentiels de sécurité (ISO -- technologies de l'information, NIST Cybersecurity Framework, CIS Controls v8) , liens vers des sites tiers, sans valeur d'avis juridique
• Mapping de contrôles -- une partie des items de checklist portent un tag ISO 27001 Annexe A / NIST CSF 2.0 / CIS Controls v8, pour relier une case cochée à un contrôle précis d'un référentiel

Findings

Distinct du panneau Outils (aide-mémoire de commandes) : un vrai tracker de findings pour une mission de test d'intrusion, accessible depuis le menu Findings (juste sous Tableau de bord, dans la sidebar).

• Engagements -- nom, client, scope, dates, statut ; historique de plusieurs missions
• Findings -- titre, description, score CVSS (badge de sévérité Faible/Moyenne/Élevée/Critique), preuves en texte libre, statut ouvert/corrigé/accepté
• Preuves en texte, plus une référence d'image optionnelle par finding (chemin ou fichier réattaché -- voir la note ci-dessous)
• Génération de rapport Word ou PDF par engagement, findings triés par CVSS décroissant

Topologie

Schéma réseau interactif : les nœuds se déplacent directement sur la page (glisser-déposer), et peuvent être imbriqués les uns dans les autres pour former des regroupements (par exemple, un hyperviseur "boîte" contenant ses VMs). Ajout de nœuds personnalisés et gestion des liens entre eux depuis Settings → Config Topology, avec le même export/import/réinitialisation JSON que les autres registres.

Exemple concret

Le réseau fictif d'une PME ("FSociety"), construit avec les outils ci-dessus pour donner une idée de la portée possible :

• Deux boîtes imbriquées : la DMZ (serveur Web + serveur Mail) et l'hyperviseur ESXi (2 VMs) -- chaque enfant reste rattaché à sa boîte quand elle est déplacée
• Des nœuds libres pour tout ce qui n'a pas besoin d'un regroupement : pare-feu, switch, contrôleur de domaine, serveur de fichiers, postes utilisateurs, sauvegarde cloud
• Des liens tracés entre nœuds de haut niveau pour représenter les segments réseau, sans devoir positionner chaque VM/serveur imbriqué individuellement

Multi-Dashboard

Crée autant de dashboards indépendants que tu veux depuis Settings → Dashboards. Chacun garde sa propre combinaison de sections activées et sa propre disposition de panneaux. Au premier lancement, quatre dashboards sont déjà prêts : Dashboard (réseau + journal système), Système d’attaque (shells, avec un Bash déjà ouvert, + outils ; si les scripts ttyd ne sont pas lancés, un avertissement temporaire le rappelle), File Explorer et GRC & Website (couverture GRC, prochaines revues, Website) ; renomme-les, modifie-les ou supprime-les librement. Autres exemples de découpage :

• Une vue orientée opérations réseau -- topologie, inventaire réseau et outils réseau au premier plan
• Une vue orientée pentest -- engagements, findings CVSS et terminaux embarqués
• Une vue orientée GRC -- checklist, registre des actifs, des risques et des incidents

Paramètres (Settings)

Tout se configure depuis une seule page, sans toucher au code -- présentée en deux volets : une nav à gauche par section, le contenu de la section choisie à droite. (Pour figer des valeurs par défaut dans le déploiement lui-même, voir Valeurs par défaut du déploiement.)

• Apparence -- Thème (5 variantes : Standard, Neon Terminal, Blade Runner, Black ICE, et Personnalisé avec un sélecteur de couleur pour choisir sa propre couleur d'accent), Langue (français/anglais, interface commune uniquement), Background (fond d'écran global, remplace celui défini par défaut sur chaque page)
• Assistant & réinitialisation -- relance le tour guidé ; sauvegarde complète (un seul JSON pour tous les registres) ; réinitialisation par registre ou totale -- voir ci-dessous
• Interface -- Pages visibles (masque des liens dans le menu latéral, n'empêche pas l'accès direct à la page) et Sections du Dashboard (par dashboard, quelles sections sont actives -- même réglage que le bouton ☰ Panneaux directement dans le Dashboard)
• GRC -- pourcentages de couverture GRC, "Ton nom" pour la traçabilité, fiche RPRP (nom, coordonnées, délégué, date de nomination), l'option « afficher tous les onglets » de la documentation (sinon l'essentiel d'abord), et une bascule par section pour chacune des 7 entrées du sous-menu GRC (indépendante du réglage global "GRC" de l'onglet Interface)
• Shells -- opacité des fenêtres de terminal dans le Dashboard, pour laisser transparaître le fond derrière elles (75 % par défaut ; une valeur déjà réglée est conservée)
• Registres -- Config Network / Tools / DevSecOps / Website / Topology / About / Branding, chacun avec export JSON, import JSON et réinitialisation par défaut
• Sécurité -- coffre-fort (chiffrement du localStorage), voir Limites connues

Assistant & réinitialisation

Trois outils dans cet onglet, pensés pour "tout casser proprement" au besoin :

• Sauvegarde complète -- un seul fichier JSON avec tous les registres (Réseau, Outils, DevSecOps, Website, Topologie, About, Branding, Checklist GRC, Actifs, Risques, Contrôles, Incidents, Continuité, Fournisseurs, Vulnérabilités, Vie privée, Conformité, IAM, Indicateurs, Findings) en un clic, pratique pour migrer de navigateur ou sauvegarder avant une réinitialisation
• Réinitialiser un registre -- un bouton par registre, chacun indépendant des autres
• Tout réinitialiser -- enchaîne tous les registres ci-dessus derrière une seule confirmation ; le coffre-fort n'est jamais touché par ce bouton (nécessite ta passphrase, geste séparé dans l'onglet Sécurité)

Valeurs par défaut du déploiement (config/)

Il y a deux façons de configurer NeonFlare. Depuis Settings (décrit ci-dessus) : chaque changement vit dans le localStorage de ce navigateur, sur cette machine uniquement -- non permanent, propre à qui l'a fait. En éditant les fichiers config/*.js : ça définit ce que voit tout navigateur neuf avant même d'ouvrir Settings -- permanent, embarqué dans le déploiement (idéal pour une instance solo ou une image d'équipe).

Chaque config/*.js est une graine. NeonFlare ne la lit que tant que ce registre n'a jamais été touché dans l'UI sur ce navigateur. Le premier ajout / édition / suppression dans Settings recopie la liste dans localStorage, et à partir de là c'est localStorage qui prime -- éditer le fichier n'a plus d'effet sur ce navigateur (un « Réinitialiser ce registre » dans Settings → Assistant efface la copie localStorage et rend la main au fichier).

Pas besoin d'écrire le JSON à la main : Settings → Registres → Config Network a un bouton « ⬇ Exporter en reseau.js » -- construis ta liste de nœuds dans l'UI, clique, colle le résultat dans config/reseau.js, redéploie.

Les fichiers

Structure de chaque fichier

Ce ne sont pas des JSON : chaque fichier déclare une constante globale (const xConfig = { … };). Garder la structure, changer les valeurs. Les chemins d'images sont relatifs à config/ (donc ../assets/images/…).

const reseauConfig = {
  background: "../assets/images/kali_xl_sharp.png",
  cards: [
    {
      url: "https://host.example",   // ouvert dans un onglet au clic
      img: "../assets/images/router.png",
      title: "Titre",
      sub: "Sous-titre",
      category: "Réseau",            // regroupe les cartes
      enabled: true                  // optionnel (défaut: true)
    }
    // ... autant de cartes que voulu
  ]
};

const topologyConfig = {
  links: [ ["nodeA", "nodeB"] ],   // paires d'ids de nœuds reliés
  nodes: [ /* arbres DOM des nœuds -- le plus simple : construire dans
              l'éditeur Topologie puis exporter, pas à la main */ ]
};

const aboutConfig = {
  background: "../assets/images/hacker.jpg",
  permit: {
    header: "", title: "", text: "", id: "",
    qrImage: null,        // chemin d'image ou null
    barcodeImage: null
  },
  links: [
    { label: "GitHub", url: "https://...", enabled: true }
  ]
};

const neonflareTechnologyConfig = {
  background: "../assets/images/kali_xl_city.png",
  cards: [
    { url: "#", img: "../assets/images/dragon-favicon.png",
      title: "Documentation", sub: "Guides et références" }
  ]
};

const brandingConfig = {
  name: "GothamBlood",                        // signature en bas à droite
  icon: "🐉",                                 // symbole devant la signature
  logo: "assets/images/dragon4_logo.png",     // icône de l'onglet (chemin relatif)
  pageTitle: "NeonFlare: Rise of GothamBlood", // titre de l'onglet
  networkStatusTitle: "Gotham Network — Status",
  topologySubtitle: "GothamBlood environment",
  linksTitle: "Professional Links - GothamBlood",
  techMenuLabel: "GothamBlood Tech"
};  // texte seulement ; champ absent ou vide = texte d'origine

const grcAuthorConfig = {
  defaultName: ""   // nom attaché aux modifs GRC tant que Settings n'est pas rempli
};

const encryptionConfig = {
  enabled: false   // true => carte "Chiffrement" visible dans Settings
};

const settingsConfig = {
  background: "../assets/images/kali_xl_forest_sharp.png"
};

// un fichier par page Outils : web, linux, windows, ad, recon, c2,
// aws, azure, docker, kubernetes, terraform, lateral, osint, post, misc
const toolsWebConfig = {
  background: "../assets/images/atlantis.png"
};

Bon à savoir

• Aucune étape de build : éditer, servir, recharger.
• Ces fichiers ne contiennent aucune donnée sensible par défaut et ne sont jamais envoyés nulle part -- ils sont servis comme le reste du site statique.
• Un fichier de graine mal formé (virgule en trop, guillemet manquant) casse la page qui le charge -- vérifie la console du navigateur en cas de doute.

Architecture

Site 100% statique -- HTML/CSS/JS, servi par nginx (voir Téléchargement) ou ouvert directement en local. Aucune donnée ne quitte ton navigateur : chaque registre de configuration est lu/écrit dans localStorage, sans appel réseau vers un serveur applicatif -- compatible avec un usage en file:// pur, sans même de serveur web.

La page racine (index.html) agit comme coquille : elle charge chaque section dans un iframe et communique avec elle via postMessage (thème, langue, visibilité des pages...). Les terminaux embarqués survivent à la navigation parce qu'ils sont rattachés à cette coquille plutôt qu'à la page affichée dans l'iframe.

Le schéma ci-dessous résume le fonctionnement complet : ce qui vit dans le navigateur, et le pont shell optionnel sur le poste hôte.

Chaque page livrée applique une politique de sécurité du contenu (CSP) stricte -- script-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'self' -- posée à la fois en balise <meta> (utile en file://) et, quand le site est servi par nginx, comme véritable en-tête HTTP (seul endroit où frame-ancestors a un effet réel). Un contrôle automatisé fait échouer la livraison si un <script> en ligne ou un attribut on*="" réapparaît sur une page.

Navigateurs supportés : Chromium (Chrome, Edge, Brave...) et Firefox, versions stables courantes -- traités comme cibles de premier rang. Chromium fonctionne en http(s):// comme en file:// ; Firefox uniquement en http(s):// (voir Limites connues). Une suite de tests automatisés (Playwright, y compris le chiffrement optionnel via WebCrypto) est rejouée sur les deux moteurs. Safari et les anciens navigateurs ne sont pas testés.

Licence

La technologie NeonFlare Community Edition (le dashboard, ses sections, son code source) est publiée sous licence MIT -- libre d'usage, de modification et de redistribution, y compris à des fins commerciales, tant que la notice de copyright originale est conservée. Aucune garantie n'est associée au logiciel (voir le texte complet de la licence MIT). Ce site vitrine suit la même licence.

Limites connues

Transparence sur ce que NeonFlare n'est pas (encore) :

FAQ

Est-ce que mes données sont envoyées quelque part ?

Non. Tout reste dans le localStorage de ton navigateur, sur ta machine.

Je perds ma config si je vide mon navigateur ?

Oui -- exporte régulièrement en JSON si tu veux pouvoir restaurer ta configuration : soit tout d'un coup depuis Settings → Assistant & réinitialisation → Sauvegarde complète, soit registre par registre (chacun a aussi son propre bouton Export).

Puis-je l'utiliser en équipe ?

Aujourd'hui, chaque personne a sa propre instance/config locale -- voir Limites connues. C'est une piste d'évolution suivie mais pas encore construite -- voir Pro Edition.