Implementação de controles eficazes em um ICS (Norma ISO IEC 62443)

No dia a dia, pensamos na segurança sob vários pontos de vista, avaliamos uma necessidade e, de acordo com essa necessidade, implementamos como arquitetos o que acreditamos ser mais adequado em cada caso.

Às vezes, pensamos no que seria mais eficaz, de acordo com a tecnologia em que operamos, e também dizemos que o antigo pensamento baseado em perímetro não nos serve mais, e descobrimos que a lista de estratégias está ficando cada vez menor.

Algumas escolas de pensamento podem apontar que a segurança baseada em padrões também é o principal alimento para uma falsa sensação de segurança, pois leva os analistas a uma zona de conforto da qual, em muitos casos, é impossível sair. Embora isso possa ser verdade, a realidade é que os padrões nos ajudam muito a criar processos, e um padrão bem utilizado é uma ótima ferramenta para combater riscos em todas as áreas em que operamos.

Pode ser no nível da rede, no nível do aplicativo e em diferentes sistemas também, mas ainda mais em uma das áreas que está recebendo atenção ultimamente ou que está realmente começando a se concentrar na segurança com mais frequência, estamos falando das áreas industriais, mais particularmente das áreas industriais que precisam implementar controles eficazes em seus sistemas ICS.

Em geral, existe uma falta de padrões que regulem os projetos e as arquiteturas correspondentes voltados para o aprimoramento dessas áreas. Nesta oportunidade, analisaremos como essa falta de padrões influencia áreas que não são voltadas para a segurança, pois sua natureza está associada às tecnologias de operação.

O aprimoramento da segurança dos sistemas de controle industrial (ICS) geralmente envolve uma avaliação completa dos riscos, seguida de uma avaliação da segurança, ambas complementadas por relatórios que detalham as vulnerabilidades, os pontos fracos e as recomendações. Em seguida, vem uma enxurrada de atividades na forma de planos de atenuação de riscos focados em determinar quais descobertas realmente merecem o investimento necessário para a atenuação - planos de atenuação que são totalmente extensos e quase impossíveis de seguir. Portanto, essa questão geralmente acaba em um acordo com o auditor relevante ou em um compromisso de conformidade de lacunas. Esse nível de aprovação tem seus benefícios, mas tende a reduzir o problema de segurança a uma lista focada de constatações que representam apenas uma parte do quadro completo de segurança do ICS. Depois de analisar as constatações, as medidas de mitigação podem levar de um a três anos para serem concluídas, dependendo de fatores como a maturidade atual da segurança do ICS, a agilidade e o orçamento disponível, além do custo operacional total de ter de desacelerar completamente as atividades porque é improvável ter uma plataforma de testes igual à produtiva devido à complexidade de alguns ambientes. Nesse momento, é hora de fazer uma reavaliação completa.

As melhorias necessárias podem ser implementadas, mas o que está faltando nessa abordagem é a coesão. Melhorar a segurança do ICS não é apenas abordar os pontos fracos adicionando controles de segurança. Esses controles devem ser cuidadosamente selecionados, complementares e, em conjunto, apoiar uma compreensão clara de como prevenir, monitorar, detectar e responder a incidentes de segurança cibernética nesses ambientes. A melhoria da segurança cibernética em um ICS não pode ser incluída em um simples roteiro sequencial de fases. O ideal é que, dependendo dos requisitos de segurança e dos níveis de proteção identificados durante o processo de avaliação de riscos, o ICS seja segmentado em zonas de segurança que possam operar em diferentes estágios de maturidade, como qualquer solução que deseje melhorar uma violação que não tenha sido tratada de forma específica por um bom tempo.

A IEC 62443 separa uma organização com ICS em zonas de segurança com base na avaliação de risco. A norma fornece orientação sobre como selecionar as zonas e atribuir os respectivos níveis de segurança (SL), a fim de poder aplicar as fases de maturidade discutidas acima.

Para cada nível, são necessários determinados controles, pois uma organização deve avaliar os níveis atribuídos para poder aplicar a segurança de forma consciente em cada etapa da análise da arquitetura a ser avaliada. Como em qualquer padrão, as lacunas correspondentes devem ser avaliadas para ver o quanto estamos distantes do padrão que queremos impor na área em que estamos implantados. Essas zonas ou níveis estão associados a uma faixa de Nível de Segurança de 0 a 4.

Características dos níveis de segurança

Para atingir um nível ideal de segurança e cumprir os requisitos de segurança, os SRs (Requisitos do Sistema) e o RE são implementados de acordo com a proteção necessária contra ameaças específicas. Os níveis de proteção da IEC 62443 são mencionados abaixo.

A implementação desses níveis segmentados, de acordo com os requisitos da área, pode tornar as soluções de segurança muito mais simples de implementar. Não é a mesma coisa aplicar um nível a toda a arquitetura (muito mais caro) do que tratar cada parte de nosso ICS de forma independente para economizar esforços de acordo com o risco.

Foto ilustrativa como exemplo

Quando uma organização separa seus ambientes ICS em várias zonas, nunca há isolamento absoluto de risco entre todas as zonas, portanto, uma zona enfraquecida pode afetar as zonas vizinhas de duas maneiras.

• Primeiro, uma interrupção dos serviços ou das operações dentro da zona enfraquecida pode se espalhar para outras zonas, dependendo dos serviços que a zona administra.
• Em segundo lugar, comprometer uma área e aproximar uma ameaça de outras áreas, fornecendo-lhes visibilidade adequada. Para superar esses desafios, o padrão sugere uma série de aprimoramentos de requisitos (REs), que abordaremos em breve.

Para ajudar os usuários a determinar os requisitos de SL associados a cada zona de segurança, o padrão que estamos explorando categoriza sete requisitos fundamentais (FRs), que, por sua vez, são divididos em uma série de requisitos de sistema para aumentar a segurança.

Para auxiliar na definição de cada SL (Security Level, nível de segurança), a norma fornece uma definição de ameaça para cada nível, na qual ela pode ser visualizada por meio de uma tabela que permite um diálogo sobre questões mais específicas. O cenário de ameaças difere de acordo com o setor, a indústria e o tipo de organização. Esse padrão nos fornece definições sólidas e um bom lugar para começar a considerá-las como um bom ponto de partida para definir a postura de defesa a ser desenvolvida. Abaixo está um exemplo de mapeamento de SRs dos requisitos fundamentais e seus respectivos aprimoramentos (ERs) para os níveis de segurança.

Potencialmente, os SLs (Níveis de Segurança) podem apresentar diferenças exclusivas para cada zona de segurança, como ameaças, mudanças operacionais e tecnologias como a Internet Industrial das Coisas (IIoT), que podem alterar a superfície de ataque de um ICS. Os FRs ajudam a definir objetivos, mas eles devem ser flexíveis e ativamente alinhados para acompanhar as mudanças globais nas ameaças. Nenhum padrão nos dá uma visão precisa e alinhada às condições locais de cada uma das soluções associadas a um ICS; precisamos sempre ter essa adaptabilidade, o que nos dá a versatilidade para alternar entre essas superfícies.

Também é importante entender o papel das contramedidas que podemos gerar, por exemplo, quando procuramos uma lista de recomendações, identificamos as oportunidades e as capacidades de expandir as contramedidas em um futuro próximo, onde isso beneficia o restante das zonas, é um pouco a arte de reciclar o esforço para evitar uma sobrecarga de trabalho ao remediar um ICS, tudo o que podemos fazer deve ser suficientemente adaptável e maleável de acordo com o ambiente e o restante dos mecanismos. Essa ideia de como abordar a questão do ponto de vista da reciclagem transforma a ilusão de economia de tempo em uma economia líquida de tempo, que se reflete no dia a dia. Assim, maximizamos nosso retorno sobre o investimento.

Importância das zonas e subzonas

Cada zona de segurança e o caminho de comunicação entre elas ( conduíte ) recebem um nível de segurança alvo (SL-T). Para atingir o que a Norma considera um nível satisfatório de segurança ("nível de segurança atingido" ou SL-A), vários fatores contribuintes devem estar presentes. Esses fatores devem ser levados em conta ao estabelecer zonas e conduítes de segurança e seus respectivos níveis de segurança.

Modelo Purdue de um sistema de controle industrial zoneado

Como veremos, um ICS pode ser segmentado em zonas de segurança, mas os caminhos de comunicação podem deixar vetores de ataque residuais entre esses segmentos. Esse conceito de nomear cada parte do nosso sistema é um conceito poderoso que nos fornece a base necessária para a segmentação.

Debido a que un ICS es un sistema de sistemas, dependiendo de la industria en la que se desempeñe, pueden ser separados en grupos más pequeños, sistemas físicos, como máquinas, sistemas de aplicativos, que executam funções operacionais enquanto compartilham riscos operacionais, e ativos de informações. Uma zona de segurança pode estar localizada dentro desses grupos, compartilhando requisitos comuns e, portanto, criando limites imaginários que os separam. Um ICS pode ser estruturado de forma que uma pequena parte, como uma caldeira, exija um nível de segurança um pouco mais alto, mas que possa se beneficiar do nível de segurança dos ativos ao redor. Para esses casos, pode ser usada uma subzona. Ao segmentar, uma zona e uma subzona de segurança são simplesmente construções lógicas das operações de um ICS e devem ser consideradas fora do contexto da rede e dos componentes físicos reais.

Depois de analisar e entender os caminhos de comunicação necessários entre as zonas de segurança, essa estrutura de segmentação pode ser sobreposta ao hardware e à rede do sistema de controle físico, de modo que os controles possam ser aplicados nessa instância e a tradução das necessidades de segmentação possa ser feita, e uma solução possa ser implementada de acordo com o problema resolvido.

Há situações em que as informações precisam fluir para dentro e para fora de uma área de segurança por meio de comunicação. Isso também inclui comunicações intermitentes por meio de terminais de programação, dispositivos móveis e dispositivos de armazenamento removíveis, entre outros. O Padrão se refere a esses canais de comunicação como conduítes, que podem ser identificados como confiáveis ou não confiáveis.

As comunicações dentro de uma zona são reconhecidas principalmente como conduítes confiáveis. Os conduítes não confiáveis são comunicações provenientes de outras zonas de segurança que não estão no mesmo nível de segurança ou que são feitas por meio de um canal de comunicação que não está no mesmo nível de segurança.

Ao modelar zonas e conduítes, há uma série de regras importantes que os profissionais devem ter em mente. Aqui estão algumas delas:

• Uma zona pode ter subzonas
• Um conduíte não pode ter subconduítes
• Uma zona pode ter mais de um conduíte, os hosts usam um ou mais conduítes para se comunicar.
• Um conduíte não pode passar por mais de uma zona.
• Um conduíte pode ser usado por duas ou mais zonas para se comunicarem entre si.

Na imagem a seguir, podemos visualizar exemplos de uma configuração correta e uma incorreta para que você possa entender a diferença entre as duas arquiteturas.

Imagem extraída do site https://gca.isa.org

Para muitas organizações, a segmentação pode ser um processo difícil. É por isso que as zonas devem ser abstraídas sem se concentrar muito no hardware e no software reais. Somente depois de aplicar os SLs é que os equipamentos ICS (como equipamentos de rede, PLCs, drives, computadores, firewalls, serviços e protocolos) devem ser sobrepostos. Esse processo mostrará claramente todas as deficiências do hardware compartilhado, dos caminhos de rede e do software presentes no ambiente.

Essas informações podem identificar oportunidades para ajudar a minimizar a alocação de SLs mais altos em muitas áreas, reduzindo assim os custos. Cada ambiente é diferente, mas os processos usados podem incluir os seguintes princípios:

• Níveis de segurança mais baixos exigem menos controles de segurança.
• A segmentação hierárquica de zonas e subzonas oferece defesa em profundidade.
• Os limites da zona fornecem pontos de estrangulamento para o monitoramento.
• A segmentação de servidores e aplicativos de software pode gerar outras oportunidades.
• O uso do controle de acesso à rede no nível do switch pode ajudar a ampliar os controles.

Alguns ambientes ICS podem ser problemáticos porque os sistemas de controle podem ter uma relação significativa de dados com os sistemas de informação da empresa, criando uma dependência operacional que deve acomodar zonas de segurança amplas; uma zona de segurança ampla implica maior monitoramento. Além disso, os sistemas de informação tendem a residir dentro da empresa, dificultando a criação de zonas hierárquicas independentes para defesa em profundidade. No entanto, nessas arquiteturas, pode ser útil usar switches com controle de acesso à rede para gerar várias subzonas em ambientes existentes e novos que exijam essa interação.

Conclusão

Entre outras coisas, precisamos aprender a ajustar nossas ferramentas de projeto e melhorar nossas habilidades de abstração ao avaliar ambientes complexos ou aparentemente complexos, como o ICS. Soluções menos complexas levam a uma compreensão muito mais dimensionável do problema em comparação com sistemas complexos.
Talvez tenha chegado o momento de as tecnologias operacionais inserirem os profissionais de segurança em seus processos de arquitetura para abrir caminho, por meio do poder da abstração, para poder simplificar as soluções em sua máxima expressão possível, visando à eficiência das comunicações nessas áreas. Em resposta a essa frase inicial, "A segurança baseada em padrões é eficaz?", muitas vezes ela ajuda a orientar os processos, mas se apenas aplicarmos o padrão, ele poderá perder sua eficácia aparente em pouco tempo. Portanto, ela deve ser nossa ferramenta, mas não deve ser a única ferramenta de referência para resolver problemas.