Descoberta de 56 falhas de dispositivos OT atribuídas à falta de brilho da cultura de segurança PlatoBlockchain Data Intelligence. Pesquisa vertical. Ai.

Descoberta de 56 falhas de dispositivos OT atribuídas à cultura de segurança sem brilho

A cultura de segurança “insegura desde a concepção” é citada na descoberta de dispositivos de tecnologia operacional cheios de bugs.

Os pesquisadores descobriram 56 vulnerabilidades que afetam dispositivos de 10 fornecedores de tecnologia operacional (TO), a maioria das quais atribuíram a falhas de design inerentes aos equipamentos e a uma abordagem negligente à segurança e ao gerenciamento de riscos que têm atormentado a indústria há décadas, disseram eles.

As vulnerabilidades – encontradas em dispositivos de fornecedores de renome Honeywell, Emerson, Motorola, Siemens, JTEKT, Bentley Nevada, Phoenix Contact, Omron, Yogogawa, bem como um fabricante não identificado – variam em termos de suas características e do que permitem que os atores da ameaça façam. de acordo com a pesquisa do Vedere Labs da Forescout.

No entanto, no geral, o “impacto de cada vulnerabilidade depende muito da funcionalidade que cada dispositivo oferece”, de acordo com um post de blog sobre as falhas publicadas terça-feira.

Os pesquisadores dividiram o tipo de falha encontrada em cada um dos produtos em quatro categorias básicas: protocolos de engenharia inseguros; criptografia fraca ou esquemas de autenticação quebrados; atualizações de firmware inseguras; ou execução remota de código por meio de funcionalidade nativa.

Entre as atividades que os agentes de ameaças podem realizar explorando as falhas em um dispositivo afetado estão: execução remota de código (RCE), com código executado em diferentes processadores especializados e em diferentes contextos dentro de um processador; negação de serviço (DoS) que pode deixar um dispositivo completamente offline ou bloquear o acesso a uma determinada função; manipulação de arquivo/firmware/configuração que permite que um invasor altere aspectos importantes de um dispositivo; comprometimento de credenciais permitindo acesso às funções do dispositivo; ou desvio de autenticação que permite que um invasor invoque a funcionalidade desejada no dispositivo alvo, disseram os pesquisadores.

Problema Sistêmico

Que as falhas – que os investigadores apelidaram colectivamente de OT:ICEFALL numa referência ao Monte Everest e à montanha que os fabricantes de dispositivos precisam de escalar em termos de segurança – existam em dispositivos-chave em redes que controlam infra-estruturas críticas por si só já é suficientemente mau.

No entanto, o pior é que as falhas poderiam ter sido evitadas, já que 74% das famílias de produtos afetadas pelas vulnerabilidades possuem algum tipo de certificação de segurança e, portanto, foram verificadas antes de serem enviadas ao mercado, descobriram os pesquisadores. Além disso, a maioria deles deveria ter sido descoberta “de forma relativamente rápida durante a descoberta aprofundada de vulnerabilidades”, observaram.

Este passe livre que os fornecedores de TO têm dado a produtos vulneráveis ​​demonstra um esforço persistente e medíocre da indústria como um todo quando se trata de segurança e gestão de riscos, algo que os investigadores esperam mudar ao lançar luz sobre o problema, disseram eles.

“Esses problemas variam desde práticas persistentes e inseguras desde o projeto em produtos certificados de segurança até tentativas abaixo da média de abandoná-las”, escreveram os pesquisadores no post. “O objetivo [de nossa pesquisa] é ilustrar como a natureza opaca e proprietária desses sistemas, o gerenciamento de vulnerabilidades abaixo do ideal que os cerca e a muitas vezes falsa sensação de segurança oferecida pelas certificações complicam significativamente os esforços de gerenciamento de riscos de TO.”

Paradoxo de Segurança

Na verdade, os profissionais de segurança também notaram o paradoxo da estratégia de segurança negligente dos fornecedores num campo que produz os sistemas que executam infra-estruturas críticas, ataques que pode ser catastrófico não apenas para as redes em que os produtos existem, mas para o mundo em geral.

“Pode-se presumir incorretamente que os dispositivos de controle industrial e de tecnologia operacional que executam algumas das tarefas mais vitais e sensíveis em infraestrutura crítica estariam entre os sistemas mais protegidos do mundo, mas a realidade muitas vezes é exatamente o oposto”, observou Chris Clements, vice-presidente de arquitetura de soluções da Cerberus Sentinel, em um e-mail ao Threatpost.

Na verdade, como evidenciado pela pesquisa, “muitos dispositivos nessas funções têm controles de segurança que são assustadoramente fáceis de serem derrotados ou contornados pelos invasores para assumir o controle total dos dispositivos”, disse ele.

As descobertas dos investigadores são mais um sinal de que a indústria de TO “está a passar por um acerto de contas de segurança cibernética há muito esperado”, que os fornecedores devem abordar em primeiro lugar, integrando a segurança ao nível mais básico de produção antes de prosseguirem, observou Clements.

“Os fabricantes de dispositivos de tecnologia operacional sensíveis devem adotar uma cultura de segurança cibernética que começa logo no início do processo de design, mas continua até a validação da implementação resultante no produto final”, disse ele.

Desafios para a gestão de riscos

Os pesquisadores descreveram algumas das razões para os problemas inerentes ao design de segurança e ao gerenciamento de riscos em dispositivos TO que sugerem que os fabricantes resolvam rapidamente.

Uma delas é a falta de uniformidade em termos de funcionalidade entre os dispositivos, o que significa que a falta inerente de segurança também varia amplamente e torna a solução de problemas complicada, disseram. Por exemplo, ao investigar três caminhos principais para obter RCE em dispositivos de nível 1 por meio de funcionalidade nativa – downloads de lógica, atualizações de firmware e operações de leitura/gravação de memória – os pesquisadores descobriram que a tecnologia individual lidava com esses caminhos de maneira diferente.

Nenhum dos sistemas analisados ​​oferece suporte à assinatura lógica e mais de 50% compilaram sua lógica em código de máquina nativo, descobriram. Além disso, 62% dos sistemas aceitam downloads de firmware via Ethernet, enquanto apenas 51% possuem autenticação para esta funcionalidade.

Entretanto, por vezes, a segurança inerente ao dispositivo não era culpa direta do fabricante, mas sim de componentes “inseguros por conceção” na cadeia de abastecimento, o que complica ainda mais a forma como os fabricantes gerem os riscos, descobriram os investigadores.

“As vulnerabilidades nos componentes da cadeia de fornecimento de TO tendem a não ser relatadas por todos os fabricantes afetados, o que contribui para as dificuldades de gestão de riscos”, afirmaram.

Longo caminho à frente

Na verdade, gerenciar o gerenciamento de riscos em dispositivos e sistemas de TO e TI requer “uma linguagem comum de risco”, algo que é difícil de alcançar com tantas inconsistências entre fornecedores e suas estratégias de segurança e produção em uma indústria, observou Nick Sanna, CEO da Lente de risco.

Para remediar esta situação, ele sugeriu que os fornecedores quantificassem o risco em termos financeiros, o que pode permitir que os gestores de risco e os operadores das instalações priorizem a tomada de decisões sobre “resposta a vulnerabilidades – correção, adição de controlos, aumento de seguros – tudo com base numa compreensão clara da exposição a perdas para tanto de TI quanto de ativos operacionais.”

No entanto, mesmo que os fornecedores comecem a enfrentar os desafios fundamentais que criaram o cenário OT:ICEFALL, enfrentam um longo caminho pela frente para mitigar o problema de segurança de forma abrangente, disseram os investigadores da Forescout.

“A proteção completa contra OT:ICEFALL exige que os fornecedores resolvam esses problemas fundamentais com alterações no firmware do dispositivo e nos protocolos suportados e que os proprietários dos ativos apliquem as alterações (patches) em suas próprias redes”, escreveram. “Realisticamente, esse processo levará muito tempo.”

Carimbo de hora:

Mais de vulnerabilidades