Sua Organização Está Preparada para uma Contingência

Sua Organização Está Preparada para uma Contingência? Marisa de Oliveira Santos Amaro 1,2 1

Marinha do Brasil Pagadoria de Pessoal da Marinha Marinha – Rio de Janeiro Janeiro – RJ 2

Programa de Pós-Graduação de Engenharia de Sistemas e Computação Universidade Federal do Rio de Janeiro (UFRJ) – Rio de Janeiro – RJ [email protected],

[email protected]

This paper intends to encourage IT professionals and executives to think about the degree of preparedness of their organisations for a contingency   situation. The diversity of information systems support solutions requires a   suitable planning of the activities for protection and recovery of crucial  resources. The results of this task depend on cooperative work of executives, chiefs information officers, application developers and database administrators.

 Abstract.

Este artigo tem o propósito de motivar profissionais de tecnologia da informação e da área de gestão executiva a refletir sobre o grau de prontidão de   suas organizações com respeito a aspectos de segurança da informação relacionados ao planejamento de contingências e procedimentos de recuperação   para continuidade de negócios. A diversidade de soluções para suporte aos   sistemas de informação requer o adequado planejamento das atividades de   proteção e recuperação dos recursos identificados como vitais para a organização e os resultados de tal tarefa dependem da eficiência do trabalho cooperativo de executivos, gerentes de informação, desenvolvedores de aplicação e administradores de bases de dados.  Resumo.

1. Introdução   No mundo digital dos dias atuais, a tecnologia de informação (TI) adquiriu  status de componente essencial para prover produtividade no desempenho das funções cotidianas executadas em uma organização. A informação, em si, constitui valioso patrimônio e sua integridade e disponibilidade são fatores cada vez mais críticos, que determinam a sobrevivência de uma empresa em um ambiente de alta competitividade. Este artigo pretende estimular profissionais de TI e da área executiva a refletir  sobre o grau de prontidão existente em suas organizações para situações de contingência, considerando-se o nível de dependência por elas apresentado em relação a sistemas de informação como componentes requeridos para a plena consecução de sua missão ou atividade-fim. atividade-fim. Neste contexto, serão abordados o nível de responsabilidade e os diferentes  papéis desempenhados por integrantes de equipes de contingência, contingência, sendo apresentada uma   proposta de modelo de estrutura organizacional para o trabalho cooperativo de   planejamento e execução, incluindo profissionais de diferentes setores, responsáveis por  funções gerenciais e também funções da área técnica, como desenvolvimento, manutenção, suporte, infra-estrutura e operação de sistemas de informação.

A motivação para o presente trabalho decorre da constatação da frequente inexistência do nível necessário de conscientização interna para a área de segurança da informação, no que se refere ao planejamento de contingências. Este segmento vem recebendo significativo incremento de soluções de mercado, principalmente depois dos atentados terroristas ocorridos em 2001 contra o World Trade Center, em razão dos quais várias empresas simplesmente desapareceram devido à impossibilidade de recuperação em tempo hábil de suas informações vitais. No Brasil, embora a área de contingências e recuperação de desastres se encontre ainda em fase inicial, existem algumas empresas especializadas em oferecer tais serviços. Em nosso país, o menor grau de ameaças externas   provenientes de desastres naturais como terremotos, maremotos, tornados e nevascas talvez transmita a falsa sensação de que interrupções de energia (os chamados “apagões ”), vírus, hackers, incêndios e falhas humanas são ameaças contornáveis, que não exigem  planejamento detalhado.   Nos Estados Unidos, estatísticas do U.S. Bureau of Labor estimam que, das empresas que venham a experimentar alguma situação de desastre sem ter um plano de contingência e recuperação, cerca de 43% nem sequer reabrirão seus negócios após o desastre, 80% sobreviverão até o primeiro ano seguinte e 93% encerrarão suas atividades, no máximo, cinco anos depois. A IBM divulgou uma pesquisa na qual afirma que apenas 8% dos negócios de Internet estão preparados para uma situação de contingência. Como caso de estudo para o planejamento de contingências e operações de recuperação de negócios, será abordada a experiência adquirida, há mais de seis anos, por  integrantes da Pagadoria de Pessoal da Marinha, por meio do trabalho cooperativo entre usuários, equipes de TI e elementos responsáveis por funções de logística e segurança orgânica das instalações. A Pagadoria de Pessoal da Marinha (PAPEM) é o órgão da Marinha do Brasil (MB) que tem por missão executar o pagamento de todo o pessoal civil e militar desta Força. Adicionalmente, a PAPEM responde também pela manutenção do ambiente operacional que hospeda sistemas corporativos da Marinha executados na  plataforma mainframe (computadores de grande porte) e pelas conexões de rede estabelecidas com bancos conveniados e entidades externas à MB. Embora mencione a segurança de informação com acentuada frequência, o presente artigo não tem a pretensão de apresentar uma abordagem completa dos aspectos centrais deste amplo campo de estudo. O foco da discussão aqui conduzida situa-se, portanto, nos aspectos de segurança mais intimamente relacionados ao planejamento de contingências e  procedimentos de recuperação de negócios. Para apresentar os temas selecionados, o texto foi organizado como descrito a seguir. A próxima seção discorre sobre etapas do ciclo de segurança, a definição de uma   política de segurança e fatores a ela relacionados, sendo descrito como o campo de   Planejamento de Contingências e Recuperação de Negócios está inserido neste contexto.   Na seção 3, apresenta-se a estrutura recomendada para um Plano de Contingência e Recuperação de Negócios, bem como considerações sobre os planos decorrentes e a distribuição, manutenção e revisão do plano. A seção 4 apresenta um modelo de estrutura organizacional para a contingência. Em seguida, na seção 5, sugere-se um checklist  em forma de questionário, que serve para avaliar, ainda que de modo superficial, o grau de prontidão para situações de contingência. Por fim, na seção 6, são expostas conclusões e lições aprendidas.

2. A Política de Segurança e o Planejamento de Contingências Para se alcançar o nível pretendido de proteção à informação – entendida como um   patrimônio ativoda organização -, torna-se imprescindível estabelecer uma política organizacional de segurança. Mesmo em pequenas empresas, onde a complexidade sistêmica pode, às vezes, induzir à equivocada conclusão de que o planejamento é desnecessário, é fundamental definir procedimentos de segurança (aí incluídos aqueles relativos à contingência e recuperação) que, uma vez estabelecidos, sejam divulgados para todos os integrantes da organização. A tarefa de definição da política de segurança organizacional constitui uma das principais etapas do chamado ciclo de segurança, como ilustrado pela Figura 1.

Análise dos Riscos e Ameaças

Definição da Política de Segurança

Implantação Administração Auditoria

Figura 1. Etapas Típicas do Ciclo de Segurança

2.1. Riscos e Ameaças A etapa inicial do ciclo corresponde a uma análise de riscos e ameaças (usualmente, denominada Business Impact Analysis – BIA), onde são estudadas criteriosamente as   potenciais exposições às quais a informação pode estar submetida, considerando-se a   probabilidade de ocorrência de situações de prejuízo. Deve-se determinar o nível aceitável para os controles de segurança, custos de implantação e também o risco admitido  para as condições que não forem completamente cobertas, procurando-se avaliar o impacto da perda de informações classificadas como sensíveis e quantificá-lo, quando possível, em termos de dias de paralisação e prejuízo financeiro total. Antes do surgimento da Internet e da tecnologia de redes, a questão da administração da segurança e proteção da informação apresentava um perfil notadamente centralizado, focado em programas normalmente executados em mainframes e instalações com arranjo típico de CPD (centro de processamento de dados), onde se localizavam todos   – ou, pelo menos, os mais críticos – os recursos de TI necessários à atividade da organização. Os planos de contingência surgiram para a proteção deste ambiente e tinham seu foco direcionado particularmente às atividades de TI. Com as facilidades de rede, os recursos disponibilizados pela Web e a quase ubíquidade de acessos remotos determinada pelas necessidades de certos tipos de negócio, as organizações passaram a ser submetidas a um universo de ameaças mais diversificado e a abordagem de segurança precisou de uma abrangência mais ampla, de modo a dotar as empresas de mecanismos de segurança capazes de identificar, proteger e recuperar dados

vitais para o domínio do negócio considerado, mantendo-os acessíveis para os sistemas de informação. Os planos de contingência passaram, então, a abordar as tarefas de recuperação tendo como foco não apenas as atividades de TI, mas também variáveis diretamente associadas ao negócio da organização e aos requisitos de continuidade necessários para sua sobrevivência em situação de desastre. Pela definição de [DRII2003], um desastre é um evento que ocorre repentina e inesperadamente, com significativas consequências de danos e perdas para uma organização. A Figura 2 mostra o relacionamento entre os principais fatores de segurança que devem ser considerados em uma abordagem de TI. Como se pode ver, os diferentes fatores estão ligados tanto a componentes de hardware e software como a aspectos organizacionais e de recursos humanos. Infra-estrutura

Recursos Tecnológicos - Software - Hardware - Rede - Comunicações - Gestão de TI

- Energia - Ar condicionado - Proteção Física - Manutenção - Segregação de Compartimentos

SEGURANÇA DA INFORMAÇÂO

Recursos Humanos

- Identificação de Usuários - Controle de Acesso

Organização - Nível de Criticidade da Informação - Salvaguardas Legais - Treinamento - Cultura Organizacional

Figura 2. Segurança da Informação - Fatores Principais

Às ameaças, internas e externas, associadas aos fatores considerados na Figura 2,   podemos ainda acrescentar incidentes de segurança como incêndios, alagamentos, interrupções no fornecimento de energia e pane em serviços de comunicação e ar  condicionado. Em função do negócio da organização e do necessário suporte por parte do ambiente de TI, as ameaças devem ser analisadas de forma conjugada com os riscos relativos aos sistemas de informação, que podem resultar na perda ou adulteração da informação e/ou indisponibilidade do serviço ou negócio. O objetivo da análise de ameaças e riscos é buscar o equilíbrio inteligente entre risco, eficiência e custo. E, por este motivo, a política e a cultura de segurança são o  ponto central para o desenho de qualquer solução, pois para manter a segurança de uma organização e o grau de prontidão necessário para reação em situação de real contingência

é fundamental que seus componentes estejam treinados e alinhados com os corretos  procedimentos a serem observados no trabalho diário.

2.2. Definição e Implantação da Política de Segurança A definição da política de segurança tem o objetivo de prover diretrizes para a proteção adequada aos equipamentos, funcionários, instalações, meios de comunicação e bens   patrimoniais necessários ao cumprimento da missão da organização, visando reduzir a  probabilidade de ocorrências danosas à segurança ou, ao menos, minimizar os danos por  elas causados, mediante a definição de um plano que permita sua adequada recuperação. A política deve apresentar com clareza os objetivos que se pretende alcançar e servir de instrumento para obter a conscientização dos integrantes da organização quanto à relevância da segurança da informação, de modo que cada um desempenhe seu papel de modo adequado. A implantação da política de segurança tem como propósito tornar operacionais os controles e regras de segurança estabelecidos e consiste na pesquisa, seleção e instalação de produtos e mecanismos apropriados que têm como função garantir a proteção necessária, conforme definido pela política de segurança. 2.3. Administração da Segurança   Na etapa de administração, é definida a estrutura pretendida para o gerenciamento da segurança, com particular atenção para os seguintes aspectos: •

Posição, no organograma da organização, da unidade responsável pela administração de segurança;

•

Definição e padronização dos controles projetados para a segurança lógica;

•

Definição de atributos e controles desejados para a segurança física; e

Perfil exigido dos profissionais que vão atuar nesta unidade organizacional. Para desempenhar tarefas pertinentes a esta etapa, é recomendável a criação de uma equipe de administração de segurança, responsável pela administração de usuários e por  recursos tais como arquivos ou bancos de dados, acesso a aplicações, transações e equipamentos. Adicionalmente, esta equipe pode estabelecer a necessidade do uso de objetos criptografados (tais como chaves de acesso) e a análise de arquivos históricos que registrem a atividade de atualização e acesso às informações (logs de segurança).   Nesta etapa do ciclo, é importante classificar os dados e recursos a serem  protegidos, especificando-se o nível de segurança lógica e física esperado para cada um. •

2.4. Auditoria A auditoria de segurança é, básicamente, uma revisão do plano de segurança elaborado e deve ser executada periodicamente, a fim de mantê-lo continuamente atualizado. Consiste, normalmente, na análise de relatórios com registros de acesso ao(s) sistema(s) e na realização de testes simulados, aplicados por auditores internos e/ou externos, que têm como propósito realimentar a verificação do plano, validando a política de segurança e implementando novos controles julgados necessários.

Adicionalmente aos recursos de auditoria, convém ressaltar que uma boa política de segurança deve prover também meios de reação imediata a uma suposta ameaça, presente em determinado momento. O objetivo é detectar, em tempo real, a ocorrência do perigo e enviar alertas para notificar os responsáveis pela ação.

2.5. Planejamento da Contingência para Continuidade dos Negócios O plano de contingência e recuperação de negócios para sistemas de informação insere-se na política de segurança como instrumento de planejamento estratégico, constituindo o documento que especifica procedimentos pré-estabelecidos, a serem observados nas tarefas de recuperação do ambiente de sistemas e negócios, de modo a minimizar o impacto nas atividades da organização ocasionado por dano ou desastre que não puderam ser evitados  pelas medidas de segurança em vigor. A fim de evitar esforços desnecessários, reduzir custos e tornar exequível um plano de contingência, geralmente são contemplados pelo planejamento somente os recursos identificados como essenciais para a continuidade da missão da organização.

3. O Plano de Contingência e Recuperação de Negócios 3.1. Estrutura do Documento O Plano de Contingência e Recuperação de Negócios (PCRN) deve ser elaborado como um documento normativo, formalmente aprovado pela direção da organização e amplamente divulgado, de modo que todos os funcionários e integrantes da empresa estejam cientes dos procedimentos por ele estabelecidos. Recomenda-se que o documento correspondente ao ato de aprovação do plano seja inserido logo após a folha de rosto. O PCRN descreve os procedimentos relativos ao ambiente de TI e à área de negócios que devem ser adotados no caso de ocorrência de sinistro ou impedimento relevante que venha a comprometer o funcionamento normal da organização. As ações a serem encetadas para a recuperação das instalações e sistemas e para a redução do impacto sobre as atividades da organização têm como premissa a ocorrência de um dano ou desastre que comprometa a execução dos serviços essenciais à sua missão. Em uma situação real de contingência, convém ressaltar que todas as ações decorrentes devem, em primeiro lugar, preservar a vida e a segurança dos integrantes da organização e demais pessoas expostas a risco. Os procedimentos descritos no plano compreendem ações a serem executadas em três diferentes fases da situação de contingência: •

Ativação(deflagração) da contingência;

•

Restauração das condições operacionais em ambiente alternativo; e

Retorno à normalidade. A estrutura desse documento deve contemplar os ítens básicos a seguir descritos. a) Propósito do plano : este item deve estabelecer de forma clara qual o objetivo do documento e a quem ele se destina.  b) Definições conceituais : como o documento não é restrito a profissionais de TI, é recomendável incluir um pequeno glossário com definições da terminologia •

usualmente empregada em contingências (sinistro, desastre, backup site, centro de operações, restauração etc). c) Escopo : o plano deve definir com objetividade a abrangência da contingência planejada e quais recursos estão cobertos pelos procedimentos definidos no documento. d) Equipes de trabalho : é importante registrar no plano como será efetuada a divisão do trabalho em situação de contingência, observando-se as três fases anteriormente citadas (ativação, restauração e retorno). Neste bloco, devem constar os elementos e unidades organizacionais envolvidos na consecução do plano e suas respectivas atribuições em cada fase. e) Descrição do ambiente alternativo : dependendo da análise dos riscos e ameaças, a solução de contingência adotada pode se resumir a procedimentos de mirroring , com duplicação de dados, mas pode também definir o uso de um CPD-alternativo em ambiente situado e configurado em alguma unidade dentro da própria organização, mas normalmente físicamente dela separada ou ainda definir soluções hot  ou cold-site , que utilizam recursos e ambientes externos às instalações da organização, contratados especificamente para este fim. A solução adotada deve ser detalhadamente descrita, incluindo-se mapa de localização da instalação alternativa e eventuais contatos externos contratuais, requeridos para a deflagração da contingência. f) Planos decorrentes : em situações de contingência, um pequeno detalhe pode, muitas vezes, transformar-se em óbice intransponível, se não tiver sido devidamente contemplado no planejamento. Como subsídios para o Plano de Contingência e Recuperação de Negócios, devem ser elaborados planos decorrentes, contendo informações suficientemente detalhadas com relação a aspectos específicos, como os mencionados na seção 3.2 deste artigo. g) Informações complementares : devem ser anexadas ao plano todas as informações consideradas úteis para a consecução dos procedimentos descritos. Como exemplo,  podemos citar algumas informações básicas, que, em um momento de desastre, tornamse críticas caso não sejam localizadas a tempo: identificação e localização de mídias  para instalação de algum software que deva ser executado em servidores de rede e/ou estações de trabalho; instruções específicas para a ativação da contingência, que devem incluir, entre outras informações, a indicação de um local de concentração para reunir as  pessoas convocadas a agir em qualquer uma das fases previstas no plano; e telefones de contato de seguradoras e órgãos que devam ser acionados no momento seguinte à ativação da contingência.

3.2. Planos Decorrentes Como exemplos típicos de planos decorrentes, podemos mencionar os documentos a seguir  descritos, que podem compor o Plano de Contingência e Recuperação de Negócios sob a forma de anexos. Plano de Backups : deve fornecer a identificação e localização das cópias de segurança, indicando os volumes e mídias a serem utilizados para a restauração de arquivos e/ou bases de dados e a referência temporal correspondente à informação assim recuperada.

Plano de Busca : provê, basicamente, a identificação das pessoas que devem ser acionadas em situação de contingência, o grupo de contingência ao qual pertencem e as formas de contato para sua localização. Plano de Recuperação de Aplicativo : deve descrever procedimentos específicos necessários para a recuperação de aplicativos residentes na instalação da organização, enfatizando possíveis detalhes não incluídos na recuperação global relativa ao ambiente operacional. Plano Logístico: deve prever as providências necessárias para assegurar a consecução do  plano de contingência no que se refere à viabilização de atividades não técnicas como, por  exemplo: deslocamento do pessoal convocado para as atividades de recuperação, tanto do ambiente de TI como das instalações danificadas; atendimento a público externo (quando aplicável); condições para alimentação e repouso das equipes envolvidas na recuperação que muitas vezes trabalharão em regime excepcional de horário -, guarda e movimentação   para instalação provisória de mobiliário, equipamentos e documentação resgatados da instalação sinistrada. 3.3. Distribuição, Revisão e Arquivamento do PCRN Todas as unidades organizacionais diretamente envolvidas nas atividades descritas no Plano de Contingência e Recuperação de Negócios precisam receber uma cópia do documento produzido. Conforme novos recursos sejam incorporados à realidade operacional da organização e à medida que funcionalidades sejam alteradas ou introduzidas no ambiente de aplicação, o PCRN deve ser atualizado pelo setor associado a tais mudanças, de modo a refletir a nova realidade. O componente da organização responsável pelo planejamento global da contingência deve estar atento ao grau de evolução dos ambientes, a fim de   programar situações significativas a serem testadas em exercícios de contingência  periódicamente executados. Por medida de prevenção, pelo menos uma cópia do PCRN deve ser mantida arquivada fora das dependências da organização, em local divulgado para as equipes de contingência.

4. Estrutura Organizacional de Contingência Para a consecução das atividades de planejamento, execução e manutenção do Plano de Contingência, propõe-se uma estrutura que organiza indivíduos de diferentes equipes em células denominadas Grupos de Contingência (GC), responsáveis por atividades específicas. Esta estrutura é ativada apenas em situações de contingência, inserindo-se no organograma da organização, de modo que cada GC assim constituído fica subordinado a uma unidade organizacional permanente. A Figura 3 ilustra a estrutura definida para o contexto da Pagadoria de Pessoal da Marinha, que suporta oito Grupos de Contingência subordinados a Departamentos que compõem a estrutura desta organização militar, além de um GC específico para os sistemas externos hospedados no ambiente operacional mainframe e gerenciados por  usuários de outras organizações militares. Todos os GC estão sob a coordenação executiva do Vice-Diretor da PAPEM, que se reporta diretamente ao Diretor.

Direção da PAPEM PAPEM-01

Coordenação Executiva Vice-Diretor  PAPEM-02

PAPEM-10

PAPEM-30

Execução do Pagamento

TI - Aplicação

Operações , Salvamento e Rescaldo Interação com a Entrada de Dados e Análise da Informação

Desenvolvimento e Manutenção do SISPAG Microinformática

PAPEM-40

TI - Infra e Suporte

Gerentes de

Sistemas Externos

Logística e Apoio Administrativo

Suporte a Hardware e Software Segurança da Informação

SISPAG: Sistema de Pagamento de Pessoal da Marinha

Processamento da Produção

Figura 3. Estrutura Organizacional de Contingência

4.1. Dividindo Responsabilidades O PCRN deve explicitar as responsabilidades de cada Grupo de Contingência, bem como aquelas atribuídas aos elementos que responderão pela Coordenação Executiva e à Direção da organização. As responsabilidades são categorizadas em responsabilidades  permanentes (obrigatórias mesmo em situação normal de operação, a fim de assegurar a   prontidão) e responsabilidades decorrentes de uma situação real de contingência (aplicáveis a necessidades evidenciadas imediatamente após a ativação da contingência, durante o período de recuperação dos danos provocados pelo desastre e na fase de retorno à normalidade). Como exemplo, são relacionadas na Tabela 1 algumas das responsabilidades atribuídas ao GC de Suporte a Hardware e Software definido para a PAPEM. Tabela 1. Responsabilidades do GC de Suporte a Hardware e Software

Responsabilidades Permanentes: Participar ao GC de Logística e Apoio Administrativo as alterações relativas ao Anexo I - Relação do Hardware sob Seguro, bem como manter atualizados os dados cadastrais das empresas prestadoras de suporte técnico para sua manutenção; Analisar e propor alternativas para a solução de contingência, recomendando, se julgada conveniente, a redefinição dos requisitos relativos ao CPD alternativo a ser utilizado; Fazer refletir nos recursos definidos para contingência as atualizações de software e hardware operacional eventualmente ocorridas nas instalações do CPD-PAPEM e necessárias em situação de contingência; Executar regularmente os procedimentos de salvaguarda para as cópias de segurança de todos os softwares e arquivos componentes do Plano de Recuperação, controlando e mantendo e estes backups de contingência fora da PAPEM;

Manter a salvo, fora da PAPEM, documentação completa da configuração do ambiente instalado (estrutura de catálogos, bancos de dados, bibliotecas, recursos da rede de teleprocessamento, etc.); Responsabilidades após a Ativação da Contingência: Assim que informado da situação de contingência e acionado pelo Grupo de COORDENAÇÃO EXECUTIVA, cada membro deste GC deverá comparecer ao Centro de Operações para receber as instruções iniciais; Executar as atividades definidas para restauração do ambiente operacional. Responsabilidades durante o Período de Recuperação: Executar os procedimentos para retirada das cópias de segurança correspondentes à posição mais recente de todos os softwares e arquivos componentes do Plano de Recuperação, armazenados fora da PAPEM; Ativar o sistema operacional e os softwares de apoio no CPD alternativo; Restaurar todos os arquivos e bases de dados e validar o acesso a eles; Disponibilizar aos usuários o acesso, remoto e local, para utilização dos aplicativos recuperados; Interagir com o GC de OPERAÇÕES DE RESCALDO E SALVAMENTO na avaliação dos danos e  possibilidade de recuperação dos equipamentos danificados; Manter o GC de COORDENAÇÃO EXECUTIVA informado do andamento das ações. Responsabilidades no Retorno à Normalidade: Concluir todas as correções e atividades programadas para execução dos processos vitais e comunicar  a todos os envolvidos o início dos procedimentos de retorno; Providenciar as cópias backup dos dados atualizados no CPD alternativo durante a contingência e seu retorno ao site da PAPEM, nas novas instalações. Apagar todos os registros e dados armazenados em discos, estações de trabalho ou servidores utilizados no CPD alternativo como recurso de processamento.

5. Checklist  Básico A lista de questões a seguir apresentada foi elaborada a partir de [DRII2003], [ISO2000] e [IBM1999], com o propósito de auxiliar gestores e profissionais de TI na avaliação preliminar do grau de prontidão de suas organizações, com referência a situações de contingência. 1.  Na hipótese de ocorrência de algum tipo de desastre ou interrupção significativa na condição de funcionamento de sua organização (por exemplo, incêndio ou interrupção continuada de energia), existem procedimentos documentados na forma de planos de contingência e recuperação ? 2.Se a resposta para a questão 1 foi positiva, que tipos de cenários de contingência estão  previstos ? 3. Se a resposta para a questão 1 foi positiva, qual o limite máximo de tempo (em termos de horas, dias, semanas, meses) admitido para inoperância de sua organização em cada cenário previsto?

4.Se a resposta para a questão 1 foi positiva, o plano de contingência estabelece  prioridades distintas para atividades críticas, vitais à organização? 5.Se a resposta para a questão 4 foi positiva, qual o tempo máximo admitido de inoperância para atividades classificadas como vitais? <04-08 horas> <01-02 dias>

6.Se a resposta para a questão 1 foi positiva, o plano de sua organização cobre alguns ou todos os locais onde são disponibilizados serviços (CPD, setor de atendimento ao  público externo, sala de servidores, etc)?

7.O CPD ou sala de servidores de sua organização está localizado no mesmo edifício ou complexo onde são realizadas as atividades de negócio? 8.  Na hipótese de contingência, sua organização possui cópias de segurança recentes salvas em um edifício diferente do complexo onde são realizadas as atividades de negócios? 9.  Na hipótese de contingência, existem meios eficientes de localizar e contactar as equipes a serem acionadas para recuperação do ambiente de sistemas? 10.Sua organização dispõe de um local alternativo previsto para fins de recuperação dos sistemas de TI? 11.Se a resposta para a questão 1 foi positiva, quantos testes do plano de contingência sua organização efetuou até a presente data? <02-04> <05-10>

12.Se a resposta para a questão 1 foi positiva, o plano prevê a participação de integrantes das áreas de negócio de sua organização ou apenas dos profissionais de TI?

13.Qual valor se aproximaria do prejuízo financeiro estimado para sua organização caso fossem perdidos ou corrompidos os dados mantidos pelos sistemas de informação? <201-500K> <501-1000K> K= R$ 1.000,00

6. Conclusões e Lições Aprendidas A tecnologia de informação se incorporou à rotina diária das organizações, que, cada vez mais, exigem qualidade, integridade e disponibilidade de seus dados. Para o quesito qualidade, a conduta normalmente observada para assegurar a correta distribuição de tarefas consiste em conscientizar o usuário (proprietário dos dados) - ou, ainda, o   profissional nomeado como analista de negócios – de que pertence a ele a parcela  principal de responsabilidade pela definição da informação com o grau de qualidade esperado. Contudo, quanto aos aspectos integridade e disponibilidade, existem ainda algumas lacunas de responsabilidade, com contornos indefinidos entre usuários e  profissionais da área de TI. Independente do porte de uma aplicação, é essencial que se tenha sempre em mente a relevância da informação por ela mantida e os requisitos de segurança que devem ser atendidos. Observa-se um impasse para definições de segurança quando os  proprietários dos dados – elementos normalmente mais afetos às funções da camada de negócios - não são requisitados a identificar quais informações são vitais para a atividade da empresa ou então delegam tal responsabilidade para o setor de TI, que, geralmente, não se encontra devidamente estruturado para responder por ela. A experiência acumulada ao longo dos mais de quinze exercícios de contingência executados pela Pagadoria de Pessoal da Marinha tem resultado em vários ajustes nas rotinas em produção e, com a gradual participação de equipes do setor de negócios, observa-se crescente grau de refinamento e exatidão na análise das vulnerabilidades dos sistemas contingenciados. Podemos resumir as lições aprendidas até o momento na forma das seguintes mensagens, destinadas a futuros planejadores de contingência:

-A segurança e integridade das pessoas deve estar em primeiro lugar; sem o conhecimento que elas possuem, a recuperação de todo o software ou hardware de sua organização será inútil. -O Plano de Contingência e Recuperação de Negócios (PCRN) deve ser redigido de forma clara e objetiva e seu conteúdo deve ser amplamente disseminado pela organização. Obtenha o comprometimento da Direção e setores da área de negócios. -Além das equipes de TI, obtenha a participação de integrantes dos setores de negócios durante os exercícios de contingência. -Reserve tempo suficiente para o planejamento das atividades relativas a cada novo exercício, a fim de explorar a oportunidade e testar novas funcionalidades ou atualizações ocorridas no ambiente operacional de sua organização. -Divulgue os resultados dos exercícios de contingência realizados e demonstre a evolução alcançada com cada teste, quanto à segurança e qualidade da informação sob custódia. -Assegure-se de que suas cópias de segurança (backups) para as informações vitais estão sendo regularmente produzidas: programe um ou mais testes da operação de restauração de arquivos ou bases de dados, de modo a evitar surpresas desagradáveis. -Estimule o trabalho cooperativo entre os integrantes dos Grupos de Contingência e mantenha-os atualizados sobre as versões do PCRN.

Referências DRII (2003) “Professional Practices for Business Continuity Planners”, Disaster Reco very International Institute. Edwards, D. (1997) “The Contingency Planner”, Disaster Recovery Journal. IBM (1999) “Business Continuity: New Risks, New Imperatives and a New Approach”, Report G510-1135-00. ISO/IEC 17799 e BS7799 (2000) “The International Security Standard - A Code of  Practice”, International Organization for Standardization. Wold, G. H. (1997) “Disaster Recovery Plan Process”, Disaster Recovery Journal.