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
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
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.
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.