Perfil de Inspección — metodología para el operador¶

Lee en tu idioma: English · Português · Español

Estado del alcance (post-congelación de alcance 2026-05-10) — Perfil de Inspección es ahora Test Kind #3 en el conjunto canónico de 7 Test Kinds. Schema combinatorio de Test Plan (10 componentes × 5 presets + custom 2^10) en dashboard/src/lib/test-plan/schema.ts. Ver ADR 0010 para el design lock original + primer CPOS para 2PC atómico entre DUT + Personas + Agents.

Resumen¶

Cada NGFW bajo prueba expone ~13 controles de inspección (descifrado TLS, IPS, AMP, filtrado de URL, etc.). Las hojas de datos de los fabricantes seleccionan la combinación más liviana; comparar dos informes de fabricantes distintos exige un paso de traducción que nadie hace. El bench TLSStress.Art resuelve ambos problemas agrupando los controles en 5 perfiles nombrados que se mapean limpiamente a la §6 del RFC 9411.

minimal    → solo L3/L4 — el techo de throughput
balanced   → descifrado TLS + IPS por defecto — baseline SMB enterprise
paranoid   → + AMP + App Control + filtrado URL + inspección de archivo
compliance → paranoid menos App Control + logging en verbosidad máxima
sandbox    → paranoid + detonación on-box de archivos (el más lento)

Cada test plan declara opcionalmente un perfil. El motor de ejecución lo aplica al NGFW antes de levantar los agentes (scripts/ip-apply-<vendor>.sh) y lo retira en el cleanup. El Anexo K del informe atestigua el estado real de los controles aplicados — incluyendo detección de drift si el fabricante cambió algo en silencio.

Para el racional completo del diseño, ver ADR 0010.

¿Por qué 5 perfiles nombrados en vez de controles libres?¶

Dos modos de falla si los perfiles no existen:

La comparación entre fabricantes se vuelve intratable. "FTD con policy Balanced" y "Palo Alto con Strict Security Profile" habilitan conjuntos de controles distintos. Un cliente leyendo dos informes no puede saber qué números están comparando lo mismo.
La planificación de capacidad esconde el costo. Los números de datasheet vienen del setting más liviano; el deployment de producción agrega controles y descubre el costo recién después de estar en producción.

El agrupamiento en 5 perfiles produce un vocabulario independiente del fabricante que se mapea a los mismos controles que la §6 del RFC 9411 enumera. El cliente puede cruzar referencias entre el Anexo K de TLSStress.Art y un informe de fabricante con certificación NetSecOPEN (p. ej. el informe Cisco FPR-3105 / UNH IOL de octubre de 2024) sin traducción.

Matriz de controles¶

Control	minimal	balanced	paranoid	compliance	sandbox
ACL L3/L4	✓	✓	✓	✓	✓
Inspección TLS (TLS 1.3)		✓	✓	✓	✓
IDS/IPS		default	strict	strict	strict
Anti-Malware (firma)			✓	✓	✓
Anti-Malware (detonación)					✓
App Control			✓		✓
Filtrado de URL			✓	✓	✓
Inspección de archivo			✓	✓	✓
Verbosidad de log	std	std	std	max	max

Por qué DNS Security no aparece en ningún perfil: los agentes todavía no emiten patrones realistas de consulta DNS; activar DNS Security mediría la respuesta del fabricante a consultas sintéticas de bajo volumen, lo que es engañoso. DNS Security ingresa a la matriz en v4.7+ cuando la flota de agentes exponga un parámetro de tasa de consultas DNS.

Cruce con RFC 9411 §6¶

Feature de RFC 9411 §6        → Perfiles que la incluyen
─────────────────────────────  ────────────────────────────────────────
TLS Inspection                 balanced, paranoid, compliance, sandbox
IDS/IPS                        balanced (default), paranoid+ (strict)
Anti-Malware                   paranoid, compliance, sandbox
App Control                    paranoid, sandbox
URL Filtering                  paranoid, compliance, sandbox
File Inspection                paranoid, compliance, sandbox
Logging                        todos (la verbosidad difiere)
DNS Security                   ninguno (postergado a v4.7+)
WAF / DLP / CASB               ninguno (fuera del alcance)
Sandboxing                     sandbox (solamente)
TLS 1.3 Decryption             absorbido en TLS Inspection — el bench es
                               TLS 1.3-only desde v3.6

Mapeo de fabricante — Cisco FTD (MVP v4.5)¶

El operador no configura el FTD a mano. scripts/ip-apply-ftd.sh --profile <nombre> hace el equivalente de estos llamados FMC REST API:

Perfil	Access Policy del FTD	IPS Policy	File Policy	URL Category	AMP
`minimal`	Allow-Trust	none	none	none	off
`balanced`	L4-and-Inspect	Balanced (default)	none	none	off
`paranoid`	L4-Inspect-Block	Security (strict)	Block-Malware	Block-Threats	inline
`compliance`	L4-Inspect-Audit	Security (strict)	Block-Malware	Block-Threats	inline
`sandbox`	L4-Inspect-Block	Security (strict)	Block-Malware-AMP	Block-Threats	Capacity Mode

El script de apply resuelve los nombres de preset a IDs de FMC en runtime — un upgrade de software del fabricante que renombre un preset hace fallar el apply con "preset 'Balanced' not found, list of currently-shipped presets is X, Y, Z" en vez de aplicar silenciosamente la policy equivocada.

Palo Alto Networks ingresa en v4.6 con una tabla equivalente.

Anexo K — atestación por ejecución¶

El Anexo K del informe ("Inspection Profile Attestation") registra:

El nombre del perfil que el operador seleccionó
El estado esperado de los controles (la fila de la matriz arriba)
El estado observado de los controles, leído del device vía API del fabricante
Cualquier drift entre esperado y observado (bloquea la ejecución en modo production)
El subset de features RFC 9411 §6 que esta ejecución satisface
Un puntero de cross-reference NetSecOPEN — p. ej. "esta ejecución es comparable al benchmark FPR-3105 HTTPS Throughput del informe NetSecOPEN de octubre de 2024"

report.inspection_profile:
  applied: true
  profile_name: "paranoid"
  vendor: "cisco-ftd"
  rfc9411_features: ["TLS Inspection", "IDS/IPS", "Anti-Malware",
                     "App Control", "URL Filtering", "File Inspection"]
  expected_dials:
    tls_inspection: true
    ids_ips: "strict"
    anti_malware_signature: true
    anti_malware_detonation: false
    app_control: true
    url_filtering: true
    file_inspection: true
    logging: "standard"
  observed_dials:                       # leído del FMC en apply + verify
    tls_inspection: true
    ids_ips: "strict"
    anti_malware_signature: true
    anti_malware_detonation: false
    app_control: true
    url_filtering: true
    file_inspection: true
    logging: "standard"
  drift: []                             # vacío = la ejecución prosigue
  netsecopen_cross_ref:
    classification: "RFC 9411 §6 subset (paranoid)"
    nearest_published_test: "FPR-3105 HTTPS Throughput (informe NetSecOPEN oct/2024)"
  attestation_sha256: "sha256:…"

Flujo del operador¶

Seleccionar un perfil¶

En el YAML del test plan:

- identifier: CAP-FIND-KNEE-30M-PARANOID
  display_name: "Capacity — paranoid inspection (30 min)"
  # … campos estándar del plan …
  environment:
    inspection_profile:
      name: paranoid
      vendor: cisco-ftd

El campo ngfw_state_required del plan se satisface implícitamente con el perfil (cada perfil sabe si decrypt está on / off). Si el plan declara ambos, deben coincidir — el loader falla con mensaje claro en caso contrario.

Ciclo apply / verify¶

El preflight del dashboard ejecuta:

ip-apply-ftd.sh --profile paranoid — emite los llamados REST del FMC, espera a que la propagación de la policy converja (FTD típicamente 30–90s).
ip-verify-ftd.sh --profile paranoid — lee de vuelta el estado actual de la policy y lo compara contra la matriz. Drift → ejecución bloqueada.

Verificación manual (raro; el preflight lo hace automáticamente):

scripts/ip-verify-ftd.sh --profile paranoid
# Esperado:
#   Profile 'paranoid' (cisco-ftd): PASS
#   - tls_inspection: true (esperado true)
#   - ids_ips: strict (esperado strict)
#   - anti_malware_signature: true (esperado true)
#   - … (todos los controles verificados)
#   - drift: ninguno

Después de la ejecución¶

ip-rollback-ftd.sh restaura el baseline del FTD (el estado de la policy capturado antes del apply). Es idempotente y seguro de llamar incluso cuando ningún perfil está aplicado — útil en paths de cleanup cuando el runner se cayó a mitad de la ejecución.

Combinar con Branch Office Simulation¶

Inspection Profile (este trabajo) y Branch Office Simulation (ADR 0008) son explícitamente ortogonales — el bench puede aplicar ambos, ninguno o uno solo. El plan combinado es el escenario realista de enterprise:

environment:
  bandwidth:                # Branch Office (ADR 0008)
    down_mbps: 100
    up_mbps: 30
  inspection_profile:       # este trabajo (ADR 0010)
    name: balanced
    vendor: cisco-ftd

Los plans combinados ingresan en v4.6 junto con el mapeo Palo Alto.

Cuándo hacer bypass (solo emergencia)¶

Si necesitas correr un test antes de que pase el verify del perfil (API del fabricante inestable, demo del cliente en 5 minutos), poné IP_GATING=observational en la UI del operador antes de iniciar el plan. La ejecución corre y el Anexo K marca el perfil como APLICADO PERO NO VERIFICADO con bandera roja. No usar esto frente a clientes.

Referencias¶

ADR 0010 — metodología
RFC 9411 — Benchmarking Methodology for Network Security Device Performance (marzo de 2023)
Informe Cisco FPR-3105 NetSecOPEN (UNH IOL, octubre de 2024) — la referencia de tercero contra la cual la matriz hace cross-reference
scripts/ip-apply-ftd.sh / ip-verify-ftd.sh / ip-rollback-ftd.sh — scripts del operador para Cisco FTD (PR-B v4.5)
dashboard/templates/annex-k-inspection-profile.md.tmpl — anexo del informe (PR-D v4.5)
dashboard/src/lib/preflight/inspection-profile-checks.ts — preflight check (PR-C v4.5)
ADR 0008 — Branch Office Simulation (compañera ortogonal)