Uma arquitetura estruturada segura na construção de sistemas

395 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
395
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Uma arquitetura estruturada segura na construção de sistemas

  1. 1. INSTITUTO TECNOLÓGICO DE AERONÁUTICA UMA ARQUITETURA ESTRUTURADA SEGURA NA CONSTRUÇÃO DE SISTEMASCENTRALIZADOS DE REGISTROS DE EVENTOSAluno: Bruno TaboadaEspecialização em Tecnologia da Informação Segurança da Informação
  2. 2. AGENDA1. Motivação2. Justificativa3. O problema4. Objetivo5. Arquitetura6. Experimento7. Resultados8. Conclusão
  3. 3. MOTIVAÇÃO•Centralização dos registros de eventos de vários formatos e dediferentes fontes em um modelo único e estruturado.•Ferramentas capazes de identificar automaticamente o comportamentosuspeito e gerar relatórios e maneiras de apresentação correlacionadasdos eventos contidos nos registros.•Sistemas capazes de receber massivas entradas de registros deeventos concorrentemente e segura.
  4. 4. JUSTIFICATIVA Indústrias representadas Outras 23% Financeiras 19% Governo 18% Educação 10% Saúde 8% Telecomunicações 7% Energia 5%Engenharia/Construção 4% Varejo 3% Manufatura 3% 0% 5% 10% 15% 20% 25%
  5. 5. JUSTIFICATIVA Tamanho das Organizações 8% Empresas (2000 ou mais empregados do mesmo país) 25% 12% Multinacionais (2000 ou mais empregados) 500 - 1999 empregados 17% 100 a 499 empregados 20% Menos de 100 empregados 18% Até 200
  6. 6. JUSTIFICATIVA Desafios na gestão de logs Mais Desafiador Desafio moderado Normalização e categorização da 40% 35% informação Pesquisar 29% 44%Usar os Logs para relatórios e análises 28% 44% Gestão de Logs, incluindo a 27% 34% manutenção da cadeia de custódia Usando Logs para conformidade 17% 35% Armazenamento /arquivamento 17% 28% Coletas de Logs 16% 30% Usar Logs para operações e 16% 44% manutenção
  7. 7. O PROBLEMA =
  8. 8. OBJETIVO Problemas:• Normalização das entradas dos registros de eventos.• Suporte à pesquisa e à análise dos dados dos registros de eventos com o objetivode identificar comportamentos suspeitos. 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.
  9. 9. ARQUITETURA ACCORSI (2009)Transmissão:Autenticação de origem: o host que recebe as mensagens de registro de eventos devegarantir que as mensagens foram enviadas por um dispositivo autorizado.Confidencialidade da mensagem: as mensagens de registro de eventos devempermanecer confidenciais durante a transmissão.Integridade da mensagem: as mensagens de registro de eventos não podem sermodificadas durante a transmissão.Singularidade da mensagem: uma mensagem de registro de eventos deve ser gravadaapenas uma vez.Entrega confiável: mensagens de registro de eventos enviadas por um dispositivo para umhost remoto devem ter a entrega garantida. Isso está relacionado ao protocolo detransporte utilizado.
  10. 10. ARQUITETURA ACCORSI (2009) Armazenamento:• Prestação de contas da entrada: entradas de registro devem incluir informações relativasao 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.
  11. 11. ARQUITETURA• Enterprise Service Bus.• Um gateway HTTP.• Um serviço assíncrono.• SGBD.• SqlRouter.• Parsers.
  12. 12. ARQUITETURATransmissão: Chave Valor Resource Nome da fonte do registro logEntry Entrada do registro de eventosArmazenamento: 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 DateTime de when. Source Nome da fonte de registro. String
  13. 13. ARQUITETURA
  14. 14. EXPERIMENTAÇÃO Cenário # Descrição: Objetivo (Ataques). Teste com o sistema Teste sem o sistema P1 * * P2 * * P3 * * Ataque Padrão do ataque
  15. 15. EXPERIMENTAÇÃO Nº Ataque Descrição Nível de força Partindo de um único endereço de IP checando um intervalo de portas sequencialmente a um único alvo A1 Port Scanner 1 1 passando por um firewall. Partindo de um único endereço de IP checando um intervalo de portas sequencialmente a três alvos A2 Port Scanner 2 2 passando por três firewalls, cada alvo protegido por um firewall. Partindo de um único endereço de IP checando portas arbitrárias a alvos arbitrários partindo de A3 Port Scanner 3 portas aleatórias passando por três firewalls e 3 realizando conexões normais com a intenção de mascarar o ataque. 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 A4 Port Scanner 4 conexões normais com a intenção de mascarar o 4 ataque, sendo que os alvos estão protegidos por esses firewalls.
  16. 16. EXPERIMENTAÇÃO O respondente deve possuir conhecimentos sobre os ataques elaborados e saber Legenda Descrição como identificá-los. Propósito Saber se foi possível identificar o ataque e o grau de dificuldade de identificação. Foi possível identificar o ataque? ( ) Sim ( ) Não P1 Pergunta 1 Grau de dificuldade em identificar os 1 a 10 ataques? P2 Pergunta 2 Foi possível contar o número de ( ) Sim ( ) Não tentativas? P3 Pergunta 3
  17. 17. EXPERIMENTAÇÃO
  18. 18. RESULTADOS Foi possível identificar o ataque? 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 S S S S S S S sistema Teste sem o S S S N N N N sistema
  19. 19. RESULTADOS Grau de dificuldade em identificar os ataques? Sumário da Cenário #1 Cenário #2 Cenário #3 Cenário #4 Cenário #5 Cenário #6 Cenário #7 Pontuação Teste com o 1 1 1 1 3 4 5 sistema Teste sem o 1 3 5 7 7 9 10 sistema
  20. 20. 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 S S S S S S S sistema Teste sem o S S N N N N N sistema
  21. 21. RESULTADOS Resultados 1900ral 1900ral 1900ral 1900ral 1900ral Notas 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral #1 #2 #3 #4 #5 #6 #7 Teste com o protótipo 1900ra 1900ra 1900ra 1900ra 1900ra 1900ra 1900ra Teste sem o protótipo 1900ra 1900ra 1900ra 1900ra 1900ra 1900ra 1900ra
  22. 22. DISCUSSÕES Sem o sistema• 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.
  23. 23. 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 commuitas fontes de diferentes formatos.• Normalização + centralização + visualização correlacionada = aumento dasegurança.• Diferentes formas em que as fontes desses registros podem secomunicar.(Enterprise Service Bus + HTTP)• ESBs possuem mecanismos de segurança embutidos fornece segurança ecredibilidade de tais sistemas.• Arquitetura ser simples.

×