Cumplimiento y pruebas: demostrar en lugar de declarar¶

Traducción automática del original francés.

Un panel que indica "cumplimiento" en verde responde a una pregunta que nadie hace. Un auditor pide algo más: "¿Cómo sabe que esto era cierto en ese momento, y que la prueba no ha sido alterada desde entonces?"

Esta página describe cómo el parque responde a esta pregunta: un catálogo de controles, sondas que miden, un estado que no se puede determinar manualmente, y un registro que no se puede reescribir sin que se note.

Los términos técnicos se refieren al glosario.

Lo que "cumplimiento" puede significar aquí¶

Dos marcos de referencia sirven como guía, y ninguno de ellos se aplica estrictamente:

NIS2 obliga a las entidades esenciales e importantes de la Unión. Un parque privado no lo es. La directiva sirve como marco de medición: sus diez medidas mínimas (artículo 21 §2) y su mecanismo de notificación (artículo 23) son un buen inventario de lo que debe cubrir una defensa seria.
SOC 2 es un informe elaborado por un auditor acreditado, durante un período. Ninguna herramienta es "certificada SOC 2", y un producto que lo afirma confunde el informe con el expediente. Sin embargo, una herramienta puede producir el expediente de pruebas que el auditor solicitaría.

Así lo hace el parque: un catálogo de controles, pruebas medidas, un estado derivado de las pruebas, una exportación — y los criterios no cubiertos, que se muestran explícitamente en lugar de ocultarlos.

flowchart LR
    classDef src fill:#3f3f46,stroke:#3f3f46,color:#fff
    classDef proof fill:#1e40af,stroke:#1e40af,color:#fff
    classDef out fill:#0f766e,stroke:#0f766e,color:#fff

    cat["Catalogue de contrôles<br/>versionné dans git"]:::src
    son["Sondes<br/>pass · fail · indeterminate"]:::src
    att["Attestations humaines<br/>session authentifiée · expiration"]:::src
    tri["Gestes de triage<br/>avant → après · auteur"]:::src

    run["Lanceur<br/>toutes les six heures"]:::proof
    reg["Registre chaîné<br/>ajout seul · SHA-256"]:::proof
    anc["Ancre quotidienne<br/>git, deux dépôts distants"]:::proof

    der["Statut DÉRIVÉ<br/>recalculé à chaque lecture"]:::out
    tab["Tableau de conformité"]:::out
    exp["Dossier d'audit"]:::out

    cat --> run
    son --> run --> reg
    att --> reg
    tri --> reg
    reg --> anc
    reg --> der --> tab
    der --> exp

1. El catálogo de controles comunes¶

Un control es una medida de seguridad que se puede demostrar que funciona. El catálogo incluye unas treinta. Cada uno incluye:

un objetivo, en una frase;
los artículos de NIS2 y los criterios de SOC 2 a los que responde — una auditoría realizada una vez sirve para ambos marcos (controles comunes);
sus fuentes de evidencia: una o varias pruebas, una declaración, o ambas.

El catálogo es un archivo versionado en Git. Cada versión se registra: no solo sabemos qué se comprobó en una fecha, sino también qué se exigía en esa fecha.

¿Cómo cubre el catálogo las diez medidas del artículo 21 §2?

NIS2, art. 21 §2	Lo que el catálogo y el informe incluyen	SOC 2	Evidencia
a) Análisis de riesgos	Análisis de riesgos y puntos ciegos documentados, revisión anual	CC3	Certificado
b) Gestión de incidentes	SIEM y alertas, detección en tiempo real, IDS de red, registros de los motores de archivos, información sobre amenazas, respuesta automática, investigación en caliente	CC7	Sensores
c) Continuidad, copias de seguridad, gestión de crisis	Copias de seguridad inmutables, restauración probada, clave maestra fuera de línea	A1, CC9	Sensores + Certificado
d) Cadena de suministro	Cuarentena de versiones, SBOM, revisión de proveedores críticos	CC8, CC9	Sensores + Certificado
e) Seguridad del desarrollo y mantenimiento, vulnerabilidades	Escaneo continuo, tiempo de corrección de vulnerabilidades, trazabilidad de los cambios, parches, bloqueo en el perímetro	CC6, CC7, CC8	Sensores
f) Evaluación de la eficacia	Integridad del registro de evidencia, revisión trimestral de los controles	CC4	Sensor + Certificado
g) Higiene cibernética y formación	Parches, endurecimiento CIS, competencia del operador	CC1, CC5	Sensores + Certificado
h) Criptografía	Certificados realmente utilizados, clave maestra	CC6	Sensores
i) Control de acceso, gestión de activos	Inventario y persistencia, SBOM, ausencia de secretos en texto plano en los hosts	CC6, C1	Sensores
j) Autenticación multifactor, comunicaciones seguras	MFA en cuentas con privilegios, canal de crisis fuera de la red	CC6, CC2	Sensor + Certificado

Además, se incluyen los artículos 20 (responsabilidad y supervisión: una certificación anual) y 23 (notificación: el registro de incidentes reponse.md#incidents).

2. Los sensores¶

Una sensor es un script que mide un hecho y emite un veredicto. Su contrato es breve, y cada cláusula tiene una razón:

Cláusula	Razón
Una única línea JSON en salida: identificador, veredicto, hecho observado, detalle, fecha de medición	Un único lanzador, un formato único, ninguna interpretación
Veredicto entre `pass`, `fail`, `indeterminate`	Tres estados, porque hay tres situaciones
Objetivo inalcanzable → `indeterminate`, nunca `pass`	La ausencia de respuesta no es una medición
Salida de éxito tan pronto como se emite un veredicto, incluso `fail`	Un fallo de control no es un sensor defectuoso
Menos de un minuto	Un sensor lento es un sensor que eventualmente se desactiva
Ningún secreto en la salida	El detalle va a un registro que otros leen
Encabezado: lo que demuestra, lo que no demuestra, el comando que lo hizo fallar	Un sensor que nunca ha mostrado rojo no mide nada

{"probe": "<identifiant>", "status": "pass",
 "observed": "<le fait mesuré, en une phrase>",
 "detail": {"...": "..."}, "measured_at": "<date ISO 8601>"}

La última cláusula es la más importante. Antes de ser admitida, cada sensor debe pasar por su verificación inversa: se provoca intencionalmente la situación que debe detectar, y se observa cómo se pone en rojo. Un sensor que no puede fallar no es una prueba, es una decoración.

Lo que miden los sensores, por ejemplo: los certificados realmente entregados y su fecha de caducidad; los agentes del SIEM conectados; un contenedor desechable que desencadena la detección en tiempo de ejecución; la regla canaria de los motores de archivos; una eliminación rechazada en el objetivo de respaldo; la antigüedad del último ejercicio de restauración; la presencia de cuarenta versiones en cada repositorio; el segundo factor de las cuentas con privilegios; la integridad del registro frente a sus anclas.

Un sensor demuestra lo que mide, y nada más

La sonda del registro de incidencias verifica que los plazos de las incidencias declaradas se cumplen. Un registro vacío indica que no hay incidencias, y no prueba que no haya ocurrido ninguna incidencia ni que una incidencia real haya sido declarada — y esto está escrito en su encabezado, donde el siguiente lector lo encontrará.

Las sondas se revisan cada seis horas. Una sonda que está presente en el disco pero no está conectada a ningún control aparece en la tabla como evidencia aislada: mide algo que nadie ha solicitado, o un control ha perdido su evidencia.

3. El estado derivado¶

El estado de un control no se captura. Se calcula, en cada lectura, a partir de las evidencias:

Estado	Condición
Activo	Todas sus sondas indican `pass`, y son recientes (36 horas por defecto), y todas sus certificaciones son válidas
Fallido	Al menos una sonda indica `fail`
No verificado	El resto: una sonda silenciosa, caducada, indeterminada, una certificación faltante o expirada

La tercera línea es la que marca la diferencia. La ausencia de medición no es una medición: un control cuya sonda ha dejado de funcionar no permanece en verde por inercia, sino que pasa a "no verificado".

¿Por qué nunca capturar un estado? Un estado capturado es una declaración. Era cierto el día en que se escribió, y sigue siendo así en la interfaz, incluso después de que la realidad haya cambiado. Un estado derivado no puede permanecer en un estado falso más tiempo que la validez de su evidencia.

4. El registro en cadena y su ancla¶

Todas las evidencias — cada resultado de la sonda, cada certificación, cada versión del catálogo — entran en un registro en cadena, añadiendo únicamente.

flowchart LR
    classDef e fill:#1e40af,stroke:#1e40af,color:#fff
    classDef a fill:#0f766e,stroke:#0f766e,color:#fff

    e1["Entrée n<br/>contenu + empreinte de n-1"]:::e
    e2["Entrée n+1<br/>contenu + empreinte de n"]:::e
    e3["Entrée n+2 — tête<br/>contenu + empreinte de n+1"]:::e
    anc["Ancre du jour<br/>numéro + empreinte de tête<br/>versionnée dans git"]:::a

    e1 --> e2 --> e3
    e3 -.->|"chaque soir"| anc

Cada entrada contiene la huella SHA-256 de la anterior. Modificar, eliminar o insertar una entrada en medio rompe la cadena en la entrada exacta: la verificación indica dónde.
Sin embargo, existe un caso en el que la cadena no lo detecta: la truncación. Eliminar las últimas entradas deja una cadena perfectamente válida, aunque más corta.
Por lo tanto, se utiliza la ancla: cada noche, el número y la huella del encabezado del registro se versionan en Git y se suben a dos repositorios remotos. Un registro truncado ya no puede recuperar sus anclas. Una sonda compara el registro con las anclas publicadas.

Una consecuencia intencionada

Restaurar la base del registro desde una copia de seguridad lo devuelve a un estado anterior: sus entradas más recientes han desaparecido, y la verificación con las anclas falla. Esto es correcto: el registro ha perdido efectivamente pruebas. Este fallo se registra; nunca se "corrige" eliminando las anclas, lo que equivaldría a borrar la huella de la pérdida.

5. Dos registros, y quién los firma¶

El registro contiene dos tipos de entradas:

las pruebas, descritas anteriormente;
las acciones humanas: cada decisión de clasificación, cada acción de corrección, registradas con su estado antes y después, en la misma transacción que la acción mismísima — una acción sin huella no puede haber tenido lugar.

El autor de una acción se lee del canal — la sesión autentificada por el proveedor de identidad — y nunca del cuerpo de la solicitud. Un registro en el que el autor se declara a sí mismo no prueba nada: cualquier persona con acceso podría escribir cualquier nombre.

6. Las declaraciones¶

Certaines choses ne se mesurent pas : qu'une analyse de risques a été relue, que l'opérateur se forme, que les fournisseurs critiques ont été revus, que le canal de crise hors du parc a été testé. Elles relèvent d'une attestation : une déclaration humaine datée.

Trois garde-fous en font autre chose qu'une case cochée :

elle n'est acceptée que depuis une session authentifiée ;
expira — anualmente o trimestralmente, según el control;
se registra como cualquier otra prueba, por lo que no se modifica.

7. Auditoría – Procedimiento¶

Un auditor, o el operador, repite estos pasos:

Recalcular la cadena del registro, y luego compararla con las referencias almacenadas en Git – no con las que anuncia el servidor: el objetivo de una referencia es que esté fuera de alcance de la máquina que está supervisando.
Exportar el informe de auditoría: catálogo, estatutos, pruebas, incidentes y método, en un archivo.
Replicar una prueba manualmente, sin registrarla, y comparar su resultado con el último registrado.
Elegir una prueba al azar y solicitar su verificación inversa: ¿qué comando la hizo fallar, y qué resultado produjo?

8. Añadir una prueba o sonda¶

Registrar la prueba según el contrato, incluyendo el encabezado.
Hacer que falle intencionalmente, y anotar el comando que la hizo fallar.
Declararla en una prueba del catálogo: el identificador de la prueba es el nombre del archivo de la prueba.
Lanzarla sin registrar, y esperar al siguiente lanzamiento. Una prueba no registrada aparece como "huérfana": se nota el olvido.

Leer después¶

Detección — la posibilidad de que las sondas sean revisadas por los testigos.
Continuidad — la inmutabilidad y la posibilidad de restaurar los datos.
Respuesta — el registro de incidentes.
Glosario.

Dernière vérification de cette page : 2026-09-11