LÍNIQUER KAVROKOV VIEIRA
UMA ARQUITETURA BASEADA EM UM MODELO
GERENTE-AGENTE PARA ANÁLISE INTEGRADA E
AUTOMAÇÃO DA COLETA DOS DADOS DE
MÉTRICAS DE SEGURANÇA
CAMPINAS
2013
i
Universidade Estadual de Campinas
Faculdade de Engenharia Elétrica e de Computação
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Engenharia Elétrica da Faculdade de Engenharia Elétrica e de Com-putação da Universidade Estadual de Campinas como parte dos requisitos exigidos para obten-ção do título de Mestre em Engenharia Elétrica. Área de concentração: Telecomunicações e Te-lemática.
Orientador: Prof. Dr. Leonardo de
Sou-za Mendes
CAMPINAS 2013
LÍNIQUER KAVROKOV VIEIRA
UMA ARQUITETURA BASEADA EM UM MODELO GERENTE-AGENTE PARA ANÁLISE INTEGRADA E AUTOMAÇÃO DA COLETA DOS DADOS DE
MÉTRICAS DE SEGURANÇA
Este exemplar corresponde à versão final da dissertação defendida pelo aluno Líniquer Kavrokov Vieira, e orientada pelo prof. Dr. Leonardo de Souza Mendes
iv
AGRADECIMENTOS
Primeiramente gostaria de agradecer a Deus por ter me concedido a oportunidade de cur-sar o mestrado na Unicamp e por estar sempre ao meu lado me abençoando e me proporcionando sabedoria para tomar as decisões corretas.
Ao professor Leonardo de Souza Mendes que confiou em meu trabalho e me aceitou co-mo aluno. Obrigado por tudo professor!
Aos meus pais, Genes Horacio da Silva Vieira e Nara Kavrokov, que batalharam a vida toda para me proporcionarem um estudo de qualidade. Graças a vocês eu estou aqui! A minha irmã Loraine Kavrokov Vieira que sempre me apoiou em todas minhas decisões. Lozinha você é a próxima!
A minha noiva e futura esposa Carla Usso Barreto, você sempre esteve comigo desde o começo! Quantas conversas, quantos conselhos, quantas "broncas" e nunca, nunca me deixou desistir! Amor, essa dissertação é dedicada especialmente a você! A vista daqui é linda e você está ao meu lado!
Aos meus amigos, Eder Ignatowicz, Tiago Dolphine, Daniel Sundfeld, Ekler Mattos, Ri-cardo Alberti, Junior Alves, Adriano Kozan, Wilson Junior, Guilherme Patrezze, Gustavo Carva-lho e Jesiel Junior. Sim, a lista é grande e ainda tem mais!!! Meus amigos do LaRCom, Rodrigo Miani, Bruno Zarpelão, Ricardo Tajiri, André Elias, Eduardo Zanoni, Alexandre Amaral, Gean Breda, José Henrique Maciel e Alexandre Soares. A parceria é bruta!!! Os churrascos e nossas histórias ficarão para sempre em minha memória e em nossas rodas de conversa!
Essa fase da minha vida foi muito importante e todos vocês fizeram e continuarão fazendo parte dela! Meus filhos e netos com certeza saberão de toda essa luta e de tantos acontecimentos inesquecíveis! A história foi escrita mais uma vez!!!
v RESUMO
A dependência cada vez maior das redes de computadores torna a segurança da informação um elemento chave para os avanços e a continuidade dos serviços em nossa sociedade. Métricas de segurança são desenvolvidas com o intuito de oferecer uma base quantitativa e objetiva para au-xiliar o gerenciamento da segurança em uma organização. Porém, a utilização de métricas para medir o nível de segurança, quando realizada de uma forma manual, pode exigir uma grande quantidade de tempo e esforço para coleta dos dados.
Este trabalho propõe uma arquitetura baseada em um modelo gerente-agente para permitir a au-tomação da coleta dos dados de diversos componentes de uma rede de computadores, visando ampliar a aplicação das métricas e auxiliar no gerenciamento de segurança. Uma ferramenta para medição e coleta automatizada dos dados foi desenvolvida baseada na arquitetura proposta e apli-cada em uma rede de computadores. A ferramenta, além de auxiliar o administrador de rede nas tomadas de decisões, também facilita o gerenciamento das métricas através de um modelo de visualização. Testes foram realizados e mostraram que a arquitetura proposta é capaz de integrar o controle das informações e auxiliar o processo de monitoramento da segurança.
Palavras-chave: Métricas de segurança. Automação da coleta dos dados. Gerenciamento da segurança. Redes de computadores.
vi
ABSTRACT
The requirement of organizations on computer network makes information security a key element to the evolution and continuity of services in our society. Security metrics are developed in order to offer a quantitative and objective basis for security assurance. However, the use of metrics to measuring security level, when performed in manually, can require a higher time and effort for data collection.
This study proposes an architecture based on agent-manager management model to allow the automated data collection from several components in a computer network, aiming to expand the security metrics application and support the security management. A tool for measurement and automated data collection based on the proposed architecture were developed and applied in a real computer network. This tool helps the network administrator in decision making and also facilitates the metrics management through a visualization model. Tests were performed showing that the proposed architecture is able to integrate the control of information and support the se-curity monitoring process.
Keywords: Security metrics. Automated data collection. Security Management. Computer
vii SUMÁRIO 1 INTRODUÇÃO ... 1 1.1 MOTIVAÇÕES ... 2 1.2 CONTRIBUIÇÕES DA DISSERTAÇÃO ... 3 1.3 ORGANIZAÇÃO DO TRABALHO ... 4 2 TRABALHOS RELACIONADOS ... 5 2.1 MÉTRICAS DE SEGURANÇA ... 5
2.2 AUTOMAÇÃO DA COLETA DOS DADOS DAS MÉTRICAS ... 7
2.3 MODELOS PARA AUTOMAÇÃO DA COLETA DOS DADOS DAS MÉTRICAS ... 9
2.4 MODELOS PARA VISUALIZAÇÕES DAS INFORMAÇÕES... 13
2.5 SOLUÇÃO PROPOSTA NESTE TRABALHO ... 16
3 APLICAÇÕES DAS MÉTRICAS ... 18
3.1 CRITÉRIOS PARA SELECIONAR MÉTRICAS ... 18
3.2 TAXONOMIAS ... 19
3.3 CRITÉRIOS PARA SELEÇÃO DAS MÉTRICAS PASSÍVEIS DE AUTOMAÇÃO 23 4 ARQUITETURA DE COLETA DOS DADOS ... 26
4.1 MODELO DE GERENCIAMENTO GERENTE-AGENTE ... 26
4.2 ARQUITETURA PROPOSTA ... 28
4.2.1 Redes de Computadores ... 29
4.2.2 Protocolos de Comunicação ... 29
4.2.3 Estação de Gerenciamento ou Gerente ... 33
5 INTEGRATED PLATFORM FOR SECURITY METRICS ANALYSIS (IPSMA) .... 36
6 ESTUDO DE CASO ... 52
6.1 LABORATÓRIO DE REDES DE COMUNICAÇÕES (LARCOM) ... 52
6.2 APLICAÇÃO DAS MÉTRICAS DE SEGURANÇA NO LARCOM ... 55
6.3 DISCUSSÃO E RESULTADOS ... 59
7 CONCLUSÃO ... 67
viii
LISTA DE FIGURAS
Figura 2.1: Métricas de segurança atuando sobre os controles de uma organização. ... 6
Figura 2.2: Visão geral do modelo proposto por Kun Sun. Extraída de (Sun et al., 2011) ... 10
Figura 2.3: Visualização das métricas de segurança. Extraída de (Sun et al., 2011) ... 15
Figura 2.4: Anomaly Propagation View. Extraída de (Amaral et al., 2012) ... 16
Figura 3.1:Metrics Catalog, um serviço do projeto Metrics Center. Extraída de (Securitymetrics.org, 2013) ... 21
Figura 3.2: Métrica de segurança seguindo o modelo utilizado pelo Metrics Center. Extraída de (Securitymetrics.org, 2013) ... 22
Figura 4.1: Exemplo de uma estrutura de gerenciamento gerente-agente. ... 27
Figura 4.2: Visão geral da arquitetura proposta. ... 28
Figura 4.3: Informações da MIB dispostas de uma forma hierárquica. Extraída de (Mauro et al., 2001) ... 31
Figura 4.4: Arquitetura NetFlow. ... 32
Figura 4.5: Camadas do modelo MVC e suas interações. ... 35
Figura 5.1: IPSMA atuando no monitoramento de uma rede de computadores. ... 36
Figura 5.2: Diagrama de Execução da ferramenta IPSMA. ... 38
Figura 5.3: Diagrama de Implantação - Mapeamento da estrutura lógica dos arquivos implementados. ... 39
Figura 5.4: Diagrama de Implantação - Interação entre o IPSMA e os componentes físicos de uma rede de computadores. ... 40
Figura 5.5: Modelo de Entidade Relacional do IPSMA. ... 47
Figura 5.6: Dados coletados antes de serem processados. ... 48
Figura 5.7: Integrated Platform for Security Metrics Analysis. ... 48
Figura 5.8: Tela de configuração de uma métrica. ... 49
Figura 5.9: Gerenciamento das métricas. ... 50
Figura 6.1: Laboratório de Redes de Comunicações (LaRCom)... 53
Figura 6.2: Fluxo de aplicação das métricas utilizando o IPSMA. ... 55
ix
Figura 6.4: Configuração da Métrica Uptime. ... 58 Figura 6.5: IPSMA atuando no monitoramento do LaRCom. ... 59 Figura 6.6: Quantidade total de horas que os serviços dos servidores permaneceram ativos. ... 60 Figura 6.7: Quantidade total de horas que os serviços dos servidores permaneceram interrompidos. ... 61 Figura 6.8: Dias que os componentes sofreram interrupção. ... 63 Figura 6.9: TOP 10 Open Ports. Extraída de (ISC, 2012)... 66
x
LISTA DE TABELAS
Tabela 6.1: Quantidade de vezes por semana que os serviços dos servidores sofreram interrupções. ... 62 Tabela 6.2: Modelo dos processadores e versão do sistema operacional. ... 64 Tabela 6.3: TOP 5 Open Ports dos servidores do LaRCom ... 65
xi
LISTA DE ABREVIAÇÕES
APV Anomaly Propagation View
CIS Center for Internet Security
CMIP Common Management Information Protocol
COBIT Control Objectives for Information and Related Technologies CORBA Common Object Request Broker Architecture
ERP Enterprise Resource Planning GUI Graphical User Interface HTTP Hypertext Transfer Protocol ICMP Internet Control Message Protocol IETF Internet Engineering Task Force
IP Internet Protocol
IPFIX Internet Protocol Flow Information Export IPSMA Integrated Platform for Security Metrics Analysis IPTV Internet Protocol Television
LARCOM Laboratório de Redes e Computação da Universidade Estadual de Campinas
MIB Management Information Base
MVC Model-View-Controller
NIST National Institute of Standards and Technology NVD National Vulnerability Database
OID Object Identifier
RMI Remote Method Invocation
SANS SysAdmin, Audit, Network, Security SDT Security, Dependability and Trust SECOM Security Monitoring
SIGM Sistema Integrado de Gestão Municipal SNMP Simple Network Management Protocol TCP Transmission Control Protocol
TMN Telecommunications Management Network
xii UML Unified Modelling Language VOIP Voice Over Internet Protocol VPN Virtual Private Network
1 1 INTRODUÇÃO
Os ambientes de comunicação têm presenciado uma mudança de paradigma. As redes de transmissão de voz, dados e vídeo estão convergindo para uma única rede multisserviço baseada nas redes IP (Internet Protocol) (Lee, 2000). Esta rede multisserviço pode fornecer uma diversi-dade de aplicações e conteúdos como acesso de banda larga à Internet, VoIP (Voice over IP), vídeo sob demanda e IPTV (Voice Over Internet Protocol). O serviço triple play, por exemplo, baseia-se na combinação da transmissão de dados, voz e multimídia através de uma única cone-xão, o que torna os clientes cada vez mais dependentes da disponibilidade da rede.
Com a convergência das redes de transmissão de voz, dados e vídeo, diversos benefícios podem ser proporcionados, como o aumento nos níveis de produtividade e a redução nos custos operacionais (Mendes et al., 2010). Porém, o aumento das falhas em componentes e nos serviços oferecidos, a descoberta de novos meios de ataque, e a dependência de uma única conexão, faz com que haja uma crescente preocupação com as questões relacionadas à segurança da informa-ção (Miani, 2009). Alguns problemas de segurança podem ocorrer, por exemplo, a ausência de protocolos de segurança em pontos de acesso, a utilização não autorizada de um sistema de in-formação ou a configuração incorreta de firewalls em uma rede de computadores (Swanson et al., 2003). Estes problemas podem comprometer a infraestrutura de comunicação e prejudicar a ima-gem da organização. Em redes de computadores de larga escala, o acompanhamento presencial das falhas torna-se uma tarefa complexa para os administradores de rede e analistas de segurança. Equipamentos e softwares fornecidos por diferentes fabricantes e que atendem a diversos objeti-vos formam um cenário complexo que exige a adoção de novas técnicas para o monitoramento da segurança, com o intuito de possibilitar o processamento de uma grande quantidade de dados e evitar a ocorrência de erros.
Uma alternativa para tentar evitar os problemas de segurança, é a implementação de pro-gramas de métricas de segurança recomendados por importantes organizações na área de segu-rança como SANS (SysAdmin, Audit, Network, Security) (SANS, 2013) e NIST (National
Institu-te of Standards and Technology) (NIST, 2013). Métricas de segurança oferecem uma abordagem
quantitativa para medir e analisar a eficiência dos controles de segurança (Jaquith, 2007). Devido à falta de consenso sobre a definição do termo, a maioria dos autores relaciona o conceito de
mé-2
tricas de segurança com a quantificação e análise de dados específicos de segurança (Miani, 2009).
A métrica Uptime, por exemplo, (Jaquith, 2007) tem como objetivo principal calcular a quantidade total de horas que os serviços de um computador, aplicação ou servidor permanece-ram ativos. Dessa forma, pode auxiliar na gerência da segurança na organização apresentando informações importantes como: i) quantidade de horas que os serviços de um servidor permane-ceram interrompidos; ii) quantidade de reinicializações inesperadas de um servidor; iii) dias em que os serviços de um servidor sofreram interrupções.
No entanto, uma das dificuldades encontradas na aplicação de métricas de segurança, quando feita de uma forma não automatizada, é o longo tempo necessário para a coleta e análise dos dados (Miani et al., 2010), (Ertürk, 2008) e (Jaquith, 2007). O desenvolvimento de ferramen-tas que realizam essa automação pode ser uma forma eficiente de auxiliar a aplicação de métricas em redes de computadores que possuem uma diversidade de equipamentos.
Outros benefícios também podem ser alcançados através da automação, por exemplo: maior precisão do processo de execução das métricas, aumento na frequência de medição e confi-abilidade dos dados coletados. Porém, apenas automatizar a coleta dos dados que compõem as métricas não é suficiente. É importante que exista um modelo para análise, gerenciamento e visu-alização das informações providas pelas métricas de segurança. A visuvisu-alização das informações através de imagens, gráficos e relatórios pode auxiliar o administrador de rede no gerenciamento da segurança da informação, além de ajudar a interpretar dados relacionados à segurança (Savola and Heinonen, 2010).
1.1 MOTIVAÇÕES
O desenvolvimento deste trabalho foi motivado de acordo com os seguintes fatores: • Melhorar o gerenciamento da segurança da informação com a aplicação de métricas
de segurança;
• Alto custo para quantificação da informação relacionada à segurança, considerando o tempo e o esforço dispensados pelo administrador de rede ao coletar e analisar os da-dos manualmente;
3
• Dificuldade no gerenciamento das informações devido à falta de ferramentas integra-das para auxiliar a coleta e análise dos dados de segurança;
• A necessidade de um modelo para o gerenciamento das métricas e facilitar a visuali-zação dos resultados obtidos a fim de auxiliar o administrador de rede nas tomadas de decisões.
1.2 CONTRIBUIÇÕES DA DISSERTAÇÃO
A principal contribuição deste trabalho é o desenvolvimento de uma arquitetura baseada em um modelo gerente-agente para permitir a automação da coleta de dados de diferentes com-ponentes em uma rede de computadores baseada no protocolo IP, a fim de ampliar e facilitar a aplicação de métricas de segurança. A arquitetura proposta também é capaz de integrar o controle das informações em uma única plataforma de gerência e auxiliar o processo de monitoramento da segurança. Outras contribuições desta dissertação são:
• Definição de critérios para criação/seleção de métricas que são passíveis de automa-ção.
• Apresentação de métricas de segurança passíveis de automação baseadas nos critérios propostos.
• Criação de arquitetura baseada no modelo de gerente-agente que permita o desenvol-vimento de uma ferramenta integrada para automação da coleta dos dados das métri-cas.
• Desenvolvimento de uma ferramenta integrada que realiza a coleta dos dados das mé-tricas de segurança de uma forma automatizada utilizando a arquitetura proposta. • Criação de um modelo para facilitar o gerenciamento das métricas e visualizar os
re-sultados obtidos, com o intuito de auxiliar o administrador de rede nas tomadas de de-cisões.
• Apresentação dos resultados da aplicação de métricas de segurança em um ambiente real de computadores.
4 1.3 ORGANIZAÇÃO DO TRABALHO
O Capítulo 2 apresenta os trabalhos relacionados a métricas de segurança, automação da coleta dos dados e visualização das informações. Neste capítulo também são apresentados as principais diferenças entre a proposta deste trabalho e os trabalhos existentes. O Capítulo 3 apre-senta diversos critérios utilizados para selecionar quais métricas de segurança podem ser automa-tizadas. O Capítulo 4 apresenta com detalhes a arquitetura proposta para automação da coleta dos dados das métricas de segurança. O Capítulo 5 apresenta os detalhes da implementação da ferra-menta desenvolvida para validar a arquitetura proposta. O Capítulo 6 apresenta um estudo de caso da aplicação de métricas de segurança no LaRCom (Laboratório de Redes e Comunicação da Unicamp) e discute os resultados obtidos.
5 2 TRABALHOS RELACIONADOS
O objetivo deste capítulo é apresentar os conceitos básicos relacionados à área de métricas de segurança, os benefícios de sua aplicação e as dificuldades encontradas nos trabalhos já reali-zados. Serão apresentados também modelos que permitem a automação da coleta dos dados das métricas e diferentes modelos para visualização das informações. Por fim, será proposta uma so-lução para resolver os problemas encontrados nos trabalhos relacionados.
2.1 MÉTRICAS DE SEGURANÇA
A segurança da informação das organizações é um fator essencial para a prestação de ser-viços nos quais elementos como confiabilidade e integridade dos dados devem ser preservados. Com o avanço da tecnologia e o surgimento de novas demandas, por exemplo, o uso de voz sobre IP (VoIP), surgiram também novas questões relacionadas a segurança da informação que podem impactar na qualidade dos serviços prestados.
A aplicação das métricas de segurança surge como uma opção para medir e avaliar as questões da segurança da informação e fornecer informações aos administradores sobre o estado da rede de uma organização com relação à segurança da informação. Além disso, as métricas contribuem para auxiliar a avaliação dos processos de segurança desenvolvidos e medir os custos e a eficiência dos controles das organizações (Jaquith, 2007).
O desenvolvimento de métricas de segurança e sua aplicação são discutidos em (Swanson et al., 2003), (The Center for Internet Security, 2010), (Black et al., 2009), (Wayne and Miles, 2007), (Henning, 2001) e (Kovacich, 1997). Swanson et al. (2003) utilizam a seguinte definição para métricas: são ferramentas projetadas para facilitar a tomada de decisões e aumentar a per-formance e prestação de contas através da coleta, análise e apresentação dos dados. Outra defini-ção é encontrada em (Kovacich, 1997): métrica é um padrão de medidas utilizando análises quan-titativas, estatísticas ou matemáticas. Jaquith (2007) afirma que qualquer problema de quantifica-ção que resulta em um valor numérico pode ser visto como uma métrica.
6
Alguns exemplos de métricas de segurança são: i) quantidade total de horas que os servi-ços de um computador, aplicação ou servidor permaneceram interrompidos; ii) porcentagem de desktops, servidores e notebooks com softwares antivírus e antisspam instalados; iii) porcenta-gem de senhas e PINs (Personal Identification Number) que são armazenados em hashs cripto-gráficos (Jaquith, 2007), (Ertürk, 2008) e (Securitymetrics.org, 2013).
Para facilitar a aplicação de métricas de segurança em redes de computadores, Ertürk (2008) divide o processo de aplicação das métricas em três grandes tarefas: i) coletar os dados necessários relativos à segurança da informação, como o número de terminais com antivírus ins-talado, o número de pontos de acesso com protocolos criptográficos, disponibilidade de servido-res; ii) analisar as informações providas pelas métricas; iii) tomar decisões conforme os resulta-dos obtiresulta-dos.
Ao aplicar as métricas, diversos benefícios podem ser obtidos para a gestão da segurança da informação, como: compreensão dos riscos de segurança, alertas para os problemas iminentes, compreensão das fragilidades na infraestrutura de segurança e incentivo no uso da tecnologia para melhorar os processos (Jaquith, 2007).
A Figura 2.1 ilustra as métricas atuando sobre os controles de segurança de uma organiza-ção. Estes controles são importantes para tentar evitar problemas relacionados às informações e a infraestrutura da organização. Nesse contexto, as métricas são aplicadas com o intuito de analisar a eficiência dos controles de segurança e auxiliar a avaliação dos processos e dos serviços desen-volvidos. Dessa forma, o administrador de rede pode tomar decisões com base nas informações providas pelas métricas e melhorar a segurança da informação.
7
Miani (2009) propõe uma metodologia para facilitar o processo de análise dos dados obti-dos com a aplicação de métricas. Esta metodologia está dividida nas seguintes fases: i) preparar o ambiente para a coleta dos dados; ii) automatizar as ferramentas de coleta de dados; iii) coletar dados; iv) cálculo das fórmulas de cada métrica; v) organizar as métricas em ordem decrescente de acordo com o resultado da fórmula; vi) agrupar os resultados de cada métrica de acordo com sua classificação; vii) analisar dados coletados em cada métrica.
Além disso, o autor implementa métricas de segurança e aplica em um ambiente de co-municação de larga escala, com o intuito de medir a eficiência dos programas de segurança e a-poiar o planejamento das ações contra os problemas detectados. São apresentadas doze métricas de segurança e discutidos os resultados obtidos na tentativa de estabelecer políticas de segurança.
Dentre as dificuldades relatadas, a necessidade de coletar muito dados de entrada para a-limentar as métricas pode se tornar um problema para os administradores de rede. Durante a apli-cação das métricas de segurança, a ausência de uma ferramenta específica para auxiliar na coleta dos dados, gravá-los em uma base de dados específica e apresentar estatísticas dos resultados gerou um aumento no esforço e no tempo necessário para coleta e análise dos dados.
O processo de extração dos dados pode depender de softwares adequados, estrutura com-putacional bem definida e administradores de rede competentes. Dessa forma, podemos concluir que a aplicação de métricas possui alta dependência tecnológica e organizacional.
2.2 AUTOMAÇÃO DA COLETA DOS DADOS DAS MÉTRICAS
A extração dos dados de segurança dos elementos em uma rede pode ser realizada utili-zando basicamente dois métodos: manualmente ou através de processos automatizados. A coleta manual pode ser caracterizada como uma coleta realizada sem a intervenção de máquinas, com-putadores ou sistemas. Logo, o aumento da quantidade, diversidade e complexidade das métricas, pode implicar em um grande custo de tempo e esforço dos envolvidos no processo.
Em (Miani, 2009), o autor apresenta um exemplo de uma métrica que necessita de dados, como o número computadores da rede que possuem antivírus instalado. Em uma rede com 150 computadores, torna-se totalmente inviável o administrador de rede deslocar-se máquina por má-quina para realizar a coleta dos dados. Neste caso, é necessária a utilização de uma ferramenta ou
8
um sistema que faça uma auditoria nos computadores, apresente os softwares instalados e salve os resultados obtidos em um relatório. Portanto, é notória a necessidade da automação da coleta dos dados das métricas em determinados casos.
Processos automatizados podem ser definidos como qualquer operação controlada por um aparelho, processo, sistemas de dispositivos mecânicos ou eletrônicos que substituem o trabalho humano. Como exemplo, podem ser citadas diversas rotinas e ferramentas complexas como ana-lisadores de protocolos e logs de auditoria (Miani et al., 2010).
Segundo Jaquith (2007), o principal objetivo da automação é aumentar a maturidade das organizações através de medições e análises, transformando dados brutos em informações que possam auxiliar o administrador de rede nas tomadas de decisões. Dessa forma, diversos benefí-cios podem ser providos ao aplicar métricas de segurança de uma forma automatizada, por exem-plo:
• Precisão (Accuracy): A automação segue a risca os modelos para aplicação das mé-tricas, proporcionando um aumento na precisão e padronização dos métodos de coleta dos dados. Dessa forma, as medições são realizadas conforme o esperado, evitando re-sultados imprecisos e proporcionando um aumento na confiança da coleta dos dados. • Repetibilidade (Repeatability): A repetibilidade permite a repetição dos métodos
uti-lizados para realizar as medições. Com isso, a subjetividade na coleta dos dados é eli-minada, reforçando a confiança nas medições e comprovação dos resultados obtidos. • Aumento na frequência da coleta (Increased measurement frequency): Através da
automação, os dados das métricas podem ser coletados com a frequência desejada, de uma forma mais rápida e periódica, contribuindo assim para a diminuição do tempo de publicação dos resultados e de tomada de decisão dos administradores de rede.
• Confiabilidade (Reliability): Refese à fidelidade e a consistência das operações re-alizadas quando os dados são coletados de uma forma automatizada. A automação proporciona um aumento na confiabilidade ao realizar operações que, quando realiza-das manualmente, estão supostamente sujeitas a erros humanos. Além disso, os pro-cessos podem ser realizados repetidamente seguindo fielmente as especificações, auxi-liando os administradores de rede nas tomada de decisões que se baseiam em resulta-dos cada vez mais confiáveis.
9
• Transparência (Transparency): As etapas do processo de aplicação das métricas tor-nam-se facilmente visíveis e pré-determinadas através da transparência e da documen-tação. Isto proporciona um aumento no nível de compreensão e aceitação das informa-ções providas pelas métricas, além de facilitar a tarefa do administrador de rede no ge-renciamento da segurança.
• Auditabilidade (Auditability): É a garantia que todas as etapas durante o processo de aplicação das métricas foram realizadas com sucesso. Com isso, os administradores de rede podem consultar informações importantes como: i) o dia e a hora que uma métri-ca iniciou a coleta dos dados; ii) os parâmetros que uma métrimétri-ca utiliza para iniciar a execução; iii) possíveis erros encontrados durante o cálculo das métricas.
As métricas podem ser automatizadas, por exemplo, através de uma plataforma de gerenciamento que permita a integração de diversos recursos, tais como a criação de uma interfa-ce gráfica com o usuário, prointerfa-cessamento distribuído e a utilização de paradigmas de orientação a objetos (Lee, 2000).
O próximo capítulo apresenta os modelos já existentes que realizam a coleta automatizada dos dados e também descreve as diferenças entre a solução proposta nesta dissertação e os traba-lhos encontrados na literatura.
2.3 MODELOS PARA AUTOMAÇÃO DA COLETA DOS DADOS DAS MÉTRICAS
Ertürk (2008) propõe um modelo para o monitoramento de segurança baseado em métri-cas, com o intuito de analisar o nível de segurança das informações continuamente. Para tanto, é necessário coletar os dados, processá-los e relatar os resultados de acordo com as necessidades das organizações. Testes foram realizados em uma organização governamental como forma de validação. Esta abordagem dividiu-se em cinco partes: selecionar métricas de segurança, desen-volver as métricas, coletar os dados, reportá-los e analisá-los.
A primeira parte do processo é selecionar as métricas de segurança. Primeiramente foram realizadas reuniões com os administradores de rede e discutidas as questões relacionadas à segu-rança da informação presentes na organização. Baseando-se nos principais problemas reportados foram selecionadas as métricas de segurança, entre elas: i) quantidade de portas abertas não
apro-10
vadas em servidores; ii) quantidade de spams detectados em mensagens de email; iii) quantidade total de transações realizadas no servidor de aplicação; iv) porcentagem de computadores com antivírus instalado.
Nestas reuniões também foram desenvolvidas as métricas e definidos seus atributos, por exemplo, a fonte de dados, a frequência de coleta e o objetivo principal de cada métrica. Com as métricas selecionadas e desenvolvidas, a próxima etapa é a coleta dos dados. Para isso, foram utilizadas diversas ferramentas de monitoramento, como o PRTG Network Monitor (PRTG, 2013), Nessus Vulnerability Scanner (Nessus, 2013), entre outros. Os dados coletados foram gra-vados em uma base de dados única. Logo, as informações foram reportadas através de uma fer-ramenta chamada SECMON (Security Monitoring) que permite a geração de gráficos e relatórios. Por fim, coube aos administradores de rede a tarefa de analisar as informações, contemplando assim o processo de aplicação das métricas.
Outro exemplo de um modelo para análise de segurança utilizando métricas é encontrado em (Sun et al., 2011). Neste trabalho, o autor apresenta uma solução que permite a coleta dos dados de uma forma automatizada e uma análise das informações providas pelas métricas de se-gurança. A Figura 2.2 apresenta uma visão geral deste modelo proposto.
Figura 2.2: Visão geral do modelo proposto por Kun Sun. Extraída de (Sun et al., 2011)
Ao observar este exemplo, é possível perceber que o autor utiliza três fontes de dados para obter informações da rede: Nessus Vulnerability Scanner, NVD (National Vulnerability
relaciona-11
das à segurança, por exemplo, detecção de possíveis invasões na rede, identificação de portas ativas para um endereço IP e informações sobre acessibilidade nos roteadores da rede. Estes da-dos podem ser coletada-dos através do Nessus Scanner e com isso utilizar a base de dada-dos NVD para encontrar os detalhes de cada vulnerabilidade.
Um estudo de caso foi realizado e as seguintes métricas de segurança foram aplicadas: • Correção ou Atualização: A aplicação de um patch de segurança para correção de
vulnerabilidades em aplicações pode ter um efeito adverso. Esta métrica busca repre-sentar o risco existente durante a aplicação de patches e pode ser calculada de acordo com a confiabilidade da sua aplicação e o tempo que o patch foi lançado e aplicado. • Séries Temporais: Representa as mudanças de segurança ocorridas em um
computador ou em uma rede durante um período de tempo. Com isso o administrador de rede pode ter uma ideia de quanto a segurança da informação tem melhorado ou se está abaixo do esperado. CVSS (Swanson et al., 2003) fornece métricas temporais pa-ra refletir o quanto uma vulnepa-rabilidade pode ser representada como uma ameaça e as mudanças ocorridas ao longo do tempo.
• Importância: Tem por função avaliar a importância de um computador na rede. Pode ser composta a partir de quatro medidas de segurança: i) localização do computador na rede (intranet, Internet ou DMZ); ii) quantidade de serviços e aplicações que utilizam o computador; iii) função do computador na rede (Servidor, firewall, roteador ou desktop) iv) valor patrimonial do computador. Como exemplo, considerando a locali-zação de dois computadores em uma rede, o computador localizado em uma DMZ po-de ter menos impacto na segurança que um computador localizado na intranet.
• Pontuação de Segurança: Tem por finalidade fornecer uma pontuação final da avali-ação da segurança de um componente de uma rede. Este resultado pode ser obtido analisando a pontuação das vulnerabilidades em uma base CVSS. Com isso esta mé-trica pode auxiliar o administrador de rede a comparar o nível de segurança entre os componentes de uma rede.
Para análise dos resultados obtidos foi utilizado o processo AHP (Analytic Hierarchy
Process) que é uma técnica estruturada para lidar com decisões complexas. Ao utilizar esta
12
de forma independente e por comparação, facilitando o processo de análise. No caso das métricas de segurança, esse processo pode ser utilizado para realizar a composição das métricas e aproxi-mar-se em um valor quantitativo final.
Ao utilizar as abordagens apresentadas em Ertürk (2008) e (Sun et al., 2011), algumas di-ficuldades podem ser encontradas durante o processo de coleta dos dados. Uma delas é a ausência de uma ferramenta integrada para realizar a coleta dos dados e auxiliar na análise dos dados de segurança em redes heterogêneas. Podemos novamente citar o exemplo de uma métrica que ne-cessite de dados como o número computadores da rede que possui antivírus instalado. Neste caso, o administrador de rede precisará utilizar outras ferramentas para realizar a coleta automatizada o que dificulta o gerenciamento das métricas e o controle das informações.
Outros modelos que possibilitam o monitoramento de uma rede de computadores também são encontrados em (Lee, 2000), (Ying and Zhao, 2010), e (Park et al., 1998). Lee (2000) apre-senta um modelo para gerenciamento de redes baseada no modelo de arquitetura TMN
(Tele-communications Management Network), que utiliza a tecnologia JAVA e possibilita um controle
de funções, como envio e recebimentos de operações aos componentes da rede, alarmes e dados de desempenho. Neste caso, é possível realizar a coleta dos dados das métricas de uma forma automatizada, mas o autor não se baseia nos conceitos de métricas de segurança desenvolvidos por NIST (2013), SANS (2013) e COBIT (2013). Além disso, realizar a coleta dos dados automa-ticamente não é o propósito do autor.
Já em (Park et al., 1998), como neste trabalho, é proposta uma arquitetura de gerencia-mento de rede baseada no modelo gerente-agente utilizando a linguagem de programação JAVA. Porém não tem como foco principal gerenciar a rede através de métricas de segurança, e sim ten-tar reduzir a complexidade envolvida nas questões de gerência de rede e alguns problemas encon-trados no SNMP, por exemplo, sobrecarga no gerenciamento e baixo nível de segurança e porta-bilidade entre arquiteturas diferentes. O objetivo principal do autor é estudar a viaporta-bilidade desta linguagem para o gerenciamento de rede. Para isso, a comunicação entre o gerente e o agente é implementada em Java e os resultados comparados com uma abordagem que utiliza o SNMP. Por fim, o estudo conclui que a implementação baseada em JAVA fornece uma segurança mais refor-çada e facilita a programação ao utilizar os conceitos de orientação a objetos.
Ying e Zhao (2010) apresentam situações em que a tecnologia JAVA pode ser utilizada para auxiliar no gerenciamento de uma rede. Buscando se adaptar ao rápido desenvolvimento da
13
tecnologia da informação, novos conceitos no desenvolvimento de ferramentas para gerencia-mento devem ser utilizados, por exemplo, gerenciagerencia-mento distribuído, cliente-servidor e gerente-agente. A utilização destes conceitos pode trazer diversos benefícios como utilização de recursos de orientação a objetos, reutilização de código e transparência nos serviços. Além disso, pode aumentar a produtividade do desenvolvedor e a qualidade do software.
O aumento na diversidade de equipamentos que atuam em uma rede IP possibilita uma in-teroperabilidade entre diversos serviços e recursos que utilizam interfaces de gerenciamento co-mo, o Simple Network Management Protocol (SNMP), Common Management Information
Pro-tocol (CMIP), Common Object Request Broker Architecture (CORBA) e Remote Method Invoca-tion (RMI) (Lee, 2000). Dessa forma diversos equipamentos podem ser gerenciados através de
uma aplicação integrada que pode ser desenvolvida utilizando recursos providos pela tecnologia JAVA.
2.4 MODELOS PARA VISUALIZAÇÕES DAS INFORMAÇÕES
Vimos que o processo de realizar a coleta dos dados das métricas de uma forma automati-zada é muito importante para auxiliar o administrador de rede durante a aplicação das métricas de segurança. Também foram apresentados alguns modelos que permitem a realização desse proces-so. Porém, apenas automatizar a coleta os dados das métricas não é suficiente. É necessário um modelo para auxiliar na análise e no gerenciamento da segurança. Além disso, neste capítulo são apresentadas algumas soluções para facilitar a visualização das informações com o intuito de au-xiliar o administrador de rede no gerenciamento das métricas.
Uma ampla visão sobre a visualização da segurança da informação é apresentada em (Shi-ravi et al., 2012), (Marty, 2008), (Savola and Heinonen, 2010) e (Sun et al., 2011). Savola (2010), afirma que a visualização das informações é basicamente a representação gráfica dos dados cole-tados e processados pelas métricas. Outro conceito também é definido por (Marty, 2008). Neste livro, o autor diz que a visualização, no sentido de segurança, é o processo de geração de imagens baseados em registros de logs e tem como finalidade mostrar estes registros em forma de repre-sentação visual.
14
Shiravi (2012) apresenta diversas questões relacionadas à visualização, com o intuito de fornecer uma orientação para os pesquisadores na área. Um dos pontos que o autor cita é a diver-sidade das técnicas de visualização que podem ser utilizadas. Tabelas, gráficos de dispersão, grá-ficos de barras e principalmente grágrá-ficos que apresentam informações que podem ser correlacio-nadas, comparadas e que proporcionam um maior feedback ao usuário são alguns exemplos re-comendados para utilização. As cores também são muito importantes e podem ser utilizadas para enfatizar as diferenças, semelhanças e transmitir significados. Além disso, a forma de visualiza-ção deve ser acima de tudo informativa e esteticamente agradável para o usuário.
Marty (2008) também ressalta a importância da visualização para a segurança e apresenta algumas vantagens que podem ser obtidas através de uma ferramenta que proporcione uma boa representação das informações:
• Responder a questões iminentes: A informação pode ser apresentada através de i-magens e gráficos de uma forma concreta e concisa. Dessa forma, facilita o trabalho do administrador de rede e evita a necessidade de vasculhar uma grande quantidade de dados em busca de respostas.
• Explorar e descobrir: Ao utilizar diferentes gráficos e formas de representações é possível identificar informações anteriormente desconhecidas e auxiliar na prevenção de possíveis falhas e questões relacionadas à segurança.
• Auxiliar a tomada de decisões: A visualização das informações mostra o estado da rede e apresenta uma grande quantidade de dados de uma forma rápida e confiável. Dessa forma, ao analisar os gráficos, o administrador de rede pode tomar decisões ba-seando-se nas informações apresentadas.
• Transmitir informações: O principal objetivo da visualização é transmitir o máximo de informação possível. Na maioria dos casos, a apresentação gráfica das informações é mais eficaz e compreensível que a apresentação das informações em formato de ar-quivos de texto.
Uma das contribuições do trabalho de (Sun et al., 2011) é o desenvolvimento de uma fer-ramenta em JAVA, a qual possui uma GUI (Graphical User Interface) que permite ao adminis-trador de rede consultar as informações providas pelas métricas através de gráficos e relatórios. Testes foram realizados e foi comprovado que uma visualização detalhada das informações é
15
capaz de auxiliar os administradores a compreender melhor o estado da segurança da rede e a gerenciar a aplicação das métricas de segurança. A ferramenta pode ser visualizada na Figura 2.2. Além disso, também é apresentada uma ferramenta para visualização desenvolvida em JAVA com o intuito de auxiliar os administradores de rede no gerenciamento das métricas. São utilizados gráficos tradicionais, por exemplo, gráficos em barra, pizza, anéis e histogramas. Atra-vés da ferramenta também é possível importar a topologia da rede o que facilita a visualização da configuração do estado da rede. O painel principal da ferramenta pode ser visualizado na Figura 2.3.
Figura 2.3: Visualização das métricas de segurança. Extraída de (Sun et al., 2011)
Já no trabalho proposto por Amaral et al. (2012), é apresentada uma arquitetura para cor-relação de alarmes composta por três camadas que tem como objetivo obter os alarmes gerados em diversos pontos da rede e apresentar ao administrador uma visão global do cenário afetado pela anomalia. A arquitetura possui uma camada de visualização responsável por apresentar o caminho de propagação da anomalia e os componentes da rede que foram afetados. Para este fim, foi desenvolvida a ferramenta Anomaly Propagation View (APV). A arquitetura proposta foi va-lidada com estudos de casos utilizando dados reais do tráfego da rede da Universidade Estadual de Londrina.
A Figura 2.4 apresenta uma visão geral da ferramenta APV. O item 1 mostra a barra de ferramentas com as opções de importar ou abrir os dados dos alarmes, salvar o mapa de
propa-16
gação da anomalia dentre outros. No item 2, é apresentado o resultado final do processo de cor-relação dos alarmes, no qual é possível visualizar com detalhes os componentes e os enlaces da rede afetados pelo um evento anômalo. Uma tabela contendo detalhes do resultado do processo de correlação pode ser visto no item 3.
Figura 2.4: Anomaly Propagation View. Extraída de (Amaral et al., 2012)
Portanto, podemos concluir que uma ferramenta para auxiliar no gerenciamento das mé-tricas e visualizar informações obtidas é importante para facilitar e complementar o processo de aplicação e coleta dos dados, oferecer informações sobre o estado da segurança e apresentar o status atual dos componentes da rede para o administrador.
2.5 SOLUÇÃO PROPOSTA NESTE TRABALHO
As métricas de segurança surgem como uma alternativa para medir e quantificar a segu-rança da informação em uma rede de computadores. No entanto, a necessidade de muitos dados de entrada para alimentar as métricas pode gerar um grande custo de tempo e esforço dos envol-vidos no processo quando a coleta é realizada de uma forma manual. O principal objetivo desta
17
dissertação é propor uma arquitetura que permita a coleta dos dados de uma forma automatizada e auxilie no monitoramento da segurança da informação.
Outra dificuldade é a ausência de uma ferramenta integrada para realizar a coleta dos da-dos de uma forma automatizada e que utilize os conceitos de métricas de segurança desenvolvi-dos pelas grandes organizações, como NIST e SANS. A solução proposta neste trabalho baseia-se no modelo gerente-agente e realiza a coleta dos dados de diferentes componentes de uma rede de computadores de uma forma integrada e automatizada, baseando-se também nos conceitos pro-postos pela NIST, SANS e COBIT.
Além disso, uma das contribuições deste trabalho é a apresentação de um modelo para vi-sualização das informações e gerenciamento das métricas, com o principal objetivo de auxiliar o administrador de rede durante o processo de aplicação das métricas e facilitar a visualização das informações.
O próximo capítulo apresenta o processo de aplicação de métricas de segurança, os crité-rios que devem ser utilizados para criação/seleção de métricas de segurança e como selecionar as métricas que são passíveis de automação.
18 3 APLICAÇÕES DAS MÉTRICAS
O CIS (Center for Internet Security) (2010) é uma organização sem fins lucrativos cujo objetivo é melhorar a segurança da informação das organizações públicas e privadas em geral. Em um dos seus trabalhos, foi desenvolvido um guia que ajuda as organizações a selecionar mé-tricas de segurança viáveis. Este guia afirma que a primeira etapa para implementar um programa de métricas de segurança é selecionar um conjunto de métricas que satisfaça os interesses da or-ganização e auxilie os gestores de segurança nas tomadas de decisões (The Center for Internet Security, 2010).
Neste capítulo serão apresentados os critérios existentes para selecionar as métricas de se-gurança, as taxonomias que podem contribuir para este processo e os novos critérios propostos neste trabalho, na tentativa de auxiliar o administrador de rede a selecionar apenas as métricas que são passíveis de automação.
3.1 CRITÉRIOS PARA SELECIONAR MÉTRICAS
A aplicação de métricas mal planejadas ou inadequadas pode trazer a falsa sensação de segurança e perda de credibilidade das medições, mas o que realmente torna uma métrica “boa”? Quais atributos ela deve possuir? O processo de coleta de dados dessa métrica pode ser automati-zado? Jaquith (2007) propôs o seguinte conjunto de características desejáveis para facilitar o pro-cesso de seleção das métricas de segurança:
• Definida de maneira consistente, sem critérios subjetivos. • Fácil de coletar, de preferência de modo automatizado.
• Expressa em números cardinais ou porcentagem, não de maneira qualitativa com rótu-los como “alto”, “médio” e “baixo”.
• Expressa utilizando ao menos uma unidade de medida, tais como “defeitos”, “horas” ou “dólares”.
• Suficientemente relevante a fim de que as decisões possam ser tomadas com base nos resultados das métricas.
19
Wayne e Miles (2007) também apresentam alguns atributos para definir um bom conjunto de métricas:
• Ser de fácil compreensão, mensuráveis e objetivas.
• Estar diretamente relacionadas ao risco de segurança da informação. • Apresentar informações consideradas importantes do sistema de segurança.
Além de possuir um conjunto de métricas com as características acima mencionadas, é necessário um planejamento e uma avaliação prévia dos dados que serão utilizados para o cálcu-lo. A falta de planejamento traz algumas desvantagens, por exemplo: custo considerável em re-cursos e tempo para coletar, analisar e gerar relatórios quando na verdade, geralmente, apenas os dados das métricas selecionadas são necessários. Se os dados não forem selecionados e organiza-dos para que suas dependências sejam claras e precisamente representadas, o resultado final da métrica pode ser enganoso (Black et al., 2009).
Portanto, é de extrema importância ressaltar que as métricas selecionadas devem possuir as características acima mencionadas, que satisfaçam os interesses da organização e principal-mente sejam relevantes para auxiliar os gestores nas tomadas de decisões.
3.2 TAXONOMIAS
Outra importante área de pesquisa em métricas de segurança é o desenvolvimento de ta-xonomias que podem auxiliar o processo de seleção e desenvolvimento de diferentes tipos de métricas. Um evento realizado no ano de 2001 e intitulado Workshop on Information Security
System Scoring and Ranking (Henning, 2002) reuniu pesquisadores da área de métricas de
segu-rança para discutir e compartilhar informações relacionadas à segusegu-rança da informação. As dis-cussões foram organizadas em três grandes categorias: métricas técnicas, organizacionais e ope-racionais. Segundo (Savola, 2009), este workshop proporcionou uma base para criação de uma taxonomia, pois logo após este evento, uma classificação foi proposta pela NIST (Swanson, 2001) que sugere as mesmas três categorias e também mais dezessete subcategorias para organi-zar as métricas. Esta classificação agrupa as métricas como:
• Técnicas: Enquadram-se as métricas que são utilizadas para avaliar e/ou comparar ob-jetos técnicos, como algoritmos, especificações, arquiteturas, modelos e produtos.
20
• Operacionais: Todas as métricas operacionais que tem por finalidade avaliar e/ou ge-renciar os riscos, práticas e os processos operacionais relacionados a segurança. • Organizacionais: Abrange as métricas que tem como objetivo principal avaliar a
efi-cácia dos programas e dos processos de segurança utilizados na organização.
Outra forma de classificação também pode ser encontrada em (Savola, 2007). Neste arti-go, o autor propõe a criação de uma taxonomia e considera os seguintes níveis de classificação de métricas: métricas de segurança para análise de custo-benefício; métricas de confiança para análi-se de riscos em termos de negócios; métricas de análi-segurança para gestão da informação e métricas de segurança de produtos, sistemas e serviços (SDT).
Jaquith (2007), COBIT (2013) e ISO/IEC (2013) também propõem taxonomias para clas-sificar as métricas de segurança. Jaquith (2007), baseando-se na classificação proposta pela NIST (Swanson, 2001), organiza as métricas em dois grandes grupos: métricas técnicas e métricas de eficiência de processo. As métricas técnicas permitem a identificação e diagnóstico de problemas de segurança em toda infraestrutura (física e lógica) de uma organização e, geralmente, não ne-cessitam da intervenção humana para coletar os dados. Já as consideradas métricas de eficiência de processo, são responsáveis por medir a eficiência dos programas e dos controles de segurança implementados, os quais são elaborados baseados em normas e práticas definidas pelas grandes organizações de segurança (Miani et al., 2010) e (Ertürk, 2008).
Um projeto interessante que também pode auxiliar na seleção das métricas é o Metrics Center ou catálogo de métricas que é mantido pelo portal SecurityMetrics.org (2013). Este proje-to possui um catálogo de métricas destinado a pesquisadores e colaboradores da área que possibi-lita a organização e o compartilhamento de definições de métricas e tem por principal objetivo promover a utilização das métricas de segurança de uma forma eficiente. A Figura 3.1 apresenta a tela do sistema de catalogação de métricas.
21
Figura 3.1:Metrics Catalog, um serviço do projeto Metrics Center. Extraída de (Securitymetrics.org, 2013) Cada uma das métricas catalogadas possui atributos que tem por função apresentar suas características, por exemplo, o objetivo da métrica, a frequência de coleta dos dados e a unidade de medida. A Figura 3.2 exemplifica uma métrica de segurança e o modelo de métricas utilizado em (Securitymetrics.org, 2013).
22
Figura 3.2: Métrica de segurança seguindo o modelo utilizado pelo Metrics Center. Extraída de (Securitymetrics.org, 2013)
Neste trabalho, também será necessário definir um modelo com os atributos das métricas com o intuito de facilitar a organização e a seleção das métricas. Com base nos modelos utiliza-dos em (Miani, 2009), (Swanson et al., 2003), (NIST, 2013), (Jaquith, 2007), (Miani et al., 2010) e (Ertürk, 2008), o modelo proposto e utilizado neste trabalho possui os seguintes atributos:
• Definição: Nome da métrica e sua definição.
• Objetivo: Principal objetivo ao aplicar a métrica de segurança.
• Processamento dos dados: Este atributo representa a fórmula utilizada no cálculo das métricas e tem como objetivo principal descrever a rotina responsável por processar os dados coletados e transformá-los em informações úteis para o administrador de rede. • Origem dos Dados: Localização (servidor, computador, switches, etc.) dos dados que
serão utilizados para o cálculo das métricas.
• Frequência: Define os períodos de tempo em que os dados serão coletados. A fre-quência pode ser diária, semanal, mensal e etc.
23
• Critério para automação: Critério utilizado para automatizar a coleta dos dados da métrica.
A principal diferença do modelo utilizado neste trabalho para os outros modelo é a criação de um atributo para classificar as métricas de acordo com o critério utilizado para automação da coleta dos dados. Enquanto Miani (2009) classifica as métricas de acordo com componentes da rede (estrutura da rede, pontos de interconexão e serviço), neste trabalho as métricas serão orga-nizadas conforme o critério utilizado para automação. A classificação é detalhada na seção 3.3.
3.3 CRITÉRIOS PARA SELEÇÃO DAS MÉTRICAS PASSÍVEIS DE AUTOMAÇÃO
Uma das contribuições desde trabalho é a criação de critérios para seleção de métricas que possam ser automatizadas. Como a arquitetura proposta neste trabalho visa abranger apenas as métricas que podem ser automatizadas, vamos nos concentrar basicamente nos tipos de métricas que se enquadram como técnicas na classificação abordada por Jaquith (2007), ou seja, métricas cujos dados podem ser coletados em servidores, estações de trabalho e equipamentos da infraes-trutura da organização.
Os dados podem ser coletados dos equipamentos utilizando os protocolos de comunica-ção. Portanto, os critérios são classificados de acordo com as camadas do modelo OSI, utilizado para coletar os dados das métricas, por exemplo, os protocolos da:
• Camada de aplicação: Protocolos SNMP, NetFlow, IPFIX, POP3, SMTP, IMAP e HTTP.
• Camada de rede: Protocolo ICMP.
• Camada de transporte: Protocolos TCP e UDP.
Estes critérios estão baseados na arquitetura TCP/IP, pois o protocolo TCP/IP é o ponto de convergência de diferentes serviços da próxima geração de redes multisserviços. O objetivo prin-cipal dos critérios é auxiliar no processo de seleção das métricas que podem ser automatizadas. Um administrador de rede, por exemplo, pode utilizar os critérios para selecionar dentre um con-junto de diversas métricas existentes, apenas as que podem ser automatizadas. Desta forma, di-versos benefícios podem ser proporcionados. Dentre eles, podemos citar: o auxilio na tomada das
24
decisões, diminuição do tempo de escolha das métricas e a garantia de uma maior confiança du-rante o processo de seleção e automação.
Um exemplo de uma métrica passível de automação é a métrica Uptime. Esta é uma mé-trica clássica da literatura e segundo Jaquith (2007) tem por definição apresentar a quantidade total de horas que os serviços de um computador, aplicação ou servidor permaneceram ativos. O objetivo principal desta métrica é analisar a instabilidade de um equipamento e verificar a exis-tência de discrepâncias entre os resultados obtidos ao longo do tempo. Estes dados podem ser coletados automaticamente através do protocolo SNMP da camada de aplicação do modelo OSI. Uma breve descrição sobre os protocolos de comunicação e como eles podem coletar os dados de uma forma automatizada será apresentada no próximo capítulo.
Portanto, os atributos da métrica Uptime podem ser representados utilizando o modelo proposto neste trabalho:
• Objetivo: Monitorar a quantidade de horas que os serviços dos servidores permanece-ram ativos, na tentativa de estabilizar o tempo de prestação de serviços dos servidores. • Processamento dos dados: Somam-se as horas acumuladas de cada dia e obtém-se a
quantidade de horas total que os serviços dos servidores permaneceram ativos. • Unidade: Horas.
• Origem dos Dados: Servidores. • Frequência: Diariamente. • Referência: Jaquith (2007).
• Critério para automação: Protocolo SNMP.
Outros exemplos de métricas passíveis de automação podem ser citados, por exemplo: i) quantidade de portas dos servidores que permanecem abertas; iii) utilização e dimensionamento do enlace de conexão com a Internet; iii) quantidade de e-mails recebidos que podem ser conside-rados como spam.
As métricas que não atendem aos critérios mencionados anteriormente ou necessitam de uma intervenção manual também são importantes e podem ser implementadas pela organização. Por exemplo, métricas que utilizam dados como:
• Pré-cadastro de componentes (roteadores, servidores, entre outros) da rede que possuem acesso físico controlado.
25
• Quantidade de funcionários da organização que possuem acesso restrito aos equipamentos da rede.
• Valores de equipamentos da rede que necessitam uma consulta ao setor financeiro da or-ganização.
• Dados de funcionários não presentes em uma base de dados e que necessitem de uma con-sulta ao setor de recursos humanos da organização.
• Dados de equipamentos que não pertencem à rede de dados.
Porém, estas métricas que necessitam de intervenção manual estão fora do escopo deste trabalho, pois a arquitetura proposta visa abranger apenas as métricas que são passíveis de auto-mação.
26 4 ARQUITETURA DE COLETA DOS DADOS
Com os critérios para seleção e automação das métricas definidos, é necessário definir uma arquitetura que auxilie a execução do programa de métricas de segurança. A arquitetura pro-posta neste trabalho está baseada em um modelo de gerenciamento gerente-agente e tem como objetivo permitir a automação da coleta dos dados e auxiliar no processo de execução das métri-cas. Neste capítulo serão apresentados os detalhes do modelo gerente-agente, os componentes da arquitetura proposta neste trabalho e como ela pode auxiliar no processo de automação da coleta dos dados.
4.1 MODELO DE GERENCIAMENTO GERENTE-AGENTE
O modelo gerente-agente está bem consolidado na área de gerência de redes de computa-dores e é constituído basicamente por três elementos (Hegering et al., 1998): i) estação de geren-ciamento de rede: um computador cujo principal objetivo é monitorar os recursos gerenciáveis e ajustá-los de acordo com os interesses dos administradores da rede; ii) agentes: estão localizados nos dispositivos de rede (switches, servidores, roteadores, etc.) e possuem objetos gerenciáveis que representam os recursos a serem gerenciados. Através da interação com estes objetos, a esta-ção de gerenciamento é capaz de gerenciar os componentes da rede; iii) protocolo de comunica-ção: permite a troca de dados entre a estação de gerenciamento e os agentes.
A Figura 4.1 ilustra a estrutura de gerenciamento gerente-agente atuando em um ambiente real. Neste exemplo, um computador é utilizado como estação de gerenciamento e utiliza a inte-ração GET request para enviar requisições de dados para diversos dispositivos da rede. O proto-colo utilizado para comunicação é o protoproto-colo SNMP (Simple Network Management Protocol). Segundo a arquitetura SNMP (RFC 1157, 1990), cada agente possui uma base de objetos geren-ciável denominada MIB (Management Information Base). Nesta base estão localizados os dados do dispositivo que serão enviados para o gerente. Além disso, os valores dos objetos de gerencia no agente podem ser alterados através da interação SET, que pode ser utilizado, por exemplo, para desabilitar uma interface de um switch. Dessa forma, ao coletar os dados dos dispositivos de rede, a estação de gerenciamento torna-se capaz de executar rotinas de cálculos das métricas,
27
transformando estes dados brutos em informações úteis aos administradores de rede. Estas infor-mações podem ser apresentadas através de gráficos e relatórios, contribuindo para facilitar a vi-sualização dos resultados e auxiliar o gerenciamento da segurança da informação.
Figura 4.1: Exemplo de uma estrutura de gerenciamento gerente-agente.
Além disso, ao observar a Figura 4.1, é possível notar apenas a utilização do Protocolo SNMP. A utilização do SNMP não é a única forma disponível de coletar dados para realizar o cálculo das métricas de segurança. Diferentes ferramentas como PRTG Network Monitor (PRTG, 2013) e Nessus Vulnerability Scanner (Nessus, 2013) podem ser utilizadas com este mesmo pro-pósito, o que dificulta o controle da informação e a integração dos dados. Dessa forma, reforça-mos a necessidade de uma arquitetura que além de coletar os dados de uma forma automatizada, permita a utilização de diversos protocolos de comunicação simultaneamente e utilize apenas uma única ferramenta para gerenciamento e coleta dos dados.
28 4.2 ARQUITETURA PROPOSTA
A arquitetura proposta neste trabalho é composta por três componentes: (1) rede de com-putadores a ser monitorada; (2) protocolos de comunicação cuja função é realizar a coleta dos dados; (3) estação de gerenciamento que realiza a coleta dos dados das métricas, transforma os dados em informação e apresenta relatórios e gráficos.
A Figura 4.2 apresenta uma visão geral da arquitetura proposta. Neste exemplo, diversos protocolos são utilizados para realizar a coleta dos dados das métricas e transportá-los dos dispo-sitivos da rede para estação de gerenciamento. Além disso, apenas uma única ferramenta será utilizada na estação de gerenciamento para realizar o processo de aplicação das métricas, com o intuito de auxiliar o processo de gerenciamento da segurança da informação e integrar o controle das informações. Os detalhes desta ferramenta serão apresentados no Capítulo 5.
Figura 4.2: Visão geral da arquitetura proposta.
As próximas seções apresentam uma descrição detalhada de cada componente, suas inte-rações e como eles colaboram para ampliar a aplicação das métricas de segurança e auxiliar no gerenciamento das informações.
29 4.2.1 Redes de Computadores
Tanenbaum (2003) define uma rede de computadores como uma infraestrutura de comunicação constituída por um conjunto de computadores e diversos componentes interconectados, a fim de trocar e compartilhar recursos e informações entre si e prover uma variedade de serviços ao usuá-rio. A arquitetura definida neste trabalho visa dar suporte ao monitoramento desta diversidade de componentes que constituem uma rede de computadores, como switches, roteadores sem fio, ser-vidores, laptops e estações de trabalho. Esta gama de equipamentos vem convergindo cada vez mais para atuar sobre uma rede IP, o que permite a disponibilização de uma diversidade de servi-ços, por exemplo, acesso a Internet, tecnologia VoIP (Voice Over Internet Protocol), utilização de sistemas ERP (Enterprise Resource Planning), e-learning, e-health, surveilance, entre outros. Tais serviços podem sofrer impactos significativos causados por falhas em equipamentos, ataques aos servidores ou possíveis vulnerabilidades na rede de computadores.
Todo esse conjunto de elementos heterogêneos possui uma grande quantidade de dados que podem ser importantes para o gerenciamento da segurança da organização. A maioria desses equipamentos dá suporte a protocolos de gerenciamento e possuem uma base de dados de gerên-cia acessível. Dessa forma, os dados de gerêngerên-cia podem ser coletados automaticamente e apoiar a avaliação do nível de segurança da organização. O próximo capítulo apresenta alguns protocolos de comunicação que podem ser utilizados para realizar a gerência e a coleta os dados de seguran-ça.
4.2.2 Protocolos de Comunicação
Uma das formas possíveis de realizar a coleta dos dados dos componentes da rede monito-rada é através do socket (RFC 147, 1971), presente na arquitetura TCP/IP. O socket é uma inter-face que fornece um mecanismo de comunicação utilizando protocolo TCP ou UDP. Dessa for-ma, diferentes aplicações podem ser implementadas para consultar dados de rede, como número de servidores com acesso via SSH liberado, número de portas abertas ou fechadas em um compu-tador, entre outros.
30
Outro protocolo importante é o SNMP (RFC 1157, 1990) que é um protocolo padrão para gerência de redes TCP/IP definido pelo IETF (Internet Engineering Task Force). O SNMP requer poucos recursos para ser implementado e utiliza o protocolo de transporte UDP para efetuar a troca de dados entre agentes e gerentes. Além disso, oferece um conjunto de operações que per-mitem um monitoramento de diversos componentes da rede, como switches, servidores, entre outros. A seguir são descritas duas operações básicas (GET e SET) e suas derivações (GET-NEXT, TRAP).
• GET: utilizada para ler o valor da variável, ou seja, o gerente realiza uma solicitação para que o agente obtenha o valor da variável.
• SET: utilizada para alterar o valor da variável, ou seja, o gerente realiza uma solicitação para que o agente faça uma alteração no valor da variável.
• GET-NEXT: utilizada para obter o valor da próxima variável ou obter valores e nomes de variáveis de uma tabela de tamanho desconhecido.
• TRAP: utilizada para comunicar um evento. Neste caso, o agente comunica ao gerente o acontecimento de um evento previamente determinado, como por exemplo, quando o en-lace de uma comunicação é interrompido, recebimento de uma mensagem SNMP do ge-rente não autenticada, entre outros.
Segundo Mauro et al. (2001), ao utilizar estas operações, é possível coletar os dados do dispositivo gerenciado. Na MIB estão contidas as variáveis, ou objetos de gerência, responsáveis por armazenar as estatísticas de funcionamento do equipamento, como por exemplo, número de interfaces de rede existentes no computador, estado atual da interface (ativada ou desativada), número de bytes recebidos pela interface, entre outros. As informações são organizadas de forma hierárquica. Para requisitar a informação contida em determinado objeto, a requisição deve conter o identificador deste objeto, o qual representa o caminho a ser percorrido na hierarquia de infor-mações da MIB. O objeto de gerência sysuptime, por exemplo, está localizado no grupo system e tem por finalidade armazenar o tempo em que o dispositivo permanece ativo. Para requisitar esta informação é necessário passar como parâmetro o identificador do objeto 1.3.6.1.2.1.1.3. A Figu-ra 4.3 apresenta a árvore de informações de uma MIB.
31
Figura 4.3: Informações da MIB dispostas de uma forma hierárquica. Extraída de (Mauro et al., 2001) Uma terceira forma de coletar os dados dos dispositivos de rede é através do protocolo NetFlow desenvolvido pela Cisco Systems (RFC 3954, 2004). Este protocolo permite que o ad-ministrador de rede exporte e colete os dados do “fluxo” de pacotes dos roteadores que suportem esta tecnologia. Dessa forma, cada interface de um roteador pode ser monitorada e os pacotes coletados e agrupados utilizando os seguintes dados presentes no cabeçalho do pacote: i) endere-ços IP de origem e destino; ii) campo protocolo do cabeçalho IP; iii) portas de origem e destino; iv) campo de tipo de serviço do cabeçalho do protocolo IP.
O roteador realiza a coleta destes dados e os mantém em sua memória. Em determinados períodos de tempo estes dados são exportados para um coletor, que realiza o armazenamento de-finitivo dos registros de fluxos IP. Além disso, os registros de fluxos contêm os timestamps do início e término do fluxo, as flags TCP observadas no monitoramento, a quantidade de bytes e a quantidade de pacotes que trafegavam neste fluxo. Dessa forma, é possível calcular, por exemplo, a taxa de transmissão em bits/s entre duas aplicações de dois nós da rede no fluxo monitorado, os serviços utilizados em cada fluxo através das portas de origem e destino e quantas conexões TCP foram estabelecidas. A correlação das informações de fluxos monitorados em diferentes roteado-res da rede pode ser importante para prover ao administrador uma visão geral de todo o sistema. A Figura 4.4 ilustra a arquitetura do protocolo NetFlow.
