Verificar la conformitat d’un servidor MCP amb el CIS
Cyberwatch avalua la conformitat dels servidors MCP (Model Context Protocol) amb el CIS MCP Server Benchmark v1.0.0, publicat pel CIS el setembre del 2026.
Les 55 recomanacions del benchmark estan disponibles en forma de regles de conformitat. Setze d’aquestes es verifiquen automàticament a partir de l’auditoria diària del servidor. La resta depenen del client, de l’allotjament o de l’organització, i s’han de verificar manualment.
Crear l’objectiu MCP
La conformitat s’avalua en un actiu de tipus servidor MCP. Per crear-lo, afegiu un objectiu de xarxa de tipus «Servidor MCP» i indiqueu l’URL exacta del seu punt final (endpoint).
L’actiu rep el sistema operatiu «MCP Server», al qual s’apliquen les regles del benchmark.
Associar els marcs de conformitat
Un objectiu MCP nou rep automàticament el marc de conformitat CIS_Benchmark_level_1, que agrupa les 39 recomanacions de nivell 1.
Per avaluar també les 16 recomanacions de nivell 2, afegiu el marc de conformitat CIS_Benchmark_level_2, o bé CIS_Benchmark, que agrupa els dos nivells. Aquests marcs de conformitat són presents per defecte a Cyberwatch.
Funcionament de l’avaluació
Les regles avaluen els fets recollits per l’última auditoria del servidor MCP, sense enviar cap sol·licitud nova al servidor. L’avaluació es torna a executar després de cada auditoria amb un resultat diferent, i com a mínim cada 30 dies.
Cada regla automàtica agrupa diversos controls. La seva sortida, visible a la pestanya «Conformitat» de l’actiu, els detalla un per línia, amb el seu veredicte i la seva constatació:
- un control és conforme, no conforme, o no avaluat quan l’auditoria no permet arribar a cap conclusió
- la regla està en l’estat Fallada tan bon punt un dels seus controls no és conforme
- està en l’estat Èxit si almenys un control és conforme i no n’hi ha cap de no conforme
- si no, està en l’estat Omesa
La sortida de la regla també recorda què queda per verificar manualment, per exemple als registres del servidor.
Recomanacions verificades automàticament
| Regla | Nivell | Controls |
|---|---|---|
| CIS-MCP-1.1 | 1 | El servidor no serveix cap revisió del protocol anterior a 2025-06-18, i rebutja una sol·licitud amb una versió desconeguda, absent o diferent entre la capçalera MCP-Protocol-Version i el cos |
| CIS-MCP-1.4 | 1 | El servidor declara el seu nom i la seva versió (serverInfo) |
| CIS-MCP-2.2 | 1 | El servidor rebutja l’HTTP sense xifrar o el redirigeix cap a HTTPS, negocia TLS 1.2 o 1.3, rebutja TLS 1.0 i 1.1, i presenta un certificat vàlid |
| CIS-MCP-2.3 | 2 | Es rebutja una sol·licitud anònima (HTTP 401 o 403) |
| CIS-MCP-2.4 | 1 | Es rebutja una sol·licitud sense capçalera Mcp-Method (HTTP 400, error JSON-RPC -32020) |
| CIS-MCP-2.5 | 1 | Es rebutja una sol·licitud amb una capçalera Origin que designa un lloc de tercers (HTTP 403) |
| CIS-MCP-3.1.2 | 1 | Es rebutja una sol·licitud anònima amb HTTP 401, i el testimoni JWT de l’objectiu és vàlid com a màxim una hora; cal revisar un testimoni vàlid durant més temps |
| CIS-MCP-3.2.2 | 1 | L’audiència del testimoni JWT de l’objectiu designa aquest servidor; cal revisar una audiència aliena |
| CIS-MCP-3.3.1 | 1 | L’audiència del testimoni JWT de l’objectiu designa aquest servidor; una audiència aliena no és conforme |
| CIS-MCP-3.3.2 | 2 | Les metadades OAuth se serveixen en HTTPS, designen el punt final com a recurs, anuncien almenys un servidor d’autorització, i l’issuer de cadascun correspon a la seva adreça |
| CIS-MCP-5.1.1 | 1 | Els esquemes d’entrada i de sortida de cada eina són esquemes JSON vàlids |
| CIS-MCP-5.1.2 | 1 | Cada plantilla de recurs declara el seu tipus MIME |
| CIS-MCP-5.1.3 | 1 | Cada argument de prompt té nom, i el seu atribut required, si n’hi ha, és un booleà |
| CIS-MCP-5.2.3 | 1 | El servidor rebutja les sol·licituds GET i DELETE (HTTP 405) i no emet cap capçalera Mcp-Session-Id |
| CIS-MCP-7.1.2 | 1 | Es rebutja una sol·licitud amb l’identificador JSON-RPC null (HTTP 400, error JSON-RPC -32600) |
| CIS-MCP-10.1 | 1 | La resposta a tools/list porta Cache-Control: no-store o private |
Les regles 5.1.1, 5.1.2 i 5.1.3 produeixen una línia per eina, plantilla o prompt, i la regla 3.3.2, una línia per servidor d’autorització. La regla 3.3.2 no és aplicable a un servidor que no publica metadades OAuth i no exigeix autenticació.
Les capçaleres Mcp-Method i les sessions sense estat només existeixen a partir de la revisió 2026-07-28 del protocol: en un servidor més antic, els controls corresponents no s’avaluen, i les regles 2.4 i 5.2.3 estan en l’estat Omesa.
Testimoni JWT de l’objectiu
Les regles 3.1.2, 3.2.2 i 3.3.1 llegeixen el testimoni configurat a l’autenticació HTTP Bearer de l’objectiu, si és un JWT. Cyberwatch descodifica localment la seva audiència (aud) i el seu període de validesa (iat, exp), sense verificar-ne la signatura ni transmetre’l a cap altre lloc que no sigui el servidor auditat.
Sense testimoni JWT, per exemple amb un testimoni opac, aquests controls no s’avaluen.
Recomanacions que cal verificar manualment
Les 39 recomanacions restants no es poden verificar amb una auditoria remota del punt final. Tracten, en particular, de:
- el client i l’amfitrió MCP (secció 4 del benchmark)
- els servidors locals en stdio
- les dades que tracta el servidor (secció 6)
- la seva cadena de subministrament (secció 8) i el seu aïllament (secció 9)
- els seus registres
- llistes aprovades pròpies de la vostra organització, per exemple les capacitats o les eines autoritzades
- controls que exigirien cridar una eina, llegir un recurs o obtenir un prompt
Aquestes regles estan en l’estat Omesa, amb la menció «Manual verification required» seguida de la raó. La fitxa de cada regla reprèn el procediment d’auditoria del CIS.
Un cop verificada una recomanació, podeu ignorar la regla i comentar aquesta decisió.