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 retira 40 pontos da sua categoria, um alto 25, um médio 10 e um baixo 3. Os informativos não descontam.

Vale percorrer a aritmética uma vez, porque ela determina como uma nota deve ser lida. Uma categoria com um achado crítico pontua 60. Uma categoria com quatro achados médios também pontua 60. Não são problemas equivalentes: o primeiro é um defeito único que provavelmente tem uma única correção, o segundo é um padrão. Uma nota comprime essa diferença até apagá-la, e por isso a pontuação de categoria fica ao lado da lista de achados e não no lugar dela.

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 está atrás de uma execução que a análise não teve.

Este último caso é o habitual, e é estrutural, não acidental. MASVS-RESILIENCE pergunta se um aplicativo detecta adulteração e como responde; estabelecer a resposta costuma exigir executá-lo sob um depurador. MASVS-AUTH pergunta sobre gestão de sessão, boa parte da qual é comportamento de servidor que um pacote não revela. 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, 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.