Retalho · SaaS
Um sistema de ponto de venda que reúne vendas, inventário e talões no terminal, no tablet e no telemóvel.
Captura de ecrã, 1908 × 944
Serviços de pentesting para apps, redes e cloud
Apps, APIs, redes e cloud atacadas como faria um atacante real. Cada resultado demonstrado, corrigido e verificado.
Pentests que fazemos
Seis testes em cada camada do seu produto, das pessoas que o usam à rede onde corre.
Engenharia social
Phishing e pretexting contra as pessoas que escolher, com regras acordadas por escrito.
Resultados habituais
Palavras-passe escritas num início de sessão falso, pedidos de MFA aprovados, dados alterados ao telefone.
Apps web e APIs
Início de sessão, sessões, regras de acesso e cada endpoint, atacados de fora e como utilizador com sessão.
Resultados habituais
Dados de outros utilizadores ao mudar um id, injeção, início de sessão falhado, segredos nas respostas.
Apps móveis
A app de iOS e Android, os dados que guarda no telemóvel e a API por trás.
Resultados habituais
Tokens guardados em texto simples, chaves no pacote da app, uma API que confia na app.
Apps de IA e LLM
Os prompts do modelo, os dados a que chega e as ferramentas que pode usar.
Resultados habituais
Injeção de prompts, dados que escapam nas respostas, ferramentas usadas para um atacante.
Segurança da IACloud
Identidades, armazenamento e serviços expostos em AWS, Azure ou Google Cloud.
Resultados habituais
Armazenamento público, funções com mais acesso do que precisam, segredos na configuração.
Redes, externa e interna
Hosts e serviços expostos à internet e, depois, a rede interna a partir de um ponto de apoio lá dentro.
Resultados habituais
Portas de administração abertas, serviços desatualizados, redes planas onde um ponto de apoio chega a tudo.
Caixa preta, cinzenta ou branca
Quanto sabe quem testa antes de começar: desde nada, como um atacante externo, até ao próprio código.
Caixa preta
Testado de fora, sem saber nada.
- Ataca como
- Qualquer pessoa na internet
- Fornece-nos
- O alvo e as regras de intervenção
- Ideal para
- Ver o que qualquer pessoa na internet consegue alcançar e quebrar
Caixa cinzenta
Testado a partir de uma conta, sabendo alguma coisa.
- Ataca como
- Um cliente, parceiro ou colaborador com sessão iniciada
- Fornece-nos
- Contas de utilizador e alguma documentação
- Ideal para
- O que um cliente, um colaborador ou uma conta roubada consegue alcançar
Caixa branca
Testado com o código na mão, sabendo tudo.
- Ataca como
- Alguém de dentro que conhece o código
- Fornece-nos
- O código, a arquitetura e acesso de administração
- Ideal para
- A cobertura mais profunda no menor tempo, antes de um lançamento ou de uma auditoria
O nosso processo de pentesting
Cinco passos, das regras do teste a cada correção verificada. O que cada um demora depende do âmbito; o orçamento fixa as datas.
01Âmbito
Alvos, caixa preta, cinzenta ou branca, a janela de testes e as contas, acordados por escrito.
02Reconhecimento
A superfície de ataque mapeada: cada endpoint, perfil e serviço exposto, analisados primeiro.
03Exploração
Achados explorados manualmente e encadeados, para que cada um mostre o seu impacto real.
04Relatório
Cada achado com a sua gravidade, prova e correção, revistos com a sua equipa.
05Novo teste
As correções testadas de novo, com um relatório atualizado e uma carta de atestação.
01Âmbito
Alvos, caixa preta, cinzenta ou branca, a janela de testes e as contas, acordados por escrito.
02Reconhecimento
A superfície de ataque mapeada: cada endpoint, perfil e serviço exposto, analisados primeiro.
03Exploração
Achados explorados manualmente e encadeados, para que cada um mostre o seu impacto real.
04Relatório
Cada achado com a sua gravidade, prova e correção, revistos com a sua equipa.
05Novo teste
As correções testadas de novo, com um relatório atualizado e uma carta de atestação.
O que recebe
Três coisas no fim de um teste, cada uma por escrito e cada uma sua.
O relatório
Cada resultado com a sua gravidade, a prova de que pode ser explorado e como o corrigir, e um resumo para quem decide.
Correções e verificação
A equipa que encontrou as falhas corrige as que escolher e depois verifica cada correção e fecha-a no relatório.
Uma carta de atestação
Uma carta que diz o que foi testado e quando, para os clientes, parceiros ou auditores que a peçam.
Setores para os quais desenvolvemos software
Desenvolvimento de software à medida para cada setor: web, móvel e IA, construído e auditado em segurança pela mesma equipa.
Também desenvolvemos software para seguros (insurtech), administração pública (govtech), energia e media. Se o seu setor não estiver na lista, também podemos desenvolver software para ele.
Porquê a SafeBlockLab
Um estúdio que ataca o seu software, prova o que encontra, corrige-o e mostra que as correções aguentam.
Provado à mão, não por um scanner.
Os scanners limpam o terreno; depois cada fraqueza é explorada à mão, e o relatório mostra os passos que o conseguiram.
Quem o quebra pode corrigi-lo.
Os engenheiros que encontraram a falha corrigem-na se quiser, sem perder nada ao passar o relatório a outra equipa.
Cada correção, verificada.
Cada correção é atacada outra vez como a falha foi explorada, e fechada no relatório ou marcada como em aberto.
Uma carta que os seus clientes podem ler.
Uma carta de atestação diz o que foi testado e quando, para a mostrar sem partilhar o relatório.
Primeiro, um orçamento por escrito.
Âmbito, regras de intervenção, preço e datas por escrito após uma primeira chamada, antes de qualquer teste.
Um NDA antes de qualquer acesso.
Assina-se antes de vermos uma conta, um documento ou uma linha de código, e o relatório e as suas evidências são seus.
Tecnologias e ferramentas para pentesting
As ferramentas que um teste usa à entrada, antes do trabalho manual que encontra o que elas não veem.
Software que temos em produção
Três produtos próprios, desenvolvidos e testados com o mesmo padrão do trabalho que fazemos para clientes.
Viagens
Uma app de reservas de viagem cujo assistente de IA encontra voos, hotéis e ideias de viagem, até à reserva confirmada.
IA
Silvia AI
Um assistente de IA para apoio ao cliente e vendas, que responde a dúvidas e orienta os compradores.
Captura de ecrã, 1908 × 944
Perguntas sobre pentesting
As que as equipas fazem antes de encomendar um, respondidas sem rodeios.
Quanto custa um pentest?
Depende do que entra no âmbito: uma app web, uma app móvel e a sua API, uma rede, uma conta cloud. Após uma primeira chamada recebe um orçamento por escrito com o âmbito, o preço e as datas, antes de começar qualquer teste.
Quanto tempo demora um pentest?
Depende do âmbito: uma API demora menos do que uma app, a sua API e a cloud por trás. O orçamento fixa as datas, e a janela de testes é acordada antes de começar.
Qual é a diferença entre caixa preta, cinzenta e branca?
A caixa preta começa onde começaria um atacante externo, sem conhecimento interno. A cinzenta começa com uma conta de utilizador e alguma documentação, como um cliente com sessão iniciada. A branca junta o código e a arquitetura, para a cobertura mais profunda.
Em que é que um pentest difere de uma auditoria de segurança?
Uma auditoria de segurança lê o código, a configuração e o design face a uma norma; um pentest ataca o sistema em funcionamento como faria um atacante. Muitas equipas precisam de ambos, e fazemos ambos.
Os testes vão afetar os nossos sistemas em produção?
Os testes correm em staging quando existe, numa janela acordada consigo e com regras de intervenção por escrito. Tudo o que possa tocar a produção é acordado antes, e nada destrutivo corre sem a sua aprovação.
O que precisam de nós?
Autorização por escrito e o âmbito, um contacto durante a janela de testes e, em caixa cinzenta ou branca, as contas, a documentação ou o código que o teste usa. Antes de tudo assina-se um NDA.
O que recebemos no fim?
Um relatório: cada resultado com a sua gravidade, a prova de que pode ser explorado e como o corrigir, e um resumo para quem decide. É seu.
Voltam a testar depois de corrigirmos os resultados?
Sim. Uma nova verificação testa cada correção face ao seu resultado e fecha-a no relatório, ou diz-lhe o que continua em aberto. Se quiser, a equipa que encontrou as falhas corrige-as primeiro.
Podemos receber uma carta para mostrar aos nossos clientes?
Sim. Depois do teste pode ter uma carta de atestação que diz o que foi testado e quando, para clientes, parceiros ou auditores que a peçam.
Testam funcionalidades de IA e LLM?
Sim. Atacamo-las como um utilizador poderia — injeção de prompts, dados que escapam através do modelo, ferramentas que o modelo pode ser levado a chamar — juntamente com a app onde estão.