Adquisición de software tipo SIEM para monitoreo de redes y análisis de compromisos

El bien ofertado cumple con las especificaciones requeridas (SI/NO)

Indicar taxativa y detalladamente el cumplimiento de lo Ofertado. Incluir Referencia (Documento/Sección/

Ítem/pagina)

Cantidad de Endpoints: 50

Cantidad de Eventos por segundo: 500

Cantidad de Agentes: 25

1. Capacidades mínimas:

• Análisis de red en tiempo real

• Seguridad y análisis de cumplimiento
• Panel de control único
• Arquitectura a escalable a nube
• Inventario de activos de autoaprendizaje
• Capacidad multi tenan
• Soporte MSP/MSSP
• Capacidad de realizar análisis correlacionales para SOC y NOC
• MITRE ATT&CK IT e ICS

2. El software de administración de eventos de seguridad  debe proporcionar una arquitectura distribuida escalable con las siguientes características:
   1. Componentes de la Colección, en adelante denominados Recopiladores, se debe poder proporcionar como un dispositivo virtual o un dispositivo físico.
   2. Capacidad de reenvío de datos de eventos al nivel de almacenamiento y correlación.
   3. Los recopiladores deben poder almacenar en caché los datos en caso de que el nivel de almacenamiento y correlación deje de estar disponible. El recopilador debe mantener los registros en caché hasta su capacidad de almacenamiento.
   4. Los recopiladores deberán poder limitar el ancho de banda utilizado para la carga de eventos.
   5. Los recopiladores deberán poder comprimir los datos antes de enviarlos al nivel de almacenamiento y correlación.
   6. Los recopiladores se deben poder comunicar con el nivel de almacenamiento y correlación a través de HTTPS. La dirección de la comunicación es DESDE los recopiladores hasta el nivel de almacenamiento y correlación.
   7. Si un recopilador falla, se debe poder implementar un recopilador de reemplazo simplemente volviendo a registrar un nuevo dispositivo Collector con el nivel de almacenamiento y correlación.
   8. Los recopiladores deberían ser capaces de procesar al menos 10.000 EPS
   1. Los recopiladores deben realizar el proceso de descubrimiento y recopilar datos de rendimiento utilizando diferentes protocolos como SNMP, OMI, SSH.
   10. Los recopiladores deberán poder procesar la información de NetFlow
   11. Capacidad de actualizar recopiladores automáticamente con nuevos analizadores una vez que se actualicen en el sistema de gestión central SIEM.
   50. Un recopilador debe poder manejar registros de múltiples al mismo tiempo.
   1000. Los recopiladores deben administrarse desde la consola web, evitando la necesidad de conectarse a cada recopilador y realizar la actualización individualmente.
   14. Los recopiladores deben admitir la comunicación indirecta con el resto de los componentes a través de proxy HTTP.
   15. Los recopiladores deben poder recibir nuevos analizadores en las actualizaciones de contenido sin necesidad de actualización.

3. La solución debe admitir los siguientes modelos de implementación:
   1. Nube
   2. En las instalaciones
      1. Virtual
      2. Hardware
   3. Híbrido

4. La solución también debe estar disponible como SaaS, en más de 3 regiones, certificada SOC2 Tipo 2 y con licencia basada en:
   1. potencia de cálculo
   2. Almacenamiento en línea
   3. Almacenamiento de archivos

5. El nivel de correlación y almacenamiento SIEM ahora denominado SIEM Cluster debería:
   1. Utilice dispositivos virtuales (VA), así como físicos
   2. Capacidad de proporcionar VA para:
      1. Vmware
      2. Hiper-V
      3. KVM
      4. AWS
      5. Azur
      6. PCG
   3. El clúster deberá poder ser escalable agregando dispositivos adicionales (virtuales o físicos) al mismo. Esta capacidad de escalamiento horizontal debe:
      1. Proporciona correlación de reglas distribuidas en memoria y en tiempo real entre todos los componentes del clúster.
      2. La carga del recopilador al clúster se deberá  poder cargar en cualquier dispositivo del clúster y la correlación en forma automática.
      3. Proporcionar informes distribuidos y análisis en todo el clúster SIEM. Automatizado sin necesidad de especificar qué componente necesita ejecutar una búsqueda, sino que debería gestionarse dinámicamente.
   4. El clúster SIEM local no debe limitar la cantidad de datos de eventos que se almacenan. Este límite solo debe depender de la cantidad de almacenamiento que se proporciona. La licencia no debe basarse en el almacenamiento, como GB por día/semana/mes.
   5. El SIEM Cluster debe poder escalarse, esto significa que SIEM Cluster puede comenzar con un solo dispositivo y escalar agregando más dispositivos. Los datos de eventos se pueden almacenar en un disco virtual cuando se trabaja con un solo dispositivo y también en NFS, Clickhouse, ElasticSearch o AWS EFS o ElasticSearch Cloud de Amazon cuando se trabaja con SIEM Cluster (múltiples VA)
   6. Los VA agregados deben tener la capacidad de configurarse para procesar eventos y ejecutar consultas o estar dedicados a consultas.
   7. El clúster SIEM debe poder escalar a al menos 500 000 EPS
   8. El clúster SIEM debe poder almacenar tanto el registro de eventos sin procesar como el registro de eventos analizado/datos normalizados en la misma base de datos.
   1. No debe ser necesario un nivel de "almacenamiento" separado que filtre o envíe un subconjunto de eventos reenviados por los recopiladores a un nivel de correlación. El clúster SIEM debe poder procesar todos los eventos reenviados por el nivel de recopilación.
   10. Los datos del evento deben almacenarse en modo comprimido.
   11. Capacidad de interactuar con Elasticsearch (ES) proporcionado por el cliente como base de datos de eventos y el cliente puede ejecutar herramientas Elastic en la base de datos de Elasticsearch.
   50. Cuando se utiliza ES, el SIEM debe proporcionar y administrar niveles de almacenamiento activo y caliente con ES.
   1000. Cuando se usa ES, no debería haber ninguna diferencia perceptible en la GUI.
   14. Capacidad de utilizar base de datos relacional para almacenar plantillas, incidentes y otra información estructurada.
   15. El VA debería ejecutarse en Linux y tener la capacidad de actualizar los paquetes del sistema operativo.

6. El SIEM debe poder recopilar contexto adicional más allá de los datos de registro de los dispositivos y esto debe lograrse mediante:
   1. Descubriendo activamente los dispositivos dentro de la red sin un agente y utilizando protocolos estándar como:
      1. SNMP
      2. WMI
      3. SDK de máquina virtual
      4. OPSEC
      5. JDBC
      6. Telnet
      7. SSH
      8. JMX
      9. API REST
   2. Capacidad para monitorear el estado y la capacidad de respuesta de servicios que incluyen DNS, FTP/SCP, TCP/UDP genérico, ICMP, JDBC, LDAP, SMTP, IMAP4, POP3, POP3S, SMTP, SSH y Web: HTTP, HTTPS.
      1. Los resultados de este monitor de disponibilidad se pueden utilizar para calcular la capacidad del servicio, como por ejemplo que la disponibilidad de un servicio esté disponible en un 99%.
   3. Una vez descubierto, el dispositivo debe presentarse en una base de datos de gestión de configuración (CMDB) integrada dentro de la solución SIEM, no como un módulo separado.
   4. Los dispositivos descubiertos deben asignarse dinámicamente a grupos CMDB según las propiedades personalizadas definidas por el cliente.
   5. La CMDB debe almacenar:
      1. Versión/Firmware/SO instalado en el dispositivo
      2. Número de serie del dispositivo
      3. Interfaces configuradas en el dispositivo junto con
         1. Nombre de la interfaz
         2. IP y subred
         3. Estado de la interfaz (habilitado, deshabilitado)
         4. Cualquier nivel de seguridad configurado en el dispositivo
         5. La velocidad de la interfaz
         6. La velocidad y el nombre de la interfaz deben ser editables.
      4. Valores personalizados según sea necesario.
      5. Procesos que se ejecutan en el dispositivo o sistema operativo.
      6. Alerte cuando haya un cambio en el estado del proceso mediante el monitoreo activo utilizando protocolos como se describe en los protocolos 3.a. Por ejemplo alertar cuando un proceso o servicio se detiene.
   6. Los dispositivos deben descubrirse automáticamente dentro de los grupos en CMDB, por ejemplo, el grupo de Windows Server o el grupo de Firewall, como resultado del proceso de descubrimiento.
   7. Las aplicaciones que se ejecutan en los dispositivos deben descubrirse automáticamente y la CMDB debe tener un grupo de aplicaciones que complete automáticamente los dispositivos del grupo. Por ejemplo, el grupo de aplicaciones "Servidores IIS" debería enumerar todos los dispositivos que ejecutan Microsoft IIS.
   8. Importe información a la CMDB a través de CSV.
   1. Información de CMDB en sistemas externos.
   10. Ser capaz de informar sobre toda la información dentro de la CMDB:
       1. Informe sobre firmware de dispositivos o número de versión.

1. 10. 2. Proporcione un informe de auditoría con aprobación/rechazo si el dispositivo tiene la versión adecuada de Versión/Firmware/OS instalada en el dispositivo.
   11. Una vez que se completa el descubrimiento activo de los dispositivos, el SIEM debe tener una plantilla incorporada que definirá automáticamente qué métricas se recopilarán para los dispositivos y los intervalos de recopilación.
   50. Las métricas de rendimiento recopiladas deben incluir:
       1. Utilización de la interfaz, errores, bytes enviados y recibidos.

1. 1. 2. UPC
      3. Memoria
      4. Disco
      5. Utilización del proceso

7. El SIEM debe proporcionar una interfaz de análisis unificada que permita que el mismo lenguaje de consulta analice tanto los datos de registro como los datos de rendimiento.

8. Analytics debe admitir consultas anidadas donde un usuario puede usar una consulta para filtrar los resultados de la consulta anterior.

9. El sistema debería poder colectar eventos en los recopiladores que no sean relevantes o no sean necesarios.

10. Tanto los datos sin procesar como los analizados y enriquecidos deben pasarse al clúster SIEM desde los recopiladores. No se debe utilizar una base de datos de eventos separada para datos sin procesar y datos analizados.
11. Los analizadores deben realizar el procesamiento de los datos del evento en el momento de la recepción del evento.

12. Todos los analizadores deberían poder modificarse y personalizarse.

13. Los analizadores personalizados deberían poder crearse y definirse en la GUI sin acceso a la CLI.

14. Se pueden agregar nuevos atributos (variables analizadas), dispositivos y tipos de eventos a través de la GUI sin acceso a la CLI.

15. Los analizadores deben definirse en un marco XML con las siguientes capacidades:
    1. Capacidad para definir patrones que se repiten como variables.
    2. Capacidad para definir funciones para identificar pares clave-valor
    3. Capacidad para definir funciones para analizar eventos estructurados JSON.
    4. Capacidad para realizar funciones de prueba y caso dentro del analizador.
    5. Capacidad para realizar transformaciones en los datos en la etapa de análisis.

16. Los dispositivos deberán poder monitorear sin agentes a través de SSH, telnet WMI, JMX y PowerShell.

17. Capacidad para recopilar eventos de Windows a través de WMI/OMI y agente.

18. El SIEM debe proporcionar un Agente de Windows que tenga las siguientes capacidades:
    1. Agentes administrados centralmente a través del dispositivo SIEM. No se debe utilizar ningún dispositivo o consola de administración independiente.
    2. Capaz de recopilar registros de archivos de texto en dispositivos Windows
    3. Capaz de recopilar registros de eventos distintos de Seguridad, Sistema y Aplicación
    4. Realizar monitoreo de integridad de archivos
    5. Realizar monitoreo de registro
    6. Monitor para dispositivos extraíbles
    7. Ejecute comandos de PowerShell y envíe resultados como registros
    8. Ejecute comandos WMI y envíe resultados como registros
    1. El agente de Windows debe enviar datos de eventos a los componentes SIEM cifrados mediante HTTPS.
    10. Detectar cambios de propiedad y permisos de archivos.
    11. Capacidad para enviar archivos monitoreados desde los agentes al VA, donde se mantiene un registro de auditoría de los cambios de archivos en la base de datos.

19. El SIEM debe proporcionar acceso basado en roles para restringir el acceso a los datos y también restringir el acceso a la GUI.

20. El SIEM deberá poder descubrir Active Directory y LDAP y mostrar la estructura y el contenido del directorio en la GUI.

21. El directorio se puede utilizar en condiciones de filtro dentro de informes y análisis.

22. Los métodos de autenticación externos deben ser compatibles e incluir:
    1. LDAP
    2. RADIUS
    3. SAML

23. Capacidad para integrar feeds de Threat Intelligence (TI):
    1. La integración de archivos CSV se puede realizar a través de la GUI
    2. Integración vía API REST con diferentes formatos de datos soportados (CSV, Personalizado, STIX)
    3. Soporte para STIX/TAXII
    4. Capacidad de descubrimiento:
       1. Direcciones IP
       2. Dominios
       3. hashes
       4. URL
       5. Nombres de procesos de malware
    5. Capacidad de admitir al menos 200.000 entradas
    6. Se deben proporcionar varias integraciones a TI comercial de forma inmediata
    7. Se deben proporcionar varias integraciones a TI de código abierto de forma inmediata
    8. Capacidad de correlacionar datos de TI en tiempo real, en memoria, con datos de eventos.
    1. Capacidad de correlacionar datos de TI con datos de eventos históricos.

24. Capacidad para consultar eventos en una vista analítica en modo de transmisión en tiempo real, de modo que se informe sobre los eventos antes de almacenarlos en el disco.

25. Proporcione informes listos para usar, sin costo adicional, para:
    1. PCI-DSS
    2. HIPAA
    3. SOX
    4. NERC
    5. FISMA
    6. ISO 27001
    7. GLBA
    8. GPG13
    1. Controles críticos SANS
    10. CEI
    11. COBIT
    50. GLBA
    1000. HIPAA
    14. NERC
    15. NESA Emiratos Árabes Unidos
    16. NIST800-53
    17. NIST800-171
    18. ECC de KSA

26. Capacidad para exportar e importar paneles, informes y reglas a través de XML.
27. Capacidad para recopilar la configuración del dispositivo de red, identificar cambios y proporcionar comparaciones en paralelo.

28. Panel PCI que proporciona un estado Rojo Ámbar Verde del estado de registro de los dispositivos monitoreados.

29. Los paneles se pueden presentar en una vista de presentación de diapositivas.

30. Las visualizaciones del panel deben admitir tipos de gráficos de:
    1. Bar
    2. Tarta
    3. Línea
    4. coropleta
    5. Vista de acordes
    6. Gráfico de burbujas agrupadas
    7. Tendencia de columna
    8. Mapa de calor
    1. Vista de tabla dinámica
    10. Diagrama de Sankey
    11. Gráfico de rayos solares
    50. Mesa
    1000. Combinación (vista de línea y tabla)
    14. Mapa de árbol
    15. Gráfico de dispersión
    16. Valores únicos
    17. medidores
    18. Mapa Geográfico
    19. Definición de humbrales

31. Notificación y Gestión de Incidentes
    1. Marco de notificación de incidentes basado en políticas
    2. Capacidad de activar un script de remediación cuando ocurre un incidente específico
    3. Integración basada en API con sistemas de emisión de tickets externos
    4. Capacidad de ampliar la integración del sistema de tickets a través de API a sistemas de terceros.
    5. Sistema integrado de emisión de tickets/gestión de casos
       1. Capacidad para definir una política de escalada que envía un correo electrónico a la administración cuando se alcanzan los umbrales.
       2. Posibilidad de agregar PDF y PNG a los casos
       3. Capacidad de asignar casos a otros operadores.
       4. Vista de línea de tiempo para capturar actividades en un caso y en incidentes relacionados
       5. Proporcionar métrica de tiempo medio de resolución
    6. Marco de corrección proporcionado para ejecutar una corrección de forma automática o manual en un dispositivo o aplicación.
       1. La solución debe tener más de 30 scripts de corrección integrados para varios proveedores diferentes, como por ejemplo: Microsoft, Linux, Fortinet, Palo Alto, Infoblox, Cisco, Aruba.
       2. Los scripts de corrección se pueden escribir en diferentes lenguajes, incluidos Python, bash y Perl, con ejemplos en Python.

32. Análisis potentes y escalables
    1. Búsqueda de eventos en tiempo real, sin necesidad de indexar ni utilizar operadores lógicos como AND, OR, NOT y paréntesis.
    2. Búsquedas basadas en palabras clave y búsquedas por atributos de eventos analizados frente a datos.
    3. Búsqueda de eventos históricos: consultas tipo SQL con condiciones de filtro booleano, agrupación por agregaciones relevantes, filtros de hora del día, coincidencias de expresiones regulares, expresiones calculadas: GUI y API.
    4. Los operadores de búsqueda deben incluir =,!=, <,>, IS NULL, IS NOT NULL, contiene, no contiene, contiene expresiones regulares, no contiene expresiones regulares.
    5. Capacidad de trabajar con patrones de eventos complejos en tiempo real utilizando el motor de reglas.
       1. Las reglas deben poder variar desde umbrales simples como X número de eventos con Y cantidad de tiempo desde Z valores distintos.
       2. Patrones completos que soportan la lógica booleana completa y permiten:
          1. Subpatrones conectados en la dimensión temporal mediante operadores como AND, OR, SEGUIDO POR, Y NO y NO SEGUIDO_BY
          2. Cada subpatrón puede filtrar y aplicar operadores de agregación como AVG, MAX, MIN, COUNT y COUNT DISTINCT.
          3. Los umbrales pueden ser estáticos o derivarse estadísticamente de datos perfilados.
             1. El perfil estadístico y la alerta de eventos deben incluir
                1. Medias móviles
                2. Desviaciones estandar
             2. Si se excede un umbral estadístico, se debe generar una alerta casi en tiempo real.
    6. Utilización de objetos CMDB descubiertos y datos de usuario/identidad y ubicación en búsquedas y reglas.
    7. Capacidad de enviar informes resultados por correo electrónico
       1. Posibilidad de exportar informes en CSV y PDF
    8. Búsqueda de eventos en toda la organización o hasta un dominio de informes físico o lógico
    1. Capacidad de realizar un seguimiento de los infractores críticos, con la capacidad de utilizar listas de vigilancia en cualquier informe o regla
    10. Análisis agregando nodos VA sin tiempo de inactividad al clúster SIEM
    11. Informes de incidentes críticos.
    50. Los nombres de incidentes deben admitir valores dinámicos como
    1000. Las reglas de correlación deben asignarse a las categorías MITRE (https://attack.mitre.org/matrices/enterprise/).
    14. La solución debe tener una capacidad incorporada de detección de falsos positivos, como poder buscar la identificación CVE a partir de la identificación de firma IPS a través de API y luego determinar si un dispositivo es vulnerable al ataque o no en función de sus vulnerabilidades asociadas.
    15. Capaz de correlacionar automáticamente el usuario con la ubicación y la dirección IP:
        1. Proporciona la capacidad de informar y buscar usuarios desde direcciones IP hasta ubicaciones. La ubicación puede ser un puerto de switch físico, una dirección mac o una VPN.

1. 15. 2. Enriquezca eventos donde no se proporciona ningún contexto de usuario basado en la dirección IP.
   16. En caso de que se produzca un incidente, poder realizar una respuesta automatizada.

33. Capacidad de reenviar cualquier información recopilada sobre eventos.

34. Posibilidad de recibir eventos.

35. Archivado de datos basado en políticas en otra ubicación, como un montaje NFS.

36. La integridad de los datos del evento a través de la GUI.

37. Capacidad para monitorear aplicaciones/dispositivos.

38. Capacidad para modelar dispositivos OT como Servicio Empresarial de Tecnología Operacional con diferentes modelos.

39. El licenciamiento de la herramienta debería ser perpetuo y se debe incluir soporte por 36 con un SLA de 24x7x365 del fabricante integrando la solución a los equipos de seguridad con que cuenta la institución certificada por el fabricante, acceso directo al TAC vía web y/o telefónico. De no renovarse el soporte, la plataforma no debe perder ninguna funcionalidad.

40. El oferente deberá presentar una Carta del fabricante de la marca que lo acredite como canal autorizado para la comercialización y/o implementación del bien ofertado.

41. El oferente deberá presentar certificación de 01 (Un) Técnico nivel Asociado de la marca ofertada.

42. El oferente deberá presentar certificación de 01 (Un) Técnico nivel Profesional de la marca ofertada.

43. El oferente deberá presentar certificación de 01 (Un) Técnico nivel Especialista de la marca ofertada.

44. Servicios de soporte técnico por un periodo de treinta y seis (36) meses del bien ofertado.

45. HORARIO A REALIZAR LOS SERVICIOS

Ordinario: período normal de actividades en oficinas del Ministerio de Industria y Comercio, de Lunes a Viernes de 08:00 hs. a 15:00 hs.

Extraordinario: a pedido de la Institución (los días sábados, domingos y feriados o dentro de los días laborales ordinarios, pero fuera del periodo normal de actividades para las implementaciones que involucren corte en el

servicio, o requerimientos de emergencia).

Ítem

Descripción del Servicio

Unidad de Medida

Cantidad

1

Adquisición de licencias SIEM

Unidad

1

Ítem Nº

Descripción

Unidad de Medida

Cantidad

Lugar de entrega de los bienes

Fecha de entrega de los bienes

1

Adquisición de licencias SIEM

Unidad

1

Ventanilla Única de Exportación

15 días corridos una vez emitida la Orden de Compra

INDICADOR

TIPO

FECHA DE PRESENTACIÓN PREVISTA

Acta de Recepción

Acta de Recepción

10 días calendario, contados a partir de la fecha de recepción del bien y/o servicio