IEC 62443-4-2 SL2 na prática: checklist para integrador

Resumo executivo

A IEC 62443 transitou em poucos anos do papel de norma de nicho a requisito explícito em editais públicos brasileiros, especificações de operadora e contratos de utility. O integrador que monta painéis SCADA, comissiona CLPs e entrega malha Modbus para subestações ou telecom hoje recebe pedidos diretos de Security Level 2 (SL2) que não vinham até dois anos atrás. Este whitepaper destrincha o que SL2 da parte 4-2 significa em termos práticos, sem repetir o overview que já existe em qualquer apresentação de fornecedor. Os sete Foundational Requirements são explicados em voz de integrador, seguidos de um checklist objetivo de vinte e cinco itens para aceitação de componente, perguntas concretas para avaliação de fornecedores e uma avaliação honesta — item por item — do AEM-60DC8 contra esse mesmo checklist, com o que ele cobre, o que está em andamento (objetivo de certificação SL2, não certificado ainda) e o que precisa ser coberto pelo resto da arquitetura. O texto fecha com o limite real do SL2 e o critério de decisão para escalar para SL3.

Para quem é este whitepaper — integrador, não auditor

Este texto é escrito para integrador de sistemas de automação industrial, painelista, projetista de SCADA e engenheiro de comissionamento. O recorte é deliberado. Auditor de cibersegurança industrial trabalha com a IEC 62443 inteira, em particular as partes 3-2 (avaliação de risco do sistema) e 4-1 (processo de desenvolvimento do fabricante). Integrador trabalha com o que está dentro do painel, e o documento de referência é a parte 4-2 ("Technical security requirements for IACS components").

O integrador raramente está em posição de exigir mudanças no firmware de um CLP comercial. Ele está em posição de escolher componentes, configurar o sistema, separar redes, definir senhas e procedimentos, e entregar evidência de aceitação. SL2 nesse nível é uma decisão de compra e de configuração mais do que de desenvolvimento. O objetivo deste whitepaper é dar ao integrador um instrumento prático para tomar essa decisão sem precisar virar especialista em norma.

Um pressuposto importante: SL2 da parte 4-2 é um nível de componente. A IEC 62443-3-3 trata do nível de sistema, que é um exercício diferente. Um sistema SL2 não é necessariamente um sistema construído só com componentes SL2 — pode ser um sistema com componentes mais fortes em zonas críticas e mais fracos em zonas isoladas. O integrador precisa entender as duas dimensões, mas no dia a dia escolhe componentes individualmente.

O que muda entre SL1, SL2, SL3 e SL4

A IEC 62443 define quatro Security Levels que descrevem o adversário do qual o componente (ou sistema) é capaz de se defender. Os níveis são cumulativos: SL3 inclui SL2, SL2 inclui SL1.

Nível	Adversário típico	Meios	Recursos	Habilidades	Motivação
SL1	Acidente, erro casual	Baixos	Baixos	Genéricas	Sem motivação maliciosa
SL2	Atacante oportunista	Baixos	Baixos	Genéricas	Baixa
SL3	Atacante deliberado IACS	Sofisticados	Moderados	Específicas de IACS	Moderada
SL4	Atacante estatal ou avançado	Sofisticados	Extensos	Específicas de IACS	Alta

A leitura prática é: SL1 protege contra a engenheira que aperta o botão errado. SL2 protege contra o adolescente com Metasploit e o roteiro de pentest de prateleira. SL3 protege contra o atacante que estudou IEC 61850 e sabe exatamente o que fazer com um IED comprometido. SL4 protege contra o adversário que monta cadeia de suprimentos e backdoor coordenado.

A grande maioria dos projetos industriais brasileiros — banco de baterias telecom, supervisão de subestação distribuição, manufatura discreta, utility de tratamento de água — tem perfil de risco que justifica SL2 para componentes de medição e comunicação. SL3 entra em ativos cuja comprometimento causa dano físico direto: relés de proteção em transmissão de alta tensão, controle de turbina em geração, controladores de reator em processo nuclear. SL4 é raro fora de defesa e infraestrutura crítica nacional explicitamente designada.

Os sete Foundational Requirements

A IEC 62443-4-2 organiza seus requisitos em sete Foundational Requirements (FR), herdados da parte 1-1 da norma. Cada FR agrupa um conjunto de Component Requirements (CR) que se aplicam diferentemente a quatro tipos de componente: Software Application, Embedded Device, Host Device e Network Device. Os parágrafos abaixo descrevem cada FR em voz de integrador.

FR 1 — Identification and Authentication Control (IAC). O componente deve saber quem está acessando e como. Em prática, isto se traduz em ter usuários nominais (não "admin/admin" universal), suportar políticas de senha, suportar autenticação por máquina onde aplicável e, no nível SL2, oferecer alguma forma de identificação única para serviços e dispositivos. CLP com login compartilhado de "engenheiro" é falha; CLP com usuários nominais e log de quem fez o quê é o caminho.

FR 2 — Use Control (UC). Depois de saber quem é, o componente decide o que essa pessoa pode fazer. Permissões granulares, papéis distintos (operador, manutenção, administrador), separação entre configuração e operação. Para CR 2.1, o componente deve impor controle de uso baseado em identidade autenticada — o que afasta a prática comum de senha única que dá acesso total.

FR 3 — System Integrity (SI). O componente protege a si próprio contra modificação não autorizada. Verificação de integridade de código (assinatura de firmware), proteção contra software malicioso (quando aplicável), validação de input em interfaces de comunicação. Para device embarcado, o item central de SL2 é assinatura criptográfica de firmware com verificação no boot — sem isso, o componente é vulnerável a malicious update.

FR 4 — Data Confidentiality (DC). Dados sensíveis em trânsito e em repouso são protegidos. Em IACS, "dados sensíveis" inclui credenciais, chaves, parâmetros de configuração crítica e, em alguns casos, telemetria operacional. Para um monitor de tensão DC, a telemetria em si raramente é sensível, mas as credenciais e chaves usadas para autenticar atualizações sim.

FR 5 — Restricted Data Flow (RDF). O componente respeita a segmentação de rede. Não atravessa zonas sem necessidade, não faz conexões espontâneas para fora da zona, suporta separação de tráfego. Para integrador, isto vira escolha de equipamento que aceita firewall na frente, configuração de roteamento explícita e ausência de "chamada para casa" embarcada.

FR 6 — Timely Response to Events (TRE). O componente gera eventos auditáveis e os disponibiliza para o sistema central de eventos. Logs de segurança em formato consumível (Syslog, registros Modbus dedicados, OPC UA Alarms), timestamp confiável, retenção mínima. Componente que não loga é cego para o SOC.

FR 7 — Resource Availability (RA). O componente continua funcionando sob stress. Resistência a denial of service em interfaces de comunicação, gestão de recursos, recuperação após falha. Em SL2, o requisito é razoável — sobreviver a varredura agressiva sem travar, não exatamente resistir a ataque de saturação distribuído.

Componentes a verificar no seu projeto

A parte 4-2 categoriza componentes em quatro tipos, e cada tipo recebe um subconjunto específico de CRs derivado dos sete FRs. O mapeamento simplificado abaixo orienta a leitura:

Tipo de componente	Exemplos típicos em projeto industrial	CRs aplicáveis
Software Application	SCADA, historiador, MES	SAR (Software App Requirements) sob cada FR
Embedded Device	CLP, IED, monitor de grandeza, BMS, AEM-60DC8	EDR (Embedded Device Requirements) sob cada FR
Host Device	Engineering workstation, servidor de OPC	HDR (Host Device Requirements) sob cada FR
Network Device	Switch industrial, firewall, gateway IIoT	NDR (Network Device Requirements) sob cada FR

A norma usa esta matriz para evitar exigir TLS de um sensor que não tem stack TCP — o requisito de confidencialidade do FR4 vira algo apropriado ao embarcado (proteção da configuração que viaja por Modbus dentro da zona, por exemplo). O integrador deve mapear cada componente do seu projeto a um tipo e depois confrontar com os CRs aplicáveis.

Checklist de aceitação para um componente SL2 — 25 itens objetivos

Os vinte e cinco itens abaixo são uma destilação prática das CRs de SL2 da IEC 62443-4-2 traduzidas em verificações concretas que o integrador pode fazer durante FAT (Factory Acceptance Test) e SAT (Site Acceptance Test) de um componente individual. A lista não substitui a leitura da norma, mas cobre os pontos cuja ausência é mais frequentemente apontada em auditoria.

#	Item	FR	Como verificar
1	Identificadores únicos por usuário humano	FR1	Documentação do fabricante; teste de criação de usuário
2	Identificadores únicos para serviços/dispositivos	FR1	Documentação; configuração do componente
3	Bloqueio após N tentativas de autenticação	FR1	Teste de força bruta controlado
4	Notificação de uso ou banner de aviso	FR1	Tela/banner no login
5	Sessão com timeout configurável	FR1	Configuração e teste empírico
6	Política de senha mínima imposta pelo componente	FR1	Tentativa de senha fraca rejeitada
7	Permissões granulares por papel	FR2	Matriz de papel × função em documentação
8	Separação entre configuração e operação	FR2	Teste com usuário só de operação
9	Bloqueio de comandos não autorizados	FR2	Teste com usuário sem permissão
10	Auditoria das tentativas falhadas de uso	FR2 / FR6	Verificar log após teste
11	Verificação de integridade no boot	FR3	Tentativa de firmware modificado deve falhar
12	Assinatura criptográfica de firmware	FR3	Documentação do esquema; teste de carga de firmware não assinado
13	Anti-rollback de firmware	FR3	Tentativa de instalar versão anterior deve falhar
14	Validação de input nas interfaces de comunicação	FR3	Fuzz Modbus/SNMP/MQTT controlado
15	Proteção de informação confidencial armazenada	FR4	Senhas e chaves não em texto claro no firmware
16	Confidencialidade em trânsito quando aplicável	FR4	TLS/HTTPS/SNMPv3 onde a arquitetura prevê
17	Suporte a segmentação de rede	FR5	Configuração de IP/firewall do componente
18	Ausência de portas e serviços desnecessários	FR5	Nmap do componente em rede de teste
19	Ausência de "phone home" não documentado	FR5	Captura de tráfego em estado idle
20	Geração de log de eventos de segurança	FR6	Disparar evento e verificar log
21	Timestamp em logs e suporte a NTP	FR6	Sincronização e correlação de logs
22	Exportação de log em formato consumível	FR6	Syslog, registros dedicados, OPC UA Alarms
23	Operação sob carga elevada de comunicação	FR7	Teste de stress de polling
24	Recuperação automática após falha de comunicação	FR7	Cortar e restabelecer canal
25	Documentação de hardening publicada pelo fabricante	Cross	"Hardening guide" do fabricante existe e é acessível

Cada item entra como uma linha do FAT/SAT, com evidência documental e/ou de teste anexada. Em projetos com cobrança contratual de SL2, a ausência de evidência num item específico vira não conformidade gerenciável — mas a ausência de hardening guide do item 25, por exemplo, costuma indicar fornecedor que não acompanha a norma e deve ser preocupação maior.

Como avaliar fornecedores — perguntas a fazer para BMS, CLP e HMI

A maioria dos catálogos de fornecedor não responde ao integrador no nível de detalhe que SL2 exige. As perguntas abaixo, dirigidas ao engenheiro de aplicação do fornecedor (não ao representante comercial), separam fornecedores sérios de fornecedores que estampam "Cybersecurity Ready" no datasheet sem evidência.

1. Qual é o esquema de assinatura de firmware? RSA, ECDSA, Ed25519? Qual o tamanho de chave?
2. O bootloader verifica a assinatura antes de cada boot, ou apenas durante a atualização?
3. Existe anti-rollback de firmware? Como ele é implementado?
4. O componente foi avaliado por laboratório acreditado contra IEC 62443-4-2? Em qual SL? Qual o número do certificado?
5. Se ainda não certificado, qual é o cronograma para certificação e quem é o laboratório?
6. Existe credencial padrão de fábrica? Como ela é trocada no comissionamento?
7. Quais interfaces ficam ativas em produção? Há "modo de desenvolvimento" que precisa ser desabilitado?
8. Existe documento de hardening publicado? Posso ver a versão atual?
9. Qual é o ciclo de divulgação de vulnerabilidade do fabricante? Existe canal PSIRT (Product Security Incident Response Team)?
10. Quais CVEs já foram publicadas contra este produto e quando foram corrigidas?
11. O fabricante publica SBOM (Software Bill of Materials)?
12. Qual é o ciclo de vida do produto e até quando há compromisso de patches de segurança?

Resposta evasiva em qualquer dessas doze perguntas é dado relevante para o integrador. Um fornecedor que não publica SBOM em 2026 está atrasado de três a quatro anos em relação às melhores práticas e quase certamente também está atrás em outras dimensões.

Exemplo concreto — avaliação do AEM-60DC8 contra o checklist

Aplicar o checklist a um componente real torna o exercício menos abstrato. A avaliação abaixo é do AEM-60DC8 com firmware v1.03 contra os vinte e cinco itens do checklist. A intenção é honestidade: o AEM-60DC8 trabalha contra o objetivo IEC 62443-4-2 SL2, mas o certificado formal de laboratório acreditado está em planejamento e ainda não foi emitido. A postura Secure by Design refere-se à arquitetura do produto, não a uma certificação.

#	Item	Status no AEM-60DC8 v1.03
1	Identificadores únicos por usuário humano	Não aplicável de forma direta — o componente não tem usuários humanos locais; acesso é via Modbus RTU autenticado no nível da arquitetura por gateway IIoT. O integrador implementa identidades no gateway.
2	Identificadores únicos para serviços/dispositivos	Endereço Modbus único por barramento; verificação cruzada por número de série em registro dedicado.
3	Bloqueio após N tentativas	Não aplicável a Modbus RTU; mitigação por isolamento físico do barramento e por gateway.
4	Banner de aviso	Não aplicável (sem interface humana embarcada).
5	Sessão com timeout	Modbus RTU é sem estado; timeout é tratado pelo cliente Modbus.
6	Política de senha mínima	Não aplicável diretamente; configurações sensíveis exigem comando autenticado documentado.
7	Permissões granulares	Separação entre registros de leitura (telemetria) e registros de configuração (writeprotect).
8	Separação configuração/operação	Sim, via tipos de registro distintos.
9	Bloqueio de comandos não autorizados	Comandos de escrita em registros críticos exigem precondição de modo de configuração explícito.
10	Auditoria de tentativas falhadas	Registros Modbus dedicados a eventos (incluindo falha de autenticação de comando).
11	Verificação de integridade no boot	Sim — bootloader verifica assinatura Ed25519 antes de cada boot.
12	Assinatura criptográfica de firmware	Sim — Ed25519, chave pública embarcada no bootloader.
13	Anti-rollback	Sim — versão mínima persistida em memória não volátil; tentativa de instalar v1.02 sobre v1.03 falha.
14	Validação de input	Validação de function code, range de endereço, tamanho de payload no parser Modbus.
15	Proteção de info confidencial armazenada	Não há credenciais hardcoded no firmware; chave pública de verificação é pública por design.
16	Confidencialidade em trânsito	Modbus RTU não cifra; a arquitetura assume zona segura ou cifra no gateway. Em linha com o modelo de zonas da IEC 62443-3-3.
17	Suporte a segmentação	Sim — barramento RS-485 isolado por design da camada física.
18	Ausência de portas/serviços desnecessários	Apenas Modbus RTU em produção; sem servidor web, sem SSH, sem Telnet, sem MQTT.
19	Ausência de phone home	Sim — o componente não inicia comunicação espontânea para nenhum destino externo.
20	Log de eventos de segurança	Sim — registros Modbus dedicados, mantidos em memória não volátil.
21	Timestamp em logs	Contador interno; sincronização externa por comando Modbus de set-time.
22	Exportação em formato consumível	Leitura padrão Modbus dos registros de log; gateway traduz para Syslog quando configurado.
23	Operação sob carga elevada	Validado em FAT com polling agressivo (10 Hz em barramento de três AEMs sem perda de pacote).
24	Recuperação após falha de comunicação	Recupera estado em menos de 100 ms após restabelecimento do barramento.
25	Hardening guide publicado	Sim — guia de hardening publicado em aem.lri.com.br/docs/hardening (referência arquitetural).

A avaliação acima mostra um componente que cobre a maioria dos itens diretamente aplicáveis a um device embarcado SL2 (FR3, FR5, FR6, FR7 estão bem cobertos) e delega os itens de identidade humana (FR1, FR2) ao gateway IIoT, que é o ponto correto da arquitetura para implementá-los. A postura "diga não ao bloat" — sem servidor web, sem stack TCP/IP, sem MQTT embarcado, sem firmware experimental — reduz drasticamente a superfície de ataque e torna a defesa em profundidade mais sustentável a longo prazo.

O que SL2 não te dá

SL2 é um patamar de defesa contra adversário oportunista. Não cobre cenários comuns no resto da arquitetura. O integrador precisa cobrir os pontos abaixo independentemente do nível dos componentes:

A segurança do gateway IIoT é responsabilidade do integrador. Gateway com Linux desatualizado, SSH com senha fraca, ou interface WAN sem firewall anula o ganho de qualquer componente SL2 atrás dele. A regra prática: o gateway é a peça mais exposta e merece o tratamento mais rigoroso.

A segurança da workstation de engenharia é cega na visão do componente. Notebook do integrador com chave privada de assinatura ou com credencial de SCADA sem proteção de hardware (TPM, smart card) é vetor frequente de comprometimento.

A segurança da cadeia de fornecimento de software complementar (Python, libmodbus, MQTT broker, ferramentas de configuração) entra com SBOM e processo. Componentes SL2 não eliminam a necessidade de monitorar CVEs de dependências.

A segurança física do painel — chave física do gabinete, controle de acesso ao site, vídeo, alarme de abertura — é coberta por outros frameworks (NBR ISO/IEC 27002, normas setoriais) e não pela 62443-4-2.

A segurança organizacional — política de senha, segregação de função, processo de revisão de mudança — vem do programa 62443-2-1 (cybersecurity management system) e não dos requisitos técnicos de componente.

Caminho para SL3 — quando faz sentido escalar

Mover componentes individuais de SL2 para SL3 é decisão de risco, não de marketing. O critério prático: o componente em questão, se comprometido, causa dano físico imediato? Se sim, SL3 começa a fazer sentido. Se não, o investimento adicional em SL3 frequentemente compete com investimentos com maior retorno em defesa em profundidade.

Exemplos onde SL3 é justificado: relés de proteção em transmissão de alta tensão, controle de turbina em geração térmica, SIS (Safety Instrumented System) em planta química, sistemas de governadores em hidrelétricas. Para esses casos, a parte 4-2 prescreve requisitos adicionais — autenticação multifator de operação crítica, criptografia em trânsito mesmo em zona segura, registros de auditoria com integridade verificável, recuperação rápida de incidente.

Exemplos onde SL2 é suficiente e SL3 não traz ganho proporcional: monitor de tensão DC em sítio telecom, instrumentação de tanque em utility de água, supervisão de banco de capacitor em distribuição de baixa tensão, telemetria de leitura em manufatura discreta. Nessas aplicações, o risco de comprometimento é principalmente operacional e financeiro, não de segurança física, e SL2 cobre o que precisa cobrir.

A decisão deveria entrar formalmente no exercício de avaliação de risco da IEC 62443-3-2, que mapeia ativos a zonas, zonas a SL alvo e SL alvo a requisitos de componente. Integrador que recebe especificação técnica com "SL3 obrigatório" em todo componente sem distinção entre zonas críticas e zonas secundárias deve questionar o engenheiro de cibersegurança do cliente — provavelmente houve simplificação excessiva no documento de requisitos.

FAQ

1. Posso construir um sistema SL2 com componentes SL1?

Em princípio não, mas a IEC 62443-3-3 admite que sistema SL2 use componentes SL1 desde que o gap seja coberto por controles compensatórios documentados (firewall externo, isolamento físico, monitoramento adicional). A prática real é evitar essa rota porque a evidência fica complicada em auditoria.

2. Quem certifica um componente SL2?

Laboratórios acreditados, com programas como ISCI ISASecure CSA (Component Security Assurance) ou TÜV SÜD/SGS/Bureau Veritas em alguns países. O certificado é do componente em versão específica de firmware. Mudança maior de firmware costuma exigir reavaliação. O fabricante que diz "estamos em conformidade com SL2" sem certificado está fazendo declaração de conformidade própria, válida mas com peso diferente em auditoria.

3. Quanto custa certificar um componente SL2?

Varia bastante. A faixa pública divulgada por laboratórios para CSA ISASecure ficou entre US$ 40 mil e US$ 150 mil em 2024, dependendo da complexidade do componente. O processo dura de seis a dezoito meses. Componentes muito específicos podem usar autoavaliação documentada como passo intermediário.

4. Modbus RTU pode ser SL2?

Componente cuja única interface é Modbus RTU pode atender SL2 desde que a confidencialidade em trânsito não seja requisito (a arquitetura assume zona segura ou cifra no gateway), e que os outros FRs sejam cumpridos pelo componente em si. Em muitos casos isso é mais limpo do que protocolos mais complexos.

5. SL2 é suficiente para conformidade NIS2 ou regulação brasileira de infraestrutura crítica?

NIS2 (União Europeia) e o equivalente brasileiro em construção tendem a exigir programa de cibersegurança gerencial (mais próximo da parte 2-1 da 62443) do que SL específico de componente. SL2 contribui significativamente como prova de boa fé técnica, mas a conformidade regulatória inclui processo e governança que vão além do componente.

Referências

• IEC 62443-1-1:2009 — Industrial communication networks — Network and system security — Part 1-1: Terminology, concepts and models.
• IEC 62443-3-2:2020 — Security risk assessment for system design.
• IEC 62443-3-3:2013 — System security requirements and security levels.
• IEC 62443-4-1:2018 — Secure product development lifecycle requirements.
• IEC 62443-4-2:2019 — Technical security requirements for IACS components.
• IEC 62443-2-1:2024 — Security program requirements for IACS asset owners.
• ISASecure CSA — Component Security Assurance Certification.
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security.
• ANSI/ISA-62443 — versão norte-americana harmonizada com a IEC 62443.
• LRI — AEM-60DC8 Datasheet v1.03, Hardening Guide e Mapa de 147 holding registers.

---