A Kaspersky Lab está desenvolvendo seu próprio sistema operacional? Confirmamos os boatos e acabamos com a especulação!

Olá!

Hoje eu gostaria de falar sobre o futuro. Sobre o não tão interessante futuro de ataques cibernéticos em massa a estações de energia nuclear, instalações de fornecimento de energia e controle de transportes, sistemas financeiros e de telecomunicações e todas as outras instalações tidas como “de extrema importância”. Você se lembra de Duro de matar 4, em que um ataque a uma infraestrutura computadorizada fez com que praticamente o país inteiro mergulhasse no caos?

Pena que John McClane não está por aqui para resolver o problema dos sistemas industriais vulneráveis e, mesmo se estivesse, seus métodos habituais não surtiriam efeito. Então, resta à KL salvar o mundo, é claro! Estamos desenvolvendo um sistema operacional seguro para proteger sistemas de informações-chave (sistemas de controle industrial – ICS) usados na indústria/infraestrutura. Alguns boatos sobre esse projeto já surgiram na internet. Portanto, acho que é hora de falar um pouco sobre nosso projeto secreto e informá-lo um pouquinho sobre o que realmente está acontecendo.

Mas, primeiro, um pouco sobre a história dos sistemas industriais vulneráveis e porque o mundo realmente precisa dessa abordagem nova e completamente diferente adotada por nós.

A indefensabilidade dos sistemas industriais

Embora os sistemas de TI industriais e, digamos, redes de computadores de escritório típicas possam ser parecidos de diversas formas, eles são, na verdade, completamente diferentes, principalmente em termos de prioridades entre segurança e usabilidade. Nas empresas em geral, um dos itens mais importantes é a confidencialidade dos dados e os administradores de TI são encorajados a isolar sistemas infectados de sistemas não infectados, além de outras iniciativas. Assim, por exemplo, se um Trojan for detectado em um servidor de arquivo corporativo, o mais fácil é desconectar o sistema infectado da rede e, posteriormente, começar a lidar com o problema.

Nos sistemas industriais, isso não pode ser feito, pois aqui a prioridade mais alta para eles é manter a operação constante, qualquer que seja a situação. A continuidade da produção é de fundamental importância em qualquer indústria do mundo. A segurança fica em segundo plano.

Outro desafio em proteger um ambiente sempre ativo reside no fato de o software em uma instalação industrial/infraestrutural só ser atualizado após uma verificação completa de tolerância a falhas, para que se tenha certeza de que os processos de trabalho não sejam interrompidos. E como tal verificação requer muito trabalho (e, ainda assim, não dá garantia contra falhas), muitas empresas simplesmente não se incomodam em nunca atualizar o ICS – deixando-o intocado por décadas. A atualização de softwares pode até ser expressamente proibida pela política de segurança de uma organização industrial/infraestrutural. Recentemente, li um artigo ótimo sobre isso, que listava Onze regras de segurança para ICS. A regra nº 1 era: “não toque nele. Nunca”. Preciso dizer mais?

Ainda assim, mesmo se existir a possibilidade de atualizar o software e corrigir falhas na segurança com patches, isso em geral não ajuda muito. Fabricantes de softwares especializados não estão interessados em análises constantes de códigos-fontes e na criação de patches para corrigir falhas. A experiência já mostrou que os orçamentos geralmente são baixos para esse tipo de atividade e os patches são lançados somente se uma determinada exploração for detectada e publicada na internet. Sejamos justos, isso acontece com softwares comuns e não apenas com softwares especializados. Bem, hoje estamos falando especificamente sobre softwares industriais.

O problema consiste no seguinte: a vulnerabilidade dos softwares de controle, controladores programados e redes de comunicação industrial impede os operadores de sistemas industriais/infraestruturais de receber informações confiáveis sobre a operação total do sistema! Teoricamente, a situação a seguir é possível: um sistema de distribuição de eletricidade é atacado e, no outro lado do país, uma instalação sofre um blecaute como consequência desse ataque. Mas, a central de controle não sabe nada sobre isso, já que os invasores enviaram dados falsos para seus computadores.

Exemplos

Não é preciso ir longe para encontrar exemplos desse tipo de situação acontecendo de verdade. O primeiro método usado – um exemplo de sabotagem cibernética mais perigosa – foi um ataque direto aos sistemas SCADA no ano 2000, na Austrália. Um funcionário de uma empresa contratada que estava trabalhando nos sistemas de controle da Maroochy Shire Council realizou 46 (!) ataques em seu sistema de controle, o que fez com que as bombas parassem de funcionar ou funcionassem de forma insuficiente. Ninguém entendeu o que estava acontecendo, pois os canais de comunicação dentro do sistema tinham sido violados e as informações transmitidas estavam distorcidas. Somente depois de meses as empresas e as autoridades conseguiram entender o que havia acontecido. O tal funcionário terceirizado queria um emprego na empresa de tratamento de água e esgoto. Como não foi aceito, decidiu inundar uma área enorme de Queensland com esgoto por vingança!

Existem vários exemplos desse tipo, eles só não são informados na mídia. Afinal, as empresas vítimas geralmente não estão nem um pouco interessadas em deixar que o mundo todo saiba que seus sistemas foram comprometidos (questões de interesse público são abundantes, mas vamos deixar para falar nisso outro dia, em outra postagem…). E em muitos incidentes, nem mesmo as próprias vítimas sabem que foram atacadas. Não faz muito tempo, foi encontrada uma falha na segurança dos roteadores industriais da RuggedCom, que permitiu que um usuário comum simplesmente aumentasse seus direitos de acesso ao nível de administrador e obtivesse controle sobre o dispositivo. Por quem, quando, como e onde essa falha poderia ser explorada não se sabe ao certo. Além disso, quantas falhas semelhantes existem e podem ser exploradas em segredo? Também não temos como saber.

Para se aprofundar no assunto, recomendo a leitura sobre ataques bem-sucedidos a ICSs – aqui, aqui e aqui.

Então, quem mais – além de chantagistas, candidatos rejeitados, entre outros – pode obter acesso ao código-fonte de softwares ICS, controladores, sistemas operacionais etc.? É claro que existem as respectivas autoridades do governo e da indústria, ou seja, aquelas com um departamento que certifica softwares para sistemas de missão crítica. Mas, nos últimos anos, departamentos foram criados para desenvolver armas cibernéticas a fim de atacar sistemas oponentes, independentemente de quais sejam – talvez concorrentes comerciais, mas, em geral, o mais provável é que sejam destinados a outros países.

Estou falando de armas como o Stuxnet e os posteriores Duqu, Flame e Gauss – malwares tão complexos que é óbvio que foram desenvolvidos com o suporte de governos federais. E não importa quem é o alvo no momento, o que importa é que tais armas cibernéticas estão sendo desenvolvidas e implantadas. E depois que a Caixa de Pandora for aberta, não vai ser possível fechá-la novamente. A criação de armamentos para ataques a sistemas industriais e a infraestruturas de inimigos, mais cedo ou mais tarde, afetará a todos nós. Então, a maior ameaça ao planeta hoje vem não da ralé cibernética e nem mesmo dos criminosos cibernéticos organizados, mas sim dos criadores de armas cibernéticas patrocinados por governos federais.

Proteção hoje: infelizmente não é eficiente

Ao mesmo tempo em que se armam, tanto as empresas de infraestrutura quanto as diversas autoridades do governo não estão se esquecendo da proteção. Sem dúvida, elas começaram a se proteger há muito tempo. O que elas fazem de fato?

Existem apenas dois métodos a serem seguidos. O primeiro é isolar objetos de missão crítica: desconectá-los da internet ou isolá-los fisicamente do mundo externo de alguma outra forma. No entanto, como a experiência já mostrou, se um técnico à noite desejar assistir filmes em um pen-drive infectado no computador de controle, nada o impedirá (temos métodos de trabalho para bloquear essa atividade, mas não vou discutir isso aqui).

O segundo é manter segredos. Tentativas coletivas e em larga escala para manter tudo em segredo. Desenvolvedores de ICSs mantêm o código-fonte em segredo, donos de fábricas e infraestruturas adesivam a palavra “SECRETO” em diagramas de informações e sistemas de controle, os tipos de software usados são mantidos em segredo etc. No entanto, ao mesmo tempo, as informações sobre vulnerabilidades na maioria dos sistemas SCADA comuns, por exemplo, estão livremente disponíveis na internet. E se cavarmos mais fundo, descobrimos que o mecanismo de pesquisa SHODAN vem funcionamento a pleno vapor há muitos anos. Ele foi desenvolvido para, entre outras coisas, procurar sistemas industriais vulneráveis (inclusive o SCADA), cujos donos decidiram conectá-los – ou se esqueceram de desconectá-los – à internet.

Paralelamente, especialistas em organizações industriais e de infraestrutura também aplicam métodos tradicionais de proteção a softwares e sistemas operacionais vulneráveis por meio do controle do comportamento de programas e das ações dos usuários. Uma proteção 100% segura não é garantida, novamente por causa da vulnerabilidade padrão do software que faz o controle. Porém, para uma infraestrutura de missão crítica, a garantia é o mais importante de tudo.

Proteção como deve ser

O ideal seria reescrever todos os softwares ICS, incorporando-se todas as tecnologias de segurança disponíveis e levando-se em conta as novas realidades dos ataques cibernéticos. Infelizmente, tal esforço colossal combinado a investimentos altíssimos, que seriam necessários para os testes e ajustes, não garantiriam a operação suficientemente estável dos sistemas.

Mas, existe uma alternativa possível: um sistema operacional seguro no qual o ICS possa ser instalado e que possa ser incorporado à infraestrutura existente, controlando sistemas existentes “saudáveis” e garantindo o recebimento de relatórios de dados confiáveis sobre a operação do sistema.

Primeiro, vou fazer a pergunta mais óbvia: como seria possível para a KL criar um sistema operacional seguro se ninguém na Microsoft, Apple ou na comunidade de código-fonte foi capaz de proteger totalmente seus respectivos sistemas operacionais? É tudo bem simples, na verdade.

Primeiro: nosso sistema é altamente adaptado, desenvolvido para solucionar uma tarefa específica e não para jogar Half-Life, editar vídeos de férias ou tagarelar em mídia social.

Segundo: estamos trabalhando em métodos de escrita de software cujo design não permitirá realizar nenhuma atividade não declarada, por trás dos panos. Esta é uma parte importante: a impossibilidade de executar código de terceiros, invadir o sistema ou executar aplicativos não autorizados em nosso sistema operacional. E isso já foi testado e comprovado.

Você pode ler mais detalhes sobre o sistema, seus requisitos e histórico de desenvolvimento aqui.

Para terminar, antecipando as diversas perguntas de colegas, parceiros, mídia e curiosos, o básico: o desenvolvimento é um ambiente verdadeiramente seguro. É um projeto sofisticado e quase impraticável sem a interação ativa com operadores e fornecedores de ICS. Não podemos revelar muitos detalhes do projeto agora devido à confidencialidade de tal cooperação. E não queremos falar sobre alguns tópicos para que os concorrentes não critiquem nossas ideias e roubem o know-how. Alguns detalhes ficarão disponíveis para sempre apenas para determinados clientes, para nos proteger contra abusos de terroristas cibernéticos. Assim que possível, informaremos mais detalhes sobre o projeto.

Até a próxima!