Capítulo 16 — Engenharia de sistemas
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX031.
flowchart TD
N0["16.1 O ciclo de vida e o V"]
N1["16.2 Necessidades, requisitos, rastreabilidade"]
N2["16.3 Interfaces e configuração"]
N3["16.4 A segurança como disciplina da engenharia de si"]
N4["16.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX031"]
Desenho lógico
flowchart LR
N0["16.1 O ciclo de vida e o V"]
N1["16.2 Necessidades, requisitos, rastreabilidade"]
N2["16.3 Interfaces e configuração"]
N3["16.4 A segurança como disciplina da engenharia de si"]
N4["16.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]
[16.1 O ciclo de vida e o V]
|
v
[16.2 Necessidades, requisitos, rastreabilidade]
|
v
[16.3 Interfaces e configuração]
|
v
[16.4 A segurança como disciplina da engenharia de si]
|
v
[16.6 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX031]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) aplicar o ciclo de vida da engenharia de sistemas — concepção, requisitos, arquitetura, projeto, integração, verificação, validação, operação, desativação — a um programa de segurança; (2) decompor as necessidades das partes interessadas em requisitos de sistema e de subsistema com rastreabilidade; (3) gerenciar interfaces e configuração; e (4) integrar a engenharia de segurança à engenharia de sistemas, em vez de acoplá-la depois. Ele se apoia nos capítulos 5 e 14 e enquadra toda a segunda metade do livro.
16.1 O ciclo de vida e o V
A engenharia de sistemas gerencia a complexidade passando das necessidades aos requisitos, à arquitetura e aos componentes, e depois subindo de volta pela integração e pela verificação. O modelo em V emparelha cada nível de decomposição, à esquerda, com um nível de verificação, à direita: necessidades das partes interessadas com validação, requisitos de sistema com verificação do sistema, projeto de subsistemas com testes de integração, componentes com testes unitários. O NASA Systems Engineering Handbook descreve esse ciclo de vida e suas revisões técnicas. O desenvolvimento iterativo não abole o V; ele executa Vs menores com mais frequência.
16.2 Necessidades, requisitos, rastreabilidade
As necessidades das partes interessadas são o que as pessoas precisam que o sistema alcance, na linguagem delas: "o hospital não pode ficar sem água por mais de quatro horas". Os requisitos de sistema traduzem as necessidades em afirmações verificáveis sobre o sistema (Capítulo 5). A rastreabilidade liga cada requisito, para cima, a uma necessidade e, para baixo, a elementos de projeto e à verificação. Um requisito sem pai é excesso de enfeite ou uma necessidade oculta; uma necessidade sem requisito é uma lacuna; um requisito sem verificação é uma afirmação sem sustentação (Capítulo 38 e Laboratório 14).
16.3 Interfaces e configuração
A maioria das falhas de sistemas acontece nas interfaces — entre subsistemas, organizações ou pessoas. Um documento de controle de interface (ICD) especifica dados, temporização, protocolos, energia, conexões físicas e responsabilidades de cada lado. A gestão de configuração identifica cada item (hardware, versões de firmware, parâmetros, documentos), controla as mudanças por meio de revisão e mantém registros, para que o sistema como construído seja conhecido. Em segurança, uma configuração desconhecida é uma superfície de ataque desconhecida. Os três documentos de controle de interface do TMRP cobrem RTU para gateway, gateway para SCADA e SCADA para DMZ. Cada um nomeia um dono de cada lado.
16.4 A segurança como disciplina da engenharia de sistemas
O NIST SP 800-160 Vol. 1 Rev. 1 enquadra a engenharia de segurança de sistemas como atividades de segurança embutidas nos processos técnicos da engenharia de sistemas: necessidades de proteção das partes interessadas, requisitos de segurança, projeto arquitetural para a segurança, verificação das afirmações de segurança, e operação e descarte seguros. Seu volume companheiro, o SP 800-160 Vol. 2 Rev. 1, trata da ciber-resiliência: antecipar, resistir, recuperar-se e adaptar-se a condições adversas, incluindo ataques. O TMRP segue essa abordagem: N2 é uma necessidade de proteção decomposta em R1 e R2, e cada um tem uma verificação planejada.
16.5 Exemplo resolvido: o TMRP como sistema (sintético)
As necessidades de nível mais alto do TMRP: N1 manter o hospital abastecido (interrupção ≤ 4 h em cenários plausíveis); N2 detectar e conter o uso indevido do controle remoto; N3 recuperar a operação remota em até um dia útil; N4 manter a visibilidade do operador durante faltas de energia da rede. Elas se decompõem nos requisitos R1–R9 apresentados até aqui (telemetria autenticada, rejeição de repetições, limites de setpoint, modo manual local, autonomia de 24 h do armário, restauração em até 8 h, alarmes em até 60 s, integridade dos logs, alarme de dosagem independente). A equipe escreve documentos de controle de interface para RTU–gateway, gateway–SCADA e SCADA–DMZ, e coloca todas as versões de firmware e os arquivos de configuração das RTUs sob controle de mudanças. Cada requisito agora tem uma necessidade-pai e um método de verificação planejado.
16.6 Atividade prática
Desenhe uma matriz de rastreabilidade N1–N4 × R1–R9 e marque o(s) pai(s) de cada requisito. Identifique qualquer necessidade com cobertura fraca. Use uma grade simples com as necessidades nas colunas e os requisitos nas linhas, e marque o pai ou os pais de cada requisito. Alguns requisitos servem a mais de uma necessidade: R5 apoia a visibilidade durante faltas de energia da rede, e R1 apoia tanto a contenção quanto o abastecimento do hospital. Quando terminar, conte os requisitos sob cada necessidade. Uma necessidade sustentada por um único requisito merece um segundo olhar, porque um único teste reprovado a deixaria sem sustentação no dossiê.
16.7 Erros comuns e limites
- Requisitos escritos depois do projeto para justificá-lo.
- Interfaces sem dono.
- Configuração conhecida apenas pelo engenheiro de comissionamento.
- Requisitos de segurança num documento separado, nunca rastreados nem verificados.
- Tratar o modelo em V como uma desculpa em cascata para adiar os testes.
No TMRP, cada um desses erros tem uma contramedida: os requisitos são rastreados até N1–N4, cada interface tem um dono, e o firmware e a configuração das RTUs estão sob controle de mudanças. A verificação é planejada para cada requisito antes do início do projeto, então o V não é usado como motivo para adiar os testes.
Exercícios — capítulo 16
EX031 — Rastreie e encontre lacunas. Objetivo: construir e analisar uma matriz de rastreabilidade. Entradas: §16.5. Passos: atribua cada um de R1–R9 à(s) sua(s) necessidade(s)-pai; identifique qual necessidade depende do menor número de requisitos e proponha um requisito adicional. Evidência esperada: matriz e proposta. Rubrica: 3 = mapeamento defensável, necessidade mais fraca identificada, com um novo requisito verificável; 2 = erros de mapeamento; 1 = sem proposta; 0 = nada.
EX032 — Controle de interface. Objetivo: especificar uma interface por completo. Entradas: a interface gateway–SCADA. Passos: liste pelo menos oito atributos da interface, com valores de exemplo (itens de dados, codificação, taxa, latência, autenticação, tratamento de erros, fonte de tempo, propriedade, processo de mudança). Evidência esperada: tabela. Rubrica: 3 = completa e coerente com os laboratórios 8 e 13; 2 = faltam atributos de segurança ou de propriedade; 1 = apenas dados; 0 = nada.
Síntese do capítulo
A engenharia de sistemas vai das necessidades a sistemas verificados e validados por meio de requisitos rastreáveis, interfaces gerenciadas e configuração controlada. A segurança pertence a esses processos: as necessidades de proteção se tornam requisitos, os requisitos se tornam arquitetura e projeto, e toda afirmação de segurança precisa de evidência de verificação.
Continue estudando — capítulo 16 de 50
← Capítulo 15 · Índice de capítulos do curso · Capítulo 17 →
Siga para a próxima lição escrita.