Pontifícia Universidade Católica de Minas Gerais (PUC/MG)
Instituto de Informática
Programa de Graduação em Sistemas de In...
2
Marcelo de Alencar Veloso
Processo de Avaliação e Análise de Riscos para
Elaboração de Planos de Continuidade de
Negócio...
3
Marcelo de Alencar Veloso
Processo de Avaliação e Análise de Riscos para
Elaboração de Planos de Continuidade de Negócio...
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 ...
7
ABSTRACT
Being this the "Age of Information", it is natural that it is present in all of the relative
aspects of the act...
8
LISTA DE FIGURAS
Figura 1: Diagrama da Equação do Risco de Segurança da Informação..................24
Figura 2: Desenvo...
9
LISTA DE SIGLAS
BIA – Business Impact Analysis
BS – British Standard
CD – Compact Disc
CRM – Customer Relationship Manag...
10
SUMÁRIO
1 INTRODUÇÃO .....................................................................................................
11
3.2.3.1 Fontes de vulnerabilidades.................................................................42
3.2.3.2 Testes de...
12
APÊNDICE A – Ficha de Atividades do Passo 1...................................................76
APÊNDICE B – Ficha de ...
13
1 INTRODUÇÃO
No contexto atual, os ambientes computacionais são muito complexos e
difíceis de gerenciar. As informações...
14
Um PCN é desenvolvido em etapas que passam pelo Planejamento e Escopo
do Plano, Análise de Impactos nos Negócios, Desen...
15
Segurança da Informação, reconhecidos internacionalmente e que tratam do
assunto, indicam apenas “o que fazer” e não “c...
16
processos do negócio. Esta avaliação considera todos os processos do negócio e
não é limitada às facilidades de process...
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 Contin...
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:
"I...
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 con...
20
Segundo a Microsoft (2006), são compostos por três elementos:
 As informações, armazenadas em meio eletrônico ou físic...
21
1. Humanas – estão diretamente relacionadas às ações de indivíduos, e
podem sofrer uma nova segregação, sendo intencion...
22
b) Vulnerabilidades naturais
São aquelas relacionadas às condições da natureza que podem colocar em
risco as informaçõe...
23
2.1.5 Impactos
Resultado da ação bem sucedida de uma ameaça ao explorar as
vulnerabilidades de um ativo, atingindo assi...
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 at...
25
3 PROCESSO TÍPICO DE ELABORAÇÃO DE PLANOS DE CONTINUIDADE DE
NEGÓCIOS
Um Plano de Continuidade de Negócios deve “garant...
26
 FEMA 141 – Federal Emergency Management Agency (FEMA) – U.S.
Department of Homeland Security Emergency Management Gui...
27
contínuo, que deverá sofrer constante revisão e manutenção, com o objetivo de ser
melhorado continuamente e refletir to...
28
Assim ele pode ser executado utilizando-se uma abordagem para o modelo
PDCA (Plan – planejar, Do – implementar, Check –...
29
Figura 3: Modelo PDCA para Planos de Continuidade de Negócios
A seguir, é feita a definição de cada uma das etapas de u...
30
 Limitações;
 Orçamento;
 Capacidade de Recursos.
É recomendado que a organização emita e divulgue, através da alta
...
31
implementação do PCN e designar um ou mais indivíduos para entregar e manter o
programa. Além disto, serão designados t...
32
Vale ressaltar que devido à natureza única de uma organização, tal roteiro
poderá ser adaptado, adequando-se às necessi...
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
primei...
34
Informações adicionais relacionadas ao ambiental operacional de TI e seus
dados inclui, mas não se limitam as seguintes...
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 pa...
36
 Uso de Ferramentas Automatizadas: Métodos técnicos proativos
podem ser usados para coletar informações de um ativo ef...
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 vul...
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 am...
39
(conclusão)
Ameaça Motivação Ações da Ameaça
Terrorista  Chantagem
 Destruição
 Exploração
 Vingança
 Bomba/Terror...
40
A declaração de ameaças, ou a lista de potenciais ameaças, deve ser
determinada individualmente à organização e seu amb...
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...
42
frequentemente variará, dependendo da natureza do ativo e a fase em que se
encontra:
 Se o ativo ainda não tiver sido ...
43
 Documentações anteriores de avaliação de risco do ativo avaliado
 Relatórios de auditoria do ativo, relatórios de an...
44
ferramentas taxam vulnerabilidades potenciais sem considerar o local e exigências
do ambiente. Algumas das "vulnerabili...
45
explicação indicando porque a atual designação ou implementação do ativo satisfaz
ou não aquela exigência.
Uma lista de...
46
(conclusão)
Área de segurança Critérios de segurança
Operação  Controle de contaminações no ar (fumaça, pó,
substância...
47
objetivos de controle específicos contra os quais um sistema ou grupo de sistemas
interconectados podem ser testados e ...
48
3.2.4 Passo 4: Determinação de Probabilidades
Para derivar uma taxa de probabilidade global que indique qual a
probabil...
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 resulta...
50
(por exemplo, perda de confiança pública, perda de credibilidade, danos aos
interesses de uma organização) não podem se...
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 d...
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
...
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
alt...
54
3.3 Definição das Estratégias de Recuperação
A estratégia de recuperação é desenvolvida a partir da análise dos resulta...
55
média de doenças, greve ou um membro fundamental da equipe ficar
indisponível durante várias semanas ou meses.
 Plano ...
56
Há várias opções disponíveis dependendo da estratégia de tecnologia da
organização, e a solução pode ser complexa. Esta...
57
 Retomar, o funcionamento normal de todas as operações empresariais
das medidas temporárias adotadas durante a recuper...
58
(continua)
Plano
Linha do
Tempo
Propósito do Plano
Plano de
Resposta a
Incidente
Resposta Administrar o resultado imedi...
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...
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
Inci...
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 p...
62
participantes, os observadores e todos os com responsabilidade para manutenção
do plano ou ativação no futuro. Ao térmi...
63
 Apresentação de procedimentos
 Arranjos de segurança
 Equipes de processos específicos
 Responsabilidades individu...
64
 Comunicações de crise
 Trabalho em locais alternativos
Treinamentos deverão também ser providos para o pessoal que f...
65
A alta administração da organização deverá, a intervalos que julgar
apropriado, revisar a capacidade de GCN da organiza...
66
A organização deverá prover para uma auditoria independente de sua
competência de GCN a capacidade para identificar def...
67
3.6.2.2 Melhoramento contínuo
Melhoria contínua, com respeito à qualidade e desempenho da organização,
foca em melhorar...
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 fe...
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Monografia PUC MINAS 2009 - Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios
Upcoming SlideShare
Loading in...5
×

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

3,850

Published on

O 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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,850
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
65
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Pontifícia Universidade Católica de Minas Gerais (PUC/MG) Instituto de Informática Programa de Graduação em Sistemas de Informação Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios Marcelo de Alencar Veloso Belo Horizonte 2009
  2. 2. 2 Marcelo de Alencar Veloso Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios Trabalho de Diplomação apresentado ao Programa de Graduação em Sistemas de Informação da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação. Orientador: Marcelo Werneck Barbosa Belo Horizonte 2009
  3. 3. 3 Marcelo de Alencar Veloso Processo de Avaliação e Análise de Riscos para Elaboração de Planos de Continuidade de Negócios Trabalho de Diplomação apresentado ao Programa de Graduação em Sistemas de Informação da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação. _________________________________________________ Marcelo Werneck Barbosa (Orientador) _________________________________________________ _________________________________________________ Belo Horizonte 2009
  4. 4. 4 Ao meu filho Nikolai Alexander
  5. 5. 5 “A garantia de nos tornarmos invencíveis está em nossas próprias mãos.” Sun Tzu
  6. 6. 6 RESUMO Sendo esta a “Era da Informação”, é natural que ela esteja presente em todos os aspectos relativos às atividades de uma empresa. A dependência hoje das informações e seu valor para o desenvolvimento dos processos de negócios, torna-a o bem mais valioso dentro de uma organização. Sendo assim, é fundamental que esta informação esteja sempre disponível aos seus legítimos usuários, quando estes necessitem, com a garantia do sigilo e sem alterações não autorizadas. Para garantir essas premissas, as empresas devem desenvolver estratégias que assegurem a utilização de suas informações, evitando a paralisação de suas atividades por interrupções de qualquer natureza, salvo as que tenham sido planejadas. Um Plano de Continuidade de Negócios tem exatamente este objetivo, o de garantir a continuidade de processos e informações vitais à sobrevivência da empresa, no menor espaço de tempo possível e com o mínimo de impacto. Para garantir o sucesso de um Plano de Continuidade de Negócios, é fundamental que ele seja desenvolvido dentro de uma boa metodologia, que possa ser adaptada às particularidades específicas de cada organização. Desta forma, o presente trabalho tem como objetivo consolidar os conceitos similares presentes em várias metodologias amplamente utilizadas, e propor um processo para a elaboração da Avaliação e Análise de Riscos, que foi considerada a etapa mais importante das necessárias para a implantação de um Plano de Continuidade de Negócios. Palavras-chave: Plano de Continuidade de Negócios. Plano de Contingência. Plano de Recuperação de Desastres. Avaliação e Análise de Riscos.
  7. 7. 7 ABSTRACT Being this the "Age of Information", it is natural that it is present in all of the relative aspects of the activities of a company. The dependence today of the information and its value for the development of the processes of businesses turns it the most valuable asset inside of an organization. So, it is fundamental that this information be always available to their legitimate users, when these need, with the warranty of the secrecy and without unauthorized alterations. To guarantee those premises, the companies should develop strategies to assure the use of their information, avoiding the discontinuity of their activities caused by interruptions of any nature, except for the ones that have been planned. A Business Continuity Plan has exactly this purpose – guarantee the continuity of processes and vital information to the company survival in the shortest time and with minimum impact. To guarantee the success of a Business Continuity Plan it is fundamental that it is developed according to a good methodology that can be adapted to the specific particularities of each organization. This way, the present work, by consolidating similar concepts in several methodologies used, proposes a process for the elaboration of the Risk Analysis and Evaluation – considered the most important phase of the implantation of a Business Continuity Plan. Word-key: Business Continuity Plan. Contingency Plan. Disaster Recovery Plan. Risk Analysis and Evaluation.
  8. 8. 8 LISTA DE FIGURAS Figura 1: Diagrama da Equação do Risco de Segurança da Informação..................24 Figura 2: Desenvolvimento do Plano de Continuidade de Negócios.........................27 Figura 3: Modelo PDCA para Planos de Continuidade de Negócios.........................29 Figura 4: Diagrama do Processo de Avaliação e Análise de Riscos. ........................32 Figura 5: A Linha do Tempo de Incidentes................................................................57 LISTA DE QUADROS Quadro 1: Exemplos de ameaças humanas: Ameaça, motivação e ações da ameaça ..................................................................................................................................39 Quadro 2: Pares de Vulnerabilidades/Ameaças........................................................41 Quadro 3: Critérios de segurança .............................................................................46 Quadro 4: Definições de probabilidade .....................................................................48 Quadro 5: Definições de Magnitude de Impacto .......................................................50 Quadro 6: Matriz de nível de risco.............................................................................52 Quadro 7: Escala de risco e ações necessárias........................................................53 Quadro 8: O uso das partes constituintes do PCN durante cada fase de um incidente ..................................................................................................................................59 Quadro 9: Níveis de treinamento de Administração de Continuidade de Negócios ..63
  9. 9. 9 LISTA DE SIGLAS BIA – Business Impact Analysis BS – British Standard CD – Compact Disc CRM – Customer Relationship Management DDoS – Distributed Denial of Service DRI – Disaster Recovery Institute ENISA – European Network and information Security Agency ERP – Enterprise Resource Planning FTP – File Transfer Protocol GCN – Gestão de Continuidade de Negócios GCSTI – Gestão de Continuidade de Serviços de Tecnologia da Informação GR – Gestão de Riscos IEC – International Electrotechnical Commission ISO – International Organization for Standardization NBR – Denominação de norma da ABNT NIST – National Institute of Science and Technology PCN – Plano de Continuidade de Negócios PDCA – Plan, Do, Check, Act RAID – Redundant Array of Independent Disks RH – Recursos Humanos RPO – Recovery Point Objective RTO – Recovery Time Objective SLA – Service Level Agreement TI – Tecnologia da Informação
  10. 10. 10 SUMÁRIO 1 INTRODUÇÃO .......................................................................................................13 1.1 Objetivo............................................................................................................14 1.1.1 Geral .........................................................................................................14 1.1.2 Específicos................................................................................................15 1.2 Definição do Problema.....................................................................................15 1.3 Contribuições...................................................................................................16 1.4 Metodologia .....................................................................................................16 1.5 Organização do Trabalho ................................................................................17 2 REFERENCIAL TEÓRICO.....................................................................................18 2.1 Segurança da Informação................................................................................18 2.1.1 Princípios básicos .....................................................................................19 2.1.2 Ativos ........................................................................................................19 2.1.3 Ameaças ...................................................................................................20 2.1.4 Vulnerabilidades........................................................................................21 2.1.5 Impactos....................................................................................................23 2.2 Riscos..............................................................................................................23 3 PROCESSO TÍPICO DE ELABORAÇÃO DE PLANOS DE CONTINUIDADE DE NEGÓCIOS...............................................................................................................25 3.1 Inicialização do Projeto de PCN ......................................................................29 3.1.1 Identificando a Organização......................................................................30 3.1.2 Definindo responsabilidades do PCN........................................................30 3.2 Avaliação e Análise de Riscos – Processo Proposto.......................................31 3.2.1 Passo 1: Caracterização de Ativos............................................................33 3.2.1.1 Informações relacionadas aos ativos..................................................33 3.2.1.2 Técnicas de Coleta de Informação .....................................................35 3.2.2 Passo 2: Identificação de Ameaças ..........................................................37 3.2.2.1 Identificação de ameaça.....................................................................37 3.2.2.2 Motivação e Ações de Ameaças.........................................................38 3.2.3 Passo 3: Identificação de Vulnerabilidades...............................................41
  11. 11. 11 3.2.3.1 Fontes de vulnerabilidades.................................................................42 3.2.3.2 Testes de Segurança de ativos ..........................................................43 3.2.3.3 Desenvolvimento da Lista de Verificação de Exigências de Segurança .......................................................................................................................44 3.2.4 Passo 4: Determinação de Probabilidades ...............................................48 3.2.5 Passo 5: Análise de Impacto.....................................................................49 3.2.6 Passo 6: Determinação do Risco ..............................................................51 3.2.6.1 Matriz de risco de nível.......................................................................51 3.2.6.2 Descrição de Nível de Risco...............................................................52 3.3 Definição das Estratégias de Recuperação.....................................................54 3.4 Desenvolvimento do PCN................................................................................56 3.4.1 Conjunto de documentos ..........................................................................57 3.5 Teste do Plano de Continuidade de Negócios.................................................60 3.5.1 Determinando o tipo de teste ....................................................................60 3.5.2 Escrevendo o plano de teste.....................................................................61 3.5.3 Conduzindo o teste ...................................................................................61 3.5.4 Comunicando o resultado do teste............................................................61 3.6 Manutenção do Programa de Gestão de Continuidade de Negócios ..............62 3.6.1 Treinamento de equipes............................................................................62 3.6.2 Manutenção e revisão do Plano de Continuidade de Negócios ................64 3.6.2.1 Gerenciamento de mudanças.............................................................66 3.6.2.2 Melhoramento contínuo ......................................................................67 3.6.3 Desenvolvendo a divulgação ....................................................................67 4 ESTUDO DE CASO ...............................................................................................68 4.1 A Empresa.......................................................................................................68 4.2 Estrutura Tecnológica......................................................................................69 4.3 Aplicação do Processo Proposto .....................................................................69 5 CONCLUSÃO ........................................................................................................72 5.1 Trabalhos Futuros............................................................................................72 6 REFERÊNCIAS BIBLIOGRÁFICAS......................................................................73
  12. 12. 12 APÊNDICE A – Ficha de Atividades do Passo 1...................................................76 APÊNDICE B – Ficha de Atividades do Passo 2...................................................80 APÊNDICE C – Ficha de Atividades do Passo 3...................................................83 APÊNDICE D – Ficha de Atividades do Passo 4...................................................87 APÊNDICE E – Ficha de Atividades do Passo 5...................................................90 APÊNDICE F – Ficha de Atividades do Passo 6 ...................................................93 APÊNDICE G – Relatório de Avaliação de Ativo...................................................95 APÊNDICE H – Cronograma de Atividades...........................................................99 APÊNDICE I – Questionário de Informações de Ativos .....................................100 APÊNDICE J – Declaração de Ameaças..............................................................103 APÊNDICE K – Lista de Vulnerabilidades ...........................................................105 APÊNDICE L – Lista de Verificação de Exigências de Segurança....................106 APÊNDICE M – Avaliação de Probabilidades .....................................................109 APÊNDICE N – Relatório de Avaliação de Impacto............................................110 APÊNDICE O – Questionário de Avaliação de Impacto .....................................111 APÊNDICE P – Relatório de Análise de Risco ....................................................115 APÊNDICE Q – Relatórios Produzidos no Estudo de Caso...............................116
  13. 13. 13 1 INTRODUÇÃO No contexto atual, os ambientes computacionais são muito complexos e difíceis de gerenciar. As informações pertinentes aos negócios da organização encontram-se segregadas, e com a crescente utilização dos computadores e as informações que neles residem, surge uma nova preocupação: assegurar a continuidade dos processos de negócios. As interrupções não planejadas de um processo de negócio de uma organização podem levar a conseqüências indesejadas e até mesmo drásticas, desde perdas financeiras por funcionários/produção parados ou a falência da companhia. Dados do instituto Disaster Recovery Institute (DRI) mostram que duas em cada cinco empresas que sofrem interrupção em suas operações por uma semana fecham as portas em menos de três anos. Levantamento realizado pela KPMG com empresas indianas revelou que 79% não tinham um Plano de Continuidade de Negócios documentado e testado. 66% não tinham qualquer espécie de instrumento para assegurar continuidade de negócios em caso de um desastre maior. Estes resultados mostram a importância para as organizações desenvolverem e manterem um bom Plano de Continuidade de Negócios (PCN), o que em muitos casos, pode significar sua sobrevivência após a ocorrência de um desastre. Um PCN tem como objetivo garantir a continuidade de processos e informações vitais à sobrevivência da empresa, no menor espaço de tempo possível e com o mínimo de impacto causado pelo desastre, através de políticas, planos e procedimentos. Ele contempla diversos e importantes aspectos que devem ser observados durante sua elaboração, através da obtenção e análise de informações que geram uma estratégia integrada para reagir a uma interrupção não programada de atividades de negócio, sendo que, no momento de um desastre, nem todos os processos têm necessária sua continuidade. Assim, deve-se planejar manter níveis aceitáveis de disponibilidade dos principais processos de negócio. Deverá resultar num conjunto de documentos onde estarão registradas as ações relativas às adequações da infra-estrutura e alterações dos procedimentos do dia-a-dia da organização.
  14. 14. 14 Um PCN é desenvolvido em etapas que passam pelo Planejamento e Escopo do Plano, Análise de Impactos nos Negócios, Desenvolvimento do Plano, Aprovação e Implementação, sendo cada fase composta por diversos processos onde ocorre o levantamento de informações e posterior análise. Após sua definição, deverá ainda passar por Testes e Manutenções periódicas, garantindo os objetivos traçados quando da sua definição. Destaca-se dentre os aspectos a serem observados durante sua elaboração a Avaliação e Análise de Riscos e o Plano de Contingência, formado pelos planos de Administração de Crise, Continuidade Operacional e Recuperação de Desastres. Durante o processo de Análise e Avaliação de Risco é que serão feitos todos os levantamentos em relação às ameaças, vulnerabilidades, probabilidades e impacto aos quais os ativos estão sujeitos. Torna-se assim, o processo mais trabalhoso e de maior duração, sendo, portanto o mais crítico. Todas as informações identificadas nesta fase irão embasar decisões estratégicas e táticas relacionadas à garantia de Continuidade de Negócios da organização. Como cada organização apresenta particularidades específicas, exigem que determinados itens do PCN tenham produtos mais detalhados, enquanto outros terão uma abordagem mais genérica, sendo todos, no entanto abrangidos durante sua elaboração. 1.1 Objetivo O objetivo geral e os objetivos específicos, que esclarecerão as intenções deste trabalho, são apresentados a seguir. 1.1.1 Geral Propor um processo sistematizado para a execução de Avaliação e Análise de Riscos em uma organização visando o desenvolvimento de um Plano de Continuidade de Negócios, a partir da constatação de que as Normas e Padrões de
  15. 15. 15 Segurança da Informação, reconhecidos internacionalmente e que tratam do assunto, indicam apenas “o que fazer” e não “como fazer”. Assim, baseado nestas Normas e Padrões, este trabalho busca detalhar uma das etapas sugeridas para a Gestão de Continuidade de Negócios. 1.1.2 Específicos Para se atingir o objetivo geral, foram definidos os seguintes objetivos específicos:  O estabelecimento de passos mínimos a serem executados para a execução de uma Avaliação e Análise de Riscos;  O detalhamento das atividades a serem executadas em cada um dos passos definidos anteriormente;  A aplicação do processo proposto em um estudo de caso. 1.2 Definição do Problema O problema consiste na inexistência de um detalhamento para a execução de uma Avaliação e Análise de Riscos para a elaboração de um Plano de Continuidade de Negócios, de acordo com as normas e padrões existentes. A Associação Brasileira de Normas Técnicas, em sua NBR ISO/IEC 17799, em sua seção 11.1.2 diz: “A continuidade do negócio deve começar pela identificação de eventos que possam causar interrupções nos processos do negócio, tais como falhas em equipamento, incêndios e inundações. Isto deve ser seguido por uma avaliação de riscos para determinar o impacto daquelas interrupções (tanto em termos de escala de danos quanto de período para recuperação). Ambas estas atividades devem ser executadas com o total envolvimento dos proprietários dos recursos e
  16. 16. 16 processos do negócio. Esta avaliação considera todos os processos do negócio e não é limitada às facilidades de processamento de informações. Dependendo dos resultados da avaliação de riscos, um plano estratégico deve ser desenvolvido para determinar o enfoque global para a continuidade do negócio. Uma vez que este plano tenha sido criado, ele deve ser endossado pela gerência.” Este exemplo ilustra a necessidade do detalhamento das atividades a serem executadas para identificar riscos, as conseqüências que eles podem trazer, e limitar os danos que possam vir a causar. 1.3 Contribuições As principais contribuições deste trabalho são:  Apresentar os principais conceitos relativos ao tema Gestão de Continuidade de Negócios;  Justificar a importância da Avaliação e Análise de Riscos para elaboração de Planos de Continuidade de Negócios;  Fornecer um processo detalhado de Avaliação e Análise de Risco, juntamente com modelos formulários para documentar a execução do processo. 1.4 Metodologia Para o desenvolvimento deste trabalho foram desenvolvidas as etapas abaixo descritas:  Pesquisa bibliográfica, incluindo normas, como ABNT NBR ISO/IEC 17799, ABNT NBR ISO/IEC 27001, além de padrões e guias estabelecidos no mercado, dentre eles ITIL v2, COBIT v4, NIST SP 800- 30, BCI Good Practice Guidelines, dentre outros;
  17. 17. 17  Definição de um processo de avaliação e análise de riscos, o qual faz parte de um processo maior, de Gestão de Continuidade de Negócios, e que foi elaborado baseado nas melhores práticas identificadas na bibliografia consultada;  Execução do processo de avaliação e análise de riscos em uma empresa fictícia, com o objetivo de confirmar a viabilidade do processo proposto, além de identificar a existência de possíveis falhas. 1.5 Organização do Trabalho O presente trabalho está dividido em seis capítulos, conforme segue:  O Capítulo 1 – Introdução define os objetivos do trabalho e a motivação de sua elaboração.  O Capítulo 2 – Referencial teórico apresenta os conceitos sobre Segurança da Informação e os princípios básicos que a norteiam; além da definição das principais terminologias associadas ao tema, visando facilitar o entendimento do leitor ao longo do trabalho.  O Capítulo 3 – Plano de Continuidade de Negócios apresenta sucintamente as etapas de um PCN, e propõe um processo detalhado de execução da etapa de Avaliação e Análise de Riscos.  O Capítulo 4 – Estudo de Caso apresenta a aplicação do processo em uma empresa e os resultados obtidos.  O Capítulo 5 – Conclusão apresenta as conclusões sobre o processo proposto e trabalhos futuros relacionados.  O Capítulo 6 – Referências bibliográficas relaciona toda referência bibliográfica consultada para elaboração dessa monografia.
  18. 18. 18 2 REFERENCIAL TEÓRICO 2.1 Segurança da Informação Segundo definição da Norma NBR ISO/IEC 17799:2001 para informação: "Informação é um ativo que, como qualquer outro ativo importante para os negócios, tem um valor para a organização e conseqüentemente necessita ser adequadamente protegido.” Sendo assim, a informação é cada vez um elemento chave para o desenvolvimento e sucesso de uma organização, independente de seu tamanho e área de atuação. De acordo com a definição do Dicionário Eletrônico Houaiss, segurança é: Segurança. S. f. 2 ação ou efeito de assegurar e garantir alguma coisa; garantia, fiança, caução. 3 estado, qualidade ou condição de uma pessoa ou coisa que está livre de perigos, de incertezas, assegurada de danos e riscos eventuais, afastada de todo mal. 6 conjunto de processos, de dispositivos, de medidas de precaução que asseguram o sucesso de um empreendimento, do funcionamento preciso de um objeto, do cumprimento de algum plano etc. Pode-se afirmar assim que Segurança da Informação são os processos e medidas empregadas para assegurar as informações de uma organização contra uma extensa variedade de ameaças, garantindo o sucesso e o funcionamento das atividades dessa organização, tendo como base para sua aplicação os princípios de confidencialidade, integridade e disponibilidade.
  19. 19. 19 2.1.1 Princípios básicos A segurança da informação tem como objetivo proteger os ativos de uma organização contra a concretização de ameaças que possam afetar a informação, seja corrompendo-a, eliminando-a, permitindo acessos indevidos ou sua indisponibilidade. A proteção contra essas ameaças baseia-se em três princípios básicos, que norteiam todas as atividades desenvolvidas. Segundo Sêmola (2003), estes princípios podem ser definidos como:  Confidencialidade – Toda informação deve ser protegida de acordo com o grau de sigilo de seu conteúdo, visando a limitação de seu acesso e uso apenas às pessoas para quem elas são destinadas.  Integridade – Toda informação deve ser mantida na mesma condição em que foi disponibilizada pelo seu proprietário, visando protege-las contra alterações indevidas, intencionais ou acidentais.  Disponibilidade – Toda informação gerada ou adquirida por um indivíduo ou instituição deve estar disponível aos seus usuários no momento em que os mesmos delas necessitem para qualquer finalidade. 2.1.2 Ativos Ativo é “todo elemento que manipula a informação, inclusive ela mesma, passando pelo seu emissor, o meio pelo qual ela é transmitida ou armazenada, até chegar a seu receptor.” (Sêmola, 2003, p.45). Os ativos são elementos a serem protegidos de forma adequada, devido ao valor que possuem para uma organização, para que suas operações não sejam prejudicadas pelos variados tipos de danos que estão sujeitos, causados por ameaças que explorem vulnerabilidades.
  20. 20. 20 Segundo a Microsoft (2006), são compostos por três elementos:  As informações, armazenadas em meio eletrônico ou físico;  Os equipamentos e sistemas que oferecem suporte a elas, incluindo hardware, software, e organização, formada pela estrutura física e organizacional da organização;  Os indivíduos que utilizam a estrutura tecnológica e de comunicação da empresa e que lidam com a informação. 2.1.3 Ameaças De acordo com a Microsoft (2006), as ameaças são a causa potencial de um incidente indesejado através da exploração de vulnerabilidades existentes, que caso se concretize pode resultar em perdas e danos aos ativos de uma organização, afetando os seus negócios. Os ativos estão constantemente sob ameaças que podem colocar em risco a integridade, a confidencialidade e a disponibilidade das informações. Essas ameaças sempre existirão e estão relacionadas a causas que representam riscos, as quais podem ser:  causas naturais ou não-naturais;  causas internas ou externas (Microsoft, 2006). As ameaças são constantes e podem ocorrer a qualquer momento. Essa relação de freqüência-tempo se baseia no conceito de risco, o qual representa a probabilidade de que uma ameaça se concretize por meio de uma vulnerabilidade ou ponto fraco. Segundo Oliveira (2006), as ameaças podem ser classificadas em três grupos:
  21. 21. 21 1. Humanas – estão diretamente relacionadas às ações de indivíduos, e podem sofrer uma nova segregação, sendo intencional as decorrentes de ações deliberadas como sabotagens, invasões, fraudes, entre outros, e não intencional as resultantes de erros e acidentes causados por funcionários. 2. Ambientais – compreendidas por hardware, software, dispositivos tecnológicos, “bugs”, falhas elétricas, etc. 3. Naturais – decorrentes de condições da natureza e a intempéries, tais como incêndio, furacão, inundação, terremotos. 2.1.4 Vulnerabilidades De acordo com Sêmola (2003, p.48), vulnerabilidade é a “fragilidade presente ou associada a ativos que manipulam e/ou processam informações que, as ser explorada por ameaças, permite a ocorrência de um incidente de segurança, afetando negativamente um ou mais princípios da segurança da informação: confidencialidade, integridade e disponibilidade.” A existência de uma vulnerabilidade não implica necessariamente na ocorrência de um incidente. Elas são os pontos que poderão ser utilizados pelas ameaças para causar danos aos ativos da organização. A sua identificação é de fundamental importância para que se possa dimensionar os riscos aos quais os ativos encontram-se expostos, definindo medidas que visem a sua correção para diminuir a possibilidade de exploração por parte das ameaças. Segundo a Microsoft (2006, p. 48-53), as vulnerabilidades podem ser divididas nas seguintes categorias: a) Vulnerabilidades físicas São aquelas presentes nos ambientes em que estão sendo armazenadas ou gerenciadas as informações, como falta de extintores, disposição desorganizada de cabos de energia e rede, etc.
  22. 22. 22 b) Vulnerabilidades naturais São aquelas relacionadas às condições da natureza que podem colocar em risco as informações, como locais próximos a rios propensos a inundações, incapacidade de resistência a manifestações da natureza como terremotos, furacões, tempestades, etc. c) Vulnerabilidades de hardware Os possíveis defeitos de fabricação ou configuração dos equipamentos da empresa que poderiam permitir o ataque ou a alteração dos mesmos, como falta de atualizações orientadas por fabricantes, conservação inadequada de equipamentos, etc. d) Vulnerabilidades de softwares Os pontos fracos dos aplicativos permitem que ocorram acessos indevidos aos sistemas de computador, inclusive sem o conhecimento de um usuário ou administrador de rede, como ausência de atualizações, configurações e instalações inadequadas, programação insegura, etc. e) Vulnerabilidades dos meios de armazenamento Os meios de armazenamento podem ser afetados por pontos fracos que podem danificá-los ou deixá-los indisponíveis, como uso incorreto, locais de armazenamento incorretos, prazo de validade vencido, etc. f) Vulnerabilidades de comunicação Esse tipo de vulnerabilidade abrange todo o tráfego de informações, como falta de criptografia, escolha de sistemas inapropriados para a natureza da informação, etc. g) Vulnerabilidades humanas Relacionam-se aos danos que as pessoas podem causar às informações e ao ambiente tecnológico que lhes oferece suporte, como falta de treinamento, senhas fracas, compartilhamento de credenciais de acesso, etc.
  23. 23. 23 2.1.5 Impactos Resultado da ação bem sucedida de uma ameaça ao explorar as vulnerabilidades de um ativo, atingindo assim um ou mais princípios da segurança da informação, causando danos a um ou mais processos do negócio da organização. 2.2 Riscos O risco pode ser encarado através de duas óticas antagônicas: como uma oportunidade ou como uma ameaça. De acordo com D’ANDREA citado por Oliveira (2006, p.23) “o risco como oportunidade está centrado no investimento e tem base em iniciativas estratégicas. Quanto maior for o risco, maior o potencial de retorno, e, paralelamente, maior pode ser o potencial de perda”. Esta visão define o risco como elemento decisivo nos resultados a serem obtidos, numa equação proporcionalmente equivalente dos ganhos a serem obtidos. Este trabalho trata do risco como ameaça, que como definido por Sêmola (2003, p. 55) “é a probabilidade de que agentes, que são as ameaças, explorem vulnerabilidades, expondo os ativos a perdas de confidencialidade, integridade e disponibilidade, causando impacto nos negócios.” A perda de um ou mais destes fatores de segurança leva “à ocorrência de efeitos negativos como perda financeira, fraude, roubo, comprometimento da imagem e reputação, infração legal, falhas tecnológicas, dentre outros.” Oliveira (2006, p.23). Na perspectiva de uma ameaça, o risco deve sempre ser tratado de maneira preventiva, buscando minimizar o impacto causado caso venha a se materializar. A gestão de riscos pode ser esboçada pela equação:
  24. 24. 24 Figura 1: Diagrama da Equação do Risco de Segurança da Informação Fonte: Sêmola, 2003 Sendo assim, o risco a qual um ativo estará exposto encontra-se na combinação dessas variáveis, sendo o objetivo principal da segurança da informação a redução dos riscos, através da eliminação das vulnerabilidades dos ativos, evitando que as ameaças as explorem e gerem impactos para as organizações. Como não existe segurança total, a organização, dentro de seus objetivos, deve manter o risco o mais próximo a zero possível.
  25. 25. 25 3 PROCESSO TÍPICO DE ELABORAÇÃO DE PLANOS DE CONTINUIDADE DE NEGÓCIOS Um Plano de Continuidade de Negócios deve “garantir a continuidade de processos e informações vitais à sobrevivência da empresa, no menor espaço de tempo possível, com o objetivo de minimizar os impactos do desastre.” (Sêmola, 2003, p.98). Enquanto a Gestão de Riscos (GR) é o processo no qual se busca minimizar, ou mesmo eliminar os riscos a que os ativos de uma organização possam estar expostos, a Gestão de Continuidade de Negócios (GCN), do qual o PCN faz parte, é um processo pró-ativo que busca assegurar que uma organização possa sobreviver a incidentes não planejados, decorrentes de riscos residuais que causem interrupções em seus processos de negócio. Ou seja, visa o planejamento e preparação para responder e contingenciar situações que se apresentarem e que todos os outros mecanismos de segurança não forem capazes de evitar. O presente trabalho apresenta uma adaptação do processo descrito pela European Network and information Security Agency (ENISA), como uma proposta para o desenvolvimento de um Plano de Continuidade de Negócios. Buscou-se sintetizar as etapas consideradas indispensáveis, e que se encontram presentes nos padrões, normas e diretrizes de melhores práticas existentes, dentre eles:  APS 232 – Australian Prudential Regulatory Authority – APS 232, 2005, Business Continuity Management;  BCI Good Practice Guidelines – The Business Continuity Institute. Good Practice Guidelines 2005 – A Framework for Business Continuity Management;  BS 25999-1 – British Standards Institute. BS 25999-1. Code of practice for business continuity management;  Cobit v4.1 – CobiT, Control Objectives for Information and related Technology, IT Governance Institute;
  26. 26. 26  FEMA 141 – Federal Emergency Management Agency (FEMA) – U.S. Department of Homeland Security Emergency Management Guide for Business & Industry;  HB 221 – Standards Australia/Standards New Zealand. HB 221-2004, Business Continuity Management;  HB 292 – Standards Australia/Standards New Zealand. HB 292-2006. Handbook. A Practitioners Guide to Business Continuity Management;  ISO 17799 – ISO/IEC 17799:2005 – Information technology – Security techniques – Code of practice for information security management;  ISO 27001 – ISO/IEC 27001:2005 – Information technology – Security techniques – Information security management systems – Requirements;  ITIL v2 – Information Technology Infrastructure Library. ITIL v2; OGC – UK Office of Government Commerce;  NFPA 1600 – National Fire Protection Association. NFPA 1600. Standard on Disaster/Emergency Management and Business Continuity Programs. 2007 Edition;  NIST SP 800-30 – National Institute of Science and Technology. NIST SP 800-34. Risk Management Guide for Information Technology Systems;  NIST SP 800-53 – National Institute of Science and Technology. NIST SP 800-53. Recommended Security Controls for Federal Information Systems and Organizations. O desenvolvimento do Plano de Continuidade de Negócios foi dividido em seis etapas, mostradas na Figura 2. A segunda etapa, que compreende a Avaliação e Análise de Riscos, sendo esta o foco principal deste trabalho, foi detalhada em um processo sistematizado para sua execução, através de passos propostos com o objetivo de garantir uma análise precisa dos riscos a que possam estar expostos os ativos avaliados. Quando um PCN é elaborado pela primeira vez em uma organização, ele é desenvolvido como um projeto, ou seja, uma atividade com início e fim. Porém, como exposto no diagrama, uma vez concluído ele assume o papel de um processo
  27. 27. 27 contínuo, que deverá sofrer constante revisão e manutenção, com o objetivo de ser melhorado continuamente e refletir todas as mudanças que venham a ocorrer na organização. Figura 2: Desenvolvimento do Plano de Continuidade de Negócios
  28. 28. 28 Assim ele pode ser executado utilizando-se uma abordagem para o modelo PDCA (Plan – planejar, Do – implementar, Check – analisar, Act – monitorar) utilizado nos modelos de gestão de qualidade, e adotado na ISO/IEC 27001:2005, como referência para melhoria dos processos a serem implementados numa organização implantando um Sistema de Gerenciamento de Segurança da Informação. As etapas do PCN estariam assim relacionadas com as fases do modelo PDCA:  Plan (planejar): Abrange as etapas de avaliação e Análise de Riscos e Definição das Estratégias de Recuperação, que envolvem as atividades de levantamento de informações, elaboração de relatórios de inventários, a escolha e o planejamento dos controles a serem adotados.  Do (implementar): Estabelece a etapa onde são desenvolvidos os Planos de Continuidade definidos anteriormente, com a implantação das estratégias, normas, procedimentos e instruções que formam os planos.  Check (analisar): Envolve a etapa de validação dos planos implementados, através de testes que comprovem sua eficiência na garantia de continuidade dos processos de negócios de uma organização.  Act (monitorar): Compreende a etapa de manutenção dos planos, através do acompanhamento de mudanças que exijam a atualização dos mesmos, e de treinamentos periódicos de todos os envolvidos em sua execução. A Figura 3 ilustra o relacionamento entre as fases do modelo PDCA e as etapas do PCN.
  29. 29. 29 Figura 3: Modelo PDCA para Planos de Continuidade de Negócios A seguir, é feita a definição de cada uma das etapas de um processo típico para elaboração de Planos de Continuidade de Negócios, com destaque para a Avaliação e Análise de Riscos, cujo detalhamento é o objetivo deste trabalho. 3.1 Inicialização do Projeto de PCN Ao implementar um programa de PCN pela primeira vez em uma organização, é recomendada a adoção de disciplinas de administração de projetos, para que se possam definir de forma clara quais serão os responsáveis, as entregas, os prazos e os orçamentos a serem desenvolvidos pelo programa. O início do programa deve incluir:  Metas e objetivos de atividades estratégicas e operacionais de Gestão de Continuidade de Negócios (GCN);  Definição de equipes e integrantes;  Identificação de entregas e resultados;  Cronograma e prazos finais;
  30. 30. 30  Limitações;  Orçamento;  Capacidade de Recursos. É recomendado que a organização emita e divulgue, através da alta administração, uma Declaração de Missão do Plano, para demonstrar seu compromisso com a continuidade dos negócios em situações emergenciais. Esta declaração deverá conter principalmente a definição do propósito do plano e a indicação que envolverá a organização inteira. 3.1.1 Identificando a Organização É necessário identificar as áreas empresariais fundamentais que precisam ser interrogadas sobre o uso delas de tecnologia e informação como também sobre o impacto provável de sua perda. O pessoal mais indicado para contribuir à Business Impact Analysis (BIA) são os gerentes ou líderes das unidades empresariais desde que eles não só entendam do negócio da sua área operacional no dia-a-dia, mas que também tenham a autoridade para definir os objetivos exigidos de recuperação. Uma compreensão clara das responsabilidades fundamentais e posicionamento dentro da organização é também exigida para designar as equipes que serão responsáveis pelo projeto de Continuidade de Negócios em todas as diferentes fases. Uma vez que as áreas empresariais foram identificadas é necessário identificar os processos de negócio dentro dessas áreas. 3.1.2 Definindo responsabilidades do PCN O grupo de administração sênior deve designar ou nomear uma pessoa com apropriada experiência e autoridade para ser responsável pela política de
  31. 31. 31 implementação do PCN e designar um ou mais indivíduos para entregar e manter o programa. Além disto, serão designados times específicos para lidar com incidentes. A estrutura e tamanho das equipes irão depender das necessidades da organização. Em organizações menores, muitos papéis e responsabilidades (estratégicos assim como operacionais) podem ser agrupados e cobertos por equipes menores. 3.2 Avaliação e Análise de Riscos – Processo Proposto Esta etapa do desenvolvimento do Plano de Continuidade de Negócios é o foco principal deste trabalho, que propõe um processo sistemático para sua execução, através da definição de passos a serem executados até a sua conclusão, resultando numa análise precisa dos riscos a que estarão expostos os ativos avaliados. Foi considerada como a etapa mais importante dentre as necessárias para a criação de um Plano de Continuidade de Negócios. Tal consideração se deve ao fato de que é através da Avaliação e Análise de Riscos que serão feitas as priorizações das ações a serem tomadas, em função do risco identificado e classificado para cada um dos ativos avaliados. A Figura 4 mostra o diagrama com o fluxo dos passos a serem executados, além das entradas e saídas de cada um. Na saída, os itens descritos em vermelho, são aqueles considerados obrigatórios, e na entrada, os que serão utilizados para a continuidade do processo e produzidos nos passos anteriores, seguindo um processo contínuo. A seguir, é feita uma descrição para cada um dos passos, abordando seus objetivos e detalhes de sua execução. Nos apêndices, são apresentadas Fichas de Atividades detalhadas, com um roteiro orientando quais atividades deverão ser executadas, as pessoas envolvidas e os documentos requeridos e produzidos ao término de cada passo, incluindo também modelos de documentos a serem produzidos ao longo do processo.
  32. 32. 32 Vale ressaltar que devido à natureza única de uma organização, tal roteiro poderá ser adaptado, adequando-se às necessidades e particularidades que venham se apresentar. Figura 4: Diagrama do Processo de Avaliação e Análise de Riscos. Entradas/Saídas em vermelho denotam documentos obrigatórios.
  33. 33. 33 3.2.1 Passo 1: Caracterização de Ativos Na avaliação de riscos para um ativo de Tecnologia da Informação (TI), o primeiro passo é definir o escopo do projeto. Neste passo, os limites dos ativos de TI são identificados, juntamente com os recursos e as informações que constituam o ativo. A caracterização de um ativo de TI estabelece a extensão da avaliação de risco, e provê informações (por exemplo, hardware, software, conectividade de sistemas, equipe responsável) essenciais para definir o risco. A metodologia descrita neste documento pode ser aplicada a avaliações de um único ativo ou múltiplos ativos relacionados. No último caso, é importante que o domínio de interesse e todas as interfaces e dependências sejam definidas bem antes de aplicar a metodologia. 3.2.1.1 Informações relacionadas aos ativos A identificação de riscos para um ativo de TI requer uma compreensão aguda do ambiente de processo do ativo. A pessoa ou pessoas que administram a avaliação de riscos têm que primeiro juntar as informações relacionadas aos ativos, normalmente classificadas como:  Hardware  Software  Interfaces de sistema (por exemplo, conectividade interna e externa)  Dados e informações  Pessoas que suportam e usam o ativo  Missão do ativo (por exemplo, os processos executados pelo ativo)  Criticidade dos dados e sistemas (por exemplo, o valor do ativo ou importância para a organização)  Sensibilidade dos dados e sistemas (o nível de proteção requerido para manter a confidencialidade, integridade e disponibilidade)
  34. 34. 34 Informações adicionais relacionadas ao ambiental operacional de TI e seus dados inclui, mas não se limitam as seguintes:  As exigências funcionais do ativo  Usuários do ativo (por exemplo, usuários de sistemas que provêem apoio técnico para o sistema; usuários de aplicação que usam o sistema para executar funções empresariais)  Políticas de segurança (políticas organizacionais, federal, exigências, leis, práticas da indústria)  Arquitetura de segurança  Topologia da rede (por exemplo, diagrama de rede)  Informação de armazenamento que garanta a disponibilidade, integridade, e confidencialidade de dados  Fluxo de informação pertencente a sistemas de TI (por exemplo, interfaces de sistema, fluxograma de entrada e saída)  Controles técnicos usados por sistemas de TI (por exemplo, produtos de segurança embutidos ou adicionados que suportam identificação e autenticação, acesso discricionário ou obrigatório, controle, auditoria, proteção de informação residual, métodos de encriptação)  Controles de administração usados por sistema de TI (por exemplo, regras de comportamento, planejamento de segurança)  Controles Operacionais usados por sistemas de TI (por exemplo, segurança de pessoal, backup, operações de contingência, recuperação e continuidade; manutenção de sistema; armazenamento off-site; procedimentos de criação e exclusão de contas de usuário; controles para segregação de funções de usuários, como acesso de usuário privilegiado contra acesso de usuário padrão)  Ambiente de segurança físico dos ativos (por exemplo, segurança de acesso, políticas de data center)  Segurança ambiental implementada para o ambiente de processamento do ativo (por exemplo, controles para umidade, água, energia, poluição, temperatura, e substâncias químicas).
  35. 35. 35 3.2.1.2 Técnicas de Coleta de Informação Quaisquer das técnicas seguintes, ou uma combinação delas, podem ser usadas para colher informações pertinentes para o ativo dentro de seu limite operacional:  Questionário: Para coletar informações pertinentes, a equipe de avaliação de riscos pode desenvolver um questionário relativo à administração e controles operacionais, planejados ou usados para o ativo. Este questionário deve ser distribuído à equipe técnica e pessoal de administração não-técnica que está projetando ou apoiando o ativo. O questionário também pode ser usado durante visitas de in loco e entrevistas.  Entrevistas in loco: Entrevistas com equipes de apoio ao ativo e de administração podem permitir à equipe de avaliação de risco coletar informações úteis sobre o ativo (por exemplo, como o ativo é operado e é administrado). Visitas in loco também permitem à equipe de avaliação de risco observar e colher informação sobre a segurança física, ambiental, e operacional do ativo. Para ativos ainda na fase de implementação, as visitas in loco colheriam dados que poderiam prover a oportunidade para avaliar o ambiente físico no qual o ativo operará.  Revisão de Documentação: Documentos de Política (por exemplo, documentação legislativa, diretivas), documentação de sistemas (por exemplo, guia do usuário de sistema, manual administrativo de sistema, documentos de desígnio e requisitos de sistema, documentos de aquisição), e documentação relacionada à segurança (por exemplo, relatório prévio de auditoria, relatório de avaliação de risco, resultados de teste de sistemas, plano de segurança de sistemas, políticas de segurança) podem prover boas informações sobre os controles de segurança usados e planejados para o ativo. Uma análise de impacto na missão de uma organização ou avaliação de criticidade de recursos provê informações relativas à criticidade e sensibilidade de dados e sistemas.
  36. 36. 36  Uso de Ferramentas Automatizadas: Métodos técnicos proativos podem ser usados para coletar informações de um ativo eficazmente. Por exemplo, uma ferramenta de mapeamento de rede pode identificar os serviços que executam em um vasto grupo de servidores. A escolha de qual das técnicas acima serão empregadas, fica a cargo do Analista de Segurança responsável pela coleta das informações, porém frequentemente a utilização de entrevistas e revisão de documentos estão sempre presentes, devido a sua abrangência e facilidade de emprego. A coleta de informações pode ser conduzida ao longo do processo de avaliação de risco, do Passo 1 (Caracterização de Ativos) ao Passo 6 (Análise de Risco). Uma Ficha de Atividades com um roteiro descritivo orientando quais atividades deverão ser executadas, as pessoas envolvidas e os documentos requeridos e produzidos ao término da execução desse passo é apresentada no Apêndice A ao final deste documento, como uma proposta passível de adaptações para se adequar às necessidades da organização, não devendo ser encarada como um guia definitivo. Saída do Passo 1: Relatório de Avaliação de Ativos.
  37. 37. 37 3.2.2 Passo 2: Identificação de Ameaças Uma ameaça é o potencial de uma particular ameaça exercitar com sucesso uma vulnerabilidade em particular. Uma vulnerabilidade é uma fraqueza que pode ser explorada acidentalmente ou intencionalmente. Uma ameaça não apresenta um risco quando não houver uma vulnerabilidade que possa ser exercitada. Para determinar a probabilidade de uma ameaça tem-se que considerar a ameaça, as potenciais vulnerabilidades, e os controles existentes. 3.2.2.1 Identificação de ameaça O objetivo deste passo é identificar as ameaças potenciais e compilar uma declaração de ameaças que liste as potenciais ameaças aplicáveis para o ativo avaliado. Na avaliação de ameaças, é importante considerar todas as potenciais ameaças que poderiam causar dano para um ativo e seu ambiente de processamento. Por exemplo, embora a declaração de ameaça para um sistema localizado em um deserto possa não incluir "inundação natural" por causa da baixa probabilidade de tal evento ocorrer, ameaças ambientais como o estouro de um cano, que podem rapidamente inundar uma sala de computadores, podem ser consideradas como possíveis de causar danos para os ativos de uma organização. Humanos podem ser uma ameaça por atos intencionais, como ataques deliberados por pessoas maliciosas ou empregados decepcionados, ou atos não intencionais, como erros e negligência. Um ataque deliberado pode também ser uma tentativa maliciosa para ganhar acesso sem autorização para um sistema (por exemplo, através de senhas adivinhadas) ou uma benigna, mas, no entanto, propositada tentativa de iludir a segurança do sistema. Um exemplo seria um programador que está escrevendo um Trojan para contornar a segurança de um sistema.
  38. 38. 38 3.2.2.2 Motivação e Ações de Ameaças A motivação e os recursos para levar a cabo um ataque fazem os humanos fonte de ameaças potencialmente perigosas. O Quadro 1 apresenta uma avaliação de muitas das ameaças humanas comuns hoje, as possíveis motivações delas, e os métodos ou ações pelas quais elas poderiam levar a cabo um ataque. Estas informações serão úteis a organizações estudando os seus ambientes humanos de ameaça e personalizando as declarações de ameaças humanas. Além disso, revisões de histórico de paradas do sistema; relatórios de violação de segurança; relatórios de incidentes; e entrevistas com os administradores de sistemas, equipe de help desk, e comunidades de usuários durante a coleta de informações ajudará a identificar ameaças humanas que têm o potencial para prejudicar um sistema e seus dados, o que se torna uma preocupação onde uma vulnerabilidade existe. (continua) Ameaça Motivação Ações da Ameaça Hacker, cracker  Desafio  Ego  Rebelião  Hacking  Engenharia social  Invasão de sistema,  Rombos  Acesso não autorizado ao sistema Criminoso digital  Destruição de informação  Divulgação ilegal de informação  Ganho monetário  Alteração de dados sem autorização  Ato Fraudulento (por exemplo, personificação, interceptação)  Suborno por informação  Spoofing  Invasão de sistemas
  39. 39. 39 (conclusão) Ameaça Motivação Ações da Ameaça Terrorista  Chantagem  Destruição  Exploração  Vingança  Bomba/Terrorismo  Guerra de Informação  Ataque de sistemas (por exemplo, Distributed Denial of Service (DDoS))  Invasão de sistema Espionagem industrial (companhias, governos estrangeiros, interesse de outros regimes)  Vantagem competitiva  Espionagem econômica  Exploração econômica  Roubo de informação  Invasão de privacidade pessoal  Engenharia social  Invasão de sistema  Acesso não autorizado ao sistema (acesso para informação secreta e proprietária) Indivíduos internos (pobremente treinado, decepcionado, malicioso, negligente, desonesto, ou empregados desligados)  Curiosidade  Ego  Inteligência  Ganho Monetário  Vingança  Erros não intencionais e omissões (por exemplo, erro de entrada de dados, erro de programação)  Chantagem  Leitura de documentos de informação proprietária  Abuso na utilização de computador  Fraude e roubo  Suborno por informação  Corrupção de dados  Interceptação  Código malicioso (por exemplo, vírus, cavalo de Tróia)  Venda de informação pessoal  Bugs de sistema  Invasão de sistema  Sabotagem  Acesso não autorizado ao sistema Quadro 1: Exemplos de ameaças humanas: Ameaça, motivação e ações da ameaça Fonte: NIST SP 800-30, 2002
  40. 40. 40 A declaração de ameaças, ou a lista de potenciais ameaças, deve ser determinada individualmente à organização e seu ambiente de processo. Em geral, informações sobre ameaças naturais (por exemplo, inundações, terremotos, tempestades) devem estar prontamente disponíveis, assim como ameaças conhecidas que foram identificadas por entidades do governo e organizações privadas. Ferramentas de detecção de intrusão também estão ficando mais prevalecentes, e o governo e organizações de indústria juntam dados continuamente em eventos de segurança, melhorando a habilidade para avaliar ameaças realisticamente. Fontes de informação incluem, mas não estão limitadas, às seguintes:  Agências de Inteligência  Meios de comunicação de massa, particularmente recursos baseados na Web como SecurityFocus.com, SecurityWatch.com, SecurityPortal.com, e SANS.org. Saída do Passo 2: Uma Declaração de Ameaças, que contém uma lista de ameaça-fonte que poderiam explorar vulnerabilidades dos ativos.
  41. 41. 41 3.2.3 Passo 3: Identificação de Vulnerabilidades A análise de riscos para um ativo de TI tem que incluir uma identificação das vulnerabilidades associadas com o ambiente do ativo. A meta deste passo é desenvolver uma lista de vulnerabilidades do ativo (falhas ou fraquezas) que poderiam ser exploradas por potenciais ameaças. O Quadro 2 apresenta exemplos de pares de vulnerabilidades/ameaças. Vulnerabilidade Ameaça Ação da Ameaça Identificadores (ID) de empregados desligados não são removidos do sistema Empregados desligados Conectando na rede da organização e acessando dados proprietários Firewall da organização permite entrada de telnet, e a conta convidado está habilitada no servidor XYZ Usuários sem autorização (por exemplo, hackers, empregados desligados, criminosos de computador, terroristas) Usando telnet para o servidor XYZ navegando pela estrutura de arquivos de sistemas com a conta convidado O fabricante identificou falhas dentro da segurança do sistema; porém hot fixes novos não têm sido aplicados no sistema Usuários sem autorização (por exemplo, hackers, empregados insatisfeitos, criminosos digitais, terroristas) Obtendo acesso não autorizado ao sistema baseado em vulnerabilidades conhecidas do sistema Quadro 2: Pares de Vulnerabilidades/Ameaças Fonte: NIST SP 800-30, 2002 Métodos indicados para identificar vulnerabilidades de ativos são o uso de fontes de vulnerabilidades, a execução de testes de segurança, e o desenvolvimento de uma lista de checklist de exigências de segurança. Devem ser observados os tipos de vulnerabilidades que existirão, e a metodologia necessária para determinar se as vulnerabilidades estão presentes
  42. 42. 42 frequentemente variará, dependendo da natureza do ativo e a fase em que se encontra:  Se o ativo ainda não tiver sido implementado, a procura por vulnerabilidades deverá focar nas políticas de segurança da organização, procedimentos de segurança planejados, e definições de requisitos de sistema, e as análises de segurança de fabricantes ou desenvolvedores (por exemplo, white papers).  Se o ativo estiver sendo implementado, a identificação de vulnerabilidades deverá ser ampliada para incluir informações mais específicas, como as características de segurança planejadas, descritas na documentação de desígnio de segurança e os resultados de certificação de testes e avaliação do ativo.  Se o ativo estiver em operação, o processo de identificação de vulnerabilidades deverá incluir uma análise das características de segurança do ativo, e os controles de segurança, técnicos e procedimentais, usados para proteger o ativo. 3.2.3.1 Fontes de vulnerabilidades As vulnerabilidades técnicas e não-técnicas associadas com um ambiente de processamento de TI podem ser identificadas através da coleta de informações técnicas descritas no Passo 1. Uma revisão de outras fontes da indústria (por exemplo, páginas Web que identificam bugs e falhas de sistemas) será útil para preparar as entrevistas e desenvolver questionários efetivos para identificar vulnerabilidades que podem ser aplicáveis para um ativo específico (por exemplo, uma versão específica de um sistema operacional). A Internet é outra fonte de informações de vulnerabilidades conhecidas postadas por fabricantes, junto com hot fixes, service packs, patches, e outras medidas que podem ser aplicadas para eliminar ou mitigar vulnerabilidades. Fontes documentadas de vulnerabilidades que devem ser consideradas em uma análise completa de vulnerabilidades incluem, mas não se limitam às seguintes:
  43. 43. 43  Documentações anteriores de avaliação de risco do ativo avaliado  Relatórios de auditoria do ativo, relatórios de anomalias do ativo, relatórios de revisão de segurança, e relatórios de avaliação e testes do ativo  Listas de vulnerabilidades  Boletins de Segurança  Boletins de fabricantes  Equipes comerciais de resposta a incidentes/emergências de computador e fóruns de discussão (por exemplo, SecurityFocus.com)  Informações seguras e alertas e boletins de vulnerabilidades para sistemas militares  Softwares de análises de segurança de sistemas. 3.2.3.2 Testes de Segurança de ativos Métodos pró-ativos, empregados para testes de sistemas, podem ser eficazmente usados para identificar vulnerabilidades do ativo, dependendo da criticidade do ativo e dos recursos disponíveis (por exemplo, recursos alocados, tecnologia disponível, pessoas capacitadas para conduzir os testes). Métodos de teste incluem:  Ferramentas de verificação automática de vulnerabilidades  Testes de avaliação e segurança  Testes de penetração Ferramentas de verificação automática de vulnerabilidades são usadas para verificar um grupo de computadores ou uma rede para serviços vulneráveis conhecidos (por exemplo, o sistema permite File Transfer Protocol (FTP) anônimo, sendmail retransmissor). Porém, deve ser notado que algumas das vulnerabilidades potenciais identificadas pela ferramenta podem não representar reais vulnerabilidades no contexto do ambiente do sistema. Por exemplo, algumas destas
  44. 44. 44 ferramentas taxam vulnerabilidades potenciais sem considerar o local e exigências do ambiente. Algumas das "vulnerabilidades" assinaladas pela ferramenta podem não ser realmente vulneráveis para um local em particular, mas podem ser configuradas desse modo porque o ambiente requeira isto. Assim, este método de teste pode produzir falsos positivos. Testes de avaliação e segurança é outra técnica que pode ser usada para identificar vulnerabilidades de ativos durante o processo de avaliação de riscos. Inclui o desenvolvimento e execução de um plano de teste (por exemplo, roteiro de teste, procedimentos de teste, e resultados esperados de teste). O propósito do teste de segurança de sistemas é testar a efetividade dos controles de segurança de um ativo que foram aplicados em um ambiente operacional. O objetivo é assegurar que os controles aplicados conheçam a especificação de segurança aprovada para o software e hardware e implementam a política de segurança da organização ou satisfazem padrões da indústria. Testes de penetração podem ser usados para complementar a revisão de controles de segurança e assegurar que diferentes facetas do ativo estão seguras. Testes de penetração, quando empregados no processo de avaliação de risco, podem ser usados para avaliar a habilidade de um ativo para resistir a tentativas intencionais de quebra de segurança de um ativo. Seu objetivo é testar o ativo do ponto de vista de uma ameaça e identificar potenciais falhas dentro do esquema de proteção de ativos. Os resultados destes testes opcionais de segurança ajudarão a identificar as vulnerabilidades de um ativo. 3.2.3.3 Desenvolvimento da Lista de Verificação de Exigências de Segurança Durante este passo, a equipe de avaliação de riscos determina se as exigências de segurança estipuladas para o ativo e coletadas durante a caracterização do ativo estão presentes nos controles de segurança existentes ou planejados. Tipicamente, as exigências de segurança de ativo podem ser apresentadas em forma de tabelas, com cada exigência acompanhada por uma
  45. 45. 45 explicação indicando porque a atual designação ou implementação do ativo satisfaz ou não aquela exigência. Uma lista de verificação de exigências de segurança contém os padrões de segurança básicos que podem ser usados para avaliar sistematicamente e identificar as vulnerabilidades dos ativos (pessoas, hardware, software, informação), procedimentos, processos, e transferências de informação associadas com um determinado ativo nas seguintes áreas de segurança:  Administrativa  Operacional  Técnica O Quadro 3 lista critérios de segurança sugeridos para uso em identificação de vulnerabilidades de ativos em cada área de segurança. (continua) Área de segurança Critérios de segurança Administração  Responsabilidades  Apoio de Continuidade  Capacidade de resposta a incidente  Revisão periódica de controles de segurança  Avaliação de risco  Treinamento técnico de segurança  Divisão de responsabilidades  Autorização de sistema  Aplicação do plano de segurança de sistema
  46. 46. 46 (conclusão) Área de segurança Critérios de segurança Operação  Controle de contaminações no ar (fumaça, pó, substâncias químicas)  Controles para assegurar a qualidade do fornecimento de energia elétrica  Acesso e disposição de mídias de dados  Capacidade de proteção (por exemplo, sala de computadores, centro de dados, escritório)  Controle de umidade  Controle temperatura  Estações de trabalho, laptops, e computadores pessoais Técnica  Comunicações (por exemplo, interconexão de sistema, routers)  Criptografia  Controle de acesso discricionário  Identificação e autenticação  Detecção de Intrusão  Auditoria de sistemas Quadro 3: Critérios de segurança Fonte: NIST SP 800-30, 2002 O resultado deste processo é a lista de verificação de exigências de segurança. Fontes que podem ser usadas para compilar tal lista incluem, mas não se limitam às seguintes fontes aplicáveis para o ambiente de processamento do ativo:  Plano de segurança do sistema avaliado  Políticas, diretrizes, e padrões de segurança da organização  Práticas da indústria O NIST SP 800-53, Controles de Segurança Recomendados para Sistemas de Informação Federais e Organizações, provê um questionário extenso que contém
  47. 47. 47 objetivos de controle específicos contra os quais um sistema ou grupo de sistemas interconectados podem ser testados e podem ser medidos. Os objetivos de controle são resumidos diretamente de exigências antigas encontradas em estatutos, políticas, e orientações em segurança e privacidade. Os resultados da lista de verificação (ou questionário) podem ser usados como contribuição para uma avaliação de obediência e descumprimento. Este processo identifica fraquezas em sistemas, processos, e procedimentos que representam vulnerabilidades potenciais. Saída do Passo 3: Uma Lista de Vulnerabilidades do ativo que poderiam ser exploradas por potenciais ameaça.
  48. 48. 48 3.2.4 Passo 4: Determinação de Probabilidades Para derivar uma taxa de probabilidade global que indique qual a probabilidade de uma potencial vulnerabilidade possa ser explorada dentro do ambiente construído, os seguintes fatores administrativos devem ser considerados:  Motivação e capacidade da ameaça  Natureza da vulnerabilidade  Existência e efetividade dos controles atuais Neste passo, serão utilizadas as saídas dos passos anteriores, traçando para cada ativo avaliado, as potenciais ameaças, as vulnerabilidades identificadas, e um nível de probabilidade da exploração de uma vulnerabilidade por uma potencial ameaça. A probabilidade que uma potencial vulnerabilidade possa ser explorada por uma determinada ameaça pode ser descrita como alta, média, ou baixa. O Quadro 4 abaixo descreve estes três níveis de probabilidade. Nível de probabilidade Definição de probabilidade Alta A ameaça está altamente motivada e suficientemente capaz, e controles para prevenir a vulnerabilidade de ser explorada são ineficazes. Média A ameaça está incentivada e capaz, mas controles estão aplicados controles que podem impedir o sucesso da exploração da vulnerabilidade. Baixa A ameaça está desmotivada ou incapaz, ou controles estão aplicados para prevenir, ou pelo menos significativamente impedir, a vulnerabilidade de ser explorada. Quadro 4: Definições de probabilidade Fonte: NIST SP 800-30, 2002 Saída do Passo 4: Relatório de Avaliação de Probabilidade (Alta, Média, Baixa)
  49. 49. 49 3.2.5 Passo 5: Análise de Impacto O próximo passo na avaliação do nível de risco é determinar o impacto adverso resultante do sucesso da exploração de uma vulnerabilidade por uma potencial ameaça. Antes de começar a análise de impacto, é necessário obter a seguintes informações, que já deverão ter sido identificadas no Passo 1:  Missão do ativo (por exemplo, os processos executados pelo ativo)  Criticidade do ativo e dos dados (por exemplo, o valor do ativo ou sua importância para uma organização)  Sensibilidade do ativo e dos dados Estas informações podem ser obtidas da documentação organizacional existente, como o Relatório de Análise de Impacto de Negócios. Uma Análise de Impacto de Negócios (também conhecida como BIA para algumas organizações) prioriza o nível de impacto associado com os ativos de informação de uma organização baseado em uma avaliação qualitativa ou quantitativa da sensibilidade e criticidade desses ativos. Se esta documentação não existe, a sensibilidade e criticidade do ativo podem ser determinadas baseadas no nível de proteção exigido para manter a disponibilidade, integridade e confidencialidade do ativo. Apesar dos métodos usados para determinar quão sensível um ativo e seus dados são, os proprietários da informação e do ativo são os únicos responsáveis por determinar o nível de impacto para o seu próprio ativo e informações. Por conseguinte, na análise de impacto, uma aproximação apropriada é entrevistar os proprietários do ativo e da informação. Então, o impacto adverso de um incidente de segurança pode ser descrito em termos de perda ou degradação de qualquer, ou uma combinação de quaisquer, dos seguintes três objetivos de segurança: integridade, disponibilidade, e confidencialidade. Alguns impactos tangíveis podem ser medidos quantitativamente em perda de faturamento, o custo de reparar o ativo, ou o nível de esforço exigido para corrigir problemas causados por uma ação bem sucedida de uma ameaça. Outros impactos
  50. 50. 50 (por exemplo, perda de confiança pública, perda de credibilidade, danos aos interesses de uma organização) não podem ser medidos em unidades específicas, mas podem ser qualificados ou podem ser descritos em termos de alto, médio, e baixo impacto. Por causa da natureza genérica desta discussão, serão designadas e descritas só as categorias qualitativas – alto, médio, e baixo impacto (Quadro 5). Magnitude do Impacto Definição do Impacto Alta A exploração da vulnerabilidade: 1. Pode resultar em perda altamente custosa dos principais tangíveis ativos ou recursos; 2. Pode significativamente violar, prejudicar, ou impedir a missão, reputação, ou interesse de uma organização; 3. Pode resultar em morte humana ou graves ferimentos. Média A exploração da vulnerabilidade: 1. Pode resultar em perda altamente custosa tangível de ativos ou recursos; 2. Pode violar, prejudicar, ou impedir a missão, reputação, ou interesse de uma organização; 3. Pode resultar em ferimento humano. Baixa A exploração da vulnerabilidade: 1. Pode resultar na perda de algum tangível ativo ou recurso; 2. Pode notoriamente afetar a missão, reputação, ou interesse de uma organização. Quadro 5: Definições de Magnitude de Impacto Fonte: NIST SP 800-30, 2002 Saída do Passo 5: Relatório de Avaliação de Impacto (Alto, Médio, ou Baixo)
  51. 51. 51 3.2.6 Passo 6: Determinação do Risco O propósito deste passo é avaliar o nível de risco para um ativo. A determinação do risco para uma ameaça/vulnerabilidade em particular pode ser expressa como uma função de:  A probabilidade de uma determinada ameaça tentar explorar uma determinada vulnerabilidade  A magnitude do impacto da exploração bem sucedida de uma vulnerabilidade por uma ameaça  A adequação de planos ou controles de segurança existentes para reduzir ou eliminar os riscos. Para medir o risco, uma escala de risco e uma matriz de nível de risco devem ser desenvolvidas. A seção 3.2.6.1 apresenta uma matriz padrão de nível de risco; a seção 3.2.6.2 descreve os níveis de risco resultantes. 3.2.6.1 Matriz de risco de nível A determinação final de risco é derivada multiplicando as avaliações determinadas para probabilidade da ameaça e impacto da ameaça. O Quadro 6 abaixo mostra como as avaliações de risco globais podem ser determinadas baseadas em contribuições da probabilidade da ameaça e categorias de impacto da ameaça. A matriz abaixo é uma matriz 3 x 3 de probabilidade da ameaça (Alta, Média, e Baixa) e impacto da ameaça (Alto, Médio, e Baixo). Dependendo das exigências do local e o nível de granularidade da avaliação de risco desejada, alguns locais podem usar uma matriz 5 x 5. Neste caso, podem-se incluir os níveis Muito Baixa/Muito Alta para probabilidade de ameaça e Muito Baixo/Muito Alto para impacto da ameaça, para gerar os níveis Muito Baixo/Muito Alto para nível de risco.
  52. 52. 52 Probabilidade da Ameaça Impacto Baixo (10) Médio (50) Alto (100) Alta (1.0) Baixo 10 x 1.0 = 10 Médio 50 x 1 = 50 Alto 100 x 1.0 = 100 Média (0.5) Baixo 10 x 0.5 = 5 Médio 50 x 0.5 = 25 Médio 100 x 0.5 = 50 Baixa (0.1) Baixo 10 x 0.1 = 1 Baixo 50 x 0.1 = 5 Baixo 100 x 0.1 = 10 Quadro 6: Matriz de nível de risco. Escala de risco: Alto (> 50 a 100); Médio (> 10 a 50); Baixo (1 a 10) Fonte: NIST SP 800-30, 2002 A matriz de exemplo no Quadro 6 mostra como os níveis de risco globais de Alto, Médio, e Baixo são derivados. A determinação destes níveis de risco pode ser subjetiva. A razão para esta justificativa pode ser explicada em termos da probabilidade determinada para cada nível de probabilidade da ameaça e um valor determinado para cada nível de impacto. Por exemplo,  A probabilidade definida para cada nível de probabilidade de ameaça é 1.0 para Alto, 0.5 para Médio, 0.1 para Baixo  O valor determinado para cada nível de impacto é 100 para Alto, 50 para Médio, e 10 para Baixo 3.2.6.2 Descrição de Nível de Risco O Quadro 7 descreve os níveis de risco mostrados na matriz anterior. Esta escala de risco, com suas avaliações de Alto, Médio, e Baixo, representa o grau ou nível de risco para qual um ativo poderia ser exposto se uma determinada vulnerabilidade fosse explorada. A escala de risco também apresenta ações que a administração sênior, tem que tomar para cada nível de risco.
  53. 53. 53 Nível de Risco Descrição de Risco e Ações Necessárias Alto Se uma observação ou descoberta é avaliada como um risco alto, há uma forte necessidade de medidas corretivas. Um sistema existente pode continuar operando, mas um plano de ação corretivo deve ser posto em prática o mais cedo possível. Médio Se uma observação for avaliada como risco médio, ações corretivas são necessárias e um plano deve ser desenvolvido para incorporar estas ações dentro de um período razoável de tempo. Baixo Se uma observação é descrita como baixo risco, os responsáveis pelo ativo devem determinar se ações corretivas ainda são requeridas ou se decidem aceitar o risco. Quadro 7: Escala de risco e ações necessárias Fonte: NIST SP 800-30, 2002 Saída do Passo 6: Relatório de Análise de Risco (Alto, Médio, Baixo). Os passos descritos nas últimas seções compõem o processo proposto neste trabalho. As próximas seções descrevem as atividades restantes do processo de elaboração de planos de continuidade e foram construídas com base nas melhores práticas da literatura e normas de mercado.
  54. 54. 54 3.3 Definição das Estratégias de Recuperação A estratégia de recuperação é desenvolvida a partir da análise dos resultados da Avaliação e Análise de Riscos e provê orientação no modo como a recuperação pode ser efetuada. A primeira fase é desenvolver um esboço das possíveis opções de recuperação que a organização poderia implementar para alcançar os seus objetivos como declarado na Política de PCN. A estratégia é desenvolvida até que a opção de recuperação mais apropriada seja escolhida. Devem ser documentadas as possíveis opções para recuperação. As opções serão definidas a partir do resultado da Avaliação e Análise de Riscos e esboçará como a área de TI pretende continuar oferecendo seus serviços para o cumprimento dos objetivos e obrigações da organização a níveis normais, a um custo-benefício aceitável, apesar da ocorrência de um incidente que afete a habilidade dela para operar. Devem ser determinadas opções para as seguintes áreas:  Equipes (incluindo habilidades e conhecimento);  Premissas (local de trabalho e locais onde a informação é guardada);  Tecnologia (telefonia, dados, aplicações, sistemas);  Estoques (materiais e equipamentos); Exemplos de risco de continuidade poderiam incluir:  Administração de Registros – A identificação de que o armazenamento, arquivamento e recuperação de registros são pobres, podendo ter como conseqüência sua indisponibilidade quando requeridos e gerando uma falha de regulamentação ou risco de perda de reputação.  Equipe de treinamento – A identificação de baixos níveis de conhecimento diversificado, treinamento ou planejamento de sucessão. Isto poderia conduzir a um risco de continuidade existir níveis acima da
  55. 55. 55 média de doenças, greve ou um membro fundamental da equipe ficar indisponível durante várias semanas ou meses.  Plano de backup – Sendo identificados riscos com respeito à backup de dados e a recuperação e restauração destes dados. As atividades de planejamento para endereçar os riscos de continuidade devem ser implementadas e deve ser relatado o trabalho já completado para assegurar que o prazo final para a entrega do PCN será alcançado. As opções dependerão de:  Objetivos do Tempo de Recuperação para os processos críticos;  Objetivos do Ponto de Recuperação para os dados críticos;  Interdependência de componentes;  Custos de implementação das várias opções;  Conseqüências de inércia Deve ser observado que a organização deve minimizar a probabilidade de implementar uma solução que pode ser impactada pelo mesmo incidente que causou a interrupção do negócio. Por exemplo, mudando a operação de um Data Center para uma localização que poderia ser também afetada pelo mesmo corte de energia, quebra de telefonia ou inundação. As estratégias adotadas são freqüentemente bastante complexas e será tipicamente uma ou uma combinação das seguintes opções:  Provisão feita dentro da organização (Deslocamento, Trabalho Remoto);  Serviços entregues à organização (instalações móveis ou unidades pré-fabricadas);  Serviços providos externamente por um terceiro (Área de Trabalho de Recuperação Instalações);  Locais espelhados que são idênticos aos locais primários em todos os aspectos técnicos;
  56. 56. 56 Há várias opções disponíveis dependendo da estratégia de tecnologia da organização, e a solução pode ser complexa. Estas opções podem ser classificadas como cold, warm ou hot sites, com vantagens e desvantagens apresentadas em cada uma. A escolha destas opções dependerá de fatores como:  Tempo de retorno para processos que apóiam as atividades críticas identificados no negócio;  Um processo com tempo de retorno menor que um dia requererá táticas que permitam a atividade a ser assumida em outros locais, ou recolocação rápida do pessoal afetado;  Local e distancia entre sites de tecnologia;  Número de sites de tecnologia;  Acesso remoto;  Conectividade e redundância de telecomunicações;  Estratégia de backup (por exemplo diário, semanal, mensal, Compact Disc (CD), fita, Redundant Array of Independent Disks (RAID));  Conectividade de terceiros e ligações externas. 3.4 Desenvolvimento do PCN Uma vez que as estratégias foram determinadas e qualquer risco de continuidade tenha sido endereçado, a organização deverá decidir como deseja apresentar o PCN. O PCN deverá suprir no mínimo a três conjuntos de atividades para as quais estão correlacionadas as três fases de um incidente, como mostrado em Figura 5.  Responder, a um incidente, emergência ou desastre.  Recuperar, atividades críticas do negócio (isto pode incluir soluções de contorno temporárias no caso da ausência de tecnologia essencial).
  57. 57. 57  Retomar, o funcionamento normal de todas as operações empresariais das medidas temporárias adotadas durante a recuperação. Figura 5: A Linha do Tempo de Incidentes Fonte: ENISA, 2008 3.4.1 Conjunto de documentos O conjunto de documentos que incluem o PCN variará de organização a organização, mas é recomendado que os planos seguintes, apresentados no Quadro 8, sejam considerados. Em organizações menores estes planos poderão ser combinados em um, mas em organizações maiores eles provavelmente existirão ou como entidades separadas ou alguns dos planos combinados juntos. Dentro de minutos a horas: Equipes e visitantes estimam vítimas, tratando da contenção de danos / limitações de avaliação de danos, invocando o gerenciamento de incidentes. Dentro de minutos a dias: Comunicação a equipes, clientes, fornecedores etc. Recuperação de atividades de negócios críticas. Reconstrução de trabalho perdido em progresso. Dentro de semanas a meses: Reparação de danos / substituição. Recolocação para o local fixo de trabalho, retomando o funcionamento normal. Recuperação de custos de seguradoras. Objetivo de recuperação global: Retornar para normalidade tão rápido quanto possível Linha do Tempo Resposta Recuperação Reinício T e m p o Z e r o Incidente
  58. 58. 58 (continua) Plano Linha do Tempo Propósito do Plano Plano de Resposta a Incidente Resposta Administrar o resultado imediato de um incidente, inclusive evacuação, ligação com serviços de emergência e saúde, segurança e bem-estar do pessoal e público Plano de Gerenciamento de Incidente Recuperação Administrar o incidente centralmente e assegurar que as equipes que efetuam a recuperação estão equipados com seus recursos críticos Plano de Recuperação de Negócios Recuperação Prover as equipes que estão recuperando os seus processos críticos, com as listas de ações necessárias, informações, procedimentos e detalhes de contato Planos de Apoio à Recuperação - Plano de Recursos Humanos (RH) - Plano Instalações - Plano de Saúde e Segurança Recuperação Prover as equipes times que têm papéis especialistas em um incidente com as informações necessárias e procedimentos para poder apoiar as equipes de recuperação Plano de continuidade de Serviços de TI Recuperação e Reinício Detalhar as ações que integrantes das equipes de tecnologia e segurança da informação deverão seguir para restabelecer os componentes críticos aos processos críticos dentro do acordado nos componentes Recovery Time Objective (RTO) e Recovery Point Objective (RPO)
  59. 59. 59 (conclusão) Plano Linha do Tempo Propósito do Plano Plano de Comunicações e Mídia Resposta, Recuperação e Reinício Este plano contém toda a informação necessária para habilitar a equipe de Comunicação e Mídia para comunicar com precisão e efetivamente com o pessoal, clientes, público, provedores e mídia Plano de Reinício de Negócios Reinício Este plano detalha os procedimentos a seguir para devolver a organização à normalidade. Pode ser um plano ou umas séries de planos e poderá incluir planos de projeto de longo alcance Quadro 8: O uso das partes constituintes do PCN durante cada fase de um incidente Fonte: ENISA, 2008 Quando O PCN é introduzido em uma organização um dos resultados é a produção de um número de documentos, nem todos os quais necessariamente são incluídos no PCN (por exemplo, um número de políticas e procedimentos como políticas de RH). O PCN pode ser usado em isolado para efetuar a recuperação no caso de um incidente afetando a organização, mas na realidade ele interage com outros documentos nas áreas de Administração de Risco, Segurança de Informação, RH/Saúde e políticas de Segurança e Continuidade de Serviços de TI. Alguns dos documentos e processos já existentes exigirão modificação como diferentes informações são requeridas. O RH, por exemplo, precisará de informações de parentes com detalhes de contato atualizados. Este sistema exigirá mudanças no processo de administração para assegurar que a informação é atual, uma política de segurança de informação para assegurar que não é amplamente acessível e para assegurar que a informação estará disponível durante um incidente envolvendo o repositório de informações. Os detalhes das interfaces entre estes programas (Gestão de Continuidade de Serviços de Tecnologia da Informação (GCSTI), Gestão de Continuidade de Negócios (GCN), Gestão de Riscos (GR)) depende da organização e do método de implementação.
  60. 60. 60 3.5 Teste do Plano de Continuidade de Negócios BS 25999-1 declara que a Continuidade de Negócio e Administração de Incidentes de uma organização não podem ser considerados seguros até serem testados. Testar é essencial para desenvolver trabalho em equipe, competência, confiança e conhecimento os quais são vitais na hora de um incidente. ISO 27002 vai além declarando que os testes deveriam assegurar que todos os membros das equipes de recuperação e outras equipes pertinentes estão conscientes dos planos e de sua responsabilidade para com a Continuidade de Negócios e a segurança de Informação, como também sabem seu papel quando um plano é invocado. 3.5.1 Determinando o tipo de teste Há muitos modos de testar que um PCN é adequado para propósito e a tabela abaixo descreve vários destes métodos. O método escolhido dependerá da maturidade de GCN dentro da organização e dos testes que tenham sido administrados anteriormente. Em alguns casos, pode ser uma boa idéia designar algumas das pessoas envolvidas (empregados e também consultores externos de confiança) no papel de facilitadores e observadores, para ajudar a conduzir e entender o teste. O promotor do teste ou exercício fará um resumo aos participantes dos objetivos do teste e fixará o cenário. Durante o teste, ele coordenará as atividades de e assegurará que o teste ocorre de acordo com o tempo programado. Depois do teste, o promotor será responsável por escrever um Relatório de Teste. Um observador observa o teste e não participa em nenhum momento do mesmo. Ele registra os resultados do teste, como progride, quais os fatores prós e contra o sucesso do teste identificados. Ele ajudará o promotor do teste sumarizando os pontos chave observados e passará seus resultados para a elaboração do Relatório de Teste a ser escrito.
  61. 61. 61 3.5.2 Escrevendo o plano de teste Para produzir o máximo valor de um teste, um Plano de Teste deverá ser desenvolvido para definir os elementos selecionados, os objetivos de teste explícitos e quais os critérios de sucesso. O plano de teste deverá conter um horário que detalha os prazos para cada teste e participantes do teste e deverá delinear a extensão, os objetivos, o enredo e a logística empregada claramente. O enredo desenvolvido deverá ser tão realístico quanto possível para testar o plano corretamente e ganhar o apoio máximo dos participantes. Em alguns testes é apropriado buscar envolvimento de pessoal externo como serviços de emergência, segurança, peritos e provedores especializados. Questionários deverão ser preparados para que observadores possam registrar as observações deles durante o teste. 3.5.3 Conduzindo o teste Antes do teste, os participantes deverão ser providos com toda a informação necessária e deverá ser feito um resumo sobre a “situação”. Os participantes fazem sua parte no teste usando os planos relacionados que são fornecidos pelo Promotor. Os Observadores determinam quais aspectos do teste estão observando e registram o que eles vêem e ouvem no questionário. Depois do teste o Promotor e os Observadores deverão documentar os resultados do teste e identificar potenciais ações de melhoria. 3.5.4 Comunicando o resultado do teste Tão logo seja possível, deverá ser conduzida após o teste uma apresentação onde os participantes reportarão o que eles perceberam que foi bem, o que foi mal e onde sua reação pode ser melhorada. A apresentação deve incluir todos os
  62. 62. 62 participantes, os observadores e todos os com responsabilidade para manutenção do plano ou ativação no futuro. Ao término da apresentação, responsáveis por atividades de melhoria do plano deverão ser nomeados. O resultado final dessa fase será a produção de um Relatório de Teste que esboça a extensão, aproximação, método e resultados do teste com as recomendações para ação e os responsáveis pela ação. 3.6 Manutenção do Programa de Gestão de Continuidade de Negócios Planos podem ficar obsoletos muito rapidamente (particularmente listas de contato) e até mesmo depois de algumas semanas, se não atualizados, a efetividade e relevância de planos podem começar a deteriorar. Após a implementação do PCN testado, é então necessário manter o plano atualizado, assegurando que todo o pessoal envolvido no andamento da GCN ou administração e resposta de incidentes foi treinado nos seus papéis e a divulgação da GCN é destacada em todos os níveis por toda a organização. 3.6.1 Treinamento de equipes [NIST 800-34] aconselha que treinamento para o pessoal com responsabilidades de Continuidade de Negócios deverá complementar as provas. Treinamentos deverão ser providos pelo menos anualmente; novos membros que terão responsabilidades no plano devem receber treinamento tão logo sejam contratados. No final das contas, todo o pessoal deve ser treinado até o ponto em que eles estejam aptos a executar a resposta a incidentes e procedimentos de administração de incidentes sem a ajuda dos documentos. Treinamentos deverão envolver:  Propósito do plano  Relacionamento entre equipes de coordenação e comunicação
  63. 63. 63  Apresentação de procedimentos  Arranjos de segurança  Equipes de processos específicos  Responsabilidades individuais [TR 19:2005] recomenda que treinamentos sejam também dirigidos a grupos específicos, como mostrado no Quadro 9 abaixo: Alvo Descrição Todo o pessoal Treinamento de divulgação básico o qual dá para a equipe uma percepção básica em Continuidade de Negócios e os informa sobre os Planos de Recuperação de Negócios e o que acontecerá a eles durante um incidente. Equipe de administração Treinamento administrativo para informar os gerentes sobre a abrangência de resposta e administração de incidentes, o propósito dos Planos de Recuperação de Negócios, o que se espera que façam durante um incidente e como eles irão implementar seus planos. Pessoal de Continuidade de Negócios e Incidente Treinamento especializado para treinar todo o pessoal envolvido em resposta, administração e recuperação de incidentes. Isto provavelmente irá envolver vários cursos de treinamento diferentes. Quadro 9: Níveis de treinamento de Administração de Continuidade de Negócios Fonte: ENISA, 2008 Exemplos dos tipos de cursos de treinamentos que poderão ser apresentados ao pessoal no terceiro grupo são:  Evacuação  Comunicações de mídia  Estabelecimento de uma sala de incidentes  Administração de incidentes
  64. 64. 64  Comunicações de crise  Trabalho em locais alternativos Treinamentos deverão também ser providos para o pessoal que formará a Equipe de Administração de Continuidade de Negócios que deverá cobrir:  Programa de Administração  Condução de uma BIA  Projetando e implementando PCNs  Avaliação de riscos e ameaças  Desenvolvimento de testes e exercícios O programa de treinamento de Continuidade de Negócios deverá ser embutido dentro do programa de treinamento e desenvolvimento da organização. Detalhes de treinamentos específicos e sua freqüência (levando em conta treinamento adicional assim como treinamento de novos membros das equipes) deverão ser incluídos em um Manual de Treinamento que fará parte do portfolio de treinamentos da organização. Idealmente, o treinamento geral de Continuidade de Negócios deverá ser incluído dentro do programa de apresentação de forma que todo o pessoal seja alertado sobre Continuidade de Negócios desde o começo de sua carreira. 3.6.2 Manutenção e revisão do Plano de Continuidade de Negócios O programa deverá assegurar que qualquer mudança (interna ou externa) a qual impacte na organização será revisada em relação ao PCN. Também deverá identificar qualquer novo produto novo e serviço e suas atividades dependentes que precisam ser incluídas no programa de manutenção da GCN. Se houver qualquer grande mudança empresarial, uma revisão da BIA deverá ser empreendida. Podem ser corrigidos os outros componentes do programa de GCN para levar conta estas mudanças.
  65. 65. 65 A alta administração da organização deverá, a intervalos que julgar apropriado, revisar a capacidade de GCN da organização para assegurar sua contínua conveniência, suficiência e efetividade. Esta revisão deverá ser documentada e deverá assegurar dentro do programa de GCN:  Que foram identificados todos os produtos e serviços chave e as atividades e recursos críticos apoiados por eles tenham sido incluídos na estratégia de GCN;  A política de GCN, estratégias, e planos refletem prioridades e exigências com precisão;  A competência de GCN e capacidade são efetivas e adequadas para o propósito e permitirá a administração de comando, controle e coordenação de um incidente;  As soluções de GCN são efetivas, adequadas para o propósito e apropriadas ao nível de risco enfrentado pela organização;  Estratégias de GCN e planos incorporam melhorias identificadas durante incidentes e exercícios como também no programa de manutenção;  A organização tem um programa contínuo para divulgação e treinamento de GCN;  Procedimentos de GCN foram efetivamente comunicados às equipes relacionadas, que entendem seus papéis e responsabilidades;  Os programas de manutenção e treinamento de GCN foram implementados e exercitados efetivamente;  Processos de controle de mudança estão sendo usados e operando efetivamente. Detalhes dos períodos de revisão e freqüência de testes e treinamento podem ser incluídos em um documento de Manutenção e Revisão separado. Este documento especifica como e quando o PCN será revisado e será testado e o processo para manutenção do plano. Os intervalos entre testes e revisões dependerão da organização, sua complexidade e taxa de mudança. Uma programação de treinamento também poderá ser incluída.
  66. 66. 66 A organização deverá prover para uma auditoria independente de sua competência de GCN a capacidade para identificar deficiências atuais e potenciais. Auditorias independentes podem ser administradas por pessoas competentes externas ou internas. O PCN poderá conter informação sensível (por exemplo, números de contato de executivos ou localização de registros vitais) que deverá ser protegida adequadamente. Deverão ser armazenadas cópias do PCN em um local remoto, a uma distância suficiente para escapar de qualquer dano de um incidente no local principal. A administração deverá assegurar que cópias do PCN são atualizadas e protegidas com o mesmo nível de segurança como aplicado no local principal [ISO 27002]. Uma vez que o PCN tenha sido embutido na organização como um processo de administração contínuo ele entra em um ciclo de iteração; sendo revisado a intervalos regulares e atualizado quando necessário. 3.6.2.1 Gerenciamento de mudanças Mudanças para o PCN as quais tenham sido identificadas como resultado de exercícios, testes, treinamentos desenvolvimentos organizacionais não podem ser feitos sem atravessar o processo de Gerenciamento de Mudança. O que pode parecer ser pequenas mudanças no nível de uma unidade empresarial pode ter impactos significantes no PCN em outras áreas. As mudanças devem ser aprovadas pelo Gerente de Continuidade de Negócios e se necessário ir antes ao Comitê Dirigente de Continuidade de Negócios para aprovação final. O Gerente de Continuidade de Negócios será responsável por emitir as mudanças conforme os procedimentos da organização para documentação e controle de versão.
  67. 67. 67 3.6.2.2 Melhoramento contínuo Melhoria contínua, com respeito à qualidade e desempenho da organização, foca em melhorar a satisfação dos clientes através de contínuos e incrementais melhoramentos de processos, inclusive a remoção de atividades desnecessárias e variações. A administração de continuidade de negócios deverá então ser incluída como parte do processo de melhoria contínua para assegurar que o plano permanece efetivo e executável e é adotado por cada um dos membros das equipes em todos os níveis dentro da organização. 3.6.3 Desenvolvendo a divulgação É necessário comunicar a mensagem de Continuidade de Negócios a todo o pessoal de forma que eles estejam informados sobre os princípios fundamentais de Continuidade de Negócios. Isto será embutido na cultura empresarial de forma que se torne hábito e parte dos valores principais da organização. Há vários modos pelos quais as informações podem ser comunicadas:  Cursos e treinamentos  Treinamento induzidos  Enredo de exercícios e testes  Artigos nos boletins informativos da organização  Inclusão na intranet  Ordem do dia em reuniões Ao longo do programa de GCN e no ciclo subseqüente de manutenção de GCN, o pessoal de equipes de todos os níveis deverá ser consultado sobre Continuidade de Negócios e suas idéias, se aprovadas, incorporadas no PCN.
  68. 68. 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.

×