Malware Ripple20 destaca desafios de segurança industrial
As más práticas de segurança permitiram que as vulnerabilidades do software se propagassem em produtos industriais e de IoT por mais de 20 anos.
A recente descoberta de 19 vulnerabilidades em uma biblioteca leve de TCP / IP gerou ondas de choque em todos os setores, pois expõe milhões de organizações a ataques cibernéticos em potencial. Conhecidas como Ripple20, essas vulnerabilidades foram encontradas em uma biblioteca lançada pela primeira vez na década de 1990.
As vulnerabilidades variam em gravidade, mas algumas podem permitir que um invasor controle um dispositivo afetado remotamente ou causar problemas de disponibilidade. O número de sistemas afetados foi estimado em centenas de milhões, e os produtos afetados incluem “dispositivos domésticos inteligentes, equipamentos de rede elétrica, sistemas de saúde, equipamentos industriais, sistemas de transporte, impressoras, roteadores, equipamentos de comunicação móvel / satélite, data center dispositivos, dispositivos de aeronaves comerciais, várias soluções empresariais e muitos outros. ”
Obviamente, todos se perguntaram em voz alta como essas vulnerabilidades poderiam existir em tantos produtos e passar despercebidas por mais de 20 anos. No entanto, não estou surpreso com a situação. As más práticas de segurança implementadas em sistemas de controle industrial (ICS) e na Internet das Coisas (IoT) contribuíram para como vulnerabilidades como as descritas na pesquisa Ripple20 se propagam em tantos produtos.
Compreendendo o risco e a qualidade do software em ICS Os produtos de
vários fabricantes de ICS, incluindo várias marcas e modelos de controladores lógicos programáveis (PLCs) e fabricantes de interface homem-máquina (IHM), são projetados principalmente com segurança e disponibilidade em mente. A confiabilidade dos PLCs é excepcional – os sistemas ICS podem ser implantados em instalações de produção por décadas e ainda funcionar corretamente.
A segurança é projetada em todos os sistemas ICS em um nível físico, não apenas em um nível lógico. Isso me leva ao tópico de risco no que se refere à maioria dos sistemas de controle industrial.
Embora existam certas indústrias onde a segurança pode ter implicações catastróficas do mundo real, como o setor de energia nuclear e outras infraestruturas críticas, a grande maioria dos sistemas ICS não tem essas considerações extremas para enfrentar. A realidade para a maioria das fábricas é que há risco financeiro presente no que diz respeito às questões de segurança: processos podem sofrer interferências para interromper a produção, produtos podem ser contaminados se o processo for alterado de maneiras específicas ou IP pode ser roubado na forma de receitas, fórmulas e detalhes de processos proprietários.
É importante compreender corretamente os riscos que um processo pode enfrentar devido a possíveis problemas de segurança, sem exagerar. Embora possam surgir problemas de produção que afetam a qualidade do produto, esses problemas serão identificados durante o processo de QA. Os fabricantes têm processos em vigor para detectar problemas, investigá-los, descartar lotes contaminados, limpar equipamentos ou consertar o problema e, em seguida, retomar a produção. Embora esse processo possa ser caro, não é necessariamente terrível.
Um problema comum enfrentado por integradores de sistemas é ser forçado a usar software proprietário de baixa qualidade. Embora os próprios PLCs sejam projetados e construídos para serem extremamente robustos e confiáveis, o mesmo não pode ser dito para outros softwares lançados por esses fabricantes. Ao trabalhar com alguns dos softwares de qualidade mais baixa, não é incomum ter vários travamentos por dia ao usar o software conforme planejado.
TI versus OT
Como a disponibilidade é crítica para os sistemas ICS e os próprios sistemas podem ser frágeis e peculiares, geralmente são responsabilidade das equipes de tecnologia operacional (OT). A equipe de tecnologia da informação (TI) geralmente gerencia a rede corporativa. Os funcionários da OT estão familiarizados com a tecnologia de processo e os sistemas que gerenciam, mas geralmente não sabem muito sobre segurança da informação, o que pode levar a implantações inseguras.
Uma situação bastante comum para os fabricantes é uma divisão, às vezes conflituosa, entre a equipe de TI e OT dentro de uma empresa.
Os funcionários da OT não querem que a equipe de TI adultere seus sistemas por medo do tempo de inatividade que pode custar à empresa. Pelo que vimos, esses relacionamentos geralmente se assemelham às atitudes da equipe vermelha versus a equipe azul em muitas organizações. A equipe azul pode se ressentir dos esforços da equipe vermelha porque esses esforços criam mais trabalho para a equipe azul e podem ser considerados uma crítica ao seu trabalho.
Os funcionários da OT frequentemente também não querem consultar seus colegas de TI ao fazer arranjos como acesso remoto, levando a situações como RDP em redes de controle comumente expostas à Internet pública. As equipes de TI e OT estão na mesma equipe e precisam educar-se mutuamente e capacitar-se a atingir seus objetivos e mandatos.
Garantindo a segurança do produto no ICS
Os setores de ICS / IoT enfrentam muitos dos mesmos desafios que as lojas tradicionais de desenvolvimento de software. No entanto, existem desafios únicos em ICS / IoT, onde os dispositivos podem ser implantados por décadas e podem precisar da instalação de sistemas legados sem correção na rede para suportá-los. A substituição imediata de um componente legado pode não existir e a reengenharia do processo para acomodar um componente mais moderno, juntamente com as perdas financeiras decorrentes do tempo de inatividade para concluir as atualizações, pode ter um custo proibitivo.
Da mesma forma, existem desafios com o gerenciamento da cadeia de suprimentos. Os fabricantes que integram componentes de terceiros em seus produtos podem não saber se algum de seus componentes individuais contém bibliotecas vulneráveis. A falta de segurança básica e princípios de codificação seguros na educação de desenvolvedores significa que eles geralmente não estão cientes dos pontos fracos de segurança. As faculdades e universidades têm a responsabilidade de treinar desenvolvedores para produzir software seguro da mesma forma que precisam para garantir que os alunos de engenharia possam projetar uma estrutura que não desmorone.
Cada uma dessas questões precisa ser abordada sistematicamente se quisermos ver um aumento na segurança dos dispositivos incorporados que controlam grande parte do nosso entorno, muitas vezes despercebido, em segundo plano. Embora prevenir essas vulnerabilidades seja o ideal, ter uma maneira de rastrear componentes de terceiros potencialmente vulneráveis em produtos é uma obrigação para facilitar a aplicação de patches e outros esforços de correção.
