Autoevaluación, no certificación. Lo emite Veritas Digital LLC sobre su propio servicio. Ningún organismo independiente lo ha auditado ni acreditado, y varias secciones señalan deficiencias abiertas.
Autoevaluación frente a Cyber Essentials
Última revisión: 5 de agosto de 2026
Autoevaluación frente a los cinco controles técnicos de Cyber Essentials del NCSC británico.
↓ Descargar el original en Markdown Es el fichero que se adjunta a un expediente; esta página es el mismo texto, legible y enlazable.
Ficha del documento
- 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.*
¿Has encontrado un error?
Estos documentos se corrigen. Si algo no cuadra con lo que hace el servicio, escríbenos a sos@veritasnexuslegal.com y se revisa.