Wagner Elias - Think Security First

Isso mesmo! Ontem as 21hrs. eu tive a oportunidade de sentir o tremor que foi percebido nos estados de São Paulo, Parana e Santa Catarina.

"Um terremoto de 5,2 graus de magnitude na escala Richter atingiu diversas regiões de São Paulo na noite desta terça-feira (22), e foi sentido em mais quatro Estados. O epicentro foi no mar, a 215 km da costa do Estado de São Paulo, segundo informação do Observatório de Sismologia da Universidade de Brasília (UnB). O fenômeno foi registrado às 21h00min48 e durou três segundos. O tremor foi um dos sete maiores em magnitude registrados por sismógrafos no país, segundo o professor George Sand França, da UnB."

Fonte: UOL

Eu moro no último andar de um edifício na Capital de São Paulo, mais precisamente no décimo quarto andar. No momento do incidente minha esposa logo gritou desesperada, já minha filha de 3 anos achou um barato. "Papai a cama está balançando!". Em seguida, minha sogra que mora no mesmo prédio nos liga contando o fato e afirma ter conversado com a portaria e foi informada que vários moradores sentiram o mesmo. Era mesmo um terremoto!

A reação neste momento podem ser as mais variadas, como nós estamos preparados? Quando digo estar preparado não estou falando em construir estruturas que suportam abalos sísmicos e sim resposta e suportes básicos aos seres humanos, como já escreveu meu amigo Fernando Fonseca sobre a pirâmide de Maslow. Estou falando de Human Resilience, a principal e mais difícil parte na resposta a qualquer incidente. Está mais que na hora das organizações e instituições governamentais colocarem a prova aqueles planos que custaram uma boa quantia em recursos e servem apenas para compliance e/ou respostas a incidentes envolvendo recursos tecnológicos.

Uma boa referência para o tema pode ser o plano estratégico que foi recentemente apresentado pelo NIST - US National Earthquake Hazards Reduction. Espero que as autoridades estejam atentas e trabalhando neste sentido.

Estava lendo o blog do Anderson Ramos e vi que a ENISA (European Network and Information Security Agency) publicou um guide interessante sobre implementação de um processo de gestão de continuidade de negócios.

Em breve escrevo minhas impressões sobre esta publicação e o Cert Resiliency Engenieering Framework.

Na metade do ano passado eu fiz um review de um framework que o Cert estava trabalhando. O Cert Resiliency Engenieering Framework é um material que impressiona. Na época eu fiquei bastante empolgado e agora finalmente ele foi lançado e está aberto para comentários.

Ainda não tive a oportunidade de estudar o guide com impressionantes 456 páginas de conteúdo. Em breve pretendo colocar minhas impressões sobre o material.

No meu último post sobre BCP, algumas considerações apareceram, a primeira delas do meu amigo Paulo Teixeira, tratava da necessidade de se manter planos atualizados e disponíveis. Vou falar um pouco sobre minha experiência em controle e distribuição de planos. O comentário do colega Fabio Urias será respondido em outro post sobre conscientização e treinamento.

A primeira coisa que devemos deixar bem claro quando falamos de controle e distribuição dos planos é a diferença entre documentação física e digital. Vamos começar tratando as características comuns sobre os dois tipos.

Organização

Os planos devem estar disponíveis/acomodados de maneira organizada e com índices/ferramentas que facilitem a pesquisa e consulta.

Controle de Versão e Alteração

A base para um controle eficaz de toda documentação é o controle das alterações e versões de cada documento. É necessário documentar todas as alterações realizadas em cada documento e saber exatamente quais são as versões atuais e que estão em uso no plano.

Granularização dos Planos

Para se obter o sucesso na Resposta a Incidentes é necessário que o Plano de Continuidade de Negócios da organização esteja dividido em vários Planos/Procedimentos que será distribuído a cada responsável. Na minha opinião uma falha grave é distribuir um book (um amontoado de papel descrevendo tudo que está definido como procedimentos de resposta). Cada indivíduo responsável por alguma atividade de resposta deve possuir apenas sua parte do plano e ser gerenciado por um coordenador de posse de um plano macro que irá definir quando cada atividade será executada.

Distribuição Controlada

Como é necessário distribuir vários documentos a indivíduos distintos da organização é deve ser implementado um processo onde as alterações dos planos devem ser analisadas, visando a distribuição ou não de novas versões. Estes planos devem estar classificados de acordo com a política de classificação da empresa e sempre que for identificado a necessidade de uma nova versão um procedimento deve ser executado para distribuir estes documentos.

Cópias Alternativas

Cópias alternativas dos planos devem ser mantidas off-site (site ou local alternativo) e um procedimento para facilitar o acesso deve ser de conhecimento de todos. 

Testes dos Planos

Como uma alteração no Plano de Continuidade de Negócios da Organização pode ser demandada por qualquer área/indivíduo é necessário criar gatilhos para identificar a necessidade de testes dos planos. Estes testes são atipicos, portanto são planos extras, além dos testes programados no programa de testes.

Após a definição clara de um processo de Controle e Distribuição de Planos que leve em considerações as características comentadas, devemos ficar atento a características de cada tipo de documento.

Documento Digital

Os documentos digitais (word/excel/pdf/*) são a base para a disponibilização dos documentos físicos. Além de estar atualizados, escritos de forma clara e concisa é necessário que ele esteja disponível e acessível por todos os envolvidos na resposta a incidentes. É imprescindivel que estes documentos possuam um controle de acesso e backups eficazes. Ferramentas de Gestão de Continuidade podem ajudar a organização dos planos digitalmente.

Documento Físico

Apesar de muitos acharem que tudo se resume ao mundo digital e tecnologia, os planos distribuídos no bom e velho papel cumprem papel importante em muitas situações. Não são poucas as situações onde não vamos dispor de recursos tecnológicos para acessar aquela ferramenta que gastamos uma fortuna ou aquele documento digital disponível em um repositório na rede da organização. Para distribuição destes planos é necessário estabelecer procedimentos formais suportados por formulários específicos para documentar cada ação.

Estes formulários alem de servir como evidência para auditoria tem papel fundamental na troca de versões. O formulário irá documentar a troca e formalizar a destruição física (fragmentação de papel) do documento antigo. Isso irá garantir que apenas versões atuais e funcionais vão estar disponíveis.

Estas são características essenciais para que uma organização possa usar seu Plano de Continuidade de Negócios e consiga responder de forma adequada a incidentes que possam interromper as suas atividades.

Uma coisa que eu tenho me questionado há algum tempo é a definição de cenários para elaboração de projetos de implementação de BCP. Após a leitura deste artigo (Verdades sobre a Paranóia do Plano de Contingência), que me pareceu muito um BCP (Bullshit Compliance Plan), pois o autor focou na necessidade de conformidades legais de um "Plano de Contingência", resolvi escrever logo sobre isto.

Eu posso e qualquer um pode, afirmar que não é possível prever todos tipos de cenários. Por mais que uma das principais características de um plano eficaz seja a implementação de um ciclo PDCA (Plan, Do, Check, Act), que irá realizar análises de riscos continuas e que poderão identificar e prospectar novos cenários, não é possível identificar todas as possibilidades.

Análise de Riscos que, em BCP (Business Continuity Plan) tem como principal objetivo identificar quais as principais ameaças e sua probabalidade de ocorrência. Com base nestas informações e nos impactos que serão identificados na BIA (Business Impact Analysis) eu preciso tomar a seguinte decisão:

1 - Quais riscos podem ser tratados? Se for identificado que os custos e possibilidades para tratamento são viáveis eu trato o risco;
2 - Todos os riscos que eu não consigo tratar, desenvolvo plano de respostas.

Portanto, planos de respostas devem auxiliar a organização a responder a todas as ameaças que não foram tratadas ou identificadas.

Esta introdução é para questionar Uma técnica bastante utilizada, a definição de cenários para elaboração de planos de respostas. Técnica que geralmente começa com um cenário absurdo (geralmente chamado de pior cenário) que é muito pouco provável de acontecer. Mesmo sendo cauteloso, tentando prever um cenário que seja factível, ainda assim não conseguiremos mensurar todos os cenários que possam impactar os negócios. Os cenários podem ser usados para coletar informações e realizar testes para validação dos planos de respostas, mas nunca deve ser o principal balizador para um Plano de Continuidade de Negócios.

Como podemos tratar esta característica?
A solução é trabalhar para responder a qualquer incidente.

Como podemos responder a qualquer incidentes?

• Tenha uma matriz de níveis de crise bem elaborada e alinhada com as necessidades da organização;
• Tenha um plano de gerenciamento de crises e comunicação claro e de entendimento de toda organização;
• Conheça e mantenha uma documentação clara de toda sua arquitetura e principais características do ambiente;
• Planeje, teste, ajuste com frequências seus planos de respostas a incidentes;
• Faça um trabalho de lições aprendidas após cada incidente.

Recomendo a leitura dos documentos do Governo Americano (National Response Framework)

RPO (Recovery Point Objective) é a métrica utilizada para identificar a disponibilização de dados que atendam os RTOs definidos para cada processo de negócio.

Não entendeu nada? Fique tranquilo, é o que eu mais vejo por aí!

Em poucas palavras o RTO é quanto o processo suporta de perda de dados. Não confunda isto com o último backup realizado, equívoco bastante comum entre os profissionais de contingência, infra-estrutura.

O último backup realizado pode servir como métrica para desenvolver uma estratégia para garantir a continuidade de processos de negócios, mas o RTO consiste em um objetivo, como o acrônimo RPO (Recovery Point Objective) deixa claro.

Vamos tentar clarear as coisas. Aconteceu um incidente, preciso restabelecer um processo dentro do objetivo de recuperação que eu identifiquei (RTO). Para restabelecer este processo eu preciso de dados, ai entra o RPO. Se eu preciso de dados de 2 horas (meu RPO) antes do incidente e meu último backup é de 24 horas atrás, tenho um problema sério.

Para atender o meu RPO de duas horas preciso alterar a minha estratégia de backup ou fazer uma reengenharia no processo.

Porque reengenharia no processo?

Porque não é sempre que o meu problema é apenas com dados digitalizados. Se o problema é backup, eu posso mudar minha solução de backup, alterar a estratégia. Agora se o processo depende de informações "não digitais"? Ai só uma reengenharia no processo pode resolver ou minimizar os impactos.

O termo RTO (Recovery Time Objective) é conhecido pela maioria dos profissionais que atuam direta ou indiretamente com Continuidade de Negócios.O RTO consiste no tempo em que determinado processo tem para que, uma solução de recuperação e/ou contingência seja executada/ativada antes que o processo venha causar impacto a organização.

Se já sabemos o que é o RTO, não existe dificuldade em identificar junto aos responsáveis pelo processo, qual o RTO de cada processo. Errado, boa parte dos RTOs identificados em trabalhos de Continuidade de Negócios não condizem com a realidade e acabam direcionando as organizações a tomar decisões precipitadas.

A primeira coisa que devemos nos ater é, o RTO é apenas o tempo que o processo tem disponível para ser suportado por uma solução alternativa que o mantenha a níveis satisfatórios sem causar impactos a organização. Neste tempo teremos apenas uma solução de contorno (Workaround), o que difere do tempo total que um processo pode ficar indisponível. O tempo total que um processo pode ficar indisponível é definido segundo a BS 25999-1 como MTPD (Maximum Tolerable Period of Disruption).

Então podemos identificar pelo diagrama abaixo que, eu preciso subtrair do tempo total que o processo pode ficar indisponível o RTO mais o tempo para reestabelecer a normalidade.

Se não bastasse o equívoco cometido quanto aos tempos de RTO/MTPD, muitos generalizam o tempo assumindo que o MTPD é o RTO, ainda temos um problema mais sério. A maioria dos RTOs mapeados em projetos é muito mais baixo do que deveria. Na prática são raras as exceções onde um processo tem RTO menor que 1, 2 hora. O que quero dizer com isto? A maioria dos profissionais valorizam muito os RTOs sem medir ou conhecer as consequências. Um processo que pode ter até 24 horas de RTO é mapeado com um 1 hora como se não houvesse problema nisto.

O grande problema quando mapeamos RTOs relativamente baixos é a solução de estratégia. Sabemos que os RTOs e critícidades dos processos da organização são mapeados na BIA (Business Impact Analysis), fase esta que antecede e serve como tomada de decisão para a próxima fase, seleção de estratégia.

Na fase de Seleção de Estratégia vamos planejar e identificar soluções para atender os tempos mapeados como objetivo (RTO) na BIA. O que acontece quando os RTOs são muito baixo? As soluções para atender estes tempos serão soluções de alta disponibilidade e consequentemente terão um custo muito mais alto que qualquer plano de resposta. Ao contrário do que muita gente pensa, Se sabemos que são raras as exceções de RTO entre 1 e 2 horas, consequentemente são raras as exceções onde você necessita de Alta Disponibilidade para atender as necessidades da organização.

Resumindo, Planos para Continuidade do Negócio estão longe de ser soluções de contingência e a maioria das organizações estão gastando mais do que deviam com soluções de Alta Disponibilidade e Contingência.

No próximo post vou falar sobre o RPO (Recovery Point Objective).

A coisa está ficando ótima para quem trabalha com Continuidade de Negócios. Calma, não estou falando que estamos ganhando rios de dinheiro ou que o mercado está bombando. Eu me refiro a quantidade de padrões que estão surgindo para embasar argumentos que muitas vezes ecoavam nos corredores sombrios das organizações e nada era feito.

O mercado está cheio de curioso, charlatão, marqueteiro, que diz conhecer Continuidade de Negócios, todos eles usam a famosa bomba de fumaça: Plano de Continuidade orientado a ISO 27001 e agora o mais novo hype, BS 25999.

Os mais informados sabem que nenhuma das duas lhe ajudará ou dará o caminho das pedras para desenvolver um processo de Continuidade de Negócios. A ISO 27001 apenas diz que você deve ter um plano, a BS 25999 é um sistema de gestão dos controles relacionados ao processo de Continuidade de Negócios.

Um profissional que conheça além de meia dúzia de Buzzword relacionados ao tema, agora tem dois padrões bem interessantes.

Série 28000 - Security management systems for the supply chain

Este padrão vem colaborar com os conceitos básicos de Continuidade de Negócios e segurança. Continuidade de Negócios deve gerenciar riscos com uma visão holística e segurança é transitiva. Do que adianta eu ter inúmeras soluções de alta-disponibilidade e contingência, se meu negócio pode parar se um fornecedor chave por algum motivo deixar de me fornecer?

ISO/PAS 22399 - Guideline for incident preparedness and operational continuity

Este padrão foi recebido com imensa alegria por mim. Sempre que eu tentei dizer que todo o processo de Continuidade de Negócios são controles de resposta a incidentes, achavam que eu era louco, que estava inventando moda.

Agora quem está dizendo é a ISO e não eu. Agora vou dar uma de louco novamente!

Todo profissional de segurança adora falar coisas como estas:

• Não existe segurança 100%
• Segurança é equilibrio

Se sabemos que, em algum momento um incidente vai acontecer, deve existir um equilibrio entre controles e procedimentos de resposta. Por que pouco se investe em Resposta?

Quando aqui no Brasil vamos ter soluções que são muito mais que recursos de HA (Alta Disponibilidade)?

O Estado do Texas nos EUA está implantando um sistema muito interessante baseado em RFID. Evacuação de ambientes é uma coisa bem crítica em determinadas situações, o sistema vai rastrear todos os envolvidos e monitorar uma evacuação.

Meu amigo Eduardo Neves me enviou uma notícia bem interessante pra quem trabalha com BCP (Business Continuity Plan).

Notícia veiculada no G1

Uma operação no Aeroporto Internacional de Campo Grande, no Mato Grosso do Sul, vai simular um grande acidente com um Boeing 737-200. A simulação vai mobilizar forças civis, militares e de órgãos da segurança pública. Alunos do curso de resgate e de duas faculdades de enfermagem representarão os 'passageiros' do acidente.

A simulação, que acontece na próxima segunda-feira (19), vai encenar o combate a um possível incêndio na aeronave e resgate de vítimas. Acadêmicos da Universidade para o Desenvolvimento do Estado e da Região do Pantanal (Uniderp) e Universidade Católica Dom Bosco (UCDB) e do curso de resgate dos Bombeiros serão os passageiros e terão os 'ferimentos' maquiados por alunos do curso de teatro da UCDB.

A operação está sendo preparada pelo Corpo de Bombeiros Militar em conjunto com a Base Aérea de Campo Grande, Infraero, unidades do Exército, Polícia Militar, PRF, Polícia Civil, Coordenadores de Defesa Civil do Estado e de Campo Grande, Samu, Hospital Regional e Santa Casa. Dois helicópteros serão usados para transportar as vítimas para os hospitais.

O exercício, segundo o tenente-coronel do Corpo de Bombeiros Jonys Cabrera Lopes, busca estabelecer coordenação em atividades de gerenciamento de crises em acidentes e desastres de grandes proporções com o emprego do sistema Integrado de Comando de Operações de Emergência.

Na operação simulada, considerada de 'grande magnitude', serão empregados todos os meios, incluindo um Boeing 737-200. O resgate será encenado o mais próximo de uma emergência real, segundo o Corpo de Bombeiros. Os resultados do exercício serão usados para planejamento e treinamento, além de 'adequações de protocolo' entre as instituições envolvidas na operação para enfrentamento de situações semelhantes.