Donde DICE:
25 La protección del lado del cliente debe tener como mínimo las siguientes funcionalidades:
- Bloquear automáticamente dominios sospechosos según su nivel de amenaza y permitir dominios legítimos con excepciones.
- Evaluación del nivel de amenazas.
- Notificaciones en tiempo real para cada nuevo descubrimiento y cambios en servicios existentes.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo en el marco de la licitación, la funcionalidad de protección del lado del cliente con bloqueo automático de dominios, evaluación de amenazas y notificaciones en tiempo real constituye un valor agregado en términos de ciberseguridad avanzada, pero no necesariamente una condición indispensable para la correcta operación del servicio solicitado. Convertir este requisito en opcional permitiría ampliar la participación de oferentes que, si bien cumplen con las demás necesidades y requerimientos establecidos en la licitación. De esta manera, se fomenta la competencia
Donde DICE:
25 La protección del lado del cliente debe tener como mínimo las siguientes funcionalidades:
- Bloquear automáticamente dominios sospechosos según su nivel de amenaza y permitir dominios legítimos con excepciones.
- Evaluación del nivel de amenazas.
- Notificaciones en tiempo real para cada nuevo descubrimiento y cambios en servicios existentes.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo en el marco de la licitación, la funcionalidad de protección del lado del cliente con bloqueo automático de dominios, evaluación de amenazas y notificaciones en tiempo real constituye un valor agregado en términos de ciberseguridad avanzada, pero no necesariamente una condición indispensable para la correcta operación del servicio solicitado. Convertir este requisito en opcional permitiría ampliar la participación de oferentes que, si bien cumplen con las demás necesidades y requerimientos establecidos en la licitación. De esta manera, se fomenta la competencia
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado. Se mantiene como obligatorio por ser una funcionalidad crítica para la defensa contra amenazas modernas.
22
EETT
Donde DICE:
27 La solución debe poseer la capacidad de importar SDL Schemas, para brindar protección para APIs que empleen GRAPHQL.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que la capacidad de importar SDL Schemas para brindar protección específica a APIs que empleen GraphQL representa una funcionalidad de nicho, ya que este tipo de implementación aún no es predominante en la mayoría de entornos productivos. Existen múltiples mecanismos alternativos de protección a nivel de API (como validación de parámetros, control de acceso y limitación de consultas) que cumplen adecuadamente con las necesidades de seguridad sin requerir necesariamente la importación de dichos esquemas. Por ello, exigir esta característica como obligatoria podría restringir la participación de soluciones técnicamente robustas que, si bien no soportan directamente este requerimiento, ofrecen un nivel de protección equivalente mediante otros enfoques ya validados en la industria.
Donde DICE:
27 La solución debe poseer la capacidad de importar SDL Schemas, para brindar protección para APIs que empleen GRAPHQL.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que la capacidad de importar SDL Schemas para brindar protección específica a APIs que empleen GraphQL representa una funcionalidad de nicho, ya que este tipo de implementación aún no es predominante en la mayoría de entornos productivos. Existen múltiples mecanismos alternativos de protección a nivel de API (como validación de parámetros, control de acceso y limitación de consultas) que cumplen adecuadamente con las necesidades de seguridad sin requerir necesariamente la importación de dichos esquemas. Por ello, exigir esta característica como obligatoria podría restringir la participación de soluciones técnicamente robustas que, si bien no soportan directamente este requerimiento, ofrecen un nivel de protección equivalente mediante otros enfoques ya validados en la industria.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado. Se mantiene como obligatorio para garantizar la protección efectiva de APIs GraphQL.
23
EETT
Donde DICE:
28 La solución debe soportar descubrimiento de la API a través de machine learning, generando un archivo de OpenAPI.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que el soporte para el descubrimiento de APIs mediante machine learning con generación automática de archivos OpenAPI constituye una funcionalidad avanzada que no resulta imprescindible para garantizar la seguridad ni la operatividad de las interfaces. Existen mecanismos convencionales de documentación y descubrimiento de APIs, tales como el versionado manual de OpenAPI o el uso de herramientas estándar de integración continua, que cumplen con el objetivo de mantener un control adecuado sobre los servicios publicados. Hacer obligatorio este requerimiento implicaría limitar la participación a soluciones que integren técnicas de machine learning, aun cuando otras soluciones con enfoques más tradicionales puedan ofrecer resultados igual de efectivos, auditables y compatibles con estándares de la industria.
Donde DICE:
28 La solución debe soportar descubrimiento de la API a través de machine learning, generando un archivo de OpenAPI.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que el soporte para el descubrimiento de APIs mediante machine learning con generación automática de archivos OpenAPI constituye una funcionalidad avanzada que no resulta imprescindible para garantizar la seguridad ni la operatividad de las interfaces. Existen mecanismos convencionales de documentación y descubrimiento de APIs, tales como el versionado manual de OpenAPI o el uso de herramientas estándar de integración continua, que cumplen con el objetivo de mantener un control adecuado sobre los servicios publicados. Hacer obligatorio este requerimiento implicaría limitar la participación a soluciones que integren técnicas de machine learning, aun cuando otras soluciones con enfoques más tradicionales puedan ofrecer resultados igual de efectivos, auditables y compatibles con estándares de la industria.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado. Se mantiene como obligatorio por ser un valor agregado significativo para la gestión moderna de APIs.
24
EETT
Donde DICE:
53 Desde el portal se deben poder configurar múltiples puertos de servicio para una aplicación o dominio específico, teniendo la posibilidad de configurar los siguientes tipos:
- TCP: Tráfico NO http.
- HTTP: Tráfico HTTP sin encriptación.
- HTTPS: Tráfico HTTP encriptado.
Solicitamos amablemente pueda considerarse como opcional al TCP atendiendo que el soporte para puertos TCP no-HTTP representa un escenario de uso particular que no resulta indispensable para la operación de la mayoría de las aplicaciones y servicios web contemplados en este proyecto. En cambio, los protocolos HTTP y HTTPS cubren de manera completa los requerimientos funcionales y de seguridad necesarios, siendo además los más utilizados y estandarizados en la industria. Por tanto, la exigencia de TCP no-HTTP debería establecerse como opcional, permitiendo que los oferentes puedan cumplir con el objetivo del requerimiento únicamente mediante la configuración de HTTP/HTTPS.
Donde DICE:
53 Desde el portal se deben poder configurar múltiples puertos de servicio para una aplicación o dominio específico, teniendo la posibilidad de configurar los siguientes tipos:
- TCP: Tráfico NO http.
- HTTP: Tráfico HTTP sin encriptación.
- HTTPS: Tráfico HTTP encriptado.
Solicitamos amablemente pueda considerarse como opcional al TCP atendiendo que el soporte para puertos TCP no-HTTP representa un escenario de uso particular que no resulta indispensable para la operación de la mayoría de las aplicaciones y servicios web contemplados en este proyecto. En cambio, los protocolos HTTP y HTTPS cubren de manera completa los requerimientos funcionales y de seguridad necesarios, siendo además los más utilizados y estandarizados en la industria. Por tanto, la exigencia de TCP no-HTTP debería establecerse como opcional, permitiendo que los oferentes puedan cumplir con el objetivo del requerimiento únicamente mediante la configuración de HTTP/HTTPS.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
25
EETT
Donde DICE:
54 El servicio debe permitir configurar desde el portal y por cada aplicación chequeos de salud de tipo TCP, HTTP y HTTPS.
Solicitamos amablemente pueda considerarse como opcional al TCP atendiendo que los chequeos de salud en protocolos HTTP y HTTPS son suficientes para garantizar la disponibilidad y correcto funcionamiento de la mayoría de las aplicaciones y servicios que se contemplan en este proyecto, dado que representan los protocolos estándar de comunicación en entornos modernos. La verificación mediante TCP, aunque útil en ciertos casos específicos, no aporta un beneficio sustancial adicional respecto a la supervisión basada en HTTP/HTTPS, ya que estos ya permiten evaluar no solo la conectividad sino también la respuesta lógica de la aplicación. Por ello, se solicita que el chequeo de salud de tipo TCP sea opcional, evitando requerirlo como condición restrictiva cuando los otros dos mecanismos cubren ampliamente las necesidades operativas y de seguridad.
Donde DICE:
54 El servicio debe permitir configurar desde el portal y por cada aplicación chequeos de salud de tipo TCP, HTTP y HTTPS.
Solicitamos amablemente pueda considerarse como opcional al TCP atendiendo que los chequeos de salud en protocolos HTTP y HTTPS son suficientes para garantizar la disponibilidad y correcto funcionamiento de la mayoría de las aplicaciones y servicios que se contemplan en este proyecto, dado que representan los protocolos estándar de comunicación en entornos modernos. La verificación mediante TCP, aunque útil en ciertos casos específicos, no aporta un beneficio sustancial adicional respecto a la supervisión basada en HTTP/HTTPS, ya que estos ya permiten evaluar no solo la conectividad sino también la respuesta lógica de la aplicación. Por ello, se solicita que el chequeo de salud de tipo TCP sea opcional, evitando requerirlo como condición restrictiva cuando los otros dos mecanismos cubren ampliamente las necesidades operativas y de seguridad.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
26
EETT
Donde DICE:
67 La solución, a través del portal, y por cada aplicación, debe permitir la creación de reglas para, remover, reescribir e insertar encabezados en el response.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que la capacidad de remover, reescribir e insertar encabezados en las respuestas a nivel de aplicación es una funcionalidad avanzada que, si bien puede resultar útil en escenarios muy específicos de integración o personalización, no es indispensable para la correcta operación ni para la seguridad de los servicios contemplados en este proyecto. La mayoría de las necesidades de control y gestión de tráfico ya se resuelven mediante configuraciones estándar de HTTP/HTTPS y a través de las propias aplicaciones, sin requerir modificaciones directas de encabezados en el response. Por ello, se considera que este requerimiento debería ser opcional, reconociéndolo como un valor agregado pero no como condición obligatoria y limitante para varios fabricantes del rubro .
Donde DICE:
67 La solución, a través del portal, y por cada aplicación, debe permitir la creación de reglas para, remover, reescribir e insertar encabezados en el response.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que la capacidad de remover, reescribir e insertar encabezados en las respuestas a nivel de aplicación es una funcionalidad avanzada que, si bien puede resultar útil en escenarios muy específicos de integración o personalización, no es indispensable para la correcta operación ni para la seguridad de los servicios contemplados en este proyecto. La mayoría de las necesidades de control y gestión de tráfico ya se resuelven mediante configuraciones estándar de HTTP/HTTPS y a través de las propias aplicaciones, sin requerir modificaciones directas de encabezados en el response. Por ello, se considera que este requerimiento debería ser opcional, reconociéndolo como un valor agregado pero no como condición obligatoria y limitante para varios fabricantes del rubro .
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado. Se mantiene como obligatorio por ser una funcionalidad útil para personalización y seguridad.
27
EETT
Donde DICE:
88 El servicio debe contar, como mínimo, con los siguientes estándares de seguridad y calidad:
- ISO/IEC 27001:2013 (Information Security Management Systems).
- ISO/IEC 27032:2012 (Security Techniques -- Guidelines for Cybersecurity)
- ISO 27017:2015 (Information Security for Cloud Services)
- ISO 27018:2014 (Information Security Protection of Personally identifiable information (PII) in public clouds)
Solicitamos amablemente aceptar cumplimiento de uno de los requerimientos dejando la solicitud como 27001 y/o 27032 y/o 27017 y/o 27018.
Los estándares ISO/IEC 27001, 27032, 27017 y 27018 corresponden todos al ámbito de la seguridad de la información, la ciberseguridad y la protección de datos en servicios en la nube, pero tienen alcances específicos y en muchos casos complementarios. Exigir el cumplimiento simultáneo de los cuatro introduce una barrera excesiva, dado que cada uno por sí mismo, o en combinación con otro, ya garantiza un marco robusto de seguridad reconocido internacionalmente. Por ejemplo, la certificación ISO 27001 asegura la gestión integral de la seguridad de la información; la ISO 27017 y 27018 extienden controles específicos a entornos cloud y protección de datos personales; y la ISO 27032 aporta lineamientos de ciberseguridad. Por lo tanto, permitir que el oferente acredite al menos una de estas certificaciones —o una combinación parcial— asegura igualmente el cumplimiento de buenas prácticas internacionales sin excluir soluciones técnicamente sólidas.
Donde DICE:
88 El servicio debe contar, como mínimo, con los siguientes estándares de seguridad y calidad:
- ISO/IEC 27001:2013 (Information Security Management Systems).
- ISO/IEC 27032:2012 (Security Techniques -- Guidelines for Cybersecurity)
- ISO 27017:2015 (Information Security for Cloud Services)
- ISO 27018:2014 (Information Security Protection of Personally identifiable information (PII) in public clouds)
Solicitamos amablemente aceptar cumplimiento de uno de los requerimientos dejando la solicitud como 27001 y/o 27032 y/o 27017 y/o 27018.
Los estándares ISO/IEC 27001, 27032, 27017 y 27018 corresponden todos al ámbito de la seguridad de la información, la ciberseguridad y la protección de datos en servicios en la nube, pero tienen alcances específicos y en muchos casos complementarios. Exigir el cumplimiento simultáneo de los cuatro introduce una barrera excesiva, dado que cada uno por sí mismo, o en combinación con otro, ya garantiza un marco robusto de seguridad reconocido internacionalmente. Por ejemplo, la certificación ISO 27001 asegura la gestión integral de la seguridad de la información; la ISO 27017 y 27018 extienden controles específicos a entornos cloud y protección de datos personales; y la ISO 27032 aporta lineamientos de ciberseguridad. Por lo tanto, permitir que el oferente acredite al menos una de estas certificaciones —o una combinación parcial— asegura igualmente el cumplimiento de buenas prácticas internacionales sin excluir soluciones técnicamente sólidas.
Donde DICE:
88 El servicio debe contar, como mínimo, con los siguientes estándares de seguridad y calidad:
- ISO/IEC 27001:2013 (Information Security Management Systems).
- ISO/IEC 27032:2012 (Security Techniques -- Guidelines for Cybersecurity)
- ISO 27017:2015 (Information Security for Cloud Services)
- ISO 27018:2014 (Information Security Protection of Personally identifiable information (PII) in public clouds)
Solicitamos amablemente aceptar cumplimiento de uno de los requerimientos dejando la solicitud como 27001 y/o 27032 y/o 27017 y/o 27018.
Los estándares ISO/IEC 27001, 27032, 27017 y 27018 corresponden todos al ámbito de la seguridad de la información, la ciberseguridad y la protección de datos en servicios en la nube, pero tienen alcances específicos y en muchos casos complementarios. Exigir el cumplimiento simultáneo de los cuatro introduce una barrera excesiva, dado que cada uno por sí mismo, o en combinación con otro, ya garantiza un marco robusto de seguridad reconocido internacionalmente. Por ejemplo, la certificación ISO 27001 asegura la gestión integral de la seguridad de la información; la ISO 27017 y 27018 extienden controles específicos a entornos cloud y protección de datos personales; y la ISO 27032 aporta lineamientos de ciberseguridad. Por lo tanto, permitir que el oferente acredite al menos una de estas certificaciones —o una combinación parcial— asegura igualmente el cumplimiento de buenas prácticas internacionales sin excluir soluciones técnicamente sólidas.
Donde DICE:
88 El servicio debe contar, como mínimo, con los siguientes estándares de seguridad y calidad:
- ISO/IEC 27001:2013 (Information Security Management Systems).
- ISO/IEC 27032:2012 (Security Techniques -- Guidelines for Cybersecurity)
- ISO 27017:2015 (Information Security for Cloud Services)
- ISO 27018:2014 (Information Security Protection of Personally identifiable information (PII) in public clouds)
Solicitamos amablemente aceptar cumplimiento de uno de los requerimientos dejando la solicitud como 27001 y/o 27032 y/o 27017 y/o 27018.
Los estándares ISO/IEC 27001, 27032, 27017 y 27018 corresponden todos al ámbito de la seguridad de la información, la ciberseguridad y la protección de datos en servicios en la nube, pero tienen alcances específicos y en muchos casos complementarios. Exigir el cumplimiento simultáneo de los cuatro introduce una barrera excesiva, dado que cada uno por sí mismo, o en combinación con otro, ya garantiza un marco robusto de seguridad reconocido internacionalmente. Por ejemplo, la certificación ISO 27001 asegura la gestión integral de la seguridad de la información; la ISO 27017 y 27018 extienden controles específicos a entornos cloud y protección de datos personales; y la ISO 27032 aporta lineamientos de ciberseguridad. Por lo tanto, permitir que el oferente acredite al menos una de estas certificaciones —o una combinación parcial— asegura igualmente el cumplimiento de buenas prácticas internacionales sin excluir soluciones técnicamente sólidas.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
28
EETT - soporte tecnico
para la solicitud 89 El proveedor de las soluciones ofertadas deberá brindar soporte técnico en sitio y/o remoto, en idioma español, 24/7 con un mínimo de 330 horas garantizadas durante el período de licenciamiento de 36 meses.
Consultamos amablemente de estas 330horas ¿deberán ser consideradas horas de ingenieros del fabricante propuesto? ¿Cuántas horas? Recordamos que se tenga en cuenta que el costo de las horas directamente desde el Fabricante es sustancialmente más elevado que las horas del técnico certificado por el fabricante (que pueda residir localmente) para cumplir este requerimiento. Resulta importante que puedan mencionar si serán necesarios y acotar cuantas horas se asumen para el desarrollo del proyecto.
para la solicitud 89 El proveedor de las soluciones ofertadas deberá brindar soporte técnico en sitio y/o remoto, en idioma español, 24/7 con un mínimo de 330 horas garantizadas durante el período de licenciamiento de 36 meses.
Consultamos amablemente de estas 330horas ¿deberán ser consideradas horas de ingenieros del fabricante propuesto? ¿Cuántas horas? Recordamos que se tenga en cuenta que el costo de las horas directamente desde el Fabricante es sustancialmente más elevado que las horas del técnico certificado por el fabricante (que pueda residir localmente) para cumplir este requerimiento. Resulta importante que puedan mencionar si serán necesarios y acotar cuantas horas se asumen para el desarrollo del proyecto.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado. Las 330 horas garantizadas deben ser proporcionadas por personal técnico certificado por el fabricante, pudiendo ser remoto o local. No se especifica un número fijo de horas de ingenieros del fabricante, pero se debe garantizar la capacidad de respuesta durante la vigencia del contrato.
29
EETT
para la solicitud 91 El proveedor local deberá contar como mínimo con 2 técnicos certificados con las certificaciones del producto vigente a la fecha de apertura de ofertas
Consultamos amablemente si serán aceptadas certificaciones del fabricante para demostrar la capacidad técnica.
para la solicitud 91 El proveedor local deberá contar como mínimo con 2 técnicos certificados con las certificaciones del producto vigente a la fecha de apertura de ofertas
Consultamos amablemente si serán aceptadas certificaciones del fabricante para demostrar la capacidad técnica.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado.
30
15) El Pliego de Bases y Condiciones exige lo siguiente:
"La solución debe soportar un modelo de integración basado en API que no requiera cambios de DNS o BGP para proteger las aplicaciones y que cuente con las siguientes características:
En la arquitectura basada en API no se requiere compartir el certificado digital.
En la arquitectura basada en API los requerimientos van directamente a la aplicación.”
Al respecto, la redacción actual limita la integración únicamente al modelo API sin cambios de DNS o BGP, lo cual restringe la participación de soluciones disponibles en el mercado que emplean un modelo de protección basado en redireccionamiento de tráfico mediante cambios controlados de DNS. Este enfoque es ampliamente utilizado en arquitecturas WAAP en la nube y habilita atributos críticos como balanceo global, continuidad operativa y resiliencia multi-PoP.
Adicionalmente, consideramos fundamental que la especificación contemple la presencia regional a través de múltiples puntos de presencia (PoPs), incluyendo al menos un PoP local en Paraguay, a fin de garantizar baja latencia, mayor disponibilidad y la posibilidad de desvío automático del tráfico hacia PoPs regionales en caso de fallas. Esta condición asegura que el servicio mantenga su operación aun ante la caída de un PoP específico, reforzando la resiliencia y continuidad de la solución.
09-09-2025
17-09-2025
15) El Pliego de Bases y Condiciones exige lo siguiente:
"La solución debe soportar un modelo de integración basado en API que no requiera cambios de DNS o BGP para proteger las aplicaciones y que cuente con las siguientes características:
En la arquitectura basada en API no se requiere compartir el certificado digital.
En la arquitectura basada en API los requerimientos van directamente a la aplicación.”
Al respecto, la redacción actual limita la integración únicamente al modelo API sin cambios de DNS o BGP, lo cual restringe la participación de soluciones disponibles en el mercado que emplean un modelo de protección basado en redireccionamiento de tráfico mediante cambios controlados de DNS. Este enfoque es ampliamente utilizado en arquitecturas WAAP en la nube y habilita atributos críticos como balanceo global, continuidad operativa y resiliencia multi-PoP.
Adicionalmente, consideramos fundamental que la especificación contemple la presencia regional a través de múltiples puntos de presencia (PoPs), incluyendo al menos un PoP local en Paraguay, a fin de garantizar baja latencia, mayor disponibilidad y la posibilidad de desvío automático del tráfico hacia PoPs regionales en caso de fallas. Esta condición asegura que el servicio mantenga su operación aun ante la caída de un PoP específico, reforzando la resiliencia y continuidad de la solución.