# Autoevaluación frente a Cyber Essentials

**Marco de referencia:** Cyber Essentials — cinco controles técnicos del NCSC (Reino Unido)
**Organización:** Veritas Digital LLC · **Sistema:** Veritas UGC
**Versión:** 1.0 · 5 de agosto de 2026

---

## Aviso de estatus

**Veritas Digital LLC no posee la certificación Cyber Essentials.** Obtenerla cuesta desde 320 GBP
y requiere un organismo certificador acreditado por el IASME.

Este documento aplica **el mismo cuestionario** al sistema real y responde con honestidad. Se
elige este marco por encima de otros porque es el más concreto que existe: cinco controles
técnicos, sin ambigüedad, con umbrales numéricos. Un marco que dice «parchea lo crítico en 14
días» se puede aprobar o suspender; uno que dice «gestione adecuadamente el riesgo», no.

**Resultado de la autoevaluación: los cinco controles se cumplen.** El detalle está abajo,
incluidos los dos puntos donde el cumplimiento requiere explicación.

---

## Alcance declarado

| | |
|---|---|
| **Alcance** | Toda la organización |
| **Dispositivos de usuario** | Una estación de trabajo Windows 11 Pro |
| **Servidores** | Servidores virtuales en rotación, con Docker |
| **Servicios en la nube** | Un servicio de almacenamiento externo, usado solo para copias cifradas |
| **Personas** | Un usuario, que es a la vez administrador |
| **Trabajo remoto** | El 100 % de la operación |

---

## Control 1 · Cortafuegos

**Objetivo:** que solo esté accesible desde internet lo que tiene que estarlo.

| Requisito | Respuesta | Evidencia |
|---|---|---|
| ¿Hay cortafuegos en el límite de cada red? | **Sí** | Cortafuegos del proveedor más `iptables` gestionado por Docker |
| ¿Se cambió la contraseña por defecto del cortafuegos? | **N/A** | Sin interfaz administrativa con contraseña: la configuración es declarativa |
| ¿Se bloquean por defecto las conexiones entrantes no autenticadas? | **Sí** | Política de denegación por defecto |
| ¿Cada regla que abre un puerto está documentada y aprobada? | **Sí** | Solo dos puertos abiertos, ambos justificados |
| ¿Se retiran las reglas que ya no hacen falta? | **Sí** | Revisión en cada despliegue |
| ¿Las interfaces administrativas están fuera de internet o protegidas? | **Sí** | La administración solo por SSH con clave; **la autenticación por contraseña está desactivada** |

**Puertos abiertos al exterior:**

| Puerto | Servicio | Justificación |
|---|---|---|
| 443 | Proxy TLS | Único punto de entrada del tráfico web |
| 2244 | SSH | Administración. Solo clave, sin contraseña, puerto no estándar |

**Ningún contenedor de la aplicación publica puertos al exterior.** La API, el procesador, la base
de datos y la cola solo son alcanzables desde la red interna de Docker. Esto es más estricto de lo
que exige el control.

> **Un matiz que conviene declarar.** La topología de la red hace que la dirección IP real del
> cliente no llegue nunca a la aplicación: el puerto 443 lo atiende un proxy de nivel TCP que no
> habla HTTP. Como consecuencia, **cualquier defensa basada en bloquear direcciones IP sería
> inútil o directamente peligrosa** —bloquearía la dirección del propio proxy y dejaría el
> servicio caído para todo internet—. Por eso la limitación de tasa se resuelve por identidad de
> visitante y no por IP. Cyber Essentials no pregunta por esto, pero omitirlo daría una imagen
> falsa de cómo está defendido el sistema.

---

## Control 2 · Configuración segura

**Objetivo:** que nada llegue a producción con la configuración de fábrica.

| Requisito | Respuesta | Evidencia |
|---|---|---|
| ¿Se eliminan las cuentas de usuario innecesarias? | **Sí** | Una sola cuenta administrativa en el servidor |
| ¿Se cambian las contraseñas por defecto? | **Sí** | Sin credenciales por defecto en ningún servicio |
| ¿Se desinstala el software innecesario? | **Sí** | Imágenes mínimas basadas en Alpine; sin herramientas de desarrollo en producción |
| ¿Se desactivan los servicios que no se usan? | **Sí** | Un proceso por contenedor |
| ¿Se desactiva la ejecución automática? | **N/A** | Sin soportes extraíbles en el flujo |
| ¿Los dispositivos se bloquean tras inactividad? | **Sí** | Bloqueo automático en la estación de trabajo |

**Endurecimiento aplicado por encima del mínimo exigido:**

| Medida | Estado |
|---|---|
| Contenedores como usuario sin privilegios | Los cuatro servicios de aplicación **y la base de datos** |
| Todas las capacidades del kernel retiradas | Sí, `cap_drop: ALL` |
| `no-new-privileges` | Sí, impide escalada por binarios setuid |
| Sistema de archivos raíz en solo lectura | Sí en los contenedores de aplicación |
| Secretos fuera de la imagen | Montados en `/run/secrets`, nunca en el registro de contenedores |

El contenedor de base de datos era, hasta hace poco, el único que corría como root con todas las
capacidades. **Se corrigió y se verificó la integridad de los datos antes y después del cambio.**

---

## Control 3 · Gestión de actualizaciones de seguridad

**Objetivo:** que ninguna vulnerabilidad crítica conocida siga abierta más de 14 días.

| Requisito | Respuesta | Evidencia |
|---|---|---|
| ¿Todo el software tiene soporte del fabricante? | **Sí** | Node 20 LTS, PostgreSQL 16, Alpine estable |
| ¿Se aplican los parches críticos en 14 días? | **Sí** | Procedimiento con plazos; reconstrucción de imagen y despliegue |
| ¿Se elimina el software sin soporte? | **Sí** | Sin dependencias abandonadas en el árbol de producción |
| ¿Están activas las actualizaciones automáticas donde procede? | **Parcial** | Automáticas en el sistema operativo del host; **manuales y deliberadas en las dependencias de la aplicación** |

**Por qué las dependencias no se actualizan solas, que es lo contrario de lo que suele
recomendarse.** El vector de ataque más activo de 2025 y 2026 en el ecosistema de Node no son las
vulnerabilidades conocidas, sino los gusanos que comprometen paquetes legítimos y se propagan en
horas. Contra eso, actualizar automáticamente **acelera el contagio en lugar de prevenirlo**: la
versión maliciosa aún no está en ninguna base de datos cuando entraría en el árbol de
dependencias.

La respuesta implantada tiene tres capas:

| Capa | Medida | Qué neutraliza |
|---|---|---|
| 1 | `ignore-scripts` en la instalación | Los guiones de instalación, que es por donde se propagan estos gusanos |
| 2 | Cuarentena de versiones publicadas hace menos de 7 días | La ventana en la que un paquete comprometido aún no ha sido detectado |
| 3 | `osv-scanner` en cada compilación | Las vulnerabilidades ya catalogadas |

`ignore-scripts` rompe los paquetes que compilan binarios nativos; esos se autorizan uno a uno de
forma explícita, que es exactamente la intención del control.

---

## Control 4 · Control de acceso de usuarios

**Objetivo:** que cada persona tenga solo el acceso que necesita, y que las cuentas privilegiadas
estén especialmente protegidas.

| Requisito | Respuesta | Evidencia |
|---|---|---|
| ¿Hay un proceso de alta de usuarios? | **Sí** | Alta por enlace mágico verificado por correo |
| ¿Se autentica a cada usuario antes de darle acceso? | **Sí** | Enlace de un solo uso con caducidad |
| ¿Se retiran los accesos que ya no hacen falta? | **Sí** | Revocación desde la consola, con registro de auditoría |
| ¿Las cuentas administrativas se usan solo para administrar? | **Sí** | El acceso administrativo va por SSH, separado del uso del producto |
| ¿Hay segundo factor donde el proveedor lo ofrece? | **Sí** | Activo en el proveedor de servidores y en la cuenta de almacenamiento |
| ¿Las contraseñas cumplen los requisitos mínimos? | **N/A por diseño** | **No se almacena ninguna contraseña de usuario.** Ver abajo |

**Sobre la ausencia de contraseñas.** El sistema no guarda contraseñas de usuario: la
autenticación es por enlace mágico de un solo uso con caducidad. El cuestionario de Cyber
Essentials asume que hay contraseñas y pregunta por su robustez; aquí la respuesta correcta no es
«sí, son robustas» sino **«no existen, y por eso no pueden filtrarse, reutilizarse ni adivinarse»**.
Es un cumplimiento por eliminación del riesgo, no por gestión del riesgo.

El acceso administrativo al servidor es exclusivamente por clave SSH con la autenticación por
contraseña desactivada en el demonio.

---

## Control 5 · Protección contra software malicioso

**Objetivo:** que ningún archivo malicioso llegue a ejecutarse ni a almacenarse.

| Requisito | Respuesta | Evidencia |
|---|---|---|
| ¿Hay antimalware en los dispositivos? | **Sí** | Microsoft Defender en la estación de trabajo |
| ¿Se actualiza a diario? | **Sí** | Automático en la estación; el contenedor de análisis refresca sus firmas por su cuenta |
| ¿Analiza los archivos al acceder? | **Sí** | En la plataforma, **cada archivo subido se analiza antes de entrar en la canalización** |
| ¿Bloquea las conexiones a sitios maliciosos? | **Parcial** | Salida de red del procesador restringida a destinos conocidos |
| Alternativa: ¿hay lista blanca de aplicaciones? | **Sí, de hecho** | Raíz en solo lectura: en los contenedores de aplicación no se puede instalar ni ejecutar nada nuevo |

**El detalle que importa: el análisis es de fallo cerrado.** Si el motor antivirus no responde, el
archivo **no pasa**. No se acepta nada sin analizar bajo ninguna circunstancia. Esta es una
elección deliberada: la alternativa —dejar pasar el archivo cuando el antivirus está caído—
convierte una caída del antivirus en una vía de entrada.

Este control estuvo roto: el código invocaba un binario que no existía en la imagen, de modo que
el análisis fallaba en silencio y el archivo pasaba igual. **Se detectó, se corrigió y se
verificó con un archivo de prueba EICAR.** Se documenta aquí porque una autoevaluación que solo
cuenta lo que funciona no sirve para nada.

---

## Resultado

| Control | Resultado |
|---|---|
| 1 · Cortafuegos | **Cumple** |
| 2 · Configuración segura | **Cumple**, con endurecimiento por encima del mínimo |
| 3 · Actualizaciones de seguridad | **Cumple**, con una desviación justificada y documentada |
| 4 · Control de acceso | **Cumple**, por eliminación del riesgo de contraseñas |
| 5 · Protección contra malware | **Cumple**, en modo fallo cerrado |

**Los cinco controles se cumplirían en una evaluación real.** Las dos respuestas que un evaluador
querría discutir son la actualización manual de dependencias (control 3) y la ausencia de
contraseñas (control 4). Ambas son desviaciones del cuestionario **hacia una postura más segura**,
no hacia una más laxa, y quedan documentadas para que el evaluador pueda juzgarlas.

**Lo que no cubre este marco.** Cyber Essentials es un suelo, no un techo: verifica higiene
básica. No dice nada sobre integridad probatoria, cadena de custodia, anclaje temporal ni
transparencia verificable, que es donde este sistema se juega su valor. Para eso están la
Declaración de Aplicabilidad de ISO/IEC 27001 y la Declaración de Prácticas del servicio de
confianza.

---

*Autoevaluación de Veritas Digital LLC, 5 de agosto de 2026. No es una certificación Cyber
Essentials ni sustituye a una. Revisión anual o ante cualquier cambio de alcance.*