Precisa-se de um FDR!

A investigação de qualquer incidente de segurança torna-se muito mais fácil quando temos disponível o histórico de atividades realizadas no ambiente investigado. Esse histórico de atividades é o que chamamos simplesmente de logs ou, em bom português, registros de eventos. Esses registros, gerados por sistemas operacionais ou mesmo por aplicações, podem apontar diversas situações como:

Inicialização correta/incorreta de um serviço;

Data e hora da entrada e saída de um usuário em um determinado sistema, bem como as ações que executou;

Comandos executados pelo administrador do sistema;

Tentativas de autenticação sem sucesso; etc.

É de extrema importância que esses registros tenham as seguintes características:

Contenham informação relevante;

A data e hora de cada registro sejam precisas; e

Sejam confiáveis, ou melhor, contenham informação íntegra, verdadeira, que não tenha sido alterada de forma indevida.

Considerando as características colocadas temos algumas dificuldades a serem enfrentadas. A primeira é relativa à relevância da informação: os eventos que serão registrados e em que nível de detalhamento são parâmetros altamente customizáveis em sistemas operacionais e mesmo em aplicações. A definição do que é evento relevante certamenta irá variar de instituição para instituição. Esse fator é certamente um complicador quando temos que realizar o cruzamento de registros de diferentes instituições para traçar o caminho de um ataque.

A segunda dificuldade, que não é tão difícil assim de ser resolvida, é garantir a precisão da data e hora de cada registro. Tipicamente resolve-se isso sincronizando-se automaticamente os relógios dos servidores com um servidor de data/hora (protocolo NTP), seja este interno ou externo. Registros com data ou hora errados podem se tornar inúteis ou mesmo confundir um investigador.

Temos ainda que garantir que os registros sejam confiáveis, isso é de extrema importância. Dependendo do local onde os registros são mantidos um atacante, um usuário ou mesmo um administrador pode alterá-los. O que torna a situação mais crítica é que é sim possível alterar registros de forma que a mesma não seja percebida. Portanto, deve-se evitar a todo custo a possibilidade de alteração dessas informações com ações preventivas.

Precisa-se de um FDR! FDR é a sigla para Flight Data Recorder, uma das famosas caixas pretas que são instaladas em um avião. Ela registra informações relevantes sobre o estado dos instrumentos, ações dos pilotos e condições do vôo. Desse modo, quando se fizer necessário, os orgãos competentes e independentes podem realizar uma auditoria e apurar as causas de um determinado evento. Note que a definição do que é informação relevante é padronizada pelos orgãos competentes e que o piloto, mesmo tendo ele o controle total da aeronave, não tem a possibilidade comprometer a integridade dos registros mantidos na caixa preta.

Comparemos agora uma instituição ao avião. O objetivo da instituição (avião) é realizar suas operações de negócio (vôo) atendendo da melhor forma possível seus clientes (passageiros). Para tal, considerando apenas aspectos de infra-estrutura de TI, a instituição emprega recursos como servidores e aplicativos (instrumentos) para gerir e executar o seu negócio. Para gerir essa infra-estrutura um administrador (piloto) ou um grupo de administradores (acrescente aí o co-piloto) é definido. Porém, quebrando a nossa "perfeita" analogia:

Raramente temos o conceito de caixa preta para registro de atividades;Não há padronização do que é ou não relevante; eAuditoria nem sempre é realizada por pessoal independente.

As situações que geralmente observamos nas implementações de registros de atividades são:

Registros mantidos nos próprios servidores: é como se no avião a caixa preta não tivesse proteção alguma para resistir a um impacto, ou seja, num caso em que a segurança de um servidor seja sériamente comprometida provavelmente não teríamos registro algum a ser auditado;

Os administradores têm acesso irrestrito aos registros: é como se o piloto do avião tivesse o poder de fazer o que bem entendesse com os registros. É importante frisar que não quero compreender aqui apenas a situação em que teríamos um administrador cuja ética seja discutível mas, também, a situação em que o atacante obtém os privilégios de acesso de um administrador;

Registros são ignorados: registrar porém não verificar os registros é desperdício claro de recursos e da chance de se antecipar a problemas. Na maioria das vezes é possível detectar o início de um potencial incidente através dos registros antes que resulte em algum comprometimento grave de segurança; e

Auditorias realizadas por administradores: é como permitir que o piloto realize ele mesmo a auditoria das suas próprias ações em alguns casos. A auditoria deve ser realizada por pessoal independente evitando que informações sejam omitidas ou mesmo alteradas indevidamente. É claro que não estou afirmando aqui que os administradores não são passíveis de confiança, na maioria dos casos é exatamente o contrário, porém ser auditado por pessoal independente dá até maior credibilidade para o próprio administrador.

O ideal portanto é termos um registro de eventos que siga o conceito da caixa preta dos aviões, centralizando as informações e protegendo-as da melhor forma possível para garantir sua precisão e, conseqüêntemente, sua utilidade na investigação de um incidente.