Para que a análise seja substantiva, primeiro corrigimos que estamos comparando o SOC OT com a estrutura do centro de monitoramento, que é implementado em nosso JSOC Solar.
Entre outras coisas, nos permitirá discutir essas diferenças no contexto das tarefas do centro GosSOPKA, que também é responsável por segmentos industriais.
Detalhes sobre cada nível do modelo podem ser encontrados em artigos anteriores sobre inventário de infraestrutura , monitoramento , Threat Intelligence ( 1 , 2 ), controle de segurança , pessoal e processos.... No artigo atual, enfocaremos o bloco central do Monitoramento de Segurança (os recursos dos processos de resposta e investigação no ICS estarão em artigos posteriores).
O teatro começa com um gancho e o SOC começa com o monitoramento
Parece que na área de monitoramento de eventos, correlação e detecção de incidentes, tudo já está definido e conhecido. E até mesmo reduzir a lacuna de ar para coletar eventos de segurança é um tópico bastante testado e comprovado . Mesmo assim, existem algumas nuances às quais definitivamente vale a pena prestar atenção.
Arquitetura geral de SOC... Apesar da solução aparentemente simples com um entreferro, a situação para grandes empresas federais com instalações distribuídas (isso é especialmente verdadeiro para o setor de energia) é bastante complicada. O número de objetos é medido em milhares, muitas vezes nem é possível colocar um servidor de coleta de eventos neles, cada um dos objetos é bastante compacto, mas pode gerar eventos de segurança da informação significativos. Além da situação descrita, o problema dos canais de comunicação é muitas vezes sobreposto, tão estreito que pelo menos alguma carga significativa na transmissão de eventos para o "centro" começa a interferir no funcionamento das principais aplicações.
Portanto, como decompor corretamente os componentes do SIEM por sites é uma questão muito séria. Voltaremos a ele em um de nossos materiais posteriores, uma vez que
Especialização de casos de uso e criação de perfis . Mesmo sem tocar no tópico de cenários completamente especializados que são relevantes apenas para o segmento ICS, é importante notar que mesmo os incidentes padrão no ICS têm um significado e criticidade completamente diferentes. Estamos todos acostumados a usar as Ferramentas de Administração Remota em uma rede corporativa há muito tempo. Mas é óbvio que a criticidade de tal incidente, bem como, em princípio, da comunicação bem-sucedida com a Internet em uma rede tecnológica fechada é enorme. O mesmo se aplica à instalação de um novo serviço de sistema em uma estação de trabalho tecnológica, ao fato de detectar malware que requer investigação obrigatória, etc.
Restrições significativas no uso de Casos de Uso são introduzidas por restrições na implementação de sistemas de segurança da informação (geralmente, segmentos tecnológicos não são muito ricos neles) e o uso de versões desatualizadas e legadas de sistemas operacionais (e os tecnólogos olham para a instalação do Sysmon com desconfiança).
No entanto, um volume muito grande de Casos de Uso do ambiente corporativo pode ser aplicado com sucesso ao segmento ICS e fornecer um nível suficientemente alto de controle de infraestrutura geral.
Bem, é difícil passar pelo Santo dos Santos - sistemas SCADA... Se no nível dos sistemas de segurança da informação, sistemas operacionais e fluxos de rede, todos os segmentos são pelo menos um pouco, mas semelhantes, então, ao avançarmos, surgem diferenças importantes. Em termos de redes e segmentos corporativos, todos sonham com monitoramento de negócios e conectividade de aplicativos de negócios. E esse processo, embora complexo (os logs mudam e não querem fingir ser CEF, as informações normais só podem ser obtidas do banco de dados, mas os administradores xingam e reclamam da lentidão), mas geralmente implementado. No segmento tecnológico, ao conectar sistemas de nível superior e médio, esses problemas são elevados a um absoluto em relação à criticidade espacial da paralisação tecnológica. Para dar os primeiros passos para conectar a fonte, você precisa:
- Monte um estande e verifique o sucesso no recebimento dos eventos
- Desenhe uma solução arquitetônica geral com todos os detalhes técnicos
- Concorde com o fornecedor em alguns meses
- Verifique novamente no estande do cliente com emulação de carga de combate
- Com muito cuidado (como na piada sobre ouriços) para implementar a solução na produção
Tristeza, saudade, processos de negócios. E isso apesar do fato de que, via de regra, o equipamento do APCS é caracterizado por uma perfilagem suficientemente ampla, completa, compreensível e de alta qualidade.
Mas, felizmente (ou por coincidência), geralmente uma abordagem diferente pode ser implementada nos segmentos ICS. A maioria dos protocolos neles não implica criptografia ou mascaramento das informações transmitidas. Portanto, uma das abordagens mais comuns para monitorar e analisar comandos de controle é a implementação de sistemas de detecção de intrusão industrial ou firewalls industriais que permitem trabalhar com uma cópia ou tráfego de rede real e analisar protocolos e comandos de controle com registro subsequente. Alguns deles, entre outras coisas, têm um mecanismo de correlação básico embutido (poupando-nos do horror da normalização, categorização e criação de perfil de eventos), mas ao mesmo tempo eles não são uma substituição completa para o sistema SIEM.
, ,
Se movendo. Parece que as questões de inventário na rede ICS devem ser as menos dolorosas. A rede é bastante estática, o equipamento é isolado dos segmentos comuns, fazer alterações na arquitetura exige todo um projeto em funcionamento. Um conto de fadas sobre redes corporativas - "Basta corrigir o modelo e inseri-lo no CMDB." Mas, como de costume, há uma nuance: para o segmento ICS, o surgimento de qualquer novo equipamento é um dos sinais extremamente importantes de um incidente ou ataque, e deve ser identificado sem falhas. E com tudo isso, os métodos clássicos de inventário (modos poupadores de operação dos scanners de vulnerabilidade) causam as alergias mais graves entre os tecnólogos e até mesmo entre os seguranças do sistema de controle automatizado de processos. Não é incomum em uma rede corporativa quando até mesmo a Varredura de inventário em um modo malsucedido em um momento malsucedido pode “colocar” algum aplicativo específico.Naturalmente, ninguém está pronto para assumir tais riscos no sistema de controle de processo automatizado.
Portanto, a principal ferramenta de inventário em APCS (além do controle manual) são os sistemas de análise de tráfego de rede e sistemas de detecção de intrusão industrial mencionados anteriormente. Cada novo nó, tendo surgido na rede, começa a se comunicar com seus vizinhos. Tanto os métodos e protocolos de comunicação, as especificidades dos pacotes e campos de serviço permitem não só ver rapidamente o novo "vizinho", mas também identificá-lo claramente.
Em contraste, o processo de identificação e gerenciamento de vulnerabilidades é mais conservador. Como regra, a infraestrutura é atualizada e corrigida com pouca frequência e de forma muito controlada, a lista de softwares de aplicação e equipamentos tecnológicos é fixa. Portanto, para determinar a lista e o status das vulnerabilidades atuais no segmento ICS, geralmente é suficiente determinar a versão do software principal e verificar os boletins dos fabricantes. Como resultado, estamos mudando do modo agressivo de varredura e verificação de software para os métodos de auditoria e análise de versão técnica e manual de um especialista do setor.
O processo de análise ou identificação de ameaças é construído de maneira semelhante. Como regra, um modelo fixo único é modernizado pelo fato de uma reconstrução crítica da infraestrutura (adição de novos nós, atualização da versão do firmware de equipamentos críticos, etc.), ou ao revelar uma nova vulnerabilidade relevante para a infraestrutura e / ou um novo vetor de ataque. No entanto, eles também não são tão simples.
OT Threat Intelligence ou as redes isoladas sonham com indicadores de comprometimento?
As informações sobre novas ameaças e vetores de ataque podem ser inúteis? Eu gostaria de responder imediatamente “não”, mas juntos vamos tentar entender a aplicabilidade dos dados clássicos de TI no segmento de OT maduro.
TIs geralmente são feeds (fluxos de dados) ou IoCs (indicadores de comprometimento para identificar malware específico ou ferramentas de hacking). Eles contêm as seguintes características:
- (IP-, URL, ), upload «» , . , , . , , «» .
- (MD5- , , / ..), / / . , . , , , , whitelisting, , . – «» . TI .
Com isso, para os ataques direcionados ao ICS, as informações sobre TTP, táticas e abordagens de atacantes, extremamente raras no mercado de TI, estão ganhando muito mais peso, o que permitirá adequar adequadamente os mecanismos de defesa e as abordagens para monitorar e identificar ameaças no segmento.
Essas e muitas outras nuances nos forçam a adotar uma abordagem muito séria e cuidadosa para o processo de construção de tal SOC ou a escolha de um contratante, bem como a pensar seriamente sobre a estratégia para formar um OT SOC. Caso se cruze com o SOC IT ou funcione separadamente dele, é possível que algum tipo de enriquecimento mútuo e sinergia em processos, equipes e tarefas sejam resolvidos. Em nosso próximo artigo, tentaremos destacar as diferentes abordagens das equipes internacionais para este assunto. Esteja seguro em todos os aspectos de sua infraestrutura e vida.