Testes ofensivos em sistemas de saúde e financeiros devem simular ataques reais dentro de limites formalmente autorizados, com isolamento, rastreabilidade e proteção da continuidade operacional. A abordagem adequada combina pentest de aplicações e APIs, validação de controles, simulação de caminhos de ataque e exercícios de resposta, sem expor pacientes, movimentar dinheiro real ou interromper serviços críticos.
Por que esses sistemas exigem uma abordagem específica
Aplicações de saúde e finanças compartilham três características: processam dados sensíveis, integram muitos sistemas e podem causar impacto material quando falham. Uma vulnerabilidade não representa apenas vazamento de informações; pode alterar uma decisão clínica, bloquear atendimento, gerar fraude financeira ou interromper operações essenciais.
Na saúde, os alvos incluem prontuários eletrônicos, portais de pacientes, sistemas hospitalares, dispositivos conectados, integrações HL7 v2, APIs FHIR e plataformas de telemedicina. Em finanças, o escopo pode envolver internet banking, aplicativos móveis, APIs de pagamento, Pix, Open Finance, CRMs, motores antifraude e sistemas administrativos.
Os principais riscos são:
- acesso indevido a dados pessoais e dados sensíveis protegidos pela LGPD;
- quebra de autenticação, autorização ou segregação entre usuários e organizações;
- abuso de APIs por automação, enumeração ou falhas de lógica;
- alteração de dados clínicos, cadastrais ou financeiros;
- indisponibilidade de serviços críticos;
- comprometimento de terceiros, integrações e credenciais técnicas;
- movimentação lateral entre aplicações, cloud e redes internas;
- falhas de detecção e resposta mesmo quando controles preventivos existem.
Por isso, executar apenas um scanner automatizado não é suficiente. É necessário validar como falhas técnicas, identidades, processos e integrações podem ser combinados.
Red team, pentest e varredura não são a mesma coisa
Varredura automatizada
Scanners identificam versões vulneráveis, configurações inseguras e padrões conhecidos. São úteis para cobertura frequente, mas geram falsos positivos e normalmente não compreendem regras de negócio.
Teste de intrusão
O pentest verifica um escopo definido, como uma aplicação web, API, aplicativo móvel ou ambiente cloud. O objetivo é confirmar vulnerabilidades, demonstrar impacto controlado e recomendar correções reproduzíveis.
Red Team Ops
Uma operação de red team avalia se pessoas, processos e tecnologias conseguem prevenir, detectar e responder a um adversário simulado. Em vez de procurar todas as falhas, a equipe persegue objetivos previamente aprovados, como verificar se seria possível acessar registros clínicos de outra instituição ou alcançar uma função financeira privilegiada.
O red team não substitui o pentest. Uma organização com baixa maturidade normalmente obtém mais valor corrigindo inventário, autenticação, exposição de APIs e vulnerabilidades conhecidas antes de executar uma operação orientada a objetivos.
Como definir um teste ofensivo seguro
Antes de qualquer atividade, deve existir uma autorização formal com regras de engajamento. Esse documento precisa definir:
- sistemas, domínios, endereços IP, aplicativos e APIs dentro do escopo;
- ambientes proibidos ou permitidos apenas em janelas específicas;
- técnicas autorizadas e expressamente vedadas;
- limites para engenharia social, persistência e movimentação lateral;
- horários de execução e contatos de emergência;
- critérios objetivos para interromper o teste;
- tratamento, retenção, criptografia e descarte das evidências;
- procedimento para comunicar vulnerabilidades críticas;
- responsabilidades do fornecedor, do contratante e de terceiros.
Em produção, o princípio é minimizar impacto. Testes destrutivos, negação de serviço, alteração irreversível e extração massiva de dados devem ser substituídos por provas mínimas. Uma evidência segura pode usar registros sintéticos, contas de teste e identificadores previamente preparados.
Um canal de emergência deve funcionar durante toda a operação. Se houver degradação, risco assistencial, transação inesperada ou suspeita de ataque real simultâneo, a atividade precisa ser interrompida e preservada para análise.
Testes ofensivos em sistemas de saúde
Aplicações, APIs FHIR e integrações HL7 v2
APIs FHIR devem ser avaliadas quanto a autenticação, autorização por recurso, paciente, organização e contexto clínico. Não basta verificar se o usuário está autenticado: é necessário confirmar se ele pode executar aquela ação sobre aquele recurso específico.
Os testes devem examinar:
- acesso indevido a recursos por troca de identificadores;
- exposição excessiva de campos clínicos;
- busca e exportação sem limites adequados;
- separação entre pacientes, profissionais e instituições;
- tokens com escopo excessivo ou validade inadequada;
- logs contendo dados clínicos, tokens ou informações pessoais;
- validação de payloads, anexos e extensões FHIR;
- comportamento de gateways, filas e serviços intermediários.
Em HL7 v2, a segurança depende frequentemente da arquitetura que transporta e processa as mensagens. Deve-se revisar segmentação de rede, autenticação entre sistemas, canais criptografados, validação de origem, filas, mecanismos de repetição e tratamento de mensagens inválidas. Também é importante verificar se dados sensíveis aparecem em logs operacionais ou ferramentas de observabilidade.
Segurança sem risco assistencial
Uma operação não deve alterar prescrições, resultados de exames ou dados utilizados na assistência. Quando uma hipótese exige alteração, o caminho recomendado é reproduzi-la em homologação representativa ou usar um registro sintético claramente identificado.
Critérios de interrupção específicos para saúde incluem:
- degradação perceptível de sistema assistencial;
- aumento anormal de filas de integração;
- impacto em estações ou equipamentos clínicos;
- contato com registro real além da prova mínima autorizada;
- qualquer possibilidade de influenciar uma decisão médica.
Testes ofensivos em sistemas financeiros
APIs, autenticação e regras de negócio
Sistemas financeiros exigem avaliação técnica e transacional. Muitas falhas relevantes não estão em componentes desatualizados, mas na sequência permitida pelas regras de negócio.
O plano de testes deve considerar:
- recuperação de conta e troca de dispositivo;
- autenticação multifator e resistência a reutilização de sessão;
- autorização por conta, empresa, função e limite transacional;
- alteração de favorecidos e dados cadastrais;
- repetição, concorrência e idempotência de operações;
- manipulação de valores, moedas, taxas e arredondamentos;
- abuso de cupons, estornos, crédito ou limites;
- proteção de APIs contra enumeração e automação;
- segregação entre criação, aprovação e execução de transações;
- exposição de chaves, segredos e dados financeiros em logs.
Testes com pagamentos devem usar sandbox ou contas e valores controlados. Quando produção for indispensável, limites, destinatários, reversão e monitoramento precisam estar acordados previamente. O objetivo é demonstrar a falha com o menor efeito possível, não maximizar o prejuízo.
Quando houver dados de cartões, requisitos aplicáveis do PCI DSS devem entrar no escopo. Para APIs, referências como OWASP API Security Top 10 e OWASP ASVS ajudam a estabelecer critérios verificáveis, mas não substituem a análise das regras de negócio.
Metodologia e evidências que geram correção
Um fluxo tecnicamente consistente pode seguir sete etapas:
- Modelagem de ameaças: identificar ativos críticos, agentes prováveis e caminhos de ataque.
- Reconhecimento autorizado: mapear superfícies expostas, tecnologias e integrações.
- Validação de controles: testar autenticação, autorização, sessões, entradas e configurações.
- Exploração controlada: confirmar impacto com a menor prova necessária.
- Encadeamento: verificar se falhas de baixo ou médio risco formam um caminho crítico.
- Avaliação de detecção: medir quais eventos foram registrados, alertados e investigados.
- Reteste: confirmar a correção e procurar variações da mesma causa raiz.
Cada achado deve incluir ativo afetado, pré-condições, evidência sanitizada, impacto, probabilidade, causa raiz e recomendação. A severidade não deve depender apenas de uma pontuação CVSS: contexto clínico, valor transacional, exposição, privilégios necessários e controles compensatórios também importam.
Para operações de red team, o relatório deve relacionar técnicas observadas a uma estrutura como MITRE ATT&CK e apresentar uma linha do tempo. Métricas úteis incluem tempo até detecção, tempo até triagem, proporção de ações registradas e pontos nos quais a equipe defensiva poderia interromper a cadeia.
Checklist para contratar ou aprovar a operação
Antes de iniciar, confirme:
- [ ] autorização assinada e escopo tecnicamente identificável;
- [ ] inventário de aplicações, APIs, clouds e terceiros envolvidos;
- [ ] contas de teste com diferentes perfis e organizações;
- [ ] dados sintéticos e mecanismos de limpeza;
- [ ] backups e procedimentos de recuperação validados;
- [ ] monitoramento ativo e contatos de emergência;
- [ ] limites para produção, engenharia social e exfiltração;
- [ ] armazenamento criptografado das evidências;
- [ ] SLA para comunicar achados críticos;
- [ ] plano de correção com responsáveis e prazos;
- [ ] reteste incluído no ciclo;
- [ ] separação entre relatório executivo e evidências técnicas sensíveis.
Como decidir entre pentest e red team
Escolha pentest quando o objetivo for encontrar e corrigir vulnerabilidades em um escopo conhecido, especialmente após uma nova aplicação, grande alteração arquitetural ou integração. Escolha red team quando a organização já possui controles básicos, monitoramento e equipe de resposta, mas precisa saber se um ataque encadeado seria detectado e contido.
Os trade-offs são claros: pentests oferecem maior cobertura de falhas por ativo; red teams oferecem maior realismo operacional, porém cobrem menos vulnerabilidades. Testes em homologação reduzem risco, mas podem ocultar diferenças de configuração. Testes em produção aumentam a fidelidade, porém exigem limites mais rigorosos e capacidade real de interrupção.
Como a Predictor Solutions resolve isso
A Predictor Solutions executa avaliações ofensivas com escopo autorizado, modelagem de ameaças, testes de aplicações e APIs, validação de cloud e análise de caminhos de ataque. Em saúde, a experiência com sistemas, dashboards, wearables, HL7 v2 e FHIR ajuda a avaliar controles sem ignorar riscos assistenciais; em plataformas financeiras e corporativas, a análise inclui autorização, integrações, identidades e regras de negócio.
A empresa também atua no desenvolvimento seguro e na correção das causas encontradas, conectando red team, engenharia de software, DevOps e observabilidade. Esse trabalho faz parte de uma atuação que já atendeu 9 empresas de médio e grande porte, com resultados gerais reportados de 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.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.