Os recentes ataques aos sistemas de frio de supermercados em vários países europeus voltaram a expor as dependências digitais das operações. A Supply Chain Magazine ouviu Fernando Chaves, líder de Risk Consulting da Marsh, sobre os fornecedores que importa acompanhar, os acessos que ficam esquecidos e os planos que precisam de funcionar quando os sistemas falham.
Primeiro, foram centenas de supermercados em França. Depois, surgiram novas ocorrências em vários países europeus, incluindo Portugal. Os ataques aos sistemas de refrigeração deram consequências físicas a um risco muitas vezes associado à perda de dados ou à indisponibilidade de serviços informáticos: alimentos deteriorados, stocks retirados da venda e equipamentos cujo funcionamento deixou de ser fiável.
Depois de acompanhar os acontecimentos em França e os impactos confirmados em Portugal, a SCM aprofundou também o tema das dependências de fornecedores tecnológicos e dos seus efeitos na operação.
Agora, fomos ouvir Fernando Chaves, líder de Risk Consulting da Marsh. Para quem gere logística, compras ou operações, por onde começa a avaliação do risco? Quem deve conhecer e controlar os acessos dos prestadores? E o que precisa de estar decidido antes de um incidente colocar os stocks e as entregas sob pressão?
SCM – Os recentes ataques aos sistemas de refrigeração mostram como um incidente num prestador externo pode chegar à operação de várias empresas. Para um diretor de logística ou de supply chain, por onde deve começar a avaliação destas dependências e que perguntas deve fazer aos fornecedores críticos?
Fernando Chaves – A avaliação deve começar pela operação e não especificamente na tecnologia. O diretor de logística (mas não só) deve perguntar que processos não podem parar, de que sistemas dependem e quanto tempo a empresa consegue trabalhar se esses sistemas deixarem de estar disponíveis.
No caso da cadeia de frio, não basta olhar para os equipamentos de refrigeração. É necessário perceber quem gere os sensores, os controladores, os alarmes, as plataformas de monitorização, as comunicações e a manutenção remota. Também deve estar claro quem pode alterar configurações, quem recebe os alertas e quem intervém quando algo corre mal e tudo isto 24/7.
A mesma análise deve ser feita relativamente ao Sistema de Gestão do Armazém e ao Sistema de Gestão de Transportes (WMS e TMS), aos sistemas de automação, às plataformas de expedição, às ligações EDI, à telemática das frotas, aos sistemas de controlo de acessos e às plataformas cloud.
É importante não esquecer os equipamentos aparentemente menores. Só a título de exemplo, em 2018, foi divulgado o caso de um casino norte-americano onde os atacantes terão utilizado como ponto de entrada um termómetro ligado à internet, instalado num aquário do lobby. O dispositivo não era um sistema central do casino, mas estava ligado à rede e permitiu chegar a informação de maior valor. Embora os detalhes públicos do caso sejam limitados, a lição é clara: um equipamento pode ser pouco importante para a operação e ser, ainda assim, uma porta de entrada relevante.
Na logística, essa porta pode ser um sensor de temperatura, uma câmara, uma impressora industrial, um terminal de expedição, um controlador de climatização ou um equipamento instalado por um prestador.
É aqui que entra o Third-Party Risk Management (TPRM). A empresa deve conhecer não apenas o fornecedor direto, mas também os subcontratados, as plataformas tecnológicas, os serviços cloud, o alojamento e a conectividade que suportam o serviço.
Aos fornecedores devemos perguntar quem tem acesso aos sistemas, se existem contas individuais, se é utilizada autenticação multifator, como são revogados os acessos e que alternativas existem quando a plataforma remota fica indisponível. Também é importante identificar se um incidente no fornecedor pode afetar simultaneamente várias instalações ou clientes.
Mais do que pedir uma certificação ou uma declaração genérica de segurança, é essencial perceber se o fornecedor tem um Plano de Continuidade de Negócio e consegue manter o serviço quando os seus próprios sistemas ou acessos estão comprometidos.
A digitalização permite acompanhar e controlar equipamentos à distância, mas cria novos acessos e “portas de entrada” na operação. Na vossa experiência, o que continua a ficar por tratar entre as equipas de operações, manutenção, compras e informática? Que decisões deveriam tomar em conjunto para reduzir certo tipo de riscos, como este?
A nossa experiência diz-nos que o problema mais frequente é a fragmentação da responsabilidade. Nem todas as organizações são necessariamente assim, mas é muito comum encontrar situações em que o contrato está em compras, a ligação remota é acompanhada pela informática, o equipamento está sob responsabilidade da manutenção, enquanto a operação recebe apenas um alerta quando algo deixa de funcionar. Cada equipa conhece uma parte, mas ninguém tem necessariamente a visão completa.
É assim que podem ficar esquecidos sensores, controladores, câmaras, impressoras industriais, terminais, sistemas de controlo de acessos ou equipamentos instalados temporariamente por um fornecedor. São considerados “menores” porque não parecem essenciais. No entanto, se estiverem ligados à rede, podem permitir o acesso a sistemas mais importantes.
A NIS2 reforça precisamente a necessidade de uma abordagem integrada: gestão de risco, controlo de acessos, resposta a incidentes, continuidade e segurança da cadeia de abastecimento devem ser tratados como partes do mesmo problema.
Para reduzir o risco, as áreas de operações, manutenção, compras, informática, cibersegurança e gestão de risco devem definir em conjunto que dispositivos existem, quem os gere, que acessos têm, que dados transmitem e que impacto teria a sua indisponibilidade. Não sendo um exercício fácil, devem tentar pensar como o ‘atacante’ e procurar todos os pontos de potencial entrada.
Também deve estar definido quem aprova alterações, quem recebe os alertas, quem pode suspender um acesso remoto e quem confirma que é seguro restabelecê-lo. A segmentação da rede é igualmente importante: um sensor ou equipamento de manutenção não deve conseguir comunicar livremente com o WMS, o TMS, sistemas financeiros ou bases de dados de clientes.
O TPRM deve ser um processo contínuo e proporcional ao risco, não apenas uma verificação feita no momento da contratação. Um fornecedor que suporta uma plataforma crítica, que tem acesso remoto a várias instalações ou que depende de uma única infraestrutura tecnológica deve ser acompanhado de forma diferente de um fornecedor sem acesso aos sistemas da empresa.
Na prática, ainda é comum encontrarmos contas partilhadas por técnicos, acessos que permanecem ativos depois de terminada uma intervenção ou alertas enviados para uma caixa de correio que deixa de estar acessível durante o próprio incidente. São falhas completamente evitáveis e que podem ter consequências significativas.
A pergunta não deve ser apenas “o fornecedor é seguro?”. Deve ser também: o que acontece à nossa operação se este fornecedor ficar indisponível ou se os seus sistemas forem comprometidos?
Se um ataque comprometer os equipamentos de frio ou parar um armazém, a empresa pode ter poucas horas para proteger os stocks e assegurar as entregas. O que deve estar definido e testado num plano de continuidade? Pode dar um exemplo de uma falha recorrente que só se torna evidente quando é preciso pôr o plano em prática?
O plano deve responder de forma prática a uma pergunta: se um sistema deixar de funcionar, ou se já não pudermos confiar na informação que apresenta, o que conseguimos continuar a fazer, durante quanto tempo e com que recursos?
No caso dos produtos de temperatura controlada, deve estar definido quem declara o incidente, quem coordena a resposta, como são confirmadas as temperaturas, que produtos ficam em quarentena e quem decide sobre a sua transferência, libertação ou destruição. Deve também existir uma resposta para a falta de capacidade de armazenamento, transporte alternativo ou intervenção técnica local.
O plano deve abranger mais do que a refrigeração. Deve considerar a indisponibilidade do WMS, a paragem de equipamentos de picking, a perda de telemática, a falha dos controlos de acesso ou a indisponibilidade de uma plataforma de expedição ou de elevadores monta-cargas. Deve ainda prever a possibilidade de um sistema continuar ligado, mas apresentar informação incorreta ou executar comandos indevidos.
A continuidade do negócio e a resposta a incidentes são também elementos centrais da NIS2. Mas, na prática, o importante é que o plano funcione, independentemente de a empresa estar ou não diretamente abrangida pelo regime.
Uma falha recorrente só se torna evidente durante um incidente: a empresa deteta que a temperatura subiu, mas não definiu quem pode bloquear o stock, em quanto tempo deve ser tomada uma decisão ou quem autoriza a destruição dos produtos. Outra falha comum é o plano depender exclusivamente de email, no sistema de comunicação (por exemplo Teams) ou sistemas de tickets que podem estar indisponíveis.
Os testes devem envolver as equipas internas e os fornecedores. Um exercício realista poderia simular a indisponibilidade da plataforma de monitorização, a impossibilidade de acesso remoto e a necessidade de decidir, em duas horas, o destino dos produtos. Poderia também incluir a descoberta de um dispositivo aparentemente menor (por exemplo, um sensor ou equipamento de manutenção) com comportamento anómalo na rede.
O objetivo não é apenas confirmar que o plano existe. É verificar se todos sabem quem decide, quem executa, que informação é fiável e como manter a operação até à recuperação segura dos sistemas.
