Quando se trata de monitorar a segurança de uma rede interna corporativa ou departamental, muitos associam isso ao controle de vazamentos de informações e à implementação de soluções DLP. E se você tentar esclarecer a questão e perguntar como detectar ataques na rede interna, a resposta será, via de regra, uma menção aos sistemas de detecção de intrusão (IDS). E o que era a única opção há 10 ou 20 anos está hoje a tornar-se um anacronismo. Existe uma opção mais eficaz e, em alguns lugares, a única possível para monitorar uma rede interna - usando protocolos de fluxo, que foram originalmente projetados para procurar problemas de rede (solução de problemas), mas com o tempo se transformaram em uma ferramenta de segurança muito interessante. Falaremos sobre quais protocolos de fluxo existem e quais são melhores para detectar ataques de rede, onde é melhor implementar o monitoramento de fluxo, o que procurar ao implantar tal esquema e até como “levantar” tudo isso em equipamentos domésticos no âmbito deste artigo.
Não vou insistir na questão “Por que é necessária a monitorização da segurança da infra-estrutura interna?” A resposta parece ser clara. Mas se, no entanto, você quiser ter certeza mais uma vez de que hoje não pode viver sem ele, um pequeno vídeo sobre como você pode penetrar em uma rede corporativa protegida por um firewall de 17 maneiras. Portanto, assumiremos que entendemos que o monitoramento interno é algo necessário e só falta entender como ele pode ser organizado.
Destaco três fontes de dados principais para monitorizar a infraestrutura ao nível da rede:
- tráfego “bruto” que capturamos e enviamos para análise a determinados sistemas de análise,
- eventos de dispositivos de rede pelos quais o tráfego passa,
- informações de tráfego recebidas através de um dos protocolos de fluxo.
A captura de tráfego bruto é a opção mais popular entre os especialistas em segurança, porque apareceu historicamente e foi a primeira. Os sistemas convencionais de detecção de intrusão em redes (o primeiro sistema comercial de detecção de intrusão foi o NetRanger do Wheel Group, adquirido em 1998 pela Cisco) estavam precisamente envolvidos na captura de pacotes (e sessões posteriores) nos quais certas assinaturas eram procuradas (“regras decisivas” em terminologia FSTEC), sinalizando ataques. Claro, você pode analisar o tráfego bruto não apenas usando IDS, mas também usando outras ferramentas (por exemplo, Wireshark, tcpdum ou a funcionalidade NBAR2 no Cisco IOS), mas elas geralmente não possuem a base de conhecimento que distingue uma ferramenta de segurança da informação de uma ferramenta comum. Ferramenta de TI.
Então, sistemas de detecção de ataques. O método mais antigo e popular de detecção de ataques de rede, que faz um bom trabalho no perímetro (não importa o que seja - corporativo, data center, segmento, etc.), mas falha em redes modernas comutadas e definidas por software. No caso de uma rede construída com base em switches convencionais, a infraestrutura de sensores de detecção de ataques torna-se muito grande - será necessário instalar um sensor em cada conexão ao nó no qual deseja monitorar os ataques. Qualquer fabricante, é claro, ficará feliz em lhe vender centenas e milhares de sensores, mas acho que seu orçamento não pode suportar tais despesas. Posso dizer que mesmo na Cisco (e nós somos os desenvolvedores do NGIPS) não poderíamos fazer isso, embora pareça que a questão do preço está diante de nós. Eu não deveria ficar de pé - a decisão é nossa. Além disso, surge a pergunta: como conectar o sensor nesta versão? Na lacuna? E se o próprio sensor falhar? Requer um módulo de bypass no sensor? Usar divisores (toque)? Tudo isso encarece a solução e a torna inacessível para uma empresa de qualquer porte.
Você pode tentar “travar” o sensor em uma porta SPAN/RSPAN/ERSPAN e direcionar o tráfego das portas de switch necessárias para ele. Esta opção elimina parcialmente o problema descrito no parágrafo anterior, mas apresenta outro - a porta SPAN não pode aceitar absolutamente todo o tráfego que será enviado para ela - não terá largura de banda suficiente. Você terá que sacrificar alguma coisa. Deixe alguns nós sem monitoramento (então você precisa priorizá-los primeiro) ou não envie todo o tráfego do nó, mas apenas um determinado tipo. De qualquer forma, podemos perder alguns ataques. Além disso, a porta SPAN pode ser utilizada para outras necessidades. Como resultado, teremos que revisar a topologia de rede existente e possivelmente fazer ajustes nela para cobrir ao máximo sua rede com o número de sensores que você possui (e coordenar isso com a TI).
E se a sua rede usar rotas assimétricas? E se você implementou ou planeja implementar SDN? E se você precisar monitorar máquinas virtualizadas ou contêineres cujo tráfego não chega ao switch físico? Estas são perguntas que os fornecedores tradicionais de IDS não gostam porque não sabem como respondê-las. Talvez eles o convençam de que todas essas tecnologias da moda são um exagero e você não precisa delas. Talvez eles falem sobre a necessidade de começar aos poucos. Ou talvez digam que você precisa colocar um debulhador poderoso no centro da rede e direcionar todo o tráfego para ele usando balanceadores. Qualquer que seja a opção oferecida a você, você precisa entender claramente como ela combina com você. E só depois disso tome a decisão de escolher uma abordagem para monitorar a segurança da informação da infraestrutura de rede. Voltando à captura de pacotes, quero dizer que este método continua a ser muito popular e importante, mas o seu principal objectivo é o controlo de fronteiras; limites entre a sua organização e a Internet, limites entre o data center e o resto da rede, limites entre o sistema de controle de processos e o segmento corporativo. Nestes locais, os IDS/IPS clássicos ainda têm o direito de existir e de cumprir bem as suas tarefas.
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 mecanismo principal, pois permite detectar apenas uma pequena classe de intrusões. Além disso, é inerente a alguma reatividade - primeiro o ataque deve ocorrer, depois deve ser registrado por um dispositivo de rede, o que de uma forma ou de outra sinalizará um problema de segurança da informação. Existem várias dessas maneiras. Pode ser syslog, RMON ou SNMP. Os dois últimos protocolos para monitoramento de rede no contexto de segurança da informação são utilizados apenas se precisarmos detectar um ataque DoS no próprio equipamento de rede, pois utilizando RMON e SNMP é possível, por exemplo, monitorar a carga na central do dispositivo processador ou suas interfaces. Este é um dos “mais baratos” (todos têm syslog ou SNMP), mas também o mais ineficaz de todos os métodos de monitoramento da segurança da informação da infraestrutura interna - muitos ataques são simplesmente ocultados dela. Claro, eles não devem ser negligenciados, e a mesma análise de syslog ajuda a identificar oportunamente alterações na configuração do próprio dispositivo, seu comprometimento, mas não é muito adequada para detectar ataques em toda a rede.
A terceira opção é analisar 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 threading consiste necessariamente em três componentes:
- Geração ou exportação de fluxo. Essa função geralmente é atribuída a um roteador, switch ou outro dispositivo de rede que, ao passar o tráfego de rede por si mesmo, permite extrair dele parâmetros-chave, que são então transmitidos ao módulo de coleta. Por exemplo, a Cisco oferece suporte ao protocolo Netflow não apenas em roteadores e switches, inclusive virtuais e industriais, mas também em controladores sem fio, firewalls e até servidores.
- Fluxo de coleta. Considerando que uma rede moderna costuma possuir mais de um dispositivo de rede, surge o problema de coleta e consolidação de fluxos, que é resolvido por meio dos chamados coletores, que processam os fluxos recebidos e depois os transmitem para análise.
- Análise de fluxo O analisador assume a tarefa intelectual principal e, aplicando vários algoritmos aos fluxos, tira certas conclusões. Por exemplo, como parte de uma função de TI, esse analisador pode identificar gargalos de rede ou analisar o perfil de carga de tráfego para otimizar ainda mais a rede. E para segurança da informação, esse analisador pode detectar vazamentos de dados, disseminação de código malicioso ou ataques DoS.
Não pense que esta arquitetura de três camadas é muito complicada - todas as outras opções (exceto, talvez, sistemas de monitoramento de rede que trabalham com SNMP e RMON) também funcionam de acordo com ela. Dispomos de um gerador de dados para análise, que pode ser um dispositivo de rede ou um sensor independente. Dispomos de um sistema de recolha de alarmes e de um sistema de gestão de toda a infraestrutura de monitorização. Os dois últimos componentes podem ser combinados em um único nó, mas em redes mais ou menos grandes eles geralmente estão espalhados por pelo menos dois dispositivos para garantir escalabilidade e confiabilidade.
Ao contrário da análise de pacotes, que se baseia no estudo dos dados do cabeçalho e do corpo de cada pacote e das sessões em que ele consiste, a análise de fluxo depende da coleta de metadados sobre o tráfego de rede. Quando, quanto, de onde e onde, como... essas são as questões respondidas pela análise de telemetria de rede utilizando diversos protocolos de fluxo. Inicialmente, eles foram usados para analisar estatísticas e encontrar problemas de TI na rede, mas depois, à medida que os mecanismos analíticos se desenvolveram, tornou-se possível aplicá-los à mesma telemetria para fins de segurança. Vale ressaltar novamente que a análise de fluxo não substitui ou substitui 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 fluxo que é mais adequada para monitorar a infraestrutura interna. Você tem dispositivos de rede (sejam eles operando em um paradigma definido por software ou de acordo com regras estáticas) que um ataque não pode ignorar. Ele pode ignorar um sensor IDS clássico, mas um dispositivo de rede que suporta o protocolo de fluxo não pode. Esta é a vantagem deste método.
Por outro lado, se você precisar de evidências para a aplicação da lei ou para sua própria equipe de investigação de incidentes, não poderá prescindir da captura de pacotes - a telemetria de rede não é uma cópia do tráfego que pode ser usada para coletar evidências; é necessário para uma rápida detecção e tomada de decisões no domínio da segurança da informação. Por outro lado, usando a análise de telemetria, você não pode “escrever” todo o tráfego de rede (se houver, a Cisco lida com data centers :-), mas apenas aquele que está envolvido no ataque. Nesse sentido, as ferramentas de análise de telemetria complementarão bem os mecanismos tradicionais de captura de pacotes, fornecendo comandos para captura e armazenamento seletivos. Caso contrário, você terá que ter uma infra-estrutura de armazenamento colossal.
Vamos imaginar uma rede operando a uma velocidade de 250 Mbit/s. Se quiser armazenar todo esse volume, você precisará de 31 MB de armazenamento 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 dados diários de uma rede com largura de banda de 10 Gbit/s, você precisará de 108 TB de armazenamento. Mas alguns reguladores exigem o armazenamento de dados de segurança por anos... O registro sob demanda, que a análise de fluxo ajuda a implementar, ajuda a reduzir esses valores em ordens de magnitude. A propósito, se falarmos sobre a proporção entre o volume de dados de telemetria de rede registrados e a captura completa de dados, então é de aproximadamente 1 para 500. Para os mesmos valores fornecidos acima, armazenando uma transcrição completa de todo o tráfego diário serão 5 e 216 GB, respectivamente (você pode até gravá-lo em uma unidade flash normal).
Se para ferramentas de análise de dados brutos de rede o método de captura é quase o mesmo de fornecedor para fornecedor, então no caso de análise de fluxo a situação é diferente. Existem várias opções de protocolos de fluxo, cujas diferenças você precisa conhecer no contexto de segurança. O mais popular é o protocolo Netflow desenvolvido pela Cisco. Existem diversas versões deste protocolo, diferindo em suas capacidades e na quantidade de informações de tráfego registradas. A versão atual é a nona (Netflow v9), com base na qual foi desenvolvido o padrão da indústria Netflow v10, também conhecido como IPFIX. Hoje, a maioria dos fornecedores de redes oferece suporte a Netflow ou IPFIX em seus equipamentos. Mas existem várias outras opções de protocolos de fluxo - sFlow, jFlow, cFlow, rFlow, NetStream, etc., dos quais sFlow é o mais popular. É este tipo 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 fato, e o sFlow? Eu destacaria vários dos principais. Primeiro, o Netflow possui campos personalizáveis pelo usuário, em oposição aos campos fixos do sFlow. E em segundo lugar, e isto é o mais importante no nosso caso, o sFlow coleta a chamada telemetria amostrada; em contraste com o sem amostra para Netflow e IPFIX. Qual a diferença entre eles?
Imagine que você decide ler o livro “”dos meus colegas - Gary McIntyre, Joseph Munitz e Nadem Alfardan (você pode baixar parte do livro no link). Você tem três opções para atingir seu objetivo: ler o livro inteiro, folheá-lo, parando a cada 10 ou 20 páginas, ou tentar encontrar uma releitura dos principais conceitos em um blog ou serviço como o SmartReading. Portanto, a telemetria sem amostragem lê cada “página” do tráfego da rede, ou seja, analisa os metadados de cada pacote. A telemetria amostrada é o estudo seletivo do tráfego na esperança de que as amostras selecionadas contenham o que você precisa. Dependendo da velocidade do canal, a telemetria amostrada será enviada para análise a cada 64, 200, 500, 1000, 2000 ou mesmo 10000 pacotes.
No contexto do monitoramento da segurança da informação, isso significa que a telemetria amostrada é adequada para detectar ataques DDoS, verificar e espalhar código malicioso, mas pode perder ataques atômicos ou de múltiplos pacotes que não foram incluídos na amostra enviada para análise. A telemetria sem amostragem não apresenta tais desvantagens. Com isso, o leque de ataques detectados é muito maior. Aqui está uma pequena lista de eventos que podem ser detectados usando ferramentas de análise de telemetria de rede.
É claro que alguns analisadores Netflow de código aberto não permitirão que você faça isso, pois sua principal tarefa é coletar telemetria e realizar análises básicas do ponto de vista de TI. Para identificar ameaças à segurança da informação com base no fluxo, é necessário equipar o analisador com vários motores e algoritmos, que irão identificar problemas de segurança cibernética com base em campos padrão ou personalizados do Netflow, enriquecer os dados padrão com dados externos de várias fontes de Threat Intelligence, etc.
Portanto, se você tiver escolha, escolha Netflow ou IPFIX. Mas mesmo que o seu equipamento funcione apenas com sFlow, como os fabricantes nacionais, mesmo neste caso você pode se beneficiar dele em um contexto de segurança.
No verão de 2019, analisei os recursos que os fabricantes russos de hardware de rede possuem e todos eles, excluindo NSG, Polygon e Craftway, anunciaram suporte para sFlow (pelo menos Zelax, Natex, Eltex, QTech, Rusteleteh).
A próxima questão que você enfrentará é onde implementar o suporte de fluxo para fins de segurança. Na verdade, a questão não está colocada de forma totalmente correta. Equipamentos modernos quase sempre suportam protocolos de fluxo. Portanto, eu reformularia a questão de forma diferente - onde é mais eficaz coletar telemetria do ponto de vista da segurança? A resposta será bastante óbvia - ao nível do acesso, onde verá 100% de todo o tráfego, onde terá informações detalhadas sobre hosts (MAC, VLAN, ID da interface), onde poderá até monitorar o tráfego P2P entre hosts, que é fundamental para a detecção e distribuição de códigos maliciosos. No nível central, você pode simplesmente não ver parte do tráfego, mas no nível do perímetro, você verá um quarto de todo o tráfego da sua rede. Mas se por algum motivo você tiver dispositivos estranhos em sua rede que permitem que invasores “entrem e saiam” sem contornar o perímetro, a análise da telemetria dele não lhe dará nada. Portanto, para cobertura máxima, recomenda-se habilitar a coleta de telemetria no nível de acesso. Ao mesmo tempo, é importante notar que mesmo que estejamos falando de virtualização ou contêineres, o suporte de fluxo também é frequentemente encontrado em switches virtuais modernos, o que permite controlar o tráfego lá também.
Mas já que levantei o assunto, preciso responder a pergunta: e se o equipamento, físico ou virtual, não suportar protocolos de fluxo? Ou é proibida a sua inclusão (por exemplo, em segmentos industriais para garantir confiabilidade)? Ou ativá-lo leva a uma alta carga da CPU (isso acontece em hardware mais antigo)? Para resolver esse problema, existem sensores virtuais especializados (sensores de fluxo), que são essencialmente divisores comuns que passam o tráfego por si mesmos e o transmitem na forma de fluxo para o módulo de coleta. É verdade que neste caso temos todos os problemas de que falamos acima em relação às ferramentas de captura de pacotes. Ou seja, é preciso compreender não apenas as vantagens da tecnologia de análise de fluxo, mas também suas limitações.
Outro ponto que é importante lembrar quando se fala em ferramentas de análise de fluxo. Se em relação aos meios convencionais de geração de eventos de segurança utilizarmos a métrica EPS (evento por segundo), então este indicador não é aplicável à análise de telemetria; ele é substituído por FPS (fluxo por segundo). Como no caso do EPS, ele não pode ser calculado antecipadamente, mas é possível estimar o número aproximado de threads que um determinado dispositivo gera dependendo de sua tarefa. Você pode encontrar na Internet tabelas com valores aproximados para diferentes tipos de dispositivos e condições empresariais, o que permitirá estimar quais licenças você precisa para ferramentas de análise e qual será sua arquitetura? O fato é que o sensor IDS é limitado por uma certa largura de banda que pode “puxar”, e o coletor de fluxo tem suas próprias limitações que devem ser compreendidas. Portanto, em redes grandes e distribuídas geograficamente geralmente existem vários coletores. Quando eu descrevi , já dei o número dos nossos coletores - são 21. E isso é para uma rede espalhada pelos cinco continentes e com cerca de meio milhão de dispositivos ativos).
Usamos nossa própria solução como sistema de monitoramento Netflow , que se concentra especificamente na solução de problemas de segurança. Possui muitos mecanismos integrados para detectar atividades anômalas, suspeitas e claramente maliciosas, o que permite detectar uma ampla gama de ameaças diferentes - desde criptomineração até vazamento de informações, desde a disseminação de código malicioso até fraude. Como a maioria dos analisadores de fluxo, o Stealthwatch é construído de acordo com um esquema de três níveis (gerador - coletor - analisador), mas é complementado com uma série de recursos interessantes que são importantes no contexto do material em consideração. Primeiro, ele se integra a soluções de captura de pacotes (como o Cisco Security Packet Analyzer), que permite gravar sessões de rede selecionadas para posterior investigação e análise aprofundadas. Em segundo lugar, especificamente para expandir as tarefas de segurança, desenvolvemos um protocolo nvzFlow especial, que permite “transmitir” a atividade de aplicativos em nós finais (servidores, estações de trabalho, etc.) em telemetria e transmiti-la ao coletor para análise posterior. Se em sua versão original o Stealthwatch funciona com qualquer protocolo de fluxo (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) no nível da rede, então o suporte ao nvzFlow permite a correlação de dados também no nível do nó. aumentando a eficiência de todo o sistema e vendo mais ataques do que os analisadores de fluxo de rede convencionais.
É claro que quando se fala em sistemas de análise Netflow do ponto de vista de segurança, o mercado não se limita a uma única solução da Cisco. Você pode usar soluções comerciais e gratuitas ou shareware. É muito estranho citar soluções de concorrentes como exemplos no blog da Cisco, então direi algumas palavras sobre como a telemetria de rede pode ser analisada usando duas ferramentas populares, semelhantes em nomes, mas ainda diferentes - SiLK e ELK.
SiLK é um conjunto de ferramentas (o System for Internet-Level Knowledge) para análise de tráfego, desenvolvido pela americana CERT/CC e que suporta, no contexto do artigo de hoje, Netflow (5º e 9º, as versões mais populares), IPFIX e sFlow e usando vários utilitários (rwfilter, rwcount, rwflowpack, etc.) para realizar diversas operações na telemetria da rede, a fim de detectar sinais de ações não autorizadas nela. Mas há alguns pontos importantes a serem observados. SiLK é uma ferramenta de linha de comando que realiza análises on-line inserindo comandos como este (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 confortável. Você pode usar a GUI do iSiLK, mas ela não facilitará muito sua vida, apenas resolvendo a função de visualização e não substituindo o analista. E este é o segundo ponto. Ao contrário das soluções comerciais, que já possuem uma base analítica sólida, algoritmos de detecção de anomalias, fluxo de trabalho correspondente, etc., no caso do SiLK você terá que fazer tudo isso sozinho, o que exigirá de você competências um pouco diferentes das de usar já pronto- ferramentas para usar. Isso não é bom nem ruim - é um recurso de quase todas as ferramentas gratuitas que pressupõem que você sabe o que fazer, e só vai te ajudar nisso (as ferramentas comerciais são menos dependentes das competências de seus usuários, embora também assumam que os analistas compreendam pelo menos os conceitos básicos de investigações e monitoramento de rede). Mas voltemos ao SiLK. O ciclo de trabalho do analista com ele fica assim:
- Formulando uma hipótese. Devemos entender o que procuraremos dentro da telemetria de rede, conhecer os atributos únicos pelos quais identificaremos certas anomalias ou ameaças.
- Construindo um modelo. Formulada uma hipótese, programamo-la utilizando o mesmo Python, shell ou outras ferramentas não incluídas no SiLK.
- Testando. Agora é a vez de verificar a veracidade da nossa hipótese, que é confirmada ou refutada usando os utilitários SiLK começando com 'rw', 'set', 'bag'.
- Análise de dados reais. Na 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 o nível de reconhecimento? » e assim por diante.
- Melhoria. Na fase final, melhoramos o que foi feito anteriormente - criamos templates, melhoramos e otimizamos o código, reformulamos e esclarecemos hipóteses, etc.
Este ciclo também será aplicável ao Cisco Stealthwatch, apenas o último automatiza ao máximo essas cinco etapas, reduzindo o número de erros do analista e aumentando a eficiência da detecção de incidentes. Por exemplo, no SiLK você pode enriquecer as estatísticas da rede com dados externos sobre IPs maliciosos usando scripts escritos à mão, e no Cisco Stealthwatch é uma função integrada que exibe imediatamente um alarme se o tráfego da rede contiver interações com endereços IP da lista negra.
Se você subir na pirâmide “paga” do software de análise de fluxo, depois do SiLK totalmente gratuito, haverá um ELK shareware, composto por três componentes principais - Elasticsearch (indexação, pesquisa e análise de dados), Logstash (entrada/saída de dados). ) e Kibana (visualização). Ao contrário do SiLK, onde você tem que escrever tudo sozinho, o ELK já possui muitas bibliotecas/módulos prontos (alguns pagos, outros não) que automatizam a análise da telemetria da rede. Por exemplo, o filtro GeoIP no Logstash permite associar endereços IP monitorados à sua localização geográfica (o Stealthwatch possui esse recurso integrado).
ELK também tem uma comunidade bastante grande que está completando os componentes que faltam para esta solução de monitoramento. Por exemplo, para trabalhar com Netflow, IPFIX e sFlow você pode usar o módulo , se você não estiver satisfeito com o módulo Logstash Netflow, que oferece suporte apenas ao Netflow.
Embora ofereça mais eficiência na coleta de fluxo e na busca nele, o ELK atualmente carece de análises integradas avançadas para detectar anomalias e ameaças na telemetria de rede. Ou seja, seguindo o ciclo de vida descrito acima, você terá que descrever de forma independente os modelos de violação e depois usá-los no sistema de combate (não há modelos integrados lá).
Existem, é claro, extensões mais sofisticadas para ELK, que já contêm alguns modelos para detecção de anomalias na telemetria de rede, mas tais extensões custam dinheiro e a questão é se o jogo vale a pena - escreva você mesmo um modelo semelhante, compre sua implementação para sua ferramenta de monitoramento, ou adquira solução pronta da classe Análise de Tráfego de Rede.
Em geral, não quero entrar no debate de que é melhor gastar dinheiro e comprar uma solução pronta para monitorar anomalias e ameaças em telemetria de rede (por exemplo, Cisco Stealthwatch) ou descobrir você mesmo e personalizar o mesmo SiLK, ELK ou nfdump ou OSU Flow Tools para cada nova ameaça (estou falando das duas últimas última vez)? Cada um escolhe por si e cada um tem seus próprios motivos para escolher qualquer uma das duas opções. Queria apenas mostrar que a telemetria de rede é uma ferramenta muito importante para garantir a segurança da rede da sua infraestrutura interna e você não deve negligenciá-la, para não entrar na lista de empresas cujo nome é citado na mídia junto com os epítetos “ hackeado”, “não conforme com os requisitos de segurança da informação””, “não pensando na segurança de seus dados e dos dados dos clientes”.
Para resumir, gostaria de listar as principais dicas que você deve seguir ao construir o monitoramento de segurança da informação da sua infraestrutura interna:
- Não se limite apenas ao perímetro! Utilize (e escolha) a infraestrutura de rede não apenas para mover o tráfego do ponto A para o ponto B, mas também para resolver problemas de segurança cibernética.
- Estude os mecanismos de monitoramento de segurança da informação existentes em seus equipamentos de rede e utilize-os.
- Para 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 da rede, fazendo o que é impossível na captura de pacotes de rede e economizando espaço para armazenar todos os eventos de segurança da informação.
- Para monitorar fluxos, use Netflow v9 ou IPFIX - eles fornecem mais informações em um contexto de segurança e permitem monitorar não apenas IPv4, mas também IPv6, MPLS, etc.
- Use um protocolo de fluxo sem amostragem – ele fornece mais informações para detectar ameaças. Por exemplo, Netflow ou IPFIX.
- Verifique a carga do seu equipamento de rede - talvez ele também não consiga lidar com o protocolo de fluxo. Então considere usar sensores virtuais ou Netflow Generation Appliance.
- Implemente o controle principalmente no nível de acesso - isso lhe dará a oportunidade de ver 100% de todo o tráfego.
- Se você não tiver escolha e estiver usando equipamento de rede russo, escolha um que suporte protocolos de fluxo ou tenha portas SPAN/RSPAN.
- Combine sistemas de detecção/prevenção de intrusões/ataques nas bordas e sistemas de análise de fluxo na rede interna (inclusive nas nuvens).
Em relação à última dica, gostaria de dar uma ilustração que já dei antes. Você vê que se anteriormente o serviço de segurança da informação da Cisco construía quase inteiramente seu sistema de monitoramento de segurança da informação com base em sistemas de detecção de intrusão e métodos de assinatura, agora eles respondem por apenas 20% dos incidentes. Outros 20% recaem sobre sistemas de análise de fluxo, o que sugere que essas soluções não são um capricho, mas uma verdadeira ferramenta nas atividades de serviços de segurança da informação de uma empresa moderna. Além disso, você tem o que há de mais importante para sua implementação - infraestrutura de rede, cujos investimentos podem ser ainda mais protegidos atribuindo funções de monitoramento de segurança da informação à rede.
Não abordei especificamente o tema da resposta a anomalias ou ameaças identificadas nos fluxos de rede, mas penso que já está claro que a monitorização não deve terminar apenas com a detecção de uma ameaça. Deve ser seguido de uma resposta e de preferência em modo automático ou automatizado. Mas este é um tópico para um artigo separado.
Informações adicionais:
PS. Se for mais fácil para você ouvir tudo o que foi escrito acima, você pode assistir à apresentação de uma hora que serviu de base para esta nota.
Fonte: habr.com