Garantia de Confiança e Proteção€¦ · mesmo nível de confiança no sistema pode ser alcançado de forma mais barata, ... •O processo de medição de confiabilidade envolve

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


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


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


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


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.



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



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


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.



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


• 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



• Ú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


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



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.



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.



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


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


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


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


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


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.


28


• 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


• 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

Processos para garantir segurança


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


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


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;


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



• 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.



• 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



• Uma hierarquia de afirmações de segurança para a bomba de

insulina:

39


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


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


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

Documents

Garantia de Confiança e Proteção€¦ · mesmo nível de confiança no sistema pode ser alcançado de forma mais barata, ... •O processo de medição de confiabilidade envolve