Modelo de Segurança para Ambientes de Avaliação e Testes de
Segurança de Software
Davidson R. Boccardo1 , Girrese Reinehr1 , Raphael C. S. Machado1 ,
Wilson de Souza Melo Jr1 , Luiz Fernando Rust da Costa Carmo1
1
Instituto Nacional de Metrologia, Qualidade e Tecnologia - INMETRO
Rio de Janeiro – RJ – Brasil
{drboccardo, gfreinehr, rcmachado, wsjunior, lfrust}@inmetro.gov.br
Resumo. O termo software está cada dia mais onipresente no cotidiano das
pessoas, desde dispositivos para uso pessoal, transações comerciais, até em infraestruturas crı́ticas como os setores financeiro, energético e transporte. Com
isso, surge a necessidade de garantir a segurança e a confiabilidade destes sistemas devido ao risco de uma falha de projeto, implementação ou configuração
se tornar um ponto vulnerável a ataques. O Inmetro, como órgão regulador,
tomou a iniciativa de estabelecer requisitos de segurança de software de forma
a incrementar a confiabilidade e a segurança destes dispositivos. Um dos requisitos, que gerou muita polêmica, exige a abertura do código-fonte, levantando
preocupações por parte dos fabricantes quanto a preservação da propriedade
intelectual. Este trabalho apresenta um modelo de segurança para ambientes
de avaliação e testes de segurança de software, estabelecendo controles lógicos
como forma de mitigar possı́veis vazamentos de propriedade intelectual.
Palavras-chave: propriedade intelectual, avaliação e testes de segurança de
software
Abstract. The term software is increasingly omnipresent on people’s daily lives,
from personal use devices, business transactions, to critical infrastructure such
as financial banks, energy and transportation. So, it is extremely important to
ensure the security and reliability of these systems because of the involved risk
of a design flaw, implementation or configuration become a vulnerable point
for an attacker. Inmetro, as the regulator of metrology, has taken the initiative
to establish software security requirements in order to increase the reliability
and security of these devices. One of the requirements, which generated much
controversy, requires the disclosure of the source code, raising concerns by manufacturers about the preservation of intellectual property. This paper presents
a security model for software assessment environments and software security
testing, establishing logical controls as a way to mitigate potential intellectual
property leaks.
Keywords: intellectual property, software security assessment, software security
testing
1. Introdução
A presença de software em dispositivos utilizados direta ou indiretamente no cotidiano
das pessoas, sejam eles de uso pessoal ou de uso coletivo, cresce rapidamente. Para o uso
coletivo, temos visto cada vez mais infraestruturas nacionais crı́ticas com software embarcado, por exemplo sistemas de controle para os setores energético, transporte e financeiro.
Qualquer falha de segurança de software nestas pode acarretar prejuı́zos inestimáveis a
uma nação. Exemplos mais tênues, mas não menos importantes, envolvem dispositivos
envolvidos em relações comerciais, por exemplo, medidores de grandezas fı́sicas, sejam
elas diretas (tempo, temperatura, massa, volume) ou indiretas (energia, velocidade). Neste
contexto, a garantia da segurança de software está mais relacionada a confiabilidade da
transação comercial entre as partes envolvidas.
Nos cenários supramencionados, fica caracterizada a importância de se avaliar e
testar a segurança de software em dispositivos de software embarcado, seja para evitar
prejuı́zos financeiros a nação ou para inibir fraudes perpetradas por uma das partes de
uma transação comercial. Neste contexto, o Inmetro (órgão regulador brasileiro) tomou
a iniciativa desde 2009 de estabelecer requisitos de segurança de software, bem como estabelecer procedimentos de ensaio de segurança a fim de avaliar e testar o cumprimento
destes. Um dos requisitos envolve a abertura do código-fonte para análise de segurança
que combinada com detalhes de implementação, compilação do código-fonte e testes permitem ao órgão regulador avaliar o nı́vel de confiabilidade e segurança de um dispositivo.
Inicialmente, houve uma certa resistência por parte dos fabricantes quanto a abertura de detalhes de implementação de software (incluindo código-fonte) uma vez que poderia representar um risco a propriedade intelectual. Entretanto, após muitas discussões
ficou estabelecida que a melhor forma de garantir a segurança e a confiabilidade destes sistemas seria a abertura de detalhes de implementação. Como forma de evitar vazamentos de propriedade intelectual uma vez que detalhes de implementação (inclusive
código-fonte) serão repassados para um avaliador, o Inmetro estabeleceu controles fı́sicos
e lógicos para o ambiente de avaliação e de testes de segurança de software. Estes controles podem servir de base para qualquer entidade ou laboratório que seja acreditado para a
realização de tais atividades.
No presente trabalho, mostraremos uma proposta de aplicação de controles lógicos
a um ambiente computacional como forma de evitar vazamentos de propriedade intelectual, propiciando um nı́vel de segurança “relativamente similar” aos controles estritamente fı́sicos. A proposta envolve controles a serem adotados no ambiente de avaliação
e testes e um processo de avaliação e testes que está dividido em três fases: entrega de
documentação, avaliação e testes.
O artigo está estruturado da seguinte maneira. Na Seção 2 comparamos a abordagem proposta com outras soluções que adotam controles fı́sicos. Na Seção 3 descrevemos
o ambiente de avaliação e os controles lógicos adotados para a obtenção de um ambiente
de avaliação e testes de segurança de software que evite “ao máximo” o vazamento de propriedade intelectual. Seção 4 contém nossas considerações finais a respeito do ambiente
proposto.
2. Normas e Referências para Modelos de Segurança
Esta seção compara o ambiente de avaliação e testes de segurança de software baseado
em controles lógicos com abordagens de controles fı́sicos adotadas para controlar um
ambiente de avaliação. Uma avaliação de software tem essencialmente por objeto um
conjunto de algoritmos e procedimentos que na forma de programas e bibliotecas de pro-
gramas, constituem o software em si. Estes elementos são usualmente designados como
ativos de informação. Dadas as questões legais de propriedade intelectual envolvidas, estes ativos devem ser manipulados de forma segura, dentro de um ambiente computacional
apropriado para tal. Os cuidados para proteção deste ambiente e consequente segurança
dos ativos de informação envolvidos são baseados em boas práticas de gerenciamento
da segurança da informação, os quais são hoje explicitados em normas e padrões bem
difundidos.
Apenas como referência, é possı́vel citar as normas da famı́lia ISO 27000 que
se aplicam à gestão da segurança da informação. As normas ISO 27006 e 27007
estão intrinsicamente ligadas ao escopo deste trabalho. A primeira remete aos requisitos para organizações que trabalham com auditoria e certificação de sistemas de gestão
de segurança da informação enquanto a segunda discute como essas organizações devem ser auditadas, relacionando assim os conceitos de avaliação da conformidade e
acreditação, respectivamente. Outro padrão importante é o NIST Special Publication 80037 [NIST 2010], guia inicialmente voltado para a certificação e acreditação de sistemas de
informação no escopo do governo federal dos EUA. Atualmente este mesmo guia constitui um arcabouço de gerenciamento de risco para sistemas de informação, especialmente
sistemas de gestão de segurança da informação.
Usualmente, programas voltados à avaliação da conformidade de ativos de
informação são baseados em normas em padrões similares àqueles descritos. Um exemplo é a Portaria Inmetro 008/2013 [INMETRO 2013], que estabelece os “Requisitos
de Avaliação da Conformidade para Equipamentos de Certificação Digital padrão ICPBrasil”, ou seja, a infraestrutura de chave pública brasileira. No Anexo E da respectiva
portaria são definidos os “Requisitos Mı́nimos de Segurança para Laboratórios de Ensaios”, que são os responsáveis pela verificação e certificação desta categoria de produto.
Esses ensaios incluem evidentemente testes e ensaios do software embarcado em dispositivos como smart cards, leitoras de cartão e HSMs (Hardware Security Modules). Uma
grande ênfase é dada a requisitos associados à segurança fı́sica e lógica dos chamados
ativos da informação, que incluem os códigos-fonte correspondentes ao software avaliado. O documento supracitado apresenta, por exemplo 5 nı́veis de segurança, para acesso
aos ativos de informação. Em especial os nı́veis 3, 4 e 5, denominados respectivamente
como Sensı́vel, Depósito e Depósito individual, são bem restritivos em questões como
controle e permissão de acesso, definindo requisitos especı́ficos como autenticação forte
e atividades verificadas por duas entidades autenticadas simultaneamente, por exemplo.
Entretanto, em casos quando os ativos de informação dizem respeito única e exclusivamente ao software, determinadas medidas de segurança usualmente implementadas no
escopo de proteção fı́sica podem ser equiparadas a medidas de proteção lógica. Esta abordagem pode ser justificada principalmente em função da redução de custos associados ao
uso de elementos de proteção fı́sica, bem como à facilidade de se automatizar e controlar
ambientes seguros.
A equiparação de medidas de segurança no escopo fı́sico e lógico, todavia, não é
algo tão trivial. É fato que, em muitos casos, a segurança dos ativos de informação pode
atingir um elevado nı́vel a partir de mecanismos fı́sicos de proteção. Considere-se por
exemplo o cenário onde a avaliação de determinado software é feita unicamente em um
ambiente confinado, sem comunicação com o meio externo, e onde o acesso ao mesmo é
Figura 1. Modelo de segurança para avaliação e testes de segurança de software.
restritivo no sentido de impedir que pessoas envolvidas no processo adentrem ou deixem o
ambiente munidos de qualquer dispositivo passı́vel de uso para obtenção de informações
(tais como smartphones ou pendrives). Sem dúvida, tal cenário é dificil de ser equiparado por qualquer mecanismo de proteção lógico, como por exemplo um terminal para
acesso somente de leitura aos ativos de informação. Todavia, a combinação de diferentes
tecnologias hoje disponı́veis para gerenciamento dos sistemas de informações, bem como
práticas consolidadas de codificação e testes de software, tais como a verificação em pares
e integração contı́nua, permitem se obter um elevado grau de segurança lógica dentro de
um ambiente razoavelmente flexı́vel em termos de segurança fı́sica e custo significativamente inferior. A apresentação de alternativas similares àquelas aqui exemplificadas é o
escopo deste trabalho, tal como será detalhado nas próximas seções.
3. Modelo de Segurança
O modelo de segurança para o ambiente de avaliação e de testes de segurança de software
envolve dois computadores, um para o ambiente de avaliação e outro para o ambiente de
testes. As fases do processo de avaliação e de testes compreende três atividades: entrega
de documentação, avaliação e testes. Como em qualquer sistema baseado em um sistema
de informação, temos o papel de um administrador com plena capacidade de evadir a
segurança; contudo, com monitoramento, auditoria, administração em par e revezamento
do papel de administrador, inibi-se pelo menos más práticas que poderiam ser realizadas
por um administrador, bem como fornece meios para atribuir culpa. Detalharemos a
seguir uma visão geral dos ambientes para depois especificarmos sobre as atividades de
um processo de avaliação e testes de segurança de software, conforme a Figura 1. Todas
as propriedades do processo de avaliação de avaliação inibem ou dificultam o vazamento
de propriedade intelectual.
3.1. Ambientes de Avaliação e Testes
Ambiente de Avaliação
O ambiente de avaliação consiste de uma máquina Linux sem conectividade com a Internet e sem acesso fı́sico as suas interfaces. Uma vez que as documentações entregues em
formato digital (incluindo código-fonte) por parte do fabricante são armazenadas nesta
máquina, o isolamento da máquina com a Internet mitiga a exploração de vulnerabilidades oriundas de conexões externas; o isolamento das interfaces mitiga a extração de
memória volátil e não volátil.
A visualização da documentação é feita por meio do Protocolo de Desktop Remoto, do termo em inglês Remote Desktop Protocol (RDP) [xrdp ]. O protocolo RDP
possui três nı́veis de segurança para as conexões entre servidor e cliente, configurados por
meio de uma diretiva configuração. O nı́vel mais alto utiliza criptografia RC4 de 128 bits
nas duas vias. A utilização de criptografia no protocolo RDP impede que um atacante
obtenha as credenciais de um avaliador por meio da escuta (sniffing) dos pacotes na rede
local.
O controle de acesso a máquina remota é realizado pela autenticação do avaliador por meio da solicitação de um usuário e senha. Uma vez autenticado, o avaliador
somente é autorizado a visualizar as documentações a ele atribuı́das. A atribuição da
documentação ao avaliador é feita pelo administrador que concede acesso somente de
leitura da documentação por meio de controle de acesso discricionário. Evita-se, portanto, que o avaliador altere a documentação do fabricante e impede que usuários não
autorizados tenham acesso às documentações.
Mesmo que o acesso a documentação seja feito de forma remota, ainda é possı́vel
que o próprio avaliador, ou um atacante com as credenciais do avaliador, repasse a
documentação por meio da rede local para um computador atacante, e a transmite via
Internet. Também existe a possibilidade de o atacante armazenar a documentação em um
dispositivo externo. Aqui, considera-se o cenário de um atacante interno (insider) com
acesso a Internet (no modelo a máquina de avaliação não tem conectividade com a Internet) e localizado na mesma rede da máquina de avaliação. Com isso, o atacante pode utilizar de um cliente instalado na máquina de avaliação para criar uma conexão com o computador atacante por meio da rede local com a finalidade de repassar a documentação. Por
exemplo, um navegador instalado na máquina para visualizar documentações em HTML,
permite ao atacante configurá-lo para conectar a um proxy situado no computador atacante, e a partir desta conexão, repassar a documentação. Como forma de bloquear este
repasse, o ambiente de avaliação está por trás de um firewall, por meio de regras estabelecidas no iptables, interface para o firewall padrão do Linux. As regras somente permitem
que conexões RDP sejam aceitas no ambiente de avaliação, limitando ao avaliador a trabalhar somente com a visualização da documentação, impedindo a criação de conexões
externas e eventualmente o repasse de propriedade intelectual.
A inserção de documentações no ambiente de avaliação é feito pelo administrador
por meio do protocolo Secure Shell (SSH) [OpenSSH ]. Logo, além de permitir conexões
RDP, conexões para o serviço SSH e para o usuário administrador são habilitadas no firewall. Para evitar o acesso não autorizado e garantir o isolamento dos arquivos, que
usuários não transfiram documentações para seus próprios computadores, o serviço de
SSH está disponı́vel apenas para o administrador, visto que é possı́vel transmitir arquivos através deste protocolo. O arquivo de configuração deste serviço possui uma diretiva a qual apenas permite que os usuários listados nela possam se conectar, desta forma
inclui-se apenas o usuário utilizado pelo administrador. Adicionalmente por questões de
segurança limita-se o acesso apenas para a mesma sub-rede (interna). A autenticação do
administrador é feita por criptografia de chave pública, evitando ataques de senha fraca
ou do tipo shoulder surfing.
O administrador eventualmente precisará instalar ou atualizar pacotes, nesta
ocasião haverá uma regra alternativa para as conexões, que uma vez em vigor, derrubará todas as conexões ativas e desativará o daemon RDP. Considera-se o ambiente de
avaliação no estado de manutenção, na qual poderá se conectar à Internet, porém apenas
um administrador com acesso ao SSH poderá estar conectado neste estado. Ao término
da manutenção, o administrador executará um procedimento (determinado em um script
bash) que reverte para as configurações do estado de produção, retornando as conexões
RDP e desabilitando o acesso à Internet, assim permitindo que as avaliações sejam retomadas.
Em um eventual caso que o disco seja comprometido, fisicamente removido
e possivelmente roubado, o atacante estaria impossibilitado de extrair a memória não
volátil, pois o disco inteiro (root filesystem) é criptografado utilizando o método dm-crypt
[dm crypt ]. Este método é muito mais recomendado para sistemas crı́ticos, inclusive
informações como nomes de usuários, programas instalados e logs são criptografados.
Dentro do ambiente de avaliação existirão várias máquinas virtuais convidadas
para a compilação dos códigos, uma vez que diferentes fabricantes precisam de ambientes de compilação distintos. Tais ambientes serão instalados/configurados pelo mesmo
administrador do ambiente de avaliação. O processo de autenticação entre a máquina
convidada e a máquina anfitriã é feita via SSH, na qual o avaliador utilizará as mesmas
credenciais de acesso ao sistema remoto para logar na máquina virtual. Após autenticar, o avaliador terá autorização para acessar os dispositivos sob sua avaliação, através
do protocolo Secure File Transfer Protocol (SFTP). As máquinas convidadas terão suas
interfaces de rede configuradas como “host-only”, opção da configuração que permite que
a máquina convidada se comunique somente com a máquina anfitriã. Com isso evita-se
qualquer comunicação de um cliente interno da máquina convidada com o ambiente externo. Após o processo de compilação do código ser concluı́do, o sistema notificará o
administrador para copiar o binário resultante para o ambiente de testes.
Ambiente de Testes
O ambiente de testes requer que suas interfaces de entrada e saı́da estejam disponı́veis, e
é necessária uma conexão para gravar os dados nos dispositivos. O servidor de testes tem
acesso apenas ao binário que será gravado no dispositivo, pois caso a máquina de teste
possuı́sse também os códigos-fontes, seria uma via alternativa para o “mundo exterior” e
quebraria todo o isolamento anteriormente estabelecido no ambiente de avaliação.
A equipe de testes poderá ter permissões para administrar o ambiente de testes
de acordo com o necessário para o seu trabalho. Visto que este ambiente não estará
de posse da propriedade intelectual do fabricante, pelo menos não do código-fonte, o
ambiente deve visar a praticidade para a realização dos testes. Ainda assim existem um
procedimento para descarte do binário do fabricante após a realização dos testes.
3.2. Fases do Processo de Avaliação e Testes
3.2.1. Entrega de documentação
A atividade de entrega de documentação envolve o envio de documentação do dispositivo
para a entidade responsável para realizar a avaliação e o teste de segurança do software.
Está documentação do dispositivo compreende detalhes do projeto, implementação (inclusive código-fonte), código-executável e o próprio dispositivo. Toda documentação
deve ser entregue de forma criptografada usando criptografia de chave pública e encaminhada para a entidade responsável por qualquer meio de comunicação.
Para tal finalidade, utilizamos por padrão a ferramenta da GNU Privacy Guard
(GPG) [GnuPG ] que implementa de forma completa e gratuita (livre) o padrão
OpenPGP. A ferramenta permite a criptografia e assinatura de mensagens e comunicação.
O algoritmo atualmente utilizado para entrega de documentação é o RSA 2048 bits. O
par de chaves é gerado no ambiente de avaliação e a chave pública é encaminhada para
qualquer fabricante que deseje enviar documentação para avaliação e testes (somente o
administrador tem acesso a chave privada correspondente).
Armazenamento
Esta atividade envolve a descriptografia da documentação entregue e seu subsequente
armazenamento no ambiente de avaliação. A descriptografia envolve a utilização da ferramenta GNU Privacy Guard (GPG) no arquivo criptografado do fabricante. Uma vez
que a chave privada correspondente somente está localizada na máquina do ambiente de
avaliação, nenhuma outra máquina é capaz de extrair seu conteúdo a não ser a máquina
de avaliação.
O primeiro passo após os dados estarem no ambiente de avaliação é gerar e armazenar o hash (SHA1) do arquivo criptografado enviado (GPG) e manter uma cópia
dele intacta. A razão de manter a cópia ı́ntegra do arquivo entregue pelo fabricante se
deve ao fato de evitar possı́veis questionamentos feitos pelo lado fabricante em relação a
documentação que foi avaliada.
Para agilizar o trabalho de múltiplos avaliadores, os arquivos compactados são
extraı́dos recursivamente e apagados em seguida, isto diminui a eficiência no armazenamento, porém aumenta a eficiência pois um avaliador não terá que esperar a extração de
um arquivo e nem múltiplos avaliadores usar muito processamento concomitante ou ter
extraı́do em pastas de usuário.
A codificação dos nomes dos arquivos muitas vezes não é recebida na mesma da
qual o sistema operacional do ambiente de avaliação, isso pode gerar caracteres que não
são exibidos corretamente no explorador de arquivos, para facilitar a tarefa de avaliação,
assim que os dados são armazenados, a codificação é analisada e convertida para o formato padrão do ambiente.
Os arquivos são armazenados utilizando uma hierarquia de diretórios onde no
nı́vel acima temos o tipo do dispositivo, em um nı́vel abaixo o fabricante, no nı́vel subsequente o modelo, e abaixo do modelo temos a data da documentação entregue no padrão
ISO (aaaa-mm-dd), de modo que é possı́vel distinguir as documentações entregues. Essa
hierarquia é importante para a atribuição de avaliadores e diferenciação de versões reprovadas e aprovadas do modelo.
Backup
Uma vez que ambiente está suscetı́vel a ataques fı́sicos e não está devidamente protegido
contra desastres, como por exemplo, uma descarga elétrica muito forte, um procedimento
periódico é adotado para realizar a redundância dos dados da documentação. Esta redundância é feita em localidades fisicamente distintas, assim evitando a perda de dados
em múltiplos locais, como por exemplo, em uma enchente. A ferramenta atualmente utilizada é o duplicity que fornece um modo eficiente para realizar backups incrementais com
conteúdo criptografado, permitindo transferências reduzidas por meio de, entre outros, o
algoritmo rsync [rsync ]. O fato dos dados já serem transmitidos de forma criptografada
deve-se ao fato de evitar vazamentos durante a transmissão e no armazenamento destino.
A primeira execução de um backup incremental é realizada de forma completa,
para após somente realizar incrementos apenas para os arquivos alterados. Desta forma
o tráfego da rede quando assim transferidos e todas operações de entrada-saı́da são reduzidas. O duplicity [duplicity ] por padrão não é uma ferramenta de backup periódica e
não assistida, para utilizá-lo sem precisar da interação de um administrador é necessário
combiná-lo com cronjobs e criar um script onde haverá as passphrases das key files. Os
backups são executados diariamente, sendo que a cada mês é gerado um novo backup
completo para diminuir a glanularidade, mantendo o sistema gerenciável e agilizando
uma eventual restauração, visto que os backups completos são mais rápidos para serem
restaurados.
3.2.2. Avaliação
Em linhas gerais, a avaliação consiste na análise de documentos de projeto e
implementação, e na inspeção de código-fonte. A análise de projeto e implementação
permite identificar falhas de segurança estruturais do projeto do dispositivo. A inspeção
de código permite verificar o mapeamento da implementação com a documentação, mas
também envolve a varredura de vulnerabilidades associadas ao desenvolvimento inseguro
de software. Após a avaliação de segurança de um código-fonte ser realizada e aprovada, ainda é necessário verificar se o respectivo código-binário — que estará, de fato,
em execução no dispositivo — corresponde ao código-fonte previamente avaliado.
O processo de garantir que o código binário embarcado corresponde ao códigofonte a ser avaliado denomina-se rastreabilidade do binário. Este processo é realizado em
máquinas convidadas, nas quais possuem o ambiente de compilação utilizado pelo desenvolvedor. Com isso, torna-se possı́vel reproduzir exatamente o ambiente de desenvolvimento do fabricante com a finalidade de compilar o código-fonte previamente aprovado.
O binário resultante deste processo iniciará a fase de testes caixa-preta a ser conduzido
sob o dispositivo em avaliação.
3.3. Testes
Entre as atividades do ambiente de testes destacamos a carga do binário correspondente
no dispositivo a fim de verificar se o dispositivo está de fato atendendo ao protocolo descrito na documentação; a coleta de resumos criptográficos da memória (completa ou parcial por intervalos) a fim de verificar a integridade do software embarcado a posteriori; a
realização de testes selecionados de segurança a fim de verificar a robustez do dispositivo;
e os testes funcionais nos quais todas as funcionalidades descritas na documentação são
executadas a fim de conferir se a respectiva funcionalidade está de acordo com a funcionalidade descrita na documentação e se a mesma não interfere nos requisitos especı́ficos
do dispositivo avaliado, nos quais estão definidos em portaria especı́fica.
4. Conclusões
A garantia que a propriedade intelectual do fabricante será mantida deve ser garantida
através de um modelo de segurança. Este modelo deve incluir um ambiente seguro, na
qual o nı́vel de confiança pode ser adquirido pela adoção estrita de controles fı́sicos, como
por exemplo uma sala cofre onde avaliadores são inspecionados durante a entrada e monitorados durante a avaliação. Este trabalho propõe uma abordagem diferente a qual busca
minimizar os custos ao transferir o método de adquirir confiança pela implementação de
controles lógicos, um ambiente seguro por boas diretivas de controle de acesso no nı́vel
do sistema operacional e a garantia que os dados não serão perdidos por backups esparsos.
Referências
dm crypt. A device-mapper crypto target. Disponı́vel em www.saout.de/misc/dm-crypt,
acessado em 25-9-2015.
duplicity. Encrypted bandwidth-efficient backup using the rsync algorithm. Disponı́vel
em duplicity.nongnu.org, acessado em 25-9-2015.
GnuPG. The gnu privacy guard. Disponı́vel em www.gnupg.org, acessado em 25-9-2015.
INMETRO (2013).
Portaria 8, de 8 de janeiro de 2013.
Disponı́vel em
http://www.inmetro.gov.br/legislacao/rtac/pdf/RTAC001958.pdf, acessado em 25-92015.
NIST (2010).
Special publication 800-37.
Disponı́vel
http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf,
acessado em 25-9-2015.
em
OpenSSH. Openssh. Disponı́vel em www.openssh.com, acessado em 25-9-2015.
rsync. rsync. Disponı́vel em rsync.samba.org, acessado em 25-9-2015.
xrdp. An open source remote desktop protocol server. Disponı́vel em www.xrdp.org,
acessado em 25-9-2015.