Garantia de Confiança
e Proteção
Alinne Corrêa e Francisco Carlos
{alinne, fcarlos}@icmc.usp.br
Junho, 2012
1/ 42
Roteiro
1. Introdução
2. Análise Estática
3. Teste de Confiabilidade
4. Teste de Proteção
5. Garantia de Processo
6. Casos de Segurança e Confiança
7. Pontos Importantes
2
Conceitos
• Garantia de Confiança e Proteção:
o Verificar se um sistema crítico atende os requisitos de confiança;
o Requer processos de Verificação e Validação (V & V) que procurem erros de
especificação, de projeto e de programa;
o Podem afetar a disponibilidade, a segurança, a confiabilidade ou a
proteção de um sistema.
• Processo de Verificação e Validação (V & V):
o Demonstrar que o sistema atende a sua especificação e que os serviços e o
comportamento do sistema que estão de acordo com os requisitos do cliente;
o Devem descobrir erros de requisitos, projeto e defeitos de programas que
precisam ser reparados.
3
• Introdução
4
• Introdução
Razões Descrição
Custos de
falhas
- Os custos e as consequências de falhas de sistemas críticos
são potencialmente altos;
- Para reduzir esses custos, é necessário investir na verificação
e validação de sistema;
- Mais econômico encontrar e remover defeitos antes do sistema
ser entregue.
Validação de
atributos de
confiança
- Criar um exemplo formal para clientes e reguladores;
- Necessidade de ter que projetar e efetuar os procedimentos
especiais de V & V que coletem evidências sobre a confiança
do sistema.
Validação em Sistemas Críticos
• Os custos de validação para sistemas críticos normalmente são
significativamente maiores do que para sistemas não-críticos, devido as
atividades adicionais envolvidas (razões);
• Normalmente, os custos da V & V ocupam mais de 50% dos custos
totais de desenvolvimento do sistema;
• O resultado do processo de validação é um corpo tangível de evidência
que demonstra o nível de confiabilidade de um sistema de software;
o Ex: Falha de um sistema de software de missão crítica
no foguete Ariane 5, onde diversos satélites foram destruídos.
5
• Introdução
Custos da Validação
Análise Estática
• Análise Estática
6
• Técnicas de Análise Estática
o São técnicas de verificação de sistema que não envolvem a execução de um
programa;
o Trabalham em uma representação fonte do software - modelo ou o código do
programa em si;
o Podem ser usadas para identificar erros antes que uma versão executável do
sistema esteja disponível;
o Inspeções e avaliações em pares são uma forma de análise estática;
o Técnicas de Análise Estática para sistemas críticos:
― Verificação formal
― Verificação de modelos
― Análise estática automática
Verificação e métodos formais
• Análise Estática
7
• Os métodos formais utilizam modelo formal de sistema que serve como
uma especificação;
• Esses métodos formais são relacionados, principalmente, a uma análise
matemática da especificação;
• No processo de V & V, os métodos formais podem ser usados em
diferentes estágios:
o Estágio 1: A especificação é desenvolvida e matematicamente analisada por
inconsistências. É eficaz em descobrir erros de especificação e omissões;
o Estágio 2: Utilização de argumentos matemáticos para verificar, se o código
de um sistema de software é consistente com sua especificação. É eficaz em
descobrir erros de programação e design.
Verificação e Métodos Formais
• Análise Estática
8
• Os proponentes dos métodos formais afirmam que o uso desses métodos
garante sistemas mais seguros e confiáveis;
• A verificação formal demonstra que o programa desenvolvido cumpre suas
especificações e que os erros de implementação não comprometerão a
confiança do sistema.
Verificação de um sistema não trivial
Pericia
matemática Ferramentas
especializadas
Verificação e Métodos Formais
• Análise Estática
9
Verificação de um sistema não trivial
Pericia
matemática Ferramentas
especializadas A verificação formal não é eficaz.... o
mesmo nível de confiança no sistema
pode ser alcançado de forma mais barata,
com outras técnicas de validação, como
inspeções e testes de sistema.
Verificação de Modelo
• Análise Estática
10
• Abordagem alternativa à análise formal;
• Baseada em uma noção mais restrita de correção;
• Usada na verificação de projetos de sistemas de hardware e em
sistemas críticos de software;
o Ex: Software de controle de veículos de exploração de Marte de NASA;
Software processador de chamadas telefônicas.
Verificação de Modelo
• Análise Estática
11
• Estágios:
o Envolve a criação de um modelo de um sistema e a verificação da correção
desse modelo, geralmente como uma máquina de estado finito estendida;
o Um conjunto de propriedades desejáveis de sistema é identificado e escrito em
uma notação formal;
o O verificador de modelos explora todos os caminhos pelo modelo (isto é,
todas as possíveis transições de estado) e verifica se uma propriedade
especificada pelo usuário é válido para cada caminho;
• Particularmente útil na validação de sistemas concorrentes que são
difíceis de se testar em virtude de sua sensibilidade a tempo.
Requisitos,
projeto ou
programa
Construção de
modelo
Especificação
de propriedade
Modelo de estado
finito estendido do
sistema
Propriedades do
sistema desejadas
Verificador de
modelo
Confirmação ou
contraexemplos
Verificação de Modelo
• Análise Estática
12
• Computacionalmente, a verificação de modelos é muito cara:
o Usa uma abordagem exaustiva para verificar todos os caminhos do modelo de
sistema;
o Tamanho do sistema aumenta, também aumenta o número de estados, e,
consequentemente, o número de caminhos a ser verificado;
o Para sistemas grandes, a verificação de modelos pode ser pouco útil, devido
ao tempo de computador requerido para executar as verificações.
Análise Estática Automática
• Análise Estática
13
• As ferramentas de análise estática trabalham no código-fonte de um
sistema;
• A análise estática automatizada é mais fácil de ser introduzida em um
processo de desenvolvimento do que a verificação formal ou a verificação
de modelos:
• Programadores não precisam aprender notações especializadas para escrever
as especificações de programa;
• Os analisadores estáticos automatizados são as ferramentas de software
que fazem a varredura no código-fonte de um programa e detectam
possíveis defeitos e anomalias;
• A intenção é desenhar um código para as anomalias no programa,
como: variáveis usadas sem iniciação, sem uso, ou ainda, dados, cujos
valores poderiam sair dos limites.
Análise Estática Automática
• Análise Estática
14
Classe de defeito Verificação de análise estática automática
Defeitos de dados
- Variáveis usadas antes da iniciação
- Variáveis usadas mais nunca declaradas
- Variáveis atribuídas duas vezes, mas nunca usadas entre atribuições
- Possíveis violações de limites de vetor
- Variáveis não declaradas
Defeitos de controle - Código inacessível
- Ramos incondicionais centro de loops
Defeitos de entrada /saída - Saída de variáveis duas vezes sem atribuição intermediária
Defeitos de interface
- Incompatibilidades de tipo de parâmetro
- Incompatibilidades número de parâmetros
- Não uso de resultados de funções
- Funções e procedimentos não chamados
Defeitos de gerenciamento de
armazenamento
- Ponteiros não atribuídos
- Ponteiro aritmético
- Perdas de memória
Análise Estática Automática
• Nos analisadores estáticos, ha três níveis de verificação que podem ser
implementados:
o Verificação de erros característicos:
― O analisador estático conhece erros comuns, realizados por programadores em
linguagens como Java ou C;
o Verificação de erros definidos pelo usuário:
― Os usuários do analisador estático podem definir padrões de erros;
o Verificação de asserções:
― Nível mais geral e mais poderoso da análise estática;
― Os desenvolvedores incluem asserções em seus programas que definem os
relacionamentos que devem manter naquele ponto de programa.
― Ex: Incluir uma asserção que indique que o valor de uma variável deve se encontrar
no intervalo de x..y
15
• Análise Estática
Análise Estática Automática
• Útil quando uma linguagem como C é usada e, portanto, muitos erros não
são detectadas pelo compilador.;
• O analisador estático pode descobrir áreas de vulnerabilidade, tais como
buffer, overflows ou insumos não fiscalizados;
• É rotineiramente usada no desenvolvimento de segurança em muitos
sistemas críticos de segurança:
o Ex: Microsoft introduziu a análise estática no desenvolvimento de drivers de
dispositivos;
• Como parte do processo de V & V, muitos sistemas críticos, incluindo os
de aviação e os sistemas nucleares, são analisados estaticamente.
16
• Análise Estática
Teste de Confiabilidade
• Teste de Confiabilidade
17
• É um processo de teste cujo objetivo é medir a confiabilidade de um
sistema.
• O processo de medição de confiabilidade envolve quatro estágios:
o Estabelecer o perfil operacional para o sistema;
o Construir dados de teste que refletem o perfil operacional;
o Testar o sistema e observar o número de falhas e os tempo dessas falhas;
o Calcular a confiabilidade depois que um número estatisticamente significativo
de falhas tenha sido observados.
Identificar perfis
operacionais
Preparar
conjunto de
dados de teste
Aplicar testes
para sistema
Computar
confiabilidade
observada
Medição de Confiabilidade
Teste de Confiabilidade
• Teste de Confiabilidade
18
• O processo de medição é conhecido como teste estatístico:
o Tem como objetivo avaliar a confiabilidade de sistema;
o Teste de software em relação à confiabilidade em vez da detecção de falhas;
o Permite prever a confiabilidade do software, por meio da medição do número
de erros;
o Um nível aceitável de confiabilidade deve ser especificado e o software testado
é alterado até que o nível de confiabilidade é atingido.
Teste de Confiabilidade
• Teste de Confiabilidade
19
• Problemas de medição:
o Incerteza de perfil operacional:
― Os perfis operacionais baseados na experiência de outros sistemas não podem ser
uma reflexão exata do uso real do sistema;
o Custos elevados de geração de dados de teste:
― Os custos podem ser muito elevados, se os dados de teste para o sistema não
poderem ser gerados automaticamente;
o Incertezas estatísticas:
― Precisa de um número estatisticamente significativo de falhas para calcular a
confiabilidade;
o Reconhecimento de falhas:
― Nem sempre é óbvio quando ocorre uma falha, pois pode haver interpretações
conflitantes de uma especificação.
Teste de Confiabilidade
• Teste de Confiabilidade
20
• Os testes estatísticos podem ser usados em conjunto com uma injeção
de defeitos, para obtenção de dados sobre quão eficaz tem sido o
processo de testes de defeitos:
o A injeção de defeitos é deliberada de erros em um programa;
• Os testes estatísticos revelam erros no software que não foram
descobertos por outros processos de V & V:
o Esses erros podem significar que a confiabilidade de um sistema não está de
acordo com os requisitos;
o Que reparos devem ser realizados.
• Depois de finalizar os reparos, o sistema pode ser testado novamente
para reavaliar sua confiabilidade.
Perfis Operacionais
• O perfil operacional de um sistema de software reflete como ele será
usado na prática;
• Pode ser gerado a partir de dados reais coletados a partir de um sistema
existente ou (mais frequentemente) depende de suposições feitas sobre
o padrão de uso de um sistema;
o Ex: Sistemas de comutação telefônica.
• Desenvolver um perfil operacional exato é possível para alguns tipos de
sistema (sistemas de telecomunicação) que tem um padrão de uso;
• Quando o sistema de software é novo e inovador é difícil antecipar como
ele será usado e consequentemente é impossível criar um perfil
operacional exato.
21
• Teste de Confiabilidade
Perfis Operacionais
• O problema é agravado porque os perfis operacionais não são estáticos,
ou seja, mudam a medida que o sistema é usado:
o Na medida em que os usuários aprendem sobre o novo sistema, eles confiam
mais nele e começam a usá-lo de maneiras mais sofisticadas;
o Muitas vezes é impossível desenvolver um perfil operacional confiável.
22
• Teste de Confiabilidade
Classes de entradas
Nú
mero
de
en
trad
as
Teste de Proteção
• Teste de Proteção
23
AVALIAÇÃO DA PROTEÇÃO DO SISTEMA
Os processos de V & V de sistemas baseados em Web devem centrar
na avaliação de proteção, em que a capacidade do sistema é testada para resistir
a diferentes tipos de ataque.
Verificação da Proteção
• Combinação de testes, análises baseadas em ferramentas e
verificação formal:
24
• Teste de Proteção
Verificação da
Proteção Descrição
Testes baseado
em experiência
- O sistema é revisto e analisado contra os tipos de ataques que são
conhecidos para a equipe de validação;
- Criação de checklists de verificação.
Equipes Tigre
- Testes baseados em experiências;
- É possível aproveitar a experiência de fora da equipe de
desenvolvimento para testar um sistema de aplicação.
Testes baseados
em ferramenta
- Várias ferramentas de segurança tais como verificadores de senha são
utilizados para analisar o sistema em funcionamento.
Verificação formal
- O sistema é verificado contra uma especificação de segurança formal
de proteção.
Teste de Proteção
• Exemplos de entradas em um checklist de proteção:
25
• Teste de Proteção
Checklist de proteção
1. Todos os arquivos criados na aplicação têm permissões de acesso apropriadas? Quando
erradas, as permissões de acesso podem levar ao acesso desses arquivos por usuários não
autorizados.
2. O sistema automaticamente encerra as sessões de usuário depois de um período de inatividade?
Sessões que ficam ativas podem permitir acesso não autorizado através de um computador não
usado.
3. Se o sistema for escrito em linguagem de programação sem verificação de limite de vetor,
existem situações em que o overflow de buffer pode ser explorado? O overflow de buffer pode
permitir que invasores enviem e executem sequencias de código para o sistema.
4. Se as senhas forem definidas, o sistema verifica se elas são fortes? Senhas fortes consistem de
pontos, números e letras misturados e não são entradas de dicionário normal. São mais difíceis
de quebrar do que senhas simples.
5. As entradas do ambiente do sistema são sempre verificadas por meio da comparação com uma
especificação de entrada? O tratamento incorreto de entradas mal formadas é uma causa comum
de vulnerabilidade de proteção.
Teste de Proteção
• Os testes de proteção são limitados pelo tempo e recursos disponíveis
para a equipe de teste;
• Para testes de sistema, deve adotar uma abordagem baseada em riscos
e concentrar-se no que acham que são os riscos mais significativos
enfrentados pelo sistema;
• A análise dos riscos de proteção de sistema poderá ser usada para
conduzir o processo de teste;
• E muito difícil para os usuários finais de um sistema verificarem sua
proteção.
26
• Teste de Proteção
Garantia de Processo
• Envolve a definição de um processo confiável e garante que este
processo é seguido durante o desenvolvimento do sistema;
• Está relacionada com:
o Se os processos de desenvolvimento de sistema usados na organização são os
corretos;
o Se os processos de desenvolvimento estão sendo executados corretamente.
• Verificação da documentação:
o A documentação de cada inspeção deve incluir:
― Checklists usados para conduzir a inspeção;
― Uma lista de pessoas envolvidas;
― Os problemas identificados durante a inspeção;
― As ações necessárias.
o Os processos ágeis, portanto, raramente são utilizados para sistemas críticos.
• Garantia de Processo
27
Processos para Garantir Segurança
• Processo de desenvolvimento de sistemas críticos de segurança deve
incluir processos de V & V voltados para a análise e garantia de
segurança:
o Acidentes são eventos raros, e pode ser praticamente impossível simulá-los
durante os testes;
o Requisitos de segurança são, requisitos do tipo “não deve” que excluem os
comportamentos inseguros do sistema.
• As atividades especificas de garantia de segurança devem ser
incluídas em todos os estágios do processo de desenvolvimento de
software:
o Essas atividades de garantia de segurança registram as análises efetuadas e
a(s) pessoa(s) responsáveis por essas análises.
• Garantia de Processo
28
Processos para Garantir Segurança
• Atividades relacionadas com a segurança do processo de software:
o Monitoramento e registro de perigos: rastreia os perigos a partir de suas
análises preliminares por meio da validação de testes de sistema;
o Revisões de segurança: usadas em todo o processo de desenvolvimento;
o Certificação de segurança: a segurança dos componentes críticos é
formalmente certificada.
• Para apoiar esses processos de garantia de segurança, devem ser
nomeados os engenheiros de segurança de projeto que tenham
explicita responsabilidade sobre os aspectos de segurança de um sistema
o Os engenheiros de segurança trabalham com os gerentes de qualidade.
• Garantia de Processo
29
Processos para Garantir Segurança
• Processo de análise de perigos:
o Parte essencial do desenvolvimento de sistemas críticos;
o Trata da identificação dos perigos, sua probabilidade de ocorrência e a
probabilidade de cada perigo gerar um acidente;
o Deve haver rastreabilidade clara dos perigos identificados através da sua
análise para as ações tomadas durante o processo para garantir que esses
riscos foram cobertos;
o Log de perigos é um documento fornece evidências que provam como os
perigos identificados foram analisados durante o desenvolvimento de software;
― Usado em cada estagio do processo de desenvolvimento de software para
documentar como cada estagio de desenvolvimento tratou os perigos.
• Garantia de Processo
30
Processos para garantir segurança
• Garantia de Processo
31
Log de perigos Page 4: Printed 20.02.200
Sistema: sistema de bomba de insulina
Engenheiro de segurança: James Brown
Arquivo: InsulinPump/Safety/HazardLog
Versão do Log: 1/3
Perigo Identificado Overdose de insulina fornecida ao paciente
Identificado por Jane Williams
Classe de criticidade 1
Risco Identificado Alto
Árvore de defeitos identificada Sim Data 24.01.07 Local Log de perigos,
Página 5
Criadores de árvores de
defeitos Jane Williams e Bill Smith
Árvore de defeitos identificadas Sim Data 28.01.07 Verificador James Brown
Requisitos de projeto de segurança de sistema
1. O sistema deve incluir software d e auto teste, o qual testara o sistema d e sensor, o relógio e o sistema de fornecimento de
insulina.
2. O software de auto verificação deve ser executado uma vez por minuto.
3. No caso do software de auto verificação descobrir um defeito em qualquer um dos componentes de sistema, será emitido um
aviso sonoro e o display da bomba deve indicar o nome do componente em que o defeito foi descoberto. O fornecimento de
insulina será suspenso.
4. O sistema deve incorporar um sistema de configuração que permite que o usuário do sistema modifique a dose de insulina
computada que será fornecida pelo sistema.
5. A quantidade de configuração não deve ser maior que um valor pré-estabelecido (maxOverride), definido quando o sistema é
configurado pela equipe médica.
Casos de Segurança e Confiança
• Casos de segurança e confiança são documentos estruturados que
estabelecem argumentos e evidências detalhados de que um sistema é
seguro ou que alcançou o nível exigido de proteção ou confiança;
• Para muitos tipos de sistema críticos, a produção de um caso de
segurança é um requisito legal;
• O caso deve satisfazer um órgão regulador ou uma certificação antes
do sistema ser implantado:
o A responsabilidade do regulador é verificar se um sistema é tão seguro ou
confiável principalmente quando um projeto de desenvolvimento está concluído
o Os reguladores e os desenvolvedores trabalham juntos e negociam o que
precisa ser incluído em um caso de segurança e confiabilidade.
32
• Casos de Segurança e Confiança
Casos de Segurança e Confiança
• Casos de confiança são desenvolvidos durante e após o processo de
desenvolvimento de sistema;
• Casos de confiança são generalizações de casos de segurança de
sistema;
• Um caso de segurança é um conjunto de documentos que inclui:
o Uma descrição do sistema a ser certificado;
o Informações sobre os processos usados para desenvolver o sistema;
o Argumentos lógicos que demonstrem que o sistema está apto a ser seguro.
33
• Casos de Segurança e Confiança
Caso de Segurança
• Um caso de segurança é (Bishop e Bloomfield (1998)):
“Um corpo de evidências documentado, que fornece argumentos convincentes e
válidos de que um sistema é suficientemente seguro para determinada aplicação
em um determinado ambiente.”
• Os argumentos em um caso de segurança ou confiabilidade pode ser
baseada em: prova formal, razão design, provas de segurança
e fatores de processo;
• Caso de segurança de software é sempre parte de um caso de segurança
de sistema mais amplo que demonstra a segurança do sistema global:
o Caso de segurança de software deve:
― Relacionar as falhas de software com falhas de sistema globais;
― Demonstrar que essas falhas de software não ocorrerão ou não serão propagadas
de forma que possam ocorrer falhas perigosas de sistema.
34
• Casos de Segurança e Confiança
Conteúdo de um Caso de Segurança
35
Capítulo Descrição
Descrição do sistema Uma visão geral do sistema e uma descrição de seus componentes essenciais.
Requisitos de segurança Os requisitos de segurança abstraídos da especificação de requisitos de sistema. Detalhes
de outros requisitos relevantes de sistema também podem ser incluídos.
Análise de perigos e
riscos
Documentos que descrevem os perigos e os riscos identificados e as medidas tomadas
para reduzir os riscos. Análise de risco e logs de perigos,
Análise de projeto Um conjunto de argumento s estruturados que justifique por que o projeto e seguro.
Verificação e Validação
Uma descrição dos procedimentos de V & V usa dose, se for o caso, os planos de teste
para o sistema. Resumos dos resultados de testes mostrando defeitos que foram
detectados e corrigidos. Se foram usados métodos formais, uma especificação formal de
sistema e quaisquer análises dessa especificação. Registros de análises estáticas do
código-fonte.
Relatórios de Revisão Registro de todas as revisões de projeto e segurança.
Competências de
Equipe
Evidência de competência de todos da equipe envolvida no desenvolvimento e validação
de sistemas relacionados com a segurança.
Processo de QA Registro dos processos de garantia de qualidade efetuados durante o desenvolvimento do
sistema.
Processo de
gerenciamento de
mudanças
Registros de todas as mudança as propostas, ações tomadas e, se for o caso, justificativa
da segurança dessas mudanças. Informações sobre os procedimentos de gerenciamento
de configuração e logs de gerenciamento de configuração.
Casos de segurança
associados Referências a outros casos de segurança que podem afetar o processo de segurança;
• Casos de Segurança e Confiança
Argumentos Estruturados
• Um argumento é um relacionamento entre o que é pensado para ser o
caso (a afirmação) e um corpo de evidências do que foi coletado;
• O argumento explica por que a afirmação sobre a proteção de sistema ou
confiança, pode ser induzida pela evidência disponível;
o Ex: Bomba de insulina
• Os casos de segurança dependem de argumentos estruturados, baseados
em afirmações.
36
Evidência
Evidência
Evidência
Suporta
Suporta
Suporta
<<ARGUMENTO>> Justifica
Afirmação
• Casos de Segurança e Confiança
Argumentos Estruturados
• Argumentos são baseados em afirmações e evidências;
• Segurança da bomba de insulina:
37
Argumentos Descrição
Afirmação A dose máxima de insulina não excedera a maxDose, avaliada como uma
única dose segura para um paciente.
Evidência Argumento de segurança para programa de controle de software da bomba
de insulina.
Evidência Conjuntos de dados de teste para a bomba de insulina. Em 400 testes, o valor da currentDose foi corretamente computado e nunca excedeu a
maxDose.
Evidência A análise estática do software de controle revelou que nenhuma anomalia afetou o valor da currentDose.
Argumento As evidências apresentadas mostram que a dose máxima de insulina que pode ser computada é igual a maxDose.
• Casos de Segurança e Confiança
Argumentos Estruturados
• Argumentos estruturados demonstram que um sistema cumpre as suas
obrigações de segurança;
• Não é necessário demonstrar que o programa funciona conforme
esperado, o objetivo é simplesmente demonstrar a segurança;
• Baseados em uma hierarquia:
o É necessário trabalhar com os argumentos para as afirmações de nível inferior;
o Mostrar que cada uma dessas afirmações de nível inferior é justificada;
o Podendo ser capaz de inferir que as afirmações de nível superior são
justificadas.
38
• Casos de Segurança e Confiança
Argumentos Estruturados
• Uma hierarquia de afirmações de segurança para a bomba de
insulina:
39
• Casos de Segurança e Confiança
A bomba de insulina não vai entregar
uma única dose de insulina não segura
A dose máxima calculada pelo
software da bomba, não deve exceder a
maxDose
Em uma operação normal, a dose
máxima calculada não excede a
maxDose
Se o software falhar, a dose máxima calculada não
excederá a maxDose
A maxDose é definida
corretamente quando a bomba está configurada
A maxDose é uma dose segura apara o
usuário da bomba de insulina
Argumentos Estruturados de Segurança
• É um tipo de argumento que demonstra que um programa cumpre suas
obrigações de segurança:
o Não é necessário provar que o programa funciona conforme o esperado;
o Só é necessário mostrar que a execução do programa não pode resultar em um
estado inseguro;
o É mais econômico fazer argumentos de segurança do que argumentos de
correção.
• Para garantir a segurança no sistema deve:
o Demonstrar que defeitos que induzem a perigos críticos de segurança não
devem ocorrer;
o Demonstrar que o perigo associado não resultará em um acidente, caso o
defeito ocorra.
40
• Casos de Segurança e Confiança
Argumentos Estruturados de Segurança
• Etapas envolvidas na criação de um argumento de segurança:
o Inicia assumindo que um estado inseguro identificado na análise de perigos de
sistema, pode ser alcançado por meio da execução do programa;
o Define um predicado (uma expressão lógica) que determina esse estado
inseguro;
o Analisa sistematicamente um modelo de sistema ou o programa, mostrando
que todos os caminhos do programa levam até esse estado;
o Após repetir essa análise para todos os perigos identificados, será obtida fortes
evidências de que o sistema é seguro.
41
• Casos de Segurança e Confiança
Pontos Importantes
• A analise estática é uma abordagem para a V & V que examina o código-
fonte de um sistema, a fim de identificar erros e anomalias;
• A verificação de modelos é uma abordagem formal para análise estática
que verifica exaustivamente todos os estados de um sistema;
• Os testes estatísticos são usados para estimar a confiabilidade de
software.
• Validação de proteção é difícil porque os requisitos de proteção informam
“o que não deve” acontecer em um sistema, e não “o que deve”;
• É importante ter um processo certificado e bem definido para o
desenvolvimento de sistemas críticos de segurança;
• Os casos de segurança e confiança coletam todas as evidências que
demonstram que um sistema é seguro e confiável.
• Pontos Importantes
42