Testes ofensivos em sistemas de saúde e financeiros devem reproduzir ataques reais sem colocar pacientes, transações ou dados pessoais em risco. Para isso, uma operação de Red Team precisa combinar autorização formal, escopo técnico preciso, regras de engajamento, monitoramento contínuo e interrupção imediata quando houver impacto clínico, financeiro ou operacional.
Por que esses sistemas exigem uma abordagem diferente
Aplicações de saúde e finanças compartilham três características: processam dados sensíveis, integram muitos sistemas e sustentam operações que não podem ser simplesmente desligadas. Uma falha pode causar exposição de informações, fraude, indisponibilidade ou decisões baseadas em dados incorretos.
Na saúde, o risco não termina na confidencialidade. Um ataque contra prontuários, prescrições, dispositivos ou integrações pode afetar a integridade dos dados usados no atendimento. Uma mensagem HL7 v2 adulterada, por exemplo, pode associar um resultado ao paciente errado; uma autorização FHIR mal implementada pode expor recursos clínicos de terceiros.
Em aplicações financeiras, a preocupação inclui alteração de beneficiários, repetição de transações, abuso de limites, manipulação de webhooks e comprometimento de contas privilegiadas. Mesmo quando o dinheiro não é movimentado, a alteração de saldos, conciliações ou trilhas de auditoria pode produzir perdas relevantes.
Por isso, executar ferramentas automáticas sem considerar o contexto não caracteriza uma operação madura de Red Team. O trabalho precisa validar caminhos completos de ataque, incluindo pessoas, aplicações, APIs, identidade, infraestrutura, cloud e capacidade de detecção.
Red Team, pentest e varredura não são a mesma coisa
A escolha do formato deve partir do objetivo:
- Varredura de vulnerabilidades: identifica versões, configurações e padrões conhecidos. É rápida e recorrente, mas produz falsos positivos e raramente demonstra impacto.
- Pentest: testa um escopo delimitado, como uma API, aplicação web ou ambiente cloud. Procura vulnerabilidades exploráveis e apresenta evidências técnicas.
- Red Team Ops: simula objetivos de um adversário, como acessar prontuários, comprometer uma conta financeira ou alcançar o ambiente de produção. Avalia também prevenção, detecção e resposta.
- Purple Team: promove colaboração entre ataque e defesa para testar controles, ajustar alertas e repetir os cenários até que sejam detectados.
Um pentest é mais indicado antes de um lançamento, após mudanças relevantes ou para avaliar uma integração específica. Red Team faz mais sentido quando a organização já possui controles básicos, logs centralizados e uma equipe capaz de reagir. Sem esses elementos, o exercício tende a apenas confirmar fragilidades já esperadas.
O que precisa existir antes do primeiro teste
Nenhuma atividade ofensiva deve começar apenas com uma autorização verbal. O documento de regras de engajamento, ou Rules of Engagement, precisa ser aprovado pelos responsáveis técnicos, jurídicos e de negócio.
Checklist de autorização e escopo
- ativos, domínios, endereços IP, aplicativos e APIs autorizados;
- ambientes permitidos e explicitamente proibidos;
- período, horários e origem do tráfego de teste;
- técnicas permitidas, condicionais e proibidas;
- limites para phishing, engenharia social e acesso físico;
- contatos disponíveis durante toda a operação;
- procedimento de parada emergencial, o chamado kill switch;
- política para coleta, armazenamento e destruição de evidências;
- tratamento de serviços terceirizados e infraestrutura compartilhada;
- critérios para comunicar uma vulnerabilidade crítica imediatamente.
Também é necessário identificar dependências que não pertencem à organização. Uma autorização para testar um portal não permite atacar o provedor de pagamentos, a operadora de saúde, o serviço de e-mail ou a plataforma de nuvem fora das condições contratuais aplicáveis.
Dados reais devem ser evitados sempre que dados sintéticos representarem adequadamente o cenário. Quando o uso de produção for indispensável, a coleta precisa ser mínima, criptografada e rastreável, com acesso restrito e prazo de eliminação definido.
Cenários ofensivos para sistemas de saúde
O teste deve acompanhar o fluxo clínico e não apenas as telas da aplicação. Isso inclui cadastro, atendimento, resultados, prescrições, faturamento, integrações e perfis administrativos.
APIs FHIR e integrações HL7 v2
Em APIs FHIR, os principais testes envolvem autenticação, autorização por recurso e segregação entre pacientes, profissionais e organizações. É necessário procurar falhas como BOLA/IDOR, filtros que permitem enumeração, escopos excessivos, referências indiretas e exposição indevida em históricos ou resultados de busca.
No HL7 v2, o foco inclui validação de mensagens, confiança entre sistemas, controle de origem, campos inesperados, repetição de mensagens e tratamento de erros. O teste nunca deve inserir uma informação clínica ambígua em produção sem contenção previamente acordada.
Outros cenários relevantes são:
- comprometimento de contas de profissionais e administradores;
- acesso entre organizações ou unidades sem autorização;
- alteração de prescrições, resultados ou identificação do paciente;
- extração de dados por relatórios, exportações e logs;
- abuso de tokens de integração e contas de serviço;
- movimentação lateral a partir de aplicações legadas;
- indisponibilidade de componentes essenciais ao atendimento.
A criticidade deve considerar o efeito clínico, não apenas a pontuação CVSS. Uma vulnerabilidade tecnicamente simples pode ser crítica se permitir modificar informações usadas em uma decisão médica.
Cenários ofensivos para aplicações financeiras
Em sistemas financeiros, testar somente o login deixa de fora os fluxos com maior impacto. O Red Team deve avaliar a jornada completa da operação, desde a inclusão de um favorecido até a confirmação, contabilização, conciliação e notificação.
Os cenários mais importantes incluem:
- bypass de autenticação multifator e recuperação insegura de conta;
- alteração de destinatário ou valor entre validação e execução;
- repetição de requisições por ausência de idempotência;
- condições de corrida em saldo, limite, resgate ou pagamento;
- quebra de segregação entre usuários, empresas e operadores;
- assinatura inadequada ou reuso de webhooks;
- exposição de chaves, tokens e credenciais em código ou pipelines;
- abuso de contas privilegiadas e painéis administrativos;
- manipulação de arquivos de conciliação e trilhas de auditoria.
Testes com movimentação real devem usar limites previamente definidos, contas controladas e mecanismos de reversão. Ataques de negação de serviço, pulverização de senhas ou automações de alto volume exigem autorização específica porque podem acionar bloqueios, mecanismos antifraude e custos de terceiros.
Como conduzir a operação com segurança
Uma execução consistente pode ser dividida em seis etapas:
- Modelagem de ameaças: identificar ativos críticos, adversários plausíveis e objetivos de ataque.
- Reconhecimento controlado: mapear exposição externa, identidades, tecnologias e integrações sem ultrapassar o escopo.
- Validação inicial: confirmar vulnerabilidades com a menor interação capaz de gerar evidência.
- Encadeamento: demonstrar como falhas menores permitem alcançar um ativo crítico.
- Detecção e resposta: verificar quais ações foram alertadas, investigadas e contidas.
- Correção e reteste: validar a solução aplicada e procurar caminhos alternativos.
Cada evidência deve registrar data, ativo, identidade utilizada, pré-condições, requisição ou comando relevante, impacto e recomendação. Capturas de tela isoladas são insuficientes quando não permitem reproduzir a descoberta.
Durante o teste, os operadores devem acompanhar erros, latência, filas, consumo de recursos e indicadores de negócio. O exercício precisa ser interrompido se houver risco de atendimento incorreto, processamento financeiro indevido, degradação não prevista ou propagação para terceiros.
Como classificar e priorizar os achados
CVSS ajuda a padronizar a severidade técnica, mas não substitui a análise de negócio. Uma priorização útil combina pelo menos cinco critérios:
| Critério | Pergunta prática |
|---|---|
| Explorabilidade | O ataque exige acesso interno, interação ou condição rara? |
| Impacto técnico | Há perda de confidencialidade, integridade ou disponibilidade? |
| Impacto de negócio | Pode afetar paciente, transação, faturamento ou operação? |
| Alcance | O problema afeta um usuário, uma organização ou todo o ambiente? |
| Detecção | A atividade gera alerta acionável e investigação adequada? |
A correção deve atacar a causa raiz. Se diferentes endpoints apresentam falhas de autorização, corrigir apenas a rota usada na prova de conceito mantém o padrão vulnerável. A solução pode exigir uma camada central de autorização, testes automatizados negativos e revisão dos perfis de acesso.
Métricas que mostram se o exercício funcionou
O número bruto de vulnerabilidades não mede sozinho a maturidade. Indicadores mais úteis incluem:
- proporção de caminhos de ataque detectados;
- tempo entre a primeira ação ofensiva e o primeiro alerta;
- tempo para triagem, contenção e escalonamento;
- quantidade de controles preventivos contornados;
- percentual de achados corrigidos e aprovados no reteste;
- reincidência por causa raiz;
- cobertura de logs sobre identidades, APIs e ativos críticos;
- diferença entre o impacto previsto e o impacto demonstrado.
Essas métricas devem ser comparadas entre exercícios equivalentes. Reduzir o tempo de detecção enquanto se amplia a cobertura é um sinal melhor do que simplesmente encontrar menos falhas.
Como a Predictor Solutions resolve isso
A Predictor Solutions estrutura avaliações ofensivas conectando aplicação, APIs, identidade, cloud, integrações e impacto de negócio. Em saúde, a experiência com sistemas, dashboards, wearables, HL7 v2 e FHIR permite avaliar controles sem ignorar segurança clínica; em aplicações financeiras, o trabalho considera autorização, transações, webhooks, segregação e rastreabilidade.
A abordagem inclui definição de escopo, regras de engajamento, modelagem de ameaças, exploração controlada, documentação reproduzível e reteste. Quando apropriado, o trabalho também integra segurança ao ciclo de desenvolvimento, com revisão arquitetural, testes de autorização, gestão de segredos, hardening de cloud e melhoria da observabilidade.
A empresa, sediada em Lavras, Minas Gerais, já atendeu 9 organizações de médio e grande porte. Em seu portfólio de software, inteligência artificial, dados e automação, registra resultados agregados de R$ 1,32 milhão de economia média por cliente ao ano, aumento médio de 70% na produtividade e crescimento de 43% no lucro em seis meses; esses indicadores representam o conjunto dos projetos e não devem ser interpretados isoladamente como resultados de Red Team.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.