IEC 62443-4-1: o ciclo de vida de desenvolvimento seguro para produtos industriais

O que é a IEC 62443-4-1?

A IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, foi publicada em janeiro de 2018. Segundo o âmbito da própria norma, especifica requisitos de processo para o desenvolvimento seguro de produtos usados em sistemas de automação e controlo industrial. O ciclo de vida que define abrange a definição de requisitos de segurança, o design seguro, a implementação segura, a verificação e validação, a gestão de defeitos, a gestão de patches e o fim de vida do produto.

Aplica-se a quem desenvolve e mantém um produto: o fornecedor do produto que fabrica controladores, dispositivos embebidos, equipamento de rede, software de host ou aplicações. Não se aplica ao integrador nem ao utilizador do produto, que têm as suas próprias partes da série. A ISA publica a série como ISA/IEC 62443.

A norma descreve requisitos de processo, políticas e procedimentos, e não funcionalidades técnicas de segurança. Os requisitos técnicos para componentes estão na IEC 62443-4-2.

As oito práticas da IEC 62443-4-1

Os requisitos estão agrupados em oito práticas, cada uma com uma abreviatura curta que antecede os identificadores dos seus requisitos. A ISA Global Cybersecurity Alliance enumera 47 requisitos no total:

Prática	Requisitos	O que abrange
1. Gestão da segurança (SM)	SM-1 a SM-13	Planear e executar o processo de segurança: responsabilidades, competências, segurança do ambiente de desenvolvimento, chaves privadas, componentes fornecidos externamente e de terceiros, verificação do processo, melhoria contínua
2. Especificação dos requisitos de segurança (SR)	SR-1 a SR-5	Contexto de segurança do produto, modelo de ameaças, requisitos de segurança do produto e respetiva revisão
3. Segurança desde a conceção (SD)	SD-1 a SD-4	Princípios de design seguro, design de defesa em profundidade, revisão do design, boas práticas de design
4. Implementação segura (SI)	SI-1 a SI-2	Revisão da implementação de segurança e normas de programação segura
5. Testes de verificação e validação da segurança (SVV)	SVV-1 a SVV-5	Testes de requisitos, testes de mitigação de ameaças, testes de vulnerabilidades, testes de intrusão, independência dos testadores
6. Gestão de problemas relacionados com a segurança (DM)	DM-1 a DM-6	Receber, rever, avaliar, resolver e divulgar problemas de segurança no produto
7. Gestão de atualizações de segurança (SUM)	SUM-1 a SUM-5	Qualificar, documentar e entregar atualizações de segurança, atempadamente
8. Orientações de segurança (SG)	SG-1 a SG-7	Documentação para o utilizador sobre defesa em profundidade, reforço da segurança, operação segura, gestão de contas e eliminação

Prática 6: gestão de problemas relacionados com a segurança (DM)

A DM é a prática que uma PSIRT reconhece como sua. Segundo a ISAGCA, os seus processos servem para tratar problemas relacionados com a segurança de um produto configurado de acordo com a sua estratégia de defesa em profundidade. Os seus seis requisitos acompanham um problema desde o relatório até ao encerramento:

• DM-1: Receber notificações de problemas relacionados com a segurança
• DM-2: Rever problemas relacionados com a segurança
• DM-3: Avaliar problemas relacionados com a segurança
• DM-4: Resolver problemas relacionados com a segurança
• DM-5: Divulgar problemas relacionados com a segurança
• DM-6: Revisão periódica da prática de gestão de defeitos de segurança

Em termos simples: receber relatórios, verificá-los, avaliá-los, corrigi-los, informar os utilizadores e rever o próprio processo.

Esta sequência é o ciclo de vida da gestão de vulnerabilidades com outro nome, e é na DM-1 e na DM-5 que entra a divulgação coordenada de vulnerabilidades. A divulgação pode ser publicada como aviso CSAF, com uma declaração VEX para as versões não afetadas.

Prática 7: gestão de atualizações de segurança (SUM)

A SUM retoma o trabalho no ponto em que a DM decide uma correção. Na síntese da ISAGCA, os seus processos garantem que as atualizações de segurança para o hardware, software ou firmware do produto são testadas quanto a regressões e disponibilizadas aos utilizadores em tempo útil. Os cinco requisitos são:

• SUM-1: Qualificação de atualizações de segurança
• SUM-2: Documentação de atualizações de segurança
• SUM-3: Documentação de atualizações de segurança de componentes dependentes ou do sistema operativo
• SUM-4: Entrega de atualizações de segurança
• SUM-5: Entrega atempada de patches de segurança

A SUM-3 é a que chega à sua cadeia de abastecimento: atualizações de componentes e sistemas operativos de que o seu produto depende. Num produto embebido construído sobre uma distribuição Linux, isso pode representar a maior parte dos patches que distribui.

Níveis de maturidade

A IEC 62443-4-1 não pergunta se um processo existe; pergunta quão maduro é. Utiliza quatro níveis de maturidade, baseados no CMMI for Development:

Nível	Significado
ML1 Initial	Os processos são executados de forma ad hoc ou não documentada
ML2 Managed	Os processos estão documentados e descrevem como a atividade é realizada e gerida
ML3 Defined (Practiced)	Os processos estão documentados, são executados e são repetíveis
ML4 Improving	Os processos são melhorados ao longo do tempo com métricas de desempenho e eficácia

A diferença entre ML2 e ML3 é a prática. Um processo DM escrito pode ser ML2. ML3 significa que o processo foi executado e repetido: problemas recebidos, avaliados e encerrados, atualizações entregues, com os registos que o demonstram.

Certificação

• ISASecure SDLA. O programa Security Development Lifecycle Assurance certifica o processo de ciclo de vida de uma organização de desenvolvimento segundo a IEC 62443-4-1. As avaliações são realizadas por laboratórios SDLA credenciados, acreditados como organismos de avaliação da conformidade.
• Organismos de certificação e IECEE CB Scheme. Organismos de ensaio e certificação como a Applus+ e a TÜV Rheinland avaliam fornecedores face à 62443-4-1 e indicam o nível de maturidade alcançado, incluindo ao abrigo do IECEE CB Scheme, aplicável em mais de 50 países.

Um certificado 62443-4-1 abrange o processo de desenvolvimento do fornecedor, não um único produto. Os produtos são avaliados separadamente face à 62443-4-2.

Como a 62443-4-1 se relaciona com o resto da série

• IEC 62443-4-2, requisitos técnicos de segurança para componentes IACS: o que o produto tem de ser capaz de fazer. A 4-1 é a forma como o constrói e mantém.
• IEC 62443-3-3, requisitos de segurança do sistema e níveis de segurança: os requisitos técnicos equivalentes ao nível do sistema.
• IEC 62443-2-4, requisitos do programa de segurança para prestadores de serviços IACS: os integradores e prestadores de manutenção que instalam e dão assistência ao seu produto nas instalações do proprietário do ativo, e que dependem das suas atualizações e orientações de segurança.

Mapear a IEC 62443-4-1 para o trabalho de uma PSIRT

Atividade da PSIRT	Onde se enquadra na 62443-4-1
Receção de relatórios de vulnerabilidades	DM-1
Triagem e análise	DM-2, DM-3
Remediação	DM-4, SUM-1
Avisos de segurança e divulgação	DM-5, SUM-2
Patches para componentes de terceiros	SUM-3, com SM-9 e SM-10 sobre componentes fornecidos externamente e de terceiros
Lançamento da correção	SUM-4, SUM-5
Métricas e revisão do processo	DM-6, SM-13

Este mapeamento é nosso, por título de requisito. A norma não menciona as PSIRT pelo nome; o mesmo trabalho está descrito no PSIRT Services Framework da FIRST e na ISO/IEC 30111.

As SBOM como evidência para DM e SUM

Os títulos dos requisitos de 2018 não mencionam SBOM. Mas muitos dos problemas de segurança num produto industrial estão em componentes que o respetivo fornecedor não escreveu: o kernel Linux, o OpenSSL, o BusyBox, uma pilha de protocolos. Responder à DM-2 e à DM-3 perante um novo aviso de segurança implica saber que produtos e versões contêm o componente afetado. Documentar atualizações SUM-3 implica saber com que versões de componentes cada versão foi distribuída. No ML3, essas respostas precisam de registos que as sustentem.

Uma lista de componentes escrita à mão, ou uma análise da árvore de código-fonte, fica desatualizada. Uma SBOM do build que produziu a versão não fica, desde que o próprio build seja registado.

Onde entra o CRACI

O CRACI não certifica nada ao abrigo da IEC 62443 e não gere o seu processo de desenvolvimento. Os registos do CRACI podem servir de evidência para partes dele: o inventário de componentes de cada versão e a monitorização de builds distribuídos quanto a novas vulnerabilidades.

O CRACI executa builds de GitHub Actions, incluindo builds Yocto, em runners próprios e regista os pacotes que cada job realmente obteve, incluindo dependências transitivas, pacotes restaurados de caches e dependências que nenhum lockfile lista. Cada SBOM indica um estado de completude e é exportada em CycloneDX ou SPDX. As SBOM monitorizadas são reavaliadas continuamente, o histórico de builds mostra que builds anteriores continham uma dependência vulnerável e a vista de inventário mostra que versões estão implementadas em que produtos. As SBOM de fornecedores para componentes adquiridos são monitorizadas a par dos seus próprios builds. Consulte acompanhamento de vulnerabilidades e CRACI para equipas PSIRT.

IEC 62443-4-1: perguntas frequentes

O que é a IEC 62443-4-1?

A IEC 62443-4-1:2018, Secure product development lifecycle requirements, é a parte da série IEC 62443 que define requisitos de processo para fornecedores que desenvolvem produtos usados em sistemas de automação e controlo industrial. Abrange requisitos de segurança, design seguro, implementação, verificação e validação, gestão de defeitos, gestão de patches e fim de vida do produto.

Quais são as oito práticas da IEC 62443-4-1?

Gestão da segurança (SM), especificação dos requisitos de segurança (SR), segurança desde a conceção (SD), implementação segura (SI), testes de verificação e validação da segurança (SVV), gestão de problemas relacionados com a segurança (DM), gestão de atualizações de segurança (SUM) e orientações de segurança (SG). No total, contêm 47 requisitos.

Qual é a diferença entre a IEC 62443-4-1 e a 62443-4-2?

A 4-1 trata do processo que um fornecedor usa para desenvolver e manter produtos. A 4-2 define requisitos técnicos de segurança para os próprios componentes, como dispositivos embebidos, dispositivos de rede, dispositivos host e aplicações de software. Normalmente, um fornecedor é avaliado face à 4-1 quanto ao seu processo de desenvolvimento e face à 4-2 quanto a um produto específico.

Que práticas da IEC 62443-4-1 abrangem a gestão de vulnerabilidades?

Sobretudo a prática 6, gestão de problemas relacionados com a segurança (DM-1 a DM-6), que abrange a receção, revisão, avaliação, resolução e divulgação de problemas de segurança, e a prática 7, gestão de atualizações de segurança (SUM-1 a SUM-5), que abrange a qualificação, documentação e entrega atempada de atualizações de segurança. Este é o trabalho de uma PSIRT.

Quais são os níveis de maturidade da IEC 62443-4-1?

Quatro níveis, baseados no CMMI for Development: ML1 Initial (ad hoc ou não documentado), ML2 Managed (processos documentados), ML3 Defined ou Practiced (documentados, executados e repetíveis) e ML4 Improving (processos melhorados ao longo do tempo com métricas de desempenho).

Como se obtém a certificação IEC 62443-4-1?

Através de um organismo de certificação acreditado. O programa SDLA da ISASecure certifica organizações de desenvolvimento segundo a IEC 62443-4-1 através de laboratórios credenciados, e organismos de certificação como a TÜV Rheinland e a Applus+ emitem certificados 62443-4-1 que indicam o nível de maturidade alcançado, incluindo ao abrigo do IECEE CB Scheme.

A IEC 62443-4-1 exige uma SBOM?

Os títulos dos requisitos de 2018 não mencionam SBOM. Vários requisitos tratam de componentes fornecidos externamente e de atualizações de componentes dependentes e sistemas operativos, e uma lista fiável dos componentes de cada versão é a forma prática de demonstrar como os trata.