Tratamento de Incidentes de Segurança

A RNP – Rede Nacional de Ensino
e Pesquisa – é qualificada como

uma Organização Social (OS),
sendo ligada ao Ministério da
Ciência, Tecnologia e Inovação
(MCTI) e responsável pelo
Programa Interministerial RNP,
que conta com a participação dos
ministérios da Educação (MEC), da
Saúde (MS) e da Cultura (MinC).
O livro oferece formação prática e aprendizado teórico Pioneira no acesso à Internet no
LIVRO DE APOIO AO CURSO

Brasil, a RNP planeja e mantém a
Tratamento de
para profissionais ligados à área de segurança da infor-
Tratamento de Incidentes de Segurança

mação e de TIC que necessitem desenvolver competên- rede Ipê, a rede óptica nacional
cias e habilidades para iniciarem a área de Tratamento acadêmica de alto desempenho.
Incidentes de
de Incidentes, implementarem e estabelecerem uma Com Pontos de Presença nas
Equipe de Tratamento e Resposta a Incidentes em Redes 27 unidades da federação, a rede
Computacionais – ETIR. Ao final do curso, o alunos esta- tem mais de 800 instituições
rá apto a criar e gerenciar uma equipe de respostas a inci- conectadas. São aproximadamente
Segurança
dentes de segurança, como também, a utilizar as técnicas e 3,5 milhões de usuários usufruindo
ferramentas para tratamento de incidentes. de uma infraestrutura de redes
Este livro inclui os roteiros de atividades práticas e o con- avançadas para comunicação,
teúdo dos slides apresentados em sala de aula, apoiando computação e experimentação,
profissionais na disseminação deste conhecimento em que contribui para a integração
suas organizações ou localidades de origem. entre o sistema de Ciência e
Tecnologia, Educação Superior,
Saúde e Cultura.
ISBN 978-85-63630-46-9
9 788563 630469
SEG4.capa-NPE-v2.0.3.indd 1 04/12/2017 11:22:14

Sobre a RNP – qualificada como uma
Organização Social (OS), a Rede Nacional
de Ensino e Pesquisa (RNP) é vinculada
ao Ministério da Ciência, Tecnologia,
Inovação e Comunicações (MCTIC) e
mantida por esse, em conjunto com
os ministérios da Educação (MEC),
Cidadania, Saúde (MS) e Defesa
(MD), que participam do Programa
Interministerial RNP (PI-RNP). Pioneira
no acesso à internet no Brasil, a RNP
planeja, opera e mantém a rede Ipê,
infraestrutura óptica nacional acadêmica
de alto desempenho. Com Pontos de
Presença em 27 unidades da federação,
a rede conecta 1.174 campi e unidades
nas capitais e no interior. São mais de
4 milhões de usuários, usufruindo de
uma infraestrutura de redes avançadas
para comunicação, computação e
experimentação, que contribui para a
integração dos sistemas de Ciência e
Tecnologia, Educação Superior, Saúde,
Cultura e Defesa.
Saiba mais em https://rnp.br.
Tratamento de
Incidentes de
Segurança
Tratamento de
Incidentes de
Segurança
Rio de Janeiro
Escola Superior de Redes
2017
Copyright © 2017 – Rede Nacional de Ensino e Pesquisa – RNP
Rua Lauro Müller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simões
Diretor de Serviços e Soluções

José Luiz Ribeiro Filho

Diretor Adjunto
Leandro Marcos de Oliveira Guimarães
Coordenação Acadêmica de Segurança e Governança de TI

Edson Kowask
Edição
Lincoln da Mata
Revisão técnica
Jácomo Picolini
Equipe ESR (em ordem alfabética)

Adriana Pierro, Camila Gomes, Celia Maciel, Edson Kowask, Elimária Barbosa,
Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato,
Márcia Correa, Márcia Helena Rodrigues, Monique Souza, Renato Duarte, Thays Farias
e Yve Marcial.
Capa, projeto visual e diagramação

Tecnodesign
Versão
2.0.3
Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de
conteúdo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Distribuição
Rua Lauro Müller, 116 – sala 1103
22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
info@esr.rnp.br
Dados Internacionais de Catalogação na Publicação (CIP)
C416t Ceron, M. João

Tratamento de Incidentes de Segurança /João Marcelo Ceron. – Rio de Janeiro:
RNP/ESR, 2014
168 p. : il. ; 27,5 cm.
ISBN 978-85-63630-46-9
1. Segurança de computador. 2. Internet – medidas de segurança. 3. Centro de estudos,

Resposta e Tratamento de Incidentes de Segurança no Brasil (CERT). 4. Grupo de Resposta a
Incidentes de Segurança (CSIRT). I. Título..
CDD 005.8
Sumário
A metodologia da ESR ix
Sobre o curso x
A quem se destina x
Convenções utilizadas neste livro x
Permissões de uso xi
Sobre o autor xii
1. Definições e fundamentos de CSIRTs

Introdução 1
Contextualização histórica 2
Identificando CSIRTs pelo mundo 3
Definição de CSIRT 3
Exercício de fixação 1 Conhecendo CSIRTs 4
Abrangência operacional e missão do CSIRT 5
Serviços de CSIRTs 6
Aspectos operacionais de um CSIRT 10
Tipos 10
Modelos 10
Autonomia 11
Definição de incidente 11
Passos para criação de um CSIRT 12
Fóruns de CSIRTS 13
iii
2. Gerenciamento do CSIRT
Introdução 15
Código de conduta 15
Equipe 17
Treinamento e desenvolvimento da equipe 20
Terceirização de serviços 20
Contratação 21
Procedimentos de ingresso e desligamento 23
Requisitos estruturais 24
Comunicação 27
Fatores de sucesso 29
3. Riscos e ameaças
Introdução 33
Análise de risco 33
Ameaças associadas a segurança de sistemas 36
Comprometimento de sistemas 37
Phishing 38
Desfiguração 39
Ataques de força bruta 39
Varredura em redes (Scan) 40
Negação de serviço (DoS e DDoS) 40
Malwares 42
Outros riscos 45
APT 46
4. Processo de tratamento de incidentes

Introdução 49
Metodologia para resposta a incidentes 50
Preparação 51
Contenção 56
Erradicação 58
Recuperação 58
Avaliação 60
Recursos adicionais 60
Roteiro para avaliação inicial de um incidente 61
Procedimentos 62
iv
5. Aspectos operacionais da resposta a incidentes
Introdução 65
Aspectos operacionais da resposta a incidente 65
Identificação 66
Exercício de fixação 1 Análise de cabeçalho de e-mail 70
Exercício de fixação 2 Utilizando o protocolo SMTP 71
Sincronismo de tempo 73
Exercício de fixação 3 Padronização do formato data e hora 75
Priorização 76
Categorização 77
Exercício de fixação 4 Classificação e triagem de incidentes 78
Atribuição 79
Boas práticas para a notificação de incidentes de segurança 85
6. Identificação de contatos
Introdução 87
Identificação de contatos 88
Traduzir domínios de redes para endereços IP (domínio > IP) 88
Traduzir o endereço IP para domínios de redes (IP > domínio) 88
Exercício de fixação 1 94
Exercício de fixação 2 96
Recursos adicionais 97
Exercício de fixação 3 utilizando a ferramenta DIG 100
Exercício de fixação 4 Sistemas Autônomos 102
7. Análise de Logs
Introdução 107
Mensagens de logs 108
Sistemas de logs 111
Gerenciamento de logs 115
Análise de logs 116
Filtragem 119
Normalização 121
Correlação 122
v
Ferramentas para o processamento de logs 123
Aspectos de segurança 125
Recomendações para sistemas de logs 126
8. Ferramentas para análise de incidentes

Introdução 129
Preocupações de privacidade 130
Proxies 132
Web-Proxies 133
Virtual Private Network (VPN) 134
Rede Tor 135
Uso da rede Tor na investigação de incidentes 136
Mecanismos de busca 137
Analisadores de malwares 137
Assinaturas de malwares 138
Ferramentas multiantivírus 139
Exercício de fixação 1 Virustotal 141
Análise comportamental 141
Exercício de fixação 2 Análise dinâmica de arquivos maliciosos 146
Considerações sobre o uso de ferramentas online 146
Analisadores de websites 147
Outros serviços online 149
Listas de bloqueio 149
Exercício de fixação 3 Pesquisando por sites relacionados com fraudes 150
Repositório de websites desfigurados 150
Exercício de fixação 4 Identificar servidores que já foram comprometidos utilizando

a base de dados do zone-h 151
Demais ferramentas para analisar artefatos 152
9. Dinâmica de tratamento de incidentes

Introdução 153
Contextualização 153
SIFRA 155
Tratamento de incidentes de segurança 156
vi
A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP)
responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunica-
ção (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências
em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e
unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do
corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicá-
veis ao uso eficaz e eficiente das TIC.
A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto
de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e
Governança de TI.
A ESR também participa de diversos projetos de interesse público, como a elaboração e

execução de planos de capacitação para formação de multiplicadores para projetos edu-
cacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil
(UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de
cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na
aprendizagem como construção do conhecimento por meio da resolução de problemas típi-
cos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza
teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não
apenas como expositor de conceitos e informações, mas principalmente como orientador do
aluno na execução de atividades contextualizadas nas situações do cotidiano profissional.
A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema

semelhantes às encontradas na prática profissional, que são superadas por meio de análise,
síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do pro-
blema, em abordagem orientada ao desenvolvimento de competências.
Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as
atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de apren-
dizagem não é considerada uma simples exposição de conceitos e informações. O instrutor
busca incentivar a participação dos alunos continuamente.
vii
As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das
atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de
estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atua-
ção do futuro especialista que se pretende formar.
As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo

para as atividades práticas, conforme descrição a seguir:
Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos).

O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema
da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta
questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma
à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se
coloque em posição de passividade, o que reduziria a aprendizagem.
Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos).

Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e
realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no
livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e oferecer
explicações complementares.
Terceira etapa: discussão das atividades realizadas (30 minutos).

O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la,
devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a
comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas,
estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem
soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.
Sobre o curso
O curso apresenta os conceitos fundamentais e descreve as fases de tratamento de inciden-
tes de segurança com exercícios práticos e simulações de casos. O curso apresenta ainda as
atividades necessárias para que seja estabelecida uma Equipe de Tratamento e Resposta a
Incidentes em Redes Computacionais – ETIR, suas responsabilidades, seu modelo de atuação
e estrutura. Ao final do curso o aluno estará preparado para iniciar a criação de um grupo de
atendimento a incidentes de segurança (Computer Security Incident Response Team - CSIRT)
e com conhecimento necessário para realizar o tratamento de incidentes na sua organização.
A quem se destina
O curso destina-se aos gestores e profissionais da área de segurança da informação e de TIC
que necessitam adquirir e desenvolver competências e habilidades para iniciarem a área de
Tratamento de Incidentes, implementarem e estabelecerem uma Equipe de Tratamento e
Resposta a Incidentes em Redes Computacionais – ETIR de acordo com a norma complementar
do DSIC e as boas práticas de mercado. Também poderão se beneficiar outros profissionais
desejam adquirir o conhecimento sobre ETIR e tratamento de incidentes.
Convenções utilizadas neste livro

As seguintes convenções tipográficas são usadas neste livro:
Itálico
Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.
viii
Largura constante
Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída
de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem
o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).
Conteúdo de slide q
Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.
Símbolo w
Indica referência complementar disponível em site ou página na internet.
Símbolo d
Indica um documento como referência complementar.
Símbolo v
Indica um vídeo como referência complementar.
Símbolo s
Indica um arquivo de aúdio como referência complementar.
Símbolo !
Indica um aviso ou precaução a ser considerada.
Símbolo p
Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao
entendimento do tema em questão.
Símbolo l
Indica notas e informações complementares como dicas, sugestões de leitura adicional ou
mesmo uma observação.
Permissões de uso
Todos os direitos reservados à RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citação: TORRES, Pedro et al. Administração de Sistemas Linux: Redes e Segurança.
Rio de Janeiro: Escola Superior de Redes, RNP, 2013.
Comentários e perguntas
Para enviar comentários e perguntas sobre esta publicação:
Escola Superior de Redes RNP
Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo
Rio de Janeiro – RJ – 22290-906
E-mail: info@esr.rnp.br
ix
Sobre o autor
Jácomo Picolini é formado em Engenharia pela Universidade Federal de São Carlos, com
pós-graduações no Instituto de Computação e Instituto de Economia da UNICAMP, possui
17 anos de experiência na área de segurança, trabalhou no CAIS/RNP até 2009 e depois
como Coordenador Acadêmico da área de Segurança e Governança de TI ESR/RNP até
2011, Diretor no Dragon Research Group, membro da diretoria do capítulo da ISACA de
Brasília 2011-2014, membro da Comissão de Direito Eletrônico e Crimes de Alta Tecnologia
da OAB SP, liasion do FIRST.org onde coordena as atividades de treinamento, professor
convidado em cursos de pós-graduação nas disciplinas de análise forense, tratamento de
incidentes, segurança de sistemas, criação e gerenciamento de CSIRTs. Atualmente trabalha
na empresa Team Cymru NFP e faz parte da equipe que provê informações para tornar a
Internet mais segura.
Edson Kowask Bezerra é profissional da área de segurança da informação e governança

há mais de quinze anos, atuando como auditor líder, pesquisador, gerente de projeto e
gerente técnico, em inúmeros projetos de gestão de riscos, gestão de segurança da informa-
ção, continuidade de negócios, PCI, auditoria e recuperação de desastres em empresas de
grande porte do setor de telecomunicações, financeiro, energia, indústria e governo. Com
vasta experiência nos temas de segurança e governança, tem atuado também como pales-
trante nos principais eventos do Brasil e ainda como instrutor de treinamentos focados em
segurança e governança. É professor e coordenador de cursos de pós-graduação na área de
segurança da informação, gestão integrada, de inovação e tecnologias web. Hoje atua como
Coordenador Acadêmico de Segurança e Governança de TI da Escola Superior de Redes.
x
1
Definições e fundamentos
de CSIRTs
objetivos
Aprender conceitos e termos relacionados com CSIRTs; Descrever os principais

aspectos operacionais de um CSIRT; Iniciar o processo de criação de um CSIRT.
conceitos
O CSIRT; Definições importantes na criação de Grupo de Resposta a Incidentes de
Segurança; Conceito de “incidente de segurança”.
Introdução
O contínuo crescimento e a popularização da internet estão sendo acompanhados pelo q
aumento de novas ameaças de segurança dos sistemas computacionais. Com o passar
do tempo, entretanto, as ameaças e ataques aos sistemas computacionais têm aumen-
tado consideravelmente. Esse aumento é decorrente de inúmeros fatores, entre os quais
o aumento no número de usuários, o aumento no número de transações financeiras e,
sobretudo, o aumento do grau de dependência tecnológica da sociedade.
Boa parte dos serviços está amplamente acessível na rede, de modo a prover suas funciona-
lidades aos seus usuários. Consequentemente, esses sistemas também se tornam expostos
aos diferentes tipos de ameaças. Tais ameaças incluem atividades de usuários, softwares
maliciosos e vulnerabilidades associadas aos serviços utilizados. Diante disso, torna-se
essencial implementar mecanismos para lidar com eventos de segurança antes mesmo Capítulo 1 - Definições e fundamentos
de CSIRTs
que danos significativos sejam causados às instituições. Além do mais, é necessário que os
procedimentos tradicionais para proteção de sistemas sejam constantemente aprimorados
de modo a contemplar as novas ameaças e ataques emergentes na internet.
Esse contexto fomentou o surgimento de equipes especializadas em lidar com incidentes q

de segurança. Dessa forma, a equipe pode desenvolver metodologias para proteger os
sistemas e, na ocorrência de um avento arbitrário de segurança, esse grupo de pessoas
pode prontamente interceder de forma efetiva.
1
Contextualização histórica
Atualmente observam-se muitos times de segurança constituídos em diferentes insti- q
tuições. Nos primórdios da internet, o número de incidentes de segurança era bastante
reduzido e de baixa complexidade. No entanto, com o passar do tempo, os incidentes
de segurança obtiveram novas proporções, sobretudo após o incidente de segurança
denominado de Internet Worm. Internet Worm:
Em 1988, o incidente
Esse incidente fomentou a discussão na comunidade de segurança pela necessidade de Internet Worm deixou
melhores meios para identificar e responder incidentes de computadores na internet de milhares de compu-
forma efetiva. tadores inoperantes.
Estima-se que seis
Como resultado, um conjunto de recomendações foi especificado tendo como mil sistemas foram
afetados, o que repre-
principal demanda: sentava aproximada-
mente 10% da internet
11 Criar um único ponto de contato na rede para comunicar problemas de segurança; operante na época.
11 Atuar de forma confiável com informações de segurança.
Em resposta a essas recomendações, foi institucionalizado o primeiro grupo de resposta a

incidentes, conhecido como CERT Coordination Center (CERT/CC), localizado na universidade
de Carnegie Mellon, nos Estados Unidos.
Na Europa, o mesmo modelo foi adotado, e em 1992 o provedor acadêmico holandês SURFnet
fundou o primeiro time europeu, o qual foi denominado SURFnet-CERT. Consequentemente,
outros times foram implementados em diferentes intuições e em diversos países.
No Brasil não foi diferente. Embora a primeira conexão da internet tenha sido oficialmente
inaugurada em 1989, a internet realmente ganhou corpo em 1995, quando foi liberada a
operação da internet comercial no Brasil. No mesmo ano, o Comitê Gestor da Internet no
Brasil (CGI.br) foi criado com a responsabilidade de coordenar e integrar todas as iniciativas
de serviços internet no país, promovendo a qualidade técnica, a inovação e a disseminação
dos serviços ofertados.
Entre as diversas iniciativas do CGI.br, a publicação do documento Rumo à Criação de uma

Coordenadoria de Segurança de Redes na Internet Brasil em agosto de 1996 foi um marco para
a segurança da internet brasileira.
Nesse documento, são discutidos aspectos de segurança nacional e a importância dos

CSIRTs para a segurança da rede. Entre as recomendações, sugeriu-se a criação de um
centro nacional de coordenação de segurança de redes.
Com base nas recomendações do CGI.br, em junho de 1997 foi estabelecido o primeiro
grupo de responsabilidade nacional, denominado NIC BR Security Office (NBSO), que poste-
riormente seria renomeado para CERT.br.
No mesmo ano, outros times de diferentes instituições brasileiras foram formalizados:
11 1997:
22 Fundação do CAIS: CSIRT da própria Rede Nacional de Ensino e Pesquisa (RNP);
22 Fundação do NBSO (Cert.br);
22 Fundação do CERT-RS: CSIRT da rede acadêmica do Rio Grande do Sul.
11 1999:
22 Fundação do GRA: CSIRT do SERPRO (Serviço Federal de Processamento de Dados);
22 Fundação de diversos CSIRTs em universidades e operadores de telecomunicações.
2
11 2004:
22 Fundação do CTIR Gov: CSIRT voltado para a administração pública federal.
11 2010:
22 Fundação do CDCiber: CSIRT responsável pelo setor cibernético no exército.
No Brasil, atualmente, podemos encontrar diversos grupos estabelecidos em diferentes

estados. No website do CERT.br são ilustrados alguns times estabelecidos e respectivas
informações de contato.
11 http://www.first.org/members/teams
11 http://www.rnp.br/cais/csirts.html
11 http://www.cert.br/contato-br.html
11 http://www.cert.org/csirts/national/contact.html
11 http://www.apcert.org/about/structure/members.html
11 http://www.cert.org/csirts/csirt-map.html
Identificando CSIRTs pelo mundo

Os websites a seguir podem ser utilizados para localizar CSIRTs e suas respectivas abrangências
operacionais nos mais diversos países.
Definição de CSIRT
Um Computer Security Incident Response Team (CSIRT) ou um Computer Security Inci- q
dent Response Team (CSIRT) – em português, Grupo de Resposta a Incidentes de Segu-
rança – é uma organização que responde a incidentes de segurança provendo suporte
necessário para resolver ou auxiliar na resolução.
O CSIRT normalmente presta serviços para uma comunidade bem definida, que pode ser a
entidade que o mantém, tal como empresa, órgão governamental ou organização acadêmica.
Independentemente de sua atuação, é fundamental que um CSIRT tenha a habilidade de ana-
lisar e prover rapidamente meios efetivos para tratar um incidente. A rápida identificação e
a efetiva análise de um incidente de segurança podem diminuir possíveis danos e, em última
análise, diminuir os eventuais custos de uma recuperação. Como consequência, a análise de
incidentes permite a implementação de medidas preventivas evitando que eventos similares
aconteçam novamente.
Capítulo 1 - Definições e fundamentos
de CSIRTs
Existe uma sutil diferença entre um CSIRT e uma equipe de segurança departamental. q
Uma equipe de segurança departamental desenvolve ações habituais relativas à moni-
toração de redes e sistemas, como por exemplo: atualização de sistemas; configuração
de filtro de pacotes; análise de logs; gerenciamento de redes e outras tarefas. Já um
CSIRT atua com foco na resposta de incidentes, implementando um ponto central para
notificação, análise e coordenação de incidentes na organização. De forma comple-
mentar, um CISRT pode complementar suas atividades incorporando tarefas de uma
equipe de segurança departamental; entretanto, seu foco deve estar no tratamento de
incidentes de segurança.
Organizações que implementam CSIRTs valem-se dos seguintes benefícios:
11 Existência de mecanismos de resposta a incidentes de segurança;
11 Instituição preparada para as ameaças emergentes;
3
11 Aumento do grau de segurança, ao desenvolver uma cultura de segurança; q
11 Criação de mecanismos que visam à preservação da instituição;
11 Introdução de senso crítico em relação à visão tradicional de TI.
É comum questionar-se em relação à denominação de grupos a resposta a incidentes. Além

l
A sigla CERT (Computer
de CSIRT, outras siglas são rotineiramente empregadas para designar grupos de resposta a Emergency Response
incidentes de segurança. Talvez as siglas mais utilizadas sejam: CERT e ETIR. Team) é uma marca
patenteada e somente
A identidade de um grupo começa pela definição do seu nome. pode ser usada
mediante prévia
O nome e a sigla permitem ao seu CSIRT criar uma identidade própria, que deve estar autorização. Já a sigla
ETIR representa Equipe
alinhada com a de sua instituição e, se possível, refletir o setor que representa (banco,
de Tratamento e
indústria, governo etc.). Resposta a Incidentes
em redes de computa-
A seguir uma listagem de siglas e nomes de alguns times: dores, o que corres-
ponde a uma tradução
11 CERT/CC: Computer Emergency Response Team/Coordination Center; livre do termo CSIRT.
11 CAIS/RNP: Centro de Atendimento a Incidentes de Segurança da Rede Nacional de Ensino

e Pesquisa;
11 CENATIS: Centro de Atendimento e Tratamento de Incidentes de Segurança da

Universidade Federal do Rio de Janeiro (UFRJ);
11 CERT.BR: Centro de Estudo, Resposta e Tratamento de Incidentes de Segurança no Brasil;
d
11 NARIS: Núcleo de Atendimento e Resposta a Incidentes de Segurança da Universidade
Federal do Rio Grande do Norte (UFRN);
Leitura recomendada
11 GRIS-CD: Grupo de Resposta a Incidentes de Segurança da Câmara dos Deputados; – definição de CSIRTs
segundo o CERT/CC:
11 TRI: Time de Resposta a Incidentes da Universidade Federal do Rio Grande do Sul (UFRGS); http://www.cert.org/
csirts/csirt_faq.html e
11 CERT-RS: Centro de Emergências em Segurança da Rede Tchê;
http://www.cert.br/
11 USP/CSIRT: Centro de Resposta a Incidentes de Segurança da Universidade de certcc/csirts/csirt_
faq-br.html e Departa-
São Paulo (USP);
mento de Segurança da
11 GRA/SERPRO: Grupo de Resposta a Ataques do Serviço Federal de Processamento de Informação e Comuni-
cações: http://dsic.
Dados (SERPRO).
planalto.gov.br/
Exercício de fixação 1 e
Conhecendo CSIRTs
Através de uma consulta na internet, localize dois exemplos de grupos de resposta a
incidentes de segurança nas áreas listadas a seguir. Escreva a sigla, o nome do grupo e a
comunidade de atuação.
CSIRT governamental:
1.
2.
4
CSIRT de instituição financeira:
1.
2.
CSIRT comercial:
1.
2.
CSIRT acadêmico:
1.
2.
Abrangência operacional e missão do CSIRT

A abrangência operacional, também conhecida por constituency, define a comunidade q
atendida pelos serviços do CSIRT. A abrangência operacional de um CSIRT pode ser
composta por diversos domínios administrativos, diferentes redes, ou ainda por um
conjunto específico de domínios. Por exemplo: “O CSIRT exemplo atende domínios e
endereços IP alocados para o AS XXXX”; ou ainda, de forma mais flexível: “Redes, ende-
reços IP e domínios atendidos pela instituição”.
Com a definição da abrangência operacional torna-se possível mapear as necessidades

de CSIRTs
e anseios da comunidade utilizadora, o que possibilita, em um contexto mais amplo,
definir a missão do CSIRT.
A missão de um CSIRT deve fornecer uma breve descrição das metas e objetivos da
equipe. A definição da missão é que permite determinar o conjunto de atividades a
serem desenvolvidas pela equipe no contexto de sua abrangência operacional.
Recomenda-se que a missão de um CSIRT seja concisa e clara. Afinal, de certa forma, a missão de
um CSIRT permite que entidades externas possam definir expectativas apropriadas em relação
às ações a serem tomadas pela equipe. Alguns exemplos de definições da missão de CSIRT:
11 Missão do CAIS/RNP (http://www.rnp.br/cais/): “O CAIS – Centro de Atendimento a q

Incidentes de Segurança atua na detecção, resolução e prevenção de incidentes de
segurança na rede acadêmica brasileira, além de elaborar, promover e disseminar
práticas de segurança em redes.”
5
11 Missão do CERT.br (http://www.cert.br/missao.html): “O CERT.br, anteriormente q
denominado NBSO/Brazilian CERT, é o Grupo de Resposta a Incidentes de Segurança
para a Internet brasileira, mantido pelo Comitê Gestor da Internet no Brasil. É o grupo
responsável por receber, analisar e responder a incidentes de segurança em compu-
tadores, envolvendo redes conectadas à internet brasileira.”
11 Missão do CTIR.gov (http://www.ctir.gov.br/): “Operar e manter o Centro de Trata-

mento de Incidentes de Segurança de Redes de Computadores da Administração
Pública Federal.”
De fato, a missão posiciona o CSIRT frente à sua comunidade de atuação. Adicionalmente, a l

sua comunidade toma conhecimento dos serviços prestados pelo time de segurança. Sabe- Segundo documen-
se, entretanto, que o relacionamento com a comunidade de atuação deve ir além da simples tação do próprio CERT/
CC, em média, um
definição e divulgação dos serviços prestados pelo time. Nesse contexto de segurança, mais CSIRT leva em torno de
do que nunca, ações falam mais alto do que definições escritas. Um CSIRT leva tempo para um ano após o início
de sua operação para
ter o seu reconhecimento na comunidade de atuação. Fatores como confiança e respeito são
que a comunidade
conquistados naturalmente com bom trabalho realizado. assimile o time e
comece um processo
Por fim, e não menos importante, é assegurar que a missão do CSRIT tenha apoio e suporte regular de notificações.
da camada de gestão da instituição (diretores ou equivalentes). Do contrário, a atuação do
time pode ser seriamente comprometida.
Serviços de CSIRTs
Os serviços de um CSIRT definem um conjunto de atividades que serão providas para q
a sua comunidade de atuação (constituency). Evidentemente, algumas atividades são
intrínsecas ao processo de tratamento de incidentes e, portanto, mandatórias a todos
os CSIRTs: análise de eventos, resposta de incidentes e coordenação para resolução de
incidentes de computadores.
Tipicamente, os CSIRTs tradicionais implementam um conjunto de serviços adicionais que

complementam as atividades relativas ao processo de resposta a incidente, tal como a
elaboração de alertas e anúncios relacionados à segurança. Outros CSIRTs, porém, diversi-
l
O aumento de
ficam a sua base de serviços provendo atividades de auditoria de sistemas, análise de riscos, notificações de
treinamento e análise forense. segurança para um
q
CSIRT é um indício de
Algumas atividades típicas de CSIRTs: acolhimento pela
comunidade de
11 Análise de artefatos maliciosos; abrangência.
11 Análise de vulnerabilidades;
11 Emissão de alertas e advertências;
11 Prospecção ou monitoração de novas tecnologias;

11 Avaliação de segurança;
11 Desenvolvimento de ferramentas de segurança;
11 Detecção de intrusão;
11 Disseminação de informações relacionadas à segurança.
Embora não exista um conjunto padrão de serviços que um CSIRT deva oferecer, é
essencial que cada time de segurança especifique serviços tendo em vista seus recursos
disponíveis, tal como equipe, expertise e infraestrutura necessária.
6
O CERT/CC, por sua vez, disponibiliza um repositório de boas práticas e recomendações que
especificam detalhes dos serviços prestados por um CSIRT.
Segundo a nomenclatura adotada, os serviços de um CSIRT podem ser agrupados em:
11 Serviços reativos;
11 Serviços proativos;
11 Serviços de qualidade.
Os serviços correspondentes a cada categoria são listados na tabela 1.1 e descritos de forma
mais detalhada na sequência.
Reativos Proativos Qualidade
11Análise de Vulnerabili- 11Monitoração da segu- 11Análise de processos e

dades. rança na rede. procedimentos.
11Elaboração de alertas e 11Alertas de ferramentas. 11Gerenciamento da
avisos. 11Avaliação situacional. equipe ou negócios.
Tabela 1.1
11Gerenciamento de 11Detecção de intrusão. 11Plano de recuperação de
Os diversos
vulnerabilidades. desastres.
tipos de serviços 11Desenvolvimento de fer-
prestados por 11Análise de malwares e ramentas de segurança. 11Educação e treinamento.
um CSIRT.
demais artefatos.
Serviços reativos
São serviços instanciados após a identificação de um incidente de segurança. Tais serviços
visam solucionar um incidente de segurança em execução ou prover meios para a investi-
gação de incidentes previamente identificados.
De todo modo, os serviços reativos fazem parte das atividades essenciais implementadas
por CSIRTs no processo de resposta a incidentes de segurança. Os serviços podem ser ins-
tanciados por uma notificação de um incidente – máquina comprometida, por exemplo – um
pedido de ajuda ou, ainda, por ferramentas de detecção do próprio time de segurança.
Serviços proativos
Os serviços proativos têm por objetivo evitar que incidentes de segurança ocorram e,
também, reduzir o impacto quando estes ocorrerem. Para isso, buscam-se desenvolver
ações seguras de maneira a aprimorar a segurança dos sistemas como um todo, buscando
diminuir o potencial de sucesso dos ataques contra a infraestrutura das organizações.
Alguns serviços dessa categoria estão diretamente relacionados a:
de CSIRTs
11 Implementar defesa em camadas e garantir que as melhores práticas de segurança
sejam implementadas nos sistemas computacionais, incluindo a configuração, definição
e implementação;
11 Realizar tarefas de auditoria, avaliação de vulnerabilidades e outras avaliações que visam

identificar fraquezas nos sistemas ou vulnerabilidades antes que estas sejam exploradas;
11 Identificar riscos de novas ameaças e tendências de maneira a identificar como elas

podem afetar a instituição;
11 Atualizar assinaturas de antivírus ou IDS de maneira a conter as novas ameaças identificadas.
7
Serviços de qualidade
São serviços desenvolvidos para aprimorar o processo de resposta a incidentes como um
todo. Para isso, são analisados processos administrativos do CSIRT e também a efetividade
dos serviços prestados. Dessa forma, podem-se identificar limitações no processo e
implementar melhorias para o time, seja elas de caráter técnica (treinamento técnico para a
equipe) ou organizacional (fluxo de informação entre os processos). Essas tarefas incluem:
11 Gerenciamento da equipe ou processos;
11 Educação ou treinamento;
11 Auditoria de sistemas.
Essas diferentes classificações descrevem a natureza dos serviços de um CSIRT e fica a

critério de cada time incorporá-los à sua comunidade. Alguns serviços são essencialmente
internos; outros; no entanto, podem ser demandados pela comunidade de atuação e
também por terceiros. Para isso, deve-se ter claramente documentado as peculiaridades de
cada serviço no que tange: escopo, formas de contato e funcionamento.
Por fim, é importante que os serviços prestados por um CSIRT sejam providos com quali-
dade tendo em foco a sua comunidade de atuação. Para isso, torna-se desejável monitorar a
excelência dos serviços prestados e aprimorá-los com lições aprendidas e contribuições dos
usuários. Do contrário, o CSIRT pode cair em descrédito e a sua comunidade pode parar de
reportar incidentes.
Interação com os serviços

Além de especificar os serviços providos por um CSIRT, é essencial descrever como estes
podem ser instanciados. Desse modo, um CSIRT deve estabelecer diferentes canais de
comunicação para a sua comunidade, permitindo que os serviços disponíveis sejam solici-
tados. Existem diferentes meios de contato.
Talvez o serviço mais utilizado para interação seja o sistema de e-mail. No entanto, devem-se
prever outras formas de interação com a equipe, incluindo até mesmo requisições pessoais
originadas por funcionários da própria empresa in loco.
Quando definir os canais de comunicação, o CSIRT deve considerar questões relativas à

documentação das solicitações. Por exemplo:
11 Como gerenciar um incidente notificado via telefone?
11 Como atualizar a equipe referente ao status de um incidente notificado pessoalmente?
11 Incidentes não documentados farão parte das estatísticas de um CSIRT?

Sabe-se que um CSIRT pode se comunicar com a sua comunidade de diferentes formas.
Na sequência, são descritos os principais canais de comunicação.
8
Formas de disseminar informações e requisitar serviços:
11 Telefone: uma das formas mais simples e diretas de comunicação com a sua comuni-
dade de atuação é via contato telefônico. A conversação telefônica é uma forma direta
de reportar incidentes e lidar com informações que possuem carácter de urgência. No
entanto, ligações telefônicas podem gerar interpretações errôneas, sobretudo em situ-
ações de emergência. Outro ponto negativo do uso do telefone é a interrupção causada
pelas ligações. Em eventos de segurança, é comum que muitas pessoas entrem em
contato com o CSIRT, o que pode atrasar a resolução de um incidente em andamento.
Alguns times optam por não realizar atendimento via telefone, mas disponibilizam um
telefone de urgência – tal como um celular – para efetivamente receber ligações telefô-
nicas de um grupo mais restrito (gerência e equipe técnica);
11 INOC-DBA: O INOC-DBA (Hotline Phone System) é uma infraestrutura VoIP para comu-
nicação direta entre Centros de Operação de Redes (NOCs) e Grupos de Tratamento de
Incidentes de Segurança (CSIRTs). Deseja-se, com isso, que todos os provedores e grandes
redes conectadas na internet sejam facilmente contatados por quaisquer outros prove-
dores do mundo. Para isso, cada participante do INOC-DBA possui um ramal – que corres-
ponde ao número do próprio AS (Sistema Autônomo, na sigla em inglês) – e pode receber
e solicitar ligações de forma gratuita. No Brasil, o Comitê Gestor da Internet no Brasil
participa do projeto fornecendo gratuitamente telefones VoIP para todos os ASes e CSIRTs
reconhecidos. Mais informações: http://www.ceptro.br/CEPTRO/MenuCEPTROSPInocDba;
11 E-mail: a maneira mais utilizada para comunicação entre o CSIRT e a comunidade de

atuação é, sem dúvida, o e-mail. Sabemos das vantagens da comunicação via e-mail:
rapidez, comodidade e fácil identificação do remetente. No contexto do CSIRT, a comuni-
cação via e-mail é essencial. Logo, faz-se necessário que o CSIRT envie e, principalmente,
receba todos os e-mails destinados ao time. Recomenda-se que nenhum tipo de filtro seja
utilizado na caixa de entrada do e-mail, tal como antispam e antivírus (filtro de anexos).
Afinal, a comunidade pode encaminhar um spam para a equipe analisar, e até mesmo
repassar arquivos maliciosos executáveis. De forma complementar, recomenda-se a utili-
zação de e-mails impessoais, ou seja, é importante a instituição ter um e-mail de contato,
como por exemplo “csirt@instituicao”. De forma resumida, as boas práticas recomendam:
22 Utilizar e-mail impessoal;
22 Não usar filtragem na caixa de e-mail (antispam);
22 Cuidado com cotas e limites de e-mails recebidos ou enviados;
22 Divulgar o e-mail institucional no website;
22 Manter o sistema de WHOIS apontado para um e-mail válido;

de CSIRTs
22 Direcionar os múltiplos e-mails (alias) do CSIRT para uma caixa postal única.
11 Boletins: alguns CSIRTs costumam repassar informações de segurança para a sua comu-
nidade por meio de listas de e-mails ou mesmo via boletins impressos.
A divulgação de informações que afetam especialmente a comunidade de abrangência
– como, por exemplo, atualização de sistemas utilizados e dicas de segurança incluindo
configuração segura – é uma maneira efetiva de evitar incidentes de segurança;
11 Website: é uma maneira eficaz de divulgar informações para a comunidade de abrangência.

Além de disseminar uma variedade de informações como boletins e notícias, um website
Defacement: serve para disponibilizar procedimentos e formas de contato do CSIRT. Alguns times também
Ataque que tem como
disponibilizam ferramentas e outros softwares úteis para a comunidade. Embora seja
objetivo alterar sem
autorização o conteúdo praticamente mandatório todo CSIRT ter um website, é importante zelar por sua segurança.
de uma página web. Afinal, um defacement no site de um CSIRT pode causar prejuízos à imagem do time;
9
11 Conferências: participar de conferências ou mesmo promover conferências e seminários
é mais uma forma de comunicar-se com a comunidade de atuação. A apresentação de
trabalhos em conferências também é importante. Ter membros da equipe apresentando
trabalhos em eventos pode aumentar a reputação do time e ajudar no processo de divul-
gação de informações para a comunidade;
11 Cursos: a realização de cursos para a comunidade com foco em segurança é uma prática
adotada por alguns times. A realização de cursos na própria instituição também serve para
intensificar e disseminar a própria política de segurança da instituição.
É importante lembrar que a comunicação entre um CSIRT e as demais partes envolvidas tipi-
camente envolvem informações sigilosas. Questões relativas à segurança das informações –
tráfego de dados e armazenamento das informações – devem ser consideradas pela equipe
no momento em que um novo canal de comunicação é instaurado.
Aspectos operacionais de um CSIRT

Os aspectos operacionais de um CSIRT definem especificamente qual será a forma de
atuação da equipe tanto no âmbito operacional quanto no organizacional.
As particularidades de cada CSIRT têm influência direta na estrutura e operação da equipe.

Por exemplo, aspectos como a comunidade atendida, natureza das informações e modelo
gerencial da equipe definirão a forma como os incidentes serão tratados internamente.
Na sequência, são discutidos os principais aspectos operacionais, considerando as particu-

laridades dos CSIRTs, incluindo tipos, modelos estruturais e autonomia da equipe:
11 Tipos; q
11 Modelos;
11 Autonomia.
Tipos
Um CSIRT pode ser classificado segundo a sua área de atuação. A abrangência de atuação dos
CSIRTs está intimamente ligada ao setor de atuação. Principais categorias de CSIRTs:
11 CSIRTs internos: são os CSIRTs que cuidam somente dos incidentes da sua instituição e,
em alguns casos, não são publicamente divulgados. Exemplo: instituições financeiras;
11 CSIRTs de coordenação: são times que atuam como intermediadores. Atuam repas-
sando informações e medindo tendências. Tais CSIRTs, tipicamente, não possuem
nenhum poder sobre os grupos com os quais interagem. Exemplo: CSIRT nacional;
11 CSIRTs de vendedores: são os CSIRTs que representam os fabricantes de hardware ou

software e que tratam das vulnerabilidades existentes nos seus produtos;
11 CSIRTs de consultoria: prestam os serviços relacionados com a resposta de incidentes

de forma terceirada. Esse tipo de CSIRT é utilizado por empresas que não possuem o seu
próprio CSIRT;
11 CSIRTs de pesquisa: são grupos especializados em pesquisa na área de segurança, tipi-

camente relacionado com estudo de vulnerabilidades.
Modelos
Apesar de atuarem na mesma área, os CSIRTs podem possuir modelos estruturais dife-
rentes. Principais estruturas organizacionais utilizadas na implantação dos CSIRTs:
10
22 CSIRTs centralizados: a equipe possui membros dedicados às atividades do CSIRT,
sendo estabelecida de forma centralizada no âmbito da organização;
22 CSIRTs descentralizados: a equipe fica geograficamente distribuída em diferentes

cidades ou, até mesmo, países. Possui equipe dedicada às atividades de tratamento
e resposta aos incidentes de rede computacionais, podendo atuar operacionalmente
de forma independente, porém alinhada com as diretrizes estabelecidas pela coorde-
nação central;
22 CSIRTs mistos: trata-se da junção entre modelos centralizados e descentralizados.

Nessa estrutura, a equipe centralizada é responsável por criar as estratégias, geren-
ciar as atividades e distribuir as tarefas entre as equipes descentralizadas;
22 CSIRTs de crise: a equipe é reunida durante a emergência de um processo de crise,

sendo composta por especialistas de cada área, deixando de existir após a conclusão
de solução do incidente.
Um desafio crescente para os CSIRTs está em acompanhar o que acontece na área de

segurança durante as 24h do dia. Um CSIRT descentralizado ou misto possui a vantagem
de possuir representantes em diversos fusos horários, permitindo, assim, cobertura mais
ampla dos acontecimentos.
Autonomia
Outro fator crítico como aspecto fundamental de organização é a autonomia do CSIRT.
A autonomia descreve o nível de responsabilidade e também o escopo de atuação da equipe
sobre atividades relacionadas ao tratamento de incidentes. A classificação dos diferentes
níveis de autonomia é apresentada a seguir:
11 Autonomia Completa: uma equipe tem autonomia plena para tomar as decisões e executar
as medidas necessárias para solucionar um incidente de segurança. As decisões podem
ser tomadas pela equipe sem a necessidade de aprovação de níveis superiores de gestão;
11 Autonomia Compartilhada: uma equipe com autonomia compartilhada deve atuar

em conjunto com os outros setores da organização. Para isso, a equipe participa do
processo de tomada de decisão sobre as ações a serem implementadas com outros
membros da organização;
11 Sem Autonomia: a equipe sem autonomia só pode agir com autorização expressa de um
responsável previamente designado. Nessa categoria a equipe apenas pode recomendar
os procedimentos a serem executados; no entanto, não tem participação no processo
final de decisão. Capítulo 1 - Definições e fundamentos
de CSIRTs
Definição de incidente
Um incidente de segurança pode ser definido como qualquer evento adverso, confirmado q
ou sob suspeita, que pode comprometer em algum aspecto a segurança computacional.
Em geral, toda situação na qual um ativo de informação está sob risco é considerado um
incidente de segurança.
A definição de um incidente de segurança é fundamental para as operações de um CSIRT.

Apesar de muitas vezes ser abstrata, a definição deve ter relação com as atividades e área
de atuação do próprio CSIRT. Deve-se, por exemplo, determinar que tipos de eventos serão
tratados pela equipe.
11
Exemplos comuns de incidentes incluem: q
11 A desfiguração do portal web de uma instituição;
11 O vazamento de informações confidenciais;
11 A propagação de um vírus por meio da lista de contatos de e-mails;
11 O envio de spam;
11 O comprometimento da rede;
11 A disponibilidade de um website.
Na sequência são listadas algumas definições de incidentes de segurança descritos por

diferentes times e especificações de segurança:
11 CAIS/RNP (http://rnp.br/cais/):
“Um incidente de segurança é resultante do mau uso dos recursos computacionais.”;
11 CERT/CC (http://www.cert.org/tech_tips/incident_reporting.html):
“Um ato de violação explícita ou implícita de uma política de segurança.”;
11 Terena (www.terena.nl/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html):
“Um incidente de segurança é um evento que envolve uma violação de segurança.”;
11 NIST (disponível em SP 800-3: Establishing a Computer Security Incident Response

Capability): “Qualquer evento adverso em que aspectos da segurança computacional
podem ser ameaçados”;
11 RFC 2350 (http://www.ietf.org/rfc/rfc2350.txt): “Qualquer evento adverso que pode com-

prometer algum aspecto da segurança de computadores ou da rede.”;
11 DSIC (http://dsic.planalto.gov.br/legislacaodsic/53): “Qualquer evento adverso, confir-

mado ou sob suspeita, relacionado à segurança dos sistemas de computação ou das
redes de computadores.”
Incidentes de segurança podem facilmente resultar em impacto significativo para uma insti-
tuição se não manejados de forma correta. De fato, a severidade de um incidente é mensurada
segundo o impacto que causa no processo de negócio de uma instituição. Por exemplo, um
incidente que indisponibiliza um site de e-commerce possui alta severidade para a instituição.
Todo incidente deve ser tratado seguindo uma metodologia previamente definida pelo q
CSIRT. Essa metodologia é chamada de processo de resposta a incidente e será poste-
riormente tratada em nosso curso.
Passos para criação de um CSIRT

Conforme descrito anteriormente, existem diferentes fatores que devem ser observados
para a criação de um CSIRT. Além de questões políticas, como aprovação organizacional, é

importante o CSIRT ser reconhecido como atuante na própria comunidade.
No que tange a questões organizacionais, é importante considerar as seguintes questões q

durante o processo de formação de um CSIRT:
11 Abrangência operacional;
11 Missão;
11 Serviços;
11 Modelo organizacional;
11 Recursos.
12
De forma resumida, temos nas etapas iniciais a definição do escopo de atuação, bem como
as metas e objetivos do CSIRT. A identificação da comunidade a ser atendida é fundamental,
pois possibilita mapear as necessidades e serviços necessários para atendê-la. Já o modelo
organizacional – incluindo o tipo e estrutura – determinam a estratégia administrativa a ser
implementada aos serviços. Por fim, e não menos importante: já na fase de estabelecimento
de um novo CSIRT deve-se assegurar os recursos necessários para manter o time operacional,
observando recursos da infraestrutura (equipamentos) e pessoal (equipe). Do contrário, as
etapas anteriores não serão efetivas.
Fóruns de CSIRTS
Assim como algumas categorias de instituições, os CERTs também se organizam em fóruns
e entidades que buscam a colaboração entre os times. As principais entidades que podem
servir de ponto de contato para localizar times são:
11 FIRST: Forum of Incident Response Security Teams – q

http://www.first.org
11 APCERT: Asian Pacific Computer Emergency Response Teams –

http://www.apcert.org
11 CSIRTs: European Trusted Introducer CSIRTs Members –

http://www.ti.terena.nl
11 OIC: Organization of the Islamic Conference –

http://www.oic-oci.org/
O Forum of Incident Response Security Teams (FIRST) é uma das organizações mais antigas.
O FIRST é uma organização profissional, sem fins lucrativos, composta por diferentes CSIRTs.
Os times de segurança que a compõem são muito heterogêneos: de times nacionais (CERTs),
CSIRTs de vendedores, CSIRTs internos a CSIRTs comerciais. O FIRST promove eventos anuais
para membros onde é possível estabelecer contatos com outros times e também capacitar a
equipe nos diversos seminários e cursos disponibilizados. É importante notar que o FIRST é uma
associação de CSIRTs, mas não atua como um CSIRT. Ou seja, o FIRST não responde a incidentes
de segurança, mas pode ser útil para identificar os responsáveis por recursos de internet.
Leitura recomendada:
11 Creating an Incident Response Team:

http://www.educause.edu/ir/library/pdf/SEC0302.pdf
11 NIST SP 800-3: Establishing a Computer Security Incident Response Capability (CSIRC):

de CSIRTs
http://www.terena.nl/activities/tf-csirt/archive/800-3.pdf
11 RFC 2.350: Expectations for Computer Security Incident Response:

http://www.ietf.org/rfc/rfc2350.txt
11 Forming an Incident Response Team:

http://www.auscert.org.au/render.html?it=2252
11 Departamento de Segurança da Informação e Comunicações (DSIC): Criação de equipes

de tratamento e resposta a incidentes em redes computacionais – ETIR. Disponível em:
http://dsic.planalto.gov.br/legislacaodsic/53
13
14
2
Gerenciamento do CSIRT
objetivos
Discutir questões relacionadas aos requisitos estruturais de um CSIRT; Conhecer os

fatores de sucesso na criação de um CSIRT; Aprender os conceitos relacionados ao
gerenciamento de um CSIRT.
conceitos
Gerenciamento de CSIRTs; Visão estrutural do CSIRT; Melhores práticas e condutas
apropriadas.
Introdução
O gerenciamento de um CSIRT, assim como outras organizações, envolvem etapas téc- q
nicas e administrativas. Todas essas etapas possuem um único objetivo: assegurar que o
CSIRT cumpra a própria missão previamente definida.
De forma mais específica, busca-se assegurar que os serviços relacionados à resposta a inci-
dentes de segurança sejam efetivamente prestados para a sua comunidade de abrangência.
Neste contexto, este capítulo discutirá tópicos relacionados ao gerenciamento de um CSIRT,

tal como: gerenciamento da equipe, comunicação, requisitos estruturais e fatores de sucesso.
Código de conduta
O código de conduta define um conjunto de premissas que balizam as ações e comporta-
mentos de um time de segurança.
O mesmo código aplica-se a todos os membros da organização, estendendo-se aos serviços

prestados e aos demais aspectos operacionais, tais como a comunicação e o zelo pelas
Capítulo 2 - Gerenciamento do CSIRT
informações.
De forma específica, o código de conduta vincula princípios e valores da própria insti- q

tuição com atividades desempenhadas pela equipe.
Princípios como profissionalismo, confiabilidade e liderança influenciam na forma com que o

CSIRT é visto externamente.
Um bom código de conduta descreve princípios para a interação com os usuários dos
serviços do CSIRT e também a maneira com que as informações são tratadas internamente
pela equipe. Sem o devido cuidado para lidar com as informações sensíveis, é provável que
as entidades parceiras possam hesitar em divulgar dados para o seu time em futuros inci-
dentes de segurança.
15
A conduta profissional com que as informações são tratadas por um CSIRT é evidentemente
particular a cada instituição. Sabe-se que existem alguns CSIRTs que optam por regras mais
restritivas. Um CSIRT militar, por exemplo, implementa alto nível de sigilo com as informa-
ções que gerencia. Por outro lado, um CSIRT acadêmico pode implementar um código de
conduta mais flexibilizado no que tange ao armazenamento de informações de segurança.
Observa-se, entretanto, que a grande maiorias dos CSIRTs possuem políticas e procedi-
mentos que classificam as informações ao menos em duas categorias: dados públicos e
dados sigilosos. Já em uma solução mais robusta, podem-se classificar as informações em
uma estrutura multinível.
A seguir temos o exemplo de uma estrutura de classificação de informações de segurança. q

11 Classificado: são informações sigilosas, onde apenas o CSIRT tem conhecimento do
incidente. Da mesma forma, a circulação das informações é restrita aos membros do
time de segurança. Esse tipo de classificação é utilizado em eventos de segurança
especiais – ou ainda em incidentes com escopo bem definido;
11 Parcialmente classificado: são dados que possuem certo nível de restrição. Tais
informações são intercambiadas apenas com entidades com alto nível e confiança, tal
como CSIRTs com bom relacionamento;
11 Não classificados: são informações que podem ser divulgadas na forma pública.
Para isso, deve-se avaliar o teor das informações a serem classificadas como “Não
classificado”, a fim de evitar prejuízos às partes envolvidas. Na maioria das vezes,
dados inseridos nessa categoria possuem caráter informacional, como, por exemplo,
divulgação de documentação ou estatísticas públicas do CSIRT.
Cada nível de classificação também especifica como as informações devem ser gerenciadas
sob o ponto de vista operacional. Em níveis mais restritivos, por exemplo, todas as informa-
ções devem ser cifradas, tanto na transmissão quanto no armazenamento.
Independentemente do modelo de classificação de informações adotado, é fundamental

que o CSIRT mantenha-se consistente e estenda a classificação para os demais serviços e
elementos relacionados ao processo de resposta a incidentes.
Um exemplo consiste na gestão das informações de contatos técnicos. Por ser um ponto de
contato para incidentes de segurança, espera-se que um CSIRT tenha um bom relaciona-
mento com entidades externas. Na maioria das vezes, a equipe do CSIRT conhece pessoas
de outros times que podem auxiliar em uma eventual emergência. Esses contatos, que não
são públicos, e sim fruto de uma boa relação com outras equipes, devem ser tratados de
forma adequada segundo a conduta o seu próprio CSRIT.
Considere a seguinte situação:

“O seu CSIRT recebe uma ligação de um colaborador externo (entidade A), em caráter de
urgência, solicitando os contatos mais específicos de uma instituição (entidade B), pois está
sofrendo ataques.”
O código de conduta de sua instituição deve prever possíveis ações que contemplem esse
exemplo. Nesse caso, deve-se analisar se o código de conduta permite encaminhar os seus
contatos mais específicos a entidades externas.
Possíveis soluções: q
11 O CSIRT não encaminha os dados (da entidade B), pois faz parte do seu código de
conduta manter contatos mais específicos de forma confidencial;
16
11 O CSIRT encaminha contatos mais específicos para o colaborador externo (entidade A); q
11 O CSIRT atua como intermediário, repassando a informação do ataque diretamente
para a entidade B.
A divulgação de informações também faz parte do código de conduta do CSIRT. Os meios

para divulgar informações serão tratados posteriormente por este curso; no entanto,
cabe ao código de conduta definir uma política para a divulgação de informações. Essa
política deve descrever o conjunto de informações que podem ser divulgadas no contexto
de resposta a incidentes. Sem a definição dessa política, a equipe pode não ter orientação
necessária para gerenciar o processo de resposta a incidentes.
Alguns times tratam todas as informações como estritamente confidencial, evitando o

compartilhamento das informações fora do âmbito dos membros da equipe. No entanto,
essa política estrita não pode ser garantida em todos os casos. Por exemplo, em casos onde
é necessária a interação da Justiça.
Logo, é desejável que, independentemente da política utilizada, sejam consideradas q

algumas questões, como:
11 Que time de informação o CSIRT divulgará quando outro CSIRT notificar um incidente
envolvendo a comunidade de sua responsabilidade?
11 Quando necessária interação com a Justiça, o seu CSIRT poderá prover informações
necessárias de forma direta?
11 Que tipo de informações serão divulgadas de forma pública?
11 Todo incidente será notificado a um CSIRT de coordenação, como por exemplo, CERT.br?
11 As informações de incidentes externos serão ocultadas, como por exemplo, saniti-

zação de IPs de sua rede?
Todas essas decisões fazem parte do código de conduta de um CSIRT e devem ser consi-
deradas nas etapas iniciais do estabelecimento de um CSIRT na comunidade. É importante
notar que essa política de conduta é algo que pode ser alterado. Em muitos times, é comum
que novas questões sejam contempladas e aprimoramentos sejam incorporados com a
aquisição de experiência.
Equipe
Constituir uma equipe é uma das primeiras coisas a serem pensadas na etapa de estabe-
lecimento de um CSIRT. De fato, a equipe tem papel fundamental nas atividades do CSIRT,
dando suporte às políticas internas, procedimentos e código de conduta intrínseco à ope-
ração de um time.
Sabe-se que a definição de uma equipe passa por diversos aspectos, incluindo questões
técnicas, gerenciais e, essencialmente, a alocação de recursos financeiros.
Do contrário, a equipe não poderá prover de forma adequada os serviços para a comunidade
e contemplar a missão do próprio CSIRT.
Alguns fatores também devem ser considerados no momento da definição de uma equipe: q
11 Número de pessoas necessárias;
11 Habilidades necessárias;
11 Habilidades desejadas;
11 Níveis hierárquicos;
17
11 Carga horária; q
11 Rotatividade;
11 Ética.
Estimar o número de pessoas necessárias para uma equipe, sobretudo em etapas iniciais
de operação, é uma tarefa complexa. O tamanho da equipe deve considerar um número
ideal de profissionais necessários para realizar as atividades de um CSIRT, incluindo equipe
técnica e gerencial.
O tamanho da equipe deve considerar aspectos como: q

11 Recursos financeiros;
11 Recursos humanos;
11 Serviços prestados;
11 Comunidade a ser atendida.
Sabe-se, no entanto, que uma vez que o time de segurança estiver estabelecido, novos
serviços são demandados pela comunidade. Além disso, o conjunto de serviços oferecidos
deve ser aprimorado, o que pode demandar mais trabalho que o inicialmente previsto.
Portanto, definir o tamanho da equipe tem influência direta na qualidade das atividades
prestadas pelo CSIRT.
Nos primeiros anos, muitos CSIRTs atuam com uma equipe minimizada e, com o passar
do tempo, novos membros ingressam no time, aprimorando os serviços prestados. A fim
de adequar o tamanho da equipe ao volume de trabalho demandado, recomenda-se fazer
uma estimativa com base nas notificações recebidas por outros times e também no número
de usuários conectados na rede, ou seja, a base de usuários que a equipe atenderá. Esse
número necessário de pessoas na equipe deve considerar também o crescimento de noti-
ficações – que pode chegar a 100% ao ano – e também possíveis expansões da instituição.
Não existe relação direta entre número de pessoas atendidas versus número de pessoas
na equipe. Isso pode variar muito, afinal, está relacionado com a missão do CSIRT, onde é
descrita a comunidade atendida e o conjunto de serviços realizados.
A equipe deve ser composta por profissionais com diferentes tipos de habilidades. Além de
habilidades técnicas necessárias para a execução das tarefas de um CSIRT, é importante que
os integrantes da equipe tenham habilidades administrativas e gerenciais.
Uma equipe multifacetada inclui profissionais com expertises em diferentes áreas: q

11 Especialistas em tecnologia de segurança;
11 Administradores de sistemas;
11 Engenheiros de redes;
11 Especialistas em suporte;
11 Gerente;
11 Conselho legal.
Evidentemente, as habilidades necessárias precisam estar alinhadas com os serviços ofe-

recidos. As habilidades técnicas desejadas na operação de um CSIRT requerem o entendi-
mento da tecnologia utilizada, tal como hardware e software.
18
Mesmo assim, existem alguns conhecimentos que são essenciais para a equipe que lida q
com incidentes de segurança:
11 Protocolos de redes (HTTP, MTA, DNS e FTP);
11 Sistemas Operacionais;
11 Infraestrutura de redes (roteadores e comutadores);
11 Ferramentas de segurança (IDS e firewall);
11 Criptografia;
11 Aplicações de rede;
l 11 Princípios básicos de segurança;

Dependendo do 11 Programação.
tamanho da equipe,
pode-se organizar o De fato, as habilidades técnicas fazem parte dos atributos necessários para os integrantes
grupo por áreas, onde
de uma equipe. Porém, nem todos os membros do time necessitam ter alto nível de conheci-
um responsável com
bom nível técnico pode mento em todas as áreas técnicas.
orientar os menos
experientes. Adicional- É fundamental, entretanto, que a equipe consiga lidar com os incidentes reportados pela
mente, as habilidades sua comunidade. Na prática, os outros departamentos da instituição só recorrerão ao CSIRT
técnicas podem ser
uma vez que reconheçam as competências técnicas do time para auxiliar de forma correta
aprimoradas através
de cursos e treina- nas necessidades identificadas.
mentos, fazendo
com que integrantes Além das habilidades técnicas, as habilidades interpessoais são igualmente importantes.
da equipe obtenham Em alguns casos, é mais fácil aprimorar as habilidades técnicas dos integrantes de uma
novas habilidades.
equipe do que trabalhar as habilidades interpessoais.
As habilidades interpessoais são exigidas nas mais diferentes etapas dos serviços prestados
por um CSIRT e não devem ser menosprezadas. A equipe está constantemente interagindo
com times de segurança e com os demais departamentos da instituição. Sabe-se da impor-
tância da interação com a comunidade de atuação do CSIRT, afinal, a reputação do CSIRT
depende do profissionalismo empreendido pela equipe.
A seguir, algumas características interpessoais desejadas: q

11 Comunicação verbal: comunicar de maneira clara e diplomática, e também saber ouvir;
11 Comunicação não verbal: leitura, escrita e linguagem corporal (para palestras e eventos);
11 Negociação: atuar com outros integrantes a fim de encontrar um resultado mutua-

mente aceitável;
11 Resolução de problemas: trabalhar em equipe para identificar, definir e solucionar

problemas, mesmo com restrições de tempo e recursos;
11 Assertividade: comunicar valores e opiniões de forma clara e confiante.

Os melhores profissionais são aqueles que aliam habilidades técnicas a habilidades

interpessoais, muito embora não exista um conjunto único de habilidades desejadas
para cada time.
É necessário avaliar a comunidade e a natureza dos serviços prestados, a fim de identificar

as habilidades necessárias. Alguns times optam por profissionais especialistas, outros,
porém, optam por profissionais generalistas.
19
Treinamento e desenvolvimento da equipe
O treinamento dos profissionais do CSIRT tem como objetivo manter a equipe preparada
para atuar no processo de resposta. Dessa forma, os integrantes do grupo podem apri-
morar suas habilidades e adquirir novas aptidões, de modo a prestar serviços de forma mais
efetiva para a comunidade de atuação.
Afinal, uma equipe com conhecimento das novas tecnologias e tendências de segurança pode q
identificar mais rapidamente as características de incidentes até então não identificadas.
O processo de desenvolvimento das habilidades da equipe deve começar com uma ava-
liação prévia das habilidades existentes no time e habilidades demandadas. Esse processo
deve avaliar cada membro da equipe de forma individual e priorizar demandas mais críticas
para o grupo. Como resultado, pode-se efetuar um treinamento com foco no indivíduo
ou, ainda, endereçado às limitações da equipe como um todo, tal como análise de riscos e
comunicação em inglês.
Procedimentos que podem ser implementados para o desenvolvimento da equipe: q

11 Estudo de procedimentos internos: ler e atualizar os procedimentos internos utili-
zados pelo CSIRT é uma forma de aprimorar habilidades individuais, sobretudo para
os novos membros da equipe. Sabe-se que os procedimentos usados na resposta a
incidentes são dinâmicos e necessitam de constantes atualizações. Logo, a constante
revisão dos procedimentos internos é benéfica para o time – que mantém o material
atualizado – e também para os integrantes que revisitam os procedimentos utilizados
nos incidentes passados;
11 Programa de tutoria: a figura de um tutor é utilizada na maioria dos CSIRTs no

treinamento de novos integrantes. Para isso, é designado um profissional da equipe
com mais experiência para auxiliar um novo integrante. O processo de tutoria deve
ser contínuo, até o tutor assegurar-se de que o novo integrante tenha proficiência e
consiga lidar, sem cometer erros custosos, com as tarefas demandadas;
11 Estudo individual: alguns CSIRTs consideram disponibilizar horário de trabalho para

que o profissional estude temas específicos – tal como análise forense – para serem
aplicados no processo de tratamento de incidentes. Para isso, a instituição deve
prover o material técnico necessário, tal como periódicos, revistas e livros;
11 Treinamento externo: alguns CSIRTs optam por treinar e desenvolver a equipe

usando instituições externas com boa reputação no mercado. Muitas vezes, trata-se
de uma questão pontual, onde novas habilidades precisam ser incorporadas à equipe
em um curto espaço de tempo.
Terceirização de serviços
Muitas vezes, a dificuldade de encontrar profissionais da área e estabelecer uma equipe

de segurança acompanhando as mudanças da indústria tem fomentado a contratação de
serviços externos, ou seja, a terceirização de serviços relacionados à segurança.
Cada instituição deve tomar as decisões que julgar mais convenientes em relação à tercei-
rização de serviços relacionados ao tratamento de incidentes de segurança. Alguns CSIRTs
optam, por exemplo, em terceirizar etapas nas quais a equipe não tem expertise, tal como
análise de malware. Por outro lado, outros times optam por terceirizar o CSIRT como um
todo, atribuindo a gerência de incidentes de segurança para uma entidade externa. Alguns
cenários onde esse modelo é comumente utilizado são em bancos e outras instituições
20
financeiras. Isso se deve, basicamente, ao grande volume de incidentes e os custos para
manter um corpo técnico especializado na instituição.
Antes de decidir pela terceirização de serviços, é fundamental avaliar as vantagens e desvan-

tagens de cada modelo.
Nesse contexto, alguns fatores devem ser considerados, tais como: q

11 Custos e riscos associados;
11 Dependência tecnológica;
11 Qualidade do serviço prestado;
11 Questões legais;
11 Questões operacionais;
11 Segurança das informações;
11 Representatividade.
A terceirização pode oferecer significativa redução dos custos enquanto estiver provendo
serviços similares com economia de recursos humanos e de infraestrutura. Além disso,
empresas terceirizadas geralmente definem um Service Level Agreement (SLA) no qual
pode ser estipulado o tempo de atendimento e demais métricas-chave que podem manter
a sua instituição segura com relação aos requisitos de qualidade. Adicionalmente, é possível
acompanhar as atividades do serviço contratado por meio de relatórios e, até mesmo, em
tempo real, tendo acesso ao sistema utilizado. Por outro lado, a terceirização de serviços
implica em disponibilizar informações sensíveis a terceiros.
Essas informações podem ser estratégias para segurança da instituição e também sob o ponto
de vista competitivo. Portanto, faz-se necessário avaliar, em âmbito operacional e gerencial, os
riscos inerentes à terceirização de serviços. É importante lembrar que a instituição que con-
trata os serviços continua sendo responsável por eventos de segurança perante a lei.
Para pensar
O armazenamento de arquivos na “nuvem” pode ser considerado terceirização

de recursos?
Contratação
A contratação é sempre um processo delicado, sobretudo para um CSIRT onde informações
sensíveis à instituição são manejadas. Para isso, faz-se necessário que o time de segurança
tenha um processo com etapas bem definidas para contratação de novos integrantes.
O processo de contratação é uma atividade que envolve outros departamentos da instituição.

O departamento de recursos humanos e o departamento jurídico, por exemplo, são setores
com os quais o CSIRT vai interagir na maioria das etapas do processo de contratação.
Já no processo de seleção, outros departamentos podem ser envolvidos. Evidentemente, q

cada instituição tem os seus próprios procedimentos internos de seleção que consi-
deram a própria cultura da instituição; no entanto, existem algumas etapas que devem
ser consideradas, tal como:
11 Análise curricular;
21
11 Entrevista pessoal; q
11 Questões contratuais;
11 Questões éticas.
Dependendo da natureza da organização e da natureza das funções a serem desempe-

nhadas, outros cuidados podem ser demandados. Isso inclui a aprovação específica das
altas hierarquias da instituição e, até mesmo, a verificação de antecedentes criminais.
As etapas do processo de seleção devem ser aptas a identificar os pontos fortes dos candi-
datos, bem como as limitações do profissional. Com isso, a equipe pode avaliar se as limita-
ções do candidato podem ser endereçadas através de treinamento e, por fim, identificar se
o candidato está apto a realizar as funções demandadas.
Uma entrevista pessoal com o candidato sempre é recomendada. O ideal é que essa
entrevista seja realizada com a presença de membros da equipe do CSIRT. Dessa forma,
questões técnicas podem ser esclarecidas e habilidades interpessoais, avaliadas. Na entre-
vista também devemos deixar claro as responsabilidades e benefícios demandados para a
equipe. Dessa forma, ambas as partes podem ajustar as suas expectativas.
Algumas questões que merecem ser esclarecidas: q

11 Atividades a serem desenvolvidas;
11 Plano de carreira;
11 Carga horária;
11 Possibilidade de viagens.
Além de questões típicas relativas ao horário de trabalho e atividade a ser desenvolvida, a

entrevista de seleção também deve tratar aspectos operacionais, tal como horas extras, tra-
balho em regime de sobreaviso e necessidade de viagens. Com isso, o candidato e o CSIRT
podem avaliar a adequação do perfil em função ao cargo.
Após a contratação, entra em ação um conjunto de tarefas que visam integrar o funcionário
à equipe e inseri-lo na cultura institucional. Por fim, também é parte do processo de contra-
tação treinar o funcionário com procedimentos internos e rotinas da equipe.
Do ponto de vista administrativo, o CSIRT deve manter a equipe motivada e com recursos
que permitam a evolução técnica e interpessoal dos integrantes do time.
Algumas formas de aprimorar e assegurar a evolução dos integrantes da equipe compreende: q

11 Garantir financiamento no plano de trabalho anual para treinamento de todos os
membros da equipe, incluindo equipe técnica e equipe gerencial;
11 Ter acesso a livros e artigos relevantes para a área de tratamento de incidentes, per-
mitindo que os membros do time expandam suas habilidades;
11 Assegurar que membros da equipe com pouca experiência sejam acompanhados de perto
por membros mais experientes, fazendo com que o esforço de aprendizado seja efetivo;
11 Participar de eventos com outros CSIRTs, pois é uma boa maneira de trocar expe-
riências práticas;
11 Encorajar membros da equipe a realizar cursos (pós-graduação, mestrado ou douto-

rado) em áreas relativas ao processo de incidentes, tais como criptografia, segurança
da informação, sistemas operacionais e redes de computadores.
22
Para pensar
Você contrataria estagiários ou bolsistas para atuar na resposta a incidentes?
Procedimentos de ingresso e desligamento

A formação de um time de resposta a incidentes não é o único desafio associado à resposta
a incidentes. Com o passar do tempo, a equipe evolui tecnicamente e novos conhecimentos
são incorporados ao CSIRT. Alguns membros do time passam para cargos gerenciais e novos
ocupam as lacunas existentes na equipe. Adicionado a isso, é comum que membros da
equipe se desliguem ou ainda sejam desligados do CSIRT.
Nesse contexto, um CSIRT deve estar preparado para lidar com a rotatividade e com a perda
de pessoas-chave na instituição.
Uma forma de lidar com a rotatividade da mão de obra é implementar uma política de q
rotatividade de atividades na própria equipe. Assim, evita-se que uma única pessoa
possua todo o conhecimento de uma determinada atividade ou processo.
Por exemplo, por um período determinado o funcionário responsável por tratar incidentes
de segurança troca de posto com o funcionário responsável pelas ferramentas de monito-
ração. Desse modo, o conhecimento das atividades do CSIRT passa a ser homogeneizado
entre os integrantes da equipe.
Devido à natureza sensível das informações que passam por um CSIRT, torna-se necessário que
procedimentos especiais sejam adotados no ingresso e no desligamento de um profissional.
Tipicamente os novos integrantes assinam contratos de confidencialidade específicos do CSIRT
e demais acordos da instituição relativos à propriedade intelectual. Por outro lado, quando
um integrante do CSIRT deixa de fazer parte do time, outros procedimentos devem entrar em
ação. Um procedimento de desligamento de funcionários de um CSIRT deve especificar tarefas
técnicas e administrativas que assegurem a segurança dos sistemas do CSIRTs. Afinal, o ex-fun-
cionário tende a levar consigo todo o conhecimento adquirido durante a sua estada no time,
incluindo sistemas utilizados, senhas dos servidores e procedimentos utilizados.
Sendo assim, aconselha-se que um roteiro de desligamento de funcionário seja criado.

Um bom procedimento de desligamento deve conter uma interação com outros departa-
mentos da instituição, tal como administradores de sistemas e administradores de bases
de dados.
As tarefas relativas ao desligamento deve considerar as seguintes questões: q

11 Credenciais de acesso:
22 Físico (portas, salas e datacenter);
22 Remoto (VPN);
22 Sistemas (contas de usuário em máquinas e servidores).
11 Dados de usuários (incluindo backup);
11 E-mail institucional.
O endereço de e-mail institucional, em especial, pode ter procedimentos diferentes para a

remoção. Alguns times optam por remover a conta subitamente, mas outros preferem
configurar uma mensagem automática informando o desligamento do funcionário.
23
Tal procedimento pode evitar possíveis ataques de engenharia social: q
“PAULO DA SILVA não faz mais parte da equjipe do CSIRT. Por favor, direcione os seus
e-mails para o e-mail do grupo, csirt@csirt.”
Por fim, é essencial que a equipe atente para os processos de ingresso de novos integrantes
e procedimentos de saída de um funcionário da equipe. Acabamos de descrever os principais
fatores para auxiliar o CSIRT a definir seus procedimentos. Sabe-se, no entanto, que existem
muitos outros fatores que não foram abordados. Por exemplo, considere a situação a seguir:
Um ex-funcionário conseguiria ter acesso ao sistema de documentação interno (website) do

CSIRT acessando a rede de visitantes da instituição?
Logo, o procedimento de desligamento de funcionários pode não ser complexo, mas deve
prever mecanismos de modo a evitar a situação do exemplo.
Requisitos estruturais
Os requisitos estruturais de um CSIRT constituem uma infraestrutura básica necessária q
para a efetiva condução de um CSIRT. Essa infraestrutura deve considerar os serviços
prestados e também o tamanho da comunidade a ser atendida. Alguns elementos estru-
turais que devem ser considerados:
11 Equipamento;
11 Software;
11 Espaço físico;
11 Legislação específica.
Evidentemente, a definição da infraestrutura operacional está sempre limitada pela dispo-

nibilidade de orçamento. Nem sempre a estrutura ideal pode ser implementada no início
do estabelecimento de um CSIRT. Mesmo assim, é importante definir recursos estruturais
mínimos para que o time possa prover os serviços para a sua comunidade. Por exemplo,
alguns softwares facilitariam a execução de tarefas relacionadas com análise de dispositivos
móveis; no entanto, o custo da licença pode pesar no orçamento inicial do CSIRT.
Outra questão fundamental na fase de especificação de recursos para a operação de um

CSIRT é ter clara a natureza das atividades prestadas pela instituição. Algumas áreas espe-
cíficas de atuação exigem normas de infraestrutura a serem seguidas pelo CSIRT. Nesses
casos, uma legislação específica deve ser seguida. Isso é muito comum para CSIRTs do setor
financeiro. Tais CSIRTs devem seguir uma normalização específica que inclui a utilização de
softwares específicos e auditoria de processos.
De fato, todos os CSIRTs possuem requisitos básicos para operar com segurança. Um dos
principais requisitos é em relação à infraestrutura operacional. Recomenda-se que a infra-

estrutura do CSIRT seja separada fisicamente e logicamente dos demais elementos da ins-
tituição. Sabe-se que a equipe de um CSIRT está constantemente lidando com informações
sensíveis e atuando com incidentes de segurança que devem ser tratados prontamente.
A separação física, por exemplo, aborda questões relativas ao local de trabalho e também ao
seu acesso físico. O ideal é que um CSIRT deve possuir uma sala dedicada para sua ope-
ração com os devidos controles de acesso. Desse modo, as informações sensíveis evitam ser
expostas a pessoas de outros setores da instituição. Nem sempre a separação física pode ser
efetivada, mesmo assim, é importante que o CSIRT implemente medidas para evitar o acesso
às suas áreas de trabalho, incluindo: filtro de privacidade, utilização de bloqueio de tela, orien-
tação do monitor no sentido contrário a do fluxo de pessoas e de câmeras de vigilância.
24
De forma complementar, é fundamental que o CSIRT implemente também a separação
lógica para os seus recursos. Por exemplo, usando um seguimento próprio de rede
(sub-rede) e servidores dedicados para as suas atividades. A topologia de rede, em especial,
deve considerar questões de redundância e conectividade. Uma queda de energia pode ser
tão prejudicial quanto um ataque de negação de serviço. Adicionalmente, a infraestrutura
de um CSIRT deve ser resiliente de modo a suportar e conter ataques. Um CSIRT é um poten-
cial alvo de ataques.
Logo, é desejável que, se isso vier a ocorrer, não cause qualquer prejuízo nas atividades
operacionais normais. Cabe à equipe possuir recursos de segurança para proteger os seus
sistemas e monitorar possíveis ações maliciosas destinadas à sua infraestrutura.
De forma resumida, os requisitos estruturais devem contemplar: q

11 Controles apropriados de defesa e controle para sistemas, redes, dispositivos, aplica-
ções, bases de dados e outros;
11 Um conjunto de procedimentos para o tratamento de incidentes e documento distri-

buído entre a equipe;
11 Tarefas designadas para cada membro da equipe e papéis definidos nos processos de
resposta a incidentes.
Procedimentos operacionais
Os procedimentos operacionais referem-se a um conjunto de atividades que têm por obje-
tivo guiar a equipe, fazendo com que ações apropriadas para a resolução de um incidente
sejam tomadas.
Para isso, são especificadas responsabilidades das partes envolvidas e as respectivas ações
que devem ser desempenhadas pelos membros do time.
Tipicamente, um CSIRT possui um conjunto de procedimentos operacionais para os prin-

cipais tipos de incidentes tratados pelo time, incluindo: comprometimentos de servidores,
infecção por vírus, negação de serviço e notificação de vulnerabilidades. Um bom procedi-
mento descreve em linhas gerais como determinados incidentes devem ser tratados, não
se atendo a tecnologia ou ferramentas a serem utilizadas. Dessa maneira, o profissional
pode seguir as etapas do procedimento e ter flexibilidade para escolher a tecnologia a ser
utilizada. Em boa parte dos casos, os procedimentos operacionais permitem eventuais
adaptações nas ações a serem realizadas; no entanto, recomenda-se que adaptações sejam
minimizadas durante o processo. Quando necessário efetuar adaptações no processo, é
essencial que as ações adicionais sejam documentadas.
Peculiaridades da instituição devem ser observadas na composição de procedimentos ope-

racionais, logo o conjunto de rotinas de cada CSIRT tende a ser único.
q
Mesmo assim, existem pontos comuns que devem ser endereçados para o efetivo
desenvolvimento de procedimentos operacionais:
11 Descrição sucinta do procedimento;
11 Classificação do incidente;
11 Situações em que o procedimento operacional deve ser aplicado;
11 A quem se destina o procedimento;
11 Quais são os recursos críticos;
25
11 Etapas prioritárias; q
11 Ações a serem realizadas;
11 Como as informações devem ser documentadas;
11 Quem pode contatar entidades externas;
11 Classificação da informação (pública, privada ou restrita);
11 Como o procedimento deve ser distribuído.
A título de ilustração, na sequência é apresentado um fragmento de um procedimento ope-

racional para coletar informações de sistemas comprometidos.
Como referência, o procedimento foi implementado tendo como base as proposições des-
critas pelos autores do livro Malware Forensics: Investigating and Analyzing Malicious Code, da
editora Elsevir.
Procedimento para coleta de informações em sistemas ativos
Em alguns incidentes específicos é necessário investigar uma máquina comprometida

mantendo o sistema em execução. Recomenda-se, nesses casos, coletar evidências de um
sistema comprometido começando pelos dados mais voláteis, ou seja, dados que podem ser
perdidos mais facilmente.
Inicialmente é importante lembrar que um sistema comprometido não é confiável. Devem-se

executar os comandos de investigação a partir de um sistema confiável, tal como um live CD
previamente preparado. Após essa observação, as seguintes etapas podem ser utilizadas no
procedimento de coleta de informações de sistemas ativos:
1. Documentar data e hora do sistema comprometido e comparar com uma fonte confiável.
2. Obter o conteúdo da memória do sistema utilizado.
3. Obter detalhes do sistema (versão do usuário, nome do computador na rede).
4. Analisar o status do sistema e detalhes do ambiente de execução (modo administrativo,
formas de acesso).
5. Identificar usuários logados no sistema.

6. Inspecionar as conexões de rede e portas abertas.
7. Examinar consultas DNS realizadas pela máquina comprometida.
8. Analisar os programas em execução.
9. Correlacionar os programas em execução e as portas abertas.
10. Inspecionar os arquivos abertos.
11. Examinar o histórico dos comandos digitados na linha de comando.
12. Verificar por contas não autorizadas no sistema, grupos e compartilhamento.
13. Determinar tarefas agendadas no sistema.
14. Coletar o conteúdo da área de transferência.
Todo procedimento deve ser previamente testado pela equipe. Os membros da equipe não
l
Uma boa forma de
podem ter dúvidas relativas às etapas a serem desempenhadas, tampouco sobre a maneira testar os procedi-
com que estas devem ser implementadas. mentos é revisar o
histórico de incidentes
É importante notar que os procedimentos não são imutáveis. Cada incidente tratado da instituição e verificar
se as etapas definidas
utilizando o respectivo procedimento é uma oportunidade para revisar a efetividade do
serão efetivas em boa
processo. Cabe ao time avaliar as diferentes etapas e identificar a sua eficiência. E, caso seja parte dos casos.
necessário, seguir a rotina que especifica como os procedimentos devem ser atualizados.
26
Comunicação
A comunicação diz respeito a todas as ações onde um CSIRT interage com outras q
entidades. Isso engloba comunicação efetuada de forma verbal ou escrita. De fato,
a comunicação com outras entidades é uma atividade muito frequente nas atividades
diárias de um CSIRT.
Afinal, sabe-se que o processo de resposta a incidentes é uma tarefa coletiva onde a comuni-
cação com diferentes entidades é demandada para a resolução de incidentes de segurança.
A comunicação pode ser efetuada utilizando diferentes meios, tal como: envio de e-mails;
telefonemas, entrevistas, palestras e cursos. Sendo assim, cabe ao CSIRT conhecer os
fundamentos de uma boa comunicação para aprimorar o fator de sucesso no processo de
No contexto de um CSIRT, o primeiro ponto a ser salientado são os diferentes níveis de

detalhamento que devem ser utilizados durante uma comunicação. Evidentemente que isso
está atrelado ao código de conduta do próprio CSIRT. Mesmo assim, devem ser tomados
cuidados especiais ao comunicar-se com as diferentes partes envolvidas no processo de
resposta a incidente. Uma das principais dificuldades está em interagir com pessoas com
diferentes níveis de conhecimento técnico.
Tipicamente, ao notificar um incidente, envia-se uma notificação para o responsável pelo

sistema afetado. Muitas vezes, no entanto, o responsável pelo sistema não possui conheci-
mentos técnicos para auxiliar na resolução do problema. Em outros casos, porém, o respon-
sável não pode ser claramente definido.
Nesses casos, para que a comunicação do incidente seja efetiva e compreendida, é q

necessário considerar alguns aspectos básicos, tais como:
11 Contextualização do problema a ser reportado;
11 Ausência de jargões;
11 Uso de sentenças claras;
11 Informações sintetizadas.
É importante descrever e sempre contextualizar como comunicação relativa à notificação de

segurança. Dessa maneira, o destinatário pode entender ou relembrar o caso a ser tratado.
Da mesma forma, é importante lembrar que muitas notificações são enviadas para e-mails
institucionais, o que pode resultar em diferentes pessoas tratando, ou continuando, o inci-
dente de segurança.
Adicionalmente, evitar o uso de jargões e siglas evita possíveis mal-entendidos. Termos

técnicos, siglas e abreviações podem ter diferentes significados, dependendo do contexto
utilizado. Por exemplo, o protocolo Border Gateway Protocol (BGP) é facilmente interpretado
por administradores de sistemas; no entanto, em outros contextos, a sigla BGP pode repre-
sentar “Batalhão da Guarda Presidencial”.
Muitas vezes a resolução de um incidente depende da boa vontade de um administrador de

rede. Por isso, é fundamental que a comunicação atenha-se a questões fundamentais para
a investigação do incidente. Em alguns casos, uma solicitação de ajuda polida e descrita de
forma direta é mais efetiva que uma notificação extrajudicial.
27
Deve-se evitar o uso de frases que possam parecer ofensivas para outros usuários e, até mesmo,
observar fatores culturais para evitar um possível insulto para a sua audiência. Por exemplo,
notificar a hospedagem de um conteúdo sexual pode gerar possíveis constrangimentos.
Por fim, é importante lembrar que a forma com que o CSRIT comunica-se vai definir como
este será visto externamente, deixando impressões do trabalho realizado.
Polidez e profissionalismo na comunicação são qualidades que devem ser buscadas

em todos os processos de resposta a incidentes, sobretudo, na interação com
outras entidades.
Como lidar com a imprensa

Muitas vezes um CSIRT necessita lidar com a imprensa para a divulgação de procedimentos
e esclarecimentos relacionados aos eventos de segurança. A efetiva comunicação com a
impressa é mais uma forma de comunicar-se com a comunidade de atuação e, em última
análise, pode ser determinante para o estabelecimento de um CSIRT na comunidade.
Cada instituição tem sua própria política de relacionamento com a imprensa. Algumas
instituições possuem departamentos próprios para atuar com a comunicação externa.
Já outras instituições optam por desenvolver políticas e procedimentos internos para
lidar com a imprensa.
Independentemente do modelo utilizado para o relacionamento com a imprensa, todos os

membros da equipe devem saber como posicionar-se frente às mídias públicas. Os membros
da equipe devem estar cientes que representam o CSIRT, onde opiniões pessoais podem
ser erroneamente interpretadas como posicionamento da equipe. A posição de um CSIRT
só pode ser considerada quando é fruto de consenso e compartilhada entre todos os
membros da equipe.
As seguintes questões devem estar definidas em uma boa política de relacionamento q

com a imprensa:
11 Quem do CSIRT possui autorização para entrevistas?
11 Qual é o meio pelo qual a comunicação pode ser realizada?
22 Comunicados impressos;
22 Entrevistas gravadas;
22 Entrevistas ao vivo.
11 Que informações o CSIRT pode divulgar?
11 A equipe divulga informações no decorrer de uma investigação?

Sabe-se que os CSIRTs são constantemente sondados por jornalistas quando grandes casos
ganham a mídia nos grandes jornais, tal como assuntos relacionados a espionagem, ciberguerra,
vazamento de informações e vulnerabilidade de sistemas. Em casos onde as informações
demandadas pela imprensa estão diretamente relacionadas com incidentes sendo investigados,
é necessário que os cuidados na comunicação sejam redobrados.
O CSIRT deve atentar para: q

11 Não divulgar informações confidenciais;
11 Não divulgar informações sobre investigações em andamento;
11 Não apontar culpados ou responsáveis;
28
11 Não relacionar parceiros, terceiros ou concorrentes sem prévio consentimento; q
11 Evitar comparações sem embasamento e sem prévio consentimento.
Declarações errôneas e más interpretações podem pôr em cheque a segurança da própria

instituição e, em últimos casos, afetar a imagem pública de uma instituição. Por exemplo,
uma indisponibilidade temporária no servidor causado por um negação de serviços pode
ser interpretada como comprometimento da infraestrutura ou, ainda, que usuários do
sistema tiveram seus dados expostos.
Algumas recomendações que a equipe pode usar para o posicionamento frente q

à imprensa:
11 Identificar os aspectos-chave da sua comunicação;
11 Antecipar questões difíceis formulando respostas prévias;
11 Utilizar sentenças curtas;
11 Explicar de forma simplificada questões técnicas;
11 Utilizar frases positivas ao invés de negativas;
11 Ser diplomático e sempre falar a verdade;
11 Utilizar vestimenta adequada.
Por fim, o entrevistado tem o direito de terminar a entrevista a qualquer momento

quando seus direitos não forem respeitados.
Figura 2.1
Como cada um Hackers derrubaram por O que as pessoas ouvem: O que os especialistas em
entende pouco tempo o website computação ouvem:
Alguém invadiu os
Fonte: http://xkcd. da CIA ontem. computadores da CIA Alguém derrubou um cartaz
com/932/
pendurado pela CIA
Fatores de sucesso
q
Fatores de sucesso descrevem aspectos que devem ser observados para que um CSIRT
tenha os seus objetivos propostos alcançados.
Evidentemente não existe um conjunto de regras que determinem o sucesso de um CSIRT.

Cabe a cada time constantemente avaliar os seus recursos e especificar métricas de ava-
liação de desempenho do time como um todo.
Sem dúvida, a qualidade dos serviços prestados é determinante para a competência e

eficiência da equipe.
29
No entanto, existem outros fatores igualmente importantes para auxiliar na longevidade q
do CSIRT e no estabelecimento do CSIRT na sua comunidade de atuação, tal como:
11 Contar com o apoio organizacional;
11 Ter papel caracterizado na política de segurança da instituição;
11 Definir a autoridade que possui o CSIRT;
11 Divulgar o CSIRT para seu público-alvo;
11 Obter formas de financiamento adequadas e duradouras.
São observados os maiores desafios operacionais nos estágios iniciais da operação. Uma das
principais barreiras para o sucesso de um CSIRT é o seu reconhecimento pela sua própria
comunidade. Nesse contexto, o apoio organizacional torna-se importante, pois evita que o CSIRT
seja visto como mais um departamento na instituição ou, ainda, um departamento com funções
sobrepostas aos demais departamentos, tal como o departamento de tecnologia de informação.
A aceitação de um time também depende de sua eficiência. É importante que o CSIRT tenha
a habilidade de coordenar a resposta a incidentes atuando de forma profissional e com a
expertise necessária para a resolução do caso. Com uma atuação transparente, descre-
vendo as ações tomadas e o status das atividades, o CSIRT tende a fortalecer a confiança dos
usuários na equipe.
Além do estabelecimento do CSIRT na estrutura organizacional da instituição, é necessário

assegurar recursos para manter o time funcionando de forma permanente. Questões como
verbas, fundos de financiamento e alocação de recursos são igualmente importantes para o
sucesso de um CSIRT. Sendo assim, cabe ao time pleitear junto à sua instituição os recursos
financeiros necessários para manter a sua operação.
Ao avaliar questões relativas a fontes de financiamento, deve-se considerar: q

11 Assegurar recursos financeiros de forma regular e permanente;
11 Identificar fontes de financiamento alternativas;
11 Estimar o custo operacional do CSIRT constantemente.
Tipicamente, os CSIRTs devidamente inseridos na estrutura organizacional possuem uma

verba já alocada para a sua operação, não tendo problemas com a falta de recursos, muito
embora isso nem sempre seja uma realidade.
A falta de financiamento é um problema encontrado por algumas equipes. Uma organização

pode fornecer recursos para o estabelecimento de uma equipe competente, com equipamentos
necessários, e o devido treinamento. Entretanto, no primeiro percalço, o financiamento para a
segurança é um dos primeiros a serem cortados.
Profissionais de segurança sabem da dificuldade de justificar o financiamento de um CSIRT.

A segurança não produz lucros para a instituição em curto prazo, mas sim em médio e longo
prazo. O CSIRT atua na prevenção e solução de incidentes de segurança, o que resulta, em
última análise, na diminuição de possíveis custos.
Sabe-se que o sucesso da equipe pode trabalhar contra a própria equipe. A redução dos inci-
dentes causados pelo bom trabalho do grupo pode passar a sensação de que a equipe é desne-
cessária. Logo, aconselha-se documentar todas as atividades e elaborar resumos executivos
das ações desempenhadas pelos CSIRTs para que estes sejam apresentados aos gestores.
30
Por outro lado, a falta da observância dos fatores descritos corrobora com o insucesso do
CSIRT. A falta de apoio institucional e a inexistência de recursos adequados para manter o
time constituem os principais fatores de fracasso de uma equipe.
A falta de planejamento e a realização de ações inadequadas tendem a minar a confiança q

no grupo, causando:
11 Falta de apoio da organização;
11 Ausência de autoridade para iniciar o processo de segurança;
11 Despreparo para responder a eventos.
É fundamental que o CSIRT entenda a atividade comercial da instituição e como o time

enquadra-se no contexto.
Em instituições comerciais, manter o funcionamento de atividades que geram receita

financeira tem prioridade. É um fato. Até mesmo em empresas não comerciais, a
continuidade dos negócios tem a primazia. Um time de resposta a incidentes deve observar
tais premissas e evitar ao máximo que a instituição deixe de realizar sua atividade comercial.
De certa forma, o CSIRT provê apoio para as atividades comerciais da instituição.
Um erro comum cometido pelos CSIRTs é focar a resolução de incidentes apenas em aspectos
técnicos, sem avaliar a situação da instituição como um todo. Os membros da equipe devem
saber o que é impactado quando um determinado recurso é comprometido. Por exemplo,
em um comprometimento de um servidor web, deve-se primeiramente identificar quais
atividades são impactadas e, só depois, identificar como o servidor foi comprometido e que
técnicas e ferramentas foram utilizadas pelo atacante.
Considere a seguinte situação:
11 O seu único servidor de e-commerce foi comprometido. Observa-se um padrão atípico na

matriz de tráfego do servidor em pleno horário de expediente da empresa.
Para pensar
Business comes first (Primeiro os negócios).
Desligar o servidor imediatamente para investigação seria a melhor opção na perspectiva de

resposta a incidentes; no entanto, no ponto de vista de continuidade de negócios, talvez não
seja a melhor opção. O desligamento do servidor durante o horário de expediente poderia

causar perdas maiores para a continuidade das atividades críticas que manter a organização
funcionando. Uma solução intermediária poderia ser agendar uma manutenção progra-
mada para a investigação do servidor em um horário com menos acessos aos serviços do
servidor. A resposta de incidentes pode ser formulada de forma mais efetiva apenas anali-
sando as consequências para a instituição.
Por fim, o sucesso de um CSIRT depende da instituição como um todo. Além de realizar um bom
trabalho, deve-se atentar para questões políticas e continuidade dos negócios de uma instituição.
31
11 Creating an Incident Response Team:

http://www.educause.edu/ir/library/pdf/SEC0302.pdf
11 NIST SP 800-3: Establishing a Computer Security Incident Response Capability (CSIRC):

http://www.terena.nl/activities/tf-csirt/archive/800-3.pdf
11 RFC 2.350: Expectations for Computer Security Incident Response

11 CERT/CC CSIRT Services:

http://www.cert.org/archive/pdf/CSIRT-services-list.pdf
11 Handbook for Computer Security Incident Response Teams (CSIRTs):

http://www.sei.cmu.edu/pub/documents/98.reports/pdf/98hb001.pdf
11 RFC2196 – Site Security Handbook: http://www.ietf.org/rfc/rfc2196.txt
11 RFC3013 – Recommended Internet Service Provider Security Services and Procedures:

11 Site Security Handbook: http://www.ietf.org/rfc/rfc2196.txt
11 Recommended Internet Service Provider Security Services and Procedures:

32
3
Riscos e ameaças
Ter visão de ameaças e riscos associados aos sistemas; Identificar os principais
incidentes de segurança observados pela comunidade de segurança; Ter ciência das
objetivos
etapas para o comprometimento de sistemas; Conhecer os conceitos relacionados

com os ataques e ameaças provenientes da internet; Discutir questões relacionadas
ao papel dos atacantes no atual cenário da segurança.
conceitos
Análise de risco e custos de um incidente; Nomeclatura de incidentes.
Introdução
Identificar as ameaças de segurança e seus respectivos riscos associados faz parte das q
premissas básicas para atuar no processo de resposta de incidentes de segurança.
Um CSIRT deve ter conhecimento das principais categorias de incidentes. Dessa forma,
pode aprimorar os seus procedimentos de modo a responder eventos de segurança de
forma eficiente.
Identificar ameaças de segurança e características de ataques permite à equipe determinar

quais são os incidentes mais danosos à infraestrutura da instituição.
E, dessa forma, direcionar melhor os seus recursos de segurança para lidar com os inci-
dentes mais críticos. Isso é fundamental, sobretudo, nas etapas iniciais do processo de
resposta a incidentes, onde os incidentes são priorizados e classificados. Sendo assim,
identificar previamente os riscos associados a um evento de segurança permite que a
equipe atribua as ações específicas de investigação.
Este capítulo busca apresentar conceitos básicos relacionados a análise de riscos e também
descreve as principais ameaças, ou seja, os tipos de incidentes frequentemente enfrentados
por equipes de respostas a incidentes. Por questões de organização, este capítulo está estru-
Capítulo 3 - Riscos e ameaças
turado em duas partes. Inicialmente são apresentados conceitos relacionados à análise de

risco e, posteriormente, são descritos os principais riscos associados à segurança de sistemas.
Análise de risco
A análise de risco é um tema bastante amplo, onde se busca prover meios para identificar
potenciais riscos associados a uma determinada ação a ser realizada. No contexto de
resposta a incidentes, a análise de risco tem um papel fundamental na definição de ações a
serem tomadas frente a um evento de segurança.
33
De certa maneira, um time de resposta de segurança atua diretamente com o gerencia- q
mento de riscos associados à sua atuação. Em um contexto mais específico, a análise de
risco busca estimar os custos associados a cada recurso e os possíveis danos causados
aos sistemas computacionais.
Em determinada instituição, por exemplo, o vazamento de informação sensível (senhas ou

informações financeiras) tem maior risco que a indisponibilidade do sistema de pagamento
e-commerce. Portanto, a identificação dos custos associados a cada recurso deve considerar
o modelo de negócio da própria instituição.
O custo de um recurso tipicamente considera fatores como: o prejuízo financeiro, tempo

para o restabelecimento e custo para reparado. Adicionalmente, devem-se avaliar os
ativos intangíveis. A tabela 3.1 exemplifica alguns recursos: Ativos intangíveis:
Recursos que não podem
Recursos tangíveis Recursos intangíveis ser tocados fisicamente,
mas que também
Dados sensíveis Reputação possuem valor asso-
ciado à instituição, tal
Computadores (servidores e desktops) Integridade de dados como a sua reputação.
Equipamentos de rede (roteadores e comutadores) Disponibilidade

Tabela 3.1
Softwares comerciais Informações de configurações
Exemplo de
recursos de uma
Arquivos de backup Senhas pessoais
instituição.
Existem diferentes metodologias para avaliação dos cursos e riscos associados aos
recursos de uma instituição.
De forma geral, a análise pode ser classifica entre avaliação quantitativa ou qualitativa. q
A análise de risco quantitativa é representa por números, ou seja, pela quantidade
monetária associada a um risco.
Geralmente essa informação é expressa em dólares, ou na moeda local, representando as

perdas financeiras anuais atreladas a cada risco. Existe uma fórmula que serve para deter-
minar os custos associados a cada análise de risco.
Risco = Probabilidade x Custo associado
Evidentemente, determinar a probabilidade e o custo associado de cada item envolve q

procedimentos mais elaborados que fogem do escopo deste curso (avaliação de riscos);
no entanto, a tabela a seguir ilustra um exemplo do cálculo de risco de determinados
recursos de uma instituição.
Recurso Probabilidade Custo Risco

Destruição de uma base de dados de clientes 0,005 $ 25,000,000 $ 125,000
Inacessibilidade do servidor web. 0,003 $ 38,000,000 $ 114,000
Sistema de cobrança corrompido 0,001 $ 18,000,000 $ 18,000
Comprometimento por malware 0,002 $ 7, 000,000 $ 14,000 Tabela 3.2

Análise de risco
Total U$ 271,000 quantitativa.
Outras metodologias de análise de riscos sugerem a classificação qualitativa, ou seja, repre- q

sentar os riscos associados com o seu respectivo nível de impacto: alto, baixo ou médio.
34
Em certos aspectos a classificação qualitativa é mais intuitiva e de fácil compreensão.
Na tabela a seguir, por exemplo, a análise quantitativa recém-apresentada é transcrita a
análise qualitativa.
Recurso Risco
Destruição de uma base de dados de clientes. Alto
Inacessibilidade do servidor web. Alto
Tabela 3.3 Sistema de cobrança corrompido. Médio

Análise de risco
qualitativa. Comprometimento por malware. Baixo
As duas metodologias para análise de riscos podem ser aplicadas no contexto de q

Cada qual com as suas vantagens e desvantagens. A análise quantitativa, por exemplo, con-
siste na ideia de calcular os valores associados a cada risco; no entanto, os valores utilizados
são apenas estimativas e não podem identificar precisamente o valor de cada risco. Por outro
lado, a análise qualitativa é subjetiva e carece de consistência na caracterização dos riscos.
Independentemente do método utilizado para avaliar os riscos, é fundamental que os

responsáveis pela segurança da instituição consigam identificar os recursos mais críticos da
instituição e que, em última análise, devem ser protegidos.
Sabe-se que a análise de risco é dinâmica. Novas ameaças estão constantemente surgindo,
fazendo com que ameaças antigas tenham o seu impacto potencial reduzido. A equipe do
CSIRT deve constantemente analisar as últimas ameaças e, também, reavaliar a classificação
dos riscos associados de maneira a tornar preciso o processo de resposta a incidentes.
Os dados relativos à análise de riscos podem ser utilizados em diferentes aspectos de um

CSIRT como, por exemplo, para compor os custos envolvidos com um incidente específico.
Nesses casos, estimar os valores associados a um incidente deve considerar todos os q

recursos impactados e também os diferentes esforços empreendidos para solucionar o
incidente. Na estimativa, devem-se considerar custos diretos e indiretos, tais como:
11 O custo estimado dos profissionais que atuaram na resposta e na investigação do inci-

dente (valor da hora do profissional multiplicado pelo número de horas trabalhadas);
11 A quantidade de horas, no total, que cada profissional empregou no incidente em si;
11 A quantidade de pessoas que foram privadas de suas atividades normais em decor-

rência do incidente de segurança;
11 A quantidade de horas produtivas, no total, que cada uma dessas pessoas impedidas
de trabalhar desperdiçou;
11 O custo estimado de cada profissional que ficou impedido de trabalhar.

Os diversos fatores apresentados neste capítulo buscam ilustrar os aspectos básicos da

análise de risco que podem ser utilizados para determinar os custos associados ao processo
de resposta a incidentes como um todo. Como consequência, o CSIRT pode identificar áreas
e tipos de incidentes que representam as maiores ameaças para a instituição.
35
11 Vulnerabilidade: fragilidade inerente de um sistema ou ambiente operacional, que q
pode ser explorado para causar dano a um sistema;
11 Ameaça: um agente (pessoal, atividade ou evento) com o potencial de causar dano a

um sistema ou ambiente operacional.
Ameaças associadas a segurança de sistemas

Este capítulo descreve as principais ameaças de segurança a sistemas computacionais.
De forma simplificada, as ameaças aos sistemas podem ser associadas a fatores naturais ou
fatores humanos (vide figura 3.1). As ameaças relacionadas com fatores naturais compre-
endem ações da natureza, como, por exemplo, tempestades, inundações, calor excessivo
etc. Como resultado, fatores naturais podem desencadear rompimento de fibra óptica,
queda de energia e mau funcionamento de equipamentos.
Ameaças de segurança
Fatores humanos Fatores naturais
Intenção Sem intenção Terremotos

Furacões
Tornados
Figura 3.1
Externos Internos Erros Diferentes ameaças
(cracker/hacker) (funcionários)
de segurança.
As ameaças relacionadas a fatores humanos, em especial, compreendem ações maliciosas ou

erros de utilização. Um erro de configuração no firewall da instituição, por exemplo, pode tornar
o acesso à instituição indisponível externamente. Por outro lado, ações mal-intencionadas
podem afetar os recursos de uma instituição de forma direcionada. Além dos externos à
instituição, uma organização sempre deve considerar ataques originados internamente por
seus próprios funcionários, tal como roubo de informações, ataque a recursos críticos e
ataques de engenharia social.
Em contraponto, os ataques externos tipicamente são executados por atacantes ou q

malwares escritos com a intenção de afetar sistemas específicos vulneráveis. Esses
ataques, em essencial, possuem diferentes motivações, sendo:
11 Demonstração de poder;
11 Prestígio;
11 Motivações financeiras;
11 Motivações ideológicas;
11 Vantagem competitiva;
11 Vingança;
11 Extorsão.
O cenário de riscos associados a incidentes de segurança atualmente é muito distinto.

É possível encontrar incidentes de segurança relacionados a ataques de diferentes níveis
de complexidade. Na sequência, são apresentadas as principais categorias de incidentes
frequentemente observadas no processo de resposta a incidentes.
36
Comprometimento de sistemas
O comprometimento de um sistema, ou uma invasão, acontece quando um atacante tem q
acesso não autorizado a um sistema, passando-se por um usuário legítimo. Geralmente
um comprometimento acontece ao nível de usuário, onde o atacante tem acesso às
mesmas informações disponíveis a um usuário específico, como acesso aos arquivos,
acesso a credenciais de acesso, histórico de comandos, histórico de navegação e outros.
Mesmo que dados ou programas não tenham sido alterados ou roubados, um comprome-
timento pode resultar em perdas para a instituição. Por exemplo, quando uma máquina
crítica é identificada como comprometida, é necessário instaurar um processo de investi-
gação que, muitas vezes, tornará o sistema temporariamente indisponível.
Evidentemente existem várias maneiras de comprometer um sistema computacional.
Um atacante pode comprometer um sistema compondo diferentes técnicas, usando, por

exemplo: engenharia social, arquivos maliciosos e vulnerabilidades de sistemas. Ataques
que exploram vulnerabilidades de aplicações tipicamente permitem que um atacante
execute comandos arbitrários no sistema vulnerável.
Dessa maneira, o atacante pode executar as mais diversas ações, como: apagar arquivos,
sobrescrever arquivos executáveis e ter acesso ao sistema de forma permanente.
Muitas vezes a efetiva exploração de vulnerabilidades permite acesso restrito ao sistema

atacado, ou seja, acesso não privilegiado. Nesses casos, quando o atacante não é capaz de
obter acesso privilegiado de imediato (root ou administrador), é necessário utilizar outras
técnicas. Tipicamente, uma vez no sistema, os atacantes buscam explorar outras vulnera-
bilidades de modo a “escalar privilégios”. Isso significa que outros ataques são executados
localmente até que o atacante tenha acesso privilegiado ao sistema.
Um comprometimento de sistema muito comum – onde se busca a exploração de vulnerabi-

lidades e posteriormente a elevação de privilégios – ocorre explorando falhas de aplicações web.
Atualmente existe grande quantidade de aplicações web que podem ser facilmente insta-
ladas, como ferramentas de blog, gerenciamento de sistemas, gerenciadores de conteúdos
e outros. Infelizmente, algumas soluções primam pela praticidade e facilidade de instalação
e, muitas vezes, os aspectos de segurança ficam em segundo plano. Falhas na especificação
ou na implementação desses aplicativos podem permitir que atacantes comprometam o
sistema de diferentes maneiras, incluindo a execução de programas (malwares), alterando o
conteúdo de páginas, acessando arquivos e diretórios do sistema e, por fim, obtendo acesso
privilegiado ao sistema.
Sabe-se que um sistema comprometido é muito valioso para um atacante. Com acesso total
a um sistema, um atacante pode coletar informações sensíveis de uma instituição e também
efetuar os mais diversos tipos de ataques a outras organizações. A figura a seguir ilustra
algumas ações que um atacante pode realizar com um sistema comprometido.
37
phishing phishing
repositório de malware propagação de malware
dados com copyright servidor web malware pirataria
pornografia infantil pornografia infantil
spam spam
cartões de crédito
webmail
e-commerce
engenharia social
ataques e-mail credenciais sistemas de pagamento
acesso ao e-mail coorporativo
sistemas de milhagem
contas de e-mail associadas
sistema webmail institucional
personagens de jogos online comprometido bitcoin / webmoney
recursos de jogos online phishing
licenças de jogos bens virtuais financeiro paypal / pagseguro
licenças de sis. operacionais fraude de clique
facebook facebook
twitter documentos
reputação sequestro info.
linkedin flickr
google+ instagram
Phishing Figura 3.2

Possíveis abusos
Phishing é uma técnica utilizada por golpistas cujo objetivo é obter informações a sistemas
financeiras ou pessoais da vítima. Dessa maneira, os golpistas podem obter ganhos comprometidos.
financeiros, ou ainda, valer-se de dados pessoais para tirar vantagem pessoal tal como:
roubo de identidade e uso das informações para lançar novos ataques personalizados.
Os ataques de phishing mais conhecidos são os quais um atacante induz usuários a acessar
um site clonado de uma instituição financeira, de modo a coletar suas credenciais de acesso.
No entanto, existem mais sofisticados, onde um usuário é induzido a instalar um programa
malicioso com o objetivo de coletar dados sensíveis do sistema.
Além dos phishings voltados para instituições financeiras, um conjunto de serviços é q

igualmente visado:
11 Credenciais de serviços: e-mails, redes sociais ou armazenamento;
11 Programas de milhagem (companhias aéreas ou redes de supermercados);
11 Comércio eletrônico;
11 Notificações de multas, débitos ou compras;
11 Webmail corporativo.
Para isso, os atacantes fazem uso de diferentes técnicas, de modo a induzir um usuário a
fornecer os seus dados pessoais inadvertidamente.
Entre as principais técnicas utilizadas em ataques de phishing, podemos citar: q

11 Modificações nos links de redirecionamento embutidos na mensagem;
11 E-mails baseados em HTML, utilizando ofuscação de informação da URL;
11 Incluindo encurtadores de URLs;
11 Mensagens personalizadas, incluindo dados pessoais como nome completo e CPF;
11 Mensagens falsas, usando cabeçalhos das mensagens alterados (From).
O grupo de resposta CAIS/RNP mantém um catálogo de fraudes relacionado a institui-

ções brasileiras, sendo possível obter exemplos reais de fraudes utilizadas por golpistas:
http://www.rnp.br/cais/fraudes.php
38
Desfiguração
A desfiguração de site, ou web defacement, é um ataque cujo objetivo é alterar sem q
autorização o conteúdo de uma página web.
A alteração de uma página, em última análise, representa um comprometimento do sistema.

Afinal, a alteração do conteúdo de uma página envolve a escrita no sistema de arquivo da
própria máquina.
Sendo assim, um ataque de desfiguração pode trazer sérias consequências à instituição, q

entre elas:
11 Constrangimento: uma instituição que tem sua página web alterada inadvertidamente
pode ter sua imagem de confiabilidade afetada. Já um website constantemente com-
prometido pode refletir o descaso com que as informações críticas de uma instituição
são tratadas;
11 Disseminação de inverdades: alterações sutis no website podem resultar em conse-

quências negativas para a instituição. Por exemplo, alteração de preços de produtos,
telefones de contato – ou editar um comunicado para a imprensa – podem trazer
inúmeros prejuízos;
11 Prejuízos de serviços: a alteração de um site pode indisponibilizar serviços pres-

tados pela instituição.
Boa parte dos ataques do tipo defacement é realizada de forma automatizada. Existem
ferramentas especializadas em identificar aplicações web populares vulneráveis – tal como
Wordpress e Joomla – de modo a explorar falhas de segurança e alterar o conteúdo da
página. Portanto, em cenários onde aplicações de gerenciamento de conteúdo são utili-
zados, é fundamental redobrar os cuidados de segurança mantendo o sistema atualizado.
Ataques de força bruta

É um tipo de ataque onde se busca descobrir as credenciais de acesso a um sistema através
de tentativas. Para isso, um atacante utiliza diferentes palavras como possíveis senhas para
identificar a combinação correta de usuário e senha.
Existem diferentes técnicas para compor as credenciais a serem testadas nos sistemas. q
Captcha: As mais conhecidas são:
Teste de Turing público
11 Busca exaustiva: nesse tipo de ataque, todas as possibilidades são testadas.
completamente auto-
matizado para distinguir Por exemplo, a combinação de todos os caracteres de um alfabeto com diferentes
computadores de seres tamanhos de senhas;
humanos. Também são
conhecidos como um 11 Ataque de dicionário: as palavras utilizadas para o ataque são oriundas de dicioná-
tipo de prova intera- rios específicos, ou seja, um subconjunto de palavras, tal como palavras de um idioma
tiva humana (Human
específico ou ainda as senhas mais comuns.
Interaction Proof - HIP).
Geralmente, é gerada
Todos os métodos criptográficos de autenticação baseados em senhas são vulneráveis a

uma imagem com várias
letras distorcidas no esses tipos de ataques. A viabilidade de tais ataques depende basicamente da quantidade
formulário de um site. de recursos disponíveis para o atacante, que pode acelerar o processo, realizando vários
O usuário então precisa
testes em paralelo.
digitar a série correta
de letras em um campo,
Para evitar esse tipo de ataque, determinadas aplicações implementam políticas de pro-
para provar que não é
uma máquina tentando teção. Por exemplo, limitando o número de tentativas por usuário ou ainda implementando
burlar o sistema. mecanismos que impedem a automatização das tentativas, como o captcha.
39
Varredura em redes (Scan)
Scan, ou varredura, é uma técnica utilizada para mapear informações de sistemas q
computacionais. Existem diferentes tipos de varreduras que podem ser utilizadas
para obter informações detalhadas de recursos, tal como: serviços sendo executados;
sistemas ativos; versões de aplicações; e, até mesmo, identificar vulnerabilidades em
sistemas-alvo. Para isso, existe um conjunto de ferramentas especializadas na tarefa de
identificação, varredura e enumeração de serviços disponíveis:
11 Varredura de portas: buscam informações de portas abertas em servidores;
11 Enumerador de redes: identifica servidores acessíveis;
11 Varredura de vulnerabilidade de redes: vulnerabilidade em serviços e redes;
11 Varredura de segurança para aplicações Web: vulnerabilidades em aplicações web.
Quando não autorizada, uma varredura potencialmente é considerada maliciosa.
Sabe-se que uma das etapas para o comprometimento de um sistema é elencar informa-
ções sobre o alvo (serviços, Sistema Operacional e suas respectivas versões). Logo, uma
varredura pode ser uma etapa inicial de um possível ataque ou, ainda, ser ocasionado por
um atacante tentando identificar possíveis alvos vulneráveis.
Negação de serviço (DoS e DDoS)

Um DoS – negação de serviço – é um ataque cujo objetivo é tornar o sistema q
computacional inacessível.
Tipicamente, um ataque de negação de serviço tem como alvo servidores web, mas podem
também alvejar servidores de e-mail, servidores de nomes (DNS) e outro tipos de serviços.
O ataque consiste em exaurir recursos de um alvo a fim de torná-lo inacessível. Na prática,
uma negação de serviço sobrecarrega um alvo fazendo grande quantidade de requisições.
Essas requisições podem ser pacotes de dados simples ou uma série de requisições custo-
mizadas. Para que o ataque tenha sucesso é necessário sobrecarregar algo com recursos.
Quando o alvo atacado não consegue processar o volume de requisições ou ainda a banda
de rede tenha sido exaurida, o alvo fica inacessível.
Um engano comum é assumir que um ataque de negação de serviço altera a integridade dos
dados, ou seja, que compromete o sistema atacado.
Portanto, um ataque de negação de serviço destinado a um serviço de banco de dados não

afetará a base de informações do servidor, mas sim o acesso ao serviço.
Uma negação de serviços pode ser inicializada por uma única máquina, mas tipicamente
é realizada utilizando múltiplas máquinas de forma coordenada. Um ataque de negação

usando múltiplas máquinas atacando um único alvo leva o nome de ataque de negação de
serviços distribuído, ou D.D.o.S. A Figura 3.3 ilustra uma negação de serviços distribuída.
40
Figura 3.3
Negação de
serviço distribuída:
múltiplas máquinas.
Nos últimos anos, os ataques de negação de serviço tornaram-se populares. Como comen-
tado, por utilizarem grande quantidade de máquinas – tipicamente comprometidas – esses
ataques são muito eficazes.
Sites como Twitter, Visa e PayPal já foram afetados por ataques de negação de serviço.
Em alguns contextos, no entanto, o ataque de negação de serviço pode ser realizado como
um recurso de ciberativismo. Nesses casos, não são utilizadas máquinas comprometidas,
mas sim voluntários. No ano de 2012, um grupo de ativistas – ou o coletivo denominado
Anonymous – ganhou notícia por atacar diversos websites utilizando técnicas de negação de
serviço distribuídas (D.D.o.S). Esses ataques, na sua maioria considerada como ciberati-
vismo, foram lançados contra diferentes instituições financeiras e também contra órgãos
governamentais. Para isso, algumas ferramentas foram utilizadas por voluntários de forma
a atacar os alvos. Uma das ferramentas mais utilizadas pelo Anonymous foi a ferramenta
Low Orbit Ion Cannon (LOIC) e suas variações, que disparavam muitas requisições a um
website específico.
Figura 3.4
Vida de
Programador
Fonte: http://
vidadeprogramador
.com.br/
41
Malwares
Malware é um nome genérico para definir os diferentes tipos de códigos maliciosos. q
São softwares desenvolvidos especificamente para causar danos aos sistemas, incluindo
computadores, redes ou até mesmo em dados.
A denominação malware comumente é empregada para se referir a vírus, worms, spywares,

trojans em geral e todo e qualquer software potencialmente malicioso.
Existem diferentes formas de um malware comprometer um sistema. Malwares podem

infectar sistemas embutindo-se em programas, anexando-se em mensagens de e-mails e pro-
pagando-se automaticamente. Outros malwares, porém, são instalados explorando vulnerabi-
lidades conhecidas em um sistema operacional ou em outros softwares, tal como um browser
vulnerável que acessa um website com um applet malicioso. A grande maioria dos malwares,
entretanto, é executada por usuários incautos induzidos a instalar programas legítimos.
Na sequência, são descritos os principais tipos de malwares amplamente encontrados
na rede.
Vírus
Os vírus são programas com a capacidade de autorreplicação, que se propagam através da
ação do usuário. Uma vez executados, fazem cópias de si mesmos buscando espalhar-se
para outros sistemas.
Geralmente os vírus infectam sistemas de arquivos, aplicações e macros de programas.

Atualmente, no entanto, os vírus não são muito notáveis. Em parte, isso se deve ferramentas
de antivírus que impedem a propagação dos vírus e também à mudança de motivação dos
desenvolvedores de vírus.
Trojans
É um tipo de software que aparenta ser legítimo, mas na realidade é um malware projetado
para comprometer um Sistema Operacional.
Um trojan tenta enganar um usuário disponibilizando funcionalidades desejadas, no

entanto, além de realizar as funcionalidades desejadas, o trojan contém funções mali-
ciosas que são executadas quando o software é executado.
Tipicamente, após a sua execução, um trojan realiza uma série de ações. Entre as ações
desempenhadas por um trojan está o download de novos malwares para o sistema e a ins-
talação de novas funcionalidades maliciosas, tal como ferramentas de negação de serviço,
propaganda, envio de spams, armazenamento de teclas digitadas e outras.
Alguns exemplos de trojans: q

11 Cracker: ferramenta para ativar softwares que, além de ativar o software, compro-
mete o sistema, instalando novos malwares;
11 Plug-ins: software que tenta passar por um plug-in (flash, segurança bancária) para
ter acesso ao sistema;
11 Proteção de tela: arquivos do tipo “.scr” que instalam uma proteção de tela, mas
também comprometem o sistema;
11 Jogos: pequenos jogos gratuitos que quando executados comprometem o sistemas.
42
Os trojans são ainda mais efetivos quando executados com privilégios de administradores
de sistema. Dessa forma, módulos de funcionalidades maliciosas podem ser inseridos no
Sistema Operacional base.
Ao contrário dos vírus e worms, os trojans não infectam computadores usando técnicas de
autorreplicação.
Necessitam da ação de um usuário para propagar-se para outros sistemas. Comumente são
encontrados em anexos de e-mails e em sites falsos que tentam enganar a boa-fé do usuário.
Figura 3.5
CUIDADO!!!
Fonte: http://xkcd.
com/1247/
Worms
Diferentemente dos vírus, um worm não necessita de uma ação do usuário para autorre- q
plicar-se. Além de fazer cópias de si mesmo, os worms têm a capacidade de propagar-se
para outros sistemas explorando vulnerabilidades existentes nos mesmos sistemas.
Adicionalmente, os worms podem ter outras fontes de propagação, tal como: anexar-se a
mensagens de e-mails; propagar-se em compartilhamento de redes; enviar-se em pro-
gramas de mensagens instantâneas; e até mesmo utilizar redes sociais para se propagar.
Mesmo não alterando arquivos do computador, como os vírus, os worms tipicamente

consomem recursos do sistema, como memória, espaço em disco e uso de rede, inviabili-
zando muitas vezes a operação normal do Sistema Operacional. Por exemplo, o primeiro
worm de que se tem notícia, o Moris Worm, utiliza vulnerabilidades dos serviços sendmail,
finger e rsh para autopropagar-se. Outro caso notável de malware foi o worm “ILOVEYOU”,
que infectou milhões de máquinas enviando cópias de si mesmo para a lista de contatos
da máquina comprometida.
l
Backdoor
Em um passado É um software que permite acesso a um computador sem usar os mecanismos de
recente, alguns worms autenticação presentes no sistema.
– como o Code Red –
caracterizavam-se por
Geralmente, os malwares do tipo backdoor são utilizados por atacantes para garantir o seu
instalar backdoors em
máquinas comprome- retorno ao sistema comprometido de forma direta, sem a necessidade de explorar novamente
tidas. Malwares como o vulnerabilidades ou utilizar senhas de usuários previamente identificadas.

worm Nimda, por
exemplo, utilizavam o Muitas vezes um atacante substitui um programa de acesso remoto por um novo programa
backdoor deixado pelo
malicioso. Por exemplo, em alguns comprometimentos observa-se que os atacantes alteram
Code Red como uma
forma de propagação. o software SSH (sshd) para um sshd alterado. Dessa forma, o acesso de um determinado
usuário será sempre permitido mesmo sem o usuário estar presente no sistema.
43
Alguns fabricantes de software inserem de forma proposital backdoors em seus sistemas,
sob a alegação de necessidades administrativas. No entanto, um backdoor no sistema –
mesmo sendo considerado legítimo – é uma ameaça à segurança do Sistema Operacional e
também para a rede como um todo. Uma vez que sejam identificados os requisitos para o
uso do backdoor, este pode ser utilizado para as ações maliciosas.
Ataques a serviços web

O ataque a aplicações web é uma das principais maneiras de comprometer sistemas com-
putacionais. Como se sabe, muitas aplicações foram portadas para a web, mas nem todas
observam com rigor os requisitos mínimos de segurança. Esse cenário é potencializado
com massificação de soluções stand alone, que podem ser utilizadas para as mais diversas
tarefas, tal como gerenciador de conteúdo online, gerenciamento de fóruns web e frond-ends
para gerenciamento. O problema não está em usar soluções prontas, mas sim na utilização
destas sem a preocupação de segurança. É muito comum observar essas ferramentas
sendo executadas sem a correta configuração de segurança e sem as devidas correções de
vulnerabilidades conhecidas (patchs de segurança).
A exploração de uma vulnerabilidade de uma aplicação web permite a um atacante ter

acesso à área do servidor que, muitas vezes, através da elevação de privilégios, pode dar
acesso administrativo ao atacante. Mesmo sem acesso de administrador, um atacante pode
alterar o conteúdo de uma página web (defacement) e realizar os mais diversos tipos de
ataques, como por exemplo:
11 Inserir um link malicioso em uma página fazendo com que todos que acessarem a
página alterada sejam direcionados para efetuar um download de um arquivo malicioso
(driven-by-download);
11 Substituir os arquivos existentes por páginas falsas de bancos utilizadas em ataques

de phishing;
11 Expor dados sensíveis armazenados na base de dados do servidor usando as mesmas

credenciais da aplicação (sql injection).
As possíveis vulnerabilidades de aplicações web são as mais diversas, podendo ir de simples

erros de configuração a, até mesmo, ataques complexos que permitem o roubo de sessões
do usuário. Anualmente é disponibilizada uma lista das principais vulnerabilidades encon-
tradas em aplicações web.
Essa lista é mantida pela organização Open Web Application Security Project (OWASP), que
tem como objetivo aprimorar a segurança de softwares: https://www.owasp.org
Bots e Botnets
São malwares que permitem que o sistema comprometido seja controlado remotamente
através de uma estrutura de administração. Assim que o malware é executado, é estabele-
cido um canal de comunicação com o controlador da rede (botmaster). O canal de comuni-
cação entre o botmaster e o sistema comprometido pode ser implementado de diferentes
formas, valendo-se de diferentes tecnologias:
11 Protocolo Internet Relay Chat (IRC);
11 Protocolo HTTP;
11 Túneis com protocolos cifrados;
11 Protocolo P2P.
44
Uma vez que a comunicação com a entidade de administração seja estabelecida com
sucesso, o sistema comprometido torna-se apto a receber comandos e instruções do contro-
lador da rede. Invariavelmente, o malware (bot) apresenta um conjunto de funcionalidades
pré-programadas que podem ser invocadas remotamente pelo botmaster.
As ações desempenhadas pelas botnets, em geral, são danosas à estrutura da internet.
As botnets são responsáveis pelas mais diversas atividades maliciosas, tais como: q
11 Envio de spam;
11 Varredura ou propagação;
11 Ataques de negação de serviços;
11 Distribuição de malwares;
11 Furto de identidade (credenciais de acesso);
11 Furto de dados sensíveis (espionagem industrial).
Além disso, os bots possuem, na maioria dos casos, a opção de atualização remota. Com
isso, novas funcionalidades podem ser incorporadas aos bots sem a necessidade do contro-
lador da rede ter de comprometer novas máquinas.
Uma forma de potencializar os ataques das máquinas comprometidas é constituir uma rede
de bots, ou seja, uma botnet. Uma botnet nada mais é que um conjunto de bots conectados
em uma mesma estrutura administrativa.
Dessa forma, um conjunto de máquinas comprometidas pode ser coordenado de modo a

lançar ataques remotamente.
Outros riscos
Encontrar uma abordagem efetiva para identificar e proteger a vasta coleção de sistemas
vulneráveis é uma luta contínua no contexto da ciberdefesa. Certas tecnologias – como
virtualização, dispositivos móveis e computação em nuvens – tendem a fornecer novas
funcionalidades e aprimoramentos aos sistemas computacionais. Por outro lado, cada nova
tecnologia também introduz complexidade adicional que pode ser potencialmente explo-
rada e causar prejuízos aos sistemas existentes na instituição.
Algumas instituições simplesmente ignoram – ou não classificam como irrelevantes – as

ameaças introduzidas pelas novas tecnologias. Outras, porém, preferem terceirizar o tra-
tamento dessas novas ameaças utilizando soluções de terceiros, mesmo sem ter noção do
nível de segurança implementado por essas soluções de terceiros.
Sabe-se que um processo de identificação de incidentes deve ser abrangente o suficiente

para lidar com os mais diversos tipos de ameaças. Em etapas iniciais, muitos CSIRTs optam
por ter foco nas ameaças possivelmente mais relevantes para o contexto de sua instituição.
Por outro lado, não se devem esquecer novas ameaças, como as Advanced Persistent Threat
(APT), que em um primeiro momento pode não ser relevante, mas que são latentes.
Para isso, é importante que os membros da equipe criem uma perspectiva de como q
reconhecer as novas ameaças e como as estas podem impactar sua organização.
É fundamental:
11 Reconhecer e categorizar novas ameaças;
11 Planejar e estar preparado para responder;
11 Educar e auxiliar outros quando necessário.
45
Os ataques sofisticados são lançados por atacantes com alto nível de especialização técnica.
Esses atacantes, ou cibercriminosos, geralmente possuem motivações financeiras. Um dos
modelos de negócio altamente lucrativos compreende o roubo de informações sensíveis
de instituições. Sendo assim, os atacantes utilizam ataques coordenados em busca de
informações que julgam relevantes, como números de cartões de crédito, contas bancária e
credenciais de acesso contendo informações que sejam valoráveis.
Atualmente, a defesa cibernética deve enfrentar grandes desafios, entre os quais: q

11 Os atacantes têm aumentado significativamente a motivação com ganhos financeiros;
11 Empresas criminosas estão competindo por talentos.
Profissionais com alto nível técnico e que possuem padrões éticos flexíveis estão encon-
trando cada vez mais oportunidades em empresas de espionagem. Observam-se, também,
a atuação desses profissionais com ética questionável atuando em empresas de contrainteli-
gência com o cargo de “consultor de segurança”.
Nesse contexto, cabe aos profissionais de segurança adaptar e preparar sua organização de
modo a evitar que ataques sofisticados sejam efetivos. Para isso, é necessário que o CSIRT
não tenha foco apenas em questões técnicas e operacionais, mas sim na implementação de
uma cultura de segurança em todos os departamentos da instituição.
APT
O Advanced Persistent Threat (APT) pode ser caracterizado por ataques que utilizam téc- q
nicas avançadas para comprometer um alvo específico. Em geral, as APTs são ameaças
bem específicas que se destinaram a alvos de grande valor, tal como instalações
governamentais, empresas de petróleo, companhias de segurança e produtos de alta
tecnologia. A motivação não é apenas ter acesso aos sistemas de uma instituição, mas
sim manter o acesso de forma persistente por um longo período de tempo. Um exemplo
clássico de APT são casos de ciberespionagem, onde uma empresa busca monitorar
informações sensíveis de um concorrente a fim de obter vantagens comerciais.
Nesses casos mais complexos, os atacantes investem meses para preparar um ataque a um
alvo específico. Nesse período, os detalhes do alvo são estudados e softwares específicos
são desenvolvidos com a finalidade de comprometer o alvo. Utilizando diferentes fontes de
informação, é possível adquirir melhores percepções sobre o alvo e utilizar a inteligência
obtida para lançar múltiplos ataques durante um longo período.
Uma característica fundamental para as APTs é permanecer invisível durante a operação. q

Como tal, os atacantes utilizam técnicas avançadas, tipicamente atuando em etapas incre-
mentais, movendo a partir de uma máquina comprometida. Dessa forma, busca-se evitar que
assinaturas de tráfego sejam identificadas. Os atacantes empenham massivos esforços para

assegurar que ações maliciosas não possam ser mapeadas pelos administradores legítimos
do sistema comprometido.
De forma resumida, as APTs têm as seguintes características: q

11 Utilizam ferramentas customizadas e técnicas de intrusão que compreendem o uso
de exploits e rootkits desenvolvidos especificamente para atacar a instituição-alvo;
11 Permanecem por um longo período na instituição-alvo e atuam de forma discreta

para evitar detecção;
11 Implementam ações de espionagem, sabotagem e, geralmente, envolvem funcionali-

dades que ocultam os autores do ataque.
46
Os ataques lançados a um alvo específico podem ser compostos com diferentes vetores
de ataques, podendo usar desde técnicas de engenharia social até o desenvolvimento de
malwares que exploram múltiplas vulnerabilidades desconhecidas (zero-days exploits).
Os malwares, em especial, são desenvolvidos usando técnicas avançadas de ofuscação,
o que dificulta a sua detecção por parte dos sistemas de antivírus.
Boa parte dos malwares utilizados em APTs, além de serem difíceis de ser detectados, q
implementam técnicas que permitem a administração remota dos sistemas compro-
metidos. Atacantes valem-se dessa capacidade de controle remoto de modo a utilizar o
sistema comprometido para:
11 Comprometer novos sistemas;
11 Identificar alvos importantes;
11 Identificar a topologia da rede;
11 Ter acesso a informações críticas.
Se um ataque do tipo APT não conseguir contatar os seus operadores, as informações e toda
a inteligência capturada não podem ser transmitidas, o tornando inefetivo. Sendo assim,
são utilizadas diferentes técnicas para ter acesso aos dados de uma instituição, como por
exemplo: túneis, envio de dados em e-mails, esteganografia, requisições HTTP (POST/GET),
entre outros.
Para pensar
Do ponto de vista operacional, as APTs possuem o funcionamento muito semelhante a

uma botnet. Apesar de usarem diferentes vetores de ataques e funcionalidades espe-
cíficas, as APTs comprometem máquinas internas e estabelecem um canal de controle
e comando de modo a controlar dispositivos e exportar dados da instituição.
Tendo em vista esse conjunto de ameaças sofisticadas, cabe aos CSIRTs adaptarem-se
para atuar e identificar incidentes de segurança relacionados aos APTs e prover uma
resposta efetiva.
Nos últimos anos, as ameaças do tipo APTs ganharam muita publicidade. O ataque mais
notável envolvendo APTs foi o Stuxnet, realizado em 2010. O objetivo do ataque era corromper
o programa nuclear do Irã e, como pôde ser observado, foi empregado um grande esforço e
sério investimento.
l O Stuxnet demonstrou como diferentes ameaças podem ser combinadas para sobressair q
Embora não oficial-
mente reconhecido, a múltiplas camadas de segurança. O ataque foi realizado utilizando diferentes etapas.
acredita-se que o A primeira etapa do ataque consistia em fazer com que um computador da rede
ataque foi planejado
interna do alvo executasse um arquivo malicioso especialmente desenvolvido para a
pelos Estados Unidos

em conjunto com Israel. operação. Estima-se que foram utilizadas diferentes técnicas para induzir a execução
do malware internamente:
11 Técnicas de engenharia social;
11 Dispositivo USB infectado;
11 E-mail com links maliciosos;
11 Phishing;
11 Sabotagem.
47
Não se sabe ao certo a técnica utilizada. De qualquer forma, o malware foi executado com
sucesso em um computador interno da instituição-alvo, sem ser detectado por ferramentas
de segurança. O Stuxnet então utilizava de algumas vulnerabilidades do tipo zero-day – mais
especificamente quatro vulnerabilidades zero-day – para comprometer o sistema e tomar
controle do sistema Windows do computador utilizado. Sabe-se que as vulnerabilidades
zero-day são falhas de segurança geralmente não conhecidas e que ainda não existe correção
disponibilizada para sua remediação. A análise do malware identificou que os arquivos foram
construídos unicamente para o ataque em particular, sendo difíceis de serem identificados.
Após a execução do malware na rede interna alvo, um conjunto de etapas foi utilizado até
que o objetivo do ataque fosse atingido. A primeira etapa consistia em obter acesso à rede
interna da Usina Nuclear Iraniana. Para isso, foram utilizadas as características do próprio
malware desenvolvido. A partir do momento em que o malware teve acesso aos sistemas
confiáveis da rede interna, o Stuxnet começou a coletar informações e inicializou contato
com servidores de controle e comandos dos atacantes. Com isso, o Stuxnet pôde ser atuali-
zado e receber instruções de como proceder com o ataque.
Na etapa seguinte, o malware propagou-se para outros sistemas internos, utilizando métodos
combinados de ataque. Essa propagação continuou, até que fosse encontrado um sistema
Windows executando um controlador de rede específico (SCADA) do fabricante Siemens.
Quando encontrado, o Stuxnet utiliza uma senha padrão (hardcoded) do software da Siemens
para ter acesso à rede de equipamentos gerenciada pelo próprio controlador da Siemens.
A partir desse momento, o Stuxnet usou o controlador da Siemens para localizar disposi-
tivos que gerenciam o funcionamento das centrífugas atômicas da Usina Nuclear Iraniana.
Por fim, esses dispositivos que controlam as centrífugas foram atacados e reprogramados
de modo a afetar o funcionamento. Como consequência, as centrífugas foram danificadas,
afetando o processo de enriquecimento de urânio da Usina Iraniana.
O Stuxnet serve como um exemplo para que o CSIRT avalie o plano de resposta adequando
para essas novas ameaças APTs. Sem um plano de resposta devidamente testado, uma
organização não pode efetivamente detectar e responder o incidente de forma rápida o
suficiente para impedir que demais danos sejam causados.
11 Viega, John. The Myths of Security: What the Computer Security Industry Doesn’t Want
You to Know. O’Reilly, 2009;
11 Schultz, Eugene, and Russell Shumway. Incident response: a strategic guide to handling
system and network security breaches. Sams, 2001;
11 Radvanovsky, Robert S., and Allan McDougall. Critical infrastructure: homeland security
and emergency preparedness. CRC Press, 2009;
11 Cartilha de Segurança para Internet – CERT.br: http://cartilha.cert.br/
11 Sugestões para defesa contra ataques de força bruta para SSH:

http://www.cert.br/docs/whitepapers/defesa-forca-bruta-ssh/
48
4
Processo de tratamento
de incidentes
objetivos
Discutir a importância de ter um plano de resposta a incidentes de segurança;

Conhecer metodologias para o processo de resposta a incidentes; Entender
os conceitos relacionados ao processo de tratamento de incidentes.
conceitos
Ameaças e riscos de segurança; Sincronização e padronização da data e hora;
Classificação de incidentes.
Introdução
O processo de tratamento de incidentes de segurança consiste na implementação de q
procedimentos e etapas bem definidas que conduzirão a equipe para a resolução de um
incidente de segurança. O conjunto de etapas definidas permite determinar um fluxo
lógico especificando ações a serem realizadas nas diferentes etapas do processo.
Além de guiar a equipe para a resolução de incidentes, a utilização de procedimentos evita

que a equipe cometa falhas. Isso é essencialmente importante, sobretudo na resposta a inci-
dentes, onde consequências de ações implementadas pela equipe podem afetar a organi-
zação como um todo.
Neste capítulo, é descrita a importância de constituir um plano de resposta a incidentes e

ter um processo para atuar com os diversos incidentes de segurança. Para isso, é apresen-
Capítulo 4 - Processo de tratamento de incidentes
tada uma metodologia específica para a resposta de incidentes de segurança – denominada
PDCERF –, onde seus aspectos de implementação são discutidos, bem como considerações
relativas a cada etapa da metodologia. Por fim, o capítulo é finalizado com exemplos de
rotinas e procedimentos que podem ser utilizados em um CSIRT.
Para pensar
Emoção é um luxo custoso durante a crise. Sem foco e lógica para tomar decisões,
tempo precioso pode ser perdido.
49
Metodologia para resposta a incidentes
Metodologia define um processo a ser executado, ou seja, o conjunto de etapas que devem
ser seguidas para a resolução de incidentes. Utilizar uma metodologia de resposta a inci-
dente não garante o sucesso da operação em si; no entanto, tende a auxiliar nos seguintes
aspectos que margeiam o processo de resposta a incidentes:
11 Estrutura e organização: geralmente um CSIRT está envolvido com diferentes inci-

dentes, onde a complexidade, muitas vezes, tende a aumentar com a evolução da investi-
gação. Ter uma metodologia definida garante que os incidentes sejam tratados de forma
estrutura (segundo as etapas) e organizada de forma padronizada;
11 Eficiência: utilizar uma metodologia bem definida e assertiva para solucionar incidentes
impede que ações desnecessárias sejam implementadas;
11 Considerações legais: alguns incidentes são necessários à colaboração com as forças da

lei. A utilização de uma metodologia estabelecida pode auxiliar na preservação de provas
e também proteger o CSIRT de possíveis questionamentos.
No contexto específico de resposta a incidentes podem ser observadas algumas metodo-

logias descritas pela literatura. Uma das principais metodologias de resposta a incidentes
– denominada PDCERF – foi definida pelo Instituto de Engenharia de Software de Pittsburgh,
Pensilvânia, nos Estados Unidos, no ano de 1989.
A referida metodologia de resposta a incidente especifica diferentes etapas por onde um q

incidente deve fluir para que a sua resolução seja efetivada com sucesso, sendo:
1. Preparação: gerenciar as ferramentas para análise de incidentes, incluindo o conhe-

cimento de todo o ambiente utilizado;
2. Detecção: detectar o incidente, determinar o escopo e as partes envolvidas com

o incidente;
3. Contenção: conter o incidente de maneira a atenuar os danos e evitar que demais

recursos sejam comprometidos;
4. Erradicação: eliminar as causas do incidente, removendo todos os eventos relacionados;
5. Recuperação: restaurar o sistema ao seu estado normal;
6. Avaliação: avaliar as ações realizadas para resolver o incidente, documentando

detalhes, e discutir lições aprendidas.
3. contenção 4. erradicação
Figura 4.1
resposta a Metodologia
2. detecção incidentes 5. recuperação
de resposta a
1. preparação 6. avaliação incidentes de
segurança.
Na sequência, as diferentes etapas são descritas com mais detalhes, incluindo ações e
tarefas relacionadas a cada etapa. Por questão de organização, o detalhamento seguirá a
mesma ordem exemplificada na figura anterior.
50
Preparação
A etapa de preparação descreve aspectos que devem ser observados pela equipe do CSIRT antes
mesmo que um incidente de segurança seja identificado. O objetivo é preparar o CSIRT para
atuar prontamente na detecção e resolução de incidentes de segurança quando ocorrerem.
Algumas atividades relativas à etapa de preparação: q

11 Implementar mecanismos de defesa e controle de ameaças;
11 Desenvolver procedimentos para lidar com incidentes de forma eficiente;
11 Obter recursos e equipe necessária para lidar com os problemas;
11 Estabelecer infraestrutura de suporte à atividade de resposta a incidentes.
Na sequência, as atividades específicas de preparação são descritas com mais detalhes:
Mecanismos de defesa e controle de ameaças

Um CSIRT geralmente está inserido na infraestrutura de uma instituição. Mesmo utilizando
uma infraestrutura compartilhada.
É recomendável que o CSIRT tenha os seus próprios mecanismos de defesa e controle

das ameaças.
Por exemplo, o CSIRT pode ter uma subrede específica dentro da rede da instituição e, através
de mecanismos – filtros de acesso e firewall –, implementar uma barreira lógica para restringir
o acesso aos seus sistemas. O CSIRT deve estar preparado para ataques externos e também
ataques internos à infraestrutura em que está inserido.
Todos os serviços providos pelo CSIRT devem ter cuidado redobrado com a segurança.
Afinal, o comprometimento de sistemas do CSIRT é um incidente de segurança crítico, pois

tais sistemas contêm informações sensíveis da própria instituição e demais organizações
envolvidas com incidentes. Os sistemas e aplicações utilizados no processo de resposta a
incidentes também podem sofrer ataques. Logo, cabe à equipe do CSIRT gerir os sistemas
e dispositivos utilizados pelo time. Isso significa que as melhores práticas de configuração
segura devem ser implementadas pelo administrador de sistemas do CSIRT. O recomendado
é alocar recursos suficientes para efetuar um controle de segurança nos sistemas geren-
ciados sem restringir de maneira rígida sua funcionalidade.
Algumas medidas básicas de administração de sistemas: q

11 Política de senhas; Capítulo 4 - Processo de tratamento de incidentes
11 Analisar regularmente os logs gerados pelas ferramentas utilizadas;
11 Zelar pela integridade dos sistemas;
11 Realizar o backup dos sistemas;
11 Atuação e gerenciamento dos sistemas;
11 Configuração segura.
Procedimentos para atuar em incidentes

Como se sabe, os procedimentos podem ser descritos como rotinas operacionais que visam
auxiliar o CSIRT para que uma atividade seja realizada com sucesso.
51
Dessa maneira, os membros do time podem realizar tarefas de maneira organizada e mais
eficiente evitando que erros sejam introduzidos no processo.
Existem diferentes procedimentos que podem ser implementados por um CSIRT, conforme
anteriormente descrito. No contexto específico da resposta a incidentes, entretanto,
podemos citar procedimentos para desinfecção de uma máquina comprometida; testes de
vulnerabilidades; análise de arquivos maliciosos; e a investigação de eventos de segurança
em arquivos de logs. Dessa forma, são designadas ações a serem seguidas para cada tipo de
incidente de segurança identificado.
Incidente Método de detecção Procedimento de resposta
Notificação externa: servidor Isolar o servidor comprome-

Comprometimento de
comprometido está reali- tido para análise e notificar os
um servidor.
zando varreduras. responsáveis.
Desfiguração de Monitoração de integridade

Isolar o servidor para análise.
página web. de arquivos.
Tabela 4.1
Coordenar com equipe de Incidentes
Indisponibilidade do Monitoração de disponibili-
suporte e responsáveis pela e possíveis
site principal. dade do sistema.
infraestrutura de rede.
procedimentos.
Essa tabela descreve alguns incidentes, métodos pelos quais os incidentes podem ser detec-
tados pelas instituições e também possíveis medidas de contenção do incidente. Sabe-se, no
entanto, que os procedimentos são dinâmicos e devem ser aprimorados com o tempo e expe-
riência da equipe. Certos times optam por descrever procedimentos de maneira mais genera-
listas, identificando aspectos-chave que devem ser observados no decorrer do processo.
Infraestrutura para resposta a incidentes

A infraestrutura para resposta a incidentes refere-se aos recursos utilizados para dar
suporte ao processo de incidentes como um todo.
Em especial, quando atuando com múltiplos incidentes de segurança, se faz necessário usar
softwares que permitam gerenciar os incidentes sendo tratados.
Alguns times utilizam ferramentas especializadas no gerenciamento de incidentes, onde é

disponibilizada uma plataforma para acompanhar um incidente de segurança. Isso envolve
descrever detalhes do incidente, ações realizadas pelo CSIRT e prover ferramentas para
auxiliar na investigação do incidente identificado. Por outro lado, alguns CSIRTs desen-
volvem seus próprios sistemas de gerenciamento.
Entre os sistemas mais conhecidos estão os de trouble ticket. Esses sistemas são pla- q
taformas de acompanhamento de atividades, onde serviços são requisitados e geren-
ciados de forma centralizada. Boa parte das soluções de trouble ticket caracteriza-se por
implementar recursos como:
11 Identificador único: permite localizar um incidente na base de dados e também ser

referenciado por outros incidentes relacionados;
11 Tipo: descrevem informações sobre o incidente, tal como: invasão, vírus, comprome-
timento de sistema e outros;
52
11 Prioridade: qual foi a prioridade designada para o incidente; q
11 Responsável: pessoa que está atualmente gerenciando o incidente;
11 Status: o estado atual do incidente incluindo informações recebidas e demandas

a serem realizadas;
11 Última atualização: quando e quem alterou as últimas informações sobre o incidente.
Os sistemas de trouble ticket mais completos também auxiliam o CSIRT com atividades
operacionais inerentes ao processo de resposta a incidentes. Por exemplo, permitir o uso de
criptografia, suporte a diferentes codificações e idiomas (alfabeto chinês, japonês, polonês
ou russo). Da mesma forma, é possível encontrar ferramentas que permitem a exportação
das informações do sistema em diferentes formatos, em especial, formatos padronizados
para troca de informações de incidentes como o Incident Object Description and
IODEF Exchange Format (IODEF).
define um formato de
dados para descrever e Como exemplo, é possível citar a ferramenta RTIR. Essa ferramenta é uma plataforma de
intercambiar informa- código aberto para gerenciar sistemas de resposta a incidentes tendo como público-alvo
ções de incidentes de CSIRTs. A figura a seguir ilustra a interface da ferramenta RTIR.
segurança entre CSIRTs.
Figura 4.2
Interface da
ferramenta RTIR:
http://bestpractical.
com/rtir/Detecção
Detecção
O processo de detecção consiste em determinar a natureza do comprometimento,
disponibilizando detalhes dos sistemas comprometidos. A avaliação inicial dos inci-
dentes pode auxiliar na investigação de um incidente de modo a confirmar a existência
de um comprometimento e também das suas consequências.
De modo geral, a etapa de detecção deve contemplar: q

11 Sistemas e serviços afetados: identificar todos os sistemas e serviços afetados
relacionados com o incidente;
11 Impacto e risco: avaliar o impacto do incidente e os potenciais riscos dos sistemas

afetados (dados vazados, informações de instituições terceiras, impacto na própria
organização e impacto na reputação);
11 Eventos correlatos: identificar a existência de outros eventos e alertas relacionados

com o incidente em questão;
53
11 Mapeamento de dados: identificar que tipo de informação e processos podem ter q
sido afetados;
11 Responsáveis: os responsáveis pelo sistema comprometido, equipes de suporte e

donos das informações.
De fato, existem diferentes maneiras de detectar um incidente de segurança. Isso inclui

investigar as notificações de incidentes recebidos e também identificar proativamente
eventos de segurança suspeitos.
Devido à sofisticação dos ataques, alguns times fazem o uso de diferentes ferramentas q
projetadas especificamente para detectar eventos de segurança, tal como:
11 Sistemas de detecção de intrusão: ferramenta que inspeciona pacotes suspeitos e

conexões baseadas em assinaturas e heurísticas pré-definidas;
11 Filtros de Pacotes: ferramenta para filtrar tráfego de rede que permite bloquear ou
permitir um determinado tráfego;
11 Sistemas de análise de malware: avaliar o comportamento de um malware em um

sistema isolado de maneira a mapear um comportamento anômalo;
11 Sistemas de antivírus: avalia assinatura de malwares conhecidos e gera alerta infor-

mando o comprometimento de um sistema;
11 Sistemas de fluxos (sflow): permitem avaliar metadados de conexões de rede geral-

mente implementado em concentradores de rede;
11 Captura de pacotes: dados capturados em uma análise de uma máquina comprome-

tida (tcpdump) podem revelar características maliciosas;
11 Fontes externas: fontes públicas podem fornecer dados valiosos para a identificação
de incidentes (redes sociais, fóruns ou blogs).
Diversas soluções comerciais prometem alto nível de detecção; no entanto, cabe ao

CSIRT coordenar como essas soluções são aplicadas na rede e monitorar seus requi-
sitos de segurança. Além da configuração e monitoração, muitas soluções de segurança
requerem constantes atualizações. Certas soluções de segurança demandam atualizações
de assinaturas, do próprio Sistema Operacional, de aplicações, ou ainda do firmware
sendo executado. Por exemplo, uma solução de antivírus só é consideravelmente efetiva
com constantes atualizações das assinaturas e do software em si. Todas essas atividades
devem ser consideradas e fazer parte dos esforços do processo de resposta a incidentes.
Sabe-se que não existe uma solução de segurança pronta . É necessário customizar os
recursos tendo em vista as particularidades da sua rede.Alguns tipos de incidentes, no
entanto, não requerem softwares especializados para serem detectados. Apenas informa-
ções disponíveis nos diferentes sistemas de logs podem identiqficar uma atividade suspeita.
Na sequência são descritas atividades suspeitas que podem configurar um incidente q

de segurança:
11 Diversas tentativas de login: certos tipos de ataques utilizam técnicas de força

bruta para ter acesso privado a sistemas;
11 Tentativas de acesso a contas de sistemas ou inexistentes: o acesso a essas

contas revelam um comportamento no mínimo suspeito e deve ser investigado;
11 Atividades em horários anormais: alta utilização da rede ou conexões externas em

horários não convencionais podem revelar atividades suspeitas;
54
11 Integridade do sistema: existem algumas ferramentas que verificam a integridade q
de programas de sistemas. Em alguns comprometimentos, programas legítimos dos
sistemas são substituídos por outros com carga maliciosa (ssh, su ou login);
11 Lacunas nos logs: é uma clara indicação que o sistema foi comprometido e certas ati-
vidades foram excluídas dos logs para mascarar a presença do atacante no sistema.
Além de identificar um incidente de segurança, faz parte da etapa de detecção obter mais
detalhes de um incidente e até mesmo correlacionar eventos de segurança sob um aspecto
mais amplo.
Isso significa que o CSIRT pode configurar seus recursos de modo a obter maior grau de q
detalhamento dos eventos envolvidos em um incidente de segurança, tal como:
11 Incrementar o nível de monitoração de ferramentas de segurança de maneira a obter

mais informações para serem investigadas;
11 Copiar as informações do sistema comprometido, incluindo artefatos do invasor e

demais provas. Dessa maneira, não se corre o risco do atacante remover evidências
que podem ser utilizadas para análise e em questões legais;
11 Documentar todos os procedimentos realizados, incluindo todas as evidências de

comprometimento identificadas pelo investigador. Na etapa de detecção, pequenos
detalhes aparentemente irrelevantes podem ser fundamentais nas etapas poste-
riores de análise.
Como resultado, após o processo de identificação e análise dos incidentes investigados,

pode-se ter uma visão preliminar do impacto do incidente na instituição. Sabe-se que
estimar o real escopo do incidente permite que a equipe possa direcionar esforços e iden-
tificar que tipos de incidentes devem ser priorizados. Cada CSIRT implementa sua própria
política de priorização.
A seguir, alguns pontos que devem ser considerados no processo de priorização de q

um incidente:
11 A quantidade de computadores e serviços que foram afetados pelo incidente detec-

tado. Diferentes métodos de intervenção podem ser empregados dependendo de
quão espraiado está o comprometimento;
11 O nível de privilégio obtido pelo atacante nos sistemas comprometidos: por exemplo,
se o atacante conseguiu ter acesso a usuários privilegiados (administrador, root) ou
que usuários foram comprometidos;
11 A criticidade dos sistemas comprometidos. Identificar se algum sistema comprome- Capítulo 4 - Processo de tratamento de incidentes
tido pode afetar a operação regular da instituição;
11 Os meios utilizados para o comprometimento dos sistemas, tal como a aplicação

atacada e vulnerabilidade explorada;
11 O nível de disseminação das informações sobre o incidente. Muitas vezes a propa-

gação de informações sobre um incidente pode repercutir negativamente com os
clientes ou parceiros da instituição afetada.
Invariavelmente, quando um incidente de segurança é detectado, existe a necessidade de

interagir com as partes envolvidas. Nesse processo, a comunicação em si é crítica. Torna-se
necessário identificar fatores-chave e fatores essencialmente necessários, que devem ser
informados para as partes envolvidas.
55
Os elementos básicos de uma notificação de incidente tipicamente compreende: q
11 Informações básicas: descrição do incidente, incluindo o tipo do ataque identificado,
motivação aparente do ataque, Sistema Operacional ou serviço afetado pelo inci-
dente, possível origem do ataque e horário;
11 Informações específicas do ataque: versão do serviço ou sistema comprometido,

fragmento do log que descreve o ataque em si, protocolo utilizado no ataque e vulne-
rabilidade explorada;
11 Consequências: todas as consequências do ataque identificadas e possíveis ameaças,

tendo em vista o grau de comprometimento do incidente. Por exemplo, o atacante
obteve acesso privilegiado a um servidor de banco de dados da empresa. Embora não
se tenha identificado o acesso à base de dados, esta pode ter sido copiada;
11 Status: situação atual do incidente, incluindo ações realizadas nos serviços

e sistemas comprometidos.
Além dessas informações, outros dados podem complementar a notificação. Uma noti-
ficação bem detalhada auxilia na investigação e resolução do incidente. Cabe lembrar,
entretanto, que nem sempre todas as partes envolvidas necessitam saber os detalhes do
incidente, sobretudo entidades externas à instituição. Em alguns casos, podem-se utilizar
notificações com diferentes níveis de detalhamento, tendo em vista o público-alvo.
Contenção
A etapa de contenção tem por objetivo limitar ou atenuar os danos causados por um inci-
dente de segurança previamente detectado. Com a implementação de medidas de contenção
deseja-se evitar que um dado incidente afete os demais recursos da instituição ou, ainda,
impeça o funcionamento de serviços críticos.
Do contrário, caso as ações de contenção não sejam implementadas, um atacante pode: q

11 Obter controle de aplicações ou novos sistemas na rede local;
11 Remover dados do sistema de arquivos: remover evidências dos logs ou ainda obter
informações sensíveis e valiosas para a instituição;
11 Lançar ataques externos destinados a outras instituições ou, até mesmo, conectar a
um controlador de botnet.
A contenção deve fornecer uma solução de segurança razoável até que informações
suficientes sejam obtidas para a resolução do incidente de maneira definitiva.
Afinal, nem sempre é possível ter visão precisa do incidente no instante seguinte em
que é detectado. Ações de contenção geralmente são realizadas de forma rápida e de
maneira paliativa. Mesmo assim, tais ações não devem ser subestimadas. Existem inci-
dentes que podem sair do controle facilmente, como a propagação de um worm em uma
instituição. No emblemático caso do worm Slammer, o malware infectou 90% das máquinas
vulneráveis na internet nos primeiros dez minutos de atuação.
Diferentes ações podem ser realizadas para diminuir os danos de um incidente. Nem
sempre a solução mais simples, como desligar um computador comprometido, é a maneira
correta de limitar os dados de um comprometimento. Certos comprometimentos valem-se
de armadilhas lógicas, por exemplo: assim que um sistema for desligado, um conjunto
de funções é ativado, tal como: remover todos os rastros do comprometimento ou ainda,
remover arquivos essenciais para a execução do Sistema Operacional.
56
l Pode-se concluir que a parte essencial da contenção é a tomada de decisão, ou seja, definir
No caso específico da efetivamente que ações devem ser realizadas para conter o incidente.
propagação de um
malware, por exemplo, A seguir são exemplificadas algumas ações de contenção:
pode-se eliminar o
vetor de ataque 11 Desconectar o sistema comprometido ou isolar a rede afetada. Em alguns casos, mesmo
utilizado pelo malware.
com o sistema comprometido, é necessário manter o sistema comprometido ativo. Como
Outra possível ação é
isolar os sistemas solução temporária, pode-se isolar o sistema da rede. Dessa forma, o sistema continua aces-
comprometidos em sível, mas apenas com acesso local, evitando que outras máquinas sejam comprometidas;
nível de rede, impe-
dindo que o worm 11 Desativar sistema é, em casos específicos, uma solução aconselhável para evitar maiores
alastre-se para outras perdas. Em um caso onde um sistema comprometido está tendo o sistema de arquivo
sub-redes.
removido, por exemplo, o desligamento do sistema evitará que o processo de formatação
seja completo;
11 Alterar políticas de roteamento dos equipamentos de redes de maneira a bloquear o

fluxo previamente identificado como malicioso;
11 Desabilitar serviços vulneráveis é essencial para certos tipos de ataques. Dessa maneira,
em casos onde um ataque explora serviços específicos, a desativação do serviço atacado
inibe o comprometimento de outros sistemas;
11 Bloquear padrões de tráfego usando ferramentas de restrição. Esse bloqueio só pode ser
efetuado quando um padrão de tráfego que caracteriza o evento de segurança investi-
gado – assinatura – é mapeado.
A contenção é uma tarefa que pode ser incremental. Com a investigação do incidente, novos
sistemas afetados podem necessitar de medidas que possam conter possíveis ações do invasor.
Evidentemente, cada incidente tem as suas particularidades. Cada caso demanda ações
onde o CSIRT define estratégias de contenção. Nas etapas iniciais de um incidente as
informações são imprecisas e existem certas pressões para que o incidente seja resolvido
rapidamente e pare de afetar os sistemas da instituição. Se por um lado desativar um
sistema comprometido pode parecer a ação mais sensata, por outro deixar o sistema ativo e
identificar o intruso pode ser mais interessante.
Qualquer ação de contenção ou mitigação nos sistemas comprometidos podem ter efeitos
indesejados, tal como destruir evidências ou fazer com que o atacante perceba que ele foi
identificado fazendo com que determinadas ações sejam lançadas (apagar todos os arquivos).
Logo, mesmo na fase de contenção, recomenda-se que sejam coletados, na medida do pos-
sível, todos os dados pertinentes para a investigação antes mesmo que as ações de contenção
sejam realizadas. Afinal, pode ser que o acesso ao sistema comprometido torne-se inviável.
Por fim, a fase de contenção deve ser devidamente documentada para que os procedi-
mentos possam ser revertidos posteriormente; afinal, na sua maioria, são ações tempo-
rárias. Não menos importante é comunicar aos usuários e partes envolvidas o real status
do sistema comprometido, descrevendo os procedimentos realizados até o momento para
a contenção dos ataques. Do contrário, as partes dependentes do serviço comprometido
podem ser informadas de forma direta sem que rumores sejam disseminados.
57
Erradicação
O objetivo da etapa de erradicação é eliminar a causa do incidente. Deseja-se remover q
a fragilidade de segurança utilizada para comprometer os sistemas relacionados com o
incidente de segurança.
Todas as ameaças e riscos devem ser removidos do sistema e redes afetadas antes que o
serviço seja reestabelecido.
Do contrário, o sistema pode ser facilmente comprometido novamente. Em alguns casos;

no entanto, apenas remover a causa do incidente pode não ser efetiva para que o sistema
possa ser recuperado.
As ações específicas de erradicação dependem da natureza do incidente.
Em sistemas onde uma vulnerabilidade de uma aplicação foi explorada para comprometer
o sistema, podem ser utilizadas ações como: atualizar a aplicação comprometida; instalar as
últimas correções de segurança; restaurar os dados dos usuários; usar sistemas de antivírus
e remoção de malware.
Como resultado, essa etapa deve: q

11 Garantir que as causas do incidente foram removidas, assim como todas as atividades
e arquivos associados ao incidente;
11 Assegurar a remoção de todos os métodos de acesso utilizado pelo atacante, incluindo:

novas contas de acessos; backdoors e, se aplicável, acesso físico ao sistema comprometido.
Da mesma forma, a erradicação deve considerar as ações de contenção realizadas pre-

viamente pela equipe, tal como bloqueios e restrição de acesso aos sistemas.
Algumas vezes, a erradicação completa do incidente não pode ser realizada e as medidas de
contenção devem ser mantidas até que a solução seja efetivada. Por exemplo, uma vulnera-
bilidade sem correção disponibilizada pelo fabricante.
Por fim, recomenda-se que o CSIRT tenha procedimentos estabelecidos para atuar com os
casos de erradicação de incidentes conhecidos e frequentemente resolvidos pela equipe.
Dessa maneira, evita-se com que tarefas sejam esquecidas durante o processo.
Recuperação
A recuperação tem o objetivo de retornar qualquer sistema comprometido completa- q
mente ao seu estado normal de operação. Essa etapa inclui retornar ao estado opera-
cional das redes afetadas, e também restaurar os dados de aplicações e de usuários, além
da integridade do sistema. Os principais objetivos do estágio de recuperação incluem:
11 Restaurar a integridade do sistema;

11 Garantir que o sistema foi recuperado corretamente e que suas funcionalidades

estejam ativas;
11 Implementar medidas de segurança para evitar novos comprometimentos.
O processo de recuperação de um incidente de segurança é determinado pelas próprias

características do ataque efetuado.
Em certos casos, a recuperação pode ser realizada logo após remover as causas do inci-
dente; em outros, porém, é necessário reconstruir o sistema como um todo. Neste contexto,
garantir a integridade do sistema é essencial.
58
Em sistemas comprometidos não se deve confiar na integridade dos arquivos, pois estes
podem ter sidos substituídos por arquivos maliciosos. Isso inclui comandos básicos de
sistema, tal como, “ls”, “md5sum”, “ps” e determinadas chamadas de sistemas. Sendo assim,
a integridade dos sistemas deve ser verificada utilizando ferramentas externas ao próprio
sistema. Caso não seja possível garantir a integridade, recomenda-se a reinstalação do
sistema operacional, usando versões confiáveis.
Além de garantir a integridade do sistema, deve-se atentar para a restauração dos dados do
sistema, tal como dados de usuários, configurações de serviços e demais arquivos.
A restauração de dados dos sistemas comprometidos pode ser realizada usando o último
backup completo armazenado. Outra maneira é utilizar sistemas tolerantes a falha, como
discos rígidos espelhados ou demais sistemas de RAID. Deve-se, no entanto, assegurar-se de
que os dados utilizados para a restauração do sistema estejam íntegros e não tenham sido
comprometidos.
Um erro comum é reinstalar aplicações e fazer com que o sistema seja restaurado com a
mesma aplicação vulnerável que levou ao comprometimento. Portanto, devemos estar
seguros de que as medidas corretivas foram aplicadas corretamente de maneira a impedir
que o incidente volte a se repedir.
Após a restauração dos sistemas, é preciso se certificar de que os serviços estejam funcio-
nando de maneira correta. Isso inclui verificar os serviços providos e a existência de alguma
restrição de acesso. Em certos incidentes, o serviço comprometido pode estar listado em
listas de bloqueio externas (blacklist). Isso é muito comum em sistemas que são compro-
metidos e utilizados para envio de spam. Sendo assim, faz parte do processo verificar a
existência de algum filtro externo e providenciar a remoção.
Adicionalmente, algumas considerações devem ser endereçadas a fim de realizar com q

sucesso o estágio de recuperação de sistemas:
11 Comunicar as pessoas envolvidas sobre o estado da restauração do sistema e prover

orientação na eventual detecção de anormalidades;
11 Continuar a monitoração das atividades do sistema em busca de possíveis anomalias,

o que pode representar o retorno do comprometimento;
11 Atualizar os demais sistemas comprometidos incluindo correção de vulnerabilidades

e também atualizar as defesas de segurança com novas regras que evitem nova-
mente o ataque sofrido.
Como comentado, tipicamente o CSIRT possui os seus próprios procedimentos implemen- Capítulo 4 - Processo de tratamento de incidentes
tados para a restauração dos sistemas.
A título de exemplo, uma pequena rotina é descrita a seguir, de maneira a ilustrar os q

conceitos dessa etapa de recuperação:
11 Remover vulnerabilidades, instalar correções e demais atualizações necessárias;
11 Reinstalar versões confiáveis de Sistemas Operacionais;
11 Reinstalar backup de dados;
11 Trocar todas as credenciais de acessos do sistema;
11 Conduzir o teste de vulnerabilidade no sistema comprometido;
11 Reconectar o sistema na rede;
11 Monitor as atividades do sistema com alto nível de detalhes;
11 Documentar o procedimento de recuperação para possíveis auditorias e avaliações.
59
Portanto, a etapa de solução de um incidente consiste em mitigar as causas, levando-se em
consideração todas as informações obtidas durante as etapas anteriores. Na medida do
possível e do aplicável, o processo de erradicação deve considerar propostas de melhorias
que visem a diminuir a exposição a novos incidentes como o que foi tratado.
Finalmente, durante a recuperação dos sistemas, é importante remover todas as medidas

defensivas utilizadas, em especial passando novamente pelas ações realizadas na etapa de
contenção do incidente. Deve-se ajustar, por exemplo, filtros aplicados aos sistemas e em
equipamentos de infraestrutura de rede envolvidos.
Avaliação
Por fim, a avaliação é a etapa que consiste em revisar e integrar todas as informações q
relacionadas com o incidente ocorrido. A avaliação do incidente passa por reconstituir
suas etapas, realizando uma análise após a resolução do incidente. As atividades de
avaliação visam:
11 Caracterizar o conjunto de lições aprendidas de modo a aprimorar os procedimentos

e processos existentes;
11 Prover estatísticas e métricas relativas ao processo de resposta a incidentes;
11 Identificar características de incidentes que podem ser utilizadas para treinar novos
membros da equipe;
11 Obter informações que podem ser utilizadas em processos legais.
Infelizmente, muitas vezes, esse estágio é negligenciado devido a fatores como esgotamento
da equipe (cansaço ou falta de recursos). No entanto, a etapa de avaliação é igualmente
importante e não deve ser omitida do processo de resposta de incidentes. Nesse contexto,
a avaliação de incidentes passa por reconstituir suas etapas, realizando uma análise post-
-mortem. Definir, por exemplo, quais foram os estágios de comprometimento; que tipo de
informação foi acessada; quais informações poderiam ter sido acessadas; onde o incidente
poderia ter sido detectado; e se as novas medidas implementadas seriam efetivas para
novos incidentes da mesma natureza.
Outra importante parte do estágio de avaliação é prover a atualização de possíveis modifi-

cações nos procedimentos utilizados pelo CSIRT, tendo em base as lições aprendidas pelo
incidente finalizado.
Possivelmente a equipe que atuou nos estágios prévios do processo de resposta a incidente
identificou etapas dos procedimentos utilizados que podem ser aprimorados. Certas etapas
podem ser melhoradas ou, até mesmo, suprimidas de maneira a deixar o procedimento de
resposta mais objetivo.
Por fim, e não mesmo importante, avaliar como decorreu a interação entre as pessoas
do CSIRT e também a comunicação com outras partes envolvidas com o incidente. Nesse
estágio de avaliação, aspectos da comunicação interpessoal também podem ser melho-
rados. Da mesma forma, deve-se avaliar a condução gerencial da equipe no momento da
resposta a incidentes, permitindo identificar possíveis limitações.
Recursos adicionais
Como comentado, as etapas da metodologia citada servem como guia para a implementação
de procedimentos e ações a serem implementados pelos CSIRTs. É importante lembrar que
não existe um procedimento ou conjunto de ações padronizadas para lidar com incidentes de
60
segurança. Todas as ações do CSIRT devem seguir a missão e a abrangência operacional tendo
em vista as políticas de cada instituição. Na sequência são apresentados alguns exemplos de
procedimentos de maneira a ilustrar os conceitos discutidos até então.
Os seguintes procedimentos são apresentados: q

11 Roteiro para avaliação inicial de um incidente de segurança;
11 Roteiros para atuar com os seguintes tipos de incidentes:
22 Comprometimento por worm;
22 Página falsa.
Roteiro para avaliação inicial de um incidente

Utilizando a metodologia recém-descrita, é possível desenvolver um roteiro ou um checklist
que pode ser útil para rapidamente avaliar e obter informações sobre o incidente. Mesmo não
disponibilizando a resposta de todos os tipos de incidentes, o checklist pode ser utilizado para
auxiliar o CSIRT nas fases iniciais de resposta a incidentes. O checklist a seguir foi embasado
no modelo proposto por Eugene Shultz e Russell Shumway (vide bibliografia deste capítulo).
Roteiro para avaliação de incidentes de segurança
1. Qual é a natureza do incidente?

[ ] Negação de serviços (DoS)
[ ] Comprometimento de sistemas
[ ] Códigos maliciosos
[ ] Acesso não autorizado
[ ] Outros
2. O incidente afetou ou comprometeu dados sensíveis da instituição, como, por exemplo,

base de clientes, credenciais de acesso, sistemas críticos?
[ ] Sim
[ ] Não
3. O atacante obteve acesso privilegiado (root ou administrador)?

[ ] Sim
[ ] Não
Quando o incidente foi detectado?

Data:
Hora: Capítulo 4 - Processo de tratamento de incidentes
4. Como o incidente foi detectado?

[ ] Auditoria de Logs ou sistemas de detecção de intrusão
[ ] Notificação externa
[ ] Software de antivírus
[ ] Usuários internos
[ ] Outros
5. Quando o incidente de fato ocorreu?

Data:
Hora:
61
6. O incidente continua?
[ ] Sim
[ ] Não
7. Quais são os sintomas atuais relativos ao incidente?
8. Que departamentos/áreas foram afetados?
9. Que sistemas foram afetados?

Descreva em detalhes características dos sistemas afetados, incluindo Sistema Opera-
cional, aplicações, endereço IP e usuário relacionado com o dispositivo ou aplicação.
10. O backup dos sistemas comprometidos está disponível?

[ ] Sim
[ ] Não
11. Os sistemas afetados ainda estão sob risco de ataques?

[ ] Sim
[ ] Não
12. Os sistemas comprometidos potencialmente necessitaram de uma análise forense?

[ ] Sim
[ ] Não
Procedimentos
Como comentado, cada CSIRT deve desenvolver os seus próprios procedimentos e q
roteiros que identificam as ações a serem executados na ocorrência de um incidente.
Na sequência são apresentados diferentes roteiros que podem servir como base para um
CSIRT desenvolver os seus próprios procedimentos.
Comprometimento por Malware/Worm
1. Isolar o sistema afetado
22 Desconectar o sistema afetado da rede ou pelo menos isolar os sistemas comprometidos;
22 Registrar as ações realizadas (regras de firewall e demais bloqueios realizados).
62
2. Notificar as autoridades responsáveis
22 Notificar o CSIRT;
22 Notificar as autoridades departamentais.
3. Identificar o problema
22 Determinar e isolar os processos e arquivos relativos ao incidente;
22 Coletar evidências: logs, snapshot do sistema, configuração etc.;
22 Listar a conexões de rede ativas;
22 Seguir os procedimentos específicos de cada Sistema Operacional para localizar

arquivos modificados, programas instalados ou arquivos ocultos.
4. Conter ações do comprometimento
22 Remover todo processo suspeito no sistema comprometido;
22 Assegurar-se de que o malware que comprometeu o sistema não será incluído no backup;
22 Manter o sistema isolado até que o comprometimento seja totalmente erradicado.
5. Erradicar os sistemas afetados
22 Avaliar a extensão dos danos antes de aplicar a correção das vulnerabilidades;
22 Aplicar correções de segurança em todos os sistemas vulneráveis;
22 Avaliar o sistema em busca de demais danos causados pelo comprometimento;
22 Caso o sistema seja recuperado do backup, é importante lembrar de apliar correções

de segurança;
6. Atualizar sistema de antivírus.
7. Restaurar os sistemas para o estado de operação normal
22 Assegurar-se de que os sistemas estão restaurando e executando em estado normal

de operação;
22 Alterar credenciais de acesso de todos os usuários.
8. Realizar uma avaliação
22 Realizar uma avaliação geral do caso, de maneira a avaliar as ações implementadas;
22 Atualizar os procedimentos internos com as lições aprendidas no caso.
Página falsa
1. Desativar a página falsa
22 Se possível, desativar o servidor web comprometido;
22 Tornar o acesso à página falsa inacessível.
2. Identificar as características do incidente
22 Identificar como a página de phishing foi instalada;
22 Determinar outras ações desempenhadas no servidor comprometido;
22 Identificar se o comprometimento ao sistema teve acesso privilegiado (super-usuário);
22 Analisar os arquivos relativos à página comprometida (base de dados, arquivos do

atacante, ferramentas do atacante);
22 Identificar todos os acessos à página comprometida (possíveis vítimas).
63
3. Notificar as partes envolvidas
22 Notificar as possíveis vítimas do ataque;
22 Enviar artefatos e informações sensíveis encontradas na máquina para

a instituição fraudada;
22 Notificar CSIRT de coordenação (CAIS/RNP ou CERT.br).
4. Restaurar os sistemas para o estado de operação normal
22 Assegurar-se de que os sistemas estão restaurando e executando em estado normal

de operação;
22 Alterar credenciais de acesso de todos os usuários;
22 Ajustar as medidas de segurança de modo a evitar novos comprometimentos;
22 Armazenar todos os arquivos relativos à página comprometida para possíveis

colaborações com a Justiça.
11 NIST SP 800-61: Computer Security Incident Handling Guide

http://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf
11 EDUCAUSE Security Task Force: Incident Handling and Response

http://www.educause.edu/IncidentHandlingandResponse/1269
11 Handbook for Computer Security Incident Response Teams

http://www.cert.org/archive/pdf/csirt-handbook.pdf
11 RFC 3.227 – Guidelines for Evidence Collection and Archiving

11 An Introduction to Incident Handling

http://www.securityfocus.com/infocus/1184
11 Handbook for Computer Security Incident Response Teams

http://www.cert.org/archive/pdf/csirt-handbook.pdf
11 CERT®/CC Steps for Recovering from a UNIX or NT System Compromise

http://www.cert.org/tech_tips/win-UNIX-system_compromise.html
11 Microsoft Says Recovery from Malware Becoming Impossible

http://www.eweek.com/article2/0,1895,1945808,00.asp
11 RFC 3.227: Guidelines for Evidence Collection and Archiving

Schultz, Eugene, and Russell Shumway. Incident response: a strategic guide to handling
system and network security breaches. Sams, 2001.
Van Wyk, Kenneth R., and Richard Forno. Incident response. O’Reilly, 2001.
11 IODEF: Incident Object Description and Exchange Format

http://www.terena.nl/activities/tf-csirt/iodef/
64
5
Aspectos operacionais da resposta
a incidentes
Identificar informações críticas em incidentes de segurança; Prover o entendimento

objetivos
e escopo de incidentes; Interpretar notificações de incidentes.
Análise de cabeçalhos de e-mails; Identificação de informações relevantes em
conceitos
logs de serviços e sistemas; Resposta, notificação e encaminhamento de incidentes
de segurança.
Introdução
Sabe-se que o processo de resposta a incidentes é constituído por uma metodologia e
etapas bem definidas. O capítulo anterior apresentou uma visão geral do processo de res-
posta a incidentes de uma maneira organizacional. De forma complementar, este capítulo
tem por objetivo apresentar as diferentes etapas sob o ponto de vista operacional. Para
isso, serão apresentadas ferramentas e técnicas que servem para identificar informações
sensíveis de incidentes e prover recursos para a resolução.
Aspectos operacionais da resposta a incidente

q
Capítulo 5 - Aspectos operacionais da resposta a incidentes
Os aspectos operacionais da resposta a incidentes descrevem de forma pragmática como
as diferentes etapas da metodologia de resposta a incidente podem ser implementadas.
É importante lembrar que existem diferentes processos e metodologias para lidar com os
incidentes de segurança – cada CSIRT deve implementar sua metodologia conforme as suas
próprias peculiaridades: abrangência operacional e política da instituição. Mesmo assim,
existe um conjunto de atividades que permeiam as diferentes metodologias e podem auxi-
liar o CSIRT em suas tarefas especializadas.
A identificação de um incidente, por exemplo, é uma tarefa presente em qualquer metodologia

de resposta a incidente. A partir do momento que um incidente de segurança é identificado,
cabe à equipe definir quais são as ações a serem desempenhadas pela equipe. Essas etapas
operacionais seguem um fluxo lógico bem definido. A figura a seguir ilustra as principais ações
que podem ser desempenhadas assim que um incidente de segurança é identificado.
65
incidente
identificação
triagem
Figura 5.1
Etapas operacionais
iniciais na análise
de um incidente de
categorizar priorizar atribuir segurança.
Inicialmente, assim que o CSIRT identifica um possível incidente de segurança, entram q

em ação etapas de classificação e priorização dos eventos.
Posteriormente, a equipe atribui os incidentes aos seus devidos responsáveis para que os
devidos procedimentos sejam aplicados. Na sequência as diferentes etapas da metodologia
são caracterizadas com maior nível de detalhamento.
Identificação
A identificação visa confirmar a real existência do incidente e realizar uma análise inicial q
dos recursos afetados. No que tange as questões operacionais, cabe relembrar as
diversas formas que um incidente pode ser identificado:
11 Identificada pelo próprio CSIRT;
11 Notificada por entidades da própria instituição;
11 Notificação por entidades externas.
Para isso, o CSIRT usa a sua infraestrutura e recursos para identificar os incidentes
de segurança. Ferramentas de segurança do próprio CSIRT, por exemplo, podem ser utili-
zadas para identificar incidentes de segurança destinados à instituição. As ferramentas de
detecção de intrusão são úteis para identificar máquinas comprometidas na própria rede
local. Da mesma forma, incidentes podem ser identificados por outros departamentos
através da simples observação comportamental dos sistemas (lentidão, muitas conexões,
uso intenso de disco rígido em ociosidade do sistema).
q
Por outro lado, um incidente pode ser notificado por meio de entidades externas, tal
como CSIRTs, redes atacadas, grupos de pesquisas.
Sendo assim, todo incidente de segurança deve ser analisado de forma criteriosa, com a
verificação da origem e a veracidade das informações reportadas. Como parte da avaliação,
não basta apenas examinar as informações do corpo da mensagem da notificação, mas em
alguns casos inspecionar seu cabeçalho.
Mensagens de e-mail
Como se sabe, o envio de mensagens é realizado por um servidor de e-mail tipicamente
utilizando o protocolo Simple Mail Transfer Protocol (SMTP) para transmissão da mensagem
66
desejada. Em geral, os servidores SMTP – servidor de e-mail da instituição – permitem que
as máquinas da rede interna conectem e enviem mensagens. Para isso, os servidores de
e-mail podem ser configurados de diferentes maneiras, usando políticas distintas para
a transmissão de mensagens. O ideal, por questões de segurança, é que um servidor de
e-mail não deveria permitir a submissão direta de mensagens de e-mails de máquinas
internas sem garantir a autenticação dos usuários. Afinal, máquinas comprometidas
poderiam valer-se dessa relação de confiança e usar o servidor da instituição para enviar
w mensagens indesejadas.
Mais informações
podem ser encontradas As boas práticas de configuração descrevem maneiras de configurar de modo seguro os ser-
em: http://www. vidores de e-mail de uma instituição. Um exemplo é a política de segurança que implementa
antispam.br/admin/
o “Gerenciamento da porta 25”.
porta25/motivacao/
Antes de analisar mensagens de e-mail, é importante relembrar a anatomia típica de uma
mensagem. Uma mensagem de e-mails é constituída por três partes distintas:
11 Envelope: diretivas utilizadas para o efetivo encaminhamento da mensagem;
11 Cabeçalho: diretivas informacionais que descrevem propriedades da mensagem;
11 Corpo de mensagens: conteúdo da mensagem de e-mail.
O envelope determina onde a mensagem de e-mail efetivamente vai ser entregue. O enve-
lope é invisível ao usuário não fazendo parte da mensagem de e-mail. As informações do
envelope são utilizadas internamente pelo protocolo de envio de mensagens (SMTP).
De forma resumida, o protocolo SMTP necessita mandatoriamente dos seguintes campos:
11 mail from: <from@instituicao.com>
11 rcpt to: <to@gmail.com>
Os campos “mail from:” e “rcpt to:” são utilizados respectivamente para especificar a origem
da mensagem e o destinatário. Caso não seja possível entregar a mensagem, a mesma
mensagem é retornada para o endereço de origem. É importante lembrar que as diretivas
do envelope da mensagem são totalmente independentes do cabeçalho. Sendo assim, é
possível ter a diretiva “mail from:” e a diretiva do cabeçalho “From” diferentes. Essa inconsis-
tência entre o cabeçalho e o envelope é uma técnica bastante utilizada por fraudadores de
modo a forjar a origem das mensagens.
Já o cabeçalho da mensagem de e-mail é constituído por um conjunto de informações espe-

cificadas na RFC 5322.
Tais diretivas descrevem informações da mensagem, como: data e hora em que a mensagem
foi envida, servidores de e-mail intermediários utilizados para enviar a mensagem e seus
respectivos horários de recebimento. Por fim, o corpo da mensagem é o conteúdo da men-
sagem propriamente dito. Tipicamente em formato texto sem formatação, mas pode conter
outros formatos, incluindo HTML, arquivos binários (anexo) e também conteúdo cifrado.
Análise de cabeçalho
A análise do cabeçalho de e-mail consiste em examinar certas informações presentes q
nas mensagens em busca de inconsistências. As características de uma mensagem de
notificação podem revelar:
11 Mensagens forjadas;
11 IP de origem do remetente;
11 Características do servidor de e-mail;
67
11 Erros de configuração; q
11 Sincronia de tempo.
O entendimento dos cabeçalhos de uma mensagem é uma habilidade demandada para os

membros da equipe do CSIRT. O primeiro passo é localizar o cabeçalho de uma mensagem
de e-mail. Muitos softwares ocultam parte das diretivas do cabeçalho apresentando apenas
algumas informações, tal como: origem, destino, assunto e data, muito embora seja possível
visualizar o cabeçalho completo das mensagens alterando o modo de exibição da ferramenta.
Mesmo em casos onde são utilizados sistemas de webmail é possível obter essas informa-
ções do cabeçalho das mensagens. No Gmail, webmail do Google, por exemplo, é possível
obter informações de cabeçalho da mensagem utilizando a opção “Show original” no menu
da mensagem, conforme ilustrado nesta figura:
Figura 5.2
Visualizando o
cabeçalho no
webmail Gmail.
O cabeçalho da mensagem deve ser interpretado no sentido “de baixo para cima”.
Na sequência – figura 5.3 –, é exemplificado um cabeçalho de uma mensagem de e-mail arbi-
trário e a sua respectiva interpretação.
1 Return-Path: <anon@anon.net>
2 X-Original-To: cert@intra.esr.rnp.br
3 Delivered-To: cert@intra.esr.rnp.br
4 Received: from mail.esr.rnp.br (mail.esr.rnp.br [10.10.10.10])
5 (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))
6 (No client certificate requested)
7 by intra.esr.rnp.br (Postfix) with ESMTPS id 9CCF04CEB46
8 for <cert@intra.esr.rnp.br>; Fri, 4 Oct 2013 16:47:56 -0300 (BRT)
9 Received: by mail.esr.rnp.br (Postfix)
10 id 5F71941AB1D; Fri, 4 Oct 2013 16:47:56 -0300 (BRT)
11 Delivered-To: cert@esr.rnp.br
12 Received: from rota5.anonnet.net (rota4.anonnet.net [10.1.1.1])
13 (using TLSv1 with cipher DHE-DSS-AES256-SHA (256/256 bits))
14 (No client certificate requested)
15 by mail.esr.rnp.br (Postfix) with ESMTPS id 52EB441AA74
16 for <cert@esr.rnp.br>; Fri, 4 Oct 2013 16:47:56 -0300 (BRT)

17 Received: from [10.10.2.1] (port=17213 helo=SXXXNIP005)
18 by sh.anonnet.net with esmtpa (Exim 4.80)
19 (envelope-from <anon@anon.net>)
20 id 1VSB6d-0048UJ-Kv
21 for cert@esr.rnp.br; Fri, 04 Oct 2013 16:32:07 -0300
22 Return-Receipt-To: “Reportador de incidentes :: anon DATACENTER” <anon@anon.net>
23 User-Agent: KMail/4.8.5 (Linux/3.2.0-54-generic; KDE/4.8.5; x86_64; ; )
24 MessageId: 4234xDfAF
25 Message-Id: <201312011813.rB1ID7V3020559>
26 Date: Fri, 04 Oct 2013 16:32:00 -0300
27 Subject: comprometimento de sistemas Figura 5.3
28 From: anon@anon.net cabeçalho de
e-mail.
68
Os diferentes campos do cabeçalho permitem observar alguns identificadores básicos q
que podem facilmente revelar detalhes do e-mail recebido, tal como:
11 Linha 2: To/X-Original-To: endereço de destino: endereço de e-mail de destino

da mensagem;
11 Linha 23: User-Agent: software utilizado: descreve a identificação do software utili-

zado para compor e submeter a mensagem de e-mail ao servidor;
11 Linha 26: Date: horário de envio: data e horário em que o e-mail foi enviado, ou seja,
no momento em que foi recebido pelo respectivo servidor de envio;
11 Linha 28: From: endereço de origem: endereço de e-mail do remetente. Essa infor-
mação é inserida pelo próprio remetente e não existe nenhuma espécie de verificação.
Sendo assim, pode-se concluir que a mensagem foi enviada pelo endereço “anon@anon.net”
através do servidor “sh.anonnet.net”, que utiliza o software “Exim versão 4.80” para envio
de e-mail. Também é possível identificar que a mensagem foi escrita no Sistema Operacional
Linux e usando o software “Kmail” para composição da mensagem. Posteriormente, a men-
sagem foi encaminhada para o servidor “mail.esr.rnp.br”, que repassou para o servidor de
e-mail “intra.esr.rnp.br” até chegar ao seu destino final.
A análise de informações do cabeçalho em sistemas e webmail é muito semelhante.

Em alguns sistemas de webmail é possível observar o campo “X-Originating-IP” presente
no cabeçalho da mensagem. Esse campo identifica o endereço IP utilizado para compor a
mensagem, ou seja, o endereço IP do computador que autenticou no webmail.
De fato, a análise do cabeçalho de mensagens de e-mail exige atenção; no entanto, existem

algumas ferramentas que podem facilitar essa tarefa. Existem serviços online que permitem
analisar o cabeçalho de e-mail de forma automatizada. Boa parte das ferramentas online
identificam os principais campos do cabeçalho e permitem que conclusões sejam tomadas
pelo analista. Um exemplo é o serviço Message Header Analyzer: https://toolbox.google-
Figura 5.4 apps.com/apps/messageheader/
Ferramenta online
para análise A título de ilustração, o mesmo cabeçalho apresentado na figura 5.4 foi analisado no
de cabeçalho referido serviço online. Como resultado, obteve-se a seguinte análise:
de e-mail.
A análise dessas informações podem revelar indícios de que uma mensagem foi forjada.
Observando campos, tal como IP de origem, servidores de e-mail utilizados para envio de
mensagens, reverso dos IPs e demais fatores são essenciais para identificar irregularidades.
69
Análise de cabeçalho de e-mail
Analise os cabeçalhos da mensagem a seguir e responda as seguintes perguntas:
Return-Path: <presidente@com.br>
X-Original-To: cert@intra.esr.rnp.br
Delivered-To: cert@intra.esr.rnp.br
Received: from mail.esr.rnp.br (mail.esr.rnp.br [10.10.10.10])
(using TLSv1.2 with cipher AECDN-AES256-SHA (256/256 bits))
(No client certificate requested)
by intra.esr.rnp.br (Postfix) with ESMTPS id 86359247A42
for <cert@intra.esr.rnp.br>; Fri, 25 Oct 2013 17:40:09 -0200 (BRST)
Received: by mail.esr.rnp.br (Postfix)
id 743B441ABE2; Fri, 25 Oct 2013 17:40:09 -0200 (BRST)
Delivered-To: cert@esr.rnp.br
Received: from server.open.bizz (unknown [10.10.2.2])
by mail.esr.rnp.br (Postfix) with ESMTP id 472E441ABE0
for <cert@esr.rnp.br>; Fri, 25 Oct 2013 17:40:09 -0200 (BRST)
Received: from qualquercoisa (localhost [127.0.0.1])
by server.open.bizz (Postfix) with SMTP id DA6CC1DC639
for <cert@esr.rnp.br>; Fri, 25 Oct 2013 17:01:57 -0200 (BRST)
Message-Id: <20131025190214.DA6CC1DC639@server.open.bizz>
Date: Fri, 25 Oct 2013 17:01:57 -0200 (BRST)
From: presidente@com.br
To: cert@esr.rnp.br
a. Qual é o destinatário da mensagem?
b. Em que horário a mensagem foi escrita, ou seja, foi enviada para o servidor?
c. Que sistema foi utilizado para compor a mensagem de e-mail?
70
d. Trata-se de uma mensagem forjada? Por quê?
O protocolo SMTP, utilizado para envio de e-mails, não faz autenticação de origem e pode
ser facilmente utilizado para forjar o remetente da mensagem. Por exemplo, o e-mail do
exercício anterior foi composto utilizando os comandos ilustrados na figura 5.5. Em vez de
usar um cliente de e-mail, optou-se por utilizar diretrizes do protocolo SMTP diretamente
com o servidor de e-mail.
user@server -> telnet localhost 25

Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is ‘^]’.
220 server.open.bizz ESMTP
helo qualquercoisa
250 server.open.bizz
mail from: presidente@com.br
250 2.1.0 Ok
rcpt to: cert@esr.rnp.br
250 2.1.5 Ok
Figura 5.5 data
Enviando uma 354 End data with <CR><LF>.<CR><LF>
mensagem de
.
e-mail seguindo o
protocolo SMTP. 250 2.0.0 Ok: queued as 91CA51DC764
Utilizando o protocolo SMTP

Com base nos comandos exemplificados na figura 5.5, vamos tentar enviar uma mensagem
de e-mail usando o servidor de sua instituição. Para isso, vamos usar comandos do pro-
tocolo SMTP comunicando-se diretamente com o servidor de e-mail. Veja as instruções a
seguir e na sequência responda as perguntas:
a. Identifique o servidor de e-mail da instituição:
dig <dominio> MX +noall +answer
user@server —> dig rnp.br MX +noall +answer

; «» DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntul
«» rnp.br MX +noall +answer
;; global options: +cmd
rnp.br. 299 IN MX 5 mx0.rnp.br.
rnp.br. 299 IN MX 15 mx1.rnp.br.
71
b. Utilize o comando telnet para acessar o servidor SMTP
telnet servidor 25
c. Usando as mensagens do protocolo SMTP, tente enviar um e-mail executando os

comandos a seguir:
helo <seu domínio><enter>
mail from: <remetente do e-mail><enter>
rcpt to: <endereço de e-mail destino><enter>
data
quit
d. O e-mail foi enviado com sucesso? O destinatário recebeu a mensagem?
e. Por que o destinatário não recebeu a mensagem?
f. Qualquer máquina na rede pode enviar um e-mail utilizando os mesmos passos execu-
tados? Quais são as implicações de segurança?
72
Sincronismo de tempo
O sincronismo de tempo é uma questão fundamental para a investigação de eventos q
relacionados com segurança. Dessa forma, podem-se evitar erros de interpretação dos logs
dos diferentes dispositivos (firewalls, roteadores e servidores). Sem a sincronia de horário, a
análise dos diferentes arquivos de logs pode ser afetada principalmente na etapa de corre-
lação de eventos.
O mecanismo mais utilizado para o sincronismo de tempo é o protocolo Network Time

Protocol (NTP). A implementação e características do protocolo NTP fogem do escopo deste
trabalho; no entanto, a bibliografia é vasta e diversos serviços estão disponíveis na rede.
Os websites a seguir descrevem detalhes do protocolo e como a sua configuração pode q

ser realizada nos diversos sistemas:
11 http://www.rnp.br/ntp/
11 http://ntp.br/
Assim como o sincronismo, a correta interpretação do horário de um incidente é essencial. Iden-

tificar o formato da data e hora nem sempre é uma tarefa simples, existe muita ambiguidade nas
representações. Cada país tem suas próprias normas de representar horários. Uma represen-
tação de horário bastante aceito internacionalmente é a especificada pela ISO 8601.
A ISO 8601 especifica a formato para representar data e tempo de forma padrão. Esse q
padrão é bastante robusto e permite especificar o tempo com grande flexibilidade, como
pode ser visto na sequência:
Ano, mês e dia:
YYYY-MM-DD (ex. 2013-07-16)
Data e hora completa:
YYYY-MM-DDThh:mm:ssTZD (ex. 2013-07-16T19:20:30+01:00)
Onde:
YYYY = ano com quatro dígitos
MM = mês com dois dígitos (01=Janeiro, etc.)
DD = dia do mês (01 até 31)

hh = hora com dois dígitos (00 até 23)
mm = minuto com dois dígitos(00 até 59)
d
ss = segundo com dois dígitos (00 até 59)
Leituras recomendadas TZD = fuso horário (Z=GMT(Greenwich Mean Time) ou +hh:mm ou -hh:mm)
– ISO 8601 “Numeric
representation of Dates Do contrário, sem a padronização de um formato, seria quase impossível identificar correta-
and Time”:
mente a data e hora. Um exemplo é ilustrado a seguir:
http://www.iso.org/iso/
en/prods-services/
11 01:00:00 05/11/06
popstds/datesandtime.
html e “A summary of 11 01:00:00 01/02/03
the international
standard date and time Nessa representação, não fica evidente o formato utilizado para representar data e a hora.
notation”: Existem alguns pontos que permitem uma interpretação redundante, por exemplo:
http://www.cl.cam.ac.
uk/~mgk25/iso-time. 11 formato da hora: 24 horas ou 12 horas;
html
11 formato da data: dia/mês/ano ou mês/dia/ano.
73
Figura 5.6
Aviso
Além de informações de data e hora, é fundamental observar questões pontuais, como q

fuso horário.
Diversos países fazem o uso do horário de verão, cada qual com suas próprias regras de
adoção. No Brasil, o horário de verão é regulamentado pelo decreto presidencial Nº 6.558,
de 8 de setembro de 2008:
“Art. 1o Fica instituída a hora de verão, a partir de zero hora do terceiro domingo do mês de
outubro de cada ano, até zero hora do terceiro domingo do mês de fevereiro do ano subse-
quente, em parte do território nacional, adiantada em sessenta minutos em relação ‘a hora legal.”
Nem todos os estados devem adotar o horário de verão. O artigo 2º do mesmo decreto
define os seguintes estados onde o horário de verão deve vigorar: Rio Grande do Sul, Santa
Catarina, Paraná, São Paulo, Rio de Janeiro, Espírito Santo, Minas Gerais, Goiás, Mato Grosso,
Mato Grosso do Sul e no Distrito Federal.
A interpretação do horário pode ser mais complexa quando a investigação engloba dife- q
rentes fontes de informações a serem avaliadas, tais como:
11 Arquivos de logs;
11 Cabeçalho de e-mails;
11 Diferentes Sistemas Operacionais.
A correta identificação da data e hora permite definir um intervalo de tempo no qual os

eventos devem ser investigados.
Dessa maneira, torna-se possível restringir o volume de dados a serem analisados e permitir
a correta priorização e classificação dos incidentes. Em casos onde um incidente é identifi-
cado muito tempo após a sua ocorrência, sua investigação é prejudicada.
Evidentemente, o termo “muito tempo” é relativo ao tipo de incidente, por exemplo:um inci-
dente envolvendo negação de serviços que aconteceu há cinco dias terá menor prioridade
do que um incidente em andamento.
Do contrário, a etapa de correlação de incidentes pode ser seriamente prejudicada.

Uma notificação com logs de servidores localizados no Japão não fará sentido no Brasil se
a informação de fuso horário não estiver presente. No exemplo, o horário do log em um
horário no futuro do ponto de vista no Brasil. Não se deve assumir o fuso horário tendo
em base apenas informação do domínio, por exemplo: Brasil = GMT -3.
Essa informação nem sempre é verdadeira, sobretudo em países com diversos fusos horários.
74
De fato, cada administrador de sistema pode configurar o formato de data e hora da maneira
que bem entender, basta apenas explicitar o formato utilizado para a correta interpretação.
Para driblar preocupações de fuso horário e horário de verão, muitos administradores optam
por armazenar os logs no formato GMT.
Padronização do formato data e hora
Reescreva os horários a seguir usando a especificação ISO 8601. Considere o horário, data, e
fuso horário.
Data/hora Formato ISO 8601
22:23 de 04 de janeiro de 2013

(fuso horário Brasil/SP)
03:23 de 04 de março de 2013

(fuso horário Brasil/SP)
Aug 31 19:37:53
(fuso horário Venezuela)
Triagem
A triagem de incidentes busca classificar e priorizar incidentes suspeitos. Dessa maneira,

torna-se possível direcionar os esforços da equipe de tratamento de incidentes. De prefe-
rência, a triagem deve ser realizada de forma centralizada, ou seja, em um repositório onde
todos os incidentes a serem avaliados pela equipe são concentrados.
Tipicamente, os CSIRTs utilizam sistemas que centralizam as notificações de incidentes. Para

isso, podem ser utilizados sistemas de trouble tickets, ou ainda diferentes caixas postais que
direcionam (alias) as notificações para um repositório central:
csirt@instituicão
security@instituicao triagem@instituicao
abuse@instituicao
A etapa de triagem implicitamente envolve uma avaliação inicial dos incidentes. Dessa

forma, os incidentes podem ser encaminhados para o seu devido tratamento. Sob o con-
texto operacional, a triagem implementa as seguintes tarefas:
11 Categorizar;
11 Priorizar;
11 Atribuir.
Dessa forma, as tarefas relacionadas com a categorização e priorização de incidentes levam

em consideração os recursos afetados pelo incidente e também o impacto às atividades
críticas da instituição. Algumas organizações optam por utilizar, na fase de triagem, pro-
fissionais com boas habilidades técnicas e profundo conhecimento da instituição. Afinal,
a triagem demanda profissionais com habilidade de tomar decisões de maneira rápida e
efetiva, baseando-se em informações limitadas.
Nem tudo o que chega até a triagem pode ser considerado um incidente de segurança que
demanda ações. Existem notificações que de fato não correspondem a um incidente de segurança.
75
Para isso, é importante observar a definição de incidente segundo a própria política de segu-
rança da instituição. Outros casos, porém, são um pouco mais nebulosos. Como a triagem
poderia atuar no caso a seguir:
“Você recebeu uma notificação contendo um link para uma página falsa de uma instituição que
não é sua. Também não foi possível identificar nenhum recurso de sua instituição envolvido no
incidente (máquina propagando o link falsificado ou máquina hospedando o site falso).”
No exemplo citado, o incidente pode ser lidado de diferentes formas. Não existe uma res-
posta certa para atuar nesse caso. Vai depender das diretrizes e da atuação de cada CSIRT.
O incidente pode ser simplesmente descartado ou ainda tratado de forma não prioritária.
Em situações onde um incidente foge do escopo do CSIRT, ao invés de descartar a men-
sagem sumariamente, aconselha-se responder o remetente informando que a notificação
não será tratada pelo motivo especificado.
Além das notificações de incidente, é muito comum que um CSIRT receba os mais diversos ques-
tionamentos relacionados com segurança da informação. Muitas vezes, pela própria exposição
que o CSIRT possui, são recebidos questionamentos que fogem do escopo técnico de atuação
de um CSIRT, tal como mensagens relacionadas com pedidos de emprego. Cabe ao CSIRT ter
procedimentos que descrevem como essas situações não técnicas devem ser tratadas.
Priorização
Nem todo incidente é uma prioridade a ser tratada pelo CSIRT. Uma tentativa de ataque q
a um servidor web da instituição, por exemplo, deve ter uma prioridade diferente de um
incidente de negação de serviço ao mesmo servidor. Obviamente, a tarefa de priorização
e avaliação da criticidade de um incidente é muito particular em cada instituição.
O conhecimento dos ativos da organização – servidores, informações críticas – permitem

ao CSIRT desenvolver metodologias e procedimentos de priorização de incidentes.
Por exemplo, para certas organizações, é preferível desativar seus serviços da internet a
permitir que informações estratégicas sejam furtadas.
Na etapa de priorização, certamente o escopo do incidente é uma questão fundamental q

a ser considerada.
Um vírus que infectou um servidor deve ser tratado com prioridades diferentes do que em um
incidente onde um worm se propagou para toda a rede da instituição. Da mesma forma, um
incidente que afeta uma máquina de trabalho regular e um incidente que afeta uma máquina de
trabalho do departamento financeiro podem possuir prioridade diferentes.
Uma boa prática para priorização de eventos é a utilização de níveis de segurança, q

como por exemplo:
11 Nível 1: incidentes com baixo impacto para a instituição, que geralmente possuem
atuação restrita. Por exemplo, um incidente envolvendo um vírus em um computador
de trabalho (desktop);
11 Nível 2: são incidentes restritos a uma localidade com grande impacto nas operações
do sistema. Por exemplo, uma conta com acesso privilegiado comprometida em um
sistema crítico;
76
11 Nível 3: são eventos ou incidentes que não são restritos a uma localidade apenas, q
mas com pequeno impacto. Por exemplo, a proliferação de um vírus de computador
em um seguimento da rede local;
11 Nível 4: são incidentes com grande impacto e que afetam múltiplas localidades da ins-
tituição. São eventos que requerem uma grande intervenção da equipe e com atuação
com alta prioridade. Por exemplo, uma invasão a um servidor de autenticação.
De qualquer forma, é impossível determinar de antemão qual será o verdadeiro impacto de

um incidente para a organização. Entretanto, um modelo de classificação auxiliará a equipe
a desenvolver um esquema onde recursos possam ser priorizados quando atuando com
múltiplos incidentes. De uma forma resumida, a classificação e a priorização dos incidentes
devem considerar o impacto técnico e o impacto no negócio da instituição.
A seguir alguns questionamentos que podem auxiliar na etapa de triagem. q

Impacto técnico Impacto nos negócios
Que sistemas foram afetados? A imagem externa da instituição foi afetada?
Quantos clientes foram afetados com o

Tabela 5.1 Que dados foram comprometidos?
incidente?
Questões a serem
ponderadas na Qual nível de privilégio que o atacante
priorização de um Que serviços ou produtos foram afetados?
obteve?
incidente.
Uma vez que o incidente de segurança tenha sido avaliado, é possível estimar seu impacto
dentro da organização e atribuir sua devida priorização. A etapa de determinação de impacto
e priorização se torna muito eficiente em organizações que possuem um processo de análise
de risco, o que permite identificar componentes críticos ou pontos falhos que podem ser
atacados, gerando um maior dano. Ao mesmo tempo, o analista de segurança deve estar bem
informado sobre o tipo de incidente que está tratando e suas características, para que seja
possível estimar esse impacto frente às diversas informações que possui.
Categorização
A categorização dos tipos dos incidentes de segurança é uma atividade complementar q
que, aliada à priorização, permite ao CSIRT estimar as possíveis extensões do evento
de segurança.

Sendo assim, torna-se possível agrupar incidentes de segurança segundo a sua natureza.
Por exemplo, incidentes relacionados a varreduras não autorizadas podem ser categori-
zados como incidentes do tipo scan.
Boa parte dos CSIRTs implementa uma nomenclatura própria de modo a classificar a q
natureza dos incidentes de segurança, como:
11 inc-web: incidentes relacionados a ataques a servidores web;
11 inc-malware: incidentes relacionados aos diversos tipos de malwares;
11 inc-phishing: incidentes relacionados com phishing;
11 inc-dos: incidentes relativos a negação de serviços.
Infelizmente não existe uma padronização amplamente aceita relativa à categorização de

incidentes de segurança. Cada CSIRT implementa as suas – a categorização deve manter-se
consistente para os diversos tipos de incidentes. O importante aqui é especificar categorias
77
genéricas, não tão específicas. Dessa forma, a classificação pode ser mais flexível e adequar-se
à dinâmica dos incidentes. Afinal, existem diferentes tipos de incidentes onde a classificação
de sua natureza nem sempre é trivial. A figura 5.7 ilustra alguns tipos de incidentes que
podem ser considerados na etapa de classificação:
worm defacement
scanD.o.S difamação
calúnia open-proxy Figura 5.7
open-relay
invasão vírus espionagem Categorização de
ameaça diferentes tipos

pirataria phishing de incidentes de
malware segurança.
De fato, certas categorias de incidentes são mais críticas que outras. Por exemplo, incidentes
categorizados como “spam” possuem prioridade diferente de incidentes do tipo “invasão”.
Mesmo em incidentes com mesma classificação têm-se uma diferenciação no tratamento:
invasão em uma máquina crítica é diferente de uma invasão em uma máquina regular. Logo,
pode-se concluir que a classificação de incidentes, de forma indireta, também atribui um
nível de priorização aos incidentes.
Classificação e triagem de incidentes
Um CSIRT deve pré-definir um conjunto de categorias em que os incidentes investigados
serão classificados. Neste exercício vamos classificar 11 incidentes de segurança. Defina a
categoria do incidente e seu respectivo grau de severidade (alto, médio, ou baixo). Compare
os seus resultados com os dos outros grupos.
Categoria Severidade
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
78
Atribuição
A fase de atribuição busca determinar ações de modo a dar encaminhamento ao pro- q
cesso de resolução de incidente. Como já discutido, cada CSIRT tem os seus próprios
procedimentos para lidar com os diferentes tipos de incidentes, muito embora tais
procedimentos passem por etapas de:
11 Encaminhamento de incidentes;
11 Escalação de incidentes;
11 Notificação de incidentes.
É evidente que todas essas etapas possuem o mesmo objetivo: a resolução do incidente.
Assim sendo, cada etapa tem seus próprios procedimentos operacionais específicos.
Na sequência são apresentados os principais aspectos das etapas supracitadas.
Encaminhamento de incidentes
Certos incidentes não são necessariamente tratados pela própria equipe do CSIRT, e q
sim encaminhados para outros departamentos da instituição ou, ainda, para entidades
externas envolvidas com o evento de segurança. A etapa de encaminhamento, por sua
vez, busca repassar as informações do incidente para terceiros, tendo como objetivo:
11 Notificar: efetivamente notificar o responsável e os demais envolvidos com o incidente;
11 Complementar: solicitar ou descrever informações complementares do incidente

em questão.
O CSIRT deve assegurar-se de que todos os envolvidos em um incidente estão sendo notifi-
cados, incluindo o CSIRT nacional, CSIRT da organização, e contato técnico disponibilizado
no sistema WHOIS. Nem sempre o mesmo nível de informação – detalhes do incidente – é
encaminhado para todas as partes envolvidas. Em certos casos não é necessário encami-
nhar o conteúdo na íntegra para terceiros, como por exemplo em um incidente onde as
informações sensíveis de usuários foram expostas.
O encaminhamento de incidentes é muito realizado por CSIRTs de coordenação – tal q

como o CERT.br, que repassam os incidentes recebidos para os responsáveis ou ainda
para outros CSIRTs.
Na maioria dos CSIRTs, no entanto, o encaminhamento é realizado para outros grupos

internos da organização, como o grupo de suporte e grupo de sistemas. A figura 5.8 ilustra
uma notificação sendo encaminhada para os responsáveis:
79
Figura 5.8
Exemplo de
repasse de uma
notificação de
phishing.
A notificação da figura 5.8 pode ser dividida em duas partes: na parte de baixo, a notificação
original reportada em inglês tendo como destino o “cais@rnp.br”. Já na parte superior, o
CAIS/RNP encaminha a mensagem para o departamento responsável onde efetivamente a
máquina está alocada.
Por fim, o processo de “encaminhamento de incidentes” deve ser constantemente verifi-

cado, uma vez que os contatos que recebem esses repasses podem não mais existir ou
estarem temporariamente ausentes (férias).
Escalação de incidentes
Uma das atribuições da equipe do CSIRT é monitorar os incidentes relativos à sua instituição
e acompanhar até que seja solucionado. Em casos específicos, no entanto, um incidente de
segurança deve receber cuidados redobrados ou ainda ter a sua prioridade de tratamento
escalada. Tais casos podem compreender: a) incidentes que passam por um longo período
até que as devidas ações sejam tomadas; e, b) incidentes de segurança reincidentes asso-
ciados a um mesmo dispositivo. De forma complementar, são apresentados alguns exem-
plos de incidentes que podem determinar ações relativas à escalação de incidentes, sendo:
11 Restauração de um backup com as mesmas vulnerabilidades utilizadas para compro-

meter o sistema;
11 Dispositivos na mesma rede comprometidos e com acesso livre ao sistema reincidente;
11 Credenciais de acesso comprometidas;
80
11 Processo de resolução e recuperação dos dispositivos mal executada;
11 Exposição de informações sensíveis.
Nesses casos onde é necessário “escalar” um incidente, o CSIRT deve estabelecer procedi-
mentos internos onde diferentes membros são contatados e inseridos no processo de reso-
lução do incidente. Uma prática comum é ter contatos mais específicos (gestores) onde eles são
contatos em incidentes de alto impacto ou ainda que necessitem de uma pronta intervenção.
Notificação de incidentes
A notificação de incidente é um aspecto-chave no processo de resolução de incidentes. q
Essa etapa não envolve apenas contatar os responsáveis, mas sim comunicar-se com
outras equipes descrevendo fatos relevantes de maneira a auxiliar no processo de
solução do problema.
Uma notificação de um incidente deve prover elementos suficientes para que as partes envolvidas
possam investigar e confirmar a existência de uma violação de segurança. A descrição do inci-
dente deve ser concisa, indicando o tipo de ataque e, caso for desejável, qual o impacto resultante.
Existem algumas informações que são fundamentais e devem estar presentes em uma q
notificação, tal como:
11 Contato de quem reportou o e-mail;
11 Endereço IP de origem do ataque;
11 Endereço IP ou rede de destino do ataque;
11 Horários relacionados ao ataque, com indicação de fuso horário;
11 Logs associados com o ataque;
11 Descrição do ataque;
11 Envio das informações em formato de texto.
Não existe necessidade de enviar um arquivo de logs muito grande (alguns megabytes).
Apenas um trecho é suficiente para investigar o incidente. Se necessário, nas próximas inte-
rações com os responsáveis pode-se incluir logs adicionais para complementação.
A seguir, um trecho de log que descreve um acesso indevido ao serviço SSH.
2013-09-30 22:07:28 PST X.X.X.17/2231-> xxx.xxx.xxx.xxx/22

Com essas informações do log os responsáveis podem pesquisar pelos eventos no firewall/NAT
de modo a confirmar a existência de tal varredura e também identificar outros dispositivos
envolvidos no mesmo incidente.
Em algumas situações, a notificação de um incidente não apresenta dados suficientes para

análise. Nesses casos, cabe à equipe solicitar os responsáveis por dados complementares.
De fato, nem sempre é possível conseguir mais detalhes do incidente, isso vai depender
da natureza do próprio incidente e de fatores específico do caso. Por exemplo, a falta de
aptidão técnica da pessoa que reportou o caso pode comprometer a análise.
Se for viável, o CSIRT deve cogitar a possibilidade de obter mais informações sobre q
o incidente usando diferentes contatos. Alguns pontos de contatos que podem ser
considerados pelo CSIRT:
11 Hierarquias superiores da instituição;
11 Financiadores;
11 Outros departamentos;
81
11 Administradores de sistemas; q
11 Auditores internos.
Da mesma forma, existem contatos que podem não estar diretamente relacionados com
um incidente, mas mesmo assim podem ser úteis para prover informações potencialmente
relevantes ao CSIRT.
Dessa forma, um CSIRT deve considerar e avaliar a necessidade de contatar entidades q

externas não relacionadas com o incidente em si, mas que podem ser úteis no processo de
investigação:
11 Vendedores (fabricantes);
11 Especialistas;
11 Outros CSIRT;
11 Provedores de rede (ISP);
11 Equipes de outros departamentos.
Nos casos onde um incidente é identificado pelo próprio CSIRT, cabe ao próprio time
notificar todas as partes envolvidas: máquinas da própria abrangência operacional do
CSIRT e máquinas externas.
Muitas vezes os CSIRTs apresentam procedimentos diferentes para lidar com notificações
internas e externas. A figura 5.9 ilustra exemplos de notificações enviadas pelo CSIRT para
entidades externas reportando incidentes de segurança:
Figura 5.9
Notificação
de um ataque
de força bruta
originada por uma
entidade externa
(200.x.10.10).
82
Na figura, o CSIRT da instituição está notificando um endereço IP externo – representado
por 200.x.10.10 – o qual realizou um ataque de força bruta destinado a uma das máquinas da
abrangência operacional do CSIRT. É importante observar o nível de detalhamento da men-
sagem. Nem sempre é necessário enviar todos os detalhes do incidente, mas sim apenas
informações que permitam com que a entidade envolvida investigue a notificação.
Em contraponto, a figura 5.10 ilustra um incidente notificado internamente e afetando somente

máquinas internas da própria instituição. Nesse caso, o nível de informação presente na notifi-
cação pode ser mais detalhado, incluindo informações do usuário do sistema afetado. Na noti-
ficação representada pela figura, por exemplo, são descritos o usuário da máquina, endereço
MAC, endereço IP e Sistema Operacional utilizado. Da mesma forma é exibido, na parte inferior
da notificação, informações sobre o incidente – varredura pelo serviço de administração
remota VNC – e os logs da ferramenta que identificou o incidente. O objetivo desse detalha-
mento é auxiliar os responsáveis a solucionar o problema de forma mais rápida possível.

Figura 5.10
Notificação de
incidente interno.
Essas mesmas ações, aplicadas a uma notificação externa, poderiam expor excessi-
vamente os sistemas internos de uma instituição.
Dando sequência aos exemplos de notificações, é apresentada uma notificação de phishing

na figura 5.11. Na referida notificação está sendo reportado um servidor que está hospe-
dando um website falso com o intuito de roubar informações dos usuários da instituição
financeira Banco do Brasil. Esse incidente foi identificado internamente, através da análise
dos spams recebidos pelos usuários. É importante notar que a notificação está copiando os
responsáveis pela rede e também os demais envolvidos com a marca.
83
Figura 5.11
Notificação de
phishing.
As notificações exibidas até agora demonstraram exemplos de como um CSIRT pode noti-
ficar as partes envolvidas com um evento de segurança. Agora, no processo reverso, onde
as notificações de incidentes são recebidas, tudo é muito semelhante.
Um CSIRT pode receber notificações de entidades externas e também da sua própria comu-
nidade de atuação. Todas as notificações recebidas passam por um fluxo de tratamento de
informações previamente definidos. Na figura 5.12, por exemplo, é ilustrado um possível
fluxo de dados de uma notificação recebida.
interno externo
Internet
Instituição CSIRT
Figura 5.12
Recebimento de
resolução resolução notificações de
incidentes.
Toda notificação recebida – representada pelo envelope – é analisada pela equipe e direcio-
nada para que as ações cabíveis sejam tomadas a fim de solucionar o incidente. Essa etapa
compreende interagir com as partes envolvidas e assegurar que o incidente foi solucionado.
Como resultado, o CSIRT pode encerrar o incidente ou ainda notificar novas partes envol-
vidas em decorrência dos novos fatos identificados na investigação realizada.
84
Boas práticas para a notificação de incidentes de segurança
11 Quando reportar e-mails para outros países, recomenda-se a utilização do idioma q
inglês. Mesmo em países onde o inglês não é a primeira língua, os times nacionais
estão preparados para entender o idioma. Deve-se evitar o uso de tradutores
automáticos (Google Translator, Yahoo Translator e Babelfish). Esses corretores nem
sempre são eficientes no contexto técnico e podem tornar a notificação incompreen-
sível para o destinatário;
11 Deixar evidente as informações básicas do incidente reportado. Por exemplo, ao reportar

uma página falsa, é importante deixar a URL em questão visível, ou seja, destacada do
texto. Dessa forma, um analista pode facilmente identificar e avaliar o incidente;
11 O assunto da notificação deve ser claro o suficiente para o analista inferir o conteúdo
reportado. Evitar assuntos genéricos do tipo: “pedido de ajuda”, “incidente de segu-
rança”, ou ainda “urgente”. Em vez de assuntos genéricos, dar preferência a assuntos
tal como: “acesso não autorizado”, “phishing em: XXXX”;
11 O uso de templates é bastante comum para notificar incidentes de segurança.

Sabe-se, no entanto, que mensagens diretas e direcionadas são mais efetivas para
a resolução de um incidente. Sendo assim, mesmo usando templates padronizados
para reportar incidentes, aconselha-se o uso de mensagens direcionadas e sucintas
em incidentes de maior impacto;
11 A resolução de um incidente passa por uma colaboração entre equipes. Reco-

menda-se armazenar os contatos que foram efetivos e prestativos no processo de
resolução de problemas, que podem ser úteis em um momento de crise;
11 Para a troca de informações via e-mail, preferir a utilização de texto sem formatação.
Deve-se evitar enviar notificações em formato HTML ou ainda informações contidas
em imagens (captura de tela).
11 Data Breach Notification Toolkit:

http://www.stonesoup.org/Meetings/0509/enter.pres/blair3.ppt
11 Data Incident Notification Templates:

http://www.educause.edu/ir/library/pdf/CSD4237.pdf
11 Internet Worm Propagation:

http://www.model.in.tum.de/um/courses/seminar/worm/WS0405/misslinger.pdf
11 NIST SP 800-61: Computer Security Incident Handling Guide:

http://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf
85
86
6
objetivos
Identificação de contatos
Identificar as partes envolvidas no incidente; Utilizar diferentes ferramentas para
identificar os responsáveis; Conhecer diferentes técnicas para investigação de contatos.
conceitos
Diferença entre contatos de redes e contatos de domínios de redes; Boas práticas
no processo de identificação de contatos.
Introdução
A identificação de contato, ou seja, identificar os responsáveis envolvidos em um incidente
de segurança, é uma etapa crucial no processo de resposta a incidentes.
A habilidade de comunicar-se com as partes interessadas no processo possibilita com q

que o CSIRT:
11 Troque informações sobre a segurança do incidente em si;
11 Melhore o entendimento das atividades relacionadas ao comprometimento;
11 Identifique possíveis novas vulnerabilidades;
11 Aprimore a segurança dos sistemas.
Identificar os responsáveis por uma instituição envolve investigar as diferentes informações

relativas ao incidente de segurança. Sabe-se que toda informação pode ser útil no processo
de análise; no entanto, uma das tarefas fundamentais desempenhadas pelo CSIRT é identi-
ficar informações relevantes para conduzir a investigação. Nesse processo, são analisadas
informações contidas pela própria notificação do incidente ou ainda nos dados identificados
pela própria equipe. Tais dados, reportados por outros administradores ou disponíveis em
logs de ferramentas automatizadas de segurança, são essenciais para a rápida identificação
Capítulo 6 - Identificação de contatos
dos contatos. Por exemplo, um endereço IP – ou domínio de rede – tende a revelar informa-
ções sobre a origem dos ataques e também dados de outros sistemas afetados diretamente
relacionados com o incidente a ser investigado.
A etapa de identificar contatos pode parecer simples, mas não deve ser subestimada. Muitas
vezes, identificar o contato efetivo das partes envolvidas com o incidente pode ser dispen-
dioso. Nem sempre é fácil encontrar informações de contatos atualizados e equipes res-
ponsivas por trás de uma informação de contato. Isso se deve a diversos fatores, como por
exemplo, a própria característica dinâmica das redes, onde constantemente ocorrem fusões
de empresa, aquisições de novos blocos de endereçamentos e novos domínios.
87
Diante disso, é interessante que os CSIRTs estejam preparados para lidar com essas tarefas
conhecendo ferramentas e técnicas que podem ser empregadas na busca de informações
de contato.
Cada time implementa uma sequência de etapas para ser utilizada na obtenção de q
informações de contato, como por exemplo:
11 Localizar contatos na própria base de dados do CSIRT;
11 Consultar informações no sistema WHOIS;
11 Consultar informações adicionais (fontes públicas e websites);
Infelizmente não existe roteiro pré-definido para a obtenção de contatos de forma efetiva.
Algumas etapas são comuns (consulta à base WHOIS, por exemplo); no entanto, existem
outras etapas de um roteiro para obtenção de contatos que são customizadas. Nota-se
que boa parte dos CSIRTs possui ferramentas customizadas para localização de informa-
ções de contato, as quais compõem informações de diferentes bases de contatos.
Alguns CSIRTs ainda optam por armazenar informações de contatos em uma base de dados
interna. Tipicamente, um CSIRT possui um conjunto de contatos mais específicos que
podem ser utilizados para notificar incidentes fora do padrão. Esses contatos mais especí-
ficos podem ser e-mails pessoais ou, ainda, e-mails de equipes de resposta a incidentes de
segundo nível. Boa parte desses contatos são fruto de relacionamento e de cooperação com
outras entidades e CSIRTs. Cabe lembrar que o gerenciamento dos contatos armazenados
pelo CSIRT deve ser constantemente atualizado, pois muitas vezes essas informações são
esquecidas e tornam-se inválidas.
Na sequência, são apresentadas algumas técnicas que podem ser úteis no processo de resposta
a incidentes de segurança no que tange a identificação das partes envolvidas em um incidente.
Identificação de contatos
Um das primeiras etapas para identificar os contatos dos responsáveis é analisar os q
dados do incidente de segurança em busca de domínio e endereços IPs relacionados
com a atividade investigada. Uma vez identificadas as informações, pode-se:
Traduzir domínios de redes para endereços IP (domínio > IP)

Existem diferentes formas para converter um IP em domínio de rede, desde ferramentas q
online a ferramentas presentes em múltiplos Sistemas Operacionais. A seguir é exempli-
ficado o uso da ferramenta nslookup para a tradução do nome:
$> nslookup www.rnp.br
Non-authoritative answer:
Name: www.rnp.br
Address: 200.130.35.4
Traduzir o endereço IP para domínios de redes (IP > domínio)

O mesmo comando apresentado anteriormente pode ser utilizado para realizar o pro- q
cesso inverso, ou seja, mapear o reverso de um endereço IP:
$> nslookup 200.130.35.4
Non-authoritative answer:
4.35.130.200.in-addr.arpa name = kerberos.na-df.rnp.br.

88
Nem todo endereço IP pode ter um nome de rede associado – essa associação não é uma q
regra. Existem IPs que não estão associados a nenhum nome de rede. Esses endereços
que não possuem nomes associados, ou ainda que não possuem resolução de nome de
reverso, geralmente tendem a demandar diferentes técnicas no processo de investigação
dos responsáveis, mas mesmo assim é perfeitamente factível obter informações de
contato. Sendo assim, certos comandos podem auxiliar na etapa de investigação prévia.
Por fim, é fundamental lembrar que as informações de resolução de nomes são dinâmicas.
Um determinado domínio pode ser traduzido para um endereço IP; no entanto, não existe
garantia de que essa informação permaneça inalterada. Durante a investigação de um
incidente, um determinado domínio pode ter a sua resolução alterada para outro IP. Isso é
muito comum em casos de phishing, onde um domínio malicioso está associado a um IP, e
quando esse domínio malicioso é bloqueado passa a ser associado a um IP de bloqueio, tal
como 127.0.0.1. Logo, em um processo de investigação e análise de incidentes, não se pode
confiar apenas nos nomes de rede. Devem-se documentar todas as informações, tal qual
foram observadas na etapa de investigação do incidente.
Serviço WHOIS
A maneira mais simples de localizar informações de contatos é consultar o serviço de q
WHOIS. O WHOIS é uma base de dados distribuída e provida por entidades de registro
que permite obter informações de recursos da internet, tais como:
11 Domínios de redes;
11 Endereçamentos IPs;
11 Sistemas autônomos.
Essa base de dados (WHOIS) é mantida pelos grandes operadores e detentores de registros
da internet. As informações relativas a endereçamento IP são mantidas por entidades regio-
nais denominadas Regional Internet Registries (RIRs). O mundo está dividido em cinco RIRs,
listadas na sequência:
11 American Registry for Internet Numbers (ARIN): Canadá, partes do Caribe e ilhas do
Atlântico Norte – http://www.arin.net/whois
11 Asia Pacific Network Information Centre (APNIC): Partes da Ásia e Regiões da Oceania
– http://www.apnic.net/search
11 Latin American and Caribbean Internet Addresses Registry (LACNIC): América Latina
e regiões do Caribe – http://lacnic.net/cgi-bin/lacnic/whois
11 Réseaux IP Européens (RIPE): Europa, Oriente médio e Ásia Central –

http://www.ripe.net/perl/whois
11 Africa Regional Internet Registry (AFRINIC): África e algumas regiões do Oceano Índico
– http://www.afrinic.net/cgi-bin/whois
A distribuição dos endereços IPs da internet é realizada pela Internet Assigned Name Authority
(IANA), que por sua vez aloca os recursos para os RIRs, que gerenciam localmente as informa-
ções repassadas e possuem autoridade para realizar realocações dentro de sua área geográfica.
Como, por exemplo, o LACNIC – que é um RIR – pode repassar blocos de endereçamento
para os National Internet Registry, tal como o Núcleo de Informação e Coordenação do
Ponto BR (NIC.br).
89
Embora não exista uma especificação padrão relativa às informações que devem ser q
disponibilizas pelos serviços de WHOIS, existe um subconjunto de informações típicas
que podem ser encontradas na maioria das bases de dados WHOIS, sendo:
11 Bloco de endereçamento IP;
11 Informações sobre o detentor do bloco;
11 Servidor DNS autoritário;
11 Contato técnico;
11 Contato para notificar abusos;
11 Informações sobre um WHOIS adicional.
A consulta a uma base de WHOIS pode ser realizada usando diferentes interfaces, entre elas,
interface web ou ainda por meio de aplicativos específicos amplamente disponíveis nos mais
diversos Sistemas Operacionais. Para isso, o WHOIS define um protocolo próprio para consulta
de informações de texto claro em uma base de dados. O protocolo é especificado pela RFC 812,
e posteriormente atualizado pela RFC 3912, utilizando a porta de comunicação 43/TCP.
As consultas para a base de dados do WHOIS podem ser realizadas pelo comando homó-
logo, ou seja, o comando whois – posteriormente ilustrado. Também é possível encontrar
outras ferramentas online especializadas na consulta de informações do serviço WHOIS.
Algumas ferramentas, por exemplo, conseguem seguir recursivamente as diferentes q

bases de dados para identificar informações de contato. Serviços para consulta online:
11 All Whois: http://www.allwhois.com/
11 Better Whois: http://betterwhois.com/
11 Geek Tools: http://www.geektools.com/whois.php
11 Cyberabuse WHOIS: http://www.fr2.cyberabuse.org/whois/?page=whois_server
11 Team Cymru WHOIS: http://asn.cymru.com/cgi-bin/whois.cgi
11 DNSstuff Tools Page: http://www.dnsstuff.com/pages/expert.htm
Na sequência, são exemplificadas com maior nível de detalhamento as diferentes formas de

obter informações dos principais recursos da internet. Inicialmente dados dos domínios de
rede, e posteriormente endereçamento IP.
National Internet Registry

Os National Internet Registry são organizações abaixo dos RIRs (LACNIC, APNIC, ARIN, q
RIPE e AFRINIC), cujo objetivo é gerenciar e coordenar recursos de internet nacionalmente.
Existem poucos países que gerenciam recursos de endereçamento em nível regional.
Na América Latina, temos:
11 NIC México: http://www.nic.mx/
11 NIC Brasil: http://www.nic.br/
11 NIC Chile: http://www.nic.cl/
90
Em outras regiões, podemos citar:
11 China Internet Network Information Center (CNNIC);
11 Japan Network Information Center (JPNIC);
11 Korea Internet & Security Agency (KRNIC);
11 Taiwan Network Information Center (TWNIC);
11 Vietnam Internet Network Information Center (VNNIC).
Essas entidades também são úteis na identificação dos responsáveis por uma determinada
rede. Boa parte dos NIR disponibiliza sistema de WHOIS para consultar informações de con-
tatos mais específicos dos recursos de internet alocados pelo próprio.
Domínios de rede
Um domínio de rede pode ser considerado um identificador único que pode ser q
mapeado para um endereço de rede.
Por exemplo, o domínio “www.exemplo.com.br” pode ser mapeado, via sistema de Domain
Name System (DNS), para um endereço IP específico.
A equipe de um CSIRT deve ter ciência de que um domínio de rede geralmente possui infor-
mações de contato diferente do respectivo endereço IP designado. Tipicamente, o contato
de um domínio de rede é um administrador de sistemas, ao passo que o contato de um
endereço IP corresponde a um provedor de rede.
Como de conhecimento, os domínios de redes são alocados por diferentes instituições, ou

entidades provedoras de registro de domínio. No Brasil, temos o Registro.br, que é respon-
sável pelo registro de nomes terminados com “.br”.
Um dos serviços providos pelo Registro.br é uma base de informação (WHOIS) com infor-
mações de recursos de endereçamento e nomes de domínios alocados pela entidade.
O Registro.br, por sua vez, disponibiliza um conjunto de informações bem amplo na sua q
base de dados WHOIS, compreendendo:
11 Domínio;
11 Instituição;
11 CPF ou CNPF;
11 Responsável técnico;
11 Responsável administrativo;
11 Data de criação do domínio;
11 Data da última atualização dos dados do domínio;

11 Data da expiração.
Todas as informações disponibilizadas são públicas e podem ser consultadas via interface
web ou serviços baseados no protocolo WHOIS. A seguir, um exemplo de uma consulta pelo
domínio “rnp.br” utilizando a interface web do Registro.br:
91
% Copyright (c) Nic.br
% A utilização dos dados abaixo é permetida somente conforme
% descrito no Termo de Uso (http://registro.br/termo), sendo
% proibida a sua disiribuição, comercialização ou reprodução,
% em particular para fins publicitários ou propósitos
%similares.
% 2013-11-07 21:15:48 (BRST -02:00)
dominio: rnp.br
titular: Associação Rede Nacional de Ensino e Pesquisa
documento: 003.508.097/0001-36
responsável: Nelson Simões Silva
pais: BR
c-titular: RCO217
c-admin: NES
c-técnico: FRK16
c-cobrança: RCO217
servidor DNS: teyr.na-cp.rnp.br 200.130.25.17 2001:12f0.3f:3::11
status DHS: 07/11/2013 AA
último AA: 07/11/2013
servidor DNS: bellana.nc-rj.rnp.br 200.143.193.3 2001:12f0:3e:102::3
status DNS: 07/11/2013 AA
último AA: 07/11/2013
servidor DNS: lua.na-df.rnp.br 200.130.77.69 2001:12f0:3d:102::45
último AA: 07/11/2013
registro DS: 51124 RSA/SHA-1 4ED9FC74C63C99E52E2FC492517C73AEFAC316F2
status DS: 03/11/2013 DSOK
último OK: 03/11/2013
criado: antes de 01/01/1995
alterado: 25/11/2011
status: publicado
Contato (ID): FRK16

nome: Flavio Rosa Kaatz
e-mail: flavio@rnp.br
criado: 07/05/2000
contato (ID): NES

nome: Nelson Simões
e-mail: nelson@na-df.rnp.br
criado: 18/12/1997
Contato (ID): RCO217

nome: RNP - Centro de Engenharia e Operações
e-mail: registro@rnp.br
criado: 06/04/2006
92
% Problemas de seguranga e spam também devem ser reportados ao

% cert.br, http://cert.br/, respectivamente para cert@cert.br
% e mail-abuse@cert.br
contato (ID): NES
nome: Nelson Simões
e-mail: nelson@na-df.rnp.br
criado: 18/12/1997
Contato (ID): RCO217

criado: 06/04/2006
% Problemas de seguranga e spam também devem ser reportados ao

Figura 6.1
Consultando %
informações do % whois.registro.br aceita somente consultas diretas. Tinos
domínio ‘rnp.br’
% de consultas são: dominio (.br), titular (entidade),
via interface do
Registro.br. % ticket, provedor, contato (ID), bloco CIDR, IP e ASN.
Como pode ser observado na Figura 6.1, é possível identificar informações que podem ser
relevantes para o processo de resposta a incidentes, tais como:
11 Contato administrativo: nelson@na-df.rnp.br;
11 Contato técnico: flavio@rnp.br.
Além das informações de contato, os dados disponibilizados pelo WHOIS permitem que sejam
realizadas certas análises.
É possível correlacionar informações das entidades e até mesmo identificar domínios q

suspeitos. Algumas características que podem revelar domínios suspeitos são:
11 Domínio foi criado ou atualizado recentemente. A maioria dos domínios não é atuali-
zada de forma requente;
11 O domínio é escrito de maneira muito similar a um domínio já conhecido;
11 Domínio é inteiramente gerado por letras e números aleatórios. Pode ser um domínio
gerado por malwares com o objetivo exclusivo de evitar a detecção de um comprome-
timento (DGA – Domain Generation Algorithm);
11 Informações dos registradores ou de contato ausentes;
11 O domínio está listado em algumas listas de bloqueio ou está associado a atividades

maliciosas (buscadores).
O serviço de WHOIS mantido pelo Registro.br, permite consultar informações usando

diferentes campos da base de dado, tal como o CPF/CNPF da entidade. Para isso, utiliza-se a
seguinte sintaxe:
whois -h whois.registro.br CPF/CNPF

Esse tipo de consulta é útil para correlacionar informações de registro. Uma simples consulta,
como exemplificado, pode revelar todos os domínios registrados por uma única entidade.
A consulta a seguir ilustra uma entidade que possui apenas quatro domínios registrados.
owner: NOME SOBRENOME
ownerid: XXX.XXX.XXX-XX
owner-c: XXXXXXX
created: 20151217
created: 20151217
93
domain: babcobradesco.com.br
domain: bancobradeaco.com.br
domain: calxa.gov.br
e-mail: reidomalware@terradonunca.xxx
Como ilustrado, todos os domínios registrados são domínios suspeitos. Afinal, são domínios
criados recentemente e com grafia similar à de instituições financeiras conhecidas. Utilizar
essas informações de contato para um domínio suspeito não é recomendado. Afinal, as
informações de contatos foram providas pelos próprios fraudados e, portanto, podem ser
falsas. No exemplo, o contato da entidade para denunciar abusos relacionados com os
domínios é o endereço de e-mail: “reidomalware@terradonunca.xxx”. Logo, enviar uma
notificação para o responsável da entidade servirá apenas para notificar o atacante de que
suas atividades foram identificadas.
As irregularidades encontradas em domínios registrados pelo Registro.br podem ser

denunciadas para: hostmaster@resgistro.br ou http://registro.br/contate.html
Encontre todos os domínios que foram registrados pela mesma entidade que registrou o
domínio “rnp.br”. Se por algum motivo essa informação não estiver disponível via linha de
comando, utilize a interface Web em http://www.registro.br/.
Endereçamento IP
A equipe do CSIRT deve estar preparada para lidar com as informações providas pelo ende-
reçamento de uma instituição. Obviamente, o primeiro passo é identificar corretamente o
endereço de origem dos ataques, o que pode requerer um esforço considerável por parte
da equipe. Em alguns incidentes os atacantes tomam certos cuidados para acobertar a sua
origem. Assumindo que o endereço de origem tenha sido determinado, este pode ser utili-
zado para identificar os responsáveis.
q
Os responsáveis pelo endereçamento IP são instituições que efetivamente passam por

um processo de solicitação de blocos junto a um RIR responsável. Grande parte das
instituições, no entanto, utiliza endereçamento sublocado por um provedor de acesso
à internet (ISP).
Por exemplo, muitas instituições conectadas na RNP recebem um bloco de endereçamento

diretamente da RNP. No entanto, esse endereçamento continua sendo de responsabilidade
da RNP, afinal, foi a própria RNP que solicitou o endereçamento ao RIR local (Lacnic).
Durante uma investigação, é muito comum encontrar dados de um provedor de acesso

quando se consulta a base WHOIS por um endereçamento IP de uma determinada instituição.
94
Essas informações de contato podem ser efetivas, afinal, muitos provedores de rede
implementam mecanismos para receber solicitações e responder incidentes de segurança.
Por outro lado, alguns provedores são responsáveis por uma grande quantidade de blocos
de endereçamento e não escalam o volume de solicitações referentes ao processo de
O sistema de WHOIS também disponibiliza informações de alocação IP, o que inclui infor- q
mações de contato (endereços de e-mail e nome dos responsáveis).
É importante notar que o conjunto de informações de alocação de IP disponibilizado pelo

WHOIS é ligeiramente diferente das informações de um nome de rede (vide figura 6.1 versus
figura 6.2). Na figura, é ilustrado o resultado de uma pesquisa pelo IP 200.130.35.4.
% Copyright (4) Nic.br

% A utilização dos dados abaixo é permitida somente conforme
% descrito no Termo de Uso (http://registro.br/termo), sendo
% proibida a sua distribuição, comercialização ou reprodução,
% em particular para fins publicitários ou propósitos similares.
% 2013-11-07 21:39:26 (BRST -02:00)
inetnum: 200.130/16
asn: AS1916
cabusos: SIC128
titular: Associação Rede Nacional de Ensino e Pesquisa
documento: 003.508.097/0001-36
responsável: Nelson Simões Silva
país: BR
c-titular: RC0217
c-técnico: RC0217
inetrev: 200.130.35/24
servidor DNS: lua.na-df.rnp.br
ultimo AA: 07/11/2013
servidor DNS: teyr.na-cp.rnp.br
status DOS: 07/11/2013 AA
último AA: 07/11/2013
servidor DNS: bellana.nc-rj.rnp.br
último AA: 07/11/2013
criado: 15/02/2000
Contato (ID): RC0217

criado: 06/04/2006
Contato (ID): SIC128

nome: Security Incidents Response Center 95
e-mail: cais@cais.rnp.br
criado: 17/04/2002
Contato (ID): RC0217
criado: 06/04/2006
Contato (ID): SIC128

nome: Security Incidents Response Center
e-mail: cais@cais.rnp.br
criado: 17/04/2002
% Problemas de seguranga e spam tamben devem ser reportados ao

% Figura 6.2
Consultando
% whois.registro.br aceita somente consultas diretas. Tipos informações de
% de consultas são: dominio (.br), titular (entidade), endereçamento IP
via interface web do
% ticket, provedor, contato (ID), blow CIDR, IP e ASN.
Registro.br.
As seguintes informações podem ser identificadas: q

11 Bloco de endereçamento: 200.130/16. Ou seja, o responsável pelo endereço
200.130.35.4 também é responsável por todos os endereços do bloco totalizando
65534 IPs;
11 Servidores DNS: lua.na-df.rnp.br, teyr.na-cp.rnp.br, bellana.nc-rj.rnp.br;
11 Contato técnico: registro@rnp.br;
11 País de alocação: BR – Brasil;
11 Contato de segurança: cais@cais.rnp.br.
De posse dessas informações, a equipe do CSIRT pode contatar os responsáveis por um

endereço IP identificado em um determinado incidente. O CSIRT deve priorizar as informações
de contato de IPs frente as informações providas pelos domínios de rede. Lembrando que as
informações de domínios são mutáveis, ou seja, no momento da ocorrência de um incidente,
um domínio pode corresponder a um IP e no momento seguinte pode ser designado a outro IP.
Consulte a base de dados WHOIS usando sua ferramenta de preferência (sistema ou ferra-
menta online) e complete a tabela a seguir:
11 Certifique-se de que os contatos estão corretos;
11 Identifique o país de alocação do IP;
11 Identifique o CSIRT de coordenação.

IP Contato Contato correto País CSIRT de coordenação
218.234.18.106 abuse@hanaro.com
71.240.222.159 abuse@verizon.net
200.204.153.97 security@telesp.net.br
84.63.113.123 abuse@arcor-ip.de
143.54.1.20 tri@ufrgs.br
196.216.2.136 abuse@godaddy.com
96
Muitas vezes, a identificação dos contatos é direta e os e-mails dos responsáveis podem
ser facilmente identificados. Em outros casos, no entanto, é necessário utilizar dife-
rentes métodos e meios de conseguir um contato funcional para reportar um incidente.
Na sequência, alguns métodos são descritos.
Recursos adicionais
Como exemplificado, os diferentes recursos de internet podem apresentar responsáveis
distintos. Um domínio de rede (www.exemplo.com.br) possui informações de contato que
geralmente são diferentes do respectivo endereço IP associado.
Muitas vezes, mesmo utilizando os diferentes contatos identificados via WHOIS, não se
obtêm um resultado satisfatório. Logo, as informações providas no sistema de WHOIS, como
demonstrado anteriormente, podem ser utilizadas como ponto de partida para contatar
os responsáveis. No entanto, nem sempre essas informações estão disponíveis ou estão
desatualizadas. Nesses casos, onde não se têm um contato funcional, o CSIRT deve usar
diferentes métodos e meios de comunicar as partes envolvidas.
Infelizmente não existe uma maneira padrão de contatar uma instituição. De fato, existem
alguns esforços que visam padronizar a forma de contatar instituições relativas a questões
de segurança e administração de redes.
Um dos esforços é descrito na RFC 2142, que recomenda endereços de e-mail

comuns que cada instituição deveria ter para facilitar o contato, tal como os e-mails
security@<dominio> ou csirt@<dominio>, para contato de segurança.
No entanto, essa boa prática de configuração não é implementada globalmente pelas

instituições, por diversos fatores, como por exemplo o grande volume de spam recebido
por essas contas ou, ainda, por desconhecimento dos administradores. Sendo assim, é
fundamental que a equipe de um CSIRT seja apta a utilizar diferentes técnicas e ferramentas
adicionais para complementar a investigação dos responsáveis por recursos de rede.
Na sequência são apresentadas algumas ferramentas e também alguns serviços publica-

mente disponíveis para consulta de dados.
Ferramentas
Existe um conjunto de ferramentas que podem ser utilizadas para obter informações de um
determinado IP ou domínio envolvido com incidentes. Algumas ferramentas são amplamente
utilizadas pela equipe do CSIRT para investigar a conectividade e acessibilidade de sistemas.
No entanto, as mesmas ferramentas podem ser utilizadas no contexto da resposta a incidentes,
mais especificamente na identificação de responsáveis por recursos de rede. Entre elas:
traceroute
traceroute <endereço>
O comando traceroute – ou o seu equivalente em sistemas Windows, tracert – exibe todos os

hosts intermediários entre a máquina onde o comando é executado até o endereço destino.
De uma forma geral, o comando traceroute pode ser utilizado para identificar a rota por
onde o fluxo de pacotes é encaminhado. No processo de resposta a incidentes, a rota por
onde o fluxo de pacotes é encaminhado pode revelar informações de contato de um deter-
minado IP suspeito, entre elas:
97
11 Identificar o provedor de acesso (ISP): os hosts intermediários podem identificar dados
do provedor de acesso ou provedor de conteúdo utilizado pelo IP suspeito. Nesses casos,
onde o contato do IP suspeito não está acessível, pode-se contatar o provedor para obter
mais informações ou ainda solicitar que uma notificação seja encaminha ao cliente;
11 Identificar o CERT: assim como o provedor, o nome dos hosts intermediários (reverso)
pode revelar qual é o país onde o IP suspeito está localizado. Com isso, pode-se solicitar
auxílio para um CSIRT nacional para que contatos mais específicos sejam ativados.
A figura 6.3 ilustra o resultado do comando traceroute usando um IP arbitrário e como as

informações podem ser úteis para identificar responsáveis por um endereçamento.
$ traceroute 143.54.1.20
traceroute to 143.54.1.20 (143.54.1.20), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 1.165 ms 2.219 ms 2.817 ms
2 200.150.185.1 (200.150.185.1) 12.053 ms 14.801 ms 15.101 ms
3 200-170-105-65.user.ajato.com.br (200.170.105.65) 15.578 ms
15.933 ms 21.064 ms
4 200.170.100.2 (200.170.100.2) 35.531 ms 35.983 ms 36.210 ms
5 200-170-96-193.spo.vaughan.ajato.com.br (200.170.96.193) 39.090
ms 39.667 ms 40.549 ms
6 as1916.sp.ptt.br (187.16.216.4) 39.367 ms 9.693 ms 13.778 ms
7 sp-sc-10g-oi.bkb.rnp.br (200.143.252.66) 44.136 ms 44.117 ms
sp-pr-10g-oi.bkb.rnp.br (20 0.143.252.62) 16.844 ms
8 sc-rs-10g-oi.bkb.rnp.br (200.143.252.57) 34.298 ms 34.280 ms
pr-rs-10g-oi.bkb.rnp.br (20 0.143.252.53) 35.368 ms
9 200.143.255.162 (200.143.255.162) 32.738 ms 33.202 ms 34.432 ms
Figura 6.3
10 ufrgs-ve-40-mlx4.tche.br (200.19.240.14) 39.066 ms 39.032 ms 39.007 ms Traceroute: hosts
11 lfs-in.ufrgs.br (143.54.0.241) 38.994 ms 39.293 ms 39.219 ms intermediários
12 penta.ufrgs.br (143.54.1.20) 31.745 ms 30.333 ms 36.441 ms até o destino
143.54.1.20.
No exemplo citado, foi utilizado um IP arbitrário “143.54.1.20” como exemplo. Cada linha
representa um host intermediário por onde o fluxo de pacotes passou para atingir o alvo.
Como pode ser observado, o alvo (143.54.1.20) possui 11 hosts intermediários a partir da
máquina em que o comando foi executado. Na maioria dos casos, os reversos dos hosts
intermediários revelam dados do provedor e localização; nas linhas 3-5 é possível inferir que
o pacote passou pelo backbone da operadora “ajato.com.br”. Na sequência, o pacote entra
no ponto de troca de tráfego (sp.ptt.br) e acessa o backbone da RNP. Como destino, o pacote
chega à rede da Universidade Federal do Rio Grande do Sul.
Nesse exemplo da figura, as seguintes informações podem ser utilizadas para tentar encon-
trar os responsáveis pelo IP suspeito:
11 Provedor de trânsito do IP suspeito é a RNP: sendo assim, uma notificação poderia ser
enviada para os contatos de segurança da RNP;
11 O IP está localizado na infraestrutura da Universidade Federal do Rio Grande do Sul: a

universidade possui um CSIRT próprio o qual poderia ser contatado para investigar o
possível incidente.
98
Dig
Dig é uma ferramenta via linha utilizada para consultar servidor de nomes (DNS). O Dig é
muito versátil e consegue obter diversas informações sobre recursos de rede permitindo
diferentes tipos de consultas, tais como:
11 A (endereço de rede);
11 ANY (todas as informações disponíveis);
11 MX (servidores de e-mails);
11 NS (servidores de nomes DNS);
11 SOA (Start of Authority Record);
11 HINFO (informações do host);
11 AXFR (transferência de zona).
Por padrão, a consulta básica realizada é uma pergunta pelo tipo A (Address), ou seja, o ende-
reço IP associado ao domínio requisitado. Os outros tipos de consultas devem ser especificados.
Como por exemplo, para consultar todos os servidores de e-mails associados a um q

determinado domínio, utilizando o comando a seguir:
$ dig domínio MX
O reverso também pode ser consultado usando o comando dig. Para requisitar uma
consulta reversa – IP para domínio –, o seguinte comando pode ser utilizado:
$ dig –x IP +short
Da mesma forma, a ferramenta permite identificar a versão de um determinado servidor

de DNS:
dig @<servidor> chaos txt version.bind
A ferramenta Dig utiliza por padrão o servidor DNS da própria rede para consultar infor-
mações; no entanto, esse comportamento pode ser alterado. Na consulta a seguir, por
exemplo, é especificado via parâmetro um servidor de DNS. No comando exemplificado
a seguir o servidor de DNS “8.8.8.8” – servidor DNS público do Google – é utilizada para
resolver o nome “www.rnp.br”.
$ dig @8.8.8.8 www.rnp.br
Outro tipo de pesquisa que pode ser útil no contexto de localização de contatos é a con-
sulta por registros do tipo SOA. Para cada domínio DNS existe um tipo especial de registro
denominado SOA (Start of Authority). O registro SOA possui um campo com informações
de contato onde um endereço de e-mail é fornecido. Essas informações podem ser obtidas
utilizando as ferramentas tradicionais de busca por nomes: dig, host e ferramentas web.
Uma consulta por registro do tipo SOA, usando o comando dig, é exemplificado a seguir:
Figura 6.4
consulta por $ dig rnp.br soa +short
informações do teyr.na-cp.rnp.br. sti.rnp.br. 2013111402 10800 3600 604800 86400
registro SOA.
99
Como resultado, a consulta ao domínio “rnp.br” apresentado na figura teve como q
resposta os seguintes valores:
11 teyr.na-cp.rnp.br: servidor primário da zona rnp.br;
11 sti.rnp.br: é um endereço de e-mail de contato. Em vez do formato tradicional

“usuário@domínio”, esse campo deve ser traduzido para sti@rnp.br;
11 2013111402: número serial da zona do DNS;
11 10800: taxa de atualização (3h);
11 3600: tempo entre realizar uma nova transferência (60 minutos);
11 604800: expiração da zona – 7 dias;
11 86400: mínimo (1 dia).
Logo, o contato de e-mail identificado pode ser mais uma forma de contatar os responsáveis
por um determinado endereço suspeito.
utilizando a ferramenta DIG
Utilize o comando dig para consultar dois servidores de nomes diferentes e resposta às per-
guntas a seguir: resolva o nome www.caixa.gov.br usando dois servidores públicos.
a. Que comandos foram utilizados?
b. Qual é a versão de software dos servidores DNS utilizados?
c. As duas consultas retornam o mesmo resultado para o nome “www.caixa.gov.br”?

Em caso negativo, o que pode ter acontecido?
Mapeando IP para AS
Outra forma de obter mais informações sobre uma instituição é consultar informações q
sobre o Sistema Autônomo – Autonomous System (AS) – associado a um determinado
endereço IP.
Como comentado, uma instituição pode ser identificada por diferentes meios. Além das
maneiras descritas anteriormente – tal como domínios de redes e endereçamento IP –,
dados de roteamento também podem ser utilizados.
100
Tipicamente, instituições de grande e médio porte possuem autonomia para gerenciar
questões relativas às políticas de roteamento. Nesse contexto, uma instituição pode ser
identificada por um número de identificação utilizado para fins de roteamento. Esse número
de identificação é denominado número AS, ou número de identificação do sistema autô-
nomo. De forma resumida, um AS especifica uma coleção de blocos de endereçamento IP
que foram designados para um provedor de internet.
Portanto, identificar um sistema autônomo de uma instituição permite determinar o q

endereçamento de redes de sua responsabilidade e, consequentemente, os contatos
para que as notificações sejam enviadas.
Para isso, um CSIRT pode consultar informações de roteamento disponível na internet e

identificar um determinado AS. Diante disso, alguns grupos disponibilizam bases de infor-
mações desenvolvidas especificamente para consultar informações de roteamento. Uma
delas é mantida pelo grupo de pesquisa Shadownserver: https://www.shadowserver.org/
O serviço provido pelo Shadownserver, que pode ser consultado via interface WHOIS,
fornece um conjunto de informações, entre elas:
11 Descrição do ASN;
11 País de alocação do ASN;
11 Prefixo BGP;
11 Data de alocação do ASN.
Na sequência, são demonstrados alguns exemplos que ilustram a utilização do serviço

de WHOIS provido pelo Shadownserver com informações relativas a roteamento.
Por exemplo:
Localizando informações de roteamento da Rede Nacional de Pesquisa/RNP. Como base para

consulta, será utilizado o site http://www.rnp.br/. Logo, faz-se necessário as seguintes etapas:
a. converter domínio para endereço IP
$ host www.rnp.br
www.rnp.br has address 200.130.35.4
b. consultar a base de dados shadowserver.org
$ whois -h asn.shadowserver.org ‘origin 200.130.35.4’
1916 | 200.130.0.0/16 | Associação | BR | RNP.BR | ASSOCIACAO REDE

NACIONAL DE ENSINO E PESQUISA
Como resultado, é possível observar que o IP 200.130.35.4 pertence ao AS 1916 e faz parte
do bloco de endereçamento 200.130.0.0/16 alocado no Brasil (BR).
De forma similar, pode ser realizada uma consulta por todos os endereços pertencentes
a um determinado AS. No exemplo a seguir é realizado uma consulta por todos os blocos
alocados ao provedor da RNP:
101
user@server —> whois -h asn.shadowserver.org 'prefix 1916'
150.161.0.0/16
150.164.0.0/16
200.17.0.0/20
200.17.25.0/24
200.17.48.0/20
200.17.64.0/20
200.17.112.0/20
200.17.128.0/20
200.17.176.0/20
200.18.128.0/20
200.18.144.0/20
200.18.160.0/20
200.18.176.0/20
200.18.192.0/19
200.19.40.0/23
200.19.112.0/20
Figura 6.5
200.19.128.0/20
Blocos de
200.19.144.0/20 endereçamento
<...> associados ao AS
1916 (RNP).
Como pudemos observar, o AS possui inúmeros blocos de endereçamento associados.

Diante disso, é possível estimar o tamanho de um provedor e suas características de rotea-
mento. De forma indireta, essas informações servem para complementar as informações
dos responsáveis por um determinado incidente (nome do provedor etc.).
Sistemas Autônomos
Com base nas informações disponibilizadas pelo site [1], responda as seguintes questões.
[1] http://bgp.he.net/
a. Identifique qual é o seu ASes neste momento.

b. Quantos ASes são estão sendo anunciados no Brasil?
102
c. Identifique quantos prefixos IPv4/IPv6 estão sendo anunciados pelo Brasil.
Demais recursos
Mesmo assim, ainda existem casos em que não é possível determinar os contatos apro-
priados por um determinado recurso.
Diante disso, o CSIRT deve recorrer a meios alternativos que podem ser empregados q
para auxiliar, de forma indireta, nesta tarefa de identificar os devidos responsáveis.
Por exemplo:
11 Utilizar informações contidas nos website (contatos);
11 Listas de discussões técnicas (maillist);
11 Redes sociais.
Um recurso que pode ser útil para comunicar-se com uma instituição envolvida com um
incidente é usar as informações contidas no próprio website da instituição.
Por exemplo, pode-se acessar o website – domínio ou endereço IP:80 – e buscar por formas
alternativas de contato. Algumas instituições disponibilizam formulários em seus sites para
contato com os clientes. Esses formulários podem ser uma alternativa para contatar os res-
ponsáveis pela segurança de uma instituição. A figura 6.6, por exemplo, ilustra uma seção de
um website com um formulário para contato.
Figura 6.6
Formulário
de contato.
103
Não bastando, um CSIRT pode utilizar recursos como fóruns técnicos e listas de
discussões (malling list) para localizar informações de contato da equipe técnica de
uma determinada instituição.
Boa parte de listas técnicas disponibilizam o arquivo de conversas de forma pública, o qual
pode ser consultado. Logo, é possível buscar informações por um determinado IP ou domínio
no arquivo dessas listas, de modo a obter mais informações dos responsáveis.
No Brasil, existe uma lista de discussão técnica denominada – Grupo de Trabalho de

Engenharia e Operação de Redes – utilizada por administradores de sistemas e provedores
de acesso. A lista é mantida pelo NIC.br e tem o seu histórico publicamente acessível no
seguinte endereço: http://eng.registro.br/pipermail/gter/
Essa lista pode ser usada para obter contatos ou, até mesmo, como ponto de partida para
localizar responsáveis por determinada redes. Além da lista GTER, existem diversas listas de
discussões técnicas que podem ser utilizadas para consulta (NANOG, LACNOG etc.).
Também é possível consultar informações de um determinado recurso em

mecanismos de buscas e até mesmo em redes sociais. Por exemplo, serviços de
microblogging, tal como Twitter, pode ser utilizado para contatar uma instituição e
solicitar os seus contatos técnicos.
De forma resumida, as técnicas e ferramentas apresentadas neste capítulo buscam dar

alternativas para identificar responsáveis por recursos de rede. Em certas situações, mesmo
utilizando diferentes fontes de informações, não é possível identificar o contato dos respon-
sáveis. Como alternativa, pode-se contatar o provedor de acesso solicitando informações do
contato desejado ou, ainda, que a própria notificação seja repassada para os responsáveis.
Adicionalmente, existem CSIRTs regionais e nacionais que podem prover contatos mais
específicos quando necessário, mesmo que essas informações não sejam da constituinte do
próprio CSIRT. Por exemplo, o CSIRT nacional pode ter informações de contatos de outros
países, mesmo tendo sua área de atuação apenas no Brasil.
Cuidados no processo de identificação de contato
11 As informações de roteamento são ativas: a ferramenta traceroute pode identificar o

caminho da comunicação até o destino; no entanto, essas informações são dinâmicas e em
uma análise pós-incidentes podem não refletir a realidade no momento do incidente;
11 As informações de resolução de nomes (DNS) são dinâmicas. Um determinado domínio

pode ser traduzido para um endereço IP; no entanto, não existe garantia de que essa infor-
mação será inalterada. Em análises pós-incidentes, da mesma forma, um domínio de rede
pode conter informações que não mais refletem a realidade no momento do incidente;
11 O contato identificado na base WHOIS deve ser sempre analisado com critério, sobre-
tudo quando se utiliza ferramentas automatizadas para extrair informações. Algumas
informações podem ser imprecisas, ou ainda, podem fazer com que as notificações sejam
enviadas para os próprios atacantes.
104
11 Mailbox Names for Common Services, Roles and Functions:

11 Regional Internet Registries: https://www.arin.net/knowledge/rirs/countries.html
11 Internet Corporation for Assigned Names and Numbers – ICANN: https://www.icann.org/
11 RFC 2821 – Simple Mail Transfer Protocol: www.ietf.org/rfc/rfc2821.txt
11 RFC 2476 – Message Submission: http://www.ietf.org/rfc/rfc2476.txt
105
106
7
objetivos
Análise de Logs
Conhecer a estrutura básica de sistemas de logs; Levantar questões relacionadas
com o processo de reportar incidentes; Analisar mensagens de logs.
conceitos
Infraestrutura de coleta e armazenamento de mensagens de logs; Processamento
e interpretação de mensagens de logs; Correlacionar informações de múltiplos sistemas.
Introdução
Os logs são importantes fontes de informações para o gerenciamento de recursos de q
sistemas computacionais. Os logs descrevem eventos registrados por dispositivos ou
aplicações, podendo conter diferentes níveis de detalhamento de informações. As infor-
mações contidas nos logs podem ser usadas em diversas etapas do gerenciamento de
sistemas, tais como:
11 Auditoria;
11 Depuração;
11 Estatísticas;
11 Provisão de recursos;
11 Identificação de falhas de hardware;
11 Investigação de incidentes de segurança;
11 Detecção de anomalias e possíveis ataques.
Geralmente os logs podem ser utilizados para responder questões relacionadas a eventos
que já aconteceram, tal como: identificar tentativas de acesso sem sucesso, instante em
que o sistema sofreu instabilidade, e informar que sistema de arquivo está sobrecarregado.
No entanto, os logs podem ser usados não apenas para revelar informações passadas,
mas sim para identificar possíveis falhas em um futuro próximo. Por exemplo, informações
que relatam constantes falhas na escrita de dados de um determinado disco rígido pode
representar uma provável falha no disco. Em questões relacionadas com segurança, os logs
podem identificar que aplicações estão sendo exploradas, permitindo à equipe avaliar se as
suas proteções de segurança são adequadas.
Logs também podem ser analisados para produzir relatórios que demonstram o comporta-
mento de usuários, os quais podem ser utilizados para marketing, desenvolvimento de pro-
dutos e detectar comportamento anormal que podem indicar possíveis ataques. De forma
complementar, os logs podem satisfazer requerimentos de autoria de um sistema e indicar
os responsáveis por ações realizadas.
107
No entanto, identificar informações relevantes em um arquivo de log pode levar tempo e
muito trabalho, principalmente em sistemas complexos com um grande volume de informa-
ções que devem ser analisadas. Logo, faz-se necessário entender as características básicas
contidas nas mensagens de logs para que informações relevantes sejam facilmente identi-
ficadas. Estar familiarizado com os diferentes formatos de logs é fundamental para que o
CSIRT possa atuar efetivamente no processo de resposta a incidentes. Da mesma forma, o
entendimento do funcionamento geral do sistema de logs permite identificar erros e, adi-
cionalmente, auxiliar na identificação de informações relevantes em arquivos de logs com
formatos ainda não conhecidos.
Este capítulo está organizado em duas etapas. A primeira etapa descreve as características
básicas do sistema de registro de eventos (logs) descrevendo: a) os diferentes tipos de
informações que podem ser encontradas nos arquivos de logs; b) formatos de arquivos, e
c) infraestruturas de coleta e transmissão de informações de eventos. Já na segunda etapa,
são abordadas diferentes maneiras de analisar os arquivos de logs, descrevendo ferra-
mentas e técnicas utilizadas.
Mensagens de logs
Uma mensagem de log é um conjunto de informações geradas por algum dispositivo ou q
sistema que denota a ocorrência de um evento.
O conjunto de informações contidas em um arquivo de log é dependente do tipo de sistema

que está gerando os eventos. Por exemplo, mensagens de logs de um servidor web contêm
informações específicas sobre o próprio serviço: arquivos acessados, páginas não encon-
tradas, requisições HTML, status do serviço web, entre outros. Por outro lado, logs de um
roteador contêm dados de protocolos e informações do próprio Sistema Operacional do
roteador (carga, status das interfaces e taxa de utilização das interfaces).
Existe uma grande quantidade de dispositivos e sistemas que podem ser configurados q
para registrar informações de eventos, tais como:
11 Impressoras;
11 Sistemas de antivírus;
11 Servidores Unix/Windows;
11 VPN (redes virtuais privadas);
11 Roteadores, firewalls e switches;
11 NAT (serviço de tradução de nomes);
11 Aplicações (serviços de rede, serviços web e softwares em geral);
11 Equipamento de controle de acesso físico (leitores biométricos e catracas).

De fato, a heterogeneidade dos dispositivos e sistemas faz com que a natureza das mensa-
gens de logs seja bastante diversificada. Algumas mensagens com maior nível de detalha-
mento de informação e outras com menos.
Mesmo com a grande variabilidade de informações que podem ser originadas pelos disposi-
tivos, podem-se agrupar as informações em certas categorias tendo em vista a natureza da
própria mensagem:
11 Gerência de mudança: informações de troca de configuração, atualização de compo-

nentes e mudanças de contas de usuários. Essa categoria engloba todos os recursos que
podem ser atualizados, adicionais, ou removidos;
108
11 Autenticação e autorização: mensagens relativas à autenticação de usuários nos
diversos sistemas e autorização de acesso a recursos privilegiados. Por exemplo, acessos
do usuário root; e tentativas de obter acesso via comando sudo;
11 Acesso a dados e sistema: registro de eventos associados ao acesso de componentes

de aplicações, incluindo informações de arquivos e banco de dados. Os eventos dessa
categoria geralmente descrevem informações operacionais e de desempenho, incluindo
questões relativas à segurança dos sistemas;
11 Ameaças: eventos gerados por dispositivos de rede que produzem mensagens de alerta
e demais atividades que violam as políticas de segurança da instituição. Nessa categoria
incluem mensagens originadas por firewalls e sistemas de detecção de intrusão;
11 Desempenho e capacidade: envolve mensagens relativas ao desempenho dos sistemas

e gerenciamento de capacidades, tais como: utilização de memória, utilização do espaço
em disco e carga do sistema;
11 Disponibilidade: informações sobre a disponibilidade do recurso computacional. Muitos

dispositivos registram eventos quando um sistema é iniciado, reiniciado ou desligado.
Essas informações são fundamentais para identificar quanto tempo um sistema ficou
indisponível – ou ainda examinar quando uma interface de um roteador está inoperante;
11 Diversas: mensagens genéricas de notificação que servem para chamar atenção de um

determinado evento configurado pelo próprio desenvolvedor da aplicação.
Independentemente da natureza e do nível de detalhamento das mensagens de logs, é pos-

sível identificar um conjunto básico de informações tipicamente presentes em boa parte das
mensagens. Identificar esse conjunto básico de informações presentes nas mensagens de logs
é determinante para que um CSIRT interprete corretamente o evento registrado.
Os elementos essenciais de uma mensagem de log são: q

11 Timestamp: instante no qual o evento foi registrado pelo sistema de logs;
11 Origem: o sistema que originou a mensagem. Geralmente um endereço IP ou nome

de uma máquina;
11 Dados: informações sobre o evento gerado, sendo dependente do objeto monitorado.

Não existe um formato padronizado de informações disponibilizadas por um evento,
podendo conter: dados de usuários, dados de aplicações e recursos de sistemas.
A maneira exata com que as mensagens de logs são compostas depende do sistema origi-
nador de mensagens – tipicamente uma aplicação – e do nível de detalhamento especificado
pela configuração da aplicação.
Talvez o formato mais comum utilizado por sistemas de computadores e dispositivos q

seja o formato baseado no Syslog (posteriormente descrito). A seguir uma mensagem de
log usando o formato Syslog:
Jan 28 11:42:59 sshd[1184]: server Accepted password for teste

from 10.10.10.10 port 6541 ssh2
Essa mensagem de log descreve um evento relacionado com o serviço SSH. Como pode ser visu-
alizado, a mensagem pode ser dividida em quatro campos com informações relativas ao evento:
109
Jan 28 11:42:59 timestamp
sshd[1184] Nome do serviço e número do processo em execução no Sistema Operacional
server Nome do servidor onde o serviço está sendo executado
Mensagem do serviço SSH informando um acesso bem sucedido pelo usuário “teste” a
Accepted pass...
partir do IP 10.10.10.10 utilizando a porta origem 6541.
Assim como mensagens de logs baseados na especificação Syslog, alguns sistemas imple- Tabela 7.1
mentam o seu próprio sistema de gerenciamento de logs. Por exemplo, o Windows XP e o Alguns incidentes
e possíveis
Windows 7 possuem um sistema de log denominado de Event Log. A figura 7.1 ilustra o procedimentos.
visualizador de eventos do sistema Windows, onde é possível obter informações de todos os
eventos relacionados a aplicações, segurança e aos aplicativos.
Figura 7.1
Event Viewer:
gerenciamento
de eventos em
sistemas Windows.
Portanto, é importante observar que as mensagens de logs são dependentes funda- q

mentalmente de dois fatores: aplicação (define o conteúdo na mensagem) e também do
sistema utilizado para registrar as informações (define o formato e estrutura).
Além de gerenciar os eventos gerados por um sistema de logs, alguns sistemas de gerencia-
mento de logs permitem priorizar certos tipos de eventos de logs. Dessa forma, informações
críticas podem ser gerenciadas de diferentes maneiras das demais informações. Isso é essen-
cialmente útil, sobretudo em sistemas onde existe um grande volume de informações.

Utilizando a priorização de eventos, torna-se viável unificar todos os eventos críticos do
sistema e das demais aplicações sendo executadas. A priorização de logs é dependente do
sistema de logs utilizado; no entanto, boa parte deles possui uma taxonomia semelhante.
A seguir um exemplo – baseado em uma implementação do Syslog – descrevendo q

algumas categorias utilizadas:
11 Debug: mensagens de depuração são geradas por sistemas e aplicações de maneira

a auxiliar desenvolvedores de softwares a identificar problemas de execução do pro-
grama. Sistemas configurados para registrar eventos em modo debug produzem uma
grande quantidade de informação e com um grande nível de detalhes;
110
11 Informational: são mensagens que são designadas para informar ao administrador q
e usuários uma ação específica. Por exemplo, alguns sistemas geram mensagens do
tipo informational quando um Sistema Operacional é reiniciado. Embora o reinício de
um sistema seja uma ação normal, em certos contextos pode constituir uma exceção
de funcionamento ou uma violação de segurança;
11 Warning: mensagens que identificam algumas exceções na execução, mas que não
impactam no funcionamento normal do sistema. Por exemplo, mensagens de log
informando que o sistema de arquivos está com pouco espaço disponível;
11 Error: mensagens de erro que representam falhas na execução e afetam o funcio-

namento normal do sistema. Por exemplo, uma mensagem informando um erro de
sintaxe na execução de um comando;
11 Alert: mensagem que contém informações não usuais e potencialmente perigosas

para a execução do sistema. Mensagens de alerta geralmente correspondem a
eventos de segurança. Por exemplo, um evento gerado por um sistema de detecção
de intrusão, quando este identifica um comportamento possivelmente malicioso.
A figura 7.2 ilustra as categorias descritas anteriormente no formato de uma pirâmide.

No topo da pirâmide estão as mensagens com maior severidade para o sistema, e na base
as mensagens com menor priorização. Embora não seja uma regra, a base da pirâmide
também representa o volume de mensagens tipicamente produzidas pelos sistemas: por
exemplo, mensagens informacionais são mais encontradas do que mensagens do tipo erro.
alert mensagens de alerta
error mensagens de erro
Severidade
warning mensagens de aviso
Figura 7.2 informational mensagens informacionais

Categorias típicas
implementadas por
debug mensagens de depuração
sistemas de logs.
Sistemas de logs
Os sistemas de logs – sistemas de registros de eventos e notificações – são compostos q
por diferentes componentes básicos responsáveis por gerar, transmitir e armazenar
informações de eventos.
Sendo assim, existe um conjunto de elementos que estabelecem uma infraestrutura de

modo a prover o efetivo funcionamento de um sistema de logs.
O funcionamento básico de um sistema de log consiste em obter as mensagens geradas por

um evento e armazená-las em um sistema de arquivo para posterior análise. De forma geral,
os arquivos de logs são armazenados localmente no servidor onde as aplicações estão sendo
executadas. No entanto, armazenar os logs localmente podem trazer possíveis pontos de inse-
gurança. Sabe-se que os sistemas falham, e em alguns incidentes nem sempre é possível ter
acesso ao sistema comprometido para analisar os logs. Além do mais, uma vez que o sistema
esteja comprometido, o atacante pode utilizar ferramentas para apagar logs e evidências de
acesso ao sistema. Sendo assim, ter uma cópia dos logs em outro local permite ter acesso
111
às informações mesmo diante da inacessibilidade da fonte dos logs. A situação é ainda mais
crítica em ambientes virtualizados baseados em computação em nuvens. Nesses cenários,
quando a infraestrutura é afetada, o acesso às informações críticas pode ser inviável.
Uma técnica bastante comum é armazenar os logs remotamente na rede, usando servi- q
dores centralizados na mesma estrutura da rede.
Dessa forma, um servidor pode armazenar informações de diferentes serviços de maneira

centralizada. Esses servidores que centralizam informações de logs podem ser sistemas
dedicados para tal função com alto nível de segurança. Por exemplo, servidores onde
apenas é possível que informações sejam adicionadas ao sistema de arquivo – política
apenas escrita incremental (append only). Em alguns casos, o servidor de logs central não
possui comunicação com a internet, apenas com a rede interna incluindo as máquinas que
exportam logs e servidores de backup.
A transmissão e coleção de dados de logs é um processo relativamente simples. Computa-

dores e dispositivos que implementam subsistemas de logs podem registrar informações e
transmiti-las segundo a configuração especificada.
Essa transmissão dos eventos de logs para um servidor pode ser realizada de diferentes q
maneiras, podendo ser:
11 Exportação em tempo de execução;
11 Definir um conjunto de informações a serem exportadas periodicamente.
Na figura 7.3, é ilustrada uma infraestrutura de coleta e armazenamento de logs. O principal

elemento da estrutura centralizada é uma entidade denominada de loghost – servidor de
logs – que nada mais é do que um servidor Unix ou Windows Server onde as informações
são armazenadas de forma integrada. Dessa forma, os diferentes dispositivos (roteadores,
firewalls, switches e servidores) podem exportar as informações para o servidor centralizado.
Ainda na figura 7.3, é possível identificar um servidor de armazenamento que gerencia e
arquiva as informações do loghost para períodos de longo prazo.
servidor de fita de Figura 7.3

servidor de
armazenamento backup Estrutura
logs
centralizada para
offline armazenamento
de logs.
Além de aspectos de segurança, usar um servidor de logs centralizado pode ter as q

seguintes vantagens:
11 Ter um local centralizado para armazenar as informações de múltiplas fontes de dados;
11 Ter um local para realizar backup de todos os dados de log;
11 Ter um local para analisar e correlacionar informações de diferentes fontes.
112
A exportação das informações de eventos para o servidor central é realizada utilizando um
protocolo de comunicação específico. Uma das maneiras mais utilizadas para transferir as
informações de eventos (logs) é por meio do protocolo Syslog.
O protocolo Syslog é um padrão aberto – definido pela RFC 3164 – para transmitir mensa-
gens de eventos e notificações. Para isso, a especificação do Syslog define uma arquitetura
modular para transmissão de notificações e também estipula um formato para as men-
l sagens de logs. De forma simplificada, a arquitetura do Syslog define dois componentes

Syslog: básicos: um cliente (originador de mensagens) e um servidor (coletor de mensagens).
aplicação: para coletar O cliente Syslog é responsável por gerar as informações de eventos e pode ser configurado
e armazenar eventos;
protocolo: transporte para enviar as informações para um servidor local ou um servidor de logs remoto. Já o
de eventos. servidor Syslog, é responsável por receber, ou retransmitir, as informações dos clientes e
armazená-las em um repositório de dados, tipicamente um sistema de arquivo.
Como descrito, todas as informações transmitidas entre o cliente e um servidor de um

sistema de log são realizadas via protocolo de transporte homólogo. O protocolo Syslog, por
sua vez, utiliza-se do protocolo UDP. Logo, todas as mensagens de eventos e notificações
transmitidas para servidores remotos utilizam a porta 514/UDP. Em versões mais modernas
do protocolo, tais como o rsyslog e syslog-ng, também é possível transmitir informações de
eventos com confirmação de entrega, usando o protocolo TCP.
O Syslog não é o único mecanismo de transmissão e coleta de logs. Existem outras imple-
mentações com especificações abertas, e também implementações utilizando protocolos
proprietários.
A seguir os mecanismos mais utilizados em infraestrutura de coleta de logs: q

11 Syslog: protocolo aberto baseado UDP. Mais comum e prevalente mecanismo para log;
11 Simple Network Management Protocol (SNMP): originalmente utilizado para gerencia-

mento de rede, no entanto pode ser utilizado para registrar determinados eventos (via traps);
11 Windows Event Log: formato proprietário de logs da empresa Microsoft. Pode ser
utilizado na maioria dos dispositivos usando a plataforma Windows;
11 Banco de Dados: algumas aplicações utilizam base de dados remota para armazenar
informações de logs de uma maneira estruturada;
11 Protocolos proprietários: alguns sistemas e aplicações implementam protocolos custo-

mizados, até mesmo criptografados, para transferir e coletar informações dos eventos.
Uma infraestrutura de logs pode ser composta por diferentes protocolos. Não é raro observar
ambientes heterogêneos onde diferentes soluções (protocolos e mecanismos) são utilizadas
para compor uma estrutura central de coleta de logs. Consequentemente, em ambientes
heterogêneos, observam-se diferentes tipos de formatos e taxonomia de mensagens.
Na sequência, os aspectos relacionados com os diferentes formatos de logs são abordados.
Diversidade no formato dos logs

Como comentado, os ambientes heterogêneos são compostos por dispositivos e aplicações
que nem sempre seguem um único formato ou especificação para registro de eventos.
Cada sistema de registro de eventos possui suas próprias características, com as suas res-
pectivas vantagens e desvantagens (vide tabela 7.2).
113
É possível classificar os formatos de logs nas seguintes categorias: q
11 Syslog: formato de mensagem baseado na especificação Syslog, contemplando
syslog-ng, rsyslog e demais implementações que são embasadas no Syslog.
O formato Syslog é texto sem uma especificação rígida das mensagens. Embora as
mensagens apresentem certa estrutura, o conteúdo da mensagem pode ser com-
posto com qualquer informação de eventos. Ou seja, não existe um dicionário de
termos que podem ser utilizados para expressar o universo de eventos reportados;
11 Texto puro: são arquivos-texto que descrevem eventos sem nenhuma estrutura
especificada. O registro de eventos não segue um padrão comum. Vale-se da forma
livre. Esse tipo de formato é comum para registrar eventos de aplicações onde as
mensagens são acrescentadas sequencialmente em um arquivo de logs;
11 Formato binário: esses tipos de formatos geralmente são especificados por fabri-
cantes para representar mensagens de eventos de seus dispositivos, tais como firewalls
e aplicações de segurança. Tipicamente as informações são bem estruturadas e
podem ser facilmente analisadas por uma ferramenta ou aplicação de análise. Existem
formatos binários que não são proprietários, tal como o formato pcap – utilizado pelo
analisador de rede tcpdump. Nesses casos, o formato binário é utilizado por questões
de desempenho: registrar uma grande quantidade de eventos sem a necessidade de
convertê-las para um formato de texto é menos custoso computacionalmente.
Vantagens Desvantagens
Disponível em boa parte dos sistemas Formato não estruturado ou semiestruturado.

Syslog facilitando a integração com ferramentas A análise de informações de forma automati-
e dispositivos existentes. zada nem sempre é trivial e pode ser custosa.
Tipicamente utilizado para depuração de Ausência de estruturação. Muitas vezes as

Texto Puro aplicações, onde o desenvolvedor tem informações são úteis apenas para o desen-
liberdade para estruturar as informações. volvedor.
Análise das informações armazenadas Não pode ser lido por editores tradicionais de
Formato binário pode ser automatizada por apresentarem texto, sendo necessárias ferramentas especí-
um formato bem estruturado. ficas para a leitura.
Na sequência, são apresentados diferentes tipos de logs para que um investigador possa Tabela 7.2
familiarizar-se com o formato e com que tipo de informação pode ser encontrado nos Características dos
diferentes formatos
sistemas a serem analisados. de logs.
Autenticação de um usuário utilizando o serviço SSH em um ambiente Linux q

Oct 6 00:20:54 server sshd[22652]: Accepted password for root
from 200.x.1.6 port 39856 ssh2
Reinício de Sistema Operacional Linux

Dec 18 11:18:20 sysgate shutdown[31208]: shutting down for system

reboot
Ajuste de sincronização de tempo realizado pelo serviço NTP
Oct 5 15:32:26 server ntpd[18983]: adjusting clock frequency by

-0.298083 to -0.429360ppm
Criando um usuário no sistema Windows
Oct 29 08:43:36 10.10.10.10 Security: 624: <DOMAIN>\<ADM USER>:

User Account Created: New Account Name: <USER CREATED> New
Domain: <DOMAIN>
114
Troca de privilégio q
Mar 30 15:14:33 HOST su: [ID 366847 auth.notice] ‘su root’ succe-
eded for USER on /dev/pts/2
Log de firewall Checkpoint
Oct 9 14:20:25 nok1 [LOG_CRIT] kernel: fwlock_call_at_release:

no memory available for operation
Alteração de configuração de um roteador da marca Extreme
Apr 4 14:31:03 10.18.3.253 KERN: NV:Starting configuration save

(primary) operation
Erro de autenticação do software VNC
Oct 25 13:45:45 10.10.10.200 WinVNC4: 1: SConnection: AuthFailu-

reException: Either the username was not recognised, or the
password was incorrect
Tentativa de acesso a um servidor web
2001:X:X:X::108 - - [30/Sep/2013:18:40:06 -0300] “GET //cgi-bin/..%

c0%2f..%c0%2f..%c0%2f..%c0%2f..%c0%2f../winnt/system32/cmd.exe?/
c+dir+c: HTTP/1.1” 404 7488 “Mozilla/5.0 (X11; Linux; rv:1 7.0)
Gecko/17.0 Firefox/17.0 OpenVAS/6.0.0”
Alerta gerado pelo IDS Snort
[**] [1:1002:15] WEB-IIS cmd.exe access [**] [Classification:

Web Application Attack] [Priority: 1] 10/24-20:15:11.900014
x.x.x.x:42200 -> y.y.y.y:80 TCP TTL:56 TOS:0x0 ID:15236 IpLen:20
DgmLen:288 DF***AP*** Seq: 0x1B16EAE9 Ack: 0x905BABE1 Win:
0x43E0 TcpLen: 32
Força bruta a um serviço VoIP
2013-09-30 22:07:28 X.X.X.17/2231->xxx.xxx.2.59/5060 17(0)
2013-09-30 22:07:28 X.X.X.17/2231->xxx.xxx.2.74/5060 17(0)
Gerenciamento de logs
Uma instituição deve implementar certas políticas para gerenciar os registros de eventos q
dos diferentes sistemas monitorados.
As tarefas de gerenciamentos envolvem atividades como instalação e atualização de softwares,

configuração de sistemas coletores e também prover recursos para manter a estrutura
funcional como um todo. No contexto do gerenciamento de logs, o armazenamento de
informações demanda atenção especial. Frequentemente grande quantidade de logs deve

ser gerenciada e armazenada de maneira a ser útil para análises posteriores. Essas informa-
ções de logs podem ser úteis em uma investigação de um incidente e também podem ser
demandadas para questões judiciais.
Atualmente não existe uma regulamentação para armazenamento de logs. Algumas institui-
ções possuem suas próprias políticas, e outras instituições seguem normas internacionais
que demandam o armazenamento de informações por um longo período, por exemplo,
instituições que seguem a especificação Payment Card Industry (PCI).
115
De fato, se o grande volume de dados armazenados nos sistemas de arquivos não for mane- lNo Brasil, o CGI.br
jado de forma correta, podem facilmente consumir todos os recursos de armazenamento do (Comitê Gestor da
sistema, o que pode afetar o funcionamento de outros programas sendo executados. Boa Internet no Brasil)
propôs uma recomen-
parte dos sistemas implementam mecanismos para automatizar o volume de informações
dação onde aconselha
gerenciadas por logs. Entre as principais técnicas utilizadas está a utilização de compressão o arquivamento de logs
dos dados (gzip) e a rotação de arquivos. por um período de três
anos. Mais informações
Em sistemas que utilizam soluções baseadas no formato Syslog, a compactação dos podem ser obtidas em:
http://www.cgi.br/
arquivos é muito utilizada. Por tratar-se somente de arquivos texto, é possível obter uma
publicacoes/documen-
taxa de compressão muito alta usando os algoritmos tradicionais de compressão, tal como tacao/desenvolvi-
gzip, bzip2 e outros. Por outro lado, em arquivos binários, a compressão nem sempre atinge mento.htm
resultados satisfatórios; no entanto, os arquivos binários tendem a ter um formato mais

compacto, o que facilita o armazenamento.
Outra técnica utilizada pela maioria dos sistemas é a rotação de arquivos. A rotação de
arquivos de logs consiste em arquivar o arquivo corrente e instanciar um novo.
Esse arquivamento pode ocorrer de forma periódica – diária, semanal, mensal – ou, q
ainda, quando determinados limiares foram atingidos, tal como:
11 Tempo: o arquivo de log é rotacionado baseado em um período de tempo;
11 Tamanho: o arquivo é rotacionado quando um determinado tamanho de disco é

atingido, por exemplo, 100M, 1G;
11 Tempo e tamanho: nesse caso, o arquivo é rotacionado quando um determinado

tamanho de arquivo é atingido ou quando um determinado tempo é atingido.
Algumas ferramentas incorporam a funcionalidade de compactação do arquivo na

mesma etapa. Dessa maneira, é possível ter a seguinte estrutura de arquivos de logs:
1. messages.log: arquivo de log atual onde as informações estão sendo salvas
2. messages.2014.log.gz: log rotacionado contendo informações de eventos do último ano.
O gerenciamento das informações de logs devem considerar as particularidades de cada ins-

tituição. Portanto, é necessário estimar o volume de informações que são geradas pelos sis-
temas de logs e por quanto tempo essas informações devem ser mantidas com segurança.
Análise de logs
A contextualização anterior possibilitou uma visão geral do processo de logs.
Para isso, foram descritos elementos e também os principais formatos das mensagens de
logs. Nesta etapa serão descritas metodologias e técnicas que podem ser utilizadas no pro-
cesso de análise de logs.
A análise de logs aqui explicitada pode ser aplicada nos mais diversos contextos, incluindo o
processo de resposta a incidentes. Na investigação de um incidente de segurança, em espe-
cial, os logs podem prover informações sobre a potencial origem de um ataque e também
identificar as ações desempenhadas por um atacante para comprometer um sistema.
Tanto nas atividades de detecção de incidentes quanto para a resposta a incidentes, muitas
vezes um CSIRT passa por atividades relacionadas com a investigação de logs.
Tipicamente notificações de incidentes possuem logs armazenados que descrevem detalhes

do incidente sendo notificado. Sendo assim, identificar informações críticas armazenadas
nos logs é crucial para dar procedimento ao processo de resposta a incidentes.
116
Afinal, as diferentes informações encontradas nos sistemas de logs podem ser utilizadas
para compor indícios de comprometimento de sistemas.
De forma resumida, a análise de logs relacionada com o processo de resposta a inci- q

dentes possibilita:
11 Identificar padrão de tráfico não usual;
11 Comandos executados e processos instanciados;
11 Identificar origem dos acessos aos sistemas;
11 Modificações em sistemas e arquivos;
11 Possíveis erros e exceções ocasionadas pela execução de programas.
Identificar atividades maliciosas e comportamentos anormais nos arquivos de logs pode

ser uma tarefa complexa. Nem sempre o processamento das informações presentes nos
arquivos pode ser processado manualmente ou, ainda, automatizado na sua totalidade.
Diante disso, torna-se necessário enumerar as principais dificuldades encontradas no
processamento de logs.
Entre os principais desafios, encontram-se: q

11 Grande volume de dados: o volume de dados registrados por diferentes sistemas e
aplicações de uma instituição pode facilmente a chegar a gigabytes diários. Com esse
volume, a análise manual torna-se inviável e faz-se necessário utilizar ferramentas
para lidar com as informações;
11 Ausência de informações: informações críticas dos logs, tal como data e hora com
fuso horário, dificultam a análise dos logs;
11 Falsos alarmes: mensagens que não refletem a realizada, como por exemplo, mensa-
gens de falso positivo originadas por sistemas IDSs;
11 Dados duplicados: um evento de log pode ter sido registrado por diferentes fontes
de informação. Isso é essencialmente crítico quando as fontes de informações (dispo-
sitivos) não apresentam sincronia de dados;
11 Diversidade de informações: devido à falta de padronização dos dados, muitas

vezes diversas fontes de informações devem ser analisadas para chegar à real con-
clusão da análise;
11 Dificuldade de obter dados: em alguns casos cada dispositivo utiliza um formato

próprio para armazenar as informações. Quando se deseja analisar informações em
um coletor centralizado, nem sempre é possível exportar os dados em um formato
unificado para que a análise seja realizada de forma normalizada.
Figura 7.4
Encaminhamento
de relatórios
117
Diante disso, cabe à equipe desenvolver metodologias que consigam endereçar as princi-
pais dificuldades do processo de análise de logs, previamente descritas. As ferramentas e
técnicas utilizadas para análise de logs geralmente consideraram ambientes heterogêneos
– com diferentes formatos de mensagens de logs – e, também, as diferentes aplicações
responsáveis por gerar eventos de log.
De fato, a análise de logs consome tempo, sobretudo com o crescente do número de

sistemas que necessitam ser monitorados. Nota-se grande quantidade de eventos relacio-
nados com a segurança de sistemas, incluindo varreduras causadas por worms e ataques
automatizados destinados a certos serviços. Sendo assim, muitos times optam por analisar
um subconjunto das informações armazenadas de cada vez, priorizando os logs dos sis-
temas mais críticos para a instituição.
Certas instituições, por exemplo, buscam priorizar eventos de segurança relacionados com
aplicações web específicas. Outras, porém, dão preferência a alertas de ferramentas de
segurança, tal como firewalls e IDS.
De uma forma geral, o processo de análise de logs pode classificar os logs em diferentes q
categorias, sendo:
11 Arquivos de rede: tráfego de rede incluindo pacotes, conexões, protocolos, ende-

reços IPs e varreduras de rede;
11 Arquivos de sistema: dados do sistema incluindo uso de CPU, uso de memória,

reinício do dispositivo, sistema de arquivo (espaço livre, arquivos abertos, data de
acesso aos arquivos);
11 Dados de processos: que processos estão sendo executados.
A análise das diferentes categorias pode ser implementada por ferramentas específicas
que permitem automatizar parte das etapas do processo de análise de logs. Para isso, uma
metodologia genérica de análise de logs deve ser constituída.
Uma metodologia tipicamente especifica etapas bem definidas: q

11 Filtragem;
11 Normalização;
11 Correlação.
A figura 7.4 ilustra uma metodologia de análise de logs composta por três etapas básicas.
Com isso, é possível observar o fluxo de informação de um processo genérico de análise de
mensagens de logs.
análise
filtro correlação
normalização
arquivo de log alerta
Figura 7.5
Fluxo típico de
informações
para análise de
dados armazenamento mensagens de logs.
não filtrados
118
Como pode ser observado na figura, um fluxo típico de informações no processo de q
análise de logs passa pela etapa de filtragem, normalização e correlação.
Assim que um arquivo de log é analisado, busca-se filtrar por certos tipos de eventos.
Quando esses eventos são mapeados, estes são direcionados para a etapa de normalização.
Já os dados não identificados pelo filtro podem ser descartados da análise ou ainda armaze-
nados em uma base para posterior processamento.
Na fase de normalização, as diferentes mensagens de logs são unificadas e organizadas q

de modo a minimizar redundância dos dados. Na sequência, o conteúdo das mensagens
passa para a etapa de correlação de eventos. Na correlação, os eventos de diferentes
fontes podem ser compostos para uma análise mais precisa propiciando, por exemplo:
gerar alertas de segurança; utilização de técnicas específicas de investigação; e ainda o
armazenamento dos dados para posterior análise.
Na sequência, as etapas são descritas com maior nível de detalhamento.
Filtragem
Como comentado anteriormente, a etapa de filtragem tem por objetivo identificar mensa-
gens de logs segundo um critério pré-definido. Dessa forma, pode-se restringir a análise
de logs às mensagens que tenham um determinado padrão ou, ainda, mensagens perten-
centes a um período de tempo específico. Tipicamente utilizam-se ferramentas para filtrar
informações de logs.
Existe um conjunto de ferramentas bem simples, porém eficientes para o processamento

de informações presentes em arquivos de logs. Boa parte dessas ferramentas foi concebida
para ambiente UNIX, no entanto, podem ser encontradas de forma gratuita para outros
sistemas (Windows ou MAC). Acredita-se que a audiência deste curso já esteja familiari-
zada com essas ferramentas; mesmo assim, cabe relembrar a sua aplicação no contexto de
análise de logs.
De uma forma geral, os comandos de filtragem recebem um texto de entrada, aplicam um

processamento e, por fim, apresentam o resultado da filtragem na saída padrão do sistema.
Na sequência são apresentados funcionalidades dos comandos mais populares:
cut: separa linhas em campos
O comando cut exibe porções selecionadas das linhas de entrada. Sendo comumente
utilizado para extrair campos delimitados. O delimitador de campos padrão é o <TAB>; no
entanto, o delimitador pode ser alterado utilizando a opção “-d”. A opção “–f” especifica que
campos devem ser incluídos na saída.
sort: ordena as linhas
O comando sort ordena as linhas ou colunas de um arquivo texto. Além de ordenar o con-
teúdo de forma crescente ou decrescente, é possível realizar uma ordenação baseando-se
em conteúdo alfanumérico e conteúdo numérico presente no arquivo.
uniq: exibe linhas únicas
O comando uniq identifica linhas redundantes de um arquivo. Com isso, é possível remover
linhas repetidas de um arquivo ou, ainda, contar a ocorrência de cada linha processada.
O uniq assume que o texto de entrada seja previamente ordenado, logo geralmente é utili-
zado em conjunto com o comando sort.
119
wc: conta linhas, palavras e caracteres
O comando wc permite contar elementos de um arquivo texto, incluindo: caracteres, pala-

vras, linhas e bytes.
tee: copia a entrada em duas saídas
O comando tee permite replicar um texto de entrada para duas saídas simultaneamente.
Por exemplo, é possível ao mesmo tempo salvar o resultado de um comando em um arquivo
texto e exibi-lo na saída padrão de forma paginada.
head e tail: lê do começo de arquivo e da saída
Os comandos head e tail exibem o conteúdo de um arquivo de forma parcial. Respectiva-

mente, o head e tail exibem um determinado número de linhas do arquivo a partir do início
e do fim do arquivo. Isso é muito útil em arquivos grandes; dessa forma, é possível extrair as
últimas mensagens de logs sem ter de processar o arquivo inteiro.
grep: localizar padrões ou expressões regulares em arquivos texto
O comando grep corresponde a uma ferramenta bastante robusta para localizar padrões e
expressões regulares em arquivos de texto.
awk: ferramenta versátil para processar textos
O comando awk é uma ferramenta bastante versátil para o processamento de texto, onde
uma linguagem própria de programação é especificada de modo a facilitar a análise de
dados. Como funcionalidades, o awk permite extrair, isolar e substituir partes de um texto.
sed: ferramenta muito flexível para realizar buscas e substituições
O comando sed também pode ser considerado uma linguagem de programação. Assim
como o comando awk, o comando sed permite extrair, isolar e substituir partes de um texto.
Algumas operações são mais triviais de serem implementadas no comando sed do que no
awk; no entanto, são comandos que possuem recursos semelhantes.
As ferramentas recém-descritas são fundamentais para a filtragem de mensagens de logs.

Sabe-se que essas ferramentas podem ser combinadas de modo a produzir melhores resul-
tados. Por exemplo, o comando a seguir:
user@server:—$ cat /etc/passwd | grep bash | cut -d ":" -f 1,7

root:/bin/bash
esr:/bin/bash
rnp:/bin/bash Figura 7.6
Comandos de
visitante:/bin/bash filtragem de texto.
Na figura são ilustrados alguns comandos para filtragem de texto de forma combinada. Como
pode ser visto, o arquivo /etc/passwd é processado em busca da palavra “bash”. Por fim, o
comando cut secciona o texto usando o “:” como delimitador e exibe o primeiro e o sétimo
campo identificado. Uma possível interpretação para esse comando seria: “liste todos os usuá-
rios que possuem o interpretador de comandos bash como padrão no Sistema Operacional”.
120
Normalização
A normalização busca organizar as diferentes mensagens e formatos de logs de modo a q
minimizar redundância dos dados.
No processo de investigação de um incidente, muitas vezes é necessário unificar as men-

sagens dos diferentes sistemas de modo a filtrar certos tipos de padrões. No entanto, um
CSIRT deve estar preparado para lidar com diferentes formatos de logs; afinal, é difícil
encontrar uma organização com um único formato de log por diversas razões: questões
políticas, diferentes vendedores de dispositivos, aplicativos legados e outros.
Muitas vezes, os diferentes sistemas podem produzir mensagens de logs de modo estruturado
(xml, json) e também em formato puro com ausência de estrutura. Nesse contexto, aconse-
lha-se durante o processo de investigação organizar as informações em um formato unificado
de modo a facilitar a análise de informações. Nessa unificação, devem ser tratadas questões
como formato da data, formato do horário e codificação dos caracteres (utf-8, isso 8999-1).
Existem campos comuns que geralmente estão presente nos diferentes formatos de q
logs, entre eles:
11 Origem/Destino;
11 Tempo;
11 Protocolo;
11 Porta;
11 Nome de usuário;
11 Evento/Notificação/Alerta.
Esse processo nem sempre é trivial quando aplicado aos diferentes sistemas de log, tal como:
Syslog, multilog, Windows Eventlog e SNMP. Evidentemente, arquivos estruturados e em modo
texto podem ser trabalhados de forma mais flexível. Um exemplo é apresentado a seguir:
Log-server1.txt: Log do servidor web Windows q

192.168.114.201, -, 03/20/01, 7:55:20, W3SVC2, SERVER, 200.X.X.X,
4502, 163, 3223, 200, 0, GET, /DeptLogo.gif, -,
Log-server2.txt: Log do servidor web Linux
192.168.1.1 - - [31/Dec/2007:00:17:10 +0100] “GET /cgi-bin/example.

cgi HTTP/1.1” 200 2708 “-” “curl/7.15.5 (i4 86-pc-linux-gnu)
libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5” 2 example
user@server:—$ cat Log-server1.txt | awk -F ','{print "DATA="$3$4 ", IP="$1 ", "$13 $14}' &&
cat Log-server2.txt | awk -F ' ' '{print "DATA="$4 ", IP="$1 ", "$6 $7}' | tr -d '" ['
DATA= 03/20/01 7:55:20 , IP=192.168.114.201, GET /DeptLogo.gif

DATA= 31/Dec/2007:00:17:10, IP=192.168.1.1, GET/cgi-bin/example.cgi
Figura 7.7 Na figura é possível observar um exemplo onde logs de diferentes sistemas são normali-
normalização das zados. O primeiro log (Log-server1.txt) contém uma requisição web de um servidor
mensagens de logs
de servidores web. Windows. Já o arquivo seguinte contém uma requisição para um servidor web Linux. Como
resultado, alguns campos são filtrados de modo a produzir um formato mais uniforme.
121
Correlação
A fase de correlação de mensagens de logs busca identificar ações relacionadas com um q
determinado evento investigado.
Por exemplo, uma máquina realizando varreduras na rede interna e acessando constan-
temente um canal de comunicação IRC pode caracterizar eventos correlacionados a um
comprometimento por bot.
Na etapa de correlação, todas as informações dos logs normalizadas previamente são anali-
sadas de modo a obter indícios de um incidente de segurança. Para efetuar essa correlação
de eventos, podem-se usar informações como origem de um ataque, alvo de um ataque,
horário inicial, horário final e características de tráfego.
De forma pragmática, existem algumas técnicas que podem ser utilizadas para auxiliar no
processamento e correlação de eventos.
Na sequência, as principais técnicas são descritas:
Busca de padrões
Essa técnica consiste em identificar padrões específicos de mensagens de logs. Para isso, q
o investigador deve ter conhecimento prévio do tipo de evento que está pesquisando, tal
como: IP atacado ou IP do atacante. Dessa forma, é possível reduzir consideravelmente o
volume de mensagens que necessita ser investigadas.
Essa técnica é muito utilizada no processo de resposta a incidentes, onde a equipe de

investigação busca confirmar a existência de um incidente e também identificar os eventos
correlacionados com uma notificação recebida. No entanto, quando aplicada na identifi-
cação proativa de incidentes, a busca de padrões apresenta algumas lacunas. Os padrões
necessitam ser previamente identificados. Ataques que utilizam padrões não conhecidos
são ignorados pela análise.
user@server:—$ grep -i "Invalid user" sshd.log | cut -d " " -f7-9 | sort | uniq -c |
sort -kl -nr | head
121 Invalid user test
118 Invalid user guest
17 Invalid user toor
15 Invalid user tester
15 Invalid user student
14 Invalid user testing
14 Invalid user students
10 Invalid user root
10 Invalid user lpd

7 Invalid user webmaster
A figura ilustra a busca de padrões em logs do serviço SSH, nos quais foi utilizado um usuário Figura 7.8
inválido para acessar o sistema. Essas informações podem ser úteis para identificar uma Busca de padrões
em logs do serviço
varredura de força bruta realizada em um determinado servidor que faz o uso do serviço SSH. SSH.
122
Sumarização de informações
Essa técnica busca resumir informações contidas em um arquivo de log em específico, mos-
trando a frequência de certas informações, tal como número de linhas, número de acessos;
número de origens e outras. Geralmente, a sumarização é realizada por uma ferramenta
especializada em um formato de arquivo, pois a ferramenta necessita saber a semântica do
arquivo de log para compor as informações resumidas.
user@server:—$ cat kern.log | tr -d "DF" | awk '{print $11,$18,$20}' | sort | uniq -c |

sort -nr -kl | more
8 SRC=218.X.X.211.19 PROTO=UDP PT=42015
7 SRC=189.X.X.177.13 PROTO=TCP PT=22
6 SRC=222.X.X.25.44 PROTO=TCP PT=9999
4 SRC=61.X.X.74 PROTO=TCP PT=22
4 SRC=222.X.X.30 PROTO=TCP PT=22
4 SRC=218.X.X.91 PROTO=UDP PT=42015
Figura 7.9 A figura ilustra a sumarização de todos os acessos bloqueados pelo filtro de pacotes
Sumarização iptables. Ao contrário da busca de padrões, a técnica de sumarização apresenta uma versão
dos acessos
bloqueados no resumida das informações mapeadas. Isso é essencialmente útil quando se tem um grande
filtro de pacotes volume de informações para ser processados.
iptables.
Remoção de informações
Nesta técnica, também é conhecida por AI (artificial ignorance), busca-se remover infor- q
mações não relevantes para análise.
Isso significa reduzir variações não desejadas, ou sabidamente normais nos logs, tais como:
informações de controle de logs (hearbeat), e número dos processos (pid). Como resultado, são
apresentadas informações não usuais colapsadas com a sua respectiva frequência identificada.
Como comentado, os arquivos de logs podem conter informações com nível de detalha-
mento elevado. Nem sempre todas essas informações – todos os campos de uma men-
sagem de log – necessitam ser analisados para investigar um determinado incidente.
Ferramentas para o processamento de logs

Além das técnicas descritas, existe um conjunto de ferramentas especializadas para imple-
mentar o processamento de mensagens de logs. Tais ferramentas são muito heterogêneas,
cada qual implementa suas próprias técnicas de análise de logs incluindo técnicas especiali-
zadas utilizando inteligência artificial. Existe grande quantidade de ferramentas comerciais e
gratuitas para isso.
Na sequência, serão descritas algumas ferramentas tradicionais utilizadas por administra-

dores para gerenciar as informações de logs.
123
11 logcheck: é uma ferramenta desenvolvida para analisar automaticamente arquivos de
log em busca de violações de segurança e atividades não usuais. Para isso, a ferramenta
utiliza uma lista de expressões regulares para classificar as mensagens dos logs. Dessa
forma, é possível definir categorias, tal como: violação de sistema, mensagens a ignorar,
tentativas de comprometimento e outras. Outro recurso da ferramenta é a possibilidade
de agendar o processamento das mensagens de logs (hora/dia/semana/mês) permitindo
o envio das análises automatizadas via e-mail;
11 swatch: muito semelhante ao logchecker. Também utiliza expressões regulares para

classificar eventos de logs; no entanto, como diferencial a ferramenta permite instan-
ciar ações para cada evento classificado. Por exemplo, assim que muitas tentativas de
conexão de um determinado IP são detectadas, uma regra de bloqueio pode ser inserida
no filtro de pacotes;
11 OSSEC: ferramenta de código aberto para armazenamento e análise de logs. O conjunto de

funcionalidades da ferramenta incluem agentes para diferentes plataformas com os quais
é possível receber informações de sistemas de logs, tal como o Syslog. O OSSEC possui um
conjunto de regras pré-instaladas com as quais os logs podem ser processados de maneira
automatizada, reduzindo consideravelmente o trabalho manual de investigação. Adicional-
mente a ferramenta possui suporte para análise de logs em tempo real;
11 Splunk: ferramenta comercial que possui funcionalidades semelhantes ao OSSEC.

O Splunk atua como um centralizador de logs, no qual é possível concentrar diferentes
formatos de logs. O serviço possui plug-ins que permitem processar logs em formato
Syslog e também logs do formato Windows unificando as informações em uma base de
dados própria. Adicionalmente, o Splunk implementa módulos de análise de logs, per-
mitindo análises gráficas, análises forense (timeline) e ainda alguns módulos de análise
específicos para dispositivos, tal como dispositivos CISCO.
Por fim, este capítulo busca apresentar algumas ferramentas de análise de logs e suas
características. Não é o objetivo aqui apresentar todas as ferramentas, nem tampouco apre-
sentar ferramentas específicas de fabricantes. Deseja-se prover uma visão das principais
funcionalidades as quais um administrador de sistema pode demandar no seu processo de
análise de logs.
SIEM
Security Information and Event Management System (SIEM) é uma ferramenta que q
combina diferentes funcionalidades úteis para facilitar o processo de coleta, correlação e
processamento de informações de segurança.
Como característica, a ferramenta SIEM possui uma base de dados unificada, onde é pos-
sível correlacionar eventos de segurança e prover alertas para um administrador.
q
Sistemas de SIEM podem coletar os mais diversos eventos para análise. Para isso, boa
parte dos SIEM utiliza agentes coletores que podem ser instalados nos diversos sis-
temas, tal como: equipamentos de rede, servidores, firewalls, antivírus e sistemas de
detecção de intrusão. Os agentes coletam eventos e os encaminham para um servidor
central, o qual implementa técnicas para identificar anomalias.
Tais regras para análise de anomalias podem utilizar regras simples com análise estatística ou
ainda heurísticas desenvolvidas pelo próprio usuário. Em sistemas mais complexos, tipica-
mente soluções comerciais, diferentes análises podem ser utilizadas (gráficas, estatísticas
e inteligência artificial) e, como resultado de uma análise, ações podem ser configuradas a
partir da interface de gerenciamento.
124
Aspectos de segurança
d
A análise dos arquivos de logs deve estar embasada na integridade das informações arma-
zenadas. Existem muitas razões para que um sistema de log seja atacado. Obviamente, a
Detalhes técnicos e primeira delas é evitar que as ações de um atacante sejam registradas e, em última análise,
demais recursos para a evitar que um comprometimento seja identificado.
proteção da infraestru-
tura de logs fogem do
Em ataques mais sofisticados, entretanto, os atacantes utilizam técnicas que podem alterar
escopo deste capítulo;
no entanto, mais informações específicas nas mensagens de logs ou ainda inserir informações espúrias de
informações podem ser modo a desorientar a investigação dos eventos.
encontradas em:
Logging and Log Sendo assim, os ataques à infraestrutura de logs devem ser considerados um fator crítico para
Management: The
a segurança da instituição. Um atacante com acesso as informações armazenadas pode iden-
Authoritative Guide to
Dealing with Syslog, tificar dados de servidores vulneráveis, nomes de usuários e possíveis falhas de segurança.
q
Audit Logs, Events,
Alerts and other IT. De forma resumida, os ataques à infraestrutura de logs podem ter diversas motivações,
entre elas:
11 Destruir rastros de comprometimento;
11 Destruir informações armazenadas;
11 Modificar informações presentes nos logs;
11 Obter informações sensíveis sobre a infraestrutura.
Tais ameaças devem ser observadas pelos administradores de rede. Cabe aos administra-
dores assegurar que as informações de logs sejam íntegras, confidenciais e disponíveis para
análise. Diferentes mecanismos podem ser empregados para aprimorar a segurança da
infraestrutura de logs, entre eles: restringir o acesso ao sistema de arquivo, assegurar que
informações logs trafegadas na rede não possam ser acessadas; determinar os sistemas que
podem registrar informações de log no servidor centralizado.
Além de questões relativas à segurança do sistema de logs em si, é fundamental que os admi- q
nistradores de sistemas atentem para os equívocos mais frequentes na gerência de logs:
11 Ausência de logs: pior que não analisar os logs de forma frequente é não ativar os
sistemas de logs para registrar eventos. Todo sistema passível de produzir logs deve
ser configurado para exportar essas informações para uma estrutura centralizada
ou mesmo para um arquivo localmente armazenado. Do contrário, investigações,
análises e resolução de problemas não podem contar com o auxílio dos logs;
11 Não analisar os logs: não basta apenas coletar as informações dos diferentes dis-
positivos e sistemas, é importante ter alguma rotina manual ou automatizada para
analisar as informações armazenadas nos arquivos de logs;
11 Armazenar informações de log por um curto período de tempo: as informações

presentes nos logs podem ser utilizadas para investigar incidentes de segurança pas-
sados e também para prever possíveis anomalias em uma análise temporal;
11 Priorizar os logs antes mesmo de serem coletados: os logs só podem ser priori-
zados depois de serem coletados pelos diversos aplicativos e sistemas. Priorizar logs
de certos dispositivos ou aplicações apenas permite uma visão parcial dos eventos
desprezando possíveis consequências ou desdobramentos de uma ação registrada;
11 Ignorar logs de aplicações: os logs dos sistemas são essenciais, mas nem sempre
podem mapear todas as ações. Registrar eventos de aplicações é uma tarefa funda-
mental para identificar causas de problemas, como por exemplo, o motivo pelo qual
uma aplicação está consumindo todos os recursos de memória do sistema;
125
11 Buscar apenas por padrões maliciosos conhecidos: a busca por padrões conhe- q
cidos nos logs vai apenas demonstrar dados de ataques já conhecidos e possivel-
mente já tratados pelas ferramentas de segurança disponíveis na instituição. Como
alternativa, podem ser utilizadas a sumarização de informação e a técnica de igno-
rância artificial, ambas previamente descritas.
Recomendações para sistemas de logs

Como visto no decorrer do capítulo, é essencial para um CSIRT conhecer os detalhes de um
sistema de armazenamento de logs onde notificações de sistemas e alertas de segurança são
registrados. Nem todos os CSIRTs são responsáveis por desenvolver um sistema de logs para
uma instituição. No entanto, muitas vezes um CSIRT pode auxiliar na especificação de um
sistema de logs, ou ainda sugerir melhorias para a equipe responsável pela gerência dos logs.
Sendo assim, a seguir são listadas algumas recomendações que podem ser úteis no geren-
ciamento dos logs.
11 Utilizar poucos arquivos de logs: embora seja possível separar os logs em diferentes
arquivos – por severidade, por aplicação, entre outros – recomenda-se a utilização
de poucos arquivos para armazenar as notificações. Segundo alguns autores, poucos
arquivos de logs facilitam etapas de gerenciamento e correlação de eventos;
11 Automatizar etapas: é recomendável ter um processo automatizado para sumarização

dos logs. Dessa forma, um processo de sumarização de informações implementado de
forma periódica tende a auxiliar o gerenciado do grande volume de informações tratadas;
11 Evitar complexidade: nem sempre soluções complexas de análise de logs são efetivas
e fáceis de serem gerenciadas. Por exemplo, soluções de análise de logs que mesclam
diferentes técnicas, tal como regras dinâmicas e identificação de limiares são complexas
de serem gerenciadas e mantidas em um ambiente sempre crescente;
11 Centralizar os logs: centralizar as informações dos diferentes sistemas permite que os

dados sejam correlacionados de forma transparente. Além disso, a centralização dos logs
endereça algumas questões de segurança, tal como armazenamento e acesso às infor-
mações de sistemas não acessíveis localmente;
11 Implementar estrutura independente: um bom sistema de log tende a ser disseminado

para todos os departamentos da instituição. Desenvolver e gerenciar uma infraestrutura
de logs baseada em único fabricante – formato proprietário – pode tornar inviável a adoção
do sistema por outros departamentos. Formatos abertos são mais fáceis de configurar e
permitem adequar às características de ambientes heterogêneos;
11 Obter ou receber logs instantaneamente: algumas mensagens de logs requerem ações

logo após terem sido geradas. Em cenários onde as mensagens são apenas obtidas uma
única vez no dia, certas mensagens de logs podem ser observadas muito tarde;
11 Utilizar mesmo formato de hora: configurar todos os sistemas para registrar os eventos
em horário UTC é considerado uma boa política. Nem sempre os sistemas de logs regis-
tram o timestamp com o fuso horário utilizado. Logo, usar um mesmo fuso horário faci-
lita no processo de análise de incidentes sem ter a necessidade de verificar se os sistemas
estão no fuso horário correto.
126
11 Nist 800-92 guide to computer security log management;
11 Logging and Log Management: The Authoritative Guide to Understanding the Concepts
Surrounding Logging and Log Management – Anton A. Chuvakin;
11 UNIX and Linux System Administration Handbook (4th Edition);
11 RFC 5424: http://tools.ietf.org/html/rfc5424
127
128
8
Ferramentas para análise de
incidentes
Discutir cuidados necessários para a efetiva investigação de incidentes de segurança;
objetivos
Identificar características de incidentes; Conhecer ferramentas que podem ser

utilizadas na análise de incidentes.
conceitos
Análise de arquivos binários; Identificação de características obtidas em
artefatos encontrados.
Introdução
A análise de incidentes busca identificar informações sobre as atividades relacionadas q
com o incidente em si. Essa análise pode revelar contribuições valiosas para a resolução
do incidente provendo, de forma complementar, o entendimento das ações realizadas
pelo atacante. Resumidamente, a análise de incidente busca:
11 Validar o incidente;
11 Obter mais informações do incidente;
11 Determinar os vetores de ataque;
11 Determinar as vulnerabilidades do sistema;
11 Determinar o impacto técnico e operacional;
11 Coordenar informações adicionais com outras partes envolvidas. Capítulo 8 - Ferramentas para análise de incidentes
Nem sempre todos os incidentes de segurança que chegam até a equipe podem ser investi-
gados de forma extensiva. A grande maioria das investigações busca obter dados relevantes
dos incidentes de modo a solucionar uma falha de segurança explorada. No entanto, o CSIRT
pode ter políticas internas para especificar que tipos de incidentes devem ser investigados
de forma mais detalhada, incluindo aspectos operacionais, e encaminhamento legal para os
eventos identificados.
Um processo de investigação de incidentes pode ter efeitos indesejados: q

11 Buscar mais dados de um ataque pode resultar no eventual vazamento de informa-
ções sobre o incidente, o que pode colocar a instituição em uma situação delicada;
11 Identificar mais dados do incidente requerem tempo e recursos que, nem sempre,
estão disponíveis para a instituição;
11 Elencar mais informações do incidente pode ferir a política de segurança de uma instituição.
129
Diversos métodos podem ser empregados para coletar informações detalhadas de
um incidente.
Quando um incidente de segurança é identificado, por exemplo, a equipe do CSIRT tem q

em mãos um conjunto básico de informações que podem ser utilizadas como ponto de
partida de uma investigação:
11 Endereços IPs envolvidos;
11 Domínios de redes;
11 Ações suspeitas;
11 Serviços abusados;
11 Protocolos utilizados;
11 Malwares;
11 Logs de eventos.
Além de tais informações sensíveis previamente identificadas nas etapas iniciais do inci-
dente, existem outras fontes que podem ser úteis na composição do cenário de investi-
gação. Para isso, é importante que a equipe do CSIRT tenha conhecimento de ferramentas
básicas para análise de dados de incidentes, incluindo ferramentas de sistemas e serviços
online disponibilizados gratuitamente na rede.
O objetivo deste capítulo é apresentar ferramentas e técnicas com as quais os membros de

um CSIRT podem aplicar em uma análise prévia e superficial de incidentes de segurança.
Foge do escopo deste capítulo realizar uma análise forense de máquinas comprometidas e
investigar arquivos maliciosos de maneira minuciosa. Sendo assim, é importante lembrar
que a investigações executadas diretamente em sistemas suspeitos de comprometimento
podem destruir evidências, como: horário de acesso de arquivos e histórico de execução
dos comandos.
Por questões de organização, este capítulo incialmente discute preocupações relativas à

privacidade dos acessos de um CSIRT, sobretudo em etapas de investigação de incidentes.
Posteriormente, são descritas ferramentas que podem ser úteis na investigação de arte-
fatos obtidos em máquinas infectadas. E, por fim, são apresentadas algumas listas de blo-
queio e base de dados com informações de sistemas comprometidos que podem ser usados
para correlacionar informações de eventos de segurança.
Preocupações de privacidade
Ao realizar uma tarefa de investigação de incidentes o CSIRT deve ter cuidados adicio- q
nais evitando que suas atividades sejam mapeadas por terceiros. Do contrário, as ações
realizadas pelo CSIRT podem ser seriamente prejudicadas. Algumas ações decorrentes
da identificação dos acessos são:
11 Bloqueios de acesso;
11 Alvo de ataques;
11 Modo de operação.
Certas atividades realizadas pelo CSIRT podem ser facilmente mapeadas por terceiros. Em
especial, os acessos de rede realizados pelo CSIRT revelam dados de endereçamento IP e
características operacionais, tal como Sistema Operacional, navegador web utilizado e perfil
de acesso a sites.
130
Em alguns casos, a identificação do endereçamento de rede do CSIRT pode acarretar em res-
trições de acessos a determinadas redes. Tem-se conhecimento de que alguns fraudadores
e atacantes bloqueiam determinados endereços de rede a fim de evitar a identificação de
suas atividades. Por exemplo, um website com fraude pode não estar acessível para o bloco
de endereçamento CSIRT, mas sim para as demais redes.
Adicionalmente, o simples fato de saber que uma investigação está sendo conduzida pelo
time pode fazer com que um atacante altere suas táticas. Em casos mais raros, a identifi-
cação pode levar com que os criminosos lancem represálias ao CSIRT como. por exemplo,
uma negação de serviço distribuído para o IP identificado.
De fato, a investigação de um incidente de segurança sempre deixará algum rastro. Por mais
cuidado que se tome, sempre existe a probabilidade de que algumas informações sejam
mapeadas pelo alvo da investigação. Os acessos realizados pelo CSIRT podem tornar um
sistema facilmente rastreável de maneiras nem sempre tão óbvias. Por exemplo, um nave-
gador web (browser) pode ser utilizado para identificar um usuário ou investigador do CSIRT.
w Quando um navegador acessa um site, um conjunto de informações é enviado para o ser-

Um projeto denomi- vidor web destino. Esse conjunto de informações corresponde a características muitas vezes
nado Panopticlick únicas de navegador, tal como: versão do navegador (user-agent), Sistema Operacional,
desenvolveu um
website onde é possível fontes. Os plug-ins (flash, java) também disponibilizam outro conjunto de dados que podem
identificar quão único e ser utilizados para identificar o browser. Existem alguns trabalhos na área de privacidade
rastreável é um browser
que investigam a entropia das informações disponibilizadas pelo browser a fim de utilizá-la
testado: https://
panopticlick.eff.org/ para mapear as atividades.
Para isso, o Panopticlick analisa todas as informações que o browser compartilha com os
sites visitados e correlaciona com informações presentes na base de dados do próprio
serviço. A figura a seguir ilustra o resultado de um teste:
Capítulo 8 - Ferramentas para análise de incidentes
Figura 8.1
Análise da
rastreabilidade de
um browser.
131
No exemplo, compondo apenas as informações que o browser forneceu para o site Panopticlick,
pode-se constatar que o browser testado pode ser unicamente identificado em toda a base
de dados do projeto.
Além do Panopticlick, existem outros projetos que buscam ilustrar apenas informações de
cabeçalho que o browser fornece para uma aplicação. O site a seguir, por exemplo, discri-
mina todas as informações disponibilizadas pelo browser: http://browserspy.dk/
Já outros serviços prometem identificar se o acesso está sendo realizado através de um

servidor proxy: http://www.iprivacytools.com/proxy-checker-anonymity-test/
Tais serviços e técnicas de identificação são úteis para conscientização de usuários sobre q
a privacidade.
No contexto de resposta a incidentes, esses serviços podem auxiliar na identificação de

possíveis rastros – pegadas digitais – deixados pelos acessos realizados pela equipe.
É importante notar que mesmo utilizando diferentes endereçamentos IPs, o mapeamento
do browser vai identificar que o acesso foi realizado do mesmo local.
Diante disso, a equipe do CSIRT deve primar por certo nível de privacidade nas tarefas
desempenhadas.
Existem alguns recursos que a equipe pode implementar para evitar que as suas ativi- q
dades sejam identificadas, como por exemplo:
11 Proxies;
11 Proxies web;
11 VPN;
11 Rede TOR.
Na sequência são descritas as principais técnicas utilizadas por CSIRT para evitar que suas
conexões e atividades sejam mapeadas por cibercriminosos.
Proxies
Uma das maneiras mais populares para mascarar os acessos na rede é através do uso q
de servidores proxy.
Os proxies são sistemas que atuam como intermediários para os acessos na rede. Para isso,
o proxy atua entre o cliente que faz a requisição por um serviço e o servidor que responde
a requisição.
Boa parte das instituições utilizam serviços de proxy para gerenciar as conexões dos usuá-
rios permitindo o uso de Web-Cache, filtro de conteúdo e bloqueio de sites, muito embora o
proxy também possa ser utilizado por questões de privacidade. Afinal, quando se utiliza um
proxy, todas as requisições são primeiramente enviadas para o proxy e posteriormente para
o seu destino com endereçamento do proxy, ou seja, com a origem mascarada.
Algumas características dos proxies: q

11 Não existe privacidade entre o cliente e o proxy. O servidor proxy tem conhecimento
de todas as informações do cliente que solicitou o acesso às informações;
11 O endereçamento do proxy pode ser facilmente mapeado; afinal, todas as conexões

realizadas iram ter como origem o endereço do próprio proxy;
132
11 Existem diferentes tipos de proxies. Diferentes proxies que suportam diferentes q
protocolos. Os principais protocolos suportados são:
22 HTTP: o protocolo para comunicação web. Um dos protocolos mais utilizados para
a comunicação com servidores proxy atuando apenas com requisições TCP;
22 SOCKS 4: é um protocolo de comunicação intermediário que suporta apenas

tráfego TCP, não permitindo nenhuma forma de autenticação para acesso;
22 SOCKS 5: o protocolo SOCKS 5 é a extensão do protocolo SOCKS 4. É incorporado

suporte aos protocolos TCP e UDP e, também, a possibilidade de usar diferentes
métodos de autenticação.
Web-Proxies
Os Web-Proxies são essencialmente proxies HTTP embutidos em uma interface web. q
Dessa maneira, um usuário acessa um website específico e insere o endereço da página web
que deseja acessar de forma anônima. O Web-Proxy recebe como parâmetro uma URL a ser
visitada e disponibiliza no próprio corpo da página o conteúdo visitado usando via Proxy,
como pode ser observado na figura:
opções de acesso
Figura 8.2
Acesso de um
website utilizando
o serviço de proxy
‘goprivate.eu’.
A imagem ilustra o uso de um serviço de Proxy-Web. Na parte superior, o usuário pode

definir a URL do site a ser acessado pelo proxy e também alguns parâmetros de acesso, tal
como bloqueio de cookies, bloqueio de scripts e outros. Capítulo 8 - Ferramentas para análise de incidentes
Na referida consulta, foi requisitada a URL: http://wwww.whatismyip.com/ e o seu con-

teúdo é disponibilizado no corpo da página web. No corpo da mensagem é disponibilizado
o conteúdo do acesso. A página requisitada “www.whatismyip.com” exibe o IP de origem
da requisição. Como pode ser visto, o IP de origem – que representa o IP do Web-Proxy – é
141.105.125.183 tendo como origem Holanda. Esse fato confirma que o acesso foi realizado
via proxy.
Naturalmente, a utilização de Web-Proxies é mais fácil. Do contrário, o usuário deveria confi-

gurar um proxy HTTP nas próprias configurações do seu navegador web. Existem diferentes
serviços de Web-Proxy disponíveis na rede. Boa parte dos serviços é gratuita; no entanto,
existem serviços pagos que incorporam funcionalidades adicionais, assim como filtro de
conteúdo e proteção contra sites maliciosos. Exemplo de sites que podem ser utilizados
para navegação anônima:
133
11 Anonymouse: http://anonymouse.org/
11 Cloack: https://incloak.com/
11 Goprive: http://goprivate.eu/
Cada serviço é independente e implementa suas próprias particularidades para acesso

anônimo. O preceito básico é acessar o website usando o próprio endereço do serviço,
ocultando o real IP que solicitou o serviço. Mesmo ocultando o IP do solicitando, existem
serviços que implementam diferentes níveis de anonimato, atuando no nível do cabeçalho
do protocolo HTTP.
O serviço anonymouse, por exemplo, remove informações do User-Agent e do tipo do q

browser utilizado pelo usuário. Entretanto, o serviço opta por inserir informações que
sinalizam a utilização do serviço Web-Proxy, inserindo a string “http://Anonymouse.org/
(Unix)” no campo User-Agent do cabeçalho HTTP:
GET /index.html HTTP/1.1
Host: mail82.anonymouse.org
User-Agent: http://Anonymouse.org/ (Unix)
Connection: keep-alive
Essas informações de cabeçalho geralmente não alteram a apresentação do website, mas

chegam até o servidor do site requisitado. Isso significa que o servidor do website pode
identificar que este foi requisitado via um serviço de “anonimização”.
Em outros serviços, por exemplo, outras informações são embutidas no cabeçalho da

requisição. No exemplo a seguir um determinado serviço de Web-Proxy opta por manter as
informações do User-Agent original do requisitante.
No entanto, o serviço insere o campo “VIA” informando o IP do proxy utilizado, como q

pode ser visualizado a seguir.
GET /index.html HTTP/1.1
Host: notsohide.com
User-Agent: Mozilla/5.0 (X11; OpenBSD amd64) AppleWebKit/537.17
Connection: keep-alive
VIA: 200.X.X.X
As diferentes implementações tornam alguns serviços mais “anônimos” que outros.

O conjunto de informações providas pelos serviços de Web-Proxies podem ser utilizados
para identificar o próprio serviço. Sendo assim, alguns servidores web maliciosos optam
por não responder requisições oriundas de serviços de anonimização ou, ainda, requisições
com certas diretivas presentes no cabeçalho HTTP. Cabe ao CSIRT avaliar o serviço a ser
utilizado tendo em vista os diferentes aspectos de privacidade dos Web-Proxies.
Virtual Private Network (VPN)

De forma similar aos proxies, uma VPN permite que uma conexão seja estabelecida com q
um servidor remoto permitindo que o tráfego seja enviado através deste. A principal
diferença, com relação aos proxies, reside no fato de que toda transmissão ocorre de
forma criptografada.
134
Para isso uma conexão VPN cria uma espécie de um túnel seguro entre dois dispositivos de
rede utilizando uma autenticação compartilhada entre as duas extremidades do túnel.
Um CSIRT pode construir sua própria infraestrutura de VPN. Para isso, pode ser contratado
um servidor remoto localizado em outro país e através de um software específico, tal como
OpenVPN, configurar os seus dispositivos para acesso.
Por outro lado, é também possível encontrar serviços de VPN especializados tendo como
foco a anonimização do tráfego. Alguns serviços comerciais, por exemplo, permitem o
estabelecimento de um túnel encriptado com um pool de centenas de IPs rotativos. Dessa
maneira, a cada estabelecimento de sessão um novo IP de saída é designado. Isso dificulta o
rastreamento e o mapeamento das atividades do CSIRT. Exemplos de serviços de VPN:
11 Private Internet Access: https://www.privateinternetaccess.com/
11 Privacy.io: https://privacy.io/
11 Viking VPN: http://vikingvpn.com/
11 IP Vanish: http://www.ipvanish.com/
Esses serviços são muitos utilizados por CSIRT e também por usuários que residem em
w
países com censura de conteúdo. Com isso, todas as conexões de um sistema são encami-
nhadas para o servidor remoto da VPN, tipicamente localizado em outro país, a partir do
Saiba mais em http:// qual os acessos são efetivamente estabelecidos.
torrentfreak.com/
vpn-services-that-take- A título de curiosidade, existem websites que listam VPNs supostamente mais anônimas, as
-your-anonymity-
quais não armazenam informações de logs. Dessa forma, ao lidar com incidentes onde tais
-seriously-2013-edition/
VPNs são utilizadas, o CSIRT certamente terá problemas de identificação.
Rede Tor
A rede Tor – The Onion Router – é uma rede desenvolvida para prover anonimato aos q
seus usuários que acessam a internet. O Tor é gratuito e pode ser utilizado na maioria
dos Sistemas Operacionais. O funcionamento da rede consiste no roteamento não deter-
minístico das informações entre os nodos da rede.
Os computadores dispersos pelo mundo que fazem parte da rede Tor são responsáveis
por repassar o fluxo de informações de forma criptografada a partir de um ponto inicial
até um dos milhares de nodos de saídas da rede.
Nesse nodo final, a requisição é descriptografada e repassada o seu destino. Nodos de saída
são servidores especiais que são responsáveis por encaminhar o tráfego até o seu destino e
também ser o ponto de entrada para o tráfego retornado. A rede Tor possui inúmeros servi-
dores de saída; no entanto, a escolha destes é realizada de forma não determinística.
Quando uma requisição TOR é solicitada, o servidor destino não sabe o seu IP originador,
mas sim o IP do nodo Tor de saída. Além do mais, a rede TOR não tem como identificar o IP
originador da requisição, pois o conhecimento está disseminado na rede. Cada nodo que
repassa as informações sabe apenas parte do caminho realizado pelos dados. Os nodos não
sabem por que outros nódulos pelos quais a informações trafegou.
135
Uso da rede Tor na investigação de incidentes
Como descrito, o Tor é uma ferramenta gratuita e disponível em diversas plataformas e q
Sistemas Operacionais. Existe um conjunto de ferramentas que permitem acessar a rede
Tor para realizar as mais diferentes tarefas, tal como navegação web de forma anônima,
download de malwares, acesso a serviços IRC e outros.
Para anonimizar as atividades na web, temos basicamente duas opções: a) instalar a ferra-
menta “tor” e configurar o seu browser para acessar a internet via SOCKS usando a porta
9050/TCP (localhost), porta padronizada para tráfego de dados na rede TOR; b) utilizar o
software Tor Browser Bundle: https://www.torproject.org/projects/torbrowser.html
O Tor Browser Bundle é um browser com todos os requisitos para navegar na rede
Tor autocontidos.
Ou seja, não necessita a instalação de nenhum recurso extra para acessar dados de
forma anônima.
Além do acesso via browser, é possível usar a rede Tor a partir da linha de comando. Isso é
muito útil em casos onde se necessita obter um malware da rede ou ainda acessar outros
protocolos. Uma dessas ferramentas é o torproxy, que atua como SOCKS para a rede Tor:
https://code.google.com/p/torsocks/
Utilizando o torsocks é possível acessar aplicações que permitem a utilização de SOCKs

diretamente via rede TOR, como exemplificado a seguir:
usewithtor [aplicação]
$ usewithtor wget http://site.malware/trojan.exe
Ou ainda:
$ usewithtor ssh root@server
Por fim, a rede Tor constitui mais uma alternativa para os CSIRT ocultarem suas atividades
da rede e evitar com que suas atividades sejam identificadas por atacantes. Sabe-se no
entanto que existem algumas limitações da rede incluindo o próprio desempenho da rede.
Devido às características intrínsecas do protocolo, uma série de nodos intermediários é
utilizada no processo de roteamento inserindo uma latência considerável no mesmo.
Figura 8.3
Notícia sobre
prisão de usuário
da rede Tor.
136
Mecanismos de busca
A busca de informações relativas a incidentes na web pode ser muito efetiva. Além de
auxiliar na identificação de detalhes de incidentes, os mecanismos de busca podem ser
úteis para revelar o modus operandi do ataque e até mesmo os responsáveis pelo ataque.
Assim como comentado anteriormente, recomenda-se zelar pela privacidade das informa-
ções. O histórico de consulta e histórico de navegação pode revelar o perfil das atividades
desempenhas pela equipe do CSIRT. Logo, é importante, ao realizar consultas a mecanismos
de busca, não estar associado a nenhuma conta, tal como a conta de usuário de serviços
(Google, Yahoo! etc.).
Adicionalmente, existem algumas extensões para o navegador web que podem ser utilizadas
para evitar aprimorar a segurança e privacidade da navegação. O site a seguir apresenta um
conjunto de extensões específicas para cada tipo de browser: http://fixtracking.com/
w Além dos tradicionais mecanismos de busca, devem-se buscar informações em fontes q
Existem outros
mecanismos de busca auxiliares, tal como websites de redes sociais e microblogs. Sites como Twitter podem
com foco em privaci- ser úteis para identificar ataques em andamento ou fazer o planejamento. Uma simples
dade. Um dos mais
busca por “attack <domínio>”, “tango down <domínio>” e “DoS <domíno>” podem revelar
populares é o
DuckDuckGo.com: possíveis ataques a um domínio. A seguir, exemplos de informações de incidentes que
http://duckduckgo.com/ podem ser investigados:
11 Artefato encontrado: muitas vezes informações contidas nos artefatos encontrados

nos sistema comprometido, tal como: comentário do código fonte, assinaturas e
hash criptográfico podem ser úteis para identificar mais detalhes sobre o incidente
investigado;
11 Método de comprometimento: em alguns casos, a forma com que o sistema foi

comprometido pode representar uma assinatura de um ataque. Isso é muito obser-
vado em ataques a aplicativos web, onde uma sequência específica de comandos é
utilizada para comprometer o sistema;
11 Endereço IP: a busca pelo endereço IP que originou o ataque pode revelar infor-
mações surpreendentes. Por exemplo, identificar que existem fóruns de segurança
comentando sobre as atividades maliciosas originadas pelo IP.
Analisadores de malwares
Muitas vezes, ao investigar um incidente de segurança, a equipe do CSIRT depara-se com
artefatos de atacantes e também arquivos maliciosos. Nesse processo de investigação,
a análise do arquivo malicioso pode revelar mais detalhes do incidente identificando, por
exemplo, ações desempenhadas pelo arquivo malicioso, vetores de ataque, motivações dos
atacantes e, até mesmo, o desenvolvedor dos malwares.
O interesse por entender o funcionamento e características de um arquivo malicioso é

uma preocupação recorrente, embora a análise de malwares seja uma atividade complexa
e carece de conhecimentos especializados. Nem sempre os CSIRTs possuem mão de obra
especializada para investigar malwares, tampouco, tempo hábil para analisar todos os
malwares e artefatos obtidos.
Em alguns incidentes de segurança, no entanto, onde é importante que a equipe do CSIRT tente
obter detalhes do comprometimento que, via de regra, passa por uma investigação de malware.
137
Existe um conjunto de técnicas e ferramentas que podem auxiliar os membros da equipe q
na investigação de arquivos maliciosos. Os principais procedimentos consistem em:
11 Assinaturas de malwares: identificação de características únicas do malware com as

quais é possível classificar um arquivo malicioso;
11 Análise comportamental: ações desempenhadas pelo arquivo malicioso quando

executado no Sistema Operacional.
Por questões didáticas, vamos usar um arquivo malicioso específico nas diferentes análises
que serão apresentadas:
Nome do Arquivo bot.exe
MD5 d262b68451826588002bcbb27b28dbef
ea5cd9326d4bb1ff89054e57c67e7f6d2925cba543aa-
SHA 256 Tabela 8.1
04f214f90f730c62f1f0
Arquivo malicioso.
Assinaturas de malwares
Uma das principais ferramentas para combater malwares são os sistemas de antivírus.
As tradicionais ferramentas tentam identificar uma assinatura – uma sequência característica
de bytes – para identificar um código malicioso.
A assinatura de um sistema de antivírus é útil para identificar as ações de um arquivo q

malicioso. A listagem anterior ilustra a execução do antivírus Clamav (clamscan), anti-
vírus gratuito e de código aberto: http://clamav.net/.
$ clamscan /tmp/bot.exe
/tmp/bot.exe: Trojan.Poebot-21 FOUND
----------- SCAN SUMMARY -----------
Known viruses: 3050244
Engine version: 0.97.8
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.12 MB
Data read: 0.12 MB (ratio 1.00:1)

Time: 8.057 sec (0 m 8 s)
A listagem anterior ilustra a inspeção do arquivo “bot.exe”, tendo como resultado a assina-
tura “Trojan.Poebot-21”. O nome da assinatura pode ser utilizado para obter informações
adicionais significantes sobre o malware. Através de uma pesquisa no website do fabricante
do antivírus, é possível obter informações do possível vetor de infecção e ações desem-
penhadas pelo malware. A figura 8.4 ilustra os detalhes da assinatura relativa ao malware
“Poebot” obtida no website da empresa Microsoft (http://www.microsoft.com/security/
portal/threat/). Nessa figura, é possível obter a descrição do comportamento e funcionali-
dades do malware (payload).
138
Figura 8.4
Descrição das
funcionalidades
do malware.
Sendo assim, o investigador pode supor que a máquina comprometida pelo malware “bot.exe”
possivelmente faz parte de uma botnet, onde diversas ações maliciosas podem ser desem-
penhadas na rede local e também destinadas a redes externas.
As assinaturas de arquivos maliciosos não são padronizadas, ou seja, o nome dado para Capítulo 8 - Ferramentas para análise de incidentes
cada assinatura é dependente das empresas do sistema de antivírus. As empresas de
sistemas de antivírus estão constantemente analisando novos malwares para a identifi-
cação de assinaturas que possam indicar um arquivo malicioso. Assim que uma assinatura é
identificada, costuma-se atribuir um nome que identifique a assinatura seguindo a nomen-
clatura da própria empresa. Logo, um mesmo malware verificado por um antivírus pode ter
uma assinatura completamente diferentes em outros sistemas de antivírus.
Ferramentas multiantivírus
Existem alguns serviços que permitem submeter arquivos suspeitos para detecção de
assinatura em múltiplas ferramentas de antivírus. Dessa forma, é possível identificar quais
assinaturas são atribuídas ao arquivo analisado e, ainda, se o mesmo arquivo é classificado
como malicioso nos diferentes antivírus.
139
Boa parte dos serviços que analisam malwares em múltiplas plataformas de antivírus está
disponível gratuitamente na rede.
A seguir são apresentados os principais serviços para análise de arquivos maliciosos em q

múltiplas ferramentas de antivírus:
11 VirusTotal: https://www.virustotal.com/
11 Virscan: http://www.virscan.org/
11 Metascan: https://www.metascan-online.com/
Mesmo existindo diversos serviços para inspeção de arquivos maliciosos, atualmente o

serviço mais completo é o VirusTotal. O VirusTotal é um serviço gratuito que permite analisar
arquivos suspeitos e também URLs em busca de facilitar a detecção rápida de arquivos
maliciosos. Embora a VirusTotal tenha incorporado uma série de novas análises adicionais,
após a sua aquisição pelo Google, este capítulo vai ater-se apenas a análise de assinaturas
de arquivos suspeitos.
O primeiro passo é submeter o arquivo diretamente ao serviço online. Para isso, o VirusTotal
permite a submissão de arquivos utilizando diferentes mecanismos:
11 Submissão via website: a maneira mais comum de submeter arquivos para análise é
através da interface web. Dessa forma, o usuário pode enviar arquivos para análise sem
gerar alertas dos sistemas de segurança – tal como filtros e IDS – usando o protocolo
HTTPS;
11 Submissão via e-mail: o usuário pode compor uma mensagem de e-mail anexando o
arquivo a ser analisado. Como resultado, será enviada uma mensagem com o resultado
para o mesmo remetente;
11 Submissão via aplicativos: através de uma interface disponibilizada, é possível desen-

volver ferramentas para submissão. Existem algumas ferramentas desenvolvidas para
a submissão de arquivos, tais como; extensões de browser, aplicativos para celulares,
aplicativos de desktop, entre outros.
Cada arquivo submetido é analisado por todos os sistemas antivírus disponibilizado pelo
VirusTotal.
Caso o mesmo arquivo (mesmo hash criptográfico) já tenha sido submetido ao

VirusTotal, é possível:
11 Forçar uma nova análise;
11 Exibir o relatório da última análise realizada.
A seguir ilustra um exemplo da interface do VirusTotal com o resultado de uma análise.

140
Figura 8.5
Resultado de
uma análise de
um malware (bot.
exe) no serviço
VirusTotal.
Como pode ser observado, o malware analisado (bot.exe) foi verificado por 46 diferentes
antivírus e foram encontradas assinaturas para o malware em 43 deles. Significa que
3 sistemas de antivírus não identificaram o arquivo como malicioso. O relatório descreve
informações relativas ao sistema de antivírus utilizado, a versão do software, a última atuali-
zação da base de dados de vacinas, e o tipo de assinatura detectado. A análise nos dife-
rentes sistemas é útil para a comparação da eficiência dos diferentes sistemas de antivírus
em relação ao um arquivo malicioso em específico.
Além da submissão de arquivos, o VirusTotal permite consultar a análise de arquivos já

examinados utilizando um hash criptográfico (MD5, SHA1, SHA256) do binário. Esse recurso
permite apenas obter a análise de um determinado arquivo previamente efetuada; no
entanto, não é possível obter o arquivo executável originalmente submetido.
Virustotal
Utilize o malware fornecido (bot.exe) e submeta para o VirusTotal. Responsa as questões
a seguir:
a. A data da primeira submissão do arquivo no serviço VirusTotal:
b. Quais antivírus não detectaram o arquivo bot.exe como arquivo malicioso.
Análise comportamental
Além da busca por assinaturas de um arquivo malicioso, é possível analisar um binário
usando outras abordagens como, por exemplo, a análise comportamental. A análise
comportamental consiste em traçar as ações desempenhadas por um arquivo binário no
Sistema Operacional no qual é executado. Essa análise do funcionamento de arquivos biná-
rios pode ser realizada de duas diferentes maneiras: de forma estática ou dinâmica.
141
A análise estática consiste em avaliar o funcionamento de um programa sem sua execução,
baseando-se apenas no seu código executável. As técnicas mais tradicionais consistem em
extrair instruções do código assembler do programa e inferir conclusões com base na sequência
das instruções. No entanto, a principal deficiência desse método é a possibilidade do código
de máquina analisado não refletir o mesmo comportamento que o malware apresenta
quando executado. O comando strings, por exemplo, pode ser utilizado para obter mais
informações de um arquivo sem executar o mesmo:
$ strings /tmp/NotaFiscal.exe
<...>
“network.proxy.autoconfig_url”
“network.proxy.no_proxies_on”
“network.proxy.ftp_port”
“network.proxy.ftp”
<...>
Como ilustrado, o resultado do comando strings exibe todos os caracteres que podem ser
visualizados contidos no arquivo executável. O fragmento citado anteriormente descreve
funções instanciadas pelo malware. Nesse caso, são exibidas funções que alteram a configu-
ração de rede, mas especificamente a configuração do proxy.
A análise estática é pouco eficiente para programas que utilizam técnicas de ofuscação ou
polimorfismo, como é o caso do malware Conficker. Nesses casos, a análise do arquivo pode
dispender maior tempo de análise e mão de obra especializada. Sendo assim, a análise
estática apresenta limitações para malwares mais complexos, o que motivou o surgimento
de técnicas complementares, como é o caso da análise dinâmica.
A análise dinâmica, por outro lado, consiste em observar as características funcionais do

malware através da sua execução em um ambiente controlado. As principais metodologias
de análise dinâmica baseiam-se em:
11 Comparação do status do Sistema Operacional antes e imediatamente após a execução

do arquivo;
11 Monitoração das ações em tempo de execução.
Na primeira abordagem, busca-se fazer uma comparação do Sistema Operacional completo

identificando alterações causadas pelo arquivo binário executado. Como resultado, essa
técnica traça uma visão geral das funcionalidades do binário, como arquivos criados, dados
removidos, entre outros. Essa solução, entretanto, não determina mudanças dinâmicas
intermediárias ao estado inicial e final da comparação do sistema. Mudanças como a criação
de arquivos durante a execução e a deleção de arquivos antes do final do processo são
transparentes a essa análise. Por outro lado, na segunda abordagem cuja monitoração das
ações do malware é dada durante a execução, tais ações são traçadas. Mesmo sendo mais
complexa de implementar, a análise de binários durante sua execução vem popularizando-
-se devido ao bom resultado da técnica perante códigos polimórficos e ofuscados.
A principal limitação da análise dinâmica de malware é a possibilidade de executar apenas

uma amostra de binário de cada vez. Afinal, a execução de outros binários no mesmo
ambiente controlado dificulta a distinção das ações de cada malware.
142
Com a utilização de tecnologias de virtualização de sistemas, a análise dinâmica de
malwares ganhou outra dimensão. De fato, a facilidade de reconstruir um ambiente virtu-
alizado permitiu o surgimento de ferramentas mais detalhistas e escaláveis para a análise
dinâmica, como é o caso dos sandboxes.
Sandbox
Sandboxes são sistemas automatizados para análise de malware onde se busca executar as
ações de um malware em um sistema isolado, geralmente através do uso de uma máquina
virtual. Dessa forma, é possível identificar ações executadas por um arquivo suspeito sem
comprometer um sistema em produção.
Tipicamente, os sandboxes são utilizados para processar um grande número de malwares

e obter características de um arquivo suspeito. Essa análise inicial permite identificar certas
ações suspeitas desempenhadas pelo arquivo analisado e classificá-lo como malicioso.
Os sandboxes são muito utilizados para efetuar uma análise instantânea das ações do
malware evitando, muitas vezes, que técnicas mais sofisticadas, tal como engenharia
reversa, seja demandada.
Em ambientes com equipes com tamanho reduzido, é importante que um sandbox seja fácil
de ser utilizado e forneça um resumo de alto nível das atividades maliciosas conduzidas
durante a análise. Isso faz com que o malware seja mais acessível e permite que qualquer
pessoa possa conduzir os primeiros estágios da investigação. No caso de obter dados inte-
ressantes, o caso pode ser repassado para análise do time ou para parceiros externos.
Evidentemente que a implementação de soluções baseadas em sandbox requer cuidados

especiais de segurança, tais como restrição de acesso à rede. Existem algumas soluções no
mercado que permitem o próprio CSIRT implementar um sandbox local e automatizar boa
parte das tarefas de análise. Por outro lado, existem diversas ferramentas automatizadas
para análise de malware disponível na web, cada qual com suas características e funcionali-
dades. Na sequência, são apresentadas algumas ferramentas disponibilizadas para análise
de malware de forma gratuita:
11 Anubis: http://anubis.iseclab.org/
11 Malwr: https://malwr.com/submission/
11 Comodo: http://camas.comodo.com/
11 EUREKA: http://eureka.cyber-ta.org/
11 ThreatExpert: http://www.threatexpert.com/submit.aspx
11 ThreatTrack: http://www.threattracksecurity.com/resources/sandbox-malware-analysis.aspx
11 ViCheck: https://www.vicheck.ca/
11 Xandora: http://www.xandora.net/xangui/
Como característica, os sandboxes tradicionalmente simulam o Sistema Operacional

Windows, afinal, a grande maioria de malwares existentes é escrita para esse sistema.
Funções comuns observadas pelo sandbox descrevem funcionalidades como:
11 Arquivos criados ou modificados;
11 Acessos ou modificações a chave do registro do sistema;
11 Bibliotecas dinâmicas carregadas;
11 Áreas da memória virtual utilizada;
11 Processos criados;
143
11 Conexões de rede instanciadas;
11 Dados transmitidos pela rede.
Os relatórios disponibilizados pelos sandboxes podem variar bastante devido a particula-

ridades de implementação. Características como o Sistema Operacional no qual o arquivo
suspeito é executado; arquitetura implementada; e o conjunto de chamadas de sistema
monitorado pelo sandbox reflete diretamente no relatório disponibilizado pela ferramenta.
O sandbox Anubis, por exemplo, é uma ferramenta para análise de malwares disponível gra-
tuitamente na web que permite análise de arquivos executáveis para a plataforma Windows
e também aplicações para sistemas Android. Para isso, o Anubis utiliza como base o software
Qemu, que permite emular Sistemas Operacionais e monitorar chamadas de sistemas
instanciadas pelos arquivos analisados. Como resultado, é disponibilizado um relatório
detalhado das funcionalidades do arquivo suspeito analisado.
Figura 8.6
Fragmento de um
relatório das ações
de um malwares
disponibilizado pelo
sandbox Anúbis.
A figura ilustra um fragmento de um relatório de análise disponibilizado pelo Anubis.

Como pode ser visto, na parte superior (Summary) são descritas as principais ações desem-
penhadas pelo arquivo analisado. Essas informações são compostas com base nas cha-
madas de sistema solicitadas pelo arquivo durante sua execução no ambiente controlado.
Diferentemente do sandbox Anubis, o sandbox de código aberto Cuckoo Sandbox integra as

plataformas mais comuns de virtualização como VirtualBox e VMware para executar e regis-
trar atividades desempenhadas por um arquivo suspeito. Dessa forma, é possível utilizar
as plataformas de virtualização para especificar qual o Sistema Operacional será emulado
(Windows ou Linux) pelo sandbox. Portanto, o Cuckoo permite instanciar diversas máquinas
virtuais com as mais diferentes configurações de Sistemas Operacionais e arquiteturas.
144
O Cuckoo também permite interagir durante a execução do malware. Em alguns casos,
certas funcionalidades de malwares só são ativadas em situações específicas, tal como
acesso a um website bancário.
Por tratar-se de um software livre e de código aberto, o Cuckoo Sandobox permite com que
todo o seu sistema seja copiado para um servidor e instanciado localmente. Sendo, portanto,
muito útil para montar um laboratório de análise de malware de uma instituição. Do contrário,
sem a necessidade de instalar o sistema, é possível usar serviços online que implementam a
ferramenta Cuckoo via interface web. Um exemplo é o site Malwr: https://malwr.com/
O Malwr funciona como uma interface para o sandbox Cuckoo. Todo arquivo submetido via inter-
face web instancia uma máquina virtual e ativa o serviço de análise. Como resultado, é exibida
uma página web com as características de execução do arquivo analisado (vide figura 8.7).
O Malwr mantém uma base de dados com informações de todos os malwares já submetidos
ao sistema. Através de uma consulta do código hash de um arquivo executável é possível
visualizar quando foi à última análise do mesmo, ou ainda, se identificar que o arquivo exe-
cutável submetido nunca foi analisado pelo sistema.
Figura 8.7
Fragmento
do relatório
das ações de
um malware
disponibilizado Capítulo 8 - Ferramentas para análise de incidentes
pelo sandbox
Malwr.
A imagem apresenta um fragmento do relatório de funcionalidades de um malware anali-

sado pelo serviço Malwr. Como resultado, é possível ter uma visão geral das funcionalidades
do malware incluindo análise estática, análise comportamental, análise de rede e arquivos
obtidos (dropped files). O relatório é agrupado em categorias, onde é possível visualizar
mais detalhes do arquivo analisado.
Por fim, os relatórios fornecidos por algumas ferramentas são bastante descritivos e per-
mitem uma visão razoável quanto às ações de um arquivo executável. As diferentes técnicas
de análise de arquivos binários recém-descritas possuem o mesmo objetivo: lidar com a
árdua tarefa de identificar as funcionalidades de um arquivo executável. A utilização das
distintas metodologias, em particular, pode ser combinada e permitir que o CSIRT obtenha
mais informações relativas ao incidente a ser investigado.
145
Análise dinâmica de arquivos maliciosos
Utilize o malware fornecido (bot.exe) e submeta para um dos serviços recém-descritos
(Anubis ou Malwr). Responda as seguintes perguntas:
a. Quais são as principais funcionalidades do arquivo bot.exe?
b. O sandbox mapeou alguma atividade de rede desempenhada pelo malware?
c. Quais softwares são afetados pelo malware?
Considerações sobre o uso de ferramentas online

Sandboxes e antivírus online podem fornecer uma primeira impressão de maneira fácil de l
arquivos desconhecidos. Na maioria dos casos, a utilização desses serviços requerer poucas Falso positivo e falso
habilidades do usuário. Afinal, tais serviços têm foco na usabilidade dos usuários e são espe- negativo são sempre
um risco para sistemas
cificados justamente para ocultar a complexidade dos sistemas de análise, muito embora de detecção. Alguns
existam sistemas mais complexos com alto nível de parametrização e customização. antivírus classificam
plugins lícitos de
Sabe-se que esses serviços são muito utilizados para uma análise rápida de arquivos; no segurança bancária
como malicioso. Por
entanto, devem-se compreender os riscos associados a esses serviços. Mesmo que um
outro lado, certos
arquivo não seja detectado como malicioso pelos sistemas de varredura (antivírus ou arquivos maliciosos não
sandboxes), isso não necessariamente significa que se trata de um arquivo não malicioso. caracterizados como
legítimos por ainda não
O contrário também é verdadeiro: caso o arquivo seja avaliado como malicioso por alguns
possuírem assinatura
softwares, isso não significa que se trata de um arquivo malicioso. nos sistemas de
segurança.
É essencial lembrar que boa parte dos serviços gratuitos online compartilham as informa-
ções com terceiros. Logo, instituições com informações críticas – segurança nacional, por
exemplo – devem reconsiderar o uso desses serviços. Afinal, alguns malwares são desen-
volvidos para alvos específicos e podem conter informações sensíveis de uma instituição
embutidos em si, tal como senhas, IPs e URLs.
Essas ferramentas de análise, além de compartilhar informações com terceiros (empresas

de segurança e fabricantes de antivírus), disponibilizam de forma pública os resultados.
Todos os usuários podem consultar as informações dos malwares analisados pelo sistema,
inclusive o próprio autor do malware. Nada impede que um atacante possa utilizar os sis-
temas de análise de arquivos online como uma fonte de informação.
146
Um atacante mais experiente pode desenvolver um malware específico – com único hash
criptográfico (md5) – destinado a uma instituição. Após um período, o próprio atacante pode
consultar em ferramentas online pelo hash criptográfico e, com isso, saber se o malware foi
identificado. Dessa forma, o atacante pode aperfeiçoar suas técnicas de evasão e aprimorar
suas táticas para conseguir o seu objetivo.
Analisadores de websites
De forma análoga aos serviços que analisam arquivos binários, é possível encontrar fer-
ramentas especializadas na análise de conteúdo web. Alguns serviços buscam auxiliar na
identificação de websites com conteúdos maliciosos, compreendendo:
11 Drive-by-download;
11 Arquivos flash maliciosos;
11 Javascript maliciosos;
11 Applets;
11 iframes ocultos;
11 Cross Site Scripting (XSS);
11 Redirecionamentos maliciosos;
11 Backdoors (e.g., C99, R57 e Webshells).
Tipicamente, os serviços de análise recebem como entrada uma URL para ser processada
pelo sistema. A partir desse momento, a ferramenta acessa a URL especificada utilizando
um ambiente controlado (sandbox), que podem ser configurados de diferentes formas
para avaliar um website suspeito. A configuração dos sistemas pode ser útil para identificar
conteúdos maliciosos destinados a um determinado alvo, como por exemplo: um navegador
particular (User-Agent), plug-ins com versões específicas (Java) ou ainda determinados Sis-
temas Operacionais.
Uma das ferramentas mais populares para análise de conteúdo é o Wepawet.

O https://wepawet.iseclab.org/ é um serviço online gratuito que busca analisar as ações desen-
cadeadas por uma página web quando acessada. Para isso, são utilizadas diferentes técnicas e
abordagens a fim de mapear possíveis ações maliciosas no Sistema Operacional que acessa um
site possivelmente comprometido.
Para cada URL submetida, o Wepawet, instancia um browser em um sistema virtualizado

e mapeia todas as modificações ocorridas no Sistema Operacional virtual. Através de uma
heurística, o sistema determina se o site é malicioso ou não. Dessa forma, diferentes tipos
de ataques podem ser determinados sem o comprometimento de um sistema de produção.
Como comentado, certos ataques são direcionados a um conjunto específico de clientes
que acessam o website. Para lidar com isso, o Wepawet permite inserir cabeçalhos (REFER) e
configurar um servidor proxy a ser utilizado na análise.
Além do Wepawet, existem outras ferramentas com funcionamento similar para analisar o
conteúdo de website maliciosos:
11 http://urlquery.net/report.php
11 http://sitecheck.sucuri.net/
147
A imagem ilustra o resultado de uma análise disponibilizada pela ferramenta urlQuery.
Figura 8.8
Na parte superior, são exibidos alguns detalhes da análise, tal como: informações do Análise usando
domínio da URL; a configuração utilizada pelo browser que acessou a URL analisada; e a ferramenta
assinatura maliciosa detectada por um sistema IDS. Já na parte inferior é possível visualizar urlQuery
demonstrando
as transações HTTP desencadeadas pelo website. Como destacado, o site “asabrasil.org.br” um ataque do
faz uma requisição de download para um arquivo malicioso hospedado em “nemohildiin.ru”. tipo “driven-by-
Isso pode identificar um ataque denominado driven-by-download comprovante que o download”.
website original possivelmente foi comprometido.
Assim como outros serviços baseados em sandboxes, as soluções não fornecem detecção
100% do conteúdo malicioso. Algumas técnicas podem ser utilizadas para identificar um
sistema virtualizado (sandbox), fazendo com que a análise de arquivos apresente resultados
imprecisos. Além do mais, certas configurações do sandbox podem ser incompatibilidades
com o esperado pelos atacantes deixando o conteúdo malicioso dormente.
148
Outros serviços online
Além dos serviços de análise de malware e de website, existe um conjunto de serviços online
e gratuitos que podem ser utilizados para obter mais informações sobre um incidente inves-
tigado. Nesse contexto, podem ser utilizados os mais diversos serviços, tal como listas de
bloqueio e repositórios de websites desfigurados.
Listas de bloqueio
São listas que descrevem recursos de rede – IPs, blocos de endereçamento, URLs e domínios
– relacionados com atividade maliciosa. Boa parte dessas informações é provida por insti-
tuições que constantemente fazem análise de malwares, spams e phishings. Dessa forma, é
possível ter uma lista com informações atualizadas dos principais recursos comprometidos
identificados pelas diversas instituições.
Essas listas de bloqueio – usualmente referenciadas black list – são segmentadas em dife-
rentes categorias:
11 Máquinas originadoras de spams;
11 Máquinas infectadas por um determinado malware;
11 Websites com conteúdo malicioso;
11 Website utilizados em fraudes.
As listas de bloqueio, em sua maioria, são independentes. Logo, é perfeitamente factível

encontrar um recurso de rede replicado nas mais diversas categorias. Por exemplo, um IP
que foi detectado como originador de spam provavelmente estará presente em uma lista de
“máquinas originadoras de spams”. Da mesma forma, se o mesmo IP estiver comprometido
e está atuando como um controlador de botnet, o mesmo pode ser mapeado também para
uma lista de “máquinas infectadas”.
Logo, utilizar essas fontes de informações de listas de bloqueio podem revelar valiosas infor-
mações sobre um IP ou domínio em questão. Nem sempre essas informações das diferentes
listas podem ser compostas de forma unificada. Quando se deseja consultar informações
relativas a certos recursos comprometidos, é necessário buscar nas mais diversas listas, o
que pode ser trabalhoso. Felizmente, existem alguns serviços online onde é possível buscar
por informações de bloqueio em múltiplas listas ao mesmo tempo. Um desses serviços é o
projeto “Anti-Abuse”:
11 Anti-Abuse: http://www.anti-abuse.org/ Capítulo 8 - Ferramentas para análise de incidentes
O Anti-Abuse disponibiliza um website onde é possível automaticamente buscar uma infor-

mação em múltiplas listas de bloqueio. Atualmente o website indexa mais de 50 listas de
bloqueio. A busca em múltiplas listas revela rapidamente se um IP ou domínio foi identi-
ficado como originador de ações maliciosas. É importante notar que, mesmo que o IP ou
domínio não esteja listado em uma lista de bloqueio, não significa que está seguro. Do con-
trário, quando um IP é listado em múltiplas listas de bloqueio, podemos supor que existem
fortes indícios de um comprometimento. Algumas listas de bloqueio populares são:
11 The Spamhaus Block List: http://www.spamhaus.org/sbl/index.lasso
11 A spam blacklist made in Switzerland: http://dnsbl.abuse.ch
11 SpamCop: http://www.spamcop.net/
11 Google Safe Browsing: https://developers.google.com/safe-browsing/
149
11 Phish Tank: http://www.phishtank.com/
11 Yandex: http://help.yandex.com/mail/account/white-list-and-black-list.xml
11 Malware Patrol: http://www.malware.com.br/
11 SPAM database loookup: http://www.dnsbl.info/
É importante ressaltar que as listas de bloqueio podem ser mantidas por empresas comer-
ciais ou por grupos de voluntários. Cada uma tem suas particularidades, tais como: critérios
para ser listado; e maneiras de remover um endereço listado. Além de descreve os IPs e
nomes possivelmente comprometidos, alguns administradores utilizam block lists em dis-
positivos de redes (firewall, roteadores, servidores de e-mail) para sumariamente bloquear
acesso aos sistemas. Logo, IPs listados em block lists podem ter problemas para acessar
determinados IPs. A política de uso de listas é diferente para cada administrador de rede.
Por fim, deve-se evitar serem listados por uma lista de bloqueio para que os acessos de sua
organização não sejam limitados por outras instituições. E, quando for o caso, consulte os
procedimentos de remoção da própria lista em que um dos seus recursos foi listado.
Pesquisando por sites relacionados com fraudes
a. Acesse o site do Phishing Tank [1] e busque por phishings relacionados a bancos brasi-
leiros. Qual foi o último phishing relativo ao Banco do Brasil?
[1] http://www.phishtank.com/target_search.php
b. Acesse o website do Phishing Tank [2] e localize todos os phishings ativos relacionados ao
AS da RNP (AS 1916). Existe algum phishing válido e online? Qual é o alvo do phishing?
[2] http://www.phishtank.com/asn_search.php
Repositório de websites desfigurados

Zone-h é uma base de dados de websites desfigurados. O portal Zone-h permite que qual-
quer usuário, incluindo o próprio atacante, reporte URLs de páginas comprometidas. Assim
que uma URL entra no sistema, o site correspondente à URL é clonado pelos servidores do
Zone-h e verificado manualmente pela equipe do Zone-h. Dessa forma, toda URL submetida
é verificada em busca de falsos positivos.
O Zone-h disponibiliza uma base de dados com: a) website a serem verificados (on-hold) e,
b) websites com desfiguração confirmada (arquive). Segundo o próprio portal, o objetivo é
observar tendências e mapear características dos ataques, tal como aplicações e vulnerabili-
dades exploradas nos ataques.
Entre os principais utilizadores do portal estão grupos de cibercriminosos ou ativistas que utilizam
o Zone-h como um ranking. Dessa maneira, para cada desfiguração realizada, o próprio atacante
encarrega-se de reportar ao portal Zone-h. Como resultado, o Zone-h apresenta um ranking
dos principais reportadores (grupos de hackers) e o respectivo número de desfigurações.
150
Figura 8.9 Apenar de ser um portal bastante controverso e, até mesmo banido em alguns países,
Base de dados o Zone-h pode ser utilizado como mais uma fonte de informações sobre possíveis compro-
com websites que
foram ou estão metimentos. Por exemplo, é possível consultar por um website comprometido mesmo que
desfigurados. não esteja mais online. A figura ilustra detalhes dos últimos websites comprometidos
apresentando o usuário que notificou (notifier), URL do website, Sistema Operacional do
servidor que hospeda a página alterada (OS) e uma cópia do website alterado (mirror).
Identificar servidores que já foram comprometidos utilizando a base de dados
do zone-h
Acesse a base de dados do zone-h em busca de sites comprometidos:
Acesse: http://www.zone-h.org/
Menu: “Attack Archive”
Verifique a existência de websites desfigurados relacionados com o Brasil, ou seja, domínios

terminados com “.br”. Identifique o último site desfigurado (.br) inserido na base do zone-h.
151
Demais ferramentas para analisar artefatos
Mesmo não sendo o escopo deste capítulo, é interessante ter uma visão das ferramentas
que podem ser úteis em casos que exigem uma análise mais aprofundada de artefatos. A
tabela a seguir sumariza algumas ferramentas que podem ser utilizadas para analisar os
mais diversos arquivos suspeitos e assim pode ser utilizada como ponto de partida para
iniciar a investigação de incidentes mais complexos. Lembre-se de que a Escola Superior de
Redes (ESR) possui um curso próprio de análise de malware.
Funcionalidade Ferramentas de análise
Firefox Firebug, Rhino debugger, JS-Beautify, SpiderMonkey, V8, Windows

Decodificar JavaScript
Script Decoder e Jsunpack
Analisar arquivos Flash SWFTtools, flasm, flare e RABCDAsm
Upx, packerid, xorsearch, xortool, ClamAV, ssdeep, md5deep, pescanner,

Analisar executáveis suspeitos
pev, pyew e bytehist
Analisar documentos maliciosos Pdftk, Origami Framework, PDF X-RAY, Peedpdf, Jsunpack e OfficeMalScanner
Analisadores de memória Volatility, bulk_extractor, AESKeyFinder, RSAKEyFinder
11 Malware Analyst’s Cookbook: Michael Ligh, Steven Adair;
11 Provos, Niels, and Thorsten Holz. Virtual honeypots: from botnet tracking to intrusion
detection. Pearson Education, 2007;
11 Free Automated Malware Analysis Services

http://zeltser.com/reverse-malware/automated-malware-analysis.html
152
9
Dinâmica de tratamento
de incidentes
Realizar a dinâmica de tratamento de incidentes; Levantar questões relacionadas
objetivos
ao processo de tratamento de incidentes; Vivenciar as etapas necessárias para o

tratamento de incidentes.
conceitos
Tratamento de incidentes; O papel de um CSIRT dentro de uma organização.
Introdução
Este capítulo consiste em uma dinâmica de tratamento de segurança que será realizada
em equipes. O objetivo dessa dinâmica é exercitar os conceitos e técnicas apresentados no
curso em um evento de segurança simulado.
Para isso, é importante considerar: q

11 A atividade será realizada em equipes independentes;
11 A equipe representará o CSIRT da instituição financeira;
11 A equipe deve eleger um representante para comunicar as ações do CSIRT;
11 Os grupos podem demandar ações para investigar o incidente;
11 Todas as informações devem ser solicitadas diretamente ao instrutor ou monitor

através do representante do time;
11 Evite olhar o material – trate essa dinâmica como um incidente em andamento.
Contextualização
q
Nesta atividade, o seu grupo representará o time de resposta a incidentes de uma

instituição financeira denominada CARTEX. A instituição que o seu CSIRT representa é
uma empresa de grande porte no setor de autorização de transações bancárias usando
cartões de crédito dos mais diversos consumidores.
O faturamento anual da empresa supera R$ 1 bilhão, o que posiciona a empresa como

uma das líderes do mercado do pagamento eletrônico, e possui as suas ações negociadas
tanto na Bolsa de Valores de São Paulo (BM&FBOVESPA) quanto na Bolsa de Valores de
Nova York (NYSE).
153
Como se sabe, a área financeira é muito visada por fraudadores e atacantes que buscam
aplicar golpes com motivações financeiras. No último ano, entretanto, a sua empresa
foi comprometida, o que causou enormes prejuízos para empresa. Além do desgaste da
imagem institucional, as ações da empresa sofreram grande desvalorização quando o inci-
dente tornou-se público.
Figura 9.1
Repercussão
do ataque à
instituição.
Como resultado, todo o departamento de TI foi restruturado. Em especial, a equipe de

resposta a incidente foi reorganizada e posicionada em uma posição estratégica no organo-
grama da empresa.
154
SIFRA
O time de resposta a incidentes de seguranças da empresa SIFRA já está estabelecido q
e é denominado SIFRA. Nesta dinâmica, o seu grupo atuará no contexto do CSIRT SIFRA.
Para isso, é importante descrever algumas características do próprio grupo estabelecido.
Como comentado, o SIFRA, possui uma estratégica na organização da estrutura da empresa,

como pode ser observado na figura a seguir. O atual CIO da empresa dá total apoio ao SIFRA
e qualquer incidente de segurança é reportado na reunião do conselho executivo, na pre-
sença dos demais diretores.
Presidência
Coordenação
SIFRA
de projetos
Figura 9.2
Estrutura
organizacional da
empresa CARTEX.
Missão do SIFRA
“Prover resposta rápida e eficaz para qualquer problema de segurança que envolva a
empresa, limitando os eventuais danos a níveis aceitáveis e reportando qualquer fraude
para a diretoria executiva dentro de um período máximo de 12 (doze) horas.”
Abrangência operacional
“Redes, endereços IP e domínios atendidos pela CARTEX.”
A sua equipe é responsável por coordenar as atividades de segurança entre os diferentes

departamentos das instituições, incluindo filiais localizadas em outros estados. Todas as
informações de segurança são centralizadas no SIFRA, que é responsável pela comunicação
com os demais departamentos. Como resultado, o SIFRA encarrega-se de produzir um
resumo executivo de todas as atividades e apresentá-lo semanalmente à diretoria executiva. Capítulo 9 - Identificação de contatos
155
Tratamento de incidentes de segurança
O exercício de tratamento de incidentes de segurança começa agora. A partir desse momento,
cada grupo tomará suas decisões de forma independente, sempre seguindo as instruções do
professor/monitor. Com a evolução das investigações, a equipe receberá novas evidências que
ajudaram o SIFRA a avaliar melhor o incidente de segurança como um todo.
Fatos iniciais: q
11 Hoje é 10 fevereiro de 2014, 9h da manhã;
11 Na caixa de e-mails do CSIRT, são encontradas diversas mensagens, entre elas:
From: csirt@universidade.exemplo.com.br
To: csirt@sifra.cartex
Subject: Máquina enviando spam - 10.10.10.20
Date: Fri, 7 Feb 2014 18:54:10 -0200 (BRST)
Senhores,
Recebemos inúmeros e-mails fraudulentos oriundos da máquina

10.10.10.20. Abaixo a mensagem que foi recebida.
Atenciosamente,
--
CSIRT
<csirt@universidade.exemplo.com.br>
----- Forwarded message from “Webmail.universidade.exemplo.com.

br” <carlao@sifra.cartex> -----
Delivered-To: aluno@universidade.exemplo.com.br
<....>
Além dessa mensagem, são encontradas outras duas mensagens relativas ao mesmo
assunto. Neste momento o seu grupo receberá as três mensagens impressas:
11 Prova A1;
11 Prova A2;
11 Prova A3.
A partir desse momento, a atividade continuará com base nas suas respostas aos ques-
tionamentos anteriores. Cada ação terá uma reação, e possivelmente novas informações
são disponibilizadas a equipe pelo instrutor/monitor.
156
Razer Anthom Nizer Rojas Montaño
é Doutorando em Informática (ênfase
em Inteligência Artificial) pela UFPR,
Mestre e Bacharel em Informática pela
UFPR. Atualmente é professor da UFPR
ministrando disciplinas de desenvolvi-
mento em Java Web e de Aplicações
Corporativas. Possui certificação SCJP, COBIT, ITIL. Acumula
mais de 15 anos de experiência em docência e mais de
20 anos de experiência no mercado de desenvolvimento,
análise e arquitetura de aplicações.
Razer Anthom Nizer Rojas Montaño Sobre a RNP – qualificada como uma
é Doutorando em Informática (ênfase Organização Social (OS), a Rede Nacional
em Inteligência Artificial) pela UFPR,
de Ensino e Pesquisa (RNP) é vinculada
Mestre e Bacharel em Informática pela
UFPR. Atualmente é professor da UFPR ao Ministério da Ciência, Tecnologia,
ministrando disciplinas de desenvolvi- Inovação e Comunicações (MCTIC) e
mento em Java Web e de Aplicações mantida por esse, em conjunto com
Corporativas. Possui certificação SCJP, COBIT, ITIL. Acumula
os ministérios da Educação (MEC),
mais de 15 anos de experiência em docência e mais de
20 anos de experiência no mercado de desenvolvimento,
Cidadania, Saúde (MS) e Defesa
análise e arquitetura de aplicações. (MD), que participam do Programa
Interministerial RNP (PI-RNP). Pioneira
Java
no acesso à internet no Brasil, a RNP
planeja, opera e mantém a rede Ipê,
O curso aborda o uso de frameworks e tecnologias para de- infraestrutura óptica nacional acadêmica
LIVRO DE APOIO AO CURSO

senvolvimento de aplicações corporativas em Java. Este tipo
Java – Frameworks e Aplicações Corporativas

de alto desempenho. Com Pontos de
de aplicação exige um grau de confiabilidade e performan- Presença em 27 unidades da federação,
ce mais elevado, fazendo uso de recursos específicos do

Java Enterprise Edition - Java EE, tais como JSF (Java Server
Faces), AJAX, Primefaces e Hibernate.
Frameworks a rede conecta 1.174 campi e unidades
nas capitais e no interior. São mais de
4 milhões de usuários, usufruindo de
uma infraestrutura de redes avançadas
O livro inicia com uma visão geral da Arquitetura do Java
EE e características dos servidores de aplicação capazes de
suportar as tecnologias/aplicações corporativas, para em
e Aplicações para comunicação, computação e
experimentação, que contribui para a
integração dos sistemas de Ciência e
Corporativas
Tecnologia, Educação Superior, Saúde,
seguida se aprofundar no JSF e Hibernate.
Cultura e Defesa.
Saiba mais em https://rnp.br.
Razer Anthom
ISBN 978-85-63630-56-8
9 788563 630568

Tratamento de Incidentes de Segurança

Uploaded by

Document Information

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Tratamento de Incidentes de Segurança

Uploaded by

Copyright:

A RNP – Rede Nacional de Ensino

e Pesquisa – é qualificada como

LIVRO DE APOIO AO CURSO

Tratamento de Incidentes de Segurança

SEG4.capa-NPE-v2.0.3.indd 1 04/12/2017 11:22:14

Diretor de Serviços e Soluções

Escola Superior de Redes

Coordenação Acadêmica de Segurança e Governança de TI

Equipe ESR (em ordem alfabética)

Capa, projeto visual e diagramação

Dados Internacionais de Catalogação na Publicação (CIP)

C416t Ceron, M. João

1. Segurança de computador. 2. Internet – medidas de segurança. 3. Centro de estudos,

Escola Superior de Redes

Convenções utilizadas neste livro x

1. Definições e fundamentos de CSIRTs

Identificando CSIRTs pelo mundo 3

Exercício de fixação 1 Conhecendo CSIRTs 4

Abrangência operacional e missão do CSIRT 5

Aspectos operacionais de um CSIRT 10

Passos para criação de um CSIRT 12

Fóruns de CSIRTS 13

Treinamento e desenvolvimento da equipe 20

Terceirização de serviços 20

Procedimentos de ingresso e desligamento 23

Fatores de sucesso 29

Ameaças associadas a segurança de sistemas 36

Ataques de força bruta 39

Varredura em redes (Scan) 40

Negação de serviço (DoS e DDoS) 40

4. Processo de tratamento de incidentes

Metodologia para resposta a incidentes 50

Recursos adicionais 60

Roteiro para avaliação inicial de um incidente 61

Aspectos operacionais da resposta a incidente 65

Exercício de fixação 1 Análise de cabeçalho de e-mail 70

Exercício de fixação 2 Utilizando o protocolo SMTP 71

Exercício de fixação 3 Padronização do formato data e hora 75

Exercício de fixação 4 Classificação e triagem de incidentes 78

Boas práticas para a notificação de incidentes de segurança 85

Traduzir domínios de redes para endereços IP (domínio > IP) 88

Traduzir o endereço IP para domínios de redes (IP > domínio) 88

Exercício de fixação 1 94

Exercício de fixação 2 96

Exercício de fixação 3 utilizando a ferramenta DIG 100

Exercício de fixação 4 Sistemas Autônomos 102

Aspectos de segurança 125

Recomendações para sistemas de logs 126

8. Ferramentas para análise de incidentes

Preocupações de privacidade 130

Virtual Private Network (VPN) 134

Uso da rede Tor na investigação de incidentes 136

Assinaturas de malwares 138

Exercício de fixação 1 Virustotal 141

Exercício de fixação 2 Análise dinâmica de arquivos maliciosos 146

Considerações sobre o uso de ferramentas online 146

Outros serviços online 149

Listas de bloqueio 149

Exercício de fixação 3 Pesquisando por sites relacionados com fraudes 150

Repositório de websites desfigurados 150

Exercício de fixação 4 Identificar servidores que já foram comprometidos utilizando

Demais ferramentas para analisar artefatos 152

9. Dinâmica de tratamento de incidentes

Tratamento de incidentes de segurança 156

A ESR também participa de diversos projetos de interesse público, como a elaboração e

A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema

As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo