PUC-MG Trabalho sobre riscos e continuidade de negócios

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
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
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
Ao meu filho
Nikolai Alexander

5
“A garantia de nos tornarmos invencíveis
está em nossas próprias mãos.”
Sun Tzu

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
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
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
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
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
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
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
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
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
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
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
 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
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
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
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
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
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
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
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
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
 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
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
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
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
 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
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
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
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
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
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
 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
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
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
(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
(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
 Sabotagem
Quadro 1: Exemplos de ameaças humanas: Ameaça, motivação e ações da ameaça
Fonte: NIST SP 800-30, 2002

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
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
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
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
 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
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
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
(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
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
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
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
Saída do Passo 4: Relatório de Avaliação de Probabilidade (Alta, Média,
Baixa)

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
(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
Saída do Passo 5: Relatório de Avaliação de Impacto (Alto, Médio, ou Baixo)

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
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)
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
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
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
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
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
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
 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
(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
(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
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
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
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
 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
 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
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
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
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
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.

PUC-MG Trabalho sobre riscos e continuidade de negócios

PUC-MG Trabalho sobre riscos e continuidade de negócios

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (9)

Semelhante a PUC-MG Trabalho sobre riscos e continuidade de negócios

Semelhante a PUC-MG Trabalho sobre riscos e continuidade de negócios (20)

Mais de Marcelo Veloso

Mais de Marcelo Veloso (15)

PUC-MG Trabalho sobre riscos e continuidade de negócios