Controlar el cumplimiento CIS de un servidor MCP
Cyberwatch evalúa el cumplimiento de los servidores MCP (Model Context Protocol) respecto al CIS MCP Server Benchmark v1.0.0, publicado por el CIS en septiembre de 2026.
Las 55 recomendaciones del benchmark están disponibles en forma de reglas de cumplimiento. Dieciséis de ellas se verifican automáticamente a partir de la auditoría diaria del servidor. Las demás dependen del cliente, del alojamiento o de la organización, y deben verificarse manualmente.
Crear el objetivo MCP
El cumplimiento se evalúa en un activo de tipo servidor MCP. Para crearlo, añadir un objetivo de red de tipo «Servidor MCP», indicando la URL exacta de su endpoint.
El activo recibe el sistema operativo «MCP Server», al que se aplican las reglas del benchmark.
Asociar los repositorios
Un nuevo objetivo MCP recibe automáticamente el repositorio CIS_Benchmark_level_1, que agrupa las 39 recomendaciones de nivel 1.
Para evaluar también las 16 recomendaciones de nivel 2, añadir el repositorio CIS_Benchmark_level_2, o bien CIS_Benchmark, que agrupa ambos niveles. Estos repositorios están presentes por defecto en Cyberwatch.
Funcionamiento de la evaluación
Las reglas evalúan los hechos registrados por la última auditoría del servidor MCP, sin enviar ninguna nueva petición al servidor. La evaluación se relanza después de cada auditoría cuyo resultado cambia, y al menos cada 30 días.
Cada regla automática agrupa varios controles. Su salida, visible en la pestaña «Cumplimiento» del activo, los detalla uno por línea, con su veredicto y su constatación:
- un control es conforme, no conforme, o no evaluado cuando la auditoría no permite concluir
- la regla está en Fallo en cuanto uno de sus controles es no conforme
- está en Éxito si al menos un control es conforme y ninguno es no conforme
- de lo contrario, está en estado Pasado
La salida de la regla recuerda también lo que queda por verificar manualmente, por ejemplo en los registros del servidor.
Recomendaciones verificadas automáticamente
| Regla | Nivel | Controles |
|---|---|---|
| CIS-MCP-1.1 | 1 | El servidor no sirve ninguna revisión del protocolo anterior a 2025-06-18, y rechaza una petición cuya versión es desconocida, está ausente o difiere entre la cabecera MCP-Protocol-Version y el cuerpo |
| CIS-MCP-1.4 | 1 | El servidor declara su nombre y su versión (serverInfo) |
| CIS-MCP-2.2 | 1 | El servidor rechaza el HTTP sin cifrar o lo redirige a HTTPS, negocia TLS 1.2 o 1.3, rechaza TLS 1.0 y 1.1, y presenta un certificado válido |
| CIS-MCP-2.3 | 2 | Una petición anónima se rechaza (HTTP 401 o 403) |
| CIS-MCP-2.4 | 1 | Una petición sin cabecera Mcp-Method se rechaza (HTTP 400, error JSON-RPC -32020) |
| CIS-MCP-2.5 | 1 | Una petición cuya cabecera Origin designa un sitio de terceros se rechaza (HTTP 403) |
| CIS-MCP-3.1.2 | 1 | Una petición anónima se rechaza con HTTP 401, y el token JWT del objetivo es válido como máximo una hora; un token válido durante más tiempo debe revisarse |
| CIS-MCP-3.2.2 | 1 | La audiencia del token JWT del objetivo designa este servidor; una audiencia ajena debe revisarse |
| CIS-MCP-3.3.1 | 1 | La audiencia del token JWT del objetivo designa este servidor; una audiencia ajena es no conforme |
| CIS-MCP-3.3.2 | 2 | Los metadatos OAuth se sirven en HTTPS, designan el endpoint como recurso, anuncian al menos un servidor de autorización, y el issuer de cada uno corresponde a su dirección |
| CIS-MCP-5.1.1 | 1 | Los esquemas de entrada y de salida de cada tool son esquemas JSON válidos |
| CIS-MCP-5.1.2 | 1 | Cada plantilla de resource declara su tipo MIME |
| CIS-MCP-5.1.3 | 1 | Cada argumento de prompt tiene nombre, y su atributo required, si existe, es un booleano |
| CIS-MCP-5.2.3 | 1 | El servidor rechaza las peticiones GET y DELETE (HTTP 405) y no emite ninguna cabecera Mcp-Session-Id |
| CIS-MCP-7.1.2 | 1 | Una petición cuyo identificador JSON-RPC es null se rechaza (HTTP 400, error JSON-RPC -32600) |
| CIS-MCP-10.1 | 1 | La respuesta a tools/list lleva Cache-Control: no-store o private |
Las reglas 5.1.1, 5.1.2 y 5.1.3 producen una línea por tool, plantilla o prompt, y la regla 3.3.2 una línea por servidor de autorización. La regla 3.3.2 no se aplica a un servidor que no publica metadatos OAuth y no exige autenticación.
Las cabeceras Mcp-Method y las sesiones sin estado solo existen a partir de la revisión 2026-07-28 del protocolo: en un servidor más antiguo, los controles correspondientes quedan sin evaluar, y las reglas 2.4 y 5.2.3 están en estado Pasado.
Token JWT del objetivo
Las reglas 3.1.2, 3.2.2 y 3.3.1 leen el token configurado en la autenticación HTTP Bearer del objetivo, si se trata de un JWT. Cyberwatch decodifica localmente su audiencia (aud) y su duración de validez (iat, exp), sin verificar su firma ni transmitirlo a ningún destino distinto del servidor auditado.
Sin token JWT, por ejemplo con un token opaco, estos controles quedan sin evaluar.
Recomendaciones que deben verificarse manualmente
Las otras 39 recomendaciones no pueden verificarse mediante una auditoría remota del endpoint. Se refieren en particular a:
- el cliente y el host MCP (sección 4 del benchmark)
- los servidores locales en stdio
- los datos tratados por el servidor (sección 6)
- su cadena de suministro (sección 8) y su aislamiento (sección 9)
- sus registros
- listas aprobadas propias de su organización, por ejemplo las capacidades o los tools autorizados
- controles que exigirían llamar a un tool, leer un resource u obtener un prompt
Estas reglas están en estado Pasado, con la mención «Manual verification required» seguida de la razón. La ficha de cada regla recoge el procedimiento de auditoría del CIS.
Una vez verificada una recomendación, es posible ignorar la regla y comentar esta elección.