Este documento apresenta um processo para a elaboração da Avaliação e Análise de Riscos para a implantação de um Plano de Continuidade de Negócios (PCN). O processo consolida conceitos de metodologias amplamente utilizadas e propõe seis passos para identificar ativos, ameaças, vulnerabilidades, probabilidades, impactos e níveis de risco. O objetivo é fornecer subsídios para o desenvolvimento de estratégias de recuperação que garantam a continuidade dos processos de negócio essenciais de

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:
<http://www.apra.gov.au/Policy/loader.cfm?url=/commonspot/security/getfile.cfm&Pa
geID=8528> 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: <http://daryus.com.br> 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: <www.technetbrasil.com.br/seguranca/> Acesso em: 13 jul. 2008.
MÓDULO. 10ª Pesquisa Nacional de Segurança da Informação. 2006. Disponível
em: <http://modulo.com.br> 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: <http://www.qsp.org.br/pdf/HB221-
2004.pdf> Acesso em: 28 fev. 2009.
STANDARDS AUSTRALIA/STANDARDS NEW ZEALAND. HB 292: A Practitioners
Guide to Business Continuity Management. 2006. Disponível em:
<www.qsp.org.br/pdf/HB292-2006.pdf> 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 =