Beruflich Dokumente
Kultur Dokumente
Tratamento de
para profissionais ligados à área de segurança da infor-
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
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
Edição
Lincoln da Mata
Revisão técnica
Jácomo Picolini
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
Escola Superior de Redes
Rua Lauro Müller, 116 – sala 1103
22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
info@esr.rnp.br
ISBN 978-85-63630-46-9
CDD 005.8
Sumário
A metodologia da ESR ix
Sobre o curso x
A quem se destina x
Permissões de uso xi
Sobre o autor xii
Contextualização histórica 2
Definição de CSIRT 3
Serviços de CSIRTs 6
Tipos 10
Modelos 10
Autonomia 11
Definição de incidente 11
iii
2. Gerenciamento do CSIRT
Introdução 15
Código de conduta 15
Equipe 17
Contratação 21
Requisitos estruturais 24
Comunicação 27
3. Riscos e ameaças
Introdução 33
Análise de risco 33
Comprometimento de sistemas 37
Phishing 38
Desfiguração 39
Malwares 42
Outros riscos 45
APT 46
Preparação 51
Contenção 56
Erradicação 58
Recuperação 58
Avaliação 60
Procedimentos 62
iv
5. Aspectos operacionais da resposta a incidentes
Introdução 65
Identificação 66
Sincronismo de tempo 73
Priorização 76
Categorização 77
Atribuição 79
6. Identificação de contatos
Introdução 87
Identificação de contatos 88
Recursos adicionais 97
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
Proxies 132
Web-Proxies 133
Rede Tor 135
Mecanismos de busca 137
Analisadores de malwares 137
Ferramentas multiantivírus 139
Análise comportamental 141
Analisadores de websites 147
Contextualização 153
SIFRA 155
vi
Escola Superior de Redes
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 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.
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.
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.
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.
x
1
Definições e fundamentos
de CSIRTs
objetivos
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.
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.
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.
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-
Tratamento de Incidentes de Segurança
11 1997:
11 1999:
2
11 2004:
11 2010:
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
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.
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;
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.
Tratamento de Incidentes de Segurança
CSIRT governamental:
1.
2.
4
CSIRT de instituição financeira:
1.
2.
CSIRT comercial:
1.
2.
CSIRT acadêmico:
1.
2.
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:
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.”
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.
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 Avaliação de segurança;
11 Detecção de intrusão;
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.
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.
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:
Capítulo 1 - Definições e fundamentos
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;
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 Educação ou treinamento;
11 Auditoria de sistemas.
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.
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.
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;
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;
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.
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;
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;
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 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.
11
Exemplos comuns de incidentes incluem: q
11 A desfiguração do portal web de uma instituição;
11 O envio de spam;
11 O comprometimento da rede;
11 A disponibilidade de um website.
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.”;
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.
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:
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:
13
14
Tratamento de Incidentes de Segurança
2
Gerenciamento do CSIRT
objetivos
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.
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.
informações.
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.
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.
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.
“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.
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 Todo incidente será notificado a um CSIRT de coordenação, como por exemplo, CERT.br?
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
Capítulo 2 - Gerenciamento do CSIRT
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.
11 Recursos humanos;
11 Serviços prestados;
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.
11 Administradores de sistemas;
11 Engenheiros de redes;
Tratamento de Incidentes de Segurança
11 Especialistas em suporte;
11 Gerente;
11 Conselho legal.
18
Mesmo assim, existem alguns conhecimentos que são essenciais para a equipe que lida q
com incidentes de segurança:
11 Sistemas Operacionais;
11 Criptografia;
11 Aplicações de rede;
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.
11 Comunicação não verbal: leitura, escrita e linguagem corporal (para palestras e eventos);
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.
Terceirização de serviços
Tratamento de Incidentes de 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.
11 Dependência tecnológica;
11 Questões legais;
11 Questões operacionais;
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
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.
Capítulo 2 - Gerenciamento do CSIRT
11 Análise curricular;
21
11 Entrevista pessoal; q
11 Questões contratuais;
11 Questões éticas.
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.
11 Plano de carreira;
11 Carga horária;
11 Possibilidade de viagens.
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.
11 Ter acesso a livros e artigos relevantes para a área de tratamento de incidentes, per-
Tratamento de Incidentes de Segurança
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;
22
Para pensar
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.
22 Remoto (VPN);
11 E-mail institucional.
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:
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.
De fato, todos os CSIRTs possuem requisitos básicos para operar com segurança. Um dos
Tratamento de Incidentes de Segurança
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.
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.
q
Capítulo 2 - Gerenciamento do CSIRT
Mesmo assim, existem pontos comuns que devem ser endereçados para o efetivo
desenvolvimento de procedimentos operacionais:
11 Classificação do incidente;
25
11 Etapas prioritárias; q
11 Ações a serem realizadas;
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.
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).
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
resposta a incidentes.
11 Ausência de jargões;
11 Informações sintetizadas.
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”.
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.
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.
22 Comunicados impressos;
22 Entrevistas gravadas;
22 Entrevistas ao vivo.
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.
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.
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
Capítulo 2 - Gerenciamento do CSIRT
Fatores de sucesso descrevem aspectos que devem ser observados para que um CSIRT
tenha os seus objetivos propostos alcançados.
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:
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.
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.
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.
Para pensar
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
Leitura recomendada:
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
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.
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
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.
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.
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
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.
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.
11 A quantidade de horas produtivas, no total, que cada uma dessas pessoas impedidas
de trabalhar desperdiçou;
35
11 Vulnerabilidade: fragilidade inerente de um sistema ou ambiente operacional, que q
pode ser explorado para causar dano a um sistema;
Ameaças de segurança
11 Demonstração de poder;
11 Prestígio;
11 Motivações financeiras;
11 Motivações ideológicas;
Tratamento de Incidentes de Segurança
11 Vantagem competitiva;
11 Vingança;
11 Extorsão.
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.
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.
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
Capítulo 3 - Riscos e ameaças
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
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.
11 Comércio eletrônico;
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.
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.
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;
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.
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
Capítulo 3 - Riscos e ameaças
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:
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.
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.
Uma negação de serviços pode ser inicializada por uma única máquina, mas tipicamente
Tratamento de Incidentes de Segurança
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.
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.
Trojans
É um tipo de software que aparenta ser legítimo, mas na realidade é um malware projetado
para comprometer um Sistema Operacional.
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.
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;
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.
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
Capítulo 3 - Riscos e ameaças
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.
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);
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
Tratamento de Incidentes de Segurança
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 HTTP;
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 botnets são responsáveis pelas mais diversas atividades maliciosas, tais como: q
11 Envio de spam;
11 Varredura ou propagação;
11 Distribuição de malwares;
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.
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.
(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:
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.
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.
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:
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
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
Capítulo 3 - Riscos e ameaças
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.
Leitura recomendada:
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
Tratamento de Incidentes de Segurança
48
4
Processo de tratamento
de incidentes
objetivos
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.
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 Eficiência: utilizar uma metodologia bem definida e assertiva para solucionar incidentes
impede que ações desnecessárias sejam implementadas;
3. contenção 4. erradicação
Figura 4.1
resposta a Metodologia
2. detecção incidentes 5. recuperação
Tratamento de Incidentes de Segurança
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.
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.
11 Configuração segura.
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.
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.
Em especial, quando atuando com múltiplos incidentes de segurança, se faz necessário usar
softwares que permitam gerenciar os incidentes sendo tratados.
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-
Tratamento de Incidentes de Segurança
ciados de forma centralizada. Boa parte das soluções de trouble ticket caracteriza-se por
implementar recursos como:
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;
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
Capítulo 4 - Processo de tratamento de incidentes
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.
53
11 Mapeamento de dados: identificar que tipo de informação e processos podem ter q
sido afetados;
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 Filtros de Pacotes: ferramenta para filtrar tráfego de rede que permite bloquear ou
permitir um determinado tráfego;
11 Fontes externas: fontes públicas podem fornecer dados valiosos para a identificação
de incidentes (redes sociais, fóruns ou blogs).
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.
Tratamento de Incidentes de Segurança
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 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
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;
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.
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
Tratamento de Incidentes de Segurança
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 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
Capítulo 4 - Processo de tratamento de incidentes
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.
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.
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:
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.
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.
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.
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 Identificar características de incidentes que podem ser utilizadas para treinar novos
membros da equipe;
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.
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.
Tratamento de Incidentes de Segurança
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.
22 Página falsa.
61
6. O incidente continua?
[ ] 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.
Tratamento de Incidentes de Segurança
Na sequência são apresentados diferentes roteiros que podem servir como base para um
CSIRT desenvolver os seus próprios procedimentos.
62
2. Notificar as autoridades responsáveis
22 Notificar o CSIRT;
3. Identificar o problema
22 Assegurar-se de que o malware que comprometeu o sistema não será incluído no backup;
Página falsa
Capítulo 4 - Processo de tratamento de incidentes
1. Desativar a página falsa
63
3. Notificar as partes envolvidas
Leitura recomendada:
64
5
Aspectos operacionais da resposta
a incidentes
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.
É 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.
65
incidente
identificação
triagem
Figura 5.1
Etapas operacionais
iniciais na análise
de um incidente de
categorizar priorizar atribuir segurança.
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:
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
Tratamento de Incidentes de Segurança
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:
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).
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.
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;
67
11 Erros de configuração; q
11 Sincronia de tempo.
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
Tratamento de Incidentes de Segurança
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 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
Exercício de fixação 1 e
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
b. Em que horário a mensagem foi escrita, ou seja, foi enviada para o servidor?
Tratamento de Incidentes de Segurança
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.
Exercício de fixação 2 e
Utilizando o protocolo SMTP
71
b. Utilize o comando telnet para acessar o servidor SMTP
telnet servidor 25
data
quit
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?
Tratamento de Incidentes 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.
11 http://www.rnp.br/ntp/
11 http://ntp.br/
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:
Onde:
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
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;
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-
Tratamento de Incidentes de Segurança
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.
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.
Exercício de fixação 3 e
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.
Aug 31 19:37:53
(fuso horário Venezuela)
Triagem
csirt@instituicão
security@instituicao triagem@instituicao
abuse@instituicao
A etapa de triagem implicitamente envolve uma avaliação inicial dos incidentes. Dessa
11 Categorizar;
11 Priorizar;
11 Atribuir.
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.
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.
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.
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.
Boa parte dos CSIRTs implementa uma nomenclatura própria de modo a classificar a q
natureza dos incidentes de segurança, como:
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
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.
Exercício de fixação 4 e
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:
Tratamento de Incidentes de Segurança
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:
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.
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.
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
Tratamento de Incidentes de Segurança
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:
80
11 Processo de resolução e recuperação dos dispositivos mal executada;
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 Descrição do ataque;
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.
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 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.
11 Vendedores (fabricantes);
11 Especialistas;
11 Outros CSIRT;
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:
Tratamento de 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.
Essas mesmas ações, aplicadas a uma notificação externa, poderiam expor excessi-
vamente os sistemas internos de uma instituição.
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.
Tratamento de Incidentes de Segurança
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 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 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).
Leitura recomendada:
85
86
Tratamento de Incidentes de Segurança
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.
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:
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:
Non-authoritative answer:
Tratamento de Incidentes de Segurança
Name: www.rnp.br
Address: 200.130.35.4
Non-authoritative answer:
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 Africa Regional Internet Registry (AFRINIC): África e algumas regiões do Oceano Índico
Capítulo 6 - Identificação de contatos
– 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 Contato técnico;
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.
90
Em outras regiões, podemos citar:
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.
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 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
status DNS: 07/11/2013 AA
ú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
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:
Além das informações de contato, os dados disponibilizados pelo WHOIS permitem que sejam
realizadas certas análises.
11 Domínio foi criado ou atualizado recentemente. A maioria dos domínios não é atuali-
zada de forma requente;
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);
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.
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.
Exercício de fixação 1 e
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
Tratamento de Incidentes de Segurança
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
resposta a incidentes.
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).
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
status DNS: 07/11/2013 AA
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
status DNS: 07/11/2013 AA
último AA: 07/11/2013
Capítulo 6 - Identificação de contatos
criado: 15/02/2000
alterado: 07/03/2013
Exercício de fixação 2 e
Consulte a base de dados WHOIS usando sua ferramenta de preferência (sistema ou ferra-
menta online) e complete a tabela a seguir:
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.
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:
Capítulo 6 - Identificação de contatos
traceroute
traceroute <endereço>
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.
$ 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-
Tratamento de Incidentes de Segurança
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;
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 MX (servidores de e-mails);
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.
$ 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
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”.
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
Capítulo 6 - Identificação de contatos
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:
Logo, o contato de e-mail identificado pode ser mais uma forma de contatar os responsáveis
por um determinado endereço suspeito.
Exercício de fixação 3 e
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.
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.
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 Prefixo BGP;
$ host www.rnp.br
Como resultado, é possível observar que o IP 200.130.35.4 pertence ao AS 1916 e faz parte
Capítulo 6 - Identificação de contatos
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).
Exercício de fixação 4 e
Sistemas Autônomos
Com base nas informações disponibilizadas pelo site [1], responda as seguintes questões.
[1] http://bgp.he.net/
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 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.
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.).
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
Leitura recomendada:
105
Tratamento de Incidentes de Segurança
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;
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.
Capítulo 7 - Identificação de contatos
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.
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;
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:
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 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;
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.
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
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.
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-
Tratamento de Incidentes de Segurança
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;
Severidade
warning mensagens de aviso
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.
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.
Essa transmissão dos eventos de logs para um servidor pode ser realizada de diferentes q
maneiras, podendo ser:
centralizada para
offline armazenamento
de logs.
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-
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.
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;
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.
Capítulo 7 - Identificação de contatos
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
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.
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
Gerenciamento de logs
Uma instituição deve implementar certas políticas para gerenciar os registros de eventos q
dos diferentes sistemas monitorados.
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
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:
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.
Tratamento de Incidentes de Segurança
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.
116
Afinal, as diferentes informações encontradas nos sistemas de logs podem ser utilizadas
para compor indícios de comprometimento de sistemas.
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;
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.
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:
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.
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.
Tratamento de Incidentes de Segurança
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.
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.
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.
Capítulo 7 - Identificação de contatos
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.
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 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.
O comando grep corresponde a uma ferramenta bastante robusta para localizar padrões e
expressões regulares em arquivos de texto.
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.
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.
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.
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:
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 '" ['
Capítulo 7 - Identificação de contatos
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.
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
Tratamento de Incidentes de Segurança
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.
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.
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.
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;
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
Tratamento de Incidentes de Segurança
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:
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;
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.
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 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;
ú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
Leitura recomendada:
11 Logging and Log Management: The Authoritative Guide to Understanding the Concepts
Surrounding Logging and Log Management – Anton A. Chuvakin;
127
Tratamento de Incidentes de Segurança
128
8
Ferramentas para análise de
incidentes
Discutir cuidados necessários para a efetiva investigação de incidentes de segurança;
objetivos
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 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.
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.
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.
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
Tratamento de Incidentes de Segurança
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.
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:
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/
Tais serviços e técnicas de identificação são úteis para conscientização de usuários sobre q
a privacidade.
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
Tratamento de Incidentes de Segurança
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.
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;
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’.
133
11 Anonymouse: http://anonymouse.org/
11 Cloack: https://incloak.com/
11 Goprive: http://goprivate.eu/
Host: mail82.anonymouse.org
Connection: keep-alive
Host: notsohide.com
Connection: keep-alive
VIA: 200.X.X.X
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.
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 Privacy.io: https://privacy.io/
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
Capítulo 8 - Ferramentas para análise de incidentes
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/
usewithtor [aplicação]
Ou ainda:
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.
Tratamento de Incidentes de Segurança
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 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,
Capítulo 8 - Ferramentas para análise de incidentes
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.
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:
Por questões didáticas, vamos usar um arquivo malicioso específico nas diferentes análises
que serão apresentadas:
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.
$ clamscan /tmp/bot.exe
Scanned directories: 0
Scanned files: 1
Infected files: 1
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.
11 VirusTotal: https://www.virustotal.com/
11 Virscan: http://www.virscan.org/
11 Metascan: https://www.metascan-online.com/
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;
Cada arquivo submetido é analisado por todos os sistemas antivírus disponibilizado pelo
VirusTotal.
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.
Exercício de fixação 1 e
Virustotal
Utilize o malware fornecido (bot.exe) e submeta para o VirusTotal. Responsa as questões
a seguir:
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.
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.
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.
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.
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
Capítulo 8 - Ferramentas para análise de incidentes
11 ThreatTrack: http://www.threattracksecurity.com/resources/sandbox-malware-analysis.aspx
11 ViCheck: https://www.vicheck.ca/
11 Xandora: http://www.xandora.net/xangui/
11 Processos criados;
143
11 Conexões de rede instanciadas;
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.
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.
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.
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
Exercício de fixação 2 e
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:
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.
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 Javascript maliciosos;
11 Applets;
11 iframes ocultos;
11 Redirecionamentos maliciosos;
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.
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
Tratamento de Incidentes de Segurança
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”.
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:
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 SpamCop: http://www.spamcop.net/
149
11 Phish Tank: http://www.phishtank.com/
11 Yandex: http://help.yandex.com/mail/account/white-list-and-black-list.xml
É 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.
Exercício de fixação 3 e
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
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).
Exercício de fixação 4 e
Capítulo 8 - Ferramentas para análise de incidentes
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/
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.
Analisar documentos maliciosos Pdftk, Origami Framework, PDF X-RAY, Peedpdf, Jsunpack e OfficeMalScanner
Leitura recomendada:
11 Provos, Niels, and Thorsten Holz. Virtual honeypots: from botnet tracking to intrusion
detection. Pearson Education, 2007;
152
9
Dinâmica de tratamento
de incidentes
Realizar a dinâmica de tratamento de incidentes; Levantar questões relacionadas
objetivos
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.
Contextualização
q
Capítulo 9 - Identificação de contatos
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.
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.
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
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ã;
From: csirt@universidade.exemplo.com.br
To: csirt@sifra.cartex
Senhores,
Atenciosamente,
--
CSIRT
<csirt@universidade.exemplo.com.br>
Delivered-To: aluno@universidade.exemplo.com.br
<....>
Tratamento de Incidentes de Segurança
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
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