Testes ofensivos em sistemas de saúde e financeiros devem validar caminhos reais de ataque sem colocar pacientes, transações ou dados sensíveis em risco. Para isso, uma operação de Red Team precisa combinar autorização formal, escopo técnico, limites de impacto, monitoramento defensivo e um plano de correção orientado ao risco de negócio.
O que é Red Team Ops
Red Team Ops é uma operação controlada que simula técnicas, táticas e procedimentos de adversários reais para medir se uma organização consegue prevenir, detectar, investigar e conter ataques. O objetivo não é apenas encontrar vulnerabilidades, mas demonstrar como falhas distintas podem ser encadeadas até causar impacto relevante.
Uma operação pode avaliar aplicações web, APIs, identidades, infraestrutura em nuvem, dispositivos, integrações com terceiros e controles do Security Operations Center, ou SOC. O trabalho costuma usar referências como MITRE ATT&CK, OWASP Application Security Verification Standard, OWASP API Security Top 10 e metodologias de teste como PTES.
Red Team não é sinônimo de pentest
As três abordagens mais comuns têm finalidades diferentes:
- Varredura de vulnerabilidades: identifica versões desatualizadas, configurações inseguras e exposições conhecidas de forma automatizada.
- Pentest: testa um escopo definido, como uma API ou aplicação, buscando vulnerabilidades exploráveis e evidências de impacto.
- Red Team: simula objetivos de um invasor, encadeia técnicas e também mede a capacidade de detecção e resposta.
Uma API de pagamentos pode passar por uma varredura e ainda permitir abuso de regras de negócio. Da mesma forma, um sistema hospitalar pode não ter vulnerabilidades conhecidas, mas apresentar autorização inadequada entre prontuários, unidades ou perfis profissionais.
Por que saúde e finanças exigem regras específicas
Aplicações de saúde e financeiras processam ativos com consequências diretas no mundo real. Na saúde, uma indisponibilidade pode interromper consultas, prescrições, laudos ou fluxos de UTI. Em finanças, uma falha pode permitir transações indevidas, alteração de favorecidos, fraude ou exposição de dados bancários.
Dados de saúde são classificados pela LGPD como dados pessoais sensíveis. Informações financeiras também podem envolver dados pessoais, sigilo contratual e requisitos regulatórios. Conforme o contexto, o teste deve considerar normas e obrigações aplicáveis, como LGPD, regras do Banco Central, PCI DSS para ambientes com cartões e contratos com operadores ou parceiros. A equipe jurídica e o encarregado de dados devem validar quais requisitos efetivamente se aplicam.
Isso muda a estratégia ofensiva. Em vez de simplesmente perguntar “é possível explorar?”, a operação precisa responder:
- Qual ativo pode ser alcançado?
- Qual seria o impacto clínico, financeiro, operacional e regulatório?
- O ataque foi detectado e correlacionado?
- Quanto tempo a equipe levou para conter a atividade?
- Quais controles impedem que a mesma cadeia volte a funcionar?
Como definir o escopo sem gerar risco operacional
Todo teste deve começar com um documento de regras de engajamento, aprovado pelas partes responsáveis. Ele precisa estabelecer sistemas incluídos, horários, técnicas permitidas, dados que podem ser acessados, contatos de emergência e condições de interrupção.
Checklist mínimo antes da execução
- Autorização formal dos proprietários dos ativos e terceiros envolvidos.
- Lista de domínios, APIs, IPs, contas, ambientes e integrações autorizadas.
- Definição explícita do que está fora do escopo.
- Contas de teste com perfis e permissões representativos.
- Dados sintéticos ou anonimizados sempre que possível.
- Backups verificados e procedimento de restauração.
- Monitoramento ativo de disponibilidade, erros e filas.
- Canal de emergência disponível durante toda a operação.
- Critérios de parada para degradação, risco ao paciente ou movimentação financeira.
- Política para coleta, criptografia, retenção e destruição das evidências.
Testes destrutivos, negação de serviço, alteração de prontuários e movimentação de dinheiro real normalmente devem ser proibidos em produção. Quando a validação precisa ocorrer no ambiente real, a técnica deve ser adaptada para produzir evidência mínima, reversível e previamente acordada.
Testes ofensivos em sistemas de saúde
O ecossistema de saúde frequentemente combina aplicações modernas com sistemas legados, equipamentos médicos, integrações HL7 v2, APIs FHIR, arquivos, bancos de dados e fornecedores externos. A superfície de ataque não termina no portal acessado pelo usuário.
Autorização e isolamento de prontuários
O teste deve verificar se um usuário consegue consultar ou modificar registros de outro paciente, unidade ou organização. Em APIs, isso inclui vulnerabilidades como BOLA, ou autorização inadequada no nível do objeto, e BFLA, relacionada a funções privilegiadas.
Também devem ser avaliados:
- Separação entre perfis clínicos, administrativos e técnicos.
- Restrições por unidade, especialidade e vínculo assistencial.
- Contas inativas, compartilhadas ou com privilégios excessivos.
- Exportação em massa de prontuários e laudos.
- Registro de consultas, alterações e ações administrativas.
- Sessões abertas em dispositivos compartilhados.
HL7 v2 e FHIR
Mensagens HL7 v2 podem trafegar em integrações que confiam excessivamente na rede interna. O protocolo e o transporte MLLP, isoladamente, não garantem autenticação, autorização e criptografia; esses controles precisam ser implementados na arquitetura, por exemplo com segmentação, túneis seguros, gateways e validação de origem.
Em APIs FHIR, o teste deve avaliar autenticação, escopos, consentimento, paginação, buscas amplas e acesso a recursos como Patient, Observation e DiagnosticReport. Implementações com OAuth 2.0, OpenID Connect ou SMART on FHIR precisam validar corretamente tokens, audiência, expiração, redirecionamentos e permissões concedidas.
O teste não deve inserir resultados clínicos falsos em fluxos assistenciais ativos. Alterações controladas devem ocorrer em ambiente segregado ou com registros sintéticos claramente identificados.
Testes ofensivos em aplicações financeiras
Sistemas financeiros exigem validação além das vulnerabilidades tradicionais de código. Muitas falhas graves aparecem em regras de negócio, concorrência, integrações assíncronas e diferenças entre o que a interface mostra e o que a API aceita.
Fluxos que merecem prioridade
- Cadastro, recuperação de conta e troca de dispositivo.
- Autenticação multifator e elevação de privilégio.
- Inclusão e alteração de favorecidos.
- Criação, confirmação, cancelamento e estorno de transações.
- Limites por usuário, dispositivo, horário e valor.
- Webhooks e callbacks de parceiros.
- Conciliação e processamento em filas.
- Perfis administrativos e operações manuais.
A operação deve verificar autorização por objeto, repetição de requisições, idempotência, condições de corrida, manipulação de valores e reutilização de tokens. Em arquiteturas baseadas em OAuth 2.0 e OpenID Connect, também devem ser analisados redirecionamentos, validação de audiência, rotação de chaves, mTLS e assinaturas quando adotados pelo sistema.
Uma evidência segura pode demonstrar que uma validação foi contornada usando uma conta e uma transação fictícias. Não é necessário transferir dinheiro real nem acessar dados de clientes para comprovar o risco.
Como medir o resultado de uma operação
Contar vulnerabilidades não é suficiente. Dez achados informativos podem ser menos relevantes do que uma única cadeia que permita assumir uma conta privilegiada.
Métricas úteis incluem:
- Percentual de técnicas detectadas pelo SOC.
- Tempo médio entre execução, alerta e investigação.
- Tempo até contenção da conta, sessão ou origem comprometida.
- Quantidade de caminhos viáveis até os ativos críticos.
- Cobertura de logs em aplicações, APIs, identidade e nuvem.
- Percentual de achados corrigidos dentro do SLA.
- Taxa de reincidência após reteste.
A severidade deve considerar probabilidade, impacto e exposição. CVSS ajuda na padronização técnica, mas não substitui o contexto: uma falha com pontuação moderada pode ser crítica se alterar uma prescrição, liberar um laudo ou contornar um limite financeiro.
O relatório precisa orientar a correção
Cada achado deve apresentar ativo afetado, pré-condições, evidência, impacto, causa raiz e recomendação verificável. Evidências com dados pessoais, tokens ou segredos precisam ser minimizadas e protegidas.
A correção deve priorizar causas estruturais. Se cinco endpoints apresentam autorização inconsistente, corrigir somente as rotas exploradas mantém o risco. O ideal é centralizar políticas de acesso, adicionar testes automatizados e bloquear regressões no pipeline de entrega.
Um fluxo objetivo pode usar quatro prazos internos: contenção imediata para risco crítico ativo, correção prioritária para vulnerabilidades exploráveis, tratamento planejado para riscos moderados e aceitação formal para riscos residuais. Os prazos exatos devem refletir a criticidade e a capacidade operacional da organização.
O reteste fecha o ciclo: confirma a correção, procura caminhos alternativos e verifica se novos controles aparecem nos logs. Red Team Ops deve alimentar backlog de engenharia, threat modeling, regras de detecção e exercícios de resposta a incidentes.
Como a Predictor Solutions resolve isso
A Predictor Solutions executa segurança ofensiva integrada à engenharia de aplicações, APIs, cloud e DevOps. Em ambientes de saúde, essa atuação é combinada com experiência em integrações HL7 v2 e FHIR; em sistemas financeiros, o trabalho prioriza identidade, autorização, regras transacionais, rastreabilidade e integrações externas.
A abordagem começa por escopo e regras de engajamento, avança por testes manuais e automatizados e termina com evidências reproduzíveis, priorização por impacto e reteste. Quando a causa está na arquitetura ou no código, a correção pode ser incorporada ao desenvolvimento, aos testes de segurança e ao pipeline de entrega.
A empresa é uma software house sediada em Lavras, Minas Gerais, e também atua com inteligência artificial aplicada, engenharia de dados, cloud e sistemas sob medida. Em seu portfólio geral, atende 9 empresas de médio e grande porte, com resultados registrados 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; esses indicadores representam os projetos da empresa como um todo, não uma garantia isolada de resultado em segurança.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.