uma arquitetura estruturada segura na construção de sistemas
DESCRIPTION
TRANSCRIPT
UMA ARQUITETURA ESTRUTURADA SEGURA NA CONSTRUÇÃO DE SISTEMAS CENTRALIZADOS DE REGISTROS DE EVENTOS
Aluno: Bruno TaboadaEspecialização em Tecnologia da Informação Segurança da
Informação
INSTITUTO TECNOLÓGICO DE AERONÁUTICA
8. Conclusão8. Conclusão
4. Objetivo4. Objetivo
AGENDA
1. Motivação1. Motivação
2. Justificativa2. Justificativa
3. O problema3. O problema
5. Arquitetura5. Arquitetura
6. Experimento6. Experimento
7. Resultados7. Resultados
MOTIVAÇÃO
• Centralização dos registros de eventos de vários formatos e de
diferentes fontes em um modelo único e estruturado.
• Ferramentas capazes de identificar automaticamente o
comportamento suspeito e gerar relatórios e maneiras de
apresentação correlacionadas dos eventos contidos nos registros.
• Sistemas capazes de receber massivas entradas de registros de
eventos concorrentemente e segura.
JUSTIFICATIVA
Manufatura
Varejo
Engenharia/Construção
Energia
Telecomunicações
Saúde
Educação
Governo
Financeiras
Outras
0% 5% 10% 15% 20% 25%
3%
3%
4%
5%
7%
8%
10%
18%
19%
23%
Indústrias representadas
JUSTIFICATIVA
24%
20%
18%
17%
12%
8%
Tamanho das Organizações
Empresas (2000 ou mais em-pregados do mesmo país)
Multinacionais (2000 ou mais empregados)
500 - 1999 empregados
100 a 499 empregados
Menos de 100 empregados
Até 200
JUSTIFICATIVA
Normalização e categorização da in-formação
Pesquisar
Usar os Logs para relatórios e análises
Gestão de Logs, incluindo a manutenção da cadeia de custódia
Usando Logs para conformidade
Armazenamento /arquivamento
Coletas de Logs
Usar Logs para operações e manutenção
40%
29%
28%
27%
17%
17%
16%
16%
35%
44%
44%
34%
35%
28%
30%
44%
Desafios na gestão de logs
Mais Desafiador Desafio moderado
O PROBLEMA
=
OBJETIVO
• Normalização das entradas dos registros de eventos.
• Suporte à pesquisa e à análise dos dados dos registros de eventos com o objetivo
de identificar comportamentos suspeitos.
Problemas:
Como:
• Arquitetura segura com componentes presentes em aplicações web tradicionais.
• A construção de um protótipo de um sistema centralizado de registros de eventos.
• Cenários com registros de eventos contendo ataques reais.
• Experimento controlado.
ARQUITETURA
Autenticação de origem: o host que recebe as mensagens de registro de eventos deve
garantir que as mensagens foram enviadas por um dispositivo autorizado.
Confidencialidade da mensagem: as mensagens de registro de eventos devem
permanecer confidenciais durante a transmissão.
Integridade da mensagem: as mensagens de registro de eventos não podem ser
modificadas durante a transmissão.
Singularidade da mensagem: uma mensagem de registro de eventos deve ser gravada
apenas uma vez.
Entrega confiável: mensagens de registro de eventos enviadas por um dispositivo para um
host remoto devem ter a entrega garantida. Isso está relacionado ao protocolo de transporte
utilizado.
ACCORSI (2009)
Transmissão:
ARQUITETURA
• Prestação de contas da entrada: entradas de registro devem incluir informações relativas
ao assunto, que são acrescentadas à entrada para formar uma trilha de auditoria.
• Integridade da entrada: trilhas de auditoria, uma vez gravadas, não podem ser alteradas
(alteradas,excluídas ou anexadas).
• Confidencialidade da entrada: entradas não são armazenadas em texto claro.
Armazenamento:
ACCORSI (2009)
ARQUITETURA
• Enterprise Service Bus.
• Um gateway HTTP.
• Um serviço assíncrono.
• SGBD.
• SqlRouter.
• Parsers.
Nome Tipo
Id Identificador único gerado pelo SGBD. Identity
Who “Quem”.Ex: um endereço IP ou nome de um usuário. String
What “O quê”. Ex: um pedido de sincronização ou ação de um usuário. String
When “Quando”. Ex: uma data e hora de quando ocorreu o evento. String
Where “Onde”. Ex: Um endereço IP de destino. String
Timestamp Data e hora registradas no momento do cadastro DateTime
Order Data e hora no tipo datetime do banco de dados convertido a
partir de when.
DateTime
Source Nome da fonte de registro. String
ARQUITETURATransmissão:
Chave Valor
Resource Nome da fonte do registro
logEntry Entrada do registro de eventosArmazenamento:
ARQUITETURA
EXPERIMENTAÇÃOCenário #
Descrição: Objetivo (Ataques).
Teste com o sistema Teste sem o sistema
P1 * *
P2 * *
P3 * *
Ataque Padrão do ataque
EXPERIMENTAÇÃONº Ataque Descrição Nível de força
A1 Port Scanner 1
Partindo de um único endereço de IP checando um
intervalo de portas sequencialmente a um único alvo
passando por um firewall.1
A2 Port Scanner 2
Partindo de um único endereço de IP checando um
intervalo de portas sequencialmente a três alvos
passando por três firewalls, cada alvo protegido por
um firewall.
2
A3 Port Scanner 3
Partindo de um único endereço de IP checando
portas arbitrárias a alvos arbitrários partindo de
portas aleatórias passando por três firewalls e
realizando conexões normais com a intenção de
mascarar o ataque.
3
A4 Port Scanner 4
Partindo de endereços IP arbitrários checando alvos
arbitrários em portas arbitrárias em tempos diferentes
passando por três firewalls e realizando conexões
normais com a intenção de mascarar o ataque, sendo
que os alvos estão protegidos por esses firewalls.
4
EXPERIMENTAÇÃO
Legenda Descrição
O respondente deve possuir conhecimentos sobre os ataques elaborados e saber
como identificá-los.
Propósito Saber se foi possível identificar o ataque e o grau de dificuldade de identificação.
P1 Pergunta 1
Foi possível identificar o ataque? ( ) Sim ( ) Não
P2 Pergunta 2
Grau de dificuldade em identificar os
ataques?
1 a 10
P3 Pergunta 3
Foi possível contar o número de
tentativas?
( ) Sim ( ) Não
EXPERIMENTAÇÃO
RESULTADOS
Sumário Cenário #1 Cenário #2 Cenário #3 Cenário #4 Cenário #5 Cenário #6 Cenário #7
Teste com o
sistemaS S S S S S S
Teste sem o
sistemaS S S N N N N
Foi possível identificar o ataque?
RESULTADOS
Grau de dificuldade em identificar os ataques?
Sumário
da
Pontuação
Cenário #1 Cenário #2 Cenário #3 Cenário #4 Cenário #5 Cenário #6 Cenário #7
Teste com o
sistema1 1 1 1 3 4 5
Teste sem o
sistema1 3 5 7 7 9 10
RESULTADOS
Foi possível contar o número de tentativas?
Sumário Cenário #1 Cenário #2 Cenário #3 Cenário #4 Cenário #5 Cenário #6 Cenário #7
Teste com o
sistemaS S S S S S S
Teste sem o
sistemaS S N N N N N
RESULTADOS
#1 #2 #3 #4 #5 #6 #7
Teste com o pro-tótipo
10 10 10 10 30 40 50
Teste sem o pro-tótipo
10 30 50 70 70 90 100
CE6605660al
CE6605660al
ResultadosN
ota
s
DISCUSSÕES
• Nível do ataque maior ataque = maior dificuldade em identificar.
• +Fontes de registros -> +Entradas = Chegar ao ponto do impossível de detectar.
• Infraestrutura maior -> Mais dispositivos -> Maior conhecimento = Impraticável.
• +Entradas = Impraticável realizar a contagem com exatidão.
Sem o sistema
CONCLUSÕES• Sem sistemas centralizados de registro de eventos fica difícil, ou até
impossível, realizar uma gestão segura desses registros em ambientes com muitas fontes de diferentes formatos.
• Normalização + centralização + visualização correlacionada = aumento da segurança.
• Diferentes formas em que as fontes desses registros podem se comunicar.(Enterprise Service Bus + HTTP)
• ESBs possuem mecanismos de segurança embutidos fornece segurança
e credibilidade de tais sistemas.
• Arquitetura ser simples.