Trabalhos anonimizados, resultados reais

Contexto: Um parceiro bancário exigiu um teste de intrusão independente como condição para o arranque. A plataforma tinha sido construída rapidamente por uma pequena equipa interna e nunca fora avaliada por ninguém de fora, faltando cerca de seis semanas para a data de lançamento.

Âmbito: Testes autenticados da aplicação web e da respetiva API REST em todos os quatro perfis de utilizador, mais uma revisão do modelo de autorização subjacente. Fixado no contrato assinado: um ambiente de pré-produção espelhado com o mesmo código de controlo de acessos, sem testes sobre registos reais de clientes e sem negação de serviço.

O que encontrámos: A questão principal era de autorização ao nível do objeto: uma conta empresarial autenticada conseguia ler o histórico de transações de outra organização bastando alterar um identificador num pedido à API. A par disso, duas questões de severidade média na gestão de sessão e uma fuga de informação de baixa severidade nas mensagens de erro.

Resultado: A questão crítica foi corrigida em poucos dias e verificada num reteste gratuito antes do lançamento. A revisão de segurança do parceiro passou à primeira e a plataforma entrou em produção na data original. A equipa agenda agora uma avaliação antes de cada versão importante.

Trabalho: Nove dias de testes · relatório técnico e resumo para a administração · reteste incluído.

Contexto: As encomendas fraudulentas e as suspeitas de apropriação de contas aumentaram acentuadamente à entrada de um pico sazonal. O apoio ao cliente absorvia os estornos e ninguém conseguia dizer se a causa eram palavras-passe de clientes divulgadas noutros sites, uma falha na loja, ou ambas.

Âmbito: Autenticação, gestão de sessão e lógica de checkout na loja, resistência ao teste massivo de credenciais e o fluxo de recuperação de conta. Em separado, e com os colaboradores informados previamente, uma sessão de sensibilização contra phishing para toda a empresa.

O que encontrámos: Nem o início de sessão nem a reposição de palavra-passe tinham limitação de tentativas, o que tornava barato para um atacante testar credenciais em grande escala. Os identificadores de sessão não eram renovados após a autenticação e uma falha no checkout permitia acumular códigos de desconto para além do limite previsto.

Resultado: A limitação de tentativas, a renovação de sessão e a correção do checkout entraram em produção nas duas semanas seguintes e o abuso automatizado do início de sessão caiu de forma acentuada. Depois da sessão de sensibilização, os colaboradores passaram a comunicar o email suspeito em vez de o apagarem em silêncio, que é a mudança que mais conta.

Trabalho: Sete dias de testes · meio dia de formação · reteste incluído.

Contexto: Clientes empresariais tinham começado a exigir prova de testes de segurança independentes antes de assinar. Dois negócios estavam parados na revisão de segurança do departamento de compras e os fundadores respondiam manualmente ao mesmo questionário de cada vez.

Âmbito: Um teste de intrusão pontual da aplicação multi-inquilino, centrado no isolamento entre clientes e no modelo de permissões, mais uma auditoria leve de configuração cloud sobre identidade, armazenamento e registo de eventos, face aos CIS Benchmarks.

O que encontrámos: O isolamento entre inquilinos aguentou testes prolongados, que era a resposta de que os fundadores mais precisavam. As questões reais estavam na conta cloud: um perfil de serviço com permissões muito além do necessário, um contentor de armazenamento legível por qualquer utilizador autenticado da conta e o registo de auditoria desligado numa das regiões.

Resultado: A empresa tem agora um relatório que pode partilhar sob acordo de confidencialidade, além de um registo de correções que mostra o que foi resolvido e quando. As revisões de segurança que demoravam semanas fecham em dias, e a mesma evidência alimentou diretamente a preparação para a ISO 27001.

Trabalho: Seis dias de testes · relatório partilhável · reteste anual.

Contexto: Um portal de rastreio para clientes e um conjunto de integrações de parceiros tinham-se acumulado ao longo de vários anos, construídos por equipas e fornecedores diferentes. Ninguém tinha um inventário completo do que estava exposto à internet e nada tinha sido testado de forma independente.

Âmbito: O perímetro de rede externo, o próprio portal de rastreio e uma revisão dos acessos das APIs partilhadas com os parceiros de distribuição. Onde a infraestrutura estava alojada num fornecedor terceiro, confirmámos a autorização deste por escrito antes de começar.

O que encontrámos: Uma cópia de testes esquecida do portal estava acessível a partir da internet, com um componente desatualizado e uma base de dados de teste muito semelhante à real. Uma chave de API de parceiro tinha muito mais acessos do que essa integração alguma vez usou, e várias interfaces de administração aceitavam ligações de qualquer endereço.

Resultado: A instância de testes foi desativada, as chaves de parceiros foram reduzidas ao necessário e rodadas, e o acesso de administração passou para trás da VPN corporativa. O exercício produziu também o inventário de ativos que faltava à equipa de operações.

Trabalho: Oito dias de testes · rede externa e web · reteste incluído.

Contexto: Uma plataforma que trata registos de doentes para um grupo de clínicas privadas precisava de demonstrar aos seus clientes que o acesso a dados de saúde estava devidamente controlado — uma pergunta que os próprios utentes faziam com precisão crescente.

Âmbito: Controlo de acessos por perfil entre contas clínicas, administrativas e de apoio, o registo de auditoria do acesso a registos, e as funcionalidades de exportação e relatórios. Os testes decorreram inteiramente sobre um conjunto de doentes sintéticos; nenhum dado de saúde real foi acedido em momento algum, o que ficou escrito no âmbito antes de começarmos.

O que encontrámos: O controlo de acessos entre clínicas estava sólido. As lacunas eram mais estreitas e concretas: um perfil de apoio conseguia ver registos fora dos casos que lhe estavam atribuídos, as exportações não ficavam no registo de auditoria e um ponto de acesso de relatórios devolvia mais campos do que a interface mostrava.

Resultado: O perfil de apoio foi restringido, as exportações passaram a gerar entradas de auditoria e o ponto de acesso de relatórios devolve apenas o necessário. O cliente usa o relatório como evidência no seu próprio dossiê de responsabilidade RGPD.

Trabalho: Sete dias de testes · apenas dados sintéticos · reteste incluído.