Comprendre Sophos Incident Response, Readiness et les assessments

En cas d’incident de sécurité actif ou suspecté, on déclenche le processus d’incident déjà établi. Une attaque en cours n’est pas un projet d’implémentation ordinaire. On utilise le contact prévu dans le plan d’urgence et le droit au service confirmé, plutôt que de commencer par commander un assessment ou un nouveau retainer.

Le Digital Forensics and Incident Response (DFIR) associe l’investigation forensique à la réponse à un incident précis. La Readiness prépare les responsables et les procédures. Les Security Testing et assessments examinent un périmètre de sécurité défini à l’avance. Ces prestations produisent des résultats différents et ne se remplacent pas mutuellement.

Transmettre correctement un incident

Sophos décrit DFIR comme une aide à l’identification et à la neutralisation des menaces actives, à l’analyse des causes, aux Compromise Assessments et au Threat Hunting. Le travail réellement pris en charge dépend de la prestation commandée et du droit confirmé. La description d’une équipe disponible jour et nuit n’est pas un engagement individuel sur le début d’intervention, la présence sur site ou la durée de rétablissement.

Pour la première transmission, on prépare un état bref et traçable :

1. Interlocuteurs et pouvoir de décision : direction technique de l’incident, responsables métier et canal de retour autorisé.
2. Observations plutôt qu’hypothèses : heure avec fuseau, systèmes ou identités concernés, messages concrets et effets visibles.
3. Mesures déjà prises : par exemple isolements, restrictions de comptes ou restaurations, avec date et exécutant.
4. Éléments disponibles : journaux, identifiants de dossiers et sauvegardes existantes, avec leur provenance et lieu de conservation. Une exhaustivité inconnue est explicitement signalée.
5. Droit au service et périmètre : client, contrat ou retainer et zone affectée connue. Un droit non confirmé ne doit pas être présenté comme acquis.

Cette liste est une recommandation Avanet pour organiser la transmission, pas une procédure forensique complète. Elle permet une première prise en charge sans perdre d’informations par des changements prématurés. On ne réinstalle pas des systèmes contaminés simplement pour obtenir un « point de départ propre ». Les responsables d’incident décident de l’isolement, de l’arrêt, de la conservation des preuves et du rétablissement selon le cas.

Les preuves peuvent contenir mots de passe, données personnelles ou informations confidentielles. Seules les données nécessaires sont transmises par un canal sécurisé confirmé. Un ticket public, un chat ou un lien non protégé ne convient pas. Si les comptes de communication peuvent être compromis, on convient d’un canal de retour fiable avant la transmission.

Distinguer MDR et DFIR

MDR est le service géré continu de recherche de menaces, de détection et de réponse convenue. DFIR traite un incident précis dans le périmètre d’investigation confirmé. Même si la même organisation fournit les deux, une alerte produit ne commande pas automatiquement DFIR et ne donne pas droit à une investigation illimitée.

Dans une exploitation MDR existante, les contacts et le mode Threat Response, ainsi que le responsable réel du dossier et l’action client requise, sont déterminants. Un dossier customer-managed n’est pas automatiquement analysé par l’équipe MDR du seul fait d’une licence Sophos. Les actions client ouvertes nécessitent un responsable et ne disparaissent pas par un changement de service supposé.

L’article Security Services Retainer explique les Service Units et les conditions particulières de DFIR. Un solde SU n’est ni un délai de réponse général ni la garantie de clore un incident en un nombre donné d’heures. Les droits existants se vérifient dans les accords précis.

Readiness : s’exercer avant l’incident

La préparation signifie que responsabilités, accès et circuits de décision sont utilisables avant un incident. Une Tabletop Exercise est une discussion guidée autour d’un scénario : l’équipe examine décisions et transmissions sans lancer une véritable attaque sur la production.

On définit l’objectif et les participants, par exemple la coordination entre IT, direction et communication lorsque des identités d’administrateurs sont compromises. L’exercice doit montrer qui déclare l’incident, qui autorise l’endiguement, comment communiquer hors des systèmes potentiellement touchés et comment décider du rétablissement. Il produit des observations documentées et des améliorations concrètes avec responsables et échéances.

Un plan d’urgence existant ne prouve pas à lui seul que la restauration fonctionne ou que les contacts sont joignables. Avanet recommande de revérifier la chaîne de contacts et d’approbation ainsi qu’un processus de restauration adapté après les changements pertinents. Une simple discussion ne remplace pas un test technique de restauration planifié séparément.

Choisir les assessments et tests de sécurité

Un External Penetration Testing examine l’accès depuis l’extérieur. Les tests internes peuvent analyser ce qui devient possible avec un accès réseau déjà présent. Les tests wireless visent les chemins d’attaque Wi-Fi ; les Web Application Assessments examinent les applications et leurs faiblesses précises. Le nom de la prestation ne garantit pas l’inclusion de tous les sites, applications ou interfaces.

Un assessment ne prouve pas non plus l’absence totale de compromission. Un Compromise Assessment recherche des signes d’intrusion dans son périmètre convenu ; un test d’intrusion évalue certains chemins d’attaque. On distingue les deux de l’exploitation continue Managed Risk et de la réponse à un incident déjà actif.

Avant un test, on fixe par écrit les cibles et exclusions, les autorisations des propriétaires, les méthodes permises, les fenêtres, les accès aux données et les critères d’arrêt. Les systèmes cloud ou tiers exigent les autorisations de test correspondantes. Un contact d’interruption doit être joignable ; disponibilité et impacts sur la production sont explicitement pris en compte. Sans autorisation claire, aucun test ne démarre.

Le résultat comprend des constats compréhensibles : systèmes concernés, preuves, effets et remédiation priorisée. Un nouveau test vérifie les points corrigés convenus ; le devis confirme s’il est inclus, quand et dans quelles limites. Un rapport n’est pas un certificat d’invulnérabilité future. La réalisation et la réception des améliorations restent des tâches distinctes et visibles.

Pour les changements planifiés après les constats, la distinction entre TAM, support et Deployment Services aide à transformer une recommandation en projet défini avec transfert technique, plutôt qu’à faire circuler les risques ouverts entre prestataires.