Avaliação dos resultados

A metodologia para análise e avaliação do ESMP utilizada é uma abordagem híbrida (KLOTI; KOTRONIS; SMITH, 2013), que combina modelagem do próprio sistema (mo- delagem dos componentes do sistema) (HERNAN et al., 2006) e modelagem de ataques de um sistema (SAINI; DUAN; PARUCHURI, 2008).

A técnica é simples: descreve as metas de segurança; analisa os componentes do sis- tema (no nosso caso, Ćuxo de dados) e modela seus recursos; modela as ameaças iminentes do sistema; e, por Ąm, veriĄca se os recursos do sistema conseguem mitigar as ameaças modeladas. O resultado desse método de análise e veriĄcação do ESMP na ETArch pode ser visto na Tab. 7.

As ameaças mitigadas pelo protocolo ESMP na ETArch são: ataque de espionagem (Snooping); análise de tráfego (analysis traffic); modiĄcação de mensagens (modiĄcation attack); denial of service (DoS); main-in-the-middle; ataque de reĆexão (reĆection at- tack); ataque de disfarce/mascaramento (masquerading) e ataque de repetição (replaying attack). Tal como está sinalizado na tabela, todos esses ataques/ameaças são mitigados em um contexto de comunicação multicast.

No caso do repúdio, o ESMP não consegue mitigar essa ameaça; ou seja, o ESMP na ETArch não consegue aĄrmar que a transação foi feita por determinada entidade em

Tabela 8 Ű Comparação do ESMP com outros protocolos e arquiteturas

MF - MobilityFirst ESQ - ETArch Status Quo

ESMP - ESMP na ETArch

Metas de Segurança Ataques TLS IPSec MF ESQ ESMP

Confidencialidade Espionagem v v v x v

Análise de tráfego x v x v v

Integridade Modificação v v v x v

Repúdio x v v x x

Disponibilidade Negação de serviço

DoS x x v v v

Man-in-the-middle v v v x v

Autenticação ReĆexão v v v x v

Mascaramento v v v x v

Repetição v v x x v

Segurança multicast Apenas os ataques

mitigados x x x v v

Adaptada de (KHONDOKER et al., 2014).

um contexto de comunicação multicast no plano de dados. Para isso, é necessário uma abordagem de comunicação que utilize, por exemplo, assinatura digital. A especiĄcação do ESMP prevê essa necessidade através do gerenciamento de chaves simétricas a partir de encriptação assimétrica na Seção 4.2; porém, esse método de gerenciamento não foi descrito nesse trabalho. A evolução dessa especiĄcação pode mitigar essa ameaça de repúdio no futuro.

Por Ąm, a Tab. 8 mostra a comparação do ESMP na ETArch com todas as outras arquiteturas ou protocolos descritas nesse trabalho. A comparação é realizada com o objetivo de apresentar as contribuições do ESMP para a arquitetura ETArch.

O ESMP na ETArch se mostra à frente, em questões de segurança, de arquiteturas de Internet do Futuro que já são maduras no mercado, como por exemplo, o MobilityFirst.

124 Capítulo 5. Análise e discussão dos Resultados No caso do IPSec, SSL/TLS e MobilityFirst, eles não apresentam mecanismos de segu- rança para comunicação multicast, sendo que esse é um dos objetivos fulcrais do ESMP por conta das demandas das aplicações atuais.

A evolução do ESMP na ETArch quando comparado com a ETArch (status quo) é signiĄcativa. A análise de tráfego e o DoS mitigados pela ETArch (status quo) não tem relação com os mecanismos de segurança do SBB SM dessa arquitetura. Nos dois casos, a mitigação acontece devido à recursos da própria ETArch (status quo). Devido a esse fato, parte-se do princípio que a ETArch (status quo) não possui nenhum mecanismo de segurança capaz de mitigar qualquer uma das ameaças modeladas pelo método de análise e avaliação.

Capítulo

6

Conclusão

O objetivo geral deste trabalho é criar uma especiĄcação de um protocolo de segu- rança multicast para uma arquitetura de Internet do Futuro. O protocolo denominou-se

Entity Security Multicast Protocol (ESMP) e tem como função principal a transformação

de um ambiente de comunicação desprovido de contramedidas de segurança em uma rede conĄável, onde entidades possam conĄar uma nas outras a Ąm de realizar uma comuni- cação segura. Desse modo, a hipótese de segurança do trabalho não destoa dos aspectos conceituais de rede deĄnida por software, nem da ETArch, e nem sequer das funções que a segurança assume na Internet.

O objetivo geral do trabalho é alcançado paulatinamente, na medida que cada objetivo especíĄco da seção 1.2 é satisfeito.

O primeiro objetivo especíĄco da seção 1.2 foi resolvido no decorrer do Cap. 4. A especiĄcação de autenticação, conĄdencialidade, integridade e disponibilidade se dissolve nas operações de gerenciamento de chaves (seção 4.2), multiplexação/demultiplexação (subseção 4.3.2), handshakes (subseção 4.3.3), cálculo e veriĄcação de hash (seção 4.4). Parte dessa dissolução encontra-se também na especiĄcação de como as primitivas de dados são operadas pelo ESMP (seção 4.4). Como dito anteriormente, esse primeiro objetivo especíĄco está espalhado pelas soluções da proposta descrita no Cap. 4, e a razão disso é que a especiĄcação desses serviços de segurança passa pela criação de vários mecanismos de segurança que são necessários para desenvolvê-los.

Nota-se, na seção 1.2, que o primeiro objetivo está destrinchado em vários requisitos que são de extrema importância para o cumprimento das metas do ESMP.

O primeiro requisito é que os serviços de segurança forneçam suporte às comunicações

multicast. Esse contexto de comunicação é intrínseco da arquitetura ETArch, e portanto,

todos os serviços de segurança especiĄcados pelo ESMP se adéquam à essa espécie de comunicação.

O segundo requisito é que os serviços de segurança sejam transparentes à camada de aplicação. No decorrer do Cap. 4, mencionamos que a entidade (aplicação) aciona os serviços de segurança ao setar o identiĄcador da política de segurança nos campos "requi-

126 Capítulo 6. Conclusão rements"ou "capabilities" (dependendo da primitiva). Esse requisito é alcançado por uma

característica intrínseca da própria arquitetura, que fornece uma aproximação semântica entre as camadas. Nesse contexto, os serviços/mecanismos de segurança são executados de forma transparente para a aplicação (entidade comunicante).

O terceiro requisito diz respeito à oferecer diferentes serviços/mecanismos de segurança para diferentes entidades (sensores, aplicações de banco, etc.). Esse requisito é resolvido com a Ćexibilidade da política de segurança (seção 4.3.1), que permite que cada aplicação requisite serviços/mecanismos de segurança de acordo com suas necessidades.

O quarto requisito relaciona-se com a sintetização de número de chaves distribuídas na comunicação multicast quando comparada com a comunicação peer-to-peer. A introdução do Cap. 4 resolve essa questão, demonstrando que enquanto a comunicação peer-to-peer do TCP/IP tem um crescimento exponencial de chaves em relação ao número de entidades participantes da comunicação, o modo de distribuição de chaves do ESMP possui um crescimento linear. Os gráĄcos 11(a)(b) demonstram essa aĄrmação.

O quinto requisito é que a especiĄcação do ESMP na ETArch eleva o nível de segurança da arquitetura em relação à ETArch (status quo). Em 3.10 é analisada a segurança dessa arquitetura no seu estado atual, e na seção 5.3 é demonstrada a evolução da ETArch quando utilizada com o protocolo ESMP.

Dito isso, encerra-se a discussão do primeiro objetivo especíĄco, e chega-se à conclusão que o trabalho conseguiu cumprir as metas esperadas.

O segundo objetivo especíĄco é resolvido pela seção 5.2. Utiliza-se um método de aná- lise e avaliação híbrido em relação às técnicas de modelagem de ataque e modelagem de sistema. Esse método se mostrou eĄcaz na amostragem das vulnerabilidades do sistema e da resistência dos mecanismos de segurança em relação aos ataques/ameaças iminentes em uma rede de comunicação. Dessa forma, conseguiu-se demonstrar se os mecanis- mos/serviços de segurança do ESMP são suĄcientes para cumprir as metas do protocolo. A Tab. 7 exibe os resultados obtidos quanto à capacidade que os mecanismos/serviços de segurança do ESMP têm de mitigar ameaças/ataques conhecidos.

Dito isso, encerra-se a discussão do segundo objetivo especíĄco, e chega-se à conclusão que o trabalho conseguiu cumprir as metas esperadas.

O terceiro requisito é fazer uma avaliação comparativa entre os resultados obtidos desse trabalho e algumas arquiteturas e protocolos de segurança que já são maduros no mercado. Foi escolhido para comparação os dois principais protocolos da arquitetura TCP/IP (IPsec/TLS), uma arquitetura de Internet do Futuro (MobilityFirst) e a própria arquitetura que serviu de protótipo do ESMP (ETArch (status quo)). O resultado dessa avaliação comparativa se encontra na Tab. 8.

Dito isso, encerra-se a discussão do terceiro objetivo especíĄco, e chega-se à conclusão que o trabalho conseguiu cumprir as metas esperadas.

do método de avaliação proposto, entende-se como cumprido o objetivo geral, que é a especiĄcação de um ambiente de comunicação multicast seguro. Uma vez atingido os objetivos especíĄcos e geral, as próximas seções tratam de destacar as principais contri- buições deste trabalho e apresentar os trabalhos futuros para melhoria da hipótese atual, além daqueles que podem ser gerados a partir deste.