Testes ofensivos em sistemas de saúde e financeiros devem simular ataques reais sem colocar pacientes, transações ou dados sensíveis em risco. Para isso, a operação precisa combinar escopo autorizado, regras de engajamento, modelagem de ameaças, controles de segurança operacional e evidências reproduzíveis — não apenas executar scanners ou procurar vulnerabilidades isoladas.
Red team, pentest e varredura não são a mesma coisa
A escolha do tipo de avaliação define profundidade, risco operacional e resultado esperado.
- Varredura de vulnerabilidades: identifica versões desatualizadas, configurações inseguras e falhas conhecidas. É rápida e repetível, mas produz falsos positivos e não comprova impacto.
- Pentest: testa um escopo delimitado, como uma aplicação web, API, aplicativo móvel ou rede. O objetivo é encontrar e explorar vulnerabilidades de maneira controlada.
- Red team: avalia se pessoas, processos e tecnologias conseguem detectar e conter um ataque orientado por objetivos. Pode envolver aplicação, nuvem, identidade, engenharia social e movimentação lateral.
- Purple team: promove colaboração direta entre ofensiva e defesa. Cada técnica executada é comparada com logs, alertas e capacidade de resposta.
Em aplicações críticas, começar por pentest e purple team costuma ser mais seguro do que iniciar com uma operação ampla de red team. O red team faz sentido quando a organização já possui inventário de ativos, monitoramento, responsáveis por incidentes e capacidade de interromper o exercício.
Por que saúde e finanças exigem regras específicas
Os dois setores concentram dados valiosos e processos com baixa tolerância a indisponibilidade. Contudo, o impacto técnico assume formas diferentes.
Riscos em sistemas de saúde
Uma exploração pode afetar prontuários, prescrições, resultados laboratoriais, agendas, integrações hospitalares e dispositivos conectados. Além da confidencialidade, é necessário proteger a integridade clínica: alterar um identificador, unidade de medida ou associação entre paciente e exame pode ser mais perigoso do que simplesmente visualizar um registro.
Integrações HL7 v2 e FHIR merecem atenção especial. Os testes devem verificar, entre outros pontos:
- autenticação e autorização por sistema, usuário e contexto;
- validação de mensagens HL7 e recursos FHIR;
- acesso indevido por troca de identificadores;
- exposição excessiva em endpoints de busca;
- separação entre dados assistenciais, administrativos e financeiros;
- rastreabilidade de leitura, alteração e exportação;
- proteção de segredos usados por mecanismos de integração;
- comportamento diante de mensagens duplicadas, atrasadas ou fora de ordem.
O teste não deve criar pacientes fictícios em produção sem autorização, alterar informações clínicas reais nem disparar fluxos de medicação, faturamento ou atendimento.
Riscos em sistemas financeiros
Aplicações financeiras precisam preservar saldo, beneficiário, valor, moeda, ordem e idempotência das transações. Uma API pode autenticar corretamente o usuário e ainda permitir fraude se não validar que ele pode operar determinada conta ou se aceitar a reutilização de uma requisição.
Os cenários prioritários incluem:
- quebra de autorização em contas, carteiras ou contratos;
- alteração de valor ou beneficiário após uma etapa de aprovação;
- reutilização de tokens e requisições;
- falhas de idempotência que geram operações duplicadas;
- abuso de recuperação de conta e redefinição de credenciais;
- contorno de limites transacionais;
- exposição de extratos, documentos e dados cadastrais;
- manipulação de webhooks e callbacks;
- comprometimento de chaves, pipelines e contas de nuvem.
Padrões como OWASP ASVS e OWASP API Security Top 10 ajudam a estruturar a cobertura. Quando houver dados de cartão, os requisitos aplicáveis do PCI DSS também precisam entrar no planejamento, sem tratar conformidade como substituta do teste ofensivo.
Como planejar uma operação ofensiva segura
1. Defina o objetivo e o escopo
Um bom objetivo é mensurável. “Testar a segurança” é vago; “avaliar se uma conta comum consegue consultar registros de outro paciente” ou “verificar se um invasor com credenciais vazadas alcança o ambiente de pagamentos” produz evidências úteis.
O escopo deve listar:
- domínios, IPs, APIs, aplicativos e ambientes autorizados;
- identidades e perfis de teste;
- integrações terceirizadas incluídas e excluídas;
- horários permitidos;
- técnicas proibidas;
- limites de volume e concorrência;
- contatos para interrupção imediata.
Qualquer ativo fora dessa lista deve ser considerado proibido até autorização formal.
2. Formalize as regras de engajamento
As regras de engajamento, ou ROE, protegem a organização e a equipe técnica. O documento precisa estabelecer quem autorizou o teste, período de validade, tratamento de evidências e condições de parada.
Em saúde e finanças, devem ser proibidas por padrão ações como negação de serviço, destruição de dados, ransomware real, persistência não controlada e exfiltração de bases completas. Para demonstrar impacto, normalmente basta acessar uma amostra mínima, mascarada quando possível, e registrar a evidência.
Critérios de parada incluem degradação perceptível, risco a um fluxo clínico, transação indevida, acesso a segredo de produção não previsto ou atuação simultânea de um atacante real.
3. Modele ameaças antes de explorar
Mapeie ativos, fronteiras de confiança, perfis de usuário, fluxos de dados e integrações. Em vez de executar uma lista genérica, formule hipóteses de ataque:
- Como um usuário de baixo privilégio chega a dados de outro titular?
- Uma credencial de integração permite movimentação lateral?
- Um webhook pode ser falsificado ou repetido?
- O sistema valida autorização em cada objeto ou apenas na interface?
- Um segredo presente no pipeline concede acesso ao ambiente crítico?
Essa abordagem reduz testes desnecessários e concentra esforço nos caminhos com maior impacto.
Execução: da aplicação à infraestrutura
A operação deve combinar testes manuais e automação. Scanners ajudam a ampliar cobertura, mas falhas de lógica de negócio, autorização e encadeamento geralmente exigem análise humana.
Camadas que precisam ser avaliadas
- Aplicação web: sessão, autorização, upload, injeção, renderização de conteúdo e proteção contra automação.
- APIs: inventário de endpoints, autorização por objeto e função, limitação de consumo, validação de esquema e exposição excessiva.
- Aplicativo móvel: armazenamento local, comunicação, proteção de tokens e dependência indevida de validações no cliente.
- Identidade: autenticação multifator, recuperação de conta, contas de serviço, privilégios e federação.
- Nuvem e DevOps: permissões, segredos, registros públicos, pipelines, imagens e separação entre ambientes.
- Integrações: confiança entre sistemas, assinatura de mensagens, certificados, filas, webhooks e tratamento de falhas.
- Detecção: geração de alertas, qualidade dos logs, correlação de eventos e tempo para contenção.
O teste deve usar identificadores próprios, marcação de tráfego e contas dedicadas. Dados coletados precisam ser criptografados, acessíveis apenas à equipe autorizada e eliminados conforme o prazo acordado.
Como classificar e comunicar os achados
Uma vulnerabilidade não deve ser priorizada apenas pela pontuação CVSS. O relatório precisa combinar explorabilidade, exposição, privilégio necessário, impacto técnico, impacto no negócio e presença de controles compensatórios. EPSS pode apoiar a análise de probabilidade para vulnerabilidades conhecidas, mas não mede falhas específicas de lógica de negócio.
Cada achado deve conter:
- ativo e ambiente afetados;
- pré-condições e perfil utilizado;
- passos reproduzíveis;
- evidência mínima, sem dados desnecessários;
- impacto técnico e operacional;
- classificação de severidade justificada;
- correção recomendada;
- alternativa de mitigação temporária;
- orientação para reteste.
Em saúde, o impacto deve considerar segurança do paciente, sigilo e continuidade assistencial. Em finanças, deve considerar fraude, integridade transacional, exposição de dados e interrupção de serviços.
Checklist para contratar ou aprovar um teste ofensivo
Antes de iniciar, confirme:
- [ ] Existe autorização formal assinada pelo responsável adequado?
- [ ] Produção e homologação estão claramente identificadas?
- [ ] Há contas e dados sintéticos suficientes para os cenários?
- [ ] Os limites de carga e as técnicas proibidas foram registrados?
- [ ] Terceiros afetados autorizaram o teste?
- [ ] A equipe defensiva sabe como validar alertas e interromper a operação?
- [ ] As evidências serão criptografadas e descartadas em prazo definido?
- [ ] O relatório avaliará lógica de negócio, não apenas CVEs?
- [ ] Está previsto reteste das correções?
- [ ] Existe um processo para tratar achados críticos imediatamente?
O principal trade-off é realismo versus segurança operacional. Testar em produção fornece sinais mais fiéis sobre controles e detecção, mas aumenta o risco; homologação reduz o impacto, porém pode esconder falhas de configuração e integração. Uma abordagem equilibrada valida exploração em ambiente controlado e executa, em produção, apenas provas mínimas previamente autorizadas.
Como a Predictor Solutions resolve isso
A Predictor Solutions executa avaliações ofensivas orientadas a risco em aplicações, APIs, nuvem e pipelines, com escopo formal, evidência reproduzível e recomendações ligadas ao impacto operacional. Em saúde, a experiência da empresa inclui sistemas e integrações HL7 v2 e FHIR; em engenharia de software, combina segurança ofensiva com desenvolvimento, dados, cloud e DevOps para corrigir a causa estrutural das falhas, e não apenas apontá-las.
Essa atuação ocorre no contexto de uma software house sediada em Lavras, Minas Gerais, que já atendeu 9 empresas de médio e grande porte. Os projetos da Predictor Solutions registram R$ 1,32 milhão de economia média por cliente ao ano, 70% de aumento médio de produtividade e 43% de aumento de lucro em seis meses — resultados empresariais que não substituem métricas de segurança, mas ajudam a integrar correção técnica, continuidade operacional e prioridade de negócio.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.