fonte: bestnuc.com,dilbert.com
O NIST 800-34 é um documento que foi criado para levar às várias agência americanas um modelo único de criação de planos de contingência e continuidade de negócios, utilizando-se para isso mais alguns documentos base como o NIST 800-30.
Este documento esta direcionado para a criação de planos de contingência dos serviços mais comuns encontrados dentro de uma estrutura de TI das agências governamentais americanas mas, que pode ser utilizada diretamente por empresas e organizações não americanas. O documento descreve a criação dos planos para os seguintes serviços:
a) Desktop e sistemas portáteis
b) Servidores
c) Sites web
d) Local Area Network (LAN)
e) Wide Area Network (WAN)
f) Sistemas distribuídos
g) Sistemas de Manframes.
No entanto, são amplamente utilizados para outros sistemas que não os relacionados diretamente mas, que podem ser muito próximos.
São etapas presentes no documento e que são parte integrante do planejamento de criação do Plano de Contingência:
a) Desenvolvimento de uma Declaração de uma Política do Plano de Contingência
b) Execução de um BIA (Business Impact Analisys)
c) Identificação preventiva dos controles existentes
d) Desenvolvimento de uma estratégia de recuperação
e) Desenvolvimento de um Plano de Contingência de TI
f) Planejamento dos testes, treinamento e exercícios
g) Plano de manutenção
Estas etapas são importantes e devem, dentro do possível, ser mantidas no plano de desenvolvimento de Planos de Contingência.
3.1.1 Desenvolvimento de uma Declaração de Política do Plano de Contingência.
Para que o plano seja criado e seguido de uma forma efetiva, este deve ser baseado em uma política formal e implementada dentro da estrutura de documentação. Esta política deve descrever os objetivos, e de forma geral, as responsabilidades.
Para que tenha uma maior eficiência, esta política deve ser apoiada diretamente pela Direção, que atribuirá responsabilidades e determinará a criação da equipe do plano de contingência.
A seguir, uma estrutura sugerida para a Política:
a) Papeis e Responsabilidades
b) Escopo do plano, apontando, tipos de serviços, plataformas e objetos do plano de contingência
c) Recursos Necessários
d) Treinamentos necessários
e) Calendários de testes e exercícios
f) Calendário de manutenção
g) Frequência do Backup e o armazenamento das mídias.
Ainda, deve-se levar em consideração, as outras políticas e normas utilizadas dentro da estrutura das empresas que devem ter o cuidado de manter a integridade entre as várias documentações existentes.
3.1.2 Execução de um BIA (Business Impact Analisys)
O BIA é o passo necessário e essencial para a realização de um Plano de Contingência com eficiência e bem realizado. É por meio do BIA que a equipe de desenvolvimento do plano vai ser capaz de identificar requisitos dos sistemas, processos e interdependência entre os mais diversos sistemas, e isso será usado para criar a matriz de prioridades de sistemas a serem colocados no Plano.
O propósito do BIA é relacionar componentes críticos do sistema com serviços críticos que eles executam, e com base neste mapa de correlação, categorizar as consequências que podem acontecer com os serviços mapeados.
Ainda são pontos importantes para a criação do relatório final do BIA a identificação de recursos críticos. Esta identificação basicamente é realizado por dois processos distintos.
a) Identificação de Pontos Únicos de Contato (POCs)
b) Identificação de impactos nos serviços ou recursos e o tempo máximo suportado (fora do ar).
O segundo ponto presente no relatório, é o desenvolvimento e criação da matriz de prioridades, tendo como base a identificação de serviços críticos e os seus impactos ao negócio.
3.1.3 Identificação de controles já existentes
Para que os trabalhos dentro do planejamento seja mais eficiente, devem ser identificados os controles de danos e riscos já existentes dentro da estrutura de TI, e estes devem ser relacionados em uma matriz de riscos, vinculando aos serviços e recursos críticos.
Quando possível e o custo for menor, devem ser utilizados sistemas de controles de riscos e paralisações, e são exemplos disso, UPS, Sistemas Supressores de Incêndio, Sistemas detectores de fumaça, HVAC apropriados e plásticos para cobrir equipamentos em caso de vazamentos de água.
Estes controles devem ser relacionados no Plano de Contingência e as pessoas envolvidas com estes controles devem ser identificados e treinados.
3.1.4 Desenvolvimento de Estratégias de Recuperação
Os procedimentos criados nesta etapa proporcionam que o serviço ou recurso seja restaurado dentro do tempo e das necessidade identificadas.
Para que seja o mais eficiente possível, várias alternativas devem ser identificadas e estas devem ser avaliadas por vários pontos como custo, impacto, risco e tempo de retorno do serviço. Isso vai proporcionar ao time de plano de contingência a utilização da melhor alternativa possível para aquele serviço ou recurso.
São estratégia aceitas:
a) Métodos de backup
b) Sites alternativos
c) Substituição de equipamentos
Não podemos esquecer que nesta etapa devem ser criadas as matrizes de responsabilidades e papeis e que todas as estratégias devem ser levadas em consideração dentro de um estudo de avaliação do custo de implantação, uso e manutenção das alternativas escolhidas.
3.1.5 Planejamento dos testes, treinamento e exercícios
Os testes são fatores fundamentais para a identificação de possível falhas nos planos desenvolvidos e por isso devem ser executados de forma periódica e sempre documentada. Outro benefício dos testes é identificar se o pessoal responsável por executar o plano de contingência é capaz de fazê-lo e se tudo aconteceu conforme foi planejado.
Para que o processo de teste seja melhor aproveitado, todo teste devem ser realizado com uma finalidade definida e com um plano específico, e este deve ser documentado e posteriormente analizado para saber se os objetivos foram alcançados.
Dois modelos de teste podem ser aplicados:
a) Tablestop ou o walkthroug : Onde os testes são realizados somente com a leitura dos planos e a identificação de pontos que podem ser problemáticos para a equipe executar. Este é o tipo mais barato de teste a ser executado e, de preferência, deve ser executado somente após um exercício funcional ser feito.
b) Exercício Funcional : Neste tipo de teste, um evento falso é criado e a equipe deve executar o plano dentro das atividades planejadas. Este tipo de teste deve ser executado somente com a autorização da direção que deve conhecer os possíveis impactos do teste dentro do ambiente real.
3.1.6 Plano de Manutenção
É essencial que os planos possuam manutenção adequada e que esta seja feita periodicamente para que os responsáveis de execução tenham certeza de que ao utilizar os planos estes estão dentro do esperados e representam a realidade dos serviços e recursos da estrutura de TI.
É adequado imaginar que a revisão dos planos, ocorra pelo menos uma vez ao ano ou sempre que a estrutura de TI sofrer mudanças significativas em seus componentes. É natural que alguns sistemas ou recursos sejam mais críticos que outros e os planos relacionados a estes devam ter uma maior constância em suas revisões.
Um fato importante deve ser observado. Como os planos de contingência são documentos que possuem informações sobre pessoas, serviços e recursos importantes para a empresa, estes devem ser distribuídos observando-se a necessidade de acesso das pessoas e a classificação das informações existentes.
As mudanças devem ser sempre documentadas e registradas dentro do próprio documento, a seguir um modelo de tabela de registro de mudanças.
3.1.7 Desenvolvimento de um Plano de Contingência de TI
Esta etapa é a etapa crítica do desenvolvimento do plano de contingência e deve apresentar de forma clara os papeis, os responsáveis, o time de recuperação e os procedimentos necessários para recuperação de cada serviço ou recurso identificado no processo de identificação de serviços e recursos chave para o negócio.
É uma das fases mais importantes do Plano de Contingência, pois é esta fase a responsável pela criação do plano propriamente dito e deve ser observado com muito cuidado. Sugerimos que seja observado o que esta descrito no item 4 do documento do NIST 800-34 para maiores informações.
É evidente que a contingência de serviços e recursos é um dos pontos mais importantes de qualquer planejamento dentro da estrutura de TI de uma empresa, e deve ser observado dentro das melhores práticas e modelos de mercado. É aconselhável a todas as empresas que desejam uma melhor gestão sobre suas estruturas de TI, que suas equipes sejam treinadas e acompanhadas em sua formação.