• Nenhum resultado encontrado

Arquitetura ponte-filtro para segurança em simulação distribuída multinacional

N/A
N/A
Protected

Academic year: 2021

Share "Arquitetura ponte-filtro para segurança em simulação distribuída multinacional"

Copied!
81
0
0

Texto

(1)

CENTRO DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Xerxes Slaghenaufi

ARQUITETURA PONTE-FILTRO PARA SEGURANÇA

EM SIMULAÇÃO DISTRIBUÍDA MULTINACIONAL

Santa Maria

2020

(2)

ARQUITETURA PONTE-FILTRO PARA SEGURANÇA EM SIMULAÇÃO DISTRIBUÍDA MULTINACIONAL

Dissertação de Mestrado apresentado ao Programa de Pós-Graduação em Ciência da Computação, Área de Concentração em Ciência da Computação, da Universidade Federal de Santa Maria (UFSM, RS), como parte dos requisitos necessários à obtenção do título de Mestre em Ciência da Compu-tação.

Orientador: Raul Ceretta Nunes

Santa Maria 2020

(3)

Sistema de geração automática de ficha catalográfica da UFSM. Dados fornecidos pelo autor(a). Sob supervisão da Direção da Divisão de Processos Técnicos da Biblioteca Central. Bibliotecária responsável Paula Schoenfeldt Patta CRB 10/1728.

80 p.; 30 cm

Orientador: Raul Ceretta Nunes

Dissertação (mestrado) - Universidade Federal de Santa Maria, Centro de Ciências Naturais e Exatas, Programa de Pós-Graduação em Ciência da Computação , RS, 2020

1. Filtro HLA 2. Ponte HLA 3. High Level Architecture 4. Simulação Multinacional I. Ceretta Nunes, Raul II. Título.

(4)
(5)

todo o apoio e suporte para que obtivesse êxito em mais esse desafio. Essa conquista é nossa. Amo muito vocês.

(6)

A Deus por me dar saúde e força e por colocar em minha vida pessoas que me ajudaram a superar os obstáculos para concluir este trabalho.

A minha esposa Viviane e a minha filha Caroline pelo apoio, paciência, carinho, amor incondicional e compreensão pelas minhas horas de ausência.

A minha mãe Irse e minha irmã Belquiz pelo exemplo, amor, compreensão e por sempre acreditarem em mim.

Ao meu orientador, professor Raul, sempre prestativo e dedicado, agradeço pelo apoio, confiança e por conduzir minha pesquisa para a direção correta e exitosa.

Ao Comando da 3ª Divisão de Exército e aos colegas da Seção de Informática que me apoiaram para realizar este trabalho. Agradeço em especial ao Coronel Wel-lington que foi um grande amigo, apoiando e incentivando meus estudos e aos colegas Vargas e Noal, que executaram por algumas vezes minhas tarefas na Seção durante minhas ausências.

Aos colegas do laboratório e do projeto que sempre compartilharam seus conhe-cimentos de forma espontânea e que foram atenciosos e solícitos quando necessitei de auxílio para o desenvolvimento da minha pesquisa. Em especial, agradeço ao colega Rodrigo pelo apoio na implementação e experimentação do protótipo.

Enfim, agradeço a todas as pessoas que fazem parte da minha vida e que de forma direta ou indireta, contribuíram para que este trabalho pudesse ser concluído e essa vitória pudesse ser alcançada. Sem a ajuda de todos, o esforço e as horas de dedicação empenhadas não seriam suficientes para o desfecho bem-sucedido deste trabalho.

(7)

Nem cora o sabre de chamá-lo irmão . . . “ (Castro Alves)

(8)

ARQUITETURA PONTE-FILTRO PARA SEGURANÇA EM SIMULAÇÃO DISTRIBUÍDA MULTINACIONAL

AUTOR: XERXES SLAGHENAUFI ORIENTADOR: RAUL CERETTA NUNES

A formação de alianças e acordos governamentais para treinamento militar entre dife-rentes países aumenta a necessidade de controles de segurança na interoperabilidade de simuladores. Os simuladores militares podem possuir informações como capa-cidades de armamentos, propriedades de equipamentos, constituição das tropas e doutrinas, as quais são classificadas em algum nível de proteção. Nesse contexto de simulação é necessária a proteção dos dados, evitando a divulgação e compar-tilhamento de informações confidenciais. Este trabalho apresenta uma solução para simulações baseadas em HLA (High Level Architecture) que permite o controle sobre o tráfego entre federações de nações ou organizações distintas. O modelo elaborado propõe a combinação de uma estrutura de ponte e uma estrutura de filtro, que pode ser introduzida entre duas federações para restringir a publicação de informações classificadas. Para demonstrar a funcionalidade da solução na proteção de dados sensíveis de simuladores foi desenvolvido um protótipo de ponte-filtro HLA. A solução implementada, além de proteger a federação nacional e evitar a supressão de dados no exercício local, possibilita aos planejadores/credenciadores do treinamento definir o que desejam compartilhar e proteger em suas federações de acordo com as regras de sua nação. Foi realizado um experimento envolvendo um simulador construtivo e uma solução RTI disponíveis no mercado. Os testes realizados no experimento demonstram que a combinação das estruturas propostas é uma solução flexível e eficaz na prote-ção de informações confidenciais quando há necessidade de realizar um treinamento multinacional.

Palavras-chave: Filtro HLA. Ponte HLA. High Level Architecture. Simulação Multi-nacional.

(9)

BRIDGE-FILTER ARCHITECTURE FOR SECURITY IN MULTINATIONAL DISTRIBUTED SIMULATION

AUTHOR: XERXES SLAGHENAUFI ADVISOR: RAUL CERETTA NUNES

Forming alliances and government agreements for military training among different countries increases the need for security controls in simulators interoperability. Military simulators may have information such as weapons capabilities, equipment properties, troop constitution and doctrines, which are classified at some level of protection. In this simulation context, data protection is necessary, avoiding the disclosure and sharing of confidential information. This work presents a solution for High Level Architecture (HLA) based simulations that allows control over the inter-federation traffic of distinct organiza-tions or naorganiza-tions. The elaborated model proposes the combination of a bridge structure and a filter structure, which can be introduced between two federations to restrict the publication of classified information. To demonstrate the functionality of the solution in protecting sensitive data from simulators, a prototype HLA bridge-filter was developed. The implemented solution protects the national federation, avoids data supression in the local exercise and allows training planners/accreditors to define what they want to share or protect in their federations according to their nation’s rules. An experiment was performed involving a constructive simulator and a RTI solution (both commercially available). The experiment tests show that the combination of the proposed frameworks is a flexible and effective solution for protecting confidential information when multina-tional training is required.

(10)

Figura 1 – Federação e Federados . . . 21

Figura 2 – Troca de objetos com base no padrão P/S . . . 22

Figura 3 – Conexão dos federados à federação . . . 24

Figura 4 – Interoperação entre federações . . . 24

Figura 5 – SH (System High) . . . 29

Figura 6 – MSL (Multi Single Level of Security) . . . 30

Figura 7 – MILS (Multiple Independent Levels of Security) . . . 31

Figura 8 – MLS (Multi-level Security) . . . 32

Figura 9 – Arquitetura para JTEN Trial 1 . . . 42

Figura 10 – Filtro Baseado no FOM . . . 44

Figura 11 – Filtro de Objetos e Interações . . . 44

Figura 12 – Domínios de Rede Seguros . . . 45

Figura 13 – Fluxo de Informações entre as Federações . . . 47

Figura 14 – Processo de Comunicação da Ponte . . . 48

Figura 15 – Estrutura de Transmissão de Dados para AggregateEntity . . . 50

Figura 16 – Primeiro nível de filtragem . . . 51

Figura 17 – Estrutura de Filtragem do segundo nível . . . 52

Figura 18 – Estrutura de Filtragem para aggregateEntity . . . 53

Figura 19 – Instanciação Dupla da Solução . . . 55

Figura 20 – Interface de Configuração da Ponte . . . 59

Figura 21 – Arquivo XML de configuração da ponte . . . 60

Figura 22 – Interface de Configuração do Filtro . . . 61

Figura 23 – Filtro Global . . . 62

Figura 24 – Interface do Filtro por Instância . . . 63

Figura 25 – Interface do Log de Eventos . . . 64

Figura 26 – Instâncias do SWORD Simulando Exércitos de Países Distintos . . 65

Figura 27 – Componentes da Solução Ponte-Filtro . . . 66

Figura 28 – Instâncias do SWORD com tropas replicadas . . . 67

Figura 29 – Aplicação de Filtro Global . . . 69

(11)

Tabela 1 – Informações consideradas sigilosas obtidas dos questionários . . . 37 Tabela 2 – Atributos de configuração dos componentes da ponte . . . 49 Tabela 3 – Exemplo de atributos de um objeto do tipo aggregateEntity . . . 49

(12)

API Application Programming Interface

C2 Comando e Controle

CMS Collective Mission Simulation COTER Comando de Operações Terrestres

DD Data Diod

DMSO Defense Modeling and Simulation Office DoD Department of Defense

EB Exército Brasileiro

EME Estado-Maior do Exército EUA Estados Unidos da América

FAFD Federation Architecture and Federation Object Model FOM Federation Object Model

GUI Graphical User Interface HLA High Level Architecture

HTTPS Hiper Text Transfer Protocol Secure

IEEE Institute of Electrical and Electronics Engineers IPSEC IP Security Protocol

IXG Information Exchange Gateway JFCOM Joint Forces Command

JG Jogo de Guerra

JTEN Joint Training and Experimentation Network LVC Live, Virtual and Constructive

MDSA Multi-Domain Security Architecture MILS Multiple Independent Levels of Security MLS Multi Level Security

(13)

MTDS Mission Training Through Distributed Simulation NATO North Atlantic Treaty Organization

NETN NATO Education and Training Network OM Organização Militar

OMT Object Model Template PKI Public Key Infrastructure

QC Quadro de Cargos

QDM Quadro de Dotação de Material

QO Quadro Organizacional

RPR Real-Time Platform Reference RTI Runtime Infrastructure

SH System High

SOM Simulation Object Model

US United States

WAN Wide Area Network

(14)

1 INTRODUÇÃO . . . . 15

2 REVISÃO DA LITERATURA . . . . 20

2.1 HLA, INTEROPERABILIDADE E FILTRAGEM . . . 20

2.1.1 Conceitos de HLA . . . . 20

2.1.2 Conceito do FOM e sua função na integração de simuladores . . 22

2.1.3 Interoperabilidade entre um federado e uma federação . . . . 23

2.1.4 Uso de pontes na interoperabilidade entre federações . . . . 24

2.1.5 Filtro HLA . . . . 25 2.2 JUSTIÇA NO COMBATE . . . 25 2.3 CLASSIFICAÇÃO DE SIMULAÇÃO . . . 26 2.3.1 Simulação viva . . . . 26 2.3.2 Simulação virtual . . . 26 2.3.3 Simulação construtiva . . . 27

2.4 SEGURANÇA DA INFORMAÇÃO PUBLICADA . . . 28

2.4.1 Treinamentos coletivos e seu impacto sobre as questões de se-gurança de informações em simuladores . . . . 28

2.4.2 Impacto das medidas de segurança sobre as informações publi-cadas . . . 28

2.4.3 Como tratar dados de diferentes classificações em simulação . 29 2.4.3.1 SH (System High) . . . 29

2.4.3.2 MSL (Multi Single Levels of Security) . . . 30

2.4.3.3 MILS (Multiple Independent Levels of Security) . . . 30

2.4.3.4 MLS (Multi Level Security) . . . 31

2.5 TRABALHOS RELACIONADOS . . . 32

3 UMA PROPOSTA DE SEGURANÇA EM SIMULAÇÃO MILITAR MUL-TINACIONAL . . . . 35

3.1 LEVANTAMENTO DE INFORMAÇÕES SENSÍVEIS . . . 35

3.2 REQUISITOS NECESSÁRIOS À FILTRAGEM . . . 38

3.2.1 Requisitos referentes a pessoal, material e estrutura de frações 38 3.2.2 Requisitos relacionados à doutrina . . . . 39

3.2.3 Flexibilidade e readequação . . . . 40

3.3 CONSIDERAÇÕES SOBRE MDSA (MULTI-DOMAIN SECURITY AR-CHITECTURE ) E SUA APLICAÇÃO EM EXERCÍCIOS DE SIMULA-ÇÃO MULTINACIONAIS . . . 41

3.3.1 Aplicação de MDSA em exercícios de simulação multinacionais 41 3.3.2 Isolamento multi-domínio a nível de aplicação HLA . . . . 43

(15)

3.4 CARACTERÍSTICAS TÉCNICAS DA SOLUÇÃO DE PONTE-FILTRO PARA GARANTIR A SEGURANÇA DOS DADOS CLASSIFICADOS

DE SIMULADORES ENTRE FEDERAÇÕES . . . 45

3.4.1 Objetivos técnicos da ponte-filtro . . . . 46

3.4.2 Estrutura de segurança da ponte-filtro . . . . 47

3.4.2.1 Estrutura de interoperabilidade entre as federações (ponte) . . . 48

3.4.2.2 Estrutura de filtragem (filtro) . . . 51

3.4.2.2.1 Primeiro nível de filtragem . . . 51

3.4.2.2.2 Segundo nível de filtragem . . . 52

3.4.2.3 Características da filtragem . . . 54

3.4.2.4 Filtragem em tempo de execução . . . 56

3.5 CONSIDERAÇÕES PARCIAIS . . . 56

4 EXPERIMENTOS REALIZADOS E RESULTADOS ALCANÇADOS . 58 4.1 PROTÓTIPO DESENVOLVIDO (HLA BrSimSecurity) . . . 58

4.1.1 Interface de configuração da ponte e do primeiro nível de filtragem 58 4.1.2 Interface de configuração do segundo nível de filtragem . . . . . 60

4.1.2.1 Filtro global . . . 61

4.1.2.2 Filtro por instância . . . 62

4.1.3 Log de eventos . . . . 63

4.1.4 Interface independente . . . . 64

4.2 EXPERIMENTO . . . 64

4.2.1 Ambiente e elementos do experimento . . . . 65

4.2.2 Verificação da ponte e primeiro nível de filtragem . . . . 66

4.2.3 Verificação do segundo nível de filtragem . . . . 68

4.2.3.1 Teste da filtragem global . . . 68

4.2.3.2 Teste da filtragem por instância . . . 70

4.2.4 Discussão do experimento . . . . 71

5 CONCLUSÃO E TRABALHOS FUTUROS . . . . 73

REFERÊNCIAS . . . . 75

(16)

1 INTRODUÇÃO

Há situações onde diferentes nações precisam treinar juntas, o que ocorre principalmente na área militar, e, nesse caso a segurança da informação é fundamental, pois, há informações disponibilizadas pelos simuladores, relacionadas a cenários, capacidades de armamentos ou doutrinas, que são classificadas em algum nível e que necessitam ser protegidas ou filtradas ao serem transmitidas entre os participantes do exercício (MÖLLER et al., 2012).

High Level Architecture (HLA) é um padrão IEEE (IEEE, 2010a) para comunica-ção em simulações distribuídas. Inicialmente, os esforços no sentido de desenvolver esse padrão se concentraram no domínio da defesa, visando permitir a interopera-bilidade de vários sistemas de simulação e convergir para uma arquitetura comum (TOPÇU; OGUZTÜZÜN, 2017).

O agrupamento de vários simuladores em HLA é conhecido como federação. Cada simulador ou sistema que participa de uma federação é chamado de federado (IEEE, 2010a). As interações entre federados são controladas pela Runtime Infras-tructure (RTI) que é o middleware HLA que integra e suporta os federados(ELKINS; WILSON; GRACANIN, 2001).

Através do HLA é possível modelar as simulações de forma independente no que tange a interoperabilidade entre simuladores, linguagem de programação e plataforma de hardware, mas a especificação HLA não inclui definição de segurança (XIANGUO et al., 2007). Portanto, para aplicação do padrão HLA em simulação distribuída, a segurança da informação trocada entre as federações, é um obstáculo a ser transposto.

A segurança em ambientes de simulação distribuída pode ser abordada do ponto de vista do tráfego das informações no canal de comunicação e da classificação da informação trocada entre os simuladores participantes de um treinamento multinacional.

Simuladores localizados em domínios distintos e distribuídos geograficamente muitas vezes necessitam integrar-se e trocar dados de forma segura por redes não seguras, como, por exemplo, a Internet (XIANGUO et al., 2007). Proteger as informa-ções que fluem pelo Canal de Comunicação, corresponde a buscar soluinforma-ções para evitar que agentes externos, não participantes da simulação, obtenham informações indevidamente pela análise do fluxo de dados sobre a camada de rede ou mesmo por um federado malicioso.

Nesse sentido, há trabalhos que propõe soluções para segurança dos dados que trafegam pela rede em simulação HLA, como o uso do protocolo IPSEC (Internet Protocol Security ) combinado com PKI (Public Key Infrastructure) (ELKINS; WILSON; GRACANIN, 2001), também o protocolo IPSEC combinado com encapsulamento do RTI-Ambassador com funções de driver NDIS (Network Driver Interface Specificacion) (XIANGUO et al., 2007) e a arquitetura de segurança para simulação em nuvem base-ada em HTTPS (Hyper Text Transfer Protocol Secure) proposta por Zhang, Chai e Hou

(17)

(2011), onde um protocolo da camada de registro de segurança fornece confidencia-lidade e integridade aos dados da simulação e um protocolo de autenticação define autenticação e os algoritmos criptográficos a serem utilizados.

A outra abordagem de segurança está relacionada às informações específicas de cada simulador utilizado em uma simulação, pois, os dados publicados por um federado HLA na RTI, muitas vezes possuem algum nível de sigilo (MÖLLER et al., 2011). O problema nesse caso é definir quais informações podem ser disponibilizadas para outros federados (simuladores) que participam da federação.

Como a especificação HLA não inclui nenhuma definição de segurança (AN-DREWS; WHARINGTON; STRATTON, 2008), tudo que é publicado na RTI fica disponí-vel para todos os simuladores participantes de uma federação.

O vazamento de informações não é identificado como um importante ponto de interesse quando todos os simuladores e as informações processadas dentro deles pertencem a mesma organização, pois, os dados são mantidos dentro de um domínio de segurança. Nestes ambientes locais/nacionais seguros, assume-se que toda a informação pode ser compartilhada com todos os sistemas e cada sistema é identificado como confiável, mas isso não significa que não existam informações classificadas ou sensíveis nestes simuladores (VERKOELEN; WYMENGA, 2009).

Assim, quando há necessidade de realizar treinamentos multinacionais que envolvam domínios distintos com requisitos técnicos de segurança a serem seguidos, o controle das informações sigilosas presentes nos simuladores pode ser um obstáculo à realização do exercício.

No contexto internacional de defesa é cada vez mais frequente a realização de treinamentos que envolvem simuladores de nações distintas, destacando-se o exercício Viking (TECNOLOGIA E DEFESA, 2018) realizado pela primeira vez em 1999, sendo um dos maiores exercícios de simulação do mundo, incluindo 2500 participantes, 35 organizações e 50 países e baseando-se em cenários realistas que podem ocorrer nas operações internacionais de paz e gestão de conflitos.

O Exército Brasileiro utiliza simulação assistida por computador em treinamentos há pelo menos duas décadas e nos últimos anos está se inserindo em um contexto internacional o que é caracterizado pelas seguintes atividades:

• participação no exercício internacional Viking (TECNOLOGIA E DEFESA, 2018); • participação do exercício Panamax (PANAMAX, 2018); e

• acordo de cooperação em matéria de defesa, firmado entre os governos do Brasil e dos Estados Unidos da América e que entrou em vigor no ano de 2015 (UNITED STATES OF AMERICA DEPARTMENT OF STATE, 2015).

Assim, percebe-se que há características de segurança que são requeridas em simuladores militares, sendo necessário entender e definir quais informações

(18)

necessitam classificação e como disponibilizar condições para que sejam filtradas caso um participante de uma simulação distribuída não queira compartilhá-las em um exercício multinacional devido ao seu nível de sigilo.

Para buscar esse esclarecimento foi realizada uma pesquisa entre militares do Exército Brasileiro com experiência em simulação militar nacional e internacional, e as respostas obtidas confirmam e se adicionam ao que as bibliografias pesquisadas afir-mam quanto a necessidade de filtrar determinados dados considerados sigilosos, como, por exemplo, as informações relacionadas à constituição das tropas e às características dos armamentos.

Nas operações simuladas que envolvem países distintos é necessário satisfazer requisitos de aceitação de mais de uma nação, havendo necessidade de segurança em vários níveis (MÖLLER et al., 2012). Dentre estes requisitos estão as informações classificadas existentes nos simuladores e a proteção destas informações é um problema de segurança nacional1. Portanto, é importante compreender quais itens de

dados podem ser suprimidos sem que haja impacto negativo à simulação, devendo-se considerar se as limitações impostas não invalidam o treinamento e o aprendizado e se não provocam a queda de desempenho da simulação (MÖLLER et al., 2015).

No sentido de proteger dados classificados de simuladores HLA Andrews, Wha-rington e Stratton (2008) propõe uma arquitetura de segurança chamada SecProxy que encapsula as regras de segurança filtrando as mensagens antes de sua publicação na RTI e Verkoelen e Wymenga (2009) faz uma descrição conceitual para prevenir o vazamento de informações de um ambiente de simuladores baseado em mecanismos de rotulagem e liberação. Ceranowicz et al. (2013) propõe que os simuladores sejam projetados desde o início como federações multi-nível, isolados por módulos guardiões que garantem que apenas conteúdo autorizado seja transferido dos níveis mais restritos para os menos restritos e (MÖLLER et al., 2015) propõe a divisão dos simuladores em domínios de alta e baixa segurança e apresenta um protótipo para demonstração do fluxo e restrição das informações que trafegam entre esses dois domínios.

Todas as propostas apresentadas nos trabalhos acima fazem um tratamento adequado de informações classificadas, mas percebe-se que apresentam soluções de segurança que ficam mais próximas do federado (simulador) e um óbice dessa característica é a necessidade de implementações de segurança nos simuladores de forma individual, o que muitas vezes tem custo elevado e é um processo lento ou inviável, dependendo das tecnologias utilizadas nos simuladores existentes.

Neste trabalho, considera-se que cada domínio participante da simulação tem a possibilidade de definir sobre as permissões de fluxo de informações para fora de sua federação HLA, visando a proteção de toda a federação. Assim, cada nação participante poderá decidir pela filtragem ou não dos conteúdos, conforme o grau de

1 A segurança nacional é um conceito relacionado à percepção da existência de ameaças que podem

(19)

sigilo dos dados (alto ou baixo). Desta forma, as federações HLA participantes são tratadas como domínios de alta segurança, mas os dados que irão trafegar em direção ao outro domínio poderão ser todos de baixa classificação (selecionados a critério de cada nação), acarretando inclusive na redução do risco de vazamento de informações sigilosas relacionadas ao canal de comunicação entre os domínios.

Neste sentido, a solução proposta neste trabalho realiza a filtragem em dois níveis:

• o primeiro nível de filtro é relacionado ao FOM e suas extensões. Propõe-se nesta fase que haja um acordo entre as federações participantes quanto ao FOM que será reconhecido por ambas as federações. Neste nível, extensões ao FOM que não fazem parte desse acordo não são carregadas e consequentemente seus objetos e interações são automaticamente filtrados; e

• o segundo nível de proteção trata-se da filtragem dos atributos de objetos e dos parâmetros de interações que fazem parte do acordo entre as federações. Neste nível é possível filtrar manualmente atributos e parâmetros específicos, caso haja neste acordo informações classificadas que não possam ser compartilhadas entre as federações.

Considerando-se que em ambientes nacionais toda a informação pode ser compartilhada com todos os sistemas e cada sistema é identificado como confiável (VERKOELEN; WYMENGA, 2009), neste trabalho não há preocupação em inspecionar o conteúdo publicado pelos federados na RTI local. A proteção é aplicada à toda a federação local, evitando novas implementações de segurança nos simuladores e voltando seu foco principal para simulações multi-domínio.

Assim, este trabalho propõe uma nova solução de segurança baseada em uma ponte-filtro que permite o controle sobre o tráfego entre federações de nações distintas, onde cada participante/credenciador de uma nação pode decidir por compartilhar ou não dados de seus simuladores de acordo com o grau de confidencialidade, tornando segura a interoperação de simuladores em treinamentos multinacionais.

Pode-se resumir as principais contribuições em:

• uma solução que possibilita a credenciadores/planejadores de treinamentos ajustar políticas de segurança da sua federação nacional de forma global ou por instância, sem a necessidade de apoio de técnicos e desenvolvedores;

• uma solução que permite a definição de regras distintas para cada enlace esta-belecido entre federações de nações distintas, respeitando tratados e alianças acordados entre estas nações; e

• uma solução que prima pela não supressão de dados na federação do domínio local ao passo que realiza a ampla proteção da federação nacional.

(20)

Também é importante salientar que o modelo proposto nesta dissertação foi aceito e publicado previamente no 9th Latin-American Symposium on Dependable Computing (SLAGHENAUFI; NUNES; AMARAL, 2019), tendo como co-autores Rodrigo Pincolini Amaral e Raul Ceretta Nunes.

O restante do trabalho está organizado da seguinte forma: no Capítulo 2 é feita a descrição do referencial teórico da pesquisa, relatando os conceitos mais importantes utilizados e também estão inclusos os trabalhos relacionados que dão suporte à proposta de pesquisa definida e demonstram o que vem sendo feito para solucionar o problema proposto; no Capítulo 3 são discutidos os elementos necessários para realizar a segurança de simuladores em treinamentos multinacionais e também é apresentado o projeto para solução do problema proposto; no Capítulo 4 é apresentado o protótipo desenvolvido de ponte-filtro e a realização de testes de validação e; o Capítulo 5 apresenta as considerações finais e trabalhos futuros a serem desenvolvidos.

(21)

2 REVISÃO DA LITERATURA

A simulação distribuída tem sido utilizada cada vez em maior escala. Atualmente, uma das áreas onde a simulação é mais aplicada trata-se do domínio militar. Quando há necessidade de simuladores trabalharem juntos, o padrão HLA pode ser utilizado e constitui-se em uma importante ferramenta para permitir que estes simuladores interoperem, mas fatores como a presença de dados sigilosos nestes simuladores pode interferir e até mesmo inviabilizar a realização de exercícios que envolvam simuladores de nações distintas.

Neste capítulo constam os principais conceitos envolvidos no tema deste traba-lho. A Seção 2.1 apresenta os principais conceitos de HLA e como simuladores podem interoperar por meio deste padrão. A Seção 2.2 trata dos problemas relacionados à jus-tiça do combate em simulação. A Seção 2.3 apresenta as categorias de simulação viva, virtual e construtiva. A Seção 2.4 discute como tratar e manter seguras informações classificadas existentes em simuladores e a Seção 2.5 analisa trabalhos que tratam da proteção da informação classificada em simuladores e seus óbices.

2.1 HLA, INTEROPERABILIDADE E FILTRAGEM

A comunidade de Modelagem & Simulação entende a interoperabilidade como a capacidade de trocar informações e usar esses dados no sistema receptor (TOLK, 2016), assim interoperabilidade trata-se de fazer com que dois simuladores distintos trabalhem juntos de forma integrada, trocando mensagens e interagindo entre si.

Existem arquiteturas que padronizam a comunicação entre os diferentes sis-temas e uma destas é HLA, que foi desenvolvida, inicialmente, pelo DMSO (De-fense Modeling and Simulation Office) do DoD (Department of De(De-fense) dos Estados Unidos, visando facilitar a reutilização do código de simulação na defesa (TOPÇU; OGUZTÜZÜN, 2017).

2.1.1 Conceitos de HLA

O padrão HLA inicia com a especificação US DoD (United States Department of Defense) HLA 1.3. Em 2000 o IEEE descreveu o padrão HLA 1516-2000, e, em 2010 evolui para a sua atual versão, chamada de HLA 1516-2010 Envolved, a qual é descrita nos seguintes documentos: HLA Federate Interface Specification (IEEE, 2010c), HLA Framework and Rules Specification (IEEE, 2010a) e HLA Object Model Template (IEEE, 2010b).

O principal objetivo de HLA é facilitar a interoperabilidade entre os simuladores e promover a reutilização de simulações e seus componentes (IEEE, 2010a). Assim, o IEEE descreveu o padrão HLA para que os desenvolvedores possam estruturar suas

(22)

aplicações e descrever seus sistemas de simulação seguindo esse padrão.

O agrupamento de vários simuladores em HLA é conhecido como federação e cada simulador ou sistema que participa de uma federação é chamado de federado, conforme demonstrado na Figura 1.

Figura 1 – Federação e Federados

Fonte: (TOPÇU, 2017, p. 33)

As interações entre simulações em uma execução de federação são controladas pela RTI. A RTI é o middleware HLA, que integra e suporta as simulações. Ela for-nece uma API (Application Program Interface) para gerenciar federações, declarações, objetos, propriedade e tempo (ELKINS; WILSON; GRACANIN, 2001).

A troca de objetos entre federados em HLA é mediada pela RTI que encaminha os objetos para os federados relacionados usando o padrão P/S (Publish/Subscribe) (TOPÇU; OGUZTÜZÜN, 2017), no qual os componentes emissor e receptor, isto é, federados, declaram ao RTI o que precisam e o que podem fornecer para a execução da federação.

Como mostra a Figura 2, os federados podem publicar na RTI, em tempo de execução. A RTI tem a função de rotear objetos de um conjunto de modelos de dados que os federados podem fornecer (publish) e de um conjunto de modelos de dados que os federados estão prontos para receber (subscribe), sendo que esse conjunto de dados é estabelecido no FOM Document Data (FDD). Após a declaração de dados, o federado pode criar (register ) um objeto ou enviar (send ) uma interação. A RTI encontra os federados que assinaram a classe dos objetos ou interações e roteia o objeto/interação para os federados assinantes, assim, um federado assinante pode receber (receive) uma interação ou descobrir (discover ) um objeto. A atualização (update) dos valores dos atributos dos objetos funciona da mesma maneira. O federado publica a atualização (update) de valores de atributos de objetos e essa atualização é refletida (reflect) pelo roteamento feito pela RTI aos federados que assinaram aqueles objetos.

(23)

Figura 2 – Troca de objetos com base no padrão P/S

Fonte: (TOPÇU, 2017, p. 39)

O padrão P/S constitui a base do modelo de comunicação usado por HLA entre federados no que se refere a objetos e interações, onde publicar significa declarar disposição para fornecer dados e assinar significa declarar as necessidades de rece-ber determinados dados, sendo que a RTI encaminha dinamicamente os dados dos publicadores para os assinantes (TOPÇU; OGUZTÜZÜN, 2017) .

Ressalta-se que a normatização estabelece padrões a serem seguidos para que um sistema de simulação esteja de acordo com HLA, mas a implementação das APIs de programação e das RTIs é de responsabilidade de seus desenvolvedores (KUNDE, 2018).

2.1.2 Conceito do FOM e sua função na integração de simuladores

O formato dos dados a serem trocados entre os simuladores, é descrito no FOM (Federation Object Model), que é armazenado em um arquivo XML, sendo considerado a linguagem da federação. Ele é diferente para uma simulação de treinamento de defesa e uma simulação de ferrovia (MÖLLER et al., 2015).

Os componentes de um FOM são classes de objeto com Atributos, Classes de Interação com Parâmetros e definições de tipos de dados. Um FOM para aplicações de defesa pode conter, por exemplo, classes como Aircraft, Fire e Detonation. O uso de FOMs torna o padrão HLA flexível, podendo ser padronizado e personalizado (MÖLLER et al., 2014).

(24)

como FOMs de referência, traz os seguintes benefícios:

- economia de tempo e recursos financeiros, pois, esforços de projetos an-teriores podem ser reutilizados, sendo necessário, na maioria das vezes, apenas o desenvolvimento de pequenas extensões;

- redução do risco de projeto, uma vez que foram testados, ajustados e que foi comprovado seu funcionamento em projetos anteriores; e

- reutilização, pois, simuladores que suportam FOMs de referência podem interoperar com outros simuladores devido a sua capacidade de trocar dados de maneira compatível.

A NETN (NATO Education and Training Network ) desenvolveu o documento FAFD (Federation Architecture and Federation Object Model) que busca integrar e me-lhorar as capacidades existentes de simulação para permitir que as nações colaborem e possam interoperar de maneira mais eficaz na modelagem e aplicação de simulação voltada para missões militares (MIFSUD; LÖFSTRAND; LLOYD, 2014).

Os acordos de interoperabilidade incluídos no NETN FAFD baseiam-se na utilização dos serviços definidos no mais recente padrão HLA e inclui um conjunto de módulos do FOM definidos de acordo com o IEEE 1516-2010 OMT (Object Model Template) (MIFSUD; LÖFSTRAND; LLOYD, 2014).

O RPR (Real-Time Platform Reference) é o FOM usado normalmente para simulações de defesa e suporta muitos recursos de simulação como plataformas, aeronaves, veículos terrestres, navios, humanos, entidades agregadas, fogo, detonação, comunicações de rádio, logística e campos minados. Como seu nome indica, é focado na simulação em tempo real (MÖLLER et al., 2014) e devido à sua adoção generalizada em todo o mundo, há uma grande quantidade de softwares que suportam o RPR FOM, tanto comerciais como governamentais, sendo que o NETN FOM é também baseado no RPR e contém extensões específicas da NATO (North Atlantic Treaty Organization). 2.1.3 Interoperabilidade entre um federado e uma federação

Em uma simulação, um federado se conecta a uma federação conforme está representado na Figura 3, ou seja, diretamente a RTI, publicando e assinando tudo o que for disponibilizado na Federação à qual o Simulador está conectado e de acordo com o FOM utilizado.

(25)

Figura 3 – Conexão dos federados à federação

Fonte: o Autor

Nesse modelo, que é definido no padrão HLA, todas as informações publicadas na RTI são acessíveis por todos os simuladores que se conectam à federação, não havendo nenhuma proteção aos objetos publicados, assim, se um federado (simulador) possuir informações classificadas que estão publicadas na RTI, as mesmas ficarão disponíveis para conhecimento e uso de outros simuladores da federação, bastando que assinem tais objetos.

2.1.4 Uso de pontes na interoperabilidade entre federações

A interconexão de federações pode ser realizada através de links entre RTIs, mas essas conexões implicam em um novo protocolo, não fornecido pelas especifi-cações HLA. Os princípios do HLA se concentram nas federações de uma única RTI (BRÉHOLÉE; SIRON, 2003).

Para integrar federações distintas no padrão HLA, há necessidade de uma ponte (MÖLLER; LÖF, 2006), como representado na Figura 4, onde há duas federações HLA, sendo que o aplicativo de ponte atua como um federado em cada federação e publica e assina dados em ambas as federações (MÖLLER et al., 2014). Dependendo dos objetivos dessa conexão entre federações, as pontes precisam criar entidades para todos os objetos e interações ou ainda traduzir informações específicas da RTI que diferem de uma federação para outra (BRÉHOLÉE; SIRON, 2003).

Figura 4 – Interoperação entre federações

Fonte: o Autor

Além de permitir que informações possam ser trocadas entre simuladores de federações diferentes, a ponte pode possuir um filtro integrado que atuará no bloqueio de dados classificados entre as federações.

(26)

2.1.5 Filtro HLA

Alguns fatores estão causando a necessidade de simulação distribuída, como a formação de alianças industriais e a realização de treinamentos ou missões entre exércitos de nações diferentes. Nesse sentido, empresas e organizações enfrentam problemas quando há necessidade de cooperar e ter que proteger sua inteligência de negócios ou sua propriedade intelectual (MÖLLER et al., 2011).

Um filtro HLA permite modificar ou descartar dados conforme são transferidos entre federações, implementando a segurança associada às informações publicadas e trocadas entre as federações, ou seja, quando não se deseja que dados classificados sejam disponibilizados para outro domínio.

Além da função de proteção de dados classificados, o filtro HLA pode ser utilizado para reduzir o tráfego de informações entre federações, em situações onde o link WAN é lento ou instável (MÖLLER et al., 2014).

2.2 JUSTIÇA NO COMBATE

Ao executar simulações distribuídas onde sistemas desenvolvidos independen-temente são suportados por modelos de intercâmbio de informações e protocolos de troca de informações entre estes sistemas de simulação, um dos problemas a ser solucionado trata-se das lutas injustas. O espaço de batalha deve ser comum para os elementos de combate, ou seja, como se movem, agem e se comunicam. Se o espaço de batalha virtual difere significativamente em dois simuladores (federados) que fazem parte de uma federação, o resultado será uma luta injusta, devido à representação diferente do ambiente de simulação (TOLK, 2016).

Diferentes sistemas de simulação usam uma representação diferente do mundo real, pois, são desenvolvidos para diferentes propósitos. Uma representação diferente do mundo real não necessariamente inviabiliza a luta justa, por exemplo, se os efeitos de comunicação não são importantes para um ambiente de simulação específico, a luta justa é alcançada mesmo se a comunicação entre unidades é modelada diferentemente por dois sistemas de simulação (SIEGFRIED et al., 2013).

A posição dos modelos de construção do terreno (móveis, carros, rochas, etc.) é significativa para manter uma luta justa. Por exemplo, enquanto pedras e carros queimados fornecem no VBS1 (Virtual BattleSpace) cobertura durante um conflito, esses objetos podem não ser modelados em um simulador construtivo, alterando assim a consciência situacional do usuário construtivo e, potencialmente, permitindo-lhe ver um jogador do simulador virtual VBS, que acredita estar protegido (CALYTRIX TECHNOLOGIES, 2014).

Quando há necessidade de interoperação entre simuladores, as lutas justas podem ser violadas por diferenças em ambientes, objetos, capacidades, visibilidade,

(27)

capacidade de armamentos e gerenciamento do tempo (SIEGFRIED et al., 2011) e o resultado dessas diferenças ou disponibilização de informações incompletas de objetos entre os simuladores podem levar a uma desvantagem e consequente luta injusta.

A luta justa só pode ser definida para um ambiente de simulação específico, ou seja, não há luta justa absoluta. Dois ou mais sistemas de simulação só podem estar em luta justa no que diz respeito aos objetivos e restrições de um ambiente de simulação específico (SIEGFRIED et al., 2013).

2.3 CLASSIFICAÇÃO DE SIMULAÇÃO

Simulação pode ser classificada em três classes distintas: simulação viva, virtual e construtiva (LVC), sendo que esses tipos variam conforme operadores e ambiente, ou seja, simulações podem incluir pessoas reais fazendo coisas reais, pessoas reais operando em ambientes simulados ou ainda pessoas reais fazendo inserções ou interagindo com pessoas e ambientes simulados.

2.3.1 Simulação viva

Na simulação viva, pessoas reais operam sistemas reais. Por exemplo, um piloto lançando bombas de aeronaves reais em alvos físicos para fins de treinamento, testes, ou para avaliar a capacidade operacional é considerada uma simulação viva (HODSON; HILL, 2014). A simulação viva utiliza material e pessoal no terreno.

Esta simulação se esforça para ser o mais próximo possível do real envolvendo equipamentos ou sistemas. Na área militar, é utilizada a simulação viva em jogos de guerra que colocam soldados reais e plataformas reais em uma situação de com-bate onde armas reais ou impactos são substituídos por instrumentos. O objetivo do treinamento de simulação viva é fornecer experiência significativa para o treinando (SOKOLOWSKI; BANKS, 2010).

Exercícios no terreno são utilizados para desenvolver ou confirmar o que foi aprendido e funcionou no exercício na carta. Esse processo é dinâmico, pois, os exercícios na carta e as manobras no terreno podem levar a novas ideias. Pode ocorrer também a mudança de ações se estas se revelarem menos efetivos do que o esperado, buscando-se validar a doutrina tendo por base seu desempenho nas simulações de combate (CUNHA, 2011).

2.3.2 Simulação virtual

A simulação virtual é o meio-termo entre simulação viva e construtiva. Na simulação virtual, pessoas reais operam sistemas simulados. Estes sistemas são criados com simuladores projetados para imergir o usuário em um ambiente realista

(28)

(HODSON; HILL, 2014), fornecendo mais experiência e feedback do que a simulação construtiva, mas com menor custo e tempo do que a simulação viva (FLETCHER, 2009).

As aplicações da simulação virtual para treinamento em rede podem incluir grupos dispersos globalmente colaborando em experimentos científicos, resolução de problemas ou tomada de decisão usando equipamentos que estariam inacessíveis de outra forma, visitando locais de difícil acesso para pesquisa de campo ou recebendo acompanhamento de especialistas (FLETCHER, 2009).

Um exemplo de treinamento em simulação virtual é o simulador de cockpit usado para treinar pilotos de aeronaves. Este simulador usa uma representação física do cockpit real com modelos de computador para gerar dinâmicas de voo e mudanças ambientais/atmosféricas às quais o piloto deve responder (SOKOLOWSKI; BANKS, 2010).

2.3.3 Simulação construtiva

Na simulação construtiva, modelos computacionais geram saídas de acordo com decisões tomadas pelo usuário. Este tipo de simulação envolve pessoas reais fazendo inserções em uma simulação com pessoas simuladas que operam sistemas simulados (SOKOLOWSKI; BANKS, 2010). Nesta categoria de simulação o tempo também pode ser simulado, avançando mais rapidamente que o tempo real. Desta forma o tempo é otimizado e resultados são gerados com maior rapidez, o que favorece o emprego desses simuladores como ferramentas de apoio à decisão em operações militares reais.

No Exército Brasileiro, a organização e a condução de Exercícios de Simulação Construtiva, é denominada JG (Jogo de Guerra), que é um exercício tático no qual são empregados meios computacionais para a apresentação digital do cenário e para a simulação de operações continuadas de combate, apoio ao combate e logística, sendo que o sistema de simulação utilizado é gerenciado pelo COTER (Comando de Operações Terrestres) (BRASIL. Exército Brasileiro, 2017).

A Simulação Construtiva utiliza de forma integrada diversos modelos. Frações militares amigas e inimigas são modeladas e representadas como ícones, da mesma forma o terreno e o clima representam modelos que interagem entre si ao longo da simulação. Os eventos, como, por exemplo, os engajamentos entre as forças oponentes, fazem uso de modelos matemáticos relacionados aos diversos atributos das entidades envolvidas (CUNHA, 2011).

(29)

2.4 SEGURANÇA DA INFORMAÇÃO PUBLICADA

Ao tratar da segurança da informação que é disponibilizada (publicada) pelos simuladores o grande desafio está em definir quais sistemas do ambiente de simulação poderão ter acesso a esses dados, que muitas vezes possuem uma classificação alta de segurança.

2.4.1 Treinamentos coletivos e seu impacto sobre as questões de segurança de informações em simuladores

Normalmente em CMS (Colective Mission Simulation) há necessidade de satis-fazer requisitos de aceitação de mais de uma nação (MÖLLER et al., 2012), os quais tem impacto sobre as questões de segurança sobre os seguintes aspectos:

• Valor da informação - os simuladores precisam de informação “exata” para funcionar e demonstrar uma visão real das capacidades do simulador.

• Visibilidade - além do valor da informação o raio de exposição de informações é maior no CMS. Dados verdadeiros do terreno incluem interações detalhadas de sensores e sistemas de armas e é potencialmente visível para todas as entidades participantes do treinamento.

• Tamanho da amostra - O CMS oferece a possibilidade de executar a mesma operação por repetidas vezes, podendo ser testadas sob diferentes circunstân-cias.

Assim, há possibilidade de ocorrer a disponibilização indevida de informações consideradas sigilosas em simuladores, sendo que as principais formas de vazamento são: a transmissão inadequada de itens de dados, as informações derivadas de ações tomadas por entidades que revelam involuntariamente capacidades em um nível de classificação mais alto e as informações derivadas da agregação de dados individuais não classificados que, quando em conjunto, revelam informações sigilosas (MÖLLER et al., 2015).

2.4.2 Impacto das medidas de segurança sobre as informações publicadas Deve haver um equilíbrio entre os riscos decorrentes do vazamento de dados versus os riscos de um treinamento abaixo do ideal. Relacionado a isso, Möller et al. (2015) refere que, quando medidas de segurança são aplicadas à simulação é necessário considerar se:

• o treinamento é válido – quando a segurança das informações dos simuladores é protegida pela limitação do que pode ser visto em relação ao que é produzido,

(30)

há necessidade de verificar se o treinamento permanece válido com essas limitações;

• o desempenho é suficiente – deve haver uma preocupação quanto aos efeitos adversos que a introdução de soluções de segurança pode causar sobre as metas de treinamento; e

• a informação pode ser fornecida aos participantes - alguns participantes podem ter metas de treinamento que precisam de informações classificadas e que não podem ser divulgadas a outros participantes. Há necessidade de verificar se o não fornecimento de determinadas informações não irá prejudicar o aprendizado do estagiário.

2.4.3 Como tratar dados de diferentes classificações em simulação

Em simulação há algumas formas de tratar dados classificados, sendo necessá-rias medidas de segurança adequadas para lidar com diferentes níveis de segurança. A seguir estão elencadas algumas MDSA (Multi-Domain Security Architecture) conhe-cidas, as quais podem ser estudadas, para individualmente ou combinadas, auxiliar na solução total ou parcial da filtragem de informações com níveis de classificação distintas.

2.4.3.1 SH (System High)

Nessa abordagem todos os simuladores conectados devem ser reclassificados para o mais alto nível de classificação na rede conforme demonstrado na Figura 5, assim, cada participante da simulação concorda em expor todos os dados que são trocados com todos os outros participantes. Isso pode resultar em risco inaceitável para alguns participantes que terão um trabalho significativo para retirar informações classifi-cadas do exercício com possível perda no valor de treinamento (CROOM-JOHNSON; HUISKAMP; MÖLLER, 2013).

Figura 5 – SH (System High)

Fonte: (NATO, 2018, H-3 p. 3)

Uma arquitetura de segurança SH deve ser considerada para MDSA apenas enquanto não há soluções permanentes de MILS/IXG (Multiple Independent Levels of Security Information Exchange Gateway ) ou MLS (Multi Level Security ) (NATO, 2018).

(31)

2.4.3.2 MSL (Multi Single Levels of Security)

Essa abordagem é usada em exercícios de treinamento multinacionais onde duas ou mais redes de dados operacionais estão em domínios de segurança distintos e estas redes estão separadas fisicamente (CROOM-JOHNSON; HUISKAMP; MÖLLER, 2013).

Nesse caso os dados e sistemas com diferentes classificações de segurança são processados em sistemas separados. Assim, a troca de dados é obtida por intervenção manual, o que significa que os usuários precisam operar vários computadores. O tempo de resposta aumentará e a proteção contra vazamentos de informações recai sobre um operador humano (NATO, 2018).

Figura 6 – MSL (Multi Single Level of Security)

Fonte: (NATO, 2018, H-3 p. 3)

Conforme demonstrado na Figura 6 as redes de treinamento são mantidas separadas, sem conectividade e apenas “operadores em uma cadeira giratória” podem trocar informações.

2.4.3.3 MILS (Multiple Independent Levels of Security)

Nesse caso os dados são separados em diferentes domínios, dependendo da classificação, e, a conexão entre as duas redes pode ser estabelecida por um DD (Data Diod1) ou por um IXG (Information Exchange Gateway ) programável (NATO, 2018).

Um DD permite um fluxo de dados unidirecional do domínio de segurança de menor classificação para o domínio de segurança de classificação mais alta, e, de acordo com a política de segurança, ele bloqueará qualquer fluxo de dados do domínio de alta segurança para o domínio de baixa segurança, o que pode limitar o valor do treinamento (CROOM-JOHNSON; HUISKAMP; MÖLLER, 2013).

Como um exemplo, uma aeronave simulada em um domínio de baixa segurança não pode ver uma aeronave simulada em um domínio de alta segurança por que essa informação é bloqueada pelo DD, mas pode executar um disparo, pois essa informação é transmitida para o domínio de nível mais alto. A aeronave no domínio mais alto pode ver a aeronave no domínio inferior, pois, recebe essa informação do domínio de nível

1 Um Data Diod (Diodo de Dados) fica na borda do perímetro de segurança da rede e visa mitigar as

ameaças cibernéticas contra a rede, ao mesmo tempo que permite a transferência de dados para fora da rede de uma maneira controlada e determinista.

(32)

mais baixo, mas como o DD não permite passar nenhuma informação para o domínio de classificação mais baixa, não pode disparar na aeronave apesar de visualizá-la (MÖLLER et al., 2011).

Os DD utilizados em soluções de MILS, normalmente são dispositivos de hard-ware que impõe um fluxo unidirecional de dados entre uma rede e outra, como, por exemplo, BAE System Data Diode, Speed Data Diode, Fox DataDiode, entre outros que são citados em (NATO, 2018) e certificados pela NATO.

Um IXG bloqueará seletivamente ou encaminhará o fluxo de dados bidirecio-nalmente entre os domínios de segurança de acordo com a política de segurança. Nesse caso, um gateway ou uma ponte é introduzida entre dois domínios de segurança diferentes conforme demonstrado na Figura 7 e um conjunto de políticas controla quais dados podem fluir entre domínios diferentes pela combinação de Guardiões (CROOM-JOHNSON; HUISKAMP; MÖLLER, 2013).

Figura 7 – MILS (Multiple Independent Levels of Security)

Fonte: (NATO, 2018, H-3 p. 3)

2.4.3.4 MLS (Multi Level Security)

É considerado por (NATO, 2018) uma solução mais flexível para treinamento e operações multinacionais, pois permite conectividade total entre participantes de simulações LVC (Live, Virtual and Constructive). Nesse caso, todas as informações são armazenadas em uma rede corporativa protegida conforme demonstrado na Figura 8, que é confiável para conter dados confidenciais em vários níveis de classificação. Assim, dados de sistemas de diferentes classificações são misturados livremente e armazenados em um Trusted System, usando dispositivos como DD e Guardiões para liberar dados aos participantes com base em permissões “need-to-know ” de acordo com a identidade pré-registrada nas políticas de gerenciamento (CROOM-JOHNSON; HUISKAMP; MÖLLER, 2013). O mecanismo de liberação, geralmente chamado de Trusted Guard, pode ser baseado na classificação e conteúdo da informação.

(33)

Figura 8 – MLS (Multi-level Security)

Fonte: (NATO, 2018, H-3 p. 3)

2.5 TRABALHOS RELACIONADOS

A seguir são apresentados trabalhos que de alguma maneira tratam da infor-mação classificada que pode estar presente em simuladores utilizados por diferentes nações. São destacadas quais soluções são adotadas para manter seguros esses dados e quais os óbices destas abordagens.

Andrews, Wharington e Stratton (2008) propõem uma arquitetura de segurança denominada SecProxy, que consiste em uma biblioteca (libSec) e em um servidor que irá fornecer o proxy para a RTI (SecProxy). A libSec se interpõe entre o Federado e a RTI e executa o processamento necessário para o envio e recebimento de informações do servidor SecProxy, que fará o serviço de intermediação (proxy ) entre o Federado e a RTI e também aplicação das regras de segurança, armazenadas em arquivo XML, para Federados e chamadas RTI. O autor propõe a interposição da libSec no lugar da libRTI, exigindo que libSec forneça uma API idêntica à libRTI e garanta que uma chamada para uma função sempre será direcionada a libSec. libSec irá se comunicar com SecProxy como se este fosse a RTI e SecProxy se comunicará com libSec como se essa fosse a libRTI, colocando assim uma camada de software entre o federado e a RTI. Percebe-se que essa abordagem funciona bem, mas o desenvolvedor precisará adaptar a libSec conforme as chamadas de função do federado, o que pode ser distinto para cada simulador.

Verkoelen e Wymenga (2009) fizeram uma descrição conceitual de segurança para identificar informações classificadas e efetuar modificações necessárias antes de enviá-las, a fim de tomar as medidas necessárias para prevenir o vazamento de informações de um ambiente de simuladores. Esse conceito é baseado em mecanismos de rotulagem e liberação efetuados como um gateway que é colocado próximo do simulador (federado HLA) que deve ser protegido. A classificação de segurança é implementada em bancos de dados distintos para cada nível de classificação. Os bancos mantêm os objetos HLA sem seus valores reais e devem ser definidos para cada objeto de um determinado simulador. Percebe-se que a alimentação desses bancos de dados, exige um grande trabalho prévio para classificar cada informação disponível no federado. Além disso, exercícios distintos podem demandar revisões de classificação

(34)

de níveis de segurança aumentando o esforço para adequar as informações do banco de dados.

Ceranowicz et al. (2013) expõem que as arquiteturas atuais para treinamento de domínio cruzado são difíceis de mudar e pouco escaláveis e afirma que isso é uma consequência de sua criação em um único domínio de segurança isolado, desta forma eles propõem que os simuladores sejam projetados desde o início sob uma arquitetura multi-nível, onde as federações protegeriam cada objeto de informação que passa pelo acordo com a política de segurança apropriada. Em seu trabalho ele descreve uma arquitetura onde os fluxos entre os módulos de simulação operem em níveis de segurança diferentes, sendo isolados por módulos (guardiões) que garantem que apenas mensagens contendo conteúdo autorizado são transferidas. O módulo de alto nível (mais restritivo) está ciente de todos os aspectos do estado atual disponível para o simulador, enquanto os níveis mais baixos têm acesso a visualização de menos informações. A criação de novos projetos de simuladores contendo níveis de segurança é uma proposta viável, mas apesar da dificuldade em fazer mudanças e adaptar os sistemas atuais para operarem em domínios diferentes com a devida segurança, é caro e trabalhoso criar novas federações para treinamento com as mesmas características das existentes e com o suporte a multi-nível proposto. É mais vantajoso encontrar soluções de segurança adaptáveis aos projetos existentes.

A abordagem de interpor uma camada de software entre o federado e a RTI, conforme propõem Andrews, Wharington e Stratton (2008),Verkoelen e Wymenga (2009) e Ceranowicz et al. (2013), onde a classificação ocorre no simulador, apesar de ser uma forma segura de proteger os dados classificados em simuladores, apresenta os seguintes óbices:

- dificuldade de gerenciar a segurança de diferentes clientes, pois exige projetos específicos de plugin onde cada cliente define o que é sensível no seu caso e alterações futuras exigem mudanças no plugin do simulador;

- em exercícios multinacionais, os níveis de classificação entre os domínios podem ser distintos, ou seja, informações que podem ser compartilhadas com uma determinada nação podem não ter permissão de compartilhamento com outra nação participante do exercício, devido a alianças ou tratados estabelecidos. Um filtro aplicado diretamente ao federado irá restringir ou liberar dados de forma unificada; e

- há situações em exercícios multinacionais onde informações de um determi-nado simulador interessa somente à federação local e a filtragem de dados entre o simulador e a RTI poderá ocasionar perdas ao treinamento que está dentro do domínio de segurança nacional.

No sentido de proteger dados classificados de simuladores HLA, (MÖLLER et al., 2015) propõem o uso de gateways de troca em um sistema de treinamento dividido em domínios de alta e baixa segurança. Estes domínios são conectados por guardiões que aplicam políticas de segurança que podem consistir em componentes de software

(35)

como filtros de protocolo e componentes de hardware de controle de fluxo de dados como DDs. A solução de Möller et al. (2015) propõe a separação dos simuladores em federações distintas, onde uma contém os federados com informações restritas e a outra federação contém os federados com informações não classificadas (não sensíveis ou com pouca necessidade de proteção). Na federação sem classificação tudo pode ser publicado e na federação de classificação alta somente informações não sigilosas podem ser publicadas, assim somente dados não classificados são trocados entre as federações. Essa característica exige adaptações nas características dos federados da federação de classificação alta para evitar a publicação de dados sigilosos, o que pode exigir o acompanhamento de técnicos. Além disso, esse modelo coíbe a participação de simuladores com dados sigilosos na federação de baixa classificação de segurança, o que pode restringir o exercício no domínio local. A solução apresentada neste trabalho é mais eficiente por permitir a filtragem por instância (filtra elementos específicos), permitindo que as federações nacionais acomodem federados que contém dados com diferentes níveis de segurança e evitando a necessidade de reorganizar os simuladores, separando os que possuem informações sigilosas dos que não possuem informações sigilosas.

(36)

3 UMA PROPOSTA DE SEGURANÇA EM SIMULAÇÃO MILITAR MULTINACIO-NAL

Para a realização de operações multinacionais há necessidade de unificar esfor-ços entre os líderes nacionais e militares dos países participantes enfatizando objetivos comuns e interesses compartilhados, sendo que acordos estratégicos e militares claramente definidos para a Força Multinacional são essenciais para orientar toda a coordenação, planejamento e execução de um treinamento (EUA, JOINT CHIEFFS OF STAFF, 2017).

Os interesses de uma nação podem não estar em completo acordo com os interesses das outras nações ou organizações, necessitando consultas e coordenação nos níveis político e militar para definição dos objetivos operacionais comuns, havendo necessidades de tratativas que antecedem ao treinamento e ao seu planejamento. Estes acordos podem envolver participantes, simuladores, ambientes e outros elementos que fazem parte de um treinamento multinacional.

Este capítulo tem por objetivo demonstrar que a segurança de dados contidos em simuladores é uma necessidade real em treinamentos militares multinacionais e apresentar uma solução de ponte-filtro, focada em uma arquitetura MILS de troca de informações, que visa proteger o tráfego de dados em operações colaborativas que envolvam duas federações de nações distintas. O capítulo inicia na Seção 3.1, que apresenta resultados da realização de um questionário sobre dados contidos em simuladores considerados sensíveis. Na Seção 3.2 são apresentadas as características que um filtro HLA deve possuir em exercícios de simulação multinacionais. Na Seção 3.3 são apresentadas as soluções de Segurança Multi-domínio utilizadas atualmente e sua relação com a solução proposta. Na Seção 3.4 são apresentadas as características técnicas e a arquitetura da solução de ponte-filtro proposta; e na Seção 3.5 estão descritas quais as vantagens do modelo apresentado para solucionar o problema proposto.

3.1 LEVANTAMENTO DE INFORMAÇÕES SENSÍVEIS

Inicialmente, buscou-se fazer um levantamento das principais informações con-sideradas sensíveis para o Exército Brasileiro em um treinamento multinacional com uso de simuladores para, com base nessa análise, elencar os requisitos necessários para proteger dados sensíveis presentes em simuladores militares Brasileiros.

O Exército Brasileiro está se inserindo em um contexto internacional no que tange a participação de exercícios que envolvem nações distintas e nesse contexto, a segurança da informação é um fator importante, pois em operações multinacionais, geralmente, as informações têm que ser classificadas em algum nível.

(37)

in-formações no âmbito do Exército Brasileiro, foram levantadas as principais inin-formações que podem estar inseridas em simuladores e que são consideradas sigilosas.

Para obtenção desses dados foi aplicado o questionário constante no Anexo. Este questionário foi enviado a 14 (quartorze) oficiais do exército brasileiro entre o posto de capitão e coronel, sendo que 8 (oito) militares enviaram suas respostas. Dentre os militares que responderam ao questionário, obteve-se que:

• 100% participou e trabalhou em Exercício de Simulação de Combate.

• 62,5% participou ou assistiu Exercício de Simulação de Combate no exterior. • 50% participou ou assistiu Exercício de Simulação de Combate onde

participa-ram países distintos.

Pela análise desses dados percebe-se que esses militares constituem uma boa fonte de obtenção de informações sobre simulação, pois estes trabalharam com siste-mas de simulação de combate e participaram de treinamentos por meio de simulação no Brasil e no exterior, podendo agregar ou ratificar informações sobre segurança em simulação obtidas na bibliografia relacionada ao tema.

Os militares participantes executaram diversas funções relacionadas à simu-lação de combate, dentre elas: controlador em jogos de Guerra, diretor de exercício, coordenador técnico de exercício, participante de equipe de aquisição e customização de simulador, participante de equipe de integração de simulador, gerente de projeto de simuladores, desenvolvimento de Comando e Controle (C2), participante de equipe de desenvolvimento de simulador, responsável pela montagem de cenário dos jogos de guerra, instrutor de operadores e controladores de sistema de simulação constru-tiva, observador de exercício construtivo internacional e participante de equipe de implantação de Simulação Virtual.

Outro dado importante obtido é que:

• 75% consideram que há informações sigilosas/sensíveis em simuladores e que sua operação por indivíduos não autorizados pode ser prejudicial a segurança do país.

• 62,5% consideram interessante a filtragem de determinadas informações conti-das nos simuladores.

Cabe ressaltar que os militares que consideraram que não há informações sensíveis em simuladores e que não consideram interessante a filtragem de informa-ções contidas nos simuladores, foram militares que não participaram de exercícios internacionais e esse é um fator que pode ter contribuído para que chegassem a essa conclusão.

(38)

A partir do relato das experiências dos militares que consideraram existirem informações sigilosas foram elencadas as informações consideradas sigilosas e que necessitam proteção em caso de exercícios multinacionais, foi gerada uma tabela que relaciona informações sensíveis e possível efeito em caso de vazamento destas.

Tabela 1 – Informações consideradas sigilosas obtidas dos questionários

Informação Sensível Efeito

Comportamento pré-definido (inteligência artificial) embutido nos sistemas de simulação, quanto à “forma de combater” de um exército e características de emprego de frações e armamentos

(comportamento doutrinário).

As informações podem ser utilizadas por membros de facções criminosas para compreender como seria a atuação das Forças Armadas em uma ação contra elas.

Características de radares, viaturas, armamentos, lançadoras e parâme-tros para cálculo de efeito de tiro.

O acesso a dados de inteligência que contém a composição de pessoal (quadro de cargos das OM do EB), equipamentos e suprimentos de unidades reais no EB (quadro de dotação de material e munição das OM do EB), dados matemáticos referentes a equipamentos e sensores, conhecimento doutrinário de peças de manobra de emprego estratégico e probabilidade de eficácia de diversos armamentos e sistemas, possibilitaria gerar informações georreferenciadas (por regiões do Brasil) das capacidades bélicas do EB e assim favorecer o movimento e manobra inimigos.

Ações de inimigos podem ser facilitadas ao compreender como seria a segurança de uma instalação militar.

Quadros de Dotação de Material (QDM) onde está disposta a composição de meios das Grandes Unidades, Organizações Militares e Frações.

Quadros de Cargos (QC) inseridos para alimentar o banco de dados do sistema (composição de tropas).

Dados Médios de Planejamento (DaMePlan) inseridos em probabi-lidades de acerto de armamento e de uso de sensores.

Os modelos de objeto utilizados em HLA podem disponibilizar informações sensíveis, inclusive quando são utilizados FOMs de referência como NETN ou RPR. Nestes há atributos como por exemplo:

• MunitionType (tipo de munição detonada) - relacionado ao efeito de tiro/arma-mento

• Formation (arranjo posicional das entidades) - relacionado às características de emprego de uma fração.

• Spatial (localização de uma tropa) - relacionado ao posicionamento das unidades no terreno.

Caso um simulador publique tais informações na RTI e considerando que esses são dados podem ser considerados sigilosos para determinados elementos especiais

(39)

(armamentos ou tropas) e que possuem efeitos nocivos em caso de vazamento, então justifica-se sua filtragem em exercícios multinacionais.

3.2 REQUISITOS NECESSÁRIOS À FILTRAGEM

Com base no levantamento feito via questionário e dados obtidos no referencial teórico referente as informações a serem protegidas contidas em simuladores baseados em HLA, percebeu-se a necessidade de alguns requisitos que um filtro HLA deve possuir para ser aplicado em exercícios de simulação multinacionais.

Conforme Ribeiro (2016) o emprego das Forças Armadas refere-se ao uso destas para cumprirem alguma de suas missões constitucionais. O exercício militar, onde está inclusa a simulação, é realizado na fase de preparo e a operação militar ocorre na fase de emprego.

Nas simulações militares, o preparo está diretamente ligado ao emprego, pois o preparo de uma tropa tem por objetivo dar as condições para um emprego eficiente. Quando tratamos do preparo pelo uso de simuladores em ambientes multinacionais, informações seguras relacionadas a tropas, equipamentos e doutrinas podem ser reveladas indevidamente, exigindo ferramentas para que isso seja evitado.

Um dos principais passos na condução do Jogo de Guerra é a preparação para o Jogo. Na condução e avaliação dos resultados são acordadas as regras do jogo e técnicas utilizadas, é revisado o conjunto inicial de forças e o Ambiente Operacional (EUA, JOINT CHIEFFS OF STAFF, 2017). A fase de planejamento do treinamento é o momento para que sejam definidas quais informações terão restrição de acesso para cada participante do exercício coletivo e, por consequência, a definição pelo uso de filtros de dados. Deste modo, estão elencadas nas subseções que seguem, considerações sobre informações restritas e que podem estar contidas em simuladores. 3.2.1 Requisitos referentes a pessoal, material e estrutura de frações

Tomando como referência o Exército Brasileiro, o QO (Quadro Organizacional) é o conjunto de documentos que uma OM (Organização Militar) possui em termos de base doutrinária, estrutura, pessoal e material para desempenhar suas atividades e tarefas (EXÉRCITO BRASILEIRO - EME, 2015). Dentre esses documentos há a Estrutura Organizacional, que detalha a concepção da OM, o QC (Quadro de Cargos), que são os cargos que preenchem a Estrutura Organizacional da OM e o QDM (Quadro de Dotação de Material) que prevê a quantidade de armamentos, munições, equipamentos, meios navais, aéreos, terrestres e anfíbios necessários ao cumprimento das atividades estabelecidas na base doutrinária. Em organizações militares equipadas e treinadas para emprego em operações militares essas informações possuem restrição de acesso.

Referências

Documentos relacionados

O estômago é um órgão revestido por uma mucosa, e essa mucosa produz enzimas digestivas, protege as células estomacais do ácido clorídrico e faz uma espécie de separação

O objetivo deste trabalho foi conhecer a prevalência dos sinais e sintomas relacionados à Disfunção Temporomandibular em um grupo de alunos do curso de fisioterapia, verificando

xạ thì không có đầy dủ các khâu của 1 phản xạ vì vậy sự co cơ đó chỉ là sự cảm ứng của của các sợi thần kinh và tế bào cơ đối với sự kích thích. - Trao đổi

(...) o controle da convencionalidade em sede internacional seria um mecanismo processual que a Corte Interamericana de Direitos Humanos teria para averiguar se o direito

Após cada VD pós-alta realiza-se um contato de referência com a Unidade Básica de Saúde (UBS) da área de abrangência da família, quando é entregue à enfermeira da

A pesquisa objetiva o estudo da Língua Inglesa, situando a pertinência do ensino de língua estrangeira nos currículos dos cursos superiores de tecnologia, mais especificamente da

Na camada de controle de acesso a autenticação e controle de acesso RBAC são modularizados por um mecanismo – intitulado Heimdall – criado para este fim,

Pressione as teclas CIMA/BAIXO para selecionar a opção e pressione a tecla DIREITA/ESQUERDA para ajustar aquela configuração1. Pressione SAIR para sair