Transformando dados públicos em conhecimento público: Nos bastidores do relatório semestral de Claroty

Já se passaram três anos desde que comecei a examinar as vulnerabilidades do sistema de controle industrial (ICS). O que começou com meu chefe dizendo: "Reúna alguns dados e vamos ver o que descobrimos", transformou-se em uma infraestrutura de raspagem automatizada que nos permitiu inspecionar o panorama geral das vulnerabilidades de dispositivos industriais expostos nos principais setores. Compartilhar nossa pesquisa e conhecimento sempre foi o objetivo final e, com dados e conclusões suficientes reunidos, a Claroty's Relatório Bianual de Risco e Vulnerabilidade de ICS nasceu.

Aprendi muito no decorrer desse projeto e, agora, depois de escrever quatro relatórios semestrais, achei que era hora de compartilhar algumas informações dos bastidores sobre o processo que criamos, na esperança de que isso ajude outras pessoas em suas respectivas abordagens de coleta e análise de dados e enfatize a importância de compartilhar conhecimento para o benefício da comunidade.

Vamos começar do início e lembrá-lo de que a próxima versão do relatório, que abrange as vulnerabilidades do primeiro semestre de 2022, estará disponível em agosto.

Comece tornando-o útil

Como eu disse acima: tudo começou quando meu chefe me pediu para coletar alguns dados sobre vulnerabilidades de ICS e ver o que eu tinha a dizer sobre isso. Mas, verdade seja dita, eu não tinha certeza, desde o início, de quais dados eu deveria coletar para ter algo significativo a dizer. Portanto, a primeira pergunta (para mim mesmo) foi: O que alguém gostaria de obter dos dados que estou coletando e analisando? Tendo isso como guia desde o início, eu tinha certeza de uma coisa: eu precisava dar às pessoas algo útil para ler, caso contrário, qual seria o objetivo?

Para isso, tive que criar informações acionáveis que fossem relevantes para a comunidade de ICS, independentemente de o usuário ser um fornecedor, CISO, pesquisador, analista ou operador de OT. Portanto, o trabalho não era para trazer novas ideias e conceitos para o mundo, mas sim para pintar um quadro o mais completo possível do cenário de vulnerabilidade do ICS com base em dados e para fornecer recomendações. O quadro completo tem o objetivo de ajudar a entender o risco decorrente dessas vulnerabilidades e as etapas para gerenciá-las, abordando assuntos como mitigações, correções, gravidade da exploração bem-sucedida e muito mais.

Com isso em mente, concentrei minha pesquisa nas seguintes questões centrais:

1. Que conclusões podem ser tiradas dos dados disponíveis publicamente sobre as vulnerabilidades de ICS divulgadas em um determinado período?

2. Quais são os desafios que essas vulnerabilidades representam para aqueles que precisam corrigir ou atenuar esses sistemas?

3. O que pode ser feito para gerenciar melhor os riscos e as vulnerabilidades de segurança nas redes ICS com relação às conclusões e aos desafios encontrados?

Depois de ter uma ideia melhor do que eu queria fazer com esse projeto, comecei a procurar dados que pudesse usar. Começando com duas fontes públicas - o National Vulnerability Database (NVD) e o ICS-CERT -, desenvolvi rastreadores que coletaram todos os CVEs relacionados a ICS e seus detalhes relevantes, incluindo a pontuação de gravidade do CVSS, quaisquer CWEs (Common Weakness Enumerations) envolvidas e os pesquisadores que divulgaram as vulnerabilidades. Nos relatórios semestrais que se seguiram, novas fontes de dados foram adicionadas e os rastreadores coletaram mais dados, como produtos afetados, disponibilidade de correções e atenuações e muito mais.

É claro que o trabalho não foi concluído nesse ponto, porque, embora todos esses dados estejam acessíveis publicamente, isso não significa que estejam disponíveis para serem usados por todos. Nem todo mundo tem os recursos, a capacidade ou o tempo para coletá-los, inspecioná-los como um todo e analisá-los. Isso faz com que muitos analistas de segurança tenham que examinar listas de divulgações de vulnerabilidades sem poder se beneficiar delas. Essa é a lacuna que o relatório semestral pretendia resolver: Transformar esses dados disponíveis publicamente em conhecimento público disponível para todos.

Um exemplo de filosofia semelhante é o trabalho de Dan Ricci, fundador do ICS Advisory Project. Ricci, que já trabalhou em uma grande empresa de consultoria, realizou avaliações de risco para fabricantes de produtos químicos. Ele logo percebeu que os operadores de ativos e os gerentes de rede estavam tendo dificuldades para manter a conscientização sobre as vulnerabilidades do sistema de controle. Combine essa falta de conscientização com uma equipe de segurança cibernética pouco treinada - um cenário comum na maioria dos fabricantes de pequeno e médio porte - e as empresas geralmente ficavam em desvantagem.

"Achei que seria ótimo poder fornecer um artefato que pudesse facilmente fornecer a eles uma maneira de filtrar os produtos do fornecedor de ICS para seu ambiente", explicou Ricci.

O projeto hospeda vários painéis interativos que os usuários podem filtrar por fornecedor, produto, pontuação CVSS, setor de infraestrutura crítica ou CWE (Common Weakness Enumeration). O painel visualiza as informações de consultoria; as consultorias são coletadas de várias fontes e oferecem aos usuários um local único para informações sobre vulnerabilidades.

Alimento para reflexão e etapas para ação

Quando terminavam de coletar dados de várias fontes, os rastreadores processavam, mesclavam e armazenavam esses dados para análise futura. Quando chegava a hora de escrever o relatório semestral, eu examinava os volumes de dados e começava a analisar, procurando tendências e informações úteis para destacar. 

Ao fazer isso, às vezes é fácil esquecer que nem tudo é igualmente importante de ser mencionado. Pensar de outra forma geralmente cria uma bagunça para os leitores, pois é fácil para qualquer pessoa se perder em meio a todos os dados, e não fica claro quais são as conclusões. Portanto, como regra geral, geralmente é melhor escolher algumas tendências principais e enfatizá-las, por exemplo, em um resumo executivo ou em um webinar dedicado.

Para criar conhecimento significativo e percepções acionáveis, apenas contar as vulnerabilidades e identificar as tendências de crescimento não foi suficiente. Contextualizar essas divulgações é importante porque, caso contrário, não conseguiremos fornecer uma compreensão profunda dos riscos que essas vulnerabilidades representam para as redes ICS. 

Um bom exemplo foi a constatação de que abordar as vulnerabilidades apenas pela pontuação CVSS não seria suficiente. O modelo de pontuação do CVSS foi criado tendo em mente as redes de TI e não a TO, onde as prioridades são diferentes (por exemplo, a integridade dos dados não é tão importante na TO quanto a disponibilidade ou a segurança). Por esse motivo, dividimos as pontuações do CVSS em seus diferentes componentes e adicionamos informações de CWE (Common Weakness and Enumeration, fraqueza e enumeração comuns), sabendo que as ramificações das explorações que levam a ataques de negação de serviço ou execução remota de código são mais importantes do que outras e devem ser enfatizadas independentemente da pontuação de criticidade. 

Como dissemos anteriormente, apenas contar e classificar as vulnerabilidades por tipo e gravidade não é suficiente. Qual é a utilidade dessas informações se não forem complementadas com conselhos acionáveis sobre mitigações ou informações de aplicação de patches. Esse é o tipo de informação que é crucial para um analista de centro de operações de segurança ou operador de TO ao traçar estratégias sobre tempo de inatividade aceitável e atualizações de sistema. 

Continuamos a usar a palavra mitigação separadamente de correção, e por um bom motivo. Ficou evidentemente claro, com base nos dados e no que sabemos no setor, que os patches de software e as atualizações de firmware nem sempre são aplicados imediatamente. Os patches devem ser testados quanto à regressão para saber se há algum problema de compatibilidade com os aplicativos existentes; não queremos que um patch interrompa um processo que está sendo executado sem problemas! 

As atualizações de firmware são outro desafio. Elas levam mais tempo para serem desenvolvidas e, uma vez disponíveis, não são triviais para serem implementadas em todos os locais, muitos dos quais podem estar em diferentes regiões geográficas ou em locais de difícil acesso. 

Claramente, as atualizações nos ambientes de TO são muito diferentes das redes de TI. Na maioria das vezes, os operadores recorrem a uma espécie de atenuação como um paliativo até que uma janela de atualização funcione em toda a empresa ou até que um patch ou atualização de firmware seja disponibilizado por um fornecedor afetado. Às vezes, esse aspecto do gerenciamento de vulnerabilidades também é prejudicado por informações incompletas fornecidas em um aviso de fornecedor ou de um CERT. Esse é o verdadeiro valor do nosso exercício de dados: mostrar o sucesso que seus colegas estão tendo com as atenuações e como você pode aplicá-las em seus ambientes. 

Entendemos que nem todo mundo que lê nosso relatório é uma pessoa técnica atrás de um teclado ou com os olhos em uma HMI o dia todo. O relatório semestral oferece uma importante combinação de insights técnicos e estratégicos que moldam não apenas as decisões operacionais cotidianas, mas também as estratégicas de longo prazo. É uma honra elaborar esse relatório e é emocionante ver o surgimento de novas tendências e confirmar que as mais antigas ainda têm alguma validade. A missão da Team82 é tornar os setores industrial, de saúde e comercial mais seguros, melhorando a segurança, a disponibilidade e a confiabilidade dos sistemas em setores críticos. O relatório semestral é apenas uma de nossas contribuições, mas é importante, e esperamos que você continue lendo.