Estação de Gerenciamento ou Gerente

4.2 ARQUITETURA PROPOSTA

4.2.3 Estação de Gerenciamento ou Gerente

A estação de gerenciamento ou gerente tem como principal responsabilidade realizar as requisições de leitura e coleta dos dados dos agentes. Esta tarefa pode ser efetivada, por exemplo, através das operações GET e GET-NEXT do SNMP descritas no Capítulo 4.2.2. Na arquitetura proposta por este trabalho a estação de gerenciamento também é responsável por transformar os dados coletados em informações úteis ao administrador de rede e apresentá-los em forma de rela- tórios e gráficos.

Dessa forma, a estação de gerenciamento necessita de uma ferramenta para desempenhar todas essas funções. A arquitetura da ferramenta utilizada na estação de gerenciamento está base- ada em um modelo MVC (model-view-controller). Este modelo divide as características da fer- ramenta em camadas, com o objetivo de facilitar a manutenção e a criação de novas interfaces. As três camadas básicas e suas respectivas funções são (An Oracle White Paper, 2011):

• Modelo (Model): Representa a camada lógica. Nesta camada estão localizados os conjun- tos de regras de negócio e a persistência dos dados. Também tem por finalidade realizar requisições para leitura e coleta dos dados dos equipamentos da rede de computadores. • Visão (View): Camada de interação com o usuário, ou seja, a interface da aplicação. É

nesta camada que os dados coletados são processados e visualizados pelo administrador de rede através de relatórios e gráficos.

• Controlador (Controller): Camada responsável por determinar o fluxo da aplicação, rea- lizar o processamento das ações dos usuários e transmitir a camada modelo. A Figura 4.5 apresenta as camadas da ferramenta e sua interação com o administrador de rede e a rede de computadores. Nesta figura, um administrador de rede realiza a interação com a camada de visão que permite realizar o gerenciamento da rede de computadores. Em seguida, a camada controladora processa todas as ações para a camada modelo, que executa as requisições dos dados necessários para os dispositivos através dos protocolos de comunicações. Os protocolos retornam com os dados coletados para a camada modelo que realiza a gravação em uma base de dados. Com os dados coletados e armazenados, o administrador de rede pode consultar e analisar as informações utilizando, por exemplo, gráficos e relatórios.

Figura 4.5: Camadas do modelo MVC e suas interações.

É importante ressaltar que é na camada de visão que os dados coletados são processados pelas métricas, ou seja, é nesta camada que os dados são transformados em informações conside- radas indispensáveis para o gerenciamento da informação. Os dados coletados são processados de acordo com o atributo “Processamento dos dados” do modelo de dados. Sendo assim, ao gerar os gráficos e relatórios, estes dados que até o momento eram considerados brutos, são processados e transformados em informações. A maneira com que estes dados são processados e os detalhes da implementação da ferramenta serão mostrados no próximo capítulo.

5 INTEGRATED PLATFORM FOR SECURITY METRICS ANALYSIS (IPSMA)

A ferramenta desenvolvida foi nomeada como Integrated Platform for Security Metrics

Analysis (IPSMA) e implementa a arquitetura proposta neste trabalho. A Figura 5.1 ilustra como

o IPSMA se enquadra no monitoramento de uma rede de computadores baseando-se na arquitetura apresentada na Figura 4.2. Como pode ser visualizado, o IPSMA é executado a partir do computador utilizado como estação de gerenciamento. A ferramenta utiliza diversos protocolos de comunicação para enviar requisições de dados para os diferentes componentes presentes na rede. Os protocolos retornam os dados para estação de gerenciamento, que executam as rotinas de cál- culos das métricas e transformam estes dados brutos em informações importantes ao administrador de rede, que podem ser visualizadas através de gráficos e relatórios. Os detalhes de como a ferramenta utiliza os protocolos para realizar o processo de coleta dos dados, como as rotinas de cálculos das métricas são executadas e o processo de geração dos gráficos e relatórios serão apresentados no decorrer do capítulo.

Uma das funções da ferramenta IPSMA é realizar o processo de coleta dos dados de uma forma automatizada. Este processo de automação da coleta foi implementado através dos concei- tos de orientação a objetos e API’s fornecidas pela linguagem de programação JAVA, como por exemplo, SNMP4J, Socket, JavaMail, etc. Para coletar os dados, cada métrica utiliza seu respec- tivo protocolo de automação apresentado no atributo “critério para automação” do modelo dados. Dessa forma, é possível coletar os dados dos diversos componentes da rede utilizando apenas uma única ferramenta e diversos protocolos simultaneamente, a fim de integrar o controle das informações e auxiliar no processo de monitoramento da segurança.

Os detalhes do desenvolvimento do IPSMA podem ser representados através da lingua- gem UML (Unified Modelling Language). UML é uma linguagem visual, ou seja, uma forma gráfica de representar a modelagem de uma ferramenta. Além disso, tem como objetivo principal fornecer uma maneira comum de expressar relações, comportamentos e ideias na forma de nota- ções que sejam simples e eficientes de entender (Pilone and Pitman, 2005). Os diagramas descri- tos a seguir são utilizados para detalhar o processo de implementação do IPSMA:

• Diagrama de Execução (Runtime View): Tem como finalidade apresentar o comporta- mento dos componentes do sistema (camadas, serviços, beans e outros objetos) durante o processo de execução (Merson, 2006). Dessa forma, é possível verificar as interações entre as camadas do sistema, os componentes que acessam a base de dados e identificar as chamadas locais ou remotas.

• Diagrama de Implantação (Deployment View): Tem por objetivo representar a estrutura lógica dos arquivos implementados. Além disso, pode ilustrar a estrutura física do sistema através de nós de hardware, componentes da rede e suas respectivas relações. Com isso, é possível analisar a ferramenta em termos de processamento, comunicação e dependência entre os componentes.

A Figura 5.2 apresenta o diagrama de execução da ferramenta IPSMA. Já a Figura 5.3 uti- liza um diagrama de Implantação para representar um mapeamento da estrutura lógica dos arqui- vos implementados.

O diagrama de implantação também pode ser utilizado para representar a interação entre a ferramenta IPSMA e os componentes físicos de uma rede de computadores como pode ser visualizado na Figura 5.4.

Figura 5.4: Diagrama de Implantação - Interação entre o IPSMA e os componentes físicos de uma rede de computadores.

Os detalhes do processo de implementação das métricas de segurança também merecem um destaque. Primeiramente, foram selecionadas as métricas levando em consideração os crité- rios de seleção propostos em (The Center for Internet Security, 2010), (Swanson et al., 2003), (SANS, 2013) e (NIST, 2013). Os critérios apresentados no Capítulo 3.3 também foram importantes para selecionar apenas as métricas passíveis de automação. A seguir são apresentadas as nove métricas de segurança selecionadas, organizadas e agrupadas de acordo com os seguintes protocolos utilizados para automação:

• Protocolo SNMP

Métrica 1 - Quantidade total de horas que os serviços dos servidores permaneceram ativos

Métrica 2 - Quantidade total de horas que os serviços dos servidores permaneceram interrompidos.

Métrica 3 - Quantidade de vezes por semana que os serviços dos servidores sofreram interrupções.

Métrica 4 - Dias que os serviços dos servidores sofreram interrupções.

Métrica 5 - Modelo do processador dos computadores e versão do sistema opera- cional instalado.

• Interface socket - Protocolo TCP

Métrica 6 - Número de computadores que permitem acesso via SSH. Métrica 7 - TOP 5 Open Ports.

• Protocolo POP3, SMTP e IMAP

Métrica 8 - Quantidade de e-mails recebidos que podem ser considerados spam. Métrica 9 - Quantidade de e-mails enviados que podem ser considerados spam. A seguir, serão apresentadas as propriedades das métricas, tais como: a definição de cada métrica e seu objetivo principal, como foi implementado o processo de automação da coleta dos dados, os protocolos utilizados, entre outras. Estas informações serão exibidas seguindo o modelo de dados proposto no Capítulo 3.2.

Protocolo SNMP

Métrica 1 - Quantidade total de horas que os serviços dos servidores permaneceram ativos.

Esta métrica, também conhecida como Uptime, tem por finalidade apresentar a quantidade total de horas que os serviços dos servidores permaneceram ativos. Os atributos desta métrica podem ser visualizados no modelo de dados apresentado como exemplo no Capítulo 3.2. Para requisitar estes dados ao agente, a estação de gerenciamento utiliza a interação GET do SNMP e passa como parâmetro a OID (Object Identifier) 1.3.6.1.2.1.1.3, que faz referência ao objeto sy-

suptime e está localizado no grupo system da hierarquia de informações da MIB. Os dados cole-

tados também serão utilizados pelas métricas 2, 3, e 4 que surgem como um complemento para as informações providas pela métrica Uptime.

Métrica 2 - Quantidade total de horas que os serviços dos servidores permaneceram interrompidos.

• Objetivo: Ao contrário da métrica Uptime, a métrica Downtime monitora o tempo em que os serviços dos servidores permaneceram interrompidos. Esta métrica é importante para validar as informações obtidas pela métrica 1.

• 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. Sendo assim, basta diminuir este resultado da quantidade total de horas do período analisado e o resultado final será o tempo que os serviços permaneceram interrompidos.

• Unidade: Horas.

• Origem dos Dados: Servidores. • Frequência: Diariamente. • Referência: Jaquith (2007).

• Critério para automação: Protocolo SNMP.

Métrica 3 - Quantidade de vezes por semana que os serviços dos servidores sofreram interrupções.

• Objetivo: Esta métrica tem como finalidade refinar os resultados obtidos pela Métrica 1 e 2 apresentando o número de interrupções que cada componente sofreu por semana. • Processamento dos dados: Caso em determinado dia do período analisado o valor

coletado for igual à zero ou menor que o valor obtido do dia anterior, então se conclui que ocorreu uma interrupção nos serviços durante essa semana. Logo, através de um contador é possível obter a quantidade de interrupções dos serviços de um servidor du- rante a semana.

• Unidade: Número de interrupções. • Origem dos Dados: Servidores. • Frequência: Diariamente

• Referência: Jaquith (2007).

• Critério para automação: Protocolo SNMP.

Métrica 4 - Dias que os serviços dos servidores sofreram interrupções.

• Objetivo: Através desta métrica é possível descobrir o dia em que os serviços dos servidores começaram a apresentar interrupções. Dessa forma, o administrador de rede pode tentar relacionar algum fato ocorrido durante o dia que pode ter colaborado para a interrupção dos serviços.

• Processamento dos dados: Esta métrica coleta os dados dos componentes várias ve- zes durante o dia. Caso o valor coletado for igual à zero ou menor que o valor obtido anteriormente, então se conclui que ocorreu uma interrupção nos serviços. Logo, atra- vés de um contador é possível obter a quantidade de interrupções dos serviços de um servidor durante o dia.

• Unidade: Número de interrupções. • Origem dos Dados: Servidores. • Frequência: De hora em hora. • Referência: Jaquith (2007).

• Critério para automação: Protocolo SNMP.

Métrica 5 - Modelo do processador dos computadores e versão do sistema operacio- nal.

Esta é uma métrica interessante, pois apesar de não estar relacionada diretamente com a segurança da informação pode ser útil para auxiliar o administrador no gerenciamento dos computadores da rede. Por exemplo, se um computador possui um alto número de interrupções nos serviços durante um curto período de tempo, pode ser que esse computador esteja com problemas de hardware. Ao utilizar esta métrica o administrador de rede pode verificar o modelo do processador e com esta informação analisar se o equipamento está defasado em relação às tecnologias atuais e pode causar problemas de instabilidade nos serviços. Além disso, através dessa métrica também é possível consultar a versão do sistema operacional utilizado nos computadores e avali- ar se é necessário agendar possíveis atualizações no software. Estes dados podem ser coletados através da interação GET do Protocolo SNMP, passando como parâmetro a OID (Object Identifi-

er) 1.3.6.1.2.1.1.1, que faz referência ao objeto sysdescr e está localizado no grupo system da

hierarquia de informações da MIB. Outra forma de obter informações sobre o processador de um computador é através da API JAVA SIGAR. De acordo com a especificação encontrada em (SI- GAR, 2013), o método getModel() retorna uma String contendo o modelo do processador do computador.

• Objetivo: Identificar possíveis computadores da rede que necessitam de uma atualiza- ção na versão do sistema operacional ou possuem processadores defasados em relação às tecnologias atuais.

• Processamento dos dados: Esta métrica não exige processamento dos dados. Os da- dos são apenas coletados e apresentados ao administrador de rede através de relató- rios.

• Unidade: Esta métrica não tem uma unidade de medida. • Origem dos Dados: Computadores.

• Frequência: Mensalmente. • Referência: Jaquith (2007).

• Critério para automação: Protocolo SNMP.

Interface socket - Protocolo TCP

As métricas 6 e 7 utilizam a interface socket do protocolo TCP para realizar a coleta dos dados automaticamente. A estação de gerenciamento se comunica com os computadores da rede na tentativa de abrir uma conexão com a porta selecionada e aguarda um período de tempo de resposta (Timeout). Se a comunicação for realizada com sucesso entende-se que a porta do com- putador estava aberta. Caso não seja possível realizar a comunicação, provavelmente a porta es- tava fechada ou a comunicação foi bloqueada pelo firewall. Dessa forma, é possível descobrir informações importantes, como por exemplo, o número de computadores que permitem acesso via SSH e possíveis portas abertas em computadores sem o consentimento do administrador de rede.

Métrica 6 - Número de computadores que permitem acesso via SSH.

• Objetivo: Analisar o número de computadores da rede que permitem acesso via SSH, com o intuito de descobrir possíveis acessos não permitidos.

• Processamento dos dados: A estação de gerenciamento se comunica com todos os computadores da rede e analisa se a porta referente ao acesso SSH de cada computador está aberta. Logo, através de um contador é possível obter o número de computa- dores encontrados que permitem este acesso.

• Unidade: Número de computadores. • Origem dos Dados: Computadores. • Frequência: Semanalmente.

• Referência: Esta métrica foi desenvolvida especificamente para este trabalho. • Critério para automação: Interface socket - Protoclo TCP.

Métrica 7 - TOP 5 Open Ports.

• Objetivo: Apresentar as cinco portas que foram mais vezes encontradas abertas nos computadores, com o intuito de descobrir possíveis portas abertas sem consentimento do administrador de rede.

• Processamento dos dados: A estação de gerenciamento se comunica com todos os computadores da rede e analisa as portas de cada computador que se encontram abertas. Logo, através de um contador é possível obter as cinco portas que foram encontradas mais vezes abertas.

• Unidade: Número de portas.

• Origem dos Dados: Computadores. • Frequência: Diariamente.

• Referência: Esta métrica foi desenvolvida especificamente para este trabalho. • Critério para automação: Interface socket - Protoclo TCP.

Protocolo POP3, SMTP e IMAP

As métricas 8 e 9 apresentam o número de e-mails recebidos ou enviados que podem ser considerados spam, ou seja, e-mails que podem ser considerados indesejáveis ou que foram envi- ados sem solicitação do usuário. Uma rotina foi desenvolvida para realizar o download e o envio de emails ao executar o IPSMA. A implementação foi realizada através da API JavaMail que utiliza os protocolos POP3, SMTP e IMAP para receber e enviar os e-mails. Dessa forma, os e-

mails podem ser filtrados através da biblioteca Classifier4J (Classifier4J, 2013) que classifica o

conteúdo da mensagem através de um filtro antisspam. As regras contidas neste filtro verificam a utilização de diversas palavras ou expressões no assunto ou no conteúdo da mensagem como, por exemplo, “compre”, “curso on-line”, “apenas R$” e outras. Uma pontuação é atribuída a cada regra quebrada e caso atinja um número maior que 7, o e-mail pode ser considerado como spam.

Métrica 8 - Quantidade de e-mails recebidos que podem ser considerados spam. • Objetivo: Auxiliar o administrador de rede a tentar diminuir o número de e-mails re-

cebidos que podem ser considerados spam.

• Processamento dos dados: Ao realizar o download dos e-mails, é adicionado um re- gistro na base de dados com a quantidade de e-mails encontrados que podem ser con- siderados spam.

• Unidade: Número de e-mails recebidos que podem ser considerados spam. • Origem dos Dados: Servidor de e-mail.

• Frequência: A coleta dos dados desta métrica é efetivada sempre que o download dos e-mails é realizado.

• Referência: Jaquith (2007).

• Critério para automação: Protocolo POP3 e IMAP.

Métrica 9 - Quantidade de e-mails enviados que podem ser considerados spam. • Objetivo: Auxiliar o administrador de rede a tentar diminuir o número de e-mails en-

viados que podem ser considerados spam.

• Processamento dos dados: Ao realizar o envio dos e-mails, é adicionado um registro na base de dados com a quantidade de e-mails encontrados que podem ser considera- dos spam.

• Unidade: Número de e-mails enviados que podem ser considerados spam. • Origem dos Dados: Servidor de e-mail.

• Frequência: A coleta dos dados desta métrica é efetivada sempre que o envio dos e- mails é realizado.

• Referência: Jaquith (2007).

• Critério para automação: Protocolo SMTP e IMAP.

Com as métricas selecionadas e o processo de coleta dos dados automatizado, é importante realizar a gravação dos dados coletados em uma base dados. Neste trabalho foi utilizado o sis- tema de gerenciamento de banco de dados Oracle XE. Dessa forma, é possível realizar uma análi- se profunda nos registros e tentar descobrir correlações não previstas entre os dados. Além disso,

permite apresentar um histórico e realizar comparações entre períodos de diferentes medições, também chamado de “before-and-after” (Jaquith, 2007), (Hauser and Katz, 2008), ou seja, com- parações entre os dados obtidos em diversas épocas. Portanto, o Modelo de Entidade Relacional da estrutura da base de dados utilizada pelo IPSMA pode ser visualizado na Figura 5.5.

Figura 5.5: Modelo de Entidade Relacional do IPSMA.

É importante lembrar que os dados são processados e transformados em informação so- mente durante o processo de geração dos gráficos e relatórios. A Figura 5.6 apresenta os dados antes de serem processados pelas métricas. Este exemplo ilustra os dados de um computador que estava há 2 horas e 12 minutos com os serviços ativos, ou seja, sem sofrer nenhuma interrupção.

Figura 5.6: Dados coletados antes de serem processados.

Finalmente, o processo de implementação encontra-se concluído e a ferramenta já pode ser utilizada em uma estação de gerenciamento. A Figura 5.7 apresenta uma visão geral da interface principal do IPSMA. Ao observar esta interface é possível visualizar um console onde são apresentados em tempo real os dados dos componentes que estão sendo coletados. Os botões encontrados na parte inferior da tela são responsáveis por “iniciar” ou “parar” o processo de coleta dos dados ou “limpar” as informações apresentadas no console.

Outro ponto importante a ser analisado neste exemplo é a presença de três botões na late- ral superior esquerda. O primeiro, nomeado como configurações, permite que o administrador de rede ajuste as configurações específicas de cada métrica, por exemplo, o IP dos computadores da rede que serão analisados, quais métricas e com que frequência cada uma delas será executada, o

timeout de espera de resposta dos componentes analisados e caso utilize o protocolo SNMP, o

identificador do objeto a ser analisado. A Figura 5.8 ilustra a tela onde as configurações de uma métrica de segurança podem ser ajustadas.

Figura 5.8: Tela de configuração de uma métrica.

Os outros dois botões (ver Figura 5.7) estão relacionados à apresentação das informações obtidas pelas métricas de segurança. Conforme apresentado no Capítulo 2.4, além de coletar os dados automaticamente é necessário um modelo para visualização das informações providas pelas métricas. Portanto, ao clicar no segundo botão “Gráficos/Relatórios” é possível visualizar os resultados obtidos durante o processo de coleta através de uma diversidade de gráficos e relató- rios. Os gráficos foram desenvolvidos através da API JfreeChart disponibilizada pelo JAVA e podem ser gerados passando como parâmetros a data inicial e final em que os dados foram coletados. Dessa forma, a aplicação realiza uma consulta na base de dados, processa os dados de a- cordo com o atributo “Processamento dos dados” do modelo de dados e os apresenta em forma de

gráficos e relatórios. Um exemplo de um gráfico gerado através do IPSMA pode ser visualizado

No documento 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 (páginas 46-65)