Os militares dos EUA usam tecnologias anti-adulteração (AT) para evitar que dados sobre sistemas militares críticos sejam adquiridos por adversários. As práticas AT visam evitar a engenharia reversa de componentes de software para exploração. Com a tecnologia AT em vigor, informações militares críticas permanecem em segredo.

Com a disseminação do software nos sistemas de hoje, pode ser assustador para os integradores de sistemas identificar quais componentes de software estão mais precisando ser protegidos pela AT. O software pode vir de uma variedade de fontes: pode ser desenvolvido organicamente, comprado comercialmente, baixado de repositórios de código aberto e até obtido de repositórios controlados pelo governo (que podem ser uma clareira para algumas dessas outras fontes). Neste post no blog, discuto como identificar componentes de software dentro de sistemas que correm o risco de serem explorados e que devem ser protegidos por práticas AT.

O que é anti-adulteração?

A AT é um aspecto de uma abordagem holística para a tecnologia e proteção de programas exigida pelo governo dos EUA e delineada no DoDI 5000.83, lançado em julho de 2020. O AT é definido especificamente no DoDD 5200.47E, da seguinte forma:

As atividades de engenharia de sistemas visavam prevenir ou retardar a exploração de informações críticas do programa (CPI) nos sistemas de defesa dos EUA em configurações domésticas e de exportação para impedir o desenvolvimento de contramedidas, transferência de tecnologia não intencional ou alteração de um sistema devido à engenharia reversa.

As atividades da AT visam impedir ou impedir que um adversário motivado obtenha acesso a informações críticas do programa (CPI) a fim de adquirir conhecimento, controle e a capacidade de explorar um sistema de forma que possa prejudicar os interesses dos EUA. Interesses dos EUA podem ser prejudicados por

  • liberação de dados ou informações classificadas, sensíveis ou proprietárias
  • diminuindo a capacidade
  • mudar para o comportamento pretendido de um sistema de defesa dos EUA

Há uma longa história de adversários em conflitos militares e nos negócios buscando tirar vantagem da superioridade de um concorrente ou encontrar fraquezas exploráveis. Nos EUA, as empresas são protegidas por leis de propriedade intelectual. Mas essa proteção não tem valor em um conflito militar.

Em 1958, houve um exemplo proeminente de uma liberação de informações confidenciais onde um míssil ar-ar AIM-9B Sidewinder atingiu seu alvo, mas não explodiu como planejado e involuntariamente caiu na posse da União Soviética durante a Guerra do Vietnã. foi a introdução pela União Soviética do míssil ar-ar AA-2 (também conhecido como Vympel K-13). Em 1999, Jacques Gansler, que foi então secretário-adjunto de defesa para aquisição e tecnologia, emitiu um memorando exigindo o uso de técnicas AT em programas de aquisição militar. Huber e Scott resumem os benefícios da AT que foram concedidos pelo memorando de Gansler:

  • impede ou mitiga a divulgação não autorizada ou inadvertida da tecnologia dos EUA, bem como sua exploração
  • protege o guerreiro dos EUA contra o desenvolvimento de contramedidas
  • permite a consumação de vendas militares estrangeiras com maior confiança de que as tecnologias dos EUA não serão comprometidas
  • reduz a carga sobre o contribuinte, ajudando a sustentar as vantagens tecnológicas dos EUA

Esse memorando de 1999 foi substituído em 2015 pelo DoDD 5200.47E, que estabelece uma política específica da AT para

  • deter, impedir, detectar e responder à exploração da CPI com base na consequência do compromisso da CPI e da exposição antecipada do sistema através da aplicação de proteções econômicas e baseadas em riscos, para incluir a AT quando justificada, de acordo com o DoDI 5200.39
  • apoiar a venda ou transferência de certos artigos de defesa para governos estrangeiros e seus contratados participantes, preservando os investimentos americanos e estrangeiros em CPI através da implementação da AT, de acordo com o DoDI 5000.02T e o DoDI 5200.39.

Componentes de software e anti-adulteração

A AT, por política, está focada na proteção da CPI, como documentação, requisitos, planos, projetos e implementações (ver Figura 1 abaixo). Essas implementações, impulsionadas por requisitos e projetos, são refletidas em componentes de hardware e software. Esses componentes de software podem vir de uma variedade de fontes. Para essa discussão e simplicidade, esses componentes podem ser caracterizados como sendo itens orgânicos ou não de desenvolvimento (NDI). Um componente de software orgânico é aquele que é criado de forma holística durante o desenvolvimento, integrado, testado e implantado em operação para atender aos requisitos da missão. O NDI também é configurado, integrado, testado e implantado em operação juntamente com os componentes de software orgânico.

image

Figura 1: Formas de componentes

Esta bifurcação ilustra uma diferença fundamental ao pensar no AT: Os componentes de software orgânicos são únicos e não estão prontamente disponíveis fora do sistema no qual esse componente opera. Em outras palavras, o sistema possui exclusivamente componentes orgânicos. Por outro lado, o NDI é obtido a partir de fontes externas (por exemplo, software comercial e de código aberto) e pode ser facilmente acessado por qualquer pessoa e compartilhado dentro do domínio do governo (por exemplo, governo fora da prateleira).

O caso da adulteração do Sidewinder, embora datado, ilustra duas lições importantes que a POLÍTICA AT aborda: O software é uma fonte de CPI para um adversário, e o acesso físico (ou a capacidade de acesso) do software é um vetor de ameaça de adulteração para o desenvolvimento de contramedidas, transferência de tecnologia não intencional ou alteração de um sistema devido à engenharia reversa. Como os soviéticos tinham a posse do míssil, era possível que eles revertessem o software, expondo assim a CPI. Esta CPI foi posteriormente reutilizada, reaproveitada e transferida para o sistema atol AA-2, resultando em uma transferência não intencional de tecnologia.

O conceito de acesso hoje é diferente. Donald Firesmith notou que a AT é um caso especial de posse física. É diferente, pois não é mais necessário ter acesso físico ao software por meio de algum meio de armazenamento físico (por exemplo, firmware, unidade USB, componente de hardware do sistema de armas), pois a posse pode ocorrer através de adulteração remota. A adulteração remota pode vir de qualquer lugar por qualquer agente contraditório motivado e capaz.

Esta ocorrência muito comum ilustra que, embora um sistema de defesa dos EUA esteja em posse exclusiva de componentes de software orgânico, alguns podem conter CPI. Por essa razão, as atividades de engenharia de sistemas devem identificar não apenas quais elementos do sistema são a CPI, mas onde e como essa CPI é implementada e implantada em componentes de software. Essas atividades podem garantir que as técnicas AT sejam usadas para que esses componentes de software detenam, impeçam, detectem e respondam (como indicado no DoDD 5200.47E) ao adversário de adulteração.

Caso de adulteração ilustrado, CPI e Componentes de Software

Considere um serviço de missão, na Figura 2 abaixo, que implemente organicamente uma função de negócios ou missão crítica para um sistema operacional conectado. Esse serviço, uma vez pronto, é implantado em operação (no ) como três peças em um componente de software operacional:MissionServiceAppOps Env

  • MissionServiceApp.jar — a implementação do algoritmo no serviço de missão
  • MissionServiceAppConfig.json — parâmetros insípidos que são usados para controlar o serviço de missão durante o tempo de execução
  • MissionApp.service — um arquivo do sistema usado para controlar automaticamente a inicialização e o desligamento do serviço de missão

image

Figura 2: Aplicativo ilustrado de serviço de missão

Por uma questão de completude, observe que o serviço de missão depende de dois outros componentes de software para operar — o próprio sistema operacional real (por exemplo, RedHat SELinux) e o Java Runtime Environment (JRE), ambos endurecidos e bloqueados de acordo com os mandatos de conformidade. Além disso, há um componente, o repo, que é usado para promover o serviço de missão testado e aprovado do. Para efeitos desta ilustração, qualquer comunicação do repo ao está em uma rede unidirecional (ou seja, diodo unidirecional) e além do escopo dessa discussão.Dev EnvOps EnvOps Env

Observe que existem, no mínimo, duas outras peças do componente de software de serviço de missão:

  • MissionServiceApp.java — Este arquivo de origem contém o serviço de missão real e organicamente desenvolvido escrito no idioma Java. O serviço de missão, nesta forma, não é implantado para o e permanece no .Ops EnvDev Env
  • MissionServiceApp.class — Este arquivo binário contém a forma compilada do serviço de missão que é implantado no , mas apenas como ele está contido dentro do mencionado acima mencionado .Ops EnvMissionServiceApp.jar

As superfícies de ataque de adulteração

A Tabela 1 descreve os componentes do software de serviço de missão em um exemplo ilustrado, examinando os vários vetores de ataque de adulteração potencialmente disponíveis para um adversário, seja através do acesso físico a esses componentes de software ou através de adulteração remota neles. O exemplo considera dois vetores específicos:

  • somente leitura — o agente contraditório é capaz de “ver” os bits em repouso no arquivo ou objeto associado ao serviço de missão. Embora não seja discutida aqui, uma análise mais aprofundada poderia ser aplicada aos bits em movimento (por exemplo, sendo entregue em uma rede ou sendo executada na memória/cache/processador).
  • read-write — O agente adversário é capaz de fazer tudo ao longo do vetor de adulteração somente leitura, mas também é capaz de alterar os bits em repouso no arquivo ou objeto associado ao serviço de missão. (Eu também não discuto bits em movimento aqui).

Dado cada vetor potencial, somente leitura e gravação, as atividades at potenciais são dadas como exemplos do que poderia ser feito para prevenir ou retardar a exploração do componente de software por um adversário usando o deter, impedir, detectar e responder do DoDD 5200.47E. É importante lembrar que o objetivo de uma atividade da AT é negar ao adversário a capacidade de “(desenvolver) o desenvolvimento de contramedidas, (alcançar) transferência de tecnologia não intencional ou (efeito) alteração de um sistema”.

Observe que esta tabela não se destina a uma lista exaustiva de todas as mitigações possíveis ou técnicas AT, que vou cobrir em um futuro post de blog, mas sim uma ilustração de todo o raciocínio de engenharia que é possível ao considerar um plano AT.

image

Tabela 1: Vetor de superfície de adulteração para aplicação de serviço de missão

Dois componentes de software de serviço de missão dependentes não são um foco das atividades AT na Tabela 1 porque esses dois componentes, Red Hat SELinux e o Java Runtime Environment, são NDI (ou seja, comercialmente disponíveis para qualquer pessoa). Como tal, os sistemas de defesa dos EUA que implantam não estão em posse exclusiva desses componentes de software NDI. Um agente contraditório poderia, portanto, simplesmente adquirir esses componentes NDI através de canais comerciais alternativos (ou seja, comprar ou baixar de um mercado de código aberto). Depois que os adversários têm esses componentes, eles são livres para explorar a engenharia reversa e aprender sobre o funcionamento e fraquezas dos componentes do software por meio de testes de penetração visíveis e invisíveis, comumente chamados de atividades de estilo “caixa branca e caixa preta”. Tais atividades são comuns para atores de ameaças que buscam vulnerabilidades de dia zero.MissionServiceApp

Há considerações importantes em relação às NDIs. Enquanto os próprios NDIs estão disponíveis para o público em geral a partir de fontes disponíveis publicamente (por exemplo, mercado comercial, comunidades de código aberto), qualquer arquivo de configuração desenvolvido por um sistema de defesa dos EUA, em proteção desse sistema e em apoio à sua missão, pode ser um alvo de um adversário. Na ilustração da Tabela 1, foi discutido um arquivo de configuração para o componente de software desenvolvido organicamente. É razoável que os arquivos de configuração para NDIs também possam ser desenvolvidos pelo sistema de defesa que devem permanecer como posse exclusiva do sistema de defesa dos EUA. Se assim for, tais artefatos de configuração podem se enquadrar em atividades AT. Para os dois NDIs no sistema na Tabela 1, dois exemplos potenciais de configuração NDI podem serMissionServiceAppConfig.jsonMissionServiceAppMissionServiceApp

  • /etc/shadow: Arquivo dentro do sistema operacional contendo credenciais para informações de contas de usuário, muitas vezes o alvo dos hackers para realizar quebra de senha off-line
  • Java keystore: Tecnologia para armazenar material de chave assimétrica pública e privada, que também é alvo de hackers para análise off-line.

Ameaças e compromissos desses arquivos de configuração (como ) podem causar danos ao sistema de defesa dos EUA que emprega o , resultando em comportamento não intencional do sistema.MissionServiceAppConfig.jsonMissionServiceApp

O que é CPI para o Serviço missionário?

A Tabela 1 explora apenas a superfície de ataque de adulteração do sistema de missão. Ainda é necessário argumentar sobre o que a CPI está sendo empregada ou implementada dentro desses componentes de software desenvolvidos organicamente que o sistema de serviço de missão possui apenas. A equipe de engenharia que realiza essa análise pode fazer uma determinação da CPI usando uma variedade de fontes; principalmente, seriam discussões com especialistas no assunto (SMEs) e comunidade de usuários, bem como uma revisão do Plano de Proteção do Programa (PPP) e possivelmente uma revisão acessória do Guia de Classificação de Segurança (SCG).

São importantes discussões entre ASPAS, comunidades de usuários e engenheiros técnicos sobre um sistema. Os engenheiros técnicos precisam garantir que as capacidades técnicas contraditórias sejam comunicadas a comunidades não técnicas para que os riscos possam ser gerenciados adequadamente.

Para efeitos desta ilustração, as SMEs confirmaram que o algoritmo da missão é a CPI. Além disso, a equipe de engenharia informou as PME do potencial de reverter o algoritmo do arquivo, para o arquivo e, finalmente, para uma forma quase legível humana da implementação original do algoritmo. As SMEs concordaram que essas formas de implantação são CPI e devem ser protegidas por meio de atividades da AT. Ficou claro que um adversário não só poderia copiar a CPI e colocá-la em uso, mas também poderia implementar contramedidas.MissionSystemApp.jar.class.java

A mesma discussão foi realizada sobre o conteúdo do arquivo de configuração de aplicativo de missão, que para este exemplo (não mostrado) elabora sobre um nome de algoritmo, um intervalo para limiares e uma chave de serviço. As SMEs consideraram que muitas dicas e muitas peças de um quebra-cabeça — uma forma de classificação derivada — são evidentes e que esse arquivo também deve ser protegido através de atividades AT. As SMEs concluíram que um adversário, dado os limites configurados para o algoritmo, poderia alterar o comportamento do aplicativo como uma contramedida. No entanto, esses conteúdos não poderiam causar transferência de tecnologia não intencional.MissionServiceAppConfig.json.json

Finalmente, para os demais componentes — o NDI e os dois NDI — a discussão concluiu que esses componentes não devem ser protegidos por meio de atividades AT. Além disso, a equipe de engenharia confirmou que nenhum arquivo de configuração para os NDIs foi modificado (além dos requisitos do Guia de Implementação Técnica de Segurança disponível publicamente (STIG) para o e concluiu que esses componentes não deveriam ser protegidos por meio de atividades AT.MissionApp.serviceMissionServiceApp

Anti-Tamper, Garantia de Software, Gerenciamento de Riscos da Cadeia de Suprimentos, Garantia de Sistemas e Resiliência Cibernética

Para esta ilustração, alguns componentes foram considerados como necessários atividades AT e alguns não. Em ambos os casos, isso não significa que não há mais nada a fazer. O DoDI 5000.83 reconhece com razão que a AT é apenas uma das cinco atividades de engenharia em uma abordagem holística para tecnologia e proteção de programas. Incluído nessa lista ao lado da AT sãoMissionServiceApp

  • garantia de hardware e software
  • gerenciamento de riscos da cadeia de suprimentos
  • garantia do sistema
  • engenharia de sistemas seguros e ciber-resilientes

Há sobreposição entre essas atividades. Por exemplo, na Tabela 1, as colunas Detect and Respond compartilham técnicas com garantia de software que garantem operacionalmente que o que foi implantado em operações seja o mesmo que foi implantado; em outras palavras, que não foi involuntariamente ou inexplicavelmente alterado fora das atividades operacionais e de manutenção. Da mesma forma, se uma detecção de mudanças realmente anormais for acionada, a resposta muitas vezes é a mesma, como restaurar a uma configuração anteriormente conhecida.

A AT é uma camada adicional de defesa para sistemas dos EUA que se destina a impedir o desenvolvimento de contramedidas, transferência de tecnologia não intencional ou alteração de um sistema devido à engenharia reversa se esses sistemas estão em uma configuração doméstica ou de exportação. Mesmo que um componente desses sistemas não se enquadra nas atividades da AT, é uma boa prática aplicar as outras quatro atividades de engenharia de tecnologia e proteção de programas.

O software é difundido em todos os sistemas em operação hoje. Com tanto software vindo de tantas fontes, desenvolvedores de sistemas e adquirentes precisam saber como identificar quais componentes de software em um determinado sistema requerem técnicas AT. Neste post, foquei em um atributo-chave, a posse exclusiva de componentes desenvolvidos organicamente. Para esses componentes, engenheiros, ESM e usuários precisam entender a vantagem que um adversário pode obter ao adquiri-los. Eles também precisam entender as capacidades do adversário para reverter o engenharia desses componentes para mudar seu comportamento ou adquirir uma capacidade técnica que o adversário anteriormente não tinha.

Em um futuro post no blog, entrarei em maiores detalhes sobre o papel das técnicas AT e um plano AT no contexto de um plano global de proteção de programas.

Autor: SCOTT HISSAM

Artigo Original