Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios

1. Pontifícia Universidade Católica de Minas Gerais (PUC/MG) Instituto de Informática Programa de Graduação em Sistemas de Informação Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios Marcelo de Alencar Veloso Belo Horizonte 2009 2. 2 Marcelo de Alencar Veloso Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios Trabalho de Diplomação apresentado ao Programa de Graduação em Sistemas de Informação da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação. Orientador: Marcelo Werneck Barbosa Belo Horizonte 2009 3. 3 Marcelo de Alencar Veloso Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios Trabalho de Diplomação apresentado ao Programa de Graduação em Sistemas de Informação da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação. _________________________________________________ Marcelo Werneck Barbosa (Orientador) _________________________________________________ _________________________________________________ Belo Horizonte 2009 4. 4 Ao meu filho Nikolai Alexander 5. 5 “A garantia de nos tornarmos invencíveis está em nossas próprias mãos.” Sun Tzu 6. 6 RESUMO Sendo esta a “Era da Informação”, é natural que ela esteja presente em todos os aspectos relativos às atividades de uma empresa. A dependência hoje das informações e seu valor para o desenvolvimento dos processos de negócios, torna-a o bem mais valioso dentro de uma organização. Sendo assim, é fundamental que esta informação esteja sempre disponível aos seus legítimos usuários, quando estes necessitem, com a garantia do sigilo e sem alterações não autorizadas. Para garantir essas premissas, as empresas devem desenvolver estratégias que assegurem a utilização de suas informações, evitando a paralisação de suas atividades por interrupções de qualquer natureza, salvo as que tenham sido planejadas. Um Plano de Continuidade de Negócios tem exatamente este objetivo, o de garantir a continuidade de processos e informações vitais à sobrevivência da empresa, no menor espaço de tempo possível e com o mínimo de impacto. Para garantir o sucesso de um Plano de Continuidade de Negócios, é fundamental que ele seja desenvolvido dentro de uma boa metodologia, que possa ser adaptada às particularidades específicas de cada organização. Desta forma, o presente trabalho tem como objetivo consolidar os conceitos similares presentes em várias metodologias amplamente utilizadas, e propor um processo para a elaboração da Avaliação e Análise de Riscos, que foi considerada a etapa mais importante das necessárias para a implantação de um Plano de Continuidade de Negócios. Palavras-chave: Plano de Continuidade de Negócios. Plano de Contingência. Plano de Recuperação de Desastres. Avaliação e Análise de Riscos. 7. 7 ABSTRACT Being this the "Age of Information", it is natural that it is present in all of the relative aspects of the activities of a company. The dependence today of the information and its value for the development of the processes of businesses turns it the most valuable asset inside of an organization. So, it is fundamental that this information be always available to their legitimate users, when these need, with the warranty of the secrecy and without unauthorized alterations. To guarantee those premises, the companies should develop strategies to assure the use of their information, avoiding the discontinuity of their activities caused by interruptions of any nature, except for the ones that have been planned. A Business Continuity Plan has exactly this purpose – guarantee the continuity of processes and vital information to the company survival in the shortest time and with minimum impact. To guarantee the success of a Business Continuity Plan it is fundamental that it is developed according to a good methodology that can be adapted to the specific particularities of each organization. This way, the present work, by consolidating similar concepts in several methodologies used, proposes a process for the elaboration of the Risk Analysis and Evaluation – considered the most important phase of the implantation of a Business Continuity Plan. Word-key: Business Continuity Plan. Contingency Plan. Disaster Recovery Plan. Risk Analysis and Evaluation. 8. 8 LISTA DE FIGURAS Figura 1: Diagrama da Equação do Risco de Segurança da Informação..................24 Figura 2: Desenvolvimento do Plano de Continuidade de Negócios.........................27 Figura 3: Modelo PDCA para Planos de Continuidade de Negócios.........................29 Figura 4: Diagrama do Processo de Avaliação e Análise de Riscos. ........................32 Figura 5: A Linha do Tempo de Incidentes................................................................57 LISTA DE QUADROS Quadro 1: Exemplos de ameaças humanas: Ameaça, motivação e ações da ameaça ..................................................................................................................................39 Quadro 2: Pares de Vulnerabilidades/Ameaças........................................................41 Quadro 3: Critérios de segurança .............................................................................46 Quadro 4: Definições de probabilidade .....................................................................48 Quadro 5: Definições de Magnitude de Impacto .......................................................50 Quadro 6: Matriz de nível de risco.............................................................................52 Quadro 7: Escala de risco e ações necessárias........................................................53 Quadro 8: O uso das partes constituintes do PCN durante cada fase de um incidente ..................................................................................................................................59 Quadro 9: Níveis de treinamento de Administração de Continuidade de Negócios ..63 9. 9 LISTA DE SIGLAS BIA – Business Impact Analysis BS – British Standard CD – Compact Disc CRM – Customer Relationship Management DDoS – Distributed Denial of Service DRI – Disaster Recovery Institute ENISA – European Network and information Security Agency ERP – Enterprise Resource Planning FTP – File Transfer Protocol GCN – Gestão de Continuidade de Negócios GCSTI – Gestão de Continuidade de Serviços de Tecnologia da Informação GR – Gestão de Riscos IEC – International Electrotechnical Commission ISO – International Organization for Standardization NBR – Denominação de norma da ABNT NIST – National Institute of Science and Technology PCN – Plano de Continuidade de Negócios PDCA – Plan, Do, Check, Act RAID – Redundant Array of Independent Disks RH – Recursos Humanos RPO – Recovery Point Objective RTO – Recovery Time Objective SLA – Service Level Agreement TI – Tecnologia da Informação 10. 10 SUMÁRIO 1 INTRODUÇÃO .......................................................................................................13 1.1 Objetivo............................................................................................................14 1.1.1 Geral .........................................................................................................14 1.1.2 Específicos................................................................................................15 1.2 Definição do Problema.....................................................................................15 1.3 Contribuições...................................................................................................16 1.4 Metodologia .....................................................................................................16 1.5 Organização do Trabalho ................................................................................17 2 REFERENCIAL TEÓRICO.....................................................................................18 2.1 Segurança da Informação................................................................................18 2.1.1 Princípios básicos .....................................................................................19 2.1.2 Ativos ........................................................................................................19 2.1.3 Ameaças ...................................................................................................20 2.1.4 Vulnerabilidades........................................................................................21 2.1.5 Impactos....................................................................................................23 2.2 Riscos..............................................................................................................23 3 PROCESSO TÍPICO DE ELABORAÇÃO DE PLANOS DE CONTINUIDADE DE NEGÓCIOS...............................................................................................................25 3.1 Inicialização do Projeto de PCN ......................................................................29 3.1.1 Identificando a Organização......................................................................30 3.1.2 Definindo responsabilidades do PCN........................................................30 3.2 Avaliação e Análise de Riscos – Processo Proposto.......................................31 3.2.1 Passo 1: Caracterização de Ativos............................................................33 3.2.1.1 Informações relacionadas aos ativos..................................................33 3.2.1.2 Técnicas de Coleta de Informação .....................................................35 3.2.2 Passo 2: Identificação de Ameaças ..........................................................37 3.2.2.1 Identificação de ameaça.....................................................................37 3.2.2.2 Motivação e Ações de Ameaças.........................................................38 3.2.3 Passo 3: Identificação de Vulnerabilidades...............................................41 11. 11 3.2.3.1 Fontes de vulnerabilidades.................................................................42 3.2.3.2 Testes de Segurança de ativos ..........................................................43 3.2.3.3 Desenvolvimento da Lista de Verificação de Exigências de Segurança .......................................................................................................................44 3.2.4 Passo 4: Determinação de Probabilidades ...............................................48 3.2.5 Passo 5: Análise de Impacto.....................................................................49 3.2.6 Passo 6: Determinação do Risco ..............................................................51 3.2.6.1 Matriz de risco de nível.......................................................................51 3.2.6.2 Descrição de Nível de Risco...............................................................52 3.3 Definição das Estratégias de Recuperação.....................................................54 3.4 Desenvolvimento do PCN................................................................................56 3.4.1 Conjunto de documentos ..........................................................................57 3.5 Teste do Plano de Continuidade de Negócios.................................................60 3.5.1 Determinando o tipo de teste ....................................................................60 3.5.2 Escrevendo o plano de teste.....................................................................61 3.5.3 Conduzindo o teste ...................................................................................61 3.5.4 Comunicando o resultado do teste............................................................61 3.6 Manutenção do Programa de Gestão de Continuidade de Negócios ..............62 3.6.1 Treinamento de equipes............................................................................62 3.6.2 Manutenção e revisão do Plano de Continuidade de Negócios ................64 3.6.2.1 Gerenciamento de mudanças.............................................................66 3.6.2.2 Melhoramento contínuo ......................................................................67 3.6.3 Desenvolvendo a divulgação ....................................................................67 4 ESTUDO DE CASO ...............................................................................................68 4.1 A Empresa.......................................................................................................68 4.2 Estrutura Tecnológica......................................................................................69 4.3 Aplicação do Processo Proposto .....................................................................69 5 CONCLUSÃO ........................................................................................................72 5.1 Trabalhos Futuros............................................................................................72 6 REFERÊNCIAS BIBLIOGRÁFICAS......................................................................73 12. 12 APÊNDICE A – Ficha de Atividades do Passo 1...................................................76 APÊNDICE B – Ficha de Atividades do Passo 2...................................................80 APÊNDICE C – Ficha de Atividades do Passo 3...................................................83 APÊNDICE D – Ficha de Atividades do Passo 4...................................................87 APÊNDICE E – Ficha de Atividades do Passo 5...................................................90 APÊNDICE F – Ficha de Atividades do Passo 6 ...................................................93 APÊNDICE G – Relatório de Avaliação de Ativo...................................................95 APÊNDICE H – Cronograma de Atividades...........................................................99 APÊNDICE I – Questionário de Informações de Ativos .....................................100 APÊNDICE J – Declaração de Ameaças..............................................................103 APÊNDICE K – Lista de Vulnerabilidades ...........................................................105 APÊNDICE L – Lista de Verificação de Exigências de Segurança....................106 APÊNDICE M – Avaliação de Probabilidades .....................................................109 APÊNDICE N – Relatório de Avaliação de Impacto............................................110 APÊNDICE O – Questionário de Avaliação de Impacto .....................................111 APÊNDICE P – Relatório de Análise de Risco ....................................................115 APÊNDICE Q – Relatórios Produzidos no Estudo de Caso...............................116 13. 13 1 INTRODUÇÃO No contexto atual, os ambientes computacionais são muito complexos e difíceis de gerenciar. As informações pertinentes aos negócios da organização encontram-se segregadas, e com a crescente utilização dos computadores e as informações que neles residem, surge uma nova preocupação: assegurar a continuidade dos processos de negócios. As interrupções não planejadas de um processo de negócio de uma organização podem levar a conseqüências indesejadas e até mesmo drásticas, desde perdas financeiras por funcionários/produção parados ou a falência da companhia. Dados do instituto Disaster Recovery Institute (DRI) mostram que duas em cada cinco empresas que sofrem interrupção em suas operações por uma semana fecham as portas em menos de três anos. Levantamento realizado pela KPMG com empresas indianas revelou que 79% não tinham um Plano de Continuidade de Negócios documentado e testado. 66% não tinham qualquer espécie de instrumento para assegurar continuidade de negócios em caso de um desastre maior. Estes resultados mostram a importância para as organizações desenvolverem e manterem um bom Plano de Continuidade de Negócios (PCN), o que em muitos casos, pode significar sua sobrevivência após a ocorrência de um desastre. Um PCN tem como objetivo garantir a continuidade de processos e informações vitais à sobrevivência da empresa, no menor espaço de tempo possível e com o mínimo de impacto causado pelo desastre, através de políticas, planos e procedimentos. Ele contempla diversos e importantes aspectos que devem ser observados durante sua elaboração, através da obtenção e análise de informações que geram uma estratégia integrada para reagir a uma interrupção não programada de atividades de negócio, sendo que, no momento de um desastre, nem todos os processos têm necessária sua continuidade. Assim, deve-se planejar manter níveis aceitáveis de disponibilidade dos principais processos de negócio. Deverá resultar num conjunto de documentos onde estarão registradas as ações relativas às adequações da infra-estrutura e alterações dos procedimentos do dia-a-dia da organização. 14. 14 Um PCN é desenvolvido em etapas que passam pelo Planejamento e Escopo do Plano, Análise de Impactos nos Negócios, Desenvolvimento do Plano, Aprovação e Implementação, sendo cada fase composta por diversos processos onde ocorre o levantamento de informações e posterior análise. Após sua definição, deverá ainda passar por Testes e Manutenções periódicas, garantindo os objetivos traçados quando da sua definição. Destaca-se dentre os aspectos a serem observados durante sua elaboração a Avaliação e Análise de Riscos e o Plano de Contingência, formado pelos planos de Administração de Crise, Continuidade Operacional e Recuperação de Desastres. Durante o processo de Análise e Avaliação de Risco é que serão feitos todos os levantamentos em relação às ameaças, vulnerabilidades, probabilidades e impacto aos quais os ativos estão sujeitos. Torna-se assim, o processo mais trabalhoso e de maior duração, sendo, portanto o mais crítico. Todas as informações identificadas nesta fase irão embasar decisões estratégicas e táticas relacionadas à garantia de Continuidade de Negócios da organização. Como cada organização apresenta particularidades específicas, exigem que determinados itens do PCN tenham produtos mais detalhados, enquanto outros terão uma abordagem mais genérica, sendo todos, no entanto abrangidos durante sua elaboração. 1.1 Objetivo O objetivo geral e os objetivos específicos, que esclarecerão as intenções deste trabalho, são apresentados a seguir. 1.1.1 Geral Propor um processo sistematizado para a execução de Avaliação e Análise de Riscos em uma organização visando o desenvolvimento de um Plano de Continuidade de Negócios, a partir da constatação de que as Normas e Padrões de 15. 15 Segurança da Informação, reconhecidos internacionalmente e que tratam do assunto, indicam apenas “o que fazer” e não “como fazer”. Assim, baseado nestas Normas e Padrões, este trabalho busca detalhar uma das etapas sugeridas para a Gestão de Continuidade de Negócios. 1.1.2 Específicos Para se atingir o objetivo geral, foram definidos os seguintes objetivos específicos:  O estabelecimento de passos mínimos a serem executados para a execução de uma Avaliação e Análise de Riscos;  O detalhamento das atividades a serem executadas em cada um dos passos definidos anteriormente;  A aplicação do processo proposto em um estudo de caso. 1.2 Definição do Problema O problema consiste na inexistência de um detalhamento para a execução de uma Avaliação e Análise de Riscos para a elaboração de um Plano de Continuidade de Negócios, de acordo com as normas e padrões existentes. A Associação Brasileira de Normas Técnicas, em sua NBR ISO/IEC 17799, em sua seção 11.1.2 diz: “A continuidade do negócio deve começar pela identificação de eventos que possam causar interrupções nos processos do negócio, tais como falhas em equipamento, incêndios e inundações. Isto deve ser seguido por uma avaliação de riscos para determinar o impacto daquelas interrupções (tanto em termos de escala de danos quanto de período para recuperação). Ambas estas atividades devem ser executadas com o total envolvimento dos proprietários dos recursos e 16. 16 processos do negócio. Esta avaliação considera todos os processos do negócio e não é limitada às facilidades de processamento de informações. Dependendo dos resultados da avaliação de riscos, um plano estratégico deve ser desenvolvido para determinar o enfoque global para a continuidade do negócio. Uma vez que este plano tenha sido criado, ele deve ser endossado pela gerência.” Este exemplo ilustra a necessidade do detalhamento das atividades a serem executadas para identificar riscos, as conseqüências que eles podem trazer, e limitar os danos que possam vir a causar. 1.3 Contribuições As principais contribuições deste trabalho são:  Apresentar os principais conceitos relativos ao tema Gestão de Continuidade de Negócios;  Justificar a importância da Avaliação e Análise de Riscos para elaboração de Planos de Continuidade de Negócios;  Fornecer um processo detalhado de Avaliação e Análise de Risco, juntamente com modelos formulários para documentar a execução do processo. 1.4 Metodologia Para o desenvolvimento deste trabalho foram desenvolvidas as etapas abaixo descritas:  Pesquisa bibliográfica, incluindo normas, como ABNT NBR ISO/IEC 17799, ABNT NBR ISO/IEC 27001, além de padrões e guias estabelecidos no mercado, dentre eles ITIL v2, COBIT v4, NIST SP 800- 30, BCI Good Practice Guidelines, dentre outros; 17. 17  Definição de um processo de avaliação e análise de riscos, o qual faz parte de um processo maior, de Gestão de Continuidade de Negócios, e que foi elaborado baseado nas melhores práticas identificadas na bibliografia consultada;  Execução do processo de avaliação e análise de riscos em uma empresa fictícia, com o objetivo de confirmar a viabilidade do processo proposto, além de identificar a existência de possíveis falhas. 1.5 Organização do Trabalho O presente trabalho está dividido em seis capítulos, conforme segue:  O Capítulo 1 – Introdução define os objetivos do trabalho e a motivação de sua elaboração.  O Capítulo 2 – Referencial teórico apresenta os conceitos sobre Segurança da Informação e os princípios básicos que a norteiam; além da definição das principais terminologias associadas ao tema, visando facilitar o entendimento do leitor ao longo do trabalho.  O Capítulo 3 – Plano de Continuidade de Negócios apresenta sucintamente as etapas de um PCN, e propõe um processo detalhado de execução da etapa de Avaliação e Análise de Riscos.  O Capítulo 4 – Estudo de Caso apresenta a aplicação do processo em uma empresa e os resultados obtidos.  O Capítulo 5 – Conclusão apresenta as conclusões sobre o processo proposto e trabalhos futuros relacionados.  O Capítulo 6 – Referências bibliográficas relaciona toda referência bibliográfica consultada para elaboração dessa monografia. 18. 18 2 REFERENCIAL TEÓRICO 2.1 Segurança da Informação Segundo definição da Norma NBR ISO/IEC 17799:2001 para informação: "Informação é um ativo que, como qualquer outro ativo importante para os negócios, tem um valor para a organização e conseqüentemente necessita ser adequadamente protegido.” Sendo assim, a informação é cada vez um elemento chave para o desenvolvimento e sucesso de uma organização, independente de seu tamanho e área de atuação. De acordo com a definição do Dicionário Eletrônico Houaiss, segurança é: Segurança. S. f. 2 ação ou efeito de assegurar e garantir alguma coisa; garantia, fiança, caução. 3 estado, qualidade ou condição de uma pessoa ou coisa que está livre de perigos, de incertezas, assegurada de danos e riscos eventuais, afastada de todo mal. 6 conjunto de processos, de dispositivos, de medidas de precaução que asseguram o sucesso de um empreendimento, do funcionamento preciso de um objeto, do cumprimento de algum plano etc. Pode-se afirmar assim que Segurança da Informação são os processos e medidas empregadas para assegurar as informações de uma organização contra uma extensa variedade de ameaças, garantindo o sucesso e o funcionamento das atividades dessa organização, tendo como base para sua aplicação os princípios de confidencialidade, integridade e disponibilidade. 19. 19 2.1.1 Princípios básicos A segurança da informação tem como objetivo proteger os ativos de uma organização contra a concretização de ameaças que possam afetar a informação, seja corrompendo-a, eliminando-a, permitindo acessos indevidos ou sua indisponibilidade. A proteção contra essas ameaças baseia-se em três princípios básicos, que norteiam todas as atividades desenvolvidas. Segundo Sêmola (2003), estes princípios podem ser definidos como:  Confidencialidade – Toda informação deve ser protegida de acordo com o grau de sigilo de seu conteúdo, visando a limitação de seu acesso e uso apenas às pessoas para quem elas são destinadas.  Integridade – Toda informação deve ser mantida na mesma condição em que foi disponibilizada pelo seu proprietário, visando protege-las contra alterações indevidas, intencionais ou acidentais.  Disponibilidade – Toda informação gerada ou adquirida por um indivíduo ou instituição deve estar disponível aos seus usuários no momento em que os mesmos delas necessitem para qualquer finalidade. 2.1.2 Ativos Ativo é “todo elemento que manipula a informação, inclusive ela mesma, passando pelo seu emissor, o meio pelo qual ela é transmitida ou armazenada, até chegar a seu receptor.” (Sêmola, 2003, p.45). Os ativos são elementos a serem protegidos de forma adequada, devido ao valor que possuem para uma organização, para que suas operações não sejam prejudicadas pelos variados tipos de danos que estão sujeitos, causados por ameaças que explorem vulnerabilidades. 20. 20 Segundo a Microsoft (2006), são compostos por três elementos:  As informações, armazenadas em meio eletrônico ou físico;  Os equipamentos e sistemas que oferecem suporte a elas, incluindo hardware, software, e organização, formada pela estrutura física e organizacional da organização;  Os indivíduos que utilizam a estrutura tecnológica e de comunicação da empresa e que lidam com a informação. 2.1.3 Ameaças De acordo com a Microsoft (2006), as ameaças são a causa potencial de um incidente indesejado através da exploração de vulnerabilidades existentes, que caso se concretize pode resultar em perdas e danos aos ativos de uma organização, afetando os seus negócios. Os ativos estão constantemente sob ameaças que podem colocar em risco a integridade, a confidencialidade e a disponibilidade das informações. Essas ameaças sempre existirão e estão relacionadas a causas que representam riscos, as quais podem ser:  causas naturais ou não-naturais;  causas internas ou externas (Microsoft, 2006). As ameaças são constantes e podem ocorrer a qualquer momento. Essa relação de freqüência-tempo se baseia no conceito de risco, o qual representa a probabilidade de que uma ameaça se concretize por meio de uma vulnerabilidade ou ponto fraco. Segundo Oliveira (2006), as ameaças podem ser classificadas em três grupos: 21. 21 1. Humanas – estão diretamente relacionadas às ações de indivíduos, e podem sofrer uma nova segregação, sendo intencional as decorrentes de ações deliberadas como sabotagens, invasões, fraudes, entre outros, e não intencional as resultantes de erros e acidentes causados por funcionários. 2. Ambientais – compreendidas por hardware, software, dispositivos tecnológicos, “bugs”, falhas elétricas, etc. 3. Naturais – decorrentes de condições da natureza e a intempéries, tais como incêndio, furacão, inundação, terremotos. 2.1.4 Vulnerabilidades De acordo com Sêmola (2003, p.48), vulnerabilidade é a “fragilidade presente ou associada a ativos que manipulam e/ou processam informações que, as ser explorada por ameaças, permite a ocorrência de um incidente de segurança, afetando negativamente um ou mais princípios da segurança da informação: confidencialidade, integridade e disponibilidade.” A existência de uma vulnerabilidade não implica necessariamente na ocorrência de um incidente. Elas são os pontos que poderão ser utilizados pelas ameaças para causar danos aos ativos da organização. A sua identificação é de fundamental importância para que se possa dimensionar os riscos aos quais os ativos encontram-se expostos, definindo medidas que visem a sua correção para diminuir a possibilidade de exploração por parte das ameaças. Segundo a Microsoft (2006, p. 48-53), as vulnerabilidades podem ser divididas nas seguintes categorias: a) Vulnerabilidades físicas São aquelas presentes nos ambientes em que estão sendo armazenadas ou gerenciadas as informações, como falta de extintores, disposição desorganizada de cabos de energia e rede, etc. 22. 22 b) Vulnerabilidades naturais São aquelas relacionadas às condições da natureza que podem colocar em risco as informações, como locais próximos a rios propensos a inundações, incapacidade de resistência a manifestações da natureza como terremotos, furacões, tempestades, etc. c) Vulnerabilidades de hardware Os possíveis defeitos de fabricação ou configuração dos equipamentos da empresa que poderiam permitir o ataque ou a alteração dos mesmos, como falta de atualizações orientadas por fabricantes, conservação inadequada de equipamentos, etc. d) Vulnerabilidades de softwares Os pontos fracos dos aplicativos permitem que ocorram acessos indevidos aos sistemas de computador, inclusive sem o conhecimento de um usuário ou administrador de rede, como ausência de atualizações, configurações e instalações inadequadas, programação insegura, etc. e) Vulnerabilidades dos meios de armazenamento Os meios de armazenamento podem ser afetados por pontos fracos que podem danificá-los ou deixá-los indisponíveis, como uso incorreto, locais de armazenamento incorretos, prazo de validade vencido, etc. f) Vulnerabilidades de comunicação Esse tipo de vulnerabilidade abrange todo o tráfego de informações, como falta de criptografia, escolha de sistemas inapropriados para a natureza da informação, etc. g) Vulnerabilidades humanas Relacionam-se aos danos que as pessoas podem causar às informações e ao ambiente tecnológico que lhes oferece suporte, como falta de treinamento, senhas fracas, compartilhamento de credenciais de acesso, etc. 23. 23 2.1.5 Impactos Resultado da ação bem sucedida de uma ameaça ao explorar as vulnerabilidades de um ativo, atingindo assim um ou mais princípios da segurança da informação, causando danos a um ou mais processos do negócio da organização. 2.2 Riscos O risco pode ser encarado através de duas óticas antagônicas: como uma oportunidade ou como uma ameaça. De acordo com D’ANDREA citado por Oliveira (2006, p.23) “o risco como oportunidade está centrado no investimento e tem base em iniciativas estratégicas. Quanto maior for o risco, maior o potencial de retorno, e, paralelamente, maior pode ser o potencial de perda”. Esta visão define o risco como elemento decisivo nos resultados a serem obtidos, numa equação proporcionalmente equivalente dos ganhos a serem obtidos. Este trabalho trata do risco como ameaça, que como definido por Sêmola (2003, p. 55) “é a probabilidade de que agentes, que são as ameaças, explorem vulnerabilidades, expondo os ativos a perdas de confidencialidade, integridade e disponibilidade, causando impacto nos negócios.” A perda de um ou mais destes fatores de segurança leva “à ocorrência de efeitos negativos como perda financeira, fraude, roubo, comprometimento da imagem e reputação, infração legal, falhas tecnológicas, dentre outros.” Oliveira (2006, p.23). Na perspectiva de uma ameaça, o risco deve sempre ser tratado de maneira preventiva, buscando minimizar o impacto causado caso venha a se materializar. A gestão de riscos pode ser esboçada pela equação: 24. 24 Figura 1: Diagrama da Equação do Risco de Segurança da Informação Fonte: Sêmola, 2003 Sendo assim, o risco a qual um ativo estará exposto encontra-se na combinação dessas variáveis, sendo o objetivo principal da segurança da informação a redução dos riscos, através da eliminação das vulnerabilidades dos ativos, evitando que as ameaças as explorem e gerem impactos para as organizações. Como não existe segurança total, a organização, dentro de seus objetivos, deve manter o risco o mais próximo a zero possível. 25. 25 3 PROCESSO TÍPICO DE ELABORAÇÃO DE PLANOS DE CONTINUIDADE DE NEGÓCIOS Um Plano de Continuidade de Negócios deve “garantir a continuidade de processos e informações vitais à sobrevivência da empresa, no menor espaço de tempo possível, com o objetivo de minimizar os impactos do desastre.” (Sêmola, 2003, p.98). Enquanto a Gestão de Riscos (GR) é o processo no qual se busca minimizar, ou mesmo eliminar os riscos a que os ativos de uma organização possam estar expostos, a Gestão de Continuidade de Negócios (GCN), do qual o PCN faz parte, é um processo pró-ativo que busca assegurar que uma organização possa sobreviver a incidentes não planejados, decorrentes de riscos residuais que causem interrupções em seus processos de negócio. Ou seja, visa o planejamento e preparação para responder e contingenciar situações que se apresentarem e que todos os outros mecanismos de segurança não forem capazes de evitar. O presente trabalho apresenta uma adaptação do processo descrito pela European Network and information Security Agency (ENISA), como uma proposta para o desenvolvimento de um Plano de Continuidade de Negócios. Buscou-se sintetizar as etapas consideradas indispensáveis, e que se encontram presentes nos padrões, normas e diretrizes de melhores práticas existentes, dentre eles:  APS 232 – Australian Prudential Regulatory Authority – APS 232, 2005, Business Continuity Management;  BCI Good Practice Guidelines – The Business Continuity Institute. Good Practice Guidelines 2005 – A Framework for Business Continuity Management;  BS 25999-1 – British Standards Institute. BS 25999-1. Code of practice for business continuity management;  Cobit v4.1 – CobiT, Control Objectives for Information and related Technology, IT Governance Institute; 26. 26  FEMA 141 – Federal Emergency Management Agency (FEMA) – U.S. Department of Homeland Security Emergency Management Guide for Business & Industry;  HB 221 – Standards Australia/Standards New Zealand. HB 221-2004, Business Continuity Management;  HB 292 – Standards Australia/Standards New Zealand. HB 292-2006. Handbook. A Practitioners Guide to Business Continuity Management;  ISO 17799 – ISO/IEC 17799:2005 – Information technology – Security techniques – Code of practice for information security management;  ISO 27001 – ISO/IEC 27001:2005 – Information technology – Security techniques – Information security management systems – Requirements;  ITIL v2 – Information Technology Infrastructure Library. ITIL v2; OGC – UK Office of Government Commerce;  NFPA 1600 – National Fire Protection Association. NFPA 1600. Standard on Disaster/Emergency Management and Business Continuity Programs. 2007 Edition;  NIST SP 800-30 – National Institute of Science and Technology. NIST SP 800-34. Risk Management Guide for Information Technology Systems;  NIST SP 800-53 – National Institute of Science and Technology. NIST SP 800-53. Recommended Security Controls for Federal Information Systems and Organizations. O desenvolvimento do Plano de Continuidade de Negócios foi dividido em seis etapas, mostradas na Figura 2. A segunda etapa, que compreende a Avaliação e Análise de Riscos, sendo esta o foco principal deste trabalho, foi detalhada em um processo sistematizado para sua execução, através de passos propostos com o objetivo de garantir uma análise precisa dos riscos a que possam estar expostos os ativos avaliados. Quando um PCN é elaborado pela primeira vez em uma organização, ele é desenvolvido como um projeto, ou seja, uma atividade com início e fim. Porém, como exposto no diagrama, uma vez concluído ele assume o papel de um processo 27. 27 contínuo, que deverá sofrer constante revisão e manutenção, com o objetivo de ser melhorado continuamente e refletir todas as mudanças que venham a ocorrer na organização. Figura 2: Desenvolvimento do Plano de Continuidade de Negócios 28. 28 Assim ele pode ser executado utilizando-se uma abordagem para o modelo PDCA (Plan – planejar, Do – implementar, Check – analisar, Act – monitorar) utilizado nos modelos de gestão de qualidade, e adotado na ISO/IEC 27001:2005, como referência para melhoria dos processos a serem implementados numa organização implantando um Sistema de Gerenciamento de Segurança da Informação. As etapas do PCN estariam assim relacionadas com as fases do modelo PDCA:  Plan (planejar): Abrange as etapas de avaliação e Análise de Riscos e Definição das Estratégias de Recuperação, que envolvem as atividades de levantamento de informações, elaboração de relatórios de inventários, a escolha e o planejamento dos controles a serem adotados.  Do (implementar): Estabelece a etapa onde são desenvolvidos os Planos de Continuidade definidos anteriormente, com a implantação das estratégias, normas, procedimentos e instruções que formam os planos.  Check (analisar): Envolve a etapa de validação dos planos implementados, através de testes que comprovem sua eficiência na garantia de continuidade dos processos de negócios de uma organização.  Act (monitorar): Compreende a etapa de manutenção dos planos, através do acompanhamento de mudanças que exijam a atualização dos mesmos, e de treinamentos periódicos de todos os envolvidos em sua execução. A Figura 3 ilustra o relacionamento entre as fases do modelo PDCA e as etapas do PCN. 29. 29 Figura 3: Modelo PDCA para Planos de Continuidade de Negócios A seguir, é feita a definição de cada uma das etapas de um processo típico para elaboração de Planos de Continuidade de Negócios, com destaque para a Avaliação e Análise de Riscos, cujo detalhamento é o objetivo deste trabalho. 3.1 Inicialização do Projeto de PCN Ao implementar um programa de PCN pela primeira vez em uma organização, é recomendada a adoção de disciplinas de administração de projetos, para que se possam definir de forma clara quais serão os responsáveis, as entregas, os prazos e os orçamentos a serem desenvolvidos pelo programa. O início do programa deve incluir:  Metas e objetivos de atividades estratégicas e operacionais de Gestão de Continuidade de Negócios (GCN);  Definição de equipes e integrantes;  Identificação de entregas e resultados;  Cronograma e prazos finais; 30. 30  Limitações;  Orçamento;  Capacidade de Recursos. É recomendado que a organização emita e divulgue, através da alta administração, uma Declaração de Missão do Plano, para demonstrar seu compromisso com a continuidade dos negócios em situações emergenciais. Esta declaração deverá conter principalmente a definição do propósito do plano e a indicação que envolverá a organização inteira. 3.1.1 Identificando a Organização É necessário identificar as áreas empresariais fundamentais que precisam ser interrogadas sobre o uso delas de tecnologia e informação como também sobre o impacto provável de sua perda. O pessoal mais indicado para contribuir à Business Impact Analysis (BIA) são os gerentes ou líderes das unidades empresariais desde que eles não só entendam do negócio da sua área operacional no dia-a-dia, mas que também tenham a autoridade para definir os objetivos exigidos de recuperação. Uma compreensão clara das responsabilidades fundamentais e posicionamento dentro da organização é também exigida para designar as equipes que serão responsáveis pelo projeto de Continuidade de Negócios em todas as diferentes fases. Uma vez que as áreas empresariais foram identificadas é necessário identificar os processos de negócio dentro dessas áreas. 3.1.2 Definindo responsabilidades do PCN O grupo de administração sênior deve designar ou nomear uma pessoa com apropriada experiência e autoridade para ser responsável pela política de 31. 31 implementação do PCN e designar um ou mais indivíduos para entregar e manter o programa. Além disto, serão designados times específicos para lidar com incidentes. A estrutura e tamanho das equipes irão depender das necessidades da organização. Em organizações menores, muitos papéis e responsabilidades (estratégicos assim como operacionais) podem ser agrupados e cobertos por equipes menores. 3.2 Avaliação e Análise de Riscos – Processo Proposto Esta etapa do desenvolvimento do Plano de Continuidade de Negócios é o foco principal deste trabalho, que propõe um processo sistemático para sua execução, através da definição de passos a serem executados até a sua conclusão, resultando numa análise precisa dos riscos a que estarão expostos os ativos avaliados. Foi considerada como a etapa mais importante dentre as necessárias para a criação de um Plano de Continuidade de Negócios. Tal consideração se deve ao fato de que é através da Avaliação e Análise de Riscos que serão feitas as priorizações das ações a serem tomadas, em função do risco identificado e classificado para cada um dos ativos avaliados. A Figura 4 mostra o diagrama com o fluxo dos passos a serem executados, além das entradas e saídas de cada um. Na saída, os itens descritos em vermelho, são aqueles considerados obrigatórios, e na entrada, os que serão utilizados para a continuidade do processo e produzidos nos passos anteriores, seguindo um processo contínuo. A seguir, é feita uma descrição para cada um dos passos, abordando seus objetivos e detalhes de sua execução. Nos apêndices, são apresentadas Fichas de Atividades detalhadas, com um roteiro orientando quais atividades deverão ser executadas, as pessoas envolvidas e os documentos requeridos e produzidos ao término de cada passo, incluindo também modelos de documentos a serem produzidos ao longo do processo. 32. 32 Vale ressaltar que devido à natureza única de uma organização, tal roteiro poderá ser adaptado, adequando-se às necessidades e particularidades que venham se apresentar. Figura 4: Diagrama do Processo de Avaliação e Análise de Riscos. Entradas/Saídas em vermelho denotam documentos obrigatórios. 33. 33 3.2.1 Passo 1: Caracterização de Ativos Na avaliação de riscos para um ativo de Tecnologia da Informação (TI), o primeiro passo é definir o escopo do projeto. Neste passo, os limites dos ativos de TI são identificados, juntamente com os recursos e as informações que constituam o ativo. A caracterização de um ativo de TI estabelece a extensão da avaliação de risco, e provê informações (por exemplo, hardware, software, conectividade de sistemas, equipe responsável) essenciais para definir o risco. A metodologia descrita neste documento pode ser aplicada a avaliações de um único ativo ou múltiplos ativos relacionados. No último caso, é importante que o domínio de interesse e todas as interfaces e dependências sejam definidas bem antes de aplicar a metodologia. 3.2.1.1 Informações relacionadas aos ativos A identificação de riscos para um ativo de TI requer uma compreensão aguda do ambiente de processo do ativo. A pessoa ou pessoas que administram a avaliação de riscos têm que primeiro juntar as informações relacionadas aos ativos, normalmente classificadas como:  Hardware  Software  Interfaces de sistema (por exemplo, conectividade interna e externa)  Dados e informações  Pessoas que suportam e usam o ativo  Missão do ativo (por exemplo, os processos executados pelo ativo)  Criticidade dos dados e sistemas (por exemplo, o valor do ativo ou importância para a organização)  Sensibilidade dos dados e sistemas (o nível de proteção requerido para manter a confidencialidade, integridade e disponibilidade) 34. 34 Informações adicionais relacionadas ao ambiental operacional de TI e seus dados inclui, mas não se limitam as seguintes:  As exigências funcionais do ativo  Usuários do ativo (por exemplo, usuários de sistemas que provêem apoio técnico para o sistema; usuários de aplicação que usam o sistema para executar funções empresariais)  Políticas de segurança (políticas organizacionais, federal, exigências, leis, práticas da indústria)  Arquitetura de segurança  Topologia da rede (por exemplo, diagrama de rede)  Informação de armazenamento que garanta a disponibilidade, integridade, e confidencialidade de dados  Fluxo de informação pertencente a sistemas de TI (por exemplo, interfaces de sistema, fluxograma de entrada e saída)  Controles técnicos usados por sistemas de TI (por exemplo, produtos de segurança embutidos ou adicionados que suportam identificação e autenticação, acesso discricionário ou obrigatório, controle, auditoria, proteção de informação residual, métodos de encriptação)  Controles de administração usados por sistema de TI (por exemplo, regras de comportamento, planejamento de segurança)  Controles Operacionais usados por sistemas de TI (por exemplo, segurança de pessoal, backup, operações de contingência, recuperação e continuidade; manutenção de sistema; armazenamento off-site; procedimentos de criação e exclusão de contas de usuário; controles para segregação de funções de usuários, como acesso de usuário privilegiado contra acesso de usuário padrão)  Ambiente de segurança físico dos ativos (por exemplo, segurança de acesso, políticas de data center)  Segurança ambiental implementada para o ambiente de processamento do ativo (por exemplo, controles para umidade, água, energia, poluição, temperatura, e substâncias químicas). 35. 35 3.2.1.2 Técnicas de Coleta de Informação Quaisquer das técnicas seguintes, ou uma combinação delas, podem ser usadas para colher informações pertinentes para o ativo dentro de seu limite operacional:  Questionário: Para coletar informações pertinentes, a equipe de avaliação de riscos pode desenvolver um questionário relativo à administração e controles operacionais, planejados ou usados para o ativo. Este questionário deve ser distribuído à equipe técnica e pessoal de administração não-técnica que está projetando ou apoiando o ativo. O questionário também pode ser usado durante visitas de in loco e entrevistas.  Entrevistas in loco: Entrevistas com equipes de apoio ao ativo e de administração podem permitir à equipe de avaliação de risco coletar informações úteis sobre o ativo (por exemplo, como o ativo é operado e é administrado). Visitas in loco também permitem à equipe de avaliação de risco observar e colher informação sobre a segurança física, ambiental, e operacional do ativo. Para ativos ainda na fase de implementação, as visitas in loco colheriam dados que poderiam prover a oportunidade para avaliar o ambiente físico no qual o ativo operará.  Revisão de Documentação: Documentos de Política (por exemplo, documentação legislativa, diretivas), documentação de sistemas (por exemplo, guia do usuário de sistema, manual administrativo de sistema, documentos de desígnio e requisitos de sistema, documentos de aquisição), e documentação relacionada à segurança (por exemplo, relatório prévio de auditoria, relatório de avaliação de risco, resultados de teste de sistemas, plano de segurança de sistemas, políticas de segurança) podem prover boas informações sobre os controles de segurança usados e planejados para o ativo. Uma análise de impacto na missão de uma organização ou avaliação de criticidade de recursos provê informações relativas à criticidade e sensibilidade de dados e sistemas. 36. 36  Uso de Ferramentas Automatizadas: Métodos técnicos proativos podem ser usados para coletar informações de um ativo eficazmente. Por exemplo, uma ferramenta de mapeamento de rede pode identificar os serviços que executam em um vasto grupo de servidores. A escolha de qual das técnicas acima serão empregadas, fica a cargo do Analista de Segurança responsável pela coleta das informações, porém frequentemente a utilização de entrevistas e revisão de documentos estão sempre presentes, devido a sua abrangência e facilidade de emprego. A coleta de informações pode ser conduzida ao longo do processo de avaliação de risco, do Passo 1 (Caracterização de Ativos) ao Passo 6 (Análise de Risco). Uma Ficha de Atividades com um roteiro descritivo orientando quais atividades deverão ser executadas, as pessoas envolvidas e os documentos requeridos e produzidos ao término da execução desse passo é apresentada no Apêndice A ao final deste documento, como uma proposta passível de adaptações para se adequar às necessidades da organização, não devendo ser encarada como um guia definitivo. Saída do Passo 1: Relatório de Avaliação de Ativos. 37. 37 3.2.2 Passo 2: Identificação de Ameaças Uma ameaça é o potencial de uma particular ameaça exercitar com sucesso uma vulnerabilidade em particular. Uma vulnerabilidade é uma fraqueza que pode ser explorada acidentalmente ou intencionalmente. Uma ameaça não apresenta um risco quando não houver uma vulnerabilidade que possa ser exercitada. Para determinar a probabilidade de uma ameaça tem-se que considerar a ameaça, as potenciais vulnerabilidades, e os controles existentes. 3.2.2.1 Identificação de ameaça O objetivo deste passo é identificar as ameaças potenciais e compilar uma declaração de ameaças que liste as potenciais ameaças aplicáveis para o ativo avaliado. Na avaliação de ameaças, é importante considerar todas as potenciais ameaças que poderiam causar dano para um ativo e seu ambiente de processamento. Por exemplo, embora a declaração de ameaça para um sistema localizado em um deserto possa não incluir "inundação natural" por causa da baixa probabilidade de tal evento ocorrer, ameaças ambientais como o estouro de um cano, que podem rapidamente inundar uma sala de computadores, podem ser consideradas como possíveis de causar danos para os ativos de uma organização. Humanos podem ser uma ameaça por atos intencionais, como ataques deliberados por pessoas maliciosas ou empregados decepcionados, ou atos não intencionais, como erros e negligência. Um ataque deliberado pode também ser uma tentativa maliciosa para ganhar acesso sem autorização para um sistema (por exemplo, através de senhas adivinhadas) ou uma benigna, mas, no entanto, propositada tentativa de iludir a segurança do sistema. Um exemplo seria um programador que está escrevendo um Trojan para contornar a segurança de um sistema. 38. 38 3.2.2.2 Motivação e Ações de Ameaças A motivação e os recursos para levar a cabo um ataque fazem os humanos fonte de ameaças potencialmente perigosas. O Quadro 1 apresenta uma avaliação de muitas das ameaças humanas comuns hoje, as possíveis motivações delas, e os métodos ou ações pelas quais elas poderiam levar a cabo um ataque. Estas informações serão úteis a organizações estudando os seus ambientes humanos de ameaça e personalizando as declarações de ameaças humanas. Além disso, revisões de histórico de paradas do sistema; relatórios de violação de segurança; relatórios de incidentes; e entrevistas com os administradores de sistemas, equipe de help desk, e comunidades de usuários durante a coleta de informações ajudará a identificar ameaças humanas que têm o potencial para prejudicar um sistema e seus dados, o que se torna uma preocupação onde uma vulnerabilidade existe. (continua) Ameaça Motivação Ações da Ameaça Hacker, cracker  Desafio  Ego  Rebelião  Hacking  Engenharia social  Invasão de sistema,  Rombos  Acesso não autorizado ao sistema Criminoso digital  Destruição de informação  Divulgação ilegal de informação  Ganho monetário  Alteração de dados sem autorização  Ato Fraudulento (por exemplo, personificação, interceptação)  Suborno por informação  Spoofing  Invasão de sistemas 39. 39 (conclusão) Ameaça Motivação Ações da Ameaça Terrorista  Chantagem  Destruição  Exploração  Vingança  Bomba/Terrorismo  Guerra de Informação  Ataque de sistemas (por exemplo, Distributed Denial of Service (DDoS))  Invasão de sistema Espionagem industrial (companhias, governos estrangeiros, interesse de outros regimes)  Vantagem competitiva  Espionagem econômica  Exploração econômica  Roubo de informação  Invasão de privacidade pessoal  Engenharia social  Invasão de sistema  Acesso não autorizado ao sistema (acesso para informação secreta e proprietária) Indivíduos internos (pobremente treinado, decepcionado, malicioso, negligente, desonesto, ou empregados desligados)  Curiosidade  Ego  Inteligência  Ganho Monetário  Vingança  Erros não intencionais e omissões (por exemplo, erro de entrada de dados, erro de programação)  Chantagem  Leitura de documentos de informação proprietária  Abuso na utilização de computador  Fraude e roubo  Suborno por informação  Corrupção de dados  Interceptação  Código malicioso (por exemplo, vírus, cavalo de Tróia)  Venda de informação pessoal  Bugs de sistema  Invasão de sistema  Sabotagem  Acesso não autorizado ao sistema Quadro 1: Exemplos de ameaças humanas: Ameaça, motivação e ações da ameaça Fonte: NIST SP 800-30, 2002 40. 40 A declaração de ameaças, ou a lista de potenciais ameaças, deve ser determinada individualmente à organização e seu ambiente de processo. Em geral, informações sobre ameaças naturais (por exemplo, inundações, terremotos, tempestades) devem estar prontamente disponíveis, assim como ameaças conhecidas que foram identificadas por entidades do governo e organizações privadas. Ferramentas de detecção de intrusão também estão ficando mais prevalecentes, e o governo e organizações de indústria juntam dados continuamente em eventos de segurança, melhorando a habilidade para avaliar ameaças realisticamente. Fontes de informação incluem, mas não estão limitadas, às seguintes:  Agências de Inteligência  Meios de comunicação de massa, particularmente recursos baseados na Web como SecurityFocus.com, SecurityWatch.com, SecurityPortal.com, e SANS.org. Saída do Passo 2: Uma Declaração de Ameaças, que contém uma lista de ameaça-fonte que poderiam explorar vulnerabilidades dos ativos. 41. 41 3.2.3 Passo 3: Identificação de Vulnerabilidades A análise de riscos para um ativo de TI tem que incluir uma identificação das vulnerabilidades associadas com o ambiente do ativo. A meta deste passo é desenvolver uma lista de vulnerabilidades do ativo (falhas ou fraquezas) que poderiam ser exploradas por potenciais ameaças. O Quadro 2 apresenta exemplos de pares de vulnerabilidades/ameaças. Vulnerabilidade Ameaça Ação da Ameaça Identificadores (ID) de empregados desligados não são removidos do sistema Empregados desligados Conectando na rede da organização e acessando dados proprietários Firewall da organização permite entrada de telnet, e a conta convidado está habilitada no servidor XYZ Usuários sem autorização (por exemplo, hackers, empregados desligados, criminosos de computador, terroristas) Usando telnet para o servidor XYZ navegando pela estrutura de arquivos de sistemas com a conta convidado O fabricante identificou falhas dentro da segurança do sistema; porém hot fixes novos não têm sido aplicados no sistema Usuários sem autorização (por exemplo, hackers, empregados insatisfeitos, criminosos digitais, terroristas) Obtendo acesso não autorizado ao sistema baseado em vulnerabilidades conhecidas do sistema Quadro 2: Pares de Vulnerabilidades/Ameaças Fonte: NIST SP 800-30, 2002 Métodos indicados para identificar vulnerabilidades de ativos são o uso de fontes de vulnerabilidades, a execução de testes de segurança, e o desenvolvimento de uma lista de checklist de exigências de segurança. Devem ser observados os tipos de vulnerabilidades que existirão, e a metodologia necessária para determinar se as vulnerabilidades estão presentes 42. 42 frequentemente variará, dependendo da natureza do ativo e a fase em que se encontra:  Se o ativo ainda não tiver sido implementado, a procura por vulnerabilidades deverá focar nas políticas de segurança da organização, procedimentos de segurança planejados, e definições de requisitos de sistema, e as análises de segurança de fabricantes ou desenvolvedores (por exemplo, white papers).  Se o ativo estiver sendo implementado, a identificação de vulnerabilidades deverá ser ampliada para incluir informações mais específicas, como as características de segurança planejadas, descritas na documentação de desígnio de segurança e os resultados de certificação de testes e avaliação do ativo.  Se o ativo estiver em operação, o processo de identificação de vulnerabilidades deverá incluir uma análise das características de segurança do ativo, e os controles de segurança, técnicos e procedimentais, usados para proteger o ativo. 3.2.3.1 Fontes de vulnerabilidades As vulnerabilidades técnicas e não-técnicas associadas com um ambiente de processamento de TI podem ser identificadas através da coleta de informações técnicas descritas no Passo 1. Uma revisão de outras fontes da indústria (por exemplo, páginas Web que identificam bugs e falhas de sistemas) será útil para preparar as entrevistas e desenvolver questionários efetivos para identificar vulnerabilidades que podem ser aplicáveis para um ativo específico (por exemplo, uma versão específica de um sistema operacional). A Internet é outra fonte de informações de vulnerabilidades conhecidas postadas por fabricantes, junto com hot fixes, service packs, patches, e outras medidas que podem ser aplicadas para eliminar ou mitigar vulnerabilidades. Fontes documentadas de vulnerabilidades que devem ser consideradas em uma análise completa de vulnerabilidades incluem, mas não se limitam às seguintes: 43. 43  Documentações anteriores de avaliação de risco do ativo avaliado  Relatórios de auditoria do ativo, relatórios de anomalias do ativo, relatórios de revisão de segurança, e relatórios de avaliação e testes do ativo  Listas de vulnerabilidades  Boletins de Segurança  Boletins de fabricantes  Equipes comerciais de resposta a incidentes/emergências de computador e fóruns de discussão (por exemplo, SecurityFocus.com)  Informações seguras e alertas e boletins de vulnerabilidades para sistemas militares  Softwares de análises de segurança de sistemas. 3.2.3.2 Testes de Segurança de ativos Métodos pró-ativos, empregados para testes de sistemas, podem ser eficazmente usados para identificar vulnerabilidades do ativo, dependendo da criticidade do ativo e dos recursos disponíveis (por exemplo, recursos alocados, tecnologia disponível, pessoas capacitadas para conduzir os testes). Métodos de teste incluem:  Ferramentas de verificação automática de vulnerabilidades  Testes de avaliação e segurança  Testes de penetração Ferramentas de verificação automática de vulnerabilidades são usadas para verificar um grupo de computadores ou uma rede para serviços vulneráveis conhecidos (por exemplo, o sistema permite File Transfer Protocol (FTP) anônimo, sendmail retransmissor). Porém, deve ser notado que algumas das vulnerabilidades potenciais identificadas pela ferramenta podem não representar reais vulnerabilidades no contexto do ambiente do sistema. Por exemplo, algumas destas 44. 44 ferramentas taxam vulnerabilidades potenciais sem considerar o local e exigências do ambiente. Algumas das "vulnerabilidades" assinaladas pela ferramenta podem não ser realmente vulneráveis para um local em particular, mas podem ser configuradas desse modo porque o ambiente requeira isto. Assim, este método de teste pode produzir falsos positivos. Testes de avaliação e segurança é outra técnica que pode ser usada para identificar vulnerabilidades de ativos durante o processo de avaliação de riscos. Inclui o desenvolvimento e execução de um plano de teste (por exemplo, roteiro de teste, procedimentos de teste, e resultados esperados de teste). O propósito do teste de segurança de sistemas é testar a efetividade dos controles de segurança de um ativo que foram aplicados em um ambiente operacional. O objetivo é assegurar que os controles aplicados conheçam a especificação de segurança aprovada para o software e hardware e implementam a política de segurança da organização ou satisfazem padrões da indústria. Testes de penetração podem ser usados para complementar a revisão de controles de segurança e assegurar que diferentes facetas do ativo estão seguras. Testes de penetração, quando empregados no processo de avaliação de risco, podem ser usados para avaliar a habilidade de um ativo para resistir a tentativas intencionais de quebra de segurança de um ativo. Seu objetivo é testar o ativo do ponto de vista de uma ameaça e identificar potenciais falhas dentro do esquema de proteção de ativos. Os resultados destes testes opcionais de segurança ajudarão a identificar as vulnerabilidades de um ativo. 3.2.3.3 Desenvolvimento da Lista de Verificação de Exigências de Segurança Durante este passo, a equipe de avaliação de riscos determina se as exigências de segurança estipuladas para o ativo e coletadas durante a caracterização do ativo estão presentes nos controles de segurança existentes ou planejados. Tipicamente, as exigências de segurança de ativo podem ser apresentadas em forma de tabelas, com cada exigência acompanhada por uma 45. 45 explicação indicando porque a atual designação ou implementação do ativo satisfaz ou não aquela exigência. Uma lista de verificação de exigências de segurança contém os padrões de segurança básicos que podem ser usados para avaliar sistematicamente e identificar as vulnerabilidades dos ativos (pessoas, hardware, software, informação), procedimentos, processos, e transferências de informação associadas com um determinado ativo nas seguintes áreas de segurança:  Administrativa  Operacional  Técnica O Quadro 3 lista critérios de segurança sugeridos para uso em identificação de vulnerabilidades de ativos em cada área de segurança. (continua) Área de segurança Critérios de segurança Administração  Responsabilidades  Apoio de Continuidade  Capacidade de resposta a incidente  Revisão periódica de controles de segurança  Avaliação de risco  Treinamento técnico de segurança  Divisão de responsabilidades  Autorização de sistema  Aplicação do plano de segurança de sistema 46. 46 (conclusão) Área de segurança Critérios de segurança Operação  Controle de contaminações no ar (fumaça, pó, substâncias químicas)  Controles para assegurar a qualidade do fornecimento de energia elétrica  Acesso e disposição de mídias de dados  Capacidade de proteção (por exemplo, sala de computadores, centro de dados, escritório)  Controle de umidade  Controle temperatura  Estações de trabalho, laptops, e computadores pessoais Técnica  Comunicações (por exemplo, interconexão de sistema, routers)  Criptografia  Controle de acesso discricionário  Identificação e autenticação  Detecção de Intrusão  Auditoria de sistemas Quadro 3: Critérios de segurança Fonte: NIST SP 800-30, 2002 O resultado deste processo é a lista de verificação de exigências de segurança. Fontes que podem ser usadas para compilar tal lista incluem, mas não se limitam às seguintes fontes aplicáveis para o ambiente de processamento do ativo:  Plano de segurança do sistema avaliado  Políticas, diretrizes, e padrões de segurança da organização  Práticas da indústria O NIST SP 800-53, Controles de Segurança Recomendados para Sistemas de Informação Federais e Organizações, provê um questionário extenso que contém 47. 47 objetivos de controle específicos contra os quais um sistema ou grupo de sistemas interconectados podem ser testados e podem ser medidos. Os objetivos de controle são resumidos diretamente de exigências antigas encontradas em estatutos, políticas, e orientações em segurança e privacidade. Os resultados da lista de verificação (ou questionário) podem ser usados como contribuição para uma avaliação de obediência e descumprimento. Este processo identifica fraquezas em sistemas, processos, e procedimentos que representam vulnerabilidades potenciais. Saída do Passo 3: Uma Lista de Vulnerabilidades do ativo que poderiam ser exploradas por potenciais ameaça. 48. 48 3.2.4 Passo 4: Determinação de Probabilidades Para derivar uma taxa de probabilidade global que indique qual a probabilidade de uma potencial vulnerabilidade possa ser explorada dentro do ambiente construído, os seguintes fatores administrativos devem ser considerados:  Motivação e capacidade da ameaça  Natureza da vulnerabilidade  Existência e efetividade dos controles atuais Neste passo, serão utilizadas as saídas dos passos anteriores, traçando para cada ativo avaliado, as potenciais ameaças, as vulnerabilidades identificadas, e um nível de probabilidade da exploração de uma vulnerabilidade por uma potencial ameaça. A probabilidade que uma potencial vulnerabilidade possa ser explorada por uma determinada ameaça pode ser descrita como alta, média, ou baixa. O Quadro 4 abaixo descreve estes três níveis de probabilidade. Nível de probabilidade Definição de probabilidade Alta A ameaça está altamente motivada e suficientemente capaz, e controles para prevenir a vulnerabilidade de ser explorada são ineficazes. Média A ameaça está incentivada e capaz, mas controles estão aplicados controles que podem impedir o sucesso da exploração da vulnerabilidade. Baixa A ameaça está desmotivada ou incapaz, ou controles estão aplicados para prevenir, ou pelo menos significativamente impedir, a vulnerabilidade de ser explorada. Quadro 4: Definições de probabilidade Fonte: NIST SP 800-30, 2002 Saída do Passo 4: Relatório de Avaliação de Probabilidade (Alta, Média, Baixa) 49. 49 3.2.5 Passo 5: Análise de Impacto O próximo passo na avaliação do nível de risco é determinar o impacto adverso resultante do sucesso da exploração de uma vulnerabilidade por uma potencial ameaça. Antes de começar a análise de impacto, é necessário obter a seguintes informações, que já deverão ter sido identificadas no Passo 1:  Missão do ativo (por exemplo, os processos executados pelo ativo)  Criticidade do ativo e dos dados (por exemplo, o valor do ativo ou sua importância para uma organização)  Sensibilidade do ativo e dos dados Estas informações podem ser obtidas da documentação organizacional existente, como o Relatório de Análise de Impacto de Negócios. Uma Análise de Impacto de Negócios (também conhecida como BIA para algumas organizações) prioriza o nível de impacto associado com os ativos de informação de uma organização baseado em uma avaliação qualitativa ou quantitativa da sensibilidade e criticidade desses ativos. Se esta documentação não existe, a sensibilidade e criticidade do ativo podem ser determinadas baseadas no nível de proteção exigido para manter a disponibilidade, integridade e confidencialidade do ativo. Apesar dos métodos usados para determinar quão sensível um ativo e seus dados são, os proprietários da informação e do ativo são os únicos responsáveis por determinar o nível de impacto para o seu próprio ativo e informações. Por conseguinte, na análise de impacto, uma aproximação apropriada é entrevistar os proprietários do ativo e da informação. Então, o impacto adverso de um incidente de segurança pode ser descrito em termos de perda ou degradação de qualquer, ou uma combinação de quaisquer, dos seguintes três objetivos de segurança: integridade, disponibilidade, e confidencialidade. Alguns impactos tangíveis podem ser medidos quantitativamente em perda de faturamento, o custo de reparar o ativo, ou o nível de esforço exigido para corrigir problemas causados por uma ação bem sucedida de uma ameaça. Outros impactos 50. 50 (por exemplo, perda de confiança pública, perda de credibilidade, danos aos interesses de uma organização) não podem ser medidos em unidades específicas, mas podem ser qualificados ou podem ser descritos em termos de alto, médio, e baixo impacto. Por causa da natureza genérica desta discussão, serão designadas e descritas só as categorias qualitativas – alto, médio, e baixo impacto (Quadro 5). Magnitude do Impacto Definição do Impacto Alta A exploração da vulnerabilidade: 1. Pode resultar em perda altamente custosa dos principais tangíveis ativos ou recursos; 2. Pode significativamente violar, prejudicar, ou impedir a missão, reputação, ou interesse de uma organização; 3. Pode resultar em morte humana ou graves ferimentos. Média A exploração da vulnerabilidade: 1. Pode resultar em perda altamente custosa tangível de ativos ou recursos; 2. Pode violar, prejudicar, ou impedir a missão, reputação, ou interesse de uma organização; 3. Pode resultar em ferimento humano. Baixa A exploração da vulnerabilidade: 1. Pode resultar na perda de algum tangível ativo ou recurso; 2. Pode notoriamente afetar a missão, reputação, ou interesse de uma organização. Quadro 5: Definições de Magnitude de Impacto Fonte: NIST SP 800-30, 2002 Saída do Passo 5: Relatório de Avaliação de Impacto (Alto, Médio, ou Baixo) 51. 51 3.2.6 Passo 6: Determinação do Risco O propósito deste passo é avaliar o nível de risco para um ativo. A determinação do risco para uma ameaça/vulnerabilidade em particular pode ser expressa como uma função de:  A probabilidade de uma determinada ameaça tentar explorar uma determinada vulnerabilidade  A magnitude do impacto da exploração bem sucedida de uma vulnerabilidade por uma ameaça  A adequação de planos ou controles de segurança existentes para reduzir ou eliminar os riscos. Para medir o risco, uma escala de risco e uma matriz de nível de risco devem ser desenvolvidas. A seção 3.2.6.1 apresenta uma matriz padrão de nível de risco; a seção 3.2.6.2 descreve os níveis de risco resultantes. 3.2.6.1 Matriz de risco de nível A determinação final de risco é derivada multiplicando as avaliações determinadas para probabilidade da ameaça e impacto da ameaça. O Quadro 6 abaixo mostra como as avaliações de risco globais podem ser determinadas baseadas em contribuições da probabilidade da ameaça e categorias de impacto da ameaça. A matriz abaixo é uma matriz 3 x 3 de probabilidade da ameaça (Alta, Média, e Baixa) e impacto da ameaça (Alto, Médio, e Baixo). Dependendo das exigências do local e o nível de granularidade da avaliação de risco desejada, alguns locais podem usar uma matriz 5 x 5. Neste caso, podem-se incluir os níveis Muito Baixa/Muito Alta para probabilidade de ameaça e Muito Baixo/Muito Alto para impacto da ameaça, para gerar os níveis Muito Baixo/Muito Alto para nível de risco. 52. 52 Probabilidade da Ameaça Impacto Baixo (10) Médio (50) Alto (100) Alta (1.0) Baixo 10 x 1.0 = 10 Médio 50 x 1 = 50 Alto 100 x 1.0 = 100 Média (0.5) Baixo 10 x 0.5 = 5 Médio 50 x 0.5 = 25 Médio 100 x 0.5 = 50 Baixa (0.1) Baixo 10 x 0.1 = 1 Baixo 50 x 0.1 = 5 Baixo 100 x 0.1 = 10 Quadro 6: Matriz de nível de risco. Escala de risco: Alto (> 50 a 100); Médio (> 10 a 50); Baixo (1 a 10) Fonte: NIST SP 800-30, 2002 A matriz de exemplo no Quadro 6 mostra como os níveis de risco globais de Alto, Médio, e Baixo são derivados. A determinação destes níveis de risco pode ser subjetiva. A razão para esta justificativa pode ser explicada em termos da probabilidade determinada para cada nível de probabilidade da ameaça e um valor determinado para cada nível de impacto. Por exemplo,  A probabilidade definida para cada nível de probabilidade de ameaça é 1.0 para Alto, 0.5 para Médio, 0.1 para Baixo  O valor determinado para cada nível de impacto é 100 para Alto, 50 para Médio, e 10 para Baixo 3.2.6.2 Descrição de Nível de Risco O Quadro 7 descreve os níveis de risco mostrados na matriz anterior. Esta escala de risco, com suas avaliações de Alto, Médio, e Baixo, representa o grau ou nível de risco para qual um ativo poderia ser exposto se uma determinada vulnerabilidade fosse explorada. A escala de risco também apresenta ações que a administração sênior, tem que tomar para cada nível de risco. 53. 53 Nível de Risco Descrição de Risco e Ações Necessárias Alto Se uma observação ou descoberta é avaliada como um risco alto, há uma forte necessidade de medidas corretivas. Um sistema existente pode continuar operando, mas um plano de ação corretivo deve ser posto em prática o mais cedo possível. Médio Se uma observação for avaliada como risco médio, ações corretivas são necessárias e um plano deve ser desenvolvido para incorporar estas ações dentro de um período razoável de tempo. Baixo Se uma observação é descrita como baixo risco, os responsáveis pelo ativo devem determinar se ações corretivas ainda são requeridas ou se decidem aceitar o risco. Quadro 7: Escala de risco e ações necessárias Fonte: NIST SP 800-30, 2002 Saída do Passo 6: Relatório de Análise de Risco (Alto, Médio, Baixo). Os passos descritos nas últimas seções compõem o processo proposto neste trabalho. As próximas seções descrevem as atividades restantes do processo de elaboração de planos de continuidade e foram construídas com base nas melhores práticas da literatura e normas de mercado. 54. 54 3.3 Definição das Estratégias de Recuperação A estratégia de recuperação é desenvolvida a partir da análise dos resultados da Avaliação e Análise de Riscos e provê orientação no modo como a recuperação pode ser efetuada. A primeira fase é desenvolver um esboço das possíveis opções de recuperação que a organização poderia implementar para alcançar os seus objetivos como declarado na Política de PCN. A estratégia é desenvolvida até que a opção de recuperação mais apropriada seja escolhida. Devem ser documentadas as possíveis opções para recuperação. As opções serão definidas a partir do resultado da Avaliação e Análise de Riscos e esboçará como a área de TI pretende continuar oferecendo seus serviços para o cumprimento dos objetivos e obrigações da organização a níveis normais, a um custo-benefício aceitável, apesar da ocorrência de um incidente que afete a habilidade dela para operar. Devem ser determinadas opções para as seguintes áreas:  Equipes (incluindo habilidades e conhecimento);  Premissas (local de trabalho e locais onde a informação é guardada);  Tecnologia (telefonia, dados, aplicações, sistemas);  Estoques (materiais e equipamentos); Exemplos de risco de continuidade poderiam incluir:  Administração de Registros – A identificação de que o armazenamento, arquivamento e recuperação de registros são pobres, podendo ter como conseqüência sua indisponibilidade quando requeridos e gerando uma falha de regulamentação ou risco de perda de reputação.  Equipe de treinamento – A identificação de baixos níveis de conhecimento diversificado, treinamento ou planejamento de sucessão. Isto poderia conduzir a um risco de continuidade existir níveis acima da 55. 55 média de doenças, greve ou um membro fundamental da equipe ficar indisponível durante várias semanas ou meses.  Plano de backup – Sendo identificados riscos com respeito à backup de dados e a recuperação e restauração destes dados. As atividades de planejamento para endereçar os riscos de continuidade devem ser implementadas e deve ser relatado o trabalho já completado para assegurar que o prazo final para a entrega do PCN será alcançado. As opções dependerão de:  Objetivos do Tempo de Recuperação para os processos críticos;  Objetivos do Ponto de Recuperação para os dados críticos;  Interdependência de componentes;  Custos de implementação das várias opções;  Conseqüências de inércia Deve ser observado que a organização deve minimizar a probabilidade de implementar uma solução que pode ser impactada pelo mesmo incidente que causou a interrupção do negócio. Por exemplo, mudando a operação de um Data Center para uma localização que poderia ser também afetada pelo mesmo corte de energia, quebra de telefonia ou inundação. As estratégias adotadas são freqüentemente bastante complexas e será tipicamente uma ou uma combinação das seguintes opções:  Provisão feita dentro da organização (Deslocamento, Trabalho Remoto);  Serviços entregues à organização (instalações móveis ou unidades pré-fabricadas);  Serviços providos externamente por um terceiro (Área de Trabalho de Recuperação Instalações);  Locais espelhados que são idênticos aos locais primários em todos os aspectos técnicos; 56. 56 Há várias opções disponíveis dependendo da estratégia de tecnologia da organização, e a solução pode ser complexa. Estas opções podem ser classificadas como cold, warm ou hot sites, com vantagens e desvantagens apresentadas em cada uma. A escolha destas opções dependerá de fatores como:  Tempo de retorno para processos que apóiam as atividades críticas identificados no negócio;  Um processo com tempo de retorno menor que um dia requererá táticas que permitam a atividade a ser assumida em outros locais, ou recolocação rápida do pessoal afetado;  Local e distancia entre sites de tecnologia;  Número de sites de tecnologia;  Acesso remoto;  Conectividade e redundância de telecomunicações;  Estratégia de backup (por exemplo diário, semanal, mensal, Compact Disc (CD), fita, Redundant Array of Independent Disks (RAID));  Conectividade de terceiros e ligações externas. 3.4 Desenvolvimento do PCN Uma vez que as estratégias foram determinadas e qualquer risco de continuidade tenha sido endereçado, a organização deverá decidir como deseja apresentar o PCN. O PCN deverá suprir no mínimo a três conjuntos de atividades para as quais estão correlacionadas as três fases de um incidente, como mostrado em Figura 5.  Responder, a um incidente, emergência ou desastre.  Recuperar, atividades críticas do negócio (isto pode incluir soluções de contorno temporárias no caso da ausência de tecnologia essencial). 57. 57  Retomar, o funcionamento normal de todas as operações empresariais das medidas temporárias adotadas durante a recuperação. Figura 5: A Linha do Tempo de Incidentes Fonte: ENISA, 2008 3.4.1 Conjunto de documentos O conjunto de documentos que incluem o PCN variará de organização a organização, mas é recomendado que os planos seguintes, apresentados no Quadro 8, sejam considerados. Em organizações menores estes planos poderão ser combinados em um, mas em organizações maiores eles provavelmente existirão ou como entidades separadas ou alguns dos planos combinados juntos. Dentro de minutos a horas: Equipes e visitantes estimam vítimas, tratando da contenção de danos / limitações de avaliação de danos, invocando o gerenciamento de incidentes. Dentro de minutos a dias: Comunicação a equipes, clientes, fornecedores etc. Recuperação de atividades de negócios críticas. Reconstrução de trabalho perdido em progresso. Dentro de semanas a meses: Reparação de danos / substituição. Recolocação para o local fixo de trabalho, retomando o funcionamento normal. Recuperação de custos de seguradoras. Objetivo de recuperação global: Retornar para normalidade tão rápido quanto possível Linha do Tempo Resposta Recuperação Reinício T e m p o Z e r o Incidente 58. 58 (continua) Plano Linha do Tempo Propósito do Plano Plano de Resposta a Incidente Resposta Administrar o resultado imediato de um incidente, inclusive evacuação, ligação com serviços de emergência e saúde, segurança e bem-estar do pessoal e público Plano de Gerenciamento de Incidente Recuperação Administrar o incidente centralmente e assegurar que as equipes que efetuam a recuperação estão equipados com seus recursos críticos Plano de Recuperação de Negócios Recuperação Prover as equipes que estão recuperando os seus processos críticos, com as listas de ações necessárias, informações, procedimentos e detalhes de contato Planos de Apoio à Recuperação - Plano de Recursos Humanos (RH) - Plano Instalações - Plano de Saúde e Segurança Recuperação Prover as equipes times que têm papéis especialistas em um incidente com as informações necessárias e procedimentos para poder apoiar as equipes de recuperação Plano de continuidade de Serviços de TI Recuperação e Reinício Detalhar as ações que integrantes das equipes de tecnologia e segurança da informação deverão seguir para restabelecer os componentes críticos aos processos críticos dentro do acordado nos componentes Recovery Time Objective (RTO) e Recovery Point Objective (RPO) 59. 59 (conclusão) Plano Linha do Tempo Propósito do Plano Plano de Comunicações e Mídia Resposta, Recuperação e Reinício Este plano contém toda a informação necessária para habilitar a equipe de Comunicação e Mídia para comunicar com precisão e efetivamente com o pessoal, clientes, público, provedores e mídia Plano de Reinício de Negócios Reinício Este plano detalha os procedimentos a seguir para devolver a organização à normalidade. Pode ser um plano ou umas séries de planos e poderá incluir planos de projeto de longo alcance Quadro 8: O uso das partes constituintes do PCN durante cada fase de um incidente Fonte: ENISA, 2008 Quando O PCN é introduzido em uma organização um dos resultados é a produção de um número de documentos, nem todos os quais necessariamente são incluídos no PCN (por exemplo, um número de políticas e procedimentos como políticas de RH). O PCN pode ser usado em isolado para efetuar a recuperação no caso de um incidente afetando a organização, mas na realidade ele interage com outros documentos nas áreas de Administração de Risco, Segurança de Informação, RH/Saúde e políticas de Segurança e Continuidade de Serviços de TI. Alguns dos documentos e processos já existentes exigirão modificação como diferentes informações são requeridas. O RH, por exemplo, precisará de informações de parentes com detalhes de contato atualizados. Este sistema exigirá mudanças no processo de administração para assegurar que a informação é atual, uma política de segurança de informação para assegurar que não é amplamente acessível e para assegurar que a informação estará disponível durante um incidente envolvendo o repositório de informações. Os detalhes das interfaces entre estes programas (Gestão de Continuidade de Serviços de Tecnologia da Informação (GCSTI), Gestão de Continuidade de Negócios (GCN), Gestão de Riscos (GR)) depende da organização e do método de implementação. 60. 60 3.5 Teste do Plano de Continuidade de Negócios BS 25999-1 declara que a Continuidade de Negócio e Administração de Incidentes de uma organização não podem ser considerados seguros até serem testados. Testar é essencial para desenvolver trabalho em equipe, competência, confiança e conhecimento os quais são vitais na hora de um incidente. ISO 27002 vai além declarando que os testes deveriam assegurar que todos os membros das equipes de recuperação e outras equipes pertinentes estão conscientes dos planos e de sua responsabilidade para com a Continuidade de Negócios e a segurança de Informação, como também sabem seu papel quando um plano é invocado. 3.5.1 Determinando o tipo de teste Há muitos modos de testar que um PCN é adequado para propósito e a tabela abaixo descreve vários destes métodos. O método escolhido dependerá da maturidade de GCN dentro da organização e dos testes que tenham sido administrados anteriormente. Em alguns casos, pode ser uma boa idéia designar algumas das pessoas envolvidas (empregados e também consultores externos de confiança) no papel de facilitadores e observadores, para ajudar a conduzir e entender o teste. O promotor do teste ou exercício fará um resumo aos participantes dos objetivos do teste e fixará o cenário. Durante o teste, ele coordenará as atividades de e assegurará que o teste ocorre de acordo com o tempo programado. Depois do teste, o promotor será responsável por escrever um Relatório de Teste. Um observador observa o teste e não participa em nenhum momento do mesmo. Ele registra os resultados do teste, como progride, quais os fatores prós e contra o sucesso do teste identificados. Ele ajudará o promotor do teste sumarizando os pontos chave observados e passará seus resultados para a elaboração do Relatório de Teste a ser escrito. 61. 61 3.5.2 Escrevendo o plano de teste Para produzir o máximo valor de um teste, um Plano de Teste deverá ser desenvolvido para definir os elementos selecionados, os objetivos de teste explícitos e quais os critérios de sucesso. O plano de teste deverá conter um horário que detalha os prazos para cada teste e participantes do teste e deverá delinear a extensão, os objetivos, o enredo e a logística empregada claramente. O enredo desenvolvido deverá ser tão realístico quanto possível para testar o plano corretamente e ganhar o apoio máximo dos participantes. Em alguns testes é apropriado buscar envolvimento de pessoal externo como serviços de emergência, segurança, peritos e provedores especializados. Questionários deverão ser preparados para que observadores possam registrar as observações deles durante o teste. 3.5.3 Conduzindo o teste Antes do teste, os participantes deverão ser providos com toda a informação necessária e deverá ser feito um resumo sobre a “situação”. Os participantes fazem sua parte no teste usando os planos relacionados que são fornecidos pelo Promotor. Os Observadores determinam quais aspectos do teste estão observando e registram o que eles vêem e ouvem no questionário. Depois do teste o Promotor e os Observadores deverão documentar os resultados do teste e identificar potenciais ações de melhoria. 3.5.4 Comunicando o resultado do teste Tão logo seja possível, deverá ser conduzida após o teste uma apresentação onde os participantes reportarão o que eles perceberam que foi bem, o que foi mal e onde sua reação pode ser melhorada. A apresentação deve incluir todos os 62. 62 participantes, os observadores e todos os com responsabilidade para manutenção do plano ou ativação no futuro. Ao término da apresentação, responsáveis por atividades de melhoria do plano deverão ser nomeados. O resultado final dessa fase será a produção de um Relatório de Teste que esboça a extensão, aproximação, método e resultados do teste com as recomendações para ação e os responsáveis pela ação. 3.6 Manutenção do Programa de Gestão de Continuidade de Negócios Planos podem ficar obsoletos muito rapidamente (particularmente listas de contato) e até mesmo depois de algumas semanas, se não atualizados, a efetividade e relevância de planos podem começar a deteriorar. Após a implementação do PCN testado, é então necessário manter o plano atualizado, assegurando que todo o pessoal envolvido no andamento da GCN ou administração e resposta de incidentes foi treinado nos seus papéis e a divulgação da GCN é destacada em todos os níveis por toda a organização. 3.6.1 Treinamento de equipes [NIST 800-34] aconselha que treinamento para o pessoal com responsabilidades de Continuidade de Negócios deverá complementar as provas. Treinamentos deverão ser providos pelo menos anualmente; novos membros que terão responsabilidades no plano devem receber treinamento tão logo sejam contratados. No final das contas, todo o pessoal deve ser treinado até o ponto em que eles estejam aptos a executar a resposta a incidentes e procedimentos de administração de incidentes sem a ajuda dos documentos. Treinamentos deverão envolver:  Propósito do plano  Relacionamento entre equipes de coordenação e comunicação 63. 63  Apresentação de procedimentos  Arranjos de segurança  Equipes de processos específicos  Responsabilidades individuais [TR 19:2005] recomenda que treinamentos sejam também dirigidos a grupos específicos, como mostrado no Quadro 9 abaixo: Alvo Descrição Todo o pessoal Treinamento de divulgação básico o qual dá para a equipe uma percepção básica em Continuidade de Negócios e os informa sobre os Planos de Recuperação de Negócios e o que acontecerá a eles durante um incidente. Equipe de administração Treinamento administrativo para informar os gerentes sobre a abrangência de resposta e administração de incidentes, o propósito dos Planos de Recuperação de Negócios, o que se espera que façam durante um incidente e como eles irão implementar seus planos. Pessoal de Continuidade de Negócios e Incidente Treinamento especializado para treinar todo o pessoal envolvido em resposta, administração e recuperação de incidentes. Isto provavelmente irá envolver vários cursos de treinamento diferentes. Quadro 9: Níveis de treinamento de Administração de Continuidade de Negócios Fonte: ENISA, 2008 Exemplos dos tipos de cursos de treinamentos que poderão ser apresentados ao pessoal no terceiro grupo são:  Evacuação  Comunicações de mídia  Estabelecimento de uma sala de incidentes  Administração de incidentes 64. 64  Comunicações de crise  Trabalho em locais alternativos Treinamentos deverão também ser providos para o pessoal que formará a Equipe de Administração de Continuidade de Negócios que deverá cobrir:  Programa de Administração  Condução de uma BIA  Projetando e implementando PCNs  Avaliação de riscos e ameaças  Desenvolvimento de testes e exercícios O programa de treinamento de Continuidade de Negócios deverá ser embutido dentro do programa de treinamento e desenvolvimento da organização. Detalhes de treinamentos específicos e sua freqüência (levando em conta treinamento adicional assim como treinamento de novos membros das equipes) deverão ser incluídos em um Manual de Treinamento que fará parte do portfolio de treinamentos da organização. Idealmente, o treinamento geral de Continuidade de Negócios deverá ser incluído dentro do programa de apresentação de forma que todo o pessoal seja alertado sobre Continuidade de Negócios desde o começo de sua carreira. 3.6.2 Manutenção e revisão do Plano de Continuidade de Negócios O programa deverá assegurar que qualquer mudança (interna ou externa) a qual impacte na organização será revisada em relação ao PCN. Também deverá identificar qualquer novo produto novo e serviço e suas atividades dependentes que precisam ser incluídas no programa de manutenção da GCN. Se houver qualquer grande mudança empresarial, uma revisão da BIA deverá ser empreendida. Podem ser corrigidos os outros componentes do programa de GCN para levar conta estas mudanças. 65. 65 A alta administração da organização deverá, a intervalos que julgar apropriado, revisar a capacidade de GCN da organização para assegurar sua contínua conveniência, suficiência e efetividade. Esta revisão deverá ser documentada e deverá assegurar dentro do programa de GCN:  Que foram identificados todos os produtos e serviços chave e as atividades e recursos críticos apoiados por eles tenham sido incluídos na estratégia de GCN;  A política de GCN, estratégias, e planos refletem prioridades e exigências com precisão;  A competência de GCN e capacidade são efetivas e adequadas para o propósito e permitirá a administração de comando, controle e coordenação de um incidente;  As soluções de GCN são efetivas, adequadas para o propósito e apropriadas ao nível de risco enfrentado pela organização;  Estratégias de GCN e planos incorporam melhorias identificadas durante incidentes e exercícios como também no programa de manutenção;  A organização tem um programa contínuo para divulgação e treinamento de GCN;  Procedimentos de GCN foram efetivamente comunicados às equipes relacionadas, que entendem seus papéis e responsabilidades;  Os programas de manutenção e treinamento de GCN foram implementados e exercitados efetivamente;  Processos de controle de mudança estão sendo usados e operando efetivamente. Detalhes dos períodos de revisão e freqüência de testes e treinamento podem ser incluídos em um documento de Manutenção e Revisão separado. Este documento especifica como e quando o PCN será revisado e será testado e o processo para manutenção do plano. Os intervalos entre testes e revisões dependerão da organização, sua complexidade e taxa de mudança. Uma programação de treinamento também poderá ser incluída. 66. 66 A organização deverá prover para uma auditoria independente de sua competência de GCN a capacidade para identificar deficiências atuais e potenciais. Auditorias independentes podem ser administradas por pessoas competentes externas ou internas. O PCN poderá conter informação sensível (por exemplo, números de contato de executivos ou localização de registros vitais) que deverá ser protegida adequadamente. Deverão ser armazenadas cópias do PCN em um local remoto, a uma distância suficiente para escapar de qualquer dano de um incidente no local principal. A administração deverá assegurar que cópias do PCN são atualizadas e protegidas com o mesmo nível de segurança como aplicado no local principal [ISO 27002]. Uma vez que o PCN tenha sido embutido na organização como um processo de administração contínuo ele entra em um ciclo de iteração; sendo revisado a intervalos regulares e atualizado quando necessário. 3.6.2.1 Gerenciamento de mudanças Mudanças para o PCN as quais tenham sido identificadas como resultado de exercícios, testes, treinamentos desenvolvimentos organizacionais não podem ser feitos sem atravessar o processo de Gerenciamento de Mudança. O que pode parecer ser pequenas mudanças no nível de uma unidade empresarial pode ter impactos significantes no PCN em outras áreas. As mudanças devem ser aprovadas pelo Gerente de Continuidade de Negócios e se necessário ir antes ao Comitê Dirigente de Continuidade de Negócios para aprovação final. O Gerente de Continuidade de Negócios será responsável por emitir as mudanças conforme os procedimentos da organização para documentação e controle de versão. 67. 67 3.6.2.2 Melhoramento contínuo Melhoria contínua, com respeito à qualidade e desempenho da organização, foca em melhorar a satisfação dos clientes através de contínuos e incrementais melhoramentos de processos, inclusive a remoção de atividades desnecessárias e variações. A administração de continuidade de negócios deverá então ser incluída como parte do processo de melhoria contínua para assegurar que o plano permanece efetivo e executável e é adotado por cada um dos membros das equipes em todos os níveis dentro da organização. 3.6.3 Desenvolvendo a divulgação É necessário comunicar a mensagem de Continuidade de Negócios a todo o pessoal de forma que eles estejam informados sobre os princípios fundamentais de Continuidade de Negócios. Isto será embutido na cultura empresarial de forma que se torne hábito e parte dos valores principais da organização. Há vários modos pelos quais as informações podem ser comunicadas:  Cursos e treinamentos  Treinamento induzidos  Enredo de exercícios e testes  Artigos nos boletins informativos da organização  Inclusão na intranet  Ordem do dia em reuniões Ao longo do programa de GCN e no ciclo subseqüente de manutenção de GCN, o pessoal de equipes de todos os níveis deverá ser consultado sobre Continuidade de Negócios e suas idéias, se aprovadas, incorporadas no PCN. 68. 68 4 ESTUDO DE CASO Para validar a eficiência e eficácia do processo de Avaliação e Análise de Riscos desenvolvido, foi feito um estudo de caso em uma empresa fictícia do setor industrial. A escolha deve-se ao fato de ser uma empresa atuante no mesmo mercado e desenhada nos mesmos moldes da empresa empregatícia do autor do trabalho, onde, entretanto, não foi possível a realização do estudo devido às restrições de confidencialidade e por possuir um Gerenciamento de Continuidade de Negócios bem desenvolvido. Fato este não comum no setor industrial e que também motivou a escolha deste perfil de empresa, uma vez que apenas 39% das empresas do segmento possuem um procedimento formalizado para análise de risco em TI (Módulo, 2007). 4.1 A Empresa A Ferrum Ind. e Com. Ltda. foi fundada em 1958, atua no setor da indústria metalúrgica e tem seu parque industrial instalado em Belo Horizonte/MG. Desde sua fundação, investe continuamente em pesquisa e no desenvolvimento de seus produtos, buscando oferecer a qualidade exigida e superar as expectativas de seus clientes. Para alcançar seus objetivos, a empresa possui em seu quadro funcional cerca de 1500 funcionários. O principal negócio da empresa é a produção de variados tipos de produtos em aço, como barras laminadas, perfis, arames, fios, pregos, telas, trilhos e tubos, etc., atendendo principalmente o mercado industrial e de construção civil. Sua participação no mercado interno é expressiva, mantendo-se sempre como uma das mais bem posicionadas em sua área de atuação. Os processos de negócios de produção operam no regime de 24 x 7 x 365 (continuamente), sendo altamente dependentes de seus sistemas de informação, o que faz com que a infra-estrutura de TI seja a base para estes e demais processos críticos da empresa, tornando-se uma das principais metas para a direção, a garantia de funcionamento contínuo dos principais sistemas de informação. 69. 69 Para fazer frente a este desafio, a empresa pretende desenvolver Plano(s) de Continuidade de Negócios, que permita(m) o restabelecimento o mais rápido possível dos sistemas de informação no caso da ocorrência de um desastre, minimizando os impactos causados pela interrupção de algum destes sistemas e consequentemente também em seus processos críticos. 4.2 Estrutura Tecnológica Sendo praticamente todos os processos de negócios da empresa informatizados, a o parque tecnológico da apresenta uma estrutura robusta, fazendo uso de diversos tipos de sistemas e serviços como Correio Eletrônico, Sistema Enterprise Resource Planning (ERP), Sistema Customer Relationship Management (CRM), Data Warehouse, Internet, Intranet, Antivírus, Servidor de Arquivos, Servidor de Impressão, além de outros sistemas desenvolvidos sob medida. Para prover estes serviços, a empresa possui atualmente 40 servidores instalados dentro de um Datacenter, além de cerca de 700 computadores Desktop utilizados pelos usuários dos sistemas. 4.3 Aplicação do Processo Proposto A aplicação do processo de Avaliação e Análise de Riscos teve início no dia 02/03/09 e término no dia 05/06/09. Os passos foram executados seguindo a agenda abaixo:  Passo 1 – Caracterização de Ativos: 02/03 a 06/04/09  Passo 2 – Análise de Ameaças: 06/04 a 20/04/09  Passo 3 – Identificação de Vulnerabilidades: 20/04 a 04/05/09  Passo 4 – Determinação de Probabilidades: 04/05 a 11/05/09  Passo 5 – Avaliação de Impacto: 11/05 a 29/05/09 70. 70  Passo 6 – Análise de Risco: 29/05 a 05/06/09 Foi escolhido como piloto para validação do processo o servidor SRVSAPPRD, considerado o mais importante dentre os ativos de TI da empresa, uma vez que sua missão é fornecer aos usuários de diferentes unidades da empresa o acesso ao sistema ERP, suportando os principais processos de negócio da empresa. Assim, no Passo 1, foi feito o levantamento de todas as informações relativas ao ativo, como configuração de hardware, software, as dependências do ativo, documentação relacionada, entre outras. Em síntese, foi feito o levantamento de todas as informações necessárias para prover aos próximos passos, os elementos necessários a sua realização. Para esse levantamento, foi definido um cronograma de trabalho a ser cumprido pelo analista responsável, conforme estabelecido no processo. Para auxiliar no levantamento das informações, foi entrevistado um dos administradores do sistema ERP que roda no servidor, sendo aplicado um questionário para orientar nas perguntas a serem feitas/respondidas. No passo 2, foi desenvolvida uma Declaração de Ameaças, contendo todas as potenciais ameaças identificadas para o ativo avaliado, sendo classificadas em três níveis: Real, Pouco Provável e Inexistente. As categorias em que foram divididas, conforme proposto no processo, foram em Humanas, Ambientais e Naturais. Para a execução do passo 3, foram utilizados dois métodos para o levantamento das vulnerabilidades: foram pesquisadas Fontes de Vulnerabilidades, para a identificação de falhas de segurança de software e atualização de hardware necessária. Com relação aos softwares, as pesquisas apontaram a existência de várias atualizações não aplicadas e que tornavam o ativo vulnerável a diversos tipos de ataques. Quanto ao hardware, apontaram também a desatualização de drivers e firmware, que além de comprometerem o desempenho do servidor, poderiam causar falhas críticas de funcionamento dos diversos componentes. Além disso, foi também aplicada uma Lista de Verificação de Exigências de Segurança, para identificar quais as necessidades mínimas de segurança exigidas para o ativo, e se existiam controles que satisfaziam essas necessidades. No passo 4, utilizando o levantamento das ameaças identificadas no passo 2 e das vulnerabilidades identificadas no passo 3, foi feito o cruzamento entre essas 71. 71 informações para se definir um nível de probabilidade do sucesso de uma das ameaças explorarem uma vulnerabilidade relacionada. Neste passo, a Lista de Verificação de Exigências de Segurança produzida no passo anterior, também foi utilizada para auxiliar na classificação das probabilidades. O passo 5, no qual ocorre a identificação dos impactos causados pela quebra dos princípios de segurança de confidencialidade, integridade e indisponibilidade, foi feito com a análise dos documentos produzidos nos passos anteriores, além de um Questionário de Avaliação de Impacto aplicado ao proprietário do ativo, para que esse determinasse o impacto de acordo com a sua consideração sobre o ativo. Por fim, em uma reunião entre os responsáveis pelo processo de Avaliação e Análise de Riscos e o proprietário do ativo, foi definido qual seria a real classificação dos impactos ao ativo. Encerrando o processo, o passo 6 produziu um Relatório de Análise de Risco, resultante do cruzamento da ameaça identificada, a probabilidade de sua ocorrência e o impacto resultante de sua concretização. Tal cruzamento resultou em uma quantificação do nível do risco a que o ativo está sujeito para cada uma das ameaças, sendo classificados como alto (8%), médio risco (77%) e baixo risco (15%). Assim, o Processo de Avaliação e Análise de Risco foi encerrado, apontando, através dos documentos produzidos, quais as ameaças a que o ativo está sujeito, as vulnerabilidades que podem ser exploradas por essas ameaças, as probabilidades de ocorrência e os impactos causados, que de acordo com os níveis que apresentem, tornam o nível do risco maior ou menor. Todos estes documentos produzidos durante a aplicação do processo são apresentados no Apêndice Q – Relatórios Produzidos no Estudo de Caso. Na avaliação dos responsáveis pelo processo de Gestão de Continuidade de Negócios, na pessoa do Gestor de Segurança e do Comitê Corporativo de Segurança, o processo foi considerado viável, de fácil execução, e eficiente e eficaz no cumprimento de sua proposta. 72. 72 5 CONCLUSÃO No presente trabalho, buscou-se desenvolver um processo sistematizado para a execução da etapa de Avaliação e Análise de Riscos, necessária para o desenvolvimento de um Plano de Continuidade de Negócios. Seu destaque justifica- se pela importância que ela assume ao ser responsável pelo levantamento das ameaças, vulnerabilidades, probabilidades e impactos aos quais os ativos de informação de uma organização possam estar sujeitos. O risco mensurado a partir do levantamento das variáveis acima, permitirá o desenvolvimento das melhores estratégias que irão garantir que incidentes com os ativos de informação da organização não causem interrupções que possam comprometer a continuidade de execução de seus principais processos de negócios. Busco-se ainda que o processo proposto fosse detalhado o suficiente para indicar quais as atividades a serem executadas em cada um dos passos em que foi dividida a Avaliação e Análise de Riscos. Este detalhamento permite que sua execução possa ser efetuada por pessoas que já compõem o quadro funcional da organização, não exigindo necessariamente especialistas em continuidade de negócios. Assim, o trabalho contribui para que a elaboração e implantação de Planos de Continuidade de Negócios seja um processo mais fácil de ser suportado por uma organização, sem a ocorrência de sobressaltos ou dificuldades que possam reduzir a sua capacidade de garantir segurança às informações da organização. 5.1 Trabalhos Futuros Como a elaboração do Plano de Continuidade de Negócios foi dividida em diferentes etapas, e o trabalho concentrou-se na etapa de Avaliação e Análise de Riscos, como extensão deste trabalho é sugerido o desenvolvimento de processos seguindo a mesma metodologia para as demais etapas, abrangendo a elaboração de um Plano de Continuidade de Negócios em sua totalidade, além da aplicação do processo em uma empresa real. 73. 73 6 REFERÊNCIAS BIBLIOGRÁFICAS ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 17799: Tecnologia da informação – Código de prática para a gestão da segurança da informação. Rio de Janeiro, 2002. AUSTRALIAN PRUDENTIAL REGULATORY AUTHORITY. Prudential Standard APS 232: Business Continuity Management. Disponível em: Acesso em: 10 jan. 2009. BRITISH STANDARDS INSTITUTE (BSI). BS 25999-1: Code of practice for business continuity management. Londres, 2006. DARYUS. Pesquisa sobre Continuidade de Negócios no Brasil - 2007/2008. São Paulo, 2008. Disponível em: Acesso em: 02 mai. 2009. EUROPEAN NETWORK AND INFORMATION SECURITY AGENCY (ENISA). Business and IT Continuity: Overview and Implementation Principles. [S.l.]: ENISA, 2008. FEDERAL EMERGENCY MANAGEMENT AGENCY (FEMA). FEMA 141: Emergency Management Guide for Business and Industry: A Step-by-Step Approach to Emergency Planning, Response and Recovery for Companies of All Sizes. Washington, 1993. FERREIRA, Fernando N. Freitas. Segurança da Informação. Rio de Janeiro: Ciência Moderna, 2003. GALLAGHER, Michael. Business Continuity Management: How to protect your company from danger. Londres: Pearson Education, 2003. 74. 74 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO); International Electrotechnical Commission (IEC). ISO/IEC 27001: Information technology - Security techniques - Information security management systems - Requirements. Geneva, 2005. IT GOVERNANCE INSTITUTE (ITGI). COBIT 4.1: Control Objectives for Information and related Technology. Rolling Meadows, 2007. KPMG. Preparedness of the Indian Industry: Survey on Business Continuity Management. Gurgaon: [S.n.], 2002 MADRID. Ministerio de Administraciones Públicas. MAGERIT versión 2: Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. 2006. MICROSOFT TECHNET. Introdução à Segurança da Informação. 2006. Disponível em: Acesso em: 13 jul. 2008. MÓDULO. 10ª Pesquisa Nacional de Segurança da Informação. 2006. Disponível em: Acesso em 02 mai. 2009. NATIONAL FIRE PROTECTION ASSOCIATION. NFPA 1600: Standard on Disaster/Emergency Management and Business Continuity Programs. Quincy, 2007. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Special Publication 800-30: Risk Management Guide for Information Technology Systems. Falls Church, 2002. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Special Publication 800-37: Guide for Security Authorization of Federal Information Systems. Gaithersburg, 2008. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Special Publication 800-53: Recommended Security Controls for Federal Information Systems and Organizations. Gaithersburg, 2009. 75. 75 OFFICE OF GOVERNMENT COMMERCE (OGC). ITIL v2: Information Technology Infrastructure Library. [S.l.], 2005. OLIVEIRA, Viviane Luciana de. Uma análise comparativa das metodologias de gerenciamento de risco FIRM, NIST SP 800-30 e OCTAVE. 2006. 180f. Dissertação (Mestrado em Computação) – Universidade Estadual de Campinas, Campinas. SÊMOLA, Marcos. Gestão da Segurança da Informação. 10ª reimpressão. Rio de Janeiro: Elsevier, 2003. SNEDAKER, Susan. Business Continuity & Disaster Recovery for IT Professionals. Burlington: Syngress, 2007. STANDARDS AUSTRALIA/STANDARDS NEW ZEALAND. HB 221: Business Continuity Management. 2004. Disponível em: Acesso em: 28 fev. 2009. STANDARDS AUSTRALIA/STANDARDS NEW ZEALAND. HB 292: A Practitioners Guide to Business Continuity Management. 2006. Disponível em: Acesso em: 28 fev. 2009. TEXAS DEPARTMENT OF INFORMATION RESOURCES. Business Continuity Planning Guidelines. Austin: [S.n.], 2004. THE BUSINESS CONTINUITY INSTITUTE (BCI). A Framework for Business Continuity Management. [S.l.], 2005. WALLACE, Michael; WEBBER, Lawrence. The disaster recovery handbook: a step-by-step plan to ensure business continuity and protect vital operations, facilities, and assets. New York: AMACOM, 2004. 76. 76 APÊNDICE A – Ficha de Atividades do Passo 1 Ficha de Atividades Nome do Passo: 1 – Caracterização de Ativos Nome da Atividade: 1 – Caracterizar Ativos Objetivo: Identificar os limites, recursos e informações de um ativo, reunindo as informações relacionadas ao mesmo, produzindo um Relatório de Avaliação de Ativos, com uma caracterização dos ativos, um quadro do ambiente em que se encontram e uma delineação dos seus limites, para elaboração de Planos de Continuidade de Negócios. Entrada(s): Documentos fornecidos pelo Gestor de Segurança/Analista de Segurança, como por exemplo:  Missão do ativo (Processos de negócio executados/suportados pelo ativo)  Documentação de hardware  Documentação de software  Documentação de interfaces (conectividade interna e externa)  Pessoas que suportam e usam o ativo  Dados e informações armazenados/manipulados  Criticidade dos dados e ativos (valor do ativo ou sua importância para a organização)  Sensibilidade dos dados e ativos (nível de proteção requerido para manter a confidencialidade, integridade e disponibilidade)  Políticas de segurança implementadas 77. 77  Controles de administração utilizados  Controles operacionais (políticas de backup, manutenção, normas e procedimentos empregados)  Descrição e documentação da segurança física (controle de acesso) e ambiental (controles de umidade, água, energia, poluição, etc.)  Relatórios fornecidos por Ferramentas Automatizadas Sendo esse o início do processo, estes documentos serão fornecidos de acordo com sua existência, que dependerá do nível de registro exigido, da documentação existente, e do histórico da organização. Isso implica que nem todos podem estar disponíveis, e outros poderão ser acrescidos à lista acima, variando conforme o caso. Saída(s):  Relatório de Avaliação de Ativos  Cronograma das Atividades – Passo 1: Avaliação de Ativos  Questionário de Informações de Ativos Papel Responsável:  Gestor de Segurança Papel(is) Envolvido(s):  Comitê Corporativo de Segurança  Analista(s) de Segurança  Administrador(es) do ativo  Usuário(s) do ativo 78. 78 Descrição da Atividade: 1. Preparação 1.1. O Gestor de Segurança reúne o Comitê Corporativo de Segurança para definir quais serão os métodos a serem utilizados para levantamento das informações necessárias para a caracterização dos ativos. 1.2. O Comitê define quais os ativos a serem avaliados com base na sua importância e relação com os processos de negócios da organização. 1.3. O Gestor de Segurança elabora um cronograma para o Analista de Segurança, com os ativos a serem avaliados e as datas a serem cumpridas para o levantamento de todas as informações. 1.4. O Analista de Segurança recebe o cronograma de trabalho, e faz uma primeira avaliação dos ativos a serem avaliados. Durante essa fase de preparação o Analista de Segurança desenvolve um Questionário para coleta de informações dos ativos, e agenda reuniões para serem feitas entrevistas com os Administradores, Usuários e demais indivíduos que estejam diretamente envolvidos com o ativo a ser avaliado. 2. Coleta de Informações 2.1. O Analista de Segurança reúne toda a documentação existente e disponível sobre o ativo avaliado e faz um mapeamento de todas as informações que considera importantes. 2.2. Caso julgue necessário e adequado, o Analista de Segurança fará uso de Ferramentas Automatizadas para a coleta de informações, que forneçam dados de forma eficaz e precisa. 3. Elaboração do Relatório de Avaliação 3.1. De posse de todas as informações já levantadas, o Analista de Segurança inicia a elaboração da versão inicial do Relatório de Avaliação de Ativos, tabulando os dados existentes, e descrevendo a 79. 79 caracterização dos ativos, um quadro do ambiente em que se encontram e uma delineação dos seus limites. 4. Entrevistas 4.1. Nas datas marcadas, o Analista de Segurança se reúne com os Administradores do ativo, Usuários e demais indivíduos para fazer uma entrevista e/ou visita in loco a fim de levantar mais informações sobre o ativo e que ainda não tenham sido identificadas. 5. Conclusão 5.1. O Analista de Segurança conclui o Relatório de Avaliação de Ativos, no qual estará descrita uma completa caracterização dos ativos, um quadro do ambiente em que se encontram e uma delineação dos seus limites. O Analista de Segurança o apresenta para o Gestor de Segurança. 5.2. Após análise e validação do documento produzido, o Gestor de Segurança reúne o Comitê Corporativo de Segurança para apresentar o Relatório de Avaliação de Ativos. Se aprovado por todos, declara a atividade concluída, de posse de um Relatório de Avaliação de Ativos. 80. 80 APÊNDICE B – Ficha de Atividades do Passo 2 Ficha de Atividades Nome do Passo: 2 – Análise de Ameaças Nome da Atividade: 1 – Identificação de Ameaças Objetivo: Identificar as ameaças potenciais e compilar uma Declaração de Ameaças que liste as potenciais ameaças aplicáveis para o ativo avaliado. Entrada(s): Documentos que foram produzidos nos passos anteriores, e obrigatórios para a continuidade do processo, sendo fornecidos pelo Gestor de Segurança/Analista de Segurança:  Relatório de Avaliação de Ativos Exemplos de outros documentos que podem ser fornecidos de acordo com sua existência, que dependerá do nível de registro exigido, da documentação existente, e do histórico da organização. Isso implica que nem todos podem estar disponíveis, e outros poderão ser acrescidos à lista abaixo, variando conforme o caso:  Relatórios de paradas de sistemas  Relatórios de violação de segurança  Relatórios de incidentes  Documentos de fontes externas de informações de ameaças  Relatórios de entrevistas 81. 81 Saída(s):  Declaração de Ameaças Papel Responsável:  Gestor de Segurança Papel(is) Envolvido(s):  Comitê Corporativo de Segurança  Analista de Segurança Descrição da Atividade: 1. Preparação 1.1. Ao iniciar a fase de Análise de Ameaças, o Gestor de Segurança reúne todos os documentos disponíveis, incluindo os relatórios de avaliação de ativos, relatórios de histórico de paradas de sistemas, de violações de segurança já ocorridas, incidentes já registrados, entre outros, existentes e que estejam disponíveis e os envia ao Analista de Segurança para que possam ser estudados. 1.2. O Analista de Segurança estuda os documentos recebidos e pesquisa outras informações que julgar relevantes sobre os ativos a serem suportados pelo PCN. 1.3. O Analista de Segurança faz um levantamento da existência de ocorrências anteriores de ameaças naturais relacionadas ao ambiente do ativo, e que ainda tenham possibilidade de se concretizarem, através de fontes do governo e de organizações privadas especializadas. 1.4. Durante essa fase de preparação o Analista de Segurança inicia a elaboração da Declaração de Ameaças. 82. 82 2. Coleta de informações 2.1. O Analista de Segurança inicia a coleta de informações através de pesquisas junto a fornecedores, representantes da indústria, organizações especializadas, a fim de levantar mais informações que possam indicar possíveis ameaças ainda não identificadas, que sejam de conhecimento geral e estejam relacionadas ao ativo analisado. 3. Conclusão 3.1. O Analista de Segurança redige o documento final, no qual estarão descritas todas as ameaças identificadas para os ativos avaliados e o apresenta para o Gestor de Segurança. 3.2. Após análise e validação do documento produzido, o Gestor de Segurança reúne o Comitê Corporativo de Segurança, para apresentar a Declaração de Ameaças. Se aprovada por todos, declara a atividade concluída, de posse de uma Declaração de Ameaças, que contém uma lista de ameaças que poderiam explorar vulnerabilidades dos ativos avaliados. 83. 83 APÊNDICE C – Ficha de Atividades do Passo 3 Ficha de Atividades Nome do Passo: 3 – Identificação de Vulnerabilidades Nome da Atividade: 1 – Identificar vulnerabilidades do ativo Objetivo: Identificar vulnerabilidades (falhas ou fraquezas) que podem ser exploradas por potenciais ameaças aplicáveis para o ativo avaliado e desenvolver uma Lista de Vulnerabilidades. Entrada(s): Documentos que foram produzidos nos passos anteriores, e obrigatórios para a continuidade do processo, sendo fornecidos pelo Gestor de Segurança/Analista de Segurança:  Relatórios de Avaliação de Ativos  Declaração de Ameaças Exemplos de outros documentos que podem ser fornecidos de acordo com sua existência, que dependerá do nível de registro exigido, da documentação existente, e do histórico da organização. Isso implica que nem todos podem estar disponíveis, e outros poderão ser acrescidos à lista abaixo, variando conforme o caso:  Documentação existente de Avaliações de Riscos já realizadas  Relatórios de Auditorias  Relatórios de Revisão de Segurança  Relatórios de Anomalias do Ativo 84. 84  Listas de Vulnerabilidades, de organismos especializados em segurança  Boletins de segurança de fabricantes (hardware/software)  Relatórios de equipes de resposta e fóruns de discussão  Relatórios de softwares de análise de segurança  Relatórios fornecidos por Ferramentas Automatizadas  Relatórios de testes de segurança do ativo Saída(s):  Lista de Vulnerabilidades  Relatório de Testes de Segurança (se aplicado)  Lista de Verificação de Exigências de Segurança Papel Responsável:  Gestor de Segurança Papel(is) Envolvido(s):  Comitê Corporativo de Segurança  Analista(s) de Segurança Descrição da Atividade: 1. Preparação 1.1. Na fase de Análise de Vulnerabilidades, o Gestor de Segurança reúne o Comitê Corporativo de Segurança para definir se serão empregados Testes de Segurança, e caso positivo, quais serão os utilizados para levantamento das vulnerabilidades do ativo, considerando para isso, a criticidade do ativo e os recursos disponíveis para o teste. Os Testes de 85. 85 Segurança a serem empregados podem ser formados por um ou uma combinação dos seguintes métodos:  Ferramentas de verificação automática de vulnerabilidades  Testes de avaliação e segurança  Testes de penetração 1.2. O Gestor de Segurança reúne todos os documentos já disponíveis, incluindo os relatórios de Avaliação de Ativo, Declaração de Ameaças, e demais relatórios e os envia ao Analista de Segurança para que possam ser estudados. 1.3. Caso tenha se optado pela realização de Testes de Segurança, o Gestor de Segurança informa ao Analista de Segurança, qual ou quais testes deverão ser empregados. 1.4. O Analista de Segurança estuda os documentos recebidos e pesquisa fontes adicionais, a fim de buscar informações que julgar relevantes e ainda não identificadas sobre vulnerabilidades dos ativos analisados. A lista abaixo apresenta uma relação de possíveis fontes a serem consultadas, devendo o Analista de Segurança não se limitar a ela e considerar outras que não estejam relacionadas:  Listas de vulnerabilidades divulgadas  Boletins de Segurança  Boletins de fabricantes  Equipes comerciais de resposta a incidentes/emergências de computador e fóruns de discussão (por exemplo, SecurityFocus.com)  Informações seguras e alertas e boletins de vulnerabilidades para sistemas militares  Softwares de análises de segurança de sistemas 1.5. Durante essa fase de preparação, o Analista de Segurança inicia a elaboração da Lista de Vulnerabilidades. 86. 86 2. Caso tenha se optado pela realização de Testes de Segurança 2.1. O Analista de Segurança inicia os Testes de Segurança estipulados anteriormente pelo Comitê Corporativo de Segurança. 2.2. O Analista de Segurança produz um Relatório de Testes, descrevendo quais os testes e sob quais condições foram executados, além dos resultados obtidos. 2.3. O Analista de Segurança analisa os dados produzidos pelos Testes de Segurança, identificando as reais vulnerabilidades encontradas e descartando falsos positivos que não representem uma vulnerabilidade no contexto do ativo avaliado, incluindo as vulnerabilidades encontradas na Lista de Vulnerabilidades. 3. Desenvolvimento da Lista de Verificação de Exigências de Segurança 3.1. O Analista de Segurança desenvolve uma Lista de Verificação de Exigências de Segurança, a fim de verificar se padrões básicos de segurança estão presentes no ativo avaliado. Devem ser incluídas pessoas, processos, procedimentos, ambiente, etc. que estejam relacionados ao ativo para se fazer a verificação. 3.2. O Analista de Segurança relaciona os itens não conformes e necessários, que tenham sido identificados pela aplicação da Lista de Verificação de Exigências de Segurança. 4. Conclusão 4.1. O Analista de Segurança redige o documento final, no qual estará descrita uma Lista de Vulnerabilidades dos ativos avaliados, e o apresenta para o Gestor de Segurança. Após análise e validação do documento produzido, o Gestor de Segurança reúne o Comitê Corporativo de Segurança, para apresentar a Lista de Vulnerabilidades. Sendo aprovada por todos, declara a atividade concluída, de posse de uma Lista de Vulnerabilidades dos ativos, que poderiam ser exploradas por ameaças potenciais. 87. 87 APÊNDICE D – Ficha de Atividades do Passo 4 Ficha de Atividades Nome do Passo: 4 – Determinação de Probabilidades Nome da Atividade: 1 – Determinar probabilidade de exploração de vulnerabilidades Objetivo: Indicar qual a probabilidade de uma potencial vulnerabilidade ser explorada por potenciais ameaças para o ativo avaliado, desenvolvendo um Relatório de Avaliação de Probabilidades. Entrada(s): Documentos que foram produzidos nos passos anteriores, e obrigatórios para a continuidade do processo, sendo fornecidos pelo Gestor de Segurança/Analista de Segurança:  Relatórios de Avaliação de Ativos  Declaração de Ameaças  Lista de Vulnerabilidades  Lista de Verificação de Exigências de Segurança Saída(s):  Relatório de Avaliação de Probabilidades Papel Responsável:  Gestor de Segurança 88. 88 Papel(is) Envolvido(s):  Comitê Corporativo de Segurança  Analista(s) de Segurança Descrição da Atividade: 1. Preparação 1.1. O Gestor de Segurança reúne os documentos produzidos nos passos executados anteriormente, que correspondem ao Relatório de Avaliação de Ativos, a Declaração de Ameaças, a Lista de Vulnerabilidades e a Lista de Verificação de Exigências de Segurança e os envia ao Analista de Segurança para que possam ser estudados. 2. Elaboração do Relatório de Avaliação de Probabilidades 2.1. O Analista de Segurança estuda os documentos recebidos e faz um mapeamento entre ativos, ameaças e vulnerabilidades, considerando a origem e motivação da ameaça, a natureza da vulnerabilidade e os controles existentes para cada ativo avaliado. A origem e motivação das ameaças serão mensuradas avaliando-se o contexto em que o ativo encontra-se inserido. A natureza da vulnerabilidade será baseada na Lista de Vulnerabilidades, e os controles existentes serão identificados na Lista de Verificação de Exigências, ambos produzidos no passo anterior. 2.2. O Analista de Segurança faz uma atribuição de valores para as probabilidades de exploração por potenciais ameaças de cada vulnerabilidade identificada para os ativos analisados, classificando-as como alta, média ou baixa. 89. 89 3. Conclusão 3.1. O Analista de Segurança redige o documento final, que contém a probabilidade de cada vulnerabilidade ser explorada por uma potencial ameaça e sua devida classificação, apresentando ao Gestor de Segurança um Relatório de Avaliação de Probabilidades. 3.2. Após análise e validação do documento produzido, o Gestor de Segurança reúne o Comitê Corporativo de Segurança, para apresentar o Relatório de Avaliação de Probabilidades. Sendo aprovada por todos, declara a atividade concluída, de posse de um Relatório de Avaliação de Probabilidades. 90. 90 APÊNDICE E – Ficha de Atividades do Passo 5 Ficha de Atividades Nome do Passo: 5 – Avaliação de Impacto Nome da Atividade: 1 – Avaliar o impacto de um incidente Objetivo: Mensurar o impacto adverso causado no ambiente resultante da exploração de uma potencial vulnerabilidade de um ativo por uma potencial ameaça, desenvolvendo um Relatório de Avaliação de Impacto. Entrada(s): Documentos que foram produzidos nos passos anteriores, e obrigatórios para a continuidade do processo, sendo fornecidos pelo Gestor de Segurança/Analista de Segurança:  Relatórios de Avaliação de Ativos  Declaração de Ameaças  Lista de Vulnerabilidades Saída(s):  Relatório de Avaliação de Impacto  Questionário de Avaliação de Impacto Papel Responsável:  Gestor de Segurança 91. 91 Papel(is) Envolvido(s):  Comitê Corporativo de Segurança  Analista(s) de Segurança  Proprietários dos ativos avaliados Descrição da Atividade: 1. Preparação 1.1. O Gestor de Segurança reúne os documentos produzidos nos passos executados anteriormente, e os envia ao Analista de Segurança para que possam ser estudados. 1.2. O Analista de Segurança agenda reuniões para serem feitas entrevistas com os proprietários dos ativos para que estes possam determinar o exato nível de impacto causado no caso da ocorrência de um incidente. 2. Elaboração do Relatório de Avaliação de Impacto 2.1. O Analista de Segurança estuda os documentos recebidos e faz o agrupamento dos ativos avaliados em função de sua natureza e sua relação com os processos de negócios. 2.2. O Analista de Segurança desenvolve um Questionário de Avaliação de Impacto com o objetivo de definir quais as prioridades de contingência e quais os níveis de tolerância à indisponibilidade dos ativos avaliados, a ser respondido pelos proprietários dos ativos. 3. Aplicação dos Questionários 3.1. O Analista de Segurança submete aos proprietários dos ativos o Questionário de Avaliação de Impacto. 3.2. O Analista de Segurança recebe de volta os questionários e inicia a elaboração do Relatório de Avaliação de Impacto. 92. 92 4. Entrevistas 4.1. Nas datas marcadas, são feitas as reuniões, estando presentes o Gestor de Segurança, o Analista de Segurança, os integrantes do Comitê Corporativo de Segurança e os proprietários dos ativos. 4.2. Com base nas respostas obtidas nos questionários são definidos os impactos da possível ocorrência de um incidente ao ativo avaliado em termos qualitativos e quando possível, quantitativamente. 5. Conclusão 5.1. O Analista de Segurança redige o documento final, que contém a classificação do impacto causado pela ocorrência de um incidente, como alto, médio ou baixo, apresentando ao Gestor de Segurança um Relatório de Avaliação de Impacto. 5.2. Após análise e validação do documento produzido, o Gestor de Segurança reúne o Comitê Corporativo de Segurança, para apresentar o Relatório de Avaliação de Impacto, e sendo aprovado por todos, declara a atividade concluída, de posse de um Relatório de Avaliação de Impacto. 93. 93 APÊNDICE F – Ficha de Atividades do Passo 6 Ficha de Atividades Nome do Passo: 6 – Análise de Risco Nome da Atividade: 1 – Determinar o nível de risco Objetivo: Determinar o nível de risco do ativo avaliado para um par ameaça/vulnerabilidade, em função da probabilidade de ocorrência, o impacto causado e os controles existentes, desenvolvendo um Relatório de Análise de Risco. Entrada(s): Documentos que foram produzidos nos passos anteriores, e obrigatórios para a continuidade do processo, sendo fornecidos pelo Gestor de Segurança/Analista de Segurança:  Relatório de Avaliação de Ativos  Declaração de Ameaças  Lista de Vulnerabilidades  Relatório de Avaliação de Probabilidades  Relatório de Avaliação de Impacto Saída(s):  Relatório de Análise de Risco Papel Responsável:  Gestor de Segurança 94. 94 Papel(is) Envolvido(s):  Comitê Corporativo de Segurança  Analista(s) de Segurança Descrição da Atividade: 1. Preparação 1.1. O Gestor de Segurança reúne os documentos produzidos nos processos executados anteriormente e os envia ao Analista de Segurança para que possam ser estudados. 2. Elaboração do Relatório de Análise de Risco 2.2. O Analista de Segurança estuda os documentos recebidos e desenvolve uma matriz de risco, derivada a partir da avaliação de probabilidade e avaliação de impacto da ocorrência de um incidente, para cada um dos ativos avaliados, definindo assim o nível de risco. 3. Conclusão 3.1. O Analista de Segurança redige o documento final, que contém a classificação do risco, definido como alto, médio ou baixo, da exploração de vulnerabilidades por potenciais ameaças para cada ativo avaliado, apresentando ao Gestor de Segurança um Relatório de Análise de Risco. 3.2. Após análise e validação do documento produzido, o Gestor de Segurança reúne o Comitê Corporativo de Segurança para apresentar o Relatório de Análise de Risco, e sendo aprovado por todos, declara a atividade concluída, de posse de um Relatório de Análise de Risco. 95. 95 APÊNDICE G – Relatório de Avaliação de Ativo Data: Responsável: Versão: Status: Identificação do ativo: _______________________________________________ Missão do ativo: __________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ Criticidade do ativo: _____ Alta _____ Média _____ Baixa Sensibilidade do ativo: _____ Alta _____ Média _____ Baixa Proprietário: _______________________________________________________ Processos de Negócio suportados: _____________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ Dependências (Entrada): _____________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ Dependências (Saída): ______________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 96. 96 Hardware Fabricante Fornecedor Modelo Nº. Série Quantidade de Processadores Quantidade de Memória RAM Garantia Tipo de Suporte Software Fabricante/Desenvolvedor Fornecedor Software Nº. Licença Versão Service Pack Interfaces/Conectividade Interfaces Modelo Velocidade IP Mac Address Equipamentos Modelo Identificação Porta Velocidade Usuários/Administradores Usuários Administradores Armazenamento Partição Tamanho Finalidade Localização 97. 97 Dados/Informações Armazenados Tipo/Descrição Criticidade (Alta/Média/Baixa) Sensibilidade (Alta/Média/Baixa) Tipo/Descrição Criticidade (Alta/Média/Baixa) Sensibilidade (Alta/Média/Baixa) Backup Diretórios/Arquivos Contemplados Tipo Periodicidade Retenção Tipo de Mídia Quantidade de Mídia (s) Procedimento Local de Guarda Diretórios/Arquivos Contemplados Tipo Periodicidade Retenção Tipo de Mídia Quantidade de Mídia (s) Procedimento Local de Guarda Localização Prédio Sala Controle de Acesso Controle de Temperatura Controle de Umidade Controle de Poluição Prevenção contra Incêndio Prevenção contra Inundação Prevenção contra Falta de Energia 98. 98 Documentos Relacionados Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização 99. APÊNDICE H – Cronograma de Atividades Passo: __________________________________________________________________________________________ Data Início: _____/ _____/ _____ Data Fim: _____/ _____/ _____ Envolvidos: ______________________________________________________________________________________ ________________________________________________________________________________________________ ID Nome da Tarefa/Atividade Responsável Mês 01 Mês 02 Mês 03 Semana Semana Semana 1 2 3 4 1 2 3 4 1 2 3 4 Obs.: Substituir os campos Mês e Número da Semana com a data apropriada. 100. 100 APÊNDICE I – Questionário de Informações de Ativos Ativo avaliado: _____________________________________________________ Data: _____/ _____/ _____ Entrevistador: _____________________________________________________ Entrevistado: ______________________________________________________ Cargo: ___________________________________________________________ Departamento: _____________________________________________________  Qual é a missão do ativo na Organização/Unidade de Negócio? ________________________________________________________________  Quantos são os usuários válidos do ativo? ________________________________________________________________  Existe monitoração/auditoria do uso e acesso ao ativo? ________________________________________________________________  Quem são os responsáveis pelo manutenção/suporte do ativo? ________________________________________________________________  Qual tipo de informação é processada e armazenada pelo ativo (por exemplo, financeira, pessoal, médica, operacional, produção, etc.)? ________________________________________________________________  Quais as informações são geradas, consumidas, processadas, armazenadas, e retornadas pelo ativo? ________________________________________________________________  Quão importante são essas informações à missão da Organização/Unidade de Negócio? ________________________________________________________________  Quais são os fluxos dessas informações? ________________________________________________________________  Qual é o nível de classificação de sensibilidade dessas informações? (Não Considerável, Relevante, Importante, Crítica, Vital) ________________________________________________________________ 101. 101  Existem controles de acesso a essas informações? ________________________________________________________________  Quais são os tipos de armazenamento dessas informações? ________________________________________________________________  Qual o efeito na missão da Organização/Unidade de Negócio se o ativo não estiver seguro? ________________________________________________________________  Um mau funcionamento, falha de segurança ou indisponibilidade do ativo poderiam resultar em ferimentos ou morte? ________________________________________________________________  Existem registros de incidentes ocorridos anteriormente que causaram a indisponibilidade do ativo? ________________________________________________________________  Existem procedimentos documentados de operação, manutenção, suporte ao ativo? ________________________________________________________________  As operações de manutenção, alteração, atualização do ativo são feitas através de procedimentos formalizados de Gestão de Mudanças? ________________________________________________________________  Existe algum tipo de seguro contra roubo, furto, incêndio ou desastre natural para o ativo? ________________________________________________________________  Existem prestadores de serviço terceirizados para operação, suporte, manutenção do ativo? ________________________________________________________________  Os contratos de suporte/manutenção para o ativo prevêem o cumprimento de SLA por parte dos fornecedores? ________________________________________________________________  Existe processo de capacitação/treinamento para os administradores e usuários do ativo? ________________________________________________________________ 102. 102 Perguntas adicionais a serem incluídas:  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________ Observações relevantes fornecidas durante a entrevista: ____________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 103. 103 APÊNDICE J – Declaração de Ameaças Data: Responsável: Versão: Status: Identificação do ativo: _______________________________________________ Preencher o quadro abaixo assinalando a classificação que mais se aproxime da possibilidade de existência da ameaça citada para o ativo. Relacionar outras ameaças que não tenham sido mencionadas: Categoria Classificação Real Pouco Provável Inexistente Humanas Terrorismo – Explosivo Terrorismo – Químico Terrorismo – Biológico Terrorismo – Radiológico Terrorismo – Nuclear Terrorismo – Cyber Sabotagem Espionagem Distúrbio civil – Histeria Distúrbio civil – Revolta Guerra Atividade Criminosa – Vandalismo Atividade Criminosa – Incêndio Provocado Atividade Criminosa – Roubo Atividade Criminosa – Fraude Atividade Criminosa – Roubo de Dados Greve Falha não intencional 104. 104 Categoria Classificação Real Pouco Provável Inexistente Ambientais Falha de Hardware Falha de Software Falha de Conectividade Falha no Fornecimento de Energia Falha no Controle de Temperatura Interferências eletromagnéticas Vazamento de Material – Químico Vazamento de Material – Radioativo Fogo Explosão Inundação Desabamento Poluição Proximidade de Aeroportos Naturais Terremoto Tsunami Vulcão Deslizamento de Terra Enchente Temperaturas Extremas Seca Fogo Neve Gelo Granizo Avalanche Ventania Furacão Ciclone Tornado Queda de Raios Infestação de Pragas/Insetos 105. 105 APÊNDICE K – Lista de Vulnerabilidades Data: Responsável: Versão: Status: Identificação do ativo: _______________________________________________ Ameaça Vulnerabilidade Comentário 106. 106 APÊNDICE L – Lista de Verificação de Exigências de Segurança1 Data: Responsável: Versão: Status: Identificação do ativo: _______________________________________________ Requisito de Segurança Exigido Conforme Sim Não Sim Não Controle de Acesso Política e procedimentos de controle de acesso Administração de contas Separação de responsabilidades Privilégios mínimos Notificação de uso de sistema Controle de sessão simultânea Bloqueio de sessão Encerramento de sessão Supervisão e revisão de controle de acesso Controle de acesso remoto Restrições de acesso sem fios Controle de acesso para dispositivos portáteis e móveis Conscientização e Treinamento Política e procedimentos de divulgação e treinamento de segurança Divulgação de segurança Treinamento de segurança Contatos com Grupos e Associações de Segurança Auditoria e Responsabilidades Política e procedimentos de auditoria e responsabilidades Eventos de auditoria Registros de conteúdo de auditorias Certificação, Credenciamento e Avaliações de Segurança Políticas e procedimentos de certificação, credenciamento e avaliação de segurança Avaliações de segurança Certificação de segurança Credenciamento de segurança Gerenciamento de Configuração Política e procedimentos de administração de configuração Linha base de configuração Controle de mudança de configuração Restrições de acesso para mudança Inventário de informação de componente de sistema 1 Baseado em NIST, 2009. 107. 107 Requisito de Segurança Exigido Conforme Sim Não Sim Não Plano de Contingência Políticas e procedimentos de plano de contingência Treinamento de contingência Teste de contingência Atualização de plano de contingência Local de armazenamento alternativo Local de processamento alternativo Backup de informação de sistema Recuperação e reconstituição de informação de sistema Identificação e Autenticação Políticas e procedimentos de identificação e autenticação Identificação e autenticação de usuário Identificação e autenticação de dispositivo Resposta a Incidentes Políticas e procedimentos de resposta a incidente Treinamento de resposta a incidente Monitoração de incidente Assistência de resposta de incidente Manutenção Políticas e procedimentos de manutenção de sistema Manutenção controlada Ferramentas de manutenção Manutenção remota Proteção de Mídia Políticas e procedimentos de Proteção de mídia Acesso de mídia Rotulagem de mídia Armazenamento de mídia Transporte de mídia Proteção Ambiental e Física Políticas e procedimentos de proteção física e ambiental Controle de acesso físico Monitoramento de acesso físico Controle de visita Registros de acesso Energia de emergência Iluminação de emergência Proteção contra incêndio Controles de temperatura e de umidade Proteção de dano de água Local de trabalho alternativo Planejamento Políticas e procedimentos de planejamento de segurança Plano de segurança de sistema Atualização de plano de segurança de sistema Regras de comportamento 108. 108 Requisito de Segurança Exigido Conforme Sim Não Sim Não Segurança Pessoal Políticas e procedimentos de segurança de pessoal Categorização de posição Transferência de pessoal Segurança de pessoal de terceiro Sanções de pessoal Aquisição de Sistemas e Serviços Políticas e procedimentos de aquisição de sistemas e serviços Alocação de recursos Documentação de informação de sistema Restrições de uso de software Administração de configuração Administração de testes de segurança Proteção de Sistemas e Comunicação Políticas e procedimentos de proteção de comunicações Separação de aplicação Proteção de negação de serviço Integridade de transmissão Confidencialidade de transmissão Estabelecimento e administração de chave criptográfica Uso de criptografia Proteções de acesso público Nome seguro / Serviço de resolução de endereço (Fonte autorizada) Autenticidade de sessão Integridade de Sistemas e Informações Políticas e procedimentos de integridade de sistemas e informações Proteção contra código malicioso Técnicas e ferramentas de monitoração de sistema de informação Alertas de segurança Verificação de funcionalidade de segurança Integridade de software e informação Proteção contra Spam Restrições de introdução de informações Precisão, perfeição, validade e autenticidade de informação Tratamento de erro Tratamento e retenção de informações produzidas 109. 109 APÊNDICE M – Avaliação de Probabilidades Data: Responsável: Versão: Status: Identificação do ativo: _______________________________________________ Ameaça Vulnerabilidade Probabilidade Alta Média Baixa 110. 110 APÊNDICE N – Relatório de Avaliação de Impacto Data: Responsável: Versão: Status: Identificação do ativo: _______________________________________________ Ameaça Impacto Alto Médio Baixo 111. 111 APÊNDICE O – Questionário de Avaliação de Impacto2 Data: _____/ _____/ _____ Identificação do ativo: _______________________________________________ Descrição: ________________________________________________________ _________________________________________________________________ Proprietário: _______________________________________________________ Ativos Dependentes (Entrada): ________________________________________ _________________________________________________________________ Ativos Dependentes (Saída): __________________________________________ _________________________________________________________________ 1. A perda deste ativo causaria o seguinte efeito à organização: _____ A. Efeito catastrófico na organização ou algumas divisões _____ B. Efeito catastrófico em uma divisão _____ C. Efeito moderado na organização ou algumas divisões _____ D. Efeito moderado em uma divisão _____ E. Efeito secundário na organização ou algumas divisões 2. Quanto tempo os processos de negócio dependentes deste ativo continuariam funcionando sem seu apoio? Assuma que a perda do ativo acontece durante o período de pico ou maior utilização. Marque somente uma opção: _____ Horas _____ Até 1 semana _____ Até 1 dia _____ Até 1 mês _____ Até 2 dias _____ Outro (Por favor, especifique) ____________________ _____ Até 3 dias 2 Baseado em Texas Department of Information Resources, 2004. 112. 112 3. Indique o pico de utilização no(s) mês(s) de um ano, e/ou o(s) dia(s) de um mês ou semana, e/ou a(s) hora(s) mais críticas de um dia, para este ativo: Mês J F M A M J J A S O N D Dia/Mês 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Dia/Semana S T Q Q S S D Hora 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 4. Há qualquer outro pico de utilização ou situações consideradas de tensão? _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 5. Foi desenvolvido/estabelecido qualquer procedimento posterior (manual ou de outra forma) a ser utilizado para dar continuidade aos processos de negócio dependentes caso um incidente torne este ativo indisponível? ________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ Se sim, esses procedimentos foram testados? _____ Sim, dentro dos últimos 6 meses _____ Sim, dentro do último ano _____ Sim, mas há mais de um ano atrás. Quando? _______________ _____ Não 113. 113 Use os seguintes códigos alfabéticos para responder às questões 6, 7, e 8: A = Acima de R$ 10.000.000,00 B = De R$ 1.000.000,00 a R$ 10.000.000,00 C = De R$ 100.000,00 a R$ 1.000.000,00 D = De R$ 10.000,00 a R$ 100.000,00 E = Abaixo de R$ 10.000,00 6. A indisponibilidade deste ativo resultaria em perdas financeiras por falta de arrecadação, faturamento, etc. Durante o tempo indicado após o desastre, esta perda seria correspondente à: _____ Horas ___ _____ Dia 1 _____ Dia 2 _____ Dia 4 _____ Semana 1 _____ Mês 1 Outro ______________________ 7. A indisponibilidade deste ativo desgastaria a base de clientes após um período de tempo. O custo para a organização, referente a negócios perdidos, depois do tempo indicado, seria: _____ Horas ___ _____ Dia 1 _____ Dia 2 _____ Dia 4 _____ Semana 1 _____ Mês 1 Outro ______________________ 8. A indisponibilidade deste ativo resultaria em multas e penalidades devido a exigências regulatórias (federal, estadual, local, por força de contratos, etc.). O total destas taxas, depois do tempo indicado, seria: _____ Horas ___ _____ Dia 1 _____ Dia 2 _____ Dia 4 _____ Semana 1 _____ Mês 1 Outro ______________________ 9. A indisponibilidade deste ativo teria as seguintes implicações legais impostas por estatutos reguladores, exigências de acionistas, ou acordos contratuais: (Especifique a área de exposição) ________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 114. 114 10. A indisponibilidade deste ativo causaria o seguinte impacto negativo ao pessoal da organização: ____________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 11. A indisponibilidade deste ativo impediria de prover os seguintes serviços a clientes externos: __________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 12. Especifique qualquer outro fator que deve ser considerado ao se avaliar o impacto da indisponibilidade deste ativo: ________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 13. Existe qualquer outra dependência (equipes, vendedor, hardware, software, recursos exclusivos, etc.) ainda não identificada acima? ____________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 14. Uma análise das respostas às perguntas anteriores indica que este ativo deveria ser considerado como "vital" para a organização? Se sim, indique abaixo qual rótulo é o mais apropriado: ___ Sempre ___ Durante o seguinte período do ano: ______________ ___ Durante o seguinte período do mês: _____________ ___ Durante o seguinte período da semana: __________ ___ Outro período de tempo. Especifique: _______________________________ 115. 115 APÊNDICE P – Relatório de Análise de Risco Data: Responsável: Versão: Status: Identificação do ativo: _______________________________________________ Ameaça Probabilidade x Impacto = Peso do Risco Baixa = 0.1 Média = 0.5 Alta = 1.0 Baixo = 10 Médio = 50 Alto = 100 Baixo = 1 a 10 Médio = 11 a 50 Alto = 51 a 100 x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = 116. 116 APÊNDICE Q – Relatórios Produzidos no Estudo de Caso Relatório de Avaliação de Ativo Data: 03/04/2009 Responsável: Marcelo Veloso Versão: 1.0 Status: Final Identificação do ativo: SRVSAPPRD ____________________________________ Missão do ativo: Cluster do ambiente de produção SAP R/3 PRD com banco de_ dados Oracle e aplicação SAP. O nó é o Owner do Cluster Group e Central _____ Instance do SAP ___________________________________________________ _________________________________________________________________ Criticidade do ativo: __X__ Alta _____ Média _____ Baixa Sensibilidade do ativo: __X__ Alta _____ Média _____ Baixa Proprietário: Álvaro Martins (Superintendente de TI) _______________________ Processos de Negócio suportados: Contabilidade e Finanças, Recursos Humanos, Produção Siderúrgica, Produção Laminação, Manutenção e Utilidades, Controle de Gestão, Planejamento e Logística ______________________________________ _________________________________________________________________ Dependências (Entrada): Não existe ____________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ Dependências (Saída): Data Warehouse, Sistema MES (Chão-de-Fábrica) _____ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 117. 117 Hardware Fabricante Fornecedor HP HP Modelo Nº. Série ProLiant DL760 G2 7MN650XR2 Quantidade de Processadores Quantidade de Memória RAM 8 x Pentium IV Xeon 2.4 7935 MB Garantia Tipo de Suporte 02 Anos (Vencimento 25/09/2009) Gold (24x7x365) Software Fabricante/Desenvolvedor Fornecedor Microsoft Microsoft Software Nº. Licença Windows 2000 Advanced Server 10XT-765129 Versão Service Pack 5.0.2195 SP4 Fabricante/Desenvolvedor Fornecedor SAP SAP Software Nº. Licença SAP R/3 654PW-746FRB941 Versão Service Pack 7.1 — Fabricante/Desenvolvedor Fornecedor Oracle Oracle Software Nº. Licença Oracle DB MP639-YWX516-PSV487 Versão Service Pack 9i — Interfaces/Conectividade Interfaces Modelo Velocidade HP NC7770 Gigabit Server Adapter 1000 Mb/s IP Mac Address 10.75.1.54 000BCD714321 Modelo Velocidade HP NC7770 Gigabit Server Adapter 1000 Mb/s IP Mac Address 10.1.2.54 000BCD714379 Equipamentos Modelo Identificação CISCO 5700 RW3100 Porta Velocidade 20 1000 Mb/s 118. 118 Usuários/Administradores Usuários Administradores 800 (Cadastrados e Ativos no Sistema) F_SERVICE F_SECURITY Armazenamento Partição Tamanho Finalidade Localização C: 17 GB Sistemas Disco Local D: 70 GB Instalação Oracle/SAP Disco Local M: 45 GB Central Instance Storage CX3-80 Dados/Informações Armazenados Tipo/Descrição Banco de Dados ERP Criticidade (Alta/Média/Baixa) Sensibilidade (Alta/Média/Baixa) Alta Alta Tipo/Descrição Criticidade (Alta/Média/Baixa) Sensibilidade (Alta/Média/Baixa) Backup Diretórios/Arquivos Contemplados Tipo Datafiles da instância PRD Online – Completo Periodicidade Retenção Seg. a Sáb. 23:00 15 dias Tipo de Mídia Quantidade de Mídia (s) LTO3 02 Procedimento Local de Guarda IOP-BKP-005 Cofre Prédio Centro Administrativo Diretórios/Arquivos Contemplados Tipo Sistema Operacional Online – Completo Periodicidade Retenção Semanal – Sáb. 09:00 15 dias Tipo de Mídia Quantidade de Mídia (s) DAT3 01 Procedimento Local de Guarda IOP-BKP-037 Cofre Prédio Centro Administrativo 119. 119 Localização Prédio Sala 3.01 DC Controle de Acesso Controle de Temperatura Sim Sim Controle de Umidade Controle de Poluição Não Não Prevenção contra Incêndio Prevenção contra Inundação Sim Não Prevenção contra Falta de Energia Sim Documentos Relacionados Descrição Identificação Instrução de Backup SO IOP-BKP-037 Mídia Localização Digital SRVFILESTIDOCIOPBKP Descrição Identificação Instrução de Backup do SAP IOP-BKP-005 Mídia Localização Digital SRVFILESTIDOCIOPBKP Descrição Identificação Instrução de Start/Shutdown do Servidor IOP-OPR-015 Mídia Localização Digital SRVFILESTIDOCIOPOPR Descrição Identificação Contrato de Garantia 65316 Mídia Localização Impressa Prédio 3.01 – Sala 4 Descrição Identificação Nota Fiscal de Hardware NF-980364 Mídia Localização Impressa Prédio 3.01 – Sala 4 Descrição Identificação Nota Fiscal de Software (Oracle) NF-4036 Mídia Localização Impressa Prédio 3.01 – Sala 4 Descrição Identificação Mídia Localização Descrição Identificação Mídia Localização 120. 120 Cronograma de Atividades Passo: Caracterização de Ativos ______________________________________________________________________ Data Início: _02__/ _03__/ _09__ Data Fim: _06__/ _04__/ _09__ Envolvidos: Marcelo Veloso (Analista de Segurança), Roberto Silveira (Gestor de Segurança) ______________________ ________________________________________________________________________________________________ ID Nome da Tarefa/Atividade Responsável MARÇO ABRIL MAIO Semana Semana Semana 02/ 03 09/ 03 16/ 03 23/ 03 30/ 03 06/ 04 13/ 04 20/ 04 27/ 04 04/ 05 11/ 05 18/ 05 01 Levantamento da documentação - SRVSAPPRD Marcelo Veloso X X X 02 Elaboração Questionário de Entrevistas Marcelo Veloso X 03 Agendamento de Entrevistas Marcelo Veloso X 04 Elaboração do Relatório de Avaliação Marcelo Veloso X X X X 05 Reuniões de Entrevistas Marcelo Veloso X X 06 Apresentação do Relatório de Avaliação Marcelo Veloso X Obs.: Substituir os campos Mês e Número da Semana com a data apropriada. 121. Questionário de Informações de Ativos Ativo avaliado: SRVSAPPRD _________________________________________ Data: _25__/ _03__/ _09__ Entrevistador: Marcelo Veloso _________________________________________ Entrevistado: Wilson Barbosa _________________________________________ Cargo: Analista Basis________________________________________________ Departamento: Tecnologia da Informação _______________________________  Qual é a missão do ativo na Organização/Unidade de Negócio? Hospedar e prover o acesso ao sistema ERP SAP _______________________  Quantos são os usuários válidos do ativo? Existem 800 licenças de uso para o sistema, tendo 750 em uso atualmente ____  Existe monitoração/auditoria do uso e acesso ao ativo? São feitos auditorias de acesso, com avaliação de logins bem e mal-sucedidos _  Quem são os responsáveis pelo manutenção/suporte do ativo? Equipe de Suporte de TI ____________________________________________  Qual tipo de informação é processada e armazenada pelo ativo (por exemplo, financeira, pessoal, médica, operacional, produção, etc.)? Informações de produção, vendas, financeira, contabilidade, recursos humanos, planejamento, gestão_______________________________________________  Quais as informações são geradas, consumidas, processadas, armazenadas, e retornadas pelo ativo? As mesmas informadas acima________________________________________  Quão importante são essas informações à missão da Organização/Unidade de Negócio? São extremamente importantes, principalmente as de produção, necessárias para a não interrupção dos processos de fabricação __________________________  Quais são os fluxos dessas informações? Cada processo de negócio possui o seu fluxo____________________________  Qual é o nível de classificação de sensibilidade dessas informações? (Não Considerável, Relevante, Importante, Crítica, Vital) Vital/Crítica/Importante, dependendo do processo que estiver utilizando _______ 122. 122  Existem controles de acesso a essas informações? Sim. O acesso é concedido de acordo com permissões previamente definidas __  Quais são os tipos de armazenamento dessas informações? São armazenadas em discos magnéticos em um Storage __________________  Qual o efeito na missão da Organização/Unidade de Negócio se o ativo não estiver seguro? Pode trazer comprometimento de todas as operações ____________________  Um mau funcionamento, falha de segurança ou indisponibilidade do ativo poderiam resultar em ferimentos ou morte? Não ____________________________________________________________  Existem registros de incidentes ocorridos anteriormente que causaram a indisponibilidade do ativo? Sim. Todas as paralisações estão registradas nos Boletins Diários do departamento de TI ________________________________________________  Existem procedimentos documentados de operação, manutenção, suporte ao ativo? Para a equipe de analistas Basis sim __________________________________  As operações de manutenção, alteração, atualização do ativo são feitas através de procedimentos formalizados de Gestão de Mudanças? Sim, todas as referentes a hardware e software __________________________  Existe algum tipo de seguro contra roubo, furto, incêndio ou desastre natural para o ativo? Não sei informar __________________________________________________  Existem prestadores de serviço terceirizados para operação, suporte, manutenção do ativo? Sim, para a manutenção de hardware__________________________________  Os contratos de suporte/manutenção para o ativo prevêem o cumprimento de SLA por parte dos fornecedores? Não sei informar __________________________________________________  Existe processo de capacitação/treinamento para os administradores e usuários do ativo? Nenhum que seja formalizado ________________________________________ 123. 123 Perguntas adicionais a serem incluídas:  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________  _____________________________________________________________? ________________________________________________________________ Observações relevantes fornecidas durante a entrevista: ____________________ Existe um histórico de várias paralisações no sistema ERP provido pelo ativo, resultantes de falhas de hardware, mesmo o equipamento estando em cluster com o servidor SRVSAPDB. Os backups efetuados não passam por um processo contínuo de validação através de restore em laboratório. ___________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 124. 124 Declaração de Ameaças Data: 17/04/09 Responsável: Marcelo Veloso Versão: 1.0 Status: Final Identificação do ativo: SRVSAPPRD ____________________________________ Preencher o quadro abaixo assinalando a classificação que mais se aproxime da possibilidade de existência da ameaça citada para o ativo. Relacionar outras ameaças que não tenham sido mencionadas: Categoria Classificação Real Pouco Provável Inexistente Humanas Terrorismo – Explosivo X Terrorismo – Químico X Terrorismo – Biológico X Terrorismo – Radiológico X Terrorismo – Nuclear X Terrorismo – Cyber X Sabotagem X Espionagem X Distúrbio civil – Histeria X Distúrbio civil – Revolta X Guerra X Atividade Criminosa – Vandalismo X Atividade Criminosa – Incêndio Provocado X Atividade Criminosa – Roubo X Atividade Criminosa – Fraude X Atividade Criminosa – Roubo de Dados X Greve X Falha não intencional X 125. 125 Categoria Classificação Real Pouco Provável Inexistente Ambientais Falha de Hardware X Falha de Software X Falha de Conectividade X Falha no Fornecimento de Energia X Falha no Controle de Temperatura X Interferências eletromagnéticas X Vazamento de Material – Químico X Vazamento de Material – Radioativo X Fogo X Explosão X Inundação X Desabamento X Poluição X Proximidade de Aeroportos X Naturais Terremoto X Tsunami X Vulcão X Deslizamento de Terra X Enchente X Temperaturas Extremas X Seca X Fogo X Neve X Gelo X Granizo X Avalanche X Ventania X Furacão X Ciclone X Tornado X Queda de Raios X Infestação de Pragas/Insetos X 126. 126 Lista de Vulnerabilidades Data: 01/05/09 Responsável: Marcelo Veloso Versão: 1.0 Status: Final Identificação do ativo: SRVSAPPRD ____________________________________ Ameaça Vulnerabilidade Comentário Terrorismo – Cyber Falta de equipe especialista em Firewall Pode haver a ocorrência de acessos não autorizados Sabotagem Funcionários com privilégios avançados Nº. de administradores acima do realmente necessário Espionagem Acesso remoto concedido para equipes de manutenção Acesso para coleta de logs e outras informações Atividade Criminosa – Roubo de Dados Fitas de backup transportadas por contínuos Pode haver o roubo pelos funcionários ou criminosos Falha não intencional Falta de treinamento para novos funcionários Funcionários das equipes de TI não são treinados nos procedimentos para operação do ativo Falha de Hardware Falta de peças sobressalentes para reposição Eventos históricos mostram que o fato já teve várias ocorrências Falha de Software Falta de aplicação de atualizações Vulnerabilidades conhecidas e presentes no SO Falha de Conectividade Falta de equipamento sobressalente Em caso de falha, alguns setores da empresa ficaram sem comunicação Falha no Fornecimento de Energia Nobreak com autonomia reduzida Caso ocorram interrupções prolongadas haverá corte de energia Falha no Controle de Temperatura Sistema de refrigeração não possui equipamento reserva semelhante Em caso de falha, terão que ser desligados outros ativos para manter a temperatura Fogo Combate a incêndio feito manualmente Não existe sistema automático de combate, apenas detecção de incêndio Queda de Raios Falta de filtro de energia elétrica Raios podem provocar oscilações que causem danos ao ativo Infestação de Pragas/Insetos Falta de dedetização no prédio Não existe registro da ocorrência da atividade 127. 127 Lista de Verificação de Exigências de Segurança Data: 24/04/09 Responsável: Marcelo Veloso Versão: 1.0 Status: Final Identificação do ativo: SRVSAPPRD ____________________________________ Requisito de Segurança Exigido Conforme Sim Não Sim Não Controle de Acesso Política e procedimentos de controle de acesso X X Administração de contas X X Separação de responsabilidades X X Privilégios mínimos X X Notificação de uso de sistema X X Controle de sessão simultânea X X Bloqueio de sessão X X Encerramento de sessão X X Supervisão e revisão de controle de acesso X X Controle de acesso remoto X Restrições de acesso sem fios X Controle de acesso para dispositivos portáteis e móveis X Conscientização e Treinamento Política e procedimentos de divulgação e treinamento de segurança X X Divulgação de segurança X X Treinamento de segurança X X Contatos com Grupos e Associações de Segurança X X Auditoria e Responsabilidades Política e procedimentos de auditoria e responsabilidades X X Eventos de auditoria X X Registros de conteúdo de auditorias X X Certificação, Credenciamento e Avaliações de Segurança Políticas e procedimentos de certificação, credenciamento e avaliação de segurança X Avaliações de segurança X Certificação de segurança X Credenciamento de segurança X Gerenciamento de Configuração Política e procedimentos de administração de configuração X X Linha base de configuração X X Controle de mudança de configuração X X Restrições de acesso para mudança X X Inventário de informação de componente de sistema X X 128. 128 Requisito de Segurança Exigido Conforme Sim Não Sim Não Plano de Contingência Políticas e procedimentos de plano de contingência X X Treinamento de contingência X X Teste de contingência X X Atualização de plano de contingência X X Local de armazenamento alternativo X X Local de processamento alternativo X X Backup de informação de sistema X X Recuperação e reconstituição de informação de sistema X X Identificação e Autenticação Políticas e procedimentos de identificação e autenticação X X Identificação e autenticação de usuário X X Identificação e autenticação de dispositivo X Resposta a Incidentes Políticas e procedimentos de resposta a incidente X Treinamento de resposta a incidente X Monitoração de incidente X Assistência de resposta de incidente X Manutenção Políticas e procedimentos de manutenção de sistema X X Manutenção controlada X X Ferramentas de manutenção X Manutenção remota X Proteção de Mídia Políticas e procedimentos de Proteção de mídia X X Acesso de mídia X X Rotulagem de mídia X X Armazenamento de mídia X X Transporte de mídia X X Proteção Ambiental e Física Políticas e procedimentos de proteção física e ambiental X X Controle de acesso físico X X Monitoramento de acesso físico X X Controle de visita X X Registros de acesso X X Energia de emergência X X Iluminação de emergência X X Proteção contra incêndio X X Controles de temperatura e de umidade X X Proteção de dano de água X X Local de trabalho alternativo X X Planejamento Políticas e procedimentos de planejamento de segurança X Plano de segurança de sistema X Atualização de plano de segurança de sistema X Regras de comportamento X 129. 129 Requisito de Segurança Exigido Conforme Sim Não Sim Não Segurança Pessoal Políticas e procedimentos de segurança de pessoal X Categorização de posição X Transferência de pessoal X Segurança de pessoal de terceiro X Sanções de pessoal X Aquisição de Sistemas e Serviços Políticas e procedimentos de aquisição de sistemas e serviços X X Alocação de recursos X Documentação de informação de sistema X X Restrições de uso de software X X Administração de configuração X X Administração de testes de segurança X Proteção de Sistemas e Comunicação Políticas e procedimentos de proteção de comunicações X X Separação de aplicação X X Proteção de negação de serviço X X Integridade de transmissão X X Confidencialidade de transmissão X X Estabelecimento e administração de chave criptográfica X Uso de criptografia X Proteções de acesso público X X Nome seguro / Serviço de resolução de endereço (Fonte autorizada) X Autenticidade de sessão X X Integridade de Sistemas e Informações Políticas e procedimentos de integridade de sistemas e informações X X Proteção contra código malicioso X Técnicas e ferramentas de monitoração de sistema de informação X X Alertas de segurança X X Verificação de funcionalidade de segurança X Integridade de software e informação X Proteção contra Spam X Restrições de introdução de informações X X Precisão, perfeição, validade e autenticidade de informação X X Tratamento de erro X X Tratamento e retenção de informações produzidas X X 130. 130 Avaliação de Probabilidades Data: 08/05/09 Responsável: Marcelo Veloso Versão: 1.0 Status: Final Identificação do ativo: SRVSAPPRD ____________________________________ Ameaça Vulnerabilidade Probabilidade Alta Média Baixa Ataque Cyber Falta de equipe especialista em Firewall X Sabotagem Funcionários com privilégios avançados X Espionagem Acesso remoto concedido para equipes de manutenção X Roubo de Dados Fitas de backup transportadas por contínuos X Falha não intencional Falta de treinamento para novos funcionários X Falha de Hardware Falta de peças sobressalentes para reposição X Falha de Software Falta de aplicação de atualizações X Falha de Conectividade Falta de equipamento sobressalente X Falha no Fornecimento de Energia Nobreak com autonomia reduzida X Falha no Controle de Temperatura Sistema de refrigeração não possui equipamento reserva semelhante X Fogo Combate a incêndio feito manualmente X Queda de Raios Falta de filtro de energia elétrica X Infestação de Pragas/Insetos Falta de dedetização no prédio X 131. 131 Relatório de Avaliação de Impacto Data: 28/05/09 Responsável: Marcelo Veloso Versão: 1.0 Status: Final Identificação do ativo: SRVSAPPRD ____________________________________ Ameaça Impacto Alto Médio Baixo Ataque Cyber X Sabotagem X Espionagem X Roubo de Dados X Falha não intencional X Falha de Hardware X Falha de Software X Falha de Conectividade X Falha no Fornecimento de Energia X Falha no Controle de Temperatura X Fogo X Queda de Raios X Infestação de Pragas/Insetos X 132. 132 Questionário de Avaliação de Impacto Data: _18__/ _05__/ _09__ Identificação do ativo: SRVSAPPRD ____________________________________ Descrição: Servidor de produção do SAP R/3 em cluster com o SRVSAPDB_____ _________________________________________________________________ Proprietário: Álvaro Martins (Superintendente de TI) ________________________ Ativos Dependentes (Entrada): RW3100 _________________________________ _________________________________________________________________ Ativos Dependentes (Saída): SRVDW01, SRVMESPRD, RW3100_____________ _________________________________________________________________ 1. A perda deste ativo causaria o seguinte efeito à organização: __X__ A. Efeito catastrófico na organização ou algumas divisões _____ B. Efeito catastrófico em uma divisão _____ C. Efeito moderado na organização ou algumas divisões _____ D. Efeito moderado em uma divisão _____ E. Efeito secundário na organização ou algumas divisões 2. Quanto tempo os processos de negócio dependentes deste ativo continuariam funcionando sem seu apoio? Assuma que a perda do ativo acontece durante o período de pico ou maior utilização. Marque somente uma opção: _03__ Horas _____ Até 1 semana _____ Até 1 dia _____ Até 1 mês _____ Até 2 dias _____ Outro (Por favor, especifique) ____________________ _____ Até 3 dias 133. 133 3. Indique o pico de utilização no(s) mês(s) de um ano, e/ou o(s) dia(s) de um mês ou semana, e/ou a(s) hora(s) mais críticas de um dia, para este ativo: Mês J F M A M J J A S O N D Dia/Mês 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Dia/Semana S T Q Q S S D Hora 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 4. Há qualquer outro pico de utilização ou situações consideradas de tensão? Períodos mensais que vão do dia 28 ao término do mês, quando ocorre o fechamento mensal de faturamento são considerados extremamente críticos, podendo causar prejuízos de grande ordem ______________________________ _________________________________________________________________ 5. Foi desenvolvido/estabelecido qualquer procedimento posterior (manual ou de outra forma) a ser utilizado para dar continuidade aos processos de negócio dependentes caso um incidente torne este ativo indisponível? ________________ Caso ocorra indisponibilidade do ativo, apenas os processos de produção possuem procedimento de operação manual, porém com diminuição da capacidade produtiva _________________________________________________________________ _________________________________________________________________ Se sim, esses procedimentos foram testados? _____ Sim, dentro dos últimos 6 meses __X__ Sim, dentro do último ano _____ Sim, mas há mais de um ano atrás. Quando? _______________ _____ Não 134. 134 Use os seguintes códigos alfabéticos para responder às questões 6, 7, e 8: A = Acima de R$ 10.000.000,00 B = De R$ 1.000.000,00 a R$ 10.000.000,00 C = De R$ 100.000,00 a R$ 1.000.000,00 D = De R$ 10.000,00 a R$ 100.000,00 E = Abaixo de R$ 10.000,00 6. A indisponibilidade deste ativo resultaria em perdas financeiras por falta de arrecadação, faturamento, etc. Durante o tempo indicado após o desastre, esta perda seria correspondente à: __C__ Horas _3_ __B__ Dia 1 __A__ Dia 2 _____ Dia 4 _____ Semana 1 _____ Mês 1 Outro ______________________ 7. A indisponibilidade deste ativo desgastaria a base de clientes após um período de tempo. O custo para a organização, referente a negócios perdidos, depois do tempo indicado, seria: _____ Horas ___ _____ Dia 1 __C__ Dia 2 _____ Dia 4 _____ Semana 1 _____ Mês 1 Outro ______________________ 8. A indisponibilidade deste ativo resultaria em multas e penalidades devido a exigências regulatórias (federal, estadual, local, por força de contratos, etc.). O total destas taxas, depois do tempo indicado, seria: _____ Horas ___ _____ Dia 1 __B__ Dia 2 _____ Dia 4 _____ Semana 1 _____ Mês 1 Outro ______________________ 9. A indisponibilidade deste ativo teria as seguintes implicações legais impostas por estatutos reguladores, exigências de acionistas, ou acordos contratuais: (Especifique a área de exposição) ________________________________________________ Existem contratos firmados com clientes que prevêem multas no caso do descumprimento dos prazos de entregas, trazendo desgaste para a unidade de Vendas ___________________________________________________________ 135. 135 10. A indisponibilidade deste ativo causaria o seguinte impacto negativo ao pessoal da organização: ____________________________________________________ A incapacidade da execução de suas atividades normais, levando a acúmulo de tarefas que terão que ser executadas em horas adicionais de trabalho _________ _________________________________________________________________ 11. A indisponibilidade deste ativo impediria de prover os seguintes serviços a clientes externos: __________________________________________________ Não seria possível efetuar novas vendas, pois consultas a estoques, cronograma de entrega entre outros estariam indisponíveis para os vendedores ______________ _________________________________________________________________ 12. Especifique qualquer outro fator que deve ser considerado ao se avaliar o impacto da indisponibilidade deste ativo: ________________________________ A dependência de praticamente todas as unidades da fábrica das informações armazenadas e processadas pelo ativo __________________________________ _________________________________________________________________ 13. Existe qualquer outra dependência (equipes, vendedor, hardware, software, recursos exclusivos, etc.) ainda não identificada acima? ____________________ Não______________________________________________________________ _________________________________________________________________ _________________________________________________________________ 14. Uma análise das respostas às perguntas anteriores indica que este ativo deveria ser considerado como "vital" para a organização? Se sim, indique abaixo qual rótulo é o mais apropriado: _X_ Sempre ___ Durante o seguinte período do ano: ______________ ___ Durante o seguinte período do mês: _____________ ___ Durante o seguinte período da semana: __________ ___ Outro período de tempo. Especifique: _______________________________ 136. 136 Relatório de Análise de Risco Data: 05/06/09 Responsável: Marcelo Veloso Versão: 1.0 Status: Final Identificação do ativo: SRVSAPPRD ____________________________________ Ameaça Probabilidade x Impacto = Peso do Risco Baixa = 0.1 Média = 0.5 Alta = 1.0 Baixo = 10 Médio = 50 Alto = 100 Baixo = 1 a 10 Médio = 11 a 50 Alto = 51 a 100 Ataque Cyber 1.0 x 100 = 100 Sabotagem 0.5 x 100 = 50 Espionagem 0.5 x 100 = 50 Roubo de Dados 0.1 x 100 = 10 Falha não intencional 1.0 x 50 = 50 Falha de Hardware 1.0 x 50 = 50 Falha de Software 1.0 x 50 = 50 Falha de Conectividade 1.0 x 50 = 50 Falha no Fornecimento de Energia 1.0 x 50 = 50 Falha no Controle de Temperatura 0.5 x 50 = 25 Fogo 0.5 x 100 = 50 Queda de Raios 0.5 x 50 = 25 Infestação de Pragas/Insetos 0.1 x 10 = 1 x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x = x =