Certified Defensive Security Analyst

Qu'est-ce que la CDSA ?

La certification CDSA permet d'acquérir des connaissances solides en tant qu'analyste en sécurité défensive. On y apprend à utiliser des solutions SIEM comme Splunk et Elastic Search pour la détection et l'investigation d'incidents, mais aussi des outils de forensic tels que x64dbg pour l'analyse de malware, Volatility pour l'analyse mémoire, les outils de la suite Get-ZimmermanTools pour l'analyse de fichiers systèmes, ou encore Autopsy pour l'investigation numérique. Le but final est d'être capable de retracer intégralement une attaque, d'identifier les IOCs (Indicators of Compromise) ainsi que les TTPs (Tactics, Techniques and Procedures) utilisés par l'attaquant.

Format de la formation

Sur HTB, il y a 15 modules à valider avant de pouvoir passer l'examen. Comme pour la CWES, chaque module alterne théorie et pratique, mais avec beaucoup plus de lecture selon moi. Je les trouve très complets car ils expliquent comment utiliser les différents outils, dans quel but, et surtout comment et où chercher les informations pertinentes. Les modules sont dans leur grande majorité plus simples à appréhender que ceux de la CWES, mais plus longs à lire. Pour ma part, j'ai largement préféré la partie pratique.

Comme pour la CWES, chaque fin de module se termine par un Skill Assessment. La différence notable, c'est que les questions pratiques ne portent plus sur des flags à soumettre, mais sur des éléments bien plus concrets : un nom d'utilisateur, un PID, un nom de processus, un nom de fichier, une clé de registre...

Difficulté et parcours personnel

J'ai suivi les modules dans l'ordre en prenant des notes au fur et à mesure de mon avancée. J'ai passé cette certification après deux ans en école de sécurité informatique dont un cours d'Investigation numérique et avec une première certification déjà en poche, donc je ne suis peut-être pas la plus objective. Cela dit, j'ai trouvé la CDSA plus accessible techniquement pour trouver les informations. En revanche, la rédaction a été une autre histoire : c'est là que j'ai passé le plus de temps, et de loin.

Préparation

Pour me préparer, j'ai surtout constitué une liste sur Notion recensant les différentes choses à chercher lors d'une investigation, et en particulier une liste des Event IDs à avoir en tête pour chaque étape d'une attaque. Voici un petit extrait de ce que j'ai noté (je vous laisse découvrir les modules pour en savoir plus) :

• Reconnaissance

  4625 (échecs logon), 5156 (filtre réseau), Sysmon 3 (scans ports), Sysmon 22 (DNS suspects)

• Initial Compromise

  4624 (logon réussi), 4672 (privilèges spéciaux), Sysmon 1 (process malveillant), Sysmon 11 (dropper), Sysmon 13 (clé registry creds)

• C2 Communications

  5156 (connexions HTTP/S), Sysmon 3 (trafic sortant C2), Sysmon 22 (beaconing DNS)

• Enumeration

  4688 (process cmd/pwsh), 5145 (accès shares), Sysmon 1 (net.exe, whoami), Sysmon 11 (dumps SAM)

• Lateral Movement

  4624 (logons réseau multiples), 4648 (logon creds explicites), 5145 (shares accédés), Sysmon 1 (PsExec/WMIExec), Sysmon 3 (SMB/RDP interne)

• Data Access & Exfiltration

  4663 (accès fichiers sensibles), 5140/5142/5145 (shares accédés/créés), Sysmon 3 (trafic volumineux), Sysmon 11 (staging/compression), Sysmon 23 (nettoyage traces)

• Malware Deployment

  1116/1118/1119/1120 (Defender), 4688 (process hollowing), Sysmon 1 (exécution malware), Sysmon 7 (DLL malveillantes)

• Process Injection & Persistence

  4698/4700/4701/4702 (scheduled tasks), 4719/4907 (audit tampering), 5001 (Defender désactivé), 7045 (service créé), Sysmon 8 (hollowing), Sysmon 10 (injection mémoire), Sysmon 13 (Run keys, AppInit_DLLs), Win 1102 (log clearing)

Je procédais ensuite par to-do list, ce que je trouvais bien plus efficace côté organisation. Bien sûr, cette liste n'est pas exhaustive : en fonction de l'incident, il faut s'adapter et chercher d'autres Event IDs, mais elle constituait une base solide pour ne pas partir de zéro.

Déroulement de l'examen

L'examen coûte 215 $ comme la CWES, et dure également 7 jours. Cette fois-ci, j'ai utilisé la Pwnbox fournie par HTB du début à la fin, car il était plus simple de travailler directement sur leur VM avec tous les outils déjà installés.

Une fois le voucher activé, on se retrouve face à deux incidents. Le premier est guidé par des questions : il faut soumettre au minimum 16 bonnes réponses sur 20. Le second n'est pas guidé et nécessite la rédaction d'un rapport d'investigation complet. HTB fournit un template prêt à être rempli, avec également la possibilité d'utiliser SysReptor (ce que j'ai choisi là encore car c'est un outil que j'apprécie vraiment).

J'ai commencé un matin et en deux jours j'avais obtenu 17 réponses sur 20 pour le premier incident. J'ai enchaîné directement sur le second sans attendre, car l'absence de questions me faisait croire que j'y passerai plus de temps que prévu. Deux jours d'investigation plus tard, je me suis arrêtée pour rédiger, et là, ça a été une autre paire de manches. La rédaction m'a pris deux jours entiers, principalement parce que je m'étais mal organisée pendant la collecte de mes preuves. Je vous conseille vivement de noter vos trouvailles dans l'ordre chronologique dès le départ, en classant vos IOCs par heure de découverte : vous vous éviterez une rédaction comme celle que j'ai eu. Comme pour la CBBH, je m'étais dit que je tenterais de récupérer les 3 réponses manquantes après la rédaction... mais j'étais complètement à plat. J'ai donc soumis mon rapport avec 1 jour d'avance.

Mes petits conseils (que je n'ai pas appliqués)

• Entraînez vous à rédiger

  J'ai perdu beaucoup de temps à rédiger mon rapport, donc je vous conseille de pratiquer sur des cas simples comme les sherlocks d'HTB par exemple.

• Organisez-vous

  Noter vos trouvailles dans l'ordre chronologique dès le départ vous évitera de perdre du temps lors de la rédaction.

• Faites des pauses

  Le stress et la fatigue peuvent vous empêchez de réfléchir clairement. N'hésitez pas à prendre des pauses si vous vous sentez surchargé.