O que MASVS e MASTG realmente medem

Um pedido recorrente na compra de segurança móvel é uma nota única para um aplicativo: uma letra, um percentual, algo que caiba em um slide. Os padrões móveis da OWASP parecem fornecer exatamente isso, e são frequentemente apresentados como se fornecessem.

Não fornecem, e a distância entre o que medem e o que se supõe que medem é grande o bastante para produzir a decisão errada.

Dois documentos, dois trabalhos

MASVS — Mobile Application Security Verification Standard — é uma lista de requisitos de segurança agrupados em categorias. Descreve o que um aplicativo bem construído deve fazer: criptografar o que armazena, validar o que recebe, resistir à adulteração.

MASTG — Mobile Application Security Testing Guide — é o manual de procedimento. Para cada requisito estabelece como verificá-lo: o que procurar, com qual ferramenta e o que constitui evidência.

O MASVS enuncia o requisito. O MASTG enuncia como a conformidade é demonstrada. Uma auditoria que cita o MASVS sem o MASTG enunciou uma conclusão sem o método que a produziu.

O teste prático dessa distinção é a reprodutibilidade. Um achado registrado como «falha em MASVS-NETWORK» não pode ser verificado por um terceiro. Um achado registrado como «falha em MASVS-NETWORK: networkSecurityConfig permite tráfego em texto claro para api.exemplo.com, observado no manifesto mesclado da build 4.2.1, SHA-256 …» pode ser reproduzido, contestado e confirmado como corrigido.

As oito categorias

O MASVS organiza os requisitos em oito grupos:

O Droidwatch atribui cada achado à sua categoria e produz uma pontuação por categoria de 0 a 100, mais uma nota em letra. As penalizações são ponderadas por severidade: um achado crítico pesa 40 pontos, um alto 25, um médio 10 e um baixo 3. Os informativos não descontam. Indicadores de malware, como correspondências de assinaturas YARA ou padrões de sobreposição de trojan bancário, não pontuam em nenhuma categoria MASVS: pertencem ao veredito de risco.

Vale percorrer a aritmética uma vez, porque ela determina como uma nota deve ser lida. Um achado sozinho deixa sua categoria em 100 menos o seu peso: 60 se for crítico, 75 se for alto, 90 se for médio. Quando uma categoria acumula vários, o mesmo defeito repetido conta uma vez — cinco activities exportadas são um defeito, não cinco — e os defeitos distintos são ordenados do pior para o menor, cada um pesando metade do anterior, de modo que a penalização total nunca passa do dobro do pior achado. Uma categoria com um achado crítico pontua, portanto, 60 (D), e uma com quatro achados médios distintos pontua 81 (B). Não são problemas equivalentes: o primeiro é um defeito grave que provavelmente tem uma única correção, o segundo é um padrão de defeitos menores. A nota os ordena de um jeito; a lista de achados é o que mostra qual das duas situações está em jogo, e por isso a pontuação de categoria fica ao lado da lista de achados e não no lugar dela.

MASVS-RESILIENCE é pontuada de forma diferente das outras sete. Ela mede as proteções que o aplicativo tem, em quatro famílias — integridade da plataforma, antiadulteração, antianálise estática e antianálise dinâmica —, com 0, 40, 65, 85 ou 100 pontos conforme estejam presentes de zero a quatro famílias. Aparece no boletim, mas não entra na nota global, porque corresponde ao perfil R do MASVS, exigível de bancos e pagamentos e não de qualquer aplicativo.

Atenção à direção da escala, porque ela inverte a do outro número do mesmo relatório. A pontuação MASVS vai de 0 a 100 onde mais alto é melhor. A pontuação de risco vai de 0 a 100 onde mais alto é pior. Dois números, mesma faixa, significado oposto — confundi-los em um relatório é um erro frequente e caro.

A limitação que importa

Esta é a frase que deveria acompanhar toda nota MASVS, e que o Droidwatch embute nos próprios dados do boletim e não apenas na interface:

O MASVS mede controles de segurança, não intenções. Um aplicativo malicioso bem construído pode pontuar alto.

Não é uma ressalva por prudência. Decorre diretamente do que o padrão pede. Considere um trojan bancário que fixa seus certificados, criptografa seu banco de dados local com uma chave guardada no Keystore do Android, ofusca as próprias strings e detecta dispositivos com root.

Diante do MASVS esse aplicativo é exemplar. Implementa a segurança de transporte corretamente, trata o armazenamento corretamente e satisfaz os requisitos de resiliência melhor do que a maioria dos aplicativos legítimos, porque seu autor tem um interesse operacional direto em resistir à análise.

O propósito dele é sobrepor-se à tela de acesso de um banco e encaminhar as credenciais interceptadas. O MASVS nunca foi desenhado para notar isso.

O erro inverso também está disponível. Um aplicativo legítimo de banco de varejo que guarda um token de sessão em preferências legíveis por qualquer um e permite tráfego em texto claro para um endpoint de log produzirá um veredito de risco benigno, porque nada nele é hostil. Tampouco é seguro para publicar. Nenhum dos dois números está errado; cada um responde a uma pergunta que não foi feita ao outro.

Onde cada número se encaixa

A consequência prática é que um relatório de segurança móvel precisa dos dois números, usados para perguntas diferentes.

O veredito de risco responde a: este aplicativo é hostil? Apoia-se em sinais de comportamento — capacidade de sobreposição combinada com abuso de acessibilidade, interceptação de SMS, padrões de dropper, infraestrutura de comando e controle — e em reputação e correspondências de regras.

A nota MASVS responde a: este aplicativo é bem construído? É o instrumento correto para um aplicativo próprio que vai ser publicado, ou para um componente de terceiros que entra na cadeia de suprimentos.

Fazer a primeira pergunta a uma nota MASVS produz o trojan descrito acima: malware com nota máxima. Fazer a segunda a um veredito de risco produz um veredito benigno sobre um aplicativo que não deveria passar na revisão.

A ausência de evidência

Há mais uma distinção que muda como um boletim deve ser lido.

Uma categoria sem achados não é uma categoria aprovada. Pode ser uma categoria que nunca foi avaliada, porque a análise correspondente não rodou, porque o aplicativo não exercita aquela superfície, ou porque a evidência necessária fica fora do que o próprio pacote consegue mostrar.

Este último caso é o habitual, e é estrutural, não acidental. MASVS-AUTH pergunta sobre gestão de sessão, boa parte da qual é comportamento de servidor que um pacote não revela, e é a categoria que com mais frequência fica sem avaliar. Uma análise estática de um .ipa — que é tudo o que existe no iOS, ao longo dos seus sete módulos — deixará mais categorias sem avaliar do que uma análise de Android que possa ser acompanhada de instrumentação.

O Droidwatch marca essas categorias como sin_evaluar (não avaliada) em vez de pontuá-las, registra o motivo no próprio dado e informa quantas das oito foram efetivamente avaliadas. Um boletim com seis de oito sem avaliar é um documento diferente de um com oito de oito aprovadas, e confundir os dois é como «fizemos uma avaliação MASVS» vira uma garantia que ninguém verificou.

É o mesmo princípio que rege o restante do relatório: uma ferramenta forense precisa distinguir olhamos e não havia nada de não olhamos.

Como usar isso na prática

Para um aplicativo de terceiros sob suspeita, comece pelo veredito e pelos achados de comportamento. Cite o MASVS onde uma falha de controle concreta sustente o caso: a transmissão de credenciais em texto claro, por exemplo, é ao mesmo tempo uma falha de MASVS-NETWORK e evidência de intenção quando combinada com um endpoint de exfiltração.

Para um aplicativo próprio antes da publicação, comece pelo MASVS. Percorra as categorias de pior pontuação e use os procedimentos MASTG correspondentes para reproduzir cada achado antes de corrigi-lo. Um achado que não se consegue reproduzir é um achado que ninguém pode confirmar como corrigido.

Para uma avaliação de cadeia de suprimentos, leia os dois e trate as categorias sem avaliar como perguntas em aberto, não como aprovações. É o contexto em que mais importa a contagem de categorias avaliadas, porque um componente é frequentemente aceito pela força de um boletim que ninguém leu além da nota.

Para um portão de publicação recorrente, as categorias MASVS são a medida estável e o veredito de risco é o detector de anomalias. As pontuações por categoria de um aplicativo próprio deveriam se mover devagar e de forma previsível; uma queda súbita em MASVS-CODE entre duas builds costuma significar que uma dependência mudou. Automatizar essa comparação é para o que serve um portão de pipeline.

Os dois números aparecem no mesmo relatório, ao lado do mapeamento MITRE ATT&CK Mobile e da evidência por achado. O percurso do relatório explica onde cada um está e como o restante do documento se organiza.

Para ver os dois números sobre um aplicativo real, envie um APK. Não é necessário meio de pagamento.