Os riscos ocultos na distribuição de ficheiros em ambientes OT

Na maioria dos ambientes de OT, a introdução de um ficheiro num sistema crítico segue uma sequência específica de passos. Começa com a chegada de um fornecedor com firmware, de um prestador de serviços com uma correção ou de uma equipa de manutenção para efetuar atualizações de configuração. Os ficheiros são analisados, aprovados e entregues. No entanto, algures entre estes procedimentos e o momento em que o ficheiro chega ao PLC (Controlador Lógico Programável) ou à HMI (Interface Homem-Máquina), as equipas de segurança perdem-no completamente de vista.

São utilizadas várias abordagens para dar resposta a este desafio. As soluções baseadas em rede gerem a transferência de ficheiros entre sistemas de TI e de OT, e os fluxos de trabalho baseados em quiosques inspecionam os suportes removíveis no ponto de entrada. No entanto, uma parte do problema permanece sistematicamente por resolver. Trata-se do que acontece a um ficheiro após ter sido verificado, enquanto se encontra em trânsito para o sistema crítico.

A maioria dos operadores de OT dispõe de fluxos de trabalho de inspeção integrados e sólidos. Normalmente, os suportes removíveis e os dispositivos temporários são analisados antes de entrarem no ambiente isolado de OT, e as aprovações são registadas. Estes controlos são necessários, mas partilham uma limitação comum: criam um único momento de confiança.

Os sistemas OT antigos não foram concebidos para questionar o que lhes chega. Os PLCs, as IHMs e as estações de trabalho de engenharia antigas normalmente não conseguem executar agentes EDR (Endpoint Detection and Response) nem verificar se os ficheiros recebidos correspondem às aprovações originais. Quando um dispositivo é ligado, os ficheiros tornam-se acessíveis por predefinição.

Estas limitações fazem com que a segurança de cada distribuição de ficheiros num sistema crítico dependa do cumprimento, por parte de cada operador, das etapas de verificação manual. Contar com o facto de cada operador seguir todas as etapas em todos os locais é um pressuposto do processo, não um controlo de segurança.

A questão deve agora passar de «este ficheiro estava limpo quando foi analisado?» para «podemos confirmar que continua a ser o mesmo ficheiro no momento em que é implementado no sistema crítico?»

Em setores regulamentados, é essencial confirmar que um ficheiro não sofreu alterações desde a sua aprovação até à sua implementação. Assim que um ficheiro for aprovado na fase de inspeção, deve existir um mecanismo que permita confirmar se sofreu alterações.

Em ambientes OT, o problema continua por resolver, uma vez que a maioria dos fluxos de trabalho atuais carece de um mecanismo para detetar alterações posteriores à verificação. Se um ficheiro for alterado após a verificação, devido a um erro ou a uma manipulação deliberada, o sistema OT de destino não consegue detetá-lo. O registo da verificação mantém-se válido e a aprovação continua registada. Um ficheiro que foi verificado como seguro há três dias e que, desde então, foi alterado, parece idêntico a um ficheiro que foi considerado seguro há três dias e que não sofreu alterações. O operador responsável pela sua distribuição não dispõe de nenhuma forma fiável de distinguir entre os dois.

A verificação não termina no MetaDefender Kiosk . Se um ficheiro verificado for alterado após a verificação e antes da implementação, é automaticamente bloqueado e ocultado. Nesse caso, esse ficheiro tem de passar novamente pela verificação antes de poder ser disponibilizado.

Este mecanismo garante a integridade dos ficheiros, pelo que o operador não tem de o fazer manualmente. Isto faz com que o modelo de segurança passe de «verificar uma vez e distribuir» para «verificar continuamente até à implementação».