Module 2 — Downgrade PQC (forensic réseau SATCOM)

2h30 Acte 3 · Audit Expert Forensic réseau · Crypto · PQC · MitM

Auteur : Thibaut Fontaine — Kodetis Institution : Université de la Réunion Date : 2026 Position : Acte 3 — module forensic (amorce Acte 4). Analyse de log obligatoire, PCAP en bonus. Artefacts : 07_telemetry_ssl.log (Zeek, obligatoire) · 07_telemetry_arp.log (obligatoire) · 07_telemetry_downgrade.pcap (bonus).

---

Table des matières

• Objectifs et contexte
• Prérequis & données
• Étape 1 — Comprendre la topologie
• Étape 2 — Détecter le downgrade dans ssl.log
• Étape 3 — Identifier le MitM dans arp.log
• Étape 4 — Reconstituer la chronologie
• Étape 5 — Bonus PCAP
• Étape 6 — Detection-as-code
• Étape 7 — Remédiation PQC-only
• Livrables & validation
• Annexe enseignant — corrigé

---

1. Objectifs et contexte

🎯 Objectif métier — repérer une attaque qui ne casse rien visiblement : la liaison reste « chiffrée » et valide, mais l’attaquant a discrètement affaibli la cryptographie pour pouvoir déchiffrer plus tard.

Pourquoi ça concerne les TAAF

L’uplink satellite (SATCOM) des bases est facile à intercepter (RF en clair sur le segment radio) et les données scientifiques/classifiées ont une longue durée de vie (décennies). C’est le terrain idéal du « Harvest Now, Decrypt Later » (HNDL) : capter aujourd’hui du trafic chiffré classique, le stocker, et le déchiffrer plus tard avec un calculateur quantique. D’où l’usage de cryptographie post-quantique (PQC) sur le lien — concrètement X25519MLKEM768 (X25519 + ML-KEM-768, codepoint TLS 0x11EC).

🔴 Au fil de l’enquête

Étape Defense Evasion du jour J à 10:14:30Z : juste avant l’exfiltration satellite, l’attaquant downgrade le lien pour s’assurer que les données exfiltrées resteront déchiffrables. C’est le pendant « réseau » du vol de données vu au Module 1.

Rigueur cryptographique (à ne pas se tromper)

• On downgrade le groupe d’échange de clés (KEM), pas la signature du certificat.
• X25519MLKEM768 = hybride post-quantique (codepoint 0x11EC). x25519 = classique (0x001D).
• L’authentification (certificat RSA-2048) reste inchangée : ce n’est PAS l’axe attaqué.
• La protection anti-downgrade de TLS 1.3 ne couvre que la version, pas le choix de groupe → l’attaque est réaliste et non détectée par TLS lui-même.
• Risque réel : perte de confidentialité post-quantique (HNDL), pas une rupture immédiate.

Architecture du TP

graph LR
 subgraph "Topologie SATCOM"
 ANT[Antenne SATCOM
10.42.20.1
client TLS]
 TEL[Serveur télémétrie
10.42.20.10:443]
 ATT[Attaquant MitM
10.42.10.66]
 end

 subgraph "Capture"
 ZEEK[Zeek monitor
span port]
 SSL[/ssl.log/]
 ARP[/arp.log/]
 end

 subgraph "Investigation"
 LOKI[(Loki)]
 GRAFANA[Grafana Explore]
 PCAP[(PCAP — bonus)]
 WS[Wireshark]
 end

 ANT -.->|ARP empoisonné| ATT
 ATT -.->|relay + modif ClientHello| TEL
 ZEEK -->|capture| SSL
 ZEEK -->|capture| ARP
 SSL --> LOKI
 ARP --> LOKI
 LOKI --> GRAFANA
 PCAP --> WS

 classDef bad fill:#ff9999,stroke:#333,stroke-width:2px
 classDef good fill:#99ff99,stroke:#333,stroke-width:2px
 classDef neutral fill:#ffcc99,stroke:#333,stroke-width:2px

 class ATT bad
 class ANT,TEL,SSL,ARP good
 class ZEEK,LOKI,GRAFANA neutral

---

2. Prérequis & données

Récupérer les artefacts

Les logs du scénario sont générés puis ingérés dans Loki par la stack monitoring (Alloy) :

# Sur la VM monitoring
cd ~/monitoring
./regen-logs.sh 2026-A    # SEED=2026-A pour la cohérence promo

→ Les fichiers atterrissent dans ~/data/_scenario/generated/ :

ls -la ~/data/_scenario/generated/07_telemetry_*
# -rw-r--r--  07_telemetry_ssl.log         (Zeek, ~120 lignes)
# -rw-r--r--  07_telemetry_arp.log         (Zeek, ~50 lignes)
# -rw-r--r--  07_telemetry_downgrade.pcap  (bonus, ~2 MB)

Format du ssl.log Zeek (rappel)

Format TSV (tab-separated) avec header #fields :

#fields ts  uid     id.orig_h    id.orig_p  id.resp_h     id.resp_p  version    cipher                             curve              server_name           subject       issuer
1781690670.123 CkRZ0a 10.42.20.1   45123      10.42.20.10   443        TLSv13     TLS_AES_256_GCM_SHA384            X25519MLKEM768     telemetry.univ-taaf.internal  CN=...        CN=TAAF Root CA
1781690900.456 CkRZ0b 10.42.20.1   45124      10.42.20.10   443        TLSv13     TLS_AES_256_GCM_SHA384            X25519MLKEM768     telemetry.univ-taaf.internal  CN=...        CN=TAAF Root CA
1781691270.789 CkRZ0c 10.42.20.1   45125      10.42.20.10   443        TLSv13     TLS_AES_256_GCM_SHA384            x25519             telemetry.univ-taaf.internal  CN=...        CN=TAAF Root CA
1781691500.012 CkRZ0d 10.42.20.1   45126      10.42.20.10   443        TLSv13     TLS_AES_256_GCM_SHA384            X25519MLKEM768     telemetry.univ-taaf.internal  CN=...        CN=TAAF Root CA

→ La 3ème ligne a un curve anormal. C’est elle qu’on cherche.

---

3. Étape 1 — Comprendre la topologie

Hôte	IP	Rôle
Antenne/modem SATCOM	10.42.20.1	Client TLS, transmet la télémétrie
Serveur télémétrie	10.42.20.10:443	Reçoit + chiffre + stocke
Attaquant	10.42.10.66	Poste pivot interne (déjà compromis au Module 1 LotL — c’est TAAF-W-PAF07 post-escalade)
Zeek monitor	—	Capture sur le span port du switch

L’attaquant fait un ARP spoofing (MitM) :

• Il dit à l’antenne : “je suis le serveur télémétrie (MAC=ma_MAC)”.
• Il dit au serveur télémétrie : “je suis l’antenne (MAC=ma_MAC)”.
• Le trafic passe par lui dans les deux sens — il peut le modifier en vol.

⚠️ Point crucial : l’attaquant n’apparaît PAS dans le ssl.log. Zeek voit le TLS handshake entre les IP réelles (antenne ↔ serveur), pas le MitM. Pour le retrouver, il faut le arp.log.

---

4. Étape 2 — Détecter le downgrade dans ssl.log

4.1 — Voie A — Grafana / Loki (LogQL)

Ouvrez Grafana → Explore → datasource Loki.

{log="ssl"} | logfmt | curve!="X25519MLKEM768"

Résultat attendu : une seule ligne (au moins) avec curve=x25519 autour de 10:14:30 UTC.

ts=1781691270.789 uid=CkRZ0c id.orig_h=10.42.20.1 id.orig_p=45125 id.resp_h=10.42.20.10 id.resp_p=443 version=TLSv13 cipher=TLS_AES_256_GCM_SHA384 curve=x25519 server_name=telemetry.univ-taaf.internal subject="CN=telemetry.univ-taaf.internal" issuer="CN=TAAF Root CA"

📸 Capture obligatoire #1 : Grafana Explore montrant la ligne x25519 isolée.

4.2 — Voie B — CLI directe sur le fichier brut

awk -F'\t' '$1!~/^#/ && $9!="X25519MLKEM768" {print}' \
  ~/data/_scenario/generated/07_telemetry_ssl.log

Sortie attendue :

1781691270.789  CkRZ0c  10.42.20.1  45125  10.42.20.10  443  TLSv13  TLS_AES_256_GCM_SHA384  x25519  telemetry.univ-taaf.internal  CN=...  CN=TAAF Root CA

4.3 — Convertir le timestamp en UTC lisible

date -u -d @1781691270  # Linux
# → Wed Jun 17 10:14:30 UTC 2026

date -u -r 1781691270   # macOS
# → Wed Jun 17 10:14:30 UTC 2026

→ L’attaque a eu lieu à 10:14:30Z du jour J, sur le couple 10.42.20.1 (antenne) ↔ 10.42.20.10 (télémétrie).

4.4 — Analyser la trame TLS

Champ	Valeur normale	Valeur attaquée	Lecture
version	TLSv13	TLSv13	✓ identique
cipher	TLS_AES_256_GCM_SHA384	TLS_AES_256_GCM_SHA384	✓ identique
curve	X25519MLKEM768	x25519	⚠️ downgrade KEM
subject / issuer	CN=TAAF Root CA	CN=TAAF Root CA	✓ certificat inchangé

Lecture critique :

• Aucune erreur TLS — la session est valide d’un point de vue protocole.
• Le certificat n’est pas falsifié — donc pas d’alerte type “untrusted CA”.
• Seul le groupe d’échange a changé. Sans alerte sur ce champ, rien ne tombe.

---

5. Étape 3 — Identifier le MitM dans arp.log

Le ssl.log ne suffit pas à pointer l’attaquant. Il faut le arp.log pour voir l’empoisonnement.

5.1 — Format du arp.log Zeek

#fields ts  src_mac           dst_mac           src_ip       dst_ip       operation  flags
1781691250.001  aa:bb:cc:dd:ee:01  aa:bb:cc:dd:ee:02  10.42.20.10  10.42.20.1   request    -
1781691250.002  aa:bb:cc:dd:ee:02  aa:bb:cc:dd:ee:01  10.42.20.1   10.42.20.10  reply      -
1781691260.123  aa:bb:cc:dd:ee:66  -                  10.42.20.1   10.42.20.10  reply      SPOOF
1781691260.456  aa:bb:cc:dd:ee:66  -                  10.42.20.10  10.42.20.1   reply      SPOOF
1781691270.789  aa:bb:cc:dd:ee:66  aa:bb:cc:dd:ee:02  10.42.20.1   10.42.20.10  -          SPOOFED_TRAFFIC

→ La 3ème et 4ème lignes sont des ARP reply non sollicités (reply sans request correspondant) avec un flag SPOOF ajouté par le monitor. Voilà notre MitM.

5.2 — Voie A — LogQL

{log="arp"} | logfmt | flags=~".*SPOOF.*"

Résultat attendu : 2-3 lignes avec src_mac=aa:bb:cc:dd:ee:66 qui se prétend être à la fois l’antenne (10.42.20.1) et le serveur télémétrie (10.42.20.10).

5.3 — Voie B — CLI

awk -F'\t' '$1!~/^#/ && $7~/SPOOF/' ~/data/_scenario/generated/07_telemetry_arp.log

5.4 — Retrouver l’IP réelle de l’attaquant

L’ARP nous donne la MAC du pivot (aa:bb:cc:dd:ee:66). Pour trouver son IP, on cherche cette MAC associée à une autre IP (la vraie) :

awk -F'\t' '$1!~/^#/ && $2~/aa:bb:cc:dd:ee:66/ && $4!~/10.42.20/' \
  ~/data/_scenario/generated/07_telemetry_arp.log | head -3

Sortie attendue :

1781689800.111  aa:bb:cc:dd:ee:66  ff:ff:ff:ff:ff:ff  10.42.10.66  10.42.10.1  request  -

→ L’attaquant est 10.42.10.66 — la MAC aa:bb:cc:dd:ee:66 s’associe normalement à cette IP. C’est le même poste que celui escaladé en DA au Module 1 LotL (cohérence kill chain).

📸 Capture obligatoire #2 : Grafana Explore avec les lignes SPOOF du arp.log + l’IP attaquant identifiée.

---

6. Étape 4 — Reconstituer la chronologie

Tableau attendu (livrable) :

Heure (UTC)	Source	Événement	Lecture
10:14:10Z	arp.log	ARP SPOOF antenne (10.42.20.1)	MitM démarre — phase 1
10:14:10Z	arp.log	ARP SPOOF télémétrie (10.42.20.10)	MitM démarre — phase 2
10:14:30Z	ssl.log	TLS 1.3 handshake, curve=x25519	Downgrade effectif
10:14:30Z+	arp.log	SPOOFED_TRAFFIC continue	Sessions suivantes interceptées

Lecture critique : l’ARP spoof précède le downgrade de ~20 secondes — c’est la fenêtre de pré-positionnement. Toute future session entre antenne et télémétrie est interceptée tant que le spoof tient.

---

7. Étape 5 — Bonus : Analyse PCAP

7.1 — Filtrer la session downgradée

tshark -r ~/data/_scenario/generated/07_telemetry_downgrade.pcap \
  -Y "ssl.handshake.type==1 && ssl.handshake.extension.type==51" \
  -V | less

L’extension 51 = key_share. Vous cherchez :

• Un ClientHello normal : key_share contient X25519MLKEM768.
• Un ClientHello downgradé : key_share ne contient que x25519.

7.2 — Comparer les extensions supported_groups

tshark -r 07_telemetry_downgrade.pcap \
  -Y "ssl.handshake.type==1" \
  -T fields -e tcp.stream -e ssl.handshake.extensions_supported_group

Sortie attendue (extrait) :

0    0x11ec, 0x001d, 0x0017   <- ClientHello normal (PQ + x25519 + autres)
1    0x11ec, 0x001d, 0x0017
2    0x001d, 0x0017             <- ClientHello downgradé (PQ retiré !)
3    0x11ec, 0x001d, 0x0017

→ Pour la session tcp.stream=2, l’attaquant a modifié le ClientHello en vol pour retirer 0x11EC (le groupe PQ) de supported_groups. Le serveur n’a plus le choix : il négocie 0x001D (x25519).

📸 Capture obligatoire #3 (bonus) : Wireshark montrant les deux ClientHello côte à côte, avec l’extension supported_groups mise en évidence.

---

8. Étape 6 — Detection-as-Code

Ajoutez à votre repo taaf-detections la règle Sigma :

rules/credential_access/satcom-pqc-downgrade.yml :

title: SATCOM TLS — Post-Quantum KEM Downgrade
id: 8e9f0a1b-2c3d-4e5f-6a7b-8c9d0e1f2a3b
status: stable
description: |
  Détecte une session TLS 1.3 vers le serveur de télémétrie SATCOM
  qui n'utilise PAS le groupe post-quantique X25519MLKEM768 attendu.
  Indique un downgrade KEM (T1600) probablement causé par un MitM.
references:
  - https://attack.mitre.org/techniques/T1600/
  - https://attack.mitre.org/techniques/T1557/002/
author: TAAF SOC
date: 2026/06/17
logsource:
  product: zeek
  service: ssl
detection:
  selection:
    id.resp_h: '10.42.20.10'
    id.resp_p: 443
    version: 'TLSv13'
  filter_pqc:
    curve: 'X25519MLKEM768'
  condition: selection and not filter_pqc
fields:
  - ts
  - uid
  - id.orig_h
  - id.resp_h
  - curve
  - server_name
falsepositives:
  - Client legacy qui ne supporte pas encore X25519MLKEM768 — doit être whitelisté explicitement
level: critical
tags:
  - attack.credential_access
  - attack.t1557.002
  - attack.defense_evasion
  - attack.t1600

Compilez :

cd ~/taaf-detections
./scripts/compile.sh

LogQL générée :

{job="zeek_ssl"} | logfmt | id_resp_h=`10.42.20.10` | id_resp_p=`443` | version=`TLSv13` | curve!=`X25519MLKEM768`

Et la règle complémentaire rules/credential_access/arp-spoofing.yml :

title: ARP Spoofing on SATCOM Segment
id: 9f0a1b2c-3d4e-5f6a-7b8c-9d0e1f2a3b4c
status: stable
description: |
  Détecte un ARP reply non sollicité (flag SPOOF de Zeek) sur le segment
  SATCOM (10.42.20.0/24). Précurseur classique d'un MitM.
references:
  - https://attack.mitre.org/techniques/T1557/002/
author: TAAF SOC
date: 2026/06/17
logsource:
  product: zeek
  service: arp
detection:
  selection:
    flags|contains: 'SPOOF'
    src_ip|startswith: '10.42.20.'
  condition: selection
fields:
  - ts
  - src_mac
  - src_ip
  - dst_ip
  - flags
level: high
tags:
  - attack.credential_access
  - attack.t1557.002

---

9. Étape 7 — Remédiation PQC-only

9.1 — Politique côté serveur télémétrie

Sur le serveur télémétrie (10.42.20.10), forcer PQC-only en refusant les groupes classiques :

# Exemple OpenSSL config (ssl.cnf)
[default_tls_ctx]
Groups = X25519MLKEM768            # <-- SEUL groupe accepté
# Au lieu de l'ancien :
# Groups = X25519MLKEM768:x25519:secp256r1

Conséquence : un client qui ne supporte pas X25519MLKEM768 voit son handshake échouer (handshake failure). C’est volontaire — l’absence de fallback est précisément ce qui empêche le downgrade.

Coût opérationnel : tous les clients doivent supporter PQ. Inventoriez les modems SATCOM, les versions logicielles, etc. Sur lien contraint, prévoyez une fenêtre de migration où PQC-only est appliqué après test.

9.2 — Intégrité ARP (Dynamic ARP Inspection — DAI)

Sur le switch du segment SATCOM (10.42.20.0/24), activer DAI :

! Cisco IOS exemple
ip arp inspection vlan 20
ip arp inspection validate src-mac dst-mac ip
interface range Gi0/1 - 23
  ip arp inspection trust   ! pour les ports vers les vrais hosts
interface Gi0/24
  ip arp inspection limit rate 10   ! rate-limit pour les ports user

→ Tout ARP reply qui ne correspond pas au binding DHCP snooping est droppé. Le MitM jour J aurait été tué dès la première trame SPOOF.

9.3 — Pinning du groupe côté client

Sur le modem SATCOM, si possible, pin le groupe attendu :

# Exemple config NGINX-style
ssl_ecdh_curve X25519MLKEM768;
ssl_protocols TLSv1.3;

9.4 — Lien avec l’Acte 2 (LDAP clair)

Ce TP a la même morale que le TP SSO AD↔NextCloud : la confidentialité du transport doit être imposée par défaut, pas optionnelle.

• LDAP clair (port 389) → LDAPS (port 636) → traité au TP PingCastle
• TLS 1.3 avec fallback x25519 → TLS 1.3 PQC-only → traité ici

→ Recommandation transversale pour le rapport d’audit IA : « toute transition de canal cryptographique doit refuser le fallback ».

---

10. Livrables & validation

Livrables

1. Fiche forensic (1 page) contenant :
   • Heure UTC du downgrade
   • Couple d’IP affecté (antenne + télémétrie)
   • IP réelle de l’attaquant (via arp.log)
   • uid Zeek + preuve curve=x25519
2. Explication de l’attaque : ARP spoof → suppression du key_share PQ → fallback.
3. Pourquoi TLS 1.3 ne l’a pas détecté + pourquoi le cert RSA n’est pas l’axe attaqué.
4. 2 règles Sigma (downgrade KEM + ARP spoof) dans le repo taaf-detections.
5. Plan de remédiation PQC-only + DAI + pinning.
6. (Bonus) Capture PCAP annotée des deux ClientHello.

Grille de validation

Critère	Pondération
Détection du downgrade dans ssl.log (LogQL + CLI)	15 %
Conversion timestamp epoch → UTC correcte	5 %
Identification IP attaquant via corrélation arp.log	20 %
Chronologie ARP spoof → downgrade reconstituée	15 %
Explication crypto rigoureuse (KEM vs cert, anti-downgrade TLS)	15 %
2 règles Sigma compilables et déployables	15 %
Plan de remédiation PQC-only avec coût opérationnel discuté	15 %
(Bonus) Analyse PCAP des deux ClientHello	+10 % bonus

Format de rendu : PDF nom-prenom-promo.pdf sur Moodle.

---

11. Annexe enseignant — corrigé

Réponses attendues aux questions de validation

1. Champ trahissant : curve (groupe d’échange de clés). Valeur anormale : x25519. Valeur attendue : X25519MLKEM768.

2. Heure UTC : 10:14:30Z (epoch 1781691270 → conversion par date -u -d @1781691270).

3. Couple IP : id.orig_h=10.42.20.1 (antenne SATCOM, client TLS) ↔ id.resp_h=10.42.20.10 (serveur télémétrie, port 443).

4. IP attaquant : 10.42.10.66. Pas dans ssl.log car l’attaquant est un MitM transparent — Zeek voit le handshake entre les IP réelles. À trouver dans arp.log via les lignes SPOOF (la MAC aa:bb:cc:dd:ee:66 se prétend être à la fois antenne et serveur).

5. Chronologie : ARP spoof à 10:14:10Z (~20s avant le downgrade) → handshake downgradé à 10:14:30Z. L’ARP spoof est un pré-positionnement nécessaire pour intercepter et modifier le ClientHello.

6. Downgrade du KEM (X25519MLKEM768 → x25519), pas de la signature. Distinction critique : la signature RSA reste valide → le certificat est authentique → aucune alerte « cert untrusted ». Seul le KEM tombe, ce qui n’est pas surveillé par défaut par les outils standards.

7. Certificat RSA valide : l’attaquant ne substitue pas le cert — il le laisse passer. Il modifie uniquement les extensions du ClientHello (supported_groups, key_share). Le serveur signe son handshake avec sa vraie clé privée, la signature est vérifiable par le client → tout est « ok » du point de vue du cert.

8. TLS 1.3 anti-downgrade = version uniquement : la sentinelle DOWNGRD\x01 dans ServerHello.random empêche un attaquant de forcer TLS 1.2. Mais elle ne protège pas le choix des supported_groups ou cipher_suites. C’est un trou documenté du protocole.

9. HNDL TAAF : le segment radio SATCOM est physiquement interceptable (n’importe qui avec un récepteur peut capter). Aujourd’hui, x25519 est solide. Mais quand un calculateur quantique avec ~4000 qubits logiques existera (estimation 2030-2040 selon NIST), tout ce trafic capté pourra être déchiffré rétroactivement. Les données scientifiques TAAF (échantillons génétiques, données climatiques) ont une valeur à long terme → le risque est réel.

10. Règle LogQL : {job="zeek_ssl"} | logfmt | id_resp_h="10.42.20.10" | id_resp_p="443" | version="TLSv13" | curve!="X25519MLKEM768". Politique serveur : refuser le fallback (PQC-only). Coût opérationnel : tous les clients doivent supporter PQ (inventaire à faire), fenêtre de migration coordonnée, plan de rollback si problème.

Erreurs courantes à pénaliser

• Confondre downgrade KEM et substitution de cert → -10 % (incompréhension du protocole).
• Conclure que TLS 1.3 est cassé → -5 % (TLS 1.3 fait ce qu’il promet : protéger la version, pas tous les paramètres).
• Donner l’IP attaquant comme l’IP source du ssl.log (10.42.20.1) → -15 % (faute majeure de lecture du log — c’est la victime, pas l’attaquant).
• Pas de corrélation ssl.log ↔ arp.log → -10 % (le forensic croise les sources, ne reste pas mono-source).
• Pas de coût opérationnel discuté pour PQC-only → -5 % (manque la lucidité d’ingénieur).

Pont vers le rapport d’audit

Le findings de ce TP alimente le rapport final (tp-rapport-audit-ia) :

• Constat : la liaison SATCOM a été downgradée KEM, HNDL probable sur la fenêtre exfiltration.
• Recommandation : politique PQC-only + DAI sur segment SATCOM + supervision du champ curve dans le SIEM.
• Priorité : 🟠 (l’incident est dans le passé mais le HNDL reste, non rattrapable).

---

Mapping MITRE ATT&CK / référentiels

Élément	Référence
ARP spoofing / interception	T1557.002 (Adversary-in-the-Middle: ARP Cache Poisoning)
Affaiblissement du chiffrement	T1600 (Weaken Encryption), T1562 (Impair Defenses)
Cadre PQC	Recommandations ANSSI sur la transition post-quantique · NIST FIPS 203 (ML-KEM)
Réglementation	NIS 2 Art. 21 §2.h (politique crypto) · IGI 1337 chap. III (chiffrement)

Convergence : avec le vol DB (Module 1) et la phase LotL, ce downgrade complète la kill chain. Toutes les preuves alimentent le rapport d’audit final.

---

Références

• RFC 8446 — TLS 1.3
• Draft-ietf-tls-hybrid-design — X25519MLKEM768
• NIST FIPS 203 — ML-KEM
• ANSSI — Plan PQC
• Zeek — ssl.log fields
• Dynamic ARP Inspection — Cisco