Réponse aux incidents et préservation des éléments de preuve

Source de référence EN · P03-L07 · needs_review

Étude exclusivement hors ligne/en lecture seule. Ne fournissez jamais de secrets, de mots de passe ni de codes d’authentification. Aucune connexion de portefeuille, autorisation réelle, révocation en direct, signature de transaction, aucun transfert, fonds ou échange. Les visuels sont uniquement des spécifications.

Lors d’un incident, les utilisateurs doivent réduire leur exposition tout en consignant suffisamment d’éléments de preuve non secrets pour une analyse ultérieure. Un rapport rétrospectif d’entreprise peut enseigner cette démarche si chaque affirmation historique conserve son attribution.

Utiliser le dossier de sources figé

Le jeu de données P03-L07-LEDGER-REPORT-20231220-v1 contient un relevé sélectif paraphrasé de la publication et un fichier de provenance. LR01 consigne les dates du rapport et de l’incident : les 20 et 14 décembre 2023, selon Ledger. LR02 conserve les affirmations regroupées sur les heures de publication CET et les versions. LR03 conserve la prise de connaissance rapportée et une entrée de la chronologie de remédiation ; son étiquette n’est pas une preuve indépendante de l’instant précis du déploiement. LR04 conserve le récit de l’entreprise sur la propagation des caches. Il s’agit de LEDGER-REPORTED / OFFICIAL COMPANY REPORT (rapporté par Ledger / rapport officiel d’entreprise), et non d’événements de l’incident capturés indépendamment.

Le dossier a été récupéré le 2026-10-01, avec une précision au jour. Il s’agit d’un rendu actuel d’une publication rétrospective, pas d’une capture contemporaine de 2023. Il ne contient aucun reçu natif de chaîne, échantillon de logiciel malveillant, artefact npm, hash de paquet, journal de signature, chiffre de pertes ni attribution humaine. Inspecter la publication officielle établit qu’elle contient les déclarations conservées ; cela n’authentifie pas indépendamment leur chronologie sous-jacente.

Lire la chronologie sans combler les lacunes

LR02 conserve sous forme regroupée les versions affectées et les étiquettes d’heure de publication. N’associez pas chaque version à une heure en supposant que leur ordre dans la liste établit une correspondance univoque. Conservez CET comme base temporelle déclarée. L’heure d’un événement historique, la date de publication et la date de récupération répondent à des questions différentes.

La déclaration de remédiation de LR03 n’établit ni un instant précis de déploiement vérifié indépendamment, ni un confinement universel. LR04 rapporte une réserve concernant les caches, tandis que l’heure exacte de dernière distribution sur l’ensemble des systèmes reste UNKNOWN (INCONNU) dans ce dossier. Un rapport ultérieur peut décrire une atténuation sans montrer ce que le navigateur d’un utilisateur précis a chargé. L’exposition d’un utilisateur nécessite des enregistrements locaux/logiciels et d’autorisation dont les sources sont appropriées ; les seules étiquettes de version ne montrent pas l’exécution d’un mouvement d’actifs.

Répéter une réponse sans prétendre qu’elle a eu lieu

Le cadre de priorités qui suit relève d’un raisonnement pédagogique INFERRED (INFÉRÉ), pas d’une reconstitution de la réponse effective de Ledger ou d’un utilisateur. Évitez d’abord de poursuivre une interaction non résolue : aucune connexion, autorisation, signature de message ou transfert supplémentaire. Dans un scénario organisationnel, isolez l’interaction/le composant suspect via un processus d’incident établi. Cet exercice en classe n’effectue aucune modification opérationnelle.

Préservez les éléments de preuve non secrets lorsque c’est sûr et rapide : URL source, résumé du message observé, nom/version déclaré du paquet, heure de la note d’incident et méthode de collecte. La préservation ne doit pas nécessiter de recharger du code suspect ni retarder un confinement urgent. Si conserver le matériel exige d’exécuter un logiciel malveillant ou d’exposer des identifiants d’accès, consignez plutôt cette lacune. Ne faites pas de « tout capturer d’abord » une règle universelle.

Séparer les catégories d’artefacts

Une déclaration de version d’un paquet n’est pas un binaire de ce paquet. Un hash de paquet n’est pas une attribution complète d’un logiciel malveillant. Un repère public de transaction n’est pas une identité humaine. Une déclaration d’utilisateur sur une signature n’est pas une autorisation consommée observée indépendamment. Construisez des lignes distinctes pour le rapport d’entreprise, l’artefact local, l’étape d’autorisation et les éléments de preuve du résultat. Dans ce dossier, seule la première catégorie contient des enregistrements historiques.

Une ligne utile comprend la source, le repère, le champ/l’affirmation, la classe de source, la base temporelle d’origine, la précision de l’heure de récupération et ce qu’elle ne permet pas d’établir. Si la remédiation modifie un système, consignez les observations ultérieures comme des contextes ultérieurs plutôt que de réécrire les éléments de preuve d’origine. Masquez les valeurs confidentielles dans toute remise pédagogique ; les recommandations de sécurité excluent le partage du matériel de récupération, des clés et des mots de passe [SECURITY].

Indiquer ce qui est connu et ce qui reste non résolu

OBSERVED (OBSERVÉ) : métadonnées de publication et existence des déclarations LR01–LR04, explicitement au niveau du rapport d’entreprise. INFERRED (INFÉRÉ) : priorités de réponse de la fiche de travail sous les hypothèses du scénario indiquées. UNKNOWN (INCONNU) : artefacts des utilisateurs affectés, signatures consommées, pertes, état complet des caches et identité humaine. INSUFFICIENT EVIDENCE (ÉLÉMENTS DE PREUVE INSUFFISANTS) : confirmation forensique indépendante, responsabilité d’une personne précise ou toute affirmation selon laquelle tous les utilisateurs étaient en sécurité après le correctif rapporté.

Préparer une transmission factuelle

Votre transmission doit comporter trois parties : décision immédiate hors ligne, inventaire des éléments de preuve conservés et questions ciblées encore non résolues. Elle ne doit jamais demander de phrase de récupération, clé privée, mot de passe, matériel de récupération ou code d’authentification. « Veuillez fournir la source non secrète du paquet/de la version et son contexte de collecte » est une demande précise d’éléments de preuve. « Donnez-moi votre matériel de récupération pour que je puisse enquêter » est interdit. L’exercice ne signe aucune révocation et ne déplace pas d’argent ; les opérations de réponse réelles nécessitent leur propre contexte d’incident de confiance et sortent du cadre de cette leçon.

• Confinement : réduction de l’exposition qui se poursuit, distincte d’une reconstitution forensique complète.
• Préservation : conservation d’éléments de preuve sûrs avec leur source et leur contexte de collecte.
• Rapporté par l’entreprise : déclaration sur l’incident attribuée à son éditeur.
• Artefact : objet collecté avec sa provenance, distinct d’une affirmation le concernant.
• Provenance temporelle : signification d’un horodatage et identité de son fournisseur.

HISTORICAL : uniquement les enregistrements LR01–LR04 du rapport d’entreprise ; aucun artefact indépendant de chaîne/forensique. Utilisez dataset.json et records/ledger-report.selective.json. La fiche de réponse propose des actions sous des hypothèses explicites de scénario hors ligne ; elle n’ajoute aucun événement Ledger fictif, aucune identité de portefeuille, perte ou conclusion causale.

Panneau d’éléments de preuve avec un bandeau LEDGER-REPORTED permanent. La piste historique ne contient que LR01–LR04 et les sections sources/bases temporelles correspondantes. Une piste distincte de fiche de travail contient les priorités de réponse INFERRED (INFÉRÉ). Une troisième piste d’artefacts inconnus indique comme indisponibles les octets du paquet, l’exposition locale et les résultats des transactions. Ne reliez jamais une étiquette de paquet à un attaquant humain ou à un total de pertes.

Les déclarations sélectionnées figurent dans l’enregistrement conservé de la publication officielle. La fiche de travail peut justifier des priorités de réponse sous des hypothèses explicites.

Une chronologie indépendante de l’incident, l’intégrité du paquet, l’attribution du logiciel malveillant/de l’attaquant, l’exposition des utilisateurs, les pertes, la fin effective du confinement ou un événement natif de chaîne de blocs.

• Présenter un récit d’entreprise comme une observation forensique indépendante.
• Préserver des éléments de preuve en réexécutant du code suspect.
• Retarder le confinement pour une série exhaustive de captures d’écran.
• Inférer des associations paquet/heure à partir d’un texte regroupé.
• Demander des secrets pour enquêter.

Créez des lignes pour LR01–LR04 : source, date de publication/d’incident, base temporelle rapportée, date/précision de récupération, affirmation sur la version du paquet lorsqu’elle existe, état des éléments de preuve et limite. Classez trois tâches hors ligne : suspendre l’interaction non résolue ; conserver la source/le contexte sûrs et expurgés ; identifier les artefacts manquants. Expliquez quand la préservation ne doit pas retarder le confinement. Rédigez une transmission factuelle contenant deux champs UNKNOWN (INCONNU) et une affirmation INSUFFICIENT EVIDENCE (ÉLÉMENTS DE PREUVE INSUFFISANTS), sans demander de secret.

Remettez un tableau et une conclusion délimitée en utilisant uniquement le matériel hors ligne fourni. Répartition éditoriale du temps : étude 12 min, exercice 8 min, correction/quiz 10 min.

• Confiner l’exposition sans ajouter d’actions en direct.
• Conserver uniquement les enregistrements non secrets disponibles sans danger.
• Garder la classe de source et la signification des horodatages.
• Conserver les affirmations regroupées du rapport sans inventer d’association.
• Distinguer artefact, déclaration et résultat.
• Laisser non résolues les affirmations d’identité/de pertes/de confinement complet.

Le cas Ledger est utilisable comme fiche de travail fondée sur un rapport d’entreprise attribué. On peut enseigner les priorités de confinement sûr et une préservation attentive à la provenance sans prétendre que le rapport vérifie indépendamment les événements ou identifie des personnes.

• Donner la priorité au confinement et consigner les faits sans demander de secrets
• Prioriser le confinement sans le retarder pour une collecte dangereuse d’éléments de preuve.
• Conserver la provenance des rapports, des paquets/versions et des horodatages.
• Distinguer l’inspection d’une publication d’une vérification indépendante de l’incident.

P03-L08 après avoir revu les prérequis et la correction.

NONE dans le catalogue de référence. Les données hors ligne fournies suffisent ; aucun achat de produit ni aucune opération de portefeuille n’est requis.

• [LEDGER] Rapport d’incident de sécurité de Ledger — Chronologie et déclarations sur les paquets attribuées à l’entreprise ; aucune preuve forensique ou de chaîne indépendante.
• [SECURITY] Sécurité Ethereum et prévention des escroqueries — Confidentialité des secrets, vérification exacte des domaines et prudence envers l’assistance non officielle.

La documentation explique les mécanismes. Les enregistrements historiques conservent leur classe de source déclarée. L’inspection d’une source ne constitue pas une acceptation éditoriale indépendante.