Muito se fala de Continuidade de Negócio, ou da sigla em inglês “Business Continuity Plan” (BCP), pela área de Tecnologia e, ainda, nos times de Infosec. Este tema parece ser tão conhecido por parte destes profissionais, mas, ao mesmo tempo, é um assunto muito distante do esperado.
Diante dos ataques de 11 de setembro de 2001, nos EUA, eu trabalhava para um banco americano e me lembro deste evento, ocorrido nas Torres Gêmeas do World Trade Center em Nova York, que desabaram depois que dois aviões comerciais colidiram. Infelizmente foi um evento triste para a humanidade, mas despertou uma nova forma de olhar para o quesito da continuidade das operações críticas de negócios.
Lembro que, naquela manhã, quando cheguei ao banco no centro de São Paulo, imediatamente fomos chamados pelo diretor e comunicados, pelas cenas da CNN, do ocorrido naquela manhã em Manhatan. Um colaborador americano que trabalhava na matriz do banco em NY ligou pedindo ajuda para nós realizarmos os backups remotamente, pois eles tinham recebidos ordens para deixar o prédio imediatamente devido a segurança pessoal. Então ajudamos com o backup e, mais tarde, o prédio foi afetado por uma das torres, onde a ação fez a diferença.
Logo depois deste evento, especialistas e entidades de segurança levaram tal tema em uma velocidade extrema e, então, pudemos perceber o quanto as empresas estavam despreparadas sobre o assunto de Business Continuity Plan (BCP) e Desaster Recovery Plan (DRP). Algumas companhias que mantinham o site principal na Torre Sul e o site backup na Torre Norte sofreram consequência incalculáveis, levando até a falência (bankruptcy).
Na época, seguradoras e bancos já investiam alto em continuidade de negócios e recuperação de desastres para as operações críticas, pois, entidades regulamentadoras, como o Banco Central, já determinavam que essas instituições deveriam assegurar a continuidade de suas operações. Ainda mais com a Sarbanex-Oxley e Basiléia, que impulsionaram a importância deste requisito.
Quase 20 anos depois, este tema ainda é tratado com soberba. Como dizia o Rei Salomão em Provérbios 16:18 “A soberba precede a destruição, e a altivez do espírito precede a queda”. Pois é, pode parecer ilusão, mas a realidade hoje é muito mais profunda para grandes organizações. Como exemplo, alguns meses atrás tivemos o caso do incêndio no datacenter de uma grande operadora de planos de saúde no Sul do Brasil. Infelizmente a falta de um DRP e uma estrutura adequada para um datacenter levou à indisponibilidade, uma perda relevante em termos financeiro e perda de dados.
Ainda hoje é comum encontrar empresas sem um BCP e um DRP documentado, atualizado e testado. Algumas confundem o termo “disponibilidade” do ITIL como Business Continuity definido na ISO 27001 e na certificação ISO 22301. Evidente que manter um processo de BCP e DRP é muito mais complexo do que se possa imaginar e requer tempo e recursos. Grandes corporações possuem uma área exclusiva e dedicada para esta matéria e pequenos detalhes geram muitas dúvidas. Sendo assim, procurei compartilhar abaixo os pontos de atenção no qual tive que considerar em um projeto de BCP que implementei para uma companhia.
Análise de Impacto ao Negócio (BIA) – É fundamental o mapeamento das operações críticas do negócio no qual você está atuando. Para isso é preciso definir as áreas que serão contempladas, cronograma de entrevistas, agendamento de reuniões para definição do BIA, complemento e correções, elaboração do relatório com o resultado e validação com os owners dos processos. O entrave aqui é o tempo e disponibilidade para falar com os owners. Usar um checklist para mapear os processos por meio de um questionário de perguntas é fundamental. Caso já tenha um mapeamento dos processos críticos de negócios da companhia use para elaborar o BIA, mas não descarta as reuniões com owners.
Definição de criticidade dos processos – É fato que cada owner irá determinar que seu processo é mais crítico que o outro, mas você precisa ter em mente qual é o coração da empresa, onde se ganha dinheiro: se for um banco, a mesa de operações, o Internet Banking, o call center, etc. Leve ao executivo principal e/ou CRO e CEO, e discuta para ajudar nesta definição.
Especificação do site alternativo – Para montar o BCP é importante compreender que está ligado a pessoas. Entretanto é necessário obter o mapeamento da infraestrutura predial, infraestrutura de processamento de TI, lista de funcionários, parceiros e fornecedores e, por fim, a elaboração da especificação do site alternativo. Com estas informações você poderá definir os custos necessários e o plano para implementar as operações em um site altenativo, tipo de site hot, warm, cold, mobile, etc.
Implementação da solução – Uma vez definida a estratégia de implementação, considerando os custos do site alternativo, precisa ficar claro a ordem de recuperação do processo mais crítico para o menos crítico. Avalie o local para implementar o site alternativo tanto para o negócio como para TI, aprovação dos locais, além disso considere identificar os recursos necessários para construção do site alternativo, ambiente de teste e homologação. Enfim, a elaboração do plano em si documentado (BCP) e (DRP) e validação dos mesmos.
As dificuldades não mencionadas – Tudo parece fácil em um manual ou norma para elaboração de um BCP e DRP. Evidentemente que é durante o projeto e dia a dia que se aprende a ser resiliente. Novamente é importante destacar que o BCP está ligado a pessoas e o DRP a TI, por meio do BCP se define o site alternativo onde os colaboradores irão dar continuidade em suas tarefas diante de uma greve ou desastre, dado que a tecnologia proporcionou o trabalho remoto que pode reduzir os custos, mas pense se o Call Center é um dos processos fundamentais para operações de cartão de crédito da sua empresa, pense que juntar 30 posições para um call center vai requerer um espaço estruturado e pode ficar caro o aluguel. Já o DRP é TI, é tudo que relaciona a infraestrutura das operações, servidor, banco de dados, network, link. Internet, etc.
Outras dificuldades
– Levantamento dos requisitos do site alternativo e custos pode levar mais tempo que o programado para a entrega do projeto;
– Escolha e aprovação do site alternativo pode ter um custo altíssimo e levar a alta direção a usar sites da empresa ou parceiros como site backup e, também, pode atrasar no cronograma. Espaço para marcação e definição das posições de trabalho pode não ser o suficiente para atender o escopo!
– Interligação com o processo de change management. O DRP precisa estar alinhado e pautado quando houver alterações no ambiente pertencente ao escopo das operações críticas e manter-se sempre atualizado;
– Lista dos contatos (nomes, transporte, cias de ônibus, táxi, transfers, telefones, celulares). Na hora “h” pode haver uma grande pressão e tais informações, se não estiverem bem acessíveis, impactam no processo. Pequenos detalhes podem fazer a diferença: pense numa caixa de pequenos socorros fácil de encontrar!
– Disponibilidade do plano e a documentação entre pessoas do grupo. Se houver um incidente, falha de sistema ou desastre natural e for definido que o DRP precisa ser executado, pense no backup de pessoas em áreas diferentes.
– Estabilidade e saúde financeira do vendor ou provedor de cloud. Monitore o ambiente por meio de um due diligente linkado com o third party risk management checando aspectos de segurança, disponibilidade e funcionalidade.
– Entender o Disaster Recovery e continuidade do SLA: quantas cópias de seus dados são realizadas, em quais locais e o que acontece se a infraestrutura falhar?
– Mantenha um consultor especialista no assunto contratado ou área especialista gerindo o processo. A falta de um especialista pode levar seu barco a afundar na horar que precisar operar o plano. Alguns owners em empresas globais podem achar que não vale pagar um recurso para cuidar do DRP, mas você como ISO deve avaliar o risco versus o custo de um profissional especialista e o custo da indisponibilidade da aplicação. Na real, o negócio chegará a conclusão que vale a pena investir em um profissional para cuidar do DRP dependendo do escopo e criticidade. Portanto aplique uma boa dose de análise de risco!
– Diante de um incidente mantenha atualizado os executivos sobre os passos e porcentagem da recuperação das operações críticas, é fundamental dar esta visibilidade por meio e um painel ou ferramenta que pode ser encontrada no mercado ou desenvolvida internamente. A ausência deste processo pode gerar insegurança para os membros do board.
– Quando executar os testes? O tempo para executar o teste pode variar de empresa para empresa. O ideal é que seja pelo menos anualmente, já vi casos de bancos realizarem 2 vezes ao ano, não tem uma receita, mas é internamente com as equipes de negócios, compliance e auditoria que você pode chegar a um consenso e determinar a melhor frequência.
– A estratégia de teste – Na hora da recuperação o plano de gestão de crise falha porque não está atualizado, o contato do DBA ou o procedimento para recuperação (roll back) em um banco dados para uma aplicação não funciona, pois houve uma mudança dois meses atrás que não refletiu no procedimento por meio do processo de change management. Portanto, isso pode gerar um custo maior e o impacto no RPO e RTO.
– Ausência de consciência do executivos e equipes de tecnologia sobre o tema pode colaborar para um desastre e risco para o negócio. Então a missão aqui é conscientizar continuamente.
Concluindo
BCP e DRP são, e irão continuar sendo, fundamentais para a sobrevivência das organizações, mas, creio que o desafio principal será garantir o pleno alinhamento da segurança cibernética com mapeamento das operações críticas de negócios, uma vez que as empresas estão movendo para o ambiente de cloud (IaaS, PaaS e SaaS). Dependendo do modelo contratado é necessário entender a diferença entre as responsabilidades da sua empresa com o provedor de cloud e serviços, para determinar as obrigações e requerimentos de segurança no contrato, que devem ser, impreterivelmente, monitorados pelo processo de third party management. Lembrando que, na particularidade de DRP que está relacionado a TI, alguns provedores de cloud como AWS, Azure, Google Cloud, Bluelock e RackSpace, algumas já oferecem o modelo de DRaaS (Disaster Recovery as a Service) que ajuda a viabilizar os requisitos da sua política de segurança corporativa.
Alguns bancos ainda são mais cautelosos em manter todo processamento em uma nuvem própria (privada), como fosse uma extensão da sua rede. Embora o caminho para o futuro será em cloud e a segurança dos dados e privacidade, o desafio para testar um DRP se tornará mais e mais complexo.
Sugiro aqui considerar um bom plano de cybersecurity usando o framework sugerido pelo NIST assegurando uma boa estratégia e, se você é de banco, considere a Resolução nº 4.658 do Banco Central, que recentemente entrou em vigor. Um bom plano cybersecurity contemplando as funções (Identify, Protect, Detect, Response e Recover) inteiramente irá contribuir para manter o seu DRP funcionando e nivelado com processos críticos do seu negócio. Por exemplo, na fase Recover, que exige uma avaliação dos stakeholders para que respondam com eficiência a um BCP e DRP.
Ressalto a importância de implementar o CARTA (Continuous Adaptive Risk and Trust Assessment), uma nova ferramenta para ajudar as empresas a entender melhor sua exposição ao risco em ambiente de multicamada como Cloud. Como o amigo Augusto Paes de Barros, do Gartner, comentou em um artigo: “é uma nova abordagem estratégica, continua e proativa que ajuda a gerir melhor os riscos associados aos ecossistemas de negócios digitais que significa identificar os problemas mais cedo, bloquear o que é possível, e responder ao que não pode ser prevenido, sendo uma boa ferramenta para um Disaster Recovery Plan (DRP) em Cloud”.
* Rangel Rodrigues é especialista em Segurança da Informação, CISSP e pós-graduado em Redes de Internet e Segurança da Informação pela FIAP e IBTA, e MBA em Gestão de TI pela FIA-USP
