GosSOPKA significa. Traduzir terminologia

Se você trabalha para uma empresa que se enquadra na ação nº 187-FZ (“Sobre a segurança da infraestrutura de informações críticas da Federação Russa”), não precisa explicar o que é GosSOPKA e por que é necessário. Quanto ao resto, explicamos: GosSOPKA significa sistema estadual para detectar, prevenir e eliminar as conseqüências de ataques de computador. Arquitetonicamente, é um único complexo de centros geograficamente distribuídos de vários tamanhos, trocando informações sobre ataques cibernéticos. Esses centros são obrigados a criar todas as empresas que possuem os objetos da infraestrutura de informações críticas (essas empresas são chamadas de sujeitos de CII). O objetivo dessa iniciativa governamental de larga escala é criar um sistema de troca de informações entre as organizações mais importantes do país sobre ataques cibernéticos em andamento e, assim, fornecer a possibilidade de proteção preventiva.

Por um longo tempo, o documento principal que define os princípios de funcionamento dos centros GosSOPKA e sua interação com um centro superior foram as “Recomendações metodológicas para a criação e operação dos centros GosSOPKA” desenvolvidas pelo FSB. Analisamos anteriormente este documento e observamos que o foco principal de sua atenção era a construção de processos para gerenciamento de incidentes e controle de segurança de sujeitos do GosSOPKA. Mas, ao mesmo tempo, essa abordagem deixou um campo bastante amplo para diferentes interpretações de quantas tarefas o centro GosSOPKA deveria resolver e quais ferramentas específicas são necessárias para isso. Recentemente, “Requisitos para ferramentas projetadas para detectar, prevenir e eliminar as conseqüências de ataques de computador e responder a incidentes de computador”. Vamos tentar descobrir o que o regulador espera das empresas que constroem os centros GosSOPKA por conta própria e investigar esse problema.


Hierarquia de interação de centros

Existem tentativas conhecidas de construir centros GosSOPKA exclusivamente em sistemas IDS. Existem também fornecedores no mercado que posicionam o IDS ou SOA como uma solução universal para o problema. Os sujeitos da KII tinham muitas perguntas sobre a funcionalidade e os requisitos dos sistemas SIEM, que muitas empresas consideravam quase a única ferramenta necessária para criar um centro GosSOPKA.

Agora, com o advento do documento "Requisitos para ferramentas projetadas para detectar, prevenir e eliminar as conseqüências de ataques de computadores e responder a incidentes com computadores", a primeira clareza aparece em relação aos requisitos reais do regulador para as ferramentas do centro.

O documento descreve cinco subsistemas principais do centro GosSOPKA:

1. Ferramentas de detecção
2. Meios de aviso
3. Ferramentas de liquidação
4. Ferramentas de Descriptografia (PACA)
5. Ferramentas de troca de informações
6. Meios de proteção criptográfica dos canais de comunicação

Vamos tentar analisar cada um dos itens sequencialmente. Faremos uma reserva imediatamente que não consideramos os problemas de "ortodoxia" do produto e a necessidade de substituição de importações. Vamos nos concentrar exclusivamente em aspectos técnicos.

Ferramentas de detecção, mas não SOA. Quatro letras

Em nossa opinião, esse item é um dos mais importantes do ponto de vista da resolução de disputas sobre os meios que podem ser utilizados, uma vez que as discussões "Você precisa do SIEM, ou simplesmente subsistemas suficientes de SOA" estão em andamento e não desaparecem.

Vamos ler o documento com mais detalhes:

Primeiro, estamos falando de uma ferramenta que coleta eventos de segurança da informação. Nem incidentes (os resultados do trabalho de equipamentos de proteção), nem tráfego bruto ou sua cópia, ou seja, eventos. Isso nos dá uma dica bastante transparente de que precisamos da funcionalidade de processamento de log.

A nota deste parágrafo também fornece uma lista bastante detalhada e ampla de fontes potenciais que devem fornecer esses eventos. A lista inclui não apenas meios clássicos de proteção (firewalls, SOA, antivírus), mas também fontes de infraestrutura (equipamentos de rede e sistemas operacionais), bem como sistemas de gerenciamento de aplicativos para equipamentos de rede, sistemas de monitoramento de qualidade de serviço, etc.

Tudo isso, bem como as palavras “correlação e agregação de eventos” mencionadas nos requisitos funcionais, em nossa opinião, definem com bastante precisão a tecnologia de destino do item como a plataforma SIEM .

Isso segue totalmente as recomendações metodológicas emitidas anteriormente, porque, para detectar totalmente incidentes de computador das categorias "acesso não autorizado", "adivinhação de senha" e "malware", um meio ativo de proteção não será suficiente.

Alguma plataforma comercializada como SIEM será igualmente adequada? Em nossa opinião, não, pois pelo menos dois requisitos bastante importantes são indicados no texto:

• O sistema de detecção não deve apenas correlacionar e detectar incidentes, mas também salvar os resultados de seu processamento e “informações sobre eventos de SI, inclusive em sua forma original”. Considerando a lista de fontes indicada acima, bem como a profundidade de armazenamento recomendada (pelo menos 6 meses), estamos falando de uma plataforma completa com funcionalidade avançada de Gerenciamento de Log e disposição para lidar com fluxos de eventos muito significativos. Isso reduz bastante a lista de opções possíveis.
• O sistema de detecção deve ter "suporte interno para várias fontes de eventos de segurança da informação e a capacidade de desenvolver módulos adicionais que fornecem informações de novas fontes de eventos de segurança da informação", ou seja, a capacidade de refinar rapidamente a lista e a composição das fontes conectadas. Isso impõe requisitos à disponibilidade de uma API aberta para o desenvolvimento de tais métodos de conexão (na gíria SIEM - conectores) ou à capacidade de obter rapidamente esse refinamento do fornecedor.

Integralmente, esses requisitos demonstram uma atitude muito séria do regulador em relação à funcionalidade do sistema de detecção. Na minha opinião, eles indiretamente deixam claro que a execução formal das recomendações metodológicas (por exemplo, "incidentes de malware podem ser detectados pelo tráfego de rede, não precisamos de antivírus" ou "precisamos apenas conectar apenas duas fontes para atender aos requisitos") provavelmente não terá o direito à existência. Será necessário um estudo sério do modelo de ameaças e trabalho na configuração de cenários de monitoramento.

Avisar ou inventariar

A próxima seção - meios de aviso - é muito mais próxima e mais compreensível para o segurança tanto em termos quanto em abordagens. As seguintes funções são atribuídas aos meios de aviso:

• Inventário de ativos de infraestrutura com capacidade de armazenar e complementar informações.
• Coleta e avaliação de informações sobre vulnerabilidades de recursos de informação.
• Coleta e avaliação de informações sobre deficiências (em nossos erros de leitura - configuração) de recursos de informação.

A lista de funções descrita é mais frequentemente implementada por produtos de software da classe Vulnerability Scanner ou scanners de segurança. Parece que o nome não óbvio “sistema de aviso” possui uma lógica muito correta: é impossível evitar um vetor de ataque em potencial e identificar pontos fracos da infraestrutura se você não tiver informações completas sobre seu estado, os nós usados, o software ou as vulnerabilidades de processo de seus ativos.

A tarefa de gerenciar ativos e vulnerabilidades, com toda sua aparente simplicidade, está repleta de um grande número de armadilhas. Mas uma discussão desses detalhes não faz parte do material atual e pode aparecer em nossos futuros artigos. Quero apenas observar que quase todas as empresas estão equipadas com as ferramentas necessárias para resolver o problema, uma vez que requisitos semelhantes já apareceram em diferentes ordens e pedidos do FSTEC e até na lei de dados pessoais. A principal tarefa é "reviver" uma ferramenta existente e iniciar processos na realidade, e não no papel.

Eliminação como Eliminação Colaborativa

Aqui, o nome do produto e os requisitos para ele receberam uma interpretação bastante inesperada. Como meio de eliminação, temos uma solução que tem função próxima da plataforma de gerenciamento de incidentes, que no mundo de TI é chamada de service desk, e o IS se refere orgulhosamente à Plataforma de Resposta a Incidentes (embora o IRP também tenha uma funcionalidade especializada). De fato, as principais tarefas do subsistema são:

• Registro de incidentes com a capacidade de editar e complementar o cartão de incidentes.
• A capacidade de gerenciar seu ciclo de vida com a transferência do incidente entre o responsável e as unidades.
• A capacidade de coletar o cartão de incidente final de acordo com os formatos aprovados pelo SCCC.

Com base nisso, também é construída a correspondência do funcional com o nome do sistema. A liquidação de um incidente requer principalmente a interação de diferentes departamentos da empresa, e o gerenciamento do processo de liquidação, controlando seu tempo e integridade, neste caso, vem à tona. Portanto, o centro GosSOPKA, como responsável por esse processo, deve ter as ferramentas apropriadas.

A escolha de soluções e tecnologias criadas especificamente para tarefas de SI no mercado ainda é muito limitada. Mas o documento não contém restrições diretas sobre o uso para esse fim de um sistema de TI comum (em design padrão ou individual) com algumas modificações nas tarefas de SI. Normalmente, os sistemas de service desk são um construtor bem personalizável, portanto, a revisão não deve ser difícil.

Outras instalações do centro

As funções e tarefas do subsistema PACA visam principalmente analisar o tráfego da rede, tanto em tempo real (para detectar ataques ou tentativas de acesso não autorizado ao equipamento de rede) quanto para registrar e armazenar o tráfego da rede com vistas a seu uso posterior em retrospectiva. análise de eventos ou investigação do incidente. Esses requisitos não são fundamentalmente novos. A tarefa de registrar o tráfego da rede foi definida para todos os proprietários de sistemas de informação do estado desde 2010, como parte de uma ordem conjunta do FSTEC e do FSB. Esses requisitos podem ser inesperados para empresas comerciais, mas na verdade sua implementação também não é particularmente difícil.

Os requisitos para os subsistemas de troca e a proteção criptográfica dos canais de comunicação também são bastante familiares e, provavelmente, não requerem explicações adicionais.

Como um breve resumo, o lançamento deste documento colocou muitos pontos em consideração em relação às ferramentas e tecnologias que precisam equipar o centro do GosSOPKA. Agora, cada cliente possui uma lista formal de requisitos, útil tanto para comparar fornecedores quanto para decidir sobre a compra / substituição de tecnologia. E a aparência de clareza nesses assuntos sempre afeta positivamente a eficiência e a velocidade das medidas adotadas por atores específicos para se conectar, bem como a segurança geral de infraestruturas críticas de informações.