Lendo as folhas de chá:

Uma análise comparativa da inteligência contra ameaças

Vector Guo Li, Universidade da Califórnia, San Diego; MatthewDunn, Universidade do Nordeste;
Paul Pearce, Georgia Tech; DamonMcCoy, Universidade de Nova York; Geoffrey M. Voelker e Stefan
Savage, Universidade da Califórnia, San Diego; Kirill Levchenko, Universidade de Illinois
Urbana-Champaign
https://www.usenix.org/conference/usenixsecurity19/presentation/li

Este artigo está incluído nos Anais do

28º Simpósio de Segurança USENIX.
14 a 16 de agosto de 2019 • Santa Clara, CA, EUA

978-1-939133-06-9

Acesso aberto aos Anais do 28º

Simpósio de Segurança USENIX
é patrocinado pela USENIX.
 Lendo as folhas de chá: uma análise comparativa da inteligência contra ameaças

Vector Guo Li 1, Matthew Dunn 2, Paul Pearce 4, Damon McCoy 3,

Geoffrey M. Voelker 1, Stefan Savage 1, Kirill Levchenko 5

1 Universidade da Califórnia, San Diego 2 Universidade do Nordeste 3 Universidade de Nova York

4 Instituto de Tecnologia da Geórgia 5 Universidade de Illinois Urbana-Champaign

Abstrato e usar esses dados para atualizar as defesas e práticas de segurança.

Na verdade, até que ponto um defensor é capaz de coletar e analisar
O termo “inteligência contra ameaças” rapidamente se tornou uma palavra-chave da
esses dados efetivamente define uma janela de vulnerabilidade de
moda na indústria de segurança de computadores. A premissa inteiramente razoável
fato - o tempo durante o qual uma organização é menos eficaz em
é que, ao compilar informações atualizadas sobre ameaças conhecidas (ou seja,
lidar com ataques devido à ignorância dos comportamentos atuais
endereços IP, nomes de domínio, hashes de arquivo, etc.), os destinatários dessas
do invasor.
informações podem ser capazes de defender melhor seus sistemas do futuro
Este problema abstrato deu origem a uma demanda concreta por fontes de dados
ataques. Portanto, hoje uma grande variedade de fontes públicas e comerciais
de ameaças contemporâneas que são frequentemente referidas coletivamente como inteligência
distribuem feeds de dados de inteligência de ameaças para apoiar esse propósito. No
de ameaças ( TI). De longe, a forma mais comum de tais dados são os chamados indicadores
entanto, nossa compreensão desses dados, sua caracterização e até que ponto eles
de compromisso: comportamentos simples observáveis que sinalizam que um host
podem apoiar de forma significativa seus usos pretendidos, ainda é bastante limitada.
ou rede pode estar comprometido. Isso inclui indicadores de rede, como endereços IP
Nesse artigo, abordamos essas lacunas definindo formalmente um conjunto de
(por exemplo, endereços conhecidos por iniciar ataques específicos ou sites de
métricas para caracterizar feeds de dados de inteligência de ameaças e usando essas
comando e controle de host, etc.) e hashes de arquivo (por exemplo, indicando um
medidas para caracterizar sistematicamente uma ampla gama de fontes públicas e
arquivo ou executável conhecido por estar associado a um determinado variedade de
comerciais. Além disso, fundamentamos nossas avaliações quantitativas usando
malware). A presença de tais indicadores é um sintoma que alerta uma organização
medições externas para investigar qualitativamente as questões de cobertura e
sobre um problema, e parte das defesas de uma organização pode razoavelmente
precisão. Infelizmente, nossos resultados de medição sugerem que há limitações e
incluir o monitoramento de seus ativos para tais indicadores para detectar e mitigar
desafios significativos no uso de dados de inteligência de ameaças existentes para
possíveis comprometimentos à medida que ocorrem.
seus objetivos pretendidos.

Embora cada organização colete naturalmente uma certa quantidade de

dados de inteligência de ameaças por conta própria (por exemplo, os ataques
1. Introdução que repelem, o spam de e-mail que filtram etc.), qualquer entidade tem uma
pegada limitada e poucas são instrumentadas para segregar cuidadosamente
A segurança do computador é uma disciplina inerentemente adversária
sinais nítidos de ataques da gama de ambigüidade encontrada na rede de
na qual cada “lado” procura explorar as suposições e limitações do outro.
produção normal e nos logs do sistema. Assim, agora é comumente aceito que
Os invasores contam com a exploração do conhecimento de
a aquisição de dados de inteligência de ameaças é uma atividade especializada
vulnerabilidades, erros de configuração ou lapsos operacionais para
em que empresas terceirizadas e / ou coleções de grupos públicos empregam
penetrar nos sistemas almejados, enquanto os defensores, por sua vez,
uma variedade de técnicas de monitoramento para agregar, filtrar e curar
buscam melhorar sua resistência a tais ataques, compreendendo melhor
informações de qualidade sobre as ameaças atuais. Na verdade, o valor
a natureza das ameaças contemporâneas e as impressões digitais
operacional prometido da inteligência de ameaças criou um mercado próspero
deixadas por nave do atacante. Invariavelmente, isso significa que os
(de vários bilhões de dólares) [ 43 ] Empresas de segurança estabelecidas com
invasores são levados a inovar e diversificar enquanto os defensores, em
raízes em software antivírus ou detecção de intrusão de rede agora oferecem
resposta, devem monitorar continuamente essas mudanças e atualizar
inteligência de ameaças para venda, enquanto alguns fornecedores se
suas práticas de segurança operacional de acordo. Essa dinâmica está
especializam em inteligência de ameaças exclusivamente, muitas vezes
presente em praticamente todos os aspectos do cenário de segurança
prometendo cobertura de ameaças mais sofisticadas do que as fontes
operacional, de assinaturas de antivírus à con fi guração de fi rewalls e
convencionais.
sistemas de detecção de intrusão à resposta a incidentes e triagem.
Comum a todas essas reformulações, no entanto, é o processo de
Infelizmente, apesar dessa promessa tremenda, houve pouca
monitoramento de novos dados sobre o comportamento do invasor
avaliação empírica dos dados de inteligência de ameaças

Associação USENIX 28º Simpósio de Segurança USENIX 851

ou mesmo um consenso sobre o que tal avaliação implicaria. Assim,
os consumidores de TI produtos têm meios limitados para comparar
ofertas ou para fatorar o custo de tais produtos em qualquer
modelo de benefício para a segurança operacional que possa ser
oferecido.
Essa questão motiva nosso trabalho a fornecer uma base
empírica e embasada para abordar tais questões. Em particular,
este documento faz as seguintes contribuições:
v Apresentamos um conjunto básico de métricas de inteligência de ameaças
e descrever uma metodologia para medi-los, notavelmente:
Volume, Contribuição Diferencial, Contribuição
Exclusiva, Latência, Cobertura e Precisão.
v Analisamos 47 endereços IP distintos TI fontes que cobrem seis
categorias de ameaças e 8 hash de arquivo de malware distinto
TI fontes e relatar suas métricas.
v Demonstramos técnicas para avaliar a precisão e
cobertura de certas categorias de TI origens.
v Conduzimos as análises em dois períodos de tempo diferentes,
com dois anos de intervalo, e demonstramos a forte consistência
entre os resultados.
De nossa análise, descobrimos que enquanto alguns TI fontes de dados
mostram sobreposição significativa, a maioria não. Este resultado é consistente
com a hipótese avançada por [ 42 ] que diferentes tipos de infraestrutura de
monitoramento irão capturar diferentes tipos de ataques, mas nós
demonstramos isso em um contexto muito mais amplo. Também revelamos
que subjacente a esta questão estão as limitações mais amplas de TI fontes em
termos de cobertura (a maioria dos indicadores são únicos) e precisão (falsos
positivos podem limitar como esses dados podem ser usados
operacionalmente). Finalmente, apresentamos uma análise longitudinal
sugerindo que esses achados são consistentes ao longo do tempo.
2 Visão Geral
Os dados de inteligência de ameaças coletados para nosso estudo foram
obtidos assinando e puxando de várias fontes de inteligência públicas e
privadas. Essas fontes variaram de listas negras simples de IPs / domínios
e hashes de arquivo ruins até trocas ricas de inteligência de ameaças com
dados bem rotulados e estruturados. Chamamos cada item (por exemplo,
endereço IP ou hash de arquivo) um indicador ( após indicador de
compromisso, o termo da indústria para esses itens de dados).
Nesta seção, enumeramos nossas fontes de inteligência de
ameaças, descrevemos a estrutura de cada fonte e como as
coletamos e, em seguida, definimos nossas métricas de medição
para medir empiricamente essas fontes. Quando a fonte dos dados é
pública ou quando temos um acordo explícito para identificar o
provedor, isso é feito. Porém, em outros casos, os dados foram
fornecidos sob condição de anonimato e nos restringimos a
descrever a natureza do provedor, mas não sua identidade. Todos os
nossos provedores de dados privados foram avaliados quanto à
natureza de nossa pesquisa, seus objetivos e a metodologia que
planejamos empregar.
852 28º Simpósio de Segurança USENIX
2.1 Conjunto e coleta de dados
Usamos várias fontes de TI dados para nossa análise:
Facebook ThreatExchange (FB) [ 17 ] Este é um
plataforma da comunidade que permite que centenas de empresas e
organizações compartilhem e interajam com vários tipos de dados de
ameaças identificados. Como parte de um acordo com o Facebook,
coletamos todos os seus dados que ele compartilhou amplamente. Em
análises subsequentes, as fontes com prefixo “FB” indicam um
contribuidor exclusivo no Facebook ThreatExchange.
Agregador de feed pago (PA). Esta é uma plataforma de agregação de dados de
inteligência de ameaças comercial paga. Ele contém dados coletados de mais de uma
centena de outras fontes de inteligência de ameaças, públicas ou privadas, junto com
seus próprios dados de ameaças. Em análises subsequentes, todas as fontes de dados
com prefixo “PA” são de fontes de dados exclusivas originadas deste agregador.
Serviço pago de reputação de IP. Este serviço comercial fornece uma lista
negra atualizada de hora em hora de endereços IP inválidos conhecidos
em diferentes categorias de ataque.
Listas negras públicas e feeds de reputação. Nós coletamos em
dicadores de listas negras públicas e fontes de dados de
reputação, incluindo fontes conhecidas como AlienVault [ 3 ],
Badips [ 5 ], Abuse.ch [ 1 ] e Packetmail [ 28 ]
Os indicadores de Threat Intelligence incluem diferentes tipos de
dados, como endereço IP, hash de arquivo malicioso, domínio, URL, etc.
Neste artigo, concentramos nossa análise em fontes que fornecem
endereços IP e hashes de arquivo, já que são os mais anteriores. -
emprestou tipos de dados em nossa coleção.
Coletamos dados de todas as fontes de hora em hora. No entanto,
tanto o Facebook ThreatExchange quanto o Paid Feed Aggregator
mudam seus membros e contribuições ao longo do tempo, criando
períodos de coleta irregulares para várias das fontes de sub-dados. Da
mesma forma, os feeds de ameaças públicas tinham vários graus de
confiabilidade, resultando em lacunas de coleta. Neste artigo, usamos a
janela de tempo de 1 de dezembro de 2017 para 20 de julho de 2018 para
a maioria das análises, pois temos o maior número de fontes ativas
durante este período. Eliminamos fontes duplicadas (por exemplo, fontes
que coletamos individualmente e também encontradas no Agregador
pago) e subfontes (uma fonte que é um ramo de outra fonte). Além disso,
dividimos as fontes de IP em categorias separadas e as tratamos como
feeds individuais, conforme mostrado na Seção 3 . Essa filtragem nos deixa
com 47 feeds de IP e 8 feeds de hash de arquivo de malware.
As formas de cada TI A fonte coleta dados varia e, em alguns
casos, a metodologia é desconhecida. Por exemplo, Packetmail IPs e
Paid IP Reputation coletam dados de ameaças por meio de
honeypots, analisando malware, etc. Outras fontes, como Badips ou
Facebook ThreatExchange, coletam seus indicadores de usuários ou
organizações em geral - por exemplo, entidades podem ser atacadas
e enviar os indicadores a esses serviços de inteligência de ameaças.
Esses serviços, então, agregam os dados e os relatam a seus
assinantes. Por meio desse nível de agregação, as metodologias
precisas de coleta e a providência de dados podem ser perdidas.
Associação USENIX
2.2 Estrutura da fonte de dados
TI fontes em nossa estrutura corpus e apresentam dados de maneiras
diferentes. Parte do desafio na produção de métricas de conjunto de
dados cruzado é normalizar tanto a estrutura dos dados quanto sua
significado. A principal diferença estrutural que influencia nossa
análise ocorre entre as fontes de dados que fornecem dados em
instantâneos e fontes de dados que fornecem eventos.
Instantâneo. Os feeds de instantâneo fornecem instantâneos periódicos de um
conjunto de indicadores. Mais formalmente, um instantâneo é um conjunto de
indicadores em função do tempo. Ele define, para um determinado momento,
o conjunto de indicadores que são membros da fonte de dados. Feeds de
instantâneos implicam Estado: a qualquer momento, há um conjunto de
indicadores que são dentro a alimentação. Uma fonte típica de instantâneo é
uma lista publicada de IPs atualizada periodicamente por seu mantenedor. Por
exemplo, uma lista de endereços IP de comando e controle para um botnet
pode ser publicada como um feed de instantâneo sujeito a atualizações
periódicas.
Todos os feeds de hashes de arquivo são instantâneos e são monotônico
no sentido de que os indicadores são apenas adicionados, não
removidos, do feed. Hashes são um proxy para o conteúdo do arquivo,
que não muda (o conteúdo do arquivo malicioso não mudará para
benigno no futuro).
Evento. Em contraste, os feeds de eventos relatam indicadores
recém-descobertos. Mais formalmente, uma fonte de evento é um conjunto de
indicadores em função de um tempo intervalo. Para um determinado intervalo
de tempo, a fonte fornece um conjunto de indicadores que foram vistos ou
descobertos naquele intervalo de tempo. Os assinantes desses feeds
consultam dados solicitando novos indicadores adicionados em uma janela de
tempo recente. Por exemplo, um usuário pode, uma vez por dia, solicitar o
conjunto de indicadores que apareceram nas últimas 24 horas.
Essa diferença estrutural é um grande desafio ao avaliar os alimentos
comparativamente. Precisamos normalizar a diferença para fazer uma
comparação justa, especialmente para feeds IP. A partir de um TI
perspectiva do consumidor, um evento feed não indica quando um
indicador irá expirar, portanto, cabe ao consumidor agir sobre a idade
dos indicadores. Dito de outra forma, as datas de validade dos
indicadores são decididas pela forma como os usuários consultam o
feed: se um usuário solicitar os indicadores vistos nos últimos 30 dias ao
consultar os dados, há uma janela de tempo válida implícita de 30 dias
para esses indicadores.
Neste artigo, escolhemos um período de validade de 30 dias para todos os
indicadores que coletamos de feeds de eventos - o mesmo período válido
usado em vários feeds de instantâneos e também uma opção de janela de
consulta comum oferecida por feeds de eventos. Em seguida, convertemos
esses feeds de eventos em feeds de instantâneo e avaliamos todos eles de
maneira unificada.
2.3 Métricas de inteligência de ameaças
O objetivo deste trabalho é desenvolver métricas de inteligência de
ameaças que permitem um TI consumidor para comparar fontes de
inteligência de ameaças e raciocinar sobre sua adequação para uma
finalidade específica. Para tanto, propomos seis métricas concretas: Volume,
contribuição diferencial, contribuição exclusiva, latência, precisão
e Cobertura.
Associação USENIX
G Volume. Nós definimos o volume de um feed seja o número total
de indicadores que aparecem em um feed durante o intervalo de
medição. Volume é o mais simples TI métrica e tem um histórico
estabelecido em trabalhos anteriores [ 21 , 23 , 24 , 30 , 35 , 36 , 42 ] Também
é útil estudar o diário avaliar de um feed, que quanti fi ca a
quantidade de dados que aparecem em um feed diariamente.
Justificativa: Para uma primeira aproximação, o volume captura a
quantidade de informações que um feed fornece ao consumidor. Para um
feed sem falsos positivos (veja precisão abaixo), e se cada indicador tiver
igual valor para o consumidor, preferiríamos uma ração de maior volume
a uma ração de menor volume. Obviamente, nem todos os indicadores
têm o mesmo valor para os consumidores: saber o endereço IP de um
host sondando toda a Internet em busca de vulnerabilidades de décadas
é menos útil do que o endereço de um scanner que visa organizações em
seu setor que procuram explorar o zero vulnerabilidades diárias.
G Contribuição diferencial. O contribuição diferencial
de um feed em relação a outro é o número de indicadores no
primeiro que não estão no segundo durante o mesmo período de
medição. Definimos a contribuição diferencial em relação ao
tamanho da primeira alimentação, de modo que a contribuição
diferencial da alimentação UMA com respeito a alimentação B é
Diff A, B = | A \ B | / | A |. Assim, Diff A, B = 1 indica que os dois
feeds não têm elementos em comum e Diff A, B = 0 indica que
cada indicador em UMA também aparece em B. Às vezes é
útil considerar o complemento de contribuição diferencial, nomeadamente o
normalizado interseção de UMA dentro B, dado por
Int A, B = | UMA ∩ B | / | A | = 1 - Diff A, B.
Justificativa: Para um consumidor, muitas vezes é útil saber como
vários adicional indicadores que um feed oferece em relação a um
ou mais feeds que o consumidor já possui. Assim, se um consumidor
já tem feed UMA e está pensando em pagar pelo feed
B, então Diff A, B indica quantos novos indicadores alimentam UMA irá
fornecer.
G Contribuição exclusiva. O contribuição exclusiva de um feed em
relação a um conjunto de outros feeds é a proporção de indicadores
exclusivos de um feed, ou seja, a proporção de indicadores que
ocorrem no feed, mas em nenhum outro. Formalmente, o
contribuição exclusiva de feed UMA é definido como Uniq A, B = B 6 = UMA B |
| UMA \ ⋃/ | A |. Assim, Uniq A, B = 0 significa que cada elemento
ment de feed UMA aparece em alguns outros feeds, enquanto Uniq A, B = 1 significa
nenhum elemento de UMA aparece em qualquer outro feed.
Justificativa: Como contribuição diferencial, contribuição exclusiva diz a
um TI consumidor quanto de um feed é diferente. No entanto, a
contribuição exclusiva compara um feed a todos os outros feeds
disponíveis para comparação, enquanto a contribuição diferencial
compara um feed a apenas outro feed. A partir de um TI da perspectiva do
consumidor, a contribuição exclusiva é uma medida geral do valor único
de um alimento.
G Latência. Para um indicador que ocorre em dois ou mais feeds, é latência
em um feed é o tempo decorrido entre sua primeira aparição em
qualquer feed e seu aparecimento no feed em questão. No feed em que
um indicador apareceu pela primeira vez, sua latência é zero. Para todos
os outros feeds, a latência indica quanto tempo depois o
28º Simpósio de Segurança USENIX 853
mesmos indicadores aparecem nesses feeds. Escolha do Provador [ 30 ]
referido à latência como tempo relativo da primeira aparição. ( Encontramos
o termo latência para ser mais sucinto, sem perda de clareza.) Como a
latência é definida para um indicador, para um feed, faz sentido
considerar estatísticas da distribuição das latências do indicador, como a
latência mediana do indicador.
Justificativa: A latência caracteriza a rapidez com que um feed inclui
novas ameaças: quanto mais cedo um feed incluir uma ameaça, mais
eficaz ele será para ajudar os consumidores a proteger seus sistemas. Na
verdade, vários estudos relatam o impacto da latência do feed em sua
eficácia em impedir o spam [ 10 , 32 ]
As métricas acima são definidas sem levar em consideração o significado
dos indicadores em um feed. Podemos calcular o volume de uma única
alimentação ou a contribuição diferencial de uma alimentação em relação
a outra, independentemente do que a alimentação pretende conter.
Embora essas métricas sejam fáceis de calcular, elas pouco nos dizem
sobre a adequação de um feed para uma finalidade específica. Para isso,
precisamos considerar o significado ou propósito dos dados de feed,
conforme anunciados pelo provedor de feed. Definimos as duas
seguintes métricas.
G Precisão. O precisão de um feed é a proporção de indicadores em um
feed que estão incluídos corretamente no feed. A precisão do feed é
análoga a precisão em Recuperação de Informação. Essa métrica presume
que a descrição do feed está bem definida e descreve um conjunto de
elementos que devem estar no feed com conhecimento perfeito. Na
prática, não temos um conhecimento perfeito nem uma descrição
perfeita do que um feed deve conter. Em alguns casos, no entanto,
podemos construir um conjunto UMA - de elementos que definitivamente
não deveriam estar em um feed UMA.
Então Acc UMA ≤ | A \ A - | / | A |.
Justificativa: A métrica de precisão diz a um TI consumidor como
muitos falsos positivos esperados ao usar um feed e, portanto, dita como
um feed pode ser usado. Por exemplo, se um consumidor bloqueia
automaticamente todo o tráfego para endereços IP que aparecem em um
feed, os falsos positivos podem causar interrupção em uma empresa,
bloqueando o tráfego para sites legítimos. Por outro lado, os
consumidores podem tolerar alguns falsos positivos se um feed for usado
apenas para obter informações adicionais durante uma investigação.
G Cobertura. O cobertura de um feed é a proporção dos indicadores
pretendidos contidos em um feed. A cobertura do feed é análoga a lembrar
em Recuperação de Informação. Assim como a precisão, a cobertura
presume que a descrição do feed é suficiente para determinar quais
elementos devem estar em um feed, desde que haja conhecimento
perfeito. Em alguns casos, é possível construir um conjunto A +
de elementos que deveriam estar em um feed. Podemos, então, limite superior
a cobertura Cov UMA ≤ | A | / | A + |.
Justificativa: Para um consumidor de alimentos que pretende obter
proteção completa contra um tipo específico de ameaça, a
cobertura é uma medida de quanta proteção um alimento
fornecerá. Por exemplo, uma organização que deseja se proteger de
um botnet específico deseja maximizar sua cobertura dos servidores
de comando e controle ou vetores de infecção desse botnet.
Nas duas seções a seguir, usamos essas métricas para avaliar dois
tipos de TI: Feeds de endereço IP e feeds de arquivo hash.
854 28º Simpósio de Segurança USENIX
3 Inteligência de ameaças de IP
Uma das formas mais comuns de TI são feeds de endereços IP
considerados maliciosos, suspeitos ou não confiáveis. Esse tipo de
inteligência contra ameaças remonta, pelo menos, às primeiras listas
negras de detecção de spam e intrusão, muitas das quais ainda
estão ativas hoje, como a SpamhausSBL [ 40 ], CBL [ 8 ] e SORBS [ 39 ]
Aqui, aplicamos as métricas descritas acima para quantificar as
diferenças entre 47 endereços IP diferentes TI
feeds.
3.1 Categorização do feed
endereço de IP TI feeds têm diferentes significados e, portanto,
propósitos. Para comparar os feeds de forma significativa entre si,
primeiro agrupamos os feeds em categorias de feeds cujos
indicadores têm o mesmo significado pretendido. Infelizmente, não
existe uma taxonomia padrão ou amplamente aceita de IP TI feeds.
Para agrupar feeds em categorias semânticas, usamos metadados
associados ao feed, bem como descrições do feed fornecidas pelo
produtor, conforme descrito abaixo.
Metadados. Alguns feeds fornecem informações de categoria com
cada indicador como metadados. Mais especificamente, todos os
feeds de agregador pago, Alienvault IP Reputation e Paid IP
Reputation incluem os metadados dessa categoria. Nesse caso,
usamos sua categoria pré-atribuída no feed. Os feeds do Facebook
ThreatExchange não incluem informações da categoria nos
metadados, mas fornecem uma frase descritiva com cada indicador.
Em seguida, derivamos sua categoria com base na descrição.
Descrição do feed. Para feeds sem metadados, contamos com
descrições online de cada feed, quando disponíveis, para determinar
sua categoria semântica. Por exemplo, o site do feed Nothink SSH [ 27
] descreve que o feed relata tentativas de login de força bruta em
seu honeypot correspondente, o que indica que o feed pertence à
categoria de força bruta.
Agrupamos nossos feeds de IP em categorias derivadas das
informações acima. Neste trabalho, analisamos seis das categorias
mais proeminentes:
◦ Varredura: Hosts fazendo varreduras de portas ou vulnerabilidades.
◦ Força bruta: Hosts fazendo tentativas de login de força bruta.
◦ Malware: Malware C&C e servidores de distribuição.
◦ Explorar: Hosts tentando explorar vulnerabilidades remotamente.
◦ Botnet: Hosts comprometidos pertencentes a um botnet.
◦ Spam: Hosts que enviaram spam ou não devem originar e-mail.
Mesa 1 lista os feeds, agrupados por categoria, usados no restante desta
seção. Os símbolos # e 4 antes do nome do feed indique se o feed é um
feed de instantâneo ou um feed de evento, respectivamente (consulte a
seção 2,2 ) Todos os dados foram coletados durante
nosso período de medição, 1 de dezembro de 2017 para 20 de julho,
2018. Observe que alguns feeds, como Reputação de IP pago, aparecem
em várias categorias. Nesses feeds, os indicadores são associados a
diferentes categorias por meio de metadados anexados. Dividimos esses
feeds em vários feeds virtuais, cada um contendo indicadores
pertencentes à mesma categoria.
Associação USENIX
3.2 Volume Tabela 1. IP TI feeds usados no estudo. Um # denota um feed instantâneo e
4 indica um feed de eventos ( Seção 2,2 ) Volume é o número total de IPs coletados
O volume é um dos mais antigos e simples TI métricas que durante nosso período de medição. Exclusivo é a contribuição exclusiva de cada feed
representam o quão informativo é cada fonte de dados. Mesa 1 mostra(Seção 3,4 ) Média Avaliar é o número médio diário de novos IPs adicionados ao feed
(Seção 3,6 ), e Média Tamanho é o tamanho médio do conjunto de trabalho de cada
o número total de endereços IP exclusivos coletados de cada
feed (Seção 3,2 )
feed durante o período de medição, na coluna Volume.
Os feeds são listados em ordem decrescente de volume, agrupados por
Alimentação Volume Exclusivo Média Avaliar Média Tamanho

categoria. Os números que mostramos são posteriores à remoção de

Scan Feeds
entradas inválidas identificadas pelas próprias fontes. Coluna # IPs PA AlienVault 1 425.967 48,6% 1.359 128.821
Média Avaliar mostra o número médio de novos IPs que recebemos por 4 IPs DShield 361.004 31,1% 1.556 69.526
# PA Packetmail ramnode 258.719 62,0% 870 78.974
dia, e Média Tamanho lista o tamanho médio do conjunto de trabalho 4 IPs do Packetmail 246.920 48,6% 942 29.751
diário de cada feed, ou seja, o tamanho médio do instantâneo. # Reputação de IP paga 204.491 75,6% 1.362 8.756
# PA Lab Scan 169.078 63,1% 869 9.775
F Encontrando: Os alimentos variam dramaticamente em volume. Dentro de # PA Snort BlockList 19.085 96,3% 56 4.000
cada categoria, grandes feeds podem conter ordens de magnitude mais dados 4 Agregador FB 1 6.066 71,3% 24 693
# Analista PA 1.572 34,5% 6,3 462
do que pequenos feeds. Por exemplo, na categoria de varredura, vimos mais Feeds de botnet

de 361.004 endereços IP exclusivos em IPs DShield, mas apenas # Analista PA 180.034 99,0% 697 54.800
# PA CI Exército 103.281 97,1% 332 30.388
1.572 endereços exclusivos no PA Analyst no mesmo período. # Reputação de IP paga 77.600 99,9% 567 4.278
Claramente, o volume é um grande diferencial para os feeds. # IPs PA Botscout 23.805 93,8% 81 7.180
# PA VoIP Blacklist 10.712 88,0% 40 3.633
A taxa média diária representa a quantidade de novos indicadores # IPs comprometidos de PA 7.679 87,0% 21 2.392
coletados de um feed a cada dia. Alguns feeds podem ter grande volume, # Bots da lista de bloqueio PA 4.179 80,7% 16 1.160
# Projeto Honeypot PA 2.600 86,5% 8,5 812
mas taxas diárias baixas, como Feodo IP Blacklist na categoria de Feeds de força bruta

malware. Isso significa que a maioria dos indicadores que obtemos desse 4 Badips SSH 542.167 84,1% 2.379 86.677
4 Badips Badbots 91.553 70,8% 559 17.577
feed são dados antigos presentes no feed antes do início de nossa # Reputação de IP paga 89.671 52,8% 483 3.705
medição. Por outro lado, a taxa média de uma alimentação pode ser # PA Brute-Force 41.394 92,1% 138 14.540
4 Nome de usuário do Badips não encontrado 37.198 54,2% 179 3662,8
maior do que o volume sugere, como Nothink SSH na categoria de força 4 Haley SSH 31.115 43,6% 40 1.224
bruta. Isso se deve ao fato de que os indicadores podem ser adicionados 4 Agregador FB 2 22.398 77,3% 74 2.086
4 Nothink SSH 20.325 62,7% 224 12.577
e removidos várias vezes em um feed. Em geral, os indicadores de IP 4 Dangerrulez Brute 10.142 4,88% 37 1.102
Feeds de malware
tendem a ser adicionados em um feed apenas uma vez: 37 entre 47 feeds
# Reputação de IP paga 234.470 99,1% 1.113 22.569
de IP têm mais de 80% de seus indicadores aparecendo apenas uma vez e 4 IPs maliciosos do FB 30.728 99,9% 129 3.873
30 deles têm essa taxa acima de 90%. Uma razão é que alguns feeds de # Feodo IP Blacklist 1.440 47,7% 1,3 1.159
# PA Lab Malware 1.184 84,6% 3,5 366
instantâneo mantêm um período válido para cada indicador, como 4 Lista negra de IP Malc0de 865 61,0% 2,9 86,6
encontramos em todos PA feeds onde a data de validade de cada # IPs PA Bambenek C2 785 92,1% 3,4 97,9
# IPs de malware PA SSL 676 53,9% 2,9 84,0
indicador é registrada explicitamente. Quando o mesmo indicador é # Analista PA 492 79,8% 2,1 149
descoberto novamente por um feed antes de seu tempo de expiração, o # PA Abuse.ch Ransomware 256 7,03% 1,6 117
# PA Mal-Traf fi c-Anal 251 60,5% 0.9 72
feed apenas estenderá sua data de expiração, então essa ocorrência não # Zeus IP Blacklist 185 49,1% 0,5 101
será capturada se simplesmente subtrairmos os dados antigos dos dados Explorar feeds
4 HTTP Badips 305.020 97,6% 1.592 22.644
recém-coletados para derivar o que é adicionado em um dia. Para feeds 4 FTP da Badips 285.329 97,5% 1.313 27.601
de eventos e feeds de instantâneo em PA onde podemos acompanhar 4 DNS da Badips 46.813 99,3% 231 4.758
4 Badips RFI 3.642 91,4% 16 104
com precisão cada ocorrência de cada indicador, examinamos ainda mais 4 Badips SQL 737 79,5% 4,4 99,2
Feeds de spam
a frequência de ocorrência de dados e ainda descobrimos que a grande
# Reputação de IP paga 543.583 99,9% 3.280 6.551
maioria dos IPs em feeds ocorreram apenas uma vez - uma observação 4 Badips Post fi xo 328.258 90,5% 842 27.951
que se relaciona à dinâmica das próprias ameaças cibernéticas. 4 Badips Spam 302.105 89,3% 1.454 30.197
# IPs PA Botscout 14.514 89,3% 49 4.390
Nothink SSH, como mencionamos acima, é uma exceção notável. Tem mais # Reputação de IP da Alienvault 11.292 96,6% 48 1.328
de 64% de seus indicadores aparecendo 7 vezes em nosso conjunto de dados.
Depois de investigar, descobrimos que este feed publica todos os seus dados
anteriores no final de cada mês, comportamento muito provavelmente devido tors, controlados pelo feed (feeds de instantâneo) ou pelo usuário (feeds
ao fornecedor do feed em vez das ameaças subjacentes. de evento). Quanto mais longo for o período de validade, maior será o
conjunto de trabalho. Feeds de snapshoot diferentes têm escolhas
O tamanho do conjunto de trabalho define a quantidade média diária de diferentes para este período válido: IPs do PA AlienVault na categoria de
indicadores que os usuários precisam armazenar em seu sistema para usar um feed varredura define um período válido de 90 dias para cada indicador
(o custo de armazenamento do uso de um feed). O tamanho médio do conjunto de adicionado ao feed, enquanto o PA Abuse.ch Ransomware usa um
trabalho é amplamente decidido pela duração do período válido dos indicadores período de 30 dias. Embora não saibamos o mecanismo de expiração de

1 Este feed é agregado por PA da Alienvault OTX, a reputação de IP da dados usado por feeds de instantâneos, exceto PA feeds, como não há
Alienvault é o feed de reputação pública que coletamos diretamente da informações relacionadas registradas, ainda podemos estimar isso
AlienVault. Eles são feeds diferentes. verificando o durações de seus indicadores - o tempo

Associação USENIX 28º Simpósio de Segurança USENIX 855


Varredura
Botnet
Força bruta
Malware
Spam Explorar
Varredura Força bruta de botnet Malware
Figura 1. Interseção de alimentação para todos os feeds IP. Cada linha / coluna representa
um feed, mostrado na mesma ordem da Tabela 1 . Cores mais escuras (mais saturadas)
indicam maior interseção.
entre um indicador sendo adicionado e removido. Quatro feeds
de reputação de IP pago têm mais de 85% de durações menores
que 10 dias, enquanto o da categoria de malware tem mais de
40% que se estendem por mais de 20 dias. Feodo IP Blacklist
tem mais de 99% de seus indicadores válidos para todo o nosso
período de medição, enquanto mais de 70% das durações na
Zeus IP Blacklist são menos de 6 dias. Não observamos um
padrão claro sobre como cada feed de instantâneo lida com a
expiração de indicadores.
3.3 Contribuição diferencial e intersecção
A métrica de contribuição diferencial mede o número de indicadores
em um feed que não estão em outro. De forma equivalente,
podemos considerar a interseção de dois feeds, que é o número de
elementos em um feed que estão presentes no outro, normalizado
pelo tamanho do primeiro: | UMA ∩ B | / | A |. Figura 1 mostra a
relação de interseção de todos os feeds no estudo. Cada célula na
matriz representa o número de elementos em ambos os feeds,
normalizado pelo tamanho do feed que abrange as linhas da tabela.
Isso é, UMA, na expressão acima, abrange linhas e B sobre as
colunas da matriz. Cores mais escuras (mais saturadas) indicam
maior interseção. As comparações de feeds dentro de uma categoria
são sombreadas em vermelho e as comparações de feeds entre
diferentes categorias são sombreadas em azul. Observe que a matriz
é assimétrica, porque, em geral, | UMA ∩ B | / | A | =
B | / | B |. Os elementos da matriz estão na mesma ordem que na
Tabela 1 .
F Encontrando: Feeds nas categorias de varredura e força bruta têm
interseções de pares mais altas: Metade da interseção de pares
856 28º Simpósio de Segurança USENIX
as taxas em duas categorias são superiores a 5%. A categoria de
varredura tem 29 de 72 pares (excluindo auto-comparações) com
uma taxa de interseção maior que 10%, e o mesmo caso ocorreu em
19 de 72 pares na categoria de força bruta.
Por outro lado, os feeds na categoria de botnet, exploit, malware e
spam não compartilham muitos dados entre si: todas as 4 categorias têm
mais de três quartos das taxas de interseção de pares inferiores a 1%.
Alguns grandes feeds nessas categorias podem compartilhar uma
quantidade significativa de dados com alguns pequenos feeds na mesma
categoria - uma característica que aparece como uma linha vertical
escura dentro de sua categoria na Figura 1 . A reputação de IP pago na
categoria de malware, por exemplo, compartilha mais de 30% de 6 outros
feeds de malware. Mas as interseções entre a grande maioria dos feeds
nessas 4 categorias são baixas. Este achado é consistente com o trabalho
anterior [ 26 , 42 ], mas fornecemos uma visão mais abrangente sobre as
diferentes categorias.
Figura 1 também mostra a relação entre feeds em diferentes
categorias. Podemos ver claramente uma relação entre varredura e
feeds de força bruta: feeds de varredura múltiplos têm interseção
Explorar Spam
não trivial com feeds na categoria de força bruta. Na verdade,
23,1% de todos os 760.263 IPs de força bruta que coletamos também
estão incluídos por feeds de varredura em nosso conjunto de dados.
Também há três feeds de botnet - PA CI Army, PA VoIP Blacklist e PA
Comprometidos IPs - que têm mais de 10% de seus dados
compartilhados com vários feeds na categoria de varredura.
3.4 Contribuição Exclusiva
A contribuição exclusiva representa o número de indicadores em um
feed que não está em nenhum outro feed. Calculamos a contribuição
exclusiva de cada feed entre todos os feeds na mesma categoria,
enfatizando sua singularidade em relação ao escopo dos dados que
afirmam relatar. Cada contribuição exclusiva de feed é apresentada
na Tabela 1 na coluna Exclusivo, calculado com base em seu volume.
F Encontrando: Como já observamos na Seção 3,3 , botnet, exploit e
feeds de spam têm interseções de pares relativamente baixas.
Conseqüentemente, os feeds nessas quatro categorias têm altas
taxas de contribuição exclusiva em geral: as taxas de contribuição
exclusiva da mediana dessas quatro categorias são
90,9%, 97,5% e 90,5%, respectivamente. A categoria de malware tem uma
taxa de exclusividade mediana baixa, uma vez que vários pequenos feeds
têm uma interseção não trivial com o maior feed de reputação de IP
paga, mas os dois maiores feeds de malware têm uma taxa exclusiva de
mais de 99%. Os feeds de varredura e de força bruta têm mais interseção
dentro de sua categoria, e suas taxas exclusivas são mais baixas: 62,0%
de taxa média em varredura e 62,7% de força bruta, e os dois maiores
feeds em ambas as categorias têm uma taxa exclusiva abaixo de 85% .
Se assumirmos um processo em que um feed tem mais probabilidade de ter
6 UMA ∩ elementos populares, feeds menores seriam incluídos em feeds maiores. No entanto,
para alguns pequenos feeds como Malc0de IP Blacklist no malware e PA Project
Honeypot nas categorias de botnet, mesmo que sejam várias ordens de magnitude
menores do que os maiores feeds em suas categorias, um significativo
Associação USENIX

Analista PA
PA Packetmail ram *
IPs do Packetmail
PA Lab Scan
FB Aggregator_1
IPs DShield
IPs PA AlienVault
Reputação de IP paga
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Latência (dias)
(uma) Distribuição de latência em feeds de varredura
Badips Badbots
Nome de usuário do Badips *
Dangerrulez Brute
Haley SSH
Nothink SSH
FB Aggregator_2
Reputação de IP paga
Badips SSH
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Latência (dias)
(b) Distribuição de latência em feeds de força bruta
Figura 2. Distribuição da latência dos indicadores em varredura e feeds de força
bruta. Cada caixa mostra a distribuição de latência de IPs compartilhados no feed,
calculada em horas, do percentil 25 ao percentil 75, com a linha do meio indicando a
mediana. (“Badips Username *” aqui é a abreviatura para o nome do feed Badips
Username Notfound; “PA Packetmail Ram *” para PA Packetmail Ramnode)
proporção de seus indicadores ainda é exclusiva para o feed. Quando agregamos os
dados em cada categoria, 73% de todos os indicadores de alimentação de varredura
são exclusivos para uma única alimentação e 88% dos indicadores de alimentação de
força bruta são exclusivos para uma alimentação. Para outras categorias, mais de
97% dos elementos na categoria são exclusivos de um único feed. Este resultado
concorda com o trabalho anterior de que a maioria dos dados em feeds de
inteligência de ameaças é única [ 26 , 42 ]
3,5 Latência
A latência do feed mede a rapidez com que um feed relata novos
indicadores de ameaça. Quanto mais cedo um feed puder relatar
ameaças em potencial, mais valioso ele será para os consumidores.
A latência absoluta de um indicador em um feed é o tempo desde o
início do evento correspondente até quando o indicador aparece no
feed. No entanto, é difícil saber a hora real em que um evento
começa a partir dos dados de inteligência de ameaças. Em vez disso,
medimos o latência relativa, que é o atraso de um indicador em um
feed para ser o tempo entre seu aparecimento naquele feed e o
primeiro visto entre todos os feeds.
A latência relativa só pode ser calculada para indicadores que ocorrem
em pelo menos dois feeds. Conforme discutido na Seção 3,4 , o número de
indicadores comuns nos feeds de botnet, malware, exploit e spam é
muito baixo (menos de 3% dos elementos ocorrem em mais de um feed).
A latência relativa calculada para esses feeds é menos significativa. Para
esta análise, portanto, nos concentramos
Associação USENIX
em varredura e feeds de força bruta.
Outro problema é a sensibilidade ao tempo das ameaças de IP. Um evento
originado de um endereço IP, como atividade de varredura ou um ataque de
força bruta, não durará para sempre. Se um feed de varredura relatar um
endereço IP hoje e outro feed relatar o mesmo IP três meses depois, faria
pouco sentido considerá-los como um evento de varredura e rotular a segunda
ocorrência como estando três meses atrasada. Infelizmente, não existe uma
maneira fácil de distinguir claramente os eventos uns dos outros. Aqui,
usamos uma janela de um mês para restringir um evento, supondo que o
mesmo ataque de uma fonte não durará mais de 30 dias; embora arbitrário,
ele fornece um limite razoavelmente conservador, e a experiência com outros
limites produziu resultados gerais semelhantes. Mais especificamente,
calculamos a latência relativa rastreando a primeira ocorrência de IPs em
todos os feeds em uma categoria e, em seguida, registramos a latência das
ocorrências seguintes e excluímos as que ocorrem após 30 dias. Usando
apenas a primeira aparência de cada IP como base, evitamos a incerteza
causada pela ocorrência múltipla de indicadores e diferentes períodos de
validade usados entre os feeds.
Figuras 2a e 2b mostram a distribuição de latência relativa entre
feeds nas categorias de varredura e força bruta, em horas. Nós nos
concentramos apenas nos feeds que têm mais de 10% dos dados
compartilhados com outras pessoas para garantir que a análise
possa representar a distribuição de latência do feed geral. Há um
feed em cada categoria (PA Snort BlockList na varredura e PA
Brute-Force na força bruta) que é excluído da figura.
F Encontrando: Nas caixas de distribuição, podemos ver que Reputação
de IP pago em varredura e Badips SSH em força bruta são os feeds mais
rápidos em sua categoria, pois têm a mediana mais baixa e latências de
75º percentil. Por outro lado, PA Analyst em varredura e Badips Badbots
em força bruta são os feeds mais lentos. Figura 2a mostra que todos os
feeds de varredura, exceto um, têm sua latência de 25º percentil igual a
0, indicando que esses feeds, em tamanhos diferentes, todos relataram
uma parte significativa de seus dados compartilhados primeiro. Um caso
semelhante também ocorre na categoria de força bruta.
Pode-se perguntar se os grandes feeds relatam dados mais
cedo do que os pequenos. O resultado mostra que isso não é
sempre o caso. Agregador FB 1 é o segundo menor feed em nossa
categoria de varredura, mas não é mais lento do que vários outros feeds
que tem mais de 10 vezes de sua taxa diária. Badips Badbots, por
outro lado, tem a segunda maior taxa na categoria de força bruta,
mas é mais lento do que todos os outros feeds na categoria de força
bruta. Feeds de pequeno volume ainda podem relatar muitos de
seus dados primeiro.
Outro fator que pode afetar a latência é se os feeds copiam dados uns
dos outros. Por exemplo, 93% de Dangerrulez Brute também aparece em
Badips SSH. Se for esse o caso, esperamos que o Dangerrulez Brute seja
mais rápido do que o Badips SSH ao relatar seus dados compartilhados.
No entanto, comparamos a latência relativa entre apenas dois feeds e
descobrimos que o Badips SSH relatou 88% de seus indicadores
compartilhados primeiro. Além disso, conduzimos essa comparação de
latência de pares entre todos os feeds
28º Simpósio de Segurança USENIX 857
Mesa 2. IP TI visão geral da precisão dos feeds. Unrt é a fração de endereços irreversíveis em
3.6 Precisão
cada feed (Seção 3,6 ) Alexa Top é o número de IPs que se cruzaram com os principais
endereços IP do domínio Alexa, e CDNs é o número de IPs interceptados com os principais A precisão mede a taxa de falsos positivos em um feed. Um falso positivo
endereços IP dos provedores de CDN.
é um indicador de que os dados são rotulados com uma categoria à qual
não pertencem. Por exemplo, um endereço IP encontrado em um feed de
Alimentação Adicionado Unrt Alexa CDNs
varredura que não realizou nenhuma varredura na Internet é um desses
Scan Feeds
falsos positivos. Da mesma forma, mesmo que um determinado IP esteja
IPs PA AlienVault 313.175 0,0% 1 0
IPs DShield 339.805 0,03% 68 62 de fato associado a atividades maliciosas, se não for inequivocamente
PA Packetmail ramnode 200.568 <0,01% 0 0
acionável (por exemplo, o DNS do Google em 8.8.8.8 é usado por
IPs do Packetmail 211.081 0,0% 0 0
Reputação de IP paga 200.915 1,65% 6 21 software malicioso e benigno), então, para muitos casos de uso, ele
PA Lab Scan 169.037 <0,01% 0 0
também deve ser tratado como um falso positivo. Os falsos positivos são
PA Snort BlockList 12.957 0,42% 1 0
Agregador FB 1 5.601 0,0% 0 0 problemáticos por vários motivos, mas principalmente porque podem ter
Analista PA 1.451 0,41% 0 0
consequências operacionais adversas. Por exemplo, alguém pode
Feeds de botnet
Analista PA 180.034 <0,01% 0 0 razoavelmente desejar bloquear todas as novas conexões de rede de e
PA CI Exército 76.125 <0,01% 0 0
para endereços IP relatados como hospedando atividades maliciosas (na
Reputação de IP paga 73.710 1,66% 6 74
IPs PA Botscout 18.638 0,09% 1 0 verdade, esse uso é uma das promessas da inteligência de ameaças). No
PA VoIP Blacklist 9.290 0,32% 0 0
entanto, falsos positivos em tais feeds também podem levar ao bloqueio
IPs comprometidos de PA 4.883 0,0% 0 0
Bots da lista de bloqueio PA 3.594 0,0% 0 0 de conexões legítimas. Portanto, o grau de precisão de um feed pode
Projeto Honeypot PA 1.947 0,0% 0 0
impedir certos casos de uso.
Feeds de força bruta
Badips SSH 456.605 0,19% 217 1 Infelizmente, determinar quais IPs pertencem a um feed e quais não
Badips Badbots 91.553 1,04% 46 1.251
podem ser extremamente desafiador. Na verdade, em qualquer escala
Reputação de IP paga 87.524 0,03% 0 10
PA Brute-Force 31.555 0,0% 0 0 razoável, não temos conhecimento de nenhum método para estabelecer
Nome de usuário do Badips não encontrado 37.198 0,53% 4 0
de maneira inequívoca e abrangente uma “verdade fundamental” sobre
Haley SSH 8.784 0,03% 0 0
Agregador FB 2 17.779 0,0% 0 0 esse assunto. Em vez disso, nesta seção, relatamos um proxy de precisão
Nothink SSH 20.325 1,51% 2 0
que fornece uma avaliação conservadora desta questão. Para saber, nós
Dangerrulez Brute 8.247 0,0% 0 0
Feeds de malware montamos um whitelist de endereços IP que não deveriam ser
Reputação de IP paga 217.073 0,13% 291 3.489
razoavelmente incluídos em um feed ou que, se incluídos, causariam uma
IPs maliciosos do FB 29.840 2,14% 2 0
Feodo IP Blacklist 296 0,0% 0 0 interrupção significativa. Argumentamos que a presença de tais IPs em
PA Lab Malware 806 2,85% 0 0
um feed são claramente falsos positivos e, portanto, definem um limite
Lista negra de IP Malc0de 668 0,0% 8 11
PA Bambenek C2 IPs PA 777 9,13% 0 0 superior na precisão de um feed. Preenchemos nossa lista a partir de três
SSL Malware IPs 674 0,0% 0 0
fontes: IPs não roteáveis, IPs associados aos principais domínios Alexa e
Analista de PA 486 0,0% 0 0
PA Abuse.ch Ransomware 256 3,12% 0 0 IPs das principais redes de distribuição de conteúdo (CDNs).
PA Mal-Traf fi c-Anal 193 0,51% 0 0
Zeus IP Blacklist 67 0,0% 1 0
Explorar feeds IPs irrotáveis. IPs não roteáveis são endereços IP que não eram
HTTP Badips 305.020 0,67% 16 2.590
roteáveis por BGP quando eles apareceram pela primeira vez em um
FTP da Badips 285.329 1,33% 14 2
DNS da Badips 46.813 0,50% 119 244 feed, conforme estabelecido por dados contemporâneos no serviço
Badips RFI 3.642 2,22% 0 0
RouteViews [ 44 ] Embora tais IPs possam ter aparecido no campo de
Badips SQL 737 1,89% 0 1
Feeds de spam endereço de origem de um pacote (ou seja, devido a spoofing de
Reputação de IP paga 543.546 78,7% 1 0
endereço), não seria possível completar um handshake TCP. Os feeds que
Badips Spam 302.105 0,02% 19 0
Badips Post fi xo 193.674 1,29% 18 1 implicam que tal interação ocorreu não devem incluir esses IPs. Por
IPs PA Botscout 11.358 0,06% 0 0
exemplo, feeds na categoria de força bruta implicam que os IPs que eles
Reputação de IP da Alienvault 10.414 0,07% 63 1.040
contêm estiveram envolvidos em tentativas de login de força bruta, mas
isso não poderia ter ocorrido se os IPs não fossem roteáveis. Embora a
inclusão de endereços não roteáveis em um feed não seja, por si só, um
problema, sua inclusão sugere um problema de controle de qualidade
com o feed, lançando uma sombra sobre a validade de outros indicadores
no feed.
em varredura, força bruta e malware (já que Paid IP Reputation Para permitir alguns atrasos no feed, verificamos se um IP foi
compartilha uma quantidade não trivial de dados com alguns roteável a qualquer momento nos sete dias anteriores à sua
pequenos feeds na categoria de malware) e não viu uma vantagem primeira aparição em um feed e, se tiver sido, não o consideramos
de latência clara entre dois feeds. Observe que esta observação não irreversível. Mesa 2 coluna Unrt, mostra a fração de indicadores de IP
provar que não há cópia de dados, uma vez que os dados compartilhados que não foram roteáveis a qualquer momento nos sete dias
entre dois feeds podem vir parcialmente da cópia e parcialmente da anteriores ao aparecimento no feed. Esta análise é conduzida
própria coleta de dados dos feeds. Além disso, nossa análise de latência apenas para os IPs adicionados após o início da nossa medição. O
está na granularidade de uma hora. número de tais IPs é mostrado na coluna Adicionado,

858 28º Simpósio de Segurança USENIX Associação USENIX

e a fração irrotável mostrada em Unrt é em relação a este
número.
Alexa. Bloquear o acesso a sites populares da Internet ou disparar
alarmes sempre que esses sites são acessados pode prejudicar a
empresa. Para nossa análise, coletamos periodicamente os 25 mil
principais domínios do Alexa (3 a 4 vezes por mês) ao longo do
período de medição [ 2 ] Para enfrentar o desafio de que tais listas
podem ter rotatividade significativa [ 33 ], restringimos nossa lista de
permissões para conter o interseção de todas essas listas dos 25 mil
principais (ou seja, domínios que estavam entre os 25 mil principais
todas as vezes que pesquisamos o Alexa durante nosso período de
medição de 8 meses), o que nos deixou com 12.009 domínios. Em
seguida, consultamos o DNS para os registros A, registros NS e
registros MX de cada domínio e coletamos os endereços IP
correspondentes. No total, coletamos 42.436 endereços IP
associados a esses domínios. Calculamos a interseção desses IPs
com TI feeds e mostrar os resultados na coluna Alexa na tabela 2 .
CDNs. Os provedores de CDN atendem a centenas de milhares de sites.
Embora esses serviços CDN possam (e sejam) abusados para realizar
atividades maliciosas [ 9 ], seus endereços IP não são acionáveis. Como
esses são serviços fundamentalmente compartilhados, o bloqueio de tais
endereços IP também interromperá o acesso a sites benignos servidos
por esses IPs. Coletamos os intervalos de IP usados por 5 provedores de
CDN populares: AWS CloudFron [ 12 ], Cloud fl are [ 11 ], Rapidamente [ 18 ],
EdgeCast [ 16 ] e MaxCDN [ 25 ] Em seguida, verificamos quantos IPs em TI os
feeds se enquadram nessas faixas. Coluna
CDNs na tabela 2 mostra o resultado.
F Encontrando: Entre os 47 feeds da tabela, 33 feeds têm pelo menos um
IP não roteável e, para 13 deles, mais de 1% dos endereços que eles
contêm são não roteáveis. Notavelmente, o feed de reputação de IP pago
na categoria de spam tem uma taxa irreversível de mais de 78%. Embora
não esteja documentado, uma explicação provável é que esse feed pode
incluir IPs irrotáveis intencionalmente, pois essa é uma prática
conhecida entre alguns feeds de spam. Por exemplo, a Lista DROP do
Spamhaus [ 41 ] inclui intervalos de endereços IP que são propriedade ou
operados por agentes mal-intencionados, sejam eles anunciados ou não.
Portanto, para feeds que incluem explicitamente IPs não roteáveis, sua
presença nos feeds não deve ser necessariamente interpretada como um
problema de controle de qualidade.
Além disso, verificamos nos feeds a presença de quaisquer “IPs
reservados” que, conforme documentado no RFC 8190, não são roteáveis
globalmente (por exemplo, intervalos de endereços privados, redes de
teste, loopback e multicast). De fato, 12 feeds relataram pelo menos um
IP reservado, incluindo quatro feeds de reputação de IP pago (exceto a
categoria de spam), seis feeds de Badips e os feeds de IPs
mal-intencionados FB e IPs de DShield. Pior, os feeds de reputação de IP
pago juntos relataram mais de 100 IPs reservados. Uma vez que tais
endereços nunca devem aparecer em uma rede pública, relatar tais IPs
indica que um provedor de alimentação falha ao incorporar algumas
verificações básicas de sanidade em seus dados.
Existem 21 feeds que incluem IPs dos principais domínios do
Alexa, conforme mostrado na coluna Alexa na tabela 2 . Entre
esses IPs existem 533 registros A, 333 IPs de registros MX e 63
IPs de registros NS. Os IPs sobrepostos incluem vários
Associação USENIX
posições de domínios notáveis. Por exemplo, os endereços IP de
www.github.com são incluídos pela Malc0de IP Blacklist. A
reputação de IP paga na categoria de malware contém o
endereço IP de www.dropbox.com. Alienvault IP Reputation
contém o registro MX de groupon.com, e Badips SSH também
contém os endereços IP de sites populares, como
www.bing.com.
A maioria dos feeds que avaliamos não contém IPs em intervalos
de CDN, mas existem alguns (incluindo vários feeds de reputação de
IP pago, feeds de Badips e Alienvault IP Reputation) que têm
interseção significativa com IPs de CDN. Os feeds Alienvault IP
Reputation e Badips se cruzam principalmente com o Cloud fl are
CDN, enquanto a maior parte da sobreposição na categoria de
malware de Reputação de IP pago se sobrepõe ao AWS CloudFront.
No geral, a taxa de falsos positivos em uma alimentação não está
fortemente correlacionada com seu volume. Além disso, certas classes de
falsos positivos (por exemplo, a presença de IPs Top Alex ou IPs CDN)
parecem ser subprodutos de como feeds distintos são coletados (por
exemplo, feeds Badips tendem a conter tais IPs, independentemente do
volume). Sem surpresa, também não encontramos correlação entre a
latência de um feed e sua precisão.
3.7 Cobertura
A métrica de cobertura fornece uma medida quantitativa de quão bem
um feed captura a ameaça pretendida. Um feed com cobertura perfeita
incluiria todos os indicadores que pertencem a uma categoria.
Infelizmente, conforme discutido acima, não há uma maneira sistemática
de avaliar a exatidão ou cobertura exata de um feed, pois não é realista
obter informações sobre todas as atividades de ameaça na Internet.
No entanto, existem algumas atividades de ameaça em grande escala
que são bem coletadas e bem estudadas. Um exemplo é a digitalização
pela Internet. Pesquisadores têm usado “telescópios da Internet” para
observar e medir as atividades de varredura de rede [ 6 , 15 , 29 ] Com um
grande telescópio e uma lógica de filtragem de varredura bem definida,
pode-se obter uma visão abrangente das atividades de varredura globais
na Internet.
Para este fim, coletamos três meses de tráfego (de 1º de janeiro a 31
de março de 2018) usando o telescópio de rede UCSD [ 38 ], que monitora
uma rede / 8 em grande parte inativa, compreendendo mais de 16
milhões de endereços IP. Em seguida, usamos os parâmetros padrão do
Bro IDS [ 7 ] para identificar o provável tráfego de varredura, ou seja, fl
uxos nos quais o mesmo endereço IP de origem é usado para contatar 25
endereços IP de destino exclusivos na mesma porta / protocolo de
destino em 5 minutos. Dado o grande número de endereços sendo
monitorados, qualquer scanner indiscriminado observado por TI feeds
provavelmente também serão vistos em nossos dados. Na verdade, ao
cruzar com os dados deste telescópio, somos capazes de quantificar
parcialmente a cobertura de cada TI digitalização de feed.
Os scanners que coletamos do telescópio consistem em
20.674.149 endereços IP. O número total de IPs em todos os feeds
de varredura durante este período é 425.286, que cobre apenas
1,7% (363.799 IPs compartilhados) de todos os IPs de varredura do telescópio. No
28º Simpósio de Segurança USENIX 859
 50%
IPs PA AlienVault PA Lab Scan
IPs DShield PA Snort BlockList
40% PA Packetmail ram * FB Aggregator_1
IPs do Packetmail Analista PA
Reputação de IP paga
30%
Cobertura
20%
10%
1K 10K 100K 1M
Tamanho do scanner
Figura 3. A cobertura de cada feed em diferentes tamanhos de scanners. Y eixo é a
proporção de scanners de um determinado tamanho ou maior que são cobertos por cada
feed.
Por outro lado, os scanners telescópicos se cruzam com 85% de todos os
IPs em feeds de varredura. Ao olhar para cada feed, os IPs PA AlienVault,
IPs DShield IPs Packetmail, PA Lab Scan e PA Packetmail ramnode têm
mais de 85% de seus dados interceptados com scanners telescópicos; os
outros quatro, entretanto, têm menos de 65% de seus dados
compartilhados (e a taxa para PA Snort BlockList é de apenas 8%).
Para entender melhor como cada feed de varredura detecta atividades
de varredura, medimos como diferentes tamanhos de scanners no
telescópio são cobertos por cada feed. Aqui, tamanho do scanner
significa quantos IPs um scanner varreu no telescópio em um dia.
Figura 3 mostra a taxa de cobertura de cada alimentação em
diferentes tamanhos de scanners, variando de 1.000 a 1 milhão.
(Existem 7.212.218 scanners do telescópio cujos tamanhos são
superiores a 1K, 271.888 que são superiores a 100K e 17.579 são
superiores a 1 milhão.)
F Encontrando: A união de todos os scanners IPs nos feeds cobre menos de 2%
dos scanners coletados pelo telescópio. Mesmo se olharmos apenas para os
scanners com tamanhos maiores que 10.000, a cobertura geral ainda está em
torno de 10%, sugerindo que a capacidade de cobertura dos feeds de
digitalização é muito limitada. O gráfico mostra que, à medida que o tamanho
do scanner aumenta, a cobertura de cada alimentação nos conjuntos de dados
também aumenta, e grandes feeds cobrem mais por cento dos scanners
telescópicos do que pequenos feeds. Essa tendência se alinha com a intuição
de que os feeds de varredura tendem a capturar scanners mais extensos.
É surpreendente que os pequenos feeds de varredura em nossa
coleção tenham uma porcentagem menor de seus IPs compartilhados
com scanners telescópicos. Isso contradiz a ideia de que pequenos feeds
conteriam uma porcentagem maior de scanners extensos (que
provavelmente também seriam observados pelo telescópio).
4 Arquivo Hash Threat Intelligence
Hashes de arquivo em um feed de inteligência de ameaças são indicadores de arquivos
maliciosos. É uma das maneiras mais leves de marcar arquivos como suspeitos. Pode-se
incorporar esses dados para bloquear downloads maliciosos, anexos de e-mail maliciosos e
malware. Da mesma forma, os hashes de arquivo podem ser usados para colocar aplicativos
na lista de permissões e
860 28º Simpósio de Segurança USENIX
esses feeds podem ser usados para garantir que arquivos maliciosos não
apareçam na lista de permissões de um cliente. Nesta seção, apresentamos
nossa análise em oito feeds de hash de arquivo, também coletados de 1º de
dezembro de 2017 a 20 de julho de 2018. Usamos as mesmas métricas
definidas na Seção 2,3 .
Os feeds hash de arquivo que coletamos usam uma gama de funções
hash diferentes para especificar arquivos maliciosos, incluindo MD5,
SHA1, SHA256 e SHA512 (e alguns feeds forneciam valores para várias
funções hash diferentes para oferecer suporte à interoperabilidade).
Como a maioria dos indicadores em nosso conjunto de dados são MD5s,
normalizamos essa representação usando outros feeds e o serviço
VirusTotal para identificar aliases de hash para arquivos maliciosos
conhecidos (ou seja, qual MD5 corresponde a um determinado valor
SHA256).
4.1 Volume
Os hashes de arquivo, ao contrário dos dados de ameaça de IP, não são
transitórios - um arquivo não muda de malicioso para benigno - e, portanto,
uma análise de volume muito mais simples é apropriada. Relatamos o volume
como o número de novos hashes que são adicionados a cada feed durante
nosso período de medição.
Como pode ser visto na Tabela 3 , examinamos o volume de cada feed e
taxa média diária. Assim como os feeds de IP, os feeds de hash de
arquivo também variam dramaticamente em volume. A maioria dos
hashes está concentrada em três feeds: FB Malware, PAMalware
Indicators e PA Analyst, que também exibem as taxas diárias mais altas.
Os outros feeds são de múltiplas ordens de magnitude menores
comparativamente.
4.2 Intersecção e contribuição exclusiva
Como mencionamos anteriormente, para conduzir a interseção e
análise exclusiva de feeds de hash de arquivo, precisamos converter
os indicadores no mesmo tipo de hash. Aqui, convertemos hashes
não MD5 em MD5s, usando metadados no próprio indicador (ou
seja, se ele relata valores para várias funções de hash) ou
consultando o hash de origem do VirusTotal [ 45 ] que relata o
conjunto completo de hashes para todos os arquivos em seu
conjunto de dados. No entanto, para uma pequena fração de
hashes, não podemos encontrar apelidos para convertê-los para a
representação MD5 e devemos excluí-los da análise nesta seção.
Esta filtragem é refletida na Tabela 3 , em que a coluna Volume
representa o número de hashes exclusivos encontrados em cada
feed e a coluna Convertido é o subconjunto que pudemos normalizar
para uma representação MD5.
F Encontrando: As interseções entre os feeds de hash são mínimas,
mesmo entre os feeds que têm várias ordens de diferenças de magnitude
no tamanho. Em todos os feeds, apenas o PA Analyst tem interseções
relativamente altas: o PA Analyst compartilha 27% dos MD5s do PA OSINT
e 13% dos MD5s do PA Twitter Emotet. O PA Malware Indicators também
tem uma pequena interseção com esses dois feeds. Todas as outras
interseções têm cerca de 1% ou menos. Consequentemente, a grande
maioria dos MD5s são exclusivos para um feed, conforme registrado na
coluna Exclusivo na tabela 3 . A exclusividade “mais baixa” pertence ao PA
Twitter Emotet e PA OSINT (ainda
Associação USENIX
Tabela 3. Visão geral dos feeds de hash de arquivo. O segundo grupo de colunas apresenta o volume de alimentação, a taxa média diária, o número de MD5s convertidos (Seção 4,2
) e proporção exclusiva. Não em VT é a fração de hashes que não são encontrados no VirusTotal, Não det. a fração de hashes que são encontrados no VirusTotal, mas não são
rotulados como maliciosos por nenhum produto, e Detectou a fração encontrada no VirusTotal e rotulada como maliciosa por pelo menos um produto. Coluna Não está em SD mostra
a fração de hashes em um feed que não está no Shadowserver Bin Check. Em NSRL e Em AppInfo mostra o número absoluto de hashes encontrados no Shadowserver (Seção 4,3 ) Exclusivo
é baseado nos hashes normalizados MD5 contados sob Convertido. Todas as outras porcentagens na tabela são baseadas em Volume.

Alimentação Volume médio Taxa convertida exclusiva Não em VT Não det. Não detectado em SD em NSRL em AppInfo

Malware FB 944.257 4.070 944.257> 99,99% 37,41% 50,50% 12,09% 99,89% 442 706
Indicadores de malware PA 39.702 171 39.702 98,73% 0,02% 0,04% 99,94%> 99,99% 2 0
Analista PA 38.586 166 37.665 97,97% 4,26% 2,82% 92,92% 99,95% 8 19
PA Twitter Emotet 1.031 4,44 960 77,29% 11,74% 0,78% 87,49% 99,81% 0 2
PA OSINT 829 3,57 783 71,65% 19,06% 0,84% 80,10% 99,88% 1 0
PA Sandbox 298 1,28 115 95,65% 72,81% 0,34% 26,85% 100% 0 0
PA Abuse.ch 267 1,15 3 100% 98,88% 0,75% 0,37% 100% 0 0
PA Zeus Tracker 17 0,07 17 100% 88,24% 5,88% 5,88% 100% 0 0

77,29% e 71,65%, respectivamente). Todos os outros feeds apresentam uma 100%

Analista PA
porcentagem exclusiva de mais de 95%, demonstrando que a maioria dos 90%
PA Zeus Tracker
PA Twitter Emotet
feeds de hash de arquivo são distintos uns dos outros. 80%
Malware FB
Devido às diferentes fontes de malware entre os feeds, uma baixa 70%

Porcentagem de Hashes
Indicadores de malware PA
PA OSINT
interseção é esperada em alguns casos. Por exemplo, o PA Twitter 60%
PA Sandbox
Emotet e o PA Zeus Tracker não devem ter interseção, pois estão 50% PA Abuse.ch

rastreando diferentes cepas de malware. Os outros feeds, mais 40%

gerais, podem esperar alguma sobreposição, mas a maioria exibe 30%

pouca ou nenhuma interseção. Considerando o grande volume do 20%

feed de malware do FB, pode-se esperar que ele encapsule muitos 10%
dos feeds menores ou pelo menos partes deles. No entanto, este
0 10 20 30 40 50 60
não é o caso, pois o FB Malware tem uma interseção insignificante
Número de verificador do VirusTotal
com todos os outros feeds.
Devido à falta de interseção entre os feeds, omitimos a análise de Figura 4. Distribuição de detecção do VirusTotal. Cada ponto significa a proporção de
latência dos feeds de hash, pois simplesmente não há dados de indicadores (valor Y) em um feed que é detectado por sobre X número de scanners AV

interseção suficientes para concluir quais feeds têm melhor no VirusTotal.

desempenho em relação à latência.

4.3 Precisão feed para esta análise.

Avaliar a precisão dos feeds de hash de arquivo apresenta um problema:
não existe uma verdade básica universal para determinar se um arquivo é
malicioso ou benigno. Assim, para avaliar a precisão dos feeds, usamos
duas métricas: uma verificação de hashes maliciosos contra o VirusTotal e
uma verificação de hashes benignos contra o serviço Bin Check do
Shadowserver. Observe que todas as porcentagens discutidas abaixo são
baseadas no Volume de cada feed.
4.3.1 VirusTotal
VirusTotal é um serviço frequentemente usado ao analisar malware
para obter uma base de informações sobre um arquivo suspeito.
Qualquer pessoa pode enviar um arquivo a ser verificado. Após o
envio, esses arquivos serão verificados por mais de 70 antivírus, o
que gera um relatório sobre quantos antivírus marcam como
malicioso, entre outras informações. Nesta análise, consultamos o
VirusTotal quanto aos hashes em cada feed de hash de arquivo e, em
seguida, inspecionamos a porcentagem de hashes marcados como
maliciosos e quantos scanners AV os gravaram. Devido ao alto
volume do feed de malware do FB e ao limite da taxa de consulta do
VirusTotal, amostramos aleatoriamente 80.000 hashes do
Mesa 3 mostra uma análise das taxas de detecção básicas para cada
feed do VirusTotal. À medida que as alimentações de PA diminuem em
volume, as taxas nas quais são encontradas no VirusTotal também
diminuem. Os feeds PA maiores têm uma taxa de detecção muito mais
alta do que suas contrapartes menores. Por outro lado, o FB Malware tem
apenas 37% de seus dados detectados por scanners antivírus e 50% no
VirusTotal sem detecção, apesar de ser o maior feed. Isso pode indicar
que o FB Malware se concentra em ameaças que visam especificamente o
Facebook e que não são tão relevantes para a maioria dos usuários do
VirusTotal, como extensões de navegador maliciosas [ 14 , 20 , 22 ] Isso
pode prejudicar a cobertura limitada do VirusTotal como um oráculo para
detectar ameaças direcionadas que não são de interesse mais amplo.
Para entender melhor como os scanners do VirusTotal relatam os
dados do feed, traçamos um gráfico de qual porcentagem de hashes em
cada feed são detectados por quantos scanners do VirusTotal. Como
pode ser visto na Figura 4 , quatro feeds têm mais de 50% de suas
amostras detectadas por mais de 20 scanners. Indicadores PAMalware e
PA Twitter Emotet não experimentaram uma grande queda de detecção
antes de 35 scanners, indicando que a maioria dos indicadores no

Associação USENIX 28º Simpósio de Segurança USENIX 861


dois feeds são arquivos maliciosos populares reconhecidos por muitos
fornecedores de AV. Embora o PA Sandbox tenha uma grande porcentagem de
seus hashes não apresentados no VirusTotal, mais de 70% das amostras
detectadas são marcadas por mais de 20 scanners AV, apresentando uma
Tabela 4. Mudanças de dados em feeds de IP em comparação com os de 2016, Média
Avaliar mostra a porcentagem da taxa diária alterada nos feeds antigos. As duas
colunas sob Unrt mostram as taxas irreversíveis de feeds em 2016 e 2018
separadamente. As duas colunas sob CDN apresentam a queda do número de IPs nas
faixas de IP do CDN em dados antigos e novos.

detecção de alta confiança.

Irreversível CDN
4.3.2 Shadowserver
Alimentação Média Avaliar 2016 2018 2016 2018
Para avaliar mais completamente a precisão dos feeds de hash do Scan Feeds
arquivo, também examinamos como cada feed é medido em relação IPs PA AlienVault + 1.347% 0,0% 0,0% 0 0
PA Packetmail ram * + 733% <0,01% <0,01% 0 0
ao Serviço de verificação de bin do Shadowserver [ 34 ] O serviço IPs do Packetmail + 135% 0,0% 0,0% 0 0
verifica os hashes do arquivo na Lista de Registro Nacional de Reputação de IP paga - 57% 8,73% 1,65% 910 21
PA Lab Scan - 1% 0,0% <0,01% 0 0
Software (NSRL) do NIST, além do próprio repositório de software PA Snort BlockList - 97% <0,01% 0,42% 1 0
conhecido do Shadowserver. Mesa 3 detalha como cada feed se Agregador FB 1 + 332% 0,0% 0,0% 6 0
Analista PA - 44% 0,0% 0,41% 0 0
compara ao serviço Bin Check do Shadowserver. Feeds de botnet
Pode-se esperar que nenhum hash seja encontrado no serviço Bin PA CI Exército + 114% <0,01% <0,01% 0 0
Reputação de IP paga - 39% 0,63% 1,66% 15 74
Check do Shadowserver, mas não é o caso. Algumas das amostras IPs PA Botscout + 1% 0,01% 0,09% 1 0
dos feeds que aparecem no Shadowserver são binários bem PA VoIP Blacklist + 252% 0,0% 0,32% 0 0
IPs comprometidos de PA - 36% 0,10% 0,0% 0 0
conhecidos, como versões de produtos do Microsoft Office, Service Bots da lista de bloqueio PA - 95% 0,0% 0,0% 0 0
Packs do Windows, calc.exe, etc. No caso de malware se injetar em Projeto Honeypot PA + 63% 0,0% 0,0% 0 0
Feeds de força bruta
um processo em execução, continua plausível que alguns desses Badips SSH + 30% 0,07% 0,19% 0 1
binários bem conhecidos encontram seu caminho para TI feeds de Badips Badbots + 1.732% 0,0% 1,04% 187 1.251
Reputação de IP paga - 62% 6,55% 0,03% 335 10
usuários atribuindo mal-intencionado incorretamente. Embora o FB PA Brute-Force - 72% 0,0% 0,0% 0 0
Malware tenha mais de mil hashes no Shadowserver, este não é um Nome de usuário do Badips * + 3.040% 0,0% 0,53% 0 0
Haley SSH + 428% 0,04% 0,03% 0 0
problema generalizado, já que todos os feeds têm <1% de seus Agregador FB 2 + 387% 0,12% 0,0% 0 0
hashes contidos no serviço Bin Check do Shadowserver. Isso mostra Nothink SSH + 886% 0,56% 1,51% 0 0
Dangerrulez Brute + 0% 0,0% 0,0% 1 0
que, embora haja algumas exceções, a maioria dos feeds não Feeds de malware
contém arquivos benignos bem conhecidos. Reputação de IP paga - 36% 0,18% 0,13% 15265 3.489
IPs maliciosos do FB - 77% 6,81% 2,14% 264 0
F Encontrando: Cada feed de PA tem uma taxa insignificante de ocorrência no
Feodo IP Blacklist + 0% 0,0% 0,0% 0 0
Shadowserver, independentemente da detecção do VirusTotal, mostrando que eles Lista negra de IP Malc0de - 9% 0,0% 0,0% 132 11
PA Bambenek C2 IPs PA + 79% 0,0% 9,13% 0 0
não contêm falsos positivos genéricos. Feeds maiores exibem altas taxas de detecção
SSL Malware IPs - 34% 0,0% 0,0% 0 0
do VirusTotal, exceto para FB Malware, enquanto feeds pequenos têm taxas de Analista de PA - 93% 0,34% 0,0% 0 0
PA Abuse.ch * - 99% 0,49% 3,12% 0 0
detecção relativamente baixas. Isso sugere que pequenos feeds de hash podem se
PA Mal-Traf fi c-Anal - 53% 0,0% 0,51% 0 0
concentrar mais em arquivos maliciosos específicos que não são amplamente Zeus IP Blacklist - 66% 0,0% 0,0% 6 0
Explorar feeds
conhecidos. O FB Malware tem uma baixa ocorrência de VirusTotal apesar de seu
HTTP Badips + 326% 0,30% 0,67% 436 2.590
tamanho e tem mais de mil hashes no Shadowserver, mas sua baixa porcentagem FTP da Badips + 556% 0,01% 1,33% 0 2
DNS da Badips + 9.525% 0,17% 0,50% 7 244
geral de hashes no Shadowserver indica que ele não contém muitos arquivos
Badips RFI + 226% 0,0% 2,22% 0 0
conhecidos e pode ter ameaças não normalmente reconhecidas pelos scanners do Feeds de spam
Reputação de IP paga + 133% 59,3% 78,7% 0 0
VirusTotal.
Badips Spam + 12.767% 0,0% 0,02% 0 0
Badips Post fi xo - 53% <0,01% 1,29% 0 1
IPs PA Botscout + 18% 0,0% 0,06% 0 0
AlienVault IP Rep + 8% 0,57% 0,07% 479 1.040

5 Comparação Longitudinal
Além do período de medição considerado até agora (1 de
dezembro de 2017 a 20 de julho de 2018), também analisamos
dados dos mesmos feeds de IP de 1 de janeiro de 2016 a 31 de
agosto de 2016. Esses dois períodos de medição, 23 meses à
parte, nos permitem medir como esses feeds de IP mudaram
em dois anos. Mesa 4 resume as diferenças entre esses dois
períodos de medição. Na mesa, 2018 representa o período de
medição atual e 2016 o período de 1º de janeiro de 2016 a 31 de
agosto de 2016.
Volume. Conforme mostrado na Tabela 4 , o volume da ração definitivamente mudou
após dois anos. Entre 43 feeds IP que se sobrepõem aos dois períodos de tempo, 21
têm uma taxa diária mais alta em comparação com 2 anos atrás, 15 feeds têm uma
taxa mais baixa e 7 feeds não
mude substancialmente (a diferença é inferior a 20%). O volume
pode mudar drasticamente com o tempo, como IPs do PA AlienVault
na categoria de varredura, que é 13 vezes maior do que antes. Por
outro lado, um feed como PA Blocklist Bots agora é 90% menor.
Cruzamento e contribuição exclusiva. Apesar do vol-
Algumas diferenças, as estatísticas de interseção entre os feeds são
basicamente as mesmas ao longo de dois anos, com feeds em varredura
e força bruta tendo interseções de pares elevados e feeds em outras
categorias sendo principalmente exclusivos. Certas relações de pares
específicas também não mudaram. Por exemplo, Badips SSH ainda
compartilhou mais de 90% dos dados em Dangerrulez Brute em

862 28º Simpósio de Segurança USENIX Associação USENIX

2016, e Paid IP Reputation em malware ainda era o único feed que tinha
uma interseção não trivial com vários pequenos feeds. Novamente, a
maioria dos dados era exclusiva para cada feed há dois anos: Em todas as
seis categorias, mais de 90% dos indicadores não são compartilhados
entre os feeds.
Latência. A relação de latência entre os feeds também era
semelhante: os feeds oportunos de hoje também eram oportunos
há dois anos, e o mesmo com os atrasos.
Precisão. Os feeds têm mais IPs que não podem ser roteados agora do
que antes, conforme mostrado na Tabela 4 : Em 2016, 22 dos 43 feeds de
IP tinham pelo menos 1 IP irrotável; quatro feeds tiveram taxas
irreversíveis acima de 1%. Ao verificar a interseção com CDNs populares,
os feeds que contêm IPs nas faixas de CDN de dois anos atrás também
são os que possuem esses IPs hoje.
Indicadores compartilhados 2016–2018. Comparamos os dados que
coletados de cada feed nos dois períodos de tempo e descobriram que 30 de 43 feeds
em 2018 se cruzam com seus dados de dois anos atrás, e 9 feeds têm uma taxa de
interseção de mais de 10%. Três feeds na categoria de malware, nomeadamente
Feodo IP Blacklist, PA Abuse.ch Ransomware e Zeus IP Blacklist, têm mais de 40% de
seus dados compartilhados com o feed anterior, o que significa que uma grande
porcentagem dos indicadores C&C de dois anos atrás ainda são identificados pelos
feeds como ameaças hoje. Os feeds na categoria botnet, no entanto, são muito
distintos do passado, com todos os feeds não tendo nenhuma interseção com o
passado, exceto reputação de IP pago.
6 Latência Absoluta
Definimos nossa métrica de latência neste artigo como latência
relativa entre TI fontes, uma vez que é fácil de calcular e permite aos
consumidores comparar os feeds entre si neste aspecto. No entanto,
também é fundamental saber sobre a distribuição de latência
absoluta dos indicadores. A latência absoluta representa a rapidez
com que um feed pode realmente relatar uma ameaça, o que decide
diretamente a eficácia dos dados quando usados de forma
pró-ativa. Como já discutimos na Seção 3,5 , a latência absoluta é
difícil de medir, pois não temos informações básicas sobre a ameaça
subjacente.
Na seção 3,7 , usamos um telescópio de Internet como nosso aproxi-
mação para informações básicas para medir a cobertura de feeds de
varredura. Na seção 4,3 , usamos o VirusTotal como um oráculo para
medir a precisão dos feeds de hash de arquivo. Embora essas fontes não
sejam verdadeiras e não esteja claro a que distância estão, essas fontes
grandes e bem gerenciadas podem nos ajudar, até certo ponto, a traçar o
perfil do desempenho de TI feeds. Nesta seção, usamos essas duas fontes
novamente para aproximar a latência absoluta dos indicadores em feeds
de IP de varredura e feeds de hash de arquivo malicioso.
Mais especificamente, medimos a latência de IPs em feeds de
varredura em relação ao tempo da primeira ocorrência do mesmo IP nos
scanners coletados do telescópio. Considerando o tamanho maciço do
telescópio, ele presumivelmente deve detectar scanners muito antes do
evento de varredura realmente acontecer. Medimos a latência dos hashes
de arquivo em relação ao visto pela primeira vez
timestamps consultados no VirusTotal. O visto pela primeira vez vezes-
Associação USENIX
Analista PA
IPs PA AlienVault
IPs DShield
IPs do Packetmail
PA Packetmail ram *
PA Lab Scan
FB Aggregator_1
Reputação de IP paga
- 2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Latência (dias)
(uma) Distribuição de latência nos feeds de varredura em relação ao telescópio da Internet
PA OSINT
Analista PA
PA Twitter Emotet
PA Sandbox
Indicadores de malware PA
Malware FB
−50 0 50 100 150 200 250 300 350 400 450
Latência (dias)
(b) Distribuição de latência em feeds de hash de arquivo em relação ao VirusTotal
Figura 5. Distribuição da latência dos indicadores em varreduras e feeds de hash de arquivo. Observe
que a distribuição dos feeds de varredura é calculada na granularidade por hora, enquanto a
distribuição dos feeds de hash do arquivo é calculada na granularidade por dia.
tamp representa a hora em que o arquivo correspondente é carregado pela
primeira vez no VirusTotal. O VirusTotal é um serviço muito popular e é uma
convenção para muitos especialistas em segurança carregar novas amostras de
malware para o VirusTotal assim que as descobrem. Portanto, esse carimbo de
data / hora indica aproximadamente quando a comunidade de segurança
percebeu pela primeira vez o arquivo malicioso e pode ser uma boa
aproximação para latência absoluta.
Figura 5 mostram a distribuição de latência de cada feed, usando
a mesma convenção de plotagem da Seção 3,5 . Alguns feeds não
são mostrados na figura, pois há poucos pontos de dados nesses
feeds para raciocinar sobre a distribuição.
F Encontrando: Figura Comparando 5a descobrir 2a , podemos ver que a
latência mediana dos feeds é maior. Isso é consistente com nossa
suposição de que um grande sensor tende a receber scanners
indiscriminados mais cedo. A latência média dos feeds de varredura é de
um a três dias em relação ao telescópio da Internet, exceto PA Analyst,
cuja latência média é de quase nove dias. A ordem da latência mediana
entre os feeds mudou em comparação com a Figura 2a , mas como as
latências medianas relativas originais entre os feeds de varredura são
muito próximas, a nova ordem aqui é mais provável de ser as variações
estatísticas. Além disso, observe que embora os IPs do PA AlienVault
pareçam muito mais lentos do que na Figura 2a , sua latência de 75
percentil ainda é a segunda menor.
Por outro lado, as distribuições de latência de feeds hash variam
de forma mais dramática. PA Malware Indicators, PA Sandbox e PA
Twitter Emotet são quase tão rápidos quanto VirusTotal: todos os
três feeds têm 25 percentil e latência mediana igual a
28º Simpósio de Segurança USENIX 863
zero. PA OSINT e PA Analyst são comparativamente muito mais
lentos, e PA OSINT ainda tem uma latência de 75 por cento de 1.680
dias. Isso pode ser devido à natureza heterogênea dos feeds de
malware. A figura também mostra que os volumes de feed não
implicam em sua latência, pois o PA Analyst e o FB Malware são
muito mais lentos do que os pequenos feeds de hash.
Figura 5 demonstra que o telescópio da Internet e o Virus-Total são de fato
boas aproximações para medição de latência absoluta, como a maioria dos
indicadores em TI os feeds são observados relativamente mais tarde. No
entanto, cada feed de digitalização tem mais de 2% de seu índice
cators detectados antes do telescópio. Agregador FB 1
e DShield IPs ainda têm mais de 10% de seus indicadores ob-
servido antes. Também há um caso semelhante em feeds de hash de arquivo.
Isso se alinha com a nossa observação na Seção 3,5 que pequenos feeds ainda
podem relatar uma quantidade não trivial de seus dados primeiro. Outra
observação interessante é que ambos os feeds do Facebook,
Agregador FB 1 e FB Malware, têm uma grande porcentagem de seus
dados observados antes do telescópio ou do VirusTotal.
Isso sugere novamente que o Facebook (e seus parceiros de inteligência de ameaças)
pode enfrentar ameaças mais direcionadas, portanto, essas ameaças serão
observadas pela primeira vez pelo Facebook.
7 discussão
7.1 Uso de métricas
A inteligência contra ameaças tem muitos usos potenciais diferentes. Por
exemplo, os analistas podem consumir dados de ameaças interativamente
durante as investigações manuais de incidentes ou podem usá-los para
automatizar a detecção de atividades suspeitas e / ou listas negras. Quando
não são determinantes, essas informações também podem ser usadas para
enriquecer outras fontes de dados, informando investigações ou
auxiliando em intervenções algorítmicas automáticas. Introduzimos um
conjunto de métricas básicas de inteligência de ameaças - volume,
interseção, contribuição exclusiva, latência, cobertura e precisão - que
podem informar e quantificar cada um desses usos. Dependendo de uma
série de fatores, como o caso de uso pretendido e o custo de falsos
positivos e negativos, algumas dessas métricas se tornarão mais ou
menos importantes ao avaliar um TI fonte. Por exemplo, um feed com
baixa precisão, mas alta cobertura pode ser ideal quando um analista
está usando um TI fonte interativamente durante as investigações de
incidentes manualmente (já que, neste caso, o analista, como um
especialista de domínio, pode fornecer filtragem adicional de falsos
positivos). Da mesma forma, a latência pode não ser uma métrica crítica
em um caso de uso retrospectivo (por exemplo, investigação de violação
pós-descoberta). No entanto, se uma organização está procurando um TI fonte inteligência de ameaças afeta seus principais indicadores de
em que os IPs devem ser adicionados à lista negra de um firewall, então a
precisão e a latência provavelmente devem ser ponderadas sobre a
cobertura, presumindo que o bloqueio de atividades benignas seja mais
caro.
Outro cenário comum do mundo real é que uma empresa tem um
orçamento limitado para comprar TI fontes e tem um conjunto específico
de ameaças (ou seja, botnet, força bruta) que eles se concentram em
mitigar. Nesses casos, as métricas que descrevemos podem ser usadas
diretamente na avaliação TI opções, polarizando twoards
864 28º Simpósio de Segurança USENIX
fontes que maximizam a cobertura das ameaças mais relevantes
enquanto limitam a interseção.
7.2 Rotulagem de Dados
Os dados de inteligência de ameaças IP têm significados diferentes. Para
usar adequadamente esses dados, é fundamental saber o que os
indicadores realmente significam: se são scanners da Internet, membros
de um botnet ou agentes mal-intencionados que já atacaram outros
lugares antes. Tentamos agrupar feeds por seu significado pretendido
em nossa análise.
No entanto, esta informação de categoria, que vem principalmente de TI fontes
próprias, nem sempre está disponível. Feeds como Alienvault IP Reputation e
Facebook Threat Exchange fontes contêm um número significativo de
indicadores rotulados como “Malicioso” ou “Suspeito”. Os significados desses
indicadores não são claros, tornando difícil para os consumidores decidirem
como usar os dados e as possíveis consequências.
Para feeds que fornecem informações de categoria, às vezes é muito amplo
para ser significativo. Por exemplo, vários feeds em nossa coleção
simplesmente rotulam seus indicadores como “Scanner”. A varredura de rede
pode representar a varredura de porta (enviando pacotes SYN) ou uma
varredura de vulnerabilidade (investigando o host em busca de
vulnerabilidades conhecidas). A ambigüidade aqui, como resultado da
rotulagem de dados ad-hoc, novamente apresenta desafios para os
especialistas em segurança ao usar TI dados.
Recentemente, padrão TI formatos foram propostos e desenvolvidos,
notavelmente IODEF [ 19 ], CybOX [ 13 ] e STIX [ 37 ], que tentam padronizar
a apresentação e o compartilhamento de informações sobre ameaças.
Mas esses padrões se concentram principalmente no formato de dados.
Há espaço para melhorar esses padrões, projetando um padrão semântica
para dados de inteligência de ameaças.
7.3 Limitações
Existem várias questões que nosso estudo não aborda. Tentamos
coletar dados de um conjunto diversificado de fontes, incluindo
feeds públicos, feeds comerciais e feeds de intercâmbio industrial,
mas não é inerentemente abrangente. Existem algumas fontes de
dados proibitivamente caras ou com restrição de publicação que não
estão disponíveis para nós. Um trabalho de medição mais
especializado deve ser feito no futuro para analisar melhor o
desempenho dessas fontes de dados caras e exclusivas.
Uma segunda limitação é nossa visibilidade de como diferentes
empresas usam a inteligência de ameaças operacionalmente. Para uma
empresa, talvez o tipo de métrica mais útil mede como uma fonte de
desempenho, bem como sua exposição ao risco. Essas métricas exigiriam
uma integração profunda nos fluxos de trabalho de segurança nas
empresas para medir o efeito da operação de decisões tomadas usando
inteligência de ameaças. Isso permitiria aos CIOs e CSOs entender melhor
exatamente o que um produto de inteligência de ameaças específico
contribui para uma empresa. Como pesquisadores, não usamos TI
operacionalmente. Um melhor entendimento das necessidades operacionais ajudaria
a refinar nossas métricas para maximizar sua utilidade para os consumidores
orientados para as operações.
Associação USENIX
 A terceira limitação é a falta de verdade fundamental, uma
limitação compartilhada por todos os trabalhos de medição
semelhantes. É simplesmente muito difícil obter o quadro completo
de uma determinada categoria de ameaça, tornando muito difícil
determinar com precisão a precisão e a cobertura dos feeds. Neste
estudo, usamos dados de um telescópio da Internet e do VirusTotal
como uma aproximação próxima. Existem também alguns casos em
que um incidente de segurança foi exaustivamente estudado por
pesquisadores, como o estudo Mirai [ 4 ], e tais esforços podem ser
usados para avaliar certos tipos de TI dados. Mas esses estudos são
poucos. Uma alternativa é tentar estabelecer a verdade fundamental
para uma rede específica. Por exemplo, uma empresa pode registrar
todo o tráfego de rede que entra e sai de sua própria rede e
identificar incidentes de segurança por meio de seu sistema IDS ou
análise forense manual. Em seguida, ele pode avaliar a precisão e
cobertura de um TI feed no contexto de sua própria rede. Isso pode
fornecer uma visão personalizada de TI feeds.
8 trabalhos relacionados
Vários estudos examinaram a eficácia da inteligência de ameaças
baseada em listas negras [ 23 , 31 , 32 , 35 , 36 ] Ramachandran et al. [ 32 ]
mostraram que as listas negras de spam estão incompletas (faltando 35%
dos IPs de origem dos emails de spam capturados em duas armadilhas
de spam) e lentas na resposta (20% dos spammers permanecem não
listados após 30 dias). Sinha et al. [ 36 ] con fi rmou ainda mais esse
resultado, mostrando que quatro das principais listas negras de spam
têm taxas de falsos negativos muito altas e analisaram as possíveis
causas da baixa cobertura. Sheng et al. [ 35 ] estudou a eficácia das listas
negras de phishing, mostrando que as listas demoram a reagir a
campanhas de phishing altamente transitórias. Esses estudos se
concentraram em tipos específicos de fontes de inteligência de ameaças e
avaliaram apenas seu desempenho operacional, em vez de produzir
métricas de avaliação empíricas para fontes de dados de inteligência de
ameaças.
Outros estudos analisaram os atributos gerais dos dados de
inteligência de ameaças. Pitsillidis et al. [ 30 ] estudou as características dos
feeds de domínio de spam, mostrando diferentes perspectivas dos feeds
de spam, e demonstrou que diferentes feeds são adequados para
responder a diferentes perguntas. Thomas et al. [ 42 ] construíram sua
própria inteligência de ameaças agregando o tráfego de abuso recebido
de seis serviços do Google, mostrando uma falta de interseção e
correlação entre essas diferentes fontes. Embora se concentrem em usos
mais amplos de inteligência de ameaças, esses estudos não se
concentraram em métricas de ameaças generalizáveis que podem ser
estendidas além do trabalho.
Existem poucos trabalhos que definem uma metodologia geral de medição para
examinar a inteligência de ameaças em um amplo conjunto de tipos e categorias.
Metcalf et al. [ 26 ] coletou e mediu listas negras de IP e domínio de várias fontes, mas
focou apenas na análise de volume e interseção. Em contraste, definimos
formalmente um conjunto de métricas de inteligência de ameaças e conduzimos um
estudo amplo e abrangente sobre uma ampla variedade de dados de inteligência de
ameaças. Conduzimos nossa medição a partir da perspectiva dos consumidores de TI dados
para oferecer
Associação USENIX
orientação sobre como escolher entre as diferentes fontes. Nosso estudo
também demonstrou a limitação da inteligência de ameaças de forma mais
completa, fornecendo características abrangentes de inteligência de ameaças
cibernéticas que nenhum trabalho havia abordado anteriormente.
9 Conclusão
Este documento enfocou as métricas mais simples, porém fundamentais, sobre
dados de inteligência de ameaças. Usando as métricas propostas, medimos um
amplo conjunto de TI fontes, e relatou as características e limitações de TI dados.
Além das descobertas individuais mencionadas em cada seção, aqui
destacamos as lições de alto nível que aprendemos com nosso estudo:
• TI os feeds, longe de conterem amostras homogêneas de alguma
verdade subjacente, variam enormemente nos tipos de dados que
capturam com base nas particularidades de sua abordagem de
coleta. Infelizmente poucos TI fornecedores explicam o mecanismo e
a metodologia pelos quais seus dados são coletados e, portanto, TI os
consumidores devem se contentar com rótulos simples como
“scan” ou “botnet”, juntamente com inferências sobre o modo
provável de coleta. Pior ainda, uma quantidade significativa de
dados nem mesmo tem uma definição clara de categoria, e é
rotulada apenas como “maliciosa” ou “suspeita”, deixando a
ambigüidade para os consumidores decidirem qual ação deve ser
tomada com base nos dados.
• Há pouca evidência de que feeds maiores contenham dados melhores, ou
mesmo que existam distinções de qualidade nítidas entre feeds em
diferentes categorias ou métricas (ou seja, que um TI provedor cujo feed
tem um bom desempenho em uma métrica terá um bom desempenho
em outra, ou que essas classificações se manterão em todas as
categorias de ameaça). A forma como os dados são coletados também
não implica necessariamente os atributos dos feeds. Por exemplo, feeds
baseados em crowdsourcing (por exemplo, feeds Badips) nem sempre
são mais lentos no relatório de dados do que os feeds de auto-coleta
(como Reputação de IP pago).
• Mais baseado em IP TI as fontes de dados são coleções de toneladas
individuais (ou seja, cada endereço IP aparece em no máximo uma
fonte) e mesmo as fontes de dados de correlação mais alta
freqüentemente têm taxas de interseção de apenas 10%. Além
disso, ao comparar dados de sensores amplos em categorias
conhecidas com efeito amplo (por exemplo, varredura aleatória),
menos de 2% dos endereços de scanner observados aparecem na
maioria das fontes de dados que analisamos; de fato, mesmo
quando focado nos maiores e mais prolí fi cos scanners, a
cobertura ainda é limitada a 10%. Existem resultados semelhantes
para fontes baseadas em hash de arquivo com pouca sobreposição
entre eles.
O baixo cruzamento e a cobertura de TI feeds podem ser o resultado
de várias possibilidades não exclusivas. A primeira é que o espaço
subjacente de indicadores (endereços IP e hashes de arquivos maliciosos)
é grande e cada fonte de dados individual pode, na melhor das hipóteses,
amostrar uma pequena fração dele. É quase certo que isso seja verdade
até certo ponto. Em segundo lugar, coleção diferente
28º Simpósio de Segurança USENIX 865
as metodologias - mesmo para a mesma categoria de ameaça - selecionarão
diferentes subdistribuições dos dados de verdade terrestre subjacentes.
Terceiro, esse último efeito provavelmente é exacerbado pelo fato de que nem
todas as ameaças são experimentadas de maneira uniforme na Internet e,
portanto, diferentes metodologias serão distorcidas para favorecer ou
desfavorecer os ataques direcionados.
Com base em nossa experiência analisando TI dados, tentamos
fornecer várias recomendações para a comunidade de segurança
sobre este tópico no futuro:
• A comunidade de inteligência de ameaças deve padronizar a rotulagem
de dados, com uma definição clara do que os dados significam e como
os dados são coletados. Os especialistas em segurança podem avaliar se
os dados atendem às suas necessidades e o tipo de ação que deve ser
tomada com relação a esses dados.
• Existem algumas regras básicas na seleção entre TI feeds, visto que não há
uma correlação clara entre as diferentes propriedades dos alimentos. Os
consumidores precisam de métricas empíricas, como as que
descrevemos, para diferenciar significativamente as fontes de dados e
priorizar certas métricas com base em suas necessidades específicas.
• Cegamente usando TI os dados - mesmo que alguém pudesse
adquirir muitas dessas fontes - provavelmente não fornecerão uma
cobertura melhor e também estão sujeitos a danos colaterais
causados por falsos positivos. Os clientes precisam estar sempre
cientes dessas questões ao decidir que ação deve ser realizada com
esses dados.
• Além de focar no TI dados em si, o trabalho futuro deve investigar os
usos operacionais da inteligência de ameaças na indústria, como o
verdadeiro valor de TI os dados só podem ser compreendidos em
cenários operacionais. Além disso, a comunidade deve explorar
mais maneiras potenciais de usar os dados, o que ampliará nossa
compreensão da inteligência de ameaças e também influenciará
como os fornecedores estão curando os dados e fornecendo os
serviços.
Existem muitas maneiras de usar os dados de inteligência de ameaças. Pode
ser usado para enriquecer outras informações (por exemplo, para investigar
possíveis explicações de um incidente de segurança), como um canário
probabilístico (ou seja, identificar uma vulnerabilidade geral do site por meio
de um único indicador de correspondência pode ter valor mesmo se outros
ataques do mesmo tipo não forem detectados) ou no fornecimento de uma
fonte útil de dados verdadeiros para sistemas supervisionados de aprendizado
de máquina. No entanto, mesmo com finalidades tão diversas, as organizações
ainda precisam de alguma forma de priorizar quais TI fontes para investir.
Nossas métricas fornecem alguma direção para essas escolhas. Por exemplo,
um analista que espera usar TI interativamente durante a resposta a incidentes
seria melhor atendido por feeds com cobertura mais alta, mas pode acomodar
baixa precisão, enquanto uma organização que tenta rotular automaticamente
instâncias maliciosas para fins de treinamento (por exemplo, ataques de força
bruta) será melhor atendido pelo contrário. Assim, se houver esperança de
demonstrar que a inteligência de ameaças pode impactar materialmente
866 28º Simpósio de Segurança USENIX
práticas de segurança operacional, acreditamos que serão
encontradas nesses casos de uso mais complexos e é aí que as
pesquisas futuras serão mais produtivas.
10 Reconhecimento
Gostaríamos de agradecer aos nossos provedores de ameaças
comerciais que disponibilizaram seus dados para nós e tornaram
essa pesquisa possível. Em particular, gostaríamos de agradecer a
Nektarios Leontiadis e o Facebook ThreatExchange por fornecer os
dados de ameaças que ajudaram a facilitar nosso estudo. Também
somos muito gratos a Alberto Dainotti e Alistair King por
compartilhar os dados do telescópio UCSD e nos ajudar com a
análise, Gautam Akiwate por nos ajudar a consultar os dados do
domínio e Matt Jonkman. Também somos gratos a Martina
Lindorfer, nosso pastor, e aos nossos revisores anônimos por seus
comentários e sugestões perspicazes. Esta pesquisa é um trabalho
conjunto de várias instituições, patrocinado em parte pelo prêmio
DHS / AFRL FA8750-18-2-0087, NSF concede CNS-1237265,
CNS-1406041, CNS-1629973, CNS-1705050 e CNS-1717062.
Referências
[1] Abuse.ch. https://abuse.ch/ .
[2] Principais domínios Alexa. https://www.alexa.com/
melhores sites/ .
http: // reputação.
[3] Reputação de IP da Alienvault.
alienvault.com/reputation.data .
[4] A NTONAKAKIS, M., A PRIL, TB AILEY, M., B ERN-
DURO, M., B URSZTEIN, E., C OCHRAN, J., D URUMÉRICO, Z., H VEREADOR,
JA, eu NVERNIZZI, EU.,
K ALLITSIS, M., ET AL. Compreendendo o botnet mirai. Dentro Simpósio
de Segurança USENIX ( 2017).
[5] Badips. https://www.badips.com/ .
[6] B ENSON, K., D AINOTTI, COMO NOEREN, AC, K ALLITSIS, M., ET AL. Aproveitando
a Internet de volta
radiação terrestre para análise de rede oportunista. Dentro
Procedimentos da Conferência de Medição da Internet de
2015 ( 2015), ACM.
[7] O monitor de segurança de rede Bro. https: //www.bro.
org / index.html .
[8] Lista composta de bloqueio. https: //www.abuseat.
org / .
[9] Espalhando a doença e vendendo a cura.
https://krebsonsecurity.com/2015/01/
espalhando-a-doença-e-vendendo-a-cura / .
[10] C HACHRA, N., M C C OY, D., S AVAGE, S., E
V OELKER, GM caracterizando empiricamente o abuso de
domínio e o impacto da lista negra na receita. Dentro
Anais do Workshop sobre Economia da Segurança da
Informação (WEIS) ( State College, PA, 2014). [11] Cloud fl
are, rede de entrega de conteúdo global rápida. https:
//www.cloudflare.com/cdn/ .
[12] AWS CloudFront, rápido, altamente seguro e programável
rede de distribuição de conteúdo. https://aws.amazon.com/
cloudfront / .
Associação USENIX
[13] Ciber observável expressão. http:
ACM.
//cyboxproject.github.io/documentation/ .
[30] P ITSILLIDIS, A., K ANICH, CV OELKER, GM,
[14] D E K FORNO, LF, S AVAGE, S., V OELKER, GM, E
eu EVCHENKO, K., E S AVAGE, Escolha de S. Taster: Uma Análise
eu EONTIADIS, N. Extensões de navegador mal-intencionadas em
Comparativa de Spam Feeds. Dentro Proceedings of the ACM
escala: Reduzindo a lacuna de observabilidade entre o site e o
Internet Measurement Conference ( Boston, MA, novembro de
navegador. Dentro 10º Workshop USENIX sobre Experimentação e
2012), pp. 427–440.
Teste de Segurança Cibernética (CSET 17) ( 2017), USENIX.
[31] R AMACHANDRAN, A., F EAMSTER, WL AGON, D.,
[15] D URUMÉRICO, Z., B AILEY, M., E H VEREADOR,
ET AL. Revelando a associação de botnet usando
JA Uma visão de digitalização em toda a Internet em toda a Internet.
contra-inteligência dnsbl. SRUTI 6 ( 2006).
Dentro Simpósio de Segurança USENIX ( 2014).
[32] R AMACHANDRAN, A., F EAMSTER, N., E V EM-
[16] Edgecast CDN, Verizon digital and media server
PALA, S. Filtragem de spam com lista negra comportamental. Dentro
vícios. https://www.verizondigitalmedia.com/
Procedimentos da 14ª Conferência ACM sobre Segurança de
plataforma / edgecast-cdn / .
Computadores e Comunicações (CCS) ( 2007).
[17] Troca de ameaças do Facebook. https: // developers.
[33] S CHEITLE, Q., H OHLFELD, O., G AMBA, J., J EL-
facebook.com/programs/threatexchange .
DEZ, J., Z IMMERMANN, T., S TROWES, SD, E
[18] CDN gerenciado rapidamente. https://www.fastly.com/
V ALLINA- R ODRIGUEZ, N. Um longo caminho para o topo: Sig- ni fi cância,
produtos / cdn de gerenciamento rápido .
estrutura e estabilidade das listas principais da Internet. Dentro
[19] Formato de troca da descrição do objeto do incidente. https:
Procedimentos da Conferência de Medição da Internet
//tools.ietf.org/html/rfc5070 .
(2018), ACM.
[20] J AGPAL, WL INGLE, POR EXEMPLO RAVEL, J.-P., M AVROM-
[34] Shadowserver. https://www.shadowserver.org/ .
MATIS, P., P ROVOS, N., R AJAB, MA, E T HOMAS,
[35] S HENG, S., W ARDMAN, B., W ARNER, G., C RANOR,
K. Tendências e lições de três anos lutando contra extensões maliciosas.
LF, H ONG, J., E Z PENDURAR, C. Uma análise empírica de listas
Dentro Simpósio de Segurança USENIX
negras de phishing. Dentro Anais da Conferência sobre
(2015).
Email e Anti-Spam (CEAS) ( 2009).
[21] J UNG, J., E S ISTO, E. Um estudo empírico do tráfego de spam e
[36] S INHA, S., B AILEY, M., E J AHANIAN, F. Tons de cinza: Sobre a
o uso de listas negras de DNS. Dentro Proceedings of the
eficácia das “listas negras” baseadas na reputação.
ACM Conference on Internet Measurement ( 2004).
Dentro 2008 3ª Conferência Internacional sobre Software
[22] K APRAVELOS, A., G RIER, C., C HACHRA, N.,
Malicioso e Indesejado (MALWARE), IEEE. [37] Structured
K RUEGEL, CV IGNA, G., E P AXSON, V. Hulk: provocando comportamento
Threat Information eXpression. https: //
malicioso em extensões de navegador. Dentro
stixproject.github.io/ .
Simpósio de Segurança USENIX ( 2014), San Diego, CA.
[38] Telescópio de rede UCSD. https://www.caida.org/
[23] K ÜHRER, SR OSSOW, C., E H OLZ, T. Pinte de preto: avaliando a
projetos / rede_telescópio / .
eficácia das listas negras de malware. Dentro Workshop
[39] O sistema de bloqueio de spam e retransmissão aberta. http: //
Internacional sobre Avanços Recentes na Detecção de
www.sorbs.net/ .
Intrusão ( 2014), Springer.
[40] A lista de bloqueio do Spamhaus. https: //www.spamhaus.
[24] L EVCHENKO, K., P ITSILLIDIS, A., C HACHRA, N., E N-
org / sbl / .
DIREITO, B., F ÉLEGYHÁZI, M., G RIER, CH ALVOR-
[41] O Spamhaus não faz roteamento ou listas de pares. https: //
FILHO, T., K ANICH, C., K REIBICH, C., L IU, H., M C-
www.spamhaus.org/drop/ .
C OY, D., W EAVER, N., P AXSON, V., V OELKER, GM,
[42] T HOMAS, K., A MIRA, R., B EN- Y OASH, A., F OLGER,
E S AVAGE, S. Clique em Trajetórias: Análise de ponta a ponta
OH ARDON, A., B ERGER, A., B URSZTEIN, E., E
da cadeia de valor do spam. Dentro Procedimentos do
B AILEY, M. A economia de compartilhamento de abuso:
Simpósio IEEE e Segurança e Privacidade ( 2011).
Compreendendo os limites das trocas de ameaças. Dentro Simpósio
[25] MaxCDN. https://www.maxcdn.com/one/ .
Internacional de Pesquisa em Ataques, Intrusões e Defesas
[26] M ETCALF, EU., E S PRING, Análise do ecossistema da JM Blacklist: período
(2016), Springer.
de janeiro de 2012 a junho de 2014. Em Procedimentos do 2º
[43] Análise de mercado de inteligência de ameaças por solução,
Workshop ACM sobre Compartilhamento de Informações e
por serviços, por implantação, por aplicativo e previsão
Segurança Colaborativa ( 2015), ACM.
de segmento, 2018 - 2025. https: // www.
[27] Nothink honeypot SSH. http://www.nothink.org/
grandviewresearch.com/industry-analysis/
honeypot_ssh.php .
mercado de inteligência de ameaças .
[28] Packetmail.net. https://www.packetmail.net/ .
[44] Projeto de vistas de rota da Universidade de Oregon. http: // www.
[29] P ANG, R., Y EGNESWARAN, V., B ARFORD, P., P MACHADO-
routeviews.org/routeviews/ .
FILHO, V., E P ETERSON, L.
Características da radiação de fundo
[45] VirusTotal. https://www.virustotal.com/#/
da Internet. Dentro Procedimentos da 4ª conferência ACM
home / upload .
SIGCOMM sobre medição na Internet ( 2004),

Associação USENIX 28º Simpósio de Segurança USENIX 867