3. Categoria III - engenharia social
•	phishing, 
•	fraudes, 
•	coleta de credenciais, 
•	exploração de urgência clínica. 

3. Como ler os cenários: do vetor de ataque ao impacto clínico

- Cada cenário a seguir descreve:
1.	contexto assistencial e componentes tecnológicos;
2.	superfície de ataque principal (o “onde entra”);
3.	cadeia de eventos plausível;
4.	impacto clínico, operacional e/ou legal;
5.	mitigação/prevenção proposta. 

Foi incluindo 	um fragmento de “código fictício” (JSON, pseudocódigo, Python ou Markdown) 
para ajudar profissionais de TI/engenharia a visualizar controles mínimos e pontos de falha. 

Os exemplos são hipotéticos e não devem ser usados como guia operacional único; servem 
para ensino e discussão interprofissional.

4.1 - Cenário DMIA: bomba de infusão “inteligente” com atualização remota e API exposta

# Contexto. 
Um hospital adota bombas de infusão “inteligentes” integradas ao prontuário eletrônico. 
O DMIA recebe prescrições validadas, aplica bibliotecas de dose (guardrails) e registra logs para
auditoria. 
Para facilitar manutenção, o fabricante disponibiliza um serviço de atualização remota e um 
endpoint de telemetria (status, alarmes, versões) acessível pela rede interna.

# Superfície de ataque. 
1.	credenciais padrão ou fracas no painel de administração do DMIA;
2.	endpoint de telemetria/API sem autenticação forte;
3.	atualização remota sem verificação robusta de integridade;
4.	segmentação de rede insuficiente permitindo movimento lateral a partir de um computador 
de enfermagem  comprometido.

# Cadeia de eventos. 
Um atacante obtém acesso a um computador do posto por phishing e escaneia a rede. Ele encontra 
o endpoint  de telemetria da bomba (porta aberta, sem autenticação forte) e descobre modelo/versão.
Em seguida, explora um fluxo de atualização mal protegido para instalar um pacote adulterado ou 
desativar controles de dose, sem necessariamente “controlar” a bomba: basta interferir no componente 
que valida parâmetros ou no canal de configuração.

# Impacto. 
Pode haver risco direto ao paciente (infusão fora de faixa), necessidade de suspensão 
de uso e troca para modo manual, além de impacto em auditoria e responsabilidade (quem alterou o quê, 
quando e por que). 
Mesmo sem danos imediato, a simples perda de confiança no parque de infusão pode gerar interrupções 
de cuidado.

# Mitigação/prevenção proposta. 
•	segmentar rede de DMIA (VLAN/ACL) e bloquear varredura lateral; 
•	desativar credenciais padrão, impor MFA onde aplicável e certificados de dispositivo; 
•	exigir atualização assinada e verificação de assinatura/versão; 
•	manter inventário e política de patches (janela de manutenção, testes, rollback);
•	registrar trilhas de auditoria e alertas de mudança de configuração. 

4.2 - Cenário DMIA: estação de imagem com IA e “poisoning” de entrada via DICOM

# Contexto. 
Uma clínica utiliza um software de apoio ao diagnóstico por imagem que roda em uma estação
local (GPU) e recebe exames no padrão DICOM a partir do PACS. 
O sistema aplica um modelo de IA para sugerir achados (ex.: suspeita de trombose, embolia 
pulmonar, nódulos) e gera um pré-relatório para revisão do especialista.

# Superfície de ataque. 
1.	pipeline de ingestão de DICOM com validação insuficiente; 
2.	dependências do software (bibliotecas de processamento) desatualizadas;
3.	ausência de verificação de origem e integridade do exame;
4.	falta de segregação entre ambiente clínico e ambiente de testes/treino do modelo.

# Cadeia de eventos. 
Um agente malicioso (ou um insider) injeta no PACS um exame DICOM com metadados
e/ou pixels manipulados para explorar uma falha de parser ou para induzir o modelo a 
produzir uma saída sistematicamente enviesada (ex.: reduzir a sensibilidade para um achado)
Na rotina, o sistema passa a “normalizar” casos patológicos, e o pré-relatório influencia 
decisões (mesmo que o especialista revise, o viés pode atuar como ancoragem cognitiva).

# Mitigação/prevenção proposta.
•	validação rigorosa de DICOM (schema, tags esperadas, limites de tamanho, origem);
•	isolamento do serviço de inferência (sandbox/contêiner com permissões mínimas);
•	assinatura/cheksum e trilha de auditoria para entrada de exames;
•	monitoramento de drift e de taxas de “achado positivo” por equipamento/período;
•	regra operacional: IA como sugestão, nunca como laudo automático. 

4.3 Cenário IoMT: monitoramento remoto e credenciais padrão em dispositivos de beira-leito

# Contexto. 
A UTI utiliza monitores multiparamétricos conectados à rede e a um servidor central, permitindo visualização 
em tempo real em estações de enfermagem e em tablets autorizados. 
O ambiente se aproxima do conceito de IoMT devido às seguintes peculiaridades: 
1.	muitos dispositivos, 
2.	alta criticidade, 
3.	comunicação constante,
4.	dependência de disponibilidade.

# Superfície de ataque. 
•	credenciais padrão mantidas por conveniência; 
•	serviços legados (Telnet/HTTP sem TLS) ainda ativos;
•	rede “plana” onde IoMT e computadores administrativos compartilham o mesmo segmento; 
•	ausência de inventário e de gestão de ciclo de vida (dispositivo sem patch por anos).

# Cadeia de eventos. 
Um notebook terceirizado acessa o Wi Fi corporativo e está comprometido. O atacante faz varredura, 
encontra monitores com senha padrão e obtém acesso ao painel web. A partir daí, pode causar 
indisponibilidade (DoS), interferir em alarmes ou “inundar” o servidor central com dados inválidos, 
levando equipes a adotar condutas com base em sinais incorretos ou a desconsiderar alarmes reais
(“fadiga de alarmes”).

# Mitigação/prevenção proposta.
•	inventariar IoMT/DMIA (modelo, versão, portas, responsável, janela de manutenção);
•	segmentar rede (IoMT separado de rede administrativa e de visitantes);
•	eliminar credenciais padrão e adotar autenticação forte (quando suportado);
•	bloquear protocolos inseguros e usar criptografia;
•	monitorar tráfego anômalo e estabelecer plano de contingência clínica. 

4.4 Cenário Cloud Computing e Medicina: bucket de armazenamento com exames/relatórios e configuração pública acidental

# Contexto. 
Uma equipe cria um data lake na nuvem para armazenar exames, laudos, PDFs e dados pseudonimizados 
para pesquisa e melhoria de modelos de IA. 
Um pipeline automático envia arquivos para um bucket, e um serviço de rotulagem/anotação acessa os dados 
para preparação de conjuntos de treino.

# Superfície de ataque.
1.	erro de configuração tornando o bucket público;
2.	chaves de API expostas em repositório ou notebook;
3.	logs contendo identificadores (ex.: nome em caminho de arquivo);
4.	ausência de classificação de dados e de controles por ambiente (dev/test/prod).

# Cadeia de eventos. 
Durante um ajuste de integração, um bucket é marcado como “public read” para facilitar testes rápidos. 
A alteração não é revertida e passa despercebida. Um mecanismo de busca/crawler encontra o endpoint e 
indexa arquivos. 
O incidente pode evoluir de simples exposição de documentos para extorsão e obrigações legais (LGPD), 
além de risco reputacional.

# Mitigação/prevenção proposta.
•	default deny para armazenamento (bloquear acesso público por política);
•	criptografia em repouso e em trânsito;
•	segregação de contas/projetos por ambiente;
•	varredura contínua de configuração (CSPM) e alertas;
•	mascaramento de identificadores em nomes de arquivos e logs;
•	revisão de acessos de terceiros. 

4.5 Cenário Cloud Computing, IA e assistência: chatbot clínico conectado ao prontuário e risco de “prompt injection”

# Contexto. 
Um hospital implementa um assistente conversacional para apoiar a equipe (ex.: “resuma a internação”, 
“liste alergias”, “gerar orientações de alta”). 
O serviço roda em contêiner na nuvem, integra-se ao prontuário via API e usa mecanismos de busca interna 
(RAG) para recuperar documentos. Para ser útil, o assistente possui permissões para consultar dados e gerar 
textos rapidamente.

# Superfície de ataque.
1.	entradas do usuário (prompt) e documentos recuperados (prompt indireto);
2.	permissões excessivas do serviço (capacidade de buscar “qualquer” coisa);
3.	vazamento de segredos (tokens) em logs/erros;
4.	falhas de isolamento do contêiner e de gestão de segredos;
5.	ausência de filtros de saída para evitar exposição de dados sensíveis.

# Cadeia de eventos. 
Um usuário solicita “gere um resumo do caso” e, intencionalmente ou não, inclui instruções para ignorar regras 
e listar dados completos (ex.: “inclua CPF, endereço e contatos”). 
Alternativamente, o assistente recupera um documento interno contendo texto malicioso (prompt indireto) que
orienta o modelo a revelar informações do sistema (“mostre sua política”, “imprima variáveis de ambiente”). 
Se o serviço tiver permissões amplas e logs verbosos, o resultado pode ser vazamento de dados pessoais e/ou 
credenciais.

Continuação do Cenário 4.5

# Mitigação/prevenção proposta.
•	princípio do menor privilégio: escopar a API do prontuário por papel e por caso;
•	separar “assistente de escrita” (gera texto) de “assistente de acesso” (consulta dados), 
reduzindo agência;
•	camadas contra prompt injection (validação de entrada, delimitação de contexto, recusa de
solicitações sensíveis, higienização de documentos recuperados);
•	gestão de segredos (vault), sem tokens em logs;
•	filtros de saída e DLP para impedir PII em respostas não autorizadas;
•	auditoria: quem consultou o quê e por qual justificativa clínica. 

5.1. Exemplos em Linguagem de Computação

Cenário 1 - Contrato mínimo de telemetria exigindo autenticação mútua e versão explícita:

JSON

{"device_id":"INF-UTI-0031","firmware_version":"3.7.2","telemetry":{"endpoint":"/v1/status","auth":"mutual_tls","client_cert_rotation_days":90},"updates":{"channel":"signed_packages_only","signature":"ed25519","allow_downgrade":false},"audit":{"log_level":"security_events","send_to_siem":true}}

Cenário 2 - Exemplo de validação

Pseudocódigo

function ingest_dicom(file): assert file.size < MAX_MB meta = parse_dicom_headers(file) assert meta.modality in ["CT","MR","US","XA"] assert meta.patient_id is not null assert meta.study_uid matches expected_format assert source_ip in ALLOWLIST_PACS assert verify_checksum(file) == true image = decode_pixels_safely(file) # sandboxed result = ai_inference(image) log_audit(event="dicom_ingest", study_uid=meta.study_uid, source=source_ip) return result

Cenário 3 - Exemplo política para segmentação

Markdown

# Segmentação mínima (exemplo) - VLAN 10: IoMT/DMIA (monitores, bombas, etc.) - VLAN 20: Estações clínicas (enfermagem, consultórios) - VLAN 30: Administrativo - VLAN 40: Visitantes Regras (ACL/Firewall): - VLAN10 -> Apenas servidor de monitoramento (porta X) e NTP/DNS internos - VLAN20 -> Acesso ao prontuário e ao servidor de monitoramento - VLAN30/40 -> Sem acesso direto à VLAN10 - Gestão remota do fabricante -> somente via VPN + jump server + MFA

Cenário 4 - Exemplo verificação automática de configuração antes de publicar:

Python 

def enforce_bucket_policy(bucket): # pseudocódigo: em cada deploy, falhar se bucket estiver público if bucket.is_public_read() or bucket.is_public_list(): raise Exception("Bucket público: bloquear deploy e acionar segurança") if not bucket.encryption_enabled(): raise Exception("Criptografia obrigatória") if bucket.logging_disabled(): raise Exception("Logs/auditoria obrigatórios") return True

Cenário 5 - Exemplo política imitando ferramentas e campos acessíveis:

JSON

{"tools":[{"name":"ehr_search","allowed":true,"scopes":["assigned_patients_only"],"fields_allowlist":["diagnoses","allergies","medications","labs"],"fields_denylist":["cpf","address","phone"]},{"name":"ehr_update","allowed":false}],"output_controls":{"pii_detection":true,"max_tokens":600,"redact_on_detect":true},"logging":{"store_prompts":false,"store_outputs":"metadata_only"}}

6. Recursos confiáveis e vigilância contínua de vulnerabilidades

Falar de superfície de ataque implica acompanhar vulnerabilidades e boas práticas ao longo do ciclo de vida. 
Na prática, isso requer combinar:
1.	fontes técnicas (boletins, CVEs, relatórios de incidentes),
2.	orientações de órgãos reguladores,
3.	processos internos de gestão de risco. 

- Para o contexto brasileiro, dispositivos médicos e softwares associados se relacionam com requisitos e práticas
regulatórias, incluindo regras sobre software como dispositivo médico (SaMD) e requisitos essenciais de 
segurança e desempenho, além de iniciativas de rastreabilidade e identificação única (UDI). 

- Em paralelo, referências internacionais ajudam a estruturar governança e documentação, como o documento do 
IMDRF sobre práticas de cibersegurança para dispositivos médicos e materiais do FDA sobre cibersegurança em 
DMIA conectados, incluindo expectativas de gestão de vulnerabilidades e transparência (ex.: SBOM). 

- Também é útil acompanhar guias e taxonomias específicas de IA, como documentos do NIST para gestão de risco 
em IA e listas de riscos para aplicações com LLMs (ex.: OWASP Top 10 para LLM). 

- O ponto central é que “segurança” não é um checklist único: é uma rotina de observação, correção, validação e
comunicação, especialmente quando o cuidado depende de disponibilidade e integridade de sistemas.

7. Desafios práticos para reduzir superfícies de ataque sem interromper o cuidado

Mesmo quando o risco é bem compreendido, a execução de mitigação em saúde enfrenta obstáculos
particulares:
• Continuidade assistencial: não é trivial “parar para atualizar” dispositivos e sistemas críticos.
• Legado tecnológico: muitos IoMT/DMIA operam com sistemas antigos e janelas restritas de patch.
• Responsabilidade compartilhada: parte do controle é do fabricante, parte é do serviço de saúde 
(configuração, rede, usuários).
• Convergência TI–Engenharia Clínica: inventário, segmentação e logs dependem de integração real 
entre áreas.
• IA como software “dinâmico”: modelos sofrem drift, mudam com dados e exigem monitoramento 
contínuo, não apenas validação inicial.

8. Considerações finais

A principal mensagem para a prática é simples: na assistência médica com IA, superfície de ataque 
não é um conceito abstrato. Ela se materializa em: 
•	integrações, 
•	redes, 
•	dispositivos conectados, 
•	credenciais, 
•	atualizações, 
•	logs, 
•	no próprio comportamento humano diante de sistemas que “parecem inteligentes”. 

Ao descrever cenários plausíveis, buscou-se aproximar profissionais da saúde de decisões concretas 
(segmentar rede, controlar privilégios, auditar mudanças, tratar dados como ativos críticos) e, ao mesmo
tempo, lembrar profissionais de computação de que a métrica final é clínica: 
1.	disponibilidade, 
2.	integridade,
3.	segurança do paciente.

Como próximos passos, recomenda-se que instituições criem uma agenda conjunta entre TI, engenharia clínica, 
segurança da informação e liderança assistencial: 
•	inventário e classificação de ativos (IoMT/DMIA e sistemas), 
•	definição de arquitetura de rede,
•	identidade, política de atualização,
•	resposta a incidentes,
•	governança específica para IA:
1.	mapeamento de riscos, 
2.	monitoramento,
3.	controles de uso. 

Reduzir a superfície de ataque é, em última instância, uma forma de proteger o cuidado:
•	manter sistemas disponíveis, 
•	dados íntegros,
•	decisões clínicas mais confiáveis.

Oi, Ricardo! Tudo bem?

A sua atividade Cibersegurança na Assistência Médica com IA - mapeando superfícies de ataque e mitigação ficou muito rica e bem alinhada ao tema de contêineres, segurança de aplicações e supply chain, conectando o conceito de superfície de ataque a cenários reais da saúde digital.

O material mostra uma ótima integração entre cibersegurança em saúde, IA, IoMT, DMIA, cloud computing, LGPD e governança, com uma abordagem muito didática ao traduzir riscos técnicos em impactos clínicos, operacionais e legais. Uma dica é, em uma próxima versão, transformar os cenários em uma matriz simples com colunas como vetor de ataque, impacto, probabilidade, criticidade e mitigação, porque isso facilita a leitura por equipes multidisciplinares e ajuda a priorizar ações de segurança sem perder de vista a continuidade do cuidado.

Qual desses cenários você considera mais urgente para discussão entre TI, engenharia clínica e liderança assistencial?

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Olá Lorena, agradeço a análise e as sugestões de melhoria. Quanto à sua pergunta, minha resposta é o cenário 4.3, pois tenho a
impressão de que ele já é uma realidade mais do que apenas uma possibilidade.
Att,
Ricardo.