Non hai moito tempo, Splunk engadiu outro modelo de licenza: licenzas baseadas en infraestruturas (
Parece arrepiante, pero ás veces esta arquitectura funciona en produción. A complexidade mata a seguridade e, en xeral, mata todo. De feito, para tales casos (falo de reducir o custo de propiedade) hai toda unha clase de sistemas: Xestión central de rexistros (CLM). Sobre iso
- Use as capacidades e ferramentas de CLM cando existan limitacións orzamentarias e de persoal, requisitos de vixilancia de seguridade e requisitos de casos de uso específicos.
- Implementa CLM para mellorar as capacidades de recollida e análise de rexistros cando unha solución SIEM resulta demasiado cara ou complexa.
- Invista en ferramentas CLM con almacenamento eficiente, busca rápida e visualización flexible para mellorar a investigación/análise de incidentes de seguridade e apoiar a caza de ameazas.
- Asegúrese de que se teñan en conta os factores e consideracións aplicables antes de implementar unha solución CLM.
Neste artigo falaremos sobre as diferenzas nos enfoques de licenzas, entenderemos CLM e falaremos dun sistema específico desta clase:
Ao comezo deste artigo, falei sobre o novo enfoque das licenzas de Splunk. Os tipos de licenza pódense comparar coas tarifas de aluguer de vehículos. Imaxinemos que o modelo, en canto ao número de CPUs, é un coche económico con quilometraxe ilimitada e gasolina. Podes ir a calquera lugar sen restricións de distancia, pero non podes ir moi rápido e, en consecuencia, percorrer moitos quilómetros ao día. A licenza de datos é semellante a un coche deportivo cun modelo de quilometraxe diaria. Podes conducir temerariamente en longas distancias, pero terás que pagar máis por superar o límite de quilometraxe diaria.
Para beneficiarse das licenzas baseadas na carga, cómpre ter a menor proporción posible de núcleos de CPU e GB de datos cargados. Na práctica isto significa algo así como:
- O menor número posible de consultas aos datos cargados.
- O menor número de usuarios posibles da solución.
- Datos o máis sinxelos e normalizados posible (para que non haxa necesidade de desperdiciar ciclos da CPU no procesamento e análise posterior de datos).
O máis problemático aquí son os datos normalizados. Se queres que un SIEM sexa un agregador de todos os rexistros dunha organización, require un gran esforzo na análise e post-procesamento. Non esquezas que tamén hai que pensar nunha arquitectura que non se derrube baixo a carga, é dicir. serán necesarios servidores adicionais e, polo tanto, procesadores adicionais.
A licenza de volume de datos baséase na cantidade de datos que se envían ás fauces do SIEM. As fontes de datos adicionais están castigadas co rublo (ou outra moeda) e isto faiche pensar no que realmente non querías recoller. Para burlar este modelo de licenza, pode morder os datos antes de que se inxecten no sistema SIEM. Un exemplo desta normalización antes da inxección é Elastic Stack e algúns outros SIEM comerciais.
Como resultado, temos que a licenza por infraestrutura é efectiva cando precisa recompilar só determinados datos cun procesamento previo mínimo, e a licenza por volume non che permitirá recoller todo. A busca dunha solución intermedia leva aos seguintes criterios:
- Simplifica a agregación e normalización de datos.
- Filtrado de datos ruidosos e menos importantes.
- Proporcionar capacidades de análise.
- Enviar datos filtrados e normalizados a SIEM
Como resultado, os sistemas SIEM obxectivo non terán que desperdiciar enerxía adicional da CPU no procesamento e poden beneficiarse de identificar só os eventos máis importantes sen reducir a visibilidade do que está a suceder.
Idealmente, tal solución de middleware tamén debería proporcionar capacidades de detección e resposta en tempo real que se poidan usar para reducir o impacto de actividades potencialmente perigosas e agregar todo o fluxo de eventos nunha cantidade útil e sinxela de datos cara ao SIEM. Ben, entón SIEM pódese usar para crear agregacións, correlacións e procesos de alerta adicionais.
Esa mesma misteriosa solución intermedia non é outra que CLM, que mencionei ao comezo do artigo. Así o ve Gartner:
Agora podes tentar descubrir como InTrust cumpre coas recomendacións de Gartner:
- Almacenamento eficiente para os volumes e tipos de datos que hai que almacenar.
- Alta velocidade de busca.
- As capacidades de visualización non son o que require CLM básico, pero a caza de ameazas é como un sistema de BI para a seguridade e a análise de datos.
- Enriquecemento de datos para enriquecer datos brutos con datos contextuais útiles (como xeolocalización e outros).
Quest InTrust usa o seu propio sistema de almacenamento con compresión de datos de ata 40:1 e deduplicación de alta velocidade, o que reduce a sobrecarga de almacenamento para os sistemas CLM e SIEM.
Consola de busca de seguridade de TI cunha busca similar a Google
Un módulo especializado de busca de seguridade de TI (ITSS) baseado na web pode conectarse aos datos de eventos no repositorio de InTrust e ofrece unha interface sinxela para buscar ameazas. A interface simplifícase ata o punto de que actúa como Google para os datos do rexistro de eventos. ITSS usa cronogramas para os resultados das consultas, pode combinar e agrupar campos de eventos e axuda eficazmente na caza de ameazas.
InTrust enriquece os eventos de Windows con identificadores de seguridade, nomes de ficheiros e identificadores de inicio de sesión de seguranza. InTrust tamén normaliza os eventos nun esquema W6 sinxelo (Quen, Que, Onde, Cando, Quen e De onde) para que os datos de diferentes fontes (eventos nativos de Windows, rexistros de Linux ou syslog) poidan verse nun único formato e nun único formato. consola de busca.
InTrust admite capacidades de alerta, detección e resposta en tempo real que se poden usar como un sistema tipo EDR para minimizar os danos causados por actividade sospeitosa. As regras de seguridade integradas detectan, pero non se limitan a, as seguintes ameazas:
- Pulverización de contrasinal.
- Kerberoasting.
- Actividade sospeitosa de PowerShell, como a execución de Mimikatz.
- Procesos sospeitosos, por exemplo, o ransomware LokerGoga.
- Cifrado mediante rexistros CA4FS.
- Inicia sesión cunha conta privilexiada nas estacións de traballo.
- Ataques de adiviñar contrasinais.
- Uso sospeitoso de grupos de usuarios locais.
Agora mostrareiche algunhas capturas de pantalla do propio InTrust para que poidas ter unha impresión das súas capacidades.
Filtros predefinidos para buscar posibles vulnerabilidades
Un exemplo de conxunto de filtros para recoller datos brutos
Un exemplo de uso de expresións regulares para crear unha reacción a un evento
Exemplo cunha regra de busca de vulnerabilidades de PowerShell
Base de coñecemento integrada con descricións de vulnerabilidades
InTrust é unha poderosa ferramenta que se pode usar como solución autónoma ou como parte dun sistema SIEM, como describín anteriormente. Probablemente a principal vantaxe desta solución é que pode comezar a usalo inmediatamente despois da instalación, porque InTrust ten unha gran biblioteca de regras para detectar ameazas e responder a elas (por exemplo, bloquear un usuario).
No artigo non falei de integracións en caixa. Pero inmediatamente despois da instalación, pode configurar o envío de eventos a Splunk, IBM QRadar, Microfocus Arcsight ou a través dun webhook a calquera outro sistema. A continuación móstrase un exemplo dunha interface de Kibana con eventos de InTrust. Xa existe integración co Elastic Stack e, se utilizas a versión gratuíta de Elastic, InTrust pódese utilizar como ferramenta para identificar ameazas, realizar alertas proactivas e enviar notificacións.
Espero que o artigo dese unha idea mínima sobre este produto. Estamos preparados para darche InTrust para probar ou realizar un proxecto piloto. A aplicación pódese deixar en
Lea os nosos outros artigos sobre seguridade da información:
Fonte: www.habr.com