PCI-DSS: Entenda como funciona a norma de segurança para transações eletrônicas

Nos últimos 10 anos, houve uma explosão de negócios via Internet - e-commerces - na mesma proporção que aumentou o uso de cartões de crédito para compras em estabelecimentos comerciais e, é claro, sites de internet.


Apesar de todos os esforços das empresas de proteger as informações de clientes, fraudes eletrônicas e roubos de informações têm aumentado drasticamente. Em 2006, mais de US$ 4 milhões foram gastos em operações fraudulentas nos Estados Unidos, de acordo com o U.S Department of Justice.


Os governos estudam formas de criar leis para combater esse tipo de crime, enquanto os bancos e as operadoras de cartão de crédito tomaram suas próprias iniciativas para criar normas para garantir boas práticas no uso, manuseio e armazenagem de dados de cartão de crédito: Payment Card Industry (PCI) - Data Security standard (DSS).


Fraudes de Cartão de Crédito


Fraudes eletrônicas ou fraudes de cartão de crédito são aquelas em que os dados do cartão de crédito (número, validade e código de segurança) são roubados e usados indevidamente para a realização de compras em estabelecimentos. Os estabelecimentos entregam o produto comprado e esperam receber, em alguns dias, o crédito referente àquela venda.


Ao receber a fatura do cartão de crédito, os clientes (portadores de cartão de crédito) identificam despesas que não foram feitas por eles e solicitam à administradora o cancelamento das mesmas. A administradora, por sua vez, estorna a compra do estabelecimento, que não recebe o dinheiro e já entregou o produto. O estabelecimento acaba assumindo o prejuízo da fraude.


O que é PCI-DSS?


Em setembro de 2006, algumas bandeiras de cartão de crédito, entre elas Visa, Mastercard e American Express, criaram um conselho designado a criar e recomendar as melhores práticas de segurança de dados, a serem seguidas pelos estabelecimentos comerciais que aceitam cartões de crédito como forma de pagamento, para proteger a privacidade dos consumidores portadores de cartão de crédito. Esse conselho é chamado PCI Council (www.pcisecuritystandards.org).


O PCI-DSS contempla 12 requerimentos básicos que têm o objetivo de:

• Manter a rede de dados segura; 
• Proteger as informações de portadores de cartão de crédito; 
• Manter um programa de Gerenciamento de vulnerabilidades; 
• Implementar um forte controle de acessos; 
• Manter uma política de segurança de informações. 

Não estar em conformidade com a PCI-DSS pode incorrer em multas e até em descredenciamento dos estabelecimentos comerciais em aceitar cartões de crédito.


12 Requerimentos da PCI-DSS

1. Instalar e manter um firewall para proteger dados de cartão de crédito.
2. Não utilizar senhas padrão ou outras configurações de segurança dos softwares utilizados.
3. Proteger dados de cartões de crédito armazenados.
4. Utilizar criptografia na transmissão de dados de cartões de crédito, manter um programa de Gerenciamento de Vulnerabilidades.
5. Utilizar regularmente programas anti-vírus.
6. Desenvolver e manter sistemas e aplicações seguras, implementar um forte controle de acesso.
7. Restringir acesso a dados de cartões de crédito por negócio e por pessoas que realmente precisam acessá-los.
8. Designar um único ID para cada usuário da rede e sistemas.
9. Restringir acesso físico aos dados de cartão de crédito, testar e monitorar a rede regularmente.
10. Rastrear e monitorar todos os acessos à rede e dados de cartões de crédito.
11. Testar a segurança de sistemas e processos regularmente, manter um programa de Gerenciamento de Vulnerabilidades.
12. Manter uma política que enderece informações de segurança.

Quem precisa estar em conformidade?


O PCI DSS se aplica a toda e qualquer empresa que coleta, processa, armazena ou transmite informação de cartão de crédito, estando, portanto, obrigada a se adaptar ao padrão. Em linhas gerais, esta adaptação inclui comerciantes, intermediários que processam dados de cartão de crédito e estão ligados à rede da associação de cartões, assim como provedores de serviço que hospedam sites, processam transações em ATM ou coletam e processam dados de cartão de crédito em nome de membros das redes Visa e Mastercard - gateways de pagamento.


A exceção fica com empresas que apenas emitem cartões de crédito e autorizam transações, como bancos e grandes varejistas, deixando de ser obrigados a demonstrar conformidade com o PCI DSS.


Qual o prazo e o nível de aderência atual?


O cronograma de conformidade varia de acordo com o continente e o mercado. No Brasil, as empresas físicas e virtuais que estão dentro do escopo do PCI terão até este ano (2009) para se adequarem. Entretanto, o resultado de uma pesquisa feita em 2006 no mercado norte-americano revelou que menos de 20% de todos os grandes varejistas e provedores de serviço atingiram a conformidade plena com o PCI DSS. Já em 2007, a mesma pesquisa chegou ao índice de 35% de conformidade.


Considerando a heterogeneidade dos ambientes operacionais e dos modelos de negócio das empresas envolvidas no compliance, podem surgir dificuldades em implementar alguns dos requerimentos. Nesses casos, será preciso definir e implementar controles compensatórios de forma a alcançar o nível de risco residual adequado.


Sabemos que para as empresas se adequarem às normas do PCI-DSS envolve muitos custos, portanto procure uma consultoria ou uma empresa séria para indicação de equipamentos que serão utilizados como Firewall, IPS/IDS, Anti-vírus e outros equipamentos e softwares para adequação desta norma.

Treinamento e Conscientização da Continuidade de Negócios

Uma GCN efetiva ajuda as organizações a aumentar sua resiliência e proteger seus empregados, ativos e processos de negócios.

Muitos planos da GCN falham devido a falta de treinamento e conscientização dentro da organização. Logo, é importante assegurar que a organização considere business continuity em todas suas atividades.

Cultivando uma conscientização coletiva.

Cultivar um entendimento e conscientização no staff é fundamental para a efetividade da GCN – isto é um elemento chave dentro da BS 25999. Entretanto, isto permanence como um desafio para muitas organizações, principalmente para as mais complexas com alto volume de staff, múltiplas localidades e diferentes culturas para influenciar.

Gerentes locais da GCN não devem tomar decisões rápidas para replicar internamente programas de treinamento e conscientização sem avaliação e análise preliminar do ambiente. Um programa como este precisa ser único para toda organização, endereçando todos os componentes da GCN, como análise de riscos, gerenciamento de crises, planos de comunicação, procedimentos de contingência e recuperação de ativos, e atividades de ongoing, como atualização e monitoramento.

Aqui estão alguns elementos simples para aludar os planejadores da GCN a construir e nutrir uma conscientização da continuidade de negócios para toda a organização:

• Use terceiros, como consultores, auditores e clientes para ajudar a mostrar a importância do planejamento da continuidade de negócios;
• Mostre como seus concorrentes estão construindo os programas de continuidade de negócios;
• Use o programa para gerar publicidade para a organização. Divulgue testes e exercícios para a mídia e comunidade local, para mostrar que sua organização tem compromisso com as operações de negócio;
• Use um sistema de notificação de emergência, como o XCORP Mobile para anunciar mudanças ou benefícios ou distribuição de procedimentos e testes;
• Use eventos atuais para ressaltar a importância da GCN ou do PCN. Notícias sobre empresas que conseguem dar continuidade aos negócios após rompimentos ou incidentes graves são uma grande fonte para isso.

Para aqueles que querem se envolver internamente:

• Faça PCN ou GCN parte da descrição de vagas para gerentes de unidade de negócios e assegure que esteja incluída no processo de revisão anual. Por exemplo, uma grande empresa farmacêutica estava tendo problemas com auditoria de BCP. Eles adicionaram Business Continuity dentro das revisões de performance e os planos ficaram prontos e completos no tempo certo e com uma boa organização e desenvolvimento. Isto também promoveu debates entre os funcionários e seus gerentes, e com outros departamentos, e ações de sensibilização e conscientização para toda a organização.
• Mencione o plano em publicações internas frequentemente;
• Torne os exercícios de testes divertidos e sempre traga comida. O conceito "lunch and learn" ajuda a manter um clima adequado para um aculturamento de toda a organização;
• Peça ajuda ao departamento de marketing na produção de brindes que ressaltam a importância do PCN. Kits para desastres ou crises são uma grande idéia.
• Eventos sociais - crie alguma idéia que ao mesmo tempo que eles queiram atender eles temem;
• Instrua os funcionários sobre prevenção de incidentes que podem ocorrer no trabalho e sobre outros que podem ocorrer em casa.

Outras idéias que podem ajudar a gerar apoio e sensibilização em toda a empresa incluem:

• Proporcione reconhecimento público de realizações pessoais no PCN ou na GCN. Tem alguém em sua empresa que desenvolveu com sucesso a construção de um plano, ou se envolveu mais do que outros?
• Use as ferramentas de continuidade de negócio para outros fins, para gerar familiaridade e conforto. Por exemplo, várias empresas têm utilizado o BIA para classificar processos críticos dentro de um projeto específico, como a Nota Fiscal eletrônica;
• Inclua artigos sobre BCP em revistas de sua organização e também na sua intranet. Uma empresa de energia assegurou que um link com o Software XCORP iContingency estava em cada página de departamento na intranet corporativa;
• Faça do treinamento de continuidade de negócios parte de orientações e imersões das novas contratações de empregados;
• Promova passeios para empregados até o datacenter secundário;
• Patrocine um evento de BCP interno ou externo. Algumas empresas de consultoria levam clientes a eventos como o DRJ, outras enviam seus próprios funcionários.

Onde está o valor agregado?

Programas de treinamento e conscientização da continuidade de negócio tem o potencial de agregar valor para toda a organização. Um programa efetivo de treinamento e conscientização está correlacionado com a habilidade da empresa em se recuperar de forma efetiva depois de uma crise ou desastre, assegurando a continuidade dos seus negócios dentro dos tempos pré-definidos. Sua empresa rodando como sempre. Para sempre.

Criando uma Estratégia para Testes de BCP/DRP

Tipos de Testes

Há três tipos de testes de plano de continuidade de negócios que podem ser usados, a saber:

• Teste de Leitura (Read-Through test), que consiste numa revisão de mesa (walk-though) do plano de continuidade de negócio e listas associadas de tarefa e ação para avaliar suficiência com os indivíduos (ou seus representantes nomeados) responsáveis pela realização dessas atividades,

• Teste de Cenário de Mesa (Scenario Desk test), onde participantes dos testes são reunidos numa sala de reuniões com observadores e o gerente de continuidade de negócio (ou nomeado). Os participantes do teste são apresentados a um desastre particular ou cenários de falhas e são solicitados a usar o plano de continuidade de negócio para simular alguma situação com eles. As circunstâncias dos cenários ocasionalmente podem ser mudadas para determinar como os participantes do teste reagem e assim a eficácia do plano de continuidade de negócio,

• Teste Real (Hands-on test), que envolve a realização efetiva das listas de tarefa e ação (p.ex. Mover pessoal-chave para um local alternativo com apoio de TI e instalações de voz).

Os testes de leitura são os mais simples e tem a menor quantidade de envolvimento de pessoal, e assim é a mais barata e menos intrusiva nas operações normais do negócio. As provas de cenário de mesa envolvem mais pessoas, não são muito intrusivas em operações normais do negócio, e trazem mais benefício do que os testes de leitura.

Os testes reais são potencialmente os mais complexos, envolve uma quantidade maior de envolvimento pessoal, pode ser valioso com o tempo e esforço, e é intrusivo às operações normais de negócio.

É possível envolver todos ou vários tipos de testes, dependendo do cenário e da complexidade da operação. É muito importante verificar a interdependência de ações, o cenário e a necessidade ou não de realizar testes integrados (p.ex. Processo de negócios X e determinados ativos que o suportam). Deve-se avançar para um nível mais complexo depois que o tipo de teste atual foi executado com êxito. Em outras palavras, só deve ser feito um teste de cenário de mesa uma vez que o teste de leitura foi executado com êxito, e então só deve ser feito o teste real depois que o teste de cenário de mesa foi realizado.

Estrutura dos Testes

Cada teste deverá ser estruturado para aumentar ao máximo o valor obtido dos recursos envolvidos. Não há nenhum sentido envolver um grande número de pessoas, e talvez recursos externos, durante um dia para um teste inicial que talvez fracasse nos primeiros 10 minutos. Os testes portanto devem ser e estar claramente focados.

Os testes iniciais devem ser curtos, e com objetivos bem limitados. Somente após a realização prévia de testes básicos, com um número limitado de cenários e tarefas, a cobertura pode ser estendida a um grupo maior de pessoas. A abordagem é iniciar com testes simples e gradualmente aumentar a complexidade e escopo, assim que testes prévios comprovem ser satisfatórios.

Como um guia para estruturar testes, os primeiros testes podem ser executados com pequenos grupos de listas de tarefa, usar cenários simples, usar a experiência de pessoas designadas dentro do plano para executar os procedimentos de contingência, uso restrito de recursos de uma única área ou unidade de negócio, e restringir testes aos testes de leitura e de cenário de mesa.

Testes posteriores poderão ser feitos com grupos maiores, para ações previamente testadas, aumentando gradativamente a quantidade de cenários, incluindo outros grupos de pessoas do staff e cuidadosamente conduzindo testes reais (Hands-On) como parte do planejamento.

Os Passos dos Testes

Introdução

Os passos para a realização dos testes do plano de continuidade de negócio da empresa são: (a) Planejar o teste – crítico para o sucesso do programa de testes; (b) Testar o plano; (c) Revisar o teste; e (d) modificar o plano, se necessário. É importante salientar que isto é um processo interativo e os passos precisam ser revistos e refeitos cuidadosamente até que seja acordado que os objetivos dos testes tenham sido obtidos. Estes passos estão descritos nas sessões abaixo:

Planejar os Testes
A primeira tarefa é estabelecer os objetivos e alcance de cada teste, assegurando que todos participantes designados estão informados, e então criar o plano de teste do plano de continuidade de negócio. Abaixo segue a lista de itens que deverão ser incluídos no planejamento do teste:
• referência e número do teste - um número "central" de referência de teste,
• a área/equipe de negócio - o nome (nomes) da área de negócio (áreas) ou a equipe (as equipes) sob teste,
• tipos de testes – se testes de leitura, cenário de mesa ou real,
• fases sendo testadas - as fases do plano que serão testadas (e.g. emergência, operação, retorno),
• objetivos do teste - os objetivos reais dos testes, de forma que seu êxito possa ser medido após a conclusão. Estes podem ser objetivos gerais, e específicos à testes,
• alcance/limite dos testes - uma descrição do alcance/limite, limitações, etc. dos testes,
• cenários - uma descrição dos jogos de circunstâncias dentro de que os testes são colocados em pratica, cobrindo o desastre ou falha que ocorreu e a extensão de estrago, indisponibilidade de serviço, ausência do pessoal, etc.,
• data, tempo e situação de testes - a data, tempo e situação onde os testes serão executadas (e/ou onde participantes devem se encontrar inicialmente),
• duração programada de testes - a duração planejada dos testes de modo que participantes possam programar sua participação com seus outros deveres,
• nome do gerente do teste - a pessoa responsável para chamar, planejar e coordenar os testes (p.ex. o gerente de continuidade de negócio ou um de sua equipe),
• observadores "independentes" do teste - os nomes de quaisquer observadores 'independente" que observarão a conduta dos testes,
• observadores "internos" do teste – como relevante, os nomes de quaisquer observadores de outras áreas/equipes de negócio onde há uma interface a eles,
• participantes do teste - os nomes dos participantes necessários para executar os testes. 

Dependendo do alcance do teste e jogo de cenário, esta lista pode ou não incluir todos esses membros da área/equipe particular do negócio sendo testado,
• referências de lista de tarefa e ação - as listas de tarefa de ação sendo testadas e, se relevante, definir as limitações nos testes (p.ex. ramifica-se "um" só, passos 1 a 5 único),
• recursos necessários - incluir recursos físicos específicos,
• data, tempo e situação de revisão do teste - detalhes de quando e onde a reunião de revisão de teste ocorrerá,
• autorização - o nome e firma do gerente de continuidade de negócio ou outro membro da equipe de coordenação que autoriza as testes,
• data de autorização - a data que os testes foram autorizadas.

Uma vez que o plano de teste tenha sido concluído e autorizado ele deve ser enviado a todos os participantes e observadores. Sempre que relevante, ajustes devem ser feitos com outras organizações de modo que estejam cientes das ações que necessitam ser realizadas e sua parte no plano. Então o gerente de teste poderá detalhar mais algumas atividades. Isto pode incluir:
• uma descrição mais detalhada da falha ou desastre relacionado, escopo e cenário dos testes,
• qualquer informação essencial inicial que pode representar “relatórios de situação” das fases anteriores da ativação do plano de continuidade de negócio, ou de outros indivíduos, áreas/equipes de negócio etc.,
• descrição de elementos envolvendo:
o quaisquer acontecimentos que precisam ser desvendados em pontos específicos nos testes (p.ex. por causa de problemas relacionados em outra parte, os serviços de emergência isolaram uma área de determinada localização),
o reações devem ser dadas a determinadas ações do plano de continuidade de negócio relativo aos participantes (p.ex. os serviços de emergência confirmam que o acesso a determinada área não será possível por 24 horas),
o intervalos de tempos devem ser endereçados (p.ex. o cenário de teste será alterado para 3 horas) e a situação revista no novo ponto com o tempo.
O gerente de testes fornecerá logs para ele e/ou qualquer outros observadores registrar problemas, observações e ações durante os testes. Mais ainda, a menos que um teste seja para estabelecer se o plano de continuidade de negócio pode ser encontrado numa emergência, uma cópia das partes relevantes do plano será fornecida a todos os participantes.

Testar o Plano

Uma explicação inicial feita pela gerente de testes deve preceder os testes, definindo as razões e objetivos do teste, os cenários e alcance dos testes, as regras de conduta nos testes, e os papéis dos participantes que estarão presentes.

O gerente de testes deve administrar o ambiente de teste, permitindo que a área/equipe de negócios execute os testes reais enquanto ele assegura que os testes são empreendidos de acordo com os scripts, contando apenas com os recursos previamente definidos nos planos (p.ex. uma cópia de papel da lista telefônica não pode ser usado para localizar alguém que deveria ser localizado pelas informações constantes no script).

Como necessário, o gerente de teste pode e deve agir como o papel de instrutor, com o intuito de treinar a equipe. Da mesma forma, se o gerente de teste está ciente de uma deficiência no plano sob teste ele pode guiar a equipe de teste a descobrir esta deficiência. (p.ex. perguntar como uma ação particular pode ser alcançada se não existe nenhum passo correspondente no plano).

Durante os testes, se necessário, o gerente de teste pode introduzir “acontecimentos” imprevistos visando testar a capacidade de reação da equipe para lidar com mudanças de acontecimentos. O gerente de teste e qualquer observador deverá documentar apropriadamente todas as dificuldades, problemas, deficiências, etc. exatamente como aparecem nos testes.

Revisar o Teste e Modificar o Plano

Após a conclusão dos testes, o gerente de teste presidirá uma reunião formal revisão do teste com os observadores e o pessoal designado envolvido nos testes, com a data, hora e local como indicado no plano original de teste. A reunião deve considerar se os objetivos determinados nos testes foram alcançados, quaisquer problemas, omissões, deficiências, problemas, etc. encontrado pelo pessoal de teste e observadores, e as lições aprendidas.

Subseqüentemente, um documento deve ser produzido identificando que áreas do plano de continuidade de negócio testado requerem modificação, com o gerente de continuidade de negócio assegurando que todas modificações foram feitas e, se for necessário, re-testado.

Além do mais, um relatório curto deve ser produzido para circulação a indivíduos relevantes, descrevendo as conclusões na conduta e eficácia dos testes, os problemas e deficiências mais importantes, o plano de ação, e o requisito para mais testes.

A Freqüência dos Testes

A freqüência dos Testes

Durante o desenvolvimento inicial do plano de continuidade de negócio, testes devem ser um processo interativo até que o plano seja julgado e considerado plenamente pronto para uso.

Uma vez que o plano está adequado, mais testes devem ocorrer assim que ocorram mudanças significativas nas operações de negócio ou na infra-estrutura de ativos e serviços de suporte (IT, voz, etc.) e/ou no próprio plano.

Os recursos necessários para tais testes dependerão da extensão de mudança. De todos modos, re-testes periódicos devem acontecer para assegurar que o plano permanece em linha com os requisitos de negócios e da corporação.

Ferramentas para Automatizar Planos de Continuidade de Negócios

A utilização de um sistema para automação dos diversos procedimentos descritos durante a elaboração de um plano de continuidade de negócios, tem que levar em conta a possibilidade de cadastramento de todo o ambiente envolvido, sejam pessoas, processos, ativos, crises, ameaças e todas as localidades envolvidas. Muitas empresas utilizam sistemas específicos na construção dos planos e esquecem do mais importante: a possibilidade de usabilidade numa situação de crise.

Um bom sistema de automação dos planos deve permitir, além da construção de todos procedimentos, a usabilidade pelos gestores de uma forma amigável e simplificada. Aqueles sistemas complexos, que geralmente são construídos com muitos campos para preenchimentos com detalhes específicos de entrevistas e de relacionamento com procedimentos operacionais, são ótimos para abranger as diversas atividades de uma contingência, mas muitas vezes se tornam impossíveis de serem implementados por gestores estratégicos, que querem somente consultar os procedimentos operacionais a serem executados por sua equipe em situações de crises e desastres. Muitos consultores acreditam que as atividades voltadas para a usabilidade do PCN são mais difíceis de serem implementadas do que a sua própria construção.

Entre diversos aspectos e características técnicas dois fatores merecem atenção especial na escolha da melhor ferramenta de apoio: a característica de ser uma ferramenta de apoio as diversas atividades que devem ser executadas pela equipe de trabalho, e não o contrário, e o fato da ferramenta possibilitar a visualização dos procedimentos que devem ser executados, ao invés de simplesmente informar os erros de sistemas e equipamentos ou detectar problemas. Algumas ferramentas não permitem alterações na sua forma de pensar, e as atividades são obrigadas a ser desenvolvidas de acordo com as etapas planejadas no sistema. Outras apenas agem como um “aviso de tempestade” e não informam os procedimentos para atuar na crise. Nestes casos as atividades desenvolvidas se tornam o apoio da ferramenta, e as conseqüências são bastante danosas para a usabilidade e implantação do sistema no ambiente corporativo. A empresa acaba se tornando pouco flexível e subordinada as regras do sistema. Nestes casos a possibilidade de implementação adicional as características da ferramenta se torna difícil de acontecer.

No desenvolvimento do PCN a equipe tem que testar, manter e atualizar os procedimentos de acordo com as regras do negócio. Um sistema eficiente de controle, automação e monitoramento dos procedimentos deve ser flexível o bastante para acompanhar as mudanças corporativas, na forma de operar e fazer negócios da empresa, sem deixar de manter um controle rígido de passos e atividades, através de uma metodologia aplicada ao desenvolvimento do projeto. Um sistema deve possuir um método de trabalho específico para o projeto PCN, onde as atividades de cadastramento, consultas e relatórios atendem os objetivos para o qual a aplicação foi desenvolvida, ou seja, acompanhar os diversos procedimentos que devem ser executados por pessoas numa situação de crises e desastres. A visão sistêmica da ferramenta deve andar sempre alinhada com a metodologia aplicada ao projeto, de forma que a visão do programador esteja orientada a da equipe de projeto.

CADASTRAMENTO

O sistema de gerenciamento do PCN deve permitir a integração e o cadastro de todos os elementos essenciais ao desenvolvimento do PCN:

-Pessoas: Todos os colaboradores devem ser compreendidos no sistema, assim como parceiros, terceirizados e contratados que, durante uma crise ou desastre, são de alguma forma acionados ou ativados na execução dos procedimentos. A possibilidade de integração com outras bases de colaboradores, já presentes em outros sistemas do ambiente de tecnologia, devem ser considerados no desenvolvimento do sistema;
-Processos de negócios: Todos os processos de negócios precisam ser cadastrados no sistema, assim como a descrição de suas funções e sua integração com os ativos que o suportam. O entendimento das alterações de funcionalidade ao longo da cadeia de valores deve ser compreendida no sistema, bem como as propiciadas pela função em locais diferentes. As vezes o atendimento a clientes, por exemplo, ocorre de forma diferenciada em função da localidade em que ocorre;
-Ativos: Todos os ativos de infra-estrutura que suportam os processos de negócios devem ser cadastrados no sistema e tratados de acordo com o seu tipo (TI, Não TI, IE, Provedores e Parceiros). Um campo de relacionamento com os processos se faz necessário;
-Ameaças: Todas as possíveis ameaças ao ambiente de negócios devem ser implementadas no cadastro do sistema, com a possibilidade de alocação de pesos específicos para cada localidade e devem permitir a inserção de notas, quando for necessário medir o grau de exposição dos ativos a estas ameaças;
-Impactos: Todos os impactos corporativos, fruto da conseqüência de uma crise causada pelo impacto de uma ameaça no ambiente de negócios, devem ser efetivamente cadastrados no sistema, bem como o peso corporativo para cada impacto;
-Procedimentos: Todos os procedimentos operacionais desenvolvidos para contingência, recuperação e gestão de crises devem ser cadastrados no sistema. Estes procedimentos são considerados o cérebro do sistema, e devem ser projetados para serem acessados pelos usuários em situações de crises de diversas formas. Pelo sistema, pela Web ou até mesmo por dispositivos móveis, de forma rápida e simplificada.

CONSULTAS

Entre todos os aspectos de cadastramento e funcionalidade, a área de consultas merece atenção redobrada. A usabilidade do sistema se torna uma realidade quando temos a facilidade de consulta aos procedimentos operacionais de forma direta e simplificada.

A consulta de cada procedimento operacional deve ser construída de forma separada. Uma consulta para recuperação de desastres, outra para gestão de crise, e assim por diante. Como cada procedimento operacional está construído por localidade, cada localidade deve presenciar cenários distintos para cada execução de procedimentos. Por exemplo, o procedimento para gerenciamento de crise no caso de incêndio em determinada localidade pode ter uma seqüência de passos diferente de outras localidades. Da mesma forma, este incêndio pode ter cenários diferentes. Pode ocorrer na fábrica, no escritório ou no refeitório. Cada cenário possui características próprias e as consultas ao sistema devem permitir a seleção e visualização destes locais, cenários e procedimentos distintos, de forma simples, descomplicada e sobretudo rápida.

CONTROLE DE ACESSO

Em muitos projetos a quantidade de processos e ativos é tão grande que o sistema necessita de um bom banco de dados para administração das diferentes bases e relacionamento. Neste sentido, uma preocupação bastante justificada é com a confidencialidade das informações. Ao mesmo tempo, uma base de dados enorme pode gerar problemas com a facilidade de uso e o controle de acesso as diversas informações do sistema.

O sistema deve permitir o controle de acesso para consulta, alteração e atualização dos procedimentos e das informações. O controle de acesso anda junto com a facilidade de uso. Um gestor de rede, por exemplo, deve visualizar somente os ativos de rede que são por ele geridos. A esta seção, deve ser configurado o tipo de acesso permitido, somente consulta, somente alteração, ou ambos. Desta forma, gestores de processos de negócios poderão visualizar seus processos de forma simples e direta, bem como controlar as atualizações necessárias para o perfeito andamento do PCN.

CONTROLE DE ATUALIZAÇÃO

Uma vez construído o PCN, os diversos procedimentos devem ser atualizados sempre que alguma alteração tenha sido realizada no ambiente de negócios ou de infra-estrutura. Note que as regras de atualização devem ser criadas de acordo com o ativo ou com o processo de negócio. Determinado ativo pode ter uma regra de atualização a cada três meses, adequada a sua característica funcional, como por exemplo um sistema operacional de um servidor. Outro ativo, como por exemplo um equipamento de rede, pode ter uma necessidade de atualização menos intensa. O sistema deve permitir estas regras de configuração.

Como temos muitos ativos, processos, gestores e, principalmente, tempos de atualização diferenciados, é desejável que o sistema tenha uma integração com software de envio de mensagens ou correio eletrônico, para que os gestores sejam avisados da necessidade uma atualização. É muito importante o controle destas atualizações, de forma que estes logs sejam armazenados e impressos em forma de relatórios, para o devido controle das atualizações do PCN.

A emissão de relatórios com os logs do sistema pode facilitar o trabalho de auditorias, criadas especificamente para acompanhar o andamento e a usabilidade do PCN.

PLANEJAMENTO DE TESTES

Da mesma forma que o PCN deve ser atualizado, a realização de testes assegura a usabilidade dos procedimentos em situações de crises e desastres. É importante que os gestores tenham em mente que procedimentos testados garantem a eficiência de sua área em situações de anormalidades e, sobretudo, a continuidade dos negócios.

O sistema de gerenciamento de procedimentos deve permitir o planejamento de testes para cada tipo de procedimento, localidade e cenário. O ideal é que o sistema aproveite as bases de procedimentos, previamente separadas por recuperação, gerenciamento e contingência, usando-as para selecionar um plano de testes.

Um plano de testes pode ser executado para um único procedimento operacional ou para um conjunto deles. Devem estar previstos seus relacionamentos, locais de testes, cenários e, principalmente, suas atividades que serão validadas por uma equipe de inspeção e acompanhamento durante a realização dos testes.

ARQUITETURA TECNOLÓGICA

Cada empresa possui uma arquitetura de desenvolvimento adequada a sua realidade financeira, operacional ou gerencial. Independente desta adequação, o sistema deve possibilitar principalmente o acesso via web, de forma que numa situação de crise possa ser acessado através de um browser, em qualquer ambiente com acesso a internet.

Um aspecto importante na escolha da melhor arquitetura para construção de um sistema, deve ser o posicionamento do fornecedor de ferramentas no mercado e as perspectivas de adequação e implementação de novas tecnologias, com padrões abertos e independentes.

Como o sistema deverá ser acessado através de um navegador da internet, e deverá ser disponibilizado para todas as pessoas que fazem parte de um plano de recuperação de desastres ou de gerenciamento de crises, é importante a escolha entre uma aplicação cliente/servidor ou de uma aplicação três camadas.

No ambiente cliente/servidor o sistema é instalado no servidor, mas necessita a instalação em todas as estações de trabalho. Esta arquitetura pode custar caro, caso o fabricante opte por uma política de preços baseada em número de usuários, e pode gerar alguns problemas em relação ao acesso via Web.

No ambiente três camadas, a aplicação roda no servidor, sobre uma camada de aplicação e o acesso pode ser feito através de um navegador, sem a necessidade de instalações adicionais nas estações de trabalho, o que favorece a disseminação do sistema no ambiente corporativo e pode ser implantado independente do número de usuários. Cabe ressaltar que cada fornecedor possui um ambiente de aplicação para ser instalado o sistema de forma particular. A Oracle utiliza o Oracle Application Server, a IBM o Websphere, a Microsoft o Internet Information Server, e assim por diante. Neste caso o sistema deverá rodar sobre uma destas plataformas.

A escolha da melhor arquitetura depende muito da atual tecnologia implantada na empresa e da escolha da melhor estratégia de médio e longo prazo. O mais importante é possibilitar acesso irrestrito através de um navegador de internet e permitir a integração com novas tecnologias como java, SMS – Short Messages Systems e equipamentos móveis, como celulares e hand helds.

O Fator Tempo na Escala de Problemas (RTO e RPO)

Em inúmeros casos de desastres ocorridos pelo mundo, o fator tempo foi muitas vezes crucial para o pronto retorno das operações. As escalas de tempo para definir o limite de autonomia de um processo de negócios em situação de contingências e o tempo máximo para ativá-la, o limite estimado de recuperação de ativos e o limite de disponibilidade dos ativos ou dos sites alternativos são altamente importantes nas tarefas de continuidade de negócios.

Eventuais disfunções causadas entre o tempo de autonomia de um processo de negócios e o tempo de recuperação de um ativo que o suporta, leva a empresa a uma decisão estratégica: assumir o impacto causado por um processo ficar mais tempo em contingência, calculando seus prejuízos operacionais, financeiros, institucionais ou estratégicos; ou investir em tecnologia para diminuir o tempo de recuperação de um ativo que falhou.

Na área de segurança muito fala-se na meta e no ponto de recuperação. A meta de recuperação, conhecida como RTO – Recovery Time Objective, é estabelecida pelo tempo necessário de autonomia requerido pelos processos de negócios para manter-se operacional sem causar impactos corporativos. Um processo que se propõe a permanecer operacional até 5 horas depois de uma crise, pode gerar aos ativos que o suportam uma expectativa de tempo de recuperação idêntica. Já o ponto de recuperação ou RPO – Recovery Point Objective, determina o ponto em que devemos iniciar o processo de disponibilidade do dado ou da informação, antes de uma crise, visando atingir a meta ou RTO pre-definido. Por exemplo, no caso acima poderiamos definir um RPO de 3 horas, onde estariamos replicando de forma síncrona alguns dados para atender a meta de RTO de 5 horas.

Uma vez que a análise de riscos determine uma não conformidade entre os tempos requeridos pelos processos de negócios e o tempo em que os ativos são recuperados depois de uma crise, precisamos revisar ou redesenhar a atual estratégia, criando uma nova estratégia de recuperação que atenda os objetivos de forma mais adequada e conforme.

Justificando o Plano de Continuidade de Negócios

Para muitas empresas pode ser caro desenvolver um Plano de Continuidade de Negócios. Além do plano, devem ser alocados recursos para contratação de pessoal qualificado, locais alternativos de processamento, equipamentos redundantes, e armazenamento externo de dados. Os planos são descritos para recuperar funções empresariais vitais e não somente para se utilizar um ambiente alternativo de processamento. Se o plano incluir alternativas e soluções mais modernas, como atualização eletrônica de dados, os custos podem subir muito.

Porém, para aqueles dirigentes que pensam que plano de continuidade de negócios é um desperdício de dinheiro, alguns incidentes claramente colocam fora de questão a dúvida em ter ou não ter um plano elaborado, desde o grande blecaute de Wall Street, em 1990, passando pela inundação de Chicago em 1992 e a de New Orleans em 2005, até o ataque terrorista ao WTC em 2001, os prejuízos ultrapassam a casa dos bilhões de dólares para governo e empresas privadas.

Na falha de Wall Street 28 firmas se mudaram para hotsites, na inundação de Chicago o número ainda era mais alto: 33 firmas, e na onda de ataques ao WTC e Pentágono 200 firmas declararam estado de alerta. A bolsa de valores de Chicago, uma das maiores trocas financeiras do mundo, fechou completamente no primeiro dia da inundação e afetou todos os mercados financeiros mundiais por causa do volume de negociações não claras. O fato mais importante para qualquer executivo se lembrar sobre o incidente de Nova Iorque e os desastres de Chicago é que o custo em dólares mais freqüentemente ouvido é “bilhão”. As vezes é impossível refinar estas estimativas porque corporações são relutantes em discutir e trazer à público suas perdas reais.

Como uma corporação determina o dinheiro e recursos para dedicar ao planejamento da continuidade de negócios? A resposta é a análise de impacto empresarial. Esta análise deve servir os seguintes propósitos:

1) Identificar os riscos potenciais,
2) Estimar os efeitos de um desastre na organização,
3) Determinar as exigências para uma estratégia de recuperação.

A análise de impacto deve quantificar os efeitos da probabilidade de ocorrência de um desastre. Regras e critérios com ênfase em estimativas de rendas perdidas e produtividade deixarão uma impressão mais duradoura na administração do que uma análise nebulosa e subjetiva. Em outras palavras, a administração se convence quando lhe é falado que um vendedor perdeu uma ordem de $100,000 porque ele não pode obter cotações de preços quando o computador central estava fora do ar.

Business As Usual: Como construir, manter e monitorar um plano de continuidade de negócios

Este documento tem a proposta de prover uma abordagem detalhada para construir, manter e monitorar um plano de continuidade de negócios. Baseado na metodologia XCORP iMethod™, todas as etapas aqui sugeridas estão alinhadas com os objetivos de controle de mecanismos e normas internacionais como DRI - Disaster Recovery Institute, BCI - Business Continuity Institute, BSI - British Standard Institute, British Standard e ISO.

O documento ajuda quem está planejando a construção de um Plano de Continuidade de Negócios - PCN, ou até mesmo aqueles que já tem um plano em andamento. A metodologia XCORP iMethod™ detalha o modelo denominado Octágono - referência aos 8 passos pré-definidos para a construção de um PCN, em conformidade com padrões internacionais.

Abordagem de Continuidade de Negócios

As ocorrências de eventos naturais, físicos, tecnológicos e humanos são a cada dia que passa uma constante, e as empresas têm dificuldade de prever e se preparar para estes acontecimentos. Greves, vandalismo, bloqueio de estradas, enchentes e inundações, indisponibilidade de fornecedores vitais, black-out de energia e muitos outros eventos reduzem as atividades a ponto de colapso, com graves prejuízos financeiros e operacionais.

As empresas mais do que nunca precisam garantir a continuidade de seus negócios independente do tipo de evento que possa paralisar suas operações. A maior dúvida é de como gerenciar e gerir os procedimentos de Gestão da Crise, antecipando todos os tipos de ameaças que a empresa possa ter e se preparar para as mesmas. A impossibilidade de parada nos negócios gera uma grande expectativa para os executivos.

Ainda que estas interrupções possam ser de curta duração, seus efeitos são extremamente danosos e quase sempre irreversíveis. Dados fornecidos pelo Disaster Recovery Institute (DRI) demonstram que de cada cinco empresas que sofrem interrupção por uma semana, duas fecham as portas em menos de três anos. A utilização de metodologia associada à Gestão de Qualidade Assegurada, com a utilização de Métricas de Controle, permite o gerenciamento eficaz do gerenciamento de Projetos e de Serviços.

Eventuais coberturas securitárias apenas cobrem prejuízos patrimoniais ou lucros cessantes, mas não garantem a sobrevivência e continuidade dos negócios. Esta continuidade só é garantida e conquistada através de planejamento, implementada por especialistas em Continuidade de Negócios, que disponibilizam conhecimento, experiência, ferramentas e metodologia específica.

BUSINESS AS USUAL: Seus negócios funcionando como sempre

O Plano de Continuidade de Negócios é um documento que tem a finalidade de minimizar e administrar o impacto de eventuais crises ou desastres, que venham causar a falha ou interrupção do ambiente operacional ou de negócios da Empresa.
Após uma compreensiva análise do ambiente corporativo e de suas unidades de negócios, realizado através de entrevistas com os gestores dos principais processos da Empresa, os dados devem ser tabulados numa ferramenta de análise de impacto, para se chegar a uma classificação final de importância, criticidade e vulnerabilidade.

O documento final tem por objetivo garantir a continuidade operacional dos processos de negócios críticos e imperativos da Empresa e a alta disponibilidade dos ativos que os suportam, levando-se em conta 04 objetivos principais:

I. Contingência: Detalhar os procedimentos de contingência dos processos de negócios, visando uma continuidade operacional em situações críticas;
II. Recuperação: Documentar os procedimentos operacionais de recuperação de ativos, garantindo a sua disponibilidade no tempo e nas condições exigidas pelos processos de negócios;
III. Gestão de Crises: Organizar os procedimentos, processos e recursos necessários para a administração e o gerenciamento de eventuais crises que possam afetar a infra-estrutura e os negócios da empresa.
IV. Ações Emergenciais: Desenvolver os procedimentos, processos e recursos necessários para ações e resposta às emergências utilizadas pelo colaboradores da empresa, em situações de crises e desastres.

O entendimento do funcionamento do manual e sua estratégia de divulgação são as principais preocupações da diretoria executiva, que se sucede pela implementação das medidas preventivas sugeridas e do treinamento dos gerentes de cada uma das áreas da empresa.

Com uma rápida e precisa coleta de informações de gestores, processos de negócios e tecnologia, através de rotinas e templates pré-definidos, é possível desenvolver um Plano de Continuidade de Negócios de forma simplificada, assegurando a qualidade e a usabilidade dos procedimentos, em situações de panes, falhas, crises ou desastres.

Introdução ao Projeto

As interrupções nos negócios, curtas ou prolongadas, afetam diretamente seus resultados, com reflexos no market-share, na credibilidade e no seu maior patrimônio: o relacionamento com os clientes. Entre as grandes missões dos executivos do novo milênio está a de garantir a continuidade das atividades das empresas, sempre em sintonia com as necessidades emergentes dos mercados.

Existem vários tipos de ameaças para as quais, geralmente, as empresas não se preparam. Uma catástrofe pode ser causada por eventos graves como incêndios, enchentes, roubos, vandalismo, sabotagens, hackers, ou até mesmo fruto de um pequeno incidente, como acessos indevidos.

O Plano de Continuidade de Negócios - PCN é uma das soluções primordiais para as empresas permanecerem competitivas no mercado. Através do PCN, a empresa garante o funcionamento de seus processos, independente das falhas de infra-estrutura que possam ocorrer no ambiente de negócios. Negócios rodando como sempre, para sempre… Isto é “business as usual”.

Resumo das Atividades do projeto

Baseado na experiência de projetos extensivos de análises de riscos e continuidade de negócios, você poderá seguir as etapas descritas abaixo:

1. Kick-Off do Projeto: Neste momento deve ser realizado um workshop, direcionado para os gestores de área de negócios e de TI, onde são apresentados (a) a visão geral do projeto, ( b) o detalhamento das atividades, (c) a metodologia empregada e (d) o formato de coleta de dados. A idéia é apresentar os principais controles que devem ser implementados visando o atendimentos a normas internacionais de gestão de riscos e continuidade de negócios.

2. Diagnóstico: O objetivo desta etapa é o entendimento e mapeamento de todos os ativos de hardware e software da empresa, e sua relação com os processos de negócios. O resultado do trabalho visa identificar todas as unidades e processos de negócios e os equipamentos da atual estrutura que o suportam, possibilitando fornecer informações importantes aos gestores e ao projeto de continuidade de negócios.

3. Análise de Gaps: Em cada unidade pode ser realizada a análise de GAP, onde é comparada a situação atual (x) com a situação desejada (y), de acordo com a normas internacionais de continuidade de negócios e/ou segurança da informação. No final os Gaps podem ser visualizados através de gráficos MS-Excell do tipo radar, demonstrando-se a efetividade, urgência e riscos de controles não implantados. Para cada Gap avaliado é desenvolvido o respectivo embasamento técnico e apontadas as devidas correções necessárias no ambiente.

4. Extensiva Análise dos principais Riscos: Para cada unidade deve ser realizada (a) a análise de impacto nos negócios, no caso de uma indisponibilidade ou interrupção na infra-estrutura, e (b) a análise de vulnerabilidade de ativos. Como resultado teremos os processos de negócios classificados em Imperativos, Críticos, Essenciais e Periféricos, e os ativos classificados em ordem de vulnerabilidade. Para cada Risco avaliado deve ser desenvolvido o respectivo Plano de Tratamento.

5. Descrição dos Procedimentos: Nesta etapa é onde são desenvolvidos e documentados os procedimentos de (a) Contingência, para processos imperativos e críticos; (b) Recuperação de Desastres para os ativos considerados críticos pela análise de riscos; (c) Gestão de Crises, para as principais ameaças; e (d) Ações Emergenciais, para as principais emergências. Para cada Grupo de Ativos, Processos de Negócios, Ameaças e Emergências devem ser considerados cenários de crises e para cada cenário descritas as ações e procedimentos operacionais, no conceito da ISO e da técnica 5W2H (o que, quem, quando, como e pontos críticos).

6. Programa de Gestão de Crises: Após a descrição dos procedimentos operacionais, um extensivo programa para gerenciar todas as crises com probabilidade de ocorrência no ambiente corporativo deve ser detalhado e descrito. Papéis e responsabilidades devem ser definidos para todos os envolvidos nos grupos de apoio, como comitê de gestão de crises, equipe de gestão de incidentes, board de diretores, stakeholders, etc. Um centro de gestão de crises deve ser planejado, para notificar, monitorar e suportar as operações dos diversos grupos em situações de emergências, crises e desastres.

7. Manutenção da Continuidade de Negócios: A equipe de continuidade de negócios deve programar testes e simulações dos procedimentos de contingência desenvolvidos para os ativos e processos críticos. Regras e controles para atualizações dos procedimentos devem ser rigorosamente planejados para todos os níveis da organização.

8. Programa de Treinamento e Divulgação: Um programa completo de treinamento deve ser construído e orquestrado para os diversos grupos que terão acesso aos procedimentos de contingência (key-users, usuários e administradores). Uma campanha de conscientização é recomendada para disseminar conhecimento e cultura da continuidade de negócios.
Como parte final dos trabalhos, a fase de quality assurance deve garantir e assegurar a qualidade de todos os entregáveis do projeto.

Ao final do projeto a empresa terá uma visão geral dos principais Riscos, um detalhado Plano de Tratamento dos Riscos, visando ações para remediá-los, transferi-los ou aceita-los, e em conformidade (compliance) com as principais regulamentações.

* Todo o material e relatórios gerados podem e devem servir de evidências para auditorias como Sarbanes-Oxley, BACEN 3380, ISO27000 e SAS70.