Uma arquitetura estruturada segura na construção de sistemas

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.