🥇Protocolos Flow como ferramenta de monitoramento de segurança da rede interna

Quando se trata de monitoramento da segurança de redes corporativas internas ou institucionais, muitos associam isso ao controle de vazamentos de informações e à implementação de soluções DLP. Mas se tentarmos esclarecer a questão e perguntar como você detecta ataques na rede interna, a resposta geralmente será uma menção a sistemas de detecção de intrusões (intrusion detection systems, IDS). E o que era a única opção há 10-20 anos, hoje se torna um anacronismo. Existe uma alternativa mais eficaz, e em alguns casos, a única possibilidade de monitoramento da rede interna - usar protocolos de fluxo, que inicialmente eram destinados à solução de problemas de rede, mas que ao longo do tempo se transformaram em uma ferramenta muito interessante de segurança. É sobre quais protocolos de fluxo existem e quais deles ajudam melhor a detectar ataques de rede, onde é mais eficaz implementar o monitoramento de fluxo, em que prestar atenção ao implantar tal esquema, e até mesmo como isso pode ser

Não vou me aprofundar na questão "Por que é necessário monitorar a segurança da infraestrutura interna?" A resposta parece ser clara. Mas se você ainda quiser se certificar de que hoje isso é imprescindível, veja um pequeno vídeo apresentando 17 maneiras de invadir uma rede corporativa protegida por um firewall. Portanto, vamos considerar que entendemos que o monitoramento interno é necessário e agora só resta saber como organizá-lo.

Eu destacaria três fontes principais de dados para monitoramento da infraestrutura em nível de rede:

"tráfego bruto", que capturamos e submetemos à análise em sistemas de análise,
eventos a partir dos dispositivos de rede pelos quais o tráfego passa,
informações sobre o tráfego obtidas por meio de um dos protocolos de fluxo.

A captura de tráfego bruto é a opção mais popular entre os especialistas em segurança, pois surgiu historicamente como a primeira. Os sistemas de detecção de intrusões de rede (o primeiro sistema comercial de detecção de intrusões foi o NetRanger da Wheel Group, adquirido pela Cisco em 1998) tratavam exatamente da captura de pacotes (e, posteriormente, de sessões), nas quais se buscavam certas assinaturas (“regras decisivas” na terminologia da FSTEC), sinalizando ataques. Certamente, é possível analisar tráfego bruto não apenas com IDS, mas também com outros meios (como Wireshark, tcpdump ou a funcionalidade NBAR2 no Cisco IOS), mas geralmente eles carecem de uma base de conhecimento que distingue uma ferramenta de segurança da informação de uma ferramenta de TI comum.

Portanto, sistemas de detecção de intrusões. O método mais antigo e mais popular de detecção de ataques de rede, que está se saindo bem em sua tarefa no perímetro (não importa qual — corporativo, de centro de dados, segmento, etc.), mas falha em redes modernas comutadas e definidas por software. No caso de uma rede construída com base em comutadores comuns, a infraestrutura dos sensores de detecção de intrusões se torna grande demais — você terá que instalar um sensor para cada conexão com o nó cujos ataques deseja monitorar. Qualquer fabricante, claro, ficará feliz em vender-lhe centenas e milhares de sensores, mas creio que seu orçamento não suportará tais despesas. Posso dizer que mesmo na Cisco (onde somos desenvolvedores do NGIPS), não conseguimos fazer isso, embora, aparentemente, o preço não devesse ser um problema — afinal, é nossa própria solução. Além disso, surge a questão de como conectar o sensor nesse caso. Em um ponto de interrupção? E se o próprio sensor falhar? Exigir a presença de um módulo de bypass no sensor? Usar divisores (tap)? Tudo isso encarece a solução e a torna inviável para empresas de qualquer porte.

Você pode tentar "anexar" um sensor a uma porta SPAN/RSPAN/ERSPAN e direcionar para ela o tráfego das portas necessárias do switch. Essa opção parcialmente resolve o problema descrito no parágrafo anterior, mas gera outro — a porta SPAN não consegue receber todo o tráfego que será direcionado a ela — ela não terá capacidade suficiente. Teremos que sacrificar algo. Ou deixar algumas das portas sem monitoramento (neste caso, você precisará priorizá-las), ou direcionar não todo o tráfego da porta, mas apenas um tipo específico. Em qualquer caso, poderemos perder alguns ataques. Além disso, a porta SPAN pode estar ocupada para outros fins. Assim, teremos que revisar a topologia existente da rede e, possivelmente, fazer ajustes nela para cobrir ao máximo sua rede com o número atual de sensores disponíveis (e coordenar isso com a TI).

E se sua rede usar rotas assimétricas? E se você tiver implantado ou planejar implantar SDN? E se você precisar monitorar máquinas virtualizadas ou contêineres, cujo tráfego nem chega ao switch físico? Essas questões não são apreciadas pelos fabricantes tradicionais de IDS, pois não sabem como respondê-las. Talvez eles tentem convencê-lo de que todas essas tecnologias modernas são apenas uma moda e que você não precisa delas. Talvez eles falem sobre a necessidade de começar pequeno. Ou talvez digam que você deve instalar uma poderosa máquina central na rede e direcionar todo o tráfego para ela usando balanceadores. Qualquer que seja a opção sugerida, você precisa entender claramente o quão adequada ela é para você. E só depois disso tomar uma decisão sobre a abordagem para o monitoramento da segurança da infraestrutura de rede. Retornando à captura de pacotes, quero dizer que esse método continua sendo muito popular e importante, mas seu propósito principal é o controle das fronteiras; fronteiras entre sua organização e a Internet, fronteiras entre o datacenter e o restante da rede, fronteiras entre o sistema de controle e o segmento corporativo. Nesses pontos, os IDS/IPS clássicos ainda têm seu lugar e desempenham bem as funções para as quais foram projetados.

Vamos passar para a segunda opção. A análise de eventos provenientes de dispositivos de rede também pode ser utilizada para fins de detecção de ataques, mas não como o mecanismo principal, pois permite detectar apenas uma pequena classe de intrusões. Além disso, possui uma certa reatividade — o ataque deve acontecer primeiro, depois deve ser registrado pelo dispositivo de rede, que de alguma forma sinalizará o problema de segurança. Existem várias maneiras de fazer isso. Pode ser syslog, RMON ou SNMP. Os últimos dois protocolos para monitoramento de rede, no contexto da segurança, são utilizados somente se precisamos detectar um ataque DoS ao próprio equipamento de rede, pois com RMON e SNMP podemos, por exemplo, rastrear a carga do processador central do dispositivo ou suas interfaces. Esta é uma das maneiras mais “baratas” (syslog ou SNMP estão disponíveis para todos), mas também a mais ineficaz entre todas as formas de monitoramento da segurança da infraestrutura interna — muitos ataques ficam simplesmente ocultos para ele. Claro que não devemos negligenciá-los e a análise do syslog ajuda a identificar alterações na configuração do próprio dispositivo, sua compromissão, mas a detecção de ataques em toda a rede não é muito adequada.

A terceira opção é a análise das informações sobre o tráfego que passa por um dispositivo que suporta um dos vários protocolos de fluxo. Neste caso, independentemente do protocolo, a infraestrutura de trabalho com fluxos deve necessariamente consistir em três componentes:

Geração ou exportação de fluxo. Esta função geralmente é atribuída a um roteador, switch ou outro dispositivo de rede, que, ao permitir o tráfego de rede passar por ele, destaca os parâmetros-chave que são então enviados para o módulo de coleta. Por exemplo, o protocolo Netflow da Cisco é suportado não apenas em roteadores e switches, incluindo os virtuais e industriais, mas também em controladores sem fio, firewalls e até servidores.
Coleta de fluxo. Considerando que em uma rede moderna geralmente há mais de um dispositivo de rede, surge a tarefa de coletar e consolidar fluxos, que é resolvida com a ajuda dos chamados coletores, que processam os fluxos recebidos e depois os transmitem para análise.
Análise de fluxo. O analisador assume a principal tarefa intelectual e, aplicando diferentes algoritmos aos fluxos, faz determinadas inferências. Por exemplo, no contexto da função de TI, esse analisador pode identificar gargalos na rede ou analisar o perfil de carga do tráfego para futuras otimizações. Para a segurança da informação, esse analisador pode detectar vazamentos de dados, a propagação de malware ou ataques DoS.

Não se deve pensar que uma arquitetura de três camadas é muito complexa — todas as outras opções (exceto, talvez, sistemas de monitoramento de rede que operam com SNMP e RMON) funcionam de acordo com ela. Temos um gerador de dados para análise, que pode ser um dispositivo de rede ou um sensor independente. Temos um sistema de coleta de alarmes e um sistema de gerenciamento de toda a infraestrutura de monitoramento. Os dois últimos componentes podem ser integrados em um único nó, mas em redes mais ou menos grandes, eles geralmente são distribuídos por pelo menos dois dispositivos, para garantir escalabilidade e confiabilidade.

Ao contrário da análise de pacotes, que se baseia no estudo do cabeçalho e do corpo dos dados de cada pacote e das sessões que deles são compostas, a análise de fluxos baseia-se na coleta de metadados sobre o tráfego de rede. Quando, quanto, de onde e para onde, como... estas são as perguntas que a análise de telemetria de rede responde por meio de vários protocolos de fluxo. Inicialmente, eles foram utilizados para analisar estatísticas e encontrar problemas de TI na rede, mas depois, com o desenvolvimento de mecanismos analíticos, tornou-se possível aplicá-los à mesma telemetria para fins de segurança. Vale ressaltar que a análise de fluxos não substitui e não anula a captura de pacotes. Cada um desses métodos tem sua própria área de aplicação. Mas, no contexto deste artigo, a análise de fluxos é a que melhor se adapta ao monitoramento da infraestrutura interna. Você tem dispositivos de rede (e não importa se operam em uma paradigma de software definido ou de acordo com regras estáticas) que um ataque não pode contornar. Um sensor IDS clássico pode ser contornado, mas um dispositivo de rede que suporta o protocolo de fluxo não pode. Esta é a vantagem desse método.

Por outro lado, se você precisar de provas para as autoridades policiais ou para seu próprio grupo de investigação de incidentes, não poderá fazer sem captura de pacotes — a telemetria de rede não é uma cópia do tráfego que pode ser usada na coleta de evidências; ela é necessária para a detecção em tempo real e a tomada de decisões na área de segurança da informação. Em contrapartida, usando a análise de telemetria, você pode "registrar" não todo o tráfego de rede (caso contrário, a Cisco e os data centers cuidarão disso :-), mas apenas aquele que participa do ataque. Ferramentas de análise de telemetria, nesse sentido, complementam bem os mecanismos tradicionais de captura de pacotes, permitindo que sejam feitos capturas seletivas e armazenamento. Caso contrário, você terá que ter uma enorme infraestrutura de armazenamento.

Vamos imaginar uma rede operando a 250 Mbit/s. Se você quiser armazenar todo esse volume, precisará de um armazenamento de 31 MB para um segundo de transmissão de tráfego, 1,8 GB para um minuto, 108 GB para uma hora e 2,6 TB para um dia. Para armazenar os dados diários de uma rede com largura de banda de 10 Gbit/s, você precisará de um armazenamento de 108 TB. E alguns reguladores exigem que os dados de segurança sejam armazenados por anos... A gravação "sob demanda", que a análise de fluxos ajuda a implementar, reduz consideravelmente esses números. A propósito, se falarmos sobre a relação entre o volume de dados gravados da telemetria de rede e a captura completa dos dados, ela é de aproximadamente 1 para 500. Para os valores mencionados acima, o armazenamento da decodificação completa de todo o tráfego diário seria de 5 e 216 GB, respectivamente (pode-se até gravar em um pen drive comum).

Se os métodos de análise de dados de rede brutos quase não mudam de fornecedor para fornecedor, no caso da análise de fluxos a situação é diferente. Existem várias opções de protocolos de fluxos, e as diferenças entre elas devem ser conhecidas especialmente no contexto da segurança. O protocolo mais popular é o Netflow, desenvolvido pela Cisco. Existem várias versões deste protocolo, que diferem nas suas capacidades e na quantidade de informações sobre o tráfego que são registradas. A versão atual é a nove (Netflow v9), que serviu de base para o padrão industrial Netflow v10, também conhecido como IPFIX. Hoje, a maioria dos fornecedores de rede suporta precisamente Netflow ou IPFIX em seu equipamento. Porém, há diversas outras opções de protocolos de fluxo — sFlow, jFlow, cFlow, rFlow, NetStream, etc., sendo que o sFlow é o mais popular. É ele que mais frequentemente é suportado pelos fabricantes nacionais de equipamentos de rede devido à sua facilidade de implementação. Quais são as principais diferenças entre o Netflow, que se tornou um padrão de facto, e o sFlow? Eu destacaria algumas. Primeiro, o Netflow tem campos ajustáveis pelo usuário, ao contrário dos campos fixos no sFlow. E, segundo, e isso é o mais crucial em nosso caso, o sFlow coleta o que se chama de telemetria amostrada; ao contrário da telemetria não amostrada do Netflow e do IPFIX. Qual é a diferença entre eles?

Imagine que você decidiu ler o livro “Security Operations Center: Building, Operating, and Maintaining your SOC” de meus colegas — Gary McIntyre, Joseph Muniz e Nadeem AlFardan (no link você pode baixar uma parte do livro). Você tem três opções para alcançar esse objetivo — ler o livro na íntegra, skim (passar os olhos) por ele, parando a cada 10 ou 20 páginas, ou tentar encontrar um resumo dos conceitos principais em algum blog ou serviço como o SmartReading. Portanto, a telemetria não amostrada é como ler cada “página” do tráfego de rede, ou seja, analisar os metadados de cada pacote. A telemetria amostrada é um estudo seletivo do tráfego na esperança de que nas amostras selecionadas se encontre o que você precisa. Dependendo da velocidade do canal, a telemetria amostrada irá disponibilizar para análise a cada 64, 200, 500, 1000, 2000 ou até 10000 pacotes.

No contexto da monitoração de segurança da informação, isso significa que a telemetria amostrada é boa para detectar ataques DDoS, varreduras e propagação de malware, mas pode perder ataques atômicos ou multi-pacotes que não foram incluídos na amostra enviada para análise. A telemetria não amostrada não tem essas desvantagens e seu espectro de detecção de ataques é muito mais amplo. Aqui está uma pequena lista de eventos que podem ser detectados usando ferramentas de análise de telemetria de rede.

Obviamente, algum analisador de código aberto de Netflow não permitirá isso, pois sua principal tarefa é coletar telemetria e realizar uma análise básica do ponto de vista de TI. Para identificar ameaças de segurança da informação com base em fluxos, é necessário equipar o analisador com diversos mecanismos e algoritmos que consigam identificar problemas de cibersegurança com base em campos padrão ou personalizados do Netflow, enriquecendo os dados padrão com informações externas de várias fontes de Threat Intelligence, entre outras.

Portanto, se você tiver a opção, escolha o Netflow ou IPFIX. Mas mesmo que seu equipamento funcione apenas com sFlow, como é o caso dos fabricantes nacionais, mesmo assim você pode extrair valor dele no contexto de segurança.

No verão de 2019, realizei uma análise das capacidades disponíveis por fabricantes de hardware de rede russo, e todos eles, exceto NSG, Polígono e Kraftway, afirmavam suportar sFlow (pelo menos, Zelax, NatEx, Eltex, QTech, Rusteletech).

A próxima questão que você enfrentará é onde implementar o suporte ao fluxo para fins de segurança? Na verdade, a questão não está exatamente formulada corretamente. Nos equipamentos modernos, o suporte a protocolos de fluxo está quase sempre presente. Portanto, eu reformularia a pergunta de outra maneira: onde é mais eficaz coletar a telemetria em termos de segurança? A resposta será bastante óbvia: no nível de acesso, onde você verá 100% de todo o tráfego, onde terá informações detalhadas sobre os hosts (MAC, VLAN, ID da interface), onde poderá até monitorar o tráfego P2P entre os hosts, o que é crítico para detectar varreduras e a disseminação de malware. No nível do núcleo, parte do tráfego pode simplesmente não ser visível, e no nível de perímetro você verá, bem, se tiver sorte, um quarto de todo o seu tráfego de rede. Mas se, por algum motivo, houver dispositivos desconhecidos em sua rede, permitindo que invasores "entrem e saiam" contornando o perímetro, então a análise da telemetria a partir dele não trará resultado algum. Portanto, para uma cobertura máxima, recomenda-se habilitar a coleta de telemetria precisamente no nível de acesso. Vale ressaltar que mesmo quando falamos sobre virtualização ou contêineres, nos comutadores virtuais modernos, o suporte ao fluxo também é frequentemente encontrado, permitindo controlar o tráfego ali.

Mas, já que levantei o tema, é preciso responder à pergunta: e se, de fato, o equipamento, físico ou virtual, não suportar protocolos de fluxo? Ou se sua ativação for proibida (por exemplo, em segmentos industriais para garantir a confiabilidade)? Ou se sua ativação levar a uma alta carga do processador central (isso acontece em equipamentos desatualizados)? Para resolver essa questão, existem sensores virtuais especializados (flow sensor), que são, na verdade, simples divisores que permitem que o tráfego passe por eles e o transmitem na forma de fluxo para o módulo de coleta. No entanto, neste caso, enfrentamos todos os problemas que discutimos anteriormente relacionados às ferramentas de captura de pacotes. Ou seja, é preciso entender não apenas as vantagens da tecnologia de análise de fluxos, mas também suas limitações.

Mais um ponto importante a se lembrar ao falar sobre ferramentas de análise de fluxos. Se, em relação às ferramentas convencionais de geração de eventos de segurança, aplicamos a métrica EPS (eventos por segundo), para a análise de telemetria essa métrica não é aplicável; ela é substituída por FPS (fluxos por segundo). Assim como no caso do EPS, sua previsão não é possível, mas podemos estimar o número aproximado de fluxos que um dispositivo gera, dependendo de sua função. Na Internet, você pode encontrar tabelas com valores aproximados para diferentes tipos de dispositivos corporativos e condições, que permitirão que você estime quais licenças você precisa para ferramentas de análise e qual será sua arquitetura. O fato é que um sensor IDS é limitado por uma certa largura de banda, que ele pode "extrair", e o coletor de fluxos também tem suas limitações, que precisam ser compreendidas. Portanto, em grandes redes distribuídas geograficamente, geralmente há vários coletores. Quando descrevi, como a rede é monitorada dentro da Cisco, já mencionei o número de nossos coletores - são 21. E isso em uma rede espalhada por cinco continentes e que conta com cerca de quinhentos mil dispositivos ativos).

Como sistema de monitoramento de Netflow, usamos nossa própria solução Cisco Stealthwatch, que é especificamente voltado para resolver questões de segurança. Possui muitos motores integrados para detectar atividades anômalas, suspeitas e claramente maliciosas, permitindo a detecção de uma ampla gama de ameaças — desde mineração de criptomoedas até vazamento de informações, desde a disseminação de malware até fraudes. Assim como a maioria dos analisadores de fluxo, o Stealthwatch é construído em uma arquitetura de três níveis (gerador — coletor — analisador), mas é complementado por uma série de características interessantes que são importantes no contexto do material em questão. Primeiro, ele se integra com soluções de captura de pacotes (por exemplo, Cisco Security Packet Analyzer), permitindo gravar sessões de rede selecionadas para investigação e análise aprofundadas posteriores. Em segundo lugar, especialmente para expandir as questões de segurança, desenvolvemos um protocolo especial chamado nvzFlow, que permite “transmitir” a atividade de aplicativos em nós finais (servidores, estações de trabalho, etc.) para telemetria e enviá-la ao coletor para análise adicional. Se na sua versão original o Stealthwatch funciona com qualquer protocolo de fluxo (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) em nível de rede, o suporte ao nvzFlow permite correlacionar dados também em nível de nó, aumentando assim a efetividade de todo o sistema e permitindo a visualização de mais ataques do que os analisadores de fluxo de rede convencionais.

É claro que, ao falar sobre sistemas de análise Netflow do ponto de vista da segurança, o mercado não se limita a uma única solução da Cisco. Você pode usar tanto soluções comerciais quanto gratuitas ou freemium. É um tanto estranho se eu citar soluções de concorrentes no blog da Cisco, então direi algumas palavras sobre como a telemetria de rede pode ser analisada com duas ferramentas populares, cujos nomes são semelhantes, mas ainda assim diferentes — SiLK e ELK.

SiLK é um conjunto de ferramentas (o Sistema para Conhecimento em Nível da Internet) para análise de tráfego, desenvolvido pelo CERT/CC dos EUA e que suporta, no contexto deste artigo, Netflow (as versões mais populares 5 e 9), IPFIX e sFlow. Com a ajuda de várias utilidades (rwfilter, rwcount, rwflowpack, etc.), ele realiza diversas operações sobre a telemetria de rede com o objetivo de detectar sinais de atividades não autorizadas. No entanto, é importante destacar alguns pontos. SiLK é uma ferramenta de linha de comando e realiza análises operacionais continuamente através de comandos do tipo (detecção de pacotes ICMP maiores que 200 bytes):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

não é muito conveniente. Você pode usar a interface gráfica iSiLK, mas ela não facilita muito sua vida, cumprindo somente a função de visualização, e não de substituição do analista. Esse é o segundo ponto. Ao contrário das soluções comerciais, que já possuem uma base analítica sólida embutida, algoritmos de detecção de anomalias e fluxos de trabalho, no caso do SiLK, você terá que realizar tudo isso por conta própria, o que exigirá de você um conjunto de competências um pouco diferente em comparação ao uso de ferramentas prontas para o trabalho. Isso não é bom nem ruim — é uma característica de quase qualquer ferramenta gratuita, que pressupõe que você saiba o que fazer, enquanto ela apenas o ajuda nesse processo (a ferramenta comercial é menos dependente das competências de seus usuários, embora também presuma que os analistas compreendam pelo menos os fundamentos de investigações e monitoramento de rede). Mas vamos voltar ao SiLK. O ciclo de trabalho de um analista com ele se apresenta da seguinte forma:

Formulação de hipóteses. Precisamos entender o que vamos procurar dentro da telemetria de rede, conhecer os atributos únicos pelos quais identificaremos certas anomalias ou ameaças.
Construção do modelo. Após formular a hipótese, programamos ela utilizando Python, shell ou outras ferramentas que não estão incluídas no SiLK.
Testes. Chegamos à fase de verificar a validade da nossa hipótese, que é confirmada ou refutada com a ajuda de utilidades SiLK, que começam com ‘rw’, ‘set’, ‘bag’.
Análise de dados reais. Em operação industrial, o SiLK nos ajuda a identificar algo e o analista deve responder às perguntas "Encontramos o que esperávamos?", "Isso corresponde à nossa hipótese?", "Como reduzir o número de falsos positivos?", "Como melhorar a taxa de reconhecimento?" e assim por diante.
Melhoria. Na fase final, aprimoramos o que foi feito anteriormente — criamos modelos, melhoramos e otimizamos o código, reformulamos e esclarecemos a hipótese, entre outras.

Este ciclo também será aplicável ao Cisco Stealthwatch, embora este último automatize ao máximo esses cinco passos, reduzindo o número de erros do analista e aumentando a rapidez na detecção de incidentes. Por exemplo, no SiLK, você pode enriquecer as estatísticas de rede com dados externos sobre IPs maliciosos através de scripts que você mesmo escreveu, enquanto no Cisco Stealthwatch — esta é uma função incorporada, que imediatamente lhe mostra um alerta se houver interação com endereços IP da lista negra na sua rede.

Se formos mais alto na pirâmide "de pagamento" de software de análise de fluxo, o SiLK absolutamente gratuito será seguido pelo ELK, que é condicionalmente gratuito e consiste em três componentes principais — Elasticsearch (indexação, busca e análise de dados), Logstash (entrada/saída de dados) e Kibana (visualização). Ao contrário do SiLK, onde tudo precisa ser escrito manualmente, o ELK já possui muitas bibliotecas/módulos prontos (alguns pagos, outros não) que automatizam a análise de telemetria de rede. Por exemplo, o filtro GeoIP no Logstash permite vincular os IPs observados a suas localizações geográficas (no Stealthwatch isso é uma função integrada).

O ELK também possui uma comunidade bastante ampla que desenvolve componentes faltantes para esta solução de monitoramento. Por exemplo, para trabalhar com Netflow, IPFIX e sFlow, você pode usar o módulo elastiflow, se você não estiver satisfeito com o Módulo Netflow do Logstash, que suporta apenas Netflow.

Oferecendo mais agilidade na coleta de fluxo e na busca nele, o ELK atualmente não possui uma análise rica incorporada para detecção de anomalias e ameaças na telemetria de rede. Ou seja, seguindo o ciclo de vida descrito acima, você terá que descrever os modelos de violações por conta própria e, em seguida, usá-los no sistema em operação (não há modelos incorporados lá).

Existem, é claro, extensões mais avançadas para ELK, que já incorporam alguns modelos de detecção de anomalias na telemetria de rede, mas essas extensões custam dinheiro e aqui a questão é se vale a pena — escrever um modelo semelhante por conta própria, comprar a implementação para seu sistema de monitoramento ou adquirir uma solução pronta da classe Network Traffic Analysis.

De fato, não quero entrar na polêmica sobre o que é melhor: gastar dinheiro e comprar uma solução pronta para monitorar anomalias e ameaças na telemetria de rede (por exemplo, Cisco Stealthwatch) ou entender como funciona e adaptar o SiLK, ELK ou nfdump ou OSU Flow Tools (me referindo aos últimos dois). falou Cada um escolhe para si e cada um tem seus motivos para optar por uma das duas alternativas. Eu só queria mostrar que a telemetria de rede é uma ferramenta muito importante na garantia da segurança da infraestrutura interna e não deve ser negligenciada, para não se juntar à lista de empresas cujo nome é mencionado na mídia com epítetos como 'invadida', 'que não cumpria requisitos de segurança da informação', 'que não se preocupa com a segurança de seus dados e dados de clientes'.

Concluindo, gostaria de listar algumas dicas-chave que deveriam ser seguidas ao estabelecer o monitoramento da segurança da informação em sua infraestrutura interna:

Não se limite apenas ao perímetro! Use (e escolha) a infraestrutura de rede não apenas para transmitir tráfego de um ponto A para um ponto B, mas também para abordar questões de cibersegurança.
Estude os mecanismos existentes de monitoramento de segurança da informação em seu equipamento de rede e utilize-os.
Para o monitoramento interno, dê preferência à análise de telemetria — ela permite detectar até 80-90% de todos os incidentes de segurança da informação, fazendo o que é impossível com a captura de pacotes de rede e economizando espaço para o armazenamento de todos os eventos de segurança da informação.
Para monitorar fluxos, use Netflow v9 ou IPFIX — eles fornecem mais informações no contexto de segurança e permitem monitorar não apenas IPv4, mas também IPv6, MPLS, etc.
Utilize um protocolo de fluxo não amostrado — ele fornece mais informações para a detecção de ameaças. Por exemplo, Netflow ou IPFIX.
Verifique a carga do seu equipamento de rede – pode ser que ele não consiga lidar com o processamento do protocolo flow. Nesse caso, considere o uso de sensores virtuais ou de um Netflow Generation Appliance.
Implemente o controle principalmente no nível de acesso – isso permitirá que você veja 100% de todo o tráfego.
Se não houver outra escolha e você usar equipamentos de rede russos, escolha aqueles que suportam protocolos flow ou que possuem portas SPAN/RSPAN.
Combine sistemas de detecção/prevenção de intrusões/ataques nas bordas com sistemas de análise de fluxos na rede interna (incluindo nas nuvens).

Quanto ao último conselho, gostaria de trazer uma ilustração que já mencionei antes. Você pode ver que, enquanto anteriormente o serviço de segurança da informação da Cisco quase que totalmente construía seu sistema de monitoramento da segurança da informação baseado em sistemas de detecção de intrusões e métodos de assinatura, agora apenas 20% dos incidentes são associados a eles. Outros 20% vêm de sistemas de análise de fluxos, o que indica que essas soluções não são um capricho, mas uma ferramenta real nas atividades dos serviços de segurança da informação das empresas modernas. Além disso, você tem para a sua implementação a coisa mais importante – a infraestrutura de rede, cujo investimento pode ser adicionalmente protegido ao atribuir à rede também funções de monitoramento da segurança da informação.

Eu intencionalmente não abordei o tema da resposta a anomalias ou ameaças detectadas nos fluxos de rede, mas acredito que está claro que o monitoramento não deve se limitar apenas à detecção de ameaças. Deve haver uma resposta, preferencialmente em modo automático ou automatizado. Mas isso já é tema para um material separado.