Monitoraggio e aggiornamento di Catalyst SD-WAN Security Advisory - Giugno 2026

Introduzione

Questo documento descrive i passaggi per identificare e affrontare le vulnerabilità critiche della sicurezza in SD-WAN in base ai consigli PSIRT del 4 e 15 giugno 2026.

---

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Componenti di controllo e architettura SD-WAN Cisco Catalyst (vManage, vSmart, vBond)
• Procedura di aggiornamento di Cisco Catalyst SD-WAN
• Procedure di gestione dei casi TAC e raccolta di dati admin-tech Cisco

Componenti usati

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

---

Premesse

Per informazioni dettagliate e gli ultimi aggiornamenti, consultare la pagina ufficiale di consulenza PSIRT.

Queste avvertenze sono disponibili ai seguenti link:

• Vulnerabilità dell'escalation dei privilegi autenticati del controller Cisco Catalyst SD-WAN, del gestore Catalyst SD-WAN e del validatore Catalyst SD-WAN
• Vulnerabilità arbitraria di scrittura dei file di Cisco Catalyst SD-WAN Manager

I seguenti problemi sono risolti dai consigli PSIRT:

• ID bug Cisco CSCwu18563
• ID bug Cisco CSCwu1841

---

Panoramica sul flusso di lavoro di risoluzione

Questi avvisi descrivono due vulnerabilità in Cisco Catalyst SD-WAN. Il primo (CVE-2026-20245) è una vulnerabilità di escalation dei privilegi nei componenti di controllo SD-WAN che richiede privilegi di netadmin da sfruttare. Il secondo (CVE-2026-20262) è una vulnerabilità arbitraria di scrittura dei file in SD-WAN Manager (vManage) che consente a un utente autenticato di creare o sovrascrivere qualsiasi file sul file system di un sistema interessato.

Sia per CVE-2026-20245 che per CVE-2026-20262, i percorsi noti per un utente malintenzionato remoto non autenticato per ottenere le credenziali richieste sono lo sfruttamento di CVE-2026-20182 (cisco-sa-sdwan-rpa2-v69WY2SW) o CVE-2026-20127 (cisco-sa-sdwan-rpa-EHchtZk). CVE-2026-20245 richiede privilegi di amministratore di rete per l'utilizzo, mentre CVE-2026-20262 richiede almeno un account utente con singolo task con privilegi inferiori.

Se i componenti di controllo sono stati aggiornati a una versione fissa per entrambi gli admin-tech e Cisco non ha identificato alcun potenziale indicatore di compromissione (IoC) nei file admin-tech forniti per gli eventi precedenti, i percorsi di utilizzo non autenticati noti per CVE-2026-20245 e CVE-2026-20262 vengono ridotti su tali dispositivi specifici, in base ai file esaminati. Ciò non elimina l'esposizione quando un utente malintenzionato possiede credenziali valide. Cisco consiglia di eseguire l'aggiornamento a una versione fissa per entrambi gli advisory.

Azione richiesta: aprire una richiesta Cisco TAC per risolvere i problemi relativi alla sicurezza.

Il TAC è disponibile per:

• Valutare l'ambiente per individuare eventuali indicatori di compromissione
• Guida l'utente attraverso il percorso di correzione appropriato in base alla valutazione
• Fornire orientamenti sulle prossime misure da adottare qualora siano individuati indicatori di compromesso

1. Collect Admin-Techs- Eseguire admin-tech su tutti i componenti di controllo (vSmart, vManage, vBond). Gli admin-tech vSmart non devono essere eseguiti simultaneamente, ovvero eseguiti uno alla volta. Tutti gli altri possono essere raccolti in qualsiasi ordine. Selezionare le opzioni Log and Tech.  Core non è richiesto.
2. Apri una richiesta TAC - Contatta Cisco TAC e fornisci tutti i pacchetti di log Admin-tech per i componenti di controllo.
3. Valutazione TAC: TAC esegue una valutazione preliminare degli indicatori di compromissione nell'ambiente in uso sulla base dei file admin-tech forniti.
4. Esegui correzione: completare la procedura specifica fornita da TAC, se necessario.

---

Passaggio 1: Raccolta dei file Admin-Tech da tutti i componenti di controllo

Obbligatorio: Raccogliere i file admin-tech da tutti i componenti di controllo prima di qualsiasi aggiornamento o modifica della configurazione, in modo da preservare i dati diagnostici e gli eventuali indicatori di compromissione (IoC). Questi file vengono utilizzati da TAC nel passaggio 3 per analizzare l'ambiente.

Raccolta: per la generazione admin-tech, selezionare le opzioni Log and Tech. Core non è richiesto.

1. Esecuzione di admin-tech su TUTTI i controller (vSmarts): non eseguirli simultaneamente; raccogli uno alla volta
2. Esegui admin-tech su TUTTI i manager (vManage)
3. Esegui admin-tech su TUTTE le convalide (vBonds)

Raccolta di informazioni su Admin-Tech in un ambiente SD-WAN e caricamento in una richiesta TAC

Alternativa: Verifica manuale (solo se non è possibile raccogliere dati relativi all'amministrazione tecnica)

Se non è possibile condividere i file admin-tech, è disponibile un passaggio di verifica manuale. Questa procedura fornisce un indicatore preliminare che deve essere documentato e condiviso con il TAC.

Per una procedura dettagliata, vedere la sezione Fasi della verifica manuale alla fine di questo documento. Documentare tutti i risultati e fornirli a TAC nella richiesta di assistenza.

---

Passaggio 2: Apri una richiesta TAC e carica i file Admin-Tech

Dopo aver raccolto i dati tecnici per l'amministratore nel passaggio 1, aprire una richiesta di assistenza in Cisco TAC e caricare i file tecnici per l'amministratore raccolti. TAC analizza gli admin-tech per gli indicatori di compromissione associati a entrambi i consigli (CVE-2026-20245 e CVE-2026-20262).

Azioni richieste:

1. Aprire una richiesta TAC di gravità 3 con "CVE-2026-20245, CVE-2026-20262" e gli advisory ID cisco-sa-sdwan-privesc-4uxFrdzx e cisco-sa-sdwan-arbfw-c2rZvQ nel titolo per avviare l'analisi.
2. Caricare TUTTI i bundle di log admin-tech raccolti nel Passo 1 (Controller, Manager e Convalide).
3. Attendere il completamento dell'analisi da parte di TAC e comunicare i risultati.

Passaggio 3: Valutazione TAC

TAC esegue un'analisi preliminare dei file admin-tech caricati nella Fase 2 e li valuta per individuare eventuali indicatori di compromesso associati a entrambi gli avvisi (CVE-2026-20245 e CVE-2026-20262).

Per l'advisory CVE-2026-20245, l'analisi è incentrata su una voce di log specifica in /var/log/scripts.log su ciascun componente di controllo (vManage, vSmart e vBond). Poiché il comando sottostante è legittimo e il registro non distingue tra utilizzo legittimo e dannoso, tutte le voci corrispondenti richiedono una revisione manuale di TAC rispetto alla normale postura operativa prima di essere trattate come un indicatore confermato.

Per l'advisory CVE-2026-20262, l'analisi è incentrata su diversi file nella directory /var/log/nms di ciascun Manager (vManage). In alcuni casi, questi indicatori di compromissione possono verificarsi durante le operazioni standard. 

Tali registri non distinguono tra uso legittimo e uso dannoso; pertanto, qualsiasi voce corrispondente richiede una revisione manuale del TAC rispetto alla normale postura operativa prima di essere trattata come un indicatore confermato.

Possibili risultati dell'analisi TAC:

• Non sono state identificate voci di log corrispondenti: in base ai file admin-tech esaminati, non sono stati osservati indicatori associati ad alcuno degli advisory. Al momento non sono necessarie ulteriori azioni specifiche per questi consigli. Il risultato è limitato ai file admin-tech ricevuti ed è soggetto al periodo di conservazione dei log su ciascun dispositivo.
• Voci del log corrispondenti identificate: TAC richiede all'utente ulteriori passaggi di revisione. Per entrambi gli advisory, si consiglia l'aggiornamento a una release fissa. Data la natura dei pareri, possono essere necessarie anche azioni supplementari. Le linee guida di TAC per scenari di compromissione confermati sono documentate negli articoli correlati della TechZone di cui alla fase 4.

Passaggio 4: Se vengono individuati indicatori di compromissione: conformità alle linee guida TAC

Se TAC identifica indicatori di compromissione associati a tali avvertenze nell'ambiente, TAC contatta l'utente con indicazioni specifiche. Completare tutte le istruzioni fornite da TAC.

Se non vengono individuati indicatori di compromissione per nessuno dei due tipi di consulenza, al momento non è necessaria alcuna ulteriore azione specifica per la valutazione di compromesso, in base ai file admin-tech esaminati. Si consiglia comunque di eseguire l'aggiornamento a una versione fissa per entrambi gli advisory.

---

Versioni software fisse

Queste versioni software contengono correzioni per le vulnerabilità identificate:

Si applica alle versioni correnti	Versione corretta	Software disponibile
20.9.9.1 e precedenti	20.9.9.2	20.9.9.2 aggiornamento delle immagini per vManage, vSmart e vBond
20.12.7.1 e precedenti	20.12.7.2	20.12.7.2 aggiornamento delle immagini per vManage, vSmart e vBond
20.15.4.4 e precedenti	20.15.4.5	20.15.4.5 immagini di aggiornamento per vManage, vSmart e vBond
20.15.5.2 e precedenti	20.15.5.3	20.15.5.3 immagini di aggiornamento per vManage, vSmart e vBond
20.16, 20.17, 20.18.x	20.18.3.1	20.18.3.1 immagini di aggiornamento per vManage, vSmart e vBond
26.1	26.1.1.2	26.1.1.2 aggiornamento delle immagini per vManage, vSmart e vBond

Riferimenti importanti:

• Matrice di aggiornamento
• Matrice di compatibilità dei controller
• Monitoraggio e aggiornamento di Catalyst SD-WAN Security Advisory - Maggio 2026
• Remediate Catalyst SD-WAN Security Advisory — Febbraio 2026
• Vulnerabilità del bypass di autenticazione del controller SD-WAN Cisco Catalyst (14 maggio 2026)

---

Considerazioni

Al termine di un monitoraggio e aggiornamento riusciti, e in base ai tuoi requisiti di sicurezza specifici, Cisco consiglia di valutare e adottare le misure appropriate per le attività igieniche elencate qui. Queste attività si applicano indipendentemente dall'opzione di correzione selezionata. sono gestiti dall'utente; Cisco non li dirige né li esegue per conto dell'utente.

• Verifica di tutti gli account utente locali
• Rotazione delle credenziali
• Rotazione di eventuali segreti presenti nelle configurazioni dei dispositivi, ad esempio (elenco non esaustivo):
  • Credenziali per gli account utente locali
  • Stringhe della community SNMP
  • Chiavi segrete TACACS
  • Chiavi e certificati VPN precondivisi
  • Chiavi SSH attendibili
• Revisione dei modelli di configurazione

Dispositivi perimetrali — Possibile compromissione

Cisco sconsiglia di specificare un percorso di ripristino; la scelta di un'opzione di risanamento spetta a ciascun cliente. 

Il comando corretto per eseguire un ripristino sicuro in fabbrica è:

factory-reset all secure

---

Appendice: Fasi di verifica manuale (solo se la raccolta di dati Admin-Tech non è possibile)

Verifica per CVE-2026-20245: Controllare scripts.log su ciascun componente di controllo per le voci di caricamento file

In base all'advisory PSIRT, gli utenti sono incoraggiati a controllare i file di log per le voci simili a quella riportata nell'esempio. Nella release 20.9 e successive, questa voce si trova in scripts.log at /var/log/. Nelle versioni precedenti alla 20.9, i dati equivalenti sono contenuti nei log di debug in /var/log/tmplog/:

Apr 15 09:44:57 vmanage vScript: Tenant list upload per vsmart serial number: /usr/bin/vconfd_script_upload_tenant_list.sh -cli path /home/admin/malicious.csv vpn 0

Passaggio 1: Accedere alla shell su ciascun componente di controllo e cercare gli indicatori CVE-2026-20245 nei file di registro appropriati

La posizione del file di log dipende dalla versione del software in esecuzione sul componente di controllo. Prima di eseguire la ricerca, determinare quale sia la soluzione più appropriata per il proprio ambiente.

Release 20.9 e successive — Search scripts.log in /var/log/tmplog/:

Dalla CLI di vManage, accedere alla shell ed eseguire:

vs
zgrep "vconfd_script_upload_tenant_list.sh" /var/log/scripts.log*

Release precedenti alla 20.9 — Search vdebug logs in /var/log/tmplog/:

Nelle versioni precedenti alla 20.9, scripts.log non è presente. I dati log equivalenti vengono scritti in /var/log/tmplog/vdebug. Vengono conservati fino a cinque file numerati progressivi (vdebug, vdebug.1 fino a vdebug.5). Cerca in tutti i file attivi con:

vs
zgrep "vconfd_script_upload_tenant_list.sh" /var/log/tmplog/vdebug*

Oltre ai file attivi, i log meno recenti vengono archiviati come file tar compressi in /var/log/ utilizzando il modello di denominazione vdebug_<timestamp>.tar.gz, con i dati di log archiviati nell'archivio in var/log/tmplog. Cerca in tutti gli archivi con:

for f in /var/log/vdebug_*.tar.gz; do echo "=== $f ==="; tar -xOf "$f" var/log/tmplog 2>/dev/null | grep "vconfd_script_upload_tenant_list.sh"; done

Ripetere tutti i controlli applicabili su ogni componente di controllo nella distribuzione (inclusi tutti i membri del cluster e gli eventuali vManage abbinati a DR).

Passaggio 2: Interpreta risultati e documento per TAC

Se NON vengono restituite voci corrispondenti:

• Nel file di log del dispositivo non sono stati rilevati indicatori di compromissione associati all'avviso.
• Documentare questo risultato per la richiesta TAC (includere il nome host del dispositivo e la data/intervallo dei file di registro cercati).
• Continuare il controllo sui manager rimanenti.

Se vengono restituite voci corrispondenti:

• Ogni voce corrispondente deve essere verificata rispetto alla normale postura operativa. Il comando sottostante (caricamento dell'elenco dei tenant) è legittimo e viene visualizzato durante le operazioni di routine.
• Per ogni voce corrispondente, acquisire il timestamp, la riga di log completa e il percorso del file a cui si fa riferimento dopo il percorso della riga successiva.
• Se una voce corrispondente non può essere riconciliata con un'operazione nota e legittima, questo è un potenziale indicatore di compromissione. Documentare il risultato e inviarlo a TAC per la revisione.
• Documentazione di tutti i risultati e apertura di una richiesta TAC. Includere le voci di log corrispondenti e l'output del comando source nel caso specifico.
• TAC esegue la valutazione ufficiale. Se la valutazione identifica indicatori di compromissione, fare riferimento al flusso descritto nei documenti correlati di TechZone: e guide ai rimedi.

Verifica per CVE-2026-20262: Verifica la presenza di voci di scrittura arbitrarie nei file di log di ogni manager (vManage)

In base all'advisory PSIRT, gli utenti sono incoraggiati a controllare questi file di log su ciascun manager (vManage) per le voci simili a quelle riportate negli esempi seguenti:

Esempio di voce sospetta in manage-server.log (in /var/log/nms/)

11-June-2026 03:53:37,310 EDT INFO  [a66cdc5f-807d-4c23-944e-5c809a2ece6b] [server] [SdraAnyConnectFileUploadHandler] (default task-40704) |default| uploaded Remote Access Anyconnect profile file: ../../../../var/lib/wildfly/standalone/deployments/suspicious.war to vManage.

Esempio di voce sospetta in manage-appserver.log (in /var/log/nms/)

11-June-2026 07:52:55,275 UTC INFO  [server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "suspicious.war" (runtime-name : "suspicious.war")

Esempio di voce sospetta in serviceproxy-access.log (disponibile in /var/log/nms/containers/service-proxy/)

POST /suspicious/index.jsp HTTP/1.1

Passaggio 1: Accedere a vshell su ciascun Manager (vManage) ed eseguire una ricerca nei file di log

Dalla CLI di vManage, accedere alla shell ed eseguire:

vs
zgrep "SdraAnyConnectFileUploadHandler" /var/log/nms/vmanage-server.log*
zgrep "WFLYSRV0010" /var/log/nms/vmanage-appserver.log*

In alcune versioni, il log del proxy di servizio è accessibile direttamente da vshell. Nelle versioni in cui è richiesto l'accesso alla shell radice, scaricare admin-tech e cercare i file serviceproxy-access.log al suo interno nello stesso modo usando un comando simile a:

Release 20.9 e successive:

tar -xOf .tar.gz var/log/nms/containers/service-proxy/serviceproxy-access.log 2>/dev/null | grep "suspicious"

Versioni precedenti alla 20.9:

tar -xOf .tar.gz var/log/nms/serverproxy-access.log 2>/dev/null | grep "suspicious"

Se si accede direttamente da vshell, utilizzare il nome file .war identificato dai risultati dei due comandi precedenti (senza l'estensione) al posto di suspicious: (sospetto):

Release 20.9 e successive:

zgrep "POST" /var/log/nms/containers/service-proxy/serviceproxy-access.log* | grep "suspicious"

Versioni precedenti alla 20.9:

zgrep "POST" /var/log/nms/serverproxy-access.log* | grep "suspicious"

Ripetere il controllo su ogni vManage della distribuzione (inclusi tutti i membri del cluster e gli eventuali vManage associati a DR).

Passaggio 2: Interpreta risultati e documento per TAC

Se NON vengono restituite voci corrispondenti:

• Nei file di log del dispositivo non sono stati rilevati indicatori di compromissione associati all'avviso.
• Documentare questo risultato per la richiesta TAC (includere il nome host del dispositivo e la data/intervallo dei file di registro cercati).
• Continuare il controllo sui manager rimanenti.

Se vengono restituite voci corrispondenti:

• Ogni voce corrispondente deve essere verificata rispetto alla normale postura operativa. Queste voci possono essere inserite durante le operazioni standard e non confermano da sole i compromessi.
• Per ogni voce corrispondente in manage-server.log, acquisire il timestamp, la riga di log completa e il percorso del file a cui si fa riferimento nel gestore di caricamento.
• Se una voce corrispondente non può essere riconciliata con un'operazione nota e legittima, questo è un potenziale indicatore di compromissione. Documentare il risultato e inviarlo a TAC per la revisione.
• Documentazione di tutti i risultati e apertura di una richiesta TAC. Includere le voci di log corrispondenti e l'output del comando source nel caso specifico.
• TAC esegue la valutazione ufficiale. Se la valutazione identifica indicatori di compromissione, fare riferimento al flusso descritto nei documenti correlati di TechZone: e guide ai rimedi.

---

Domande frequenti

Q: Qual è il primo passo per risolvere questi problemi relativi alla sicurezza?

A: Raccogliere i file admin-tech da tutti i componenti di controllo (vSmart, vManage, vBond) prima di qualsiasi aggiornamento o modifica della configurazione per preservare i dati di diagnostica e qualsiasi potenziale indicatore di compromissione. Quindi, aprire una richiesta Cisco TAC e caricare gli admin-tech in modo che TAC possa analizzarli.

Q: Cisco ha rilasciato una correzione software per queste vulnerabilità?

A: Sì, le versioni fisse sono disponibili per entrambi gli advisory, come indicato nella sezione Versioni software fisse. Non sono disponibili soluzioni alternative.

Q: Perché Cisco consiglia di intraprendere altre azioni oltre all'aggiornamento?

A: Lo sfruttamento di queste vulnerabilità richiede un utente autenticato. Un utente non autenticato può ottenere queste credenziali solo attraverso credenziali valide o attraverso lo sfruttamento di CVE-2026-20182 o CVE-2026-20127. Garantendo che i componenti di controllo siano aggiornati alle versioni fisse per tali avvisi precedenti indirizzi i percorsi non autenticati noti per ottenere i privilegi necessari per sfruttare queste vulnerabilità. L'analisi admin-tech nella Fase 3 aiuta a determinare se vi sono indicatori di compromissione nei file esaminati.

Q: È necessario raccogliere gli admin-tech da tutti i componenti di controllo?

A: Sì. TAC richiede file admin-tech da tutti i controller (vSmart, raccolti uno alla volta), da tutti i manager (vManage) e da tutti i validatori (vBond) per eseguire l'analisi.

Q: In che modo TAC determina se il sistema dispone di indicatori di compromesso associati a questi consigli?

A: TAC esamina i file admin-tech per individuare gli indicatori di compromissione specifici di ciascun advisory. Per Privilege Escalation advisory (CVE-2026-20245), TAC cerca le voci di log specifiche in /var/log/scripts.log su ciascun componente di controllo. Per l'advisory della scrittura di file arbitrari (CVE-2026-20262), TAC cerca voci di log specifiche in tre file di log su ciascun Manager: /var/log/nms/vmanage-server.log, /var/log/nms/vmanage-appserver.log e /var/log/nms/containers/service-proxy/serviceproxy-access.log. In entrambi i casi, l'attività sottostante può verificarsi durante le operazioni standard; tutte le voci corrispondenti vengono esaminate da TAC rispetto alla normale postura operativa prima di essere trattate come un indicatore confermato.

Q: Cosa succede se vengono individuati indicatori di compromesso?

A: TAC contatta l'utente con indicazioni specifiche. L'aggiornamento da solo non risolve un compromesso confermato. Le linee guida del TAC si basano sul flusso documentato negli articoli relativi alla TechZone per i pareri del maggio 2026 e del febbraio 2026.

Q: I router perimetrali (Cisco IOS XE) sono interessati da queste avvertenze?

A: Questi avvisi riguardano principalmente i componenti di controllo Cisco Catalyst SD-WAN. Per l'advisory dell'escalation dei privilegi (CVE-2026-20245), sono interessati tutti i componenti di controllo (vManage, vSmart, vBond) e Cisco ha osservato casi limitati in cui lo sfruttamento ha determinato il push di una modifica della configurazione ai dispositivi periferici; gli utenti sono invitati a verificare la configurazione dei propri dispositivi edge. Per l'arbitrary file write advisory (CVE-2026-20262), la vulnerabilità è limitata al file system SD-WAN Manager e non influisce direttamente sui dispositivi periferici.

Q: Quali tipi di distribuzione sono interessati?

A: In base a questi avvisi, queste vulnerabilità influiscono su tutti i tipi di installazione di Cisco Catalyst SD-WAN indipendentemente dalla configurazione del dispositivo, inclusa l'installazione locale, Cisco SD-WAN Cloud-Pro, Cisco SD-WAN Cloud (Cisco Managed) e Cisco SD-WAN per enti pubblici (FedRAMP).

Q: Ho già effettuato l'aggiornamento per i consigli di maggio 2026 e febbraio 2026 e non sono stati identificati indicatori di compromesso per tali eventi. Sono esposto a queste nuove vulnerabilità?

A: Se i componenti di controllo eseguono una versione fissa sia per CVE-2026-20182 che per CVE-2026-20127 e non sono stati identificati indicatori di compromissione per gli eventi precedenti nei file admin-tech esaminati, i percorsi di utilizzo noti non autenticati per CVE-2026-20245 e CVE-2026-20262 vengono ridotti su tali dispositivi specifici, in base ai file esaminati. Ciò non elimina l'esposizione quando un utente malintenzionato possiede credenziali valide. Cisco consiglia di eseguire l'aggiornamento a una versione fissa per questi avvisi.

Q: È possibile eseguire personalmente la verifica anziché attendere il TAC?

A: Gli utenti che non possono condividere gli admin-tech possono eseguire la procedura di verifica manuale descritta nell'Appendice. Il risultato è preliminare; documenta i risultati e li condivide con TAC, che effettua la valutazione ufficiale.

Q: Quali sono le best practice generali per rafforzare la mia sovrapposizione SD-WAN?

A: Per le best practice, consultare la guida alla protezione avanzata di Cisco Catalyst SD-WAN.

Q: Cisco TAC fornisce servizi di analisi forense o di indagine per queste vulnerabilità?

A: Cisco TAC può assistere gli utenti revisionando i file admin-tech per gli indicatori di compromesso documentati in entrambi gli avvisi PSIRT. Cisco TAC non esegue analisi forensi approfondite o indagini sugli incidenti. Per un lavoro legale completo o per indagini dettagliate sulla sicurezza, gli utenti sono incoraggiati a rivolgersi alla società di terze parti preferita per la gestione degli incidenti.