Por que a produção de um caso de segurança é muitas vezes falha?

A produção de um caso de segurança é frequentemente vista como uma tarefa burocrática e técnica, algo que deve ser feito para cumprir as normas, sem um exame verdadeiro e profundo da segurança do sistema. No caso do Nimrod, por exemplo, o processo de elaboração do caso de segurança foi fatalmente prejudicado por uma sensação generalizada de que o sistema estava “seguro de qualquer forma”, simplesmente porque já havia voado com sucesso por 30 anos. Este sentimento de complacência, aliado a uma falta de crítica e uma presunção de segurança pré-existente, resultou em um processo onde a elaboração do caso de segurança tornou-se apenas uma formalidade, uma mera atividade de “marcar caixas” em uma lista. A consequência disso é a falta de uma análise crítica genuína dos riscos envolvidos, o que pode levar à falha do sistema.

Quando se ensina sobre casos de segurança, frequentemente recorro a um experimento que aprendi em uma referência de Rolf Dobelli, baseado em pesquisas de Peter Wason. Neste experimento, escrevo os números 2, 4, 6, 8, 10 na lousa e peço aos participantes que deduzam a regra por trás da sequência, sugerindo o próximo número. Sempre alguém sugere 12, que é aceito e adicionado à sequência. Depois, alguém sugere 14, e isso também é adicionado. Ao longo do tempo, o número 26 pode ser o mais recente da sequência. Eventualmente, alguém pode sugerir 153, e eu escrevo esse número na lousa também. Com isso, a classe percebe que a verdadeira regra não é “o próximo número é o anterior somado a dois”, mas sim “o próximo número deve ser maior que o anterior”. As sugestões como 12, 14, 16, etc., que apenas confirmam aquilo que as pessoas já acreditam, não fornecem tanta informação quanto aquelas que vão contra a crença geral, como o número 153. A partir disso, fica claro que, ao construir um caso de segurança, precisamos buscar evidências que desafiem nossas crenças pré-existentes sobre a segurança do sistema, em vez de procurar apenas confirmações dessas crenças.

A ideia é evitar o viés de confirmação. Por exemplo, ao elaborar um caso de segurança, podemos ser tentados a procurar apenas evidências que confirmem que o sistema é seguro, já que já acreditamos nisso. Porém, evidências que desafiem essa crença são mais valiosas. Uma das abordagens para combater esse viés é pedir aos desenvolvedores que mostrem de forma clara como o sistema pode falhar. Isso aproxima-se de uma forma de argumentação eliminativa, um conceito que foi introduzido por John Goodenough e que também está presente no padrão GSN (Goal Structuring Notation), utilizado para estruturar e representar as argumentações dos casos de segurança.

Ao preparar um caso de segurança, é essencial fazer perguntas desafiadoras. Em vez de simplesmente perguntar “este sistema está pronto para ser lançado?”, deveríamos reformular a questão para “você consegue pensar em alguma razão pela qual este sistema não está pronto para ser lançado?”. Isso ajuda a identificar falhas no raciocínio e a estimular uma análise mais profunda do sistema. Essa abordagem pode elevar a moral da equipe, permitindo que preocupações que estavam guardadas sejam finalmente expressas e resolvidas.

É importante destacar que, ao elaborar um caso de segurança, as informações devem ser organizadas de forma clara e estruturada. Uma das metodologias utilizadas é a notação GSN, que se destina a formalizar os argumentos e evidências que sustentam a segurança do sistema. No entanto, também existem outras ferramentas, como as Redes de Crença Bayesiana (BBN) e o Modelo de Garantia Estruturada (SACM), que podem ser usadas dependendo da complexidade do sistema e do nível de detalhamento necessário.

Além disso, ao buscar evidências, deve-se considerar não apenas as evidências que confirmam as alegações, mas também aquelas que podem refutá-las ou enfraquecê-las. Isso é feito por meio de “atacantes” ou “defensores”, que se concentram em testar a validade das alegações e evidências. Por exemplo, podem surgir “atacantes diretos” que desafiem as alegações, ou “atacantes de evidências” que questionem a qualidade das provas apresentadas. A introdução de tais questionamentos não só fortalece o caso de segurança, como também contribui para a credibilidade e robustez do processo como um todo.

Por fim, a construção de um caso de segurança não é uma tarefa pontual, mas um processo contínuo que envolve revisões e refinamentos. A abordagem iterativa, onde se revisitam as fases do processo até que todas as falhas sejam abordadas, é fundamental para garantir que o sistema seja verdadeiramente seguro. Portanto, a construção de um caso de segurança deve ser vista como um exercício de análise crítica constante, onde cada suposição é questionada e cada falha é identificada antes que o sistema seja considerado seguro para operação.

Como avaliar ameaças à segurança de sistemas: limites da análise probabilística e o papel dos casos de segurança

A análise tradicional de segurança em sistemas críticos baseia-se, historicamente, na atribuição de probabilidades a eventos básicos e na avaliação combinatória desses eventos para inferir a probabilidade de acidentes. Essa abordagem, profundamente influenciada pela estatística clássica, presume que os eventos são aleatórios, quantificáveis, e regidos por incerteza do tipo aleatória (aleatória no sentido probabilístico, ou aleatoriedade objetiva).

No entanto, quando se trata de segurança no contexto de ameaças intencionais — como é o caso em cibersegurança — essa lógica se desfaz. O comportamento de adversários inteligentes não pode ser modelado adequadamente pelas mesmas ferramentas aplicadas à análise de falhas técnicas acidentais. A incerteza aqui é epistêmica: não diz respeito ao acaso, mas à ausência de conhecimento sobre as intenções, capacidades e estratégias dos atacantes. Atribuir probabilidades numéricas ao comportamento de um agente malicioso torna-se, no mínimo, uma abstração perigosa.

Essa limitação tem levado pesquisadores a questionar a adequação das abordagens de segurança herdadas das disciplinas de confiabilidade e segurança funcional para o domínio da cibersegurança. A diferença de natureza entre falhas acidentais e ações maliciosas exige um deslocamento metodológico. A engenharia de segurança precisa reconhecer que um sistema pode apresentar um comportamento nominalmente correto — e mesmo assim estar vulnerável, caso suas premissas de segurança tenham sido mal definidas ou ignoradas no projeto.

Erros de projeto, como apontado em recentes estudos de campo, têm superado em número os acidentes causados por eventos aleatórios. Esses erros não são meramente "probabilísticos"; são estruturais, conceituais e, muitas vezes, invisíveis até que um evento externo — frequentemente uma falha catastrófica — revele sua existência. Casos como o comportamento de “Heisenbugs” ilustram bem essa categoria: falhas que parecem intermitentes e desaparecem quando se tenta observá-las, desafiando qualquer análise tradicional de confiabilidade.

Dentro desse contexto, a noção de “safety case” (caso de segurança) adquire nova centralidade. Trata-se de um argumento estruturado, baseado em evidências, que busca justificar que um sistema é suficientemente seguro para um propósito definido, em um determinado contexto operacional. A construção de um safety case exige não apenas dados estatísticos ou modelagens probabilísticas, mas um raciocínio rigoroso, fundamentado em hipóteses explicitadas, justificativas técnicas e documentação rastreável.

Particularmente interessante é a discussão sobre os chamados “retrospective safety cases” — construídos após o sistema já estar em operação. Embora contrários ao ideal de que a segurança deve ser projetada desde o início, esses casos fornecem insights valiosos com base no histórico de uso do sistema (provas empíricas). Por exemplo, um argumento típico seria: “O sistema operou durante X horas sem incidentes, portanto argumentamos que ele atende ao nível Y de segurança exigido”. Porém, tal inferência só é válida quando a ausência de falhas é significativa — o que depende da frequência esperada de falhas e da criticidade do sistema.

Por outro lado, a evolução dos safety cases aponta para a necessidade de integrar argumentos operacionais, especialmente em sistemas que não podem ser desligados para manutenção ou revalidação contínua. A complexidade dos sistemas modernos — como veículos autônomos ou redes de energia — exige uma abordagem dinâmica, onde segurança, confiabilidade e resiliência sejam tratadas de forma conjunta, contínua e iterativa.

Importante ainda destacar a crescente convergência entre safety e security. A linha que separava a análise de segurança funcional (safety) da segurança contra ataques (security) torna-se cada vez mais tênue. Falhas de segurança podem ser exploradas como vetores de ataque; da mesma forma, vulnerabilidades intencionais podem se manifestar como falhas funcionais. Essa interseção exige engenheiros capazes de transitar entre os domínios, compreendendo tanto as dinâmicas dos sistemas quanto os aspectos estratégicos das ameaças.

Neste cenário, os argumentos de segurança não podem se basear exclusivamente em fórmulas ou simulações. Exigem julgamento, responsabilidade e, sobretudo, uma consciência crítica sobre os limites do conhecimento disponível. A “prova” de segurança não é uma dedução matemática; é uma construção argumentativa, sempre passível de revisão, reforço e contestação.

Importante entender que a noção de evidência, neste contexto, não pode ser confundida com mera observação empírica. Como já foi observado, a acumulação de dados observacionais, por si só, não constitui prova. É preciso que haja uma estrutura de raciocínio que conecte esses dados às conclusões, explicitando os pressupostos, os limites e os possíveis contraexemplos. O safety case não é apenas um documento — é um exercício disciplinado de pensamento.

Como identificar e analisar riscos e perigos em dispositivos médicos complexos?

Ao abordar o desenvolvimento de dispositivos médicos, a análise sistemática de perigos e riscos torna-se um elemento crítico não apenas de conformidade normativa, mas de viabilidade técnica e segurança operacional. O plano de segurança de um projeto deve, necessariamente, incorporar dois documentos fundamentais: o manual de segurança, que especifica responsabilidades e autoridades, e os procedimentos de análise de risco que detalham práticas exigidas durante o ciclo de desenvolvimento. Ambos os documentos não são acessórios — eles constituem a espinha dorsal da argumentação de segurança do produto final.

Ao adquirir componentes, é comum encontrar manuais de segurança anexados, indicando práticas obrigatórias, advertências e condições de uso. Essas recomendações não são triviais: a falha em seguir uma instrução como “a função abc() NÃO DEVE ser invocada a menos que a função xyz() tenha retornado EOK” pode comprometer diretamente a segurança do sistema. A clareza normativa nesse contexto é suportada por documentos como os RFCs 2119 e 8174, que padronizam termos como MUST, MUST NOT, MAY — minimizando ambiguidades interpretativas em exigências técnicas.

A análise de riscos (HARA — Hazard and Risk Analysis) busca identificar perigos potenciais e seus riscos associados, determinar sua criticidade, e definir medidas de mitigação. A figura 7.1 do modelo citado demonstra como as análises de perigos, falhas e a argumentação de segurança se entrelaçam, formando um corpo único e coeso. Reduzir riscos não é um objetivo opcional, mas uma exigência explícita: a cada risco identificado deve corresponder uma exigência de segurança implementada e rastreável.

O uso de abordagens estruturadas como HAZOP (Hazard and Operability Study) e HACCP (Hazard Analysis and Critical Control Points), mesmo tendo origem em contextos industriais (química, alimentos), mostra-se surpreendentemente eficaz quando adaptado ao domínio de software embarcado em dispositivos médicos. Técnicas como o HAZOP, originalmente voltadas para instalações químicas, foram efetivamente transpostas para o desenvolvimento de sistemas embarcados, permitindo a antecipação de cenários falhos ainda em fases conceituais. Isso exige, no entanto, adaptação semântica: em vez de válvulas e pressões, analisam-se fluxos de dados, estados do sistema e interfaces humanas.

Na prática, o HAZOP envolve imaginar desvios funcionais extremos e suas consequências. Por exemplo, em um dispositivo médico, analisa-se: "E se o operador inserir mais dígitos do que o necessário?" ou "E se dois operadores se logarem simultaneamente?". Ou ainda: "E se for colocada mais substância no dispensador do que o especificado?". Tais hipóteses, embora pareçam exageradas, são valiosas para revelar fragilidades ocultas. A antecipação de falhas depende diretamente da habilidade da equipe em imaginar absurdos plausíveis.

A norma ISO 14971 estabelece diretrizes para identificação, avaliação e mitigação de riscos em dispositivos médicos. Embora desenvolvida especificamente para esse domínio, ela herda práticas de normas industriais robustas, como a ISO 22000 e referências como o UL 2900. A edição de 2019 da ISO 14971 eliminou a menção direta ao HAZOP, mas isso não invalida sua utilidade como técnica complementar. Pelo contrário, ela continua sendo uma ferramenta poderosa para enriquecer a base de evidência de segurança.

Erros comuns encontrados em análises retrospectivas de falhas incluem: ausência de definição de estado seguro, inconsistência de unidades entre módulos de sof

Como a Aleatoriedade e a Incerteza Afetam a Análise de Falhas em Programas de Software

A compreensão dos erros, falhas e incertezas na programação de software exige um exame atento de como as falhas se manifestam e como elas podem ser previsíveis ou aleatórias. A abordagem clássica na engenharia de software distingue entre diferentes tipos de incerteza que podem surgir durante a execução de programas. A falha de um sistema de software pode ser ocasionada por uma série de fatores, sendo mais do que uma simples questão de erro de programação. Muitas vezes, as falhas podem ser vistas como manifestações de incertezas, seja pela falta de conhecimento do comportamento do sistema (incerteza epistêmica) ou pela própria natureza aleatória de certos eventos durante a execução (incerteza aleatória).

A primeira dessas incertezas é a incerteza epistêmica, que ocorre quando não se sabe completamente o que está acontecendo no sistema, seja por falta de dados ou pela complexidade do próprio programa. Imagine que, ao escrever um código, o programador não sabe com precisão o estado do sistema ou a interação entre os componentes, o que pode gerar um comportamento inesperado. Isso é especialmente evidente em sistemas complexos, onde mesmo pequenas variações no ambiente podem levar a resultados diferentes, criando uma série de falhas aparentemente aleatórias. Neste caso, o programador não pode prever com total precisão o comportamento do sistema, pois ele está lidando com um espaço de possibilidades que não é completamente conhecido.

Por outro lado, a incerteza aleatória refere-se ao comportamento imprevisível que ocorre devido a fatores que estão além do controle do programador. Isso pode incluir falhas de hardware, interferência no ambiente ou até mesmo comportamentos que são estatisticamente imprevisíveis. No contexto da engenharia de software, esse tipo de incerteza pode ser comparado à imprevisibilidade de falhas de hardware, como erros que ocorrem por conta de falhas físicas em componentes de computadores, como memória ou processadores. No entanto, ao contrário das falhas de hardware, onde podemos medir as taxas de falha com maior precisão, as falhas de software podem ser mais difíceis de prever devido à sua interação complexa com múltiplos componentes e variáveis ambientais.

Um exemplo clássico de falha de software pode ser encontrado em programas que, mesmo com um código aparentemente simples e sem erros lógicos evidentes, apresentam comportamentos inesperados devido a interações não documentadas ou condições raras que não foram testadas adequadamente. Como mostrado no exemplo do programa descrito na seção anterior, ao executar o código várias vezes, a saída do programa pode variar de forma imprevisível, resultando em falhas que são, na verdade, causadas pela interação de vários fatores desconhecidos ou não testados, como as condições de tempo de execução ou o comportamento do sistema sob cargas diferentes.

Essa aleatoriedade pode ser observada também em cenários onde o código é otimizado pelo compilador de forma que o comportamento esperado do programa não seja mais o mesmo do que o programador antecipou. A remoção silenciosa de loops ou modificações no comportamento das variáveis globais são exemplos de como a aleatoriedade pode ser introduzida na execução de um programa, levando a resultados inesperados que são difíceis de replicar ou diagnosticar.

Para estudar e mitigar essas falhas, é importante ter ferramentas que permitam inspecionar o código e prever o comportamento do sistema. Testes rigorosos e simulações são necessários, mas mesmo com essas abordagens, o ambiente de execução e a interação entre os componentes do sistema podem ainda introduzir um grau de incerteza que torna difícil garantir um desempenho sem falhas. A simples verificação de falhas através de testes não é suficiente para assegurar que o programa será capaz de lidar com todas as condições possíveis de execução.

Ao considerar as taxas de falha e a confiabilidade de sistemas de software, é necessário ter em mente que a falha de um sistema não pode ser considerada apenas como o resultado de erros de programação. A própria natureza do sistema, a interação com o ambiente e a presença de incertezas aleatórias e epistêmicas podem influenciar fortemente a taxa de falha observada.

Por fim, é fundamental que os engenheiros de software entendam a importância de combinar práticas de verificação de código com uma compreensão profunda das incertezas que afetam os sistemas. As falhas não podem ser tratadas apenas como erros a serem corrigidos, mas sim como manifestações de uma complexa rede de fatores imprevisíveis que, muitas vezes, desafiam os métodos tradicionais de análise e solução.