Cibersegurança dos dispositivos médicos conectados: como traduzir os alertas e as atualizações de segurança?

Quando é descoberta uma vulnerabilidade crítica num dispositivo médico conectado, a rapidez de reação é essencial. É necessário identificar os produtos afetados, avaliar o risco, preparar uma correção e informar os utilizadores. Para um fabricante presente em vários mercados, outra etapa torna-se igualmente determinante: transmitir as mesmas informações, com o mesmo grau de precisão, em várias línguas.

A tradução de alertas de cibersegurança para dispositivos médicos conectados não pode, portanto, ser tratada como um simples trabalho editorial. Um erro relativo a uma versão de software, a uma condição de exploração ou a uma medida compensatória pode levar um estabelecimento a tomar uma medida inadequada. Pode também atrasar a instalação de uma correção ou criar uma falsa sensação de segurança.

A tradução dos alertas como questão de segurança 

Neste contexto, um alerta de cibersegurança não é uma comunicação de marketing. Deve, nomeadamente, permitir ao destinatário determinar se o seu dispositivo é afetado e conhecer o nível de risco associado. Deve também especificar se foi observada uma exploração ativa, indicar a versão a instalar e assinalar a eventual existência de uma medida temporária antes da implementação da correção.

A tradução de dispositivos médicos deve preservar estas respostas sem acrescentar ambiguidade. O tradutor deve compreender a terminologia do produto, mas também a lógica de uma vulnerabilidade, de uma correção ou de um procedimento de remediação. Uma formulação tecnicamente plausível pode ser perigosa se alterar o alcance real do alerta.

Os conteúdos de cibersegurança a traduzir 

Os conteúdos em causa podem incluir, nomeadamente:

• os alertas e avisos de segurança;
• os boletins de vulnerabilidade;
• as notas de versão e os históricos de alterações;
• as instruções de instalação das correções;
• as atualizações de firmware e de software;
• as medidas compensatórias temporárias;
• as mensagens apresentadas na interface do dispositivo;
• as mensagens de correio eletrónico destinadas aos estabelecimentos e aos distribuidores;
• os artigos de suporte e as perguntas frequentes;
• os guiões de suporte destinados às equipas locais;
• as comunicações regulamentares ou de segurança no terreno.

Importa também distinguir um alerta puramente técnico de uma comunicação de segurança no âmbito de um processo de qualidade ou regulamentar. Uma vulnerabilidade para a qual não tenha sido identificada qualquer consequência clínica não será necessariamente objeto da mesma comunicação que um problema suscetível de afetar o funcionamento do dispositivo. Esta classificação deve ser definida antes da tradução, e não deixada à interpretação do linguista.

A organização da tradução dos alertas de cibersegurança

1. Classificar a urgência antes da tradução

Nem todas as comunicações requerem o mesmo prazo. Uma vulnerabilidade ativamente explorada, uma falha crítica exposta à Internet e uma melhoria preventiva não seguem o mesmo calendário. O nível de urgência deve ser visível no pedido de tradução e na ordem de tratamento das línguas.

Esta classificação permite igualmente a adaptação dos recursos. Um alerta crítico pode justificar uma equipa dedicada, disponibilidade fora dos horários habituais e um processo de validação contínuo. Uma nota de versão planeada com várias semanas de antecedência pode seguir o fluxo de localização padrão.

2. Fornecer um dossiê de tradução completo

O tradutor deve receber elementos complementares ao texto de partida. O dossiê entregue deveria incluir o boletim de partida aprovado, as versões afetadas, as referências CVE, a nota de versão da correção, as capturas de ecrã da interface e os documentos anteriores relacionados com o mesmo incidente.

Neste contexto, a coerência com a tradução de software é particularmente importante. Uma instrução que mencione um comando, um menu ou um botão deve reproduzir exatamente a designação que o utilizador vê na interface. O prestador deve, portanto, dispor das traduções validadas do software para evitar qualquer diferença entre o alerta de segurança e os elementos apresentados no ecrã.

Esta documentação limita os riscos de interpretação errada e reduz o recurso a suposições. Facilita também a identificação dos elementos que não devem ser traduzidos, como um comando, um caminho de acesso, um valor de registo, uma impressão digital criptográfica ou um nome de ficheiro.

3. Validar a versão traduzida no seu contexto

Uma frase pode estar correta quando considerada isoladamente e tornar-se ambígua numa interface, numa tabela ou num procedimento. A validação deve, portanto, incidir sobre o documento final, com a sua paginação, as suas ligações, as suas capturas de ecrã e os seus eventuais campos dinâmicos.

Para os conteúdos destinados a ser divulgados em vários canais, é também necessário comparar a página Web, o ficheiro PDF, a mensagem de correio eletrónico e o artigo de suporte. As informações críticas devem permanecer idênticas, mesmo quando a extensão ou a apresentação diferem. De forma mais ampla, a necessidade de estruturar os processos de tradução no âmbito do RDM e do RDIV diz respeito a todos os conteúdos regulamentares, nomeadamente os avisos de segurança e as interfaces de software que os utilizadores devem consultar.

A preservação da precisão técnica do alerta

A tradução deve conservar os identificadores e os valores técnicos sem alterações. As referências CVE (sistema público de identificação das vulnerabilidades informáticas conhecidas), as pontuações CVSS (sistema comum de avaliação da gravidade das vulnerabilidades), os números de versão, as portas de rede, os hashes, os comandos, os nomes de ficheiros e os caminhos de acesso devem ser protegidos na ferramenta de tradução. As unidades, os separadores e as convenções de versão devem também manter-se em conformidade com o produto.

Os verbos que exprimem uma obrigação ou uma possibilidade exigem uma atenção especial. “Deve ser instalado”, “pode ser explorado”, “deveria ser desativado” e “não deve ser utilizado” não implicam as mesmas ações. Uma formulação demasiado atenuada pode transformar uma instrução obrigatória numa simples recomendação. Por outro lado, uma tradução demasiado categórica pode provocar uma interrupção desnecessária de um sistema clínico.

Estas distinções devem constar do glossário do projeto. Quando um termo inglês é habitualmente utilizado no domínio em causa, pode ser mantido entre parênteses na sua primeira ocorrência, desde que esta prática seja harmonizada em todas as comunicações.

A coordenação entre a tradução e a atualização de segurança

A tradução de atualizações de segurança deve ser integrada no calendário de publicação da correção. Para além disso, deve ocorrer antes da divulgação da atualização técnica. Assim que o conteúdo de partida se torne suficientemente estável, as equipas linguísticas devem receber as notas de versão, as instruções de instalação, as mensagens integradas no software e os cenários de reversão para a versão anterior.

Esta antecipação evita que um utilizador possa descarregar a correção sem dispor das instruções correspondentes na sua língua. Limita também as divergências entre a página de suporte, o software, a mensagem de correio eletrónico informativa e a documentação técnica. A CNPD recomenda a adoção de medidas de segurança para minimizar as consequências dos ataques aos sistemas de informação e destaca a necessidade de manter os sistemas atualizados. Uma comunicação compreensível e disponível nos prazos exigidos facilita diretamente a aplicação destas medidas.

O enquadramento regulamentar a ter em conta 

Os fabricantes de dispositivos médicos que integram software devem gerir a cibersegurança durante todo o ciclo de vida do produto. Esta abordagem visa, nomeadamente, prevenir os ataques, o comprometimento dos dados e a utilização indevida dos dispositivos colocados no mercado.

O INFARMED disponibiliza informação sobre dispositivos médicos baseados em software e sobre os requisitos de interoperabilidade e segurança aplicáveis. Estes recursos permitem enquadrar a comunicação multilingue numa abordagem global de controlo dos riscos digitais.

O Regulamento de Ciber-resiliência (CRA) deve ser analisado com precisão. De acordo com o Centro Nacional de Cibersegurança (CNCS), o regulamento estabelece regras de cibersegurança para produtos de hardware e software com uma componente digital, mas prevê exclusões específicas, nomeadamente para os dispositivos médicos, que já são abrangidos por regras próprias. Estas disposições devem, por isso, ser analisadas tendo em conta o enquadramento regulamentar aplicável aos produtos digitais e as respetivas exclusões.

O Quadro Nacional de Referência para a Cibersegurança destaca, nomeadamente, a confidencialidade, a cifragem, a autenticação, a continuidade da atividade e as auditorias de segurança. Uma comunicação multilingue exata não constitui, por si só, um controlo de cibersegurança, mas pode contribuir para que as medidas e os procedimentos de segurança sejam compreendidos e aplicados corretamente pelos respetivos destinatários.

A monitorização dos alertas e a preparação da sua divulgação multilingue 

Uma monitorização estruturada permite reduzir o tempo entre a publicação de um alerta relativo a uma vulnerabilidade e o início da resposta interna. As equipas podem acompanhar os alertas de segurança e as informações sobre vulnerabilidades disponibilizados pelo Centro Nacional de Cibersegurança (CNCS). Estas informações devem depois ser analisadas em função dos sistemas e componentes utilizados nos dispositivos.

As recomendações gerais continuam também a ser úteis para estabelecer o contexto dos alertas. O Centro Nacional de Cibersegurança (CNCS) disponibiliza orientações e boas práticas destinadas a apoiar a proteção das redes e dos sistemas de informação. Estas referências podem servir de base aos procedimentos internos e às ações de sensibilização em matéria de cibersegurança.

Os controlos de qualidade a aplicar antes da publicação

O controlo linguístico deve procurar omissões, erros de sentido, incoerências terminológicas e formulações ambíguas. Deve também verificar os números, as datas, as versões, as referências de vulnerabilidade, as ligações e os nomes de produtos. Um controlo automático pode detetar algumas divergências, mas não substitui uma leitura técnica completa.

A validação deveria envolver vários intervenientes complementares:

• a equipa PSIRT ou a equipa de cibersegurança verifica a vulnerabilidade e as medidas propostas;
• a equipa de produto confirma as versões, as funções e as designações da interface;
• a área de assuntos regulamentares avalia o tipo de comunicação necessário;
• a equipa de qualidade garante a rastreabilidade e o cumprimento dos procedimentos;
• o especialista linguístico verifica o sentido, a terminologia e a legibilidade;
• um representante local verifica, quando pertinente, a adequação ao mercado.

Otimizar os prazos sem reduzir a qualidade 

A urgência não deve levar à supressão da revisão. É preferível preparar antecipadamente um sistema específico para as comunicações críticas: glossário validado, modelos de alertas, contactos de prevenção, níveis de prioridade, procedimento de escalonamento e regras de validação. Estes elementos reduzem o número de decisões a tomar durante o incidente.

As memórias de tradução podem acelerar o tratamento das formulações recorrentes, mas as suas correspondências devem ser verificadas. Uma frase validada no âmbito de uma vulnerabilidade anterior pode conter uma versão, uma condição ou uma ação que não seja adequada ao novo incidente. Para além disso, os segmentos que contêm dados técnicos variáveis devem ser identificados como particularmente sensíveis.

Para os fabricantes presentes em vários mercados, uma tradução profissional integrada no processo de gestão de vulnerabilidades proporciona maior segurança do que uma tradução improvisada à última hora ou realizada no final do processo. O prestador pode assim conhecer o produto, preparar a terminologia e mobilizar rapidamente os linguistas e revisores adequados.

Conclusão

A tradução de alertas de cibersegurança para dispositivos médicos conectados exige uma organização tão rigorosa como a implementada para preparar a própria correção. O conteúdo deve ser exato, imediatamente compreensível, coerente com o software e estar disponível quando os utilizadores têm de agir.

Ao integrarem a tradução de atualizações de segurança no processo de gestão de vulnerabilidades, os fabricantes reduzem as ambiguidades e aceleram a aplicação das medidas necessárias. Uma preparação terminológica, uma validação técnica e uma publicação coordenada permitem proteger de forma mais eficaz os dispositivos, os dados e a continuidade dos cuidados.