See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/334466530

Método para Uso do SIEM como Ferramenta de Inteligência e Automação

Conference Paper · July 2019

CITATIONS READS
0 49

2 authors, including:

José Lopes Oliveira Jr.

Companhia Energética de Minas Gerais
7 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Centro de Operações de Rede e Segurança View project

All content following this page was uploaded by José Lopes Oliveira Jr. on 15 July 2019.

The user has requested enhancement of the downloaded file.

FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
Método para Uso do SIEM como Ferramenta de
Inteligência e Automação
José Lopes de Oliveira Júnior, Luiz Felipe Antunes Batista
Centro de Operações de Rede e Segurança
Companhia Energética de Minas Gerais (Cemig)
{joselopes, luiz.batista}@cemig.com.br
Resumo—Os sistemas de gestão de segurança e eventos (SIEM
—do inglês, Security Information and Event Management) estão
estabelecidos no mercado há mais de uma década, oferecendo
potencial para elevar o nı́vel de segurança das corporações e
ajudar na conformidade com normas. Contudo, não há um
guia amplamente usado que mostre como implantar e operar a
ferramenta para obter melhores resultados, exigindo criatividade
e experiência do time de segurança em um tipo de sistema
pouco conhecido. Este trabalho apresenta o método constituı́do
pela polı́tica de uso do SIEM e pelo processo de tratamento
dos dados recebidos, possibilitando a detecção de incidentes,
o monitoramento de segurança e a resolução de problemas a
partir de logs e netflows. São apresentados exemplos e casos
reais de aplicação do método, dentro do contexto da Companhia
Energética de Minas Gerais (Cemig), detalhando os ganhos
obtidos em cada etapa, além de perspectivas futuras.
Index Terms—segurança cibernética, siem, logs, netflows, sox,
scada, api, automação.
I. I NTRODUÇ ÃO
Como descrito por Zimmerman [1], sistemas de gestão
de segurança da informação e eventos —do inglês, Secu-
rity Information and Event Management (SIEM)—, foram
desenvolvidos para coletar, agregar, filtrar, armazenar, triar,
correlacionar e apresentar dados relevantes para a segurança,
o que os torna indicados para garantir conformidade com
normas. Nessa linha, em 2006, a Cemig adquiriu um SIEM
para auxiliar no cumprimento de controles da Lei Sarbanes-
Oxley (SOX), por ter ações negociadas nos Estados Unidos.
No ápice de utilização da ferramenta, ela recebia logs de cerca
de 50 servidores, mas as correlações se limitavam apenas a
eventos do Intrusion Prevention System (IPS) e do antivı́rus.
As regras eram bastante simples e consistiam apenas em gerar
incidentes se determinados logs fossem recebidos de uma
das duas origens, sem qualquer tipo de cruzamento de dados
entre eles. Uma vez gerado, o incidente era automaticamente
replicado, via integração, para o sistema de tickets usado
pela gestão de serviços da Superintendência de Tecnologia
da Informação e Telecomunicações (TI). Apesar de algumas
pesquisas predefinidas terem sido criadas, esse SIEM era usado
primariamente como um banco de dados de logs, que era
auditado periodicamente. Essa forma de utilização perdurou
por todo o tempo de vida da ferramenta, que finalizou em
2017, devido ao desenvolvedor tê-la descontinuado.
Isso obrigou a TI a adquirir outro sistema, mas desta
vez, foi comprada uma das soluções lı́deres no segmento,
com hardware e software mais robustos, além de funções
1
mais modernas. Apesar do escopo inicial do novo SIEM
ter sido apenas de substituir o anterior, sem prever novas
formas de utilização, assim que entrou em produção, o time
responsável por operar a ferramenta, o Centro de Operações de
Rede e Segurança (CORS), percebeu esse potencial, passando
a utilizá-la para automatizar algumas tarefas, normalmente
associadas a controles SOX, e para monitorar a segurança da
empresa. Com isso, a quantidade de origens de log no SIEM
quadruplicou em um ano.
Com o drástico aumento, não só de origens de log, mas
também de expectativas de auditores e gestores sobre a ferra-
menta, o CORS buscou formas de garantir a continuidade do
SIEM e das iniciativas de automação e monitoramento, além
de iniciar outras ações relacionadas à resolução de incidentes.
Logo nos estudos iniciais, foi percebido que faltavam critérios
para definição das origens de log e que as regras de correlação,
quando existiam, eram mal exploradas, gerando muitos falso-
positivos devido à má configuração. Além disso, como o
conceito era de encarar o sistema como um simples banco de
dados, as funções de monitoramento não eram usadas e havia
apenas uma integração criada, herança da solução anterior.
No macrocenário, a Cemig passava por uma grande
mudança, visando a melhoria de produtividade. Isso era des-
dobrado na TI através de reuniões periódicas de alinhamento e
sensibilização. Além de receber os impactos dessas diretrizes,
o CORS passava por profundas mudanças, fruto da sua recente
criação, a partir da fusão entre o Network Operation Center
(NOC) e o Security Operation Center (SOC). As novas
orientações da operação visavam mais alinhamento com as
expectativas da Cemig —e da TI—, mais documentação e mais
automação. Tudo para garantir a continuidade dos serviços
24x7, uma vez que a rede de dados é ponto-chave para
automação do setor elétrico e o CORS é responsável por boa
parte disso, includindo1 cerca de 3.000 ativos de rede, 8.000
clientes de antivı́rus, 49 firewalls2 , dentre outras ferramentas
de rede e segurança, mais 4 controles SOX diretos e 19
indiretos, sendo um deles, o mais crı́tico dentro do escopo
da TI.
Além disso, dada a evolução das áreas de automação do
sistema elétrico, redes baseadas no Internet Protocol (IP)
passaram a ser adotadas largamente em plantas industriais,
levando à criação de uma rede de dados de missão crı́tica.
1 Dados aproximados de junho de 2019.
2 Em junho de 2019 eram 7 e o restante estava previsto para implantação
até o final de 2020.
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
Muitos protocolos usados na automação do sistema elétrico
exigem dessa rede, alta disponibilidade e tendência ao de-
terminismo, algo não tão simples de se obter em soluções
baseadas em IP, segundo Stoufer [2]. Não obstante, devido à
evolução da automação, equipamentos e firmwares passaram a
se valer de vários recursos de TI, expondo ambientes crı́ticos a
vulnerabilidades comuns, amplamente discutidas em fóruns de
segurança da informação, mas agora com potencial de causar
blackouts e danos fı́sicos, como nos incidentes da Ucrânia [3] e
na Alemanha [4]. Isso aumenta consideravelmente a responsa-
bilidade do CORS, visto que incidentes que afetem os sistemas
e áreas de missão crı́tica tendem a ser catastróficos para a
empresa e, de forma ampla, para a sociedade e segurança
nacional.
Com base nesse cenário, foi criada dentro do CORS a
polı́tica e a metodologia para garantir um uso mais racional
do SIEM, visando aumentar a visibilidade da rede, melhorar
a detecção de incidentes e automatizar tarefas. A ideia era
de agregar dados dos sistemas mais crı́ticos da Cemig no
SIEM, através de logs ou netflows de rede, indexando os
campos mais relevantes, para serem usados em pesquisas,
monitoramento, regras de correlação ou serem enviados para
tratamento em outros sistemas. Este texto apresenta os pontos-
chave nesse processo, começando com a definição da polı́tica
de SIEM na seção II. Na seção III é introduzido o processo
de tratamento dos dados recebidos, com seus requisitos mais
básicos, seguidos dos resultados diretos que podem ser obtidos
deles: correlações —seção IV—, pesquisas —seção V— e
monitoramento —seção VI. Já na seção VII são apresentados
os benefı́cios e ideias para integração entre o SIEM e outros
sistemas, finalizando com as conclusões na seção VIII.
II. P OL ÍTICA
Frye [5] afirma que gerenciar logs muitas vezes é um
ideal quase impossı́vel de ser implementado em muitas
organizações, que raramente conseguem definir métodos para
entender e dissecar os dados. Com efeito, a mirı́ade de origens
de dados implica em um grande volume de informações no
SIEM, o que requer planejamento para definir claramente o
escopo de aplicação, além de padrões de extração de dados
para uso em correlações, pesquisas ou monitoramento. A
criação de uma polı́tica para o SIEM visa resolver problemas
como os apresentados, embasando a tomada de decisões, como
orientado por Swift [6], principalmente porque, segundo Frye
[5], há pouca orientação sobre o que deve ser mantido e como
definir boas fontes de dados. As subseções a seguir discorrem
sobre cada uma das partes sugeridas da polı́tica criada na
Cemig para orientar o uso do SIEM.
A. Cabeçalho
O cabeçalho é a seção mais simples e objetiva da polı́tica,
que trata de metadados do documento. Se bem organizado,
garante o entendimento geral sobre qual a versão mais nova
da polı́tica, os responsáveis pelo trabalho, e como o mesmo
evoluiu ao longo do tempo, além de deixar claro onde versões
mais recentes podem ser obtidas. Bons exemplos de campos
para compor o cabeçalho são:
2
• autores: lista de autores e colaboradores da versão;
• classificação: classificação da informação, como usado
na empresa —e.g., público, reservado ou confidencial;
• onde encontrar: onde está publicada a versão mais nova
do documento;
• data de publicação: a data em que a versão do docu-
mento foi publicada;
• versão: identificador da versão; e
• changelog: histórico de notas de alterações entre cada
versão.
B. Escopo
Definir claramente o escopo de cobertura do SIEM é
fundamental para fazer melhor uso da ferramenta, conforme
orientação de Swift [6]. Na mesma linha, Zimmerman [1]
afirma que devem ser retidos dados para suportar requisitos
criminais, civis e administrativos da companhia, mostrando
que ferramentas de segurança como firewalls, antispams e
proxies são bons candidatos para isso. Na mesma linha,
Knapp [7] mostra que ativos cibernéticos crı́ticos também
devem ser monitorados, propondo um método simples para
identificação deles, que pode ser adotado por empresas de
qualquer segmento. Apesar de haver tantas fontes informando
sobre a importância de definição do escopo, não existe um
consenso ou uma regra prática sobre o que deve ser enviado
para o SIEM. Isso obriga que os analistas tenham perı́cia,
conhecimento do ambiente e foco no resultado esperado, para
atingir resultados relevantes.
Ter critérios ajuda a entender quem —sistema— pode
mandar logs para o SIEM, mas igualmente importante é definir
o quê —dado— deve ser enviado. Frye [5] sugere que tudo o
que for enviado precisa ajudar na tomada de ações, ajudando
a responder questões como: “quando”, “quem” e “onde”.
Uma vez que soluções em geral criam logs para diversas
finalidades3 , enviar para o SIEM todos os eventos que elas
geram, tende a causar confusão em tratamentos posteriores,
além de desperdiçar recursos. Nessa linha, Frye [5] e Zim-
merman [1] concordam que a entrada de dados irrelevantes
tende a gerar informações irrelevantes —eles usam o termo
em inglês garbage in, garbage out, que pode ser traduzido
para o português como “entra lixo, sai lixo”. Dessa forma,
os sistemas devem ser configurados para enviar estritamente
dados necessários para atender aos objetivos da companhia.
Seguindo essa linha, Swift [6] lembra que normas tendem
a ser redundantes, acarretando no armazenamento de dados
em comum, o que garante conformidade sem aumentar a
quantidade de envios.
Como exemplo, pode-se pensar em um controle SOX que
exige a gestão dos acessos a determinado servidor Unix. Neste
caso, deveriam ser enviados apenas logs das facilities auth
e authpriv do syslog, que englobam logins locais, uso dos
comandos su e sudo, além de logins remotos. Importante
notar que mesmo dentro desses subgrupos, nem todos os
logs seriam necessários, assim um parâmetro razoável seria
3 Em termos de netflows, a preocupação é com a frequência com que eles
devem ser enviados, já que sua padronização garante seu fácil reconhecimento
em diversas ferramentas.
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
de configurar a severidade para info, o que evitaria dados
desnecessários de depuração. Em suma, como apresentado por
Miller [8], deve-se entender que logs podem vir de sistemas
operacionais, como Windows e Unix, de appliances, como
Cisco IOS e Palo Alto PAN-OS, ou de aplicações diversas,
cabendo ao time de operação escolher o tipo que deve ser
enviado e como configurá-lo corretamente, para atingir os
objetivos esperados.
O CORS começou a aplicação desse método no grupo
de servidores Windows, que era constituı́do basicamente de
controladores de domı́nio. Eles enviavam uma quantidade
considerável de logs e faziam parte do escopo de controles
SOX. Contudo, após análise, percebeu-se o recebimento de
muitos eventos desnecessários, o que motivou a sanitização. A
tabela I apresenta os números desse trabalho, que trouxe ganho
significativo, já que a eliminação de logs tornou pesquisas mais
rápidas e liberou recursos para recebimento de logs de outros
sistemas.
Tabela I
S ERVIDORES W INDOWS : ANTES E DEPOIS DA APLICAÇ ÃO DOS CRIT ÉRIOS
DE ENVIO DE LOG PARA O SIEM.
Antes Depois Redução
Origens de log 92 66 28,26%
Event IDs 1.069 136 87,28%
EPS 3.217 2.157 32,95%
Seguindo a linha de ativos cibernéticos crı́ticos proposta
por Knapp [7], foi definido que os sistemas SCADA4 preci-
sariam ser monitorados pelo SIEM, pois são softwares usados
para supervisionar e controlar remotamente dispositivos de
campo, como relés, disjuntores e religadores, sendo essenciais
para a operação do setor elétrico. Durante a execução deste
trabalho, percebeu-se que nenhum SCADA estava integrado
com o SIEM e isso era claramente uma ótima oportunidade
de melhoria. Com isso, foi envolvida a área de engenharia
responsável por um dos SCADA mais crı́ticos da Cemig, o
SAGE, tornando-o o primeiro sistema de controle industrial
da companhia a enviar e ter logs tratados e monitorados no
SIEM.
Tendo critérios bem definidos na polı́tica de SIEM sobre o
escopo de cobertura da ferramenta, ajuda em configurações
futuras. Contudo, o inverso também é interessante: definir
critérios para o que não deve ser enviado. Exemplo disso é
deixar claro que apenas sistemas em produção podem enviar
logs para o SIEM, o que já evita ambientes de desenvolvi-
mento. A polı́tica também precisa deixar claro que exceções
podem ser abertas, desde que bem mapeadas e monitoradas,
pois caso se tornem constantes, podem ser um problema ou
terem virado regra, devendo passar a constar na polı́tica.
C. Nomes
A cada novo sistema cadastrado ou cada novo campo de
extração de dados criado, é preciso definir um identificador
no SIEM, como mostrado por Knapp [7]. Padronizar a criação
4 Sigla em inglês para Supervisory Control and Data Acquisition, que pode
ser traduzido para português como sistema de controle e aquisição de dados.
3
desses nomes não só ajuda na organização da ferramenta, mas
também na criação de correlações, pesquisas e monitoramento.
Com efeito, Zimmerman [1] aponta que já foram criados
vários padrões para organização dos dados de logs, nenhum
com adoção relevante. Um deles foi criado pelo Mitre: o
Common Event Expression5 (CEE). Descontinuado em 2014, o
CEE visava a criação de uma linguagem unificada de eventos
para facilitar a interoperabilidade, e uma das suas principais
partes focava na padronização de nomes para campos de log.
A polı́tica deve conter uma seção especı́fica para definir a
convenção de nomes a ser usada no SIEM para as diversas
finalidades que a ferramenta possibilitar. Para isso, podem
ser adaptados padrões como aquele proposto no CEE ou o
PEP-86 , da linguagem de programação Python, observando
que deve ser um padrão consistente, que ajude a identificar
os elementos, sem exigir uso excessivo de caracteres de
escape em scripts ou dar margem para ambiguidades. Isso é
primordial para facilitar atividades futuras no SIEM.
Na Cemig, foram criados padrões de nomes para origens
de log, campos de logs e pesquisas. O modelo foi baseado no
PEP-8, onde basicamente são usadas apenas letras minúsculas
ASCII e o underscore como separador para nomes compostos.
Já a composição dos nomes é algo subjetivo, que deve fazer
sentido para o time de operação. Por isso, usar hostnames
ou criar padrões baseados em vendors ou versões, não era
cogitado. Definiu-se então que origens de log deveriam ter
nomes que ajudassem a referenciar facilmente as ferramentas
de acordo com o grupo a que pertenciam e como eram reco-
nhecidas pela equipe. Nomes de campos deveriam referenciar
as origens de log e pesquisas deveriam ser agrupadas por
finalidade, como conformidade, monitoramento ou resolução
de problemas. A tabela II mostra exemplos de nomes adotados
no CORS para essas três classes.
Tabela II
E XEMPLOS DA NOMENCLATURA ADOTADA NO CORS.
Tipo Exemplos
Origens de log unix_honeypot_certbr
paloalto_panos
unix_db_oracle_1
cisco_asr_9000
unix_sage_1
Campos de log cors_honeypot_user
cors_honeypot_password
cors_honeypot_url
cors_honeypot_user_agent
cors_paloalto_rulename
cors_unix_sshd_username
cors_unix_su_src_username
cors_unix_sudo_command
cors_cisco_interface
Pesquisas compliance_sox_dss0501
monitoring_wsa_realtime
tshoot_vpn_users_logged
Como pode ser visto nos exemplos, optou-se por definir
um prefixo para os campos de log, para ter clareza de quais
propriedades foram definidas automaticamente pelo SIEM e
5 https://cee.mitre.org/
6 https://www.python.org/dev/peps/pep-0008/
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
quais foram criados pelos analistas. Além disso, para as pes-
quisas, foram definidos três prefixos para agrupá-las de acordo
com a sua finalidade. Interessante ressaltar que o número de
campos de log extraı́dos foi reduzido em 78,11% durante a
fase de sanitização, apenas ao excluir as propriedades sem
uso. Teoricamente, esse tipo de ação reduz o processamento
do SIEM, podendo ser qualificada como boa prática.
D. Retenção
A última seção da polı́tica deve tratar dos tempos de
retenção de logs e netflows, para garantir que eles estarão
disponı́veis apenas durante o tempo em que forem necessários,
liberando espaço no banco de dados do SIEM. As informações
armazenadas por motivos de conformidade, usualmente já têm
tempos definidos pelas próprias normas, mas para os demais
casos, as equipes envolvidas precisarão definir tempos de
retenção adequados. Além disso, é preciso que seja definida
na polı́tica, uma regra padrão para descarte dos dados que
não se encaixarem nas classes criadas. Knapp [7] exemplifica
bem essa questão em termos de espaço de armazenamento,
mostrando em uma tabela, conforme a quantidade de dados
enviados e o tamanho médio das mensagens, que o banco de
dados tem um tamanho medido de terabytes.
De acordo com a utilização do SIEM, no caso da Cemig,
foram definidos quatro supergrupos, mostrados na tabela III.
A tı́tulo de exemplo, logs de equipamentos de rede —routers
e switches— e netflows em geral foram agrupados na classe 1.
Logs de firewall, proxy e antispam entraram na classe 2, logs
do sistema de controle de acesso à rede foram para a classe 3
e logs de controladores de domı́nio e bancos de dados foram
para a classe 4. Se o log não se encaixar em alguma das
classes, cairá na polı́tica padrão, cujo descarte foi definido em
três meses.
Tabela III
T EMPOS DE RETENÇ ÃO DE ACORDO COM AS CLASSES .
# Classe Meses
1 Curtı́ssimo Prazo 6 complementa esse raciocı́nio, informando que a tecnologia
2 Curto Prazo 18
3 Médio Prazo 30
4 Longo Prazo 60
Definir a polı́tica garante respaldo para praticamente todas
as decisões futuras relativas ao SIEM. Portanto, o tempo inves-
tido na definição de padrões e na escrita do documento, tende
a ser recuperado posteriormente. Além disso, ter uma polı́tica
bem definida ajuda o time de operação nas interações com as
equipes de conformidade e auditoria, resguardando suas ações.
Nas próximas seções, serão apresentados os métodos para
tratamento de logs e netflows, mas é importante ter sempre
em mente que eles seguem os preceitos definidos na polı́tica.
III. P ROCESSO DE T RATAMENTO DE DADOS
Para colocar a polı́tica do SIEM em prática é necessário
definir um processo de tratamento de logs e netflows, como
sugerido por Swift [6]. Tal processo deverá implementar ações
para maximizar o uso dos dados recebidos, assegurando que
4
cada nova origem seja estudada e devidamente configurada,
para que os dados estejam disponı́veis no perı́odo adequado
para ajudar na tomada de decisões e no cumprimento de
regulações. O fluxograma da figura 1 representa esse processo,
que pode ser resumido em quatro macroetapas:
1) Configuração básica: engloba envio, cadastro, estudo e
extração de dados.
2) Criação de correlações: escrita de regras que conside-
ram dados de uma ou mais fontes para identificação de
incidentes.
3) Criação de pesquisas: definição de pesquisas para
agrupamento e listagem de dados.
4) Criação de monitoramento: painéis de monitoramento
compostos por dados extraı́dos de fontes diversas.
Nesta seção serão apresentadas as ações do processo per-
tencentes à etapa de configuração básica. As demais serão
detalhadas nas seções subsequentes.
A. Configuração da Aplicação
Definido que um novo sistema será cadastrado no SIEM, a
primeira coisa a se fazer é configurar a origem dos dados, que
podem ser logs ou netflows. Para os logs, essa configuração
varia de acordo com cada sistema e arquitetura de rede, mas
grosso modo, devem ser definidos os tipos de log a serem
enviados, como de sistema, de aplicações ou de autenticação.
Além disso, devem ser estabelecidas as severidades dos log
que devem ser enviados, como informacionais, de depuração,
de erro ou de avisos. Frye [5] afirma que há pouco direciona-
mento sobre o que exatamente precisa ser enviado para o SIEM
e quais logs realmente trazem informações relevantes para a
segurança. De fato, essa tarefa é complexa, pois exige que o
analista saiba o que fazer com o log que ainda não recebeu.
Por isso é necessário estudar a aplicação e testar configurações
de envio de logs, para usar parâmetros que se adequem às
necessidades da organização.
A análise dos netflows é um método útil para criar visões
de alto nı́vel da rede, conforme Miller [8]. Zimmerman [1]
traz o resumo de uma conversação entre dois dispositivos
de rede7 , sem necessariamente trazer o payload da conexão.
Isso possibilita entender o funcionamento da rede e guardar
dados históricos, sem a necessidade de grandes espaços de
armazenamento. Um parâmetro interessante para se usar no
tratamento de netflows é a taxa de amostragem, pois pode-se
dividir os equipamentos por classes, que enviarão quantidades
diferentes, tendo-se em mente que o tempo para definir uma
linha de base de comportamento do equipamento é inversa-
mente proporcional à taxa configurada para envio de netflows,
ou seja, quanto menor a taxa, mais tempo será necessário para
definir um padrão de comportamento da rede.
Como disposto por Miller [8] e Frye [5], não é necessário
receber todos os logs e netflows de todos os dispositivos,
porque isso tende a dificultar análises futuras, ou comprometer
7 Segundo Zimmerman [1], de forma genérica, netflows provêm os seguintes
dados de uma conexão: tempos de origem e fim, endereços IP e portas
de origem e destino, protocolo de camada de transporte, bytes enviados e
recebidos e flags TCP.
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
Figura 1. Fluxograma do processo de tratamento de dados.
o desempenho do SIEM. Não obstante, quanto mais dados
enviados, maior tende a ser o processamento de remetente
e destinatário, além de gerar tráfego extra e desnecessário
na rede, o que pode causar impactos negativos. Assim, é
importante ater-se aos manuais e guias dos fabricantes, além de
ter bem claro o escopo de aplicação do SIEM, sempre balance-
ando o envio de dados com as limitações fı́sicas do ambiente
e o atendimento a requisitos impostos. A configuração das
aplicações sempre deve ser seguida da validação dos dados
no SIEM, garantindo que a ferramenta esteja recebendo tudo
o que havia sido planejado. De fato, este é o primeiro loop
do processo mostrado na figura 1, que itera entre SIEM e
aplicação, para validação grosseira das informações.
B. Análise dos Dados
Tendo os dados no SIEM, deve-se estudá-los para entender
os campos que os compõem, pois como Swift [6] pondera,
análises bem feitas podem detectar ameaças emergentes e
tendências. O SIEM pode extrair automaticamente alguns
campos, mas é comum ter que criar novas extrações para
indexação, pois isso aumenta a velocidade de acesso e permite
a criação de regras de correlação. É importante ressaltar
5
que cada aplicação pode tratar determinado tipo de log de
uma forma, mas o campo extraı́do será o mesmo, motivo
pelo qual Knapp [7] e Miller [8] definem essa etapa como
“normalização”. Como netflows são baseados em padrões bem
definidos, geralmente basta definir qual será o formato usado,
como NetFlow v1-9, IPFIX, ou sFlow, e o SIEM já saberá
como tratar cada um deles. Assim, boa parte desta etapa do
processo diz respeito a logs.
Como não existe um padrão de facto para composição
de logs, normalmente cada aplicação organiza os dados da
forma que o programador escolheu. Isso complica a tarefa
do SIEM, obrigando o analista a ler manuais e interpretar
os logs recebidos, para saber o que está chegando e quais
campos devem ser extraı́dos. Portanto, o sucesso dessa tarefa
exige do profissional muita atenção, habilidade em detectar
padrões e bons conhecimentos de expressões regulares —
comumente conhecidas pelo termo regex8 —, para criar rotinas
que identifiquem precisamente os campos a serem extraı́dos.
Trata-se de uma etapa bastante técnica e que precisa ser
executada com planejamento, visando evitar a repetição de
8 Contração do termo em inglês regular expression.
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
padrões, já que campos podem se repetir em diferentes fontes
de log e a mesma regex pode ser usada para todos eles, como
nomes de usuário, condições de equipamentos ou datas, que
é a normalização em si.
Posteriormente, deve ser feita uma análise para determinar
se os dados extraı́dos são suficientes para atender a demanda
especificada. Isso fecha o segundo loop do processo, que volta
para a etapa de configuração da aplicação, caso os dados não
sejam suficientes, ou avança em caso contrário. A próxima
etapa consiste em determinar o tempo de retenção dos dados
recebidos e isso deve ser feito de acordo com as definições
da polı́tica. Apesar de ser uma atividade simples —tendo-se
essas definições na polı́tica—, é extremamente importante ter
atenção nesse passo, visto que o descarte de informações antes
do prazo definido nas normas pode causar sérios problemas,
como perdas financeiras ou danos de imagem.
C. Exemplos de Configuração
Visando melhorar a visibilidade de segurança da rede, o
CORS resolveu enviar para o SIEM netflows do honeypot.
Como a gestão deste sistema é feita em conjunto com o
CERT.br9 , foi uma escolha conjunta a utilização do Internet
Protocol Flow Information Export (IPFIX). Posteriormente,
resolveu-se pelo envio de logs dos listeners do honeypot, sendo
para isso, criado um script10 que transforma cada linha gerada
pelo software de simulação em uma mensagem syslog. Após,
foi feita a análise dos logs no SIEM, destacando-se a extração
de credenciais —usuários e senhas— usadas pelos ofensores.
Apesar desses campos virem de listeners diversos, em padrões
diferentes de mensagens, eles foram unificados nas mesmas
variáveis usando regexes capazes de operar em padrões dis-
tintos. A tabela IV apresenta todos os campos extraı́dos dos
logs do honeypot, com as respectivas expressões regulares —
os campos usuário e senha podem ser vistos nas variáveis
cors_honeypot_user e cors_honeypot_pass, res-
pectivamente. A listagem da figura 2 exemplifica alguns logs
recebidos do honeypot, que são reconhecidos pelas duas ex-
pressões, garantindo a normalização de usuários e senhas, além
de outros campos.
Outro exemplo interessante de aplicação do processo foi
na configuração do antivı́rus. Legado do antigo SIEM, o
antivı́rus estava configurado para envio de logs desde que
a nova ferramenta entrou em operação. Contudo, os dados
enviados não eram tratados; apenas armazenados. Após estudo
da aplicação, foram extraı́dos campos para serem usados
em outras atividades, como nomes de ameaças identificadas,
endereços IP das máquinas e nomes dos arquivos infectados.
Neste caso, havia o agravante do antivı́rus ser objeto de
controle SOX —DSS05.01—, sendo de responsabilidade do
CORS manter ao menos 95% do parque atualizado com as
vacinas dos últimos 5 dias. Para esse caso especı́fico, foi
criado um script no servidor do antivı́rus, que calculava os
percentuais, criava uma mensagem syslog e a encaminhava
para o SIEM. Dessa forma, para comprovação de atendimento
9 https://honeytarg.cert.br/
10 Código-fonte disponı́vel em: https://gist.github.com/forkd/
81b90d86b30e2730df241c90cc323837.
6
ao controle, grosso modo, o time de operação apenas precisaria
garantir o funcionamento do script e apresentar os logs para
a auditoria.
Usar o mesmo processo nos proxies também trouxe ganhos
significativos em termos de visibilidade da rede. Após os
estudos, foram indexadas informações como usuário, URLs
acessadas, categorias dos sites, domı́nios —extraı́dos das
URLs—, endereços IP de origem e volume de tráfego. Essas
informações dão margem para uma série de estudos, que serão
mostrados nas próximas seções.
Desde que foi colocado em operação, o novo SIEM recebia
netflows de uma única origem: o honeypot. Contudo, em 2019
foi iniciado um projeto para equipamentos-chave da rede —
switches e routers— passassem a fazer o mesmo, visando
agrupá-los em classes de acordo com a taxas de amostragem
e criando uma linha de base de acessos, além de cruzar os
dados com blacklists de endereços IP, o que serviria como
base para identificação de comportamentos anômalos na rede.
Esse trabalho encontra-se em estágio inicial no momento de
escrita deste texto.
As configurações básicas das aplicações e do SIEM são
o inı́cio do processo de obtenção ordenada de dados e parte
essencial do trabalho. Caso não seja feita adequadamente, pode
comprometer todas as atividades seguintes, correndo o risco
de impossibilitá-las, inclusive. Por isso, essa primeira etapa é
crı́tica para o sucesso do trabalho, devendo ser devidamente
validada e documentada.
IV. C ORRELAÇ ÃO
Criar regras que correlacionam dados de uma ou mais
origens é uma das atividades que mais diferenciam o SIEM de
sistemas de gerenciamento de logs —Zimmerman [1] tem uma
boa tabela de diferenciação dessas tecnologias. Apesar disso,
criar correlações não é muito simples, pois exige dos analistas
bons conhecimentos sobre o funcionamento esperado da rede,
para criar regras que representam comportamentos anormais.
Bons exemplos de regras, que podem ser aplicadas em vários
ambientes com poucas alterações, são apresentados por Swift
[6].
O uso mais simples desse recurso é a criação de regras
que consideram apenas um tipo de evento para identificar
um incidente. Contudo, implantações mais maduras de SIEM
utilizam mais tipos de eventos, inclusive considerando outros
dados, como origens distintas, faixas de horários e limites. A
tabela V apresenta um modelo de maturidade de correlações,
de acordo com os tipos de regras criadas. Importante notar que
um SIEM pode ser composto por regras dos três grupos, sem
perda de segurança. O modelo apenas refere-se à capacidade
do time de operação em criar cada classe quando necessário
e aplicá-las adequadamente no SIEM.
Em todo caso, de acordo com Zimmerman [1], é impres-
cindı́vel definir padrões adequados, para evitar falso-positivos
ou falso-negativos. Para isso, deve-se testar exaustivamente
cada regra criada antes de colocá-las em produção, princi-
palmente aquelas que tomam ações automáticas em outra
ferramenta.
As únicas regras de correlação usadas no antigo SIEM
da Cemig eram do nı́vel de maturidade 1: antivı́rus e IPS
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO 7

Tabela IV
E XPRESS ÕES REGULARES PARA EXTRAÇ ÃO DE CAMPOS DO HONEYPOT.

Nome do campo Regex

cors_honeypot_datetime
cors_honeypot_ftp_unknown
cors_honeypot_http_code
cors_honeypot_http_dstport
cors_honeypot_http_request
cors_honeypot_srcip
cors_honeypot_listener
cors_honeypot_pass
cors_honeypot_url
cors_honeypot_user
cors_honeypot_user_agent
ˆ.+?\]:\s(\w{3}\s\d\d\s(\d\d:){2}\d\d|
\d{4}(-\d\d){2}\s(\d\d:){2}\d\d\s\+\d{4})
unknown\scommand:\s’(.+?)’
code:\s(\d+)
dstport:\s(\d+),
request:\s"(.+?)"
(IP:|\sfrom)\s([\d\.]+),?
(\s([\w\.-]+)\[\d+]:).*(\s([\w\.-]+)\[\d+]:)
(password|PASS|pass):?\s(’|")(.+?)(’|")
[a-zA-Z]+://[ˆ\s,)";]+
((login|USER|user|password\sauth\ssucceeded\sfor):?\s(’|"))(.+?)(’|")
[Uu]ser-[Aa]gent:\s"?(.+?)("|\s)

Figura 2. Logs do honeypot, destacando os campos extraı́dos com expressões regulares.

1 <13>Mar 20 17:47:50 logger[84804]: 2019-03-19 20:29:25 +0000 : ftp-honeyd.pl [39832]: IP:

54.215.xxx.yyy , USER: ’ anonymous ’
2 <13>Jun 13 00:30:10 logger[90565]: Jun 12 23:53:06 tesla sshd-honeyd [5742]: password auth
succeeded for ’ root ’ (password ’ root ’) from 141.98.xxx.yyy
3 <13>Jun 13 00:30:08 logger[68364]: 2019-06-12 02:23:24 +0000 : pop3-honeyd.pl [18239]: IP:
193.56.xxx.yyy , USER: ’ spammer ’
4 <13>Jun 13 00:30:07 logger[9923]: 2019-06-12 23:49:27 +0000 : dlink-telnetd.pl [50705]: IP:
128.201.xxx.yyy , status: login failed, login: " Administrator ", password: " admin "

Tabela V algoritmo 1. Com isso, a média de incidentes de antivı́rus

M ODELO DE MATURIDADE DE REGRAS DE CORRELAÇ ÃO .
Nı́vel Descrição
1 Incidentes são detectados a partir de um tipo
de dados.
2 Incidentes são detectados a partir do cru-
zamento de mais de um tipo de dados, de
uma ou mais origens, ou de outras variáveis,
como tempo e limites estabelecidos.
3 Ações são executadas automaticamente em
outras ferramentas a partir da detecção de
incidentes, sendo esses abertos apenas para
conferência humana.
mandavam logs e, caso fossem enviados dados indicando a
detecção de malware —antivı́rus— ou alertas de intrusão —
IPS—, incidentes eram abertos. Essas regras foram portadas
para o novo SIEM, mas dada a mudança de visão, percebeu-se
que podiam ser melhoradas.
Visto que o antivı́rus foi trocado junto com o SIEM, portar
a regra antiga trouxe problemas para a operação. Caso o
escaneamento falhasse por qualquer motivo, um novo log era
enviado, mesmo que o software ainda não tivesse esgotado
suas tentativas de análise. Criar a regra sem estudar os logs,
gerou muitos falso-positivos, aumentando desnecessariamente
o número de incidentes abertos. Seguindo o processo pro-
posto neste texto, após identificado o comportamento dos
logs do novo antivı́rus, os dados foram estudados e extraı́dos.
Percebeu-se aı́ que incidentes deviam ser abertos apenas se
logs informassem certas categorias e ações, como exposto no
caiu de 350 para 107 registros por mês, uma redução de
69,42%. Considerando ainda que falso-positivos podem levar
à banalização de incidentes pelos analistas, fazendo com que
casos reais não sejam devidamente tratados, esse foi um ganho
muito expressivo para o time de segurança.
Algoritmo 1: C ORRELAÇ ÃO DE ANTIV ÍRUS .
Entrada: log source group, av category,
av malware categories, av action,
av malware actions
Saı́da: Incidente registrado
1 inı́cio
2 se log source == ’antivirus’ então
3 se av category ∈ av malware categories E
av action ∈ av malware actions então
4 registra incidente;
5 fim
6 fim
7 fim
Usar o honeypot como fonte de informação para detecção
de incidentes é outro bom exemplo. Considerando-se que
todos acessos a esse sistema são maliciosos, pode-se usar os
endereços IP de origem para compor uma lista negra, que será
verificada a cada permissão de firewall, para detectar acessos
suspeitos à rede. Como alguns serviços são normalmente
publicados com regras de acesso mais permissivas, como web
e VoIP, uma lista de exceção precisa ser criada, pois sua
 FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
exposição na internet deixa-os naturalmente suscetı́veis a esses
acessos. O algoritmo 2 representa esse comportamento.
Algoritmo 2: C ORRELAÇ ÃO DE DADOS DO HONEYPOT E
FIREWALLS .
Entrada: f low source, log source group,
honeypot blacklist,
honeypot exclusion list, sourcei p
Saı́da: Incidente registrado
1 inı́cio
2 se f low source == ’honeypot’ então
3 se source ip 6∈ honeypot blacklist então
4 honeypot blacklist ← source ip
5 fim
6 fim
7 se log source group == ’firewalls’ então
8 se source ip ∈ honeypot blacklist E
source ip 6∈ honeypot exclusion list então
9 registra incidente;
10 fim
11 fim
12 fim
Outro exemplo comum é de detecção de ataques de força
bruta. Para isso, pode-se definir que se um endereço IP de ori-
gem causar cinco falhas de login em um servidor, no perı́odo
de um minuto, um incidente será registrado. Analogamente,
para determinados servidores crı́ticos, com acessos bastante
restritos, pode-se determinar que se ocorrer algum acesso ao
sistema em tal faixa de horários, serão registrados incidentes.
Mais um bom exemplo real de correlação usado na Cemig
é a avaliação do percentual de máquinas com antivı́rus atua-
lizados, para conformidade com o controle SOX DSS05.01,
exposto na subseção III-C, que abre automaticamente um
incidente caso o log informe um valor menor que 95%.
V. P ESQUISAS P REDEFINIDAS
Além das correlações, os dados extraı́dos de logs e netflows
podem ser usados em pesquisas destinadas, tanto para uso
em telas de monitoramento, quanto para uso em atividades de
resolução de problemas —em inglês, troubleshooting. Definir
pesquisas tende a facilitar muito o trabalho de operadores e
auditores, uma vez que com poucos cliques, uma sentença
predefinida de busca pode ser carregada, bastando ao analista
alterar parâmetros especı́ficos, como datas, nomes de usuário
ou endereços IP. Swift [6] apresenta várias ideias para pesqui-
sas em um dos seus anexos, mas também chama a atenção para
a revisão periódica das mesmas, pois mudanças no ambiente
devem ser refletidas nelas.
Dependendo das funcionalidades do SIEM, pode-se conce-
der acesso para certas equipes acessarem pesquisas especı́ficas
para o seu trabalho. Dessa maneira, pode-se reduzir a carga
do time de segurança, dando mais autonomia para outros
grupos. Obviamente, toda pesquisa carrega em si o potencial
de aumentar sobremodo o processamento e o consumo de
memória do SIEM, causando perda de desempenho. Assim,
tal disponibilização tem de ser avaliada com cautela, inclusive
8
avaliando se a mesma pode ser substituı́da pela emissão
periódica de relatórios estáticos, que podem ser gerados em
horários de baixa demanda.
Na Cemig, após definir que apenas pesquisas com
propósitos bem definidos poderiam estar publicadas no SIEM,
foi iniciada a readequação, definindo três finalidades, que
foram usadas como prefixos nos nomes de cada pesquisa: con-
formidade —compliance—, monitoramento —monitoring— e
resolução de problemas. Finalizado o trabalho, foram mantidas
apenas 33 pesquisas de um total de 169, uma redução de
80,47%. Das pesquisas relacionadas à conformidade, chama
a atenção aquela referente ao controle SOX DSS05.01,
compliance_sox_dss05.01 —figura 3. Nela, são lista-
dos a hora de apuração e o percentual de máquinas atualizadas
nos últimos trinta dias, o que facilita o trabalho de auditoria.
Importante perceber que alterar qualquer parâmetro da pes-
quisa é trivial, como o tempo de apuração: basta carregar a
pesquisa clicando no seu nome, e após carregada a sentença
de busca, alterar os valores antes de iniciar a procura.
Figura 3. Pesquisa do controle SOX DSS05.01.
1 select dateformat(starttime,’yyyy-MM-dd
HH:mm’),
"cors_mcafee_updated_hosts_percent"
2 from events
3 where logsourcename(logsourceid) =
’mcafee_epo_2’
4 order by starttime desc
5 last 30 days
Usada no monitoramento, a pesquisa
monitoring_honeypot_top_pass —figura 4— lista
as dez senhas mais frequentemente usadas no honeypot. Esse
campo é extraı́do com a regex cors_honeypot_pass,
mostrada na tabela IV e a pesquisa apresenta as senhas e
quantas vezes cada uma foi tentada, ordenando da mais usada
para a menos usada. Novamente, é usado o perı́odo de trinta
dias, mas os campos podem ser alterados facilmente, de
acordo com a necessidade.
Figura 4. Senhas mais frequentemente usadas no honeypot.
1 select "cors_honeypot_pass" as pass,
count(*) as cpass
2 from events
3 where (sourceip = ’128.201.xxx.yyy’) and
("cors_honeypot_user" is not null)
4 group by pass
5 order by cpass desc
6 limit 10
7 last 30 days
Usada para resolução de problemas, a pesquisa
tshoot_wsa_top_access —figura 5— lista os usuários
que mais trafegaram dados no proxy, calculando o volume em
megabytes, no perı́odo especificado pelos parâmetros start
e stop. Essa pesquisa é interessante, pois possibilitou ao
CORS criar um controle de tráfego, para ser executado
periodicamente e sob demanda, para detecção proativa
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
de usuários que estão usando excessivamente a rede,
possivelmente causando lentidão. Logo na primeira execução,
foi encontrado um usuário consumindo cerca de 6 GB por
dia, ao assistir vı́deo-aulas de cursos online voltados para
concursos públicos. Feito o bloqueio no proxy, os acessos
indevidos cessaram e o consumo do usuário caiu para menos
1 GB por dia.
Figura 5. Maiores consumidores de dados web.
1 select "cors_wsa_username" as name,
"cors_wsa_srcip",
sum("cors_wsa_total_bytes"/1048576) as
volume_mb
2 from events
3 where (logsourcegroupname(devicegrouplist)
ilike ’%proxy%’ and
("cors_wsa_httpcode" >= 200 and
"cors_wsa_httpcode" <= 299) and (name
is not null)
4 group by name
5 order by volume_mb desc
6 limit 10
7 start ’2019-06-28 00:00’
8 stop ’2019-06-28 23:59’
Visto que algumas pesquisas podem consumir muito pro-
cessamento e demorar para ser executadas, caso o SIEM per-
mita, é interessante que os analistas criem agendamentos para
execução delas em horários de baixa demanda. Dessa forma,
as buscas podem ser executadas automaticamente durante a
madrugada e os resultados podem ser enviados via email para
os analistas ou pode ser gerado um identificador para que os
resultados sejam visualizados no diretamente no SIEM. Essa
função é especialmente interessante para pesquisas periódicas,
garantindo não só a execução de controles, mas também o
melhor uso de recursos computacionais.
VI. M ONITORAMENTO
Criar painéis bem configurados de monitoramento possi-
bilita ao time de segurança detectar rapidamente incidentes,
para minimizar ou evitar os impactos negativos causados por
eles. Por receber logs de muitas origens, incluindo ativos
cibernéticos crı́ticos, o SIEM é um sistema estratégico para
monitorar segurança da rede. Os gráficos para esse fim são
normalmente criados a partir de pesquisas predefinidas, que
permitem aos operadores acompanhar visualmente o com-
portamento do ambiente. Isso vai na linha do disposto por
Zimmerman [1], onde o dado, seja de log ou netflow, é tratado
e associado a outros dados, transformando-se em informação,
que também é processada e vira conhecimento, que por sua
vez é usado na tomada de decisão.
Obviamente, o monitoramento depende não só do aparato
tecnológico, mas de processos e pessoas treinadas, que não só
deverão identificar problemas, mas tratá-los adequadamente,
como disposto por Frye [5]. Durante a criação dos painéis,
é importante que os analistas tenham em mente o objetivo a
ser atingido, para evitar trazer para o SIEM atividades fora do
escopo, visto que a partir de logs e netflows também é possı́vel
monitorar a conectividade de equipamentos. Zimmerman [1]
9
inclusive afirma que ferramentas de gestão de rede e segurança
não são intercambiáveis, apesar de terem várias similaridades.
Para supervisionar ativos de TI existem outras aplicações,
como Zabbix ou Nagios, sendo o Simple Network Management
Protocol (SNMP) o protocolo mais indicado obter esses dados.
Assim, o monitoramento pelo SIEM deve tratar de outra
camada não coberta por essas aplicações, visando sempre a
segurança cibernética.
No caso da Cemig, pouco tempo depois da implantação do
novo SIEM, o mesmo passou a ser usado para monitoramento
de segurança, mas com o gradual amadurecimento da equipe
na sua operação, os gráficos foram melhorados para trazer
mais informações relevantes para a tomada de decisão. Na
versão mais atual, são usados dois painéis de monitoramento
mostrados nas figuras 6 e 7, ambos atualizados a cada minuto,
com os dados agregados da última hora. No primeiro, na
coluna da esquerda, são listados os maiores bloqueios e per-
missões de firewall, por endereço IP de origem. Analogamente,
na coluna central, tem-se os bloqueios e permissões de firewall
por endereço IP de destino. Na coluna da direita, acima,
são listados os endereços IP que mais acessaram o honeypot
e, abaixo, os bloqueios registrados no IPS agrupados por
endereço IP de origem.
Figura 6. Painel de monitoramento de segurança #1.
No segundo painel, na parte superior da coluna da es-
querda, tem-se as máquinas com maior número de ameaças
identificadas pelo antivı́rus e, na parte inferior, as ameaças
mais recorrentes identificadas. No meio, acima, são listados
os usuários que mais trafegaram dados pelo proxy com seus
endereços IP associados e, na parte inferior, os usuários
que mais foram bloqueados no proxy. Por fim, são listados
os domı́nios e remetentes que mais se repetem nos emails
processados pelo antispam —está em curso a melhoria des-
ses gráficos para apresentar apenas as informações sobre os
bloqueios realizados.
A eficiência do monitoramento pode ser exemplificada
por dois incidentes. No primeiro, foi detectado, via logs de
permissão no firewall, um volume exorbitante de acessos ao
sistema de gestão de inspeção e manutenção de redes de
distribuição da Cemig. Após várias reuniões ao longo de três
semanas, foi descoberto que, após atualizada, uma aplicação
de telefonia enviava uma string inadequada em situações bem
especı́ficas, causando o fechamento da conexão no sistema de
destino e a reabertura da conexão no sistema de origem, um
loop que se repetia indefinidamente, criando várias conexões
simultâneas. Interessante notar que os servidores relacionados
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
Figura 7. Painel de monitoramento de segurança #2.
eram tão robustos, que nenhuma lentidão era notada, mas
em determinados momentos, requisições começavam a ser
enfileiradas e os analistas resolviam o problema reiniciando
os serviços, o que cancelava todas as conexões em loop,
normalizando os acessos.
A figura 8 apresenta o quantitativo de logs de permissão
gerados nos firewalls, entre a aplicação de telefonia e o sistema
da Cemig, destacando que em certos perı́odos, chegava-se a pi-
cos de quase 47 milhões de logs, sendo que o comportamento
normal era de dezenas de milhares de logs. Nesse gráfico é
possı́vel ver claramente os momentos em que os serviços eram
reiniciados, diminuindo drasticamente a quantidade de dados
apurada. De fato, o volume de tráfego era tão alto, que o
gráfico aparenta não trazer dados na maior parte do tempo,
mas pode-se ver na figura que em um desses momentos, em
3 de junho, o volume chegava a quase 30 mil eventos.
No segundo caso, foi identificado um número alto de
acessos ao honeypot, seguido de vários logs de bloqueios
no firewalls, todos de um determinado endereço IP externo,
que foi devidamente bloqueado e monitorado. Após exposição
interna do incidente, que aparentava tratar-se de uma atividade
agressiva de enumeração, foi descoberto que os responsáveis
eram funcionários que trabalham em outra equipe da Cemig.
Eles estavam testando uma ferramenta de análise de vulnera-
bilidades nos endereços públicos da companhia sem informar
à operação.
Um monitoramento bem feito é dever de ofı́cio de qualquer
equipe de operações e isso não é diferente com a segurança.
Usar o SIEM para este fim, além de outras ferramentas para
supervisionar a condição de ativos, garante um nı́vel melho-
rado na gestão e operação da rede. Apesar de ser a última etapa
do fluxo definido na figura 1, o monitoramento pode retroali-
mentar o processo, já que se a ocorrência de alguns incidentes
criar padrões previsı́veis nas telas de monitoramento, podem
ser criadas regras de correlação para identificação automática
deles.
Apesar de passar a sensação de tempo real, como explicado
por Frye [5], é importante ter noção que o monitoramento
é baseado em ações passadas: alguém fez alguma coisa que
gerou um log ou netflow, que foi encaminhado para o SIEM,
que indexou e correlacionou os dados após processamento,
registrando um incidente ou atualizando um gráfico. Após,
o operador ainda deve detectar o problema e tomar ação
adequada, o que evidencia que o tempo entre a ocorrência
de um incidente e o inı́cio da tratativa vai depender da origem
10
dos dados, da rede, do SIEM e do analista.
VII. I NTEGRAÇ ÕES
As correlações são, conforme Zimmerman [1], um gatilho
interessante para tomada de ação, como o envio de emails
ou abertura de incidentes no próprio SIEM. Contudo, como
apresentado na tabela V, no maior grau de maturidade, ações
são executadas automaticamente em outros sistemas de acordo
com os parâmetros passados, garantindo mais agilidade na
resposta a incidentes e até melhor gestão da rede. Essa seria
a forma mais sofisticada de uso das correlações e também
a mais sensı́vel, já que ações erradas, podem causar proble-
mas graves para a operação. Segundo o Gartner [9], times
de segurança têm enfrentado dificuldades de gestão dada a
complexidade e variedade de soluções ofertadas. Portanto,
manter o conhecimento da equipe para operar tais ferramentas,
associado a habilidade em tomar decisões e seguir processos é
um grande desafio para manutenção da segurança cibernética
das companhias.
Com base nesse cenário, é natural pensar na automatização
de tarefas, mas criar rotinas de integração entre sistemas de
segurança requer conhecimento aprofundado de cada um des-
ses sistemas. Além disso, eles necessariamente devem possuir
mecanismos para interoperabilidade, como RESTful APIs, que
são Application Programming Interfaces (APIs) disponibiliza-
das com a arquitetura Representational State Transfer (REST),
como explicado por Gastón [10]. Apesar de RESTful APIs
facilitarem troca de dados entre aplicações, criar integrações
requer conhecimentos de programação, que normalmente não
são de domı́nio dos operadores de rede e segurança, fator que
pode inviabilizar a atividade.
Ao fazer um exercı́cio para arquitetar um ambiente ideal,
pode-se pensar em uma ferramenta de integração entre o SIEM
e os outros sistemas, que criaria uma camada de abstração
entre eles, de forma que o profissional de SIEM precisaria
saber apenas, por exemplo, quais dados o firewall precisa
receber e não como ele funciona. Similarmente, o profissional
de automação não precisaria saber como o SIEM funciona,
bastando receber os dados mı́nimos para servirem de entrada
para a API do firewall. Essa solução ainda precisaria de um
programador no time de operação, capaz de aprender as APIs
dos sistemas e interagir com os demais analistas, não só para
receber os dados adequadamente, mas também para configurar
o ambiente da forma mais segura possı́vel e conduzir os testes
necessários sem causar impactos.
Justamente para esse nicho, recentemente surgiu o que o
Gartner define como Security Orchestration Automation and
Response (SOAR) [9], um tipo de software que coordena
a tomada de decisões ao implementar fluxos que se valem
de rotinas de integração com outros sistemas, para obtenção
de dados e execução automática de ações. A ideia é que
os processos são desenhados no SOAR, incluindo as ações
automáticas a serem tomadas em cada etapa, desde consultas
a bancos de dados de endereçamento IP —IP Address Ma-
nagement (IPAM)—, até aplicações de regras em firewalls,
passando pela coleta de dados que são obtidos da internet,
através do Registration Data Access Protocol (RDAP), por
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO
Figura 8. Volume de tráfego anormal nos acessos a uma aplicação crı́tica.
exemplo. Dessa forma, caberia ao time de operação definir
adequadamente os processos e implementar as integrações,
além de avaliar as execuções automáticas, corrigindo possı́veis
falhas de execução.
Para organizar e facilitar o consumo de recursos via REST-
ful APIs, mesmo sem possuir um SOAR, em 2019 foi iniciado
no CORS o projeto de código-aberto Corsair11 . Basicamente,
ele implementa wrappers das principais ferramentas usadas
na Cemig na linguagem Python, facilitando a criação dos
scripts de automação. O projeto ainda está em estágio inicial
e como não existe um programador dedicado no time, o
desenvolvimento tem sido lento. Espera-se que, ao atingir
certo grau de maturidade, o Corsair ajude a agilizar tarefas de
automação, garantindo também a reusabilidade de código, fora
a consequente abstração do funcionamento básico das APIs.
Como a automação de tarefas requer testes minuciosos e o
Corsair ainda é um projeto em estágio embrionário, não foi
possı́vel apurar os resultados que ele pode entregar. Contudo,
espera-se ter essas informações em médio ou longo prazo, para
determinar se haverá ganho, justificando a contratação de mais
mão de obra nesse sentindo, como um programador dedicado
à integrações visando automação de atividades. Não obstante,
mesmo com um SOAR, espera-se que essa biblioteca seja
de grande utilidade, servindo como base para as integrações
que venham a ser criadas. É importante frisar que, ainda
que o termo “automação” possa ser entendido como redução
da força de trabalho, Zimmerman [1] é taxativo em afirmar
não há substituição para o analista humano: ao implementar
um SIEM, o time de segurança terá visão de atividades
antes despercebidas, ampliando a carga de trabalho com ações
que precisam ser executadas por pessoal especializado, para
aumentar efetivamente o grau de segurança.
VIII. C ONCLUS ÃO
Apesar de produtos SIEM, segundo Zimmerman [1], esta-
rem no mercado desde o inı́cio dos anos 2000, existe pouca
literatura sobre o assunto que apresente melhores práticas e
casos de uso. Boa parte do material existente é feito pelos
próprios desenvolvedores das ferramentas, que normalmente
servem mais como itens promocionais do que como guias
que realmente auxiliem na melhor utilização da tecnologia.
Acredita-se que esse seja um dos motivos pelos quais Swift
[6] afirme que organizações despendem muito dinheiro para
gestão de logs, obtendo resultados ruins —como aconteceu na
Cemig por mais de uma década. Criar a polı́tica e o processo
para tratamento dos dados no SIEM não é ideia nova, pois
11 Código-fonte disponı́vel em https://github.com/forkd/corsair.
11
Miller [8], Swift [6] e Frye [5] já apresentaram isso, sem
dar detalhes, no entanto. Espera-se que esta seja a principal
contribuição deste texto, apresentando mais detalhes sobre
como fazer isso.
A criação da polı́tica e posterior aplicação do processo pro-
posto neste texto trouxe ganhos significativos para a operação
de segurança cibernética na Cemig, visto que aumentou a
visibilidade da rede, possibilitou a detecção automática de
incidentes e permitiu a implementação de uma série de con-
troles impossı́veis de serem feitos sem o tratamento adequado
dos dados. Contudo, esses são os ganhos imediatos e com o
desenvolvimento de trabalhos ainda em curso, outros tendem
a aparecer.
Os sistemas SCADA, por exemplo, ainda precisam ser
totalmente integrados na ferramenta e os primeiros automa-
tismos decorrentes de correlações de eventos precisam ser
criados. Para melhorar o monitoramento, está sendo estudado
o uso de ferramentas especı́ficas para criação de painéis,
como Grafana12 e Graphite13 , para aprimorar ainda mais a
apresentação dos dados, facilitando a análise do operador.
Também encontra-se em curso, o estudo do envio de netflows
de equipamentos estratégicos da rede, para ampliar ainda mais
a visão de segurança. Além disso, a aplicação do processo
descrito neste texto pode ajudar em projetos proteção de dados
pessoais, como conformidade com a Lei Geral de Proteção de
Dados (LGPD).
Existem algumas ideias de trabalhos futuros que podem sur-
gir em decorrência do presente estudo, tanto no processamento
de netflows, quanto no de logs. Sobre netflows, pode-se pensar
na criação de uma metodologia para identificação dos equipa-
mentos que deverão enviá-los, agrupando-os por classes, sendo
que cada classe pode usar uma taxa determinada de envio de
netflows. Além disso, podem ser indicadas correlações que
detectem incidentes usando apenas os dados enviados pelos
equipamentos. Relativo a logs, um bom trabalho seria de
estudo e definição de padrões de envio de logs de sistemas
operacionais diferentes e firmwares de equipamentos de rede.
Poderiam ser mostrados os campos interessantes para serem
usados em análises de segurança, junto com sugestões de
correlações.
Em sı́ntese, criar uma polı́tica para uso do SIEM e aplicar
o processo de tratamento de dados trouxe muitos ganhos
para a Cemig e acredita-se que isso pode ser obtido também
em outras companhias. Logs e netflows são dados muito
importantes, pois trazem em si, evidências importantes de
12 https://grafana.com
13 https://graphiteapp.org
FÓRUM BRASILEIRO DE CSIRTS, CERT.BR, 8a EDIÇÃO, SETEMBRO 2019 CLASSIFICAÇÃO: PÚBLICO 12

ações que ocorreram e que podem ser usadas, sozinhas ou

dentro de um contexto, para identificação de incidentes ou
tomada de decisões. Não é absurdo imaginar que os incidentes
na Ucrânia [3] e na Alemanha [4] poderiam ter sido evitados
se os dados dos sistemas crı́ticos tivessem sido corretamente
tratados. Por isso, tratar adequadamente esses dados é uma
iniciativa inteligente e muitas vezes barata, com o potencial
de trazer ganhos significativos para as organizações, não só
para garantir conformidade com normas, mas para melhorar
nı́vel de segurança cibernética.

R EFER ÊNCIAS
[1] C. Zimmerman, Ten Strategies of a World-Class Cybersecurity Opera-
tions Center. Mitre, 201, p.118-174.
[2] K. Stouffer, J. Falco, and K. Scarfone, Special Publication 800-82:
Guide to Industrial Control Systems (ICS) Security. National Institute
of Standards and Technology, 2011.
[3] R. M. Lee, M. J. Assante, and T. Conway, “Analysis of the cyber attack
on the ukranian power grid,” SANS, 2016 (acessado em 18 de maio de
2019).
[4] ——, “German steel mill cyber attack,” SANS, 2014 (acessado em 18
de maio de 2019).
[5] D. Frye, “Effective use case modeling for security information event
management,” SANS, 2009.
[6] D. Swift, “Successful siem and log management strategies for audit and
compliance,” SANS, 2010.
[7] E. Knapp, Industrial Network Security. Elsevier, 2011, p.215-247.
[8] D. R. Miller, S. Harrin, A. A. Harper, S. Vandyke, and C. Blask, Security
Information and Event Management (SIEM) Implementation. McGraw-
Hill, 2011, p.53-135.
[9] C. Neiva, C. Lawson, T. Bussa, and G. Sadowski, “Innovation insight
for security orchestration,” Gartner, Tech. Rep., 2017.
[10] G. C. Hillar, Building RESTful Python Web Services. Packt, 2016.

José Lopes Trabalha com TI desde 2007 e com

segurança da informação desde 2013. Em 2014, es-
truturou o CSIRT Cemig e apresentou-o no CERT.br.
Desde 2017 é coordenador do SOC e do NOC da
Cemig, times que foram unificados como Centro de
Operações de Rede e Segurança (CORS). Paralela-
mente, atuou como gestor técnico do honeypot, como
programador de automação de tarefas do CORS,
como arquiteto de soluções, redesenhando processos
e procedimentos de redes e segurança, e como lı́der
de mudanças e de resposta a incidentes.

Luiz Felipe Formado em Sistemas de Informação

pelo IFMG, atuou como operador no Centro de
Operações de Rede e Segurança (CORS) entre março
de 2017 e dezembro de 2018, quando foi promo-
vido a analista de segurança da informação focado
em SIEM, cargo que ocupa até a atualidade. Re-
centemente, tornou-se facilitador e articulador dos
programas da Fundação Estudar, uma organização
focada na formação de novos lı́deres, além de ser
vice-diretor na ONG Inspirando Gigantes.

View publication stats