Manuel de prise en main

Objectif

Horus Audit Check pilote les niveaux 3 et 4 : audit approfondi humain, puis correction. Les tests gratuits (N1) et payants automatiques (N2) restent sur Web Check (site) ou AI Check (chatbot / agent).

À la création de mission, choisir le volet : Site web (17 thèmes OWASP/PTES) ou IA (14 thèmes OWASP GenAI).

Ce n’est pas un scanner. Burp, ZAP, nmap et les revues de prompts restent à côté. Aucun payload n’est lancé depuis cet écran.

Les 4 niveaux Horus

1. N1 gratuit — Web Check (8088) ou AI Check (8089), automatique.
2. N2 payant — tests plus poussés, toujours sur la même plateforme.
3. N3 audit — ici : mission humaine, checklist, fiches, PDF.
4. N4 correction — après livraison, Horus corrige les fiches (onglet Correction).

Un achat = un volet (site ou IA). Deux cibles = deux missions.

Chaîne méthodologique Horus

1. N1 / N2 — Web Check (8088) ou AI Check (8089), bouton « Demander un audit Horus ».
2. N3 Audit Check (8090) — mission humaine, checklist du volet, fiches, PDF.
3. Livraison — e-mail client + copie archive Horus.
4. N4 Correction — même dossier, après statut LIVRE.

Méthode PTES (site) ou OWASP GenAI (IA). Les cases sont des thèmes de couverture, pas des boutons « lancer le test ».

0 Démarrer

NetBeans : projet Horus-AuditDesk, Exécuter (F6). Ou :

cd /home/gilles/NetBeansProjects/Horus-AuditDesk
mvn -q exec:java

Ouvrir /horusauditdesk/. Javalin n’apparaît pas dans Services → Serveurs (Payara seulement). Arrêt : carré rouge de l’onglet Sortie, ou pkill -f 'org.horus.auditdesk.App'.

1 Connexion

Login

Identifiant interne. En local : prérempli admin.

Mot de passe

En local, sans variable d’environnement : admin. Créé seulement au premier démarrage.

Entrer

Ouvre la session (cookie). Le bandeau affiche ensuite Déconnexion.

2 Créer une mission

Client

Raison sociale — titre du rapport.

Contact

Interlocuteur côté client.

E-mail client

Destinataire par défaut de Livrer au client.

Périmètre (URL / IP / endpoint IA)

Limite juridique du test. Pas d’élargissement sans avenant.

Volet

Site web (17 tests) ou IA (14 tests). Obligatoire. Un volet par mission.

Id scan

Référence Web Check ou AI Check (selon le volet).

Notes

Contexte interne (horaires, exclusions, astreinte).

Créer mission

Statut BROUILLON + clone de la checklist du volet.

Puis Ouvrir dans le tableau. Statuts : BROUILLON → EN_COURS → LIVRE → REMEDIATION → CLOTURE.

3 Les onglets

• Checklist — 17 thèmes web ou 14 thèmes IA.
• Fiches — vulnérabilités à remettre au client.
• Import — JSON Web Check ou AI Check selon le volet, sans écraser les fiches.
• PDF / Livraison — rapport et envoi.
• Correction — niveau 4, après livraison.

4 Les tests, un par un

Cocher Fait uniquement lorsque le thème a été couvert dans le mandat (y compris « non applicable, justifié »). Cocher n’est pas « RAS ». Un trou se saisit en fiche.

La colonne Note est affichée si elle existe ; en V1 la saisie se fait dans les notes de mission, une fiche, ou l’outil technique.

1. RECON — OSINT, DNS, bannières, sans sortir du public. Web Check peut amorcer. Pas de données volées.
2. SURFACE — Hôtes, ports, apps dans le périmètre (nmap / inventaire client). Inventaire écrit.
3. CONFIG — TLS, en-têtes, cookies, versions. Web Check en boîte noire ; l’humain complète (CDN, interne).
4. AUTH — Login, reset, MFA, SSO. Tests manuels Burp sous mandat. MFA absent → souvent une fiche.
5. SESSION — Fixation, timeout, flags cookies, logout. Premier avis possible via Web Check.
6. CTRL_ACCESS — IDOR, rôles, API. Toujours humain. Au moins un cas horizontal et un vertical (ou une sola persona documentée).
7. INPUT — Formulaires et API : lister les points d’entrée avant injection / XSS / upload.
8. INJECTION — SQLi, commande, etc. Uniquement sous mandat, outils de l’auditeur. Audit Check n’envoie aucun payload. Constat = fiche.
9. XSS — Réfléchi, stocké, DOM. Même règle : humain, mandat, pas d’exploit depuis ce serveur.
10. UPLOAD — Types, double extension, exécution. Web Check peut détecter un upload ; l’humain confirme.
11. CRYPTO — Transit (TLS, Web Check / SSL Labs) + repos (mots de passe, sauvegardes — souvent entretien).
12. INFO_LEAK — .env, .git, stack traces, listing. Trier bruit vs secret ; secret = fiche.
13. ADMIN — Panneaux /admin, cloud, phpMyAdmin. Lister, vérifier l’auth et la restriction IP/VPN.
14. BRUTE — Lockout, captcha, rate-limit. Interdit de lancer un bruteforce depuis Audit Check. Quelques tentatives + politique.
15. LOGS — Les essais apparaissent-ils ? Entretien client et échantillon de logs Horus. Documenter « non fourni » si besoin. Playbook au clic sur la ligne.
16. BACKUP — Existence, chiffrement, restauration, backups exposés. Souvent processus client.
17. CGU — Obligatoire avant PDF. Périmètre respecté, pas de DoS, données minimisées. Ne pas livrer si non coché.

Volet IA (14 thèmes)

1. IA_RECON — Type d’app, modèle, plugins.
2. IA_SURFACE — Chat, API, MCP, outils.
3. IA_AUTH — Tenant / API / session du bot.
4. IA_PROMPT — Injection et jailbreak sous mandat (humain, pas Promptfoo ici).
5. IA_HIDDEN — System prompt et politiques exposés.
6. IA_DATA — Fuites PII, secrets, métier.
7. IA_RAG — Isolation documents / tenants.
8. IA_AGENT — Autonomie des outils, actions sans confirmation.
9. IA_OUTPUT — Markup, URL, commandes dangereuses.
10. IA_RES — Bornes / déni de service LLM.
11. IA_MISINFO — Hallucinations, certitude abusive.
12. IA_SUPPLY — Modèle, plugins, MCP.
13. IA_LOGS — Journalisation conversations / incidents.
14. IA_CGU — Obligatoire avant PDF.

5 Fiches de vulnérabilité

Titre

Obligatoire. Court et précis.

Sévérité

FAIBLE / MODERE (défaut) / CRITIQUE.

Attaquant

DEBUTANT / EXPERT / ETATIQUE — qui peut réaliser l’attaque. Un débutant qui y arrive = plus grave.

Description

Quoi, où, comment reproduire, sans coller un exploit destructif.

Ajouter fiche

Calcule le risque : INACCEPTABLE, ACCEPTABLE ou BAS (matrice sévérité × attaquant).

Une case cochée sans fiche = thème couvert sans trou retenu. Plusieurs fiches pour un même thème = plusieurs constats. En V1, mettez l’essentiel dans le titre et la description (le PDF les reprend).

6 Import plateforme

Selon le volet, coller le JSON Web Check ou AI Check, puis Importer. Les fiches humaines ne sont jamais écrasées. Mauvais volet → erreur.

{"url":"https://exemple.fr","score":70,"verdict":"A_CORRIGER","controles":[]}
{"url":"https://bot.exemple/chat","score":42,"grade":"E","findings":[]}

7 PDF et livraison

• Télécharger le PDF — titre intrusion (site) ou audit de sécurité IA. À relire avant envoi.
• E-mail de livraison — prérempli. Obligatoire pour livrer.
• Livrer au client — joint le PDF, statut LIVRE, copie archive si configurée. Sans SMTP : simulation dans les logs.

Le PDF rappelle le mandat écrit, OWASP / PTES ou GenAI, l’absence d’exploitation automatique et la non-exhaustivité.

8 Correction (N4)

Après LIVRE, bouton Démarrer la remédiation. Chaque fiche : A_FAIRE → EN_COURS → CORRIGE → VERIFIE. Ce n’est pas un scanner : Horus corrige (code, config, prompts).

Pièges fréquents

• Cocher toutes les cases sans avoir testé.
• Prendre N1/N2 pour un audit N3 (INJECTION / XSS / IA_PROMPT restent humains).
• Mélanger site et IA dans une même mission (un volet par dossier).
• Importer le JSON de la mauvaise plateforme.
• Élargir le périmètre sans avenant.
• Orchestrer bruteforce ou exploit depuis Audit Check (interdit).
• Livrer un PDF non relu (client, périmètre, fiches vides).
• Démarrer N4 avant livraison (remédiation seulement depuis LIVRE).
• admin / admin : développement local uniquement.

Version longue (script audio, liste des captures) : fichier docs/manuel_prise_en_main_fr.md du projet Horus-AuditDesk.