A tecnologia operacional em IoT industrial não tolera patching no estilo TI. “Análise de ameaças” é uma solução segura e poderosa

Falando sobre a Internet das Coisas Industrial - (IIoT). A tecnologia operacional na Internet das coisas industrial (IoT) não pode tolerar patching no estilo de TI. Usar a “análise de ameaças” é uma solução segura e poderosa. Dentro das empresas e em todo o ecossistema global da IIoT - é uma fusão negociada e intrincadamente entrelaçada de TI e OT. Os sistemas OT não são apenas críticos para os negócios, eles podem ser críticos para o país ou para a vida ou morte.

Cada cliente industrial da Internet das coisas (IIoT) com quem falo deseja a segurança mais forte possível. Não é a internet das coisas - internet das coisas industrial (IIoT).

Quem dentro da organização do cliente executará e será o proprietário deste processo? Em reunião após reunião com clientes que criam recursos de IIoT, encontro uma incerteza natural, mas às vezes tensa, entre os profissionais de TI e OT / LOB no que diz respeito à segurança de IIoT.

Esta incerteza capital - é ela própria - uma vulnerabilidade de segurança porque atrasa a implementação de segurança essencial.

Uma pesquisa recente da Forrester com líderes de TI e OT / LOB mostrou os gerentes de TI e OT igualmente divididos sobre se TI ou OT é responsável pela segurança, de acordo com DARKReading da InformationWeek. Como resultado alarmante desse impasse, relata a Forrester, um número inaceitavelmente grande de empresas - 59 por cento - estão dispostas a "tolerar riscos de médio a alto em relação à segurança de IoT".

Acredito que seja incorreto e errado as empresas permitirem que essa negligência continue - além de ser perigoso para todas as suas operações.

Considere as diferenças entre TI corporativa e OT:

• Disponibilidade :
  A TI considera 99 por cento de tempo de atividade aceitável, enquanto OT requer 99,999 por cento de tempo de atividade - a diferença entre 8,76 horas e 5,25 minutos de tempo de inatividade anual.
  • Vida do sistema :
  Os sistemas de TI são atualizados, em média, a cada três a cinco anos. Os sistemas OT, por outro lado, duram de 10 a 15 anos.
  • Correção :
  Patches / atualizações de TI podem ser feitos sempre que houver atualizações disponíveis, mas correções / atualizações de OT podem interromper as operações industriais estratégicas e geradoras de receita.

Existem muitas outras diferenças de TI / OT - como abordagens variadas para a nuvem.

No entanto, todas as diferenças são subsumidas pela necessidade universal de segurança IIoT mais resiliente disponível.

Uma abordagem que eu defendo é ajudar as empresas industriais a usar as lições de TI duramente conquistadas e conquistadas por muito tempo para saltar para um estado avançado de segurança IIoT. IIoT é habilmente arquitetado e implantado para atender aos requisitos diferenciados da OT. Alguns acreditam que os sistemas OT são outra forma de data center, o núcleo fortemente protegido da TI corporativa.

Existem algumas ideias promissoras que podem ser adaptadas após décadas de experiência em TI. Usando essas ideias e, em seguida, adicionando-as para fornecer novos níveis de segurança IIoT, ao mesmo tempo que respeita as necessidades específicas da OT. Entre essas adaptações estão a separação de redes de ponto final, microssegmentação e análise de comportamento do usuário (UBA). Discutirei isso em artigos futuros.

Com patching , TI e OT falam idiomas diferentes. Insira “análise de ameaças”.

Entendemos que o processo de patching visa atualizar, corrigir ou melhorar um programa de software. Normalmente uma solução rápida - e muitas vezes uma solução aleatória, ainda por cima. Quando se trata de patching, no entanto, uma porta direta da prática diária de TI para OT nem sempre é viável.

Quando se trata de patching, TI e OT falam idiomas diferentes.

É essencial que o setor de IIoT - TI e OT se unam para o benefício de suas empresas. Isso exigirá pensar mais profundamente e com mais imaginação para desenvolver técnicas robustas de segurança cibernética. Por necessidade, essas operações precisarão ser mais ágeis e eficazes do que o patching reflexivo.

Os patches podem criar problemas para OT. Como estamos vendo com os patches para as vulnerabilidades de CPU Meltdown e Spectre, às vezes um patch pode piorar as coisas. Os primeiros patches para Meltdown e Spectre impactaram o desempenho de todo o sistema.

A dura verdade é que o ponto fraco da economia industrial moderna são, em grande parte, as velhas máquinas OT. No mundo da TI, se algo está infectado, o primeiro instinto é desligá-lo rapidamente e corrigir (ou substituí-lo). Mas em OT, muitas vezes o oposto é verdadeiro:mantenha-o instalado e funcionando.

Alguns sistemas OT cruciais estão no chão de fábrica por 15 a 25 anos ou mais. Esses bebês não podem ser facilmente retirados e remendados. Mesmo se um patch apropriado estivesse disponível - esses sistemas geralmente não têm memória ou largura de banda de CPU suficiente para aceitar patches.

Finalmente, há o problema da relativa complexidade e fragilidade dos sistemas OT em comparação com os sistemas de TI.

Os sistemas de TI podem ser desativados, corrigidos e reiniciados para fornecer serviço idêntico. A TI pode operar racks carregados com servidores idênticos e, se um falhar ou queimar, o próximo da fila assume sem problemas. Mas os sistemas OT são frequentemente combinações altamente orquestradas de software e hardware que têm "personalidades".

Mesmo quando as empresas podem desligar as máquinas para aplicação de patches - quando elas voltam a funcionar - os resultados podem ser imprevisíveis. Não é o mesmo sistema porque o patch introduziu curingas que podem proliferar por meio de outros elementos do sistema.

Em OT, a imprevisibilidade não é aceitável.

Resultado: deve haver uma maneira melhor de proteger os sistemas IIoT do que patchear reflexivamente OU ignorar uma ameaça à segurança porque o patch simplesmente não é viável - por todos os motivos que acabei de descrever.

A MELHOR FORMA:“ANÁLISE DE AMEAÇAS”

A melhor abordagem em OT é examinar os desafios de segurança de uma maneira muito mais granular do que atualmente. Proponho que usemos a antiga abordagem de análise de ameaças para patching.

Primeira etapa na análise de ameaças:

Não tome qualquer ação imediata. Isso significa evitar o patching, não patching, nada mais. Espere um segundo até validarmos se uma vulnerabilidade do sistema realmente existe - e se existe - como ela pode ser explorada?

Existem vários fatores a serem considerados.

Alguns sistemas que operam dentro das empresas podem de fato ter vulnerabilidades. Como o sistema está muito isolado dentro da empresa, o risco de segurança real é menor do que o risco de desligar os sistemas para correção - supondo que exista um patch.

O cálculo muda ao avaliar os sistemas expostos à nuvem ou à Internet - é onde o risco à segurança é obviamente muito maior.

Análise de ameaças:

Análise de ameaças: identificaria rapidamente quais sistemas provavelmente podem continuar operando sem patches e quais sistemas precisam ser interrompidos para o patch.

Análise de ameaças: também validaria uma vulnerabilidade. É importante fazer outra pergunta:se esta vulnerabilidade pode ser explorada por certas ameaças, há uma maneira de impedir isso sem patching ?

Por exemplo, especialistas em segurança podem criar um conjunto de scripts pré-determinados na rede ou no próprio dispositivo de endpoint. Isso ajudaria a identificar a resposta apropriada a uma série de ameaças diferentes. Esses scripts serviriam como um modelo “se / então” para formalizar, automatizar e acelerar respostas a ameaças. O ponto é pensar com mais sofisticação do que um patch binário / decisão de não aplicar patch.

As empresas de software devem apoiar o desenvolvimento da análise de ameaças, informando aos clientes mais sobre os patches que lançam. As principais informações que gostaríamos de ver são como as vulnerabilidades podem ser exploradas e as possíveis maneiras de protegê-las.

Essa transparência extra daria aos clientes mais informações para tomar decisões sobre os movimentos de segurança certos para os sistemas afetados. Os especialistas em segurança precisam ter certeza de que um patch irá, no mínimo, manter o mesmo nível de risco que existia antes de uma vulnerabilidade ser descoberta.

Análise de ameaças: deve ser extremamente granular. Se uma empresa tiver 100 dispositivos em execução, cada um exigirá sua própria análise de ameaças, que incluiria uma comparação de vulnerabilidades e benefícios do patch, bem como um “menu” resultante de opções de segurança.

O objetivo principal, é claro, é aumentar a segurança e, ao mesmo tempo, maximizar o tempo de atividade do OT.

Análise de ameaças: é mais sutil e multidimensional do que as decisões de patching go / no-go.

Mas há um desafio que a indústria deve resolver para ir de onde estamos até onde devemos estar:agora, seguir o processo descrito acima leva tempo, custa dinheiro, requer profissionais altamente qualificados - e mesmo assim, não é fácil de fazer.

A comunidade de fornecedores precisa começar a agir de acordo com um conjunto de padrões acordado. Precisamos de padrões e, possivelmente, de legislação sobre como os relatórios e as vulnerabilidades de abordagem serão tratados. Significado - não encoberto. Todo este processo pode ser automatizado.

O que funcionou tão bem em TI simplesmente não se encaixa no OT.

É hora de inovar em todo o setor, além da escolha entre patch, patch, patch - ou permitir que sistemas sem patch rodem vulneráveis.

Nosso objetivo deve ser construir processos poderosos e eficazes e, em seguida, automatizar eles para colocar esta nova abordagem. Tudo isso pode estar ao alcance de empresas industriais e nações em uma base global.

Só porque podemos ver esse futuro melhor claramente não significa que ele está próximo.

Mas vamos começar agora a chegar lá, juntos.