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

Embed Size (px)

TRANSCRIPT

<ul><li><p>Especificao de confiabilidade e segurana </p><p>Danilo Mendes </p><p>Rodrigo Corra </p></li><li><p>Aeroporto de Varsvia, Polnia (1993) </p><p> Um avio modelo Lufthansa A320 seguia em direo ao aeroporto de Varsvia. </p><p> 9 segundos aps a aterrissagem os sistemas de freio automticos no funcionavam. </p><p> O sistema no havia reconhecido que o avio j havia pousado (falha). </p><p> Uma ferramenta de segurana garantiu que o sistema no habilitasse o reversor, pois seria perigoso caso isso fosse feito no ar. </p><p> O Avio seguiu em direo a um banco de areia e pegou fogo. </p></li><li><p>Aeroporto de Varsvia, Polnia (1993) </p></li><li><p> Houve falha do sistema como um todo? </p><p> Houve falha do sistema de freios? </p><p>Aeroporto de Varsvia, Polnia (1993) </p></li><li><p>Requisitos de confiabilidade e segurana </p><p> Confiabilidade no depende apenas de bom trabalho de engenharia </p><p> Requer ateno na hora de levantar os requisitos </p><p> Requisitos adicionais em relao confiabilidade e segurana devem ser includos </p></li><li><p>Requisitos de confiabilidade e segurana </p><p> Requisitos funcionais: definem as ferramentas de verificao, recuperao do sistema e proteo contra falhas e ataques externos (requisitos no deve). </p><p> E.g.: O sistema no deve permitir que o reversor seja ligado se o avio estiver voando </p><p> Requisitos no-funcionais: garantem a confiabilidade e a disponibilidade do sistema. </p></li><li><p>Abordagem baseada em riscos </p><p> Como descobrir os requisitos de segurana e confiabilidade? Abordagem baseada em riscos </p><p> necessrio identificar e classificar as catstrofes que causaro os eventos, incluindo suas probabilidades de ocorrncia </p><p> Gerar requisitos que devero impedir ou, pelo menos, minimizar os problemas de maior ocorrncia e aqueles que, mesmo improvveis, causaro danos graves. </p></li><li><p>Abordagem baseada em riscos </p><p>Fonte: Sommerville, 2011 </p></li><li><p>I - Identificao dos riscos </p><p> Os riscos do sistema so identificados </p><p> Depende apenas do meio em que a aplicao ser implementada (independente da tecnologia utilizada) </p></li><li><p>II - Anlise dos riscos e classificao </p><p> Cada risco considerado separadamente. </p><p> Aqueles que so potencialmente perigosos e no so improvveis so selecionados para anlise futura. </p><p> Neste estgio, riscos que so improvveis ou no podem ser detectados pelo sistema so eliminados Ex.: reao alrgica causada por sistema de </p><p>bombeamento de insulina </p></li><li><p>III - Decomposio de riscos </p><p> Cada risco tem sua causa identificada. </p><p> As causas podem ser por problemas no hardware, software ou herdadas de falhas no projeto. </p></li><li><p>IV Reduo de riscos </p><p> Propor maneiras para reduo ou eliminao dos riscos </p><p> Esta etapa gera requisitos de confiabilidade </p></li><li><p>Etapas adicionais (p/ grandes sistemas) </p><p> A anlise de risco deve ser divida em trs partes: </p><p> Anlise preliminar: apenas dos riscos do meio da aplicao </p><p> Anlise de ciclo de vida: dos riscos que aparecem no desenvolvimento ou no projeto </p><p> Anlise de risco operacional: dos riscos envolvendo interface com usurio. </p></li><li><p>Abordagem baseada em riscos </p><p>Todas as etapas so importantes! impossvel fazer todas as decises de segurana </p><p>e confiabilidade sem conhecimento total do sistema. </p></li><li><p>Especificao de segurana Sistemas de segurana crtica so sistemas onde </p><p>suas falhas podem causar danos ou morte aos seus usurios. </p><p> Os seus requisitos geralmente no esto relacionados com os requisitos comuns do sistemas (requisitos de proteo). </p><p> Baseada na busca por perigos. </p><p>Segurana e funcionalidade </p><p>Superproteo </p></li><li><p>Especificao de segurana </p><p>Identificao dos perigos </p><p>Avaliao dos perigos </p><p>Anlise dos perigos </p><p>Reduo dos riscos </p><p>Mapeada na abordagem baseada em riscos </p></li><li><p>I - Identificao dos perigos </p><p> Listar todos os perigos envolvidos no problema com ajuda de especialista da rea. </p><p> Classific-los de acordo com seu tipo (eltrico, biolgico, fsico, falha no sistema, etc.). </p><p> Tcnicas em grupo como brainstorm so utilizadas. Exemplos (sistema bombeador de insulina): </p><p> Envio de quantidade demasiada de insulina (falha no sistema) </p><p> Envio de quantidade abaixo do esperado de insulina (falha no sistema) </p><p> Reao alrgica ao equipamento (biolgico) Fim da bateria (eltrico) </p></li><li><p>II - Avaliao dos perigos </p><p> Levantamento das consequncias e probabilidades de eventos perigosos ocorrerem. </p></li><li><p>II - Avaliao dos perigos </p></li><li><p>II - Avaliao dos perigos </p><p> Riscos no tolerveis: esto ligadas aos risco de vida dos seres envolvidos. O sistema deve garantir preveno desses eventos. </p><p> 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 </p><p> Riscos aceitveis: so riscos que no afetam em nada o sistema Os projetistas devem minimizar a quantidade de riscos </p><p>aceitveis, contanto que no afete significantemente os gastos, tempo de entrega ou outros requisitos funcionais </p></li><li><p>II - Avaliao dos perigos </p></li><li><p>II - Avaliao dos perigos </p></li><li><p>III Anlise dos perigos </p><p> Encontrar as causas razes dos perigos. </p><p> Podem ser empregadas abordagens top-down (intuitivas) ou bottom-top (indutivas). </p><p> Vrias tcnicas podem ser utilizadas. </p><p> Redes de Petri (Peterson, 1981) </p><p> Lgica formal (Jahanian &amp; Mok, 1986) </p><p> rvores de falhas (Leveson &amp; Stolzy, 1987) </p></li><li><p>III Anlise dos perigos Sistema bombeador de insulina </p></li><li><p>IV Reduo dos riscos </p><p> Neste estgio, os perigos j foram identificados, avaliados e analisados. Resta apenas a soluo. </p><p> Existem trs abordagens distintas Evitar o perigo </p><p> Deteco e remoo de perigo </p><p> Limitao de danos </p><p> Normalmente so utilizados uma combinao das trs abordagens. </p></li><li><p>IV Reduo dos riscos Sistema bombeador de insulina </p><p> Erros aritmticos Alguma operao matemtica leva a uma </p><p>inconsistncia. Gerar exceo e trat-la. </p><p> Levar o sistema a um estado seguro (desligado). </p><p> Erros no algoritmo Mais difcil de ser tratado, pois no existe exceo </p><p>clara a ser tratada. </p><p> Poderia ser resolvido comparando medidas anteriores e percebendo discrepncia. </p></li><li><p>12.3 Especificao de confiabilidade </p><p> Segurana e proteo Evitar situaes indesejadas Confiabilidade Limitar situaes indesejadas </p><p> possvel especificar o nvel de confiabilidade do sistema. </p><p> Dependncias </p><p> Confiabilidade do hardware Confiabilidade do software Confiabilidade dos operadores </p><p> Requisitos de confiabilidade devem </p><p> Compensar falhas de software Ajudar a detectar e recuperar o sistema aps falhas de hardware </p><p>ou erros do operador. </p></li><li><p>12.3 Especificao de confiabilidade </p><p> Processo de especificao de confiabilidade </p><p> Identificao dos riscos </p><p> Identificar os tipos de falhas no sistema que podem acarretar alguma perda econmica. </p><p> Analise dos riscos Estimar os custos e consequncias dos diferentes tipos de falhas. </p><p> Selecionar as falhas mais graves para anlise posterior. </p><p> Decomposio dos riscos Analisar a raiz da causa da provvel falha. </p></li><li><p>12.3 Especificao de confiabilidade </p><p> Processo de especificao de confiabilidade </p><p> Reduo dos riscos </p><p> Deve-se estabelecer as probabilidades aceitveis dos diferentes tipos de falhas, levando em conta os custos de cada falha. </p></li><li><p>12.3.1 Indicadores de confiana </p><p> Probabilidade de falha na demanda (POFOD) Probabilidade de ocorrer uma falha durante um ciclo do </p><p>sistema. Ex.: POFOD = 0.001 significa que existe 1 chance em 1000 de ocorrer </p><p>uma determinada falha durante uma execuo do sistema. </p><p> Taxa de ocorrncia de falhas (ROCOF) Nmero provvel de falhas no sistema relativo a um </p><p>determinado perodo de tempo ou um determinado numero de execues do sistema. Ex.: ROCOF= 1/1000 significa que em 1000 execues do sistema, </p><p>apenas uma falha ocorrer. </p></li><li><p>12.3.1 Indicadores de confiana </p><p> Disponibilidade (AVAIL) </p><p> Probabilidade do sistema estar operando quando </p><p>requisitado um servio. Ex.: AVAIL= 0.9999 significa que o sistema estar disponivel, </p><p>em mdia, durante 99,99% do tempo de operao. </p><p> Tempo mdio entre falhas (MTTF) </p><p> Unidade de tempo mdia entre falhas no sistema. </p><p> Ex.: MTTF = 30min significa que a cada meia hora ocorrer uma falha. </p></li><li><p>12.3.1 Indicadores de confiana </p><p> Para avaliar a confiana do sistema necessrio obter dados da sua operao. </p><p> Ex.: O nmero de falhas dos sistema dado um nmero de pedidos </p><p>de servio ao sistema. Utilizado para medir a probabilidade de falha na demanda (POFOD). </p><p> O tempo ou o nmero de transaes entre falhas no sistema. Utilizado para medir a taxa de ocorrncia de falhas (ROCOF) e o tempo </p><p>mdio entre falhas (MTTF). </p><p> 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). </p></li><li><p>12.3.2 Requisitos de confiabilidade no funcionais </p><p> Envolve especificaes quantitativas dos requisitos de confiabilidade e disponibilidade do sistema. </p><p> Vantagens: Decidir o nvel de confiabilidade do sistema, mostrando o </p><p>que realmente necessrio. </p><p> Fornece uma base para avaliar quando os testes no sistema podem ser interrompidos (assim que o nvel de confiabilidade de cada requisito for atingido). </p><p> uma forma de avaliar qual estratgia de design melhora a confiabilidade do sistema. </p><p> Certificao do sistema. </p></li><li><p>12.3.2 Requisitos de confiabilidade no funcionais </p><p> Dificuldade: Traduzir experincias prticas em especificaes </p><p>quantitativas. </p><p> Custos em testes. </p><p> Ex.: 1. POFOD = 0.0001. Ento necessrio cerca de 50 mil </p><p>testes para verificar se o POFOD de determinada falha realmente 0.0001. </p><p>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. </p></li><li><p>12.3.2 Requisitos de confiabilidade no funcionais </p><p> Passos para evitar especificaes mal estimadas </p><p> Especificar os requisitos para diferentes tipos de falhas. </p><p> Especificar separadamente os requisitos para servios diferentes. </p><p> 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 </p><p>falhas durante certas operaes quando estas poderiam ser apenas canceladas. </p></li><li><p>12.3.3 Requisitos de confiabilidade funcionais </p><p> Envolve identificar os requisitos que definem restries e caractersticas que contribuem para a confiabilidade do sistema. </p><p> 3 Tipos: 1. Requisitos de checagem </p><p> Restries nas portas de entrada do sistema para evitar valores incorretos ou fora da zona de valores permitidos. </p><p>2. Requisitos de recuperao Devem ajudar na recuperao do sistema aps uma falha. </p><p>Ex.: Ponto de restaurao do windows. </p><p>3. Requisitos de redundncia Implicam em redundncias no sistema para que uma falha </p><p>isolada no gere uma perda total do servio. </p></li><li><p>12.3.3 Requisitos de confiabilidade funcionais </p><p> Exemplos: </p><p> RR1: Um intervalo de valores deve ser definido para todos </p><p>os operadores de entrada. (Requisito de checagem) </p><p> 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) </p></li><li><p>12.4 Especificaes de proteo </p><p> Semelhanas com especificaes de segurana impraticvel de especificar quantitativamente. </p><p> Deve-se usar no deve na elaborao dos requisitos. </p><p> Diferenas: Ataques ao sistema so planejados e o invasor pode </p><p>conhecer os pontos fracos do sistema. </p><p> Encontrar a raiz do ataque pode ser difcil, uma vez que esta pode ter sido ocultada. </p><p> Desligar o sistema, na maioria das vezes, significa que o ataque foi bem sucedido. </p><p> O invasor pode realizar ataques diferentes, aprimorando-se a medida que comea a conhecer mais o sistema. </p></li><li><p>12.4 Especificaes de proteo </p><p> 10 tipos de requisitos de proteo (Firesmith - 2003) 1. Requisitos de identificao </p><p> Especifica quando um sistema deve identificar o usurio que ir interagir com ele. </p><p>2. Requisitos de autenticao Especifica como um usurio deve ser identificado. </p><p>3. Requisitos de autorizao Especifica os privilgios e permisses de acesso de um </p><p>usurio identificado. </p></li><li><p>12.4 Especificaes de proteo </p><p>4. Requisitos de imunidade Especifica como um sistema deve se proteger contra vrus, </p><p>worms e ameaas similares. </p><p> 5. Requisitos de integridade </p><p> Especifica como a corrupo dos dados pode ser evitada. </p><p> 6. Requisitos de deteco de intrusos </p><p> Especifica quais mecanismos devem ser usados para detectar ataques ao sistema. </p><p> 7. Requisitos de no repudiao </p><p> Especifica que uma parte em transao no pode negar seu envolvimento nesta. </p></li><li><p>12.4 Especificaes de proteo </p><p>8. Requisitos de privacidade Especifica como a privacidade dos dados ser mantida. </p><p>9. Requisitos de auditoria de proteo Especifica como o uso do sistema pode ser auditado e </p><p>verificado. </p><p>10. Requisitos de manuteno da proteo do sistema Especifica como um aplicativo pode prevenir que </p><p>alteraes autorizadas acidentalmente passem pelos mecanismos de proteo. </p></li><li><p>12.4 Especificaes de proteo </p><p> Estgios do processo: </p><p> Processo de avaliao e analise de riscos so variaes do processo de especificaes genricas da abordagem baseada em riscos. </p></li><li><p>12.4 Especificaes de proteo </p><p> Estgios do processo: 1. Identificao (Identificao de riscos) </p><p> Onde os ativos do sistema que requerem proteo so identificados. </p><p>2. Avaliao do valor de um ativo (Anlise dos riscos) Estimar o valor de um ativo identificado. </p><p>3. Avaliao da exposio (Anlise dos riscos) Avaliar a perda em potencial associada a cada ativo. </p><p>4. Identificao de ameaas (Anlise dos riscos) Identificar as ameaas que podem ocorrer nos ativos do </p><p>sistema. </p></li><li><p>12.4 Especificaes de proteo </p><p>5. Avaliao de ataques (Decomposio dos riscos) Decompor cada ameaa em ataques que o sistema pode sofrer e </p><p>as possveis maneiras que este ataque pode ocorrer. </p><p>6. Controle de identificao (Reduo dos riscos) Propor os controles que podem ser instalados para proteger os </p><p>ativos. </p><p> 7. Avaliao de viabilidade (Reduo dos riscos) </p><p> Avaliar a viabilidade tcnica e os custos dos controles propostos. </p><p> 8. Definio dos requisitos de proteo (Reduo dos </p><p>riscos) Formular os requisitos de proteo do sistema utilizando os </p><p>conhecimentos da exposio do sistema, das ameaas e da avaliao dos controles. </p></li><li><p>12.4 Especificaes de proteo </p><p> Exemplo: Sistema de informao (Hospital para sade mental) Requisitos de proteo </p><p>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. </p><p>2. Todas as informaes referentes aos pacientes devem ser criptografadas. </p><p>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. </p><p>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. </p></li><li><p>12.5 Especificao formal </p><p> Abordagem baseada em formalismo matemtico onde definido um modelo formal para o software. </p><p> 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 </p></li><li><p>12.5 Especificao formal </p><p> Modelo formal </p><p> Traduo dos requisitos de sistema do usurio (escrito em linguagem natural, diagramas e tabelas) em linguagem matemtica com semntica formal definida. </p><p> No ambgua </p><p> Permite verificao do comportamento do modelo (manualmente ou com ferramentas automatizadas) </p></li><li><p>12.5 Especificao formal - Vantagens </p><p> Conforme a especificao formal criada, os requisitos do sistema ficam cada vez mais compreendidos. Causa deteco antecipada de erros </p><p> Como a especificao descrita em linguagem formal, possvel automatizar a deteco de inconsistncias. </p><p> Pode reduzir custos de testes do programa por ter sido verificado atravs da especificao formal e no do uso do programa em si. </p></li><li><p>12.5 Especificao formal - Desvantagens </p><p> 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. </p><p> Muito difcil de prever o ganho financeiro em adotar estar abordagem. </p><p> Resistncia por parte dos engenheiros que no sabem utilizar os mtodos formais </p><p> No se aplica muito a problemas de grande escala </p><p> No compatvel com mtodos geis de desenvolvimento </p></li><li><p>12.5 Especificao formal - Desvantagens </p><p> http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/ExtraChaps/FormalSpec.pdf </p>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</li></ul>

Recommended

View more >