Capítulo 31 — Segurança de TO, IoT e sistemas ciberfísicos: casos avançados

Mapa da aula

Aula 31 publicada. Mapa, exemplo, EX091.

flowchart TD
  N0["31.1 Ferramentas voltadas a dispositivos ICS/SCADA"]
  N1["31.2 Capacidade não é incidente"]
  N2["31.3 Do comportamento à detecção"]
  N3["31.4 Comparando tipos de caso"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX091"]

Desenho lógico

flowchart LR
  N0["31.1 Ferramentas voltadas a dispositivos ICS/SCADA"]
  N1["31.2 Capacidade não é incidente"]
  N2["31.3 Do comportamento à detecção"]
  N3["31.4 Comparando tipos de caso"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX091"]

[31.1 Ferramentas voltadas a dispositivos ICS/SCADA]
    |
    v
[31.2 Capacidade não é incidente]
    |
    v
[31.3 Do comportamento à detecção]
    |
    v
[31.4 Comparando tipos de caso]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX091]

Objetivos de aprendizagem

Você vai (1) analisar um framework modular de ataque a ICS a partir de um alerta da CISA; (2) distinguir capacidade de uso observado; (3) derivar oportunidades de detecção a partir de comportamentos documentados; e (4) comparar um alerta centrado em capacidades com um relatório de incidente.

31.1 Ferramentas voltadas a dispositivos ICS/SCADA

A CISA, com agências parceiras, publicou o alerta AA22-103A em abril de 2022, avisando que agentes de ameaça persistente avançada tinham desenvolvido ferramentas customizadas capazes de procurar, comprometer e controlar certos CLPs da Schneider Electric, CLPs OMRON Sysmac NEX e servidores OPC UA, uma vez que tivessem acesso à rede de TO. O mesmo alerta descreve uma ferramenta que explorava um driver vulnerável de placa-mãe ASRock para comprometer estações de engenharia baseadas em Windows. O alerta nomeia famílias de produtos e ferramentas, não vítimas, e isso molda a forma como a LDHP deve lê-lo.

31.2 Capacidade não é incidente

Ao contrário do alerta de 2015 sobre a Ucrânia, o AA22-103A não descreve uma interrupção numa vítima identificada. Ele descreve uma capacidade. A resposta certa é a preparação: inventariar as famílias de produtos afetadas, restringir os protocolos de engenharia às estações de engenharia, monitorar conexões inesperadas e proteger os drivers das estações. As mitigações do alerta incluem isolar as redes de ICS, impor autenticação multifator para acesso remoto e monitorar drivers incomuns. A leitura de Maya para a LDHP: nenhuma das famílias de produtos nomeadas está em uso, mas o servidor OPC UA do HIST-1 e os drivers da EWS-1 são as exposições genéricas que o alerta descreve.

31.3 Do comportamento à detecção

O comportamento documentado sugere detecções específicas: um novo host falando o protocolo de engenharia de um fabricante de CLP; upload ou download de programa fora de uma janela de mudança (ATT&CK for ICS T0843 Program Download); sessões OPC UA a partir de hosts que não sejam os clientes conhecidos; carregamento de um driver assinado sabidamente vulnerável numa estação. Maya acrescentou duas dessas ao monitoramento da LDHP: sessões OPC UA com o HIST-1 a partir de clientes não aprovados, e eventos de carregamento de drivers na EWS-1, agora na lista de encaminhamento de logs da estação. A terceira, download de programa para o PLC-H fora de uma janela de mudança, cabe no monitor passivo já existente no switch de controle, que já alerta sobre downloads de firmware; estendê-lo para downloads de lógica só exige o calendário das janelas de mudança como entrada.

31.4 Comparando tipos de caso

Relatórios de incidente ensinam o que aconteceu sob restrições reais; alertas de capacidade ensinam o que poderia acontecer em seguida. Os dois são necessários, e nenhum substitui o seu próprio inventário. A tabela de casos de Maya no Capítulo 20 usou relatórios de incidente: a estação de água de 2021 e o Mirai, cada um com um análogo na LDHP. O AA22-103A acrescenta um tipo diferente de entrada, porque a LDHP não usa nenhum dos produtos nomeados. A resposta dela, duas novas detecções para o HIST-1 e a EWS-1, veio do inventário, e não da lista de produtos do alerta. Uma planta que só conferisse a lista de produtos teria concluído que não havia nada a fazer.

Exemplo resolvido (LDHP sintética)

A LDHP não usa nenhuma família de produtos nomeada no AA22-103A. Maya não para por aí: ela observa que o servidor OPC UA do HIST-1 é uma exposição genérica, acrescenta "sessões OPC UA a partir de clientes não aprovados" ao monitoramento e acrescenta "eventos de carregamento de drivers na EWS-1" à lista de encaminhamento de logs da estação.

Caso sintético — Lakeside District Heating Plant. A combinação de produtos da LDHP é inventada; o AA22-103A é um alerta real.

Erros e limites

Os alertas são retratos de um momento; procure atualizações. Não baixe nem execute ferramentas nomeadas em alertas fora de um ambiente de pesquisa autorizado e isolado.

Exercícios

• EX091 — Escopo do alerta. Nomeie as duas famílias de fabricantes de CLP e o tipo de servidor listados no AA22-103A.
  Mostrar critérios de avaliação

  Rubrica: 3 = Schneider Electric, OMRON (Sysmac NEX), servidores OPC UA; 2 = dois; 1 = um; 0 = nada.
• EX092 — Uma detecção a partir da T0843. Escreva uma ideia de regra de detecção baseada no comportamento de download de programa.
  Mostrar critérios de avaliação

  Rubrica: 3 = alertar sobre download de programa para o CLP fora de uma janela de mudança aprovada ou a partir de um host que não seja de engenharia; 2 = parcial; 1 = "monitorar os CLPs"; 0 = nada.
• EX093 — Não afetado, mas agindo. Por que agir com base num alerta que nomeia produtos que você não tem?
  Mostrar critérios de avaliação

  Rubrica: 3 = as técnicas se transferem (OPC UA, drivers de estações, protocolos de engenharia); o inventário pode estar incompleto; 2 = um; 1 = "por precaução"; 0 = nada.

Síntese

Analisar casos avançados significa ler os alertas em busca de comportamentos, traduzir comportamentos em detecções e recusar-se a concluir "não é conosco" só a partir de uma lista de produtos.