◇ OpenCyber Academy
Ingeniería · Capítulo 48 · Español

Capítulo 48 — Expediente de evidencia

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Capítulo 48 — Expediente de evidencia

Mapa de la lección

Lección 48 publicada. Mapa, ejemplo, EX142.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["48.1 Qué es el expediente"]
  N2["48.2 Estructura"]
  N3["48.3 Integridad y reproducibilidad"]
  N4["48.4 Riesgo residual honesto"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX142"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["48.1 Qué es el expediente"]
  N2["48.2 Estructura"]
  N3["48.3 Integridad y reproducibilidad"]
  N4["48.4 Riesgo residual honesto"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX142"]
[Resultados de aprendizaje]
    |
    v
[48.1 Qué es el expediente]
    |
    v
[48.2 Estructura]
    |
    v
[48.3 Integridad y reproducibilidad]
    |
    v
[48.4 Riesgo residual honesto]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX142]

Resultados de aprendizaje

Usted será capaz de (1) reunir un expediente de evidencia que respalde un caso de seguridad funcional y ciberseguridad para el proyecto final; (2) organizar la evidencia por afirmación y por requisito; (3) garantizar la integridad y la reproducibilidad de la evidencia; y (4) exponer con honestidad el riesgo residual y las limitaciones.

48.1 Qué es el expediente

El expediente es el conjunto completo y organizado de evidencia de que el sistema cumple sus requisitos y de que sus riesgos residuales se comprenden y se aceptan. Respalda el caso de seguridad funcional y ciberseguridad, y es lo que examinaría un evaluador, un cliente o un regulador. El expediente se reúne a lo largo de todo el proyecto, no al final. Cada informe de pruebas, revisión y resultado de ensayo se archiva con sus versiones a medida que se produce, de modo que la tarea final consiste en organizar y enlazar, no en buscar. Un evaluador debe poder partir de cualquier afirmación y llegar a su evidencia en pocos pasos, y partir de cualquier elemento de evidencia y ver qué afirmación respalda.

48.2 Estructura

  1. Resumen: sistema, uso previsto, afirmaciones, riesgos residuales, recomendación.
  2. Caso de seguridad funcional y ciberseguridad: afirmaciones, argumentos, referencias a la evidencia, refutadores.
  3. Matriz de trazabilidad de requisitos: requisito → diseño → implementación → resultado de la verificación.
  4. Informes de verificación y validación (laboratorios I–II, equipo rojo, piloto).
  5. Informe del ensayo de recuperación y acciones posteriores.
  6. Revisiones de diseño y su cierre.
  7. Configuración: versiones y hashes del código, los modelos, los datos y los prompts.
  8. Documentación: fichas de modelo, fichas técnicas, manuales de operación.
  9. Registro de riesgos residuales con responsables y fechas de revisión.

El orden sigue las preguntas de un evaluador. El resumen responde qué se afirma; el caso, por qué debería creerse; y la matriz, dónde comprobarlo.

48.3 Integridad y reproducibilidad

Registre los hashes de los archivos de evidencia en un manifiesto; guarde el expediente en un repositorio con control de versiones; haga que la evaluación sea reproducible a partir de las configuraciones registradas (scripts, semillas, entornos). El laboratorio de hashes del capítulo 19 es la forma más sencilla de esta disciplina.

"""Lab H: integrity of model artefacts with SHA-256 manifests (stdlib only).
Creates synthetic 'artefact' bytes, records a manifest, then detects a
one-byte tampering and a swapped file. No real models are involved."""
import hashlib, json
files = {"model.bin": bytes(range(256)) * 40, "tokenizer.json": b'{"vocab": ["a", "b"]}',
         "config.yaml": b"layers: 4\nheads: 8\n"}
manifest = {n: hashlib.sha256(b).hexdigest() for n, b in files.items()}
print(json.dumps({k: v[:16] for k, v in manifest.items()}, indent=1))
received = dict(files)
tampered = bytearray(received["model.bin"]); tampered[5000] ^= 1
received["model.bin"] = bytes(tampered)
received["config.yaml"] = b"layers: 4\nheads: 8\ntrust_remote_code: true\n"
for n, b in sorted(received.items()):
    ok = hashlib.sha256(b).hexdigest() == manifest[n]
    print(f"{n:15s} {'OK' if ok else 'MISMATCH'}")

Salida esperada:

{
 "model.bin": "e96760a87768717b",
 "tokenizer.json": "f63d2ddabc61f2d9",
 "config.yaml": "e5bbb570ca0fcb87"
}
config.yaml     MISMATCH
model.bin       MISMATCH
tokenizer.json  OK

Un manifiesto muestra que la evidencia no se modificó después de producirse; la reproducibilidad muestra que puede volver a producirse. Registrar las semillas, los entornos y las versiones hace posibles las repeticiones años después, por ejemplo cuando un regulador pregunta por una versión antigua. El control de versiones añade un historial de cuándo y quién añadió cada elemento de evidencia, lo que ayuda a un evaluador a entender cómo creció el expediente.

48.4 Riesgo residual honesto

Enumere lo que no se probó, lo que falló y se aceptó, y lo que depende de suposiciones (por ejemplo, «los técnicos leen las pantallas de aprobación»). Los reguladores y los clientes confían en los expedientes que exponen sus límites. Las suposiciones merecen un cuidado especial porque son invisibles hasta que fallan. Bulletin Gate supone que los boletines de proveedores llegan por un canal autenticado; si esa suposición se rompe, un atacante podría enviar boletines directamente. Poner por escrito la suposición, junto con lo que mostraría que ha dejado de cumplirse, la convierte en algo que los operadores pueden vigilar. Una entrada del registro de riesgos residuales también nombra quién aceptó el riesgo y cuándo se revisará.

48.5 Ejemplo resuelto (caso sintético de NRS)

El expediente de Bulletin Gate de Sam tenía 41 requisitos: 39 se superaron, uno se superó tras una corrección y una nueva prueba, y uno (los adjuntos de imagen) quedó formalmente fuera del alcance. Los riesgos residuales incluían los ataques adaptativos más allá del conjunto probado, la dependencia de la autenticación del canal de los proveedores y la atención de los revisores. El manifiesto de evidencia enumeraba 312 archivos con hashes SHA-256; un evaluador volvió a ejecutar el entorno de evaluación a partir del expediente y reprodujo las cifras principales dentro de sus intervalos.

La reproducción por parte del evaluador es la evidencia más sólida del expediente, ya que muestra que los resultados procedían del sistema registrado y no de una ejecución irrepetible.

48.6 Errores y límites

Una carpeta de documentos sin vínculos con las afirmaciones deja al evaluador la tarea de construir el argumento, y puede construir uno distinto. Sin versiones, nadie puede saber qué sistema describe un resultado. Un registro de riesgos residuales que dice «ninguno» nunca es cierto y sugiere que el equipo no buscó. La plantilla del expediente de Sam se niega a generarse si alguna afirmación no tiene enlace a evidencia o algún archivo de evidencia no tiene hash.

Ejercicios — capítulo 48

Síntesis del capítulo

El expediente de evidencia hace evaluable el proyecto final: afirmaciones vinculadas a evidencia verificada, versionada y reproducible, y un registro honesto de lo que queda pendiente.

Siga estudiando — capítulo 48 de 50

← Capítulo 47 (borrador) · Índice de capítulos del curso · Capítulo 49 (borrador) →