◇ OpenCyber Academy
Engenharia · Capítulo 14 · Português

Capítulo 14 — Engenharia de software

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 14 — Engenharia de software

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 Ferramentas são produtos"]
  N1["14.2 Condicione o alargamento"]
  N2["14.3 Dados de teste da integração contínua"]
  N3["Nota prática"]
  N4["14.1b Trens de versão versus correções urgentes"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 Ferramentas são produtos"]
  N1["14.2 Condicione o alargamento"]
  N2["14.3 Dados de teste da integração contínua"]
  N3["Nota prática"]
  N4["14.1b Trens de versão versus correções urgentes"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX040"]
[14.1 Ferramentas são produtos]
    |
    v
[14.2 Condicione o alargamento]
    |
    v
[14.3 Dados de teste da integração contínua]
    |
    v
[Nota prática]
    |
    v
[14.1b Trens de versão versus correções urgentes]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) pôr as ferramentas de segurança de TO sob controle de versão, com revisão; (2) condicionar as mudanças que alargam condutos; (3) manter a integração contínua apenas com dados de teste sintéticos.

14.1 Ferramentas são produtos

Compiladores de listas de permissões, verificadores de alcançabilidade e configurações de detectores são software. Precisam de repositórios, revisões, tags e registros de mudanças. Uma permissão de trabalho que cita a exportação do firewall sem um hash está incompleta.

Lena mantém as ferramentas do CNHP num único repositório, com versões marcadas por tags e um registro de mudanças, e toda permissão de trabalho cita a tag e o hash das exportações em que se apoia. Quando um revisor pergunta qual versão do verificador de alcançabilidade produziu um resultado, a resposta é uma tag, não uma lembrança.

14.2 Condicione o alargamento

Merges que acrescentam um conduto, abrem um código de função ou removem um bloqueio exigem um segundo revisor e um ticket de autorização vinculado. As mudanças que restringem podem ser mais leves. Codifique isso no CODEOWNERS dos caminhos de política.

Lena designa donos de código da engenharia de controle para os arquivos de listas de permissões e de condutos, de modo que as mudanças que alargam não possam ser integradas sem eles. As mudanças que restringem ainda precisam de um revisor. A regra é imposta pelas configurações de donos de código nos caminhos de política, então não pode ser pulada por um revisor ocupado. Uma mudança que alarga também precisa de um ticket de autorização vinculado, que nomeie quem aprovou o novo caminho e por quê.

14.3 Dados de teste da integração contínua

A integração contínua roda os laboratórios e os testes de unidade sobre dados sintéticos. Nunca aponte a integração contínua para uma VPN da planta. Os dados de semente ficam no repositório; as credenciais da planta ficam num cofre e nunca nos logs da integração contínua.

Caso sintético — Ashford Batch Plant. Um PR acrescentou uma regra temporária do L4 para o L2 para a visita de um fornecedor. A verificação de alcançabilidade da integração contínua falhou porque o L1-SIS se tornou alcançável; o PR foi bloqueado até que a regra fosse reescrita através da DMZ.

O pipeline de Lena carrega dados de teste sintéticos para as zonas e a lista de permissões da ABP.

14.4 Erros e limites

As tags podem se afastar do que os operadores de fato executam; registre o hash em execução no log do trabalho no início da janela.

O log de trabalho de Lena registra o hash do binário do monitor e da lista de permissões efetivamente em execução no início de cada janela. Se ele diferir da versão marcada, a janela espera até que a diferença seja explicada. Essa verificação encontrou um monitor de bancada ainda rodando uma versão candidata depois de uma correção urgente. Os hashes em execução vão para o registro da janela. Uma divergência é tratada como parada, não como aviso.

Nota prática

Os repositórios de política usam a mesma cultura de dupla aprovação que os downloads de lógica de CLP. Se baixar o ladder para o PLC-A exige duas pessoas, publicar um conduto que alcança o PLC-A também deveria exigir.

14.1b Trens de versão versus correções urgentes

As melhorias normais seguem um trem de versões com os Laboratórios I/II. Uma correção urgente do monitor ou de uma lista de permissões pode pular funcionalidades, mas não a verificação: o pacote mínimo de regressão com falha fechada roda antes que qualquer janela a use. Marque as correções urgentes com clareza, para que uma janela possa fixar conscientemente ou a build do trem ou o SHA da correção. As versões fixadas aparecem na lista de verificação de abertura, ao lado do hash da permissão de trabalho; se a versão fixada e o binário em execução discordarem, a janela não começa.

As correções urgentes da ABP têm a sua própria tag e o resultado do pacote de regressão na nota de versão, para que um líder de janela veja exatamente o que foi verificado.

14.5 Exemplo resolvido — revisando uma mudança em permit() (ABP sintética)

Um pull request alarga a faixa gravável da IHM no PLC-A de 40001–40010 para 40001–40012, para um novo setpoint do agitador. A lista de verificação da revisão de Lena: o ID do requisito que justifica 40011–40012; novos vetores de conformidade para 40012 (passa) e 40013 (bloqueia); a negação por padrão inalterada para origens desconhecidas; um incremento de versão e uma linha no registro de mudanças; e um segundo revisor da engenharia de controle que confirma o significado dos registradores no projeto do CLP. O merge espera a execução em bancada dos vetores contra a build real do firewall. A disciplina de engenharia de software aqui não é cerimônia: um erro de um caractere na faixa deixaria a IHM escrever num registrador que o projeto do processo nunca previu.

Exercícios

Síntese

Trate o software de segurança de TO como software de produção: versões, condições de revisão, integração contínua sintética.

Continue estudando — capítulo 14 de 50

← Capítulo 13 · Índice de capítulos do curso · Capítulo 15 →

Siga para a próxima lição escrita.