Resposta atrasada

Ao rever meu camarada Wagner Elias no H2HC, lembrei que ficamos de papear a respeito de um procedimento em alto nível para suspeita de vazamento de dados por comprometimento de um servidor. O tempo estava escasso, muitas viagens acontecendo e o papo acabou não acontecendo.
Ao revê-lo, decidi abordar o assunto neste post aqui.

Basicamente, algumas leis americanas estão requerendo que seja determinada a extensão de um ataque, ao ponto de poder provar que os dados dos clientes não foram comprometidos. Caso a empresa não consiga apresentar provas de que nada foi comprometido, ela está obrigada a reportar a perda publicamente. Outras determinações nesse sentido estão por conta do PCI DSS, um conjunto de requisitos de Segurança de Informações para quem opera com cartões de crédito. Um dos requisitos seria a existência de um procedimento para a equipe de resposta a incidentes que deixasse explícito como agir em caso de suspeita de ataque. O procedimento seria complementar a resposta do incidente, indicando os passos necessários para determinar se houve ou não vazamento de informações privadas, principalmente as info relacionadas a número de cartão de crédito.

Não vou detalhar o procedimento aqui no post, mas a linha seria seguir:

1. Logs de rede relativos a infraestrutura e segurança (logs do firewall, logs dos roteadores, logs de acesso do servidor de dados).

2. Captura de pacotes de rede nas máquinas suspeitas de estarem comprometidas.

3. Imagem da memória das máquinas comprometidas.

4. Imagem forense das máquinas comprometidas.

Os dados dos quatro itens acima, devidamente correlacionados, poderão indicar se houve ou não o comprometimento dos dados. Pelo item 1 é possível verificar aquilo que foi negado ou permitido nas operações, e que podem ter culminado no comprometimento do servidor. Por exemplo, se os dados estão armazenados no servidor de banco de dados, os logs da trilha de auditoria deverão dar indicações do acesso e/ou modificação dos dados.

Como já foi comentado, o servidor com possibilidade de comprometimento não deve ser imediatamente desligado. Antes, deve-se espelhar sua porta no switch para um sniffer que colha informações e pacotes de todas as comunicações para esse servidor. O resultado, geralmente um arquivo pcap, deve ser analisado em busca de palavras chave nos pacotes.

Com o item 3 e 4 conseguimos, a luz de outros procedimentos, definir o que estava na memória e no disco que pudesse implicar ou indicar perda dos dados.

Alguém quer acrescentar algo ?

Até o próximo post !