Especificação de confiabilidade e segurança ?· Requisitos de confiabilidade e segurança •Confiabilidade…

Download Especificação de confiabilidade e segurança ?· Requisitos de confiabilidade e segurança •Confiabilidade…

Post on 20-Nov-2018

212 views

Category:

Documents

0 download

TRANSCRIPT

  • Especificao de confiabilidade e segurana

    Danilo Mendes

    Rodrigo Corra

  • Aeroporto de Varsvia, Polnia (1993)

    Um avio modelo Lufthansa A320 seguia em direo ao aeroporto de Varsvia.

    9 segundos aps a aterrissagem os sistemas de freio automticos no funcionavam.

    O sistema no havia reconhecido que o avio j havia pousado (falha).

    Uma ferramenta de segurana garantiu que o sistema no habilitasse o reversor, pois seria perigoso caso isso fosse feito no ar.

    O Avio seguiu em direo a um banco de areia e pegou fogo.

  • Aeroporto de Varsvia, Polnia (1993)

  • Houve falha do sistema como um todo?

    Houve falha do sistema de freios?

    Aeroporto de Varsvia, Polnia (1993)

  • Requisitos de confiabilidade e segurana

    Confiabilidade no depende apenas de bom trabalho de engenharia

    Requer ateno na hora de levantar os requisitos

    Requisitos adicionais em relao confiabilidade e segurana devem ser includos

  • Requisitos de confiabilidade e segurana

    Requisitos funcionais: definem as ferramentas de verificao, recuperao do sistema e proteo contra falhas e ataques externos (requisitos no deve).

    E.g.: O sistema no deve permitir que o reversor seja ligado se o avio estiver voando

    Requisitos no-funcionais: garantem a confiabilidade e a disponibilidade do sistema.

  • Abordagem baseada em riscos

    Como descobrir os requisitos de segurana e confiabilidade? Abordagem baseada em riscos

    necessrio identificar e classificar as catstrofes que causaro os eventos, incluindo suas probabilidades de ocorrncia

    Gerar requisitos que devero impedir ou, pelo menos, minimizar os problemas de maior ocorrncia e aqueles que, mesmo improvveis, causaro danos graves.

  • Abordagem baseada em riscos

    Fonte: Sommerville, 2011

  • I - Identificao dos riscos

    Os riscos do sistema so identificados

    Depende apenas do meio em que a aplicao ser implementada (independente da tecnologia utilizada)

  • II - Anlise dos riscos e classificao

    Cada risco considerado separadamente.

    Aqueles que so potencialmente perigosos e no so improvveis so selecionados para anlise futura.

    Neste estgio, riscos que so improvveis ou no podem ser detectados pelo sistema so eliminados Ex.: reao alrgica causada por sistema de

    bombeamento de insulina

  • III - Decomposio de riscos

    Cada risco tem sua causa identificada.

    As causas podem ser por problemas no hardware, software ou herdadas de falhas no projeto.

  • IV Reduo de riscos

    Propor maneiras para reduo ou eliminao dos riscos

    Esta etapa gera requisitos de confiabilidade

  • Etapas adicionais (p/ grandes sistemas)

    A anlise de risco deve ser divida em trs partes:

    Anlise preliminar: apenas dos riscos do meio da aplicao

    Anlise de ciclo de vida: dos riscos que aparecem no desenvolvimento ou no projeto

    Anlise de risco operacional: dos riscos envolvendo interface com usurio.

  • Abordagem baseada em riscos

    Todas as etapas so importantes! impossvel fazer todas as decises de segurana

    e confiabilidade sem conhecimento total do sistema.

  • Especificao de segurana Sistemas de segurana crtica so sistemas onde

    suas falhas podem causar danos ou morte aos seus usurios.

    Os seus requisitos geralmente no esto relacionados com os requisitos comuns do sistemas (requisitos de proteo).

    Baseada na busca por perigos.

    Segurana e funcionalidade

    Superproteo

  • Especificao de segurana

    Identificao dos perigos

    Avaliao dos perigos

    Anlise dos perigos

    Reduo dos riscos

    Mapeada na abordagem baseada em riscos

  • I - Identificao dos perigos

    Listar todos os perigos envolvidos no problema com ajuda de especialista da rea.

    Classific-los de acordo com seu tipo (eltrico, biolgico, fsico, falha no sistema, etc.).

    Tcnicas em grupo como brainstorm so utilizadas. Exemplos (sistema bombeador de insulina):

    Envio de quantidade demasiada de insulina (falha no sistema)

    Envio de quantidade abaixo do esperado de insulina (falha no sistema)

    Reao alrgica ao equipamento (biolgico) Fim da bateria (eltrico)

  • II - Avaliao dos perigos

    Levantamento das consequncias e probabilidades de eventos perigosos ocorrerem.

  • II - Avaliao dos perigos

  • II - Avaliao dos perigos

    Riscos no tolerveis: esto ligadas aos risco de vida dos seres envolvidos. O sistema deve garantir preveno desses eventos.

    ALARP (As low as reasonably practical): so riscos de consequncias menores ou com baixssimas chances de ocorrncia se possurem consequncia grave. Anlises de custos e viabilidade devem ser feitas

    Riscos aceitveis: so riscos que no afetam em nada o sistema Os projetistas devem minimizar a quantidade de riscos

    aceitveis, contanto que no afete significantemente os gastos, tempo de entrega ou outros requisitos funcionais

  • II - Avaliao dos perigos

  • II - Avaliao dos perigos

  • III Anlise dos perigos

    Encontrar as causas razes dos perigos.

    Podem ser empregadas abordagens top-down (intuitivas) ou bottom-top (indutivas).

    Vrias tcnicas podem ser utilizadas.

    Redes de Petri (Peterson, 1981)

    Lgica formal (Jahanian & Mok, 1986)

    rvores de falhas (Leveson & Stolzy, 1987)

  • III Anlise dos perigos Sistema bombeador de insulina

  • IV Reduo dos riscos

    Neste estgio, os perigos j foram identificados, avaliados e analisados. Resta apenas a soluo.

    Existem trs abordagens distintas Evitar o perigo

    Deteco e remoo de perigo

    Limitao de danos

    Normalmente so utilizados uma combinao das trs abordagens.

  • IV Reduo dos riscos Sistema bombeador de insulina

    Erros aritmticos Alguma operao matemtica leva a uma

    inconsistncia. Gerar exceo e trat-la.

    Levar o sistema a um estado seguro (desligado).

    Erros no algoritmo Mais difcil de ser tratado, pois no existe exceo

    clara a ser tratada.

    Poderia ser resolvido comparando medidas anteriores e percebendo discrepncia.

  • 12.3 Especificao de confiabilidade

    Segurana e proteo Evitar situaes indesejadas Confiabilidade Limitar situaes indesejadas

    possvel especificar o nvel de confiabilidade do sistema.

    Dependncias

    Confiabilidade do hardware Confiabilidade do software Confiabilidade dos operadores

    Requisitos de confiabilidade devem

    Compensar falhas de software Ajudar a detectar e recuperar o sistema aps falhas de hardware

    ou erros do operador.

  • 12.3 Especificao de confiabilidade

    Processo de especificao de confiabilidade

    Identificao dos riscos

    Identificar os tipos de falhas no sistema que podem acarretar alguma perda econmica.

    Analise dos riscos Estimar os custos e consequncias dos diferentes tipos de falhas.

    Selecionar as falhas mais graves para anlise posterior.

    Decomposio dos riscos Analisar a raiz da causa da provvel falha.

  • 12.3 Especificao de confiabilidade

    Processo de especificao de confiabilidade

    Reduo dos riscos

    Deve-se estabelecer as probabilidades aceitveis dos diferentes tipos de falhas, levando em conta os custos de cada falha.

  • 12.3.1 Indicadores de confiana

    Probabilidade de falha na demanda (POFOD) Probabilidade de ocorrer uma falha durante um ciclo do

    sistema. Ex.: POFOD = 0.001 significa que existe 1 chance em 1000 de ocorrer

    uma determinada falha durante uma execuo do sistema.

    Taxa de ocorrncia de falhas (ROCOF) Nmero provvel de falhas no sistema relativo a um

    determinado perodo de tempo ou um determinado numero de execues do sistema. Ex.: ROCOF= 1/1000 significa que em 1000 execues do sistema,

    apenas uma falha ocorrer.

  • 12.3.1 Indicadores de confiana

    Disponibilidade (AVAIL)

    Probabilidade do sistema estar operando quando

    requisitado um servio. Ex.: AVAIL= 0.9999 significa que o sistema estar disponivel,

    em mdia, durante 99,99% do tempo de operao.

    Tempo mdio entre falhas (MTTF)

    Unidade de tempo mdia entre falhas no sistema.

    Ex.: MTTF = 30min significa que a cada meia hora ocorrer uma falha.

  • 12.3.1 Indicadores de confiana

    Para avaliar a confiana do sistema necessrio obter dados da sua operao.

    Ex.: O nmero de falhas dos sistema dado um nmero de pedidos

    de servio ao sistema. Utilizado para medir a probabilidade de falha na demanda (POFOD).

    O tempo ou o nmero de transaes entre falhas no sistema. Utilizado para medir a taxa de ocorrncia de falhas (ROCOF) e o tempo

    mdio entre falhas (MTTF).

    O tempo de restaurar ou reiniciar o sistema aps uma falha que leva a perda de servio. Utilizado para medir a disponibilidade do sistema (AVAIL).

  • 12.3.2 Requisitos de confiabilidade no funcionais

    Envolve especificaes quantitativas dos requisitos de confiabilidade e disponibilidade do sistema.

    Vantagens: Decidir o nvel de confiabilidade do sistema, mostrando o

    que realmente necessrio.

    Fornece uma base para avaliar quando os testes no sistema podem ser interrompidos (assim que o nvel de confiabilidade de cada requisito for atingido).

    uma forma de avaliar qual estratgia de design melhora a confiabilidade do sistema.

    Certificao do sistema.

  • 12.3.2 Requisitos de confiabilidade no funcionais

    Dificuldade: Traduzir experincias prticas em especificaes

    quantitativas.

    Custos em testes.

    Ex.: 1. POFOD = 0.0001. Ento necessrio cerca de 50 mil

    testes para verificar se o POFOD de determinada falha realmente 0.0001.

    2. 1 000 copias do sistema esto instaladas e o sistema executa 1 000 vezes por segundo e o sistema no pode falhar uma nica vez.

  • 12.3.2 Requisitos de confiabilidade no funcionais

    Passos para evitar especificaes mal estimadas

    Especificar os requisitos para diferentes tipos de falhas.

    Especificar separadamente os requisitos para servios diferentes.

    Decidir quando necessrio melhorar a confiabilidade e quando pode-se atingir os objetivos de outra maneira. Ex.: Um sistema bancrio pode investir altos valores para evitar

    falhas durante certas operaes quando estas poderiam ser apenas canceladas.

  • 12.3.3 Requisitos de confiabilidade funcionais

    Envolve identificar os requisitos que definem restries e caractersticas que contribuem para a confiabilidade do sistema.

    3 Tipos: 1. Requisitos de checagem

    Restries nas portas de entrada do sistema para evitar valores incorretos ou fora da zona de valores permitidos.

    2. Requisitos de recuperao Devem ajudar na recuperao do sistema aps uma falha.

    Ex.: Ponto de restaurao do windows.

    3. Requisitos de redundncia Implicam em redundncias no sistema para que uma falha

    isolada no gere uma perda total do servio.

  • 12.3.3 Requisitos de confiabilidade funcionais

    Exemplos:

    RR1: Um intervalo de valores deve ser definido para todos

    os operadores de entrada. (Requisito de checagem)

    RR2: Copias do bando de dados dos pacientes devem ser mantidas em 2 servers separados que no estejam no mesmo prdio. (Requisito de restaurao e requisito de redundncia)

  • 12.4 Especificaes de proteo

    Semelhanas com especificaes de segurana impraticvel de especificar quantitativamente.

    Deve-se usar no deve na elaborao dos requisitos.

    Diferenas: Ataques ao sistema so planejados e o invasor pode

    conhecer os pontos fracos do sistema.

    Encontrar a raiz do ataque pode ser difcil, uma vez que esta pode ter sido ocultada.

    Desligar o sistema, na maioria das vezes, significa que o ataque foi bem sucedido.

    O invasor pode realizar ataques diferentes, aprimorando-se a medida que comea a conhecer mais o sistema.

  • 12.4 Especificaes de proteo

    10 tipos de requisitos de proteo (Firesmith - 2003) 1. Requisitos de identificao

    Especifica quando um sistema deve identificar o usurio que ir interagir com ele.

    2. Requisitos de autenticao Especifica como um usurio deve ser identificado.

    3. Requisitos de autorizao Especifica os privilgios e permisses de acesso de um

    usurio identificado.

  • 12.4 Especificaes de proteo

    4. Requisitos de imunidade Especifica como um sistema deve se proteger contra vrus,

    worms e ameaas similares.

    5. Requisitos de integridade

    Especifica como a corrupo dos dados pode ser evitada.

    6. Requisitos de deteco de intrusos

    Especifica quais mecanismos devem ser usados para detectar ataques ao sistema.

    7. Requisitos de no repudiao

    Especifica que uma parte em transao no pode negar seu envolvimento nesta.

  • 12.4 Especificaes de proteo

    8. Requisitos de privacidade Especifica como a privacidade dos dados ser mantida.

    9. Requisitos de auditoria de proteo Especifica como o uso do sistema pode ser auditado e

    verificado.

    10. Requisitos de manuteno da proteo do sistema Especifica como um aplicativo pode prevenir que

    alteraes autorizadas acidentalmente passem pelos mecanismos de proteo.

  • 12.4 Especificaes de proteo

    Estgios do processo:

    Processo de avaliao e analise de riscos so variaes do processo de especificaes genricas da abordagem baseada em riscos.

  • 12.4 Especificaes de proteo

    Estgios do processo: 1. Identificao (Identificao de riscos)

    Onde os ativos do sistema que requerem proteo so identificados.

    2. Avaliao do valor de um ativo (Anlise dos riscos) Estimar o valor de um ativo identificado.

    3. Avaliao da exposio (Anlise dos riscos) Avaliar a perda em potencial associada a cada ativo.

    4. Identificao de ameaas (Anlise dos riscos) Identificar as ameaas que podem ocorrer nos ativos do

    sistema.

  • 12.4 Especificaes de proteo

    5. Avaliao de ataques (Decomposio dos riscos) Decompor cada ameaa em ataques que o sistema pode sofrer e

    as possveis maneiras que este ataque pode ocorrer.

    6. Controle de identificao (Reduo dos riscos) Propor os controles que podem ser instalados para proteger os

    ativos.

    7. Avaliao de viabilidade (Reduo dos riscos)

    Avaliar a viabilidade tcnica e os custos dos controles propostos.

    8. Definio dos requisitos de proteo (Reduo dos

    riscos) Formular os requisitos de proteo do sistema utilizando os

    conhecimentos da exposio do sistema, das ameaas e da avaliao dos controles.

  • 12.4 Especificaes de proteo

    Exemplo: Sistema de informao (Hospital para sade mental) Requisitos de proteo

    1. Informaes sobre o paciente devem ser baixadas do banco de dados para uma rea segura no computador do consultrio no inicio de cada consulta.

    2. Todas as informaes referentes aos pacientes devem ser criptografadas.

    3. As informaes sobre o paciente deve ser atualizadas no banco de dados e ento deletadas do computador do consultrio ao final de cada consulta.

    4. Um registro de todas as alteraes feitas no banco de dados do sistema e quem as fez deve ser mantido em um computador que no seja o mesmo onde est o bando de dados.

  • 12.5 Especificao formal

    Abordagem baseada em formalismo matemtico onde definido um modelo formal para o software.

    Em princpio, possvel comear com um modelo formal e provar que o sistema desenvolvido consistente com o modelo, eliminando falhas resultantes dos erros de programao

  • 12.5 Especificao formal

    Modelo formal

    Traduo dos requisitos de sistema do usurio (escrito em linguagem natural, diagramas e tabelas) em linguagem matemtica com semntica formal definida.

    No ambgua

    Permite verificao do comportamento do modelo (manualmente ou com ferramentas automatizadas)

  • 12.5 Especificao formal - Vantagens

    Conforme a especificao formal criada, os requisitos do sistema ficam cada vez mais compreendidos. Causa deteco antecipada de erros

    Como a especificao descrita em linguagem formal, possvel automatizar a deteco de inconsistncias.

    Pode reduzir custos de testes do programa por ter sido verificado atravs da especificao formal e no do uso do programa em si.

  • 12.5 Especificao formal - Desvantagens

    Responsveis e especialistas do negcio podem no entender a linguagem formal, bem como engenheiros que entendem a linguagem formal no entendem e to bem o negcio.

    Muito difcil de prever o ganho financeiro em adotar estar abordagem.

    Resistncia por parte dos engenheiros que no sabem utilizar os mtodos formais

    No se aplica muito a problemas de grande escala

    No compatvel com mtodos geis de desenvolvimento

  • 12.5 Especificao formal - Desvantagens

    http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdf

    http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdfhttp://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdf

Recommended

View more >