Skip to content

Perfil de Inspeção — metodologia para o operador

Leia no seu idioma: English · Português · Español

Status do escopo (pós-congelamento de escopo 2026-05-10) — Perfil de Inspeção é agora Test Kind #3 no conjunto canônico de 7 Test Kinds. Schema combinatorial de Test Plan (10 componentes × 5 presets + custom 2^10) em dashboard/src/lib/test-plan/schema.ts. Ver ADR 0010 para o design lock original + primer CPOS para 2PC atômico entre DUT + Personas + Agents.

Resumo

Todo NGFW sob teste expõe ~13 controles de inspeção (decriptografia TLS, IPS, AMP, filtro de URL, etc.). Os datasheets dos fabricantes escolhem a combinação mais leve a dedo; comparar dois relatórios de fabricantes diferentes exige um passo de tradução que ninguém faz na prática. O bench TLSStress.Art resolve os dois problemas agrupando os controles em 5 perfis nomeados que mapeiam diretamente para a §6 da RFC 9411.

minimal    → só L3/L4 — o teto de throughput
balanced   → decrypt TLS + IPS no padrão — baseline do enterprise SMB
paranoid   → + AMP + App Control + filtro de URL + inspeção de arquivo
compliance → paranoid menos App Control + logging em verbosidade máxima
sandbox    → paranoid + detonação on-box de arquivo (mais lento)

Cada test plan declara opcionalmente um perfil. O motor de execução aplica no NGFW antes dos agentes subirem (scripts/ip-apply-<vendor>.sh) e remove no cleanup. O Anexo K do relatório atesta o estado real dos controles aplicados — incluindo detecção de divergência (drift) caso o fabricante mude algo silenciosamente.

Para o racional completo do design, veja ADR 0010.

Por que 5 perfis nomeados em vez de controles livres?

Dois modos de falha se os perfis não existirem:

  1. Comparação entre fabricantes vira intratável. "FTD com policy Balanced" e "Palo Alto com Strict Security Profile" habilitam conjuntos de controles diferentes. O cliente lendo dois relatórios não consegue dizer quais números estão comparando coisas equivalentes.
  2. Planejamento de capacidade esconde o custo. Os números do datasheet vêm da configuração mais leve; o deployment de produção liga mais controles e descobre o custo só depois de já estar em produção.

O agrupamento em 5 perfis produz um vocabulário independente do fabricante que mapeia para os mesmos controles que a §6 da RFC 9411 enumera. O cliente pode cruzar uma referência entre o Anexo K do TLSStress.Art e um relatório de fabricante com certificação NetSecOPEN (ex.: o relatório Cisco FPR-3105 / UNH IOL de outubro de 2024) sem tradução.

Matriz de controles

Controle minimal balanced paranoid compliance sandbox
ACL L3/L4 ✓ ✓ ✓ ✓ ✓
Inspeção TLS (TLS 1.3) ✓ ✓ ✓ ✓
IDS/IPS padrão strict strict strict
Anti-Malware (assinatura) ✓ ✓ ✓
Anti-Malware (detonação) ✓
App Control ✓ ✓
Filtro de URL ✓ ✓ ✓
Inspeção de arquivo ✓ ✓ ✓
Verbosidade de log std std std max max

Por que DNS Security não está em nenhum perfil: os agentes ainda não emitem padrões realistas de consulta DNS; ligar DNS Security mediria a resposta do fabricante a consultas sintéticas em volume baixo, o que é enganoso. DNS Security entra na matriz em v4.7+ quando a frota de agentes expuser um parâmetro de taxa de consultas DNS.

Cruzamento com a RFC 9411 §6

Feature da RFC 9411 §6        → Perfis que a incluem
─────────────────────────────  ────────────────────────────────────────
TLS Inspection                 balanced, paranoid, compliance, sandbox
IDS/IPS                        balanced (padrão), paranoid+ (strict)
Anti-Malware                   paranoid, compliance, sandbox
App Control                    paranoid, sandbox
URL Filtering                  paranoid, compliance, sandbox
File Inspection                paranoid, compliance, sandbox
Logging                        todos (a verbosidade que difere)
DNS Security                   nenhum (adiado para v4.7+)
WAF / DLP / CASB               nenhum (fora do escopo)
Sandboxing                     sandbox (apenas)
TLS 1.3 Decryption             absorvido no TLS Inspection — o bench é
                               TLS 1.3-only desde v3.6

Mapeamento de fabricante — Cisco FTD (MVP v4.5)

O operador não configura o FTD na mão. scripts/ip-apply-ftd.sh --profile <nome> faz o equivalente a estas chamadas FMC REST API:

Perfil Access Policy do 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

O script de apply resolve nomes de preset para IDs do FMC em runtime — um upgrade de software do fabricante que renomeie um preset falha o apply com "preset 'Balanced' not found, list of currently-shipped presets is X, Y, Z" em vez de aplicar silenciosamente a policy errada.

Palo Alto Networks entra em v4.6 com uma tabela equivalente.

Anexo K — atestação por execução

O Anexo K do relatório ("Inspection Profile Attestation") registra:

  • O nome do perfil que o operador selecionou
  • O estado esperado dos controles (a linha da matriz acima)
  • O estado observado dos controles, lido do device via API do fabricante
  • Qualquer divergência entre esperado e observado (bloqueia a execução em modo production)
  • O subset de features RFC 9411 §6 que esta execução satisfaz
  • Um ponteiro de cross-reference NetSecOPEN — ex.: "esta execução é comparável ao benchmark FPR-3105 HTTPS Throughput do relatório NetSecOPEN de outubro 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:                       # lido do FMC no 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: []                             # vazio = a execução prossegue
  netsecopen_cross_ref:
    classification: "RFC 9411 §6 subset (paranoid)"
    nearest_published_test: "FPR-3105 HTTPS Throughput (relatório NetSecOPEN out/2024)"
  attestation_sha256: "sha256:…"

Workflow do operador

Selecionando um perfil

No YAML do test plan:

- identifier: CAP-FIND-KNEE-30M-PARANOID
  display_name: "Capacity — paranoid inspection (30 min)"
  # … campos padrão do plan …
  environment:
    inspection_profile:
      name: paranoid
      vendor: cisco-ftd

O campo ngfw_state_required do plan é implicitamente satisfeito pelo perfil (cada perfil sabe se decrypt está on / off). Se o plan declarar ambos, eles precisam concordar — o loader falha com mensagem clara caso contrário.

Ciclo de apply / verify

O preflight do dashboard executa:

  1. ip-apply-ftd.sh --profile paranoid — emite as chamadas REST do FMC, espera a propagação da policy convergir (FTD tipicamente 30–90s).
  2. ip-verify-ftd.sh --profile paranoid — lê de volta o estado corrente da policy e compara contra a matriz. Drift → execução bloqueada.

Verificação manual (raro; o preflight faz isso automaticamente):

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 os controles verificados)
#   - drift: nenhum

Depois da execução

ip-rollback-ftd.sh restaura o baseline do FTD (o estado da policy capturado antes do apply). É idempotente e seguro de chamar mesmo quando nenhum perfil está aplicado — útil em paths de cleanup quando o runner travou no meio da execução.

Combinando com Branch Office Simulation

Inspection Profile (este trabalho) e Branch Office Simulation (ADR 0008) são explicitamente ortogonais — o bench pode aplicar os dois, nenhum ou um só. O plan combinado é o cenário realista de enterprise:

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

Plans combinados entram em v4.6 junto com o mapeamento Palo Alto.

Quando bypassar (emergência apenas)

Se você precisa rodar um teste antes do verify do perfil passar (API do fabricante flutuando, demo do cliente em 5 minutos), defina IP_GATING=observational na UI do operador antes de iniciar o plan. A execução roda e o Anexo K marca o perfil como APLICADO MAS NÃO VERIFICADO com bandeira vermelha. Não use isso em frente a clientes.

Referências

  • ADR 0010 — metodologia
  • RFC 9411 — Benchmarking Methodology for Network Security Device Performance (março de 2023)
  • Relatório Cisco FPR-3105 NetSecOPEN (UNH IOL, outubro de 2024) — a referência de terceiro contra a qual a matriz faz cross-reference
  • scripts/ip-apply-ftd.sh / ip-verify-ftd.sh / ip-rollback-ftd.sh — scripts do operador para Cisco FTD (PR-B v4.5)
  • dashboard/templates/annex-k-inspection-profile.md.tmpl — anexo do relatório (PR-D v4.5)
  • dashboard/src/lib/preflight/inspection-profile-checks.ts — preflight check (PR-C v4.5)
  • ADR 0008 — Branch Office Simulation (companhia ortogonal)