O Uso de Táticas de Segurança em Projetos de Software de Código Aberto

Jungwoo Ryoo, Membro, IEEE, Bryan Malone, Phillip A. Laplante, Fellow, IEEE e Priya Anand

Resumo
Apesar das melhores intenções dos arquitetos de software, geralmente ocorre que os
desenvolvedores individuais não implementam fielmente as decisões de design de segurança
originais. Tal cenário às vezes leva a uma situação em que enquanto um arquiteto reivindica o uso
de uma arquitetura segura na forma de alguma tática, o código-fonte correspondente não apóia a
afirmação. Para preencher essa lacuna, a primeira etapa crítica é verificar se o código-fonte reflete
pelo menos alguns dos recursos estruturais ou comportamentais necessários para uma tática.
Neste estudo, examinamos a extensão dessa discrepância entre a visão de um arquiteto de quais
táticas de segurança precisam ser adotadas no software e a implementação real. Alcançamos esse
objetivo de pesquisa 1) explorando a intenção de um arquiteto de usar táticas de segurança, 2)
verificando se a tática se manifesta no projeto e, finalmente, 3) recuperando a evidência dos
esforços para implementar o projeto no código-fonte. Para evitar limitações de acesso à
documentação e código-fonte, usamos projetos de código aberto para conduzir nossa pesquisa.

Termos para indexação - software de código-fonte aberto, táticas de segurança, arquitetura de

software.

I. INTRODUÇÃO
A segurança de software está se tornando mais importante à medida que o número e a
diversidade de ameaças contra vulnerabilidades de software aumentam. Uma forma de garantir a
segurança do software é adotar contramedidas de segurança desde o início, durante o processo de
desenvolvimento de software. As táticas de segurança estão disponíveis há muito tempo para os
profissionais desde que foram introduzidas. No entanto, muitos profissionais desconhecem as
táticas de segurança e confiam na intuição e no aprendizado informal de colegas para tentar
resolver as preocupações associadas ao aspecto de segurança de seu software.
Portanto, suspeitamos que esta aplicação informal e ad-hoc de princípios e soluções de
segurança para design de software é mais prevalente do que as abordagens sistemáticas baseadas
na adoção de táticas. Como uma etapa inicial para testar nossa hipótese, revisamos a
documentação externa e o código-fonte de 53 projetos de software de código aberto (OSS) que
afirmam utilizar contramedidas de segurança. Não exigimos a menção explícita de táticas de
segurança na documentação externa desses projetos de software de fonte aberta ao selecioná-los
para nossos assuntos de estudo, principalmente por causa de nossa suposição de que os
profissionais estão usando as táticas de segurança implicitamente e alguns dos usos informais e
coincidentes de táticas de segurança será semelhante às práticas mais formais refletidas em uma
hierarquia de táticas de segurança estabelecida.
Acreditamos que nossa pesquisa seja significativa porque estabelece uma linha de base em
termos de compreensão do uso prático das táticas de segurança. Compreender o grau de adoção
de táticas de segurança em termos de consistência, exatidão e integridade estabelece uma base
para responder, em última análise, à questão de pesquisa mais profunda sobre se as táticas de
segurança são realmente eficazes no tratamento de vulnerabilidades de segurança e ameaças que
se aproveitam delas. Portanto, os objetivos de pesquisa imediatos deste trabalho são primeiro
quantificar a extensão do uso de táticas de segurança em projetos de software de fonte aberta e,
em seguida, medir a lacuna entre a reclamação e o uso real no código-fonte.
Para cumprir esses objetivos de pesquisa, desenvolvemos uma metodologia para extrair
artefatos relacionados à segurança do código-fonte, identificamos táticas de segurança entre os
vários artefatos relacionados à segurança extraídos do código-fonte, desenvolvemos um método
para decidir a extensão do uso formal e informal das táticas de segurança na prática e, finalmente,
decidiu-se se as táticas de segurança foram propagadas no código-fonte.

II. TÁTICAS DE SEGURANÇA

As táticas são blocos de construção arquitetônicos porque estabelecem princípios básicos
para uma arquitetura de software. As táticas tratam diretamente de questões de atributos de
qualidade, como disponibilidade, modificabilidade, segurança, desempenho, usabilidade e
testabilidade.
Idealmente, selecionar ou criar uma arquitetura de sistema é o primeiro estágio no
desenvolvimento de software. Estendendo-se além da funcionalidade básica do sistema, as
preocupações com a qualidade ajudam a raciocinar sobre a arquitetura do sistema. O sistema deve
ser desenvolvido com a qualidade em mente desde o início do projeto, e não como uma reflexão
tardia. No entanto, nenhum sistema deve ser desenvolvido para todos os atributos de qualidade,
pois isso seria impraticável porque eles atendem a propósitos diferentes que podem entrar em
conflito uns com os outros. Além disso, esses atributos de qualidade são influenciados uns pelos
outros e, como tal, a modificação de um atributo dificilmente será realizada de forma isolada. Por
exemplo, cada mudança feita para melhorar o atributo de qualidade de segurança frequentemente
degradará o desempenho, pois causa mais sobrecarga no processamento.
Esforços para construir “segurança” como uma qualidade são ineficazes quando sua
existência não pode ser testada. Portanto, o projeto arquitetônico deve começar com a forma
como se pode testar as qualidades que a arquitetura afirma transmitir. Especificamente, para fins
de segurança, os elementos do modelo de teste incluem um estímulo, sua fonte, um ambiente, o
alvo sob ataque, a resposta desejada do sistema e a medida dessa resposta. Um estímulo é o
ataque real ou a tentativa de quebrar a segurança. Secundariamente, um artefato é o serviço ou os
dados em um sistema. O ataque pode ter origem online/offline, dentro/fora da rede ou mesmo se
houver um firewall instalado no ambiente. Uma resposta é então determinada com base no fato de
o usuário ser legítimo ou não, e então as medidas apropriadas são tomadas, usando a aplicação de
uma trilha de auditoria quando necessário. A medida de resposta contende com recuperação e
sobrevivência dependendo da gravidade do ataque.
A segurança de um sistema é definida pelas seguintes características: não repúdio
(garantindo a não negação das mensagens enviadas/recebidas), confidencialidade, integridade,
disponibilidade, etc. Mas a compreensão desses requisitos de segurança de forma alguma implica
que será fácil incorporar os controles correspondentes no design. Nesse sentido, as táticas de
segurança preenchem a lacuna entre os requisitos de segurança e o projeto arquitetônico. As
táticas de segurança incorporam decisões sobre design, que abordam as preocupações
relacionadas aos atributos de qualidade de segurança. Os padrões arquitetônicos podem então
adotar muitas dessas táticas para aprimorar sua segurança. Portanto, projetar uma arquitetura de
sistema seguro envolve a tomada de uma variedade de decisões de segurança relacionadas e, se
qualquer uma dessas decisões mostrar um comportamento repetido, tem potencial para se tornar
uma tática. Especificamente para sistemas de segurança, essas táticas lidam com a resistência,
detecção e recuperação de ataques, conforme mostrado na Figura 1. Em seguida, os avaliadores de
arquiteturas seguras buscarão verificar a presença dessas táticas no código-fonte.
 Figura 1. Hierarquia de Táticas de Segurança

III. PESQUISA RELACIONADA

Conforme discutido na Seção II, há uma série de trabalhos de pesquisa promovendo o uso
de táticas durante o desenvolvimento de software. A maioria das pesquisas existentes
concentra-se em definir claramente o que é uma tática e categorizá-las em uma determinada
hierarquia para facilitar sua adoção. Outro aspecto importante da pesquisa de táticas é especificar
as táticas em várias formas otimizadas para consumo humano e de máquina, bem como minerar
tantas instâncias de táticas quanto possível, o que poderia levar a uma adoção mais ampla de
táticas. Existem também esforços de pesquisa para fornecer metodologias para a adoção de
táticas de forma mais adequada e eficiente em um ciclo de vida de desenvolvimento de software
(SDLC).
Muito pouco foi feito em termos de investigação de como as táticas estão realmente sendo
usadas em sistemas de software da vida real, sem mencionar a avaliação da eficácia de sua adoção.
Portanto, nossa pesquisa é significativa, especialmente no sentido de que fornece um trabalho
seminal que explora o grau de adoção de táticas e fornece um instantâneo significativo do status
quo. Parte das dificuldades associadas a este tipo de pesquisa é que o código-fonte dos projetos de
destino não está prontamente disponível, por isso nos concentramos nos projetos de código
aberto. Além disso, a natureza intensiva e manual do trabalho é outro impedimento para a
pesquisa neste campo. Finalmente, o último desafio que gostaríamos de apontar são as
ambigüidades no uso de termos para táticas, padrões e padrões arquitetônicos. Muitas vezes,
"padrão" é um termo abrangente usado para se referir a táticas e padrões arquitetônicos. Portanto,
é comum encontrar as instâncias de táticas nos repositórios de padrões arquitetônicos. Embora
não seja tão abrangente quanto nosso estudo e não sobre a adoção de táticas, houve uma
tentativa de fornecer mais informações sobre a adoção de padrões de design. Nesse caso, Seen et
al. examinou a adoção de padrões de design em grandes corporações como AT&T, Siemens, etc. e
ofereceu suas recomendações para as melhores práticas de adoção de padrões de design.

4. METODOLOGIA
Este estudo é puramente baseado em observações. Portanto, não há hipótese a provar ou
desaprovar. Em vez disso, desenvolvemos uma métrica para primeiro decidir sobre um melhor
indicador de implementações de contramedidas de segurança no código-fonte (Seção V-A e Seção
V-B). A segunda métrica é usada para medir a extensão do uso de táticas de segurança em projetos
de OSS (Seção V-C).

A. Identificação do alvo de software de código aberto (OSS)

A primeira etapa da metodologia foi identificar aplicativos de software de código aberto
candidatos para nossa análise. As informações do projeto de software foram coletadas de
repositórios de software de código aberto (OSS), em particular SourceForge e GitHub. Esses dois
recursos são os principais provedores de hospedagem de projetos de software de fonte aberta. Um
dos principais critérios para incluir um projeto de software de fonte aberta em nosso estudo foi se
nossa análise de sua documentação externa revelou quaisquer alegações de uso de contramedidas
de segurança. Usando este critério, identificamos 53 projetos de OSS. Nossa esperança era que
algumas dessas declarações documentadas nos levassem a descobrir as implementações reais das
contra-medidas de segurança na forma de táticas no código-fonte.
Para fornecer uma amostra populacional mais aleatória, os recursos do OSS foram
recuperados dos principais downloads de cada semana ao longo de 32 semanas de
http://sourceforge.com e http://github.com durante o período de 1 ° de junho de 2013 até 11 de
janeiro de 2014. Embora muitos dos aplicativos estivessem hospedados em ambos os sites, nem
todos os arquivos de projeto puderam ser encontrados em ambos os sites.

B. Validação de Adoção de Táticas em Implementações de OSS

 Para validar se seu forte foco na segurança na documentação de design é propagado para
o código-fonte, processamos o código-fonte OSS candidato com Structure 101 Studio, FileSeek e
7-Zip para extrair os detalhes da classe. O recurso de pesquisa na Estrutura 101 foi utilizado para
pesquisar palavras-chave específicas relacionadas à segurança, como "senha", conforme mostrado
na Tabela I.

TABELA I
AMOSTRA DE TERMOS DE BUSCA

Algumas das palavras-chave de segurança foram emprestadas diretamente da hierarquia

de táticas existente. Por exemplo, palavras-chave como “autenticar” e “autorizar” correspondem
diretamente às táticas de segurança propostas por Bass et al. Outras palavras-chave como X.509 e
VPN derivam das táticas de segurança. Por exemplo, tanto o X.509 (um padrão de certificado
digital) quanto a Rede Privada Virtual (VPN: padrão de comunicação de rede segura) são protocolos
de segurança usados ​em aplicativos de rede. Eles estão fortemente relacionados às seguintes
táticas: identificar atores, autenticar atores, limitar o acesso e criptografar dados.
 Quando há variações na palavra-chave (por exemplo, MD4, MD5, MD6, etc.), a parte
invariável da palavra-chave (ou seja, MD) foi usada para as pesquisas. As palavras-chave que
começam com hífens indicam que são variações da palavra-chave sem os hifens diretamente acima
delas.
Asseguramos que as palavras-chave de segurança que identificamos tenham
mapeamentos explícitos para a hierarquia de táticas na Fig. 1 criando uma matriz mostrada na
Tabela II. Observe que estamos mostrando apenas a parte superior da matriz devido ao limite de
espaço.
TABELA II
MAPEAMENTO DE PALAVRAS-CHAVE DE SEGURANÇA E TÁTICAS

Nossas pesquisas visavam nomes de arquivos, nomes de classes e a documentação interna

do código-fonte. Quando vários arquivos de código-fonte foram arquivados em um único arquivo,
como um arquivo .jar, usamos FileSeek e 7-Zip para extrair arquivos individuais. O Structure 101
oferece extração de preservação de comportamento na forma de diagramas de classe, colaboração
e dependência. Portanto, uma vez identificados os termos de segurança, uma avaliação mais
aprofundada dos pacotes e classes foi realizada na tentativa de determinar as interações das
classes. Por exemplo, a Fig. 2 mostra um pacote com os detalhes de uma classe de credencial
contendo os recursos criptográficos e MD5 do lado esquerdo da janela e os colaboradores, java e
javax, do lado direito da janela. A parte inferior da tela mostra a quebra de dependência e o uso da
estrutura rg.mortbay.jetty.security e suas classes constituintes. Além disso, como os arquivos
geralmente indicam uma estrutura em termos de classes, a visualização das categorias e das
interações de classe expõe detalhes adicionais sobre a estrutura do sistema. Essa revisão e
avaliação manual e aprofundada do código-fonte nos permitiu concluir se algum dos recursos de
segurança reivindicados foi implementado. Medir o grau de implementação (por exemplo, total ou
parcialmente) estava fora do escopo deste artigo.

Figura 2. Visão geral da divisão da dependência da interface do aplicativo da estrutura 101.

V. RESULTADOS
Esta seção descreve todas as principais descobertas de nosso estudo. Primeiro
apresentamos nossos resultados de análise de "ameaças à validade" com relação ao nosso método
de pesquisa de nome de arquivo usado para localizar artefatos de segurança, como arquivos
relevantes para a segurança, classes e seus relacionamentos.

A. Análise de ameaças à validade

Uma das ameaças à validade é que as pesquisas de nome de arquivo usando as
palavras-chave de segurança nem sempre levam à descoberta do código de segurança. Por
exemplo, 17 dos 53 projetos de software de fonte aberta (34%) que estudamos não revelaram
nenhum código de segurança quando seus nomes de arquivo indicaram o uso de contramedidas de
segurança. O contrário também é verdade. É possível que arquivos sem associação aparente com
contramedidas de segurança em seus nomes contenham código de segurança. A Fig. 3 mostra a
proporção do número real de classes de segurança reveladas após inspeções adicionais e o número
total de classes inspecionadas como resultado de correspondências de palavras-chave de
segurança nas pesquisas que conduzimos neste estudo. Usamos essa métrica (ou seja, a proporção)
para medir a eficácia dos nomes dos arquivos e suas alternativas como indicadores de
implementações de contramedidas de segurança. Portanto, a métrica pode ser formalmente
denotada como:

Ei = (Is / Ik)
onde Ei representa a eficácia de um indicador, e Is e Ik representa o número de correspondências

de palavras-chave que realmente levam ao código de contramedida de segurança e o número de

correspondências de palavras-chave, respectivamente, ao usar o indicador. Outra ameaça à
validade reside na natureza manual de nossas revisões de código, que podem estar sujeitas a erros.

Figura 3. Nomes de arquivos que levam ao código de segurança.

B. Resultados e análise da pesquisa

1) Adoção de contramedidas de segurança no Código: Conforme discutido na Seção IV, conduzimos

pesquisas de palavras-chave de segurança para localizar as áreas do código-fonte, contendo a
evidência de implementações de contramedidas de segurança. Depois de considerar as ameaças à
validade devido aos nomes de arquivo enganosos, decidimos usar nomes de classe para nossas
pesquisas de palavras-chave de segurança. Portanto, o indicador que usamos neste estudo são os
nomes das classes. Tivemos que reduzir o tamanho da nossa amostra para 33 para remover
outliers que tinham muitas ou poucas correspondências de palavras-chave devido à natureza mais
trabalhosa das pesquisas de nome de classe. Em nossa amostra reduzida, 27 dos 33 projetos
estudados (81,9%) tiveram classes com intenção de segurança. Para esta amostra reduzida,
verifica-se um aumento da confiança com tendência central (média) de aumentar de 4,41% para
10,5% (Fig. 4), proporcionando assim um melhor reflexo das classes de segurança encontradas no
conteúdo sobre a recuperação do nome do arquivo.

Figura 4. Classes de segurança para classes totais.

Com base nesse resultado, podemos concluir que a maioria dos projetos de OSS (81,8%)
analisados ​neste estudo têm classes implementando contramedidas de segurança conforme
afirmam em sua documentação externa. No entanto, a questão restante é quantas dessas classes
implementam táticas de segurança e outras formas de conceitos de design de segurança, como
padrões de segurança. Outra questão de pesquisa importante é como essas táticas e padrões de
segurança são usados ​nos projetos de software de fonte aberta. Por exemplo, a distribuição da
adoção de táticas e padrões de segurança conhecidos pode fornecer alguns insights úteis. Neste
artigo, focalizamos a investigação da primeira questão de pesquisa.

C. Adoção de táticas de segurança no Código

 A Tabela III e a Fig. 5 mostram a distribuição das classes de segurança na população de
amostra do total de 9.811 classes que descobrimos por meio das pesquisas de palavras-chave como
parte deste estudo. Discutimos cada entrada da Tabela III no restante desta seção.

TABELA III
DISTRIBUIÇÃO DE CLASSE DE SEGURANÇA POR CATEGORIA TÁTICA
 Figura 5. Porcentagem do total de classes por classificação.

1) Autenticar: a autenticação garante que o usuário seja quem afirma ser. Do ponto de vista das
táticas de segurança, a autenticação parece ser um padrão para muitos dos aplicativos para
usuários que realizam identificação digital ao interagir com a rede e os recursos do sistema. Os
certificados, que são semelhantes à autenticação, usam criptografia assimétrica para identificar e
verificar se o remetente da mensagem (e não o destinatário) é quem afirma ser e, a esse respeito,
são como um passaporte. Os tokens também podem representar uma forma de entrada certificada
ou código de identificação exclusivo usado para confirmar que uma sessão, pacote ou mensagem é
factual. Os certificados são assinados digitalmente e visam fornecer não-repúdio. Um exemplo é
encontrado no uso de uma Autoridade de Certificação (CA) que emite um certificado digital que
contém uma chave pública. A medida de classes significa que há uso substancial de táticas de
segurança para identificação de usuários, certificados e tokens, pois reflete 13,7% do total de
classes na amostra populacional (Tabela III). Esta categoria está ligada especificamente à busca por
atores de autenticação, identificando funções, grupos e privilégios em táticas de resistência a
ataques.

2) Autorizar: a autorização concede aos usuários acesso aos recursos e recursos do sistema. Da
Tabela III, há 0,7% das classes controlando os direitos de acesso dos usuários. Este é um número
aparentemente pequeno, dada a natureza da tarefa. Esta categoria está ligada especificamente à
busca por atores autorizados, identificando seus papéis, grupos e privilégios na categoria de
táticas de resistência a ataques. A categoria auth foi usada para classes que desafiam uma divisão
clara entre autenticação e autorização. No entanto, o uso de auth representa 1,7% do total de
classes da amostra populacional. Embora o uso combinado das táticas de autenticação e
autorização pareça ter interações relacionadas, há uma diferença substancial na implementação
dessas táticas de segurança. Não há vínculo direto com uma categoria tática a não ser em função
das táticas de resistência.
TABELA IV
EXEMPLO DE RESULTADOS DE PESQUISA DE CLASSE DE PALAVRAS-CHAVE DE SEGURANÇA

3) Transporte: O transporte de pacotes de dados, frequentemente chamados de datagramas, entre

canais requer alguma forma de proteção, pois não existe um método para garantir a entrega livre
de erros desses pacotes. Os recursos de transporte garantem a entrega de mensagens para os
principais aplicativos, como aplicativos da web, mensagens instantâneas e soluções de voz sobre IP
(VoIP), usando serviços de datagrama como método de entrega de backbone. A categoria de
transporte contém apenas 3,5% do total de classes na amostra da população. Esta categoria está
ligada especificamente à busca pela tática de “identificar atores” na categoria de táticas de
resistência a ataques, uma vez que requer os endereços de origem e destino para a transmissão de
pacotes.

4) Conexão: as conexões são uma garantia entre dois dispositivos ou nós na rede. As conexões ou
soquetes e proxies se enquadram na categoria de garantia de transmissão de dados livre de erros.
Para verificar a conexão entre dois nós, os certificados emitidos pela VeriSign, Symantec, GoDaddy
e outros continuam aumentando como um meio de garantir que a conexão não seja apenas
confiável, mas também validada, especialmente em termos de integridade da mensagem. Uso de
conexões foi a quarta classe mais numerosa no estudo, contendo 12,0% do total de classes da
amostra populacional. Esta categoria está especificamente ligada à busca pela tática de
“criptografar dados” na categoria de táticas de resistência a ataques. Além disso, essa categoria de
classe exige a adição de uma nova categoria de tática, que é “verificar integridade”, que é um
recurso de segurança crucial ainda não documentado nas hierarquias de táticas existentes.

5) Padrões de criptografia: os padrões de criptografia buscam fornecer uma base para definir o uso
dos padrões necessários para garantir que a criptografia funcione por meio de criptografia de
dados consistente. Na Tabela III, “padrões” referem-se às funções hash criptográficas usadas para
verificar a integridade dos dados. Os padrões em criptografia produziram 0,5% do total de classes
na amostra populacional. Esta categoria está ligada especificamente à busca pela tática de “dados
criptografados” em táticas de resistência a ataques.

6) Criptografar: “Criptografia” é, no entanto, identificada como criptografia, mas abrange a

descriptografia e várias cifras cujos algoritmos são usados ​para fazer a criptografia funcionar.
Embora os padrões não produzam muito em termos da população amostral, o uso da criptografia
em si é bastante substancial em sua representação na população amostral. A criptografia
representa o maior componente nas classes de segurança com 32,8% do total de classes na
amostra populacional. Esta categoria está especificamente ligada à busca pela tática de
“criptografar dados” na categoria de táticas de resistência a ataques.

7) Codificar: O objetivo da codificação é representar os dados, mensagem ou pacote de alguma

forma a ser consumido por um receptor na transferência de dados. O objetivo da decodificação é
remover o esquema de codificação. A Codificação costuma ser confundida com criptografia, por
isso decidimos ainda adicionar essa palavra-chave à nossa pesquisa. Durante a compilação dos
resultados da pesquisa, prefixos-chave como “código”, “codificar” e “decodificar” foram
combinados, pois os nomes das classes não deixam claro o que as classes realmente continham.
Codificar foi o terceiro maior componente nos achados com 12,7% do total de classes da amostra
populacional. Essa categoria está relacionada especificamente à busca pela tática de “criptografar
dados” na categoria de táticas de resistência a ataques.

8) Protocolo: os protocolos estabelecem regras de “comportamento” para mensagens e buscam

definir princípios de conexão de sessão, padrões de rede, conformidade de modelo de referência,
garantia de entrega de túnel e muito mais. Os protocolos fornecem a essência da estrutura para o
handshake entre clientes e servidores e para transmissão de dados, conexão e interação entre os
clientes e servidores, seja por meio da entrega de conteúdo da camada de aplicativo ou outras
camadas de rede. Os protocolos refletiram 10,2% do total de classes da amostra populacional. Esta
categoria está vinculada especificamente à busca pela tática de “identificar atores” na categoria de
táticas de resistência a ataques, uma vez que envolve a identificação das partes envolvidas,
especialmente no contexto de segurança.

9) Escalonamento de privilégios: o escalonamento de privilégios é uma vulnerabilidade que

concede direitos de acesso em um nível mais alto do que o atribuído ao usuário ao ser autorizado.
Embora essa designação representasse uma porcentagem relativamente baixa das descobertas
gerais, Escalation of Privilege realmente apareceu como classes no aplicativo Zocalo
(http://zocalo.sourceforge.net/javadoc/) e é mais detalhada na documentação de design e
implementação em seu site como um meio de evitar o aumento de privilégios. Os padrões em
geral parecem refletir um nível mais alto de classes que representam esta categoria. Embora as
contramedidas de escalonamento de privilégios reflitam a presença relativamente baixa de
medidas de segurança, os ataques de escalonamento de privilégios são bem conhecidos e podem
ter implicações de longo alcance para qualquer diretiva de pesquisa futura relacionada a táticas de
segurança. A escalada de privilégio refletiu 0,1% do total de classes na amostra populacional. As
classes nesta categoria estão especificamente ligadas à busca pela tática de “atores autorizados”
na categoria de táticas de resistência a ataques.

10) Solicitação de comentários (RFC): Este conjunto de classes pertence a todos os métodos,
comportamentos, inovações e pesquisas que se aplicam à Internet e aos sistemas de rede,
incluindo contramedidas de segurança. RFCs são gerenciados pela Internet Engineering Task Force
(IETF). A pesquisa sobre RFCs demonstra uma ênfase limitada de design na população da amostra.
Por exemplo, as definições de classe específicas para RFC 6101 abordam características de rede no
uso de padrões Secure Socket Layer (SSL). As RFCs representaram 0,4% do total de classes. Embora
constituam uma porcentagem consideravelmente baixa do total de classes, os RFCs são usados
​para todos os aspectos das implementações de segurança em sistemas baseados na Internet ou
em rede. Esta categoria tem vários vínculos com as classificações de táticas de segurança, e a
implementação de classe de uma RFC que encontramos estava ligada às táticas de “identificar”,
“autenticar”, “autorizar” e “criptografar”.
11) Sandbox: Sandbox é uma medida de segurança criada no desenvolvimento Java, que contém um
conjunto de regras usadas para evitar que os applets executem muitas atividades indesejáveis
​diferentes, como acessar certos recursos designados. Um miniaplicativo Java é incorporado à
página da web, e a segurança Java depende do verificador de código de byte, carregador de classes
e gerenciador de segurança para restringir o acesso ao sistema de arquivos, acesso à rede e acesso
aos recursos internos do navegador. Três aplicativos usam o conceito Sandbox: Java Sandbox,
Chromium e JOSSO. As sandboxes representaram 0,5% do total de classes da amostra
populacional. Esta categoria está ligada especificamente à busca da “tática de acesso limitado” na
categoria de táticas de resistência a ataques.

12) Segurança: Segurança é um termo abrangente e autodefinido. As medidas de segurança

procuram definir quem ou o que pode ter acesso aos recursos do sistema. O prefixo “secur” e o
termo segurança produzem contribuições marginalmente significativas, mas requerem exploração
adicional. Pesquisas futuras no uso de segurança precisam de esclarecimento. A segurança
representou 3,6% do total de classes da amostra populacional. Esta categoria não tem vínculo com
a busca de qualquer tática de segurança específica, pois pode detectar, resistir, reagir ou se
recuperar de ataques.

13) Single Sign-On: Outra revelação significativa refletindo medidas relativamente baixas de
segurança e uma fraqueza conhecida é encontrada no uso de Single Sign-On (SSO). Pesquisas
adicionais neste domínio podem render uma contribuição significativa. Os SSOs perguntam a um
autenticador se existe algum SSO para uma determinada solicitação. No caso de autenticação
bem-sucedida, as credenciais são retornadas. O Single Sign-On representou 0,2% do total de
classes na amostra populacional. Esta categoria depende especificamente da busca pela tática de
“autenticar atores” na categoria de táticas de resistência a ataques.

14) Padrões: os padrões de segurança ou “estabelecer padrões de segurança” devem ser

considerados como outra tática candidata. Os padrões que tratam das políticas de segurança são
requisitos obrigatórios com base em um consenso da comunidade para proteger o sistema contra
ameaças ou vulnerabilidades. Os esquemas de representação de caracteres podem ser
substancialmente mais complexos com padrões de segurança adicionais se os usuários buscarem
explorar qualquer vulnerabilidade quando se espera que se comportem de maneira benigna. Em
última análise, a conformidade uniforme com os padrões de segurança bloqueia as oportunidades
de interromper processos e procedimentos intencionalmente. Embora significativamente mais
difíceis de rastrear, os padrões compreenderam 7,2% do total de classes na amostra populacional.
Esta categoria não tem vínculos específicos com as classificações de táticas de segurança
existentes.

15) Monitoramento de rede: esta classificação dentro de nossa taxonomia é o conjunto de classes
que são responsáveis ​pelo registro e monitoramento. Por exemplo, o esquema de monitoramento
de rede poderia ser o Protocolo Simples de Gerenciamento de Rede (SNMP), que realiza avaliações
de rede e determina quais atividades estão ocorrendo enquanto fornece soluções baseadas em
serviços para usuários finais. O SNMP também é conhecido por adicionar sobrecarga desnecessária
à rede, mas é necessário para solucionar problemas de rede situacionais. Esses problemas podem
consistir em dispositivos de rede com defeito, etc. Em geral, SNMP não foi utilizado em um nível
que sugerisse significância e é usado normalmente como a primeira palavra-chave como um
determinante para a direção de classificação para a qual as classes serão colocadas. Apenas dois
aplicativos usaram a categoria de monitoramento de rede: JOSSO e MingW. O monitoramento da
rede representou 0,1% do total de classes da amostra populacional. Esta categoria tem ligações
diretas com as táticas de “manutenção da trilha de auditoria”.

Embora não sejam completas, muitas das descobertas na categoria de pesquisa de nome
de classe (Tabela III) podem ser associadas à tática de “criptografar dados” para a categoria de
táticas de resistência a ataques. Quatro das dezesseis classificações refletiram o uso de dados
criptografados resistindo a ataques, correspondendo a 25,0% do total de resultados da
classificação. Essa revelação aponta para uma forte ênfase no uso de dados criptografados para a
categoria de táticas de “resistir a ataques”. Além disso, na análise dos termos de busca definidos,
25 de 60 continham soluções de criptografia junto com outros dois endereçando padrões
criptográficos, perfazendo assim 41,67% dos termos de busca. A criptografia não é uma solução
abrangente para o problema de segurança e esse foco na criptografia indica uma grande lacuna na
adoção atual de táticas de segurança no software de fonte aberta.

VI. ESTUDO DE CASO

Para demonstrar como nossa metodologia proposta funciona mais claramente,
fornecemos um estudo de caso nesta seção. O projeto de código aberto que selecionamos para
este estudo de caso é SPNEGO: http://spnego.sourceforge.net/, que fornece uma biblioteca
alternativa para servidores de aplicativos usarem para autenticar seus clientes. O SPNEGO afirma
claramente em seu documento de design que aborda as táticas de Autenticação de Atores e
Autorização de Atores, cuja implementação tem um total de 11 classes. Com base na
documentação do projeto SPNEGO, listamos seus nomes de classes e suas funções pretendidas na
Tabela V.
TABELA IV
NOMES DE CLASSE SPNEGO E SUAS FUNÇÕES

Inspecionamos manualmente o código-fonte do SPNEGO para verificar se cada classe

realmente implementou a tática de segurança cujo uso foi reivindicado na documentação do
projeto. A Tabela VI resume o resultado de nossa inspeção manual.

TABELA VI
IMPLEMENTAÇÃO DE PALAVRAS-CHAVE E TÁTICAS DE SEGURANÇA
 Este estudo de caso demonstra claramente como identificamos a extensão do uso de
táticas de segurança em um projeto de código aberto. Embora alguns nomes de classes impliquem
o uso de táticas de segurança neles, apenas quatro das sete classes realmente implementam as
táticas. Esta proporção das classes de segurança para o total de classes para o projeto SPNEGO é
refletida na Fig. 4. Este estudo de caso também ajuda a reforçar nossa crença de que as táticas de
segurança não são completamente implementadas como sugeridas em seus nomes de classe ou
como pretendido durante a fase de design .

VII. CONCLUSÃO
Neste artigo, investigamos o grau de adoção de táticas de segurança nos projetos de
software de fonte aberta. Conduzimos nossa investigação nos níveis de design e implementação.
Os resultados são mistos. Embora a maioria dos projetos de software de fonte aberta adotem
táticas de segurança tanto no design quanto na implementação, o escopo da adoção foi bastante
limitado. Ou seja, a adoção focou apenas em um determinado conjunto de táticas, como
“criptografar dados” na hierarquia de táticas. Outras táticas raramente eram usadas ou nem eram
usadas. Isso representa uma oportunidade para a comunidade OSS explorar outras táticas de
segurança menos usadas e considerá-las para adoção. Acreditamos que essa adoção
desequilibrada de táticas de segurança se deve principalmente à falta de conhecimento em táticas
de segurança, ao invés de evitar intencionalmente o uso de certas táticas de segurança.
Também percebemos que existem vários candidatos a táticas de segurança que podem ser
incorporados à hierarquia de táticas existente. As táticas de segurança que os candidatos
descobriram durante nossa busca por evidências de contramedidas de segurança no código-fonte
são especialmente valiosas porque são elas que estão sendo usadas pelos profissionais. Outra
razão para sua importância é que a formação da hierarquia de táticas também é parcialmente
dependente desse processo comunitário de propor táticas de segurança e adotá-las pelos
praticantes. Portanto, pesquisas futuras devem identificar mais táticas de segurança candidatas
usadas na prática e encontrar maneiras de incorporá-las sistematicamente na hierarquia de táticas
de segurança existentes. Pesquisas adicionais também são necessárias para avaliar a eficácia das
táticas de segurança recém-descobertas quando elas são incorporadas a uma hierarquia de táticas.
 TABELA VII
PROJETOS E BREVES DESCRIÇÕES