1

O VÍRUS STUXNET E A SEGURANÇA DAS REDES DE AUTOMAÇÃ O INDUSTRIAL

José Carlos Faial jcfaial@gmail.com

http://infrasecurity.wordpress.com

ABSTRACT This paper presents the recent findings about the Stuxnet virus, the first malware ever

discovered that was specifically designed to target industrial control systems. The Stuxnet’s unique characteristics are discussed and used to demonstrate that current state of cybercontrols applied to industrial control systems networks were insufficient to protect those systems.

The work, also present an introduction to some ISA99 standard guidelines and requirements for industrial network protection and how they can be used to provide better security against malicious threats such Stuxnet and future variants.

RESUMO Este artigo apresenta uma discussão sobre os possíveis impactos que a recente descoberta

vírus Stuxnet, o primeiro vírus de computador especificamente escrito para atacar sistemas de automação industrial, pode ter sobre a forma como a segurança das redes que suportam estes sistemas é feita atualmente. As principais iniciativas de proteção das redes industriais com foco apenas na construção de perímetros com o ambiente corporativo se mostraram ineficazes no caso do Stuxnet. As características gerais, os fatos conhecidos e principais hipóteses sobre seu propósito e forma de funcionamento são apresentados.

O trabalho também apresenta a norma ISA99 e como um programa de segurança baseado nesta norma pode diminuir o dano causado por malwares como o Stuxnet Palavras chaves : Norma ISA99, Segurança de Redes, Firewalls, Stuxnet, antivírus. 1 INTRODUÇÃO

Já não é mais novidade que a segurança das redes de automação industrial viraram foco de especial atenção. Após os atentados terroristas do 11 de setembro, governos, principalmente o americano, acordaram para os riscos potenciais de um ataque em larga escala contra sua infraestrutura crítica nacional (água, energia, telecomunicações básicas, óleo e gás, transporte e outros serviços fundamentais). Um dos possíveis cenários levantados pelos especialistas é o de um ataque visando as redes e sistemas digitais de automação e controle que suportam esta infraestrutura. Composta basicamente por tecnologias que priorizam o desempenho de processamento em tempo real, a alta confiabilidade contra falhas e a garantia da proteção do processo industrial, da planta, do meio ambiente e das pessoas (safety), estes sistemas carecem dos controles e recursos de segurança (security) básicos para rodar em ambientes de conectividade abertas. Abertura esta, cada vez mais comum, devido a necessidade de integração das informações do processo com sistemas de informações corporativos e movida também, pela necessidade de otimização de custos, através do compartilhamento dos enlaces de telecomunicações entre os ambientes corporativo e industrial.

Estas vulnerabilidades contribuíram para a ocorrência de alguns incidentes, na sua maioria não direcionados especificamente para o sistema de automação, mas que ainda assim causaram grande impacto nos processos industriais. No entanto, recentemente, pesquisadores de empresas antivírus descobriram um novo vírus ativo na Internet, escrito especificamente com o propósito de invadir redes de automação baseados numa plataforma de software para controle de redes SCADA fornecido pelo fabricante Siemens. A descoberta iniciou pronto debate sobre as características e propósitos do vírus, levando a algumas hipóteses e considerações. O vírus foi batizado Stuxnet, e a forma como ele se propaga é feita principalmente através de mídias removíveis, como os comuns pen-drives, ao invés da rede de dados, como é feito pela maioria dos vírus conhecidos.

O conceito de rede de automação é amplo e complexo, envolvendo diversas tecnologias e camadas de comunicação. Ela compreende os protocolos e infraestrutura de campo, os barramentos de comunicação com os dispositivos que compõe o processo, como sensores e atuadores, bem como

2

protocolos de camada mais alta, para transmissão de dados em longa distância, telemetria, supervisão e controle remotos. Como o escopo deste trabalho discute os riscos associados a ameaças provenientes da Internet e redes de dados corporativas, baseadas no protocolo TCP/IP com predominância do Ethernet, deve ser entendido que o termo “redes de automação industrial” utilizado neste artigo considera apenas os segmentos da rede de automação que se utilizam destas tecnologias.

Na parte 1.1 deste trabalho é apresentado um breve resumo histórico dos principais incidentes de segurança da informação que afetaram redes de automação. No item 1.2 é discutido como estes eventos foram abusados pela mídia não especializada e por pseudo especialistas com uma falsa percepção sobre como estes ambientes funcionam, de forma a inflamar as discussões sobre o tema de segurança de redes industriais, geralmente atrapalhando e divergindo o foco correto e sensato deste tema. Na parte 2 é apresentado os fatos a cerca do descobrimento do vírus Stuxnet, sua forma de funcionamento, fatos conhecidos e como ele deve mudar a postura em relação a forma como a segurança das rede de automação vem sendo feitas. Também são apresentadas algumas hipóteses para sua origem. Por fim, na parte 3 é apresentada a norma ISA99, como um resumo da sua utilização da redução de riscos e impactos causados por vírus como o Stuxnet.

1.1 BREVE RESUMO DOS PRINCIPAIS INCIDENTES ENVOLVEN DO SISTEMAS DE AUTOMAÇÃO

Diversos incidentes de segurança da informação, afetando sistemas de automação, tornaram-se

públicos ao longo dos últimos anos, contribuindo para aumentar a sensibilização para o problema da vulnerabilidade destes ambientes e acelerando o desenvolvimento e uso das normas e melhores práticas pelas empresas. No entanto, é fato que os incidentes de maior divulgação pública não se enquadram especificamente no que se poderia classificar como um ataque digital direcionado contra um sistema de automação. Observe na tabela 1 abaixo, que dos principais incidentes divulgados, apenas os dois primeiros podem ser considerados um ataque direcionado especificamente e com o propósito de se atingir a rede de automação. Nos demais casos, vemos que a rede de automação foi afetada por um evento aleatório, não direcionado especificamente para o processo.

Principais incidentes de segurança da informação co m impacto sobre sistemas de automação Evento Ano Descrição Direcionado

Maroochy Shire Sewage Spill 2000

Um ex-empregado de uma organização Australiana que desenvolve software para automação industrial, aplicou para uma vaga de emprego com o governo local e foi rejeitado. Como vingança, o empregado rejeitado utilizou-se de transmissores de radio para, num período de dois meses, realizar 46 invasões remotas aos controladores de uma estação de tratamento de esgoto. Ele alterou os dados de uma estação de bombeio, causando mal funcionamento na sua operação e lançando cerca de 264.000 galões de esgoto sem tratamento diretamente em rios e parques próximos a estação

SIM

Worcester Air Traffic

Communications 1997

Um adolescente de Worcester, Massachusetts, desabilitou parte da rede de telefonia pública (PSTN) utilizando uma conexão dial-up através de um modem conectado ao sistema. Este evento desabilitou as linhas da torre de controle, segurança do aeroporto, brigada de incêndio, serviço meteorológico e empresas aéreas do aeroporto. Além disso, o ataque desabilitou o transmissor de rádio principal da torre, bem como outro transmissor que ativa as luzes de pouso da pista. Também foram impactadas

SIM

3

cerca de 600 residências e empresas na cidade vizinha.

CSX Train Signaling System

2003

O worm SOBIG foi considerado culpado por desativar os sistemas de sinalização ferroviário da costa leste dos EUA. O worm contaminou os computadores da empresa CSX Corp, responsável pela operação e controle desta malha.

NÃO

Davis-Besse 2003

A agência reguladora de energia nuclear americana confirmou que o worm SQL Slammer, que afeta servidores de banco de dados Microsoft SQL Server, comprometeu uma rede privada na usina Davis-Besse, em Oak Harbor, desabilitando o sistema de EMS (emergency shutdown) por cerca de cinco horas. O worm também afetou a comunicação de toda a rede de automação e controle, deixando os controladores da planta incomunicáveis por cerca de seis horas.

NÃO

Northeast Power Blackout 2003

Falha no processador de alarmes da rede SCADA da companhia First Energy, impediu que os operadores tivessem informações adequadas sobre as condições operacionais do grid elétrico. Como conseqüência, não foi possível detectar e ativar contramedidas para impedir que um problema iniciado numa das linhas de transmissão se propagasse para as demais, provocando um efeito cascata. A falha do sistema de alarmes foi causada por um vírus que afetou o servidor da aplicação.

NÃO

Bellingham, Washington

Gasoline Pipeline Failure

1999

Cerca de 237.000 galões de gasolina vazaram de um duto, incendiando-se cerca de uma hora e meia depois. O incêndio causou a morte de 3 pessoas. A falha no duto foi atribuída a incapacidade dos operadores do sistema SCADA de realizar suas funções de monitoração e controle, devido a baixa performance e resposta do sistema, que impediu os controladores de receber as informações adequadas sobre as condições do duto e da falha

NÃO

Tabela 1 Com o surgimento do vírus Stuxnet, esta lista ganha um novo membro, que inaugura também

uma nova categoria de ataques contra os sistemas de automação: o ataque automatizado. Enquanto que os dois eventos direcionados da tabela acima foram executados manualmente por um invasor, contando até mesmo com informações internas sobre estes sistemas, o caso do Stuxnet é totalmente automatizado. Desde a forma de propagação até os ataques utilizados para invadir o sistema, tudo foi desenvolvido para encontrar automaticamente um alvo específico.

O caso deste vírus gerou grande furor na mídia. Sites e jornais anunciaram um vírus capaz de tomar o controle da infraestrutura crítica de uma nação, criando um verdadeiro Armageddon digital. Parte deste medo vem do pouco ou nenhum conhecimento sobre o funcionamento de uma rede de automação por parte dos indivíduos que produzem estas matérias.

1.2 A FALSA PERCEPÇÃO DA MÍDIA E PÚBLICO EM GERAL S OBRE A SEGURANÇA DAS REDES DE AUTOMAÇÃO

4

Os processos geograficamente distribuídos, como ocorre principalmente com a arquitetura SCADA, são considerados mais susceptíveis a ataques, basicamente por conta dos métodos de comunicação de longa distância com a RTU e/ou slave empregados nestes ambientes, onde é comum o uso de redes públicas de transmissão, como a rede de telefonia pública – tanto na sua forma tradicional quanto mais recentemente na forma de celulares – bem como através de enlaces via Internet e rádios padrão WIFI (IEEE 802.11). Um diagnóstico da segurança destas redes foi realizado pelo INL (Idaho National Laboratory) para o Department of Energy dos Estados Unidos, compreendendo cerca de 21 (vinte e um) ambientes de automação, tanto de empresas públicas quanto privadas, que confirmou a larga presença de vulnerabilidades nestas redes.

Desta forma as redes SCADA vem recebendo muito mais atenção do que o ambiente DCS, mas no entanto é incorreto afirmar que uma arquitetura é mais ou menos vulnerável do que a outra, pois sabemos que nenhuma planta é idêntica e cada processo guarda características únicas que requerem análises individuais. Complicando a comparação, as tecnologias de PLC e RTU modernos apresentam certa sobreposição, pois encontramos PLCs com função de RTU e vice versa disponíveis no mercado. O foco no SCADA parece estar mesmo no fato da mídia não especializada ser incapaz de distinguir as tecnologias, adotando o termo “SCADA” como um nome genérico para tudo que significa automação e controle industrial.

Percebemos esta característica em trabalhos como “How to take down the Power Grid”, do colunista do site Internet Evolution, Ira Winkler; da apresentação “SCADA System Fuzzing” apresentada por Ganesh Devarajan na conferência LayerOne 2007 e “SCADA - Fear, Uncertainty, and the Digital Armageddon”, apresentado por Morgan Marquis-Boire na conferência hacker Defcon 16, além de outros facilmente encontrados através da pesquisa de conjuntos de termos como “scada, attacks, security, vulnerability” na sua ferramenta de buscas on-line de preferência.

São trabalhos que extrapolam as conseqüências de um incidente de segurança da informação em redes SCADA, de modo a criar uma situação de semi ou total catástrofe. As contribuições hollywoodianas de filmes como “Duro de Matar 4.0” ajudam a criar a falsa impressão que as redes de automação não possuem nenhum mecanismo de segurança para preservar a integridade e confiabilidade do processo. Mesmo possuindo vulnerabilidades reais, como mostra o relatório do INL, qualquer processo é modelado com segurança (safety), confiabilidade e desempenho em mente. Estes trabalhos e publicações parecem ignorar que:

• Que os processos são continuamente monitorados pelos operadores, que podem atuar de

forma a prevenir uma situação indesejada; • Que os operadores, de forma análoga aos pilotos de aeronaves, são treinados através de

simuladores que também exercitam a sua atuação em situações de risco ou funcionamento anormal do processo;

• Que os controladores possuem lógicas de intertravamento do processo, atuando de forma a impedir uma operação ou situação que leve a um determinado ponto crítico de risco;

• Que os processos críticos, aqueles com potencial de impacto e conseqüências sérias, possuem sistemas SIS/EMS (Safety Instrumented System / Emergency Shutdown System), em paralelo e de forma independente da rede de controle principal, que atua também de forma a prevenir uma situação de alto risco;

• E que podemos contar ainda com os botões de pânico, estrategicamente posicionados para permitir o acionamento manual pelo pessoal presente na planta.

É certo que incidentes como os apresentados na Tabela 1 nos leva a pensar que as salvaguardas apresentadas na lista acima são ineficazes. Na verdade, nenhum processo possui risco zero e mesmo com todos os cuidados, problemas podem ocorrer. Só não é possível aceitar a afirmação de que tais problemas são triviais e comuns. Tais incidentes possuem sim, alto potencial para impactar a lucratividade do processo industrial, mas deste ponto a outro onde teríamos uma situação de catástrofe nacional existe uma grande distância.

2 O VÍRUS STUXNET

Concretizando algumas previsões, uma fabricante de software antivírus russa chamada VirusBlokAda encontrou na rede de alguns clientes um novo vírus. Batizado de Stuxnet, o que chamou a atenção dos pesquisadores da empresa era que o vírus utilizava-se de uma vulnerabilidade até então desconhecida, que afetava todas as versões do sistema operacional Windows da Microsoft. Mais tarde, denominada MS10-46 Vulnerability in Windows Shell Could Allow Remote Code Execution

5

(Shortcut Icon Loading Vulnerability - CVE-2010-2568), a vulnerabilidade impressionou pelo fato de não ser necessária a execução manual de nenhum programa ou clique de link por parte dos usuários, bastando que a pasta com um arquivo contaminado fosse visualizada para que a infecção ocorresse, de forma silenciosa. Os pesquisadores também identificaram que uma vez executado, o vírus instala dois rootkits no sistema, ocultos na forma de drivers de dispositivos de hardware do fabricante Realtek Semiconductor Corp. Para assegurar o disfarce, o vírus utiliza um certificado digital aparentemente válido do fabricante. O método principal de propagação do vírus é através de pen-drives infectados, porém o mesmo pode utilizar outros vetores de propagação. 2.1 A DESCOBERTA DA RELAÇÃO ENTRE O STUXNET E A AUT OMAÇÃO INDUSTRIAL

Não foi de imediato que os pesquisadores perceberam a relação do vírus Stuxnet com as redes

de automação industrial. Apenas após engenharia reversa do seu código, realizada pelo pesquisador Frank Boldewin, que o assunto veio a tona. Ele postou num fórum on-line a seguinte mensagem (http://www.wilderssecurity.com/showthread.php?p=1712146):

Figura 1 – Mensagem anunciando uma possível relação entre o Stuxnet e o Sistema WinCC da Siemens Que traduzindo e simplificando quer dizer: “Olá, alguém já deu um olhada detalhada neste malware? Decriptando o código, encontrei coisas

como esta aí embaixo <código>. Isto, para mim, aponta para o sistema Siemens WinCC SCADA. Parece que este vírus foi feito para espionagem.”

O código encontrado pelo pesquisador mostra como o vírus se utiliza de um recurso de

programação embutido no produto da Siemens, para ganhar credenciais de acesso com privilégios irrestritos ao sistema. O recurso de programação utilizado, onde as credenciais de acesso estão codificadas dentro do próprio programa é considerado uma vulnerabilidade, por permitir que uma inspeção neste código revele estas credenciais e com isso, ganhar acesso ao banco de dados.

6

A partir deste ponto o Stuxnet passa da condição de um mais um simples malware, como dezenas de outros descobertos diariamente, para uma condição de destaque e grande divulgação. Os fabricantes afetados, Siemens e Microsoft atuaram com velocidade para orientar seus clientes e oferecer soluções de contorno, enquanto novas análises e soluções definitivas estavam sendo desenvolvidas.

Testes iniciais mostraram que o vírus tentava copiar os dados dos projetos encontrados no computador infectado para um servidor na Internet. Não foi encontrados indícios de que o vírus realizasse qualquer tipo de alteração nos dados do projeto ou nos controladores. Esse fato foi associada a divulgação feita pela Siemens de que o vírus havia sido encontrado em alguns de seus clientes, porém em nenhum dos casos se apresentou qualquer anomalia no processo, e diminuiu o alarde feito pela mídia em torno do Stuxnet.

2.2 FATOS CONHECIDOS SOBRE O VÍRUS O desenvolvimento do código do Stuxnet demonstra uma grande e raramente encontrada

habilidade. A análise de outros vírus mostra que em geral, não é feito muito esforço na qualidade de seu desenvolvimento. A razão para isso é que vírus comuns, de larga propagação possuem um tempo efetivo de sucesso pequeno, pois devido ao grande número de usuários afetados, os fabricantes de antivírus rapidamente disponibilizam vacinas. Dessa forma, há um entendimento de que o investimento na qualidade do software não é um investimento interessante. No caso do Stuxnet, esta premissa se mostrou falsa. Não só, do ponto de vista de técnicas de engenharia de software não do propósito, o Stuxnet é inaugura novo patamar na qualidade de desenvolvimento de um vírus de computador:

• Os vírus mais comumente encontrados hoje na Internet são desenvolvidos através de “kits”

adquiridos ilegalmente em sites e fóruns controlados por grupos criminosos. Tais “kits” possuem um leque limitado de possibilidades de exploração de falhas na máquina alvo, para ganhar acesso ao sistema. Como a descoberta de novas falhas é um processo complexo e difícil, eles se utilizam de falhas já conhecidas e amplamente divulgadas;

• O Stuxnet não só faz uso de uma vulnerabilidade inédita, como divulgado inicialmente, mas sim de 04 (quatro) novas vulnerabilidades desconhecidas e sem correção. Estima-se que uma vulnerabilidade ainda sem correção pelo fabricante (chama-se 0-day na gíria de segurança), que afeta sistemas operacionais de ampla utilização seja avaliada em milhares de dólares no mercado negro;

• O Stuxnet é silencioso, trabalhando de forma a não impactar o desempenho da máquina, o que poderia chamar a atenção de um administrador atento;

• Ele procura por uma planta com PLC ou grupo de PLCs com parâmetros específicos e dados de projeto únicos. Se ele perceber que está rodando no computador errado, fora do alvo, ele não faz absolutamente nada. Isso mostra que o desenvolvimento do vírus levou em conta informações internas e privilegiadas sobre o seu alvo;

• Faz varreduras na rede para encontrar outras máquinas contaminadas e uma vez encontradas, constrói uma rede P2P (peer-to-peer) entre elas, permitindo que instruções enviadas pelo seu controlador sejam repassadas de máquina em máquina;

• Usando a rede P2P criada, permite que sejam distribuídas atualizações para outras máquinas, adicionando novas funcionalidades e caracteríticas;

• Instala-se como um driver de dispositivo assinado digitalmente, através da chave privada de um popular fabricante de periféricos e hardware;

• O Stuxnet não ameaça executar uma sabotagem, como faria um grupo criminoso com intenções de extorsão, uma vez no local correto, ele faz a sabotagem sem ameaçar.

• Não se espalha de forma indiscriminada, não usa as máquinas contaminadas para construir uma botnet;

• Não rouba senhas, logins e nem cartões de crédito. São todas características impressionantes, que se estima terem demandado longo tempo de desenvolvimento, recursos humanos altamente especializados e uma coordenação de projeto de qualidade. Isso leva algumas especulações, discutidas no item a seguir.

7

2.3 ESPECULAÇÕES AO REDOR DO VÍRUS Dada tamanha atenção, dezenas de pesquisadores de vírus se lançaram a novas e mais

detalhadas análises. A cada nova descoberta, foi aumentando a especulação de que o Stuxnet é um vírus desenvolvido por algum órgão de algum governo, como “arma” digital para atacar algum alvo militarmente selecionado.

Foi através de um destes testes que o pesquisador Ralph Langner publicou através do seu logbook de 16 de setembro de 2010, uma hipótese totalmente especulativa em suas próprias palavras, de que o alvo do vírus Stuxnet seria o programa nuclear Iraniano. Ele usou como base o discrepante número de registro de máquina infectadas no Irã e nos demais países onde a empresa responsável pelo comissionamento da usina possui outros projetos. Veja no gráfico abaixo, extraído do site da Symantec:

Figura 2 – Gráfico da distribuição da indidência do Stuxnet Além deste gráfico, o pesquisador correlacionou notícias sobre alguns atrasos no projeto

causados por problemas operacionais, não perfeitamente identificados. Essa teoria levou a outras, e mais evidências vem sendo adicionadas: foram encontradas

algumas strings no código do vírus que nos faz associá-lo com o Estado de Israel. A palavra “myrtus” aparece no código e estaria relacionada a Rainha Ester, também conhecida como “Hadassah” que na língua hebraica significa exatamente “myrtus”. A outra string “19790509” seria decodificada como uma data relacionada a execução, pelo governo do Irã, de um cidadão Israelense por alegações de espionagem.

A discussão mais recente, e aparentemente melhor fundamentada, cruza as datas de surgimento

e disseminação inicial do Stuxnet, com uma série de defeitos e o declínio no número de centrífugas na planta de enriquecimento de urânio de Natanz, conforme gráfico extraído do jornal Financial Times, feito com dados publicados pela AIEA:

8

Fato ou especulação, a realidade é que o Stuxnet, neste momento, também está sendo estudado

e dissecado por criminosos. Deste estudo, as suas habilidades de desenvolvimento irão se aperfeiçoar e o que é pior, o Stuxnet “ensina” a estes invasores a como executar rotinas de comunicação com os PLCs, tanto através das bibliotecas do sistema S7 quanto diretamente. Ao dominar estas rotinas, estes invasores poderão construir vírus com a capacidade de “bypass” de qualquer barreira ou restrição imposta pelo sistema supervisório ao se comunicar diretamente com o PLC.

3 COMO A NORMA ISA99 PODE AJUDAR

Diante das vulnerabilidades identificadas para os sistemas de automação e do crescente aumento das ameaças, várias entidades governamentais e organizações privadas, iniciaram o desenvolvimento e divulgação de melhores práticas, diretrizes e normas de segurança da informação herdados do ambiente de TI, mas que pudessem ser adaptadas e aplicadas às características únicas dos ambientes de automação. Sendo uma das ações mais conhecidas o “Energy Policy Act” americano, que obriga as empresas de energia conectadas ao seu grid a respeitarem padrões de qualidade e confiabilidade no seu fornecimento. A lei autorizou também a criação de uma agência auto-reguladora da confiabilidade, a NERC (North American Energy Reliability Corporation) assumiu este fim. As empresas ligadas ao sistema bulk elétrico devem respeitar e seguir, efetivo desde o dia 18 de Junho de 2007, a 83 novos padrões de confiabilidade com risco de sofrerem penalidades que podem chegar a 1 milhão de dólares por dia. Dentre os vários padrões, alguns se referem especificamente à segurança da informação das redes de automação. São eles:

• CIP-002-1 Critical Cyber Asset Identification • CIP-003-1 Security Management Controls • CIP-004-1 Personnel & Training • CIP-005-1 Electronic Security Perimeter(s) • CIP-006-1 Physical Security of Critical Cyber Assets • CIP-007-1 Systems Security Management • CIP-008-1 Incident Reporting and Response Planning • CIP-009-1 Recovery Plans for Critical Cyber Asset

Com destaque também para os padrões e requerimentos para os serviços de telecomunicações: COM-001-1 Telecommunications.

Estes requerimentos legais geraram uma grande busca por parte das empresas, por padrões e soluções de tecnologia que atendessem tais requisitos, objetivando a conformidade legal. Com isso, diversas normas de segurança da informação, como a já consagrada série ISO 2700x (antiga ISO 17799) que trata do ambiente de TI, foram adotadas como base para o desenvolvimento de um

9

programa de segurança. Como esta série ISO foi desenvolvida para o ambiente de TI, ela possui diversos requisitos incompatíveis com um ambiente de automação industrial, como a necessidade de se adotar protetores de tela protegidos por senhas em todas as máquinas, só para citar um requisito bem simples com grande impacto, por exemplo, nas estações de HMI. Diante destas incompatibilidades, diversos órgãos iniciaram (já antes mesmo do CIP NERC) o desenvolvimento de recomendações, normas e diretrizes, voltadas para características do seu setor, como as apresentadas na tabela abaixo:

Organização Documento Setor

AGA AGA 12 Gás Natural API Standard 1164 – Pipeline SCADA Security Petróleo e Gás

API Security Guidelines for the Petroleum Industry, 3ed

Petróleo e Gás

CIDX Guidance for Addressing Cybersecurity in the Chemical Sector Químico

IEEE IEEE 1402 - Guide for Electric Power Substation Physical and Electronic Security

Energia

NIST SP800-53 - Recommended Security Controls for Federal Information Systems Vários

NIST SP800-82 - Guide for SCADA and ICS Security Vários Tabela 2 – Padrões e normas de segurança da informa ção para redes industriais

Diante do pouco alinhamento entre as normas de segurança da informação com as

características do ambiente de automação industrial e com os requisitos legais e a consagrada ISO 2700x, a ISA iniciou o desenvolvimento da norma SP99, atualmente denominada ISA99. A norma ISA99, denominada “Security Guidelines and User Resources for Industrial Automation and Control Systems”, se propõe a estabelecer critérios e contramedidas sólidas para o desenvolvimento e implementação de um programa de segurança da informação efetivo para as redes de automação. A ISA99 considera como base conceitual que um programa de segurança efetivo é função de uma equação onde são considerados “Tecnologias de Segurança de TI apropriadas”, “Expertise em Segurança de Redes e Sistemas” e “Expertise no Domínio de Automação Industrial”:

Figura 3 – Bases da ISA99

O desenvolvimento da ISA99 conta com mais de 260 profissionais de mais de 200 empresas, e

no seu atual estágio de desenvolvimento vários produtos (ou partes) já foram publicados, tendo sofrido ampla adoção por parte das empresas. A tabela abaixo apresenta os documentos que a compõem:

Tecnologias de Segurança de TI Adequadas,

Expertise em Segurança de Sistemas,

Expertise em Automação Industrial

Segurança Efetiva dos Sistemas de Automação =

f (

)

10

Figura 4 – Estrutura de componentes da ISA99 © ISA Não é escopo deste trabalho realizar uma análise de cada componente da norma, nem apresentar todas as suas características e requisitos, mas sim destacar alguns pontos importantes que podem ser usados para diminuir os risco do impacto de malwares como o Stuxnet. Um dos fatores que deve ser levado em consideração na construção de tais contramedidas, e entender que o ambiente de automação industrial está sofrendo mudanças drásticas nas tecnologias utilizadas, com forte predomínio de padrões abertos de TI, como por exemplo:

• HMI via web está se tornando uma opção padrão, cada vez mais comum;

• Comunicações sem fio, em diversas formas, mas com grande adoção do padrão IEEE 802.11;

• Protocolos multimídia e convergência de voz e vídeo já estão presentes em muitas plantas de automação, com grande adoção de câmeras inteligentes de vídeo para monitoração da planta e do processo;

• Uso de redes de celulares, com destaque para aplicações móveis, via smartphones;

• O Linux já começa a aparecer como opção para sistema operacional embutido em controladores e outros dispositivos, com expectativa de rápida adoção pelo mercado;

• Uso de Autoridades Certificadoras (CA) e Certificação Digital, através de ambientes de PKI usando protocolo x.509 como requisito fundamental para a nova versão do protocolo OPC, o OPC UA (unified architecture);

• Diversidade de vetores para propagação de vírus e outros malwares, com destaque para proliferação de infestações via pen-drives e outras mídias removíveis;

• Exploração de vulnerabilidades nos componentes de TI para ganhar acesso aos componentes de automação, como no caso do vírus Stuxnet.

11

Outra abordagem importante é tentar eliminar alguns mitos que tornam ainda mais difícil realizar a segurança da rede de automação, sendo um dos mais comuns a afirmativa de que todos os sistemas de automação industrial não podem ter recursos de antivírus ou outros agentes de segurança. O correto é afirmar que máquinas que desempenham funções críticas, com necessidades de processamento em tempo real, com poucos recursos de memória e CPU ou que utilizam sistemas operacionais de legado, não podem rodar tais agentes de segurança, como IPS de host e antivírus, mas que nem todos os componentes da automação se enquadram nessa definição, e mesmo por isso, fabricantes tradicionais como a ABB, EMERSON, OSIsoft e Honeywell já homologaram e recomendam uso de antivírus para diversos de seus produtos. Mesmo com a possibilidade de se adotar algumas soluções de tecnologia de segurança da informação para alguns componentes da rede automação, as exceções, ou seja, onde estas tecnologias não podem ser adotadas, referem-se exatamente ao que é mais crítico dentro da planta, como os controladores e estações de supervisão, por exemplo. Dessa forma, a única opção é adotar mecanismos de segurança da informação em outras camadas, sendo a rede que transporta os dados dos sistemas de automação, o lugar ideal para sua implementação. A ISA99 faz uso desta abordagem para estabelecer o conceito de Zonas e Conduítes. 3.1 ZONAS E CONDUÍTES Uma característica básica da ISA99, é que um sistema é composto por diversos elementos com características de segurança distintos com níveis de criticidade com potenciais de baixo a alto impacto. Por exemplo, um controlador lógico programável, dependendo da sua função na planta pode ter o potencial de prejudicar o processo de forma que o mesmo tenha que ser suspenso, porém tais componentes carecem de recursos mais avançados de segurança, para suportar, por exemplo, um simples port-scan sem travar ou perder a comunicação com a rede IP. Por outro lado, podemos encontrar na mesma rede de automação hosts rodando versões completas de um servidor WEB, que com a configuração adequada são bastante seguros, mas que não possuem a criticidade do PLC, nem o mesmo potencial de causar impactos na planta. É uma discrepância. Mesmo que a situação acima pareça dois extremos, é possível encontrar componentes com grau de criticidade semelhantes, mas distintos recursos de segurança. Como exemplo, podemos citar uma estação de engenharia rodando Windows NT (desatualizado, altamente vulnerável a ataques) e outra com Windows XP ou até mesmo Windows 7, mais robustos e atualizados. Levando os exemplos do host para rede, é comum encontrar numa rede de automação ambientes de rede sem fio, que são reconhecidamente inseguras sem as devidas configurações de segurança; algumas redes possuem mecanismos de acesso remoto externo, para suporte ou monitoração dos fornecedores; conexões com redes externas via satélite, celular ou linha discada para telemetria ou operação remota dos dispositivos. Se considerarmos o papel e criticidade que um PLC pode desempenhar, não podemos considerar que é seguro conectá-lo sem o devido cuidado no mesmo segmento de rede onde há presença de pontos de acesso wireless abertos, ou mesmo outros hosts que não desempenham o mesmo papel no processo e podem ser fontes de ataques dentro da própria rede de automação. Por isso a ISA99 considera que os elementos que compreendem a rede de automação devem receber alguns atributos de classificação, de modo a diferenciá-los de acordo com sua criticidade e potencial de impacto. Uma vez que esta diferenciação seja feita, a norma propõe que eles sejam alocados de forma segregada, agrupando aqueles de atributos semelhantes, e implementando mecanismos seguros para garantir que o fluxo de dados entre eles ocorra de forma eficiente. O item 4.3.3.4 da ISA-99.02.01 estabelece (tradução adaptada para melhor simplificação e entendimento): 4.3.3.4 Elemento – Segregação de Rede Objetivo: Agrupar e separar elementos chave do sistema de automação dentro de zonas com nível de proteção de segurança necessário para o gerenciamento dos riscos associados a estes elementos. Requisito 4.3.3.4.1: uma estratégia de contramedidas empregando a segmentação da rede em zonas de segurança deve ser desenvolvida para os elementos do sistema de automação, baseando-se no risco a que estão sujeitos cada um destes elementos. Com este objetivo, a ISA99 estabeleceu dois componentes que formam a base estrutural da norma. Eles são chamados ZONAS e CONDUÍTES.

12

ZONA: Conforme item 3.2.116 da ISA–99.00.01–2007, a zona é um agrupamento de elementos lógicos ou físicos do sistema de automação, que compartilham os mesmos requisitos de segurança. CONDUÍTE: O item 3.2.27 define o conduíte como um grupo lógico de recursos de interconexão que protegem a comunicação e fluxo de dados entre duas zonas com requisitos de segurança distintos. Uma zona possui limites e bordas bem definidas, e a sua política de segurança deve ser garantida por controles no seu interior, ou nestas bordas. A figura abaixo ilustra este conceito:

Figura 5 – Exemplo lógico de zonas e conduítes Na figura acima, duas zonas lógicas concentram os hosts HMI e os controladores industriais. Como estes componentes possuem recursos e requisitos de segurança da informação diferentes, para garantir uma comunicação segura entre estas zonas, é aplicado um conduíte. A classificação de um componente dentro de uma zona leva em consideração alguns atributos, dentre eles o Security Level Target e o Security Level Capability. 3.2 SECURITY LEVELS Cada zona possui um atributo chamado Security Level Target (SLT) baseado na criticidade e potencial de impacto (conseqüência) que seus componentes possuem. Este atributo define o nível de segurança que se deseja para esta zona. Da mesma forma, para que um componente possa estar presente numa determinada zona, com um SLT específico, ele deve possuir os requisitos de segurança adequados para satisfazer os requerimentos desta zona. Assim, cada componente dentro de uma zona possui um atributo chamado Security Level Capability (SLC). Para que os objetivos de segurança sejam atingidos, estes componentes (assets) e sua respectiva zona devem possuir atributos com o mesmo valor. Se eles não forem iguais, então, deve ser adicionando recursos de tecnologia de segurança da informação. Voltando as analogias, se compararmos os recursos de segurança encontrados num PLC em relação aos mesmos atributos de um host HMI de supervisão baseado numa configuração adequada do Windows, podemos observar que o primeiro possui um SLC menor do que o segundo, mas se levarmos em conta a criticidade e potencial de impacto, o PLC deve ser conectado a uma zona com SLT maior. Dessa forma, para que ambos possam se comunicar é necessário o uso de um conduíte que irá ajustar o valor destes atributos, adicionando contramedidas para compensar o SLC menor do PLC ao mesmo tempo que permite ao HMI que está numa zona com SLT menor acessar a zona do PLC. Com as políticas adequadas, o conduíte irá proteger o PLC contra um ataque proveniente da máquina HMI, caso a mesma seja comprometida de alguma forma. Numa aplicação prática, poderíamos ter uma situação semelhante a da figura abaixo:

Zona HMI

Zona Controladores

Conduíte

13

Figura 6 – Exemplo de um firewall como conduíte. © I SA

Num programa de segurança baseado na ISA99, deve-se ir além destes exemplos, dando uma classificação mais detalhada da rede de processos e identificando de maneira mais adequada seus requisitos de segurança da informação e estabelecendo-se um modelo de hierarquia para a planta industrial com base na norma ISA95. Aplicando-se este modelo de hierarquia, tornam-se mais visíveis as bordas e interfaces das distintas áreas do sistema de automação, permitindo melhor identificação e classificação das áreas críticas e seus respectivos critérios de segurança da informação.

Figura 7 – Modelo padrão de hierarquia de níveis co nforme ISA95. © ISA Uma descrição detalhada de cada nível apresentado na figura está presente na primeira parte da norma, ISA-99.01.01. A principal estratégia deste modelo é estabelecer mais camadas de proteção, isolando os componentes mais críticos nas camadas inferiores, estabelecendo bordas entre eles e controlando a comunicação e o acesso. As melhores práticas da ISA99 estabelecem, no mínimo, a

14

segregação entre as camadas 3 e 4, e a criação de uma DMZ entre elas e as camadas inferiores. Uma DMZ é uma área da rede de transição, onde são colocados hosts utilizados como meio de transporte ou compartilhamento confiável de informações entre zonas distintas, permitindo o fluxo de informações ao mesmo tempo em que a comunicação direta entre estas zonas é bloqueada. O uso de firewalls para criação desta segregação de rede é a forma mais comum utilizada atualmente, devido a sua longa trajetória de adoção em ambientes de TI e grande variedade de opções no mercado. Essas facilidades, no entanto, não escondem certas dificuldades, como complexidade de definição das regras de acesso necessárias para refletir os requisitos do negócio, manutenção da “saúde” do equipamento (desempenho, capacidade, disponibilidade etc), e incompatibilidade com alguns protocolos de automação industrial, principalmente com o OPC, que possui uma natureza difícil para o modo de funcionamento dos firewalls. Outra fonte de preocupação dos administradores das redes de automação é com a possibilidade de que erros de configuração possam expor o processo às ameaças da rede corporativa ou pior, impedir o fluxo de dados necessários para o funcionamento do processo. É fato que uma regra de acesso incorretamente configurada por alguém com pouco conhecimento sobre firewalls pode permitir a comunicação total entre estas redes ou impedir que dados importantes cheguem ao seu destino. Por isso a ISA99 estabelece que os firewalls ou outras tecnologias de segurança da informação para redes, uma vez instalados como conduítes, sejam alvo de várias rotinas formais de administração e monitoração, garantindo a gestão da mudança, a análise dos riscos de uma nova regra e a pronta recuperação em casos de falhas. Os desenvolvedores de firewalls vêm continuamente dotando seus produtos de capacidades específicas para atender os requisitos da automação industrial, como é o caso de suporte nativo, na camada de aplicação, dos protocolos OPC, Modbus e DNP3, além de outros. O hardware também vem sofrendo adequações e é possível encontrar firewalls rodando em appliances padrão industrial de diversos fabricantes, com suporte a condições hostis de temperatura, poeira, vibrações e umidade. É importante destacar, no entanto, que apesar do exemplo mais fácil para ilustrar o conceito de conduíte seja o firewall, ele não é o único modo de se implementar tal recurso. Um conduíte pode ser uma VPN IPSec (rede privada virtual com criptografia dos dados), um gateway antivírus de rede, um IPS (Intrusion Protection System) de rede, além de outras tecnologias de segurança. O mais importante na adoção do modelo de zonas e conduítes é considerar que o mapeamento de das políticas de acesso deve ser feito com muito cuidado e testes, de modo que uma regra incorretamente configurada não possa impactar o correto funcionamento da planta. É mandatório que o processo industrial tenha um comportamento bem definido e as prioridades que tem a sua segurança (safety) e desempenho não sejam ser interrompidas pela instalação de nenhum dispositivo. 4 CONCLUSÃO É certo que talvez, a aderência a norma ISA99 ou a qualquer outra norma de segurança da informação, esteja fora dos objetivos da maioria dos gestores das unidades de automação industrial no Brasil hoje. Sem a pressão pela conformidade legal a que estão sujeitas as americanas, as empresas brasileiras tem buscado por soluções de segurança por consciência própria, ou pelo fato de já terem sido impactadas por algum incidente no passado. O caso do vírus Stuxnet, trás a tona o nível de fragilidade destas redes e sistemas, em relação as ameaças de segurança da informação: mesmo completamente isoladas ao nível de rede, o Stuxnet foi capaz de se instalar em diversas redes de automação ao redor do mundo, usando para isso um simples mecanismo de propagação baseado em mídias removíveis. Alertando-nos também para a forma como a segregação entre as redes de automação e corporativa vem sendo feita. E o entendimento principal que deve ser feito disso, é que se deve reconhecer que a rede de automação não deve ser encarada como um único, constante e simples barramento de rede, mas sim um ambiente crítico, complexo e com diversos requisitos diferentes de segurança da informação. Por outro lado, esse entendimento pode levar a interpretação errônea de que a ISA99 recomenda a separação total e indiscriminada da rede na forma da instalação de firewalls nos seus diversos segmentos. Na verdade, o que a ISA99 prega é que o perímetro das bordas seja bem construído, posicionado no lugar correto, separando aquilo que merece e precisa ser separado, ou seja, não é

15

quantidade de zonas e conduítes que irá tornar uma rede de automação mais segura, mas sim a sua correta definição, através da aplicação dos critérios e atributos de segurança para cada zona. . Na área de segurança da informação existe uma afirmativa, que já virou clichê, que diz o seguinte “a segurança é o inverso da comodidade”. Encontrar o balanço entre os dois é um desafio, por isso a tecnologia deve ser uma ferramenta flexível e adaptável e as normas, apenas uma base para nortear os caminhos e servir de referência na escolha das tecnologias e mecanismos mais adequados para cada ambiente. Excluindo-se o exagero sensacionalista da mídia não especializada, é fato que o Stuxnet inaugura uma nova realidade para o potencial de danos que futuros malwares poderão causar nas redes de automação. Por isso, é importante que os gestores iniciem o quanto antes uma avaliação dos riscos para os seus processos e suas plantas, e preparem suas redes e sistemas de modo garantir melhores contramedidas para mitigar estes riscos.

.

5 REFERÊNCIAS BIBLIOGRÁFICAS G.Ericsson, “Towards a Framework for Managing Information Security for an Electric Power Utility – Cigré Experiences,” Paper TPWRD-406- 2006 published in IEEE Transactions on Power Delivery, Vol. 22, No. 3, July 2007, pp. 1461-1469. R. Carlson, J. Dagle, S. Shamsuddin, and R. Evans, “A Summary of Control System Security Standards Activities in the Energy Sector,” Office of Electricity Delivery and Energy Reliability U.S. Department of Energy, October 2005. V. Igure, S. Laughter, and R. Williams, “Security issues in SCADA networks,” Computers & Security 25, (2006) 498 – 506. ISO/IEC, “Information technology — Security techniques — Code of practice for information security management,” International Organization for Standardization, International Electrotechnical Commission, ISO/IEC 17799:2005, 2005. ISO/IEC,” Information technology – Security techniques – Information security management systems – Requirements,” International Organization for Standardization, International Electrotechnical Commission, ISO/IEC 27001: 2005. Department of Homeland Security (DHS), “Catalog of Control Systems Security: Recommendations for Standards Developers,” DHS, January 2008 DHS, “Cyber Security Procurement Language for Control Systems,” DHS, August 2008 ISA, “ANSI/ISA–99.00.01–2007 Security for Industrial Automation and Control Systems Part 1: Terminology, Concepts, and Models,” International Society of Automation (ISA), October 2007 ISA, “ANSI/ISA-TR99.00.01-2007 Security Technologies for Industrial Automation and Control Systems,” International Society of Automation (ISA), October 2007 ISA, “ANSI/ISA—TR99.00.02—2004 Integrating Electronic Security into the Manufacturing and Control Systems Environment,” International Society of Automation (ISA), October 2004 K. Stouffer, J. Falco, K. Scarfone, “Guide to Industrial Control Systems (ICS) Security Special Publication 800-82,” Second public draft, National Institute of Standards and Technology, September 2007. GAO, “Technology Assessment - Cybersecurity for Critical Infrastructure Protection,” U.S. Government Accountability Office, May 2004. AGA, “Cryptographic Protection of SCADA Communications Part 1: Background, Policies and Test Plan (AGA 12, Part 1),” American Gas Association (AGA), March 2006. CPNI, “Good Practice Guide, Process Control and SCADA Security,” Centre for the Protection of National Infrastructure (CPNI), 2005.

16

DOE, “21 steps to Improve Cyber Security of SCADA Networks,” Office of Energy Assurance, U.S. Department of Energy, 2002. NERC, “CIP-001-1 - CIP-009-1,” North American Electric Reliability Corporation (NERC), 2006. NIST, “System Protection Profile - Industrial Control Systems,” Version 1.0, National Institute of Standards and Technology (NIST), April 2004. Internet Evolution, “How to take down the Power Grid”, Ira Winkler