En las Especificaciones Técnicas, punto de Administración, donde dice:
Debe poder integrarse con sistemas de Directorios como método de autenticación, como mínimo Active Directory, LDAP, Radius.
Solicitamos amablemente que para este punto la autenticación por Radius sea opcional o que se acepte otros métodos de autenticación.
En las Especificaciones Técnicas, punto de Administración, donde dice:
Debe poder integrarse con sistemas de Directorios como método de autenticación, como mínimo Active Directory, LDAP, Radius.
Solicitamos amablemente que para este punto la autenticación por Radius sea opcional o que se acepte otros métodos de autenticación.
En las Especificaciones Técnicas, punto de Network Detection and Response, donde dice:
La solución debe tener la capacidad de detectar tráfico sospechoso a través de la utilización de reglas YARA.
Solicitamos amablemente que para este punto, la solución ofertada pueda integrarse con herramientas que utilizan reglas YARA para la detección de tráfico sospechoso y malware.
En las Especificaciones Técnicas, punto de Network Detection and Response, donde dice:
La solución debe tener la capacidad de detectar tráfico sospechoso a través de la utilización de reglas YARA.
Solicitamos amablemente que para este punto, la solución ofertada pueda integrarse con herramientas que utilizan reglas YARA para la detección de tráfico sospechoso y malware.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución no debe limitar la cantidad de GB por día a recibir, el único parámetro de licenciamiento deben ser Eventos por Segundo.", se solicita amablemente a la entidad considerar la modificación del punto a fin de permitir esquemas de licenciamiento alternativos al modelo exclusivo de Eventos por Segundo (EPS). Existen soluciones que se licencian por cantidad de activos o volúmenes de datos diarios, lo cual ofrece mayor flexibilidad operativa y previsibilidad presupuestaria, sin comprometer la cobertura o funcionalidad. Esta apertura permitirá una mayor competencia y la participación de soluciones técnicamente equivalentes. Lo solicitado encuentra sustento legal en virtud de lo establecido en el Art. 45 de la Ley N° 7021/22, que dispone: “En los procedimientos de contratación será obligación de las convocantes elaborar las bases y condiciones del llamado con la mayor amplitud de acuerdo con la naturaleza específica del contrato con el objeto de que concurra el mayor número de Oferentes”.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución no debe limitar la cantidad de GB por día a recibir, el único parámetro de licenciamiento deben ser Eventos por Segundo.", se solicita amablemente a la entidad considerar la modificación del punto a fin de permitir esquemas de licenciamiento alternativos al modelo exclusivo de Eventos por Segundo (EPS). Existen soluciones que se licencian por cantidad de activos o volúmenes de datos diarios, lo cual ofrece mayor flexibilidad operativa y previsibilidad presupuestaria, sin comprometer la cobertura o funcionalidad. Esta apertura permitirá una mayor competencia y la participación de soluciones técnicamente equivalentes. Lo solicitado encuentra sustento legal en virtud de lo establecido en el Art. 45 de la Ley N° 7021/22, que dispone: “En los procedimientos de contratación será obligación de las convocantes elaborar las bases y condiciones del llamado con la mayor amplitud de acuerdo con la naturaleza específica del contrato con el objeto de que concurra el mayor número de Oferentes”.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución debe realizar el discovery en forma automática de los activos tanto físicos como virtuales que están siendo protegidos o monitoreados. Debe realizar la clasificación automática de los mismos y mantener una base de datos de configuraciones (CMDB), la cual debe tener nativa dentro de la propia herramienta SIEM.", se solicita a la convocante considerar la posibilidad de aceptar soluciones que, si bien pueden no integrar una CMDB completa y nativa, sí incorporan funciones robustas de descubrimiento automático y clasificación de activos, manteniendo una base interna con información esencial (IP, MAC, ubicación, tipo de activo). Este enfoque es común en plataformas modernas, permitiendo una gestión efectiva de activos relevantes para la ciberseguridad sin la complejidad de una CMDB tradicional. Esto ampliará la participación de alternativas técnicas viables y alineadas con los objetivos.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución debe realizar el discovery en forma automática de los activos tanto físicos como virtuales que están siendo protegidos o monitoreados. Debe realizar la clasificación automática de los mismos y mantener una base de datos de configuraciones (CMDB), la cual debe tener nativa dentro de la propia herramienta SIEM.", se solicita a la convocante considerar la posibilidad de aceptar soluciones que, si bien pueden no integrar una CMDB completa y nativa, sí incorporan funciones robustas de descubrimiento automático y clasificación de activos, manteniendo una base interna con información esencial (IP, MAC, ubicación, tipo de activo). Este enfoque es común en plataformas modernas, permitiendo una gestión efectiva de activos relevantes para la ciberseguridad sin la complejidad de una CMDB tradicional. Esto ampliará la participación de alternativas técnicas viables y alineadas con los objetivos.
En las especificaciones técnicas, dónde se cita lo siguiente "Se deberá incluir una plataforma o módulo de inteligencia de amenazas (CTI) de diversas fuentes de inteligencia, tanto públicas como privadas. Esta plataforma o módulo deberá permitir: Cargar indicadores de compromiso de manera eficiente a través de API. Contar con un algoritmo de puntuación basado en reglas, de manera a gestionar la inteligencia sobre amenazas cargada por la entidad. Una vez cargados y procesados los IoC a través del algoritmo de puntuación, la entidad deberá poder crear feeds de inteligencia de amenazas personalizadas. Disponer de al menos 100 fuentes de inteligencia sobre amenazas, asimismo, la solución deberá formar parte de Cyber Threat Alliance.", se solicita amablemente a la entidad considerar la modificación del punto a fin de aceptar que la solución propuesta integre múltiples fuentes de inteligencia sobre amenazas, incluyendo fuentes integradas, premium y personalizables, sin que sea obligatoria la pertenencia a una alianza específica como condición excluyente. Esta flexibilidad permitirá la participación de soluciones técnicamente equivalentes o superiores con ecosistemas de inteligencia más amplios y configurables, garantizando un alto nivel de enriquecimiento y análisis contextual. Lo solicitado encuentra sustento legal en virtud de lo establecido en el Art. 45 de la Ley N° 7021/22, que dispone: “En los procedimientos de contratación será obligación de las convocantes elaborar las bases y condiciones del llamado con la mayor amplitud de acuerdo con la naturaleza específica del contrato con el objeto de que concurra el mayor número de Oferentes”.
En las especificaciones técnicas, dónde se cita lo siguiente "Se deberá incluir una plataforma o módulo de inteligencia de amenazas (CTI) de diversas fuentes de inteligencia, tanto públicas como privadas. Esta plataforma o módulo deberá permitir: Cargar indicadores de compromiso de manera eficiente a través de API. Contar con un algoritmo de puntuación basado en reglas, de manera a gestionar la inteligencia sobre amenazas cargada por la entidad. Una vez cargados y procesados los IoC a través del algoritmo de puntuación, la entidad deberá poder crear feeds de inteligencia de amenazas personalizadas. Disponer de al menos 100 fuentes de inteligencia sobre amenazas, asimismo, la solución deberá formar parte de Cyber Threat Alliance.", se solicita amablemente a la entidad considerar la modificación del punto a fin de aceptar que la solución propuesta integre múltiples fuentes de inteligencia sobre amenazas, incluyendo fuentes integradas, premium y personalizables, sin que sea obligatoria la pertenencia a una alianza específica como condición excluyente. Esta flexibilidad permitirá la participación de soluciones técnicamente equivalentes o superiores con ecosistemas de inteligencia más amplios y configurables, garantizando un alto nivel de enriquecimiento y análisis contextual. Lo solicitado encuentra sustento legal en virtud de lo establecido en el Art. 45 de la Ley N° 7021/22, que dispone: “En los procedimientos de contratación será obligación de las convocantes elaborar las bases y condiciones del llamado con la mayor amplitud de acuerdo con la naturaleza específica del contrato con el objeto de que concurra el mayor número de Oferentes”.
En las especificaciones técnicas, se observan dos requisitos relacionados con la escalabilidad: "La solución debe soportar hasta 30,000 Eventos por Segundo sin necesidad de agregar nodos adicionales" y "Debe poder escalar hasta al menos 5.000 Eventos por segundo y 200.000 flujos por minuto en la misma implementación virtual ofertada". Se solicita amablemente a la entidad clarificar el requisito de capacidad de eventos por segundo (EPS) deseado, ya que se mencionan valores distintos (30.000 EPS y 5.000 EPS). Una vez aclarado el volumen objetivo, se solicita considerar ajustes que permitan valorar arquitecturas que, si bien pueden no soportar el volumen completo en un único nodo físico, sí garantizan el procesamiento eficiente, estable y escalable de los EPS requeridos a través de configuraciones modulares o distribuidas. Estas soluciones logran la capacidad necesaria mediante componentes coordinados que trabajan como una solución integral, optimizando el rendimiento, la disponibilidad y la distribución de carga, lo que puede traducirse en eficiencia operativa y ahorro de costos. Lo solicitado encuentra sustento legal en virtud de lo establecido en el Art. 45 de la Ley N° 7021/22, que dispone: “En los procedimientos de contratación será obligación de las convocantes elaborar las bases y condiciones del llamado con la mayor amplitud de acuerdo con la naturaleza específica del contrato con el objeto de que concurra el mayor número de Oferentes”.
En las especificaciones técnicas, se observan dos requisitos relacionados con la escalabilidad: "La solución debe soportar hasta 30,000 Eventos por Segundo sin necesidad de agregar nodos adicionales" y "Debe poder escalar hasta al menos 5.000 Eventos por segundo y 200.000 flujos por minuto en la misma implementación virtual ofertada". Se solicita amablemente a la entidad clarificar el requisito de capacidad de eventos por segundo (EPS) deseado, ya que se mencionan valores distintos (30.000 EPS y 5.000 EPS). Una vez aclarado el volumen objetivo, se solicita considerar ajustes que permitan valorar arquitecturas que, si bien pueden no soportar el volumen completo en un único nodo físico, sí garantizan el procesamiento eficiente, estable y escalable de los EPS requeridos a través de configuraciones modulares o distribuidas. Estas soluciones logran la capacidad necesaria mediante componentes coordinados que trabajan como una solución integral, optimizando el rendimiento, la disponibilidad y la distribución de carga, lo que puede traducirse en eficiencia operativa y ahorro de costos. Lo solicitado encuentra sustento legal en virtud de lo establecido en el Art. 45 de la Ley N° 7021/22, que dispone: “En los procedimientos de contratación será obligación de las convocantes elaborar las bases y condiciones del llamado con la mayor amplitud de acuerdo con la naturaleza específica del contrato con el objeto de que concurra el mayor número de Oferentes”.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución debe ser compatible con los métodos de recopilación de logs de la industria (syslog, WMI, JDBC, SNMP, Checkpoint LEA, OPSEC, ALE, registros de FTP, SCP, SFTP)", se sugiere ampliar este requisito para permitir la participación de soluciones que, aunque no soporten de forma nativa todos los métodos listados, sí ofrecen mecanismos flexibles, extensibles y compatibles con los estándares de la industria para la recopilación de logs y datos de red. Existen soluciones que integran múltiples métodos de ingesta (syslog, NetFlow, IPFIX, WMI, SNMP) y permiten la integración con fuentes externas mediante API abiertas o agentes de forwarding, lo que asegura un alto nivel de interoperabilidad y adaptabilidad a diversos entornos, incluso heterogéneos.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución debe ser compatible con los métodos de recopilación de logs de la industria (syslog, WMI, JDBC, SNMP, Checkpoint LEA, OPSEC, ALE, registros de FTP, SCP, SFTP)", se sugiere ampliar este requisito para permitir la participación de soluciones que, aunque no soporten de forma nativa todos los métodos listados, sí ofrecen mecanismos flexibles, extensibles y compatibles con los estándares de la industria para la recopilación de logs y datos de red. Existen soluciones que integran múltiples métodos de ingesta (syslog, NetFlow, IPFIX, WMI, SNMP) y permiten la integración con fuentes externas mediante API abiertas o agentes de forwarding, lo que asegura un alto nivel de interoperabilidad y adaptabilidad a diversos entornos, incluso heterogéneos.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución debe tener la capacidad de detectar tráfico sospechoso a través de la utilización de reglas YARA.", se sugiere ampliar este requisito para incluir mecanismos equivalentes o complementarios de detección avanzada de tráfico sospechoso, más allá del uso exclusivo de reglas YARA. Las reglas YARA están más asociadas a la detección de malware en archivos, y su aplicación directa al análisis de tráfico de red puede ser limitada. Existen soluciones que implementan múltiples motores de detección y análisis de tráfico, incluyendo reglas SIGMA, modelos de machine learning (supervisado y no supervisado), sistemas de correlación avanzados, integración con motores IDS, sandboxes, reglas personalizadas y módulos de inteligencia de amenazas. Este enfoque multicapas proporciona mayor precisión, menor tasa de falsos positivos y adaptabilidad a nuevas amenazas, ofreciendo un marco de protección más robusto.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución debe tener la capacidad de detectar tráfico sospechoso a través de la utilización de reglas YARA.", se sugiere ampliar este requisito para incluir mecanismos equivalentes o complementarios de detección avanzada de tráfico sospechoso, más allá del uso exclusivo de reglas YARA. Las reglas YARA están más asociadas a la detección de malware en archivos, y su aplicación directa al análisis de tráfico de red puede ser limitada. Existen soluciones que implementan múltiples motores de detección y análisis de tráfico, incluyendo reglas SIGMA, modelos de machine learning (supervisado y no supervisado), sistemas de correlación avanzados, integración con motores IDS, sandboxes, reglas personalizadas y módulos de inteligencia de amenazas. Este enfoque multicapas proporciona mayor precisión, menor tasa de falsos positivos y adaptabilidad a nuevas amenazas, ofreciendo un marco de protección más robusto.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución debe proporcionar reportes out-of-the-box de cumplimiento de regulaciones y marcos de control -PCI-DSS, HIPAA, SOX, NERC, FISMA, ISO 27001, GLBA, GPG13, SANS, COBIT, NIST, entre otros", se sugiere ajustar este requerimiento para no restringir la participación de soluciones que, si bien pueden no incluir reportes preconfigurados para la totalidad de los marcos mencionados, sí ofrecen plantillas listas para marcos ampliamente utilizados (PCI-DSS, HIPAA, ISO 27001, NIST), además de brindar la flexibilidad para construir y personalizar reportes alineados a otros estándares o requerimientos internos. Este enfoque, basado en plantillas flexibles y reportes dinámicos, permite cumplir con los objetivos de gobernanza, riesgo y cumplimiento, sin depender exclusivamente de reportes fijos y preconfigurados, y amplía la oferta de soluciones.
En las especificaciones técnicas, dónde se cita lo siguiente "La solución debe proporcionar reportes out-of-the-box de cumplimiento de regulaciones y marcos de control -PCI-DSS, HIPAA, SOX, NERC, FISMA, ISO 27001, GLBA, GPG13, SANS, COBIT, NIST, entre otros", se sugiere ajustar este requerimiento para no restringir la participación de soluciones que, si bien pueden no incluir reportes preconfigurados para la totalidad de los marcos mencionados, sí ofrecen plantillas listas para marcos ampliamente utilizados (PCI-DSS, HIPAA, ISO 27001, NIST), además de brindar la flexibilidad para construir y personalizar reportes alineados a otros estándares o requerimientos internos. Este enfoque, basado en plantillas flexibles y reportes dinámicos, permite cumplir con los objetivos de gobernanza, riesgo y cumplimiento, sin depender exclusivamente de reportes fijos y preconfigurados, y amplía la oferta de soluciones.
En las especificaciones técnicas, dónde se cita lo siguiente "Marco de corrección proporcionado para ejecutar una corrección de forma automática o manual en un dispositivo o aplicación. 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. Los scripts de corrección se pueden escribir en diferentes lenguajes, incluidos Python, bash y Perl, con ejemplos en Python.", se sugiere ajustar el enfoque de este requerimiento, permitiendo la participación de soluciones que, en lugar de depender de un número fijo de scripts integrados, cuenten con un módulo de orquestación y automatización (SOAR) nativo. Este módulo debe permitir la ejecución de acciones de corrección, manuales y automáticas, con alta capacidad de integración e interoperabilidad. Algunas plataformas permiten desarrollar e integrar scripts personalizados en lenguajes como Python, Bash, PowerShell, etc., mediante API abiertas o Webhooks, lo cual ofrece una flexibilidad superior para adaptarse a diversos entornos y tecnologías, y puede incluir cientos de playbooks preconfigurados. Este enfoque optimiza tiempos de respuesta y estandariza procedimientos.
En las especificaciones técnicas, dónde se cita lo siguiente "Marco de corrección proporcionado para ejecutar una corrección de forma automática o manual en un dispositivo o aplicación. 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. Los scripts de corrección se pueden escribir en diferentes lenguajes, incluidos Python, bash y Perl, con ejemplos en Python.", se sugiere ajustar el enfoque de este requerimiento, permitiendo la participación de soluciones que, en lugar de depender de un número fijo de scripts integrados, cuenten con un módulo de orquestación y automatización (SOAR) nativo. Este módulo debe permitir la ejecución de acciones de corrección, manuales y automáticas, con alta capacidad de integración e interoperabilidad. Algunas plataformas permiten desarrollar e integrar scripts personalizados en lenguajes como Python, Bash, PowerShell, etc., mediante API abiertas o Webhooks, lo cual ofrece una flexibilidad superior para adaptarse a diversos entornos y tecnologías, y puede incluir cientos de playbooks preconfigurados. Este enfoque optimiza tiempos de respuesta y estandariza procedimientos.