Quando algo corre mal, restaura-se.
Quando se perdem dados, recuperam-se.
Quando os sistemas falham, reverte-se para uma versão anterior.
Os backups são essenciais.
Mas, após um ciberincidente, respondem à pergunta errada.
A verdadeira pergunta não é «Conseguimos restaurar os dados?»
É esta:
«Conseguimos provar que os dados continuam a ser verdadeiros?»
Recuperar não é o mesmo que verificar
Após um incidente, as organizações apressam-se a repor os sistemas em funcionamento.
Os backups cumprem a sua função: os ficheiros reaparecem, as bases de dados são restauradas, os serviços são retomados.
Mas falta algo crítico.
Um backup pode dizer-lhe:
• que dados existiam num determinado momento,
• que versão foi restaurada,
• quando ocorreu a restauração.
Não lhe pode dizer:
• se os dados já estavam comprometidos antes do backup,
• se os registos foram alterados silenciosamente,
• se a informação é fiável como prova.
A recuperação dá-lhe continuidade.
A verificação dá-lhe credibilidade.
O pressuposto perigoso por detrás dos backups
A maioria das organizações funciona com base num pressuposto implícito:
«Se veio de um backup, tem de estar correto.»
Após um incidente, esse pressuposto passa a ser um risco.
Os atacantes nem sempre apagam os dados.
Alteram-nos. De forma subtil. Seletiva. Silenciosa.
Um único campo alterado.
Um carimbo temporal modificado.
Uma cláusula alterada num documento.
Os backups preservam fielmente tudo isso - incluindo o comprometimento.
Do ponto de vista técnico, tudo parece estar bem. Do ponto de vista jurídico, regulatório ou de auditoria, tudo é questionável.
Os auditores não pedem backups. Pedem provas.
Quando auditores, reguladores ou equipas jurídicas intervêm, o êxito da recuperação não lhes interessa.
Fazem outras perguntas:
• Como sabe que este registo não foi alterado?
• Consegue provar que este documento existia exatamente nesta forma naquele momento?
• Que elementos de prova tem de que estes dados são autênticos?
«Porque o restaurámos a partir de um backup» não é uma resposta. É um pressuposto - e os pressupostos não resistem a um escrutínio.
Sem prova verificável:
• as auditorias abrandam ou falham,
• os relatórios de conformidade são contestados,
• as posições jurídicas enfraquecem,
• as decisões atrasam-se.
O problema não é o armazenamento. É a confiança.
A maioria das estratégias de segurança assenta na proteção do armazenamento:
• cifrar a base de dados,
• reforçar o controlo de acessos,
• replicar os dados,
• fazer backup.
Tudo necessário. Nada suficiente.
A confiança não vem do local onde os dados estão armazenados.
Vem de ser possível verificar a sua integridade de forma independente.
Após um incidente, a confiança tem de ser conquistada - não presumida.
E a confiança que depende apenas de sistemas internos é frágil, sobretudo quando esses sistemas acabaram de ser comprometidos.
A prova tem de existir fora do raio de impacto
Se as únicas provas de que dispõe estão nos mesmos sistemas que foram atacados, não tem provas - tem incerteza.
Uma prova real tem três propriedades:
• Imutável: não pode ser alterada retroativamente
• Com carimbo temporal: prova quando algo existiu
• Independente: sobrevive mesmo que os sistemas internos falhem
Sem estas propriedades, os dados podem ser recuperáveis - mas não são defensáveis.
Os backups são necessários. Não são suficientes.
Isto não é um argumento contra os backups.
É um argumento contra confiar neles para algo para que nunca foram concebidos.
Os backups dizem respeito à disponibilidade.
A prova diz respeito à integridade.
Continuidade sem credibilidade é frágil.
E, em ambientes regulados onde muito está em jogo, a fragilidade é um risco que as organizações não podem correr.
No próximo artigo, vamos explorar o que significa, na prática, provar a integridade dos dados desde a conceção - e porque é que a verificação tem de começar no momento da criação, e não após um incidente.
Porque, após uma violação de segurança, a questão já não é se recuperou os dados - é se alguém pode confiar neles.