Garantia de Confiança e Proteção

Transcrição

1 Garantia de Confiança e Proteção Alinne Corrêa e Francisco Carlos {alinne, fcarlos}@icmc.usp.br Junho, / 42

2 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

3 Introdução 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

4 Introdução Validação em Sistemas Críticos Razões Custos de falhas Validação de atributos de confiança Descrição - 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. - 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. 4

5 Introdução Custos da Validação 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

6 Análise Estática Análise Estática 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 6

7 Análise Estática Verificação e métodos formais 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. 7

8 Análise Estática Verificação e Métodos Formais 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 8

9 Análise Estática Verificação e Métodos Formais 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. 9

10 Análise Estática Verificação de Modelo 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. 10

11 Análise Estática Verificação de Modelo 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 Modelo de estado finito estendido do sistema Verificador de modelo Especificação de propriedade Propriedades do sistema desejadas Confirmação ou contraexemplos 11

12 Análise Estática Verificação de Modelo 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. 12

13 Análise Estática Análise Estática Automática 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. 13

14 Análise Estática Análise Estática Automática Classe de defeito Defeitos de dados Defeitos de controle Defeitos de entrada /saída Defeitos de interface Defeitos de gerenciamento de armazenamento Verificação de análise estática automática - 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 - Código inacessível - Ramos incondicionais centro de loops - Saída de variáveis duas vezes sem atribuição intermediária - 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 - Ponteiros não atribuídos - Ponteiro aritmético - Perdas de memória 14

15 Análise Estática 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

16 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

17 Teste de Confiabilidade Teste de Confiabilidade É 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 17

18 Teste de Confiabilidade Teste de Confiabilidade 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. 18

19 Teste de Confiabilidade Teste de Confiabilidade 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. 19

20 Teste de Confiabilidade Teste de Confiabilidade 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. 20

21 Teste de 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

22 Número de entradas 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. Classes de entradas 22

23 Teste de Proteção Teste de Proteção 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. 23

24 Teste de Proteção Verificação da Proteção Combinação de testes, análises verificação formal: baseadas em ferramentas e Verificação da Proteção Testes baseado em experiência Equipes Tigre Testes baseados em ferramenta Descrição - 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. - Testes baseados em experiências; - É possível aproveitar a experiência de fora da equipe de desenvolvimento para testar um sistema de aplicação. - 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. 24

25 Teste de Proteção Teste de Proteção Exemplos de entradas em um checklist 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. 25

26 Teste 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

27 Garantia de Processo 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. 27

28 Garantia de Processo 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. 28

29 Garantia de Processo 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. 29

30 Garantia de Processo 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. 30

31 Garantia de Processo Processos para garantir segurança Log de perigos Page 4: Printed Sistema: sistema de bomba de insulina Engenheiro de segurança: James Brown Perigo Identificado Identificado por Classe de criticidade 1 Risco Identificado Overdose de insulina fornecida ao paciente Jane Williams Alto Arquivo: InsulinPump/Safety/HazardLog Versão do Log: 1/3 Árvore de defeitos identificada Sim Data Local Criadores de árvores de defeitos Jane Williams e Bill Smith Log de perigos, Página 5 Árvore de defeitos identificadas Sim Data 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. 31

32 Casos de Segurança e Confiança 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

33 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

34 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

35 Casos de Segurança e Confiança Conteúdo de um Caso de Segurança Capítulo Descrição do sistema Requisitos de segurança Análise de perigos e riscos Análise de projeto Verificação e Validação Relatórios de Revisão Competências de Equipe Processo de QA Processo de gerenciamento de mudanças Casos de segurança associados Descrição Uma visão geral do sistema e uma descrição de seus componentes essenciais. 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. 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, Um conjunto de argumento s estruturados que justifique por que o projeto e seguro. 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. Registro de todas as revisões de projeto e segurança. Evidência de competência de todos da equipe envolvida no desenvolvimento e validação de sistemas relacionados com a segurança. Registro dos processos de garantia de qualidade efetuados durante o desenvolvimento do sistema. 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. Referências a outros casos de segurança que podem afetar o processo de segurança; 35

36 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. Evidência Suporta Evidência Suporta <<ARGUMENTO>> Justifica Afirmação Evidência Suporta 36

37 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: Argumentos Afirmação Evidência Evidência Evidência Argumento Descrição A dose máxima de insulina não excedera a maxdose, avaliada como uma única dose segura para um paciente. Argumento de segurança para programa de controle de software da bomba de insulina. 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. A análise estática do software de controle revelou que nenhuma anomalia afetou o valor da currentdose. As evidências apresentadas mostram que a dose máxima de insulina que pode ser computada é igual a maxdose. 37

38 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

39 Casos de Segurança e Confiança Argumentos Estruturados Uma hierarquia de afirmações de segurança para a bomba de insulina: 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 A maxdose é definida corretamente quando a bomba está configurada A maxdose é uma dose segura apara o usuário da bomba de insulina 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 39

40 Casos de Segurança e Confiança 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

41 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

42 Pontos Importantes Pontos Importantes A analise estática é uma abordagem para a V & V que examina o códigofonte 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. 42