Verificare la conformità di un server MCP al CIS
Cyberwatch valuta la conformità dei server MCP (Model Context Protocol) al CIS MCP Server Benchmark v1.0.0, pubblicato dal CIS a settembre 2026.
Le 55 raccomandazioni del benchmark sono disponibili sotto forma di regole di conformità. Sedici di esse vengono verificate automaticamente a partire dall’audit quotidiano del server. Le altre riguardano il client, l’hosting o l’organizzazione, e vanno verificate manualmente.
Creare il target MCP
La conformità si valuta su un asset di tipo server MCP. Per crearlo, aggiungere un target di rete di tipo «Server MCP», indicando l’URL esatto del suo endpoint.
L’asset riceve il sistema operativo «MCP Server», al quale si applicano le regole del benchmark.
Associare i framework
Un nuovo target MCP riceve d’ufficio il framework CIS_Benchmark_level_1, che raggruppa le 39 raccomandazioni di livello 1.
Per valutare anche le 16 raccomandazioni di livello 2, aggiungere il framework CIS_Benchmark_level_2, oppure CIS_Benchmark, che raggruppa entrambi i livelli. Questi framework sono presenti per impostazione predefinita in Cyberwatch.
Funzionamento della valutazione
Le regole valutano i fatti rilevati dall’ultimo audit del server MCP, senza inviare nuove richieste al server. La valutazione viene rieseguita dopo ogni audit il cui risultato cambia, e almeno ogni 30 giorni.
Ogni regola automatica raggruppa più controlli. Il suo output, visibile nella scheda «Conformità» dell’asset, li dettaglia uno per riga, con il relativo verdetto e la relativa constatazione:
- un controllo è conforme, non conforme, o non valutato quando l’audit non consente di concludere
- la regola è nello stato Non superato non appena uno dei suoi controlli è non conforme
- è nello stato Successo se almeno un controllo è conforme e nessuno è non conforme
- altrimenti, è nello stato Saltata
L’output della regola ricorda anche ciò che resta da verificare manualmente, ad esempio nei log del server.
Raccomandazioni verificate automaticamente
| Regola | Livello | Controlli |
|---|---|---|
| CIS-MCP-1.1 | 1 | Il server non serve alcuna revisione del protocollo precedente a 2025-06-18, e rifiuta una richiesta la cui versione è sconosciuta, assente, o diversa tra l’intestazione MCP-Protocol-Version e il corpo |
| CIS-MCP-1.4 | 1 | Il server dichiara il proprio nome e la propria versione (serverInfo) |
| CIS-MCP-2.2 | 1 | Il server rifiuta l’HTTP in chiaro o lo reindirizza verso HTTPS, negozia TLS 1.2 o 1.3, rifiuta TLS 1.0 e 1.1, e presenta un certificato valido |
| CIS-MCP-2.3 | 2 | Una richiesta anonima viene rifiutata (HTTP 401 o 403) |
| CIS-MCP-2.4 | 1 | Una richiesta senza intestazione Mcp-Method viene rifiutata (HTTP 400, errore JSON-RPC -32020) |
| CIS-MCP-2.5 | 1 | Una richiesta la cui intestazione Origin designa un sito terzo viene rifiutata (HTTP 403) |
| CIS-MCP-3.1.2 | 1 | Una richiesta anonima viene rifiutata con HTTP 401, e il token JWT del target è valido al massimo un’ora; un token valido più a lungo è da rivedere |
| CIS-MCP-3.2.2 | 1 | L’audience del token JWT del target designa questo server; un’audience estranea è da rivedere |
| CIS-MCP-3.3.1 | 1 | L’audience del token JWT del target designa questo server; un’audience estranea è non conforme |
| CIS-MCP-3.3.2 | 2 | I metadati OAuth sono serviti in HTTPS, designano l’endpoint come risorsa, annunciano almeno un server di autorizzazione, e l’issuer di ciascuno corrisponde al suo indirizzo |
| CIS-MCP-5.1.1 | 1 | Gli schemi di input e di output di ogni tool sono schemi JSON validi |
| CIS-MCP-5.1.2 | 1 | Ogni template di resource dichiara il proprio tipo MIME |
| CIS-MCP-5.1.3 | 1 | Ogni argomento di prompt ha un nome, e il suo eventuale attributo required è un booleano |
| CIS-MCP-5.2.3 | 1 | Il server rifiuta le richieste GET e DELETE (HTTP 405) e non emette alcuna intestazione Mcp-Session-Id |
| CIS-MCP-7.1.2 | 1 | Una richiesta il cui identificativo JSON-RPC è null viene rifiutata (HTTP 400, errore JSON-RPC -32600) |
| CIS-MCP-10.1 | 1 | La risposta a tools/list riporta Cache-Control: no-store o private |
Le regole 5.1.1, 5.1.2 e 5.1.3 producono una riga per tool, template o prompt, e la regola 3.3.2 una riga per server di autorizzazione. La regola 3.3.2 non è applicabile a un server che non pubblica metadati OAuth e non richiede autenticazione.
Le intestazioni Mcp-Method e le sessioni stateless esistono solo a partire dalla revisione 2026-07-28 del protocollo: su un server meno recente, i controlli corrispondenti sono non valutati, e le regole 2.4 e 5.2.3 sono nello stato Saltata.
Token JWT del target
Le regole 3.1.2, 3.2.2 e 3.3.1 leggono il token configurato nell’autenticazione HTTP Bearer del target, se si tratta di un JWT. Cyberwatch decodifica localmente la sua audience (aud) e la sua durata di validità (iat, exp), senza verificarne la firma né trasmetterlo ad altri che al server sottoposto ad audit.
Senza token JWT, ad esempio con un token opaco, questi controlli sono non valutati.
Raccomandazioni da verificare manualmente
Le altre 39 raccomandazioni non possono essere verificate da un audit remoto dell’endpoint. Riguardano in particolare:
- il client e l’host MCP (sezione 4 del benchmark)
- i server locali in stdio
- i dati trattati dal server (sezione 6)
- la sua supply chain (sezione 8) e il suo isolamento (sezione 9)
- i suoi log
- elenchi approvati specifici della propria organizzazione, ad esempio le capability o i tool autorizzati
- controlli che richiederebbero di chiamare un tool, leggere una resource o ottenere un prompt
Queste regole sono nello stato Saltata, con la dicitura «Manual verification required» seguita dal motivo. La scheda di ogni regola riporta la procedura di audit del CIS.
Una volta verificata una raccomandazione, è possibile ignorare la regola e commentare questa scelta.