Paulo Cesar Masiero Engenharia de Software. Falhas provocam custos  Computadores são onipresentes  Problemas causados por falhas vêm piorando  Exemplos:

Apresentação em tema: "Paulo Cesar Masiero Engenharia de Software. Falhas provocam custos  Computadores são onipresentes  Problemas causados por falhas vêm piorando  Exemplos:"— Transcrição da apresentação:

1 Paulo Cesar Masiero Engenharia de Software

2

3 Falhas provocam custos  Computadores são onipresentes  Problemas causados por falhas vêm piorando  Exemplos: Falha em e-commerce Falha em controle embarcado de carros Software malicioso em computadores de uma empresa  O usuário precisa confiar no sistema

4 Confiança: Funcionalidade 1. Falhas do sistema afetam grande numero de pessoas 2. Usuários rejeitam sistemas não-confiáveis, inseguros ou desprotegidos 3. Custos de falhas do sistema podem ser enormes 4. Sistemas pouco confiáveis podem causar perdas de informação

5 Tipos de falhas 1. Falhas de Hardware 2. Falhas de Software 3. Falhas operacionais

6 Sistemas críticos  É um tipo de sistema em que falhas podem causar: Danos a pessoas, Danos ao ambientes, Grandes perdas econômicas  Exemplos: Bomba de insulina (crítico por segurança) Sistemas de navegação para ônibus espaciais (crítico por missão) Sistemas de transferência monetária online (crítico por negócio)

7

8 Confiança

9 Dimensões da Confiança Confiança Disponibilidade Habilidade do sistema fornecer serviços quando requisitado Confiabilidade Habilidade do sistema fornecer os serviços especificados Segurança Habilidade do sistema operar sem falhas catastróficas Proteção Habilidade do sistema se proteger contra intrusão acidental ou deliberada Definição Informal

10 Para desenvolver um software confiável é preciso... 1. Evitar introdução acidental de erros durante as fases de especificação e desenvolvimento. 2. Usar processos de verificação e validação que detectem erros residuais. 3. Projetar mecanismos de proteção que protejam o sistema contra ataques. 4. Configurar corretamente o sistema final e seus software de suporte para o ambiente operacional.... e incluir mecanismos de recuperação para restaurar o serviço o mais rapidamente possível.

11 Para tolerar defeitos é necessário:  Usar código redundante para: Monitorar o sistema Detectar estados errôneos Recuperar o sistema quando ocorrerem falhas  Consequência: Perda de eficiência EficiênciaConfiança Decisão do desenvolvedor

12 Custos  Software com baixa Confiança custa pouco para melhorar  Sistema com alta confiança custa exponencialmente mais caro  Custo aumenta exponencialmente BaixaMédiaAlta Muito Alta Ultra alta

13

14 Disponibilidade e Confiabilidade Disponibilidade e Confiabilidade são propriedades relacionadas que podem ser expressas numericamente.

15 Disponibilidade  Probabilidade do sistema estar ativo e funcional para fornecer os serviços quando requisitado  Ex. Se o sistema tem disponibilidade 0,999 significa que ele está disponível 99,9% das vezes em que é requisitado.

16 Confiabilidade  Probabilidade do sistema fornecer os serviço conforme definido na especificação do sistema  Ex. Se o sistema, em média, apresenta erros em 2 a cada 1.000 entradas a confiabilidade do sistema é 0,002

17 Relação entre Disponibilidade e Confiabilidade  A importância da propriedade depende do sistema: Se o usuário demanda uso continuo do sistema, então a disponibilidade deve ser alta ○ Sistemas bancários online Se os custos de uma falha são baixos, então a confiabilidade pode ser baixa. ○ Sistemas telefônicos.

18 Fator tempo  Disponibilidade leva em conta o tempo para resolver uma falha Sistema A 1 falha por ano 3 dias (média) para recuperar 4.320 minutos por ano indisponível Sistema B 1 falha por mês 10 minutos (média) para recuperar 120 minutos por ano indisponível Melhor disponibilidade

19 Fator Momento  Não só o tempo é importante para a disponibilidade, mas também o momento em que as falhas ocorrem.  Um sistema que falha uma hora por dia entre 3 e 4 da manhã não afeta tantos usuários quanto um sistema que falha 10 minutos por dia durante o horário comercial.  A definição de disponibilidade NÃO leva em conta o momento da falha.

20 Definições TermoDescrição Exemplo (sistema de avaliação climática remoto) Erro humano (Engano) Comportamento humano que resulta na introdução de erros no sistema Programador decide computar a hora da próxima transmissão como sendo (hora atual + 1). Erro de sistema (system fault) Característica de um sistema que pode levar a um defeito de sistema Adicionar 1 a hora atual sem verificar se hora atual > 23 Defeito de sistema (system error) Um estado incorreto do sistema, ou seja, um estado do sistema que não é esperado por seus projetistas Valor da hora de transmissão é entrado como 24.XX em vez de 00.XX Falha de sistema (system failure) Um evento que ocorre em algum momento, quando o sistema não fornece o serviço esperado por seus usuários A informação não é transmitida porque a hora está incorretamente informada

21 Estado de erro Input Set Programa Output Set

22 Defeitos e Falhas  Erros não necessariamente provocam defeitos.  Defeitos não necessariamente provocam falhas. Nem todo código de um programa é executado Defeitos são transientes O sistema pode conter detecção e proteção contra falhas. Usuários evitam entradas que a experiência mostrou provocar falhas.

23 Como Melhorar a Confiabilidade  Evitar erros.  Detecção e remoção de erros.  Tolerância a erros especificação

24 11.3 Segurança  Sistemas críticos com relação à segurança são aqueles em que a operação do sistema deve ser sempre segura, isto é, não devem causar danos às pessoas e ao ambiente, mesmo que ocorra uma falha.  Exemplos: Sistemas de controle de aviões; Sistemas de controle de automóveis; Sistemas de controle de plantas químicas, etc.

25 Geralmente...  É mais simples implementar e analisar o controle de hardware do que o de software.  Entretanto, sistemas muito complexos muitas vezes não podem ser controlados só por hardware. Ex: aeronaves militares são aerodinamicamente instáveis e requerem ajuste contínuo controlado por software.

26 Tipos de Software Crítico com relação à... ... segurança primária: é um software embarcado como um controlador em um sistema. Se o software não funcionar bem, causa problema ao hardware. Ex. bomba de insulina ...segurança secundária: é um software que pode causar indiretamente um dano. Exemplo: um sistema de CAD/CAM.

27 Confiabilidade e segurança  Há um relacionamento entre confiabilidade e segurança mas uma não implica na outra.  Razões para que um software confiável seja inseguro: Não é possível estar 100% seguro que um software esteja livre de defeitos, que podem ficar adormecidos por muito tempo; A especificação pode ser incompleta; Problemas de hardware podem levar a comportamentos imprevisíveis; Operadores do sistema podem gerar entradas erradas ou de tal forma combinadas que levam a erros.

28 Terminologia de Segurança

29 Garantia de segurança  Garantir que não ocorram acidentes ou que as consequências sejam mínimas. Prevenção de perigos: evitar riscos. Ex. apertar dois botões para assegurar que as duas mãos estejam fora do alcance do perigo. Detecção e remoção de perigos. Ex. válvula para aliviar pressão. Limitação de danos: motor de avião, que possuem extintores de incêndio automáticos.

30 Garantia da segurança (cont.)  Análises de acidentes mostram que os acidentes geralmente ocorrem quando há várias falhas ao mesmo tempo.  Combinações inesperadas de falhas podem levar a falhas globais.  Há argumentos prós e contras o uso de software para controle.  É preciso fazer uma análise de senso de proporção sobre a segurança do sistema, já que sistemas 100% seguros são impossíveis.

31 Proteção  É um atributo do sistema que reflete sua capacidade de se proteger de ataques externos (acidentais ou deliberados).  O uso em rede facilita o acesso de estranhos.  Exemplos: vírus, cavalos de troia, acesso não autorizado,...  Para alguns sistemas, a proteção é a dimensão mais importante da confiança. Ex. sistemas militares, de comércio eletrônico e de reserva de passagens aéreas.

32 Terminologia de proteção

33 Principais ameaças à proteção de sistemas em rede:  Confidencialidade do sistema e seus dados.  Integridade do sistema e seus dados.  Disponibilidade do sistema e seus dados.  As três são naturalmente interdependentes.

34 Vulnerabilidades em Sistemas de Informação  Falhas humanas: senhas fáceis de descobrir ou senhas anotadas em lugares que são facilmente descobertos Administradores cometem erros de configuração de controle de acesso Usuários não instalam software de proteção  Muitas vezes, erros que parecem dos usuários são facilitados por decisões de projeto. Exemplo: exigência de alterações constantes de senhas, que levam à anotação das senhas em papel.

35 Controles para melhorar a proteção  Prevenção de vulnerabilidade: para evitar que os ataques sejam bem sucedidos Sistema não está ligado a uma rede pública Criptografia  Detecção e neutralização de ataques: funcionalidades para monitorar a operação do sistema e descobrir padrões incomuns de uso e tomar medidas como desligar o sistema, restringir o acesso etc.  Limitação de exposição e recuperação. Ex. backups automatizado e espelhamento.

36 Comentários finais  Métodos para certificação de disponibilidade, confiabilidade e segurança de sistemas assumem que o software operacional é o mesmo instalado originalmente.  Se o sistema foi atacado e modificado, esses princípios não são mais válidos.  Exemplo: controle de limites de vetores.