72 horas numa violação de dados: para onde vai o tempo do lado do software

A notificação de violações é apresentada como um processo jurídico. Mas quanto deste prazo se perde é determinado pela forma como o sistema foi concebido, meses antes do incidente.

Um alerta chega à mesa de uma organização numa segunda-feira de manhã: foi detetado um acesso invulgar num servidor. A partir desse momento, o relógio das setenta e duas horas começa a correr.

Setenta e duas horas parece muito tempo. O que se segue é um relato hora a hora de para onde vai realmente esse tempo, porque sem ver essa repartição é difícil perceber por que razão a preparação para uma violação tem de ser feita meses antes, não durante ela.

As primeiras oito horas: será mesmo uma violação?

A primeira tarefa é determinar se o alerta é real. Pode ser um falso positivo, uma operação de manutenção ou uma permissão mal configurada.

Nesta fase, a equipa técnica analisa os registos. Se os registos não forem suficientemente bons, e na maioria das organizações não são, isto arrasta-se. Sem saber que conta acedeu a que tabela a partir de que endereço, não é possível dar nenhum passo seguinte.

O primeiro ponto crítico é este. Quem não mantém registos vê o relógio esgotar-se aqui, e esse tempo nunca mais se recupera.

As vinte e quatro horas seguintes: que dados foram afetados

Uma vez estabelecido que se trata de uma violação, surge uma única pergunta. Que dados pessoais existiam nesse servidor?

Uma organização com um inventário atualizado responde a isto em dez minutos. Uma que não o tenha tenta descobrir examinando o esquema da base de dados, verificando nomes de tabelas, extraindo registos de amostra, perguntando aos programadores. Só isso pode facilmente levar um dia inteiro.

A segunda metade da pergunta é mais difícil. O que existe nas cópias de segurança? Existe uma cópia que foi exportada para um relatório? Foi carregada uma amostra num ambiente de testes? Se as respostas não estiverem escritas em lado nenhum, acabam por assentar em suposições, e uma notificação baseada em suposições acaba por ter de ser corrigida depois.

As doze horas seguintes: quantas pessoas são afetadas

Uma vez delimitado o âmbito, é preciso produzir um número. Quantos titulares, que categorias de dados, que zonas geográficas.

Um erro frequente aqui é arredondar o número. Dizer "aproximadamente dez mil pessoas" não leva à rejeição da notificação, mas se mais tarde surgir um número real bem diferente, isso prejudica a credibilidade do que a organização declarou. Se não for possível obter um número exato, é melhor dizê-lo assim, e explicar porquê, do que arriscar um.

O tempo restante: preparar e enviar a notificação

A notificação ao Conselho deve cobrir quando e como ocorreu a violação, que categorias de dados foram afetadas, as suas possíveis consequências e as medidas tomadas e previstas.

Redigir isso a partir de uma página em branco consome o tempo que resta. Uma organização com um modelo já pronto preenche-o em meia hora. Quem está autorizado a assiná-la também deve ser decidido antecipadamente, porque se essa discussão começar nesta fase, não há tempo para ela.

Notificar as pessoas afetadas é uma tarefa à parte. Faz-se assim que for razoavelmente possível depois de identificadas as pessoas afetadas; se o contacto direto não for possível, recorre-se a outro meio adequado. A linguagem importa aqui. Uma mensagem enterrada em detalhe técnico impede que a pessoa perceba o que realmente tem de fazer.

O que o plano tem mesmo de conter

A lição deste percurso é esta. O valor de um plano de resposta a incidentes está em ter-se pensado antecipadamente no que é preciso pensar no momento do incidente.

Precisa de uma repartição clara de funções. Quem delimita o incidente, quem decide que é uma violação, quem assina. Um plano que depende de uma única pessoa cai no dia em que essa pessoa está ausente.

Precisa de um limiar definido. O que se considera violação deve estar escrito antecipadamente; caso contrário, essa discussão acontece dentro das setenta e duas horas.

Precisa de uma regra de preservação de provas. O primeiro instinto costuma ser limpar os sistemas afetados, o que torna impossível uma investigação adequada. O plano deve dizer explicitamente que os registos são mantidos intactos.

Precisa de modelos de comunicação já preparados, tanto para o Conselho como para os titulares afetados.

Nada termina quando a notificação é enviada

A notificação não é o fim da obrigação. O Conselho avalia se as medidas técnicas e organizativas adotadas foram suficientes.

Uma violação que se repete na mesma organização é interpretada como prova de que essas medidas não eram suficientes. Por isso, a ação corretiva adotada após uma violação deve ficar registada e o seu efeito deve ser medido. A frase "foram tomadas as medidas necessárias" não é, por si só, prova de nada.

A única coisa que vale a pena fazer hoje

O mais rentável que se pode fazer antes de sofrer uma violação é elaborar o inventário juntamente com a localização física dos dados: que base de dados, que tabela, que campo e que cópia de segurança contém cada dado.

Se essa tabela existir, cerca das primeiras trinta das setenta e duas horas ficam efetivamente recuperadas. Se não existir, por bem redigido que esteja o plano, o tempo não vai chegar.