Skip to content

Testes alinhados ao NetSecOPEN com TLSStress.Art — primer do operador

Outros idiomas: English · Português · Español

Audiência: operador NGFW rodando um banco de testes TLSStress.Art que precisa produzir resultados no formato publicado por Cisco, Palo Alto, Fortinet, Check Point, e outros vendors em seus reports de cert NetSecOPEN (Cisco Secure Firewall 1220CX, 3105, etc.).

Docs companheiros: NETSECOPEN_ALIGNMENT.md (vocabulário + mapeamento RFC 9411), INSPECTION_PROFILE.md (os 5 perfis nomeados), STRESS_ENGINES_CATALOG.md § Which engine for which Test Kind (os 6 tipos de teste).

TL;DR

# 1. Escolha um plano alinhado ao NetSecOPEN (3 prontos)
#    via dashboard /tests/new → Template: "NetSecOPEN cert §7.2 — TCP/HTTP CPS"
# 2. Aperte Run. O bench impõe RFC 9411 §4.3.4 + thresholds §7.x.3.3.
# 3. Baixe o report → escolha template "cert" → PDF/HTML/Markdown.
# 4. A audit chain (NSO-20) anexa SHA-256 por teste + assinatura Cosign
#    para o cliente verificar que o report não foi adulterado.

O bench é NetSecOPEN-aligned, não (ainda) um Approved Tool. Significa: todo report que você entrega bate exatamente com o formato publicado, mas o logo do consórcio NetSecOPEN na capa do report é deliberadamente omitido até que nossa campanha de membership (Phase D-E) esteja completa. Veja §"Por que ainda não somos um Approved Tool".

O que é o NetSecOPEN

NetSecOPEN é um consórcio da indústria que publica:

  1. RFC 9411 — Benchmarking Methodology for Network Security Device Performance (Mar 2023), a metodologia chancelada pelo IETF para medir performance de NGFW / IDS / IPS.
  2. Approved test tools — uma lista curta (atualmente Keysight CyPerf + BreakingPoint, Viavi/Spirent CyberFlood) auditada pelo consórcio para produzir resultados reproduzíveis.
  3. Cert reports — vendors rodam seus produtos por uma das ferramentas aprovadas em um lab aprovado (e.g. EANTC) e publicam um cert report. Esses reports seguem um layout fixo de 16 tabelas.

Quando um cliente pergunta "qual seu throughput NetSecOPEN?" ele está perguntando sobre a Tabela 6 do cert report (HTTPS throughput @ 256 KByte object size, Inspection Profile = balanced ou paranoid).

O que o TLSStress.Art entrega

Um cert report byte-a-byte idêntico no formato a um cert NetSecOPEN da Cisco / Palo Alto / Fortinet. DUT de exemplo: Cisco Secure Firewall 1220CX. Mix de exemplo: Healthcare. Report de exemplo: ver docs/sample-reports/ (entregue no NSO-22).

Todo report tem:

Elemento RFC 9411 § Módulo TLSStress.Art
Tabelas 1-16 (layout cert) §5 + Apêndice C NSO-16 KPI aggregator
Stability graphs (sustain phase) §4.3.4 NSO-17 stability graph renderer
Pie charts (Figuras 2-3) §7.1 NSO-18 pie chart renderer
Render PDF/HTML/Markdown §5 reporting NSO-19 report renderer
Audit chain SHA-256 por teste §5.1 traceability NSO-20 audit chain
Assinatura Cosign no chain tip (best practice) NSO-20 cosign_bundle

Passo 1 — Escolha um plano alinhado

Abra o dashboard → Tests / New → dropdown Template. Você verá entradas agrupadas em NetSecOPEN cert:

Template RFC 9411 § Espelha tabela do cert
App Mix Performance — Healthcare §7.1 Tabela 2 + Figura 2
App Mix Performance — Education §7.1 Tabela 2 + Figura 3
TCP/HTTP CPS por object size §7.2 Tabela 7
HTTP Throughput por object size §7.3 Tabela 8
TCP/HTTP TTFB+TTLB @ 50% CPS §7.4 Tabela 9
TCP/HTTPS CPS por object size §7.6 Tabela 11
HTTPS Throughput por object size §7.7 Tabela 12
TCP/HTTPS TTFB+TTLB @ 50% CPS §7.8 Tabela 13
Concurrent connections §7.5 + §7.9 Tabela 3/4 linha 6
Detection Rate — corpus CVE Apêndice A.2 Tabela 15
Under Load — Detection Rate Apêndice A.3 Tabela 16

Escolha o que corresponde à tabela do cert que você deve ao cliente.

Passo 2 — Escolha sua DUT class

Per RFC 9411 §4.2 + Apêndice B, o bench auto-classifica o DUT em XS / S / M / L baseado no throughput rated. Isso determina a contagem de regras ACL e outros tunables.

Classe Throughput Regras ACL (block-only baseline)
XS ≤ 1 Gbit/s 65
S 1 – 5 Gbit/s 120
M 5 – 10 Gbit/s 230
L > 10 Gbit/s 560

O bench aplica o rule set certo automaticamente (módulo NSO-5). Override via dashboard → Tests → Advanced → DUT class.

Passo 3 — Confirme o preflight

Antes do teste iniciar, o painel preflight roda 16 checks (módulo NSO-6). O painel é dividido em três tiers de severidade:

  • PASS (verde) — pronto
  • WARN (amarelo) — prossiga, o report vai notar a lacuna
  • FAIL (vermelho) — bench se recusa a iniciar

Requisitos hard (FAIL na violação):

  • DUT em modo Inline (não TAP / SPAN)
  • Fail-Open desabilitado
  • TLS Inspection habilitado (para testes HTTPS)

Recommended (FAIL se desabilitado sem reason; WARN se reason consta):

  • IDS/IPS, Antivirus, Anti-Spyware, Anti-Botnet, Anti-Evasion, Logging, App-ID

Se está testando uma postura NGFW baseline, clique em "Apply NetSecOPEN balanced profile" — o bench configura todas as 8 features RECOMMENDED automaticamente.

Passo 4 — Run

Aperte Run. O orchestrator (NSO-7 FSM) percorre a 11-state phase machine:

init → ramp_up → sustain → ramp_down → analyze → done

Per RFC 9411 §4.3.4: - init ≥ 5s - sustain ≥ 300s (a janela do stability graph) - Sampling interval ≤ 2000 ms

O dashboard mostra barra de progresso live + o stability graph sendo desenhado em real time. Se failed_tx exceder 0.001% ou fwd_rate_dev exceder 5%, o teste é flagado FAIL (per thresholds §7.x.3.3).

Passo 5 — Baixe o report

Após done, clique Download report → escolha template:

Template Use para
cert Entregável ao cliente no formato Cisco/Keysight/Viavi
lab Review interno / collateral marketing / share-out de champion

Cada template tem 3 formatos de saída:

  • .pdf — print-ready, SVGs embarcados
  • .html — single-file com CSS + SVGs inline
  • .md — Markdown para pinning git/audit

A audit chain (NSO-20) é anexada como audit-chain.json ao lado do report. O cliente verifica via:

tlsstress-art audit verify --chain audit-chain.json --report report.pdf

Por que ainda não somos um Approved Tool

O programa Approved Tool do NetSecOPEN lista atualmente exatamente dois vendors (Keysight + Viavi/Spirent). O processo de aprovação exige:

  1. Membership do consórcio ($XX,XXX/ano de sponsorship)
  2. Validação por lab independente (tipicamente EANTC) rodando nossa ferramenta contra um DUT de referência e confirmando resultados dentro da tolerância
  3. Auditoria de reproducibility — code review + disclosure do corpus de teste

Status (per discuss_netsecopen_rfc9411.md roadmap 5-fases):

Fase Status
A — Technical Readiness (NSO-1..22) ✅ Em produção (v3.7.0)
B — Independent Validation ⚪ Não iniciado
C — Licensing / Corporate setup ⚪ Não iniciado
D — Membership engagement ⚪ Não iniciado
E — Approval Campaign ⚪ Não iniciado

Timeline estimada full: 24-36 meses.

Enquanto isso, shipamos reports com o label inequívoco "NetSecOPEN-aligned" (não "NetSecOPEN-certified"). Formato idêntico; só falta o endorsement do consórcio.

Cross-refs