Capítulo 10 — Ética e segurança em engenharia
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX019.
flowchart TD
N0["10.1 Os deveres de um engenheiro"]
N1["10.2 Segurança operacional e segurança da informação"]
N2["10.3 Autorização e lei"]
N3["10.4 Decidir sob incerteza"]
N4["10.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX019"]
Desenho lógico
flowchart LR
N0["10.1 Os deveres de um engenheiro"]
N1["10.2 Segurança operacional e segurança da informação"]
N2["10.3 Autorização e lei"]
N3["10.4 Decidir sob incerteza"]
N4["10.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX019"]
[10.1 Os deveres de um engenheiro]
|
v
[10.2 Segurança operacional e segurança da informação]
|
v
[10.3 Autorização e lei]
|
v
[10.4 Decidir sob incerteza]
|
v
[10.6 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX019]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) aplicar códigos de ética profissional a decisões de segurança de infraestrutura; (2) explicar a relação entre segurança operacional (safety) e segurança da informação (security) e onde elas entram em conflito; (3) reconhecer os limites legais e de autorização para testes e pesquisas; e (4) tomar e documentar uma decisão ética sob incerteza, incluindo quando escalar. Ele se apoia no Capítulo 5 e enquadra todos os capítulos seguintes, em particular os de testes (capítulos 30 e 40) e de prática (Capítulo 43).
10.1 Os deveres de um engenheiro
Os códigos profissionais convergem para uma hierarquia: colocar acima de tudo a segurança, a saúde e o bem-estar do público; agir dentro da própria competência; ser honesto e objetivo; evitar conflitos de interesse; proteger informações confidenciais. O NSPE Code of Ethics for Engineers faz da segurança pública o primeiro cânone fundamental; o ACM Code of Ethics and Professional Conduct pede aos profissionais de computação que evitem danos e sejam honestos sobre as capacidades e os limites dos sistemas. Em infraestrutura crítica, o público é concreto: pacientes em diálise, domicílios sem água, pessoas esperando uma ambulância. O dever não é cumprido seguindo instruções se o resultado for um dano público previsível.
10.2 Segurança operacional e segurança da informação juntas
A segurança operacional (safety) protege as pessoas e o meio ambiente de danos causados pelo sistema; a segurança da informação (security) protege o sistema contra o uso indevido deliberado. Em tecnologia operacional, as duas interagem. Um controle de segurança da informação pode criar um perigo para a segurança operacional — o bloqueio automático de uma conta num console de operador durante uma emergência, ou uma correção que reinicia um controlador durante a execução de um processo. Um mecanismo de segurança operacional pode ser um alvo de segurança da informação: o malware TRITON/TRISIS mirou controladores de sistemas instrumentados de segurança, como descrito no relatório de análise do malware HatMan da CISA. A boa prática trata ambas numa única análise de perigos (Capítulo 33) e dá às funções de segurança operacional independência em relação às redes e aos sistemas que elas protegem.
10.3 Autorização e lei
Testar um sistema que você não possui, ou que não tem permissão escrita para testar, pode ser crime, quaisquer que sejam suas intenções, e em infraestrutura pode pôr pessoas em perigo. A autorização precisa ser escrita, específica (sistemas, horários, métodos), dada por alguém com legitimidade para concedê-la, e incluir condições de interrupção. Pesquisas que envolvem pessoas ou dados operacionais precisam de revisão ética e de acordos sobre os dados. Vulnerabilidades que você encontre por acaso devem ir ao dono do ativo de forma privada ou por meio de um programa de divulgação coordenada, como o programa de CVD da CISA. Os laboratórios deste livro são sintéticos exatamente por essas razões.
10.4 Decidir sob incerteza
Um procedimento prático de decisão ética: (1) declare a decisão e quem é afetado; (2) identifique os deveres e os fatos que pesam sobre eles; (3) liste as opções, incluindo escalar e recusar; (4) avalie as consequências para as partes interessadas mais vulneráveis; (5) escolha, documente o raciocínio e as divergências e marque um ponto de revisão. Os engenheiros raramente enfrentam dilemas limpos; com mais frequência, o problema é a pressão para aprovar algo que ainda não se mostrou funcional. "Não verificado" é uma resposta honesta e suficiente. No exemplo resolvido a seguir, o engenheiro de verificação do TMRP usa exatamente esses cinco passos.
10.5 Exemplo resolvido: a aprovação no prazo final (sintético)
O prazo de comissionamento do TMRP é sexta-feira. O teste T3 (limites de setpoint) falhou: o controlador da PS4 aceita um setpoint fora da faixa segura quando enviado como valor NaN. O fornecedor propõe comissionar com uma nota para corrigir na próxima versão. Como engenheiro de verificação, você aplica o procedimento: as pessoas afetadas incluem os pacientes do hospital, se a PS4 se comportar de forma imprevisível; seu dever é para com a segurança pública e o relato honesto; as opções são (a) assinar, (b) recusar, (c) comissionar com um controle compensatório — escritas remotas de setpoint desabilitadas no gateway, operação apenas local para a PS4 — e uma correção datada. Você recomenda (c), registra T3 como reprovado, não dispensado, e exige um novo teste antes que as escritas remotas sejam habilitadas. A decisão é documentada e assinada pelo gerente de operações, que é o dono do risco operacional.
10.6 Atividade prática
Escreva um modelo de autorização de uma página para um teste de um sistema sintético: escopo, métodos excluídos, janela de tempo, condições de interrupção, contatos, tratamento de dados e aprovação. Preencha o modelo para um teste de bancada do gateway de telemetria da LRWA, e não para uma estação em operação. Diga quem pode assiná-lo, liste os métodos excluídos, como qualquer tráfego dirigido a RTUs reais, e dê condições de interrupção que um testador consiga reconhecer sem interpretação. Inclua um contato que possa interromper o teste a qualquer momento e uma regra sobre o que acontece depois com os dados capturados. Um modelo que permitisse a alguém testar a PS4 durante um período de alta demanda falhou em seu propósito.
10.7 Erros comuns e limites
- Tratar a ética como uma lista de verificação de conformidade, em vez de raciocinar sobre danos.
- "Permissão verbal" para testes.
- Controles de segurança da informação projetados sem considerar a segurança operacional em emergências.
- Aprovar o que não foi verificado porque um cronograma exige.
- Divulgar publicamente fraquezas de infraestrutura sem coordenação.
A aprovação no prazo final do exemplo resolvido mostra vários desses erros de uma vez: pressão para comissionar, um fornecedor oferecendo uma promessa verbal de corrigir depois e um teste reprovado que poderia facilmente ter sido marcado como dispensado. O engenheiro evitou cada um deles ao registrar a falha e acordar por escrito um controle compensatório.
Exercícios — capítulo 10
EX019 — Conflito entre segurança operacional e segurança da informação. Objetivo: resolver um controle que põe as operações em perigo. Entradas: proposta de bloquear as contas da IHM dos operadores após cinco logins malsucedidos. Passos: analise o perigo, proponha uma alternativa que preserve a intenção de segurança e diga como você a verificaria. Evidência esperada: análise de meia página. Rubrica: 3 = perigo claro (bloqueio durante uma emergência), alternativa que mantém a responsabilização e resiste a tentativas de adivinhação (por exemplo, limitação de taxa com alertas, liberação por presença física, contas de turno com registro em log), verificação declarada; 2 = alternativa fraca; 1 = apenas o perigo; 0 = nada.
EX020 — Achado incidental. Objetivo: agir dentro da autorização. Entradas: ao estudar, para um trabalho do curso, documentos de compras de uma concessionária pública, você nota numa captura de tela uma página de gerenciamento de um controlador de bombas exposta à internet, com o fornecedor e o modelo visíveis. Passos: diga o que você não deve fazer, o que deve fazer e para quem, e o que seu trabalho pode dizer. Evidência esperada: 150 palavras. Rubrica: 3 = nenhum acesso ou sondagem, notificação privada ao dono ou via CVD, trabalho anonimizado; 2 = um passo ausente; 1 = sugere "verificar se é real"; 0 = nada.
Síntese do capítulo
A segurança pública vem primeiro, relatada com honestidade. A segurança operacional e a segurança da informação precisam ser analisadas juntas, porque cada uma pode derrotar a outra. Teste apenas com autorização escrita e específica; relate os achados incidentais de forma privada. Decida sob incerteza com um procedimento documentado e trate "não verificado" como uma resposta que você tem o direito — e a obrigação — de dar.
Continue estudando — capítulo 10 de 50
← Capítulo 09 · Índice de capítulos do curso · Capítulo 11 →
Siga para a próxima lição escrita.