Testes ofensivos em sistemas de saúde e financeiros devem validar não apenas vulnerabilidades técnicas, mas também autorização, segregação de dados, fraude, resiliência e capacidade de detecção. A execução exige escopo formal, regras de engajamento, limites operacionais e evidências reproduzíveis, porque um teste mal controlado pode interromper atendimentos, expor dados sensíveis ou movimentar valores reais.
Red team, pentest e avaliação de aplicações não são a mesma coisa
Um pentest procura vulnerabilidades em um escopo delimitado, como uma aplicação web, API ou aplicativo móvel. Já uma operação de red team simula objetivos de um adversário e avalia pessoas, processos, aplicações, infraestrutura e resposta a incidentes.
Em ambientes críticos, três modalidades costumam ser combinadas:
- Pentest de aplicação: identifica falhas como injeção, controle de acesso quebrado, exposição de dados e configurações inseguras.
- Teste de lógica de negócio: procura formas de abusar de fluxos legítimos, como alterar beneficiários, acessar prontuários de outro paciente ou duplicar transações.
- Red Team Ops: verifica se o invasor consegue atingir um objetivo e se SOC, SIEM, EDR, WAF e equipes internas detectam e contêm a atividade.
A escolha depende da pergunta que precisa ser respondida. Se a organização quer saber quais falhas existem em uma API, um pentest é adequado. Se quer descobrir se um invasor conseguiria acessar prontuários ou manipular uma operação financeira sem ser detectado, é necessário um exercício orientado a objetivos.
Por que saúde e finanças exigem controles adicionais
Dados clínicos e financeiros têm alto impacto individual e operacional. Uma exploração pode comprometer confidencialidade, integridade e disponibilidade ao mesmo tempo.
Em saúde, os riscos incluem:
- acesso indevido a prontuários, exames ou prescrições;
- alteração de informações usadas em decisões clínicas;
- indisponibilidade de sistemas assistenciais;
- abuso de integrações HL7 v2, FHIR ou dispositivos conectados;
- identificação de pacientes a partir de dados pseudonimizados.
No setor financeiro, devem ser considerados:
- alteração de conta favorecida ou valor;
- repetição de transações e ataques de replay;
- condições de corrida em saldo, limite ou resgate;
- fraude por abuso de recuperação de conta;
- quebra de isolamento entre clientes ou empresas;
- manipulação de webhooks, conciliações e rotinas assíncronas.
A LGPD exige medidas técnicas e administrativas para proteger dados pessoais. Entretanto, conformidade documental não substitui validação ofensiva: uma política pode declarar segregação de acesso enquanto a API permite consultar recursos de outros usuários pela troca de um identificador.
Como definir regras de engajamento
As regras de engajamento, ou Rules of Engagement, devem ser aprovadas antes de qualquer atividade. O documento precisa responder, no mínimo, às seguintes questões:
- Quais domínios, aplicativos, APIs, endereços IP e contas estão autorizados?
- O teste ocorrerá em produção, homologação ou ambiente dedicado?
- Quais técnicas são proibidas, como negação de serviço ou engenharia social?
- Quais dados podem ser acessados, copiados ou apenas visualizados?
- Qual é a janela de execução e quem pode interromper o teste?
- Como vulnerabilidades críticas serão comunicadas emergencialmente?
- Como evidências e credenciais temporárias serão armazenadas e eliminadas?
Também deve existir um kill switch: canal e procedimento para suspensão imediata. Em saúde, sinais de degradação assistencial devem encerrar o teste. Em finanças, qualquer possibilidade de movimentação real, alteração contábil ou impacto em clientes exige interrupção e validação conjunta.
Produção ou homologação?
Testar em homologação reduz o risco operacional, mas pode produzir uma visão incompleta. Ambientes de teste frequentemente usam configurações, dados, integrações e controles diferentes de produção.
Uma abordagem equilibrada é executar testes destrutivos em ambiente isolado e manter, em produção, apenas técnicas previamente aprovadas e de baixo impacto. Contas sintéticas, transações reversíveis, limites reduzidos e monitoramento em tempo real diminuem o risco sem eliminar a validade do exercício.
Controles que devem ser testados em aplicações críticas
Referências como OWASP ASVS, OWASP Web Security Testing Guide e OWASP API Security Top 10 ajudam a estruturar a cobertura. Elas não substituem a modelagem de ameaças específica do negócio.
Identidade, sessão e autorização
Autenticação forte não corrige autorização fraca. Os testes precisam verificar:
- bypass ou fadiga de MFA;
- recuperação de conta e troca de dispositivo;
- expiração e revogação de tokens;
- fixação, reutilização e sequestro de sessão;
- elevação de privilégio horizontal e vertical;
- isolamento entre organizações, filiais, médicos, pacientes e contas;
- permissões excessivas em contas de serviço.
BOLA, ou Broken Object Level Authorization, merece atenção especial em APIs. Trocar um identificador de recurso não pode permitir acesso a um prontuário, fatura ou transação pertencente a outro usuário.
APIs, integrações e processamento assíncrono
APIs devem ser avaliadas além dos endpoints publicados. É importante procurar versões antigas, documentação exposta, rotas administrativas, GraphQL com consultas excessivas e serviços internos acessíveis externamente.
Webhooks e filas exigem testes de assinatura, timestamp, idempotência, ordenação e repetição. Uma operação crítica não deve ser executada duas vezes porque a mesma mensagem foi reenviada. A aplicação também precisa rejeitar mensagens adulteradas ou fora da janela temporal aceita.
Lógica financeira
Em fluxos financeiros, o teste deve cobrir:
- valores negativos, extremos ou com precisão inesperada;
- arredondamento e divergências entre frontend e backend;
- alteração do favorecido após aprovação;
- reutilização de comprovantes ou solicitações;
- concorrência entre saques, compras, resgates ou transferências;
- aprovação pelo mesmo usuário que iniciou a operação;
- divergência entre saldo exibido, saldo disponível e razão contábil.
Os testes não devem movimentar recursos reais sem autorização explícita. Quando possível, deve-se usar uma conta controlada, valores mínimos e mecanismo de reversão previamente definido.
HL7 v2, FHIR e aplicações de saúde
HL7 v2 é um padrão de mensagens, não um mecanismo completo de segurança. Integrações baseadas em MLLP normalmente dependem de segmentação de rede, túneis protegidos, autenticação complementar e monitoramento para reduzir o risco.
Em FHIR, devem ser verificados escopos OAuth, SMART on FHIR, compartimentos de pacientes, operações de busca e exportação. Filtros amplos, paginação mal implementada ou escopos excessivos podem permitir enumeração e extração em massa.
Outros cenários relevantes incluem:
- alteração de identificadores de paciente ou atendimento;
- associação incorreta entre exame e prontuário;
- acesso de profissionais fora da relação assistencial;
- permanência de acesso após desligamento ou troca de função;
- exposição de dados em logs, URLs, notificações e ferramentas de observabilidade.
Como executar uma operação ofensiva controlada
Um processo verificável pode ser organizado em sete etapas:
- Modelagem de ameaças: identificar ativos, agentes, fronteiras de confiança e impactos.
- Definição de objetivos: estabelecer provas concretas, como demonstrar acesso indevido sem extrair registros reais.
- Preparação: criar contas, dados sintéticos, monitoramento e procedimentos de parada.
- Reconhecimento autorizado: mapear superfícies externas e internas dentro do escopo.
- Exploração controlada: obter a menor evidência necessária, evitando persistência ou movimentação lateral desnecessária.
- Validação defensiva: medir alertas, investigação, contenção e tempo de resposta.
- Remediação e reteste: confirmar tecnicamente que a correção elimina a causa, não apenas o payload utilizado.
Uma prova de conceito deve coletar o mínimo de dados. Em vez de baixar milhares de prontuários, por exemplo, pode ser suficiente demonstrar que uma conta sintética acessa um recurso sintético de outro perfil.
Como priorizar as descobertas
CVSS ajuda a descrever severidade técnica, mas não representa sozinho o risco do negócio. A priorização deve considerar pelo menos cinco dimensões:
- facilidade e pré-requisitos de exploração;
- exposição pública ou interna;
- alcance sobre usuários, organizações ou registros;
- impacto clínico, financeiro e regulatório;
- capacidade atual de detectar e conter o abuso.
Uma falha com pontuação técnica moderada pode ser prioritária se permitir alterar uma prescrição ou desviar uma aprovação financeira. Da mesma forma, uma vulnerabilidade crítica em um componente isolado pode ter risco menor quando existem controles compensatórios verificáveis.
Cada achado deve conter ativo afetado, pré-condições, passos de reprodução, evidência mínima, impacto, causa raiz, recomendação e critério de reteste. Capturas sem contexto e listas geradas automaticamente não são suficientes para orientar correções.
Checklist para contratar ou aprovar um teste ofensivo
Antes da execução, confirme:
- [ ] autorização formal e escopo técnico;
- [ ] inventário de APIs, integrações e perfis de acesso;
- [ ] dados sintéticos e contas controladas;
- [ ] contatos de emergência e kill switch;
- [ ] exclusão explícita de técnicas destrutivas não autorizadas;
- [ ] proteção e prazo de eliminação das evidências;
- [ ] plano para vulnerabilidades críticas;
- [ ] participação das equipes de aplicação, infraestrutura e segurança;
- [ ] reteste incluído nos critérios de aceite;
- [ ] relatório executivo e relatório técnico reproduzível.
O principal trade-off está entre realismo e segurança operacional. Quanto mais próximo da produção for o exercício, mais representativos serão os resultados — e maior deverá ser o controle sobre impacto, dados e possibilidade de interrupção.
Como a Predictor Solutions resolve isso
A Predictor Solutions, software house de Lavras, Minas Gerais, atua com segurança ofensiva, desenvolvimento sob medida, inteligência artificial, engenharia de dados, cloud e DevOps. Em saúde, trabalha com sistemas e integrações HL7 v2 e FHIR, além dos produtos Predictor Health e Predictor AI Hospitals; essa experiência permite avaliar tanto vulnerabilidades convencionais quanto falhas específicas de fluxos clínicos e interoperabilidade.
A abordagem combina modelagem de ameaças, revisão de arquitetura, testes de aplicações e APIs, validação de lógica de negócio e reteste. Os exercícios são delimitados por regras de engajamento, evidência mínima e critérios de parada, evitando que o próprio teste crie um incidente.
No conjunto de seus projetos de tecnologia, a Predictor Solutions atendeu 9 empresas de médio e grande porte, com resultados informados de R$ 1,32 milhão de economia média por cliente ao ano, aumento médio de 70% de produtividade e crescimento de 43% do lucro em seis meses. Esses números representam resultados gerais dos projetos e não substituem métricas específicas de segurança, que devem ser definidas para cada operação.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.