Testes ofensivos em sistemas de saúde e financeiros devem simular objetivos reais de um invasor, mas com autorização formal, limites técnicos e mecanismos de interrupção imediata. O foco não é apenas encontrar vulnerabilidades: é verificar se controles preventivos, monitoramento e resposta conseguem impedir que uma falha se transforme em fraude, vazamento de dados ou risco assistencial.
Red Team não é sinônimo de pentest
Um teste de intrusão tradicional costuma avaliar um escopo técnico delimitado, como uma aplicação web, API ou ambiente cloud. O Red Team Ops trabalha com objetivos de negócio e pode combinar análise de aplicações, identidade, infraestrutura, engenharia social autorizada e avaliação da capacidade de detecção.
A diferença prática está na pergunta respondida:
- Pentest: quais vulnerabilidades podem ser exploradas neste escopo?
- Red Team: um adversário conseguiria atingir determinado ativo crítico sem ser contido?
- Purple Team: como equipes ofensivas e defensivas podem validar e melhorar controles em conjunto?
Em saúde, um objetivo poderia ser avaliar se uma conta comprometida alcançaria prontuários além do necessário. Em finanças, poderia ser verificar se uma falha de autorização permitiria consultar contas de terceiros ou iniciar uma operação indevida. A execução deve usar dados sintéticos, transações controladas e ambientes segregados sempre que possível.
Por que saúde e finanças exigem outra abordagem
Esses setores concentram dados pessoais, integrações complexas e operações com baixa tolerância a indisponibilidade. Uma técnica aceitável em um portal institucional pode ser perigosa em uma UTI, em um sistema de prescrição ou em uma plataforma que processa pagamentos.
Os riscos principais são diferentes, embora parcialmente sobrepostos:
| Setor | Ativos críticos | Impactos possíveis |
|---|---|---|
| Saúde | prontuários, prescrições, resultados, dispositivos e integrações clínicas | exposição de dados, atraso assistencial, alteração de informação clínica |
| Financeiro | contas, saldos, credenciais, transações, chaves e trilhas contábeis | fraude, movimentação indevida, inconsistência de ledger e indisponibilidade |
| Ambos | identidade, APIs, cloud, backups, fornecedores e logs | escalada de privilégio, vazamento, extorsão e falha de recuperação |
A LGPD se aplica aos dois contextos, com atenção especial aos dados de saúde, classificados como dados pessoais sensíveis. Instituições financeiras também precisam considerar normas setoriais, requisitos contratuais e, quando houver processamento de cartões, o PCI DSS. A aplicabilidade exata deve ser validada pelas áreas jurídica, de compliance e segurança.
Planejamento seguro da operação
Nenhum Red Team deve começar pela execução técnica. O primeiro artefato é um documento de regras de engajamento, aprovado pelos responsáveis pelo ambiente e pelo negócio.
O que as regras de engajamento precisam definir
- Objetivo, escopo, datas e janelas permitidas.
- Domínios, APIs, contas, redes e ambientes incluídos.
- Técnicas autorizadas, condicionais e proibidas.
- Dados que podem ser acessados, copiados ou apenas visualizados.
- Limites para persistência, movimentação lateral e elevação de privilégio.
- Contatos operacionais e executivo com disponibilidade durante o teste.
- Palavra ou procedimento de interrupção imediata, o chamado kill switch.
- Regras para retenção, criptografia e destruição das evidências.
- Tratamento de incidentes reais descobertos durante a operação.
- Responsabilidade sobre terceiros, fornecedores e serviços compartilhados.
Ativos de terceiros não devem ser testados apenas porque estão integrados ao sistema avaliado. É necessária autorização específica do proprietário e compatibilidade com os termos do provedor.
Modelagem baseada em objetivos e ameaças
Uma operação eficaz começa pelos chamados crown jewels: ativos cuja perda de confidencialidade, integridade ou disponibilidade causa impacto relevante. Depois, o time constrói cenários de ameaça plausíveis e define evidências de sucesso sem produzir dano real.
Exemplos de objetivos controlados incluem:
- Demonstrar acesso não autorizado a um registro sintético.
- Validar se uma conta de baixo privilégio alcança uma função administrativa.
- Verificar se segredos expostos permitem chegar a um ambiente restrito.
- Simular uma tentativa de transação usando beneficiário, valor e conta de teste.
- Medir se o SOC detecta e contém uma sequência autorizada de eventos.
MITRE ATT&CK pode organizar técnicas e cobertura de detecção. OWASP ASVS, OWASP API Security Top 10, NIST SP 800-115 e PTES ajudam a estruturar controles e metodologia. Esses referenciais são complementares; nenhum deles substitui a análise do fluxo de negócio.
Pontos críticos em sistemas de saúde
Aplicações clínicas raramente funcionam isoladas. Elas se conectam a prontuários eletrônicos, laboratórios, sistemas de imagem, operadoras, dispositivos e plataformas de identidade.
HL7 v2 e FHIR
HL7 v2 define mensagens e estruturas de integração, mas a proteção do transporte depende da implementação. Ambientes legados podem usar canais internos que foram projetados sob premissas de confiança de rede. O teste deve verificar segmentação, autenticação entre sistemas, validação de mensagens, rastreabilidade e limitação de acesso.
Em APIs FHIR, a avaliação deve incluir:
- autenticação e expiração de tokens;
- autorização por usuário, organização, paciente e tipo de recurso;
- busca e paginação sem exposição excessiva;
- controle de operações em massa;
- prevenção de acesso direto a recursos de outro paciente;
- auditoria de leitura, alteração e exportação;
- proteção contra abuso de taxa e enumeração.
O teste não deve alterar prescrições, resultados ou dados clínicos reais. Quando produção for inevitável, a preferência é por contas e registros sintéticos previamente identificados, com monitoramento conjunto e técnicas não destrutivas.
Pontos críticos em aplicações financeiras
Em sistemas financeiros, a vulnerabilidade frequentemente aparece na lógica de negócio, não em uma falha clássica de infraestrutura. Uma API pode estar tecnicamente protegida e ainda permitir alteração de beneficiário, repetição de requisição ou quebra de segregação entre contas.
O plano deve avaliar, de forma controlada:
- autorização por conta, empresa, carteira e perfil;
- autenticação forte e recuperação de acesso;
- idempotência de operações;
- vínculo entre valor, beneficiário e confirmação;
- assinatura e validação de webhooks;
- segregação entre consulta, aprovação e liquidação;
- limites transacionais e controles antifraude;
- consistência entre saldo, lançamento e ledger;
- exposição de dados em relatórios, logs e arquivos exportados.
Nenhuma simulação deve gerar transferência real não planejada. Operações financeiras precisam usar sandbox, contas controladas ou mecanismos de reversão previamente aprovados.
Como testar sem interromper o negócio
Há três opções principais de ambiente:
- Produção: oferece maior realismo, mas também maior risco operacional e regulatório.
- Homologação fiel: reduz risco, desde que reproduza identidades, políticas, integrações e configurações relevantes.
- Laboratório isolado: permite técnicas mais invasivas, porém pode esconder falhas existentes apenas na operação real.
Uma estratégia comum é executar descoberta e validações destrutivas em laboratório, testar exploração controlada em homologação e reservar produção para cenários não destrutivos. Saúde exige atenção adicional a equipamentos e fluxos assistenciais; finanças, a filas, conciliações e eventos assíncronos.
Controles de segurança durante o teste incluem limites de requisições, horários de menor impacto, snapshots, backups verificados, monitoramento em tempo real e interrupção automática diante de latência, erro ou indisponibilidade acima do limite acordado.
Como medir o resultado
Contar vulnerabilidades não mede sozinho a eficácia da defesa. Um relatório executivo e técnico deve relacionar cada evidência ao impacto e aos controles que falharam.
Métricas úteis incluem:
- MTTD: tempo entre o início da atividade e sua detecção.
- MTTC: tempo entre a detecção e a contenção.
- Percentual de técnicas detectadas, investigadas e bloqueadas.
- Quantidade de caminhos independentes até o ativo crítico.
- Cobertura de logs necessária para reconstruir a atividade.
- Tempo de correção por criticidade.
- Taxa de reincidência após o reteste.
CVSS ajuda a padronizar severidade técnica, mas deve ser combinado com contexto. Uma falha de autorização em prontuário ou pagamento pode ter prioridade maior que uma vulnerabilidade com pontuação técnica semelhante em um ativo sem dados críticos.
Entregáveis que realmente ajudam a corrigir
O relatório precisa ser reproduzível sem virar um manual de abuso. Para cada achado, deve conter ativo afetado, pré-condições, evidências minimizadas, impacto, causa raiz, controles compensatórios e recomendação técnica.
Um bom encerramento inclui:
- reunião executiva sobre exposição e decisões de risco;
- sessão técnica com desenvolvimento, cloud, segurança e operações;
- plano de correção com responsáveis e prazos;
- atualização de alertas e procedimentos de resposta;
- reteste das falhas críticas;
- exercício Purple Team para validar a nova cobertura.
Evidências com dados pessoais, tokens ou segredos devem ser criptografadas, ter acesso restrito e prazo de descarte definido. Capturas de tela e amostras devem mostrar somente o mínimo necessário.
Checklist para contratar ou aprovar um Red Team
Antes de iniciar, confirme:
- [ ] Existe autorização formal e escopo assinado?
- [ ] Os ativos críticos e impactos intoleráveis foram identificados?
- [ ] Há dados sintéticos e contas de teste disponíveis?
- [ ] Terceiros autorizaram testes em seus ativos?
- [ ] O kill switch foi testado?
- [ ] Backups e procedimentos de recuperação foram validados?
- [ ] SOC, operação clínica ou financeira sabem como escalar incidentes?
- [ ] O relatório incluirá causa raiz, correção e reteste?
- [ ] A custódia e destruição das evidências estão definidas?
- [ ] O teste cobre lógica de negócio, APIs, identidade, cloud e observabilidade?
Como a Predictor Solutions resolve isso
A Predictor Solutions, software house de Lavras, Minas Gerais, executa segurança ofensiva integrada à engenharia de aplicações, cloud e dados. Em sistemas de saúde, a experiência com HL7 v2, FHIR, dashboards e aplicações hospitalares permite avaliar não apenas endpoints, mas também autorização clínica, integrações, rastreabilidade e risco operacional; em plataformas financeiras, o trabalho considera identidade, APIs, segregação de funções e lógica transacional.
A abordagem combina definição de regras de engajamento, modelagem de ameaças, testes controlados, análise de causa raiz e reteste. Quando apropriado, a operação evolui para Purple Team, transformando evidências ofensivas em alertas, melhorias de arquitetura e testes automatizados no ciclo de desenvolvimento.
A Predictor Solutions já atendeu 9 empresas de médio e grande porte. Em seu portfólio geral de projetos, registra R$ 1,32 milhão de economia média por cliente ao ano, aumento médio de 70% em produtividade e crescimento de 43% no lucro em seis meses; esses resultados descrevem a atuação global da empresa e não devem ser interpretados como garantia específica de um projeto de segurança.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.