UEFI Bootkits et Attaques sur le Firmware : Persistance A...

Auteur : Ayi NEDJIMI    Date : 15 fevrier 2026 Cet article fournit une analyse technique approfondie et des recommandations pratiques pour les professionnels de la cybersecurite. Les concepts presentes sont issus de retours d'experience terrain et des meilleures pratiques du secteur. Les equipes techniques y trouveront des methodologies eprouvees, des outils recommandes et des strategies de mise en oeuvre adaptees aux environnements de production modernes. La maitrise de ces sujets est devenue incontournable dans le contexte actuel de menaces en constante evolution. Cet article fournit une analyse technique approfondie et des recommandations pratiques pour les professionnels de la cybersecurite. Les concepts presentes sont issus de retours d'experience terrain et des meilleures pratiques du secteur. Les equipes techniques y trouveront des methodologies eprouvees, des outils recommandes et des strategies de mise en oeuvre adaptees aux environnements de production modernes. La maitrise de ces sujets est devenue incontournable dans le contexte actuel de menaces en constante evolution.

---

Votre architecture de sécurité repose-t-elle sur une seule couche de défense ?

1. Introduction

La persistance sous le systeme d'exploitation represente le Saint Graal de l'attaque informatique avancee. Alors que les solutions EDR/XDR detectent de mieux en mieux les malwares au niveau du systeme d'exploitation, les acteurs APT les plus poussés se tournent vers les couches inferieures : le firmware UEFI. Un implant firmware survit au reformatage du disque dur, a la reinstallation du systeme d'exploitation, et meme au remplacement du disque de stockage dans certains cas.

L'annee 2023 a marque un tournant avec la decouverte de BlackLotus, le premier bootkit UEFI capable de contourner Secure Boot sur des systemes Windows 11 entierement mis a jour. Combine avec les decouvertes anterieures de CosmicStrand et MosaicRegressor par les equipes de Kaspersky, ces implants demontrent que les menaces firmware sont passees du domaine theorique au domaine operationnel. Selon les rapports de l'ANSSI et du CERT-EU, au moins cinq groupes APT disposent desormais de capacites d'implantation firmware actives.

Cet article explore en profondeur l'architecture UEFI et ses mecanismes de securite, analyse les bootkits decouverts in-the-wild, detaille les techniques d'implantation et de contournement de Secure Boot, et presente les strategies de detection et de remediation disponibles pour les equipes de securite.

---

2. Architecture UEFI et Secure Boot

Le processus de demarrage UEFI

L'Unified Extensible Firmware Interface (UEFI) a remplace le BIOS legacy comme interface entre le firmware de la carte mere et le systeme d'exploitation. Contrairement au BIOS qui executait du code 16 bits avec des capacites limitees, UEFI est un veritable environnement d'execution avec un modele de drivers, un systeme de fichiers (ESP - EFI System Partition), un networking stack, et des capacites graphiques.

Les phases de demarrage UEFI : Pour approfondir, consultez Living-off-the-Land (LOL-Bins/LOLBAS) à l’échelle.

1. SEC (Security Phase) : Premiere phase executee a la mise sous tension. Initialise le processeur, verifie l'integrite du firmware (root of trust), et prepare le transfert vers PEI. Code generalement stocke en ROM ou dans une region protegee de la flash SPI.
2. PEI (Pre-EFI Initialization) : Initialise la memoire RAM (memory controller), decouvre et initialise les ressources materielles de base. Les PEIM (PEI Modules) sont charges et executes pour configurer le materiel.
3. DXE (Driver Execution Environment) : Phase principale ou les drivers UEFI sont charges. Le dispatcher DXE charge les drivers depuis la flash SPI et l'ESP. C'est la phase la plus cibelee par les bootkits car elle offre un environnement d'execution riche.
4. BDS (Boot Device Selection) : Selection du peripherique de demarrage et chargement du bootloader. C'est ici que Secure Boot intervient pour verifier la signature du bootloader.
5. TSL (Transient System Load) : Chargement du bootloader (ex: bootmgfw.efi pour Windows, grubx64.efi pour Linux) et transfert du controle au systeme d'exploitation.
6. RT (Runtime) : Les Runtime Services UEFI restent accessibles apres le demarrage de l'OS, offrant des services comme l'acces aux variables UEFI (NVRAM), le RTC (Real Time Clock), et les capsule updates.

Secure Boot : Chaine de confiance

Secure Boot est un mecanisme de verification cryptographique qui garantit que seul du code signe par des autorites de confiance est execute pendant le processus de demarrage. La chaine de confiance repose sur quatre bases de donnees stockees dans la NVRAM UEFI :

Mise en pratique et recommandations

# Bases de donnees Secure Boot
# Stockees en NVRAM UEFI (variables authentifiees)

PK (Platform Key):
  # Cle racine, generalement celle du fabricant OEM
  # Seul le detenteur de la PK peut modifier les autres bases
  # Format: X.509 certificat ou SHA-256 hash
  Owner: Microsoft Corporation / OEM

KEK (Key Exchange Key):
  # Cles autorisees a modifier db et dbx
  # Generalement: Microsoft KEK + OEM KEK
  Entries:
    - Microsoft Corporation KEK CA 2011
    - Microsoft Corporation KEK 2K CA 2023
    - [OEM specific KEK]

db (Authorized Signatures Database):
  # Certificats et hashes autorises pour le boot
  Entries:
    - Microsoft Windows Production PCA 2011
    - Microsoft Corporation UEFI CA 2011  # Signe shim/grub pour Linux
    - Microsoft Windows UEFI Driver Publisher (WinPE)
    - [OEM specific certificates]

dbx (Forbidden Signatures Database):
  # Certificats et hashes explicitement bloques
  # Mis a jour via Windows Update (UEFI Revocation List)
  Entries:
    - [Hashes de bootloaders vulnerables revoques]
    - [Certificats compromis]
    - [Hashes BlackLotus boot stages]

# Verification Secure Boot a l'execution:
# 1. Le firmware verifie la signature du bootloader (BDS phase)
# 2. Le bootloader est signe par une cle presente dans db
# 3. Le hash du bootloader n'est PAS dans dbx
# 4. Si les deux conditions sont remplies: execution autorisee
# 5. Sinon: echec de boot, message d'erreur

Flash SPI et stockage firmware

Le firmware UEFI est stocke dans une puce flash SPI (Serial Peripheral Interface) soudee sur la carte mere. Cette puce de 16 a 32 Mo contient l'ensemble du firmware, y compris le code SEC/PEI/DXE, les drivers UEFI, les micro-codes processeur, le ME/CSME firmware (Intel Management Engine), et les variables NVRAM. La protection de cette flash est assuree par plusieurs mecanismes :

• BIOS Write Protection (BWP) : Bit de protection dans le chipset qui empeche l'ecriture directe dans la flash SPI depuis le systeme d'exploitation.
• SPI Protected Ranges (PR0-PR4) : Registres du chipset definissant des regions de la flash comme en lecture seule.
• SMM BIOS Write Protection (SMM_BWP) : Requiert que les ecritures flash transitent par le System Management Mode, un mode d'execution ultra-privilegie du processeur.
• Intel Boot Guard : Verification materielle (fuses dans le processeur) du firmware au tout premier demarrage, avant meme la phase SEC.
• AMD Platform Secure Boot (PSB) : Equivalent AMD de Boot Guard, avec verification par le AMD Security Processor (PSP).

---

Combien de vos contrôles de sécurité ont été testés en conditions réelles cette année ?

3. BlackLotus Bootkit

Analyse technique de BlackLotus

BlackLotus, decouvert par ESET en mars 2023, est le premier bootkit UEFI in-the-wild capable de contourner Secure Boot sur des systemes Windows 11 entierement mis a jour. Vendu pour environ 5000 USD sur les forums cybercriminels, il represente une democratisation majeure des capacites offensives firmware, auparavant reservees aux acteurs etatiques.

Chaine d'infection BlackLotus :

1. Exploitation de CVE-2022-21894 (Baton Drop) : BlackLotus exploite une vulnerabilite dans le gestionnaire de demarrage Windows (bootmgr) qui permet de contourner les politiques Secure Boot. Bien que Microsoft ait publie un correctif, la revocation du bootloader vulnerable dans dbx est un processus lent et complexe.
2. Installation de bootloaders vulnerables : Le malware installe des versions anciennes et signees de bootloaders Windows sur la partition ESP, qui sont encore acceptees par Secure Boot car leurs hashes n'ont pas ete revoques dans dbx.
3. Modification de la BCD (Boot Configuration Data) : Les parametres de demarrage sont modifies pour charger le bootloader vulnerable au lieu du bootloader actuel.
4. Chargement du driver kernel malveillant : Le bootloader vulnerable desactive les protections (VBS, HVCI, BitLocker) et charge un driver kernel non signe.
5. Deploiement du HTTP downloader : Un composant usermode est injecte pour communiquer avec le C2 et telecharger des payloads supplementaires.

# Structure de l'ESP apres infection BlackLotus
# (EFI System Partition, generalement montee sur S:)

S:\EFI\Microsoft\Boot\
    bootmgfw.efi          # Bootloader Windows original (sauvegarde)
    bootmgfw.efi.bak      # Backup du bootloader
    grubx64.efi           # Faux fichier, en realite le bootkit
    BCD                   # Configuration de demarrage modifiee

S:\system32\
    bootmgr.efi           # Version vulnerable de bootmgr (signee Microsoft)
                          # Exploite CVE-2022-21894

# Registres modifies par BlackLotus
# (Variables UEFI NVRAM)

BootOrder: 0001, 0000     # Ordre de boot modifie
Boot0001:
  Description: "Windows Boot Manager"
  FilePath: \EFI\Microsoft\Boot\grubx64.efi  # Pointe vers le bootkit

# Capacites post-infection:
# - Desactivation de Windows Defender
# - Desactivation de BitLocker (sans TPM pin)
# - Desactivation de HVCI (Hypervisor-Protected Code Integrity)
# - Chargement de drivers kernel non signes
# - Persistence survivant au reformatage
# - Communication C2 via HTTP/HTTPS

Mecanisme de contournement Secure Boot

Le contournement de Secure Boot par BlackLotus repose sur une logique subtile : plutot que de casser la cryptographie ou de modifier les cles Secure Boot, il utilise des binaires legitimement signes par Microsoft mais contenant des vulnerabilites. C'est l'approche "Living off the Land" appliquee au niveau firmware.

Analyse approfondie et recommandations

La vulnerabilite CVE-2022-21894 exploitee par BlackLotus reside dans la facon dont le Boot Configuration Data (BCD) est traite par le gestionnaire de demarrage Windows. Un attaquant peut creer une configuration BCD malveillante qui provoque un debordement de memoire, permettant l'execution de code arbitraire dans le contexte du bootloader, avant que les protections Windows (PatchGuard, DSE, HVCI) ne soient actives. Pour approfondir, consultez Livre Blanc : Sécurisation.

---

4. CosmicStrand et MosaicRegressor

CosmicStrand : Implant firmware materiel

CosmicStrand, decouvert par Kaspersky en juillet 2022, est un implant firmware UEFI attribue a un acteur APT sinophone. Contrairement a BlackLotus qui opere depuis l'ESP, CosmicStrand modifie directement le firmware UEFI stocke dans la flash SPI de la carte mere, le rendant resistant meme a un remplacement du disque dur.

Mecanisme d'infection CosmicStrand :

# Flux d'infection CosmicStrand
# Cible: firmware UEFI des cartes meres ASUS et Gigabyte (chipsets H81)

# 1. Modification du driver DXE dans la flash SPI
#    Le driver CSMCORE (Compatibility Support Module) est patche
#    pour inclure un hook au moment du chargement du kernel Windows

# Structure du firmware infecte:
UEFI Flash SPI (16 MB):
  +-- Intel ME Region (protegee)
  +-- BIOS Region:
      +-- SEC Volume
      +-- PEI Volume
      +-- DXE Volume:
          +-- [Drivers UEFI normaux]
          +-- CSMCORE.efi [MODIFIE]
              +-- Hook installe dans la routine
              +-- de transition vers le bootloader
      +-- NVRAM Volume

# 2. Le hook intercepte le chargement du kernel Windows
#    CosmicStrand se positionne dans la chaine de boot:
#    UEFI DXE -> Hook CosmicStrand -> bootmgfw.efi -> winload.efi -> ntoskrnl.exe

# 3. Injection dans le processus kernel Windows
#    Le hook modifie le kernel en memoire pour:
#    - Desactiver Driver Signature Enforcement (DSE)
#    - Charger un driver malveillant
#    - Injecter un shellcode dans le processus svchost.exe

# 4. Communication C2
#    Le shellcode injecte contacte un serveur C2 via DNS
#    pour telecharger et executer des payloads supplementaires

# Cartes meres affectees (connues):
# - ASUS H81 series
# - Gigabyte H81 series
# - Potentiellement d'autres avec le meme BIOS vendor (AMI)

MosaicRegressor : Cadre d'espionnage firmware

MosaicRegressor, decouvert par Kaspersky en 2020, est le premier implant firmware UEFI decouvert in-the-wild utilise dans des campagnes d'espionnage APT ciblees. Attribue au groupe Winnti/APT41, il ciblait des organisations diplomatiques et des ONG. MosaicRegressor est construit sur le framework Hacking Team VectorEDK, dont le code source a fuite en 2015.

L'implant MosaicRegressor utilise un driver DXE UEFI malveillant qui ecrit un executable Windows malveillant dans le dossier de demarrage Windows a chaque boot. Meme si l'utilisateur supprime le malware et reinstalle Windows, l'implant firmware le recreera au prochain demarrage. Ce mecanisme de persistence est d'une efficacite redoutable car il opere en dessous de toutes les couches de securite du systeme d'exploitation.

Autres menaces firmware documentees

Implant	Decouvert	Attribution	Cible	Methode
LoJax	2018	APT28/Fancy Bear	Gouvernements EU	Flash SPI write
MosaicRegressor	2020	APT41/Winnti	Diplomatie, ONG	DXE driver
FinSpy UEFI	2021	Commercial	Surveillance ciblee	ESP bootloader
ESPecter	2021	Inconnu	Asie du Sud-Est	ESP bootmgfw
CosmicStrand	2022	APT sinophone	Cibles variees	Flash SPI patch
BlackLotus	2023	Cybercriminel	Tout Windows 11	Secure Boot bypass

---

5. Techniques d'Implantation

Ecriture directe dans la flash SPI

L'ecriture directe dans la flash SPI est la methode la plus invasive et la plus persistante. Elle necessite soit un acces physique a la carte mere (via un programmeur SPI), soit l'exploitation d'une vulnerabilite permettant le contournement des protections d'ecriture du chipset : Pour approfondir, consultez Exfiltration furtive (DNS, DoH,.

# Lecture et modification du firmware SPI
# Necessite des privileges Ring 0 (kernel) ou un acces physique

# 1. Lecture du firmware actuel avec CHIPSEC
$ python chipsec_util.py spi dump firmware.bin
[*] SPI Flash Controller Base: 0xFE010000
[*] Flash Region 0 (Flash Descriptor): 0x0 - 0xFFF
[*] Flash Region 1 (BIOS): 0x1000 - 0xFFFFFF
[*] Flash Region 2 (ME): [protected]
[+] Dumped 16 MB to firmware.bin

# 2. Extraction et analyse avec UEFITool
$ UEFIExtract firmware.bin all
[*] Parsing firmware image...
[*] Found 342 DXE drivers
[*] Found 28 PEI modules
[*] NVRAM variables: 156

# 3. Modification du driver DXE cible
# Injection d'un hook dans un driver existant
# ou remplacement par un driver infecte

# 4. Reconstruction et reflash
$ python chipsec_util.py spi write modified_firmware.bin
[WARNING] Flash write protection may be enabled
[*] Writing 16 MB to SPI flash...

# Verification des protections SPI avec CHIPSEC
$ python chipsec_main.py -m common.bios_wp
[*] BIOS write protection (BIOSWE): 0 (protected)
[*] BIOS Lock Enable (BLE): 1 (enabled)
[*] SMM BIOS Write Protection (SMM_BWP): 1 (enabled)
[*] SPI Protected Ranges:
    PR0: 0x00000000 - 0x00000FFF (Flash Descriptor) [Read-Only]
    PR1: 0x00800000 - 0x00FFFFFF (BIOS region) [Read-Only]

# Si les protections sont actives, exploitation necessaire:
# - ThinkPwn (Lenovo, CVE-2016-8222): bypass SMM
# - S3 Resume Script (divers): modification pendant le resume S3
# - RWEverything/RWUtils: acces direct aux ports I/O

Modification de l'ESP (EFI System Partition)

La modification de l'ESP est la methode la plus simple car elle ne necessite pas d'interagir avec la flash SPI. L'ESP est une partition FAT32 standard accessible depuis le systeme d'exploitation avec des privileges administrateur :

# Acces a l'ESP depuis Windows (privileges admin)
mountvol S: /s

# Structure de l'ESP:
S:\EFI\Boot\bootx64.efi           # Bootloader par defaut
S:\EFI\Microsoft\Boot\bootmgfw.efi # Bootloader Windows
S:\EFI\Microsoft\Boot\BCD          # Configuration de boot
S:\EFI\ubuntu\grubx64.efi         # Bootloader Linux (si dual boot)

# Attaque: Remplacement du bootloader
# 1. Sauvegarder l'original
copy S:\EFI\Microsoft\Boot\bootmgfw.efi S:\EFI\Microsoft\Boot\bootmgfw.efi.bak

# 2. Remplacer par un bootloader infecte
# Le bootloader infecte charge l'original apres son execution
copy malicious_boot.efi S:\EFI\Microsoft\Boot\bootmgfw.efi

# Acces a l'ESP depuis Linux
$ sudo mount /dev/sda1 /mnt/esp
$ ls /mnt/esp/EFI/

# Sous Linux, les fichiers EFI peuvent etre modifies directement
# sans contourner de protections specifiques

---

6. Contournement de Secure Boot

Vulnerabilites connues dans les bootloaders signes

Le contournement de Secure Boot ne necessite pas de casser la cryptographie RSA-2048 ou les hashes SHA-256. La strategie principale consiste a exploiter des vulnerabilites dans des bootloaders legitimement signes par Microsoft ou les OEM, qui n'ont pas encore ete revoques dans la base dbx :

• CVE-2022-21894 (Baton Drop) : Vulnerabilite dans bootmgr exploitee par BlackLotus. Permet l'execution de code via une configuration BCD malveillante.
• CVE-2023-24932 : Correctif additionnel pour Secure Boot bypass, mais la revocation dbx complete est prevue pour 2026.
• BootHole (CVE-2020-10713) : Vulnerabilite dans GRUB2 permettant l'execution de code via un fichier grub.cfg malveillant, contournant Secure Boot sur les systemes Linux.
• CVE-2024-7344 : Vulnerabilite dans un composant UEFI signe par Microsoft et utilise par plusieurs fournisseurs, permettant le chargement de code non signe pendant le demarrage.
• shim vulnerabilities : Multiples vulnerabilites dans le shim bootloader utilise par les distributions Linux pour le Secure Boot (CVE-2023-40547 et suivants).

Techniques de contournement alternatives

# Technique 1: Desactivation de Secure Boot depuis l'OS
# Si l'attaquant a un acces kernel, il peut modifier les variables UEFI

# Windows: Modification de la variable SecureBoot via SetFirmwareEnvironmentVariable
# (necessite SE_SYSTEM_ENVIRONMENT_NAME_PRIVILEGE)

# Linux:
$ efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
Value: 0x01  # Secure Boot actif

# Certains firmwares permettent la desactivation via NVRAM sans PK
# C'est une misconfiguration mais elle est frequente

# Technique 2: Ajout d'une cle de confiance dans db
# Si PK est vide ou en mode Setup (premiere installation)
# L'attaquant peut ajouter sa propre cle dans db

$ cert-to-efi-sig-list attacker_cert.pem attacker.esl
$ efi-updatevar -a -c attacker_cert.pem db

# Technique 3: Passage en mode Custom/Setup
# Efface toutes les cles Secure Boot
# Possible physiquement via le menu BIOS ou via NVRAM sur certains firmwares

# Technique 4: Exploitation du fallback boot
# Si le bootloader principal est absent, UEFI cherche:
# \EFI\BOOT\BOOTX64.EFI sur tous les volumes
# Un attaquant peut placer un bootloader infecte a cet emplacement
# sur une cle USB ou un volume supplementaire

---

7. Detection et Remediation

Outils de verification firmware

La detection des implants firmware est un defi majeur car le malware opere en dessous de toutes les couches de securite du systeme d'exploitation. Plusieurs outils et methodes sont disponibles :

Analyse approfondie

# CHIPSEC - Framework Intel pour l'audit firmware
# https://github.com/chipsec/chipsec

# Verification complete des protections firmware
$ python chipsec_main.py
[*] Running module common.bios_wp... PASSED
[*] Running module common.bios_ts... WARNING
[*] Running module common.spi_lock... PASSED
[*] Running module common.secureboot.variables... PASSED
[*] Running module common.uefi.s3bootscript... WARNING
[*] Running module tools.uefi.whitelist... FAILED

# Verification de l'integrite du firmware
$ python chipsec_util.py spi dump current_fw.bin
$ python chipsec_main.py -m tools.uefi.whitelist \
    -a check,current_fw.bin,golden_fw.bin

# UEFITool - Analyse et edition de firmware UEFI
# Permet l'extraction et l'analyse de chaque module DXE/PEI
# Detection de modules inconnus ou modifies

# LVFS/fwupd - Linux Vendor Firmware Service
$ fwupdmgr get-devices
$ fwupdmgr security --force
  Host Security ID: HSI:3
  UEFI Secure Boot: Enabled
  TPM 2.0: Found
  Intel BootGuard: Verified
  SPI Write Protection: Locked
  UEFI PK: Valid

# Microsoft Defender System Guard
# Verification d'integrite du boot via attestation TPM
# Disponible dans Windows Security > Device Security

Detection des bootkits ESP

# Script de verification de l'ESP (PowerShell)
# Detection des modifications suspectes

# Monter l'ESP
mountvol S: /s

# Verifier l'integrite des bootloaders
$bootmgfw = Get-FileHash "S:\EFI\Microsoft\Boot\bootmgfw.efi" -Algorithm SHA256
$known_good_hashes = @(
    "ABC123...",  # Windows 11 23H2
    "DEF456...",  # Windows 11 24H2
)

if ($bootmgfw.Hash -notin $known_good_hashes) {
    Write-Warning "ALERTE: bootmgfw.efi hash inconnu!"
    Write-Warning "Hash: $($bootmgfw.Hash)"
}

# Lister tous les fichiers EFI pour detection de fichiers suspects
Get-ChildItem -Path "S:\" -Recurse -Include "*.efi" |
    ForEach-Object {
        [PSCustomObject]@{
            Path = $_.FullName
            Size = $_.Length
            Hash = (Get-FileHash $_.FullName -Algorithm SHA256).Hash
            Modified = $_.LastWriteTime
            Signed = (Get-AuthenticodeSignature $_.FullName).Status
        }
    } | Format-Table -AutoSize

# Verifier la configuration BCD
bcdedit /enum all | Select-String -Pattern "path|description|device"

# Indicateurs de compromission BlackLotus:
# - Fichier grubx64.efi dans \EFI\Microsoft\Boot\ (absent normalement)
# - BCD modifie pointant vers un bootloader non standard
# - Fichiers .efi recents dans l'ESP avec timestamp suspect
# - bootmgfw.efi avec un hash ne correspondant pas a la version Windows installee

Strategies de remediation

---

Pour approfondir ce sujet, consultez notre outil open-source security-automation-framework qui facilite l'automatisation des workflows de sécurité.

Questions frequentes

8. Conclusion

Les menaces firmware representent un changement de référence dans l'écosystème de la cybersecurite. L'emergence de BlackLotus comme premier bootkit UEFI grand public capable de contourner Secure Boot marque la democratisation de capacites offensives auparavant reservees aux acteurs etatiques les plus avancés. Combine avec les implants CosmicStrand et MosaicRegressor, il est clair que la couche firmware est devenue un champ de bataille actif.

La complexite de la remediation des implants firmware, la lenteur des processus de revocation dbx, et la difficulte de detection en dessous du systeme d'exploitation rendent ces menaces particulierement dangereuses. Les organisations doivent adopter une approche proactive : verification reguliere de l'integrite firmware avec des outils comme CHIPSEC et fwupd, activation de toutes les protections disponibles (Secure Boot, Boot Guard, TPM), et integration du monitoring firmware dans les processus SOC existants.

L'avenir de la securite firmware repose sur l'adoption generalisee des mecanismes de verification materielle (Boot Guard, PSB, DRTM), la modernisation des processus de mise a jour et de revocation Secure Boot, et le developpement de solutions de detection firmware deployables a l'echelle de l'entreprise. Les equipes de securite doivent des maintenant integrer la dimension firmware dans leurs evaluations de risques et leurs plans de reponse aux incidents.

Partagez cet Article

Cet article vous a ete utile ? Partagez-le avec votre reseau professionnel !

Partager sur X Partager sur LinkedIn Copier le Lien